Hello, > -----Original Message----- > From: Jonas Gorski <jonas.gorski@xxxxxxxxx> > Sent: Tuesday, March 7, 2023 1:31 AM > To: Mahapatra, Amit Kumar <amit.kumar-mahapatra@xxxxxxx> > Cc: broonie@xxxxxxxxxx; miquel.raynal@xxxxxxxxxxx; richard@xxxxxx; > vigneshr@xxxxxx; jic23@xxxxxxxxxx; tudor.ambarus@xxxxxxxxxxxxx; > pratyush@xxxxxxxxxx; Mehta, Sanju <Sanju.Mehta@xxxxxxx>; chin- > ting_kuo@xxxxxxxxxxxxxx; clg@xxxxxxxx; kdasu.kdev@xxxxxxxxx; > f.fainelli@xxxxxxxxx; rjui@xxxxxxxxxxxx; sbranden@xxxxxxxxxxxx; > eajames@xxxxxxxxxxxxx; olteanv@xxxxxxxxx; han.xu@xxxxxxx; > john.garry@xxxxxxxxxx; shawnguo@xxxxxxxxxx; s.hauer@xxxxxxxxxxxxxx; > narmstrong@xxxxxxxxxxxx; khilman@xxxxxxxxxxxx; > matthias.bgg@xxxxxxxxx; haibo.chen@xxxxxxx; linus.walleij@xxxxxxxxxx; > daniel@xxxxxxxxxx; haojian.zhuang@xxxxxxxxx; robert.jarzmik@xxxxxxx; > agross@xxxxxxxxxx; bjorn.andersson@xxxxxxxxxx; heiko@xxxxxxxxx; > krzysztof.kozlowski@xxxxxxxxxx; andi@xxxxxxxxxxx; > mcoquelin.stm32@xxxxxxxxx; alexandre.torgue@xxxxxxxxxxx; > wens@xxxxxxxx; jernej.skrabec@xxxxxxxxx; samuel@xxxxxxxxxxxx; > masahisa.kojima@xxxxxxxxxx; jaswinder.singh@xxxxxxxxxx; > rostedt@xxxxxxxxxxx; mingo@xxxxxxxxxx; l.stelmach@xxxxxxxxxxx; > davem@xxxxxxxxxxxxx; edumazet@xxxxxxxxxx; kuba@xxxxxxxxxx; > pabeni@xxxxxxxxxx; alex.aring@xxxxxxxxx; stefan@xxxxxxxxxxxxxxxxxx; > kvalo@xxxxxxxxxx; james.schulman@xxxxxxxxxx; david.rhodes@xxxxxxxxxx; > tanureal@xxxxxxxxxxxxxxxxxxxxx; rf@xxxxxxxxxxxxxxxxxxxxx; > perex@xxxxxxxx; tiwai@xxxxxxxx; npiggin@xxxxxxxxx; > christophe.leroy@xxxxxxxxxx; mpe@xxxxxxxxxxxxxx; oss@xxxxxxxxxxxx; > windhl@xxxxxxx; yangyingliang@xxxxxxxxxx; > william.zhang@xxxxxxxxxxxx; kursad.oney@xxxxxxxxxxxx; > anand.gore@xxxxxxxxxxxx; rafal@xxxxxxxxxx; git (AMD-Xilinx) > <git@xxxxxxx>; linux-spi@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > joel@xxxxxxxxx; andrew@xxxxxxxx; radu_nicolae.pirea@xxxxxx; > nicolas.ferre@xxxxxxxxxxxxx; alexandre.belloni@xxxxxxxxxxx; > claudiu.beznea@xxxxxxxxxxxxx; bcm-kernel-feedback-list@xxxxxxxxxxxx; > fancer.lancer@xxxxxxxxx; kernel@xxxxxxxxxxxxxx; festevam@xxxxxxxxx; > linux-imx@xxxxxxx; jbrunet@xxxxxxxxxxxx; > martin.blumenstingl@xxxxxxxxxxxxxx; avifishman70@xxxxxxxxx; > tmaimon77@xxxxxxxxx; tali.perry1@xxxxxxxxx; venture@xxxxxxxxxx; > yuenn@xxxxxxxxxx; benjaminfair@xxxxxxxxxx; yogeshgaur.83@xxxxxxxxx; > konrad.dybcio@xxxxxxxxxxxxxx; alim.akhtar@xxxxxxxxxxx; > ldewangan@xxxxxxxxxx; thierry.reding@xxxxxxxxx; jonathanh@xxxxxxxxxx; > Simek, Michal <michal.simek@xxxxxxx>; linux-aspeed@xxxxxxxxxxxxxxxx; > openbmc@xxxxxxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx; linux-rpi- > kernel@xxxxxxxxxxxxxxxxxxx; linux-amlogic@xxxxxxxxxxxxxxxxxxx; linux- > mediatek@xxxxxxxxxxxxxxxxxxx; linux-arm-msm@xxxxxxxxxxxxxxx; linux- > rockchip@xxxxxxxxxxxxxxxxxxx; linux-samsung-soc@xxxxxxxxxxxxxxx; linux- > stm32@xxxxxxxxxxxxxxxxxxxxxxxxxxxx; linux-sunxi@xxxxxxxxxxxxxxx; linux- > tegra@xxxxxxxxxxxxxxx; netdev@xxxxxxxxxxxxxxx; linux- > wpan@xxxxxxxxxxxxxxx; libertas-dev@xxxxxxxxxxxxxxxxxxx; linux- > wireless@xxxxxxxxxxxxxxx; linux-mtd@xxxxxxxxxxxxxxxxxxx; lars@xxxxxxxxxx; > Michael.Hennerich@xxxxxxxxxx; linux-iio@xxxxxxxxxxxxxxx; > michael@xxxxxxxx; palmer@xxxxxxxxxxx; linux-riscv@xxxxxxxxxxxxxxxxxxx; > alsa-devel@xxxxxxxxxxxxxxxx; patches@xxxxxxxxxxxxxxxxxxxxx; linuxppc- > dev@xxxxxxxxxxxxxxxx; amitrkcian2002@xxxxxxxxx > 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- > mahapatra@xxxxxxx> 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- > mahapatra@xxxxxxx> > > --- > > 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
