* Re: [V7] cxl: Add support for ASB_Notify on POWER9
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Christophe Lombard, linuxppc-dev, fbarrat, vaibhav,
andrew.donnellan
In-Reply-To: <1515660925-10026-1-git-send-email-clombard@linux.vnet.ibm.com>
On Thu, 2018-01-11 at 08:55:25 UTC, Christophe Lombard wrote:
> The POWER9 core supports a new feature: ASB_Notify which requires the
> support of the Special Purpose Register: TIDR.
>
> The ASB_Notify command, generated by the AFU, will attempt to
> wake-up the host thread identified by the particular LPID:PID:TID.
>
> This patch assign a unique TIDR (thread id) for the current thread which
> will be used in the process element entry.
>
> Signed-off-by: Christophe Lombard <clombard@linux.vnet.ibm.com>
> Reviewed-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
> Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Reviewed-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/b1db551324f72fa14ad82ca31237a7
cheers
^ permalink raw reply
* Re: powerpc: restore alphabetic order in Kconfig
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras,
Scott Wood, Balbir Singh
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <20180104153525.A03F56E5E6@localhost.localdomain>
On Thu, 2018-01-04 at 15:35:25 UTC, Christophe Leroy wrote:
> This patch restores the alphabetic order which was broken by
> commit 1e0fc9d1eb2b0 ("powerpc/Kconfig: Enable STRICT_KERNEL_RWX
> for some configs")
>
> Fixes: 1e0fc9d1eb2b0 ("powerpc/Kconfig: Enable STRICT_KERNEL_RWX for some configs")
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
> Acked-by: Balbir Singh <bsingharora@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/4ec591e51a4b0aedb6c7f1a8cd722a
cheers
^ permalink raw reply
* Re: [1/2] powerpc/xive: Move definition of ESB bits
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Benjamin Herrenschmidt, linuxppc-dev
In-Reply-To: <20180112023928.10926-1-benh@kernel.crashing.org>
On Fri, 2018-01-12 at 02:39:27 UTC, Benjamin Herrenschmidt wrote:
> >From xive.h to xive-regs.h since it's a HW register definition
> and it can be used from assembly
>
> Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/12c1f339cd49119e39063ae67f02d9
cheers
^ permalink raw reply
* Re: [RESEND] powerpc: mpic_timer: avoid struct timeval
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Arnd Bergmann, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, Tyrel Datwyler, Arnd Bergmann, linux-kernel
In-Reply-To: <20180116170220.2598520-1-arnd@arndb.de>
On Tue, 2018-01-16 at 17:01:50 UTC, Arnd Bergmann wrote:
> In an effort to remove all instances of 'struct timeval'
> from the kernel, I'm changing the powerpc mpic_timer interface
> to use plain seconds instead. There is only one user of this
> interface, and that doesn't use the microseconds portion, so
> the code gets noticeably simpler in the process.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/11ed8c5569b149a065184dc8ce2241
cheers
^ permalink raw reply
* Re: [RESEND] spufs: use timespec64 for timestamps
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Arnd Bergmann, Jeremy Kerr, Arnd Bergmann, Benjamin Herrenschmidt,
Paul Mackerras
Cc: Andrew Morton, linuxppc-dev, Al Viro, linux-kernel
In-Reply-To: <20180116170053.2557047-1-arnd@arndb.de>
On Tue, 2018-01-16 at 17:00:35 UTC, Arnd Bergmann wrote:
> The switch log prints the tv_sec portion of timespec as a 32-bit
> number, while overflows in 2106. It also uses the timespec type,
> which is safe on 64-bit architectures, but deprecated because
> it causes overflows in 2038 elsewhere.
>
> This changes it to timespec64 and printing a 64-bit number for
> consistency.
>
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Jeremy Kerr <jk@ozlabs.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/cef37ac119b1abffcb41a9a7067929
cheers
^ permalink raw reply
* Re: [4/6] KVM: PPC: Book3S HV: Improve handling of debug-trigger HMIs on POWER9
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Paul Mackerras, kvm, linuxppc-dev; +Cc: kvm-ppc
In-Reply-To: <1516182675-25331-5-git-send-email-paulus@ozlabs.org>
On Wed, 2018-01-17 at 09:51:13 UTC, Paul Mackerras wrote:
> Hypervisor maintenance interrupts (HMIs) are generated by various
> causes, signalled by bits in the hypervisor maintenance exception
> register (HMER). In most cases calling OPAL to handle the interrupt
> is the correct thing to do, but the "debug trigger" HMIs signalled by
> PPC bit 17 (bit 46) of HMER are used to invoke software workarounds
> for hardware bugs, and OPAL does not have any code to handle this
> cause. The debug trigger HMI is used in POWER9 DD2.0 and DD2.1 chips
> to work around a hardware bug in executing vector load instructions to
> cache inhibited memory. In POWER9 DD2.2 chips, it is generated when
> conditions are detected relating to threads being in TM (transactional
> memory) suspended mode when the core SMT configuration needs to be
> reconfigured.
>
> The kernel currently has code to detect the vector CI load condition,
> but only when the HMI occurs in the host, not when it occurs in a
> guest. If a HMI occurs in the guest, it is always passed to OPAL, and
> then we always re-sync the timebase, because the HMI cause might have
> been a timebase error, for which OPAL would re-sync the timebase, thus
> removing the timebase offset which KVM applied for the guest. Since
> we don't know what OPAL did, we don't know whether to subtract the
> timebase offset from the timebase, so instead we re-sync the timebase.
>
> This adds code to determine explicitly what the cause of a debug
> trigger HMI will be. This is based on a new device-tree property
> under the CPU nodes called ibm,hmi-special-triggers, if it is
> present, or otherwise based on the PVR (processor version register).
> The handling of debug trigger HMIs is pulled out into a separate
> function which can be called from the KVM guest exit code. If this
> function handles and clears the HMI, and no other HMI causes remain,
> then we skip calling OPAL and we proceed to subtract the guest
> timebase offset from the timebase.
>
> The overall handling for HMIs that occur in the host (i.e. not in a
> KVM guest) is largely unchanged, except that we now don't set the flag
> for the vector CI load workaround on DD2.2 processors.
>
> This also removes a BUG_ON in the KVM code. BUG_ON is generally not
> useful in KVM guest entry/exit code since it is difficult to handle
> the resulting trap gracefully.
>
> Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/d075745d893c78730e4a3b7a60fca2
cheers
^ permalink raw reply
* Re: [kernel] powerpc/powernv/ioda: Finish removing explicit max window size check
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Alexey Kardashevskiy, linuxppc-dev
Cc: Alexey Kardashevskiy, Jonas Pfefferle1, David Gibson
In-Reply-To: <20180118025103.9684-1-aik@ozlabs.ru>
On Thu, 2018-01-18 at 02:51:03 UTC, Alexey Kardashevskiy wrote:
> 9003a2498 removed checn from the DMA window pages allocator, however
> the VFIO driver tests limits before doing so by calling
> the get_table_size hook which was left behind; this fixes it.
>
> Fixes: 9003a2498 "powerpc/powernv/ioda: Remove explicit max window size check"
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/ae677ff02f2ddb0980953efd4afed1
cheers
^ permalink raw reply
* Re: powerpc/watchdog: remove arch_trigger_cpumask_backtrace
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20180117124722.31063-1-npiggin@gmail.com>
On Wed, 2018-01-17 at 12:47:22 UTC, Nicholas Piggin wrote:
> The powerpc NMI IPIs may not be recoverable if they are taken in
> some sections of code, and also there have been and still are issues
> with taking NMIs (in KVM guest code, in firmware, etc) which makes them
> a bit dangerous to use.
>
> Generic code like softlockup detector and rcu stall detectors really
> hammer on trigger_*_backtrace, which has lead to further problems
> because we've implemented it with the NMI.
>
> So stop providing NMI backtraces for now. Importantly, the powerpc code
> uses NMI IPIs in crash/debug, and the SMP hardlockup watchdog. So if the
> softlockup and rcu hang detection traces are not being printed because
> the CPU is stuck with interrupts off, then the hard lockup watchdog
> should get it with the NMI IPI.
>
> Fixes: 2104180a5369 ("powerpc/64s: implement arch-specific hardlockup watchdog")
> Signed-of-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/47712a921bb781caf69fca9eae43be
cheers
^ permalink raw reply
* Re: [v10,03/27] powerpc: initial pkey plumbing
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Ram Pai, mingo, akpm, corbet, arnd
Cc: linux-arch, ebiederm, linux-doc, x86, dave.hansen, linux-kernel,
linuxram, mhocko, linux-mm, paulus, aneesh.kumar, linux-kselftest,
bauerman, linuxppc-dev, khandual
In-Reply-To: <1516326648-22775-4-git-send-email-linuxram@us.ibm.com>
On Fri, 2018-01-19 at 01:50:24 UTC, Ram Pai wrote:
> Basic plumbing to initialize the pkey system.
> Nothing is enabled yet. A later patch will enable it
> once all the infrastructure is in place.
>
> Signed-off-by: Ram Pai <linuxram@us.ibm.com>
Patches 3-27 applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/92e3da3cf193fd27996909956c12a2
cheers
^ permalink raw reply
* Re: powerpc/64s: Fix ps3 build error due to tlbiel_all()
From: Michael Ellerman @ 2018-01-22 3:34 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev; +Cc: sfr, npiggin
In-Reply-To: <20180119085531.7708-1-mpe@ellerman.id.au>
On Fri, 2018-01-19 at 08:55:31 UTC, Michael Ellerman wrote:
> The recent changes to TLB handling broke the PS3 build:
>
> arch/powerpc/include/asm/book3s/64/tlbflush.h:30: undefined reference to `.hash__tlbiel_all'
>
> Fix it by adding an fallback version of tlbiel_all() for non-native
> builds. It should never be called, due to checks in callers so it
> calls BUG(). We should probably clean it up further but this will
> suffice for now.
>
> Fixes: d4748276ae14 ("powerpc/64s: Improve local TLB flush for boot and MCE on POWER9")
> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Applied to powerpc next.
https://git.kernel.org/powerpc/c/7a074fc08389f43b448ebef74bf56b
cheers
^ permalink raw reply
* Re: [PATCH 02/13] powerpc/powernv: Set correct configuration space size for opencapi devices
From: Andrew Donnellan @ 2018-01-22 5:07 UTC (permalink / raw)
To: Michael Ellerman, Frederic Barrat, linuxppc-dev, linux-kernel
Cc: arnd, gregkh, alastair
In-Reply-To: <87607wc0wy.fsf@concordia.ellerman.id.au>
On 20/01/18 20:52, Michael Ellerman wrote:> On my Power8 PowerVM LPAR:
<snip>
Will fix...
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
^ permalink raw reply
* [PATCH v2 0/6] Nintendo Wii GPIO driver
From: Jonathan Neuschäfer @ 2018-01-22 5:04 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, linux-gpio, devicetree, Jonathan Neuschäfer
This series adds a driver for the GPIO controller used in the Nintendo
Wii game console.
The driver itself, and the related devicetree work should be pretty
uncontroversial, but due to the system architecture of the Wii, I also
had to extend an old resource allocation hack to kernel/resource.c: On
the Wii, there are two separate RAM ranges, with MMIO right in the
middle, but AFAIK, Linux on PPC32 doesn't support discontiguous memory
properly. So the hack is to allocate one big RAM range with a hole
(marked as reserved memory) for MMIO in the middle.
Because this series touches different subsystems (GPIO, DT, core
resource management), I guess it should be picked up patch-by-patch by
the different maintainers.
The main difference between v2 and the previous version is that I
rewrote the driver on top of the GPIO_GENERIC library, saving 60 lines
of code.
Jonathan Neuschäfer (6):
resource: Extend the PPC32 reserved memory hack
powerpc: wii: Explicitly configure GPIO owner for poweroff pin
gpio: Add GPIO driver for Nintendo Wii
dt-bindings: gpio: Add binding for Wii GPIO controller
powerpc: wii.dts: Add ngpios property
powerpc: wii.dts: Add GPIO line names
.../bindings/gpio/nintendo,hollywood-gpio.txt | 27 +++++
.../devicetree/bindings/powerpc/nintendo/wii.txt | 9 +-
arch/powerpc/boot/dts/wii.dts | 9 ++
arch/powerpc/platforms/embedded6xx/wii.c | 7 ++
drivers/gpio/Kconfig | 9 ++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-hlwd.c | 123 +++++++++++++++++++++
kernel/resource.c | 21 +++-
8 files changed, 197 insertions(+), 9 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
create mode 100644 drivers/gpio/gpio-hlwd.c
--
2.15.1
^ permalink raw reply
* [PATCH v2 3/6] gpio: Add GPIO driver for Nintendo Wii
From: Jonathan Neuschäfer @ 2018-01-22 5:04 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, linux-gpio, devicetree, Jonathan Neuschäfer,
Albert Herranz, Segher Boessenkool, Linus Walleij
In-Reply-To: <20180122050411.32460-1-j.neuschaefer@gmx.net>
The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller
that supports a configurable number of pins (up to 32), interrupts, and
some special mechanisms to share the controller between the system's
security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is
not supported.
This patch adds a basic driver for this GPIO controller. Interrupt
support will come in a later patch.
This patch is based on code developed by Albert Herranz and the GameCube
Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
has grown quite dissimilar.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Cc: Albert Herranz <albert_herranz@yahoo.es>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
---
v2:
- Change hlwd_gpio_driver.driver.name to "gpio-hlwd" to match the
filename (was "hlwd_gpio")
- Remove unnecessary include of linux/of_gpio.h, as suggested by Linus
Walleij.
- Add struct device pointer to context struct to make it possible to use
dev_info(hlwd->dev, "..."), as suggested by Linus Walleij
- Use the GPIO_GENERIC library to reduce code size, as suggested by
Linus Walleij
- Use iowrite32be instead of __raw_writel for big-endian MMIO access, as
suggested by Linus Walleij
- Remove commit message paragraph suggesting to diff against the
original driver, because it's so different now
---
drivers/gpio/Kconfig | 9 ++++
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-hlwd.c | 123 +++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 133 insertions(+)
create mode 100644 drivers/gpio/gpio-hlwd.c
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index d6a8e851ad13..47606dfe06cc 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -229,6 +229,15 @@ config GPIO_GRGPIO
Select this to support Aeroflex Gaisler GRGPIO cores from the GRLIB
VHDL IP core library.
+config GPIO_HLWD
+ tristate "Nintendo Wii (Hollywood) GPIO"
+ depends on OF_GPIO
+ select GPIO_GENERIC
+ help
+ Select this to support the GPIO controller of the Nintendo Wii.
+
+ If unsure, say N.
+
config GPIO_ICH
tristate "Intel ICH GPIO"
depends on PCI && X86
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 4bc24febb889..492f62d0eb59 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_GPIO_FTGPIO010) += gpio-ftgpio010.o
obj-$(CONFIG_GPIO_GE_FPGA) += gpio-ge.o
obj-$(CONFIG_GPIO_GPIO_MM) += gpio-gpio-mm.o
obj-$(CONFIG_GPIO_GRGPIO) += gpio-grgpio.o
+obj-$(CONFIG_GPIO_HLWD) += gpio-hlwd.o
obj-$(CONFIG_HTC_EGPIO) += gpio-htc-egpio.o
obj-$(CONFIG_GPIO_ICH) += gpio-ich.o
obj-$(CONFIG_GPIO_INGENIC) += gpio-ingenic.o
diff --git a/drivers/gpio/gpio-hlwd.c b/drivers/gpio/gpio-hlwd.c
new file mode 100644
index 000000000000..cf3f05a1621c
--- /dev/null
+++ b/drivers/gpio/gpio-hlwd.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+// Copyright (C) 2008-2009 The GameCube Linux Team
+// Copyright (C) 2008,2009 Albert Herranz
+// Copyright (C) 2017-2018 Jonathan Neuschäfer
+//
+// Nintendo Wii (Hollywood) GPIO driver
+
+#include <linux/gpio/driver.h>
+#include <linux/io.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
+#include <linux/slab.h>
+
+/*
+ * Register names and offsets courtesy of WiiBrew:
+ * https://wiibrew.org/wiki/Hardware/Hollywood_GPIOs
+ *
+ * Note that for most registers, there are two versions:
+ * - HW_GPIOB_* Is always accessible by the Broadway PowerPC core, but does
+ * always give access to all GPIO lines
+ * - HW_GPIO_* Is only accessible by the Broadway PowerPC code if the memory
+ * firewall (AHBPROT) in the Hollywood chipset has been configured to allow
+ * such access.
+ *
+ * The ownership of each GPIO line can be configured in the HW_GPIO_OWNER
+ * register: A one bit configures the line for access via the HW_GPIOB_*
+ * registers, a zero bit indicates access via HW_GPIO_*. This driver uses
+ * HW_GPIOB_*.
+ */
+#define HW_GPIOB_OUT 0x00
+#define HW_GPIOB_DIR 0x04
+#define HW_GPIOB_IN 0x08
+#define HW_GPIOB_INTLVL 0x0c
+#define HW_GPIOB_INTFLAG 0x10
+#define HW_GPIOB_INTMASK 0x14
+#define HW_GPIOB_INMIR 0x18
+#define HW_GPIO_ENABLE 0x1c
+#define HW_GPIO_OUT 0x20
+#define HW_GPIO_DIR 0x24
+#define HW_GPIO_IN 0x28
+#define HW_GPIO_INTLVL 0x2c
+#define HW_GPIO_INTFLAG 0x30
+#define HW_GPIO_INTMASK 0x34
+#define HW_GPIO_INMIR 0x38
+#define HW_GPIO_OWNER 0x3c
+
+
+struct hlwd_gpio {
+ struct gpio_chip gpioc;
+ void __iomem *regs;
+ struct device *dev;
+};
+
+static int hlwd_gpio_probe(struct platform_device *pdev)
+{
+ struct hlwd_gpio *hlwd;
+ struct resource *regs_resource;
+ u32 ngpios;
+ int res;
+
+ hlwd = devm_kzalloc(&pdev->dev, sizeof(*hlwd), GFP_KERNEL);
+ if (!hlwd)
+ return -ENOMEM;
+
+ /* Save the struct device pointer so dev_info, etc. can be used. */
+ hlwd->dev = &pdev->dev;
+
+ regs_resource = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (IS_ERR(regs_resource))
+ return PTR_ERR(regs_resource);
+
+ hlwd->regs = devm_ioremap_resource(&pdev->dev, regs_resource);
+ if (IS_ERR(hlwd->regs))
+ return PTR_ERR(hlwd->regs);
+
+ /*
+ * Claim all GPIOs using the OWNER register. This will not work on
+ * systems where the AHBPROT memory firewall hasn't been configured to
+ * permit PPC access to HW_GPIO_*.
+ *
+ * Note that this has to happen before bgpio_init reads the
+ * HW_GPIOB_OUT and HW_GPIOB_DIR, because otherwise it reads the wrong
+ * values.
+ */
+ iowrite32be(0xffffffff, hlwd->regs + HW_GPIO_OWNER);
+
+ res = bgpio_init(&hlwd->gpioc, &pdev->dev, 4,
+ hlwd->regs + HW_GPIOB_IN, hlwd->regs + HW_GPIOB_OUT,
+ NULL, hlwd->regs + HW_GPIOB_DIR, NULL,
+ BGPIOF_BIG_ENDIAN_BYTE_ORDER);
+
+ if (res < 0) {
+ dev_warn(hlwd->dev, "bgpio_init failed: %d\n", res);
+ return res;
+ }
+
+ if (of_property_read_u32(pdev->dev.of_node, "ngpios", &ngpios))
+ ngpios = 32;
+ hlwd->gpioc.ngpio = ngpios;
+
+ return devm_gpiochip_add_data(&pdev->dev, &hlwd->gpioc, hlwd);
+}
+
+static const struct of_device_id hlwd_gpio_match[] = {
+ { .compatible = "nintendo,hollywood-gpio", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, hlwd_gpio_match);
+
+static struct platform_driver hlwd_gpio_driver = {
+ .driver = {
+ .name = "gpio-hlwd",
+ .of_match_table = hlwd_gpio_match,
+ },
+ .probe = hlwd_gpio_probe,
+};
+module_platform_driver(hlwd_gpio_driver);
+
+MODULE_AUTHOR("Jonathan Neuschäfer <j.neuschaefer@gmx.net>");
+MODULE_DESCRIPTION("Nintendo Wii GPIO driver");
+MODULE_LICENSE("GPL");
--
2.15.1
^ permalink raw reply related
* [PATCH v2 6/6] powerpc: wii.dts: Add GPIO line names
From: Jonathan Neuschäfer @ 2018-01-22 5:04 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, linux-gpio, devicetree, Jonathan Neuschäfer,
Rob Herring, Mark Rutland, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
In-Reply-To: <20180122050411.32460-1-j.neuschaefer@gmx.net>
These are the GPIO line names on a Nintendo Wii, as documented in:
https://wiibrew.org/wiki/Hardware/Hollywood_GPIOs
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
v2:
- no change
---
arch/powerpc/boot/dts/wii.dts | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index 7235e375919c..07d5e84e98b1 100644
--- a/arch/powerpc/boot/dts/wii.dts
+++ b/arch/powerpc/boot/dts/wii.dts
@@ -178,6 +178,14 @@
gpio-controller;
ngpios = <24>;
+ gpio-line-names =
+ "POWER", "SHUTDOWN", "FAN", "DC_DC",
+ "DI_SPIN", "SLOT_LED", "EJECT_BTN", "SLOT_IN",
+ "SENSOR_BAR", "DO_EJECT", "EEP_CS", "EEP_CLK",
+ "EEP_MOSI", "EEP_MISO", "AVE_SCL", "AVE_SDA",
+ "DEBUG0", "DEBUG1", "DEBUG2", "DEBUG3",
+ "DEBUG4", "DEBUG5", "DEBUG6", "DEBUG7";
+
/*
* This is commented out while a standard binding
* for i2c over gpio is defined.
--
2.15.1
^ permalink raw reply related
* [PATCH v2 1/6] resource: Extend the PPC32 reserved memory hack
From: Jonathan Neuschäfer @ 2018-01-22 5:04 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, linux-gpio, devicetree, Jonathan Neuschäfer,
Albert Herranz, Tom Lendacky, Borislav Petkov, Brijesh Singh,
Thomas Gleixner
In-Reply-To: <20180122050411.32460-1-j.neuschaefer@gmx.net>
On the Nintendo Wii, there are two ranges of physical memory, and MMIO
in between, but Linux on ppc32 doesn't support discontiguous memory.
Therefore a hack was introduced in commit c5df7f775148 ("powerpc: allow
ioremap within reserved memory regions") and commit de32400dd26e ("wii:
use both mem1 and mem2 as ram"):
- Treat the area from the start of the first memory area (MEM1) to the
end of the second (MEM2) as one big memory area, but mark the part
that doesn't belong to MEM1 or MEM2 as reserved.
- Only on the Wii, allow ioremap to be used on reserved memory.
This hack, however, doesn't account for the "resource"-based API in
kernel/resource.c, because __request_region performs its own checks.
Extend the hack to kernel/resource.c, to allow more drivers to allocate
their MMIO regions on the Wii.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Cc: Albert Herranz <albert_herranz@yahoo.es>
---
v2:
- CC Albert Herranz, who introduced this hack in 2009.
---
kernel/resource.c | 21 ++++++++++++++++++++-
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/kernel/resource.c b/kernel/resource.c
index 54ba6de3757c..bb3d329329da 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -1134,6 +1134,24 @@ resource_size_t resource_alignment(struct resource *res)
static DECLARE_WAIT_QUEUE_HEAD(muxed_resource_wait);
+/*
+ * On some ppc32 platforms (Nintendo Wii), reserved memory is used to work
+ * around the fact that Linux doesn't support discontiguous memory (all memory
+ * is treated as one large area with holes punched in it), and reserved memory
+ * is allowed to be allocated.
+ */
+#ifdef CONFIG_PPC32
+static bool conflict_ignored(struct resource *conflict)
+{
+ extern int __allow_ioremap_reserved;
+
+ return __allow_ioremap_reserved &&
+ (conflict->flags & IORESOURCE_SYSRAM);
+}
+#else
+static bool conflict_ignored(struct resource *conflict) { return false; }
+#endif
+
/**
* __request_region - create a new busy resource region
* @parent: parent resource descriptor
@@ -1166,8 +1184,9 @@ struct resource * __request_region(struct resource *parent,
res->desc = parent->desc;
conflict = __request_resource(parent, res);
- if (!conflict)
+ if (!conflict || conflict_ignored(conflict))
break;
+
if (conflict != parent) {
if (!(conflict->flags & IORESOURCE_BUSY)) {
parent = conflict;
--
2.15.1
^ permalink raw reply related
* [PATCH v2 2/6] powerpc: wii: Explicitly configure GPIO owner for poweroff pin
From: Jonathan Neuschäfer @ 2018-01-22 5:04 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, linux-gpio, devicetree, Jonathan Neuschäfer,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
In-Reply-To: <20180122050411.32460-1-j.neuschaefer@gmx.net>
The Hollywood chipset's GPIO controller has two sets of registers: One
for access by the PowerPC CPU, and one for access by the ARM coprocessor
(but both are accessible from the PPC because the memory firewall
(AHBPROT) is usually disabled when booting Linux, today).
The wii_power_off function currently assumes that the poweroff GPIO pin
is configured for use via the ARM side, but the upcoming GPIO driver
configures all pins for use via the PPC side, breaking poweroff.
Configure the owner register explicitly in wii_power_off to make
wii_power_off work with and without the new GPIO driver.
I think the Wii can be switched to the generic gpio-poweroff driver,
after the GPIO driver is merged.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
v2:
- no change
---
arch/powerpc/platforms/embedded6xx/wii.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/arch/powerpc/platforms/embedded6xx/wii.c b/arch/powerpc/platforms/embedded6xx/wii.c
index 79a1fe54ebc9..6e6db1e16d71 100644
--- a/arch/powerpc/platforms/embedded6xx/wii.c
+++ b/arch/powerpc/platforms/embedded6xx/wii.c
@@ -45,6 +45,7 @@
#define HW_GPIO_BASE(idx) (idx * 0x20)
#define HW_GPIO_OUT(idx) (HW_GPIO_BASE(idx) + 0)
#define HW_GPIO_DIR(idx) (HW_GPIO_BASE(idx) + 4)
+#define HW_GPIO_OWNER (HW_GPIO_BASE(1) + 0x1c)
#define HW_GPIO_SHUTDOWN (1<<1)
#define HW_GPIO_SLOT_LED (1<<5)
@@ -177,6 +178,12 @@ static void wii_power_off(void)
local_irq_disable();
if (hw_gpio) {
+ /*
+ * set the owner of the shutdown pin to ARM, because it is
+ * accessed through the registers for the ARM, below
+ */
+ clrbits32(hw_gpio + HW_GPIO_OWNER, HW_GPIO_SHUTDOWN);
+
/* make sure that the poweroff GPIO is configured as output */
setbits32(hw_gpio + HW_GPIO_DIR(1), HW_GPIO_SHUTDOWN);
--
2.15.1
^ permalink raw reply related
* [PATCH v2 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller
From: Jonathan Neuschäfer @ 2018-01-22 5:04 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, linux-gpio, devicetree, Jonathan Neuschäfer,
Linus Walleij, Rob Herring, Mark Rutland, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman
In-Reply-To: <20180122050411.32460-1-j.neuschaefer@gmx.net>
The Nintendo Wii game console has a GPIO controller, which is used for
the optical disk slot LED, buttons, poweroff, etc. This patch adds a
binding for this GPIO controller.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Reviewed-by: Rob Herring <robh@kernel.org>
---
v2:
- Drop the leading zero in the example, as suggested by Rob Herring
- Add some text to the commit message, as suggested by Linus Walleij
---
.../bindings/gpio/nintendo,hollywood-gpio.txt | 27 ++++++++++++++++++++++
.../devicetree/bindings/powerpc/nintendo/wii.txt | 9 +-------
2 files changed, 28 insertions(+), 8 deletions(-)
create mode 100644 Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
diff --git a/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
new file mode 100644
index 000000000000..20fc72d9e61e
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
@@ -0,0 +1,27 @@
+Nintendo Wii (Hollywood) GPIO controller
+
+Required properties:
+- compatible: "nintendo,hollywood-gpio
+- reg: Physical base address and length of the controller's registers.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells: Should be <2>. The first cell is the pin number and the
+ second cell is used to specify optional parameters:
+ - bit 0 specifies polarity (0 for normal, 1 for inverted).
+
+Optional properties:
+- ngpios: see Documentation/devicetree/bindings/gpio/gpio.txt
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- interrupts: Interrupt specifier for the controller's Broadway (PowerPC)
+ interrupt.
+- interrupt-parent: phandle of the parent interrupt controller.
+
+Example:
+
+ GPIO: gpio@d8000c0 {
+ #gpio-cells = <2>;
+ compatible = "nintendo,hollywood-gpio";
+ reg = <0x0d8000c0 0x40>;
+ gpio-controller;
+ ngpios = <24>;
+ }
diff --git a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
index 36afa322b04b..a3dc4b9fa11a 100644
--- a/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
+++ b/Documentation/devicetree/bindings/powerpc/nintendo/wii.txt
@@ -152,14 +152,7 @@ Nintendo Wii device tree
1.l) The General Purpose I/O (GPIO) controller node
- Represents the dual access 32 GPIO controller interface.
-
- Required properties:
-
- - #gpio-cells : <2>
- - compatible : should be "nintendo,hollywood-gpio"
- - reg : should contain the IPC registers location and length
- - gpio-controller
+ see Documentation/devicetree/bindings/gpio/nintendo,hollywood-gpio.txt
1.m) The control node
--
2.15.1
^ permalink raw reply related
* [PATCH v2 5/6] powerpc: wii.dts: Add ngpios property
From: Jonathan Neuschäfer @ 2018-01-22 5:04 UTC (permalink / raw)
To: linux-kernel
Cc: linuxppc-dev, linux-gpio, devicetree, Jonathan Neuschäfer,
Rob Herring, Mark Rutland, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman
In-Reply-To: <20180122050411.32460-1-j.neuschaefer@gmx.net>
The Hollywood GPIO controller supports 32 GPIOs, but on the Wii, only 24
are used.
Signed-off-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
---
v2:
- no change
---
arch/powerpc/boot/dts/wii.dts | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/boot/dts/wii.dts b/arch/powerpc/boot/dts/wii.dts
index 40b324b6391e..7235e375919c 100644
--- a/arch/powerpc/boot/dts/wii.dts
+++ b/arch/powerpc/boot/dts/wii.dts
@@ -176,6 +176,7 @@
compatible = "nintendo,hollywood-gpio";
reg = <0x0d8000c0 0x40>;
gpio-controller;
+ ngpios = <24>;
/*
* This is commented out while a standard binding
--
2.15.1
^ permalink raw reply related
* Re: [PATCH v2 1/5] powerpc/mm: Enhance 'slice' for supporting PPC32
From: Christophe LEROY @ 2018-01-22 7:52 UTC (permalink / raw)
To: Segher Boessenkool
Cc: Aneesh Kumar K.V, Benjamin Herrenschmidt, Paul Mackerras,
Michael Ellerman, Scott Wood, linuxppc-dev, linux-kernel
In-Reply-To: <20180120175655.GY21977@gate.crashing.org>
Le 20/01/2018 à 18:56, Segher Boessenkool a écrit :
> Hi!
>
> On Sat, Jan 20, 2018 at 09:22:50AM +0100, christophe leroy wrote:
>>>>>>>>> On PPC32, the address space is limited to 4Gbytes, hence only the
>>>>>>>>> low
>>>>>>>>> slices will be used. As of today, the code uses
>>>>>>>>> SLICE_LOW_TOP (0x100000000ul) and compares it with addr to determine
>>>>>>>>> if addr refers to low or high space.
>>>>>>>>> On PPC32, such a (addr < SLICE_LOW_TOP) test is always false because
>>>>>>>>> 0x100000000ul degrades to 0. Therefore, the patch modifies
>>>>>>>>> SLICE_LOW_TOP to (0xfffffffful) and modifies the tests to
>>>>>>>>> (addr <= SLICE_LOW_TOP) which will then always be true on PPC32
>>>>>>>>> as addr has type 'unsigned long' while not modifying the PPC64
>>>>>>>>> behaviour.
>
> It should work to define SLICE_LOW_TOP as 0x100000000ull and keep
> everything else the same, no?
great, yes it works indeed.
>
>>> I don't think so. When I had the missing prototype, the compilation goes
>>> ok, including the final link. Which means at the end the code is not
>>> included since radix_enabled() evaluates to 0.
>>>
>>> Many many parts of the kernel are based on this assumption.
>>
>> Segher, what is your opinion on the above ? Can we consider that a ' if
>> (nbits)' will always be compiled out when nbits is a #define constant,
>> or should we duplicate the macros as suggested in order to avoid
>> unneccessary 'if' test on platforms where 'nbits' is always not null by
>> definition ?
>
> Doing things like
>
> if (nbits)
> some_undeclared_function();
>
> will likely work in practice if the condition evaluates to false at
> compile time, but a) it will warn; b) it is just yuck; and c) it will
> not always work (for example, you get the wrong prototype in this case,
> not lethal here with most ABIs, but ugh).
>
> Just make sure to declare all functions, or define it to some empty
> thing, or #ifdeffery if you have to. There are many options, it is
> not hard, and if it means you have to pull code further apart that is
> not so bad: you get cleaner, clearer code.
Ok, if I understand well, your comment applies to the following indeed,
so you confirm the #ifdef is necessary.
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -553,9 +553,11 @@ unsigned long hugetlb_get_unmapped_area(struct file
*file, unsigned long addr,
struct hstate *hstate = hstate_file(file);
int mmu_psize = shift_to_mmu_psize(huge_page_shift(hstate));
+#ifdef CONFIG_PPC_RADIX_MMU
if (radix_enabled())
return radix__hugetlb_get_unmapped_area(file, addr, len,
pgoff, flags);
+#endif
return slice_get_unmapped_area(addr, len, flags, mmu_psize, 1);
}
#endif
However, my question was related to another part of the current
patchset, where the functions are always refined:
On PPC32 we set:
+#define SLICE_LOW_SHIFT 28
+#define SLICE_HIGH_SHIFT 0
On PPC64 we set:
#define SLICE_LOW_SHIFT 28
#define SLICE_HIGH_SHIFT 40
We define:
+#define slice_bitmap_zero(dst, nbits) \
+ do { if (nbits) bitmap_zero(dst, nbits); } while (0)
We have a function with:
{
slice_bitmap_zero(ret->low_slices, SLICE_NUM_LOW);
slice_bitmap_zero(ret->high_slices, SLICE_NUM_HIGH);
}
So the question is to find the better approach. Is the above approach
correct, including performance wise ?
Or should we define two sets of the macro slice_bitmap_zero(), one for
CONFIG_PPC32 with the 'if (nbits)' test and one for CONFIG_PPC64 without
the unnecessary test ?
Or should we avoid this macro entirely and instead do something like:
{
bitmap_zero(ret->low_slices, SLICE_NUM_LOW);
#if SLICE_NUM_HIGH != 0
bitmap_zero(ret->high_slices, SLICE_NUM_HIGH);
#endif
}
And if we say the 'macro' approach is OK, should it be better the use a
static inline function instead ?
Thanks,
Christophe
^ permalink raw reply
* [PATCH v3] cpufreq: powernv: Add support of frequency domain
From: Abhishek Goel @ 2018-01-22 8:17 UTC (permalink / raw)
To: viresh.kumar, benh, paulus, rjw, mpe, linux-pm, linuxppc-dev,
linux-kernel
Cc: Abhishek Goel
Frequency-domain indicates group of CPUs that would share same frequency.
It is detected using device-tree node "frequency-domain-indicator".
frequency-domain-indicator is a bitmask which will have different value
depending upon the generation of the processor.
CPUs of the same chip for which the result of a bitwise AND between
their PIR and the frequency-domain-indicator is the same share the same
frequency.
In this patch, we define hash-table indexed by the aforementioned
bitwise ANDed value to store the cpumask of the CPUs sharing the same
frequency domain. Further, the cpufreq policy will be created per
frequency-domain
So for POWER9, a cpufreq policy is created per quad while for POWER8 it
is created per core. Governor decides frequency for each policy but
multiple cores may come under same policy. In such case frequency needs
to be set on each core sharing that policy.
Signed-off-by: Abhishek Goel <huntbag@linux.vnet.ibm.com>
---
Skiboot patch required for the corresponding device-tree changes have been
posted here : http://patchwork.ozlabs.org/patch/862256/
drivers/cpufreq/powernv-cpufreq.c | 104 ++++++++++++++++++++++++++++++++++----
1 file changed, 95 insertions(+), 9 deletions(-)
diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
index b6d7c4c..aab23a4 100644
--- a/drivers/cpufreq/powernv-cpufreq.c
+++ b/drivers/cpufreq/powernv-cpufreq.c
@@ -37,6 +37,7 @@
#include <asm/smp.h> /* Required for cpu_sibling_mask() in UP configs */
#include <asm/opal.h>
#include <linux/timer.h>
+#include <linux/hashtable.h>
#define POWERNV_MAX_PSTATES 256
#define PMSR_PSAFE_ENABLE (1UL << 30)
@@ -130,6 +131,9 @@ enum throttle_reason_type {
static int nr_chips;
static DEFINE_PER_CPU(struct chip *, chip_info);
+static u32 freq_domain_indicator;
+static bool p9_occ_quirk;
+
/*
* Note:
* The set of pstates consists of contiguous integers.
@@ -194,6 +198,38 @@ static inline void reset_gpstates(struct cpufreq_policy *policy)
gpstates->last_gpstate_idx = 0;
}
+#define SIZE NR_CPUS
+#define ORDER_FREQ_MAP ilog2(SIZE)
+
+static DEFINE_HASHTABLE(freq_domain_map, ORDER_FREQ_MAP);
+
+struct hashmap {
+ cpumask_t mask;
+ int chip_id;
+ u32 pir_key;
+ struct hlist_node hash_node;
+};
+
+static void insert(u32 key, int cpu)
+{
+ struct hashmap *data;
+
+ hash_for_each_possible(freq_domain_map, data, hash_node, key%SIZE) {
+ if (data->chip_id == cpu_to_chip_id(cpu) &&
+ data->pir_key == key) {
+ cpumask_set_cpu(cpu, &data->mask);
+ return;
+ }
+ }
+
+ data = kzalloc(sizeof(*data), GFP_KERNEL);
+ hash_add(freq_domain_map, &data->hash_node, key%SIZE);
+ cpumask_set_cpu(cpu, &data->mask);
+ data->chip_id = cpu_to_chip_id(cpu);
+ data->pir_key = key;
+
+}
+
/*
* Initialize the freq table based on data obtained
* from the firmware passed via device-tree
@@ -206,6 +242,7 @@ static int init_powernv_pstates(void)
u32 len_ids, len_freqs;
u32 pstate_min, pstate_max, pstate_nominal;
u32 pstate_turbo, pstate_ultra_turbo;
+ u32 key;
power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
if (!power_mgt) {
@@ -246,9 +283,18 @@ static int init_powernv_pstates(void)
else
powernv_pstate_info.wof_enabled = true;
+ if (of_device_is_compatible(power_mgt, "freq-domain-v1") &&
+ of_property_read_u32(power_mgt, "ibm,freq-domain-indicator",
+ &freq_domain_indicator))
+ pr_warn("ibm,freq-domain-indicator not found\n");
+
+ if (of_device_is_compatible(power_mgt, "p9-occ-quirk"))
+ p9_occ_quirk = true;
+
next:
pr_info("cpufreq pstate min %d nominal %d max %d\n", pstate_min,
pstate_nominal, pstate_max);
+ pr_info("frequency domain indicator %d", freq_domain_indicator);
pr_info("Workload Optimized Frequency is %s in the platform\n",
(powernv_pstate_info.wof_enabled) ? "enabled" : "disabled");
@@ -276,6 +322,15 @@ static int init_powernv_pstates(void)
return -ENODEV;
}
+ if (freq_domain_indicator) {
+ hash_init(freq_domain_map);
+ for_each_possible_cpu(i) {
+ key = ((u32) get_hard_smp_processor_id(i) &
+ freq_domain_indicator);
+ insert(key, i);
+ }
+ }
+
powernv_pstate_info.nr_pstates = nr_pstates;
pr_debug("NR PStates %d\n", nr_pstates);
for (i = 0; i < nr_pstates; i++) {
@@ -760,25 +815,56 @@ static int powernv_cpufreq_target_index(struct cpufreq_policy *policy,
spin_unlock(&gpstates->gpstate_lock);
- /*
- * Use smp_call_function to send IPI and execute the
- * mtspr on target CPU. We could do that without IPI
- * if current CPU is within policy->cpus (core)
+ /* The current DVFS implementation in firmware requires that to set a
+ * frequency in a quad, all cores of the quad need to set frequency in
+ * their respective PMCR's. Ideally setting frequency on any of the
+ * core of that quad should change frequency for the quad.
*/
- smp_call_function_any(policy->cpus, set_pstate, &freq_data, 1);
+ if (p9_occ_quirk) {
+ cpumask_t temp;
+ u32 cpu;
+
+ cpumask_copy(&temp, policy->cpus);
+ while (!cpumask_empty(&temp)) {
+ cpu = cpumask_first(&temp);
+ smp_call_function_any(cpu_sibling_mask(cpu),
+ set_pstate, &freq_data, 1);
+ cpumask_andnot(&temp, &temp, cpu_sibling_mask(cpu));
+ }
+ } else {
+ smp_call_function_any(policy->cpus, set_pstate, &freq_data, 1);
+ }
+
return 0;
}
static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
{
- int base, i, ret;
+ int ret;
struct kernfs_node *kn;
struct global_pstate_info *gpstates;
- base = cpu_first_thread_sibling(policy->cpu);
+ if (!freq_domain_indicator) {
+ int base, i;
- for (i = 0; i < threads_per_core; i++)
- cpumask_set_cpu(base + i, policy->cpus);
+ base = cpu_first_thread_sibling(policy->cpu);
+ for (i = 0; i < threads_per_core; i++)
+ cpumask_set_cpu(base + i, policy->cpus);
+ } else {
+ u32 key;
+ struct hashmap *data;
+
+ key = ((u32) get_hard_smp_processor_id(policy->cpu) &
+ freq_domain_indicator);
+ hash_for_each_possible(freq_domain_map, data, hash_node,
+ key%SIZE) {
+ if (data->chip_id == cpu_to_chip_id(policy->cpu) &&
+ data->pir_key == key) {
+ cpumask_copy(policy->cpus, &data->mask);
+ break;
+ }
+ }
+ }
kn = kernfs_find_and_get(policy->kobj.sd, throttle_attr_grp.name);
if (!kn) {
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2] powerpc/mm: Fix growth direction for hugepages mmaps with slice
From: Christophe LEROY @ 2018-01-22 8:22 UTC (permalink / raw)
To: Aneesh Kumar K.V, linuxppc-dev
In-Reply-To: <87mv1ayxi6.fsf@linux.vnet.ibm.com>
Le 19/01/2018 à 11:05, Aneesh Kumar K.V a écrit :
>
> Did a reply instead of reply-all.
>
> Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> writes:
>
>> Christophe LEROY <christophe.leroy@c-s.fr> writes:
>>
>>> Le 17/01/2018 à 04:19, Aneesh Kumar K.V a écrit :
>>>>
>>>>
>>>> On 01/16/2018 10:18 PM, Christophe LEROY wrote:
>>>>>
>>>>>
>>>>> Le 16/01/2018 à 17:03, Aneesh Kumar K.V a écrit :
>>>>>> Christophe Leroy <christophe.leroy@c-s.fr> writes:
>>>>>>
>>>>>>> An application running with libhugetlbfs fails to allocate
>>>>>>> additional pages to HEAP due to the hugemap being done
>>>>>>> inconditionally as topdown mapping:
>>>>>>>
>>>>>>> mmap(0x10080000, 1572864, PROT_READ|PROT_WRITE,
>>>>>>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0) = 0x73e80000
>>>>>>> [...]
>>>>>>> mmap(0x74000000, 1048576, PROT_READ|PROT_WRITE,
>>>>>>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d80000
>>>>>>> munmap(0x73d80000, 1048576) = 0
>>>>>>> [...]
>>>>>>> mmap(0x74000000, 1572864, PROT_READ|PROT_WRITE,
>>>>>>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d00000
>>>>>>> munmap(0x73d00000, 1572864) = 0
>>>>>>> [...]
>>>>>>> mmap(0x74000000, 1572864, PROT_READ|PROT_WRITE,
>>>>>>> MAP_PRIVATE|MAP_ANONYMOUS|0x40000, -1, 0x180000) = 0x73d00000
>>>>>>> munmap(0x73d00000, 1572864) = 0
>>>>>>> [...]
>>>>>>>
>>>>>>
>>>>>> Can you explain the failure details above. I am not sure I understand
>>>>>> what to read from the above output.
>>>>>
>>>>> libhugetlbfs first requests an area of size 1.5Mbytes, at address
>>>>> 0x10080000
>>>>> mmap() returns an area at address 0x73e80000
>>>>>
>>>>> Then libhugetlbfs requests an additional area on top of that, ie at
>>>>> address 0x74000000, to expand the heap.
>>>>> But mmap() returns an area at address 0x73d80000, ie under the
>>>>> previous area.
>>>>>
>>>>
>>>>
>>>> Can you share the test details?. Why does it not fail on book3s64? We
>>>> use topdown search with book3s64.
>>>
>>> I don't know about book3s64, I only have 8xx.
>>>
>>> Here is my test app:
>>>
>>
>> The test ran fine on ppc64.
>>
>> kvaneesh@ltctulc6a-p1:[~]$ HUGETLB_MORECORE=yes ./a.out
>> 10000000-10010000 r-xp 00000000 fc:00 9044312 /home/kvaneesh/a.out
>> 10010000-10020000 r--p 00000000 fc:00 9044312 /home/kvaneesh/a.out
>> 10020000-10030000 rw-p 00010000 fc:00 9044312 /home/kvaneesh/a.out
>> 7ffff7d60000-7ffff7f10000 r-xp 00000000 fc:00 9250090 /lib/powerpc64le-linux-gnu/libc-2.23.so
>> 7ffff7f10000-7ffff7f20000 r--p 001a0000 fc:00 9250090 /lib/powerpc64le-linux-gnu/libc-2.23.so
>> 7ffff7f20000-7ffff7f30000 rw-p 001b0000 fc:00 9250090 /lib/powerpc64le-linux-gnu/libc-2.23.so
>> 7ffff7f40000-7ffff7f60000 r-xp 00000000 fc:00 10754812 /usr/lib/libhugetlbfs.so.0
>> 7ffff7f60000-7ffff7f70000 r--p 00010000 fc:00 10754812 /usr/lib/libhugetlbfs.so.0
>> 7ffff7f70000-7ffff7f80000 rw-p 00020000 fc:00 10754812 /usr/lib/libhugetlbfs.so.0
>> 7ffff7f80000-7ffff7fa0000 r-xp 00000000 00:00 0 [vdso]
>> 7ffff7fa0000-7ffff7fe0000 r-xp 00000000 fc:00 9250107 /lib/powerpc64le-linux-gnu/ld-2.23.so
>> 7ffff7fe0000-7ffff7ff0000 r--p 00030000 fc:00 9250107 /lib/powerpc64le-linux-gnu/ld-2.23.so
>> 7ffff7ff0000-7ffff8000000 rw-p 00040000 fc:00 9250107 /lib/powerpc64le-linux-gnu/ld-2.23.so
>> 7ffffffd0000-800000000000 rw-p 00000000 00:00 0 [stack]
>>
>>
>> Allocated 1Mbytes at 0x10000000010
>>
>>
>> Allocated 1Mbytes at 0x10002000020
>>
>>
>> Allocated 1Mbytes at 0x10004000030
>>
>> 10000000-10010000 r-xp 00000000 fc:00 9044312 /home/kvaneesh/a.out
>> 10010000-10020000 r--p 00000000 fc:00 9044312 /home/kvaneesh/a.out
>> 10020000-10030000 rw-p 00010000 fc:00 9044312 /home/kvaneesh/a.out
>> 10000000000-10003000000 rw-p 00000000 00:0d 1041435 /anon_hugepage (deleted)
>> 10003000000-10005000000 rw-p 03000000 00:0d 1041436 /anon_hugepage (deleted)
>> 10005000000-10007000000 rw-p 05000000 00:0d 1041437 /anon_hugepage (deleted)
>> 7ffff7d60000-7ffff7f10000 r-xp 00000000 fc:00 9250090 /lib/powerpc64le-linux-gnu/libc-2.23.so
>> 7ffff7f10000-7ffff7f20000 r--p 001a0000 fc:00 9250090 /lib/powerpc64le-linux-gnu/libc-2.23.so
>> 7ffff7f20000-7ffff7f30000 rw-p 001b0000 fc:00 9250090 /lib/powerpc64le-linux-gnu/libc-2.23.so
>> 7ffff7f40000-7ffff7f60000 r-xp 00000000 fc:00 10754812 /usr/lib/libhugetlbfs.so.0
>> 7ffff7f60000-7ffff7f70000 r--p 00010000 fc:00 10754812 /usr/lib/libhugetlbfs.so.0
>> 7ffff7f70000-7ffff7f80000 rw-p 00020000 fc:00 10754812 /usr/lib/libhugetlbfs.so.0
>> 7ffff7f80000-7ffff7fa0000 r-xp 00000000 00:00 0 [vdso]
>> 7ffff7fa0000-7ffff7fe0000 r-xp 00000000 fc:00 9250107 /lib/powerpc64le-linux-gnu/ld-2.23.so
>> 7ffff7fe0000-7ffff7ff0000 r--p 00030000 fc:00 9250107 /lib/powerpc64le-linux-gnu/ld-2.23.so
>> 7ffff7ff0000-7ffff8000000 rw-p 00040000 fc:00 9250107 /lib/powerpc64le-linux-gnu/ld-2.23.so
>> 7ffffffd0000-800000000000 rw-p 00000000 00:00 0 [stack]
>>
>>
>>
>> So i am definitely missing something. I understand that generic hugetlb
>> get unmapped area always search bottom up and 8xx used to depend on that
>> callback. But on ppc64 slice based get unmapped area always did topdown
>> and I am not sure whether we should change that. More over I don't think
>> MAP_GROWSDOWN is the right flag for selecting topdown/bottom up search.
>>
>>
>> Is it that libhugetlbfs does something specific for 32 bit? Other option
>> is to add huget_get_unmapped_area for 8xx that does bottom up search?
I think I identified the difference. In my run you have the following
warning:
libhugetlbfs: WARNING: Heap originates at 0x73e80000 instead of 0x10080000
In your run, there is no such warning.
I tried running the test with HUGETLB_MORECORE_HEAPBASE=0x30000000, and
it works without the patch:
root@vgoip:~# HUGETLB_MORECORE=yes HUGETLB_MORECORE_HEAPBASE=0x30000000
./huge_m
alloc_test
00100000-00108000 r-xp 00000000 00:00 0 [vdso]
0fde4000-0fde8000 r-xp 00000000 00:0f 168 /lib/libdl-2.23.so
0fde8000-0fe00000 ---p 00004000 00:0f 168 /lib/libdl-2.23.so
0fe00000-0fe04000 r--p 0000c000 00:0f 168 /lib/libdl-2.23.so
0fe04000-0fe08000 rwxp 00010000 00:0f 168 /lib/libdl-2.23.so
0fe18000-0ff88000 r-xp 00000000 00:0f 191 /lib/libc-2.23.so
0ff88000-0ffa4000 ---p 00170000 00:0f 191 /lib/libc-2.23.so
0ffa4000-0ffa8000 r--p 0017c000 00:0f 191 /lib/libc-2.23.so
0ffa8000-0ffac000 rwxp 00180000 00:0f 191 /lib/libc-2.23.so
0ffac000-0ffb0000 rwxp 00000000 00:00 0
0ffc0000-0ffd4000 r-xp 00000000 00:0f 90 /lib/libhugetlbfs.so
0ffd4000-0ffe0000 ---p 00014000 00:0f 90 /lib/libhugetlbfs.so
0ffe0000-0ffe4000 rwxp 00010000 00:0f 90 /lib/libhugetlbfs.so
0ffe4000-0fff0000 rwxp 00000000 00:00 0
10000000-10004000 r-xp 00000000 00:0f 3076 /root/huge_malloc_test
10010000-10014000 rwxp 00000000 00:0f 3076 /root/huge_malloc_test
77ee0000-77f04000 r-xp 00000000 00:0f 171 /lib/ld-2.23.so
77f1c000-77f20000 r--p 0002c000 00:0f 171 /lib/ld-2.23.so
77f20000-77f24000 rwxp 00030000 00:0f 171 /lib/ld-2.23.so
7f830000-7f854000 rw-p 00000000 00:00 0 [stack]
Allocated 1Mbytes at 0x30000008
Allocated 1Mbytes at 0x30100010
Allocated 1Mbytes at 0x30200018
00100000-00108000 r-xp 00000000 00:00 0 [vdso]
0fde4000-0fde8000 r-xp 00000000 00:0f 168 /lib/libdl-2.23.so
0fde8000-0fe00000 ---p 00004000 00:0f 168 /lib/libdl-2.23.so
0fe00000-0fe04000 r--p 0000c000 00:0f 168 /lib/libdl-2.23.so
0fe04000-0fe08000 rwxp 00010000 00:0f 168 /lib/libdl-2.23.so
0fe18000-0ff88000 r-xp 00000000 00:0f 191 /lib/libc-2.23.so
0ff88000-0ffa4000 ---p 00170000 00:0f 191 /lib/libc-2.23.so
0ffa4000-0ffa8000 r--p 0017c000 00:0f 191 /lib/libc-2.23.so
0ffa8000-0ffac000 rwxp 00180000 00:0f 191 /lib/libc-2.23.so
0ffac000-0ffb0000 rwxp 00000000 00:00 0
0ffc0000-0ffd4000 r-xp 00000000 00:0f 90 /lib/libhugetlbfs.so
0ffd4000-0ffe0000 ---p 00014000 00:0f 90 /lib/libhugetlbfs.so
0ffe0000-0ffe4000 rwxp 00010000 00:0f 90 /lib/libhugetlbfs.so
0ffe4000-0fff0000 rwxp 00000000 00:00 0
10000000-10004000 r-xp 00000000 00:0f 3076 /root/huge_malloc_test
10010000-10014000 rwxp 00000000 00:0f 3076 /root/huge_malloc_test
30000000-30180000 rw-p 00000000 00:0b 7682 /anon_hugepage (deleted)
30180000-30280000 rw-p 00180000 00:0b 7683 /anon_hugepage (deleted)
30280000-30380000 rw-p 00280000 00:0b 7684 /anon_hugepage (deleted)
77ee0000-77f04000 r-xp 00000000 00:0f 171 /lib/ld-2.23.so
77f1c000-77f20000 r--p 0002c000 00:0f 171 /lib/ld-2.23.so
77f20000-77f24000 rwxp 00030000 00:0f 171 /lib/ld-2.23.so
7f830000-7f854000 rw-p 00000000 00:00 0 [stack]
On your side, could you try and see with
HUGETLB_MORECORE_HEAPBASE=0x11000000 ?
Christophe
>>
>> If you are on ppc64 irc on freenode we can discuss this there.
>> -aneesh
^ permalink raw reply
* Re: [PATCH v2] cpufreq: powernv: Add support of frequency domain
From: Abhishek @ 2018-01-22 8:30 UTC (permalink / raw)
To: Viresh Kumar; +Cc: rjw, benh, paulus, mpe, linux-pm, linuxppc-dev, linux-kernel
In-Reply-To: <20171220065028.GW19815@vireshk-i7>
On 12/20/2017 12:20 PM, Viresh Kumar wrote:
> On 20-12-17, 12:12, Abhishek Goel wrote:
>> diff --git a/drivers/cpufreq/powernv-cpufreq.c b/drivers/cpufreq/powernv-cpufreq.c
>> index b6d7c4c..fd642bc 100644
>> --- a/drivers/cpufreq/powernv-cpufreq.c
>> +++ b/drivers/cpufreq/powernv-cpufreq.c
>> @@ -37,6 +37,7 @@
>> #include <asm/smp.h> /* Required for cpu_sibling_mask() in UP configs */
>> #include <asm/opal.h>
>> #include <linux/timer.h>
>> +#include <linux/hashtable.h>
>>
>> #define POWERNV_MAX_PSTATES 256
>> #define PMSR_PSAFE_ENABLE (1UL << 30)
>> @@ -130,6 +131,9 @@ static struct chip {
>> static int nr_chips;
>> static DEFINE_PER_CPU(struct chip *, chip_info);
>>
>> +static u32 freq_domain_indicator;
>> +static u32 flag;
> I wouldn't name it as flag, its unreadable. Maybe its better to name
> it based on the quirk you are trying to workaround with ?
>
>> +
>> /*
>> * Note:
>> * The set of pstates consists of contiguous integers.
>> @@ -194,6 +198,38 @@ static inline void reset_gpstates(struct cpufreq_policy *policy)
>> gpstates->last_gpstate_idx = 0;
>> }
>>
>> +#define SIZE NR_CPUS
>> +#define ORDER_FREQ_MAP ilog2(SIZE)
>> +
>> +static DEFINE_HASHTABLE(freq_domain_map, ORDER_FREQ_MAP);
>> +
>> +struct hashmap {
>> + cpumask_t mask;
>> + int chip_id;
>> + u32 pir_key;
>> + struct hlist_node hash_node;
>> +};
>> +
>> +static void insert(u32 key, int cpu)
>> +{
>> + struct hashmap *data;
>> +
>> + hash_for_each_possible(freq_domain_map, data, hash_node, key%SIZE) {
>> + if (data->chip_id == cpu_to_chip_id(cpu) &&
>> + data->pir_key == key) {
>> + cpumask_set_cpu(cpu, &data->mask);
>> + return;
>> + }
>> + }
>> +
>> + data = kzalloc(sizeof(*data), GFP_KERNEL);
>> + hash_add(freq_domain_map, &data->hash_node, key%SIZE);
>> + cpumask_set_cpu(cpu, &data->mask);
>> + data->chip_id = cpu_to_chip_id(cpu);
>> + data->pir_key = key;
>> +
>> +}
>> +
>> /*
>> * Initialize the freq table based on data obtained
>> * from the firmware passed via device-tree
>> @@ -206,7 +242,9 @@ static int init_powernv_pstates(void)
>> u32 len_ids, len_freqs;
>> u32 pstate_min, pstate_max, pstate_nominal;
>> u32 pstate_turbo, pstate_ultra_turbo;
>> + u32 key;
>>
>> + flag = 0;
> Isn't flag already 0 (global-uninitialized) ?
>
>> power_mgt = of_find_node_by_path("/ibm,opal/power-mgt");
>> if (!power_mgt) {
>> pr_warn("power-mgt node not found\n");
>> @@ -229,6 +267,17 @@ static int init_powernv_pstates(void)
>> return -ENODEV;
>> }
>>
>> + if (of_device_is_compatible(power_mgt, "freq-domain-v1") &&
>> + of_property_read_u32(power_mgt, "ibm,freq-domain-indicator",
>> + &freq_domain_indicator)) {
>> + pr_warn("ibm,freq-domain-indicator not found\n");
>> + freq_domain_indicator = 0;
> You shouldn't be required to set it to 0 here.
>
>> + }
>> +
>> + if (of_device_is_compatible(power_mgt, "P9-occ-quirk")) {
>> + flag = 1;
>> + }
> Remove {} and a better name like p9_occ_quirk would be good for flag.
> Also making it a bool may be better ?
>
>> +
>> if (of_property_read_u32(power_mgt, "ibm,pstate-ultra-turbo",
>> &pstate_ultra_turbo)) {
>> powernv_pstate_info.wof_enabled = false;
>> @@ -249,6 +298,7 @@ static int init_powernv_pstates(void)
>> next:
>> pr_info("cpufreq pstate min %d nominal %d max %d\n", pstate_min,
>> pstate_nominal, pstate_max);
>> + pr_info("frequency domain indicator %d", freq_domain_indicator);
>> pr_info("Workload Optimized Frequency is %s in the platform\n",
>> (powernv_pstate_info.wof_enabled) ? "enabled" : "disabled");
>>
>> @@ -276,6 +326,15 @@ static int init_powernv_pstates(void)
>> return -ENODEV;
>> }
>>
>> + if (freq_domain_indicator) {
>> + hash_init(freq_domain_map);
>> + for_each_possible_cpu(i) {
>> + key = ((u32) get_hard_smp_processor_id(i) &
>> + freq_domain_indicator);
> Maybe break it like:
>
> key = (u32) get_hard_smp_processor_id(i);
> key &= freq_domain_indicator;
>
> to make it easily readable ?
>
>> + insert(key, i);
>> + }
>> + }
>> +
>> powernv_pstate_info.nr_pstates = nr_pstates;
>> pr_debug("NR PStates %d\n", nr_pstates);
>> for (i = 0; i < nr_pstates; i++) {
>> @@ -693,6 +752,7 @@ static int powernv_cpufreq_target_index(struct cpufreq_policy *policy,
>> {
>> struct powernv_smp_call_data freq_data;
>> unsigned int cur_msec, gpstate_idx;
>> +
> :(
>
>> struct global_pstate_info *gpstates = policy->driver_data;
>>
>> if (unlikely(rebooting) && new_index != get_nominal_index())
>> @@ -760,25 +820,55 @@ static int powernv_cpufreq_target_index(struct cpufreq_policy *policy,
>>
>> spin_unlock(&gpstates->gpstate_lock);
>>
>> - /*
>> - * Use smp_call_function to send IPI and execute the
>> - * mtspr on target CPU. We could do that without IPI
>> - * if current CPU is within policy->cpus (core)
>> - */
>> - smp_call_function_any(policy->cpus, set_pstate, &freq_data, 1);
>> + if (flag) {
> Maybe add a comment over this on why you need to do things differently
> here, as it isn't obvious.
>
>> + cpumask_t temp;
>> + u32 cpu;
>> +
>> + /*
>> + * Use smp_call_function to send IPI and execute the mtspr
>> + * on CPU. This needs to be done on every core of the policy.
>> + */
>> + cpumask_copy(&temp, policy->cpus);
>> + while (!cpumask_empty(&temp)) {
>> + cpu = cpumask_first(&temp);
>> + smp_call_function_any(cpu_sibling_mask(cpu),
>> + set_pstate, &freq_data, 1);
>> + cpumask_andnot(&temp, &temp, cpu_sibling_mask(cpu));
>> + }
>> + } else {
>> + smp_call_function_any(policy->cpus, set_pstate, &freq_data, 1);
>> + }
>> +
>> return 0;
>> }
>>
>> static int powernv_cpufreq_cpu_init(struct cpufreq_policy *policy)
>> {
>> - int base, i, ret;
>> + int ret;
>> struct kernfs_node *kn;
>> struct global_pstate_info *gpstates;
>>
>> - base = cpu_first_thread_sibling(policy->cpu);
>> + if (!freq_domain_indicator) {
>> + int base, i;
>>
>> - for (i = 0; i < threads_per_core; i++)
>> - cpumask_set_cpu(base + i, policy->cpus);
>> + base = cpu_first_thread_sibling(policy->cpu);
>> + for (i = 0; i < threads_per_core; i++)
>> + cpumask_set_cpu(base + i, policy->cpus);
>> + } else {
>> + u32 key;
>> + struct hashmap *data;
>> +
>> + key = ((u32) get_hard_smp_processor_id(policy->cpu) &
>> + freq_domain_indicator);
>> + hash_for_each_possible(freq_domain_map, data, hash_node,
>> + key%SIZE) {
>> + if (data->chip_id == cpu_to_chip_id(policy->cpu) &&
>> + data->pir_key == key) {
>> + cpumask_copy(policy->cpus, &data->mask);
>> + break;
>> + }
>> + }
>> + }
>>
>> kn = kernfs_find_and_get(policy->kobj.sd, throttle_attr_grp.name);
>> if (!kn) {
>> --
>> 2.9.3
Have posted the next version with the changes made as suggested. Also
the skiboot patch required for the device tree changes made is posted
here : http://patchwork.ozlabs.org/patch/862256/
-Abhishek
^ permalink raw reply
* Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues
From: Frank Rowand @ 2018-01-22 8:43 UTC (permalink / raw)
To: Wolfram Sang, devicetree
Cc: Tyrel Datwyler, Geert Uytterhoeven, linux-renesas-soc,
linuxppc-dev, Rob Herring, Steven Rostedt, linux-kernel
In-Reply-To: <20180121143117.19805-1-wsa+renesas@sang-engineering.com>
On 01/21/18 06:31, Wolfram Sang wrote:
> I got a bug report for a DT node refcounting problem in the I2C subsystem. This
> patch was a huge help in validating the bug report and the proposed solution.
> So, I thought I bring it to attention again. Thanks Tyrel, for the initial
> work!
>
> Note that I did not test the dynamic updates, only of_node_{get|put} so far. I
> read that Tyrel checked dynamic updates extensively with this patch. And since
> DT overlays are also used within our Renesas dev team, this will help there, as
> well.
>
> Tested on a Renesas Salvator-XS board (R-Car H3).
>
> Changes since RFC v1:
> * rebased to v4.15-rc8
> * fixed commit abbrev and one of the sysfs paths in commit desc
> * removed trailing space and fixed pointer declaration in code
>
> I consider all the remaining checkpatch issues irrelevant for this patch.
>
> So what about applying it?
>
> Kind regards,
>
> Wolfram
>
>
> Tyrel Datwyler (1):
> of: introduce event tracepoints for dynamic device_node lifecyle
>
> drivers/of/dynamic.c | 32 ++++++----------
> include/trace/events/of.h | 93 +++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 105 insertions(+), 20 deletions(-)
> create mode 100644 include/trace/events/of.h
>
Please go back and read the thread for version 1. Simply resubmitting a
forward port is ignoring that whole conversation.
There is a lot of good info in that thread. I certainly learned stuff in it.
Thanks,
Frank
^ permalink raw reply
* Re: [RFC PATCH v2 0/1] of: easier debugging for node life cycle issues
From: Wolfram Sang @ 2018-01-22 11:49 UTC (permalink / raw)
To: Frank Rowand
Cc: Wolfram Sang, devicetree, Tyrel Datwyler, Geert Uytterhoeven,
linux-renesas-soc, linuxppc-dev, Rob Herring, Steven Rostedt,
linux-kernel
In-Reply-To: <ac4f02e1-6d49-158a-4fb6-56ac0d474a44@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]
Hi Frank,
> Please go back and read the thread for version 1. Simply resubmitting a
> forward port is ignoring that whole conversation.
>
> There is a lot of good info in that thread. I certainly learned stuff in it.
Yes, I did that and learned stuff, too. My summary of the discussion was:
- you mentioned some drawbacks you saw (like the mixture of trace output
and printk output)
- most of them look like addressed to me? (e.g. Steven showed a way to redirect
printk to trace)
- you posted your version (which was, however, marked as "not user friendly"
even by yourself)
- The discussion stalled over having two approaches
So, I thought reposting would be a good way of finding out if your
concerns were addressed in the discussion or not. If I overlooked
something, I am sorry for that. Still, my intention is to continue the
discussion, not to ignore it. Because as it stands, we don't have such a
debugging mechanism in place currently, and with people working with DT
overlays, I'd think it would be nice to have.
Kind regards,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH v8 2/2] cxl: read PHB indications from the device tree
From: Philippe Bergheaud @ 2018-01-22 13:33 UTC (permalink / raw)
To: linuxppc-dev; +Cc: fbarrat, clombard, benh, Philippe Bergheaud
In-Reply-To: <20180122133339.2802-1-felix@linux.vnet.ibm.com>
Configure the P9 XSL_DSNCTL register with PHB indications found
in the device tree, or else use legacy hard-coded values.
Signed-off-by: Philippe Bergheaud <felix@linux.vnet.ibm.com>
---
Changelog:
v2: New patch. Use the new device tree property "ibm,phb-indications".
v3: No change.
v4: No functional change.
Drop cosmetic fix in comment.
v5: get_phb_indications():
- make static variables local to function.
- return static variable values by arguments.
v6: get_phb_indications():
- acquire a mutex before setting the phb indications.
v7: get_phb_indications():
cxl_get_xsl9_dsnctl():
- return -ENODEV instead of -1.
v8: get_phb_indications():
- stay on the safe side: acquire the mutex unconditionally
This patch depends on the following skiboot patch:
https://patchwork.ozlabs.org/patch/858324/
---
drivers/misc/cxl/cxl.h | 2 +-
drivers/misc/cxl/cxllib.c | 2 +-
drivers/misc/cxl/pci.c | 48 ++++++++++++++++++++++++++++++++++++++++++-----
3 files changed, 45 insertions(+), 7 deletions(-)
diff --git a/drivers/misc/cxl/cxl.h b/drivers/misc/cxl/cxl.h
index e46a4062904a..5a6e9a921c2b 100644
--- a/drivers/misc/cxl/cxl.h
+++ b/drivers/misc/cxl/cxl.h
@@ -1062,7 +1062,7 @@ int cxl_psl_purge(struct cxl_afu *afu);
int cxl_calc_capp_routing(struct pci_dev *dev, u64 *chipid,
u32 *phb_index, u64 *capp_unit_id);
int cxl_slot_is_switched(struct pci_dev *dev);
-int cxl_get_xsl9_dsnctl(u64 capp_unit_id, u64 *reg);
+int cxl_get_xsl9_dsnctl(struct pci_dev *dev, u64 capp_unit_id, u64 *reg);
u64 cxl_calculate_sr(bool master, bool kernel, bool real_mode, bool p9);
void cxl_native_irq_dump_regs_psl9(struct cxl_context *ctx);
diff --git a/drivers/misc/cxl/cxllib.c b/drivers/misc/cxl/cxllib.c
index dc9bc1807fdf..61f80d586279 100644
--- a/drivers/misc/cxl/cxllib.c
+++ b/drivers/misc/cxl/cxllib.c
@@ -99,7 +99,7 @@ int cxllib_get_xsl_config(struct pci_dev *dev, struct cxllib_xsl_config *cfg)
if (rc)
return rc;
- rc = cxl_get_xsl9_dsnctl(capp_unit_id, &cfg->dsnctl);
+ rc = cxl_get_xsl9_dsnctl(dev, capp_unit_id, &cfg->dsnctl);
if (rc)
return rc;
if (cpu_has_feature(CPU_FTR_POWER9_DD1)) {
diff --git a/drivers/misc/cxl/pci.c b/drivers/misc/cxl/pci.c
index 19969ee86d6f..12e5cae6d452 100644
--- a/drivers/misc/cxl/pci.c
+++ b/drivers/misc/cxl/pci.c
@@ -409,21 +409,59 @@ int cxl_calc_capp_routing(struct pci_dev *dev, u64 *chipid,
return 0;
}
-int cxl_get_xsl9_dsnctl(u64 capp_unit_id, u64 *reg)
+static DEFINE_MUTEX(indications_mutex);
+
+static int get_phb_indications(struct pci_dev *dev, u64* capiind, u64 *asnind,
+ u64 *nbwind)
+{
+ static u64 nbw, asn, capi = 0;
+ struct device_node *np;
+ const __be32 *prop;
+
+ mutex_lock(&indications_mutex);
+ if (!capi) {
+ if (!(np = pnv_pci_get_phb_node(dev))) {
+ mutex_unlock(&indications_mutex);
+ return -ENODEV;
+ }
+
+ prop = of_get_property(np, "ibm,phb-indications", NULL);
+ if (!prop) {
+ nbw = 0x0300UL; /* legacy values */
+ asn = 0x0400UL;
+ capi = 0x0200UL;
+ } else {
+ nbw = (u64)be32_to_cpu(prop[2]);
+ asn = (u64)be32_to_cpu(prop[1]);
+ capi = (u64)be32_to_cpu(prop[0]);
+ }
+ of_node_put(np);
+ }
+ *capiind = capi;
+ *asnind = asn;
+ *nbwind = nbw;
+ mutex_unlock(&indications_mutex);
+ return 0;
+}
+
+int cxl_get_xsl9_dsnctl(struct pci_dev *dev, u64 capp_unit_id, u64 *reg)
{
u64 xsl_dsnctl;
+ u64 capiind, asnind, nbwind;
/*
* CAPI Identifier bits [0:7]
* bit 61:60 MSI bits --> 0
* bit 59 TVT selector --> 0
*/
+ if (get_phb_indications(dev, &capiind, &asnind, &nbwind))
+ return -ENODEV;
/*
* Tell XSL where to route data to.
* The field chipid should match the PHB CAPI_CMPM register
*/
- xsl_dsnctl = ((u64)0x2 << (63-7)); /* Bit 57 */
+ xsl_dsnctl = (capiind << (63-15)); /* Bit 57 */
xsl_dsnctl |= (capp_unit_id << (63-15));
/* nMMU_ID Defaults to: b’000001001’*/
@@ -437,14 +475,14 @@ int cxl_get_xsl9_dsnctl(u64 capp_unit_id, u64 *reg)
* nbwind=0x03, bits [57:58], must include capi indicator.
* Not supported on P9 DD1.
*/
- xsl_dsnctl |= ((u64)0x03 << (63-47));
+ xsl_dsnctl |= (nbwind << (63-55));
/*
* Upper 16b address bits of ASB_Notify messages sent to the
* system. Need to match the PHB’s ASN Compare/Mask Register.
* Not supported on P9 DD1.
*/
- xsl_dsnctl |= ((u64)0x04 << (63-55));
+ xsl_dsnctl |= asnind;
}
*reg = xsl_dsnctl;
@@ -464,7 +502,7 @@ static int init_implementation_adapter_regs_psl9(struct cxl *adapter,
if (rc)
return rc;
- rc = cxl_get_xsl9_dsnctl(capp_unit_id, &xsl_dsnctl);
+ rc = cxl_get_xsl9_dsnctl(dev, capp_unit_id, &xsl_dsnctl);
if (rc)
return rc;
--
2.15.1
^ permalink raw reply related
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