* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Yijing Wang @ 2014-09-29 10:13 UTC (permalink / raw)
To: Lucas Stach
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, Bharat.Bhushan, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Thomas Petazzoni, Liviu Dudau, Tony Luck, Sergei Shtylyov,
linux-kernel, Ralf Baechle, iommu, David Vrabel, Wuyun,
linuxppc-dev, David S. Miller
In-Reply-To: <1411979850.2625.7.camel@pengutronix.de>
On 2014/9/29 16:37, Lucas Stach wrote:
> Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
>> On 2014/9/28 10:32, Yijing Wang wrote:
>>> On 2014/9/26 17:05, Thierry Reding wrote:
>>>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>>>> [...]
>>>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>>>> directly (patch attached).
>>>>
>>>> Really attached this time.
>>>>
>>>> Thierry
>>>>
>>>
>>> It looks good to me, so I will update the arm pci hostbridge driver to assign
>>> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
>>> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
>>> temporarily for more comments, especially from Bjorn.
>>
>> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
>> assign msi chip to root bus in all host drivers's scan functions.
>
> Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
> and I would think it would be no problem to to the same with rcar.
Good.
>
> Regards,
> Lucas
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Yijing Wang @ 2014-09-29 10:12 UTC (permalink / raw)
To: Liviu Dudau
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140929092600.GA15854@bart.dudau.co.uk>
>>> Not necessarily. What I have in mind is something like this:
>>
>> This is a good idea, what I'm worried is this series is already large, so I think we need to post
>> another series to do it.
>
> I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
> it comes to handling msi chip in an arch independent way.
It's a good suggestion, thanks! :)
>
>>
>>
^ permalink raw reply
* [PATCH] powerpc, powernv: Add OPAL platform event driver
From: Anshuman Khandual @ 2014-09-29 10:12 UTC (permalink / raw)
To: linuxppc-dev
This patch creates a new OPAL platform event character driver
which will give userspace clients the access to these events
and process them effectively. Following platforms events are
currently supported with this platform driver.
(1) Environmental and Power Warning (EPOW)
(2) Delayed Power Off (DPO)
The user interface for this driver is /dev/opal_event character
device file where the user space clients can poll and read for
new opal platform events. The expected sequence of events driven
from user space should be like the following.
(1) Open the character device file
(2) Poll on the file for POLLIN event
(3) When unblocked, must attempt to read PLAT_EVENT_MAX_SIZE size
(4) Kernel driver will pass at most one opal_plat_event structure
(5) Poll again for more new events
The driver registers for OPAL messages notifications corresponding to
individual OPAL events. When any of those event messages arrive in the
kernel, the callbacks are called to process them which in turn unblocks
the polling thread on the character device file. The driver also registers
a timer function which will be called after a threshold amount of time to
shutdown the system. The user space client receives the timeout value for
all individual OPAL platform events and hence must prepare the system and
eventually shutdown. In case the user client does not shutdown the system,
the timer function will be called after the threshold and shutdown the
system explicitly.
Signed-off-by: Anshuman Khandual <khandual@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/opal.h | 45 +-
.../include/uapi/asm/opal_platform_events.h | 90 +++
arch/powerpc/platforms/powernv/Makefile | 2 +-
.../platforms/powernv/opal-platform-events.c | 737 +++++++++++++++++++++
arch/powerpc/platforms/powernv/opal-wrappers.S | 1 +
arch/powerpc/platforms/powernv/opal.c | 8 +-
6 files changed, 880 insertions(+), 3 deletions(-)
create mode 100644 arch/powerpc/include/uapi/asm/opal_platform_events.h
create mode 100644 arch/powerpc/platforms/powernv/opal-platform-events.c
diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h
index 86055e5..c134137 100644
--- a/arch/powerpc/include/asm/opal.h
+++ b/arch/powerpc/include/asm/opal.h
@@ -151,6 +151,7 @@ struct opal_sg_list {
#define OPAL_HANDLE_HMI 98
#define OPAL_REGISTER_DUMP_REGION 101
#define OPAL_UNREGISTER_DUMP_REGION 102
+#define OPAL_GET_DPO_STATUS 105
#ifndef __ASSEMBLY__
@@ -249,6 +250,7 @@ enum OpalMessageType {
OPAL_MSG_EPOW,
OPAL_MSG_SHUTDOWN,
OPAL_MSG_HMI_EVT,
+ OPAL_MSG_DPO,
OPAL_MSG_TYPE_MAX,
};
@@ -417,6 +419,46 @@ struct opal_msg {
__be64 params[8];
};
+/*
+ * EPOW status sharing (OPAL and the host)
+ *
+ * The host will pass on OPAL, a buffer of length OPAL_SYSEPOW_MAX
+ * with individual elements being 16 bits wide to fetch the system
+ * wide EPOW status. Each element in the buffer will contain the
+ * EPOW status in it's bit representation for a particular EPOW sub
+ * class as defiend here. So multiple detailed EPOW status bits
+ * specific for any sub class can be represented in a single buffer
+ * element as it's bit representation.
+ */
+
+/* System EPOW type */
+enum OpalSysEpow {
+ OPAL_SYSEPOW_POWER = 0, /* Power EPOW */
+ OPAL_SYSEPOW_TEMP = 1, /* Temperature EPOW */
+ OPAL_SYSEPOW_COOLING = 2, /* Cooling EPOW */
+ OPAL_SYSEPOW_MAX = 3, /* Max EPOW categories */
+};
+
+/* Power EPOW */
+enum OpalSysPower {
+ OPAL_SYSPOWER_UPS = 0x0001, /* System on UPS power */
+ OPAL_SYSPOWER_CHNG = 0x0002, /* System power config change */
+ OPAL_SYSPOWER_FAIL = 0x0004, /* System impending power failure */
+ OPAL_SYSPOWER_INCL = 0x0008, /* System incomplete power */
+};
+
+/* Temperature EPOW */
+enum OpalSysTemp {
+ OPAL_SYSTEMP_AMB = 0x0001, /* System over ambient temperature */
+ OPAL_SYSTEMP_INT = 0x0002, /* System over internal temperature */
+ OPAL_SYSTEMP_HMD = 0x0004, /* System over ambient humidity */
+};
+
+/* Cooling EPOW */
+enum OpalSysCooling {
+ OPAL_SYSCOOL_INSF = 0x0001, /* System insufficient cooling */
+};
+
struct opal_machine_check_event {
enum OpalMCE_Version version:8; /* 0x00 */
uint8_t in_use; /* 0x01 */
@@ -881,7 +923,7 @@ int64_t opal_pci_fence_phb(uint64_t phb_id);
int64_t opal_pci_reinit(uint64_t phb_id, uint64_t reinit_scope, uint64_t data);
int64_t opal_pci_mask_pe_error(uint64_t phb_id, uint16_t pe_number, uint8_t error_type, uint8_t mask_action);
int64_t opal_set_slot_led_status(uint64_t phb_id, uint64_t slot_id, uint8_t led_type, uint8_t led_action);
-int64_t opal_get_epow_status(__be64 *status);
+int64_t opal_get_epow_status(uint16_t *status, uint16_t *length);
int64_t opal_set_system_attention_led(uint8_t led_action);
int64_t opal_pci_next_error(uint64_t phb_id, __be64 *first_frozen_pe,
__be16 *pci_error_type, __be16 *severity);
@@ -924,6 +966,7 @@ int64_t opal_sensor_read(uint32_t sensor_hndl, int token, __be32 *sensor_data);
int64_t opal_handle_hmi(void);
int64_t opal_register_dump_region(uint32_t id, uint64_t start, uint64_t end);
int64_t opal_unregister_dump_region(uint32_t id);
+int64_t opal_get_dpo_status(int64_t *dpo_timeout);
/* Internal functions */
extern int early_init_dt_scan_opal(unsigned long node, const char *uname,
diff --git a/arch/powerpc/include/uapi/asm/opal_platform_events.h b/arch/powerpc/include/uapi/asm/opal_platform_events.h
new file mode 100644
index 0000000..6d2e13e
--- /dev/null
+++ b/arch/powerpc/include/uapi/asm/opal_platform_events.h
@@ -0,0 +1,90 @@
+/*
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License, version 2, as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+ *
+ * Copyright IBM Corp. 2014
+ *
+ * Author: Anshuman Khandual <khandual@linux.vnet.ibm.com>
+ */
+#ifndef __LINUX_OPAL_PLATFORM_EVENTS_H
+#define __LINUX_OPAL_PLATFORM_EVENTS_H
+
+#include <linux/types.h>
+
+/* EPOW classification */
+enum epow_condition {
+ EPOW_SYSPOWER_CHNG = 0, /* Power */
+ EPOW_SYSPOWER_FAIL = 1,
+ EPOW_SYSPOWER_INCL = 2,
+ EPOW_SYSPOWER_UPS = 3,
+ EPOW_SYSTEMP_AMB = 4, /* Temperature */
+ EPOW_SYSTEMP_INT = 5,
+ EPOW_SYSTEMP_HMD = 6,
+ EPOW_SYSCOOL_INSF = 7, /* Cooling */
+ EPOW_MAX = 8,
+};
+
+/* OPAL EPOW event */
+struct epow_event {
+ __u64 epow[EPOW_MAX]; /* Detailed system EPOW status */
+ __u64 timeout; /* Timeout to shutdown in secs */
+};
+
+/* OPAL DPO event */
+struct dpo_event {
+ __u64 orig_timeout; /* Platform provided timeout in secs */
+ __u64 remain_timeout; /* Timeout to shutdown in secs */
+};
+
+/* OPAL event */
+struct opal_plat_event {
+ __u32 type; /* Type of OPAL platform event */
+#define OPAL_PLAT_EVENT_TYPE_EPOW 0
+#define OPAL_PLAT_EVENT_TYPE_DPO 1
+#define OPAL_PLAT_EVENT_TYPE_MAX 2
+ __u32 size; /* Size of OPAL platform event */
+ union {
+ struct epow_event epow; /* EPOW platform event */
+ struct dpo_event dpo; /* DPO platform event */
+ };
+};
+
+/*
+ * Suggested read size
+ *
+ * The user space client should attempt to read OPAL_PLAT_EVENT_READ_SIZE
+ * amount of data from the character device file '/dev/opal_event' at any
+ * point of time. The kernel driver will pass an entire opal_plat_event
+ * structure in every read. This ensures that minium data the user space
+ * client gets from the kernel is one opal_plat_event structure.
+ */
+#define PLAT_EVENT_MAX_SIZE 4096
+
+/*
+ * Suggested user operation
+ *
+ * The user space client must follow these steps in order to be able to
+ * exploit the features exported through the OPAL platform event driver.
+ *
+ * (1) Open the character device file
+ * (2) Poll on the file for POLLIN
+ * (3) When unblocked, must attempt to read PLAT_EVENT_MAX_SIZE size
+ * (4) Kernel driver will pass one opal_plat_event structure
+ * (5) Poll again for more new events
+ *
+ * The character device file (/dev/opal_event) must be opened and operated by
+ * only one user space client at any point of time. Other attempts to open the
+ * file will be returned by the driver as EBUSY.
+ */
+
+#endif /* __LINUX_OPAL_PLATFORM_EVENTS_H */
diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile
index f241acc..c4b3b9b 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -1,7 +1,7 @@
obj-y += setup.o opal-wrappers.o opal.o opal-async.o
obj-y += opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o
obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o opal-sensor.o
-obj-y += opal-msglog.o opal-hmi.o
+obj-y += opal-msglog.o opal-hmi.o opal-platform-events.o
obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o
obj-$(CONFIG_PCI) += pci.o pci-p5ioc2.o pci-ioda.o
diff --git a/arch/powerpc/platforms/powernv/opal-platform-events.c b/arch/powerpc/platforms/powernv/opal-platform-events.c
new file mode 100644
index 0000000..5e87d2b
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/opal-platform-events.c
@@ -0,0 +1,737 @@
+/*
+ * IBM PowerNV OPAL platform events driver
+ *
+ * Copyright IBM Corporation 2014
+ *
+ * Author: Anshuman Khandual <khandual@linux.vnet.ibm.com>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+#define PREFIX "OPAL_EVENT"
+#define pr_fmt(fmt) PREFIX ": " fmt
+
+#include <linux/kernel.h>
+#include <linux/of.h>
+#include <linux/of_device.h>
+#include <linux/of_platform.h>
+#include <linux/fs.h>
+#include <linux/module.h>
+#include <linux/cdev.h>
+#include <linux/list.h>
+#include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/poll.h>
+#include <linux/timer.h>
+#include <linux/reboot.h>
+#include <asm/uaccess.h>
+#include <asm/opal.h>
+#include <asm/opal_platform_events.h>
+
+/* Platform events driver */
+static dev_t opal_event_dev;
+static struct cdev opal_event_cdev;
+static struct class *opal_event_class;
+static bool opal_event_open_flag;
+
+#define OPAL_EVENT_MAX_DEVS 1
+
+/* Platform events timers */
+static struct timer_list opal_event_timer;
+
+static DECLARE_WAIT_QUEUE_HEAD(opal_plat_evt_wait);
+static DECLARE_WAIT_QUEUE_HEAD(opal_plat_open_wait);
+static DEFINE_SPINLOCK(opal_plat_evt_spinlock);
+static DEFINE_SPINLOCK(opal_plat_timer_spinlock);
+static DEFINE_MUTEX(opal_plat_evt_mutex);
+
+/*
+ * Platform timeout values
+ *
+ * XXX: The default timeout value is 5 minutes. In future this
+ * should be communicated from the platform firmware through
+ * device tree attributes.
+ */
+#define OPAL_EPOW_TIMEOUT 300
+
+struct opal_platform_evt {
+ struct opal_plat_event opal_event;
+ struct list_head link;
+};
+static LIST_HEAD(opal_event_queue);
+static unsigned long opal_dpo_target;
+static bool opal_event_probe_finished;
+
+/*
+ * OPAL event map
+ *
+ * Converts OPAL event type into it's description.
+ */
+static const char *opal_event_map[OPAL_PLAT_EVENT_TYPE_MAX] = {
+ "OPAL_PLAT_EVENT_TYPE_EPOW", "OPAL_PLAT_EVENT_TYPE_DPO"
+};
+
+/*
+ * opal_event_timeout
+ *
+ * This is the actual timer handler. If the any of the timers
+ * expire, this function will be called to shutdown the system
+ * gracefully.
+ */
+static void opal_event_timeout(unsigned long data)
+{
+ orderly_poweroff(1);
+}
+
+/*
+ * opal_event_start_timer
+ *
+ * This will start opal event timer with given timeout value as the expiry
+ * if either the timer is not active or the expiry value of the already
+ * activated timer is at a later point of time in the future compared to the
+ * timeout value for this given new event. The function mod_timer takes care
+ * all the cases whether the opal event timer is already active or not.
+ */
+static void opal_event_start_timer(unsigned long event, u64 timeout)
+{
+ unsigned long flags;
+
+ /* Timer active with earlier timeout */
+ spin_lock_irqsave(&opal_plat_timer_spinlock, flags);
+ if (timer_pending(&opal_event_timer) &&
+ (opal_event_timer.expires < (jiffies + timeout * HZ))) {
+ spin_unlock_irqrestore(&opal_plat_timer_spinlock, flags);
+ pr_info("Timer for %s event active with an earlier timeout\n",
+ opal_event_map[opal_event_timer.data]);
+ return;
+ }
+ opal_event_timer.data = event;
+ mod_timer(&opal_event_timer, jiffies + timeout * HZ);
+ spin_unlock_irqrestore(&opal_plat_timer_spinlock, flags);
+ pr_info("Timer activated for %s event\n", opal_event_map[event]);
+}
+
+/*
+ * opal_event_stop_timer
+ *
+ * This will attempt to stop opal_event_timer if it is already enabled.
+ */
+static void opal_event_stop_timer(void)
+{
+ unsigned long flags;
+
+ spin_lock_irqsave(&opal_plat_timer_spinlock, flags);
+ del_timer_sync(&opal_event_timer);
+ spin_unlock_irqrestore(&opal_plat_timer_spinlock, flags);
+ pr_info("Timer deactivated\n");
+}
+
+/*
+ * opal_event_read
+ *
+ * User client needs to attempt to read PLAT_EVENT_MAX_SIZE amount of data
+ * from the file descriptor at a time. The driver will pass a single node
+ * from the list if available at a time and then delete the node from the list.
+ */
+static ssize_t opal_event_read(struct file *filep,
+ char __user *buf, size_t len, loff_t *off)
+{
+ struct opal_platform_evt *evt;
+ unsigned long flags;
+
+ if (len < sizeof(struct opal_plat_event))
+ return -EINVAL;
+
+ /* Fetch the first node on the list */
+ spin_lock_irqsave(&opal_plat_evt_spinlock, flags);
+ if (list_empty(&opal_event_queue)) {
+ spin_unlock_irqrestore(&opal_plat_evt_spinlock, flags);
+ return 0;
+ }
+
+ /* Fetch and delete from the list */
+ evt = list_first_entry(&opal_event_queue,
+ struct opal_platform_evt, link);
+ list_del(&evt->link);
+
+ /*
+ * Update the remaining timeout for DPO event.
+ * This can only be updated during the read time.
+ */
+ if (evt->opal_event.type == OPAL_PLAT_EVENT_TYPE_DPO) {
+ unsigned long timeout;
+
+ if (opal_dpo_target &&
+ evt->opal_event.dpo.orig_timeout) {
+ timeout = (opal_dpo_target - jiffies) / HZ;
+ evt->opal_event.dpo.remain_timeout = timeout;
+ }
+ }
+ spin_unlock_irqrestore(&opal_plat_evt_spinlock, flags);
+
+ if (copy_to_user(buf, &evt->opal_event,
+ sizeof(struct opal_plat_event))) {
+
+ /*
+ * Copy to user has failed. The event node had
+ * been deleted from the list. Lets add it back
+ * there.
+ */
+ spin_lock_irqsave(&opal_plat_evt_spinlock, flags);
+ list_add_tail(&evt->link, &opal_event_queue);
+ spin_unlock_irqrestore(&opal_plat_evt_spinlock, flags);
+ return -EFAULT;
+ }
+
+ kfree(evt);
+ return sizeof(struct opal_plat_event);
+}
+
+/*
+ * opal_event_poll
+ *
+ * Poll is unblocked right away with POLLIN when data is available.
+ * When data is not available, the process will have to block till
+ * it gets waked up and data is available to read.
+ */
+static unsigned int opal_event_poll(struct file *file, poll_table *wait)
+{
+ poll_wait(file, &opal_plat_evt_wait, wait);
+ if (!list_empty(&opal_event_queue))
+ return POLLIN;
+ return 0;
+}
+
+/*
+ * opal_event_open
+ *
+ * This makes sure that only one process can open the
+ * character device file at any point of time. Others
+ * attempting to open the file descriptor will either
+ * get EBUSY (with O_NONBLOCK flag) or wait for the
+ * other process to close the file descriptor.
+ */
+static int opal_event_open(struct inode *inode, struct file *file)
+{
+ int err;
+
+ mutex_lock(&opal_plat_evt_mutex);
+ while (opal_event_open_flag) {
+ mutex_unlock(&opal_plat_evt_mutex);
+ if (file->f_flags & O_NONBLOCK)
+ return -EBUSY;
+ err = wait_event_interruptible(opal_plat_open_wait,
+ !opal_event_open_flag);
+ if (err)
+ return -ERESTARTSYS;
+ mutex_lock(&opal_plat_evt_mutex);
+ }
+ opal_event_open_flag = true;
+ mutex_unlock(&opal_plat_evt_mutex);
+ return 0;
+}
+
+/*
+ * opal_event_release
+ *
+ * Releases the file descriptor for the device file.
+ */
+static int opal_event_release(struct inode *inode, struct file *file)
+{
+ mutex_lock(&opal_plat_evt_mutex);
+ if (opal_event_open_flag) {
+ opal_event_open_flag = false;
+ wake_up_interruptible(&opal_plat_open_wait);
+ }
+ mutex_unlock(&opal_plat_evt_mutex);
+ return 0;
+}
+
+/* Defined file operation */
+static const struct file_operations fops = {
+ .owner = THIS_MODULE,
+ .open = opal_event_open,
+ .release = opal_event_release,
+ .read = opal_event_read,
+ .poll = opal_event_poll,
+};
+
+/* Process the received EPOW information */
+void process_epow(__u64 *epow, int16_t *epow_status, int max_epow_class)
+{
+ /*
+ * Platform might have returned less number of EPOW
+ * subclass status than asked for. This situation
+ * happens when the platform firmware is older compared
+ * to the kernel.
+ */
+
+ if (!max_epow_class) {
+ pr_warn("EPOW: OPAL_SYSEPOW_POWER subclass not present\n");
+ return;
+ }
+
+ /* Power */
+ max_epow_class--;
+ if (epow_status[OPAL_SYSEPOW_POWER] & OPAL_SYSPOWER_CHNG) {
+ pr_info("EPOW: Power configuration changed\n");
+ epow[EPOW_SYSPOWER_CHNG] = 1;
+ }
+
+ if (epow_status[OPAL_SYSEPOW_POWER] & OPAL_SYSPOWER_FAIL) {
+ pr_info("EPOW: Impending system power failure\n");
+ epow[EPOW_SYSPOWER_FAIL] = 1;
+ }
+
+ if (epow_status[OPAL_SYSEPOW_POWER] & OPAL_SYSPOWER_INCL) {
+ pr_info("EPOW: Incomplete system power\n");
+ epow[EPOW_SYSPOWER_INCL] = 1;
+ }
+
+ if (epow_status[OPAL_SYSEPOW_POWER] & OPAL_SYSPOWER_UPS) {
+ pr_info("EPOW: System on UPS power\n");
+ epow[EPOW_SYSPOWER_UPS] = 1;
+ }
+
+ if (!max_epow_class) {
+ pr_warn("EPOW: OPAL_SYSEPOW_TEMP subclass not present\n");
+ return;
+ }
+
+ /* Temperature */
+ max_epow_class--;
+ if (epow_status[OPAL_SYSEPOW_TEMP] & OPAL_SYSTEMP_AMB) {
+ pr_info("EPOW: Over ambient temperature\n");
+ epow[EPOW_SYSTEMP_AMB] = 1;
+ }
+
+ if (epow_status[OPAL_SYSEPOW_TEMP] & OPAL_SYSTEMP_INT) {
+ pr_info("EPOW: Over internal temperature\n");
+ epow[EPOW_SYSTEMP_INT] = 1;
+ }
+
+ if (epow_status[OPAL_SYSEPOW_TEMP] & OPAL_SYSTEMP_HMD) {
+ pr_info("EPOW: Over internal humidity\n");
+ epow[EPOW_SYSTEMP_HMD] = 1;
+ }
+
+ if (!max_epow_class) {
+ pr_warn("EPOW: OPAL_SYSEPOW_COOLING subclass not present\n");
+ return;
+ }
+
+ /* Cooling */
+ max_epow_class--;
+ if (epow_status[OPAL_SYSEPOW_COOLING] & OPAL_SYSCOOL_INSF) {
+ pr_info("EPOW: Insufficient cooling\n");
+ epow[EPOW_SYSCOOL_INSF] = 1;
+ }
+}
+
+/*
+ * fetch_epow_status
+ *
+ * Fetch the system EPOW status through an OPAL call and
+ * validate the number of EPOW sub class status received.
+ */
+static void fetch_epow_status(int16_t *epow_status, int16_t *n_epow)
+{
+ int rc;
+
+ memset(epow_status, 0, sizeof(int16_t) * OPAL_SYSEPOW_MAX);
+ *n_epow = OPAL_SYSEPOW_MAX;
+ rc = opal_get_epow_status(epow_status, n_epow);
+ if (rc != OPAL_SUCCESS) {
+ pr_err("EPOW: OPAL call failed\n");
+ memset(epow_status, 0, sizeof(int16_t) * OPAL_SYSEPOW_MAX);
+ *n_epow = 0;
+ return;
+ }
+ if (!(*n_epow))
+ pr_err("EPOW: No subclass status received\n");
+}
+
+/*
+ * fetch_dpo_timeout
+ *
+ * Fetch the system DPO timeout status through an OPAL call.
+ */
+static void fetch_dpo_timeout(int64_t *dpo_timeout)
+{
+ int rc;
+
+ rc = opal_get_dpo_status(dpo_timeout);
+ if (rc != OPAL_SUCCESS) {
+ pr_err("DPO: OPAL call failed\n");
+ *dpo_timeout = 0;
+ return;
+ }
+}
+
+/*
+ * valid_epow
+ *
+ * Validate the received EPOW event status. This ensures
+ * that there are valid status for various EPOW sub classes
+ * and their individual events.
+ */
+static bool valid_epow(int16_t *epow_status, int16_t n_epow)
+{
+ int i;
+
+ /* EPOW sub classes present */
+ if (!n_epow)
+ return false;
+
+ /* EPOW events present */
+ for (i = 0; i < n_epow; i++) {
+ if (epow_status[i])
+ return true;
+ }
+ return false;
+}
+
+/*
+ * epow_exclude
+ *
+ * XXX: EPOW events on the action exclude list. System shutdown
+ * would not be scheduled for all these platform events. In future
+ * this should be communicated from the platform firmware through
+ * device tree attributes.
+ */
+static bool epow_exclude(int epow_event)
+{
+ switch (epow_event) {
+ case EPOW_SYSPOWER_CHNG:
+ return true;
+ case EPOW_SYSPOWER_INCL:
+ return true;
+ case EPOW_SYSPOWER_UPS:
+ return true;
+ case EPOW_SYSTEMP_HMD:
+ return true;
+ case EPOW_SYSCOOL_INSF:
+ return true;
+ default:
+ return false;
+ }
+}
+
+/*
+ * actionable_epow
+ *
+ * There are some EPOW events for which the user client must receive
+ * their status but the driver would not schedule a timer for that
+ * event as the platform would not force shutdown the system because
+ * of this event. This filters only the actionable EPOW events for
+ * which shutdown timer need to be scheduled.
+ */
+static bool actionable_epow(__u64 *epow)
+{
+ int i;
+
+ for (i = 0; i < EPOW_MAX; i++) {
+ if (!epow_exclude(i) && epow[i])
+ return true;
+ }
+ return false;
+}
+
+/*
+ * opal_event_handle_basic
+ *
+ * Sets up the basic information for an opal platform event,
+ * activates the timer, adds to the list and wakes up waiting
+ * threads on the character device.
+ */
+static void opal_event_handle_basic(struct opal_platform_evt *evt,
+ unsigned long type, unsigned long timeout)
+{
+ unsigned long flags;
+
+ evt->opal_event.type = type;
+ switch (type) {
+ case OPAL_PLAT_EVENT_TYPE_EPOW:
+ evt->opal_event.size = sizeof(struct epow_event);
+ evt->opal_event.epow.timeout = timeout;
+ if (actionable_epow(evt->opal_event.epow.epow))
+ opal_event_start_timer(OPAL_PLAT_EVENT_TYPE_EPOW,
+ OPAL_EPOW_TIMEOUT);
+ break;
+ case OPAL_PLAT_EVENT_TYPE_DPO:
+ evt->opal_event.size = sizeof(struct dpo_event);
+ evt->opal_event.dpo.orig_timeout = timeout;
+ opal_event_start_timer(OPAL_PLAT_EVENT_TYPE_DPO, timeout);
+ break;
+ default:
+ pr_err("Unknown event type\n");
+ break;
+ }
+ spin_lock_irqsave(&opal_plat_evt_spinlock, flags);
+ list_add_tail(&evt->link, &opal_event_queue);
+ spin_unlock_irqrestore(&opal_plat_evt_spinlock, flags);
+ wake_up_interruptible(&opal_plat_evt_wait);
+}
+
+/*
+ * opal_event_existing_status
+ *
+ * Fetch and process existing opal platform event conditions
+ * present on the system. If events detected, add them to the
+ * list which can be consumed by the user space right away.
+ */
+static void opal_event_existing_status(void)
+{
+ struct opal_platform_evt *evt;
+ int64_t dpo_timeout;
+ int16_t epow_status[OPAL_SYSEPOW_MAX], n_epow;
+
+ fetch_epow_status(epow_status, &n_epow);
+ if (valid_epow(epow_status, n_epow)) {
+ evt = kzalloc(sizeof(struct opal_platform_evt), GFP_KERNEL);
+ if (!evt) {
+ pr_err("EPOW: Memory allocation for event failed\n");
+ return;
+ }
+ process_epow(evt->opal_event.epow.epow, epow_status, n_epow);
+ opal_event_handle_basic(evt, OPAL_PLAT_EVENT_TYPE_EPOW,
+ OPAL_EPOW_TIMEOUT);
+ }
+
+ fetch_dpo_timeout(&dpo_timeout);
+ if (dpo_timeout) {
+ evt = kzalloc(sizeof(struct opal_platform_evt), GFP_KERNEL);
+ if (!evt) {
+ pr_err("DPO: Memory allocation for event failed\n");
+ return;
+ }
+ opal_dpo_target = jiffies + dpo_timeout * HZ;
+ opal_event_handle_basic(evt, OPAL_PLAT_EVENT_TYPE_DPO,
+ dpo_timeout);
+ }
+}
+
+/* Platform EPOW message received */
+static int opal_epow_event(struct notifier_block *nb,
+ unsigned long msg_type, void *msg)
+{
+ struct opal_platform_evt *evt;
+ int16_t epow_status[OPAL_SYSEPOW_MAX], n_epow;
+
+ if (msg_type != OPAL_MSG_EPOW)
+ return 0;
+
+ fetch_epow_status(epow_status, &n_epow);
+ if (!valid_epow(epow_status, n_epow))
+ return -EINVAL;
+
+ pr_debug("EPOW event: Power(%x) Thermal(%x) Cooling(%x)\n",
+ epow_status[0], epow_status[1], epow_status[2]);
+ evt = kzalloc(sizeof(struct opal_platform_evt), GFP_KERNEL);
+ if (!evt) {
+ pr_err("EPOW: Memory allocation for event failed\n");
+ return -ENOMEM;
+ }
+ process_epow(evt->opal_event.epow.epow, epow_status, n_epow);
+ opal_event_handle_basic(evt,
+ OPAL_PLAT_EVENT_TYPE_EPOW, OPAL_EPOW_TIMEOUT);
+ return 0;
+}
+
+/* Platform DPO message received */
+static int opal_dpo_event(struct notifier_block *nb,
+ unsigned long msg_type, void *msg)
+{
+ struct opal_platform_evt *evt;
+ int64_t dpo_timeout;
+
+ if (msg_type != OPAL_MSG_DPO)
+ return 0;
+
+ fetch_dpo_timeout(&dpo_timeout);
+ if (!dpo_timeout)
+ return -EINVAL;
+
+ pr_debug("DPO event: Timeout:%llu\n", dpo_timeout);
+ evt = kzalloc(sizeof(struct opal_platform_evt), GFP_KERNEL);
+ if (!evt) {
+ pr_err("DPO: Memory allocation for event failed\n");
+ return -ENOMEM;
+ }
+ opal_dpo_target = jiffies + dpo_timeout * HZ;
+ opal_event_handle_basic(evt, OPAL_PLAT_EVENT_TYPE_DPO, dpo_timeout);
+ return 0;
+}
+
+/* OPAL EPOW event notifier block */
+static struct notifier_block opal_epow_nb = {
+ .notifier_call = opal_epow_event,
+ .next = NULL,
+ .priority = 0,
+};
+
+/* OPAL DPO event notifier block */
+static struct notifier_block opal_dpo_nb = {
+ .notifier_call = opal_dpo_event,
+ .next = NULL,
+ .priority = 0,
+};
+
+/* Platform driver probe */
+static int opal_event_probe(struct platform_device *pdev)
+{
+ struct device *dev;
+ int ret;
+
+ if (opal_event_probe_finished) {
+ pr_err("%s getting called once again\n", __func__);
+ return 0;
+ }
+ opal_event_probe_finished = true;
+
+ init_timer(&opal_event_timer);
+ opal_event_timer.function = opal_event_timeout;
+ opal_event_open_flag = false;
+ opal_dpo_target = 0;
+
+ ret = alloc_chrdev_region(&opal_event_dev, 0,
+ OPAL_EVENT_MAX_DEVS, "opal_event");
+ if (ret < 0) {
+ dev_err(&pdev->dev, "aloc_chrdev_region failed\n");
+ return ret;
+ }
+
+ opal_event_class = class_create(THIS_MODULE, "opal_event");
+ if (IS_ERR(opal_event_class)) {
+ ret = PTR_ERR(opal_event_class);
+ dev_err(&pdev->dev, "class_create failed with %d\n", ret);
+ goto fail_chrdev;
+ }
+
+ dev = device_create(opal_event_class, &pdev->dev,
+ opal_event_dev, NULL, "opal_event");
+ if (IS_ERR(dev)) {
+ ret = PTR_ERR(dev);
+ dev_err(&pdev->dev, "device_create failed with %d\n", ret);
+ goto fail_class;
+ }
+
+ cdev_init(&opal_event_cdev, &fops);
+ ret = cdev_add(&opal_event_cdev, opal_event_dev, OPAL_EVENT_MAX_DEVS);
+ if (ret < 0) {
+ dev_err(dev, "cdev_add failed\n");
+ ret = -EINVAL;
+ goto fail_device;
+ }
+
+ ret = opal_message_notifier_register(OPAL_MSG_EPOW, &opal_epow_nb);
+ if (ret) {
+ pr_err("EPOW: Platform event message notifier failed\n");
+ goto fail_cdev;
+ }
+
+ ret = opal_message_notifier_register(OPAL_MSG_DPO, &opal_dpo_nb);
+ if (ret) {
+ pr_err("DPO: Platform event message notifier failed\n");
+ opal_notifier_unregister(&opal_epow_nb);
+ goto fail_cdev;
+ }
+
+ /*
+ * During the system boot, reboot and kexecs, the host can miss
+ * some of the EPOW or DPO messages sent from OPAL. This ensures
+ * that the current status of EPOW or DPO if any, is fetched and
+ * then updated correctly. The user space needs to first read the
+ * existing system status before entering into the poll/read loop.
+ *
+ */
+ opal_event_existing_status();
+ pr_info("OPAL platform event driver initialized\n");
+ return 0;
+fail_cdev:
+ cdev_del(&opal_event_cdev);
+fail_device:
+ device_destroy(opal_event_class, opal_event_dev);
+fail_class:
+ class_destroy(opal_event_class);
+fail_chrdev:
+ unregister_chrdev_region(opal_event_dev, OPAL_EVENT_MAX_DEVS);
+ return ret;
+}
+
+/* Platform driver remove */
+static int opal_event_remove(struct platform_device *pdev)
+{
+ struct opal_platform_evt *evt;
+
+ /* OPAL notifiers */
+ opal_notifier_unregister(&opal_dpo_nb);
+ opal_notifier_unregister(&opal_epow_nb);
+
+ /* Devices */
+ cdev_del(&opal_event_cdev);
+ device_destroy(opal_event_class, opal_event_dev);
+ class_destroy(opal_event_class);
+ unregister_chrdev_region(opal_event_dev, OPAL_EVENT_MAX_DEVS);
+
+ /* Timers */
+ opal_event_stop_timer();
+
+ /* Flush the list */
+ while (!list_empty(&opal_event_queue)) {
+ evt = list_first_entry(&opal_event_queue,
+ struct opal_platform_evt, link);
+ list_del(&evt->link);
+ kfree(evt);
+ }
+
+ pr_info("OPAL platform event driver exited\n");
+ return 0;
+}
+
+/* Platform driver property match */
+static struct of_device_id opal_event_match[] = {
+ {
+ .compatible = "ibm,opal-v3-epow",
+ },
+ {},
+};
+MODULE_DEVICE_TABLE(of, opal_event_match);
+
+static struct platform_driver opal_event_driver = {
+ .probe = opal_event_probe,
+ .remove = opal_event_remove,
+ .driver = {
+ .name = "opal-platform-event-driver",
+ .owner = THIS_MODULE,
+ .of_match_table = opal_event_match,
+ },
+};
+
+static int __init opal_platform_event_init(void)
+{
+ opal_event_probe_finished = false;
+ return platform_driver_register(&opal_event_driver);
+}
+
+static void __exit opal_platform_event_exit(void)
+{
+ platform_driver_unregister(&opal_event_driver);
+}
+module_init(opal_platform_event_init);
+module_exit(opal_platform_event_exit);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Anshuman Khandual <khandual@linux.vnet.ibm.com>");
+MODULE_DESCRIPTION("PowerNV OPAL platform events driver");
diff --git a/arch/powerpc/platforms/powernv/opal-wrappers.S b/arch/powerpc/platforms/powernv/opal-wrappers.S
index 2e6ce1b..2d1dc99 100644
--- a/arch/powerpc/platforms/powernv/opal-wrappers.S
+++ b/arch/powerpc/platforms/powernv/opal-wrappers.S
@@ -247,3 +247,4 @@ OPAL_CALL(opal_set_param, OPAL_SET_PARAM);
OPAL_CALL(opal_handle_hmi, OPAL_HANDLE_HMI);
OPAL_CALL(opal_register_dump_region, OPAL_REGISTER_DUMP_REGION);
OPAL_CALL(opal_unregister_dump_region, OPAL_UNREGISTER_DUMP_REGION);
+OPAL_CALL(opal_get_dpo_status, OPAL_GET_DPO_STATUS);
diff --git a/arch/powerpc/platforms/powernv/opal.c b/arch/powerpc/platforms/powernv/opal.c
index b44eec3..869dd45 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -625,7 +625,7 @@ static void __init opal_dump_region_init(void)
}
static int __init opal_init(void)
{
- struct device_node *np, *consoles;
+ struct device_node *np, *consoles, *epow;
const __be32 *irqs;
int rc, i, irqlen;
@@ -649,6 +649,12 @@ static int __init opal_init(void)
of_node_put(consoles);
}
+ epow = of_find_node_by_path("/ibm,opal/epow");
+ if (epow) {
+ of_platform_device_create(epow, "opal_event", NULL);
+ of_node_put(epow);
+ }
+
/* Find all OPAL interrupts and request them */
irqs = of_get_property(opal_node, "opal-interrupts", &irqlen);
pr_debug("opal: Found %d interrupts reserved for OPAL\n",
--
1.9.3
^ permalink raw reply related
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Liviu Dudau @ 2014-09-29 9:26 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <5428B971.50101@huawei.com>
On Mon, Sep 29, 2014 at 09:44:17AM +0800, Yijing Wang wrote:
> On 2014/9/28 19:21, Liviu Dudau wrote:
> > On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>>>> What I would like to see is a way of creating the pci_host_bridge structure outside
> >>>>>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> >>>>>> details like associated msi_chip into the host bridge and the child busses will
> >>>>>> have an easy way of finding the information needed by finding the root bus and then
> >>>>>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> >>>>>> everyone and the drivers can remove their kludges that try to work around the
> >>>>>> current limitations.
> >>>>
> >>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> >>>
> >>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> >>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> >>> sysdata around the pci_host_bridge*.
> >>
> >> I inspected every arch and found there are almost no common stuff,
> >
> > I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
>
> Most.
>
> > pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> > IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> > arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> > with the platform code due to convoluted way(s) in which PCI code gets instantiated.
>
> Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
> resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
> pci scan functions.
>
> >
> > What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> > common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> > we will have more commonality and it will be easier to re-factor the code.
>
> Now, I got it, thanks!
>
> >
> >> and generic data struct should
> >> be created in generic PCI code.
> >
> > Not necessarily. What I have in mind is something like this:
>
> This is a good idea, what I'm worried is this series is already large, so I think we need to post
> another series to do it.
I wasn't asking to do it here, I was just offering a suggestion (and sharing some experience) when
it comes to handling msi chip in an arch independent way.
>
>
> >
> > - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
> > and anything else that is needed (like find_pci_host_bridge() function).
> > - arch code does:
> >
> > struct pci_controller {
> > struct pci_host_bridge bridge;
> > .....
> > };
> >
> > #define to_pci_controller(bridge) container_of(bridge, struct pci_controller, bridge)
> >
> > static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> > {
> > struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> > if (bridge)
> > return to_pci_controller(bridge);
> >
> > return NULL;
> > }
> >
> > int arch_pci_init(....)
> > {
> > struct pci_controller *hose;
> > ....
> > hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> > pci_init_host_bridge(&hose->bridge);
> > ....
> > pci_scan_root_bus(...., &hose->bridge, &resources);
> > ....
> > return 0;
> > }
> >
> > Then finding the right structure will be easy.
> >
> >> Another, I don't like associate msi chip and every PCI device, further more,
> >> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> >> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> >> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
> >>
> >
> > I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> > I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> > thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> > and for arches that don't care about MSI it doesn't get implemented.
>
> Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
> be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.
OK. But as you might have seen that still implies open coding a separate version of pci_scan_root_bus().
Best regards,
Liviu
>
> Thanks!
> Yijing.
>
> >
> > Best regards,
> > Liviu
> >
> >
> >> Thanks!
> >> Yijing.
> >>
> >>>
> >>> Best regards,
> >>> Liviu
> >>>
> >>>>
> >>>>>
> >>>>> I think both issues are orthogonal. Last time I checked a lot of work
> >>>>> was still necessary to unify host bridges enough so that it could be
> >>>>> shared across architectures. But perhaps some of that work has
> >>>>> happened in the meantime.
> >>>>>
> >>>>> But like I said, when you create the root bus, you can easily attach the
> >>>>> MSI chip to it.
> >>>>>
> >>>>> Thierry
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Thanks!
> >>>> Yijing
> >>>>
> >>>>
> >>>
> >>
> >>
> >> --
> >> Thanks!
> >> Yijing
> >>
> >>
> >
>
>
> --
> Thanks!
> Yijing
>
>
--
-------------------
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
^ permalink raw reply
* Re: [PATCH 10/15] powerpc/mm: Add hooks for cxl
From: Aneesh Kumar K.V @ 2014-09-29 9:10 UTC (permalink / raw)
To: Michael Neuling, greg, arnd, mpe, benh
Cc: cbe-oss-dev, mikey, linux-kernel, linuxppc-dev, jk, imunsie,
anton
In-Reply-To: <1411028820-29933-11-git-send-email-mikey@neuling.org>
Michael Neuling <mikey@neuling.org> writes:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> This add a hook into tlbie() so that we use global invalidations when there are
> cxl contexts active.
>
> Normally cxl snoops broadcast tlbie. cxl can have TLB entries invalidated via
> MMIO, but we aren't doing that yet. So for now we are just disabling local
> tlbies when cxl contexts are active. In future we can make tlbie() local mode
> smarter so that it invalidates cxl contexts explicitly when it needs to.
>
> This also adds a hooks for when SLBs are invalidated to ensure any
> corresponding SLBs in cxl are also invalidated at the same time.
We are not really invalidating cx1 SLB's when we are doing
slb_flush_and_rebolt(). May be add some code documentation around to
explain when we are invalidating cx1 slb here. ?
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> arch/powerpc/mm/hash_native_64.c | 6 +++++-
> arch/powerpc/mm/hash_utils_64.c | 3 +++
> arch/powerpc/mm/slice.c | 3 +++
> 3 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/hash_native_64.c b/arch/powerpc/mm/hash_native_64.c
> index afc0a82..ae4962a 100644
> --- a/arch/powerpc/mm/hash_native_64.c
> +++ b/arch/powerpc/mm/hash_native_64.c
> @@ -29,6 +29,8 @@
> #include <asm/kexec.h>
> #include <asm/ppc-opcode.h>
>
> +#include <misc/cxl.h>
> +
> #ifdef DEBUG_LOW
> #define DBG_LOW(fmt...) udbg_printf(fmt)
> #else
> @@ -149,9 +151,11 @@ static inline void __tlbiel(unsigned long vpn, int psize, int apsize, int ssize)
> static inline void tlbie(unsigned long vpn, int psize, int apsize,
> int ssize, int local)
> {
> - unsigned int use_local = local && mmu_has_feature(MMU_FTR_TLBIEL);
> + unsigned int use_local;
> int lock_tlbie = !mmu_has_feature(MMU_FTR_LOCKLESS_TLBIE);
>
> + use_local = local && mmu_has_feature(MMU_FTR_TLBIEL) && !cxl_ctx_in_use();
> +
> if (use_local)
> use_local = mmu_psize_defs[psize].tlbiel;
> if (lock_tlbie && !use_local)
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index 66071af..be40ff7 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -34,6 +34,7 @@
> #include <linux/signal.h>
> #include <linux/memblock.h>
> #include <linux/context_tracking.h>
> +#include <misc/cxl.h>
>
> #include <asm/processor.h>
> #include <asm/pgtable.h>
> @@ -906,6 +907,7 @@ void demote_segment_4k(struct mm_struct *mm, unsigned long addr)
> #ifdef CONFIG_SPU_BASE
> spu_flush_all_slbs(mm);
> #endif
> + cxl_slbia(mm);
> if (get_paca_psize(addr) != MMU_PAGE_4K) {
> get_paca()->context = mm->context;
> slb_flush_and_rebolt();
> @@ -1145,6 +1147,7 @@ int hash_page_mm(struct mm_struct *mm, unsigned long ea, unsigned long access, u
> #ifdef CONFIG_SPU_BASE
> spu_flush_all_slbs(mm);
> #endif
> + cxl_slbia(mm);
> }
> }
>
> diff --git a/arch/powerpc/mm/slice.c b/arch/powerpc/mm/slice.c
> index b0c75cc..4d3a34b 100644
> --- a/arch/powerpc/mm/slice.c
> +++ b/arch/powerpc/mm/slice.c
> @@ -30,6 +30,7 @@
> #include <linux/err.h>
> #include <linux/spinlock.h>
> #include <linux/export.h>
> +#include <misc/cxl.h>
> #include <asm/mman.h>
> #include <asm/mmu.h>
> #include <asm/spu.h>
> @@ -235,6 +236,7 @@ static void slice_convert(struct mm_struct *mm, struct slice_mask mask, int psiz
> #ifdef CONFIG_SPU_BASE
> spu_flush_all_slbs(mm);
> #endif
> + cxl_slbia(mm);
> }
>
> /*
> @@ -674,6 +676,7 @@ void slice_set_psize(struct mm_struct *mm, unsigned long address,
> #ifdef CONFIG_SPU_BASE
> spu_flush_all_slbs(mm);
> #endif
> + cxl_slbia(mm);
> }
>
> void slice_set_range_psize(struct mm_struct *mm, unsigned long start,
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH 08/15] powerpc/mm: Add new hash_page_mm()
From: Aneesh Kumar K.V @ 2014-09-29 8:50 UTC (permalink / raw)
To: Michael Neuling, greg, arnd, mpe, benh
Cc: cbe-oss-dev, mikey, linux-kernel, linuxppc-dev, jk, imunsie,
anton
In-Reply-To: <1411028820-29933-9-git-send-email-mikey@neuling.org>
Michael Neuling <mikey@neuling.org> writes:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> This adds a new function hash_page_mm() based on the existing hash_page().
> This version allows any struct mm to be passed in, rather than assuming
> current. This is useful for servicing co-processor faults which are not in the
> context of the current running process.
>
> We need to be careful here as the current hash_page() assumes current in a few
> places.
Can you also explain calling semantics. ie, why would we want to call
this with anything other than current ? Should we flush slb now or
should it be skipped ? so what would happen if the new hash page can
result in segment demotion ? You don't put that under if (mm ==
current->mm). is that ok ?
if ((pte_val(*ptep) & _PAGE_4K_PFN) && psize == MMU_PAGE_64K) {
demote_segment_4k(mm, ea);
psize = MMU_PAGE_4K;
}
We also update paca context there
if (get_paca_psize(addr) != MMU_PAGE_4K) {
get_paca()->context = mm->context;
slb_flush_and_rebolt();
}
You also added code to handle KERNEL_REGION_ID in
[PATCH 02/15] powerpc/cell: Move data segment faulting code out of cell
platform. do we need to handle that here ?
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> arch/powerpc/include/asm/mmu-hash64.h | 1 +
> arch/powerpc/mm/hash_utils_64.c | 20 +++++++++++++-------
> 2 files changed, 14 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
> index fd19a53..a3b85e9 100644
> --- a/arch/powerpc/include/asm/mmu-hash64.h
> +++ b/arch/powerpc/include/asm/mmu-hash64.h
> @@ -319,6 +319,7 @@ extern int __hash_page_64K(unsigned long ea, unsigned long access,
> unsigned int local, int ssize);
> struct mm_struct;
> unsigned int hash_page_do_lazy_icache(unsigned int pp, pte_t pte, int trap);
> +extern int hash_page_mm(struct mm_struct *mm, unsigned long ea, unsigned long access, unsigned long trap);
> extern int hash_page(unsigned long ea, unsigned long access, unsigned long trap);
> int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
> pte_t *ptep, unsigned long trap, int local, int ssize,
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index 0f73367..66071af 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -991,26 +991,24 @@ static void check_paca_psize(unsigned long ea, struct mm_struct *mm,
> * -1 - critical hash insertion error
> * -2 - access not permitted by subpage protection mechanism
> */
> -int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
> +int hash_page_mm(struct mm_struct *mm, unsigned long ea, unsigned long access, unsigned long trap)
> {
> enum ctx_state prev_state = exception_enter();
> pgd_t *pgdir;
> unsigned long vsid;
> - struct mm_struct *mm;
> pte_t *ptep;
> unsigned hugeshift;
> const struct cpumask *tmp;
> int rc, user_region = 0, local = 0;
> int psize, ssize;
>
> - DBG_LOW("hash_page(ea=%016lx, access=%lx, trap=%lx\n",
> - ea, access, trap);
> + DBG_LOW("%s(ea=%016lx, access=%lx, trap=%lx\n",
> + __func__, ea, access, trap);
>
> /* Get region & vsid */
> switch (REGION_ID(ea)) {
> case USER_REGION_ID:
> user_region = 1;
> - mm = current->mm;
> if (! mm) {
> DBG_LOW(" user region with no mm !\n");
> rc = 1;
> @@ -1106,7 +1104,8 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
> WARN_ON(1);
> }
> #endif
> - check_paca_psize(ea, mm, psize, user_region);
> + if (current->mm == mm)
> + check_paca_psize(ea, mm, psize, user_region);
>
> goto bail;
> }
> @@ -1149,7 +1148,8 @@ int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
> }
> }
>
> - check_paca_psize(ea, mm, psize, user_region);
> + if (current->mm == mm)
> + check_paca_psize(ea, mm, psize, user_region);
> #endif /* CONFIG_PPC_64K_PAGES */
>
> #ifdef CONFIG_PPC_HAS_HASH_64K
> @@ -1184,6 +1184,12 @@ bail:
> exception_exit(prev_state);
> return rc;
> }
> +EXPORT_SYMBOL_GPL(hash_page_mm);
> +
> +int hash_page(unsigned long ea, unsigned long access, unsigned long trap)
> +{
> + return hash_page_mm(current->mm, ea, access, trap);
> +}
> EXPORT_SYMBOL_GPL(hash_page);
>
> void hash_preload(struct mm_struct *mm, unsigned long ea,
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Lucas Stach @ 2014-09-29 8:37 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, Bharat.Bhushan, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Thomas Petazzoni, Liviu Dudau, Tony Luck, Sergei Shtylyov,
linux-kernel, Ralf Baechle, iommu, David Vrabel, Wuyun,
linuxppc-dev, David S. Miller
In-Reply-To: <5427A6A0.5040703@huawei.com>
Am Sonntag, den 28.09.2014, 14:11 +0800 schrieb Yijing Wang:
> On 2014/9/28 10:32, Yijing Wang wrote:
> > On 2014/9/26 17:05, Thierry Reding wrote:
> >> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> >> [...]
> >>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
> >>> directly (patch attached).
> >>
> >> Really attached this time.
> >>
> >> Thierry
> >>
> >
> > It looks good to me, so I will update the arm pci hostbridge driver to assign
> > pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> > platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> > temporarily for more comments, especially from Bjorn.
>
> Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
> assign msi chip to root bus in all host drivers's scan functions.
Designware will switch away from pci_scan_root_bus() in the 3.18 cycle
and I would think it would be no problem to to the same with rcar.
Regards,
Lucas
--
Pengutronix e.K. | Lucas Stach |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH 02/15] powerpc/cell: Move data segment faulting code out of cell platform
From: Aneesh Kumar K.V @ 2014-09-29 8:30 UTC (permalink / raw)
To: Michael Neuling, greg, arnd, mpe, benh
Cc: cbe-oss-dev, mikey, linux-kernel, linuxppc-dev, jk, imunsie,
anton
In-Reply-To: <1411028820-29933-3-git-send-email-mikey@neuling.org>
Michael Neuling <mikey@neuling.org> writes:
> From: Ian Munsie <imunsie@au1.ibm.com>
>
> __spu_trap_data_seg() currently contains code to determine the VSID and ESID
> required for a particular EA and mm struct.
>
> This code is generically useful for other co-processors. This moves the code
> of the cell platform so it can be used by other powerpc code.
>
> Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> arch/powerpc/include/asm/mmu-hash64.h | 2 ++
> arch/powerpc/mm/copro_fault.c | 48 ++++++++++++++++++++++++++++++++++
> arch/powerpc/mm/slb.c | 3 ---
> arch/powerpc/platforms/cell/spu_base.c | 41 +++--------------------------
> 4 files changed, 54 insertions(+), 40 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/mmu-hash64.h b/arch/powerpc/include/asm/mmu-hash64.h
> index d765144..fd19a53 100644
> --- a/arch/powerpc/include/asm/mmu-hash64.h
> +++ b/arch/powerpc/include/asm/mmu-hash64.h
> @@ -180,6 +180,8 @@ static inline unsigned int mmu_psize_to_shift(unsigned int mmu_psize)
> * we work in all cases including 4k page size.
> */
> #define VPN_SHIFT 12
> +#define slb_vsid_shift(ssize) \
> + ((ssize) == MMU_SEGSIZE_256M ? SLB_VSID_SHIFT : SLB_VSID_SHIFT_1T)
can it be static inline similar to segment_shift() ?
>
> /*
> * HPTE Large Page (LP) details
> diff --git a/arch/powerpc/mm/copro_fault.c b/arch/powerpc/mm/copro_fault.c
> index ba7df14..4105a63 100644
> --- a/arch/powerpc/mm/copro_fault.c
> +++ b/arch/powerpc/mm/copro_fault.c
> @@ -90,3 +90,51 @@ out_unlock:
> return ret;
> }
> EXPORT_SYMBOL_GPL(copro_handle_mm_fault);
> +
> +int copro_data_segment(struct mm_struct *mm, u64 ea, u64 *esid, u64 *vsid)
> +{
> + int psize, ssize;
> +
> + *esid = (ea & ESID_MASK) | SLB_ESID_V;
> +
> + switch (REGION_ID(ea)) {
> + case USER_REGION_ID:
> + pr_devel("copro_data_segment: 0x%llx -- USER_REGION_ID\n", ea);
> +#ifdef CONFIG_PPC_MM_SLICES
> + psize = get_slice_psize(mm, ea);
> +#else
> + psize = mm->context.user_psize;
> +#endif
We don't need that.
#ifdef CONFIG_PPC_STD_MMU_64
#define get_slice_psize(mm, addr) ((mm)->context.user_psize)
> + ssize = user_segment_size(ea);
> + *vsid = (get_vsid(mm->context.id, ea, ssize)
> + << slb_vsid_shift(ssize)) | SLB_VSID_USER
> + | (ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 0);
> + break;
> + case VMALLOC_REGION_ID:
> + pr_devel("copro_data_segment: 0x%llx -- VMALLOC_REGION_ID\n", ea);
> + if (ea < VMALLOC_END)
> + psize = mmu_vmalloc_psize;
> + else
> + psize = mmu_io_psize;
> + *vsid = (get_kernel_vsid(ea, mmu_kernel_ssize)
> + << SLB_VSID_SHIFT) | SLB_VSID_KERNEL
> + | (mmu_kernel_ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 0);
> + break;
> + case KERNEL_REGION_ID:
> + pr_devel("copro_data_segment: 0x%llx -- KERNEL_REGION_ID\n", ea);
> + psize = mmu_linear_psize;
> + *vsid = (get_kernel_vsid(ea, mmu_kernel_ssize)
> + << SLB_VSID_SHIFT) | SLB_VSID_KERNEL
> + | (mmu_kernel_ssize == MMU_SEGSIZE_1T ? SLB_VSID_B_1T : 0);
> + break;
> + default:
> + /* Future: support kernel segments so that drivers can use the
> + * CoProcessors */
> + pr_debug("invalid region access at %016llx\n", ea);
> + return 1;
> + }
> + *vsid |= mmu_psize_defs[psize].sllp;
> +
> + return 0;
> +}
large part of this is same as what we do in hash_page. And we are not
really updating vsid here, it is vsid slb encoding. So why not abstract
the vsid part and use that in hash_page also ? That would have also taken
care of the above #ifdef.
> +EXPORT_SYMBOL_GPL(copro_data_segment);
> diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
> index 0399a67..6e450ca 100644
> --- a/arch/powerpc/mm/slb.c
> +++ b/arch/powerpc/mm/slb.c
> @@ -46,9 +46,6 @@ static inline unsigned long mk_esid_data(unsigned long ea, int ssize,
> return (ea & slb_esid_mask(ssize)) | SLB_ESID_V | slot;
> }
>
> -#define slb_vsid_shift(ssize) \
> - ((ssize) == MMU_SEGSIZE_256M? SLB_VSID_SHIFT: SLB_VSID_SHIFT_1T)
> -
> static inline unsigned long mk_vsid_data(unsigned long ea, int ssize,
> unsigned long flags)
> {
> diff --git a/arch/powerpc/platforms/cell/spu_base.c b/arch/powerpc/platforms/cell/spu_base.c
> index 2930d1e..fe004b1 100644
> --- a/arch/powerpc/platforms/cell/spu_base.c
> +++ b/arch/powerpc/platforms/cell/spu_base.c
> @@ -167,45 +167,12 @@ static inline void spu_load_slb(struct spu *spu, int slbe, struct spu_slb *slb)
>
> static int __spu_trap_data_seg(struct spu *spu, unsigned long ea)
> {
> - struct mm_struct *mm = spu->mm;
> struct spu_slb slb;
> - int psize;
> -
> - pr_debug("%s\n", __func__);
> -
> - slb.esid = (ea & ESID_MASK) | SLB_ESID_V;
> + int ret;
>
> - switch(REGION_ID(ea)) {
> - case USER_REGION_ID:
> -#ifdef CONFIG_PPC_MM_SLICES
> - psize = get_slice_psize(mm, ea);
> -#else
> - psize = mm->context.user_psize;
> -#endif
> - slb.vsid = (get_vsid(mm->context.id, ea, MMU_SEGSIZE_256M)
> - << SLB_VSID_SHIFT) | SLB_VSID_USER;
> - break;
> - case VMALLOC_REGION_ID:
> - if (ea < VMALLOC_END)
> - psize = mmu_vmalloc_psize;
> - else
> - psize = mmu_io_psize;
> - slb.vsid = (get_kernel_vsid(ea, MMU_SEGSIZE_256M)
> - << SLB_VSID_SHIFT) | SLB_VSID_KERNEL;
> - break;
> - case KERNEL_REGION_ID:
> - psize = mmu_linear_psize;
> - slb.vsid = (get_kernel_vsid(ea, MMU_SEGSIZE_256M)
> - << SLB_VSID_SHIFT) | SLB_VSID_KERNEL;
> - break;
> - default:
> - /* Future: support kernel segments so that drivers
> - * can use SPUs.
> - */
> - pr_debug("invalid region access at %016lx\n", ea);
> - return 1;
> - }
> - slb.vsid |= mmu_psize_defs[psize].sllp;
> + ret = copro_data_segment(spu->mm, ea, &slb.esid, &slb.vsid);
> + if (ret)
> + return ret;
>
> spu_load_slb(spu, spu->slb_replace, &slb);
>
-aneesh
^ permalink raw reply
* Re: [PATCH] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
From: Alexander Graf @ 2014-09-29 8:28 UTC (permalink / raw)
To: Aneesh Kumar K.V, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1411977758-24506-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com>
On 29.09.14 10:02, Aneesh Kumar K.V wrote:
> We use cma reserved area for creating guest hash page table.
> Don't do the reservation in non-hypervisor mode. This avoids unnecessary
> CMA reservation when booting with limited memory configs like
> fadump and kdump.
>
> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Thanks, applied to kvm-ppc-queue.
Alex
^ permalink raw reply
* [PATCH] KVM: PPC: BOOK3S: HV: CMA: Reserve cma region only in hypervisor mode
From: Aneesh Kumar K.V @ 2014-09-29 8:02 UTC (permalink / raw)
To: agraf, benh, paulus; +Cc: linuxppc-dev, kvm, kvm-ppc, Aneesh Kumar K.V
We use cma reserved area for creating guest hash page table.
Don't do the reservation in non-hypervisor mode. This avoids unnecessary
CMA reservation when booting with limited memory configs like
fadump and kdump.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/kvm/book3s_hv_builtin.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/kvm/book3s_hv_builtin.c b/arch/powerpc/kvm/book3s_hv_builtin.c
index b9615ba5b083..4fdc27c80f4c 100644
--- a/arch/powerpc/kvm/book3s_hv_builtin.c
+++ b/arch/powerpc/kvm/book3s_hv_builtin.c
@@ -163,6 +163,12 @@ void __init kvm_cma_reserve(void)
unsigned long align_size;
struct memblock_region *reg;
phys_addr_t selected_size = 0;
+
+ /*
+ * We need CMA reservation only when we are in HV mode
+ */
+ if (!cpu_has_feature(CPU_FTR_HVMODE))
+ return;
/*
* We cannot use memblock_phys_mem_size() here, because
* memblock_analyze() has not been called yet.
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Yijing Wang @ 2014-09-29 1:44 UTC (permalink / raw)
To: Liviu Dudau
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140928112144.GA4671@bart.dudau.co.uk>
On 2014/9/28 19:21, Liviu Dudau wrote:
> On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
>>>>>> What I would like to see is a way of creating the pci_host_bridge structure outside
>>>>>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
>>>>>> details like associated msi_chip into the host bridge and the child busses will
>>>>>> have an easy way of finding the information needed by finding the root bus and then
>>>>>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
>>>>>> everyone and the drivers can remove their kludges that try to work around the
>>>>>> current limitations.
>>>>
>>>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>>>
>>> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
>>> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
>>> sysdata around the pci_host_bridge*.
>>
>> I inspected every arch and found there are almost no common stuff,
>
> I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
Most.
> pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
> IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
> arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
> with the platform code due to convoluted way(s) in which PCI code gets instantiated.
Yes, currently some archs store MEM and IO resource in pci sysdata, and others not, move the MEM and IO
resource to pci_host_bride could make code become simple, we can clean up the resource list argument in
pci scan functions.
>
> What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
> common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
> we will have more commonality and it will be easier to re-factor the code.
Now, I got it, thanks!
>
>> and generic data struct should
>> be created in generic PCI code.
>
> Not necessarily. What I have in mind is something like this:
This is a good idea, what I'm worried is this series is already large, so I think we need to post
another series to do it.
>
> - drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
> and anything else that is needed (like find_pci_host_bridge() function).
> - arch code does:
>
> struct pci_controller {
> struct pci_host_bridge bridge;
> .....
> };
>
> #define to_pci_controller(bridge) container_of(bridge, struct pci_controller, bridge)
>
> static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
> {
> struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
> if (bridge)
> return to_pci_controller(bridge);
>
> return NULL;
> }
>
> int arch_pci_init(....)
> {
> struct pci_controller *hose;
> ....
> hose = kzalloc(sizeof(*hose), GFP_KERNEL);
> pci_init_host_bridge(&hose->bridge);
> ....
> pci_scan_root_bus(...., &hose->bridge, &resources);
> ....
> return 0;
> }
>
> Then finding the right structure will be easy.
>
>> Another, I don't like associate msi chip and every PCI device, further more,
>> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
>> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
>> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>>
>
> I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
> I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
> thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
> and for arches that don't care about MSI it doesn't get implemented.
Currently, a property "msi-parent" was introduced in arm, and all msi chip integrated in irq chip controller will
be added to of_pci_msi_chip_list. PCI host driver find the match msi chip by its of_node.
Thanks!
Yijing.
>
> Best regards,
> Liviu
>
>
>> Thanks!
>> Yijing.
>>
>>>
>>> Best regards,
>>> Liviu
>>>
>>>>
>>>>>
>>>>> I think both issues are orthogonal. Last time I checked a lot of work
>>>>> was still necessary to unify host bridges enough so that it could be
>>>>> shared across architectures. But perhaps some of that work has
>>>>> happened in the meantime.
>>>>>
>>>>> But like I said, when you create the root bus, you can easily attach the
>>>>> MSI chip to it.
>>>>>
>>>>> Thierry
>>>>>
>>>>
>>>>
>>>> --
>>>> Thanks!
>>>> Yijing
>>>>
>>>>
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>>
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Liviu Dudau @ 2014-09-28 11:21 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <54276F6C.5010705@huawei.com>
On Sun, Sep 28, 2014 at 10:16:12AM +0800, Yijing Wang wrote:
> >>>> What I would like to see is a way of creating the pci_host_bridge structure outside
> >>>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
> >>>> details like associated msi_chip into the host bridge and the child busses will
> >>>> have an easy way of finding the information needed by finding the root bus and then
> >>>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
> >>>> everyone and the drivers can remove their kludges that try to work around the
> >>>> current limitations.
> >>
> >> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
> >
> > Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> > changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> > sysdata around the pci_host_bridge*.
>
> I inspected every arch and found there are almost no common stuff,
I will disagree here. Most (all?) of the structures that are passed as sysdata argument to
pci_create_root_bus() or pci_scan_root_bus() have a set of resources for storing the MEM and
IO ranges, which struct pci_host_bridge already has. So that can be factored out of the
arch code. Same for pci_domain_nr. Then there are some variables that are used for communication
with the platform code due to convoluted way(s) in which PCI code gets instantiated.
What I am arguing here is not that the arch equivalent of pci_host_bridge structure is already
common, but that by moving the members that are common out of arch sysdata into pci_host_bridge
we will have more commonality and it will be easier to re-factor the code.
> and generic data struct should
> be created in generic PCI code.
Not necessarily. What I have in mind is something like this:
- drivers/pci/ exports pci_init_host_bridge() that does the initialisation of bridge->windows
and anything else that is needed (like find_pci_host_bridge() function).
- arch code does:
struct pci_controller {
struct pci_host_bridge bridge;
.....
};
#define to_pci_controller(bridge) container_of(bridge, struct pci_controller, bridge)
static inline struct pci_controller *get_host_controller(const struct pci_bus *bus)
{
struct pci_host_bridge *bridge = find_pci_host_bridge(bus);
if (bridge)
return to_pci_controller(bridge);
return NULL;
}
int arch_pci_init(....)
{
struct pci_controller *hose;
....
hose = kzalloc(sizeof(*hose), GFP_KERNEL);
pci_init_host_bridge(&hose->bridge);
....
pci_scan_root_bus(...., &hose->bridge, &resources);
....
return 0;
}
Then finding the right structure will be easy.
> Another, I don't like associate msi chip and every PCI device, further more,
> almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
> to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
> should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
>
I wasn't suggesing to associate an msi chip with every PCI device, but with the pci_host_bridge.
I don't expect a host bridge to have more than one msi chip, so that should be OK. Also, I'm
thinking that getting the associated msi chip should be some sort of pci_host_bridge ops function,
and for arches that don't care about MSI it doesn't get implemented.
Best regards,
Liviu
> Thanks!
> Yijing.
>
> >
> > Best regards,
> > Liviu
> >
> >>
> >>>
> >>> I think both issues are orthogonal. Last time I checked a lot of work
> >>> was still necessary to unify host bridges enough so that it could be
> >>> shared across architectures. But perhaps some of that work has
> >>> happened in the meantime.
> >>>
> >>> But like I said, when you create the root bus, you can easily attach the
> >>> MSI chip to it.
> >>>
> >>> Thierry
> >>>
> >>
> >>
> >> --
> >> Thanks!
> >> Yijing
> >>
> >>
> >
>
>
> --
> Thanks!
> Yijing
>
>
--
-------------------
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
^ permalink raw reply
* RE: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Jingchang Lu @ 2014-09-28 10:01 UTC (permalink / raw)
To: Laurentiu.Tudor@freescale.com, mturquette@linaro.org
Cc: Scott Wood, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <542410D3.2060507@freescale.com>
Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogVHVkb3IgTGF1cmVudGl1LUIxMDcx
Ng0KPlNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjUsIDIwMTQgODo1NiBQTQ0KPlRvOiBMdSBK
aW5nY2hhbmctQjM1MDgzOyBtdHVycXVldHRlQGxpbmFyby5vcmcNCj5DYzogV29vZCBTY290dC1C
MDc0MjE7IGxpbnV4cHBjLWRldkBsaXN0cy5vemxhYnMub3JnOyBsaW51eC0NCj5rZXJuZWxAdmdl
ci5rZXJuZWwub3JnOyBsaW51eC1hcm0ta2VybmVsQGxpc3RzLmluZnJhZGVhZC5vcmcNCj5TdWJq
ZWN0OiBSZTogW1BBVENIdjRdIGNsazogcHBjLWNvcmVuZXQ6IHJlbmFtZSB0byBwcGMtcW9yaXEg
YW5kIGFkZA0KPkNMS19PRl9ERUNMQVJFIHN1cHBvcnQNCj4NCj5IaSBKaW5nY2hhbmcsDQo+DQo+
T24gMDkvMjMvMjAxNCAwOTo0NiBBTSwgSmluZ2NoYW5nIEx1IHdyb3RlOg0KPj4gVGhlIElQIGlz
IHNoYXJlZCBieSBQUEMgYW5kIEFSTSwgdGhpcyByZW5hbWVzIGl0IHRvIHFvcmlxIGZvciBiZXR0
ZXINCj4+IHJlcHJlc2VudGlvbiwgYW5kIHRoaXMgYWxzbyBhZGRzIHRoZSBDTEtfT0ZfREVDTEFS
RSBzdXBwb3J0IGZvciBiZWluZw0KPj4gaW5pdGlhbGl6ZWQgYnkgb2ZfY2xrX2luaXQoKSBvbiBB
Uk0uDQo+Pg0KPg0KPkkgdGhpbmsgeW91IG5lZWQgdG8gYWxzbyB1cGRhdGUgZHJpdmVycy9jcHVm
cmVxL0tjb25maWcucG93ZXJwYyB0byB1c2UgdGhlDQo+cmVuYW1lZCBjb25maWcgb3B0aW9uLg0K
Pg0KDQpUaGFua3MsIEkgd2lsbCB1cGRhdGUgdGhhdCBzZWxlY3RlZCBjb25maWcgb3B0aW9uIG9m
IENMS19QUENfQ09SRU5FVC4NCg0KQmVzdCBSZWdhcmRzLA0KSmluZ2NoYW5nDQo+LS0tDQo+QmVz
dCBSZWdhcmRzLCBMYXVyZW50aXUNCg0KDQo=
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Yijing Wang @ 2014-09-28 6:11 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, Bharat.Bhushan, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Thomas Petazzoni, Liviu Dudau, Tony Luck, Sergei Shtylyov,
linux-kernel, Ralf Baechle, iommu, David Vrabel, Wuyun,
linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <54277327.6070500@huawei.com>
On 2014/9/28 10:32, Yijing Wang wrote:
> On 2014/9/26 17:05, Thierry Reding wrote:
>> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
>> [...]
>>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>>> directly (patch attached).
>>
>> Really attached this time.
>>
>> Thierry
>>
>
> It looks good to me, so I will update the arm pci hostbridge driver to assign
> pci root bus the msi chip instead of current pcibios_add_bus(). But for other
> platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
> temporarily for more comments, especially from Bjorn.
Oh, sorry, I found designware and rcar use pci_scan_root_bus(), so we can not simply
assign msi chip to root bus in all host drivers's scan functions.
>
> Thanks!
> Yijing.
>
--
Thanks!
Yijing
^ permalink raw reply
* RE: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Yuantian Tang @ 2014-09-28 2:18 UTC (permalink / raw)
To: Mike Turquette, Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Jingchang Lu
In-Reply-To: <20140926232900.19023.35854@quantum>
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMaW51eHBwYy1kZXYNCj4gW21h
aWx0bzpsaW51eHBwYy1kZXYtYm91bmNlcytiMjk5ODM9ZnJlZXNjYWxlLmNvbUBsaXN0cy5vemxh
YnMub3JnXSBPbg0KPiBCZWhhbGYgT2YgTWlrZSBUdXJxdWV0dGUNCj4gU2VudDogU2F0dXJkYXks
IFNlcHRlbWJlciAyNywgMjAxNCA3OjI5IEFNDQo+IFRvOiBXb29kIFNjb3R0LUIwNzQyMQ0KPiBD
YzogbGludXhwcGMtZGV2QGxpc3RzLm96bGFicy5vcmc7IGxpbnV4LWtlcm5lbEB2Z2VyLmtlcm5l
bC5vcmc7DQo+IGxpbnV4LWFybS1rZXJuZWxAbGlzdHMuaW5mcmFkZWFkLm9yZzsgTHUgSmluZ2No
YW5nLUIzNTA4Mw0KPiBTdWJqZWN0OiBSZTogW1BBVENIdjRdIGNsazogcHBjLWNvcmVuZXQ6IHJl
bmFtZSB0byBwcGMtcW9yaXEgYW5kIGFkZA0KPiBDTEtfT0ZfREVDTEFSRSBzdXBwb3J0DQo+IA0K
PiBRdW90aW5nIFNjb3R0IFdvb2QgKDIwMTQtMDktMjUgMTU6NTY6MjApDQo+ID4gT24gVGh1LCAy
MDE0LTA5LTI1IGF0IDE1OjU0IC0wNzAwLCBNaWtlIFR1cnF1ZXR0ZSB3cm90ZToNCj4gPiA+IFF1
b3RpbmcgU2NvdHQgV29vZCAoMjAxNC0wOS0yNSAxMzowODowMCkNCj4gPiA+ID4gV2VsbCwgbGlr
ZSBJIHNhaWQsIEknZCByYXRoZXIgc2VlIHRoZSBDTEtfT0ZfREVDTEFSRSBzdHVmZiBiZSBtYWRl
DQo+ID4gPiA+IHRvIHdvcmsgb24gUFBDIHJhdGhlciB0aGFuIGhhdmUgdGhlIGRyaXZlciBjYXJy
eSBhcm91bmQgdHdvDQo+ID4gPiA+IGJpbmRpbmcgbWV0aG9kcy4NCj4gPiA+DQo+ID4gPiBJIGd1
ZXNzIHRoYXQgaXMgYW4gZXhpc3RpbmcgcHJvYmxlbSwgYW5kIG5vdCByZWxhdGVkIGRpcmVjdGx5
IHRvDQo+ID4gPiB0aGlzIHBhdGNoPyBUaGlzIHBhdGNoIGlzIGVzc2VudGlhbGx5IGp1c3QgcmVu
YW1lcyAodGhvdWdoIHRoZQ0KPiA+ID4gVjEuMC9WMi4wIHN0dWZmIHNlZW1zIHdlaXJkKS4NCj4g
Pg0KPiA+IFRoaXMgcGF0Y2ggaXMgYWRkaW5nIENMS19PRl9ERUNMQVJFLg0KPiANCj4gSSdtIGZp
bmUgdGFraW5nIHRoaXMgcGF0Y2ggYnV0IHlvdXIgY29tbWVudHMgYXJlIHN0aWxsIHVucmVzb2x2
ZWQuIFdoYXQgZG8geW91DQo+IHRoaW5rIG5lZWRzIHRvIGJlIGRvbmUgdG8gZml4IHRoZSBwcm9i
bGVtcyB0aGF0IHlvdSBzZWU/DQo+IA0KQ0xLX09GX0RFQ0xBUkUgaXMgdG90YWxseSB3b3JrZWQg
b24gUFBDLiBJIHdpbGwgZG8gaXQgaW4gYSBzZXBhcmF0ZSBwYXRjaC4NClJlZ2FyZGluZyBWMS4w
IGFuZCBWMi4wLCBpdCBpcyBub3Qgd2lyZWQganVzdCBzYW1lIGZvciBub3cuIEJ1dCB3ZSBhcmUg
bm90IHN1cmUgaWYgaXQgaXMgc2FtZSBmb3IgdjMuMCBpbiB0aGUgZnV0dXJlLg0KDQpCZXNpZGVz
IHVwZGF0aW5nIGRyaXZlcnMvY3B1ZnJlcS9LY29uZmlnLnBvd2VycGMsIHRoZXJlIGlzIG9uZSBt
b3JlIHRoaW5nIEkgYW0gbm90IGNvbWZvcnRhYmxlIHdpdGg6DQpUaGlzIHBhdGNoIHVzZXMgIiBm
aXhlZC1jbG9jayIgYXMgc3lzY2xrJ3MgY29tcGF0aWJsZSBzdHJpbmcsIHdoaWxlIG9uIFBQQyB3
ZSB0cmVhdGVkIGl0IGFzICIgZnNsLHFvcmlxLXN5c2Nsay1bMS0yXS4wIi4NClRoYXQncyBpbmNv
bnNpc3RlbnQgb24gYm90aCBBUk0gYW5kIFBQQyBwbGF0Zm9ybXMsIG5laXRoZXIgZGlkIG9uIGJp
bmRpbmdzLg0KDQpUaGFua3MsDQpZdWFudGlhbg0KDQo+IFJlZ2FyZHMsDQo+IE1pa2UNCj4gDQo+
ID4NCj4gPiAtU2NvdHQNCj4gPg0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+IExpbnV4cHBjLWRldiBtYWlsaW5nIGxpc3QNCj4gTGludXhw
cGMtZGV2QGxpc3RzLm96bGFicy5vcmcNCj4gaHR0cHM6Ly9saXN0cy5vemxhYnMub3JnL2xpc3Rp
bmZvL2xpbnV4cHBjLWRldg0K
^ permalink raw reply
* Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
From: Yijing Wang @ 2014-09-28 2:35 UTC (permalink / raw)
To: Thomas Gleixner
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
linux-arm-kernel, Thomas Petazzoni, Xinwei Hu, Tony Luck,
Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu, David Vrabel,
Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <alpine.DEB.2.11.1409261236160.4567@nanos>
>> MSI chip in this series is to setup MSI irq, including IRQ allocation, Map,
>> compose MSI msg ..., in different platform, many arch specific MSI irq details in it.
>> It's difficult to extract the common data and code.
>>
>> I have a plan to rework MSI related irq_chips in kernel, PCI and Non-PCI, currently,
>> HPET, DMAR and PCI have their own irq_chip and MSI related functions, write_msi_msg(),
>> mask_msi_irq(), etc... I want to extract the common data set for that, so we can
>> remove lots of unnecessary MSI code.
>
> That makes sense. Can you please make sure that this does not conflict
> with the ongoing work Jiang is doing in the x86 irq area with
> hierarchical irqdomains to distangle layered levels like MSI from the
> underlying vector/irqremap mechanics.
Yes, I'm reviewing Jiang hierarchical irqdomains series, I'm interested in that changes.
Thanks!
Yijing.
>
> Thanks,
>
> tglx
>
> .
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Yijing Wang @ 2014-09-28 2:32 UTC (permalink / raw)
To: Thierry Reding
Cc: linux-mips, linux-ia64, linux-pci, Xinwei Hu, sparclinux,
linux-arch, linux-s390, Russell King, Joerg Roedel, x86,
Sebastian Ott, Bharat.Bhushan, xen-devel, arnab.basu,
Arnd Bergmann, Konrad Rzeszutek Wilk, Chris Metcalf,
Bjorn Helgaas, Thomas Gleixner, linux-arm-kernel,
Thomas Petazzoni, Liviu Dudau, Tony Luck, Sergei Shtylyov,
linux-kernel, Ralf Baechle, iommu, David Vrabel, Wuyun,
linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140926090537.GH31106@ulmo>
On 2014/9/26 17:05, Thierry Reding wrote:
> On Fri, Sep 26, 2014 at 10:54:32AM +0200, Thierry Reding wrote:
> [...]
>> At least for Tegra it's trivial to just hook it up in tegra_pcie_scan_bus()
>> directly (patch attached).
>
> Really attached this time.
>
> Thierry
>
It looks good to me, so I will update the arm pci hostbridge driver to assign
pci root bus the msi chip instead of current pcibios_add_bus(). But for other
platforms which only have a one msi chip, I will kept the arch_find_msi_chip()
temporarily for more comments, especially from Bjorn.
Thanks!
Yijing.
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
From: Yijing Wang @ 2014-09-28 2:16 UTC (permalink / raw)
To: Liviu Dudau
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
Thomas Gleixner, linux-arm-kernel, Thomas Petazzoni, Xinwei Hu,
Tony Luck, Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu,
David Vrabel, Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <20140926085030.GE31157@bart.dudau.co.uk>
>>>> What I would like to see is a way of creating the pci_host_bridge structure outside
>>>> the pci_create_root_bus(). That would then allow us to pass this sort of platform
>>>> details like associated msi_chip into the host bridge and the child busses will
>>>> have an easy way of finding the information needed by finding the root bus and then
>>>> the host bridge structure. Then the generic pci_scan_root_bus() can be used by (mostly)
>>>> everyone and the drivers can remove their kludges that try to work around the
>>>> current limitations.
>>
>> So I think maybe save msi chip in PCI arch sysdata is a good candidate.
>
> Except that arch sysdata at the moment is an opaque pointer. I am all in favour in
> changing the type of sysdata from void* into pci_host_bridge* and arches can wrap their old
> sysdata around the pci_host_bridge*.
I inspected every arch and found there are almost no common stuff, and generic data struct should
be created in generic PCI code. Another, I don't like associate msi chip and every PCI device, further more,
almost all platforms except arm have only one MSI controller, and currently, PCI enumerating code doesn't need
to know the MSI chip details, like for legacy IRQ, PCI device doesn't need to know which IRQ controller they
should deliver IRQ to. I would think more about it, and hope other PCI guys can give some comments, especially from Bjorn.
Thanks!
Yijing.
>
> Best regards,
> Liviu
>
>>
>>>
>>> I think both issues are orthogonal. Last time I checked a lot of work
>>> was still necessary to unify host bridges enough so that it could be
>>> shared across architectures. But perhaps some of that work has
>>> happened in the meantime.
>>>
>>> But like I said, when you create the root bus, you can easily attach the
>>> MSI chip to it.
>>>
>>> Thierry
>>>
>>
>>
>> --
>> Thanks!
>> Yijing
>>
>>
>
--
Thanks!
Yijing
^ permalink raw reply
* Re: [PATCH 3/3] powerpc/ftrace: simplify prepare_ftrace_return
From: Segher Boessenkool @ 2014-09-27 0:22 UTC (permalink / raw)
To: Anton Blanchard; +Cc: paulus, linuxppc-dev, Steven Rostedt, Alan Modra
In-Reply-To: <20140924123307.7649bec8@kryten>
On Wed, Sep 24, 2014 at 12:33:07PM +1000, Anton Blanchard wrote:
> We are scratching our heads trying to remember details of the issue
> right now. In retrospect we should have linked the gcc bugzilla or
> gcc commit details in the kernel commit message :)
There have been many GCC bugs in this area.
30282 (for 32-bit)
44199 (for 64-bit)
52828 (for everything, and this one should finally handle things for good)
Also a bunch of duplicates, and I'm sure I've missed some more.
The original issue as far as I remember: when using a frame pointer, GCC
would sometimes schedule the epilogue to do the stack adjust before
restoring all regs from the stack. Then an interrupt comes in, those
saved regs are clobbered, kaboom. We cannot disable the frame pointer
because -pg forces it (although PowerPC does not need it). The
-mno-sched-epilog flag is a workaround: the epilogue (and prologue) will
not be reordered by instruction scheduling. Slow code is better than
blowing up fast ;-)
Segher
^ permalink raw reply
* Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
From: Mike Turquette @ 2014-09-26 23:29 UTC (permalink / raw)
To: Scott Wood
Cc: linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, Lu Jingchang-B35083
In-Reply-To: <1411685780.13320.209.camel@snotra.buserror.net>
Quoting Scott Wood (2014-09-25 15:56:20)
> On Thu, 2014-09-25 at 15:54 -0700, Mike Turquette wrote:
> > Quoting Scott Wood (2014-09-25 13:08:00)
> > > Well, like I said, I'd rather see the CLK_OF_DECLARE stuff be made to
> > > work on PPC rather than have the driver carry around two binding
> > > methods.
> > =
> > I guess that is an existing problem, and not related directly to this
> > patch? This patch is essentially just renames (though the V1.0/V2.0
> > stuff seems weird).
> =
> This patch is adding CLK_OF_DECLARE.
I'm fine taking this patch but your comments are still unresolved. What
do you think needs to be done to fix the problems that you see?
Regards,
Mike
> =
> -Scott
> =
>=20
^ permalink raw reply
* Re: [PATCH][V2] Freescale Frame Manager Device Tree binding document
From: Bob Cochran @ 2014-09-26 16:37 UTC (permalink / raw)
To: Igal.Liberman, devicetree, linuxppc-dev, netdev; +Cc: scottwood, Emilian.Medve
In-Reply-To: <1410952110-32733-1-git-send-email-igal.liberman@freescale.com>
On 09/17/2014 07:08 AM, Igal.Liberman wrote:
> From: Igal Liberman <Igal.Liberman@freescale.com>
>
> The Frame Manager (FMan) combines the Ethernet network interfaces with packet
> distribution logic to provide intelligent distribution and queuing decisions
> for incoming traffic at line rate.
>
> This binding document describes Freescale's Frame Manager hardware attributes
> that are used by the Frame Manager driver for its basic initialization and
> configuration.
>
> Difference between [V1] and [V2]:
> Addressed all comments recieved from Scott in [V1]
>
> Signed-off-by: Igal Liberman <Igal.Liberman@freescale.com>
Is there a reference (FMAN) dts file I can compare this against? I was
reviewing this against my (combined) dts file for my t1040rdb built with
either FSL's SDK1.6 or Yocto Project meta-fsl-ppc master branch, and I'm
not finding a good match between the nodes / properties in my dts file
and what you have here.
For example, I don't find the required "clocks" or
"fsl,qman-channel-range" properties under my <fman0: fman@400000 ...>
node.
I'm wondering if this document is trailing or leading the source in the
latest published FSL SDK (1.6).
And a minor nit pick: twice you write "bellow" where you should have "below"
Thanks
Bob
> ---
> .../devicetree/bindings/powerpc/fsl/fman.txt | 529 ++++++++++++++++++++
> 1 file changed, 529 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/powerpc/fsl/fman.txt
>
> diff --git a/Documentation/devicetree/bindings/powerpc/fsl/fman.txt b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> new file mode 100644
> index 0000000..da8e5f2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/powerpc/fsl/fman.txt
> @@ -0,0 +1,529 @@
> +=============================================================================
> +Freescale Frame Manager Device Bindings
> +
> +CONTENTS
> + - FMan Node
> + - FMan Port Node
> + - FMan MURAM Node
> + - FMan dTSEC/XGEC/mEMAC Node
> + - FMan IEEE 1588 Node
> + - Example
> +
> +=============================================================================
> +FMan Node
> +
> +DESCRIPTION
> +
> +Due to the fact that the FMan is an aggregation of sub-engines (ports, MACs,
> +etc.) the FMan node will have child nodes for each of them.
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: Must include "fsl,fman"
> + FMan version can be determined via FM_IP_REV_1 register in the
> + FMan block. The offset is 0xc4 from the beginning of the
> + Frame Processing Manager memory map (0xc3000 from the
> + beginning of the FMan node).
> +
> +- cell-index
> + Usage: required
> + Value type: <u32>
> + Definition: Specifies the index of the FMan unit.
> +
> + The cell-index value may be used by the SoC, to identify the
> + FMan unit in the SoC memory map. In the table bellow,
> + there's a description of the cell-index use in each SoC:
> +
> + - P1023:
> + register[bit] FMan unit cell-index
> + ============================================================
> + DEVDISR[1] 1 0
> +
> + - P2041, P3041, P4080 P5020, P5040:
> + register[bit] FMan unit cell-index
> + ============================================================
> + DCFG_DEVDISR2[6] 1 0
> + DCFG_DEVDISR2[14] 2 1
> + (Second FM available only in P4080 and P5040)
> +
> + - B4860, T1040, T2080, T4240:
> + register[bit] FMan unit cell-index
> + ============================================================
> + DCFG_CCSR_DEVDISR2[24] 1 0
> + DCFG_CCSR_DEVDISR2[25] 2 1
> + (Second FM available only in T4240)
> +
> + DEVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in
> + the specific SoC "Device Configuration/Pin Control" Memory
> + Map.
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property. Specifies the offset of the
> + following configuration registers:
> + - BMI configuration registers.
> + - QMI configuration registers.
> + - DMA configuration registers.
> + - FPM configuration registers.
> + - FMan controller configuration registers.
> +
> +- ranges
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> +
> +- clocks
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: phandle for fman clock.
> +
> +- clock-names
> + usage: optional
> + Value type: <stringlist>
> + Definition: A standard property
> +
> +- interrupts
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A pair of IRQs are specified in this property.
> + The first element is associated with the event interrupts and
> + the second element is associated with the error interrupts.
> +
> +- fsl,qman-channel-range
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: Specifies the range of the available dedicated
> + channels in the FMan. The first cell specifies the beginning
> + of the range and the second cell specifies the number of
> + channels.
> + Further information available at:
> + "Work Queue (WQ) Channel Assignments in the QMan" section
> + in DPAA Reference Manual.
> +
> +=============================================================================
> +FMan MURAM Node
> +
> +DESCRIPTION
> +
> +FMan Internal memory - shared between all the FMan modules.
> +It contains data structures that are common and written to or read by
> +the modules.
> +FMan internal memory is split into the following parts:
> + Packet buffering (Tx/Rx FIFOs)
> + Frames internal context
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: Must include "fsl,fman-muram"
> +
> +- ranges
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> + Specifies the multi-user memory offset and the size within
> + the FMan.
> +
> +EXAMPLE
> +
> +muram@0 {
> + compatible = "fsl,fman-muram";
> + ranges = <0 0x000000 0x28000>;
> +};
> +
> +=============================================================================
> +FMan Port Node
> +
> +DESCRIPTION
> +
> +The Frame Manager (FMan) supports several types of hardware ports:
> + Ethernet receiver (RX)
> + Ethernet transmitter (TX)
> + Offline/Host command (O/H)
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: A standard property.
> + Must include one of the following:
> + - "fsl,fman-v2-port-oh" for FManV2 OH ports
> + - "fsl,fman-v2-port-rx" for FManV2 RX ports
> + - "fsl,fman-v2-port-tx" for FManV2 TX ports
> + - "fsl,fman-v3-port-oh" for FManV3 OH ports
> + - "fsl,fman-v3-port-rx" for FManV3 RX ports
> + - "fsl,fman-v3-port-tx" for FManV3 TX ports
> +
> +- cell-index
> + Usage: required
> + Value type: <u32>
> + Definition: Specifies the hardware port id.
> + Each hardware port on the FMan has its own hardware PortID.
> + Super set of all hardware Port IDs available at FMan Reference
> + Manual under "FMan Hardware Ports in Freescale Devices" table.
> +
> + Each hardware port is assigned a 4KB, port-specific page in
> + the FMan hardware port memory region (which is part of the
> + FMan memory map). The first 4 KB in the FMan hardware ports
> + memory region is used for what are called common registers.
> + The subsequent 63 4KB pages are allocated to the hardware
> + ports.
> + The page of a specific port is determined by the cell-index.
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: There is one reg region describing the port
> + configuration registers.
> +
> +EXAMPLE
> +
> +port@a8000 {
> + cell-index = <0x28>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa8000 0x1000>;
> +};
> +
> +port@88000 {
> + cell-index = <0x8>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x88000 0x1000>;
> +};
> +
> +port@81000 {
> + cell-index = <0x1>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x81000 0x1000>;
> +};
> +
> +=============================================================================
> +FMan dTSEC/XGEC/mEMAC Node
> +
> +DESCRIPTION
> +
> +mEMAC/dTSEC/XGEC are the Ethernet network interfaces
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: A standard property.
> + Must include one of the following:
> + - "fsl,fman-dtsec" for dTSEC MAC
> + - "fsl,fman-xgec" for XGEC MAC
> + - "fsl,fman-memac for mEMAC MAC
> +
> +- cell-index
> + Usage: required
> + Value type: <u32>
> + Definition: Specifies the MAC id.
> +
> + The cell-index value may be used by the FMan or the SoC, to
> + identify the MAC unit in the FMan (or SoC) memory map.
> + In the tables bellow there's a description of the cell-index
> + use, there are two tables, one describes the use of cell-index
> + by the FMan, the second describes the use by the SoC:
> +
> + 1. FMan Registers
> +
> + FManV2:
> + register[bit] MAC cell-index
> + ============================================================
> + FM_EPI[16] XGEC 8
> + FM_EPI[16+n] dTSECn n-1
> + FM_NPI[11+n] dTSECn n-1
> + n = 1,..,5
> +
> + FManV3:
> + register[bit] MAC cell-index
> + ============================================================
> + FM_EPI[16+n] mEMACn n-1
> + FM_EPI[25] mEMAC10 9
> +
> + FM_NPI[11+n] mEMACn n-1
> + FM_NPI[10] mEMAC10 9
> + FM_NPI[11] mEMAC9 8
> + n = 1,..8
> +
> + FM_EPI and FM_NPI are located in the FMan memory map.
> +
> + 2. SoC registers:
> +
> + - P2041, P3041, P4080 P5020, P5040:
> + register[bit] FMan MAC cell
> + Unit index
> + ============================================================
> + DCFG_DEVDISR2[7] 1 XGEC 8
> + DCFG_DEVDISR2[7+n] 1 dTSECn n-1
> + DCFG_DEVDISR2[15] 2 XGEC 8
> + DCFG_DEVDISR2[15+n] 2 dTSECn n-1
> + n = 1,..5
> +
> + - T1040, T2080, T4240, B4860:
> + register[bit] FMan MAC cell
> + Unit index
> + ============================================================
> + DCFG_CCSR_DEVDISR2[n-1] 1 mEMACn n-1
> + DCFG_CCSR_DEVDISR2[11+n] 2 mEMACn n-1
> + n = 1,..6,9,10
> +
> + EVDISR, DCFG_DEVDISR2 and DCFG_CCSR_DEVDISR2 are located in
> + the specific SoC "Device Configuration/Pin Control" Memory
> + Map.
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> +
> +- fsl,fman-ports
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: An array of two phandles - the first references is
> + the FMan RX port and the second is the TX port used by this
> + MAC.
> +
> +- ptp-timer
> + Usage required
> + Value type: <phandle>
> + Definition: A phandle for 1EEE1588 timer.
> +
> +EXAMPLE
> +
> +fman1_tx28: port@a8000 {
> + cell-index = <0x28>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa8000 0x1000>;
> +};
> +
> +fman1_rx8: port@88000 {
> + cell-index = <0x8>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x88000 0x1000>;
> +};
> +
> +ptp-timer: ptp_timer@fe000 {
> + compatible = "fsl,fman-ptp-timer";
> + reg = <0xfe000 0x1000>;
> +};
> +
> +ethernet@e0000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <0>;
> + reg = <0xe0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx8 &fman1_tx28>;
> + ptp-timer = <&ptp-timer>;
> +};
> +
> +============================================================================
> +FMan IEEE 1588 Node
> +
> +DESCRIPTION
> +
> +The FMan interface to support IEEE 1588
> +
> +
> +PROPERTIES
> +
> +- compatible
> + Usage: required
> + Value type: <stringlist>
> + Definition: A standard property.
> + Must include "fsl,fman-ptp-timer".
> +
> +- reg
> + Usage: required
> + Value type: <prop-encoded-array>
> + Definition: A standard property.
> +
> +EXAMPLE
> +
> +ptp-timer@fe000 {
> + compatible = "fsl,fman-ptp-timer";
> + reg = <0xfe000 0x1000>;
> +};
> +
> +=============================================================================
> +Example
> +
> +fman@400000 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + cell-index = <1>;
> + compatible = "fsl,fman"
> + ranges = <0 0x400000 0x100000>;
> + reg = <0x400000 0x100000>;
> + clocks = <&fman_clk>;
> + clock-names = "fmanclk";
> + interrupts = <
> + 96 2 0 0
> + 16 2 1 1>;
> + fsl,qman-channel-range = <0x40 0xc>;
> +
> + muram@0 {
> + compatible = "fsl,fman-muram";
> + reg = <0x0 0x28000>;
> + };
> +
> + port@81000 {
> + cell-index = <1>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x81000 0x1000>;
> + };
> +
> + port@82000 {
> + cell-index = <2>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x82000 0x1000>;
> + };
> +
> + port@83000 {
> + cell-index = <3>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x83000 0x1000>;
> + };
> +
> + port@84000 {
> + cell-index = <4>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x84000 0x1000>;
> + };
> +
> + port@85000 {
> + cell-index = <5>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x85000 0x1000>;
> + };
> +
> + port@86000 {
> + cell-index = <6>;
> + compatible = "fsl,fman-v2-port-oh";
> + reg = <0x86000 0x1000>;
> + };
> +
> + fman1_rx_0x8: port@88000 {
> + cell-index = <0x8>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x88000 0x1000>;
> + };
> +
> + fman1_rx_0x9: port@89000 {
> + cell-index = <0x9>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x89000 0x1000>;
> + };
> +
> + fman1_rx_0xa: port@8a000 {
> + cell-index = <0xa>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x8a000 0x1000>;
> + };
> +
> + fman1_rx_0xb: port@8b000 {
> + cell-index = <0xb>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x8b000 0x1000>;
> + };
> +
> + fman1_rx_0xc: port@8c000 {
> + cell-index = <0xc>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x8c000 0x1000>;
> + };
> +
> + fman1_rx_0x10: port@90000 {
> + cell-index = <0x10>;
> + compatible = "fsl,fman-v2-port-rx";
> + reg = <0x90000 0x1000>;
> + };
> +
> + fman1_tx_0x28: port@a8000 {
> + cell-index = <0x28>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa8000 0x1000>;
> + };
> +
> + fman1_tx_0x29: port@a9000 {
> + cell-index = <0x29>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xa9000 0x1000>;
> + };
> +
> + fman1_tx_0x2a: port@aa000 {
> + cell-index = <0x2a>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xaa000 0x1000>;
> + };
> +
> + fman1_tx_0x2b: port@ab000 {
> + cell-index = <0x2b>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xab000 0x1000>;
> + };
> +
> + fman1_tx_0x2c: port@ac0000 {
> + cell-index = <0x2c>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xac000 0x1000>;
> + };
> +
> + fman1_tx_0x30: port@b0000 {
> + cell-index = <0x30>;
> + compatible = "fsl,fman-v2-port-tx";
> + reg = <0xb0000 0x1000>;
> + };
> +
> + ethernet@e0000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <0>;
> + reg = <0xe0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0x8 &fman1_tx_0x28>;
> + };
> +
> + ethernet@e2000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <1>;
> + reg = <0xe2000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0x9 &fman1_tx_0x29>;
> + };
> +
> + ethernet@e4000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <2>;
> + reg = <0xe4000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0xa &fman1_tx_0x2a>;
> + };
> +
> + ethernet@e6000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <3>;
> + reg = <0xe6000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0xb &fman1_tx_0x2b>;
> + };
> +
> + ethernet@e8000 {
> + compatible = "fsl,fman-dtsec";
> + cell-index = <4>;
> + reg = <0xf0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0xc &fman1_tx_0x2c>;
> +
> + ethernet@f0000 {
> + cell-index = <8>;
> + compatible = "fsl,fman-xgec";
> + reg = <0xf0000 0x1000>;
> + fsl,fman-ports = <&fman1_rx_0x10 &fman1_tx_0x30>;
> + };
> +
> + ptp-timer@fe000 {
> + compatible = "fsl,fman-ptp-timer";
> + reg = <0xfe000 0x1000>;
> + };
> +};
>
^ permalink raw reply
* Re: [PATCH 10/15] powerpc/mm: Add hooks for cxl
From: Anton Blanchard @ 2014-09-26 13:24 UTC (permalink / raw)
To: Michael Neuling
Cc: cbe-oss-dev, arnd, greg, linux-kernel, imunsie, linuxppc-dev, jk
In-Reply-To: <1411731209.1733.51.camel@ale.ozlabs.ibm.com>
Hi Mikey,
> We only map what a user processes maps and we tear it down when the
> process is teared down (on the file descriptor release). So I think
> we are ok.
>
> Unless there's some lazy teardown you're alluding to that I'm missing?
I was trying to make sure things like the TLB batching code won't allow
a tlbie to be postponed until after a CAPI mapping is destroyed. It's
been ages since I looked at that part of the mm code.
Anton
^ permalink raw reply
* Re: [PATCH 10/15] powerpc/mm: Add hooks for cxl
From: Michael Neuling @ 2014-09-26 11:33 UTC (permalink / raw)
To: Anton Blanchard
Cc: cbe-oss-dev, arnd, greg, linux-kernel, imunsie, linuxppc-dev, jk
In-Reply-To: <20140926143309.33c0eeac@kryten>
On Fri, 2014-09-26 at 14:33 +1000, Anton Blanchard wrote:
> > From: Ian Munsie <imunsie@au1.ibm.com>
> >=20
> > This add a hook into tlbie() so that we use global invalidations when
> > there are cxl contexts active.
> >=20
> > Normally cxl snoops broadcast tlbie. cxl can have TLB entries
> > invalidated via MMIO, but we aren't doing that yet. So for now we
> > are just disabling local tlbies when cxl contexts are active. In
> > future we can make tlbie() local mode smarter so that it invalidates
> > cxl contexts explicitly when it needs to.
> >=20
> > This also adds a hooks for when SLBs are invalidated to ensure any
> > corresponding SLBs in cxl are also invalidated at the same time.
> >=20
> > Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
>=20
> > + use_local =3D local && mmu_has_feature(MMU_FTR_TLBIEL) && !cxl_ctx_in=
_use();
>=20
> Seems reasonable until we can get the MMIO based optimisation in.
>=20
> Will all CAPI cached translations be invalidated before we finish using
> a CAPI context?=20
I'm not sure I understand. Can you elaborate?
> And conversely, could CAPI cache any translations when a
> context isn't active?=20
The kernel invalidates all translations when the file descriptor is
closed. So no, unless the PSL was badly behaving and ignoring the
invalidations.... but if we can't trust the PSL we're screwed.
> I'm mostly concerned that we can't have a
> situation where badly behaving userspace could result in a stale
> translation.
We only map what a user processes maps and we tear it down when the
process is teared down (on the file descriptor release). So I think we
are ok. =20
Unless there's some lazy teardown you're alluding to that I'm missing?
>=20
> > spu_flush_all_slbs(mm);
> > #endif
> > + cxl_slbia(mm);
>=20
> > spu_flush_all_slbs(mm);
> > #endif
> > + cxl_slbia(mm);
>=20
> > spu_flush_all_slbs(mm);
> > #endif
> > + cxl_slbia(mm);
>=20
> > spu_flush_all_slbs(mm);
> > #endif
> > + cxl_slbia(mm);
>=20
> Should we combine the SPU vs CXL callouts into something common -
> perhaps copro_flush_all_slbs()?
Sounds good. I'll update.
Mikey
^ permalink raw reply
* Re: [PATCH 02/15] powerpc/cell: Move data segment faulting code out of cell platform
From: Michael Neuling @ 2014-09-26 11:19 UTC (permalink / raw)
To: Anton Blanchard
Cc: cbe-oss-dev, arnd, greg, linux-kernel, imunsie, linuxppc-dev, jk
In-Reply-To: <20140926140506.3d8fdac3@kryten>
On Fri, 2014-09-26 at 14:05 +1000, Anton Blanchard wrote:
> > From: Ian Munsie <imunsie@au1.ibm.com>
> >=20
> > __spu_trap_data_seg() currently contains code to determine the VSID
> > and ESID required for a particular EA and mm struct.
> >=20
> > This code is generically useful for other co-processors. This moves
> > the code of the cell platform so it can be used by other powerpc code.
>=20
> Could we also mention:
>=20
> and adds 1TB segment support.
Good point. I'll add.
> > Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
> > Signed-off-by: Michael Neuling <mikey@neuling.org>
>=20
> Reviewed-by: Anton Blanchard <anton@samba.org>
Thanks,
Mikey
^ permalink raw reply
* Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
From: Thomas Gleixner @ 2014-09-26 10:38 UTC (permalink / raw)
To: Yijing Wang
Cc: linux-mips, linux-ia64, linux-pci, Bharat.Bhushan, Thierry Reding,
sparclinux, linux-arch, linux-s390, Russell King, Joerg Roedel,
x86, Sebastian Ott, xen-devel, arnab.basu, Arnd Bergmann,
Konrad Rzeszutek Wilk, Chris Metcalf, Bjorn Helgaas,
linux-arm-kernel, Thomas Petazzoni, Xinwei Hu, Tony Luck,
Sergei Shtylyov, linux-kernel, Ralf Baechle, iommu, David Vrabel,
Wuyun, linuxppc-dev, David S. Miller, Lucas Stach
In-Reply-To: <5424D30A.6040900@huawei.com>
On Fri, 26 Sep 2014, Yijing Wang wrote:
> On 2014/9/25 18:38, Thomas Gleixner wrote:
> > On Thu, 25 Sep 2014, Yijing Wang wrote:
> >
> >> Introduce weak arch_find_msi_chip() to find the match msi_chip.
> >> Currently, MSI chip associates pci bus to msi_chip. Because in
> >> ARM platform, there may be more than one MSI controller in system.
> >> Associate pci bus to msi_chip help pci device to find the match
> >> msi_chip and setup MSI/MSI-X irq correctly. But in other platform,
> >> like in x86. we only need one MSI chip, because all device use
> >> the same MSI address/data and irq etc. So it's no need to associate
> >> pci bus to MSI chip, just use a arch function, arch_find_msi_chip()
> >> to return the MSI chip for simplicity. The default weak
> >> arch_find_msi_chip() used in ARM platform, find the MSI chip
> >> by pci bus.
> >
> > This is really backwards. On one hand you try to get rid of the weak
> > arch functions zoo and then you invent new ones for no good
> > reason. Why can't x86 store the chip in the pci bus?
> >
> > Looking deeper, I'm questioning the whole notion of different
> > msi_chips. Are this really different MSI controllers with a different
> > feature set or are this defacto multiple instances of the same
> > controller which just need a different data set?
>
> MSI chip in this series is to setup MSI irq, including IRQ allocation, Map,
> compose MSI msg ..., in different platform, many arch specific MSI irq details in it.
> It's difficult to extract the common data and code.
>
> I have a plan to rework MSI related irq_chips in kernel, PCI and Non-PCI, currently,
> HPET, DMAR and PCI have their own irq_chip and MSI related functions, write_msi_msg(),
> mask_msi_irq(), etc... I want to extract the common data set for that, so we can
> remove lots of unnecessary MSI code.
That makes sense. Can you please make sure that this does not conflict
with the ongoing work Jiang is doing in the x86 irq area with
hierarchical irqdomains to distangle layered levels like MSI from the
underlying vector/irqremap mechanics.
Thanks,
tglx
^ 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