Skip to contentSkip to conversation

x86/platform changes for v3.9

GIT PULL Ingo Molnar 4 participants 7 messages Feb 19, 2013 – Feb 20, 2013

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

Linus,

Please pull the latest x86-platform-for-linus git tree from:

git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-platform-for-linus

HEAD: 7d0291256ca99cbb6124f63228003329e7a64b21 x86: Add TS-5500 platform support

* Support for the Technologic Systems TS-5500 platform, by Vivien Didelot

* Improved NUMA support on AMD systems:

Add support for federated systems where multiple memory controllers can exist and see each other over multiple PCI domains. This basically means that AMD node ids can be more than 8 now and the code handling this is taught to incorporate PCI domain into those IDs.

* Support for the Goldfish virtual Android emulator, by Jun Nakajima, Intel, Google, et al.

* Misc fixlets.

out-of-topic modifications in x86-platform-for-linus:
-----------------------------------------------------
MAINTAINERS # 7d02912: x86: Add TS-5500 platform support
drivers/edac/amd64_edac.c # c7e5301: amd64_edac: Fix type usage in NB

                                   # e2c0bff: amd64_edac: Fix PCI function look
                                   # 8b84c8d: x86, AMD, NB: Use u16 for northbr
                                   # 772c3ff: x86, AMD, NB: Add multi-domain su
drivers/edac/amd64_edac.h          # c7e5301: amd64_edac: Fix type usage in NB 
                                   # 772c3ff: x86, AMD, NB: Add multi-domain su

Thanks,

Ingo

------------------>
Cong Ding (1):
x86/apb/timer: Remove unnecessary "if"

Daniel J Blueman (4):
x86, AMD, NB: Add multi-domain support
x86, AMD, NB: Use u16 for northbridge IDs in amd_get_nb_id
amd64_edac: Fix PCI function lookup
amd64_edac: Fix type usage in NB IDs and memory ranges

Davidlohr Bueso (1):
x86/srat: Simplify memory affinity init error handling

Jun Nakajima (1):
goldfish: platform device for x86

Vivien Didelot (1):
x86: Add TS-5500 platform support

 Documentation/ABI/testing/sysfs-platform-ts5500 |  47 ++++
 MAINTAINERS                                     |   5 +
 arch/x86/Kconfig                                |  21 ++
 arch/x86/include/asm/amd_nb.h                   |  17 ++
 arch/x86/include/asm/processor.h                |   2 +-
 arch/x86/kernel/apb_timer.c                     |   2 +-
 arch/x86/kernel/cpu/amd.c                       |   4 +-
 arch/x86/mm/srat.c                              |  29 +-
 arch/x86/platform/Makefile                      |   2 +
 arch/x86/platform/goldfish/Makefile             |   1 +
 arch/x86/platform/goldfish/goldfish.c           |  51 ++++
 arch/x86/platform/ts5500/Makefile               |   1 +
 arch/x86/platform/ts5500/ts5500.c               | 339 ++++++++++++++++++++++++
 drivers/edac/amd64_edac.c                       | 109 ++++----
 drivers/edac/amd64_edac.h                       |  12 +-
 15 files changed, 563 insertions(+), 79 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-platform-ts5500
 create mode 100644 arch/x86/platform/goldfish/Makefile
 create mode 100644 arch/x86/platform/goldfish/goldfish.c
 create mode 100644 arch/x86/platform/ts5500/Makefile
 create mode 100644 arch/x86/platform/ts5500/ts5500.c
Documentation/ABI/testing/sysfs-platform-ts5500 new file +47 -0
new file mode 100644
index 0000000..c88375a
@@ -0,0 +1,47 @@
+What:		/sys/devices/platform/ts5500/adc
+Date:		January 2013
+KernelVersion:	3.7
+Contact:	"Savoir-faire Linux Inc." <[email protected]>
+Description:
+		Indicates the presence of an A/D Converter. If it is present,
+		it will display "1", otherwise "0".
+
+What:		/sys/devices/platform/ts5500/ereset
+Date:		January 2013
+KernelVersion:	3.7
+Contact:	"Savoir-faire Linux Inc." <[email protected]>
+Description:
+		Indicates the presence of an external reset. If it is present,
+		it will display "1", otherwise "0".
+
+What:		/sys/devices/platform/ts5500/id
+Date:		January 2013
+KernelVersion:	3.7
+Contact:	"Savoir-faire Linux Inc." <[email protected]>
+Description:
+		Product ID of the TS board. TS-5500 ID is 0x60.
+
+What:		/sys/devices/platform/ts5500/jumpers
+Date:		January 2013
+KernelVersion:	3.7
+Contact:	"Savoir-faire Linux Inc." <[email protected]>
+Description:
+		Bitfield showing the jumpers' state. If a jumper is present,
+		the corresponding bit is set. For instance, 0x0e means jumpers
+		2, 3 and 4 are set.
+
+What:		/sys/devices/platform/ts5500/rs485
+Date:		January 2013
+KernelVersion:	3.7
+Contact:	"Savoir-faire Linux Inc." <[email protected]>
+Description:
+		Indicates the presence of the RS485 option. If it is present,
+		it will display "1", otherwise "0".
+
+What:		/sys/devices/platform/ts5500/sram
+Date:		January 2013
+KernelVersion:	3.7
+Contact:	"Savoir-faire Linux Inc." <[email protected]>
+Description:
+		Indicates the presence of the SRAM option. If it is present,
+		it will display "1", otherwise "0".
MAINTAINERS +5 -0
index 3105c48..2617040 100644
@@ -7543,6 +7543,11 @@ F:	drivers/net/team/
 F:	include/linux/if_team.h
 F:	include/uapi/linux/if_team.h
 
+TECHNOLOGIC SYSTEMS TS-5500 PLATFORM SUPPORT
+M:	Savoir-faire Linux Inc. <[email protected]>
+S:	Maintained
+F:	arch/x86/platform/ts5500/
+
 TECHNOTREND USB IR RECEIVER
 M:	Sean Young <[email protected]>
 L:	[email protected]
arch/x86/Kconfig +21 -0
index 79795af..0709e34 100644
@@ -320,6 +320,10 @@ config X86_BIGSMP
 	---help---
 	  This option is needed for the systems that have more than 8 CPUs
 
+config GOLDFISH
+       def_bool y
+       depends on X86_GOLDFISH
+
 if X86_32
 config X86_EXTENDED_PLATFORM
 	bool "Support for extended (non-PC) x86 platforms"
@@ -402,6 +406,14 @@ config X86_UV
 # Following is an alphabetically sorted list of 32 bit extended platforms
 # Please maintain the alphabetic order if and when there are additions
 
+config X86_GOLDFISH
+       bool "Goldfish (Virtual Platform)"
+       depends on X86_32
+       ---help---
+	 Enable support for the Goldfish virtual platform used primarily
+	 for Android development. Unless you are building for the Android
+	 Goldfish emulator say N here.
+
 config X86_INTEL_CE
 	bool "CE4100 TV platform"
 	depends on PCI
@@ -2187,6 +2199,15 @@ config GEOS
 	---help---
 	  This option enables system support for the Traverse Technologies GEOS.
 
+config TS5500
+	bool "Technologic Systems TS-5500 platform support"
+	depends on MELAN
+	select CHECK_SIGNATURE
+	select NEW_LEDS
+	select LEDS_CLASS
+	---help---
+	  This option enables system support for the Technologic Systems TS-5500.
+
 endif # X86_32
 
 config AMD_NB
arch/x86/include/asm/amd_nb.h +17 -0
index b3341e9..a54ee1d 100644
@@ -81,6 +81,23 @@ static inline struct amd_northbridge *node_to_amd_nb(int node)
 	return (node < amd_northbridges.num) ? &amd_northbridges.nb[node] : NULL;
 }
 
+static inline u16 amd_get_node_id(struct pci_dev *pdev)
+{
+	struct pci_dev *misc;
+	int i;
+
+	for (i = 0; i != amd_nb_num(); i++) {
+		misc = node_to_amd_nb(i)->misc;
+
+		if (pci_domain_nr(misc->bus) == pci_domain_nr(pdev->bus) &&
+		    PCI_SLOT(misc->devfn) == PCI_SLOT(pdev->devfn))
+			return i;
+	}
+
+	WARN(1, "Unable to find AMD Northbridge id for %s\n", pci_name(pdev));
+	return 0;
+}
+
 #else
 
 #define amd_nb_num(x)		0
arch/x86/include/asm/processor.h +1 -1
index 888184b..cf50054 100644
@@ -943,7 +943,7 @@ extern void start_thread(struct pt_regs *regs, unsigned long new_ip,
 extern int get_tsc_mode(unsigned long adr);
 extern int set_tsc_mode(unsigned int val);
 
-extern int amd_get_nb_id(int cpu);
+extern u16 amd_get_nb_id(int cpu);
 
 struct aperfmperf {
 	u64 aperf, mperf;
arch/x86/kernel/apb_timer.c +1 -1
index afdc3f75..cf92735 100644
@@ -240,7 +240,7 @@ static int apbt_cpuhp_notify(struct notifier_block *n,
 		dw_apb_clockevent_pause(adev->timer);
 		if (system_state == SYSTEM_RUNNING) {
 			pr_debug("skipping APBT CPU %lu offline\n", cpu);
-		} else if (adev) {
+		} else {
 			pr_debug("APBT clockevent for cpu %lu offline\n", cpu);
 			dw_apb_clockevent_stop(adev->timer);
 		}
arch/x86/kernel/cpu/amd.c +2 -2
index 15239ff..782c456 100644
@@ -364,9 +364,9 @@ static void __cpuinit amd_detect_cmp(struct cpuinfo_x86 *c)
 #endif
 }
 
-int amd_get_nb_id(int cpu)
+u16 amd_get_nb_id(int cpu)
 {
-	int id = 0;
+	u16 id = 0;
 #ifdef CONFIG_SMP
 	id = per_cpu(cpu_llc_id, cpu);
 #endif
arch/x86/mm/srat.c +15 -14
index 4ddf497..cdd0da9 100644
@@ -149,39 +149,40 @@ acpi_numa_memory_affinity_init(struct acpi_srat_mem_affinity *ma)
 	int node, pxm;
 
 	if (srat_disabled())
-		return -1;
-	if (ma->header.length != sizeof(struct acpi_srat_mem_affinity)) {
-		bad_srat();
-		return -1;
-	}
+		goto out_err;
+	if (ma->header.length != sizeof(struct acpi_srat_mem_affinity))
+		goto out_err_bad_srat;
 	if ((ma->flags & ACPI_SRAT_MEM_ENABLED) == 0)
-		return -1;
-
+		goto out_err;
 	if ((ma->flags & ACPI_SRAT_MEM_HOT_PLUGGABLE) && !save_add_info())
-		return -1;
+		goto out_err;
+
 	start = ma->base_address;
 	end = start + ma->length;
 	pxm = ma->proximity_domain;
 	if (acpi_srat_revision <= 1)
 		pxm &= 0xff;
+
 	node = setup_node(pxm);
 	if (node < 0) {
 		printk(KERN_ERR "SRAT: Too many proximity domains.\n");
-		bad_srat();
-		return -1;
+		goto out_err_bad_srat;
 	}
 
-	if (numa_add_memblk(node, start, end) < 0) {
-		bad_srat();
-		return -1;
-	}
+	if (numa_add_memblk(node, start, end) < 0)
+		goto out_err_bad_srat;
 
 	node_set(node, numa_nodes_parsed);
 
 	printk(KERN_INFO "SRAT: Node %u PXM %u [mem %#010Lx-%#010Lx]\n",
 	       node, pxm,
 	       (unsigned long long) start, (unsigned long long) end - 1);
+
 	return 0;
+out_err_bad_srat:
+	bad_srat();
+out_err:
+	return -1;
 }
 
 void __init acpi_numa_arch_fixup(void) {}
arch/x86/platform/Makefile +2 -0
index 8d87439..01e0231 100644
@@ -2,10 +2,12 @@
 obj-y	+= ce4100/
 obj-y	+= efi/
 obj-y	+= geode/
+obj-y	+= goldfish/
 obj-y	+= iris/
 obj-y	+= mrst/
 obj-y	+= olpc/
 obj-y	+= scx200/
 obj-y	+= sfi/
+obj-y	+= ts5500/
 obj-y	+= visws/
 obj-y	+= uv/
arch/x86/platform/goldfish/Makefile new file +1 -0
new file mode 100644
index 0000000..f030b53
@@ -0,0 +1 @@
+obj-$(CONFIG_GOLDFISH)	+= goldfish.o
arch/x86/platform/goldfish/goldfish.c new file +51 -0

51 lines not on this page · raw message

arch/x86/platform/ts5500/Makefile new file +1 -0
new file mode 100644
index 0000000..c54e348
@@ -0,0 +1 @@
+obj-$(CONFIG_TS5500)	+= ts5500.o
arch/x86/platform/ts5500/ts5500.c new file +339 -0

339 lines not on this page · raw message

drivers/edac/amd64_edac.c +57 -52

246 lines not on this page · raw message

drivers/edac/amd64_edac.h +3 -9
index e864f40..35637d8 100644
@@ -292,12 +292,6 @@
 /* MSRs */
 #define MSR_MCGCTL_NBE			BIT(4)
 
-/* AMD sets the first MC device at device ID 0x18. */
-static inline u8 get_node_id(struct pci_dev *pdev)
-{
-	return PCI_SLOT(pdev->devfn) - 0x18;
-}
-
 enum amd_families {
 	K8_CPUS = 0,
 	F10_CPUS,
@@ -340,7 +334,7 @@ struct amd64_pvt {
 	/* pci_device handles which we utilize */
 	struct pci_dev *F1, *F2, *F3;
 
-	unsigned mc_node_id;	/* MC index of this MC node */
+	u16 mc_node_id;		/* MC index of this MC node */
 	int ext_model;		/* extended model value of this node */
 	int channel_count;
 
@@ -393,7 +387,7 @@ struct err_info {
 	u32 offset;
 };
 
-static inline u64 get_dram_base(struct amd64_pvt *pvt, unsigned i)
+static inline u64 get_dram_base(struct amd64_pvt *pvt, u8 i)
 {
 	u64 addr = ((u64)pvt->ranges[i].base.lo & 0xffff0000) << 8;
 
@@ -403,7 +397,7 @@ static inline u64 get_dram_base(struct amd64_pvt *pvt, unsigned i)
 	return (((u64)pvt->ranges[i].base.hi & 0x000000ff) << 40) | addr;
 }
 
-static inline u64 get_dram_limit(struct amd64_pvt *pvt, unsigned i)
+static inline u64 get_dram_limit(struct amd64_pvt *pvt, u8 i)
 {
 	u64 lim = (((u64)pvt->ranges[i].lim.lo & 0xffff0000) << 8) | 0x00ffffff;
 
#1 lore raw
Quoted 2 lines · Ingo Molnar

Please pull the latest x86-platform-for-linus git tree from:

Hmm.

My main desktop just had a reboot failure - it just got stuck at the end, not powering down, and not rebooting like it should have.

This is *not* necessarily the pull that caused it, but 8f55cea410db rebooted cleanly, and 1a13c0b181f2 did not. That implies that it's one of your pull requests. The pulls I did in between are:

- scheduler (with the dyntick and cputime accounting)

- smp-hotplug-for-linus: stop_machine preparatory patches from Thomas..

- timers-core-for-linus. Hmm..

- x86-apic-for-linus: certainly possibly causing problems at shutdown..

- x86-asm-for-linus: sounds unlikely, but who knows..

- x86-boot-for-linus: shouldn't affect shutdown, but..

- x86-build-for-linus: _really_ shouldn't affect shutdown..

- x86-cleanups-for-linus: unlikely

- x86-hyperv-for-linus: no, not a hyperv user ;)

- x86-platform-for-linus: rebooting is a platform thing, but none of
this seems relevant

- x86-uv-for-linus: not likely relevant.

I'm not going to bisect it right now, hoping that somebody goes "Hmm, maybe it's xyzzy". And maybe it was just a one-time event, but I don't recall having had that whole "reboot fails" case on this machine before. Any ideas?

Linus

#2 lore raw
Quoted 36 lines · Linus Torvalds
Quoted 2 lines · Ingo Molnar

Please pull the latest x86-platform-for-linus git tree from:

Hmm.

My main desktop just had a reboot failure - it just got stuck at the end, not powering down, and not rebooting like it should have.

This is *not* necessarily the pull that caused it, but 8f55cea410db rebooted cleanly, and 1a13c0b181f2 did not. That implies that it's one of your pull requests. The pulls I did in between are:

- scheduler (with the dyntick and cputime accounting)

- smp-hotplug-for-linus: stop_machine preparatory patches from Thomas..

- timers-core-for-linus. Hmm..

- x86-apic-for-linus: certainly possibly causing problems at shutdown..

- x86-asm-for-linus: sounds unlikely, but who knows..

- x86-boot-for-linus: shouldn't affect shutdown, but..

- x86-build-for-linus: _really_ shouldn't affect shutdown..

- x86-cleanups-for-linus: unlikely

- x86-hyperv-for-linus: no, not a hyperv user ;)

- x86-platform-for-linus: rebooting is a platform thing, but none of
this seems relevant

Quoted 6 lines

- x86-uv-for-linus: not likely relevant.

I'm not going to bisect it right now, hoping that somebody goes "Hmm, maybe it's xyzzy". And maybe it was just a one-time event, but I don't recall having had that whole "reboot fails" case on this machine before. Any ideas?

Hm, no quick ideas. None of those trees had any similar problems during development, so there's no "drat, it must be _that_ tree again" memory.

Timers and APIC would be my leading suspect - but scheduler and hotplug changes might be the culprits as well.

Yesterday, while preparing the trees I wanted to mention this x86/apic commit:

336224ba5e4f x86, apic: Mask IO-APIC and PIC unconditionally on LAPIC resume

... as a change that needs monitored because it changes the suspend and shutdown sequence but then skipped mentioning it because it seemed relatively old and proven.

But there are other potentially dangerous commits as well - I suspect we won't be able to avoid a bisection :-/

Thanks,

Ingo

#3 lore raw
Quoted 6 lines · Linus Torvalds
Quoted 4 lines

My main desktop just had a reboot failure - it just got stuck at the end, not powering down, and not rebooting like it should have.

if it matters: I have test machines of various x86 vintage, most of which test booted these trees before sending, and none had reboot failures: so I'd suspect the hang is either system/driver specific, or somehow .config dependent. I'd be surprised if it was a generic hang.

Thanks,

Ingo

#4 lore raw
In reply to Ingo Molnar
Quoted 11 lines · Ingo Molnar

Timers and APIC would be my leading suspect - but scheduler and hotplug changes might be the culprits as well.

Yesterday, while preparing the trees I wanted to mention this x86/apic commit:

336224ba5e4f x86, apic: Mask IO-APIC and PIC unconditionally on LAPIC resume

... as a change that needs monitored because it changes the suspend and shutdown sequence but then skipped mentioning it because it seemed relatively old and proven.

Hmm, this commit only touches the resume-path. I would wonder if this has something to do with reboot, can't rule it out, though.

Quoted 2 lines

But there are other potentially dangerous commits as well - I suspect we won't be able to avoid a bisection :-/

Yes, I think a bisection would be best if the problem is reproducible.

Joerg

#5 lore raw
In reply to Linus Torvalds
Quoted 3 lines · Linus Torvalds

My main desktop just had a reboot failure - it just got stuck at the end, not powering down, and not rebooting like it should have.

Ok, it doesn't seem to be repeatable, so I'm going to ignore it until it happens again.

Linus

#6 lore raw
Quoted 8 lines · Linus Torvalds
Quoted 3 lines · Linus Torvalds

My main desktop just had a reboot failure - it just got stuck at the end, not powering down, and not rebooting like it should have.

Ok, it doesn't seem to be repeatable, so I'm going to ignore it until it happens again.

FWIW, I just saw this happen too on an AMD box running your tree as of ece8e0b2f9c980e5511fe8db2d68c6f1859b9d83

Not going to have time to bisect it though, due to travel.

Dave