linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: jiada_wang@mentor.com (Jiada Wang)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH RFC 0/5] *** SPI Slave mode support ***
Date: Tue, 25 Apr 2017 00:56:23 -0700	[thread overview]
Message-ID: <58FF0127.7070703@mentor.com> (raw)
In-Reply-To: <CAMuHMdVQS494-BAc-W-XOOLK8Xow85n+Cgih0FG+t4QxCFxhMA@mail.gmail.com>

Hi Geert

On 04/24/2017 06:10 AM, Geert Uytterhoeven wrote:
> Hi Jiada,
>
> On Mon, Apr 24, 2017 at 2:48 PM, Jiada Wang<jiada_wang@mentor.com>  wrote:
>> On 04/24/2017 03:55 AM, Geert Uytterhoeven wrote:
>>> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang<jiada_wang@mentor.com>   wrote:
>>>> On 04/13/2017 12:47 PM, Geert Uytterhoeven wrote:
>>>>> On Thu, Apr 13, 2017 at 2:59 PM, Mark Brown<broonie@kernel.org>    wrote:
>>>>>> On Thu, Apr 13, 2017 at 05:13:59AM -0700, jiada_wang at mentor.com wrote:
>>>>>>> From: Jiada Wang<jiada_wang@mentor.com>
>>>>>>>
>>>>>>> v1:
>>>>>>>      add Slave mode support in SPI core
>>>>>>>      spidev create slave device when SPI controller work in slave mode
>>>>>>>      spi-imx support to work in slave mode
>>>>>> Adding Geert who also had a series doing this in progress that was
>>>>>> getting very near to being merged.
>>>>> Thank you!
>>>>>
>>>>> Actually my plan is to fix the last remaining issues and resubmit for
>>>>> v4.13.
>>>> I noticed your patch set for SPI slave support,
>>>> (I am sure you can find out some of the change
>>>> in this patch set is based on your work).
>>>> we have similar requirement to add slave mode support to ecspi IP on imx6
>>>> Soc.
>>>>
>>>> Our use case is to use spidev as an interface to communicate with
>>>> external
>>>> SPI master devices.
>>>> meanwhile the SPI bus controller can also act as master device to send
>>>> data
>>>> to other
>>>> SPI slave devices on the board.
>>> That sounds a bit hackish to me. SPI was never meant to be a multi-master
>>> bus.
>>> While it can be done, you will need external synchronization (signals) to
>>> avoid conflicts between the SPI masters.
>> It doesn't need to be a multi-master bus,
>> for example A is master device for slave device B.
>> while B has its own slave device C
>> for each SPI connection A<=>  B, and B<=>  C, there is only one master
>> device.
>>
>> and I think from use case point of view, it's very normal,
>> one CPU upon receives command from external SPI master device,
>> it writes data to its own slave device (EEPROM) connected to it.
> So "A<=>  B" and "B<=>  C" are two distinct SPI buses?
> Or do they share some signals?
>
> Your comment seems to suggest otherwise:
the use case of
"A (master) <=> B (slave)", "B (master) <=> C(slave)", do share MISO and 
MOSI lines,
but there is no SS line between A and C. so for each SPI slave device, 
there is only one
master device.

so I think the question becomes whether the above mentioned hardware 
setup is valid or not.

Thanks,
Jiada
>>>> I found in your implementation, SPI bus controller is limited to either work in master mode or
>>>> slave mode, is there any reasoning to not configure SPI mode based on SPI devices use case?
> If they are distinct, it should work. Then B has two SPI controllers: one slave
> controller controlled by A, and one master controller to control C.
>
> Gr{oetje,eeting}s,
>
>                          Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                  -- Linus Torvalds

  reply	other threads:[~2017-04-25  7:56 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-13 12:13 [PATCH RFC 0/5] *** SPI Slave mode support *** jiada_wang at mentor.com
2017-04-13 12:14 ` [PATCH RFC 1/5] spi: core: add support to work in Slave mode jiada_wang at mentor.com
2017-04-13 12:14 ` [PATCH RFC 2/5] spi: spidev: use different name for SPI controller slave mode device jiada_wang at mentor.com
2017-04-13 12:14 ` [PATCH RFC 3/5] spi: imx: add selection for iMX53 and iMX6 controller jiada_wang at mentor.com
2017-04-13 12:14 ` [PATCH RFC 4/5] ARM: dts: imx: change compatiblity for SPI controllers on imx53 later soc jiada_wang at mentor.com
2017-04-13 12:14 ` [PATCH RFC 5/5] spi: imx: Add support for SPI Slave mode for imx53 and imx6 chips jiada_wang at mentor.com
2017-04-13 12:59 ` [PATCH RFC 0/5] *** SPI Slave mode support *** Mark Brown
2017-04-13 19:47   ` Geert Uytterhoeven
2017-04-14  5:39     ` Jiada Wang
2017-04-24 10:55       ` Geert Uytterhoeven
2017-04-24 12:48         ` Jiada Wang
2017-04-24 13:10           ` Geert Uytterhoeven
2017-04-25  7:56             ` Jiada Wang [this message]
2017-04-25  8:07               ` Uwe Kleine-König
2017-04-25  8:09               ` Geert Uytterhoeven
2017-04-25 10:31         ` Mark Brown
2017-04-27  6:43           ` Jiada Wang
2017-05-24 17:29             ` Mark Brown
2017-05-29 12:01             ` Fabio Estevam
2017-05-30  2:53               ` Jiada Wang

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=58FF0127.7070703@mentor.com \
    --to=jiada_wang@mentor.com \
    --cc=linux-arm-kernel@lists.infradead.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).