On Mon, Apr 09, 2018 at 02:59:57PM +0300, Sergey Suloev wrote:
> > > But as soon as sun4i SPI driver is correctly declaring
> > > max_transfer_size then "smart" clients will work well by limiting a
> > > single transfer size to FIFO depth. I tested it with real hardware,
> > > again.
> > This is r
On 04/09/2018 02:36 PM, Maxime Ripard wrote:
On Mon, Apr 09, 2018 at 02:10:40PM +0300, Sergey Suloev wrote:
On 04/09/2018 01:50 PM, Mark Brown wrote:
On Mon, Apr 09, 2018 at 01:26:23PM +0300, Sergey Suloev wrote:
On 04/09/2018 12:27 PM, Maxime Ripard wrote:
On Fri, Apr 06, 2018 at 06:48:23PM
On Mon, Apr 09, 2018 at 02:10:40PM +0300, Sergey Suloev wrote:
> On 04/09/2018 01:50 PM, Mark Brown wrote:
> > On Mon, Apr 09, 2018 at 01:26:23PM +0300, Sergey Suloev wrote:
> > > On 04/09/2018 12:27 PM, Maxime Ripard wrote:
> > > > On Fri, Apr 06, 2018 at 06:48:23PM +0300, Sergey Suloev wrote:
> >
On Mon, Apr 09, 2018 at 02:10:40PM +0300, Sergey Suloev wrote:
> On 04/09/2018 01:50 PM, Mark Brown wrote:
> > On Mon, Apr 09, 2018 at 01:26:23PM +0300, Sergey Suloev wrote:
> > > Because current implementation tries to send more than FIFO-depth of data
> > > in
> > > a single call to "transfer_o
On 04/09/2018 01:50 PM, Mark Brown wrote:
On Mon, Apr 09, 2018 at 01:26:23PM +0300, Sergey Suloev wrote:
On 04/09/2018 12:27 PM, Maxime Ripard wrote:
On Fri, Apr 06, 2018 at 06:48:23PM +0300, Sergey Suloev wrote:
On 04/06/2018 10:34 AM, Maxime Ripard wrote:
According to what you said the drive
On Mon, Apr 09, 2018 at 01:26:23PM +0300, Sergey Suloev wrote:
> On 04/09/2018 12:27 PM, Maxime Ripard wrote:
> > On Fri, Apr 06, 2018 at 06:48:23PM +0300, Sergey Suloev wrote:
> > > On 04/06/2018 10:34 AM, Maxime Ripard wrote:
> > > According to what you said the driver must implement
> > > "tran
On 04/09/2018 12:27 PM, Maxime Ripard wrote:
On Fri, Apr 06, 2018 at 06:48:23PM +0300, Sergey Suloev wrote:
On 04/06/2018 10:34 AM, Maxime Ripard wrote:
On Thu, Apr 05, 2018 at 04:44:16PM +0300, Sergey Suloev wrote:
On 04/05/2018 04:17 PM, Mark Brown wrote:
On Thu, Apr 05, 2018 at 12:59:35PM
On Fri, Apr 06, 2018 at 06:48:23PM +0300, Sergey Suloev wrote:
> On 04/06/2018 10:34 AM, Maxime Ripard wrote:
> > On Thu, Apr 05, 2018 at 04:44:16PM +0300, Sergey Suloev wrote:
> > > On 04/05/2018 04:17 PM, Mark Brown wrote:
> > > > On Thu, Apr 05, 2018 at 12:59:35PM +0300, Sergey Suloev wrote:
> >
On 04/06/2018 10:34 AM, Maxime Ripard wrote:
On Thu, Apr 05, 2018 at 04:44:16PM +0300, Sergey Suloev wrote:
On 04/05/2018 04:17 PM, Mark Brown wrote:
On Thu, Apr 05, 2018 at 12:59:35PM +0300, Sergey Suloev wrote:
On 04/05/2018 12:19 PM, Maxime Ripard wrote:
The point of that patch was precise
On 04/06/2018 10:34 AM, Maxime Ripard wrote:
On Thu, Apr 05, 2018 at 04:44:16PM +0300, Sergey Suloev wrote:
On 04/05/2018 04:17 PM, Mark Brown wrote:
On Thu, Apr 05, 2018 at 12:59:35PM +0300, Sergey Suloev wrote:
On 04/05/2018 12:19 PM, Maxime Ripard wrote:
The point of that patch was precise
On Thu, Apr 05, 2018 at 04:44:16PM +0300, Sergey Suloev wrote:
> On 04/05/2018 04:17 PM, Mark Brown wrote:
> > On Thu, Apr 05, 2018 at 12:59:35PM +0300, Sergey Suloev wrote:
> > > On 04/05/2018 12:19 PM, Maxime Ripard wrote:
> > > > The point of that patch was precisely to allow to send more data t
On 04/05/2018 04:17 PM, Mark Brown wrote:
On Thu, Apr 05, 2018 at 12:59:35PM +0300, Sergey Suloev wrote:
On 04/05/2018 12:19 PM, Maxime Ripard wrote:
The point of that patch was precisely to allow to send more data than
the FIFO. You're breaking that behaviour without any justification,
and thi
On Thu, Apr 05, 2018 at 12:59:35PM +0300, Sergey Suloev wrote:
> On 04/05/2018 12:19 PM, Maxime Ripard wrote:
> > The point of that patch was precisely to allow to send more data than
> > the FIFO. You're breaking that behaviour without any justification,
> > and this is not ok.
> I am sorry, but
On Thu, Apr 05, 2018 at 11:19:13AM +0200, Maxime Ripard wrote:
> On Wed, Apr 04, 2018 at 02:35:14PM +0300, Sergey Suloev wrote:
> > What exactly and in what way ?
> You should explain, at least:
> A) What is the current behaviour
> B) Why that is a problem, or what problem does it cause
> C) What
On 04/05/2018 12:19 PM, Maxime Ripard wrote:
On Wed, Apr 04, 2018 at 02:35:14PM +0300, Sergey Suloev wrote:
On 04/04/2018 09:50 AM, Maxime Ripard wrote:
On Tue, Apr 03, 2018 at 06:44:46PM +0300, Sergey Suloev wrote:
There is no need to handle 3/4 empty interrupt as the maximum
supported transf
On Wed, Apr 04, 2018 at 02:35:14PM +0300, Sergey Suloev wrote:
> On 04/04/2018 09:50 AM, Maxime Ripard wrote:
> > On Tue, Apr 03, 2018 at 06:44:46PM +0300, Sergey Suloev wrote:
> > > There is no need to handle 3/4 empty interrupt as the maximum
> > > supported transfer length in PIO mode is equal t
On 04/04/2018 09:50 AM, Maxime Ripard wrote:
On Tue, Apr 03, 2018 at 06:44:46PM +0300, Sergey Suloev wrote:
There is no need to handle 3/4 empty interrupt as the maximum
supported transfer length in PIO mode is equal to FIFO depth,
i.e. 128 bytes for sun6i and 64 bytes for sun8i SoCs.
Changes i
On Tue, Apr 03, 2018 at 06:44:46PM +0300, Sergey Suloev wrote:
> There is no need to handle 3/4 empty interrupt as the maximum
> supported transfer length in PIO mode is equal to FIFO depth,
> i.e. 128 bytes for sun6i and 64 bytes for sun8i SoCs.
>
> Changes in v3:
> 1) Restored processing of 3/4 F
18 matches
Mail list logo
