Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4460725imu; Tue, 29 Jan 2019 01:50:21 -0800 (PST) X-Google-Smtp-Source: ALg8bN6bDTW/oMc//LmqJR9ln7NRKuAIFEq9yImG5tx5RcY1SCPpcW/rFtFBxwvDNuYilUJuB0HS X-Received: by 2002:a17:902:5601:: with SMTP id h1mr25906961pli.160.1548755421338; Tue, 29 Jan 2019 01:50:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548755421; cv=none; d=google.com; s=arc-20160816; b=MQ4AfzDKa3ydyYxh6EHx5FYoxvzxWhgA6df80H2jJ86rODFlziZDlf+//TPPherrcW SR5fCXVCh4ej/a12EfSAe83Qdpj402g8j+ZGWPvfXRv3j9jVdiRvXSpFS3YNKO95uQ1O +MAd6l1LuUsjPgjqULyaheUXVVvIqzGuPKppaKMFQLtxrKrsAWp/lHqpiROdptYL3yLZ afUXsxUC8quUHMMKPQh/Rr4tk4JvBVxVEYFojMQArhxUYHFT6ZFfcD86QlMXoiHuw3xa u98bPlA2YwOxXD0JJzn0sLGC7WhZNmPv7un5ZYxglZ+xGr0ppZoLqA4nckdZ/omcVmyl 2yBQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=r4OgAu/r0jEU6lujj2lT+uSpRTg9en/HeuGEXeyCIEQ=; b=OMZap2T+mPyB9ODVyo4FmfzKGGedo8uhin4M48I/i3To+PNn9SSLrZD+mg06LnAx33 d32GL6QKmA1e/JjbazSIIJkLqi2TvCkDRfIvRCa6/JDeuRZRiag2x1TSL0A2MyuOkTFr 0p7a7i6PwxoYpOQHMG6vS1oazNCCmKsqnxiKWApegRfkFEcZbz1kiaBa9tKJgk6WUYRq TtI3gWbeH7gj5Xr97oUzgyo3qLNEuhvEcOf9tfdiQcYRMzknPCNXRk5vKrDxcO1Q02co 7Xww79X1DRQD3nLeIAycffGs3nfxOuIoQaCSzg1ILIHka92PaOqfIxnJcKYLBwXzZ4w1 Dfjw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@norrbonn-se.20150623.gappssmtp.com header.s=20150623 header.b=cUMukSke; 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 31si23550538plz.263.2019.01.29.01.50.05; Tue, 29 Jan 2019 01:50:21 -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=@norrbonn-se.20150623.gappssmtp.com header.s=20150623 header.b=cUMukSke; 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 S1727990AbfA2Jtm (ORCPT + 99 others); Tue, 29 Jan 2019 04:49:42 -0500 Received: from mail-lj1-f193.google.com ([209.85.208.193]:35619 "EHLO mail-lj1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725810AbfA2Jtl (ORCPT ); Tue, 29 Jan 2019 04:49:41 -0500 Received: by mail-lj1-f193.google.com with SMTP id x85-v6so16927900ljb.2 for ; Tue, 29 Jan 2019 01:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=norrbonn-se.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=r4OgAu/r0jEU6lujj2lT+uSpRTg9en/HeuGEXeyCIEQ=; b=cUMukSke9EktEf0iHUFzMRF+MVGR/o7JaXot6tJNgn6NSnpJ/9p7yb4xouDkeLiM2h dhhLH1l7ju7aN2bwmF0HxGEsIQL8vQz0NIQKZehXHgLsqxVNupNv6n25PfaG0T7QavMz ryy2pFxfr45Wv113RZx5kwv2IJr9HE2iHRDwVRFRllmtc9HpESIq0b/nfW6HYy66Fctd BJ98LMx4nGQRlI3UK3qv88mRTqKh4tNkZ/drwN28lRqEAYswp8/hDdw9hAgvfkVGPZg7 /gh6mqjzi+aEQa/P/D1HhD8x/Oacqz2UTbM2cng+RuF1LXAkTSR1sxmfSLFWJSN8QDkb KsiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=r4OgAu/r0jEU6lujj2lT+uSpRTg9en/HeuGEXeyCIEQ=; b=JInRSWoLw/4VeAmA001a5sbdDOr2oYnsokcEKt7SYSVoiMkodahYlq/+gYPydGIwHd 0Gs/NB2QxjnHqW4M6MyG4UhRt50qdzSdT+TltJ/x/tYGCvS+gE/QR5EWEmgAwVxVmHoh EwYDdgR5wgJHPiYGTYep7Y9Xz5ZaxA0vgGukqKNhbkc4wVY/9NssSJ7eUIvN77Fkc/2Y f+ZYsYfXkbG4DxB53jqC7eRgPRQH1bF4Kry0D/SzjFSRGx01+9uLOrtmnbITEhTNyfyZ v0N6OViwJISv4jyGeuqTUGxKyZ6uOi9YSPqNXPZaFR3imybYA1NLU4+rNrlqWBGSCsew n+gw== X-Gm-Message-State: AJcUukcnXLawh9e6FRztIEzUIrZLALhMhGid80f7aqYt5GNlTXQHPdUf MgS3sJWcyHVNszzD6JeptMMLXg== X-Received: by 2002:a2e:92:: with SMTP id e18-v6mr20230673lji.130.1548755378851; Tue, 29 Jan 2019 01:49:38 -0800 (PST) Received: from [192.168.1.169] (h-29-16.A159.priv.bahnhof.se. [79.136.29.16]) by smtp.gmail.com with ESMTPSA id y23-v6sm3562457ljk.95.2019.01.29.01.49.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 01:49:38 -0800 (PST) Subject: Re: [PATCH v3 1/2] spi: support inter-word delay requirement for devices To: Baolin Wang Cc: Mark Brown , LKML , linux-spi , Rob Herring , Mark Rutland , Lanqing Liu 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> <28617b72-fbc0-4274-d9d1-34c37f03f867@norrbonn.se> From: Jonas Bonn Message-ID: Date: Tue, 29 Jan 2019 10:49:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 29/01/2019 10:35, Baolin Wang wrote: > On Tue, 29 Jan 2019 at 17:14, Jonas Bonn wrote: >> >> >> >> On 29/01/2019 10:04, Baolin Wang wrote: >>> 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. >> >> OK, so it is the SPI clock. That's good. There's a comment in the >> driver that makes it look like it should be the source clock. > > Sorry for my unclear description, what I mean is that it is the SPI > source clock cycles. > >> The problem with a delay in clock cycles is that the faster the clock, >> the shorter the delay. The delay is a property of the slave and the >> slave has a fixed internal clock. This means that if we increase SCK we >> also need to increase the word_delay (in cycles) in order to give the >> slave the same amount of breathing room. > > Sorry for my confusing description, our case requires source clock > cycles for word delay. OK. So the user (perhaps in userspace using spidev) has to know the rate of the IO clock that the SPI controller sits behind and then has to match this to the required delay of the slave device... Doesn't sound very portable. > >> >>> >>> union { >>> int word_delay_us; >>> int word_delay_cycle; >>> } w; >>> >> >> I don't think that's a practical solution. >> >> The register setting in the spi-sprd driver is what... SCK cycles? So >> you'd want word_delay_us * max_speed_hz? >> >> The register setting on my Atmel board is in SPI-clock cycles >> (effectively). So I want word_delay_us*clk_get_rate(spi-clk). > > Okay, so your case is different with Spreadtrum SPI. > No, if your register is source clock cycles then it's the same. On my board, the register setting is source clock cycles, too. It's a straightforward conversion from delay to clock cycles... rough, unscaled formula above. /Jonas