* [GIT PULL v3] pxa: patches for v2.6.38-rc
From: Russell King - ARM Linux @ 2011-01-15 9:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinZUW9Xvp-Yoz_cQnVo+iGb7A1XBgzE0yuCJzvN@mail.gmail.com>
On Fri, Jan 14, 2011 at 07:26:39PM -0600, Eric Miao wrote:
> On Fri, Jan 14, 2011 at 3:49 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Fri, Jan 14, 2011 at 05:31:47PM +0000, Russell King - ARM Linux wrote:
> >> On Fri, Jan 14, 2011 at 11:08:59AM -0600, Eric Miao wrote:
> >> > Hi Russell,
> >> >
> >> > I rebased the branch on top of devel-stable. The conflict in irq.c is
> >> > fixed. And there is a one-liner patch fixing a building issue in spitz.c
> >> > missing of physmap.h. Please re-pull and let know any other issue.
> >>
> >> Pulled cleanly, thanks.
> >
> > Building my PXA config:
> >
> > arch/arm/mach-pxa/irq.c:124: warning: initialization from incompatible pointer type
> > arch/arm/mach-pxa/irq.c:125: warning: initialization from incompatible pointer type
> > arch/arm/mach-pxa/irq.c:126: warning: initialization from incompatible pointer type
> > arch/arm/mach-pxa/irq.c:127: warning: initialization from incompatible pointer type
> >
> > Seems the initializers want to be .irq_ack rather than .ack etc.
>
> You are right. Do you want me to have another patch on top or I
> make the change back into the guilty commit and you re-pull? I'd
> prefer the latter.
I dropped your tree so you can fix them locally.
^ permalink raw reply
* SMP: BUG() on cat /proc/$PID/stack
From: Rabin Vincent @ 2011-01-15 4:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110113231136.GF24149@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 04:41, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> So, rather than going BUG(), lets instead return a terminated trace -
> something like this. ?Could you test and report back please?
Tested-by: Rabin Vincent <rabin@rab.in>
^ permalink raw reply
* [PATCH] ARM: make head.S less dependent on the compile time PHYS_OFFSET define
From: Nicolas Pitre @ 2011-01-15 4:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115004449.GU15996@n2100.arm.linux.org.uk>
On Sat, 15 Jan 2011, Russell King - ARM Linux wrote:
> I've pushed it out under the branch p2v. I think before this
> goes upstream, "ARM: P2V: Use pv_fixup trick to get physical address"
> needs merging with "ARM: P2V: make head.S use PLAT_PHYS_OFFSET" -
> it doesn't really make sense to fix the same code twice for the same
> underlying problem in the same patch set when it's possible to only
> fix it once.
Indeed. You probably should fold the following with it as well:
diff --git a/arch/arm/kernel/head.S b/arch/arm/kernel/head.S
index f5fe0c4..02a7a84 100644
--- a/arch/arm/kernel/head.S
+++ b/arch/arm/kernel/head.S
@@ -26,10 +26,6 @@
#include <mach/debug-macro.S>
#endif
-#define KERNEL_RAM_VADDR (PAGE_OFFSET + TEXT_OFFSET)
-#define KERNEL_RAM_PADDR (PLAT_PHYS_OFFSET + TEXT_OFFSET)
-
-
/*
* swapper_pg_dir is the virtual address of the initial page table.
* We place the page tables 16K below KERNEL_RAM_VADDR. Therefore, we must
@@ -37,6 +33,7 @@
* the least significant 16 bits to be 0x8000, but we could probably
* relax this restriction to KERNEL_RAM_VADDR >= PAGE_OFFSET + 0x4000.
*/
+#define KERNEL_RAM_VADDR (PAGE_OFFSET + TEXT_OFFSET)
#if (KERNEL_RAM_VADDR & 0xffff) != 0x8000
#error KERNEL_RAM_VADDR must start at 0xXXXX8000
#endif
@@ -195,10 +192,8 @@ __create_page_tables:
/*
* Map some ram to cover our .data and .bss areas.
*/
- orr r3, r7, #(KERNEL_RAM_PADDR & 0xff000000)
- .if (KERNEL_RAM_PADDR & 0x00f00000)
- orr r3, r3, #(KERNEL_RAM_PADDR & 0x00f00000)
- .endif
+ add r3, r8, #TEXT_OFFSET
+ orr r3, r3, r7
add r0, r4, #(KERNEL_RAM_VADDR & 0xff000000) >> 18
str r3, [r0, #(KERNEL_RAM_VADDR & 0x00f00000) >> 18]!
ldr r6, =(_end - 1)
^ permalink raw reply related
* [PATCH 27/48] ARM: PL08x: avoid duplicating registers in txd and phychan structures
From: Dan Williams @ 2011-01-15 1:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <E1PZt3Z-00025W-0c@rmk-PC.arm.linux.org.uk>
On Mon, Jan 3, 2011 at 2:39 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> As we now have all the code accessing the phychan {csrc,cdst,clli,cctl,
> ccfg} members in one function, there's no point storing the data into
> the struct. ?Get rid of the struct members. ?Re-order the register dump
> in the dev_dbg() to reflect the order we write the registers to the DMA
> device.
>
> The txd {csrc,cdst,clli,cctl} values are duplicates of the lli[0]
> values, so there's no point duplicating these either. ?Program the DMAC
> registers directly from the lli[0] values.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
This one caused:
drivers/dma/amba-pl08x.c: In function 'pl08x_start_txd':
drivers/dma/amba-pl08x.c:205: warning: dereferencing 'void *' pointer
So I appended the following:
diff --git a/include/linux/amba/pl08x.h b/include/linux/amba/pl08x.h
index 933b4ed..5b87b6a 100644
--- a/include/linux/amba/pl08x.h
+++ b/include/linux/amba/pl08x.h
@@ -118,7 +118,7 @@ struct pl08x_txd {
dma_addr_t dst_addr;
size_t len;
dma_addr_t llis_bus;
- void *llis_va;
+ struct pl08x_lli *llis_va;
bool active;
/* Default cctl value for LLIs */
u32 cctl;
--
Dan
^ permalink raw reply related
* [GIT PULL v3] pxa: patches for v2.6.38-rc
From: Eric Miao @ 2011-01-15 1:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114214900.GP15996@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 3:49 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Fri, Jan 14, 2011 at 05:31:47PM +0000, Russell King - ARM Linux wrote:
>> On Fri, Jan 14, 2011 at 11:08:59AM -0600, Eric Miao wrote:
>> > Hi Russell,
>> >
>> > I rebased the branch on top of devel-stable. The conflict in irq.c is
>> > fixed. And there is a one-liner patch fixing a building issue in spitz.c
>> > missing of physmap.h. Please re-pull and let know any other issue.
>>
>> Pulled cleanly, thanks.
>
> Building my PXA config:
>
> arch/arm/mach-pxa/irq.c:124: warning: initialization from incompatible pointer type
> arch/arm/mach-pxa/irq.c:125: warning: initialization from incompatible pointer type
> arch/arm/mach-pxa/irq.c:126: warning: initialization from incompatible pointer type
> arch/arm/mach-pxa/irq.c:127: warning: initialization from incompatible pointer type
>
> Seems the initializers want to be .irq_ack rather than .ack etc.
You are right. Do you want me to have another patch on top or I
make the change back into the guilty commit and you re-pull? I'd
prefer the latter.
>
> I also need to remove asm/pgtable.h from arch/arm/mach-pxa/generic.c:
> ?CC ? ? ?arch/arm/mach-pxa/generic.o
> In file included from arch/arm/include/asm/pgtable.h:461,
> ? ? ? ? ? ? ? ? from arch/arm/mach-pxa/generic.c:26:
> include/asm-generic/pgtable.h: In function ?ptep_test_and_clear_young?:
> include/asm-generic/pgtable.h:29: error: dereferencing pointer to incomplete type
>
> and I also got:
> arch/arm/mach-pxa/tosa-bt.c: In function ?tosa_bt_probe?:
> arch/arm/mach-pxa/tosa-bt.c:84: error: implicit declaration of function ?rfkill_set_led_trigger_name?
>
> which looks like a missing dependency.
>
> Do you want to fix these and send an updated pull?
>
^ permalink raw reply
* [PATCH v2] ARM: pxa: PalmZ72: Add OV9640 camera support
From: Marek Vasut @ 2011-01-15 1:17 UTC (permalink / raw)
To: linux-arm-kernel
Rework of patch from 2009:
PalmZ72: Add support for OV9640 camera sensor
Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
---
v2: Use gpio_request_array()/gpio_free_array() array
arch/arm/mach-pxa/include/mach/palmz72.h | 5 +
arch/arm/mach-pxa/palmz72.c | 127 ++++++++++++++++++++++++++++++
2 files changed, 132 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-pxa/include/mach/palmz72.h b/arch/arm/mach-pxa/include/mach/palmz72.h
index 2bbcf70..0d4700a 100644
--- a/arch/arm/mach-pxa/include/mach/palmz72.h
+++ b/arch/arm/mach-pxa/include/mach/palmz72.h
@@ -44,6 +44,11 @@
#define GPIO_NR_PALMZ72_BT_POWER 17
#define GPIO_NR_PALMZ72_BT_RESET 83
+/* Camera */
+#define GPIO_NR_PALMZ72_CAM_PWDN 56
+#define GPIO_NR_PALMZ72_CAM_RESET 57
+#define GPIO_NR_PALMZ72_CAM_POWER 91
+
/** Initial values **/
/* Battery */
diff --git a/arch/arm/mach-pxa/palmz72.c b/arch/arm/mach-pxa/palmz72.c
index 7bf4017..27a8e6d 100644
--- a/arch/arm/mach-pxa/palmz72.c
+++ b/arch/arm/mach-pxa/palmz72.c
@@ -30,6 +30,7 @@
#include <linux/wm97xx.h>
#include <linux/power_supply.h>
#include <linux/usb/gpio_vbus.h>
+#include <linux/i2c-gpio.h>
#include <asm/mach-types.h>
#include <asm/mach/arch.h>
@@ -47,6 +48,9 @@
#include <mach/palm27x.h>
#include <mach/pm.h>
+#include <mach/camera.h>
+
+#include <media/soc_camera.h>
#include "generic.h"
#include "devices.h"
@@ -103,6 +107,28 @@ static unsigned long palmz72_pin_config[] __initdata = {
GPIO22_GPIO, /* LCD border color */
GPIO96_GPIO, /* lcd power */
+ /* PXA Camera */
+ GPIO81_CIF_DD_0,
+ GPIO48_CIF_DD_5,
+ GPIO50_CIF_DD_3,
+ GPIO51_CIF_DD_2,
+ GPIO52_CIF_DD_4,
+ GPIO53_CIF_MCLK,
+ GPIO54_CIF_PCLK,
+ GPIO55_CIF_DD_1,
+ GPIO84_CIF_FV,
+ GPIO85_CIF_LV,
+ GPIO93_CIF_DD_6,
+ GPIO108_CIF_DD_7,
+
+ GPIO56_GPIO, /* OV9640 Powerdown */
+ GPIO57_GPIO, /* OV9640 Reset */
+ GPIO91_GPIO, /* OV9640 Power */
+
+ /* I2C */
+ GPIO117_GPIO, /* I2C_SCL */
+ GPIO118_GPIO, /* I2C_SDA */
+
/* Misc. */
GPIO0_GPIO | WAKEUP_ON_LEVEL_HIGH, /* power detect */
GPIO88_GPIO, /* green led */
@@ -254,6 +280,106 @@ device_initcall(palmz72_pm_init);
#endif
/******************************************************************************
+ * SoC Camera
+ ******************************************************************************/
+#if defined(CONFIG_SOC_CAMERA_OV9640) || \
+ defined(CONFIG_SOC_CAMERA_OV9640_MODULE)
+static struct pxacamera_platform_data palmz72_pxacamera_platform_data = {
+ .flags = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
+ PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
+ .mclk_10khz = 2600,
+};
+
+/* Board I2C devices. */
+static struct i2c_board_info palmz72_i2c_device[] = {
+ {
+ I2C_BOARD_INFO("ov9640", 0x30),
+ }
+};
+
+static int palmz72_camera_power(struct device *dev, int power)
+{
+ gpio_set_value(GPIO_NR_PALMZ72_CAM_PWDN, !power);
+ mdelay(50);
+ return 0;
+}
+
+static int palmz72_camera_reset(struct device *dev)
+{
+ gpio_set_value(GPIO_NR_PALMZ72_CAM_RESET, 1);
+ mdelay(50);
+ gpio_set_value(GPIO_NR_PALMZ72_CAM_RESET, 0);
+ mdelay(50);
+ return 0;
+}
+
+static struct soc_camera_link palmz72_iclink = {
+ .bus_id = 0, /* Match id in pxa27x_device_camera in device.c */
+ .board_info = &palmz72_i2c_device[0],
+ .i2c_adapter_id = 0,
+ .module_name = "ov96xx",
+ .power = &palmz72_camera_power,
+ .reset = &palmz72_camera_reset,
+ .flags = SOCAM_DATAWIDTH_8,
+};
+
+static struct i2c_gpio_platform_data palmz72_i2c_bus_data = {
+ .sda_pin = 118,
+ .scl_pin = 117,
+ .udelay = 10,
+ .timeout = 100,
+};
+
+static struct platform_device palmz72_i2c_bus_device = {
+ .name = "i2c-gpio",
+ .id = 0, /* we use this as a replacement for i2c-pxa */
+ .dev = {
+ .platform_data = &palmz72_i2c_bus_data,
+ }
+};
+
+static struct platform_device palmz72_camera = {
+ .name = "soc-camera-pdrv",
+ .id = -1,
+ .dev = {
+ .platform_data = &palmz72_iclink,
+ },
+};
+
+/* Here we request the camera GPIOs and configure them. We power up the camera
+ * module, deassert the reset pin, but put it into powerdown (low to no power
+ * consumption) mode. This allows us to later bring the module up fast. */
+static struct gpio palmz72_camera_gpios[] = {
+ { GPIO_NR_PALMZ72_CAM_POWER, GPIOF_INIT_HIGH,"Camera DVDD" },
+ { GPIO_NR_PALMZ72_CAM_RESET, GPIOF_INIT_LOW, "Camera RESET" },
+ { GPIO_NR_PALMZ72_CAM_PWDN, GPIOF_INIT_LOW, "Camera PWDN" },
+};
+
+static inline void __init palmz72_cam_gpio_init(void)
+{
+ int ret;
+
+ ret = gpio_request_array(ARRAY_AND_SIZE(palmz72_camera_gpios));
+ if (!ret)
+ gpio_free_array(ARRAY_AND_SIZE(palmz72_camera_gpios));
+ else
+ printk(KERN_ERR "Camera GPIO init failed!\n");
+
+ return;
+}
+
+static void __init palmz72_camera_init(void)
+{
+ palmz72_cam_gpio_init();
+ pxa_set_camera_info(&palmz72_pxacamera_platform_data);
+ platform_device_register(&palmz72_i2c_bus_device);
+ platform_device_register(&palmz72_camera);
+}
+#else
+static inline void palmz72_camera_init(void) {}
+#endif
+
+/******************************************************************************
* Machine init
******************************************************************************/
static void __init palmz72_init(void)
@@ -276,6 +402,7 @@ static void __init palmz72_init(void)
palm27x_pmic_init();
palmz72_kpc_init();
palmz72_leds_init();
+ palmz72_camera_init();
}
MACHINE_START(PALMZ72, "Palm Zire72")
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/6 v12] ARM: Add basic architecture support for VIA/WonderMedia 85xx SoC's
From: Alexey Charkov @ 2011-01-15 1:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115005818.GV15996@n2100.arm.linux.org.uk>
<previous response went off-list by mistake, sorry for that>
2011/1/15 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Sat, Jan 15, 2011 at 03:53:56AM +0300, Alexey Charkov wrote:
>> 2010/12/28 Alexey Charkov <alchark@gmail.com>:
>> > 2010/12/23 Alexey Charkov <alchark@gmail.com>:
>> >> This adds support for the family of Systems-on-Chip produced initially
>> >> by VIA and now its subsidiary WonderMedia that have recently become
>> >> widespread in lower-end Chinese ARM-based tablets and netbooks.
>> >>
>> >> Support is included for both VT8500 and WM8505, selectable by a
>> >> configuration switch at kernel build time.
>> >>
>> >> Included are basic machine initialization files, register and
>> >> interrupt definitions, support for the on-chip interrupt controller,
>> >> high-precision OS timer, GPIO lines, necessary macros for early debug,
>> >> pulse-width-modulated outputs control, as well as platform device
>> >> configurations for the specific drivers implemented elsewhere.
>> >>
>> >> Signed-off-by: Alexey Charkov <alchark@gmail.com>
>> >
>> > Russell, will you take this for .38? Please note that the last
>> > revision of this patch was also submitted to the ARM Linux patch
>> > tracking system:
>> >
>> > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6597/1
>> >
>> > Best regards,
>> > Alexey
>> >
>>
>> Russell, I realize that there are quite a lot of other things to worry
>> about currently in the ARM Linux world, but could you please still
>> consider merging this patch before .38 window closes?
>
> It got lost in the patch system in the middle of the SPEAR deluge -
> and after that deluge I did say on list that it would result in things
> being missed. ?I've basically been ignoring everything in there since
> beyond the top few newest entries.
>
> In any case, I believe it's too late in this merge window with only
> four days left to start merging large amounts of code. ?I'd get
> moaned at by Linus. ?Sorry.
>
Ok, life is life. Could you then please take these to your tree for .39?
Best regards,
Alexey
^ permalink raw reply
* [PATCH 1/6 v12] ARM: Add basic architecture support for VIA/WonderMedia 85xx SoC's
From: Russell King - ARM Linux @ 2011-01-15 0:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTinb3A5CJ6r4Y0D0kMwJn8ZEyf_0mb4uW99mmUZ9@mail.gmail.com>
On Sat, Jan 15, 2011 at 03:53:56AM +0300, Alexey Charkov wrote:
> 2010/12/28 Alexey Charkov <alchark@gmail.com>:
> > 2010/12/23 Alexey Charkov <alchark@gmail.com>:
> >> This adds support for the family of Systems-on-Chip produced initially
> >> by VIA and now its subsidiary WonderMedia that have recently become
> >> widespread in lower-end Chinese ARM-based tablets and netbooks.
> >>
> >> Support is included for both VT8500 and WM8505, selectable by a
> >> configuration switch at kernel build time.
> >>
> >> Included are basic machine initialization files, register and
> >> interrupt definitions, support for the on-chip interrupt controller,
> >> high-precision OS timer, GPIO lines, necessary macros for early debug,
> >> pulse-width-modulated outputs control, as well as platform device
> >> configurations for the specific drivers implemented elsewhere.
> >>
> >> Signed-off-by: Alexey Charkov <alchark@gmail.com>
> >
> > Russell, will you take this for .38? Please note that the last
> > revision of this patch was also submitted to the ARM Linux patch
> > tracking system:
> >
> > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6597/1
> >
> > Best regards,
> > Alexey
> >
>
> Russell, I realize that there are quite a lot of other things to worry
> about currently in the ARM Linux world, but could you please still
> consider merging this patch before .38 window closes?
It got lost in the patch system in the middle of the SPEAR deluge -
and after that deluge I did say on list that it would result in things
being missed. I've basically been ignoring everything in there since
beyond the top few newest entries.
In any case, I believe it's too late in this merge window with only
four days left to start merging large amounts of code. I'd get
moaned at by Linus. Sorry.
^ permalink raw reply
* [PATCH 1/6 v12] ARM: Add basic architecture support for VIA/WonderMedia 85xx SoC's
From: Alexey Charkov @ 2011-01-15 0:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTik1tcL_ABdnq5r=MCxmLJtdP0nhOzA8irP1n0CC@mail.gmail.com>
2010/12/28 Alexey Charkov <alchark@gmail.com>:
> 2010/12/23 Alexey Charkov <alchark@gmail.com>:
>> This adds support for the family of Systems-on-Chip produced initially
>> by VIA and now its subsidiary WonderMedia that have recently become
>> widespread in lower-end Chinese ARM-based tablets and netbooks.
>>
>> Support is included for both VT8500 and WM8505, selectable by a
>> configuration switch at kernel build time.
>>
>> Included are basic machine initialization files, register and
>> interrupt definitions, support for the on-chip interrupt controller,
>> high-precision OS timer, GPIO lines, necessary macros for early debug,
>> pulse-width-modulated outputs control, as well as platform device
>> configurations for the specific drivers implemented elsewhere.
>>
>> Signed-off-by: Alexey Charkov <alchark@gmail.com>
>
> Russell, will you take this for .38? Please note that the last
> revision of this patch was also submitted to the ARM Linux patch
> tracking system:
>
> http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=6597/1
>
> Best regards,
> Alexey
>
Russell, I realize that there are quite a lot of other things to worry
about currently in the ARM Linux world, but could you please still
consider merging this patch before .38 window closes?
It has been (at different stages):
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Reviewed-by: Ryan Mallon <ryan@bluewatersys.com>
There's also a patch to the i8042 input controller that Dmitry
Torokhov wished to be merged together with this code. That one is:
Acked-by: Dmitry Torokhov <dtor@mail.ru>
and available at:
http://lists.arm.linux.org.uk/lurker/message/20101222.214141.c745816a.en.html
Best regards,
Alexey
^ permalink raw reply
* [PATCH] ARM: make head.S less dependent on the compile time PHYS_OFFSET define
From: Russell King - ARM Linux @ 2011-01-15 0:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101140050070.25804@xanadu.home>
On Fri, Jan 14, 2011 at 01:18:20AM -0500, Nicolas Pitre wrote:
> On Thu, 13 Jan 2011, Russell King - ARM Linux wrote:
>
> > On Thu, Jan 13, 2011 at 05:04:28PM -0500, Nicolas Pitre wrote:
> > > + .macro phys_offset, rd
> > > + mov \rd, pc
> > > + and \rd, \rd, #0xf8000000
> > > + .endm
> >
> > We can do loads better than that, as the p2v fixup code has proven.
> > Now that r8 has been eliminated, I may rebase the p2v stuff ontop of
> > that commit, and move the computation of phys_offset out of the p2v
> > fixup code - and have it in r8 for __create_page_tables to use.
> > FYI, the real PHYS_OFFSET value can be found by (eg):
> >
> > 1: .long .
> > .long PAGE_OFFSET
> >
> > adr r0, 1b
> > ldmia r0, {r1, r2}
> > sub r1, r0, r1
> > add r3, r2, r1
> >
> > r1 now contains the offset between virtual and physical spaces, r2
> > contains the compile-time PAGE_OFFSET constant, and r3 the runtime
> > equivalent of PHYS_OFFSET.
> >
> > None of this uses troublesome masking which will trip up on platforms
> > such as MSM - we really must stop writing code which assumes that
> > physical memory is aligned to >= 32MB.
>
> That is more reliable indeed. But without visibility into your reworked
> version of that code I opted for a less intrusive solution.
>
> Unfortunately this trick can't work for CONFIG_AUTO_ZRELADDR.
I've pushed it out under the branch p2v. I think before this
goes upstream, "ARM: P2V: Use pv_fixup trick to get physical address"
needs merging with "ARM: P2V: make head.S use PLAT_PHYS_OFFSET" -
it doesn't really make sense to fix the same code twice for the same
underlying problem in the same patch set when it's possible to only
fix it once.
^ permalink raw reply
* [PATCHv2] hwrng: add support for picoxcell TRNG
From: Herbert Xu @ 2011-01-15 0:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295030661-16364-1-git-send-email-jamie@jamieiles.com>
On Fri, Jan 14, 2011 at 06:44:21PM +0000, Jamie Iles wrote:
>
> + /* Wait for some data to become available. */
> + while (__raw_readl(csr) & CSR_OUT_EMPTY_MASK) {
> + if (!wait)
> + return 0;
> + cpu_relax();
> + }
This has the potential to loop indefinitely. Please add a time-out
to prevent that (see existing RNG drivers for example).
Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Tony Lindgren @ 2011-01-15 0:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115002531.GF22505@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 16:24]:
> On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> > * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> > >
> > > # ARMv6k
> > > config CPU_32v6K
> > > bool "Support ARM V6K processor extensions" if !SMP
> > > depends on CPU_V6 || CPU_V7
> > > default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> > >
> > > OMAP2 prevents the selection of armv6k support. This is probably a very
> > > bad idea if you want to run the resulting kernel on SMP hardware as it
> > > removes a barrier in the spinlock code and disables the SMP-safe bitops.
> >
> > I have some ideas to fix this. Unfortunately it will be inefficient
> > as spinlock.h can be included from modules too :( I was thinking we can
> > implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm
> > builds.
>
> For spinlocks, the important thing is the barrier. The wfe/sev are an
> optimization. The barrier contained with the ifdef is a valid V6
> instruction.
OK, great it's just drain WB. Then we can do the ussual iffdeffery
on it for multi-arm builds as it does not depend on the 6K extensions.
I can do a patch for this on Monday, gotta run now.
> > > The original patch which started turning this off was from the MX3 stuff,
> > > but without explaination.
> > >
> > > However, OMAP extended this to disabling the select statement for CPU_32v6K
> > > even if CPU_V7 is set:
> > >
> > > config CPU_V7
> > > bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |- select CPU_32v6K
> > > + select CPU_32v6K if !ARCH_OMAP2
> > >
> > > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
> > > patch should not have been merged.
> >
> > The only way we can fix that is do smp_on_up style rewriting of the assembly
> > during init between CPUv6 and v6K. Want me to do a patch for that?
>
> The bitops code is quite different between the two versions, and I doubt
> the smp_on_up rewriting will look at all pretty. I think it needs an
> alternative idea - like not using the 'byte' operations at all.
>
> Whether we have any code which passes non-word aligned pointers to bitops
> isn't particularly known - in theory they should all be unsigned long *'s,
> so should be word-aligned. Who knows what filesystems do though... and
> such a change could be disasterous to peoples data if the block/inode
> bitmaps get corrupted.
Hmm, how about emulation of those instructions for non-v6K ARMv6 processors?
I guess we could do some address checking in the bitops functions too for
multi-arm builds..
> IOW, such a change needs testing on a box where a range of filesystems are
> used, and the filesystems can be thrown away if corrupted.
Or we could patch in the address checking first and only disable it
later if now warnings.
Tony
^ permalink raw reply
* [PATCH v2] Introduce VPR200 board.
From: Marc Reilly @ 2011-01-15 0:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294962532-15790-2-git-send-email-marc@cpdesign.com.au>
Signed-off-by: Marc Reilly <marc@cpdesign.com.au>
---
arch/arm/mach-mx3/Kconfig | 14 ++
arch/arm/mach-mx3/Makefile | 1 +
arch/arm/mach-mx3/mach-vpr200.c | 327 +++++++++++++++++++++++++++++++++++++++
3 files changed, 342 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/mach-mx3/mach-vpr200.c
diff --git a/arch/arm/mach-mx3/Kconfig b/arch/arm/mach-mx3/Kconfig
index 0717f88..de80d98 100644
--- a/arch/arm/mach-mx3/Kconfig
+++ b/arch/arm/mach-mx3/Kconfig
@@ -229,4 +229,18 @@ config MACH_EUKREA_MBIMXSD35_BASEBOARD
endchoice
+config MACH_VPR200
+ bool "Support VPR200 platform"
+ select SOC_IMX35
+ select IMX_HAVE_PLATFORM_FSL_USB2_UDC
+ select IMX_HAVE_PLATFORM_IMX2_WDT
+ select IMX_HAVE_PLATFORM_IMX_UART
+ select IMX_HAVE_PLATFORM_IMX_I2C
+ select IMX_HAVE_PLATFORM_MXC_EHCI
+ select IMX_HAVE_PLATFORM_MXC_NAND
+ select IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX
+ help
+ Include support for VPR200 platform. This includes specific
+ configurations for the board and its peripherals.
+
endif
diff --git a/arch/arm/mach-mx3/Makefile b/arch/arm/mach-mx3/Makefile
index 8db1329..bc7294f 100644
--- a/arch/arm/mach-mx3/Makefile
+++ b/arch/arm/mach-mx3/Makefile
@@ -22,3 +22,4 @@ obj-$(CONFIG_MACH_MX35_3DS) += mach-mx35_3ds.o
obj-$(CONFIG_MACH_KZM_ARM11_01) += mach-kzm_arm11_01.o
obj-$(CONFIG_MACH_EUKREA_CPUIMX35) += mach-cpuimx35.o
obj-$(CONFIG_MACH_EUKREA_MBIMXSD35_BASEBOARD) += eukrea_mbimxsd-baseboard.o
+obj-$(CONFIG_MACH_VPR200) += mach-vpr200.o
diff --git a/arch/arm/mach-mx3/mach-vpr200.c b/arch/arm/mach-mx3/mach-vpr200.c
new file mode 100644
index 0000000..22ec78a
--- /dev/null
+++ b/arch/arm/mach-mx3/mach-vpr200.c
@@ -0,0 +1,327 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc. All Rights Reserved.
+ * Copyright (C) 2009 Marc Kleine-Budde, Pengutronix
+ * Copyright 2010 Creative Product Design
+ *
+ * Derived from mx35 3stack.
+ * Original author: Fabio Estevam <fabio.estevam@freescale.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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.
+ */
+
+#include <linux/types.h>
+#include <linux/init.h>
+#include <linux/platform_device.h>
+#include <linux/mtd/physmap.h>
+#include <linux/memory.h>
+#include <linux/gpio.h>
+
+#include <asm/mach-types.h>
+#include <asm/mach/arch.h>
+#include <asm/mach/time.h>
+
+#include <mach/hardware.h>
+#include <mach/common.h>
+#include <mach/iomux-mx35.h>
+#include <mach/irqs.h>
+#include <mach/ipu.h>
+#include <mach/mx3fb.h>
+
+#include <linux/i2c.h>
+#include <linux/i2c/at24.h>
+#include <linux/mfd/mc13xxx.h>
+#include <linux/gpio_keys.h>
+
+#include "devices-imx35.h"
+#include "devices.h"
+
+#define GPIO_LCDPWR IMX_GPIO_NR(1, 2)
+#define GPIO_PMIC_INT IMX_GPIO_NR(2, 0)
+
+#define GPIO_BUTTON1 IMX_GPIO_NR(1, 4)
+#define GPIO_BUTTON2 IMX_GPIO_NR(1, 5)
+#define GPIO_BUTTON3 IMX_GPIO_NR(1, 7)
+#define GPIO_BUTTON4 IMX_GPIO_NR(1, 8)
+#define GPIO_BUTTON5 IMX_GPIO_NR(1, 9)
+#define GPIO_BUTTON6 IMX_GPIO_NR(1, 10)
+#define GPIO_BUTTON7 IMX_GPIO_NR(1, 11)
+#define GPIO_BUTTON8 IMX_GPIO_NR(1, 12)
+
+static const struct fb_videomode fb_modedb[] = {
+ {
+ /* 800x480 @ 60 Hz */
+ .name = "PT0708048",
+ .refresh = 60,
+ .xres = 800,
+ .yres = 480,
+ .pixclock = KHZ2PICOS(33260),
+ .left_margin = 50,
+ .right_margin = 156,
+ .upper_margin = 10,
+ .lower_margin = 10,
+ .hsync_len = 1, /* note: DE only display */
+ .vsync_len = 1, /* note: DE only display */
+ .sync = FB_SYNC_CLK_IDLE_EN | FB_SYNC_OE_ACT_HIGH,
+ .vmode = FB_VMODE_NONINTERLACED,
+ .flag = 0,
+ }, {
+ /* 800x480 @ 60 Hz */
+ .name = "CTP-CLAA070LC0ACW",
+ .refresh = 60,
+ .xres = 800,
+ .yres = 480,
+ .pixclock = KHZ2PICOS(27000),
+ .left_margin = 50,
+ .right_margin = 50, /* whole line should have 900 clocks */
+ .upper_margin = 10,
+ .lower_margin = 10, /* whole frame should have 500 lines */
+ .hsync_len = 1, /* note: DE only display */
+ .vsync_len = 1, /* note: DE only display */
+ .sync = FB_SYNC_CLK_IDLE_EN | FB_SYNC_OE_ACT_HIGH,
+ .vmode = FB_VMODE_NONINTERLACED,
+ .flag = 0,
+ }
+};
+
+static struct ipu_platform_data mx3_ipu_data = {
+ .irq_base = MXC_IPU_IRQ_START,
+};
+
+static struct mx3fb_platform_data mx3fb_pdata = {
+ .dma_dev = &mx3_ipu.dev,
+ .name = "PT0708048",
+ .mode = fb_modedb,
+ .num_modes = ARRAY_SIZE(fb_modedb),
+};
+
+static struct physmap_flash_data vpr200_flash_data = {
+ .width = 2,
+};
+
+static struct resource vpr200_flash_resource = {
+ .start = MX35_CS0_BASE_ADDR,
+ .end = MX35_CS0_BASE_ADDR + SZ_64M - 1,
+ .flags = IORESOURCE_MEM,
+};
+
+static struct platform_device vpr200_flash = {
+ .name = "physmap-flash",
+ .id = 0,
+ .dev = {
+ .platform_data = &vpr200_flash_data,
+ },
+ .resource = &vpr200_flash_resource,
+ .num_resources = 1,
+};
+
+static const struct mxc_nand_platform_data
+ vpr200_nand_board_info __initconst = {
+ .width = 1,
+ .hw_ecc = 1,
+ .flash_bbt = 1,
+};
+
+#define VPR_KEY_DEBOUNCE 500
+static struct gpio_keys_button vpr200_gpio_keys_table[] = {
+ {KEY_F2, GPIO_BUTTON1, 1, "vpr-keys: F2", 0, VPR_KEY_DEBOUNCE},
+ {KEY_F3, GPIO_BUTTON2, 1, "vpr-keys: F3", 0, VPR_KEY_DEBOUNCE},
+ {KEY_F4, GPIO_BUTTON3, 1, "vpr-keys: F4", 0, VPR_KEY_DEBOUNCE},
+ {KEY_F5, GPIO_BUTTON4, 1, "vpr-keys: F5", 0, VPR_KEY_DEBOUNCE},
+ {KEY_F6, GPIO_BUTTON5, 1, "vpr-keys: F6", 0, VPR_KEY_DEBOUNCE},
+ {KEY_F7, GPIO_BUTTON6, 1, "vpr-keys: F7", 0, VPR_KEY_DEBOUNCE},
+ {KEY_F8, GPIO_BUTTON7, 1, "vpr-keys: F8", 1, VPR_KEY_DEBOUNCE},
+ {KEY_F9, GPIO_BUTTON8, 1, "vpr-keys: F9", 1, VPR_KEY_DEBOUNCE},
+};
+
+static struct gpio_keys_platform_data vpr200_gpio_keys_data = {
+ .buttons = vpr200_gpio_keys_table,
+ .nbuttons = ARRAY_SIZE(vpr200_gpio_keys_table),
+};
+
+static struct platform_device vpr200_device_gpiokeys = {
+ .name = "gpio-keys",
+ .dev = {
+ .platform_data = &vpr200_gpio_keys_data,
+ }
+};
+
+static struct mc13xxx_platform_data vpr200_pmic = {
+ .flags = MC13XXX_USE_ADC | MC13XXX_USE_TOUCHSCREEN,
+};
+
+static const struct imxi2c_platform_data vpr200_i2c0_data __initconst = {
+ .bitrate = 50000,
+};
+
+static struct at24_platform_data vpr200_eeprom = {
+ .byte_len = 2048 / 8,
+ .page_size = 1,
+};
+
+static struct i2c_board_info vpr200_i2c_devices[] = {
+ {
+ I2C_BOARD_INFO("at24", 0x50), /* E0=0, E1=0, E2=0 */
+ .platform_data = &vpr200_eeprom,
+ }, {
+ I2C_BOARD_INFO("mc13892", 0x08),
+ .platform_data = &vpr200_pmic,
+ .irq = gpio_to_irq(GPIO_PMIC_INT),
+ }
+};
+
+static iomux_v3_cfg_t vpr200_pads[] = {
+ /* UART1 */
+ MX35_PAD_TXD1__UART1_TXD_MUX,
+ MX35_PAD_RXD1__UART1_RXD_MUX,
+ /* UART3 */
+ MX35_PAD_ATA_DATA10__UART3_RXD_MUX,
+ MX35_PAD_ATA_DATA11__UART3_TXD_MUX,
+ /* FEC */
+ MX35_PAD_FEC_TX_CLK__FEC_TX_CLK,
+ MX35_PAD_FEC_RX_CLK__FEC_RX_CLK,
+ MX35_PAD_FEC_RX_DV__FEC_RX_DV,
+ MX35_PAD_FEC_COL__FEC_COL,
+ MX35_PAD_FEC_RDATA0__FEC_RDATA_0,
+ MX35_PAD_FEC_TDATA0__FEC_TDATA_0,
+ MX35_PAD_FEC_TX_EN__FEC_TX_EN,
+ MX35_PAD_FEC_MDC__FEC_MDC,
+ MX35_PAD_FEC_MDIO__FEC_MDIO,
+ MX35_PAD_FEC_TX_ERR__FEC_TX_ERR,
+ MX35_PAD_FEC_RX_ERR__FEC_RX_ERR,
+ MX35_PAD_FEC_CRS__FEC_CRS,
+ MX35_PAD_FEC_RDATA1__FEC_RDATA_1,
+ MX35_PAD_FEC_TDATA1__FEC_TDATA_1,
+ MX35_PAD_FEC_RDATA2__FEC_RDATA_2,
+ MX35_PAD_FEC_TDATA2__FEC_TDATA_2,
+ MX35_PAD_FEC_RDATA3__FEC_RDATA_3,
+ MX35_PAD_FEC_TDATA3__FEC_TDATA_3,
+ /* Display */
+ MX35_PAD_LD0__IPU_DISPB_DAT_0,
+ MX35_PAD_LD1__IPU_DISPB_DAT_1,
+ MX35_PAD_LD2__IPU_DISPB_DAT_2,
+ MX35_PAD_LD3__IPU_DISPB_DAT_3,
+ MX35_PAD_LD4__IPU_DISPB_DAT_4,
+ MX35_PAD_LD5__IPU_DISPB_DAT_5,
+ MX35_PAD_LD6__IPU_DISPB_DAT_6,
+ MX35_PAD_LD7__IPU_DISPB_DAT_7,
+ MX35_PAD_LD8__IPU_DISPB_DAT_8,
+ MX35_PAD_LD9__IPU_DISPB_DAT_9,
+ MX35_PAD_LD10__IPU_DISPB_DAT_10,
+ MX35_PAD_LD11__IPU_DISPB_DAT_11,
+ MX35_PAD_LD12__IPU_DISPB_DAT_12,
+ MX35_PAD_LD13__IPU_DISPB_DAT_13,
+ MX35_PAD_LD14__IPU_DISPB_DAT_14,
+ MX35_PAD_LD15__IPU_DISPB_DAT_15,
+ MX35_PAD_LD16__IPU_DISPB_DAT_16,
+ MX35_PAD_LD17__IPU_DISPB_DAT_17,
+ MX35_PAD_D3_FPSHIFT__IPU_DISPB_D3_CLK,
+ MX35_PAD_D3_DRDY__IPU_DISPB_D3_DRDY,
+ MX35_PAD_CONTRAST__IPU_DISPB_CONTR,
+ /* LCD Enable */
+ MX35_PAD_D3_VSYNC__GPIO1_2,
+ /* USBOTG */
+ MX35_PAD_USBOTG_PWR__USB_TOP_USBOTG_PWR,
+ MX35_PAD_USBOTG_OC__USB_TOP_USBOTG_OC,
+ /* SDCARD */
+ MX35_PAD_SD1_CMD__ESDHC1_CMD,
+ MX35_PAD_SD1_CLK__ESDHC1_CLK,
+ MX35_PAD_SD1_DATA0__ESDHC1_DAT0,
+ MX35_PAD_SD1_DATA1__ESDHC1_DAT1,
+ MX35_PAD_SD1_DATA2__ESDHC1_DAT2,
+ MX35_PAD_SD1_DATA3__ESDHC1_DAT3,
+ /* PMIC */
+ MX35_PAD_GPIO2_0__GPIO2_0,
+ /* GPIO keys */
+ MX35_PAD_SCKR__GPIO1_4,
+ MX35_PAD_COMPARE__GPIO1_5,
+ MX35_PAD_SCKT__GPIO1_7,
+ MX35_PAD_FST__GPIO1_8,
+ MX35_PAD_HCKT__GPIO1_9,
+ MX35_PAD_TX5_RX0__GPIO1_10,
+ MX35_PAD_TX4_RX1__GPIO1_11,
+ MX35_PAD_TX3_RX2__GPIO1_12,
+};
+
+/* USB Device config */
+static const struct fsl_usb2_platform_data otg_device_pdata __initconst = {
+ .operating_mode = FSL_USB2_DR_DEVICE,
+ .phy_mode = FSL_USB2_PHY_UTMI,
+ .workaround = FLS_USB2_WORKAROUND_ENGCM09152,
+};
+
+/* USB HOST config */
+static const struct mxc_usbh_platform_data usb_host_pdata __initconst = {
+ .portsc = MXC_EHCI_MODE_SERIAL,
+ .flags = MXC_EHCI_INTERFACE_SINGLE_UNI |
+ MXC_EHCI_INTERNAL_PHY,
+};
+
+static struct platform_device *devices[] __initdata = {
+ &vpr200_flash,
+ &vpr200_device_gpiokeys,
+};
+
+/*
+ * Board specific initialization.
+ */
+static void __init vpr200_board_init(void)
+{
+ mxc_iomux_v3_setup_multiple_pads(vpr200_pads, ARRAY_SIZE(vpr200_pads));
+
+ imx35_add_fec(NULL);
+ imx35_add_imx2_wdt(NULL);
+
+ platform_add_devices(devices, ARRAY_SIZE(devices));
+
+ if (0 != gpio_request(GPIO_LCDPWR, "LCDPWR"))
+ printk(KERN_WARNING "vpr200: Couldn't get LCDPWR gpio\n");
+ else
+ gpio_direction_output(GPIO_LCDPWR, 0);
+
+ if (0 != gpio_request(GPIO_PMIC_INT, "PMIC_INT"))
+ printk(KERN_WARNING "vpr200: Couldn't get PMIC_INT gpio\n");
+ else
+ gpio_direction_input(GPIO_PMIC_INT);
+
+ imx35_add_imx_uart0(NULL);
+ imx35_add_imx_uart2(NULL);
+
+ mxc_register_device(&mx3_ipu, &mx3_ipu_data);
+ mxc_register_device(&mx3_fb, &mx3fb_pdata);
+
+ imx35_add_fsl_usb2_udc(&otg_device_pdata);
+ imx35_add_mxc_ehci_hs(&usb_host_pdata);
+
+ imx35_add_mxc_nand(&vpr200_nand_board_info);
+ imx35_add_sdhci_esdhc_imx(0, NULL);
+
+ i2c_register_board_info(0, vpr200_i2c_devices,
+ ARRAY_SIZE(vpr200_i2c_devices));
+
+ imx35_add_imx_i2c0(&vpr200_i2c0_data);
+}
+
+static void __init vpr200_timer_init(void)
+{
+ mx35_clocks_init();
+}
+
+struct sys_timer vpr200_timer = {
+ .init = vpr200_timer_init,
+};
+
+MACHINE_START(VPR200, "VPR200")
+ /* Maintainer: Creative Product Design */
+ .map_io = mx35_map_io,
+ .init_irq = mx35_init_irq,
+ .init_machine = vpr200_board_init,
+ .timer = &vpr200_timer,
+MACHINE_END
--
1.7.1
^ permalink raw reply related
* New i.MX35 based board - VPR200, round 2
From: Marc Reilly @ 2011-01-15 0:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294962532-15790-2-git-send-email-marc@cpdesign.com.au>
Hi,
Thanks to all for their feedback. I've hopefully addressed everything
adequately.
Cheers
Marc
^ permalink raw reply
* [PATCH 4/6] dmaengine: at_hdmac: use subsys_initcall instead of module_init
From: Dan Williams @ 2011-01-15 0:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294843150-6962-3-git-send-email-nicolas.ferre@atmel.com>
On Wed, Jan 12, 2011 at 6:39 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> From: Eric Xu <hong.xu@atmel.com>
>
> Use subsys_initcall instead of module_init in order to keep DMA engine rolling
> before other peripheral drivers.
>
> Signed-off-by: Eric Xu <hong.xu@atmel.com>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
> ?drivers/dma/at_hdmac.c | ? ?2 +-
> ?1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/dma/at_hdmac.c b/drivers/dma/at_hdmac.c
> index 4f83431..a1a0fc6 100644
> --- a/drivers/dma/at_hdmac.c
> +++ b/drivers/dma/at_hdmac.c
> @@ -1209,7 +1209,7 @@ static int __init at_dma_init(void)
> ?{
> ? ? ? ?return platform_driver_probe(&at_dma_driver, at_dma_probe);
> ?}
> -module_init(at_dma_init);
> +subsys_initcall(at_dma_init);
If this matters shouldn't we also do this?
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 1b61d3a..4d14626 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -90,7 +90,7 @@ config DW_DMAC
can be integrated in chips such as the Atmel AT32ap7000.
config AT_HDMAC
- tristate "Atmel AHB DMA support"
+ bool "Atmel AHB DMA support"
depends on ARCH_AT91SAM9RL || ARCH_AT91SAM9G45
select DMA_ENGINE
help
^ permalink raw reply related
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Russell King - ARM Linux @ 2011-01-15 0:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115001254.GU4957@atomide.com>
On Fri, Jan 14, 2011 at 04:12:55PM -0800, Tony Lindgren wrote:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
> >
> > # ARMv6k
> > config CPU_32v6K
> > bool "Support ARM V6K processor extensions" if !SMP
> > depends on CPU_V6 || CPU_V7
> > default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
> >
> > OMAP2 prevents the selection of armv6k support. This is probably a very
> > bad idea if you want to run the resulting kernel on SMP hardware as it
> > removes a barrier in the spinlock code and disables the SMP-safe bitops.
>
> I have some ideas to fix this. Unfortunately it will be inefficient
> as spinlock.h can be included from modules too :( I was thinking we can
> implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm
> builds.
For spinlocks, the important thing is the barrier. The wfe/sev are an
optimization. The barrier contained with the ifdef is a valid V6
instruction.
> > The original patch which started turning this off was from the MX3 stuff,
> > but without explaination.
> >
> > However, OMAP extended this to disabling the select statement for CPU_32v6K
> > even if CPU_V7 is set:
> >
> > config CPU_V7
> > bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |- select CPU_32v6K
> > + select CPU_32v6K if !ARCH_OMAP2
> >
> > Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
> > patch should not have been merged.
>
> The only way we can fix that is do smp_on_up style rewriting of the assembly
> during init between CPUv6 and v6K. Want me to do a patch for that?
The bitops code is quite different between the two versions, and I doubt
the smp_on_up rewriting will look at all pretty. I think it needs an
alternative idea - like not using the 'byte' operations at all.
Whether we have any code which passes non-word aligned pointers to bitops
isn't particularly known - in theory they should all be unsigned long *'s,
so should be word-aligned. Who knows what filesystems do though... and
such a change could be disasterous to peoples data if the block/inode
bitmaps get corrupted.
IOW, such a change needs testing on a box where a range of filesystems are
used, and the filesystems can be thrown away if corrupted.
^ permalink raw reply
* [PATCH] dmaengine i.MX SDMA: Fix firmware loading
From: Dan Williams @ 2011-01-15 0:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294827494-15092-2-git-send-email-s.hauer@pengutronix.de>
On Wed, Jan 12, 2011 at 2:18 AM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> When loading the microcode to the SDMA engine we have to use
> the ram_code_start_addr found in the firmware image. The copy
> in the sdma engine is not initialized correctly. This is broken
> since:
> 5b28aa3 dmaengine i.MX SDMA: Allow to run without firmware
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
I'll apply this to my 'fixes' branch once I rebase on top of rc1.
--
Dan
^ permalink raw reply
* [PATCH] Fix latest regression - pgtable.h (was: [GIT PULL v3] pxa: patches for v2.6.38-rc)
From: Russell King - ARM Linux @ 2011-01-15 0:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110115000215.GS15996@n2100.arm.linux.org.uk>
On Sat, Jan 15, 2011 at 12:02:15AM +0000, Russell King - ARM Linux wrote:
> On Fri, Jan 14, 2011 at 09:49:00PM +0000, Russell King - ARM Linux wrote:
> > I also need to remove asm/pgtable.h from arch/arm/mach-pxa/generic.c:
> > CC arch/arm/mach-pxa/generic.o
> > In file included from arch/arm/include/asm/pgtable.h:461,
> > from arch/arm/mach-pxa/generic.c:26:
> > include/asm-generic/pgtable.h: In function ?ptep_test_and_clear_young?:
> > include/asm-generic/pgtable.h:29: error: dereferencing pointer to incomplete type
>
> Looking through kautobuild, it seems this also affects
> arch/arm/mach-sa1100/generic.c too, and is a recently introduced
> regression (within the last 24 hours) in mainline.
Hmm, it not only affects PXA, SA1100, but also H720x as well. Let's kill
all instances with one patch:
8<-----
Subject: [PATCH] ARM: Fix build regression on SA11x0, PXA, and H720x targets
Build errors similar this appeared in todays kautobuild for the above
targets:
In file included from arch/arm/include/asm/pgtable.h:461,
from arch/arm/mach-pxa/generic.c:26:
include/asm-generic/pgtable.h: In function 'ptep_test_and_clear_young':
include/asm-generic/pgtable.h:29: error: dereferencing pointer to incomplete type
None of the .c files including asm/pgtable.h with this error is using
this header, so simply remove the include.
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
---
arch/arm/mach-h720x/h7201-eval.c | 1 -
arch/arm/mach-h720x/h7202-eval.c | 1 -
arch/arm/mach-pxa/generic.c | 1 -
arch/arm/mach-sa1100/generic.c | 1 -
4 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-h720x/h7201-eval.c b/arch/arm/mach-h720x/h7201-eval.c
index 79f0b89..629454d 100644
--- a/arch/arm/mach-h720x/h7201-eval.c
+++ b/arch/arm/mach-h720x/h7201-eval.c
@@ -23,7 +23,6 @@
#include <asm/types.h>
#include <asm/mach-types.h>
#include <asm/page.h>
-#include <asm/pgtable.h>
#include <asm/mach/arch.h>
#include <mach/hardware.h>
#include "common.h"
diff --git a/arch/arm/mach-h720x/h7202-eval.c b/arch/arm/mach-h720x/h7202-eval.c
index cc28b1e..e9f46b6 100644
--- a/arch/arm/mach-h720x/h7202-eval.c
+++ b/arch/arm/mach-h720x/h7202-eval.c
@@ -23,7 +23,6 @@
#include <asm/types.h>
#include <asm/mach-types.h>
#include <asm/page.h>
-#include <asm/pgtable.h>
#include <asm/mach/arch.h>
#include <mach/irqs.h>
#include <mach/hardware.h>
diff --git a/arch/arm/mach-pxa/generic.c b/arch/arm/mach-pxa/generic.c
index d6e15f7..f5d91ef 100644
--- a/arch/arm/mach-pxa/generic.c
+++ b/arch/arm/mach-pxa/generic.c
@@ -22,7 +22,6 @@
#include <mach/hardware.h>
#include <asm/system.h>
-#include <asm/pgtable.h>
#include <asm/mach/map.h>
#include <asm/mach-types.h>
diff --git a/arch/arm/mach-sa1100/generic.c b/arch/arm/mach-sa1100/generic.c
index 59d14f0..e21f347 100644
--- a/arch/arm/mach-sa1100/generic.c
+++ b/arch/arm/mach-sa1100/generic.c
@@ -21,7 +21,6 @@
#include <asm/div64.h>
#include <mach/hardware.h>
#include <asm/system.h>
-#include <asm/pgtable.h>
#include <asm/mach/map.h>
#include <asm/mach/flash.h>
#include <asm/irq.h>
--
1.6.2.5
^ permalink raw reply related
* [PATCH] dmaengine: at_hdmac: use dma_address to program DMA hardware
From: Dan Williams @ 2011-01-15 0:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2B07D0.5050602@atmel.com>
On Mon, Jan 10, 2011 at 5:21 AM, Nicolas Ferre <nicolas.ferre@atmel.com> wrote:
> Le 15/12/2010 18:50, Nicolas Ferre :
>> In atc_prep_slave_sg() function we use dma_address field of scatterlist with
>> sg_dma_address() macro instead of sg_phys(). DMA address is already computed
>> by dma_map_sg() or another mapping function in calling driver.
>
> Ping?
>
Applied.
^ permalink raw reply
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Tony Lindgren @ 2011-01-15 0:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114235840.GE22505@n2100.arm.linux.org.uk>
* Russell King - ARM Linux <linux@arm.linux.org.uk> [110114 15:58]:
>
> # ARMv6k
> config CPU_32v6K
> bool "Support ARM V6K processor extensions" if !SMP
> depends on CPU_V6 || CPU_V7
> default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
>
> OMAP2 prevents the selection of armv6k support. This is probably a very
> bad idea if you want to run the resulting kernel on SMP hardware as it
> removes a barrier in the spinlock code and disables the SMP-safe bitops.
I have some ideas to fix this. Unfortunately it will be inefficient
as spinlock.h can be included from modules too :( I was thinking we can
implement dsb_sev in the proc-*.S functions for the unoptimized multi-arm
builds.
> The original patch which started turning this off was from the MX3 stuff,
> but without explaination.
>
> However, OMAP extended this to disabling the select statement for CPU_32v6K
> even if CPU_V7 is set:
>
> config CPU_V7
> bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |- select CPU_32v6K
> + select CPU_32v6K if !ARCH_OMAP2
>
> Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
> patch should not have been merged.
The only way we can fix that is do smp_on_up style rewriting of the assembly
during init between CPUv6 and v6K. Want me to do a patch for that?
For the defconfigs, I have a branch where I occasionally compile all
the old removed defconfigs too. And I believe Kevin test compiles various
PM options.
Tony
^ permalink raw reply
* [GIT PULL v3] pxa: patches for v2.6.38-rc
From: Russell King - ARM Linux @ 2011-01-15 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114214900.GP15996@n2100.arm.linux.org.uk>
On Fri, Jan 14, 2011 at 09:49:00PM +0000, Russell King - ARM Linux wrote:
> I also need to remove asm/pgtable.h from arch/arm/mach-pxa/generic.c:
> CC arch/arm/mach-pxa/generic.o
> In file included from arch/arm/include/asm/pgtable.h:461,
> from arch/arm/mach-pxa/generic.c:26:
> include/asm-generic/pgtable.h: In function ?ptep_test_and_clear_young?:
> include/asm-generic/pgtable.h:29: error: dereferencing pointer to incomplete type
Looking through kautobuild, it seems this also affects
arch/arm/mach-sa1100/generic.c too, and is a recently introduced
regression (within the last 24 hours) in mainline.
^ permalink raw reply
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Russell King - ARM Linux @ 2011-01-14 23:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.DEB.2.00.1101141551140.28621@utopia.booyaka.com>
On Fri, Jan 14, 2011 at 04:10:29PM -0700, Paul Walmsley wrote:
> I wonder if, in a similar vein, you would consider adding a CONFIG_CPU_V6
> plus CONFIG_CPU_V7 config, such as omap2plus_defconfig, into your
> compile-testing regimen, if one is not already present?
>
> That would help catch compile problems like the recent CONFIG_SWP_EMULATE
> one[1].
Such as these?
../build/msm/.config:CONFIG_CPU_V6=y
../build/omap2/.config:CONFIG_CPU_V6=y
../build/omap3/.config:CONFIG_CPU_V7=y
../build/omap3/.config:# CONFIG_SWP_EMULATE is not set
../build/omap4/.config:CONFIG_CPU_V7=y
../build/omap4/.config:# CONFIG_SWP_EMULATE is not set
../build/realview/.config:CONFIG_CPU_V6=y
../build/realview/.config:CONFIG_CPU_V7=y
../build/realview/.config:CONFIG_SWP_EMULATE=y
../build/vexpress/.config:CONFIG_CPU_V7=y
../build/vexpress/.config:CONFIG_SWP_EMULATE=y
So, I already have configs for V7 only+SWP_EMULATE=y, V7 only+SWP_EMULATE=n,
V6 only, V6+V7+SWP_EMULATE=y but not V6+V7+SWP_EMULATE=n
It doesn't appear for me because my toolchain new enough to be broken.
What has been merged into the toolchain (gcc emitting a .armv7 at the
beginning of its assembler output) was a pretty stupid idea as it's
going to break _everything_ out there which has been carefully crafted
to compile for ARMv6 but selectively use ARMv7 instructions.
I am very much of the opinion that this new "feature" needs to be removed
from the toolchain, and it should do as previous versions of the toolchain
does - where the gcc frontend passes the correct architecture flags to
the assembler.
This "feature" will have broken a lot more than just the SWP emulate code
in the kernel - anything which tries to build a kernel crossing several
CPU architectures will hit this failure.
This is what I get from building the realview configuration listed above:
$ emake O=../build/realview/ arch/arm/kernel/
Using /home/rmk/git/linux-2.6-rmk as source for kernel
GEN /home/rmk/git/build/realview/Makefile
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[2]: `include/generated/mach-types.h' is up to date.
CALL /home/rmk/git/linux-2.6-rmk/scripts/checksyscalls.sh
CC arch/arm/kernel/elf.o
AS arch/arm/kernel/entry-armv.o
AS arch/arm/kernel/entry-common.o
CC arch/arm/kernel/irq.o
CC arch/arm/kernel/process.o
CC arch/arm/kernel/ptrace.o
CC arch/arm/kernel/return_address.o
CC arch/arm/kernel/setup.o
CC arch/arm/kernel/signal.o
CC arch/arm/kernel/sys_arm.o
CC arch/arm/kernel/stacktrace.o
CC arch/arm/kernel/time.o
CC arch/arm/kernel/traps.o
CC arch/arm/kernel/compat.o
CC arch/arm/kernel/leds.o
CC arch/arm/kernel/armksyms.o
CC arch/arm/kernel/module.o
CC arch/arm/kernel/sched_clock.o
CC arch/arm/kernel/smp.o
CC arch/arm/kernel/smp_tlb.o
CC arch/arm/kernel/smp_scu.o
CC arch/arm/kernel/smp_twd.o
CC arch/arm/kernel/sys_oabi-compat.o
CC arch/arm/kernel/swp_emulate.o
CC arch/arm/kernel/hw_breakpoint.o
CC arch/arm/kernel/pmu.o
CC arch/arm/kernel/perf_event.o
CC arch/arm/kernel/io.o
AS arch/arm/kernel/debug.o
LD arch/arm/kernel/built-in.o
AS arch/arm/kernel/head.o
CC arch/arm/kernel/init_task.o
LDS arch/arm/kernel/vmlinux.lds
So, as you can see, it builds perfectly fine for me. GCC 4.3.5,
binutils 2.19.1. The command used to build swp_emulate.o was:
arm-linux-gcc -Wp,-MD,arch/arm/kernel/.swp_emulate.o.d -nostdinc
-isystem /usr/local/aeabi/lib/gcc/arm-linux/4.3.5/include
-I/home/rmk/git/linux-2.6-rmk/arch/arm/include -Iinclude
-I/home/rmk/git/linux-2.6-rmk/include -include include/generated/autoconf.h
-I/home/rmk/git/linux-2.6-rmk/arch/arm/kernel -Iarch/arm/kernel
-D__KERNEL__ -mlittle-endian
-I/home/rmk/git/linux-2.6-rmk/arch/arm/mach-realview/include
-I/home/rmk/git/linux-2.6-rmk/arch/arm/plat-versatile/include
-Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-fno-strict-aliasing -fno-common -Werror-implicit-function-declaration
-Wno-format-security -fno-delete-null-pointer-checks -O2 -marm
-fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=aapcs-linux
-mno-thumb-interwork -D__LINUX_ARM_ARCH__=6 -march=armv6k -mtune=arm1136j-s
-msoft-float -Uarm -fno-stack-protector -fno-omit-frame-pointer
-fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign
-fno-strict-overflow -Wa,-march=armv7-a
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(swp_emulate)"
-D"KBUILD_MODNAME=KBUILD_STR(swp_emulate)"
-c -o arch/arm/kernel/swp_emulate.o
/home/rmk/git/linux-2.6-rmk/arch/arm/kernel/swp_emulate.c
So, the reason I don't see it is because I don't build the omap2plus_defconfig
build, as:
# ARMv6k
config CPU_32v6K
bool "Support ARM V6K processor extensions" if !SMP
depends on CPU_V6 || CPU_V7
default y if SMP && !(ARCH_MX3 || ARCH_OMAP2)
OMAP2 prevents the selection of armv6k support. This is probably a very
bad idea if you want to run the resulting kernel on SMP hardware as it
removes a barrier in the spinlock code and disables the SMP-safe bitops.
The original patch which started turning this off was from the MX3 stuff,
but without explaination.
However, OMAP extended this to disabling the select statement for CPU_32v6K
even if CPU_V7 is set:
config CPU_V7
bool "Support ARM V7 processor" if ARCH_INTEGRATOR || MACH_REALVIEW_EB |- select CPU_32v6K
+ select CPU_32v6K if !ARCH_OMAP2
Arguably, SMP _requires_ CPU_32v6K to be enabled for a safe kernel, and this
patch should not have been merged.
^ permalink raw reply
* [PATCH] Introduce VPR200 board.
From: Marc Reilly @ 2011-01-14 23:50 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114101820.GH24920@pengutronix.de>
On Friday, January 14, 2011 09:18:20 pm Uwe Kleine-K?nig wrote:
> Hi Wolfram,
>
> On Fri, Jan 14, 2011 at 11:06:40AM +0100, Wolfram Sang wrote:
> > > And to do it really correct, you need to check for errors returned by
> > > gpio_request and gpio_direction_input.
> > >
> > > Provided you really need it, I'd do it as follows:
> > > int ret;
> > >
> > > #define setup_for_gpiokey(nr) \
> > >
> > > ret = gpio_request(GPIO_BUTTON ## nr, "BUTTON" #nr); \
> > > if (ret) \
> > >
> > > return ret; \
> > >
> > > ret = gpio_direction_input(GPIO_BUTTON ## nr); \
> > > if (ret) \
> > >
> > > return ret; \
> > >
> > > gpio_free(GPIO_BUTTON ## nr);
> > >
> > > setup_for_gpiokey(1);
> > > setup_for_gpiokey(2);
> > > setup_for_gpiokey(3);
> > > setup_for_gpiokey(4);
> > > ...
> >
> > I'd think using gpio_request_array() is the better option ;)
>
> didn't know that one, nice.
Thanks to all for comments on this, but as Uwe and Jamie pointed out, all of
this is actually taken care of by the driver, so it can all go.
Cheers
Marc
^ permalink raw reply
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Paul Walmsley @ 2011-01-14 23:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110114212027.GD22505@n2100.arm.linux.org.uk>
On Fri, 14 Jan 2011, Russell King - ARM Linux wrote:
> If it helps, here's what I do - not only do I run a few of the standard
> defconfigs in the tree, but I also run a number of platform specific
> builds, both covering platforms I do and do not have. I'll pick a random
> selection of existing build trees to rebuild and see what the results are.
> This shows the spread of trees which I've built over the last year - and
> note that many of these I don't even have:
>
> drwxrwxr-x. 20 rmk rmk 4096 Jan 14 20:30 omap4
> drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:45 versatile
> drwxrwxr-x. 21 rmk rmk 4096 Jan 14 11:14 iop13xx
> drwxrwxr-x. 20 rmk rmk 4096 Jan 13 23:10 vexpress
> drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:48 integrator
> drwxrwxr-x. 21 rmk rmk 4096 Jan 11 13:44 realview
> drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:10 assabet
> drwxrwxr-x. 21 rmk rmk 4096 Jan 8 11:07 rpc
> drwxrwxr-x. 21 rmk rmk 4096 Jan 7 17:34 omap3
> drwxrwxr-x. 20 rmk rmk 4096 Jan 6 14:24 nommu
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:44 omap2
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:27 omap
> drwxrwxr-x. 21 rmk rmk 4096 Jan 6 10:24 u300
> drwxrwxr-x. 21 rmk rmk 4096 Jan 5 19:14 pxa
> drwxrwxr-x. 21 rmk rmk 4096 Jan 5 10:30 msm
> drwxrwxr-x. 21 rmk rmk 4096 Jan 4 17:25 orion-kirkwood
> drwxrwxr-x. 21 rmk rmk 4096 Dec 24 11:06 ks8695
> drwxrwxr-x. 21 rmk rmk 4096 Dec 16 16:12 s3c2410
> drwxrwxr-x. 21 rmk rmk 4096 Dec 11 17:17 ixp4xx
> drwxrwxr-x. 20 rmk rmk 4096 Oct 9 22:59 netwinder2
> drwxrwxr-x. 21 rmk rmk 4096 Sep 5 23:54 ebsa285
> drwxrwxr-x. 21 rmk rmk 4096 Aug 4 2010 zylonite
> drwxrwxr-x. 21 rmk rmk 4096 Jul 8 2010 ep93xx
> drwxrwxr-x. 21 rmk rmk 4096 Jun 29 2010 corgi
> drwxrwxr-x. 21 rmk rmk 4096 Apr 25 2010 ebsa110
> drwxrwxr-x. 21 rmk rmk 4096 Mar 25 2010 clps711x
> drwxrwxr-x. 21 rmk rmk 4096 Mar 24 2010 ixp23xx
> drwxrwxr-x. 21 rmk rmk 4096 Mar 20 2010 n2100
> drwxrwxr-x. 21 rmk rmk 4096 Feb 19 2010 iop32x
> drwxrwxr-x. 21 rmk rmk 4096 Jan 20 2010 mx1
> drwxrwxr-x. 21 rmk rmk 4096 Jan 10 2010 w90p910evb
>
> omap4 = 4430SDP only (I have).
> omap3 = 3430LDP (I have) + 3430SDP + RX51 (I don't)
> omap2 = H2 (whose config can be traced to 2005 from when I once had one.)
> omap = some random omap1 config
> realview = realview eb/smp only
> assabet = assabet+neponset daugter board
>
> All those are build trees, built from my git tree with:
> make ARCH=arm CROSS_COMPILE=arm-linux- O=../build/$tree <args>
>
> You can see from the above that I built a kernel for at least orion-kirkwood,
> msm, u300, omap, nommu trees before sending my pull to Linus on the 6th,
> none of which I have (ever) had hardware for. I also built omap3, omap4,
> and a bunch of the ARM evaluation platforms as well as older platforms
> like RiscPC, but those are hidden by later re-builds for work I've been
> doing since (which is all based upon commit 9e9bc97.)
>
> I'm not saying that's perfect - it isn't. It's better than just testing
> the defconfigs - and with regular checking of kautobuild/linux-next, it
> seems to catch quite a bit of really silly stuff.
I wonder if, in a similar vein, you would consider adding a CONFIG_CPU_V6
plus CONFIG_CPU_V7 config, such as omap2plus_defconfig, into your
compile-testing regimen, if one is not already present?
That would help catch compile problems like the recent CONFIG_SWP_EMULATE
one[1].
- Paul
1. _linux-next: omap2plus_defconfig not building_. linux-arm-kernel
mailing list thread, started 19 October 2010 by Anand Gadiyar.
http://comments.gmane.org/gmane.linux.ports.arm.kernel/93694
^ permalink raw reply
* mmci: U300 "sync with blockend" broken for multi-block?
From: Russell King - ARM Linux @ 2011-01-14 22:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTim4J8xrj9axhsu4=_7YkEy_ndiJ6cjDNf2WfzEg@mail.gmail.com>
On Fri, Jan 14, 2011 at 09:13:05PM +0100, Linus Walleij wrote:
> 2011/1/5 Russell King - ARM Linux <linux@arm.linux.org.uk>:
>
> > Any chance of pr_debug'ing the complete status register each time you
> > service an interrupt? ?You'll probably need to set the kernel log
> > buffer fairly large to ensure that you capture everything.
>
> I did this test now.
Just to complete the picture, can I see the patch between the version
which produced this and mainline?
^ 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