Re: LDP: next-20150402: twl4030 regression?
On Mon, Apr 06, 2015 at 01:45:22PM -0500, Nishanth Menon wrote: On 04/06/2015 10:27 AM, Felipe Balbi wrote: Hi, On Mon, Apr 06, 2015 at 10:17:37AM -0500, Nishanth Menon wrote: On 04/06/2015 10:01 AM, Mark Brown wrote: On Mon, Apr 06, 2015 at 02:58:29PM +0100, Russell King - ARM Linux wrote: On Mon, Apr 06, 2015 at 08:53:36AM -0500, Nishanth Menon wrote: at least a description of the problem you're seeing and some attempt at Test was a simple boot test. There seems to be a lockdep reported at the very least in the log provided (see https://github.com/nmenon/kernel-test-logs/blob/next-20150402/omap2plus_defconfig/ldp.txt#L488 ). I think what Mark is trying to say is to include a fuller description of the problem, and don't expect people to fire up their web browser to get a basic overview of what the problem is. Yes, indeed. I hadn't actually opened the links, I might've got round to it later on. My guess is that the problem _appears_ to be that someone's added a call to debug_check_no_locks_held() into schedule_hrtimeout_range_clock() without considering what this means. What it means is that you can't now use usleep_range() from within any driver probe function - which is absolutely absurd. I can't think of any regulator side changes which might be relevant in that period. It's possible that there might be something in the MFD I guess. Ran a few tests since my original email.. 6261b06de565baafa590e58a531a1a5522cea0b6 (regulator: Defer lookup of supply to regulator_get) was the only patch that was introduced in the interval. there seems nothing in mfd either. I still have the following in my log.. trying to further down. I noticed a similar warning with AM437x SK posting intermediate debug results: I did a bisect on the merge commits to identify which tree the regression got introduced, looks like it is the merge from akpm tree - I have not yet looked deeper. b58a6c0b0808 Merge branch 'akpm-current/current' --- FAIL http://paste.ubuntu.org.cn/2540641 ef31288bdf44 Merge remote-tracking branch 'livepatching/for-next' -- OK - http://paste.ubuntu.org.cn/2540778 yeah, this works on my SK too. I bisected it further down to one commit. commit 6dfc11e36ee0 is the first bad commit, but looks like that's not in linux-next anymore. -- balbi signature.asc Description: Digital signature
[PATCH v4 3/8] dmaengine: Add driver for TI DMA crossbar on DRA7x
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 | 185 ++
3 files changed, 190 insertions(+)
create mode 100644 drivers/dma/ti-dma-crossbar.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 91eced044321..33a7401597be 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -234,6 +234,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
@@ -319,6 +322,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 7e8301cb489d..19ac70b8af0a 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -38,6 +38,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 ..5cb1eb7e86d2
--- /dev/null
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -0,0 +1,185 @@
+/*
+ * 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/idr.h
+#include linux/of_address.h
+#include linux/of_device.h
+#include linux/of_dma.h
+
+#define TI_XBAR_OUTPUTS127
+#define TI_XBAR_INPUTS 256
+
+static DEFINE_IDR(map_idr);
+
+struct ti_dma_xbar_data {
+ void __iomem *iomem;
+
+ struct dma_router dmarouter;
+
+ 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 */
+};
+
+struct ti_dma_xbar_map {
+ int xbar_in;
+ int xbar_out;
+};
+
+static inline void ti_dma_xbar_write(void __iomem *iomem, int xbar, int val)
+{
+ writew_relaxed(val, iomem + (xbar * 2));
+}
+
+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);
+
+ ti_dma_xbar_write(xbar-iomem, map-xbar_out, xbar-safe_val);
+ idr_remove(map_idr, map-xbar_out);
+ kfree(map);
+}
+
+static void *ti_dma_xbar_route_allocate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct platform_device *pdev = of_find_device_by_node(ofdma-of_node);
+ struct ti_dma_xbar_data *xbar = platform_get_drvdata(pdev);
+ struct ti_dma_xbar_map *map;
+
+ if (dma_spec-args[0] = xbar-xbar_requests) {
+ dev_err(pdev-dev, Invalid XBAR request number: %d\n,
+ dma_spec-args[0]);
+ return NULL;
+ }
+
+ dma_spec-np = of_parse_phandle(ofdma-of_node, dma-masters, 0);
+ if (!dma_spec-np) {
+ dev_err(pdev-dev, Can't get DMA master\n);
+ return NULL;
+ }
+
+ map = kzalloc(sizeof(*map), GFP_KERNEL);
+ if (!map)
+ return NULL;
+
+ map-xbar_out = idr_alloc(map_idr, NULL, 0, xbar-dma_requests,
+ GFP_KERNEL);
+ map-xbar_in = dma_spec-args[0];
+
+ /* The DMA request is 1 based in sDMA */
+ dma_spec-args[0] = map-xbar_out + 1;
+
+ dev_dbg(pdev-dev, Mapping XBAR%d to DMA%d\n,
+ map-xbar_in, map-xbar_out);
+
+ ti_dma_xbar_write(xbar-iomem, map-xbar_out, map-xbar_in);
+
+ return map;
+}
+
+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;
+
[PATCH v4 0/8] dmaengine/dra7x: DMA router (crossbar support)
Hi, Vinod: is it OK if I send the Documnetation/dmanegine/ update a bit later when we agree on what form it should be? Changes since v3: - Comments from Russell: - Warnings removed in case of non DT boot when taking the DMA request number - Reduced the number of channels presented to DMAengine - removed the dma_sig parameter from omap_dma_chan_init() - Comments from Arnd: - dma-device property renamed to dma-masters - Allow list of phandes in dma-masters Changes since v2: - not using regmap for the TI crossbar driver. Changes since v1: - Comments from Russell King and Paul Bolle addressed: - Use the added defined in the omap-dma changes - MODULE_* removed from the ti-dma-crossbar driver. - DMA router documentation: do not limit the #dma-cells to be the same as the dma controller's #dma-cells. It might be possible to have a router which needs more information than the DMA controller (direct request pairing for example) - Use defines in the ti-dma-crossbar driver - Binding document for the ti-dma-crossbar driver Intro mail from v1: The series adds support for DMA router type of devices. They are used in SoCs which has more peripherals with DMA request lines than the DMA controller can handle. The router itself is not part of the DMA controller and it's operation should be transparent (as it is in the HW) for the SW stack. This series takes into accound the comments Sricharan received for his version of the crossbar driver: https://lkml.org/lkml/2014/3/7/199 This implementation is not tied to any DMA driver so it is possible to use the framework by other vendors, also ACPI version of binding can be easy enough to be added. Regards, Peter --- Peter Ujfalusi (8): dmaengine: of_dma: Support for DMA routers Documentation: devicetree: dma: Binding documentation for TI DMA crossbar dmaengine: Add driver for TI DMA crossbar on DRA7x dmaengine: omap-dma: Use defines for dma channels and request count dmaengine: omap-dma: Take DMA request number from DT if it is available dmaengine: omap-dma: Remove mapping between virtual channels and requests dmaengine: omap-dma: Reduce the number of virtual channels ARM: DTS: dra7x: Integrate sDMA crossbar Documentation/devicetree/bindings/dma/dma.txt | 28 .../devicetree/bindings/dma/ti-dma-crossbar.txt| 52 ++ arch/arm/boot/dts/dra7.dtsi| 57 --- drivers/dma/Kconfig| 4 + drivers/dma/Makefile | 1 + drivers/dma/dmaengine.c| 7 + drivers/dma/of-dma.c | 86 ++ drivers/dma/omap-dma.c | 29 +++- drivers/dma/ti-dma-crossbar.c | 185 + include/linux/dmaengine.h | 17 ++ include/linux/of_dma.h | 21 +++ 11 files changed, 457 insertions(+), 30 deletions(-) create mode 100644 Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt create mode 100644 drivers/dma/ti-dma-crossbar.c -- 2.3.5 -- 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 v4 2/8] Documentation: devicetree: dma: Binding documentation for TI DMA crossbar
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 request
line of the DMA controller.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
.../devicetree/bindings/dma/ti-dma-crossbar.txt| 52 ++
1 file changed, 52 insertions(+)
create mode 100644 Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
diff --git a/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
new file mode 100644
index ..63a48928f3a8
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/ti-dma-crossbar.txt
@@ -0,0 +1,52 @@
+Texas Instruments DMA Crossbar (DMA request router)
+
+Required properties:
+- compatible: ti,dra7-dma-crossbar for DRA7xx DMA crossbar
+- reg: Memory map for accessing module
+- #dma-cells: Should be set to 1.
+ Clients should use the crossbar request number (input)
+- dma-requests:Number of DMA requests the crossbar can receive
+- dma-masters: phandle pointing to the DMA controller
+
+The DMA controller node need to have the following poroperties:
+- dma-requests:Number of DMA requests the controller can handle
+
+Optional properties:
+- ti,dma-safe-map: Safe routing value for unused request lines
+
+Example:
+
+/* DMA controller */
+sdma: dma-controller@4a056000 {
+ compatible = ti,omap4430-sdma;
+ reg = 0x4a056000 0x1000;
+ interrupts =GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH,
+ GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH;
+ #dma-cells = 1;
+ dma-channels = 32;
+ dma-requests = 127;
+};
+
+/* DMA crossbar */
+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-masters = sdma;
+};
+
+/* DMA client */
+uart1: serial@4806a000 {
+ compatible = ti,omap4-uart;
+ reg = 0x4806a000 0x100;
+ interrupts-extended = gic GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH;
+ ti,hwmods = uart1;
+ clock-frequency = 4800;
+ status = disabled;
+ dmas = sdma_xbar 49, sdma_xbar 50;
+ dma-names = tx, rx;
+};
--
2.3.5
--
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 v4 8/8] ARM: DTS: dra7x: Integrate sDMA crossbar
The sDMA requests are routed through the DMA crossbar and without the
crossbar only peripherals using DMA request 0-127 can be used.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/boot/dts/dra7.dtsi | 57 ++---
1 file changed, 33 insertions(+), 24 deletions(-)
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5332b57b4950..a2f4aa01984f 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -303,6 +303,15 @@
dma-requests = 127;
};
+ 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-masters = sdma;
+ };
+
gpio1: gpio@4ae1 {
compatible = ti,omap4-gpio;
reg = 0x4ae1 0x200;
@@ -398,7 +407,7 @@
ti,hwmods = uart1;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 49, sdma 50;
+ dmas = sdma_xbar 49, sdma_xbar 50;
dma-names = tx, rx;
};
@@ -409,7 +418,7 @@
ti,hwmods = uart2;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 51, sdma 52;
+ dmas = sdma_xbar 51, sdma_xbar 52;
dma-names = tx, rx;
};
@@ -420,7 +429,7 @@
ti,hwmods = uart3;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 53, sdma 54;
+ dmas = sdma_xbar 53, sdma_xbar 54;
dma-names = tx, rx;
};
@@ -431,7 +440,7 @@
ti,hwmods = uart4;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 55, sdma 56;
+ dmas = sdma_xbar 55, sdma_xbar 56;
dma-names = tx, rx;
};
@@ -442,7 +451,7 @@
ti,hwmods = uart5;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 63, sdma 64;
+ dmas = sdma_xbar 63, sdma_xbar 64;
dma-names = tx, rx;
};
@@ -453,7 +462,7 @@
ti,hwmods = uart6;
clock-frequency = 4800;
status = disabled;
- dmas = sdma 79, sdma 80;
+ dmas = sdma_xbar 79, sdma_xbar 80;
dma-names = tx, rx;
};
@@ -862,7 +871,7 @@
ti,hwmods = mmc1;
ti,dual-volt;
ti,needs-special-reset;
- dmas = sdma 61, sdma 62;
+ dmas = sdma_xbar 61, sdma_xbar 62;
dma-names = tx, rx;
status = disabled;
pbias-supply = pbias_mmc_reg;
@@ -874,7 +883,7 @@
interrupts = GIC_SPI 81 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mmc2;
ti,needs-special-reset;
- dmas = sdma 47, sdma 48;
+ dmas = sdma_xbar 47, sdma_xbar 48;
dma-names = tx, rx;
status = disabled;
};
@@ -885,7 +894,7 @@
interrupts = GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mmc3;
ti,needs-special-reset;
- dmas = sdma 77, sdma 78;
+ dmas = sdma_xbar 77, sdma_xbar 78;
dma-names = tx, rx;
status = disabled;
};
@@ -896,7 +905,7 @@
interrupts = GIC_SPI 91 IRQ_TYPE_LEVEL_HIGH;
ti,hwmods = mmc4;
ti,needs-special-reset;
- dmas = sdma 57, sdma 58;
+ dmas = sdma_xbar 57, sdma_xbar 58;
dma-names = tx, rx;
status = disabled;
};
@@ -1041,14 +1050,14 @@
#size-cells = 0;
ti,hwmods = mcspi1;
ti,spi-num-cs = 4;
- dmas = sdma 35,
- sdma 36,
- sdma 37,
- sdma 38,
- sdma 39,
-
[PATCH v4 5/8] dmaengine: omap-dma: Take DMA request number from DT if it is available
Use the dma-requests property from DT to get the number of DMA requests.
In case of legacy boot or failure to find the property, use the default
127 as number of requests.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 4065963fbffb..8c41cdb55a4b 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -34,6 +34,7 @@ struct omap_dmadev {
const struct omap_dma_reg *reg_map;
struct omap_system_dma_plat_info *plat;
bool legacy;
+ unsigned dma_requests;
spinlock_t irq_lock;
uint32_t irq_enable_mask;
struct omap_chan *lch_map[OMAP_SDMA_CHANNELS];
@@ -1119,7 +1120,16 @@ static int omap_dma_probe(struct platform_device *pdev)
tasklet_init(od-task, omap_dma_sched, (unsigned long)od);
- for (i = 0; i OMAP_SDMA_REQUESTS; i++) {
+ od-dma_requests = OMAP_SDMA_REQUESTS;
+ if (pdev-dev.of_node of_property_read_u32(pdev-dev.of_node,
+ dma-requests,
+ od-dma_requests)) {
+ dev_info(pdev-dev,
+Missing dma-requests property, using %u.\n,
+OMAP_SDMA_REQUESTS);
+ }
+
+ for (i = 0; i od-dma_requests; i++) {
rc = omap_dma_chan_init(od, i);
if (rc) {
omap_dma_free(od);
--
2.3.5
--
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 v4 6/8] dmaengine: omap-dma: Remove mapping between virtual channels and requests
Do not direct map the virtual channels to sDMA request number. When the
sDMA is behind of a crossbar this direct mapping can cause situations when
certain channel can not be requested since the crossbar request number
will no longer match with the sDMA request line.
The direct mapping for virtual channels with HW request lines will make it
harder to implement MEM_TO_MEM mode for the driver.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 8c41cdb55a4b..5ece72c30216 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -593,6 +593,7 @@ static void omap_dma_free_chan_resources(struct dma_chan
*chan)
omap_free_dma(c-dma_ch);
dev_dbg(od-ddev.dev, freeing channel for %u\n, c-dma_sig);
+ c-dma_sig = 0;
}
static size_t omap_dma_sg_size(struct omap_sg *sg)
@@ -1041,7 +1042,7 @@ static int omap_dma_resume(struct dma_chan *chan)
return 0;
}
-static int omap_dma_chan_init(struct omap_dmadev *od, int dma_sig)
+static int omap_dma_chan_init(struct omap_dmadev *od)
{
struct omap_chan *c;
@@ -1050,7 +1051,6 @@ static int omap_dma_chan_init(struct omap_dmadev *od, int
dma_sig)
return -ENOMEM;
c-reg_map = od-reg_map;
- c-dma_sig = dma_sig;
c-vc.desc_free = omap_dma_desc_free;
vchan_init(c-vc, od-ddev);
INIT_LIST_HEAD(c-node);
@@ -1130,7 +1130,7 @@ static int omap_dma_probe(struct platform_device *pdev)
}
for (i = 0; i od-dma_requests; i++) {
- rc = omap_dma_chan_init(od, i);
+ rc = omap_dma_chan_init(od);
if (rc) {
omap_dma_free(od);
return rc;
@@ -1221,10 +1221,14 @@ static struct platform_driver omap_dma_driver = {
bool omap_dma_filter_fn(struct dma_chan *chan, void *param)
{
if (chan-device-dev-driver == omap_dma_driver.driver) {
+ struct omap_dmadev *od = to_omap_dma_dev(chan-device);
struct omap_chan *c = to_omap_dma_chan(chan);
unsigned req = *(unsigned *)param;
- return req == c-dma_sig;
+ if (req = od-dma_requests) {
+ c-dma_sig = req;
+ return true;
+ }
}
return false;
}
--
2.3.5
--
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 v4 7/8] dmaengine: omap-dma: Reduce the number of virtual channels
Since the mapping between the hardware request lines and channels has been
removed it no longer make sense to have too many channels.
Set the number of channels to match with the number of logical channels
supported by sDMA.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/omap-dma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/omap-dma.c b/drivers/dma/omap-dma.c
index 5ece72c30216..66513fc24e83 100644
--- a/drivers/dma/omap-dma.c
+++ b/drivers/dma/omap-dma.c
@@ -1129,7 +1129,7 @@ static int omap_dma_probe(struct platform_device *pdev)
OMAP_SDMA_REQUESTS);
}
- for (i = 0; i od-dma_requests; i++) {
+ for (i = 0; i OMAP_SDMA_CHANNELS; i++) {
rc = omap_dma_chan_init(od);
if (rc) {
omap_dma_free(od);
--
2.3.5
--
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 v4 1/8] dmaengine: of_dma: Support for DMA routers
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. The driver for the router is
responsible to craft the dma_spec (in the of_dma_route_allocate callback)
which can be used to 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.
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 | 86 +++
include/linux/dmaengine.h | 17 ++
include/linux/of_dma.h| 21 +++
5 files changed, 159 insertions(+)
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
index 82104271e754..6312fb00ce8d 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-masters: phandle of the DMA controller or list of phandles for
+ the DMA controllers the router can direct the signal to.
+- #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.
+- In the node pointed by the dma-masters:
+ - 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-masters = sdma;
+ };
* DMA client
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 24967c89f5d4..c7aa232b4a59 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -267,6 +267,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 cbd4a8aff120..98b3b61624f0 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -45,6 +45,47 @@ 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 of_phandle_args dma_spec_target;
+ void*route_data;
+
+ /* translate the request for the real DMA controller */
+ memcpy(dma_spec_target, dma_spec, sizeof(dma_spec_target));
+ route_data = ofdma-of_dma_route_allocate(dma_spec_target, ofdma);
+
+ ofdma_target = of_dma_find_controller(dma_spec_target);
+ if (!ofdma_target)
+ return NULL;
+
+ chan = ofdma_target-of_dma_xlate(dma_spec_target, ofdma_target);
+ if (chan) {
+ chan-router = ofdma-dma_router;
+ chan-route_data =
[PATCH v4 4/8] dmaengine: omap-dma: Use defines for dma channels and request count
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 167dbaf65742..4065963fbffb 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
+
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 {
@@ -1116,7 +1119,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.5
--
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 v4 3/8] dmaengine: Add driver for TI DMA crossbar on DRA7x
Hi,
On Wed, Apr 08, 2015 at 04:14:47PM +0300, 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 | 185
++
3 files changed, 190 insertions(+)
create mode 100644 drivers/dma/ti-dma-crossbar.c
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index 91eced044321..33a7401597be 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -234,6 +234,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
@@ -319,6 +322,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 7e8301cb489d..19ac70b8af0a 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -38,6 +38,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 ..5cb1eb7e86d2
--- /dev/null
+++ b/drivers/dma/ti-dma-crossbar.c
@@ -0,0 +1,185 @@
+/*
+ * 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/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
+
+static DEFINE_IDR(map_idr);
+
+struct ti_dma_xbar_data {
+ void __iomem *iomem;
+
+ struct dma_router dmarouter;
+
+ 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 */
+};
+
+struct ti_dma_xbar_map {
+ int xbar_in;
+ int xbar_out;
+};
+
+static inline void ti_dma_xbar_write(void __iomem *iomem, int xbar, int val)
+{
+ writew_relaxed(val, iomem + (xbar * 2));
Silently casting val (an integer) to a u16 isn't really nice I
guess. At least you could be upfront about it in the prototype.
+}
+
+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);
+
+ ti_dma_xbar_write(xbar-iomem, map-xbar_out, xbar-safe_val);
+ idr_remove(map_idr, map-xbar_out);
+ kfree(map);
+}
+
+static void *ti_dma_xbar_route_allocate(struct of_phandle_args *dma_spec,
+ struct of_dma *ofdma)
+{
+ struct platform_device *pdev = of_find_device_by_node(ofdma-of_node);
+ struct ti_dma_xbar_data *xbar = platform_get_drvdata(pdev);
+ struct ti_dma_xbar_map *map;
+
+ if (dma_spec-args[0] = xbar-xbar_requests) {
+ dev_err(pdev-dev, Invalid XBAR request number: %d\n,
+ dma_spec-args[0]);
+ return NULL;
+ }
+
+ dma_spec-np = of_parse_phandle(ofdma-of_node, dma-masters, 0);
+ if (!dma_spec-np) {
+ dev_err(pdev-dev, Can't get DMA master\n);
+ return NULL;
+ }
+
+ map = kzalloc(sizeof(*map), GFP_KERNEL);
+ if (!map)
+ return NULL;
You're leaking dma_spec-np.
+
+ map-xbar_out = idr_alloc(map_idr, NULL, 0, xbar-dma_requests,
+ GFP_KERNEL);
+ map-xbar_in = dma_spec-args[0];
+
+ /* The DMA request is 1 based in sDMA */
+ dma_spec-args[0] = map-xbar_out + 1;
+
+ dev_dbg(pdev-dev, Mapping XBAR%d to DMA%d\n,
+ map-xbar_in, map-xbar_out);
+
+ ti_dma_xbar_write(xbar-iomem, map-xbar_out, map-xbar_in);
+
Re: [PATCH v4 1/8] dmaengine: of_dma: Support for DMA routers
Hi,
On Wed, Apr 08, 2015 at 04:14:45PM +0300, 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. The driver for the router is
responsible to craft the dma_spec (in the of_dma_route_allocate callback)
which can be used to 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.
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 | 86
+++
include/linux/dmaengine.h | 17 ++
include/linux/of_dma.h| 21 +++
5 files changed, 159 insertions(+)
Can that be moved to a header / C file of its own?
There's a lot of various code already in dmaengine.h and dmaengine.c,
it would be really great to avoid adding more random stuff in there.
diff --git a/Documentation/devicetree/bindings/dma/dma.txt
b/Documentation/devicetree/bindings/dma/dma.txt
index 82104271e754..6312fb00ce8d 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-masters: phandle of the DMA controller or list of
phandles for
+ the DMA controllers the router can direct the signal to.
+- #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.
+- In the node pointed by the dma-masters:
+ - 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-masters = sdma;
+ };
* DMA client
diff --git a/drivers/dma/dmaengine.c b/drivers/dma/dmaengine.c
index 24967c89f5d4..c7aa232b4a59 100644
--- a/drivers/dma/dmaengine.c
+++ b/drivers/dma/dmaengine.c
@@ -267,6 +267,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 cbd4a8aff120..98b3b61624f0 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -45,6 +45,47 @@ 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 of_phandle_args dma_spec_target;
+ void*route_data;
+
+ /* translate the request for the real DMA controller */
+ memcpy(dma_spec_target, dma_spec, sizeof(dma_spec_target));
+ route_data =
Re: ARM errata 430973 on multi platform kernels
* Russell King - ARM Linux li...@arm.linux.org.uk [150408 16:09]: On Tue, Apr 07, 2015 at 08:44:05AM -0700, Tony Lindgren wrote: And then on top of that patch, we can fix the sefaulting issues with the following, what do you guys think? Has this change been tested on OMAP secure parts? Boots just fine for me on n900, but let's wait for comments from Sebastian. Regards, Tony 8 From: Tony Lindgren t...@atomide.com Date: Tue, 7 Apr 2015 07:52:39 -0700 Subject: [PATCH] ARM: mm: Fix Cortex-A8 erratum 430973 segfaults for bootloaders and multiarch Looks like apps can be made to segfault easily on armhf distros just by running cpuburn-a8 in the background, then starting apt get update unless erratum 430973 workaround is enabled. This happens on r3p2 also, which has 430973 fixed in hardware. Turns out the reason for this is some bootloaders incorrectly setting the auxilary register IBE bit, which probably causes us to hit erratum 687067 on Cortex-A8 later than r1p2. Now that Cortex-A8 has it's own cpu_ca8_switch_mm, we can fix these issues: 1. If the bootloader incorrectly sets the IBE bit in the auxilary control register for Cortex-A8 revisions with 430973 fixed in hardware, we need to call flush BTAC/BTB to avoid segfaults probably caused by erratum 687067. So let's flush BTAC/BTB unconditionally for Cortex-A8. It won't do anything unless the IBE bit is set. 2. We can and should now keep 430973 enabled for multiarch builds as it no longer causes issues with Cortex-A9 as we have a separate cpu_ca8_switch_mm. Note that SoCs probably should also add checks and print warnings for the misconfigured IBE bit depending on the Cortex-A8 revision so the bootloaders can be fixed Cortex-A8 revisions later than r1p2 to not set the IBE bit. Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/mm/proc-v7-2level.S +++ b/arch/arm/mm/proc-v7-2level.S @@ -36,14 +36,16 @@ * * It is assumed that: * - we are not using split page tables + * + * Note that we always need to flush BTAC/BTB if IBE is set + * even on Cortex-A8 revisions not affected by 430973. + * If IBE is not set, the flush BTAC/BTB won't do anything. */ ENTRY(cpu_ca8_switch_mm) #ifdef CONFIG_MMU mov r2, #0 -#ifdef CONFIG_ARM_ERRATA_430973 mcr p15, 0, r2, c7, c5, 6 @ flush BTAC/BTB #endif -#endif ENTRY(cpu_v7_switch_mm) #ifdef CONFIG_MMU mmidr1, r1 @ get mm-context.id --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -352,7 +352,7 @@ __v7_setup: ldr r10, =0x0c08@ Cortex-A8 primary part number teq r0, r10 bne 2f -#if defined(CONFIG_ARM_ERRATA_430973) !defined(CONFIG_ARCH_MULTIPLATFORM) +#if defined(CONFIG_ARM_ERRATA_430973) teq r5, #0x0010 @ only present in r1p* mrceq p15, 0, r10, c1, c0, 1 @ read aux control register -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 -- 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] (gpio-fan): Move the thermal registration after registration is complete
On 04/08/2015 04:23 PM, Nishanth Menon wrote: Thermal framework may already be ready and cooling policies might already be functional when we are attempting to register gpio fan as a cooling device. This can be reproduced by changing probe order in which registration of various modules are done in a system. In such a case, kernel generates an oops since the data structures are not completely populated with the wrong assumption that thermal framework is not yet ready. Fix this by reordering the thermal framework registration to occur after hwmon registration of the fan is complete. Example kernel oops: [ 149.005828] Unable to handle kernel NULL pointer dereference at virtual address 008c [ 149.014369] pgd = ecf48000 [ 149.017204] [008c] *pgd=ac065831, *pte=, *ppte= [ 149.023820] Internal error: Oops: 17 [#1] SMP ARM [ 149.028745] Modules linked in: gpio_fan(+) cpufreq_dt ipv6 evdev leds_gpio led_class omap_wdt phy_omap_usb2 rtc_palmas palmas_pwrbutton tmp102 ti_soc_thermal dwc3_omap thermal_sys extcon rtc_omap rtc_ds1307 hwmon [ 149.048629] CPU: 1 PID: 1183 Comm: modprobe Not tainted 4.0.0-rc7-next-20150407-2-g7a82da074c99 #3 [ 149.058383] Hardware name: Generic DRA74X (Flattened Device Tree) [ 149.064763] task: edec1240 ti: ec0e task.ti: ec0e [ 149.070421] PC is at dev_driver_string+0x0/0x38 [ 149.075165] LR is at __dev_printk+0x24/0x70 [ 149.079540] pc : [c03d6cd0]lr : [c03d72c4]psr: 2013 [ 149.079540] sp : ec0e1c28 ip : edec1240 fp : [ 149.091568] r10: edf3eee0 r9 : r8 : [ 149.097040] r7 : edf3eea0 r6 : 0034 r5 : 0010 r4 : ec0e1c44 [ 149.103871] r3 : ec0e1c4c r2 : ec0e1c44 r1 : c079d800 r0 : 0010 [ 149.110709] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 149.118182] Control: 10c5387d Table: acf4806a DAC: 0015 [ 149.124198] Process modprobe (pid: 1183, stack limit = 0xec0e0218) [ 149.130673] Stack: (0xec0e1c28 to 0xec0e2000) [ 149.135235] 1c20: 6013 c05e2ae0 edf3ec00 ec934a10 c03d73d4 ... [ 149.392230] 1fe0: befe1888 befe1878 00019418 b6ea08f0 8010 0003 [ 149.400798] [c03d6cd0] (dev_driver_string) from [c03d72c4] (__dev_printk+0x24/0x70) [ 149.409193] [c03d72c4] (__dev_printk) from [c03d73d4] (dev_warn+0x34/0x48) [ 149.416767] [c03d73d4] (dev_warn) from [bf0f54fc] (get_fan_speed_index+0x94/0xa4 [gpio_fan]) [ 149.425980] [bf0f54fc] (get_fan_speed_index [gpio_fan]) from [bf0f5524] (gpio_fan_get_cur_state+0x18/0x30 [gpio_fan]) [ 149.437476] [bf0f5524] (gpio_fan_get_cur_state [gpio_fan]) from [bf02767c] (thermal_zone_trip_update+0xe8/0x2a4 [thermal_sys]) [ 149.449794] [bf02767c] (thermal_zone_trip_update [thermal_sys]) from [bf027844] (step_wise_throttle+0xc/0x74 [thermal_sys]) [ 149.461832] [bf027844] (step_wise_throttle [thermal_sys]) from [bf024ff4] (handle_thermal_trip+0x5c/0x188 [thermal_sys]) [ 149.473603] [bf024ff4] (handle_thermal_trip [thermal_sys]) from [bf0256c4] (thermal_zone_device_update+0x94/0x108 [thermal_sys]) [ 149.486104] [bf0256c4] (thermal_zone_device_update [thermal_sys]) from [bf026470] (__thermal_cooling_device_register+0x2e8/0x374 [thermal_sys]) [ 149.499956] [bf026470] (__thermal_cooling_device_register [thermal_sys]) from [bf0f58e4] (gpio_fan_probe+0x350/0x4d0 [gpio_fan]) [ 149.512438] [bf0f58e4] (gpio_fan_probe [gpio_fan]) from [c03db8a0] (platform_drv_probe+0x48/0x98) [ 149.522109] [c03db8a0] (platform_drv_probe) from [c03da30c] (driver_probe_device+0x1b0/0x26c) [ 149.531399] [c03da30c] (driver_probe_device) from [c03da45c] (__driver_attach+0x94/0x98) [ 149.540238] [c03da45c] (__driver_attach) from [c03d8bb0] (bus_for_each_dev+0x54/0x88) [ 149.548814] [c03d8bb0] (bus_for_each_dev) from [c03d9a34] (bus_add_driver+0xdc/0x1d4) [ 149.557381] [c03d9a34] (bus_add_driver) from [c03dac30] (driver_register+0x78/0xf4) [ 149.565765] [c03dac30] (driver_register) from [c0009784] (do_one_initcall+0x80/0x1d8) [ 149.574340] [c0009784] (do_one_initcall) from [c00c2278] (do_init_module+0x5c/0x1b8) [ 149.582833] [c00c2278] (do_init_module) from [c00c3bbc] (load_module+0x1720/0x1dcc) [ 149.591212] [c00c3bbc] (load_module) from [c00c43d0] (SyS_finit_module+0x68/0x6c) [ 149.599418] [c00c43d0] (SyS_finit_module) from [c000f3c0] (ret_fast_syscall+0x0/0x4c) [ 149.607994] Code: 1583 e1a6 e28dd008 e8bd8070 (e590307c) Cc: Eduardo Valentin edubez...@gmail.com Fixes: b5cf88e46bad ((gpio-fan): Add thermal control hooks) Signed-off-by: Nishanth Menon n...@ti.com --- Applied to -next. Thanks, Guenter -- 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 1/2] ARM: dts: am57xx-beagle-x15: Fix IRQ type for mcp7941x
From: Grygorii Strashko grygorii.stras...@linaro.org
The interrupt polarity provided in devicetree is used to configure
the interrupt controller(ARM GIC), however, it seems that we have an
inverter at the GIC boundary inside AM57xx which inverts the signal
input from sys_irq external interrupt source.
Further, as per GIC distributor TRM,
http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438d/BGBHIACJ.html#BABJFCFB
ARM GIC distributor does not support IRQ trigger type
IRQ_TYPE_LEVEL_LOW, and only rising or level high signals.
However, for some reason, the current configuration(which gets ignored
by GIC driver) functions on some platforms, however, on few platforms
results in infinite interrupts hogging the system down.
Switch over to rising edge for GIC configuration which is also aligned
with trigger point from the RTC chip and the internal inversion.
Fixes: 5a0f93c6576a (ARM: dts: Add am57xx-beagle-x15)
Signed-off-by: Grygorii Strashko grygorii.stras...@linaro.org
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/am57xx-beagle-x15.dts |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index fe141c47d647..57279e3b439b 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -455,7 +455,7 @@
mcp_rtc: rtc@6f {
compatible = microchip,mcp7941x;
reg = 0x6f;
- interrupts = GIC_SPI 2 IRQ_TYPE_LEVEL_LOW; /* IRQ_SYS_1N */
+ interrupts = GIC_SPI 2 IRQ_TYPE_EDGE_RISING; /* IRQ_SYS_1N */
pinctrl-names = default;
pinctrl-0 = mcp79410_pins_default;
--
1.7.9.5
--
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: LDP: next-20150402: twl4030 regression?
Hi Felipe, On Wed, 8 Apr 2015 11:35:59 -0500 Felipe Balbi ba...@ti.com wrote: On Mon, Apr 06, 2015 at 01:45:22PM -0500, Nishanth Menon wrote: On 04/06/2015 10:27 AM, Felipe Balbi wrote: Hi, On Mon, Apr 06, 2015 at 10:17:37AM -0500, Nishanth Menon wrote: On 04/06/2015 10:01 AM, Mark Brown wrote: On Mon, Apr 06, 2015 at 02:58:29PM +0100, Russell King - ARM Linux wrote: On Mon, Apr 06, 2015 at 08:53:36AM -0500, Nishanth Menon wrote: at least a description of the problem you're seeing and some attempt at Test was a simple boot test. There seems to be a lockdep reported at the very least in the log provided (see https://github.com/nmenon/kernel-test-logs/blob/next-20150402/omap2plus_defconfig/ldp.txt#L488 ). I think what Mark is trying to say is to include a fuller description of the problem, and don't expect people to fire up their web browser to get a basic overview of what the problem is. Yes, indeed. I hadn't actually opened the links, I might've got round to it later on. My guess is that the problem _appears_ to be that someone's added a call to debug_check_no_locks_held() into schedule_hrtimeout_range_clock() without considering what this means. What it means is that you can't now use usleep_range() from within any driver probe function - which is absolutely absurd. I can't think of any regulator side changes which might be relevant in that period. It's possible that there might be something in the MFD I guess. Ran a few tests since my original email.. 6261b06de565baafa590e58a531a1a5522cea0b6 (regulator: Defer lookup of supply to regulator_get) was the only patch that was introduced in the interval. there seems nothing in mfd either. I still have the following in my log.. trying to further down. I noticed a similar warning with AM437x SK posting intermediate debug results: I did a bisect on the merge commits to identify which tree the regression got introduced, looks like it is the merge from akpm tree - I have not yet looked deeper. b58a6c0b0808 Merge branch 'akpm-current/current' --- FAIL http://paste.ubuntu.org.cn/2540641 ef31288bdf44 Merge remote-tracking branch 'livepatching/for-next' -- OK - http://paste.ubuntu.org.cn/2540778 yeah, this works on my SK too. I bisected it further down to one commit. commit 6dfc11e36ee0 is the first bad commit, but looks like that's not in linux-next anymore. Please give at least the summary line as well when you refer to commits. They get rebase and rewritten which means that their commit SHA1 changes ... That commit is kernel/time/hrtimer.c: restart_syscall: use freezable blocking call and, indeed, it was removed from linux-next and Andrew's tree. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpIg8zTIDw_X.pgp Description: OpenPGP digital signature
[PATCH] (gpio-fan): Move the thermal registration after registration is complete
Thermal framework may already be ready and cooling policies might already be functional when we are attempting to register gpio fan as a cooling device. This can be reproduced by changing probe order in which registration of various modules are done in a system. In such a case, kernel generates an oops since the data structures are not completely populated with the wrong assumption that thermal framework is not yet ready. Fix this by reordering the thermal framework registration to occur after hwmon registration of the fan is complete. Example kernel oops: [ 149.005828] Unable to handle kernel NULL pointer dereference at virtual address 008c [ 149.014369] pgd = ecf48000 [ 149.017204] [008c] *pgd=ac065831, *pte=, *ppte= [ 149.023820] Internal error: Oops: 17 [#1] SMP ARM [ 149.028745] Modules linked in: gpio_fan(+) cpufreq_dt ipv6 evdev leds_gpio led_class omap_wdt phy_omap_usb2 rtc_palmas palmas_pwrbutton tmp102 ti_soc_thermal dwc3_omap thermal_sys extcon rtc_omap rtc_ds1307 hwmon [ 149.048629] CPU: 1 PID: 1183 Comm: modprobe Not tainted 4.0.0-rc7-next-20150407-2-g7a82da074c99 #3 [ 149.058383] Hardware name: Generic DRA74X (Flattened Device Tree) [ 149.064763] task: edec1240 ti: ec0e task.ti: ec0e [ 149.070421] PC is at dev_driver_string+0x0/0x38 [ 149.075165] LR is at __dev_printk+0x24/0x70 [ 149.079540] pc : [c03d6cd0]lr : [c03d72c4]psr: 2013 [ 149.079540] sp : ec0e1c28 ip : edec1240 fp : [ 149.091568] r10: edf3eee0 r9 : r8 : [ 149.097040] r7 : edf3eea0 r6 : 0034 r5 : 0010 r4 : ec0e1c44 [ 149.103871] r3 : ec0e1c4c r2 : ec0e1c44 r1 : c079d800 r0 : 0010 [ 149.110709] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 149.118182] Control: 10c5387d Table: acf4806a DAC: 0015 [ 149.124198] Process modprobe (pid: 1183, stack limit = 0xec0e0218) [ 149.130673] Stack: (0xec0e1c28 to 0xec0e2000) [ 149.135235] 1c20: 6013 c05e2ae0 edf3ec00 ec934a10 c03d73d4 ... [ 149.392230] 1fe0: befe1888 befe1878 00019418 b6ea08f0 8010 0003 [ 149.400798] [c03d6cd0] (dev_driver_string) from [c03d72c4] (__dev_printk+0x24/0x70) [ 149.409193] [c03d72c4] (__dev_printk) from [c03d73d4] (dev_warn+0x34/0x48) [ 149.416767] [c03d73d4] (dev_warn) from [bf0f54fc] (get_fan_speed_index+0x94/0xa4 [gpio_fan]) [ 149.425980] [bf0f54fc] (get_fan_speed_index [gpio_fan]) from [bf0f5524] (gpio_fan_get_cur_state+0x18/0x30 [gpio_fan]) [ 149.437476] [bf0f5524] (gpio_fan_get_cur_state [gpio_fan]) from [bf02767c] (thermal_zone_trip_update+0xe8/0x2a4 [thermal_sys]) [ 149.449794] [bf02767c] (thermal_zone_trip_update [thermal_sys]) from [bf027844] (step_wise_throttle+0xc/0x74 [thermal_sys]) [ 149.461832] [bf027844] (step_wise_throttle [thermal_sys]) from [bf024ff4] (handle_thermal_trip+0x5c/0x188 [thermal_sys]) [ 149.473603] [bf024ff4] (handle_thermal_trip [thermal_sys]) from [bf0256c4] (thermal_zone_device_update+0x94/0x108 [thermal_sys]) [ 149.486104] [bf0256c4] (thermal_zone_device_update [thermal_sys]) from [bf026470] (__thermal_cooling_device_register+0x2e8/0x374 [thermal_sys]) [ 149.499956] [bf026470] (__thermal_cooling_device_register [thermal_sys]) from [bf0f58e4] (gpio_fan_probe+0x350/0x4d0 [gpio_fan]) [ 149.512438] [bf0f58e4] (gpio_fan_probe [gpio_fan]) from [c03db8a0] (platform_drv_probe+0x48/0x98) [ 149.522109] [c03db8a0] (platform_drv_probe) from [c03da30c] (driver_probe_device+0x1b0/0x26c) [ 149.531399] [c03da30c] (driver_probe_device) from [c03da45c] (__driver_attach+0x94/0x98) [ 149.540238] [c03da45c] (__driver_attach) from [c03d8bb0] (bus_for_each_dev+0x54/0x88) [ 149.548814] [c03d8bb0] (bus_for_each_dev) from [c03d9a34] (bus_add_driver+0xdc/0x1d4) [ 149.557381] [c03d9a34] (bus_add_driver) from [c03dac30] (driver_register+0x78/0xf4) [ 149.565765] [c03dac30] (driver_register) from [c0009784] (do_one_initcall+0x80/0x1d8) [ 149.574340] [c0009784] (do_one_initcall) from [c00c2278] (do_init_module+0x5c/0x1b8) [ 149.582833] [c00c2278] (do_init_module) from [c00c3bbc] (load_module+0x1720/0x1dcc) [ 149.591212] [c00c3bbc] (load_module) from [c00c43d0] (SyS_finit_module+0x68/0x6c) [ 149.599418] [c00c43d0] (SyS_finit_module) from [c000f3c0] (ret_fast_syscall+0x0/0x4c) [ 149.607994] Code: 1583 e1a6 e28dd008 e8bd8070 (e590307c) Cc: Eduardo Valentin edubez...@gmail.com Fixes: b5cf88e46bad ((gpio-fan): Add thermal control hooks) Signed-off-by: Nishanth Menon n...@ti.com --- Reproduced on next-20150407 tag. drivers/hwmon/gpio-fan.c | 19 +++ 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/drivers/hwmon/gpio-fan.c b/drivers/hwmon/gpio-fan.c index 632b8e3ff5bf..a3dae6d0082a 100644 --- a/drivers/hwmon/gpio-fan.c +++ b/drivers/hwmon/gpio-fan.c @@ -563,18 +563,10 @@ static int gpio_fan_probe(struct platform_device *pdev) err = gpio_fan_get_of_pdata(pdev-dev,
Re: ARM errata 430973 on multi platform kernels
On Tue, Apr 07, 2015 at 08:22:08AM -0700, Tony Lindgren wrote: Works for me. The above needs the following fix folded in to build: --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -532,7 +532,7 @@ __v7_ca9mp_proc_info: __v7_ca8_proc_info: .long 0x410fc080 .long 0xff00 - __v7_proc __v7_ca8mp_proc_info, proc_fns = ca8_processor_functions + __v7_proc __v7_ca8_proc_info, __v7_setup, proc_fns = ca8_processor_functions .size __v7_ca8_proc_info, . - __v7_ca8_proc_info #endif /* CONFIG_ARM_LPAE */ Thanks, merged into the original patch. -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 2/2] ARM: dts: am57xx-beagle-x15: Fix RTC aliases
With commit bc078316d86c (ARM: dts: DRA7: Add node for RTC), we now
have AM57xx RTC register itself as alias 0 even before DS1307 or TPS
rtc drivers are loaded up. However, since neither TPS, nor AM57xx RTC
are capable of being backedup by battery, we would like to maintain
the primary rtc as mcp79410 rtc device.
This also generates the following warnings in the bootlog highlighting
the issue:
[5.895445] rtc-ds1307 2-006f: /aliases ID 0 not available
...
[6.476285] palmas-rtc 4807.i2c:tps659038@58:tps659038_rtc: /aliases ID
1 not available
So, add proper aliases to ensure that RTC order is always consistent
to userspace immaterial of probe order.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/boot/dts/am57xx-beagle-x15.dts |1 +
arch/arm/boot/dts/dra7.dtsi |2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index 57279e3b439b..6837f44db534 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -18,6 +18,7 @@
aliases {
rtc0 = mcp_rtc;
rtc1 = tps659038_rtc;
+ rtc2 = rtc;
};
memory {
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index 5332b57b4950..0f73fea9f5c3 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1203,7 +1203,7 @@
status = disabled;
};
- rtc@48838000 {
+ rtc: rtc@48838000 {
compatible = ti,am3352-rtc;
reg = 0x48838000 0x100;
interrupts = GIC_SPI 217 IRQ_TYPE_LEVEL_HIGH,
--
1.7.9.5
--
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: ARM errata 430973 on multi platform kernels
On Tue, Apr 07, 2015 at 08:44:05AM -0700, Tony Lindgren wrote: And then on top of that patch, we can fix the sefaulting issues with the following, what do you guys think? Has this change been tested on OMAP secure parts? 8 From: Tony Lindgren t...@atomide.com Date: Tue, 7 Apr 2015 07:52:39 -0700 Subject: [PATCH] ARM: mm: Fix Cortex-A8 erratum 430973 segfaults for bootloaders and multiarch Looks like apps can be made to segfault easily on armhf distros just by running cpuburn-a8 in the background, then starting apt get update unless erratum 430973 workaround is enabled. This happens on r3p2 also, which has 430973 fixed in hardware. Turns out the reason for this is some bootloaders incorrectly setting the auxilary register IBE bit, which probably causes us to hit erratum 687067 on Cortex-A8 later than r1p2. Now that Cortex-A8 has it's own cpu_ca8_switch_mm, we can fix these issues: 1. If the bootloader incorrectly sets the IBE bit in the auxilary control register for Cortex-A8 revisions with 430973 fixed in hardware, we need to call flush BTAC/BTB to avoid segfaults probably caused by erratum 687067. So let's flush BTAC/BTB unconditionally for Cortex-A8. It won't do anything unless the IBE bit is set. 2. We can and should now keep 430973 enabled for multiarch builds as it no longer causes issues with Cortex-A9 as we have a separate cpu_ca8_switch_mm. Note that SoCs probably should also add checks and print warnings for the misconfigured IBE bit depending on the Cortex-A8 revision so the bootloaders can be fixed Cortex-A8 revisions later than r1p2 to not set the IBE bit. Signed-off-by: Tony Lindgren t...@atomide.com --- a/arch/arm/mm/proc-v7-2level.S +++ b/arch/arm/mm/proc-v7-2level.S @@ -36,14 +36,16 @@ * * It is assumed that: * - we are not using split page tables + * + * Note that we always need to flush BTAC/BTB if IBE is set + * even on Cortex-A8 revisions not affected by 430973. + * If IBE is not set, the flush BTAC/BTB won't do anything. */ ENTRY(cpu_ca8_switch_mm) #ifdef CONFIG_MMU mov r2, #0 -#ifdef CONFIG_ARM_ERRATA_430973 mcr p15, 0, r2, c7, c5, 6 @ flush BTAC/BTB #endif -#endif ENTRY(cpu_v7_switch_mm) #ifdef CONFIG_MMU mmidr1, r1 @ get mm-context.id --- a/arch/arm/mm/proc-v7.S +++ b/arch/arm/mm/proc-v7.S @@ -352,7 +352,7 @@ __v7_setup: ldr r10, =0x0c08@ Cortex-A8 primary part number teq r0, r10 bne 2f -#if defined(CONFIG_ARM_ERRATA_430973) !defined(CONFIG_ARCH_MULTIPLATFORM) +#if defined(CONFIG_ARM_ERRATA_430973) teq r5, #0x0010 @ only present in r1p* mrceq p15, 0, r10, c1, c0, 1 @ read aux control register -- FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up according to speedtest.net. -- 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 0/2] ARM: dts: am57xx-beagle-x15: Fixes for RTC
Couple of fixes for MCP79410 RTC on BeagleBoard-X15 platform. This is not urgent enough for 4.0 material, but will be good to have it on one of 4.1 rcs. tested on next-20150407: http://pastebin.ubuntu.com/1033/ (NOTE: I believe DRA7 rtc still needs reset driver to be done before it can be fully functional). Grygorii Strashko (1): ARM: dts: am57xx-beagle-x15: Fix IRQ type for mcp7941x Nishanth Menon (1): ARM: dts: am57xx-beagle-x15: Fix RTC aliases arch/arm/boot/dts/am57xx-beagle-x15.dts |3 ++- arch/arm/boot/dts/dra7.dtsi |2 +- 2 files changed, 3 insertions(+), 2 deletions(-) Regards, Nishanth Menon -- 1.7.9.5 -- 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
