* Re: [PATCH] ASoC: fsl: Set sdma peripheral type directly
From: Shawn Guo @ 2013-07-25 14:01 UTC (permalink / raw)
To: Nicolin Chen; +Cc: fabio.estevam, alsa-devel, broonie, linuxppc-dev, timur
In-Reply-To: <1374745301-29508-1-git-send-email-b42378@freescale.com>
On Thu, Jul 25, 2013 at 05:41:41PM +0800, Nicolin Chen wrote:
> Let CPU DAI drivers set SDMA periperal type directly to support more
> dma types(SPDIF, ESAI) other than only two for SSI.
> This will easily allow some non-SSI drivers to use the imx-pcm-dma
> as well.
>
> Signed-off-by: Nicolin Chen <b42378@freescale.com>
Acked-by: Shawn Guo <shawn.guo@linaro.org>
^ permalink raw reply
* Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
From: Frederic Weisbecker @ 2013-07-25 13:30 UTC (permalink / raw)
To: Preeti U Murthy
Cc: rjw, shangw, arnd, linux-pm, geoff, rostedt, deepthi,
paul.gortmaker, paulus, srivatsa.bhat, schwidefsky, john.stultz,
tglx, paulmck, linuxppc-dev, linux-kernel, chenhui.zhao
In-Reply-To: <20130725090302.12500.42998.stgit@preeti.in.ibm.com>
On Thu, Jul 25, 2013 at 02:33:02PM +0530, Preeti U Murthy wrote:
> In the current design of timer offload framework, the broadcast cpu should
> *not* go into tickless idle so as to avoid missed wakeups on CPUs in deep idle states.
>
> Since we prevent the CPUs entering deep idle states from programming the lapic of the
> broadcast cpu for their respective next local events for reasons mentioned in
> PATCH[3/5], the broadcast CPU checks if there are any CPUs to be woken up during
> each of its timer interrupt programmed to its local events.
>
> With tickless idle, the broadcast CPU might not get a timer interrupt till after
> many ticks which can result in missed wakeups on CPUs in deep idle states. By
> disabling tickless idle, worst case, the tick_sched hrtimer will trigger a
> timer interrupt every period to check for broadcast.
>
> However the current setup of tickless idle does not let us make the choice
> of tickless on individual cpus. NOHZ_MODE_INACTIVE which disables tickless idle,
> is a system wide setting. Hence resort to an arch specific call to check if a cpu
> can go into tickless idle.
Hi Preeti,
I'm not exactly sure why you can't enter the broadcast CPU in dynticks idle mode.
I read in the previous patch that's because in dynticks idle mode the broadcast
CPU deactivates its lapic so it doesn't receive the IPI. But may be I misunderstood.
Anyway that's not good for powersaving.
Also when an arch wants to prevent a CPU from entering dynticks idle mode, it typically
use arch_needs_cpu(). May be that could fit for you as well?
Thanks.
^ permalink raw reply
* Re: [PATCH] module: ppc64 module CRC relocation fix causes perf issues
From: Neil Horman @ 2013-07-25 13:02 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Rusty Russell, linux-kernel, Paul Mackerras, Anton Blanchard,
Scott Wood, linuxppc-dev
In-Reply-To: <1374707665.6142.18.camel@pasglop>
On Thu, Jul 25, 2013 at 09:14:25AM +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 08:34 +1000, Anton Blanchard wrote:
> > > Apart from the annoying colors, is there anything specific I should
> > > be looking for? Some sort of error message, or output that actually
> > > makes sense?
> >
> > Thanks for testing! Ben, I think the patch is good to go.
>
> Sent it yesterday to Linus, it's upstream already :-)
>
> Cheers,
> Ben.
>
Sorry I'm a bit late to the thread, I've ben swamped. Has someone tested this
with kexec/kdump? Thats why the origional patch was created, because when kexec
loads the kernel at a different physical address, the relocations messed with
the module crc's, and modules couldn't load during the kexec boot. Assuming
that kernaddr_start gets set appropriately during boot, using PHYSICAL_START
should be fine, but I wanted to check, and don't currently have access to a
powerpc system to do so.
Neil
>
>
>
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
From: Kevin Hao @ 2013-07-25 12:54 UTC (permalink / raw)
To: Scott Wood; +Cc: linuxppc, Alexander Graf
In-Reply-To: <1374618676.15592.40@snotra>
[-- Attachment #1: Type: text/plain, Size: 15330 bytes --]
On Tue, Jul 23, 2013 at 05:31:16PM -0500, Scott Wood wrote:
> On 06/06/2013 09:00:20 PM, Kevin Hao wrote:
> > Vector table: BAR=1 offset=00000000
<snip>
> > PBA: BAR=1 offset=00000800
> >
> >
> >As you can see, the only difference between these two logs is the
> >io resource address and all the mem and bus address are still the
> >same.
>
> I dug a bit deeper into this, and it's making by head hurt. It
> seems that we're now getting saved by the host bridge (that for some
> reason has the class code of a PCI-to-PCI bridge rather than a host
> bridge) having I/O space of 0x1000 bytes[1], which gets allocated at
> zero. There have been some changes in the QEMU PCI code since I saw
> the problem, including changing the class code of the bridge, so
> that's probably why it sort-of works now.
We are not just lucky here. Even without the change of the qemu pci
code we still can get the correct IO address in the current kernel.
The following is the log by running the latest kernel on the qemu which
doesn't have the PCI-to-PCI bridge change yet. As you can see we don't
pick a primary pci bus in this case and the Ethernet controller still get
the I/O ports at 1000.
PCI: Probing PCI hardware
fsl-pci e0008000.pci: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0xf1020000-0xf102ffff] (bus address [0x0000-0xffff])
pci_bus 0000:00: root bus resource [mem 0xc0000000-0xdfffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
pci 0000:00:00.0: [1957:0030] type 00 class 0x0b2000
pci 0000:00:11.0: [1af4:1000] type 00 class 0x020000
pci 0000:00:11.0: reg 0x10: [io 0xf1020000-0xf102001f]
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
pci 0000:00:11.0: BAR 0: assigned [io 0xf1021000-0xf102101f]
pci_bus 0000:00: resource 4 [io 0xf1020000-0xf102ffff]
pci_bus 0000:00: resource 5 [mem 0xc0000000-0xdfffffff]
root@localhost:~# lspci -v
00:00.0 Power PC: Freescale Semiconductor Inc MPC8533E
Subsystem: Red Hat, Inc Device 1100
Flags: bus master, fast devsel, latency 0
00:11.0 Ethernet controller: Red Hat, Inc Virtio network device
Subsystem: Red Hat, Inc Device 0001
Flags: fast devsel, IRQ 16
I/O ports at 1000 [disabled] [size=32]
The reason is that the ppc kernel assume that the BARs starting
at 0 is unset and will reassign it later. There is a bug in the previous
kernel, so the kernel maybe not work well for qemu in this case. But I
think this has been fixed by the commit c5df457f (powerpc/pci: Check the
bus address instead of resource address in pcibios_fixup_resources).
>
> What QEMU is doing does not match what real hardware does, though.
> At least on mpc8536 which is similar to mpc8544 (I wasn't able to
> quickly get access to a working mpc8544 to test on), the PCI bridge
> has class code Processor, rather than bridge of any sort. Thus, on
> real hardware we would not get the 0x1000 reservation.
This doesn't matter. We can always make sure to reassign these resources
starting at 0. I also done a test on the mpc8536ds board. Both the pci
and pcie devices work pretty well without picking a primary pci bus
on this board. The following is the log.
Found FSL PCI host bridge at 0x00000000ffe08000. Firmware bus number: 0->0
PCI host bridge /pci@ffe08000 ranges:
MEM 0x0000000080000000..0x000000008fffffff -> 0x0000000080000000
IO 0x00000000ffc00000..0x00000000ffc0ffff -> 0x0000000000000000
/pci@ffe08000: PCICSRBAR @ 0xfff00000
Found FSL PCI host bridge at 0x00000000ffe09000. Firmware bus number: 0->0
PCI host bridge /pcie@ffe09000 ranges:
MEM 0x0000000098000000..0x000000009fffffff -> 0x0000000098000000
IO 0x00000000ffc20000..0x00000000ffc2ffff -> 0x0000000000000000
/pcie@ffe09000: PCICSRBAR @ 0xfff00000
Found FSL PCI host bridge at 0x00000000ffe0a000. Firmware bus number: 0->1
PCI host bridge /pcie@ffe0a000 ranges:
MEM 0x0000000090000000..0x0000000097ffffff -> 0x0000000090000000
IO 0x00000000ffc10000..0x00000000ffc1ffff -> 0x0000000000000000
/pcie@ffe0a000: PCICSRBAR @ 0xfff00000
Found FSL PCI host bridge at 0x00000000ffe0b000. Firmware bus number: 0->0
PCI host bridge /pcie@ffe0b000 ranges:
MEM 0x00000000a0000000..0x00000000bfffffff -> 0x00000000a0000000
IO 0x00000000ffc30000..0x00000000ffc3ffff -> 0x0000000000000000
/pcie@ffe0b000: PCICSRBAR @ 0xfff00000
PCI: Probing PCI hardware
fsl-pci ffe08000.pci: PCI host bridge to bus 0000:00
pci_bus 0000:00: root bus resource [io 0xe1020000-0xe102ffff] (bus address [0x0000-0xffff])
pci_bus 0000:00: root bus resource [mem 0x80000000-0x8fffffff]
pci_bus 0000:00: root bus resource [bus 00-ff]
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to ff
pci 0000:00:00.0: [1957:0050] type 00 class 0x0b2000
pci 0000:00:00.0: reg 0x10: [mem 0xfff00000-0xffffffff]
pci 0000:00:00.0: reg 0x14: [mem 0x00000000-0x1fffffff pref]
pci 0000:00:11.0: [8086:107c] type 00 class 0x020000
pci 0000:00:11.0: reg 0x10: [mem 0x80000000-0x8001ffff]
pci 0000:00:11.0: reg 0x14: [mem 0x80020000-0x8003ffff]
pci 0000:00:11.0: reg 0x18: [io 0xe1021000-0xe102103f]
pci 0000:00:11.0: reg 0x30: [mem 0x00000000-0x0001ffff pref]
pci 0000:00:11.0: PME# supported from D0 D3hot D3cold
pci_bus 0000:00: busn_res: [bus 00-ff] end is updated to 00
fsl-pci ffe09000.pcie: PCI host bridge to bus 0001:01
pci_bus 0001:01: root bus resource [io 0xe1040000-0xe104ffff] (bus address [0x0000-0xffff])
pci_bus 0001:01: root bus resource [mem 0x98000000-0x9fffffff]
pci_bus 0001:01: root bus resource [bus 01-ff]
pci_bus 0001:01: busn_res: [bus 01-ff] end is updated to ff
pci 0001:01:00.0: [1957:0050] type 01 class 0x0b2000
pci 0001:01:00.0: ignoring class 0x0b2000 (doesn't match header type 01)
pci 0001:01:00.0: supports D1 D2
pci 0001:01:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0001:01:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0001:01:00.0: PCI bridge to [bus 02-ff]
pci 0001:01:00.0: bridge window [io 0xe1040000-0xe1040fff]
pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff]
pci 0001:01:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref]
pci_bus 0001:02: busn_res: [bus 02-ff] end is updated to 02
pci_bus 0001:01: busn_res: [bus 01-ff] end is updated to 02
fsl-pci ffe0a000.pcie: PCI host bridge to bus 0002:03
pci_bus 0002:03: root bus resource [io 0xe1060000-0xe106ffff] (bus address [0x0000-0xffff])
pci_bus 0002:03: root bus resource [mem 0x90000000-0x97ffffff]
pci_bus 0002:03: root bus resource [bus 03-ff]
pci_bus 0002:03: busn_res: [bus 03-ff] end is updated to ff
pci 0002:03:00.0: [1957:0050] type 01 class 0x0b2000
pci 0002:03:00.0: ignoring class 0x0b2000 (doesn't match header type 01)
pci 0002:03:00.0: supports D1 D2
pci 0002:03:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0002:03:00.0: Primary bus is hard wired to 0
pci 0002:03:00.0: bridge configuration invalid ([bus 01-01]), reconfiguring
pci 0002:04:00.0: [8086:107d] type 00 class 0x020000
pci 0002:04:00.0: reg 0x10: [mem 0x90000000-0x9001ffff]
pci 0002:04:00.0: reg 0x14: [mem 0x90020000-0x9003ffff]
pci 0002:04:00.0: reg 0x18: [io 0xe1061000-0xe106101f]
pci 0002:04:00.0: PME# supported from D0 D3hot D3cold
pci 0002:03:00.0: PCI bridge to [bus 04-ff]
pci 0002:03:00.0: bridge window [io 0xe1060000-0xe1060fff]
pci 0002:03:00.0: bridge window [mem 0x90000000-0x900fffff]
pci_bus 0002:04: busn_res: [bus 04-ff] end is updated to 04
pci_bus 0002:03: busn_res: [bus 03-ff] end is updated to 04
fsl-pci ffe0b000.pcie: PCI host bridge to bus 0003:05
pci_bus 0003:05: root bus resource [io 0xe1080000-0xe108ffff] (bus address [0x0000-0xffff])
pci_bus 0003:05: root bus resource [mem 0xa0000000-0xbfffffff]
pci_bus 0003:05: root bus resource [bus 05-ff]
pci_bus 0003:05: busn_res: [bus 05-ff] end is updated to ff
pci 0003:05:00.0: [1957:0050] type 01 class 0x0b2000
pci 0003:05:00.0: ignoring class 0x0b2000 (doesn't match header type 01)
pci 0003:05:00.0: supports D1 D2
pci 0003:05:00.0: PME# supported from D0 D1 D2 D3hot D3cold
pci 0003:05:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring
pci 0003:05:00.0: PCI bridge to [bus 06-ff]
pci 0003:05:00.0: bridge window [io 0xe1080000-0xe1080fff]
pci 0003:05:00.0: bridge window [mem 0x00000000-0x000fffff]
pci 0003:05:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref]
pci_bus 0003:06: busn_res: [bus 06-ff] end is updated to 06
pci_bus 0003:05: busn_res: [bus 05-ff] end is updated to 06
PCI 0001:01 Cannot reserve Legacy IO [io 0xe1040000-0xe1040fff]
PCI 0002:03 Cannot reserve Legacy IO [io 0xe1060000-0xe1060fff]
PCI 0003:05 Cannot reserve Legacy IO [io 0xe1080000-0xe1080fff]
pci 0000:00:11.0: BAR 6: assigned [mem 0x80040000-0x8005ffff pref]
pci 0001:01:00.0: PCI bridge to [bus 02]
pci 0001:01:00.0: bridge window [io 0xe1040000-0xe104ffff]
pci 0001:01:00.0: bridge window [mem 0x98000000-0x9fffffff]
pci 0002:03:00.0: PCI bridge to [bus 04]
pci 0002:03:00.0: bridge window [io 0xe1060000-0xe106ffff]
pci 0002:03:00.0: bridge window [mem 0x90000000-0x97ffffff]
pci 0003:05:00.0: PCI bridge to [bus 06]
pci 0003:05:00.0: bridge window [io 0xe1080000-0xe108ffff]
pci 0003:05:00.0: bridge window [mem 0xa0000000-0xbfffffff]
pci 0001:01:00.0: enabling device (0106 -> 0107)
pci 0002:03:00.0: enabling device (0106 -> 0107)
pci 0003:05:00.0: enabling device (0106 -> 0107)
pci_bus 0000:00: resource 4 [io 0xe1020000-0xe102ffff]
pci_bus 0000:00: resource 5 [mem 0x80000000-0x8fffffff]
pci_bus 0001:01: resource 4 [io 0xe1040000-0xe104ffff]
pci_bus 0001:01: resource 5 [mem 0x98000000-0x9fffffff]
pci_bus 0001:02: resource 0 [io 0xe1040000-0xe104ffff]
pci_bus 0001:02: resource 1 [mem 0x98000000-0x9fffffff]
pci_bus 0002:03: resource 4 [io 0xe1060000-0xe106ffff]
pci_bus 0002:03: resource 5 [mem 0x90000000-0x97ffffff]
pci_bus 0002:04: resource 0 [io 0xe1060000-0xe106ffff]
pci_bus 0002:04: resource 1 [mem 0x90000000-0x97ffffff]
pci_bus 0003:05: resource 4 [io 0xe1080000-0xe108ffff]
pci_bus 0003:05: resource 5 [mem 0xa0000000-0xbfffffff]
pci_bus 0003:06: resource 0 [io 0xe1080000-0xe108ffff]
pci_bus 0003:06: resource 1 [mem 0xa0000000-0xbfffffff]
root@intel_tunnel_creek-2:/root> lspci -v
0000:00:00.0 Power PC: Freescale Semiconductor Inc MPC8536E (rev 91)
Flags: bus master, 66MHz, fast devsel, latency 128
Memory at <ignored> (32-bit, non-prefetchable)
Memory at <unassigned> (32-bit, prefetchable)
Memory at <unassigned> (64-bit, non-prefetchable)
Memory at <unassigned> (64-bit, non-prefetchable)
0000:00:11.0 Ethernet controller: Intel Corporation 82541PI Gigabit Ethernet Controller (rev 05)
Subsystem: Intel Corporation PRO/1000 GT Desktop Adapter
Flags: bus master, 66MHz, medium devsel, latency 128, IRQ 35
Memory at 80000000 (32-bit, non-prefetchable) [size=128K]
Memory at 80020000 (32-bit, non-prefetchable) [size=128K]
I/O ports at 1000 [size=64]
[virtual] Expansion ROM at 80040000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Capabilities: [e4] PCI-X non-bridge device
Kernel driver in use: e1000
0001:01:00.0 PCI bridge: Freescale Semiconductor Inc MPC8536E (rev 91) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Memory at <ignored> (32-bit, non-prefetchable)
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 00000000-00000fff
Memory behind bridge: 98000000-9fffffff
Capabilities: [44] Power Management version 2
Capabilities: [4c] Express Root Port (Slot-), MSI 00
Capabilities: [100] Advanced Error Reporting
0002:03:00.0 PCI bridge: Freescale Semiconductor Inc MPC8536E (rev 91) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Memory at <ignored> (32-bit, non-prefetchable)
Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
I/O behind bridge: 00000000-00000fff
Memory behind bridge: 90000000-97ffffff
Capabilities: [44] Power Management version 2
Capabilities: [4c] Express Root Port (Slot-), MSI 00
Capabilities: [100] Advanced Error Reporting
0002:04:00.0 Ethernet controller: Intel Corporation 82572EI Gigabit Ethernet Controller (Copper) (rev 06)
Subsystem: Intel Corporation PRO/1000 PT Server Adapter
Flags: bus master, fast devsel, latency 0, IRQ 38
Memory at 90000000 (32-bit, non-prefetchable) [size=128K]
Memory at 90020000 (32-bit, non-prefetchable) [size=128K]
I/O ports at 1000 [disabled] [size=32]
Capabilities: [c8] Power Management version 2
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [e0] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 00-15-17-ff-ff-f0-ad-1f
Kernel driver in use: e1000e
0003:05:00.0 PCI bridge: Freescale Semiconductor Inc MPC8536E (rev 91) (prog-if 00 [Normal decode])
Flags: bus master, fast devsel, latency 0
Memory at <ignored> (32-bit, non-prefetchable)
Bus: primary=00, secondary=06, subordinate=06, sec-latency=0
I/O behind bridge: 00000000-00000fff
Memory behind bridge: a0000000-bfffffff
Capabilities: [44] Power Management version 2
Capabilities: [4c] Express Root Port (Slot-), MSI 00
Capabilities: [100] Advanced Error Reporting
> What
> hardware does seems broken to me (when PCI is configured as a host
> rather than as an endpoint), but so does calling a host bridge a
> PCI-to-PCI bridge, and so does relying on this mess (not that the
> primary-bus hack is much better...).
>
> Note that in the case of PCIe -- but not PCI -- Linux has a quirk
> that relabels the "Processor" on FSL chips as a PCI-to-PCI bridge.
> Despite the "Processor" labelling, Freescale PCIe (but not PCI)
> devices appear to have a type 1 config space layout in host mode.
> I guess this is considered to be the virtual root port.
The resource reassign will occur no matter whether it is a pci or pcie.
All in all the resource starting at 0 is considered a invalid resource
by the ppc kernel and then the kernel will try to reassign it later.
So we really don't have a reason to pick up a pci primary bus on
a board which doesn't have ISA device at all in the current kernel.
Thanks,
Kevin
>
> -Scott
>
> [1] Really, it's the bridge not having any I/O, but this is how an
> I/O base/limit of zero are interpreted.
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH v2] powerpc: Update compilation flags with core specific options
From: Catalin Udma @ 2013-07-25 11:54 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Catalin Udma
If CONFIG_E500 is enabled, the compilation flags are updated
specifying the target core -mcpu=e5500/e500mc/8540
Also remove -Wa,-me500, being incompatible with -mcpu=e5500/e6500
The assembler option is redundant if the -mcpu= flag is set.
The patch fixes the kernel compilation problem for e5500/e6500
when using gcc option -mcpu=e5500/e6500.
Signed-off-by: Catalin Udma <catalin.udma@freescale.com>
---
changes for v2:
- update also KBUILD_AFLAGS with -mcpu and -msoft-float flags
arch/powerpc/Makefile | 16 +++++++++++++++-
1 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index 0624909..cb5cbe2 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -140,6 +140,21 @@ ifeq ($(CONFIG_6xx),y)
KBUILD_CFLAGS += -mcpu=powerpc
endif
+ifeq ($(CONFIG_E500),y)
+ifeq ($(CONFIG_64BIT),y)
+KBUILD_CFLAGS += -mcpu=e5500
+KBUILD_AFLAGS += -mcpu=e5500 -msoft-float
+else
+ifeq ($(CONFIG_PPC_E500MC),y)
+KBUILD_CFLAGS += -mcpu=e500mc
+KBUILD_AFLAGS += -mcpu=e500mc -msoft-float
+else
+KBUILD_CFLAGS += -mcpu=8540
+KBUILD_AFLAGS += -mcpu=8540 -msoft-float
+endif
+endif
+endif
+
# Work around a gcc code-gen bug with -fno-omit-frame-pointer.
ifeq ($(CONFIG_FUNCTION_TRACER),y)
KBUILD_CFLAGS += -mno-sched-epilog
@@ -147,7 +162,6 @@ endif
cpu-as-$(CONFIG_4xx) += -Wa,-m405
cpu-as-$(CONFIG_ALTIVEC) += -Wa,-maltivec
-cpu-as-$(CONFIG_E500) += -Wa,-me500
cpu-as-$(CONFIG_E200) += -Wa,-me200
KBUILD_AFLAGS += $(cpu-as-y)
--
1.7.8
^ permalink raw reply related
* Re: [PATCH] powerpc: Prepare to support kernel handling of IOMMU map/unmap
From: Alexey Kardashevskiy @ 2013-07-25 10:33 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: linux-kernel, linux-mm, Paul Mackerras, Andrew Morton,
linuxppc-dev
In-Reply-To: <1374747961-28501-1-git-send-email-aik@ozlabs.ru>
On 07/25/2013 08:26 PM, Alexey Kardashevskiy wrote:
> The current VFIO-on-POWER implementation supports only user mode
> driven mapping, i.e. QEMU is sending requests to map/unmap pages.
> However this approach is really slow, so we want to move that to KVM.
> Since H_PUT_TCE can be extremely performance sensitive (especially with
> network adapters where each packet needs to be mapped/unmapped) we chose
> to implement that as a "fast" hypercall directly in "real
> mode" (processor still in the guest context but MMU off).
>
> To be able to do that, we need to provide some facilities to
> access the struct page count within that real mode environment as things
> like the sparsemem vmemmap mappings aren't accessible.
>
> This adds an API to get page struct when MMU is off.
>
> This adds to MM a new function put_page_unless_one() which drops a page
> if counter is bigger than 1. It is going to be used when MMU is off
> (real mode on PPC64 is the first user) and we want to make sure that page
> release will not happen in real mode as it may crash the kernel in
> a horrible way.
Yes, my english needs to be polished, I even know where :)
--
Alexey
^ permalink raw reply
* [PATCH] powerpc: Prepare to support kernel handling of IOMMU map/unmap
From: Alexey Kardashevskiy @ 2013-07-25 10:26 UTC (permalink / raw)
To: linuxppc-dev
Cc: Alexey Kardashevskiy, linux-kernel, linux-mm, Paul Mackerras,
Andrew Morton
In-Reply-To: <1374707624.6142.16.camel@pasglop>
The current VFIO-on-POWER implementation supports only user mode
driven mapping, i.e. QEMU is sending requests to map/unmap pages.
However this approach is really slow, so we want to move that to KVM.
Since H_PUT_TCE can be extremely performance sensitive (especially with
network adapters where each packet needs to be mapped/unmapped) we chose
to implement that as a "fast" hypercall directly in "real
mode" (processor still in the guest context but MMU off).
To be able to do that, we need to provide some facilities to
access the struct page count within that real mode environment as things
like the sparsemem vmemmap mappings aren't accessible.
This adds an API to get page struct when MMU is off.
This adds to MM a new function put_page_unless_one() which drops a page
if counter is bigger than 1. It is going to be used when MMU is off
(real mode on PPC64 is the first user) and we want to make sure that page
release will not happen in real mode as it may crash the kernel in
a horrible way.
CONFIG_SPARSEMEM_VMEMMAP and CONFIG_FLATMEM are supported.
Cc: linux-mm@kvack.org
Reviewed-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
2013/07/25:
* removed realmode_put_page and added put_page_unless_one() instead.
The name has been chosen to conform the already existing get_page_unless_zero().
* removed realmode_get_page. Instead, get_page_unless_zero() will be used
* realmode_pfn_to_page fixed to return NULL for compound pages
2013/07/10:
* adjusted comment (removed sentence about virtual mode)
* get_page_unless_zero replaced with atomic_inc_not_zero to minimize
effect of a possible get_page_unless_zero() rework (if it ever happens).
2013/06/27:
* realmode_get_page() fixed to use get_page_unless_zero(). If failed,
the call will be passed from real to virtual mode and safely handled.
* added comment to PageCompound() in include/linux/page-flags.h.
2013/05/20:
* PageTail() is replaced by PageCompound() in order to have the same checks
for whether the page is huge in realmode_get_page() and realmode_put_page()
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
arch/powerpc/include/asm/pgtable-ppc64.h | 2 ++
arch/powerpc/mm/init_64.c | 54 +++++++++++++++++++++++++++++++-
include/linux/mm.h | 14 +++++++++
include/linux/page-flags.h | 4 ++-
4 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc64.h b/arch/powerpc/include/asm/pgtable-ppc64.h
index 46db094..4a191c4 100644
--- a/arch/powerpc/include/asm/pgtable-ppc64.h
+++ b/arch/powerpc/include/asm/pgtable-ppc64.h
@@ -394,6 +394,8 @@ static inline void mark_hpte_slot_valid(unsigned char *hpte_slot_array,
hpte_slot_array[index] = hidx << 4 | 0x1 << 3;
}
+struct page *realmode_pfn_to_page(unsigned long pfn);
+
static inline char *get_hpte_slot_array(pmd_t *pmdp)
{
/*
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index d0cd9e4..d2bb97c 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -300,5 +300,57 @@ void vmemmap_free(unsigned long start, unsigned long end)
{
}
-#endif /* CONFIG_SPARSEMEM_VMEMMAP */
+/*
+ * We do not have access to the sparsemem vmemmap, so we fallback to
+ * walking the list of sparsemem blocks which we already maintain for
+ * the sake of crashdump. In the long run, we might want to maintain
+ * a tree if performance of that linear walk becomes a problem.
+ *
+ * realmode_pfn_to_page functions can fail due to:
+ * 1) As real sparsemem blocks do not lay in RAM continously (they
+ * are in virtual address space which is not available in the real mode),
+ * the requested page struct can be split between blocks so get_page/put_page
+ * may fail.
+ * 2) When huge pages are used, the get_page/put_page API will fail
+ * in real mode as the linked addresses in the page struct are virtual
+ * too.
+ */
+struct page *realmode_pfn_to_page(unsigned long pfn)
+{
+ struct vmemmap_backing *vmem_back;
+ struct page *page;
+ unsigned long page_size = 1 << mmu_psize_defs[mmu_vmemmap_psize].shift;
+ unsigned long pg_va = (unsigned long) pfn_to_page(pfn);
+ for (vmem_back = vmemmap_list; vmem_back; vmem_back = vmem_back->list) {
+ if (pg_va < vmem_back->virt_addr)
+ continue;
+
+ /* Check that page struct is not split between real pages */
+ if ((pg_va + sizeof(struct page)) >
+ (vmem_back->virt_addr + page_size))
+ return NULL;
+
+ page = (struct page *) (vmem_back->phys + pg_va -
+ vmem_back->virt_addr);
+
+ if (PageCompound(page))
+ return NULL;
+
+ return page;
+ }
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(realmode_pfn_to_page);
+
+#elif defined(CONFIG_FLATMEM)
+
+struct page *realmode_pfn_to_page(unsigned long pfn)
+{
+ struct page *page = pfn_to_page(pfn);
+ return page;
+}
+EXPORT_SYMBOL_GPL(realmode_pfn_to_page);
+
+#endif /* CONFIG_SPARSEMEM_VMEMMAP/CONFIG_FLATMEM */
diff --git a/include/linux/mm.h b/include/linux/mm.h
index f022460..ef07aea 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -290,12 +290,26 @@ static inline int put_page_testzero(struct page *page)
/*
* Try to grab a ref unless the page has a refcount of zero, return false if
* that is the case.
+ * This can be called when MMU is off so it must not to access
+ * any of the virtual mappings.
*/
static inline int get_page_unless_zero(struct page *page)
{
return atomic_inc_not_zero(&page->_count);
}
+/*
+ * Try to drop a ref unless the page has a refcount of one, return false if
+ * that is the case.
+ * This is to make sure that the refcount won't become zero after this drop.
+ * This can be called when MMU is off so it must not to access
+ * any of the virtual mappings.
+ */
+static inline int put_page_unless_one(struct page *page)
+{
+ return atomic_add_unless(&page->_count, -1, 1);
+}
+
extern int page_is_ram(unsigned long pfn);
/* Support for virtually mapped pages */
diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
index 6d53675..98ada58 100644
--- a/include/linux/page-flags.h
+++ b/include/linux/page-flags.h
@@ -329,7 +329,9 @@ static inline void set_page_writeback(struct page *page)
* System with lots of page flags available. This allows separate
* flags for PageHead() and PageTail() checks of compound pages so that bit
* tests can be used in performance sensitive paths. PageCompound is
- * generally not used in hot code paths.
+ * generally not used in hot code paths except arch/powerpc/mm/init_64.c
+ * and arch/powerpc/kvm/book3s_64_vio_hv.c which use it to detect huge pages
+ * and avoid handling those in real mode.
*/
__PAGEFLAG(Head, head) CLEARPAGEFLAG(Head, head)
__PAGEFLAG(Tail, tail)
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH 1/4 v6] powerpc: export debug registers save function for KVM
From: Alexander Graf @ 2013-07-25 10:20 UTC (permalink / raw)
To: Bharat Bhushan
Cc: Stephen Rothwell, Michael Neuling, kvm@vger.kernel.org list,
kvm-ppc, Bharat Bhushan, "“tiejun.chen” Chen",
Scott Wood, linuxppc-dev
In-Reply-To: <1372921067-19678-2-git-send-email-Bharat.Bhushan@freescale.com>
On 04.07.2013, at 08:57, Bharat Bhushan wrote:
> KVM need this function when switching from vcpu to user-space
> thread. My subsequent patch will use this function.
>=20
> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
Ben / Michael, please ack.
Alex
> ---
> v5->v6
> - switch_booke_debug_regs() not guarded by the compiler switch
>=20
> arch/powerpc/include/asm/switch_to.h | 1 +
> arch/powerpc/kernel/process.c | 3 ++-
> 2 files changed, 3 insertions(+), 1 deletions(-)
>=20
> diff --git a/arch/powerpc/include/asm/switch_to.h =
b/arch/powerpc/include/asm/switch_to.h
> index 200d763..db68f1d 100644
> --- a/arch/powerpc/include/asm/switch_to.h
> +++ b/arch/powerpc/include/asm/switch_to.h
> @@ -29,6 +29,7 @@ extern void giveup_vsx(struct task_struct *);
> extern void enable_kernel_spe(void);
> extern void giveup_spe(struct task_struct *);
> extern void load_up_spe(struct task_struct *);
> +extern void switch_booke_debug_regs(struct thread_struct =
*new_thread);
>=20
> #ifndef CONFIG_SMP
> extern void discard_lazy_cpu_state(void);
> diff --git a/arch/powerpc/kernel/process.c =
b/arch/powerpc/kernel/process.c
> index 01ff496..da586aa 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -362,12 +362,13 @@ static void prime_debug_regs(struct =
thread_struct *thread)
> * debug registers, set the debug registers from the values
> * stored in the new thread.
> */
> -static void switch_booke_debug_regs(struct thread_struct *new_thread)
> +void switch_booke_debug_regs(struct thread_struct *new_thread)
> {
> if ((current->thread.debug.dbcr0 & DBCR0_IDM)
> || (new_thread->debug.dbcr0 & DBCR0_IDM))
> prime_debug_regs(new_thread);
> }
> +EXPORT_SYMBOL_GPL(switch_booke_debug_regs);
> #else /* !CONFIG_PPC_ADV_DEBUG_REGS */
> #ifndef CONFIG_HAVE_HW_BREAKPOINT
> static void set_debug_reg_defaults(struct thread_struct *thread)
> --=20
> 1.7.0.4
>=20
>=20
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] powerpc: allow kvm to use kerel debug framework
From: Alexander Graf @ 2013-07-25 10:17 UTC (permalink / raw)
To: Michael Neuling
Cc: linux-kernel, Bharat Bhushan, Bharat Bhushan, scottwood,
linuxppc-dev
In-Reply-To: <21895.1373441122@ale.ozlabs.ibm.com>
On 10.07.2013, at 09:25, Michael Neuling wrote:
> Alexander Graf <agraf@suse.de> wrote:
>=20
>>=20
>> On 09.07.2013, at 06:24, Michael Neuling wrote:
>>=20
>>> Alexander Graf <agraf@suse.de> wrote:
>>>=20
>>>>=20
>>>> On 04.07.2013, at 08:15, Bharat Bhushan wrote:
>>>>=20
>>>>> From: Bharat Bhushan <bharat.bhushan@freescale.com>
>>>>>=20
>>>>> This patchset moves the debug registers in a structure, which =
allows
>>>>> kvm to use same structure for debug emulation.
>>>>>=20
>>>>> Note: Earilier a patchset =
"https://lists.ozlabs.org/pipermail/linuxppc-dev/2013-June/108132.html"
>>>>> was sent which is a bunch of six patches. That patchset is divided =
into two parts:
>>>>> 1) powerpc specific changes (These 2 patches are actually have =
those changes)
>>>>> 2) KVM specific changes (will send separate patch on agraf =
repository)
>>>>=20
>>>> Mikey, if you like those could you please apply the into a topic
>>>> branch and get that one merged with Ben? I'd also pull it into my =
tree
>>>> then.
>>>=20
>>> benh would pull these directly. =20
>>>=20
>>> I'll have a chat with him to see if he wants my ACK before he does =
that.
>>=20
>> I have a bunch of patches that I need to apply on top, so I need a =
topic branch.
>=20
> I've acked the PPC specific bits of the v6 version of these patches.
>=20
> benh said he'll open a topic branch for you sometime next week and =
he'll
> stick them in there. =20
Ping? :)
Alex
^ permalink raw reply
* [PATCH] ASoC: fsl: Set sdma peripheral type directly
From: Nicolin Chen @ 2013-07-25 9:41 UTC (permalink / raw)
To: shawn.guo, broonie, timur; +Cc: fabio.estevam, alsa-devel, linuxppc-dev
Let CPU DAI drivers set SDMA periperal type directly to support more
dma types(SPDIF, ESAI) other than only two for SSI.
This will easily allow some non-SSI drivers to use the imx-pcm-dma
as well.
Signed-off-by: Nicolin Chen <b42378@freescale.com>
---
@Timur
Compile-passed with mpc85xx_defconfig by using gcc-4.6.3-nolibc_powerpc-linux.
---
sound/soc/fsl/fsl_ssi.c | 4 ++--
sound/soc/fsl/imx-pcm.h | 7 ++-----
sound/soc/fsl/imx-ssi.c | 4 ++--
3 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/sound/soc/fsl/fsl_ssi.c b/sound/soc/fsl/fsl_ssi.c
index 11469fe..4d78df7 100644
--- a/sound/soc/fsl/fsl_ssi.c
+++ b/sound/soc/fsl/fsl_ssi.c
@@ -775,9 +775,9 @@ static int fsl_ssi_probe(struct platform_device *pdev)
"fsl,spba-bus");
imx_pcm_dma_params_init_data(&ssi_private->filter_data_tx,
- dma_events[0], shared);
+ dma_events[0], shared ? IMX_DMATYPE_SSI_SP : IMX_DMATYPE_SSI);
imx_pcm_dma_params_init_data(&ssi_private->filter_data_rx,
- dma_events[1], shared);
+ dma_events[1], shared ? IMX_DMATYPE_SSI_SP : IMX_DMATYPE_SSI);
}
/* Initialize the the device_attribute structure */
diff --git a/sound/soc/fsl/imx-pcm.h b/sound/soc/fsl/imx-pcm.h
index fd56cad..9136625 100644
--- a/sound/soc/fsl/imx-pcm.h
+++ b/sound/soc/fsl/imx-pcm.h
@@ -22,14 +22,11 @@
static inline void
imx_pcm_dma_params_init_data(struct imx_dma_data *dma_data,
- int dma, bool shared)
+ int dma, enum sdma_peripheral_type peripheral_type)
{
dma_data->dma_request = dma;
dma_data->priority = DMA_PRIO_HIGH;
- if (shared)
- dma_data->peripheral_type = IMX_DMATYPE_SSI_SP;
- else
- dma_data->peripheral_type = IMX_DMATYPE_SSI;
+ dma_data->peripheral_type = peripheral_type;
}
struct imx_pcm_fiq_params {
diff --git a/sound/soc/fsl/imx-ssi.c b/sound/soc/fsl/imx-ssi.c
index f029e27..f58bcd8 100644
--- a/sound/soc/fsl/imx-ssi.c
+++ b/sound/soc/fsl/imx-ssi.c
@@ -571,13 +571,13 @@ static int imx_ssi_probe(struct platform_device *pdev)
res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "tx0");
if (res) {
imx_pcm_dma_params_init_data(&ssi->filter_data_tx, res->start,
- false);
+ IMX_DMATYPE_SSI);
}
res = platform_get_resource_byname(pdev, IORESOURCE_DMA, "rx0");
if (res) {
imx_pcm_dma_params_init_data(&ssi->filter_data_rx, res->start,
- false);
+ IMX_DMATYPE_SSI);
}
platform_set_drvdata(pdev, ssi);
--
1.7.1
^ permalink raw reply related
* [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
From: Preeti U Murthy @ 2013-07-25 9:03 UTC (permalink / raw)
To: benh, paul.gortmaker, paulus, shangw, galak, fweisbec, paulmck,
michael, arnd, linux-pm, rostedt, rjw, john.stultz, tglx,
chenhui.zhao, deepthi, geoff, linux-kernel, srivatsa.bhat,
schwidefsky, svaidy, linuxppc-dev
In-Reply-To: <20130725090016.12500.28888.stgit@preeti.in.ibm.com>
In the current design of timer offload framework, the broadcast cpu should
*not* go into tickless idle so as to avoid missed wakeups on CPUs in deep idle states.
Since we prevent the CPUs entering deep idle states from programming the lapic of the
broadcast cpu for their respective next local events for reasons mentioned in
PATCH[3/5], the broadcast CPU checks if there are any CPUs to be woken up during
each of its timer interrupt programmed to its local events.
With tickless idle, the broadcast CPU might not get a timer interrupt till after
many ticks which can result in missed wakeups on CPUs in deep idle states. By
disabling tickless idle, worst case, the tick_sched hrtimer will trigger a
timer interrupt every period to check for broadcast.
However the current setup of tickless idle does not let us make the choice
of tickless on individual cpus. NOHZ_MODE_INACTIVE which disables tickless idle,
is a system wide setting. Hence resort to an arch specific call to check if a cpu
can go into tickless idle.
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
---
arch/powerpc/kernel/time.c | 5 +++++
kernel/time/tick-sched.c | 7 +++++++
2 files changed, 12 insertions(+)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 8ed0fb3..68a636f 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -862,6 +862,11 @@ static void decrementer_timer_broadcast(const struct cpumask *mask)
arch_send_tick_broadcast(mask);
}
+int arch_can_stop_idle_tick(int cpu)
+{
+ return cpu != bc_cpu;
+}
+
static void register_decrementer_clockevent(int cpu)
{
struct clock_event_device *dec = &per_cpu(decrementers, cpu);
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 6960172..e9ffa84 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -700,8 +700,15 @@ static void tick_nohz_full_stop_tick(struct tick_sched *ts)
#endif
}
+int __weak arch_can_stop_idle_tick(int cpu)
+{
+ return 1;
+}
+
static bool can_stop_idle_tick(int cpu, struct tick_sched *ts)
{
+ if (!arch_can_stop_idle_tick(cpu))
+ return false;
/*
* If this cpu is offline and it is the one which updates
* jiffies, then give up the assignment and let it be taken by
^ permalink raw reply related
* [RFC PATCH 5/5] cpuidle/ppc: Add longnap state to the idle states on powernv
From: Preeti U Murthy @ 2013-07-25 9:03 UTC (permalink / raw)
To: benh, paul.gortmaker, paulus, shangw, galak, fweisbec, paulmck,
michael, arnd, linux-pm, rostedt, rjw, john.stultz, tglx,
chenhui.zhao, deepthi, geoff, linux-kernel, srivatsa.bhat,
schwidefsky, svaidy, linuxppc-dev
In-Reply-To: <20130725090016.12500.28888.stgit@preeti.in.ibm.com>
This patch hooks into the existing broadcast framework with the support that this
patchset introduces for ppc, and the cpuidle driver backend
for powernv(posted out recently by Deepthi Dharwar) to add sleep state as
one of the deep idle states, in which the decrementer is switched off.
However in this patch, we only emulate sleep by going into a state which does
a nap with the decrementer interrupts disabled, termed as longnap. This enables
focus on the timer broadcast framework for ppc in this series of patches ,
which is required as a first step to enable sleep on ppc.
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/processor_idle.c | 48 +++++++++++++++++++++++
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/powernv/processor_idle.c b/arch/powerpc/platforms/powernv/processor_idle.c
index f43ad91a..9aca502 100644
--- a/arch/powerpc/platforms/powernv/processor_idle.c
+++ b/arch/powerpc/platforms/powernv/processor_idle.c
@@ -9,16 +9,18 @@
#include <linux/cpuidle.h>
#include <linux/cpu.h>
#include <linux/notifier.h>
+#include <linux/clockchips.h>
#include <asm/machdep.h>
#include <asm/runlatch.h>
+#include <asm/time.h>
struct cpuidle_driver powernv_idle_driver = {
.name = "powernv_idle",
.owner = THIS_MODULE,
};
-#define MAX_IDLE_STATE_COUNT 2
+#define MAX_IDLE_STATE_COUNT 3
static int max_idle_state = MAX_IDLE_STATE_COUNT - 1;
static struct cpuidle_device __percpu *powernv_cpuidle_devices;
@@ -54,6 +56,43 @@ static int nap_loop(struct cpuidle_device *dev,
return index;
}
+/* Emulate sleep, with long nap.
+ * During sleep, the core does not receive decrementer interrupts.
+ * Emulate sleep using long nap with decrementers interrupts disabled.
+ * This is an initial prototype to test the timer offload framework for ppc.
+ * We will eventually introduce the sleep state once the timer offload framework
+ * for ppc is stable.
+ */
+static int longnap_loop(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ int cpu = dev->cpu;
+
+ unsigned long lpcr = mfspr(SPRN_LPCR);
+
+ lpcr &= ~(LPCR_MER | LPCR_PECE); /* lpcr[mer] must be 0 */
+
+ /* exit powersave upon external interrupt, but not decrementer
+ * interrupt, Emulate sleep.
+ */
+ lpcr |= LPCR_PECE0;
+
+ if (cpu != bc_cpu) {
+ mtspr(SPRN_LPCR, lpcr);
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ENTER, &cpu);
+ power7_nap();
+ clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_EXIT, &cpu);
+ } else {
+ /* Wakeup on a decrementer interrupt, Do a nap */
+ lpcr |= LPCR_PECE1;
+ mtspr(SPRN_LPCR, lpcr);
+ power7_nap();
+ }
+
+ return index;
+}
+
/*
* States for dedicated partition case.
*/
@@ -72,6 +111,13 @@ static struct cpuidle_state powernv_states[MAX_IDLE_STATE_COUNT] = {
.exit_latency = 10,
.target_residency = 100,
.enter = &nap_loop },
+ { /* LongNap */
+ .name = "LongNap",
+ .desc = "LongNap",
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .exit_latency = 10,
+ .target_residency = 100,
+ .enter = &longnap_loop },
};
static int powernv_cpuidle_add_cpu_notifier(struct notifier_block *n,
^ permalink raw reply related
* [RFC PATCH 3/5] cpuidle/ppc: Add timer offload framework to support deep idle states
From: Preeti U Murthy @ 2013-07-25 9:02 UTC (permalink / raw)
To: benh, paul.gortmaker, paulus, shangw, galak, fweisbec, paulmck,
michael, arnd, linux-pm, rostedt, rjw, john.stultz, tglx,
chenhui.zhao, deepthi, geoff, linux-kernel, srivatsa.bhat,
schwidefsky, svaidy, linuxppc-dev
In-Reply-To: <20130725090016.12500.28888.stgit@preeti.in.ibm.com>
On ppc, in deep idle states, the lapic of the cpus gets switched off.
Hence make use of the broadcast framework to wakeup cpus in sleep state,
except that on ppc, we do not have an external device such as HPET, but
we use the lapic of a cpu itself as the broadcast device.
Instantiate two different clock event devices, one representing the
lapic and another representing the broadcast device for each cpu.
Such a cpu is forbidden to enter the deep idle state. The cpu which hosts
the broadcast device will be referred to as the broadcast cpu in the
changelogs of this patchset for convenience.
For now, only the boot cpu's broadcast device gets registered as a clock event
device along with the lapic. Hence this is the broadcast cpu.
On the broadcast cpu, on each timer interrupt, apart from the regular lapic event
handler the broadcast handler is also called. We avoid the overhead of
programming the lapic for a broadcast event specifically. The reason is
prevent multiple cpus from sending IPIs to program the lapic of the broadcast
cpu for their next local event each time they go to deep idle state.
Apart from this there is no change in the way broadcast is handled today. On
a broadcast ipi the event handler for a timer interrupt is called on the cpu
in deep idle state to handle the local events.
The current design and implementation of the timer offload framework supports
the ONESHOT tick mode but not the PERIODIC mode.
Signed-off-by: Preeti U. Murthy <preeti@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/time.h | 3 +
arch/powerpc/kernel/smp.c | 4 +-
arch/powerpc/kernel/time.c | 79 ++++++++++++++++++++++++++++++++
arch/powerpc/platforms/powernv/Kconfig | 1
4 files changed, 84 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/time.h b/arch/powerpc/include/asm/time.h
index c1f2676..936be0d 100644
--- a/arch/powerpc/include/asm/time.h
+++ b/arch/powerpc/include/asm/time.h
@@ -24,14 +24,17 @@ extern unsigned long tb_ticks_per_jiffy;
extern unsigned long tb_ticks_per_usec;
extern unsigned long tb_ticks_per_sec;
extern struct clock_event_device decrementer_clockevent;
+extern struct clock_event_device broadcast_clockevent;
struct rtc_time;
extern void to_tm(int tim, struct rtc_time * tm);
extern void GregorianDay(struct rtc_time *tm);
+extern void decrementer_timer_interrupt(void);
extern void generic_calibrate_decr(void);
extern void set_dec_cpu6(unsigned int val);
+extern int bc_cpu;
/* Some sane defaults: 125 MHz timebase, 1GHz processor */
extern unsigned long ppc_proc_freq;
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 6a68ca4..d3b7014 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -114,7 +114,7 @@ int smp_generic_kick_cpu(int nr)
static irqreturn_t timer_action(int irq, void *data)
{
- timer_interrupt();
+ decrementer_timer_interrupt();
return IRQ_HANDLED;
}
@@ -223,7 +223,7 @@ irqreturn_t smp_ipi_demux(void)
#ifdef __BIG_ENDIAN
if (all & (1 << (24 - 8 * PPC_MSG_TIMER)))
- timer_interrupt();
+ decrementer_timer_interrupt();
if (all & (1 << (24 - 8 * PPC_MSG_RESCHEDULE)))
scheduler_ipi();
if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 65ab9e9..8ed0fb3 100644
--- a/arch/powerpc/kernel/time.c
+++ b/arch/powerpc/kernel/time.c
@@ -42,6 +42,7 @@
#include <linux/timex.h>
#include <linux/kernel_stat.h>
#include <linux/time.h>
+#include <linux/timer.h>
#include <linux/init.h>
#include <linux/profile.h>
#include <linux/cpu.h>
@@ -97,8 +98,11 @@ static struct clocksource clocksource_timebase = {
static int decrementer_set_next_event(unsigned long evt,
struct clock_event_device *dev);
+static int broadcast_set_next_event(unsigned long evt,
+ struct clock_event_device *dev);
static void decrementer_set_mode(enum clock_event_mode mode,
struct clock_event_device *dev);
+static void decrementer_timer_broadcast(const struct cpumask *mask);
struct clock_event_device decrementer_clockevent = {
.name = "decrementer",
@@ -106,13 +110,26 @@ struct clock_event_device decrementer_clockevent = {
.irq = 0,
.set_next_event = decrementer_set_next_event,
.set_mode = decrementer_set_mode,
- .features = CLOCK_EVT_FEAT_ONESHOT,
+ .broadcast = decrementer_timer_broadcast,
+ .features = CLOCK_EVT_FEAT_C3STOP | CLOCK_EVT_FEAT_ONESHOT,
};
EXPORT_SYMBOL(decrementer_clockevent);
+struct clock_event_device broadcast_clockevent = {
+ .name = "broadcast",
+ .rating = 200,
+ .irq = 0,
+ .set_next_event = broadcast_set_next_event,
+ .set_mode = decrementer_set_mode,
+ .features = CLOCK_EVT_FEAT_ONESHOT,
+};
+EXPORT_SYMBOL(broadcast_clockevent);
+
DEFINE_PER_CPU(u64, decrementers_next_tb);
static DEFINE_PER_CPU(struct clock_event_device, decrementers);
+static DEFINE_PER_CPU(struct clock_event_device, bc_timer);
+int bc_cpu;
#define XSEC_PER_SEC (1024*1024)
#ifdef CONFIG_PPC64
@@ -487,6 +504,8 @@ void timer_interrupt(struct pt_regs * regs)
struct pt_regs *old_regs;
u64 *next_tb = &__get_cpu_var(decrementers_next_tb);
struct clock_event_device *evt = &__get_cpu_var(decrementers);
+ struct clock_event_device *bc_evt = &__get_cpu_var(bc_timer);
+ int cpu = smp_processor_id();
u64 now;
/* Ensure a positive value is written to the decrementer, or else
@@ -532,6 +551,10 @@ void timer_interrupt(struct pt_regs * regs)
*next_tb = ~(u64)0;
if (evt->event_handler)
evt->event_handler(evt);
+ if (cpu == bc_cpu && bc_evt->event_handler) {
+ bc_evt->event_handler(bc_evt);
+ }
+
} else {
now = *next_tb - now;
if (now <= DECREMENTER_MAX)
@@ -806,6 +829,18 @@ static int decrementer_set_next_event(unsigned long evt,
return 0;
}
+/*
+ * We cannot program the decrementer of a remote CPU. Hence CPUs going into
+ * deep idle states need to send IPIs to the broadcast CPU to program its
+ * decrementer for their next local event so as to receive a broadcast IPI
+ * for the same. In order to avoid this overhead, this function is a nop.
+ */
+static int broadcast_set_next_event(unsigned long evt,
+ struct clock_event_device *dev)
+{
+ return 0;
+}
+
static void decrementer_set_mode(enum clock_event_mode mode,
struct clock_event_device *dev)
{
@@ -813,6 +848,20 @@ static void decrementer_set_mode(enum clock_event_mode mode,
decrementer_set_next_event(DECREMENTER_MAX, dev);
}
+void decrementer_timer_interrupt(void)
+{
+ struct clock_event_device *evt;
+ evt = &per_cpu(decrementers, smp_processor_id());
+
+ if (evt->event_handler)
+ evt->event_handler(evt);
+}
+
+static void decrementer_timer_broadcast(const struct cpumask *mask)
+{
+ arch_send_tick_broadcast(mask);
+}
+
static void register_decrementer_clockevent(int cpu)
{
struct clock_event_device *dec = &per_cpu(decrementers, cpu);
@@ -826,6 +875,20 @@ static void register_decrementer_clockevent(int cpu)
clockevents_register_device(dec);
}
+static void register_broadcast_clockevent(int cpu)
+{
+ struct clock_event_device *bc_evt = &per_cpu(bc_timer, cpu);
+
+ *bc_evt = broadcast_clockevent;
+ bc_evt->cpumask = cpumask_of(cpu);
+
+ printk_once(KERN_DEBUG "clockevent: %s mult[%x] shift[%d] cpu[%d]\n",
+ bc_evt->name, bc_evt->mult, bc_evt->shift, cpu);
+
+ clockevents_register_device(bc_evt);
+ bc_cpu = cpu;
+}
+
static void __init init_decrementer_clockevent(void)
{
int cpu = smp_processor_id();
@@ -840,6 +903,19 @@ static void __init init_decrementer_clockevent(void)
register_decrementer_clockevent(cpu);
}
+static void __init init_broadcast_clockevent(void)
+{
+ int cpu = smp_processor_id();
+
+ clockevents_calc_mult_shift(&broadcast_clockevent, ppc_tb_freq, 4);
+
+ broadcast_clockevent.max_delta_ns =
+ clockevent_delta2ns(DECREMENTER_MAX, &broadcast_clockevent);
+ broadcast_clockevent.min_delta_ns =
+ clockevent_delta2ns(2, &broadcast_clockevent);
+ register_broadcast_clockevent(cpu);
+}
+
void secondary_cpu_time_init(void)
{
/* Start the decrementer on CPUs that have manual control
@@ -916,6 +992,7 @@ void __init time_init(void)
clocksource_init();
init_decrementer_clockevent();
+ init_broadcast_clockevent();
}
diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig
index ace2d22..e1a96eb 100644
--- a/arch/powerpc/platforms/powernv/Kconfig
+++ b/arch/powerpc/platforms/powernv/Kconfig
@@ -6,6 +6,7 @@ config PPC_POWERNV
select PPC_ICP_NATIVE
select PPC_P7_NAP
select PPC_PCI_CHOICE if EMBEDDED
+ select GENERIC_CLOCKEVENTS_BROADCAST
select EPAPR_BOOT
default y
^ permalink raw reply related
* [RFC PATCH 2/5] powerpc: Implement broadcast timer interrupt as an IPI message
From: Preeti U Murthy @ 2013-07-25 9:02 UTC (permalink / raw)
To: benh, paul.gortmaker, paulus, shangw, galak, fweisbec, paulmck,
michael, arnd, linux-pm, rostedt, rjw, john.stultz, tglx,
chenhui.zhao, deepthi, geoff, linux-kernel, srivatsa.bhat,
schwidefsky, svaidy, linuxppc-dev
In-Reply-To: <20130725090016.12500.28888.stgit@preeti.in.ibm.com>
From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
For scalability and performance reasons, we want the broadcast timer
interrupts to be handled as efficiently as possible. Fixed IPI messages
are one of the most efficient mechanisms available - they are faster
than the smp_call_function mechanism because the IPI handlers are fixed
and hence they don't involve costly operations such as adding IPI handlers
to the target CPU's function queue, acquiring locks for synchronization etc.
Luckily we have an unused IPI message slot, so use that to implement
broadcast timer interrupts efficiently.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/smp.h | 3 ++-
arch/powerpc/kernel/smp.c | 19 +++++++++++++++----
arch/powerpc/platforms/cell/interrupt.c | 2 +-
arch/powerpc/platforms/ps3/smp.c | 2 +-
4 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 51bf017..d877b69 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -117,7 +117,7 @@ extern int cpu_to_core_id(int cpu);
*
* Make sure this matches openpic_request_IPIs in open_pic.c, or what shows up
* in /proc/interrupts will be wrong!!! --Troy */
-#define PPC_MSG_UNUSED 0
+#define PPC_MSG_TIMER 0
#define PPC_MSG_RESCHEDULE 1
#define PPC_MSG_CALL_FUNC_SINGLE 2
#define PPC_MSG_DEBUGGER_BREAK 3
@@ -190,6 +190,7 @@ extern struct smp_ops_t *smp_ops;
extern void arch_send_call_function_single_ipi(int cpu);
extern void arch_send_call_function_ipi_mask(const struct cpumask *mask);
+extern void arch_send_tick_broadcast(const struct cpumask *mask);
/* Definitions relative to the secondary CPU spin loop
* and entry point. Not all of them exist on both 32 and
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index bc41e9f..6a68ca4 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -35,6 +35,7 @@
#include <asm/ptrace.h>
#include <linux/atomic.h>
#include <asm/irq.h>
+#include <asm/hw_irq.h>
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/prom.h>
@@ -111,9 +112,9 @@ int smp_generic_kick_cpu(int nr)
}
#endif /* CONFIG_PPC64 */
-static irqreturn_t unused_action(int irq, void *data)
+static irqreturn_t timer_action(int irq, void *data)
{
- /* This slot is unused and hence available for use, if needed */
+ timer_interrupt();
return IRQ_HANDLED;
}
@@ -144,14 +145,14 @@ static irqreturn_t debug_ipi_action(int irq, void *data)
}
static irq_handler_t smp_ipi_action[] = {
- [PPC_MSG_UNUSED] = unused_action, /* Slot available for future use */
+ [PPC_MSG_TIMER] = timer_action,
[PPC_MSG_RESCHEDULE] = reschedule_action,
[PPC_MSG_CALL_FUNC_SINGLE] = call_function_single_action,
[PPC_MSG_DEBUGGER_BREAK] = debug_ipi_action,
};
const char *smp_ipi_name[] = {
- [PPC_MSG_UNUSED] = "ipi unused",
+ [PPC_MSG_TIMER] = "ipi timer",
[PPC_MSG_RESCHEDULE] = "ipi reschedule",
[PPC_MSG_CALL_FUNC_SINGLE] = "ipi call function single",
[PPC_MSG_DEBUGGER_BREAK] = "ipi debugger",
@@ -221,6 +222,8 @@ irqreturn_t smp_ipi_demux(void)
all = xchg(&info->messages, 0);
#ifdef __BIG_ENDIAN
+ if (all & (1 << (24 - 8 * PPC_MSG_TIMER)))
+ timer_interrupt();
if (all & (1 << (24 - 8 * PPC_MSG_RESCHEDULE)))
scheduler_ipi();
if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
@@ -266,6 +269,14 @@ void arch_send_call_function_ipi_mask(const struct cpumask *mask)
do_message_pass(cpu, PPC_MSG_CALL_FUNC_SINGLE);
}
+void arch_send_tick_broadcast(const struct cpumask *mask)
+{
+ unsigned int cpu;
+
+ for_each_cpu(cpu, mask)
+ do_message_pass(cpu, PPC_MSG_TIMER);
+}
+
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
void smp_send_debugger_break(void)
{
diff --git a/arch/powerpc/platforms/cell/interrupt.c b/arch/powerpc/platforms/cell/interrupt.c
index 28166e4..1359113 100644
--- a/arch/powerpc/platforms/cell/interrupt.c
+++ b/arch/powerpc/platforms/cell/interrupt.c
@@ -213,7 +213,7 @@ static void iic_request_ipi(int msg)
void iic_request_IPIs(void)
{
- iic_request_ipi(PPC_MSG_UNUSED);
+ iic_request_ipi(PPC_MSG_TIMER);
iic_request_ipi(PPC_MSG_RESCHEDULE);
iic_request_ipi(PPC_MSG_CALL_FUNC_SINGLE);
iic_request_ipi(PPC_MSG_DEBUGGER_BREAK);
diff --git a/arch/powerpc/platforms/ps3/smp.c b/arch/powerpc/platforms/ps3/smp.c
index 488f069..5cb742a 100644
--- a/arch/powerpc/platforms/ps3/smp.c
+++ b/arch/powerpc/platforms/ps3/smp.c
@@ -74,7 +74,7 @@ static int __init ps3_smp_probe(void)
* to index needs to be setup.
*/
- BUILD_BUG_ON(PPC_MSG_UNUSED != 0);
+ BUILD_BUG_ON(PPC_MSG_TIMER != 0);
BUILD_BUG_ON(PPC_MSG_RESCHEDULE != 1);
BUILD_BUG_ON(PPC_MSG_CALL_FUNC_SINGLE != 2);
BUILD_BUG_ON(PPC_MSG_DEBUGGER_BREAK != 3);
^ permalink raw reply related
* [RFC PATCH 0/5] cpuidle/ppc: Timer offload framework to support deep idle states
From: Preeti U Murthy @ 2013-07-25 9:02 UTC (permalink / raw)
To: benh, paul.gortmaker, paulus, shangw, galak, fweisbec, paulmck,
michael, arnd, linux-pm, rostedt, rjw, john.stultz, tglx,
chenhui.zhao, deepthi, geoff, linux-kernel, srivatsa.bhat,
schwidefsky, svaidy, linuxppc-dev
On PowerPC, when CPUs enter deep idle states, their local timers are
switched off. The responsibility of waking them up at their next timer event,
needs to be handed over to an external device. On PowerPC, we do not have an
external device equivalent to HPET, which is currently done on architectures
like x86. Instead we assign the local timer of one of the CPUs to do this job.
This patchset is an attempt to make use of the existing timer broadcast
framework in the kernel to meet the above requirement, except that the tick
broadcast device is the local timer of the boot CPU.
This patch series is ported ontop of 3.11-rc1 + the cpuidle driver backend
for powernv posted by Deepthi Dharwar recently. The current design and
implementation supports the ONESHOT tick mode. It does not yet support
the PERIODIC tick mode. This patch is tested with NOHZ_FULL off.
Patch[1/5], Patch[2/5]: optimize the broadcast mechanism on ppc.
Patch[3/5]: Introduces the core of the timer offload framework on powerpc.
Patch[4/5]: The cpu doing the broadcast should not go into tickless idle.
Patch[5/5]: Add a deep idle state to the cpuidle state table on powernv.
Patch[5/5] is the patch that ultimately makes use of the timer offload
framework that the patches Patch[1/5] to Patch[4/5] build.
---
Preeti U Murthy (3):
cpuidle/ppc: Add timer offload framework to support deep idle states
cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints
cpuidle/ppc: Add longnap state to the idle states on powernv
Srivatsa S. Bhat (2):
powerpc: Free up the IPI message slot of ipi call function (PPC_MSG_CALL_FUNC)
powerpc: Implement broadcast timer interrupt as an IPI message
arch/powerpc/include/asm/smp.h | 3 +
arch/powerpc/include/asm/time.h | 3 +
arch/powerpc/kernel/smp.c | 23 ++++--
arch/powerpc/kernel/time.c | 84 +++++++++++++++++++++++
arch/powerpc/platforms/cell/interrupt.c | 2 -
arch/powerpc/platforms/powernv/Kconfig | 1
arch/powerpc/platforms/powernv/processor_idle.c | 48 +++++++++++++
arch/powerpc/platforms/ps3/smp.c | 2 -
kernel/time/tick-sched.c | 7 ++
9 files changed, 161 insertions(+), 12 deletions(-)
--
Signature
^ permalink raw reply
* [RFC PATCH 1/5] powerpc: Free up the IPI message slot of ipi call function (PPC_MSG_CALL_FUNC)
From: Preeti U Murthy @ 2013-07-25 9:02 UTC (permalink / raw)
To: benh, paul.gortmaker, paulus, shangw, galak, fweisbec, paulmck,
michael, arnd, linux-pm, rostedt, rjw, john.stultz, tglx,
chenhui.zhao, deepthi, geoff, linux-kernel, srivatsa.bhat,
schwidefsky, svaidy, linuxppc-dev
In-Reply-To: <20130725090016.12500.28888.stgit@preeti.in.ibm.com>
From: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
The IPI handlers for both PPC_MSG_CALL_FUNC and PPC_MSG_CALL_FUNC_SINGLE
map to a common implementation - generic_smp_call_function_single_interrupt().
So, we can consolidate them and save one of the IPI message slots, (which are
precious, since only 4 of those slots are available).
So, implement the functionality of PPC_MSG_CALL_FUNC using
PPC_MSG_CALL_FUNC_SINGLE itself and release its IPI message slot, so that it
can be used for something else in the future, if desired.
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Signed-off-by: Preeti U Murthy <preeti@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/smp.h | 2 +-
arch/powerpc/kernel/smp.c | 12 +++++-------
arch/powerpc/platforms/cell/interrupt.c | 2 +-
arch/powerpc/platforms/ps3/smp.c | 2 +-
4 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index ffbaabe..51bf017 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -117,7 +117,7 @@ extern int cpu_to_core_id(int cpu);
*
* Make sure this matches openpic_request_IPIs in open_pic.c, or what shows up
* in /proc/interrupts will be wrong!!! --Troy */
-#define PPC_MSG_CALL_FUNCTION 0
+#define PPC_MSG_UNUSED 0
#define PPC_MSG_RESCHEDULE 1
#define PPC_MSG_CALL_FUNC_SINGLE 2
#define PPC_MSG_DEBUGGER_BREAK 3
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 38b0ba6..bc41e9f 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -111,9 +111,9 @@ int smp_generic_kick_cpu(int nr)
}
#endif /* CONFIG_PPC64 */
-static irqreturn_t call_function_action(int irq, void *data)
+static irqreturn_t unused_action(int irq, void *data)
{
- generic_smp_call_function_interrupt();
+ /* This slot is unused and hence available for use, if needed */
return IRQ_HANDLED;
}
@@ -144,14 +144,14 @@ static irqreturn_t debug_ipi_action(int irq, void *data)
}
static irq_handler_t smp_ipi_action[] = {
- [PPC_MSG_CALL_FUNCTION] = call_function_action,
+ [PPC_MSG_UNUSED] = unused_action, /* Slot available for future use */
[PPC_MSG_RESCHEDULE] = reschedule_action,
[PPC_MSG_CALL_FUNC_SINGLE] = call_function_single_action,
[PPC_MSG_DEBUGGER_BREAK] = debug_ipi_action,
};
const char *smp_ipi_name[] = {
- [PPC_MSG_CALL_FUNCTION] = "ipi call function",
+ [PPC_MSG_UNUSED] = "ipi unused",
[PPC_MSG_RESCHEDULE] = "ipi reschedule",
[PPC_MSG_CALL_FUNC_SINGLE] = "ipi call function single",
[PPC_MSG_DEBUGGER_BREAK] = "ipi debugger",
@@ -221,8 +221,6 @@ irqreturn_t smp_ipi_demux(void)
all = xchg(&info->messages, 0);
#ifdef __BIG_ENDIAN
- if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNCTION)))
- generic_smp_call_function_interrupt();
if (all & (1 << (24 - 8 * PPC_MSG_RESCHEDULE)))
scheduler_ipi();
if (all & (1 << (24 - 8 * PPC_MSG_CALL_FUNC_SINGLE)))
@@ -265,7 +263,7 @@ void arch_send_call_function_ipi_mask(const struct cpumask *mask)
unsigned int cpu;
for_each_cpu(cpu, mask)
- do_message_pass(cpu, PPC_MSG_CALL_FUNCTION);
+ do_message_pass(cpu, PPC_MSG_CALL_FUNC_SINGLE);
}
#if defined(CONFIG_DEBUGGER) || defined(CONFIG_KEXEC)
diff --git a/arch/powerpc/platforms/cell/interrupt.c b/arch/powerpc/platforms/cell/interrupt.c
index 2d42f3b..28166e4 100644
--- a/arch/powerpc/platforms/cell/interrupt.c
+++ b/arch/powerpc/platforms/cell/interrupt.c
@@ -213,7 +213,7 @@ static void iic_request_ipi(int msg)
void iic_request_IPIs(void)
{
- iic_request_ipi(PPC_MSG_CALL_FUNCTION);
+ iic_request_ipi(PPC_MSG_UNUSED);
iic_request_ipi(PPC_MSG_RESCHEDULE);
iic_request_ipi(PPC_MSG_CALL_FUNC_SINGLE);
iic_request_ipi(PPC_MSG_DEBUGGER_BREAK);
diff --git a/arch/powerpc/platforms/ps3/smp.c b/arch/powerpc/platforms/ps3/smp.c
index 4b35166..488f069 100644
--- a/arch/powerpc/platforms/ps3/smp.c
+++ b/arch/powerpc/platforms/ps3/smp.c
@@ -74,7 +74,7 @@ static int __init ps3_smp_probe(void)
* to index needs to be setup.
*/
- BUILD_BUG_ON(PPC_MSG_CALL_FUNCTION != 0);
+ BUILD_BUG_ON(PPC_MSG_UNUSED != 0);
BUILD_BUG_ON(PPC_MSG_RESCHEDULE != 1);
BUILD_BUG_ON(PPC_MSG_CALL_FUNC_SINGLE != 2);
BUILD_BUG_ON(PPC_MSG_DEBUGGER_BREAK != 3);
^ permalink raw reply related
* Re: [PATCH 2/2] kvm: powerpc: set cache coherency only for kernel managed pages
From: Gleb Natapov @ 2013-07-25 8:50 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, kvm@vger.kernel.org list, Alexander Graf,
kvm-ppc@vger.kernel.org, “tiejun.chen”,
Bhushan Bharat-R65777, Paolo Bonzini, linuxppc-dev
In-Reply-To: <1374697969.15592.67@snotra>
On Wed, Jul 24, 2013 at 03:32:49PM -0500, Scott Wood wrote:
> On 07/24/2013 04:39:59 AM, Alexander Graf wrote:
> >
> >On 24.07.2013, at 11:35, Gleb Natapov wrote:
> >
> >> On Wed, Jul 24, 2013 at 11:21:11AM +0200, Alexander Graf wrote:
> >>>> Are not we going to use page_is_ram() from
> >e500_shadow_mas2_attrib() as Scott commented?
> >>>
> >>> rWhy aren't we using page_is_ram() in kvm_is_mmio_pfn()?
> >>>
> >>>
> >> Because it is much slower and, IIRC, actually used to build pfn
> >map that allow
> >> us to check quickly for valid pfn.
> >
> >Then why should we use page_is_ram()? :)
> >
> >I really don't want the e500 code to diverge too much from what
> >the rest of the kvm code is doing.
>
> I don't understand "actually used to build pfn map...". What code
> is this? I don't see any calls to page_is_ram() in the KVM code, or
> in generic mm code. Is this a statement about what x86 does?
It may be not page_is_ram() directly, but the same into page_is_ram() is
using. On power both page_is_ram() and do_init_bootmem() walks some kind
of memblock_region data structure. What important is that pfn_valid()
does not mean that there is a memory behind page structure. See Andrea's
reply.
>
> On PPC page_is_ram() is only called (AFAICT) for determining what
> attributes to set on mmaps. We want to be sure that KVM always
> makes the same decision. While pfn_valid() seems like it should be
> equivalent, it's not obvious from the PPC code that it is.
>
Again pfn_valid() is not enough.
> If pfn_valid() is better, why is that not used for mmap? Why are
> there two different names for the same thing?
>
They are not the same thing. page_is_ram() tells you if phys address is
ram backed. pfn_valid() tells you if there is struct page behind the
pfn. PageReserved() tells if you a pfn is marked as reserved. All non
ram pfns should be reserved, but ram pfns can be reserved too. Again,
see Andrea's reply.
Why ppc uses page_is_ram() for mmap? How should I know? But looking at
the function it does it only as a fallback if
ppc_md.phys_mem_access_prot() is not provided. Making access to MMIO
noncached as a safe fallback makes sense. It is also make sense to allow
noncached access to reserved ram sometimes.
--
Gleb.
^ permalink raw reply
* P1021rdb-pc
From: BHARATHI KANDIMALLA @ 2013-07-25 8:29 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
[-- Attachment #1: Type: text/plain, Size: 2680 bytes --]
Dear Sir,
We are using P1021rdb-pc board with p1021 processor.
1. compilation and build process is taking so much of time. How should I
reduce the time for linux build process?
2. In kernel configuration we are not able to select P1021rdb., When we configured the board for p1021RDB-PC , in default kenel config file all the below platforms are selected , We want only p1021rdb , what should we select here?
CONFIG_PPC_CELL is not set
CONFIG_FSL_SOC_BOOKE=y
CONFIG_FSL_85XX_CACHE_SRAM=y
CONFIG_MPC8540_ADS=y
CONFIG_MPC8560_ADS=y
CONFIG_MPC85xx_CDS=y
CONFIG_MPC85xx_MDS=y
CONFIG_MPC8536_DS=y
CONFIG_MPC85xx_DS=y
CONFIG_MPC85xx_RDB=y
# CONFIG_P1010_RDB is not set
CONFIG_P1022_DS=y
CONFIG_P1023_RDS=y
CONFIG_SOCRATES=y
CONFIG_KSI8560=y
CONFIG_XES_MPC85xx=y
CONFIG_STX_GP3=y
CONFIG_TQM8540=y
CONFIG_TQM8541=y
CONFIG_TQM8548=y
CONFIG_TQM8555=y
CONFIG_TQM8560=y
CONFIG_SBC8548=y
I am attaching .config file for the reference
3. We are using p1021 processor which has 36 bit support , but we have compiled uboot for 32 bit only.Is there any specfic use of 36 bit compilation, ?
only large amount of memory size 0f 64G, any way we are using only 512Mbyte of DDR, 128MBYte NOR FLASH
4. Now we are using SDK 1.3.2 for p1021 procesor .Is there any specific
necessity that we should switch to sdk1.4
regarding linux drivers specially included for p1021 procesor?
5.UMCC driver is available in linux driver ? where should I get some help regarding UMCC ?
regards
Bharathi kandimalla
P.S. - Please Note our New Corporate office Address:-
ICOMM House,
Plot No.31, Kamalapuri,
Srinagar Colony, Banjara Hills,
Hyderabad - 500073, INDIA.
Disclaimer
This email is confidential. If you are not the addressee tell the sender immediately and destroy this email without using, sending or storing it. E-mail transmission cannot be secure as information could be intercepted, corrupted, lost, destroyed, delay, interception, amendment or incomplete, or contain viruses. ICOMM TELE LTD and subsidiaries ("ICOMM") do not accept liability for damage caused by this email and may monitor email traffic. Unless expressly stated, any opinions are the sender's and are not approved by ICOMM and this email is not an offer, solicitation, recommendation or agreement of any kind. If verification is required please request a hard-copy version. ICOMM's corporate office is ICOMM House, Plot No.31, Kamalapuri, Srinagar Colony, Banjara Hills, Hyderabad - 500073 INDIA. Ph. No. : +91-40-2355-2222. Fax. No. : +91-40-2355-2266.
Thank You
ICOMM<http://www.icommtele.com>
[-- Attachment #2: Type: text/html, Size: 4590 bytes --]
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Chen Gang @ 2013-07-25 8:36 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1374740911.6142.70.camel@pasglop>
On 07/25/2013 04:28 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 16:22 +0800, Chen Gang wrote:
>> > On 07/25/2013 04:06 PM, Benjamin Herrenschmidt wrote:
>>> > > On Thu, 2013-07-25 at 15:59 +0800, Chen Gang wrote:
>>>> > >>
>>>> > >> For my opinion: one fix may like below (assume have removed max_cpus)
>>>> > >> which is more reasonable for code readers.
>>> > >
>>> > > So instead of just failing to bring the secondary CPUs, but potentially
>>> > > still having a working system, you crash during boot.... potentially
>>> > > before a console is even visible. And this is good how ?
>>> > >
>> >
>> > Hmm... how about the above DBG("...") within this function ?
>> >
>> > One implementation of BUG_ON() is use printk() and coredump, if it is a
>> > critical failure, I suggest to use it (if console is really invisible, I
>> > guess still can generate the coredump).
> Whatever ... looks like you don't feel like listening so I'm not going
> to waste my breath anymore, nor will I accept your patches.
I can understand,
But 'patch' or 'patches' ? ;-)
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Benjamin Herrenschmidt @ 2013-07-25 8:28 UTC (permalink / raw)
To: Chen Gang
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <51F0E037.1080609@asianux.com>
On Thu, 2013-07-25 at 16:22 +0800, Chen Gang wrote:
> On 07/25/2013 04:06 PM, Benjamin Herrenschmidt wrote:
> > On Thu, 2013-07-25 at 15:59 +0800, Chen Gang wrote:
> >>
> >> For my opinion: one fix may like below (assume have removed max_cpus)
> >> which is more reasonable for code readers.
> >
> > So instead of just failing to bring the secondary CPUs, but potentially
> > still having a working system, you crash during boot.... potentially
> > before a console is even visible. And this is good how ?
> >
>
> Hmm... how about the above DBG("...") within this function ?
>
> One implementation of BUG_ON() is use printk() and coredump, if it is a
> critical failure, I suggest to use it (if console is really invisible, I
> guess still can generate the coredump).
Whatever ... looks like you don't feel like listening so I'm not going
to waste my breath anymore, nor will I accept your patches.
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Chen Gang @ 2013-07-25 8:22 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1374739597.6142.68.camel@pasglop>
On 07/25/2013 04:06 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 15:59 +0800, Chen Gang wrote:
>>
>> For my opinion: one fix may like below (assume have removed max_cpus)
>> which is more reasonable for code readers.
>
> So instead of just failing to bring the secondary CPUs, but potentially
> still having a working system, you crash during boot.... potentially
> before a console is even visible. And this is good how ?
>
Hmm... how about the above DBG("...") within this function ?
One implementation of BUG_ON() is use printk() and coredump, if it is a
critical failure, I suggest to use it (if console is really invisible, I
guess still can generate the coredump).
Hmm... But do you mean it really can be failed, but it is not a critical
failure ? if so we need print the related warning message instead of.
Thanks.
--
Chen Gang
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Benjamin Herrenschmidt @ 2013-07-25 8:06 UTC (permalink / raw)
To: Chen Gang
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <51F0DAF1.9060702@asianux.com>
On Thu, 2013-07-25 at 15:59 +0800, Chen Gang wrote:
>
> For my opinion: one fix may like below (assume have removed max_cpus)
> which is more reasonable for code readers.
So instead of just failing to bring the secondary CPUs, but potentially
still having a working system, you crash during boot.... potentially
before a console is even visible. And this is good how ?
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Chen Gang @ 2013-07-25 7:59 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1374737592.6142.67.camel@pasglop>
On 07/25/2013 03:33 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 14:17 +0800, Chen Gang wrote:
>> >
>> > Hmm... for an extern function (espeically have been implemented in
>> > various modules), normally, we can assume it may fail in some cases
>> > (although now, we don't know what cases can cause its failure).
>> >
>> > If "we don't have a good way to handle the failure", "print the related
>> > warning message" is an executable choice (or "BUG_ON()", if it is critical).
>> >
>> > So, if the performance is not sensible, I still suggest to let extern
>> > function have return value.
> This is not a module function. We are not doing a uni course on how to
> write C code here. Be real.
In our case, 'module' points to various sub directories of arch/powerpc
(maybe 'module' is not quite precise, it is easy misunderstand).
The real world is not conflict with "how to write C code".
For my opinion: one fix may like below (assume have removed max_cpus)
which is more reasonable for code readers.
-----------------------------diff begin------------------------------
diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
index 7edbd5b..53155f4 100644
--- a/arch/powerpc/kernel/smp.c
+++ b/arch/powerpc/kernel/smp.c
@@ -347,7 +347,7 @@ void __init smp_prepare_cpus(unsigned int max_cpus)
cpumask_set_cpu(boot_cpuid, cpu_core_mask(boot_cpuid));
if (smp_ops && smp_ops->probe)
- smp_ops->probe();
+ BUG_ON(smp_ops->probe() < 0);
}
void smp_prepare_boot_cpu(void)
-----------------------------diff end--------------------------------
Thanks
--
Chen Gang
^ permalink raw reply related
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Benjamin Herrenschmidt @ 2013-07-25 7:33 UTC (permalink / raw)
To: Chen Gang
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <51F0C2E8.3050005@asianux.com>
On Thu, 2013-07-25 at 14:17 +0800, Chen Gang wrote:
>
> Hmm... for an extern function (espeically have been implemented in
> various modules), normally, we can assume it may fail in some cases
> (although now, we don't know what cases can cause its failure).
>
> If "we don't have a good way to handle the failure", "print the related
> warning message" is an executable choice (or "BUG_ON()", if it is critical).
>
> So, if the performance is not sensible, I still suggest to let extern
> function have return value.
This is not a module function. We are not doing a uni course on how to
write C code here. Be real.
Ben.
^ permalink raw reply
* Re: [PATCH v2] powerpc: kernel: remove useless code which related with 'max_cpus'
From: Chen Gang @ 2013-07-25 6:30 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: chenhui.zhao, paulus@samba.org, Srivatsa S. Bhat, Thomas Gleixner,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1374732225.6142.66.camel@pasglop>
On 07/25/2013 02:03 PM, Benjamin Herrenschmidt wrote:
> On Thu, 2013-07-25 at 15:51 +1000, Benjamin Herrenschmidt wrote:
>> On Thu, 2013-07-25 at 13:24 +0800, Chen Gang wrote:
>>> For an extern function, if the performance is not sensible, better to
>>> have the return value which can indicate the failure with the negative
>>> number.
>>
>> The return value is meaningless.
>>
>> We don't have a good way to handle it. It has no defined semantics. What
>> does "failure" means in that case ? Nothing !
>>
>> So just remove it.
>
> Note: If you want to create a concept of smp_ops->probe() failing, then
> not only you need to check all the implementations, but *also* add
> something sensible to do when it fails ... such as disabling bringup of
> CPUs.
>
Hmm... if critical, use BUG(), else (none critical), just print a
warning message ?
> In this case however, we have put the burden of doing whatever makes
> sense in the probe() function itself. If can adjust the possible map if
> it fails.
>
Excuse me, my English is not quite well, I guss your meaning is: "it can
be fail in internal implementation, but has no effect with the final
result to caller", is it correct ?
If what I understand is correct, it needn't let caller know about it.
Thanks.
--
Chen Gang
^ 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