Received: by 2002:ac0:950c:0:0:0:0:0 with SMTP id f12csp2633513imc; Tue, 12 Mar 2019 19:32:03 -0700 (PDT) X-Google-Smtp-Source: APXvYqwjjbzHI01En/6jHaSLh2zRbD5QZHku/MDd3qe3wm/oyRBBZLY9WOEwp76x2wSoFRa0EQ0S X-Received: by 2002:a65:514a:: with SMTP id g10mr11147535pgq.400.1552444322924; Tue, 12 Mar 2019 19:32:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1552444322; cv=none; d=google.com; s=arc-20160816; b=JLmsPHAUzWyts+GrKMjJoocdW4aG16tl4Dk7OLlbyqMSdG+nruF0M/bvqCvJkFwGee 2S/Cx7IxpvmidWOTZfrTB9Rx7BjAHGkYfwAAf7pi3qnGlI0oxwmWY8ZTl4TxZZfe/5Bz F4M1lMQKZ4yE1p6d08cK/vgfZ0aaNzN5EkIn4cuquriigqBPzMtSkrTj9qLFG1r0cSpM QnXQSUhAvqNuaIDwBIS4QXQI/5lIHDgdg/InfFgqgeq3jDVEVSlcESVu4C1lcYEJx5eU fHv1yzdLGBs4w+UXrLk3FWWEOY5XYPnHnCMWGjDt29rD0UqZc9Xpkm2iAGk+ED+41A1C AQ8Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature; bh=CeOJaG97RudUgnRHJXx0Hhk78STnHOd86bpiStiOLiY=; b=uFVaZ2fKffc5GU+3M+jdoHUPme+5s1sPXsSrlAtzmdsx5V6+y3joZ2wD7aKxuHy1dO y+/J/73qY18BqHrC5z6RaCDAjgJzGaL+4wRycZ/F3216MsJ7cpC5mOLrUcZIUyhUs1r5 WjbdY+6tVqNN1UcpdgnwLmkhMKRi02jp4bXyz28SvqP30M1FGOcK/opfyDKj/LapWIha QBZh/E+euSSFLUmQvVS+1GaKXgHgIbT5DBPmG8IuXaBkIxOmCBeYidR/8mf0PT//lNeZ BYk2fmKg7HxWzk+G3mFVuAFLq67UvqhOaRAdNWRd9LvjSfCefRFEa54J97I8U9T6F22I u8zg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=RRSSBNKY; dkim=pass header.i=@codeaurora.org header.s=default header.b="EAkxa/BH"; 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 t85si9466351pfa.110.2019.03.12.19.31.46; Tue, 12 Mar 2019 19:32:02 -0700 (PDT) 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; dkim=pass header.i=@codeaurora.org header.s=default header.b=RRSSBNKY; dkim=pass header.i=@codeaurora.org header.s=default header.b="EAkxa/BH"; 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 S1726793AbfCMCbP (ORCPT + 99 others); Tue, 12 Mar 2019 22:31:15 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:46994 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726426AbfCMCbO (ORCPT ); Tue, 12 Mar 2019 22:31:14 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id F150F60907; Wed, 13 Mar 2019 02:31:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1552444273; bh=RkVRjMrLS0Dchxt7UP6TAUBfGoygtjWqi9+MGDeQBUY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=RRSSBNKYFM+XrX6J/BwJt+66VMToiXHU3tbGIo7xR0vc8cWlQb2exGjzfyMeQTyUX WKN8z3EsfHxpLZg2kLvzK8LdznVgd8BZK9oIqwVkMYCmm+TyarGwE1s5vx7T+FWlqp 5DqQeEGQY78mu0DEo+e+k5pDG1m7UwwhexD2k2go= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.7 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_INVALID,DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.0 Received: from [10.206.25.9] (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: riteshh@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 9F64660159; Wed, 13 Mar 2019 02:31:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1552444271; bh=RkVRjMrLS0Dchxt7UP6TAUBfGoygtjWqi9+MGDeQBUY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EAkxa/BHSjzwMKZwuYZCsF+v1HJbk8UkyXqJsydLQxHRI9Tffn9hrKvVDl9NWoFax r/PlSX2bS1OXK8Pm5YiGRvvECtbeKk26MvP5rlhno6Zhnf+r/6lJyG2NH8qCTyJFhn nwRa1ySymbWNejqTKi3ATvpR/+iFqC1By91WtzU4= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 9F64660159 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=riteshh@codeaurora.org Subject: Re: [PATCH V1 07/11] mmc: cqhci: add quirk for setting DCMD CMD_TIMING To: Sowjanya Komatineni , Adrian Hunter , "ulf.hansson@linaro.org" , "robh+dt@kernel.org" , "mark.rutland@arm.com" , Asutosh Das Cc: "thierry.reding@gmail.com" , Jonathan Hunter , Aniruddha Tvs Rao , "linux-tegra@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mmc@vger.kernel.org" , "devicetree@vger.kernel.org" References: <1551504025-3541-1-git-send-email-skomatineni@nvidia.com> <1551504025-3541-7-git-send-email-skomatineni@nvidia.com> From: Ritesh Harjani Message-ID: <05a6e500-9dc9-1984-9576-44b3a9fdc595@codeaurora.org> Date: Wed, 13 Mar 2019 08:01:05 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/7/2019 11:46 PM, Sowjanya Komatineni wrote: >> On 3/6/2019 6:30 PM, Adrian Hunter wrote: >>> On 2/03/19 7:20 AM, Sowjanya Komatineni wrote: >>>> This patch adds a quirk for setting CMD_TIMING to 1 in descriptor for >>>> DCMD with R1B response type to allow the command to be sent to device >>>> during data activity or busy time. >>>> >>>> Tegra186 CQHCI host has bug where it selects DATA_PRESENT_SELECT to 1 >>>> by CQHCI controller for DCMDs with R1B response type and since DCMD >>>> does not trigger any data transfer, DCMD task complete happens >>>> leaving the DATA FSM of host controller in wait state for data. >>>> >>>> This effects the data transfer task issued after R1B DCMD task and no >>>> interrupt is generated for the data transfer task. >>>> >>>> SW WAR for this issue is to set CMD_TIMING bit to 1 in DCMD task >>>> descriptor and as DCMD task descriptor preparation is done by cqhci >>>> driver, this patch adds cqequirk to handle this. >>>> >>>> Signed-off-by: Sowjanya Komatineni >>>> --- >>>> drivers/mmc/host/cqhci.c | 5 ++++- >>>> drivers/mmc/host/cqhci.h | 1 + >>>> 2 files changed, 5 insertions(+), 1 deletion(-) >>>> >>>> diff --git a/drivers/mmc/host/cqhci.c b/drivers/mmc/host/cqhci.c >>>> index a8af682a9182..b34c07125f32 100644 >>>> --- a/drivers/mmc/host/cqhci.c >>>> +++ b/drivers/mmc/host/cqhci.c >>>> @@ -521,7 +521,10 @@ static void cqhci_prep_dcmd_desc(struct mmc_host *mmc, >>>> } else { >>>> if (mrq->cmd->flags & MMC_RSP_R1B) { >>>> resp_type = 0x3; >>>> - timing = 0x0; >>>> + if (cq_host->quirks & CQHCI_QUIRK_CMD_TIMING_R1B_DCMD) >>>> + timing = 0x1; >>>> + else >>>> + timing = 0x0; >>> I was thinking it would be nice if there was a generic way for drivers >>> to make changes to descriptors before a task is started. Currently >>> there is >>> host->ops->write_l() which would make it possible by checking for >>> host->ops->CQHCI_TDBR >>> register and, in this case, the DCMD tag. We would need to export >>> get_desc(), perhaps rename it cqhci_get_desc() and put it in cqhci.h >>> since it is an inline function. >> We take spin_lock_irqsave after the descriptor is prepared and before writing to TDBR. >> Not sure but tomorrow this may become a limitation for drivers to make changes to descriptors if they edit descriptors in host->ops->write_l() call. >> Though in this case it is not required here. >> >>> Alternatively we could add host->ops for descriptor preparation. >> Both ways sounds good to me. >> But maybe adding a host->ops for descriptor preparation is better way to go, >> since that will be the right interface exposed to make changes to >> descriptors. >> > DCMD descriptor attributes remain same for any host and also task parameters as QBR need to be enabled with DCMD. > So I believe it should be ok if we just add callback to allow hosts to update command parameters of DCMD descriptor only thru cqhci_host_ops. For now we can add host->ops as update_dcmd_desc and pass the task_desc of DCMD for updating any params which host may want to update. > > Also, don’t see any requirement for host specific Task parameter updates in Task descriptor so not sure if there is any need to provide callback for task descriptor data preparation to hosts. > Please confirm. Sure, for now the requirement has come up only for DCMD desc update. Sure we can add task descriptor ops in the similar way later when required. Adrian, please confirm if you are fine with both of above? > >>> What do people think? >>> >>>> } else { >>>> resp_type = 0x2; >>>> timing = 0x1; >>>> diff --git a/drivers/mmc/host/cqhci.h b/drivers/mmc/host/cqhci.h >>>> index 9e68286a07b4..f96d8565cc07 100644 >>>> --- a/drivers/mmc/host/cqhci.h >>>> +++ b/drivers/mmc/host/cqhci.h >>>> @@ -170,6 +170,7 @@ struct cqhci_host { >>>> >>>> u32 quirks; >>>> #define CQHCI_QUIRK_SHORT_TXFR_DESC_SZ 0x1 >>>> +#define CQHCI_QUIRK_CMD_TIMING_R1B_DCMD 0x2 >>>> >>>> bool enabled; >>>> bool halted; >>>>