* [PATCH v2 00/14] OMAP-GPMC related cleanup for common zImage
From: Tony Lindgren @ 2012-10-16 18:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010163840.GA13585@parrot.com>
* Ivan Djelic <ivan.djelic@parrot.com> [121010 09:40]:
>
> I ran several mtd regression tests on a Beagle Board on your gpmc-czimage-v2 tag.
> All BCH error correcting tests passed successfully.
>
> I occasionally had weird read errors though, especially when reading blank pages:
> the omap driver returned 512-byte sectors containing something like:
>
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff
> 30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ff30ffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>
> instead of:
>
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
> ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
>
> I was able to reproduce the problem also on l2-mtd tip, albeit less often.
> The problem seems to occur quite randomly, it may be a hardware issue on
> my board...
Things like this typically happen in the GPMC timings are not correct.
Maybe add #define DEBUG to top of gpmc.c and compare the timings
before and after Afzal's patches?
> Anyway, the ECC handling part looks OK to me.
Regards,
Tony
^ permalink raw reply
* [RFC PATCH] ARM: kernel: update cpuinfo to print all online CPUs features
From: Santosh Shilimkar @ 2012-10-16 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350404684-6883-1-git-send-email-lorenzo.pieralisi@arm.com>
On Tuesday 16 October 2012 09:54 PM, Lorenzo Pieralisi wrote:
> Currently, reading /proc/cpuinfo provides userspace with CPU ID of
> the CPU carrying out the read from the file. This is fine as long as all
> CPUs in the system are the same. With the advent of big.LITTLE and
> heterogenous ARM systems this approach provides user space with incorrect
> bits of information since CPU ids in the system might differ from the one
> provided by the CPU reading the file.
>
> This patch updates the cpuinfo show function and some internal data
> structures so that a read from /proc/cpuinfo prints HW information for
> all online CPUs at once, mirroring x86 behaviour.
>
> Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
> ---
>
> Posting it as a way to get advice on the best way to improve /proc/cpuinfo for
> heterogenous multi-cluster systems and to provide proper information to
> userspace without breaking existing semantics, no more than that.
>
> Comments more than welcome.
>
> Thanks,
> Lorenzo
>
> arch/arm/include/asm/cpu.h | 1 +
> arch/arm/kernel/setup.c | 66 +++++++++++++++++++++++-----------------------
> arch/arm/kernel/smp.c | 1 +
> 3 files changed, 35 insertions(+), 33 deletions(-)
>
[...]
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 8707cff..bf7839d08 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -1054,13 +1054,15 @@ static const char *hwcap_str[] = {
>
> static int c_show(struct seq_file *m, void *v)
> {
> - int i;
> + int i, j;
> + u32 cpuid;
>
> - seq_printf(m, "Processor\t: %s rev %d (%s)\n",
> - cpu_name, read_cpuid_id() & 15, elf_platform);
> + for_each_online_cpu(i) {
> + cpuid = is_smp() ? per_cpu(cpu_data, i).cpuid : read_cpuid_id();
> + seq_printf(m, "Processor\t: %s rev %d (%s)\n",
> + cpu_name, cpuid & 15, elf_platform);
>
Not exactly related to the $subject patch, but I remember doing a patch
to have cat /proc/cpuinfo spitting only online CPUs just like x86 using
for_each_online_cpu(i).
At that point Russell mentioned about a possibility of read() syscall
spreading over the hot-plug operation and hence the above may not
be safe.
is that right Russell ?
regards
Santosh
^ permalink raw reply
* [PATCH] ARM: OMAP2+: hwmod data: Fix wrong lostcontext_mask for OMAP4 l4_abe
From: Tony Lindgren @ 2012-10-16 17:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507D20F2.9060007@ti.com>
* Benoit Cousson <b-cousson@ti.com> [121016 01:56]:
> The following commit added the support for the lostcontext_mask
> along with the usage of the flag for l4_abe.
>
> commit ce80979aedfce937926a8dd40a1f92fd4bc2fd53
> Author: Tero Kristo <t-kristo@ti.com>
> Date: Sun Sep 23 17:28:19 2012 -0600
>
> ARM: OMAP4: hwmod data: add support for lostcontext_mask
>
> Unfortunately, the l4_abe does not contain this memory and thus
> cannot contain that flag.
>
> Remove the flag from the l4_abe hwmod.
>
> Change as well the mask for omap44xx_aess_hwmod to avoid missing
> the status in case LOSTMEM_AESSMEM is set. The AESS logic does
> not support retention and thus only the memory state is useful.
> It is even mandatory to avoid a crash in the case of the AESS
> resume.
>
> TBD: Ideally each hwmod should contain an extra entry for memory
> context attached to it. The AESS does contain only one, but some
> IP like the IVAHD does have three memories with dedicated status.
> The granularity is never used, but at least one global information
> for all the memory banks is useful.
>
> Signed-off-by: Benoit Cousson <b-cousson@ti.com>
> Cc: Tero Kristo <t-kristo@ti.com>
Thanks applying into omap-for-v3.7-rc1/fixes-part2.
Regards,
Tony
^ permalink raw reply
* [PATCH] OMAP4: devices: fixup OMAP4 DMIC platform device error message
From: Tony Lindgren @ 2012-10-16 17:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350401440-9620-1-git-send-email-s-guiriec@ti.com>
* Sebastien Guiriec <s-guiriec@ti.com> [121016 08:32]:
> Correct DMIC hwmod lockup error message and replace printk() by
> pr_err().
Thanks applying into omap-for-v3.7-rc1/fixes-part2.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: kexec: fix segment memory addresses check
From: Aaro Koskinen @ 2012-10-16 17:57 UTC (permalink / raw)
To: linux-arm-kernel
Commit c564df4db85aac8d1d65a56176a0a25f46138064 (ARM: 7540/1: kexec:
Check segment memory addresses) added a safety check with accidentally
reversed condition, and broke kexec functionality on ARM. Fix this.
Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
---
arch/arm/kernel/machine_kexec.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index e29c333..8ef8c93 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -45,10 +45,9 @@ int machine_kexec_prepare(struct kimage *image)
for (i = 0; i < image->nr_segments; i++) {
current_segment = &image->segment[i];
- err = memblock_is_region_memory(current_segment->mem,
- current_segment->memsz);
- if (err)
- return - EINVAL;
+ if (!memblock_is_region_memory(current_segment->mem,
+ current_segment->memsz))
+ return -EINVAL;
err = get_user(header, (__be32*)current_segment->buf);
if (err)
--
1.7.2.5
^ permalink raw reply related
* [PATCH 5/5] arm/dts: am33xx: Add cpsw and mdio module nodes for AM33XX
From: Tony Lindgren @ 2012-10-16 17:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b4d88ef79fb0dec95bb598aaf1f15f0a7344c435.1350327325.git.richardcochran@gmail.com>
* Richard Cochran <richardcochran@gmail.com> [121015 12:23]:
> From: Mugunthan V N <mugunthanvnm@ti.com>
>
> Add CPSW and MDIO related device tree data for AM33XX.
> Also enable them into board/evm dts files by providing
> respective phy-id.
These omap specific .dts changes should be queued by Benoit Cousson,
please cc him and linux-omap.
Regards,
Tony
^ permalink raw reply
* [PATCH 2/5] ARM: OMAP3+: hwmod: Add AM33XX HWMOD data for davinci_mdio
From: Tony Lindgren @ 2012-10-16 17:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <c048044c10b5712e25d190a0ae1dfee3155f81f7.1350327325.git.richardcochran@gmail.com>
* Richard Cochran <richardcochran@gmail.com> [121015 12:23]:
> From: Mugunthan V N <mugunthanvnm@ti.com>
>
> This patch adds minimal hwmod support for davinci mdio driver. This patch
> requires rework on parent child relation between cpsw and davinci mdio
> hwmod data to support runtime PM.
Looks like Paul Walmsley may have missed this one, maybe please resend
with him and linux-omap cc:d.
Regards,
Tony
^ permalink raw reply
* [PATCH 1/5] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Tony Lindgren @ 2012-10-16 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <41d66042625157d089e9c9532030a6831e79c641.1350327324.git.richardcochran@gmail.com>
* Richard Cochran <richardcochran@gmail.com> [121015 12:18]:
> From: hvaibhav at ti.com <hvaibhav@ti.com>
>
> With recent changes in omap gpmc driver code, in case of DT
> boot mode, where bootloader does not configure gpmc cs space
> will result into kernel BUG() inside gpmc_mem_init() function,
> as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
> gpmc_config7[0].baseaddress is set to '0' on reset.
>
> This use-case is applicable for any board/EVM which doesn't have
> any peripheral connected to gpmc cs0, for example BeagleXM and
> BeagleBone, so DT boot mode fails.
>
> This patch adds of_have_populated_dt() check before creating
> device, so that for DT boot mode, gpmc probe will not be called
> which is expected behavior, as gpmc is not supported yet from DT.
I'm applying this one into omap-for-v3.7-rc1/fixes-part2.
Next time, please also cc linux-omap at vger.kernel.org for series
like this. I'm sure the people reading the omap list are interested
in these.
Regards,
Tony
^ permalink raw reply
* [PATCH] ARM: OMAP2+: gpmc: Fix kernel BUG for DT boot mode
From: Tony Lindgren @ 2012-10-16 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121010143742.GE13724@beef>
* Matt Porter <mporter@ti.com> [121010 07:38]:
> On Wed, Oct 10, 2012 at 10:35:01AM -0400, Matt Porter wrote:
> > On Wed, Oct 10, 2012 at 02:19:40PM +0000, Vaibhav Hiremath wrote:
> > > On Wed, Oct 10, 2012 at 19:30:27, Porter, Matt wrote:
> > > > On Tue, Oct 09, 2012 at 02:27:20PM +0530, Vaibhav Hiremath wrote:
> > > > > With recent changes in omap gpmc driver code, in case of DT
> > > > > boot mode, where bootloader does not configure gpmc cs space
> > > > > will result into kernel BUG() inside gpmc_mem_init() function,
> > > > > as gpmc cs0 gpmc_config7[0].csvalid bit is set to '1' and
> > > > > gpmc_config7[0].baseaddress is set to '0' on reset.
> > > > >
> > > > > This use-case is applicable for any board/EVM which doesn't have
> > > > > any peripheral connected to gpmc cs0, for example BeagleXM and
> > > > > BeagleBone, so DT boot mode fails.
> > > > >
> > > > > This patch adds of_have_populated_dt() check before creating
> > > > > device, so that for DT boot mode, gpmc probe will not be called
> > > > > which is expected behavior, as gpmc is not supported yet from DT.
> > > > >
> > > > > Signed-off-by: Vaibhav Hiremath <hvaibhav@ti.com>
> > > > > Cc: Afzal Mohammed <afzal@ti.com>
> > > > > Cc: Tony Lindgren <tony@atomide.com>
> > > > > Cc Paul Walmsley <paul@pwsan.com>
> > > > > ---
> > > > > This should go in for rc1, as this breaks AM33xx boot.
> > > >
> > > > Fixes BeagleBone on mainline.
> > > >
> > > > Tested-by: Matt Porter <mporter@ti.com>
> > > >
> > >
> > > Thanks Matt and Afzal,
> > >
> > > Tony can this be picked up for rc1?? I know you have already sent pull
> > > request for rc1, but by any chance you are planning to send another request?
> >
> > I also found a separate problem with the mcasp clock data that's needed
> > for rc1. I just posted a patch for that as I need both this patch and the
> > clock data fix to boot from current mainline.
>
> Disregard now that you got me pointed to the pull request with this :)
Thanks applying $Subject patch into omap-for-v3.7-rc1/fixes-part2 and
ignoring the comments about the mcasp clock as it sounds like the mcasp
is already fixed.
Regards,
Tony
^ permalink raw reply
* [PATCH RFC 02/11 v4] gpio: Add sysfs support to block GPIO API
From: Greg KH @ 2012-10-16 17:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYaaSt9uLN2_=KXYDK2b5D5paopsYxgYKqezKCx8cy=vQ@mail.gmail.com>
On Tue, Oct 16, 2012 at 07:27:15PM +0200, Linus Walleij wrote:
> On Tue, Oct 16, 2012 at 6:43 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> > On Tue, Oct 16, 2012 at 02:53:45PM +0200, Roland Stigge wrote:
> >>
> >> Further, current gpio and gpiochip devices are also doing this way:
> >> creating the device and subsequently their attrs, even though there may
> >> be a better way but I'm still wondering how this would be.
> >
> > Then the existing code is broken and should be fixed to use dev_attrs.
> > I guess it's time to audit the tree and find all places that get this
> > wrong...
>
> The thing is, as I've tried to explain but maybe didn't get across,
> that these devices don't *have* a parent, and are not part of any
> tree.
You are passing in a parent device to the device_create() call, where
did that pointer come from?
Either way, the attribute creation needs to happen before we announce
the device to userspace, that's a bug that should be fixed now.
> They are parentless mock devices, created on-the-fly just to get
> sysfs entries.
That's fine, well, not the "parentless" part, but that should be trivial
to fix, just pass in the correct pointer and you should be fine.
> What is needed it to get the device model right in the first
> place.
I thought it was in the device model already?
> Fixing it has been drafted by me and Grant:
> https://blueprints.launchpad.net/linux-linaro/+spec/gpiochip-to-dev
>
> This is not all-encompassing though :-/
That's a good list to work from, good luck :)
greg k-h
^ permalink raw reply
* [PATCH] ARM: smp: switch away from the idmap before updating init_mm.mm_count
From: Will Deacon @ 2012-10-16 17:36 UTC (permalink / raw)
To: linux-arm-kernel
When booting a secondary CPU, the primary CPU hands two sets of page
tables via the secondary_data struct:
(1) swapper_pg_dir: a normal, cacheable, shared (if SMP) mapping
of the kernel image (i.e. the tables used by init_mm).
(2) idmap_pgd: an uncached mapping of the .idmap.text ELF
section.
The idmap is generally used when enabling and disabling the MMU, which
includes early CPU boot. In this case, the secondary CPU switches to
swapper as soon as it enters C code:
struct mm_struct *mm = &init_mm;
unsigned int cpu = smp_processor_id();
/*
* All kernel threads share the same mm context; grab a
* reference and switch to it.
*/
atomic_inc(&mm->mm_count);
current->active_mm = mm;
cpumask_set_cpu(cpu, mm_cpumask(mm));
cpu_switch_mm(mm->pgd, mm);
This causes a problem on ARMv7, where the identity mapping is treated as
strongly-ordered leading to architecturally UNPREDICTABLE behaviour of
exclusive accesses, such as those used by atomic_inc.
This patch re-orders the secondary_start_kernel function so that we
switch to swapper before performing any exclusive accesses.
Cc: David McKay <david.mckay@st.com>
Reported-by: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
---
The only potentially viable alternative to this patch that I can think
of is using swapper instead of idmap_pgd when VA == PA. However, that
has the unpleasant side-effect of making the identity mapping cacheable,
which I'm not comfortable with for things like CPU suspend.
Will
arch/arm/kernel/smp.c | 14 ++++++++++----
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 8e20754d..fbc8b26 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -294,18 +294,24 @@ static void percpu_timer_setup(void);
asmlinkage void __cpuinit secondary_start_kernel(void)
{
struct mm_struct *mm = &init_mm;
- unsigned int cpu = smp_processor_id();
+ unsigned int cpu;
+
+ /*
+ * The identity mapping is uncached (strongly ordered), so
+ * switch away from it before attempting any exclusive accesses.
+ */
+ cpu_switch_mm(mm->pgd, mm);
+ enter_lazy_tlb(mm, current);
+ local_flush_tlb_all();
/*
* All kernel threads share the same mm context; grab a
* reference and switch to it.
*/
+ cpu = smp_processor_id();
atomic_inc(&mm->mm_count);
current->active_mm = mm;
cpumask_set_cpu(cpu, mm_cpumask(mm));
- cpu_switch_mm(mm->pgd, mm);
- enter_lazy_tlb(mm, current);
- local_flush_tlb_all();
printk("CPU%u: Booted secondary processor\n", cpu);
--
1.7.4.1
^ permalink raw reply related
* [PATCH 0/2] ARM: tegra: bring back tegra_timer clock
From: Stephen Warren @ 2012-10-16 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350382116-18024-1-git-send-email-sivaramn@nvidia.com>
On 10/16/2012 04:08 AM, Sivaram Nair wrote:
> This patchset fixes a bug introduced by commit
> 20f4665831cec65d6e5d33587bba28ffa536b91d by bringing back the
> tegra_timer clock. The above commit caused tegra_init_timer() failing
> to get the clk reference.
>
> The first patch renames the existing tegra_timer object to
> tegra_sys_timer and the second patch adds previously-removed tegra_timer
> clock object.
Thanks. The series applied to Tegra's for-3.7/fixes-for-rc2 branch.
Sorry for the regression.
^ permalink raw reply
* [PATCH RFC 02/11 v4] gpio: Add sysfs support to block GPIO API
From: Linus Walleij @ 2012-10-16 17:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016164326.GA4858@kroah.com>
On Tue, Oct 16, 2012 at 6:43 PM, Greg KH <gregkh@linuxfoundation.org> wrote:
> On Tue, Oct 16, 2012 at 02:53:45PM +0200, Roland Stigge wrote:
>>
>> Further, current gpio and gpiochip devices are also doing this way:
>> creating the device and subsequently their attrs, even though there may
>> be a better way but I'm still wondering how this would be.
>
> Then the existing code is broken and should be fixed to use dev_attrs.
> I guess it's time to audit the tree and find all places that get this
> wrong...
The thing is, as I've tried to explain but maybe didn't get across,
that these devices don't *have* a parent, and are not part of any
tree.
They are parentless mock devices, created on-the-fly just to get
sysfs entries.
What is needed it to get the device model right in the first
place.
Fixing it has been drafted by me and Grant:
https://blueprints.launchpad.net/linux-linaro/+spec/gpiochip-to-dev
This is not all-encompassing though :-/
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] Re: Hardcoded instruction causes certain features to fail on ARM platfrom due to endianness
From: Dave Martin @ 2012-10-16 17:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAKw8HL3shtbi0Kk-7ZWO9KhtBVU+Vj_Zunh52GDOGJTZSvt6Gg@mail.gmail.com>
On Wed, Oct 17, 2012 at 12:33:54AM +0800, Fei Yang wrote:
> 2012/10/16 Dave Martin <dave.martin@linaro.org>:
> > On Mon, Oct 15, 2012 at 11:33:08PM +0800, Fei Yang wrote:
> >> 2012/10/15 Mikael Pettersson <mikpe@it.uu.se>:
> >> > Yangfei (Felix) writes:
> >> > > Hi all,
> >> > >
> >> > > I found that hardcoded instruction in inline asm can cause certains certain features fail to work on ARM platform due to endianness.
> >> > > As an example, consider the following code snippet of platform_do_lowpower function from arch/arm/mach-realview/hotplug.c:
> >> > > / *
> >> > > * here's the WFI
> >> > > */
> >> > > asm(".word 0xe320f003\n"
> >> > > :
> >> > > :
> >> > > : "memory", "cc");
> >> > >
> >> > > The instruction generated from this inline asm will not work on big-endian ARM platform, such as ARM BE-8 format. Instead, an exception will be generated.
> >> > >
> >> > > Here the code should be:
> >> > > / *
> >> > > * here's the WFI
> >> > > */
> >> > > asm("WFI\n"
> >> > > :
> >> > > :
> >> > > : "memory", "cc");
> >> > >
> >> > > Seems the kernel doesn't support ARM BE-8 well. I don't know why this problem happens.
> >> > > Can anyone tell me who owns this part? I can prepare a patch then.
> >> > > Thanks.
> >> >
> >> > Questions regarding the ARM kernel should go to the linux-arm-kernel mailing list
> >> > (see the MAINTAINERS file), with an optional cc: to the regular LKML.
> >> >
> >> > BE-8 is, if I recall correctly, ARMv7's broken format where code and data have
> >> > different endianess. GAS supports an ".inst" directive which is like ".word"
> >> > except the data is assumed to be code. This matters for disassembly, and may
> >> > also be required for BE-8.
> >> >
> >> > That is, just s/.word/.inst/g above and report back if that works or not.
> >> > --
> >> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> > the body of a message to majordomo at vger.kernel.org
> >> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >> > Please read the FAQ at http://www.tux.org/lkml/
> >> >
> >> >
> >>
> >> Hi Mikael,
> >>
> >> Thanks for the reply. I modified the code as suggested and rebuilt the
> >> kernel, cpu-hotplug feature now works on big-endian(BE-8) ARM
> >> platform.
> >> Since the ARM core can be configured by system software to work in
> >> big-endian mode, it's necessary to fix this problem. And here is a
> >> small patch :
> >>
> >> diff -urN linux-3.6.2/arch/arm/mach-exynos/hotplug.c
> >> linux/arch/arm/mach-exynos/hotplug.c
> >> --- linux-3.6.2/arch/arm/mach-exynos/hotplug.c 2012-10-13
> >> 04:50:59.000000000 +0800
> >> +++ linux/arch/arm/mach-exynos/hotplug.c 2012-10-15 23:05:44.000000000 +0800
> >> @@ -72,7 +72,7 @@
> >> /*
> >> * here's the WFI
> >> */
> >> - asm(".word 0xe320f003\n"
> >> + asm(".inst 0xe320f003\n"
> >
> > The cleanest fix would simply be to build these files with appropriate
> > modified CFLAGS (-march=armv6k or -march=armv7-a), and use the proper
> > "wfi" mnemonic.
> >
> > Failing that, you could use the facilities in <asm/opcodes.h> to
> > declare a wrapper macro for injecting this opcode (see
> > <asm/opcodes-virt.h> for an example). However, putting custom
> > opcodes into the assembler should only be done if it's really
> > necessary. Nowadays, I think we can consider tools which don't
> > understand the WFI mnemonic to be obsolete, at least for platforms
> > which only build for v7 and above.
> >
> > The relevant board maintainers would need to sign off on such a
> > change, so we don't end up breaking their builds.
> >
> > If any of these boards needs to build for v6K, the custom opcode might
> > be worth it -- some people might just possibly be relying on older tools
> > for such platforms.
> >
> > Cheers
> > ---Dave
> >
> >> :
> >> :
> >> : "memory", "cc");
> >> diff -urN linux-3.6.2/arch/arm/mach-realview/hotplug.c
> >> linux/arch/arm/mach-realview/hotplug.c
> >> --- linux-3.6.2/arch/arm/mach-realview/hotplug.c 2012-10-13
> >> 04:50:59.000000000 +0800
> >> +++ linux/arch/arm/mach-realview/hotplug.c 2012-10-15 23:05:00.000000000 +0800
> >> @@ -66,7 +66,7 @@
> >> /*
> >> * here's the WFI
> >> */
> >> - asm(".word 0xe320f003\n"
> >> + asm(".inst 0xe320f003\n"
> >> :
> >> :
> >> : "memory", "cc");
> >> diff -urN linux-3.6.2/arch/arm/mach-shmobile/hotplug.c
> >> linux/arch/arm/mach-shmobile/hotplug.c
> >> --- linux-3.6.2/arch/arm/mach-shmobile/hotplug.c 2012-10-13
> >> 04:50:59.000000000 +0800
> >> +++ linux/arch/arm/mach-shmobile/hotplug.c 2012-10-15 23:05:25.000000000 +0800
> >> @@ -53,7 +53,7 @@
> >> /*
> >> * here's the WFI
> >> */
> >> - asm(".word 0xe320f003\n"
> >> + asm(".inst 0xe320f003\n"
> >> :
> >> :
> >> : "memory", "cc");
> >>
> >> _______________________________________________
> >> linux-arm-kernel mailing list
> >> linux-arm-kernel at lists.infradead.org
> >> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
> Thanks for the suggestions. The ".inst" directive here may also bring
> us trouble if some older tools is used.
> In that situation, "wfi" mnemonic will not be recognized either. If we
> cannot suppose that newer tools is used, then how can we determine the
> endianness during the preprocessor/compile phase? Any ideas?
The endianness is controlled by the build-time configuration of the
kernel. A single kernel image cannot be bi-endian.
The __inst_*() macros in <asm/opcodes.h> take care of this based on which
CONFIG_CPU_ENDIAN_* option is selected by the board in the kernel config.
For compatibility with old tools, this is done instead of using the
".inst" directive.
> BTW: I found this bug on my ARM V7-A Cortex-A9 board and the processor
> is configured to work in big-endian mode at boot stage (word and
> halfword data is interpreted as big-endian, but instruction is still
> little-endian) . The kernel is ported from arch/arm/mach-realview. And
> I think these boards(mach-realview/mach-shmobile/mach-exynos) should
> have the similar problems. ARM arch is Bi-endian since versions 3 and
> above.
I believe that shmobile and exynos are v7-only, so it may be better to
just use "wfi" and override the CFLAGS for those files. As you can
see, those were just created by copy-pasting the code from mach-realview.
realview itself can be used with ARMv6 based core-tiles, so there may be
an argument for a custom opcode in this case:
#include <asm/opcodes.h>
#define __WFI __inst_arm_thumb16(0xE320F003, 0xBF30)
Not handling the Thumb case is a definite bug for any file which may
run on v7, since the kernel could be built in Thumb for that case.
For example, the existing code is mach-realview/hotplug.c is broken
when building an SMP Thumb-2 kernel for the Realview PBX-A9.
Cheers
---Dave
^ permalink raw reply
* [PATCH v3 0/6] OMAP: iommu: hwmod, reset handling and runtime PM
From: Tony Lindgren @ 2012-10-16 17:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350003977-32744-1-git-send-email-omar.luna@linaro.org>
* Omar Ramirez Luna <omar.luna@linaro.org> [121011 18:07]:
> These patches are needed for remoteproc to work on OMAP4.
>
> Introduced iommu hwmod support for OMAP3 (iva, isp) and
> OMAP4 (ipu, dsp), along with the corresponding runtime PM
> and routines to deassert reset lines, enable/disable clocks
> and configure sysc registers.
>
> Although IOMMU hwmod patches were already submitted in the past,
> this series adds few more changes, like:
> - New reset handling.
> - Save and restore context code rework.
> - Device tree bindings for OMAP3 and OMAP4.
>
> For this series I just dropped the patches already included in
> mainline.
These will need to be rebased on omap-for-v3.8/cleanup-headers-iommu
when I have that pushed out as that removes plat/*iommu*.h files.
Regards,
Tony
> Previous work can be found at:
> [v2]
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg75701.html
> [v1]
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg70447.html
>
> [old iteration without reset, save/restore and device tree]
> http://www.mail-archive.com/linux-omap at vger.kernel.org/msg60133.html
>
> Omar Ramirez Luna (6):
> ARM: OMAP3/4: iommu: migrate to hwmod framework
> ARM: OMAP3/4: iommu: adapt to runtime pm
> ARM: OMAP: iommu: pm runtime save and restore context
> ARM: OMAP: iommu: optimize save and restore routines
> ARM: OMAP: iommu: add device tree support
> arm/dts: OMAP3/4: Add iommu nodes
>
> .../devicetree/bindings/arm/omap/iommu.txt | 10 ++
> arch/arm/boot/dts/omap3.dtsi | 12 +-
> arch/arm/boot/dts/omap4.dtsi | 17 +-
> arch/arm/mach-omap2/devices.c | 2 +-
> arch/arm/mach-omap2/iommu2.c | 74 ++------
> arch/arm/mach-omap2/omap-iommu.c | 176 +++++---------------
> arch/arm/plat-omap/include/plat/iommu.h | 20 ++-
> arch/arm/plat-omap/include/plat/iommu2.h | 4 -
> drivers/iommu/omap-iommu.c | 163 ++++++++++++++----
> 9 files changed, 245 insertions(+), 233 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/omap/iommu.txt
>
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] ARM: kirkwood: fix buttons on lsxl boards
From: Michael Walle @ 2012-10-16 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348782877-857-1-git-send-email-michael@walle.cc>
Hi Andrew,
Can you pick this patch?
Am Donnerstag 27 September 2012, 23:54:37 schrieb Michael Walle:
> Change event type to switch for the power and autopower switches.
> Additionally, this patch aligns the keycodes with the other linkstation
> boards already supported by linux.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
> arch/arm/boot/dts/kirkwood-lsxl.dtsi | 8 +++++---
> 1 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> b/arch/arm/boot/dts/kirkwood-lsxl.dtsi index a1dd36d..8fea375 100644
> --- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> +++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> @@ -48,17 +48,19 @@
> #size-cells = <0>;
> button at 1 {
> label = "Function Button";
> - linux,code = <132>;
> + linux,code = <357>;
> gpios = <&gpio1 9 1>;
> };
> button at 2 {
> label = "Power-on Switch";
> - linux,code = <116>;
> + linux,code = <0>;
> + linux,input-type = <5>;
> gpios = <&gpio1 10 1>;
> };
> button at 3 {
> label = "Power-auto Switch";
> - linux,code = <142>;
> + linux,code = <1>;
> + linux,input-type = <5>;
> gpios = <&gpio1 11 1>;
> };
> };
--
Michael
^ permalink raw reply
* [PATCH] ARM: kirkwood: fix LEDs names for lsxl boards
From: Michael Walle @ 2012-10-16 17:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348519742-20126-1-git-send-email-michael@walle.cc>
Hi Andrew,
Can you pick this patch?
Am Montag 24 September 2012, 22:49:02 schrieb Michael Walle:
> Don't use the specific board name in a the common device tree include file.
> Instead use the common name 'lsxl'.
>
> Signed-off-by: Michael Walle <michael@walle.cc>
> ---
> arch/arm/boot/dts/kirkwood-lsxl.dtsi | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> b/arch/arm/boot/dts/kirkwood-lsxl.dtsi index 8ac51c0..a1dd36d 100644
> --- a/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> +++ b/arch/arm/boot/dts/kirkwood-lsxl.dtsi
> @@ -67,28 +67,28 @@
> compatible = "gpio-leds";
>
> led at 1 {
> - label = "lschlv2:blue:func";
> + label = "lsxl:blue:func";
> gpios = <&gpio1 4 1>;
> };
>
> led at 2 {
> - label = "lschlv2:red:alarm";
> + label = "lsxl:red:alarm";
> gpios = <&gpio1 5 1>;
> };
>
> led at 3 {
> - label = "lschlv2:amber:info";
> + label = "lsxl:amber:info";
> gpios = <&gpio1 6 1>;
> };
>
> led at 4 {
> - label = "lschlv2:blue:power";
> + label = "lsxl:blue:power";
> gpios = <&gpio1 7 1>;
> linux,default-trigger = "default-on";
> };
>
> led at 5 {
> - label = "lschlv2:red:func";
> + label = "lsxl:red:func";
> gpios = <&gpio1 16 1>;
> };
> };
--
michael
^ permalink raw reply
* [RESEND PATCH 2/2] ARM: kexec: Check segment memory addresses
From: Will Deacon @ 2012-10-16 17:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016170900.GB1613@blackmetal.musicnaut.iki.fi>
On Tue, Oct 16, 2012 at 06:09:00PM +0100, Aaro Koskinen wrote:
> On Tue, Oct 16, 2012 at 05:32:26PM +0100, Will Deacon wrote:
> > Interesting, it sounds like kexec thinks that you don't have contiguous
> > memory from 0x80008000 to 0x803ad000. Can you provide some more information
> > about your physical memory map please?
>
> Well, I think it's because the patch is wrong. Shouldn't it be:
>
> diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
> index e29c333..a80192e 100644
> --- a/arch/arm/kernel/machine_kexec.c
> +++ b/arch/arm/kernel/machine_kexec.c
> @@ -47,7 +47,7 @@ int machine_kexec_prepare(struct kimage *image)
>
> err = memblock_is_region_memory(current_segment->mem,
> current_segment->memsz);
> - if (err)
> + if (!err)
> return - EINVAL;
>
> err = get_user(header, (__be32*)current_segment->buf);
Oops, that's a howler! Thanks for spotting it. We should probably reflow the
code a bit because !err sounds like everything should be ok.
Fancy reworking the patch or do you want me to take care of this?
Cheers,
Will
^ permalink raw reply
* [PATCH V2 0/7] support the cpts found on am335x devices
From: Richard Cochran @ 2012-10-16 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <EB1619762EAF8B4E97A227FB77B7E0293E9F82F0@DBDE01.ent.ti.com>
On Tue, Oct 16, 2012 at 04:33:55PM +0000, N, Mugunthan V wrote:
> I had seen some issues with the patch series.
Please take another look. Excepting the last, none of your points
holds water.
> * CPTS will hold only LSB 32 bits of 64 bit Timer and the upper 32 bit
> time value has to be taken care by the software, but the time stamp
> which is passed to skb or PTP clock consist of only 32 bit time value
The driver handles this already.
> * CPTS interrupts should be utilized to service Half and Full roll over
> events as it is non sync events with respect to get/set time and PTP
> pkt Tx/Rx
Nope, no need for interrupts, since we already have a better way to
handle this.
> * CPTS Time which is obtained from hardware is not actually a nano
> seconds as the CPTS ref clock is tied to 250MHz for AM335x.
Did you even look at the code in my patch?
> * CPSW register mapping done in this patch series removes the CPSW
> driver support for previous version found in TI814x
In which Linux version (or commit) did this driver appear?
I never saw it.
> * CPSW Time stamping is done only for port 0 and port 1 is not done
Yes, you are right, and it is strange that the hardware time stamps on
the external ports of the switch, and not at the host port as it
should. Of course it does present us with a problem, since we cannot
reasonably have both ports time stamping at the same time. I propose
simply using a device tree attribute to tell which port to activate.
Thanks,
Richard
^ permalink raw reply
* [PATCH v3] ARM: vfp: fix save and restore when running on pre-VFPv3 and CONFIG_VFPv3 set
From: Jon Hunter @ 2012-10-16 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015175317.GE15569@atomide.com>
On 10/15/2012 12:53 PM, Tony Lindgren wrote:
> * Paul Walmsley <paul@pwsan.com> [121014 22:26]:
>>
>> After commit 846a136881b8f73c1f74250bf6acfaa309cab1f2 ("ARM: vfp: fix
>> saving d16-d31 vfp registers on v6+ kernels"), the OMAP 2430SDP board
>> started crashing during boot with omap2plus_defconfig:
>>
>> [ 3.875122] mmcblk0: mmc0:e624 SD04G 3.69 GiB
>> [ 3.915954] mmcblk0: p1
>> [ 4.086639] Internal error: Oops - undefined instruction: 0 [#1] SMP ARM
>> [ 4.093719] Modules linked in:
>> [ 4.096954] CPU: 0 Not tainted (3.6.0-02232-g759e00b #570)
>> [ 4.103149] PC is at vfp_reload_hw+0x1c/0x44
>> [ 4.107666] LR is at __und_usr_fault_32+0x0/0x8
>>
>> It turns out that the context save/restore fix unmasked a latent bug
>> in commit 5aaf254409f8d58229107b59507a8235b715a960 ("ARM: 6203/1: Make
>> VFPv3 usable on ARMv6"). When CONFIG_VFPv3 is set, but the kernel is
>> booted on a pre-VFPv3 core, the code attempts to save and restore the
>> d16-d31 VFP registers. These are only present on non-D16 VFPv3+, so
>> this results in an undefined instruction exception. The code didn't
>> crash before commit 846a136 because the save and restore code was
>> only touching d0-d15, present on all VFP.
>>
>> Fix by implementing a request from Russell King to add a new HWCAP
>> flag that affirmatively indicates the presence of the d16-d31
>> registers:
>>
>> http://marc.info/?l=linux-arm-kernel&m=135013547905283&w=2
>>
>> and some feedback from M?ns to clarify the name of the HWCAP flag.
>>
>> Signed-off-by: Paul Walmsley <paul@pwsan.com>
>> Cc: Tony Lindgren <tony@atomide.com>
>> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
>> Cc: Catalin Marinas <catalin.marinas@arm.com>
>> Cc: Dave Martin <dave.martin@linaro.org>
>> Cc: M?ns Rullg?rd <mans.rullgard@linaro.org>
>
> This fixes the error above on my 2430sdp:
>
> Tested-by: Tony Lindgren <tony@atomide.com>
Fixes same error on 2420 H4.
Tested-by: Jon Hunter <jon-hunter@ti.com>
Cheers
Jon
^ permalink raw reply
* [RESEND PATCH 2/2] ARM: kexec: Check segment memory addresses
From: Aaro Koskinen @ 2012-10-16 17:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016163226.GG23979@mudshark.cambridge.arm.com>
On Tue, Oct 16, 2012 at 05:32:26PM +0100, Will Deacon wrote:
> On Tue, Oct 16, 2012 at 05:10:21PM +0100, Aaro Koskinen wrote:
> > On Thu, Sep 20, 2012 at 05:03:38PM +0100, Will Deacon wrote:
> > > From: Matthew Leach <matthew.leach@arm.com>
> > >
> > > Ensure that the memory regions that are set within the segments
> > > correspond to physical contiguous memory regions.
> >
> > This patch seems to break kexec for me in 3.7-rc1 (commit
> > c564df4db85aac8d1d65a56176a0a25f46138064, bisected).
> >
> > kexec -l fails with the following output:
> >
> > kexec_load failed: Invalid argument
> > entry = 0x80008000 flags = 280000
> > nr_segments = 2
> > segment[0].buf = 0xc48008
> > segment[0].bufsz = 230
> > segment[0].mem = 0x80001000
> > segment[0].memsz = 1000
> > segment[1].buf = 0xb6a9b008
> > segment[1].bufsz = 3a4668
> > segment[1].mem = 0x80008000
> > segment[1].memsz = 3a5000
> > Could not load the kexec kernel: n800-zImage
> >
> > The board is OMAP2420 / Nokia N800.
>
> Interesting, it sounds like kexec thinks that you don't have contiguous
> memory from 0x80008000 to 0x803ad000. Can you provide some more information
> about your physical memory map please?
Well, I think it's because the patch is wrong. Shouldn't it be:
diff --git a/arch/arm/kernel/machine_kexec.c b/arch/arm/kernel/machine_kexec.c
index e29c333..a80192e 100644
--- a/arch/arm/kernel/machine_kexec.c
+++ b/arch/arm/kernel/machine_kexec.c
@@ -47,7 +47,7 @@ int machine_kexec_prepare(struct kimage *image)
err = memblock_is_region_memory(current_segment->mem,
current_segment->memsz);
- if (err)
+ if (!err)
return - EINVAL;
err = get_user(header, (__be32*)current_segment->buf);
A.
^ permalink raw reply related
* [PATCH] ARM: dts: imx6q-arm2: move NANDF_CS pins out of 'hog'
From: Olof Johansson @ 2012-10-16 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121015133516.GC24393@S2101-09.ap.freescale.net>
On Mon, Oct 15, 2012 at 09:35:20PM +0800, Shawn Guo wrote:
> On Mon, Oct 15, 2012 at 08:45:48AM -0400, Huang Shijie wrote:
> > On Mon, Oct 15, 2012 at 4:48 AM, Shawn Guo <shawn.guo@linaro.org> wrote:
> > > Commit 9e3c0066 (ARM: dts: imx6q-arm2: add pinctrl for uart and enet)
> > > defines NANDF_CS pins as gpio in 'hog', assuming these two pins are
> > > always used by usdhc3 in gpio mode as card-detection and
> > > write-protection on ARM2 board. But it's not true. These pins are
> > > shared by usdhc3 and gpmi-nand. We should have the pins functional
> > > for gpmi-nand when usdhc3 is disabled.
> > >
> > > Move the pins out of 'hog', so that pins only work in gpio mode as CD
> > > and WP when usdhc3 is enabled, and otherwise they are available for
> > > gpmi-nand.
> > >
> > > Reported-by: Huang Shijie <b32955@freescale.com>
> > > Signed-off-by: Shawn Guo <shawn.guo@linaro.org>
> > > ---
> > > Huang,
> > >
> > > Please help test the patch to see if it fixes your problem, thanks.
> >
> > yes, this patch fixes the problem.
> > thanks a lot.
> >
> > Tested-by: Huang Shijie <shijie8@gmail.com>
> >
> Arnd, Olof,
>
> Can you please send it for later -rc, since it fixes a regression
> in -rc1?
Done, applied to fixes and will be sent up with the next batch for
3.7-rc2.
-Olof
^ permalink raw reply
* [RFC][PATCH v4? 0/7] Adaptive Body-Bias for OMAP
From: Mike Turquette @ 2012-10-16 17:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016163225.GQ15569@atomide.com>
Quoting Tony Lindgren (2012-10-16 09:32:25)
> * Mike Turquette <mturquette@ti.com> [121011 15:27]:
> > Quoting Nishanth Menon (2012-10-11 06:33:04)
> > > On 18:26-20121003, Mike Turquette wrote:
> > > > From: Mike Turquette <mturquette@linaro.org>
> > > [...]
> > > >
> > > > arch/arm/mach-omap2/Makefile | 8 +-
> > > > arch/arm/mach-omap2/abb.c | 322 +++++++++++++++++++++++++
> > > > arch/arm/mach-omap2/abb.h | 94 ++++++++
> > > [...]
> > > > arch/arm/plat-omap/include/plat/voltage.h | 1 +
> > > > 18 files changed, 699 insertions(+), 37 deletions(-)
> > > > create mode 100644 arch/arm/mach-omap2/abb.c
> > > > create mode 100644 arch/arm/mach-omap2/abb.h
> > > > create mode 100644 arch/arm/mach-omap2/abb36xx_data.c
> > > > create mode 100644 arch/arm/mach-omap2/abb44xx_data.c
> > >
> > > dumb question: with the request to move everything out of mach-omap2
> > > directory, do we still want to add more files into mach-omap2?
> > >
> >
> > Not a dumb question at all. I approached this problem by modeling it
> > after existing voltage layer code (in particular the vp and vc drivers).
> >
> > My hope is to get it merged as-is and then bundle the abb code up with
> > the vp/vc migration to drivers/* when that happens some day. People
> > using omap36xx and above need this code now, so it seems prudent to take
> > this approach today.
>
> This is needed, but makes moving the vc code to drivers a bit
> more complex.
>
> So we also need a plan to move this all to drivers in the follow
> up patches. And we need a maintainer for the code. Who is going to
> be doing all that?
>
Is there already somebody committed to moving vp/vc code out to drivers?
If so then I can take responsibility for moving the abb code and
coordinate with that person. If nobody has put the vp/vc migration onto
their todo list then that is a bigger question.
Regards,
Mike
> Regards,
>
> Tony
^ permalink raw reply
* [PATCH 7/7] ARM: tegra30: cpuidle: add LP2 driver for CPU0
From: Stephen Warren @ 2012-10-16 17:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016080634.GG3196@tbergstrom-lnx.Nvidia.com>
On 10/16/2012 02:06 AM, Peter De Schrijver wrote:
>>> Even though we have plan to use coupled cpuidle, I still prefer to go
>>> with the LP2 driver first. Then adding one more patch to support coupled
>>> cpuidle based on LP2 driver. This is good for history. And if there is
>>> any issue, it's more easy to roll back to the stable one.
>>
>> I don't think that implementing it one way and then changing to a
>> different way will benefit history at all. It'll make the history more
>> complicated. What exactly is the problem with just using coupled cpuidle
>> from the start? If we did merge this implementation now, then switch to
>> coupled cpuidle later, when do you think the switch would happen?
>
> Before we consider doing this, I think we should have some idea on how
> frequently we run into the situation where CPU0 is idle but a secondary
> core is not. Depending on that we can then decide how useful coupled cpuidle
> would be for us.
Would it not be 75% of the time where we have 1 of 4 CPUs active? At
least, that's assuming that all work is evenly distributed amongst CPUs,
and hence it's random which CPU is the last to go idle, but perhaps
that's not the case if CPU0 is somehow special workload-wise?
But yes, some stats gathered from real-world use-cases could well be
interesting.
^ permalink raw reply
* [PATCH 1/4] arm64: Select MODULES_USE_ELF_RELA
From: Will Deacon @ 2012-10-16 16:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350406000-30882-2-git-send-email-catalin.marinas@arm.com>
On Tue, Oct 16, 2012 at 05:46:37PM +0100, Catalin Marinas wrote:
> With commit 786d35d4 (make most arch asm/module.h files use
> asm-generic/module.h) arm64 needs to enable MODULES_USE_ELF_RELA for
> loadable modules.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
> ---
> arch/arm64/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7ff68c9..ef54a59 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -22,6 +22,7 @@ config ARM64
> select HAVE_PERF_EVENTS
> select HAVE_SPARSE_IRQ
> select IRQ_DOMAIN
> + select MODULES_USE_ELF_RELA
> select NO_BOOTMEM
> select OF
> select OF_EARLY_FLATTREE
Acked-by: Will Deacon <will.deacon@arm.com>
Will
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox