On Tue, Nov 24, 2009 at 01:20:26PM +, Catalin Marinas wrote:
> BTW, the two patches below were mentioned to me some time ago but I
> haven't got the time to look at them:
>
> [ARM] vfp: Fix bug in vfp_pm_suspend
> https://www.codeaurora.org/gitweb/quic/le/?p=kernel/msm.git;a=commit;h=88984c9b2
On Tue, Oct 19, 2010 at 04:31:30PM -0700, Daniel Walker wrote:
> On Mon, 2010-10-18 at 09:44 +0200, Ohad Ben-Cohen wrote:
> > OMAP4 introduces a Spinlock hardware module, which provides hardware
> > assistance for synchronization and mutual exclusion between heterogeneous
> > processors and those n
On Fri, Oct 22, 2010 at 11:51:08AM -0700, Tony Lindgren wrote:
> diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> index 1953e3d..a58b91d 100644
> --- a/arch/arm/kernel/vmlinux.lds.S
> +++ b/arch/arm/kernel/vmlinux.lds.S
> @@ -114,6 +114,7 @@ SECTIONS
>
On Wed, Oct 27, 2010 at 11:19:47AM +0300, Felipe Contreras wrote:
> Yes, but this has to be done on every library/app that is using the dsp.
> It's much easier to do it on kernel side.
>
> Besides, at least on gst-dsp we want it to work for _all_ bridge
> versions, so it would be:
>
> @@ -829,7 +
On Tue, Nov 23, 2010 at 03:01:17PM +0100, Uwe Kleine-König wrote:
> I wonder if it's not better to make these static inlines instead. Then
> no naming conflicts can occur. And maybe we'd catch some more strange
> things because p gets a proper type.
>
> I don't know how this influences gcc thoug
On Fri, Nov 26, 2010 at 10:53:10AM +0200, Ohad Ben-Cohen wrote:
> >> +int __hwspin_trylock(struct hwspinlock *hwlock, int mode, unsigned long
> >> *flags)
> >> +{
> >> + int ret;
> >> +
> >> + if (unlikely(!hwlock)) {
> >> + pr_err("invalid hwlock\n");
> >
> > These kind of err
On Fri, Nov 26, 2010 at 12:16:39PM +0200, Ohad Ben-Cohen wrote:
> On Fri, Nov 26, 2010 at 11:18 AM, Russell King - ARM Linux
> wrote:
> > On Fri, Nov 26, 2010 at 10:53:10AM +0200, Ohad Ben-Cohen wrote:
> >> >> +int __hwspin_trylock(struct hwspinlock *hwlock, int m
On Sat, Nov 27, 2010 at 12:18:55AM +0200, Ohad Ben-Cohen wrote:
> But then there's the other (quite reasonable) claim that says we
> shouldn't crash the machine because of a non fatal bug: if a crappy
> driver messes up, the user (not the developer) will most probably
> prefer the machine to keep r
On Tue, Nov 30, 2010 at 08:17:00PM +0300, Anton Vorontsov wrote:
> Nothing fancy needs to be done, just use generic SCU routines.
>
> Signed-off-by: Anton Vorontsov
This I assume is an age old patch.
> diff --git a/arch/arm/mach-cns3xxx/include/mach/smp.h
> b/arch/arm/mach-cns3xxx/include/mach
On Tue, Nov 30, 2010 at 08:31:05PM +0300, Anton Vorontsov wrote:
> This greatly reduces amount of platform-specific code, and thus
> makes it easier to add local timers for new platforms.
>
> Technically, it's not very nice to place machine-specific (i.e.
> local_timer_setup()) routine into the ma
On Tue, Nov 30, 2010 at 08:16:58PM +0300, Anton Vorontsov wrote:
> For CNS3xxx we want to reuse the original ARM approach of booting
> secondary CPUs. This patch factors out VExpress' code into a common
> file, so that now platform code can call these routines.
>
> Note that this patch doesn't con
On Tue, Nov 30, 2010 at 08:17:01PM +0300, Anton Vorontsov wrote:
> +/* If there are more than one CPU let them know where to start. */
> +static void __init smp_point_cpus(void)
> +{
> + if (num_present_cpus() <= 1)
> + return;
>
> - for (i = 0; i < ncores; i++)
> -
On Tue, Nov 30, 2010 at 08:16:58PM +0300, Anton Vorontsov wrote:
> +/*
> + * Initialise the CPU possible map early - this describes the CPUs
> + * which may be present or become present in the system.
> + */
> +void __init scu_init_cpus(void __iomem *scu_base)
> +{
> + unsigned int ncores = scu
On Tue, Nov 30, 2010 at 11:32:04PM +, Russell King - ARM Linux wrote:
> Note that I'll go with factoring this out into arch/arm/kernel/smp_scu.c
> for the time being, but I'm not convinced about the other parts yet.
IOW, something like the attached. I've gone a little fu
On Mon, Oct 25, 2010 at 02:10:05PM -0500, Fernando Guzman Lugo wrote:
> Omap platform is omap_iounmap function.
>
> Signed-off-by: Fernando Guzman Lugo
> ---
> arch/arm/plat-omap/iovmm.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/plat-omap/iovmm.c b/
On Thu, Dec 02, 2010 at 06:07:23AM -0600, Kanigeri, Hari wrote:
> Hi Tony,
>
> The following changes since commit e8a7e48bb248a1196484d3f8afa53bded2b24e71:
> Linus Torvalds (1):
> Linux 2.6.37-rc4
>
> are available in the git repository at:
>
> git://gitorious.org/iommu_mailbox/iommu
On Thu, Dec 02, 2010 at 08:50:07AM -0600, Guzman Lugo, Fernando wrote:
> On Thu, Dec 2, 2010 at 6:33 AM, Russell King - ARM Linux
> wrote:
> > On Thu, Dec 02, 2010 at 06:07:23AM -0600, Kanigeri, Hari wrote:
> >> Hi Tony,
> >>
> >
On Thu, Dec 02, 2010 at 03:19:05PM +, Catalin Marinas wrote:
> On 1 December 2010 00:25, Russell King - ARM Linux
> wrote:
> > On Tue, Nov 30, 2010 at 11:32:04PM +0000, Russell King - ARM Linux wrote:
> >> Note that I'll go with factoring this out into arch/arm/ker
On Thu, Dec 02, 2010 at 04:28:40PM +, Catalin Marinas wrote:
> The SCU is part of the core TRM, so I don't expect it to be the same
> across various MP cores (and A15 is an example).
>
> You may want to consolidate functions like scu_prepare_cpus (maybe call
> it smp_prepare_cpus)
You do real
On Thu, Dec 02, 2010 at 05:38:24PM +, Russell King - ARM Linux wrote:
> What if a platform, for what ever reason, wants to have 3 CPUs,
> numbered 0, 2, 3 ? That's the reason why the code which sets the
> possible and present maps isn't in the ARM core code - Eg, we don
This has been around since October:
drivers/video/omap2/vram.c: In function ■omap_vram_reserve_sdram_memblock■:
drivers/video/omap2/vram.c:573: error: ■MEMBLOCK_REAL_LIMIT■ undeclared (first
use in this function)
drivers/video/omap2/vram.c:573: error: (Each undeclared identifier is reported
only
drivers/built-in.o: In function `omapfb_do_probe':
drivers/video/omap/omapfb_main.c:1773: undefined reference to `omap2_int_ctrl'
Looks like there's a missing dependency for CONFIG_FB_OMAP. As the
only place omap2_int_ctrl is defined is in drivers/video/omap/dispc.c,
and this isn't built for OMAP
On Wed, Nov 10, 2010 at 07:50:24PM -0600, Omar Ramirez Luna wrote:
> From: Felipe Contreras
>
> Also, don't be picky about the location, which incidentally fixes the
> build since MEMBLOCK_REAL_LIMIT is gone on 2.6.37.
That comment is wrong. memblock_alloc() is still as picky as the
original.
On Thu, Dec 02, 2010 at 01:58:38PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [101202 13:04]:
> > This has been around since October:
> >
> > drivers/video/omap2/vram.c: In function ■omap_vram_reserve_sdram_memblock■:
> > drivers/video/omap2/vram.c:573:
On Fri, Dec 03, 2010 at 12:09:55PM +0900, Paul Mundt wrote:
> On Thu, Dec 02, 2010 at 02:32:08PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux [101202 14:06]:
> > > On Thu, Dec 02, 2010 at 01:58:38PM -0800, Tony Lindgren wrote:
> > > > * Russell K
On Fri, Dec 03, 2010 at 02:10:23PM +0200, Felipe Contreras wrote:
> On Fri, Dec 3, 2010 at 10:41 AM, Russell King - ARM Linux
> wrote:
> > On Fri, Dec 03, 2010 at 12:09:55PM +0900, Paul Mundt wrote:
> >> This has been fixed since -rc2.
> >
> > So it is.
On Thu, Dec 02, 2010 at 06:01:50PM +, Russell King - ARM Linux wrote:
> On Thu, Dec 02, 2010 at 05:38:24PM +0000, Russell King - ARM Linux wrote:
> > What if a platform, for what ever reason, wants to have 3 CPUs,
> > numbered 0, 2, 3 ? That's the reason why the
This patch series cleans up the GIC code, consolidating some of the
per-platform practices into the common GIC code.
One notable change is to the initialization methods - we used to
require platforms to pass in the address of the per-CPU interfaces
despite them always being identical between all c
Provide gic_init() which initializes the GIC distributor and current
CPU's GIC interface for the boot (or single) CPU.
Signed-off-by: Russell King
---
arch/arm/common/gic.c| 11 +--
arch/arm/include/asm/hardware/gic.h |2 +-
arch/arm/mach-cns3xxx/core.c
We don't need to re-pass the base address for the CPU interfaces to the
GIC for secondary CPUs, as it will never be different from the boot CPU
- and even if it was, we'd overwrite the boot CPU's base address.
Get rid of this argument, and rename to gic_secondary_init().
Signed-off-by: Russell Ki
Every architecture using the GIC has a gic_cpu_base_addr pointer for
GIC 0 for their entry assembly code to use to decode the cause of the
current interrupt. Move this into the common GIC code.
Signed-off-by: Russell King
---
arch/arm/common/gic.c |5 +
arch/ar
This avoids writing unnecessarily to gic_data[] from other CPUs,
making this a mostly read-only variable.
Signed-off-by: Russell King
---
arch/arm/common/gic.c | 48
1 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/arch/arm/commo
Provide a standard get_irqnr_preamble assembler macro for platforms
to use, which retrieves the base address of the GIC CPU interface
from gic_cpu_base_addr. Allow platforms to override this by defining
HAVE_GET_IRQNR_PREAMBLE.
Signed-off-by: Russell King
---
arch/arm/include/asm/hardware/entry
This patch set adds support for __read_mostly - a separate section
which is used to hold data which is hardly ever written.
The idea behind this feature is to reduce the amount of cache line
bouncing between SMP cores by avoiding this data sharing cache lines
with data which is written more freque
Signed-off-by: Russell King
---
arch/arm/kernel/setup.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 336f14e..8075e59 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -75,9 +75,
As our SMP implementation uses MESI protocols. Grouping together data
which is mostly only read together means that we avoid unnecessary
cache line bouncing when this code shares a cache line with other data.
In other words, cache lines associated with read-mostly data are
expected to spend most
On Sun, Dec 05, 2010 at 10:18:27PM +, Catalin Marinas wrote:
> On 5 December 2010 11:43, Russell King - ARM Linux
> wrote:
> > diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
> > index cead889..1581f6d 100644
> > --- a/arch/arm/kernel/vmli
As previously requested.
The following is the behaviour of the latest mainline kernel on the LDP3430
platform.
[ cut here ]
WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1185
_omap_hwmod_enable+0x34/0x114()
omap_hwmod: wd_timer2: enabled state can only be entered from init
On Mon, Dec 06, 2010 at 09:16:23AM -0600, Kanigeri, Hari wrote:
> Ruseell,
>
> On Thu, Dec 2, 2010 at 9:43 AM, Guzman Lugo, Fernando
> wrote:
> > On Thu, Dec 2, 2010 at 9:20 AM, Russell King - ARM Linux
> > wrote:
> >> On Thu, Dec 02, 2010 at 08:50:07AM -
On Mon, Dec 06, 2010 at 07:59:59AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [101206 04:45]:
> >
> > [ cut here ]
> > WARNING: at arch/arm/mach-omap2/omap_hwmod.c:1185
> > _omap_hwmod_enable+0x34/0x114()
> > omap_hwmod: wd_
On Mon, Dec 06, 2010 at 11:27:45AM -0700, Paul Walmsley wrote:
> On Mon, 6 Dec 2010, Tony Lindgren wrote:
>
> > * Russell King - ARM Linux [101206 04:45]:
> > >
> > > NET: Registered protocol family 16
> > > [ cut here ]
> > &
On Tue, Dec 07, 2010 at 04:50:50PM +, Dave Martin wrote:
> I'll follow up shortly with a patch to the generic ARM Kconfig to make
> this explicit, so that ARCH_OMAP2 and THUMB2_KERNEL can't accidentally
> be configured together.
That's a rubbish dependency. You may have an ARCH_OMAP2 platform
On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
> void __init omap1_camera_init(void *info)
> {
> struct platform_device *dev = &omap1_camera_device;
> + dma_addr_t paddr = omap1_camera_phys_mempool_base;
> + dma_addr_t size = omap1_camera_phys_mempool_size;
>
On Mon, Dec 06, 2010 at 09:16:23AM -0600, Kanigeri, Hari wrote:
> Ruseell,
>
> On Thu, Dec 2, 2010 at 9:43 AM, Guzman Lugo, Fernando
> wrote:
> > On Thu, Dec 2, 2010 at 9:20 AM, Russell King - ARM Linux
> > wrote:
> >> On Thu, Dec 02, 2010 at 08:50:07AM -
On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
> On 10 December 2010 17:03, Russell King - ARM Linux
> wrote:
> > On Fri, Dec 10, 2010 at 12:03:07PM +0100, Janusz Krzysztofik wrote:
> >> void __init omap1_camera_init(void *info)
> >> {
> >
On Mon, Dec 13, 2010 at 09:23:29AM -0800, Abhijeet Dharmapurikar wrote:
> Sorry for being late on testing this out. The patch series and works on
> the msm 8660.
>
> Acked-By: Abhijeet Dharmapurikar
Would you prefer a Tested-by: ?
--
To unsubscribe from this list: send the line "unsubscribe lin
John Stultz notes in his commit:
clocksource: Add clocksource_register_hz/khz interface
How to pick good mult/shift pairs has always been difficult to
describe to folks writing clocksource drivers, since it requires
careful tradeoffs in adjustment accuracy vs overflow limits.
In d7e81c2 (clocksource: Add clocksource_register_hz/khz interface) new
interfaces were added which simplify (and optimize) the selection of the
divisor shift/mult constants. Switch over to using this new interface.
Signed-off-by: Russell King
---
arch/arm/mach-omap1/time.c |6 +-
On Mon, Dec 13, 2010 at 05:02:12PM -0600, Guzman Lugo, Fernando wrote:
> On Mon, Dec 13, 2010 at 11:31 AM, Kanigeri, Hari wrote:
> > On Sun, Dec 12, 2010 at 5:20 AM, Russell King - ARM Linux
> > wrote:
> >> On Mon, Dec 06, 2010 at 09:16:23AM -0600, Kanigeri, H
On Tue, Dec 14, 2010 at 05:17:28PM -0700, Paul Walmsley wrote:
> Hello Omar
>
> On Mon, 13 Dec 2010, Ramirez Luna, Omar wrote:
>
> > On Mon, Dec 13, 2010 at 2:12 AM, Cousson, Benoit wrote:
> > > On 12/11/2010 12:45 AM, Ramirez Luna, Omar wrote:
> > >>
> > >> Make the parameter received by omap_d
On Wed, Dec 15, 2010 at 12:39:20PM +, Catalin Marinas wrote:
> On 13 December 2010 16:29, Russell King - ARM Linux
> wrote:
> > On Mon, Dec 13, 2010 at 03:52:20PM +, Catalin Marinas wrote:
> >> On 10 December 2010 17:03, Russell King - ARM Linux
> >> wrote:
ftrace requires sched_clock() to be notrace. Ensure that all
implementations are so marked.
Signed-off-by: Russell King
---
arch/arm/mach-ixp4xx/common.c |2 +-
arch/arm/mach-mmp/time.c |2 +-
arch/arm/mach-pxa/time.c |2 +-
arch/arm/mach-sa1100/gen
On Thu, Dec 16, 2010 at 02:08:11PM +0530, Varadarajan, Charulatha wrote:
> > + oh = omap_hwmod_lookup("mailbox");
> > + if (!oh) {
> > + pr_err("%s: unable to find hwmod\n", __func__);
> > + return;
> > + }
> > +
> > + od = omap_device_build("omap
This patch series replaces existing sched_clock() implementations
with a version which gives a full 64-bit nanosecond time from counters
with less than 33 bits.
This series depends on the prevously posted clocksource patch series,
and the notrace sched_clock patch, and the ftrace tree previously
m
Provide common sched_clock() infrastructure for platforms to use to
create a 64-bit ns based sched_clock() implementation from a counter
running at a non-variable clock rate.
This implementation is based upon maintaining an epoch for the counter
and an epoch for the nanosecond time. When we desir
Convert omap to use the new sched_clock() infrastructure for extending
32bit counters to full 64-bit nanoseconds.
Signed-off-by: Russell King
---
arch/arm/Kconfig |1 +
arch/arm/plat-omap/counter_32k.c | 24 ++--
2 files changed, 23 insertions(+), 2 dele
On Thu, Dec 16, 2010 at 09:27:47AM +, Russell King - ARM Linux wrote:
> Provide common sched_clock() infrastructure for platforms to use to
> create a 64-bit ns based sched_clock() implementation from a counter
> running at a non-variable clock rate.
Some of the comments in the p
There is one issue which remains with this code - that is the
initialization ordering.
init/main.c:
setup_arch(&command_line);
...
sched_init();
...
early_irq_init();
init_IRQ();
...
timekeeping_init();
time_init();
sched_in
On Thu, Dec 16, 2010 at 08:42:23PM +0530, Rabin Vincent wrote:
> On Thu, Dec 16, 2010 at 1:48 PM, Russell King - ARM Linux
> wrote:
> > ftrace requires sched_clock() to be notrace. Ensure that all
> > implementations are so marked.
> >
> > Signed-off-by: Russell Kin
On Thu, Dec 16, 2010 at 09:52:56PM +0530, Rabin Vincent wrote:
> Yes, I now see U300 no longer needs the notrace addition. It still
> could do with the #include addition though, which was
> also being done as part of that patch.
Okay, added to u300, tegra, iop, and omap which weren't including
l
On Thu, Dec 16, 2010 at 11:27:18AM -0600, Omar Ramirez Luna wrote:
> diff --git a/arch/arm/mach-omap2/board-am3517crane.c
> b/arch/arm/mach-omap2/board-am3517crane.c
> index 8ba4047..781ed25 100644
> --- a/arch/arm/mach-omap2/board-am3517crane.c
> +++ b/arch/arm/mach-omap2/board-am3517crane.c
> @@
From: John Stultz
Russell King reports:
| On the ARM dev boards, we have a 32-bit counter running at 24MHz. Calling
| clocks_calc_mult_shift(&mult, &shift, 24MHz, NSEC_PER_SEC, 60) gives
| us a multiplier of 2796202666 and a shift of 26.
|
| Over a large counter delta, this produces an error - l
Here is the entire set of clocksource and sched_clock patches which
have been previously posted. There's a couple of small tweaks in a
few of the patches (such as adding notrace to OMAP clocksource read
functions), and this also shows the proper ordering of these patches.
Still looking for acks o
In d7e81c2 (clocksource: Add clocksource_register_hz/khz interface) new
interfaces were added which simplify (and optimize) the selection of the
divisor shift/mult constants. Switch over to using this new interface.
Signed-off-by: Russell King
---
arch/arm/mach-omap1/time.c |6 +-
ftrace requires sched_clock() to be notrace. Ensure that all
implementations are so marked. Also make sure that they include
linux/sched.h
Also ensure OMAP clocksource read functions are marked notrace as
they're used for sched_clock() too.
Signed-off-by: Russell King
---
arch/arm/mach-ixp4xx
On Tue, Aug 24, 2010 at 11:53:37PM -0400, Jacob Tanenbaum wrote:
> +/* Micron MT46H32M32LF-6 */
> +/* FIXME: borrowed from sdram-micron-mt46h32m32lf-6.h because on LogicPD
> + * boards we can't use the default values -- why? I suspect the reason
> + * lies in the boot strap code. We correct this pa
On Tue, Aug 24, 2010 at 11:53:38PM -0400, Jacob Tanenbaum wrote:
> From: jake
Not a valid address... please fix.
>
> ARM: OMAP3LOGIC: Adding SDMMC support
> Add low-level initialization for hsmmc controller for
> LogicPD's OMAP 3530 LV SOM and OMAP 35x Torpedo bo
On Tue, Aug 24, 2010 at 11:53:40PM -0400, Jacob Tanenbaum wrote:
> +static inline void __init board_smsc911x_init(void)
> +{
> + /* OMAP3530 LV SOM board */
> + if (machine_is_omap3530_lv_som()) {
> + board_smsc911x_data.gpio_irq =
> + OMAP353
Basically same comments as previous patches.
--
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
On Thu, Aug 19, 2010 at 10:38:11AM +0300, Tony Lindgren wrote:
> --- a/arch/arm/kernel/head.S
> +++ b/arch/arm/kernel/head.S
> @@ -346,8 +346,10 @@ __fixup_smp:
> bne smp_on_up @ no, assume UP
> mrc p15, 0, r0, c0, c0, 5 @ read MIDR
> movsr0, r0, lsr #3
On Mon, Aug 30, 2010 at 03:55:27PM -0700, Tony Lindgren wrote:
> * Tony Lindgren [100820 04:59]:
> > * Russell King - ARM Linux [100819 13:13]:
> > > On Thu, Aug 19, 2010 at 12:57:06PM +0300, Tony Lindgren wrote:
> > > > Looks like something is not quit
On Thu, Sep 02, 2010 at 09:20:40AM -0700, Tony Lindgren wrote:
> >From 253e91b76e104dbdf05c5c3eaf9cbf426972c938 Mon Sep 17 00:00:00 2001
> From: Tony Lindgren
> Date: Wed, 1 Sep 2010 16:49:13 -0700
> Subject: [PATCH 3/6] ARM: Fix v7wbi_tlb_flags for SMP on UP
>
> Fix v7wbi_tlb_flags for SMP on UP
On Thu, Sep 02, 2010 at 09:22:20AM -0700, Tony Lindgren wrote:
> >From 8b22546af2ba9a0d96c2f419bfcec1f3c01a414d Mon Sep 17 00:00:00 2001
> From: Tony Lindgren
> Date: Mon, 30 Aug 2010 14:03:28 -0700
> Subject: [PATCH 5/6] ARM: Don't set TLB ops broadcasting on UP ARMv7
>
> Don't set TLB ops broad
On Thu, Sep 02, 2010 at 09:18:47AM -0700, Tony Lindgren wrote:
> >From 7044c13594c3023da6095f8d432eda260bc3207f Mon Sep 17 00:00:00 2001
> From: Tony Lindgren
> Date: Mon, 30 Aug 2010 14:00:54 -0700
> Subject: [PATCH 1/6] ARM: Add inline function smp_on_up() for early init
> testing
>
> Add inli
On Thu, Sep 02, 2010 at 10:21:33AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux [100902 09:50]:
> > On Thu, Sep 02, 2010 at 09:22:20AM -0700, Tony Lindgren wrote:
> > > >From 8b22546af2ba9a0d96c2f419bfcec1f3c01a414d Mon Sep 17 00:00:00 2001
> > > From:
On Thu, Sep 02, 2010 at 11:13:17AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux [100902 10:54]:
> > On Thu, Sep 02, 2010 at 10:21:33AM -0700, Tony Lindgren wrote:
> > > * Russell King - ARM Linux [100902 09:50]:
> > > > On Thu, Sep 02, 2010 at 09:22:2
On Fri, Sep 03, 2010 at 12:20:26PM +0800, Bryan Wu wrote:
> Awesome, where can get those finalize the patches for testing? After
> that I can test our Ubuntu kernel on both boards.
Not yet - they're work in progress. Final patches will probably be a
few days yet.
--
To unsubscribe from this list:
On Fri, Sep 03, 2010 at 09:58:23AM +0100, Will Deacon wrote:
> Your patches are turning up as attachments here, so I can't comment
> inline. The only problem I can see is for SMP v6 platforms (ARM11MPCore)
> where the MPIDR is actually the `CPU ID register' with bits 31:12 set to
> zero, so we'll s
On Thu, Sep 02, 2010 at 04:47:46PM -0700, Tony Lindgren wrote:
> Correction, only boots on SMP hardawre. On UP hardware I still
> need the following patch.
This should fix that properly.
arch/arm/Kconfig | 12
arch/arm/include/asm/assembler.h | 20 +
On Fri, Sep 03, 2010 at 10:07:34AM +0100, Russell King - ARM Linux wrote:
> On Thu, Sep 02, 2010 at 04:47:46PM -0700, Tony Lindgren wrote:
> > Correction, only boots on SMP hardawre. On UP hardware I still
> > need the following patch.
>
> This should fix that properly.
Corr
On Fri, Sep 03, 2010 at 10:04:03AM -0700, Tony Lindgren wrote:
> * Russell King - ARM Linux [100903 02:02]:
> > On Fri, Sep 03, 2010 at 10:07:34AM +0100, Russell King - ARM Linux wrote:
> > > On Thu, Sep 02, 2010 at 04:47:46PM -0700, Tony Lindgren wrote:
> > > >
On Thu, Sep 02, 2010 at 09:21:24AM -0700, Tony Lindgren wrote:
> Do not call test_for_ipi or test_for_ltrirq on UP systems.
>
> Note that we can't put test_for_ltriq into SMP statement as
> it's inlined into the code and the remaining lines of the
> macro would still run before UP macro line.
I t
On Fri, Sep 03, 2010 at 05:30:57PM +0530, Shilimkar, Santosh wrote:
> > diff --git a/arch/arm/kernel/entry-armv.S b/arch/arm/kernel/entry-armv.S
> > index bb2ef60..b8c1ec7 100644
> > --- a/arch/arm/kernel/entry-armv.S
> > +++ b/arch/arm/kernel/entry-armv.S
> > @@ -40,6 +40,11 @@
> > bne asm
On Fri, Sep 03, 2010 at 05:27:25PM +0530, Shilimkar, Santosh wrote:
> Since UP/SMP both cases are handled, the above patch can be something
> like this now...
No - this results in the instruction used for ARMv6 SMP systems being
changed to the ARMv7 instruction, which probably won't work.
--
To u
On Fri, Sep 03, 2010 at 05:36:27PM +0530, Shilimkar, Santosh wrote:
> > -Original Message-
> > From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
> > ow...@vger.kernel.org] On Behalf Of Tony Lindgren
> > Sent: Thursday, September 02, 2010 9:54 PM
> >
On Mon, Sep 06, 2010 at 10:28:53AM +0100, Catalin Marinas wrote:
> I haven't followed your patches closely but can we restrict the ARMv6
> SMP/UP support to only those cores that have TEX remapping (most of them
> probably)?
We don't support TEX remapping on ARMv6.
--
To unsubscribe from this list
On Mon, Sep 06, 2010 at 10:38:30AM +0100, Catalin Marinas wrote:
> On Mon, 2010-09-06 at 10:34 +0100, Russell King - ARM Linux wrote:
> > On Mon, Sep 06, 2010 at 10:28:53AM +0100, Catalin Marinas wrote:
> > > I haven't followed your patches closely but can we restrict
Here's my latest patch (which is combined from two patches.)
Tony, could you follow up with patches for anything which is still
required - I think there's two things you've addressed which this
currently misses:
1. not initializing twd_base (I'm not convinced this is safe - rather
making smp_p
On Sat, Sep 04, 2010 at 02:23:19PM +0200, Michał Mirosław wrote:
> 2010/9/1 Ohad Ben-Cohen :
> > Add a simple mechanism to pass platform data to the
> > SDIO instances of wl12xx.
> >
> > This way there is no confusion over who owns the 'embedded data',
> > typechecking is preserved, and no possibil
On Mon, Sep 06, 2010 at 12:46:34PM +0100, Catalin Marinas wrote:
> Russell,
>
> I can see you posted another version while writing this e-mail. But I
> think most comments still apply.
>
> On Fri, 2010-09-03 at 10:10 +0100, Russell King - ARM Linux wrote:
> > diff --gi
On Mon, Sep 06, 2010 at 04:53:47PM +0100, Catalin Marinas wrote:
> On Mon, 2010-09-06 at 16:34 +0100, Russell King - ARM Linux wrote:
> > On Mon, Sep 06, 2010 at 12:46:34PM +0100, Catalin Marinas wrote:
> > > Would this work with Thumb-2 kernel builds? Maybe you can add a W(instr
On Tue, Sep 07, 2010 at 08:14:05PM -0700, Tony Lindgren wrote:
> This is not needed on UP. Additionally with will cause issues when
> booting CONFIG_SMP_ON_UP kernel on earlier ARM cores.
Doesn't make sense.
>
> Signed-off-by: Tony Lindgren
>
> diff --git a/arch/arm/kernel/process.c b/arch/arm
On Mon, Sep 06, 2010 at 09:42:41PM +0200, Michał Mirosław wrote:
> W dniu 6 września 2010 14:07 użytkownik Russell King - ARM Linux
> napisał:
> > On Sat, Sep 04, 2010 at 02:23:19PM +0200, Michał Mirosław wrote:
> >> 2010/9/1 Ohad Ben-Cohen :
> >> > Add a simple m
On Fri, Sep 17, 2010 at 03:17:46PM +0530, Santosh Shilimkar wrote:
> Currently we map 1 MB section while setting up SRAM on OMAPs.
> The actual physcal OCM RAM available on OMAP SOCs is in order
physical
> of KBs. This patch maps only available sram and removes some
> non necessary cpu_is_xxx che
On Fri, Sep 17, 2010 at 03:17:47PM +0530, Santosh Shilimkar wrote:
> On Davinci SRAM is mapped as MT_DEVICE becasue of the section
> mapping pre-requisite instead of intended MT_MEMORY_NONCACHED
>
> Since the section mapping limitation gets fixed with first
> patch in this series, the MT_MEMORY_NO
On Thu, Sep 23, 2010 at 08:02:40PM +0530, Varadarajan, Charulatha wrote:
> +static struct omap_hwmod omap2430_wd_timer2_hwmod = {
> + .name = "wd_timer2",
> + .class = &omap2430_wd_timer_hwmod_class,
> + .main_clk = "mpu_wdt_fck",
Why are we going backwards to
On Fri, Sep 24, 2010 at 08:38:37AM -0700, Cory Maccarrone wrote:
> Not really sure, I wasn't the one who first came up with that mask.
> All I know is that it seems to work, and not just for my device, but
> lots of other HTC OMAP850 devices we've tried it on too.
>
> I'm interested though, what i
On Mon, Sep 27, 2010 at 07:11:37PM +0530, G, Manjunath Kondaiah wrote:
> > Can you please check that? Will not merge for now until we
> > figure out what changes with these patches.
> >
> > Then, I also noticed the following exports getting added:
> >
> > +EXPORT_SYMBOL(omap2_gp_clockevent_set_g
On Tue, Sep 28, 2010 at 12:29:01PM +0530, Nayak, Rajendra wrote:
> ...
> > > >
> > > > static int omap_i2c_init(struct omap_i2c_dev *dev)
> > > > @@ -356,6 +333,7 @@ static int omap_i2c_init(struct omap_i2c_dev *dev)
> > > > unsigned long fclk_rate = 1200;
> > > > unsigned long
On Wed, Sep 29, 2010 at 03:51:21PM +0100, Catalin Marinas wrote:
> Hi Santosh,
>
> Santosh Shilimkar wrote:
> > This patch populates the L1 entries for MT_MEMORY and MT_MEMORY_NONCACHED
> > types so that at boot-up, we can map memories outside system memory
> > at page level granularity
> >
> > P
401 - 500 of 2180 matches
Mail list logo
