From: Serge Semin <fancer.lancer@gmail.com>
To: Sean Anderson <seanga2@gmail.com>
Cc: Mark Brown <broonie@kernel.org>,
Damien Le Moal <damien.lemoal@wdc.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
linux-riscv@lists.infradead.org, Rob Herring <robh+dt@kernel.org>,
Frank Rowand <frowand.list@gmail.com>,
devicetree@vger.kernel.org, linux-spi@vger.kernel.org,
Stephen Boyd <sboyd@kernel.org>,
linux-clk@vger.kernel.org,
Linus Walleij <linus.walleij@linaro.org>,
linux-gpio@vger.kernel.org,
Philipp Zabel <p.zabel@pengutronix.de>
Subject: Re: [PATCH 03/32] spi: dw: Fix driving MOSI low while recieving
Date: Mon, 9 Nov 2020 23:17:44 +0300 [thread overview]
Message-ID: <20201109201744.zlxwur4p3ejbraup@mobilestation> (raw)
In-Reply-To: <5808c9b9-5955-4733-2c56-b93c627cb556@gmail.com>
On Mon, Nov 09, 2020 at 02:40:01PM -0500, Sean Anderson wrote:
> On 11/9/20 2:19 PM, Serge Semin wrote:
> > On Mon, Nov 09, 2020 at 02:14:22PM +0000, Mark Brown wrote:
> >> On Mon, Nov 09, 2020 at 08:47:10AM -0500, Sean Anderson wrote:
> >>> On 11/9/20 8:29 AM, Mark Brown wrote:
> >>>> On Sat, Nov 07, 2020 at 05:13:51PM +0900, Damien Le Moal wrote:
> >>>>
> >
> >>>>> The resting state of MOSI is high when nothing is driving it. If we
> >>>>> drive it low while recieving, it looks like we are transmitting 0x00
> >>>>> instead of transmitting nothing. This can confuse slaves (like SD cards)
> >>>>> which allow new commands to be sent over MOSI while they are returning
> >>>>> data over MISO. The return of MOSI from 0 to 1 at the end of recieving
> >>>>> a byte can look like a start bit and a transmission bit to an SD card.
> >
> > Yeah, that's what we've also experienced on our systems. We've worked
> > around the problem in exactly the same way as you have. But we haven't
> > dared to send it out as the solution seemed a bit hackish.
>
> Well, the way it is now is equally wrong, since it is driving the line
> low.
Alas a lot of the SPI-controller drivers have got it implemented in the
same way. So, yeah, all of them won't work well with the SPI-based MMC
interfaces, unless either the client driver or the SPI core code are
properly fixed.
>
> >>>>
> >>>> If client devices are interpreting the transmitted data then I would
> >>>> expect the drivers for that hardware to be ensuring that whatever we
> >>>> transmit matches what the device is expecting. We shouldn't be putting
> >>>> a hack in a particular controller driver to paper over things, that will
> >>>> mean that the device will break when used with other controllers and if
> >>>> different devices have different requirements then obviously we can't
> >>>> satisfy them. There is not meaningfully a general specification for SPI
> >>>> which says what happens when signals are idle, it's all specific to the
> >>>> client device.
> >>>>
> >>>> In this case it also looks like the controller hardware requires
> >>>> transmit data and therefore should be setting SPI_MUST_TX and just
> >>>> removing the in driver default anyway, though that will have no effect
> >>>> one way or anther on the issue you're seeing.
> >>
> >
> >>> There is a recieve-only mode, but it is not used by this driver. Perhaps
> >>> it should be.
> >>
> >> I'd expect it'd perform better, especially on systems that are
> >> apparently struggling for CPU bandwidth like yours seems to.
> >
> > CPU-wise. RO-mode won't help in that case. Moreover it will be even
> > more errors-prone for the systems with small CPU bandwidth. As I said
> > the Receive-only mode will make the SPI controller automatically
> > receiving data from the SPI bus and putting it into the Rx FIFO. If
> > CPU is either busy with something else or too slow in fetching the
> > data from the Rx FIFO, the FIFO will be eventually overflown with
> > data, which we need to avoid at all cost.
> >
> > As I see it the Receive-only mode is only acceptable in the next two
> > situations:
> >
> > 1) Rx-only DMA. But only if the DMA-engine and system bus are fast
> > enough to fetch the incoming data on time. (Note for example in our
> > system some DWC DMA-engine channels don't work well with the DW APB
> > SSI working with full-speed, so we had to set constraints on the DWC
> > DMA channels being used in conjunction with the DW APB SSI
> > controller.)
> >
> > 2) Rx-only with atomic CPU utilization. In order to make sure that the
> > CPU keeps up with fetching the data from the Rx FIFO, we have to
> > disable the local CPU IRQs while performing the Rx-only transfers, so
> > to prevent the Rx FIFO overflow while the CPU is doing something else.
> > Needless to say that such approach should be utilized only as a last
> > resort, if we have no choice but to run the Receive-only transfers.
> > Because locking the CPU for God knows how much time may cause the
> > system interactivity degradation. For instance, a possible use-case of
> > that design is when the controller is communicating with the
> > SPI-devices with native DW APB SSI chip-select attached. BTW You can
> > also find that design implemented in the kernel 5.10 spi-dw-core.c
> > driver in context of the SPI-memory operations (with my last patches
> > merged in). In particular I had to use it to handle the CPU-based
> > EEPROM-read mode.
> >
> > So in all other cases for normal CPU-based SPI-transfers when
> > GPIO-based chip-select is available the safest solution would be to
> > use a normal Push-Pull mode. In this case we have no risk in getting
> > the Rx FIFO overflow unless there is a bug in the code, which is
> > fixable anyway.
> >
> > Getting back to the patch. In fact I don't really see how the
> > Receive-only mode will help us with solving the problem noted in the
> > patch log.
>
> Shouldn't it put MOSI into High-Z like when the device is idle? The
> issue is mainly that the idle state and RX state are different.
AFAICS the manual doesn't say anything about High-Z, but only: "In
receive-only mode, transmitted data are not valid. After the first
write to the transmit FIFO, the same word is retransmitted for the
duration of the transfer."
I don't know for sure what "word" the authors meant, but it doesn't
sound like Tri-state anyway. So some value will still be put out on
the bus. Most likely it's the word written to the Tx-buffer to
initiate the Rx-only transfer.
>
> > As Mark said the problem with the Tx data on Rx-only
> > transfers should be fixed on the client side. If an subordinate
> > SPI-device needs a specific value to be received in that case, then
> > that value should be somehow provided to the SPI-controller anyway.
> > So the native Rx-only mode of the DW APB SSI controller won't help.
> > Currently it's possible to be done only by executing a Full-duplex
> > SPI-transfer with the Tx-buffer being pre-initialized with that
> > value.
> >
> > Another possible solution for the problem would be to fix the SPI core
> > so aside with tx_buf being set to the NULL-pointer, a client driver
> > would provide a default level or some specific value being put to the
> > SPI bus on Rx-only transfers. If an SPI-controller is capable of
> > satisfying the request, then it will accept the transfer. If it's not,
> > then the SPI core may try to convert the Rx-only transfer into the
> > Full-duplex transfer with the Tx-buffer being initialized with the
> > requested level.
>
> This is probably the most general solution; is there an existing way to
> specify this sort of thing?
Without touching the SPI core code, as Mark said, the problem is
fixable only by converting the client-driver to executing the
Full-duplex SPI-transfers instead of the Rx-only ones. The client
driver will have to allocate a dummy-buffer and pre-initialize it with
the required default value of the MOSI lane.
-Sergey
>
> --Sean
next prev parent reply other threads:[~2020-11-09 20:17 UTC|newest]
Thread overview: 132+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-07 8:13 [PATCH 00/32] RISC-V Kendryte K210 support improvments Damien Le Moal
2020-11-07 8:13 ` [PATCH 01/32] of: Fix property supplier parsing Damien Le Moal
2020-11-09 15:05 ` Serge Semin
2020-11-09 15:14 ` Andy Shevchenko
2020-11-09 17:44 ` Serge Semin
2020-11-09 20:52 ` Rob Herring
2020-11-07 8:13 ` [PATCH 02/32] spi: dw: Add support for 32-bits ctrlr0 layout Damien Le Moal
2020-11-07 13:28 ` Sean Anderson
2020-11-09 14:25 ` Serge Semin
2020-11-09 14:33 ` Sean Anderson
2020-11-09 14:35 ` Sean Anderson
2020-11-09 14:40 ` Andy Shevchenko
2020-11-09 14:41 ` Andy Shevchenko
2020-11-09 14:49 ` Sean Anderson
2020-11-09 15:10 ` Andy Shevchenko
2020-11-09 14:36 ` Andy Shevchenko
2020-11-09 17:56 ` Serge Semin
2020-11-07 8:13 ` [PATCH 03/32] spi: dw: Fix driving MOSI low while recieving Damien Le Moal
2020-11-07 13:30 ` Sean Anderson
2020-11-09 13:29 ` Mark Brown
2020-11-09 13:47 ` Sean Anderson
2020-11-09 14:14 ` Mark Brown
2020-11-09 14:48 ` Serge Semin
2020-11-09 16:45 ` Mark Brown
2020-11-09 19:19 ` Serge Semin
2020-11-09 19:40 ` Sean Anderson
2020-11-09 20:17 ` Serge Semin [this message]
2020-11-09 20:29 ` Mark Brown
2020-11-09 20:20 ` Mark Brown
2020-11-09 21:05 ` Serge Semin
2020-11-10 13:43 ` Mark Brown
2020-11-07 8:13 ` [PATCH 04/32] spi: dw: Introduce polling device tree property Damien Le Moal
2020-11-09 16:04 ` Mark Brown
2020-11-09 19:59 ` Serge Semin
2020-11-13 9:22 ` Damien Le Moal
2020-11-15 16:01 ` Serge Semin
2020-11-16 7:47 ` Damien Le Moal
2020-11-16 12:33 ` Mark Brown
2020-11-16 21:55 ` Serge Semin
2020-11-17 14:44 ` Damien Le Moal
2020-11-17 18:26 ` Serge Semin
2020-11-18 4:41 ` Damien Le Moal
2020-11-18 15:16 ` Serge Semin
2020-11-19 5:12 ` Damien Le Moal
2020-11-19 8:51 ` Serge Semin
2020-11-19 8:57 ` Damien Le Moal
2020-11-07 8:13 ` [PATCH 05/32] spi: dw: Introduce DW_SPI_CAP_POLL_NODELAY Damien Le Moal
2020-11-09 14:03 ` Mark Brown
2020-11-09 20:45 ` Serge Semin
2020-11-07 8:13 ` [PATCH 06/32] spi: dw: Add support for the Kendryte K210 SoC Damien Le Moal
2020-11-07 13:31 ` Sean Anderson
2020-11-07 13:42 ` Damien Le Moal
2020-11-07 13:52 ` Sean Anderson
2020-11-09 14:15 ` Mark Brown
2020-11-13 8:00 ` Damien Le Moal
2020-11-09 21:21 ` Serge Semin
2020-11-09 21:39 ` Damien Le Moal
2020-11-09 21:55 ` Rob Herring
2020-11-09 22:00 ` Damien Le Moal
2020-11-09 23:07 ` Rob Herring
2020-11-10 0:35 ` Damien Le Moal
2020-11-07 8:13 ` [PATCH 07/32] dt-bindings: Update DW SPI device tree bindings Damien Le Moal
2020-11-07 8:13 ` [PATCH 08/32] riscv: Fix kernel time_init() Damien Le Moal
2020-11-12 7:21 ` Atish Patra
2020-11-13 7:31 ` Stephen Boyd
2020-11-07 8:13 ` [PATCH 09/32] riscv: Fix SiFive gpio probe Damien Le Moal
2020-11-10 14:39 ` Linus Walleij
2020-11-07 8:13 ` [PATCH 10/32] riscv: Fix sifive serial driver Damien Le Moal
2020-11-07 8:13 ` [PATCH 11/32] riscv: Enable interrupts during syscalls with M-Mode Damien Le Moal
2020-11-07 8:14 ` [PATCH 12/32] riscv: Automatically select sysctl config options Damien Le Moal
2020-11-07 8:14 ` [PATCH 13/32] riscv: Fix builtin DTB handling Damien Le Moal
2020-11-15 4:17 ` kernel test robot
2020-11-07 8:14 ` [PATCH 14/32] dt-bindings: Define all Kendryte K210 clock IDs Damien Le Moal
2020-11-07 13:33 ` Sean Anderson
2020-11-07 8:14 ` [PATCH 15/32] dt-bindings: Define Kendryte K210 sysctl registers Damien Le Moal
2020-11-07 13:34 ` Sean Anderson
2020-11-09 21:59 ` Rob Herring
2020-11-09 22:10 ` Sean Anderson
2020-11-09 23:01 ` Rob Herring
2020-11-07 8:14 ` [PATCH 16/32] dt-bindings: Define Kendryte K210 pin functions Damien Le Moal
2020-11-07 13:38 ` Sean Anderson
2020-11-07 8:14 ` [PATCH 17/32] dt-bindings: Define Kendryte K210 reset signals Damien Le Moal
2020-11-07 13:38 ` Sean Anderson
2020-11-07 8:14 ` [PATCH 18/32] riscv: Add Kendryte K210 SoC clock driver Damien Le Moal
2020-11-07 13:48 ` Sean Anderson
2020-11-07 8:14 ` [PATCH 19/32] riscv: Add Kendryte K210 SoC reset controller Damien Le Moal
2020-11-07 13:58 ` Sean Anderson
2020-11-07 8:14 ` [PATCH 20/32] riscv: Add Kendryte K210 FPIOA pinctrl driver Damien Le Moal
2020-11-09 18:48 ` kernel test robot
2020-11-15 0:28 ` kernel test robot
2020-11-24 8:43 ` Linus Walleij
2020-11-24 8:53 ` Damien Le Moal
2020-11-29 21:33 ` Linus Walleij
2020-11-30 3:13 ` Damien Le Moal
2020-11-30 7:05 ` Serge Semin
2020-11-30 7:27 ` Damien Le Moal
2020-11-24 8:56 ` Damien Le Moal
2020-11-07 8:14 ` [PATCH 21/32] dt-bindings: Add Kendryte and Canaan vendor prefix Damien Le Moal
2020-11-07 14:03 ` Sean Anderson
2020-11-13 8:17 ` Damien Le Moal
2020-11-09 22:01 ` Rob Herring
2020-11-09 22:04 ` Damien Le Moal
2020-11-07 8:14 ` [PATCH 22/32] dt-binding: Document kendryte,k210-sysctl bindings Damien Le Moal
2020-11-07 14:05 ` Sean Anderson
2020-11-09 15:32 ` Rob Herring
2020-11-07 8:14 ` [PATCH 23/32] dt-binding: Document kendryte,k210-clk bindings Damien Le Moal
2020-11-07 14:05 ` Sean Anderson
2020-11-09 21:58 ` Rob Herring
2020-11-07 8:14 ` [PATCH 24/32] dt-bindings: Document kendryte,k210-fpioa bindings Damien Le Moal
2020-11-07 14:06 ` Sean Anderson
2020-11-09 15:32 ` Rob Herring
2020-11-09 15:36 ` Rob Herring
2020-11-09 15:45 ` Sean Anderson
2020-11-11 14:32 ` Rob Herring
2020-11-19 10:57 ` Geert Uytterhoeven
2020-11-19 11:22 ` Damien Le Moal
2020-11-07 8:14 ` [PATCH 25/32] dt-bindings: Document kendryte,k210-rst bindings Damien Le Moal
2020-11-07 14:07 ` Sean Anderson
2020-11-09 15:37 ` Rob Herring
2020-11-09 15:41 ` Rob Herring
2020-11-07 8:14 ` [PATCH 26/32] riscv: Update Kendryte K210 device tree Damien Le Moal
2020-11-07 14:08 ` Sean Anderson
2020-11-07 8:14 ` [PATCH 27/32] riscv: Add SiPeed MAIX BiT board " Damien Le Moal
2020-11-07 14:13 ` Sean Anderson
2020-11-07 8:14 ` [PATCH 28/32] riscv: Add SiPeed MAIX DOCK " Damien Le Moal
2020-11-07 8:14 ` [PATCH 29/32] riscv: Add SiPeed MAIX GO " Damien Le Moal
2020-11-07 8:14 ` [PATCH 30/32] riscv: Add SiPeed MAIXDUINO " Damien Le Moal
2020-11-07 14:14 ` Sean Anderson
2020-11-07 8:14 ` [PATCH 31/32] riscv: Add Kendryte KD233 " Damien Le Moal
2020-11-07 8:14 ` [PATCH 32/32] riscv: Update Kendryte K210 defconfig Damien Le Moal
2020-11-09 12:51 ` [PATCH 00/32] RISC-V Kendryte K210 support improvments Mark Brown
2020-11-09 12:55 ` Damien Le Moal
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=20201109201744.zlxwur4p3ejbraup@mobilestation \
--to=fancer.lancer@gmail.com \
--cc=broonie@kernel.org \
--cc=damien.lemoal@wdc.com \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=linus.walleij@linaro.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=palmer@dabbelt.com \
--cc=robh+dt@kernel.org \
--cc=sboyd@kernel.org \
--cc=seanga2@gmail.com \
/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).