Re: [PATCH v2 1/7] dmaengine: of_dma: Support for DMA routers
On Wed, Mar 11, 2015 at 03:23:24PM +0200, Peter Ujfalusi wrote:
DMA routers are transparent devices used to mux DMA requests from
peripherals to DMA controllers. They are used when the SoC integrates more
devices with DMA requests then their controller can handle.
DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request
lines, but in SoC level it has 205 DMA requests.
The of_dma_router will be registered as of_dma_controller with special
xlate function and additional parameters and the code will translate and
requests a DMA channel from the real DMA controller.
This way the router can be transparent for the system while remaining generic
enough to be used in different environments.
Looks fine, was expecting a Documentation updates as well, but that can come
as follow up patch too
--
~Vinod
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
Documentation/devicetree/bindings/dma/dma.txt | 28
drivers/dma/dmaengine.c | 7 ++
drivers/dma/of-dma.c | 92
+++
include/linux/dmaengine.h | 17 +
include/linux/of_dma.h| 21 ++
5 files changed, 165 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
index 82104271e754..f728b978178e 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -31,6 +31,34 @@ Example:
dma-requests = 127;
};
+* DMA router
+
+DMA routers are transparent IP blocks used to route DMA request lines from
+devices to the DMA controller. Some SoCs (like TI DRA7x) have more
peripherals
+integrated with DMA requests than what the DMA controller can handle
directly.
+
+Required property:
+- dma-device:phandle of the DMA controller. The router is
modifying
+ the DMA requests for this controller.
+- #dma-cells:Must be at least 1. Used to provide DMA router
specific
+ information. See DMA client binding below for more
+ details.
+
+Optional properties:
+- dma-requests: Number of incoming request lines the router can handle.
+- dma-device
+ - dma-requests: The router driver might need to look for this in order
+ to configure the routing.
+
+Example:
+ sdma_xbar: dma-router@4a002b78 {
+ compatible = ti,dra7-dma-crossbar;
+ reg = 0x4a002b78 0xfc;
+ #dma-cells = 1;
+ dma-requests = 205;
+ ti,dma-safe-map = 0;
+ dma-device = sdma;
+ };
* DMA client
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 344b0ac6d985..1bb67dae5880 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -271,6 +271,13 @@ static void dma_chan_put(struct dma_chan *chan)
/* This channel is not in use anymore, free it */
if (!chan-client_count chan-device-device_free_chan_resources)
chan-device-device_free_chan_resources(chan);
+
+ /* If the channel is used via a DMA request router, free the mapping */
+ if (chan-router chan-router-route_free) {
+ chan-router-route_free(chan-router-dev, chan-route_data);
+ chan-router = NULL;
+ chan-route_data = NULL;
+ }
}
enum dma_status dma_sync_wait(struct dma_chan *chan, dma_cookie_t cookie)
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index ca31f1b45366..c86f8823da0d 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -45,6 +45,53 @@ static struct of_dma *of_dma_find_controller(struct
of_phandle_args *dma_spec)
}
/**
+ * of_dma_router_xlate - translation function for router devices
+ * @dma_spec:pointer to DMA specifier as found in the device tree
+ * @of_dma: pointer to DMA controller data (router information)
+ *
+ * The function creates new dma_spec to be passed to the router driver's
+ * of_dma_route_allocate() function to prepare a dma_spec which will be used
+ * to request channel from the real DMA controller.
+ */
+static struct dma_chan *of_dma_router_xlate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct dma_chan *chan;
+ struct of_dma *ofdma_target;
+ struct device_node *dma_target;
+ struct of_phandle_args dma_spec_target;
+ void*route_data;
+
+ dma_target = of_parse_phandle(dma_spec-np, dma-device, 0);
+ if (!dma_target) {
+ pr_err(%s: Can't get target DMA\n, __func__);
+ return NULL;
+ }
+
+ /* translate the request for the real DMA controller */
+ memcpy(dma_spec_target, dma_spec, sizeof(dma_spec_target));
+ dma_spec_target.np =
Re: [PATCH v2 4/7] dmaengine: omap-dma: Use defines for dma channels and request count
On Wed, Mar 11, 2015 at 03:23:27PM +0200, Peter Ujfalusi wrote:
Instead of magic numbers in the code, use define for number of logical DMA
channels and DMA requests.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 7dd6dd121681..56c33e93dd24 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -22,6 +22,9 @@
#include virt-dma.h
+#define OMAP_SDMA_REQUESTS 127
+#define OMAP_SDMA_CHANNELS 32
Again why dont we put these things in DT ?
--
~Vinod
+
struct omap_dmadev {
struct dma_device ddev;
spinlock_t lock;
@@ -33,7 +36,7 @@ struct omap_dmadev {
bool legacy;
spinlock_t irq_lock;
uint32_t irq_enable_mask;
- struct omap_chan *lch_map[32];
+ struct omap_chan *lch_map[OMAP_SDMA_CHANNELS];
};
struct omap_chan {
@@ -1115,7 +1118,7 @@ static int omap_dma_probe(struct platform_device *pdev)
tasklet_init(od-task, omap_dma_sched, (unsigned long)od);
- for (i = 0; i 127; i++) {
+ for (i = 0; i OMAP_SDMA_REQUESTS; i++) {
rc = omap_dma_chan_init(od, i);
if (rc) {
omap_dma_free(od);
--
2.3.0
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] dmaengine: of_dma: Support for DMA routers
On 03/26/2015 12:50 PM, Vinod Koul wrote: On Wed, Mar 11, 2015 at 03:23:24PM +0200, Peter Ujfalusi wrote: DMA routers are transparent devices used to mux DMA requests from peripherals to DMA controllers. They are used when the SoC integrates more devices with DMA requests then their controller can handle. DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request lines, but in SoC level it has 205 DMA requests. The of_dma_router will be registered as of_dma_controller with special xlate function and additional parameters and the code will translate and requests a DMA channel from the real DMA controller. This way the router can be transparent for the system while remaining generic enough to be used in different environments. Looks fine, was expecting a Documentation updates as well, but that can come as follow up patch too I have added the DT binding document since this series adds support for routers for platforms booting with DT: Documentation/devicetree/bindings/dma/dma.txt | 28 -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] dmaengine: Add driver for TI DMA crossbar on DRA7x
On Wed, Mar 11, 2015 at 03:23:26PM +0200, Peter Ujfalusi wrote:
The DRA7x has more peripherals with DMA requests than the sDMA can handle:
205 vs 127. All DMA requests are routed through the DMA crossbar, which can
be configured to route selected incoming DMA requests to specific sDMA
request.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/Kconfig | 4 +
drivers/dma/Makefile | 1 +
drivers/dma/ti-dma-crossbar.c | 190
++
3 files changed, 195 insertions(+)
create mode 100644 drivers/dma/ti-dma-crossbar.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 074ffad334a7..519657a37ca1 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -247,6 +247,9 @@ config TI_EDMA
Enable support for the TI EDMA controller. This DMA
engine is found on TI DaVinci and AM33xx parts.
+config TI_DMA_CROSSBAR
+ bool
+
config ARCH_HAS_ASYNC_TX_FIND_CHANNEL
bool
@@ -332,6 +335,7 @@ config DMA_OMAP
depends on ARCH_OMAP
select DMA_ENGINE
select DMA_VIRTUAL_CHANNELS
+ select TI_DMA_CROSSBAR if SOC_DRA7XX
config DMA_BCM2835
tristate BCM2835 DMA engine support
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index bf4485800c60..6ec7af6a416c 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -39,6 +39,7 @@ obj-$(CONFIG_EP93XX_DMA) += ep93xx_dma.o
obj-$(CONFIG_DMA_SA11X0) += sa11x0-dma.o
obj-$(CONFIG_MMP_TDMA) += mmp_tdma.o
obj-$(CONFIG_DMA_OMAP) += omap-dma.o
+obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
obj-$(CONFIG_DMA_BCM2835) += bcm2835-dma.o
obj-$(CONFIG_MMP_PDMA) += mmp_pdma.o
obj-$(CONFIG_DMA_JZ4740) += dma-jz4740.o
diff --git a/drivers/dma/ti-dma-crossbar.c b/drivers/dma/ti-dma-crossbar.c
new file mode 100644
index ..591307bd4370
--- /dev/null
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -0,0 +1,190 @@
+/*
+ * Copyright (C) 2015 Texas Instruments Incorporated - http://www.ti.com
+ * Author: Peter Ujfalusi peter.ujfal...@ti.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include linux/slab.h
+#include linux/err.h
+#include linux/init.h
+#include linux/list.h
+#include linux/io.h
+#include linux/regmap.h
+#include linux/idr.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+
+#define TI_XBAR_OUTPUTS 127
+#define TI_XBAR_INPUTS 256
Ideally this should be moved to DT. Will next revision of this chip always
support these output and inputs?
+
+static DEFINE_IDR(map_idr);
+
+struct ti_dma_xbar_data {
+ struct dma_router dmarouter;
+ struct regmap *regmap;
+
+ uint safe_val; /* Value to rest the crossbar lines */
+ uint xbar_requests; /* number of DMA requests connected to XBAR */
+ uint dma_requests; /* number of DMA requests forwarded to DMA */
+
+ void __iomem *iomem;
+};
+
+struct ti_dma_xbar_map {
+ int xbar_in;
+ int xbar_out;
+};
+
+static void ti_dma_xbar_free(struct device *dev, void *route_data)
+{
+ struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
+ struct ti_dma_xbar_map *map = route_data;
+
+ dev_dbg(dev, Unmapping XBAR%d (was routed to %d)\n,
+ map-xbar_in, map-xbar_out);
+
+ regmap_write(xbar-regmap, map-xbar_out * 2, 0);
just out of curiosity how much do you save using regmap :)
+static int ti_dma_xbar_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct device_node *dma_node;
+ struct ti_dma_xbar_data *xbar;
+ struct resource *res;
+ void __iomem *iomem;
+ int i, ret;
+
+ if (!node)
+ return -ENODEV;
+
+ dma_node = of_parse_phandle(node, dma-device, 0);
+ if (!dma_node) {
+ dev_err(pdev-dev, Can't get target DMA node\n);
+ return -ENODEV;
+ }
+
+ xbar = devm_kzalloc(pdev-dev, sizeof(*xbar), GFP_KERNEL);
+ if (!xbar)
+ return -ENOMEM;
+
+ if (of_property_read_u32(dma_node, dma-requests,
+ xbar-dma_requests)) {
+ dev_info(pdev-dev,
+ Missing XBAR output information, using %u.\n,
+ TI_XBAR_OUTPUTS);
+ xbar-dma_requests = TI_XBAR_OUTPUTS;
+ }
+ of_node_put(dma_node);
_put here?
+int omap_dmaxbar_init(void)
+{
+ return platform_driver_register(ti_dma_xbar_driver);
+}
+arch_initcall(omap_dmaxbar_init);
why arch_initcall?
--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 11/35] ARM: OMAP2+: clock: move clock provider infrastructure to clock driver
On 03/26/2015 09:24 AM, Tero Kristo wrote:
On 03/26/2015 01:17 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [150325 08:12]:
Splits the clock provider init out of the PRM driver and moves it to
clock driver. This is needed so that once the PRCM drivers are
separated,
they can logically just access the clock driver not needing to go
through
common PRM code. This would be wrong in the case of control module for
example.
...
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
...
-u32 omap2_clk_readl(struct clk_hw_omap *clk, void __iomem *reg)
+u32 omap2_clk_memmap_readl(void __iomem *reg)
{
-u32 val;
+struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
-if (clk-flags MEMMAP_ADDRESSING) {
-struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
-val = readl_relaxed(clk_memmaps[r-index] + r-offset);
-} else {
-val = readl_relaxed(reg);
-}
+return readl_relaxed(clk_memmaps[r-index] + r-offset);
+}
The cast from void __iomem *reg to struct clk_omap_reg *r looks still
nasty.. Why don't you add the IO address into struct clk_omap_reg:
struct clk_omap_reg {
u16 offset;
u16 index;
struct regmap *regmap;
void __iomem *addr;
};
...
Then populate it during init and then have the clock code use it
directly if available? Then it seems you would not need the
static struct clk_iomap *clk_memmaps[CLK_MAX_MEMMAPS] at all?
Doing a change like this should probably be planned, but it is a larger
modification. Currently none of the low-level clock APIs support this,
but instead expect a direct iomem pointer against which they can do
arithmetic operations. The major problem is the companion clocks, which
just XOR some bits in the registers to get ICLK / IDLEST register offset
from FCLK.
So, for now, clock code just uses the void __iomem pointer as a storage
class for struct clk_omap_reg, on which arithmetic operations can be done.
I did this change as a trial, and this is the diff required to get it
working:
arch/arm/mach-omap2/clkt_iclk.c | 20 -
arch/arm/mach-omap2/clock.c | 47
+--
arch/arm/mach-omap2/clock.h |8 +++
arch/arm/mach-omap2/clock2430.c |5 +++--
arch/arm/mach-omap2/clock34xx.c | 36 ++
arch/arm/mach-omap2/clock3517.c | 20 -
arch/arm/mach-omap2/cm.h|4 +++-
arch/arm/mach-omap2/cm2xxx.c|9 +++-
arch/arm/mach-omap2/cm3xxx.c| 10 +++--
drivers/clk/ti/clk.c| 10 +
drivers/clk/ti/divider.c| 24 ++--
drivers/clk/ti/dpll.c | 11 -
drivers/clk/ti/gate.c | 21 +++--
drivers/clk/ti/interface.c |9
drivers/clk/ti/mux.c| 22 --
include/linux/clk/ti.h |5 +++--
16 files changed, 137 insertions(+), 124 deletions(-)
I think we should probably keep this out of this set now and do this
while moving the OMAP core clock support code under clock driver... just
to keep it more easily manageable.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote: On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote: I think we now have a new error: (seen with omap2plus_defconfig) on next-20150324 : ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size' referenced in expression make: *** [vmlinux] Error 1 Thanks, I am seeing that too. My armchair suggestion is that the following should be reverted. e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page) Can you try again with the latest -next please? We've merged an additional patch aimed at sorting this out. Reverting isn't really an option, as there's an awful lot of code that depends on the bounce page removal. Will -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] ASoC: davinci-evm: drop un-necessary remove function
From: Manish Badarkhe manis...@ti.com
As davinci card gets registered using 'devm_' api
there is no need to unregister the card in 'remove'
function.
Hence drop the 'remove' function.
Signed-off-by: Manish Badarkhe manis...@ti.com
Signed-off-by: Jyri Sarha jsa...@ti.com
---
sound/soc/davinci/davinci-evm.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/sound/soc/davinci/davinci-evm.c b/sound/soc/davinci/davinci-evm.c
index b6bb594..8c2b9be 100644
--- a/sound/soc/davinci/davinci-evm.c
+++ b/sound/soc/davinci/davinci-evm.c
@@ -425,18 +425,8 @@ static int davinci_evm_probe(struct platform_device *pdev)
return ret;
}
-static int davinci_evm_remove(struct platform_device *pdev)
-{
- struct snd_soc_card *card = platform_get_drvdata(pdev);
-
- snd_soc_unregister_card(card);
-
- return 0;
-}
-
static struct platform_driver davinci_evm_driver = {
.probe = davinci_evm_probe,
- .remove = davinci_evm_remove,
.driver = {
.name = davinci_evm,
.pm = snd_soc_pm_ops,
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 4/7] dmaengine: omap-dma: Use defines for dma channels and request count
On 03/26/2015 12:57 PM, Vinod Koul wrote: On Wed, Mar 11, 2015 at 03:23:27PM +0200, Peter Ujfalusi wrote: Instead of magic numbers in the code, use define for number of logical DMA channels and DMA requests. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/dma/omap-dma.c | 7 +-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c index 7dd6dd121681..56c33e93dd24 100644 --- a/drivers/dma/omap-dma.c +++ b/drivers/dma/omap-dma.c @@ -22,6 +22,9 @@ #include virt-dma.h +#define OMAP_SDMA_REQUESTS 127 +#define OMAP_SDMA_CHANNELS 32 Again why dont we put these things in DT ? They are in DT, the next patch will take the needed information from there and uses these values as fallback values in case they are missing for some reason. -- Péter -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] dmaengine: Add driver for TI DMA crossbar on DRA7x
On 03/26/2015 12:56 PM, Vinod Koul wrote:
+#define TI_XBAR_OUTPUTS 127
+#define TI_XBAR_INPUTS 256
Ideally this should be moved to DT. Will next revision of this chip always
support these output and inputs?
They are coming from DT. I'm using these as fall back values in case we can
not get this from DT and a warning will be printed in case if this unlikely
event happens.
+
+static DEFINE_IDR(map_idr);
+
+struct ti_dma_xbar_data {
+struct dma_router dmarouter;
+struct regmap *regmap;
+
+uint safe_val; /* Value to rest the crossbar lines */
+uint xbar_requests; /* number of DMA requests connected to XBAR */
+uint dma_requests; /* number of DMA requests forwarded to DMA */
+
+void __iomem *iomem;
+};
+
+struct ti_dma_xbar_map {
+int xbar_in;
+int xbar_out;
+};
+
+static void ti_dma_xbar_free(struct device *dev, void *route_data)
+{
+struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
+struct ti_dma_xbar_map *map = route_data;
+
+dev_dbg(dev, Unmapping XBAR%d (was routed to %d)\n,
+map-xbar_in, map-xbar_out);
+
+regmap_write(xbar-regmap, map-xbar_out * 2, 0);
just out of curiosity how much do you save using regmap :)
good point, not much I guess. I had it implemented w/o regmap as well, but
thought why not use regmap if it is available.
+static int ti_dma_xbar_probe(struct platform_device *pdev)
+{
+struct device_node *node = pdev-dev.of_node;
+struct device_node *dma_node;
+struct ti_dma_xbar_data *xbar;
+struct resource *res;
+void __iomem *iomem;
+int i, ret;
+
+if (!node)
+return -ENODEV;
+
+dma_node = of_parse_phandle(node, dma-device, 0);
+if (!dma_node) {
+dev_err(pdev-dev, Can't get target DMA node\n);
+return -ENODEV;
+}
+
+xbar = devm_kzalloc(pdev-dev, sizeof(*xbar), GFP_KERNEL);
+if (!xbar)
+return -ENOMEM;
+
+if (of_property_read_u32(dma_node, dma-requests,
+ xbar-dma_requests)) {
+dev_info(pdev-dev,
+ Missing XBAR output information, using %u.\n,
+ TI_XBAR_OUTPUTS);
+xbar-dma_requests = TI_XBAR_OUTPUTS;
+}
+of_node_put(dma_node);
_put here?
The code takes the real dma controller's node and it should be put back after
I have got the information I needed from it (number of DMA requests).
+int omap_dmaxbar_init(void)
+{
+return platform_driver_register(ti_dma_xbar_driver);
+}
+arch_initcall(omap_dmaxbar_init);
why arch_initcall?
It should be on the same init level as the real DMA controller. omap-dma at
the moment, but in some platforms this can work with the edma as well.
Since all device in the system (well most of them anyway) uses DMA it is
better to not delay their probe with deferring because the crossbar driver is
still not loaded
--
Péter
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ASoC: davinci-evm: drop un-necessary remove function
On Thu, Mar 26, 2015 at 03:38:25PM +0200, Jyri Sarha wrote: From: Manish Badarkhe manis...@ti.com As davinci card gets registered using 'devm_' api there is no need to unregister the card in 'remove' function. Hence drop the 'remove' function. Not only that but the current remove function creates a double free. Applied, thanks. signature.asc Description: Digital signature
Re: [RESEND PATCH 2/2] bus: ocp2scp: SYNC2 value should be changed to 0x6
* Kishon Vijay Abraham I kis...@ti.com [150317 04:25]: As per the TRMs of AM572x, OMAP4430, OMAP4460, OMAP543x, the value of SYNC2 must be set to 0x6 in order to ensure correct operation. So modified the SYNC2 value of OCP2SCP TIMING register to 0x6 in all the platforms that use OCP2SCP driver except AM437x. Also introduced a new compatible property since we don't want to modify the OCP2SCP TIMING register for AM437x. OK thanks I'll apply both into omap-for-v4.1/fixes-not-urgent as it seems we've gotten away with it for quite a few years now, and I don't see any specific description of what these fix. If that's not the case, please let me know. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] ARM: DRA7: Enable Cortex A15 errata 798181
* Nishanth Menon n...@ti.com [150325 16:32]: On 03/25/2015 06:25 PM, Praneeth Bajjuri wrote: ARM errata 798181 is applicable for OMAP5/DRA7 based devices. So enable the same in the build. DRA7xx is based on Cortex-A15 r2p2 revision. ARM Errata extract and workaround information is as below. On Cortex-A15 (r0p0..r3p2) the TLBI*IS/DSB operations are not adequately shooting down all use of the old entries. The ARM_ERRATA_798181 option enables the Linux kernel workaround for this erratum which sends an IPI to the CPUs that are running the same ASID as the one being invalidated. Signed-off-by: Praneeth Bajjuri prane...@ti.com --- arch/arm/mach-omap2/Kconfig |1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig index c7d8d86..3e4b4ae 100644 --- a/arch/arm/mach-omap2/Kconfig +++ b/arch/arm/mach-omap2/Kconfig @@ -69,6 +69,7 @@ config SOC_DRA7XX select ARM_GIC select HAVE_ARM_ARCH_TIMER select IRQ_CROSSBAR + select ARM_ERRATA_798181 if SMP config ARCH_OMAP2PLUS bool Gee thanks and Apologies on missing this patch. Acked-by: Nishanth Menon n...@ti.com Seen on DRA7 only builds, so kinda slipped radar a bit.. verified to apply on v4.0-rc1 Is this needed as a fix for v4.0-rc series or can this wait for v4.1? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] arm: mach-omap2: remove superfluous NULL pointer check
* Stefan Agner ste...@agner.ch [150321 17:00]:
The NULL pointer check for superset-muxnames will always evaluate
true since muxnames is an array within struct omap_mux. Remove the
superfluous check to avoid warnings when using LLVM/clang.
Signed-off-by: Stefan Agner ste...@agner.ch
Applying into omap-for-v4.1/fixes-not-urgent thanks.
Tony
---
For the reference, the warning generated by LLVM/clang:
arch/arm/mach-omap2/mux.c:1056:18: warning: address of array
'superset-muxnames' will always evaluate to 'true'
[-Wpointer-bool-conversion]
if (!superset-muxnames || !superset-muxnames[0]) {
~~~^~~~
arch/arm/mach-omap2/mux.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/mux.c b/arch/arm/mach-omap2/mux.c
index 78064b0..176eef6 100644
--- a/arch/arm/mach-omap2/mux.c
+++ b/arch/arm/mach-omap2/mux.c
@@ -1053,7 +1053,7 @@ static void __init omap_mux_init_list(struct
omap_mux_partition *partition,
struct omap_mux *entry;
#ifdef CONFIG_OMAP_MUX
- if (!superset-muxnames || !superset-muxnames[0]) {
+ if (!superset-muxnames[0]) {
superset++;
continue;
}
--
2.3.3
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patch phy: Add a driver for dm816x USB PHY added to linux-phy tree
* Matthijs van Duin matthijsvand...@gmail.com [150326 00:02]: On 26 March 2015 at 00:36, Kishon Vijay Abraham I kis...@ti.com wrote: Let me know if you find any problems with this patch. I spotted a minor issue in drivers/phy/Kconfig: + Enable this for dm81xx USB to work. This should say dm816x instead. Yes that's correct, the phy on dm814x seems to be like on am335x, not like on dm816x. Kishon, let me know if you prefer a follow-up patch to fix this. I'm not seeing the original mail for this thread anywhere for some reason BTW. It does not seem to be in the mailing list archives either, well at least not yet. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 11/35] ARM: OMAP2+: clock: move clock provider infrastructure to clock driver
* Tero Kristo t-kri...@ti.com [150326 03:55]:
On 03/26/2015 09:24 AM, Tero Kristo wrote:
On 03/26/2015 01:17 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [150325 08:12]:
Splits the clock provider init out of the PRM driver and moves it to
clock driver. This is needed so that once the PRCM drivers are
separated,
they can logically just access the clock driver not needing to go
through
common PRM code. This would be wrong in the case of control module for
example.
...
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
...
-u32 omap2_clk_readl(struct clk_hw_omap *clk, void __iomem *reg)
+u32 omap2_clk_memmap_readl(void __iomem *reg)
{
-u32 val;
+struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
-if (clk-flags MEMMAP_ADDRESSING) {
-struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
-val = readl_relaxed(clk_memmaps[r-index] + r-offset);
-} else {
-val = readl_relaxed(reg);
-}
+return readl_relaxed(clk_memmaps[r-index] + r-offset);
+}
The cast from void __iomem *reg to struct clk_omap_reg *r looks still
nasty.. Why don't you add the IO address into struct clk_omap_reg:
struct clk_omap_reg {
u16 offset;
u16 index;
struct regmap *regmap;
void __iomem *addr;
};
...
Then populate it during init and then have the clock code use it
directly if available? Then it seems you would not need the
static struct clk_iomap *clk_memmaps[CLK_MAX_MEMMAPS] at all?
Doing a change like this should probably be planned, but it is a larger
modification. Currently none of the low-level clock APIs support this,
but instead expect a direct iomem pointer against which they can do
arithmetic operations. The major problem is the companion clocks, which
just XOR some bits in the registers to get ICLK / IDLEST register offset
from FCLK.
So, for now, clock code just uses the void __iomem pointer as a storage
class for struct clk_omap_reg, on which arithmetic operations can be done.
Well how about keep the check if (clk-flags MEMMAP_ADDRESSING) at
least? Maybe WARN_ON(!(clk-flags MEMMAP_ADDRESSING))?
Otherwise this could be a nightmare to debug if anything goes wrong.
I did this change as a trial, and this is the diff required to get it
working:
arch/arm/mach-omap2/clkt_iclk.c | 20 -
arch/arm/mach-omap2/clock.c | 47
+--
arch/arm/mach-omap2/clock.h |8 +++
arch/arm/mach-omap2/clock2430.c |5 +++--
arch/arm/mach-omap2/clock34xx.c | 36 ++
arch/arm/mach-omap2/clock3517.c | 20 -
arch/arm/mach-omap2/cm.h|4 +++-
arch/arm/mach-omap2/cm2xxx.c|9 +++-
arch/arm/mach-omap2/cm3xxx.c| 10 +++--
drivers/clk/ti/clk.c| 10 +
drivers/clk/ti/divider.c| 24 ++--
drivers/clk/ti/dpll.c | 11 -
drivers/clk/ti/gate.c | 21 +++--
drivers/clk/ti/interface.c |9
drivers/clk/ti/mux.c| 22 --
include/linux/clk/ti.h |5 +++--
16 files changed, 137 insertions(+), 124 deletions(-)
I think we should probably keep this out of this set now and do this while
moving the OMAP core clock support code under clock driver... just to keep
it more easily manageable.
OK fine with me to do that as a follow-up patch.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 11/35] ARM: OMAP2+: clock: move clock provider infrastructure to clock driver
On 03/26/2015 07:30 PM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [150326 03:55]:
On 03/26/2015 09:24 AM, Tero Kristo wrote:
On 03/26/2015 01:17 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [150325 08:12]:
Splits the clock provider init out of the PRM driver and moves it to
clock driver. This is needed so that once the PRCM drivers are
separated,
they can logically just access the clock driver not needing to go
through
common PRM code. This would be wrong in the case of control module for
example.
...
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
...
-u32 omap2_clk_readl(struct clk_hw_omap *clk, void __iomem *reg)
+u32 omap2_clk_memmap_readl(void __iomem *reg)
{
-u32 val;
+struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
-if (clk-flags MEMMAP_ADDRESSING) {
-struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
-val = readl_relaxed(clk_memmaps[r-index] + r-offset);
-} else {
-val = readl_relaxed(reg);
-}
+return readl_relaxed(clk_memmaps[r-index] + r-offset);
+}
The cast from void __iomem *reg to struct clk_omap_reg *r looks still
nasty.. Why don't you add the IO address into struct clk_omap_reg:
struct clk_omap_reg {
u16 offset;
u16 index;
struct regmap *regmap;
void __iomem *addr;
};
...
Then populate it during init and then have the clock code use it
directly if available? Then it seems you would not need the
static struct clk_iomap *clk_memmaps[CLK_MAX_MEMMAPS] at all?
Doing a change like this should probably be planned, but it is a larger
modification. Currently none of the low-level clock APIs support this,
but instead expect a direct iomem pointer against which they can do
arithmetic operations. The major problem is the companion clocks, which
just XOR some bits in the registers to get ICLK / IDLEST register offset
from FCLK.
So, for now, clock code just uses the void __iomem pointer as a storage
class for struct clk_omap_reg, on which arithmetic operations can be done.
Well how about keep the check if (clk-flags MEMMAP_ADDRESSING) at
least? Maybe WARN_ON(!(clk-flags MEMMAP_ADDRESSING))?
Otherwise this could be a nightmare to debug if anything goes wrong.
Yea, adding a warning is a good idea for now, I'll do this update
tomorrow morning.
-Tero
I did this change as a trial, and this is the diff required to get it
working:
arch/arm/mach-omap2/clkt_iclk.c | 20 -
arch/arm/mach-omap2/clock.c | 47
+--
arch/arm/mach-omap2/clock.h |8 +++
arch/arm/mach-omap2/clock2430.c |5 +++--
arch/arm/mach-omap2/clock34xx.c | 36 ++
arch/arm/mach-omap2/clock3517.c | 20 -
arch/arm/mach-omap2/cm.h|4 +++-
arch/arm/mach-omap2/cm2xxx.c|9 +++-
arch/arm/mach-omap2/cm3xxx.c| 10 +++--
drivers/clk/ti/clk.c| 10 +
drivers/clk/ti/divider.c| 24 ++--
drivers/clk/ti/dpll.c | 11 -
drivers/clk/ti/gate.c | 21 +++--
drivers/clk/ti/interface.c |9
drivers/clk/ti/mux.c| 22 --
include/linux/clk/ti.h |5 +++--
16 files changed, 137 insertions(+), 124 deletions(-)
I think we should probably keep this out of this set now and do this while
moving the OMAP core clock support code under clock driver... just to keep
it more easily manageable.
OK fine with me to do that as a follow-up patch.
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 4/4] DTS: ARM: OMAP3-N900: Add lis3lv02d support
* Sebastian Reichel s...@kernel.org [150321 13:20]:
From: Sebastian Reichel s...@kernel.or
This adds support for the N900's accelerometer to
the Nokia N900 DTS file.
Signed-off-by: Sebastian Reichel s...@kernel.org
This at least currently does not conflict with anything I have
queued, so I suggest you try to get Greg to take the whole set:
Acked-by: Tony Lindgren t...@atomide.com
---
arch/arm/boot/dts/omap3-n900.dts | 52
1 file changed, 52 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-n900.dts
b/arch/arm/boot/dts/omap3-n900.dts
index 6040327..b02a717 100644
--- a/arch/arm/boot/dts/omap3-n900.dts
+++ b/arch/arm/boot/dts/omap3-n900.dts
@@ -602,6 +602,58 @@
pinctrl-0 = i2c3_pins;
clock-frequency = 40;
+
+ lis302dl: lis3lv02d@1d {
+ compatible = st,lis3lv02d;
+ reg = 0x1d;
+
+ Vdd-supply = vaux1;
+ Vdd_IO-supply = vio;
+
+ interrupt-parent = gpio6;
+ interrupts = 21 20; /* 181 and 180 */
+
+ /* click flags */
+ st,click-single-x;
+ st,click-single-y;
+ st,click-single-z;
+
+ /* Limits are 0.5g * value */
+ st,click-threshold-x = 8;
+ st,click-threshold-y = 8;
+ st,click-threshold-z = 10;
+
+ /* Click must be longer than time limit */
+ st,click-time-limit = 9;
+
+ /* Kind of debounce filter */
+ st,click-latency = 50;
+
+ /* Interrupt line 2 for click detection */
+ st,irq2-click;
+
+ st,wakeup-x-hi;
+ st,wakeup-y-hi;
+ st,wakeup-threshold = (800/18); /* millig-value / 18 to get
HW values */
+
+ st,wakeup2-z-hi;
+ st,wakeup2-threshold = (900/18); /* millig-value / 18 to get
HW values */
+
+ st,hipass1-disable;
+ st,hipass2-disable;
+
+ st,axis-x = 1;/* LIS3_DEV_X */
+ st,axis-y = (-2); /* LIS3_INV_DEV_Y */
+ st,axis-z = (-3); /* LIS3_INV_DEV_Z */
+
+ st,min-limit-x = (-32);
+ st,min-limit-y = 3;
+ st,min-limit-z = 3;
+
+ st,max-limit-x = (-3);
+ st,max-limit-y = 32;
+ st,max-limit-z = 32;
+ };
};
mmc1 {
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V2 2/2] ARM: dts: am57xx-beagle-x15: Add thermal map to include fan and tmp102
* Eduardo Valentin edubez...@gmail.com [150324 08:17]: On Mon, Mar 23, 2015 at 02:39:39PM -0500, Nishanth Menon wrote: BeagleBoard-X15 has capability for a fan and has an onboard TMP102 temperature sensor as well. This allows us to create a new thermal zone (called, un-imaginatively board), and allows us to use some active cooling as temperatures start edge upward in the system by creating a new alert temperature (emperically 50C) for cpu. NOTE: Fan is NOT mounted by default on the platform, in such a case, all we end up doing is switch on a regulator and leak very minimal current. Signed-off-by: Nishanth Menon n...@ti.com Acked-by: Eduardo Valentin edubez...@gmail.com Applying both of these into omap-for-v4.1/fixes-not-urgent thanks. Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
On Thu, Mar 26, 2015 at 08:29:21AM -0700, Tyler Baker wrote: On 26 March 2015 at 06:36, Will Deacon will.dea...@arm.com wrote: On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote: On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote: I think we now have a new error: (seen with omap2plus_defconfig) on next-20150324 : ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size' referenced in expression make: *** [vmlinux] Error 1 Thanks, I am seeing that too. My armchair suggestion is that the following should be reverted. e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page) Can you try again with the latest -next please? We've merged an additional patch aimed at sorting this out. Reverting isn't really an option, as there's an awful lot of code that depends on the bounce page removal. Here are the kernelci.org -next results[1], if you click the build status you can dig down into the build failures. next-20150326 has now hit a compiler bug, Arnd mentioned he was looking into this issue. I have confirmed that next-20150326 does not compile without the following reverted: 12eb3e833961 (ARM: kvm: assert on HYP section boundaries not actual code size) e60a1fec44a2 (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f6200 (ARM, arm64: kvm: get rid of the bounce page) -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: patch phy: Add a driver for dm816x USB PHY added to linux-phy tree
On 26 March 2015 at 00:36, Kishon Vijay Abraham I kis...@ti.com wrote: Let me know if you find any problems with this patch. I spotted a minor issue in drivers/phy/Kconfig: + Enable this for dm81xx USB to work. This should say dm816x instead. Matthijs -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv5 11/35] ARM: OMAP2+: clock: move clock provider infrastructure to clock driver
On 03/26/2015 01:17 AM, Tony Lindgren wrote:
* Tero Kristo t-kri...@ti.com [150325 08:12]:
Splits the clock provider init out of the PRM driver and moves it to
clock driver. This is needed so that once the PRCM drivers are separated,
they can logically just access the clock driver not needing to go through
common PRM code. This would be wrong in the case of control module for
example.
...
--- a/arch/arm/mach-omap2/clock.c
+++ b/arch/arm/mach-omap2/clock.c
...
-u32 omap2_clk_readl(struct clk_hw_omap *clk, void __iomem *reg)
+u32 omap2_clk_memmap_readl(void __iomem *reg)
{
- u32 val;
+ struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
- if (clk-flags MEMMAP_ADDRESSING) {
- struct clk_omap_reg *r = (struct clk_omap_reg *)reg;
- val = readl_relaxed(clk_memmaps[r-index] + r-offset);
- } else {
- val = readl_relaxed(reg);
- }
+ return readl_relaxed(clk_memmaps[r-index] + r-offset);
+}
The cast from void __iomem *reg to struct clk_omap_reg *r looks still
nasty.. Why don't you add the IO address into struct clk_omap_reg:
struct clk_omap_reg {
u16 offset;
u16 index;
struct regmap *regmap;
void __iomem *addr;
};
...
Then populate it during init and then have the clock code use it
directly if available? Then it seems you would not need the
static struct clk_iomap *clk_memmaps[CLK_MAX_MEMMAPS] at all?
Doing a change like this should probably be planned, but it is a larger
modification. Currently none of the low-level clock APIs support this,
but instead expect a direct iomem pointer against which they can do
arithmetic operations. The major problem is the companion clocks, which
just XOR some bits in the registers to get ICLK / IDLEST register offset
from FCLK.
So, for now, clock code just uses the void __iomem pointer as a storage
class for struct clk_omap_reg, on which arithmetic operations can be done.
-Tero
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] ARM: dts: dra7: remove ti,hwmod property from pcie phy
On Thu, 26 Mar 2015, Kishon Vijay Abraham I wrote: On Thursday 19 March 2015 10:19 PM, Paul Walmsley wrote: On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 05:45 PM, Paul Walmsley wrote: On Thu, 19 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/19/2015 04:55 PM, Paul Walmsley wrote: On Wed, 18 Mar 2015, grygorii.stras...@linaro.org wrote: On 03/18/2015 06:57 PM, Tony Lindgren wrote: * Grygorii Strashko grygorii.stras...@ti.com [150318 09:37]: As I can see Patch 1 from this series was merged in 4.0-rc4, but this patch wasn't. As result, I can see below warning all the time during boot now: [0.594591] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' OK. Is this needed as a fix for the v4.0-rc series, or can this wait for v4.1? I think, Yes. These two patches should go all together, because they are interrelated. Does the warning result in a functional problem, or is it just a warning? PCE1 PHY device is not registered any more. How does the second patch fix that? I've re-checked it - sorry for disinfo. PHY devices are created, but omap_device_fail_pm_domain is assigned to them. As result Runtime PM is not working any more. [0.592501] platform 4a094000.pciephy: Cannot lookup hwmod 'pcie1-phy' [0.597510] pinctrl-single 4a003400.pinmux: 281 pins at pa fc003400 size 1124 [0.602794] ti-pipe3 4a094000.pciephy: _od_fail_runtime_resume: FIXME: missing hwmod/omap_dev info When ti,hwmods is not present PCI PHY will be added as regular Platform device and Runtime PM will work again. OK then it should definitely go up as a fix. Kishon, for future references, those two patches should have been combined into a single patch. As it stands now, if someone bisects down to that first patch, it sounds like PM will be at least partially broken. Too bad I don't have a DRA7xx board where things like this can be tested before being sent upstream. huh.. was under the assumption that patches for device tree and the kernel patches should be separate. Generally that's true, _unless_ separating them will break something between the two patches. That appears to be the case here. The important thing is to make sure every single commit builds and functions at least as well as the previous commit - i.e., there should be no regressions. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mmc: omap_hsmmc: stop using .enable and .disable method.
On 26 March 2015 at 02:18, NeilBrown ne...@suse.de wrote:
On Thu, 26 Mar 2015 08:43:37 +1100 NeilBrown n...@brown.name wrote:
enable and disable are only used to get and put
runtime pm references. .set_ios already does this
itself, and other drivers just do it in set_ios
and .request without using enable/disable.
So add pm_runtime get/put to omap_hsmmc_request(),
and discard the enable/disable methods.
Signed-off-by: NeilBrown n...@brown.name
Sorry, that patch wasn't much good. This one I have really tested properly
and checked that the 'put' match the 'get's and that the device to regularly
go to sleep as expected.
NeilBrown
From: NeilBrown n...@brown.name
Date: Thu, 26 Mar 2015 08:28:43 +1100
Subject: [PATCH] mmc: omap_hsmmc: stop using .enable and .disable method.
enable and disable are only used to get and put
runtime pm references. .set_ios already does this
itself, and other drivers just do it in set_ios
and .request without using enable/disable.
So add pm_runtime get/put to omap_hsmmc_request(),
and discard the enable/disable methods.
Signed-off-by: NeilBrown n...@brown.name
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f84cfb01716d..2cb81538a612 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -882,6 +882,8 @@ static void omap_hsmmc_request_done(struct
omap_hsmmc_host *host, struct mmc_req
return;
host-mrq = NULL;
mmc_request_done(host-mmc, mrq);
+ pm_runtime_mark_last_busy(host-dev);
+ pm_runtime_put_autosuspend(host-dev);
}
How about adding a function like this:
_omap_hsmmc_request_done(struct omap_hsmmc_host *host, struct mmc_req)
{
mmc_request_done(host-mmc, mrq);
pm_runtime_mark_last_busy(host-dev);
pm_runtime_put_autosuspend(host-dev);
}
Then just invoke it from those places were needed?
/*
@@ -1305,6 +1307,8 @@ static void omap_hsmmc_dma_callback(void *param)
host-mrq = NULL;
mmc_request_done(host-mmc, mrq);
+ pm_runtime_mark_last_busy(host-dev);
+ pm_runtime_put_autosuspend(host-dev);
}
}
@@ -1537,6 +1541,7 @@ static void omap_hsmmc_request(struct mmc_host *mmc,
struct mmc_request *req)
BUG_ON(host-req_in_progress);
BUG_ON(host-dma_ch != -1);
+ pm_runtime_get_sync(host-dev);
if (host-protect_card) {
if (host-reqs_blocked 3) {
/*
@@ -1553,6 +1558,8 @@ static void omap_hsmmc_request(struct mmc_host *mmc,
struct mmc_request *req)
req-data-error = -EBADF;
req-cmd-retries = 0;
mmc_request_done(mmc, req);
+ pm_runtime_mark_last_busy(host-dev);
+ pm_runtime_put_autosuspend(host-dev);
return;
} else if (host-reqs_blocked)
host-reqs_blocked = 0;
@@ -1566,6 +1573,8 @@ static void omap_hsmmc_request(struct mmc_host *mmc,
struct mmc_request *req)
req-data-error = err;
host-mrq = NULL;
mmc_request_done(mmc, req);
+ pm_runtime_mark_last_busy(host-dev);
+ pm_runtime_put_autosuspend(host-dev);
return;
}
if (req-sbc !(host-flags AUTO_CMD23)) {
@@ -1778,25 +1787,6 @@ static void omap_hsmmc_conf_bus_power(struct
omap_hsmmc_host *host)
set_sd_bus_power(host);
}
-static int omap_hsmmc_enable_fclk(struct mmc_host *mmc)
-{
- struct omap_hsmmc_host *host = mmc_priv(mmc);
-
- pm_runtime_get_sync(host-dev);
-
- return 0;
-}
-
-static int omap_hsmmc_disable_fclk(struct mmc_host *mmc)
-{
- struct omap_hsmmc_host *host = mmc_priv(mmc);
-
- pm_runtime_mark_last_busy(host-dev);
- pm_runtime_put_autosuspend(host-dev);
-
- return 0;
-}
-
static int omap_hsmmc_multi_io_quirk(struct mmc_card *card,
unsigned int direction, int blk_size)
{
@@ -1808,8 +1798,6 @@ static int omap_hsmmc_multi_io_quirk(struct mmc_card
*card,
}
static struct mmc_host_ops omap_hsmmc_ops = {
- .enable = omap_hsmmc_enable_fclk,
- .disable = omap_hsmmc_disable_fclk,
.post_req = omap_hsmmc_post_req,
.pre_req = omap_hsmmc_pre_req,
.request = omap_hsmmc_request,
Finally, I think you have forgotten to deal with pm_runtime_get|put*()
in omap_hsmmc_enable_sdio_irq().
Kind regards
Uffe
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] mmc: omap_hsmmc: stop using .enable and .disable method.
On 26 March 2015 at 08:38, Ulf Hansson ulf.hans...@linaro.org wrote:
On 26 March 2015 at 02:18, NeilBrown ne...@suse.de wrote:
On Thu, 26 Mar 2015 08:43:37 +1100 NeilBrown n...@brown.name wrote:
enable and disable are only used to get and put
runtime pm references. .set_ios already does this
itself, and other drivers just do it in set_ios
and .request without using enable/disable.
So add pm_runtime get/put to omap_hsmmc_request(),
and discard the enable/disable methods.
Signed-off-by: NeilBrown n...@brown.name
Sorry, that patch wasn't much good. This one I have really tested properly
and checked that the 'put' match the 'get's and that the device to regularly
go to sleep as expected.
NeilBrown
From: NeilBrown n...@brown.name
Date: Thu, 26 Mar 2015 08:28:43 +1100
Subject: [PATCH] mmc: omap_hsmmc: stop using .enable and .disable method.
enable and disable are only used to get and put
runtime pm references. .set_ios already does this
itself, and other drivers just do it in set_ios
and .request without using enable/disable.
So add pm_runtime get/put to omap_hsmmc_request(),
and discard the enable/disable methods.
Signed-off-by: NeilBrown n...@brown.name
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f84cfb01716d..2cb81538a612 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -882,6 +882,8 @@ static void omap_hsmmc_request_done(struct
omap_hsmmc_host *host, struct mmc_req
return;
host-mrq = NULL;
mmc_request_done(host-mmc, mrq);
+ pm_runtime_mark_last_busy(host-dev);
+ pm_runtime_put_autosuspend(host-dev);
}
How about adding a function like this:
_omap_hsmmc_request_done(struct omap_hsmmc_host *host, struct mmc_req)
{
mmc_request_done(host-mmc, mrq);
pm_runtime_mark_last_busy(host-dev);
pm_runtime_put_autosuspend(host-dev);
}
Then just invoke it from those places were needed?
/*
@@ -1305,6 +1307,8 @@ static void omap_hsmmc_dma_callback(void *param)
host-mrq = NULL;
mmc_request_done(host-mmc, mrq);
+ pm_runtime_mark_last_busy(host-dev);
+ pm_runtime_put_autosuspend(host-dev);
}
}
@@ -1537,6 +1541,7 @@ static void omap_hsmmc_request(struct mmc_host *mmc,
struct mmc_request *req)
BUG_ON(host-req_in_progress);
BUG_ON(host-dma_ch != -1);
+ pm_runtime_get_sync(host-dev);
if (host-protect_card) {
if (host-reqs_blocked 3) {
/*
@@ -1553,6 +1558,8 @@ static void omap_hsmmc_request(struct mmc_host *mmc,
struct mmc_request *req)
req-data-error = -EBADF;
req-cmd-retries = 0;
mmc_request_done(mmc, req);
+ pm_runtime_mark_last_busy(host-dev);
+ pm_runtime_put_autosuspend(host-dev);
return;
} else if (host-reqs_blocked)
host-reqs_blocked = 0;
@@ -1566,6 +1573,8 @@ static void omap_hsmmc_request(struct mmc_host *mmc,
struct mmc_request *req)
req-data-error = err;
host-mrq = NULL;
mmc_request_done(mmc, req);
+ pm_runtime_mark_last_busy(host-dev);
+ pm_runtime_put_autosuspend(host-dev);
return;
}
if (req-sbc !(host-flags AUTO_CMD23)) {
@@ -1778,25 +1787,6 @@ static void omap_hsmmc_conf_bus_power(struct
omap_hsmmc_host *host)
set_sd_bus_power(host);
}
-static int omap_hsmmc_enable_fclk(struct mmc_host *mmc)
-{
- struct omap_hsmmc_host *host = mmc_priv(mmc);
-
- pm_runtime_get_sync(host-dev);
-
- return 0;
-}
-
-static int omap_hsmmc_disable_fclk(struct mmc_host *mmc)
-{
- struct omap_hsmmc_host *host = mmc_priv(mmc);
-
- pm_runtime_mark_last_busy(host-dev);
- pm_runtime_put_autosuspend(host-dev);
-
- return 0;
-}
-
static int omap_hsmmc_multi_io_quirk(struct mmc_card *card,
unsigned int direction, int blk_size)
{
@@ -1808,8 +1798,6 @@ static int omap_hsmmc_multi_io_quirk(struct mmc_card
*card,
}
static struct mmc_host_ops omap_hsmmc_ops = {
- .enable = omap_hsmmc_enable_fclk,
- .disable = omap_hsmmc_disable_fclk,
.post_req = omap_hsmmc_post_req,
.pre_req = omap_hsmmc_pre_req,
.request = omap_hsmmc_request,
Finally, I think you have forgotten to deal with pm_runtime_get|put*()
in omap_hsmmc_enable_sdio_irq().
No, _me_ totally forgot that SDIO IRQ is a special case and from the
above mentioned function we mustn't deal with runtime PM, since that
function is executed in IRQ context. :-)
Also, since omap's runtime PM -suspend() callback disables regular
SDIO IRQS and enables wakeups, this case is already covered. Please
ignore my comment above and sorry for the noise.
Re: Possible regression in next-20150323 due to ARM, arm64: kvm: get rid of the bounce page
On 26 March 2015 at 06:36, Will Deacon will.dea...@arm.com wrote: On Thu, Mar 26, 2015 at 12:39:39AM +, Simon Horman wrote: On Tue, Mar 24, 2015 at 11:13:58AM -0500, Nishanth Menon wrote: I think we now have a new error: (seen with omap2plus_defconfig) on next-20150324 : ./arch/arm/kernel/vmlinux.lds:677: undefined symbol `__hyp_idmap_size' referenced in expression make: *** [vmlinux] Error 1 Thanks, I am seeing that too. My armchair suggestion is that the following should be reverted. e60a1fec44a2f (ARM: kvm: implement replacement for ld's LOG2CEIL()) 06f75a1f62000 (ARM, arm64: kvm: get rid of the bounce page) Can you try again with the latest -next please? We've merged an additional patch aimed at sorting this out. Reverting isn't really an option, as there's an awful lot of code that depends on the bounce page removal. Here are the kernelci.org -next results[1], if you click the build status you can dig down into the build failures. next-20150326 has now hit a compiler bug, Arnd mentioned he was looking into this issue. Will ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel [1] http://kernelci.org/job/next/ Tyler -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/7] dmaengine: of_dma: Support for DMA routers
On Thu, Mar 26, 2015 at 02:11:38PM +0200, Peter Ujfalusi wrote: On 03/26/2015 12:50 PM, Vinod Koul wrote: On Wed, Mar 11, 2015 at 03:23:24PM +0200, Peter Ujfalusi wrote: DMA routers are transparent devices used to mux DMA requests from peripherals to DMA controllers. They are used when the SoC integrates more devices with DMA requests then their controller can handle. DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request lines, but in SoC level it has 205 DMA requests. The of_dma_router will be registered as of_dma_controller with special xlate function and additional parameters and the code will translate and requests a DMA channel from the real DMA controller. This way the router can be transparent for the system while remaining generic enough to be used in different environments. Looks fine, was expecting a Documentation updates as well, but that can come as follow up patch too I have added the DT binding document since this series adds support for routers for platforms booting with DT: Documentation/devicetree/bindings/dma/dma.txt | 28 I meant the update to Documnetation/dmanegine/ for routers :) -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] dmaengine: Add driver for TI DMA crossbar on DRA7x
* Peter Ujfalusi peter.ujfal...@ti.com [150326 05:32]:
On 03/26/2015 12:56 PM, Vinod Koul wrote:
+
+static void ti_dma_xbar_free(struct device *dev, void *route_data)
+{
+ struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
+ struct ti_dma_xbar_map *map = route_data;
+
+ dev_dbg(dev, Unmapping XBAR%d (was routed to %d)\n,
+ map-xbar_in, map-xbar_out);
+
+ regmap_write(xbar-regmap, map-xbar_out * 2, 0);
just out of curiosity how much do you save using regmap :)
good point, not much I guess. I had it implemented w/o regmap as well, but
thought why not use regmap if it is available.
Regmap is nice for slow devices and devices in a shared register
range like the omap syscon general area. For normal use, there's
quite a bit of overhead with regmap compared to just read/write :)
Regards,
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 3/7] dmaengine: Add driver for TI DMA crossbar on DRA7x
On Thu, Mar 26, 2015 at 02:31:30PM +0200, Peter Ujfalusi wrote:
On 03/26/2015 12:56 PM, Vinod Koul wrote:
+#define TI_XBAR_OUTPUTS 127
+#define TI_XBAR_INPUTS256
Ideally this should be moved to DT. Will next revision of this chip always
support these output and inputs?
They are coming from DT. I'm using these as fall back values in case we can
not get this from DT and a warning will be printed in case if this unlikely
event happens.
Oops missed, that. Looks fine then
+
+static DEFINE_IDR(map_idr);
+
+struct ti_dma_xbar_data {
+ struct dma_router dmarouter;
+ struct regmap *regmap;
+
+ uint safe_val; /* Value to rest the crossbar lines */
+ uint xbar_requests; /* number of DMA requests connected to XBAR */
+ uint dma_requests; /* number of DMA requests forwarded to DMA */
+
+ void __iomem *iomem;
+};
+
+struct ti_dma_xbar_map {
+ int xbar_in;
+ int xbar_out;
+};
+
+static void ti_dma_xbar_free(struct device *dev, void *route_data)
+{
+ struct ti_dma_xbar_data *xbar = dev_get_drvdata(dev);
+ struct ti_dma_xbar_map *map = route_data;
+
+ dev_dbg(dev, Unmapping XBAR%d (was routed to %d)\n,
+ map-xbar_in, map-xbar_out);
+
+ regmap_write(xbar-regmap, map-xbar_out * 2, 0);
just out of curiosity how much do you save using regmap :)
good point, not much I guess. I had it implemented w/o regmap as well, but
thought why not use regmap if it is available.
Yes but there is overhead involved in setting it up. I though you have some
latency issues. It is okay to have it :)
Cache is anyways fastest :)
+static int ti_dma_xbar_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev-dev.of_node;
+ struct device_node *dma_node;
+ struct ti_dma_xbar_data *xbar;
+ struct resource *res;
+ void __iomem *iomem;
+ int i, ret;
+
+ if (!node)
+ return -ENODEV;
+
+ dma_node = of_parse_phandle(node, dma-device, 0);
+ if (!dma_node) {
+ dev_err(pdev-dev, Can't get target DMA node\n);
+ return -ENODEV;
+ }
+
+ xbar = devm_kzalloc(pdev-dev, sizeof(*xbar), GFP_KERNEL);
+ if (!xbar)
+ return -ENOMEM;
+
+ if (of_property_read_u32(dma_node, dma-requests,
+ xbar-dma_requests)) {
+ dev_info(pdev-dev,
+ Missing XBAR output information, using %u.\n,
+ TI_XBAR_OUTPUTS);
+ xbar-dma_requests = TI_XBAR_OUTPUTS;
+ }
+ of_node_put(dma_node);
_put here?
The code takes the real dma controller's node and it should be put back after
I have got the information I needed from it (number of DMA requests).
+int omap_dmaxbar_init(void)
+{
+ return platform_driver_register(ti_dma_xbar_driver);
+}
+arch_initcall(omap_dmaxbar_init);
why arch_initcall?
It should be on the same init level as the real DMA controller. omap-dma at
the moment, but in some platforms this can work with the edma as well.
Since all device in the system (well most of them anyway) uses DMA it is
better to not delay their probe with deferring because the crossbar driver is
still not loaded
Deferring if resources not available is the right thing and helps you get rid
of init level ordering magic...
--
~Vinod
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
