* [PATCH v2 0/5] dmaengine: convert dw_dmac/spear13xx to generic binding
From: Arnd Bergmann @ 2013-01-28 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359395857-1235-1-git-send-email-arnd@arndb.de>
Hi everyone,
I'm rather embarrassed to have sent yet another patch series
to the wrong mailing list address, this now goes to the
correct linux-arm-kernel list, so please comment here,
not on the first version. I have also made some smaller
changes and updated the DT bindings where I extended
the drivers. I also uploaded the git branch to the
spear/dma branch of
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
This is my attempt to convert the spear platform and the dw_dmac to
the generic device tree binding for DMA, so that we don't get
a release with the broken version. I'm pretty sure that this
has bugs, but it's as good as I could do without access to
hardware or specs.
Please review and comment,
Arnd
Arnd Bergmann (5):
dmaengine: dw_dmac: move to generic DMA binding
spi: pl022: use generic DMA slave configuration if possible
serial: pl011: use generic DMA slave configuration if possible
ata: arasan: remove the need for platform_data
ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT
.../devicetree/bindings/ata/pata-arasan.txt | 22 ++++
Documentation/devicetree/bindings/dma/snps-dma.txt | 70 +++++------
arch/arm/boot/dts/spear1340.dtsi | 2 +
arch/arm/boot/dts/spear13xx.dtsi | 25 +++-
arch/arm/mach-spear/generic.h | 6 -
arch/arm/mach-spear/include/mach/spear.h | 2 -
arch/arm/mach-spear/spear1310.c | 30 +----
arch/arm/mach-spear/spear1340.c | 32 +----
arch/arm/mach-spear/spear13xx-dma.h | 128 --------------------
arch/arm/mach-spear/spear13xx.c | 58 ---------
drivers/ata/pata_arasan_cf.c | 31 +++--
drivers/dma/dw_dmac.c | 130 ++++++++++-----------
drivers/dma/dw_dmac_regs.h | 4 -
drivers/spi/spi-pl022.c | 43 ++++++-
drivers/tty/serial/amba-pl011.c | 62 ++++++----
include/linux/dw_dmac.h | 5 -
include/linux/pata_arasan_cf_data.h | 2 -
17 files changed, 243 insertions(+), 409 deletions(-)
delete mode 100644 arch/arm/mach-spear/spear13xx-dma.h
--
1.8.0
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Jon Hunter <jon-hunter@ti.com>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: spi-devel-general at lists.sourceforge.net
^ permalink raw reply
* [PATCH 1/5] dmaengine: dw_dmac: move to generic DMA binding
From: Arnd Bergmann @ 2013-01-28 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359410300-26113-1-git-send-email-arnd@arndb.de>
The original device tree binding for this driver, from Viresh Kumar
unfortunately conflicted with the generic DMA binding, and did not allow
to completely seperate slave device configuration from the controller.
This is an attempt to replace it with an implementation of the generic
binding, but it is currently completely untested, because I do not have
any hardware with this particular controller.
The patch applies on top of linux-next, which contains both the base
support for the generic DMA binding, as well as the earlier attempt from
Viresh. Both of these are currently not merged upstream however.
There are a couple of TODO items that are left remaining and are open
for ideas from other people.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
---
Documentation/devicetree/bindings/dma/snps-dma.txt | 71 ++++++-----
drivers/dma/dw_dmac.c | 137 ++++++++++-----------
drivers/dma/dw_dmac_regs.h | 4 -
include/linux/dw_dmac.h | 5 -
4 files changed, 102 insertions(+), 115 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/snps-dma.txt b/Documentation/devicetree/bindings/dma/snps-dma.txt
index 5bb3dfb..212d387 100644
--- a/Documentation/devicetree/bindings/dma/snps-dma.txt
+++ b/Documentation/devicetree/bindings/dma/snps-dma.txt
@@ -3,59 +3,62 @@
Required properties:
- compatible: "snps,dma-spear1340"
- reg: Address range of the DMAC registers
-- interrupt-parent: Should be the phandle for the interrupt controller
- that services interrupts for this device
- interrupt: Should contain the DMAC interrupt number
-- nr_channels: Number of channels supported by hardware
-- is_private: The device channels should be marked as private and not for by the
- general purpose DMA channel allocator. False if not passed.
+- dma-channels: Number of channels supported by hardware
+- dma-requests: Number of DMA request lines supported
+- dma-masters: Number of AHB masters supported by the controller
+- #dma-cells: must be <3>
- chan_allocation_order: order of allocation of channel, 0 (default): ascending,
1: descending
- chan_priority: priority of channels. 0 (default): increase from chan 0->n, 1:
increase from chan n->0
- block_size: Maximum block size supported by the controller
-- nr_masters: Number of AHB masters supported by the controller
- data_width: Maximum data width supported by hardware per AHB master
(0 - 8bits, 1 - 16bits, ..., 5 - 256bits)
-- slave_info:
- - bus_id: name of this device channel, not just a device name since
- devices may have more than one channel e.g. "foo_tx". For using the
- dw_generic_filter(), slave drivers must pass exactly this string as
- param to filter function.
- - cfg_hi: Platform-specific initializer for the CFG_HI register
- - cfg_lo: Platform-specific initializer for the CFG_LO register
- - src_master: src master for transfers on allocated channel.
- - dst_master: dest master for transfers on allocated channel.
+
+
+Optional properties:
+- interrupt-parent: Should be the phandle for the interrupt controller
+ that services interrupts for this device
+- is_private: The device channels should be marked as private and not for by the
+ general purpose DMA channel allocator. False if not passed.
Example:
- dma at fc000000 {
+ dmahost: dma at fc000000 {
compatible = "snps,dma-spear1340";
reg = <0xfc000000 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
- nr_channels = <8>;
+ dma-channels = <8>;
+ dma-requests = <32>;
+ dma-masters = <2>;
+ #dma-cells = <3>;
chan_allocation_order = <1>;
chan_priority = <1>;
block_size = <0xfff>;
- nr_masters = <2>;
data_width = <3 3 0 0>;
+ };
- slave_info {
- uart0-tx {
- bus_id = "uart0-tx";
- cfg_hi = <0x4000>; /* 0x8 << 11 */
- cfg_lo = <0>;
- src_master = <0>;
- dst_master = <1>;
- };
- spi0-tx {
- bus_id = "spi0-tx";
- cfg_hi = <0x2000>; /* 0x4 << 11 */
- cfg_lo = <0>;
- src_master = <0>;
- dst_master = <0>;
- };
- };
+DMA clients connected to the Designware DMA controller must use the format
+described in the dma.txt file, using a five-cell specifier for each channel.
+The five cells in order are:
+
+1. A phandle pointing to the DMA controller
+2. The value for the cfg_hi register.
+3. The value for the cfg_lo register.
+4. Source master for transfers on allocated channel.
+5. Destination master for transfers on allocated channel.
+
+Example:
+
+ serial at e0000000 {
+ compatible = "arm,pl011", "arm,primecell";
+ reg = <0xe0000000 0x1000>;
+ interrupts = <0 35 0x4>;
+ status = "disabled";
+ dmas = <&dmahost 0x6000 0 0 1>,
+ <&dmahost 0x680 0 1 0>;
+ dma-names = "rx", "rx";
};
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 8cfaaf8..88504c2 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -18,6 +18,7 @@
#include <linux/interrupt.h>
#include <linux/io.h>
#include <linux/of.h>
+#include <linux/of_dma.h>
#include <linux/mm.h>
#include <linux/module.h>
#include <linux/platform_device.h>
@@ -1179,49 +1180,69 @@ static void dwc_free_chan_resources(struct dma_chan *chan)
dev_vdbg(chan2dev(chan), "%s: done\n", __func__);
}
-bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
+/* forward declaration used in filter */
+static struct platform_driver dw_driver;
+
+struct dw_dma_filter_args {
+ struct dw_dma *dw;
+ u32 cfg_lo;
+ u32 cfg_hi;
+ unsigned src;
+ unsigned dst;
+};
+
+static bool dw_dma_generic_filter(struct dma_chan *chan, void *param)
{
struct dw_dma *dw = to_dw_dma(chan->device);
- static struct dw_dma *last_dw;
- static char *last_bus_id;
- int i = -1;
+ struct dw_dma_filter_args *fargs = param;
+ struct dw_dma_slave *sd;
- /*
- * dmaengine framework calls this routine for all channels of all dma
- * controller, until true is returned. If 'param' bus_id is not
- * registered with a dma controller (dw), then there is no need of
- * running below function for all channels of dw.
- *
- * This block of code does this by saving the parameters of last
- * failure. If dw and param are same, i.e. trying on same dw with
- * different channel, return false.
- */
- if ((last_dw == dw) && (last_bus_id == param))
+ /* both the driver and the device must match */
+ if (chan->device->dev->driver != &dw_driver.driver)
+ return false;
+ if (dw != fargs->dw)
return false;
- /*
- * Return true:
- * - If dw_dma's platform data is not filled with slave info, then all
- * dma controllers are fine for transfer.
- * - Or if param is NULL
- */
- if (!dw->sd || !param)
- return true;
- while (++i < dw->sd_count) {
- if (!strcmp(dw->sd[i].bus_id, param)) {
- chan->private = &dw->sd[i];
- last_dw = NULL;
- last_bus_id = NULL;
+ /* FIXME: memory leak! could we put this into dw_dma_chan? */
+ sd = devm_kzalloc(dw->dma.dev, sizeof (*sd), GFP_KERNEL);
+ if (!sd)
+ return false;
- return true;
- }
- }
+ sd->dma_dev = dw->dma.dev;
+ sd->cfg_hi = fargs->cfg_hi;
+ sd->cfg_lo = fargs->cfg_lo;
+ sd->src_master = fargs->src;
+ sd->dst_master = fargs->dst;
+
+ chan->private = sd;
- last_dw = dw;
- last_bus_id = param;
- return false;
+ return true;
+}
+
+static struct dma_chan *dw_dma_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct dw_dma *dw = ofdma->of_dma_data;
+ struct dw_dma_filter_args fargs = {
+ .dw = dw,
+ };
+ dma_cap_mask_t cap;
+
+ if (dma_spec->args_count != 4)
+ return NULL;
+
+ /* FIXME: This binding is rather clumsy. Can't we use the
+ request line numbers here instead? */
+ fargs.cfg_lo = be32_to_cpup(dma_spec->args+0);
+ fargs.cfg_hi = be32_to_cpup(dma_spec->args+1);
+ fargs.src = be32_to_cpup(dma_spec->args+2);
+ fargs.dst = be32_to_cpup(dma_spec->args+3);
+
+ dma_cap_zero(cap);
+ dma_cap_set(DMA_SLAVE, cap);
+ /* FIXME: there should be a simpler way to do this */
+ return dma_request_channel(cap, dw_dma_generic_filter, &dma_spec->args[0]);
}
-EXPORT_SYMBOL(dw_dma_generic_filter);
/* --------------------- Cyclic DMA API extensions -------------------- */
@@ -1510,9 +1531,8 @@ static void dw_dma_off(struct dw_dma *dw)
static struct dw_dma_platform_data *
dw_dma_parse_dt(struct platform_device *pdev)
{
- struct device_node *sn, *cn, *np = pdev->dev.of_node;
+ struct device_node *np = pdev->dev.of_node;
struct dw_dma_platform_data *pdata;
- struct dw_dma_slave *sd;
u32 tmp, arr[4];
if (!np) {
@@ -1524,7 +1544,7 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (!pdata)
return NULL;
- if (of_property_read_u32(np, "nr_channels", &pdata->nr_channels))
+ if (of_property_read_u32(np, "dma-channels", &pdata->nr_channels))
return NULL;
if (of_property_read_bool(np, "is_private"))
@@ -1539,7 +1559,7 @@ dw_dma_parse_dt(struct platform_device *pdev)
if (!of_property_read_u32(np, "block_size", &tmp))
pdata->block_size = tmp;
- if (!of_property_read_u32(np, "nr_masters", &tmp)) {
+ if (!of_property_read_u32(np, "dma-masters", &tmp)) {
if (tmp > 4)
return NULL;
@@ -1551,36 +1571,6 @@ dw_dma_parse_dt(struct platform_device *pdev)
for (tmp = 0; tmp < pdata->nr_masters; tmp++)
pdata->data_width[tmp] = arr[tmp];
- /* parse slave data */
- sn = of_find_node_by_name(np, "slave_info");
- if (!sn)
- return pdata;
-
- /* calculate number of slaves */
- tmp = of_get_child_count(sn);
- if (!tmp)
- return NULL;
-
- sd = devm_kzalloc(&pdev->dev, sizeof(*sd) * tmp, GFP_KERNEL);
- if (!sd)
- return NULL;
-
- pdata->sd = sd;
- pdata->sd_count = tmp;
-
- for_each_child_of_node(sn, cn) {
- sd->dma_dev = &pdev->dev;
- of_property_read_string(cn, "bus_id", &sd->bus_id);
- of_property_read_u32(cn, "cfg_hi", &sd->cfg_hi);
- of_property_read_u32(cn, "cfg_lo", &sd->cfg_lo);
- if (!of_property_read_u32(cn, "src_master", &tmp))
- sd->src_master = tmp;
-
- if (!of_property_read_u32(cn, "dst_master", &tmp))
- sd->dst_master = tmp;
- sd++;
- }
-
return pdata;
}
#else
@@ -1644,8 +1634,6 @@ static int dw_probe(struct platform_device *pdev)
clk_prepare_enable(dw->clk);
dw->regs = regs;
- dw->sd = pdata->sd;
- dw->sd_count = pdata->sd_count;
/* get hardware configuration parameters */
if (autocfg) {
@@ -1765,7 +1753,11 @@ static int dw_probe(struct platform_device *pdev)
dma_async_device_register(&dw->dma);
- return 0;
+ err = of_dma_controller_register(pdev->dev.of_node, dw_dma_xlate, dw);
+ if (err)
+ dma_async_device_unregister(&dw->dma);
+
+ return err;
}
static int dw_remove(struct platform_device *pdev)
@@ -1773,6 +1765,7 @@ static int dw_remove(struct platform_device *pdev)
struct dw_dma *dw = platform_get_drvdata(pdev);
struct dw_dma_chan *dwc, *_dwc;
+ of_dma_controller_free(pdev->dev.of_node);
dw_dma_off(dw);
dma_async_device_unregister(&dw->dma);
diff --git a/drivers/dma/dw_dmac_regs.h b/drivers/dma/dw_dmac_regs.h
index 88a069f..8896559 100644
--- a/drivers/dma/dw_dmac_regs.h
+++ b/drivers/dma/dw_dmac_regs.h
@@ -239,10 +239,6 @@ struct dw_dma {
struct tasklet_struct tasklet;
struct clk *clk;
- /* slave information */
- struct dw_dma_slave *sd;
- unsigned int sd_count;
-
u8 all_chan_mask;
/* hardware configuration */
diff --git a/include/linux/dw_dmac.h b/include/linux/dw_dmac.h
index 41766de..481ab23 100644
--- a/include/linux/dw_dmac.h
+++ b/include/linux/dw_dmac.h
@@ -27,7 +27,6 @@
*/
struct dw_dma_slave {
struct device *dma_dev;
- const char *bus_id;
u32 cfg_hi;
u32 cfg_lo;
u8 src_master;
@@ -60,9 +59,6 @@ struct dw_dma_platform_data {
unsigned short block_size;
unsigned char nr_masters;
unsigned char data_width[4];
-
- struct dw_dma_slave *sd;
- unsigned int sd_count;
};
/* bursts size */
@@ -114,6 +110,5 @@ void dw_dma_cyclic_stop(struct dma_chan *chan);
dma_addr_t dw_dma_get_src_addr(struct dma_chan *chan);
dma_addr_t dw_dma_get_dst_addr(struct dma_chan *chan);
-bool dw_dma_generic_filter(struct dma_chan *chan, void *param);
#endif /* DW_DMAC_H */
--
1.8.0
^ permalink raw reply related
* [PATCH 2/5] spi: pl022: use generic DMA slave configuration if possible
From: Arnd Bergmann @ 2013-01-28 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359410300-26113-1-git-send-email-arnd@arndb.de>
With the new OF DMA binding, it is possible to completely avoid the
need for platform_data for configuring a DMA channel. In cases where the
platform has already been converted, calling dma_request_slave_channel
should get all the necessary information from the device tree.
Like the patch that converts the dw_dma controller, this is completely
untested and is looking for someone to try it out.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: spi-devel-general at lists.sourceforge.net
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
---
.../devicetree/bindings/spi/spi_pl022.txt | 36 ++++++++++++++++++
drivers/spi/spi-pl022.c | 43 +++++++++++++++++++++-
2 files changed, 77 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/spi/spi_pl022.txt b/Documentation/devicetree/bindings/spi/spi_pl022.txt
index f158fd3..22ed679 100644
--- a/Documentation/devicetree/bindings/spi/spi_pl022.txt
+++ b/Documentation/devicetree/bindings/spi/spi_pl022.txt
@@ -16,6 +16,11 @@ Optional properties:
device will be suspended immediately
- pl022,rt : indicates the controller should run the message pump with realtime
priority to minimise the transfer latency on the bus (boolean)
+- dmas : Two or more DMA channel specifiers following the convention outlined
+ in bindings/dma/dma.txt
+- dma-names: Names for the dma channels, if present. There must be at
+ least one channel named "tx" for transmit and named "rx" for
+ receive.
SPI slave nodes must be children of the SPI master node and can
@@ -32,3 +37,34 @@ contain the following properties.
- pl022,wait-state : Microwire interface: Wait state
- pl022,duplex : Microwire interface: Full/Half duplex
+
+Example:
+
+ spi at e0100000 {
+ compatible = "arm,pl022", "arm,primecell";
+ reg = <0xe0100000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ interrupts = <0 31 0x4>;
+ dmas = <&dma-controller 23 1>,
+ <&dma-controller 24 0>;
+ dma-names = "rx", "tx";
+
+ m25p80 at 1 {
+ compatible = "st,m25p80";
+ reg = <1>;
+ spi-max-frequency = <12000000>;
+ spi-cpol;
+ spi-cpha;
+ pl022,hierarchy = <0>;
+ pl022,interface = <0>;
+ pl022,slave-tx-disable;
+ pl022,com-mode = <0x2>;
+ pl022,rx-level-trig = <0>;
+ pl022,tx-level-trig = <0>;
+ pl022,ctrl-len = <0x11>;
+ pl022,wait-state = <0>;
+ pl022,duplex = <0>;
+ };
+ };
+
diff --git a/drivers/spi/spi-pl022.c b/drivers/spi/spi-pl022.c
index b0fe393..371cc66f 100644
--- a/drivers/spi/spi-pl022.c
+++ b/drivers/spi/spi-pl022.c
@@ -1139,6 +1139,35 @@ err_no_rxchan:
return -ENODEV;
}
+static int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+ struct device *dev = &pl022->adev->dev;
+
+ /* automatically configure DMA channels from platform, normally using DT */
+ pl022->dma_rx_channel = dma_request_slave_channel(dev, "rx");
+ if (!pl022->dma_rx_channel)
+ goto err_no_rxchan;
+
+ pl022->dma_tx_channel = dma_request_slave_channel(dev, "tx");
+ if (!pl022->dma_tx_channel)
+ goto err_no_txchan;
+
+ pl022->dummypage = kmalloc(PAGE_SIZE, GFP_KERNEL);
+ if (!pl022->dummypage)
+ goto err_no_dummypage;
+
+ return 0;
+
+err_no_dummypage:
+ dma_release_channel(pl022->dma_tx_channel);
+ pl022->dma_tx_channel = NULL;
+err_no_txchan:
+ dma_release_channel(pl022->dma_rx_channel);
+ pl022->dma_rx_channel = NULL;
+err_no_rxchan:
+ return -ENODEV;
+}
+
static void terminate_dma(struct pl022 *pl022)
{
struct dma_chan *rxchan = pl022->dma_rx_channel;
@@ -1167,6 +1196,11 @@ static inline int configure_dma(struct pl022 *pl022)
return -ENODEV;
}
+static inline int pl022_dma_autoprobe(struct pl022 *pl022)
+{
+ return 0;
+}
+
static inline int pl022_dma_probe(struct pl022 *pl022)
{
return 0;
@@ -2226,8 +2260,13 @@ static int pl022_probe(struct amba_device *adev, const struct amba_id *id)
goto err_no_irq;
}
- /* Get DMA channels */
- if (platform_info->enable_dma) {
+ /* Get DMA channels, try autoconfiguration first */
+ status = pl022_dma_autoprobe(pl022);
+
+ /* If that failed, use channels from platform_info */
+ if (status == 0)
+ platform_info->enable_dma = 1;
+ else if (platform_info->enable_dma) {
status = pl022_dma_probe(pl022);
if (status != 0)
platform_info->enable_dma = 0;
--
1.8.0
^ permalink raw reply related
* [PATCH 3/5] serial: pl011: use generic DMA slave configuration if possible
From: Arnd Bergmann @ 2013-01-28 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359410300-26113-1-git-send-email-arnd@arndb.de>
With the new OF DMA binding, it is possible to completely avoid the
need for platform_data for configuring a DMA channel. In cases where the
platform has already been converted, calling dma_request_slave_channel
should get all the necessary information from the device tree.
This also adds a binding document specific to the pl011 controller,
and extends the generic primecell binding to mention "dmas" and other
common properties.
Like the patch that converts the dw_dma controller, this is completely
untested and is looking for someone to try it out.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Grant Likely <grant.likely@secretlab.ca>
Cc: Jiri Slaby <jslaby@suse.cz>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Linus Walleij <linus.walleij@linaro.org>
Cc: spi-devel-general at lists.sourceforge.net
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Vinod Koul <vinod.koul@linux.intel.com>
Cc: devicetree-discuss at lists.ozlabs.org
Cc: linux-arm-kernel at lists.infradead.org
---
.../devicetree/bindings/arm/primecell.txt | 19 ++++++-
Documentation/devicetree/bindings/serial/pl011.txt | 17 ++++++
drivers/tty/serial/amba-pl011.c | 62 +++++++++++++---------
3 files changed, 72 insertions(+), 26 deletions(-)
create mode 100644 Documentation/devicetree/bindings/serial/pl011.txt
diff --git a/Documentation/devicetree/bindings/arm/primecell.txt b/Documentation/devicetree/bindings/arm/primecell.txt
index 64fc82b..0df6aca 100644
--- a/Documentation/devicetree/bindings/arm/primecell.txt
+++ b/Documentation/devicetree/bindings/arm/primecell.txt
@@ -16,14 +16,31 @@ Optional properties:
- clocks : From common clock binding. First clock is phandle to clock for apb
pclk. Additional clocks are optional and specific to those peripherals.
- clock-names : From common clock binding. Shall be "apb_pclk" for first clock.
+- dmas : From common DMA binding. If present, refers to one or more dma channels.
+- dma-names : From common DMA binding, needs to match the 'dmas' property.
+ Devices with exactly one receive and transmit channel shall name
+ these "rx" and "tx", respectively.
+- pinctrl-<n> : Pinctrl states as described in bindings/pinctrl/pinctrl-bindings.txt
+- pinctrl-names : Names corresponding to the numbered pinctrl states
+- interrupts : one or more interrupt specifiers
+- interrupt-names : names corresponding to the interrupts properties
Example:
serial at fff36000 {
compatible = "arm,pl011", "arm,primecell";
arm,primecell-periphid = <0x00341011>;
+
clocks = <&pclk>;
clock-names = "apb_pclk";
-
+
+ dmas = <&dma-controller 4>, <&dma-controller 5>;
+ dma-names = "rx", "tx";
+
+ pinctrl-0 = <&uart0_default_mux>, <&uart0_default_mode>;
+ pinctrl-1 = <&uart0_sleep_mode>;
+ pinctrl-names = "default","sleep";
+
+ interrupts = <0 11 0x4>;
};
diff --git a/Documentation/devicetree/bindings/serial/pl011.txt b/Documentation/devicetree/bindings/serial/pl011.txt
new file mode 100644
index 0000000..5d2e840
--- /dev/null
+++ b/Documentation/devicetree/bindings/serial/pl011.txt
@@ -0,0 +1,17 @@
+* ARM AMBA Primecell PL011 serial UART
+
+Required properties:
+- compatible: must be "arm,primecell", "arm,pl011"
+- reg: exactly one register range with length 0x1000
+- interrupts: exactly one interrupt specifier
+
+Optional properties:
+- pinctrl: When present, must have one state named "sleep"
+ and one state named "default"
+- clocks: When present, must refer to exactly one clock named
+ "apb_pclk"
+- dmas: When present, may have one or two dma channels.
+ The first one must be named "rx", the second one
+ must be named "tx".
+
+See also bindings/arm/primecell.txt
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index 7fca402..f9af04d 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -245,7 +245,7 @@ static void pl011_sgbuf_free(struct dma_chan *chan, struct pl011_sgbuf *sg,
}
}
-static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
+static void pl011_dma_probe_initcall(struct device *dev, struct uart_amba_port *uap)
{
/* DMA is the sole user of the platform data right now */
struct amba_pl011_data *plat = uap->port.dev->platform_data;
@@ -259,20 +259,25 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
struct dma_chan *chan;
dma_cap_mask_t mask;
- /* We need platform data */
- if (!plat || !plat->dma_filter) {
- dev_info(uap->port.dev, "no DMA platform data\n");
- return;
- }
+ chan = dma_request_slave_channel(dev, "tx");
- /* Try to acquire a generic DMA engine slave TX channel */
- dma_cap_zero(mask);
- dma_cap_set(DMA_SLAVE, mask);
-
- chan = dma_request_channel(mask, plat->dma_filter, plat->dma_tx_param);
if (!chan) {
- dev_err(uap->port.dev, "no TX DMA channel!\n");
- return;
+ /* We need platform data */
+ if (!plat || !plat->dma_filter) {
+ dev_info(uap->port.dev, "no DMA platform data\n");
+ return;
+ }
+
+ /* Try to acquire a generic DMA engine slave TX channel */
+ dma_cap_zero(mask);
+ dma_cap_set(DMA_SLAVE, mask);
+
+ chan = dma_request_channel(mask, plat->dma_filter,
+ plat->dma_tx_param);
+ if (!chan) {
+ dev_err(uap->port.dev, "no TX DMA channel!\n");
+ return;
+ }
}
dmaengine_slave_config(chan, &tx_conf);
@@ -282,7 +287,18 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
dma_chan_name(uap->dmatx.chan));
/* Optionally make use of an RX channel as well */
- if (plat->dma_rx_param) {
+ chan = dma_request_slave_channel(dev, "rx");
+
+ if (!chan && plat->dma_rx_param) {
+ chan = dma_request_channel(mask, plat->dma_filter, plat->dma_rx_param);
+
+ if (!chan) {
+ dev_err(uap->port.dev, "no RX DMA channel!\n");
+ return;
+ }
+ }
+
+ if (chan) {
struct dma_slave_config rx_conf = {
.src_addr = uap->port.mapbase + UART01x_DR,
.src_addr_width = DMA_SLAVE_BUSWIDTH_1_BYTE,
@@ -291,12 +307,6 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
.device_fc = false,
};
- chan = dma_request_channel(mask, plat->dma_filter, plat->dma_rx_param);
- if (!chan) {
- dev_err(uap->port.dev, "no RX DMA channel!\n");
- return;
- }
-
dmaengine_slave_config(chan, &rx_conf);
uap->dmarx.chan = chan;
@@ -315,6 +325,7 @@ static void pl011_dma_probe_initcall(struct uart_amba_port *uap)
struct dma_uap {
struct list_head node;
struct uart_amba_port *uap;
+ struct device *dev;
};
static LIST_HEAD(pl011_dma_uarts);
@@ -325,7 +336,7 @@ static int __init pl011_dma_initcall(void)
list_for_each_safe(node, tmp, &pl011_dma_uarts) {
struct dma_uap *dmau = list_entry(node, struct dma_uap, node);
- pl011_dma_probe_initcall(dmau->uap);
+ pl011_dma_probe_initcall(dmau->dev, dmau->uap);
list_del(node);
kfree(dmau);
}
@@ -334,18 +345,19 @@ static int __init pl011_dma_initcall(void)
device_initcall(pl011_dma_initcall);
-static void pl011_dma_probe(struct uart_amba_port *uap)
+static void pl011_dma_probe(struct device *dev, struct uart_amba_port *uap)
{
struct dma_uap *dmau = kzalloc(sizeof(struct dma_uap), GFP_KERNEL);
if (dmau) {
dmau->uap = uap;
+ dmau->dev = dev;
list_add_tail(&dmau->node, &pl011_dma_uarts);
}
}
#else
-static void pl011_dma_probe(struct uart_amba_port *uap)
+static void pl011_dma_probe(struct device *dev, struct uart_amba_port *uap)
{
- pl011_dma_probe_initcall(uap);
+ pl011_dma_probe_initcall(dev, uap);
}
#endif
@@ -2023,7 +2035,7 @@ static int pl011_probe(struct amba_device *dev, const struct amba_id *id)
uap->port.ops = &amba_pl011_pops;
uap->port.flags = UPF_BOOT_AUTOCONF;
uap->port.line = i;
- pl011_dma_probe(uap);
+ pl011_dma_probe(&dev->dev, uap);
/* Ensure interrupts from this UART are masked and cleared */
writew(0, uap->port.membase + UART011_IMSC);
--
1.8.0
^ permalink raw reply related
* [PATCH 4/5] ata: arasan: remove the need for platform_data
From: Arnd Bergmann @ 2013-01-28 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359410300-26113-1-git-send-email-arnd@arndb.de>
This adds a complete DT binding for the arasan device driver. There is
currently only one user, which is the spear13xx platform, so we don't
actually have to parse all the properties until another user comes in,
but this does use the generic DMA binding to find the DMA channel.
The patch is untested so far and is part of a series to convert
the spear platform over to use the generic DMA binding, so it
should stay with the rest of the series.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Viresh Kumar <viresh.linux@gmail.com>
Cc: Vinod Koul <vinod.koul@intel.com>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: devicetree-discuss at lists.ozlabs.org
---
.../devicetree/bindings/ata/pata-arasan.txt | 22 +++++++++++++
drivers/ata/pata_arasan_cf.c | 37 +++++++++++-----------
include/linux/pata_arasan_cf_data.h | 2 --
3 files changed, 41 insertions(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/ata/pata-arasan.txt b/Documentation/devicetree/bindings/ata/pata-arasan.txt
index 95ec7f8..2aff154 100644
--- a/Documentation/devicetree/bindings/ata/pata-arasan.txt
+++ b/Documentation/devicetree/bindings/ata/pata-arasan.txt
@@ -6,6 +6,26 @@ Required properties:
- interrupt-parent: Should be the phandle for the interrupt controller
that services interrupts for this device
- interrupt: Should contain the CF interrupt number
+- clock-frequency: Interface clock rate, in Hz, one of
+ 25000000
+ 33000000
+ 40000000
+ 50000000
+ 66000000
+ 75000000
+ 100000000
+ 125000000
+ 150000000
+ 166000000
+ 200000000
+
+Optional properties:
+- arasan,broken-udma: if present, UDMA mode is unusable
+- arasan,broken-mwdma: if present, MWDMA mode is unusable
+- arasan,broken-pio: if present, PIO mode is unusable
+- dmas: one DMA channel, as described in bindings/dma/dma.txt
+ required unless both UDMA and MWDMA mode are broken
+- dma-names: the corresponding channel name, must be "data"
Example:
@@ -14,4 +34,6 @@ Example:
reg = <0xfc000000 0x1000>;
interrupt-parent = <&vic1>;
interrupts = <12>;
+ dmas = <&dma-controller 23>;
+ dma-names = "data";
};
diff --git a/drivers/ata/pata_arasan_cf.c b/drivers/ata/pata_arasan_cf.c
index 405022d..7638121 100644
--- a/drivers/ata/pata_arasan_cf.c
+++ b/drivers/ata/pata_arasan_cf.c
@@ -209,8 +209,6 @@ struct arasan_cf_dev {
struct dma_chan *dma_chan;
/* Mask for DMA transfers */
dma_cap_mask_t mask;
- /* dma channel private data */
- void *dma_priv;
/* DMA transfer work */
struct work_struct work;
/* DMA delayed finish work */
@@ -308,6 +306,7 @@ static void cf_card_detect(struct arasan_cf_dev *acdev, bool hotplugged)
static int cf_init(struct arasan_cf_dev *acdev)
{
struct arasan_cf_pdata *pdata = dev_get_platdata(acdev->host->dev);
+ unsigned int if_clk;
unsigned long flags;
int ret = 0;
@@ -325,8 +324,12 @@ static int cf_init(struct arasan_cf_dev *acdev)
spin_lock_irqsave(&acdev->host->lock, flags);
/* configure CF interface clock */
- writel((pdata->cf_if_clk <= CF_IF_CLK_200M) ? pdata->cf_if_clk :
- CF_IF_CLK_166M, acdev->vbase + CLK_CFG);
+ /* TODO: read from device tree */
+ if_clk = CF_IF_CLK_166M;
+ if (pdata && pdata->cf_if_clk <= CF_IF_CLK_200M)
+ if_clk = pdata->cf_if_clk;
+
+ writel(if_clk, acdev->vbase + CLK_CFG);
writel(TRUE_IDE_MODE | CFHOST_ENB, acdev->vbase + OP_MODE);
cf_interrupt_enable(acdev, CARD_DETECT_IRQ, 1);
@@ -357,12 +360,6 @@ static void dma_callback(void *dev)
complete(&acdev->dma_completion);
}
-static bool filter(struct dma_chan *chan, void *slave)
-{
- chan->private = slave;
- return true;
-}
-
static inline void dma_complete(struct arasan_cf_dev *acdev)
{
struct ata_queued_cmd *qc = acdev->qc;
@@ -530,8 +527,7 @@ static void data_xfer(struct work_struct *work)
/* request dma channels */
/* dma_request_channel may sleep, so calling from process context */
- acdev->dma_chan = dma_request_channel(acdev->mask, filter,
- acdev->dma_priv);
+ acdev->dma_chan = dma_request_slave_channel(acdev->host->dev, "data");
if (!acdev->dma_chan) {
dev_err(acdev->host->dev, "Unable to get dma_chan\n");
goto chan_request_fail;
@@ -798,6 +794,7 @@ static int arasan_cf_probe(struct platform_device *pdev)
struct ata_host *host;
struct ata_port *ap;
struct resource *res;
+ u32 quirk;
irq_handler_t irq_handler = NULL;
int ret = 0;
@@ -817,12 +814,17 @@ static int arasan_cf_probe(struct platform_device *pdev)
return -ENOMEM;
}
+ if (pdata)
+ quirk = pdata->quirk;
+ else
+ quirk = CF_BROKEN_UDMA; /* as it is on spear1340 */
+
/* if irq is 0, support only PIO */
acdev->irq = platform_get_irq(pdev, 0);
if (acdev->irq)
irq_handler = arasan_cf_interrupt;
else
- pdata->quirk |= CF_BROKEN_MWDMA | CF_BROKEN_UDMA;
+ quirk |= CF_BROKEN_MWDMA | CF_BROKEN_UDMA;
acdev->pbase = res->start;
acdev->vbase = devm_ioremap_nocache(&pdev->dev, res->start,
@@ -859,17 +861,16 @@ static int arasan_cf_probe(struct platform_device *pdev)
INIT_WORK(&acdev->work, data_xfer);
INIT_DELAYED_WORK(&acdev->dwork, delayed_finish);
dma_cap_set(DMA_MEMCPY, acdev->mask);
- acdev->dma_priv = pdata->dma_priv;
/* Handle platform specific quirks */
- if (pdata->quirk) {
- if (pdata->quirk & CF_BROKEN_PIO) {
+ if (quirk) {
+ if (quirk & CF_BROKEN_PIO) {
ap->ops->set_piomode = NULL;
ap->pio_mask = 0;
}
- if (pdata->quirk & CF_BROKEN_MWDMA)
+ if (quirk & CF_BROKEN_MWDMA)
ap->mwdma_mask = 0;
- if (pdata->quirk & CF_BROKEN_UDMA)
+ if (quirk & CF_BROKEN_UDMA)
ap->udma_mask = 0;
}
ap->flags |= ATA_FLAG_PIO_POLLING | ATA_FLAG_NO_ATAPI;
diff --git a/include/linux/pata_arasan_cf_data.h b/include/linux/pata_arasan_cf_data.h
index a7b4fc3..3cc21c9 100644
--- a/include/linux/pata_arasan_cf_data.h
+++ b/include/linux/pata_arasan_cf_data.h
@@ -37,8 +37,6 @@ struct arasan_cf_pdata {
#define CF_BROKEN_PIO (1)
#define CF_BROKEN_MWDMA (1 << 1)
#define CF_BROKEN_UDMA (1 << 2)
- /* This is platform specific data for the DMA controller */
- void *dma_priv;
};
static inline void
--
1.8.0
^ permalink raw reply related
* [PATCH 5/5] ARM: SPEAr13xx: Pass generic DW DMAC platform data from DT
From: Arnd Bergmann @ 2013-01-28 21:58 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359410300-26113-1-git-send-email-arnd@arndb.de>
This replaces an earlier patch from Viresh Kumar to move
the spear platform over to the generic DMA binding. This
version is now based on the merged multiplatform capable
spear platform, rather than the separate spear13xx/3xx/6xx
directories.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Vinod Koul <vinod.koul@linux.intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: devicetree-discuss at lists.ozlabs.org
---
arch/arm/boot/dts/spear1340.dtsi | 3 +
arch/arm/boot/dts/spear13xx.dtsi | 25 +++++-
arch/arm/mach-spear/generic.h | 6 --
arch/arm/mach-spear/include/mach/spear.h | 2 -
arch/arm/mach-spear/spear1310.c | 30 +-------
arch/arm/mach-spear/spear1340.c | 32 +-------
arch/arm/mach-spear/spear13xx-dma.h | 128 -------------------------------
arch/arm/mach-spear/spear13xx.c | 58 --------------
8 files changed, 29 insertions(+), 255 deletions(-)
delete mode 100644 arch/arm/mach-spear/spear13xx-dma.h
diff --git a/arch/arm/boot/dts/spear1340.dtsi b/arch/arm/boot/dts/spear1340.dtsi
index 34da11a..e1786a0 100644
--- a/arch/arm/boot/dts/spear1340.dtsi
+++ b/arch/arm/boot/dts/spear1340.dtsi
@@ -113,6 +113,9 @@
reg = <0xb4100000 0x1000>;
interrupts = <0 105 0x4>;
status = "disabled";
+ dmas = <&dwdma0 0x600 0 0 1>, /* 0xC << 11 */
+ <&dwdma0 0x680 0 1 0>; /* 0xD << 7 */
+ dma-names = "tx", "rx";
};
thermal@e07008c4 {
diff --git a/arch/arm/boot/dts/spear13xx.dtsi b/arch/arm/boot/dts/spear13xx.dtsi
index b4ca60f..45597fd 100644
--- a/arch/arm/boot/dts/spear13xx.dtsi
+++ b/arch/arm/boot/dts/spear13xx.dtsi
@@ -98,13 +98,24 @@
reg = <0xb2800000 0x1000>;
interrupts = <0 29 0x4>;
status = "disabled";
+ dmas = <&dwdma0 0 0 0 0>;
+ dma-names = "data";
};
- dma at ea800000 {
+ dwdma0: dma at ea800000 {
compatible = "snps,dma-spear1340";
reg = <0xea800000 0x1000>;
interrupts = <0 19 0x4>;
status = "disabled";
+
+ dma-channels = <8>;
+ #dma-cells = <3>;
+ dma-requests = <32>;
+ chan_allocation_order = <1>;
+ chan_priority = <1>;
+ block_size = <0xfff>;
+ dma-masters = <2>;
+ data_width = <3 3 0 0>;
};
dma at eb000000 {
@@ -112,6 +123,15 @@
reg = <0xeb000000 0x1000>;
interrupts = <0 59 0x4>;
status = "disabled";
+
+ dma-requests = <32>;
+ dma-channels = <8>;
+ dma-masters = <2>;
+ #dma-cells = <3>;
+ chan_allocation_order = <1>;
+ chan_priority = <1>;
+ block_size = <0xfff>;
+ data_width = <3 3 0 0>;
};
fsmc: flash at b0000000 {
@@ -261,6 +281,9 @@
#size-cells = <0>;
interrupts = <0 31 0x4>;
status = "disabled";
+ dmas = <&dwdma0 0x2000 0 0 0>, /* 0x4 << 11 */
+ <&dwdma0 0x0280 0 0 0>; /* 0x5 << 7 */
+ dma-names = "tx", "rx";
};
rtc@e0580000 {
diff --git a/arch/arm/mach-spear/generic.h b/arch/arm/mach-spear/generic.h
index 32b7d00..01c6ca3 100644
--- a/arch/arm/mach-spear/generic.h
+++ b/arch/arm/mach-spear/generic.h
@@ -20,13 +20,7 @@
extern struct sys_timer spear13xx_timer;
extern struct sys_timer spear3xx_timer;
-extern struct pl022_ssp_controller pl022_plat_data;
extern struct pl08x_platform_data pl080_plat_data;
-extern struct dw_dma_platform_data dmac_plat_data;
-extern struct dw_dma_slave cf_dma_priv;
-extern struct dw_dma_slave nand_read_dma_priv;
-extern struct dw_dma_slave nand_write_dma_priv;
-bool dw_dma_filter(struct dma_chan *chan, void *slave);
void __init spear_setup_of_timer(void);
void __init spear3xx_clk_init(void __iomem *misc_base,
diff --git a/arch/arm/mach-spear/include/mach/spear.h b/arch/arm/mach-spear/include/mach/spear.h
index 374ddc3..cf3a536 100644
--- a/arch/arm/mach-spear/include/mach/spear.h
+++ b/arch/arm/mach-spear/include/mach/spear.h
@@ -82,8 +82,6 @@
#define VA_L2CC_BASE IOMEM(UL(0xFB000000))
/* others */
-#define DMAC0_BASE UL(0xEA800000)
-#define DMAC1_BASE UL(0xEB000000)
#define MCIF_CF_BASE UL(0xB2800000)
/* Debug uart for linux, will be used for debug and uncompress messages */
diff --git a/arch/arm/mach-spear/spear1310.c b/arch/arm/mach-spear/spear1310.c
index 7c4ed3c..2622b1e 100644
--- a/arch/arm/mach-spear/spear1310.c
+++ b/arch/arm/mach-spear/spear1310.c
@@ -23,40 +23,12 @@
#include <mach/spear.h>
/* Base addresses */
-#define SPEAR1310_SSP1_BASE UL(0x5D400000)
-#define SPEAR1310_SATA0_BASE UL(0xB1000000)
-#define SPEAR1310_SATA1_BASE UL(0xB1800000)
-#define SPEAR1310_SATA2_BASE UL(0xB4000000)
-
#define SPEAR1310_RAS_GRP1_BASE UL(0xD8000000)
#define VA_SPEAR1310_RAS_GRP1_BASE UL(0xFA000000)
-static struct arasan_cf_pdata cf_pdata = {
- .cf_if_clk = CF_IF_CLK_166M,
- .quirk = CF_BROKEN_UDMA,
- .dma_priv = &cf_dma_priv,
-};
-
-/* ssp device registration */
-static struct pl022_ssp_controller ssp1_plat_data = {
- .enable_dma = 0,
-};
-
-/* Add SPEAr1310 auxdata to pass platform data */
-static struct of_dev_auxdata spear1310_auxdata_lookup[] __initdata = {
- OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL, &cf_pdata),
- OF_DEV_AUXDATA("snps,dma-spear1340", DMAC0_BASE, NULL, &dmac_plat_data),
- OF_DEV_AUXDATA("snps,dma-spear1340", DMAC1_BASE, NULL, &dmac_plat_data),
- OF_DEV_AUXDATA("arm,pl022", SSP_BASE, NULL, &pl022_plat_data),
-
- OF_DEV_AUXDATA("arm,pl022", SPEAR1310_SSP1_BASE, NULL, &ssp1_plat_data),
- {}
-};
-
static void __init spear1310_dt_init(void)
{
- of_platform_populate(NULL, of_default_bus_match_table,
- spear1310_auxdata_lookup, NULL);
+ of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL);
}
static const char * const spear1310_dt_board_compat[] = {
diff --git a/arch/arm/mach-spear/spear1340.c b/arch/arm/mach-spear/spear1340.c
index 98d509c..3fb3fdf 100644
--- a/arch/arm/mach-spear/spear1340.c
+++ b/arch/arm/mach-spear/spear1340.c
@@ -16,7 +16,6 @@
#include <linux/ahci_platform.h>
#include <linux/amba/serial.h>
#include <linux/delay.h>
-#include <linux/dw_dmac.h>
#include <linux/of_platform.h>
#include <linux/pata_arasan_cf_data.h>
#include <linux/irqchip.h>
@@ -24,11 +23,10 @@
#include "generic.h"
#include <mach/spear.h>
-#include "spear13xx-dma.h"
+/* FIXME: Move SATA PHY code into a standalone driver */
/* Base addresses */
#define SPEAR1340_SATA_BASE UL(0xB1000000)
-#define SPEAR1340_UART1_BASE UL(0xB4100000)
/* Power Management Registers */
#define SPEAR1340_PCM_CFG (VA_MISC_BASE + 0x100)
@@ -80,28 +78,6 @@
(SPEAR1340_MIPHY_OSC_BYPASS_EXT | \
SPEAR1340_MIPHY_PLL_RATIO_TOP(25))
-static struct dw_dma_slave uart1_dma_param[] = {
- {
- /* Tx */
- .cfg_hi = DWC_CFGH_DST_PER(SPEAR1340_DMA_REQ_UART1_TX),
- .cfg_lo = 0,
- .src_master = DMA_MASTER_MEMORY,
- .dst_master = SPEAR1340_DMA_MASTER_UART1,
- }, {
- /* Rx */
- .cfg_hi = DWC_CFGH_SRC_PER(SPEAR1340_DMA_REQ_UART1_RX),
- .cfg_lo = 0,
- .src_master = SPEAR1340_DMA_MASTER_UART1,
- .dst_master = DMA_MASTER_MEMORY,
- }
-};
-
-static struct amba_pl011_data uart1_data = {
- .dma_filter = dw_dma_filter,
- .dma_tx_param = &uart1_dma_param[0],
- .dma_rx_param = &uart1_dma_param[1],
-};
-
/* SATA device registration */
static int sata_miphy_init(struct device *dev, void __iomem *addr)
{
@@ -160,14 +136,8 @@ static struct ahci_platform_data sata_pdata = {
/* Add SPEAr1340 auxdata to pass platform data */
static struct of_dev_auxdata spear1340_auxdata_lookup[] __initdata = {
- OF_DEV_AUXDATA("arasan,cf-spear1340", MCIF_CF_BASE, NULL, &cf_dma_priv),
- OF_DEV_AUXDATA("snps,dma-spear1340", DMAC0_BASE, NULL, &dmac_plat_data),
- OF_DEV_AUXDATA("snps,dma-spear1340", DMAC1_BASE, NULL, &dmac_plat_data),
- OF_DEV_AUXDATA("arm,pl022", SSP_BASE, NULL, &pl022_plat_data),
-
OF_DEV_AUXDATA("snps,spear-ahci", SPEAR1340_SATA_BASE, NULL,
&sata_pdata),
- OF_DEV_AUXDATA("arm,pl011", SPEAR1340_UART1_BASE, NULL, &uart1_data),
{}
};
diff --git a/arch/arm/mach-spear/spear13xx-dma.h b/arch/arm/mach-spear/spear13xx-dma.h
deleted file mode 100644
index d50bdb6..0000000
--- a/arch/arm/mach-spear/spear13xx-dma.h
+++ /dev/null
@@ -1,128 +0,0 @@
-/*
- * arch/arm/mach-spear13xx/include/mach/dma.h
- *
- * DMA information for SPEAr13xx machine family
- *
- * Copyright (C) 2012 ST Microelectronics
- * Viresh Kumar <viresh.linux@gmail.com>
- *
- * This file is licensed under the terms of the GNU General Public
- * License version 2. This program is licensed "as is" without any
- * warranty of any kind, whether express or implied.
- */
-
-#ifndef __MACH_DMA_H
-#define __MACH_DMA_H
-
-/* request id of all the peripherals */
-enum dma_master_info {
- /* Accessible from only one master */
- DMA_MASTER_MCIF = 0,
- DMA_MASTER_FSMC = 1,
- /* Accessible from both 0 & 1 */
- DMA_MASTER_MEMORY = 0,
- DMA_MASTER_ADC = 0,
- DMA_MASTER_UART0 = 0,
- DMA_MASTER_SSP0 = 0,
- DMA_MASTER_I2C0 = 0,
-
-#ifdef CONFIG_MACH_SPEAR1310
- /* Accessible from only one master */
- SPEAR1310_DMA_MASTER_JPEG = 1,
-
- /* Accessible from both 0 & 1 */
- SPEAR1310_DMA_MASTER_I2S = 0,
- SPEAR1310_DMA_MASTER_UART1 = 0,
- SPEAR1310_DMA_MASTER_UART2 = 0,
- SPEAR1310_DMA_MASTER_UART3 = 0,
- SPEAR1310_DMA_MASTER_UART4 = 0,
- SPEAR1310_DMA_MASTER_UART5 = 0,
- SPEAR1310_DMA_MASTER_I2C1 = 0,
- SPEAR1310_DMA_MASTER_I2C2 = 0,
- SPEAR1310_DMA_MASTER_I2C3 = 0,
- SPEAR1310_DMA_MASTER_I2C4 = 0,
- SPEAR1310_DMA_MASTER_I2C5 = 0,
- SPEAR1310_DMA_MASTER_I2C6 = 0,
- SPEAR1310_DMA_MASTER_I2C7 = 0,
- SPEAR1310_DMA_MASTER_SSP1 = 0,
-#endif
-
-#ifdef CONFIG_MACH_SPEAR1340
- /* Accessible from only one master */
- SPEAR1340_DMA_MASTER_I2S_PLAY = 1,
- SPEAR1340_DMA_MASTER_I2S_REC = 1,
- SPEAR1340_DMA_MASTER_I2C1 = 1,
- SPEAR1340_DMA_MASTER_UART1 = 1,
-
- /* following are accessible from both master 0 & 1 */
- SPEAR1340_DMA_MASTER_SPDIF = 0,
- SPEAR1340_DMA_MASTER_CAM = 1,
- SPEAR1340_DMA_MASTER_VIDEO_IN = 0,
- SPEAR1340_DMA_MASTER_MALI = 0,
-#endif
-};
-
-enum request_id {
- DMA_REQ_ADC = 0,
- DMA_REQ_SSP0_TX = 4,
- DMA_REQ_SSP0_RX = 5,
- DMA_REQ_UART0_TX = 6,
- DMA_REQ_UART0_RX = 7,
- DMA_REQ_I2C0_TX = 8,
- DMA_REQ_I2C0_RX = 9,
-
-#ifdef CONFIG_MACH_SPEAR1310
- SPEAR1310_DMA_REQ_FROM_JPEG = 2,
- SPEAR1310_DMA_REQ_TO_JPEG = 3,
- SPEAR1310_DMA_REQ_I2S_TX = 10,
- SPEAR1310_DMA_REQ_I2S_RX = 11,
-
- SPEAR1310_DMA_REQ_I2C1_RX = 0,
- SPEAR1310_DMA_REQ_I2C1_TX = 1,
- SPEAR1310_DMA_REQ_I2C2_RX = 2,
- SPEAR1310_DMA_REQ_I2C2_TX = 3,
- SPEAR1310_DMA_REQ_I2C3_RX = 4,
- SPEAR1310_DMA_REQ_I2C3_TX = 5,
- SPEAR1310_DMA_REQ_I2C4_RX = 6,
- SPEAR1310_DMA_REQ_I2C4_TX = 7,
- SPEAR1310_DMA_REQ_I2C5_RX = 8,
- SPEAR1310_DMA_REQ_I2C5_TX = 9,
- SPEAR1310_DMA_REQ_I2C6_RX = 10,
- SPEAR1310_DMA_REQ_I2C6_TX = 11,
- SPEAR1310_DMA_REQ_UART1_RX = 12,
- SPEAR1310_DMA_REQ_UART1_TX = 13,
- SPEAR1310_DMA_REQ_UART2_RX = 14,
- SPEAR1310_DMA_REQ_UART2_TX = 15,
- SPEAR1310_DMA_REQ_UART5_RX = 16,
- SPEAR1310_DMA_REQ_UART5_TX = 17,
- SPEAR1310_DMA_REQ_SSP1_RX = 18,
- SPEAR1310_DMA_REQ_SSP1_TX = 19,
- SPEAR1310_DMA_REQ_I2C7_RX = 20,
- SPEAR1310_DMA_REQ_I2C7_TX = 21,
- SPEAR1310_DMA_REQ_UART3_RX = 28,
- SPEAR1310_DMA_REQ_UART3_TX = 29,
- SPEAR1310_DMA_REQ_UART4_RX = 30,
- SPEAR1310_DMA_REQ_UART4_TX = 31,
-#endif
-
-#ifdef CONFIG_MACH_SPEAR1340
- SPEAR1340_DMA_REQ_SPDIF_TX = 2,
- SPEAR1340_DMA_REQ_SPDIF_RX = 3,
- SPEAR1340_DMA_REQ_I2S_TX = 10,
- SPEAR1340_DMA_REQ_I2S_RX = 11,
- SPEAR1340_DMA_REQ_UART1_TX = 12,
- SPEAR1340_DMA_REQ_UART1_RX = 13,
- SPEAR1340_DMA_REQ_I2C1_TX = 14,
- SPEAR1340_DMA_REQ_I2C1_RX = 15,
- SPEAR1340_DMA_REQ_CAM0_EVEN = 0,
- SPEAR1340_DMA_REQ_CAM0_ODD = 1,
- SPEAR1340_DMA_REQ_CAM1_EVEN = 2,
- SPEAR1340_DMA_REQ_CAM1_ODD = 3,
- SPEAR1340_DMA_REQ_CAM2_EVEN = 4,
- SPEAR1340_DMA_REQ_CAM2_ODD = 5,
- SPEAR1340_DMA_REQ_CAM3_EVEN = 6,
- SPEAR1340_DMA_REQ_CAM3_ODD = 7,
-#endif
-};
-
-#endif /* __MACH_DMA_H */
diff --git a/arch/arm/mach-spear/spear13xx.c b/arch/arm/mach-spear/spear13xx.c
index c1af386..371fc10 100644
--- a/arch/arm/mach-spear/spear13xx.c
+++ b/arch/arm/mach-spear/spear13xx.c
@@ -15,7 +15,6 @@
#include <linux/amba/pl022.h>
#include <linux/clk.h>
-#include <linux/dw_dmac.h>
#include <linux/err.h>
#include <linux/of.h>
#include <asm/hardware/cache-l2x0.h>
@@ -24,63 +23,6 @@
#include "generic.h"
#include <mach/spear.h>
-#include "spear13xx-dma.h"
-
-/* common dw_dma filter routine to be used by peripherals */
-bool dw_dma_filter(struct dma_chan *chan, void *slave)
-{
- struct dw_dma_slave *dws = (struct dw_dma_slave *)slave;
-
- if (chan->device->dev == dws->dma_dev) {
- chan->private = slave;
- return true;
- } else {
- return false;
- }
-}
-
-/* ssp device registration */
-static struct dw_dma_slave ssp_dma_param[] = {
- {
- /* Tx */
- .cfg_hi = DWC_CFGH_DST_PER(DMA_REQ_SSP0_TX),
- .cfg_lo = 0,
- .src_master = DMA_MASTER_MEMORY,
- .dst_master = DMA_MASTER_SSP0,
- }, {
- /* Rx */
- .cfg_hi = DWC_CFGH_SRC_PER(DMA_REQ_SSP0_RX),
- .cfg_lo = 0,
- .src_master = DMA_MASTER_SSP0,
- .dst_master = DMA_MASTER_MEMORY,
- }
-};
-
-struct pl022_ssp_controller pl022_plat_data = {
- .enable_dma = 1,
- .dma_filter = dw_dma_filter,
- .dma_rx_param = &ssp_dma_param[1],
- .dma_tx_param = &ssp_dma_param[0],
-};
-
-/* CF device registration */
-struct dw_dma_slave cf_dma_priv = {
- .cfg_hi = 0,
- .cfg_lo = 0,
- .src_master = 0,
- .dst_master = 0,
-};
-
-/* dmac device registeration */
-struct dw_dma_platform_data dmac_plat_data = {
- .nr_channels = 8,
- .chan_allocation_order = CHAN_ALLOCATION_DESCENDING,
- .chan_priority = CHAN_PRIORITY_DESCENDING,
- .block_size = 4095U,
- .nr_masters = 2,
- .data_width = { 3, 3, 0, 0 },
-};
-
void __init spear13xx_l2x0_init(void)
{
/*
--
1.8.0
^ permalink raw reply related
* [PATCH v2 02/27] of/pci: Add of_pci_get_devfn() function
From: Stephen Warren @ 2013-01-28 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359399397-29729-3-git-send-email-thomas.petazzoni@free-electrons.com>
On 01/28/2013 11:56 AM, Thomas Petazzoni wrote:
> From: Thierry Reding <thierry.reding@avionic-design.de>
>
> This function can be used to parse the device and function number from a
> standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
> the returned value obtain the device and function numbers respectively.
> diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
> static inline int __of_pci_pci_compare(struct device_node *node,
> unsigned int devfn)
> {
> - unsigned int size;
> - const __be32 *reg = of_get_property(node, "reg", &size);
> + int err;
I think I commented when Thierry posted this, that calling that "err"
seems a little odd. Thierry replied:
Maybe renaming the devfn parameter to data and using devfn for the local
variable would be more obvious.
^ permalink raw reply
* [GIT PULL] imx cleanup for 3.9
From: Olof Johansson @ 2013-01-28 22:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130122144813.GD2812@S2101-09.ap.freescale.net>
Hi,
On Tue, Jan 22, 2013 at 10:48:15PM +0800, Shawn Guo wrote:
> Shawn Guo (4):
> ARM: dts: imx: use nodes label in board dts
Hmm.
This patch is 1000 lines of pure churn. Sure, the style on OMAP is different,
but there's no clear benefit from it -- it's actually advantageous to see some
of the bus hierarchies even on the leaf-level board nodes.
Would you mind respinning with this left out, please? If you still want to
argue it to be included, we can do so, but I'd like to pick up the rest of the
branch meanwhile. :-)
Thanks!
-Olof
^ permalink raw reply
* [PATCH 2/2] ARM: multi_v7_defconfig: add ARCH_ZYNQ
From: Olof Johansson @ 2013-01-28 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <7b635cbd-4c77-41c7-9b69-c1b9ef92353c@CH1EHSMHS019.ehs.local>
On Fri, Jan 25, 2013 at 03:08:06PM +0000, Michal Simek wrote:
>
>
> > -----Original Message-----
> > From: Josh Cartwright [mailto:josh.cartwright at ni.com]
> > Sent: Thursday, January 24, 2013 9:17 PM
> > To: arm at kernel.org; Rob Herring
> > Cc: linux-arm-kernel at lists.infradead.org; Michal Simek
> > Subject: Re: [PATCH 2/2] ARM: multi_v7_defconfig: add ARCH_ZYNQ
> >
> > On Thu, Jan 24, 2013 at 01:33:25PM -0600, Josh Cartwright wrote:
> > > Cc: Michal Simek <michal.simek@ni.com>
> >
> > Ugh, my fingers typed '@ni.com' out of habit. Corrected patch below (and
> > correct Cc added).
>
> Acked-by: Michal Simek <michal.simek@xilinx.com>
Applied, thanks.
-Olof
^ permalink raw reply
* [PATCH v2 07/27] PCI: Add software-emulated host bridge
From: Stephen Warren @ 2013-01-28 22:03 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301282018.17714.arnd@arndb.de>
On 01/28/2013 01:18 PM, Arnd Bergmann wrote:
> On Monday 28 January 2013, Thomas Petazzoni wrote:
>> From: Thierry Reding <thierry.reding@avionic-design.de>
>>
>> [Thomas Petazzoni:
>> - Simplify capabilities handling.
>> - Move to a separate file.
>> - Fix mask used when writing a 4 bytes value.]
>>
>> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
>> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
>
> Not even a description why this is needed?
>
> This patch (together with patch 8) seems like the most controversial
> one of the series, so you should better provide a really good reason
> why we would emulate something in software rather than using whatever
> hardware is there.
At least on Tegra, there is no HW that exposes PCI configuration
registers for the host bridge itself. Only the root ports have exposed
PCI configuration registers. There was some debate re: whether a host
bridge device needed to exist or not. This patch makes such a device
exist if it's required.
^ permalink raw reply
* [PATCH 1/2] ARM: multi_v7_defconfig: remove unnecessary CONFIG_GPIOLIB
From: Olof Johansson @ 2013-01-28 22:04 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <bb37ce3392153c4cae3a2bc642f831683620473a.1359057921.git.josh.cartwright@ni.com>
On Thu, Jan 24, 2013 at 12:59:22PM -0600, Josh Cartwright wrote:
> Commit 38669e045dbf8f62a008898a7fb1e93975b3817c ("ARM: vexpress: Start
> using new Versatile Express infrastructure") introduces a hard
> dependency to GPIOLIB for the multi_v7_defconfig:
>
> ARCH_MULTI_V7 -> ARCH_VEXPRESS -> ARCH_REQUIRE_GPIOLIB -> GPIOLIB
>
> Remove unnecessary explicit CONFIG_GPIOLIB=y from multi_v7_defconfig.
>
> Signed-off-by: Josh Cartwright <josh.cartwright@ni.com>
Applied, thanks.
-Olof
^ permalink raw reply
* [PATCH v2 08/27] pci: implement an emulated PCI-to-PCI bridge
From: Stephen Warren @ 2013-01-28 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128195501.GD17722@obsidianresearch.com>
On 01/28/2013 12:55 PM, Jason Gunthorpe wrote:
> On Mon, Jan 28, 2013 at 08:39:47PM +0100, Thomas Petazzoni wrote:
>
>>> In the Marvell case, this capability can be constructed by pulling
>>> data from the the Express End Point capability of the PCI-E port:
>>
>> I am not sure what you mean by "pulling". Do you mean that I should get
>> informations from the real PCIe interface, from within the emulated
>> PCI-to-PCI bridge implementation? This would unfortunately not be
>> really nice, because until now, the PCI-to-PCI bridge emulation is
>> clearly separated from the Marvell PCIe driver itself. Of course, it
>> could register a hook or something like that, so that the emulated
>> PCI-to-PCI bridge could potentially call back into the Marvell PCIe
>> driver.
>
> Yes, a callback would be needed to the main driver and IIRC the driver
> can read/write the end port link info config regsiters via MMIO. They
> probably need a bit of massaging to be in root port format, but
> otherwise it should be straightforward..
>
>> I'll have to dig a little bit more about this capability to see how it
>> works exactly.
>
> All ports have registers to report and control the link, but the root
> port and end port versions are a bit different, so the goal is to read
> the end port formatted registers and map them into the root port
> format so that userspace can properly see the link state and
> configuration.
Isn't the thing being emulated here a host bridge, which "contains" the
PCIe root ports underneath, which in turn "contain" the PCIe devices
underneath? At least on Tegra, there is no host bridge device that
exposes PCIe config registers, but the PCIe root ports do exist and do
expose PCIe config registers...
^ permalink raw reply
* [GIT PULL] ux500 fixes for the v3.8 series
From: Olof Johansson @ 2013-01-28 22:06 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdYhVbu2S6iD=SRnU1gMRNfau25ihOqoDoXvCrH71seREQ@mail.gmail.com>
On Fri, Jan 25, 2013 at 01:40:34PM +0100, Linus Walleij wrote:
> Hi ARM SoC guys,
>
> here are three fixes for the Ux500 that need to go to the -rc:s.
>
> Please pull them in!
>
> Yours,
> Linus Walleij
>
>
> The following changes since commit d1c3ed669a2d452cacfb48c2d171a1f364dae2ed:
>
> Linux 3.8-rc2 (2013-01-02 18:13:21 -0800)
>
> are available in the git repository at:
>
> http://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git
> tags/ux500-fixes-for-v3.8
Pulled, thanks.
Nit below:
> Steve Zhan (1):
> ARM: ux500: add spin_unlock(&master_lock).
That's not a great patch subject, but I'm not going to ask a respin just for
it.
-Olof
^ permalink raw reply
* [PATCH v2 11/27] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
From: Stephen Warren @ 2013-01-28 22:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359399397-29729-12-git-send-email-thomas.petazzoni@free-electrons.com>
On 01/28/2013 11:56 AM, Thomas Petazzoni wrote:
> The Armada 370 has two gatable clocks for each PCIe interface, and we
> want both of them to be enabled. We therefore make one of the two
> clocks a child of the other, as we did for the sataX and sataXlnk
> clocks on Armada XP.
> diff --git a/drivers/clk/mvebu/clk-gating-ctrl.c b/drivers/clk/mvebu/clk-gating-ctrl.c
> @@ -119,8 +119,8 @@ static const struct mvebu_soc_descr __initconst armada_370_gating_descr[] = {
> { "pex1_en", NULL, 2 },
> { "ge1", NULL, 3 },
> { "ge0", NULL, 4 },
> - { "pex0", NULL, 5 },
> - { "pex1", NULL, 9 },
> + { "pex0", "pex0_en", 5 },
> + { "pex1", "pex1_en", 9 },
I must admit, I know nothing about struct mvebu_soc_descr, but I'm
having a hard time seeing how that code change makes one of those clock
a parent of the other, since the pex0 entry doesn't reference anything
"pex1"-related, nor vice-versa. Is more explanation in the commit
message warranted here?
^ permalink raw reply
* [PATCH v2 07/27] PCI: Add software-emulated host bridge
From: Jason Gunthorpe @ 2013-01-28 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5106F5CB.8050304@wwwdotorg.org>
On Mon, Jan 28, 2013 at 03:03:55PM -0700, Stephen Warren wrote:
> On 01/28/2013 01:18 PM, Arnd Bergmann wrote:
> > On Monday 28 January 2013, Thomas Petazzoni wrote:
> >> From: Thierry Reding <thierry.reding@avionic-design.de>
> >>
> >> [Thomas Petazzoni:
> >> - Simplify capabilities handling.
> >> - Move to a separate file.
> >> - Fix mask used when writing a 4 bytes value.]
> >>
> >> Signed-off-by: Thierry Reding <thierry.reding@avionic-design.de>
> >> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
> >
> > Not even a description why this is needed?
> >
> > This patch (together with patch 8) seems like the most controversial
> > one of the series, so you should better provide a really good reason
> > why we would emulate something in software rather than using whatever
> > hardware is there.
>
> At least on Tegra, there is no HW that exposes PCI configuration
> registers for the host bridge itself. Only the root ports have exposed
> PCI configuration registers. There was some debate re: whether a host
> bridge device needed to exist or not. This patch makes such a device
> exist if it's required.
If Linux will discover properly (I strongly suspect it does) without
the host bridge, then I would say to ditch this...
The PCI-E standard requires a host bridge device, but if Linux doesn't
require it then there is no reason to emulate one.
That would simplify the question of PCI IDs - for Marvell's case and
the sw root port bridge we can just copy the IDs from the bogus config
space of the HW.
Jason
^ permalink raw reply
* [PATCH v2 07/27] PCI: Add software-emulated host bridge
From: Thomas Petazzoni @ 2013-01-28 22:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <201301282018.17714.arnd@arndb.de>
Dear Arnd Bergmann,
On Mon, 28 Jan 2013 20:18:17 +0000, Arnd Bergmann wrote:
> Not even a description why this is needed?
>
> This patch (together with patch 8) seems like the most controversial
> one of the series, so you should better provide a really good reason
> why we would emulate something in software rather than using whatever
> hardware is there.
Hum, you're right. In fact, the very reason why I'm adding an emulated
host bridge and emulated PCI-to-PCI bridges is simply because this was
one of the main suggestion raised during the review of the first
revision of this patch set.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 02/27] of/pci: Add of_pci_get_devfn() function
From: Thierry Reding @ 2013-01-28 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5106F4EA.20904@wwwdotorg.org>
On Mon, Jan 28, 2013 at 03:00:10PM -0700, Stephen Warren wrote:
> On 01/28/2013 11:56 AM, Thomas Petazzoni wrote:
> > From: Thierry Reding <thierry.reding@avionic-design.de>
> >
> > This function can be used to parse the device and function number from a
> > standard 5-cell PCI resource. PCI_SLOT() and PCI_FUNC() can be used on
> > the returned value obtain the device and function numbers respectively.
>
> > diff --git a/drivers/of/of_pci.c b/drivers/of/of_pci.c
>
> > static inline int __of_pci_pci_compare(struct device_node *node,
> > unsigned int devfn)
> > {
> > - unsigned int size;
> > - const __be32 *reg = of_get_property(node, "reg", &size);
> > + int err;
>
> I think I commented when Thierry posted this, that calling that "err"
> seems a little odd. Thierry replied:
>
> Maybe renaming the devfn parameter to data and using devfn for the local
> variable would be more obvious.
That's already fixed up in my series. I was going to wait until I was
done with the MSI rework but maybe posting an intermediate version is in
order to share the latest state.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20130128/02aacdbf/attachment.sig>
^ permalink raw reply
* [PATCH v2 08/27] pci: implement an emulated PCI-to-PCI bridge
From: Jason Gunthorpe @ 2013-01-28 22:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5106F668.60605@wwwdotorg.org>
On Mon, Jan 28, 2013 at 03:06:32PM -0700, Stephen Warren wrote:
> On 01/28/2013 12:55 PM, Jason Gunthorpe wrote:
> > On Mon, Jan 28, 2013 at 08:39:47PM +0100, Thomas Petazzoni wrote:
> >
> >>> In the Marvell case, this capability can be constructed by pulling
> >>> data from the the Express End Point capability of the PCI-E port:
> >>
> >> I am not sure what you mean by "pulling". Do you mean that I should get
> >> informations from the real PCIe interface, from within the emulated
> >> PCI-to-PCI bridge implementation? This would unfortunately not be
> >> really nice, because until now, the PCI-to-PCI bridge emulation is
> >> clearly separated from the Marvell PCIe driver itself. Of course, it
> >> could register a hook or something like that, so that the emulated
> >> PCI-to-PCI bridge could potentially call back into the Marvell PCIe
> >> driver.
> >
> > Yes, a callback would be needed to the main driver and IIRC the driver
> > can read/write the end port link info config regsiters via MMIO. They
> > probably need a bit of massaging to be in root port format, but
> > otherwise it should be straightforward..
> >
> >> I'll have to dig a little bit more about this capability to see how it
> >> works exactly.
> >
> > All ports have registers to report and control the link, but the root
> > port and end port versions are a bit different, so the goal is to read
> > the end port formatted registers and map them into the root port
> > format so that userspace can properly see the link state and
> > configuration.
>
> Isn't the thing being emulated here a host bridge, which "contains" the
> PCIe root ports underneath, which in turn "contain" the PCIe devices
> underneath? At least on Tegra, there is no host bridge device that
> exposes PCIe config registers, but the PCIe root ports do exist and do
> expose PCIe config registers...
Patch #7 create a SW emulated host bridge, which tegra and marvell
lack in HW.
Patch #8 creates a SW emulated root port bridge, which tegra has
properly in HW, while Marvell doesn't.
Basically, on the Marvell chips, the PCI config space of the PCI
complex is useless when used as a root complex - the config space is
only usable when the device is configured as an end port.
Jason
^ permalink raw reply
* [PATCH v2 07/27] PCI: Add software-emulated host bridge
From: Thomas Petazzoni @ 2013-01-28 22:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128220904.GA21446@obsidianresearch.com>
Dear Jason Gunthorpe,
On Mon, 28 Jan 2013 15:09:04 -0700, Jason Gunthorpe wrote:
> If Linux will discover properly (I strongly suspect it does) without
> the host bridge, then I would say to ditch this...
>
> The PCI-E standard requires a host bridge device, but if Linux doesn't
> require it then there is no reason to emulate one.
>
> That would simplify the question of PCI IDs - for Marvell's case and
> the sw root port bridge we can just copy the IDs from the bogus config
> space of the HW.
Not sure what you mean in this last paragraph. In this second version,
I really rely on the emulated PCI-to-PCI bridges for the resource
allocation. I give the Linux PCI core a global range of addresses for
memory regions and a global range of addresses for I/O regions, and
then I let Linux do the allocation of ranges on a per bridge basis,
depending on the devices detected downstream. And at the end, I use
those allocated ranges to set up the address decoding windows.
This all comes from your suggestions during the review of the first
revision of this patch set.
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 19/27] pci: PCIe driver for Marvell Armada 370/XP systems
From: Stephen Warren @ 2013-01-28 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359399397-29729-20-git-send-email-thomas.petazzoni@free-electrons.com>
On 01/28/2013 11:56 AM, Thomas Petazzoni wrote:
> This driver implements the support for the PCIe interfaces on the
> Marvell Armada 370/XP ARM SoCs. In the future, it might be extended to
> cover earlier families of Marvell SoCs, such as Dove, Orion and
> Kirkwood.
>
> The driver implements the hw_pci operations needed by the core ARM PCI
> code to setup PCI devices and get their corresponding IRQs, and the
> pci_ops operations that are used by the PCI core to read/write the
> configuration space of PCI devices.
>
> Since the PCIe interfaces of Marvell SoCs are completely separate and
> not linked together in a bus, this driver sets up an emulated PCI host
> bridge, with one PCI-to-PCI bridge as child for each hardware PCIe
> interface.
>
> In addition, this driver enumerates the different PCIe slots, and for
> those having a device plugged in, it sets up the necessary address
> decoding windows, using the new armada_370_xp_alloc_pcie_window()
> function from mach-mvebu/addr-map.c.
> diff --git a/Documentation/devicetree/bindings/pci/armada-370-xp-pcie.txt b/Documentation/devicetree/bindings/pci/armada-370-xp-pcie.txt
> +Mandatory properties:
> +- compatible: must be "marvell,armada-370-xp-pcie"
> +- status: either "disabled" or "okay"
status is a standard DT property; I certainly wouldn't expect its
presence to be mandatory (there's a defined default), nor would I expect
each device's binding to redefine this property.
> +In addition, the Device Tree node must have sub-nodes describing each
> +PCIe interface, having the following mandatory properties:
> +- marvell,pcie-port: the physical PCIe port number
Should the standardized cell-index property be used here instead? Or,
perhaps that property is deprecated/discouraged...
> +- status: either "disabled" or "okay"
Similar comment as above.
> diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
> +obj-$(CONFIG_PCI_MVEBU) += pci-mvebu.o
> +ccflags-$(CONFIG_PCI_MVEBU) += \
> + -I$(srctree)/arch/arm/plat-orion/include \
> + -I$(srctree)/arch/arm/mach-mvebu/include
That seems a little dangerous w.r.t. multi-platform zImage. Can the
required headers be moved out to somewhere more public to avoid this?
> diff --git a/drivers/pci/host/pci-mvebu.c b/drivers/pci/host/pci-mvebu.c
> +/*
> + * Those are the product IDs used for the emulated PCI Host bridge and
> + * emulated PCI-to-PCI bridges. They are temporary until we get
> + * official IDs assigned.
> + */
> +#define MARVELL_EMULATED_HOST_BRIDGE_ID 4141
> +#define MARVELL_EMULATED_PCI_PCI_BRIDGE_ID 4242
I assume that means we can't merge this driver yet. The cover letter
mentioned a desire to merge this for 3.9; there's not much time to get
official IDs assigned, then.
> +static int mvebu_pcie_init(void)
> +{
> + return platform_driver_probe(&mvebu_pcie_driver,
> + mvebu_pcie_probe);
> +}
> +
> +subsys_initcall(mvebu_pcie_init);
Why isn't that just platform_driver_register()?
> +MODULE_LICENSE("GPL");
"GPL v2".
^ permalink raw reply
* [PATCH v2 11/27] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
From: Thomas Petazzoni @ 2013-01-28 22:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5106F6EE.4000101@wwwdotorg.org>
Dear Stephen Warren,
On Mon, 28 Jan 2013 15:08:46 -0700, Stephen Warren wrote:
> I must admit, I know nothing about struct mvebu_soc_descr, but I'm
> having a hard time seeing how that code change makes one of those clock
> a parent of the other, since the pex0 entry doesn't reference anything
> "pex1"-related, nor vice-versa. Is more explanation in the commit
> message warranted here?
See the definition of mvebu_soc_descr:
struct mvebu_soc_descr {
const char *name;
const char *parent;
int bit_idx;
};
It simply registers the pex0 clock with the pex0_en clock as its
parents. Those clocks are normal gatable clocks, registered with
clk_register_gate(). This ensures that whenever the pex0 clock is
enabled, its parent clock pex0_en gets enabled as well. We do the same
for SATA clocks on Armada XP, for example:
static const struct mvebu_soc_descr __initconst
armada_xp_gating_descr[] = { { "audio", NULL, 0 },
[...]
{ "sata0lnk", NULL, 14 },
{ "sata0", "sata0lnk", 15 },
[...]
{ "sata1lnk", NULL, 29 },
{ "sata1", "sata1lnk", 30 },
{ }
};
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [PATCH v2 07/27] PCI: Add software-emulated host bridge
From: Jason Gunthorpe @ 2013-01-28 22:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128231829.6b205c3c@skate>
On Mon, Jan 28, 2013 at 11:18:29PM +0100, Thomas Petazzoni wrote:
> > That would simplify the question of PCI IDs - for Marvell's case and
> > the sw root port bridge we can just copy the IDs from the bogus config
> > space of the HW.
>
> Not sure what you mean in this last paragraph. In this second version,
> I really rely on the emulated PCI-to-PCI bridges for the resource
I'm refering to your earlier question about what PCI IDs to use for
the SW emulated devices. If there is no need for the host bridge then
you only need 1 PCI ID (for the root port bridge) and you can probably
fairly safely re-use the one in the Marvell config space of the HW.
> allocation. I give the Linux PCI core a global range of addresses for
> memory regions and a global range of addresses for I/O regions, and
> then I let Linux do the allocation of ranges on a per bridge basis,
> depending on the devices detected downstream. And at the end, I use
> those allocated ranges to set up the address decoding windows.
Yes, that all seems OK to me.
Jason
^ permalink raw reply
* [RFC PATCH 0/4] Add support for LZ4-compressed kernels
From: Andrew Morton @ 2013-01-28 22:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1359179447-31118-1-git-send-email-kyungsik.lee@lge.com>
On Sat, 26 Jan 2013 14:50:43 +0900
Kyungsik Lee <kyungsik.lee@lge.com> wrote:
> This patchset is for supporting LZ4 compressed kernel and initial ramdisk on
> the x86 and ARM architectures.
>
> According to http://code.google.com/p/lz4/, LZ4 is a very fast lossless
> compression algorithm and also features an extremely fast decoder.
>
> Kernel Decompression APIs are based on implementation by Yann Collet
> (http://code.google.com/p/lz4/source/checkout).
> De/compression Tools are also provided from the site above.
>
> The initial test result on ARM(v7) based board shows that the size of kernel
> with LZ4 compressed is 8% bigger than LZO compressed but the decompressing
> speed is faster(especially under the enabled unaligned memory access).
>
> Test: 3.4 based kernel built with many modules
> Uncompressed kernel size: 13MB
> lzo: 6.3MB, 301ms
> lz4: 6.8MB, 251ms(167ms, with enabled unaligned memory access)
>
> It seems that it___s worth trying LZ4 compressed kernel image or ramdisk
> for making the kernel boot more faster.
>
> ...
>
> 20 files changed, 663 insertions(+), 3 deletions(-)
>
> ...
>
What's this "with enabled unaligned memory access" thing? You mean "if
the arch supports CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS"? If so,
that's only x86, which isn't really in the target market for this
patch, yes?
It's a lot of code for a 50ms boot-time improvement. Does anyone have
any opinions on whether or not the benefits are worth the cost?
^ permalink raw reply
* [PATCH v2 11/27] clk: mvebu: create parent-child relation for PCIe clocks on Armada 370
From: Stephen Warren @ 2013-01-28 22:27 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128232150.53b56e62@skate>
On 01/28/2013 03:21 PM, Thomas Petazzoni wrote:
> Dear Stephen Warren,
>
> On Mon, 28 Jan 2013 15:08:46 -0700, Stephen Warren wrote:
>
>> I must admit, I know nothing about struct mvebu_soc_descr, but I'm
>> having a hard time seeing how that code change makes one of those clock
>> a parent of the other, since the pex0 entry doesn't reference anything
>> "pex1"-related, nor vice-versa. Is more explanation in the commit
>> message warranted here?
>
> See the definition of mvebu_soc_descr:
>
> struct mvebu_soc_descr {
> const char *name;
> const char *parent;
> int bit_idx;
> };
>
> It simply registers the pex0 clock with the pex0_en clock as its
> parents. Those clocks are normal gatable clocks, registered with
> clk_register_gate(). This ensures that whenever the pex0 clock is
> enabled, its parent clock pex0_en gets enabled as well.
Oh I see; I was confused by the patch description. The two clocks being
made child/parent are the two clocks for a port, and this relationship
is set up for each port; for some reason I thought there was a
requirement to make one port's clock a child of the other port's clock.
^ permalink raw reply
* [PATCH v2 07/27] PCI: Add software-emulated host bridge
From: Thomas Petazzoni @ 2013-01-28 22:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20130128222348.GA21628@obsidianresearch.com>
Dear Jason Gunthorpe,
On Mon, 28 Jan 2013 15:23:48 -0700, Jason Gunthorpe wrote:
> I'm refering to your earlier question about what PCI IDs to use for
> the SW emulated devices. If there is no need for the host bridge then
> you only need 1 PCI ID (for the root port bridge) and you can probably
> fairly safely re-use the one in the Marvell config space of the HW.
Ah, ok, I see. But isn't a host bridge needed to bind all the
PCI-to-PCI bridges under a single bus, in order to get the global
resource assignment I was referring to?
Regarding the PCI IDs, I have started to work with Marvell to see what
is possible. I, unfortunately, haven't received the answer for now.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ 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