From patchwork Fri Jun 13 18:13:32 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Doug Anderson X-Patchwork-Id: 4351341 Return-Path: X-Original-To: patchwork-linux-samsung-soc@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.19.201]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 7DF6DBEEAA for ; Fri, 13 Jun 2014 18:14:26 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 8E9E220211 for ; Fri, 13 Jun 2014 18:14:25 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 940D9201D3 for ; Fri, 13 Jun 2014 18:14:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751357AbaFMSN7 (ORCPT ); Fri, 13 Jun 2014 14:13:59 -0400 Received: from mail-qa0-f73.google.com ([209.85.216.73]:42308 "EHLO mail-qa0-f73.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751345AbaFMSN5 (ORCPT ); Fri, 13 Jun 2014 14:13:57 -0400 Received: by mail-qa0-f73.google.com with SMTP id m5so448807qaj.2 for ; Fri, 13 Jun 2014 11:13:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=SxpgxO0WPUICTZb1C161P8qBM4HwSji7cfOAnhRgKoc=; b=cbKDDALIchN7V1OIyI5Ady5Y19ID/8x7SmLcYtbjOz8uzIAp3LO18+kCzqdwivRO2c o0wdsm/bfVRQL5oesHQNj7AIOmnMGJj4UcRvoobkYxdHaE42KoZCK0jq1wsOfUi8FUnM C3AZ16s/PyxoJFqvMzxzHxdrALQGrnEDWShwBrY5Tv0KuUMLmiq7pKU2b3v45uR/dC2J LSZPS9rdlZC0rAkoHpYT4/RCYnUj5TkxWJPKqYh/Wwpl63kkN9mq0Ke+chRnjRxAA7x/ pE2pfMJ8abd7VEM3UN9k3BJeImJTBY0ToRJiQIiBu28PeeMvYKenDrtuUBVJ87mYn76l s0JQ== X-Gm-Message-State: ALoCoQk7Qf+ldzYXt78EeHr0LgNPLyXKcNF5Jmxlarz1Wv72wu4ax04PWjw+jm0qm53RqKi2bdm5 X-Received: by 10.236.1.198 with SMTP id 46mr739579yhd.16.1402683236725; Fri, 13 Jun 2014 11:13:56 -0700 (PDT) Received: from corp2gmr1-2.hot.corp.google.com (corp2gmr1-2.hot.corp.google.com [172.24.189.93]) by gmr-mx.google.com with ESMTPS id n68si361619yhj.5.2014.06.13.11.13.56 for (version=TLSv1.1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 13 Jun 2014 11:13:56 -0700 (PDT) Received: from tictac.mtv.corp.google.com (tictac.mtv.corp.google.com [172.22.72.141]) by corp2gmr1-2.hot.corp.google.com (Postfix) with ESMTP id 7F5875A430C; Fri, 13 Jun 2014 11:13:56 -0700 (PDT) Received: by tictac.mtv.corp.google.com (Postfix, from userid 121310) id 196A9806D3; Fri, 13 Jun 2014 11:13:56 -0700 (PDT) From: Doug Anderson To: Samuel Ortiz , Lee Jones , Kukjin Kim Cc: Tomasz Figa , broonie@kernel.org, sjg@chromium.org, olof@lixom.net, javier.martinez@collabora.co.uk, ch.naveen@samsung.com, swarren@wwwdotorg.org, khilman@linaro.org, ajaynumb@gmail.com, rahul.sharma@samsung.com, tushar.b@samsung.com, linux-samsung-soc@vger.kernel.org, Doug Anderson , linux-kernel@vger.kernel.org Subject: [PATCH 1/2] mfd: cros_ec: spi: Fix end of transfer on devices with no spi-msg-delay Date: Fri, 13 Jun 2014 11:13:32 -0700 Message-Id: <1402683213-23120-1-git-send-email-dianders@chromium.org> X-Mailer: git-send-email 2.0.0.526.g5318336 Sender: linux-samsung-soc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-samsung-soc@vger.kernel.org X-Spam-Status: No, score=-7.5 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP cros_ec_spi makes the assumption that a 0-length message will put the spi chip select back to normal (non cs_toggle mode). This used to be the case back on kernel-3.8 on the spi-s3c64xx driver but doesn't appear to be true anymore. It seems like it was a pretty questionable assumption to begin with, so let's fix the code to be more robust. We know that a message with a single 0-length segment _will_ put things back in order. Change cros_ec_spi to handle this. This wasn't a problem on the main user of cros_ec_spi upstream (tegra) because it specified 'google,cros-ec-spi-msg-delay'. Signed-off-by: Doug Anderson --- drivers/mfd/cros_ec_spi.c | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/mfd/cros_ec_spi.c index 0b8d328..0cbc3db 100644 --- a/drivers/mfd/cros_ec_spi.c +++ b/drivers/mfd/cros_ec_spi.c @@ -266,18 +266,14 @@ static int cros_ec_command_spi_xfer(struct cros_ec_device *ec_dev, dev_err(ec_dev->dev, "spi transfer failed: %d\n", ret); } - /* turn off CS */ + /* + * Turn off CS, possibly adding a delay to ensure the rising edge + * doesn't come too soon after the end of the data. + */ spi_message_init(&msg); - - if (ec_spi->end_of_msg_delay) { - /* - * Add delay for last transaction, to ensure the rising edge - * doesn't come too soon after the end of the data. - */ - memset(&trans, 0, sizeof(trans)); - trans.delay_usecs = ec_spi->end_of_msg_delay; - spi_message_add_tail(&trans, &msg); - } + memset(&trans, 0, sizeof(trans)); + trans.delay_usecs = ec_spi->end_of_msg_delay; + spi_message_add_tail(&trans, &msg); final_ret = spi_sync(ec_spi->spi, &msg); ktime_get_ts(&ts);