On Wed, Jan 18, 2012 at 10:54:46AM +0100, stephane eranian wrote:
> Should I use Will's -next tree as the base instead of Linus'?
> Given that MARC is shutdown today, would you mind packing those patches
> into a tarball and sending them to me directly?
Other archive sites are available.
There's
On Tue, Jan 17, 2012 at 09:27:02PM +0100, Shilimkar, Santosh wrote:
> There is nothing fancy here. It's an ARM security architecture feature
> which OMAP implements. Have given enough reason about boot-loaders
> issues.
There is nothing fancy about not being permitted to access registers
due to se
On Tue, Jan 17, 2012 at 09:11:37PM +0100, Shilimkar, Santosh wrote:
> On Tue, Jan 17, 2012 at 8:47 PM, Russell King - ARM Linux
> wrote:
> > On Tue, Jan 17, 2012 at 04:27:21PM +, Catalin Marinas wrote:
> >> Anyway, the first step is this API provided by the secure firm
On Tue, Jan 17, 2012 at 04:27:21PM +, Catalin Marinas wrote:
> Anyway, the first step is this API provided by the secure firmware.
> Since such API may need to be called before the MMU is initialised,
> Linux would need to have knowledge of the platform type early on. Having
> some platform hoo
On Tue, Jan 17, 2012 at 02:58:18PM +0100, Shilimkar, Santosh wrote:
> Patching in boot-loaders isn't an option either since every customers
> prefers to use there own boot-loader and then controlling
> this vital bits is impossible.
>
> So I re-iterate that we need to have solution to this problem
On Mon, Jan 16, 2012 at 01:43:03PM +0100, Shilimkar, Santosh wrote:
> This code will be in assembly and that's what I have
> been using. Not having stack shoudn't be a blocker
> and can be work-around in this code. And this API
> has to be anyway called before MMU is enabled.
What about SMC on OMA
On Mon, Jan 16, 2012 at 11:18:21AM +0100, Shilimkar, Santosh wrote:
> + linux-arm, Russell and Catalin
>
> On Mon, Jan 16, 2012 at 11:03 AM, Joe Woodward wrote:
> > The latest uBoot release (2011.12) disables the L2/outer cache during boot
> > on OMAP boards.
> >
> > uBoot commit: "armv7: disabl
On Fri, Jan 13, 2012 at 02:05:20PM +, Russell King - ARM Linux wrote:
> From: Russell King
> ARM: Add arm_memblock_steal() to allocate memory away from the kernel
>
> Several platforms are now using the memblock_alloc+memblock_free+
> memblock_remove trick to obtain memory
On Thu, Jan 12, 2012 at 11:59:51AM -0800, Tony Lindgren wrote:
> * Nicolas Pitre [120112 11:15]:
> > On Thu, 12 Jan 2012, Nicolas Pitre wrote:
> > >
> > > Do you really need that return code?
> > >
> > > It was initially hooked to core_initcall() which requires a return code.
> > > Now that yo
On Thu, Jan 12, 2012 at 09:32:40PM +0100, Shilimkar, Santosh wrote:
> OK. Point taken.
Can you also explain this in the code:
size = ALIGN(PAGE_SIZE, SZ_1M);
Isn't that just SZ_1M written in a rather complex way? A comment may be
a better way of explaining it.
--
To unsubscribe from thi
On Thu, Jan 12, 2012 at 09:20:38PM +0100, Shilimkar, Santosh wrote:
> On Thu, Jan 12, 2012 at 9:11 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Jan 12, 2012 at 08:04:43PM +0000, Russell King - ARM Linux wrote:
> >> On Thu, Jan 12, 2012 at 10:42:57AM -0800, Tony Lindgren
On Thu, Jan 12, 2012 at 08:04:43PM +, Russell King - ARM Linux wrote:
> On Thu, Jan 12, 2012 at 10:42:57AM -0800, Tony Lindgren wrote:
> > Commit 73829af71fdb8655e7ba4b5a2a6612ad34a75a11
> > (Merge branch 'vmalloc' of git://git.linaro.org/people/nico/linux
> > in
On Thu, Jan 12, 2012 at 10:42:57AM -0800, Tony Lindgren wrote:
> Commit 73829af71fdb8655e7ba4b5a2a6612ad34a75a11
> (Merge branch 'vmalloc' of git://git.linaro.org/people/nico/linux
> into devel-stable) merged generic ioremap changes.
>
> Commit 137d105d50f6e6c373c1aa759f59045e6239cf66
> (ARM: OMAP
On Thu, Dec 22, 2011 at 02:19:23PM +0530, Shilimkar, Santosh wrote:
> + Peter Z
>
> On Wed, Dec 21, 2011 at 3:37 PM, Russell King - ARM Linux
> wrote:
> > On Wed, Dec 21, 2011 at 05:59:07PM +0800, Barry Song wrote:
> >> 2011/12/21 Russell King - ARM Linux :
>
On Wed, Dec 21, 2011 at 05:59:07PM +0800, Barry Song wrote:
> 2011/12/21 Russell King - ARM Linux :
> > cpu hotplug is basically totally buggered - the preconditions placed
> > upon the bringup code path are basically impossible to satisfy in any
> > shape or form at the mo
On Wed, Dec 21, 2011 at 05:23:48PM +0800, Barry Song wrote:
> Hi guys,
> i tried cpuhotplug on pandaboard for both
> Pandroid_Froyo_L27.8.2_release_pkg and Linaro 11.11. It has failed to
> work stably.
> On Pandroid_Froyo_L27.8.2_release_pkg, unplugging cpu1 works well:
> # echo 0 > /sys/devices/sy
On Tue, Dec 20, 2011 at 12:28:32AM +0100, Janusz Krzysztofik wrote:
> diff --git a/drivers/input/serio/ams_delta_serio.c
> b/drivers/input/serio/ams_delta_serio.c
> index d4d08bd..56ffd7c 100644
> --- a/drivers/input/serio/ams_delta_serio.c
> +++ b/drivers/input/serio/ams_delta_serio.c
> @@ -165,6
On Fri, Dec 16, 2011 at 04:45:48PM -0800, Turquette, Mike wrote:
> On Wed, Dec 14, 2011 at 5:18 AM, Thomas Gleixner wrote:
> > On Tue, 13 Dec 2011, Mike Turquette wrote:
> >> +void __clk_unprepare(struct clk *clk)
> >> +{
> >> + if (!clk)
> >> + return;
> >> +
> >> + if (WARN_O
On Fri, Dec 09, 2011 at 11:00:01AM +0100, Janusz Krzysztofik wrote:
> On Friday 09 of December 2011 at 09:42:45, Russell King - ARM Linux wrote:
> > On Tue, Nov 29, 2011 at 01:25:32AM +0100, Janusz Krzysztofik wrote:
> > > However, the result of cpufreq_scale() differs from
On Tue, Nov 29, 2011 at 01:25:32AM +0100, Janusz Krzysztofik wrote:
> However, the result of cpufreq_scale() differs from that of
> (re)calibrate_delay() by ca. 6%, i.e., 70.40 vs. 74.54. Please advise if
> this approximation is acceptable.
You don't say which figure is what.
Note that calibrate_
On Mon, Dec 05, 2011 at 02:15:56PM -0700, Paul Walmsley wrote:
> The types associated with clock rates in the clock interface
> (include/linux/clk.h) are inconsistent, and we should fix this.
Rubbish. They're different with good reason. Rates are primerily
unsigned quantities - and should be t
On Fri, Dec 02, 2011 at 10:13:10AM -0700, Paul Walmsley wrote:
> Hi Russell,
>
> On Thu, 1 Dec 2011, Russell King - ARM Linux wrote:
>
> > On Wed, Nov 30, 2011 at 06:20:50PM -0700, Paul Walmsley wrote:
> > > 1. When a clock user calls clk_enable() on a clock, the cl
On Thu, Dec 01, 2011 at 11:30:16AM -0700, Paul Walmsley wrote:
> The intention behind the clk_{allow,block}_rate_change() proposal was to
> allow the current user of the clock to change its rate without having to
> call clk_{allow,block}_rate_change(), if that driver was the sole user of
> the c
On Wed, Nov 30, 2011 at 06:20:50PM -0700, Paul Walmsley wrote:
> 1. When a clock user calls clk_enable() on a clock, the clock framework
> should prevent other users of the clock from changing the clock's rate.
> This should persist until the clock user calls clk_disable() (but see also
> #2 be
On Sun, Nov 27, 2011 at 04:32:30AM +0100, Janusz Krzysztofik wrote:
> This is required on ARM OMAP1 platform, after DPLL reprogramming has
> been fixed by moving it from setup_arch() to kernel_init().
>
> Created against linux-3.2-rc2.
Why do you need this? If you know what the original CPU cloc
On Wed, Nov 23, 2011 at 10:55:19AM -0800, Tony Lindgren wrote:
> What else are you aware of that is really needed early for clocks other
> than clockevent?
TWD will lose its auto-calibration. Then there's various clock source
and clock event implementations. These all call for the clk API to be
On Wed, Nov 23, 2011 at 08:59:04AM -0800, Tony Lindgren wrote:
> ..let's plan on getting rid of the early usage of clocks instead so
> you don't have the issue of deferring stuff.
No - we have too many platforms already using them early to do a change
like this - and to do such a change will force
On Tue, Nov 22, 2011 at 07:42:59AM -0800, Greg KH wrote:
> On Mon, Nov 21, 2011 at 05:40:42PM -0800, Mike Turquette wrote:
> > .sysfs support. Visualize your clk tree at /sys/clk! Where would be
> > a better place to put the clk tree besides the root of /sys/?
>
> Um, in the "proper" place for
On Tue, Nov 15, 2011 at 03:52:36PM +0530, Shubhrajyoti D wrote:
> Making MTD_NAND_OMAP2 depend on ARCH_OMAP2PLUS instead of
> oring with ARCH2/3/4.
>
> Reported-by: Russell King
Thanks, but please make this rmk+ker...@arm.linux.org.uk.
> Signed-off-by: Shubhrajyoti D
> ---
> drivers/mtd/nand
On Tue, Nov 15, 2011 at 11:57:40AM +0530, Shubhrajyoti D wrote:
> Making SERIAL_OMAP depend on ARCH_OMAP2PLUS instead of
> oring with ARCH2/3/4.
>
> Acked-by: Felipe Balbi
> Suggested-by: Sricharan R
> Signed-off-by: Shubhrajyoti D
There's another one:
drivers/mtd/nand/Kconfig: depends o
On Thu, Nov 10, 2011 at 03:33:47PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [10 13:54]:
> > Thanks, merged that into the series. The updated OMAP patch updated is
> > below, which has been moved to part 2. Lastly, the final patch of part
> > 2 has been
On Thu, Nov 10, 2011 at 01:50:09PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [10 11:49]:
> > On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
> > > As suggested by Russell King - ARM Linux ,
> > > there's no need to keep local
On Thu, Nov 10, 2011 at 12:17:19PM -0800, Tony Lindgren wrote:
> As suggested by Russell King - ARM Linux ,
> there's no need to keep local prototypes in non-local headers.
>
> Add mach-omap1/common.h and mach-omap2/common.h and move the
> local prototypes there from plat/com
On Wed, Nov 09, 2011 at 03:25:25PM -0800, Tony Lindgren wrote:
> Commit 7b88e62f5d219a86d81bdf4388012c97dc42e8f8 (ARM: OMAP1: Use generic
> map_io, init_early and init_irq) changed omap1 to use generic map_io.
>
> Looks like I missed one board though. Fix this by adding a custom
> map_io for Amstr
On Tue, Nov 08, 2011 at 12:42:14AM +, Russell King - ARM Linux wrote:
> On Mon, Nov 07, 2011 at 04:18:41PM -0800, Tony Lindgren wrote:
> > * Tony Lindgren [07 13:12]:
> > > * Russell King - ARM Linux [07 12:54]:
> > > > Arnd,
> > > >
>
On Mon, Nov 07, 2011 at 04:18:41PM -0800, Tony Lindgren wrote:
> * Tony Lindgren [07 13:12]:
> > * Russell King - ARM Linux [07 12:54]:
> > > Arnd,
> > >
> > > Don't pull this - there's yet more crap in OMAP to be fixed before
> > >
On Mon, Nov 07, 2011 at 03:07:28PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [07 14:20]:
> > On Mon, Nov 07, 2011 at 02:51:57PM -0800, Tony Lindgren wrote:
> > > Here's what I got. Looks like the removal of the sr[12]_hwmod
> > > part is no lo
On Mon, Nov 07, 2011 at 02:51:57PM -0800, Tony Lindgren wrote:
> Here's what I got. Looks like the removal of the sr[12]_hwmod
> part is no longer needed, so only the r value check part is needed.
Err. So do you have anything in your git tree which you're pushing out
this evening which removes th
On Mon, Nov 07, 2011 at 02:29:35PM -0700, Paul Walmsley wrote:
> On Mon, 7 Nov 2011, Russell King - ARM Linux wrote:
>
> > Again, can never have been tested on OMAP3.
> >
> > Does anyone apart from me bother doing any testing what so ever on OMAP3
> > platforms? Am
Arnd,
Don't pull this - there's yet more crap in OMAP to be fixed before
these go to mainline. OMAP3 is severely broken at the moment with,
to put it bluntly, totally fucked up OMAP hwmod code, and should be
fixed *now* by folk before this pull request.
The fixes are damned trivial I expect even
On Mon, Nov 07, 2011 at 09:39:09PM +0200, Felipe Balbi wrote:
> Hi,
>
> On Mon, Nov 07, 2011 at 06:32:08PM +, Russell King - ARM Linux wrote:
> > On Mon, Nov 07, 2011 at 07:56:57PM +0200, Felipe Balbi wrote:
> > > commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) ha
On Mon, Nov 07, 2011 at 07:56:57PM +0200, Felipe Balbi wrote:
> commit d6504acd (OMAP2+: hwmod: remove OMAP_CHIP*) has
> mistakenly added MUSB as a hwmod available only on ES2.0
> of OMAP3430.
>
> MUSB hwmod has always be available on all OMAP revisions
> since OMAP2430.
This doesn't seem to solv
On Mon, Nov 07, 2011 at 09:55:11PM +0530, Balaji T K wrote:
> From: Per Forlin
>
> Reported by Russell King:
> mmcblk0: error -84 transferring data, sector 149201, nr 64,
> cmd response 0x900, card status 0xb00
> mmcblk0: retrying using single block read
>
> WARNING: at lib/dma-debug.c:811 check
On Mon, Nov 07, 2011 at 09:26:00AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [06 03:44]:
> > Yet again I find that I'm having to email about crap on OMAP3.
> >
> > I'm getting really fed up with OMAP stuff which keeps breaking in
> > idi
On Thu, Nov 03, 2011 at 11:30:02AM -0700, Tony Lindgren wrote:
> Considering we now have the DT branch merged, I'll apply the earlier
> patch from Sanjeev with a minor modification to avoid a build
> warning in board-generic.c.
>
> Updated patch below, Sekhar & Thomas, care to ack?
When are we li
Here's a list of my peaves about current platform code - which are
causing me great issue when trying to clean up the arch_reset() stuff:
1. Lack of trailing ',' on structure initializers
This makes it much harder to add additional initializers at the end
of existing initializers, and increa
Yet again I find that I'm having to email about crap on OMAP3.
I'm getting really fed up with OMAP stuff which keeps breaking in
idiotic ways - and the way there's fatal build errors at EVERY merge
window. The OMAP workflow is totally broken. Something MUST change
in the way the OMAP community w
On Sat, Nov 05, 2011 at 05:57:59PM +0100, Thomas Weber wrote:
> This patch fixes the dependencies for OMAP3_EMU after
> commit 53eebb0df85e4005
> ARM: OC_ETM should not select ARM_AMBA
>
> When "OMAP3 debugging peripherals" is selected the warning:
> (OMAP3_EMU) selects OC_ETM which
> has unmet di
On Tue, Nov 01, 2011 at 05:15:52PM -0500, Omar Ramirez Luna wrote:
> Use runtime PM functionality interfaced with hwmod enable/idle
> functions, to replace direct clock operations, reset and sysconfig
> handling.
>
> Tidspbridge uses a macro removed with this patch, for now the value
> is hardcode
On Fri, Oct 28, 2011 at 11:39:21AM +0200, Tony Lindgren wrote:
> FYI, the ioremap_exec patch seems is available as commit
> 6c5482d53f195d3ca61c9ec1be25b0f4a92575fe (ARM: 7129/1:
> Add __arm_ioremap_exec for mapping external memory)
> in Russell's for-linus branch.
And is in mainline.
--
To unsubs
On Thu, Oct 20, 2011 at 09:12:52AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux [111020 05:23]:
> > On Thu, Oct 20, 2011 at 05:09:07PM +0530, Mohammed, Afzal wrote:
> > > Hi Russell,
> > >
> > > n Mon, Oct 17, 2011 at 18:30:32, Mohamm
On Thu, Oct 20, 2011 at 05:09:07PM +0530, Mohammed, Afzal wrote:
> Hi Russell,
>
> n Mon, Oct 17, 2011 at 18:30:32, Mohammed, Afzal wrote:
> > Hi, Russell,
> >
> > While adding low level debug support for new board in OMAP2+ family, we
> > came across following error,
> >
> > arch/arm/kernel/deb
On Thu, Oct 13, 2011 at 08:36:19PM +0530, Premi, Sanjeev wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Thursday, October 13, 2011 8:26 PM
> > To: Premi, Sanjeev
> > Cc: linux-omap@
On Thu, Oct 13, 2011 at 08:23:43PM +0530, Sanjeev Premi wrote:
> +#if defined(CONFIG_ARCH_OMAP4)
Please use #ifdef unless you're intending to expand the condition.
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More ma
On Thu, Oct 13, 2011 at 11:15:39AM +0200, Ohad Ben-Cohen wrote:
> On Wed, Oct 5, 2011 at 11:26 AM, Ohad Ben-Cohen wrote:
> > Hi Russell,
> >
> > On Sun, Sep 25, 2011 at 1:58 PM, Ohad Ben-Cohen wrote:
> >> Add a private iommu pointer to the ARM-specific arch data in the
> >> device struct, which w
On Fri, Oct 07, 2011 at 03:49:37PM -0700, Kevin Hilman wrote:
> I see this in Arnd's randconfig/arm branch but not yet in
> arm-soc/for-next. Is this being queued for v3.2?
Yes.
> This will also conflict with your devel-stable where the suspend.c is
> added.
Already sorted.
--
To unsubscribe f
On Fri, Oct 07, 2011 at 03:31:26PM -0700, Kevin Hilman wrote:
> Some platforms (e.g. OMAP) use the same common cpu_suspend/cpu_resume
> helpers during idle as well as suspend.
>
> Currently, if suspend is disabled (CONFIG_PM_SLEEP=n) and the platform
> idle code is using the common cpu_suspend/cpu
On Fri, Oct 07, 2011 at 12:48:21PM -0700, Joe Perches wrote:
> On Fri, 2011-10-07 at 20:18 +0100, Russell King - ARM Linux wrote:
> > On Fri, Oct 07, 2011 at 10:40:39AM -0700, Joe Perches wrote:
> > > At some point in the next couple of years, I want
> > > to convert all
On Fri, Oct 07, 2011 at 10:40:39AM -0700, Joe Perches wrote:
> At some point in the next couple of years, I want
> to convert all of, or as many as possible of, the
> remaining printk uses to pr_.
If the idea is also to get rid of printk() too (which IMHO would be a
good thing as it kills off the
On Fri, Oct 07, 2011 at 10:50:16AM +0200, Víctor Manuel Jáquez Leal wrote:
> Convert a printk(KERN_ERR) message in the driver to pr_err().
...
> @@ -111,7 +111,7 @@ static void omap_dm_timer_wait_for_reset(struct
> omap_dm_timer *timer)
> while (!(__raw_readl(timer->sys_stat) & 1)) {
>
On Thu, Oct 06, 2011 at 02:39:28PM -0600, Paul Walmsley wrote:
> @@ -3240,7 +3240,7 @@ int __init omap3xxx_hwmod_init(void)
>
> /* Register hwmods common to all OMAP3 */
> r = omap_hwmod_register(omap3xxx_hwmods);
> - if (!r)
> + if (IS_ERR_VALUE(r))
> return r;
On Thu, Oct 06, 2011 at 01:47:22PM -0600, Paul Walmsley wrote:
> + if ((omap_rev() == OMAP3430_REV_ES3_1 ||
> + omap_rev() == OMAP3430_REV_ES3_1_2) ||
> + cpu_is_omap3630())
> + omap_features |= OMAP3_HAS_IO_CHAIN_CTRL;
(a || b) || c === a || b || c
IOW, n
On Tue, Sep 27, 2011 at 01:10:04PM +0100, Mark Brown wrote:
> On Tue, Sep 27, 2011 at 03:42:45PM +0530, Rajendra Nayak wrote:
>
> > + init_data = devm_kzalloc(dev, sizeof(struct regulator_init_data),
> > +GFP_KERNEL);
> > + if (!init_data)
> > +
On Tue, Oct 04, 2011 at 05:10:36PM -0400, Nicolas Pitre wrote:
> Which makes me think... with all those architectures intercepting
> ioremap calls in order to provide an equivalent static mapping address,
> they already get an unexpected domain given that static mappings are
> mostly DOMAIN_IO a
On Mon, Oct 03, 2011 at 06:09:57PM -0400, Nicolas Pitre wrote:
> On Mon, 3 Oct 2011, Tony Lindgren wrote:
> > Having the SRAM base address move around with different sizes also
> > requires the SoC detection.. Otherwise we can end up mapping wrong
> > size and end up trying to access secure SRAM th
On Sun, Oct 02, 2011 at 04:45:45PM +0200, Arnd Bergmann wrote:
> The logic to allow only one DMA driver in MUSB is currently
> flawed, because it also allows picking no DMA driver at all
> and also not selecting PIO mode.
>
> Using a choice statement makes this foolproof for now and
> also simplif
On Sun, Oct 02, 2011 at 05:56:07PM +0200, Bjarne Steinsbo wrote:
> Arnd,
>
> Ref http://www.spinics.net/lists/linux-omap/msg57274.html
>
> Don't get me wrong. This is not about you "stealing" my patch, or
> anything like that. But look also at thread starting at
> http://www.spinics.net/lists/l
On Sun, Oct 02, 2011 at 04:45:41PM +0200, Arnd Bergmann wrote:
> -#if defined(CONFIG_MENELAUS) &&
> \
> - (defined(CONFIG_MMC_OMAP) || defined(CONFIG_MMC_OMAP_MODULE))
> +#if defined(CONFIG_MENELAUS) && defined(CONFIG_MMC_OMAP)
> +/* || defined(CONF
On Thu, Sep 29, 2011 at 10:00:58AM +0800, Bryan Wu wrote:
> Hiya,
>
> Any comments and need I do anything to improve this patch?
No idea, I don't remember the original errors which this stuff spat out
and how they were caused.
The only thing I care about is that the conversion of the existing AR
On Tue, Sep 20, 2011 at 11:47:18AM +0800, Shawn Guo wrote:
> On Mon, Sep 19, 2011 at 05:37:41PM +0100, Russell King - ARM Linux wrote:
> > This is a re-post of the previous patch series, but with an additional
> > TLB flush to ensure that hte global TLB entry in the page tables is
We don't require cpu_resume_turn_mmu_on as we can combine the ldr
instruction with the following code provided we ensure that
cpu_resume_mmu is aligned for older CPUs. Note that we also align
to a 32-byte boundary to ensure that the code can't cross a section
boundary.
Tested-by: Santosh Shilimka
Only use the preallocated page table during the resume, not while
suspending. This avoids the overhead of having to switch unnecessarily
to the resume page table in the suspend path.
Tested-by: Santosh Shilimkar
Signed-off-by: Russell King
---
arch/arm/kernel/sleep.S | 19 +
There is no need to save and restore the context ID register on ARMv6
and ARMv7 with a temporary page table as we write the context ID
register when we switch back to the real page tables for the thread.
Moreover, the temporary page tables do not contain any non-global
mappings, so the context ID
Convert some of the sleep.S guts to C code, which makes it easier to
use our macros and to add L2 cache handling. We provide a helper
function, __cpu_suspend_save(), which deals with saving the common
state, setting up for resume, and flushing caches.
The remainder left as assembly code is the sa
We need to ensure that state is pushed out from the L2 cache when
suspending so that the resume paths can access their data before the
MMU and caches have been re-initialized. Add the necessary calls to
__cpu_suspend_save().
Tested-by: Santosh Shilimkar
Signed-off-by: Russell King
---
arch/arm
Preallocate a page table and setup an identity mapping for the MMU
enable code. This means we don't have to "borrow" a page table to
do this, avoiding complexities with L2 cache coherency.
Tested-by: Santosh Shilimkar
Signed-off-by: Russell King
---
arch/arm/include/asm/suspend.h | 17 +-
Ensure that the return value from __cpu_suspend is non-zero when
aborting. Zero indicates a successful suspend occurred.
Tested-by: Santosh Shilimkar
Signed-off-by: Russell King
---
arch/arm/kernel/sleep.S |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/kerne
This is a re-post of the previous patch series, but with an additional
TLB flush to ensure that hte global TLB entry in the page tables is
flushed out. This is a flush of all TLB entries, but it could probably
be more targetted if we need to.
Original cover mail follows:
Some systems (such as OM
On Wed, Sep 07, 2011 at 04:48:28PM +0100, Lorenzo Pieralisi wrote:
> > @@ -29,8 +48,7 @@ int cpu_suspend(unsigned long arg, int (*fn)(unsigned
> > long))
> > * resume (indicated by a zero return code), we need to switch
> > * back to the correct page tables.
> > */
> > - ret = __c
On Sun, Sep 11, 2011 at 12:10:04AM +0800, Shawn Guo wrote:
> On Thu, Sep 01, 2011 at 11:57:54PM +0800, Shawn Guo wrote:
> > On Thu, Sep 01, 2011 at 04:34:51PM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Sep 01, 2011 at 11:33:43PM +0800, Shawn Guo wrote:
> > >
On Sat, Sep 17, 2011 at 10:05:14AM -0600, Grant Likely wrote:
> > +static struct omap_device *omap_device_alloc(struct platform_device *pdev,
> > + struct omap_hwmod **ohs, int oh_cnt,
> > + struct omap_device_pm_latency *pm_lats,
On Sat, Sep 17, 2011 at 07:58:20PM +0530, Pedanekar, Hemant wrote:
> But since I had submitted v1 (see [1]) and am working on v2 post review, can
> you
> please suggest how to go about it as I will need the above for adding support
> for TI8148 EVM?
The answer you require is in this statement:
#
On Sat, Sep 10, 2011 at 06:24:53AM +0530, DebBarma, Tarun Kanti wrote:
> [...]
> >> Please rebase onto that branch so these changes can be tested along with
> >> changes already queued for v3.2.
> > Ok.
> I am not able to git pull
> git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-p
On Fri, Sep 09, 2011 at 12:30:11PM -0700, Mark Brown wrote:
> On Fri, Sep 09, 2011 at 08:01:35PM +0100, Russell King - ARM Linux wrote:
>
> > Well, with DT, there won't be any 'board type' anymore. There won't be
> > any 'machine_is_xxx()' to sort
On Fri, Sep 09, 2011 at 12:38:51PM +0100, Mans Rullgard wrote:
> This converts the per-board modules to platform drivers for a
> device created by in main platform setup. These drivers call
> snd_soc_register_card() directly instead of going via a "soc-audio"
> device and the corresponding driver
On Fri, Sep 09, 2011 at 11:42:54AM -0400, Nick Bowler wrote:
> And after all that, I forgot to CC Russell on these patches. Oops.
Doesn't matter, I get them anyway (provided lakml is in the cc).
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to m
On Fri, Sep 09, 2011 at 09:11:52AM -0700, Mark Brown wrote:
> On Fri, Sep 09, 2011 at 10:41:56AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote:
>
> > > The problem is that someone has to manually go and add the device
On Thu, Sep 08, 2011 at 04:59:04PM -0700, Mark Brown wrote:
> On Fri, Sep 09, 2011 at 12:01:02AM +0100, Russell King - ARM Linux wrote:
> > On Thu, Sep 08, 2011 at 03:47:31PM -0700, Mark Brown wrote:
>
> > > What will happen for device tree is that there will be a device in
On Thu, Sep 08, 2011 at 03:47:31PM -0700, Mark Brown wrote:
> On Thu, Sep 08, 2011 at 11:37:20PM +0100, Russell King - ARM Linux wrote:
>
> > With DT of course, all devices get instantiated from the device tree,
> > so there should not be any more platform specific chunks of
On Thu, Sep 08, 2011 at 03:29:11PM -0700, Mark Brown wrote:
> On Thu, 2011-09-08 at 22:28 +0200, Arnd Bergmann wrote:
> > On Thursday 08 September 2011 20:05:48 Mans Rullgard wrote:
>
> > > I had the same thought, but I couldn't find a suitable string anywhere.
> > > Are you suggesting an if(machi
On Wed, Sep 07, 2011 at 04:41:32PM +0100, Catalin Marinas wrote:
> On 1 September 2011 13:49, Russell King - ARM Linux
> wrote:
> > Add a dsb after the isb to ensure that the previous writes to the
> > CP15 registers take effect before we enable the MMU.
> >
> &g
On Tue, Sep 06, 2011 at 04:29:14AM -0700, Tony Lindgren wrote:
> Arnd,
>
> Care to pull the following fixes to the -rc series from Paul?
Tony,
I don't think that will happen until master.kernel.org is back online
as the tree was hosted on that machine.
--
To unsubscribe from this list: send the
On Mon, Sep 05, 2011 at 04:12:02PM +0530, Santosh wrote:
> On Monday 05 September 2011 03:41 PM, Sergei Shtylyov wrote:
>> Hello.
>>
>> On 04-09-2011 17:54, Santosh Shilimkar wrote:
>>
>>> OMAP4 L2X0 initialisation code uses BUG_ON() for the ioremap()
>>> failure scenarios.
>>
>>> Use WARN_ON() ins
On Sat, Sep 03, 2011 at 10:06:38PM +0530, Santosh wrote:
> Thanks a lot Russell for this series. I have tested the entire series
> with OMAP4 S2R and CPUIDLE and it works great.
>
> Tested-by: Santosh Shilimkar
Thanks. I've merged added that to the non-fixes stuff (which Linus
hasn't pulled) and
On Sat, Sep 03, 2011 at 10:03:00PM +0530, Santosh wrote:
> Typo which results in build error.
> Error: co-processor register expected -- `mcr p15,0,ip,c13,0,1'
>
> You can fold below fix.
Kevin already reported this, and I've already folded this fix in. Thanks.
--
To unsubscribe from this list: s
On Fri, Sep 02, 2011 at 11:13:03AM +0200, Cousson, Benoit wrote:
> On 9/2/2011 11:08 AM, Russell King - ARM Linux wrote:
>> On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
>>> Now, that kernel.org is back, I'll pull you branches :-).
>>
>>
On Fri, Sep 02, 2011 at 10:46:56AM +0200, Cousson, Benoit wrote:
> Now, that kernel.org is back, I'll pull you branches :-).
Umm. Are you sure? What are you checking - that some kernel.org
servers are reachable or that master.kernel.org is reachable (it
isn't.)
--
To unsubscribe from this list:
On Thu, Sep 01, 2011 at 11:33:43PM +0800, Shawn Guo wrote:
> This is also the case on i.MX6Q, which L2 cache is retained during a
> suspend/resume cycle. Currently, I have to call into the following
> before calling generic cpu_suspend() to clean/invalidate the entire
> L2 cache.
>
> outer_
Add a dsb after the isb to ensure that the previous writes to the
CP15 registers take effect before we enable the MMU.
Signed-off-by: Russell King
---
arch/arm/mm/proc-v7.S |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
inde
ARM920 and ARM926 save four registers, not three. Fix the size of
the suspend region required.
Signed-off-by: Russell King
---
arch/arm/mm/proc-arm920.S |2 +-
arch/arm/mm/proc-arm926.S |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mm/proc-arm920.S b/arc
901 - 1000 of 2180 matches
Mail list logo
