Received: by 10.223.185.116 with SMTP id b49csp6323904wrg; Thu, 8 Mar 2018 05:42:34 -0800 (PST) X-Google-Smtp-Source: AG47ELutpOAOlZYig0Qkx1v1xMzm86jqriRzwKAQs4/IbVj2rdFsVFsvnymvzd2n9jhekallursC X-Received: by 2002:a17:902:6b43:: with SMTP id g3-v6mr12214368plt.153.1520516554272; Thu, 08 Mar 2018 05:42:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520516554; cv=none; d=google.com; s=arc-20160816; b=kNQNjjPc8tuPqeCxx9J0tEk0AuSwIUGNSdSDEhXMRfihJK+FUHD1DqEdam24KZ2fzQ 9OX47804YYc9jkPQUA9e4G/o5Ij93KD71xjkDLqVE2d+um4/iqSm4u2+CTPStGsIaVw4 uFPvrjAurmHUUA+LditD9OuAUw42IWZHqeKf38Bgj3ix6LV5xAxo+eT/DHuFkyRkC9Ud pn3gtz5ap8uW2ekUFQXoirLbp8yBsJeMj9sievxWqbKWn85RS3mbgtvoXUZh50b/AA6A YNk3MNvC8UQ/RqpDp7Gfj+SeszlcdWQoF1+O9LMXgLKO+5F+ky1PqhDosMg0RwP7/29+ BQPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:message-id:references :in-reply-to:subject:cc:to:from:date:content-transfer-encoding :mime-version:dkim-signature:dkim-signature :arc-authentication-results; bh=EINyeOFZ6VjutKm3cYes/Q7tvPsE9j2vHRPfT7IDsz4=; b=bvkHPT1mfaRmVYjALwHLFxpA6Z3ekN9KUSzU+chLQSP1mYc1rYvEWJIJyzTSgUOI49 wLBP60j1uidlgp67+CUXmwfODu2lONBP9uPtZHLsLePCamtEDHPRFCIZ4bgrrfHGghJ3 Q1yARUsFy6Sa7O7SsDQrVpZB0kXQqsvKJ1hd1aJbRCs1jWnvU+nqX6EuXPCiZGcfFv/8 3UsDL/0zRe9qoyLcIRsUN3elQaohh6yOQ2RB9edLXV5w4/zH5rWSOlCn28sU9CFzyf86 /6xqcsTdogjY/Hc29BoIItmnSXuo0htBHhFcBA+NeGdupraxEr/nw+a+uOp4jS5yLZBX Jq5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=UgM6NTHu; dkim=pass header.i=@codeaurora.org header.s=default header.b=P9yFKg3s; 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 c12-v6si14655856plo.278.2018.03.08.05.42.20; Thu, 08 Mar 2018 05:42:34 -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; dkim=pass header.i=@codeaurora.org header.s=default header.b=UgM6NTHu; dkim=pass header.i=@codeaurora.org header.s=default header.b=P9yFKg3s; 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 S966329AbeCHNkv (ORCPT + 99 others); Thu, 8 Mar 2018 08:40:51 -0500 Received: from smtp.codeaurora.org ([198.145.29.96]:46150 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966282AbeCHNkt (ORCPT ); Thu, 8 Mar 2018 08:40:49 -0500 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id BECD460390; Thu, 8 Mar 2018 13:40:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520516448; bh=hQ9Tu/GwS8V+fwJTBfqdP0/vTYK/KVJJbSu0wpOMOlk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=UgM6NTHu2Oi25wij/hEkGOp2mn8AyNNYUVU0IqOzaFIzsCLC8cKbso0eLWvdNUQbo ewcp+8XIBprp7G3LzIa8PGN0Cfids+m1XattCjmvCxuz1+IobiYwQXvrwSpB5xFsG+ 9uaUg+iyy/r6NLEXAKexsFNomfkczX0ZKZNY97GY= 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.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from mail.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.codeaurora.org (Postfix) with ESMTP id 959A160386; Thu, 8 Mar 2018 13:40:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1520516447; bh=hQ9Tu/GwS8V+fwJTBfqdP0/vTYK/KVJJbSu0wpOMOlk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=P9yFKg3s4hL5OFi+DZT7GUjeFZqxoEIRZ/wO33mn/V7xPnQbVKk6bmRnL0lrOvVSl CDGCB2O7e2gSP1tCBunA15E49tvfpYZk/5TE49L4g/qdaY0fmKjD8oEm5xfgeBwGA1 P5E7MoyqNj65MM1wKDdwsFVc9y9OkZMCRSNEzPBc= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 08 Mar 2018 19:10:47 +0530 From: Abhishek Sahu To: Andy Gross Cc: Wolfram Sang , David Brown , Sricharan R , linux-arm-msm@vger.kernel.org, linux-soc@vger.kernel.org, linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 04/12] i2c: qup: schedule EOT and FLUSH tags at the end of transfer In-Reply-To: <20180227223654.GE20901@hector.attlocal.net> References: <1517644697-30806-1-git-send-email-absahu@codeaurora.org> <1517644697-30806-5-git-send-email-absahu@codeaurora.org> <20180227223654.GE20901@hector.attlocal.net> Message-ID: X-Sender: absahu@codeaurora.org User-Agent: Roundcube Webmail/1.2.5 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2018-02-28 04:06, Andy Gross wrote: > On Sat, Feb 03, 2018 at 01:28:09PM +0530, Abhishek Sahu wrote: >> A single BAM transfer can have multiple read and write messages. >> The EOT and FLUSH tags should be scheduled at the end of BAM HW >> descriptors. Since the READ and WRITE can be present in any order >> so for some of the cases, these tags are not being written >> correctly. >> >> Signed-off-by: Abhishek Sahu >> --- >> drivers/i2c/busses/i2c-qup.c | 54 >> ++++++++++++++++++++------------------------ >> 1 file changed, 24 insertions(+), 30 deletions(-) >> >> diff --git a/drivers/i2c/busses/i2c-qup.c >> b/drivers/i2c/busses/i2c-qup.c >> index bb83a2967..6357aff 100644 >> --- a/drivers/i2c/busses/i2c-qup.c >> +++ b/drivers/i2c/busses/i2c-qup.c >> @@ -560,7 +560,7 @@ static int qup_i2c_set_tags_smb(u16 addr, u8 >> *tags, struct qup_i2c_dev *qup, >> } >> >> static int qup_i2c_set_tags(u8 *tags, struct qup_i2c_dev *qup, >> - struct i2c_msg *msg, int is_dma) >> + struct i2c_msg *msg) >> { >> u16 addr = i2c_8bit_addr_from_msg(msg); >> int len = 0; >> @@ -601,11 +601,6 @@ static int qup_i2c_set_tags(u8 *tags, struct >> qup_i2c_dev *qup, >> else >> tags[len++] = data_len; >> >> - if ((msg->flags & I2C_M_RD) && last && is_dma) { >> - tags[len++] = QUP_BAM_INPUT_EOT; >> - tags[len++] = QUP_BAM_FLUSH_STOP; >> - } >> - > > So lets say you have multiple read and 1 write message. These changes > will send > a EOT/FLUSH for all reads. I think the intent here was that the last > read > message (not the last message) would have the EOT+FLUSH. Can there be > an issue > with sending EOT/FLUSH for all reads? And how does this mesh up with > the BAM > signaling? > Thanks Andy and Austin for reviewing these patches. The role of FLUSH and EOT tag is to flush already scheduled descriptors in HW. EOT is required only when descriptors are scheduled in RX FIFO. If all the messages are WRITE, then only FLUSH tag will be used. Let’s take following example READ, READ, READ, READ Currently EOT and FLUSH tags are being written after each READ. If we get the NACK for first READ itself, then flush will be triggered. It will look for first FLUSH tag in TX FIFO and will stop there so only descriptors for first READ will be flushed. We need to clear all scheduled descriptors to generate the completion. Now this patch is scheduling FLUSH and EOT only once after all the descriptors. So, flush will clear all the scheduled descriptors and BAM will generate the completion interrupt. For multiple READ and single WRITE also, this will work fine. I tested with - single xfer with multiple read messages - single xfer with multiple write messages - single xfer with multiple alternate read and write messages for non-connected address in forceful DMA mode which will generate the NACK for first byte itself. Thanks, Abhishek