Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4325594yba; Sun, 12 May 2019 10:08:16 -0700 (PDT) X-Google-Smtp-Source: APXvYqwz1Fsrye4VzjR9SlRnhb5E0fCd4ysb2/fNE47S3+ia0x68kqoHRUf+UEp6fuACsUgDIlu1 X-Received: by 2002:a63:441c:: with SMTP id r28mr26570323pga.255.1557680896346; Sun, 12 May 2019 10:08:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557680896; cv=none; d=google.com; s=arc-20160816; b=z8us0VN5SvrJuk8fGxRxPFGplrIWy2uCLfT/NQmXM+SLsM4lJ2qkR5yv8Sd//pO/6D Mjouw63mZRE9GVYF21Uji9vEtYevvZ96wC4efcJowN4NsxKaio04s3+SgI6YsFAxKdo0 J2oL0NTGDHWNTvSmthLxaw4/2W5wNgX7RhNcwKPTTF7w1lJzkiSmr1BpDwoyI937jlzq U1jH1OklfwqG8YD4021WojZ8IS58wlgwy1w4OYNX4TqoSZ7crz1ywncsvJF/UocFKEQK w/0iEqCbA9SZN1A7FHhhrOt30VOzBamiq2gVFHO9Gk0Z1GDaAZbzj/2a0EPU1r2xe8DC 95Sw== 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-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ndywyr82/NFXN1lC+orQHknEu4sY+tlBor1wOLnwHSE=; b=q+6JGCvvYBDyCBZSpre9Lw/OdKwK1XZ9nqKzTNzv/TA/xwJmE5q9qJYmvbTD1UiJ+8 jvGatdS1uJMGLOGDfJ4YmkMi0W/mUnMKq0h7wcf6sv83ai/IgxyHMZwW+2TzckuLKmDe oLbJS/IxW8qjqytaZ31CakG1GFffcYFKw8MKbr9ROgcJWd8UG8+c19wZ1rhFyygbgr04 l8QrySOUJc3y0XfqSAVdvE5n5Fu/Q2SAMEfd7wTwmY0mgGflT1KnyTINKREqfuiLTvL/ SnYc20lphZILTsExh3VCJtiKRG+Fnc5I9SRy9qs2XEcTttOj5H8CvGMc79tDpVjgN0rY 0HWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=Opwi9hM5; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id k75si13465696pgc.515.2019.05.12.10.08.00; Sun, 12 May 2019 10:08:16 -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; dkim=fail header.i=@sirena.org.uk header.s=20170815-heliosphere header.b=Opwi9hM5; 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=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727003AbfELRFs (ORCPT + 99 others); Sun, 12 May 2019 13:05:48 -0400 Received: from heliosphere.sirena.org.uk ([172.104.155.198]:49464 "EHLO heliosphere.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726883AbfELRFr (ORCPT ); Sun, 12 May 2019 13:05:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sirena.org.uk; s=20170815-heliosphere; h=In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ndywyr82/NFXN1lC+orQHknEu4sY+tlBor1wOLnwHSE=; b=Opwi9hM51BLy0cPkDfwO3cqSQ 9nRzofIkcNCQfT+hrTfUv8FrTcrP+2t9/YRayPL9C5CxWkqF87Eq4uLN6LmvutKsUXNq/MiTQgzp9 DR7LWfSifYzHzl7+qeL1P5R0BQJpvra4fXMJ5RWFfYbVK/mkELLD+MONxJ6qfYY786dVQ=; Received: from [81.145.206.43] (helo=finisterre.sirena.org.uk) by heliosphere.sirena.org.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hPruu-00044k-9y; Sun, 12 May 2019 17:05:40 +0000 Received: by finisterre.sirena.org.uk (Postfix, from userid 1000) id BB886440059; Sun, 12 May 2019 09:54:09 +0100 (BST) Date: Sun, 12 May 2019 17:54:09 +0900 From: Mark Brown To: Martin Sperl Cc: Jon Hunter , linux-tegra , Linux Kernel Mailing List , linux-spi@vger.kernel.org Subject: Re: Regression: spi: core: avoid waking pump thread from spi_sync instead run teardown delayed Message-ID: <20190512085409.GM21483@sirena.org.uk> References: <20190115192619.GG5522@sirena.org.uk> <5D3256B1-5DAE-4E3F-9099-5425F4BCA304@martin.sperl.org> <20190115212539.GK5522@sirena.org.uk> <20190118191202.GG6260@sirena.org.uk> <20190123175609.GG7503@sirena.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jB+02Y6wHc2pEa2x" Content-Disposition: inline In-Reply-To: X-Cookie: HOST SYSTEM RESPONDING, PROBABLY UP... User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --jB+02Y6wHc2pEa2x Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, May 09, 2019 at 09:47:08PM +0200, Martin Sperl wrote: > While thinking about this again maybe an idea: > What about implement a second spi_transfer_one implementation (together > with a message pump implementation) that would handle things correctly. > Any driver then can select the old (default) or new implementation and th= us > would allow the optimizations to take place only for verified working dri= vers... I'd rather avoid having yet another interface for drivers to use, people already get confused trying to choose between the ones we already have. It'd have to be something where the existing drivers got actively converted and the old interface retired rather than something that hangs around. > What I would then also like to do for the new implementation is modify the > API a bit - ideally I would like to: > * Make spi_sync the primary interface which the message pump is also=20 > using directly > * move all the prepare stuff early into spi-sync, so that for example the > Preparing (including dma mapping) would get done in the calling thread > And only the prepared message would get submitted to the queue > - special processing would be needed for the spi-async case. IIRC the mapping is deliberately done late in order to minimize the amount of time we're consuming resources for the mapping, there were some systems that had limited DMA channels. However I don't know how big a concern that is in this day and age with even relatively old systems. The idea of spi_async() having a separate path also makes me a bit nervous as it's much less widely used so more likely to get broken accidentially. Otherwise pushing things out to the caller makes sense, it should have no real impact in the majority of cases where the thread is just getting used to idle the controller and the actual work is all happening in the calling context anyway and if the pump is being used it means it's spending more time actually pushing transfers out. For the case where we do have the message pump going one thing it'd be good to do is overlap more of the admin work around the messages with other transfers - ideally we'd be able to kick off the next transfer =66rom within the completion of a DMA. I need to have a dig around and figure out if I have any hardware that can actually support that, last time I looked at this my main system needed to kick everything up to the thread due to hardware requirements. --jB+02Y6wHc2pEa2x Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAlzX3zAACgkQJNaLcl1U h9BPIQf+IXs6QkyGGEDlkcfJDDpZrmikAxecDDwRGwsR0dIdbhHaiZp+bNayRaaX ygo+j+63kO8AJ6fOHI3tPyLlCPcktVWeIMIbI2BGiOa5+Y58ZuJd1zCODDVOElK1 YHmzWKZZaeYGsZ+3McBRBRjURVPVxKXkLYaVBOLskI4gS2t7qedUXQrwqX+75YIe jRI53hs7tuL1Hlq31Fpy9wqibKjb6L41WkbL1c4eTpYEM5zR5umw//HJXheDW84r 94g7Q2+fvwaLt3fi7TXjJOMS6tRjQEupWfbxcd6bmySW65b5CNx/i3WaFs+26xbh yqrApK5wdTIXj637t8vHGfE9WpxMnQ== =22+6 -----END PGP SIGNATURE----- --jB+02Y6wHc2pEa2x--