Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4426966imu; Tue, 29 Jan 2019 01:06:25 -0800 (PST) X-Google-Smtp-Source: ALg8bN7u2mYyH5wqrObs19BNaYC/xGyl3t//6n1kWvdvHoN6grVRQIbzesZnWkmhXbisLfOZNN/a X-Received: by 2002:a63:3e05:: with SMTP id l5mr15341135pga.96.1548752785377; Tue, 29 Jan 2019 01:06:25 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548752785; cv=none; d=google.com; s=arc-20160816; b=tDiwH7n60ni3cU3WHFmKNBATAEBCBVZEBCsOw36LncI6igshY53kNy11MbW0nSHDuw BlLpnFWhqN78hxWZjAR305c2PHreZevC4OGOnCeyb5/Du7SD3QMUxSs+a/GLtZchkxkl joALOQUigSrGqU2tGY14Z+I7qsW0nb+zK8k1KZ2d5QjWqLZ0pxjeBdLiX+nLt5w3tLfU jgHTHVuNIAxqKQ6IT6x3rhwxp2qEOv0M569EcTLrQs2In8qeLx9/AGHN/F4E9YJLeROx w8DFFGs4Uoukma9Jl2hx0xGtpjURZxpAOqPl5tgXgP5lXcLrEgz72pAQEw91d+MwE2Fr Xq0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=UMbazCSb1nLk9SjRCQYLf+OiTTp5QrpSco9qD6Gx0AU=; b=xoaz6ruA36iBjWaAqYafeIinAhS/EtV41cnGoVBBSDVo9vPHL8KiDNMeJ9odMqsmni f5SRfMMcqJQXxmUZHfap99xT5MFQMk+P5XKHNl7xcvBaH7y+vrExWId3Yznjva0ZuhdM QHmcGxj3CLkZiuF6pfw+9juWNsr1pUQSZQVdaaip3mZu5bYDAOZv+VXGFsA+x4vidzpw RS76iO50OrQiR7jqe279NGNSJoEzI9KvsyBt9NgPr4gJyAK9JorNsy0t1xQPPkvMLSMq dQfKfK8QzSJonP0pL7Qj1vAFhYQQVXfgGRoEER59vVRnsTQpngQ2gNoDRbZLEKOzVSCq emqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=YaHZ8DKf; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id y7si35466338pgc.236.2019.01.29.01.06.09; Tue, 29 Jan 2019 01:06:25 -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=@linaro.org header.s=google header.b=YaHZ8DKf; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727862AbfA2JE3 (ORCPT + 99 others); Tue, 29 Jan 2019 04:04:29 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:40788 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725298AbfA2JE2 (ORCPT ); Tue, 29 Jan 2019 04:04:28 -0500 Received: by mail-lj1-f196.google.com with SMTP id n18-v6so16771966lji.7 for ; Tue, 29 Jan 2019 01:04:27 -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=UMbazCSb1nLk9SjRCQYLf+OiTTp5QrpSco9qD6Gx0AU=; b=YaHZ8DKfdir0ctMFXX8giR96KjXIRT3UpWFTmAntv+m6n0mHDDq7ATVd02sAkkkZO+ CN1K4EBb0ob92zrSbfNDNiZWCMh93Uc2y1HMNgyhYHrfThp7mVjK/tV3ztc+kFUGyMHA tMAMjiRKYwJ1XrvpFxMKPaTp4twb/s4AJoItQ= 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=UMbazCSb1nLk9SjRCQYLf+OiTTp5QrpSco9qD6Gx0AU=; b=ltrySCg43iM5CqobNFPq1bVWlDpIrOSdKFkrvkEhBlrEpRsw3UHcAqYfk/we/VebX2 k41Hen/sdastEBju9ZRvDeUxzme6lcIOwprUXoxXdPLQOjSC0PQnL0NA71xXLfyQm6eU iGnpFwiseXr3lZXq13aX31180iF84x8wtuWdfkdRU9UMSjotYQRYPxO3A2EC1i6fvEbo NVC4nso9pYV7K72r+LmdjEAlU7FLzFYbpSeovcHvNEumqPa403lghMCXVw7YNg9Y/8QB 2zKEgrGvlNGCTVuSNYuhuvCrm/7sClO2thT/iRNwa7ezNYXNwkyh5lfVIWZFG/yqbUPh j32w== X-Gm-Message-State: AJcUukfLayO1ywBDYjbxYCKrEdIs+7uvtgn36+HEHPAtGjUiLnYWGyMA X/UKjUpNP1WsEl989UJqXeZJm8uDkqUQpkN/oNdf3Q== X-Received: by 2002:a2e:7e04:: with SMTP id z4-v6mr21023898ljc.97.1548752666742; Tue, 29 Jan 2019 01:04:26 -0800 (PST) MIME-Version: 1.0 References: <20190126163220.26421-1-jonas@norrbonn.se> <20190126163220.26421-2-jonas@norrbonn.se> <20190128181038.GF11699@sirena.org.uk> <1b9807aa-3e6e-16f2-a2c2-ebe5e186d904@norrbonn.se> In-Reply-To: <1b9807aa-3e6e-16f2-a2c2-ebe5e186d904@norrbonn.se> From: Baolin Wang Date: Tue, 29 Jan 2019 17:04:15 +0800 Message-ID: Subject: Re: [PATCH v3 1/2] spi: support inter-word delay requirement for devices To: Jonas Bonn Cc: Mark Brown , LKML , linux-spi , Rob Herring , Mark Rutland , Lanqing Liu Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Jonas, On Tue, 29 Jan 2019 at 05:28, Jonas Bonn wrote: > > Hi, > > On 28/01/2019 19:10, Mark Brown wrote: > > On Sat, Jan 26, 2019 at 05:32:19PM +0100, Jonas Bonn wrote: > > > >> @@ -164,6 +166,7 @@ struct spi_device { > >> char modalias[SPI_NAME_SIZE]; > >> const char *driver_override; > >> int cs_gpio; /* chip select gpio */ > >> + uint16_t word_delay; /* inter-word delay (us) */ > > > > This needs some code in the core joining it up with the per-transfer > > word delay similar to what we have for speed_hz and bits_per_word in > > __spi_validate(). Then the controller drivers can just look at the > > per-transfer value and support both without having to duplicate logic. > > > > So spi_transfer already has a field word_delay and it's defined as > _clock cycles_ to delay between words. I defined word_delay in > spi_device as _microseconds_ to delay along the lines of delay_usecs. > > Given that the inter-word delay is a function of the slave device speed > and not of the SPI bus speed, I'm inclined to say that a time-based > delay is what we want (to be independent of bus speed). As such, I want > to know if I should add word_delay_usecs to _both_ spi_transfer and > spi_device? > > There's only one user of word_delay from spi_transfer. Just looking at > it quickly, it looks like it wants the word_delay in > SPI-controller-clock cycles and not SCK cycles which seems pretty broken > to me. Adding Baolin and Lanqing to CC: for comment. Could we rework > that to be microseconds and do the calculation in the driver? The Spreadtrum SPI controller's word delay unit is clock cycle of the SPI clock, since the SPI source clock can be changed, we can not force user to know the real microseconds. But can we change it to a union structure? not sure if this is a good way. union { int word_delay_us; int word_delay_cycle; } w; -- Baolin Wang Best Regards