All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonas Gorski <jonas.gorski@gmail.com>
To: Amit Kumar Mahapatra <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, 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.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, 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
Date: Mon, 6 Mar 2023 21:00:44 +0100	[thread overview]
Message-ID: <CAOiHx=nmsAh3ADL3s0eZKpEZJqCB_POi=8YjfxrHYLEbjRfwHg@mail.gmail.com> (raw)
In-Reply-To: <20230306172109.595464-10-amit.kumar-mahapatra@amd.com>

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).

Regards,
Jonas

WARNING: multiple messages have this Message-ID (diff)
From: Jonas Gorski <jonas.gorski@gmail.com>
To: Amit Kumar Mahapatra <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, 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,
	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.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, 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
Date: Mon, 6 Mar 2023 21:00:44 +0100	[thread overview]
Message-ID: <CAOiHx=nmsAh3ADL3s0eZKpEZJqCB_POi=8YjfxrHYLEbjRfwHg@mail.gmail.com> (raw)
In-Reply-To: <20230306172109.595464-10-amit.kumar-mahapatra@amd.com>

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).

Regards,
Jonas

WARNING: multiple messages have this Message-ID (diff)
From: Jonas Gorski <jonas.gorski@gmail.com>
To: Amit Kumar Mahapatra <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, 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.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, 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
Date: Mon, 6 Mar 2023 21:00:44 +0100	[thread overview]
Message-ID: <CAOiHx=nmsAh3ADL3s0eZKpEZJqCB_POi=8YjfxrHYLEbjRfwHg@mail.gmail.com> (raw)
In-Reply-To: <20230306172109.595464-10-amit.kumar-mahapatra@amd.com>

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).

Regards,
Jonas

______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/

WARNING: multiple messages have this Message-ID (diff)
From: Jonas Gorski <jonas.gorski@gmail.com>
To: Amit Kumar Mahapatra <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, 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.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, 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
Date: Mon, 6 Mar 2023 21:00:44 +0100	[thread overview]
Message-ID: <CAOiHx=nmsAh3ADL3s0eZKpEZJqCB_POi=8YjfxrHYLEbjRfwHg@mail.gmail.com> (raw)
In-Reply-To: <20230306172109.595464-10-amit.kumar-mahapatra@amd.com>

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).

Regards,
Jonas

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

WARNING: multiple messages have this Message-ID (diff)
From: Jonas Gorski <jonas.gorski@gmail.com>
To: Amit Kumar Mahapatra <amit.kumar-mahapatra@amd.com>
Cc: kursad.oney@broadcom.com, heiko@sntech.de,
	linus.walleij@linaro.org, eajames@linux.ibm.com, perex@perex.cz,
	alim.akhtar@samsung.com, miquel.raynal@bootlin.com,
	rafal@milecki.pl, linux-stm32@st-md-mailman.stormreply.com,
	stefan@datenfreihafen.org, tmaimon77@gmail.com,
	linux-samsung-soc@vger.kernel.org, samuel@sholland.org,
	tiwai@suse.com, haibo.chen@nxp.com, mingo@redhat.com,
	linux-imx@nxp.com, linux-sunxi@lists.linux.dev,
	anand.gore@broadcom.com, s.hauer@pengutronix.de,
	l.stelmach@samsung.com, npiggin@gmail.com,
	james.schulman@cirrus.com, Sanju.Mehta@amd.com,
	sbranden@broadcom.com, andrew@aj.id.au,
	linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-spi@vger.kernel.org, yogeshgaur.83@gmail.com,
	michael@walle.cc, kernel@pengutronix.de, olteanv@gmail.com,
	linux-wpan@vger.kernel.org, claudiu.beznea@microchip.com,
	alexandre.belloni@bootlin.com, tanureal@opensource.cirrus.com,
	david.rhodes@cirrus.com, edumazet@google.com,
	ldewangan@nvidia.com, windhl@126.com, lars@meta foo.de,
	jonathanh@nvidia.com, linux-rockchip@lists.infradead.org,
	jbrunet@baylibre.com, andi@etezian.org,
	Michael.Hennerich@analog.com, martin.blumenstingl@googlemail.com,
	linux-arm-msm@vger.kernel.org, radu_nicolae.pirea@upb.ro,
	haojian.zhuang@gmail.com, jaswinder.singh@linaro.org,
	clg@kaod.org, linux-amlogic@lists.infradead.org,
	michal.simek@amd.com, linux-arm-kernel@lists.infradead.org,
	libertas-dev@lists.infradead.org, mcoquelin.stm32@gmail.com,
	khilman@baylibre.com, jic23@kernel.org,
	linux-rpi-kernel@lists.infradead.org, narmstrong@baylibre.com,
	linux-iio@vger.kernel.org, alsa-devel@alsa-project.org,
	linux-tegra@vger.kernel.org, patches@opensource.cirrus.com,
	linux-mtd@lists.infradead.org, masahisa.kojima@linaro.org,
	festevam@gmail.com, linux-aspeed@lists.ozlabs.org, git@amd.com,
	f.fainelli@gmail.com, benjaminfair@google.com,
	jernej.skrabec@gmail.com, yuenn@google.com, wens@csie.org,
	bcm-kernel-feedback-list@broadcom.com, joel@jms.id.au,
	yangyingliang@huawei.com, pabeni@redhat. com,
	amitrkcian2002@gmail.com, william.zhang@broadcom.com,
	rjui@broadcom.com, john.garry@huawei.com, rostedt@goodmis.org,
	rf@opensource.cirrus.com, broonie@kernel.org,
	tali.perry1@gmail.com, avifishman70@gmail.com,
	thierry.reding@gmail.com, netdev@vger.kernel.org,
	shawnguo@kernel.org, davem@davemloft.net, alex.aring@gmail.com,
	vigneshr@ti.com, konrad.dybcio@somainline.org,
	alexandre.torgue@foss.st.com, bjorn.andersson@linaro.org,
	linux-riscv@lists.infradead.org, robert.jarzmik@free.fr,
	kdasu.kdev@gmail.com, richard@nod.at,
	chin-ting_kuo@aspeedtech.com, agross@kernel.org, kuba@kernel.org,
	tudor.ambarus@microchip.com, kvalo@kernel.org,
	linux-mediatek@lists.infradead.org, matthias.bgg@gmail.com,
	han.xu@nxp.com, oss@buserror.net, venture@google.com,
	nicolas.ferre@microchip.com, fancer.lancer@gmail.com,
	krzysztof.kozlowski@linaro.org, palmer@dabbelt.com,
	pratyush@kernel.org, linuxppc-dev@lists.ozlabs.org,
	openbmc@lists.ozlabs.org, daniel@zonque.org
Subject: Re: [PATCH V5 09/15] spi: Add stacked and parallel memories support in SPI core
Date: Mon, 6 Mar 2023 21:00:44 +0100	[thread overview]
Message-ID: <CAOiHx=nmsAh3ADL3s0eZKpEZJqCB_POi=8YjfxrHYLEbjRfwHg@mail.gmail.com> (raw)
In-Reply-To: <20230306172109.595464-10-amit.kumar-mahapatra@amd.com>

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).

Regards,
Jonas

WARNING: multiple messages have this Message-ID (diff)
From: Jonas Gorski <jonas.gorski@gmail.com>
To: Amit Kumar Mahapatra <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, 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.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, 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
Date: Mon, 6 Mar 2023 21:00:44 +0100	[thread overview]
Message-ID: <CAOiHx=nmsAh3ADL3s0eZKpEZJqCB_POi=8YjfxrHYLEbjRfwHg@mail.gmail.com> (raw)
In-Reply-To: <20230306172109.595464-10-amit.kumar-mahapatra@amd.com>

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).

Regards,
Jonas

_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic

  reply	other threads:[~2023-03-06 20:00 UTC|newest]

Thread overview: 134+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-06 17:20 [PATCH V5 00/15] spi: Add support for stacked/parallel memories Amit Kumar Mahapatra
2023-03-06 17:20 ` Amit Kumar Mahapatra
2023-03-06 17:20 ` Amit Kumar Mahapatra
2023-03-06 17:20 ` Amit Kumar Mahapatra
2023-03-06 17:20 ` Amit Kumar Mahapatra
2023-03-06 17:20 ` Amit Kumar Mahapatra
2023-03-06 17:20 ` [PATCH V5 01/15] spi: Replace all spi->chip_select and spi->cs_gpiod references with function call Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:32   ` Mark Brown
2023-03-06 17:32     ` Mark Brown
2023-03-06 17:32     ` Mark Brown
2023-03-06 17:32     ` Mark Brown
2023-03-06 17:32     ` Mark Brown
2023-03-06 17:32     ` Mark Brown
2023-03-06 21:27   ` Mark Brown
2023-03-06 21:27     ` Mark Brown
2023-03-06 21:27     ` Mark Brown
2023-03-06 21:27     ` Mark Brown
2023-03-06 21:27     ` Mark Brown
2023-03-06 21:27     ` Mark Brown
2023-03-06 17:20 ` [PATCH V5 02/15] net: " Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
     [not found]   ` <CGME20230315133446eucas1p2e6acaf7a67368b99022b1dca5ef25a17@eucas1p2.samsung.com>
2023-03-15 13:34     ` Lukasz Stelmach
2023-03-06 17:20 ` [PATCH V5 03/15] iio: imu: " Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20 ` [PATCH V5 04/15] mtd: devices: " Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20 ` [PATCH V5 05/15] staging: " Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:20   ` Amit Kumar Mahapatra
2023-03-06 17:21 ` [PATCH V5 06/15] platform/x86: serial-multi-instantiate: " Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21 ` [PATCH V5 07/15] powerpc/83xx/mpc832x_rdb: Replace all spi->chip_select " Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21 ` [PATCH V5 08/15] ALSA: hda: cs35l41: " Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21 ` [PATCH V5 09/15] spi: Add stacked and parallel memories support in SPI core Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 20:00   ` Jonas Gorski [this message]
2023-03-06 20:00     ` Jonas Gorski
2023-03-06 20:00     ` Jonas Gorski
2023-03-06 20:00     ` Jonas Gorski
2023-03-06 20:00     ` Jonas Gorski
2023-03-06 20:00     ` Jonas Gorski
2023-03-07 11:09     ` Mahapatra, Amit Kumar
2023-03-07 11:09       ` Mahapatra, Amit Kumar
2023-03-07 11:09       ` Mahapatra, Amit Kumar
2023-03-07 11:09       ` Mahapatra, Amit Kumar
2023-03-07 11:09       ` Mahapatra, Amit Kumar
2023-03-07 11:09     ` Mahapatra, Amit Kumar via Alsa-devel
2023-03-07  4:21   ` Tudor Ambarus
2023-03-07  4:21     ` Tudor Ambarus
2023-03-07 11:37     ` Mahapatra, Amit Kumar
2023-03-07 11:37       ` Mahapatra, Amit Kumar
2023-03-07 11:47       ` Tudor Ambarus
2023-03-07 11:47         ` Tudor Ambarus
2023-03-07 14:01         ` Mark Brown
2023-03-07 14:01           ` Mark Brown
2023-03-06 17:21 ` [PATCH V5 10/15] mtd: spi-nor: Convert macros with inline functions Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21 ` [PATCH V5 11/15] mtd: spi-nor: Add APIs to set/get nor->params Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21 ` [PATCH V5 12/15] mtd: spi-nor: Add stacked memories support in spi-nor Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21 ` [PATCH V5 13/15] spi: spi-zynqmp-gqspi: Add stacked memories support in GQSPI driver Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21 ` [PATCH V5 14/15] mtd: spi-nor: Add parallel memories support in spi-nor Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21 ` [PATCH V5 15/15] spi: spi-zynqmp-gqspi: Add parallel memories support in GQSPI driver Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-06 17:21   ` Amit Kumar Mahapatra
2023-03-13 16:49 ` (subset) [PATCH V5 00/15] spi: Add support for stacked/parallel memories Mark Brown
2023-03-13 16:49   ` Mark Brown
2023-03-13 16:49   ` Mark Brown
2023-03-13 16:49   ` Mark Brown
2023-03-13 16:49   ` Mark Brown

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