* [PATCH v6 02/15] ARM: Section based HYP idmap
From: Christoffer Dall @ 2013-01-16 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116175716.29147.15348.stgit@ubuntu>
Add a method (hyp_idmap_setup) to populate a hyp pgd with an
identity mapping of the code contained in the .hyp.idmap.text
section.
Offer a method to drop this identity mapping through
hyp_idmap_teardown.
Make all the above depend on CONFIG_ARM_VIRT_EXT and CONFIG_ARM_LPAE.
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Christoffer Dall <c.dall@virtualopensystems.com>
---
arch/arm/include/asm/idmap.h | 1
arch/arm/include/asm/pgtable-3level-hwdef.h | 1
arch/arm/kernel/vmlinux.lds.S | 6 ++-
arch/arm/mm/idmap.c | 55 ++++++++++++++++++++++-----
4 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/arch/arm/include/asm/idmap.h b/arch/arm/include/asm/idmap.h
index bf863ed..1a66f907 100644
--- a/arch/arm/include/asm/idmap.h
+++ b/arch/arm/include/asm/idmap.h
@@ -8,6 +8,7 @@
#define __idmap __section(.idmap.text) noinline notrace
extern pgd_t *idmap_pgd;
+extern pgd_t *hyp_pgd;
void setup_mm_for_reboot(void);
diff --git a/arch/arm/include/asm/pgtable-3level-hwdef.h b/arch/arm/include/asm/pgtable-3level-hwdef.h
index d795282..a2d404e 100644
--- a/arch/arm/include/asm/pgtable-3level-hwdef.h
+++ b/arch/arm/include/asm/pgtable-3level-hwdef.h
@@ -44,6 +44,7 @@
#define PMD_SECT_XN (_AT(pmdval_t, 1) << 54)
#define PMD_SECT_AP_WRITE (_AT(pmdval_t, 0))
#define PMD_SECT_AP_READ (_AT(pmdval_t, 0))
+#define PMD_SECT_AP1 (_AT(pmdval_t, 1) << 6)
#define PMD_SECT_TEX(x) (_AT(pmdval_t, 0))
/*
diff --git a/arch/arm/kernel/vmlinux.lds.S b/arch/arm/kernel/vmlinux.lds.S
index 11c1785..b571484 100644
--- a/arch/arm/kernel/vmlinux.lds.S
+++ b/arch/arm/kernel/vmlinux.lds.S
@@ -19,7 +19,11 @@
ALIGN_FUNCTION(); \
VMLINUX_SYMBOL(__idmap_text_start) = .; \
*(.idmap.text) \
- VMLINUX_SYMBOL(__idmap_text_end) = .;
+ VMLINUX_SYMBOL(__idmap_text_end) = .; \
+ ALIGN_FUNCTION(); \
+ VMLINUX_SYMBOL(__hyp_idmap_text_start) = .; \
+ *(.hyp.idmap.text) \
+ VMLINUX_SYMBOL(__hyp_idmap_text_end) = .;
#ifdef CONFIG_HOTPLUG_CPU
#define ARM_CPU_DISCARD(x)
diff --git a/arch/arm/mm/idmap.c b/arch/arm/mm/idmap.c
index 99db769..b9ae344 100644
--- a/arch/arm/mm/idmap.c
+++ b/arch/arm/mm/idmap.c
@@ -1,4 +1,6 @@
+#include <linux/module.h>
#include <linux/kernel.h>
+#include <linux/slab.h>
#include <asm/cputype.h>
#include <asm/idmap.h>
@@ -6,6 +8,7 @@
#include <asm/pgtable.h>
#include <asm/sections.h>
#include <asm/system_info.h>
+#include <asm/virt.h>
pgd_t *idmap_pgd;
@@ -59,11 +62,17 @@ static void idmap_add_pud(pgd_t *pgd, unsigned long addr, unsigned long end,
} while (pud++, addr = next, addr != end);
}
-static void identity_mapping_add(pgd_t *pgd, unsigned long addr, unsigned long end)
+static void identity_mapping_add(pgd_t *pgd, const char *text_start,
+ const char *text_end, unsigned long prot)
{
- unsigned long prot, next;
+ unsigned long addr, end;
+ unsigned long next;
+
+ addr = virt_to_phys(text_start);
+ end = virt_to_phys(text_end);
+
+ prot |= PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AF;
- prot = PMD_TYPE_SECT | PMD_SECT_AP_WRITE | PMD_SECT_AF;
if (cpu_architecture() <= CPU_ARCH_ARMv5TEJ && !cpu_is_xscale())
prot |= PMD_BIT4;
@@ -74,28 +83,52 @@ static void identity_mapping_add(pgd_t *pgd, unsigned long addr, unsigned long e
} while (pgd++, addr = next, addr != end);
}
+#ifdef CONFIG_ARM_VIRT_EXT
+pgd_t *hyp_pgd;
+
+extern char __hyp_idmap_text_start[], __hyp_idmap_text_end[];
+
+static int __init init_static_idmap_hyp(void)
+{
+ hyp_pgd = kzalloc(PTRS_PER_PGD * sizeof(pgd_t), GFP_KERNEL);
+ if (!hyp_pgd)
+ return -ENOMEM;
+
+ pr_info("Setting up static HYP identity map for 0x%p - 0x%p\n",
+ __hyp_idmap_text_start, __hyp_idmap_text_end);
+ identity_mapping_add(hyp_pgd, __hyp_idmap_text_start,
+ __hyp_idmap_text_end, PMD_SECT_AP1);
+
+ return 0;
+}
+#else
+static int __init init_static_idmap_hyp(void)
+{
+ return 0;
+}
+#endif
+
extern char __idmap_text_start[], __idmap_text_end[];
static int __init init_static_idmap(void)
{
- phys_addr_t idmap_start, idmap_end;
+ int ret;
idmap_pgd = pgd_alloc(&init_mm);
if (!idmap_pgd)
return -ENOMEM;
- /* Add an identity mapping for the physical address of the section. */
- idmap_start = virt_to_phys((void *)__idmap_text_start);
- idmap_end = virt_to_phys((void *)__idmap_text_end);
+ pr_info("Setting up static identity map for 0x%p - 0x%p\n",
+ __idmap_text_start, __idmap_text_end);
+ identity_mapping_add(idmap_pgd, __idmap_text_start,
+ __idmap_text_end, 0);
- pr_info("Setting up static identity map for 0x%llx - 0x%llx\n",
- (long long)idmap_start, (long long)idmap_end);
- identity_mapping_add(idmap_pgd, idmap_start, idmap_end);
+ ret = init_static_idmap_hyp();
/* Flush L1 for the hardware to see this page table content */
flush_cache_louis();
- return 0;
+ return ret;
}
early_initcall(init_static_idmap);
^ permalink raw reply related
* [PATCH 1/2] ARM: tegra: config: enable SERIAL_TEGRA
From: Stephen Warren @ 2013-01-16 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358341572-8154-1-git-send-email-ldewangan@nvidia.com>
On 01/16/2013 06:06 AM, Laxman Dewangan wrote:
> Enable high speed serial driver for tegra platform.
Thanks, I've applied patch 1 to Tegra's for-3.9/defconfig branch and
patch 2 to Tegra's for-3.9/dt branch.
Just as an FYI, the dt branch is merged into my for-next branch, and
sent upstream, before the defconfig branch, so your patch order was
reversed relative to that, but it's not an issue here.
Question: How do I test this; do I just fire up bluez(?) and point it at
the UARTC serial port, or is there more to it?
^ permalink raw reply
* [PATCH v6 01/15] ARM: Add page table and page defines needed by KVM
From: Christoffer Dall @ 2013-01-16 17:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116175716.29147.15348.stgit@ubuntu>
KVM uses the stage-2 page tables and the Hyp page table format,
so we define the fields and page protection flags needed by KVM.
The nomenclature is this:
- page_hyp: PL2 code/data mappings
- page_hyp_device: PL2 device mappings (vgic access)
- page_s2: Stage-2 code/data page mappings
- page_s2_device: Stage-2 device mappings (vgic access)
Reviewed-by: Will Deacon <will.deacon@arm.com>
Reviewed-by: Marcelo Tosatti <mtosatti@redhat.com>
Christoffer Dall <c.dall@virtualopensystems.com>
---
arch/arm/include/asm/pgtable-3level.h | 18 ++++++++++++++++++
arch/arm/include/asm/pgtable.h | 7 +++++++
arch/arm/mm/mmu.c | 22 ++++++++++++++++++++++
3 files changed, 47 insertions(+)
diff --git a/arch/arm/include/asm/pgtable-3level.h b/arch/arm/include/asm/pgtable-3level.h
index a3f3792..6ef8afd 100644
--- a/arch/arm/include/asm/pgtable-3level.h
+++ b/arch/arm/include/asm/pgtable-3level.h
@@ -104,11 +104,29 @@
*/
#define L_PGD_SWAPPER (_AT(pgdval_t, 1) << 55) /* swapper_pg_dir entry */
+/*
+ * 2nd stage PTE definitions for LPAE.
+ */
+#define L_PTE_S2_MT_UNCACHED (_AT(pteval_t, 0x5) << 2) /* MemAttr[3:0] */
+#define L_PTE_S2_MT_WRITETHROUGH (_AT(pteval_t, 0xa) << 2) /* MemAttr[3:0] */
+#define L_PTE_S2_MT_WRITEBACK (_AT(pteval_t, 0xf) << 2) /* MemAttr[3:0] */
+#define L_PTE_S2_RDONLY (_AT(pteval_t, 1) << 6) /* HAP[1] */
+#define L_PTE_S2_RDWR (_AT(pteval_t, 2) << 6) /* HAP[2:1] */
+
+/*
+ * Hyp-mode PL2 PTE definitions for LPAE.
+ */
+#define L_PTE_HYP L_PTE_USER
+
#ifndef __ASSEMBLY__
#define pud_none(pud) (!pud_val(pud))
#define pud_bad(pud) (!(pud_val(pud) & 2))
#define pud_present(pud) (pud_val(pud))
+#define pmd_table(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \
+ PMD_TYPE_TABLE)
+#define pmd_sect(pmd) ((pmd_val(pmd) & PMD_TYPE_MASK) == \
+ PMD_TYPE_SECT)
#define pud_clear(pudp) \
do { \
diff --git a/arch/arm/include/asm/pgtable.h b/arch/arm/include/asm/pgtable.h
index 9c82f98..f30ac3b 100644
--- a/arch/arm/include/asm/pgtable.h
+++ b/arch/arm/include/asm/pgtable.h
@@ -70,6 +70,9 @@ extern void __pgd_error(const char *file, int line, pgd_t);
extern pgprot_t pgprot_user;
extern pgprot_t pgprot_kernel;
+extern pgprot_t pgprot_hyp_device;
+extern pgprot_t pgprot_s2;
+extern pgprot_t pgprot_s2_device;
#define _MOD_PROT(p, b) __pgprot(pgprot_val(p) | (b))
@@ -82,6 +85,10 @@ extern pgprot_t pgprot_kernel;
#define PAGE_READONLY_EXEC _MOD_PROT(pgprot_user, L_PTE_USER | L_PTE_RDONLY)
#define PAGE_KERNEL _MOD_PROT(pgprot_kernel, L_PTE_XN)
#define PAGE_KERNEL_EXEC pgprot_kernel
+#define PAGE_HYP _MOD_PROT(pgprot_kernel, L_PTE_HYP)
+#define PAGE_HYP_DEVICE _MOD_PROT(pgprot_hyp_device, L_PTE_HYP)
+#define PAGE_S2 _MOD_PROT(pgprot_s2, L_PTE_S2_RDONLY)
+#define PAGE_S2_DEVICE _MOD_PROT(pgprot_s2_device, L_PTE_USER | L_PTE_S2_RDONLY)
#define __PAGE_NONE __pgprot(_L_PTE_DEFAULT | L_PTE_RDONLY | L_PTE_XN | L_PTE_NONE)
#define __PAGE_SHARED __pgprot(_L_PTE_DEFAULT | L_PTE_USER | L_PTE_XN)
diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
index 9f06102..1f51d71 100644
--- a/arch/arm/mm/mmu.c
+++ b/arch/arm/mm/mmu.c
@@ -57,6 +57,9 @@ static unsigned int cachepolicy __initdata = CPOLICY_WRITEBACK;
static unsigned int ecc_mask __initdata = 0;
pgprot_t pgprot_user;
pgprot_t pgprot_kernel;
+pgprot_t pgprot_hyp_device;
+pgprot_t pgprot_s2;
+pgprot_t pgprot_s2_device;
EXPORT_SYMBOL(pgprot_user);
EXPORT_SYMBOL(pgprot_kernel);
@@ -66,34 +69,46 @@ struct cachepolicy {
unsigned int cr_mask;
pmdval_t pmd;
pteval_t pte;
+ pteval_t pte_s2;
};
+#ifdef CONFIG_ARM_LPAE
+#define s2_policy(policy) policy
+#else
+#define s2_policy(policy) 0
+#endif
+
static struct cachepolicy cache_policies[] __initdata = {
{
.policy = "uncached",
.cr_mask = CR_W|CR_C,
.pmd = PMD_SECT_UNCACHED,
.pte = L_PTE_MT_UNCACHED,
+ .pte_s2 = s2_policy(L_PTE_S2_MT_UNCACHED),
}, {
.policy = "buffered",
.cr_mask = CR_C,
.pmd = PMD_SECT_BUFFERED,
.pte = L_PTE_MT_BUFFERABLE,
+ .pte_s2 = s2_policy(L_PTE_S2_MT_UNCACHED),
}, {
.policy = "writethrough",
.cr_mask = 0,
.pmd = PMD_SECT_WT,
.pte = L_PTE_MT_WRITETHROUGH,
+ .pte_s2 = s2_policy(L_PTE_S2_MT_WRITETHROUGH),
}, {
.policy = "writeback",
.cr_mask = 0,
.pmd = PMD_SECT_WB,
.pte = L_PTE_MT_WRITEBACK,
+ .pte_s2 = s2_policy(L_PTE_S2_MT_WRITEBACK),
}, {
.policy = "writealloc",
.cr_mask = 0,
.pmd = PMD_SECT_WBWA,
.pte = L_PTE_MT_WRITEALLOC,
+ .pte_s2 = s2_policy(L_PTE_S2_MT_WRITEBACK),
}
};
@@ -310,6 +325,7 @@ static void __init build_mem_type_table(void)
struct cachepolicy *cp;
unsigned int cr = get_cr();
pteval_t user_pgprot, kern_pgprot, vecs_pgprot;
+ pteval_t hyp_device_pgprot, s2_pgprot, s2_device_pgprot;
int cpu_arch = cpu_architecture();
int i;
@@ -421,6 +437,8 @@ static void __init build_mem_type_table(void)
*/
cp = &cache_policies[cachepolicy];
vecs_pgprot = kern_pgprot = user_pgprot = cp->pte;
+ s2_pgprot = cp->pte_s2;
+ hyp_device_pgprot = s2_device_pgprot = mem_types[MT_DEVICE].prot_pte;
/*
* ARMv6 and above have extended page tables.
@@ -444,6 +462,7 @@ static void __init build_mem_type_table(void)
user_pgprot |= L_PTE_SHARED;
kern_pgprot |= L_PTE_SHARED;
vecs_pgprot |= L_PTE_SHARED;
+ s2_pgprot |= L_PTE_SHARED;
mem_types[MT_DEVICE_WC].prot_sect |= PMD_SECT_S;
mem_types[MT_DEVICE_WC].prot_pte |= L_PTE_SHARED;
mem_types[MT_DEVICE_CACHED].prot_sect |= PMD_SECT_S;
@@ -498,6 +517,9 @@ static void __init build_mem_type_table(void)
pgprot_user = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | user_pgprot);
pgprot_kernel = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG |
L_PTE_DIRTY | kern_pgprot);
+ pgprot_s2 = __pgprot(L_PTE_PRESENT | L_PTE_YOUNG | s2_pgprot);
+ pgprot_s2_device = __pgprot(s2_device_pgprot);
+ pgprot_hyp_device = __pgprot(hyp_device_pgprot);
mem_types[MT_LOW_VECTORS].prot_l1 |= ecc_mask;
mem_types[MT_HIGH_VECTORS].prot_l1 |= ecc_mask;
^ permalink raw reply related
* [PATCH v6 00/15] KVM/ARM Implementation
From: Christoffer Dall @ 2013-01-16 17:57 UTC (permalink / raw)
To: linux-arm-kernel
The following series implements KVM support for ARM processors,
specifically on the Cortex A-15 platform.
Work is done in collaboration between Columbia University, Virtual Open
Systems and ARM/Linaro.
The patch series applies to Linux 3.8-rc3.
The series relies on two additional patches in Will Deacon's perf tree:
ARM: Define CPU part numbers and implementors
ARM: Use implementor and part defines from cputype.h
This is Version 16 of the patch series, the first 10 versions were
reviewed on the KVM/ARM and KVM mailing lists. Changes can also be
pulled from:
git://github.com/virtualopensystems/linux-kvm-arm.git
branch: kvm-arm-v16
branch: kvm-arm-v16-vgic
branch: kvm-arm-v16-vgic-timers
A non-flattened edition of the patch series, which can always be merged,
can be found at:
git://github.com/virtualopensystems/linux-kvm-arm.git kvm-arm-master
This patch series requires QEMU compatibility. Use the branch
git://github.com/virtualopensystems/qemu.git kvm-arm
There is also WIP QEMU patches to support virtio on ARM:
git://github.com/virtualopensystems/qemu.git kvm-arm-virtio
There is also a rebasing WIP branch with support for huge pages:
git://github.com/virtualopensystems/linux-kvm-arm.git kvm-arm-hugetlb
Finally there is kvmtool support available for the mach-virt machine:
git://git.kernel.org/pub/scm/linux/kernel/git/will/kvmtool.git
Following this patch series, which implements core KVM support, are two
other patch series implementing Virtual Generic Interrupt Controller
(VGIC) support and Architected Generic Timers. All three patch series
should be applied for full QEMU compatibility.
The implementation is broken up into a logical set of patches, the first
are preparatory patches:
1. ARM: Add page table defines for KVM
2. ARM: Section based HYP idmaps
The main implementation is broken up into separate patches, the first
containing a skeleton of files, makefile changes, the basic user space
interface and KVM architecture specific stubs. Subsequent patches
implement parts of the system as listed:
3. Skeleton and reset hooks
4. Hypervisor initialization
5. Memory virtualization setup (hyp mode mappings and 2nd stage)
6. Inject IRQs and FIQs from userspace
7. World-switch implementation and Hyp exception vectors
8. Emulation framework and coproc emulation
9. Coproc user space API
10. Demux multiplexed coproc registers
11. User spac API to get/set VFP registers
12. Handle guest user memory aborts
13. Handle guest MMIO aborts
14. Support PSCI interface
15. Add an entry in the MAINTAINERS file
Testing:
Tested on the Versatile Express TC2 devboard and on the Arndale board.
running simultaenous VMs, all running SMP, on an SMP host, each
VM running hackbench and cyclictest and with extreme memory pressure
applied to the host with swapping enabled to provoke page eviction.
Also tested KSM merging swapping on the host. Fully boots both Ubuntu
(user space Thumb-2) and Debian (user space ARM) guests each of which
can run a number of worloads like apache, mysql, kernel compile, network
tests, and more.
For a guide on how to set up a testing environment and try out these
patches, see:
http://www.virtualopensystems.com/media/pdf/kvm-arm-guide.pdf
Changes since v15:
- Removed load/store MMIO instruction decoding
- Remove unused memory slot parameter from io_mem_abort
- Grab kvm->srcu lock when needed
- Minor fixes to world-switch code
- Minor fixes and updates from reviewers
- Reuse kvm_call_hyp in vcpu_init_hyp_mode
- Enable dcaches in hyp mode
- Add PSCI support
- Move one-time init to its own function in the run loop
- Add trace event for HVC calls
Changes since v14:
- Fixed permission fault handling by correctly retrieving the IPA on
Stage-2 permission faults
- Fix compile error when !CONFIG_KVM_ARM_HOST
- Support building into separate object directory
- Fixed the Vodoo Bug (see
https://github.com/virtualopensystems/linux-kvm-arm/wiki/Voodoo-Bug)
- Improved some tracepoint debugs
- Improved and cleaned up VTCR and VTTBR initialization
- Clarified and unified Stage-2 page table clearing
- Addressed a large number of concerns from Will Deacon's review,
including fixing a race condition and removing unused exports.
- Be a little more verbose when something goes wrong during the init
process.
Changes since v13:
- Fix VTTBR mask bug
- Change KVM_MAX_VCPUS to config option (defualt 4)
- Go back to struct pt_regs in kvm_regs struct
- Factor out mmio instruction decoding to a separate file with non
kvm-specific data structures as the interface.
- Update kvm_device_address struct to use 64-bit fields
- Various cleanups and compile fixes
Changes since v12:
- Documentation updates
- Change Hyp-ABI to function call based paradigm
- Cleanup world-switch code
- Unify HIFAR/HDFAR on the vcpu struct
- Simplify vcpu register access in sofware
- Enforce use of vcpu field accessors
- Factor out mmio handling into separate file
- Check for overlaps in mmio address mappings
- Bugfix in mmio decoding
- Complete rework of ARM mmio load/store instruction
Changes since v11:
- Memory setup and page table defines reworked
- We do not export unused perf bitfields anymore
- No module support anymore and following cleanup
- Hide vcpu register accessors
- Fix unmap range mmu notifier race condition
- Factored out A15 coprocs in separate file
- Factored out world-switch assembly macros to separate file
- Add dmux of multiplexed coprocs to user space
- Add VFP get/set interface to user space
- Addressed various cleanup comments from reviewers
Changes since v10:
- Boot in Hyp mode and user HVC to initialize HVBAR
- Support VGIC
- Support Arch timers
- Support Thumb-2 mmio instruction decoding
- Transition to GET_ONE/SET_ONE register API
- Added KVM_VCPU_GET_REG_LIST
- New interrupt injection API
- Don't pin guest pages anymore
- Fix race condition in page fault handler
- Cleanup guest instruction copying.
- Fix race when copying SMP guest instructions
- Inject data/prefetch aborts when guest does something strange
Changes since v9:
- Addressed reviewer comments (see mailing list archive)
- Limit the user of .arch_extensiion sec/virt for compilers that need them
- VFP/Neon Support (Antonios Motakis)
- Run exit handling under preemption and still handle guest cache ops
- Add support for IO mapping at Hyp level (VGIC prep)
- Add support for IO mapping at Guest level (VGIC prep)
- Remove backdoor call to irq_svc
- Complete rework of CP15 handling and register reset (Rusty Russell)
- Don't use HSTR for anything else than CR 15
- New ioctl to set emulation target core (only A15 supported for now)
- Support KVM_GET_MSRS / KVM_SET_MSRS
- Add page accounting and page table eviction
- Change pgd lock to spinlock and fix sleeping in atomic bugs
- Check kvm_condition_valid for HVC traps of undefs
- Added a naive implementation of kvm_unmap_hva_range
Changes since v8:
- Support cache maintenance on SMP through set/way
- Hyp mode idmaps are now section based and happen at kernel init
- Handle aborts in Hyp mode
- Inject undefined exceptions into the guest on error
- Kernel-side reset of all crucial registers
- Specifically state which target CPU is being virtualized
- Exit statistics in debugfs
- Some L2CTLR cp15 emulation cleanups
- Support spte_hva for MMU notifiers and take write faults
- FIX: Race condition in VMID generation
- BUG: Run exit handling code with disabled preemption
- Save/Restore abort fault register during world switch
Changes since v7:
- Traps accesses to ACTLR
- Do not trap WFE execution
- Upgrade barriers and TLB operations to inner-shareable domain
- Restrucure hyp_pgd related code to be more opaque
- Random SMP fixes
- Random BUG fixes
- Improve commenting
- Support module loading/unloading of KVM/ARM
- Thumb-2 support for host kernel and KVM
- Unaligned cross-page wide guest Thumb instruction fetching
- Support ITSTATE fields in CPSR for Thumb guests
- Document HCR settings
Changes since v6:
- Support for MMU notifiers to not pin user pages in memory
- Suport build with log debugging
- Bugfix: v6 clobbered r7 in init code
- Simplify hyp code mapping
- Cleanup of register access code
- Table-based CP15 emulation from Rusty Russell
- Various other bug fixes and cleanups
Changes since v6:
- General bugfixes and nit fixes from reviews
- Implemented re-use of VMIDs
- Cleaned up the Hyp-mapping code to be readable by non-mm hackers
(including myself)
- Integrated preliminary SMP support in base patches
- Lock-less interrupt injection and WFI support
- Fixed signal-handling in while in guest (increases overall stability)
Changes since v4:
- Addressed reviewer comments from v4
* cleanup debug and trace code
* remove printks
* fixup kvm_arch_vcpu_ioctl_run
* add trace details to mmio emulation
- Fix from Marc Zyngier: Move kvm_guest_enter/exit into non-preemptible
section (squashed into world-switch patch)
- Cleanup create_hyp_mappings/remove_hyp_mappings from Marc Zyngier
(squashed into hypervisor initialization patch)
- Removed the remove_hyp_mappings feature. Removing hypervisor mappings
could potentially unmap other important data shared in the same page.
- Removed the arm_ prefix from the arch-specific files.
- Initial SMP host/guest support
Changes since v3:
- v4 actually works, fully boots a guest
- Support compiling as a module
- Use static inlines instead of macros for vcpu_reg and friends
- Optimize kvm_vcpu_reg function
- Use Ftrace for trace capabilities
- Updated documentation and commenting
- Use KVM_IRQ_LINE instead of KVM_INTERRUPT
- Emulates load/store instructions not supported through HSR
syndrome information.
- Frees 2nd stage translation tables on VM teardown
- Handles IRQ/FIQ instructions
- Handles more CP15 accesses
- Support guest WFI calls
- Uses debugfs instead of /proc
- Support compiling in Thumb mode
Changes since v2:
- Performs world-switch code
- Maps guest memory using 2nd stage translation
- Emulates co-processor 15 instructions
- Forwards I/O faults to QEMU.
---
Christoffer Dall (13):
ARM: Add page table and page defines needed by KVM
ARM: Section based HYP idmap
KVM: ARM: Initial skeleton to compile KVM support
KVM: ARM: Hypervisor initialization
KVM: ARM: Memory virtualization setup
KVM: ARM: Inject IRQs and FIQs from userspace
KVM: ARM: World-switch implementation
KVM: ARM: Emulation framework and CP15 emulation
trom: Christoffer Dall <c.dall@virtualopensystems.com>
KVM: ARM: Demux CCSIDR in the userspace API
KVM: ARM: Handle guest faults in KVM
KVM: ARM: Handle I/O aborts
KVM: ARM: Add maintainer entry for KVM/ARM
Marc Zyngier (1):
KVM: ARM: Power State Coordination Interface implementation
Rusty Russell (1):
KVM: ARM: VFP userspace interface
Documentation/virtual/kvm/api.txt | 99 ++-
MAINTAINERS | 8
arch/arm/Kconfig | 2
arch/arm/Makefile | 1
arch/arm/include/asm/idmap.h | 1
arch/arm/include/asm/kvm_arm.h | 214 ++++++
arch/arm/include/asm/kvm_asm.h | 84 ++
arch/arm/include/asm/kvm_coproc.h | 47 +
arch/arm/include/asm/kvm_emulate.h | 67 ++
arch/arm/include/asm/kvm_host.h | 161 ++++
arch/arm/include/asm/kvm_mmio.h | 56 +
arch/arm/include/asm/kvm_mmu.h | 50 +
arch/arm/include/asm/kvm_psci.h | 23 +
arch/arm/include/asm/pgtable-3level-hwdef.h | 5
arch/arm/include/asm/pgtable-3level.h | 18
arch/arm/include/asm/pgtable.h | 7
arch/arm/include/uapi/asm/kvm.h | 164 ++++
arch/arm/kernel/asm-offsets.c | 25 +
arch/arm/kernel/vmlinux.lds.S | 6
arch/arm/kvm/Kconfig | 56 +
arch/arm/kvm/Makefile | 21 +
arch/arm/kvm/arm.c | 1010 ++++++++++++++++++++++++++
arch/arm/kvm/coproc.c | 1046 +++++++++++++++++++++++++++
arch/arm/kvm/coproc.h | 153 ++++
arch/arm/kvm/coproc_a15.c | 162 ++++
arch/arm/kvm/emulate.c | 373 ++++++++++
arch/arm/kvm/guest.c | 222 ++++++
arch/arm/kvm/init.S | 114 +++
arch/arm/kvm/interrupts.S | 493 +++++++++++++
arch/arm/kvm/interrupts_head.S | 441 +++++++++++
arch/arm/kvm/mmio.c | 153 ++++
arch/arm/kvm/mmu.c | 787 ++++++++++++++++++++
arch/arm/kvm/psci.c | 105 +++
arch/arm/kvm/reset.c | 74 ++
arch/arm/kvm/trace.h | 235 ++++++
arch/arm/mm/idmap.c | 55 +
arch/arm/mm/mmu.c | 22 +
include/uapi/linux/kvm.h | 9
38 files changed, 6549 insertions(+), 20 deletions(-)
create mode 100644 arch/arm/include/asm/kvm_arm.h
create mode 100644 arch/arm/include/asm/kvm_asm.h
create mode 100644 arch/arm/include/asm/kvm_coproc.h
create mode 100644 arch/arm/include/asm/kvm_emulate.h
create mode 100644 arch/arm/include/asm/kvm_host.h
create mode 100644 arch/arm/include/asm/kvm_mmio.h
create mode 100644 arch/arm/include/asm/kvm_mmu.h
create mode 100644 arch/arm/include/asm/kvm_psci.h
create mode 100644 arch/arm/include/uapi/asm/kvm.h
create mode 100644 arch/arm/kvm/Kconfig
create mode 100644 arch/arm/kvm/Makefile
create mode 100644 arch/arm/kvm/arm.c
create mode 100644 arch/arm/kvm/coproc.c
create mode 100644 arch/arm/kvm/coproc.h
create mode 100644 arch/arm/kvm/coproc_a15.c
create mode 100644 arch/arm/kvm/emulate.c
create mode 100644 arch/arm/kvm/guest.c
create mode 100644 arch/arm/kvm/init.S
create mode 100644 arch/arm/kvm/interrupts.S
create mode 100644 arch/arm/kvm/interrupts_head.S
create mode 100644 arch/arm/kvm/mmio.c
create mode 100644 arch/arm/kvm/mmu.c
create mode 100644 arch/arm/kvm/psci.c
create mode 100644 arch/arm/kvm/reset.c
create mode 100644 arch/arm/kvm/trace.h
--
^ permalink raw reply
* [PATCH] ata: sata_mv: fix sg_tbl_pool alignment
From: Jason Cooper @ 2013-01-16 17:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F6DDF7.9080605@web.de>
On Wed, Jan 16, 2013 at 06:05:59PM +0100, Soeren Moch wrote:
> On 16.01.2013 16:50, Jason Cooper wrote:
> >On Wed, Jan 16, 2013 at 09:55:55AM +0100, Soeren Moch wrote:
> >>On 16.01.2013 04:24, Soeren Moch wrote:
> >>>On 16.01.2013 03:40, Jason Cooper wrote:
> >>>>On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
> >>>>>On 15.01.2013 22:56, Jason Cooper wrote:
> >>>>>>On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
> >
> >>OK, I could trigger the error
> >> ERROR: 1024 KiB atomic DMA coherent pool is too small!
> >> Please increase it with coherent_pool= kernel parameter!
> >>only with em28xx sticks and sata, dib0700 sticks removed.
> >
> >Did you test the reverse scenario? ie dib0700 with sata_mv and no
> >em28xx.
>
> Maybe I can test this next night.
Please do, this will tell us if it is in the USB drivers or lower
(something in common).
> >>>>What would be most helpful is if you could do a git bisect between
> >>>>v3.5.x (working) and the oldest version where you know it started
> >>>>failing (v3.7.1 or earlier if you know it).
> >>>>
> >>>I did not bisect it, but Marek mentioned earlier that commit
> >>>e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
> >>>new code for dma allocations. This is probably the root cause for the
> >>>new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
> >>
> >>I don't want to say that Mareks patch is wrong, probably it triggers a
> >>bug somewhere else! (in em28xx?)
> >
> >Of the four drivers you listed, none are using dma. sata_mv is the only
> >one.
>
> usb_core is doing the actual DMA for the usb bridge drivers, I think.
Yes, my mistake. I'd like to attribute that statement to pre-coffee
rambling. :-)
> >If one is to believe the comments in sata_mv.c:~151, then the alignment
> >is wrong for the sg_tbl_pool.
> >
> >Could you please try the following patch?
>
> OK, what should I test first, the setup from last night (em28xx, no
> dib0700) plus your patch, or the reverse setup (dib0700, no em28xx)
> without your patch, or my normal setting (all dvb sticks) plus your
> patch?
if testing time is limited, please do the test I outlined at the top of
this email. I've been digging more into the dma code and while I think
the patch is correct, I don't see where it would fix your problem (yet).
thx,
Jason.
^ permalink raw reply
* [PATCH v2] drivers/pinctrl: grab default handles from device core
From: Stephen Warren @ 2013-01-16 17:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdbFH6RCEEnXO=A9FVa0B5rtE9RkjXz9Hhy+w7NvwcBCgg@mail.gmail.com>
On 01/11/2013 01:45 PM, Linus Walleij wrote:
> On Fri, Jan 11, 2013 at 9:36 PM, Laurent Pinchart
> <laurent.pinchart@ideasonboard.com> wrote:
>
>> I've sent several patch series for the SH PFC (Pin Function Controller) to the
>> linux-sh mailing list. One of the series included pinctrl core patches for
>> easier testing, but I made it clear that they should *not* be pushed to
>> mainline through the SH tree.
>
> No big deal, what fun is linux-next if we don't break it ;-)
Hmm. It's causing a lot of engineers here a lot of trouble, since they
all see linux-next won't boot, and haven't been paying enough attention
to know which commit to revert:-(. Lots of lost productivity:-(
Simon, the offending commit:
6d3ef6b drivers/pinctrl: grab default handles from device core
is still in next-20130116. Can you please remove it?
Or does it make sense for Stephen Rothwell to revert it when building
linux-next?
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Jason Cooper @ 2013-01-16 17:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F6E419.5080007@web.de>
On Wed, Jan 16, 2013 at 06:32:09PM +0100, Soeren Moch wrote:
> On 16.01.2013 09:55, Soeren Moch wrote:
> >On 16.01.2013 04:24, Soeren Moch wrote:
> >>I did not bisect it, but Marek mentioned earlier that commit
> >>e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
> >>new code for dma allocations. This is probably the root cause for the
> >>new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
> >
> >I don't want to say that Mareks patch is wrong, probably it triggers a
> >bug somewhere else! (in em28xx?)
>
> The em28xx sticks are using isochronous usb transfers. Is there a
> special handling for that?
I'm looking at that now. It looks like the em28xx wants (as a maximum)
655040 bytes (em28xx-core.c:1088). There are 5 transfer buffers, with
64 max packets and 2047 max packet size (runtime reported max & 0x7ff).
If it actually needs all of that, then the answer may be to just
increase coherent_pool= when using that driver. I'll keep digging.
thx,
Jason.
^ permalink raw reply
* [PATCH] [RFC] ARM: compile fix for DEBUG_LL=y && MMU=n
From: Stephen Warren @ 2013-01-16 17:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358346726-27199-1-git-send-email-u.kleine-koenig@pengutronix.de>
On 01/16/2013 07:32 AM, Uwe Kleine-K?nig wrote:
> debug_ll_addr is only used on machines with an MMU so it can be #ifdef'ed
> out safely. This fixes:
>
> arch/arm/kernel/debug.S: Assembler messages:
> arch/arm/kernel/debug.S:104: Error: too many positional arguments
>
> Signed-off-by: Uwe Kleine-K?nig <u.kleine-koenig@pengutronix.de>
> Cc: Rob Herring <rob.herring@calxeda.com>
> Cc: Stephen Warren <swarren@nvidia.com>
> Cc: Olof Johansson <olof@lixom.net>
> ---
> The obvious alternative fix is to make addruart on !MMU take 3
> arguments, too.
>
> The problem was introduced in
>
> e5c5f2a (ARM: implement debug_ll_io_init())
It may be useful to mention that in the commit message.
Sorry for the breakage. Are there any ARM defconfigs for !MMU?
Reviewed-by: Stephen Warren <swarren@nvidia.com>
(although should the second copy of debug_ll_addr at the end of the file
be ifdef'd away too; the one for CONFIG_DEBUG_SEMIHOSTING)?
^ permalink raw reply
* linux-next: manual merge of the tegra tree with the arm-soc tree
From: Olof Johansson @ 2013-01-16 17:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F6DE9D.5080906@wwwdotorg.org>
On Wed, Jan 16, 2013 at 9:08 AM, Stephen Warren <swarren@wwwdotorg.org> wrote:
> On 01/16/2013 09:27 AM, Olof Johansson wrote:
>> Hi,
>>
>> On Tue, Jan 15, 2013 at 8:52 PM, Tony Prisk <linux@prisktech.co.nz> wrote:
>>> On Tue, 2013-01-15 at 21:32 -0700, Stephen Warren wrote:
>>>> On 01/15/2013 08:49 PM, Tony Prisk wrote:
>>>>> On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> Today's linux-next merge of the tegra tree got a conflict in
>>>>>> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500:
>>>>>> Move timer code to drivers/clocksource") from the arm-soc tree and commit
>>>>>> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
>>>>>> the tegra tree.
>>>>>>
>>>>>> I fixed it up (see below) and can carry the fix as necessary (no action
>>>>>> is required).
>>>>>>
>>>>>
>>>>> I don't know about everyone else, but I feel the preference should be to
>>>>> keep things alphabetized where possible to help avoid with merge
>>>>> conflicts later on. This is always a problem when we start tacking
>>>>> things on the end of lists.
>>>>>
>>>>> I realise this Kconfig is not alphabetized anyway, but it's never too
>>>>> early to start on the 'right' path.
>>>>
>>>> Sounds like a good idea, but the issue is: When to do the initial sort
>>>> so it doesn't conflict with all the adds in a kernel cycle... Post and
>>>> immediately commit a new patch near the end of the merge window?
>>>
>>> Given that the maintainer can quite safely do the patch (sorry
>>> maintainers), I don't see any reason why it couldn't be done at the
>>> point where they stop accepting patches for the merge-window. Once the
>>> patches are stopped, sort the list in one last patch.
>
> That only works well if the one maintainer is the only person taking
> patches for the drivers/clocksource tree. It might be true that the "one
> maintainer" here ends up being arm-soc in this kernel cycle though?
I'll send a patch to Linus at the end of the merge window, no need to
do it through a merge -- that way it's trivial for him to fixup a
merge conflict (and he can refuse to take it if he feels it's silly).
>>> It makes sense to get it done in this window if possible as the Kconfig
>>> will only get bigger as time goes on, making sorting it more time
>>> consuming.
>>
>> Actually, Russell wen through and reordered these not long ago, if I
>> remember correctly. The current ordering is the same as in the
>> structure definition, and should be kept that way.
>
> I think this is talking about Makefile entries rather than struct
> definitions?
Ah, yes, they should be sorted. But definitely not right now since
it'll just make things worse.
-Olof
^ permalink raw reply
* [PATCH v2] mm: dmapool: use provided gfp flags for all dma_alloc_coherent() calls
From: Soeren Moch @ 2013-01-16 17:32 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F66B1B.40301@web.de>
On 16.01.2013 09:55, Soeren Moch wrote:
> On 16.01.2013 04:24, Soeren Moch wrote:
>> On 16.01.2013 03:40, Jason Cooper wrote:
>>> Soeren,
>>>
>>> On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
>>>> On 15.01.2013 22:56, Jason Cooper wrote:
>>>>> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>>>>>> If my understanding is correct, one of the drivers (most likely one)
>>>>>> either asks for too small of a dma buffer, or is not properly
>>>>>> deallocating blocks from the per-device pool. Either case leads to
>>>>>> exhaustion, and falling back to the atomic pool. Which subsequently
>>>>>> gets wiped out as well.
>>>>>
>>>>> If my hunch is right, could you please try each of the three dvb
>>>>> drivers
>>>>> in turn and see which one (or more than one) causes the error?
>>>>
>>>> In fact I use only 2 types of DVB sticks: em28xx usb bridge plus drxk
>>>> demodulator, and dib0700 usb bridge plus dib7000p demod.
>>>>
>>>> I would bet for em28xx causing the error, but this is not thoroughly
>>>> tested. Unfortunately testing with removed sticks is not easy, because
>>>> this is a production system and disabling some services for the long
>>>> time we need to trigger this error will certainly result in unhappy
>>>> users.
>>>
> OK, I could trigger the error
> ERROR: 1024 KiB atomic DMA coherent pool is too small!
> Please increase it with coherent_pool= kernel parameter!
> only with em28xx sticks and sata, dib0700 sticks removed.
>
>>> Just out of curiosity, what board is it?
>>
>> The kirkwood board? A modified Guruplug Server Plus.
> em28xx sticks: "TerraTec Cinergy HTC Stick HD" and "PCTV Quatro Stick"
> dib0700 sticks: "WinTV-NOVA-TD Stick"
>>>
>>>> I will see what I can do here. Is there an easy way to track the buffer
>>>> usage without having to wait for complete exhaustion?
>>>
>>> DMA_API_DEBUG
>>
>> OK, maybe I can try this.
>>>
>>>> In linux-3.5.x there is no such problem. Can we use all available
>>>> memory
>>>> for dma buffers here on armv5 architectures, in contrast to newer
>>>> kernels?
>>>
>>> Were the loads exactly the same when you tested 3.5.x?
>>
>> Exactly the same, yes.
>>
>>> I looked at the
>>> changes from v3.5 to v3.7.1 for all four drivers you mentioned as well
>>> as sata_mv.
>>>
>>> The biggest thing I see is that all of the media drivers got shuffled
>>> around into their own subdirectories after v3.5. 'git show -M 0c0d06c'
>>> shows it was a clean copy of all the files.
>>>
>>> What would be most helpful is if you could do a git bisect between
>>> v3.5.x (working) and the oldest version where you know it started
>>> failing (v3.7.1 or earlier if you know it).
>>>
>> I did not bisect it, but Marek mentioned earlier that commit
>> e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
>> new code for dma allocations. This is probably the root cause for the
>> new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
>
> I don't want to say that Mareks patch is wrong, probably it triggers a
> bug somewhere else! (in em28xx?)
The em28xx sticks are using isochronous usb transfers. Is there a
special handling for that?
>> I'm not very familiar with arm mm code, and from the patch itself I
>> cannot understand what's different. Maybe CONFIG_CMA is default
>> also for armv5 (not only v6) now? But I might be totally wrong here,
>> maybe someone of the mm experts can explain the difference?
>>
Regards,
Soeren
^ permalink raw reply
* [PATCH v4 5/9] ARM: Tegra: Define Tegra30 CAR binding
From: Stephen Warren @ 2013-01-16 17:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116132856.2896df94f553f78273c4574c@nvidia.com>
On 01/16/2013 04:28 AM, Hiroshi Doyu wrote:
> On Fri, 11 Jan 2013 08:46:23 +0100
> Prashant Gaikwad <pgaikwad@nvidia.com> wrote:
>
>> The device tree binding models Tegra30 CAR (Clock And Reset)
>> as a single monolithic clock provider.
>> diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt b/Documentation/devicetree/bindings/clock/nvidia,tegra30-car.txt
>> +Example board file:
>> +
>> +/ {
>> + clocks {
>> + compatible = "simple-bug";
>
> typo, 's/simple-bug/simple-bus/' ?
It was rather accurate though; a simple bug:-)
I've squashed the fix into the patch.
^ permalink raw reply
* [PATCH v2 03/10] ARM: dt: tegra30: Add clock information
From: Stephen Warren @ 2013-01-16 17:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50F65E4B.8040409@nvidia.com>
On 01/16/2013 01:01 AM, Terje Bergstr?m wrote:
> On 11.01.2013 10:01, Prashant Gaikwad wrote:
>> diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
>> index 6765646..c3e129a 100644
>> --- a/arch/arm/boot/dts/tegra30.dtsi
>> +++ b/arch/arm/boot/dts/tegra30.dtsi
>> gr3d {
>> compatible = "nvidia,tegra30-gr3d";
>> reg = <0x54180000 0x00040000>;
>> + clocks = <&tegra_car 24>;
>> };
>
> In Tegra3, 3D has two clocks. I believe you'd need to add <&tegra_car
> 98> here.
Thanks. I've squashed the following into the patch. Do those clock names
make sense to you?
diff --git a/arch/arm/boot/dts/tegra30.dtsi b/arch/arm/boot/dts/tegra30.dtsi
index b9709ae..c26d75b 100644
--- a/arch/arm/boot/dts/tegra30.dtsi
+++ b/arch/arm/boot/dts/tegra30.dtsi
@@ -54,7 +54,8 @@
gr3d {
compatible = "nvidia,tegra30-gr3d";
reg = <0x54180000 0x00040000>;
- clocks = <&tegra_car 24>;
+ clocks = <&tegra_car 24 &tegra_car 98>;
+ clock-names = "3d", "3d2";
};
dc at 54200000 {
^ permalink raw reply related
* linux-next: manual merge of the tegra tree with the arm-soc tree
From: Stephen Warren @ 2013-01-16 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOesGMgr_f-XGHOdMW3ugfXbVaUc4EALrbfJD=XeOKixxrY8PA@mail.gmail.com>
On 01/16/2013 09:27 AM, Olof Johansson wrote:
> Hi,
>
> On Tue, Jan 15, 2013 at 8:52 PM, Tony Prisk <linux@prisktech.co.nz> wrote:
>> On Tue, 2013-01-15 at 21:32 -0700, Stephen Warren wrote:
>>> On 01/15/2013 08:49 PM, Tony Prisk wrote:
>>>> On Wed, 2013-01-16 at 14:14 +1100, Stephen Rothwell wrote:
>>>>> Hi all,
>>>>>
>>>>> Today's linux-next merge of the tegra tree got a conflict in
>>>>> drivers/clocksource/Makefile between commit ff7ec345f0ec ("timer: vt8500:
>>>>> Move timer code to drivers/clocksource") from the arm-soc tree and commit
>>>>> ac0fd9eca3ba ("ARM: tegra: move timer.c to drivers/clocksource/") from
>>>>> the tegra tree.
>>>>>
>>>>> I fixed it up (see below) and can carry the fix as necessary (no action
>>>>> is required).
>>>>>
>>>>
>>>> I don't know about everyone else, but I feel the preference should be to
>>>> keep things alphabetized where possible to help avoid with merge
>>>> conflicts later on. This is always a problem when we start tacking
>>>> things on the end of lists.
>>>>
>>>> I realise this Kconfig is not alphabetized anyway, but it's never too
>>>> early to start on the 'right' path.
>>>
>>> Sounds like a good idea, but the issue is: When to do the initial sort
>>> so it doesn't conflict with all the adds in a kernel cycle... Post and
>>> immediately commit a new patch near the end of the merge window?
>>
>> Given that the maintainer can quite safely do the patch (sorry
>> maintainers), I don't see any reason why it couldn't be done at the
>> point where they stop accepting patches for the merge-window. Once the
>> patches are stopped, sort the list in one last patch.
That only works well if the one maintainer is the only person taking
patches for the drivers/clocksource tree. It might be true that the "one
maintainer" here ends up being arm-soc in this kernel cycle though?
>> It makes sense to get it done in this window if possible as the Kconfig
>> will only get bigger as time goes on, making sorting it more time
>> consuming.
>
> Actually, Russell wen through and reordered these not long ago, if I
> remember correctly. The current ordering is the same as in the
> structure definition, and should be kept that way.
I think this is talking about Makefile entries rather than struct
definitions?
^ permalink raw reply
* [PATCH 8/8] ARM: shmobile: completely switch MMC interfaces on armadillo800eva-reference to DT
From: Guennadi Liakhovetski @ 2013-01-16 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358356097-26180-1-git-send-email-g.liakhovetski@gmx.de>
Switch MMCIF, SDHI0 and SDHI1 to complete DT initialisation: use DT
bindings to configure regulators, interface pins, card-detect GPIOs,
various interface configuration parameters.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
.../boot/dts/r8a7740-armadillo800eva-reference.dts | 101 ++++++++++++++++++++
.../board-armadillo800eva-reference.c | 5 +-
2 files changed, 103 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
index 319af9b..27774eb 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva-reference.dts
@@ -30,4 +30,105 @@
sh-eth,register-type = "gigabit";
sh-eth,phy-id = <0>;
};
+
+ reg_3p3v: regulator at 0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-3.3V";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ };
+
+ mmcif0: mmcif at 0xe6bd0000 {
+ compatible = "renesas,sh-mmcif", "renesas,sh7372-mmcif";
+ reg = <0xe6bd0000 0x100>;
+ interrupt-parent = <&intca>;
+ interrupts = <0x1ac0 0x1ae0>;
+ vmmc-supply = <®_3p3v>;
+ bus-width = <8>;
+ non-removable;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
+ };
+
+ vcc_sdhi0: regulator at 1 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vcc-sdhi0";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&gpio 75 0>;
+ enable-active-high;
+ };
+
+ vcc_sdhi1: regulator at 2 {
+ compatible = "regulator-fixed";
+
+ regulator-name = "vcc-sdhi1";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+
+ gpio = <&gpio 16 0>;
+ enable-active-high;
+ };
+
+ vccq_sdhi0: gpio-regulator at 0 {
+ compatible = "regulator-gpio";
+
+ regulator-name = "vccq-sdhi0";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <3300000>;
+ vin-supply = <&vcc_sdhi0>;
+
+ enable-gpio = <&gpio 74 0>;
+ gpios = <&gpio 17 0>;
+ states = <3300000 0
+ 1800000 1>;
+
+ enable-active-high;
+ };
+
+ sdhi0: sdhi at 0xe6850000 {
+ compatible = "renesas,shmobile-sdhi";
+ reg = <0xe6850000 0x100>;
+ interrupt-parent = <&intca>;
+ interrupts = <0xe20 0xe40>;
+ vmmc-supply = <&vcc_sdhi0>;
+ vqmmc-supply = <&vccq_sdhi0>;
+ bus-width = <4>;
+ cd-gpios = <&gpio 167 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhi0_pins>;
+ toshiba,mmc-has-idle-wait;
+ toshiba,mmc-cap-sdio-irq;
+ };
+
+ sdhi1: sdhi at 0xe6860000 {
+ compatible = "renesas,shmobile-sdhi";
+ reg = <0xe6860000 0x100>;
+ interrupt-parent = <&intca>;
+ interrupts = <0xea0 0xec0>;
+ vmmc-supply = <&vcc_sdhi1>;
+ bus-width = <4>;
+ cd-gpios = <&gpio 72 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhi1_pins>;
+ toshiba,mmc-has-idle-wait;
+ toshiba,mmc-cap-sdio-irq;
+ };
+};
+
+&gpio {
+ sdhi0_pins: pfc_sdhi0_pins {
+ renesas,pins = "sdhi0_data4", "sdhi0_ctrl", "sdhi0_wp";
+ renesas,function = "sdhi0";
+ };
+ sdhi1_pins: pfc_sdhi1_pins {
+ renesas,pins = "sdhi1_data4", "sdhi1_ctrl", "sdhi1_wp";
+ renesas,function = "sdhi1";
+ };
+ mmc0_pins: pfc_mmc0_pins {
+ renesas,pins = "mmc0_data8_1", "mmc0_ctrl_1";
+ renesas,function = "mmc0";
+ };
};
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
index c206612..f929931 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva-reference.c
@@ -107,9 +107,10 @@
*/
static void __init eva_init(void)
{
- r8a7740_pinmux_init();
r8a7740_meram_workaround();
+ r8a7740_add_standard_devices_dt();
+
/* SCIFA1 */
gpio_request(GPIO_FN_SCIFA1_RXD, NULL);
gpio_request(GPIO_FN_SCIFA1_TXD, NULL);
@@ -142,8 +143,6 @@ static void __init eva_init(void)
/* Early BRESP enable, Shared attribute override enable, 32K*8way */
l2x0_init(IOMEM(0xf0002000), 0x40440000, 0x82000fff);
#endif
-
- r8a7740_add_standard_devices_dt();
}
#define RESCNT2 IOMEM(0xe6188020)
--
1.7.2.5
^ permalink raw reply related
* [PATCH 7/8] ARM: shmobile: completely switch MMC interfaces on mackerel-reference to DT
From: Guennadi Liakhovetski @ 2013-01-16 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358356097-26180-1-git-send-email-g.liakhovetski@gmx.de>
Switch MMCIF, SDHI0 and SDHI2 to complete DT initialisation: use DT
bindings to configure interface pins, card-detect GPIOs, various
interface configuration parameters. Notice, since MMCIF and SDHI1 share
the same card slot, both devices cannot be successfully probed
simultaneously: they both would try to get the card-detection GPIO and only
one would succeed. Ideally it should be possible to let the user decide
which device to enable by, possibly, patching the DT at run-time. As long as
this is unsupported, we choose to enable MMCIF and remove SDHI1 from DT
completely.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
arch/arm/boot/dts/sh7372-mackerel-reference.dts | 42 +++++++++++++++----
arch/arm/mach-shmobile/board-mackerel-reference.c | 46 ---------------------
2 files changed, 33 insertions(+), 55 deletions(-)
diff --git a/arch/arm/boot/dts/sh7372-mackerel-reference.dts b/arch/arm/boot/dts/sh7372-mackerel-reference.dts
index 2fd1eff..aa72309 100644
--- a/arch/arm/boot/dts/sh7372-mackerel-reference.dts
+++ b/arch/arm/boot/dts/sh7372-mackerel-reference.dts
@@ -75,6 +75,11 @@
interrupt-parent = <&intca>;
interrupts = <0x1ac0 0x1ae0>;
vmmc-supply = <®_1p8v>;
+ bus-width = <8>;
+ cd-gpios = <&gpio 41 1>;
+ broken-cd;
+ pinctrl-names = "default";
+ pinctrl-0 = <&mmc0_pins>;
};
sdhi0: sdhi at 0xe6850000 {
@@ -83,22 +88,26 @@
interrupt-parent = <&intca>;
interrupts = <0x0e00 0x0e20 0x0e40>;
vmmc-supply = <®_3p3v>;
- };
-
- sdhi1: sdhi at 0xe6860000 {
- compatible = "renesas,shmobile-sdhi";
- reg = <0xe6860000 0x100>;
- interrupt-parent = <&intca>;
- interrupts = <0x0e80 0x0ea0 0x0ec0>;
- vmmc-supply = <®_1p8v>;
+ bus-width = <4>;
+ cd-gpios = <&gpio 172 1>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhi0_pins>;
+ toshiba,mmc-cap-sdio-irq;
};
sdhi2: sdhi at 0xe6870000 {
compatible = "renesas,shmobile-sdhi";
reg = <0xe6870000 0x100>;
interrupt-parent = <&intca>;
- interrupts = <0x1200 0x1220 0x1240>;
+ interrupts = <0x1220 0x1240>;
vmmc-supply = <®_3p3v>;
+ bus-width = <4>;
+ cd-gpios = <&gpio 162 1>;
+ broken-cd;
+ pinctrl-names = "default";
+ pinctrl-0 = <&sdhi2_pins>;
+ toshiba,mmc-wrprotect-disable;
+ toshiba,mmc-cap-sdio-irq;
};
flash at 2000000 {
@@ -129,3 +138,18 @@
};
};
};
+
+&gpio {
+ sdhi0_pins: pfc_sdhi0_pins {
+ renesas,pins = "sdhi0_data4", "sdhi0_ctrl", "sdhi0_wp";
+ renesas,function = "sdhi0";
+ };
+ sdhi2_pins: pfc_sdhi2_pins {
+ renesas,pins = "sdhi2_data4", "sdhi2_ctrl";
+ renesas,function = "sdhi2";
+ };
+ mmc0_pins: pfc_mmc0_pins {
+ renesas,pins = "mmc0_data8_0", "mmc0_ctrl_0";
+ renesas,function = "mmc0";
+ };
+};
diff --git a/arch/arm/mach-shmobile/board-mackerel-reference.c b/arch/arm/mach-shmobile/board-mackerel-reference.c
index 1d83653..323a812 100644
--- a/arch/arm/mach-shmobile/board-mackerel-reference.c
+++ b/arch/arm/mach-shmobile/board-mackerel-reference.c
@@ -42,8 +42,6 @@ static void __init mackerel_init(void)
/* External clock source */
clk_set_rate(&sh7372_dv_clki_clk, 27000000);
- sh7372_pinmux_init();
-
/* enable SCIFA0 */
gpio_request(GPIO_FN_SCIFA0_TXD, NULL);
gpio_request(GPIO_FN_SCIFA0_RXD, NULL);
@@ -59,50 +57,6 @@ static void __init mackerel_init(void)
/* enable Accelerometer */
gpio_request(GPIO_FN_IRQ21, NULL);
irq_set_irq_type(IRQ21, IRQ_TYPE_LEVEL_HIGH);
-
- /* enable SDHI0 */
- gpio_request(GPIO_FN_SDHIWP0, NULL);
- gpio_request(GPIO_FN_SDHICMD0, NULL);
- gpio_request(GPIO_FN_SDHICLK0, NULL);
- gpio_request(GPIO_FN_SDHID0_3, NULL);
- gpio_request(GPIO_FN_SDHID0_2, NULL);
- gpio_request(GPIO_FN_SDHID0_1, NULL);
- gpio_request(GPIO_FN_SDHID0_0, NULL);
-
- /* SDHI0 PORT172 card-detect IRQ26 */
- gpio_request(GPIO_FN_IRQ26_172, NULL);
-
- /* enable SDHI1 */
- gpio_request(GPIO_FN_SDHICMD1, NULL);
- gpio_request(GPIO_FN_SDHICLK1, NULL);
- gpio_request(GPIO_FN_SDHID1_3, NULL);
- gpio_request(GPIO_FN_SDHID1_2, NULL);
- gpio_request(GPIO_FN_SDHID1_1, NULL);
- gpio_request(GPIO_FN_SDHID1_0, NULL);
-
- /* enable SDHI2 */
- gpio_request(GPIO_FN_SDHICMD2, NULL);
- gpio_request(GPIO_FN_SDHICLK2, NULL);
- gpio_request(GPIO_FN_SDHID2_3, NULL);
- gpio_request(GPIO_FN_SDHID2_2, NULL);
- gpio_request(GPIO_FN_SDHID2_1, NULL);
- gpio_request(GPIO_FN_SDHID2_0, NULL);
-
- /* card detect pin for microSD slot (CN23) */
- gpio_request(GPIO_PORT162, NULL);
- gpio_direction_input(GPIO_PORT162);
-
- /* MMCIF */
- gpio_request(GPIO_FN_MMCD0_0, NULL);
- gpio_request(GPIO_FN_MMCD0_1, NULL);
- gpio_request(GPIO_FN_MMCD0_2, NULL);
- gpio_request(GPIO_FN_MMCD0_3, NULL);
- gpio_request(GPIO_FN_MMCD0_4, NULL);
- gpio_request(GPIO_FN_MMCD0_5, NULL);
- gpio_request(GPIO_FN_MMCD0_6, NULL);
- gpio_request(GPIO_FN_MMCD0_7, NULL);
- gpio_request(GPIO_FN_MMCCMD0, NULL);
- gpio_request(GPIO_FN_MMCCLK0, NULL);
}
static const char *mackerel_compat_dt[] __initdata = {
--
1.7.2.5
^ permalink raw reply related
* [PATCH 6/8] ARM: shmobile: use GPIO SD-card detection on armadillo800eva
From: Guennadi Liakhovetski @ 2013-01-16 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358356097-26180-1-git-send-email-g.liakhovetski@gmx.de>
Switch SDHI0 and SDHI1 SD-card interfaces on armadillo800eva to using GPIO
card detection, which provides maximum power saving and automatically
selects IRQ or polling mode, depending on the CD GPIO capability.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
arch/arm/mach-shmobile/board-armadillo800eva.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-shmobile/board-armadillo800eva.c b/arch/arm/mach-shmobile/board-armadillo800eva.c
index e657a7a..1cf1157 100644
--- a/arch/arm/mach-shmobile/board-armadillo800eva.c
+++ b/arch/arm/mach-shmobile/board-armadillo800eva.c
@@ -580,10 +580,10 @@ static struct regulator_consumer_supply fixed3v3_power_consumers[] =
static struct sh_mobile_sdhi_info sdhi0_info = {
.dma_slave_tx = SHDMA_SLAVE_SDHI0_TX,
.dma_slave_rx = SHDMA_SLAVE_SDHI0_RX,
- .tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ |\
- MMC_CAP_NEEDS_POLL,
+ .tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
.tmio_ocr_mask = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
- .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
+ .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_USE_GPIO_CD,
+ .cd_gpio = GPIO_PORT167,
};
static struct resource sdhi0_resources[] = {
@@ -624,7 +624,9 @@ static struct sh_mobile_sdhi_info sdhi1_info = {
.dma_slave_rx = SHDMA_SLAVE_SDHI1_RX,
.tmio_caps = MMC_CAP_SD_HIGHSPEED | MMC_CAP_SDIO_IRQ,
.tmio_ocr_mask = MMC_VDD_165_195 | MMC_VDD_32_33 | MMC_VDD_33_34,
- .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT,
+ .tmio_flags = TMIO_MMC_HAS_IDLE_WAIT | TMIO_MMC_USE_GPIO_CD,
+ /* Port72 cannot generate IRQs, will be used in polling mode. */
+ .cd_gpio = GPIO_PORT72,
};
static struct resource sdhi1_resources[] = {
--
1.7.2.5
^ permalink raw reply related
* [PATCH 5/8] ARM: shmobile: add a GPIO controller DT node for sh7372
From: Guennadi Liakhovetski @ 2013-01-16 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358356097-26180-1-git-send-email-g.liakhovetski@gmx.de>
Add a missing GPIO controller node to sh7372.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
arch/arm/boot/dts/sh7372.dtsi | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sh7372.dtsi b/arch/arm/boot/dts/sh7372.dtsi
index 582fdec..7ca9322 100644
--- a/arch/arm/boot/dts/sh7372.dtsi
+++ b/arch/arm/boot/dts/sh7372.dtsi
@@ -19,6 +19,14 @@
};
};
+ gpio: pfc at e6050000 {
+ compatible = "renesas,pfc-sh7372";
+ reg = <0xe6050000 0x8000>,
+ <0xe605800c 0x20>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <1>;
--
1.7.2.5
^ permalink raw reply related
* [PATCH 4/8] ARM: shmobile: add MMCIF and SDHI DT clock aliases to sh73a0 and r8a7740
From: Guennadi Liakhovetski @ 2013-01-16 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358356097-26180-1-git-send-email-g.liakhovetski@gmx.de>
Add clock lookup entries for SDHI and MMCIF device names, for the FDT case.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
arch/arm/mach-shmobile/clock-r8a7740.c | 4 ++++
arch/arm/mach-shmobile/clock-sh73a0.c | 3 +++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-shmobile/clock-r8a7740.c b/arch/arm/mach-shmobile/clock-r8a7740.c
index 8765a76..83209bf 100644
--- a/arch/arm/mach-shmobile/clock-r8a7740.c
+++ b/arch/arm/mach-shmobile/clock-r8a7740.c
@@ -611,12 +611,16 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("i2c-sh_mobile.1", &mstp_clks[MSTP323]),
CLKDEV_DEV_ID("renesas_usbhs", &mstp_clks[MSTP320]),
CLKDEV_DEV_ID("sh_mobile_sdhi.0", &mstp_clks[MSTP314]),
+ CLKDEV_DEV_ID("e6850000.sdhi", &mstp_clks[MSTP314]),
CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP313]),
+ CLKDEV_DEV_ID("e6860000.sdhi", &mstp_clks[MSTP313]),
CLKDEV_DEV_ID("sh_mmcif", &mstp_clks[MSTP312]),
+ CLKDEV_DEV_ID("e6bd0000.mmcif", &mstp_clks[MSTP312]),
CLKDEV_DEV_ID("sh-eth", &mstp_clks[MSTP309]),
CLKDEV_DEV_ID("e9a00000.sh-eth", &mstp_clks[MSTP309]),
CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP415]),
+ CLKDEV_DEV_ID("e6870000.sdhi", &mstp_clks[MSTP415]),
/* ICK */
CLKDEV_ICK_ID("host", "renesas_usbhs", &mstp_clks[MSTP416]),
diff --git a/arch/arm/mach-shmobile/clock-sh73a0.c b/arch/arm/mach-shmobile/clock-sh73a0.c
index afa5423..5fa106b 100644
--- a/arch/arm/mach-shmobile/clock-sh73a0.c
+++ b/arch/arm/mach-shmobile/clock-sh73a0.c
@@ -581,10 +581,13 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID("e6822000.i2c", &mstp_clks[MSTP323]), /* I2C1 */
CLKDEV_DEV_ID("renesas_usbhs", &mstp_clks[MSTP322]), /* USB */
CLKDEV_DEV_ID("sh_mobile_sdhi.0", &mstp_clks[MSTP314]), /* SDHI0 */
+ CLKDEV_DEV_ID("ee100000.sdhi", &mstp_clks[MSTP314]), /* SDHI0 */
CLKDEV_DEV_ID("sh_mobile_sdhi.1", &mstp_clks[MSTP313]), /* SDHI1 */
+ CLKDEV_DEV_ID("ee120000.sdhi", &mstp_clks[MSTP313]), /* SDHI1 */
CLKDEV_DEV_ID("sh_mmcif.0", &mstp_clks[MSTP312]), /* MMCIF0 */
CLKDEV_DEV_ID("e6bd0000.mmcif", &mstp_clks[MSTP312]), /* MMCIF0 */
CLKDEV_DEV_ID("sh_mobile_sdhi.2", &mstp_clks[MSTP311]), /* SDHI2 */
+ CLKDEV_DEV_ID("ee140000.sdhi", &mstp_clks[MSTP311]), /* SDHI2 */
CLKDEV_DEV_ID("leds-renesas-tpu.12", &mstp_clks[MSTP303]), /* TPU1 */
CLKDEV_DEV_ID("leds-renesas-tpu.21", &mstp_clks[MSTP302]), /* TPU2 */
CLKDEV_DEV_ID("leds-renesas-tpu.30", &mstp_clks[MSTP301]), /* TPU3 */
--
1.7.2.5
^ permalink raw reply related
* [PATCH 3/8] ARM: shmobile: simplify armadillo800eva and kzm9g Kconfig dependencies
From: Guennadi Liakhovetski @ 2013-01-16 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358356097-26180-1-git-send-email-g.liakhovetski@gmx.de>
Reference kernel configurations for armadillo800eva and kzm9g boards do not
have to depend on their respective "legacy" configurations, doing device
instantiation in .c, they can be configured and built independently.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
arch/arm/mach-shmobile/Kconfig | 12 ++++++++++--
1 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 5f61e8f..927eecc 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -106,7 +106,11 @@ config MACH_ARMADILLO800EVA
config MACH_ARMADILLO800EVA_REFERENCE
bool "Armadillo-800 EVA board - Reference Device Tree Implementation"
- depends on MACH_ARMADILLO800EVA
+ depends on ARCH_R8A7740
+ select ARCH_REQUIRE_GPIOLIB
+ select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select SND_SOC_WM8978 if SND_SIMPLE_CARD
+ select USE_OF
---help---
Use reference implementation of Aramdillo800 EVA board support
which makes a greater use of device tree at the expense
@@ -136,7 +140,11 @@ config MACH_KZM9G
config MACH_KZM9G_REFERENCE
bool "KZM-A9-GT board - Reference Device Tree Implementation"
- depends on MACH_KZM9G
+ depends on ARCH_SH73A0
+ select ARCH_REQUIRE_GPIOLIB
+ select REGULATOR_FIXED_VOLTAGE if REGULATOR
+ select SND_SOC_AK4642 if SND_SIMPLE_CARD
+ select USE_OF
---help---
Use reference implementation of KZM-A9-GT board support
which makes as greater use of device tree at the expense
--
1.7.2.5
^ permalink raw reply related
* [PATCH 2/8] pinctrl: add SDHI and MMCIF pin groups to sh7372
From: Guennadi Liakhovetski @ 2013-01-16 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358356097-26180-1-git-send-email-g.liakhovetski@gmx.de>
Add pin groups for all three SDHI interfaces and two alternative pin
groups for the MMCIF interface on the sh7372 SoC.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
drivers/pinctrl/sh-pfc/pfc-sh7372.c | 205 +++++++++++++++++++++++++++++++++++
1 files changed, 205 insertions(+), 0 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-sh7372.c b/drivers/pinctrl/sh-pfc/pfc-sh7372.c
index 847e0cd..78444a0 100644
--- a/drivers/pinctrl/sh-pfc/pfc-sh7372.c
+++ b/drivers/pinctrl/sh-pfc/pfc-sh7372.c
@@ -933,6 +933,206 @@ static struct sh_pfc_pin pinmux_pins[] = {
GPIO_PORT_ALL(),
};
+static const unsigned int sdhi0_data1_pins[] = {
+ /* D0 */
+ 173,
+};
+static const unsigned int sdhi0_data1_mux[] = {
+ SDHID0_0_MARK,
+};
+static const unsigned int sdhi0_data4_pins[] = {
+ /* D[0:3] */
+ 173, 174, 175, 176,
+};
+static const unsigned int sdhi0_data4_mux[] = {
+ SDHID0_0_MARK, SDHID0_1_MARK, SDHID0_2_MARK, SDHID0_3_MARK,
+};
+static const unsigned int sdhi0_ctrl_pins[] = {
+ /* CMD, CLK */
+ 177, 171,
+};
+static const unsigned int sdhi0_ctrl_mux[] = {
+ SDHICMD0_MARK, SDHICLK0_MARK,
+};
+static const unsigned int sdhi0_cd_pins[] = {
+ /* CD */
+ 172,
+};
+static const unsigned int sdhi0_cd_mux[] = {
+ SDHICD0_MARK,
+};
+static const unsigned int sdhi0_wp_pins[] = {
+ /* WP */
+ 178,
+};
+static const unsigned int sdhi0_wp_mux[] = {
+ SDHIWP0_MARK,
+};
+
+static const unsigned int sdhi1_data1_pins[] = {
+ /* D0 */
+ 180,
+};
+static const unsigned int sdhi1_data1_mux[] = {
+ SDHID1_0_MARK,
+};
+static const unsigned int sdhi1_data4_pins[] = {
+ /* D[0:3] */
+ 180, 181, 182, 183,
+};
+static const unsigned int sdhi1_data4_mux[] = {
+ SDHID1_0_MARK, SDHID1_1_MARK, SDHID1_2_MARK, SDHID1_3_MARK,
+};
+static const unsigned int sdhi1_ctrl_pins[] = {
+ /* CMD, CLK */
+ 184, 179,
+};
+static const unsigned int sdhi1_ctrl_mux[] = {
+ SDHICMD1_MARK, SDHICLK1_MARK,
+};
+
+static const unsigned int sdhi2_data1_pins[] = {
+ /* D0 */
+ 186,
+};
+static const unsigned int sdhi2_data1_mux[] = {
+ SDHID2_0_MARK,
+};
+static const unsigned int sdhi2_data4_pins[] = {
+ /* D[0:3] */
+ 186, 187, 188, 189,
+};
+static const unsigned int sdhi2_data4_mux[] = {
+ SDHID2_0_MARK, SDHID2_1_MARK, SDHID2_2_MARK, SDHID2_3_MARK,
+};
+static const unsigned int sdhi2_ctrl_pins[] = {
+ /* CMD, CLK */
+ 190, 185,
+};
+static const unsigned int sdhi2_ctrl_mux[] = {
+ SDHICMD2_MARK, SDHICLK2_MARK,
+};
+
+static const unsigned int mmc0_data1_0_pins[] = {
+ /* D[0] */
+ 84,
+};
+static const unsigned int mmc0_data1_0_mux[] = {
+ MMCD0_0_MARK,
+};
+static const unsigned int mmc0_data4_0_pins[] = {
+ /* D[0:3] */
+ 84, 85, 86, 87,
+};
+static const unsigned int mmc0_data4_0_mux[] = {
+ MMCD0_0_MARK, MMCD0_1_MARK, MMCD0_2_MARK, MMCD0_3_MARK,
+};
+static const unsigned int mmc0_data8_0_pins[] = {
+ /* D[0:7] */
+ 84, 85, 86, 87, 88, 89, 90, 91,
+};
+static const unsigned int mmc0_data8_0_mux[] = {
+ MMCD0_0_MARK, MMCD0_1_MARK, MMCD0_2_MARK, MMCD0_3_MARK,
+ MMCD0_4_MARK, MMCD0_5_MARK, MMCD0_6_MARK, MMCD0_7_MARK,
+};
+static const unsigned int mmc0_ctrl_0_pins[] = {
+ /* CMD, CLK */
+ 92, 99,
+};
+static const unsigned int mmc0_ctrl_0_mux[] = {
+ MMCCMD0_MARK, MMCCLK0_MARK,
+};
+
+static const unsigned int mmc0_data1_1_pins[] = {
+ /* D[0] */
+ 54,
+};
+static const unsigned int mmc0_data1_1_mux[] = {
+ MMCD1_0_MARK,
+};
+static const unsigned int mmc0_data4_1_pins[] = {
+ /* D[0:3] */
+ 54, 55, 56, 57,
+};
+static const unsigned int mmc0_data4_1_mux[] = {
+ MMCD1_0_MARK, MMCD1_1_MARK, MMCD1_2_MARK, MMCD1_3_MARK,
+};
+static const unsigned int mmc0_data8_1_pins[] = {
+ /* D[0:7] */
+ 54, 55, 56, 57, 58, 59, 60, 61,
+};
+static const unsigned int mmc0_data8_1_mux[] = {
+ MMCD1_0_MARK, MMCD1_1_MARK, MMCD1_2_MARK, MMCD1_3_MARK,
+ MMCD1_4_MARK, MMCD1_5_MARK, MMCD1_6_MARK, MMCD1_7_MARK,
+};
+static const unsigned int mmc0_ctrl_1_pins[] = {
+ /* CMD, CLK */
+ 67, 66,
+};
+static const unsigned int mmc0_ctrl_1_mux[] = {
+ MMCCMD1_MARK, MMCCLK1_MARK,
+};
+
+static const struct sh_pfc_pin_group pinmux_groups[] = {
+ SH_PFC_PIN_GROUP(sdhi0_data1),
+ SH_PFC_PIN_GROUP(sdhi0_data4),
+ SH_PFC_PIN_GROUP(sdhi0_ctrl),
+ SH_PFC_PIN_GROUP(sdhi0_cd),
+ SH_PFC_PIN_GROUP(sdhi0_wp),
+ SH_PFC_PIN_GROUP(sdhi1_data1),
+ SH_PFC_PIN_GROUP(sdhi1_data4),
+ SH_PFC_PIN_GROUP(sdhi1_ctrl),
+ SH_PFC_PIN_GROUP(sdhi2_data1),
+ SH_PFC_PIN_GROUP(sdhi2_data4),
+ SH_PFC_PIN_GROUP(sdhi2_ctrl),
+ SH_PFC_PIN_GROUP(mmc0_data1_0),
+ SH_PFC_PIN_GROUP(mmc0_data4_0),
+ SH_PFC_PIN_GROUP(mmc0_data8_0),
+ SH_PFC_PIN_GROUP(mmc0_ctrl_0),
+ SH_PFC_PIN_GROUP(mmc0_data1_1),
+ SH_PFC_PIN_GROUP(mmc0_data4_1),
+ SH_PFC_PIN_GROUP(mmc0_data8_1),
+ SH_PFC_PIN_GROUP(mmc0_ctrl_1),
+};
+
+static const char * const sdhi0_groups[] = {
+ "sdhi0_data1",
+ "sdhi0_data4",
+ "sdhi0_ctrl",
+ "sdhi0_cd",
+ "sdhi0_wp",
+};
+
+static const char * const sdhi1_groups[] = {
+ "sdhi1_data1",
+ "sdhi1_data4",
+ "sdhi1_ctrl",
+};
+
+static const char * const sdhi2_groups[] = {
+ "sdhi2_data1",
+ "sdhi2_data4",
+ "sdhi2_ctrl",
+};
+
+static const char * const mmc0_groups[] = {
+ "mmc0_data1_0",
+ "mmc0_data4_0",
+ "mmc0_data8_0",
+ "mmc0_ctrl_0",
+ "mmc0_data1_1",
+ "mmc0_data4_1",
+ "mmc0_data8_1",
+ "mmc0_ctrl_1",
+};
+
+static const struct sh_pfc_function pinmux_functions[] = {
+ SH_PFC_FUNCTION(sdhi0),
+ SH_PFC_FUNCTION(sdhi1),
+ SH_PFC_FUNCTION(sdhi2),
+ SH_PFC_FUNCTION(mmc0),
+};
+
#define PINMUX_FN_BASE ARRAY_SIZE(pinmux_pins)
static struct pinmux_func pinmux_func_gpios[] = {
@@ -1644,6 +1844,11 @@ struct sh_pfc_soc_info sh7372_pinmux_info = {
.pins = pinmux_pins,
.nr_pins = ARRAY_SIZE(pinmux_pins),
+ .groups = pinmux_groups,
+ .nr_groups = ARRAY_SIZE(pinmux_groups),
+ .functions = pinmux_functions,
+ .nr_functions = ARRAY_SIZE(pinmux_functions),
+
.func_gpios = pinmux_func_gpios,
.nr_func_gpios = ARRAY_SIZE(pinmux_func_gpios),
--
1.7.2.5
^ permalink raw reply related
* [PATCH 1/8] pinctrl: add SDHI and MMCIF pin groups to r8a7740
From: Guennadi Liakhovetski @ 2013-01-16 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1358356097-26180-1-git-send-email-g.liakhovetski@gmx.de>
Add pin groups for the first two SDHI interfaces and two alternative pin
groups for the MMCIF interface on the r8a7740 SoC.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
drivers/pinctrl/sh-pfc/pfc-r8a7740.c | 180 ++++++++++++++++++++++++++++++++++
1 files changed, 180 insertions(+), 0 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7740.c b/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
index d0b7165..5e9a671 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
@@ -1870,6 +1870,138 @@ static const unsigned int lcd1_sys_mux[] = {
LCD1_CS_MARK, LCD1_WR_MARK, LCD1_RD_MARK, LCD1_RS_MARK,
};
+static const unsigned int sdhi0_data1_pins[] = {
+ /* D0 */
+ 77,
+};
+static const unsigned int sdhi0_data1_mux[] = {
+ SDHI0_D0_MARK,
+};
+static const unsigned int sdhi0_data4_pins[] = {
+ /* D[0:3] */
+ 77, 78, 79, 80,
+};
+static const unsigned int sdhi0_data4_mux[] = {
+ SDHI0_D0_MARK, SDHI0_D1_MARK, SDHI0_D2_MARK, SDHI0_D3_MARK,
+};
+static const unsigned int sdhi0_ctrl_pins[] = {
+ /* CMD, CLK */
+ 76, 82,
+};
+static const unsigned int sdhi0_ctrl_mux[] = {
+ SDHI0_CMD_MARK, SDHI0_CLK_MARK,
+};
+static const unsigned int sdhi0_cd_pins[] = {
+ /* CD */
+ 81,
+};
+static const unsigned int sdhi0_cd_mux[] = {
+ SDHI0_CD_MARK,
+};
+static const unsigned int sdhi0_wp_pins[] = {
+ /* WP */
+ 83,
+};
+static const unsigned int sdhi0_wp_mux[] = {
+ SDHI0_WP_MARK,
+};
+
+static const unsigned int sdhi1_data1_pins[] = {
+ /* D0 */
+ 68,
+};
+static const unsigned int sdhi1_data1_mux[] = {
+ SDHI1_D0_MARK,
+};
+static const unsigned int sdhi1_data4_pins[] = {
+ /* D[0:3] */
+ 68, 69, 70, 71,
+};
+static const unsigned int sdhi1_data4_mux[] = {
+ SDHI1_D0_MARK, SDHI1_D1_MARK, SDHI1_D2_MARK, SDHI1_D3_MARK,
+};
+static const unsigned int sdhi1_ctrl_pins[] = {
+ /* CMD, CLK */
+ 67, 66,
+};
+static const unsigned int sdhi1_ctrl_mux[] = {
+ SDHI1_CMD_MARK, SDHI1_CLK_MARK,
+};
+static const unsigned int sdhi1_cd_pins[] = {
+ /* CD */
+ 72,
+};
+static const unsigned int sdhi1_cd_mux[] = {
+ SDHI1_CD_MARK,
+};
+static const unsigned int sdhi1_wp_pins[] = {
+ /* WP */
+ 73,
+};
+static const unsigned int sdhi1_wp_mux[] = {
+ SDHI1_WP_MARK,
+};
+
+static const unsigned int mmc0_data1_0_pins[] = {
+ /* D[0] */
+ 68,
+};
+static const unsigned int mmc0_data1_0_mux[] = {
+ MMC0_D0_PORT68_MARK,
+};
+static const unsigned int mmc0_data4_0_pins[] = {
+ /* D[0:3] */
+ 68, 69, 70, 71,
+};
+static const unsigned int mmc0_data4_0_mux[] = {
+ MMC0_D0_PORT68_MARK, MMC0_D1_PORT69_MARK, MMC0_D2_PORT70_MARK, MMC0_D3_PORT71_MARK,
+};
+static const unsigned int mmc0_data8_0_pins[] = {
+ /* D[0:7] */
+ 68, 69, 70, 71, 72, 73, 74, 75,
+};
+static const unsigned int mmc0_data8_0_mux[] = {
+ MMC0_D0_PORT68_MARK, MMC0_D1_PORT69_MARK, MMC0_D2_PORT70_MARK, MMC0_D3_PORT71_MARK,
+ MMC0_D4_PORT72_MARK, MMC0_D5_PORT73_MARK, MMC0_D6_PORT74_MARK, MMC0_D7_PORT75_MARK,
+};
+static const unsigned int mmc0_ctrl_0_pins[] = {
+ /* CMD, CLK */
+ 66, 67,
+};
+static const unsigned int mmc0_ctrl_0_mux[] = {
+ MMC0_CMD_PORT67_MARK, MMC0_CLK_PORT66_MARK,
+};
+
+static const unsigned int mmc0_data1_1_pins[] = {
+ /* D[0] */
+ 149,
+};
+static const unsigned int mmc0_data1_1_mux[] = {
+ MMC1_D0_PORT149_MARK,
+};
+static const unsigned int mmc0_data4_1_pins[] = {
+ /* D[0:3] */
+ 149, 148, 147, 146,
+};
+static const unsigned int mmc0_data4_1_mux[] = {
+ MMC1_D0_PORT149_MARK, MMC1_D1_PORT148_MARK, MMC1_D2_PORT147_MARK, MMC1_D3_PORT146_MARK,
+};
+static const unsigned int mmc0_data8_1_pins[] = {
+ /* D[0:7] */
+ 149, 148, 147, 146, 145, 144, 143, 142,
+};
+static const unsigned int mmc0_data8_1_mux[] = {
+ MMC1_D0_PORT149_MARK, MMC1_D1_PORT148_MARK, MMC1_D2_PORT147_MARK, MMC1_D3_PORT146_MARK,
+ MMC1_D4_PORT145_MARK, MMC1_D5_PORT144_MARK, MMC1_D6_PORT143_MARK, MMC1_D7_PORT142_MARK,
+};
+static const unsigned int mmc0_ctrl_1_pins[] = {
+ /* CMD, CLK */
+ 104, 103,
+};
+static const unsigned int mmc0_ctrl_1_mux[] = {
+ MMC1_CMD_PORT104_MARK, MMC1_CLK_PORT103_MARK,
+};
+
static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(lcd0_data8),
SH_PFC_PIN_GROUP(lcd0_data9),
@@ -1893,6 +2025,24 @@ static const struct sh_pfc_pin_group pinmux_groups[] = {
SH_PFC_PIN_GROUP(lcd1_lclk),
SH_PFC_PIN_GROUP(lcd1_sync),
SH_PFC_PIN_GROUP(lcd1_sys),
+ SH_PFC_PIN_GROUP(sdhi0_data1),
+ SH_PFC_PIN_GROUP(sdhi0_data4),
+ SH_PFC_PIN_GROUP(sdhi0_ctrl),
+ SH_PFC_PIN_GROUP(sdhi0_cd),
+ SH_PFC_PIN_GROUP(sdhi0_wp),
+ SH_PFC_PIN_GROUP(sdhi1_data1),
+ SH_PFC_PIN_GROUP(sdhi1_data4),
+ SH_PFC_PIN_GROUP(sdhi1_ctrl),
+ SH_PFC_PIN_GROUP(sdhi1_cd),
+ SH_PFC_PIN_GROUP(sdhi1_wp),
+ SH_PFC_PIN_GROUP(mmc0_data1_0),
+ SH_PFC_PIN_GROUP(mmc0_data4_0),
+ SH_PFC_PIN_GROUP(mmc0_data8_0),
+ SH_PFC_PIN_GROUP(mmc0_ctrl_0),
+ SH_PFC_PIN_GROUP(mmc0_data1_1),
+ SH_PFC_PIN_GROUP(mmc0_data4_1),
+ SH_PFC_PIN_GROUP(mmc0_data8_1),
+ SH_PFC_PIN_GROUP(mmc0_ctrl_1),
};
static const char * const lcd0_groups[] = {
@@ -1923,9 +2073,39 @@ static const char * const lcd1_groups[] = {
"lcd1_sys",
};
+static const char * const sdhi0_groups[] = {
+ "sdhi0_data1",
+ "sdhi0_data4",
+ "sdhi0_ctrl",
+ "sdhi0_cd",
+ "sdhi0_wp",
+};
+
+static const char * const sdhi1_groups[] = {
+ "sdhi1_data1",
+ "sdhi1_data4",
+ "sdhi1_ctrl",
+ "sdhi1_cd",
+ "sdhi1_wp",
+};
+
+static const char * const mmc0_groups[] = {
+ "mmc0_data1_0",
+ "mmc0_data4_0",
+ "mmc0_data8_0",
+ "mmc0_ctrl_0",
+ "mmc0_data1_1",
+ "mmc0_data4_1",
+ "mmc0_data8_1",
+ "mmc0_ctrl_1",
+};
+
static const struct sh_pfc_function pinmux_functions[] = {
SH_PFC_FUNCTION(lcd0),
SH_PFC_FUNCTION(lcd1),
+ SH_PFC_FUNCTION(sdhi0),
+ SH_PFC_FUNCTION(sdhi1),
+ SH_PFC_FUNCTION(mmc0),
};
#define PINMUX_FN_BASE ARRAY_SIZE(pinmux_pins)
--
1.7.2.5
^ permalink raw reply related
* [PATCH 0/8] ARM: shmobile: pinctrl and DT extensions
From: Guennadi Liakhovetski @ 2013-01-16 17:08 UTC (permalink / raw)
To: linux-arm-kernel
These patches extend sh7372 and r8a7740 pinctrl support and use it to add
SDHI and MMCIF to armadillo800eva and mackerel reference DT
implementations. GPIO-based pin configuration is removed from board files.
Additionally, MMC interfaces on armadillo800eva support run-time
power-switching, which is also supported in DT with these patches.
This series is based on recent work by Laurent and Simon. sh7372 and
r8a7740 pinctrl support seems to be stable and, probably, won't change,
so, also the base for these patches seems solid. Since the current pinctrl
implementation for sh73a0 is likely to change, support for kzm9g isn't
included in this series.
Guennadi Liakhovetski (8):
pinctrl: add SDHI and MMCIF pin groups to r8a7740
pinctrl: add SDHI and MMCIF pin groups to sh7372
ARM: shmobile: simplify armadillo800eva and kzm9g Kconfig
dependencies
ARM: shmobile: add MMCIF and SDHI DT clock aliases to sh73a0 and
r8a7740
ARM: shmobile: add a GPIO controller DT node for sh7372
ARM: shmobile: use GPIO SD-card detection on armadillo800eva
ARM: shmobile: completely switch MMC interfaces on mackerel-reference
to DT
ARM: shmobile: completely switch MMC interfaces on
armadillo800eva-reference to DT
.../boot/dts/r8a7740-armadillo800eva-reference.dts | 101 ++++++++++
arch/arm/boot/dts/sh7372-mackerel-reference.dts | 42 +++-
arch/arm/boot/dts/sh7372.dtsi | 8 +
arch/arm/mach-shmobile/Kconfig | 12 +-
.../board-armadillo800eva-reference.c | 5 +-
arch/arm/mach-shmobile/board-armadillo800eva.c | 10 +-
arch/arm/mach-shmobile/board-mackerel-reference.c | 46 -----
arch/arm/mach-shmobile/clock-r8a7740.c | 4 +
arch/arm/mach-shmobile/clock-sh73a0.c | 3 +
drivers/pinctrl/sh-pfc/pfc-r8a7740.c | 180 +++++++++++++++++
drivers/pinctrl/sh-pfc/pfc-sh7372.c | 205 ++++++++++++++++++++
11 files changed, 552 insertions(+), 64 deletions(-)
--
1.7.2.5
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
^ permalink raw reply
* [PATCH] ata: sata_mv: fix sg_tbl_pool alignment
From: Soeren Moch @ 2013-01-16 17:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116155045.GI25500@titan.lakedaemon.net>
On 16.01.2013 16:50, Jason Cooper wrote:
> On Wed, Jan 16, 2013 at 09:55:55AM +0100, Soeren Moch wrote:
>> On 16.01.2013 04:24, Soeren Moch wrote:
>>> On 16.01.2013 03:40, Jason Cooper wrote:
>>>> On Wed, Jan 16, 2013 at 01:17:59AM +0100, Soeren Moch wrote:
>>>>> On 15.01.2013 22:56, Jason Cooper wrote:
>>>>>> On Tue, Jan 15, 2013 at 03:16:17PM -0500, Jason Cooper wrote:
>
>> OK, I could trigger the error
>> ERROR: 1024 KiB atomic DMA coherent pool is too small!
>> Please increase it with coherent_pool= kernel parameter!
>> only with em28xx sticks and sata, dib0700 sticks removed.
>
> Did you test the reverse scenario? ie dib0700 with sata_mv and no
> em28xx.
Maybe I can test this next night.
> What kind of throughput are you pushing to the sata disk?
Close to nothing. In the last test I had the root filesystem running
on the sata disk plus a few 10 megabytes per hour.
>>>> What would be most helpful is if you could do a git bisect between
>>>> v3.5.x (working) and the oldest version where you know it started
>>>> failing (v3.7.1 or earlier if you know it).
>>>>
>>> I did not bisect it, but Marek mentioned earlier that commit
>>> e9da6e9905e639b0f842a244bc770b48ad0523e9 in Linux v3.6-rc1 introduced
>>> new code for dma allocations. This is probably the root cause for the
>>> new (mis-)behavior (due to my tests 3.6.0 is not working anymore).
>>
>> I don't want to say that Mareks patch is wrong, probably it triggers a
>> bug somewhere else! (in em28xx?)
>
> Of the four drivers you listed, none are using dma. sata_mv is the only
> one.
usb_core is doing the actual DMA for the usb bridge drivers, I think.
> If one is to believe the comments in sata_mv.c:~151, then the alignment
> is wrong for the sg_tbl_pool.
>
> Could you please try the following patch?
OK, what should I test first, the setup from last night (em28xx, no
dib0700) plus your patch, or the reverse setup (dib0700, no em28xx)
without your patch, or my normal setting (all dvb sticks) plus your
patch?
Regards,
Soeren
^ permalink raw reply
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
From: KyongHo Cho @ 2013-01-16 17:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130116105327.GA16543@mudshark.cambridge.arm.com>
On Wed, Jan 16, 2013 at 7:53 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Dec 26, 2012 at 01:53:15AM +0000, Cho KyongHo wrote:
>> notice: v6 patch-set is rebased on next/iommu-exynos branch of
>> linux-samsung.git. This patch-set does not include 2 patches (05 and 06
>> patches in v5 patch-se) because they alread exist already in the branch.
>
> Given that devicetree-discuss has been notably absent from discussion
> surrounding the proposed binding, I think that including that patch in
> linux-samsung.git and dropping it from this series is rather premature.
>
> I have comments on the binding, so I'll dig up the version you posted in v5
> and add devicetree-discuss to CC.
Thank you.
>> The current exynos-iommu(System MMU) driver does not work autonomously
>> since it is lack of support for power management of peripheral blocks.
>> For example, MFC device driver must ensure that its System MMU is disabled
>> before MFC block is power-down not to invalidate IOTLB in the System MMU
>> when I/O memory mapping is changed. Because A System MMU is resides in the
>> same H/W block, access to control registers of System MMU while the H/W
>> block is turned off must be prohibited.
>>
>> This set of changes solves the above problem with setting each System MMUs
>> as the parent of the device which owns the System MMU to recieve the
>> information when the device is turned off or turned on.
>>
>> Another big change to the driver is the support for devicetree.
>> The bindings for System MMU is described in
>> Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
>
> This should probably be Documentation/devicetree/bindings/iommu/ no?
Please let me check it.
Thank you.
KyongHo.
^ permalink raw reply
* [PATCH v6 00/12] iommu/exynos: Fixes and Enhancements of System MMU driver with DT
From: KyongHo Cho @ 2013-01-16 16:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <50EC9C71.7010909@gmail.com>
On Wed, Jan 9, 2013 at 7:23 AM, Sylwester Nawrocki
<sylvester.nawrocki@gmail.com> wrote:
> On 01/07/2013 11:45 AM, KyongHo Cho wrote:
>>>
>>> > The current exynos-iommu(System MMU) driver does not work autonomously
>>> > since it is lack of support for power management of peripheral blocks.
>>> > For example, MFC device driver must ensure that its System MMU is
>>
>> disabled
>>>
>>> > before MFC block is power-down not to invalidate IOTLB in the System
>>> > MMU
>>> > when I/O memory mapping is changed. Because A System MMU is resides
>>
>> in the
>>>
>>> > same H/W block, access to control registers of System MMU while the H/W
>>> > block is turned off must be prohibited.
>>> >
>>> > This set of changes solves the above problem with setting each System
>>
>> MMUs
>>>
>>> > as the parent of the device which owns the System MMU to recieve the
>>> > information when the device is turned off or turned on.
>>>
>>>
>>> I intend to make Exynos4412 FIMC-LITEn (Exynos5 CAMIFn) devices child
>>> devices of the FIMC-IS (camera ISP) platform device. This patch reflects
>>> that: http://patchwork.linuxtv.org/patch/16046
>>>
>>> This is required since AFAIK FIMC-LITE depends on clocks from FIMC-IS.
>>> By setting fimc-is device as the parent fimc-lite's dependency on it is
>>> resolved without any hacks between these drivers.
>>>
>>> Then how this tree will look like after your sysmmu related
>>> re-parenting:
>>>
>>> fimc-is
>>> / \
>>> fimc-lite0 fimc-lite1
>>>
>>>
>>> ?
>>
>>
>> First of all, I think that clock dependency shuold be resolved with
>> setting the parent of clock descriptor of fimc-lite to the clock
>> descriptor of fimc-is.
>
>
> I'll need to investigate it more, but AFAIU there is more than one clock
> for the FIMC-IS device that needs to be enabled before FIMC-LITE can be
> used. IOW FIMC-LITE must be activated after FIMC-IS, and deactivated before
> FIMC-IS is (runtime) suspended.
>
> So I'm afraid I can't simply alter the clock tree for the sake of the
> subsystem dependencies - it's not a one-to-one relation and it doesn't
> sound right.
I have just little knowledge about FIMC-IS.
I don't understand why the sequence of power gating or suspend/resume
is important.
Are you concerning about the dependency of clock gating?
If the drivers of FIMC-IS and FIMC-LITE are not dependent upon each other,
I think it is just enough to add them to the same power domain.
I will check the clock description in the devicetree.
>
>> If you are concerning about power management, it is simply resolved with
>> putting fimc-lite to the power domain of fimc-is.
>
>
> Yes, these devices are already registered to same power domain (ISP).
>
>
>> The above tree will be changed like below after probing System MMU:
>> sysmmu-fimc-is
>> I
>> fimc-is
>>
>> sysmmu-fimc-lite0
>> I
>> fimc-lite0
>>
>> sysmmu-fimc-lite1
>> I
>> fimc-lite1
>
>
> I'm just concerned that this iommu driver would drop previous parent
> configurations and introduce its own. There might be other devices for
> which this would be harmful. Didn't you consider just moving any existing
> device's parent and setting it as iommu's parent, so the tree looks like
>
> sysmmu-fimc-is
> |
> fimc-is
> / \
> sysmmu-fimc-lite0 sysmmu-fimc-lite1
> | |
> fimc-lite0 fimc-lite1
>
> ?
>
> But it's not really much better...
Thanks for the proposal. I will consider to insert System MMU in the
existing dpm and rpm tree
without breaking the existing tree.
I did not find a better solution to guarantee that the System MMU is
always resumed
before its master (like fimc-lite0) is resumed and suspended after its
master is suspended.
It must be guaranteed in terms of APM and Runtime PM.
>>> > Another big change to the driver is the support for devicetree.
>>> > The bindings for System MMU is described in
>>> > Documentation/devicetree/bindings/arm/samsung/system-mmu.txt
>>>
>>>
>>> Yes, and there is no patch adding this file in this series. Let me paste
>>> it here:
>>>
>>> From 88987ff5b77acc7211b9f537a6ef6ea38e3efdd0 Mon Sep 17 00:00:00 2001
>>> From: KyongHo Cho <pullip.cho@samsung.com
>>> <mailto:pullip.cho@samsung.com>>
>>>
>>> Date: Tue, 11 Dec 2012 14:06:25 +0900
>>> Subject: [PATCH] ARM: EXYNOS: add System MMU definition to DT
>>>
>>> This commit adds System MMU nodes to DT of Exynos SoCs.
>>>
>>> Signed-off-by: KyongHo Cho <pullip.cho@samsung.com
>>
>> <mailto:pullip.cho@samsung.com>>
>>>
>>> Signed-off-by: Kukjin Kim <kgene.kim@samsung.com
>>
>> <mailto:kgene.kim@samsung.com>>
>>
>>> ---
>>> .../devicetree/bindings/arm/exynos/system-mmu.txt | 86 ++++++++++++
>>> arch/arm/boot/dts/exynos4210.dtsi | 96 +++++++++++++
>>> arch/arm/boot/dts/exynos4x12.dtsi | 124
>>
>> +++++++++++++++++
>>>
>>> arch/arm/boot/dts/exynos5250.dtsi | 147
>>
>> +++++++++++++++++++-
>>>
>>> 4 files changed, 451 insertions(+), 2 deletions(-)
>>> create mode 100644
>>
>> Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>>>
>>>
>>> diff --git
>>
>> a/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>> b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>>>
>>> new file mode 100644
>>> index 0000000..b33d682
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/arm/exynos/system-mmu.txt
>>> @@ -0,0 +1,86 @@
>>> +* Samsung Exynos System MMU
>>> +
>>> +Samsung's Exynos architecture includes System MMU that enables
>>> scattered
>>> +physical chunks to be visible as a contiguous region to DMA-capabile
>>
>> peripheral
>>>
>>> +devices like MFC, FIMC, FIMD, GScaler, FIMC-IS and so forth.
>>> +
>>> +System MMU is a sort of IOMMU and support identical translation table
>>
>> format to
>>>
>>> +ARMv7 translation tables with minimum set of page properties
>>
>> including access
>>>
>>> +permissions, shareability and security protection. In addition System
>>
>> MMU has
>>>
>>> +another capabilities like L2 TLB or block-fetch buffers to minimize
>>
>> translation
>>>
>>> +latency
>>> +
>>> +Each System MMU is included in the H/W block of a peripheral device.
>>
>> Thus, it is
>>>
>>> +important to specify that a System MMU is dedicated to which
>>
>> peripheral device
>>>
>>> +before using System MMU. System initialization must specify the
>>
>> relationships
>>>
>>> +between a System MMU and a peripheral device that owns the System MMU.
>>> +
>>> +Some device drivers may control several peripheral devices with a
>>
>> single device
>>>
>>> +descriptor like MFC. Since handling a System MMU with IOMMU API
>>
>> requires a
>>>
>>> +device descriptor that needs the System MMU, it is best to combine
>>
>> the System
>>>
>>> +MMUs of the peripheral devices and control them with a single System
>>
>> MMU device
>>>
>>> +descriptor. If it is unable to combine them into a single device
>>
>> descriptor,
>>>
>>> +they can be linked with each other by the means of device.parent
>>
>> relationship.
>>>
>>> +
>>> +Required properties:
>>> +- compatible: Should be "samsung,exynos-sysmmu".
>>> +- reg: Tuples of base address and size of System MMU registers. The
>>
>> number of
>>>
>>> + tuples can be more than one if two or more System MMUs are
>>
>> controlled
>>>
>>> + by a single device descriptor.
>>> +- interrupt-parent: The phandle of the interrupt controller of System
>>> MMU
>>> +- interrupts: Tuples of numbers that indicates the interrupt source.
>>> The
>>> + number of elements in the tuple is dependent upon
>>> + 'interrupt-parent' property. The number of tuples in this property
>>> + must be the same with 'reg' property.
>>> +
>>> +Optional properties:
>>> +- mmuname: Strings of the name of System MMU for debugging purpose.
>>
>> The number
>>>
>>> + of strings must be the same with the number of tuples in
>>> 'reg'
>>> + property.
>>>
>>> As commented on previous patch, this isn't something that belongs here.
>>> But for debugging you could probably retrieve this from the node name ?
>>
>>
>> Thank you for good idea. However mmuname is an array of strings,
>> actually. Anyway I agree with your opinion that 'mmuname' is not proper
>> property of a device node. I will remove it and substitute it with base
>> register address of a System MMU.
>
>
> Ok.
>
>
>>> +- mmu-master: phandle to the device node that owns System MMU. Only
>>
>> the device
>>>
>>> + that is specified whith this property can control System
>>
>> MMU with
>>>
>>> + IOMMU API.
>>> +
>>> +Examples:
>>> +
>>> +MFC has 2 System MMUs for each port that MFC is attached. Thus it
>>
>> seems natural
>>>
>>> +to define 2 System MMUs for each port of the MFC:
>
>
> "The video codec (MFC) device has a System MMUs for each port (AXI master).
> Thus it seems natural to define a System MMU device node for each port of
>
> the MFC:"
Thanks. I think your expression is easier to understand.
I am also not a good English writer :)
>>> +
>>> + sysmmu-mfc-l {
>>> + mmuname = "mfc_l";
>>> + reg = <0x11210000 0x1000>;
>>> + compatible = "samsung,exynos-sysmmu";
>>> + interrupt-parent = <&combiner>;
>>> + interrupts = <8 5>;
>>> + mmu-master = <&mfc>;
>>> + };
>>> +
>>> + sysmmu-mfc-r {
>>> + mmuname = "mfc_r";
>>> + reg = <0x11200000 0x1000>;
>>> + compatible = "samsung,exynos-sysmmu";
>>> + interrupt-parent = <&combiner>;
>>> + interrupts = <6 2>;
>>> + mmu-master = <&mfc>;
>>> + };
>>> +
>>> +Actually, MFC device driver requires sub-devices that represents each
>>
>> port and
>>>
>>> +above 'mmu-master' properties of sysmmu-mfc-l and sysmmu-mfc-r have
>>
>> the phandles
>>>
>>> +to those sub-devices.
>>>
>>> I find this sentence really difficult to parse. This documentation
>>
>> should talk
>>>
>>> about how the device is designed and represented, rather than about
>>
>> its driver.
>>>
>>>
>> OK. I will trying to find another expression easy to understand. Do you
>> have any suggestion?
>
>
> I'm not a native English speaker, but maybe something like this makes sense:
>
> "The sysmmu-mfc-l, sysmmy-mfc-r nodes represent parts of the MFC device
> which
> indicate their 'mmu-master' phandles pointing to the mfc node."
I understand what you have intended.
Thank you for the suggestion. I will consider to make it easy to understand.
>
> ?
>
>>> +However, it is also a good idea that treats the above System MMUs as
>
>
> treats -> treat
>
Thanks.
>
>> one System
>>>
>>> +MMU because those System MMUs are actually required by the MFC device:
>>> +
>>> + sysmmu-mfc {
>>> + mmuname = "mfc_l", "mfc_r";
>>> + reg = <0x11210000 0x1000
>>> + 0x11200000 0x1000>;
>>> + compatible = "samsung,exynos-sysmmu";
>>> + interrupt-parent = <&combiner>;
>>> + interrupts = <8 5
>>> + 6 2>;
>
>
> interrupts = <8 5>, <6 2>; ?
>
Please see my reply below.
>
>>> + mmu-master = <&mfc>;
>>> + };
>>> +
>>> +If System MMU of MFC is defined like the above, the number of
>>
>> elements and the
>>>
>>> +order of list in 'mmuname', 'reg' and 'interrupts' must be the same.
>
> ...
>
>>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>>
>> b/arch/arm/boot/dts/exynos5250.dtsi
>>>
>>> index 2e3b6ef..2ff6d78 100644
>>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>>> @@ -75,7 +75,7 @@
>>> interrupts = <0 42 0>;
>>> };
>>>
> ...
>
>>> + sysmmu-is0 {
>>> + mmuname = "isp", "drc", "scalerc", "scalerp", "fd",
>>> "mcu";
>>> + reg = < 0x13260000 0x1000
>>> + 0x13270000 0x1000
>>> + 0x13280000 0x1000
>>> + 0x13290000 0x1000
>>> + 0x132A0000 0x1000
>>> + 0x132B0000 0x1000 >;
>>> + compatible = "samsung,exynos-sysmmu";
>>> + interrupt-parent = <&combiner>;
>>> + interrupts = < 10 6
>>> + 11 6
>>> + 5 2
>>> + 3 6
>>> + 5 0
>>> + 5 4 >;
>>>
>>> I believe this should be
>>>
>>> interrupts = <10 6>, <11 6>, <5 2>,
>>> <3 6>, <5 0>, <5 4>;
>>>
>> I found the syntax of array of resources in the specifications of device
>> tree. I found that it works correctly.
>
>
> OK, it seems both conventions are valid. I just found it unusual, since
> all interrupt specifiers I've seen for Samsung SoCs use the syntax, where
> each interrupt is enclosed in triangular brackets. Maybe it's better to
> keep it consistent across all files ?
Let me check the other dts/dti and change my expression to follow the
convention:)
Sorry for late reply. I have just little time to spend after work in
these days. :(
Thank you for kind review.
KyongHo
^ 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