From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1428345AbdDYIMa (ORCPT ); Tue, 25 Apr 2017 04:12:30 -0400 Received: from mail-io0-f171.google.com ([209.85.223.171]:36794 "EHLO mail-io0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1176427AbdDYIJm (ORCPT ); Tue, 25 Apr 2017 04:09:42 -0400 MIME-Version: 1.0 In-Reply-To: <58FF0127.7070703@mentor.com> References: <1492085644-4195-1-git-send-email-jiada_wang@mentor.com> <20170413125929.dygodgj6c35ydh5p@sirena.org.uk> <58F06092.9080409@mentor.com> <58FDF430.5090306@mentor.com> <58FF0127.7070703@mentor.com> From: Geert Uytterhoeven Date: Tue, 25 Apr 2017 10:09:39 +0200 X-Google-Sender-Auth: 4JctCrkJROtbi6aaCf1yci2nB5U Message-ID: Subject: Re: [PATCH RFC 0/5] *** SPI Slave mode support *** To: Jiada Wang Cc: Mark Brown , Rob Herring , Mark Rutland , Shawn Guo , Sascha Hauer , Fabio Estevam , linux-spi , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jiada, On Tue, Apr 25, 2017 at 9:56 AM, Jiada Wang wrote: > On 04/24/2017 06:10 AM, Geert Uytterhoeven wrote: >> On Mon, Apr 24, 2017 at 2:48 PM, Jiada Wang wrote: >>> On 04/24/2017 03:55 AM, Geert Uytterhoeven wrote: >>>> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang >>>> wrote: >>>>> 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. Do you share CLK, too? Then you need a slave select from B to C. If you use a separate clock, the slave select from B to C can be optional. > so I think the question becomes whether the above mentioned hardware setup > is valid or not. It's a non-conventional SPI bus setup, but it can work, provided you have some form of synchronization between A and B. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Geert Uytterhoeven Subject: Re: [PATCH RFC 0/5] *** SPI Slave mode support *** Date: Tue, 25 Apr 2017 10:09:39 +0200 Message-ID: References: <1492085644-4195-1-git-send-email-jiada_wang@mentor.com> <20170413125929.dygodgj6c35ydh5p@sirena.org.uk> <58F06092.9080409@mentor.com> <58FDF430.5090306@mentor.com> <58FF0127.7070703@mentor.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <58FF0127.7070703@mentor.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Jiada Wang Cc: Mark Rutland , "devicetree@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Rob Herring , linux-spi , Mark Brown , Sascha Hauer , Fabio Estevam , Shawn Guo , "linux-arm-kernel@lists.infradead.org" List-Id: devicetree@vger.kernel.org Hi Jiada, On Tue, Apr 25, 2017 at 9:56 AM, Jiada Wang wrote: > On 04/24/2017 06:10 AM, Geert Uytterhoeven wrote: >> On Mon, Apr 24, 2017 at 2:48 PM, Jiada Wang wrote: >>> On 04/24/2017 03:55 AM, Geert Uytterhoeven wrote: >>>> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang >>>> wrote: >>>>> 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. Do you share CLK, too? Then you need a slave select from B to C. If you use a separate clock, the slave select from B to C can be optional. > so I think the question becomes whether the above mentioned hardware setup > is valid or not. It's a non-conventional SPI bus setup, but it can work, provided you have some form of synchronization between A and B. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: geert@linux-m68k.org (Geert Uytterhoeven) Date: Tue, 25 Apr 2017 10:09:39 +0200 Subject: [PATCH RFC 0/5] *** SPI Slave mode support *** In-Reply-To: <58FF0127.7070703@mentor.com> References: <1492085644-4195-1-git-send-email-jiada_wang@mentor.com> <20170413125929.dygodgj6c35ydh5p@sirena.org.uk> <58F06092.9080409@mentor.com> <58FDF430.5090306@mentor.com> <58FF0127.7070703@mentor.com> Message-ID: To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org Hi Jiada, On Tue, Apr 25, 2017 at 9:56 AM, Jiada Wang wrote: > On 04/24/2017 06:10 AM, Geert Uytterhoeven wrote: >> On Mon, Apr 24, 2017 at 2:48 PM, Jiada Wang wrote: >>> On 04/24/2017 03:55 AM, Geert Uytterhoeven wrote: >>>> On Fri, Apr 14, 2017 at 7:39 AM, Jiada Wang >>>> wrote: >>>>> 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. Do you share CLK, too? Then you need a slave select from B to C. If you use a separate clock, the slave select from B to C can be optional. > so I think the question becomes whether the above mentioned hardware setup > is valid or not. It's a non-conventional SPI bus setup, but it can work, provided you have some form of synchronization between A and B. 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