Re: [PATCH] scripts: recordmcount: break hardlinks

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

Re: [PATCH] ARM: Runtime patch udiv/sdiv instructions into __aeabi_{u}idiv()

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

Re: [PATCH] scripts: recordmcount: break hardlinks

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 <li...@arm.linux.org.uk> wrote: > > > On Fri, Dec 11, 2015 at 01:10:29PM -0500, Steven Rostedt wrote: > > > I ran it through mos

Re: [PATCH v4 1/5] PCI: designware: add memory barrier after enabling region

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.

Re: [PATCH v2 1/2] scripts: Add a recorduidiv program

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

Re: [PATCH v2 1/2] scripts: Add a recorduidiv program

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 <li...@arm.linux.org.uk> wrote: > > > They hardly "do nothing", as the (eg) recordmcount plasters the build > > log with warnings.

Re: [PATCH v2 1/2] scripts: Add a recorduidiv program

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 <li...@arm.linux.org.uk> wrote: > > > Another suggestion - maybe recordmcount, which fstat()s the file, > > should check the st_nlink before mo

Re: [PATCH v2 1/2] scripts: Add a recorduidiv program

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

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

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

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

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

Re: [PATCH v2 1/2] scripts: Add a recorduidiv program

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

Re: [PATCH v2 2/2] ARM: Replace calls to __aeabi_{u}idiv with udiv/sdiv instructions

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

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

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

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

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

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

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

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

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

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

On Tue, Nov 24, 2015 at 12:10:02PM +, Måns Rullgård wrote: > Russell King - ARM Linux <li...@arm.linux.org.uk> 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

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

On Tue, Nov 24, 2015 at 12:29:06PM +, Måns Rullgård wrote: > Russell King - ARM Linux <li...@arm.linux.org.uk> writes: > > > On Tue, Nov 24, 2015 at 12:10:02PM +, Måns Rullgård wrote: > >> Russell King - ARM Linux <li...@arm.linux.org.uk> writes: > >

Re: [PATCH v3 2/6] PCI: designware: add memory barrier after enabling region

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

Re: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM

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 *c

Re: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM

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

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

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

Re: [RFC/PATCH 0/3] ARM: Use udiv/sdiv for __aeabi_{u}idiv library functions

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

Re: [RFC/PATCH 2/3] recordmcount: Record locations of __aeabi_{u}idiv() calls on ARM

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

Re: [PATCH] ARM: use "depends on" for SoC configs instead of "if" after prompt

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

Re: [Patch v2] firmware: qcom: scm: Add function stubs for ARM64

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

Re: [PATCH] firmware: qcom: scm: Add function stubs for ARM64

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 >

Re: [GIT PULL] qcom fixes for 4.3-rc1

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

Re: [PATCH 00/18] ARM: use const and __initconst for smp_operations

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

Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x

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 that

Re: [PATCH] ARM: Set proper TEXT_OFFSET for IPQ806x

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 used for Shared Memory

Re: [PATCH v2 1/2] ARM: Add cpu_resume_arm() for firmwares that resume in ARM state

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

Re: [PATCH] ARM: Enter CPU in ARM state for cpu_resume

On Tue, Jun 02, 2015 at 08:18:18AM +0200, Ard Biesheuvel wrote: On 1 June 2015 at 23:45, Russell King - ARM Linux li...@arm.linux.org.uk 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 right thing

Re: [PATCH v2 1/2] ARM: Add cpu_resume_arm() for firmwares that resume in ARM state

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

Re: [PATCH] ARM: Enter CPU in ARM state for cpu_resume

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 to

Re: [RFC PATCH v15 01/11] ARM: cpuidle: Register per cpuidle device

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 =

Re: Question regarding Linux Bringup in ARMA9 platform

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 [413fc090]

Re: [RFC v2] arm:extend the reserved mrmory for initrd to be page aligned

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 anyway.

Re: [PATCH] ARM: Update processor_modes for hyp and monitor mode

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 didn't

Re: [PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations

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:

Re: [PATCH resend] arm:extend the reserved memory for initrd to be page aligned

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: diff -Nru

Re: [PATCH resend] arm:extend the reserved memory for initrd to be page aligned

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 initrd,

Re: [PATCH 0/3] Krait VFP fixes

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

Re: [PATCH 2/3] ARM: vfp: fix VFPv3 hwcap detection on non-ARM vfp implementations

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(0x3

Re: [RFC] arm:extend the reserved mrmory for initrd to be page aligned

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 page

Re: [RFC] arm:extend the reserved mrmory for initrd to be page aligned

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:8192---8752

Re: [RFC] arm:extend the reserved mrmory for initrd to be page aligned

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

Re: [RFC v2] arm:extend the reserved mrmory for initrd to be page aligned

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 page

Re: [PATCH v5] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

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); +

Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

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() which can

Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

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 patch.

Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

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

Re: [PATCH v4] irqchip: gic: Allow gic_arch_extn hooks to call into scheduler

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) introduced an acquisition of the irq_controller_lock

Re: [PATCH RFC 3/5] mmc: mmci: relax blksz check for SDIO

On Tue, Aug 12, 2014 at 01:04:40PM +0100, Srinivas Kandagatla wrote: From: Srinivas Kandagatla srinivas.kandaga...@linaro.org 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

Re: [PATCH] spi: qup: Add DMA capabilities

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, +

Re: [PATCH v5 11/13] mmc: mmci: add explicit clk control

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

Re: [PATCH v5 02/13] mmc: mmci: convert register bits to use BIT() macro.

On Fri, May 30, 2014 at 06:13:00PM +0100, srinivas.kandaga...@linaro.org wrote: From: Srinivas Kandagatla srinivas.kandaga...@linaro.org 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:

Re: [Qemu-devel] Change of TEXT_OFFSET for multi_v7_defconfig

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

Re: [Qemu-devel] Change of TEXT_OFFSET for multi_v7_defconfig

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... unless you hack

Re: Change of TEXT_OFFSET for multi_v7_defconfig

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 cases

Re: [Qemu-devel] Change of TEXT_OFFSET for multi_v7_defconfig

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_MULTIPLATFORM

Re: Change of TEXT_OFFSET for multi_v7_defconfig

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

Re: Change of TEXT_OFFSET for multi_v7_defconfig

On Wed, Apr 16, 2014 at 10:36:11PM +0100, Peter Maydell wrote: On 16 April 2014 22:08, Christopher Covington c...@codeaurora.org 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

Re: [PATCHv4 2/2] arm: Get rid of meminfo

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:

Re: [PATCHv4 2/2] arm: Get rid of meminfo

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 prefered method for tracking memory

Re: [PATCHv4 2/2] arm: Get rid of meminfo

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

Build error: MSM DRM

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

Re: [PATCHv4 2/2] arm: Get rid of meminfo

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

Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding

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 node

Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding

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, and

Re: [Patch v3 2/2] dmaengine: qcom_bam_dma: Add device tree binding

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

Re: [PATCH 2/4] ARM: msm: Remove 7x00 support

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's

Re: [PATCH v3 02/10] spmi: Linux driver framework for SPMI

On Mon, Oct 28, 2013 at 01:12:35PM -0500, Josh Cartwright wrote: From: Kenneth Heitke khei...@codeaurora.org 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

Re: [RFC 2/3] arm: mm: Define set_memory_* functions for ARM

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

Re: [RFC 0/3] Allow CONFIG_DEBUG_SET_MODULE_RONX to be used on ARM

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 from x86 describes it best

Re: [RFC 0/3] Allow CONFIG_DEBUG_SET_MODULE_RONX to be used on ARM

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 allow CONFIG_DEBUG_SET_MODULE_RONX to be used on ARM

Re: [RFC 0/3] Allow CONFIG_DEBUG_SET_MODULE_RONX to be used on ARM

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's

Re: Use of drivers/platform and matching include?

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 having

Re: Use of drivers/platform and matching include?

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 we used

Re: Use of drivers/platform and matching include?

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

Re: [PATCH v2 3/9] ARM: msm: Move debug-macro.S to include/debug

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 Boyd

Re: [PATCH v2 3/9] ARM: msm: Move debug-macro.S to include/debug

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 sb...@codeaurora.org --- arch/arm/Kconfig.debug | 9 +++- .../mach/debug-macro.S =

Re: [PATCH v4 03/17] sched_clock: Use an hrtimer instead of timer

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 setting up

Re: [RFC 2/3] arm: mm: Define set_memory_* functions for ARM

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. Please

Re: [PATCHv2 4/6] sched_clock: Add support for 32 bit sched_clock

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. The

Re: [PATCHv2 4/6] sched_clock: Add support for 32 bit sched_clock

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 li...@arm.linux.org.uk wrote: Least I can do is to say Thanks. On Mon, Jun 10, 2013 at 08:46:36PM +0530, anish singh wrote: Probably a trivial question.I was wondering

Re: [PATCH 2/3] ARM: msm: Re-organize platsmp to make it extensible

On Mon, Jun 03, 2013 at 05:19:44PM -0700, Rohit Vaswani wrote: + sc1_base_ptr = of_iomap(dn, 0); + if (sc1_base_ptr) { + writel_relaxed(0, sc1_base_ptr + VDD_SC1_ARRAY_CLAMP_GFS_CTL); + writel_relaxed(0, sc1_base_ptr + SCSS_CPU1CORE_RESET); +

Re: [PATCHv2 4/6] sched_clock: Add support for 32 bit sched_clock

On Mon, Jun 03, 2013 at 06:51:59PM -0700, Stephen Boyd wrote: On 06/03/13 15:12, Russell King - ARM Linux wrote: If you have a 56-bit clock which ticks at a period of 1ns, then cd.rate = 1, and your sched_clock() values will be truncated to 56-bits. The scheduler always _requires_ 64-bits

Re: [PATCHv2 3/6] sched_clock: Make ARM's sched_clock generic for all architectures

On Tue, Jun 04, 2013 at 10:56:00AM -0700, John Stultz wrote: On 06/03/2013 12:50 PM, Stephen Boyd wrote: On 06/03/13 00:12, Baruch Siach wrote: Hi Stephen, On Sat, Jun 01, 2013 at 11:39:40PM -0700, Stephen Boyd wrote: {arch/arm/include/asm = include/linux}/sched_clock.h | 9 +++--

Re: [PATCHv2 4/6] sched_clock: Add support for 32 bit sched_clock

On Mon, Jun 03, 2013 at 02:11:59PM -0700, Stephen Boyd wrote: On 06/03/13 02:39, Russell King - ARM Linux wrote: On Sat, Jun 01, 2013 at 11:39:41PM -0700, Stephen Boyd wrote: +} + +void __init +setup_sched_clock_64(u64 (*read)(void), int bits, unsigned long rate) +{ + if (cd.rate

Re: [PATCH] ARM: avoid mis-detecting some V7 cores in the decompressor

On Thu, May 23, 2013 at 10:54:26AM -0700, Stephen Boyd wrote: On 05/15/13 12:38, Stephen Boyd wrote: On 05/08/13 14:47, Stephen Boyd wrote: From: Brian Swetland swetl...@google.com Currently v7 CPUs with an MIDR that has no bits set in the range [16:12] will be detected as old ARM CPUs

Re: [PATCHv2] arm: mm: Use phys_addr_t properly for ioremap functions

On Wed, May 15, 2013 at 04:15:39PM +0200, Arnd Bergmann wrote: On Tuesday 14 May 2013, Laura Abbott wrote: Several of the ioremap functions use unsigned long in places resulting in truncation if physical addresses greater than 4G are passed in. Change the types of the functions and the

Re: [PATCH] arm: mm: Use phys_addr_t properly for ioremap functions

On Thu, May 02, 2013 at 07:02:37PM +0100, Russell King - ARM Linux wrote: On Tue, Apr 23, 2013 at 04:51:38PM -0700, Laura Abbott wrote: - unsigned long last_addr; - unsigned long offset = phys_addr ~PAGE_MASK; + phys_addr_t last_addr; + phys_addr_t offset = phys_addr ~PAGE_MASK

Re: [PATCH 1/3] driver core: Add API to wait for deferred probe to complete during init

On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote: On Thu, May 09, 2013 at 12:50:46PM +0100, Grant Likely wrote: However, if a device that shuts down resources after init has completed and then cannot turn those resources back on when another driver requests them then it sounds

Re: [PATCH 1/3] driver core: Add API to wait for deferred probe to complete during init

On Thu, May 09, 2013 at 03:37:02PM +0100, Mark Brown wrote: On Thu, May 09, 2013 at 03:14:45PM +0100, Russell King - ARM Linux wrote: On Thu, May 09, 2013 at 02:50:17PM +0100, Mark Brown wrote: Even if the driver copes fine it can still be desirable to avoid the power down/up cycle

Re: [PATCH] arm: mm: Use phys_addr_t properly for ioremap functions

On Tue, Apr 23, 2013 at 04:51:38PM -0700, Laura Abbott wrote: - unsigned long last_addr; - unsigned long offset = phys_addr ~PAGE_MASK; + phys_addr_t last_addr; + phys_addr_t offset = phys_addr ~PAGE_MASK; BTW, this doesn't need to be phys_addr_t. An offset of a page is

Re: [RFC][PATCH] arm: highmem: Add support for flushing kmap_atomic mappings

On Fri, Apr 05, 2013 at 02:42:51PM -0700, Laura Abbott wrote: The highmem code provides kmap_flush_unused to ensure all kmap mappings are really removed if they are used. This code does not handle kmap_atomic mappings since they are managed separately. This prevents an issue for any code which

Re: [PATCH] ARM: sched_clock: Add more notrace to prevent recursion

On Wed, Apr 17, 2013 at 05:34:45PM -0700, Stephen Boyd wrote: On 03/26/13 10:35, Stephen Boyd wrote: On 03/21/13 10:49, Stephen Boyd wrote: On 03/14/13 17:08, Stephen Boyd wrote: cyc_to_sched_clock() is called by sched_clock() and cyc_to_ns() is called by cyc_to_sched_clock(). I suspect

Re: [PATCH] ARM: timer: Shutdown clock event device when stopping local timer

On Sat, Mar 30, 2013 at 05:57:38PM +0800, Ning Jiang wrote: 2013/3/30 Stephen Boyd sb...@codeaurora.org: On 03/29/13 02:24, ning.n.ji...@gmail.com wrote: From: Ning Jiang ning.n.ji...@gmail.com Currently there are two problems when we try to stop local timer. First, it calls set_mode

Re: [PATCH] ARM: vfp: fix fpsid register subarchitecture field mask width

On Tue, Feb 26, 2013 at 05:37:17PM -0800, Stephen Boyd wrote: On 02/25/13 12:02, Russell King - ARM Linux wrote: This can of worms is getting bigger. We have more problems with our handling of the different VFP versions, specifically the handling of the EX=0 DEX=0 case. VFP common

  1   2   3   >