Hello,
-----Original Message----- From: Jonas Gorski jonas.gorski@gmail.com Sent: Tuesday, March 7, 2023 1:31 AM To: Mahapatra, Amit Kumar amit.kumar-mahapatra@amd.com Cc: broonie@kernel.org; miquel.raynal@bootlin.com; richard@nod.at; vigneshr@ti.com; jic23@kernel.org; tudor.ambarus@microchip.com; pratyush@kernel.org; Mehta, Sanju Sanju.Mehta@amd.com; chin- ting_kuo@aspeedtech.com; clg@kaod.org; kdasu.kdev@gmail.com; f.fainelli@gmail.com; rjui@broadcom.com; sbranden@broadcom.com; eajames@linux.ibm.com; olteanv@gmail.com; han.xu@nxp.com; john.garry@huawei.com; shawnguo@kernel.org; s.hauer@pengutronix.de; narmstrong@baylibre.com; khilman@baylibre.com; matthias.bgg@gmail.com; haibo.chen@nxp.com; linus.walleij@linaro.org; daniel@zonque.org; haojian.zhuang@gmail.com; robert.jarzmik@free.fr; agross@kernel.org; bjorn.andersson@linaro.org; heiko@sntech.de; krzysztof.kozlowski@linaro.org; andi@etezian.org; mcoquelin.stm32@gmail.com; alexandre.torgue@foss.st.com; wens@csie.org; jernej.skrabec@gmail.com; samuel@sholland.org; masahisa.kojima@linaro.org; jaswinder.singh@linaro.org; rostedt@goodmis.org; mingo@redhat.com; l.stelmach@samsung.com; davem@davemloft.net; edumazet@google.com; kuba@kernel.org; pabeni@redhat.com; alex.aring@gmail.com; stefan@datenfreihafen.org; kvalo@kernel.org; james.schulman@cirrus.com; david.rhodes@cirrus.com; tanureal@opensource.cirrus.com; rf@opensource.cirrus.com; perex@perex.cz; tiwai@suse.com; npiggin@gmail.com; christophe.leroy@csgroup.eu; mpe@ellerman.id.au; oss@buserror.net; windhl@126.com; yangyingliang@huawei.com; william.zhang@broadcom.com; kursad.oney@broadcom.com; anand.gore@broadcom.com; rafal@milecki.pl; git (AMD-Xilinx) git@amd.com; linux-spi@vger.kernel.org; linux-kernel@vger.kernel.org; joel@jms.id.au; andrew@aj.id.au; radu_nicolae.pirea@upb.ro; nicolas.ferre@microchip.com; alexandre.belloni@bootlin.com; claudiu.beznea@microchip.com; bcm-kernel-feedback-list@broadcom.com; fancer.lancer@gmail.com; kernel@pengutronix.de; festevam@gmail.com; linux-imx@nxp.com; jbrunet@baylibre.com; martin.blumenstingl@googlemail.com; avifishman70@gmail.com; tmaimon77@gmail.com; tali.perry1@gmail.com; venture@google.com; yuenn@google.com; benjaminfair@google.com; yogeshgaur.83@gmail.com; konrad.dybcio@somainline.org; alim.akhtar@samsung.com; ldewangan@nvidia.com; thierry.reding@gmail.com; jonathanh@nvidia.com; Simek, Michal michal.simek@amd.com; linux-aspeed@lists.ozlabs.org; openbmc@lists.ozlabs.org; linux-arm-kernel@lists.infradead.org; linux-rpi- kernel@lists.infradead.org; linux-amlogic@lists.infradead.org; linux- mediatek@lists.infradead.org; linux-arm-msm@vger.kernel.org; linux- rockchip@lists.infradead.org; linux-samsung-soc@vger.kernel.org; linux- stm32@st-md-mailman.stormreply.com; linux-sunxi@lists.linux.dev; linux- tegra@vger.kernel.org; netdev@vger.kernel.org; linux- wpan@vger.kernel.org; libertas-dev@lists.infradead.org; linux- wireless@vger.kernel.org; linux-mtd@lists.infradead.org; lars@metafoo.de; Michael.Hennerich@analog.com; linux-iio@vger.kernel.org; michael@walle.cc; palmer@dabbelt.com; linux-riscv@lists.infradead.org; alsa-devel@alsa-project.org; patches@opensource.cirrus.com; linuxppc- dev@lists.ozlabs.org; amitrkcian2002@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- mahapatra@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-
mahapatra@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