From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8A17FC3F2CD for ; Wed, 4 Mar 2020 10:33:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 58E1420705 for ; Wed, 4 Mar 2020 10:33:19 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="mXT5WtUh" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387774AbgCDKdS (ORCPT ); Wed, 4 Mar 2020 05:33:18 -0500 Received: from mail-vs1-f68.google.com ([209.85.217.68]:38283 "EHLO mail-vs1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387688AbgCDKdS (ORCPT ); Wed, 4 Mar 2020 05:33:18 -0500 Received: by mail-vs1-f68.google.com with SMTP id r18so798410vso.5 for ; Wed, 04 Mar 2020 02:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oavuclMu1bzFOooB6OMmYHMNvudw3zSMha1bvQGFwlM=; b=mXT5WtUhyrlswngAqH6ya+Juu2LGtRuHOusP2nOG7HjjTZyzZfKHy5sBYZ+UyMuoGx 1C9UM1j6DPFWmzU6eIMdSEHuH+Daaw7KNhAnz1qsp7m07VGBy6UCuzNAvI17a0JARLr5 GgzJmucnCXZq06g5AKqMDKpJr9i7hC4NjXD4q4WNcTwQH74hs8uvjFZLDNsUPbfJMmxt s1GseK3iVpTYMg6sEJYBbxI59Y0pC5dkMYM3Chc2dpMkt5ItQ3DUbPebklsY6xgSgAgc sySj8ET3u8vjIpi8mF6gZAdbgHWwW4LPMW9oKEA8ygbzFx0BFAi+j7+ztl2Wdr8NNtWQ 7qsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oavuclMu1bzFOooB6OMmYHMNvudw3zSMha1bvQGFwlM=; b=XUAvNc9Z1HQ0/pFdP3HrJ+8oc8IyvSo0XU7PsWfMSo6Eq4Jq4vbRJ8VDnXoMBVEhIp QymCCaBtHnoBvRdKqOR02UX4EimOJLcGZWOYTlNkpDDwk6tdnKkesa5hYAN/NmnVjMrI 4yq8MBwm0JcIk7VE7bpfeE7EG6r2WMzBp5oQ4coJzq7vYqAbpt6kluVpQqnokq/6Lm4l 7+lS62In6hWE3fUhQDUcZNRUTF2QkOskNANXYNuYtQYCkyV/075diNBHdrSSsELc2Hhy ZXE4/9USzgJBHyG2hjGJW+RuCdipWKnrw/GwMZZQnuwpaTQ0zC0CWe2hNfnlGwn0b1xt HMvA== X-Gm-Message-State: ANhLgQ0YjVUdyOAqMFwrfE8FYPdKXJi430qBO4SzdvUicwITo1bxKonD 6mo3MlqfwGidNGa7NGKLPH0/tgSdnfLxdvwNoGZF+A== X-Google-Smtp-Source: ADFU+vt8lszpIIskiGB9+FhpTPR1wmM1HuQk0VGywmC3a/Ll2JBX9fYN7Go6GOFSjkphJhvCqF2NGIj6hT+js/1446k= X-Received: by 2002:a05:6102:4af:: with SMTP id r15mr1253954vsa.35.1583317997633; Wed, 04 Mar 2020 02:33:17 -0800 (PST) MIME-Version: 1.0 References: <6523119a-50ac-973a-d1cd-ab1569259411@nvidia.com> <0963b60f-15e7-4bc6-10df-6fc8003e4d42@nvidia.com> <34fd84d7-387b-b6f3-7fb3-aa490909e205@ti.com> <5e9b5646-bd48-e55b-54ee-1c2c41fc9218@nvidia.com> In-Reply-To: From: Ulf Hansson Date: Wed, 4 Mar 2020 11:32:41 +0100 Message-ID: Subject: Re: LKFT: arm x15: mmc1: cache flush error -110 To: Sowjanya Komatineni Cc: Jon Hunter , Bitan Biswas , Adrian Hunter , Naresh Kamboju , Jens Axboe , Alexei Starovoitov , linux-block , lkft-triage@lists.linaro.org, open list , "linux-mmc@vger.kernel.org" , Arnd Bergmann , John Stultz , Faiz Abbas , Thierry Reding , Anders Roxell , Kishon Content-Type: text/plain; charset="UTF-8" Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org [...] > > > Actually we always use R1B with CMD6 as per spec. > > I fully agree that R1B is preferable, but it's not against the spec to > send CMD13 to poll for busy. > > Moreover, we need to cope with the scenario when the host has > specified a maximum timeout that isn't sufficiently long enough for > the requested operation. Do you have another proposal for how to > manage this, but disabling MMC_RSP_BUSY? > > Let's assume you driver would get a R1B for the CMD6 (we force it), > then what timeout would the driver be using if we would set > cmd.busy_timeout to 30ms? /s/30ms/30s Kind regards Uffe