Message ID | 20240131003714.2779593-1-jm@ti.com |
---|---|
Headers |
Return-Path: <linux-kernel+bounces-45535-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7301:2087:b0:106:209c:c626 with SMTP id gs7csp1590100dyb; Tue, 30 Jan 2024 16:41:50 -0800 (PST) X-Google-Smtp-Source: AGHT+IHa6WXNi7j4ybJJ2kdz4Ko2pz8bCKzWmVpGzJJ6PYuhhObIY0SC2X9gEWreqf4SUc9HCfR+ X-Received: by 2002:a05:6402:2297:b0:55f:57b4:89dc with SMTP id cw23-20020a056402229700b0055f57b489dcmr112845edb.19.1706661709788; Tue, 30 Jan 2024 16:41:49 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706661709; cv=pass; d=google.com; s=arc-20160816; b=aZHxLd5WtUD3OFs0GpKMRYpmQNCb0uoLT83PjsGgHWGOIvA9glxRBDFzQwCAay69OQ u670KXMgjQu12c/XtGSZK6GQU7JQ+v7V5Tih94GgJKVLKdhTmNK5YIi9OaKko2OVyw7I bFe9N0wFpJ4vg6K8QZEADXOsuIr0g8uvkqzskxKF0WiTwOK7uJpkqBhXTfuz5vI73Ycm O5uNdoiee7jnvAGzWka2RAvKo25SxUnsJxkSeqRoMgKy4rboTFISomf0lNF79sre7vRX sX2IuwmjtvVJ4qcLXHelICGmFEwno70TWGFzCm4YGxFhta+eO/jp4+9os4KKWB3OHMQk gzWw== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from:dkim-signature; bh=xtnSmZCipnrpT8/DHBFeXQG5H33NY0uj3pHdnmk5/gk=; fh=efueuLfsKYuL+CzWPT+XXFEHgpJ0ikCfOr5B1D2Wtu4=; b=XAK3+zvGZHGQkTEI9UsLWd639ryFZmeSjr37P3PsLQySvM4MYGKwj/MngY/boPvPdZ udR2iTNijjfh4RG77C4cN5Gz2Ez/WPHekiKPorPEpJZ3n8TvxOFjVH9HGh82Mx3/x2k5 D5kcVT4uGqz8Ywsdzsa8LW+XPyjBoxOvL35A4clRidJIOltaK++9xAHav7YmyPaD42A0 nobzc4AoiUIQTQkxZGnvfB0O8KYGuio5bRCUR5GK9QbeaqD6fyxQG2aHOPuSNoZh07q3 9+vvvihH2KLUNLvyhXq2GJSGUDpgz+MjkZ+FlTDhetpsPJG6a0A0UuJ3TJM7yst2KOsx K/ow==; dara=google.com ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=hzWh4m4l; arc=pass (i=1 spf=pass spfdomain=ti.com dkim=pass dkdomain=ti.com dmarc=pass fromdomain=ti.com); spf=pass (google.com: domain of linux-kernel+bounces-45535-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-45535-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com X-Forwarded-Encrypted: i=1; AJvYcCWHlrPXUijjp56H007ZQ64mITVT1qDepu2zu77fZgxAFHQ5qED3N3D6c9u1Z3JSvMsPOBeMjHpxya5pLVYju4ckoml11w== Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [2604:1380:4601:e00::3]) by mx.google.com with ESMTPS id x5-20020aa7d6c5000000b0055f2b309c58si1577943edr.366.2024.01.30.16.41.49 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 30 Jan 2024 16:41:49 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-45535-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3; Authentication-Results: mx.google.com; dkim=pass header.i=@ti.com header.s=ti-com-17Q1 header.b=hzWh4m4l; arc=pass (i=1 spf=pass spfdomain=ti.com dkim=pass dkdomain=ti.com dmarc=pass fromdomain=ti.com); spf=pass (google.com: domain of linux-kernel+bounces-45535-ouuuleilei=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) smtp.mailfrom="linux-kernel+bounces-45535-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=ti.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id E7A131F26A0C for <ouuuleilei@gmail.com>; Wed, 31 Jan 2024 00:41:30 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id BE6EE37149; Wed, 31 Jan 2024 00:37:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="hzWh4m4l" Received: from lelv0142.ext.ti.com (lelv0142.ext.ti.com [198.47.23.249]) (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 EED001C27; Wed, 31 Jan 2024 00:37:23 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.47.23.249 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706661447; cv=none; b=C0mRNSxNrm1BU6N/35cBW83DPGteMvH78YbCUarCJtiTNm51ucxqpD97bFDSKBsqOSz+GBYNW8dv2iFULCsbkC8ilbMd6m3PF9djHNmBFIPM1PEWmMeR/WTfrE50wqZRytqJkHAsuEqonV22z/3A4njI2Zm15rHqOlpxR8+zvOY= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706661447; c=relaxed/simple; bh=R1xFZYlZq5iDmiqO1hgP/SCPOxGVh8mZ3jaCmVuJr1M=; h=From:To:CC:Subject:Date:Message-ID:MIME-Version:Content-Type; b=VVmJ1YugZYnhzE5VnZCjQ2+mP+q2KTq4nXulM5baQxVM+/Fw5REGZXI7V8bEAQBeA++hLYTdtTuBZGitNX9hmKBnBYGakMrNNglosj6qP0t06OykQti/qIf6jenvhc4L6fbleGPVGELxISFj6nL6uMxu26fH9soDFejMFZlxD8k= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com; spf=pass smtp.mailfrom=ti.com; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b=hzWh4m4l; arc=none smtp.client-ip=198.47.23.249 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ti.com Received: from lelv0266.itg.ti.com ([10.180.67.225]) by lelv0142.ext.ti.com (8.15.2/8.15.2) with ESMTP id 40V0bF3o121322; Tue, 30 Jan 2024 18:37:15 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1706661435; bh=xtnSmZCipnrpT8/DHBFeXQG5H33NY0uj3pHdnmk5/gk=; h=From:To:CC:Subject:Date; b=hzWh4m4lLeIjrj7ap7nsEu1Rw7cKCFvmpXuypgLFIJXdz61NYwgPPYqm8ZWWSnkX0 3/FPHknYdmIcdwpcIk2/IOu7Ri5vB+svgdP4kaDXfkUSthSk3bZU/NHIUFQAZiAG/1 yq/UFuU4YcREEIJfDFLX1Gyn1qJh/DWamCXz5k7w= Received: from DFLE113.ent.ti.com (dfle113.ent.ti.com [10.64.6.34]) by lelv0266.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 40V0bFTd045565 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 30 Jan 2024 18:37:15 -0600 Received: from DFLE109.ent.ti.com (10.64.6.30) by DFLE113.ent.ti.com (10.64.6.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Tue, 30 Jan 2024 18:37:15 -0600 Received: from lelvsmtp6.itg.ti.com (10.180.75.249) by DFLE109.ent.ti.com (10.64.6.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Tue, 30 Jan 2024 18:37:14 -0600 Received: from judy-hp.dhcp.ti.com (judy-hp.dhcp.ti.com [128.247.81.105]) by lelvsmtp6.itg.ti.com (8.15.2/8.15.2) with ESMTP id 40V0bEw7026520; Tue, 30 Jan 2024 18:37:14 -0600 From: Judith Mendez <jm@ti.com> To: Ulf Hansson <ulf.hansson@linaro.org>, Rob Herring <robh+dt@kernel.org>, Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>, Conor Dooley <conor+dt@kernel.org> CC: Adrian Hunter <adrian.hunter@intel.com>, <linux-mmc@vger.kernel.org>, <linux-kernel@vger.kernel.org>, Nishanth Menon <nm@ti.com>, Vignesh Raghavendra <vigneshr@ti.com>, Andrew Davis <afd@ti.com>, Udit Kumar <u-kumar1@ti.com>, Roger Quadros <rogerq@kernel.org>, <devicetree@vger.kernel.org>, Randolph Sapp <rs@ti.com> Subject: [RFC PATCH 00/13] Add tuning algorithm for delay chain Date: Tue, 30 Jan 2024 18:37:01 -0600 Message-ID: <20240131003714.2779593-1-jm@ti.com> X-Mailer: git-send-email 2.34.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1789564508755201333 X-GMAIL-MSGID: 1789564508755201333 |
Series |
Add tuning algorithm for delay chain
|
|
Message
Judith Mendez
Jan. 31, 2024, 12:37 a.m. UTC
This patch series introduces a new tuning algorithm for mmc. The new algorithm should be used when delay chain is enabled. The ITAPDLY is selected from the largest passing window and the buffer is not viewed as a circular buffer. The new tuning algorithm is implemented as per the paper published here [0] and has been tested on the following platforms: AM62x SK, AM62A SK, AM62p SK, AM64x SK, and AM64x EVM. The series also includes a few fixes in the sdhci_am654 driver on OTAPDLYEN/ITAPDLYEN and ITAPDELSEL. There are also device tree node fixes for missing mmc nodes, modifying DLL properties, and fixes for OTAP/ITAP delay values. MMC0/MMC2 nodes are introduced for AM62ax in this series. This series is sent as a RFC mostly to get some feedback and/or comments on the new tuning algorithm implementation. [0] https://www.ti.com/lit/an/spract9/spract9.pdf Judith Mendez (11): drivers: mmc: host: sdhci_am654: Add tuning algorithm for delay chain drivers: mmc: host: sdhci_am654: Write ITAPDLY for DDR52 timing drivers: mmc: host: sdhci_am654: Add missing OTAP/ITAP enable drivers: mmc: host: sdhci_am654: Add ITAPDLYSEL in sdhci_j721e_4bit_set_clock drivers: mmc: host: sdhci_am654: Fix ITAPDLY for HS400 timing arm64: dts: ti: k3-am62a-main: Add sdhci2 instance arm64: dts: ti: k3-am64-main: Update ITAP/OTAP values for MMC arm64: dts: ti: k3-am62-main: Update ITAP/OTAP values for MMC arm64: dts: ti: k3-am62p: Add missing properties for MMC arm64: dts: ti: k3-am6*: Remove DLL properties for soft phys arm64: dts: ti: k3-am6*: Reorganize MMC properties Nitin Yadav (2): arm64: dts: ti: k3-am62a-main: Add sdhci0 instance arm64: dts: ti: k3-am62a7-sk: Enable eMMC support arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 57 +++-- .../arm64/boot/dts/ti/k3-am625-beagleplay.dts | 5 - arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 45 +++- arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 27 ++- arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 44 +++- arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 7 +- .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 4 +- arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 17 +- arch/arm64/boot/dts/ti/k3-am642-evm.dts | 4 +- arch/arm64/boot/dts/ti/k3-am642-sk.dts | 2 - drivers/mmc/host/sdhci_am654.c | 215 ++++++++++++++---- 11 files changed, 321 insertions(+), 106 deletions(-)
Comments
Hi, On 1/31/2024 6:07 AM, Judith Mendez wrote: > This patch series introduces a new tuning algorithm for > mmc. The new algorithm should be used when delay chain is > enabled. The ITAPDLY is selected from the largest passing > window and the buffer is not viewed as a circular buffer. > The new tuning algorithm is implemented as per the paper > published here [0] and has been tested on the following > platforms: AM62x SK, AM62A SK, AM62p SK, AM64x SK, and AM64x > EVM. > > The series also includes a few fixes in the sdhci_am654 > driver on OTAPDLYEN/ITAPDLYEN and ITAPDELSEL. There are > also device tree node fixes for missing mmc nodes, > modifying DLL properties, and fixes for OTAP/ITAP delay > values. > > MMC0/MMC2 nodes are introduced for AM62ax in this series. > > This series is sent as a RFC mostly to get some feedback > and/or comments on the new tuning algorithm implementation. > > [0] https://www.ti.com/lit/an/spract9/spract9.pdf > > Judith Mendez (11): > drivers: mmc: host: sdhci_am654: Add tuning algorithm for delay chain > drivers: mmc: host: sdhci_am654: Write ITAPDLY for DDR52 timing > drivers: mmc: host: sdhci_am654: Add missing OTAP/ITAP enable > drivers: mmc: host: sdhci_am654: Add ITAPDLYSEL in > sdhci_j721e_4bit_set_clock > drivers: mmc: host: sdhci_am654: Fix ITAPDLY for HS400 timing These patches needs to have Fixes: tag as they are bug fixes IMO. > arm64: dts: ti: k3-am62a-main: Add sdhci2 instance > arm64: dts: ti: k3-am64-main: Update ITAP/OTAP values for MMC > arm64: dts: ti: k3-am62-main: Update ITAP/OTAP values for MMC > arm64: dts: ti: k3-am62p: Add missing properties for MMC > arm64: dts: ti: k3-am6*: Remove DLL properties for soft phys > arm64: dts: ti: k3-am6*: Reorganize MMC properties > > Nitin Yadav (2): > arm64: dts: ti: k3-am62a-main: Add sdhci0 instance > arm64: dts: ti: k3-am62a7-sk: Enable eMMC support > Can the driver changes be merged independent of DT changes? Or are they meant to go together? Latter would be problematic as it creates cross tree dependencies. > arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 57 +++-- > .../arm64/boot/dts/ti/k3-am625-beagleplay.dts | 5 - > arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 45 +++- > arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 27 ++- > arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 44 +++- > arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 7 +- > .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 4 +- > arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 17 +- > arch/arm64/boot/dts/ti/k3-am642-evm.dts | 4 +- > arch/arm64/boot/dts/ti/k3-am642-sk.dts | 2 - > drivers/mmc/host/sdhci_am654.c | 215 ++++++++++++++---- > 11 files changed, 321 insertions(+), 106 deletions(-) >
On 31/01/2024 14:35, Raghavendra, Vignesh wrote: >> Judith Mendez (11): >> drivers: mmc: host: sdhci_am654: Add tuning algorithm for delay chain >> drivers: mmc: host: sdhci_am654: Write ITAPDLY for DDR52 timing >> drivers: mmc: host: sdhci_am654: Add missing OTAP/ITAP enable >> drivers: mmc: host: sdhci_am654: Add ITAPDLYSEL in >> sdhci_j721e_4bit_set_clock >> drivers: mmc: host: sdhci_am654: Fix ITAPDLY for HS400 timing > > These patches needs to have Fixes: tag as they are bug fixes IMO. > >> arm64: dts: ti: k3-am62a-main: Add sdhci2 instance >> arm64: dts: ti: k3-am64-main: Update ITAP/OTAP values for MMC >> arm64: dts: ti: k3-am62-main: Update ITAP/OTAP values for MMC >> arm64: dts: ti: k3-am62p: Add missing properties for MMC >> arm64: dts: ti: k3-am6*: Remove DLL properties for soft phys >> arm64: dts: ti: k3-am6*: Reorganize MMC properties >> >> Nitin Yadav (2): >> arm64: dts: ti: k3-am62a-main: Add sdhci0 instance >> arm64: dts: ti: k3-am62a7-sk: Enable eMMC support >> > > Can the driver changes be merged independent of DT changes? Or are they > meant to go together? Latter would be problematic as it creates cross > tree dependencies. DTS cannot depend on driver changes, because that would mean hardware description is not really hardware but OS. So the answer to your question must be "yes, can be merged independently". Best regards, Krzysztof
On 1/31/2024 7:11 PM, Krzysztof Kozlowski wrote: > On 31/01/2024 14:35, Raghavendra, Vignesh wrote: >>> Judith Mendez (11): >>> drivers: mmc: host: sdhci_am654: Add tuning algorithm for delay chain >>> drivers: mmc: host: sdhci_am654: Write ITAPDLY for DDR52 timing >>> drivers: mmc: host: sdhci_am654: Add missing OTAP/ITAP enable >>> drivers: mmc: host: sdhci_am654: Add ITAPDLYSEL in >>> sdhci_j721e_4bit_set_clock >>> drivers: mmc: host: sdhci_am654: Fix ITAPDLY for HS400 timing >> >> These patches needs to have Fixes: tag as they are bug fixes IMO. >> >>> arm64: dts: ti: k3-am62a-main: Add sdhci2 instance >>> arm64: dts: ti: k3-am64-main: Update ITAP/OTAP values for MMC >>> arm64: dts: ti: k3-am62-main: Update ITAP/OTAP values for MMC >>> arm64: dts: ti: k3-am62p: Add missing properties for MMC >>> arm64: dts: ti: k3-am6*: Remove DLL properties for soft phys >>> arm64: dts: ti: k3-am6*: Reorganize MMC properties >>> >>> Nitin Yadav (2): >>> arm64: dts: ti: k3-am62a-main: Add sdhci0 instance >>> arm64: dts: ti: k3-am62a7-sk: Enable eMMC support >>> >> >> Can the driver changes be merged independent of DT changes? Or are they >> meant to go together? Latter would be problematic as it creates cross >> tree dependencies. > > DTS cannot depend on driver changes, because that would mean hardware > description is not really hardware but OS. So the answer to your > question must be "yes, can be merged independently". > Normally yes, but here I see update to tuning algorithm and timing paramaters to the algorithm. DT updates seem to be nature of bug fixes where in parameters have been refined due to more HW char data/understanding being available. I get nervous when anyone posts both driver and DT changes in a single series, because they may not have tested driver changes standalone and may have broken the DT backward compatibility > Best regards, > Krzysztof > Regards Vignesh
On 1/31/24 7:35 AM, Raghavendra, Vignesh wrote: > Hi, > > On 1/31/2024 6:07 AM, Judith Mendez wrote: >> This patch series introduces a new tuning algorithm for >> mmc. The new algorithm should be used when delay chain is >> enabled. The ITAPDLY is selected from the largest passing >> window and the buffer is not viewed as a circular buffer. >> The new tuning algorithm is implemented as per the paper >> published here [0] and has been tested on the following >> platforms: AM62x SK, AM62A SK, AM62p SK, AM64x SK, and AM64x >> EVM. >> >> The series also includes a few fixes in the sdhci_am654 >> driver on OTAPDLYEN/ITAPDLYEN and ITAPDELSEL. There are >> also device tree node fixes for missing mmc nodes, >> modifying DLL properties, and fixes for OTAP/ITAP delay >> values. >> >> MMC0/MMC2 nodes are introduced for AM62ax in this series. >> >> This series is sent as a RFC mostly to get some feedback >> and/or comments on the new tuning algorithm implementation. >> >> [0] https://www.ti.com/lit/an/spract9/spract9.pdf >> > > >> Judith Mendez (11): >> drivers: mmc: host: sdhci_am654: Add tuning algorithm for delay chain >> drivers: mmc: host: sdhci_am654: Write ITAPDLY for DDR52 timing >> drivers: mmc: host: sdhci_am654: Add missing OTAP/ITAP enable >> drivers: mmc: host: sdhci_am654: Add ITAPDLYSEL in >> sdhci_j721e_4bit_set_clock >> drivers: mmc: host: sdhci_am654: Fix ITAPDLY for HS400 timing > > These patches needs to have Fixes: tag as they are bug fixes IMO. Understood, will add. > >> arm64: dts: ti: k3-am62a-main: Add sdhci2 instance >> arm64: dts: ti: k3-am64-main: Update ITAP/OTAP values for MMC >> arm64: dts: ti: k3-am62-main: Update ITAP/OTAP values for MMC >> arm64: dts: ti: k3-am62p: Add missing properties for MMC >> arm64: dts: ti: k3-am6*: Remove DLL properties for soft phys >> arm64: dts: ti: k3-am6*: Reorganize MMC properties >> >> Nitin Yadav (2): >> arm64: dts: ti: k3-am62a-main: Add sdhci0 instance >> arm64: dts: ti: k3-am62a7-sk: Enable eMMC support >> > > Can the driver changes be merged independent of DT changes? Or are they > meant to go together? Latter would be problematic as it creates cross > tree dependencies. The driver changes can be merged independently. > >> arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 57 +++-- >> .../arm64/boot/dts/ti/k3-am625-beagleplay.dts | 5 - >> arch/arm64/boot/dts/ti/k3-am62a-main.dtsi | 45 +++- >> arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 27 ++- >> arch/arm64/boot/dts/ti/k3-am62p-main.dtsi | 44 +++- >> arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 7 +- >> .../arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 4 +- >> arch/arm64/boot/dts/ti/k3-am64-main.dtsi | 17 +- >> arch/arm64/boot/dts/ti/k3-am642-evm.dts | 4 +- >> arch/arm64/boot/dts/ti/k3-am642-sk.dts | 2 - >> drivers/mmc/host/sdhci_am654.c | 215 ++++++++++++++---- >> 11 files changed, 321 insertions(+), 106 deletions(-) >>
On 31/01/2024 14:53, Raghavendra, Vignesh wrote: > > > On 1/31/2024 7:11 PM, Krzysztof Kozlowski wrote: >> On 31/01/2024 14:35, Raghavendra, Vignesh wrote: >>>> Judith Mendez (11): >>>> drivers: mmc: host: sdhci_am654: Add tuning algorithm for delay chain >>>> drivers: mmc: host: sdhci_am654: Write ITAPDLY for DDR52 timing >>>> drivers: mmc: host: sdhci_am654: Add missing OTAP/ITAP enable >>>> drivers: mmc: host: sdhci_am654: Add ITAPDLYSEL in >>>> sdhci_j721e_4bit_set_clock >>>> drivers: mmc: host: sdhci_am654: Fix ITAPDLY for HS400 timing >>> >>> These patches needs to have Fixes: tag as they are bug fixes IMO. >>> >>>> arm64: dts: ti: k3-am62a-main: Add sdhci2 instance >>>> arm64: dts: ti: k3-am64-main: Update ITAP/OTAP values for MMC >>>> arm64: dts: ti: k3-am62-main: Update ITAP/OTAP values for MMC >>>> arm64: dts: ti: k3-am62p: Add missing properties for MMC >>>> arm64: dts: ti: k3-am6*: Remove DLL properties for soft phys >>>> arm64: dts: ti: k3-am6*: Reorganize MMC properties >>>> >>>> Nitin Yadav (2): >>>> arm64: dts: ti: k3-am62a-main: Add sdhci0 instance >>>> arm64: dts: ti: k3-am62a7-sk: Enable eMMC support >>>> >>> >>> Can the driver changes be merged independent of DT changes? Or are they >>> meant to go together? Latter would be problematic as it creates cross >>> tree dependencies. >> >> DTS cannot depend on driver changes, because that would mean hardware >> description is not really hardware but OS. So the answer to your >> question must be "yes, can be merged independently". >> > > Normally yes, but here I see update to tuning algorithm and timing > paramaters to the algorithm. DT updates seem to be nature of bug fixes > where in parameters have been refined due to more HW char > data/understanding being available. Then the patchset should be probably split into fixes and new features, so it would be clear that new DTS features do not depend on driver code. Best regards, Krzysztof