* [PATCH 2/2] ARM i.MX23/28: Add framebuffer device support
From: Sascha Hauer @ 2011-02-21 14:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218093622.GE18085@S2100-06.ap.freescale.net>
On Fri, Feb 18, 2011 at 05:36:23PM +0800, Shawn Guo wrote:
> On Fri, Feb 18, 2011 at 10:26:50AM +0100, Sascha Hauer wrote:
> > On Fri, Feb 18, 2011 at 05:17:18PM +0800, Shawn Guo wrote:
> > > > > I understand that "mxsfb" was picked up for the device name to
> > > > > reflect the driver name. But since this is the device under mach- mxs
> > > > > folder, can we simply call it "fb" just like the way you name fb.h?
> > > > >
> > > > > In this way, we have all mxs platform device naming schema aligned,
> > > > > auart, duart, dma, fb, fec, flexcan, mmc ...
> > > >
> > > > I see it the other way round. mach/fb.h is too generic, I would prefer
> > > > mach/mxsfb.h to be able to add support for a different framebuffer
> > > > later. So I better change fb.h to mxsfb.h.
> > > >
> > > I'm fine with either way, but just wondering what kind of fb later
> > > it is and its naming, relatively to mxsfs.
> >
> > IPU...?
> >
> AFAICT, this is something that never going to happen.
Just the first thing that came to my mind. It could also be the lcd
controller known from i.MX1/2
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 1/2] video: Add i.MX23/28 framebuffer driver
From: Sascha Hauer @ 2011-02-21 14:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110218122946.GF18085@S2100-06.ap.freescale.net>
On Fri, Feb 18, 2011 at 08:29:47PM +0800, Shawn Guo wrote:
> > +
> > +#include <linux/kernel.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/clk.h>
> > +#include <linux/dma-mapping.h>
> > +#include <linux/io.h>
> > +#include <mach/fb.h>
> > +#include <mach/hardware.h>
> > +#include <mach/mxs.h>
> > +
> > +#define REG_SET 4
> > +#define REG_CLR 8
> > +
> We already have these defined in mxs.h
I know, but as Wolfram realized this makes the driver architecture
specific. So I decided to duplicate this here and to remove
mach/hardware.h and mach/mxs.h (obviously still present in the last
posted version)
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 v2] mxcmmc: use dmaengine API
From: Sascha Hauer @ 2011-02-21 14:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102181437.02943.arnd@arndb.de>
On Fri, Feb 18, 2011 at 02:37:02PM +0100, Arnd Bergmann wrote:
> On Friday 18 February 2011, Sascha Hauer wrote:
> > This switches the mxcmmc driver to use the dmaengine API. Unlike
> > the old one this one is always present in the tree, even if no DMA
> > is implemented, hence we can remove all the #ifdefs in from the driver.
> > The driver automatically switches to PIO mode if no DMA support or no
> > suitable channel is available.
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> The patch looks good to me, but shouldn't you also add a Kconfig
> dependency or select on CONFIG_DMA_ENGINE? I don't see where that
> gets set.
I was about to answer with a patch adding a select on CONFIG_DMA_ENGINE
but just realized this isn't necessary. Without dmaengine support
dma_request_channel becomes a static inline returning NULL. The mxcmmc
driver falls back to PIO then and still works.
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 14/17] omap4: cpuidle: Add MPUSS RET OFF states
From: Santosh Shilimkar @ 2011-02-21 14:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <6176616fe77333f80f0cfaae4fc8aff3@mail.gmail.com>
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
> Sent: Monday, February 21, 2011 3:57 PM
> To: Jean Pihet
> Cc: linux-omap at vger.kernel.org; Kevin Hilman; linux-arm-
> kernel at lists.infradead.org; Rajendra Nayak
> Subject: RE: [PATCH 14/17] omap4: cpuidle: Add MPUSS RET OFF states
>
[...]
> > I think the piece of code below is rather difficult to read and
> > understand. Based on the patch description and the comment here
> > below
> > I do not see the relation with the code.
> >
> There is relation. The comments are as per the conditions. And
> The hardware constraint is back-ground behind the conditions.
>
> > " On OMAP4 because of hardware constraints, no low power states
> are
> > targeted when both CPUs are online and in SMP mode. The low power
> > states are attempted only when secondary CPU gets offline to OFF
> > through hotplug infrastructure. "
> > The test below does not seem to match this comment.
> >
> > > + ? ? ? /*
> > > + ? ? ? ?* Special hardware/software considerations:
> > > + ? ? ? ?* 1. Do only WFI for secondary CPU(non-boot - CPU1).
> > > + ? ? ? ?* ? ?Secondary cores are taken down only via hotplug
> > path.
> > The comment looks contradictory. Which one is taken OFF using this
> > code, which one from hotplug?
> > Does this correspond to the condition '(dev->cpu)' in the test
> > below?
>
> Yes.
> >
> > > + ? ? ? ?* 2. Do only a WFI as long as in SMP mode.
> > Does this correspond to the condition '(num_online_cpus() > 1)' in
> > the
> > test below? If so it this one triggering the low power mode for
> > cpu0?
> yes
> >
> > > + ? ? ? ?* 3. Continue to do only WFI till CPU1 hits OFF state.
> > > + ? ? ? ?* ? ?This is necessary to honour hardware
> recommondation
> > > + ? ? ? ?* ? ?of triggeing all the possible low power modes once
> > CPU1 is
> > > + ? ? ? ?* ? ?out of coherency and in OFF mode.
> > Does this correspond to the condition '(cpu1_state !=
> > PWRDM_POWER_OFF)' in the test below?
> >
> Yes
>
> > > + ? ? ? ?* Update dev->last_state so that governor stats
> reflects
> > right
> > > + ? ? ? ?* data.
> > > + ? ? ? ?*/
> > > + ? ? ? cpu1_state = pwrdm_read_pwrst(cpu1_pd);
> > > + ? ? ? if ((dev->cpu) || (num_online_cpus() > 1) ||
> > > + ? ? ? ? ? ? ? ? ? ? ? (cpu1_state != PWRDM_POWER_OFF)) {
> > Are '||' correct here?
> Yes.
>
> > Sorry if the code behaves correctly, the remarks are about
> > readability especially in the comments.
> >
> You got all three correct. Instead of having three If's doing
> same thing I have merged them and added comments above.
>
> And you got all of them correctly.
>
Will add the code conditions in comments as well so that
it becomes mere readable.
^ permalink raw reply
* [PATCH V5 30/63] ST SPEAr: Replacing SIZE macro's with actual required size
From: viresh kumar @ 2011-02-21 13:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221130952.GO14495@n2100.arm.linux.org.uk>
On 2/21/11, Russell King - ARM Linux <linux@arm.linux.org.uk> wrote:
> On Mon, Feb 21, 2011 at 05:34:20PM +0530, viresh kumar wrote:
>> On 02/21/2011 05:23 PM, Russell King - ARM Linux wrote:
>> So sending only first 10 patches looks a bit insufficient to me? Would be
>> better
>> to send all of them (leaving what you have already applied), so that they
>> apply cleanly at your end.
>
> I don't know, and I'm getting to the point of giving up with this SPEAr
> stuff. It's more trouble and time consuming than it's worth because of
> the size of the patch set. It's just *too* large to properly deal with.
>
Please don't do that now. I agree that it was too big to get reviewed
and get added.
I will make it sure, that it doesn't happen again from our side. But
now lots of effort
has already been put on it, by everybody in reviewing and preparing them.
Let me check, might be only few patches are required to be resent and
others will
automatically apply over them.
--
viresh
^ permalink raw reply
* [PATCH 6/6] omap3: pm: Use exported set_cr() instead of a custom one.
From: Santosh Shilimkar @ 2011-02-21 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298294365-30770-1-git-send-email-santosh.shilimkar@ti.com>
Remove the custom restore_control_register() and use the exported
set_cr() instead to set the system control register(SCTRL) value.
No functional change.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/pm34xx.c | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/arch/arm/mach-omap2/pm34xx.c b/arch/arm/mach-omap2/pm34xx.c
index 2f864e4..63a3e1d 100644
--- a/arch/arm/mach-omap2/pm34xx.c
+++ b/arch/arm/mach-omap2/pm34xx.c
@@ -311,11 +311,6 @@ static irqreturn_t prcm_interrupt_handler (int irq, void *dev_id)
return IRQ_HANDLED;
}
-static void restore_control_register(u32 val)
-{
- __asm__ __volatile__ ("mcr p15, 0, %0, c1, c0, 0" : : "r" (val));
-}
-
/* Function to restore the table entry that was modified for enabling MMU */
static void restore_table_entry(void)
{
@@ -337,7 +332,7 @@ static void restore_table_entry(void)
control_reg_value = __raw_readl(scratchpad_address
+ OMAP343X_CONTROL_REG_VALUE_OFFSET);
/* This will enable caches and prediction */
- restore_control_register(control_reg_value);
+ set_cr(control_reg_value);
}
void omap_sram_idle(void)
--
1.6.0.4
^ permalink raw reply related
* [PATCH 5/6] omap3: pm: Clear the SCTLR C bit in asm code to prevent data cache allocation
From: Santosh Shilimkar @ 2011-02-21 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298294365-30770-1-git-send-email-santosh.shilimkar@ti.com>
On the newer ARM processors like CortexA8, CortexA9, the caches can be
speculatively loaded while they are getting flushed.
Clear the SCTLR C bit to prevent further data cache allocation as
part of cache clean routine
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/sleep34xx.S | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 28baeb2..1e723bb 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -224,6 +224,12 @@ l1_logic_lost:
mrc p15, 0, r4, c1, c0, 0 @ save control register
stmia r8!, {r4}
+ /* Clear the SCTLR C bit to prevent further data cache allocation */
+ mrc p15, 0, r0, c1, c0, 0
+ bic r0, r0, #(1 << 2) @ Disable the C bit
+ mcr p15, 0, r0, c1, c0, 0
+ isb
+
clean_caches:
/*
* jump out to kernel flush routine
@@ -270,6 +276,12 @@ omap3_do_wfi:
nop
bl wait_sdrc_ok
+ mrc p15, 0, r0, c1, c0, 0
+ tst r0, #(1 << 2) @ Check C bit enabled?
+ orreq r0, r0, #(1 << 2) @ Enable the C bit if cleared
+ mcreq p15, 0, r0, c1, c0, 0
+ isb
+
/*
* ===================================
* == Exit point from non-OFF modes ==
--
1.6.0.4
^ permalink raw reply related
* [PATCH 4/6] omap3: pm: Remove un-necessary cp15 registers form low power cpu context
From: Santosh Shilimkar @ 2011-02-21 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298294365-30770-1-git-send-email-santosh.shilimkar@ti.com>
The current code saves few un-necessary registers which are read-only or
write-only, unused CP15 registers.
Remove them and keep only necessary CP15 registers part of
low power context save/restore.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/sleep34xx.S | 156 ++++++++++-----------------------------
1 files changed, 40 insertions(+), 116 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 7442431..28baeb2 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -199,66 +199,29 @@ save_context_wfi:
beq clean_caches
l1_logic_lost:
- /* Store sp and spsr to SDRAM */
- mov r4, sp
- mrs r5, spsr
- mov r6, lr
+ mov r4, sp @ Store sp
+ mrs r5, spsr @ Store spsr
+ mov r6, lr @ Store lr
stmia r8!, {r4-r6}
- /* Save all ARM registers */
- /* Coprocessor access control register */
- mrc p15, 0, r6, c1, c0, 2
- stmia r8!, {r6}
- /* TTBR0, TTBR1 and Translation table base control */
- mrc p15, 0, r4, c2, c0, 0
- mrc p15, 0, r5, c2, c0, 1
- mrc p15, 0, r6, c2, c0, 2
- stmia r8!, {r4-r6}
- /*
- * Domain access control register, data fault status register,
- * and instruction fault status register
- */
- mrc p15, 0, r4, c3, c0, 0
- mrc p15, 0, r5, c5, c0, 0
- mrc p15, 0, r6, c5, c0, 1
- stmia r8!, {r4-r6}
- /*
- * Data aux fault status register, instruction aux fault status,
- * data fault address register and instruction fault address register
- */
- mrc p15, 0, r4, c5, c1, 0
- mrc p15, 0, r5, c5, c1, 1
- mrc p15, 0, r6, c6, c0, 0
- mrc p15, 0, r7, c6, c0, 2
- stmia r8!, {r4-r7}
- /*
- * user r/w thread and process ID, user r/o thread and process ID,
- * priv only thread and process ID, cache size selection
- */
- mrc p15, 0, r4, c13, c0, 2
- mrc p15, 0, r5, c13, c0, 3
- mrc p15, 0, r6, c13, c0, 4
- mrc p15, 2, r7, c0, c0, 0
+
+ mrc p15, 0, r4, c1, c0, 2 @ Coprocessor access control register
+ mrc p15, 0, r5, c2, c0, 0 @ TTBR0
+ mrc p15, 0, r6, c2, c0, 1 @ TTBR1
+ mrc p15, 0, r7, c2, c0, 2 @ TTBCR
stmia r8!, {r4-r7}
- /* Data TLB lockdown, instruction TLB lockdown registers */
- mrc p15, 0, r5, c10, c0, 0
- mrc p15, 0, r6, c10, c0, 1
- stmia r8!, {r5-r6}
- /* Secure or non secure vector base address, FCSE PID, Context PID*/
- mrc p15, 0, r4, c12, c0, 0
- mrc p15, 0, r5, c13, c0, 0
- mrc p15, 0, r6, c13, c0, 1
- stmia r8!, {r4-r6}
- /* Primary remap, normal remap registers */
- mrc p15, 0, r4, c10, c2, 0
- mrc p15, 0, r5, c10, c2, 1
- stmia r8!,{r4-r5}
- /* Store current cpsr*/
- mrs r2, cpsr
- stmia r8!, {r2}
+ mrc p15, 0, r4, c3, c0, 0 @ Domain access Control Register
+ mrc p15, 0, r5, c10, c2, 0 @ PRRR
+ mrc p15, 0, r6, c10, c2, 1 @ NMRR
+ stmia r8!,{r4-r6}
+
+ mrc p15, 0, r4, c13, c0, 1 @ Context ID
+ mrc p15, 0, r5, c13, c0, 2 @ User r/w thread and process ID
+ mrc p15, 0, r6, c12, c0, 0 @ Secure or NS vector base address
+ mrs r7, cpsr @ Store current cpsr
+ stmia r8!, {r4-r7}
- mrc p15, 0, r4, c1, c0, 0
- /* save control register */
+ mrc p15, 0, r4, c1, c0, 0 @ save control register
stmia r8!, {r4}
clean_caches:
@@ -463,68 +426,29 @@ skipl2reen:
ldr r4, scratchpad_base
ldr r3, [r4,#0xBC]
adds r3, r3, #16
+
ldmia r3!, {r4-r6}
- mov sp, r4
- msr spsr_cxsf, r5
- mov lr, r6
-
- ldmia r3!, {r4-r9}
- /* Coprocessor access Control Register */
- mcr p15, 0, r4, c1, c0, 2
-
- /* TTBR0 */
- MCR p15, 0, r5, c2, c0, 0
- /* TTBR1 */
- MCR p15, 0, r6, c2, c0, 1
- /* Translation table base control register */
- MCR p15, 0, r7, c2, c0, 2
- /* Domain access Control Register */
- MCR p15, 0, r8, c3, c0, 0
- /* Data fault status Register */
- MCR p15, 0, r9, c5, c0, 0
-
- ldmia r3!,{r4-r8}
- /* Instruction fault status Register */
- MCR p15, 0, r4, c5, c0, 1
- /* Data Auxiliary Fault Status Register */
- MCR p15, 0, r5, c5, c1, 0
- /* Instruction Auxiliary Fault Status Register*/
- MCR p15, 0, r6, c5, c1, 1
- /* Data Fault Address Register */
- MCR p15, 0, r7, c6, c0, 0
- /* Instruction Fault Address Register*/
- MCR p15, 0, r8, c6, c0, 2
- ldmia r3!,{r4-r7}
+ mov sp, r4 @ Restore sp
+ msr spsr_cxsf, r5 @ Restore spsr
+ mov lr, r6 @ Restore lr
- /* User r/w thread and process ID */
- MCR p15, 0, r4, c13, c0, 2
- /* User ro thread and process ID */
- MCR p15, 0, r5, c13, c0, 3
- /* Privileged only thread and process ID */
- MCR p15, 0, r6, c13, c0, 4
- /* Cache size selection */
- MCR p15, 2, r7, c0, c0, 0
- ldmia r3!,{r4-r8}
- /* Data TLB lockdown registers */
- MCR p15, 0, r4, c10, c0, 0
- /* Instruction TLB lockdown registers */
- MCR p15, 0, r5, c10, c0, 1
- /* Secure or Nonsecure Vector Base Address */
- MCR p15, 0, r6, c12, c0, 0
- /* FCSE PID */
- MCR p15, 0, r7, c13, c0, 0
- /* Context PID */
- MCR p15, 0, r8, c13, c0, 1
-
- ldmia r3!,{r4-r5}
- /* Primary memory remap register */
- MCR p15, 0, r4, c10, c2, 0
- /* Normal memory remap register */
- MCR p15, 0, r5, c10, c2, 1
-
- /* Restore cpsr */
- ldmia r3!,{r4} @ load CPSR from SDRAM
- msr cpsr, r4 @ store cpsr
+ ldmia r3!, {r4-r7}
+ mcr p15, 0, r4, c1, c0, 2 @ Coprocessor access Control Register
+ mcr p15, 0, r5, c2, c0, 0 @ TTBR0
+ mcr p15, 0, r6, c2, c0, 1 @ TTBR1
+ mcr p15, 0, r7, c2, c0, 2 @ TTBCR
+
+ ldmia r3!,{r4-r6}
+ mcr p15, 0, r4, c3, c0, 0 @ Domain access Control Register
+ mcr p15, 0, r5, c10, c2, 0 @ PRRR
+ mcr p15, 0, r6, c10, c2, 1 @ NMRR
+
+
+ ldmia r3!,{r4-r7}
+ mcr p15, 0, r4, c13, c0, 1 @ Context ID
+ mrc p15, 0, r5, c12, c0, 0 @ Secure or NS vector base address
+ msr cpsr, r6 @ store cpsr
+ mcr p15, 0, r7, c13, c0, 2 @ User r/w thread and process ID
/* Enabling MMU here */
mrc p15, 0, r7, c2, c0, 2 @ Read TTBRControl
--
1.6.0.4
^ permalink raw reply related
* [PATCH 3/6] omap3: pm: Allow the cache clean when L1 is lost.
From: Santosh Shilimkar @ 2011-02-21 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298294365-30770-1-git-send-email-santosh.shilimkar@ti.com>
When L1 cache is suppose to be lost, it needs to be cleaned before
entrering to the low power mode.
While at this, also fix few comments and remove un-necessary
clean_l2 lable.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/sleep34xx.S | 15 +++------------
1 files changed, 3 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 4478379..7442431 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -173,12 +173,12 @@ ENTRY(omap34xx_cpu_suspend)
stmfd sp!, {r0-r12, lr} @ save registers on stack
/*
- * r0 contains restore pointer in sdram
+ * r0 contains CPU context save/restore pointer in sdram
* r1 contains information about saving context:
* 0 - No context lost
* 1 - Only L1 and logic lost
- * 2 - Only L2 lost
- * 3 - Both L1 and L2 lost
+ * 2 - Only L2 lost (Even L1 is retained we clean it along with L2)
+ * 3 - Both L1 and L2 lost and logic lost
*/
/* Directly jump to WFI is the context save is not required */
@@ -263,15 +263,6 @@ l1_logic_lost:
clean_caches:
/*
- * Clean Data or unified cache to POU
- * How to invalidate only L1 cache???? - #FIX_ME#
- * mcr p15, 0, r11, c7, c11, 1
- */
- cmp r1, #0x1 @ Check whether L2 inval is required
- beq omap3_do_wfi
-
-clean_l2:
- /*
* jump out to kernel flush routine
* - reuse that code is better
* - it executes in a cached space so is faster than refetch per-block
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/6] omap3: pm: Fix the mmu on sequence in the asm code
From: Santosh Shilimkar @ 2011-02-21 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298294365-30770-1-git-send-email-santosh.shilimkar@ti.com>
Add necessary barriers after enabling MMU. Also use the sane way to
load pc and jump to it instead of executing ldma first up.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/sleep34xx.S | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index db4cc57..4478379 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -591,12 +591,17 @@ usettbr0:
ldr r2, cache_pred_disable_mask
and r4, r2
mcr p15, 0, r4, c1, c0, 0
+ dsb
+ isb
+ ldr r0, =restoremmu_on
+ bx r0
/*
* ==============================
* == Exit point from OFF mode ==
* ==============================
*/
+restoremmu_on:
ldmfd sp!, {r0-r12, pc} @ restore regs and return
--
1.6.0.4
^ permalink raw reply related
* [PATCH 1/6] omap3: pm: Use amrv7 supported instructions instead of legacy cp15 ones
From: Santosh Shilimkar @ 2011-02-21 13:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1298294365-30770-1-git-send-email-santosh.shilimkar@ti.com>
On ARMv7 dsb, dmb instructions are supported and can be used directly
instead of their cp15 equivalnet. Also remove the opcodes for smc
and use the available instruction directly in OMAP3 low power asm code
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Kevin Hilman <khilman@ti.com>
---
arch/arm/mach-omap2/sleep34xx.S | 35 +++++++++++++++++------------------
1 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/arch/arm/mach-omap2/sleep34xx.S b/arch/arm/mach-omap2/sleep34xx.S
index 98d8232..db4cc57 100644
--- a/arch/arm/mach-omap2/sleep34xx.S
+++ b/arch/arm/mach-omap2/sleep34xx.S
@@ -131,9 +131,9 @@ ENTRY(save_secure_ram_context)
mov r1, #0 @ set task id for ROM code in r1
mov r2, #4 @ set some flags in r2, r6
mov r6, #0xff
- mcr p15, 0, r0, c7, c10, 4 @ data write barrier
- mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
- .word 0xE1600071 @ call SMI monitor (smi #1)
+ dsb @ data write barrier
+ dmb @ data memory barrier
+ smc #1 @ call SMI monitor (smi #1)
nop
nop
nop
@@ -289,9 +289,8 @@ omap3_do_wfi:
str r5, [r4] @ write back to SDRC_POWER register
/* Data memory barrier and Data sync barrier */
- mov r1, #0
- mcr p15, 0, r1, c7, c10, 4
- mcr p15, 0, r1, c7, c10, 5
+ dsb
+ dmb
/*
* ===================================
@@ -406,9 +405,9 @@ skipl2dis:
mov r2, #4 @ set some flags in r2, r6
mov r6, #0xff
adr r3, l2_inv_api_params @ r3 points to dummy parameters
- mcr p15, 0, r0, c7, c10, 4 @ data write barrier
- mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
- .word 0xE1600071 @ call SMI monitor (smi #1)
+ dsb @ data write barrier
+ dmb @ data memory barrier
+ smc #1 @ call SMI monitor (smi #1)
/* Write to Aux control register to set some bits */
mov r0, #42 @ set service ID for PPA
mov r12, r0 @ copy secure Service ID in r12
@@ -417,9 +416,9 @@ skipl2dis:
mov r6, #0xff
ldr r4, scratchpad_base
ldr r3, [r4, #0xBC] @ r3 points to parameters
- mcr p15, 0, r0, c7, c10, 4 @ data write barrier
- mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
- .word 0xE1600071 @ call SMI monitor (smi #1)
+ dsb @ data write barrier
+ dmb @ data memory barrier
+ smc #1 @ call SMI monitor (smi #1)
#ifdef CONFIG_OMAP3_L2_AUX_SECURE_SAVE_RESTORE
/* Restore L2 aux control register */
@@ -432,9 +431,9 @@ skipl2dis:
ldr r4, scratchpad_base
ldr r3, [r4, #0xBC]
adds r3, r3, #8 @ r3 points to parameters
- mcr p15, 0, r0, c7, c10, 4 @ data write barrier
- mcr p15, 0, r0, c7, c10, 5 @ data memory barrier
- .word 0xE1600071 @ call SMI monitor (smi #1)
+ dsb @ data write barrier
+ dmb @ data memory barrier
+ smc #1 @ call SMI monitor (smi #1)
#endif
b logic_l1_restore
@@ -443,18 +442,18 @@ l2_inv_api_params:
l2_inv_gp:
/* Execute smi to invalidate L2 cache */
mov r12, #0x1 @ set up to invalidate L2
- .word 0xE1600070 @ Call SMI monitor (smieq)
+ smc #0 @ Call SMI monitor
/* Write to Aux control register to set some bits */
ldr r4, scratchpad_base
ldr r3, [r4,#0xBC]
ldr r0, [r3,#4]
mov r12, #0x3
- .word 0xE1600070 @ Call SMI monitor (smieq)
+ smc #0 @ Call SMI monitor
ldr r4, scratchpad_base
ldr r3, [r4,#0xBC]
ldr r0, [r3,#12]
mov r12, #0x2
- .word 0xE1600070 @ Call SMI monitor (smieq)
+ smc #0 @ Call SMI monitor
logic_l1_restore:
ldr r1, l2dis_3630
cmp r1, #0x1 @ Test if L2 re-enable needed on 3630
--
1.6.0.4
^ permalink raw reply related
* [PATCH 0/6] omap3: pm: Fixes for low power code
From: Santosh Shilimkar @ 2011-02-21 13:19 UTC (permalink / raw)
To: linux-arm-kernel
The series does below fixes to the omap3 low power code.
1. Use supported ARMv7 instructions instead of the legacy ones
2. Fix the MMU on sequence
3. Fix the cache flush scenario when only L1 lost.
4. Remove all un-necessary context save registers
5. Disable C-bit before cache clean
6. Use set_cr() exported API instead of custom one.
It's generated against mainline and tested with OMAP3630 ZOOM3.
1. Renetion and off-mode mode in suspend - ok.
2. Retention in idle - ok
The following changes since commit 85e2efbb1db9a18d218006706d6e4fbeb0216213:
Linus Torvalds (1):
Linux 2.6.38-rc5
Santosh Shilimkar (6):
omap3: pm: Use amrv7 supported instructions instead of legacy cp15
ones
omap3: pm: Fix the mmu on sequence in the asm code
omap3: pm: Allow the cache clean when L1 is lost.
omap3: pm: Remove un-necessary cp15 registers form low power cpu
context
omap3: pm: Clear the SCTLR C bit in asm code to prevent data cache
allocation
omap3: pm: Use exported set_cr() instead of a custom one.
arch/arm/mach-omap2/pm34xx.c | 7 +-
arch/arm/mach-omap2/sleep34xx.S | 223 ++++++++++++++-------------------------
2 files changed, 78 insertions(+), 152 deletions(-)
^ permalink raw reply
* Question About Linux Memory Mapping
From: Russell King - ARM Linux @ 2011-02-21 13:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTikdPrjHRFc6bD1VsN3MCZkKD0dVSNq1ijgp7qz9@mail.gmail.com>
On Mon, Feb 21, 2011 at 01:13:16PM +0100, Drasko DRASKOVIC wrote:
> Thanks for your answers.
>
> I can see now that "mem" parameter is parsed in
> arch/arm/kernel/setup.c, as Nicolas underlined. However, in my case
> early_mem() is never called during the Linux boot.
>
> Does anybody have an idea why ?
Maybe the command line setting is being ignored by your boot loader
and the one built-in to the kernel is being used?
Maybe your kernel is configured to ignore the command line supplied
by your boot loader?
Maybe you're setting it in the kernel build but not realising that
the boot loader passed one is being used instead?
If you provide the kernel configuration and the kernel boot messages
for the last kernel you tried, it may be possible to work out what's
going on.
^ permalink raw reply
* [PATCH V5 30/63] ST SPEAr: Replacing SIZE macro's with actual required size
From: Russell King - ARM Linux @ 2011-02-21 13:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D6254C4.9060506@st.com>
On Mon, Feb 21, 2011 at 05:34:20PM +0530, viresh kumar wrote:
> On 02/21/2011 05:23 PM, Russell King - ARM Linux wrote:
> > In which case, please only send the first 10, and make sure that they
> > apply on top of my 'spear' branch.
> >
> > Also note that there's some SPEAr patches queued in the 'fixes' branch
> > which will be going upstream tonight.
>
> Russell,
>
> I have taken care of above two steps, but i have some doubt.
> I have made changes at few places:
> - EMI driver: Changes according to your review comments.
> - Removed CLCD patch, as you mentioned that earlier.
> - fixed PLGPIO & EMI patch issue resolved, code has been put to individual patches
> and patch 57 removed completely.
> - PATCH 29 & 30 are placed at the top and changes made other individual patches
>
> So sending only first 10 patches looks a bit insufficient to me? Would be better
> to send all of them (leaving what you have already applied), so that they
> apply cleanly at your end.
I don't know, and I'm getting to the point of giving up with this SPEAr
stuff. It's more trouble and time consuming than it's worth because of
the size of the patch set. It's just *too* large to properly deal with.
^ permalink raw reply
* [PATCH 5/5] mmc: sdhci: add quirk SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO
From: Richard Zhao @ 2011-02-21 12:26 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221110624.GK14495@n2100.arm.linux.org.uk>
On Mon, Feb 21, 2011 at 11:06:24AM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 21, 2011 at 05:54:55PM +0800, Richard Zhao wrote:
> > + if (host->quirks & SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO) {
> > + if (readl(host->ioaddr + SDHCI_VENDOR_SPEC) & 0x2)
> > + writel(readl(host->ioaddr + SDHCI_VENDOR_SPEC) & ~0x2,
> > + host->ioaddr + SDHCI_VENDOR_SPEC);
>
> Is it necessary to read the register twice, or would:
>
> u32 val = readl(host->ioaddr + SDHCI_VENDOR_SPEC);
> if (val & 0x02)
> writel(val & ~0x02, host->ioaddr + SDHCI_VENDOR_SPEC);
>
> be clearer and more obvious?
correct. Thanks.
Richard
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Question About Linux Memory Mapping
From: Drasko DRASKOVIC @ 2011-02-21 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <919555.44803.qm@web161702.mail.bf1.yahoo.com>
Thanks for your answers.
I can see now that "mem" parameter is parsed in
arch/arm/kernel/setup.c, as Nicolas underlined. However, in my case
early_mem() is never called during the Linux boot.
Does anybody have an idea why ?
BR,
Drasko
On Mon, Feb 21, 2011 at 6:27 AM, hong zhang <henryzhang62@yahoo.com> wrote:
> Drasko,
>
> Command line can assign all physical memory or partial memory to kernel using one or few mem=. For example, if you have 1 GBytes memory with starting port at 0x80000000, and want to reserve 512M anywhere between 0x80000000 and 0xc0000000 saying at 0x90000000. Then command line should be
> mem=256M at 0x80000000 mem=256M at 0xb0000000. At this format, kernel should not touch memory between 0x9000000 and 0xb0000000 and the memory can be used by other OS or firmware.
>
> This is my understanding.
>
> ---henry
>
> --- On Sat, 2/19/11, Marek Vasut <marek.vasut@gmail.com> wrote:
>
>> From: Marek Vasut <marek.vasut@gmail.com>
>> Subject: Re: Question About Linux Memory Mapping
>> To: linux-arm at lists.infradead.org
>> Cc: "Drasko DRASKOVIC" <drasko.draskovic@gmail.com>, linux-arm-kernel at lists.infradead.org
>> Date: Saturday, February 19, 2011, 2:22 PM
>> On Friday 18 February 2011 21:56:28
>> Drasko DRASKOVIC wrote:
>> > Hi all,
>> > in the article Booting ARM Linux :
>> > http://www.simtec.co.uk/products/SWLINUX/files/booting_article.html
>> > I can see that mem map is passed via ATAG_MEM.
>> However, in the same
>> > article it is mentioned that this information can also
>> be passed via
>> > kernel command line paramters,
>> mem=<size>[KM][,@<phys_offset>].
>> >
>> > However, this does not seem to be true, as "mem"
>> command line
>> > parameter seems to be formated like this : mem= n[KMG]
>> (i.e. no
>> > offset), regarding to this reference :
>> > http://oreilly.com/linux/excerpts/9780596100797/kernel-boot-command-line-pa
>> > rameter-reference.html. Seems like memmap should be
>> used instead.
>> >
>> > I tried passing the parameters like memmap=
>> n[KMG]@start[KMG] but that
>> > had no effect at all - still the same amount of System
>> Ram was read
>> > from ATAGS and presented in the system via
>> /proc/iomem.
>> >
>> > What I needed it to reserve 1MB region for one FIFO at
>> the end of RAM
>> > (or somewhere else)
>> > and protect it from the kernel. I tried passing
>> memmap=
>> > n[KMG]$start[KMG], but that did not worn neither.
>>
>> What are you exactly trying to achieve ? btw. if you really
>> need to make a hole
>> in RAM, you should reserve a bootmem node maybe?
>> >
>> > So my questions are following :
>> > 1) Why commandlines are ignored and ATAGS are given
>> priority ?
>> > 2) What is the most elegant way to protect one region
>> in RAM :
>> >? a) By giving less memory with ATAGS_MEM and thus
>> making protected
>> > region invisible to Linux, lying to it that RAM is
>> smaller
>> >? b) By changing somehow linker script
>> >? c) By changing some configuration variables
>> (which ?)
>> >
>> > Thanks for the answers and best regards,
>> > Drasko
>> >
>> > _______________________________________________
>> > linux-arm mailing list
>> > linux-arm at lists.infradead.org
>> > http://lists.infradead.org/mailman/listinfo/linux-arm
>>
>> _______________________________________________
>> linux-arm mailing list
>> linux-arm at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm
>>
>
>
>
>
^ permalink raw reply
* [PATCH] DaVinci: fix compilation warnings in <mach/clkdev.h>
From: Nori, Sekhar @ 2011-02-21 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D5ED8BA.5000703@mvista.com>
Hi Sergei,
On Sat, Feb 19, 2011 at 02:08:18, Sergei Shtylyov wrote:
> Kevin, Sekhar, will you apply this?
Last two weeks were pretty busy for me and there has been
a patch backlog. I started today with testing of Mike's SPI
patches.
I should get to your patches this week itself.
Thanks,
Sekhar
^ permalink raw reply
* [PATCH V5 30/63] ST SPEAr: Replacing SIZE macro's with actual required size
From: viresh kumar @ 2011-02-21 12:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221115356.GN14495@n2100.arm.linux.org.uk>
On 02/21/2011 05:23 PM, Russell King - ARM Linux wrote:
> In which case, please only send the first 10, and make sure that they
> apply on top of my 'spear' branch.
>
> Also note that there's some SPEAr patches queued in the 'fixes' branch
> which will be going upstream tonight.
Russell,
I have taken care of above two steps, but i have some doubt.
I have made changes at few places:
- EMI driver: Changes according to your review comments.
- Removed CLCD patch, as you mentioned that earlier.
- fixed PLGPIO & EMI patch issue resolved, code has been put to individual patches
and patch 57 removed completely.
- PATCH 29 & 30 are placed at the top and changes made other individual patches
So sending only first 10 patches looks a bit insufficient to me? Would be better
to send all of them (leaving what you have already applied), so that they
apply cleanly at your end.
--
viresh
^ permalink raw reply
* [PATCH V5 30/63] ST SPEAr: Replacing SIZE macro's with actual required size
From: Russell King - ARM Linux @ 2011-02-21 11:53 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D625013.3000204@st.com>
On Mon, Feb 21, 2011 at 05:14:19PM +0530, viresh kumar wrote:
> On 02/21/2011 04:33 PM, Russell King - ARM Linux wrote:
> > If you can update the ones I've mentioned in the patch tracker that'd
> > be great.
>
> Ok. I will do that.
> You can decline all pending patches from your tracker, and i will resend
> them after rearranging.
In which case, please only send the first 10, and make sure that they
apply on top of my 'spear' branch.
Also note that there's some SPEAr patches queued in the 'fixes' branch
which will be going upstream tonight.
^ permalink raw reply
* [PATCH V5 30/63] ST SPEAr: Replacing SIZE macro's with actual required size
From: viresh kumar @ 2011-02-21 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221110331.GJ14495@n2100.arm.linux.org.uk>
On 02/21/2011 04:33 PM, Russell King - ARM Linux wrote:
> If you can update the ones I've mentioned in the patch tracker that'd
> be great.
Ok. I will do that.
You can decline all pending patches from your tracker, and i will resend
them after rearranging.
--
viresh
^ permalink raw reply
* [PATCH V5 36/63] ST SPEAr : EMI (Extrenal Memory Interface) controller driver
From: Vipin Kumar @ 2011-02-21 11:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221110233.GI14495@n2100.arm.linux.org.uk>
On 2/21/2011 4:32 PM, Russell King - ARM Linux wrote:
> On Mon, Feb 21, 2011 at 11:56:10AM +0530, Vipin Kumar wrote:
>>>> +void __init
>>>> +emi_init_board_info(struct platform_device *pdev, struct resource *resources,
>>>> + int res_num, struct mtd_partition *partitions,
>>>> + unsigned int nr_partitions, unsigned int width)
>>>> +{
>>>> + struct physmap_flash_data *emi_plat_data = dev_get_platdata(&pdev->dev);
>>>> +
>>>> + pdev->resource = resources;
>>>> + pdev->num_resources = res_num;
>>>> +
>>>> + if (partitions) {
>>>> + emi_plat_data->parts = partitions;
>>>> + emi_plat_data->nr_parts = nr_partitions;
>>>> + }
>>>> +
>>>> + emi_plat_data->width = width;
>>>> +}
>>>
>>> I don't see why this has to be code rather than in the platform specific
>>> files as static initializers.
>>
>> The device is instantiated in the machine file and above information comes
>> from the board file. So we kept them this way.
>
> Ok, but I don't see why this should be in the EMI code. Surely this
> should be along side the nor device, and called 'nor_init_board_info'
> or something similar?
> .
>
Yes, you are right. I would change this and resend
Thanks
Regards
Vipin
^ permalink raw reply
* [RFC PATCH 2/2] ARMv7: Invalidate the TLB before freeing page tables
From: Russell King - ARM Linux @ 2011-02-21 11:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTin4vJ_5su-M6t6p4RCDSU-0LrJhgP5vnrEvR24q@mail.gmail.com>
On Mon, Feb 21, 2011 at 11:04:22AM +0000, Catalin Marinas wrote:
> On 21 February 2011 10:30, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Feb 21, 2011 at 09:39:32AM +0000, Catalin Marinas wrote:
> >> On 20 February 2011 12:12, Russell King - ARM Linux
> >> <linux@arm.linux.org.uk> wrote:
> >> > On Tue, Feb 15, 2011 at 02:42:06PM +0000, Catalin Marinas wrote:
> >> >> On Tue, 2011-02-15 at 12:14 +0000, Russell King - ARM Linux wrote:
> >> >> > On Tue, Feb 15, 2011 at 11:32:42AM +0000, Russell King - ARM Linux wrote:
> >> >> > > The point of TLB shootdown is that we unmap the entries from the page
> >> >> > > tables, then issue the TLB flushes, and then free the pages and page
> >> >> > > tables after that. ?All that Peter's patch tries to do is to get ARM to
> >> >> > > use the generic stuff.
> >> >> >
> >> >> > As Peter's patch preserves the current behaviour, that's not sufficient.
> >> >> > So, let's do this our own way and delay pages and page table frees on
> >> >> > ARMv6 and v7. ?Untested.
> >> >>
> >> >> ARMv7 should be enough, I'm not aware of any pre-v7 with this behaviour.
> >> >
> >> > ARM11MPCore. ?Any SMP system can access a page which was free'd by the
> >> > tlb code but hasn't been flushed from the hardware TLBs. ?So maybe we
> >> > want it to be "defined(CONFIG_SMP) || defined(CONFIG_CPU_32v7)" ?
> >>
> >> In practice, since the hardware TLB does not store higher level
> >> entries on existing v6 cores, there is no cached value pointing to the
> >> freed pte page.
> >
> > It's not about cached values of PTE pointers.
>
> My point is about cached values in the 1st level of page tables
> pointing to the second level and the freeing of the 2nd level of page
> tables.
Your point is about parts of the system keeping pointers to page tables
around. This is no different from keeping pointers to pages themselves
around. This is not something new. This is something well known on
architectures such as x86.
> I think we talk about two different cases (but could be fixable with
> the same patch). Your scenario is valid as well, just different.
No, it's the same. The way the hardware achieves it may be different
but from the software point of view it's the same.
> >> In theory, we first clear the pmd entry but another
> >> CPU could be doing a PTW at the same time and had already read the pmd
> >> before being cleared. But the timing constraints are difficult to
> >> reproduce in practice.
> >
> > I don't think you properly understand the problem.
> >
> > CPU#0 is unmapping page tables, eg due to munmap(), mremap(), etc.
> > CPU#1 is running a thread, and has TLB entries for the region being unmapped.
> >
> > ? ? ? ?CPU#0 ? ? ? ? ? ? ? ? ? ? ? ? ? CPU#1
> > ? ? ? ?clear page table entry
> > ? ? ? ?frees page
> > ? ? ? ?loop continues
> > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?accesses page
> > ? ? ? ?...
> > ? ? ? ?sometime in the future
> > ? ? ? ?invalidates TLB
>
> For this scenario we only need to implement tlb_remove_page() to
> invalidate the TLB before releasing the page (called via
> zap_pte_range). We currently delay the TLB operation until
> tlb_end_vma() which happens after the page was released.
Do you not understand that the TLB shootdown code is supposed to make this
more efficient than having to issue a broadcasted TLB invalidate for every
page as we remove each one in sequence?
You should look at include/asm-generic/tlb.h and arch/x86/include/asm/tlb.h
to see how the majority of other architectures handle this stuff...
Anyway, patch committed.
^ permalink raw reply
* [PATCH 5/5] mmc: sdhci: add quirk SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO
From: Wolfram Sang @ 2011-02-21 11:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221110905.GL14495@n2100.arm.linux.org.uk>
On Mon, Feb 21, 2011 at 11:09:05AM +0000, Russell King - ARM Linux wrote:
> On Mon, Feb 21, 2011 at 11:46:08AM +0100, Wolfram Sang wrote:
> > > > > - if (cpu_is_mx35() || cpu_is_mx51())
> > > > > + if (cpu_is_mx53())
> > > > > + host->quirks |= SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO;
> > > >
> > > > Have you tried it doing it via IO-accessors?
> > > Richard Zhu: This quirk is used to fix a mechanism problem in the MMC CMDs execution procedure.
> > > It would be very abrupt and ugly, if the IO-accessors are added into these original procedures.
> >
> > Please don't get it personal, but IMHO it is pretty ugly the way it is
> > now. This quirk is very imx-specific and calling something like
> > SDHCI_VENDOR_SPEC in sdhci.c looks clearly wrong to me. By the way, what
> > does this bit do, the description doesn't say so?
>
> SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO is rather too verbose. Isn't
> there a shorter version which could be used? SDHCI_QUIRK_SDIO_MULTIBLK_INT
> maybe?
As I understand, the non-SDIO part is handled here:
+ /*Set the CMD_TYPE of the CMD12, fix no INT in MULTI_BLK IO */
+ if (host->quirks & SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO) {
+ if (cmd->opcode == 12)
+ flags |= SDHCI_CMD_ABORTCMD;
+ }
But I'd really like to avoid the quirk bit. Maybe we'll get a better
idea once we understand what that magic bit actually does. For a start,
we might simply set SDHCI_QUIRK_NO_MULTIBLOCK for mx53 like we do for
other imx.
Regards,
Wolfram
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110221/d80aa342/attachment.sig>
^ permalink raw reply
* [PATCH 2/2] DM9000B: Fix PHY power for network down/up
From: Sergei Shtylyov @ 2011-02-21 11:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4D618B5D.5040001@henry.nestler.mail.gmail.com>
Hello.
On 21-02-2011 0:45, Henry Nestler wrote:
> DM9000 revision B needs 1 ms delay after PHY power on (see spec), and PHY
> power must on in register
Couldn't parse that.
> DM9000_GPR before all other settings will change.
> Remember, that register DM9000_GPR was not changed by reset sequence.
> Without these fix the FIFO goes out of sync and sends wrong data after
s/these/this/
> sequence of "ifconfig ethX down ; sleep 3 ; ifconfig ethX up".
[...]
> diff --git a/drivers/net/dm9000.c b/drivers/net/dm9000.c
> index 2d4c4fc..5925569 100644
> --- a/drivers/net/dm9000.c
> +++ b/drivers/net/dm9000.c
[...]
> @@ -1194,6 +1191,10 @@ dm9000_open(struct net_device *dev)
> if (request_irq(dev->irq, dm9000_interrupt, irqflags, dev->name, dev))
> return -EAGAIN;
>
> + /* GPIO0 on pre-activate PHY, Reg 1F is not set by reset */
> + iow(db, DM9000_GPR, 0); /* REG_1F bit0 activate phyxcer */
> + udelay(1000); /* delay needs by DM9000B */
Why not mdelay(1)?
WBR, Sergei
^ permalink raw reply
* [PATCH 5/5] mmc: sdhci: add quirk SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO
From: Russell King - ARM Linux @ 2011-02-21 11:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110221104608.GF2616@pengutronix.de>
On Mon, Feb 21, 2011 at 11:46:08AM +0100, Wolfram Sang wrote:
> > > > - if (cpu_is_mx35() || cpu_is_mx51())
> > > > + if (cpu_is_mx53())
> > > > + host->quirks |= SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO;
> > >
> > > Have you tried it doing it via IO-accessors?
> > Richard Zhu: This quirk is used to fix a mechanism problem in the MMC CMDs execution procedure.
> > It would be very abrupt and ugly, if the IO-accessors are added into these original procedures.
>
> Please don't get it personal, but IMHO it is pretty ugly the way it is
> now. This quirk is very imx-specific and calling something like
> SDHCI_VENDOR_SPEC in sdhci.c looks clearly wrong to me. By the way, what
> does this bit do, the description doesn't say so?
SDHCI_QUIRK_FIX_NO_INT_IN_MULTI_BLK_IO is rather too verbose. Isn't
there a shorter version which could be used? SDHCI_QUIRK_SDIO_MULTIBLK_INT
maybe?
^ 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