If CONFIG_CPU_V6 is enabled, avoid using the double-word exclusive
instructions in the kernel's atomic implementations as these are not
supported. Fall back to the generic spinlock code instead.
Signed-off-by: Russell King
---
arch/arm/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 dele
Rather than turning off CPU domain switching when the build architecture
includes ARMv6K, thereby causing problems for ARMv6-supporting kernels,
turn it on when it's required to support a CPU architecture.
Signed-off-by: Russell King
---
arch/arm/mm/Kconfig |7 +--
1 files changed, 5 ins
CPU_32v6K controls whether we use the ARMv6K extension instructions in
the kernel, and in some places whether we use SMP-safe code sequences
(eg, bitops.)
MX3 prevents the selection of this option to ensure that it is not
enabled for their CPU, which is ARMv6 only. Now that we've split the
CPU_V6
Make Dove platforms select the new V6K CPU option.
Signed-off-by: Russell King
---
arch/arm/mach-dove/Kconfig |4 +++-
arch/arm/mm/Kconfig|4 ++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-dove/Kconfig b/arch/arm/mach-dove/Kconfig
index a4ed390.
SMP extensions are only supported on ARMv6k or ARMv7 architectures, so
only offer the option if we're building for such an architecture.
Signed-off-by: Russell King
---
arch/arm/Kconfig |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
i
If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register.
Use the conditional code which copes with this variability. Otherwise,
if CONFIG_CPU_32v6K is set, we know we have the TLS register on all
supported CPUs, so use it unconditionally.
Signed-off-by: Russell King
---
arch/arm/in
Now that we build a v6+v6k+v7 kernel with -march=armv6k for everything,
we don't need to disable swp emulation to work around the build problem
with OMAP.
Signed-off-by: Russell King
---
arch/arm/mm/Kconfig |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/Kco
If CONFIG_CPU_V6 is enabled, then the kernel must support ARMv6 CPUs
which don't have the V6K extensions implemented. Always use the
dummy store-exclusive method to ensure that the exclusive monitors are
cleared.
If CONFIG_CPU_V6 is not set, but CONFIG_CPU_32v6K is enabled, then we
have the K ext
Introduce a CPU_V6K configuration option for platforms to select if they
have a V6K CPU core. This allows us to identify whether we need to
support ARMv6 CPUs without the V6K SMP extensions at build time.
Currently CPU_V6K is just an alias for CPU_V6, and all places which
reference CPU_V6 are rep
On Mon, Jan 17, 2011 at 05:23:43PM -0500, Nicolas Pitre wrote:
> On Mon, 17 Jan 2011, Russell King - ARM Linux wrote:
>
> > If CONFIG_CPU_V6 is enabled, we may or may not have the TLS register.
> > Use the conditional code which copes with this variability. Otherwise,
> >
On Mon, Jan 17, 2011 at 10:36:35PM +, Russell King - ARM Linux wrote:
> It may be better at some point to get rid of the CPU_32v* and replace
> them with CPU_ARCH_V* instead, which makes it clear that these ones
> definitely refer to the architecture versions.
Last point on this
On Tue, Jan 18, 2011 at 09:52:44AM +0200, Aaro Koskinen wrote:
> Move voiceblue definitions into the board-specific header.
>
> Signed-off-by: Aaro Koskinen
Let's instead simplify this, and allow other platforms to hook into the
reset handler if they choose. This has only been build-tested on m
On Tue, Jan 18, 2011 at 10:36:08AM -, Will Deacon wrote:
> > diff --git a/arch/arm/Makefile b/arch/arm/Makefile
> > index c22c1ad..9c43052 100644
> > --- a/arch/arm/Makefile
> > +++ b/arch/arm/Makefile
> > @@ -89,6 +89,7 @@ tune-$(CONFIG_CPU_XSCALE) :=$(call
> > cc-option,-mtune=xscale,-mtune=
On Tue, Jan 18, 2011 at 11:09:22AM +, Russell King - ARM Linux wrote:
> I'd rather not in this patch - this patch adds CPU_V6K as an alias for
> CPU_V6 - so eveywhere which referenced CPU_V6 becomes (CPU_V6 || CPU_V6K).
> We could remove it in a later patch though.
Here's a
On Tue, Jan 18, 2011 at 01:00:21AM -0500, Nicolas Pitre wrote:
> I also wonder what happens with a misaligned ldrex/strex... Does the
> alignment trap get invoked? If so, the assertion could be put there
> instead if that's not done already, removing this overhead from bitops
> calls. In the p
On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
> On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King - ARM Linux wrote:
> > This patch series reworks the ARMv6/ARMv6K support options, code
> > selection, and bit operations such that it's possible t
On Tue, Jan 18, 2011 at 04:44:52PM +0200, Kirill A. Shutemov wrote:
> On Tue, Jan 18, 2011 at 02:40:14PM +0000, Russell King - ARM Linux wrote:
> > On Tue, Jan 18, 2011 at 04:30:41PM +0200, Kirill A. Shutemov wrote:
> > > On Mon, Jan 17, 2011 at 07:20:50PM +0000, Russell King
On Tue, Jan 18, 2011 at 04:32:57PM +0100, Uwe Kleine-König wrote:
> Hi Russell,
>
> On Mon, Jan 17, 2011 at 10:46:18AM +, Russell King - ARM Linux wrote:
> > On Mon, Jan 17, 2011 at 11:08:57AM +0100, Uwe Kleine-König wrote:
> > > On Sun, Jan 16, 2011 at 12:19:11PM +
On Tue, Jan 18, 2011 at 04:58:51PM +0100, Uwe Kleine-König wrote:
> Hello Russell,
>
> On Tue, Jan 18, 2011 at 03:43:44PM +, Russell King - ARM Linux wrote:
> > On Tue, Jan 18, 2011 at 04:32:57PM +0100, Uwe Kleine-König wrote:
> > > On Mon, Jan 17, 2011 at 10:46:18AM +
A warning for OMAP.
Your use of the __virt_to_phys() in assembly code for the debug stuff
will break with this patch... please ensure that it is resolved by the
next merge window.
- Forwarded message from Russell King - ARM Linux
-
Date: Tue, 04 Jan 2011 20:23:18 +
From: Russell
On Tue, Jan 18, 2011 at 01:05:49PM +0100, Jean Pihet wrote:
> Dave, Russell,
>
> On Mon, Jan 17, 2011 at 4:46 PM, Dave Martin wrote:
> > One way to work around this is would be to make omap_sram_push() a macro:
> >
> > #define omap_sram_push(funcp, size) \
> > (typeof(funcp))_do_omap_sram_push
On Thu, Jan 20, 2011 at 03:06:30PM -0600, Aguirre, Sergio wrote:
> And while debugging further, i realized that the point of stall was
> in mm/memory.c, function:
>
> static int remap_pte_range(struct mm_struct *mm, pmd_t *pmd,
> unsigned long addr, unsigned long end,
>
On Fri, Jan 21, 2011 at 07:13:48PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Rob Herring [mailto:robherri...@gmail.com]
> > Sent: Thursday, January 20, 2011 10:05 PM
> > To: Santosh Shilimkar
> > Cc: linux-arm-ker...@lists.infradead.org; Russell King; linux-
> > o...@
On Fri, Jan 21, 2011 at 09:00:04AM -0600, Rob Herring wrote:
> Why? If preset_lpj is non-zero, calibrate_delay will effectively be
> skipped which is the same thing your patch does.
Theoretically...
You boot. lpj= sets preset_lpj. calibrate_delay() sets loops_per_jiffy
based on preset_lpj whi
On Sat, Jan 22, 2011 at 01:14:21PM +0530, Santosh Shilimkar wrote:
> Surely whichever way we should remove the recalibration otherwise
> every time secondary cpus spend ~ 200 ms there.
>
> Russell,
> How do you like to address this?
Well, the last piece of the puzzle which needs consideration is
On Mon, Jan 17, 2011 at 07:21:40PM +, Russell King - ARM Linux wrote:
> Switch the set/clear/change bitops to use the word-based exclusive
> operations, which are only present in a wider range of ARM architectures
> than the byte-based exclusive operations.
>
> Signed-off-b
On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
> At least another person did post results:
>
> http://mid.gmane.org/20110117094602.ga2...@pulham.picochip.com
> http://mid.gmane.org/20110117110308.gc2...@pulham.picochip.com
Slightly different patch - there were three revisions. I
On Sun, Jan 23, 2011 at 03:39:23PM +0300, Sergei Shtylyov wrote:
>> diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
>> index 4d7a816..22690e9 100644
>> --- a/drivers/video/omap2/dss/dss.c
>> +++ b/drivers/video/omap2/dss/dss.c
> [...]
>> @@ -609,15 +609,18 @@ static int d
Move non-mapping and non-irq initialization code out of .map_io and
.init_irq respectively into the new init_early hook.
Signed-off-by: Russell King
---
I think I've updated this patch correctly for the new platforms merged
into mainline.
Please ensure that new platforms merged after this patch
On Sun, Jan 23, 2011 at 05:13:44PM +, Russell King - ARM Linux wrote:
> Move non-mapping and non-irq initialization code out of .map_io and
> .init_irq respectively into the new init_early hook.
>
> Signed-off-by: Russell King
> ---
> I think I've updated this patc
On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote:
> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav wrote:
> > On Sun, Jan 23, 2011 at 3:05 PM, Russell King - ARM Linux
> > wrote:
> >> On Sat, Jan 22, 2011 at 11:44:59PM -0500, Nicolas Pitre wrote:
> >
On Mon, Jan 24, 2011 at 02:21:19PM +0530, Santosh Shilimkar wrote:
> On some architectures, secondary cores shares clock with primiary
> core and hence scale together. Hence secondary core lpj calibration
> is not necessary and can be skipped to save considerable time.
>
> This can speed up the se
On Mon, Jan 24, 2011 at 02:21:17PM +0530, Santosh Shilimkar wrote:
> In CPU low power state, local timer looses its register context. This
> patch adds context save restore hooks which can be used by platforms
> appropriately.
I thought the whole point of CLOCK_EVT_FEAT_C3STOP was that the generic
On Mon, Jan 24, 2011 at 11:06:09AM +, Russell King - ARM Linux wrote:
> On Mon, Jan 24, 2011 at 02:21:17PM +0530, Santosh Shilimkar wrote:
> > In CPU low power state, local timer looses its register context. This
> > patch adds context save restore hooks which can be us
On Mon, Jan 24, 2011 at 07:17:54PM +0530, Poddar, Sourav wrote:
> On Mon, Jan 24, 2011 at 3:58 PM, Russell King - ARM Linux
> wrote:
> > On Mon, Jan 24, 2011 at 02:27:24PM +0530, Poddar, Sourav wrote:
> >> On Mon, Jan 24, 2011 at 2:08 PM, Poddar, Sourav
> >> wrot
On Mon, Jan 24, 2011 at 08:24:41PM +0530, Poddar, Sourav wrote:
> nfs filesystem.
Thanks.
--
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 Mon, Jan 24, 2011 at 12:26:29PM -0800, Tony Lindgren wrote:
> * Tony Lindgren [110124 12:16]:
> >
> > So far tested on zoom3 only, but the following gets it booting
> > on top of your patch.
>
> Looks like there are some other patches needed too.. At least
> omap4 still fails with these.
>Fr
On Mon, Jan 24, 2011 at 11:39:13PM -0800, Colin Cross wrote:
> On Mon, Jan 24, 2011 at 3:11 AM, Russell King - ARM Linux
> wrote:
> > On Mon, Jan 24, 2011 at 11:06:09AM +0000, Russell King - ARM Linux wrote:
> >> On Mon, Jan 24, 2011 at 02:21:17PM +0530, Santosh Shilimkar wro
On Mon, Jan 24, 2011 at 11:39:13PM -0800, Colin Cross wrote:
> This doesn't work for oneshot timers if the TWD_TIMER_CONTROL register
> gets reset by cpu idle between twd_set_mode and twd_set_next_event.
> Shadowing ctrl in a percpu variable and rewriting it during every call
> to twd_set_next_even
On Mon, Jan 24, 2011 at 02:21:18PM +0530, Santosh Shilimkar wrote:
> This patch moves SCU register defines from smp_scu.c to smp_scu.h
> so that its available for platforms to use
>
> The SCU CPU power status registers is used for power management
> on OMAP4.
Could we instead have an API inside s
On Tue, Jan 25, 2011 at 05:10:37PM +0530, Santosh Shilimkar wrote:
> As I was suspecting the one shot mode wouldn't work it. Collin
> just confirmed it.
> To make it fully work it needs control register save restore.
> And that can be managed within TWD library so that every platform
> doesn't have
On Tue, Jan 25, 2011 at 05:32:57PM +0530, Santosh Shilimkar wrote:
> I have similar patch implemented but what it does is just
> prepares the value to be programmed and stores it to a scratchpad.
> I see your point but below patch may now work well. The reason is the SCU
> register needs to accesse
On Tue, Jan 25, 2011 at 05:38:49PM +0530, Santosh Shilimkar wrote:
> Looping Thomas G
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Tuesday, January 25, 2011 5:19 PM
> > To: Santosh Shilimkar
> > Cc: Col
On Tue, Jan 25, 2011 at 12:16:56PM +, Russell King - ARM Linux wrote:
> On Tue, Jan 25, 2011 at 05:32:57PM +0530, Santosh Shilimkar wrote:
> > I have similar patch implemented but what it does is just
> > prepares the value to be programmed and stores it to a scratchpad.
>
On Tue, Jan 25, 2011 at 06:06:27PM +0530, Santosh Shilimkar wrote:
> Ok. I missed some information my last email.
> The SCU power status programming is used to take CPU in/out
> of coherency as an alternative to SMP bit. We don't
> have an access to SMP bit on OMAP4. ARM has already
> confirmed SCU
On Tue, Jan 25, 2011 at 12:56:56PM +, Russell King - ARM Linux wrote:
> On Tue, Jan 25, 2011 at 06:06:27PM +0530, Santosh Shilimkar wrote:
> > Ok. I missed some information my last email.
> > The SCU power status programming is used to take CPU in/out
> > of coherency as
On Tue, Jan 25, 2011 at 01:04:22PM +, Russell King - ARM Linux wrote:
> Actually, we can do this safely - byte stores are permitted to SCU
> registers probably for this very reason.
3rd revision of the patch:
arch/arm/include/asm/smp_scu.h |5 +
arch/arm/kernel/smp_scu.c
On Tue, Jan 25, 2011 at 02:23:10PM +0100, Thomas Gleixner wrote:
> On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
> > On Mon, Jan 24, 2011 at 11:39:13PM -0800, Colin Cross wrote:
> > > On Mon, Jan 24, 2011 at 3:11 AM, Russell King - ARM Linux
> > > wrote:
> &g
On Tue, Jan 25, 2011 at 06:06:27PM +0530, Santosh Shilimkar wrote:
> Ok. I missed some information my last email.
> The SCU power status programming is used to take CPU in/out
> of coherency as an alternative to SMP bit. We don't
> have an access to SMP bit on OMAP4. ARM has already
> confirmed SCU
On Tue, Jan 25, 2011 at 01:57:26PM -, Will Deacon wrote:
> Hi Russell,
>
> Hopefully this isn't too late to be useful.
>
> > On Mon, Jan 17, 2011 at 07:21:40PM +0000, Russell King - ARM Linux wrote:
> > > Switch the set/clear/change bitops to use the word-
On Tue, Jan 25, 2011 at 03:12:24PM +0100, Thomas Gleixner wrote:
> On Tue, 25 Jan 2011, Russell King - ARM Linux wrote:
> > On Tue, Jan 25, 2011 at 02:23:10PM +0100, Thomas Gleixner wrote:
> > > In which way? I mean the generic code issues a call to the set_mode
> > >
On Tue, Jan 25, 2011 at 09:34:15PM +0530, Santosh Shilimkar wrote:
> Russell, Thomas
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Tuesday, January 25, 2011 7:08 PM
> > To: Thomas Gleixner
> > C
On Tue, Jan 25, 2011 at 04:43:52PM +, Dave Martin wrote:
> A couple of questions on this:
>
> 1) I notice these spinlock functions are generally marked inline.
>
> Is that likely to happen in modules? If so, there would be a need to
> do SMP_ON_UP fixups at module load time -- I don't think
On Tue, Jan 25, 2011 at 05:33:14PM +, Dave Martin wrote:
> On Tue, Jan 25, 2011 at 4:59 PM, Russell King - ARM Linux
> wrote:
> > On Tue, Jan 25, 2011 at 04:43:52PM +, Dave Martin wrote:
> >> A couple of questions on this:
> >>
> >> 1) I notice
On Wed, Jan 26, 2011 at 09:46:13AM +0100, Uwe Kleine-König wrote:
> Will you care for imx (mach-{mx*,imx}), too, or should I fix them up?
Does mx stuff do non-irq setup or non-map_io stuff in those callbacks?
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a
On Fri, Jan 07, 2011 at 08:56:26AM -0800, Tony Lindgren wrote:
> > diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> > index e66687b..c203204 100644
> > --- a/arch/arm/mach-omap2/io.c
> > +++ b/arch/arm/mach-omap2/io.c
> > @@ -314,14 +314,13 @@ static int _set_hwmod_postsetup_state
On Fri, Jan 07, 2011 at 08:56:26AM -0800, Tony Lindgren wrote:
> > diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> > index 17bd639..9eaa28c 100644
> > --- a/arch/arm/mach-omap2/mux.c
> > +++ b/arch/arm/mach-omap2/mux.c
> > @@ -160,7 +160,7 @@ static int __init _omap_mux_get_by_
On Wed, Jan 26, 2011 at 10:11:03AM +0100, Uwe Kleine-König wrote:
> On Wed, Jan 26, 2011 at 08:52:40AM +0000, Russell King - ARM Linux wrote:
> > On Wed, Jan 26, 2011 at 09:46:13AM +0100, Uwe Kleine-König wrote:
> > > Will you care for imx (mach-{mx*,imx}), too, or sh
On Wed, Jan 26, 2011 at 11:11:31AM +, Dave Martin wrote:
> Do we need to consider any other discarded sections? In vmlinux.lds, I have:
>
> /* Default discards */
> /DISCARD/ : { *(.exit.text) *(.cpuexit.text) *(.memexit.text)
> *(.exit.data) *(.cpuexit.data) *(.cpuexit.rodata) *(.memexit.d
On Wed, Jan 26, 2011 at 10:42:41AM -0500, Nicolas Pitre wrote:
> On Wed, 26 Jan 2011, Dave Martin wrote:
> > Alternatively, I wonder .alt.smp.init could make weak references
> > instead of normal references: then if the referenced section is
> > discarded, the reference will revert to 0 and the fix
On Wed, Jan 26, 2011 at 10:15:37AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [110126 01:00]:
> > On Fri, Jan 07, 2011 at 08:56:26AM -0800, Tony Lindgren wrote:
> > > > diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
> > > &
On Wed, Jan 26, 2011 at 10:12:16AM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux [110126 00:57]:
> > On Fri, Jan 07, 2011 at 08:56:26AM -0800, Tony Lindgren wrote:
> > > > diff --git a/arch/arm/mach-omap2/io.c b/arch/arm/mach-omap2/io.c
> > > &
On Thu, Jan 27, 2011 at 06:19:21PM +0530, Raghuveer Murthy wrote:
>> +r = request_irq(dss_irq,
>> +cpu_is_omap24xx()
>> +? dss_irq_handler_omap2
>> +: dss_irq_handler_omap3,
>
> it should be
>
> cpu_is_omap24xx()
> ? dss_irq_handle
On Thu, Jan 27, 2011 at 02:37:09PM +, Dave Martin wrote:
> On Wed, Jan 26, 2011 at 04:31:37PM -0500, Nicolas Pitre wrote:
> > Since discarded sections are by definition not used, we should at least
> > put them into the .init section so to discard them at run time. And
> > only the EXIT_TEXT
On Thu, Jan 27, 2011 at 06:14:56PM +, Catalin Marinas wrote:
> On 17 January 2011 19:24, Russell King - ARM Linux
> wrote:
> > Rather than turning off CPU domain switching when the build architecture
> > includes ARMv6K, thereby causing problems for ARMv6-supporting kerne
On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote:
> Does this mean that we could still configure a kernel to run on CPU_V6
> with domains disabled? The vectors page becomes read-only and setting
> the TLS would fail.
Yes it will, so that's not acceptable either.
> My point is that
On Fri, Jan 28, 2011 at 10:46:51AM +, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 09:46:06AM +, Catalin Marinas wrote:
> > > My point is that we may want SWP_EMULATE disable
On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 11:06 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 10:46:51AM +, Catalin Marinas wrote:
> > > On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
>
On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 11:06 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 10:46:51AM +, Catalin Marinas wrote:
> > > On Fri, 2011-01-28 at 09:59 +0000, Russell King - ARM Linux wrote:
>
On Fri, Jan 28, 2011 at 01:10:56PM +, Catalin Marinas wrote:
> On Fri, 2011-01-28 at 13:05 +0000, Russell King - ARM Linux wrote:
> > On Fri, Jan 28, 2011 at 12:25:18PM +, Catalin Marinas wrote:
> > > With your latest patches, do we use the TLS emulation on ARMv7 (
On Tue, Feb 01, 2011 at 10:12:38AM +0200, Ohad Ben-Cohen wrote:
> On Tue, Feb 1, 2011 at 9:40 AM, Andrew Morton
> wrote:
> > On Tue, 1 Feb 2011 09:36:22 +0200 Ohad Ben-Cohen wrote:
> >
> >> On Tue, Feb 1, 2011 at 8:38 AM, Andrew Morton
> >> wrote:
> >> >> I'll do a quick respin of the patches
On Fri, Feb 04, 2011 at 12:09:34AM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Dave Martin [mailto:dave.mar...@linaro.org]
> > Sent: Thursday, February 03, 2011 11:33 PM
> > To: linux-arm-ker...@lists.infradead.org
> > Cc: Dave Martin; Tony Lindgren; Santosh Shilimkar;
On Thu, Feb 03, 2011 at 05:22:07PM -0800, Tony Lindgren wrote:
> Allow machine specific init of the DEBUG_LL serial port. This is needed
> to debug kernels built with support for multiple machines compiled in
> without recompiling the kernel.
>
> As some SoCs need to use variables to store the por
On Tue, Jan 18, 2011 at 11:32:16PM +0100, Martin Hostettler wrote:
> +#include
Please use linux/gpio.h in future.
--
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
On Tue, Jan 25, 2011 at 11:53:35PM +0530, Santosh Shilimkar wrote:
> After fixing the 3rd version for base address break, I was able to
> use this patch and test it. Seems to work. SMC related stuff can
> be ignored because OMAP4 ES1.0 doesn't have functional PM hardware
> support.
I think I'd pre
On Thu, Dec 09, 2010 at 11:59:42AM +, Dave Martin wrote:
> Because the nwfpe support is unlikely to be used on new platforms
> and requires CONFIG_OABI_COMPAT, which is not generally used with
> ARMv7+, we shouldn't expect to build nwfpe support into a Thumb-2
> kernel.
>
> At present, nwfpe c
On Fri, Feb 04, 2011 at 04:16:07PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Friday, February 04, 2011 4:11 PM
> > To: Santosh Shilimkar
> > Cc: catalin.mari...@arm.c
On Fri, Feb 04, 2011 at 08:39:34AM +, Russell King - ARM Linux wrote:
> Can't we just hard-configure the virtual/physical address at build
> time and be done with it?
>
> I've given up with the current state of affairs which tries to use the
> platform ID to select th
On Thu, Feb 03, 2011 at 10:33:42PM -0500, Nicolas Pitre wrote:
> On Thu, 3 Feb 2011, Tony Lindgren wrote:
>
> > This way we can have the debug-macro.S be common for omap1 and omap2+
> > and get sensible error messages booting the wrong zImage with
> > CONFIG_AUTO_ZRELADDR selected. Note that this
On Thu, Feb 03, 2011 at 05:15:39PM -0800, Tony Lindgren wrote:
> * Tony Lindgren [110118 12:36]:
> > * Russell King - ARM Linux [110118 10:32]:
> > > A warning for OMAP.
> > >
> > > Your use of the __virt_to_phys() in assembly code for the debug stuff
> &
On Mon, Jan 17, 2011 at 03:37:34PM +0530, Santosh Shilimkar wrote:
> The I2C timeout issue I could reproduce on my ES1.0 board. It's ES1.0
> specific issue because I2C burst mode wasn't fuctional on it. Twl RTC
> driver uses I2C burst mode and hence it times out. Other TWL I2C
> module has no such
On Mon, Feb 07, 2011 at 03:21:44PM +0530, Santosh Shilimkar wrote:
> > -Original Message-
> > From: Russell King - ARM Linux [mailto:li...@arm.linux.org.uk]
> > Sent: Friday, February 04, 2011 5:01 PM
> > To: Santosh Shilimkar
> > Cc: catalin.mari...@arm.c
On Mon, Feb 07, 2011 at 03:51:04PM +0530, Santosh Shilimkar wrote:
> > > > +int scu_power_mode(void __iomem *scu_base, unsigned int mode)
> > > > +{
> > > > + unsigned int val;
> > > > + int cpu = smp_processor_id();
> > > > + int shift;
> > > shift is unused with this version now
On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
> For v6, wfi is architected as a defined MCR instruction, so
> use that definition.
>
> Doing a no-op instead of wfi() is probably bad, so for older
> processors than v6, wfi() is not defined. If needed, some CPU-
> specific wfi() will
On Tue, Feb 08, 2011 at 01:11:51PM +0100, Arnd Bergmann wrote:
> On Tuesday 08 February 2011, Russell King - ARM Linux wrote:
> > On Tue, Feb 08, 2011 at 11:01:25AM +, Dave Martin wrote:
> > > For v6, wfi is architected as a defined MCR instruction, so
> &g
On Tue, Feb 08, 2011 at 02:45:51PM +, Dave Martin wrote:
> If support for a v6K processor is included, we have no way to know
> from preprocessor definitions whether a plain v6 processor is also to
> be supported.
Yes we do. See the v6 patches I've recently posted to various mailing
lists.
T
On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
> But that doesn't work if you build a combined v5/v6/v7 kernel, because
> v5 supports neither form, right? I think to do that, it needs the
> same kind of abstraction that we have for a number of other things
> like cache management in
On Tue, Feb 08, 2011 at 04:17:58PM +0100, Arnd Bergmann wrote:
> On Tuesday 08 February 2011, Dave Martin wrote:
> > CFLAGS_cpu_specific_object.o+= -march=armv7-a
> >
> > Whether it's safe to do it depends on whether code from that file
> > could ever get run on other processors. I'm not
On Tue, Feb 08, 2011 at 10:06:20PM +0530, Santosh Shilimkar wrote:
> Have tested this series on OMAP4430 and OMAP3430.
> Don't know if it helps to push some of these patches to be part
> of rc cycles. At least the SMP specific fixes should get merged
> otherwise, builds like omap2plus_defconfig won
On Tue, Feb 08, 2011 at 05:47:18PM +0100, Arnd Bergmann wrote:
> On Tuesday 08 February 2011 17:25:16 Russell King - ARM Linux wrote:
> > On Tue, Feb 08, 2011 at 04:15:15PM +0100, Arnd Bergmann wrote:
> > > But that doesn't work if you build a combined v5/v6/v7 kernel, be
On Wed, Jan 26, 2011 at 05:25:35PM +, Dave P. Martin wrote:
> SMP_ON_UP fixups lead to vmlinux link errors if those sections are
> discarded at link-time. In particular this may happen for built-in
> __exit stuff.
>
> This patch modifies the vmlinux linker script to reduce the amount
> of dis
On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:
> * Santosh Shilimkar [110209 01:59]:
> > > From: Dave Martin [mailto:dave.mar...@linaro.org]
> > >
> > > You could also have a "v7+" unified kernel -- i.e., supporting
> > > OMAP3+4+SMP.
> > > This is what we currently do in Linaro, s
On Wed, Feb 09, 2011 at 04:32:04PM +, Russell King - ARM Linux wrote:
> On Wed, Feb 09, 2011 at 08:24:21AM -0800, Tony Lindgren wrote:
> > * Santosh Shilimkar [110209 01:59]:
> > > > From: Dave Martin [mailto:dave.mar...@linaro.org]
> > > >
> > > &g
On Wed, Feb 09, 2011 at 02:22:11PM +, Russell King - ARM Linux wrote:
> On Wed, Jan 26, 2011 at 05:25:35PM +, Dave P. Martin wrote:
> > SMP_ON_UP fixups lead to vmlinux link errors if those sections are
> > discarded at link-time. In particular this may happen for buil
On Wed, Feb 09, 2011 at 10:01:33AM +, Catalin Marinas wrote:
> Could we make the domains usage a run-time feature based on the
> architecture version? For ARMv7, we need to have the vectors page
> read-only anyway if the SWP emulation is enabled (and I posted a
> simple patch in a reply to your
On Thu, Feb 10, 2011 at 01:12:35PM +, Catalin Marinas wrote:
> On Thu, 2011-02-10 at 13:04 +0000, Russell King - ARM Linux wrote:
> > On Wed, Feb 09, 2011 at 10:01:33AM +, Catalin Marinas wrote:
> > > Could we make the domains usage a run-time feature based on the
On Thu, Feb 10, 2011 at 02:13:13PM +, Dave Martin wrote:
> On Thu, Feb 10, 2011 at 2:11 PM, Dave Martin wrote:
> > Hi, apologies-- didn't see my mail for a bit.
> >
> > I get the problem with this tree and config (which builds with
> > SMP_ON_UP and THUMB2_KERNEL for omap3/4):
> >
> > Tree: gi
On Thu, Feb 10, 2011 at 08:19:19PM +0530, Santosh Shilimkar wrote:
> This patch will need below update so that the smp_scu.h
> header can be included from assembly files. Will you
> fold this into your patch or you want me to
> send below as separate patch ?
Folded.
--
To unsubscribe from this lis
On Thu, Feb 10, 2011 at 06:29:41PM +, Dave Martin wrote:
> On Thu, Feb 10, 2011 at 2:46 PM, Russell King - ARM Linux
> wrote:
> > On Thu, Feb 10, 2011 at 02:13:13PM +, Dave Martin wrote:
> >> Note that this tree contains some extra patches (though I believe
> &
On Fri, Feb 11, 2011 at 09:33:56AM +, Dave Martin wrote:
> Agreed -- actually, I suspected we might need to support this. But I
> don't think solving this problem (= keeping the fixup implementation
> in memory and enhancing the module loader) solved the
> fixups-referencing-sections-discarded
601 - 700 of 2180 matches
Mail list logo
