* [PATCH v2 0/3] dmaengine: mpc512x: add device tree binding document and DMA channel lookup
From: Alexander Popov @ 2014-06-18 10:48 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine, devicetree
This patch series introduces a device tree binding document for
the MPC512x DMA controller and adds device tree based DMA channel lookup
for it.
This version has improved device tree binding document.
Alexander Popov (3):
dmaengine: mpc512x: add device tree binding document
dmaengine: of: add common xlate function for matching by channel id
dmaengine: mpc512x: register for device tree channel lookup
.../devicetree/bindings/dma/mpc512x-dma.txt | 31 +++++++++++++++++++
arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
drivers/dma/mpc512x_dma.c | 13 +++++++-
drivers/dma/of-dma.c | 35 ++++++++++++++++++++++
include/linux/of_dma.h | 4 +++
5 files changed, 83 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
--
1.8.4.2
^ permalink raw reply
* [PATCH v2 1/3] dmaengine: mpc512x: add device tree binding document
From: Alexander Popov @ 2014-06-18 10:48 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine, devicetree
In-Reply-To: <1403088492-15241-1-git-send-email-a13xp0p0v88@gmail.com>
Introduce a device tree binding document for the MPC512x DMA controller
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
.../devicetree/bindings/dma/mpc512x-dma.txt | 31 ++++++++++++++++++++++
1 file changed, 31 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
new file mode 100644
index 0000000..95e2ca0
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
@@ -0,0 +1,31 @@
+* Freescale MPC512x and MPC8308 DMA Controller
+
+The DMA controller in Freescale MPC512x and MPC8308 SoCs can move
+blocks of memory contents between memory and peripherals or
+from memory to memory.
+
+Refer to "Generic DMA Controller and DMA request bindings" in
+the dma/dma.txt file for a more detailed description of binding.
+
+Required properties:
+- compatible: should be "fsl,mpc5121-dma" or "fsl,mpc8308-dma";
+- reg: should contain the DMA controller registers location and length;
+- interrupt for the DMA controller: syntax of interrupt client node
+ is described in interrupt-controller/interrupts.txt file.
+
+Optional properties:
+- #dma-cells: the length of the DMA specifier, must be <1>.
+ Each channel of this DMA controller has a peripheral request line,
+ the assignment is fixed in hardware. This one cell
+ in dmas property of a client device represents the channel number.
+
+Example:
+
+ dma0: dma@14000 {
+ compatible = "fsl,mpc5121-dma";
+ reg = <0x14000 0x1800>;
+ interrupts = <65 0x8>;
+ #dma-cells = <1>;
+ };
+
+DMA clients must use the format described in dma/dma.txt file.
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 2/3] dmaengine: of: add common xlate function for matching by channel id
From: Alexander Popov @ 2014-06-18 10:48 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine, devicetree
In-Reply-To: <1403088492-15241-1-git-send-email-a13xp0p0v88@gmail.com>
This patch adds a new common OF dma xlate callback function which will match a
channel by it's id. The binding expects one integer argument which it will use to
lookup the channel by the id.
Unlike of_dma_simple_xlate this function is able to handle a system with
multiple DMA controllers. When registering the of dma provider with
of_dma_controller_register a pointer to the dma_device struct which is
associated with the dt node needs to passed as the data parameter.
New function will use this pointer to match only channels which belong to the
specified DMA controller.
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
drivers/dma/of-dma.c | 35 +++++++++++++++++++++++++++++++++++
include/linux/of_dma.h | 4 ++++
2 files changed, 39 insertions(+)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index e8fe9dc..d5fbeaa 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -218,3 +218,38 @@ struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
&dma_spec->args[0]);
}
EXPORT_SYMBOL_GPL(of_dma_simple_xlate);
+
+/**
+ * of_dma_xlate_by_chan_id - Translate dt property to DMA channel by channel id
+ * @dma_spec: pointer to DMA specifier as found in the device tree
+ * @of_dma: pointer to DMA controller data
+ *
+ * This function can be used as the of xlate callback for DMA driver which wants
+ * to match the channel based on the channel id. When using this xlate function
+ * the #dma-cells propety of the DMA controller dt node needs to be set to 1.
+ * The data parameter of of_dma_controller_register must be a pointer to the
+ * dma_device struct the function should match upon.
+ *
+ * Returns pointer to appropriate dma channel on success or NULL on error.
+ */
+struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct dma_device *dev = ofdma->of_dma_data;
+ struct dma_chan *chan, *candidate = NULL;
+
+ if (!dev || dma_spec->args_count != 1)
+ return NULL;
+
+ list_for_each_entry(chan, &dev->channels, device_node)
+ if (chan->chan_id == dma_spec->args[0]) {
+ candidate = chan;
+ break;
+ }
+
+ if (!candidate)
+ return NULL;
+
+ return dma_get_slave_channel(candidate);
+}
+EXPORT_SYMBOL_GPL(of_dma_xlate_by_chan_id);
diff --git a/include/linux/of_dma.h b/include/linux/of_dma.h
index ae36298..56bc026 100644
--- a/include/linux/of_dma.h
+++ b/include/linux/of_dma.h
@@ -41,6 +41,8 @@ extern struct dma_chan *of_dma_request_slave_channel(struct device_node *np,
const char *name);
extern struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_spec,
struct of_dma *ofdma);
+extern struct dma_chan *of_dma_xlate_by_chan_id(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma);
#else
static inline int of_dma_controller_register(struct device_node *np,
struct dma_chan *(*of_dma_xlate)
@@ -66,6 +68,8 @@ static inline struct dma_chan *of_dma_simple_xlate(struct of_phandle_args *dma_s
return NULL;
}
+#define of_dma_xlate_by_chan_id NULL
+
#endif
#endif /* __LINUX_OF_DMA_H */
--
1.8.4.2
^ permalink raw reply related
* [PATCH v2 3/3] dmaengine: mpc512x: register for device tree channel lookup
From: Alexander Popov @ 2014-06-18 10:48 UTC (permalink / raw)
To: Gerhard Sittig, Dan Williams, Vinod Koul, Lars-Peter Clausen,
Arnd Bergmann, Anatolij Gustschin, Andy Shevchenko,
Alexander Popov, linuxppc-dev, dmaengine, devicetree
In-Reply-To: <1403088492-15241-1-git-send-email-a13xp0p0v88@gmail.com>
Register the controller for device tree based lookup of DMA channels
(non-fatal for backwards compatibility with older device trees) and
provide the '#dma-cells' property in the shared mpc5121.dtsi file
Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
---
arch/powerpc/boot/dts/mpc5121.dtsi | 1 +
drivers/dma/mpc512x_dma.c | 13 ++++++++++++-
2 files changed, 13 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/boot/dts/mpc5121.dtsi b/arch/powerpc/boot/dts/mpc5121.dtsi
index 2c0e155..7f9d14f 100644
--- a/arch/powerpc/boot/dts/mpc5121.dtsi
+++ b/arch/powerpc/boot/dts/mpc5121.dtsi
@@ -498,6 +498,7 @@
compatible = "fsl,mpc5121-dma";
reg = <0x14000 0x1800>;
interrupts = <65 0x8>;
+ #dma-cells = <1>;
};
};
diff --git a/drivers/dma/mpc512x_dma.c b/drivers/dma/mpc512x_dma.c
index 2ad4373..881db2b 100644
--- a/drivers/dma/mpc512x_dma.c
+++ b/drivers/dma/mpc512x_dma.c
@@ -53,6 +53,7 @@
#include <linux/of_address.h>
#include <linux/of_device.h>
#include <linux/of_irq.h>
+#include <linux/of_dma.h>
#include <linux/of_platform.h>
#include <linux/random.h>
@@ -1036,7 +1037,15 @@ static int mpc_dma_probe(struct platform_device *op)
if (retval)
goto err_free2;
- return retval;
+ /* Register with OF helpers for DMA lookups (nonfatal) */
+ if (dev->of_node) {
+ retval = of_dma_controller_register(dev->of_node,
+ of_dma_xlate_by_chan_id, mdma);
+ if (retval)
+ dev_warn(dev, "Could not register for OF lookup\n");
+ }
+
+ return 0;
err_free2:
if (mdma->is_mpc8308)
@@ -1057,6 +1066,8 @@ static int mpc_dma_remove(struct platform_device *op)
struct device *dev = &op->dev;
struct mpc_dma *mdma = dev_get_drvdata(dev);
+ if (dev->of_node)
+ of_dma_controller_free(dev->of_node);
dma_async_device_unregister(&mdma->dma);
if (mdma->is_mpc8308) {
free_irq(mdma->irq2, mdma);
--
1.8.4.2
^ permalink raw reply related
* [PATCH] vfio: Fix endianness handling for emulated BARs
From: Alexey Kardashevskiy @ 2014-06-18 11:36 UTC (permalink / raw)
To: linuxppc-dev
Cc: Nikunj A Dadhania, kvm, Alexey Kardashevskiy, linux-kernel,
Alexander Graf, Alex Williamson
VFIO exposes BARs to user space as a byte stream so userspace can
read it using pread()/pwrite(). Since this is a byte stream, VFIO should
not do byte swapping and simply return values as it gets them from
PCI device.
Instead, the existing code assumes that byte stream in read/write is
little-endian and it fixes endianness for values which it passes to
ioreadXX/iowriteXX helpers. This works for little-endian as PCI is
little endian and le32_to_cpu/... are stubs.
This also works for big endian but rather by an accident: it reads 4 bytes
from the stream (@val is big endian), converts to CPU format (which should
be big endian) as it was little endian (@val becomes actually little
endian) and calls iowrite32() which does not do swapping on big endian
system.
This removes byte swapping and makes use ioread32be/iowrite32be
(and 16bit versions) on big-endian systems. The "be" helpers take
native endian values and do swapping at the moment of writing to a PCI
register using one of "store byte-reversed" instructions.
Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
drivers/vfio/pci/vfio_pci_rdwr.c | 20 ++++++++++++++++----
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 210db24..f363b5a 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -21,6 +21,18 @@
#include "vfio_pci_private.h"
+#ifdef __BIG_ENDIAN__
+#define ioread16_native ioread16be
+#define ioread32_native ioread32be
+#define iowrite16_native iowrite16be
+#define iowrite32_native iowrite32be
+#else
+#define ioread16_native ioread16
+#define ioread32_native ioread32
+#define iowrite16_native iowrite16
+#define iowrite32_native iowrite32
+#endif
+
/*
* Read or write from an __iomem region (MMIO or I/O port) with an excluded
* range which is inaccessible. The excluded range drops writes and fills
@@ -50,9 +62,9 @@ static ssize_t do_io_rw(void __iomem *io, char __user *buf,
if (copy_from_user(&val, buf, 4))
return -EFAULT;
- iowrite32(le32_to_cpu(val), io + off);
+ iowrite32_native(val, io + off);
} else {
- val = cpu_to_le32(ioread32(io + off));
+ val = ioread32_native(io + off);
if (copy_to_user(buf, &val, 4))
return -EFAULT;
@@ -66,9 +78,9 @@ static ssize_t do_io_rw(void __iomem *io, char __user *buf,
if (copy_from_user(&val, buf, 2))
return -EFAULT;
- iowrite16(le16_to_cpu(val), io + off);
+ iowrite16_native(val, io + off);
} else {
- val = cpu_to_le16(ioread16(io + off));
+ val = ioread16_native(io + off);
if (copy_to_user(buf, &val, 2))
return -EFAULT;
--
2.0.0
^ permalink raw reply related
* Re: [PATCH v2] powerpc/powernv: hwmon driver for power values, fan rpm and temperature
From: Guenter Roeck @ 2014-06-18 13:05 UTC (permalink / raw)
To: Neelesh Gupta, linuxppc-dev, jdelvare, lm-sensors; +Cc: sbhat
In-Reply-To: <53A1514F.30907@linux.vnet.ibm.com>
On 06/18/2014 01:43 AM, Neelesh Gupta wrote:
>
>>> +}
>>> +
>>> +static void __init get_sensor_index_attr(const char *name, u32 *index, char *attr)
>>> +{
>>> + char *hash_pos = strchr(name, '#');
>>> + char *dash_pos;
>>> + u32 copy_len;
>>> + char buf[8];
>>> +
>>> + memset(buf, 0, sizeof(buf));
>>> + *index = 0;
>>> + *attr = '\0';
>>> +
>>> + if (hash_pos) {
>>> + dash_pos = strchr(hash_pos, '-');
>>> + if (dash_pos) {
>>> + copy_len = dash_pos - hash_pos - 1;
>>> + if (copy_len < sizeof(buf)) {
>>> + strncpy(buf, hash_pos + 1, copy_len);
>>> + sscanf(buf, "%d", index);
>>
>> What if sscanf fails ? Might be an interesting exercise to try and create
>> multiple sensors with index 0 (or, for that matter, with the same index value).
>> Do you have any protection against bad input data ? Guess not; did you test
>> what happens if you pass bad data to the driver (such as duplicate sensor
>> entries) ?
>
> We can't have duplicate entries in the device tree under the same node ?
> But yes, rest other scenarios must be validated.
>
Was this a serious question ? Sorry, I wonder. It seems quite unlikely for a file
system to accept two files with the same name in the same directory.
Guenter
^ permalink raw reply
* Re: [PATCH 0/6] powerpc/powernv: Applying it_page_shift to platform code
From: Benjamin Herrenschmidt @ 2014-06-18 13:07 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: Paul Mackerras, linuxppc-dev, linux-kernel, Alistair Popple
In-Reply-To: <53A14623.4080900@ozlabs.ru>
On Wed, 2014-06-18 at 17:56 +1000, Alexey Kardashevskiy wrote:
> On 06/06/2014 06:44 PM, Alexey Kardashevskiy wrote:
> > Here is what I got for powernv in order to support variable page size
> > in iommu_table.
> >
> > I am very uncertain about Patch #4 "Add @it_owner to iommu_table struct"
> > and wonder if there any better way to get PE from iommu_table.
> >
> > Please comment. Thanks.
>
>
> Ben, these patches are really simple :)
Sure, they also arrived in the middle of the merge window, so they
can surely wait a bit longer.
Cheers,
Ben.
>
> >
> >
> > Alexey Kardashevskiy (6):
> > powerpc/powernv: use it_page_shift for TCE invalidation
> > powerpc/powernv: use it_page_shift in TCE build
> > powerpc/powernv: Add a page size parameter to
> > pnv_pci_setup_iommu_table()
> > powerpc/powernv: Add @it_owner to iommu_table struct
> > powerpc/powernv: Make set_bypass() callback a type
> > powerpc/powernv: Make invalidate() callback an iommu_table callback
> >
> > arch/powerpc/include/asm/iommu.h | 13 ++++++-
> > arch/powerpc/platforms/powernv/pci-ioda.c | 55 ++++++++++++++---------------
> > arch/powerpc/platforms/powernv/pci-p5ioc2.c | 3 +-
> > arch/powerpc/platforms/powernv/pci.c | 43 +++++++++++++++-------
> > arch/powerpc/platforms/powernv/pci.h | 7 ++--
> > 5 files changed, 74 insertions(+), 47 deletions(-)
> >
>
>
^ permalink raw reply
* Re: [PATCH v4 1/2]: Allow architectures to skip a callchain entry
From: Jiri Olsa @ 2014-06-18 13:39 UTC (permalink / raw)
To: Sukadev Bhattiprolu
Cc: linuxppc-dev, Anton Blanchard, linux-kernel,
Arnaldo Carvalho de Melo, michael, Ulrich.Weigand,
Maynard Johnson
In-Reply-To: <20140606032109.GA16600@us.ibm.com>
On Thu, Jun 05, 2014 at 08:21:09PM -0700, Sukadev Bhattiprolu wrote:
SNIP
> index 7409ac8..3f97cf2 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -1288,8 +1288,10 @@ static int machine__resolve_callchain_sample(struct machine *machine,
> {
> u8 cpumode = PERF_RECORD_MISC_USER;
> int chain_nr = min(max_stack, (int)chain->nr);
> + enum chain_order order = callchain_param.order;
> int i;
> int err;
> + int skip_idx;
>
> callchain_cursor_reset(&callchain_cursor);
>
> @@ -1298,14 +1300,13 @@ static int machine__resolve_callchain_sample(struct machine *machine,
> return 0;
> }
>
> + skip_idx = arch_skip_callchain_idx(machine, thread, chain);
> +
> for (i = 0; i < chain_nr; i++) {
> u64 ip;
> struct addr_location al;
>
> - if (callchain_param.order == ORDER_CALLEE)
> - ip = chain->ips[i];
> - else
> - ip = chain->ips[chain->nr - i - 1];
> + ip = next_callchain_ip(chain, order, i, skip_idx);
hum, I still dont see a point of adding new user
enum API (PERF_CONTEXT_IGNORE) when we can just do:
#ifdef HAVE_SKIP_CALLCHAIN_IDX
if (idx == skip_idx)
continue;
#endif
if (callchain_param.order == ORDER_CALLEE)
ip = chain->ips[i];
else
ip = chain->ips[chain->nr - i - 1];
jirka
>
> if (ip >= PERF_CONTEXT_MAX) {
> switch (ip) {
> @@ -1318,6 +1319,8 @@ static int machine__resolve_callchain_sample(struct machine *machine,
> case PERF_CONTEXT_USER:
> cpumode = PERF_RECORD_MISC_USER;
> break;
> + case PERF_CONTEXT_IGNORE:
> + break;
> default:
> pr_debug("invalid callchain context: "
> "%"PRId64"\n", (s64) ip);
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH v2 1/3] dmaengine: mpc512x: add device tree binding document
From: Mark Rutland @ 2014-06-18 13:37 UTC (permalink / raw)
To: Alexander Popov
Cc: devicetree@vger.kernel.org, Lars-Peter Clausen, Arnd Bergmann,
Vinod Koul, Gerhard Sittig, Andy Shevchenko,
dmaengine@vger.kernel.org, Dan Williams, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1403088492-15241-2-git-send-email-a13xp0p0v88@gmail.com>
On Wed, Jun 18, 2014 at 11:48:10AM +0100, Alexander Popov wrote:
> Introduce a device tree binding document for the MPC512x DMA controller
>
> Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
> ---
> .../devicetree/bindings/dma/mpc512x-dma.txt | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
>
> diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
> new file mode 100644
> index 0000000..95e2ca0
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
> @@ -0,0 +1,31 @@
> +* Freescale MPC512x and MPC8308 DMA Controller
> +
> +The DMA controller in Freescale MPC512x and MPC8308 SoCs can move
> +blocks of memory contents between memory and peripherals or
> +from memory to memory.
> +
> +Refer to "Generic DMA Controller and DMA request bindings" in
> +the dma/dma.txt file for a more detailed description of binding.
> +
> +Required properties:
> +- compatible: should be "fsl,mpc5121-dma" or "fsl,mpc8308-dma";
> +- reg: should contain the DMA controller registers location and length;
> +- interrupt for the DMA controller: syntax of interrupt client node
> + is described in interrupt-controller/interrupts.txt file.
> +
> +Optional properties:
> +- #dma-cells: the length of the DMA specifier, must be <1>.
> + Each channel of this DMA controller has a peripheral request line,
> + the assignment is fixed in hardware. This one cell
> + in dmas property of a client device represents the channel number.
Surely this is required to be able to refer to DMA channels on the
device?
Mark.
^ permalink raw reply
* Re: [PATCH v2 1/3] dmaengine: mpc512x: add device tree binding document
From: Alexander Popov @ 2014-06-18 14:56 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree@vger.kernel.org, Lars-Peter Clausen, Arnd Bergmann,
Vinod Koul, Gerhard Sittig, Andy Shevchenko, Alexander Popov,
dmaengine@vger.kernel.org, Dan Williams, Anatolij Gustschin,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20140618133730.GB11895@leverpostej>
Hello Mark, thanks for your reply!
2014-06-18 17:37 GMT+04:00 Mark Rutland <mark.rutland@arm.com>:
> On Wed, Jun 18, 2014 at 11:48:10AM +0100, Alexander Popov wrote:
>> Introduce a device tree binding document for the MPC512x DMA controller
>>
>> Signed-off-by: Alexander Popov <a13xp0p0v88@gmail.com>
>> ---
>> .../devicetree/bindings/dma/mpc512x-dma.txt | 31 ++++++++++++++++++++++
>> 1 file changed, 31 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/dma/mpc512x-dma.txt
>>
>> diff --git a/Documentation/devicetree/bindings/dma/mpc512x-dma.txt b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
>> new file mode 100644
>> index 0000000..95e2ca0
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/dma/mpc512x-dma.txt
>> @@ -0,0 +1,31 @@
>> +* Freescale MPC512x and MPC8308 DMA Controller
>> +
>> +The DMA controller in Freescale MPC512x and MPC8308 SoCs can move
>> +blocks of memory contents between memory and peripherals or
>> +from memory to memory.
>> +
>> +Refer to "Generic DMA Controller and DMA request bindings" in
>> +the dma/dma.txt file for a more detailed description of binding.
>> +
>> +Required properties:
>> +- compatible: should be "fsl,mpc5121-dma" or "fsl,mpc8308-dma";
>> +- reg: should contain the DMA controller registers location and length;
>> +- interrupt for the DMA controller: syntax of interrupt client node
>> + is described in interrupt-controller/interrupts.txt file.
>> +
>> +Optional properties:
>> +- #dma-cells: the length of the DMA specifier, must be <1>.
>> + Each channel of this DMA controller has a peripheral request line,
>> + the assignment is fixed in hardware. This one cell
>> + in dmas property of a client device represents the channel number.
>
> Surely this is required to be able to refer to DMA channels on the
> device?
Excuse me, I didn't understand your question.
Do you inquire about the reason of making #dma-cells an optional property?
It's optional because device tree based lookup support is made
optional (part 3/3).
Best regards,
Alexander
^ permalink raw reply
* RE: [PATCH] fsl-rio: add support for mapping inbound windows
From: Bounine, Alexandre @ 2014-06-18 15:17 UTC (permalink / raw)
To: Martijn de Gouw, linuxppc-dev@lists.ozlabs.org,
scottwood@freescale.com
Cc: stef.van.os@prodrive-technologies.com, Martijn de Gouw,
Wood, Barry
In-Reply-To: <1402657758-3019-1-git-send-email-martijn.de.gouw@prodrive-technologies.com>
On Friday, June 13, 2014 7:09 AM Martijn de Gouw [mailto:martijn.de.gouw@pr=
odrive-
technologies.com] wrote:
> Add support for mapping and unmapping of inbound rapidio windows.
>=20
> Signed-off-by: Martijn de Gouw <martijn.de.gouw@prodrive.nl>
> ---
... skip ...
> +
> +int fsl_map_inb_mem(struct rio_mport *mport, dma_addr_t lstart,
> + u64 rstart, u32 size, u32 flags)
> +{
> + struct rio_priv *priv =3D mport->priv;
> + u32 base_size;
> + unsigned int base_size_log;
> + u64 win_start, win_end;
> + u32 riwar;
> + int i;
> +
> + base_size_log =3D __ilog2(size) + ((size & (size - 1)) !=3D 0);
> + base_size =3D 1 << base_size_log;
> +
> + for (i =3D 0; i < RIO_INB_ATMU_COUNT; i++) {
> + riwar =3D in_be32(&priv->inb_atmu_regs[i].riwar);
> + if ((riwar & RIWAR_ENABLE) =3D=3D 0)
> + break;
> + /* check conflicting ranges */
> + win_start =3D ((u64)(in_be32(&priv->inb_atmu_regs[i].riwbar) & RIWBAR_=
BADD_MASK))
> + << RIWBAR_BADD_VAL_SHIFT;
> + win_end =3D win_start + ((1 << ((riwar & RIWAR_SIZE_MASK) + 1)) - 1);
> + if (rstart < win_end && (rstart + size) > win_start)
> + return -EINVAL;
> + }
It looks like the check for conflicting ranges assumes sequential mapping r=
equests only.
This check will be missed if ATMU windows are dynamically mapped/unmapped o=
ut-of-order.
Because the unmap callback is implemented please consider possibility of us=
ing ATMU windows
in any order.
^ permalink raw reply
* [PATCH] KVM: PPC: Book3E: Unlock mmu_lock when setting caching atttribute
From: Mihai Caraman @ 2014-06-18 15:45 UTC (permalink / raw)
To: kvm-ppc; +Cc: Bharat Bhushan, Mihai Caraman, linuxppc-dev, kvm
The patch 08c9a188d0d0fc0f0c5e17d89a06bb59c493110f
kvm: powerpc: use caching attributes as per linux pte
do not handle properly the error case, letting mmu_lock locked. The lock
will further generate a RCU stall from kvmppc_e500_emul_tlbwe() caller.
In case of an error go to out label.
Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
Cc: Bharat Bhushan <bharat.bhushan@freescale.com>
---
arch/powerpc/kvm/e500_mmu_host.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu_host.c
index 0528fe5..54144c7 100644
--- a/arch/powerpc/kvm/e500_mmu_host.c
+++ b/arch/powerpc/kvm/e500_mmu_host.c
@@ -473,7 +473,8 @@ static inline int kvmppc_e500_shadow_map(struct kvmppc_vcpu_e500 *vcpu_e500,
if (printk_ratelimit())
pr_err("%s: pte not present: gfn %lx, pfn %lx\n",
__func__, (long)gfn, pfn);
- return -EINVAL;
+ ret = -EINVAL;
+ goto out;
}
kvmppc_e500_ref_setup(ref, gtlbe, pfn, wimg);
--
1.7.11.7
^ permalink raw reply related
* RE: [PATCH] KVM: PPC: Book3E: Unlock mmu_lock when setting caching atttribute
From: Bharat.Bhushan @ 2014-06-18 16:01 UTC (permalink / raw)
To: mihai.caraman@freescale.com, kvm-ppc@vger.kernel.org
Cc: mihai.caraman@freescale.com, linuxppc-dev@lists.ozlabs.org,
kvm@vger.kernel.org
In-Reply-To: <1403106305-11565-1-git-send-email-mihai.caraman@freescale.com>
> -----Original Message-----
> From: Mihai Caraman [mailto:mihai.caraman@freescale.com]
> Sent: Wednesday, June 18, 2014 9:15 PM
> To: kvm-ppc@vger.kernel.org
> Cc: kvm@vger.kernel.org; linuxppc-dev@lists.ozlabs.org; Caraman Mihai Cla=
udiu-
> B02008; Bhushan Bharat-R65777
> Subject: [PATCH] KVM: PPC: Book3E: Unlock mmu_lock when setting caching
> atttribute
>=20
> The patch 08c9a188d0d0fc0f0c5e17d89a06bb59c493110f
> kvm: powerpc: use caching attributes as per linux pte
> do not handle properly the error case, letting mmu_lock locked. The lock
> will further generate a RCU stall from kvmppc_e500_emul_tlbwe() caller.
>=20
> In case of an error go to out label.
>=20
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> Cc: Bharat Bhushan <bharat.bhushan@freescale.com>
Thanks mike for fixing this; I am curious to know how you reached to this p=
oint :)
Reviewed-by: Bharat Bhushan <bharat.bhushan@freescale.com>
Regards
-Bharat
> ---
> arch/powerpc/kvm/e500_mmu_host.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>=20
> diff --git a/arch/powerpc/kvm/e500_mmu_host.c b/arch/powerpc/kvm/e500_mmu=
_host.c
> index 0528fe5..54144c7 100644
> --- a/arch/powerpc/kvm/e500_mmu_host.c
> +++ b/arch/powerpc/kvm/e500_mmu_host.c
> @@ -473,7 +473,8 @@ static inline int kvmppc_e500_shadow_map(struct
> kvmppc_vcpu_e500 *vcpu_e500,
> if (printk_ratelimit())
> pr_err("%s: pte not present: gfn %lx, pfn %lx\n",
> __func__, (long)gfn, pfn);
> - return -EINVAL;
> + ret =3D -EINVAL;
> + goto out;
> }
> kvmppc_e500_ref_setup(ref, gtlbe, pfn, wimg);
>=20
> --
> 1.7.11.7
^ permalink raw reply
* Re: [PATCH v4] KVM: PPC: e500mc: Enhance tlb invalidation condition on vcpu schedule
From: Scott Wood @ 2014-06-18 17:21 UTC (permalink / raw)
To: Mihai Caraman; +Cc: linuxppc-dev, kvm, kvm-ppc
In-Reply-To: <1403075722-11151-1-git-send-email-mihai.caraman@freescale.com>
On Wed, 2014-06-18 at 10:15 +0300, Mihai Caraman wrote:
> On vcpu schedule, the condition checked for tlb pollution is too loose.
> The tlb entries of a vcpu become polluted (vs stale) only when a different
> vcpu within the same logical partition runs in-between. Optimize the tlb
> invalidation condition keeping last_vcpu per logical partition id.
>
> With the new invalidation condition, a guest shows 4% performance improvement
> on P5020DS while running a memory stress application with the cpu oversubscribed,
> the other guest running a cpu intensive workload.
>
> Guest - old invalidation condition
> real 3.89
> user 3.87
> sys 0.01
>
> Guest - enhanced invalidation condition
> real 3.75
> user 3.73
> sys 0.01
>
> Host
> real 3.70
> user 1.85
> sys 0.00
>
> The memory stress application accesses 4KB pages backed by 75% of available
> TLB0 entries:
>
> char foo[ENTRIES][4096] __attribute__ ((aligned (4096)));
>
> int main()
> {
> char bar;
> int i, j;
>
> for (i = 0; i < ITERATIONS; i++)
> for (j = 0; j < ENTRIES; j++)
> bar = foo[j][0];
>
> return 0;
> }
>
> Signed-off-by: Mihai Caraman <mihai.caraman@freescale.com>
> Cc: Scott Wood <scottwood@freescale.com>
> ---
> v4:
> - rename last_vcpu_on_cpu to last_vcpu_of_lpid
> - use "*[" syntax despite checkpatch error
>
> v3:
> - use existing logic while keeping last_cpu per lpid
>
> arch/powerpc/kvm/e500mc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/powerpc/kvm/e500mc.c b/arch/powerpc/kvm/e500mc.c
> index 17e4562..690499d 100644
> --- a/arch/powerpc/kvm/e500mc.c
> +++ b/arch/powerpc/kvm/e500mc.c
> @@ -110,7 +110,7 @@ void kvmppc_mmu_msr_notify(struct kvm_vcpu *vcpu, u32 old_msr)
> {
> }
>
> -static DEFINE_PER_CPU(struct kvm_vcpu *, last_vcpu_on_cpu);
> +static DEFINE_PER_CPU(struct kvm_vcpu *[KVMPPC_NR_LPIDS], last_vcpu_of_lpid);
>
> static void kvmppc_core_vcpu_load_e500mc(struct kvm_vcpu *vcpu, int cpu)
> {
> @@ -141,9 +141,9 @@ static void kvmppc_core_vcpu_load_e500mc(struct kvm_vcpu *vcpu, int cpu)
> mtspr(SPRN_GESR, vcpu->arch.shared->esr);
>
> if (vcpu->arch.oldpir != mfspr(SPRN_PIR) ||
> - __get_cpu_var(last_vcpu_on_cpu) != vcpu) {
> + __get_cpu_var(last_vcpu_of_lpid)[vcpu->kvm->arch.lpid] != vcpu) {
> kvmppc_e500_tlbil_all(vcpu_e500);
> - __get_cpu_var(last_vcpu_on_cpu) = vcpu;
> + __get_cpu_var(last_vcpu_of_lpid)[vcpu->kvm->arch.lpid] = vcpu;
> }
>
> kvmppc_load_guest_fp(vcpu);
Reviewed-by: Scott Wood <scottwood@freescale.com>
-Scott
^ permalink raw reply
* Kernel 3.15: Boot problems with a PA6T board
From: Christian Zigotzky @ 2014-06-18 17:42 UTC (permalink / raw)
To: Michael Ellerman, Olof Johansson, linuxppc-dev
In-Reply-To: <25927053.1589.1403105603389.JavaMail.adrian@Gurnard>
On 18.06.14 17:33, Adrian Cox wrote:
>
> ----- Original Message -----
>> From: "Christian Zigotzky" <chzigotzky@xenosoft.de>
>>>> Christian
>>> But my opinion is, that's normal for the SB600 south bridge to
>>> presents itself as multiple devices on the PCIe bus on x86 PCs. I
>>> see
>>> a lot of PCs with SB600 south bridge on the internet. And the Linux
>>> kernel works with this south bridge. Or is it a powerpc issue?
>>>
> It is a powerpc issue. The SB600 connects to the AMD north bridge in a PC using a mode which is not PCIe compliant, and this makes the SB600 internal units appear as though they are on the root bus of a legacy PC. The powerpc does not have this built-in SB600 support.
>
>
> Adrian
>
^ permalink raw reply
* Re: [RFC PATCH V3 14/17] ppc/pci: create/release dev-tree node for VFs
From: Grant Likely @ 2014-06-18 18:26 UTC (permalink / raw)
To: Wei Yang
Cc: Benjamin Herrenschmidt, linux-pci@vger.kernel.org, gwshan,
Mike Qiu, Bjorn Helgaas, yan, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <1402365399-5121-15-git-send-email-weiyang@linux.vnet.ibm.com>
On Tue, Jun 10, 2014 at 2:56 AM, Wei Yang <weiyang@linux.vnet.ibm.com> wrote:
> Currently, powernv platform is not aware of VFs. This means no dev-node
> represents a VF. Also, VF PCI device is created when PF driver want to enable
> it. This leads to the pdn->pdev and pdn->pe_number an invalid value.
>
> This patch create/release dev-node for VF and fixs this when a VF's pci_dev
> is created.
>
> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
I don't think this is the right way to handle this. Unless it is a
fixup to a buggy devicetree provided by firmware, I don't want to see
any code modifying the devicetree to describe stuff that is able to be
directly enumerated. Really the pci code should handle the lack of a
device_node gracefully. If it cannot then it should be fixed.
g.
> ---
> arch/powerpc/platforms/powernv/Kconfig | 1 +
> arch/powerpc/platforms/powernv/pci-ioda.c | 103 +++++++++++++++++++++++++++++
> arch/powerpc/platforms/powernv/pci.c | 20 ++++++
> 3 files changed, 124 insertions(+)
>
> diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig
> index 895e8a2..0dd331b 100644
> --- a/arch/powerpc/platforms/powernv/Kconfig
> +++ b/arch/powerpc/platforms/powernv/Kconfig
> @@ -11,6 +11,7 @@ config PPC_POWERNV
> select PPC_UDBG_16550
> select PPC_SCOM
> select ARCH_RANDOM
> + select OF_DYNAMIC
> default y
>
> config PPC_POWERNV_RTAS
> diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c b/arch/powerpc/platforms/powernv/pci-ioda.c
> index e46c5bf..9ace027 100644
> --- a/arch/powerpc/platforms/powernv/pci-ioda.c
> +++ b/arch/powerpc/platforms/powernv/pci-ioda.c
> @@ -23,6 +23,7 @@
> #include <linux/io.h>
> #include <linux/msi.h>
> #include <linux/memblock.h>
> +#include <linux/of_pci.h>
>
> #include <asm/sections.h>
> #include <asm/io.h>
> @@ -771,6 +772,108 @@ static void pnv_pci_ioda_setup_PEs(void)
> }
> }
>
> +#ifdef CONFIG_PCI_IOV
> +static void pnv_pci_create_vf_node(struct pci_dev *dev, u16 vf_num)
> +{
> + struct device_node *dn, *p_dn;
> + struct pci_dn *pdn;
> + struct pci_controller *hose;
> + struct property *pp;
> + void* value;
> + u16 id;
> +
> + hose = pci_bus_to_host(dev->bus);
> +
> + /* Create dev-tree node for VFs if this is a PF */
> + p_dn = pci_bus_to_OF_node(dev->bus);
> + if (p_dn == NULL) {
> + dev_err(&dev->dev, "SRIOV: VF bus NULL device node\n");
> + return;
> + }
> +
> + for (id = 0; id < vf_num; id++) {
> + dn = kzalloc(sizeof(*dn), GFP_KERNEL);
> + pdn = kzalloc(sizeof(*pdn), GFP_KERNEL);
> + pp = kzalloc(sizeof(*pp), GFP_KERNEL);
> + value = kzalloc(sizeof(u32), GFP_KERNEL);
> +
> + if (!dn || !pdn || !pp || !value) {
> + kfree(dn);
> + kfree(pdn);
> + kfree(pp);
> + kfree(value);
> + dev_warn(&dev->dev, "%s: failed to create"
> + "dev-tree node for idx(%d)\n",
> + __func__, id);
> +
> + break;
> + }
> +
> + pp->value = value;
> + pdn->node = dn;
> + pdn->devfn = pci_iov_virtfn_devfn(dev, id);
> + pdn->busno = dev->bus->number;
> + pdn->pe_number = IODA_INVALID_PE;
> + pdn->phb = hose;
> +
> + dn->data = pdn;
> + kref_init(&dn->kref);
> + dn->full_name = dn->name =
> + kasprintf(GFP_KERNEL, "%s/vf%d",
> + p_dn->full_name, pdn->devfn);
> + dn->parent = p_dn;
> +
> + pp->name = kasprintf(GFP_KERNEL, "reg");
> + pp->length = 5 * sizeof(__be32);
> + *(u32*)pp->value = cpu_to_be32(pdn->devfn) << 8;
> + dn->properties = pp;
> +
> + of_attach_node(dn);
> + }
> +}
> +
> +static void pnv_pci_release_vf_node(struct pci_dev *dev, u16 vf_num)
> +{
> + struct device_node *dn;
> + struct property *pp;
> + u16 id;
> +
> + for (id = 0; id < vf_num; id++) {
> + dn = of_pci_find_child_device(dev->bus->dev.of_node,
> + pci_iov_virtfn_devfn(dev, id));
> + if (!dn)
> + continue;
> +
> + of_detach_node(dn);
> + pp = dn->properties;
> + kfree(pp->name);
> + kfree(pp->value);
> + kfree(pp);
> + kfree(dn->data);
> + kfree(dn);
> + }
> +}
> +
> +int pcibios_sriov_disable(struct pci_dev *pdev)
> +{
> + struct pci_sriov *iov;
> + u16 vf_num;
> +
> + iov = pdev->sriov;
> + vf_num = iov->num_VFs;
> + pnv_pci_release_vf_node(pdev, vf_num);
> +
> + return 0;
> +}
> +
> +int pcibios_sriov_enable(struct pci_dev *pdev, u16 vf_num)
> +{
> + pnv_pci_create_vf_node(pdev, vf_num);
> +
> + return 0;
> +}
> +#endif /* CONFIG_PCI_IOV */
> +
> static void pnv_pci_ioda_dma_dev_setup(struct pnv_phb *phb, struct pci_dev *pdev)
> {
> struct pci_dn *pdn = pci_get_pdn(pdev);
> diff --git a/arch/powerpc/platforms/powernv/pci.c b/arch/powerpc/platforms/powernv/pci.c
> index 687a068..43fcc73 100644
> --- a/arch/powerpc/platforms/powernv/pci.c
> +++ b/arch/powerpc/platforms/powernv/pci.c
> @@ -654,6 +654,26 @@ static void pnv_pci_dma_dev_setup(struct pci_dev *pdev)
> {
> struct pci_controller *hose = pci_bus_to_host(pdev->bus);
> struct pnv_phb *phb = hose->private_data;
> +#ifdef CONFIG_PCI_IOV
> + struct pnv_ioda_pe *pe;
> + struct pci_dn *pdn;
> +
> + /* Fix the VF pdn PE number */
> + if (pdev->is_virtfn) {
> + pdn = pci_get_pdn(pdev);
> + if (pdn->pcidev == NULL || pdn->pe_number == IODA_INVALID_PE) {
> + list_for_each_entry(pe, &phb->ioda.pe_list, list) {
> + if (pe->rid ==
> + ((pdev->bus->number << 8) | (pdev->devfn & 0xff))) {
> + pdn->pcidev = pdev;
> + pdn->pe_number = pe->pe_number;
> + pe->pdev = pdev;
> + break;
> + }
> + }
> + }
> + }
> +#endif /* CONFIG_PCI_IOV */
>
> /* If we have no phb structure, try to setup a fallback based on
> * the device-tree (RTAS PCI for example)
> --
> 1.7.9.5
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] vfio: Fix endianness handling for emulated BARs
From: Alex Williamson @ 2014-06-18 18:35 UTC (permalink / raw)
To: Alexey Kardashevskiy
Cc: kvm, Nikunj A Dadhania, linux-kernel, Alexander Graf,
linuxppc-dev
In-Reply-To: <1403091391-31780-1-git-send-email-aik@ozlabs.ru>
On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
> VFIO exposes BARs to user space as a byte stream so userspace can
> read it using pread()/pwrite(). Since this is a byte stream, VFIO should
> not do byte swapping and simply return values as it gets them from
> PCI device.
>
> Instead, the existing code assumes that byte stream in read/write is
> little-endian and it fixes endianness for values which it passes to
> ioreadXX/iowriteXX helpers. This works for little-endian as PCI is
> little endian and le32_to_cpu/... are stubs.
vfio read32:
val = cpu_to_le32(ioread32(io + off));
Where the typical x86 case, ioread32 is:
#define ioread32(addr) readl(addr)
and readl is:
__le32_to_cpu(__raw_readl(addr));
So we do canceling byte swaps, which are both nops on x86, and end up
returning device endian, which we assume is little endian.
vfio write32 is similar:
iowrite32(le32_to_cpu(val), io + off);
The implicit cpu_to_le32 of iowrite32() and our explicit swap cancel
out, so input data is device endian, which is assumed little.
> This also works for big endian but rather by an accident: it reads 4 bytes
> from the stream (@val is big endian), converts to CPU format (which should
> be big endian) as it was little endian (@val becomes actually little
> endian) and calls iowrite32() which does not do swapping on big endian
> system.
Really?
In arch/powerpc/kernel/iomap.c iowrite32() is just a wrapper around
writel(), which seems to use the generic implementation, which does
include a cpu_to_le32.
I also see other big endian archs like parisc doing cpu_to_le32 on
iowrite32, so I don't think this statement is true. I imagine it's
probably working for you because the swap cancel.
> This removes byte swapping and makes use ioread32be/iowrite32be
> (and 16bit versions) on big-endian systems. The "be" helpers take
> native endian values and do swapping at the moment of writing to a PCI
> register using one of "store byte-reversed" instructions.
So now you want iowrite32() on little endian and iowrite32be() on big
endian, the former does a cpu_to_le32 (which is a nop on little endian)
and the latter does a cpu_to_be32 (which is a nop on big endian)...
should we just be using __raw_writel() on both? There doesn't actually
seem to be any change in behavior here, it just eliminates back-to-back
byte swaps, which are a nop on x86, but not power, right?
> Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
> ---
> drivers/vfio/pci/vfio_pci_rdwr.c | 20 ++++++++++++++++----
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
> index 210db24..f363b5a 100644
> --- a/drivers/vfio/pci/vfio_pci_rdwr.c
> +++ b/drivers/vfio/pci/vfio_pci_rdwr.c
> @@ -21,6 +21,18 @@
>
> #include "vfio_pci_private.h"
>
> +#ifdef __BIG_ENDIAN__
> +#define ioread16_native ioread16be
> +#define ioread32_native ioread32be
> +#define iowrite16_native iowrite16be
> +#define iowrite32_native iowrite32be
> +#else
> +#define ioread16_native ioread16
> +#define ioread32_native ioread32
> +#define iowrite16_native iowrite16
> +#define iowrite32_native iowrite32
> +#endif
> +
> /*
> * Read or write from an __iomem region (MMIO or I/O port) with an excluded
> * range which is inaccessible. The excluded range drops writes and fills
> @@ -50,9 +62,9 @@ static ssize_t do_io_rw(void __iomem *io, char __user *buf,
> if (copy_from_user(&val, buf, 4))
> return -EFAULT;
>
> - iowrite32(le32_to_cpu(val), io + off);
> + iowrite32_native(val, io + off);
> } else {
> - val = cpu_to_le32(ioread32(io + off));
> + val = ioread32_native(io + off);
>
> if (copy_to_user(buf, &val, 4))
> return -EFAULT;
> @@ -66,9 +78,9 @@ static ssize_t do_io_rw(void __iomem *io, char __user *buf,
> if (copy_from_user(&val, buf, 2))
> return -EFAULT;
>
> - iowrite16(le16_to_cpu(val), io + off);
> + iowrite16_native(val, io + off);
> } else {
> - val = cpu_to_le16(ioread16(io + off));
> + val = ioread16_native(io + off);
>
> if (copy_to_user(buf, &val, 2))
> return -EFAULT;
^ permalink raw reply
* OF_DYNAMIC node lifecycle
From: Grant Likely @ 2014-06-18 20:07 UTC (permalink / raw)
To: Nathan Fontenot, Tyrel Datwyler
Cc: devicetree@vger.kernel.org, Pantelis Antoniou, linuxppc-dev
Hi Nathan and Tyrel,
I'm looking into lifecycle issues on nodes modified by OF_DYNAMIC, and
I'm hoping you can help me. Right now, pseries seems to be the only
user of OF_DYNAMIC, but making OF_DYNAMIC work has a huge impact on
the entire kernel because it requires all DT code to manage reference
counting with iterating over nodes. Most users simply get it wrong.
Pantelis did some investigation and found that the reference counts on
a running kernel are all over the place. I have my doubts that any
code really gets it right.
The problem is that users need to know when it is appropriate to call
of_node_get()/of_node_put(). All list traversals that exit early need
an extra call to of_node_put(), and code that is searching for a node
in the tree and holding a reference to it needs to call of_node_get().
I've got a few pseries questions:
- What are the changes being requested by pseries firmware? Is it only
CPUs and memory nodes, or does it manipulate things all over the tree?
- How frequent are the changes? How many changes would be likely over
the runtime of the system?
- Are you able to verify that removed nodes are actually able to be
freed correctly? Do you have any testcases for node removal?
I'm thinking very seriously about changing the locking semantics of DT
code entirely so that most users never have to worry about
of_node_get/put at all. If the DT code is switched to use rcu
primitives for tree iteration (which also means making DT code use
list_head, something I'm already investigating), then instead of
trying to figure out of_node_get/put rules, callers could use
rcu_read_lock()/rcu_read_unlock() to protect the region that is
searching over nodes, and only call of_node_get() if the node pointer
is needed outside the rcu read-side lock.
I'd really like to be rid of the node reference counting entirely, but
I can't figure out a way of doing that safely, so I'd settle for
making it a lot easier to get correct.
Thoughts?
g.
^ permalink raw reply
* Re: [PATCH v3 -next 4/9] DMA, CMA: support arbitrary bitmap granularity
From: Andrew Morton @ 2014-06-18 20:48 UTC (permalink / raw)
To: Joonsoo Kim
Cc: kvm-ppc, Russell King - ARM Linux, kvm, linux-mm, Gleb Natapov,
Greg Kroah-Hartman, Alexander Graf, Michal Nazarewicz,
linux-kernel, Minchan Kim, Paul Mackerras, Aneesh Kumar K.V,
Paolo Bonzini, Zhang Yanfei, linuxppc-dev, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <1402897251-23639-5-git-send-email-iamjoonsoo.kim@lge.com>
On Mon, 16 Jun 2014 14:40:46 +0900 Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
> PPC KVM's CMA area management requires arbitrary bitmap granularity,
> since they want to reserve very large memory and manage this region
> with bitmap that one bit for several pages to reduce management overheads.
> So support arbitrary bitmap granularity for following generalization.
>
> ...
>
> --- a/drivers/base/dma-contiguous.c
> +++ b/drivers/base/dma-contiguous.c
> @@ -38,6 +38,7 @@ struct cma {
> unsigned long base_pfn;
> unsigned long count;
> unsigned long *bitmap;
> + unsigned int order_per_bit; /* Order of pages represented by one bit */
> struct mutex lock;
> };
>
> @@ -157,9 +158,37 @@ void __init dma_contiguous_reserve(phys_addr_t limit)
>
> static DEFINE_MUTEX(cma_mutex);
>
> +static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int align_order)
> +{
> + return (1 << (align_order >> cma->order_per_bit)) - 1;
> +}
Might want a "1UL << ..." here.
> +static unsigned long cma_bitmap_maxno(struct cma *cma)
> +{
> + return cma->count >> cma->order_per_bit;
> +}
> +
> +static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
> + unsigned long pages)
> +{
> + return ALIGN(pages, 1 << cma->order_per_bit) >> cma->order_per_bit;
> +}
Ditto. I'm not really sure what the compiler will do in these cases,
but would prefer not to rely on it anyway!
--- a/drivers/base/dma-contiguous.c~dma-cma-support-arbitrary-bitmap-granularity-fix
+++ a/drivers/base/dma-contiguous.c
@@ -160,7 +160,7 @@ static DEFINE_MUTEX(cma_mutex);
static unsigned long cma_bitmap_aligned_mask(struct cma *cma, int align_order)
{
- return (1 << (align_order >> cma->order_per_bit)) - 1;
+ return (1UL << (align_order >> cma->order_per_bit)) - 1;
}
static unsigned long cma_bitmap_maxno(struct cma *cma)
@@ -171,7 +171,7 @@ static unsigned long cma_bitmap_maxno(st
static unsigned long cma_bitmap_pages_to_bits(struct cma *cma,
unsigned long pages)
{
- return ALIGN(pages, 1 << cma->order_per_bit) >> cma->order_per_bit;
+ return ALIGN(pages, 1UL << cma->order_per_bit) >> cma->order_per_bit;
}
static void cma_clear_bitmap(struct cma *cma, unsigned long pfn, int count)
_
^ permalink raw reply
* Re: [RFC PATCH V3 14/17] ppc/pci: create/release dev-tree node for VFs
From: Benjamin Herrenschmidt @ 2014-06-18 20:51 UTC (permalink / raw)
To: Wei Yang
Cc: linux-pci@vger.kernel.org, gwshan, Mike Qiu, Bjorn Helgaas, yan,
linuxppc-dev@lists.ozlabs.org
In-Reply-To: <CACxGe6v6Rdd=GQ8qR5LQ64NThidn7kn3WkKFkOXOsNuWq75D-A@mail.gmail.com>
On Wed, 2014-06-18 at 19:26 +0100, Grant Likely wrote:
> I don't think this is the right way to handle this. Unless it is a
> fixup to a buggy devicetree provided by firmware, I don't want to see
> any code modifying the devicetree to describe stuff that is able to be
> directly enumerated. Really the pci code should handle the lack of a
> device_node gracefully. If it cannot then it should be fixed.
Right, I've long said that we need to get rid of that "pci_dn" structure
we've been carrying around forever on ppc64.
Any auxiliary data structures we keep around associated with a PCI
device should be pointed to by the pci_dev itself, possibly using
firmware_data or similar.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH v3 -next 0/9] CMA: generalize CMA reserved area management code
From: Andrew Morton @ 2014-06-18 20:51 UTC (permalink / raw)
To: Joonsoo Kim
Cc: kvm-ppc, Russell King - ARM Linux, kvm, linux-mm, Gleb Natapov,
Greg Kroah-Hartman, Alexander Graf, Michal Nazarewicz,
linux-kernel, Minchan Kim, Paul Mackerras, Aneesh Kumar K.V,
Paolo Bonzini, Zhang Yanfei, linuxppc-dev, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20140617012507.GA6825@js1304-P5Q-DELUXE>
On Tue, 17 Jun 2014 10:25:07 +0900 Joonsoo Kim <iamjoonsoo.kim@lge.com> wrote:
> > >v2:
> > > - Although this patchset looks very different with v1, the end result,
> > > that is, mm/cma.c is same with v1's one. So I carry Ack to patch 6-7.
> > >
> > >This patchset is based on linux-next 20140610.
> >
> > Thanks for taking care of this. I will test it with my setup and if
> > everything goes well, I will take it to my -next tree. If any branch
> > is required for anyone to continue his works on top of those patches,
> > let me know, I will also prepare it.
>
> Hello,
>
> I'm glad to hear that. :)
> But, there is one concern. As you already know, I am preparing further
> patches (Aggressively allocate the pages on CMA reserved memory). It
> may be highly related to MM branch and also slightly depends on this CMA
> changes. In this case, what is the best strategy to merge this
> patchset? IMHO, Anrew's tree is more appropriate branch. If there is
> no issue in this case, I am willing to develope further patches based
> on your tree.
That's probably easier. Marek, I'll merge these into -mm (and hence
-next and git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git)
and shall hold them pending you review/ack/test/etc, OK?
^ permalink raw reply
* Re: [PATCH] powerpc: module: fix TOC symbol CRC
From: Anton Blanchard @ 2014-06-18 23:44 UTC (permalink / raw)
To: Laurent Dufour, rusty; +Cc: linuxppc-dev
In-Reply-To: <20140617155658.30560.578.stgit@nimbus>
Hi Laurent,
> The commit 71ec7c55ed91 introduced the magic symbol ".TOC." for ELFv2
> ABI. This symbol is built manually and has no CRC value computed. A
> zero value is put in the CRC section to avoid modpost complaining
> about a missing CRC. Unfortunately, this breaks the kernel module
> loading when the kernel is relocated (kdump case for instance)
> because of the relocation applied to the kcrctab values.
>
> This patch compute a CRC value for the TOC symbol which will match
> the one compute by the kernel when it is relocated - aka '0 -
> relocate_start' done in maybe_relocated called by check_version
> (module.c).
Adding Rusty since he maintains the module loader code.
Anton
> Signed-off-by: Laurent Dufour <ldufour@linux.vnet.ibm.com>
> Cc: Anton Blanchard <anton@samba.org>
> ---
> arch/powerpc/kernel/module_64.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/module_64.c
> b/arch/powerpc/kernel/module_64.c index 077d2ce..a80c933 100644
> --- a/arch/powerpc/kernel/module_64.c
> +++ b/arch/powerpc/kernel/module_64.c
> @@ -315,8 +315,15 @@ static void dedotify_versions(struct
> modversion_info *vers, struct modversion_info *end;
>
> for (end = (void *)vers + size; vers < end; vers++)
> - if (vers->name[0] == '.')
> + if (vers->name[0] == '.') {
> memmove(vers->name, vers->name+1, strlen(vers->name));
> + /* The TOC symbol has no CRC computed. To avoid CRC
> + * check failing, we must force it to the expected
> + * value (see CRC check in module.c).
> + */
> + if (!strcmp(vers->name, "TOC."))
> + vers->crc = -(unsigned long)reloc_start;
> + }
> }
>
> /* Undefined symbols which refer to .funcname, hack to funcname
> (or .TOC.) */
^ permalink raw reply
* Re: [PATCH] vfio: Fix endianness handling for emulated BARs
From: Alexey Kardashevskiy @ 2014-06-19 0:50 UTC (permalink / raw)
To: Alex Williamson
Cc: kvm, Nikunj A Dadhania, linux-kernel, Alexander Graf,
linuxppc-dev
In-Reply-To: <1403116512.3707.175.camel@ul30vt.home>
On 06/19/2014 04:35 AM, Alex Williamson wrote:
> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
>> VFIO exposes BARs to user space as a byte stream so userspace can
>> read it using pread()/pwrite(). Since this is a byte stream, VFIO should
>> not do byte swapping and simply return values as it gets them from
>> PCI device.
>>
>> Instead, the existing code assumes that byte stream in read/write is
>> little-endian and it fixes endianness for values which it passes to
>> ioreadXX/iowriteXX helpers. This works for little-endian as PCI is
>> little endian and le32_to_cpu/... are stubs.
>
> vfio read32:
>
> val = cpu_to_le32(ioread32(io + off));
>
> Where the typical x86 case, ioread32 is:
>
> #define ioread32(addr) readl(addr)
>
> and readl is:
>
> __le32_to_cpu(__raw_readl(addr));
>
> So we do canceling byte swaps, which are both nops on x86, and end up
> returning device endian, which we assume is little endian.
>
> vfio write32 is similar:
>
> iowrite32(le32_to_cpu(val), io + off);
>
> The implicit cpu_to_le32 of iowrite32() and our explicit swap cancel
> out, so input data is device endian, which is assumed little.
>
>> This also works for big endian but rather by an accident: it reads 4 bytes
>> from the stream (@val is big endian), converts to CPU format (which should
>> be big endian) as it was little endian (@val becomes actually little
>> endian) and calls iowrite32() which does not do swapping on big endian
>> system.
>
> Really?
>
> In arch/powerpc/kernel/iomap.c iowrite32() is just a wrapper around
> writel(), which seems to use the generic implementation, which does
> include a cpu_to_le32.
Ouch, wrong comment. iowrite32() does swapping. My bad.
>
> I also see other big endian archs like parisc doing cpu_to_le32 on
> iowrite32, so I don't think this statement is true. I imagine it's
> probably working for you because the swap cancel.
>
>> This removes byte swapping and makes use ioread32be/iowrite32be
>> (and 16bit versions) on big-endian systems. The "be" helpers take
>> native endian values and do swapping at the moment of writing to a PCI
>> register using one of "store byte-reversed" instructions.
>
> So now you want iowrite32() on little endian and iowrite32be() on big
> endian, the former does a cpu_to_le32 (which is a nop on little endian)
> and the latter does a cpu_to_be32 (which is a nop on big endian)...
> should we just be using __raw_writel() on both?
We can do that too. The beauty of iowrite32be on ppc64 is that it does not
swap and write separately, it is implemented via the "Store Word
Byte-Reverse Indexed X-form" single instruction.
And some archs (do not know which ones) may add memory barriers in their
implementations of ioread/iowrite. __raw_writel is too raw :)
> There doesn't actually
> seem to be any change in behavior here, it just eliminates back-to-back
> byte swaps, which are a nop on x86, but not power, right?
Exactly. No dependency for QEMU.
>
>> Suggested-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
>> ---
>> drivers/vfio/pci/vfio_pci_rdwr.c | 20 ++++++++++++++++----
>> 1 file changed, 16 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
>> index 210db24..f363b5a 100644
>> --- a/drivers/vfio/pci/vfio_pci_rdwr.c
>> +++ b/drivers/vfio/pci/vfio_pci_rdwr.c
>> @@ -21,6 +21,18 @@
>>
>> #include "vfio_pci_private.h"
>>
>> +#ifdef __BIG_ENDIAN__
>> +#define ioread16_native ioread16be
>> +#define ioread32_native ioread32be
>> +#define iowrite16_native iowrite16be
>> +#define iowrite32_native iowrite32be
>> +#else
>> +#define ioread16_native ioread16
>> +#define ioread32_native ioread32
>> +#define iowrite16_native iowrite16
>> +#define iowrite32_native iowrite32
>> +#endif
>> +
>> /*
>> * Read or write from an __iomem region (MMIO or I/O port) with an excluded
>> * range which is inaccessible. The excluded range drops writes and fills
>> @@ -50,9 +62,9 @@ static ssize_t do_io_rw(void __iomem *io, char __user *buf,
>> if (copy_from_user(&val, buf, 4))
>> return -EFAULT;
>>
>> - iowrite32(le32_to_cpu(val), io + off);
>> + iowrite32_native(val, io + off);
>> } else {
>> - val = cpu_to_le32(ioread32(io + off));
>> + val = ioread32_native(io + off);
>>
>> if (copy_to_user(buf, &val, 4))
>> return -EFAULT;
>> @@ -66,9 +78,9 @@ static ssize_t do_io_rw(void __iomem *io, char __user *buf,
>> if (copy_from_user(&val, buf, 2))
>> return -EFAULT;
>>
>> - iowrite16(le16_to_cpu(val), io + off);
>> + iowrite16_native(val, io + off);
>> } else {
>> - val = cpu_to_le16(ioread16(io + off));
>> + val = ioread16_native(io + off);
>>
>> if (copy_to_user(buf, &val, 2))
>> return -EFAULT;
>
>
>
--
Alexey
^ permalink raw reply
* Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64
From: Michael Ellerman @ 2014-06-19 1:30 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: Jeremy Fitzhardinge, linux-ia64, sparse,
Linux Kernel Mailing List, Paul Mackerras, H. Peter Anvin,
Thomas Gleixner, linux-tip-commits, anil.s.keshavamurthy,
Ingo Molnar, Suzuki K. Poulose, Fenghua Yu, Arnd Bergmann,
Rusty Russell, Chris Wright, yrl.pp-manager.tt, akataria,
Tony Luck, Kevin Hao, linuxppc-dev, rdunlap, Tony Luck, dl9pf,
Andrew Morton, Linus Torvalds, David S. Miller
In-Reply-To: <53A15201.7060404@hitachi.com>
On Wed, 2014-06-18 at 17:46 +0900, Masami Hiramatsu wrote:
> (2014/06/18 16:56), Michael Ellerman wrote:
> > On Fri, 2014-06-06 at 15:38 +0900, Masami Hiramatsu wrote:
> >> Ping?
> >>
> >> I guess this should go to 3.16 branch, shouldn't it?
> >
> >>> diff --git a/arch/powerpc/include/asm/types.h b/arch/powerpc/include/asm/types.h
> >>> index bfb6ded..8b89d65 100644
> >>> --- a/arch/powerpc/include/asm/types.h
> >>> +++ b/arch/powerpc/include/asm/types.h
> >>> @@ -25,6 +25,17 @@ typedef struct {
> >>> unsigned long env;
> >>> } func_descr_t;
> >>>
> >>> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> >>> +/*
> >>> + * On PPC64 ABIv1 the function pointer actually points to the
> >>> + * function's descriptor. The first entry in the descriptor is the
> >>> + * address of the function text.
> >>> + */
> >>> +#define function_entry(fn) (((func_descr_t *)(fn))->entry)
> >>> +#else
> >>> +#define function_entry(fn) ((unsigned long)(fn))
> >>> +#endif
> >
> > We already have ppc_function_entry(), can't you use that?
>
> I'd like to ask you whether the address which ppc_function_entry() returns on
> PPC ABIv2 is really same address in kallsyms or not.
> As you can see, kprobes uses function_entry() to get the actual entry address
> where kallsyms knows. I have not much information about that, but it seems that
> the "global entry point" is the address which kallsyms knows, isn't it?
OK. I'm not sure off the top of my head which address kallsyms knows about, but
yes it's likely that it is the global entry point.
I recently sent a patch to add ppc_global_function_entry(), because we need it
in the ftrace code. Once that is merged you could use that.
How do you hit the original problem, you don't actually specify in your commit
message? Something with kprobes obviously, but what exactly? I'll try and
reproduce it here.
cheers
^ permalink raw reply
* Re: Boot failure in Power7 pSeries
From: Michael Ellerman @ 2014-06-19 1:32 UTC (permalink / raw)
To: Mike Qiu; +Cc: linuxppc-dev
In-Reply-To: <53A155A6.2030805@linux.vnet.ibm.com>
On Wed, 2014-06-18 at 17:02 +0800, Mike Qiu wrote:
> On 06/18/2014 03:54 PM, Michael Ellerman wrote:
> > On Wed, 2014-06-18 at 11:27 +0800, Mike Qiu wrote:
> >> Anyone has a idea on this issue?
> > Did it ever work? If so which kernel version?
> It works for 3.15, but failed with linux version 3.16.0-rc1-next-20140617
What about 3.16-rc1 ?
> The config file can be simply get from /boot/configxxx. and "make
> menuconfig" and save without change anything(default).
Sure, but I don't have access to your box so please ..
> > Can you attach your actual .config.
^^^^
> > You could try building without CONFIG_PPC_POWERNV.
>
> Trying...., but it should work as default config from /boot/
Well yes that would be nice, but I'm trying to help you narrow down what the
problem is.
cheers
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox