On Fri, Apr 06, 2018 at 06:48:23PM +0300, Sergey Suloev wrote:
On 04/06/2018 10:34 AM, Maxime Ripard wrote:I'm not sure what makes you think that I said that.
On Thu, Apr 05, 2018 at 04:44:16PM +0300, Sergey Suloev wrote:According to what you said the driver must implement
On 04/05/2018 04:17 PM, Mark Brown wrote:Because you're not supposed to have a transfer larger than the FIFO,
On Thu, Apr 05, 2018 at 12:59:35PM +0300, Sergey Suloev wrote:Well, normally yes, but this is not the case with the hardware that I own.
On 04/05/2018 12:19 PM, Maxime Ripard wrote:Are you positive about that? Normally you can add things to hardware
The point of that patch was precisely to allow to send more data thanI am sorry, but you can't. That's a hardware limitation.
the FIFO. You're breaking that behaviour without any justification,
and this is not ok.
FIFOs while they're being drained so so long as you can keep data
flowing in at least as fast as it's being consumed.
My a20 (BPiM1+) and a31 (BPiM2) boards behaves differently. With a transfer
larger than FIFO then TC interrupt never happens.
but to have to setup at first a transfer the size of the FIFO, and
then when it's (or starts to be) depleted, fill it up again.
"transfer_one_message" instead of "transfer_one"
Maxime
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel