From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f50.google.com (mail-wm1-f50.google.com [209.85.128.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B35A030567E for ; Sat, 30 May 2026 10:20:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.50 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780136430; cv=none; b=LGMqzHMoP9SaECLaUo99X7J/nAOukuSAG/2yirST97TuJVGDFU9bb+EbUBSKbL0NoQ992fF1kiDvjQuWBBI3JCSZWIlUcC5pH21NPGQGVkty6El+sAvpMB3FL/l/rBkU3D5G31GnxGlzpzsyb+rhTr0nqxmZiXp8f4jiO7f0UWo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780136430; c=relaxed/simple; bh=35VdMsjmS0v8dh1CHRiPhqq+k7uITgm7avOyoT5qusA=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=m5j7BtxWigOdJGLWDAyRxXYqiikZFtrUspAHoJBlA54tPtLsecIkojoFH42g3/Ms1xy2Zv3raGhTwZIQbg8cF/aT5spoT0KsUBL+NKSbmaenPCFZAMc95mQdgTnOW+0v49E47rDbDba0qTKx1QQk+2nZnF5j4Ze3I35XenX+y5I= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=ZAItoU4o; arc=none smtp.client-ip=209.85.128.50 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="ZAItoU4o" Received: by mail-wm1-f50.google.com with SMTP id 5b1f17b1804b1-49041e84237so70183225e9.1 for ; Sat, 30 May 2026 03:20:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1780136427; x=1780741227; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=iUCw4AYxN77fr8cBRoZeZFoHBmuyuGZ+QkqYbRydK8M=; b=ZAItoU4oou5vEoHAtmJijjFpXtVUrUX7XW92SJOJ3FgBfhnGo4/50sh8cySx1/TQNF eYerKBS8DcXIyCiazVP1tL9M04rfFfAwgBkpYE/MGDHZsFAws4aLkhJCQR1+hjhXeP1M ilXm9AL6BDWBvvEJjXLclEXtJiXNDKPJgjDcGRCjEDFO9XBmudhSpz6Ncu0FXOp0ABaI qKkRe/udZSJZ/PZF7nmEOGXMXYtwsb/dDebP9/NALd1zmetmVYSWMh6rJFOunEM6lq1/ eO7xd484pB86lubdWTdfjEwog9ecdSzvrJyv4lZ/i6BS9b2aNtBU1+kXmOybQ/nAmn/y 66OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780136427; x=1780741227; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=iUCw4AYxN77fr8cBRoZeZFoHBmuyuGZ+QkqYbRydK8M=; b=gqAcHDm1MK9aAF6r3h8D85REeAE1OTlxgNQxnWR+aZMTSa0JgaS+Sd4zQ7sG6CYmfe 9NeLjcHJp++Zv/uXLfNl798UVyrz2vDAEHmAsMM1KvZ5ZS18TJ+TpLidSQVQnNdlxBjx s9xbeRLW7wfHd5Dv1rgTvi8JLRe1BCvMh43rAI1tuwpNLizyTO4myCmnaQAuW+2FVC2C uZLxTM2l3IUSMtXLMVsnP7xGjaTy+EgmBLxNfTgpOooA0Ru173oGROfd0jSeM3vkWMNR cYpAY7oEuaOXyfeyjX5kNUB1RSc44ympQUEPQ9VE1z8X+ihc2omFFeVKD/WSG2ijgk3z M3Ew== X-Forwarded-Encrypted: i=1; AFNElJ8XgWx0JtnQ2Jbft+4a+WqDijtzQxKO2zKOtZgJjY8KuEIMZkuwQ6Ps3ZkFSLvm90SBhIziCstsuA2Z3fQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyuWfTgfHqwIKv38SKiUlVG7DQ3UR1APL7dBQQKHelOehtqGyUd B3k5aQPWaWUov7LaKOJ/v8/Nyn48JnFi3OpqqwCkioApYuFFZ3RtGXiX X-Gm-Gg: Acq92OECnJDQsmj8P5jdO+ASDzDiqtCEgsyjklvKcER38NySYObFxIlbdlpmMNrfWhf y6oI0W62Z72OQctjBqrasW8KsWbtlwUWUprKVzj299W2NNQsUWAxxh1I9Jm5GC+0kliGI1bwnVc fD/pOFAZ5KvNpieDJExxUmA/smTc+387jgSBIEjZUYKkSP86EVMG+OW/oa7cwJRzPlVoHDgQP6Y F62J/XONBUbWL2H0I8dbIUvAp/Ma29YoNaly+PGnxtK6OqD9ZkXpmpb8yBacY0N3/EFGToo0pwy pG2yZOuhiPnYD9n8B/hp3yGH2TzovpukOlVSG/DfnfReGC5WTrEwQRibH/tt3VbRIArn+jmjFqk 4fRK7JOTzsomioJD+MfJq42/MB8HPEnzP5jWqvIJ2WdJ9uF16YxPbWHbPGlvyh+aIplE7WikM1s 6OHadC+Mw4C6ndSu2WObWEAPXcskg9857vOfr4P9Pi34omH3E5m28ONyPeFOBFPdRpQcAca4A= X-Received: by 2002:a05:600c:19cb:b0:48a:5339:a46 with SMTP id 5b1f17b1804b1-490a2a43c41mr42348235e9.9.1780136426957; Sat, 30 May 2026 03:20:26 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4909c128dacsm31436165e9.32.2026.05.30.03.20.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 30 May 2026 03:20:26 -0700 (PDT) Date: Sat, 30 May 2026 11:20:25 +0100 From: David Laight To: Mark Brown Cc: Peter Collingbourne , Jani Nikula , Ville =?UTF-8?B?U3lyasOkbMOk?= , Christophe Kerello , Patrice Chotard , Boris Brezillon , linux-spi@vger.kernel.org, linux-kernel@vger.kernel.org, Simona Vetter , Randy Dunlap Subject: Re: [PATCH v2] iopoll: use udelay() for initial polling Message-ID: <20260530112025.66897837@pumpkin> In-Reply-To: <19509a36-cf7b-4f2b-a25c-2c1293c19b6c@sirena.org.uk> References: <20260519102446.209723-1-peter@pcc.me.uk> <4e8d842d-790a-44ad-8b80-a0a8df1fde2b@sirena.org.uk> <20260529122016.0059f55d@pumpkin> <19509a36-cf7b-4f2b-a25c-2c1293c19b6c@sirena.org.uk> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 29 May 2026 22:56:23 +0100 Mark Brown wrote: > On Fri, May 29, 2026 at 12:20:16PM +0100, David Laight wrote: > > > I think I remember someone saying that the spi hardware interface normally > > generates an interrupt when the request completes? > > So for spi this is only fall-back code for a few systems. > > For something like spi-mem I'd expect to have interrupt support, we go > all the way down to fully bitbanged though. You also often have > copybreak cutoffs for smaller transfers (and quicker operations) where > it's more efficient to poll for completion than use an interrupt, or > PIO rather than DMA. I do wonder about copybreak cutoffs especially for systems with iommu (which has started including x86 systems). Many years ago a colleague got a figure of ~1200 bytes for a sparc sbus card. I suspect that the iommu setup code has got more complex (and slower) since then and the memory copies faster (especially if you can do overlong aligned copies that include the required data). For spi-mem writes (max size is probably 256 bytes) that take 100s of us it is best the sleep (for timer or isr). spi-mem reads are another matter since the only delays are those needed to bit-bang the physical device - which might be at over 100MHz and 4 (or even 8) data bits at a time. Possibly worth using DMA for the data (to avoid leisurely PCIe reads) but polling (ideally host memory) for completion to avoid the cost of the ISR as well as avoiding context switches. For the much slower smbus and i2c you pretty much always want to offload the 'bit bang' to hardware and wait for an interrupts. (I've seen ethernet drivers 'bugger' the system by repeatedly reading the phy status - that could be done 1 bit every timer interrupt.) > > > The code has this comment: > > /* Wait for the write - typically 0.6ms (max 5ms). > > * In spite of the datasheet values, I'm seeing 200us writes. */ > > It waits 200us and then polls every 50us for 2 seconds. FWIW I wrote the comment, the code below it, and the logic on the fpga that converts the PCIe slave cycles into signals to the memory chip. What I/we never resolved was why some chips/boards failed to act on the 'read status' command issued after the first delay. > You can also get fun with things like contention on shared buses. Indeed - and in places you don't realise. In some cases repeated reads of a slow device can restrict bus throughput enough to make DMA requests underrun (eg trying to use an LCD panel on a SA1100/SA1101 strongarm system). -- David