* [PATCH 06/10] x86: Convert cpu_llc_id to be a per cpu variable (v3)
From: travis @ 2007-09-12 1:56 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, Andi Kleen, linux-kernel, linuxppc-dev, sparclinux,
Christoph Lameter
In-Reply-To: <20070912015644.927677070@sgi.com>
Convert cpu_llc_id from a static array sized by NR_CPUS to a
per_cpu variable. This saves sizeof(cpu_llc_id) * NR unused
cpus. Access is mostly from startup and CPU HOTPLUG functions.
Note there's an addtional change of the type of cpu_llc_id
from int to u8 for ARCH i386 to correspond with the same
type in ARCH x86_64.
Signed-off-by: Mike Travis <travis@sgi.com>
---
arch/i386/kernel/cpu/intel_cacheinfo.c | 4 ++--
arch/i386/kernel/smpboot.c | 6 +++---
arch/x86_64/kernel/smpboot.c | 6 +++---
include/asm-i386/processor.h | 6 +++++-
include/asm-x86_64/smp.h | 9 ++++-----
5 files changed, 17 insertions(+), 14 deletions(-)
--- a/arch/i386/kernel/cpu/intel_cacheinfo.c
+++ b/arch/i386/kernel/cpu/intel_cacheinfo.c
@@ -417,14 +417,14 @@
if (new_l2) {
l2 = new_l2;
#ifdef CONFIG_X86_HT
- cpu_llc_id[cpu] = l2_id;
+ per_cpu(cpu_llc_id, cpu) = l2_id;
#endif
}
if (new_l3) {
l3 = new_l3;
#ifdef CONFIG_X86_HT
- cpu_llc_id[cpu] = l3_id;
+ per_cpu(cpu_llc_id, cpu) = l3_id;
#endif
}
--- a/arch/i386/kernel/smpboot.c
+++ b/arch/i386/kernel/smpboot.c
@@ -67,7 +67,7 @@
EXPORT_SYMBOL(smp_num_siblings);
/* Last level cache ID of each logical CPU */
-int cpu_llc_id[NR_CPUS] __cpuinitdata = {[0 ... NR_CPUS-1] = BAD_APICID};
+DEFINE_PER_CPU(u8, cpu_llc_id) = BAD_APICID;
/* representing HT siblings of each logical CPU */
DEFINE_PER_CPU(cpumask_t, cpu_sibling_map);
@@ -348,8 +348,8 @@
}
for_each_cpu_mask(i, cpu_sibling_setup_map) {
- if (cpu_llc_id[cpu] != BAD_APICID &&
- cpu_llc_id[cpu] == cpu_llc_id[i]) {
+ if (per_cpu(cpu_llc_id, cpu) != BAD_APICID &&
+ per_cpu(cpu_llc_id, cpu) == per_cpu(cpu_llc_id, i)) {
cpu_set(i, c[cpu].llc_shared_map);
cpu_set(cpu, c[i].llc_shared_map);
}
--- a/arch/x86_64/kernel/smpboot.c
+++ b/arch/x86_64/kernel/smpboot.c
@@ -65,7 +65,7 @@
EXPORT_SYMBOL(smp_num_siblings);
/* Last level cache ID of each logical CPU */
-u8 cpu_llc_id[NR_CPUS] __cpuinitdata = {[0 ... NR_CPUS-1] = BAD_APICID};
+DEFINE_PER_CPU(u8, cpu_llc_id) = BAD_APICID;
/* Bitmask of currently online CPUs */
cpumask_t cpu_online_map __read_mostly;
@@ -285,8 +285,8 @@
}
for_each_cpu_mask(i, cpu_sibling_setup_map) {
- if (cpu_llc_id[cpu] != BAD_APICID &&
- cpu_llc_id[cpu] == cpu_llc_id[i]) {
+ if (per_cpu(cpu_llc_id, cpu) != BAD_APICID &&
+ per_cpu(cpu_llc_id, cpu) == per_cpu(cpu_llc_id, i)) {
cpu_set(i, c[cpu].llc_shared_map);
cpu_set(cpu, c[i].llc_shared_map);
}
--- a/include/asm-i386/processor.h
+++ b/include/asm-i386/processor.h
@@ -110,7 +110,11 @@
#define current_cpu_data boot_cpu_data
#endif
-extern int cpu_llc_id[NR_CPUS];
+/*
+ * the following now lives in the per cpu area:
+ * extern int cpu_llc_id[NR_CPUS];
+ */
+DECLARE_PER_CPU(u8, cpu_llc_id);
extern char ignore_fpu_irq;
void __init cpu_detect(struct cpuinfo_x86 *c);
--- a/include/asm-x86_64/smp.h
+++ b/include/asm-x86_64/smp.h
@@ -39,16 +39,14 @@
extern void smp_send_reschedule(int cpu);
/*
- * cpu_sibling_map and cpu_core_map now live
- * in the per cpu area
- *
+ * the following now live in the per cpu area:
* extern cpumask_t cpu_sibling_map[NR_CPUS];
* extern cpumask_t cpu_core_map[NR_CPUS];
+ * extern u8 cpu_llc_id[NR_CPUS];
*/
DECLARE_PER_CPU(cpumask_t, cpu_sibling_map);
DECLARE_PER_CPU(cpumask_t, cpu_core_map);
-
-extern u8 cpu_llc_id[NR_CPUS];
+DECLARE_PER_CPU(u8, cpu_llc_id);
#define SMP_TRAMPOLINE_BASE 0x6000
@@ -120,6 +118,7 @@
#ifdef CONFIG_SMP
#define cpu_physical_id(cpu) per_cpu(x86_cpu_to_apicid, cpu)
#else
+extern unsigned int boot_cpu_id;
#define cpu_physical_id(cpu) boot_cpu_id
#endif /* !CONFIG_SMP */
#endif
--
^ permalink raw reply
* [PATCH 10/10] sparc64: Convert cpu_sibling_map to a per_cpu data array (v3)
From: travis @ 2007-09-12 1:56 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, Andi Kleen, linux-kernel, linuxppc-dev, sparclinux,
Christoph Lameter
In-Reply-To: <20070912015644.927677070@sgi.com>
Convert cpu_sibling_map to a per_cpu cpumask_t array for the sparc64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
Note: these changes have not been built nor tested.
Signed-off-by: Mike Travis <travis@sgi.com>
---
arch/sparc64/kernel/smp.c | 17 ++++++++---------
include/asm-sparc64/smp.h | 3 ++-
include/asm-sparc64/topology.h | 2 +-
3 files changed, 11 insertions(+), 11 deletions(-)
--- a/arch/sparc64/kernel/smp.c
+++ b/arch/sparc64/kernel/smp.c
@@ -52,14 +52,13 @@
cpumask_t cpu_possible_map __read_mostly = CPU_MASK_NONE;
cpumask_t cpu_online_map __read_mostly = CPU_MASK_NONE;
-cpumask_t cpu_sibling_map[NR_CPUS] __read_mostly =
- { [0 ... NR_CPUS-1] = CPU_MASK_NONE };
+DEFINE_PER_CPU(cpumask_t, cpu_sibling_map) = CPU_MASK_NONE;
cpumask_t cpu_core_map[NR_CPUS] __read_mostly =
{ [0 ... NR_CPUS-1] = CPU_MASK_NONE };
EXPORT_SYMBOL(cpu_possible_map);
EXPORT_SYMBOL(cpu_online_map);
-EXPORT_SYMBOL(cpu_sibling_map);
+EXPORT_PER_CPU_SYMBOL(cpu_sibling_map);
EXPORT_SYMBOL(cpu_core_map);
static cpumask_t smp_commenced_mask;
@@ -1259,16 +1258,16 @@
for_each_present_cpu(i) {
unsigned int j;
- cpus_clear(cpu_sibling_map[i]);
+ cpus_clear(per_cpu(cpu_sibling_map, i));
if (cpu_data(i).proc_id == -1) {
- cpu_set(i, cpu_sibling_map[i]);
+ cpu_set(i, per_cpu(cpu_sibling_map, i));
continue;
}
for_each_present_cpu(j) {
if (cpu_data(i).proc_id ==
cpu_data(j).proc_id)
- cpu_set(j, cpu_sibling_map[i]);
+ cpu_set(j, per_cpu(cpu_sibling_map, i));
}
}
}
@@ -1340,9 +1339,9 @@
cpu_clear(cpu, cpu_core_map[i]);
cpus_clear(cpu_core_map[cpu]);
- for_each_cpu_mask(i, cpu_sibling_map[cpu])
- cpu_clear(cpu, cpu_sibling_map[i]);
- cpus_clear(cpu_sibling_map[cpu]);
+ for_each_cpu_mask(i, per_cpu(cpu_sibling_map, cpu))
+ cpu_clear(cpu, per_cpu(cpu_sibling_map, i));
+ cpus_clear(per_cpu(cpu_sibling_map, cpu));
c = &cpu_data(cpu);
--- a/include/asm-sparc64/smp.h
+++ b/include/asm-sparc64/smp.h
@@ -28,8 +28,9 @@
#include <asm/bitops.h>
#include <asm/atomic.h>
+#include <asm/percpu.h>
-extern cpumask_t cpu_sibling_map[NR_CPUS];
+DECLARE_PER_CPU(cpumask_t, cpu_sibling_map);
extern cpumask_t cpu_core_map[NR_CPUS];
extern int sparc64_multi_core;
--- a/include/asm-sparc64/topology.h
+++ b/include/asm-sparc64/topology.h
@@ -5,7 +5,7 @@
#define topology_physical_package_id(cpu) (cpu_data(cpu).proc_id)
#define topology_core_id(cpu) (cpu_data(cpu).core_id)
#define topology_core_siblings(cpu) (cpu_core_map[cpu])
-#define topology_thread_siblings(cpu) (cpu_sibling_map[cpu])
+#define topology_thread_siblings(cpu) (per_cpu(cpu_sibling_map, cpu))
#define mc_capable() (sparc64_multi_core)
#define smt_capable() (sparc64_multi_core)
#endif /* CONFIG_SMP */
--
^ permalink raw reply
* [PATCH 08/10] ia64: Convert cpu_sibling_map to a per_cpu data array (v3)
From: travis @ 2007-09-12 1:56 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, Andi Kleen, linux-kernel, linuxppc-dev, sparclinux,
Christoph Lameter
In-Reply-To: <20070912015644.927677070@sgi.com>
Convert cpu_sibling_map to a per_cpu cpumask_t array for the ia64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
There was one access to cpu_sibling_map before the per_cpu data
area was created, so that step was moved to after the per_cpu
area is setup.
Tested and verified on an A4700.
Signed-off-by: Mike Travis <travis@sgi.com>
---
arch/ia64/kernel/setup.c | 4 ----
arch/ia64/kernel/smpboot.c | 18 ++++++++++--------
arch/ia64/mm/contig.c | 6 ++++++
include/asm-ia64/smp.h | 2 +-
include/asm-ia64/topology.h | 2 +-
5 files changed, 18 insertions(+), 14 deletions(-)
--- a/arch/ia64/kernel/setup.c
+++ b/arch/ia64/kernel/setup.c
@@ -528,10 +528,6 @@
#ifdef CONFIG_SMP
cpu_physical_id(0) = hard_smp_processor_id();
-
- cpu_set(0, cpu_sibling_map[0]);
- cpu_set(0, cpu_core_map[0]);
-
check_for_logical_procs();
if (smp_num_cpucores > 1)
printk(KERN_INFO
--- a/arch/ia64/kernel/smpboot.c
+++ b/arch/ia64/kernel/smpboot.c
@@ -138,7 +138,9 @@
EXPORT_SYMBOL(cpu_possible_map);
cpumask_t cpu_core_map[NR_CPUS] __cacheline_aligned;
-cpumask_t cpu_sibling_map[NR_CPUS] __cacheline_aligned;
+DEFINE_PER_CPU_SHARED_ALIGNED(cpumask_t, cpu_sibling_map);
+EXPORT_PER_CPU_SYMBOL(cpu_sibling_map);
+
int smp_num_siblings = 1;
int smp_num_cpucores = 1;
@@ -650,12 +652,12 @@
{
int i;
- for_each_cpu_mask(i, cpu_sibling_map[cpu])
- cpu_clear(cpu, cpu_sibling_map[i]);
+ for_each_cpu_mask(i, per_cpu(cpu_sibling_map, cpu))
+ cpu_clear(cpu, per_cpu(cpu_sibling_map, i));
for_each_cpu_mask(i, cpu_core_map[cpu])
cpu_clear(cpu, cpu_core_map[i]);
- cpu_sibling_map[cpu] = cpu_core_map[cpu] = CPU_MASK_NONE;
+ per_cpu(cpu_sibling_map, cpu) = cpu_core_map[cpu] = CPU_MASK_NONE;
}
static void
@@ -666,7 +668,7 @@
if (cpu_data(cpu)->threads_per_core == 1 &&
cpu_data(cpu)->cores_per_socket == 1) {
cpu_clear(cpu, cpu_core_map[cpu]);
- cpu_clear(cpu, cpu_sibling_map[cpu]);
+ cpu_clear(cpu, per_cpu(cpu_sibling_map, cpu));
return;
}
@@ -807,8 +809,8 @@
cpu_set(i, cpu_core_map[cpu]);
cpu_set(cpu, cpu_core_map[i]);
if (cpu_data(cpu)->core_id == cpu_data(i)->core_id) {
- cpu_set(i, cpu_sibling_map[cpu]);
- cpu_set(cpu, cpu_sibling_map[i]);
+ cpu_set(i, per_cpu(cpu_sibling_map, cpu));
+ cpu_set(cpu, per_cpu(cpu_sibling_map, i));
}
}
}
@@ -839,7 +841,7 @@
if (cpu_data(cpu)->threads_per_core == 1 &&
cpu_data(cpu)->cores_per_socket == 1) {
- cpu_set(cpu, cpu_sibling_map[cpu]);
+ cpu_set(cpu, per_cpu(cpu_sibling_map, cpu));
cpu_set(cpu, cpu_core_map[cpu]);
return 0;
}
--- a/include/asm-ia64/smp.h
+++ b/include/asm-ia64/smp.h
@@ -58,7 +58,7 @@
extern cpumask_t cpu_online_map;
extern cpumask_t cpu_core_map[NR_CPUS];
-extern cpumask_t cpu_sibling_map[NR_CPUS];
+DECLARE_PER_CPU(cpumask_t, cpu_sibling_map);
extern int smp_num_siblings;
extern int smp_num_cpucores;
extern void __iomem *ipi_base_addr;
--- a/include/asm-ia64/topology.h
+++ b/include/asm-ia64/topology.h
@@ -112,7 +112,7 @@
#define topology_physical_package_id(cpu) (cpu_data(cpu)->socket_id)
#define topology_core_id(cpu) (cpu_data(cpu)->core_id)
#define topology_core_siblings(cpu) (cpu_core_map[cpu])
-#define topology_thread_siblings(cpu) (cpu_sibling_map[cpu])
+#define topology_thread_siblings(cpu) (per_cpu(cpu_sibling_map, cpu))
#define smt_capable() (smp_num_siblings > 1)
#endif
--- a/arch/ia64/mm/contig.c
+++ b/arch/ia64/mm/contig.c
@@ -212,6 +212,12 @@
cpu_data += PERCPU_PAGE_SIZE;
per_cpu(local_per_cpu_offset, cpu) = __per_cpu_offset[cpu];
}
+ /*
+ * cpu_sibling_map is now a per_cpu variable - it needs to
+ * be accessed after per_cpu_init() sets up the per_cpu area.
+ */
+ cpu_set(0, per_cpu(cpu_sibling_map, 0));
+ cpu_set(0, cpu_core_map[0]);
}
return __per_cpu_start + __per_cpu_offset[smp_processor_id()];
}
--
^ permalink raw reply
* [PATCH 05/10] x86: Convert x86_cpu_to_apicid to be a per cpu variable (v3)
From: travis @ 2007-09-12 1:56 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, Andi Kleen, linux-kernel, linuxppc-dev, sparclinux,
Christoph Lameter
In-Reply-To: <20070912015644.927677070@sgi.com>
This patch converts the x86_cpu_to_apicid array to be a per
cpu variable. This saves sizeof(apicid) * NR unused cpus.
Access is mostly from startup and CPU HOTPLUG functions.
MP_processor_info() is one of the functions that require access
to the x86_cpu_to_apicid array before the per_cpu data area is
setup. For this case, a pointer to the __initdata array is
initialized in setup_arch() and removed in smp_prepare_cpus()
after the per_cpu data area is initialized.
A second change is included to change the initial array value
of ARCH i386 from 0xff to BAD_APICID to be consistent with
ARCH x86_64.
Signed-off-by: Mike Travis <travis@sgi.com>
---
arch/i386/kernel/acpi/boot.c | 2 +-
arch/i386/kernel/smp.c | 2 +-
arch/i386/kernel/smpboot.c | 22 +++++++++++++++-------
arch/x86_64/kernel/genapic.c | 15 ++++++++++++---
arch/x86_64/kernel/genapic_flat.c | 2 +-
arch/x86_64/kernel/mpparse.c | 15 +++++++++++++--
arch/x86_64/kernel/setup.c | 5 +++++
arch/x86_64/kernel/smpboot.c | 23 ++++++++++++++++++++++-
arch/x86_64/mm/numa.c | 2 +-
include/asm-i386/smp.h | 6 ++++--
include/asm-x86_64/ipi.h | 2 +-
include/asm-x86_64/smp.h | 6 ++++--
12 files changed, 80 insertions(+), 22 deletions(-)
--- a/arch/i386/kernel/acpi/boot.c
+++ b/arch/i386/kernel/acpi/boot.c
@@ -555,7 +555,7 @@
int acpi_unmap_lsapic(int cpu)
{
- x86_cpu_to_apicid[cpu] = -1;
+ per_cpu(x86_cpu_to_apicid, cpu) = -1;
cpu_clear(cpu, cpu_present_map);
num_processors--;
--- a/arch/i386/kernel/smp.c
+++ b/arch/i386/kernel/smp.c
@@ -673,7 +673,7 @@
int i;
for (i = 0; i < NR_CPUS; i++) {
- if (x86_cpu_to_apicid[i] == apic_id)
+ if (per_cpu(x86_cpu_to_apicid, i) == apic_id)
return i;
}
return -1;
--- a/arch/i386/kernel/smpboot.c
+++ b/arch/i386/kernel/smpboot.c
@@ -92,9 +92,17 @@
struct cpuinfo_x86 cpu_data[NR_CPUS] __cacheline_aligned;
EXPORT_SYMBOL(cpu_data);
-u8 x86_cpu_to_apicid[NR_CPUS] __read_mostly =
- { [0 ... NR_CPUS-1] = 0xff };
-EXPORT_SYMBOL(x86_cpu_to_apicid);
+/*
+ * The following static array is used during kernel startup
+ * and the x86_cpu_to_apicid_ptr contains the address of the
+ * array during this time. Is it zeroed when the per_cpu
+ * data area is removed.
+ */
+u8 x86_cpu_to_apicid_init[NR_CPUS] __initdata =
+ { [0 ... NR_CPUS-1] = BAD_APICID };
+void *x86_cpu_to_apicid_ptr;
+DEFINE_PER_CPU(u8, x86_cpu_to_apicid) = BAD_APICID;
+EXPORT_PER_CPU_SYMBOL(x86_cpu_to_apicid);
u8 apicid_2_node[MAX_APICID];
@@ -804,7 +812,7 @@
irq_ctx_init(cpu);
- x86_cpu_to_apicid[cpu] = apicid;
+ per_cpu(x86_cpu_to_apicid, cpu) = apicid;
/*
* This grunge runs the startup process for
* the targeted processor.
@@ -866,7 +874,7 @@
cpu_clear(cpu, cpu_initialized); /* was set by cpu_init() */
cpucount--;
} else {
- x86_cpu_to_apicid[cpu] = apicid;
+ per_cpu(x86_cpu_to_apicid, cpu) = apicid;
cpu_set(cpu, cpu_present_map);
}
@@ -915,7 +923,7 @@
struct warm_boot_cpu_info info;
int apicid, ret;
- apicid = x86_cpu_to_apicid[cpu];
+ apicid = per_cpu(x86_cpu_to_apicid, cpu);
if (apicid == BAD_APICID) {
ret = -ENODEV;
goto exit;
@@ -965,7 +973,7 @@
boot_cpu_physical_apicid = GET_APIC_ID(apic_read(APIC_ID));
boot_cpu_logical_apicid = logical_smp_processor_id();
- x86_cpu_to_apicid[0] = boot_cpu_physical_apicid;
+ per_cpu(x86_cpu_to_apicid, 0) = boot_cpu_physical_apicid;
current_thread_info()->cpu = 0;
--- a/arch/x86_64/kernel/mpparse.c
+++ b/arch/x86_64/kernel/mpparse.c
@@ -86,7 +86,7 @@
return sum & 0xFF;
}
-static void __cpuinit MP_processor_info (struct mpc_config_processor *m)
+static void __cpuinit MP_processor_info(struct mpc_config_processor *m)
{
int cpu;
cpumask_t tmp_map;
@@ -123,7 +123,18 @@
cpu = 0;
}
bios_cpu_apicid[cpu] = m->mpc_apicid;
- x86_cpu_to_apicid[cpu] = m->mpc_apicid;
+ /*
+ * We get called early in the the start_kernel initialization
+ * process when the per_cpu data area is not yet setup, so we
+ * use a static array that is removed after the per_cpu data
+ * area is created.
+ */
+ if (x86_cpu_to_apicid_ptr) {
+ u8 *x86_cpu_to_apicid = (u8 *)x86_cpu_to_apicid_ptr;
+ x86_cpu_to_apicid[cpu] = m->mpc_apicid;
+ } else {
+ per_cpu(x86_cpu_to_apicid, cpu) = m->mpc_apicid;
+ }
cpu_set(cpu, cpu_possible_map);
cpu_set(cpu, cpu_present_map);
--- a/arch/x86_64/kernel/smpboot.c
+++ b/arch/x86_64/kernel/smpboot.c
@@ -701,7 +701,7 @@
clear_node_cpumask(cpu); /* was set by numa_add_cpu */
cpu_clear(cpu, cpu_present_map);
cpu_clear(cpu, cpu_possible_map);
- x86_cpu_to_apicid[cpu] = BAD_APICID;
+ per_cpu(x86_cpu_to_apicid, cpu) = BAD_APICID;
return -EIO;
}
@@ -848,6 +848,26 @@
}
/*
+ * Copy apicid's found by MP_processor_info from initial array to the per cpu
+ * data area. The x86_cpu_to_apicid_init array is then expendable and the
+ * x86_cpu_to_apicid_ptr is zeroed indicating that the static array is no
+ * longer available.
+ */
+void __init smp_set_apicids(void)
+{
+ int cpu;
+
+ for_each_cpu_mask(cpu, cpu_possible_map) {
+ if (per_cpu_offset(cpu))
+ per_cpu(x86_cpu_to_apicid, cpu) =
+ x86_cpu_to_apicid_init[cpu];
+ }
+
+ /* indicate the static array will be going away soon */
+ x86_cpu_to_apicid_ptr = NULL;
+}
+
+/*
* Prepare for SMP bootup. The MP table or ACPI has been read
* earlier. Just do some sanity checking here and enable APIC mode.
*/
@@ -856,6 +876,7 @@
nmi_watchdog_default();
current_cpu_data = boot_cpu_data;
current_thread_info()->cpu = 0; /* needed? */
+ smp_set_apicids();
set_cpu_sibling_map(0);
if (smp_sanity_check(max_cpus) < 0) {
--- a/arch/x86_64/mm/numa.c
+++ b/arch/x86_64/mm/numa.c
@@ -612,7 +612,7 @@
{
int i;
for (i = 0; i < NR_CPUS; i++) {
- u8 apicid = x86_cpu_to_apicid[i];
+ u8 apicid = x86_cpu_to_apicid_init[i];
if (apicid == BAD_APICID)
continue;
if (apicid_to_node[apicid] == NUMA_NO_NODE)
--- a/include/asm-i386/smp.h
+++ b/include/asm-i386/smp.h
@@ -39,9 +39,11 @@
extern void unlock_ipi_call_lock(void);
#define MAX_APICID 256
-extern u8 x86_cpu_to_apicid[];
+extern u8 __initdata x86_cpu_to_apicid_init[];
+extern void *x86_cpu_to_apicid_ptr;
+DECLARE_PER_CPU(u8, x86_cpu_to_apicid);
-#define cpu_physical_id(cpu) x86_cpu_to_apicid[cpu]
+#define cpu_physical_id(cpu) per_cpu(x86_cpu_to_apicid, cpu)
extern void set_cpu_sibling_map(int cpu);
--- a/include/asm-x86_64/ipi.h
+++ b/include/asm-x86_64/ipi.h
@@ -119,7 +119,7 @@
*/
local_irq_save(flags);
for_each_cpu_mask(query_cpu, mask) {
- __send_IPI_dest_field(x86_cpu_to_apicid[query_cpu],
+ __send_IPI_dest_field(per_cpu(x86_cpu_to_apicid, query_cpu),
vector, APIC_DEST_PHYSICAL);
}
local_irq_restore(flags);
--- a/include/asm-x86_64/smp.h
+++ b/include/asm-x86_64/smp.h
@@ -85,7 +85,9 @@
* Some lowlevel functions might want to know about
* the real APIC ID <-> CPU # mapping.
*/
-extern u8 x86_cpu_to_apicid[NR_CPUS]; /* physical ID */
+extern u8 __initdata x86_cpu_to_apicid_init[];
+extern void *x86_cpu_to_apicid_ptr;
+DECLARE_PER_CPU(u8, x86_cpu_to_apicid); /* physical ID */
extern u8 bios_cpu_apicid[];
static inline int cpu_present_to_apicid(int mps_cpu)
@@ -116,7 +118,7 @@
}
#ifdef CONFIG_SMP
-#define cpu_physical_id(cpu) x86_cpu_to_apicid[cpu]
+#define cpu_physical_id(cpu) per_cpu(x86_cpu_to_apicid, cpu)
#else
#define cpu_physical_id(cpu) boot_cpu_id
#endif /* !CONFIG_SMP */
--- a/arch/x86_64/kernel/genapic_flat.c
+++ b/arch/x86_64/kernel/genapic_flat.c
@@ -172,7 +172,7 @@
*/
cpu = first_cpu(cpumask);
if ((unsigned)cpu < NR_CPUS)
- return x86_cpu_to_apicid[cpu];
+ return per_cpu(x86_cpu_to_apicid, cpu);
else
return BAD_APICID;
}
--- a/arch/x86_64/kernel/genapic.c
+++ b/arch/x86_64/kernel/genapic.c
@@ -24,10 +24,19 @@
#include <acpi/acpi_bus.h>
#endif
-/* which logical CPU number maps to which CPU (physical APIC ID) */
-u8 x86_cpu_to_apicid[NR_CPUS] __read_mostly
+/*
+ * which logical CPU number maps to which CPU (physical APIC ID)
+ *
+ * The following static array is used during kernel startup
+ * and the x86_cpu_to_apicid_ptr contains the address of the
+ * array during this time. Is it zeroed when the per_cpu
+ * data area is removed.
+ */
+u8 x86_cpu_to_apicid_init[NR_CPUS] __initdata
= { [0 ... NR_CPUS-1] = BAD_APICID };
-EXPORT_SYMBOL(x86_cpu_to_apicid);
+void *x86_cpu_to_apicid_ptr;
+DEFINE_PER_CPU(u8, x86_cpu_to_apicid) = BAD_APICID;
+EXPORT_PER_CPU_SYMBOL(x86_cpu_to_apicid);
struct genapic __read_mostly *genapic = &apic_flat;
--- a/arch/x86_64/kernel/setup.c
+++ b/arch/x86_64/kernel/setup.c
@@ -276,6 +276,11 @@
dmi_scan_machine();
+#ifdef CONFIG_SMP
+ /* setup to use the static apicid table during kernel startup */
+ x86_cpu_to_apicid_ptr = (void *)&x86_cpu_to_apicid_init;
+#endif
+
#ifdef CONFIG_ACPI
/*
* Initialize the ACPI boot-time table parser (gets the RSDP and SDT).
--
^ permalink raw reply
* [PATCH 09/10] ppc64: Convert cpu_sibling_map to a per_cpu data array (v3)
From: travis @ 2007-09-12 1:56 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, Andi Kleen, linux-kernel, linuxppc-dev, sparclinux,
Christoph Lameter
In-Reply-To: <20070912015644.927677070@sgi.com>
Convert cpu_sibling_map to a per_cpu cpumask_t array for the ppc64
architecture. This fixes build errors in block/blktrace.c and
kernel/sched.c when CONFIG_SCHED_SMT is defined.
Note: these changes have not been built nor tested.
Signed-off-by: Mike Travis <travis@sgi.com>
---
arch/powerpc/kernel/setup-common.c | 4 ++--
arch/powerpc/kernel/smp.c | 4 ++--
arch/powerpc/platforms/cell/cbe_cpufreq.c | 2 +-
include/asm-powerpc/smp.h | 4 +++-
include/asm-powerpc/topology.h | 2 +-
5 files changed, 9 insertions(+), 7 deletions(-)
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -415,9 +415,9 @@
* Do the sibling map; assume only two threads per processor.
*/
for_each_possible_cpu(cpu) {
- cpu_set(cpu, cpu_sibling_map[cpu]);
+ cpu_set(cpu, cpu_sibling_map(cpu));
if (cpu_has_feature(CPU_FTR_SMT))
- cpu_set(cpu ^ 0x1, cpu_sibling_map[cpu]);
+ cpu_set(cpu ^ 0x1, cpu_sibling_map(cpu));
}
vdso_data->processorCount = num_present_cpus();
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -61,11 +61,11 @@
cpumask_t cpu_possible_map = CPU_MASK_NONE;
cpumask_t cpu_online_map = CPU_MASK_NONE;
-cpumask_t cpu_sibling_map[NR_CPUS] = { [0 ... NR_CPUS-1] = CPU_MASK_NONE };
+DEFINE_PER_CPU(cpumask_t, cpu_sibling_map) = CPU_MASK_NONE;
EXPORT_SYMBOL(cpu_online_map);
EXPORT_SYMBOL(cpu_possible_map);
-EXPORT_SYMBOL(cpu_sibling_map);
+EXPORT_PER_CPU_SYMBOL(cpu_sibling_map);
/* SMP operations for this machine */
struct smp_ops_t *smp_ops;
--- a/arch/powerpc/platforms/cell/cbe_cpufreq.c
+++ b/arch/powerpc/platforms/cell/cbe_cpufreq.c
@@ -119,7 +119,7 @@
policy->cur = cbe_freqs[cur_pmode].frequency;
#ifdef CONFIG_SMP
- policy->cpus = cpu_sibling_map[policy->cpu];
+ policy->cpus = cpu_sibling_map(policy->cpu);
#endif
cpufreq_frequency_table_get_attr(cbe_freqs, policy->cpu);
--- a/include/asm-powerpc/smp.h
+++ b/include/asm-powerpc/smp.h
@@ -25,6 +25,7 @@
#ifdef CONFIG_PPC64
#include <asm/paca.h>
+#include <asm/percpu.h>
#endif
extern int boot_cpuid;
@@ -58,7 +59,8 @@
(smp_hw_index[(cpu)] = (phys))
#endif
-extern cpumask_t cpu_sibling_map[NR_CPUS];
+DECLARE_PER_CPU(cpumask_t, cpu_sibling_map);
+#define cpu_sibling_map(cpu) per_cpu(cpu_sibling_map, cpu)
/* Since OpenPIC has only 4 IPIs, we use slightly different message numbers.
*
--- a/include/asm-powerpc/topology.h
+++ b/include/asm-powerpc/topology.h
@@ -108,7 +108,7 @@
#ifdef CONFIG_PPC64
#include <asm/smp.h>
-#define topology_thread_siblings(cpu) (cpu_sibling_map[cpu])
+#define topology_thread_siblings(cpu) (cpu_sibling_map(cpu))
#endif
#endif
--
^ permalink raw reply
* [PATCH 07/10] x86: acpi-use-cpu_physical_id (v3)
From: travis @ 2007-09-12 1:56 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-mm, Andi Kleen, linux-kernel, linuxppc-dev, sparclinux,
Christoph Lameter
In-Reply-To: <20070912015644.927677070@sgi.com>
This is from an earlier message from Christoph Lameter:
processor_core.c currently tries to determine the apicid by special casing
for IA64 and x86. The desired information is readily available via
cpu_physical_id()
on IA64, i386 and x86_64.
Signed-off-by: Christoph Lameter <clameter@sgi.com>
Additionally, boot_cpu_id needed to be exported to fix compile errors in
dma code when !CONFIG_SMP.
Signed-off-by: Mike Travis <travis@sgi.com>
---
arch/x86_64/kernel/mpparse.c | 2 ++
drivers/acpi/processor_core.c | 8 +-------
2 files changed, 3 insertions(+), 7 deletions(-)
--- a/drivers/acpi/processor_core.c
+++ b/drivers/acpi/processor_core.c
@@ -419,12 +419,6 @@
return 0;
}
-#ifdef CONFIG_IA64
-#define arch_cpu_to_apicid ia64_cpu_to_sapicid
-#else
-#define arch_cpu_to_apicid x86_cpu_to_apicid
-#endif
-
static int map_madt_entry(u32 acpi_id)
{
unsigned long madt_end, entry;
@@ -498,7 +492,7 @@
return apic_id;
for (i = 0; i < NR_CPUS; ++i) {
- if (arch_cpu_to_apicid[i] == apic_id)
+ if (cpu_physical_id(i) == apic_id)
return i;
}
return -1;
--- a/arch/x86_64/kernel/mpparse.c
+++ b/arch/x86_64/kernel/mpparse.c
@@ -57,6 +57,8 @@
/* Processor that is doing the boot up */
unsigned int boot_cpu_id = -1U;
+EXPORT_SYMBOL(boot_cpu_id);
+
/* Internal processor count */
unsigned int num_processors __cpuinitdata = 0;
--
^ permalink raw reply
* Re: FDT for Microblaze and PPC405
From: David Gibson @ 2007-09-12 2:03 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Michal Simek
In-Reply-To: <fa686aa40709111009j64925edag511078d88ff904c@mail.gmail.com>
On Tue, Sep 11, 2007 at 11:09:07AM -0600, Grant Likely wrote:
> On 9/11/07, Michal Simek <Monstr@seznam.cz> wrote:
> > For example emaclite driver needs information about turning on/off ping pong buffer...
> >
> > I would like to make this properly.
>
> FDT design is just as much art as it is science. It takes taste and
> judgement to desgin a nice set of bindings. Your best option is to
> draft something and post it to the linuxppc-embedded mailing list for
> review.
Yes, this is the preferred procedure, for now.
> > And second question is on early console logs and timers setting. I read about aliases in FDT. I think that aliases can cover this setting.
> > For example my design contain 4 serial line and I would like to know which serial line is set on early console.
>
> You use the chosen node for this. In the chosen node, you add a
> property called "linux,stdout-path" which holds the path to your
> console. You can look at examples under arch/powerpc/boot/dts/*
Yes. Currently we don't use /aliases in the flat device tree. This
is possibly a mistake, and something I'm thinking about changing.
But, for now, linux,stdout-path in /chosen is the way to do this.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* [PATCH] powerpc: add new required termio functions
From: Michael Neuling @ 2007-09-12 2:04 UTC (permalink / raw)
To: Linus Torvalds, akpm, paulus, Alan Cox, David S. Miller
Cc: linuxppc-dev, linux-kernel
The "tty: termios locking functions break with new termios type" patch
(f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
This adds the required API to asm-powerpc.
Signed-off-by: Michael Neuling <mikey@neuling.org>
--
This needs to go up for 2.6.23.
Should we really put these definitions in asm-generic/termios.h as I'm
guessing other architectures are broken too?
coopers@include/ % git grep kernel_termios_to_user_termios_1
asm-arm/termios.h:#define kernel_termios_to_user_termios_1(u, k)
asm-cris/termios.h:#define kernel_termios_to_user_termios_1(u, k)
asm-h8300/termios.h:#define kernel_termios_to_user_termios_1(u, k)
asm-i386/termios.h:#define kernel_termios_to_user_termios_1(u, k)
asm-ia64/termios.h:#define kernel_termios_to_user_termios_1(u, k)
asm-m32r/termios.h:#define kernel_termios_to_user_termios_1(u, k)
asm-m68k/termios.h:#define kernel_termios_to_user_termios_1(u, k)
asm-mips/termios.h:#define kernel_termios_to_user_termios_1(u, k)
asm-v850/termios.h:#define kernel_termios_to_user_termios_1(u, k)
asm-x86_64/termios.h:#define kernel_termios_to_user_termios_1(u, k)
include/asm-powerpc/termios.h | 3 +++
1 file changed, 3 insertions(+)
Index: linux-2.6-ozlabs/include/asm-powerpc/termios.h
===================================================================
--- linux-2.6-ozlabs.orig/include/asm-powerpc/termios.h
+++ linux-2.6-ozlabs/include/asm-powerpc/termios.h
@@ -80,6 +80,9 @@ struct termio {
#include <asm-generic/termios.h>
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u, sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k, sizeof(struct termios))
+
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_TERMIOS_H */
^ permalink raw reply
* Re: SYSFS: need a noncaching read
From: David Gibson @ 2007-09-12 2:05 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev, linux-kernel, Detlev Zundel
In-Reply-To: <1189503798.6674.46.camel@Zeus.EmbLux>
On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> Hello,
>
> I have developed a device driver and use the sysFS to export some
> registers to userspace. I opened the sysFS File for one register and did
> some reads from this File, but I alwas becoming the same value from the
> register, whats not OK, because they are changing. So I found out that
> the sysFS caches the reads ... :-(
>
> Is there a way to retrigger the reads (in that way, that the sysFS
> rereads the values from the driver), without closing and opening the
> sysFS Files? Or must I better use the ioctl () Driver-interface for
> exporting these registers?
>
> I am asking this, because I must read every 10 ms 2 registers, so
> doing a open/read/close for reading one registers is a little bit too
> much overhead.
>
> I made a sysFS seek function, which retriggers the read, and that works
> fine, but I have again 2 syscalls, whats also is not optimal.
>
> Or can we make a open () with a (new?)Flag, that informs the sysFS to
> always reread the values from the underlying driver?
>
> Or a new flag in the "struct attribute_group" in include/linux/sysfs.h,
> which let the sysfs rereading the values?
This sounds more like sysfs is really not the right interface for
polling your registers. You would probably be better off having your
driver export a character device from which the register values could
be read.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Linus Torvalds @ 2007-09-12 2:17 UTC (permalink / raw)
To: Michael Neuling
Cc: linux-kernel, linuxppc-dev, paulus, Alan Cox, akpm,
David S. Miller
In-Reply-To: <8018.1189562679@neuling.org>
On Wed, 12 Sep 2007, Michael Neuling wrote:
>
> The "tty: termios locking functions break with new termios type" patch
> (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
Really?
It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
on the architecture having a define for TCGETS2, and I think they match
up. I see:
[torvalds@woody linux]$ git grep -l kernel_termios_to_user_termios_1 include | wc -l
10
[torvalds@woody linux]$ git grep -l TCGETS2 include | wc -l
10
and in neither case is ppc in that list of architecures.
So maybe you just read the patch without actually testing whether it
actually broke powerpc?
Or is something subtler going on?
Linus
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Geoff Levand @ 2007-09-12 2:19 UTC (permalink / raw)
To: Michael Neuling
Cc: linux-kernel, linuxppc-dev, paulus, Alan Cox, akpm,
Linus Torvalds, David S. Miller
In-Reply-To: <8018.1189562679@neuling.org>
Michael Neuling wrote:
> The "tty: termios locking functions break with new termios type" patch
> (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> This adds the required API to asm-powerpc.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> --
> This needs to go up for 2.6.23.
>
> Should we really put these definitions in asm-generic/termios.h as I'm
> guessing other architectures are broken too?
I think it would be better to do so, as that is where we pickup the defs for
the original kernel_termios_to_user_termios and user_termios_to_kernel_termios.
-Geoff
^ permalink raw reply
* Re: [PATCH] powerpc: add new required termio functions
From: Tony Breeds @ 2007-09-12 2:33 UTC (permalink / raw)
To: Linus Torvalds
Cc: Michael Neuling, linux-kernel, linuxppc-dev, paulus, Alan Cox,
akpm, David S. Miller
In-Reply-To: <alpine.LFD.0.999.0709111915350.16478@woody.linux-foundation.org>
On Tue, Sep 11, 2007 at 07:17:42PM -0700, Linus Torvalds wrote:
> Really?
>
> It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
> on the architecture having a define for TCGETS2, and I think they match
> up. I see:
>
> [torvalds@woody linux]$ git grep -l kernel_termios_to_user_termios_1 include | wc -l
> 10
> [torvalds@woody linux]$ git grep -l TCGETS2 include | wc -l
> 10
>
> and in neither case is ppc in that list of architecures.
>
> So maybe you just read the patch without actually testing whether it
> actually broke powerpc?
>
> Or is something subtler going on?
As far as I can see TIOCSLCKTRMIOS and TIOCGLCKTRMIOS aren't protected
by TCGETS2 guards. Do they need to be ... Perhaps
From: Tony Breeds <tony@bakeyournoodle.com>
Add Guards around TIOCSLCKTRMIOS and TIOCGLCKTRMIOS.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
drivers/char/tty_ioctl.c | 14 ++++++++++++++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/char/tty_ioctl.c b/drivers/char/tty_ioctl.c
index 4a8969c..3ee73cf 100644
--- a/drivers/char/tty_ioctl.c
+++ b/drivers/char/tty_ioctl.c
@@ -795,6 +795,19 @@ int n_tty_ioctl(struct tty_struct * tty, struct file * file,
if (L_ICANON(tty))
retval = inq_canon(tty);
return put_user(retval, (unsigned int __user *) arg);
+#ifndef TCGETS2
+ case TIOCGLCKTRMIOS:
+ if (kernel_termios_to_user_termios((struct termios __user *)arg, real_tty->termios_locked))
+ return -EFAULT;
+ return 0;
+
+ case TIOCSLCKTRMIOS:
+ if (!capable(CAP_SYS_ADMIN))
+ return -EPERM;
+ if (user_termios_to_kernel_termios(real_tty->termios_locked, (struct termios __user *) arg))
+ return -EFAULT;
+ return 0;
+#else
case TIOCGLCKTRMIOS:
if (kernel_termios_to_user_termios_1((struct termios __user *)arg, real_tty->termios_locked))
return -EFAULT;
@@ -806,6 +819,7 @@ int n_tty_ioctl(struct tty_struct * tty, struct file * file,
if (user_termios_to_kernel_termios_1(real_tty->termios_locked, (struct termios __user *) arg))
return -EFAULT;
return 0;
+#endif
case TIOCPKT:
{
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply related
* Re: [PATCH] powerpc: add new required termio functions
From: Michael Neuling @ 2007-09-12 2:34 UTC (permalink / raw)
To: Linus Torvalds
Cc: linux-kernel, linuxppc-dev, paulus, Alan Cox, akpm,
David S. Miller
In-Reply-To: <alpine.LFD.0.999.0709111915350.16478@woody.linux-foundation.org>
> On Wed, 12 Sep 2007, Michael Neuling wrote:
> >
> > The "tty: termios locking functions break with new termios type" patch
> > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
>
> Really?
>
> It shouldn't. The use of kernel_termios_to_user_termios_1() is conditional
> on the architecture having a define for TCGETS2, and I think they match
> up. I see:
>
> [torvalds@woody linux]$ git grep -l kernel_termios_to_user_termios_1 in
clude | wc -l
> 10
> [torvalds@woody linux]$ git grep -l TCGETS2 include | wc -l
> 10
>
> and in neither case is ppc in that list of architecures.
>
> So maybe you just read the patch without actually testing whether it
> actually broke powerpc?
Not, I actually compiled it.
> Or is something subtler going on?
Looks like those new calls are not protected by the TCGETS2 define.
Adding those ifdefs seems like the correct fix.
Mikey
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: David Gibson @ 2007-09-12 3:00 UTC (permalink / raw)
To: Kumar Gala; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <C1272D92-42A0-43E4-9AE0-12161178AAA2@kernel.crashing.org>
On Tue, Sep 11, 2007 at 12:59:22PM -0500, Kumar Gala wrote:
>
> On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
>
> > Olof Johansson wrote:
> >> On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
> >>> Olof Johansson wrote:
> >>>> On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
> >>>>> well the ifdefs are orthogonal. We don't have a way of knowing
> >>>>> primary from the device tree today.
> >>>> How about something like "fsl,primary-phb" in the bus device
> >>>> node? I don't
> >>>> know, maybe it's already been discussed and turned down for some
> >>>> reason.
> >>> It's more of a Linux issue than anything to do with the hardware.
> >>
> >> That doesn't stop firmware from telling linux which bus is the
> >> primary
> >> one on the system to help out.
> >
> > The entire notion of a "primary" PCI bus is due to a Linux flaw.
> >
> > If we did put it in the device tree, it should be something like
> > "linux,primary-phb". But since Linux can tell from the node's
> > children,
> > there doesn't seem to be much point.
>
> Once someone rights code to do this I'm happy to change over. I took
> this model of explicitly knowing the primary PHB from the pmac code.
In the meantime, couldn't the code still be merged, using an explicit
test of the root node's 'compatible' or 'model' properties to decide
on the right primary bus.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: David Gibson @ 2007-09-12 3:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0709111436290.14121@blarg.am.freescale.net>
On Tue, Sep 11, 2007 at 02:37:56PM -0500, Kumar Gala wrote:
> Added basic board port for MPC8572 DS reference platform that is
> similiar to the MPC8544/33 DS reference platform in uniprocessor mode.
>
> ---
>
> Rev 3 -- updates to the device tree based on discussion on how we want
> to handle memory busses going forward.
[snip]
> + mdio@24520 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "mdio";
I don't think we actually have an mdio device_type binding defined.
> + compatible = "gianfar";
This needs to be more specific. And it certainly shouldn't be the
same compatible string as the ethernet MACs have.
> + reg = <24520 20>;
> + phy0: ethernet-phy@0 {
> + interrupt-parent = <&mpic>;
> + interrupts = <a 1>;
> + reg = <0>;
> + device_type = "ethernet-phy";
Do we actually have an ethernet-phy device_type binding? If not, we
should kill this. 'compatible' properties for phys would probably be
a good idea, though (giving the actual phy model).
> + };
> + phy1: ethernet-phy@1 {
> + interrupt-parent = <&mpic>;
> + interrupts = <a 1>;
> + reg = <1>;
> + device_type = "ethernet-phy";
> + };
> + phy2: ethernet-phy@2 {
> + interrupt-parent = <&mpic>;
> + interrupts = <a 1>;
> + reg = <2>;
> + device_type = "ethernet-phy";
> + };
> + phy3: ethernet-phy@3 {
> + interrupt-parent = <&mpic>;
> + interrupts = <a 1>;
> + reg = <3>;
> + device_type = "ethernet-phy";
> + };
> + };
> +
> + ethernet@24000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <24000 1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <1d 2 1e 2 22 2>;
> + interrupt-parent = <&mpic>;
> + phy-handle = <&phy0>;
> + phy-connection-type = "rgmii-id";
> + };
> +
> + ethernet@25000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <25000 1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <23 2 24 2 28 2>;
> + interrupt-parent = <&mpic>;
> + phy-handle = <&phy1>;
> + phy-connection-type = "rgmii-id";
> + };
> +
> + ethernet@26000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <26000 1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <1f 2 20 2 21 2>;
> + interrupt-parent = <&mpic>;
> + phy-handle = <&phy2>;
> + phy-connection-type = "rgmii-id";
> + };
> +
> + ethernet@27000 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + device_type = "network";
> + model = "eTSEC";
> + compatible = "gianfar";
> + reg = <27000 1000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <25 2 26 2 27 2>;
> + interrupt-parent = <&mpic>;
> + phy-handle = <&phy3>;
> + phy-connection-type = "rgmii-id";
> + };
> +
> + serial@4500 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4500 100>;
> + clock-frequency = <0>;
> + interrupts = <2a 2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + serial@4600 {
> + device_type = "serial";
> + compatible = "ns16550";
> + reg = <4600 100>;
> + clock-frequency = <0>;
> + interrupts = <2a 2>;
> + interrupt-parent = <&mpic>;
> + };
> +
> + global-utilities@e0000 { //global utilities block
> + compatible = "fsl,mpc8548-guts";
Hrm... this should have "fsp,mpc8572-guts" in addition to the older
model with which it is compatible.
> + reg = <e0000 1000>;
> + fsl,has-rstcr;
> + };
> +
> + mpic: pic@40000 {
> + clock-frequency = <0>;
> + interrupt-controller;
> + #address-cells = <0>;
> + #interrupt-cells = <2>;
> + reg = <40000 40000>;
> + compatible = "chrp,open-pic";
> + device_type = "open-pic";
> + big-endian;
> + };
> + };
> +
> + pcie@ffe08000 {
> + compatible = "fsl,mpc8548-pcie";
And again, "fsl,mpc8572-pcie", "fsl,mpc8548-pcie".
> + device_type = "pci";
> + #interrupt-cells = <1>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + reg = <ffe08000 1000>;
> + bus-range = <0 ff>;
> + ranges = <02000000 0 80000000 80000000 0 20000000
> + 01000000 0 00000000 ffc00000 0 00010000>;
> + clock-frequency = <1fca055>;
> + interrupt-parent = <&mpic>;
> + interrupts = <18 2>;
> + interrupt-map-mask = <fb00 0 0 0>;
> + interrupt-map = <
> + /* IDSEL 0x11 - PCI slot 1 */
> + 8800 0 0 1 &mpic 2 1
> + 8800 0 0 2 &mpic 3 1
> + 8800 0 0 3 &mpic 4 1
> + 8800 0 0 4 &mpic 1 1
> +
> + /* IDSEL 0x12 - PCI slot 2 */
> + 9000 0 0 1 &mpic 3 1
> + 9000 0 0 2 &mpic 4 1
> + 9000 0 0 3 &mpic 1 1
> + 9000 0 0 4 &mpic 2 1
> +
> + // IDSEL 0x1c USB
> + e000 0 0 0 &i8259 c 2
> + e100 0 0 0 &i8259 9 2
> + e200 0 0 0 &i8259 a 2
> + e300 0 0 0 &i8259 b 2
> +
> + // IDSEL 0x1d Audio
> + e800 0 0 0 &i8259 6 2
> +
> + // IDSEL 0x1e Legacy
> + f000 0 0 0 &i8259 7 2
> + f100 0 0 0 &i8259 7 2
> +
> + // IDSEL 0x1f IDE/SATA
> + f800 0 0 0 &i8259 e 2
> + f900 0 0 0 &i8259 5 2
> +
> + >;
> + uli1575@0 {
> + reg = <0 0 0 0 0>;
This looks kind of bogus...
> + #size-cells = <2>;
> + #address-cells = <3>;
> + ranges = <02000000 0 80000000
> + 02000000 0 80000000
> + 0 20000000
> + 01000000 0 00000000
> + 01000000 0 00000000
> + 0 00100000>;
> +
> + pci_bridge@0 {
Ok.. why is pci_bridge nested within uli1575 - with the matching reg
and ranges, it looks like they ought to be one device. Also if this
is a PCI<->PCI bridge, I believe it shold have device_type = "pci".
> + reg = <0 0 0 0 0>;
> + #size-cells = <2>;
> + #address-cells = <3>;
> + ranges = <02000000 0 80000000
> + 02000000 0 80000000
> + 0 20000000
> + 01000000 0 00000000
> + 01000000 0 00000000
> + 0 00100000>;
> +
> + isa@1e {
> + device_type = "isa";
> + #interrupt-cells = <2>;
> + #size-cells = <1>;
> + #address-cells = <2>;
> + reg = <f000 0 0 0 0>;
> + ranges = <1 0 01000000 0 0
> + 00001000>;
> + interrupt-parent = <&i8259>;
> +
> + i8259: interrupt-controller@20 {
> + reg = <1 20 2
> + 1 a0 2
> + 1 4d0 2>;
> + clock-frequency = <0>;
Hrm.. what is clock-frequency for on an i8259? I see that other 8259
descriptions have this as well, so it's not a problem with this patch
specifically.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: SYSFS: need a noncaching read
From: Michael Ellerman @ 2007-09-12 3:18 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, Heiko Schocher, linux-kernel, Detlev Zundel
In-Reply-To: <20070912020526.GD16001@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 1927 bytes --]
On Wed, 2007-09-12 at 12:05 +1000, David Gibson wrote:
> On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > Hello,
> >
> > I have developed a device driver and use the sysFS to export some
> > registers to userspace. I opened the sysFS File for one register and did
> > some reads from this File, but I alwas becoming the same value from the
> > register, whats not OK, because they are changing. So I found out that
> > the sysFS caches the reads ... :-(
> >
> > Is there a way to retrigger the reads (in that way, that the sysFS
> > rereads the values from the driver), without closing and opening the
> > sysFS Files? Or must I better use the ioctl () Driver-interface for
> > exporting these registers?
> >
> > I am asking this, because I must read every 10 ms 2 registers, so
> > doing a open/read/close for reading one registers is a little bit too
> > much overhead.
> >
> > I made a sysFS seek function, which retriggers the read, and that works
> > fine, but I have again 2 syscalls, whats also is not optimal.
> >
> > Or can we make a open () with a (new?)Flag, that informs the sysFS to
> > always reread the values from the underlying driver?
> >
> > Or a new flag in the "struct attribute_group" in include/linux/sysfs.h,
> > which let the sysfs rereading the values?
>
> This sounds more like sysfs is really not the right interface for
> polling your registers. You would probably be better off having your
> driver export a character device from which the register values could
> be read.
I thought relay(fs) was the trendy way to do this these days?
Documentation/filesystems/relay.txt
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-12 3:35 UTC (permalink / raw)
To: David Gibson; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <20070912030005.GA20218@localhost.localdomain>
On Sep 11, 2007, at 10:00 PM, David Gibson wrote:
> On Tue, Sep 11, 2007 at 12:59:22PM -0500, Kumar Gala wrote:
>>
>> On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
>>
>>> Olof Johansson wrote:
>>>> On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
>>>>> Olof Johansson wrote:
>>>>>> On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
>>>>>>> well the ifdefs are orthogonal. We don't have a way of knowing
>>>>>>> primary from the device tree today.
>>>>>> How about something like "fsl,primary-phb" in the bus device
>>>>>> node? I don't
>>>>>> know, maybe it's already been discussed and turned down for some
>>>>>> reason.
>>>>> It's more of a Linux issue than anything to do with the hardware.
>>>>
>>>> That doesn't stop firmware from telling linux which bus is the
>>>> primary
>>>> one on the system to help out.
>>>
>>> The entire notion of a "primary" PCI bus is due to a Linux flaw.
>>>
>>> If we did put it in the device tree, it should be something like
>>> "linux,primary-phb". But since Linux can tell from the node's
>>> children,
>>> there doesn't seem to be much point.
>>
>> Once someone rights code to do this I'm happy to change over. I took
>> this model of explicitly knowing the primary PHB from the pmac code.
>
> In the meantime, couldn't the code still be merged, using an explicit
> test of the root node's 'compatible' or 'model' properties to decide
> on the right primary bus.
I will be, I'm not going to wait on having some device tree spec for
this. The board code can handle it until we come to some agreement
on how to do this. I'm in agreement with Scott in that code should
be added to scan or allow explicit determination. Adding a 'prop' to
the device tree just for linux seems a bit silly.
- k
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Kumar Gala @ 2007-09-12 3:33 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev
In-Reply-To: <20070912031132.GC20218@localhost.localdomain>
On Sep 11, 2007, at 10:11 PM, David Gibson wrote:
> On Tue, Sep 11, 2007 at 02:37:56PM -0500, Kumar Gala wrote:
>> Added basic board port for MPC8572 DS reference platform that is
>> similiar to the MPC8544/33 DS reference platform in uniprocessor
>> mode.
>>
>> ---
>>
>> Rev 3 -- updates to the device tree based on discussion on how we
>> want
>> to handle memory busses going forward.
>
> [snip]
>> + mdio@24520 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + device_type = "mdio";
>
> I don't think we actually have an mdio device_type binding defined.
We've had this on 83xx/85xx/86xx device trees for a far amount of
time now. Look at section 2a in booting-without-of.txt
>
>
>> + compatible = "gianfar";
>
> This needs to be more specific. And it certainly shouldn't be the
> same compatible string as the ethernet MACs have.
Why not its the same controller? Again, we've been doing this for
some period of time already.
>
>> + reg = <24520 20>;
>> + phy0: ethernet-phy@0 {
>> + interrupt-parent = <&mpic>;
>> + interrupts = <a 1>;
>> + reg = <0>;
>> + device_type = "ethernet-phy";
>
> Do we actually have an ethernet-phy device_type binding? If not, we
> should kill this. 'compatible' properties for phys would probably be
> a good idea, though (giving the actual phy model).
Look section 2c in booting-without-of.txt
>> + };
>> + phy1: ethernet-phy@1 {
>> + interrupt-parent = <&mpic>;
>> + interrupts = <a 1>;
>> + reg = <1>;
>> + device_type = "ethernet-phy";
>> + };
>> + phy2: ethernet-phy@2 {
>> + interrupt-parent = <&mpic>;
>> + interrupts = <a 1>;
>> + reg = <2>;
>> + device_type = "ethernet-phy";
>> + };
>> + phy3: ethernet-phy@3 {
>> + interrupt-parent = <&mpic>;
>> + interrupts = <a 1>;
>> + reg = <3>;
>> + device_type = "ethernet-phy";
>> + };
>> + };
[snip]
>>
>> + global-utilities@e0000 { //global utilities block
>> + compatible = "fsl,mpc8548-guts";
>
> Hrm... this should have "fsp,mpc8572-guts" in addition to the older
> model with which it is compatible.
I've changed this to just fsl,mpc8572-guts
>
>> + reg = <e0000 1000>;
>> + fsl,has-rstcr;
>> + };
>> +
>> + mpic: pic@40000 {
>> + clock-frequency = <0>;
>> + interrupt-controller;
>> + #address-cells = <0>;
>> + #interrupt-cells = <2>;
>> + reg = <40000 40000>;
>> + compatible = "chrp,open-pic";
>> + device_type = "open-pic";
>> + big-endian;
>> + };
>> + };
>> +
>> + pcie@ffe08000 {
>> + compatible = "fsl,mpc8548-pcie";
>
> And again, "fsl,mpc8572-pcie", "fsl,mpc8548-pcie".
But why? there is no difference between the PCIe controller in
mpc8548 and mpc8572?
>
>> + device_type = "pci";
>> + #interrupt-cells = <1>;
>> + #size-cells = <2>;
>> + #address-cells = <3>;
>> + reg = <ffe08000 1000>;
>> + bus-range = <0 ff>;
>> + ranges = <02000000 0 80000000 80000000 0 20000000
>> + 01000000 0 00000000 ffc00000 0 00010000>;
>> + clock-frequency = <1fca055>;
>> + interrupt-parent = <&mpic>;
>> + interrupts = <18 2>;
>> + interrupt-map-mask = <fb00 0 0 0>;
>> + interrupt-map = <
>> + /* IDSEL 0x11 - PCI slot 1 */
>> + 8800 0 0 1 &mpic 2 1
>> + 8800 0 0 2 &mpic 3 1
>> + 8800 0 0 3 &mpic 4 1
>> + 8800 0 0 4 &mpic 1 1
>> +
>> + /* IDSEL 0x12 - PCI slot 2 */
>> + 9000 0 0 1 &mpic 3 1
>> + 9000 0 0 2 &mpic 4 1
>> + 9000 0 0 3 &mpic 1 1
>> + 9000 0 0 4 &mpic 2 1
>> +
>> + // IDSEL 0x1c USB
>> + e000 0 0 0 &i8259 c 2
>> + e100 0 0 0 &i8259 9 2
>> + e200 0 0 0 &i8259 a 2
>> + e300 0 0 0 &i8259 b 2
>> +
>> + // IDSEL 0x1d Audio
>> + e800 0 0 0 &i8259 6 2
>> +
>> + // IDSEL 0x1e Legacy
>> + f000 0 0 0 &i8259 7 2
>> + f100 0 0 0 &i8259 7 2
>> +
>> + // IDSEL 0x1f IDE/SATA
>> + f800 0 0 0 &i8259 e 2
>> + f900 0 0 0 &i8259 5 2
>> +
>> + >;
>> + uli1575@0 {
>> + reg = <0 0 0 0 0>;
>
> This looks kind of bogus...
Its a PCIe to PCI bridge that is transparent.
>> + #size-cells = <2>;
>> + #address-cells = <3>;
>> + ranges = <02000000 0 80000000
>> + 02000000 0 80000000
>> + 0 20000000
>> + 01000000 0 00000000
>> + 01000000 0 00000000
>> + 0 00100000>;
>> +
>> + pci_bridge@0 {
>
> Ok.. why is pci_bridge nested within uli1575 - with the matching reg
> and ranges, it looks like they ought to be one device. Also if this
> is a PCI<->PCI bridge, I believe it shold have device_type = "pci".
We've been using this as it stands for a while. If there are some
changes here that make sense I'm willing to make them.
>> + reg = <0 0 0 0 0>;
>> + #size-cells = <2>;
>> + #address-cells = <3>;
>> + ranges = <02000000 0 80000000
>> + 02000000 0 80000000
>> + 0 20000000
>> + 01000000 0 00000000
>> + 01000000 0 00000000
>> + 0 00100000>;
>> +
>> + isa@1e {
>> + device_type = "isa";
>> + #interrupt-cells = <2>;
>> + #size-cells = <1>;
>> + #address-cells = <2>;
>> + reg = <f000 0 0 0 0>;
>> + ranges = <1 0 01000000 0 0
>> + 00001000>;
>> + interrupt-parent = <&i8259>;
>> +
>> + i8259: interrupt-controller@20 {
>> + reg = <1 20 2
>> + 1 a0 2
>> + 1 4d0 2>;
>> + clock-frequency = <0>;
>
> Hrm.. what is clock-frequency for on an i8259? I see that other 8259
> descriptions have this as well, so it's not a problem with this patch
> specifically.
Its a copy-paste thing so I don't know.
- k
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: Olof Johansson @ 2007-09-12 3:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, David Gibson
In-Reply-To: <0F762D4F-C84B-4979-92D4-42C5D40AE455@kernel.crashing.org>
On Tue, Sep 11, 2007 at 10:35:01PM -0500, Kumar Gala wrote:
> > In the meantime, couldn't the code still be merged, using an explicit
> > test of the root node's 'compatible' or 'model' properties to decide
> > on the right primary bus.
>
> I will be, I'm not going to wait on having some device tree spec for
> this. The board code can handle it until we come to some agreement
> on how to do this. I'm in agreement with Scott in that code should
> be added to scan or allow explicit determination. Adding a 'prop' to
> the device tree just for linux seems a bit silly.
Sounds good to me as well.
-Olof
^ permalink raw reply
* Re: [PATCH] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: David Gibson @ 2007-09-12 3:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <0F762D4F-C84B-4979-92D4-42C5D40AE455@kernel.crashing.org>
On Tue, Sep 11, 2007 at 10:35:01PM -0500, Kumar Gala wrote:
>
> On Sep 11, 2007, at 10:00 PM, David Gibson wrote:
>
> > On Tue, Sep 11, 2007 at 12:59:22PM -0500, Kumar Gala wrote:
> >>
> >> On Sep 11, 2007, at 12:48 PM, Scott Wood wrote:
> >>
> >>> Olof Johansson wrote:
> >>>> On Tue, Sep 11, 2007 at 12:21:30PM -0500, Scott Wood wrote:
> >>>>> Olof Johansson wrote:
> >>>>>> On Tue, Sep 11, 2007 at 11:00:28AM -0500, Kumar Gala wrote:
> >>>>>>> well the ifdefs are orthogonal. We don't have a way of knowing
> >>>>>>> primary from the device tree today.
> >>>>>> How about something like "fsl,primary-phb" in the bus device
> >>>>>> node? I don't
> >>>>>> know, maybe it's already been discussed and turned down for some
> >>>>>> reason.
> >>>>> It's more of a Linux issue than anything to do with the hardware.
> >>>>
> >>>> That doesn't stop firmware from telling linux which bus is the
> >>>> primary
> >>>> one on the system to help out.
> >>>
> >>> The entire notion of a "primary" PCI bus is due to a Linux flaw.
> >>>
> >>> If we did put it in the device tree, it should be something like
> >>> "linux,primary-phb". But since Linux can tell from the node's
> >>> children,
> >>> there doesn't seem to be much point.
> >>
> >> Once someone rights code to do this I'm happy to change over. I took
> >> this model of explicitly knowing the primary PHB from the pmac code.
> >
> > In the meantime, couldn't the code still be merged, using an explicit
> > test of the root node's 'compatible' or 'model' properties to decide
> > on the right primary bus.
>
> I will be, I'm not going to wait on having some device tree spec for
> this. The board code can handle it until we come to some agreement
> on how to do this. I'm in agreement with Scott in that code should
> be added to scan or allow explicit determination. Adding a 'prop' to
> the device tree just for linux seems a bit silly.
Yes, saw that in your new version after I'd posted that. Sorry.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: [PATCH v3] [POWERPC] 85xx: Add basic Uniprocessor MPC8572 DS port
From: David Gibson @ 2007-09-12 3:53 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <AC5C6EF4-EE8E-487F-BF45-3653A5C2617D@kernel.crashing.org>
On Tue, Sep 11, 2007 at 10:33:20PM -0500, Kumar Gala wrote:
>
> On Sep 11, 2007, at 10:11 PM, David Gibson wrote:
>
> > On Tue, Sep 11, 2007 at 02:37:56PM -0500, Kumar Gala wrote:
> >> Added basic board port for MPC8572 DS reference platform that is
> >> similiar to the MPC8544/33 DS reference platform in uniprocessor
> >> mode.
> >>
> >> ---
> >>
> >> Rev 3 -- updates to the device tree based on discussion on how we
> >> want
> >> to handle memory busses going forward.
> >
> > [snip]
> >> + mdio@24520 {
> >> + #address-cells = <1>;
> >> + #size-cells = <0>;
> >> + device_type = "mdio";
> >
> > I don't think we actually have an mdio device_type binding defined.
>
> We've had this on 83xx/85xx/86xx device trees for a far amount of
> time now. Look at section 2a in booting-without-of.txt
Ah, so we have; sorry. Although the binding as it is currently
written is pretty much pointless - it should actually define some
mappings between dt properties / addresses and the standards defining
the MDIO bus.x
> >
> >> + compatible = "gianfar";
> >
> > This needs to be more specific. And it certainly shouldn't be the
> > same compatible string as the ethernet MACs have.
>
> Why not its the same controller? Again, we've been doing this for
> some period of time already.
Yes you have, but it's still crap. 'compatible' should be sufficient
to distinguish the driver needed for device nodes, but the MACs and
MDIO should clearly have different drivers (or at least, different
parts of a driver).
> >> + reg = <24520 20>;
> >> + phy0: ethernet-phy@0 {
> >> + interrupt-parent = <&mpic>;
> >> + interrupts = <a 1>;
> >> + reg = <0>;
> >> + device_type = "ethernet-phy";
> >
> > Do we actually have an ethernet-phy device_type binding? If not, we
> > should kill this. 'compatible' properties for phys would probably be
> > a good idea, though (giving the actual phy model).
>
> Look section 2c in booting-without-of.txt
Ah, yes. That one's a rather less redeemable pointless device_type
binding. We should kill it from booting-without-of.txt.
> >> + reg = <e0000 1000>;
> >> + fsl,has-rstcr;
> >> + };
> >> +
> >> + mpic: pic@40000 {
> >> + clock-frequency = <0>;
> >> + interrupt-controller;
> >> + #address-cells = <0>;
> >> + #interrupt-cells = <2>;
> >> + reg = <40000 40000>;
> >> + compatible = "chrp,open-pic";
> >> + device_type = "open-pic";
> >> + big-endian;
> >> + };
> >> + };
> >> +
> >> + pcie@ffe08000 {
> >> + compatible = "fsl,mpc8548-pcie";
> >
> > And again, "fsl,mpc8572-pcie", "fsl,mpc8548-pcie".
>
> But why? there is no difference between the PCIe controller in
> mpc8548 and mpc8572?
As far as you've yet discovered...
> >> + uli1575@0 {
> >> + reg = <0 0 0 0 0>;
> >
> > This looks kind of bogus...
>
> Its a PCIe to PCI bridge that is transparent.
Right.... if it has no control registers, I think it should just lack
'reg', not define a zero-length register block.
> >> + #size-cells = <2>;
> >> + #address-cells = <3>;
> >> + ranges = <02000000 0 80000000
> >> + 02000000 0 80000000
> >> + 0 20000000
> >> + 01000000 0 00000000
> >> + 01000000 0 00000000
> >> + 0 00100000>;
And if truly transparent, it should perhaps have just ranges;
indicating that child addresses are identity mapped to parent
addresses.
> >> +
> >> + pci_bridge@0 {
> >
> > Ok.. why is pci_bridge nested within uli1575 - with the matching reg
> > and ranges, it looks like they ought to be one device. Also if this
> > is a PCI<->PCI bridge, I believe it shold have device_type = "pci".
>
> We've been using this as it stands for a while. If there are some
> changes here that make sense I'm willing to make them.
Right, at present I don't see why you couldn't just ditch the
pci_bridge node, and drop its contents straight into the uli1575 node.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Whitespace changes to define_machine(mpc885_ads).
From: Tony Breeds @ 2007-09-12 3:58 UTC (permalink / raw)
To: LinuxPPC-dev, Paul Mackerras
Make the define_machine() block for mpc885_ads more greppable and consistent
with other examples in tree.
Signed-off-by: Tony Breeds <tony@bakeyournoodle.com>
---
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 17 +++++++++++------
1 file changed, 11 insertions(+), 6 deletions(-)
Index: working/arch/powerpc/platforms/8xx/mpc885ads_setup.c
===================================================================
--- working.orig/arch/powerpc/platforms/8xx/mpc885ads_setup.c 2007-09-10 16:56:54.000000000 +1000
+++ working/arch/powerpc/platforms/8xx/mpc885ads_setup.c 2007-09-12 13:53:17.000000000 +1000
@@ -441,9 +441,14 @@ static int __init mpc885ads_probe(void)
define_machine(mpc885_ads)
{
-.name = "MPC885 ADS",.probe = mpc885ads_probe,.setup_arch =
- mpc885ads_setup_arch,.init_IRQ =
- m8xx_pic_init,.show_cpuinfo = mpc8xx_show_cpuinfo,.get_irq =
- mpc8xx_get_irq,.restart = mpc8xx_restart,.calibrate_decr =
- mpc8xx_calibrate_decr,.set_rtc_time =
- mpc8xx_set_rtc_time,.get_rtc_time = mpc8xx_get_rtc_time,};
+ .name = "MPC885 ADS",
+ .probe = mpc885ads_probe,
+ .setup_arch = mpc885ads_setup_arch,
+ .init_IRQ = m8xx_pic_init,
+ .show_cpuinfo = mpc8xx_show_cpuinfo,
+ .get_irq = mpc8xx_get_irq,
+ .restart = mpc8xx_restart,
+ .calibrate_decr = mpc8xx_calibrate_decr,
+ .set_rtc_time = mpc8xx_set_rtc_time,
+ .get_rtc_time = mpc8xx_get_rtc_time,
+};
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: writing to flash from linux
From: Ratheesh @ 2007-09-12 4:08 UTC (permalink / raw)
To: Yoni Levin; +Cc: linuxppc-embedded
In-Reply-To: <1E2D24B6DA8A4EE68CFFD33998B2BC26.MAI@mail.livedns.co.il>
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
Hi,
You can write into flash from linux if you have mapped the flash in mtd
partition. you can open /dev/mtdx(partition that covers your flash
area) file and use normal read/write function calls to read/write from the
flash. Remember to erase the flash before attempting to write data. You can
refer sourcecode of mtd-utils.
Regards
Ratheesh
On 9/11/07, Yoni Levin <yoni.l@slyde-tech.com> wrote:
>
> Hi , I have EN29LV640H flash (http://www.eonsdi.com/pdf/EN29LV640.pdf)
>
> On my mpc83xx board.
>
> How can I write data to flash from linux.?
>
> I guess it done with mtd , there is an example somewhere?
>
> Thanks.
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2502 bytes --]
^ permalink raw reply
* Re: [RFC/PATCH] Implement {read,update}_persistent_clock. v2
From: Tony Breeds @ 2007-09-12 4:56 UTC (permalink / raw)
To: Milton Miller; +Cc: ppcdev
In-Reply-To: <4d781cd1a4751e20098cae29aa4d2b60@bga.com>
On Tue, Sep 11, 2007 at 09:34:13AM -0500, Milton Miller wrote:
> Previously we called ppc_md.get_boot_time at most once. How about
> moving the check for it into the if (first) block?
Yup on investigatiion it looks like moving it inside the "if (fist)" is
safe.
> Have you tested with a platform that doesn't implement get_rtc_time?
Well no I haven't. AFAICT without my patch read_persistent_clock() is a
weak symbol that always returns 0. So any platform that doesn't have a
ppc_md.get_boot_time() or ppc_md.get_rtc_time() will still get a 0 at
all the call sites.
I'll locate a machine and verify I'm not making things worse.
Yours Tony
linux.conf.au http://linux.conf.au/ || http://lca2008.linux.org.au/
Jan 28 - Feb 02 2008 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: SYSFS: need a noncaching read
From: Robert Schwebel @ 2007-09-12 5:32 UTC (permalink / raw)
To: Heiko Schocher; +Cc: linuxppc-dev, linux-kernel, Detlev Zundel
In-Reply-To: <1189503798.6674.46.camel@Zeus.EmbLux>
On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> I have developed a device driver and use the sysFS to export some
> registers to userspace.
Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
not to play around with registers from userspace.
> I opened the sysFS File for one register and did some reads from this
> File, but I alwas becoming the same value from the register, whats not
> OK, because they are changing. So I found out that the sysFS caches
> the reads ... :-(
Yes, it does. What you can do is close()ing the file handle between
accesses, which makes it work but is slow.
> Is there a way to retrigger the reads (in that way, that the sysFS
> rereads the values from the driver), without closing and opening the
> sysFS Files? Or must I better use the ioctl () Driver-interface for
> exporting these registers?
What kind of problem do you want to solve? Userspace is for
applications, and applications usually don't have to know about hardware
details like registers. So if you have to do something every 10 ms from
userspace, your design is probably wrong.
If you absolutely need to do such things from userspace, have a look at
uio. But in most cases the answer is: make a proper abstraction for the
problem you wanna solve and write a proper driver.
Robert
--
Pengutronix - Linux Solutions for Science and Industry
Entwicklungszentrum Nord http://www.pengutronix.de
^ 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