On Tue, 15 Dec 2015, Russell King - ARM Linux wrote:
> On Tue, Dec 15, 2015 at 10:33:25AM +0100, Pali Rohár wrote:
> > So am I understand correctly that solution would be to hack
> > arch/arm/mm/mmu.c to not overwrite page at PHYS_OFFSET?
>
> That's completely unnecessary: there are enough
On Mon, 30 Nov 2015, Pali Rohár wrote:
> On Monday 30 November 2015 07:23:53 Tony Lindgren wrote:
> > * Pali Rohár <pali.ro...@gmail.com> [151129 16:16]:
> > > On Monday 30 November 2015 01:09:17 Nicolas Pitre wrote:
> > > > On Sun, 29 Nov 2015, Russell King
On Sun, 29 Nov 2015, Russell King - ARM Linux wrote:
> On Sat, Nov 28, 2015 at 12:34:23PM -0500, Nicolas Pitre wrote:
> > Good. And Arnd likes the idea too. So we might be converging at last
> > which is a good thing.
>
> I disagree with the idea that there is conv
On Sat, 28 Nov 2015, Russell King - ARM Linux wrote:
> On Fri, Nov 27, 2015 at 06:28:50PM -0500, Nicolas Pitre wrote:
> > On Fri, 27 Nov 2015, Arnd Bergmann wrote:
> >
> > > I don't mind creating the /proc/atags compatibility hack from the kernel
> > > for a DT
On Fri, 27 Nov 2015, Arnd Bergmann wrote:
> I don't mind creating the /proc/atags compatibility hack from the kernel
> for a DT based N700 kernel, as long as we limit it as much as we can
> to the machines that need it. Leaving a board file for the N700 in place
> that contains the procfs code
do_div() is meant to be used with an unsigned dividend.
Signed-off-by: Nicolas Pitre <n...@linaro.org>
diff --git a/drivers/clk/ti/clkt_dpll.c b/drivers/clk/ti/clkt_dpll.c
index 9023ca9caf..b5cc6f66ae 100644
--- a/drivers/clk/ti/clkt_dpll.c
+++ b/drivers/clk/ti/clkt_dpll.c
@@ -240,7 +240,7
do_div() is meant to be used with an unsigned dividend.
Signed-off-by: Nicolas Pitre <n...@linaro.org>
diff --git a/drivers/clk/ti/fapll.c b/drivers/clk/ti/fapll.c
index f4b2e9888b..66a0d0ed8b 100644
--- a/drivers/clk/ti/fapll.c
+++ b/drivers/clk/ti/fapll.c
@@ -168,7 +168,7 @@ static un
On Mon, 2 Feb 2015, Pavel Machek wrote:
On Tue 2015-01-27 10:16:24, Nicolas Pitre wrote:
On Tue, 27 Jan 2015, Pavel Machek wrote:
I would say, problem is because omap3-n900 binary DT is too large
I agree.
OK if that's the case, then your patch makes sense to me
On Tue, 27 Jan 2015, Russell King - ARM Linux wrote:
On Tue, Jan 27, 2015 at 10:16:24AM -0500, Nicolas Pitre wrote:
On Tue, 27 Jan 2015, Pavel Machek wrote:
(Note, that in 3.19 dts for n900 got too big, so we are actually
triggering old bugs. That means that this is a regression fix
On Tue, 27 Jan 2015, Pavel Machek wrote:
I would say, problem is because omap3-n900 binary DT is too large
I agree.
OK if that's the case, then your patch makes sense to me. It also
seems we can have the temporary stack be larger than the initial
stack just for
On Mon, 26 Jan 2015, Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [150126 08:26]:
On Monday 26 January 2015 17:14:55 Tony Lindgren wrote:
* Pali Rohár pali.ro...@gmail.com [150123 14:39]:
On Friday 23 January 2015 22:39:55 Pali Rohár wrote:
Hello,
when I boot
On Mon, 26 Jan 2015, Pavel Machek wrote:
Hi!
$ du -b arch/arm/boot/dts/omap3-n900.dtb
70212 arch/arm/boot/dts/omap3-n900.dtb
$ echo $((0x1))
65536
I would say, problem is because omap3-n900 binary DT is too large
I agree.
OK if that's the case,
On Thu, 16 Oct 2014, Russell King - ARM Linux wrote:
So, let me put this another way: a compiler with this bug is _completely_
unsuitable for use for compiling programs for use under the Linux
kernel _as well_ as the Linux kernel itself.
The difference is that the Linaro compilers come with
On Tue, 1 Jul 2014, Will Deacon wrote:
Hi Mans,
On Tue, Jul 01, 2014 at 06:24:43PM +0100, Måns Rullgård wrote:
Russell King - ARM Linux li...@arm.linux.org.uk writes:
As you point out, bx lr /may/ be treated specially (I've actually been
Most, if not all, Cortex-A cores do this
On Wed, 25 Sep 2013, Rob Landley wrote:
On 09/24/2013 09:07:57 PM, Nicolas Pitre wrote:
I'd strongly suggest you make your binutils compatible with newer
instruction syntax instead of making the kernel more complex.
Meaning I play whack-a-mole as this becomes permission to depend
On Tue, 24 Sep 2013, Rob Landley wrote:
On 09/24/2013 04:48:00 PM, Russell King - ARM Linux wrote:
Now, if you feel strongly about this, we _could_ introduce a
CONFIG_OLD_BINUTILS and give everyone their cake - but it will be
fragile. Not everyone will remember to get that right, because
--
Any solution for this one ? omap2plus passes for me.
gcc version used is arm-poky-linux-gnueabi-gcc (GCC) 4.7.2 from poky
1.3.
That's due to:
commit e8f9bb1bd6bb93fff773345cc54c42585e0e3ece
Author: Nicolas Pitre nicolas.pi...@linaro.org
Date: Tue Jul 16 20:59:53 2013
Adding Kevin Hilman to the CC as he might be interested as well.
On Mon, 9 Sep 2013, Guenter Roeck wrote:
On Mon, Sep 09, 2013 at 09:31:41PM +0100, Russell King - ARM Linux wrote:
On Mon, Sep 09, 2013 at 09:03:48AM -0700, Guenter Roeck wrote:
Unfortunately, there are more problems.
On Tue, 30 Apr 2013, Dave Martin wrote:
On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
Latest nightly build of 3.9+my for-next+arm-soc's for-next results in a
great load of new warnings and errors.
On Tue, 30 Apr 2013, Dave Martin wrote:
On Tue, Apr 30, 2013 at 11:12:12AM -0400, Nicolas Pitre wrote:
On Tue, 30 Apr 2013, Dave Martin wrote:
On Tue, Apr 30, 2013 at 01:04:20PM +0200, Arnd Bergmann wrote:
On Tuesday 30 April 2013, Russell King - ARM Linux wrote:
Latest nightly
On Thu, 21 Feb 2013, Tom Rini wrote:
FIT isn't required. FIT is just trying to offer a nice usability
thing to folks.
Usability is often counter-balanced by maintenance costs.
A point of device trees is a single image works in a
lot of places. FIT gives you a single file works in a lot of
On Thu, 21 Feb 2013, Tom Rini wrote:
On 02/21/2013 12:25 PM, Nicolas Pitre wrote:
On Thu, 21 Feb 2013, Tom Rini wrote:
[snip]
uboot dug _itself_ into this hole. It's uboot's problem.
A whole lot of people dug this particular hole. Joel is trying
to offer up a solution that maybe
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 12:25:21PM -0500, Nicolas Pitre wrote:
So let's stop kidding ourselves and be coherent please: either we move
device specifics away from the kernel, or we keep them together. In
other words, the DT should ideally come
On Thu, 21 Feb 2013, Stephen Warren wrote:
On 02/21/2013 12:21 PM, Nicolas Pitre wrote:
DT installation must be outside of the distribution's responsibilities.
It should be the OEM's responsibility, just like BIOS updates for PCs
which don't come from Fedora/Debian/Ubuntu. Obviously
On Thu, 21 Feb 2013, Jason Gunthorpe wrote:
On Thu, Feb 21, 2013 at 02:57:46PM -0500, Nicolas Pitre wrote:
For embedded appliance product you may do as you wish. Nobody will
interfere in the way you develop and support your own products (as long
as you honor the applicable licenses
On Fri, 15 Feb 2013, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [130215 05:34]:
On Friday 15 February 2013 06:57 PM, Russell King - ARM Linux wrote:
On Fri, Feb 15, 2013 at 06:56:47PM +0530, Santosh Shilimkar wrote:
Whats your view on use of arch_ioremap_caller()
a...@arndb.de
Looks sensible.
Acked-by: Nicolas Pitre n...@linaro.org
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 3e3444e..8ff1d38 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -979,7 +979,6 @@ config ARCH_MULTI_V7
bool ARMv7 based platforms (Cortex-A, PJ4, Krait
On Wed, 30 Jan 2013, Ruslan Bilovol wrote:
Currently, reading /proc/cpuinfo provides userspace with CPU ID of
the CPU carrying out the read from the file.
Userspace using this information may decide what module
to load or how to configure some specific (and processor-depended)
settings or
On Wed, 30 Jan 2013, Matt Sealey wrote:
On Wed, Jan 30, 2013 at 1:07 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Wed, 30 Jan 2013, Ruslan Bilovol wrote:
Currently, reading /proc/cpuinfo provides userspace with CPU ID of
the CPU carrying out the read from the file.
Userspace using
On Wed, 30 Jan 2013, Russell King - ARM Linux wrote:
On Wed, Jan 30, 2013 at 02:07:53PM -0500, Nicolas Pitre wrote:
On Wed, 30 Jan 2013, Ruslan Bilovol wrote:
Currently, reading /proc/cpuinfo provides userspace with CPU ID of
the CPU carrying out the read from the file.
Userspace
)) -ne 1 ]; then \
+ echo 'multiple (or no) load addresses: $(UIMAGE_LOADADDR)'; \
echo 'This is incompatible with uImages'; \
echo 'Specify LOADADDR on the commandline to build an uImage'; \
false; \
Acked-by: Nicolas Pitre n...@linaro.org
Nicolas
--
To unsubscribe from
double word read with __get_user_xb() (Russell King's suggestion)
v3: explain in comment about why this works for narrowing fetch to 1,
2, or 4 byte type on ARM.
Signed-off-by: Rob Clark r...@ti.com
Acked-by: Nicolas Pitre n...@linaro.org
---
arch/arm/include/asm/uaccess.h | 22
On Sat, 6 Oct 2012, Marc Zyngier wrote:
Hi Tony,
On Fri, 5 Oct 2012 13:08:22 -0700, Tony Lindgren t...@atomide.com wrote:
Hi,
* Marc Zyngier marc.zyng...@arm.com [120907 10:04]:
From: Dave Martin dave.mar...@linaro.org
This patch does two things:
* Ensure that
if not entered in HYP mode.
Yes, with this it boots OK.
OK. In that case, I suggest this patch be sent to Russell to fix this
issue so he could push the ARM stuff to Linus ASAP.
Acked-by: Nicolas Pitre n...@linaro.org
Nicolas
--
To unsubscribe from this list: send the line unsubscribe linux
On Fri, 5 Oct 2012, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [121005 16:27]:
* Russell King - ARM Linux li...@arm.linux.org.uk [121005 16:10]:
On Fri, Oct 05, 2012 at 01:08:22PM -0700, Tony Lindgren wrote:
Just bisected this down in linux-next for breaking booting of
my
and
invalidates the D-cache up to LoUIS and invalidates the I-cache, according
to the new API.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Reviewed-by: Nicolas Pitre n...@linaro.org
---
arch/arm/include/asm/cacheflush.h
-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Acked-by: Nicolas Pitre n...@linaro.org
---
arch/arm/mm/cache-v7.S | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mm/cache-v7.S b/arch/arm/mm/cache-v7.S
index d1fa2f6..140b294 100644
--- a/arch
management remains unchanged.
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Reviewed-by: Nicolas Pitre n...@linaro.org
---
arch/arm/kernel/suspend.c | 17 -
1 file changed, 16 insertions(+), 1 deletion
Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Acked-by: Nicolas Pitre n...@linaro.org
---
arch/arm/kernel/smp.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index d3eb222
Shilimkar santosh.shilim...@ti.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Reviewed-by: Nicolas Pitre n...@linaro.org
---
arch/arm/mm/proc-v7.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index c2e2b66
On Mon, 3 Sep 2012, Mohammed, Afzal wrote:
Hi,
On Fri, Aug 31, 2012 at 23:53:32, Nicolas Pitre wrote:
On Fri, 31 Aug 2012, Hiremath, Vaibhav wrote:
On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote:
On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote
On Fri, 31 Aug 2012, Hiremath, Vaibhav wrote:
On Fri, Aug 31, 2012 at 22:43:36, Russell King - ARM Linux wrote:
On Fri, Aug 31, 2012 at 08:24:51PM +0530, Vaibhav Hiremath wrote:
Hi Russell Tony,
AM335X EVM (based on AM33XX device) only supports DT boot mode and
doesn't have
On Mon, 14 May 2012, Cousson, Benoit wrote:
Salut Thomas,
Sorry for the delay.
On 5/4/2012 5:59 PM, Thomas Petazzoni wrote:
Hello Benoit,
Le Fri, 23 Sep 2011 22:23:09 +0200,
Benoit Coussonb-cous...@ti.com a écrit :
Add SoC specific map_io function to be used by the generic
On Wed, 21 Mar 2012, Paul Walmsley wrote:
Hello Nico,
On Tue, 20 Mar 2012, Nicolas Pitre wrote:
This common clk API has been under development for over *two* years
already, with several attempts to merge it. And each previous merge
attempt aborted because someone came along
On Tue, 20 Mar 2012, Kevin Hilman wrote:
Looks like you never heard from anyone actively working on at91,
shmobile, kirwood or davinci.
I'm not sure we should merge those platform-specific changes without an
ack from those platform maintainers.
Depends. There is a limit to how long you
On Wed, 21 Mar 2012, Amit Kucheria wrote:
On Wed, Mar 21, 2012 at 12:48 AM, Kevin Hilman khil...@ti.com wrote:
Maybe it's time that drivers/cpuidle gets a maintainer. With lots of
discussions of scheduler changes that affect load estimation, I suspect
we're all going to have a bit of
On Tue, 20 Mar 2012, Paul Walmsley wrote:
We need to indicate in some way that the existing code and API is very
likely to change in ways that could involve quite a bit of work for
adopters.
[...]
Anyway. It is okay if we want to have some starter common clock framework
in mainline;
On Thu, 15 Mar 2012, Russell King - ARM Linux wrote:
I really don't like these behind-the-scenes discussions which never then
get followed up in public, and people then start quoting what was agreed
as that's the way things must be done.
It's a bit like folk at the recent Linaro Connect
On Tue, 31 Jan 2012, Catalin Marinas wrote:
Maybe we could factor out the CPU-specific settings from proc-v*.S
into a separate arch/arm/boot/preload directory. We keep proc-v*.S
entirely generic and the implementation-defined bits setting in the
preload code. You could have an option to link
On Tue, 31 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 31, 2012 at 3:26 PM, Russell King - ARM Linux
li...@arm.linux.org.uk wrote:
So, as many people have said, we're not going to go down the route of
allowing platforms to hook into this code. There's plenty of other
solutions to
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 5:27 PM, Catalin Marinas
catalin.mari...@arm.com wrote:
BTW, does the firmware make any checks on what bits it allows to be set?
Some of them may have security implications (and may not even be
documented).
Anyway,
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
How about allowing platform hooks for single SOC builds. I mean having
this code under !single_zImage or something like
On Tue, 17 Jan 2012, Nicolas Pitre wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
How about allowing platform hooks for single SOC builds. I mean having
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 9:45 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote:
On Tue, Jan 17, 2012 at 8:39 PM, Nicolas Pitre n...@fluxnic.net wrote:
On Tue, 17 Jan 2012, Shilimkar, Santosh wrote
On Thu, 12 Jan 2012, 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: OMAP4: Fix errata i688 with
On Thu, 12 Jan 2012, Nicolas Pitre wrote:
On Thu, 12 Jan 2012, Tony Lindgren wrote:
Commit 73829af71fdb8655e7ba4b5a2a6612ad34a75a11
(Merge branch 'vmalloc' of git://git.linaro.org/people/nico/linux
into devel-stable) merged generic ioremap changes.
Commit
On Thu, 6 Oct 2011, Tony Lindgren wrote:
* S, Venkatraman svenk...@ti.com [110825 07:23]:
On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com wrote:
Hi Venkat,
On 8/24/2011 9:46 PM, S, Venkatraman wrote:
As part of an effort to get single ARM kernel binary [1],
On Fri, 7 Oct 2011, Santosh Shilimkar wrote:
I have reviewed and tested this series. No problems seen.
As asked on other thread, if you are targeting this one for
3.2, then sram changes would have a small conflict with
OMAP4 errata patch. If it is for 3.3, we should be able to
sort out that
-by: Nicolas Pitre nicolas.pi...@linaro.org
---
arch/arm/mach-omap1/io.c |1 +
arch/arm/mach-omap2/io.c |1 +
arch/arm/plat-omap/include/plat/io.h |2 ++
arch/arm/plat-omap/io.c | 10 ++
4 files changed, 14 insertions(+), 0
On Fri, 7 Oct 2011, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111007 12:41]:
On Thu, 6 Oct 2011, Tony Lindgren wrote:
* S, Venkatraman svenk...@ti.com [110825 07:23]:
On Thu, Aug 25, 2011 at 5:19 PM, Cousson, Benoit b-cous...@ti.com
wrote:
Hi Venkat
On Fri, 7 Oct 2011, Tony Lindgren wrote:
* Santosh Shilimkar santosh.shilim...@ti.com [111006 23:22]:
The changes looks fine to me. Though the ugly hard-coding
is back with it, it's a step towards generic_io, so hopefully
it won't have to stay for long time.
Nico please correct me if
On Mon, 3 Oct 2011, Russell King - ARM Linux wrote:
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
On Tue, 4 Oct 2011, Santosh Shilimkar wrote:
On Tuesday 04 October 2011 04:08 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111003 14:36]:
On Mon, 3 Oct 2011, Tony Lindgren wrote:
Having the SRAM base address move around with different sizes also
requires the SoC detection
On Tue, 4 Oct 2011, Russell King - ARM Linux wrote:
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
On Tue, 4 Oct 2011, Tony Lindgren wrote:
In any case, I suggest we add the following __arm_ioremap_exec patch
and then sort out issues with it as they show up.
This allows further work on the common SRAM genalloc patches and generic
map_io patches.
Nico, I already have a series
-by: Tony Lindgren t...@atomide.com
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
As mentioned, you might consider dropping the export until needed.
---
arch/arm/include/asm/io.h |1 +
arch/arm/mm/ioremap.c | 22 ++
2 files changed, 23 insertions(+), 0 deletions
On Tue, 4 Oct 2011, Tony Lindgren wrote:
This allows us to remove omap hacks for map_io.
Signed-off-by: Tony Lindgren t...@atomide.com
Nice cleanup.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
---
arch/arm/mach-omap2/io.c | 19 +---
arch/arm/plat-omap/sram.c | 69
On Tue, 4 Oct 2011, Tony Lindgren wrote:
Otherwise we can't do generic map_io as we currently rely on
static mappings that work only because of arch_ioremap.
Signed-off-by: Tony Lindgren t...@atomide.com
That's great.
Acked-by: Nicolas Pitre nicolas.pi...@linaro.org
diff --git a/arch/arm
On Tue, 4 Oct 2011, Rob Herring wrote:
On 10/04/2011 04:21 PM, Nicolas Pitre wrote:
On Tue, 4 Oct 2011, Santosh Shilimkar wrote:
On Tuesday 04 October 2011 04:08 AM, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111003 14:36]:
On Mon, 3 Oct 2011, Tony Lindgren wrote
rant
I must state up front that I'm starting to share the frustration that
was publicly expressed by some other kernel maintainers on a few
occasions during the last year. I'm sorry that this frustration
build-up often ends up bursting out on the OMAP code, but the OMAP
kernel community is
On Mon, 3 Oct 2011, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111003 11:26]:
The problem is that those ioremap() calls are performed _*before*_ the
memory is fully set up yet, and also even before the corresponding
static mappings are even in place! So not only
On Mon, 3 Oct 2011, Nicolas Pitre wrote:
On Mon, 3 Oct 2011, Tony Lindgren wrote:
* Nicolas Pitre n...@fluxnic.net [111003 11:26]:
Furthermore... there is also a static mapping for physical address
0x4e00 using virtual address 0xff10 which is already reserved
for other
On Thu, 8 Sep 2011, Arnd Bergmann wrote:
On Tuesday 06 September 2011, Russell King - ARM Linux wrote:
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
On Fri, 2 Sep 2011, Kevin Hilman wrote:
Hi Tony,
Your testing-board branch currently has a couple new boards that are
missing the boot_params to atag_offset conversion (patch below.)
There's a patch below to fix this, but maybe it's better to just rebase
your testing-board branch onto
On Fri, 2 Sep 2011, Nicolas Pitre wrote:
On Fri, 2 Sep 2011, Kevin Hilman wrote:
Hi Tony,
Your testing-board branch currently has a couple new boards that are
missing the boot_params to atag_offset conversion (patch below.)
There's a patch below to fix this, but maybe it's better
On Wed, 31 Aug 2011, Will Deacon wrote:
On Wed, Aug 31, 2011 at 02:43:33PM +0100, Mark Salter wrote:
On Wed, 2011-08-31 at 09:49 +0100, Will Deacon wrote:
On Wed, Aug 31, 2011 at 01:23:47AM +0100, Chen Peter-B29397 wrote:
One question: why this write buffer issue did not happen at UP
On Wed, 15 Jun 2011, Ben Dooks wrote:
On Wed, Jun 01, 2011 at 05:19:26PM -0700, Kevin Hilman wrote:
Ben,
Please pull in this series from Andy Green for the next merge window.
v4 is simply a rebase of Andy's v3 against v3.0-rc1 with some basic
sanity testing against with the latest
acks ASAP. Thanks to Mark for pointing this out with a patch
for Samsung.
Acked-by: Nicolas Pitre n...@fluxnic.net
arch/arm/Kconfig |2 ++
arch/arm/plat-omap/Kconfig |1 +
2 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm
On Wed, 27 Apr 2011, Tony Lindgren wrote:
* Tony Lindgren t...@atomide.com [110427 05:44]:
We can't overwrite the running code when relocating only a small amount,
say 0x100 or so.
There's no need to relocate all the way past the compressed kernel,
we just need to relocate past the
).
Gh. Indeed.
Thanks to Aaro Koskinen aaro.koski...@nokia.com for debugging
the address of the relocated area that gets corrupted, and to
Nicolas Pitre nicolas.pi...@linaro.org for the other uncompress
related fixes.
Signed-off-by: Tony Lindgren t...@atomide.com
I think there could
On Thu, 21 Apr 2011, Tony Lindgren wrote:
* Nicolas Pitre nicolas.pi...@linaro.org [110421 20:20]:
I found the bugger. The problem was a bad stack alignment.
.. as this patch won't solve the n900 booting problem with zImage.
With LZMA I'm still also getting LZMA data is corrupt.
Hmmm
On Thu, 21 Apr 2011, Tony Lindgren wrote:
Otherwise we end up overwriting ourselves. This fixes booting
on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db
(ARM: 6750/1: improvements to compressed/head.S).
Signed-off-by: Tony Lindgren t...@atomide.com
I don't understand why this
On Thu, 21 Apr 2011, Nicolas Pitre wrote:
On Thu, 21 Apr 2011, Tony Lindgren wrote:
Otherwise we end up overwriting ourselves. This fixes booting
on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db
(ARM: 6750/1: improvements to compressed/head.S).
Signed-off-by: Tony
On Thu, 21 Apr 2011, Nicolas Pitre wrote:
On Thu, 21 Apr 2011, Nicolas Pitre wrote:
On Thu, 21 Apr 2011, Tony Lindgren wrote:
Otherwise we end up overwriting ourselves. This fixes booting
on n900 after commit 6d7d0ae51574943bf571d269da3243257a2d15db
(ARM: 6750/1: improvements
On Tue, 19 Apr 2011, Tony Lindgren wrote:
Aaro and I speculated that boards using u-boot with uImage work,
while n900 is using zImage and fails with the same kernel probably
because of the different placement of compressed image in the
memory.
Could you try the following (by changing the
On Wed, 13 Apr 2011, Tony Lindgren wrote:
* Nicolas Pitre nicolas.pi...@linaro.org [110402 05:40]:
On Thu, 31 Mar 2011, Aaro Koskinen wrote:
Hi,
On Wed, 30 Mar 2011, Kevin Hilman wrote:
Tony Lindgren t...@atomide.com writes:
FYI, looks like we've started hitting some
On Fri, 8 Apr 2011, Li Li wrote:
Dears,
I cannot understand how TLS EMU ensure it's SMP safe, because get_tls
helper (at 0x0fe0) just read the value from 0x0ff0. But all
SMP cores should have the exact same mapping to the vectors page (at
0x). So various threads running on
On Mon, 4 Apr 2011, Benjamin Herrenschmidt wrote:
On Fri, 2011-04-01 at 16:28 +0200, Detlef Vollmann wrote:
* No board files
Where do you put code that needs to run very early (e.g. pinging the
watchdog)?
Even on powerpc I keep board files :-)
The main thing is:
- The generic
On Fri, 1 Apr 2011, Arnd Bergmann wrote:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 16:59, Arnd Bergmann wrote:
On Friday 01 April 2011, Detlef Vollmann wrote:
On 04/01/11 15:54, Arnd Bergmann wrote:
9. All interesting work is going into a handful of platforms, all
On Fri, 1 Apr 2011, Arnd Bergmann wrote:
On Friday 01 April 2011, Will Deacon wrote:
1. The core arch code is not a problem (Russell does a great job here)
2. The platform specific code contains a lot of crap that doesn't belong
there
(not enough reviewers to push back on crap)
On Sat, 2 Apr 2011, Arnd Bergmann wrote:
On Friday 01 April 2011 21:54:47 Nicolas Pitre wrote:
I however don't think it is practical to go off in a separate
mach-nocrap space and do things in parallel. Taking OMAP as an example,
there is already way too big of an infrastructure in place
reverted -rc1 works:
commit d239b1dc093d551046a909920b5310c1d1e308c1
Author: Nicolas Pitre nicolas.pi...@linaro.org
Date: Mon Feb 21 04:57:38 2011 +0100
ARM: 6746/1: remove the 4x expansion presumption while decompressing
the kernel
With the revert, also bigger
On Wed, 30 Mar 2011, da...@lang.hm wrote:
On Wed, 30 Mar 2011, Nicolas Pitre wrote:
As long as SOC vendors keep producing wildly different architectures
besides the core CPU we'll have this problem. Denying the reality won't
make that problem go away either. And device tree won't stop
On Thu, 31 Mar 2011, Geert Uytterhoeven wrote:
On Thu, Mar 31, 2011 at 01:31, Nicolas Pitre n...@fluxnic.net wrote:
On ARM there is simply not such thing as a single machine design to
clone, and a closed source test bench to design for.
There are other architectures that didn't start from
On Thu, 31 Mar 2011, da...@lang.hm wrote:
I think that part of the issue is that when Linus points out a problem, the
response isn't we agree and are working on it, here's what we are doing,
instead it seems to be mostly there is no problem, this is just because there
is so much variation in
On Thu, 31 Mar 2011, Thomas Gleixner wrote:
Start off with such a trivial, but immense effective cleanup and see
what it helps to share code even accross SoC vendors. They all glue
together random IP blocks from the market and there are not soo many
sources which are relevant. This makes
On Thu, 31 Mar 2011, Linus Torvalds wrote:
What I'm _not_ seeing is a lot of cross-platform maintenance or sense
of people trying to reign things in and look for solutions to the
proliferation of random stupid and mindless platform code.
I do that, Russell does that, Catalin does that, Tony
On Thu, 31 Mar 2011, Linus Torvalds wrote:
On Thu, Mar 31, 2011 at 12:25 PM, Nicolas Pitre n...@fluxnic.net wrote:
So we need help! If core kernel people could get off their X86 stool
and get down in the ARM mud to help sort out this mess that would be
really nice (thanks tglx). Until
On Wed, 30 Mar 2011, Linus Torvalds wrote:
ARM right now i a nightmare, and most of it is because ARM hardware
manufacturers are morons.
If in your mind competitors == morons then you might be right.
But the way the ARM tree is then laid out
has made that even more painful, and the decision
On Wed, 30 Mar 2011, Linus Torvalds wrote:
On Wed, Mar 30, 2011 at 1:41 PM, Nicolas Pitre n...@fluxnic.net wrote:
If in your mind competitors == morons then you might be right.
There's a difference between competition and do things differently
just to be difficult.
Absolutely. We've
1 - 100 of 166 matches
Mail list logo
