On Mon, Sep 29, 2014 at 08:06:47PM +0200, Sebastian Andrzej Siewior wrote:
> Cc: [email protected]
> Reviewed-by: Tony Lindgren <[email protected]>
> Tested-by: Tony Lindgren <[email protected]>
> Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
> ---
> 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.
--
Len Sorensen
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
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.
--
Len Sorensen
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.
--
Len Sorensen
Hello,
On Tue, Nov 4, 2014 at 6:21 PM, Lennart Sorensen
<[email protected]> 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
On 11/04/2014 12:32 PM, Javier Martinez Canillas wrote:
> Hello,
>
> On Tue, Nov 4, 2014 at 6:21 PM, Lennart Sorensen
> <[email protected]> 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.
--
Regards,
Nishanth Menon
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
> <[email protected]> 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.
--
Len Sorensen
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.
--
Len Sorensen
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.
--
Len Sorensen
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
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.
--
Len Sorensen
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?
--
Len Sorensen
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
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…
--
Len Sorensen
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
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).
--
Len Sorensen