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

Hello,

> -----Original Message-----
> From: Jonas Gorski <jonas.gorski@gmail.com>
> Sent: Sunday, March 12, 2023 9:30 PM
> 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 V6 09/15] spi: Add stacked and parallel memories
> support in SPI core
> 
> Hi,
> 
> On Fri, 10 Mar 2023 at 18:37, 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.
> 
> Can you pinmux your SPI controller's (cs) pins as GPIO? If so, you should be
> able use that for testing.
> 

Xilinx Controller drivers that support multi cs are registered under 
spi-mem framework. So even if I modify the pinmux the chip selection 
will not go through the SPI core. 
So, we cannot test the CS GPIO changes in SPI core on our platforms.

> >
> > Signed-off-by: Amit Kumar Mahapatra <amit.kumar-
> mahapatra@amd.com>
> > ---
> >  drivers/spi/spi.c       | 225 +++++++++++++++++++++++++++-------------
> >  include/linux/spi/spi.h |  34 ++++--
> >  2 files changed, 182 insertions(+), 77 deletions(-)
> >
> > diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index
> > c725b4bab7af..742bd688381c 100644
> > --- a/drivers/spi/spi.c
> > +++ b/drivers/spi/spi.c
> > @@ -612,10 +612,17 @@ static int spi_dev_check(struct device *dev,
> > void *data)  {
> >         struct spi_device *spi = to_spi_device(dev);
> >         struct spi_device *new_spi = data;
> > -
> > -       if (spi->controller == new_spi->controller &&
> > -           spi_get_chipselect(spi, 0) == spi_get_chipselect(new_spi, 0))
> > -               return -EBUSY;
> > +       int idx, nw_idx;
> > +
> > +       if (spi->controller == new_spi->controller) {
> > +               for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) {
> > +                       for (nw_idx = 0; nw_idx < SPI_CS_CNT_MAX; nw_idx++) {
> > +                               if (spi_get_chipselect(spi, idx) ==
> > +                                   spi_get_chipselect(new_spi, nw_idx))
> > +                                       return -EBUSY;
> > +                       }
> > +               }
> 
> AFAICT unused chip selects are initialized to 0, so all single chip select devices
> would have it as their second one. This will then cause this check to reject
> every single chip select device after the first one. So you first need to make
> sure to only compare valid chip selects.
> 
> So the loop condition should be something along idx <
> spi_get_num_chipselect(), not idx < SPI_CS_CNT_MAX.
> 

Agreed, will update the loop condition as per num_cs.

> > +       }
> >         return 0;
> >  }
> >
> > @@ -629,7 +636,7 @@ static int __spi_add_device(struct spi_device
> > *spi)  {
> >         struct spi_controller *ctlr = spi->controller;
> >         struct device *dev = ctlr->dev.parent;
> > -       int status;
> > +       int status, idx;
> >
> >         /*
> >          * We need to make sure there's no other device with this @@
> > -638,8 +645,7 @@ static int __spi_add_device(struct spi_device *spi)
> >          */
> >         status = bus_for_each_dev(&spi_bus_type, NULL, spi, spi_dev_check);
> >         if (status) {
> > -               dev_err(dev, "chipselect %d already in use\n",
> > -                               spi_get_chipselect(spi, 0));
> > +               dev_err(dev, "chipselect %d already in use\n",
> > + spi_get_chipselect(spi, 0));
> 
> The message might be misleading for multi cs devices where the first one is
> free, but the second one is already in use.
> 
> So maybe move this error message into spi_dev_check(), where you have
> that information available. You then even have the chance to state what is
> using the CS then, but that might be something for a different patch.
> 
> 

Agreed, I will move the error message to spi_dev_check().

> >                 return status;
> >         }
> >
> > @@ -649,8 +655,10 @@ static int __spi_add_device(struct spi_device *spi)
> >                 return -ENODEV;
> >         }
> >
> > -       if (ctlr->cs_gpiods)
> > -               spi_set_csgpiod(spi, 0, ctlr->cs_gpiods[spi_get_chipselect(spi, 0)]);
> > +       if (ctlr->cs_gpiods) {
> > +               for (idx = 0; idx < SPI_CS_CNT_MAX; idx++)
> > +                       spi_set_csgpiod(spi, idx, ctlr-
> >cs_gpiods[spi_get_chipselect(spi, idx)]);
> > +       }
> >
> >         /*
> >          * Drivers may modify this initial i/o setup, but will @@
> > -690,13 +698,15 @@ int spi_add_device(struct spi_device *spi)  {
> >         struct spi_controller *ctlr = spi->controller;
> >         struct device *dev = ctlr->dev.parent;
> > -       int status;
> > +       int status, idx;
> >
> > -       /* Chipselects are numbered 0..max; validate. */
> > -       if (spi_get_chipselect(spi, 0) >= ctlr->num_chipselect) {
> > -               dev_err(dev, "cs%d >= max %d\n", spi_get_chipselect(spi, 0),
> > -                       ctlr->num_chipselect);
> > -               return -EINVAL;
> > +       for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) {
> > +               /* Chipselects are numbered 0..max; validate. */
> > +               if (spi_get_chipselect(spi, idx) >= ctlr->num_chipselect) {
> > +                       dev_err(dev, "cs%d >= max %d\n", spi_get_chipselect(spi,
> idx),
> > +                               ctlr->num_chipselect);
> > +                       return -EINVAL;
> > +               }
> >         }
> >
> >         /* Set the bus ID string */
> > @@ -713,12 +723,15 @@ static int spi_add_device_locked(struct
> > spi_device *spi)  {
> >         struct spi_controller *ctlr = spi->controller;
> >         struct device *dev = ctlr->dev.parent;
> > +       int idx;
> >
> > -       /* Chipselects are numbered 0..max; validate. */
> > -       if (spi_get_chipselect(spi, 0) >= ctlr->num_chipselect) {
> > -               dev_err(dev, "cs%d >= max %d\n", spi_get_chipselect(spi, 0),
> > -                       ctlr->num_chipselect);
> > -               return -EINVAL;
> > +       for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) {
> > +               /* Chipselects are numbered 0..max; validate. */
> > +               if (spi_get_chipselect(spi, idx) >= ctlr->num_chipselect) {
> > +                       dev_err(dev, "cs%d >= max %d\n", spi_get_chipselect(spi,
> idx),
> > +                               ctlr->num_chipselect);
> > +                       return -EINVAL;
> > +               }
> >         }
> >
> >         /* Set the bus ID string */
> > @@ -966,58 +979,119 @@ static void spi_res_release(struct
> > spi_controller *ctlr, struct spi_message *mes  static void
> > spi_set_cs(struct spi_device *spi, bool enable, bool force)  {
> >         bool activate = enable;
> > +       u32 cs_num = __ffs(spi->cs_index_mask);
> > +       int idx;
> >
> >         /*
> > -        * Avoid calling into the driver (or doing delays) if the chip select
> > -        * isn't actually changing from the last time this was called.
> > +        * In parallel mode all the chip selects are asserted/de-asserted
> > +        * at once
> >          */
> > -       if (!force && ((enable && spi->controller->last_cs ==
> spi_get_chipselect(spi, 0)) ||
> > -                      (!enable && spi->controller->last_cs != spi_get_chipselect(spi,
> 0))) &&
> > -           (spi->controller->last_cs_mode_high == (spi->mode &
> SPI_CS_HIGH)))
> > -               return;
> > -
> > -       trace_spi_set_cs(spi, activate);
> > -
> > -       spi->controller->last_cs = enable ? spi_get_chipselect(spi, 0) : -1;
> > -       spi->controller->last_cs_mode_high = spi->mode & SPI_CS_HIGH;
> > -
> > -       if ((spi_get_csgpiod(spi, 0) || !spi->controller->set_cs_timing) &&
> !activate)
> > -               spi_delay_exec(&spi->cs_hold, NULL);
> > -
> > -       if (spi->mode & SPI_CS_HIGH)
> > -               enable = !enable;
> > +       if ((spi->cs_index_mask & SPI_PARALLEL_CS_MASK) ==
> SPI_PARALLEL_CS_MASK) {
> > +               spi->controller->last_cs_mode_high = spi->mode &
> > + SPI_CS_HIGH;
> > +
> > +               if ((spi_get_csgpiod(spi, 0) || !spi->controller->set_cs_timing) &&
> !activate)
> > +                       spi_delay_exec(&spi->cs_hold, NULL);
> > +
> > +               if (spi->mode & SPI_CS_HIGH)
> > +                       enable = !enable;
> > +
> > +               if (spi_get_csgpiod(spi, 0) && spi_get_csgpiod(spi, 1)) {
> > +                       if (!(spi->mode & SPI_NO_CS)) {
> > +                               /*
> > +                                * Historically ACPI has no means of the GPIO polarity
> and
> > +                                * thus the SPISerialBus() resource defines it on the per-
> chip
> > +                                * basis. In order to avoid a chain of negations, the GPIO
> > +                                * polarity is considered being Active High. Even for the
> cases
> > +                                * when _DSD() is involved (in the updated versions of
> ACPI)
> > +                                * the GPIO CS polarity must be defined Active High to
> avoid
> > +                                * ambiguity. That's why we use enable, that takes
> SPI_CS_HIGH
> > +                                * into account.
> > +                                */
> > +                               if (has_acpi_companion(&spi->dev)) {
> > +                                       for (idx = 0; idx < SPI_CS_CNT_MAX; idx++)
> > +                                               gpiod_set_value_cansleep(spi_get_csgpiod(spi,
> idx),
> > +                                                                        !enable);
> > +                               } else {
> > +                                       for (idx = 0; idx < SPI_CS_CNT_MAX; idx++)
> > +                                               /* Polarity handled by GPIO library */
> > +                                               gpiod_set_value_cansleep(spi_get_csgpiod(spi,
> idx),
> > +                                                                        activate);
> > +                               }
> > +                       }
> > +                       /* Some SPI masters need both GPIO CS & slave_select */
> > +                       if ((spi->controller->flags & SPI_MASTER_GPIO_SS) &&
> > +                           spi->controller->set_cs)
> > +                               spi->controller->set_cs(spi, !enable);
> 
> > +                       else if (spi->controller->set_cs)
> > +                               spi->controller->set_cs(spi, !enable);
> 
> this else if belongs to the following brace as the else of the if
> (spi_get_csgpiod(spi, 0) && spi_get_csgpiod(spi, 1). Currently it would make

Agreed, will fix it in the next series.

> the first check redundant, as the second case would always be true if the first
> one is.
> 
> Actually shouldn't you iterate over the cs's here in case one is using
> set_cs() and the other one is gpiod? You can only get here if both are backed
> by gpiods. And you would only set the first cs, but not the second one. The -
> >set_cs() callback doesn't allow specifying which of the (multiple) cs's should
> be set though.
>
 
After fixing the else if indentation we will get here if either one of the
 CS support gpiod or both the CS support set_cs. Yes, one is using set_cs() 
and the other one is gpiod use case handling is missing. I need to iterate 
over the CS’s to find the CS GPIO, call gpiod_set_value_cansleep ( ) and 
then call set_cs( ). In the set_cs( ) driver API the driver needs to first check 
if any of the cs_index_mask enabled CS's is not a CS GPIO and then enable 
only the non-gpio CS. 
Please let me your thoughts on this approach.

> > +               }
> >
> > -       if (spi_get_csgpiod(spi, 0)) {
> > -               if (!(spi->mode & SPI_NO_CS)) {
> > -                       /*
> > -                        * Historically ACPI has no means of the GPIO polarity and
> > -                        * thus the SPISerialBus() resource defines it on the per-chip
> > -                        * basis. In order to avoid a chain of negations, the GPIO
> > -                        * polarity is considered being Active High. Even for the cases
> > -                        * when _DSD() is involved (in the updated versions of ACPI)
> > -                        * the GPIO CS polarity must be defined Active High to avoid
> > -                        * ambiguity. That's why we use enable, that takes
> SPI_CS_HIGH
> > -                        * into account.
> > -                        */
> > -                       if (has_acpi_companion(&spi->dev))
> > -                               gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0),
> !enable);
> > -                       else
> > -                               /* Polarity handled by GPIO library */
> > -                               gpiod_set_value_cansleep(spi_get_csgpiod(spi, 0),
> activate);
> > +               for (idx = 0; idx < SPI_CS_CNT_MAX; idx++) {
> > +                       if (spi_get_csgpiod(spi, idx) || !spi->controller-
> >set_cs_timing) {
> > +                               if (activate)
> > +                                       spi_delay_exec(&spi->cs_setup, NULL);
> > +                               else
> > +                                       spi_delay_exec(&spi->cs_inactive, NULL);
> > +                       }
> 
> Won't you delay twice if both CS's are backed by gpiod (and the controller
> does not implement set_cs_timing)? You should probably break after the
> first or so.
> 

True, I will add a check to avoid extra delay.

> I wonder if it would makes sense to have a helper function to set cs state to
> all cs's indicated by cs_index_mask so you can share most of the logic
> between the single and multi cs paths.
> 
> Currently it seems both paths have a lot of code (and comment) duplication,
> with the difference being one path is touching one cs and the other two (or
> all).
> 

Agreed, will update the logic.

> >                 }
> > -               /* Some SPI masters need both GPIO CS & slave_select */
> > -               if ((spi->controller->flags & SPI_MASTER_GPIO_SS) &&
> > -                   spi->controller->set_cs)
> > +       } else {
> > +               /*
> > +                * Avoid calling into the driver (or doing delays) if the chip select
> > +                * isn't actually changing from the last time this was called.
> > +                */
> > +               if (!force && ((enable && spi->controller->last_cs ==
> > +                               spi_get_chipselect(spi, cs_num)) ||
> > +                               (!enable && spi->controller->last_cs !=
> > +                                spi_get_chipselect(spi, cs_num))) &&
> > +                   (spi->controller->last_cs_mode_high ==
> > +                    (spi->mode & SPI_CS_HIGH)))
> > +                       return;
> > +
> > +               trace_spi_set_cs(spi, activate);
> > +
> > +               spi->controller->last_cs = enable ? spi_get_chipselect(spi, cs_num)
> : -1;
> > +               spi->controller->last_cs_mode_high = spi->mode &
> > + SPI_CS_HIGH;
> > +
> > +               if ((spi_get_csgpiod(spi, cs_num) || !spi->controller-
> >set_cs_timing) && !activate)
> > +                       spi_delay_exec(&spi->cs_hold, NULL);
> > +
> > +               if (spi->mode & SPI_CS_HIGH)
> > +                       enable = !enable;
> > +
> > +               if (spi_get_csgpiod(spi, cs_num)) {
> > +                       if (!(spi->mode & SPI_NO_CS)) {
> > +                               /*
> > +                                * Historically ACPI has no means of the GPIO polarity
> and
> > +                                * thus the SPISerialBus() resource defines it on the per-
> chip
> > +                                * basis. In order to avoid a chain of negations, the GPIO
> > +                                * polarity is considered being Active High. Even for the
> cases
> > +                                * when _DSD() is involved (in the updated versions of
> ACPI)
> > +                                * the GPIO CS polarity must be defined Active High to
> avoid
> > +                                * ambiguity. That's why we use enable, that takes
> SPI_CS_HIGH
> > +                                * into account.
> > +                                */
> > +                               if (has_acpi_companion(&spi->dev))
> > +                                       gpiod_set_value_cansleep(spi_get_csgpiod(spi,
> cs_num),
> > +                                                                !enable);
> > +                               else
> > +                                       /* Polarity handled by GPIO library */
> > +                                       gpiod_set_value_cansleep(spi_get_csgpiod(spi,
> cs_num),
> > +                                                                activate);
> > +                       }
> > +                       /* Some SPI masters need both GPIO CS & slave_select */
> > +                       if ((spi->controller->flags & SPI_MASTER_GPIO_SS) &&
> > +                           spi->controller->set_cs)
> > +                               spi->controller->set_cs(spi, !enable);
> > +               } else if (spi->controller->set_cs) {
> >                         spi->controller->set_cs(spi, !enable);
> > -       } else if (spi->controller->set_cs) {
> > -               spi->controller->set_cs(spi, !enable);
> > -       }
> > +               }
> >
> > -       if (spi_get_csgpiod(spi, 0) || !spi->controller->set_cs_timing) {
> > -               if (activate)
> > -                       spi_delay_exec(&spi->cs_setup, NULL);
> > -               else
> > -                       spi_delay_exec(&spi->cs_inactive, NULL);
> > +               if (spi_get_csgpiod(spi, cs_num) || !spi->controller-
> >set_cs_timing) {
> > +                       if (activate)
> > +                               spi_delay_exec(&spi->cs_setup, NULL);
> > +                       else
> > +                               spi_delay_exec(&spi->cs_inactive, NULL);
> > +               }
> >         }
> >  }
> >
> > @@ -2246,8 +2320,8 @@ static void of_spi_parse_dt_cs_delay(struct
> > device_node *nc,  static int of_spi_parse_dt(struct spi_controller *ctlr,
> struct spi_device *spi,
> >                            struct device_node *nc)  {
> > -       u32 value;
> > -       int rc;
> > +       u32 value, cs[SPI_CS_CNT_MAX] = {0};
> > +       int rc, idx;
> >
> >         /* Mode (clock phase/polarity/etc.) */
> >         if (of_property_read_bool(nc, "spi-cpha")) @@ -2320,13
> > +2394,21 @@ static int of_spi_parse_dt(struct spi_controller *ctlr, struct
> spi_device *spi,
> >         }
> >
> >         /* Device address */
> > -       rc = of_property_read_u32(nc, "reg", &value);
> > -       if (rc) {
> > +       rc = of_property_read_variable_u32_array(nc, "reg", &cs[0], 1,
> > +                                                SPI_CS_CNT_MAX);
> > +       if (rc < 0 || rc > ctlr->num_chipselect) {
> >                 dev_err(&ctlr->dev, "%pOF has no valid 'reg' property (%d)\n",
> >                         nc, rc);
> >                 return rc;
> > +       } else if ((of_property_read_bool(nc, "parallel-memories")) &&
> > +                  (!ctlr->multi_cs_cap)) {
> > +               dev_err(&ctlr->dev, "SPI controller doesn't support multi CS\n");
> > +               return -EINVAL;
> >         }
> > -       spi_set_chipselect(spi, 0, value);
> > +       for (idx = 0; idx < rc; idx++)
> > +               spi_set_chipselect(spi, idx, cs[idx]);
> > +       /* By default set the spi->cs_index_mask as 1 */
> > +       spi->cs_index_mask = 0x01;
> >
> >         /* Device speed */
> >         if (!of_property_read_u32(nc, "spi-max-frequency", &value)) @@
> > -3846,6 +3928,7 @@ static int __spi_validate(struct spi_device *spi, struct
> spi_message *message)
> >         struct spi_controller *ctlr = spi->controller;
> >         struct spi_transfer *xfer;
> >         int w_size;
> > +       u32 cs_num = __ffs(spi->cs_index_mask);
> >
> >         if (list_empty(&message->transfers))
> >                 return -EINVAL;
> > @@ -3858,7 +3941,7 @@ static int __spi_validate(struct spi_device *spi,
> struct spi_message *message)
> >          * cs_change is set for each transfer.
> >          */
> >         if ((spi->mode & SPI_CS_WORD) && (!(ctlr->mode_bits &
> SPI_CS_WORD) ||
> > -                                         spi_get_csgpiod(spi, 0))) {
> > +                                         spi_get_csgpiod(spi,
> > + cs_num))) {
> 
> Wouldn't you need to check for any of the cs_index_mask enabled CS's, and
> not just the first one? AFAICT you would currently fail to catch a
> SPI_CS_WORD transfer with both cs enabled where the first one is a
> SPI_CS_WORD capable native CS and the second one a gpiod.
> 

That’s true, I will add a loop and check for each of the cs_index_mask 
enabled CS's.

> >                 size_t maxsize;
> >                 int ret;
> >
> > diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h index
> > bdb35a91b4bf..452682aa1a39 100644
> > --- a/include/linux/spi/spi.h
> > +++ b/include/linux/spi/spi.h
> > @@ -19,6 +19,11 @@
> >  #include <linux/acpi.h>
> >  #include <linux/u64_stats_sync.h>
> >
> > +/* Max no. of CS supported per spi device */ #define SPI_CS_CNT_MAX 2
> > +
> > +/* chip select mask */
> > +#define SPI_PARALLEL_CS_MASK   (BIT(0) | BIT(1))
> >  struct dma_chan;
> >  struct software_node;
> >  struct ptp_system_timestamp;
> > @@ -166,6 +171,7 @@ extern void
> spi_transfer_cs_change_delay_exec(struct spi_message *msg,
> >   *     deasserted. If @cs_change_delay is used from @spi_transfer, then
> the
> >   *     two delays will be added up.
> >   * @pcpu_statistics: statistics for the spi_device
> > + * @cs_index_mask: Bit mask of the active chipselect(s) in the
> > + chipselect array
> >   *
> >   * A @spi_device is used to interchange data between an SPI slave
> >   * (usually a discrete chip) and CPU memory.
> > @@ -181,7 +187,7 @@ struct spi_device {
> >         struct spi_controller   *controller;
> >         struct spi_controller   *master;        /* Compatibility layer */
> >         u32                     max_speed_hz;
> > -       u8                      chip_select;
> > +       u8                      chip_select[SPI_CS_CNT_MAX];
> >         u8                      bits_per_word;
> >         bool                    rt;
> >  #define SPI_NO_TX      BIT(31)         /* No transmit wire */
> > @@ -202,7 +208,7 @@ struct spi_device {
> >         void                    *controller_data;
> >         char                    modalias[SPI_NAME_SIZE];
> >         const char              *driver_override;
> > -       struct gpio_desc        *cs_gpiod;      /* Chip select gpio desc */
> > +       struct gpio_desc        *cs_gpiod[SPI_CS_CNT_MAX];      /* Chip select
> gpio desc */
> >         struct spi_delay        word_delay; /* Inter-word delay */
> >         /* CS delays */
> >         struct spi_delay        cs_setup;
> > @@ -212,6 +218,13 @@ struct spi_device {
> >         /* The statistics */
> >         struct spi_statistics __percpu  *pcpu_statistics;
> >
> > +       /* Bit mask of the chipselect(s) that the driver need to use from
> > +        * the chipselect array.When the controller is capable to handle
> > +        * multiple chip selects & memories are connected in parallel
> > +        * then more than one bit need to be set in cs_index_mask.
> > +        */
> > +       u32                     cs_index_mask : 2;
> 
> SPI_CS_CNT_MAX?
> 

Agreed, will replace 2 with SPI_CS_CNT_MAX.

> > +
> >         /*
> >          * likely need more hooks for more protocol options affecting how
> >          * the controller talks to each chip, like:
> > @@ -268,22 +281,22 @@ static inline void *spi_get_drvdata(struct
> > spi_device *spi)
> >
> >  static inline u8 spi_get_chipselect(struct spi_device *spi, u8 idx)
> > {
> > -       return spi->chip_select;
> > +       return spi->chip_select[idx];
> >  }
> >
> >  static inline void spi_set_chipselect(struct spi_device *spi, u8 idx,
> > u8 chipselect)  {
> > -       spi->chip_select = chipselect;
> > +       spi->chip_select[idx] = chipselect;
> >  }
> >
> >  static inline struct gpio_desc *spi_get_csgpiod(struct spi_device
> > *spi, u8 idx)  {
> > -       return spi->cs_gpiod;
> > +       return spi->cs_gpiod[idx];
> >  }
> >
> >  static inline void spi_set_csgpiod(struct spi_device *spi, u8 idx,
> > struct gpio_desc *csgpiod)  {
> > -       spi->cs_gpiod = csgpiod;
> > +       spi->cs_gpiod[idx] = csgpiod;
> >  }
> >
> >  /**
> > @@ -388,6 +401,8 @@ extern struct spi_device
> *spi_new_ancillary_device(struct spi_device *spi, u8 ch
> >   * @bus_lock_spinlock: spinlock for SPI bus locking
> >   * @bus_lock_mutex: mutex for exclusion of multiple callers
> >   * @bus_lock_flag: indicates that the SPI bus is locked for exclusive
> > use
> > + * @multi_cs_cap: indicates that the SPI Controller can assert/de-assert
> > + *     more than one chip select at once.
> >   * @setup: updates the device mode and clocking records used by a
> >   *     device's SPI controller; protocol code may call this.  This
> >   *     must fail if an unrecognized or unsupported mode is requested.
> > @@ -585,6 +600,13 @@ struct spi_controller {
> >         /* Flag indicating that the SPI bus is locked for exclusive use */
> >         bool                    bus_lock_flag;
> >
> > +       /*
> > +        * Flag indicating that the spi-controller has multi chip select
> > +        * capability and can assert/de-assert more than one chip select
> > +        * at once.
> > +        */
> > +       bool                    multi_cs_cap;
> 
> I admit I haven't followed the first iterations, but Is there a reason this isn't a
> SPI_XXX flag in spi.h? There seem to be quite a few free bits left.
> 

Yes, it can be a SPI_XX flag as well. I will add a flag & remove this 
structure member.

> I would think multi_cs can be emulated (somewhat) via gpiod for the second
> CS as long as the controller supports set_cs() (and SPI_NO_CS?).
> 

It is not just about handling the CS's, but rather this flag indicates 
that the controller can communicate (reading & writing data) with 
both the devices simultaneously.

Regards,
Amit

> > +
> >         /* Setup mode and clock, etc (spi driver may call many times).
> >          *
> >          * IMPORTANT:  this may be called when transfers to another
> > --
> > 2.25.1
> >
> 
> Regards
> Jonas

  reply	other threads:[~2023-03-20 19:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-10 17:32 [PATCH V6 00/15] Add support for stacked/parallel memories Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 02/15] net: Replace all spi->chip_select and spi->cs_gpiod references with function call Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 03/15] iio: imu: " Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 04/15] mtd: devices: " Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 05/15] staging: " Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 06/15] platform/x86: serial-multi-instantiate: " Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 07/15] powerpc/83xx/mpc832x_rdb: Replace all spi->chip_select " Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 08/15] ALSA: hda: cs35l41: " Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 09/15] spi: Add stacked and parallel memories support in SPI core Amit Kumar Mahapatra
2023-03-12 15:59   ` Jonas Gorski
2023-03-20 19:15     ` Mahapatra, Amit Kumar [this message]
2023-03-13 17:15   ` Stefan Binding
2023-03-10 17:32 ` [PATCH V6 10/15] mtd: spi-nor: Convert macros with inline functions Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 11/15] mtd: spi-nor: Add APIs to set/get nor->params Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 12/15] mtd: spi-nor: Add stacked memories support in spi-nor Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 13/15] spi: spi-zynqmp-gqspi: Add stacked memories support in GQSPI driver Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 14/15] mtd: spi-nor: Add parallel memories support in spi-nor Amit Kumar Mahapatra
2023-03-10 17:32 ` [PATCH V6 15/15] spi: spi-zynqmp-gqspi: Add parallel memories support in GQSPI driver Amit Kumar Mahapatra
2023-03-11 21:16 ` (subset) [PATCH V6 00/15] Add support for stacked/parallel memories 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=BN7PR12MB2802FFB8112849DEB9C22FBFDC809@BN7PR12MB2802.namprd12.prod.outlook.com \
    --to=amit.kumar-mahapatra@amd.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=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=jonas.gorski@gmail.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=sbinding@opensource.cirrus.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).