| Message ID | 1412014009-13315-12-git-send-email-bigeasy@linutronix.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Mon, Sep 29, 2014 at 08:06:47PM +0200, Sebastian Andrzej Siewior wrote: > Cc: devicetree@vger.kernel.org > Reviewed-by: Tony Lindgren <tony@atomide.com> > Tested-by: Tony Lindgren <tony@atomide.com> > Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> > --- > arch/arm/boot/dts/dra7.dtsi | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi > index d678152db4cb..f273e3811f75 100644 > --- a/arch/arm/boot/dts/dra7.dtsi > +++ b/arch/arm/boot/dts/dra7.dtsi > @@ -332,6 +332,8 @@ > ti,hwmods = "uart1"; > clock-frequency = <48000000>; > status = "disabled"; > + dmas = <&sdma 49>, <&sdma 50>; > + dma-names = "tx", "rx"; > }; > > uart2: serial@4806c000 { > @@ -341,6 +343,8 @@ > ti,hwmods = "uart2"; > clock-frequency = <48000000>; > status = "disabled"; > + dmas = <&sdma 51>, <&sdma 52>; > + dma-names = "tx", "rx"; > }; > > uart3: serial@48020000 { > @@ -350,6 +354,8 @@ > ti,hwmods = "uart3"; > clock-frequency = <48000000>; > status = "disabled"; > + dmas = <&sdma 53>, <&sdma 54>; > + dma-names = "tx", "rx"; > }; > > uart4: serial@4806e000 { > @@ -359,6 +365,8 @@ > ti,hwmods = "uart4"; > clock-frequency = <48000000>; > status = "disabled"; > + dmas = <&sdma 55>, <&sdma 56>; > + dma-names = "tx", "rx"; > }; > > uart5: serial@48066000 { > @@ -368,6 +376,8 @@ > ti,hwmods = "uart5"; > clock-frequency = <48000000>; > status = "disabled"; > + dmas = <&sdma 63>, <&sdma 64>; > + dma-names = "tx", "rx"; > }; > > uart6: serial@48068000 { > @@ -377,6 +387,8 @@ > ti,hwmods = "uart6"; > clock-frequency = <48000000>; > status = "disabled"; > + dmas = <&sdma 79>, <&sdma 80>; > + dma-names = "tx", "rx"; > }; > > uart7: serial@48420000 { According to the manual the DMA channels for UART7 to 10 are: uart7: 144 145 uart8: 146 147 uart9: 148 149 uart10: 150 151 Might as well add those too. We have uart 7 and 8 in use on our board so I am about to go test it.
On 11/04/2014 06:02 PM, Lennart Sorensen wrote: > > According to the manual the DMA channels for UART7 to 10 are: > > uart7: 144 145 > uart8: 146 147 > uart9: 148 149 > uart10: 150 151 > > Might as well add those too. We have uart 7 and 8 in use on our board > so I am about to go test it. Mind sharing the manual with me? Mine does not mention DMA channels for UART7-10. If you are able to test 7+8 (and it works) could you please make patch which with for the remaining four devices? Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 04, 2014 at 06:06:37PM +0100, Sebastian Andrzej Siewior wrote: > On 11/04/2014 06:02 PM, Lennart Sorensen wrote: > > > > According to the manual the DMA channels for UART7 to 10 are: > > > > uart7: 144 145 > > uart8: 146 147 > > uart9: 148 149 > > uart10: 150 151 > > > > Might as well add those too. We have uart 7 and 8 in use on our board > > so I am about to go test it. > > Mind sharing the manual with me? Mine does not mention DMA channels for > UART7-10. If you are able to test 7+8 (and it works) could you please > make patch which with for the remaining four devices? Well the file I have is called AM572x_ES1.1_NDA_TRM_vT.pdf, so I am not sure who I am allowed to share that file with. Might be simpler to just ask TI for the latest version. How I hate NDAs.
Hello, On Tue, Nov 4, 2014 at 6:21 PM, Lennart Sorensen <lsorense@csclub.uwaterloo.ca> wrote: >> Mind sharing the manual with me? Mine does not mention DMA channels for >> UART7-10. If you are able to test 7+8 (and it works) could you please >> make patch which with for the remaining four devices? > > Well the file I have is called AM572x_ES1.1_NDA_TRM_vT.pdf, so I am not > sure who I am allowed to share that file with. Might be simpler to just > ask TI for the latest version. > > How I hate NDAs. > I saw today an announcement about a public AM572x Silicon Revision 1.1 TRM [0] that has just made available by TI. I'm not familiar with this SoC so I don't know if that has the information you want but I thought it was worth to mention in case it did. Best regards, Javier [0]: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Nov 04, 2014 at 12:21:17PM -0500, Lennart Sorensen wrote: > Well the file I have is called AM572x_ES1.1_NDA_TRM_vT.pdf, so I am not > sure who I am allowed to share that file with. Might be simpler to just > ask TI for the latest version. > > How I hate NDAs. Well it doesn't work, because I don't have the dma croassbar patches from ti-linux-3.14.y which are required to use the full range of dma channels on the dra7. I will see how well it works without dma at least.
On 11/04/2014 12:32 PM, Javier Martinez Canillas wrote: > Hello, > > On Tue, Nov 4, 2014 at 6:21 PM, Lennart Sorensen > <lsorense@csclub.uwaterloo.ca> wrote: >>> Mind sharing the manual with me? Mine does not mention DMA channels for >>> UART7-10. If you are able to test 7+8 (and it works) could you please >>> make patch which with for the remaining four devices? >> >> Well the file I have is called AM572x_ES1.1_NDA_TRM_vT.pdf, so I am not >> sure who I am allowed to share that file with. Might be simpler to just >> ask TI for the latest version. >> >> How I hate NDAs. >> > > I saw today an announcement about a public AM572x Silicon Revision 1.1 > TRM [0] that has just made available by TI. I'm not familiar with this > SoC so I don't know if that has the information you want but I thought > it was worth to mention in case it did. > > Best regards, > Javier > > [0]: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf Same chip.
On Tue, Nov 04, 2014 at 07:32:07PM +0100, Javier Martinez Canillas wrote: > Hello, > > On Tue, Nov 4, 2014 at 6:21 PM, Lennart Sorensen > <lsorense@csclub.uwaterloo.ca> wrote: > >> Mind sharing the manual with me? Mine does not mention DMA channels for > >> UART7-10. If you are able to test 7+8 (and it works) could you please > >> make patch which with for the remaining four devices? > > > > Well the file I have is called AM572x_ES1.1_NDA_TRM_vT.pdf, so I am not > > sure who I am allowed to share that file with. Might be simpler to just > > ask TI for the latest version. > > > > How I hate NDAs. > > > > I saw today an announcement about a public AM572x Silicon Revision 1.1 > TRM [0] that has just made available by TI. I'm not familiar with this > SoC so I don't know if that has the information you want but I thought > it was worth to mention in case it did. > > Best regards, > Javier > > [0]: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf That's the right one. Page 3622 has the dma channels for uart 7 through 10, but it still needs the updated crossbar dma driver to work.
On Tue, Nov 04, 2014 at 01:33:15PM -0500, Lennart Sorensen wrote: > Well it doesn't work, because I don't have the dma croassbar patches > from ti-linux-3.14.y which are required to use the full range of dma > channels on the dra7. > > I will see how well it works without dma at least. So it seems to be working on our board so far. Will stress test it some more. No DMA of course for now, but oh well.
On Tue, Nov 04, 2014 at 04:03:15PM -0500, Lennart Sorensen wrote: > So it seems to be working on our board so far. Will stress test it > some more. No DMA of course for now, but oh well. Well 4 hours running with multiple reboots (our testsuite reboots every 30 minutes to test the watchdog). So far it has only lost 70 bytes out of 40MB of data sent between uart7 and uart8 (and we are pretty sure the serial test has a small bug that causes a few bytes to be lost right after a reboot sometimes). The reason I am even trying the new driver today is that we were seeing soft lockups on the CPU whenever the serial ports were being tested, usually in less than 5 minutes, so 4 hours without a lockup is a good sign. No idea what might be wrong with the old omap serial driver, but it seems something is (unless of course we managed to break it somehow when we tried to solve its habit of dropping characters). I think I will stick with this new driver. Better long term future anyhow.
On 11/05/2014 02:15 AM, Lennart Sorensen wrote: > Well 4 hours running with multiple reboots (our testsuite reboots every > 30 minutes to test the watchdog). So far it has only lost 70 bytes out > of 40MB of data sent between uart7 and uart8 (and we are pretty sure > the serial test has a small bug that causes a few bytes to be lost right > after a reboot sometimes). > > The reason I am even trying the new driver today is that we were seeing > soft lockups on the CPU whenever the serial ports were being tested, > usually in less than 5 minutes, so 4 hours without a lockup is a good > sign. No idea what might be wrong with the old omap serial driver, but > it seems something is (unless of course we managed to break it somehow > when we tried to solve its habit of dropping characters). Okay. No DMA but the basic part seems to work for you. Thanks for testing. Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 05, 2014 at 09:11:35AM +0100, Sebastian Andrzej Siewior wrote: > Okay. No DMA but the basic part seems to work for you. Thanks for > testing. Two systems ran 16 hours each so far with no issues. Pushed 170MB of data through the pair of serial ports on one system at 230400.
On Wed, Nov 05, 2014 at 10:33:15AM -0500, Lennart Sorensen wrote: > Two systems ran 16 hours each so far with no issues. Pushed 170MB of > data through the pair of serial ports on one system at 230400. The console on uart3 doesn't appear to be using the dma assuming the values in /sys for the dma controller and bytes transferred mean anything. It does mention in dmesg that it allocated dma channels for uart3 though. How do you tell if it is using dma?
On 11/05/2014 05:20 PM, Lennart Sorensen wrote: > On Wed, Nov 05, 2014 at 10:33:15AM -0500, Lennart Sorensen wrote: >> Two systems ran 16 hours each so far with no issues. Pushed 170MB of >> data through the pair of serial ports on one system at 230400. > > The console on uart3 doesn't appear to be using the dma assuming the > values in /sys for the dma controller and bytes transferred mean anything. > It does mention in dmesg that it allocated dma channels for uart3 though. Then it should use it :) > How do you tell if it is using dma? There is omap_8250_tx_dma() and omap_8250_rx_dma(). Both setup callbacks (the rx+tx _complete). Upon successful DMA transfer you should see them invoked with bytes transfered (>0). For RX transfer you need at least trigger bytes in the FIFO within a given time frame (I think it was 46 bytes and the delay may be up to 2 bytes). If you miss this then DMA for RX won't wire and you purge the FIFO manually via "timeout-interrupt" (the callback will be invoked with an error condition and 0 bytes). Assuming this works for you then one should figure out why the counters in /sys are not updated… Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Nov 05, 2014 at 05:30:51PM +0100, Sebastian Andrzej Siewior wrote: > On 11/05/2014 05:20 PM, Lennart Sorensen wrote: > > On Wed, Nov 05, 2014 at 10:33:15AM -0500, Lennart Sorensen wrote: > >> Two systems ran 16 hours each so far with no issues. Pushed 170MB of > >> data through the pair of serial ports on one system at 230400. > > > > The console on uart3 doesn't appear to be using the dma assuming the > > values in /sys for the dma controller and bytes transferred mean anything. > > It does mention in dmesg that it allocated dma channels for uart3 though. > > Then it should use it :) I managed to get something dma related on uart3. But it isn't happy: [ 95.577401] DMA misaligned error with device 53 repeated many times. I wonder if the dma support isn't quite working for the omap572x yet in this tree (ti's 3.12.y tree), or maybe it is picky and the driver still needs a bit of work. I have had no issues on uart7 and 8 without dma. > There is omap_8250_tx_dma() and omap_8250_rx_dma(). Both setup > callbacks (the rx+tx _complete). Upon successful DMA transfer you > should see them invoked with bytes transfered (>0). > For RX transfer you need at least trigger bytes in the FIFO within a > given time frame (I think it was 46 bytes and the delay may be up to 2 > bytes). If you miss this then DMA for RX won't wire and you purge the > FIFO manually via "timeout-interrupt" (the callback will be invoked > with an error condition and 0 bytes). > > Assuming this works for you then one should figure out why the counters > in /sys are not updated…
On 11/05/2014 08:43 PM, Lennart Sorensen wrote: > I managed to get something dma related on uart3. But it isn't happy: > > [ 95.577401] DMA misaligned error with device 53 > repeated many times. > > I wonder if the dma support isn't quite working for the omap572x yet in > this tree (ti's 3.12.y tree), or maybe it is picky and the driver still > needs a bit of work. misaligned dma? I haven't seen any alignment requirement for SDMA/EDMA and I haven't seen this error on beagle board, am335x-evm or dra7-evm. > I have had no issues on uart7 and 8 without dma. So basically what you are saying is that DMA (no matter which channel) gives you this error and without DMA it works fine? Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Nov 13, 2014 at 07:34:09PM +0100, Sebastian Andrzej Siewior wrote: > misaligned dma? I haven't seen any alignment requirement for SDMA/EDMA > and I haven't seen this error on beagle board, am335x-evm or dra7-evm. Well I am using the am5728, so it should be the same as the dra7-evm. > So basically what you are saying is that DMA (no matter which channel) > gives you this error and without DMA it works fine? Yes. I am trying to get the 3.14 kernel tree going, just as soon as I figure out which config setting makes the timer probe not crash (it works with the default config that enables every omap ever made, but I want a cleaner build than that).
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi index d678152db4cb..f273e3811f75 100644 --- a/arch/arm/boot/dts/dra7.dtsi +++ b/arch/arm/boot/dts/dra7.dtsi @@ -332,6 +332,8 @@ ti,hwmods = "uart1"; clock-frequency = <48000000>; status = "disabled"; + dmas = <&sdma 49>, <&sdma 50>; + dma-names = "tx", "rx"; }; uart2: serial@4806c000 { @@ -341,6 +343,8 @@ ti,hwmods = "uart2"; clock-frequency = <48000000>; status = "disabled"; + dmas = <&sdma 51>, <&sdma 52>; + dma-names = "tx", "rx"; }; uart3: serial@48020000 { @@ -350,6 +354,8 @@ ti,hwmods = "uart3"; clock-frequency = <48000000>; status = "disabled"; + dmas = <&sdma 53>, <&sdma 54>; + dma-names = "tx", "rx"; }; uart4: serial@4806e000 { @@ -359,6 +365,8 @@ ti,hwmods = "uart4"; clock-frequency = <48000000>; status = "disabled"; + dmas = <&sdma 55>, <&sdma 56>; + dma-names = "tx", "rx"; }; uart5: serial@48066000 { @@ -368,6 +376,8 @@ ti,hwmods = "uart5"; clock-frequency = <48000000>; status = "disabled"; + dmas = <&sdma 63>, <&sdma 64>; + dma-names = "tx", "rx"; }; uart6: serial@48068000 { @@ -377,6 +387,8 @@ ti,hwmods = "uart6"; clock-frequency = <48000000>; status = "disabled"; + dmas = <&sdma 79>, <&sdma 80>; + dma-names = "tx", "rx"; }; uart7: serial@48420000 {