* [PATCH 1/3] ARM64: perf: add support for perf registers API
From: Jean Pihet @ 2014-02-03 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391451509-31265-1-git-send-email-jean.pihet@linaro.org>
This patch implements the functions required for the perf registers API,
allowing the perf tool to interface kernel register dumps with libunwind
in order to provide userspace backtracing.
Compat mode is also supported.
Only the general purpose user space registers are exported, i.e.:
PERF_REG_ARM_X0,
...
PERF_REG_ARM_X28,
PERF_REG_ARM_FP,
PERF_REG_ARM_LR,
PERF_REG_ARM_SP,
PERF_REG_ARM_PC
and not the PERF_REG_ARM_V* registers.
Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/Kconfig | 2 ++
arch/arm64/include/asm/ptrace.h | 1 +
arch/arm64/include/uapi/asm/Kbuild | 1 +
arch/arm64/include/uapi/asm/perf_regs.h | 40 ++++++++++++++++++++++++++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/perf_regs.c | 44 +++++++++++++++++++++++++++++++++
6 files changed, 89 insertions(+)
create mode 100644 arch/arm64/include/uapi/asm/perf_regs.h
create mode 100644 arch/arm64/kernel/perf_regs.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index dd4327f..e9899bb 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -37,6 +37,8 @@ config ARM64
select HAVE_HW_BREAKPOINT if PERF_EVENTS
select HAVE_MEMBLOCK
select HAVE_PERF_EVENTS
+ select HAVE_PERF_REGS
+ select HAVE_PERF_USER_STACK_DUMP
select IRQ_DOMAIN
select MODULES_USE_ELF_RELA
select NO_BOOTMEM
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index 0e7fa49..fbb0020 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -68,6 +68,7 @@
/* Architecturally defined mapping between AArch32 and AArch64 registers */
#define compat_usr(x) regs[(x)]
+#define compat_fp regs[11]
#define compat_sp regs[13]
#define compat_lr regs[14]
#define compat_sp_hyp regs[15]
diff --git a/arch/arm64/include/uapi/asm/Kbuild b/arch/arm64/include/uapi/asm/Kbuild
index e4b78bd..942376d 100644
--- a/arch/arm64/include/uapi/asm/Kbuild
+++ b/arch/arm64/include/uapi/asm/Kbuild
@@ -9,6 +9,7 @@ header-y += byteorder.h
header-y += fcntl.h
header-y += hwcap.h
header-y += kvm_para.h
+header-y += perf_regs.h
header-y += param.h
header-y += ptrace.h
header-y += setup.h
diff --git a/arch/arm64/include/uapi/asm/perf_regs.h b/arch/arm64/include/uapi/asm/perf_regs.h
new file mode 100644
index 0000000..172b831
--- /dev/null
+++ b/arch/arm64/include/uapi/asm/perf_regs.h
@@ -0,0 +1,40 @@
+#ifndef _ASM_ARM64_PERF_REGS_H
+#define _ASM_ARM64_PERF_REGS_H
+
+enum perf_event_arm_regs {
+ PERF_REG_ARM64_X0,
+ PERF_REG_ARM64_X1,
+ PERF_REG_ARM64_X2,
+ PERF_REG_ARM64_X3,
+ PERF_REG_ARM64_X4,
+ PERF_REG_ARM64_X5,
+ PERF_REG_ARM64_X6,
+ PERF_REG_ARM64_X7,
+ PERF_REG_ARM64_X8,
+ PERF_REG_ARM64_X9,
+ PERF_REG_ARM64_X10,
+ PERF_REG_ARM64_X11,
+ PERF_REG_ARM64_X12,
+ PERF_REG_ARM64_X13,
+ PERF_REG_ARM64_X14,
+ PERF_REG_ARM64_X15,
+ PERF_REG_ARM64_X16,
+ PERF_REG_ARM64_X17,
+ PERF_REG_ARM64_X18,
+ PERF_REG_ARM64_X19,
+ PERF_REG_ARM64_X20,
+ PERF_REG_ARM64_X21,
+ PERF_REG_ARM64_X22,
+ PERF_REG_ARM64_X23,
+ PERF_REG_ARM64_X24,
+ PERF_REG_ARM64_X25,
+ PERF_REG_ARM64_X26,
+ PERF_REG_ARM64_X27,
+ PERF_REG_ARM64_X28,
+ PERF_REG_ARM64_X29,
+ PERF_REG_ARM64_LR,
+ PERF_REG_ARM64_SP,
+ PERF_REG_ARM64_PC,
+ PERF_REG_ARM64_MAX,
+};
+#endif /* _ASM_ARM64_PERF_REGS_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 2d4554b..9a5d592 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -15,6 +15,7 @@ arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o \
sys_compat.o
arm64-obj-$(CONFIG_MODULES) += arm64ksyms.o module.o
arm64-obj-$(CONFIG_SMP) += smp.o smp_spin_table.o
+arm64-obj-$(CONFIG_PERF_EVENTS) += perf_regs.o
arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT)+= hw_breakpoint.o
arm64-obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c
new file mode 100644
index 0000000..f2d6f0a
--- /dev/null
+++ b/arch/arm64/kernel/perf_regs.c
@@ -0,0 +1,44 @@
+#include <linux/errno.h>
+#include <linux/kernel.h>
+#include <linux/perf_event.h>
+#include <linux/bug.h>
+#include <asm/perf_regs.h>
+#include <asm/ptrace.h>
+
+u64 perf_reg_value(struct pt_regs *regs, int idx)
+{
+ if (WARN_ON_ONCE((u32)idx >= PERF_REG_ARM64_MAX))
+ return 0;
+
+ /*
+ * Compat (i.e. 32 bit) mode:
+ * - PC has been set in the pt_regs struct in kernel_entry,
+ * - Handle SP and LR here.
+ */
+ if (compat_user_mode(regs)) {
+ if ((u32)idx == PERF_REG_ARM64_SP)
+ return regs->compat_sp;
+ if ((u32)idx == PERF_REG_ARM64_LR)
+ return regs->compat_lr;
+ }
+
+ return regs->regs[idx];
+}
+
+#define REG_RESERVED (~((1ULL << PERF_REG_ARM64_MAX) - 1))
+
+int perf_reg_validate(u64 mask)
+{
+ if (!mask || mask & REG_RESERVED)
+ return -EINVAL;
+
+ return 0;
+}
+
+u64 perf_reg_abi(struct task_struct *task)
+{
+ if (is_compat_thread(task_thread_info(task)))
+ return PERF_SAMPLE_REGS_ABI_32;
+ else
+ return PERF_SAMPLE_REGS_ABI_64;
+}
--
1.7.11.7
^ permalink raw reply related
* [PATCH 2/3] ARM64: perf: add support for frame pointer unwinding in compat mode
From: Jean Pihet @ 2014-02-03 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391451509-31265-1-git-send-email-jean.pihet@linaro.org>
When profiling a 32-bit application, user space callchain unwinding
using the frame pointer is performed in compat mode. The code is taken
over from the AARCH32 code and adapted to work on AARCH64.
Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/kernel/perf_event.c | 75 +++++++++++++++++++++++++++++++++++++-----
1 file changed, 67 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index 5b1cd79..e868c72 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -1348,8 +1348,8 @@ early_initcall(init_hw_perf_events);
* Callchain handling code.
*/
struct frame_tail {
- struct frame_tail __user *fp;
- unsigned long lr;
+ struct frame_tail __user *fp;
+ unsigned long lr;
} __attribute__((packed));
/*
@@ -1386,22 +1386,80 @@ user_backtrace(struct frame_tail __user *tail,
return buftail.fp;
}
+/*
+ * The registers we're interested in are at the end of the variable
+ * length saved register structure. The fp points at the end of this
+ * structure so the address of this struct is:
+ * (struct compat_frame_tail *)(xxx->fp)-1
+ *
+ * This code has been adapted from the ARM OProfile support.
+ */
+struct compat_frame_tail {
+ compat_uptr_t fp; /* a (struct compat_frame_tail *) in compat mode */
+ u32 sp;
+ u32 lr;
+} __attribute__((packed));
+
+static struct compat_frame_tail __user *
+compat_user_backtrace(struct compat_frame_tail __user *tail,
+ struct perf_callchain_entry *entry)
+{
+ struct compat_frame_tail buftail;
+ unsigned long err;
+
+ /* Also check accessibility of one struct frame_tail beyond */
+ if (!access_ok(VERIFY_READ, tail, sizeof(buftail)))
+ return NULL;
+
+ pagefault_disable();
+ err = __copy_from_user_inatomic(&buftail, tail, sizeof(buftail));
+ pagefault_enable();
+
+ if (err)
+ return NULL;
+
+ perf_callchain_store(entry, buftail.lr);
+
+ /*
+ * Frame pointers should strictly progress back up the stack
+ * (towards higher addresses).
+ */
+ if (tail + 1 >= (struct compat_frame_tail __user *)
+ compat_ptr(buftail.fp))
+ return NULL;
+
+ return (struct compat_frame_tail __user *)compat_ptr(buftail.fp) - 1;
+}
+
void perf_callchain_user(struct perf_callchain_entry *entry,
struct pt_regs *regs)
{
- struct frame_tail __user *tail;
-
if (perf_guest_cbs && perf_guest_cbs->is_in_guest()) {
/* We don't support guest os callchain now */
return;
}
perf_callchain_store(entry, regs->pc);
- tail = (struct frame_tail __user *)regs->regs[29];
- while (entry->nr < PERF_MAX_STACK_DEPTH &&
- tail && !((unsigned long)tail & 0xf))
- tail = user_backtrace(tail, entry);
+ if (!compat_user_mode(regs)) {
+ /* AARCH64 mode */
+ struct frame_tail __user *tail;
+
+ tail = (struct frame_tail __user *)regs->regs[29];
+
+ while (entry->nr < PERF_MAX_STACK_DEPTH &&
+ tail && !((unsigned long)tail & 0xf))
+ tail = user_backtrace(tail, entry);
+ } else {
+ /* AARCH32 compat mode */
+ struct compat_frame_tail __user *tail;
+
+ tail = (struct compat_frame_tail __user *)regs->compat_fp - 1;
+
+ while ((entry->nr < PERF_MAX_STACK_DEPTH) &&
+ tail && !((unsigned long)tail & 0x3))
+ tail = compat_user_backtrace(tail, entry);
+ }
}
/*
@@ -1429,6 +1487,7 @@ void perf_callchain_kernel(struct perf_callchain_entry *entry,
frame.fp = regs->regs[29];
frame.sp = regs->sp;
frame.pc = regs->pc;
+
walk_stackframe(&frame, callchain_trace, entry);
}
--
1.7.11.7
^ permalink raw reply related
* [PATCH 3/3] ARM64: perf: support dwarf unwinding in compat mode
From: Jean Pihet @ 2014-02-03 18:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391451509-31265-1-git-send-email-jean.pihet@linaro.org>
Add support for unwinding using the dwarf information in compat
mode. Using the correct user stack pointer allows perf to record
the frames correctly in the native and compat modes.
Note that although the dwarf frame unwinding works ok using
libunwind in native mode (on ARMv7 & ARMv8), some changes are
required to the libunwind code for the compat mode. Those changes
are posted separately on the libunwind mailing list.
Tested on ARMv8 platform with v8 and compat v7 binaries, the latter
are statically built.
Signed-off-by: Jean Pihet <jean.pihet@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
---
arch/arm64/include/asm/compat.h | 2 +-
arch/arm64/include/asm/ptrace.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index fda2704..e71f81f 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -228,7 +228,7 @@ static inline compat_uptr_t ptr_to_compat(void __user *uptr)
return (u32)(unsigned long)uptr;
}
-#define compat_user_stack_pointer() (current_pt_regs()->compat_sp)
+#define compat_user_stack_pointer() (user_stack_pointer(current_pt_regs()))
static inline void __user *arch_compat_alloc_user_space(long len)
{
diff --git a/arch/arm64/include/asm/ptrace.h b/arch/arm64/include/asm/ptrace.h
index fbb0020..86d5b54 100644
--- a/arch/arm64/include/asm/ptrace.h
+++ b/arch/arm64/include/asm/ptrace.h
@@ -133,7 +133,7 @@ struct pt_regs {
(!((regs)->pstate & PSR_F_BIT))
#define user_stack_pointer(regs) \
- ((regs)->sp)
+ (!compat_user_mode(regs)) ? ((regs)->sp) : ((regs)->compat_sp)
/*
* Are the current registers suitable for user mode? (used to maintain
--
1.7.11.7
^ permalink raw reply related
* [PATCH v5 0/4] perf: AARCH64 arch support
From: Jean Pihet @ 2014-02-03 18:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140124163548.GH31040@mudshark.cambridge.arm.com>
Hi Will, Arnaldo,
On 24 January 2014 17:35, Will Deacon <will.deacon@arm.com> wrote:
> Hi Jean,
>
> On Wed, Jan 22, 2014 at 02:11:15PM +0000, Jean Pihet wrote:
>> Add AARCH64 specific support. This includes the following:
>> - AARCH64 perf registers definition and hooks,
>> - compat mode registers use, i.e. profiling a 32-bit binary on
>> a 64-bit system,
>> - unwinding using the dwarf information from the .debug_frame
>> section of the ELF binary,
>> - unwinding using the frame pointer information; in 64-bit and
>> compat modes.
>>
>> Note: support for unwinding using the dwarf information in compat
>> mode requires some changes to the libunwind code. Those changes
>> have been submitted on the libunwind ML and are in discussion.
>>
>> Tested on ARMv7, ARMv8 and x86_64 platforms. The compat mode has been
>> tested on ARMv8 using statically built 32-bit binaries.
>
> This is look alright to me now, but there are still two blockers:
>
> (1) Getting the libunwind code merged
This one is independent of the kernel changes. The libunwind stuff is
under disuccsion atm, cf. libunwind ML.
> (2) Splitting this into an arch/arm64 series and a tools/perf series, so
> that acme can merge the latter independently (and avoid the mess we had
> last time).
Split into:
- the tools/perf change: '[PATCH] perf: ARM64: wire up perf_regs and
unwind support'
and
- the arch/arm64 changes: '[PATCH v6 0/3] perf: AARCH64 arch support'.
>
> Anyway, for the series:
>
> Acked-by: Will Deacon <will.deacon@arm.com>
Thanks! I have added your Acked-By in the series.
>
> Will
Jean
^ permalink raw reply
* [PATCH] [RFC] Support for creating generic host_bridge from device tree
From: Liviu Dudau @ 2014-02-03 18:33 UTC (permalink / raw)
To: linux-arm-kernel
Following the discussion started here [1], I now have a proposal for tackling
generic support for host bridges described via device tree. It is an initial
stab at it, to try to get feedback and suggestions, but it is functional enough
that I have PCI Express for arm64 working on an FPGA using the patch that I am
also publishing that adds support for PCI for that platform.
Looking at the existing architectures that fit the requirements (use of device
tree and PCI) yields the powerpc and microblaze as generic enough to make them
candidates for conversion. I have a tentative patch for microblaze that I can
only compile test it, unfortunately using qemu-microblaze leads to an early
crash in the kernel.
As Bjorn has mentioned in the previous discussion, the idea is to add to
struct pci_host_bridge enough data to be able to reduce the size or remove the
architecture specific pci_controller structure. arm64 support actually manages
to get rid of all the architecture static data and has no pci_controller structure
defined. For host bridge drivers that means a change of API unless architectures
decide to provide a compatibility layer (comments here please).
In order to initialise a host bridge with the new API, the following example
code is sufficient for a _probe() function:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct resource bus_range;
struct myhostbridge_port *pp;
LIST_HEAD(resources);
dev = pdev->dev.of_node;
if (!of_device_is_available(dev)) {
pr_warn("%s: disabled\n", dev->full_name);
return -ENODEV;
}
pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
if (!pp)
return -ENOMEM;
err = of_pci_parse_bus_range(dev, &bus_range);
if (err) {
bus_range.start = 0;
bus_range.end = 255;
bus_range.flags = IORESOURCE_BUS;
}
pci_add_resource(&resources, &bus_range);
bridge = pci_host_bridge_of_init(&pdev->dev, 0, &myhostbridge_ops, pp, &resources);
if (!bridge) {
err = -EINVAL;
goto bridge_init_fail;
}
err = myhostbridge_setup(bridge->bus);
if (err)
goto bridge_init_fail;
/*
* Add flags here, this is just an example
*/
pci_add_flags(PCI_ENABLE_PROC_DOMAINS | PCI_COMPAT_DOMAIN_0);
pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
bus_range.end = pci_scan_child_bus(bridge->bus);
pci_bus_update_busn_res_end(bridge->bus, bus_range.end);
pci_assign_unassigned_bus_resources(bridge->bus);
pci_bus_add_devices(bridge->bus);
return 0;
bridge_init_fail:
kfree(pp);
pci_free_resource_list(&resources);
return err;
}
Best regards,
Liviu Dudau
[1] http://thread.gmane.org/gmane.linux.kernel.pci/25946
Liviu Dudau (1):
pci: Add support for creating a generic host_bridge from device tree
drivers/pci/host-bridge.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++
drivers/pci/probe.c | 11 ++++++
include/linux/pci.h | 14 ++++++++
3 files changed, 117 insertions(+)
--
1.8.5.3
^ permalink raw reply
* [PATCH] pci: Add support for creating a generic host_bridge from device tree
From: Liviu Dudau @ 2014-02-03 18:33 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391452428-22917-1-git-send-email-Liviu.Dudau@arm.com>
Several platforms use a rather generic version of parsing
the device tree to find the host bridge ranges. Move that
into the generic PCI code and use it to create a pci_host_bridge
structure that can be used by arch code.
Based on early attempts by Andrew Murray to unify the code.
Used powerpc and microblaze PCI code as starting point.
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>
Cc: Will Deacon <Will.Deacon@arm.com>
---
drivers/pci/host-bridge.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++
drivers/pci/probe.c | 11 ++++++
include/linux/pci.h | 14 ++++++++
3 files changed, 117 insertions(+)
diff --git a/drivers/pci/host-bridge.c b/drivers/pci/host-bridge.c
index 06ace62..9d11deb 100644
--- a/drivers/pci/host-bridge.c
+++ b/drivers/pci/host-bridge.c
@@ -6,6 +6,7 @@
#include <linux/init.h>
#include <linux/pci.h>
#include <linux/module.h>
+#include <linux/of_address.h>
#include "pci.h"
@@ -91,3 +92,94 @@ void pcibios_bus_to_resource(struct pci_bus *bus, struct resource *res,
res->end = region->end + offset;
}
EXPORT_SYMBOL(pcibios_bus_to_resource);
+
+/**
+ * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
+ * @dev: device node of the host bridge having the range property
+ * @resources: list where the range of resources will be added after DT parsing
+ *
+ * This function will parse the "ranges" property of a PCI host bridge device
+ * node and setup the resource mapping based on its content. It is expected
+ * that the property conforms with the Power ePAPR document.
+ *
+ * Each architecture will then apply their filtering based on the limitations
+ * of each platform. One general restriction seems to be the number of IO space
+ * ranges, the PCI framework makes intensive use of struct resource management,
+ * and for IORESOURCE_IO types they can only be requested if they are contained
+ * within the global ioport_resource, so that should be limited to one IO space
+ * range.
+ */
+static int pci_host_bridge_of_get_ranges(struct device_node *dev,
+ struct list_head *resources)
+{
+ struct resource *res;
+ struct of_pci_range range;
+ struct of_pci_range_parser parser;
+ int err;
+
+ pr_info("PCI host bridge %s ranges:\n", dev->full_name);
+
+ /* Check for ranges property */
+ err = of_pci_range_parser_init(&parser, dev);
+ if (err)
+ return err;
+
+ pr_debug("Parsing ranges property...\n");
+ for_each_of_pci_range(&parser, &range) {
+ /* Read next ranges element */
+ pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
+ range.pci_space, range.pci_addr);
+ pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
+ range.cpu_addr, range.size);
+
+ /* If we failed translation or got a zero-sized region
+ * (some FW try to feed us with non sensical zero sized regions
+ * such as power3 which look like some kind of attempt
+ * at exposing the VGA memory hole) then skip this range
+ */
+ if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
+ continue;
+
+ res = kzalloc(sizeof(struct resource), GFP_KERNEL);
+ if (!res) {
+ err = -ENOMEM;
+ goto bridge_ranges_nomem;
+ }
+
+ of_pci_range_to_resource(&range, dev, res);
+
+ pci_add_resource_offset(resources, res,
+ range.cpu_addr - range.pci_addr);
+ }
+
+ /* Apply architecture specific fixups for the ranges */
+ pcibios_fixup_bridge_ranges(resources);
+
+ return 0;
+
+bridge_ranges_nomem:
+ pci_free_resource_list(resources);
+ return err;
+}
+
+struct pci_host_bridge *
+pci_host_bridge_of_init(struct device *parent, int busno, struct pci_ops *ops,
+ void *host_data, struct list_head *resources)
+{
+ struct pci_bus *root_bus;
+ struct pci_host_bridge *bridge;
+
+ /* first parse the host bridge bus ranges */
+ if (pci_host_bridge_of_get_ranges(parent->of_node, resources))
+ return NULL;
+
+ /* then create the root bus */
+ root_bus = pci_create_root_bus(parent, busno, ops, host_data, resources);
+ if (!root_bus)
+ return NULL;
+
+ bridge = to_pci_host_bridge(root_bus->bridge);
+
+ return bridge;
+}
+EXPORT_SYMBOL(pci_host_bridge_of_init);
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index 6e34498..16febae 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1787,6 +1787,17 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
list_for_each_entry_safe(window, n, resources, list) {
list_move_tail(&window->list, &bridge->windows);
res = window->res;
+ /*
+ * IO resources are stored in the kernel with a CPU start
+ * address of zero. Adjust the data accordingly and remember
+ * the offset
+ */
+ if (resource_type(res) == IORESOURCE_IO) {
+ bridge->io_offset = res->start;
+ res->end -= res->start;
+ window->offset -= res->start;
+ res->start = 0;
+ }
offset = window->offset;
if (res->flags & IORESOURCE_BUS)
pci_bus_insert_busn_res(b, bus, res->end);
diff --git a/include/linux/pci.h b/include/linux/pci.h
index fb57c89..8953997 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -394,6 +394,8 @@ struct pci_host_bridge_window {
struct pci_host_bridge {
struct device dev;
struct pci_bus *bus; /* root bus */
+ resource_size_t io_offset; /* CPU address offset for io resources */
+ int domain_nr;
struct list_head windows; /* pci_host_bridge_windows */
void (*release_fn)(struct pci_host_bridge *);
void *release_data;
@@ -1762,11 +1764,23 @@ static inline struct device_node *pci_bus_to_OF_node(struct pci_bus *bus)
return bus ? bus->dev.of_node : NULL;
}
+struct pci_host_bridge *
+pci_host_bridge_of_init(struct device *parent, int busno, struct pci_ops *ops,
+ void *host_data, struct list_head *resources);
+
+void pcibios_fixup_bridge_ranges(struct list_head *resources);
#else /* CONFIG_OF */
static inline void pci_set_of_node(struct pci_dev *dev) { }
static inline void pci_release_of_node(struct pci_dev *dev) { }
static inline void pci_set_bus_of_node(struct pci_bus *bus) { }
static inline void pci_release_bus_of_node(struct pci_bus *bus) { }
+
+static inline struct pci_host_bridge *
+pci_host_bridge_of_init(struct device *parent, struct pci_ops *ops,
+ void *host_data, struct list_head *resources)
+{
+ return NULL;
+}
#endif /* CONFIG_OF */
#ifdef CONFIG_EEH
--
1.8.5.3
^ permalink raw reply related
* [PATCH] [RFC] Add AArch64 support for PCI
From: Liviu Dudau @ 2014-02-03 18:43 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
This patch adds support for PCI to AArch64. It is based on the patch posted
here [1] that adds support for creating generic host bridge structure from
device tree. With that in place, I was able to boot an FPGA platform that
has PCIe host bridge support and use a PCIe network card.
The API used is different from the one used by ARM architecture. There is
no pci_common_init_dev() function and no hw_pci structure, as that is no
longer needed. Once the last signature is added to the legal agreement, I
will post the host bridge driver code that I am using. Meanwhile, here
is an example of what the probe function looks like, posted as an example:
static int myhostbridge_probe(struct platform_device *pdev)
{
int err;
struct device_node *dev;
struct pci_host_bridge *bridge;
struct resource bus_range;
struct myhostbridge_port *pp;
LIST_HEAD(resources);
dev = pdev->dev.of_node;
if (!of_device_is_available(dev)) {
pr_warn("%s: disabled\n", dev->full_name);
return -ENODEV;
}
pp = kzalloc(sizeof(struct myhostbridge_port), GFP_KERNEL);
if (!pp)
return -ENOMEM;
err = of_pci_parse_bus_range(dev, &bus_range);
if (err) {
bus_range.start = 0;
bus_range.end = 255;
bus_range.flags = IORESOURCE_BUS;
}
pci_add_resource(&resources, &bus_range);
bridge = pci_host_bridge_of_init(&pdev->dev, 0, &myhostbridge_ops, pp, &resources);
if (!bridge) {
err = -EINVAL;
goto bridge_init_fail;
}
err = myhostbridge_setup(bridge->bus);
if (err)
goto bridge_init_fail;
/*
* Add flags here, this is just an example
*/
pci_add_flags(PCI_ENABLE_PROC_DOMAINS | PCI_COMPAT_DOMAIN_0);
pci_add_flags(PCI_REASSIGN_ALL_BUS | PCI_REASSIGN_ALL_RSRC);
bus_range.end = pci_scan_child_bus(bridge->bus);
pci_bus_update_busn_res_end(bridge->bus, bus_range.end);
pci_assign_unassigned_bus_resources(bridge->bus);
pci_bus_add_devices(bridge->bus);
return 0;
bridge_init_fail:
kfree(pp);
pci_free_resource_list(&resources);
return err;
}
Best regards,
Liviu
[1] http://marc.info/?l=linux-pci&m=139145254821334&w=2
Liviu Dudau (1):
arm64: Add support for PCI
arch/arm64/Kconfig | 17 +++++++
arch/arm64/include/asm/Kbuild | 1 +
arch/arm64/include/asm/io.h | 4 ++
arch/arm64/include/asm/pci.h | 35 +++++++++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/pci.c | 112 ++++++++++++++++++++++++++++++++++++++++++
6 files changed, 170 insertions(+)
create mode 100644 arch/arm64/include/asm/pci.h
create mode 100644 arch/arm64/kernel/pci.c
--
1.8.5.3
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Liviu Dudau @ 2014-02-03 18:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391453028-23191-1-git-send-email-Liviu.Dudau@arm.com>
Use the generic host bridge functions to provide support for
PCI Express on arm64. There is no support for ISA memory.
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>
---
arch/arm64/Kconfig | 17 +++++++
arch/arm64/include/asm/Kbuild | 1 +
arch/arm64/include/asm/io.h | 4 ++
arch/arm64/include/asm/pci.h | 35 +++++++++++++
arch/arm64/kernel/Makefile | 1 +
arch/arm64/kernel/pci.c | 112 ++++++++++++++++++++++++++++++++++++++++++
6 files changed, 170 insertions(+)
create mode 100644 arch/arm64/include/asm/pci.h
create mode 100644 arch/arm64/kernel/pci.c
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index f8e5ee6..48fdd69 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -133,6 +133,23 @@ menu "Bus support"
config ARM_AMBA
bool
+config PCI
+ bool "PCI support"
+ help
+ This feature enables support for PCIe bus system. If you say Y
+ here, the kernel will include drivers and infrastructure code
+ to support PCIe bus devices.
+
+config PCI_DOMAINS
+ def_bool PCI
+
+config PCI_SYSCALL
+ def_bool PCI
+
+source "drivers/pci/Kconfig"
+source "drivers/pci/pcie/Kconfig"
+source "drivers/pci/hotplug/Kconfig"
+
endmenu
menu "Kernel Features"
diff --git a/arch/arm64/include/asm/Kbuild b/arch/arm64/include/asm/Kbuild
index 71c53ec..46924bc 100644
--- a/arch/arm64/include/asm/Kbuild
+++ b/arch/arm64/include/asm/Kbuild
@@ -26,6 +26,7 @@ generic-y += mman.h
generic-y += msgbuf.h
generic-y += mutex.h
generic-y += pci.h
+generic-y += pci-bridge.h
generic-y += poll.h
generic-y += posix_types.h
generic-y += resource.h
diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 4cc813e..ce5bad2 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
/*
* I/O port access primitives.
*/
+#define arch_has_dev_port() (0)
#define IO_SPACE_LIMIT 0xffff
#define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_2M))
+#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
+#define ioport_unmap(addr)
+
static inline u8 inb(unsigned long addr)
{
return readb(addr + PCI_IOBASE);
diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
new file mode 100644
index 0000000..dd084a3
--- /dev/null
+++ b/arch/arm64/include/asm/pci.h
@@ -0,0 +1,35 @@
+#ifndef __ASM_PCI_H
+#define __ASM_PCI_H
+#ifdef __KERNEL__
+
+#include <linux/types.h>
+#include <linux/slab.h>
+#include <linux/dma-mapping.h>
+
+#include <asm/io.h>
+#include <asm-generic/pci-bridge.h>
+#include <asm-generic/pci-dma-compat.h>
+
+#define PCIBIOS_MIN_IO 0
+#define PCIBIOS_MIN_MEM 0
+
+/*
+ * Set to 1 if the kernel should re-assign all PCI bus numbers
+ */
+#define pcibios_assign_all_busses() \
+ (pci_has_flag(PCI_REASSIGN_ALL_BUS))
+
+/*
+ * PCI address space differs from physical memory address space
+ */
+#define PCI_DMA_BUS_IS_PHYS (0)
+
+extern int isa_dma_bridge_buggy;
+
+extern int pci_domain_nr(struct pci_bus *bus);
+extern int pci_proc_domain(struct pci_bus *bus);
+
+extern int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr);
+
+#endif /* __KERNEL__ */
+#endif /* __ASM_PCI_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 2d7fcc1..8cfec47 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -21,6 +21,7 @@ arm64-obj-$(CONFIG_EARLY_PRINTK) += early_printk.o
arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND) += sleep.o suspend.o
arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
arm64-obj-$(CONFIG_SCHED_HMP) += sched_hmp.o
+arm64-obj-$(CONFIG_PCI) += pci.o
obj-y += $(arm64-obj-y) vdso/
obj-m += $(arm64-obj-m)
diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
new file mode 100644
index 0000000..7b652cf
--- /dev/null
+++ b/arch/arm64/kernel/pci.c
@@ -0,0 +1,112 @@
+/*
+ * Code borrowed from powerpc/kernel/pci-common.c
+ *
+ * Copyright (C) 2003 Anton Blanchard <anton@au.ibm.com>, IBM
+ * Copyright (C) 2014 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2 as published by the Free Software Foundation.
+ *
+ */
+
+#include <linux/init.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/mm.h>
+#include <linux/of_pci.h>
+#include <linux/of_platform.h>
+#include <linux/slab.h>
+
+#include <asm/pci-bridge.h>
+
+
+/*
+ * Return the domain number for this bus
+ */
+int pci_domain_nr(struct pci_bus *bus)
+{
+ struct pci_host_bridge *bridge = to_pci_host_bridge(bus->bridge);
+
+ if (bridge)
+ return bridge->domain_nr;
+
+ return 0;
+}
+
+int pci_proc_domain(struct pci_bus *bus)
+{
+ return pci_domain_nr(bus);
+}
+
+/*
+ * Called after each bus is probed, but before its children are examined
+ */
+void pcibios_fixup_bus(struct pci_bus *bus)
+{
+ struct pci_dev *dev;
+ struct resource *res;
+ int i;
+
+ if (bus->self != NULL) {
+ pci_read_bridge_bases(bus);
+
+ pci_bus_for_each_resource(bus, res, i) {
+ if (!res || !res->flags || res->parent)
+ continue;
+
+ /*
+ * If we are going to reassign everything, we can
+ * shrink the P2P resource to have zero size to
+ * save space
+ */
+ if (pci_has_flag(PCI_REASSIGN_ALL_RSRC)) {
+ res->flags |= IORESOURCE_UNSET;
+ res->start = 0;
+ res->end = -1;
+ continue;
+ }
+ }
+ }
+
+ list_for_each_entry(dev, &bus->devices, bus_list) {
+ /* Ignore fully discovered devices */
+ if (dev->is_added)
+ continue;
+
+ set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
+
+ /* Read default IRQs and fixup if necessary */
+ dev->irq = of_irq_parse_and_map_pci(dev, 0, 0);
+ }
+}
+EXPORT_SYMBOL(pcibios_fixup_bus);
+
+/*
+ * We don't have to worry about legacy ISA devices, so nothing to do here
+ */
+resource_size_t pcibios_align_resource(void *data, const struct resource *res,
+ resource_size_t size, resource_size_t align)
+{
+ return ALIGN(res->start, align);
+}
+EXPORT_SYMBOL(pcibios_align_resource);
+
+int pcibios_enable_device(struct pci_dev *dev, int mask)
+{
+ return pci_enable_resources(dev, mask);
+}
+
+void pcibios_fixup_bridge_ranges(struct list_head *resources)
+{
+}
+
+int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
+{
+ BUG_ON(offset + SZ_64K - 1 > IO_SPACE_LIMIT);
+
+ return ioremap_page_range((unsigned long)PCI_IOBASE + offset,
+ (unsigned long)PCI_IOBASE + offset + SZ_64K,
+ phys_addr,
+ __pgprot(PROT_DEVICE_nGnRE));
+}
--
1.8.5.3
^ permalink raw reply related
* [PATCH] pci: Add support for creating a generic host_bridge from device tree
From: Arnd Bergmann @ 2014-02-03 18:46 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391452428-22917-2-git-send-email-Liviu.Dudau@arm.com>
On Monday 03 February 2014 18:33:48 Liviu Dudau wrote:
> +/**
> + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
> + * @dev: device node of the host bridge having the range property
> + * @resources: list where the range of resources will be added after DT parsing
> + *
> + * This function will parse the "ranges" property of a PCI host bridge device
> + * node and setup the resource mapping based on its content. It is expected
> + * that the property conforms with the Power ePAPR document.
> + *
> + * Each architecture will then apply their filtering based on the limitations
> + * of each platform. One general restriction seems to be the number of IO space
> + * ranges, the PCI framework makes intensive use of struct resource management,
> + * and for IORESOURCE_IO types they can only be requested if they are contained
> + * within the global ioport_resource, so that should be limited to one IO space
> + * range.
Actually we have quite a different set of restrictions around I/O space on ARM32
at the moment: Each host bridge can have its own 64KB range in an arbitrary
location on MMIO space, and the total must not exceed 2MB of I/O space.
> + */
> +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
> + struct list_head *resources)
> +{
> + struct resource *res;
> + struct of_pci_range range;
> + struct of_pci_range_parser parser;
> + int err;
> +
> + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
> +
> + /* Check for ranges property */
> + err = of_pci_range_parser_init(&parser, dev);
> + if (err)
> + return err;
> +
> + pr_debug("Parsing ranges property...\n");
> + for_each_of_pci_range(&parser, &range) {
> + /* Read next ranges element */
> + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> + range.pci_space, range.pci_addr);
> + pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> + range.cpu_addr, range.size);
> +
> + /* If we failed translation or got a zero-sized region
> + * (some FW try to feed us with non sensical zero sized regions
> + * such as power3 which look like some kind of attempt
> + * at exposing the VGA memory hole) then skip this range
> + */
> + if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> + continue;
> +
> + res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> + if (!res) {
> + err = -ENOMEM;
> + goto bridge_ranges_nomem;
> + }
> +
> + of_pci_range_to_resource(&range, dev, res);
> +
> + pci_add_resource_offset(resources, res,
> + range.cpu_addr - range.pci_addr);
> + }
I believe of_pci_range_to_resource() will return the MMIO aperture for the
I/O space window here, which is not what you are supposed to pass into
pci_add_resource_offset.
> +EXPORT_SYMBOL(pci_host_bridge_of_init);
EXPORT_SYMBOL_GPL
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index 6e34498..16febae 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -1787,6 +1787,17 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> list_for_each_entry_safe(window, n, resources, list) {
> list_move_tail(&window->list, &bridge->windows);
> res = window->res;
> + /*
> + * IO resources are stored in the kernel with a CPU start
> + * address of zero. Adjust the data accordingly and remember
> + * the offset
> + */
> + if (resource_type(res) == IORESOURCE_IO) {
> + bridge->io_offset = res->start;
> + res->end -= res->start;
> + window->offset -= res->start;
> + res->start = 0;
> + }
> offset = window->offset;
> if (res->flags & IORESOURCE_BUS)
Won't this break all existing host bridges?
Arnd
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-03 18:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391453028-23191-2-git-send-email-Liviu.Dudau@arm.com>
On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:
> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> index 4cc813e..ce5bad2 100644
> --- a/arch/arm64/include/asm/io.h
> +++ b/arch/arm64/include/asm/io.h
> @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> /*
> * I/O port access primitives.
> */
> +#define arch_has_dev_port() (0)
Why not?
> #define IO_SPACE_LIMIT 0xffff
You probably want to increase this a bit, to allow multiple host bridges
to have their own I/O space.
> #define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_2M))
And modify this location: There is no particular reason to have the I/O space
mapped exactly 2MB below the loadable modules, as virtual address space is
essentially free.
> +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> +#define ioport_unmap(addr)
inline functions?
> static inline u8 inb(unsigned long addr)
> {
> return readb(addr + PCI_IOBASE);
> diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> new file mode 100644
> index 0000000..dd084a3
> --- /dev/null
> +++ b/arch/arm64/include/asm/pci.h
> @@ -0,0 +1,35 @@
> +#ifndef __ASM_PCI_H
> +#define __ASM_PCI_H
> +#ifdef __KERNEL__
> +
> +#include <linux/types.h>
> +#include <linux/slab.h>
> +#include <linux/dma-mapping.h>
> +
> +#include <asm/io.h>
> +#include <asm-generic/pci-bridge.h>
> +#include <asm-generic/pci-dma-compat.h>
> +
> +#define PCIBIOS_MIN_IO 0
> +#define PCIBIOS_MIN_MEM 0
PCIBIOS_MIN_IO is normally set to 0x1000, to stay out of the ISA range.
> diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> new file mode 100644
> index 0000000..7b652cf
> --- /dev/null
> +++ b/arch/arm64/kernel/pci.c
> @@ -0,0 +1,112 @@
None of this looks really arm64 specific, nor should it be. I think
we should try a little harder to move this as a default implementation
into common code, even if we start out by having all architectures
override it.
> +int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
> +{
> + BUG_ON(offset + SZ_64K - 1 > IO_SPACE_LIMIT);
> +
> + return ioremap_page_range((unsigned long)PCI_IOBASE + offset,
> + (unsigned long)PCI_IOBASE + offset + SZ_64K,
> + phys_addr,
> + __pgprot(PROT_DEVICE_nGnRE));
> +}
Not sure if we want to treat this one as architecture specific though.
It certainly won't be portable to x86, but it could be shared with
a couple of others. We may also want to redesign the interface.
I've been thinking we could make this function allocate space in the
Linux virtual I/O space aperture, and pass two resources into it
(physical I/O aperture and bus I/O range), and get the actual
io_offset as the return value, or a negative error number.
That way, you could have an arbitrary number of host bridges in the
system and each one gets a share of the virtual aperture until
it's full.
Arnd
^ permalink raw reply
* [PATCH] pci: Add support for creating a generic host_bridge from device tree
From: Liviu Dudau @ 2014-02-03 19:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7398333.9L5KlyFggU@wuerfel>
Hi Arnd,
First of all, thanks for reviewing this!
On Mon, Feb 03, 2014 at 06:46:10PM +0000, Arnd Bergmann wrote:
> On Monday 03 February 2014 18:33:48 Liviu Dudau wrote:
> > +/**
> > + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
> > + * @dev: device node of the host bridge having the range property
> > + * @resources: list where the range of resources will be added after DT parsing
> > + *
> > + * This function will parse the "ranges" property of a PCI host bridge device
> > + * node and setup the resource mapping based on its content. It is expected
> > + * that the property conforms with the Power ePAPR document.
> > + *
> > + * Each architecture will then apply their filtering based on the limitations
> > + * of each platform. One general restriction seems to be the number of IO space
> > + * ranges, the PCI framework makes intensive use of struct resource management,
> > + * and for IORESOURCE_IO types they can only be requested if they are contained
> > + * within the global ioport_resource, so that should be limited to one IO space
> > + * range.
>
> Actually we have quite a different set of restrictions around I/O space on ARM32
> at the moment: Each host bridge can have its own 64KB range in an arbitrary
> location on MMIO space, and the total must not exceed 2MB of I/O space.
And that is why the filtering is not (yet) imposed in the generic code. But once
you use pci_request_region, that will call request_region which will check
against ioport_resource as parent for the requested resource. That should fail
if is is not in the correct range, so I don't know how arm arch code manages
multiple IO ranges.
>
> > + */
> > +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
> > + struct list_head *resources)
> > +{
> > + struct resource *res;
> > + struct of_pci_range range;
> > + struct of_pci_range_parser parser;
> > + int err;
> > +
> > + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
> > +
> > + /* Check for ranges property */
> > + err = of_pci_range_parser_init(&parser, dev);
> > + if (err)
> > + return err;
> > +
> > + pr_debug("Parsing ranges property...\n");
> > + for_each_of_pci_range(&parser, &range) {
> > + /* Read next ranges element */
> > + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> > + range.pci_space, range.pci_addr);
> > + pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> > + range.cpu_addr, range.size);
> > +
> > + /* If we failed translation or got a zero-sized region
> > + * (some FW try to feed us with non sensical zero sized regions
> > + * such as power3 which look like some kind of attempt
> > + * at exposing the VGA memory hole) then skip this range
> > + */
> > + if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> > + continue;
> > +
> > + res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> > + if (!res) {
> > + err = -ENOMEM;
> > + goto bridge_ranges_nomem;
> > + }
> > +
> > + of_pci_range_to_resource(&range, dev, res);
> > +
> > + pci_add_resource_offset(resources, res,
> > + range.cpu_addr - range.pci_addr);
> > + }
>
> I believe of_pci_range_to_resource() will return the MMIO aperture for the
> I/O space window here, which is not what you are supposed to pass into
> pci_add_resource_offset.
And that is why the code in probe.c has been added to deal with that. It is
too early to do the adjustments here as all we have is the list of resources
and that might get culled by the architecture fixup code. Remembering the
io_offset will happen once the pci_host_bridge gets created, and the resources
are then adjusted.
>
> > +EXPORT_SYMBOL(pci_host_bridge_of_init);
>
> EXPORT_SYMBOL_GPL
Will change for v2, thanks!
>
> > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > index 6e34498..16febae 100644
> > --- a/drivers/pci/probe.c
> > +++ b/drivers/pci/probe.c
> > @@ -1787,6 +1787,17 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> > list_for_each_entry_safe(window, n, resources, list) {
> > list_move_tail(&window->list, &bridge->windows);
> > res = window->res;
> > + /*
> > + * IO resources are stored in the kernel with a CPU start
> > + * address of zero. Adjust the data accordingly and remember
> > + * the offset
> > + */
> > + if (resource_type(res) == IORESOURCE_IO) {
> > + bridge->io_offset = res->start;
> > + res->end -= res->start;
> > + window->offset -= res->start;
> > + res->start = 0;
> > + }
> > offset = window->offset;
> > if (res->flags & IORESOURCE_BUS)
>
> Won't this break all existing host bridges?
I am not sure. I believe not, due to what I've explained earlier, but you might be right.
The adjustment happens before the resource is added to the host bridge windows and translates
it from MMIO range into IO range.
Best regards,
Liviu
>
> Arnd
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
^ permalink raw reply
* [PATCH] arm64: Add architecture support for PCI
From: Liviu Dudau @ 2014-02-03 19:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <21596846.kVTqp7roW4@wuerfel>
On Mon, Feb 03, 2014 at 06:58:56PM +0000, Arnd Bergmann wrote:
> On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:
> > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> > index 4cc813e..ce5bad2 100644
> > --- a/arch/arm64/include/asm/io.h
> > +++ b/arch/arm64/include/asm/io.h
> > @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> > /*
> > * I/O port access primitives.
> > */
> > +#define arch_has_dev_port() (0)
>
> Why not?
Maybe I got it the wrong way around, but the comment in include/linux/io.h says:
/*
* Some systems do not have legacy ISA devices.
* /dev/port is not a valid interface on these systems.
* So for those archs, <asm/io.h> should define the following symbol.
*/
So ... defining it should mean no legacy ISA devices, right?
>
> > #define IO_SPACE_LIMIT 0xffff
>
> You probably want to increase this a bit, to allow multiple host bridges
> to have their own I/O space.
OK, but to what size?
>
> > #define PCI_IOBASE ((void __iomem *)(MODULES_VADDR - SZ_2M))
>
> And modify this location: There is no particular reason to have the I/O space
> mapped exactly 2MB below the loadable modules, as virtual address space is
> essentially free.
Will talk with Catalin about where to place this.
>
> > +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> > +#define ioport_unmap(addr)
>
> inline functions?
Will do, thanks!
>
> > static inline u8 inb(unsigned long addr)
> > {
> > return readb(addr + PCI_IOBASE);
> > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> > new file mode 100644
> > index 0000000..dd084a3
> > --- /dev/null
> > +++ b/arch/arm64/include/asm/pci.h
> > @@ -0,0 +1,35 @@
> > +#ifndef __ASM_PCI_H
> > +#define __ASM_PCI_H
> > +#ifdef __KERNEL__
> > +
> > +#include <linux/types.h>
> > +#include <linux/slab.h>
> > +#include <linux/dma-mapping.h>
> > +
> > +#include <asm/io.h>
> > +#include <asm-generic/pci-bridge.h>
> > +#include <asm-generic/pci-dma-compat.h>
> > +
> > +#define PCIBIOS_MIN_IO 0
> > +#define PCIBIOS_MIN_MEM 0
>
> PCIBIOS_MIN_IO is normally set to 0x1000, to stay out of the ISA range.
:) No ISA support! (Die ISA, die!!)
>
> > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > new file mode 100644
> > index 0000000..7b652cf
> > --- /dev/null
> > +++ b/arch/arm64/kernel/pci.c
> > @@ -0,0 +1,112 @@
>
> None of this looks really arm64 specific, nor should it be. I think
> we should try a little harder to move this as a default implementation
> into common code, even if we start out by having all architectures
> override it.
Agree. This is the RFC version. I didn't dare to post a patch with fixes
for all architectures. :)
>
> > +int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
> > +{
> > + BUG_ON(offset + SZ_64K - 1 > IO_SPACE_LIMIT);
> > +
> > + return ioremap_page_range((unsigned long)PCI_IOBASE + offset,
> > + (unsigned long)PCI_IOBASE + offset + SZ_64K,
> > + phys_addr,
> > + __pgprot(PROT_DEVICE_nGnRE));
> > +}
>
> Not sure if we want to treat this one as architecture specific though.
> It certainly won't be portable to x86, but it could be shared with
> a couple of others. We may also want to redesign the interface.
> I've been thinking we could make this function allocate space in the
> Linux virtual I/O space aperture, and pass two resources into it
> (physical I/O aperture and bus I/O range), and get the actual
> io_offset as the return value, or a negative error number.
Not sure I completely follow your idea.
>
> That way, you could have an arbitrary number of host bridges in the
> system and each one gets a share of the virtual aperture until
> it's full.
One still needs to fix the pci_request_region use that checks against
ioport_resource. But it is an interesting idea.
>
> Arnd
>
>
Thanks for reviewing this patch!
Liviu
--
====================
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---------------
?\_(?)_/?
-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782
^ permalink raw reply
* [PATCH] ARM: unistd.h: relocate comments back to place
From: Baruch Siach @ 2014-02-03 19:21 UTC (permalink / raw)
To: linux-arm-kernel
Commit cb8db5d45 (UAPI: (Scripted) Disintegrate arch/arm/include/asm) moved
these syscall comments out of their context into the UAPI headers. Fix this.
Fixes: cb8db5d4578a ("UAPI: (Scripted) Disintegrate arch/arm/include/asm")
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
arch/arm/include/asm/unistd.h | 10 ++++++++++
arch/arm/include/uapi/asm/unistd.h | 11 -----------
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/arm/include/asm/unistd.h b/arch/arm/include/asm/unistd.h
index acabef1a75df..4229595e5c04 100644
--- a/arch/arm/include/asm/unistd.h
+++ b/arch/arm/include/asm/unistd.h
@@ -15,7 +15,17 @@
#include <uapi/asm/unistd.h>
+/*
+ * This may need to be greater than __NR_last_syscall+1 in order to
+ * account for the padding in the syscall table
+ */
#define __NR_syscalls (384)
+
+/*
+ * *NOTE*: This is a ghost syscall private to the kernel. Only the
+ * __kuser_cmpxchg code in entry-armv.S should be aware of its
+ * existence. Don't ever use this from user code.
+ */
#define __ARM_NR_cmpxchg (__ARM_NR_BASE+0x00fff0)
#define __ARCH_WANT_STAT64
diff --git a/arch/arm/include/uapi/asm/unistd.h b/arch/arm/include/uapi/asm/unistd.h
index fb5584d0cc05..c3776331f407 100644
--- a/arch/arm/include/uapi/asm/unistd.h
+++ b/arch/arm/include/uapi/asm/unistd.h
@@ -410,11 +410,6 @@
#define __NR_sched_getattr (__NR_SYSCALL_BASE+381)
/*
- * This may need to be greater than __NR_last_syscall+1 in order to
- * account for the padding in the syscall table
- */
-
-/*
* The following SWIs are ARM private.
*/
#define __ARM_NR_BASE (__NR_SYSCALL_BASE+0x0f0000)
@@ -425,12 +420,6 @@
#define __ARM_NR_set_tls (__ARM_NR_BASE+5)
/*
- * *NOTE*: This is a ghost syscall private to the kernel. Only the
- * __kuser_cmpxchg code in entry-armv.S should be aware of its
- * existence. Don't ever use this from user code.
- */
-
-/*
* The following syscalls are obsolete and no longer available for EABI.
*/
#if !defined(__KERNEL__)
--
1.8.5.3
^ permalink raw reply related
* [RFC] dtc: add ability to make nodes conditional on them being referenced
From: Maxime Ripard @ 2014-02-03 19:22 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1578575.rVWgTPdq1W@phil>
Hi,
On Thu, Jan 30, 2014 at 01:25:56PM +0100, Heiko St?bner wrote:
> From: Heiko Stuebner <heiko.stuebner@bqreaders.com>
>
> On i.MX, which carries a lot of pin-groups of which most are unused on
> individual boards, they noticed that this plehora of nodes also results
> in the runtime-lookup-performance also degrading [0].
>
> A i.MX-specific solution defining the pingroups in the board files but
> using macros to reference the pingroup-data was not well received
>
> This patch is trying to solve this issue in a more general way, by
> adding the ability to mark nodes as needing to be referenced somewhere
> in the tree.
>
> To mark a node a needing to be referenced it must be prefixed with
> /delete-unreferenced/. This makes dtc check the nodes reference-status
> when creating the flattened tree, dropping it if unreferenced.
>
> For example, the i.MX6SL pingroup
>
> /delete-uneferenced/ pinctrl_ecspi1_1: ecspi1grp-1 {
> fsl,pins = <
> MX6SL_PAD_ECSPI1_MISO__ECSPI1_MISO 0x100b1
> MX6SL_PAD_ECSPI1_MOSI__ECSPI1_MOSI 0x100b1
> MX6SL_PAD_ECSPI1_SCLK__ECSPI1_SCLK 0x100b1
> >;
> };
>
> would only be included in the dtb if it got referenced somewhere
> as pingroup via
>
> node {
> pinctrl-0 <&pinctrl_ecscpi1_1>;
> };
>
> [0] http://thread.gmane.org/gmane.linux.ports.arm.kernel/275912/
>
> Signed-off-by: Heiko Stuebner <heiko.stuebner@bqreaders.com>
> ---
> This is just the idea I had in [1] explored a bit more. I'm definitely
> not sure if this is a valid approach to the problem.
> Also this is my first venture into dtc as well as flex and bison :-) .
>
> [1] http://www.spinics.net/lists/arm-kernel/msg303731.html
This is a nice feature to have :)
However, I wonder wether it's the right way of implementing it. I'd
have another use case for this, which would be to embed a DT in a
first-stage bootloader. We have around 7kB available currently for the
DT, and this is actually less than any of our (very small already)
DTBs. So having this of feature makes complete sense to us
too. However, we also have some other tools that require most of the
nodes to be in the DTB.
So I guess turning wether we should delete a node if unreferenced into
a dtc option would make sense, since every DT user will be able to
choose, without having to duplicate the DT and make conflicting
changes.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140203/4771d4c2/attachment-0001.sig>
^ permalink raw reply
* [PATCH v3 1/8] clk: sunxi: Add Allwinner A20/A31 GMAC clock unit
From: Maxime Ripard @ 2014-02-03 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391398346-5094-2-git-send-email-wens@csie.org>
Hi,
On Mon, Feb 03, 2014 at 11:32:19AM +0800, Chen-Yu Tsai wrote:
> The Allwinner A20/A31 clock module controls the transmit clock source
> and interface type of the GMAC ethernet controller. Model this as
> a single clock for GMAC drivers to use.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> Documentation/devicetree/bindings/clock/sunxi.txt | 26 +++++++
> drivers/clk/sunxi/clk-sunxi.c | 83 +++++++++++++++++++++++
> 2 files changed, 109 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt b/Documentation/devicetree/bindings/clock/sunxi.txt
> index 0cf679b..f43b4c0 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -37,6 +37,7 @@ Required properties:
> "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
> "allwinner,sun4i-mod0-clk" - for the module 0 family of clocks
> "allwinner,sun7i-a20-out-clk" - for the external output clocks
> + "allwinner,sun7i-a20-gmac-clk" - for the GMAC clock module on A20/A31
>
> Required properties for all clocks:
> - reg : shall be the control register address for the clock.
> @@ -50,6 +51,9 @@ Required properties for all clocks:
> If the clock module only has one output, the name shall be the
> module name.
>
> +For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
> +dummy clocks at 25 MHz and 125 MHz, respectively. See example.
> +
> Clock consumers should specify the desired clocks they use with a
> "clocks" phandle cell. Consumers that are using a gated clock should
> provide an additional ID in their clock property. This ID is the
> @@ -96,3 +100,25 @@ mmc0_clk: clk at 01c20088 {
> clocks = <&osc24M>, <&pll6 1>, <&pll5 1>;
> clock-output-names = "mmc0";
> };
> +
> +mii_phy_tx_clk: clk at 2 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <25000000>;
> + clock-output-names = "mii_phy_tx";
> +};
> +
> +gmac_int_tx_clk: clk at 3 {
> + #clock-cells = <0>;
> + compatible = "fixed-clock";
> + clock-frequency = <125000000>;
> + clock-output-names = "gmac_int_tx";
> +};
> +
> +gmac_clk: clk at 01c20164 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun7i-a20-gmac-clk";
> + reg = <0x01c20164 0x4>;
> + clocks = <&mii_phy_tx_clk>, <&gmac_int_tx_clk>;
You should also document in which order you expect the parents to
be. Or it will probably be easier to just use clock-names here.
> + clock-output-names = "gmac";
> +};
> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> index 736fb60..0b361d2 100644
> --- a/drivers/clk/sunxi/clk-sunxi.c
> +++ b/drivers/clk/sunxi/clk-sunxi.c
> @@ -379,6 +379,89 @@ static void sun7i_a20_get_out_factors(u32 *freq, u32 parent_rate,
>
>
> /**
> + * sun7i_a20_gmac_clk_setup - Setup function for A20/A31 GMAC clock module
> + *
> + * This clock looks something like this
> + * ________________________
> + * MII TX clock from PHY >-----|___________ _________|----> to GMAC core
> + * GMAC Int. RGMII TX clk >----|___________\__/__gate---|----> to PHY
> + * Ext. 125MHz RGMII TX clk >--|__divider__/ |
> + * |________________________|
> + *
> + * The external 125 MHz reference is optional, i.e. GMAC can use its
> + * internal TX clock just fine. The A31 GMAC clock module does not have
> + * the divider controls for the external reference.
> + *
> + * To keep it simple, let the GMAC use either the MII TX clock for MII mode,
> + * and its internal TX clock for GMII and RGMII modes. The GMAC driver should
> + * select the appropriate source and gate/ungate the output to the PHY.
> + *
> + * Only the GMAC should use this clock. Altering the clock so that it doesn't
> + * match the GMAC's operation parameters will result in the GMAC not being
> + * able to send traffic out. The GMAC driver should set the clock rate and
> + * enable/disable this clock to configure the required state. The clock
> + * driver then responds by auto-reparenting the clock.
> + */
> +
> +#define SUN7I_A20_GMAC_GPIT 2
> +#define SUN7I_A20_GMAC_MASK 0x3
> +#define SUN7I_A20_GMAC_MAX_PARENTS 2
> +
> +static void __init sun7i_a20_gmac_clk_setup(struct device_node *node)
> +{
> + struct clk *clk;
> + struct clk_mux *mux;
> + struct clk_gate *gate;
> + const char *clk_name = node->name;
> + const char *parents[SUN7I_A20_GMAC_MAX_PARENTS];
> + void *reg;
> + int i = 0;
> +
> + /* allocate mux and gate clock structs */
> + mux = kzalloc(sizeof(struct clk_mux), GFP_KERNEL);
> + if (!mux)
> + return;
Newline.
> + gate = kzalloc(sizeof(struct clk_gate), GFP_KERNEL);
> + if (!gate) {
> + kfree(mux);
> + return;
> + }
> +
> + reg = of_iomap(node, 0);
You should check for the return code here.
> + of_property_read_string(node, "clock-output-names", &clk_name);
And here too, since you made the clock-output-names property mandatory
> + while (i < SUN7I_A20_GMAC_MAX_PARENTS &&
> + (parents[i] = of_clk_get_parent_name(node, i)) != NULL)
You should check for an error here too, but if you switch to using
clock-names, that will probably be refactored anyway.
> + i++;
> +
> + /* set up gate and fixed rate properties */
> + gate->reg = reg;
> + gate->bit_idx = SUN7I_A20_GMAC_GPIT;
> + gate->lock = &clk_lock;
> + mux->reg = reg;
> + mux->mask = SUN7I_A20_GMAC_MASK;
> + mux->flags = CLK_MUX_INDEX_BIT;
> + mux->lock = &clk_lock;
> +
> + clk = clk_register_composite(NULL, clk_name,
> + parents, i,
> + &mux->hw, &clk_mux_ops,
> + NULL, NULL,
> + &gate->hw, &clk_gate_ops,
> + 0);
> +
> + if (!IS_ERR(clk)) {
> + of_clk_add_provider(node, of_clk_src_simple_get, clk);
> + clk_register_clkdev(clk, clk_name, NULL);
> + }
> +}
> +CLK_OF_DECLARE(sun7i_a20_gmac, "allwinner,sun7i-a20-gmac-clk",
> + sun7i_a20_gmac_clk_setup);
> +
> +
> +
> +/**
> * sunxi_factors_clk_setup() - Setup function for factor clocks
> */
>
> --
> 1.9.rc1
>
It looks fine otherwise.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140203/1ee9717e/attachment.sig>
^ permalink raw reply
* [PATCH] pci: Add support for creating a generic host_bridge from device tree
From: Arnd Bergmann @ 2014-02-03 19:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203190649.GB4889@e106497-lin.cambridge.arm.com>
On Monday 03 February 2014 19:06:49 Liviu Dudau wrote:
> On Mon, Feb 03, 2014 at 06:46:10PM +0000, Arnd Bergmann wrote:
> > On Monday 03 February 2014 18:33:48 Liviu Dudau wrote:
> > > +/**
> > > + * pci_host_bridge_of_get_ranges - Parse PCI host bridge resources from DT
> > > + * @dev: device node of the host bridge having the range property
> > > + * @resources: list where the range of resources will be added after DT parsing
> > > + *
> > > + * This function will parse the "ranges" property of a PCI host bridge device
> > > + * node and setup the resource mapping based on its content. It is expected
> > > + * that the property conforms with the Power ePAPR document.
> > > + *
> > > + * Each architecture will then apply their filtering based on the limitations
> > > + * of each platform. One general restriction seems to be the number of IO space
> > > + * ranges, the PCI framework makes intensive use of struct resource management,
> > > + * and for IORESOURCE_IO types they can only be requested if they are contained
> > > + * within the global ioport_resource, so that should be limited to one IO space
> > > + * range.
> >
> > Actually we have quite a different set of restrictions around I/O space on ARM32
> > at the moment: Each host bridge can have its own 64KB range in an arbitrary
> > location on MMIO space, and the total must not exceed 2MB of I/O space.
>
> And that is why the filtering is not (yet) imposed in the generic code. But once
> you use pci_request_region, that will call request_region which will check
> against ioport_resource as parent for the requested resource. That should fail
> if is is not in the correct range, so I don't know how arm arch code manages
> multiple IO ranges.
Let's try to come up with nomenclature so we can talk about this better
The ioport_resource is in "logical I/O space", which is a Linux fiction,
it goes from 0 to IO_SPACE_LIMIT (2MB on ARM) and is mapped into "virtual
I/O space", which start at (void __iomem *)PCI_IO_VIRT_BASE.
Each PCI domain can have its own "bus I/O aperture", which is typically
between 0x1000 and 0xffff and reflects the address that is used in PCI
transactions and in BARs. The aperture here reflects the subset of the
4GB bus I/O space that is actually mapped into a CPU visible "physical
I/O aperture" using an inbound mapping of the host bridge. The physical
I/O aperture in turn gets mapped to the virtual I/O space using
pci_ioremap_io. The difference between a bus I/O address and a logical
I/O address is stored in the io_offset.
So much for basic definitions. When a device driver calls pci_request_region,
the port number it sees is the bus I/O port number adjusted using the
io_offset to turn it into a logical I/O port number, which should
always be within the host bridge window, which in turn is a subset
of the ioport_resource.
> > > +static int pci_host_bridge_of_get_ranges(struct device_node *dev,
> > > + struct list_head *resources)
> > > +{
> > > + struct resource *res;
> > > + struct of_pci_range range;
> > > + struct of_pci_range_parser parser;
> > > + int err;
> > > +
> > > + pr_info("PCI host bridge %s ranges:\n", dev->full_name);
> > > +
> > > + /* Check for ranges property */
> > > + err = of_pci_range_parser_init(&parser, dev);
> > > + if (err)
> > > + return err;
> > > +
> > > + pr_debug("Parsing ranges property...\n");
> > > + for_each_of_pci_range(&parser, &range) {
> > > + /* Read next ranges element */
> > > + pr_debug("pci_space: 0x%08x pci_addr:0x%016llx ",
> > > + range.pci_space, range.pci_addr);
> > > + pr_debug("cpu_addr:0x%016llx size:0x%016llx\n",
> > > + range.cpu_addr, range.size);
> > > +
> > > + /* If we failed translation or got a zero-sized region
> > > + * (some FW try to feed us with non sensical zero sized regions
> > > + * such as power3 which look like some kind of attempt
> > > + * at exposing the VGA memory hole) then skip this range
> > > + */
> > > + if (range.cpu_addr == OF_BAD_ADDR || range.size == 0)
> > > + continue;
> > > +
> > > + res = kzalloc(sizeof(struct resource), GFP_KERNEL);
> > > + if (!res) {
> > > + err = -ENOMEM;
> > > + goto bridge_ranges_nomem;
> > > + }
> > > +
> > > + of_pci_range_to_resource(&range, dev, res);
> > > +
> > > + pci_add_resource_offset(resources, res,
> > > + range.cpu_addr - range.pci_addr);
> > > + }
> >
> > I believe of_pci_range_to_resource() will return the MMIO aperture for the
> > I/O space window here, which is not what you are supposed to pass into
> > pci_add_resource_offset.
>
> And that is why the code in probe.c has been added to deal with that. It is
> too early to do the adjustments here as all we have is the list of resources
> and that might get culled by the architecture fixup code. Remembering the
> io_offset will happen once the pci_host_bridge gets created, and the resources
> are then adjusted.
So you want to register an incorrect I/O resource first and then
have it fixed up later, rather than registering the correct
one from the start as everyone else?
> > > diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> > > index 6e34498..16febae 100644
> > > --- a/drivers/pci/probe.c
> > > +++ b/drivers/pci/probe.c
> > > @@ -1787,6 +1787,17 @@ struct pci_bus *pci_create_root_bus(struct device *parent, int bus,
> > > list_for_each_entry_safe(window, n, resources, list) {
> > > list_move_tail(&window->list, &bridge->windows);
> > > res = window->res;
> > > + /*
> > > + * IO resources are stored in the kernel with a CPU start
> > > + * address of zero. Adjust the data accordingly and remember
> > > + * the offset
> > > + */
> > > + if (resource_type(res) == IORESOURCE_IO) {
> > > + bridge->io_offset = res->start;
> > > + res->end -= res->start;
> > > + window->offset -= res->start;
> > > + res->start = 0;
> > > + }
> > > offset = window->offset;
> > > if (res->flags & IORESOURCE_BUS)
> >
> > Won't this break all existing host bridges?
>
> I am not sure. I believe not, due to what I've explained earlier, but you might be right.
>
> The adjustment happens before the resource is added to the host bridge windows and translates
> it from MMIO range into IO range.
AFAICT, the resource_type of the resource you register above should be
IORESOURCE_MEM, so you are not actually matching it here.
Arnd
^ permalink raw reply
* [PATCH v3 2/8] ARM: dts: sun7i: Add GMAC clock node to sun7i DTSI
From: Maxime Ripard @ 2014-02-03 19:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391398346-5094-3-git-send-email-wens@csie.org>
On Mon, Feb 03, 2014 at 11:32:20AM +0800, Chen-Yu Tsai wrote:
> The GMAC uses 1 of 2 sources for its transmit clock, depending on the
> PHY interface mode. Add both sources as dummy clocks, and as parents
> to the GMAC clock node.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 1595e9a..fc7f470 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -314,6 +314,34 @@
> };
>
> /*
> + * The following two are dummy clocks, placeholders used
> + * on gmac_tx clock. The actual frequency and availability
> + * depends on the external PHY, operation mode and link
> + * speed.
> + */
If it depends on the external PHY, I guess that means it also depends
on the board, right? Or is the GMAC supposed to always have that clock
running at 25MHz, no matter what PHY is connected to it?
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140203/7297c745/attachment.sig>
^ permalink raw reply
* [PATCH v3 8/8] ARM: dts: sun7i: Add ethernet alias for GMAC
From: Maxime Ripard @ 2014-02-03 19:38 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391398346-5094-9-git-send-email-wens@csie.org>
On Mon, Feb 03, 2014 at 11:32:26AM +0800, Chen-Yu Tsai wrote:
> U-Boot will insert MAC address into the device tree image.
> It looks up ethernet[0-5] aliases to find the ethernet nodes.
> Alias GMAC as ethernet0, as it is the only ethernet controller used.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 65fb8d0..c48fb11 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -17,7 +17,7 @@
> interrupt-parent = <&gic>;
>
> aliases {
> - ethernet0 = &emac;
> + ethernet0 = &gmac;
> };
I'm not very fond of this patch.
People might rely on the fact that ethernet0 is actually the emac, and
are expecting u-boot to fill the ethaddr variable to the emac, and not
the gmac.
Since u-boot is totally able to deal with several ethernet addresses,
please add it as ethernet1.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140203/27a51970/attachment-0001.sig>
^ permalink raw reply
* [RFC PATCH V3 1/4] pci: APM X-Gene PCIe controller driver
From: Tanmay Inamdar @ 2014-02-03 19:42 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201401301516.27091.arnd@arndb.de>
On Thu, Jan 30, 2014 at 6:16 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Friday 24 January 2014, Tanmay Inamdar wrote:
>
>> +static void xgene_pcie_fixup_bridge(struct pci_dev *dev)
>> +{
>> + int i;
>> +
>> + /* Hide the PCI host BARs from the kernel as their content doesn't
>> + * fit well in the resource management
>> + */
>> + for (i = 0; i < DEVICE_COUNT_RESOURCE; i++) {
>> + dev->resource[i].start = dev->resource[i].end = 0;
>> + dev->resource[i].flags = 0;
>> + }
>> + dev_info(&dev->dev, "Hiding X-Gene pci host bridge resources %s\n",
>> + pci_name(dev));
>> +}
>> +DECLARE_PCI_FIXUP_HEADER(XGENE_PCIE_VENDORID, XGENE_PCIE_DEVICEID,
>> + xgene_pcie_fixup_bridge);
>
> Shouldn't this be gone now that the host bridge is correctly shown
> at the domain root?
In inbound region configuration, whole DDR space is mapped into the
BAR of RC. When Linux PCI mid-layer starts enumerating, it reads the
size of BAR of RC and tries to fit it into the memory resource. First
thing is that the outbound memory is not enough to map the inbound BAR
space. This creates problem with the resource management logic and
second thing is that, it is not required to map inbound BAR space RC
bar as no one will be accessing it further.
As Jason suggested, Bridge BAR's should be 0 size unless the bridge
itself has registers. However this is not the case with XGene PCIe
controller. It may have been inherited from the legacy design.
'arch/powerpc/sysdev/ppc4xx_pci.c' has similar fixup function.
>
>> +static int xgene_pcie_setup(int nr, struct pci_sys_data *sys)
>> +{
>> + struct xgene_pcie_port *pp = sys->private_data;
>> + struct resource *io = &pp->realio;
>> +
>> + io->start = sys->domain * SZ_64K;
>> + io->end = io->start + SZ_64K;
>> + io->flags = pp->io.res.flags;
>> + io->name = "PCI IO";
>> + pci_ioremap_io(io->start, pp->io.res.start);
>> +
>> + pci_add_resource_offset(&sys->resources, io, sys->io_offset);
>> + sys->mem_offset = pp->mem.res.start - pp->mem.pci_addr;
>> + pci_add_resource_offset(&sys->resources, &pp->mem.res,
>> + sys->mem_offset);
>> + return 1;
>> +}
>
> Thanks for bringing back the I/O space handling.
>
> You don't seem to set sys->io_offset anywhere, but each of the
> ports listed in your DT starts a local bus I/O register range
> at port 0.
>
> AFAICT, you need to add (somewhere)
>
> sys->io_offset = pp->realio.start - pp->io.pci_addr;
>
> but there could be something else missing. You clearly haven't
> tested if the I/O space actually works.
That is correct :-). Could not find the card. Thanks for the patch below.
>
> If you want to try out the I/O space, I'd suggest using an Intel
> e1000 network card, which has both memory and i/o space. There
> is a patch at http://www.spinics.net/lists/linux-pci/msg27684.html
> that lets you check the I/O registers on it, or you can go
> through /dev/port from user space.
>
> I also haven't seen your patch that adds pci_ioremap_io() for
> arm64. It would be helpful to keep it in the same patch
> series, since it won't build without this patch.
I will post the arm64 pci patch along with next revision of this
driver. That will cover the 'pci_ioremap_io' as well.
>
> Arnd
^ permalink raw reply
* [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Maxime Ripard @ 2014-02-03 19:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52EFC573.2050302@linaro.org>
Hi Daniel,
(Adding DT mailing-list in CC)
On Mon, Feb 03, 2014 at 05:36:03PM +0100, Daniel Lezcano wrote:
> On 02/02/2014 02:37 PM, Maxime Ripard wrote:
> >The Allwinner A10 compatibles were following a slightly different compatible
> >patterns than the rest of the SoCs for historical reasons. Add compatibles
> >matching the other pattern to the timer driver for consistency, and keep the
> >older one for backward compatibility.
>
> Hi Maxime,
>
> is it really needed to keep the old pattern ?
We agreed during the ARM Kernel Summit to consider the DT as a stable
ABI.
While I'd be ok with removing the older ones, that also means that we
would break the boot of newer kernels with older DT, so yes, we
actually need to keep the old compatibles.
> >Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
> >---
> > Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt | 5 +++--
> > drivers/clocksource/sun4i_timer.c | 4 ++++
> > 2 files changed, 7 insertions(+), 2 deletions(-)
> >
> >diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
> >index 48aeb78..d9e35ae 100644
> >--- a/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
> >+++ b/Documentation/devicetree/bindings/timer/allwinner,sun4i-timer.txt
> >@@ -2,7 +2,8 @@ Allwinner A1X SoCs Timer Controller
> >
> > Required properties:
> >
> >-- compatible : should be "allwinner,sun4i-timer"
> >+- compatible : should be "allwinner,sun4i-a10-timer"
> >+ (Deprecated "allwinner,sun4i-timer")
> > - reg : Specifies base physical address and size of the registers.
> > - interrupts : The interrupt of the first timer
> > - clocks: phandle to the source clock (usually a 24 MHz fixed clock)
> >@@ -10,7 +11,7 @@ Required properties:
> > Example:
> >
> > timer {
> >- compatible = "allwinner,sun4i-timer";
> >+ compatible = "allwinner,sun4i-a10-timer";
> > reg = <0x01c20c00 0x400>;
> > interrupts = <22>;
> > clocks = <&osc>;
> >diff --git a/drivers/clocksource/sun4i_timer.c b/drivers/clocksource/sun4i_timer.c
> >index bf497af..de03895 100644
> >--- a/drivers/clocksource/sun4i_timer.c
> >+++ b/drivers/clocksource/sun4i_timer.c
> >@@ -196,5 +196,9 @@ static void __init sun4i_timer_init(struct device_node *node)
> > clockevents_config_and_register(&sun4i_clockevent, rate,
> > TIMER_SYNC_TICKS, 0xffffffff);
> > }
> >+CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-a10-timer",
> >+ sun4i_timer_init);
> >+
> >+/* Deprecated */
> > CLOCKSOURCE_OF_DECLARE(sun4i, "allwinner,sun4i-timer",
> > sun4i_timer_init);
> >
>
>
> --
> <http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
>
> Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
> <http://twitter.com/#!/linaroorg> Twitter |
> <http://www.linaro.org/linaro-blog/> Blog
>
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140203/63754870/attachment.sig>
^ permalink raw reply
* [PATCH 0/2] arm64: vdso fixes for coarse clocks
From: Nathan Lynch @ 2014-02-03 19:48 UTC (permalink / raw)
To: linux-arm-kernel
While working on vdso for 32-bit ARM I have referred heavily to the
arm64 implementation. In arm64 I found a couple of issues with the
handling of CLOCK_MONOTONIC_COARSE and CLOCK_REALTIME_COARSE,
which are addressed in this series.
Nathan Lynch (2):
arm64: vdso: fix coarse clock handling
arm64: vdso: update wtm fields for CLOCK_MONOTONIC_COARSE
arch/arm64/kernel/vdso.c | 4 ++--
arch/arm64/kernel/vdso/gettimeofday.S | 9 ++++++---
2 files changed, 8 insertions(+), 5 deletions(-)
--
1.8.3.1
^ permalink raw reply
* [PATCH 1/2] arm64: vdso: fix coarse clock handling
From: Nathan Lynch @ 2014-02-03 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391456932-17815-1-git-send-email-nathan_lynch@mentor.com>
When __kernel_clock_gettime is called with a CLOCK_MONOTONIC_COARSE or
CLOCK_REALTIME_COARSE clock id, it returns incorrectly to whatever the
caller has placed in x2. Fix this by saving x30/LR to x2
unconditionally.
Also: the tv_nsec field in the result is shifted by the value in x12.
In the high-precision case x12 is cs_shift from the data page, but
for coarse clocks x12 is uninitialized. Fix this by setting x12 to 0
once we know we are dealing with a coarse clock.
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
---
arch/arm64/kernel/vdso/gettimeofday.S | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/vdso/gettimeofday.S b/arch/arm64/kernel/vdso/gettimeofday.S
index f0a6d10b5211..6c37ae4a70c0 100644
--- a/arch/arm64/kernel/vdso/gettimeofday.S
+++ b/arch/arm64/kernel/vdso/gettimeofday.S
@@ -88,13 +88,13 @@ ENDPROC(__kernel_gettimeofday)
/* int __kernel_clock_gettime(clockid_t clock_id, struct timespec *tp); */
ENTRY(__kernel_clock_gettime)
.cfi_startproc
+ mov x2, x30
+ .cfi_register x30, x2
+
cmp w0, #CLOCK_REALTIME
ccmp w0, #CLOCK_MONOTONIC, #0x4, ne
b.ne 2f
- mov x2, x30
- .cfi_register x30, x2
-
/* Get kernel timespec. */
adr vdso_data, _vdso_data
1: seqcnt_acquire
@@ -118,6 +118,9 @@ ENTRY(__kernel_clock_gettime)
ccmp w0, #CLOCK_MONOTONIC_COARSE, #0x4, ne
b.ne 8f
+ /* Set shift to 0 for coarse clocks */
+ mov x12, #0
+
/* Get coarse timespec. */
adr vdso_data, _vdso_data
3: seqcnt_acquire
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/2] arm64: vdso: update wtm fields for CLOCK_MONOTONIC_COARSE
From: Nathan Lynch @ 2014-02-03 19:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1391456932-17815-1-git-send-email-nathan_lynch@mentor.com>
Update wall-to-monotonic fields in the VDSO data page
unconditionally. These are used to service CLOCK_MONOTONIC_COARSE,
which is not guarded by use_syscall.
Signed-off-by: Nathan Lynch <nathan_lynch@mentor.com>
---
arch/arm64/kernel/vdso.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/vdso.c b/arch/arm64/kernel/vdso.c
index 65d40cf6945a..a7149cae1615 100644
--- a/arch/arm64/kernel/vdso.c
+++ b/arch/arm64/kernel/vdso.c
@@ -238,6 +238,8 @@ void update_vsyscall(struct timekeeper *tk)
vdso_data->use_syscall = use_syscall;
vdso_data->xtime_coarse_sec = xtime_coarse.tv_sec;
vdso_data->xtime_coarse_nsec = xtime_coarse.tv_nsec;
+ vdso_data->wtm_clock_sec = tk->wall_to_monotonic.tv_sec;
+ vdso_data->wtm_clock_nsec = tk->wall_to_monotonic.tv_nsec;
if (!use_syscall) {
vdso_data->cs_cycle_last = tk->clock->cycle_last;
@@ -245,8 +247,6 @@ void update_vsyscall(struct timekeeper *tk)
vdso_data->xtime_clock_nsec = tk->xtime_nsec;
vdso_data->cs_mult = tk->mult;
vdso_data->cs_shift = tk->shift;
- vdso_data->wtm_clock_sec = tk->wall_to_monotonic.tv_sec;
- vdso_data->wtm_clock_nsec = tk->wall_to_monotonic.tv_nsec;
}
smp_wmb();
--
1.8.3.1
^ permalink raw reply related
* [PATCH] arm64: Add architecture support for PCI
From: Arnd Bergmann @ 2014-02-03 20:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203191837.GC4889@e106497-lin.cambridge.arm.com>
On Monday 03 February 2014 19:18:38 Liviu Dudau wrote:
> On Mon, Feb 03, 2014 at 06:58:56PM +0000, Arnd Bergmann wrote:
> > On Monday 03 February 2014 18:43:48 Liviu Dudau wrote:
> > > diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
> > > index 4cc813e..ce5bad2 100644
> > > --- a/arch/arm64/include/asm/io.h
> > > +++ b/arch/arm64/include/asm/io.h
> > > @@ -120,9 +120,13 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
> > > /*
> > > * I/O port access primitives.
> > > */
> > > +#define arch_has_dev_port() (0)
> >
> > Why not?
>
> Maybe I got it the wrong way around, but the comment in include/linux/io.h says:
>
> /*
> * Some systems do not have legacy ISA devices.
> * /dev/port is not a valid interface on these systems.
> * So for those archs, <asm/io.h> should define the following symbol.
> */
>
> So ... defining it should mean no legacy ISA devices, right?
I would read that comment as referring to systems that don't have
any I/O space. If you have PCI, you can by definition have ISA
compatible devices behind a bridge. A typical example would be
a VGA card that supports the 03c0-03df port range.
> >
> > > #define IO_SPACE_LIMIT 0xffff
> >
> > You probably want to increase this a bit, to allow multiple host bridges
> > to have their own I/O space.
>
> OK, but to what size?
2 MB was a compromise on arm32 to allow up to 32 PCI host bridges but not
take up too much virtual space. On arm64 it should be at least as big.
Could be more than that, although I don't see a reason why it should be,
unless we expect to see systems with tons of host bridges, or buses
that exceed 64KB of I/O space.
> > > +#define ioport_map(port, nr) (PCI_IOBASE + ((port) & IO_SPACE_LIMIT))
> > > +#define ioport_unmap(addr)
> >
> > inline functions?
>
> Will do, thanks!
I suppose you can actually use the generic implementation from
asm-generic/io.h, and fix it by using the definition you have
above, since it's currently broken.
> > > diff --git a/arch/arm64/include/asm/pci.h b/arch/arm64/include/asm/pci.h
> > > new file mode 100644
> > > index 0000000..dd084a3
> > > --- /dev/null
> > > +++ b/arch/arm64/include/asm/pci.h
> > > @@ -0,0 +1,35 @@
> > > +#ifndef __ASM_PCI_H
> > > +#define __ASM_PCI_H
> > > +#ifdef __KERNEL__
> > > +
> > > +#include <linux/types.h>
> > > +#include <linux/slab.h>
> > > +#include <linux/dma-mapping.h>
> > > +
> > > +#include <asm/io.h>
> > > +#include <asm-generic/pci-bridge.h>
> > > +#include <asm-generic/pci-dma-compat.h>
> > > +
> > > +#define PCIBIOS_MIN_IO 0
> > > +#define PCIBIOS_MIN_MEM 0
> >
> > PCIBIOS_MIN_IO is normally set to 0x1000, to stay out of the ISA range.
>
> :) No ISA support! (Die ISA, die!!)
If only it were that easy.
> > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c
> > > new file mode 100644
> > > index 0000000..7b652cf
> > > --- /dev/null
> > > +++ b/arch/arm64/kernel/pci.c
> > > @@ -0,0 +1,112 @@
> >
> > None of this looks really arm64 specific, nor should it be. I think
> > we should try a little harder to move this as a default implementation
> > into common code, even if we start out by having all architectures
> > override it.
>
> Agree. This is the RFC version. I didn't dare to post a patch with fixes
> for all architectures. :)
No need to change the other architectures. You can make it opt-in for
now and just put the code into a common location.
An interesting question however is what the transition plan is to
have the code shared between arm32 and arm64: We will certainly need
to share at least the dw-pcie and the generic SBSA compliant pci
implementation.
> > > +int pci_ioremap_io(unsigned int offset, phys_addr_t phys_addr)
> > > +{
> > > + BUG_ON(offset + SZ_64K - 1 > IO_SPACE_LIMIT);
> > > +
> > > + return ioremap_page_range((unsigned long)PCI_IOBASE + offset,
> > > + (unsigned long)PCI_IOBASE + offset + SZ_64K,
> > > + phys_addr,
> > > + __pgprot(PROT_DEVICE_nGnRE));
> > > +}
> >
> > Not sure if we want to treat this one as architecture specific though.
> > It certainly won't be portable to x86, but it could be shared with
> > a couple of others. We may also want to redesign the interface.
> > I've been thinking we could make this function allocate space in the
> > Linux virtual I/O space aperture, and pass two resources into it
> > (physical I/O aperture and bus I/O range), and get the actual
> > io_offset as the return value, or a negative error number.
>
> Not sure I completely follow your idea.
Something like this (coded in mail client, don't try to compile):
#define IO_SPACE_PAGES (IO_SPACE_LIMIT + 1) / PAGE_SIZE)
static DECLARE_BITMAP(pci_iospace, IO_SPACE_PAGES);
unsigned long pci_ioremap_io(const struct resource *bus, const struct resource phys)
{
unsigned long start, len, virt_start;
int error;
/* use logical address == bus address if possible */
start = bus->start / PAGE_SIZE;
if (start > IO_SPACE_LIMIT / PAGE_SIZE)
start = 0;
/*
* try finding free space for the whole size first,
* fall back to 64K if not available
*/
len = min(resource_size(bus), resource_size(phys);
start = bitmap_find_next_zero_area(pci_iospace, IO_SPACE_PAGES,
start, len / PAGE_SIZE, 0);
if (start == IO_SPACE_PAGES && len > SZ_64K)
len = SZ_64K;
start = 0;
start = bitmap_find_next_zero_area(pci_iospace, IO_SPACE_PAGES,
start, len / PAGE_SIZE, 0);
}
/* no 64K area found */
if (start == IO_SPACE_PAGES)
return -ENOMEM;
/* ioremap physical aperture to virtual aperture */
virt_start = start * PAGE_SIZE + (unsigned long)PCI_IOBASE;
error = ioremap_page_range(virt_start, virt_start + len,
phys->start, __pgprot(PROT_DEVICE_nGnRE));
if (error)
return error;
bitmap_set(start, len / PAGE_SIZE);
/* return io_offset */
return start * PAGE_SIZE - bus->start;
}
EXPORT_SYMBOL_GPL(pci_ioremap_io);
Arnd
^ permalink raw reply
* [PATCH 1/2] clocksource: sunxi: Add new compatibles
From: Rob Herring @ 2014-02-03 20:11 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140203194505.GF25625@lukather>
On Mon, Feb 3, 2014 at 1:45 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi Daniel,
>
> (Adding DT mailing-list in CC)
>
> On Mon, Feb 03, 2014 at 05:36:03PM +0100, Daniel Lezcano wrote:
>> On 02/02/2014 02:37 PM, Maxime Ripard wrote:
>> >The Allwinner A10 compatibles were following a slightly different compatible
>> >patterns than the rest of the SoCs for historical reasons. Add compatibles
>> >matching the other pattern to the timer driver for consistency, and keep the
>> >older one for backward compatibility.
>>
>> Hi Maxime,
>>
>> is it really needed to keep the old pattern ?
>
> We agreed during the ARM Kernel Summit to consider the DT as a stable
> ABI.
>
> While I'd be ok with removing the older ones, that also means that we
> would break the boot of newer kernels with older DT, so yes, we
> actually need to keep the old compatibles.
It all depends if that would really cause problems for a given
platform. So if Allwinner DT support is a moving target, then changing
is probably okay. For example, if anyone using the platform is going
to need to update their DTB to add more nodes to get various features
anyway, then breaking it is not all that important.
Rob
^ 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