Received: by 2002:a25:7ec1:0:0:0:0:0 with SMTP id z184csp3641122ybc; Thu, 14 Nov 2019 12:16:37 -0800 (PST) X-Google-Smtp-Source: APXvYqz6BEDqSmRsCV2EyA6Jqgu7lcJTegtD+FDyt4A0Gjsc+iDRpl3+K6E9PXuWTYMneSGV+JPC X-Received: by 2002:a2e:9ec3:: with SMTP id h3mr8296492ljk.203.1573762596988; Thu, 14 Nov 2019 12:16:36 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573762596; cv=none; d=google.com; s=arc-20160816; b=dxgPrCCGEVbyxpJFU7kiHBsQfGFofoL+cbR5EMYTJbBFi3tHOQ6VHd30qj7mUbOl2E 0p3ASeLat0c/tYj0bVrBxmN7GdfsFhizIavrhfoNmBl5o/+YAxtCnpm33zxmNnxlnLGu rJTzE2cH0+VRph/3a7972kBAOBtwRIbRnEVXUvTZupPMhb1GG3aaLdIDcO+KJfWREhSM RXhC2d3xcj+T9RWvC9xHe8Ba2XFyw/+WWOjCNuo0EeM1fiDDIO/zRI+HAmDzGaERb2Ym MpdVDwwt9/4q+z0X8yWmnFhvwaydyoIGHBDH9eqeckkOznpIO6t4ymlboWf89SELNjtG lteg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=4Ji7JT/ph1Z3xblJCeIO/m+YSvCBj007fUeZA8XJLhY=; b=Sf2Az6P6vzxSBlJ3McEZqhy8W27oGyZAiwxRKClWUopw+wvfnBhwOaeBgc/nLi9mJk P2dtIomyCY9nHitE0TMF4sg5kBkERrwL2dDWBI0W96Q84YgXcM50+drCgkg1ja2dXM2B oheeUrSc7JP2zuZstEF4Rm9BruvGnj3OBWrWKDOSp+jpNHW772X9zFfOkekTiZ5WvWNx BAQrdg9azaMFYwewia4QY/f3FaKO1X1TQNQGI8k3ROqy92snUshyWa6MTec6NIFvrxr0 uMnQ1KTvut5P3fn8kM9iC1LlVW516fQ+2G5TpJEJIi6h9Pl7dcnvNrRQsCJL23LXKBIl 9Akw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f6si4445990ejx.0.2019.11.14.12.16.12; Thu, 14 Nov 2019 12:16:36 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726852AbfKNUPR (ORCPT + 99 others); Thu, 14 Nov 2019 15:15:17 -0500 Received: from sauhun.de ([88.99.104.3]:44526 "EHLO pokefinder.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726474AbfKNUPR (ORCPT ); Thu, 14 Nov 2019 15:15:17 -0500 Received: from localhost (x4db7660f.dyn.telefonica.de [77.183.102.15]) by pokefinder.org (Postfix) with ESMTPSA id 0F4272C03EE; Thu, 14 Nov 2019 21:15:15 +0100 (CET) Date: Thu, 14 Nov 2019 21:15:14 +0100 From: Wolfram Sang To: Ulf Hansson Cc: Eugeniu Rosca , Wolfram Sang , Yoshihiro Shimoda , Niklas =?utf-8?Q?S=C3=B6derlund?= , Geert Uytterhoeven , Simon Horman , "linux-mmc@vger.kernel.org" , Linux Kernel Mailing List , Linux-Renesas , Eugeniu Rosca , Harish Jenny K N , Andrew Gabbasov Subject: Re: [PATCH] mmc: renesas_sdhi_internal_dmac: Add MMC_CAP_ERASE to Gen3 SoCs Message-ID: <20191114201514.GA3058@kunai> References: <20191112134808.23546-1-erosca@de.adit-jv.com> <20191112204952.GA2976@kunai> <20191114113743.GA19656@vmlxhi-102.adit-jv.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ulf, thanks again for the heads up. > Let's first take a step back, because I don't know how the HW busy > detection works for your controller. >=20 > I have noticed there is TMIO_STAT_CMD_BUSY bit being set for some > variants, which seems to cause renesas_sdhi_wait_idle() to loop for a > pre-defined number of loops/timeout. This looks scary, but I can't > tell if it's really a problem. That should be okay. The datasheet mentions that some registers can only be accessed when either CBSY or SCLKDIVEN bits signal non-busyness. renesas_sdhi_wait_idle() is for that. > BTW, do you know what TMIO_STAT_CMD_BUSY actually is monitoring? 0: A command sequence has been completed. 1: A command sequence is being executed. > I have also noticed that MMC_CAP_WAIT_WHILE_BUSY isn't set for any of > the renesas/tmio variant hosts. Is that simply because the HW doesn't > support this? Or because implementation is missing? Good thing we use public development. I recalled we discussed this before but I needed a search engine to find it again: https://patchwork.kernel.org/patch/8114821/ Summary: The HW (at least since Gen2) has HW support for busy timeout detection but I never came around to implement it (and even forgot about it :( ). So, we still use a workqueue for it. Kind regards, Wolfram --+QahgC5+KEYLbs62 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEOZGx6rniZ1Gk92RdFA3kzBSgKbYFAl3Ntc4ACgkQFA3kzBSg KbbALRAAtN5mgjwND8GXvfgnDgmjvkOqkG4JE3T24NtpQdmjoSGhduWW8lhSsCeD 2i6ziNE3oght8mF1Rkh3KkD/LX8yzYJPAEWsLJ2+P2pmmkqNFo2HUnS5udIGP5mV yo3XMA6cshF69DV1eafWLEBYluk9SmrMD2iD+0kO+4Mc7+SlwAcF8xVG9fpQ2ODh asack+7659QzovDga35Yp6xnC0T9bRXbA/+j9KbInci5I1txfMR1JCmbiYdHjvcP ioGgGAW0lSck//kLuQUZ/c08KrkcdW625W3xmZXbINhLcXU9UAMPliH9Peaehcz6 jaoUdUFXJlUc63uyvxkHinWRgVAztFfZQ8SAJjtRJ1Mhafi85yYlvFXEw8UIE3rm N8JyQh27VhBXuDGvV6ea3aQUyOp4zNJ1i4Ap/xmgPTKZocYgJGsvfN+9uofGYMvh YpCnl0Y+jGDvlGnoNwIWFDcG0MAm2lA5Ty0hzIkpnOCY2C5WZL09QYlTQYZh3dCo iEx7Tbhq/WkgDV9wdMywuTFdjWHm64oTa8e5qmW5d8qOwjon0vbDlkdN7IkXQ+Zt KZNuFNQr4vZ4Cs/l1FcLOM0S+ttMRaGwaCjFwBrThP+9rvxbEBj+uArxZZTzy98a It7rsCfb75FPhfDjB39xttbtcxtm9ZjBgwJiD7eS2RQZ3+B8uZo= =JtQE -----END PGP SIGNATURE----- --+QahgC5+KEYLbs62--