From: Robin Murphy <robin.murphy@arm.com>
To: Heiko Stuebner <heiko@sntech.de>
Cc: Katsuhiro Suzuki <katsuhiro@katsuster.net>,
linux-rockchip@lists.infradead.org, linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2] arm64: dts: rockchip: add rk3399 UART DMAs
Date: Thu, 11 Apr 2019 20:17:36 +0100 [thread overview]
Message-ID: <2e5a1468-9a65-9cc5-f96c-272faeb92ec9@arm.com> (raw)
In-Reply-To: <8d164cfe-c345-aa45-aaf3-11983f9142e5@arm.com>
On 2019-04-11 2:48 pm, Robin Murphy wrote:
> On 11/04/2019 13:46, Heiko Stuebner wrote:
>> Hi Robin,
>>
>> Am Samstag, 30. März 2019, 00:24:16 CEST schrieb Robin Murphy:
>>> On 2019-03-27 12:00 pm, Heiko Stuebner wrote:
>>>> Hi,
>>>>
>>>> Am Dienstag, 26. März 2019, 14:49:16 CET schrieb Katsuhiro Suzuki:
>>>>> Hello Robin,
>>>>>
>>>>> Sorry for inconvenience. Since I don't adhere enabling DMA for UARTs,
>>>>> please revert my patch if you need.
>>>>
>>>> I've dropped the patch from my queue now.
>>>>
>>>>> BTW, there are DMA properties in RK3328 device-tree like as this
>>>>> patch.
>>>>> RK3328 UART DMA could not work correctly too...??
>>>>
>>>> I remember Rockcihip dma-controllers having issues with burst-sizes
>>>> and flushing (there is a no-flushp option in pl330), so it's
>>>> possible that all share the same error up to rk3399 and rk3328
>>>>
>>>> But so far no-one has shouted regarding the rk3328.
>>>
>>> Let me be the first, then, I guess :)
>>>
>>> I found an easy way to observe the problem on my 3399, and I've just
>>> fired up my 3328 box with a 5.0 distro kernel to find that it behaves
>>> the same. Basically just dump a large pile of text into 'less' on the
>>> serial console, and scroll through line-by-line - certain lines get
>>> dropped except for a few characters at the end.
>>>
>>> I'll see if I can narrow it down a bit, starting with trying
>>> broken-flushp...
>>
>> did you manage to find time for that test you wanted to do?
>
> Sadly not - I got somewhat distracted by the ethernet thing, and since
> then I've had too much else going on to follow up on any of my 'for fun'
> projects :(
Urgh, and it turns out what I thought were dropped characters seems to
just be my console handling line wrapping weirdly, so now I have no idea
if RK3328 actually has an issue, and coming up with a reliable
reproducer for RK3399 is going to take some thought...
Robin.
next prev parent reply other threads:[~2019-04-11 19:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-21 16:22 Katsuhiro Suzuki
2019-03-25 12:34 ` Heiko Stuebner
2019-03-26 11:48 ` Robin Murphy
2019-03-26 13:49 ` Katsuhiro Suzuki
2019-03-27 12:00 ` Heiko Stuebner
2019-03-29 23:24 ` Robin Murphy
2019-04-11 12:46 ` Heiko Stuebner
2019-04-11 13:48 ` Robin Murphy
2019-04-11 19:17 ` Robin Murphy [this message]
2019-03-27 12:10 ` Robin Murphy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2e5a1468-9a65-9cc5-f96c-272faeb92ec9@arm.com \
--to=robin.murphy@arm.com \
--cc=heiko@sntech.de \
--cc=katsuhiro@katsuster.net \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®