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
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
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 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:
> > > 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
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
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
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
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
> > >
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
> > >
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 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 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
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
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
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
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
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
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
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
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,
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,
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)
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)
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
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
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
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
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
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
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
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
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 FIFO full interrupt.
Signed-off-by: Sergey Suloev
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 FIFO full interrupt.
Signed-off-by: Sergey Suloev
---
38 matches
Mail list logo