All of lore.kernel.org
 help / color / mirror / Atom feed
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Santhosh Kumar K <s-k6@ti.com>
Cc: <broonie@kernel.org>,  <robh@kernel.org>,  <krzk+dt@kernel.org>,
	<conor+dt@kernel.org>,  <richard@nod.at>,  <vigneshr@ti.com>,
	<pratyush@kernel.org>,  <mwalle@kernel.org>,
	<takahiro.kuwano@infineon.com>,  <linux-spi@vger.kernel.org>,
	<devicetree@vger.kernel.org>,  <linux-kernel@vger.kernel.org>,
	<linux-mtd@lists.infradead.org>,  <praneeth@ti.com>,
	 <u-kumar1@ti.com>, <a-dutta@ti.com>
Subject: Re: [PATCH v7 16/18] mtd: spinand: negotiate optimal controller operating point before dirmap creation
Date: Thu, 13 Aug 2026 10:35:52 +0200	[thread overview]
Message-ID: <87bjb6l8nr.fsf@bootlin.com> (raw)
In-Reply-To: <20260811183313.1550425-17-s-k6@ti.com> (Santhosh Kumar K.'s message of "Wed, 12 Aug 2026 00:03:11 +0530")

Hi Santhosh,

I have only one comment on the spinand bits.

> +/*
> + * spinand_try_ranked_variant() - Try controller optimization on variants in
> + *				  performance order.
> + * @spinand:    SPI NAND device
> + * @mem:        SPI memory device
> + * @iface:      bus interface to iterate (ODTR or SSDR)
> + * @tried_mask: bitmask of already-tried variant indices; updated on each try
> + *
> + * Iterates the full read variant list in descending performance order,
> + * skipping variants in @tried_mask, and calls execute_tuning on each until
> + * one succeeds. Ranked iteration finds the best available variant without
> + * re-trying already-attempted ones.
> + *
> + * On success, sets spinand->max_read_op and updates the matching
> + * odtr_op_templates.read_cache or ssdr_op_templates.read_cache.
> + */
> +static bool spinand_try_ranked_variant(struct spinand_device *spinand,
> +				       struct spi_mem *mem,
> +				       enum spinand_bus_interface iface,
> +				       u32 *tried_mask)
> +{
> +	const struct spinand_op_variants *variants = spinand->all_read_variants;
> +	const struct spi_mem_op *best;
> +	int ret;
> +
> +	if (!variants)
> +		return false;
> +
> +	while ((best = spinand_op_find_best_variant(spinand, variants, iface,
> +						    *tried_mask))) {
> +		*tried_mask |= BIT(best - variants->ops);
> +		spinand->max_read_op = *best;
> +		spinand->max_read_op.max_freq = 0;
> +		spinand->max_write_op.max_freq = 0;
> +		ret = spi_mem_execute_tuning(mem, &spinand->max_read_op,
> +					     &spinand->max_write_op);
> +		if (ret && ret != -EOPNOTSUPP)
> +			dev_dbg(&mem->spi->dev, "%s optimization failed: %d\n",
> +				iface == ODTR ? "ODTR" : "SSDR", ret);
> +		if (!ret && spinand->max_read_op.max_freq) {
> +			if (iface == ODTR)
> +				spinand->odtr_op_templates.read_cache = best;
> +			else
> +				spinand->ssdr_op_templates.read_cache = best;
> +			spinand->cont_read_possible = false;

Why do you disable continuous reads? I know it is not the same as the
read template, but it only differs by a few dummy cycles, so everything
should work as expected. I believe without complexifying much the logic
we should be able to support it.

Thanks,
Miquèl

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

WARNING: multiple messages have this Message-ID (diff)
From: Miquel Raynal <miquel.raynal@bootlin.com>
To: Santhosh Kumar K <s-k6@ti.com>
Cc: <broonie@kernel.org>,  <robh@kernel.org>,  <krzk+dt@kernel.org>,
	<conor+dt@kernel.org>,  <richard@nod.at>,  <vigneshr@ti.com>,
	<pratyush@kernel.org>,  <mwalle@kernel.org>,
	<takahiro.kuwano@infineon.com>,  <linux-spi@vger.kernel.org>,
	<devicetree@vger.kernel.org>,  <linux-kernel@vger.kernel.org>,
	<linux-mtd@lists.infradead.org>,  <praneeth@ti.com>,
	 <u-kumar1@ti.com>, <a-dutta@ti.com>
Subject: Re: [PATCH v7 16/18] mtd: spinand: negotiate optimal controller operating point before dirmap creation
Date: Thu, 13 Aug 2026 10:35:52 +0200	[thread overview]
Message-ID: <87bjb6l8nr.fsf@bootlin.com> (raw)
In-Reply-To: <20260811183313.1550425-17-s-k6@ti.com> (Santhosh Kumar K.'s message of "Wed, 12 Aug 2026 00:03:11 +0530")

Hi Santhosh,

I have only one comment on the spinand bits.

> +/*
> + * spinand_try_ranked_variant() - Try controller optimization on variants in
> + *				  performance order.
> + * @spinand:    SPI NAND device
> + * @mem:        SPI memory device
> + * @iface:      bus interface to iterate (ODTR or SSDR)
> + * @tried_mask: bitmask of already-tried variant indices; updated on each try
> + *
> + * Iterates the full read variant list in descending performance order,
> + * skipping variants in @tried_mask, and calls execute_tuning on each until
> + * one succeeds. Ranked iteration finds the best available variant without
> + * re-trying already-attempted ones.
> + *
> + * On success, sets spinand->max_read_op and updates the matching
> + * odtr_op_templates.read_cache or ssdr_op_templates.read_cache.
> + */
> +static bool spinand_try_ranked_variant(struct spinand_device *spinand,
> +				       struct spi_mem *mem,
> +				       enum spinand_bus_interface iface,
> +				       u32 *tried_mask)
> +{
> +	const struct spinand_op_variants *variants = spinand->all_read_variants;
> +	const struct spi_mem_op *best;
> +	int ret;
> +
> +	if (!variants)
> +		return false;
> +
> +	while ((best = spinand_op_find_best_variant(spinand, variants, iface,
> +						    *tried_mask))) {
> +		*tried_mask |= BIT(best - variants->ops);
> +		spinand->max_read_op = *best;
> +		spinand->max_read_op.max_freq = 0;
> +		spinand->max_write_op.max_freq = 0;
> +		ret = spi_mem_execute_tuning(mem, &spinand->max_read_op,
> +					     &spinand->max_write_op);
> +		if (ret && ret != -EOPNOTSUPP)
> +			dev_dbg(&mem->spi->dev, "%s optimization failed: %d\n",
> +				iface == ODTR ? "ODTR" : "SSDR", ret);
> +		if (!ret && spinand->max_read_op.max_freq) {
> +			if (iface == ODTR)
> +				spinand->odtr_op_templates.read_cache = best;
> +			else
> +				spinand->ssdr_op_templates.read_cache = best;
> +			spinand->cont_read_possible = false;

Why do you disable continuous reads? I know it is not the same as the
read template, but it only differs by a few dummy cycles, so everything
should work as expected. I believe without complexifying much the logic
we should be able to support it.

Thanks,
Miquèl

  reply	other threads:[~2026-08-13  8:36 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11 18:32 [PATCH v7 00/18] spi: cadence-quadspi: add PHY tuning support Santhosh Kumar K
2026-08-11 18:32 ` Santhosh Kumar K
2026-08-11 18:32 ` [PATCH v7 01/18] spi: dt-bindings: add spi-max-post-config-frequency-hz property Santhosh Kumar K
2026-08-11 18:32   ` Santhosh Kumar K
2026-08-11 18:32 ` [PATCH v7 02/18] spi: dt-bindings: add spi-phy-pattern-partition property Santhosh Kumar K
2026-08-11 18:32   ` Santhosh Kumar K
2026-08-11 18:32 ` [PATCH v7 03/18] spi: parse spi-max-post-config-frequency-hz into post_config_max_speed_hz Santhosh Kumar K
2026-08-11 18:32   ` Santhosh Kumar K
2026-08-11 18:32 ` [PATCH v7 04/18] spi: spi-mem: teach spi_mem_adjust_op_freq() about post-config ops Santhosh Kumar K
2026-08-11 18:32   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 05/18] spi: spi-mem: add execute_tuning callback and spi_mem_execute_tuning() Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 06/18] spi: cadence-quadspi: move cqspi_readdata_capture earlier Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 07/18] spi: cadence-quadspi: add DQS support to read data capture Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 08/18] spi: cadence-quadspi: add PHY tuning support Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 09/18] spi: cadence-quadspi: skip DDR PHY tuning for 2-byte-address ops (i2383) Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 10/18] spi: cadence-quadspi: refactor direct read path for PHY support Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 11/18] spi: cadence-quadspi: enable PHY for direct reads Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 12/18] spi: cadence-quadspi: enable PHY for indirect writes Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 13/18] spi: cadence-quadspi: reprogram CS timing on every chip-select switch Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 14/18] spi: cadence-quadspi: reprogram PHY DLL on runtime resume Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 15/18] mtd: spinand: extract variant ranking logic into spinand_op_find_best_variant() Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-13  8:24   ` Miquel Raynal
2026-08-13  8:24     ` Miquel Raynal
2026-08-11 18:33 ` [PATCH v7 16/18] mtd: spinand: negotiate optimal controller operating point before dirmap creation Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-13  8:35   ` Miquel Raynal [this message]
2026-08-13  8:35     ` Miquel Raynal
2026-08-11 18:33 ` [PATCH v7 17/18] mtd: spi-nor: extract read op template construction into helper Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K
2026-08-11 18:33 ` [PATCH v7 18/18] mtd: spi-nor: run controller optimization before dirmap creation Santhosh Kumar K
2026-08-11 18:33   ` Santhosh Kumar K

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=87bjb6l8nr.fsf@bootlin.com \
    --to=miquel.raynal@bootlin.com \
    --cc=a-dutta@ti.com \
    --cc=broonie@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-spi@vger.kernel.org \
    --cc=mwalle@kernel.org \
    --cc=praneeth@ti.com \
    --cc=pratyush@kernel.org \
    --cc=richard@nod.at \
    --cc=robh@kernel.org \
    --cc=s-k6@ti.com \
    --cc=takahiro.kuwano@infineon.com \
    --cc=u-kumar1@ti.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 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.