From: Pratyush Yadav <p.yadav@ti.com>
To: "Cédric Le Goater" <clg@kaod.org>
Cc: <linux-spi@vger.kernel.org>, <linux-mtd@lists.infradead.org>,
Mark Brown <broonie@kernel.org>,
Tudor Ambarus <tudor.ambarus@microchip.com>,
Miquel Raynal <miquel.raynal@bootlin.com>,
Richard Weinberger <richard@nod.at>,
Vignesh Raghavendra <vigneshr@ti.com>,
<linux-aspeed@lists.ozlabs.org>, Joel Stanley <joel@jms.id.au>,
Andrew Jeffery <andrew@aj.id.au>,
Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>,
<devicetree@vger.kernel.org>, Rob Herring <robh+dt@kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, Tao Ren <rentao.bupt@gmail.com>
Subject: Re: [PATCH v4 03/11] spi: spi-mem: Convert Aspeed SMC driver to spi-mem
Date: Thu, 31 Mar 2022 01:03:43 +0530 [thread overview]
Message-ID: <20220330193343.qg5kcr6twerde6ho@ti.com> (raw)
In-Reply-To: <20220325100849.2019209-4-clg@kaod.org>
Hi Cedric,
Thanks for doing the conversion.
On 25/03/22 11:08AM, Cédric Le Goater wrote:
> This SPI driver adds support for the Aspeed static memory controllers
> of the AST2600, AST2500 and AST2400 SoCs using the spi-mem interface.
>
> * AST2600 Firmware SPI Memory Controller (FMC)
> . BMC firmware
> . 3 chip select pins (CE0 ~ CE2)
> . Only supports SPI type flash memory
> . different segment register interface
> . single, dual and quad mode.
>
> * AST2600 SPI Flash Controller (SPI1 and SPI2)
> . host firmware
> . 2 chip select pins (CE0 ~ CE1)
> . different segment register interface
> . single, dual and quad mode.
>
> * AST2500 Firmware SPI Memory Controller (FMC)
> . BMC firmware
> . 3 chip select pins (CE0 ~ CE2)
> . supports SPI type flash memory (CE0-CE1)
> . CE2 can be of NOR type flash but this is not supported by the driver
> . single, dual mode.
>
> * AST2500 SPI Flash Controller (SPI1 and SPI2)
> . host firmware
> . 2 chip select pins (CE0 ~ CE1)
> . single, dual mode.
>
> * AST2400 New Static Memory Controller (also referred as FMC)
> . BMC firmware
> . New register set
> . 5 chip select pins (CE0 ∼ CE4)
> . supports NOR flash, NAND flash and SPI flash memory.
> . single, dual and quad mode.
>
> Each controller has a memory range on which flash devices contents are
> mapped. Each device is assigned a window that can be changed at bootime
> with the Segment Address Registers.
>
> Each SPI flash device can then be accessed in two modes: Command and
> User. When in User mode, SPI transfers are initiated with accesses to
> the memory segment of a device. When in Command mode, memory
> operations on the memory segment of a device generate SPI commands
> automatically using a Control Register for the settings.
>
> This initial patch adds support for User mode. Command mode needs a little
> more work to check that the memory window on the AHB bus fits the device
> size. It will come later when support for direct mapping is added.
>
> Single and dual mode RX transfers are supported. Other types than SPI
> are not supported.
>
> Reviewed-by: Joel Stanley <joel@jms.id.au>
> Tested-by: Joel Stanley <joel@jms.id.au>
> Tested-by: Tao Ren <rentao.bupt@gmail.com>
> Signed-off-by: Chin-Ting Kuo <chin-ting_kuo@aspeedtech.com>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> drivers/mtd/spi-nor/controllers/aspeed-smc.c | 910 ------------------
> drivers/spi/spi-aspeed-smc.c | 709 ++++++++++++++
> .../devicetree/bindings/mtd/aspeed-smc.txt | 51 -
> MAINTAINERS | 1 +
> drivers/mtd/spi-nor/controllers/Kconfig | 10 -
> drivers/mtd/spi-nor/controllers/Makefile | 1 -
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> 8 files changed, 722 insertions(+), 972 deletions(-)
> delete mode 100644 drivers/mtd/spi-nor/controllers/aspeed-smc.c
> create mode 100644 drivers/spi/spi-aspeed-smc.c
> delete mode 100644 Documentation/devicetree/bindings/mtd/aspeed-smc.txt
>
[...]
> +static void aspeed_spi_send_cmd_addr(struct aspeed_spi_chip *chip, u8 addr_nbytes,
> + u64 offset, u32 opcode)
> +{
> + struct aspeed_spi *aspi = chip->aspi;
> + __be32 temp;
> + u32 cmdaddr;
> +
> + switch (addr_nbytes) {
> + default:
> + dev_warn_once(aspi->dev, "Unexpected address width %u, defaulting to 3",
> + addr_nbytes);
> + fallthrough;
I think it is better if you reject ops where addr width is not 3 or 4.
This you can drop this. Or if you really want to keep it, you can change
it to a WARN_ON() and return an error.
> + case 3:
> + cmdaddr = offset & 0xFFFFFF;
> + cmdaddr |= opcode << 24;
> +
> + temp = cpu_to_be32(cmdaddr);
> + aspeed_spi_write_to_ahb(chip->ahb_base, &temp, 4);
> + break;
> + case 4:
> + temp = cpu_to_be32(offset);
> + aspeed_spi_write_to_ahb(chip->ahb_base, &opcode, 1);
> + aspeed_spi_write_to_ahb(chip->ahb_base, &temp, 4);
> + break;
> + }
> +}
> +
[...]
> +/* support for 1-1-1, 1-1-2 or 1-1-4 */
> +static bool aspeed_spi_supports_op(struct spi_mem *mem, const struct spi_mem_op *op)
> +{
> + if (op->cmd.buswidth > 1)
> + return false;
> +
> + if (op->addr.nbytes != 0) {
> + if (op->addr.buswidth > 1 || op->addr.nbytes > 4)
As mentioned above, this should reject ops with addr width 1 and 2.
> + return false;
> + }
> +
> + if (op->dummy.nbytes != 0) {
> + if (op->dummy.buswidth > 1 || op->dummy.nbytes > 7)
> + return false;
> + }
> +
> + if (op->data.nbytes != 0 && op->data.buswidth > 4)
> + return false;
> +
> + return spi_mem_default_supports_op(mem, op);
> +}
> +
> +static int do_aspeed_spi_exec_op(struct spi_mem *mem, const struct spi_mem_op *op)
> +{
> + struct aspeed_spi *aspi = spi_controller_get_devdata(mem->spi->master);
> + struct aspeed_spi_chip *chip = &aspi->chips[mem->spi->chip_select];
> + u32 addr_mode, addr_mode_backup;
> + u32 ctl_val;
> + int ret = 0;
> +
> + dev_dbg(aspi->dev,
> + "CE%d %s OP %#x mode:%d.%d.%d.%d naddr:%#x ndummies:%#x len:%#x",
> + chip->cs, op->data.dir == SPI_MEM_DATA_IN ? "read" : "write",
> + op->cmd.opcode, op->cmd.buswidth, op->addr.buswidth,
> + op->dummy.buswidth, op->data.buswidth,
> + op->addr.nbytes, op->dummy.nbytes, op->data.nbytes);
> +
> + addr_mode = readl(aspi->regs + CE_CTRL_REG);
> + addr_mode_backup = addr_mode;
> +
> + ctl_val = chip->ctl_val[ASPEED_SPI_BASE];
> + ctl_val &= ~CTRL_IO_CMD_MASK;
> +
> + ctl_val |= op->cmd.opcode << CTRL_COMMAND_SHIFT;
> +
> + /* 4BYTE address mode */
> + if (op->addr.nbytes) {
> + if (op->addr.nbytes == 4)
> + addr_mode |= (0x11 << chip->cs);
> + else
> + addr_mode &= ~(0x11 << chip->cs);
> + }
> +
> + if (op->dummy.buswidth && op->dummy.nbytes)
Nitpick: op->dummy.nbytes being set should imply op->dummy.buswidth > 0.
> + ctl_val |= CTRL_IO_DUMMY_SET(op->dummy.nbytes / op->dummy.buswidth);
> +
> + if (op->data.nbytes != 0) {
> + if (op->data.buswidth)
Nitpick: op->data.nbytes != 0 should imply op->data.buswidth > 0.
> + ctl_val |= aspeed_spi_get_io_mode(op);
> + }
> +
> + if (op->data.dir == SPI_MEM_DATA_OUT)
> + ctl_val |= CTRL_IO_MODE_WRITE;
> + else
> + ctl_val |= CTRL_IO_MODE_READ;
> +
> + if (addr_mode != addr_mode_backup)
> + writel(addr_mode, aspi->regs + CE_CTRL_REG);
> + writel(ctl_val, chip->ctl);
> +
> + if (op->data.dir == SPI_MEM_DATA_IN) {
> + if (!op->addr.nbytes)
> + ret = aspeed_spi_read_reg(chip, op);
> + else
> + ret = aspeed_spi_read_user(chip, op, op->addr.val,
> + op->data.nbytes, op->data.buf.in);
> + } else {
> + if (!op->addr.nbytes)
> + ret = aspeed_spi_write_reg(chip, op);
> + else
> + ret = aspeed_spi_write_user(chip, op);
> + }
> +
> + /* Restore defaults */
> + if (addr_mode != addr_mode_backup)
> + writel(addr_mode_backup, aspi->regs + CE_CTRL_REG);
> + writel(chip->ctl_val[ASPEED_SPI_READ], chip->ctl);
Why do you need to restore defaults here? Do you expect some other piece
of software to use it as well?
The patch looks good to me apart from these.
> + return ret;
> +}
> +
[...]
--
Regards,
Pratyush Yadav
Texas Instruments Inc.
next prev parent reply other threads:[~2022-03-30 19:34 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-25 10:08 [PATCH v4 00/11] " Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 01/11] ARM: dts: aspeed: Adjust "reg" property of FMC/SPI controllers Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 02/11] dt-bindings: spi: Add Aspeed SMC controllers device tree binding Cédric Le Goater
2022-03-30 19:19 ` Pratyush Yadav
2022-03-31 7:36 ` Cédric Le Goater
2022-03-31 12:20 ` Pratyush Yadav
2022-03-25 10:08 ` [PATCH v4 03/11] spi: spi-mem: Convert Aspeed SMC driver to spi-mem Cédric Le Goater
2022-03-29 8:56 ` Cédric Le Goater
2022-03-29 10:49 ` Mark Brown
2022-03-30 19:33 ` Pratyush Yadav [this message]
2022-04-04 7:06 ` Cédric Le Goater
2022-04-05 19:29 ` Pratyush Yadav
2022-03-25 10:08 ` [PATCH v4 04/11] spi: aspeed: Add support for direct mapping Cédric Le Goater
2022-03-30 19:45 ` Pratyush Yadav
2022-04-04 7:11 ` Cédric Le Goater
2022-04-05 19:27 ` Pratyush Yadav
2022-03-25 10:08 ` [PATCH v4 05/11] spi: aspeed: Adjust direct mapping to device size Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 06/11] spi: aspeed: Workaround AST2500 limitations Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 07/11] spi: aspeed: Add support for the AST2400 SPI controller Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 08/11] spi: aspeed: Calibrate read timings Cédric Le Goater
2022-03-30 11:53 ` Chin-Ting Kuo
2022-03-30 12:14 ` Cédric Le Goater
2022-03-31 2:46 ` Chin-Ting Kuo
2022-03-31 7:15 ` Cédric Le Goater
2022-03-31 8:34 ` Chin-Ting Kuo
2022-03-31 16:41 ` Pratyush Yadav
2022-04-04 7:30 ` Cédric Le Goater
2022-04-05 19:22 ` Pratyush Yadav
2022-03-25 10:08 ` [PATCH v4 09/11] ARM: dts: aspeed: Enable Dual SPI RX transfers Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 10/11] ARM: dts: aspeed-g4: Set spi-max-frequency for all flashes Cédric Le Goater
2022-03-25 10:08 ` [PATCH v4 11/11] mtd: spi-nor: aspeed: set the decoding size to at least 2MB for AST2600 Cédric Le Goater
2022-03-30 19:49 ` Pratyush Yadav
2022-04-01 14:12 ` [PATCH v4 00/11] spi: spi-mem: Convert Aspeed SMC driver to spi-mem Jae Hyun Yoo
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=20220330193343.qg5kcr6twerde6ho@ti.com \
--to=p.yadav@ti.com \
--cc=andrew@aj.id.au \
--cc=broonie@kernel.org \
--cc=chin-ting_kuo@aspeedtech.com \
--cc=clg@kaod.org \
--cc=devicetree@vger.kernel.org \
--cc=joel@jms.id.au \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-aspeed@lists.ozlabs.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=linux-spi@vger.kernel.org \
--cc=miquel.raynal@bootlin.com \
--cc=rentao.bupt@gmail.com \
--cc=richard@nod.at \
--cc=robh+dt@kernel.org \
--cc=tudor.ambarus@microchip.com \
--cc=vigneshr@ti.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
all inboxes | Powered by JetHome®