* [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re: 4430SDP boot failure)
From: Santosh Shilimkar @ 2011-02-12 8:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <cace62268ad657586f07ecbb0e6a99ab@mail.gmail.com>
Tony,
> -----Original Message-----
> From: Santosh Shilimkar [mailto:santosh.shilimkar at ti.com]
> Sent: Thursday, February 03, 2011 2:13 PM
> To: Tony Lindgren
> Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava
> Munegowda; Felipe Balbi
> Subject: RE: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> 4430SDP boot failure)
>
> > -----Original Message-----
> > From: Tony Lindgren [mailto:tony at atomide.com]
> > Sent: Thursday, February 03, 2011 1:19 AM
> > To: Santosh Shilimkar
> > Cc: Anand Gadiyar; Russell King - ARM Linux; linux-arm-
> > kernel at lists.infradead.org; linux-omap at vger.kernel.org; Keshava
> > Munegowda; Felipe Balbi
> > Subject: Re: [PATCH] omap4: Fix ULPI PHY init for ES1.0 SDP (Re:
> > 4430SDP boot failure)
> >
> > * Santosh Shilimkar <santosh.shilimkar@ti.com> [110201 22:04]:
> > > >
> > > > It's a ES1.0 blaze, with the patch below it reboots early
> > > > during the boot. I also have to disable omap_l2_cache_init
> > > > on this board to get it to boot.
> > > >
> > > Do you still get this problem with 'omap_l2_cache_init' ?
> > > As reported earlier, we don't see this issue on ES1.0
> > > SDP.
> >
> > Yeah I do, it rarely makes it to the userspace. Works reliably
> > if I disable omap_l2_cache_init.
> >
> Ok. I shall try few experiments and try to reproduce it
Not sure if it's the same issue but I managed to reproduce the
issue on ES2.0 itself. And after some experiments, it boiled
down to the V6 and V7 issue. By disabling OMAP2 from the build,
everything was fine again.
Regards,
Santosh
^ permalink raw reply
* [PATCH v4 00/22] Updates for Tegra support in 2.6.39
From: Colin Cross @ 2011-02-12 8:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297320204-31882-1-git-send-email-ccross@android.com>
On Wed, Feb 9, 2011 at 10:43 PM, Colin Cross <ccross@android.com> wrote:
> This is a repost of the same series with the suspend and
> idle support dropped for now while the necessary changes
> to the gic, l2x0, and init notifiers are discussed. ?If
> there are no further comments, I will push these to
> tegra/for-next.
>
> ?arch/arm/configs/tegra_defconfig ? ? ? ? ? ? ? | ?123 +++++++++++
> ?arch/arm/mach-tegra/Makefile ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?arch/arm/mach-tegra/board.h ? ? ? ? ? ? ? ? ? ?| ? ?2 +
> ?arch/arm/mach-tegra/common.c ? ? ? ? ? ? ? ? ? | ? 17 ++-
> ?arch/arm/mach-tegra/cpu-tegra.c ? ? ? ? ? ? ? ?| ? 75 ++++++--
> ?arch/arm/mach-tegra/dma.c ? ? ? ? ? ? ? ? ? ? ?| ?198 ++++++++++--------
> ?arch/arm/mach-tegra/gpio.c ? ? ? ? ? ? ? ? ? ? | ? ?1 +
> ?arch/arm/mach-tegra/include/mach/debug-macro.S | ? 25 +--
> ?arch/arm/mach-tegra/include/mach/iomap.h ? ? ? | ? 69 +++++-
> ?arch/arm/mach-tegra/include/mach/irqs.h ? ? ? ?| ? 14 +-
> ?arch/arm/mach-tegra/include/mach/legacy_irq.h ?| ? ?4 +
> ?arch/arm/mach-tegra/include/mach/pinmux-t2.h ? | ? 10 +
> ?arch/arm/mach-tegra/include/mach/powergate.h ? | ? 40 ++++
> ?arch/arm/mach-tegra/include/mach/suspend.h ? ? | ? 38 ++++
> ?arch/arm/mach-tegra/include/mach/system.h ? ? ?| ? 10 +-
> ?arch/arm/mach-tegra/include/mach/uncompress.h ?| ? 18 +--
> ?arch/arm/mach-tegra/irq.c ? ? ? ? ? ? ? ? ? ? ?| ?186 ++++++++---------
> ?arch/arm/mach-tegra/legacy_irq.c ? ? ? ? ? ? ? | ?109 ++++++++++-
> ?arch/arm/mach-tegra/pinmux-t2-tables.c ? ? ? ? | ? 26 ++-
> ?arch/arm/mach-tegra/powergate.c ? ? ? ? ? ? ? ?| ?212 +++++++++++++++++++
> ?arch/arm/mach-tegra/tegra2_clocks.c ? ? ? ? ? ?| ?264 ++++++++++++++++++++++--
> ?arch/arm/mach-tegra/timer.c ? ? ? ? ? ? ? ? ? ?| ? 61 ++++++-
> ?22 files changed, 1212 insertions(+), 291 deletions(-)
>
I pushed this patch set to tegra/for-next, with minor fixups from
Stephen Warren.
^ permalink raw reply
* [PATCH 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Arnd Bergmann @ 2011-02-12 8:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110212140417.GA9821@S2100-06.ap.freescale.net>
On Saturday 12 February 2011 15:04:19 Shawn Guo wrote:
> > and tmio_mmc.c more or less do what I'm suggesting you do instead.
> >
> > Looking at sh_mmcif:
> >
> > host->chan_tx = dma_request_channel(mask, sh_mmcif_filter,
> > &pdata->dma->chan_priv_tx);
> >
> >
> > This is the only place where dma engine specific data is used
> > in the driver, and chan_priv_tx is part of the platform data, so the
> > mmc driver can simply pass it down as a void pointer without knowing
> > the type. The platform data as defined in the machine file ties
> > both the dma controller and the mmc device together, but neither
> > of the two drivers needs to know anything about the implementation
> > of the other.
> >
> Not really. Though mmc does not need to know anything about dma
> driver, dma knows that mmc driver has to pass .slave_id via
> chan->private. The snippet below is copied from shdma.
>
> struct sh_dmae_slave_config {
> unsigned int slave_id;
> dma_addr_t addr;
> u32 chcr;
> char mid_rid;
> };
> ---
> if (chan->private) {
> /* The caller is holding dma_list_mutex */
> struct sh_dmae_slave *param = chan->private;
> clear_bit(param->slave_id, sh_dmae_slave_used);
> }
>
> And it only works when slave_id is the first member of
> sh_dmae_slave_config.
>
> For me, it's more natural to define device's dma related things like
> dma channel id and irq as its resources than platform data. So I
> still maintain the current approach.
I'm not arguing against passing the data as platform data (well, not any
more, but it was never the main objection anyway).
You are right that sh_dmae_slave_config contains all the private data
for the DMA controller, and I have no objection to you doing the
same. However, sh_mmcif.c does not know the defintion of
sh_dmae_slave_config, it just gets it via a void pointer from the
platform data and passes it to the dma_request_channel function via
another void pointer. That function calls into the sh_dmae driver, which
casts it back to struct sh_dmae_slave_config, and that is same that I'm
suggesting you to do.
It should really be a trivial change to move your struct mxs_dma_data
from struct mxs_mmc_host to your platform_data:
struct mxs_mmc_platform_data {
int wp_gpio; /* write protect pin */
void *dma_data;
};
static struct mxs_dma_data mxs_mmc_dma_data = {
.chan_irq = MMC_DMA_IRQ,
};
static struct mxs_mmc_platform_data mxs_mmc_pdata = {
.wp_gpio = SOME_CONSTANT,
.dma_data = &mxs_mmc_dma_data,
}
Now only the platform definition needs to know about both
mxs_mmc_platform_data and mxs_dma_data, while the dma engine driver
and the mmc driver each just need to know about their own data.
Sorry for being too vague in what I asking for before.
Arnd
^ permalink raw reply
* [PATCH 1/6] ARM: move cache/processor/fault glue to separate include files
From: Russell King - ARM Linux @ 2011-02-12 9:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimZOGkgjudvxeaOMJz=p2peZAt6Zf-sFjrz66YL@mail.gmail.com>
On Fri, Feb 11, 2011 at 06:52:14PM -0800, Colin Cross wrote:
> Acked-by: Colin Cross <ccross@android.com>
>
> Tested on Tegra 2.
Thanks, I'll take these as Tested-by's.
^ permalink raw reply
* [PATCH v4 02/19] ARM: LPAE: Fix early_pte_alloc() assumption about the Linux PTE
From: Russell King - ARM Linux @ 2011-02-12 9:56 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295891761-18366-3-git-send-email-catalin.marinas@arm.com>
On Mon, Jan 24, 2011 at 05:55:44PM +0000, Catalin Marinas wrote:
> With LPAE we no longer have software bits in a separate Linux PTE and
> the early_pte_alloc() function should pass PTE_HWTABLE_OFF +
> PTE_HWTABLE_SIZE to early_alloc() to avoid allocating extra memory.
This one can also go to the patch system too.
^ permalink raw reply
* [PATCH v4 03/19] ARM: LPAE: use long long format when printing physical addresses and ptes
From: Russell King - ARM Linux @ 2011-02-12 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295891761-18366-4-git-send-email-catalin.marinas@arm.com>
On Mon, Jan 24, 2011 at 05:55:45PM +0000, Catalin Marinas wrote:
> diff --git a/arch/arm/kernel/setup.c b/arch/arm/kernel/setup.c
> index 5ea4fb7..3d23f0f 100644
> --- a/arch/arm/kernel/setup.c
> +++ b/arch/arm/kernel/setup.c
> @@ -449,7 +449,7 @@ static int __init arm_add_memory(unsigned long start, unsigned long size)
>
> if (meminfo.nr_banks >= NR_BANKS) {
> printk(KERN_CRIT "NR_BANKS too low, "
> - "ignoring memory at %#lx\n", start);
> + "ignoring memory at %#08llx\n", (long long)start);
This is not equivalent. %#lx produces '0x0'. %#08llx produces '0x000000'
not '0x00000000' - the '0x' is included in the field width. So you want
'%#010llx' or '0x%08llx' - there's no real advantage to either. Or just
convert '%#lx' to '%#llx'.
^ permalink raw reply
* [PATCH] omap iommu: print module name on error messages
From: David Cohen @ 2011-02-12 10:02 UTC (permalink / raw)
To: linux-arm-kernel
OMAP IOMMU generic layer doesn't need ot print function name during
error messages. Print module name instead which is more useful.
Signed-off-by: David Cohen <dacohen@gmail.com>
---
arch/arm/plat-omap/iommu.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/plat-omap/iommu.c b/arch/arm/plat-omap/iommu.c
index b1107c0..f55f458 100644
--- a/arch/arm/plat-omap/iommu.c
+++ b/arch/arm/plat-omap/iommu.c
@@ -806,7 +806,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
iopgd = iopgd_offset(obj, da);
if (!iopgd_is_table(*iopgd)) {
- dev_err(obj->dev, "%s: da:%08x pgd:%p *pgd:%08x\n", __func__,
+ dev_err(obj->dev, "%s: da:%08x pgd:%p *pgd:%08x\n", obj->name,
da, iopgd, *iopgd);
return IRQ_NONE;
}
@@ -814,7 +814,7 @@ static irqreturn_t iommu_fault_handler(int irq, void *data)
iopte = iopte_offset(iopgd, da);
dev_err(obj->dev, "%s: da:%08x pgd:%p *pgd:%08x pte:%p *pte:%08x\n",
- __func__, da, iopgd, *iopgd, iopte, *iopte);
+ obj->name, da, iopgd, *iopgd, iopte, *iopte);
return IRQ_NONE;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 1/7] mmc: mxs-mmc: add mmc host driver for i.MX23/28
From: Arnd Bergmann @ 2011-02-12 10:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110212172357.GB9821@S2100-06.ap.freescale.net>
On Saturday 12 February 2011 18:23:58 Shawn Guo wrote:
> Well, we are removing inclusion of mach/dma.h from mmc driver, but
> adding it to every mxs based machine code. This makes mmc driver
> clean but machine code becomes not. For some dma client devices
> coming later, the platform data could be saved at all, if they do not
> have any. But with the approach you are suggesting, every single
> client device will have to get platform data.
Right, unless there is a way to encode it exlusively in the resources,
which is what I was suggesting at first: If the dma engine driver
knows about all the channels, you only need to pass the channel number.
If you use a flattened device tree, you can avoid the need for
platform data by adding the phandle of the dma engine device to
a property of the mmc driver, along with the channel number inside
of that device. I think that would be the cleanest approach, but
some people still need to be convinced that changing drivers to
use fdt data is the right direction for ARM.
Arnd
^ permalink raw reply
* mc13xxx-core, support for i2c, V4
From: Marc Reilly @ 2011-02-12 10:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110212084035.GB17755@angua.secretlab.ca>
Hi Grant,
Thanks for your comments,
On Saturday, February 12, 2011 07:40:35 pm Grant Likely wrote:
> On Tue, Jan 04, 2011 at 04:34:55PM +1100, Marc Reilly wrote:
> > Hi,
> >
> > These patches add i2c support for the mc13xxx-core drive. For v4 I've
> > tried to take in all previous comments, hopefully making it better to
> > follow, and bisectable.
>
> This series looks okay to me. Since this is audio drivers, I expect
> that it would best be taken via the ASoC tree? Have you sent it to
> Mark Brown and the ALSA list for review?
>
> g.
Actually only the mc13873 has audio support. I think these IC's really fit
better under the MFD tree, but silly me didn't add Samuel Ortiz (MFD
maintainer) to this series... so included him now.
Samuel, are you the most appropriate to take this series in and would you like
me to resend these patches to you? The thread archive is at [1].
Cheers
Marc
[1]
http://lists.arm.linux.org.uk/lurker/message/20110104.053455.45bc5880.en.html
^ permalink raw reply
* [RFC PATCH 0/3] CPU PM notifiers
From: Santosh Shilimkar @ 2011-02-12 10:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297373487-23902-1-git-send-email-ccross@android.com>
> -----Original Message-----
> From: Colin Cross [mailto:ccross at android.com]
> Sent: Friday, February 11, 2011 3:01 AM
> To: linux-arm-kernel at lists.infradead.org; Russell King
> Cc: linux at arm.linux.org.uk; santosh.shilimkar at ti.com;
> catalin.marinas at arm.com; will.deacon at arm.com; Colin Cross
> Subject: [RFC PATCH 0/3] CPU PM notifiers
>
> This patch set tries to address Russell's concerns with platform
> pm code calling into the driver for every block in the Cortex A9s
> during idle, hotplug, and suspend. The first patch adds cpu pm
> notifiers that can be called by platform code, the second uses
> the notifier to save and restore the GIC state, and the third
> saves the VFP state.
>
> The notifiers are used for two types of events, CPU PM events and
> CPU complex PM events. CPU PM events are used to save per-cpu
> context when a single CPU is preparing to enter or has just exited
> a low power state. For example, the VFP saves the last thread
> context, and the GIC saves banked CPU registers.
>
> CPU complex events are used after all the CPUs in a power domain
> have been prepared for the low power state. The GIC uses these
> events to save global register state.
>
> What is not included:
> * Multiple power states - it is assumed that if the platform
> code calls cpu_pm_enter(), every listener needs to save
> its context.
> * L2 cache - The L2 cache will need very different behavior
> depending on the HW implementation and power mode being
> entered.
>
> Both problems could be solved be defining a set of power states
> shared by all platforms, if an agreeable set exists. For example:
> * CPU reset (TWD, GIC, VFP), L1 retention, L2 untouched
> * CPU reset + L1 lost, L2 retention
> * CPU reset, L1 + L2 lost
>
> Santosh previously mentioned that the GIC is not reset in the first
> two states on OMAP, which starts to make the list complicated. Does
> disabling the GIC cause a problem in these states?
>
Yep it will be an issue. L2 and GIC are not part of CPU powerdomain
but they are part of another power domain.
OMAP has many aspect like more power domains, trust zone, multiple
power state combinations and it will complicate most of the generic
code. I suggest you go ahead with what suits to majority of the SoCs.
> An alternate solution is to pass a set of flags instead of a power
> state:
> CPU_PM_LOCALTIMERS_RESET
> CPU_PM_INTERRUPTS_RESET
> CPU_PM_L1_RETENTION
> CPU_PM_L1_RESET
> CPU_PM_L2_RETENTION
> CPU_PM_L2_RESET
>
> arch/arm/common/gic.c | 204
> +++++++++++++++++++++++++++++++++++++++++
> arch/arm/include/asm/cpu_pm.h | 123 +++++++++++++++++++++++++
> arch/arm/kernel/Makefile | 1 +
> arch/arm/kernel/cpu_pm.c | 116 +++++++++++++++++++++++
> arch/arm/vfp/vfpmodule.c | 24 +++++
> 5 files changed, 468 insertions(+), 0 deletions(-)
^ permalink raw reply
* Help - Getting started
From: Daniel F. Pigatto @ 2011-02-12 10:27 UTC (permalink / raw)
To: linux-arm-kernel
Hi everybody,
I am very beginner in embedded systems, and I really need your help. I guess
it will not be too difficult for you, who already work with ARM processors.
I have bought the following kit which includes an ARM processor with a video
module and some other peripherals:
http://www.gumstix.com/store/catalog/product_info.php?products_id=253
Then, obviously, I need to install an operating system in order to be able
to run some cryptographic algorithms and evaluate some behaviours of this
hardware. I chose Linux ARM, because Linux is a very well-known system,
which is also very trustable.
My doubts are about how to get started installing the OS. Is there any
tutorial or something that I could read to start installing? Is it a
difficult way that I will probably face?
I do need a help to get started. Just this.
Thank you very much!
--
Daniel Fernando Pigatto
MSc. Candidate at ICMC/USP
<http://www.usp.br>Curr?culo Lattes <http://lattes.cnpq.br/4624030380501998>
| LinkedIn <http://linkedin.com/in/danielpigatto>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20110212/e6eac38d/attachment.html>
^ permalink raw reply
* [PATCH v4 15/19] ARM: LPAE: use phys_addr_t instead of unsigned long for physical addresses
From: Russell King - ARM Linux @ 2011-02-12 10:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295891761-18366-16-git-send-email-catalin.marinas@arm.com>
On Mon, Jan 24, 2011 at 05:55:57PM +0000, Catalin Marinas wrote:
> arch/arm/include/asm/memory.h | 17 +++++++++--------
> arch/arm/include/asm/outercache.h | 14 ++++++++------
> arch/arm/include/asm/pgtable.h | 2 +-
> arch/arm/include/asm/setup.h | 2 +-
> arch/arm/kernel/setup.c | 5 +++--
> arch/arm/mm/init.c | 6 +++---
> arch/arm/mm/mmu.c | 7 ++++---
> 7 files changed, 29 insertions(+), 24 deletions(-)
If this is split up into four separate patches, we can probably sort out
merging this for the upcoming window.
asm/memory.h will conflict non-trivially with p2v patch set, but I think
we can merge the changes to everything but __virt_to_phys/__phys_to_virt.
asm/outercache.h changes are stand-alone.
asm/pgtable.h looks like it could use __pfn_to_phys(pfn) rather than
adding the cast, and can be combined with mm/init.c and mm/mmu.c.
asm/setup.h and arch/arm/kernel/setup.c form another logical group.
^ permalink raw reply
* [PATCH v4 16/19] ARM: LPAE: Use generic dma_addr_t type definition
From: Russell King - ARM Linux @ 2011-02-12 10:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295891761-18366-17-git-send-email-catalin.marinas@arm.com>
On Mon, Jan 24, 2011 at 05:55:58PM +0000, Catalin Marinas wrote:
> From: Will Deacon <will.deacon@arm.com>
>
> This patch uses the types.h implementation in asm-generic to define the
> dma_addr_t type as the same width as phys_addr_t.
>
> NOTE: this is a temporary patch until the corresponding patches unifying
> the dma_addr_t and removing the dma64_addr_t are merged into mainline.
I'm not too sure about this patch. All of the DMA devices we have only
take 32-bit addresses for their DMA, so making dma_addr_t 64-bit seems
wrong as we'll implicitly truncate these addresses.
As ARM platforms don't (sanely) support DMA, I think dropping this patch
for the time being would be a good idea, and stick with 32-bit dma_addr_t,
especially as we need to first do a sweep for dma_addr_t usage in device
driver structures (such as dma engine scatter lists.) These really should
use __le32/__be32/u32 depending on whether they're little endian, big
endian or native endian.
^ permalink raw reply
* [PATCH v4 17/19] ARM: LPAE: mark memory banks with start > ULONG_MAX as highmem
From: Russell King - ARM Linux @ 2011-02-12 10:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295891761-18366-18-git-send-email-catalin.marinas@arm.com>
On Mon, Jan 24, 2011 at 05:55:59PM +0000, Catalin Marinas wrote:
> @@ -782,7 +782,8 @@ static void __init sanity_check_meminfo(void)
>
> #ifdef CONFIG_HIGHMEM
> if (__va(bank->start) > vmalloc_min ||
> - __va(bank->start) < (void *)PAGE_OFFSET)
> + __va(bank->start) < (void *)PAGE_OFFSET ||
> + bank->start > ULONG_MAX)
I think this check should be first, so that we don't try to evaluate __va()
on phys addresses > ULONG_MAX, possibly resulting in truncation.
^ permalink raw reply
* [PATCH v4 12/19] ARM: LPAE: Add context switching support
From: Russell King - ARM Linux @ 2011-02-12 10:44 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1295891761-18366-13-git-send-email-catalin.marinas@arm.com>
On Mon, Jan 24, 2011 at 05:55:54PM +0000, Catalin Marinas wrote:
> +#ifdef CONFIG_ARM_LPAE
> +#define cpu_set_asid(asid) { \
> + unsigned long ttbl, ttbh; \
> + asm(" mrrc p15, 0, %0, %1, c2 @ read TTBR0\n" \
> + " mov %1, %1, lsl #(48 - 32) @ set ASID\n" \
> + " mcrr p15, 0, %0, %1, c2 @ set TTBR0\n" \
> + : "=r" (ttbl), "=r" (ttbh) \
> + : "r" (asid & ~ASID_MASK)); \
This is wrong:
1. It does nothing with %2 (the new asid)
2. it shifts the high address bits of TTBR0 left 16 places each time its
called.
> +}
> +#else
> +#define cpu_set_asid(asid) \
> + asm(" mcr p15, 0, %0, c13, c0, 1\n" : : "r" (asid))
> +#endif
> +
> /*
> * We fork()ed a process, and we need a new context for the child
> * to run in. We reserve version 0 for initial tasks so we will
> @@ -37,7 +51,7 @@ void __init_new_context(struct task_struct *tsk, struct mm_struct *mm)
> static void flush_context(void)
> {
> /* set the reserved ASID before flushing the TLB */
> - asm("mcr p15, 0, %0, c13, c0, 1\n" : : "r" (0));
> + cpu_set_asid(0);
> isb();
> local_flush_tlb_all();
> if (icache_is_vivt_asid_tagged()) {
> @@ -99,7 +113,7 @@ static void reset_context(void *info)
> set_mm_context(mm, asid);
>
> /* set the new ASID */
> - asm("mcr p15, 0, %0, c13, c0, 1\n" : : "r" (mm->context.id));
> + cpu_set_asid(mm->context.id);
> isb();
> }
>
> diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
> index a22b89f..ed4f3cb 100644
> --- a/arch/arm/mm/proc-v7.S
> +++ b/arch/arm/mm/proc-v7.S
> @@ -117,6 +117,11 @@ ENTRY(cpu_v7_switch_mm)
> #ifdef CONFIG_MMU
> mov r2, #0
> ldr r1, [r1, #MM_CONTEXT_ID] @ get mm->context.id
How about swapping the order here to avoid r1 being referenced in the very
next instruction?
> +#ifdef CONFIG_ARM_LPAE
> + and r3, r1, #0xff
> + mov r3, r3, lsl #(48 - 32) @ ASID
> + mcrr p15, 0, r0, r3, c2 @ set TTB 0
> +#else /* !CONFIG_ARM_LPAE */
> ALT_SMP(orr r0, r0, #TTB_FLAGS_SMP)
> ALT_UP(orr r0, r0, #TTB_FLAGS_UP)
> #ifdef CONFIG_ARM_ERRATA_430973
> @@ -124,9 +129,10 @@ ENTRY(cpu_v7_switch_mm)
> #endif
> mcr p15, 0, r2, c13, c0, 1 @ set reserved context ID
> isb
> -1: mcr p15, 0, r0, c2, c0, 0 @ set TTB 0
> + mcr p15, 0, r0, c2, c0, 0 @ set TTB 0
> isb
> mcr p15, 0, r1, c13, c0, 1 @ set context ID
> +#endif /* CONFIG_ARM_LPAE */
> isb
> #endif
> mov pc, lr
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Arnd Bergmann @ 2011-02-12 10:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <AANLkTimZb-hxz-31nGmycdtU-i=t=9wBoDJ-chAXUmD6@mail.gmail.com>
On Saturday 12 February 2011 00:23:37 Linus Walleij wrote:
> H'm! That's an interesting resource indeed. When you write
> "From measurements, it appears that the size in which data is
> managed is typically 64 kb on SD cards" and "the size of the
> medium is always a multiple of entire allocation groups, and
> the most common size today is 4 MB" and then list
> Size, Allocation Unit, Write Size, Page Size, FAT Location,
> open AUs linear, open AUs random, Algorithm.
>
> How exactly do you measure that?
It's not an exact science, but for most cards I have found
reasonably good ways to identify these numbers:
* the allocation unit size can almost always be found
using read-only tests: reading 2kb across an allocation
unit boundary is slightly slower than reading 2kb
just before or just after the boundary.
For a few cards where this doesn't work, I do write tests.
After finding out how many allocation units can be open,
it's trivial to find out the size.
* Finding the number of open allocation units means I write
to the start of a few AUs alternating. Up to a certain
number, the throughput is constant, above that, it drops
sharply, sometimes by one or two orders of magnitude.
* The page size can also be found doing read-only tests, with
varying block sizes. Smaller reads always give lower throughput
than larger reads, but getting smaller than page size
drops down significantly more than the difference between
multi-page reads. This effect is more prominent in write tests.
* Finding the algorithm basically means I write an allocation
unit using varying block sizes two times, using both linear
access and random access. Cards that are optimized for
linear access can be unbelievably slow in the random access
tests. Sometimes the performance is the same above a specific
block size, but slower for random access below that size.
This is the write block size.
* Finding the write block size in cases where this is not the
case can be harder. Most cards have a noticable performance
drop in writes of less than a few pages, so that's the
size I put in the table.
* The FAT location is clearly visible in a number of tests
done inside of an allocation unit. It's normally slower for
linear access, but faster for random access. Sometimes
reading the FAT is also slower than reading elsewhere.
> I'm sort of smelling a card-probe.git with this tool that you
> can run on your device and get out data like that listed
> in your table. We have a rather large stash of cards we can
> probe for you to get that kind of data out if it is useful, and
> I believe other Linaro members may have such stuff too,
> if empirical data is usefult to your work.
The tool I'm using is on http://git.linaro.org/gitweb?p=people/arnd/flashbench.git
Unfortunately, it's not yet in the state that I'm recommending
anyone besides me to run it. I'm still rewriting the source
for every new card I get to nail down the specific properties.
I will make an announcement when I have the tool in a state
of general usefulness, and at that point I would really
appreciate people to run it, but just not yet.
Arnd
^ permalink raw reply
* MMC quirks relating to performance/lifetime.
From: Russell King - ARM Linux @ 2011-02-12 10:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201102121145.42053.arnd@arndb.de>
On Sat, Feb 12, 2011 at 11:45:41AM +0100, Arnd Bergmann wrote:
> * The FAT location is clearly visible in a number of tests
> done inside of an allocation unit. It's normally slower for
> linear access, but faster for random access. Sometimes
> reading the FAT is also slower than reading elsewhere.
I wouldn't also be surprised if there's some cards out there which parse
the FAT being written, and start activities (such as erasing clusters)
based upon changes therein. Such cards would be unsuitable for use with
non-FAT filesystems.
It might be worth devising some sort of check for this kind of behaviour.
Unrelated, I have a USB based device which provides an emulated FAT
filesystem - all files except one on this filesystem are read-only.
The writable file is a textual configuration file. It can be reliably
updated by Windows based systems, but updates from Linux based systems
are ignored - presumably because updates to the FAT/directory/data
clusters are occuring in a different order.
^ permalink raw reply
* [PATCH] OMAP: IOMMU: add missing function declaration
From: David Cohen @ 2011-02-12 11:09 UTC (permalink / raw)
To: linux-arm-kernel
Function declaration 'iopgtable_lookup_entry' is missing from header
file.
Signed-off-by: David Cohen <dacohen@gmail.com>
---
arch/arm/plat-omap/include/plat/iommu.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-omap/include/plat/iommu.h b/arch/arm/plat-omap/include/plat/iommu.h
index 9e8c104..5a2475f 100644
--- a/arch/arm/plat-omap/include/plat/iommu.h
+++ b/arch/arm/plat-omap/include/plat/iommu.h
@@ -163,6 +163,8 @@ extern void flush_iotlb_range(struct iommu *obj, u32 start, u32 end);
extern void flush_iotlb_all(struct iommu *obj);
extern int iopgtable_store_entry(struct iommu *obj, struct iotlb_entry *e);
+extern void iopgtable_lookup_entry(struct iommu *obj, u32 da, u32 **ppgd,
+ u32 **ppte);
extern size_t iopgtable_clear_entry(struct iommu *obj, u32 iova);
extern int iommu_set_da_range(struct iommu *obj, u32 start, u32 end);
--
1.7.1
^ permalink raw reply related
* [PATCH 0/5] ARM: omap4 related fixes for 2.6.39
From: Santosh Shilimkar @ 2011-02-12 11:29 UTC (permalink / raw)
To: linux-arm-kernel
The series mainly does below
- Makes ARM local timers selection runtime instead of compile time.
- Enables the LOCAL_TIMER support for OMAP4430
- Add and enable PL310 Errata for flush by Way
- Fixes the NR_CPU value in omap2plus config
- Removes the un-necessary omap44xx_sram_init FIXME
Boot tested on OMAP4430 ES1.0 and ES2.X silicons.
The following changes since commit 100b33c8bd8a3235fd0b7948338d6cbb3db3c63d:
Linus Torvalds (1):
Linux 2.6.38-rc4
are available in the git repository at:
git://dev.omapzoom.org/pub/scm/santosh/kernel-omap4-base.git omap4-misc_for.39
Santosh Shilimkar (5):
ARM: smp: Select local timers vs dummy timer support runtime
omap4: Enable ARM local timers with OMAP4430 es1.0 exception
ARM: l2x0: Errata fix for flush by Way operation can cause data
corruption
omap2plus: omap4: Set NR_CPU to 2 instead of default 4
omap4: Remove 'FIXME: omap44xx_sram_init not implemented'
arch/arm/Kconfig | 11 +++++++++++
arch/arm/configs/omap2plus_defconfig | 1 +
arch/arm/include/asm/localtimer.h | 8 +++++++-
arch/arm/kernel/smp.c | 7 +++----
arch/arm/mach-msm/timer.c | 3 ++-
arch/arm/mach-omap2/Kconfig | 2 ++
arch/arm/mach-omap2/timer-mpu.c | 7 ++++++-
arch/arm/mach-realview/localtimer.c | 3 ++-
arch/arm/mach-s5pv310/localtimer.c | 3 ++-
arch/arm/mach-shmobile/localtimer.c | 3 ++-
arch/arm/mach-tegra/localtimer.c | 3 ++-
arch/arm/mach-ux500/localtimer.c | 3 ++-
arch/arm/mach-vexpress/localtimer.c | 3 ++-
arch/arm/mm/cache-l2x0.c | 16 ++++++++++------
arch/arm/plat-omap/sram.c | 16 ----------------
15 files changed, 54 insertions(+), 35 deletions(-)
^ permalink raw reply
* [PATCH 1/5] ARM: smp: Select local timers vs dummy timer support runtime
From: Santosh Shilimkar @ 2011-02-12 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297510187-31547-1-git-send-email-santosh.shilimkar@ti.com>
The current code support of dummy timers in absence of local
timer is compile time. This is an attempt to convert it to runtime
so that on few SOC version if the local timers aren't supported
kernel can switch to dummy timers. OMAP4430 ES1.0 does suffer from
this limitation.
This patch should not have any functional impact on affected
files.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: David Brown <davidb@codeaurora.org>
Cc: Daniel Walker <dwalker@codeaurora.org>
Cc: Bryan Huntsman <bryanh@codeaurora.org>
Cc: Tony Lindgren <tony@atomide.com>
Cc: Kukjin Kim <kgene.kim@samsung.com>
Cc: Paul Mundt <lethal@linux-sh.org>
Cc: Magnus Damm <magnus.damm@gmail.com>
Cc: Colin Cross <ccross@android.com>
Cc: Erik Gilling <konkers@android.com>
Cc: Srinidhi Kasagar <srinidhi.kasagar@stericsson.com>
Cc: Linus Walleij <linus.walleij@stericsson.com>
---
arch/arm/include/asm/localtimer.h | 8 +++++++-
arch/arm/kernel/smp.c | 7 +++----
arch/arm/mach-msm/timer.c | 3 ++-
arch/arm/mach-omap2/timer-mpu.c | 3 ++-
arch/arm/mach-realview/localtimer.c | 3 ++-
arch/arm/mach-s5pv310/localtimer.c | 3 ++-
arch/arm/mach-shmobile/localtimer.c | 3 ++-
arch/arm/mach-tegra/localtimer.c | 3 ++-
arch/arm/mach-ux500/localtimer.c | 3 ++-
arch/arm/mach-vexpress/localtimer.c | 3 ++-
10 files changed, 26 insertions(+), 13 deletions(-)
diff --git a/arch/arm/include/asm/localtimer.h b/arch/arm/include/asm/localtimer.h
index 6bc63ab..080d74f 100644
--- a/arch/arm/include/asm/localtimer.h
+++ b/arch/arm/include/asm/localtimer.h
@@ -44,8 +44,14 @@ int local_timer_ack(void);
/*
* Setup a local timer interrupt for a CPU.
*/
-void local_timer_setup(struct clock_event_device *);
+int local_timer_setup(struct clock_event_device *);
+#else
+
+static inline int local_timer_setup(struct clock_event_device *evt)
+{
+ return -ENXIO;
+}
#endif
#endif
diff --git a/arch/arm/kernel/smp.c b/arch/arm/kernel/smp.c
index 4539ebc..7b9cc53 100644
--- a/arch/arm/kernel/smp.c
+++ b/arch/arm/kernel/smp.c
@@ -474,13 +474,12 @@ static void smp_timer_broadcast(const struct cpumask *mask)
#define smp_timer_broadcast NULL
#endif
-#ifndef CONFIG_LOCAL_TIMERS
static void broadcast_timer_set_mode(enum clock_event_mode mode,
struct clock_event_device *evt)
{
}
-static void local_timer_setup(struct clock_event_device *evt)
+static void dummy_timer_setup(struct clock_event_device *evt)
{
evt->name = "dummy_timer";
evt->features = CLOCK_EVT_FEAT_ONESHOT |
@@ -492,7 +491,6 @@ static void local_timer_setup(struct clock_event_device *evt)
clockevents_register_device(evt);
}
-#endif
void __cpuinit percpu_timer_setup(void)
{
@@ -502,7 +500,8 @@ void __cpuinit percpu_timer_setup(void)
evt->cpumask = cpumask_of(cpu);
evt->broadcast = smp_timer_broadcast;
- local_timer_setup(evt);
+ if (local_timer_setup(evt))
+ dummy_timer_setup(evt);
}
#ifdef CONFIG_HOTPLUG_CPU
diff --git a/arch/arm/mach-msm/timer.c b/arch/arm/mach-msm/timer.c
index c105d28..ae85aa9 100644
--- a/arch/arm/mach-msm/timer.c
+++ b/arch/arm/mach-msm/timer.c
@@ -255,7 +255,7 @@ static void __init msm_timer_init(void)
}
#ifdef CONFIG_SMP
-void __cpuinit local_timer_setup(struct clock_event_device *evt)
+int __cpuinit local_timer_setup(struct clock_event_device *evt)
{
struct msm_clock *clock = &msm_clocks[MSM_GLOBAL_TIMER];
@@ -287,6 +287,7 @@ void __cpuinit local_timer_setup(struct clock_event_device *evt)
gic_enable_ppi(clock->irq.irq);
clockevents_register_device(evt);
+ return 0;
}
inline int local_timer_ack(void)
diff --git a/arch/arm/mach-omap2/timer-mpu.c b/arch/arm/mach-omap2/timer-mpu.c
index 954682e..09c73dc 100644
--- a/arch/arm/mach-omap2/timer-mpu.c
+++ b/arch/arm/mach-omap2/timer-mpu.c
@@ -26,9 +26,10 @@
/*
* Setup the local clock events for a CPU.
*/
-void __cpuinit local_timer_setup(struct clock_event_device *evt)
+int __cpuinit local_timer_setup(struct clock_event_device *evt)
{
evt->irq = OMAP44XX_IRQ_LOCALTIMER;
twd_timer_setup(evt);
+ return 0;
}
diff --git a/arch/arm/mach-realview/localtimer.c b/arch/arm/mach-realview/localtimer.c
index 60b4e11..aca29ce 100644
--- a/arch/arm/mach-realview/localtimer.c
+++ b/arch/arm/mach-realview/localtimer.c
@@ -19,8 +19,9 @@
/*
* Setup the local clock events for a CPU.
*/
-void __cpuinit local_timer_setup(struct clock_event_device *evt)
+int __cpuinit local_timer_setup(struct clock_event_device *evt)
{
evt->irq = IRQ_LOCALTIMER;
twd_timer_setup(evt);
+ return 0;
}
diff --git a/arch/arm/mach-s5pv310/localtimer.c b/arch/arm/mach-s5pv310/localtimer.c
index 2784036..8239c6a 100644
--- a/arch/arm/mach-s5pv310/localtimer.c
+++ b/arch/arm/mach-s5pv310/localtimer.c
@@ -18,8 +18,9 @@
/*
* Setup the local clock events for a CPU.
*/
-void __cpuinit local_timer_setup(struct clock_event_device *evt)
+int __cpuinit local_timer_setup(struct clock_event_device *evt)
{
evt->irq = IRQ_LOCALTIMER;
twd_timer_setup(evt);
+ return 0;
}
diff --git a/arch/arm/mach-shmobile/localtimer.c b/arch/arm/mach-shmobile/localtimer.c
index 2111c28..ad9ccc9 100644
--- a/arch/arm/mach-shmobile/localtimer.c
+++ b/arch/arm/mach-shmobile/localtimer.c
@@ -18,8 +18,9 @@
/*
* Setup the local clock events for a CPU.
*/
-void __cpuinit local_timer_setup(struct clock_event_device *evt)
+int __cpuinit local_timer_setup(struct clock_event_device *evt)
{
evt->irq = 29;
twd_timer_setup(evt);
+ return 0;
}
diff --git a/arch/arm/mach-tegra/localtimer.c b/arch/arm/mach-tegra/localtimer.c
index f81ca7c..e91d681 100644
--- a/arch/arm/mach-tegra/localtimer.c
+++ b/arch/arm/mach-tegra/localtimer.c
@@ -18,8 +18,9 @@
/*
* Setup the local clock events for a CPU.
*/
-void __cpuinit local_timer_setup(struct clock_event_device *evt)
+int __cpuinit local_timer_setup(struct clock_event_device *evt)
{
evt->irq = IRQ_LOCALTIMER;
twd_timer_setup(evt);
+ return 0;
}
diff --git a/arch/arm/mach-ux500/localtimer.c b/arch/arm/mach-ux500/localtimer.c
index 2288f6a..5ba1133 100644
--- a/arch/arm/mach-ux500/localtimer.c
+++ b/arch/arm/mach-ux500/localtimer.c
@@ -21,8 +21,9 @@
/*
* Setup the local clock events for a CPU.
*/
-void __cpuinit local_timer_setup(struct clock_event_device *evt)
+int __cpuinit local_timer_setup(struct clock_event_device *evt)
{
evt->irq = IRQ_LOCALTIMER;
twd_timer_setup(evt);
+ return 0;
}
diff --git a/arch/arm/mach-vexpress/localtimer.c b/arch/arm/mach-vexpress/localtimer.c
index c0e3a59..e5adbfa 100644
--- a/arch/arm/mach-vexpress/localtimer.c
+++ b/arch/arm/mach-vexpress/localtimer.c
@@ -19,8 +19,9 @@
/*
* Setup the local clock events for a CPU.
*/
-void __cpuinit local_timer_setup(struct clock_event_device *evt)
+int __cpuinit local_timer_setup(struct clock_event_device *evt)
{
evt->irq = IRQ_LOCALTIMER;
twd_timer_setup(evt);
+ return 0;
}
--
1.6.0.4
^ permalink raw reply related
* [PATCH 2/5] omap4: Enable ARM local timers with OMAP4430 es1.0 exception
From: Santosh Shilimkar @ 2011-02-12 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297510187-31547-1-git-send-email-santosh.shilimkar@ti.com>
On OMAP4430 ES1.0 the local timers are gated by security. Enable the
CONFIG_LOCAL_TIMERS for omap2plus build and handle the OMAP4430 es1.0
exception case.
This patch has dependency on the first patch in this series.
ARM: smp: Select local timers vs dummy timer support runtime
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mach-omap2/timer-mpu.c | 4 ++++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1a2cf62..f285dd7 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -44,6 +44,7 @@ config ARCH_OMAP4
depends on ARCH_OMAP2PLUS
select CPU_V7
select ARM_GIC
+ select LOCAL_TIMERS
select PL310_ERRATA_588369
select ARM_ERRATA_720789
select ARCH_HAS_OPP
diff --git a/arch/arm/mach-omap2/timer-mpu.c b/arch/arm/mach-omap2/timer-mpu.c
index 09c73dc..31c0ac4 100644
--- a/arch/arm/mach-omap2/timer-mpu.c
+++ b/arch/arm/mach-omap2/timer-mpu.c
@@ -28,6 +28,10 @@
*/
int __cpuinit local_timer_setup(struct clock_event_device *evt)
{
+ /* Local timers are not supprted on OMAP4430 ES1.0 */
+ if (omap_rev() == OMAP4430_REV_ES1_0)
+ return -ENXIO;
+
evt->irq = OMAP44XX_IRQ_LOCALTIMER;
twd_timer_setup(evt);
return 0;
--
1.6.0.4
^ permalink raw reply related
* [PATCH 3/5] ARM: l2x0: Errata fix for flush by Way operation can cause data corruption
From: Santosh Shilimkar @ 2011-02-12 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297510187-31547-1-git-send-email-santosh.shilimkar@ti.com>
PL310 implements the Clean & Invalidate by Way L2 cache maintenance
operation (offset 0x7FC). This operation runs in background so that
PL310 can handle normal accesses while it is in progress. Under very
rare circumstances, due to this erratum, write data can be lost when
PL310 treats a cacheable write transaction during a Clean & Invalidate
by Way operation.
Workaround:
Disable Write-Back and Cache Linefill (Debug Control Register)
Clean & Invalidate by Way (0x7FC)
Re-enable Write-Back and Cache Linefill (Debug Control Register)
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
---
arch/arm/Kconfig | 11 +++++++++++
arch/arm/mach-omap2/Kconfig | 1 +
arch/arm/mm/cache-l2x0.c | 16 ++++++++++------
3 files changed, 22 insertions(+), 6 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 5cff165..2e6b879 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1177,6 +1177,17 @@ config ARM_ERRATA_743622
visible impact on the overall performance or power consumption of the
processor.
+config PL310_ERRATA_727915
+ bool "Background Clean & Invalidate by Way operation can cause data corruption"
+ depends on CACHE_L2X0 && ARCH_OMAP4
+ help
+ PL310 implements the Clean & Invalidate by Way L2 cache maintenance
+ operation (offset 0x7FC). This operation runs in background so that
+ PL310 can handle normal accesses while it is in progress. Under very
+ rare circumstances, due to this erratum, write data can be lost when
+ PL310 treats a cacheable write transaction during a Clean &
+ Invalidate by Way operation Note that this errata uses Texas
+ Instrument's secure monitor api to implement the work around.
endmenu
source "arch/arm/common/Kconfig"
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index f285dd7..1f0ff75 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -46,6 +46,7 @@ config ARCH_OMAP4
select ARM_GIC
select LOCAL_TIMERS
select PL310_ERRATA_588369
+ select PL310_ERRATA_727915
select ARM_ERRATA_720789
select ARCH_HAS_OPP
select PM_OPP if PM
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 170c9bb..c7c8fbe 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch/arm/mm/cache-l2x0.c
@@ -67,7 +67,7 @@ static inline void l2x0_inv_line(unsigned long addr)
writel_relaxed(addr, base + L2X0_INV_LINE_PA);
}
-#ifdef CONFIG_PL310_ERRATA_588369
+#if defined(CONFIG_PL310_ERRATA_588369) || defined(CONFIG_PL310_ERRATA_727915)
static void debug_writel(unsigned long val)
{
extern void omap_smc1(u32 fn, u32 arg);
@@ -78,7 +78,14 @@ static void debug_writel(unsigned long val)
*/
omap_smc1(0x100, val);
}
+#else
+/* Optimised out for non-errata case */
+static inline void debug_writel(unsigned long val)
+{
+}
+#endif
+#ifdef CONFIG_PL310_ERRATA_588369
static inline void l2x0_flush_line(unsigned long addr)
{
void __iomem *base = l2x0_base;
@@ -91,11 +98,6 @@ static inline void l2x0_flush_line(unsigned long addr)
}
#else
-/* Optimised out for non-errata case */
-static inline void debug_writel(unsigned long val)
-{
-}
-
static inline void l2x0_flush_line(unsigned long addr)
{
void __iomem *base = l2x0_base;
@@ -119,9 +121,11 @@ static void l2x0_flush_all(void)
/* clean all ways */
spin_lock_irqsave(&l2x0_lock, flags);
+ debug_writel(0x03);
writel_relaxed(l2x0_way_mask, l2x0_base + L2X0_CLEAN_INV_WAY);
cache_wait_way(l2x0_base + L2X0_CLEAN_INV_WAY, l2x0_way_mask);
cache_sync();
+ debug_writel(0x00);
spin_unlock_irqrestore(&l2x0_lock, flags);
}
--
1.6.0.4
^ permalink raw reply related
* [PATCH 4/5] omap2plus: omap4: Set NR_CPU to 2 instead of default 4
From: Santosh Shilimkar @ 2011-02-12 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297510187-31547-1-git-send-email-santosh.shilimkar@ti.com>
The omap2plus_defconfig picks default NR_CPU value as 4 which isn't
correct for OMAP4430. Available CPUs are ony 2, so fix the same.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/configs/omap2plus_defconfig | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/arm/configs/omap2plus_defconfig b/arch/arm/configs/omap2plus_defconfig
index ae890ca..019fb7c 100644
--- a/arch/arm/configs/omap2plus_defconfig
+++ b/arch/arm/configs/omap2plus_defconfig
@@ -58,6 +58,7 @@ CONFIG_ARM_ERRATA_411920=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_SMP=y
+CONFIG_NR_CPUS=2
# CONFIG_LOCAL_TIMERS is not set
CONFIG_AEABI=y
CONFIG_LEDS=y
--
1.6.0.4
^ permalink raw reply related
* [PATCH 5/5] omap4: Remove 'FIXME: omap44xx_sram_init not implemented'
From: Santosh Shilimkar @ 2011-02-12 11:29 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1297510187-31547-1-git-send-email-santosh.shilimkar@ti.com>
The omap44xx_sram_init() implements functionality to push some
code on SRAM whenever the code can't be executed from external
memory. The low power and DVFS code can be executed from
external DDR itself thanks to OMAP4 memory controller hardware
support. So on OMAP4, sram_push kind of functionality isn't needed.
Hence remove the FIXME warning added for implementing sram push
feature on OMAP4.
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
---
arch/arm/plat-omap/sram.c | 16 ----------------
1 files changed, 0 insertions(+), 16 deletions(-)
diff --git a/arch/arm/plat-omap/sram.c b/arch/arm/plat-omap/sram.c
index e26e504..2d7bded 100644
--- a/arch/arm/plat-omap/sram.c
+++ b/arch/arm/plat-omap/sram.c
@@ -405,20 +405,6 @@ static inline int omap34xx_sram_init(void)
}
#endif
-#ifdef CONFIG_ARCH_OMAP4
-static int __init omap44xx_sram_init(void)
-{
- printk(KERN_ERR "FIXME: %s not implemented\n", __func__);
-
- return -ENODEV;
-}
-#else
-static inline int omap44xx_sram_init(void)
-{
- return 0;
-}
-#endif
-
int __init omap_sram_init(void)
{
omap_detect_sram();
@@ -432,8 +418,6 @@ int __init omap_sram_init(void)
omap243x_sram_init();
else if (cpu_is_omap34xx())
omap34xx_sram_init();
- else if (cpu_is_omap44xx())
- omap44xx_sram_init();
return 0;
}
--
1.6.0.4
^ permalink raw reply related
* [PATCH V2 1/4] ARM: Xilinx: Adding Xilinx board support
From: Russell King - ARM Linux @ 2011-02-12 12:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <0e8b21c6-60ff-4f82-a8e6-5c2a0fe80372@VA3EHSMHS005.ehs.local>
On Wed, Feb 09, 2011 at 10:00:42AM -0700, John Linn wrote:
> +/* arch/arm/mach-xilinx/board_ep107.c
> + *
> + * This file contains code specific to the Xilinx EP107 board.
> + *
> + * Copyright (C) 2011 Xilinx
> + *
> + * based on /arch/arm/mach-realview/core.c
> + *
> + * Copyright (C) 1999 - 2003 ARM Limited
> + * Copyright (C) 2000 Deep Blue Solutions Ltd
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
You probably don't want to include this paragraph - their address keeps
changing, so will require files to be constantly updated.
> + */
> +
> +#include <linux/platform_device.h>
> +#include <asm/mach-types.h>
> +#include <asm/mach/arch.h>
> +#include <mach/xilinx_soc.h>
> +#include <mach/irqs.h>
> +#include <linux/clkdev.h>
Please group linux/ includes together, then asm/ includes, lastly mach/
includes.
> @@ -0,0 +1,113 @@
> +/* arch/arm/mach-xilinx/common.c
...
> +/**
> + * system_init - System specific initialization, intended to be called from
> + * board specific initialization.
> + *
> + **/
> +void __init system_init(void)
Is there a better name for this - maybe prefixing it with xilinx_ ?
> +{
> +#ifdef CONFIG_CACHE_L2X0
> + /*
> + * 64KB way size, 8-way associativity, parity disabled
> + */
> + l2x0_init(PL310_L2CC_BASE, 0x02060000, 0xF0F0FFFF);
> +#endif
> +}
> +
> +/**
> + * irq_init - Interrupt controller initialization for the GIC.
> + *
> + **/
> +void __init irq_init(void)
Ditto.
> +/**
> + * map_io - Create memory mappings needed for early I/O.
> + *
> + **/
> +void __init map_io(void)
Ditto.
^ 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