* [PATCH v5 3/3] omap3: beaglexm: fix power on of DVI
From: Tony Lindgren @ 2011-01-12 0:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D2CEDD7.4020507@ti.com>
* Nishanth Menon <nm@ti.com> [110111 15:54]:
> Tony Lindgren had written, on 01/11/2011 05:23 PM, the following:
> [..]
> >>-
> >>- gpio_request(gpio + 1, "EHCI_nOC");
> >>- gpio_direction_input(gpio + 1);
> >>+ if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
> >>+ gpio_request(gpio + 1, "EHCI_nOC");
> >>+ gpio_direction_input(gpio + 1);
> >>+ }
> >
> >The return value for gpio_request must be checked.
> Ack.
> we can go down two paths:
> a) I can redo this patch as in v6.patch (attached)
Yes let's do that, one comment below though..
> OR
> b) we take this patch and do another one cleaning the function up -
> gpio-check.patch
That can be done later.
> + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
> + r = gpio_request(gpio + 1, "nDVI_PWR_EN");
> + if (!r) {
> + r = gpio_direction_output(gpio + 1, 0);
> + if (r)
> + gpio_free(gpio + 1);
> + }
> + if (r)
> + pr_err("%s: unable to configure nDVI_PWR_EN\n",
> + __func__);
> + r = gpio_request(gpio + 2, "DVI_LDO_EN");
> + if (!r) {
> + r = gpio_direction_output(gpio + 2, 1);
> + if (r)
> + gpio_free(gpio + 1);
> + }
> + if (r)
> + pr_err("%s: unable to configure DVI_LDO_EN\n",
> + __func__);
> + }
> +
Should the second gpio_free be gpio + 2 instead of gpio + 1?
Tony
^ permalink raw reply
* [PATCH] ARM: Thumb-2: Fix out-of-range offset for Thumb-2 in proc-v7.S
From: Dave Martin @ 2011-01-12 0:03 UTC (permalink / raw)
To: linux-arm-kernel
The following patch introduces a pre-increment addressing
offset which is out of range for Thumb-2:
ARM: pgtable: switch order of Linux vs hardware page tables
162: str r3, [r0, #2048]!
Thumb-2 only permits offsets <256 for pre-increment addressing.
This patch replaces the store instruction with a suitable add-str
pair for the Thumb-2 case.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
KernelVersion: v2.6.37
arch/arm/mm/proc-v7.S | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index b49fab2..0c1172b 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -159,7 +159,9 @@ ENTRY(cpu_v7_set_pte_ext)
tstne r1, #L_PTE_PRESENT
moveq r3, #0
- str r3, [r0, #2048]!
+ ARM( str r3, [r0, #2048]! )
+ THUMB( add r0, r0, #2048 )
+ THUMB( str r3, [r0] )
mcr p15, 0, r0, c7, c10, 1 @ flush_pte
#endif
mov pc, lr
--
1.7.1
^ permalink raw reply related
* [PATCH 1/1] ARM: Thumb-2: Symbol manipulation macros for function body copying
From: Dave Martin @ 2011-01-12 0:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294790551-17069-1-git-send-email-dave.martin@linaro.org>
In low-level board support code, there is sometimes a need to
copy a function body to another location at run-time.
A straightforward call to memcpy doesn't work in Thumb-2,
because bit 0 of external Thumb function symbols is set to 1,
indicating that the function is Thumb. Without corrective
measures, this will cause an off-by-one copy, and the copy
may be called using the wrong instruction set.
This patch adds macros to help with such cases.
Particular care is needed, because C doesn't guarantee any
defined behaviour when casting a function pointer to any other
type. This has been observed to lead to strange optimisation
side-effects when doing the arithmetic which is required in
order to copy/move function bodies correctly in Thumb-2.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
KernelVersion: next-20110111
arch/arm/include/asm/unified.h | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
index bc63116..636a765 100644
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -24,6 +24,32 @@
.syntax unified
#endif
+#ifndef __ASSEMBLY__
+#include <linux/types.h>
+#define __funcp_to_uint(funcp) ({ \
+ uintptr_t __result; \
+ \
+ asm("" : "=r" (__result) : "0" (funcp)); \
+ __result; \
+ })
+#define __uint_to_funcp(i, funcp) ({ \
+ typeof(funcp) __result; \
+ \
+ asm("" : "=r" (__result) : "0" (i)); \
+ __result; \
+ })
+#define FSYM_REBASE(funcp, dest_buf) \
+ __uint_to_funcp((uintptr_t)(dest_buf) | FSYM_TYPE(funcp), funcp)
+
+#ifdef CONFIG_THUMB2_KERNEL
+#define FSYM_BASE(funcp) ((void *)(__funcp_to_uint(funcp) & ~(uintptr_t)1))
+#define FSYM_TYPE(funcp) (__funcp_to_uint(funcp) & 1)
+#else /* !CONFIG_THUMB2_KERNEL */
+#define FSYM_BASE(funcp) ((void *)__funcp_to_uint(funcp))
+#define FSYM_TYPE(funcp) 0
+#endif /* !CONFIG_THUMB2_KERNEL */
+#endif /* !__ASSEMBLY__ */
+
#ifdef CONFIG_THUMB2_KERNEL
#if __GNUC__ < 4
--
1.7.1
^ permalink raw reply related
* [PATCH 0/0] RFC: ARM: Thumb-2: Symbol manipulation macros for function body copying
From: Dave Martin @ 2011-01-12 0:02 UTC (permalink / raw)
To: linux-arm-kernel
For at least one board (omap3), some functions are copied from
their link-time location into other memory at run-time.
This is a plausible thing to do if, for example, the board
might need to do something like manipulating the SDRAM
controller configuration during power management operations.
Such code may not be able to execute from the SDRAM itself.
In Thumb-2, copying function bodies is not straightforward:
for Thumb symbols, bit 0 is set by the toolchain, and so
a function symbol can't be used directly as a base address
for memcpy: this leads to an off-by-one error, resulting in
garbage instructions in the destination buffer.
The obvious solution is to mask off this bit when calling
memcpy() and then insert the bit into the address of the
target buffer, in order to derive a pointer which can be
used to call the copied function in the correct instruction
set. However, in practice the compiler may optimise this
operation away. This seems wrong, but having discussed this
with compiler folks I believe it's not a compiler bug: rather,
C doesn't specifiy what happens when casting function pointers
and attempting to do arithmetic on them. So some surprising
optimisations can happen.
To make it easier to deal with cases like this, I've had a
go at writing some macros to make copying function bodies
easier, while being robust for ARM and Thumb-2.
In particular, the required type-casts are implemented as
empty asm() blocks, to ensure that the compiler makes no
assumptions about the result.
These macros just help with the address manipulations: e.g.:
extern int scary_function(int a, char *b);
extern const int size_of_scary_function;
extern void *scary_memory_buf;
int (*runtime_scary_function)(int a, char *b);
runtime_scary_function = FSYM_REBASE(
scary_function,
memcpy(scary_memory_buf, FSYM_BASE(scary_function),
size_of_scary_function));
This is quite a lot more readable than the explicit code,
and gives the correct result (modulo bugs in my patch...)
It's still necessary to do the appropriate cache-flushing
before runtime_scary_function is actually called. Also,
it's not possible to determine the size of a function from
C code. This must be done by other means, such as adding
extra symbols in the assembler code where scary_function is
defined.
I can't comment on how widespread the requirement for function
body copying is in the arch/arm/ tree, however.
Signed-off-by: Dave Martin <dave.martin@linaro.org>
---
KernelVersion: next-20110111
arch/arm/include/asm/unified.h | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/arch/arm/include/asm/unified.h b/arch/arm/include/asm/unified.h
index bc63116..636a765 100644
--- a/arch/arm/include/asm/unified.h
+++ b/arch/arm/include/asm/unified.h
@@ -24,6 +24,32 @@
.syntax unified
#endif
+#ifndef __ASSEMBLY__
+#include <linux/types.h>
+#define __funcp_to_uint(funcp) ({ \
+ uintptr_t __result; \
+ \
+ asm("" : "=r" (__result) : "0" (funcp)); \
+ __result; \
+ })
+#define __uint_to_funcp(i, funcp) ({ \
+ typeof(funcp) __result; \
+ \
+ asm("" : "=r" (__result) : "0" (i)); \
+ __result; \
+ })
+#define FSYM_REBASE(funcp, dest_buf) \
+ __uint_to_funcp((uintptr_t)(dest_buf) | FSYM_TYPE(funcp), funcp)
+
+#ifdef CONFIG_THUMB2_KERNEL
+#define FSYM_BASE(funcp) ((void *)(__funcp_to_uint(funcp) & ~(uintptr_t)1))
+#define FSYM_TYPE(funcp) (__funcp_to_uint(funcp) & 1)
+#else /* !CONFIG_THUMB2_KERNEL */
+#define FSYM_BASE(funcp) ((void *)__funcp_to_uint(funcp))
+#define FSYM_TYPE(funcp) 0
+#endif /* !CONFIG_THUMB2_KERNEL */
+#endif /* !__ASSEMBLY__ */
+
#ifdef CONFIG_THUMB2_KERNEL
#if __GNUC__ < 4
--
1.7.1
*** BLURB HERE ***
Dave Martin (1):
ARM: Thumb-2: Symbol manipulation macros for function body copying
arch/arm/include/asm/unified.h | 26 ++++++++++++++++++++++++++
1 files changed, 26 insertions(+), 0 deletions(-)
^ permalink raw reply related
* [PATCH v5 3/3] omap3: beaglexm: fix power on of DVI
From: Nishanth Menon @ 2011-01-11 23:55 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111232329.GY4957@atomide.com>
Tony Lindgren had written, on 01/11/2011 05:23 PM, the following:
[..]
>> -
>> - gpio_request(gpio + 1, "EHCI_nOC");
>> - gpio_direction_input(gpio + 1);
>> + if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
>> + gpio_request(gpio + 1, "EHCI_nOC");
>> + gpio_direction_input(gpio + 1);
>> + }
>
> The return value for gpio_request must be checked.
Ack.
we can go down two paths:
a) I can redo this patch as in v6.patch (attached)
OR
b) we take this patch and do another one cleaning the function up -
gpio-check.patch
--
Regards,
Nishanth Menon
^ permalink raw reply
* [PATCH] omap3: beagle: check gpio returns in gpio_setup
From: Nishanth Menon @ 2011-01-11 23:51 UTC (permalink / raw)
To: linux-arm-kernel
gpio request and set of directions need checks of return value
to ensure that operation succeeded or not.
Signed-off-by: Nishanth Menon <nm@ti.com>
---
arch/arm/mach-omap2/board-omap3beagle.c | 49 ++++++++++++++++++++++++-------
1 files changed, 38 insertions(+), 11 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
index 458aee4..fc598d3 100644
--- a/arch/arm/mach-omap2/board-omap3beagle.c
+++ b/arch/arm/mach-omap2/board-omap3beagle.c
@@ -273,6 +273,8 @@ static struct gpio_led gpio_leds[];
static int beagle_twl_gpio_setup(struct device *dev,
unsigned gpio, unsigned ngpio)
{
+ int r;
+
if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
mmc[0].gpio_wp = -EINVAL;
} else if ((omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_C1_3) ||
@@ -294,19 +296,29 @@ static int beagle_twl_gpio_setup(struct device *dev,
* power switch and overcurrent detect
*/
if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
- gpio_request(gpio + 1, "EHCI_nOC");
- gpio_direction_input(gpio + 1);
+ r = gpio_request(gpio + 1, "EHCI_nOC");
+ if (!r) {
+ r = gpio_direction_input(gpio + 1);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err("%s: unable to configure EHCI_nOC\n", __func__);
}
/*
* TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
* high / others active low)
*/
- gpio_request(gpio + TWL4030_GPIO_MAX, "nEN_USB_PWR");
- if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
- gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
- else
- gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ r = gpio_request(gpio + TWL4030_GPIO_MAX, "nEN_USB_PWR");
+ if (!r) {
+ if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
+ r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 1);
+ else
+ r = gpio_direction_output(gpio + TWL4030_GPIO_MAX, 0);
+ }
+ if (r)
+ pr_err("%s: unable to configure nEN_USB_PWR\n", __func__);
/* DVI reset GPIO is different between beagle revisions */
if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM)
@@ -324,12 +336,27 @@ static int beagle_twl_gpio_setup(struct device *dev,
* A2+ revisions (production): LDO (supplies DVI, serial, led blocks)
*/
if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
- gpio_request(gpio + 1, "nDVI_PWR_EN");
- gpio_direction_output(gpio + 1, 0);
- gpio_request(gpio + 2, "DVI_LDO_EN");
- gpio_direction_output(gpio + 2, 1);
+ r = gpio_request(gpio + 1, "nDVI_PWR_EN");
+ if (!r) {
+ r = gpio_direction_output(gpio + 1, 0);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err("%s: unable to configure nDVI_PWR_EN\n",
+ __func__);
+ r = gpio_request(gpio + 2, "DVI_LDO_EN");
+ if (!r) {
+ r = gpio_direction_output(gpio + 2, 1);
+ if (r)
+ gpio_free(gpio + 1);
+ }
+ if (r)
+ pr_err("%s: unable to configure DVI_LDO_EN\n",
+ __func__);
}
+
return 0;
}
--
1.6.3.3
--------------030608000406040903000005--
^ permalink raw reply related
* [PATCH v2] ARM: Change misleading warning when CONFIG_CMDLINE_FORCE is used
From: Alexander Holler @ 2011-01-11 23:45 UTC (permalink / raw)
To: linux-arm-kernel
When CONFIG_CMDLINE_FORCE is used, the warning
Ignoring unrecognised tag 0x54410009
was displayed. Change this to
Ignoring tag cmdline (using the default kernel command line)
Signed-off-by: Alexander Holler <holler@ahsoftware.de>
---
arch/arm/kernel/setup.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
index 336f14e..eed2425 100644
--- a/arch/arm/kernel/setup.c
+++ b/arch/arm/kernel/setup.c
@@ -649,15 +649,17 @@ static int __init parse_tag_revision(const struct tag *tag)
__tagtable(ATAG_REVISION, parse_tag_revision);
-#ifndef CONFIG_CMDLINE_FORCE
static int __init parse_tag_cmdline(const struct tag *tag)
{
+#ifndef CONFIG_CMDLINE_FORCE
strlcpy(default_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
+#else
+ pr_warning("Ignoring tag cmdline (using the default kernel command line)\n");
+#endif /* CONFIG_CMDLINE_FORCE */
return 0;
}
__tagtable(ATAG_CMDLINE, parse_tag_cmdline);
-#endif /* CONFIG_CMDLINE_FORCE */
/*
* Scan the tag table for this tag, and call its parse function.
--
1.7.3.4
^ permalink raw reply related
* [PATCH] omap3: igep3: Add omap_reserve functionality
From: Tony Lindgren @ 2011-01-11 23:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294760874-28088-1-git-send-email-eballetbo@gmail.com>
* Enric Balletbo i Serra <eballetbo@gmail.com> [110111 07:47]:
> This patch adds omap_reserve functionality to board-igep0030.c.
>
> This patch is in similar lines to commit id 71ee7dad9b6991, from
> Russell king
Applying to devel-board.
Tony
> Cc: Russell King <rmk+kernel@arm.linux.org.uk>
> Signed-off-by: Enric Balletbo i Serra <eballetbo@gmail.com>
> ---
> arch/arm/mach-omap2/board-igep0030.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-igep0030.c b/arch/arm/mach-omap2/board-igep0030.c
> index 11b944f..4dc62a9 100644
> --- a/arch/arm/mach-omap2/board-igep0030.c
> +++ b/arch/arm/mach-omap2/board-igep0030.c
> @@ -450,6 +450,7 @@ static void __init igep3_init(void)
>
> MACHINE_START(IGEP0030, "IGEP OMAP3 module")
> .boot_params = 0x80000100,
> + .reserve = omap_reserve,
> .map_io = omap3_map_io,
> .init_irq = igep3_init_irq,
> .init_machine = igep3_init,
> --
> 1.7.0.4
>
^ permalink raw reply
* [PATCH] ARM: Change misleading warning when CONFIG_CMDLINE_FORCE is used
From: Russell King - ARM Linux @ 2011-01-11 23:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294766953-6889-1-git-send-email-holler@ahsoftware.de>
On Tue, Jan 11, 2011 at 06:29:13PM +0100, Alexander Holler wrote:
> +#else
> + printk(KERN_WARNING
> + "Ignoring tag cmdline"
> + " (using the default kernel command line)\n");
In addition to Jamey's comment, we do have a set of pr_xxx helpers:
pr_warning("Ignoring tag cmdline (using the default kernel command line)\n");
which I think is neater.
^ permalink raw reply
* [PATCH v5 3/3] omap3: beaglexm: fix power on of DVI
From: Tony Lindgren @ 2011-01-11 23:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294766017-12182-4-git-send-email-nm@ti.com>
* Nishanth Menon <nm@ti.com> [110111 09:12]:
> From: Koen Kooi <koen@beagleboard.org>
>
> TFP410 DVI chip is used to provide display out.
> This chip is controlled by 2 lines:
> LDO which supplies the power is controlled over gpio + 2
> and the enable of the chip itself is done over gpio + 1
> NOTE: the LDO is necessary for LED, serial blocks as well.
>
> gpio + 1 was used to sense USB overcurrent in vanilla beagle.
>
> Without this fix, the display would not function as the LDO
> remains shut down.
>
> [nm at ti.com: split up, added descriptive changelogs]
> Signed-off-by: Nishanth Menon <nm@ti.com>
> Signed-off-by: Koen Kooi <koen@beagleboard.org>
> ---
> arch/arm/mach-omap2/board-omap3beagle.c | 20 +++++++++++++++++---
> 1 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap2/board-omap3beagle.c b/arch/arm/mach-omap2/board-omap3beagle.c
> index 673deb9..458aee4 100644
> --- a/arch/arm/mach-omap2/board-omap3beagle.c
> +++ b/arch/arm/mach-omap2/board-omap3beagle.c
> @@ -293,9 +293,10 @@ static int beagle_twl_gpio_setup(struct device *dev,
> /* REVISIT: need ehci-omap hooks for external VBUS
> * power switch and overcurrent detect
> */
> -
> - gpio_request(gpio + 1, "EHCI_nOC");
> - gpio_direction_input(gpio + 1);
> + if (omap3_beagle_get_rev() != OMAP3BEAGLE_BOARD_XM) {
> + gpio_request(gpio + 1, "EHCI_nOC");
> + gpio_direction_input(gpio + 1);
> + }
The return value for gpio_request must be checked.
> /*
> * TWL4030_GPIO_MAX + 0 == ledA, EHCI nEN_USB_PWR (out, XM active
> @@ -316,6 +317,19 @@ static int beagle_twl_gpio_setup(struct device *dev,
> /* TWL4030_GPIO_MAX + 1 == ledB, PMU_STAT (out, active low LED) */
> gpio_leds[2].gpio = gpio + TWL4030_GPIO_MAX + 1;
>
> + /*
> + * gpio + 1 on Xm controls the TFP410's enable line (active low)
> + * gpio + 2 control varies depending on the board rev as follows:
> + * P7/P8 revisions(prototype): Camera EN
> + * A2+ revisions (production): LDO (supplies DVI, serial, led blocks)
> + */
> + if (omap3_beagle_get_rev() == OMAP3BEAGLE_BOARD_XM) {
> + gpio_request(gpio + 1, "nDVI_PWR_EN");
> + gpio_direction_output(gpio + 1, 0);
> + gpio_request(gpio + 2, "DVI_LDO_EN");
> + gpio_direction_output(gpio + 2, 1);
> + }
> +
> return 0;
> }
Here too. I've applied the first two patches into devel-board branch,
but not this one.
Regards,
Tony
^ permalink raw reply
* [PATCH] MMCI: don't read command response when invalid
From: Chris Ball @ 2011-01-11 23:20 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111163556.GA18746@n2100.arm.linux.org.uk>
Hi,
On Tue, Jan 11, 2011 at 04:35:56PM +0000, Russell King - ARM Linux wrote:
> Don't read the command response from the registers when either the
> command timed out (because there was no response from the card) or
> the checksum on the response was invalid.
>
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> ---
> drivers/mmc/host/mmci.c | 10 +++++-----
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
> index 5630228..040de4f 100644
> --- a/drivers/mmc/host/mmci.c
> +++ b/drivers/mmc/host/mmci.c
> @@ -394,15 +394,15 @@ mmci_cmd_irq(struct mmci_host *host, struct mmc_command *cmd,
>
> host->cmd = NULL;
>
> - cmd->resp[0] = readl(base + MMCIRESPONSE0);
> - cmd->resp[1] = readl(base + MMCIRESPONSE1);
> - cmd->resp[2] = readl(base + MMCIRESPONSE2);
> - cmd->resp[3] = readl(base + MMCIRESPONSE3);
> -
> if (status & MCI_CMDTIMEOUT) {
> cmd->error = -ETIMEDOUT;
> } else if (status & MCI_CMDCRCFAIL && cmd->flags & MMC_RSP_CRC) {
> cmd->error = -EILSEQ;
> + } else {
> + cmd->resp[0] = readl(base + MMCIRESPONSE0);
> + cmd->resp[1] = readl(base + MMCIRESPONSE1);
> + cmd->resp[2] = readl(base + MMCIRESPONSE2);
> + cmd->resp[3] = readl(base + MMCIRESPONSE3);
> }
>
> if (!cmd->data || cmd->error) {
Thanks, pushed to mmc-next and queued as a .38 fix.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* [PATCH] ARM: Change misleading warning when CONFIG_CMDLINE_FORCE is used
From: Jamie Iles @ 2011-01-11 23:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294766953-6889-1-git-send-email-holler@ahsoftware.de>
Hi Alexander,
On Tue, Jan 11, 2011 at 06:29:13PM +0100, Alexander Holler wrote:
> When CONFIG_CMDLINE_FORCE is used, the warning
>
> Ignoring unrecognised tag 0x54410009
>
> was displayed. Change this to
>
> Ignoring tag cmdline (using the default kernel command line)
>
> Signed-off-by: Alexander Holler <holler@ahsoftware.de>
> ---
> arch/arm/kernel/setup.c | 8 ++++++--
> 1 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 336f14e..19c0e96 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -649,15 +649,19 @@ static int __init parse_tag_revision(const struct tag *tag)
>
> __tagtable(ATAG_REVISION, parse_tag_revision);
>
> -#ifndef CONFIG_CMDLINE_FORCE
> static int __init parse_tag_cmdline(const struct tag *tag)
> {
> +#ifndef CONFIG_CMDLINE_FORCE
> strlcpy(default_command_line, tag->u.cmdline.cmdline, COMMAND_LINE_SIZE);
> +#else
> + printk(KERN_WARNING
> + "Ignoring tag cmdline"
> + " (using the default kernel command line)\n");
> +#endif /* CONFIG_CMDLINE_FORCE */
For strings in a printk() like this you don't need to split them to keep
them under 80 characters. This makes it harder to grep for so it's fine
(and preferred) to keep this on a single line.
Jamie
^ permalink raw reply
* [PATCH 5/5 v2] ARM: pxa: Fix recursive call of pxa_(un)mask_low_gpio()
From: Eric Miao @ 2011-01-11 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294699993-4712-5-git-send-email-marek.vasut@gmail.com>
The original intention is to re-use pxa_{mask,unmask}_irq(), will
the change below looks better? The move of irq_base() is to avoid
the error of function not declared.
diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
index a7deff5..6107253 100644
--- a/arch/arm/mach-pxa/irq.c
+++ b/arch/arm/mach-pxa/irq.c
@@ -53,6 +53,17 @@ static inline int cpu_has_ipr(void)
return !cpu_is_pxa25x();
}
+static inline void __iomem *irq_base(int i)
+{
+ static unsigned long phys_base[] = {
+ 0x40d00000,
+ 0x40d0009c,
+ 0x40d00130,
+ };
+
+ return (void __iomem *)io_p2v(phys_base[i]);
+}
+
static void pxa_mask_irq(unsigned int irq)
{
void __iomem *base = get_irq_chip_data(irq);
@@ -108,25 +119,11 @@ static void pxa_ack_low_gpio(unsigned int irq)
GEDR0 = (1 << (irq - IRQ_GPIO0));
}
-static void pxa_mask_low_gpio(unsigned int irq)
-{
- struct irq_desc *desc = irq_to_desc(irq);
-
- desc->chip->mask(irq);
-}
-
-static void pxa_unmask_low_gpio(unsigned int irq)
-{
- struct irq_desc *desc = irq_to_desc(irq);
-
- desc->chip->unmask(irq);
-}
-
static struct irq_chip pxa_low_gpio_chip = {
.name = "GPIO-l",
.ack = pxa_ack_low_gpio,
- .mask = pxa_mask_low_gpio,
- .unmask = pxa_unmask_low_gpio,
+ .mask = pxa_mask_irq,
+ .unmask = pxa_unmask_irq,
.set_type = pxa_set_low_gpio_type,
};
@@ -141,6 +138,7 @@ static void __init pxa_init_low_gpio_irq(set_wake_t fn)
for (irq = IRQ_GPIO0; irq <= IRQ_GPIO1; irq++) {
set_irq_chip(irq, &pxa_low_gpio_chip);
+ set_irq_chip_data(irq, irq_base(0));
set_irq_handler(irq, handle_edge_irq);
set_irq_flags(irq, IRQF_VALID);
}
@@ -148,17 +146,6 @@ static void __init pxa_init_low_gpio_irq(set_wake_t fn)
pxa_low_gpio_chip.set_wake = fn;
}
-static inline void __iomem *irq_base(int i)
-{
- static unsigned long phys_base[] = {
- 0x40d00000,
- 0x40d0009c,
- 0x40d00130,
- };
-
- return (void __iomem *)io_p2v(phys_base[i]);
-}
-
void __init pxa_init_irq(int irq_nr, set_wake_t fn)
{
int irq, i, n;
On Mon, Jan 10, 2011 at 4:53 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> ---
> v2: Remove dead code as proposed by Sergei
>
> ?arch/arm/mach-pxa/irq.c | ? ?8 ++------
> ?1 files changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
> index a7deff5..76e69cf 100644
> --- a/arch/arm/mach-pxa/irq.c
> +++ b/arch/arm/mach-pxa/irq.c
> @@ -110,16 +110,12 @@ static void pxa_ack_low_gpio(unsigned int irq)
>
> ?static void pxa_mask_low_gpio(unsigned int irq)
> ?{
> - ? ? ? struct irq_desc *desc = irq_to_desc(irq);
> -
> - ? ? ? desc->chip->mask(irq);
> + ? ? ? pxa_mask_irq(irq);
> ?}
>
> ?static void pxa_unmask_low_gpio(unsigned int irq)
> ?{
> - ? ? ? struct irq_desc *desc = irq_to_desc(irq);
> -
> - ? ? ? desc->chip->unmask(irq);
> + ? ? ? pxa_unmask_irq(irq);
> ?}
>
> ?static struct irq_chip pxa_low_gpio_chip = {
> --
> 1.7.2.3
>
>
^ permalink raw reply related
* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Tony Lindgren @ 2011-01-11 23:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110110185209.GC4957@atomide.com>
* Tony Lindgren <tony@atomide.com> [110110 10:51]:
> * Russell King - ARM Linux <linux@arm.linux.org.uk> [110107 08:12]:
> > On Thu, Jan 06, 2011 at 12:40:54PM -0800, Tony Lindgren wrote:
> > > Anyways, I can debug the DEBUG_LL booting issue further if the patch
> > > I posted does not help.
> >
> > This is what I ended up with earlier today to make the debug code work
> > both in the decompressor and in the kernel - once I had it working I
> > haven't bothered putting any more effort into it.
>
> Hmm I have DEBUG_LL working fine (execept not for the uncompress code).
>
> Looks like the only issue I have with my 4430 es1.0 blaze board is
> that it won't boot reliably unless I disable l2x0_init.
>
> Have you guys seen this issue?
>
> Of course there are all kinds of omap4 warnings there, but after
> disabling l2x0_init I was able to run apt-get dist-upgrade on my
> board. This is with what I have queued up in omap-fixes.
Here's one more es1.0 fix after the recent USB changes.
Regards,
Tony
Author: Tony Lindgren <tony@atomide.com>
Date: Tue Jan 11 15:03:03 2011 -0800
omap4: Fix ULPI PHY init for ES1.0 SDP
Commit 6aa85a5ae610106d89e50c7e1f760c56d12f9bc4 (omap4: 4430sdp:
enable the ehci port on 4430SDP) added code to enable EHCI
support on 4430sdp board.
Looks like the ULPI pin does not seem to be muxed properly on ES1.0
SDP and this causes the system to reboot when the ULPI PHY is
enabled.
Fix this by muxing the pin, this is the same setting for
both ES1.0 and ES2.0. Also add checking for gpio_request.
Cc: Keshava Munegowda <keshava_mgowda at ti.com
Signed-off-by: Tony Lindgren <tony@atomide.com>
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -554,6 +554,7 @@ static void __init omap_sfh7741prox_init(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ OMAP4_MUX(USBB2_ULPITLL_CLK, OMAP_MUX_MODE4 | OMAP_PIN_OUTPUT),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
@@ -576,11 +577,12 @@ static void __init omap_4430sdp_init(void)
omap4_twl6030_hsmmc_init(mmc);
/* Power on the ULPI PHY */
- if (gpio_is_valid(OMAP4SDP_MDM_PWR_EN_GPIO)) {
- /* FIXME: Assumes pad is already muxed for GPIO mode */
- gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY VMDM_3V3");
+ status = gpio_request(OMAP4SDP_MDM_PWR_EN_GPIO, "USBB1 PHY VMDM_3V3");
+ if (status)
+ pr_err("%s: Could not get USBB1 PHY GPIO\n");
+ else
gpio_direction_output(OMAP4SDP_MDM_PWR_EN_GPIO, 1);
- }
+
usb_ehci_init(&ehci_pdata);
usb_musb_init(&musb_board_data);
^ permalink raw reply
* [PATCH 4/5 v2] ARM: pxa: Fix suspend/resume array index miscalculation
From: Eric Miao @ 2011-01-11 22:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201101110046.13141.marek.vasut@gmail.com>
On Mon, Jan 10, 2011 at 5:46 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
> On Tuesday 11 January 2011 00:41:26 Eric Miao wrote:
>> On Mon, Jan 10, 2011 at 4:53 PM, Marek Vasut <marek.vasut@gmail.com> wrote:
>> > Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
>> > ---
>> > v2: Fix loop condition as proposed by Sergei
>> >
>> > ?arch/arm/mach-pxa/irq.c | ? ?8 ++++----
>> > ?1 files changed, 4 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/arch/arm/mach-pxa/irq.c b/arch/arm/mach-pxa/irq.c
>> > index 78f0e0c..a7deff5 100644
>> > --- a/arch/arm/mach-pxa/irq.c
>> > +++ b/arch/arm/mach-pxa/irq.c
>> > @@ -156,7 +156,7 @@ static inline void __iomem *irq_base(int i)
>> > ? ? ? ? ? ? ? ?0x40d00130,
>> > ? ? ? ?};
>> >
>> > - ? ? ? return (void __iomem *)io_p2v(phys_base[i >> 5]);
>> > + ? ? ? return (void __iomem *)io_p2v(phys_base[i]);
>> > ?}
>> >
>> > ?void __init pxa_init_irq(int irq_nr, set_wake_t fn)
>> > @@ -168,7 +168,7 @@ void __init pxa_init_irq(int irq_nr, set_wake_t fn)
>> > ? ? ? ?pxa_internal_irq_nr = irq_nr;
>> >
>> > ? ? ? ?for (n = 0; n < irq_nr; n += 32) {
>> > - ? ? ? ? ? ? ? void __iomem *base = irq_base(n);
>> > + ? ? ? ? ? ? ? void __iomem *base = irq_base(n >> 5);
>> >
>> > ? ? ? ? ? ? ? ?__raw_writel(0, base + ICMR); ? /* disable all IRQs */
>> > ? ? ? ? ? ? ? ?__raw_writel(0, base + ICLR); ? /* all IRQs are IRQ, not
>> > FIQ */ @@ -200,7 +200,7 @@ static int pxa_irq_suspend(struct sys_device
>> > *dev, pm_message_t state) {
>> > ? ? ? ?int i;
>> >
>> > - ? ? ? for (i = 0; i < pxa_internal_irq_nr; i += 32) {
>> > + ? ? ? for (i = 0; i < pxa_internal_irq_nr / 32; i++) {
>> > ? ? ? ? ? ? ? ?void __iomem *base = irq_base(i);
>>
>> I prefer it to be IRQ number based instead of IRQ bank based,
>>
>> in other word, I'd rather to change the statement below:
>> > ? ? ? ? ? ? ? ?saved_icmr[i] = __raw_readl(base + ICMR);
>>
>> to something:
>>
>> saved_icmr[i / 32] = __raw_read(base + ICMR);
>
> Exactly what I wanted to avoid ... won't you be doing a division "# of bank"-
> times instead of once there ?
>
I'm fine with either way. Applied.
>>
>> > @@ -219,7 +219,7 @@ static int pxa_irq_resume(struct sys_device *dev)
>> > ?{
>> > ? ? ? ?int i;
>> >
>> > - ? ? ? for (i = 0; i < pxa_internal_irq_nr; i += 32) {
>> > + ? ? ? for (i = 0; i < pxa_internal_irq_nr / 32; i++) {
>> > ? ? ? ? ? ? ? ?void __iomem *base = irq_base(i);
>> >
>> > ? ? ? ? ? ? ? ?__raw_writel(saved_icmr[i], base + ICMR);
>> > --
>> > 1.7.2.3
>
^ permalink raw reply
* [PATCH] bitops: remove condition code clobber for CLZ
From: Nicolas Pitre @ 2011-01-11 22:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111185306.GM11039@n2100.arm.linux.org.uk>
On Tue, 11 Jan 2011, Russell King - ARM Linux wrote:
> On Tue, Jan 11, 2011 at 01:51:19PM -0500, Nicolas Pitre wrote:
> > On Tue, 11 Jan 2011, Russell King - ARM Linux wrote:
> >
> > > On Tue, Jan 11, 2011 at 11:12:05PM +0530, Rabin Vincent wrote:
> > > > The CLZ instruction does not alter the condition flags, so remove the
> > > > "cc" clobber from the inline asm for fls().
> > >
> > > Do you have any evidence that this changes anything, or is it just
> > > subjective?
> >
> > This probably doesn't change anything, as gcc has been presuming that
> > inline asms do clobber the condition code for years now, in order to
> > prevent issues caused by a lack of %? appended to instructions in order
> > to conditionally execute them otherwise. So this would only make the
> > code self consistent.
>
> So given that Linus complains about churn from ARM, what's the
> justification to apply a patch which has no effect what so ever?
Code self documentation.
If we know the inline asm is actually clobbering the condition code,
then it makes sense to list cc in the clobber list. And conversely as
well, for the benefit of those reading that code. Having cc in the
clobber list for some inline asm that does not actually clobber the
condition code is just confusing.
Nicolas
^ permalink raw reply
* [PATCH] net/fec: remove config FEC2 as it's used nowhere
From: David Miller @ 2011-01-11 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294747672-4433-1-git-send-email-shawn.guo@freescale.com>
From: Shawn Guo <shawn.guo@freescale.com>
Date: Tue, 11 Jan 2011 20:07:52 +0800
> Signed-off-by: Shawn Guo <shawn.guo@freescale.com>
Applied.
^ permalink raw reply
* [PATCH 16/16] w1: mxc_w1: don't treat NULL clk as an error
From: Russell King - ARM Linux @ 2011-01-11 21:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294749833-32019-17-git-send-email-jamie@jamieiles.com>
On Tue, Jan 11, 2011 at 12:43:53PM +0000, Jamie Iles wrote:
> clk_get() returns a struct clk cookie to the driver and some platforms
> may return NULL if they only support a single clock. clk_get() has only
> failed if it returns a ERR_PTR() encoded pointer.
Another good catch.
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
Thanks for doing this.
^ permalink raw reply
* [PATCH 09/16] ARM: pxa: don't treat NULL clk as an error
From: Russell King - ARM Linux @ 2011-01-11 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294749833-32019-10-git-send-email-jamie@jamieiles.com>
On Tue, Jan 11, 2011 at 12:43:46PM +0000, Jamie Iles wrote:
> clk_get() returns a struct clk cookie to the driver and some platforms
> may return NULL if they only support a single clock. clk_get() has only
> failed if it returns a ERR_PTR() encoded pointer.
Good catch.
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
^ permalink raw reply
* [PATCH 08/16] ARM: samsung: serial: don't treat NULL clk as an error
From: Russell King - ARM Linux @ 2011-01-11 21:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294749833-32019-9-git-send-email-jamie@jamieiles.com>
On Tue, Jan 11, 2011 at 12:43:45PM +0000, Jamie Iles wrote:
> clk_get() returns a struct clk cookie to the driver and some platforms
> may return NULL if they only support a single clock. clk_get() has only
> failed if it returns a ERR_PTR() encoded pointer.
Acked-by: Russell King <rmk+kernel@arm.linux.org.uk>
>
> Cc: Kukjin Kim <kgene.kim@samsung.com>
> Cc: linux-arm-kernel at lists.infradead.org
> Signed-off-by: Jamie Iles <jamie@jamieiles.com>
^ permalink raw reply
* [PATCH] bitops: remove condition code clobber for CLZ
From: Russell King - ARM Linux @ 2011-01-11 18:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <alpine.LFD.2.00.1101111347320.17086@xanadu.home>
On Tue, Jan 11, 2011 at 01:51:19PM -0500, Nicolas Pitre wrote:
> On Tue, 11 Jan 2011, Russell King - ARM Linux wrote:
>
> > On Tue, Jan 11, 2011 at 11:12:05PM +0530, Rabin Vincent wrote:
> > > The CLZ instruction does not alter the condition flags, so remove the
> > > "cc" clobber from the inline asm for fls().
> >
> > Do you have any evidence that this changes anything, or is it just
> > subjective?
>
> This probably doesn't change anything, as gcc has been presuming that
> inline asms do clobber the condition code for years now, in order to
> prevent issues caused by a lack of %? appended to instructions in order
> to conditionally execute them otherwise. So this would only make the
> code self consistent.
So given that Linus complains about churn from ARM, what's the
justification to apply a patch which has no effect what so ever?
^ permalink raw reply
* [PATCH] bitops: remove condition code clobber for CLZ
From: Nicolas Pitre @ 2011-01-11 18:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111183942.GL11039@n2100.arm.linux.org.uk>
On Tue, 11 Jan 2011, Russell King - ARM Linux wrote:
> On Tue, Jan 11, 2011 at 11:12:05PM +0530, Rabin Vincent wrote:
> > The CLZ instruction does not alter the condition flags, so remove the
> > "cc" clobber from the inline asm for fls().
>
> Do you have any evidence that this changes anything, or is it just
> subjective?
This probably doesn't change anything, as gcc has been presuming that
inline asms do clobber the condition code for years now, in order to
prevent issues caused by a lack of %? appended to instructions in order
to conditionally execute them otherwise. So this would only make the
code self consistent.
Nicolas
^ permalink raw reply
* [PATCH] bitops: remove condition code clobber for CLZ
From: Russell King - ARM Linux @ 2011-01-11 18:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294767725-14814-1-git-send-email-rabin@rab.in>
On Tue, Jan 11, 2011 at 11:12:05PM +0530, Rabin Vincent wrote:
> The CLZ instruction does not alter the condition flags, so remove the
> "cc" clobber from the inline asm for fls().
Do you have any evidence that this changes anything, or is it just
subjective?
^ permalink raw reply
* [PATCH 1/2] serial: Add auart driver for i.MX23/28
From: Sascha Hauer @ 2011-01-11 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110111171050.GA522@pengutronix.de>
On Tue, Jan 11, 2011 at 06:10:50PM +0100, Wolfram Sang wrote:
> On Tue, Jan 11, 2011 at 04:09:04PM +0100, Sascha Hauer wrote:
> [...]
> > +#include <asm/cacheflush.h>
> > +#include <mach/mx28.h>
>
> What about MX23 and STMP3xxx?
This include is not needed, will remove. Instead we need linux/io.h.
>
> > +
> > +#define MXS_AUART_PORTS 5
>
> MX23 has just 2. We should better adapt to that depending on the type?
This is just the maximum number the driver supports, it's safe to keep
it as is.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* [PATCH] bitops: remove condition code clobber for CLZ
From: Nicolas Pitre @ 2011-01-11 17:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1294767725-14814-1-git-send-email-rabin@rab.in>
On Tue, 11 Jan 2011, Rabin Vincent wrote:
> The CLZ instruction does not alter the condition flags, so remove the
> "cc" clobber from the inline asm for fls().
>
> Signed-off-by: Rabin Vincent <rabin@rab.in>
Acked-by: Nicolas Pitre <nicolas.pitre@linaro.org>
> ---
> arch/arm/include/asm/bitops.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/arm/include/asm/bitops.h b/arch/arm/include/asm/bitops.h
> index 338ff19..7b1bb2b 100644
> --- a/arch/arm/include/asm/bitops.h
> +++ b/arch/arm/include/asm/bitops.h
> @@ -285,7 +285,7 @@ static inline int fls(int x)
> if (__builtin_constant_p(x))
> return constant_fls(x);
>
> - asm("clz\t%0, %1" : "=r" (ret) : "r" (x) : "cc");
> + asm("clz\t%0, %1" : "=r" (ret) : "r" (x));
> ret = 32 - ret;
> return ret;
> }
> --
> 1.7.2.3
>
^ 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