Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
On 09/03/2014 07:48 PM, Tony Lindgren wrote: I will check this upper part of this email soon… OK. At least it's starting to now sound that the bugs are pretty much the same with 8250 and serial-omap :) Do you see a reason for not posting the entire series again since now I am bug compatible in the pm-runtime part? We have -rc3 and I would like to get this merge the series I have now and this seems to be the only problem I am aware of. Regards, Tony 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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140904 06:46]: On 09/03/2014 07:48 PM, Tony Lindgren wrote: I will check this upper part of this email soon… OK. At least it's starting to now sound that the bugs are pretty much the same with 8250 and serial-omap :) Do you see a reason for not posting the entire series again since now I am bug compatible in the pm-runtime part? We have -rc3 and I would like to get this merge the series I have now and this seems to be the only problem I am aware of. Yeah makes sense to me. Thanks for ensuring the bug compability :) 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 15/15] tty: serial: 8250: omap: add dma support
On 09/04/2014 04:52 PM, Tony Lindgren wrote: Yeah makes sense to me. Thanks for ensuring the bug compability :) Thanks. What about the ttyOx vs ttySx. Do you want me to add kernel line fixup somewhere arch/arm or we ignore this for now? Greg didn't say anything… Regards, Tony 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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140904 07:56]: On 09/04/2014 04:52 PM, Tony Lindgren wrote: Yeah makes sense to me. Thanks for ensuring the bug compability :) Thanks. What about the ttyOx vs ttySx. Do you want me to add kernel line fixup somewhere arch/arm or we ignore this for now? Greg didn't say anything… I suggest we have both drivers just available first and then attempt to deal with the removal of most of omap-serial later on. If both drivers are present, we should try to ensure 8250 gets probed first which I believe it already does based on the Makefile order. Once the 8250 based driver is known to work, it might make sense to remove most of the functions in omap-serial and have it use the 8250 functions too to remove duplicate code. That might be already enough and no proxying is needed and we get rid of the duplicate code :) 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 15/15] tty: serial: 8250: omap: add dma support
On 09/02/2014 10:15 PM, Tony Lindgren wrote: - I see to face two kind of deaths: - the LED still goes on and off and the uart just does not respond even if I tell the button print something on the screen (the button also changes the frequency of the LED so I know that the button is doing something). Also from dumping the content of /proc/interrupts it seems that a wake up is made, the uart should have restored the registers. OK yeah this is the case I was seeing too. So do you just set the LED triggers to none in sysfs to make it easier to reproduce? Yes. - one where the system is dead and the LED does not blink anymore. Also my button is dead. This I don't think I've seen. This could also be the errata issue on your earlier rev beagleboard-xm with off-idle. might be. Your pstore hint gave me something. I tried that earlier but somehow assumed that dram content was killed on init. But the content is even there are pressing the reset button :) However, I was able to capture the case where the LED was not blinking: The IIR register says 0xc6 (= line status error). That is okay. At the same time LSR register says 0xe0. This is not okay. It means that there is some kind of error and at least one error bit is set in this register which is not the case. Also those bits are cleared on read which does not happen here. And we loop forever so the LED does blink anymore. The RX-count register says that it is empty which sense because bit 0 is not set (in LSR). However I can read multiple times from the RX FIFO until I get the unhandled bus access error which usually happens right away if the empty FIFO is read on omap3 HW. In the last test I mange to read 91 times before the crash. I hoped that this FIFO read would make the interrupt go away but it did not. The HW seems to be in a strange state. It might be either the errata or something else. I even took the resume routine from omap-serial in case I did something wrong. In my last test it worked for 10minues before the interrupt storm came. This is probably the same thing I see on the omap-serial driver where I got from pstore: [ 32.659271] random: nonblocking pool is initialized [ 212.170623] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper:0] So I *guess* the interrupt routine is looping. This is problem one, no idea what is going on (the register status captured on 8250-omap makes no sense). Problem two, where the UART does not wakeup: What I observed is that sometimes the UART does not wake up properly i.e. it does not write anything on the console, even where it should. I can't tell if the read is working properly, the write does not. From my capture I see that the resume routine was running and the register should have been written. That means the UART should be up and running but nothing happens. It often works again after the system comes out of resume again (i.e. RPM suspens and resumes the UART). So it is okay on the next wakeup. Or the wakeup after next. From the script: | while ((1)) | do | | echo -n 409-chars /dev/ttyUSB0 | | sleep 1 | a=$(date) | echo -e \n#$a /dev/ttyUSB0 | echo $a | sleep 13; | done I see that sometimes one or two sequential timestamps are missing. And the it continues like nothing happened. Tony 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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140903 09:46]: On 09/02/2014 10:15 PM, Tony Lindgren wrote: - I see to face two kind of deaths: - the LED still goes on and off and the uart just does not respond even if I tell the button print something on the screen (the button also changes the frequency of the LED so I know that the button is doing something). Also from dumping the content of /proc/interrupts it seems that a wake up is made, the uart should have restored the registers. OK yeah this is the case I was seeing too. So do you just set the LED triggers to none in sysfs to make it easier to reproduce? Yes. - one where the system is dead and the LED does not blink anymore. Also my button is dead. This I don't think I've seen. This could also be the errata issue on your earlier rev beagleboard-xm with off-idle. might be. Your pstore hint gave me something. I tried that earlier but somehow assumed that dram content was killed on init. But the content is even there are pressing the reset button :) Yeah pstore is very nice for debugging mystery hangs :) However, I was able to capture the case where the LED was not blinking: The IIR register says 0xc6 (= line status error). That is okay. At the same time LSR register says 0xe0. This is not okay. It means that there is some kind of error and at least one error bit is set in this register which is not the case. Also those bits are cleared on read which does not happen here. And we loop forever so the LED does blink anymore. OK The RX-count register says that it is empty which sense because bit 0 is not set (in LSR). However I can read multiple times from the RX FIFO until I get the unhandled bus access error which usually happens right away if the empty FIFO is read on omap3 HW. In the last test I mange to read 91 times before the crash. I hoped that this FIFO read would make the interrupt go away but it did not. The HW seems to be in a strange state. It might be either the errata or something else. I even took the resume routine from omap-serial in case I did something wrong. In my last test it worked for 10minues before the interrupt storm came. This is probably the same thing I see on the omap-serial driver where I got from pstore: [ 32.659271] random: nonblocking pool is initialized [ 212.170623] NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper:0] So I *guess* the interrupt routine is looping. This is problem one, no idea what is going on (the register status captured on 8250-omap makes no sense). See recent commit cc824534d4fe, and try commenting out the check for HWMOD_FORCE_MSTANDBY in omap_hwmod.c so _reconfigure_io_chain() is always called. If that changes something, we at least have some idea. It could be also the wake-up interrupt looping. So you may also want to try adding some printks (pstore only) into omap_prcm_irq_handler() and omap3xxx_prm_clear_mod_irqs() as that's handling the wake-up event interrupts. Problem two, where the UART does not wakeup: What I observed is that sometimes the UART does not wake up properly i.e. it does not write anything on the console, even where it should. I can't tell if the read is working properly, the write does not. From my capture I see that the resume routine was running and the register should have been written. That means the UART should be up and running but nothing happens. This seems also be hinting to something needing _reconfigure_io_chain() to be called along the lines of commit cc824534d4fe. It often works again after the system comes out of resume again (i.e. RPM suspens and resumes the UART). So it is okay on the next wakeup. Or the wakeup after next. From the script: | while ((1)) | do | | echo -n 409-chars /dev/ttyUSB0 | | sleep 1 | a=$(date) | echo -e \n#$a /dev/ttyUSB0 | echo $a | sleep 13; | done I see that sometimes one or two sequential timestamps are missing. And the it continues like nothing happened. OK. At least it's starting to now sound that the bugs are pretty much the same with 8250 and serial-omap :) 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 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Reichel s...@kernel.org [140901 20:06]: Hi, On Mon, Sep 01, 2014 at 07:47:53PM +0200, Sebastian Andrzej Siewior wrote: On 08/29/2014 06:12 PM, Tony Lindgren wrote: Looks like the paste bug is there for sure, doing off idle and pasting 240 characters to the console can hang the UART RX after few attempts, and pasting 16 charactes won't show up at all if the system is idling. So you may want to play with that too a bit :) One character wakes it up. After that you can send 16, 64 and you see them. Right away. No delay. If you send a lot data in one-go it takes approx 152 characters until the first one is displayed properly at 115200,8N1. That is approx 13ms. Could it take that long to get up and be ready? I noticed the same behaviour when I tested the runtime PM stuff on my N900 with the existing serial-omap driver and I also assumed, that the chip needs that long to get up. OK yeah I've confirmed that serial-omap also won't do anything with the pasted data until woken up. It takes some time to get things powered up again, there's nothing we can do beyond having the autoidle disabled by default. Comparing it with serial-omap I see the same thing: I takes approx the same amount of data until the first one is displayed. After a lot of long writes which wake the chip up from idle I manage to freeze both, the serial-omap driver and mine driver. Hmm I have not seen the RX hang with serial-omap when pasting data to the console to wake it up. One thing that is probably a dumb idea is that printk in omap_8250_mdr1_errataset(). Would it be possible that when I hit a printk in the resume path that I may deadlock and box will freeze? I guess yeah. You may want to use pstore as console to debug that. You need to use this patch to prevent pstore from hanging: https://lkml.org/lkml/2013/4/9/831 Then enable: CONFIG_PSTORE=y CONFIG_PSTORE_CONSOLE=y CONFIG_PSTORE_RAM=y CONFIG_FUNCTION_TRACER=y CONFIG_DEBUG_FS=y CONFIG_PSTORE_FTRACE=y Then at kernel cmdline, specify something like this: memmap=2M$0x8800 ramoops.mem_address=0x8800 ramoops.mem_size=0x20 ramoops.record_size=0x4 And leave out console=ttyS line and spin up a getty on the serial line. After booting, you should just need to do: # mount -t pstore - /sys/fs/pstore And then you see dmesg in /sys/fs/pstore. To debug hangs, set up the PMIC watchdog and do not set up omap watchdog, and you should see the last dmesg in /sys/fs/pstore after a warm reset. 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 15/15] tty: serial: 8250: omap: add dma support
On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote: Comparing it with serial-omap I see the same thing: I takes approx the same amount of data until the first one is displayed. After a lot of long writes which wake the chip up from idle I manage to freeze both, the serial-omap driver and mine driver. So after some testing: - it happens with omap-serial as well. Especially after disabling the LED trigger for both LEDs. - it seemed that disabling the MDR1 check whether or not we lost context made the problem appear less often but it was a trick. Even with restoring the context each time I see the same problem. - it seems to be easier to trigger with the LED trigger switched off. However sometimes it works for 10 minutes, sometimes it triggers after one. - I see to face two kind of deaths: - the LED still goes on and off and the uart just does not respond even if I tell the button print something on the screen (the button also changes the frequency of the LED so I know that the button is doing something). Also from dumping the content of /proc/interrupts it seems that a wake up is made, the uart should have restored the registers. - one where the system is dead and the LED does not blink anymore. Also my button is dead. - disabling DMA makes the problem not go away. - mdelay(25) in omap8250_lost_context() is long enough to drop the 403 bytes I send in my testcase. That means I see only good characters. With this the box remained alive for 2h. However the uart died anyway. Regards, Tony 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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140902 11:40]: On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote: Comparing it with serial-omap I see the same thing: I takes approx the same amount of data until the first one is displayed. After a lot of long writes which wake the chip up from idle I manage to freeze both, the serial-omap driver and mine driver. So after some testing: - it happens with omap-serial as well. Especially after disabling the LED trigger for both LEDs. - it seemed that disabling the MDR1 check whether or not we lost context made the problem appear less often but it was a trick. Even with restoring the context each time I see the same problem. - it seems to be easier to trigger with the LED trigger switched off. However sometimes it works for 10 minutes, sometimes it triggers after one. - I see to face two kind of deaths: - the LED still goes on and off and the uart just does not respond even if I tell the button print something on the screen (the button also changes the frequency of the LED so I know that the button is doing something). Also from dumping the content of /proc/interrupts it seems that a wake up is made, the uart should have restored the registers. OK yeah this is the case I was seeing too. So do you just set the LED triggers to none in sysfs to make it easier to reproduce? - one where the system is dead and the LED does not blink anymore. Also my button is dead. This I don't think I've seen. This could also be the errata issue on your earlier rev beagleboard-xm with off-idle. - disabling DMA makes the problem not go away. OK - mdelay(25) in omap8250_lost_context() is long enough to drop the 403 bytes I send in my testcase. That means I see only good characters. With this the box remained alive for 2h. However the uart died anyway. I wonder if doing some TX on the uart restores it? So maybe try $ while [ 1 ]; do date; sleep 10 done To have it occasionally print something in the background. 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 15/15] tty: serial: 8250: omap: add dma support
On Tue, Sep 02, 2014 at 01:15:37PM -0700, Tony Lindgren wrote: * Sebastian Andrzej Siewior bige...@linutronix.de [140902 11:40]: On 09/01/2014 07:47 PM, Sebastian Andrzej Siewior wrote: Comparing it with serial-omap I see the same thing: I takes approx the same amount of data until the first one is displayed. After a lot of long writes which wake the chip up from idle I manage to freeze both, the serial-omap driver and mine driver. So after some testing: - it happens with omap-serial as well. Especially after disabling the LED trigger for both LEDs. - it seemed that disabling the MDR1 check whether or not we lost context made the problem appear less often but it was a trick. Even with restoring the context each time I see the same problem. - it seems to be easier to trigger with the LED trigger switched off. However sometimes it works for 10 minutes, sometimes it triggers after one. - I see to face two kind of deaths: - the LED still goes on and off and the uart just does not respond even if I tell the button print something on the screen (the button also changes the frequency of the LED so I know that the button is doing something). Also from dumping the content of /proc/interrupts it seems that a wake up is made, the uart should have restored the registers. OK yeah this is the case I was seeing too. So do you just set the LED triggers to none in sysfs to make it easier to reproduce? - one where the system is dead and the LED does not blink anymore. Also my button is dead. This I don't think I've seen. This could also be the errata issue on your earlier rev beagleboard-xm with off-idle. - disabling DMA makes the problem not go away. OK - mdelay(25) in omap8250_lost_context() is long enough to drop the 403 bytes I send in my testcase. That means I see only good characters. With this the box remained alive for 2h. However the uart died anyway. I wonder if doing some TX on the uart restores it? So maybe try $ while [ 1 ]; do date; sleep 10 done To have it occasionally print something in the background. If there is a way to detect the hangup you may try to recover by resetting the serial device using omap_hwmod_reset(). -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
On 08/29/2014 06:12 PM, Tony Lindgren wrote: Looks like the paste bug is there for sure, doing off idle and pasting 240 characters to the console can hang the UART RX after few attempts, and pasting 16 charactes won't show up at all if the system is idling. So you may want to play with that too a bit :) One character wakes it up. After that you can send 16, 64 and you see them. Right away. No delay. If you send a lot data in one-go it takes approx 152 characters until the first one is displayed properly at 115200,8N1. That is approx 13ms. Could it take that long to get up and be ready? Comparing it with serial-omap I see the same thing: I takes approx the same amount of data until the first one is displayed. After a lot of long writes which wake the chip up from idle I manage to freeze both, the serial-omap driver and mine driver. One thing that is probably a dumb idea is that printk in omap_8250_mdr1_errataset(). Would it be possible that when I hit a printk in the resume path that I may deadlock and box will freeze? Regards, Tony 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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
Hi, On Mon, Sep 01, 2014 at 07:47:53PM +0200, Sebastian Andrzej Siewior wrote: On 08/29/2014 06:12 PM, Tony Lindgren wrote: Looks like the paste bug is there for sure, doing off idle and pasting 240 characters to the console can hang the UART RX after few attempts, and pasting 16 charactes won't show up at all if the system is idling. So you may want to play with that too a bit :) One character wakes it up. After that you can send 16, 64 and you see them. Right away. No delay. If you send a lot data in one-go it takes approx 152 characters until the first one is displayed properly at 115200,8N1. That is approx 13ms. Could it take that long to get up and be ready? I noticed the same behaviour when I tested the runtime PM stuff on my N900 with the existing serial-omap driver and I also assumed, that the chip needs that long to get up. Comparing it with serial-omap I see the same thing: I takes approx the same amount of data until the first one is displayed. After a lot of long writes which wake the chip up from idle I manage to freeze both, the serial-omap driver and mine driver. One thing that is probably a dumb idea is that printk in omap_8250_mdr1_errataset(). Would it be possible that when I hit a printk in the resume path that I may deadlock and box will freeze? -- Sebastian signature.asc Description: Digital signature
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
On Fri, Aug 29, 2014 at 11:32:36AM +0200, Sebastian Andrzej Siewior wrote: On 08/29/2014 12:54 AM, Tony Lindgren wrote: * Sebastian Andrzej Siewior bige...@linutronix.de [140828 12:37]: On 08/28/2014 06:46 PM, Tony Lindgren wrote: Sounds like there should be some way to clear that state.. I wonder if omap-serial.c had something before it's DMA support was removed? Its DMA was removed? Like there was DMA support? Yeah see commit 494574304711a86e7dd5fd3ebbc3b7024994... Interesting. I've been browsing that file and checking other trees and never noticed that it was there at some point. I only saw the pieces which looked it was there. it was known to be broken and unused. There was no way to even enable that code. -- balbi signature.asc Description: Digital signature
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140829 02:32]: On 08/29/2014 12:54 AM, Tony Lindgren wrote: OK thanks, I'm seeing the same issue as you. And the idlest registers don't show any blockers. Looking at the errata docs, seems like Usage Note 2.7 in sprz318f.pdf says: Details When configured for DMA operations using smartidle mode (SYSC[4:3].IDLEMODE = 0x2), the UART module will not acknowledge incoming idle requests. As a consequence, it can prevent L4 from going to idle. When there are additional expected transfers, the UART should be placed in force-idle mode. Ehm. So I haven't found an errata document for omap3630, there is nothing like that in that one I have for am335x or dra7. The document you mentioned is for AM3715. Interesting… Yes I would not be suprised if that same bug is in all of them though.. So I've added also Paul to Cc, he may have better suggestions for the hwmod flags to use. The experimental patch below seems to allow idling for me, care to give it a try? Yep, this one works. And I see DMA transfers (for RX side) after the core hit idle so it seems to look good :) OK great :) Looks like the paste bug is there for sure, doing off idle and pasting 240 characters to the console can hang the UART RX after few attempts, and pasting 16 charactes won't show up at all if the system is idling. So you may want to play with that too a bit :) 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 15/15] tty: serial: 8250: omap: add dma support
On 08/29/2014 06:12 PM, Tony Lindgren wrote: Looks like the paste bug is there for sure, doing off idle and pasting 240 characters to the console can hang the UART RX after few attempts, and pasting 16 charactes won't show up at all if the system is idling. So you may want to play with that too a bit :) Oh. perfect. Please note that we the threshold moved from 16 to 48. However I see that usually we lose a lot of characters before the uart wakes up and does its job. Usually I see a couple characters but sometimes is see broken characters which suggests that the clock was not (yet) perfect. And I managed not get get it woken once. So let me look at this once I am through with the review responses… Regards, Tony 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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Tony Lindgren | 2014-08-27 13:23:14 [-0700]: which means I just enable DMA mode in UART and disable it. No DMA operations were performed. With this change I see a lost character now and then which means the UART-IP goes into off and loses its context. Good. However I don't see core off anymore. This looks like a bug beyond my responsibilities :) OK, that sounds like a bug still lurking around somewhere. The core domain won't hit idle if there are any hardware pieces blocking. Yes. I added code to cancel and start DMA transfers in runtime suspend callbacks. Do you mean just the OMAP_UART_SCR_DMAMODE_CTL related code, or also the dmaengine calls? dmaengine calls are unused because up.dma is not assigned. It is basically like you wouldn't have the dma properties in the devicetree. And while in that non-DMA mode I just set and unset the DMAMODE_CTL + DMAMODE_1 bits in the SCR register. Nothing else. Based on some testing I just did, DMAMODE_CTL does not make the difference. DMAMODE_CTL + DMAMODE_1 does. However core-off with DMA won't work. I think we could document this in the binding document. What do you think? There should not be such a limitation though. Maybe dump out the values of cm_idlest_per and cm_idlest1_core for working and failing off idle cases and see what the difference is? I can't follow here. This is the working case: usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:109,RET:22,INA:71,ON:203,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:137,RET:126,INA:0,ON:264,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:383,RET:861,INA:0,ON:1245,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:311,RET:889,INA:44,ON:1245,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:311,RET:889,INA:44,ON:1245,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm-usbhost_pwrdm (0) sgx_clkdm-sgx_pwrdm (0) per_clkdm-per_pwrdm (15) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) d2d_clkdm-core_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) core_l4_clkdm-core_pwrdm (20) core_l3_clkdm-core_pwrdm (1) neon_clkdm-neon_pwrdm (0) non-working: usbhost_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 sgx_pwrdm (OFF),OFF:1,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 core_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0 per_pwrdm (ON),OFF:0,RET:0,INA:0,ON:1,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 dss_pwrdm (ON),OFF:253,RET:159,INA:0,ON:413,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 cam_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 neon_pwrdm (ON),OFF:135,RET:242,INA:35,ON:413,RET-LOGIC-OFF:0 mpu_pwrdm (ON),OFF:135,RET:242,INA:35,ON:413,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0 iva2_pwrdm (OFF),OFF:1,RET:1,INA:0,ON:2,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0,RET-MEMBANK3-OFF:0,RET-MEMBANK4-OFF:0 usbhost_clkdm-usbhost_pwrdm (0) sgx_clkdm-sgx_pwrdm (0) per_clkdm-per_pwrdm (15) cam_clkdm-cam_pwrdm (0) dss_clkdm-dss_pwrdm (1) d2d_clkdm-core_pwrdm (0) iva2_clkdm-iva2_pwrdm (0) mpu_clkdm-mpu_pwrdm (0) core_l4_clkdm-core_pwrdm (21) core_l3_clkdm-core_pwrdm (1) neon_clkdm-neon_pwrdm (0) so per_pwrdm and core_pwrdm remain on and I guess the former is where the UART sits. It could be the either the dma or the uart hardware blocking. I guess it could be also an issue with runtime pm use somewhere. So I just toggle the two DMA bits in SCR and the UART seems to block since the DMA hw is not involved. Reading SCR back says that those bits are not set. To use DMA you don't have to enable it in SCR register you can also use the FCR register. The manual says that you can only write this DMA enable bit in the FCR register if the baud clock is not running. And guess what: same thing: I only *toggle* the DMA enable bit here (it remains 0 later) and the core won't hit idle. Same effect if I toggle this bit while the baud clock is running (the manual says that this bit can only be written if the baud clock is not running). Seems like the UART is following its own specification and it remains blocking once the DMA was enabled. It would be nice if someone from the UART-IP team could ACK this. Bah. Does it make sense to use runtime-PM if we can't hit core-off? I'm thinking to add a printk once dma is enabled says that runtime-pm is switched off. Tony 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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
On 08/28/2014 06:46 PM, Tony Lindgren wrote: To use DMA you don't have to enable it in SCR register you can also use the FCR register. The manual says that you can only write this DMA enable bit in the FCR register if the baud clock is not running. And guess what: same thing: I only *toggle* the DMA enable bit here (it remains 0 later) and the core won't hit idle. Same effect if I toggle this bit while the baud clock is running (the manual says that this bit can only be written if the baud clock is not running). Seems like the UART is following its own specification and it remains blocking once the DMA was enabled. It would be nice if someone from the UART-IP team could ACK this. Sounds like there should be some way to clear that state.. I wonder if omap-serial.c had something before it's DMA support was removed? Its DMA was removed? Like there was DMA support? I'd assume when the UART is powered down by runtime PM it's state is completetely reset and we could restore the non-DMA state? I tried that by canceling the RX-DMA request and removing the DMA-enable bits from UART but it didn't help. Then I noticed that once that DMA en bit is set, the UART won't do any idle. Maybe post your current patches and a test patch to try to toggle the DMA on and off? Oh. I pushed my dirty tree to git://git.breakpoint.cc/bigeasy/linux.git uart_v8_wip The top most commit does not setup dma at all and adds commented out code how to enable DMA via SCR or FCR register. With this I hit core-off. Once _one_ of the modes are enabled, it doesn't work anymore. I will try to address review comments tomorrow and hopefully post a v8 based on -rc2. The same goes for your patch (which I will try tomorrow). Bah. Does it make sense to use runtime-PM if we can't hit core-off? I'm thinking to add a printk once dma is enabled says that runtime-pm is switched off. Well if we can't find a way to unset the DMA registers in the UART, how about only enable it if a kernel cmdline option is specified? Hmmm. So removing DMA properties from DT is not an option? Currently I added a message that DMA might forbid low power mode so people might remove dma-names from DT (or assign ) and DMA is off. However if this is no good, then I guess I could add kernel module which enables DMA. We do have runtime PM working without it, and the serial console super important for any kind of debugging no matter what idle mode the SoC hits.. So let's not break that. Yeah, I know. I've been debugging while I broke something which means uart wasn't working :) Regards, Tony 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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140828 12:37]:
On 08/28/2014 06:46 PM, Tony Lindgren wrote:
Sounds like there should be some way to clear that state.. I wonder
if omap-serial.c had something before it's DMA support was removed?
Its DMA was removed? Like there was DMA support?
Yeah see commit 494574304711a86e7dd5fd3ebbc3b7024994...
I'd assume when the UART is powered down by runtime PM it's state
is completetely reset and we could restore the non-DMA state?
I tried that by canceling the RX-DMA request and removing the DMA-enable
bits from UART but it didn't help. Then I noticed that once that DMA en
bit is set, the UART won't do any idle.
Maybe post your current patches and a test patch to try to toggle
the DMA on and off?
Oh. I pushed my dirty tree to
git://git.breakpoint.cc/bigeasy/linux.git uart_v8_wip
The top most commit does not setup dma at all and adds commented out
code how to enable DMA via SCR or FCR register. With this I hit
core-off. Once _one_ of the modes are enabled, it doesn't work anymore.
I will try to address review comments tomorrow and hopefully post a v8
based on -rc2. The same goes for your patch (which I will try tomorrow).
OK thanks, I'm seeing the same issue as you. And the idlest registers
don't show any blockers. Looking at the errata docs, seems like
Usage Note 2.7 in sprz318f.pdf says:
Details When configured for DMA operations using smartidle mode
(SYSC[4:3].IDLEMODE =
0x2), the UART module will not acknowledge incoming idle requests. As a
consequence,
it can prevent L4 from going to idle.
When there are additional expected transfers, the UART should be placed in
force-idle
mode.
So I've added also Paul to Cc, he may have better suggestions for the
hwmod flags to use. The experimental patch below seems to allow idling
for me, care to give it a try?
Regards,
Tony
8
From: Tony Lindgren t...@atomide.com
Date: Thu, 28 Aug 2014 15:41:21 -0700
Subject: [PATCH] ARM: OMAP3: Use force-idle for UARTs because of DMA errata
In sprz318f.pdf Usage Note 2.7 says that UARTs cannot acknowledge
idle requests in smartidle mode when configure for DMA operations.
This prevents L4 from going idle. Sol et's use force-idle mode
instead.
--- a/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
+++ b/arch/arm/mach-omap2/omap_hwmod_3xxx_data.c
@@ -490,7 +490,9 @@ static struct omap_hwmod omap3xxx_uart1_hwmod = {
.mpu_irqs = omap2_uart1_mpu_irqs,
.sdma_reqs = omap2_uart1_sdma_reqs,
.main_clk = uart1_fck,
- .flags = DEBUG_TI81XXUART1_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+ .flags = DEBUG_TI81XXUART1_FLAGS |
+ HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+ HWMOD_FORCE_MSTANDBY,
.prcm = {
.omap2 = {
.module_offs = CORE_MOD,
@@ -509,7 +511,9 @@ static struct omap_hwmod omap3xxx_uart2_hwmod = {
.mpu_irqs = omap2_uart2_mpu_irqs,
.sdma_reqs = omap2_uart2_sdma_reqs,
.main_clk = uart2_fck,
- .flags = DEBUG_TI81XXUART2_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+ .flags = DEBUG_TI81XXUART2_FLAGS |
+ HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+ HWMOD_FORCE_MSTANDBY,
.prcm = {
.omap2 = {
.module_offs = CORE_MOD,
@@ -529,7 +533,8 @@ static struct omap_hwmod omap3xxx_uart3_hwmod = {
.sdma_reqs = omap2_uart3_sdma_reqs,
.main_clk = uart3_fck,
.flags = DEBUG_OMAP3UART3_FLAGS | DEBUG_TI81XXUART3_FLAGS |
- HWMOD_SWSUP_SIDLE_ACT,
+ HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+ HWMOD_FORCE_MSTANDBY,
.prcm = {
.omap2 = {
.module_offs = OMAP3430_PER_MOD,
@@ -559,7 +564,9 @@ static struct omap_hwmod omap36xx_uart4_hwmod = {
.mpu_irqs = uart4_mpu_irqs,
.sdma_reqs = uart4_sdma_reqs,
.main_clk = uart4_fck,
- .flags = DEBUG_OMAP3UART4_FLAGS | HWMOD_SWSUP_SIDLE_ACT,
+ .flags = DEBUG_OMAP3UART4_FLAGS |
+ HWMOD_NO_OCP_AUTOIDLE | HWMOD_SWSUP_SIDLE |
+ HWMOD_FORCE_MSTANDBY,
.prcm = {
.omap2 = {
.module_offs = OMAP3430_PER_MOD,
--
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 15/15] tty: serial: 8250: omap: add dma support
On 08/21/2014 08:44 PM, Tony Lindgren wrote:
Also, with DMA enabled, looks like omap deeper idle states are
blocked as the DMA stays reserved. After I commented out the
DMA info for my console UART, PM started working.
Hmm. This would explain something. This would mean that I should cancel
the RX DMA transfer in the PM-suspend routine. Let me see how that
works.
OK and if the DMA works with PM, then I don't see why we would not
want to have it automatically enabled.
I re-did that part where the registers are restored. Mostly for that
reason to use function in runtime_resume() as in set_termios(). I think
that is cute :) _And_ if somebody changes here something and breaks it
then it doesn't work with and without runtime-pm. It looks like the
omap-serial doesn't restore the XON1 XOFF1 registers.
While at it I made sure that it works as good as I could and that means:
core_pwrdm
(ON),OFF:182,RET:21,INA:131,ON:335,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
The core off part with DMA looks like a no no:
I #if 0 the block in where it assigned up.dma. With this I hit
core-off. Step two was
|static void omap8250_update_scr(struct uart_8250_port *up,
| struct omap8250_priv *priv)
|{
|serial_out(up, UART_OMAP_SCR, priv-scr | OMAP_UART_SCR_DMAMODE_CTL);
|serial_out(up, UART_OMAP_SCR, priv-scr | OMAP_UART_SCR_DMAMODE_CTL |
OMAP_UART_SCR_DMAMODE_1);
|serial_out(up, UART_OMAP_SCR, priv-scr | |OMAP_UART_SCR_DMAMODE_CTL);
|serial_out(up, UART_OMAP_SCR, priv-scr);
|}
which means I just enable DMA mode in UART and disable it. No DMA
operations were performed.
With this change I see a lost character now and then which means the
UART-IP goes into off and loses its context. Good. However I don't see
core off anymore. This looks like a bug beyond my responsibilities :)
I added code to cancel and start DMA transfers in runtime suspend
callbacks.
However core-off with DMA won't work. I think we could document this in
the binding document. What do you think?
BTW, looks like the ports move around now though. If set a port
to disabled with status = disabled; in the .dts file, you'll get
a different console which does not happen with omap-serial I believe.
You a right. I fixed it in the 8250-core code.
Regards,
Tony
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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140827 12:54]:
On 08/21/2014 08:44 PM, Tony Lindgren wrote:
Also, with DMA enabled, looks like omap deeper idle states are
blocked as the DMA stays reserved. After I commented out the
DMA info for my console UART, PM started working.
Hmm. This would explain something. This would mean that I should cancel
the RX DMA transfer in the PM-suspend routine. Let me see how that
works.
OK and if the DMA works with PM, then I don't see why we would not
want to have it automatically enabled.
I re-did that part where the registers are restored. Mostly for that
reason to use function in runtime_resume() as in set_termios(). I think
that is cute :) _And_ if somebody changes here something and breaks it
then it doesn't work with and without runtime-pm. It looks like the
omap-serial doesn't restore the XON1 XOFF1 registers.
While at it I made sure that it works as good as I could and that means:
core_pwrdm
(ON),OFF:182,RET:21,INA:131,ON:335,RET-LOGIC-OFF:0,RET-MEMBANK1-OFF:0,RET-MEMBANK2-OFF:0
Hey that's great, that's the ultimate torture test here!
There's nothing like rebooting the system every time you hit
idle and still have drivers working :)
The core off part with DMA looks like a no no:
I #if 0 the block in where it assigned up.dma. With this I hit
core-off. Step two was
|static void omap8250_update_scr(struct uart_8250_port *up,
| struct omap8250_priv *priv)
|{
|serial_out(up, UART_OMAP_SCR, priv-scr | OMAP_UART_SCR_DMAMODE_CTL);
|serial_out(up, UART_OMAP_SCR, priv-scr | OMAP_UART_SCR_DMAMODE_CTL |
OMAP_UART_SCR_DMAMODE_1);
|serial_out(up, UART_OMAP_SCR, priv-scr | |OMAP_UART_SCR_DMAMODE_CTL);
|serial_out(up, UART_OMAP_SCR, priv-scr);
|}
which means I just enable DMA mode in UART and disable it. No DMA
operations were performed.
With this change I see a lost character now and then which means the
UART-IP goes into off and loses its context. Good. However I don't see
core off anymore. This looks like a bug beyond my responsibilities :)
OK, that sounds like a bug still lurking around somewhere. The core
domain won't hit idle if there are any hardware pieces blocking.
I added code to cancel and start DMA transfers in runtime suspend
callbacks.
Do you mean just the OMAP_UART_SCR_DMAMODE_CTL related code, or
also the dmaengine calls?
However core-off with DMA won't work. I think we could document this in
the binding document. What do you think?
There should not be such a limitation though. Maybe dump out the values
of cm_idlest_per and cm_idlest1_core for working and failing off idle
cases and see what the difference is?
It could be the either the dma or the uart hardware blocking. I guess
it could be also an issue with runtime pm use somewhere.
BTW, looks like the ports move around now though. If set a port
to disabled with status = disabled; in the .dts file, you'll get
a different console which does not happen with omap-serial I believe.
You a right. I fixed it in the 8250-core code.
OK thanks.
Tony
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
On 08/15/2014 11:02 PM, Tony Lindgren wrote:
* Sebastian Andrzej Siewior bige...@linutronix.de [140815 11:13]:
+#ifdef CONFIG_SERIAL_8250_DMA
+if (pdev-dev.of_node) {
+/*
+ * Oh DMA support. If there are no DMA properties in the DT then
+ * we will fall back to a generic DMA channel which does not
+ * really work here. To ensure that we do not get a generic DMA
+ * channel assigned, we have the the_no_dma_filter_fn() here.
+ * To avoid failed to request DMA messages we check for DMA
+ * properties in DT.
+ */
+ret = of_property_count_strings(pdev-dev.of_node, dma-names);
+if (ret == 2) {
+up.dma = priv-omap8250_dma;
+priv-omap8250_dma.fn = the_no_dma_filter_fn;
+priv-omap8250_dma.rx_size = RX_TRIGGER;
+priv-omap8250_dma.rxconf.src_maxburst = RX_TRIGGER;
+priv-omap8250_dma.txconf.dst_maxburst = TX_TRIGGER;
+
+if (of_machine_is_compatible(ti,am33xx))
+up.bugs |= UART_BUG_DMATX;
+}
+}
+#endif
Hmm I wonder if there's a more generic solution to this?
To what exactly? The trigger level, the TX-bug or using DMA in the
first place?
It would be also nice to be able to specify the use of DMA from
the board specific .dts file.
Really? I don't see this requirement for MMC for instance. However you
still could provide an empty dma-names property in your board .dts
file if you do not want use DMA. Would this work?
Also, with DMA enabled, looks like omap deeper idle states are
blocked as the DMA stays reserved. After I commented out the
DMA info for my console UART, PM started working.
Hmm. This would explain something. This would mean that I should cancel
the RX DMA transfer in the PM-suspend routine. Let me see how that
works.
Regards,
Tony
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: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140821 01:37]:
On 08/15/2014 11:02 PM, Tony Lindgren wrote:
* Sebastian Andrzej Siewior bige...@linutronix.de [140815 11:13]:
+#ifdef CONFIG_SERIAL_8250_DMA
+ if (pdev-dev.of_node) {
+ /*
+ * Oh DMA support. If there are no DMA properties in the DT then
+ * we will fall back to a generic DMA channel which does not
+ * really work here. To ensure that we do not get a generic DMA
+ * channel assigned, we have the the_no_dma_filter_fn() here.
+ * To avoid failed to request DMA messages we check for DMA
+ * properties in DT.
+ */
+ ret = of_property_count_strings(pdev-dev.of_node, dma-names);
+ if (ret == 2) {
+ up.dma = priv-omap8250_dma;
+ priv-omap8250_dma.fn = the_no_dma_filter_fn;
+ priv-omap8250_dma.rx_size = RX_TRIGGER;
+ priv-omap8250_dma.rxconf.src_maxburst = RX_TRIGGER;
+ priv-omap8250_dma.txconf.dst_maxburst = TX_TRIGGER;
+
+ if (of_machine_is_compatible(ti,am33xx))
+ up.bugs |= UART_BUG_DMATX;
+ }
+ }
+#endif
Hmm I wonder if there's a more generic solution to this?
To what exactly? The trigger level, the TX-bug or using DMA in the
first place?
Oh sorry, I meant to having to do of_property_count_strings to
figure out if it's correct or not.
It would be also nice to be able to specify the use of DMA from
the board specific .dts file.
Really? I don't see this requirement for MMC for instance. However you
still could provide an empty dma-names property in your board .dts
file if you do not want use DMA. Would this work?
OK yeah that works. And that's needed mostly because of the issue
below.
Also, with DMA enabled, looks like omap deeper idle states are
blocked as the DMA stays reserved. After I commented out the
DMA info for my console UART, PM started working.
Hmm. This would explain something. This would mean that I should cancel
the RX DMA transfer in the PM-suspend routine. Let me see how that
works.
OK and if the DMA works with PM, then I don't see why we would not
want to have it automatically enabled.
BTW, looks like the ports move around now though. If set a port
to disabled with status = disabled; in the .dts file, you'll get
a different console which does not happen with omap-serial I believe.
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 15/15] tty: serial: 8250: omap: add dma support
This patch adds the required pieces to 8250-OMAP UART driver for DMA
support. The TX burst size is set to 1 so we can send an arbitrary
amount of bytes.
The RX burst is currently set to 48 which means we receive an DMA
interrupt every 48 bytes and have to reprogram everything. Less bytes in
the RX-FIFO mean that no DMA transfer will happen and the UART will send a
RX-timeout _or_ RDI event at which point the FIFO will be manually purged.
There is a workaround for TX-DMA on AM33xx where we put the first byte
into the FIFO to kick start the DMA process. Haven't seen this problem on
OMAP3 (beagle bone) or DRA7xx.
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/tty/serial/8250/8250_omap.c | 79 +++--
1 file changed, 76 insertions(+), 3 deletions(-)
diff --git a/drivers/tty/serial/8250/8250_omap.c
b/drivers/tty/serial/8250/8250_omap.c
index 368e9d8..dfd2ddd 100644
--- a/drivers/tty/serial/8250/8250_omap.c
+++ b/drivers/tty/serial/8250/8250_omap.c
@@ -31,10 +31,16 @@
#define UART_ERRATA_i202_MDR1_ACCESS (1 0)
#define OMAP_UART_WER_HAS_TX_WAKEUP(1 1)
+#define OMAP_UART_FCR_RX_TRIG 6
+#define OMAP_UART_FCR_TX_TRIG 4
+
/* SCR register bitmasks */
#define OMAP_UART_SCR_RX_TRIG_GRANU1_MASK (1 7)
#define OMAP_UART_SCR_TX_TRIG_GRANU1_MASK (1 6)
#define OMAP_UART_SCR_TX_EMPTY (1 3)
+#define OMAP_UART_SCR_DMAMODE_MASK (3 1)
+#define OMAP_UART_SCR_DMAMODE_1(1 1)
+#define OMAP_UART_SCR_DMAMODE_CTL (1 0)
/* MVR register bitmasks */
#define OMAP_UART_MVR_SCHEME_SHIFT 30
@@ -45,6 +51,12 @@
#define OMAP_UART_MVR_MAJ_SHIFT8
#define OMAP_UART_MVR_MIN_MASK 0x3f
+#define UART_TI752_TLR_TX 0
+#define UART_TI752_TLR_RX 4
+
+#define TRIGGER_TLR_MASK(x)((x 0x3c) 2)
+#define TRIGGER_FCR_MASK(x)(x 3)
+
/* Enable XON/XOFF flow control on output */
#define OMAP_UART_SW_TX0x08
/* Enable XON/XOFF flow control on input */
@@ -82,6 +94,7 @@ struct omap8250_priv {
u32 calc_latency;
struct pm_qos_request pm_qos_request;
struct work_struct qos_work;
+ struct uart_8250_dma omap8250_dma;
};
static u32 uart_read(struct uart_8250_port *up, u32 reg)
@@ -162,6 +175,20 @@ static void omap_8250_get_divisor(struct uart_port *port,
unsigned int baud,
}
}
+static void omap8250_update_scr(struct uart_8250_port *up,
+ struct omap8250_priv *priv)
+{
+ /*
+* The manual recommends not to enable the DMA mode selector in the SCR
+* (instead of the FCR) register _and_ selecting the DMA mode as one
+* register write because this may lead to malfunction.
+*/
+ if (priv-scr OMAP_UART_SCR_DMAMODE_MASK)
+ serial_out(up, UART_OMAP_SCR,
+ priv-scr ~OMAP_UART_SCR_DMAMODE_MASK);
+ serial_out(up, UART_OMAP_SCR, priv-scr);
+}
+
/*
* OMAP can use CLK / (16 or 13) / div for baud rate. And then we have have
* some differences in how we want to handle flow control.
@@ -286,6 +313,9 @@ static void omap_8250_set_termios(struct uart_port *port,
serial_out(up, UART_TI752_TLR,
TRIGGER_TLR_MASK(TX_TRIGGER) UART_TI752_TLR_TX |
TRIGGER_TLR_MASK(RX_TRIGGER) UART_TI752_TLR_RX);
+ if (up-dma)
+ priv-scr |= OMAP_UART_SCR_DMAMODE_1 |
+ OMAP_UART_SCR_DMAMODE_CTL;
/*
* We enable TRIG_GRANU for RX and TX and additionaly we set
* SCR_TX_EMPTY bit. The result is the following:
@@ -294,6 +324,14 @@ static void omap_8250_set_termios(struct uart_port *port,
* once the UART decides that there no new bytes arriving.
* - Once THRE is enabled, the interrupt will be fired once the FIFO is
* empty - the trigger level is ignored here.
+*
+* Once DMA is enabled:
+* - UART will assert the TX DMA line once there is room for TX_TRIGGER
+* bytes in the TX FIFO. On each assert the DMA engine will move
+* TX_TRIGGER bytes into the FIFO.
+* - UART will assert the RX DMA line once there are RX_TRIGGER bytes in
+* the FIFO and move RX_TRIGGER bytes.
+* This is because treshold and trigger values are the same.
*/
priv-fcr = UART_FCR_ENABLE_FIFO;
priv-fcr |= TRIGGER_FCR_MASK(TX_TRIGGER) OMAP_UART_FCR_TX_TRIG;
@@ -302,7 +340,7 @@ static void omap_8250_set_termios(struct uart_port *port,
serial_out(up, UART_FCR, priv-fcr);
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
- serial_out(up, UART_OMAP_SCR, priv-scr);
+ omap8250_update_scr(up, priv);
/* Reset UART_MCR_TCRTLR: this must be done with the EFR_ECB bit set */
serial_out(up, UART_LCR, UART_LCR_CONF_MODE_A);
@@ -525,6 +563,9 @@ static int
Re: [PATCH 15/15] tty: serial: 8250: omap: add dma support
* Sebastian Andrzej Siewior bige...@linutronix.de [140815 11:13]:
+#ifdef CONFIG_SERIAL_8250_DMA
+ if (pdev-dev.of_node) {
+ /*
+ * Oh DMA support. If there are no DMA properties in the DT then
+ * we will fall back to a generic DMA channel which does not
+ * really work here. To ensure that we do not get a generic DMA
+ * channel assigned, we have the the_no_dma_filter_fn() here.
+ * To avoid failed to request DMA messages we check for DMA
+ * properties in DT.
+ */
+ ret = of_property_count_strings(pdev-dev.of_node, dma-names);
+ if (ret == 2) {
+ up.dma = priv-omap8250_dma;
+ priv-omap8250_dma.fn = the_no_dma_filter_fn;
+ priv-omap8250_dma.rx_size = RX_TRIGGER;
+ priv-omap8250_dma.rxconf.src_maxburst = RX_TRIGGER;
+ priv-omap8250_dma.txconf.dst_maxburst = TX_TRIGGER;
+
+ if (of_machine_is_compatible(ti,am33xx))
+ up.bugs |= UART_BUG_DMATX;
+ }
+ }
+#endif
Hmm I wonder if there's a more generic solution to this?
It would be also nice to be able to specify the use of DMA from
the board specific .dts file.
Also, with DMA enabled, looks like omap deeper idle states are
blocked as the DMA stays reserved. After I commented out the
DMA info for my console UART, PM started working.
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
