Re: [RFC PATCH] powerpc/powernv: Fix dma_ops for bypass window
On Thu, Sep 25, 2014 at 02:14:20PM +1000, Gavin Shan wrote:
Please ignore this. I was told by Ben some drivers don't call
set_dev_mask(). So I have to fix it in another way.
Thanks,
Gavin
When using bypass window on IODA2, the incorrect DMA operations
dma_iommu_ops is used by devices. The device driver calls
dma_get_required_mask() to determine using 32-bits or bypass DMA
window. Unfortunately, the returned DMA mask always forces the
driver to use 32-bits DMA window. The problem was reported on
the device as follows:
0004:03:00.0 0107: 1000:0087 (rev 05)
0004:03:00.0 Serial Attached SCSI controller: LSI Logic / Symbios \
Logic SAS2308 PCI-Express Fusion-MPT SAS-2 (rev 05)
The patch fixes above issue by keeping things consistent: when
enabling bypass window, we switch to dma_direct_ops. Instead,
switch to pci_dma_ops when disabling bypass window.
Reported-by: Murali N. Iyer mni...@us.ibm.com
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/platforms/powernv/pci-ioda.c | 76 +++
1 file changed, 46 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 36b1a7a..60e44d9 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -883,13 +883,29 @@ static int pnv_pci_ioda_dma_set_mask(struct pnv_phb *phb,
set_dma_offset(pdev-dev, pe-tce_bypass_base);
} else {
dev_info(pdev-dev, Using 32-bit DMA via iommu\n);
- set_dma_ops(pdev-dev, dma_iommu_ops);
+ set_dma_ops(pdev-dev, get_pci_dma_ops());
set_iommu_table_base(pdev-dev, pe-tce32_table);
}
*pdev-dev.dma_mask = dma_mask;
return 0;
}
+static void pnv_ioda_setup_dev_dma(struct pnv_ioda_pe *pe,
+ struct pci_dev *pdev,
+ bool add_to_iommu_group)
+{
+ if (pe-tce_bypass_enabled) {
+ set_dma_ops(pdev-dev, dma_direct_ops);
+ set_dma_offset(pdev-dev, pe-tce_bypass_base);
+ } else {
+ set_dma_ops(pdev-dev, get_pci_dma_ops());
+ set_iommu_table_base(pdev-dev, pe-tce32_table);
+ }
+
+ if (add_to_iommu_group)
+ iommu_add_device(pdev-dev);
+}
+
static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe,
struct pci_bus *bus,
bool add_to_iommu_group)
@@ -897,11 +913,7 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe,
struct pci_dev *dev;
list_for_each_entry(dev, bus-devices, bus_list) {
- if (add_to_iommu_group)
- set_iommu_table_base_and_group(dev-dev,
- pe-tce32_table);
- else
- set_iommu_table_base(dev-dev, pe-tce32_table);
+ pnv_ioda_setup_dev_dma(pe, dev, add_to_iommu_group);
if (dev-subordinate)
pnv_ioda_setup_bus_dma(pe, dev-subordinate,
@@ -909,6 +921,15 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe,
}
}
+static void pnv_ioda_setup_pe_dma(struct pnv_ioda_pe *pe,
+bool add_to_iommu_group)
+{
+ if (pe-pdev)
+ pnv_ioda_setup_dev_dma(pe, pe-pdev, add_to_iommu_group);
+ else
+ pnv_ioda_setup_bus_dma(pe, pe-pbus, add_to_iommu_group);
+}
+
static void pnv_pci_ioda1_tce_invalidate(struct pnv_ioda_pe *pe,
struct iommu_table *tbl,
__be64 *startp, __be64 *endp, bool rm)
@@ -1080,11 +1101,7 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb
*phb,
iommu_init_table(tbl, phb-hose-node);
iommu_register_group(tbl, phb-hose-global_number, pe-pe_number);
- if (pe-pdev)
- set_iommu_table_base_and_group(pe-pdev-dev, tbl);
- else
- pnv_ioda_setup_bus_dma(pe, pe-pbus, true);
-
+ pnv_ioda_setup_pe_dma(pe, true);
return;
fail:
/* XXX Failure: Try to fallback to 64-bit only ? */
@@ -1101,7 +1118,13 @@ static void pnv_pci_ioda2_set_bypass(struct iommu_table
*tbl, bool enable)
uint16_t window_id = (pe-pe_number 1 ) + 1;
int64_t rc;
+ /* Check if we really need do something */
+ if (pe-tce_bypass_enabled == enable)
+ return;
+
pe_info(pe, %sabling 64-bit DMA bypass\n, enable ? En : Dis);
+ pe-tce_bypass_enabled = enable;
+
if (enable) {
phys_addr_t top = memblock_end_of_DRAM();
@@ -1117,22 +1140,15 @@ static void pnv_pci_ioda2_set_bypass(struct
iommu_table *tbl, bool enable)
window_id,
pe-tce_bypass_base,
0);
-
-
[PATCH v3] powerpc/iommu/ddw: Fix endianness
rtas_call() accepts and returns values in CPU endianness.
The ddw_query_response and ddw_create_response structs members are
defined and treated as BE but as they are passed to rtas_call() as
(u32 *) and they get byteswapped automatically, the data is CPU-endian.
This fixes ddw_query_response and ddw_create_response definitions and use.
of_read_number() is designed to work with device tree cells - it assumes
the input is big-endian and returns data in CPU-endian. However due
to the ddw_create_response struct fix, create.addr_hi/lo are already
CPU-endian so do not byteswap them.
ddw_avail is a pointer to the ibm,ddw-applicable property which contains
3 cells which are big-endian as it is a device tree. rtas_call() accepts
a RTAS token in CPU-endian. This makes use of of_property_read_u32_array
to byte swap and avoid the need for a number of be32_to_cpu calls.
Cc: sta...@vger.kernel.org # v3.13
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Reviewed-by: Anton Blanchard an...@samba.org
[aik: folded Anton's patch with of_property_read_u32_array]
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v3:
* of_property_read_u32_array() is used for ddw_avail[]
v2:
* updated commit log
* fixed definition of ddw_query_response and ddw_create_response
---
arch/powerpc/platforms/pseries/iommu.c | 51 +++---
1 file changed, 28 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 4642d6a..de1ec54 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -329,16 +329,16 @@ struct direct_window {
/* Dynamic DMA Window support */
struct ddw_query_response {
- __be32 windows_available;
- __be32 largest_available_block;
- __be32 page_size;
- __be32 migration_capable;
+ u32 windows_available;
+ u32 largest_available_block;
+ u32 page_size;
+ u32 migration_capable;
};
struct ddw_create_response {
- __be32 liobn;
- __be32 addr_hi;
- __be32 addr_lo;
+ u32 liobn;
+ u32 addr_hi;
+ u32 addr_lo;
};
static LIST_HEAD(direct_window_list);
@@ -725,16 +725,18 @@ static void remove_ddw(struct device_node *np, bool
remove_prop)
{
struct dynamic_dma_window_prop *dwp;
struct property *win64;
- const u32 *ddw_avail;
+ u32 ddw_avail[3];
u64 liobn;
- int len, ret = 0;
+ int ret = 0;
+
+ ret = of_property_read_u32_array(np, ibm,ddw-applicable,
+ddw_avail[0], 3);
- ddw_avail = of_get_property(np, ibm,ddw-applicable, len);
win64 = of_find_property(np, DIRECT64_PROPNAME, NULL);
if (!win64)
return;
- if (!ddw_avail || len 3 * sizeof(u32) || win64-length sizeof(*dwp))
+ if (ret || win64-length sizeof(*dwp))
goto delprop;
dwp = win64-value;
@@ -872,8 +874,9 @@ static int create_ddw(struct pci_dev *dev, const u32
*ddw_avail,
do {
/* extra outputs are LIOBN and dma-addr (hi, lo) */
- ret = rtas_call(ddw_avail[1], 5, 4, (u32 *)create, cfg_addr,
- BUID_HI(buid), BUID_LO(buid), page_shift,
window_shift);
+ ret = rtas_call(ddw_avail[1], 5, 4, (u32 *)create,
+ cfg_addr, BUID_HI(buid), BUID_LO(buid),
+ page_shift, window_shift);
} while (rtas_busy_delay(ret));
dev_info(dev-dev,
ibm,create-pe-dma-window(%x) %x %x %x %x %x returned %d
@@ -910,7 +913,7 @@ static u64 enable_ddw(struct pci_dev *dev, struct
device_node *pdn)
int page_shift;
u64 dma_addr, max_addr;
struct device_node *dn;
- const u32 *uninitialized_var(ddw_avail);
+ u32 ddw_avail[3];
struct direct_window *window;
struct property *win64;
struct dynamic_dma_window_prop *ddwprop;
@@ -942,8 +945,9 @@ static u64 enable_ddw(struct pci_dev *dev, struct
device_node *pdn)
* for the given node in that order.
* the property is actually in the parent, not the PE
*/
- ddw_avail = of_get_property(pdn, ibm,ddw-applicable, len);
- if (!ddw_avail || len 3 * sizeof(u32))
+ ret = of_property_read_u32_array(pdn, ibm,ddw-applicable,
+ddw_avail[0], 3);
+ if (ret)
goto out_failed;
/*
@@ -966,11 +970,11 @@ static u64 enable_ddw(struct pci_dev *dev, struct
device_node *pdn)
dev_dbg(dev-dev, no free dynamic windows);
goto out_failed;
}
- if (be32_to_cpu(query.page_size) 4) {
+ if (query.page_size 4) {
page_shift = 24; /* 16MB */
- } else if (be32_to_cpu(query.page_size) 2) {
+ } else if (query.page_size 2) {
page_shift = 16; /* 64kB */
-
[PATCH v2 0/3] fix bugs in mobility RTAS calls
This patchset addresses endian issues and bugs in device tree update for ibm,update-nodes and ibm,update-properties RTAS calls. A subseqent patchset will deal with issues in device tree node addition (ibm,configure-connector RTAS call) as well as more robust handling of deleting critical device tree nodes. v1 attempted to keep the structure of the existing code. v2 rewrites the relevent sections of mobility.c. Cyril Bur (3): drivers/of: add of_changeset_apply_locked powerpc/pseries: create rtas buffer accessor powerpc/pseries: fix bugs in mobility RTAS calls arch/powerpc/platforms/pseries/Makefile | 4 +- arch/powerpc/platforms/pseries/mobility.c| 406 --- arch/powerpc/platforms/pseries/pseries.h | 41 +++ arch/powerpc/platforms/pseries/rtas_buffer.c | 126 + drivers/of/dynamic.c | 11 + include/linux/of.h | 1 + 6 files changed, 425 insertions(+), 164 deletions(-) create mode 100644 arch/powerpc/platforms/pseries/rtas_buffer.c -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/3] drivers/of: add of_changeset_apply_locked
Due to the requirement of of_changesets that of_changeset_apply be called
holding the of_mutex and that the of_mutex cannot be accessed nicely outside
the of code, added a wrapper which grabs the lock and called
of_changeset_apply.
Signed-off-by: Cyril Bur cyril@au1.ibm.com
---
drivers/of/dynamic.c | 11 +++
include/linux/of.h | 1 +
2 files changed, 12 insertions(+)
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 54fecc4..cbff2a2 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -542,6 +542,17 @@ void of_changeset_destroy(struct of_changeset *ocs)
__of_changeset_entry_destroy(ce);
}
+int of_changeset_apply_locked(struct of_changeset *ocs)
+{
+ int ret;
+
+ mutex_lock(of_mutex);
+ ret = of_changeset_apply(ocs);
+ mutex_unlock(of_mutex);
+
+ return ret;
+}
+
/**
* of_changeset_apply - Applies a changeset
*
diff --git a/include/linux/of.h b/include/linux/of.h
index 6c4363b..f5c48fa 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -827,6 +827,7 @@ struct of_changeset {
extern void of_changeset_init(struct of_changeset *ocs);
extern void of_changeset_destroy(struct of_changeset *ocs);
extern int of_changeset_apply(struct of_changeset *ocs);
+extern int of_changeset_apply_locked(struct of_changeset *ocs);
extern int of_changeset_revert(struct of_changeset *ocs);
extern int of_changeset_action(struct of_changeset *ocs,
unsigned long action, struct device_node *np,
--
1.9.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 3/3] powerpc/pseries: fix bugs in mobility RTAS calls
These calls use a shared memory buffer to communicate device tree updates and
PAPR specifies that RTAS buffers are to be written in big endian. Used the
rtas buffer accessor to help solve both endian problems and standard buffer
access problems.
It seems more sane to stop trying to parse a buffer on errors. Attempting to
continue opens up the possibility of overflows and/or garbage reads. Used
of_changesets throughout to avoid leaving the device tree in an inconsitent
state on error.
Don't warn about failed allcations when the amount was taken from the buffer,
assume the value was incorrect, don't needlessly concern the user.
Signed-off-by: Cyril Bur cyril@au1.ibm.com
---
arch/powerpc/platforms/pseries/mobility.c | 406 ++
1 file changed, 243 insertions(+), 163 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/mobility.c
b/arch/powerpc/platforms/pseries/mobility.c
index e7cb6d4..37d16da 100644
--- a/arch/powerpc/platforms/pseries/mobility.c
+++ b/arch/powerpc/platforms/pseries/mobility.c
@@ -20,16 +20,11 @@
#include asm/machdep.h
#include asm/rtas.h
+
#include pseries.h
-static struct kobject *mobility_kobj;
-struct update_props_workarea {
- u32 phandle;
- u32 state;
- u64 reserved;
- u32 nprops;
-} __packed;
+static struct kobject *mobility_kobj;
#define NODE_ACTION_MASK 0xff00
#define NODE_COUNT_MASK0x00ff
@@ -40,7 +35,7 @@ struct update_props_workarea {
#define MIGRATION_SCOPE(1)
-static int mobility_rtas_call(int token, char *buf, s32 scope)
+static int mobility_rtas_call(int token, void *buf, s32 scope)
{
int rc;
@@ -54,171 +49,193 @@ static int mobility_rtas_call(int token, char *buf, s32
scope)
return rc;
}
-static int delete_dt_node(u32 phandle)
+static int create_property(struct rtas_buffer *rtas_buf, struct property
**prop,
+ const char *name, int length)
{
- struct device_node *dn;
-
- dn = of_find_node_by_phandle(phandle);
- if (!dn)
- return -ENOENT;
+ void *prop_value;
+ void *new_value;
- dlpar_detach_node(dn);
- of_node_put(dn);
- return 0;
-}
+ struct property *working_prop = *prop;
-static int update_dt_property(struct device_node *dn, struct property **prop,
- const char *name, u32 vd, char *value)
-{
- struct property *new_prop = *prop;
- int more = 0;
+ if (!get_rtas_buf_mem(rtas_buf, prop_value, length))
+ return -EOVERFLOW;
- /* A negative 'vd' value indicates that only part of the new property
-* value is contained in the buffer and we need to call
-* ibm,update-properties again to get the rest of the value.
-*
-* A negative value is also the two's compliment of the actual value.
-*/
- if (vd 0x8000) {
- vd = ~vd + 1;
- more = 1;
- }
-
- if (new_prop) {
- /* partial property fixup */
- char *new_data = kzalloc(new_prop-length + vd, GFP_KERNEL);
- if (!new_data)
- return -ENOMEM;
-
- memcpy(new_data, new_prop-value, new_prop-length);
- memcpy(new_data + new_prop-length, value, vd);
-
- kfree(new_prop-value);
- new_prop-value = new_data;
- new_prop-length += vd;
- } else {
- new_prop = kzalloc(sizeof(*new_prop), GFP_KERNEL);
- if (!new_prop)
- return -ENOMEM;
-
- new_prop-name = kstrdup(name, GFP_KERNEL);
- if (!new_prop-name) {
- kfree(new_prop);
+ if (!working_prop) {
+ working_prop = kzalloc(sizeof(*working_prop), GFP_KERNEL);
+ if (!working_prop) {
return -ENOMEM;
}
- new_prop-length = vd;
- new_prop-value = kzalloc(new_prop-length, GFP_KERNEL);
- if (!new_prop-value) {
- kfree(new_prop-name);
- kfree(new_prop);
+ working_prop-name = kstrdup(name, GFP_KERNEL | __GFP_NOWARN);
+ if (!working_prop-name) {
+ kfree(working_prop);
return -ENOMEM;
}
-
- memcpy(new_prop-value, value, vd);
- *prop = new_prop;
+ *prop = working_prop;
}
- if (!more) {
- of_update_property(dn, new_prop);
+ new_value = krealloc(working_prop-value, working_prop-length +
length, GFP_KERNEL | __GFP_NOWARN);
+ if (!new_value) {
+ kfree(working_prop-value);
+ kfree(working_prop-name);
+ kfree(working_prop);
*prop = NULL;
+ return -ENOMEM;
}
+ working_prop-value
[PATCH v2 2/3] powerpc/pseries: create rtas buffer accessor
Added simple accessor functions for rtas in memory buffers which performs
accesses of appropriate type and performs endian conversions.
Signed-off-by: Cyril Bur cyril@au1.ibm.com
---
arch/powerpc/platforms/pseries/Makefile | 4 +-
arch/powerpc/platforms/pseries/pseries.h | 41 +
arch/powerpc/platforms/pseries/rtas_buffer.c | 126 +++
3 files changed, 170 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/pseries/rtas_buffer.c
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 0348079..7eb7c46 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -3,7 +3,9 @@ ccflags-$(CONFIG_PPC_PSERIES_DEBUG) += -DDEBUG
obj-y := lpar.o hvCall.o nvram.o reconfig.o \
setup.o iommu.o event_sources.o ras.o \
- firmware.o power.o dlpar.o mobility.o rng.o
+ firmware.o power.o dlpar.o mobility.o \
+ rng.o rtas_buffer.o
+
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_SCANLOG) += scanlog.o
obj-$(CONFIG_EEH) += eeh_pseries.o
diff --git a/arch/powerpc/platforms/pseries/pseries.h
b/arch/powerpc/platforms/pseries/pseries.h
index 361add6..f24e352 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -66,4 +66,45 @@ int pseries_root_bridge_prepare(struct pci_host_bridge
*bridge);
unsigned long pseries_memory_block_size(void);
+/* Manipulation of the in memory data returned from an RTAS call */
+
+/* Data pointed to by ptr is in big endian */
+struct rtas_buffer {
+ void *ptr;
+ int len;
+ int pos;
+};
+
+/* Buffer is already zeroed */
+int make_rtas_buf(struct rtas_buffer *b, size_t size);
+void free_rtas_buf(struct rtas_buffer *b);
+
+/* Return pointer to the buffer being used */
+void *get_rtas_buf(struct rtas_buffer *b);
+
+/* Checks if the buffer exists and the read position is less than the length*/
+bool check_rtas_buf(struct rtas_buffer *b);
+size_t get_rtas_buf_size(struct rtas_buffer *b);
+
+/* Advance the internal position of the buffer by size bytes */
+bool advance_rtas_buf(struct rtas_buffer *b, size_t size);
+
+/* Put a value val into the buffer at position pos. Function expect val in cpu
+ * endian. Returns true if the write to the buffer was successful.
+ */
+bool put_rtas_buf_32(struct rtas_buffer *b, u32 val, int pos);
+
+/* Grab the byte at the current position of the buffer without incrementing
+ * the internal position of the buffer */
+bool peek_rtas_buf(struct rtas_buffer *b, u8 *c);
+
+/* Accessor functions return true if access succeeded and value is written to
+ * val in cpu endian. Automatically advances its reference into the buffer by
+ * the requested amount.
+ */
+bool get_rtas_buf_32(struct rtas_buffer *b, u32 *val);
+bool get_rtas_buf_64(struct rtas_buffer *b, u64 *val);
+bool get_rtas_buf_mem(struct rtas_buffer *b, void **p, size_t len);
+bool get_rtas_buf_str(struct rtas_buffer *b, char **s);
+
#endif /* _PSERIES_PSERIES_H */
diff --git a/arch/powerpc/platforms/pseries/rtas_buffer.c
b/arch/powerpc/platforms/pseries/rtas_buffer.c
new file mode 100644
index 000..f06b73c
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/rtas_buffer.c
@@ -0,0 +1,126 @@
+#include linux/kernel.h
+#include linux/slab.h
+
+#include pseries.h
+
+
+int make_rtas_buf(struct rtas_buffer *b, size_t sz)
+{
+ b-ptr = kzalloc(sz, GFP_KERNEL);
+ b-len = sz;
+ b-pos = 0;
+ return (!b-ptr) ? -ENOMEM : 0;
+}
+
+void free_rtas_buf(struct rtas_buffer *b)
+{
+ kfree(b-ptr);
+}
+
+void *get_rtas_buf(struct rtas_buffer *b)
+{
+ return (b) ? b-ptr : NULL;
+}
+
+size_t get_rtas_buf_size(struct rtas_buffer *b)
+{
+ return (b) ? b-len : 0;
+}
+
+bool check_rtas_buf(struct rtas_buffer *b)
+{
+ return (b b-ptr b-pos b-len);
+}
+
+static inline void *buf_pos(struct rtas_buffer *b)
+{
+ return (b b-ptr) ? b-ptr + b-pos : NULL;
+}
+
+bool peek_rtas_buf(struct rtas_buffer *b, u8 *c)
+{
+ if (!b || !c || b-pos = b-len)
+ return false;
+
+ *c = *(u8 *)buf_pos(b);
+
+ return true;
+}
+
+bool put_rtas_buf_32(struct rtas_buffer *b, u32 val, int pos)
+{
+ if (!b || b-pos = b-len)
+ return false;
+
+ *((__be32 *)buf_pos(b)) = cpu_to_be32(val);
+
+ return true;
+}
+
+bool get_rtas_buf_32(struct rtas_buffer *b, u32 *val)
+{
+ if (!b || !val || b-len - b-pos sizeof(u32))
+ return false;
+
+ *val = be32_to_cpu(*((__be32 *)buf_pos(b)));
+ b-pos += sizeof(u32);
+ return true;
+}
+
+bool get_rtas_buf_64(struct rtas_buffer *b, u64 *val)
+{
+ if (!b || !val || b-len - b-pos sizeof(u64))
+ return false;
+
+ *val = be64_to_cpu(*((__be64 *)buf_pos(b)));
+ b-pos += sizeof(u64);
+ return true;
+}
[PATCH] selftests/powerpc: Add test of load_unaligned_zero_pad()
It is a rarely exercised case, so we want to have a test to ensure it
works as required.
Signed-off-by: Anton Blanchard an...@samba.org
Signed-off-by: Michael Ellerman m...@ellerman.id.au
---
arch/powerpc/include/asm/word-at-a-time.h | 13 +-
tools/testing/selftests/powerpc/Makefile | 2 +-
.../testing/selftests/powerpc/primitives/Makefile | 17 +++
.../selftests/powerpc/primitives/asm/asm-compat.h | 1 +
.../selftests/powerpc/primitives/asm/ppc-opcode.h | 0
.../powerpc/primitives/load_unaligned_zeropad.c| 147 +
.../selftests/powerpc/primitives/word-at-a-time.h | 1 +
7 files changed, 179 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/selftests/powerpc/primitives/Makefile
create mode 12 tools/testing/selftests/powerpc/primitives/asm/asm-compat.h
create mode 100644 tools/testing/selftests/powerpc/primitives/asm/ppc-opcode.h
create mode 100644
tools/testing/selftests/powerpc/primitives/load_unaligned_zeropad.c
create mode 12 tools/testing/selftests/powerpc/primitives/word-at-a-time.h
diff --git a/arch/powerpc/include/asm/word-at-a-time.h
b/arch/powerpc/include/asm/word-at-a-time.h
index 07cc121e8a79..ea52b51be401 100644
--- a/arch/powerpc/include/asm/word-at-a-time.h
+++ b/arch/powerpc/include/asm/word-at-a-time.h
@@ -116,6 +116,15 @@ static inline unsigned long prep_zero_mask(unsigned long
a, unsigned long bits,
#endif
+/*
+ * We use load_unaligned_zero() in a selftest, which builds a userspace
+ * program. Some linker scripts seem to discard the .fixup section, so allow
+ * the test code to use a different section name.
+ */
+#ifndef FIXUP_SECTION
+#define FIXUP_SECTION .fixup
+#endif
+
static inline unsigned long load_unaligned_zeropad(const void *addr)
{
unsigned long ret, offset, tmp;
@@ -123,7 +132,7 @@ static inline unsigned long load_unaligned_zeropad(const
void *addr)
asm(
1: PPC_LL %[ret], 0(%[addr])\n
2:\n
- .section .fixup,\ax\\n
+ .section FIXUP_SECTION ,\ax\\n
3:
#ifdef __powerpc64__
clrrdi %[tmp], %[addr], 3\n\t
@@ -156,4 +165,6 @@ static inline unsigned long load_unaligned_zeropad(const
void *addr)
return ret;
}
+#undef FIXUP_SECTION
+
#endif /* _ASM_WORD_AT_A_TIME_H */
diff --git a/tools/testing/selftests/powerpc/Makefile
b/tools/testing/selftests/powerpc/Makefile
index 74a78cedce37..f6ff90a76bd7 100644
--- a/tools/testing/selftests/powerpc/Makefile
+++ b/tools/testing/selftests/powerpc/Makefile
@@ -13,7 +13,7 @@ CFLAGS := -Wall -O2 -flto -Wall -Werror
-DGIT_VERSION='$(GIT_VERSION)' -I$(CUR
export CC CFLAGS
-TARGETS = pmu copyloops mm tm
+TARGETS = pmu copyloops mm tm primitives
endif
diff --git a/tools/testing/selftests/powerpc/primitives/Makefile
b/tools/testing/selftests/powerpc/primitives/Makefile
new file mode 100644
index ..ea737ca01732
--- /dev/null
+++ b/tools/testing/selftests/powerpc/primitives/Makefile
@@ -0,0 +1,17 @@
+CFLAGS += -I$(CURDIR)
+
+PROGS := load_unaligned_zeropad
+
+all: $(PROGS)
+
+$(PROGS): ../harness.c
+
+run_tests: all
+ @-for PROG in $(PROGS); do \
+ ./$$PROG; \
+ done;
+
+clean:
+ rm -f $(PROGS) *.o
+
+.PHONY: all run_tests clean
diff --git a/tools/testing/selftests/powerpc/primitives/asm/asm-compat.h
b/tools/testing/selftests/powerpc/primitives/asm/asm-compat.h
new file mode 12
index ..b14255e15a25
--- /dev/null
+++ b/tools/testing/selftests/powerpc/primitives/asm/asm-compat.h
@@ -0,0 +1 @@
+../.././../../../../arch/powerpc/include/asm/asm-compat.h
\ No newline at end of file
diff --git a/tools/testing/selftests/powerpc/primitives/asm/ppc-opcode.h
b/tools/testing/selftests/powerpc/primitives/asm/ppc-opcode.h
new file mode 100644
index ..e69de29bb2d1
diff --git
a/tools/testing/selftests/powerpc/primitives/load_unaligned_zeropad.c
b/tools/testing/selftests/powerpc/primitives/load_unaligned_zeropad.c
new file mode 100644
index ..d1b647509596
--- /dev/null
+++ b/tools/testing/selftests/powerpc/primitives/load_unaligned_zeropad.c
@@ -0,0 +1,147 @@
+/*
+ * Userspace test harness for load_unaligned_zeropad. Creates two
+ * pages and uses mprotect to prevent access to the second page and
+ * a SEGV handler that walks the exception tables and runs the fixup
+ * routine.
+ *
+ * The results are compared against a normal load that is that is
+ * performed while access to the second page is enabled via mprotect.
+ *
+ * Copyright (C) 2014 Anton Blanchard an...@au.ibm.com, IBM
+ *
+ * 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.
+ */
+
+#include stdlib.h
+#include string.h
+#include stdio.h
+#include stdbool.h
+#include signal.h
+#include unistd.h
+#include sys/mman.h
+
+#define
Re: [PATCH v2 1/3] drivers/of: add of_changeset_apply_locked
Hi Cyril, Nit: On Thu, 25 Sep 2014 16:41:28 +1000 Cyril Bur cyril@au1.ibm.com wrote: Due to the requirement of of_changesets that of_changeset_apply be called holding the of_mutex and that the of_mutex cannot be accessed nicely outside the of code, added a wrapper which grabs the lock and called ^^ calls of_changeset_apply. -- Cheers, Stephen Rothwells...@canb.auug.org.au signature.asc Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 02/22] PCI/MSI: Remove useless bus-msi assignment
On Thu, Sep 25, 2014 at 11:14:12AM +0800, Yijing Wang wrote: Currently, PCI drivers will initialize bus-msi in pcibios_add_bus(). pcibios_add_bus() will be called in every pci bus initialization. So the bus-msi assignment in pci_alloc_child_bus() is useless. I think this should be the other way around. The default should be to inherit bus-msi from the parent. That way drivers don't typically have to do it, yet they can still opt to override it if they need to. For Tegra for example I think it would work if we assigned the MSI chip to the root bus (in tegra_pcie_scan_bus()) and then have it propagated to child busses in pci_alloc_child_bus() so that tegra_pcie_add_bus() can be removed altogether. Thierry pgpFwquRLDPN2.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 01/22] PCI/MSI: Clean up struct msi_chip argument
On Thu, Sep 25, 2014 at 11:14:11AM +0800, Yijing Wang wrote: Msi_chip functions setup_irq/teardown_irq rarely use msi_chip argument. That's not true. Out of the four drivers that you modify two use the parameter. And the two that don't probably should be using it too. 50% is not rarely. =) We can look up msi_chip pointer by the device pointer or irq number, so clean up msi_chip argument. I don't like this particular change. The idea was to keep the API object oriented so that drivers wouldn't have to know where to get the MSI chip from. It also makes it more resilient against code reorganizations since the core code is the only place that needs to know where to get the chip from. Thierry pgph9zihLqtV_.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 03/22] MSI: Remove the redundant irq_set_chip_data()
On Thu, Sep 25, 2014 at 11:14:13AM +0800, Yijing Wang wrote: Currently, pcie-designware, pcie-rcar, pci-tegra drivers use irq chip_data to save the msi_chip pointer. They already call irq_set_chip_data() in their own MSI irq map functions. So irq_set_chip_data() in arch_setup_msi_irq() is useless. Again, I think this should be the other way around. If drivers do something that's already handled by the core, then the duplicate code should be dropped from the drivers. Thierry pgpxIZ1YRzG2D.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2] powerpc/powernv: Override dma_get_required_mask()
When using bypass window on IODA2, the incorrect DMA operations
dma_iommu_ops is used by devices. The device driver calls
dma_get_required_mask() to determine using 32-bits or 64-bits
bypass DMA window. Unfortunately, the returned DMA mask always
forces the driver to use 32-bits DMA window. The problem was
reported on the device as follows:
0004:03:00.0 0107: 1000:0087 (rev 05)
0004:03:00.0 Serial Attached SCSI controller: LSI Logic / Symbios \
Logic SAS2308 PCI-Express Fusion-MPT SAS-2 (rev 05)
The patch fixes above issue by overriding dma_get_required_mask(),
which returns mask corresponding to bypass window base. Otherwise,
dma_iommu_ops::get_required_mask will be called to return mask
corresponding to 32-bits DMA window.
Reported-by: Murali N. Iyer mni...@us.ibm.com
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/dma-mapping.h| 1 +
arch/powerpc/kernel/dma.c | 14 ++
arch/powerpc/platforms/powernv/pci-ioda.c | 23 +++
arch/powerpc/platforms/powernv/pci.c | 11 +++
arch/powerpc/platforms/powernv/pci.h | 2 ++
arch/powerpc/platforms/powernv/powernv.h | 6 ++
arch/powerpc/platforms/powernv/setup.c| 9 +
7 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 150866b..894d538 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -135,6 +135,7 @@ static inline int dma_supported(struct device *dev, u64
mask)
extern int dma_set_mask(struct device *dev, u64 dma_mask);
extern int __dma_set_mask(struct device *dev, u64 dma_mask);
+extern u64 __dma_get_required_mask(struct device *dev);
#define dma_alloc_coherent(d,s,h,f)dma_alloc_attrs(d,s,h,f,NULL)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index ee78f6e..210ff9d 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -202,6 +202,7 @@ int __dma_set_mask(struct device *dev, u64 dma_mask)
*dev-dma_mask = dma_mask;
return 0;
}
+
int dma_set_mask(struct device *dev, u64 dma_mask)
{
if (ppc_md.dma_set_mask)
@@ -210,13 +211,10 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
}
EXPORT_SYMBOL(dma_set_mask);
-u64 dma_get_required_mask(struct device *dev)
+u64 __dma_get_required_mask(struct device *dev)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
- if (ppc_md.dma_get_required_mask)
- return ppc_md.dma_get_required_mask(dev);
-
if (unlikely(dma_ops == NULL))
return 0;
@@ -225,6 +223,14 @@ u64 dma_get_required_mask(struct device *dev)
return DMA_BIT_MASK(8 * sizeof(dma_addr_t));
}
+
+u64 dma_get_required_mask(struct device *dev)
+{
+ if (ppc_md.dma_get_required_mask)
+ return ppc_md.dma_get_required_mask(dev);
+
+ return __dma_get_required_mask(dev);
+}
EXPORT_SYMBOL_GPL(dma_get_required_mask);
static int __init dma_init(void)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 36b1a7a..380ebc9 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -890,6 +890,28 @@ static int pnv_pci_ioda_dma_set_mask(struct pnv_phb *phb,
return 0;
}
+static u64 pnv_pci_ioda_dma_get_required_mask(struct pnv_phb *phb,
+ struct pci_dev *pdev)
+{
+ struct pci_dn *pdn = pci_get_pdn(pdev);
+ struct pnv_ioda_pe *pe;
+ u64 end, mask;
+
+ if (WARN_ON(!pdn || pdn-pe_number == IODA_INVALID_PE))
+ return 0;
+
+ pe = phb-ioda.pe_array[pdn-pe_number];
+ if (!pe-tce_bypass_enabled)
+ return __dma_get_required_mask(pdev-dev);
+
+
+ end = pe-tce_bypass_base + memblock_end_of_DRAM();
+ mask = 1ULL (fls64(end) - 1);
+ mask += mask - 1;
+
+ return mask;
+}
+
static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe *pe,
struct pci_bus *bus,
bool add_to_iommu_group)
@@ -1782,6 +1804,7 @@ void __init pnv_pci_init_ioda_phb(struct device_node *np,
/* Setup TCEs */
phb-dma_dev_setup = pnv_pci_ioda_dma_dev_setup;
phb-dma_set_mask = pnv_pci_ioda_dma_set_mask;
+ phb-dma_get_required_mask = pnv_pci_ioda_dma_get_required_mask;
/* Setup shutdown function for kexec */
phb-shutdown = pnv_pci_ioda_shutdown;
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index b854b57..e9f509b 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -761,6 +761,17 @@ int pnv_pci_dma_set_mask(struct pci_dev *pdev, u64
dma_mask)
return __dma_set_mask(pdev-dev, dma_mask);
}
+u64 pnv_pci_dma_get_required_mask(struct pci_dev
Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
On Thu, Sep 25, 2014 at 11:14:16AM +0800, 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. Can't x86 simply set the bus' .msi field anyway? It would seem to be easy to do and unifies the code rather than driving it further apart using even more of the __weak functions. Thierry pgpWgEOYkYCBa.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 12/22] MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On Thu, Sep 25, 2014 at 11:14:22AM +0800, Yijing Wang wrote:
[...]
diff --git a/arch/mips/pci/msi-octeon.c b/arch/mips/pci/msi-octeon.c
[...]
@@ -132,12 +132,12 @@ msi_irq_allocated:
/* Make sure the search for available interrupts didn't fail */
if (irq = 64) {
if (request_private_bits) {
- pr_err(arch_setup_msi_irq: Unable to find %d free
interrupts, trying just one,
+ pr_err(octeon_setup_msi_irq: Unable to find %d free
interrupts, trying just one,
1 request_private_bits);
Perhaps while at it make this (and other similar changes in this patch):
pr_err(%s(): Unable to ..., __func__, ...);
So that it becomes more resilient against this kind of rename?
request_private_bits = 0;
goto try_only_one;
} else
- panic(arch_setup_msi_irq: Unable to find a free MSI
interrupt);
+ panic(octeon_setup_msi_irq: Unable to find a free MSI
interrupt);
@@ -210,14 +210,13 @@ int arch_setup_msi_irqs(struct pci_dev *dev, int nvec,
int type)
return 0;
}
-
This...
@@ -240,7 +239,7 @@ void arch_teardown_msi_irq(unsigned int irq)
*/
number_irqs = 0;
while ((irq0 + number_irqs 64)
-(msi_multiple_irq_bitmask[index]
+ (msi_multiple_irq_bitmask[index]
... and this seem like unrelated whitespace changes.
(1ull (irq0 + number_irqs
number_irqs++;
number_irqs++;
@@ -249,8 +248,8 @@ void arch_teardown_msi_irq(unsigned int irq)
/* Shift the mask to the correct bit location */
bitmask = irq0;
if ((msi_free_irq_bitmask[index] bitmask) != bitmask)
- panic(arch_teardown_msi_irq: Attempted to teardown MSI
- interrupt (%d) not in use, irq);
+ panic(octeon_teardown_msi_irq: Attempted to teardown MSI
+ interrupt (%d) not in use, irq);
And the second line here also needlessly changes the indentation.
Thierry
pgphO7kCbONIP.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 14/22] MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On Thu, Sep 25, 2014 at 11:14:24AM +0800, Yijing Wang wrote:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Nit: s/irq/IRQ/ in the above.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/mips/pci/msi-xlp.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/mips/pci/msi-xlp.c b/arch/mips/pci/msi-xlp.c
index e469dc7..6b791ef 100644
--- a/arch/mips/pci/msi-xlp.c
+++ b/arch/mips/pci/msi-xlp.c
@@ -245,7 +245,7 @@ static struct irq_chip xlp_msix_chip = {
.irq_unmask = unmask_msi_irq,
};
-void arch_teardown_msi_irq(unsigned int irq)
+void xlp_teardown_msi_irq(unsigned int irq)
Should this not be static now as well?
Thierry
pgphFbTjhVGSy.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 15/22] MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On Thu, Sep 25, 2014 at 11:14:25AM +0800, Yijing Wang wrote:
[...]
diff --git a/arch/mips/pci/pci-xlr.c b/arch/mips/pci/pci-xlr.c
[...]
@@ -214,11 +214,11 @@ static int get_irq_vector(const struct pci_dev *dev)
}
#ifdef CONFIG_PCI_MSI
-void arch_teardown_msi_irq(unsigned int irq)
+void xlr_teardown_msi_irq(unsigned int irq)
{
}
-int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
+int xlr_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
Can both of these now be static?
Thierry
pgpaAVXXtC0iK.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 17/22] s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On Thu, Sep 25, 2014 at 11:14:27AM +0800, Yijing Wang wrote: [...] diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c [...] @@ -358,7 +358,7 @@ static void zpci_irq_handler(struct airq_struct *airq) } } -int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type) +int zpci_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type) static? pgpVFB42NfoJx.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote: This series is based Bjorn's pci/msi branch git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi Currently, there are a lot of weak arch functions in MSI code. Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm. This series use MSI chip framework to refactor MSI code across all platforms to eliminate weak arch functions. Then all MSI irqs will be managed in a unified framework. Because this series changed a lot of ARCH MSI code, so tests in the platforms which MSI code modified are warmly welcomed! Apart from the comments to the individual patches I very much like where this is going. Thanks for taking care of this. Thierry pgpDwjda86h1Y.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 01/10] tools/perf: support parsing parameterized events
On Wed, Sep 24, 2014 at 12:27:15PM -0700, Sukadev Bhattiprolu wrote: From: Cody P Schafer c...@linux.vnet.ibm.com Enable event specification like: pmu/event_name,param1=0x1,param2=0x4/ Assuming that /sys/bus/event_source/devices/pmu/events/event_name Contains something like param2=foo,bar=1,param1=baz hum, so what happened to the '?' ... AFAIU from out last discussion, you wanted to mark terms which are mandatory and user must provide values for them.. and I thought the decision was to have following alias record: $ cat /sys/bus/event_source/devices/pmu/events/event_name param2=?,bar=1,param1=? while perf would scream if any of param1/2 wasnt filled like for: pmu/event_name,param1=0x1/ thanks, jirka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 01/22] PCI/MSI: Clean up struct msi_chip argument
On Thu, 25 Sep 2014, Thierry Reding wrote: On Thu, Sep 25, 2014 at 11:14:11AM +0800, Yijing Wang wrote: Msi_chip functions setup_irq/teardown_irq rarely use msi_chip argument. That's not true. Out of the four drivers that you modify two use the parameter. And the two that don't probably should be using it too. 50% is not rarely. =) We can look up msi_chip pointer by the device pointer or irq number, so clean up msi_chip argument. I don't like this particular change. The idea was to keep the API object oriented so that drivers wouldn't have to know where to get the MSI chip from. It also makes it more resilient against code reorganizations since the core code is the only place that needs to know where to get the chip from. Right. We have the same thing in the irq_chip callbacks. All of them take struct irq_data, because it's already available in the core code and it gives easy access to all information (chip, chipdata ...) which is necessary for the callback implementations. Thanks, tglx ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
Hi, Scott and Mike,
Could you please help review this patch and give an ACK if ok. Thanks.
Best Regards,
Jingchang
-Original Message-
From: Jingchang Lu [mailto:jingchang...@freescale.com]
Sent: Tuesday, September 23, 2014 2:47 PM
To: mturque...@linaro.org
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; linux-
ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Lu
Jingchang-B35083
Subject: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add
CLK_OF_DECLARE support
The IP is shared by PPC and ARM, this renames it to qoriq for better
represention, and this also adds the CLK_OF_DECLARE support for being
initialized by of_clk_init() on ARM.
Signed-off-by: Jingchang Lu jingchang...@freescale.com
---
changes in v4:
remove corenet literals omitted in v3 remove.
changes in v3:
generate the patch with -M -C option
changes in v2:
rename the driver name to ppc-qoriq.c for shared on PPC and ARM.
drivers/clk/Kconfig| 9 +
drivers/clk/Makefile | 2 +-
drivers/clk/{clk-ppc-corenet.c = clk-qoriq.c} | 27 +++--
-
3 files changed, 22 insertions(+), 16 deletions(-) rename
drivers/clk/{clk-ppc-corenet.c = clk-qoriq.c} (89%)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
85131ae..f5f76cb 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -92,12 +92,13 @@ config COMMON_CLK_AXI_CLKGEN
Support for the Analog Devices axi-clkgen pcore clock generator
for Xilinx
FPGAs. It is commonly used in Analog Devices' reference designs.
-config CLK_PPC_CORENET
- bool Clock driver for PowerPC corenet platforms
- depends on PPC_E500MC OF
+config CLK_QORIQ
+ bool Clock driver for PowerPC corenet and compatible ARM-based
platforms
+ depends on (PPC_E500MC || ARM) OF
---help---
This adds the clock driver support for Freescale PowerPC corenet
-platforms using common clock framework.
+platforms and compatible Freescale ARM based platforms using
common
+clock framework.
config COMMON_CLK_XGENE
bool Clock driver for APM XGene SoC
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
27c542b..20f42e9 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -29,7 +29,7 @@ obj-$(CONFIG_ARCH_MOXART)+= clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK)+= clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
obj-$(CONFIG_COMMON_CLK_PALMAS) += clk-palmas.o
-obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+obj-$(CONFIG_CLK_QORIQ) += clk-qoriq.o
obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
obj-$(CONFIG_COMMON_CLK_SI570)+= clk-si570.o
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-qoriq.c
similarity index 89% rename from drivers/clk/clk-ppc-corenet.c rename to
drivers/clk/clk-qoriq.c index 8e58edf..cba8abe 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-qoriq.c
@@ -155,7 +155,7 @@ static void __init core_pll_init(struct device_node
*np)
base = of_iomap(np, 0);
if (!base) {
- pr_err(clk-ppc: iomap error\n);
+ pr_err(clk-qoriq: iomap error\n);
return;
}
@@ -252,7 +252,7 @@ static void __init sysclk_init(struct device_node
*node)
u32 rate;
if (!np) {
- pr_err(ppc-clk: could not get parent node\n);
+ pr_err(qoriq-clk: could not get parent node\n);
return;
}
@@ -278,30 +278,35 @@ static const struct of_device_id clk_match[]
__initconst = {
{}
};
-static int __init ppc_corenet_clk_probe(struct platform_device *pdev)
+static int __init qoriq_clk_probe(struct platform_device *pdev)
{
of_clk_init(clk_match);
return 0;
}
-static const struct of_device_id ppc_clk_ids[] __initconst = {
+static const struct of_device_id qoriq_clk_ids[] __initconst = {
{ .compatible = fsl,qoriq-clockgen-1.0, },
{ .compatible = fsl,qoriq-clockgen-2.0, },
{}
};
-static struct platform_driver ppc_corenet_clk_driver __initdata = {
+static struct platform_driver qoriq_clk_driver __initdata = {
.driver = {
- .name = ppc_corenet_clock,
+ .name = qoriq_clock,
.owner = THIS_MODULE,
- .of_match_table = ppc_clk_ids,
+ .of_match_table = qoriq_clk_ids,
},
- .probe = ppc_corenet_clk_probe,
+ .probe = qoriq_clk_probe,
};
-static int __init ppc_corenet_clk_init(void)
+static int __init qoriq_clk_init(void)
{
- return platform_driver_register(ppc_corenet_clk_driver);
+ return platform_driver_register(qoriq_clk_driver);
}
-subsys_initcall(ppc_corenet_clk_init);
+subsys_initcall(qoriq_clk_init);
+
+CLK_OF_DECLARE(qoriq_core_pll_v1, fsl,qoriq-core-pll-1.0,
+core_pll_init);
Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
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? Thanks, tglx ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
Hi Jingchang, On 09/23/2014 09:46 AM, Jingchang Lu wrote: The IP is shared by PPC and ARM, this renames it to qoriq for better represention, and this also adds the CLK_OF_DECLARE support for being initialized by of_clk_init() on ARM. I think you need to also update drivers/cpufreq/Kconfig.powerpc to use the renamed config option. --- Best Regards, Laurentiu ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote: This series is based Bjorn's pci/msi branch git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi Is there a git tree for these patches? Currently, there are a lot of weak arch functions in MSI code. Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm. This series use MSI chip framework to refactor MSI code across all platforms to eliminate weak arch functions. Then all MSI irqs will be managed in a unified framework. Because this series changed a lot of ARCH MSI code, so tests in the platforms which MSI code modified are warmly welcomed! v1-v2: Add a patch to make s390 MSI code build happy between patch x86/xen/MSI: E.. and s390/MSI: Use MSI... Fix several typo problems found by Lucas. RFC-v1: Updated [patch 4/21] x86/xen/MSI: Eliminate..., export msi_chip instead of #ifdef to fix MSI bug in xen running in x86. Rename arch_get_match_msi_chip() to arch_find_msi_chip(). Drop use struct device as the msi_chip argument, we will do that later in another patchset. Yijing Wang (22): PCI/MSI: Clean up struct msi_chip argument PCI/MSI: Remove useless bus-msi assignment MSI: Remove the redundant irq_set_chip_data() x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq() s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq() PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip PCI/MSI: Refactor struct msi_chip to make it become more common x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq x86/MSI: Remove unused MSI weak arch functions MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq MIPS/Xlp: Remove the dead function destroy_irq() to fix build error MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq PCI/MSI: Clean up unused MSI arch functions arch/arm/mach-iop13xx/include/mach/pci.h |2 + arch/arm/mach-iop13xx/iq81340mc.c|1 + arch/arm/mach-iop13xx/iq81340sc.c|1 + arch/arm/mach-iop13xx/msi.c |9 ++- arch/arm/mach-iop13xx/pci.c |6 ++ arch/ia64/kernel/msi_ia64.c | 18 - arch/mips/pci/msi-octeon.c | 35 ++ arch/mips/pci/msi-xlp.c | 18 -- arch/mips/pci/pci-xlr.c | 15 - arch/powerpc/kernel/msi.c| 14 +++- arch/s390/pci/pci.c | 18 - arch/sparc/kernel/pci.c | 14 +++- arch/tile/kernel/pci_gx.c| 14 +++- arch/x86/include/asm/apic.h |4 + arch/x86/include/asm/pci.h |4 +- arch/x86/include/asm/x86_init.h |7 -- arch/x86/kernel/apic/io_apic.c | 16 - arch/x86/kernel/x86_init.c | 34 - arch/x86/pci/xen.c | 60 +--- drivers/iommu/irq_remapping.c|9 ++- drivers/irqchip/irq-armada-370-xp.c |8 +-- drivers/pci/host/pci-tegra.c |8 ++- drivers/pci/host/pcie-designware.c |4 +- drivers/pci/host/pcie-rcar.c |8 ++- drivers/pci/msi.c| 114 ++ drivers/pci/probe.c |1 - include/linux/msi.h | 26 ++- 27 files changed, 266 insertions(+), 202 deletions(-) ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 04/22] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
On Thu, Sep 25, 2014 at 11:14:14AM +0800, Yijing Wang wrote:
Commit 0e4ccb150 added two __weak arch functions arch_msix_mask_irq()
and arch_msi_mask_irq() to fix a bug found when running xen in x86.
Introduced these two funcntions make MSI code complex. And mask/unmask
These two functions made the MSI code more complex.
is the irq actions related to interrupt controller, should not use
weak arch functions to override mask/unmask interfaces. This patch
I am bit baffled of what you are saying.
reverted commit 0e4ccb150 and export struct irq_chip msi_chip, modify
msi_chip-irq_mask/irq_unmask() in xen init functions to fix this
bug for simplicity. Also this is preparation for using struct
msi_chip instead of weak arch MSI functions in all platforms.
Keep default_msi_mask_irq() and default_msix_mask_irq() in
linux/msi.h to make s390 MSI code compile happy, they wiil be removed
s/wiil/will.
in the later patch.
Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
I don't even remember testing it - I guess I did the earlier version.
So a couple of questions since I've totally forgotten about this:
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 50f67a3..5f8f3af 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -162,7 +162,7 @@ static inline __attribute_const__ u32 msi_mask(unsigned x)
* reliably as devices without an INTx disable bit will then generate a
* level IRQ which will never be cleared.
*/
-u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
+u32 __msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
{
u32 mask_bits = desc-masked;
@@ -176,14 +176,9 @@ u32 default_msi_mask_irq(struct msi_desc *desc, u32
mask, u32 flag)
return mask_bits;
}
-__weak u32 arch_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
-{
- return default_msi_mask_irq(desc, mask, flag);
-}
-
static void msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag)
{
- desc-masked = arch_msi_mask_irq(desc, mask, flag);
+ desc-masked = __msi_mask_irq(desc, mask, flag);
}
/*
@@ -193,7 +188,7 @@ static void msi_mask_irq(struct msi_desc *desc, u32 mask,
u32 flag)
* file. This saves a few milliseconds when initialising devices with lots
* of MSI-X interrupts.
*/
-u32 default_msix_mask_irq(struct msi_desc *desc, u32 flag)
+u32 __msix_mask_irq(struct msi_desc *desc, u32 flag)
{
u32 mask_bits = desc-masked;
unsigned offset = desc-msi_attrib.entry_nr * PCI_MSIX_ENTRY_SIZE +
@@ -206,14 +201,9 @@ u32 default_msix_mask_irq(struct msi_desc *desc, u32
flag)
return mask_bits;
}
-__weak u32 arch_msix_mask_irq(struct msi_desc *desc, u32 flag)
-{
- return default_msix_mask_irq(desc, flag);
-}
-
static void msix_mask_irq(struct msi_desc *desc, u32 flag)
{
- desc-masked = arch_msix_mask_irq(desc, flag);
+ desc-masked = __msix_mask_irq(desc, flag);
}
static void msi_set_mask_bit(struct irq_data *data, u32 flag)
@@ -852,7 +842,7 @@ void pci_msi_shutdown(struct pci_dev *dev)
/* Return the device with MSI unmasked as initial states */
mask = msi_mask(desc-msi_attrib.multi_cap);
/* Keep cached state to be restored */
- arch_msi_mask_irq(desc, mask, ~mask);
+ __msi_mask_irq(desc, mask, ~mask);
If I am reading this right, it will call the old 'default_msi_mask_irq'
which is exactly what we don't want to do under Xen. We want to call
the NOP code.
/* Restore dev-irq to its default pin-assertion irq */
dev-irq = desc-msi_attrib.default_irq;
@@ -950,7 +940,7 @@ void pci_msix_shutdown(struct pci_dev *dev)
/* Return the device with MSI-X masked as initial states */
list_for_each_entry(entry, dev-msi_list, list) {
/* Keep cached states to be restored */
- arch_msix_mask_irq(entry, 1);
+ __msix_mask_irq(entry, 1);
Ditto here.
Looking more at this code I have to retract my Reviewed-by and Tested-by
on the whole series.
Is it possible to get a git tree for this please?
}
msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 45ef8cb..cc46a62 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -19,6 +19,8 @@ void read_msi_msg(struct msi_desc *entry, struct msi_msg
*msg);
void get_cached_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
void write_msi_msg(unsigned int irq, struct msi_msg *msg);
+u32 __msix_mask_irq(struct msi_desc *desc, u32 flag);
+u32 __msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag);
struct msi_desc {
struct {
@@ -59,8 +61,8 @@ void arch_restore_msi_irqs(struct pci_dev *dev);
void default_teardown_msi_irqs(struct pci_dev *dev);
void default_restore_msi_irqs(struct pci_dev *dev);
-u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32
Re: bit fields data tearing
On Fri 2014-09-05 12:17:16, Peter Hurley wrote:
On 09/05/2014 08:37 AM, David Laight wrote:
From: Peter Hurley
On 09/05/2014 04:30 AM, David Laight wrote:
I've seen gcc generate 32bit accesses for 16bit structure members on arm.
It does this because of the more limited range of the offsets for the
16bit access.
OTOH I don't know if it ever did this for writes - so it may be moot.
Can you recall the particulars, like what ARM config or what code?
I tried an overly-simple test to see if gcc would bump up to the word load
for
the 12-bit offset mode, but it stuck with register offset rather than
immediate
offset. [I used the compiler options for allmodconfig and a 4.8
cross-compiler.]
Maybe the test doesn't generate enough register pressure on the compiler?
Dunno, I would have been using a much older version of the compiler.
It is possible that it doesn't do it any more.
It might only have done it for loads.
The compiler used to use misaligned 32bit loads for structure
members on large 4n+2 byte boundaries as well.
I'm pretty sure it doesn't do that either.
There have been a lot of compiler versions since I was compiling
anything for arm.
Yeah, it seems gcc for ARM no longer uses the larger operand size as a
substitute for 12-bit immediate offset addressing mode, even for reads.
While this test:
struct x {
short b[12];
};
short load_b(struct x *p) {
return p-b[8];
}
generates the 8-bit immediate offset form,
short load_b(struct x *p) {
0: e1d001f0ldrsh r0, [r0, #16]
4: e12fff1ebx lr
pushing the offset out past 256:
struct x {
long unused[64];
short b[12];
};
short load_b(struct x *p) {
return p-b[8];
}
generates the register offset addressing mode instead of 12-bit immediate:
short load_b(struct x *p) {
0: e3a03e11mov r3, #272; 0x110
4: e19000f3ldrsh r0, [r0, r3]
8: e12fff1ebx lr
If we rely on new gcc features for correctness, does minimum compiler version
need to be updated?
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote: On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote: On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote: This series is based Bjorn's pci/msi branch git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi Currently, there are a lot of weak arch functions in MSI code. Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm. This series use MSI chip framework to refactor MSI code across all platforms to eliminate weak arch functions. Then all MSI irqs will be managed in a unified framework. Because this series changed a lot of ARCH MSI code, so tests in the platforms which MSI code modified are warmly welcomed! Apart from the comments to the individual patches I very much like where this is going. Thanks for taking care of this. Thierry I am actually in disagreement with you, Thierry. I don't like the general direction of the patches, or at least I don't like the fact that we don't have a portable way of setting up the msi_chip without having to rely on weak architectural hooks. Oh, good. That's actually one of the things I said I wasn't happy with either. =) I'm surprised no one considers the case of a platform having more than one host bridge and possibly more than one MSI unit. With the current proposed patchset I can't see how that would work. The PCI core can already deal with that. An MSI chip can be set per bus and the weak pcibios_add_bus() can be used to set that. Often it might not even be necessary to do it via pcibios_add_bus() if you create the root bus directly, since you can attach the MSI chip at that time. 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. 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 pgpgSobAjxC8D.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
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.
-Scott
On Thu, 2014-09-25 at 04:47 -0500, Lu Jingchang-B35083 wrote:
Hi, Scott and Mike,
Could you please help review this patch and give an ACK if ok. Thanks.
Best Regards,
Jingchang
-Original Message-
From: Jingchang Lu [mailto:jingchang...@freescale.com]
Sent: Tuesday, September 23, 2014 2:47 PM
To: mturque...@linaro.org
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; linux-
ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Lu
Jingchang-B35083
Subject: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add
CLK_OF_DECLARE support
The IP is shared by PPC and ARM, this renames it to qoriq for better
represention, and this also adds the CLK_OF_DECLARE support for being
initialized by of_clk_init() on ARM.
Signed-off-by: Jingchang Lu jingchang...@freescale.com
---
changes in v4:
remove corenet literals omitted in v3 remove.
changes in v3:
generate the patch with -M -C option
changes in v2:
rename the driver name to ppc-qoriq.c for shared on PPC and ARM.
drivers/clk/Kconfig| 9 +
drivers/clk/Makefile | 2 +-
drivers/clk/{clk-ppc-corenet.c = clk-qoriq.c} | 27 +++--
-
3 files changed, 22 insertions(+), 16 deletions(-) rename
drivers/clk/{clk-ppc-corenet.c = clk-qoriq.c} (89%)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
85131ae..f5f76cb 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -92,12 +92,13 @@ config COMMON_CLK_AXI_CLKGEN
Support for the Analog Devices axi-clkgen pcore clock generator
for Xilinx
FPGAs. It is commonly used in Analog Devices' reference designs.
-config CLK_PPC_CORENET
-bool Clock driver for PowerPC corenet platforms
-depends on PPC_E500MC OF
+config CLK_QORIQ
+bool Clock driver for PowerPC corenet and compatible ARM-based
platforms
+depends on (PPC_E500MC || ARM) OF
---help---
This adds the clock driver support for Freescale PowerPC corenet
- platforms using common clock framework.
+ platforms and compatible Freescale ARM based platforms using
common
+ clock framework.
config COMMON_CLK_XGENE
bool Clock driver for APM XGene SoC
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
27c542b..20f42e9 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -29,7 +29,7 @@ obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
obj-$(CONFIG_COMMON_CLK_PALMAS) += clk-palmas.o
-obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+obj-$(CONFIG_CLK_QORIQ) += clk-qoriq.o
obj-$(CONFIG_COMMON_CLK_S2MPS11)+= clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-qoriq.c
similarity index 89% rename from drivers/clk/clk-ppc-corenet.c rename to
drivers/clk/clk-qoriq.c index 8e58edf..cba8abe 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-qoriq.c
@@ -155,7 +155,7 @@ static void __init core_pll_init(struct device_node
*np)
base = of_iomap(np, 0);
if (!base) {
-pr_err(clk-ppc: iomap error\n);
+pr_err(clk-qoriq: iomap error\n);
return;
}
@@ -252,7 +252,7 @@ static void __init sysclk_init(struct device_node
*node)
u32 rate;
if (!np) {
-pr_err(ppc-clk: could not get parent node\n);
+pr_err(qoriq-clk: could not get parent node\n);
return;
}
@@ -278,30 +278,35 @@ static const struct of_device_id clk_match[]
__initconst = {
{}
};
-static int __init ppc_corenet_clk_probe(struct platform_device *pdev)
+static int __init qoriq_clk_probe(struct platform_device *pdev)
{
of_clk_init(clk_match);
return 0;
}
-static const struct of_device_id ppc_clk_ids[] __initconst = {
+static const struct of_device_id qoriq_clk_ids[] __initconst = {
{ .compatible = fsl,qoriq-clockgen-1.0, },
{ .compatible = fsl,qoriq-clockgen-2.0, },
{}
};
-static struct platform_driver ppc_corenet_clk_driver __initdata = {
+static struct platform_driver qoriq_clk_driver __initdata = {
.driver = {
-.name = ppc_corenet_clock,
+.name = qoriq_clock,
.owner = THIS_MODULE,
-.of_match_table = ppc_clk_ids,
+.of_match_table = qoriq_clk_ids,
},
-.probe = ppc_corenet_clk_probe,
+.probe = qoriq_clk_probe,
};
-static int __init ppc_corenet_clk_init(void)
+static int __init qoriq_clk_init(void)
{
-return
Re: [PATCH 2/3] qe_common: add qe common functions to qe_common.c
On Thu, 2014-09-25 at 10:47 +0800, Zhao Qiang wrote: qe need to call some common functions, move them into public directory, add a new file drivers/soc/qe/qe_common.c for them. Signed-off-by: Zhao Qiang b45...@freescale.com --- drivers/soc/qe/Makefile| 2 +- drivers/soc/qe/qe_common.c | 185 + include/linux/fsl/qe.h | 52 +++-- 3 files changed, 230 insertions(+), 9 deletions(-) create mode 100644 drivers/soc/qe/qe_common.c I see code being copied, not moved. Where is patch 1/3? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
Quoting Jingchang Lu (2014-09-22 23:46:46)
The IP is shared by PPC and ARM, this renames it to qoriq for better
represention, and this also adds the CLK_OF_DECLARE support for being
initialized by of_clk_init() on ARM.
Signed-off-by: Jingchang Lu jingchang...@freescale.com
---
changes in v4:
remove corenet literals omitted in v3 remove.
changes in v3:
generate the patch with -M -C option
changes in v2:
rename the driver name to ppc-qoriq.c for shared on PPC and ARM.
drivers/clk/Kconfig| 9 +
drivers/clk/Makefile | 2 +-
drivers/clk/{clk-ppc-corenet.c = clk-qoriq.c} | 27
+++---
3 files changed, 22 insertions(+), 16 deletions(-)
rename drivers/clk/{clk-ppc-corenet.c = clk-qoriq.c} (89%)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 85131ae..f5f76cb 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -92,12 +92,13 @@ config COMMON_CLK_AXI_CLKGEN
Support for the Analog Devices axi-clkgen pcore clock generator for
Xilinx
FPGAs. It is commonly used in Analog Devices' reference designs.
-config CLK_PPC_CORENET
- bool Clock driver for PowerPC corenet platforms
- depends on PPC_E500MC OF
+config CLK_QORIQ
+ bool Clock driver for PowerPC corenet and compatible ARM-based
platforms
+ depends on (PPC_E500MC || ARM) OF
---help---
This adds the clock driver support for Freescale PowerPC corenet
- platforms using common clock framework.
+ platforms and compatible Freescale ARM based platforms using common
+ clock framework.
config COMMON_CLK_XGENE
bool Clock driver for APM XGene SoC
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 27c542b..20f42e9 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -29,7 +29,7 @@ obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
obj-$(CONFIG_COMMON_CLK_PALMAS)+= clk-palmas.o
-obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+obj-$(CONFIG_CLK_QORIQ)+= clk-qoriq.o
obj-$(CONFIG_COMMON_CLK_S2MPS11) += clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351)+= clk-si5351.o
obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-qoriq.c
similarity index 89%
rename from drivers/clk/clk-ppc-corenet.c
rename to drivers/clk/clk-qoriq.c
index 8e58edf..cba8abe 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-qoriq.c
@@ -155,7 +155,7 @@ static void __init core_pll_init(struct device_node *np)
base = of_iomap(np, 0);
if (!base) {
- pr_err(clk-ppc: iomap error\n);
+ pr_err(clk-qoriq: iomap error\n);
return;
}
@@ -252,7 +252,7 @@ static void __init sysclk_init(struct device_node *node)
u32 rate;
if (!np) {
- pr_err(ppc-clk: could not get parent node\n);
+ pr_err(qoriq-clk: could not get parent node\n);
return;
}
@@ -278,30 +278,35 @@ static const struct of_device_id clk_match[]
__initconst = {
{}
};
-static int __init ppc_corenet_clk_probe(struct platform_device *pdev)
+static int __init qoriq_clk_probe(struct platform_device *pdev)
{
of_clk_init(clk_match);
return 0;
}
-static const struct of_device_id ppc_clk_ids[] __initconst = {
+static const struct of_device_id qoriq_clk_ids[] __initconst = {
{ .compatible = fsl,qoriq-clockgen-1.0, },
{ .compatible = fsl,qoriq-clockgen-2.0, },
{}
};
-static struct platform_driver ppc_corenet_clk_driver __initdata = {
+static struct platform_driver qoriq_clk_driver __initdata = {
.driver = {
- .name = ppc_corenet_clock,
+ .name = qoriq_clock,
.owner = THIS_MODULE,
- .of_match_table = ppc_clk_ids,
+ .of_match_table = qoriq_clk_ids,
},
- .probe = ppc_corenet_clk_probe,
+ .probe = qoriq_clk_probe,
};
-static int __init ppc_corenet_clk_init(void)
+static int __init qoriq_clk_init(void)
{
- return platform_driver_register(ppc_corenet_clk_driver);
+ return platform_driver_register(qoriq_clk_driver);
}
-subsys_initcall(ppc_corenet_clk_init);
+subsys_initcall(qoriq_clk_init);
+
+CLK_OF_DECLARE(qoriq_core_pll_v1, fsl,qoriq-core-pll-1.0, core_pll_init);
+CLK_OF_DECLARE(qoriq_core_pll_v2, fsl,qoriq-core-pll-2.0, core_pll_init);
+CLK_OF_DECLARE(qoriq_core_mux_v1, fsl,qoriq-core-mux-1.0, core_mux_init);
+CLK_OF_DECLARE(qoriq_core_mux_v2, fsl,qoriq-core-mux-2.0, core_mux_init);
Is there binding documentation for these compatibles?
Re: [PATCH v2] powerpc/powernv: Override dma_get_required_mask()
On Thu, 2014-09-25 at 17:24 +1000, Gavin Shan wrote:
When using bypass window on IODA2, the incorrect DMA operations
dma_iommu_ops is used by devices. The device driver calls
dma_get_required_mask() to determine using 32-bits or 64-bits
bypass DMA window. Unfortunately, the returned DMA mask always
forces the driver to use 32-bits DMA window. The problem was
reported on the device as follows:
I would write the above comment a bit differently:
The dma_get_required_mask() function is used by some drivers to
query the platform about what DMA mask is needed to cover all of memory.
This is a bit of a strange semantic when we have to chose between iommu
translation or bypass, but essentially what it means is what DMA mask
will give best performances.
Currently, our iommu backend always returns a 32-bit mask here, we don't
do anything special to it when we have bypass available. This causes
some drivers to chose a 32-bit mask, thus losing the ability to use the
bypass window, thinking this is more efficient.
This patch adds an override of that function in order to, instead,
return a 64-bit mask whenever a bypass window is available in order for
drivers to prefer this configuration.
... or something along those lines.
0004:03:00.0 0107: 1000:0087 (rev 05)
0004:03:00.0 Serial Attached SCSI controller: LSI Logic / Symbios \
Logic SAS2308 PCI-Express Fusion-MPT SAS-2 (rev 05)
The patch fixes above issue by overriding dma_get_required_mask(),
which returns mask corresponding to bypass window base. Otherwise,
dma_iommu_ops::get_required_mask will be called to return mask
corresponding to 32-bits DMA window.
Reported-by: Murali N. Iyer mni...@us.ibm.com
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/dma-mapping.h| 1 +
arch/powerpc/kernel/dma.c | 14 ++
arch/powerpc/platforms/powernv/pci-ioda.c | 23 +++
arch/powerpc/platforms/powernv/pci.c | 11 +++
arch/powerpc/platforms/powernv/pci.h | 2 ++
arch/powerpc/platforms/powernv/powernv.h | 6 ++
arch/powerpc/platforms/powernv/setup.c| 9 +
7 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 150866b..894d538 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -135,6 +135,7 @@ static inline int dma_supported(struct device *dev, u64
mask)
extern int dma_set_mask(struct device *dev, u64 dma_mask);
extern int __dma_set_mask(struct device *dev, u64 dma_mask);
+extern u64 __dma_get_required_mask(struct device *dev);
#define dma_alloc_coherent(d,s,h,f) dma_alloc_attrs(d,s,h,f,NULL)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index ee78f6e..210ff9d 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -202,6 +202,7 @@ int __dma_set_mask(struct device *dev, u64 dma_mask)
*dev-dma_mask = dma_mask;
return 0;
}
+
int dma_set_mask(struct device *dev, u64 dma_mask)
{
if (ppc_md.dma_set_mask)
@@ -210,13 +211,10 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
}
EXPORT_SYMBOL(dma_set_mask);
-u64 dma_get_required_mask(struct device *dev)
+u64 __dma_get_required_mask(struct device *dev)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
- if (ppc_md.dma_get_required_mask)
- return ppc_md.dma_get_required_mask(dev);
-
if (unlikely(dma_ops == NULL))
return 0;
@@ -225,6 +223,14 @@ u64 dma_get_required_mask(struct device *dev)
return DMA_BIT_MASK(8 * sizeof(dma_addr_t));
}
+
+u64 dma_get_required_mask(struct device *dev)
+{
+ if (ppc_md.dma_get_required_mask)
+ return ppc_md.dma_get_required_mask(dev);
+
+ return __dma_get_required_mask(dev);
+}
EXPORT_SYMBOL_GPL(dma_get_required_mask);
static int __init dma_init(void)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 36b1a7a..380ebc9 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -890,6 +890,28 @@ static int pnv_pci_ioda_dma_set_mask(struct pnv_phb *phb,
return 0;
}
+static u64 pnv_pci_ioda_dma_get_required_mask(struct pnv_phb *phb,
+ struct pci_dev *pdev)
+{
+ struct pci_dn *pdn = pci_get_pdn(pdev);
+ struct pnv_ioda_pe *pe;
+ u64 end, mask;
+
+ if (WARN_ON(!pdn || pdn-pe_number == IODA_INVALID_PE))
+ return 0;
+
+ pe = phb-ioda.pe_array[pdn-pe_number];
+ if (!pe-tce_bypass_enabled)
+ return __dma_get_required_mask(pdev-dev);
+
+
+ end = pe-tce_bypass_base + memblock_end_of_DRAM();
+ mask = 1ULL (fls64(end) - 1);
+ mask += mask - 1;
+
+ return mask;
+}
+
Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
On Thu, 2014-09-25 at 14:39 -0700, Mike Turquette wrote: Quoting Jingchang Lu (2014-09-22 23:46:46) +CLK_OF_DECLARE(qoriq_core_pll_v1, fsl,qoriq-core-pll-1.0, core_pll_init); +CLK_OF_DECLARE(qoriq_core_pll_v2, fsl,qoriq-core-pll-2.0, core_pll_init); +CLK_OF_DECLARE(qoriq_core_mux_v1, fsl,qoriq-core-mux-1.0, core_mux_init); +CLK_OF_DECLARE(qoriq_core_mux_v2, fsl,qoriq-core-mux-2.0, core_mux_init); Is there binding documentation for these compatibles? Documentation/devicetree/bindings/clock/qoriq-clock.txt -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote: On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote: This series is based Bjorn's pci/msi branch git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi Currently, there are a lot of weak arch functions in MSI code. Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm. This series use MSI chip framework to refactor MSI code across all platforms to eliminate weak arch functions. Then all MSI irqs will be managed in a unified framework. Because this series changed a lot of ARCH MSI code, so tests in the platforms which MSI code modified are warmly welcomed! Apart from the comments to the individual patches I very much like where this is going. Thanks for taking care of this. Thierry I am actually in disagreement with you, Thierry. I don't like the general direction of the patches, or at least I don't like the fact that we don't have a portable way of setting up the msi_chip without having to rely on weak architectural hooks. I'm surprised no one considers the case of a platform having more than one host bridge and possibly more than one MSI unit. With the current proposed patchset I can't see how that would work. 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. Best regards, Liviu - .oooO ( ) \ ( Oooo. \_) ( ) ) / (_/ One small step for me ... ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
On Thu, Sep 25, 2014 at 06:49:38PM +0200, Thierry Reding wrote: On Thu, Sep 25, 2014 at 03:48:55PM +0100, Liviu Dudau wrote: On Thu, Sep 25, 2014 at 09:42:36AM +0200, Thierry Reding wrote: On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote: This series is based Bjorn's pci/msi branch git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi Currently, there are a lot of weak arch functions in MSI code. Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm. This series use MSI chip framework to refactor MSI code across all platforms to eliminate weak arch functions. Then all MSI irqs will be managed in a unified framework. Because this series changed a lot of ARCH MSI code, so tests in the platforms which MSI code modified are warmly welcomed! Apart from the comments to the individual patches I very much like where this is going. Thanks for taking care of this. Thierry I am actually in disagreement with you, Thierry. I don't like the general direction of the patches, or at least I don't like the fact that we don't have a portable way of setting up the msi_chip without having to rely on weak architectural hooks. Oh, good. That's actually one of the things I said I wasn't happy with either. =) I'm surprised no one considers the case of a platform having more than one host bridge and possibly more than one MSI unit. With the current proposed patchset I can't see how that would work. The PCI core can already deal with that. An MSI chip can be set per bus and the weak pcibios_add_bus() can be used to set that. Often it might not even be necessary to do it via pcibios_add_bus() if you create the root bus directly, since you can attach the MSI chip at that time. But I'm thinking that we need to move away from pcibios_add_bus() interface to do something that should be generic. You don't need to be called for every bus when all you want is just the root bus in order to add the MSI chip. Also, from looking at the current patchset, a lot of architectures would set the MSI chip to a global variable, which means you don't have an option to choose the MSI chip based on the bus. 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. 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. Breaking out the host bridge creation from root bus creation is not difficult, just not agree upon. That would be the first step in making the generic host brige structure useful for sharing, specially if used as a sort of parent structure that you can wrap with your actual host bridge structure. But like I said, when you create the root bus, you can easily attach the MSI chip to it. Not if you want to use the generic pci_scan_root_bus() function. One needs to copy the code and add their own needed modifications. Which makes it hard to fix bugs and prevents code reuse. Best regards, Liviu Thierry -- --- .oooO ( ) \ ( Oooo. \_) ( ) ) / (_/ One small step for me ... ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 1/3] drivers/of: add of_changeset_apply_locked
On 09/24/2014 11:41 PM, Cyril Bur wrote:
Due to the requirement of of_changesets that of_changeset_apply be called
holding the of_mutex and that the of_mutex cannot be accessed nicely outside
the of code, added a wrapper which grabs the lock and called
of_changeset_apply.
Signed-off-by: Cyril Bur cyril@au1.ibm.com
---
drivers/of/dynamic.c | 11 +++
include/linux/of.h | 1 +
2 files changed, 12 insertions(+)
This patch needs to go through Grant Likely and the device tree list.
When unsure scripts/get_maintainer.pl can help point the way.
-Tyrel
diff --git a/drivers/of/dynamic.c b/drivers/of/dynamic.c
index 54fecc4..cbff2a2 100644
--- a/drivers/of/dynamic.c
+++ b/drivers/of/dynamic.c
@@ -542,6 +542,17 @@ void of_changeset_destroy(struct of_changeset *ocs)
__of_changeset_entry_destroy(ce);
}
+int of_changeset_apply_locked(struct of_changeset *ocs)
+{
+ int ret;
+
+ mutex_lock(of_mutex);
+ ret = of_changeset_apply(ocs);
+ mutex_unlock(of_mutex);
+
+ return ret;
+}
+
/**
* of_changeset_apply - Applies a changeset
*
diff --git a/include/linux/of.h b/include/linux/of.h
index 6c4363b..f5c48fa 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -827,6 +827,7 @@ struct of_changeset {
extern void of_changeset_init(struct of_changeset *ocs);
extern void of_changeset_destroy(struct of_changeset *ocs);
extern int of_changeset_apply(struct of_changeset *ocs);
+extern int of_changeset_apply_locked(struct of_changeset *ocs);
extern int of_changeset_revert(struct of_changeset *ocs);
extern int of_changeset_action(struct of_changeset *ocs,
unsigned long action, struct device_node *np,
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/3] powerpc/pseries: create rtas buffer accessor
On 09/24/2014 11:41 PM, Cyril Bur wrote:
Added simple accessor functions for rtas in memory buffers which performs
accesses of appropriate type and performs endian conversions.
Signed-off-by: Cyril Bur cyril@au1.ibm.com
---
arch/powerpc/platforms/pseries/Makefile | 4 +-
arch/powerpc/platforms/pseries/pseries.h | 41 +
arch/powerpc/platforms/pseries/rtas_buffer.c | 126
+++
3 files changed, 170 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/pseries/rtas_buffer.c
Maybe Michael has an opinion here, but seems to me since this is all
RTAS related it would make sense for this code to belong in
kernel/rtas.c and include/asm/rtas.h.
-Tyrel
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 0348079..7eb7c46 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -3,7 +3,9 @@ ccflags-$(CONFIG_PPC_PSERIES_DEBUG) += -DDEBUG
obj-y:= lpar.o hvCall.o nvram.o reconfig.o \
setup.o iommu.o event_sources.o ras.o \
-firmware.o power.o dlpar.o mobility.o rng.o
+firmware.o power.o dlpar.o mobility.o \
+rng.o rtas_buffer.o
+
obj-$(CONFIG_SMP)+= smp.o
obj-$(CONFIG_SCANLOG)+= scanlog.o
obj-$(CONFIG_EEH)+= eeh_pseries.o
diff --git a/arch/powerpc/platforms/pseries/pseries.h
b/arch/powerpc/platforms/pseries/pseries.h
index 361add6..f24e352 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -66,4 +66,45 @@ int pseries_root_bridge_prepare(struct pci_host_bridge
*bridge);
unsigned long pseries_memory_block_size(void);
+/* Manipulation of the in memory data returned from an RTAS call */
+
+/* Data pointed to by ptr is in big endian */
+struct rtas_buffer {
+ void *ptr;
+ int len;
+ int pos;
+};
+
+/* Buffer is already zeroed */
+int make_rtas_buf(struct rtas_buffer *b, size_t size);
+void free_rtas_buf(struct rtas_buffer *b);
+
+/* Return pointer to the buffer being used */
+void *get_rtas_buf(struct rtas_buffer *b);
+
+/* Checks if the buffer exists and the read position is less than the
length*/
+bool check_rtas_buf(struct rtas_buffer *b);
+size_t get_rtas_buf_size(struct rtas_buffer *b);
+
+/* Advance the internal position of the buffer by size bytes */
+bool advance_rtas_buf(struct rtas_buffer *b, size_t size);
+
+/* Put a value val into the buffer at position pos. Function expect val in
cpu
+ * endian. Returns true if the write to the buffer was successful.
+ */
+bool put_rtas_buf_32(struct rtas_buffer *b, u32 val, int pos);
+
+/* Grab the byte at the current position of the buffer without incrementing
+ * the internal position of the buffer */
+bool peek_rtas_buf(struct rtas_buffer *b, u8 *c);
+
+/* Accessor functions return true if access succeeded and value is written to
+ * val in cpu endian. Automatically advances its reference into the buffer by
+ * the requested amount.
+ */
+bool get_rtas_buf_32(struct rtas_buffer *b, u32 *val);
+bool get_rtas_buf_64(struct rtas_buffer *b, u64 *val);
+bool get_rtas_buf_mem(struct rtas_buffer *b, void **p, size_t len);
+bool get_rtas_buf_str(struct rtas_buffer *b, char **s);
+
#endif /* _PSERIES_PSERIES_H */
diff --git a/arch/powerpc/platforms/pseries/rtas_buffer.c
b/arch/powerpc/platforms/pseries/rtas_buffer.c
new file mode 100644
index 000..f06b73c
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/rtas_buffer.c
@@ -0,0 +1,126 @@
+#include linux/kernel.h
+#include linux/slab.h
+
+#include pseries.h
+
+
+int make_rtas_buf(struct rtas_buffer *b, size_t sz)
+{
+ b-ptr = kzalloc(sz, GFP_KERNEL);
+ b-len = sz;
+ b-pos = 0;
+ return (!b-ptr) ? -ENOMEM : 0;
+}
+
+void free_rtas_buf(struct rtas_buffer *b)
+{
+ kfree(b-ptr);
+}
+
+void *get_rtas_buf(struct rtas_buffer *b)
+{
+ return (b) ? b-ptr : NULL;
+}
+
+size_t get_rtas_buf_size(struct rtas_buffer *b)
+{
+ return (b) ? b-len : 0;
+}
+
+bool check_rtas_buf(struct rtas_buffer *b)
+{
+ return (b b-ptr b-pos b-len);
+}
+
+static inline void *buf_pos(struct rtas_buffer *b)
+{
+ return (b b-ptr) ? b-ptr + b-pos : NULL;
+}
+
+bool peek_rtas_buf(struct rtas_buffer *b, u8 *c)
+{
+ if (!b || !c || b-pos = b-len)
+ return false;
+
+ *c = *(u8 *)buf_pos(b);
+
+ return true;
+}
+
+bool put_rtas_buf_32(struct rtas_buffer *b, u32 val, int pos)
+{
+ if (!b || b-pos = b-len)
+ return false;
+
+ *((__be32 *)buf_pos(b)) = cpu_to_be32(val);
+
+ return true;
+}
+
+bool get_rtas_buf_32(struct rtas_buffer *b, u32 *val)
+{
+ if (!b || !val || b-len - b-pos sizeof(u32))
+ return false;
+
+ *val =
Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
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).
Regards,
Mike
-Scott
On Thu, 2014-09-25 at 04:47 -0500, Lu Jingchang-B35083 wrote:
Hi, Scott and Mike,
Could you please help review this patch and give an ACK if ok. Thanks.
Best Regards,
Jingchang
-Original Message-
From: Jingchang Lu [mailto:jingchang...@freescale.com]
Sent: Tuesday, September 23, 2014 2:47 PM
To: mturque...@linaro.org
Cc: Wood Scott-B07421; linuxppc-dev@lists.ozlabs.org; linux-
ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; Lu
Jingchang-B35083
Subject: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add
CLK_OF_DECLARE support
The IP is shared by PPC and ARM, this renames it to qoriq for better
represention, and this also adds the CLK_OF_DECLARE support for being
initialized by of_clk_init() on ARM.
Signed-off-by: Jingchang Lu jingchang...@freescale.com
---
changes in v4:
remove corenet literals omitted in v3 remove.
changes in v3:
generate the patch with -M -C option
changes in v2:
rename the driver name to ppc-qoriq.c for shared on PPC and ARM.
drivers/clk/Kconfig| 9 +
drivers/clk/Makefile | 2 +-
drivers/clk/{clk-ppc-corenet.c = clk-qoriq.c} | 27 +++--
-
3 files changed, 22 insertions(+), 16 deletions(-) rename
drivers/clk/{clk-ppc-corenet.c = clk-qoriq.c} (89%)
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig index
85131ae..f5f76cb 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -92,12 +92,13 @@ config COMMON_CLK_AXI_CLKGEN
Support for the Analog Devices axi-clkgen pcore clock generator
for Xilinx
FPGAs. It is commonly used in Analog Devices' reference designs.
-config CLK_PPC_CORENET
-bool Clock driver for PowerPC corenet platforms
-depends on PPC_E500MC OF
+config CLK_QORIQ
+bool Clock driver for PowerPC corenet and compatible ARM-based
platforms
+depends on (PPC_E500MC || ARM) OF
---help---
This adds the clock driver support for Freescale PowerPC corenet
- platforms using common clock framework.
+ platforms and compatible Freescale ARM based platforms using
common
+ clock framework.
config COMMON_CLK_XGENE
bool Clock driver for APM XGene SoC
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile index
27c542b..20f42e9 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -29,7 +29,7 @@ obj-$(CONFIG_ARCH_MOXART) += clk-moxart.o
obj-$(CONFIG_ARCH_NOMADIK) += clk-nomadik.o
obj-$(CONFIG_ARCH_NSPIRE) += clk-nspire.o
obj-$(CONFIG_COMMON_CLK_PALMAS) += clk-palmas.o
-obj-$(CONFIG_CLK_PPC_CORENET) += clk-ppc-corenet.o
+obj-$(CONFIG_CLK_QORIQ) += clk-qoriq.o
obj-$(CONFIG_COMMON_CLK_S2MPS11)+= clk-s2mps11.o
obj-$(CONFIG_COMMON_CLK_SI5351) += clk-si5351.o
obj-$(CONFIG_COMMON_CLK_SI570) += clk-si570.o
diff --git a/drivers/clk/clk-ppc-corenet.c b/drivers/clk/clk-qoriq.c
similarity index 89% rename from drivers/clk/clk-ppc-corenet.c rename to
drivers/clk/clk-qoriq.c index 8e58edf..cba8abe 100644
--- a/drivers/clk/clk-ppc-corenet.c
+++ b/drivers/clk/clk-qoriq.c
@@ -155,7 +155,7 @@ static void __init core_pll_init(struct device_node
*np)
base = of_iomap(np, 0);
if (!base) {
-pr_err(clk-ppc: iomap error\n);
+pr_err(clk-qoriq: iomap error\n);
return;
}
@@ -252,7 +252,7 @@ static void __init sysclk_init(struct device_node
*node)
u32 rate;
if (!np) {
-pr_err(ppc-clk: could not get parent node\n);
+pr_err(qoriq-clk: could not get parent node\n);
return;
}
@@ -278,30 +278,35 @@ static const struct of_device_id clk_match[]
__initconst = {
{}
};
-static int __init ppc_corenet_clk_probe(struct platform_device *pdev)
+static int __init qoriq_clk_probe(struct platform_device *pdev)
{
of_clk_init(clk_match);
return 0;
}
-static const struct of_device_id ppc_clk_ids[] __initconst = {
+static const struct of_device_id qoriq_clk_ids[] __initconst = {
{ .compatible = fsl,qoriq-clockgen-1.0, },
{ .compatible = fsl,qoriq-clockgen-2.0, },
{}
};
-static struct platform_driver ppc_corenet_clk_driver __initdata = {
+static struct platform_driver qoriq_clk_driver __initdata = {
.driver = {
-.name = ppc_corenet_clock,
+
Re: [PATCHv4] clk: ppc-corenet: rename to ppc-qoriq and add CLK_OF_DECLARE support
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. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/powernv: Override dma_get_required_mask()
On Fri, Sep 26, 2014 at 07:51:56AM +1000, Benjamin Herrenschmidt wrote:
On Thu, 2014-09-25 at 17:24 +1000, Gavin Shan wrote:
When using bypass window on IODA2, the incorrect DMA operations
dma_iommu_ops is used by devices. The device driver calls
dma_get_required_mask() to determine using 32-bits or 64-bits
bypass DMA window. Unfortunately, the returned DMA mask always
forces the driver to use 32-bits DMA window. The problem was
reported on the device as follows:
I would write the above comment a bit differently:
The dma_get_required_mask() function is used by some drivers to
query the platform about what DMA mask is needed to cover all of memory.
This is a bit of a strange semantic when we have to chose between iommu
translation or bypass, but essentially what it means is what DMA mask
will give best performances.
Currently, our iommu backend always returns a 32-bit mask here, we don't
do anything special to it when we have bypass available. This causes
some drivers to chose a 32-bit mask, thus losing the ability to use the
bypass window, thinking this is more efficient.
This patch adds an override of that function in order to, instead,
return a 64-bit mask whenever a bypass window is available in order for
drivers to prefer this configuration.
... or something along those lines.
Thanks, Ben. I'll fold your comments into next revision.
Thanks,
Gavin
0004:03:00.0 0107: 1000:0087 (rev 05)
0004:03:00.0 Serial Attached SCSI controller: LSI Logic / Symbios \
Logic SAS2308 PCI-Express Fusion-MPT SAS-2 (rev 05)
The patch fixes above issue by overriding dma_get_required_mask(),
which returns mask corresponding to bypass window base. Otherwise,
dma_iommu_ops::get_required_mask will be called to return mask
corresponding to 32-bits DMA window.
Reported-by: Murali N. Iyer mni...@us.ibm.com
Signed-off-by: Gavin Shan gws...@linux.vnet.ibm.com
---
arch/powerpc/include/asm/dma-mapping.h| 1 +
arch/powerpc/kernel/dma.c | 14 ++
arch/powerpc/platforms/powernv/pci-ioda.c | 23 +++
arch/powerpc/platforms/powernv/pci.c | 11 +++
arch/powerpc/platforms/powernv/pci.h | 2 ++
arch/powerpc/platforms/powernv/powernv.h | 6 ++
arch/powerpc/platforms/powernv/setup.c| 9 +
7 files changed, 62 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/dma-mapping.h
b/arch/powerpc/include/asm/dma-mapping.h
index 150866b..894d538 100644
--- a/arch/powerpc/include/asm/dma-mapping.h
+++ b/arch/powerpc/include/asm/dma-mapping.h
@@ -135,6 +135,7 @@ static inline int dma_supported(struct device *dev, u64
mask)
extern int dma_set_mask(struct device *dev, u64 dma_mask);
extern int __dma_set_mask(struct device *dev, u64 dma_mask);
+extern u64 __dma_get_required_mask(struct device *dev);
#define dma_alloc_coherent(d,s,h,f) dma_alloc_attrs(d,s,h,f,NULL)
diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c
index ee78f6e..210ff9d 100644
--- a/arch/powerpc/kernel/dma.c
+++ b/arch/powerpc/kernel/dma.c
@@ -202,6 +202,7 @@ int __dma_set_mask(struct device *dev, u64 dma_mask)
*dev-dma_mask = dma_mask;
return 0;
}
+
int dma_set_mask(struct device *dev, u64 dma_mask)
{
if (ppc_md.dma_set_mask)
@@ -210,13 +211,10 @@ int dma_set_mask(struct device *dev, u64 dma_mask)
}
EXPORT_SYMBOL(dma_set_mask);
-u64 dma_get_required_mask(struct device *dev)
+u64 __dma_get_required_mask(struct device *dev)
{
struct dma_map_ops *dma_ops = get_dma_ops(dev);
-if (ppc_md.dma_get_required_mask)
-return ppc_md.dma_get_required_mask(dev);
-
if (unlikely(dma_ops == NULL))
return 0;
@@ -225,6 +223,14 @@ u64 dma_get_required_mask(struct device *dev)
return DMA_BIT_MASK(8 * sizeof(dma_addr_t));
}
+
+u64 dma_get_required_mask(struct device *dev)
+{
+if (ppc_md.dma_get_required_mask)
+return ppc_md.dma_get_required_mask(dev);
+
+return __dma_get_required_mask(dev);
+}
EXPORT_SYMBOL_GPL(dma_get_required_mask);
static int __init dma_init(void)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 36b1a7a..380ebc9 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -890,6 +890,28 @@ static int pnv_pci_ioda_dma_set_mask(struct pnv_phb
*phb,
return 0;
}
+static u64 pnv_pci_ioda_dma_get_required_mask(struct pnv_phb *phb,
+ struct pci_dev *pdev)
+{
+struct pci_dn *pdn = pci_get_pdn(pdev);
+struct pnv_ioda_pe *pe;
+u64 end, mask;
+
+if (WARN_ON(!pdn || pdn-pe_number == IODA_INVALID_PE))
+return 0;
+
+pe = phb-ioda.pe_array[pdn-pe_number];
+if (!pe-tce_bypass_enabled)
+return __dma_get_required_mask(pdev-dev);
+
+
+end =
Re: [PATCH v3] cpufreq: powernv: Set the cpus to nominal frequency during reboot/kexec
On Thursday, September 11, 2014 05:03:22 PM Viresh Kumar wrote: On 11 September 2014 15:43, Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com wrote: This patch ensures the cpus to kexec/reboot at nominal frequency. Nominal frequency is the highest cpu frequency on PowerPC at which the cores can run without getting throttled. If the host kernel had set the cpus to a low pstate and then it kexecs/reboots to a cpufreq disabled kernel it would cause the target kernel to perform poorly. It will also increase the boot up time of the target kernel. So set the cpus to high pstate, in this case to nominal frequency before rebooting to avoid such scenarios. The reboot notifier will set the cpus to nominal frequncy. Signed-off-by: Shilpasri G Bhat shilpa.b...@linux.vnet.ibm.com Suggested-by: Viresh Kumar viresh.ku...@linaro.org Reviewed-by: Preeti U Murthy pre...@linux.vnet.ibm.com --- Changes v2-v3: We return EBUSY when cpufreq governor tries to change the frequency after rebooting is set to true. This results in console being flushed with error messages indicating failed attempts to change the frequency. So instead of returning EBUSY we return 0 to stop the governor from changing the frequency without alerting a failure to do the same on reboot, as this is not an errorneaos condition. Acked-by: Viresh Kumar viresh.ku...@linaro.org Queued up for 3.18, thanks! -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/3] powerpc/pseries: create rtas buffer accessor
On Thu, 2014-09-25 at 15:47 -0700, Tyrel Datwyler wrote:
On 09/24/2014 11:41 PM, Cyril Bur wrote:
Added simple accessor functions for rtas in memory buffers which performs
accesses of appropriate type and performs endian conversions.
Signed-off-by: Cyril Bur cyril@au1.ibm.com
---
arch/powerpc/platforms/pseries/Makefile | 4 +-
arch/powerpc/platforms/pseries/pseries.h | 41 +
arch/powerpc/platforms/pseries/rtas_buffer.c | 126
+++
3 files changed, 170 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/platforms/pseries/rtas_buffer.c
Maybe Michael has an opinion here, but seems to me since this is all
RTAS related it would make sense for this code to belong in
kernel/rtas.c and include/asm/rtas.h.
Could quite possibly go there, I wanted to get the code looked at first
but I'll take a look if it could be used more generally and if so move.
Thanks
-Tyrel
diff --git a/arch/powerpc/platforms/pseries/Makefile
b/arch/powerpc/platforms/pseries/Makefile
index 0348079..7eb7c46 100644
--- a/arch/powerpc/platforms/pseries/Makefile
+++ b/arch/powerpc/platforms/pseries/Makefile
@@ -3,7 +3,9 @@ ccflags-$(CONFIG_PPC_PSERIES_DEBUG) += -DDEBUG
obj-y := lpar.o hvCall.o nvram.o reconfig.o \
setup.o iommu.o event_sources.o ras.o \
- firmware.o power.o dlpar.o mobility.o rng.o
+ firmware.o power.o dlpar.o mobility.o \
+ rng.o rtas_buffer.o
+
obj-$(CONFIG_SMP) += smp.o
obj-$(CONFIG_SCANLOG) += scanlog.o
obj-$(CONFIG_EEH) += eeh_pseries.o
diff --git a/arch/powerpc/platforms/pseries/pseries.h
b/arch/powerpc/platforms/pseries/pseries.h
index 361add6..f24e352 100644
--- a/arch/powerpc/platforms/pseries/pseries.h
+++ b/arch/powerpc/platforms/pseries/pseries.h
@@ -66,4 +66,45 @@ int pseries_root_bridge_prepare(struct pci_host_bridge
*bridge);
unsigned long pseries_memory_block_size(void);
+/* Manipulation of the in memory data returned from an RTAS call */
+
+/* Data pointed to by ptr is in big endian */
+struct rtas_buffer {
+ void *ptr;
+ int len;
+ int pos;
+};
+
+/* Buffer is already zeroed */
+int make_rtas_buf(struct rtas_buffer *b, size_t size);
+void free_rtas_buf(struct rtas_buffer *b);
+
+/* Return pointer to the buffer being used */
+void *get_rtas_buf(struct rtas_buffer *b);
+
+/* Checks if the buffer exists and the read position is less than the
length*/
+bool check_rtas_buf(struct rtas_buffer *b);
+size_t get_rtas_buf_size(struct rtas_buffer *b);
+
+/* Advance the internal position of the buffer by size bytes */
+bool advance_rtas_buf(struct rtas_buffer *b, size_t size);
+
+/* Put a value val into the buffer at position pos. Function expect val in
cpu
+ * endian. Returns true if the write to the buffer was successful.
+ */
+bool put_rtas_buf_32(struct rtas_buffer *b, u32 val, int pos);
+
+/* Grab the byte at the current position of the buffer without incrementing
+ * the internal position of the buffer */
+bool peek_rtas_buf(struct rtas_buffer *b, u8 *c);
+
+/* Accessor functions return true if access succeeded and value is written
to
+ * val in cpu endian. Automatically advances its reference into the buffer
by
+ * the requested amount.
+ */
+bool get_rtas_buf_32(struct rtas_buffer *b, u32 *val);
+bool get_rtas_buf_64(struct rtas_buffer *b, u64 *val);
+bool get_rtas_buf_mem(struct rtas_buffer *b, void **p, size_t len);
+bool get_rtas_buf_str(struct rtas_buffer *b, char **s);
+
#endif /* _PSERIES_PSERIES_H */
diff --git a/arch/powerpc/platforms/pseries/rtas_buffer.c
b/arch/powerpc/platforms/pseries/rtas_buffer.c
new file mode 100644
index 000..f06b73c
--- /dev/null
+++ b/arch/powerpc/platforms/pseries/rtas_buffer.c
@@ -0,0 +1,126 @@
+#include linux/kernel.h
+#include linux/slab.h
+
+#include pseries.h
+
+
+int make_rtas_buf(struct rtas_buffer *b, size_t sz)
+{
+ b-ptr = kzalloc(sz, GFP_KERNEL);
+ b-len = sz;
+ b-pos = 0;
+ return (!b-ptr) ? -ENOMEM : 0;
+}
+
+void free_rtas_buf(struct rtas_buffer *b)
+{
+ kfree(b-ptr);
+}
+
+void *get_rtas_buf(struct rtas_buffer *b)
+{
+ return (b) ? b-ptr : NULL;
+}
+
+size_t get_rtas_buf_size(struct rtas_buffer *b)
+{
+ return (b) ? b-len : 0;
+}
+
+bool check_rtas_buf(struct rtas_buffer *b)
+{
+ return (b b-ptr b-pos b-len);
+}
+
+static inline void *buf_pos(struct rtas_buffer *b)
+{
+ return (b b-ptr) ? b-ptr + b-pos : NULL;
+}
+
+bool peek_rtas_buf(struct rtas_buffer *b, u8 *c)
+{
+ if (!b || !c || b-pos = b-len)
+ return false;
+
+ *c = *(u8 *)buf_pos(b);
+
+ return true;
+}
+
+bool put_rtas_buf_32(struct rtas_buffer *b, u32 val, int pos)
+{
+ if
Re: [PATCH v2 02/22] PCI/MSI: Remove useless bus-msi assignment
On 2014/9/25 15:06, Thierry Reding wrote: On Thu, Sep 25, 2014 at 11:14:12AM +0800, Yijing Wang wrote: Currently, PCI drivers will initialize bus-msi in pcibios_add_bus(). pcibios_add_bus() will be called in every pci bus initialization. So the bus-msi assignment in pci_alloc_child_bus() is useless. I think this should be the other way around. The default should be to inherit bus-msi from the parent. That way drivers don't typically have to do it, yet they can still opt to override it if they need to. For Tegra for example I think it would work if we assigned the MSI chip to the root bus (in tegra_pcie_scan_bus()) and then have it propagated to child busses in pci_alloc_child_bus() so that tegra_pcie_add_bus() can be removed altogether. Hi Thierry, thanks very much for your review and comments! Because pcibios_add_bus() and child-msi = parent-msi; in pci_alloc_child_bus() do the same thing. So I think we should use one and remove another. I like the latter. In addition, I consider several solutions to associate msi chip and PCI device. 1. Add a msi_chip member in PCI arch sysdata to store the msi_chip pointer. Because all PCI devices under a PCI hostbridge always share the same msi chip, so every PCI device can find the msi chip by pci_bus-sysdata, but in this solution, we also need to add ARCH specific functions to extract msi chip from PCI arch sysdata, like pci_domain_nr(). Then we can remove .add_bus() like tegra_pcie_add_bus() and the msi assignment in pci_alloc_child_bus(). 2. Remove .add_bus() functions, associate PCI root bus and msi chip after PCI root bus created, as you mentioned above. In this solution we need to associate PCI root bus and msi chip in all PCI hostbridge drivers, like in tegra_pcie_scan_bus(). 3. Introduce a global msi chip list, currently, only in arm, there maybe more than one type MSI chip, but in arm, we can find msi chip by PCI hostbridge platform device's of_node, Eg. use msi-parent property to find it. Or msi chip is integrated into PCI hostbridge, we can find msi chip by compare msi_chip-dev and PCI hostbridge's platform device's struct device *dev pointer. And because PCI hostbridge platform device pass to pci_create_root_bus() as the parent device, so every PCI devices can first find the platform device, then to find the msi chip, this solution looks a bit ugly, but we only associate pci hostbridge and msi chip, PCI child buses and devices do not have to know the msi chip details. 4. Last, in this series, introduced weak arch function arch_find_msi_chip(), it's the simplest one, because all platforms except arm, only one msi chip will exist in system. What do you think about this ? Thanks! Yijing. Thierry -- Thanks! Yijing ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 01/22] PCI/MSI: Clean up struct msi_chip argument
On 2014/9/25 15:15, Thierry Reding wrote: On Thu, Sep 25, 2014 at 11:14:11AM +0800, Yijing Wang wrote: Msi_chip functions setup_irq/teardown_irq rarely use msi_chip argument. That's not true. Out of the four drivers that you modify two use the parameter. And the two that don't probably should be using it too. 50% is not rarely. =) We can look up msi_chip pointer by the device pointer or irq number, so clean up msi_chip argument. I don't like this particular change. The idea was to keep the API object oriented so that drivers wouldn't have to know where to get the MSI chip from. It also makes it more resilient against code reorganizations since the core code is the only place that needs to know where to get the chip from. Hm, ok, Thomas also don't like this change, I will drop this one, thanks. Thanks! Yijing. Thierry -- Thanks! Yijing ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 03/22] MSI: Remove the redundant irq_set_chip_data()
On 2014/9/25 15:19, Thierry Reding wrote:
On Thu, Sep 25, 2014 at 11:14:13AM +0800, Yijing Wang wrote:
Currently, pcie-designware, pcie-rcar, pci-tegra drivers
use irq chip_data to save the msi_chip pointer. They
already call irq_set_chip_data() in their own MSI irq map
functions. So irq_set_chip_data() in arch_setup_msi_irq()
is useless.
Again, I think this should be the other way around. If drivers do
something that's already handled by the core, then the duplicate code
should be dropped from the drivers.
Hi Thierry, this is different thing, because chip_data is specific to IRQ
controller, and in other platform, like in x86, chip_data is used to save
irq_cfg.
So we can not call irq_set_chip_data() in core code.
x86 irq piece code
int arch_setup_hwirq(unsigned int irq, int node)
{
struct irq_cfg *cfg;
unsigned long flags;
int ret;
cfg = alloc_irq_cfg(irq, node);
if (!cfg)
return -ENOMEM;
raw_spin_lock_irqsave(vector_lock, flags);
ret = __assign_irq_vector(irq, cfg, apic-target_cpus());
raw_spin_unlock_irqrestore(vector_lock, flags);
if (!ret)
irq_set_chip_data(irq, cfg); -Save irq_cfg
else
free_irq_cfg(irq, cfg);
return ret;
}
Thanks!
Yijing.
Thierry
--
Thanks!
Yijing
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
On 2014/9/25 15:26, Thierry Reding wrote: On Thu, Sep 25, 2014 at 11:14:16AM +0800, 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. Can't x86 simply set the bus' .msi field anyway? It would seem to be easy to do and unifies the code rather than driving it further apart using even more of the __weak functions. As mentioned in the first reply, I will rework this one when we find a better solution. Thanks! Yijing. Thierry -- Thanks! Yijing ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 12/22] MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On 2014/9/25 15:34, Thierry Reding wrote:
On Thu, Sep 25, 2014 at 11:14:22AM +0800, Yijing Wang wrote:
[...]
diff --git a/arch/mips/pci/msi-octeon.c b/arch/mips/pci/msi-octeon.c
[...]
@@ -132,12 +132,12 @@ msi_irq_allocated:
/* Make sure the search for available interrupts didn't fail */
if (irq = 64) {
if (request_private_bits) {
-pr_err(arch_setup_msi_irq: Unable to find %d free
interrupts, trying just one,
+pr_err(octeon_setup_msi_irq: Unable to find %d free
interrupts, trying just one,
1 request_private_bits);
Perhaps while at it make this (and other similar changes in this patch):
pr_err(%s(): Unable to ..., __func__, ...);
Will update it, thanks!
So that it becomes more resilient against this kind of rename?
request_private_bits = 0;
goto try_only_one;
} else
-panic(arch_setup_msi_irq: Unable to find a free MSI
interrupt);
+panic(octeon_setup_msi_irq: Unable to find a free MSI
interrupt);
@@ -210,14 +210,13 @@ int arch_setup_msi_irqs(struct pci_dev *dev, int nvec,
int type)
return 0;
}
-
This...
OK
@@ -240,7 +239,7 @@ void arch_teardown_msi_irq(unsigned int irq)
*/
number_irqs = 0;
while ((irq0 + number_irqs 64)
- (msi_multiple_irq_bitmask[index]
+(msi_multiple_irq_bitmask[index]
... and this seem like unrelated whitespace changes.
OK
(1ull (irq0 + number_irqs
number_irqs++;
number_irqs++;
@@ -249,8 +248,8 @@ void arch_teardown_msi_irq(unsigned int irq)
/* Shift the mask to the correct bit location */
bitmask = irq0;
if ((msi_free_irq_bitmask[index] bitmask) != bitmask)
-panic(arch_teardown_msi_irq: Attempted to teardown MSI
- interrupt (%d) not in use, irq);
+panic(octeon_teardown_msi_irq: Attempted to teardown MSI
+interrupt (%d) not in use, irq);
And the second line here also needlessly changes the indentation.
OK
Thierry
--
Thanks!
Yijing
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 14/22] MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On 2014/9/25 15:36, Thierry Reding wrote:
On Thu, Sep 25, 2014 at 11:14:24AM +0800, Yijing Wang wrote:
Use MSI chip framework instead of arch MSI functions to configure
MSI/MSI-X irq. So we can manage MSI/MSI-X irq in a unified framework.
Nit: s/irq/IRQ/ in the above.
Signed-off-by: Yijing Wang wangyij...@huawei.com
---
arch/mips/pci/msi-xlp.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/mips/pci/msi-xlp.c b/arch/mips/pci/msi-xlp.c
index e469dc7..6b791ef 100644
--- a/arch/mips/pci/msi-xlp.c
+++ b/arch/mips/pci/msi-xlp.c
@@ -245,7 +245,7 @@ static struct irq_chip xlp_msix_chip = {
.irq_unmask = unmask_msi_irq,
};
-void arch_teardown_msi_irq(unsigned int irq)
+void xlp_teardown_msi_irq(unsigned int irq)
Should this not be static now as well?
Yes, Will update.
Thierry
--
Thanks!
Yijing
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 17/22] s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On 2014/9/25 15:38, Thierry Reding wrote: On Thu, Sep 25, 2014 at 11:14:27AM +0800, Yijing Wang wrote: [...] diff --git a/arch/s390/pci/pci.c b/arch/s390/pci/pci.c [...] @@ -358,7 +358,7 @@ static void zpci_irq_handler(struct airq_struct *airq) } } -int arch_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type) +int zpci_setup_msi_irqs(struct pci_dev *pdev, int nvec, int type) static? Yes, Will update. -- Thanks! Yijing ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 01/22] PCI/MSI: Clean up struct msi_chip argument
On 2014/9/25 18:20, Thomas Gleixner wrote: On Thu, 25 Sep 2014, Thierry Reding wrote: On Thu, Sep 25, 2014 at 11:14:11AM +0800, Yijing Wang wrote: Msi_chip functions setup_irq/teardown_irq rarely use msi_chip argument. That's not true. Out of the four drivers that you modify two use the parameter. And the two that don't probably should be using it too. 50% is not rarely. =) We can look up msi_chip pointer by the device pointer or irq number, so clean up msi_chip argument. I don't like this particular change. The idea was to keep the API object oriented so that drivers wouldn't have to know where to get the MSI chip from. It also makes it more resilient against code reorganizations since the core code is the only place that needs to know where to get the chip from. Right. We have the same thing in the irq_chip callbacks. All of them take struct irq_data, because it's already available in the core code and it gives easy access to all information (chip, chipdata ...) which is necessary for the callback implementations. OK, I will drop this change, tglx, thanks for your review and comments! Thanks! Yijing. Thanks, tglx -- To unsubscribe from this list: send the line unsubscribe linux-pci in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html . -- Thanks! Yijing ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 15/22] MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq
On 2014/9/25 15:37, Thierry Reding wrote:
On Thu, Sep 25, 2014 at 11:14:25AM +0800, Yijing Wang wrote:
[...]
diff --git a/arch/mips/pci/pci-xlr.c b/arch/mips/pci/pci-xlr.c
[...]
@@ -214,11 +214,11 @@ static int get_irq_vector(const struct pci_dev *dev)
}
#ifdef CONFIG_PCI_MSI
-void arch_teardown_msi_irq(unsigned int irq)
+void xlr_teardown_msi_irq(unsigned int irq)
{
}
-int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
+int xlr_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc)
Can both of these now be static?
Yes, Will update.
Thierry
--
Thanks!
Yijing
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 01/10] tools/perf: support parsing parameterized events
Jiri Olsa [jo...@redhat.com] wrote: | On Wed, Sep 24, 2014 at 12:27:15PM -0700, Sukadev Bhattiprolu wrote: | From: Cody P Schafer c...@linux.vnet.ibm.com | | Enable event specification like: | | pmu/event_name,param1=0x1,param2=0x4/ | | Assuming that | | /sys/bus/event_source/devices/pmu/events/event_name | | Contains something like | | param2=foo,bar=1,param1=baz | | hum, so what happened to the '?' ... AFAIU from out last discussion, | you wanted to mark terms which are mandatory and user must provide | values for them.. and I thought the decision was to have following | alias record: | | $ cat /sys/bus/event_source/devices/pmu/events/event_name | param2=?,bar=1,param1=? | | while perf would scream if any of param1/2 wasnt filled like for: | pmu/event_name,param1=0x1/ Sorry, I meant to make perf list consistent with sysfs. Consider these two sysfs entries: $ cat HPM_0THRD_NON_IDLE_CCYC__PHYS_CORE domain=0x2,offset=0xe0,starting_index=core,lpar=0x0 $ cat HPM_0THRD_NON_IDLE_CCYC__VCPU_HOME_CORE domain=0x3,offset=0xe0,starting_index=vcpu,lpar=sibling_guest_id In the first one, starting_index refers to a 'core' while in the second it refers to a vcpu. This serves as a hint for the parameter's meaning. By replacing both with 'starting_index=?' we lose that hint. Should we fix both sysfs and 'perf list' to say starting_index=?core Sukadev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
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? Hi Thomas, I introduced this weak function , because I thought all platforms except arm always have only one msi chip, and I hoped to provide a simplest solution, less code changes. I consider several solutions to associate msi chip and PCI device. In my reply to Thierry in first reply, http://marc.info/?l=linux-pcim=141169658208255w=2 Could you give me some advices ? Thanks! Yijing. 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? Thanks, tglx . -- Thanks! Yijing ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 06/22] PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip
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. Thanks! Yijing. Thanks, tglx . -- Thanks! Yijing ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
On 2014/9/25 22:23, Konrad Rzeszutek Wilk wrote: On Thu, Sep 25, 2014 at 11:14:10AM +0800, Yijing Wang wrote: This series is based Bjorn's pci/msi branch git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git pci/msi Is there a git tree for these patches? Hi Konrad, my git tree in company can not be pulled from outside. I will try to update this series to github these days. Currently, there are a lot of weak arch functions in MSI code. Thierry Reding Introduced MSI chip framework to configure MSI/MSI-X in arm. This series use MSI chip framework to refactor MSI code across all platforms to eliminate weak arch functions. Then all MSI irqs will be managed in a unified framework. Because this series changed a lot of ARCH MSI code, so tests in the platforms which MSI code modified are warmly welcomed! v1-v2: Add a patch to make s390 MSI code build happy between patch x86/xen/MSI: E.. and s390/MSI: Use MSI... Fix several typo problems found by Lucas. RFC-v1: Updated [patch 4/21] x86/xen/MSI: Eliminate..., export msi_chip instead of #ifdef to fix MSI bug in xen running in x86. Rename arch_get_match_msi_chip() to arch_find_msi_chip(). Drop use struct device as the msi_chip argument, we will do that later in another patchset. Yijing Wang (22): PCI/MSI: Clean up struct msi_chip argument PCI/MSI: Remove useless bus-msi assignment MSI: Remove the redundant irq_set_chip_data() x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq() s390/MSI: Use __msi_mask_irq() instead of default_msi_mask_irq() PCI/MSI: Introduce weak arch_find_msi_chip() to find MSI chip PCI/MSI: Refactor struct msi_chip to make it become more common x86/MSI: Use MSI chip framework to configure MSI/MSI-X irq x86/xen/MSI: Use MSI chip framework to configure MSI/MSI-X irq Irq_remapping/MSI: Use MSI chip framework to configure MSI/MSI-X irq x86/MSI: Remove unused MSI weak arch functions MIPS/Octeon/MSI: Use MSI chip framework to configure MSI/MSI-X irq MIPS/Xlp: Remove the dead function destroy_irq() to fix build error MIPS/Xlp/MSI: Use MSI chip framework to configure MSI/MSI-X irq MIPS/Xlr/MSI: Use MSI chip framework to configure MSI/MSI-X irq Powerpc/MSI: Use MSI chip framework to configure MSI/MSI-X irq s390/MSI: Use MSI chip framework to configure MSI/MSI-X irq arm/iop13xx/MSI: Use MSI chip framework to configure MSI/MSI-X irq IA64/MSI: Use MSI chip framework to configure MSI/MSI-X irq Sparc/MSI: Use MSI chip framework to configure MSI/MSI-X irq tile/MSI: Use MSI chip framework to configure MSI/MSI-X irq PCI/MSI: Clean up unused MSI arch functions arch/arm/mach-iop13xx/include/mach/pci.h |2 + arch/arm/mach-iop13xx/iq81340mc.c|1 + arch/arm/mach-iop13xx/iq81340sc.c|1 + arch/arm/mach-iop13xx/msi.c |9 ++- arch/arm/mach-iop13xx/pci.c |6 ++ arch/ia64/kernel/msi_ia64.c | 18 - arch/mips/pci/msi-octeon.c | 35 ++ arch/mips/pci/msi-xlp.c | 18 -- arch/mips/pci/pci-xlr.c | 15 - arch/powerpc/kernel/msi.c| 14 +++- arch/s390/pci/pci.c | 18 - arch/sparc/kernel/pci.c | 14 +++- arch/tile/kernel/pci_gx.c| 14 +++- arch/x86/include/asm/apic.h |4 + arch/x86/include/asm/pci.h |4 +- arch/x86/include/asm/x86_init.h |7 -- arch/x86/kernel/apic/io_apic.c | 16 - arch/x86/kernel/x86_init.c | 34 - arch/x86/pci/xen.c | 60 +--- drivers/iommu/irq_remapping.c|9 ++- drivers/irqchip/irq-armada-370-xp.c |8 +-- drivers/pci/host/pci-tegra.c |8 ++- drivers/pci/host/pcie-designware.c |4 +- drivers/pci/host/pcie-rcar.c |8 ++- drivers/pci/msi.c| 114 ++ drivers/pci/probe.c |1 - include/linux/msi.h | 26 ++- 27 files changed, 266 insertions(+), 202 deletions(-) . -- Thanks! Yijing ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 04/22] x86/xen/MSI: Eliminate arch_msix_mask_irq() and arch_msi_mask_irq()
On 2014/9/25 22:33, Konrad Rzeszutek Wilk wrote:
On Thu, Sep 25, 2014 at 11:14:14AM +0800, Yijing Wang wrote:
Commit 0e4ccb150 added two __weak arch functions arch_msix_mask_irq()
and arch_msi_mask_irq() to fix a bug found when running xen in x86.
Introduced these two funcntions make MSI code complex. And mask/unmask
These two functions made the MSI code more complex.
OK, will update, thanks.
is the irq actions related to interrupt controller, should not use
weak arch functions to override mask/unmask interfaces. This patch
I am bit baffled of what you are saying.
Sorry for my poor English. The meaning is that I think override irq_chip
mask/unmask irq is better than introduced weak functions.
reverted commit 0e4ccb150 and export struct irq_chip msi_chip, modify
msi_chip-irq_mask/irq_unmask() in xen init functions to fix this
bug for simplicity. Also this is preparation for using struct
msi_chip instead of weak arch MSI functions in all platforms.
Keep default_msi_mask_irq() and default_msix_mask_irq() in
linux/msi.h to make s390 MSI code compile happy, they wiil be removed
s/wiil/will.
Will update, thanks.
in the later patch.
Tested-by: Konrad Rzeszutek Wilk konrad.w...@oracle.com
I don't even remember testing it - I guess I did the earlier version.
Yes, I added your tested-by because in last version, you help to test the whole
series in xen.
And I didn't change something in xen part patches in this new version.
So a couple of questions since I've totally forgotten about this:
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index 50f67a3..5f8f3af 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
...
static void msi_set_mask_bit(struct irq_data *data, u32 flag)
@@ -852,7 +842,7 @@ void pci_msi_shutdown(struct pci_dev *dev)
/* Return the device with MSI unmasked as initial states */
mask = msi_mask(desc-msi_attrib.multi_cap);
/* Keep cached state to be restored */
-arch_msi_mask_irq(desc, mask, ~mask);
+__msi_mask_irq(desc, mask, ~mask);
If I am reading this right, it will call the old 'default_msi_mask_irq'
which is exactly what we don't want to do under Xen. We want to call
the NOP code.
Good catch. I missed this one, it will also be called in xen.
I need to rework this patch.
/* Restore dev-irq to its default pin-assertion irq */
dev-irq = desc-msi_attrib.default_irq;
@@ -950,7 +940,7 @@ void pci_msix_shutdown(struct pci_dev *dev)
/* Return the device with MSI-X masked as initial states */
list_for_each_entry(entry, dev-msi_list, list) {
/* Keep cached states to be restored */
-arch_msix_mask_irq(entry, 1);
+__msix_mask_irq(entry, 1);
Ditto here.
Looking more at this code I have to retract my Reviewed-by and Tested-by
on the whole series.
OK, because this patch still need some enhancement.
Is it possible to get a git tree for this please?
I will provide a git tree as soon as possible.
Thanks!
Yijing.
}
msix_clear_and_set_ctrl(dev, PCI_MSIX_FLAGS_ENABLE, 0);
diff --git a/include/linux/msi.h b/include/linux/msi.h
index 45ef8cb..cc46a62 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -19,6 +19,8 @@ void read_msi_msg(struct msi_desc *entry, struct msi_msg
*msg);
void get_cached_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
void __write_msi_msg(struct msi_desc *entry, struct msi_msg *msg);
void write_msi_msg(unsigned int irq, struct msi_msg *msg);
+u32 __msix_mask_irq(struct msi_desc *desc, u32 flag);
+u32 __msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag);
struct msi_desc {
struct {
@@ -59,8 +61,8 @@ void arch_restore_msi_irqs(struct pci_dev *dev);
void default_teardown_msi_irqs(struct pci_dev *dev);
void default_restore_msi_irqs(struct pci_dev *dev);
-u32 default_msi_mask_irq(struct msi_desc *desc, u32 mask, u32 flag);
-u32 default_msix_mask_irq(struct msi_desc *desc, u32 flag);
+#define default_msi_mask_irq__msi_mask_irq
+#define default_msix_mask_irq __msix_mask_irq
struct msi_chip {
struct module *owner;
--
1.7.1
.
--
Thanks!
Yijing
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 00/22] Use MSI chip framework to configure MSI/MSI-X in all platforms
I am actually in disagreement with you, Thierry. I don't like the general direction of the patches, or at least I don't like the fact that we don't have a portable way of setting up the msi_chip without having to rely on weak architectural hooks. Oh, good. That's actually one of the things I said I wasn't happy with either. =) Hm, I decide to drop weak arch_find_msi_chip(), no one likes it. Let's find a better solution :) I'm surprised no one considers the case of a platform having more than one host bridge and possibly more than one MSI unit. With the current proposed patchset I can't see how that would work. The PCI core can already deal with that. An MSI chip can be set per bus and the weak pcibios_add_bus() can be used to set that. Often it might not even be necessary to do it via pcibios_add_bus() if you create the root bus directly, since you can attach the MSI chip at that time. Yes, PCI hostbridge driver find the matched msi chip during its initialization, and assign the msi chip to PCI bus in pcibios_add_bus(). 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. 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 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 01/15] powerpc/cell: Move spu_handle_mm_fault() out of cell platform
From: Ian Munsie imun...@au1.ibm.com Currently spu_handle_mm_fault() is in the cell platform. This code is generically useful for other non-cell co-processors on powerpc. This patch moves this function out of the cell platform into arch/powerpc/mm so that others may use it. Signed-off-by: Ian Munsie imun...@au1.ibm.com Signed-off-by: Michael Neuling mi...@neuling.org Reviewed-by: Anton Blanchard an...@samba.org Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 02/15] powerpc/cell: Move data segment faulting code out of cell platform
From: Ian Munsie imun...@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. Could we also mention: and adds 1TB segment support. Signed-off-by: Ian Munsie imun...@au1.ibm.com Signed-off-by: Michael Neuling mi...@neuling.org Reviewed-by: Anton Blanchard an...@samba.org Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 10/15] powerpc/mm: Add hooks for cxl
From: Ian Munsie imun...@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. Signed-off-by: Ian Munsie imun...@au1.ibm.com Signed-off-by: Michael Neuling mi...@neuling.org + use_local = local mmu_has_feature(MMU_FTR_TLBIEL) !cxl_ctx_in_use(); Seems reasonable until we can get the MMIO based optimisation in. Will all CAPI cached translations be invalidated before we finish using a CAPI context? And conversely, could CAPI cache any translations when a context isn't active? I'm mostly concerned that we can't have a situation where badly behaving userspace could result in a stale translation. spu_flush_all_slbs(mm); #endif + cxl_slbia(mm); spu_flush_all_slbs(mm); #endif + cxl_slbia(mm); spu_flush_all_slbs(mm); #endif + cxl_slbia(mm); spu_flush_all_slbs(mm); #endif + cxl_slbia(mm); Should we combine the SPU vs CXL callouts into something common - perhaps copro_flush_all_slbs()? Anton ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 09/15] powerpc/opal: Add PHB to cxl mode call
From: Ian Munsie imun...@au1.ibm.com This adds the OPAL call to change a PHB into cxl mode. Signed-off-by: Ian Munsie imun...@au1.ibm.com Signed-off-by: Michael Neuling mi...@neuling.org Reviewed-by: Anton Blanchard an...@samba.org ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
