From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtpout-04.galae.net (smtpout-04.galae.net [185.171.202.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 055D02FB997 for ; Thu, 5 Feb 2026 17:39:51 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.171.202.116 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770313191; cv=none; b=oc3UqllhyC401oANGo+Pz/lDszsoZIbGqYcX1ny4B3vWldBe98Gbkjd6/iZDtjtQjHVxgzx9fDA5wgayDIkaH0cD/hm9anQ/v/Nw89c6zVkOo5Dk7AW4nYb3X8T3w26rKjrG8wnvLsu6rS9kzW5lH43l+aO4gEIkN3VZuMYTRN4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770313191; c=relaxed/simple; bh=hAkW6nhF+LUmUNanvGpF1I/RUdvXsSUbwnPXo59V8eU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Ajj0vaFG3p8ED+bY8/SJ9Z9hlzQIYncERRuhF6kPCTigF7mS2lq8Xa9IBZYRKXpKKTr6DvBBHmDqF0/7yV0qcAHC47rYJWx4BrPMu+aoN3L/jvJpK9yesXC/fZnXh6ib1B/i1pk1Eju2LvjrVUvw5BrZQuUEp72jQza9G6pNmxA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com; spf=pass smtp.mailfrom=bootlin.com; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b=dDiXS8Bs; arc=none smtp.client-ip=185.171.202.116 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=bootlin.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bootlin.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=bootlin.com header.i=@bootlin.com header.b="dDiXS8Bs" Received: from smtpout-01.galae.net (smtpout-01.galae.net [212.83.139.233]) by smtpout-04.galae.net (Postfix) with ESMTPS id 405BEC243B0; Thu, 5 Feb 2026 17:39:55 +0000 (UTC) Received: from mail.galae.net (mail.galae.net [212.83.136.155]) by smtpout-01.galae.net (Postfix) with ESMTPS id EC8AA6074D; Thu, 5 Feb 2026 17:39:48 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id B160C102F1B6D; Thu, 5 Feb 2026 18:39:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=dkim; t=1770313188; h=from:subject:date:message-id:to:cc:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=m5bZ0GbyBq2QVmRhYdoLegbe54IqW06SZN2AvRVDWyo=; b=dDiXS8Bs+DJPLycI9dC8wYV3oa+ZNSsQMS1HwuWuKWiT5DRf9iH8wZtCUG4P/WgYQEW7YD RlnsVErwGI2UeiBRUVeAUy/QDvk3VKVRr98m7RoN//wwQ8lqEdZeDlbNWj0J8ouvMn1HPy T7s0ZCQVP+InnKgqFTFOV6HA31uoi30MOOpc8jKp+ot4OW1XArg+UBuMx5UfJIGjqfhv+O iNql0bUtA6Ecy91BK65fJlnOztGWix4BnpGDoI21deGLLm6f0bNyQy+kiIJnlynyO0f1G9 LbvYCxDfTZCxMP6JHi1Keb0+hV4jyksJhGRoeiO3u3+5JYMC6UTkvn8142eyXw== From: Miquel Raynal To: Santhosh Kumar K Cc: , , , , , , , , , , , , , , , , Subject: Re: [RFC PATCH v2 09/12] spi: cadence-quadspi: add PHY tuning infrastructure In-Reply-To: <20260113141617.1905039-10-s-k6@ti.com> (Santhosh Kumar K.'s message of "Tue, 13 Jan 2026 19:46:14 +0530") References: <20260113141617.1905039-1-s-k6@ti.com> <20260113141617.1905039-10-s-k6@ti.com> User-Agent: mu4e 1.12.7; emacs 30.2 Date: Thu, 05 Feb 2026 18:39:45 +0100 Message-ID: <87bji3gkda.fsf@bootlin.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Last-TLS-Session-Version: TLSv1.3 On 13/01/2026 at 19:46:14 +0530, Santhosh Kumar K wrote: > Implement the spi_controller_mem_ops execute_tuning callback to enable > PHY tuning support for the Cadence controller. PHY tuning optimizes data > capture timing at high frequencies by calibrating the read data capture > delay through the controller's PHY interface. > > Tuning algorithm functions (cqspi_phy_tuning_ddr/sdr and > cqspi_phy_pre/post_config) are placeholders to be implemented > in subsequent commits. > > Signed-off-by: Santhosh Kumar K > --- > drivers/spi/spi-cadence-quadspi.c | 241 ++++++++++++++++++++++++++++++ > 1 file changed, 241 insertions(+) > > diff --git a/drivers/spi/spi-cadence-quadspi.c b/drivers/spi/spi-cadence-= quadspi.c > index 0df286d24256..b8b0e85f4f68 100644 > --- a/drivers/spi/spi-cadence-quadspi.c > +++ b/drivers/spi/spi-cadence-quadspi.c > @@ -32,6 +32,7 @@ >=20=20 > #define CQSPI_NAME "cadence-qspi" > #define CQSPI_MAX_CHIPSELECT 4 > +#define CQSPI_AM654_NON_PHY_CLK_RATE 25000000 >=20=20 > static_assert(CQSPI_MAX_CHIPSELECT <=3D SPI_DEVICE_CS_CNT_MAX); >=20=20 > @@ -65,6 +66,7 @@ struct cqspi_st; > struct cqspi_flash_pdata { > struct cqspi_st *cqspi; > u32 clk_rate; > + u32 non_phy_clk_rate; This is the second (and last) main issue I have with the series as it is right now. We cannot set this type of frequency in the driver IMO, it is too board specific. We currently have a DT property for the SPI maximum supported frequency. I believe this is no longer enough. Why not making this frequency property an array? First frequency would be the default, non tuned maximum frequency. The second would be the maximum frequency reachable when tuning the PHY. The rest of the patch LGTM otherwise, but there is this frequency information which I think should be handled with more care. Thanks, Miqu=C3=A8l