Re: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain
* Felipe Balbi ba...@ti.com [140730 09:23]: Hi, On Wed, Jul 30, 2014 at 10:45:41AM -0500, Nishanth Menon wrote: On Wed, Jul 30, 2014 at 9:40 AM, Felipe Balbi ba...@ti.com wrote: HI, On Tue, Jul 29, 2014 at 11:04:21PM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 09:36]: Hi, On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote: On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 07:18]: Hi, On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. This patch seems to somehow break off-idle for omap3 where it no longer wakes up. Sure your bisection is correct ? This patch just switches from legacy irq domain to linear irq domain. Yes, I tried it a few times. Just enabling retention idle hangs too with this patch. Maybe it's omap3_prcm_irq_setup that relies on 11 + OMAP_INTC_START? There may be other such issues lol. OMAP4 has the same nonsense. made me think why (if) OMAP4 works with that same setup. Does wake from OFF work with OMAP4 ? Not without similar changes, omap4+ has the same issue.. There's a RFC series from Nishant to fix some of this, and Tero is moving the PRCM into a driver. Anyway, here's a quick little hack to check if that's the reason for the regression: OK yeah that's along the same lines with Nishant's RFC series in thread [RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of interrupts FYI, it did not compile, needs to include linux/of_irq.h. But yes, I might have sent the wrong version as I had that same build error and fixed it localy. it fixes the regression for me, Also now the whole series works for me :) good to know. What do you want to do now ? Wait for PRCM to become a driver ? Wait for Nishanth's series to get accepted ? I guess the same thing could be done for OMAP3 and AM33, then we would have a chance of having working wake from idle with the new irqchip. I can repost the current series as it stands now once 17-rc1 comes out (without the build failure ofcourse).. if that helps to move it out of RFC status. That'd be great. It would be ever greater if you could add support for OMAP3 on that too. Yeah sounds good to me. Tero, does that work OK for your PRCM changes? Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] clk: ti: clk-7xx: Correct ABE DPLL configuration
On 07/31/2014 01:42 AM, Mike Turquette wrote: Quoting Tero Kristo (2014-07-30 05:27:07) On 07/30/2014 08:53 AM, Peter Ujfalusi wrote: On 07/29/2014 07:12 PM, Mike Turquette wrote: Oh yea, seems this got lost into the myriad of branches I have. I can push this on top of my for-v3.17/ti-clk-drv if you like. That is the easiest thing for me. I think that Peter wanted to take this as a fix for 3.16 though. Peter is that correct? Yes, it would have been better to have it in 3.16 along with the DRA7 ATL clock driver. W/O this patch the ATL will not going to be usable since the ABE DPLL is set too high to be usable for it's purpose. Ok, this is now pushed on top of the for-v3.17/ti-clk-driver branch in my git-repo. Mike, do you want a new pull-req for this just in case? I've picked it manually and applied on top of 3.16-rc7 for a last minute fix. I can add your Ack if you like. Ok thanks, Add my ack if you wish, no need from my side. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain
On 07/31/2014 09:28 AM, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140730 09:23]: Hi, On Wed, Jul 30, 2014 at 10:45:41AM -0500, Nishanth Menon wrote: On Wed, Jul 30, 2014 at 9:40 AM, Felipe Balbi ba...@ti.com wrote: HI, On Tue, Jul 29, 2014 at 11:04:21PM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 09:36]: Hi, On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote: On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 07:18]: Hi, On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. This patch seems to somehow break off-idle for omap3 where it no longer wakes up. Sure your bisection is correct ? This patch just switches from legacy irq domain to linear irq domain. Yes, I tried it a few times. Just enabling retention idle hangs too with this patch. Maybe it's omap3_prcm_irq_setup that relies on 11 + OMAP_INTC_START? There may be other such issues lol. OMAP4 has the same nonsense. made me think why (if) OMAP4 works with that same setup. Does wake from OFF work with OMAP4 ? Not without similar changes, omap4+ has the same issue.. There's a RFC series from Nishant to fix some of this, and Tero is moving the PRCM into a driver. Anyway, here's a quick little hack to check if that's the reason for the regression: OK yeah that's along the same lines with Nishant's RFC series in thread [RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of interrupts FYI, it did not compile, needs to include linux/of_irq.h. But yes, I might have sent the wrong version as I had that same build error and fixed it localy. it fixes the regression for me, Also now the whole series works for me :) good to know. What do you want to do now ? Wait for PRCM to become a driver ? Wait for Nishanth's series to get accepted ? I guess the same thing could be done for OMAP3 and AM33, then we would have a chance of having working wake from idle with the new irqchip. I can repost the current series as it stands now once 17-rc1 comes out (without the build failure ofcourse).. if that helps to move it out of RFC status. That'd be great. It would be ever greater if you could add support for OMAP3 on that too. Yeah sounds good to me. Tero, does that work OK for your PRCM changes? Well, this set seems to break PM. suspend-resume on omap3-beagle just hangs after this set is applied. Works fine without it with 3.16-rc5 tag. -Tero -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: OMAP3/AM3517 EHCI USB Issue
Am 29.07.2014 17:20, schrieb Michael Welling: On Tue, Jul 29, 2014 at 11:59:07AM +0300, Roger Quadros wrote: Hi Michael, On 07/28/2014 09:10 PM, Felipe Balbi wrote: On Mon, Jul 28, 2014 at 12:57:39PM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 10:57:18AM -0500, Felipe Balbi wrote: Hi, On Mon, Jul 28, 2014 at 10:29:49AM -0500, Michael Welling wrote: On Mon, Jul 28, 2014 at 11:02:47AM -0400, Alan Stern wrote: On Fri, 25 Jul 2014, Michael Welling wrote: The plot thickens So if I run the above command before anything is plugged into the ports the HUB disconnects. root@som3517:~# echo on /sys/bus/usb/devices/1-1/power/control [ 63.068839] usb 1-1: USB disconnect, device number 2 Here is the output of the usbmon output when running the above command: root@som3517:/sys/kernel/debug/usb/usbmon# cat 1t de382e40 376573 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788890604 C Ci:001:00 0 4 = 0705 de382e40 3788892965 S Ci:001:00 s a3 00 0002 0004 4 de382e40 3788893093 C Ci:001:00 0 4 = 0001 de382e40 3788894834 S Ci:001:00 s a3 00 0003 0004 4 de382e40 3788894958 C Ci:001:00 0 4 = 0001 de7d92c0 3788896519 S Ii:001:01 -115 4 de382e40 3788898778 S Ci:001:00 s a3 00 0001 0004 4 de382e40 3788900188 C Ci:001:00 0 4 = 0705 de382e40 3788902705 S Co:001:00 s 23 01 0002 0001 0 de382e40 3788905793 C Co:001:00 0 0 de382e40 3788940998 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3788942065 C Ii:001:01 0 1 = 02 de7d92c0 3788943013 S Ii:001:01 -115 4 de382e40 3788943145 C Ci:001:00 0 4 = 03050400 de382e40 3788961031 S Co:001:00 s 23 01 0012 0001 0 de382e40 3788961175 C Co:001:00 0 0 de382e40 3788961304 S Ci:002:00 s 80 00 0002 2 de382e40 3788965395 C Ci:002:00 -71 0 de249040 3788966954 S Co:001:00 s 23 03 0004 0001 0 de249040 3788968362 C Co:001:00 0 0 de249040 3789021103 S Ci:001:00 s a3 00 0001 0004 4 de7d92c0 3789022194 C Ii:001:01 0 1 = 02 de7d92c0 378906 S Ii:001:01 -115 4 de249040 3789023423 C Ci:001:00 0 4 = 01051200 de249040 3789025010 S Co:001:00 s 23 03 0004 0001 0 de249040 3789026815 C Co:001:00 0 0 de249040 3789230980 S Ci:001:00 s a3 00 0001 0004 4 de249040 378923 C Ci:001:00 0 4 = 00010300 de249040 3789232280 S Co:001:00 s 23 01 0014 0001 0 de249040 3789232404 C Co:001:00 0 0 de249040 3789233056 S Co:001:00 s 23 01 0001 0001 0 de249040 3789235345 C Co:001:00 0 0 de249040 3789236820 S Co:001:00 s 23 01 0001 0001 0 de249040 3789237201 C Co:001:00 0 0 de249040 3789238180 S Co:001:00 s 23 01 0001 0001 0 de249040 3789238510 C Co:001:00 0 0 de249040 3789240602 S Ci:001:00 s a3 00 0001 0004 4 de249040 3789241661 C Ci:001:00 0 4 = 00010300 de249040 3789242264 S Co:001:00 s 23 01 0010 0001 0 de249040 3789243921 C Co:001:00 0 0 de249040 3789246540 S Co:001:00 s 23 01 0011 0001 0 de249040 3789246930 C Co:001:00 0 0 de2490c0 3789283096 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789286255 C Ci:001:00 0 4 = 0001 de2490c0 3789330975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789332606 C Ci:001:00 0 4 = 0001 de2490c0 3789371015 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789371146 C Ci:001:00 0 4 = 0001 de2490c0 3789410975 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789411097 C Ci:001:00 0 4 = 0001 de2490c0 3789450972 S Ci:001:00 s a3 00 0001 0004 4 de2490c0 3789451081 C Ci:001:00 0 4 = 0001 de7d92c0 3789452462 C Ii:001:01 -2 0 Not sure what any of it means. Basically it means what you said above: the hub disconnected. I can't tell why. You'll have to ask someone who's familiar with the hardware on that board. Sadly, there is no one more familar with this specific hardware than myself. I can however ellaborate the hardware setup of the USB subsystem in case there is someone out there that has used a similar setup. The board uses the AM3517 SoC from TI. The SoC's USB host port (HSUSB1) is connected to a USB3320 PHY. The PHY is connected to a USB2512 switch to provide two downstream USB ports. The very same hardware worked with the 2.6.37 kernel that I am trying to move away from. It should be noted that the USB hardware work on the 3.2 kernel as well. Today I am going to try using 3.10 and 3.14 kernels see if they exhibit the same behavior. It should be noted that the 3.10 kernel did not even detect the external HUB and the 3.14 kernel exhibits the same failure as 3.16. Do you have off-while-idle enabled ? This could be, as Alan suggested, a problem with remote wakeup. EHCI on TI parts is kinda awkward, if you will, and getting remote wakeup with PM working, is generally a challenge. How would one determine if off-while-idle is enabled? Is this a flag in an entry in the devicetree? there is a pm_debug file on debugfs which you can use. Set autosuspend delay to UART (it's set to -1 by default, IIRC), then leave the board idle for a couple minutes, then read /sys/kernel/debug/pm_debug and see if the OFF() counters
[PATCH 1/2] dmaengine: edma: Do not change the error code returned from edma_alloc_slot
In case of edma_alloc_slot() failure during probe we should return the error
unchanged to make debugging easier.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 69f1f5250120..2953de0f53f3 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -1048,7 +1048,7 @@ static int edma_probe(struct platform_device *pdev)
ecc-dummy_slot = edma_alloc_slot(ecc-ctlr, EDMA_SLOT_ANY);
if (ecc-dummy_slot 0) {
dev_err(pdev-dev, Can't allocate PaRAM dummy slot\n);
- return -EIO;
+ return ecc-dummy_slot;
}
dma_cap_zero(ecc-dma_slave.cap_mask);
--
2.0.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 2/2] dmaengine: edma: Do not register second device when booted with DT
DT boot does not yet support more than one edma device. To avoid issues at
runtime we should not register the second device when the kernel is booted
with DT.
Signed-off-by: Peter Ujfalusi peter.ujfal...@ti.com
---
drivers/dma/edma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index 2953de0f53f3..d99351361fcb 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -23,6 +23,7 @@
#include linux/platform_device.h
#include linux/slab.h
#include linux/spinlock.h
+#include linux/of.h
#include linux/platform_data/edma.h
@@ -1133,7 +1134,7 @@ static int edma_init(void)
}
}
- if (EDMA_CTLRS == 2) {
+ if (!of_have_populated_dt() EDMA_CTLRS == 2) {
pdev1 = platform_device_register_full(edma_dev_info1);
if (IS_ERR(pdev1)) {
platform_driver_unregister(edma_driver);
--
2.0.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
Re: [PATCH] ARM: dts: dra7-evm: add parallel NOR flash support
+Sourav for QSPI and Balaji for mmc
On 07/30/2014 10:40 PM, Pekon Gupta wrote:
Hi Roger,
On Tue, Jul 29, 2014 at 5:45 PM, Roger Quadros rog...@ti.com wrote:
On 07/23/2014 01:58 PM, Pekon Gupta wrote:
This patch adds support for parallel NOR device (S29GL512S10) present on
J6-EVM.
The Flash device is connected to GPMC controller on chip-select[0] and
accessed
as memory-mapped device. It has data-witdh=x16, capacity-64MBytes(512Mbits)
and
is CFI compatible.
As multiple devices are share GPMC pins on this board, so following board
settings are required to detect NOR device:
SW5.1 (NAND_BOOTn) = OFF (logic-1)
SW5.2 (NOR_BOOTn) = ON (logic-0) /* Active-low */
SW5.3 (eMMC_BOOTn) = OFF (logic-1)
SW5.4 (QSPI_BOOTn) = OFF (logic-1)
Why does NOR have any dependency on states of eMMC_BOOTn and QSPI_BOOTn?
If you see the schematics of J6-EVM, GPMC data and control lines are shared
between NAND, NOR, eMMC (and probably QSPI also).
I don't have access to TI's hardaware or board schematics anymore, so
please double check.
I just took a deeper look in the schematics.
It has nothing to do with GPMC Data and control lines but with the address
lines.
The GPMC address lines are muxed on the same pins of the SoC as QSPI and MMC2.
i.e. A13-A18,CS2 for QSPI and A19-A27,CS1 for MMC2
NAND can probably work simultaneously with QSPI and MMC2 but for NOR case, QSPI
and MMC2
need to be disabled.
This is starting to look ugly where apart from changing the DIP switch the DTS
has to be
hand modified to support a certain case.
Lets leave the most usable configuration for default case i.e. NAND, QSPI and
MMC2 enabled and keep NOR information in the dts but keep it disabled with a
note that if NOR is enabled then NAND, QSPI, and MMC2 nodes need to be disabled.
I will resend this patch with the relevant changes.
cheers,
-roger
Also to maintain NAND Boot functionality, following setting are kept as
default
- NAND status=enabled
- NOR status=disabled
Too bad they designed the hardware so that either NOR or NAND can be used at
a time.
Better to mention about this limitation by stating that CS0 is shared
between NOR and NAND
and only one can be used at a time.
NAND/NOR/eMMC/QSPI effectively all are storage devices, so users may
not use all of
them at once, so may be to optimize usage of pins they added multiple
devices on CS0.
Sorry, I may not be able to re-spin this patch anytime soon, as I have
no access to TI
resources so request you to please re-send it with appropriate commit
log change as you wish.
Signed-off-by: Pekon Gupta pe...@ti.com
---
/* Flash read/write access tested after enabling NOR sub-node in DT */
linux# flash_erase /dev/mtd9 0 0
linux# dd if=/dev/urandom of=/tmp/source.hex bs=1c count=2048
linux# mtd_debug write /dev/mtd9 0x0 2048 /tmp/source.hex
linux# mtd_debug read /dev/mtd9 0x0 2048 /tmp/destination.hex
linux# diff /tmp/source.hex /tmp/destination.hex
arch/arm/boot/dts/dra7-evm.dts | 141
-
1 file changed, 140 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 4adc280..1ee9727 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -151,6 +151,66 @@
0xd0(PIN_OUTPUT | MUX_MODE0)/*
gpmc_be0n_cle */
;
};
+
+ nor_flash_x16: nor_flash_x16 {
+ /* On DRA7 EVM, NOR_BOOTn comes from DIP switch
+ * So NOR flash requires following switch settings:
+ * SW5.1 (NAND_BOOTn) = OFF (logic-1)
+ * SW5.2 (NOR_BOOTn) = ON (logic-0) Active-low
+ * SW5.3 (eMMC_BOOTn) = OFF (logic-1)
+ * SW5.4 (QSPI_BOOTn) = OFF (logic-1)
+ */
The only requirement for NOR_BOOTn is SW5.2 = ON and SW5.1 (NAND_BOOTn) =
OFF.
As mentioned above, please check board schematics
IIRC, GPMC lines pass through various levels of on-board
bi-directional multiplexers,
And 'select' lines of these multiplexers are controlled indirectly via
these xxx_BOOTn switches.
[...]
i2c1 {
@@ -417,8 +477,9 @@
status = okay;
pinctrl-names = default;
pinctrl-0 = nand_flash_x16;
- ranges = 0 0 0 0x0100;/* minimum GPMC partition = 16MB */
+ ranges = 0 0 0x0800 0x0400; /* address offset=128MB,
range=512Mb=64MB */
nand@0,0 {
+ status = okay;
Not needed. If it is not explicitly disabled it is always enabled by default.
Yes, but good to have clarity in DTS, as most users will just copy-paste
TI-EVM
DTS and then tweak it for their own custom board DTS. So better to have this
mentioned explicitely.
with regards, pekon
--
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
Re: [PATCH 1/2] dmaengine: edma: Do not change the error code returned from edma_alloc_slot
On Thu, Jul 31, 2014 at 01:12:37PM +0300, Peter Ujfalusi wrote: In case of edma_alloc_slot() failure during probe we should return the error unchanged to make debugging easier. Applied both Thanks -- ~Vinod -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] dmaengine: edma: fix two faults which happen with the 8250_dma user
On Tue, Jul 29, 2014 at 08:58:58PM +0200, Sebastian Andrzej Siewior wrote:
The rx path of the 8250_dma user in the RX-timeout case:
- it starts the RX transfer
- if the rx-timeout interrupt occures, it dmaengine_pause() the transfer
- step two is dmaengine_terminate_all() on this channel.
Okay after this whole channel needs to be reset, which means all the
descriptors are discared.
- based on dmaengine_tx_status() it learns the number of transfered
bytes.
- the rx interrupt occures,
why, channel is terminated, so existing txn needs to be aborted too
it does not start the RX-transfer because
according to dmaengine_tx_status() the status of the current transfer
is still DMA_IN_PROGRESS because the earlier dmaengine_terminate_all()
did not reset this.
there is no current transfer anymore
- on rx-timeout it invokes dmaengine_pause() again. This time, it
segfaults because the channel has no descriptor yet.
To make the upper case work better, this patch adds dma_cookie_complete()
to complete the cookie. Also it adds is an additional check for echan-edesc
in case the channel has no descriptor assigned.
I think we are fixing the behvaiour rather than cause. terminate_all(()
needs to do a proper cleanup of the channel
And this looks a series, without cover letter sent to all. Which makes it a
bit hard to see what is getting done
--
~Vinod
Cc: Joel Fernandes jo...@ti.com
Cc: Vinod Koul vinod.k...@intel.com
Cc: Dan Williams dan.j.willi...@intel.com
Cc: dmaeng...@vger.kernel.org
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/edma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/dma/edma.c b/drivers/dma/edma.c
index d08c4de..ff05dd4 100644
--- a/drivers/dma/edma.c
+++ b/drivers/dma/edma.c
@@ -256,6 +256,7 @@ static int edma_terminate_all(struct edma_chan *echan)
* echan-edesc is NULL and exit.)
*/
if (echan-edesc) {
+ dma_cookie_complete(echan-edesc-vdesc.tx);
echan-edesc = NULL;
edma_stop(echan-ch_num);
}
@@ -282,7 +283,7 @@ static int edma_slave_config(struct edma_chan *echan,
static int edma_dma_pause(struct edma_chan *echan)
{
/* Pause/Resume only allowed with cyclic mode */
- if (!echan-edesc-cyclic)
+ if (!echan-edesc || !echan-edesc-cyclic)
return -EINVAL;
edma_pause(echan-ch_num);
--
2.0.1
--
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/7] dmaengine: edma: fix two faults which happen with the 8250_dma user
On 07/31/2014 02:17 PM, Vinod Koul wrote: On Tue, Jul 29, 2014 at 08:58:58PM +0200, Sebastian Andrzej Siewior wrote: The rx path of the 8250_dma user in the RX-timeout case: - it starts the RX transfer - if the rx-timeout interrupt occures, it dmaengine_pause() the transfer - step two is dmaengine_terminate_all() on this channel. Okay after this whole channel needs to be reset, which means all the descriptors are discared. - based on dmaengine_tx_status() it learns the number of transfered bytes. - the rx interrupt occures, why, channel is terminated, so existing txn needs to be aborted too serial8250_rx_dma() is invoked on 8250' RX interrupt to move all the data from the FIFO to memory. This is when the dma transfer is programmed (on all platforms but omap because we need to program it before the data is in the FIFO but this detail shouldn't matter). On Omap (atleast) it happens that if there are not enough characters in the FIFO over a given time the UART triggers a RX-timeout and no bytes are moved by the DMA engine. This is when UART_IIR_RX_TIMEOUT is hit. At that point it invokes the completion hanlder (__dma_rx_do_complete()) to learn how much bytes were transfered and to cancel the transfer (so the remaining bytes can be fetched via PIO). it does not start the RX-transfer because according to dmaengine_tx_status() the status of the current transfer is still DMA_IN_PROGRESS because the earlier dmaengine_terminate_all() did not reset this. there is no current transfer anymore That is correct but since we never completed that cookie, dmaengine_tx_status() returns DMA_IN_PROGRESS and the 8250_dma does no book keeping of its own. - on rx-timeout it invokes dmaengine_pause() again. This time, it segfaults because the channel has no descriptor yet. To make the upper case work better, this patch adds dma_cookie_complete() to complete the cookie. Also it adds is an additional check for echan-edesc in case the channel has no descriptor assigned. I think we are fixing the behvaiour rather than cause. terminate_all(() needs to do a proper cleanup of the channel The channel is clean an can be reused. Since the cookie has never been completed / incremented, serial8250_rx_dma() never enqueues another transfer. Are you suggesting that the 8250_dma driver should have its own book keeping whether it started a transfer or not? Either way, it looks wrong that dmaengine_tx_status() reports DMA_IN_PROGRESS even that the transfer got aborted and the channel is properly cleaned up. And this looks a series, without cover letter sent to all. Which makes it a bit hard to see what is getting done What is getting done, is getting 8250_dma used on omap after the 8250 based driver is used for uart. The UART is mostly the same on am335x (where edma is used) as on DRA7 (where omap-dma is used) that is why I made the two patches for the two dma engines. The cover letter is at [1]. I tried to cover the problem and all informations in the patch description so you have all the required informations. [0] drivers/tty/serial/8250/8250_dma.c [1] https://lkml.org/lkml/2014/7/29/513 Sebastian -- 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.16-rc4
On 07/30/2014 08:39 AM, Tony Lindgren wrote:
8 ---
From: Tony Lindgrent...@atomide.com
Date: Tue, 29 Jul 2014 22:36:59 -0700
Subject: [PATCH] ARM: dts: Enable UART wake-up events for beagleboard
For device tree based booting, we need to use wake-up
interrupts like we already do for some omaps. This fixes
a PM regression on beagleboard compared to legacy booting.
Signed-off-by: Tony Lindgrent...@atomide.com
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -292,6 +292,7 @@
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
+ interrupts-extended = intc 74 omap3_pmx_core OMAP3_UART3_RX;
};
gpio1 {
--
The above patch works for me with ret/off-idle on beagle rev C4 on top
of 3.16-rc5. Without it, the board just seems to hang with ret, and with
off, it just doesn't respond to anything on uart but seems alive otherwise.
Tested-by: Tero Kristo t-kri...@ti.com
--
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.16-rc4
* Paul Walmsley p...@pwsan.com [140730 00:55]: On Tue, 29 Jul 2014, Tony Lindgren wrote: The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one? 3530es3beagle retention dynamic idle tests hang on next-20140729. (Maybe other boards fail too - haven't tested any others). I just checked that today's linux next works for off-idle and wake-up events for at least 37xx evm. http://www.pwsan.com/omap/testlogs/next_20140729/20140730010841/pm/3530es3beagle/3530es3beagle_log.txt Adding the patch you sent doesn't change that, but now some extra warning messages appear (PRM: I/O chain clock line assertion timed out): http://www.pwsan.com/omap/testlogs/next_20140729_beagle_pm/20140730004856/pm/3530es3beagle/3530es3beagle_log.txt Weird it should just work. I don't know why the PRM: I/O chain clock line assertion timed out happens for you, I have not seen that. So far I've tested it on n900, beagle xm and 37xx-evm. None of those are 3530 though, but it should behave the same way as on n900. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/2] Manage OMAP34xx ES3.1.2 rev to resume from suspend
Hi, My kernel crashed when my OMAP34xx ES3.1.2 leave suspend mode. The first patch seems to solve the issue, and the second one corrects Linux kernel coding style problems. Jeremy Vial (2): ARM: OMAP3: Fix choice of omap3_restore_es function in OMAP34XX rev3.1.2 case. ARM: OMAP3: Fix coding style problems in arch/arm/mach-omap2/control.c arch/arm/mach-omap2/control.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 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
[PATCH 2/2] ARM: OMAP3: Fix coding style problems in arch/arm/mach-omap2/control.c
Signed-off-by: Jeremy Vial jv...@adeneo-embedded.com
---
arch/arm/mach-omap2/control.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c
index acadac0..cc5d767 100644
--- a/arch/arm/mach-omap2/control.c
+++ b/arch/arm/mach-omap2/control.c
@@ -281,6 +281,7 @@ void omap3_clear_scratchpad_contents(void)
u32 max_offset = OMAP343X_SCRATCHPAD_ROM_OFFSET;
void __iomem *v_addr;
u32 offset = 0;
+
v_addr = OMAP2_L4_IO_ADDRESS(OMAP343X_SCRATCHPAD_ROM);
if (omap2_prm_read_mod_reg(OMAP3430_GR_MOD, OMAP3_PRM_RSTST_OFFSET)
OMAP3430_GLOBAL_COLD_RST_MASK) {
@@ -475,7 +476,6 @@ void omap3_control_save_context(void)
control_context.csi = omap_ctrl_readl(OMAP343X_CONTROL_CSI);
control_context.padconf_sys_nirq =
omap_ctrl_readl(OMAP343X_CONTROL_PADCONF_SYSNIRQ);
- return;
}
void omap3_control_restore_context(void)
@@ -533,7 +533,6 @@ void omap3_control_restore_context(void)
omap_ctrl_writel(control_context.csi, OMAP343X_CONTROL_CSI);
omap_ctrl_writel(control_context.padconf_sys_nirq,
OMAP343X_CONTROL_PADCONF_SYSNIRQ);
- return;
}
void omap3630_ctrl_disable_rta(void)
--
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
[PATCH 1/2] ARM: OMAP3: Fix choice of omap3_restore_es function in OMAP34XX rev3.1.2 case.
According to the comment “restore_es3: applies to 34xx = ES3.0 in arch/arm/mach-omap2/sleep34xx.S”, omap3_restore_es3 should be used if the revision of an OMAP34xx is ES3.1.2. Signed-off-by: Jeremy Vial jv...@adeneo-embedded.com --- arch/arm/mach-omap2/control.c |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/control.c b/arch/arm/mach-omap2/control.c index 751f354..acadac0 100644 --- a/arch/arm/mach-omap2/control.c +++ b/arch/arm/mach-omap2/control.c @@ -314,7 +314,8 @@ void omap3_save_scratchpad_contents(void) scratchpad_contents.public_restore_ptr = virt_to_phys(omap3_restore_3630); else if (omap_rev() != OMAP3430_REV_ES3_0 - omap_rev() != OMAP3430_REV_ES3_1) + omap_rev() != OMAP3430_REV_ES3_1 + omap_rev() != OMAP3430_REV_ES3_1_2) scratchpad_contents.public_restore_ptr = virt_to_phys(omap3_restore); else -- 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: [PATCH 29/35] arm: omap: intc: switch over to linear irq domain
Hi, On Thu, Jul 31, 2014 at 10:57:09AM +0300, Tero Kristo wrote: On 07/31/2014 09:28 AM, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140730 09:23]: Hi, On Wed, Jul 30, 2014 at 10:45:41AM -0500, Nishanth Menon wrote: On Wed, Jul 30, 2014 at 9:40 AM, Felipe Balbi ba...@ti.com wrote: HI, On Tue, Jul 29, 2014 at 11:04:21PM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 09:36]: Hi, On Tue, Jul 29, 2014 at 10:40:57AM -0500, Felipe Balbi wrote: On Tue, Jul 29, 2014 at 08:20:52AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140729 07:18]: Hi, On Tue, Jul 29, 2014 at 05:14:25AM -0700, Tony Lindgren wrote: * Felipe Balbi ba...@ti.com [140728 14:19]: now that we don't need to support legacy board-files, we can completely switch over to a linear irq domain and make use of irq_alloc_domain_generic_chips() to allocate all generic irq chips for us. This patch seems to somehow break off-idle for omap3 where it no longer wakes up. Sure your bisection is correct ? This patch just switches from legacy irq domain to linear irq domain. Yes, I tried it a few times. Just enabling retention idle hangs too with this patch. Maybe it's omap3_prcm_irq_setup that relies on 11 + OMAP_INTC_START? There may be other such issues lol. OMAP4 has the same nonsense. made me think why (if) OMAP4 works with that same setup. Does wake from OFF work with OMAP4 ? Not without similar changes, omap4+ has the same issue.. There's a RFC series from Nishant to fix some of this, and Tero is moving the PRCM into a driver. Anyway, here's a quick little hack to check if that's the reason for the regression: OK yeah that's along the same lines with Nishant's RFC series in thread [RFC PATCH 0/7] ARM: OMAP4+: PRM: minor cleanups and dt support of interrupts FYI, it did not compile, needs to include linux/of_irq.h. But yes, I might have sent the wrong version as I had that same build error and fixed it localy. it fixes the regression for me, Also now the whole series works for me :) good to know. What do you want to do now ? Wait for PRCM to become a driver ? Wait for Nishanth's series to get accepted ? I guess the same thing could be done for OMAP3 and AM33, then we would have a chance of having working wake from idle with the new irqchip. I can repost the current series as it stands now once 17-rc1 comes out (without the build failure ofcourse).. if that helps to move it out of RFC status. That'd be great. It would be ever greater if you could add support for OMAP3 on that too. Yeah sounds good to me. Tero, does that work OK for your PRCM changes? Well, this set seems to break PM. suspend-resume on omap3-beagle just hangs after this set is applied. Works fine without it with 3.16-rc5 tag. did you apply the quick little hack to prm3xxx.c ? prcm IRQ is hardcoded to 11, once we switch to a linear irq domain, irq_base may change. -- balbi signature.asc Description: Digital signature
[patch] usb: dwc3: omap: signedness bug in dwc3_omap_set_utmi_mode()
ret should be signed. It's only used for zero and negative error
codes.
Signed-off-by: Dan Carpenter dan.carpen...@oracle.com
diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index ef4936f..9dcfbe7 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -425,7 +425,7 @@ static void dwc3_omap_set_utmi_mode(struct dwc3_omap *omap)
static int dwc3_omap_extcon_register(struct dwc3_omap *omap)
{
- u32 ret;
+ int ret;
struct device_node *node = omap-dev-of_node;
struct extcon_dev *edev;
--
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 v3 0/7] Enable L2 cache support on Exynos4210/4x12 SoCs
On 17.07.2014 18:38, Tomasz Figa wrote:
This series intends to add support for L2 cache on Exynos4 SoCs on boards
running under secure firmware, which requires certain initialization steps
to be done with help of firmware, as selected registers are writable only
from secure mode.
First four patches extend existing support for secure write in L2C driver
to account for design of secure firmware running on Exynos. Namely:
1) direct read access to certain registers is needed on Exynos, because
secure firmware calls set several registers at once,
2) not all boards are running secure firmware, so .write_sec callback
needs to be installed in Exynos firmware ops initialization code,
3) write access to {DATA,TAG}_LATENCY_CTRL registers fron non-secure world
is not allowed and so must use l2c_write_sec as well,
4) on certain boards, default value of prefetch register is incorrect
and must be overridden at L2C initialization.
For boards running with firmware that provides access to individual
L2C registers this series should introduce no functional changes. However
since the driver is widely used on other platforms I'd like to kindly ask
any interested people for testing.
Further two patches add impelmentation of .write_sec for Exynos secure
firmware and necessary DT nodes to enable L2 cache.
Tested on Exynos4210-based Universal C210 and Trats (both without secure
firmware) and Exynos4412-based TRATS2 and ODROID-U3 boards (both with secure
firmware).
Depends on:
- [PATCH] ARM: make it easier to check the CPU part number correctly
(http://thread.gmane.org/gmane.linux.ports.arm.kernel/335126
already in linux-next)
- [PATCH v2 0/2] Firmware-assisted suspend/resume of Exynos SoCs
(https://lkml.org/lkml/2014/7/17/431)
Changes since v2:
(https://lkml.org/lkml/2014/6/25/416)
- refactored L2C driver to use commit-like interface and make it no longer
depend on availability of writes to individual registers,
- moved L2C resume to assembly code, because doing it later makes some
systems unstable - this is also needed for deeper cpuidle modes,
- dropped unnecessary patch hacking around the .write_sec interface,
- dropped patch making the driver use l2c_write_sec() for LATENCY_CTRL
registers as Exynos is no longer affected and I'm not aware of any
reports that this is also needed on other platforms (can be applied
separately if it turns out to be so),
- rebased onto next-20140717 tag of linux-next tree.
Changes since v1:
(https://www.mail-archive.com/linux-omap@vger.kernel.org/msg106323.html)
- rebased onto for-next branch of linux-samsung tree,
- changed argument order of outer_cache.write_sec() callback to match
l2c_write_sec() function in cache-l2x0.c,
- added support of overriding of prefetch settings to work around incorrect
default settings on certain Exynos4x12-based boards,
- added call to firmware to invalidate whole L2 cache before setting enable
bit in L2C control register (required by Exynos secure firmware).
Tomasz Figa (7):
ARM: l2c: Refactor the driver to use commit-like interface
ARM: l2c: Add interface to ask hypervisor to configure L2C
ARM: l2c: Get outer cache .write_sec callback from mach_desc only if
not NULL
ARM: l2c: Add support for overriding prefetch settings
ARM: EXYNOS: Add .write_sec outer cache callback for L2C-310
ARM: EXYNOS: Add support for non-secure L2X0 resume
ARM: dts: exynos4: Add nodes for L2 cache controller
Documentation/devicetree/bindings/arm/l2cc.txt | 10 +
arch/arm/boot/dts/exynos4210.dtsi | 9 +
arch/arm/boot/dts/exynos4x12.dtsi | 14 ++
arch/arm/include/asm/outercache.h | 3 +
arch/arm/kernel/irq.c | 3 +-
arch/arm/mach-exynos/common.h | 1 +
arch/arm/mach-exynos/firmware.c| 40
arch/arm/mach-exynos/sleep.S | 41 +
arch/arm/mm/cache-l2x0.c | 245
-
9 files changed, 274 insertions(+), 92 deletions(-)
Any comments for this series?
Best regards,
Tomasz
--
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.16-rc4
On Thu, 31 Jul 2014, Tony Lindgren wrote: * Paul Walmsley p...@pwsan.com [140730 00:55]: On Tue, 29 Jul 2014, Tony Lindgren wrote: The following patch should fix the tests above for 3530es3beagle. Care to test and ack as I don't have one? 3530es3beagle retention dynamic idle tests hang on next-20140729. (Maybe other boards fail too - haven't tested any others). I just checked that today's linux next works for off-idle and wake-up events for at least 37xx evm. I ran the full set of tests across all boards. The only board that passed the dynamic idle testing on next-20140729 was the 3730beaglexm. http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/README.txt 37xxevm hangs on the first suspend entry: http://www.pwsan.com/omap/testlogs/next_20140729/20140730124836/pm/37xxevm/37xxevm_log.txt If I find some extra time, I'll set up a bisection run. - Paul -- To unsubscribe from this list: send the line unsubscribe linux-omap in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
