Received: by 10.213.65.68 with SMTP id h4csp334500imn; Fri, 6 Apr 2018 00:36:25 -0700 (PDT) X-Google-Smtp-Source: AIpwx48VsipQsn2zRA1cZ0ZTC7c9ci8o/RMAP9UnioA5ddTmlY9BxydIKglk7Lrsy/wUyhS+7qpn X-Received: by 2002:a17:902:7c8d:: with SMTP id y13-v6mr15130422pll.398.1523000185861; Fri, 06 Apr 2018 00:36:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523000185; cv=none; d=google.com; s=arc-20160816; b=sCn7D8tQGhTHxS9YwBz9NzLkIZCD22KTAtuWPov6iON3AgShDiWOE81TEzmr/Qd/Kn cyg1k7Q6kfqV90f4X9Mcj1F68B1sHWIwEHdiMe6yrki4a0gXOaW4/jiUopET4UnRIwar qn+XvaztEwbaPc8cbREfsoCiRbsvoVI7Pokk56QnhBl+SPFk06vHMPw4h4EpItRODCDQ DAlAuEy8Xhci4DiIZbFldOOVK1/Yaz/Qc+RB+6Ee6FryeVA8SVB/dcYTjXgq5tOHTy8r JzW8JDTautyW9lEmzCqRMftNguwFrFwr3wlaU5iGh+Drb1s6HR7TZvVKpaQwaCKK6i6V TJsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date :arc-authentication-results; bh=2jdJA73YDr2jiOdjWdieLKNw2ijsyw694ecu0NMO9Ng=; b=n0AAyd8XyhN3kLR9FW7LRlgKbSHOApYSs2Em5kkVAZr0M8o5+h0oJOoHSHJEVfm5mq F1mMnQIQ4c6PrvwN5beHFnnwBKBpcEyFOO1YIWQR55nVUWcAldsfJvjhNDqYi8NUf6l7 bXTU1wPie7hXO+JMwgALNmhNctAqFlw7dOiW3x6DKp/XnK7od0U1YL00U+fppjbEe/ea VC7Wm/QRiCZKsyNEkL/WlLbElgmhsfmDNjwzmVjiIBY3FRzo6ibAXnZB/KbSk9GsjTQk 3IYHjynQhEq+rhKkG5H/iUujkukp5WHO0KsDn8Vs1jt6erJZhFSMN1qovce3i0TiUfde nZEQ== ARC-Authentication-Results: i=1; mx.google.com; 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 a61-v6si7754546pla.400.2018.04.06.00.36.12; Fri, 06 Apr 2018 00:36:25 -0700 (PDT) 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; 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 S1751896AbeDFHey convert rfc822-to-8bit (ORCPT + 99 others); Fri, 6 Apr 2018 03:34:54 -0400 Received: from mail.bootlin.com ([62.4.15.54]:49149 "EHLO mail.bootlin.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751711AbeDFHex (ORCPT ); Fri, 6 Apr 2018 03:34:53 -0400 Received: by mail.bootlin.com (Postfix, from userid 110) id A773B207F5; Fri, 6 Apr 2018 09:34:51 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mail.bootlin.com X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,SHORTCIRCUIT shortcircuit=ham autolearn=disabled version=3.4.0 Received: from localhost (LStLambert-657-1-97-87.w90-63.abo.wanadoo.fr [90.63.216.87]) by mail.bootlin.com (Postfix) with ESMTPSA id 792722038E; Fri, 6 Apr 2018 09:34:41 +0200 (CEST) Date: Fri, 6 Apr 2018 09:34:41 +0200 From: Maxime Ripard To: Sergey Suloev Cc: Mark Brown , Chen-Yu Tsai , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-spi@vger.kernel.org Subject: Re: [PATCH v3 3/6] spi: sun6i: restrict transfer length in PIO-mode Message-ID: <20180406073441.xesojvzc3deljhoy@flea> References: <20180403154449.2443-1-ssuloev@orpaltech.com> <20180403154449.2443-4-ssuloev@orpaltech.com> <20180404065048.n76r3ytuznd6fqsl@flea> <20180405091913.ky4dnmszoobn2xry@flea> <20180405131735.GB12349@sirena.org.uk> <8159c3a5-af74-9f13-aedb-7ecc708bdff6@orpaltech.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: 8BIT In-Reply-To: <8159c3a5-af74-9f13-aedb-7ecc708bdff6@orpaltech.com> User-Agent: NeoMutt/20180323 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 05, 2018 at 04:44:16PM +0300, Sergey Suloev wrote: > On 04/05/2018 04:17 PM, Mark Brown wrote: > > On Thu, Apr 05, 2018 at 12:59:35PM +0300, Sergey Suloev wrote: > > > On 04/05/2018 12:19 PM, Maxime Ripard wrote: > > > > The point of that patch was precisely to allow to send more data than > > > > the FIFO. You're breaking that behaviour without any justification, > > > > and this is not ok. > > > I am sorry, but you can't. That's a hardware limitation. > > Are you positive about that? Normally you can add things to hardware > > FIFOs while they're being drained so so long as you can keep data > > flowing in at least as fast as it's being consumed. > > Well, normally yes, but this is not the case with the hardware that I own. > My a20 (BPiM1+) and a31 (BPiM2) boards behaves differently. With a transfer > larger than FIFO then TC interrupt never happens. Because you're not supposed to have a transfer larger than the FIFO, but to have to setup at first a transfer the size of the FIFO, and then when it's (or starts to be) depleted, fill it up again. That's the point of the patch you're reverting, and if it doesn't work, you should make it work and not simply revert it. Maxime -- Maxime Ripard, Bootlin (formerly Free Electrons) Embedded Linux and Kernel engineering https://bootlin.com