From patchwork Fri Oct 7 10:55:47 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Kurtz X-Patchwork-Id: 9366025 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 36B20600C8 for ; Fri, 7 Oct 2016 10:55:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 22D8F29510 for ; Fri, 7 Oct 2016 10:55:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 147F829514; Fri, 7 Oct 2016 10:55:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7A92F29510 for ; Fri, 7 Oct 2016 10:55:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755211AbcJGKzw (ORCPT ); Fri, 7 Oct 2016 06:55:52 -0400 Received: from mail-pa0-f42.google.com ([209.85.220.42]:35977 "EHLO mail-pa0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754738AbcJGKzv (ORCPT ); Fri, 7 Oct 2016 06:55:51 -0400 Received: by mail-pa0-f42.google.com with SMTP id ry6so21348899pac.3 for ; Fri, 07 Oct 2016 03:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=from:to:cc:subject:date:message-id; bh=OvO2NWAvbrd71yBnvVbpEwbcXsoSXcVCx4jGcrnPqlU=; b=LM8CtIkNiROS+pK4nBSnxOiwuXYZ38PpU2xoP/uUFuhWEzIgdellR+yQKzLnK13rzx frE5pjSCnObLkYKrA0+PtJHG1PWuDxYZf11mH5DwLwYggZ5IfPsMwMHPUQifzWob3IuM ExC8Wu8yc3WYrykSCpPKF4hSyI35RsdHXY+Uo= 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=OvO2NWAvbrd71yBnvVbpEwbcXsoSXcVCx4jGcrnPqlU=; b=Wa8dBSyV3ROUg9YRT1X2jjCoULcWDYkPSNvlGunevVqMfulxUEr95p0NV9b6L9TFCN ZgAlckpuM2eLUYr3MrEIUxHzVVFA2tVEIS5dboZytE+OFNpdL3i/ouh+uS79Fhu9S9ss cnIm2DGQPgUcAzCqfHv7/jH8zs24GUvdlTc+kwB5Fb7L5ifhJBkbBi9+jlq6Fojgd0zS 2bh5AAP3pj0NWtbd1ZTidzaGnb5TOw/SfuQxLbfjR7Khd8grbrH3mIYCfU4hBagNnBO3 yAOlzs04f4Msjg63C/uJ3oxJE9JfZb1lBQb/YDAU6h6qbGxD6oD0N7J8aSWJxlxZFXrg NMTg== X-Gm-Message-State: AA6/9Rn81yeHKcrlbySjLVdcI9kWllmHi45HyHymfQsktUHOaTEM1PFzi49bPEUAHl2tbCV9 X-Received: by 10.66.41.17 with SMTP id b17mr4250571pal.53.1475837750635; Fri, 07 Oct 2016 03:55:50 -0700 (PDT) Received: from djkurtz-z840.tpe.corp.google.com ([172.30.210.11]) by smtp.gmail.com with ESMTPSA id m11sm12944661pfi.30.2016.10.07.03.55.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 07 Oct 2016 03:55:50 -0700 (PDT) From: Daniel Kurtz Cc: dianders@chromium.org, gwendal@chromium.org, Daniel Kurtz , Mark Brown , linux-spi@vger.kernel.org (open list:SPI SUBSYSTEM), linux-kernel@vger.kernel.org (open list) Subject: [PATCH] spi: change post transfer udelay() to usleep_range() for long delays Date: Fri, 7 Oct 2016 18:55:47 +0800 Message-Id: <1475837747-7385-1-git-send-email-djkurtz@chromium.org> X-Mailer: git-send-email 2.8.0.rc3.226.g39d4020 To: unlisted-recipients:; (no To-header on input) Sender: linux-spi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-spi@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The spi_transfer parameter delay_usecs allows specifying a time to wait after transferring a spi message. This wait can be quite long - some devices, such as some Chrome OS ECs, require as much as 2000 usecs after a SPI transaction, before it can respond. (cf: arch/arm64/boot/dts/nvidia/tegra132-norrin.dts: google,cros-ec-spi-msg-delay = <2000> ) Blocking a CPU for 2 msecs in a busy loop like this doesn't seem very friendly to other processes, so change the blocking delay to a sleep to allow other things to use this CPU (or so it can sleep). This should be safe to do, because: (a) A post-transaction delay like this is always specified as a minimum wait time (b) A delay here is most likely not very time sensitive, as it occurs after all data has been transferred (c) This delay occurs in a non-critical section of the spi worker thread so where it is safe to sleep. Two caveats: 1) To avoid penalizing short delays, still use udelay for delays < 10us. 2) usleep_range() very often picks the upper bound, an upper bounds 10% should be plenty. Signed-off-by: Daniel Kurtz --- drivers/spi/spi.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c index a0b6e14..31b4440 100644 --- a/drivers/spi/spi.c +++ b/drivers/spi/spi.c @@ -845,8 +845,14 @@ static int spi_transfer_one_message(struct spi_master *master, if (msg->status != -EINPROGRESS) goto out; - if (xfer->delay_usecs) - udelay(xfer->delay_usecs); + if (xfer->delay_usecs) { + u16 us = xfer->delay_usecs; + + if (us <= 10) + udelay(us); + else + usleep_range(us, us + DIV_ROUND_UP(us, 10)); + } if (xfer->cs_change) { if (list_is_last(&xfer->transfer_list,