* [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
* [PATCH v2 1/3] drivers: bus: ocp2scp: add pdata support
From: Tony Lindgren @ 2012-10-16 16:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1349675983-23803-2-git-send-email-kishon@ti.com>
* Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> ocp2scp was not having pdata support which makes *musb* fail for non-dt
> boot in OMAP platform. The pdata will have information about the devices
> that is connected to ocp2scp. ocp2scp driver will now make use of this
> information to create the devices that is attached to ocp2scp.
>
> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
This fixes the regression on my panda es for musb port:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* [PATCH v2 2/3] ARM: OMAP4: add _dev_attr_ to ocp2scp for representing usb_phy
From: Tony Lindgren @ 2012-10-16 16:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011004413.GW12552@atomide.com>
* Tony Lindgren <tony@atomide.com> [121010 17:46]:
> Hi,
>
> * Kishon Vijay Abraham I <kishon@ti.com> [121007 23:01]:
> > In order to reflect devices(usb_phy) attached to ocp2scp bus, ocp2scp
> > is assigned a device attribute to represent the attached devices.
> ...
>
> > --- a/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > +++ b/arch/arm/mach-omap2/omap_hwmod_44xx_data.c
> > @@ -21,6 +21,7 @@
> > #include <linux/io.h>
> > #include <linux/platform_data/gpio-omap.h>
> > #include <linux/power/smartreflex.h>
> > +#include <linux/platform_data/omap_ocp2scp.h>
> >
> > #include <plat/omap_hwmod.h>
> > #include <plat/i2c.h>
> > @@ -2681,6 +2682,32 @@ static struct omap_hwmod_class omap44xx_ocp2scp_hwmod_class = {
> > .sysc = &omap44xx_ocp2scp_sysc,
> > };
> >
> > +/* ocp2scp dev_attr */
> > +static struct resource omap44xx_usb_phy_and_pll_addrs[] = {
> > + {
> > + .name = "usb_phy",
> > + .start = 0x4a0ad080,
> > + .end = 0x4a0ae000,
> > + .flags = IORESOURCE_MEM,
> > + },
> > + {
> > + /* XXX: Remove this once control module driver is in place */
> > + .name = "ctrl_dev",
> > + .start = 0x4a002300,
> > + .end = 0x4a002303,
> > + .flags = IORESOURCE_MEM,
> > + },
> > + { }
> > +};
>
> Why don't you set the CONTROL_DEV_CONF as a fixed regulator?
After some more investigating, we may be able to set it up as a
regulator or clock later on. But as a regression fix, this seems
OK for me.
Benoit, is this OK for you?
Regards,
Tony
^ permalink raw reply
* [PATCH 4/4] arm64: No need to set the x0-x2 registers in start_thread()
From: Catalin Marinas @ 2012-10-16 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350406000-30882-1-git-send-email-catalin.marinas@arm.com>
For historical reasons, ARM used to set r0-r2 in start_thread() to the
first values on the user stack when starting a new user application. The
same logic has been inherited in AArch64. The x0 register is overridden
by the sys_execve() return value so it's always zero on success. The x1
and x2 registers are ignored by AArch64 and EABI AArch32 applications,
so we can safely remove the register setting for both native and compat
user space.
This also fixes a potential fault with the kernel accessing user space
stack directly.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
---
arch/arm64/include/asm/processor.h | 10 ----------
1 file changed, 10 deletions(-)
diff --git a/arch/arm64/include/asm/processor.h b/arch/arm64/include/asm/processor.h
index 39a208a..5d81004 100644
--- a/arch/arm64/include/asm/processor.h
+++ b/arch/arm64/include/asm/processor.h
@@ -92,30 +92,20 @@ static inline void start_thread_common(struct pt_regs *regs, unsigned long pc)
static inline void start_thread(struct pt_regs *regs, unsigned long pc,
unsigned long sp)
{
- unsigned long *stack = (unsigned long *)sp;
-
start_thread_common(regs, pc);
regs->pstate = PSR_MODE_EL0t;
regs->sp = sp;
- regs->regs[2] = stack[2]; /* x2 (envp) */
- regs->regs[1] = stack[1]; /* x1 (argv) */
- regs->regs[0] = stack[0]; /* x0 (argc) */
}
#ifdef CONFIG_COMPAT
static inline void compat_start_thread(struct pt_regs *regs, unsigned long pc,
unsigned long sp)
{
- unsigned int *stack = (unsigned int *)sp;
-
start_thread_common(regs, pc);
regs->pstate = COMPAT_PSR_MODE_USR;
if (pc & 1)
regs->pstate |= COMPAT_PSR_T_BIT;
regs->compat_sp = sp;
- regs->regs[2] = stack[2]; /* x2 (envp) */
- regs->regs[1] = stack[1]; /* x1 (argv) */
- regs->regs[0] = stack[0]; /* x0 (argc) */
}
#endif
^ permalink raw reply related
* [PATCH 3/4] arm64: Ignore memory blocks below PHYS_OFFSET
From: Catalin Marinas @ 2012-10-16 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350406000-30882-1-git-send-email-catalin.marinas@arm.com>
According to Documentation/arm64/booting.txt, the kernel image must be
loaded at a pre-defined offset from the start of RAM so that the kernel
can calculate PHYS_OFFSET based on this address. If the DT contains
memory blocks below this PHYS_OFFSET, report them and ignore the
corresponding memory range.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm64/kernel/setup.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 48ffb9f..7665a9b 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -170,7 +170,19 @@ static void __init setup_machine_fdt(phys_addr_t dt_phys)
void __init early_init_dt_add_memory_arch(u64 base, u64 size)
{
+ base &= PAGE_MASK;
size &= PAGE_MASK;
+ if (base + size < PHYS_OFFSET) {
+ pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
+ base, base + size);
+ return;
+ }
+ if (base < PHYS_OFFSET) {
+ pr_warning("Ignoring memory range 0x%llx - 0x%llx\n",
+ base, PHYS_OFFSET);
+ size -= PHYS_OFFSET - base;
+ base = PHYS_OFFSET;
+ }
memblock_add(base, size);
}
^ permalink raw reply related
* [PATCH 2/4] arm64: Fix the update_vsyscall() prototype
From: Catalin Marinas @ 2012-10-16 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350406000-30882-1-git-send-email-catalin.marinas@arm.com>
With commit 576094b7 (time: Introduce new GENERIC_TIME_VSYSCALL) the old
update_vsyscall() prototype is no longer available. This patch updates
the arm64 port.
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Will Deacon <will.deacon@arm.com>
Cc: John Stultz <john.stultz@linaro.org>
---
arch/arm64/kernel/vdso.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 17948fc..ba45794 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -28,6 +28,7 @@
#include <linux/sched.h>
#include <linux/signal.h>
#include <linux/slab.h>
+#include <linux/timekeeper_internal.h>
#include <linux/vmalloc.h>
#include <asm/cacheflush.h>
@@ -222,11 +223,10 @@ struct vm_area_struct *get_gate_vma(struct mm_struct *mm)
/*
* Update the vDSO data page to keep in sync with kernel timekeeping.
*/
-void update_vsyscall(struct timespec *ts, struct timespec *wtm,
- struct clocksource *clock, u32 mult)
+void update_vsyscall(struct timekeeper *tk)
{
struct timespec xtime_coarse;
- u32 use_syscall = strcmp(clock->name, "arch_sys_counter");
+ u32 use_syscall = strcmp(tk->clock->name, "arch_sys_counter");
++vdso_data->tb_seq_count;
smp_wmb();
@@ -237,13 +237,13 @@ void update_vsyscall(struct timespec *ts, struct timespec *wtm,
vdso_data->xtime_coarse_nsec = xtime_coarse.tv_nsec;
if (!use_syscall) {
- vdso_data->cs_cycle_last = clock->cycle_last;
- vdso_data->xtime_clock_sec = ts->tv_sec;
- vdso_data->xtime_clock_nsec = ts->tv_nsec;
- vdso_data->cs_mult = mult;
- vdso_data->cs_shift = clock->shift;
- vdso_data->wtm_clock_sec = wtm->tv_sec;
- vdso_data->wtm_clock_nsec = wtm->tv_nsec;
+ vdso_data->cs_cycle_last = tk->clock->cycle_last;
+ vdso_data->xtime_clock_sec = tk->xtime_sec;
+ vdso_data->xtime_clock_nsec = tk->xtime_nsec >> tk->shift;
+ vdso_data->cs_mult = tk->mult;
+ vdso_data->cs_shift = tk->shift;
+ vdso_data->wtm_clock_sec = tk->wall_to_monotonic.tv_sec;
+ vdso_data->wtm_clock_nsec = tk->wall_to_monotonic.tv_nsec;
}
smp_wmb();
^ permalink raw reply related
* [PATCH 1/4] arm64: Select MODULES_USE_ELF_RELA
From: Catalin Marinas @ 2012-10-16 16:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350406000-30882-1-git-send-email-catalin.marinas@arm.com>
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
^ permalink raw reply related
* [PATCH 0/4] arm64: Random fixes for 3.7
From: Catalin Marinas @ 2012-10-16 16:46 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
These are a few AArch64 fixes I want to get in 3.7.
Comments welcome. Thanks.
Catalin Marinas (4):
arm64: Select MODULES_USE_ELF_RELA
arm64: Fix the update_vsyscall() prototype
arm64: Ignore memory blocks below PHYS_OFFSET
arm64: No need to set the x0-x2 registers in start_thread()
arch/arm64/Kconfig | 1 +
arch/arm64/include/asm/processor.h | 10 ----------
arch/arm64/kernel/setup.c | 12 ++++++++++++
arch/arm64/kernel/vdso.c | 20 ++++++++++----------
4 files changed, 23 insertions(+), 20 deletions(-)
^ permalink raw reply
* [PATCH RFC 02/11 v4] gpio: Add sysfs support to block GPIO API
From: Greg KH @ 2012-10-16 16:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <507D58D9.2040607@antcom.de>
On Tue, Oct 16, 2012 at 02:53:45PM +0200, Roland Stigge wrote:
> On 10/16/2012 01:57 AM, Greg KH wrote:
> > On Tue, Oct 16, 2012 at 01:31:18AM +0200, Roland Stigge wrote:
> >> +int gpio_block_export(struct gpio_block *block)
> >> +{
> >> + int status;
> >> + struct device *dev;
> >> +
> >> + /* can't export until sysfs is available ... */
> >> + if (!gpio_class.p) {
> >> + pr_debug("%s: called too early!\n", __func__);
> >> + return -ENOENT;
> >> + }
> >> +
> >> + mutex_lock(&sysfs_lock);
> >> + dev = device_create(&gpio_class, NULL, MKDEV(0, 0), block,
> >> + block->name);
> >> + if (!IS_ERR(dev))
> >> + status = sysfs_create_group(&dev->kobj, &gpio_block_attr_group);
> >> + else
> >> + status = PTR_ERR(dev);
> >> + mutex_unlock(&sysfs_lock);
> >
> > You just raced with userspace telling it that the device was present,
> > yet the attributes are not there. Don't do that, use the default class
> > attributes for the class and then the driver core will create them
> > automagically without needing to this "by hand" at all.
>
> I guess you mean class attributes like gpio_class_attrs[] of gpio_class?
Yes.
> Aren't class attributes specific to a class only (i.e. only one
> attribute at the root for all devices)? What I needed above are
> attributes for the block itself (of which there can be several). So we
> need device attributes for each block, not class attributes here.
Yes, that is what the dev_attrs field in 'struct class' is for.
> Maybe there's some other kind of locking/atomicity available for this task?
>
> 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...
greg k-h
^ permalink raw reply
* [PATCH V2 0/7] support the cpts found on am335x devices
From: N, Mugunthan V @ 2012-10-16 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cover.1350329726.git.richardcochran@gmail.com>
> -----Original Message-----
> From: Richard Cochran [mailto:richardcochran at gmail.com]
> Sent: Tuesday, October 16, 2012 1:18 AM
> To: netdev at vger.kernel.org
> Cc: linux-arm-kernel at lists.infradead.org; David Miller; Chemparathy,
> Cyril; N, Mugunthan V; Govindarajan, Sriramakrishnan
> Subject: [PATCH V2 0/7] support the cpts found on am335x devices
>
> This patch series, based on linux-3.7-rc1 plus the fixes I posted
> today, adds support for the Common Platform Time Sync (CPTS) found on
> the popular BeagleBone. The code enables hardware time stamping and a
> PTP Hardware Clock.
>
> Changes in V2
> - Now uses device tree
> - Actually works with vanilla kernel
>
> This work has been tested using the linuxptp PTP stack, and it seems
> to be working quite well. One limitation of the hardware is that not
> possible to adjust the clock frequency. Even without with this
> capability, the driver will be still be useful for 802.1AS
> applications, since they typically use a free running clock.
>
> There is one open issue with this driver which will hopefully soon be
> resolved. Time stamping only works on UDP packets. Although Layer 2 is
> supposed to work according to the TRM, I have not yet figured out
> how. The UDP only works when setting an undocumented bit, so maybe
> someone from TI can fill me in on this.
>
> Thanks,
> Richard
>
>
> Richard Cochran (7):
> cpsw: rename register banks to match the reference manual
> cpsw: add missing fields to the CPSW_SS register bank.
> cpsw: correct the CPSW_PORT register bank declaration
> cpsw: add a common header file for regsiter declarations
> cpts: introduce time stamping code and a PTP hardware clock.
> cpsw: add a DT field for the cpts offset
> cpsw: use the time stamping capabilities of the cpts
>
> Documentation/devicetree/bindings/net/cpsw.txt | 11 +-
> arch/arm/boot/dts/am33xx.dtsi | 5 +-
> drivers/net/ethernet/ti/Kconfig | 8 +
> drivers/net/ethernet/ti/Makefile | 2 +-
> drivers/net/ethernet/ti/cpsw.c | 84 ++++-
> drivers/net/ethernet/ti/cpsw_reg.h | 81 ++++
> drivers/net/ethernet/ti/cpts.c | 468
> ++++++++++++++++++++++++
> drivers/net/ethernet/ti/cpts.h | 148 ++++++++
> include/linux/platform_data/cpsw.h | 1 +
> 9 files changed, 788 insertions(+), 20 deletions(-)
> create mode 100644 drivers/net/ethernet/ti/cpsw_reg.h
> create mode 100644 drivers/net/ethernet/ti/cpts.c
> create mode 100644 drivers/net/ethernet/ti/cpts.h
>
> --
> 1.7.2.5
Richard
I had seen some issues with the patch series.
* 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
* 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
* CPTS Time which is obtained from hardware is not actually a nano
seconds as the CPTS ref clock is tied to 250MHz for AM335x.
* CPSW register mapping done in this patch series removes the CPSW
driver support for previous version found in TI814x
* CPSW Time stamping is done only for port 0 and port 1 is not done
Regards
Mugunthan V N
^ permalink raw reply
* [PATCH] Re: Hardcoded instruction causes certain features to fail on ARM platfrom due to endianness
From: Fei Yang @ 2012-10-16 16:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016124956.GC26075@linaro.org>
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?
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.
^ permalink raw reply
* [RESEND PATCH 2/2] ARM: kexec: Check segment memory addresses
From: Will Deacon @ 2012-10-16 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016161020.GA1613@blackmetal.musicnaut.iki.fi>
On Tue, Oct 16, 2012 at 05:10:21PM +0100, Aaro Koskinen wrote:
> Hi,
Hi Aaro,
> 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?
Cheers,
Will
^ permalink raw reply
* [RFC][PATCH v4? 0/7] Adaptive Body-Bias for OMAP
From: Tony Lindgren @ 2012-10-16 16:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121011222107.2941.62545@nucleus>
* 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?
Regards,
Tony
^ permalink raw reply
* [PATCH v3] video: Versatile Express DVI output driver
From: Pawel Moll @ 2012-10-16 16:30 UTC (permalink / raw)
To: linux-arm-kernel
Versatile Express' DVI video output can be connected to one the three
sources - motherboard's CLCD controller or a video signal generated
by one of the daughterboards.
This driver configures the muxer FPGA so the output displays content
of one of the framebuffers in the system (0 by default, can be changed
by user writing to the "fb" sysfs attribute of the muxfpga device).
It will also set up the display formatter mode and keep it up
to date with mode changes requested by the user (eg. with fbset
tool).
Signed-off-by: Pawel Moll <pawel.moll@arm.com>
---
drivers/video/Makefile | 3 +
drivers/video/vexpress-dvi.c | 220 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 223 insertions(+)
create mode 100644 drivers/video/vexpress-dvi.c
Hi Florian,
This is pretty much the same stuff I posted a month ago...
Other relevant changes are on their way to 3.8.
Would you be so kind and have a look at it? If the code looks fine,
would you prefer to merge it yourself, or should I push it through
arm-soc tree?
Thanks!
Pawel
diff --git a/drivers/video/Makefile b/drivers/video/Makefile
index 23e948e..2f4440d 100644
--- a/drivers/video/Makefile
+++ b/drivers/video/Makefile
@@ -167,3 +167,6 @@ obj-$(CONFIG_FB_VIRTUAL) += vfb.o
#video output switch sysfs driver
obj-$(CONFIG_VIDEO_OUTPUT_CONTROL) += output.o
+
+# platform specific output drivers
+obj-$(CONFIG_VEXPRESS_CONFIG) += vexpress-dvi.o
diff --git a/drivers/video/vexpress-dvi.c b/drivers/video/vexpress-dvi.c
new file mode 100644
index 0000000..f087534
--- /dev/null
+++ b/drivers/video/vexpress-dvi.c
@@ -0,0 +1,220 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Copyright (C) 2012 ARM Limited
+ */
+
+#define pr_fmt(fmt) "vexpress-dvi: " fmt
+
+#include <linux/fb.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/vexpress.h>
+
+
+static struct vexpress_config_func *vexpress_dvimode_func;
+
+static struct {
+ u32 xres, yres, mode;
+} vexpress_dvi_dvimodes[] = {
+ { 640, 480, 0 }, /* VGA */
+ { 800, 600, 1 }, /* SVGA */
+ { 1024, 768, 2 }, /* XGA */
+ { 1280, 1024, 3 }, /* SXGA */
+ { 1600, 1200, 4 }, /* UXGA */
+ { 1920, 1080, 5 }, /* HD1080 */
+};
+
+static void vexpress_dvi_mode_set(struct fb_info *info, u32 xres, u32 yres)
+{
+ int err = -ENOENT;
+ int i;
+
+ if (!vexpress_dvimode_func)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(vexpress_dvi_dvimodes); i++) {
+ if (vexpress_dvi_dvimodes[i].xres == xres &&
+ vexpress_dvi_dvimodes[i].yres == yres) {
+ pr_debug("mode: %ux%u = %d\n", xres, yres,
+ vexpress_dvi_dvimodes[i].mode);
+ err = vexpress_config_write(vexpress_dvimode_func, 0,
+ vexpress_dvi_dvimodes[i].mode);
+ break;
+ }
+ }
+
+ if (err)
+ pr_warn("Failed to set %ux%u mode! (%d)\n", xres, yres, err);
+}
+
+
+static struct vexpress_config_func *vexpress_muxfpga_func;
+static int vexpress_dvi_fb = -1;
+
+static int vexpress_dvi_mux_set(struct fb_info *info)
+{
+ int err;
+ u32 site = vexpress_get_site_by_dev(info->device);
+
+ if (!vexpress_muxfpga_func)
+ return -ENXIO;
+
+ err = vexpress_config_write(vexpress_muxfpga_func, 0, site);
+ if (!err) {
+ pr_debug("Selected MUXFPGA input %d (fb%d)\n", site,
+ info->node);
+ vexpress_dvi_fb = info->node;
+ vexpress_dvi_mode_set(info, info->var.xres,
+ info->var.yres);
+ } else {
+ pr_warn("Failed to select MUXFPGA input %d (fb%d)! (%d)\n",
+ site, info->node, err);
+ }
+
+ return err;
+}
+
+static int vexpress_dvi_fb_select(int fb)
+{
+ int err;
+ struct fb_info *info;
+
+ /* fb0 is the default */
+ if (fb < 0)
+ fb = 0;
+
+ info = registered_fb[fb];
+ if (!info || !lock_fb_info(info))
+ return -ENODEV;
+
+ err = vexpress_dvi_mux_set(info);
+
+ unlock_fb_info(info);
+
+ return err;
+}
+
+static ssize_t vexpress_dvi_fb_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ return sprintf(buf, "%d\n", vexpress_dvi_fb);
+}
+
+static ssize_t vexpress_dvi_fb_store(struct device *dev,
+ struct device_attribute *attr, const char *buf, size_t count)
+{
+ long value;
+ int err = kstrtol(buf, 0, &value);
+
+ if (!err)
+ err = vexpress_dvi_fb_select(value);
+
+ return err ? err : count;
+}
+
+DEVICE_ATTR(fb, S_IRUGO | S_IWUSR, vexpress_dvi_fb_show,
+ vexpress_dvi_fb_store);
+
+
+static int vexpress_dvi_fb_event_notify(struct notifier_block *self,
+ unsigned long action, void *data)
+{
+ struct fb_event *event = data;
+ struct fb_info *info = event->info;
+ struct fb_videomode *mode = event->data;
+
+ switch (action) {
+ case FB_EVENT_FB_REGISTERED:
+ if (vexpress_dvi_fb < 0)
+ vexpress_dvi_mux_set(info);
+ break;
+ case FB_EVENT_MODE_CHANGE:
+ case FB_EVENT_MODE_CHANGE_ALL:
+ if (info->node == vexpress_dvi_fb)
+ vexpress_dvi_mode_set(info, mode->xres, mode->yres);
+ break;
+ }
+
+ return NOTIFY_OK;
+}
+
+static struct notifier_block vexpress_dvi_fb_notifier = {
+ .notifier_call = vexpress_dvi_fb_event_notify,
+};
+static bool vexpress_dvi_fb_notifier_registered;
+
+
+enum vexpress_dvi_func { FUNC_MUXFPGA, FUNC_DVIMODE };
+
+static struct of_device_id vexpress_dvi_of_match[] = {
+ {
+ .compatible = "arm,vexpress-muxfpga",
+ .data = (void *)FUNC_MUXFPGA,
+ }, {
+ .compatible = "arm,vexpress-dvimode",
+ .data = (void *)FUNC_DVIMODE,
+ },
+ {}
+};
+
+static int vexpress_dvi_probe(struct platform_device *pdev)
+{
+ enum vexpress_dvi_func func;
+ const struct of_device_id *match =
+ of_match_device(vexpress_dvi_of_match, &pdev->dev);
+
+ if (match)
+ func = (enum vexpress_dvi_func)match->data;
+ else
+ func = pdev->id_entry->driver_data;
+
+ switch (func) {
+ case FUNC_MUXFPGA:
+ vexpress_muxfpga_func =
+ vexpress_config_func_get_by_dev(&pdev->dev);
+ device_create_file(&pdev->dev, &dev_attr_fb);
+ break;
+ case FUNC_DVIMODE:
+ vexpress_dvimode_func =
+ vexpress_config_func_get_by_dev(&pdev->dev);
+ break;
+ }
+
+ if (!vexpress_dvi_fb_notifier_registered) {
+ fb_register_client(&vexpress_dvi_fb_notifier);
+ vexpress_dvi_fb_notifier_registered = true;
+ }
+
+ vexpress_dvi_fb_select(vexpress_dvi_fb);
+
+ return 0;
+}
+
+static const struct platform_device_id vexpress_dvi_id_table[] = {
+ { .name = "vexpress-muxfpga", .driver_data = FUNC_MUXFPGA, },
+ { .name = "vexpress-dvimode", .driver_data = FUNC_DVIMODE, },
+ {}
+};
+
+static struct platform_driver vexpress_dvi_driver = {
+ .probe = vexpress_dvi_probe,
+ .driver = {
+ .name = "vexpress-dvi",
+ .of_match_table = vexpress_dvi_of_match,
+ },
+ .id_table = vexpress_dvi_id_table,
+};
+
+static int __init vexpress_dvi_init(void)
+{
+ return platform_driver_register(&vexpress_dvi_driver);
+}
+device_initcall(vexpress_dvi_init);
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH] ARM: kernel: update cpuinfo to print all online CPUs features
From: Lorenzo Pieralisi @ 2012-10-16 16:24 UTC (permalink / raw)
To: linux-arm-kernel
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/include/asm/cpu.h b/arch/arm/include/asm/cpu.h
index d797223..2744f06 100644
--- a/arch/arm/include/asm/cpu.h
+++ b/arch/arm/include/asm/cpu.h
@@ -15,6 +15,7 @@
struct cpuinfo_arm {
struct cpu cpu;
+ u32 cpuid;
#ifdef CONFIG_SMP
unsigned int loops_per_jiffy;
#endif
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);
#if defined(CONFIG_SMP)
- for_each_online_cpu(i) {
/*
* glibc reads /proc/cpuinfo to determine the number of
* online processors, looking for lines beginning with
@@ -1070,42 +1072,40 @@ static int c_show(struct seq_file *m, void *v)
seq_printf(m, "BogoMIPS\t: %lu.%02lu\n\n",
per_cpu(cpu_data, i).loops_per_jiffy / (500000UL/HZ),
(per_cpu(cpu_data, i).loops_per_jiffy / (5000UL/HZ)) % 100);
- }
-#else /* CONFIG_SMP */
- seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
- loops_per_jiffy / (500000/HZ),
- (loops_per_jiffy / (5000/HZ)) % 100);
+#else
+ seq_printf(m, "BogoMIPS\t: %lu.%02lu\n",
+ loops_per_jiffy / (500000/HZ),
+ (loops_per_jiffy / (5000/HZ)) % 100);
#endif
+ /* dump out the processor features */
+ seq_puts(m, "Features\t: ");
- /* dump out the processor features */
- seq_puts(m, "Features\t: ");
+ for (j = 0; hwcap_str[j]; j++)
+ if (elf_hwcap & (1 << j))
+ seq_printf(m, "%s ", hwcap_str[j]);
- for (i = 0; hwcap_str[i]; i++)
- if (elf_hwcap & (1 << i))
- seq_printf(m, "%s ", hwcap_str[i]);
+ seq_printf(m, "\nCPU implementer\t: 0x%02x\n", cpuid >> 24);
+ seq_printf(m, "CPU architecture: %s\n",
+ proc_arch[cpu_architecture()]);
- seq_printf(m, "\nCPU implementer\t: 0x%02x\n", read_cpuid_id() >> 24);
- seq_printf(m, "CPU architecture: %s\n", proc_arch[cpu_architecture()]);
-
- if ((read_cpuid_id() & 0x0008f000) == 0x00000000) {
- /* pre-ARM7 */
- seq_printf(m, "CPU part\t: %07x\n", read_cpuid_id() >> 4);
- } else {
- if ((read_cpuid_id() & 0x0008f000) == 0x00007000) {
- /* ARM7 */
- seq_printf(m, "CPU variant\t: 0x%02x\n",
- (read_cpuid_id() >> 16) & 127);
+ if ((cpuid & 0x0008f000) == 0x00000000) {
+ /* pre-ARM7 */
+ seq_printf(m, "CPU part\t: %07x\n", cpuid >> 4);
} else {
- /* post-ARM7 */
- seq_printf(m, "CPU variant\t: 0x%x\n",
- (read_cpuid_id() >> 20) & 15);
+ if ((cpuid & 0x0008f000) == 0x00007000) {
+ /* ARM7 */
+ seq_printf(m, "CPU variant\t: 0x%02x\n",
+ (cpuid >> 16) & 127);
+ } else {
+ /* post-ARM7 */
+ seq_printf(m, "CPU variant\t: 0x%x\n",
+ (cpuid >> 20) & 15);
+ }
+ seq_printf(m, "CPU part\t: 0x%03x\n",
+ (cpuid >> 4) & 0xfff);
}
- seq_printf(m, "CPU part\t: 0x%03x\n",
- (read_cpuid_id() >> 4) & 0xfff);
+ seq_printf(m, "CPU revision\t: %d\n\n", cpuid & 15);
}
- seq_printf(m, "CPU revision\t: %d\n", read_cpuid_id() & 15);
-
- seq_puts(m, "\n");
seq_printf(m, "Hardware\t: %s\n", machine_name);
seq_printf(m, "Revision\t: %04x\n", system_rev);
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index f0bcb1e..73f407e 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -211,6 +211,7 @@ static void __cpuinit smp_store_cpu_info(unsigned int cpuid)
struct cpuinfo_arm *cpu_info = &per_cpu(cpu_data, cpuid);
cpu_info->loops_per_jiffy = loops_per_jiffy;
+ cpu_info->cpuid = read_cpuid_id();
store_cpu_topology(cpuid);
}
--
1.7.12
^ permalink raw reply related
* [GIT PULL] Versatile Express updates for v3.8
From: Pawel Moll @ 2012-10-16 16:24 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof,
Would you be so kind to pull the updates for Versatile Express? It's the
same stuff as discussed last month (I've just added a couple of fixes
for bugs reported by Tixy) plus the hwmon driver (the maintainer acked
it and chosen to get it merged through the arm-soc tree).
Thanks!
Pawe?
The following changes since commit ddffeb8c4d0331609ef2581d84de4d763607bd37:
Linux 3.7-rc1 (2012-10-14 14:41:04 -0700)
are available in the git repository at:
git://git.linaro.org/people/pawelmoll/linux.git vexpress-v3.7-rc1
for you to fetch changes up to 1a84f27233a708e39e50d023e58b7ba14bf52171:
ARM: vexpress: Make the debug UART detection more specific (2012-10-16 17:12:58 +0100)
----------------------------------------------------------------
Pawel Moll (8):
hwmon: Versatile Express hwmon driver
mfd: Versatile Express config infrastructure
mfd: Versatile Express system registers driver
ARM: vexpress: Reset driver
ARM: vexpress: Add config bus components and clocks to DTs
ARM: vexpress: Start using new Versatile Express infrastructure
ARM: vexpress: Remove motherboard dependencies in the DTS files
ARM: vexpress: Make the debug UART detection more specific
.../devicetree/bindings/arm/vexpress-sysreg.txt | 50 ++
Documentation/devicetree/bindings/arm/vexpress.txt | 98 +++-
.../devicetree/bindings/hwmon/vexpress.txt | 23 +
Documentation/hwmon/vexpress | 34 ++
arch/arm/boot/dts/vexpress-v2m-rs1.dtsi | 146 +++++-
arch/arm/boot/dts/vexpress-v2m.dtsi | 146 +++++-
arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dts | 121 ++++-
arch/arm/boot/dts/vexpress-v2p-ca15_a7.dts | 186 ++++++-
arch/arm/boot/dts/vexpress-v2p-ca5s.dts | 84 ++-
arch/arm/boot/dts/vexpress-v2p-ca9.dts | 136 ++++-
arch/arm/include/asm/hardware/sp810.h | 6 -
arch/arm/include/debug/vexpress.S | 10 +-
arch/arm/mach-vexpress/Kconfig | 4 +-
arch/arm/mach-vexpress/Makefile | 2 +-
arch/arm/mach-vexpress/ct-ca9x4.c | 41 +-
arch/arm/mach-vexpress/include/mach/motherboard.h | 81 ---
arch/arm/mach-vexpress/platsmp.c | 3 +-
arch/arm/mach-vexpress/reset.c | 141 +++++
arch/arm/mach-vexpress/v2m.c | 349 ++++---------
drivers/hwmon/Kconfig | 8 +
drivers/hwmon/Makefile | 1 +
drivers/hwmon/vexpress.c | 229 ++++++++
drivers/mfd/Kconfig | 6 +
drivers/mfd/Makefile | 1 +
drivers/mfd/vexpress-config.c | 277 ++++++++++
drivers/mfd/vexpress-sysreg.c | 552 ++++++++++++++++++++
include/linux/vexpress.h | 121 +++++
27 files changed, 2435 insertions(+), 421 deletions(-)
create mode 100644 Documentation/devicetree/bindings/arm/vexpress-sysreg.txt
create mode 100644 Documentation/devicetree/bindings/hwmon/vexpress.txt
create mode 100644 Documentation/hwmon/vexpress
create mode 100644 arch/arm/mach-vexpress/reset.c
create mode 100644 drivers/hwmon/vexpress.c
create mode 100644 drivers/mfd/vexpress-config.c
create mode 100644 drivers/mfd/vexpress-sysreg.c
create mode 100644 include/linux/vexpress.h
^ permalink raw reply
* [RESEND PATCH 2/2] ARM: kexec: Check segment memory addresses
From: Aaro Koskinen @ 2012-10-16 16:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1348157018-31059-2-git-send-email-will.deacon@arm.com>
Hi,
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.
A.
^ permalink raw reply
* [PATCH 00/11] Minimum set of omap serial patches to fix merge window breakage
From: Tony Lindgren @ 2012-10-16 15:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016101458.GZ21164@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [121016 03:16]:
>
> There are two options to resolve this. The first one is to revert this
> patch to bring the driver back down to the pre-merge window state. The
> other is to apply this series of patches, which frankly I don't think
> is -rc material, even with the above regressions.
Yes reverting it is the way to go as we discussed in some off-list
emails. I think everybody agrees that this is too intrusive for the
-rc series :)
Regards,
Tony
^ permalink raw reply
* [PATCH 1/1] Documentation: Describe Device Tree bindings for GPIO Regulator driver
From: Stephen Warren @ 2012-10-16 15:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350374553-12678-1-git-send-email-lee.jones@linaro.org>
On 10/16/2012 02:02 AM, Lee Jones wrote:
> Here we specify all non-standard bindings which can be used when
> requesting the use of an GPIO controlled regulator from Device Tree.
FWIW since I commented on this before and accidentally noticed the
repost, the binding looks fine to me now. So, this patch,
Reviewed-by: Stephen Warren <swarren@nvidia.com>
^ permalink raw reply
* [PATCH 1/4] leds: leds-ns2: add device tree binding
From: Jason Cooper @ 2012-10-16 15:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20121016093914.GD28384@kw.sim.vm.gnt>
On Tue, Oct 16, 2012 at 11:39:14AM +0200, Simon Guinot wrote:
> On Mon, Oct 15, 2012 at 03:58:09PM -0400, Jason Cooper wrote:
> > On Mon, Oct 15, 2012 at 09:12:22PM +0200, Simon Guinot wrote:
> > > On Mon, Oct 15, 2012 at 01:41:44PM -0400, Jason Cooper wrote:
> > > > On Mon, Oct 15, 2012 at 05:34:52PM +0200, Simon Guinot wrote:
...
> > > > > @@ -312,8 +389,9 @@ static struct platform_driver ns2_led_driver = {
> > > > > .probe = ns2_led_probe,
> > > > > .remove = __devexit_p(ns2_led_remove),
> > > > > .driver = {
> > > > > - .name = "leds-ns2",
> > > > > - .owner = THIS_MODULE,
> > > > > + .name = "leds-ns2",
> > > > > + .owner = THIS_MODULE,
> > > >
> > > > nit. whitespace before '=', above two lines.
> > >
> > > Sorry I don't get it. For the two lines before, I used two tabs before
> > > '='. As a result, this lines are aligned with the next one. I got no
> > > warnings and no errors from checkpatch.pl.
> >
> > It's not a checkpatch problem. It's that before your patch, the equals
> > signs were lined up. Afterwards, they aren't. In either case, if you
> > would like to fix the whitespace (line up all struct elements and the
> > equals signs), that should be a separate patch.
>
> The current patch inserts a new field (of_match_table) in the structure.
> This new field breaks the equals signs alignment. I think it is correct
> to restore the alignment broken by a patch in the same patch context.
>
> Do you really want me to put this in a separate patch ?
Ok, I see what you were doing. No need for a separate patch.
> > > > > + .of_match_table = of_match_ptr(of_ns2_leds_match),
> > > >
> > > > Have you tried this with OF_GPIO=n? of_match_ptr() handles CONFIG_OF
> > > > being enabled/disabled. Which means the case of CONFIG_OF=y,
> > > > CONFIG_OF_GPIO=n appears to be unhandled.
> > >
> > > Good caught. I guess I have just copied a bug from the driver gpio-fan.
> >
> > On the next round, please add a separate patch fixing gpio-fan.c.
>
> After a second look, I noticed that several drivers are also mixing up
> CONFIG_OF and CONFIG_OF_GPIO checks: gpio-fan, leds-gpio, gpio_keys.c,
> i2c-gpio.c, spi-s3c64xx.c, ...
>
> I also noticed that CONFIG_OF_GPIO can't be selected separately from
> CONFIG_OF. From Kconfig, CONFIG_OF implies CONFIG_OF_GPIO.
>
> So, I am no longer convinced we have a bug here. But if there is, we
> will need more than a single patch to fix it :)
Agreed. I'd hate to see what happens if CONFIG_OF_GPIO was decoupled
from CONFIG_OF. :-/ Once DT conversion has settled down, we'll have to
look at removing it.
thx,
Jason.
^ permalink raw reply
* [PATCH] OMAP4: devices: fixup OMAP4 DMIC platform device error message
From: Sebastien Guiriec @ 2012-10-16 15:30 UTC (permalink / raw)
To: linux-arm-kernel
Correct DMIC hwmod lockup error message and replace printk() by
pr_err().
Signed-off-by: Sebastien Guiriec <s-guiriec@ti.com>
---
arch/arm/mach-omap2/devices.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index c8c2117..cba60e0 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -341,7 +341,7 @@ static void __init omap_init_dmic(void)
oh = omap_hwmod_lookup("dmic");
if (!oh) {
- printk(KERN_ERR "Could not look up mcpdm hw_mod\n");
+ pr_err("Could not look up dmic hw_mod\n");
return;
}
--
1.7.10.4
^ permalink raw reply related
* [PATCH] Revert "serial: omap: fix software flow control"
From: Tony Lindgren @ 2012-10-16 15:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1350396562-32579-1-git-send-email-balbi@ti.com>
* Felipe Balbi <balbi@ti.com> [121016 07:16]:
> This reverts commit 957ee7270d632245b43f6feb0e70d9a5e9ea6cf6
> (serial: omap: fix software flow control).
>
> As Russell has pointed out, that commit isn't fixing
> Software Flow Control at all, and it actually makes
> it even more broken.
>
> It was agreed to revert this commit and use Russell's
> latest UART patches instead.
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Signed-off-by: Felipe Balbi <balbi@ti.com>
This seems like the best way to go for the -rc series:
Acked-by: Tony Lindgren <tony@atomide.com>
^ permalink raw reply
* PDF documentation
From: Mikael Pettersson @ 2012-10-16 14:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAE7jHC83biZy7TNYSr+-X85tpenqtAHuwSO47Q-6+XRF0fUxLA@mail.gmail.com>
On Tue, 16 Oct 2012 15:22:52 +0200, Constantine Shulyupin <const@makelinux.com> wrote:
> Hi,
>
> I have some questions and ideas about documentation in PDF format.
> During embedded SW development I often work with documentation,
> especially datasheets in PDF format. I have some issues with such
> documentation. It is not so easy to manage a lot of PDF documents
> sometimes with strange code in file names. It is not easy to store
> and share links to documentation.
> It is possible to reference to a PDF page in this way
> http://www.ti.com/lit/ds/symlink/omap4430.pdf#page=3D100 , but it slow
> and doesn't work in all cases.
> Sometimes it is more easy just to copy paste and send by email part of
> documentation instead of using hyperlinks.
> I found, that it is more easy work (and work collaboratively) with
> documentation in HTML format. Sometimes it is possible just to convert
> PDF to HTML.
>
> Questions:
> - have same issues with PDF documentation and datasheets?
No. They work just fine.
> - do you think documentation and datasheets in HTML format on a site
> can be more useful than PDF?
Fore brief overviews, html will do, but for actual technical documentation
PDF is *infinitely* better than html.
> - what PDF documentation do you use? (You can just drop a link to PDF,
> for example http://www.ti.com/lit/ds/symlink/omap4430.pdf)
CPU manuals and errata updates, ISA manuals, ABI manuals.
^ permalink raw reply
* dma_alloc_coherent fails in framebuffer
From: James Bottomley @ 2012-10-16 14:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAA_GA1cPE+m8N1LQA2iOym4jbFwcHG+K2p-3iBovPWuf1N1q+g@mail.gmail.com>
On Tue, 2012-10-16 at 10:17 +0800, Bob Liu wrote:
> I think you need to declare that memory using
> dma_declare_coherent_memory() before
> alloc_from_coherent.
This isn't true. Almost every platform has a mechanism for
manufacturing coherent memory (in the worst case, they just turn off the
CPU cache on a page and hand it out). The purpose of
dma_declare_coherent_memory() is to allow a per device declaration of
preferred regions ... usually because they reside either on the fast
path to the device or sometimes on the device itself. There are only a
handful of devices which need it, so in the ordinary course of events,
dma_alloc_coherent() is used without any memory declaration.
James
^ permalink raw reply
* [Celinux-dev] PDF documentation
From: Wolfgang Denk @ 2012-10-16 14:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAE7jHC83biZy7TNYSr+-X85tpenqtAHuwSO47Q-6+XRF0fUxLA@mail.gmail.com>
Dear Constantine Shulyupin,
In message <CAE7jHC83biZy7TNYSr+-X85tpenqtAHuwSO47Q-6+XRF0fUxLA@mail.gmail.com> you wrote:
>
> I have some questions and ideas about documentation in PDF format.
> During embedded SW development I often work with documentation,
> especially datasheets in PDF format. I have some issues with such
> documentation. It is not so easy to manage a lot of PDF documents
> sometimes with strange code in file names. It is not easy to store
> and share links to documentation.
PDF has a lot of advantages in many situations, but I agree that it is
also non-perfect for many other use cases.
> Questions:
> - have same issues with PDF documentation and datasheets?
> - do you think documentation and datasheets in HTML format on a site
> can be more useful than PDF?
HTML is really useful in a web browser only.
For documentation of the U-Boot boot loader we use a very different
approach: documentation is created, stored and edited in a wiki
(using FosWiki, see http://foswiki.org/). This has the advantage that
you can make it either easily editable to the community, or put
arbitrary access restrictions to it by using wiki user / group access
permissions. In combination with some plugins (like TocPlugin,
BookmakerPlugin and PublishPlugin) we can then "linearize" the entries
in the wiki to generate a "book" which can be read both online (as
HTML) or offline (by publishing the content as a linerarized, single
HTLP, plain text, PDF and/or PostScript document).
To give you a feeling how this works, please see for example
http://www.denx.de/wiki/view/DULG/Manual?stickboard=m28
http://www.denx.de/wiki/publish/DULG/DULG-m28.html
http://www.denx.de/wiki/publish/DULG/DULG-m28.ps
and http://www.denx.de/wiki/publish/DULG/DULG-m28.pdf
[Actually this documentation does much more behind the scenes; all
examples in this documentation come from include files which are
automatically generated from our regression test suite (DUTS); so the
procedure is to come up with a new software version, run the test
suite over it, upload the generated log files to the web server, and
voila, there is a new version of the documentation matching exactly
the new software version.]
And the nice thing is: all this is based on free software only...
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
One difference between a man and a machine is that a machine is quiet
when well oiled.
^ 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