Received: by 2002:a05:7412:8d10:b0:f3:1519:9f41 with SMTP id bj16csp1620974rdb; Thu, 7 Dec 2023 04:38:27 -0800 (PST) X-Google-Smtp-Source: AGHT+IFVt2GsB27qF0dfPVH/hdETc4uBUGeasMmJyTHPZbX8ppXNTzbsaJaI2br8T/rK9DmcANXg X-Received: by 2002:a05:6a00:9a7:b0:6ce:6185:44e1 with SMTP id u39-20020a056a0009a700b006ce618544e1mr1876121pfg.66.1701952707087; Thu, 07 Dec 2023 04:38:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1701952707; cv=none; d=google.com; s=arc-20160816; b=cA0ND63n73j5hPrC6ddz2eHrbditvV5BJf3UCXCmQWrtbzJtpD97/c8+nB+M3WeXmC DPFoB5kFj3UGvWsn7eWoybjU+Jru7ceUTH0fooNr/6PIV799RPT1zf1QHOPN7BOvPqzQ Tv5nGJ2ocbajtRPdscTcJYqujPHcSzaPvCszYKrWblY8Rr5rWBKMPyRO9KVSJQXox81W rnC44pNRBb2sn/S2mQV3tsISSZYDUAEY9AyWIXFC2Qgdy4Yl3tcGT36E2BuOt7XE1CHl Uqz/H3favCrmUeHoQVWmsXLS4AtdcfSFF5aQ2Pqbkyigz9hoqQ0zWPCzJ02BiVgLooy5 fsbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=wJUFdR/T3fk+7q1z81V/QYA3AidCEQ3jro3FXKsX6OY=; fh=IahxZwkFRGsTVSuqdpYl/VKavhYtcHlG7dug7XQvnsI=; b=zd2x7zOMGXTaewIJdAKQJHP5c0zEdC4LhX2UIDEDrJjZm7p2KJUShefpQXsf37cSfP Rg4KDtZ0RrMeClgccoygvz6KMw/1ACp5gp36wm2eELTXUeNum1eFh3gql9ghqS+qoz5B r6oAJXRXYHlg0NG/U5/SHuO1eSbeXw6919zoeslSHIjg19SC3V+Tetk2SYUP21H/qLir 9WYHcVzkJ1avvn1+XbR8VadQ+otYSET7DZgvByZC35hGCmNQrbXg0KoGjKpMUT8wjesD V8syDrWWTdd7LwMzLqLP04y2bjHgUUT/gLk0Cy4p9VZk0waiSp56etZ2wLnutLLvAB01 0Ijw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=BWy5jkpB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Return-Path: Received: from howler.vger.email (howler.vger.email. [2620:137:e000::3:4]) by mx.google.com with ESMTPS id q20-20020a656854000000b005c65defc409si1113007pgt.748.2023.12.07.04.38.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Dec 2023 04:38:27 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) client-ip=2620:137:e000::3:4; Authentication-Results: mx.google.com; dkim=pass header.i=@collabora.com header.s=mail header.b=BWy5jkpB; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:4 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=collabora.com Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by howler.vger.email (Postfix) with ESMTP id A8078824777E; Thu, 7 Dec 2023 04:38:22 -0800 (PST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at howler.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1379518AbjLGMiF (ORCPT + 99 others); Thu, 7 Dec 2023 07:38:05 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42706 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1379413AbjLGMh7 (ORCPT ); Thu, 7 Dec 2023 07:37:59 -0500 Received: from madras.collabora.co.uk (madras.collabora.co.uk [IPv6:2a00:1098:0:82:1000:25:2eeb:e5ab]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EF0E310F0; Thu, 7 Dec 2023 04:38:01 -0800 (PST) Received: from [100.113.186.2] (cola.collaboradmins.com [195.201.22.229]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: kholk11) by madras.collabora.co.uk (Postfix) with ESMTPSA id 4B8BC660738E; Thu, 7 Dec 2023 12:37:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1701952680; bh=4FannGmPzD8CTNLgg1c0SxMxDgNTQfia5dxSGdeJOck=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=BWy5jkpBBuyQgLvhL5xgoDA6sGW8Hh0NrDwPp+9690sCYRgTkbe5jzuTtvVauJv9C E6zkCC1unRdDhsh1YjP7p8wIVi+MoxzXbDeHBbw+ZXr4wKpzUafWyqZh7wqlOOoPcN wN5Oer8NUorVHwS6sW9Y6l5LNMaddcevFU9eeMEZfUz8TUECdMcmOQYINpQ2EwHc9b 2hwAbOQ6UYUT3nPYB2vDne/g0l17Kf8Nd0vknwqR5R1YQqP02jE21d+wEzp50D90Uv 8a9LZBfe93dhdYQyW+vcV5fJ07yNtMvAvcBBFTRpzSFaN5V5Yno2ijptpi2/rLOLKo kwsqlGAEKKI/A== Message-ID: <6c7c65a1-1398-43fc-8036-d901e8bc0934@collabora.com> Date: Thu, 7 Dec 2023 13:37:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v4 2/2] mmc: mediatek: extend number of tuning steps Content-Language: en-US To: Axe Yang , Chaotian Jing , Ulf Hansson , Rob Herring , Krzysztof Kozlowski , Conor Dooley , Matthias Brugger , Wenbin Mei Cc: linux-mmc@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Project_Global_Chrome_Upstream_Group@mediatek.com References: <20231207063535.29546-1-axe.yang@mediatek.com> <20231207063535.29546-3-axe.yang@mediatek.com> From: AngeloGioacchino Del Regno In-Reply-To: <20231207063535.29546-3-axe.yang@mediatek.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-0.9 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on howler.vger.email Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (howler.vger.email [0.0.0.0]); Thu, 07 Dec 2023 04:38:23 -0800 (PST) Il 07/12/23 07:35, Axe Yang ha scritto: > Previously, during the MSDC calibration process, a full clock cycle > actually not be covered, which in some cases didn't yield the best > results and could cause CRC errors. This problem is particularly > evident when MSDC is used as an SDIO host. In fact, MSDC support > tuning up to a maximum of 64 steps, but by default, the step number > is 32. By increase the tuning step, we are more likely to cover more > parts of a clock cycle, and get better calibration result. > > To illustrate, when tuning 32 steps, if the obtained window has a hole > near the middle, like this: 0xffc07ff (hex), then the selected delay > will be the 6 (counting from right to left). > > (32 <- 1) > 1111 1111 1100 0000 0000 0111 11(1)1 1111 > > However, if we tune 64 steps, the window obtained may look like this: > 0xfffffffffffc07ff. The final selected delay will be 44, which is > safer as it is further away from the hole: > > (64 <- 1) > 1111 ... (1)111 1111 1111 1111 1111 1100 0000 0000 0111 1111 1111 > > In this case, delay 6 selected through 32 steps tuning is obviously > not optimal, and this delay is closer to the hole, using it would > easily cause CRC problems. > > As per mesaurements taken on mediatek SoC platform, the tuning phase > will take: > eMMC - 32 steps: ~3ms > - 64 steps: ~6ms > SDIO - 32 steps: ~4ms > - 64 steos: ~7ms > Tuning more steps won't prolong boot times by any meaningful amount > of time, so for SD/SDIO the default tuning steps will be adjust to > 64. But for eMMC, it is still preferred to use 32 steps tuning as > otherwise there would be performance lose when accessing the RPMB > partition(requiring retuning each time). > > You can configure property "mediatek,tuning-step" in MSDC dts node > to adjust the step number. > > Signed-off-by: Axe Yang Reviewed-by: AngeloGioacchino Del Regno