linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Sergey Suloev <ssuloev@orpaltech.com>
Cc: Maxime Ripard <maxime.ripard@bootlin.com>,
	Chen-Yu Tsai <wens@csie.org>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org, linux-spi@vger.kernel.org
Subject: Re: [PATCH v3 3/6] spi: sun6i: restrict transfer length in PIO-mode
Date: Mon, 9 Apr 2018 12:27:03 +0100	[thread overview]
Message-ID: <20180409112703.GD11532@sirena.org.uk> (raw)
In-Reply-To: <67c2006b-17f2-2459-e3c9-e91e3c694d8c@orpaltech.com>

[-- Attachment #1: Type: text/plain, Size: 1411 bytes --]

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_one" which is wrong.

> > No, that's absolutely not the case.  All any of these functions has to
> > do is transfer whatever they were asked to, how they do it is not at all
> > important to the framework.

> I think you don't fully understand the issue. Let's talk about sun4i and 
> sun6i SPI  drivers separately.

> sun4i

> 1)it is correctly declaring max_transfer_size=FIFO depth for PIO mode  but
> transfer_one() function doesn't follow the declaration allowing PIO
> transfers longer than FIFO depth  by just refilling FIFO using 3/4 FIFO
> empty interrupt. I can definitely state here that long transfers WON'T WORK
> on real hardware. I tested it and that's why I can say that. 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.

None of this is in the slightest bit related to the use of transfer_one() 
vs transfer_one_message().  These are all implementation details and
will so far as I can tell apply equally to both APIs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2018-04-09 11:27 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-03 15:44 [PATCH v3 0/6] spi: Add support for DMA transfers in sun6i SPI driver Sergey Suloev
2018-04-03 15:44 ` [PATCH v3 1/6] spi: sun6i: coding style/readability improvements Sergey Suloev
2018-04-04  6:45   ` Maxime Ripard
2018-04-03 15:44 ` [PATCH v3 2/6] spi: sun6i: handle chip select polarity flag Sergey Suloev
2018-04-03 15:44 ` [PATCH v3 3/6] spi: sun6i: restrict transfer length in PIO-mode Sergey Suloev
2018-04-04  6:50   ` Maxime Ripard
2018-04-04 11:35     ` Sergey Suloev
2018-04-05  9:19       ` Maxime Ripard
2018-04-05  9:59         ` Sergey Suloev
2018-04-05 13:17           ` Mark Brown
2018-04-05 13:44             ` Sergey Suloev
2018-04-06  7:34               ` Maxime Ripard
2018-04-06 15:48                 ` Sergey Suloev
2018-04-09  9:27                   ` Maxime Ripard
2018-04-09 10:26                     ` Sergey Suloev
2018-04-09 10:50                       ` Mark Brown
2018-04-09 11:10                         ` Sergey Suloev
2018-04-09 11:27                           ` Mark Brown [this message]
2018-04-09 11:36                           ` Maxime Ripard
2018-04-09 11:59                             ` Sergey Suloev
2018-04-10 14:05                               ` Maxime Ripard
2018-04-06 15:54                 ` Sergey Suloev
2018-04-05 10:07         ` Mark Brown
2018-04-03 15:44 ` [PATCH v3 4/6] spi: sun6i: use completion provided by SPI core Sergey Suloev
2018-04-04  6:53   ` Maxime Ripard
2018-04-03 15:44 ` [PATCH v3 5/6] spi: sun6i: introduce register set/unset helpers Sergey Suloev
2018-04-04  1:32   ` kbuild test robot
2018-04-04  7:02   ` Maxime Ripard
2018-04-03 15:44 ` [PATCH v3 6/6] spi: sun6i: add DMA transfers support Sergey Suloev
2018-04-04  7:00   ` Maxime Ripard

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=20180409112703.GD11532@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=maxime.ripard@bootlin.com \
    --cc=ssuloev@orpaltech.com \
    --cc=wens@csie.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;
as well as URLs for NNTP newsgroup(s).