On Fri, Dec 11, 2015 at 10:50:02PM +0100, Arnd Bergmann wrote:
> On Friday 11 December 2015 12:10:29 Nicolas Pitre wrote:
> > On Fri, 11 Dec 2015, Arnd Bergmann wrote:
> > > #ifdef CONFIG_CPU_PJ4B
> > > .type __v7_pj4b_proc_info, #object
> > > __v7_pj4b_proc_info:
> > > .long 0x
On Fri, Dec 11, 2015 at 01:51:15PM -0500, Steven Rostedt wrote:
> On Fri, 11 Dec 2015 18:33:27 +
> Russell King - ARM Linux wrote:
>
> > On Fri, Dec 11, 2015 at 01:10:29PM -0500, Steven Rostedt wrote:
> > > I ran it through most my tests (it's still running a
On Fri, Dec 11, 2015 at 01:10:29PM -0500, Steven Rostedt wrote:
> I ran it through most my tests (it's still running and is at 20 of 33
> tests). If there was anything wrong with this patch, I'm sure one of my
> tests would have crashed by now.
Thanks for testing.
> Do you want to take it, or sha
On Fri, Dec 11, 2015 at 09:31:25AM -0500, Steven Rostedt wrote:
> On Fri, 11 Dec 2015 12:09:03 +
> Russell King wrote:
>
> > recordmcount edits the file in-place, which can cause problems when
> > using ccache in hardlink mode. Arrange for recordmcount to break a
> > hardlinked object.
> >
On Wed, Dec 09, 2015 at 10:10:05AM +0530, Pratyush Anand wrote:
> On Tue, Dec 8, 2015 at 2:31 PM, Stanimir Varbanov
> wrote:
> >
> > On 12/03/2015 03:35 PM, Stanimir Varbanov wrote:
> > > Add 'write memory' barrier after enable region in PCIE_ATU_CR2
> > > register. The barrier is needed to ensure
On Tue, Dec 01, 2015 at 06:16:43PM +, Russell King - ARM Linux wrote:
> On Tue, Dec 01, 2015 at 12:22:12PM -0500, Steven Rostedt wrote:
> > I guess another solution is to do a copy instead of modifying in place
> > if it detects the multiple hard link?
>
> That woul
On Tue, Dec 01, 2015 at 12:22:12PM -0500, Steven Rostedt wrote:
> On Tue, 1 Dec 2015 17:10:14 +
> Russell King - ARM Linux wrote:
>
> > Another suggestion - maybe recordmcount, which fstat()s the file,
> > should check the st_nlink before modifying the file, and error o
On Tue, Dec 01, 2015 at 11:49:29AM -0500, Steven Rostedt wrote:
> On Tue, 1 Dec 2015 16:19:44 +
> Russell King - ARM Linux wrote:
>
> > They hardly "do nothing", as the (eg) recordmcount plasters the build
> > log with warnings. A solution to that would be
On Tue, Dec 01, 2015 at 05:07:05PM +0100, Michal Marek wrote:
> On 2015-11-30 16:40, Michal Marek wrote:
> > On 2015-11-30 16:32, Russell King - ARM Linux wrote:
> >> On Mon, Nov 30, 2015 at 04:11:16PM +0100, Michal Marek wrote:
> >>> On 2015-11-26 00:47, Russell Kin
On Mon, Nov 30, 2015 at 04:11:16PM +0100, Michal Marek wrote:
> On 2015-11-26 00:47, Russell King - ARM Linux wrote:
> > On Wed, Nov 25, 2015 at 01:51:03PM -0800, Stephen Boyd wrote:
> >> The ARM compiler inserts calls to __aeabi_uidiv() and
> >> __aeabi_idiv() when it n
On Thu, Nov 26, 2015 at 12:50:08AM +, Måns Rullgård wrote:
> If not calling the function saves an I-cache miss, the benefit can be
> substantial. No, I have no proof of this being a problem, but it's
> something that could happen.
That's a simplistic view of modern CPUs.
As I've already said
On Wed, Nov 25, 2015 at 01:51:04PM -0800, Stephen Boyd wrote:
> diff --git a/arch/arm/include/asm/cputype.h b/arch/arm/include/asm/cputype.h
> index 85e374f873ac..48c77d422a0d 100644
> --- a/arch/arm/include/asm/cputype.h
> +++ b/arch/arm/include/asm/cputype.h
> @@ -250,8 +250,14 @@ static inline i
On Wed, Nov 25, 2015 at 06:09:13PM -0500, Nicolas Pitre wrote:
> 3) In fact I was wondering if the overhead of the branch and back is
>really significant compared to the non trivial cost of a idiv
>instruction and all the complex infrastructure required to patch
>those branches direc
On Wed, Nov 25, 2015 at 01:51:03PM -0800, Stephen Boyd wrote:
> The ARM compiler inserts calls to __aeabi_uidiv() and
> __aeabi_idiv() when it needs to perform division on signed and
> unsigned integers. If a processor has support for the udiv and
> sdiv division instructions the calls to these sup
On Tue, Nov 24, 2015 at 12:07:30PM -0800, Stephen Boyd wrote:
> Ok. Presumably the order of arch-$(CONFIG) lines in the Makefile
> are done in an order to allow the build to degrade to the lowest
> common denominator among architecture support.
Correct. Make processes the directives in the order
On Tue, Nov 24, 2015 at 12:29:06PM +, Måns Rullgård wrote:
> Russell King - ARM Linux writes:
>
> > On Tue, Nov 24, 2015 at 12:10:02PM +, Måns Rullgård wrote:
> >> Russell King - ARM Linux writes:
> >>
> >> > On Tue, Nov 24, 2015 at 11:38:
On Tue, Nov 24, 2015 at 12:10:02PM +, Måns Rullgård wrote:
> Russell King - ARM Linux writes:
>
> > On Tue, Nov 24, 2015 at 11:38:53AM +0100, Arnd Bergmann wrote:
> >> I suggested using -mcpu=cortex-a15 because there are old gcc versions
> >> that don't
On Tue, Nov 24, 2015 at 11:38:53AM +0100, Arnd Bergmann wrote:
> I suggested using -mcpu=cortex-a15 because there are old gcc versions
> that don't know about -march=armv7ve or -march=armv7-a+idiv yet, but
> that do understand -mcpu=cortex-a15.
That's not all. The bigger problem is that there are
On Tue, Nov 24, 2015 at 12:53:49AM -0800, Stephen Boyd wrote:
> On 11/23, Stephen Boyd wrote:
> > On 11/23, Arnd Bergmann wrote:
> > >
> > > Ok, thanks for the confirmation.
> > >
> > > Summarizing what we've found, I think we can get away with just
> > > introducing two Kconfig symbols ARCH_MULT
On Mon, Nov 23, 2015 at 04:13:06PM -0800, Stephen Boyd wrote:
> On 11/23, Arnd Bergmann wrote:
> >
> > Ok, thanks for the confirmation.
> >
> > Summarizing what we've found, I think we can get away with just
> > introducing two Kconfig symbols ARCH_MULTI_V7VE and CPU_V7VE.
> > Most CPUs fall clea
On Mon, Nov 23, 2015 at 01:16:01PM -0800, Stephen Boyd wrote:
> Thanks. I don't see the prints on my system even with this config
> on top of allyesconfig. Odd.
Hmm.
It could be because I use ccache in hardlink mode to avoid the disk
overhead of having two copies and having to duplicate the file
On Mon, Nov 23, 2015 at 12:53:35PM -0800, Stephen Boyd wrote:
> On 11/21, Russell King - ARM Linux wrote:
> > On Fri, Nov 20, 2015 at 05:23:16PM -0800, Stephen Boyd wrote:
> > > @@ -452,14 +631,14 @@ static char const *
> > > __has_rel_mcount(Elf_Shdr const *cons
On Mon, Nov 23, 2015 at 11:28:59AM +0200, Stanimir Varbanov wrote:
> Add 'write memory' barrier after enable region in PCIE_ATU_CR2
> register. The barrier is needed to ensure that the region enable
> request has been reached it's destination at time when we
> read/write to PCI configuration space.
On Sun, Nov 22, 2015 at 08:58:08PM +0100, Arnd Bergmann wrote:
> does it work with -mcpu=cortex-a15? I've tried crosstool as versions
> 2.23.52.20130913, 2.24.0.20141017 and 2.25.51.20150518, and they
> all seem to behave as expected, failing with -mcpu=cortex-a9 and
> marvell-pj4 but succeeding w
On Sun, Nov 22, 2015 at 08:25:27PM +0100, Arnd Bergmann wrote:
> The question is really about Marvell Dove, MMP and Armada 370,
> which are all based on PJ4 or PJ4B (CPU part : 0x581), so ARMv7-A
> and report idivt support but idiva.
Well, it's pretty hard to test when binutils blocks your ability
On Fri, Nov 20, 2015 at 05:23:16PM -0800, Stephen Boyd wrote:
> @@ -452,14 +631,14 @@ static char const *
> __has_rel_mcount(Elf_Shdr const *const relhdr, /* is SHT_REL or SHT_RELA */
>Elf_Shdr const *const shdr0,
>char const *const shstrtab,
> - char
On Mon, Nov 16, 2015 at 10:32:51AM +, yamada.masah...@socionext.com wrote:
> Hi Arnd,
>
>
> > On Monday 16 November 2015 12:06:10 Masahiro Yamada wrote:
> > > Many ARM sub-architectures use prompts followed by "if" conditional,
> > > but it is wrong.
> > >
> > > Please notice the difference
On Fri, Sep 11, 2015 at 04:01:16PM -0500, Andy Gross wrote:
> This patch adds stubs for the SCM functions exposed in the QCOM SCM API.
>
> Signed-off-by: Andy Gross
Looks much better, thanks.
Acked-by: Russell King
--
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
acco
Arnd, Kevin, Olof,
Please hold off on this until the comments I made on the patch in this
pull request, which was only posted 15 minutes prior to this pull
request, have been discussed.
Thanks.
On Fri, Sep 11, 2015 at 01:07:33PM -0500, Andy Gross wrote:
> The following changes since commit bc019
On Fri, Sep 11, 2015 at 12:50:56PM -0500, Andy Gross wrote:
> This patch adds stubs for the SCM functions exposed in the QCOM SCM API.
>
> Signed-off-by: Andy Gross
> ---
> drivers/firmware/Makefile |4 +++
> drivers/firmware/qcom_scm-64.c | 63
> +
On Mon, Aug 24, 2015 at 02:12:06PM -0700, Olof Johansson wrote:
> Easiest of all would probably be to get the sub-arch patches into one
> release, then switch the prototypes and function definitions in the
> next. If you switch prototypes first you'll get a bunch of warnings,
> right?
Wrong way ar
On Thu, Aug 20, 2015 at 12:20:10PM -0500, Andy Gross wrote:
> On Thu, Aug 20, 2015 at 02:00:06PM +0100, Russell King - ARM Linux wrote:
> > On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote:
> > > RAM starts at 0x4000 for IPQ. The lower 21MB of RAM is use
On Thu, Aug 20, 2015 at 05:45:41PM +0530, Varadarajan Narayanan wrote:
> RAM starts at 0x4000 for IPQ. The lower 21MB of RAM is used
> for Shared Memory and the kernel can start from 0x4150.
Why do people keep creating crap like this? Each time something like
this is created, it means tha
On Mon, Jun 15, 2015 at 08:33:25AM +0200, Uwe Kleine-König wrote:
> Hello,
> > + .arm
> > +ENTRY(cpu_resume_arm)
> > + THUMB(badrr9, 1f ) @ Kernel is entered in ARM.
> > + THUMB(bx r9 ) @ If this is a Thumb-2 kernel,
> > + THUMB(.thumb
On Mon, Jun 08, 2015 at 03:03:04PM -0700, Kevin Hilman wrote:
> Stephen Boyd writes:
> > I'm happy to see it be applied by arm-soc maintainers directly given
> > that Russell said "the patch looks good to me". The commit text needs a
> > slight reword here though, so I can resubmit the patches to
On Tue, Jun 02, 2015 at 12:12:57PM -0700, Stephen Boyd wrote:
> Some platforms always enter the kernel in the ARM state even if
> the kernel is compiled for THUMB2. Add a small wrapper on top of
> cpu_resume() that switches into THUMB2 state.
>
> This fixes a problem reported by Kevin Hilman on ne
On Tue, Jun 02, 2015 at 08:18:18AM +0200, Ard Biesheuvel wrote:
> On 1 June 2015 at 23:45, Russell King - ARM Linux
> wrote:
> > Please do this differently. The default should be (as we do with
> > the SMP secondary entry path) to assume that the firmware does the
> > rig
On Mon, Jun 01, 2015 at 01:22:00PM -0700, Stephen Boyd wrote:
> The standard boot protocol on ARM requires CPUs to be entered in
> the ARM state, unless they don't support the ARM instruction set
> (see Documentation/arm/Booting). On THUMB2 kernels, we assume
> the firmware can determine what state
On Mon, Mar 09, 2015 at 09:16:36AM -0600, Lina Iyer wrote:
> @@ -105,18 +109,46 @@ static int __init arm_idle_init(void)
> if (ret <= 0)
> return ret ? : -ENODEV;
>
> +
A bit better formatting would be nice - you don't need the extra blank
line here.
> + ret = cpuidle_re
On Thu, Jan 08, 2015 at 03:42:29PM +0530, Abhijit Ray Chaudhury wrote:
> Uncompressing Linux... done, booting the kernel.
> Booting Linux on physical CPU 0
> Linux version 3.6.0-uc0 (gcc version 4.7.1 (crosstool-NG 1.16.0) ) #7
> PREEMPT Tue Jan 6 12:29:13 IST 2015
> CPU: ARMv7 Processor [413fc09
On Fri, Dec 05, 2014 at 05:07:45PM +, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 12:05:06PM +, Will Deacon wrote:
> > Care to submit this as a proper patch? We should at least fix Peter's issue
> > before doing things like extending headers, which won't work for older
> > kernels anyw
On Wed, Nov 26, 2014 at 05:54:41PM -0800, Stephen Boyd wrote:
> On 11/17/2014 05:05 PM, Stephen Boyd wrote:
> >If the kernel is running in hypervisor mode or monitor mode we'll
> >print UK6_32 or UK10_32 if we call into __show_regs(). Let's
> >update these strings to indicate the new modes that did
On Wed, Oct 22, 2014 at 04:01:26PM -0700, Stephen Boyd wrote:
> Where did this end up? When we talked at Connect I think we settled on
> exploring a driver core specific API like dev_get_localbus_address()
> that calls of_get_localbus_address() for devices with an of_node and in
> the future it cou
On Fri, Sep 19, 2014 at 11:24:01AM -0700, Stephen Boyd wrote:
> Thank you for the warm welcome! I looked at the TRMs for ARM11 and ARM9.
> I can't find anywhere where VFPv2 is supported and these bits are set.
>
> Bits 22-16 of FPSID:
>
> ARM1136r1p5: 0x01
> ARM1136r1p3: 0x01
> ARM1176:
On Mon, Sep 29, 2014 at 03:21:58PM -0400, valdis.kletni...@vt.edu wrote:
> On Fri, 26 Sep 2014 10:40:54 +0800, "Wang, Yalin" said:
>
> > I am really confused,
> > I read this web:
> > http://www.arm.linux.org.uk/developer/patches/info.php
> > it said use diff -urN to generate patch like this:
> >
On Fri, Sep 19, 2014 at 11:00:02AM +0100, Catalin Marinas wrote:
> On Fri, Sep 19, 2014 at 08:09:47AM +0100, Wang, Yalin wrote:
> > this patch extend the start and end address of initrd to be page aligned,
> > so that we can free all memory including the un-page aligned head or tail
> > page of ini
On Thu, Sep 18, 2014 at 02:43:12PM -0700, Stephen Boyd wrote:
> From: Stepan Moskovchenko
>
> Certain ARM CPU implementations (e.g. Cortex-A15) may not raise a
> floating- point exception whenever deprecated short-vector VFP
> instructions are executed. Instead these instructions are treated
> as
On Thu, Sep 18, 2014 at 02:43:11PM -0700, Stephen Boyd wrote:
> diff --git a/arch/arm/include/asm/vfp.h b/arch/arm/include/asm/vfp.h
> index f4ab34fd4f72..76d3f6907cce 100644
> --- a/arch/arm/include/asm/vfp.h
> +++ b/arch/arm/include/asm/vfp.h
> @@ -21,7 +21,7 @@
> #define FPSID_FORMAT_MASK(0
It would be nice to be copied on these patches, as the VFP code is
entirely my creation... I'll review these patches shortly.
On Thu, Sep 18, 2014 at 02:43:09PM -0700, Stephen Boyd wrote:
> These changes allow us to support VFP correctly on Krait processors.
> They also fix short vector emulation
On Mon, Sep 15, 2014 at 07:07:20PM +0800, Wang, Yalin wrote:
> this patch extend the start and end address of initrd to be page aligned,
> so that we can free all memory including the un-page aligned head or tail
> page of initrd, if the start or end address of initrd are not page
> aligned, the pa
On Mon, Sep 15, 2014 at 06:22:12PM +0800, Wang, Yalin wrote:
> Oh, I see your meaning,
> Yeah , my initrd is a cpio image,
> And it can still work after apply this patch.
Okay, that's what I wanted to know. However, I believe your patch to
be incorrect. You delete the assignments to initrd_start
On Mon, Sep 15, 2014 at 05:59:27PM +0800, Wang, Yalin wrote:
> Hi
>
> Add more log:
> <4>[0.00] INITRD unalign phys address:0x0200+0x0022fb0e
> <4>[0.00] INITRD aligned phys address:0x0200+0x0023
> <4>[0.574868] free_initrd: free initrd 0xc200+0xc222fb0e
> <4>[
On Mon, Sep 15, 2014 at 05:07:53PM +0800, Wang, Yalin wrote:
> Hi
>
> I tested it on my phone,
> >From log:
> <4>[0.00] INITRD unalign phys address:0x0200+0x0022fb0e
> <4>[0.00] INITRD aligned phys address:0x0200+0x0023
>
> <4>[0.579474] free_initrd_mem: free pfn:8
On Mon, Sep 15, 2014 at 01:11:14PM +0800, Wang, Yalin wrote:
> this patch extend the start and end address of initrd to be page aligned,
> so that we can free all memory including the un-page aligned head or tail
> page of initrd, if the start or end address of initrd are not page
> aligned, the pa
On Wed, Aug 20, 2014 at 12:22:41PM -0700, Stephen Boyd wrote:
> @@ -605,7 +615,7 @@ static void gic_raise_softirq(const struct cpumask *mask,
> unsigned int irq)
> int cpu;
> unsigned long flags, map = 0;
>
> - raw_spin_lock_irqsave(&irq_controller_lock, flags);
> + sgi_map_l
On Sun, Aug 17, 2014 at 03:04:34PM -0400, Jason Cooper wrote:
> Quoting Nico:
>
> "Of course it would be good to clarify things wrt Russell's remark
> independently from this patch."
>
> I took 'independently' to mean "This patch is ok, *and* we need to
> address Russell's concerns in a follow-up
On Sun, Aug 17, 2014 at 01:32:36PM -0400, Jason Cooper wrote:
> Stephen,
>
> On Wed, Aug 13, 2014 at 06:57:18AM -0700, Stephen Boyd wrote:
> > Commit 1a6b69b6548c (ARM: gic: add CPU migration support,
> > 2012-04-12) introduced an acquisition of the irq_controller_lock
> > in gic_raise_softirq() w
On Wed, Aug 13, 2014 at 07:55:26AM -0700, Stephen Boyd wrote:
> On 08/13, Russell King - ARM Linux wrote:
> > On Wed, Aug 13, 2014 at 06:57:18AM -0700, Stephen Boyd wrote:
> > > Commit 1a6b69b6548c (ARM: gic: add CPU migration support,
> > > 2012-04-12) intro
On Wed, Aug 13, 2014 at 06:57:18AM -0700, Stephen Boyd wrote:
> Commit 1a6b69b6548c (ARM: gic: add CPU migration support,
> 2012-04-12) introduced an acquisition of the irq_controller_lock
> in gic_raise_softirq() which can lead to a spinlock recursion if
> the gic_arch_extn hooks call into the sch
On Tue, Aug 12, 2014 at 01:04:40PM +0100, Srinivas Kandagatla wrote:
> From: Srinivas Kandagatla
>
> This patch adds condition in mmci_validate_data to skip checking
> blocksize for SDIO card types. SDIO card type can issue blocksizes
> which are not exactly power of 2 so this check always fails,
On Fri, Jun 27, 2014 at 10:54:22AM -0500, Andy Gross wrote:
> On Fri, Jun 27, 2014 at 11:50:57AM +0100, Mark Brown wrote:
> > On Thu, Jun 26, 2014 at 04:06:21PM -0500, Andy Gross wrote:
> >
> > > + if (xfer->rx_buf) {
> > > + rx_dma = dma_map_single(controller->dev, xfer->rx_buf,
> > > +
On Fri, May 30, 2014 at 06:13:00PM +0100, srinivas.kandaga...@linaro.org wrote:
> From: Srinivas Kandagatla
>
> This patch converts the register bits in the header file to use BIT(()
> macro, which looks much neater.
>
> No functional changes done.
>
> Signed-off-by: Srinivas Kandagatla
This
On Fri, May 30, 2014 at 06:14:40PM +0100, srinivas.kandaga...@linaro.org wrote:
> @@ -1325,6 +1329,18 @@ static void mmci_set_ios(struct mmc_host *mmc, struct
> mmc_ios *ios)
> if (!ios->clock && variant->pwrreg_clkgate)
> pwr &= ~MCI_PWR_ON;
>
> + if ((host->variant->exp
On Tue, Apr 22, 2014 at 08:32:10PM +0200, Arnd Bergmann wrote:
> @@ -1943,6 +1953,7 @@ config DEPRECATED_PARAM_STRUCT
> # TEXT and BSS so we preserve their values in the config files.
> config ZBOOT_ROM_TEXT
> hex "Compressed ROM boot loader base address"
> + depends on BROKEN_MULTIPLAT
On Tue, Apr 22, 2014 at 01:55:16PM -0400, Nicolas Pitre wrote:
> We do not want people in general to have PLAT_PHYS_OFFSET defined and
> CONFIG_ARM_PATCH_PHYS_VIRT disabled. In fact a huge effort has been
> deployed to go the exact opposite way over the last few years.
>
> There are special case
On Tue, Apr 22, 2014 at 11:53:25AM -0600, Jason Gunthorpe wrote:
> On Tue, Apr 22, 2014 at 06:11:42PM +0100, Russell King - ARM Linux wrote:
>
> > Put another way, if your platform is part of the multi-platform kernel
> > then you are *excluded* from being able to use this.
On Tue, Apr 22, 2014 at 04:50:12PM +0200, Michal Simek wrote:
> On 04/17/2014 10:35 PM, Jason Gunthorpe wrote:
> > +/* If we have a known, fixed physical load address then set LOAD_OFFSET
> > + and generate an ELF that has the physical load address in the program
> > + headers. */
> > +#ifndef
On Tue, Apr 22, 2014 at 11:26:53AM +0100, Daniel Thompson wrote:
> On 18/04/14 05:34, Nicolas Pitre wrote:
> >> I'm not suggesting to break anything or changing existing platforms,
> >> > but how do we improve the Image format in a compatible way. If
> >> > bootloaders want to support booting Image
On Tue, Apr 22, 2014 at 10:53:07AM +0100, Daniel Thompson wrote:
> On 17/04/14 22:35, Russell King - ARM Linux wrote:
> > On Thu, Apr 17, 2014 at 04:18:45PM -0500, Rob Herring wrote:
> >> The problem here is more than just the TEXT_OFFSET changed. From what
> >> I'v
On Thu, Apr 17, 2014 at 09:53:23PM -0500, Rob Herring wrote:
> On Thu, Apr 17, 2014 at 4:35 PM, Russell King - ARM Linux
> wrote:
> > No. You simply can't eliminate any of the above - each one has been
> > negotiated through quite an amount of discussion with relevant pa
On Thu, Apr 17, 2014 at 04:18:45PM -0500, Rob Herring wrote:
> The problem here is more than just the TEXT_OFFSET changed. From what
> I've heard, there are some QC chips which need much more reserved RAM
> than the 2MB discussed here. Changing the TEXT_OFFSET is a hack that
> doesn't scale.
You m
On Thu, Apr 17, 2014 at 04:06:16PM -0400, Nicolas Pitre wrote:
> On Thu, 17 Apr 2014, Rob Herring wrote:
> > Better yet, we should adopt the arm64 Image header which has this and
> > other fields for arm Image files. We're going to have to deal with raw
> > Image (and Image.gz) in bootloaders for a
On Wed, Apr 16, 2014 at 10:36:11PM +0100, Peter Maydell wrote:
> On 16 April 2014 22:08, Christopher Covington wrote:
> > On 04/16/2014 03:14 PM, Nicolas Pitre wrote:
> >> But both QEMU and the boot-wrapper should deal with zImage. That's the
> >> only image format with documented load offset is g
On Wed, Apr 16, 2014 at 05:08:35PM -0400, Christopher Covington wrote:
> What I meant to ask about was variance from one kernel version and build to
> the next, given a single platform. Platform-to-platform variation can probably
> be abstracted where needed by the scripts controlling the external
On Tue, Feb 18, 2014 at 02:15:33PM -0800, Laura Abbott wrote:
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index b68c6b2..c3ae96c 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -1061,74 +1061,44 @@ phys_addr_t arm_lowmem_limit __initdata = 0;
> void __init sanity_check_m
On Wed, Mar 12, 2014 at 01:38:06PM +, Russell King - ARM Linux wrote:
> Try booting a machine with 2G of RAM with page offset set to 3GB and
> highmem enabled - it will fail as per the above.
BTW, simple way to test this on any ARM platform:
Build with PAGE_OFFSET=3GB and highmem e
On Wed, Mar 12, 2014 at 03:09:53PM +0200, Grygorii Strashko wrote:
> Hi Russell,
>
> On 03/12/2014 10:54 AM, Russell King - ARM Linux wrote:
>> On Tue, Feb 18, 2014 at 02:15:33PM -0800, Laura Abbott wrote:
>>> memblock is now fully integrated into the kernel and is the
On Tue, Feb 18, 2014 at 02:15:33PM -0800, Laura Abbott wrote:
> memblock is now fully integrated into the kernel and is the prefered
> method for tracking memory. Rather than reinvent the wheel with
> meminfo, migrate to using memblock directly instead of meminfo as
> an intermediate.
>
> Acked-by
Automated build testing of allmodconfig discovered this error in the
MSM DRM driver:
drivers/gpu/drm/msm/hdmi/hdmi.o:(.rodata+0x10): multiple definition of
`__mod_of_device_table'
drivers/gpu/drm/msm/adreno/a3xx_gpu.o:(.rodata+0x4dc): first defined here
It appears that this will happen whenever
On Tue, Feb 18, 2014 at 02:15:33PM -0800, Laura Abbott wrote:
> memblock is now fully integrated into the kernel and is the prefered
> method for tracking memory. Rather than reinvent the wheel with
> meminfo, migrate to using memblock directly instead of meminfo as
> an intermediate.
> #define N
On Tue, Jan 28, 2014 at 01:05:10PM +0100, Arnd Bergmann wrote:
> Ok, thanks for clearing up my mistake. However, the argument remains:
> the direction doesn't need to be in the DT DMA descriptor since it
> gets set by software anyway.
Yes - for full-duplex, it's implied, since you have one DMA req
On Tue, Jan 28, 2014 at 01:08:47PM +0100, Arnd Bergmann wrote:
> On a related note, should we try to remove the slave_id field from
> the slave config structure as well? I believe it is still used by
> the shmobile dma engine in non-DT mode, but that is inconsistent with
> how all the others work,
On Tue, Jan 28, 2014 at 10:16:53AM +0100, Arnd Bergmann wrote:
> On Tuesday 28 January 2014 10:05:35 Lars-Peter Clausen wrote:
> > Why does the direction needs to be specified in specifier? I see two
> > options, either the direction per is fixed in hardware. In that case the DMA
> > controller nod
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_suspend':
drivers/usb/phy/phy-msm-usb.c:1691:2: error: implicit declaration of function
'msm_otg_suspend'
drivers/usb/phy/phy-msm-usb.c: In function 'msm_otg_runtime_resume':
drivers/usb/phy/phy-msm-usb.c:1699:2: error: implicit declarati
On Thu, Oct 31, 2013 at 10:35:06AM -0700, Daniel Walker wrote:
> ARM and the sub-architectures is already confusing I don't think we need
> to start compounding the problem by allowing random whatever-you-want
> sub-directories from every sub-architecture.
Confusing?
I'm not sure about that. It'
On Mon, Oct 28, 2013 at 01:12:35PM -0500, Josh Cartwright wrote:
> From: Kenneth Heitke
>
> System Power Management Interface (SPMI) is a specification
> developed by the MIPI (Mobile Industry Process Interface) Alliance
> optimized for the real time control of Power Management ICs (PMIC).
>
> S
On Sun, Oct 27, 2013 at 10:34:52AM +, Russell King - ARM Linux wrote:
> On Thu, Oct 24, 2013 at 02:03:46PM +0100, Russell King - ARM Linux wrote:
> > On Wed, Jun 12, 2013 at 10:23:27AM -0700, Laura Abbott wrote:
> > > Hi,
> > >
> > > This is an RFC to allo
On Thu, Oct 24, 2013 at 02:03:46PM +0100, Russell King - ARM Linux wrote:
> On Wed, Jun 12, 2013 at 10:23:27AM -0700, Laura Abbott wrote:
> > Hi,
> >
> > This is an RFC to allow CONFIG_DEBUG_SET_MODULE_RONX to be used on ARM. The
> > current config description
On Fri, Oct 25, 2013 at 02:08:40PM +0100, Will Deacon wrote:
> Hi Laura,
>
> On Wed, Jun 12, 2013 at 06:23:29PM +0100, Laura Abbott wrote:
> > Other architectures define various set_memory functions to allow
> > attributes to be changed (e.g. set_memory_x, set_memory_rw, etc.)
> > Currently, these
On Wed, Jun 12, 2013 at 10:23:27AM -0700, Laura Abbott wrote:
> Hi,
>
> This is an RFC to allow CONFIG_DEBUG_SET_MODULE_RONX to be used on ARM. The
> current config description from x86 describes it best:
>
> This option helps catch unintended modifications to loadable
> kernel module
On Thu, Oct 03, 2013 at 10:54:07AM -0700, Olof Johansson wrote:
> It wouldn't be a huge deal to add something like arch/arm/syslib and
> give some of the system library-type code a home there -- stuff like
> resource allocation libraries, etc. I don't think we want to collect
> all the back-end dri
On Thu, Oct 03, 2013 at 10:09:14AM -0700, Greg Kroah-Hartman wrote:
> On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote:
> > I don't have a good answer though. If it wasn't for the arm64 fork,
> > locating these under arch/arm somewhere would really be the reasonable
> > answer, like w
On Thu, Oct 03, 2013 at 09:46:30AM -0700, Olof Johansson wrote:
> I don't have a good answer though. If it wasn't for the arm64 fork,
> locating these under arch/arm somewhere would really be the reasonable
> answer, like we used to do on powerpc. :(
Are you seriously suggesting going back to havi
On Wed, Jul 24, 2013 at 01:54:28PM -0700, Stephen Boyd wrote:
> One more step to allowing MSM to participate in the
> multi-platform defconfig.
>
> Signed-off-by: Stephen Boyd
> ---
> arch/arm/Kconfig.debug | 9 +++-
> .../mach/debug-macro.S => include/debug/msm.S}
On Tue, Jul 30, 2013 at 01:55:32PM -0700, David Brown wrote:
> On Wed, Jul 24, 2013 at 01:54:28PM -0700, Stephen Boyd wrote:
>> One more step to allowing MSM to participate in the
>> multi-platform defconfig.
>
> Full patch: https://patchwork.kernel.org/patch/2833034/
>
>> Signed-off-by: Stephen Bo
On Mon, Jul 22, 2013 at 11:58:47AM -0700, Stephen Boyd wrote:
> On 07/22/13 11:45, Stephen Boyd wrote:
> > Hmm. Is it too early to use hrtimers? Moving the hrtimer_start() into
> > sched_clock_register() also causes the same crash.
>
> Yes that seems to be the problem. The vexpress board is settin
On Fri, Jul 19, 2013 at 10:20:19AM -0400, Nicolas Pitre wrote:
> On Fri, 19 Jul 2013, Will Deacon wrote:
>
> > Looks good to me. The current scheme would be very fiddly to extend to
> > 64-bit values on 32-bit architectures without cheap atomic doubleword
> > accesses.
>
> You should have a look
On Wed, Jun 12, 2013 at 10:23:29AM -0700, Laura Abbott wrote:
> Other architectures define various set_memory functions to allow
> attributes to be changed (e.g. set_memory_x, set_memory_rw, etc.)
> Currently, these functions are missing on ARM. Define these in an
> appropriate manner for ARM.
Ple
On Mon, Jun 10, 2013 at 09:31:21PM +0530, anish singh wrote:
> On Mon, Jun 10, 2013 at 9:08 PM, Russell King - ARM Linux
> wrote:
>
> Least I can do is to say "Thanks".
> > On Mon, Jun 10, 2013 at 08:46:36PM +0530, anish singh wrote:
> >> Probably a triv
On Mon, Jun 10, 2013 at 08:46:36PM +0530, anish singh wrote:
> Probably a trivial question.I was wondering why this particular requirement
> exists in the first place.I looked into this commit 112f38a4a3 but couldn't
> gather the reason.
You're looking at a commit introducing an implementation. T
1 - 100 of 323 matches
Mail list logo
