Re: [PATCH 00/55]: ARM: OMAP2+: PRCM move to drivers
On 04/01/2014 01:09 AM, Tony Lindgren wrote: * Tero Kristo t-kri...@ti.com [140331 08:20]: Hi, This set is continuation for the work started earlier to cleanup the CM/PRM and attempt to make it a separate driver. This set depends on these two sets: CM/PRM cleanup set: http://marc.info/?l=linux-omapm=139395000918201w=2 OMAP2 clock DT set: http://comments.gmane.org/gmane.linux.ports.arm.omap/111257 This set is pretty huge but the patches can be applied in stages if need be. Anyway, it would be good to get some feedback whether the driver folder locations etc. are good, and whether the effort taken here will be enough to actually move the driver. Clockdomain / powerdomain code can also be moved easily under the drivers/power/omap folder (or someplace else if requested) once this set is in. Also, clockdomain / powerdomain data should be possible to convert to DT format or some sort of firmware blob once this is done. Good to see this happening :) Patch #55 in this set is pretty massive as it moves all the C files at the same time, this should probably be split up as multiple patches. Maybe try to break this series into few smaller sets of patches? Yes, this was the idea once getting the initial feedback for the approach itself. I will post smaller sets (split from this one) once the CM/PRM cleanup set referenced above gets in. Then a diffstat with these kind of large patch sets would be nice in the cover letter to get some kind of idea what's going on :) Browsing through the set it seems that all the patches in this series moving register defines to a public location are bad news. We don't want to make access to these registers available without proper frameworks as that will lead into misuse by various drivers. And cleaning up that mess later in is a huge pain. Currently, only thing that requires access to the register offsets is basically all the legacy clock data still in the kernel (when can we get rid of this, I have posted patches for it already?) and also the clockdomain / powerdomain data. I can work on getting clockdomain + powerdomain data to DT format if this would be preferred, then we can remove these data files also. Alternatively I can just move all these defines to the C files which actually use them. To avoid that, you can probably do something like this: 1. Set up the PRCM registers as multiple regmap areas See for example these commits in linux next how one of the SCM misc register areas is now available for drivers as tisyscon defined in the .dts files: 11469e0bb1c5 regulator: add pbias regulator support cd042fe5c1f6 ARM: dts: add pbias dt node So basically we now have drivers/regulators/pbias-regulator.c that claims some of the tisyscon registers and implements a regulator. Then the MMC driver can just use the standard regulator related functions. It seems that you can set up multiple PRCM register ranges in a similar way as regmap ranges and that way partition the PRCM register areas to something that's private to individual drivers. So, basically you are proposing to add a regmap or regmap like API for the PRCM, which would provide access to a subset of registers only outside the PRCM driver? Some functions provided by PRCM spawn to multiple registers (like clocks), and the ranges have holes, and would require finetuning a register / bit level access map (some registers may contain functions for several drivers.) 2. Have the core PRCM driver(s) claim some of the regmap ranges Some PRCM features can potentially be implemented using existing Linux generic frameworks where possible for clocks, regulators, reset drivers etc. That way you can keep the register defines for these ranges private to the core PRCM driver(s). Ideally with no need to add _any_ custom exported functions here. There is separate work ongoing for reset driver, and for VC/VP, there has been some regulator related work. But yes, mostly this approach should be fine. 3. Have the other drivers claim some regmap ranges The register ranges that are clearly owned by some driver should be claimed by those drivers. Then the defines for those registers can stay private to that driver. Some drivers that can probably own some PRCM ranges are clock drivers and voltage related drivers. Yeah, this sounds reasonable. -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
[PATCH 1/1] ARM: dts: omap5: Add clocks to USB3 PHY node
The USB3 PHY driver (ti-pipe3) was updated so that the relevant clock phandles are expected in the DT node. Provide the necessary clocks. Reported-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Roger Quadros rog...@ti.com --- arch/arm/boot/dts/omap5.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 757f0b9..4df1e7a 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -794,6 +794,12 @@ 0x4a084c00 0x40; reg-names = phy_rx, phy_tx, pll_ctrl; ctrl-module = omap_control_usb3phy; + clocks = usb_phy_cm_clk32k, +sys_clkin, +usb_otg_ss_refclk960m; + clock-names = wkupclk, + sysclk, + refclk; #phy-cells = 0; }; }; -- 1.8.3.2 -- 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/1] OMAP5: USB3 fix for 3.15
Hi Tony, The following patch fixes USB3 on OMAP5 on linux-next. There was a patch [1] that added named clocks to the USB3 phy driver but somehow the dts part got missed out. Due to that USB3 on OMAP5 is currently broken on linux-next and this patch should fix it. cheers, -roger [1] - http://patchwork.ozlabs.org/patch/327481/ Roger Quadros (1): ARM: dts: omap5: Add clocks to USB3 PHY node arch/arm/boot/dts/omap5.dtsi | 6 ++ 1 file changed, 6 insertions(+) -- 1.8.3.2 -- 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 v2 12/14] dma: edma: Prefix debug prints where the text were identical in prep callbacks
prep_slave_sg and prep_dma_cyclic callbacks have mostly same failure cases
with the same texts printed in case we hit them. It helps when debugging if
we know exactly which callback generated the errors.
At the same time change the debug level for descriptor allocation failure
from dbg to err since all other error cases are dev_err and this failure is
similarly fatal as the other ones.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index e8de2e84a60a..7feb6231276e 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -434,14 +434,14 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
}
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
- dev_err(dev, Undefined slave buswidth\n);
+ dev_err(dev, %s: Undefined slave buswidth\n, __func__);
return NULL;
}
edesc = kzalloc(sizeof(*edesc) + sg_len *
sizeof(edesc-pset[0]), GFP_ATOMIC);
if (!edesc) {
- dev_dbg(dev, Failed to allocate a descriptor\n);
+ dev_err(dev, %s: Failed to allocate a descriptor\n, __func__);
return NULL;
}
@@ -457,7 +457,8 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
EDMA_SLOT_ANY);
if (echan-slot[i] 0) {
kfree(edesc);
- dev_err(dev, Failed to allocate slot\n);
+ dev_err(dev, %s: Failed to allocate slot\n,
+ __func__);
return NULL;
}
}
@@ -526,7 +527,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
}
if (dev_width == DMA_SLAVE_BUSWIDTH_UNDEFINED) {
- dev_err(dev, Undefined slave buswidth\n);
+ dev_err(dev, %s: Undefined slave buswidth\n, __func__);
return NULL;
}
@@ -551,7 +552,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc = kzalloc(sizeof(*edesc) + nslots *
sizeof(edesc-pset[0]), GFP_ATOMIC);
if (!edesc) {
- dev_dbg(dev, Failed to allocate a descriptor\n);
+ dev_err(dev, %s: Failed to allocate a descriptor\n, __func__);
return NULL;
}
@@ -569,7 +570,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
EDMA_SLOT_ANY);
if (echan-slot[i] 0) {
kfree(edesc);
- dev_err(dev, Failed to allocate slot\n);
+ dev_err(dev, %s: Failed to allocate slot\n,
+ __func__);
return NULL;
}
}
--
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
[PATCH v2 13/14] dma: edma: Add channel number to debug prints
It helps to identify issues if we have some information regarding to the
channel which the event is associated.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 7feb6231276e..2413237840f8 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -185,7 +185,8 @@ static void edma_execute(struct edma_chan *echan)
edma_resume(echan-ch_num);
if (edesc-processed = MAX_NR_SG) {
- dev_dbg(dev, first transfer starting %d\n, echan-ch_num);
+ dev_dbg(dev, first transfer starting on channel %d\n,
+ echan-ch_num);
edma_start(echan-ch_num);
}
@@ -195,7 +196,7 @@ static void edma_execute(struct edma_chan *echan)
* MAX_NR_SG
*/
if (echan-missed) {
- dev_dbg(dev, missed event in execute detected\n);
+ dev_dbg(dev, missed event on channel %d\n, echan-ch_num);
edma_clean_channel(echan-ch_num);
edma_stop(echan-ch_num);
edma_start(echan-ch_num);
@@ -736,7 +737,7 @@ static int edma_alloc_chan_resources(struct dma_chan *chan)
echan-alloced = true;
echan-slot[0] = echan-ch_num;
- dev_dbg(dev, allocated channel for %u:%u\n,
+ dev_dbg(dev, allocated channel %d for %u:%u\n, echan-ch_num,
EDMA_CTLR(echan-ch_num), EDMA_CHAN_SLOT(echan-ch_num));
return 0;
--
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
[PATCH v2 14/14] dma: edma: Print the direction value as well when it is not supported
In case of not supported direction it is better to print the direction also.
It is unlikely, but in such an event it helps with the debugging.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2413237840f8..912bf0190f45 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -430,7 +430,7 @@ static struct dma_async_tx_descriptor *edma_prep_slave_sg(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
- dev_err(dev, %s: bad direction?\n, __func__);
+ dev_err(dev, %s: bad direction: %d\n, __func__, direction);
return NULL;
}
@@ -523,7 +523,7 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
dev_width = echan-cfg.dst_addr_width;
burst = echan-cfg.dst_maxburst;
} else {
- dev_err(dev, %s: bad direction?\n, __func__);
+ dev_err(dev, %s: bad direction: %d\n, __func__, direction);
return NULL;
}
--
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
[PATCH v2 11/14] dma: edma: Reduce debug print verbosity for non verbose debugging
Do not print the paRAM information when verbose debugging is not asked and
also reduce the number of lines printed in edma_prep_dma_cyclic()
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index d954099650ae..e8de2e84a60a 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -141,7 +141,7 @@ static void edma_execute(struct edma_chan *echan)
for (i = 0; i nslots; i++) {
j = i + edesc-processed;
edma_write_slot(echan-slot[i], edesc-pset[j]);
- dev_dbg(echan-vchan.chan.device-dev,
+ dev_vdbg(echan-vchan.chan.device-dev,
\n pset[%d]:\n
chnum\t%d\n
slot\t%d\n
@@ -558,9 +558,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
edesc-cyclic = 1;
edesc-pset_nr = nslots;
- dev_dbg(dev, %s: nslots=%d\n, __func__, nslots);
- dev_dbg(dev, %s: period_len=%d\n, __func__, period_len);
- dev_dbg(dev, %s: buf_len=%d\n, __func__, buf_len);
+ dev_dbg(dev, %s: channel=%d nslots=%d period_len=%zu buf_len=%zu\n,
+ __func__, echan-ch_num, nslots, period_len, buf_len);
for (i = 0; i nslots; i++) {
/* Allocate a PaRAM slot, if needed */
@@ -594,8 +593,8 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic(
else
src_addr += period_len;
- dev_dbg(dev, %s: Configure period %d of buf:\n, __func__, i);
- dev_dbg(dev,
+ dev_vdbg(dev, %s: Configure period %d of buf:\n, __func__, i);
+ dev_vdbg(dev,
\n pset[%d]:\n
chnum\t%d\n
slot\t%d\n
--
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
[PATCH v2 09/14] dma: edma: Implement device_slave_caps callback
With the callback implemented omap-dma can provide information to client
drivers regarding to supported address widths, directions, residue
granularity, etc.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 10048b40fac8..855766672aa9 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -855,6 +855,23 @@ static void __init edma_chan_init(struct edma_cc *ecc,
}
}
+#define EDMA_DMA_BUSWIDTHS (BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) | \
+BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) | \
+BIT(DMA_SLAVE_BUSWIDTH_4_BYTES))
+
+static int edma_dma_device_slave_caps(struct dma_chan *dchan,
+ struct dma_slave_caps *caps)
+{
+ caps-src_addr_widths = EDMA_DMA_BUSWIDTHS;
+ caps-dstn_addr_widths = EDMA_DMA_BUSWIDTHS;
+ caps-directions = BIT(DMA_DEV_TO_MEM) | BIT(DMA_MEM_TO_DEV);
+ caps-cmd_pause = true;
+ caps-cmd_terminate = true;
+ caps-residue_granularity = DMA_RESIDUE_GRANULARITY_DESCRIPTOR;
+
+ return 0;
+}
+
static void edma_dma_init(struct edma_cc *ecc, struct dma_device *dma,
struct device *dev)
{
@@ -865,6 +882,7 @@ static void edma_dma_init(struct edma_cc *ecc, struct
dma_device *dma,
dma-device_issue_pending = edma_issue_pending;
dma-device_tx_status = edma_tx_status;
dma-device_control = edma_control;
+ dma-device_slave_caps = edma_dma_device_slave_caps;
dma-dev = dev;
INIT_LIST_HEAD(dma-channels);
--
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
[PATCH v2 05/14] arm: common: edma: Select event queue 1 as default when booted with DT
Use the EVENTQ_1 for default and leave the EVENTQ_0 to be used by high priority channels, like audio. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/common/edma.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 86a8b263278f..19520e2519d9 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1546,7 +1546,8 @@ static int edma_of_parse_dt(struct device *dev, pdata-queue_priority_mapping = queue_priority_map; - pdata-default_queue = 0; + /* select queue 1 as default */ + pdata-default_queue = EVENTQ_1; prop = of_find_property(node, ti,edma-xbar-event-map, sz); if (prop) -- 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
[PATCH v2 06/14] arm: common: edma: Save the number of event queues/TCs
For later use save the number of queues available for the CC. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/common/edma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 19520e2519d9..be267b2080be 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1770,6 +1770,9 @@ static int edma_probe(struct platform_device *pdev) map_queue_tc(j, queue_tc_mapping[i][0], queue_tc_mapping[i][1]); + /* Save the number of TCs */ + edma_cc[j]-num_tc = i; + /* Event queue priority mapping */ for (i = 0; queue_priority_mapping[i][0] != -1; i++) assign_priority_to_queue(j, -- 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
[PATCH v2 10/14] dma: edma: Simplify direction configuration in edma_config_pset()
We only support DEV_TO_MEM or MEM_TO_DEV directions with edma driver and the
check for the direction has been already done in the function calling
edma_config_pset().
The error reporting is redundant and also the else if () can be removed.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 855766672aa9..d954099650ae 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -372,14 +372,12 @@ static int edma_config_pset(struct dma_chan *chan, struct
edmacc_param *pset,
src_cidx = cidx;
dst_bidx = 0;
dst_cidx = 0;
- } else if (direction == DMA_DEV_TO_MEM) {
+ } else {
+ /* DMA_DEV_TO_MEM */
src_bidx = 0;
src_cidx = 0;
dst_bidx = acnt;
dst_cidx = cidx;
- } else {
- dev_err(dev, %s: direction not implemented yet\n, __func__);
- return -EINVAL;
}
pset-opt = EDMA_TCC(EDMA_CHAN_SLOT(echan-ch_num));
--
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
[PATCH v2 07/14] arm: common: edma: API to request non default queue for a channel
When using eDMA3 via dmaengine all dma channels will use the default queue.
Since during request time we do not have means to change this it need to be done
later, before the DMA has been started.
With the added function it is possible to move the channel to a non default
queue if it is possible, otherwise (when only one EQ/TC is available for the CC)
the default queue is going to be used.
For example: For optimal system performance the audio (cyclic) DMA should
be placed to a separate queue which is different than what the rest of the
system is using.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
arch/arm/common/edma.c | 27 +++
include/linux/platform_data/edma.h | 2 ++
2 files changed, 29 insertions(+)
diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
index be267b2080be..eaf6dd19f082 100644
--- a/arch/arm/common/edma.c
+++ b/arch/arm/common/edma.c
@@ -712,6 +712,33 @@ int edma_alloc_channel(int channel,
}
EXPORT_SYMBOL(edma_alloc_channel);
+/**
+ * edma_request_non_default_queue - try to map the channel to non default queue
+ * @channel: dma channel returned from edma_alloc_channel()
+ *
+ * For certain type of applications like audio it is preferred to not use the
+ * default event queue/tc to avoid eDMA caused latency.
+ *
+ * This function will iterate through the event queues available for the CC and
+ * picks the first EQ/TC which is not set as the default for the CC
+ */
+void edma_request_non_default_queue(int channel)
+{
+ unsigned ctlr = EDMA_CTLR(channel);
+ enum dma_event_q eventq_no = EVENTQ_DEFAULT;
+ int i;
+
+ for (i = 0; i edma_cc[ctlr]-num_tc; i++) {
+ if (i != edma_cc[ctlr]-default_queue) {
+ eventq_no = i;
+ break;
+ }
+ }
+
+ channel = EDMA_CHAN_SLOT(channel);
+ map_dmach_queue(ctlr, channel, eventq_no);
+}
+EXPORT_SYMBOL(edma_request_non_default_queue);
/**
* edma_free_channel - deallocate DMA channel
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index 923f8a3e4ce0..5d0a1b98f205 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -117,6 +117,8 @@ int edma_alloc_channel(int channel,
void *data, enum dma_event_q);
void edma_free_channel(unsigned channel);
+void edma_request_non_default_queue(int channel);
+
/* alloc/free parameter RAM slots */
int edma_alloc_slot(unsigned ctlr, int slot);
void edma_free_slot(unsigned slot);
--
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
[PATCH v2 08/14] DMA: edma: Use different eventq for cyclic channels
To improve latency with cyclic DMA operation it is preferred to use different eventq/tc than the default which is used by all other drivers (mmc, spi, i2c, etc). When preparing the cyclic dma ask for non default queue for the channel which is going to be used with cyclic mode. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/dma/edma.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 1dd9e8806975..10048b40fac8 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -628,6 +628,9 @@ static struct dma_async_tx_descriptor *edma_prep_dma_cyclic( edesc-pset[i].opt |= TCINTEN; } + /* Use different eventq/tc for cyclic DMA to reduce latency */ + edma_request_non_default_queue(echan-ch_num); + return vchan_tx_prep(echan-vchan, edesc-vdesc, tx_flags); } -- 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
[PATCH v2 03/14] dma: edma: Add support for DMA_PAUSE/RESUME operation
Pause/Resume can be used by the audio stack when the stream is paused/resumed
The edma platform code has support for this and the legacy audio stack used
this.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2742867fd1e6..7891378a03f0 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -240,6 +240,26 @@ static int edma_slave_config(struct edma_chan *echan,
return 0;
}
+static int edma_dma_pause(struct edma_chan *echan)
+{
+ /* Pause/Resume only allowed with cyclic mode */
+ if (!echan-edesc-cyclic)
+ return -EINVAL;
+
+ edma_pause(echan-ch_num);
+ return 0;
+}
+
+static int edma_dma_resume(struct edma_chan *echan)
+{
+ /* Pause/Resume only allowed with cyclic mode */
+ if (!echan-edesc-cyclic)
+ return -EINVAL;
+
+ edma_resume(echan-ch_num);
+ return 0;
+}
+
static int edma_control(struct dma_chan *chan, enum dma_ctrl_cmd cmd,
unsigned long arg)
{
@@ -255,6 +275,14 @@ static int edma_control(struct dma_chan *chan, enum
dma_ctrl_cmd cmd,
config = (struct dma_slave_config *)arg;
ret = edma_slave_config(echan, config);
break;
+ case DMA_PAUSE:
+ ret = edma_dma_pause(echan);
+ break;
+
+ case DMA_RESUME:
+ ret = edma_dma_resume(echan);
+ break;
+
default:
ret = -ENOSYS;
}
--
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
[PATCH v2 04/14] dma: edma: Set DMA_CYCLIC capability flag
Indicate that the edma dmaengine driver has support for cyclic mode. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- arch/arm/common/edma.c | 1 + drivers/dma/edma.c | 1 + 2 files changed, 2 insertions(+) diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c index 41bca32409fc..86a8b263278f 100644 --- a/arch/arm/common/edma.c +++ b/arch/arm/common/edma.c @@ -1574,6 +1574,7 @@ static struct edma_soc_info *edma_setup_info_from_dt(struct device *dev, return ERR_PTR(ret); dma_cap_set(DMA_SLAVE, edma_filter_info.dma_cap); + dma_cap_set(DMA_CYCLIC, edma_filter_info.dma_cap); of_dma_controller_register(dev-of_node, of_dma_simple_xlate, edma_filter_info); diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index 7891378a03f0..1dd9e8806975 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -891,6 +891,7 @@ static int edma_probe(struct platform_device *pdev) dma_cap_zero(ecc-dma_slave.cap_mask); dma_cap_set(DMA_SLAVE, ecc-dma_slave.cap_mask); + dma_cap_set(DMA_CYCLIC, ecc-dma_slave.cap_mask); edma_dma_init(ecc, ecc-dma_slave, pdev-dev); -- 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
[PATCH v2 00/14] dma: edma: Fixes for cyclic (audio) operation
Hi, This is basically a resend of the previous series: https://lkml.org/lkml/2014/3/13/119 with removed ASoC patches (most of them are applied already). Changes since v1: - ASoC patches removed - Comments from Andriy Shevchenko addressed - patch added to fix cases when src/dst_maxburst is set to 0 Adding support for DMA pause/resume Possibility to select non default event queue/TC for cyclic (audio) dma channels: all devices using the eDMA via dmaengine was assigned to the default EQ/TC (mmc, i2c, spi, etc, and audio). This is not optimal from system performance point of view since sharing the same EQ/TC can cause latency spikes for cyclic channels (long DMA transfers for MMC for example). While debugging the edma to get things sorted out I noticed that the debug was too verbose and the important information was hidden even when the we did not asked for verbose dmaengine debug. I have included some debug cleanups for the edma dmaengine driver also. Regards, Peter --- Peter Ujfalusi (14): platform_data: edma: Be precise with the paRAM struct dma: edma: Correct the handling of src/dst_maxburst == 0 dma: edma: Add support for DMA_PAUSE/RESUME operation dma: edma: Set DMA_CYCLIC capability flag arm: common: edma: Select event queue 1 as default when booted with DT arm: common: edma: Save the number of event queues/TCs arm: common: edma: API to request non default queue for a channel DMA: edma: Use different eventq for cyclic channels dma: edma: Implement device_slave_caps callback dma: edma: Simplify direction configuration in edma_config_pset() dma: edma: Reduce debug print verbosity for non verbose debugging dma: edma: Prefix debug prints where the text were identical in prep callbacks dma: edma: Add channel number to debug prints dma: edma: Print the direction value as well when it is not supported arch/arm/common/edma.c | 34 +- drivers/dma/edma.c | 96 +- include/linux/platform_data/edma.h | 20 3 files changed, 119 insertions(+), 31 deletions(-) -- 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
[PATCH v2 02/14] dma: edma: Correct the handling of src/dst_maxburst == 0
When clients asks for maxburst = 0 it is basically the same case as if they were asking for maxburst = 1 since in both case ASYNC need to be used and the eDMA is expected to write/read one word per DMA request. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/dma/edma.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c index cd04eb7b182e..2742867fd1e6 100644 --- a/drivers/dma/edma.c +++ b/drivers/dma/edma.c @@ -285,6 +285,10 @@ static int edma_config_pset(struct dma_chan *chan, struct edmacc_param *pset, int absync; acnt = dev_width; + + /* src/dst_maxburst == 0 is the same case as src/dst_maxburst == 1 */ + if (!burst) + burst = 1; /* * If the maxburst is equal to the fifo width, use * A-synced transfers. This allows for large contiguous -- 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
[PATCH v2 01/14] platform_data: edma: Be precise with the paRAM struct
The edmacc_param struct should follow the layout of the paRAM area in the
HW. Be explicit on the size of the fields (u32) and also mark the struct
as packed to avoid any padding on non 32bit architectures.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
include/linux/platform_data/edma.h | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/include/linux/platform_data/edma.h
b/include/linux/platform_data/edma.h
index f50821cb64be..923f8a3e4ce0 100644
--- a/include/linux/platform_data/edma.h
+++ b/include/linux/platform_data/edma.h
@@ -43,15 +43,15 @@
/* PaRAM slots are laid out like this */
struct edmacc_param {
- unsigned int opt;
- unsigned int src;
- unsigned int a_b_cnt;
- unsigned int dst;
- unsigned int src_dst_bidx;
- unsigned int link_bcntrld;
- unsigned int src_dst_cidx;
- unsigned int ccnt;
-};
+ u32 opt;
+ u32 src;
+ u32 a_b_cnt;
+ u32 dst;
+ u32 src_dst_bidx;
+ u32 link_bcntrld;
+ u32 src_dst_cidx;
+ u32 ccnt;
+} __packed;
/* fields in edmacc_param.opt */
#define SAMBIT(0)
--
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
[PATCH v4 0/5] drivers: bus: omap_l3: Conversion to devm_*
Hi, Changes since v3: - Tony's ack added Changes since v2: Comments from Alexander Shiyan addressed: - Do not check the return of platform_get_resource() - no need to do that - Use devm_ioremap_resource() instead devm_request_and_ioremap() Changes since v1: - Fixed Santosh's email address in the commit messages. Cleanup of platform probe and remove (removing the remove function at the end) with converting the driver to use the devm_* versions kzalloc, ioremap and request_irq. This is a resend of an old series which I found when doing some spring cleanup on my HDD: http://www.spinics.net/lists/linux-omap/msg90531.html Regards, Peter --- Peter Ujfalusi (5): drivers: bus: omap_l3: Convert to use devm_kzalloc drivers: bus: omap_l3: Convert to use devm_ioremap_resource() drivers: bus: omap_l3: Convert to use devm_request_irq() drivers: bus: omap_l3: Remove the platform driver's remove function drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails drivers/bus/omap_l3_noc.c | 102 +- 1 file changed, 20 insertions(+), 82 deletions(-) -- 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
[PATCH v4 2/5] drivers: bus: omap_l3: Convert to use devm_ioremap_resource()
We can then remove the iounmap() calls from probe and remove.
Since the driver requests the resources via index we can do the mem resource
request within a for loop.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/bus/omap_l3_noc.c | 59 +--
1 file changed, 11 insertions(+), 48 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index d25d727e7cfb..6f58be3c2f76 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -131,52 +131,24 @@ static irqreturn_t l3_interrupt_handler(int irq, void
*_l3)
static int omap4_l3_probe(struct platform_device *pdev)
{
static struct omap4_l3 *l3;
- struct resource *res;
- int ret;
+ int ret, i;
l3 = devm_kzalloc(pdev-dev, sizeof(*l3), GFP_KERNEL);
if (!l3)
return -ENOMEM;
platform_set_drvdata(pdev, l3);
- res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
- if (!res) {
- dev_err(pdev-dev, couldn't find resource 0\n);
- return -ENODEV;
- }
-
- l3-l3_base[0] = ioremap(res-start, resource_size(res));
- if (!l3-l3_base[0]) {
- dev_err(pdev-dev, ioremap failed\n);
- return -ENOMEM;
- }
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
- if (!res) {
- dev_err(pdev-dev, couldn't find resource 1\n);
- ret = -ENODEV;
- goto err1;
- }
- l3-l3_base[1] = ioremap(res-start, resource_size(res));
- if (!l3-l3_base[1]) {
- dev_err(pdev-dev, ioremap failed\n);
- ret = -ENOMEM;
- goto err1;
- }
-
- res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
- if (!res) {
- dev_err(pdev-dev, couldn't find resource 2\n);
- ret = -ENODEV;
- goto err2;
- }
+ /* Get mem resources */
+ for (i = 0; i L3_MODULES; i++) {
+ struct resource *res = platform_get_resource(pdev,
+IORESOURCE_MEM, i);
- l3-l3_base[2] = ioremap(res-start, resource_size(res));
- if (!l3-l3_base[2]) {
- dev_err(pdev-dev, ioremap failed\n);
- ret = -ENOMEM;
- goto err2;
+ l3-l3_base[i] = devm_ioremap_resource(pdev-dev, res);
+ if (IS_ERR(l3-l3_base[i])) {
+ dev_err(pdev-dev, ioremap %d failed\n, i);
+ return PTR_ERR(l3-l3_base[i]);
+ }
}
/*
@@ -189,7 +161,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
if (ret) {
pr_crit(L3: request_irq failed to register for 0x%x\n,
l3-debug_irq);
- goto err3;
+ return ret;
}
l3-app_irq = platform_get_irq(pdev, 1);
@@ -206,12 +178,6 @@ static int omap4_l3_probe(struct platform_device *pdev)
err4:
free_irq(l3-debug_irq, l3);
-err3:
- iounmap(l3-l3_base[2]);
-err2:
- iounmap(l3-l3_base[1]);
-err1:
- iounmap(l3-l3_base[0]);
return ret;
}
@@ -221,9 +187,6 @@ static int omap4_l3_remove(struct platform_device *pdev)
free_irq(l3-app_irq, l3);
free_irq(l3-debug_irq, l3);
- iounmap(l3-l3_base[0]);
- iounmap(l3-l3_base[1]);
- iounmap(l3-l3_base[2]);
return 0;
}
--
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
[PATCH v4 5/5] drivers: bus: omap_l3: Change pr_crit() to dev_err() when IRQ request fails
Use dev_err() which will going to print the driver's name as well and the
KERN_ERR level is sufficient in this case (we also print via dev_err when
there is an error with the mem resources)
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/bus/omap_l3_noc.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 0eff48585ae3..972691a668a3 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -158,8 +158,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(pdev-dev, l3-debug_irq, l3_interrupt_handler,
IRQF_DISABLED, l3-dbg-irq, l3);
if (ret) {
- pr_crit(L3: request_irq failed to register for 0x%x\n,
- l3-debug_irq);
+ dev_err(pdev-dev, request_irq failed for %d\n,
+ l3-debug_irq);
return ret;
}
@@ -167,8 +167,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
ret = devm_request_irq(pdev-dev, l3-app_irq, l3_interrupt_handler,
IRQF_DISABLED, l3-app-irq, l3);
if (ret)
- pr_crit(L3: request_irq failed to register for 0x%x\n,
- l3-app_irq);
+ dev_err(pdev-dev, request_irq failed for %d\n, l3-app_irq);
return ret;
}
--
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
[PATCH v4 3/5] drivers: bus: omap_l3: Convert to use devm_request_irq()
With this we can remove the free_irq() calls from probe and remove.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/bus/omap_l3_noc.c | 23 +--
1 file changed, 5 insertions(+), 18 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 6f58be3c2f76..25bcb60be880 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -155,9 +155,8 @@ static int omap4_l3_probe(struct platform_device *pdev)
* Setup interrupt Handlers
*/
l3-debug_irq = platform_get_irq(pdev, 0);
- ret = request_irq(l3-debug_irq,
- l3_interrupt_handler,
- IRQF_DISABLED, l3-dbg-irq, l3);
+ ret = devm_request_irq(pdev-dev, l3-debug_irq, l3_interrupt_handler,
+ IRQF_DISABLED, l3-dbg-irq, l3);
if (ret) {
pr_crit(L3: request_irq failed to register for 0x%x\n,
l3-debug_irq);
@@ -165,29 +164,17 @@ static int omap4_l3_probe(struct platform_device *pdev)
}
l3-app_irq = platform_get_irq(pdev, 1);
- ret = request_irq(l3-app_irq,
- l3_interrupt_handler,
- IRQF_DISABLED, l3-app-irq, l3);
- if (ret) {
+ ret = devm_request_irq(pdev-dev, l3-app_irq, l3_interrupt_handler,
+ IRQF_DISABLED, l3-app-irq, l3);
+ if (ret)
pr_crit(L3: request_irq failed to register for 0x%x\n,
l3-app_irq);
- goto err4;
- }
-
- return 0;
-err4:
- free_irq(l3-debug_irq, l3);
return ret;
}
static int omap4_l3_remove(struct platform_device *pdev)
{
- struct omap4_l3 *l3 = platform_get_drvdata(pdev);
-
- free_irq(l3-app_irq, l3);
- free_irq(l3-debug_irq, l3);
-
return 0;
}
--
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
[PATCH v4 4/5] drivers: bus: omap_l3: Remove the platform driver's remove function
It is NOP after the devm_* conversion.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/bus/omap_l3_noc.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index 25bcb60be880..0eff48585ae3 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -173,11 +173,6 @@ static int omap4_l3_probe(struct platform_device *pdev)
return ret;
}
-static int omap4_l3_remove(struct platform_device *pdev)
-{
- return 0;
-}
-
#if defined(CONFIG_OF)
static const struct of_device_id l3_noc_match[] = {
{.compatible = ti,omap4-l3-noc, },
@@ -190,7 +185,6 @@ MODULE_DEVICE_TABLE(of, l3_noc_match);
static struct platform_driver omap4_l3_driver = {
.probe = omap4_l3_probe,
- .remove = omap4_l3_remove,
.driver = {
.name = omap_l3_noc,
.owner = THIS_MODULE,
--
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
[PATCH v4 1/5] drivers: bus: omap_l3: Convert to use devm_kzalloc
We can remove the kfree() calls from probe and remove.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
Reviewed-by: Santosh Shilimkar santosh.shilim...@ti.com
Acked-by: Tony Lindgren t...@atomide.com
---
drivers/bus/omap_l3_noc.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/drivers/bus/omap_l3_noc.c b/drivers/bus/omap_l3_noc.c
index feeecae623f6..d25d727e7cfb 100644
--- a/drivers/bus/omap_l3_noc.c
+++ b/drivers/bus/omap_l3_noc.c
@@ -134,7 +134,7 @@ static int omap4_l3_probe(struct platform_device *pdev)
struct resource *res;
int ret;
- l3 = kzalloc(sizeof(*l3), GFP_KERNEL);
+ l3 = devm_kzalloc(pdev-dev, sizeof(*l3), GFP_KERNEL);
if (!l3)
return -ENOMEM;
@@ -142,15 +142,13 @@ static int omap4_l3_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res) {
dev_err(pdev-dev, couldn't find resource 0\n);
- ret = -ENODEV;
- goto err0;
+ return -ENODEV;
}
l3-l3_base[0] = ioremap(res-start, resource_size(res));
if (!l3-l3_base[0]) {
dev_err(pdev-dev, ioremap failed\n);
- ret = -ENOMEM;
- goto err0;
+ return -ENOMEM;
}
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
@@ -214,8 +212,6 @@ err2:
iounmap(l3-l3_base[1]);
err1:
iounmap(l3-l3_base[0]);
-err0:
- kfree(l3);
return ret;
}
@@ -228,7 +224,6 @@ static int omap4_l3_remove(struct platform_device *pdev)
iounmap(l3-l3_base[0]);
iounmap(l3-l3_base[1]);
iounmap(l3-l3_base[2]);
- kfree(l3);
return 0;
}
--
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
AM3517: Address Hole seen by USB_OTG at address dc0f9c0c
am3517-evm: http://slexy.org/raw/s2136sr6sb Just noticed this, but present in v3.14-rc1(http://slexy.org/view/s21053Cq8K) as well (dont have older logs remaining in my machine at least).. [0.392086] Address Hole seen by USB_OTG at address dc0f9c0c [0.392115] [ cut here ] [0.392169] WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_smx.c:162 omap3_l3_app_irq+0x100/0x128() [0.392186] Modules linked in: [0.392221] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.14.0-next-20140401-6-g6e78bd6 #1 [0.392279] [c0014cd8] (unwind_backtrace) from [c0011968] (show_stack+0x10/0x14) [0.392312] [c0011968] (show_stack) from [c053fe1c] (dump_stack+0x78/0x94) [0.392341] [c053fe1c] (dump_stack) from [c003fc4c] (warn_slowpath_common+0x6c/0x8c) [0.392368] [c003fc4c] (warn_slowpath_common) from [c003fc88] (warn_slowpath_null+0x1c/0x24) [0.392394] [c003fc88] (warn_slowpath_null) from [c02f1c58] (omap3_l3_app_irq+0x100/0x128) [0.392434] [c02f1c58] (omap3_l3_app_irq) from [c008e098] (handle_irq_event_percpu+0x58/0x20c) [0.392463] [c008e098] (handle_irq_event_percpu) from [c008e288] (handle_irq_event+0x3c/0x5c) [0.392495] [c008e288] (handle_irq_event) from [c0090b78] (handle_level_irq+0xac/0x148) [0.392523] [c0090b78] (handle_level_irq) from [c008d9a0] (generic_handle_irq+0x20/0x30) [0.392551] [c008d9a0] (generic_handle_irq) from [c000ef48] (handle_IRQ+0x4c/0xac) [0.392577] [c000ef48] (handle_IRQ) from [c0008800] (omap3_intc_handle_irq+0x80/0x9c) [0.392610] [c0008800] (omap3_intc_handle_irq) from [c0546024] (__irq_svc+0x44/0x5c) [0.392627] Exception stack(0xce055d90 to 0xce055dd8) [0.392650] 5d80: 0001 ce053068 ce052b00 [0.392674] 5da0: 6153 ce005594 ce005594 001a ce005574 6153 [0.392696] 5dc0: ce005540 ce055dd8 c008515c c0545a18 2153 [0.392726] [c0546024] (__irq_svc) from [c0545a18] (_raw_spin_unlock_irqrestore+0x34/0x44) [0.392753] [c0545a18] (_raw_spin_unlock_irqrestore) from [c008f910] (__setup_irq+0x2d8/0x4c0) [0.392782] [c008f910] (__setup_irq) from [c008fbb0] (request_threaded_irq+0xb8/0x13c) [0.392822] [c008fbb0] (request_threaded_irq) from [c07cd288] (omap3_l3_probe+0x10c/0x16c) [0.392858] [c07cd288] (omap3_l3_probe) from [c035310c] (platform_drv_probe+0x18/0x48) [0.392887] [c035310c] (platform_drv_probe) from [c03517f8] (driver_probe_device+0x110/0x224) [0.392913] [c03517f8] (driver_probe_device) from [c03519a0] (__driver_attach+0x94/0x98) [0.392937] [c03519a0] (__driver_attach) from [c035010c] (bus_for_each_dev+0x54/0x88) [0.392961] [c035010c] (bus_for_each_dev) from [c0350f8c] (bus_add_driver+0xdc/0x1d4) [0.392985] [c0350f8c] (bus_add_driver) from [c0351fd0] (driver_register+0x78/0xf4) [0.393010] [c0351fd0] (driver_register) from [c0352af8] (platform_driver_probe+0x20/0xa4) [0.393036] [c0352af8] (platform_driver_probe) from [c0008ab8] (do_one_initcall+0x34/0x15c) [0.393065] [c0008ab8] (do_one_initcall) from [c079ac04] (kernel_init_freeable+0xfc/0x1cc) [0.393098] [c079ac04] (kernel_init_freeable) from [c053a78c] (kernel_init+0x8/0xe4) [0.393124] [c053a78c] (kernel_init) from [c000e6e8] (ret_from_fork+0x14/0x2c) [0.393372] ---[ end trace 530cbcb2923bd006 ]--- -- Regards, Nishanth Menon -- 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
[RESEND 3/3] mfd: twl6040: Clear the interrupt ID register before requesting IRQ
If for some reason the boot loader enabled the audpwron GPIO we will have pending IRQs to be handled. This seams to break twl6040 for some reason leading to non working i2c communication (i2c timeouts). Clearing the INTID register after we requested the audpwron GPIO (and set it to low) will ensure that the chip will operate normally in this case as well. Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com --- drivers/mfd/twl6040.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c index dc5c05940e96..2e6504a8e1e3 100644 --- a/drivers/mfd/twl6040.c +++ b/drivers/mfd/twl6040.c @@ -687,6 +687,9 @@ static int twl6040_probe(struct i2c_client *client, GPIOF_OUT_INIT_LOW, audpwron); if (ret) goto gpio_err; + + /* Clear any pending interrupt */ + twl6040_reg_read(twl6040, TWL6040_REG_INTID); } ret = regmap_add_irq_chip(twl6040-regmap, twl6040-irq, IRQF_ONESHOT, -- 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
[RESEND 2/3] mfd: twl6040: Move register patching earlier in probe
Make sure that we patch the ACCCTL register as the first thing when the
driver loads, thus configuring I2C fast mode and i2c access for dual access
registers.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl6040.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index 2c308750f40f..dc5c05940e96 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -665,6 +665,9 @@ static int twl6040_probe(struct i2c_client *client,
mutex_init(twl6040-mutex);
init_completion(twl6040-ready);
+ regmap_register_patch(twl6040-regmap, twl6040_patch,
+ ARRAY_SIZE(twl6040_patch));
+
twl6040-rev = twl6040_reg_read(twl6040, TWL6040_REG_ASICREV);
if (twl6040-rev 0) {
dev_err(client-dev, Failed to read revision register: %d\n,
@@ -712,10 +715,6 @@ static int twl6040_probe(struct i2c_client *client,
goto readyirq_err;
}
- /* dual-access registers controlled by I2C only */
- regmap_register_patch(twl6040-regmap, twl6040_patch,
- ARRAY_SIZE(twl6040_patch));
-
/*
* The main functionality of twl6040 to provide audio on OMAP4+ systems.
* We can add the ASoC codec child whenever this driver has been loaded.
--
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
[RESEND 1/3] mfd: twl6040: Select i2c fast mode as default with regmap patch
All boards using twl6040 configures the i2c bus to 400KHz. While twl6040's
defaults to normal mode (100KHz). So far twl6040 has no problem with i2c
communication in this configuration it is safer to select fast i2c mode.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/mfd/twl6040.c | 9 +++--
include/linux/mfd/twl6040.h | 1 +
2 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mfd/twl6040.c b/drivers/mfd/twl6040.c
index 6e88f25832fb..2c308750f40f 100644
--- a/drivers/mfd/twl6040.c
+++ b/drivers/mfd/twl6040.c
@@ -87,8 +87,13 @@ static struct reg_default twl6040_defaults[] = {
};
static struct reg_default twl6040_patch[] = {
- /* Select I2C bus access to dual access registers */
- { TWL6040_REG_ACCCTL, 0x09 },
+ /*
+* Select I2C bus access to dual access registers
+* Interrupt register is cleared on read
+* Select fast mode for i2c (400KHz)
+*/
+ { TWL6040_REG_ACCCTL,
+ TWL6040_I2CSEL | TWL6040_INTCLRMODE | TWL6040_I2CMODE(1) },
};
diff --git a/include/linux/mfd/twl6040.h b/include/linux/mfd/twl6040.h
index 81f639bc1ae6..a69d16b30c18 100644
--- a/include/linux/mfd/twl6040.h
+++ b/include/linux/mfd/twl6040.h
@@ -157,6 +157,7 @@
#define TWL6040_I2CSEL 0x01
#define TWL6040_RESETSPLIT 0x04
#define TWL6040_INTCLRMODE 0x08
+#define TWL6040_I2CMODE(x) ((x 0x3) 4)
/* STATUS (0x2E) fields */
--
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
[RESEND 0/3] mfd: twl6040: Updates for i2s speed and fix for chip deadlock
Hi, While looking into a report by Florian Vaussard [1] I have noticed couple of most likely unrelated issues: - all boards using twl6040 configures the i2c bus to 400KHz while twl6040 is set to 100KHz as default. - if I set the audpwron GPIO high [2] in the bootloader the i2c communication towards twl6040 will be broken - got confirmation from HW design teams that twl6040 can work on a bus with 400KHz even if after hard reset but it is optimal to swithc to 400KHz mode as soon as possible. The solution or these are: set the twl6040 to i2c fast mode with regmap patch Clear the INTID register right after we request the audpwron GPIO and set it to low. Generated on top of: git://git.linaro.org/people/lee.jones/mfd.git for-mfd-next Tested on PandaBoard, PandaBoardES, OMAP4-blaze (SDP) [1] http://www.spinics.net/lists/arm-kernel/msg310725.html [2] Command in u-boot to enable the audpwron on PandaBoards: gpio set 127 Regards, Peter --- Peter Ujfalusi (3): mfd: twl6040: Select i2c fast mode as default with regmap patch mfd: twl6040: Move register patching earlier in probe mfd: twl6040: Clear the interrupt ID register before requesting IRQ drivers/mfd/twl6040.c | 19 +-- include/linux/mfd/twl6040.h | 1 + 2 files changed, 14 insertions(+), 6 deletions(-) -- 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
am3517-craneboard: regression?
next-20140401-omap2plus_defconfig craneboard: Boot FAIL: http://slexy.org/raw/s2QxOJkvil multi_v7_defconfig seems to boot fine as well (http://slexy.org/raw/s20Tg7ldyt). next-20140331-omap2plus_defconfig craneboard: Boot PASS: http://slexy.org/raw/s21s8CTKxd diffstat between next-20140331 and next-20140401 showed nothing interesting on a quick look.. no other of my 17 platforms I monitor showed regression meanwhile. -- Regards, Nishanth Menon -- 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: am3517-craneboard: regression?
On Tue, Apr 1, 2014 at 8:57 AM, Nishanth Menon n...@ti.com wrote: next-20140401-omap2plus_defconfig craneboard: Boot FAIL: http://slexy.org/raw/s2QxOJkvil Looks like a false alarm.. Apologies.. http://slexy.org/raw/s21jnBobtP - i did rerun multiple times and i see it working consistently - could be something to do with remote test setup or something. Regards, Nishanth Menon -- 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/1] ARM: dts: omap5: Add clocks to USB3 PHY node
On Tue, Apr 01, 2014 at 01:37:27PM +0300, Roger Quadros wrote: The USB3 PHY driver (ti-pipe3) was updated so that the relevant clock phandles are expected in the DT node. Provide the necessary clocks. Reported-by: Kishon Vijay Abraham I kis...@ti.com Signed-off-by: Roger Quadros rog...@ti.com Great!!! Acked-by: Felipe Balbi ba...@ti.com --- arch/arm/boot/dts/omap5.dtsi | 6 ++ 1 file changed, 6 insertions(+) diff --git a/arch/arm/boot/dts/omap5.dtsi b/arch/arm/boot/dts/omap5.dtsi index 757f0b9..4df1e7a 100644 --- a/arch/arm/boot/dts/omap5.dtsi +++ b/arch/arm/boot/dts/omap5.dtsi @@ -794,6 +794,12 @@ 0x4a084c00 0x40; reg-names = phy_rx, phy_tx, pll_ctrl; ctrl-module = omap_control_usb3phy; + clocks = usb_phy_cm_clk32k, + sys_clkin, + usb_otg_ss_refclk960m; + clock-names = wkupclk, + sysclk, + refclk; #phy-cells = 0; }; }; -- 1.8.3.2 -- balbi signature.asc Description: Digital signature
[PATCH] ARM: AM335X: EVM: fix pinmux documentation in devicetree
Wrong documentation in pinmux description can be especially confusing.
Keep it proper.
Signed-off-by: Wolfram Sang w...@the-dreams.de
---
arch/arm/boot/dts/am335x-evm.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/am335x-evm.dts b/arch/arm/boot/dts/am335x-evm.dts
index 7e6c64ed966d..fb5dc92692cf 100644
--- a/arch/arm/boot/dts/am335x-evm.dts
+++ b/arch/arm/boot/dts/am335x-evm.dts
@@ -295,8 +295,8 @@
am335x_evm_audio_pins: am335x_evm_audio_pins {
pinctrl-single,pins =
- 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
mii1_rx_dv.mcasp1_aclkx */
- 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
mii1_txd3.mcasp1_fsx */
+ 0x10c (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
mii1_crs.mcasp1_aclkx */
+ 0x110 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
mii1_rxerr.mcasp1_fsx */
0x108 (PIN_OUTPUT_PULLDOWN | MUX_MODE4) /*
mii1_col.mcasp1_axr2 */
0x144 (PIN_INPUT_PULLDOWN | MUX_MODE4) /*
rmii1_ref_clk.mcasp1_axr3 */
;
--
1.9.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: OMAP baseline test results for v3.14-rc4 (SDP2430 fail to boot - mmc fs)
On 02/24/2014 12:35 PM, Paul Walmsley wrote: Boot to userspace: FAIL ( 1/12): 2430sdp http://www.pwsan.com/omap/testlogs/test_v3.14-rc4/20140224102552/boot/2430sdp/ Figured out why 2430sdp does not boot with MMC filesystem. DEVCONTROL0,1 needs to be modelled in DT-only boot as well. OMAP243X SDP # md.l 0x490022e8 1 490022e8: 002fff80../. OMAP243X SDP # md.l 0x49002274 1 49002274: 0400 OMAP243X SDP # mw.l 0x490022e8 802fff80 ^^ bit 31 is step (a) below OMAP243X SDP # mw.l 0x49002274 0500 ^^ bit 24 is step (b) below OMAP243X SDP # md.l 0x49002274 1 49002274: 0500 OMAP243X SDP # md.l 0x490022e8 1 490022e8: 802fff80../. OMAP243X SDP # boot happily detects the mmc partitions. http://slexy.org/view/s21QaCLMWQ we modelled pbias in dt so far - this is necessary, but two other steps are needed as well (based on arch/arm/mach-omap2/hsmmc.c used in non-dt boot): a) OMAP243X_CONTROL_DEVCONF1:: OMAP243X_MMC1_ACTIVE_OVERWRITE should be tweaked based on vdd b) OMAP2_CONTROL_DEVCONF0::OMAP2_MMCSDIO1ADPCLKISEL should be set for internal_clk (sdp2430). -- Regards, Nishanth Menon -- 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 00/55]: ARM: OMAP2+: PRCM move to drivers
* Tero Kristo t-kri...@ti.com [140401 01:38]: On 04/01/2014 01:09 AM, Tony Lindgren wrote: We don't want to make access to these registers available without proper frameworks as that will lead into misuse by various drivers. And cleaning up that mess later in is a huge pain. Currently, only thing that requires access to the register offsets is basically all the legacy clock data still in the kernel (when can we get rid of this, I have posted patches for it already?) and also the clockdomain / powerdomain data. I can work on getting clockdomain + powerdomain data to DT format if this would be preferred, then we can remove these data files also. Alternatively I can just move all these defines to the C files which actually use them. With display support getting merged hopefully we can retry dropping omap3 legacy booting as long as we get the missing boards working. I don't know how urgent of an issue the clock and power domains are for the data compared to clocks and muxes. But if it allows us to easily add support for new SoC variants, then yes it makes sense. But in any case the defines should be private to the code claiming the PRCM register area. So, basically you are proposing to add a regmap or regmap like API for the PRCM, which would provide access to a subset of registers only outside the PRCM driver? Some functions provided by PRCM spawn to multiple registers (like clocks), and the ranges have holes, and would require finetuning a register / bit level access map (some registers may contain functions for several drivers.) Yeah something like that as that allows implementing the Linux generic frameworks where the code really should be. And does not require exporting tons of custom functions. 2. Have the core PRCM driver(s) claim some of the regmap ranges Some PRCM features can potentially be implemented using existing Linux generic frameworks where possible for clocks, regulators, reset drivers etc. That way you can keep the register defines for these ranges private to the core PRCM driver(s). Ideally with no need to add _any_ custom exported functions here. There is separate work ongoing for reset driver, and for VC/VP, there has been some regulator related work. But yes, mostly this approach should be fine. OK cool. 3. Have the other drivers claim some regmap ranges The register ranges that are clearly owned by some driver should be claimed by those drivers. Then the defines for those registers can stay private to that driver. Some drivers that can probably own some PRCM ranges are clock drivers and voltage related drivers. Yeah, this sounds reasonable. OK 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
[PATCH] irq: crossbar: improve allocate_free_irq() complexity
current algorithm in allocate_free_irq() is O(n),
by just keeping track of last allocated IRQ with a
simple unsigned integer, we can find a free IRQ
in O(1).
Signed-off-by: Felipe Balbi ba...@ti.com
---
compile-tested only as J6 DTS is currently missing crossbar
altogether :-(
There's a drawback with this patch which I'm not sure if we
should care a lot because I couldn't entirely grasp when is
domain-xlate() called and if we will map/unmap IRQs in runtime
or will this *always* be done only during boot.
If we're talking about runtime IRQ remapping, then this, clearly,
won't work. But if this will be done only during boot up, then we
avoid iterating over the irq_map array each time we try to translate
a new IRQ prior to mapping it.
Comments are highly welcome as I'll probably learn something new
about the IRQ subsystem ;-)
drivers/irqchip/irq-crossbar.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index fc817d2..1c4da5a 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -31,6 +31,7 @@ struct crossbar_device {
void __iomem *crossbar_base;
int *register_offsets;
void (*write) (int, int);
+ unsigned int current_irq;
};
static struct crossbar_device *cb;
@@ -52,16 +53,15 @@ static inline void crossbar_writeb(int irq_no, int cb_no)
static inline int allocate_free_irq(int cb_no)
{
- int i;
+ int current_irq;
- for (i = 0; i cb-int_max; i++) {
- if (cb-irq_map[i] == IRQ_FREE) {
- cb-irq_map[i] = cb_no;
- return i;
- }
- }
+ if (cb-current_irq == cb-int_max)
+ return -ENODEV;
+
+ current_irq = cb-current_irq++;
+ cb-irq_map[current_irq++] = cb_no;
- return -ENODEV;
+ return current_irq;
}
static int crossbar_domain_map(struct irq_domain *d, unsigned int irq,
--
1.9.1.286.g5172cb3
--
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] irq: crossbar: improve allocate_free_irq() complexity
On Tue, Apr 01, 2014 at 05:44:19PM -0500, Felipe Balbi wrote:
current algorithm in allocate_free_irq() is O(n),
by just keeping track of last allocated IRQ with a
simple unsigned integer, we can find a free IRQ
in O(1).
Signed-off-by: Felipe Balbi ba...@ti.com
---
compile-tested only as J6 DTS is currently missing crossbar
altogether :-(
There's a drawback with this patch which I'm not sure if we
should care a lot because I couldn't entirely grasp when is
domain-xlate() called and if we will map/unmap IRQs in runtime
or will this *always* be done only during boot.
If we're talking about runtime IRQ remapping, then this, clearly,
won't work. But if this will be done only during boot up, then we
avoid iterating over the irq_map array each time we try to translate
a new IRQ prior to mapping it.
Comments are highly welcome as I'll probably learn something new
about the IRQ subsystem ;-)
drivers/irqchip/irq-crossbar.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/irqchip/irq-crossbar.c b/drivers/irqchip/irq-crossbar.c
index fc817d2..1c4da5a 100644
--- a/drivers/irqchip/irq-crossbar.c
+++ b/drivers/irqchip/irq-crossbar.c
@@ -31,6 +31,7 @@ struct crossbar_device {
void __iomem *crossbar_base;
int *register_offsets;
void (*write) (int, int);
+ unsigned int current_irq;
};
static struct crossbar_device *cb;
@@ -52,16 +53,15 @@ static inline void crossbar_writeb(int irq_no, int cb_no)
static inline int allocate_free_irq(int cb_no)
{
- int i;
+ int current_irq;
- for (i = 0; i cb-int_max; i++) {
- if (cb-irq_map[i] == IRQ_FREE) {
- cb-irq_map[i] = cb_no;
- return i;
- }
- }
+ if (cb-current_irq == cb-int_max)
+ return -ENODEV;
+
+ current_irq = cb-current_irq++;
+ cb-irq_map[current_irq++] = cb_no;
this increment is bogus, thought I had committed already, please ignore.
--
balbi
signature.asc
Description: Digital signature
