Hello, > -----Original Message----- > From: Jonas Gorski <jonas.gor...@gmail.com> > Sent: Tuesday, March 7, 2023 1:31 AM > To: Mahapatra, Amit Kumar <amit.kumar-mahapa...@amd.com> > Cc: broo...@kernel.org; miquel.ray...@bootlin.com; rich...@nod.at; > vigne...@ti.com; ji...@kernel.org; tudor.amba...@microchip.com; > praty...@kernel.org; Mehta, Sanju <sanju.me...@amd.com>; chin- > ting_...@aspeedtech.com; c...@kaod.org; kdasu.k...@gmail.com; > f.faine...@gmail.com; r...@broadcom.com; sbran...@broadcom.com; > eaja...@linux.ibm.com; olte...@gmail.com; han...@nxp.com; > john.ga...@huawei.com; shawn...@kernel.org; s.ha...@pengutronix.de; > narmstr...@baylibre.com; khil...@baylibre.com; > matthias....@gmail.com; haibo.c...@nxp.com; linus.wall...@linaro.org; > dan...@zonque.org; haojian.zhu...@gmail.com; robert.jarz...@free.fr; > agr...@kernel.org; bjorn.anders...@linaro.org; he...@sntech.de; > krzysztof.kozlow...@linaro.org; a...@etezian.org; > mcoquelin.st...@gmail.com; alexandre.tor...@foss.st.com; > w...@csie.org; jernej.skra...@gmail.com; sam...@sholland.org; > masahisa.koj...@linaro.org; jaswinder.si...@linaro.org; > rost...@goodmis.org; mi...@redhat.com; l.stelm...@samsung.com; > da...@davemloft.net; eduma...@google.com; k...@kernel.org; > pab...@redhat.com; alex.ar...@gmail.com; ste...@datenfreihafen.org; > kv...@kernel.org; james.schul...@cirrus.com; david.rho...@cirrus.com; > tanur...@opensource.cirrus.com; r...@opensource.cirrus.com; > pe...@perex.cz; ti...@suse.com; npig...@gmail.com; > christophe.le...@csgroup.eu; m...@ellerman.id.au; o...@buserror.net; > win...@126.com; yangyingli...@huawei.com; > william.zh...@broadcom.com; kursad.o...@broadcom.com; > anand.g...@broadcom.com; ra...@milecki.pl; git (AMD-Xilinx) > <g...@amd.com>; linux-...@vger.kernel.org; linux-ker...@vger.kernel.org; > j...@jms.id.au; and...@aj.id.au; radu_nicolae.pi...@upb.ro; > nicolas.fe...@microchip.com; alexandre.bell...@bootlin.com; > claudiu.bez...@microchip.com; bcm-kernel-feedback-l...@broadcom.com; > fancer.lan...@gmail.com; ker...@pengutronix.de; feste...@gmail.com; > linux-...@nxp.com; jbru...@baylibre.com; > martin.blumensti...@googlemail.com; avifishma...@gmail.com; > tmaimo...@gmail.com; tali.per...@gmail.com; vent...@google.com; > yu...@google.com; benjaminf...@google.com; yogeshgaur...@gmail.com; > konrad.dyb...@somainline.org; alim.akh...@samsung.com; > ldewan...@nvidia.com; thierry.red...@gmail.com; jonath...@nvidia.com; > Simek, Michal <michal.si...@amd.com>; linux-asp...@lists.ozlabs.org; > open...@lists.ozlabs.org; linux-arm-ker...@lists.infradead.org; linux-rpi- > ker...@lists.infradead.org; linux-amlo...@lists.infradead.org; linux- > media...@lists.infradead.org; linux-arm-...@vger.kernel.org; linux- > rockc...@lists.infradead.org; linux-samsung-...@vger.kernel.org; linux- > st...@st-md-mailman.stormreply.com; linux-su...@lists.linux.dev; linux- > te...@vger.kernel.org; net...@vger.kernel.org; linux- > w...@vger.kernel.org; libertas-...@lists.infradead.org; linux- > wirel...@vger.kernel.org; linux-...@lists.infradead.org; l...@metafoo.de; > michael.henner...@analog.com; linux-...@vger.kernel.org; > mich...@walle.cc; pal...@dabbelt.com; linux-ri...@lists.infradead.org; > alsa-de...@alsa-project.org; patc...@opensource.cirrus.com; linuxppc- > d...@lists.ozlabs.org; amitrkcian2...@gmail.com > Subject: Re: [PATCH V5 09/15] spi: Add stacked and parallel memories > support in SPI core > > Hi, > > On Mon, 6 Mar 2023 at 18:26, Amit Kumar Mahapatra <amit.kumar- > mahapa...@amd.com> wrote: > > > > For supporting multiple CS the SPI device need to be aware of all the > > CS values. So, the "chip_select" member in the spi_device structure is > > now an array that holds all the CS values. > > > > spi_device structure now has a "cs_index_mask" member. This acts as an > > index to the chip_select array. If nth bit of spi->cs_index_mask is > > set then the driver would assert spi->chip_select[n]. > > > > In parallel mode all the chip selects are asserted/de-asserted > > simultaneously and each byte of data is stored in both devices, the > > even bits in one, the odd bits in the other. The split is > > automatically handled by the GQSPI controller. The GQSPI controller > > supports a maximum of two flashes connected in parallel mode. A > > "multi-cs-cap" flag is added in the spi controntroller data, through > > ctlr->multi-cs-cap the spi core will make sure that the controller is > > capable of handling multiple chip selects at once. > > > > For supporting multiple CS via GPIO the cs_gpiod member of the > > spi_device structure is now an array that holds the gpio descriptor > > for each chipselect. > > > > Multi CS support using GPIO is not tested due to unavailability of > > necessary hardware setup. > > > > Signed-off-by: Amit Kumar Mahapatra <amit.kumar- > mahapa...@amd.com> > > --- > > drivers/spi/spi.c | 213 +++++++++++++++++++++++++++------------- > > include/linux/spi/spi.h | 34 +++++-- > > 2 files changed, 173 insertions(+), 74 deletions(-) > > > > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index > > 5866bf5813a4..8ec7f58fa111 100644 > > --- a/drivers/spi/spi.c > > +++ b/drivers/spi/spi.c > > @@ -613,7 +613,8 @@ static int spi_dev_check(struct device *dev, void > *data) > > struct spi_device *new_spi = data; > > > > if (spi->controller == new_spi->controller && > > - spi_get_chipselect(spi, 0) == spi_get_chipselect(new_spi, 0)) > > + spi_get_chipselect(spi, 0) == spi_get_chipselect(new_spi, 0) && > > + spi_get_chipselect(spi, 1) == spi_get_chipselect(new_spi, > > + 1)) > > return -EBUSY; > > This will only reject new devices if both chip selects are identical, but not > if > they only share one, e.g. CS 1 + 2 vs 1 + 3, or 1 + 2 vs only 2, or if the > order is > different (1 + 2 vs 2 + 1 - haven't read the code too close to know if this is > allowed/possible).
Agreed, will add in the next series. Regards, Amit > > Regards, > Jonas
