Received: by 2002:a05:6a10:d5a5:0:0:0:0 with SMTP id gn37csp87739pxb; Thu, 30 Sep 2021 01:35:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxjTsGRvfCS9fF5eEqQ932mEWsq726Hnr4YftzFf19r+mQmACOpYcBVarNDKaKcJK6EYbF+ X-Received: by 2002:a17:906:289a:: with SMTP id o26mr5360937ejd.243.1632990919303; Thu, 30 Sep 2021 01:35:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632990919; cv=none; d=google.com; s=arc-20160816; b=wH3UgqDF51xnmVGlXkbigy6NAD2wEEC8RqnYwrRPp4nOtGuFeFu02CwFt7wko7Ghod yhwlAs1D/Nyy4o8x+khTe/FWdrvX3Zdh+P+NA0Xs2UFMawIO8Uw5tda/OPET+3+breL0 1Z1qlN1iWq2ICkpkhll8/rsyjGHGDtkNTw+pT6npeLhgp4h2zIOHR/VVdl3OuDJmuLAB lKoHVqDJQWM8YODvxwKQMVuQAqs4Ymg8H+hSy9EXZGpBFe2KVPe7pNjsQpX0P9rCmZ2+ Lsc9ZvLQLKtIjrgVukM9mBec556ls5mLrnvjdOCR4Z2KKnrm3XwvlWlOK5B8Egnr4WAV I7Tw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=eVKKgg0sT53Aa2tyHwnvow4D7vuz3bqxW+cGbL/laWk=; b=nQmKLOy6kdquBjPB+LjfS2M84JZglS0k11QS5ba9jvnSwv/l1Nq+svhFGAYrH2xCFf 584/CGg3y5JcPeB93ZOyDzgrwXJ93LVnfd8pGMtFCRn1dZoH3Ukf1xuzJpgskbimkXcL OskAH9pvJmB7qK+0KSH5s3rBwI3hlskr/cLG0UIw16EhaXTFyWa55MXkhaExTTkJgVtd b+Hg9umyyeFKRvJvkWCVYNFpgAlwQL9fbYRC0pfB1ShMe84VXjSGHKoNLrMJZ/VyAivQ vobU1Goz835tzQaG82nTQBj1BNhxYd0UH3TRWmavinPOtJLlWAamihR8ruBdlKDMGysk H4Ww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id hp20si3766768ejc.560.2021.09.30.01.34.55; Thu, 30 Sep 2021 01:35:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1348722AbhI3H1x (ORCPT + 99 others); Thu, 30 Sep 2021 03:27:53 -0400 Received: from muru.com ([72.249.23.125]:38994 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1348693AbhI3H1w (ORCPT ); Thu, 30 Sep 2021 03:27:52 -0400 Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id 9BD358050; Thu, 30 Sep 2021 07:26:38 +0000 (UTC) Date: Thu, 30 Sep 2021 10:26:07 +0300 From: Tony Lindgren To: Andy Shevchenko Cc: Greg Kroah-Hartman , Andy Shevchenko , Jiri Slaby , Johan Hovold , Vignesh Raghavendra , linux-serial@vger.kernel.org, linux-omap@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/4] serial: core: Add wakeup() and start_pending_tx() for power management Message-ID: References: <20210930062906.58937-1-tony@atomide.com> <20210930062906.58937-2-tony@atomide.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andy Shevchenko [210930 07:11]: > On Thu, Sep 30, 2021 at 9:30 AM Tony Lindgren wrote: > > > > If the serial driver implements PM runtime with autosuspend, the port may > > be powered down on TX. To wake up the port, let's add new wakeup() call > > for serial drivers to implement as needed. We can call wakeup() from > > __uart_start() and flow control related functions before attempting to > > write to the serial port registers. > > > > Let's keep track of the serial port with a new runtime_suspended flag > > that the device driver runtime PM suspend and resume can manage with > > atomic_set(). This is because only the device driver knows what the > > device runtime PM state as in Documentation/power/runtime_pm.rst > > under "9. Autosuspend, or automatically-delayed suspend" for locking. > > > > To allow the serial port drivers to send out pending tx on runtime PM > > resume, let's add start_pending_tx() as suggested by Johan Hovold > > . > > ... > > > + wakeup(port) > > + Wake up port if it has been runtime PM suspended. > > + > > + Locking: port->lock taken. > > + > > + Interrupts: locally disabled. > > > + This call must not sleep > > If it's suspended via ACPI methods, it can't be resumed here, right? It should work for that too assuming the runtime PM resume function is implemented. > Only what we can do is to schedule a resume, but it means we may not > access registers immediately after and we have to be sure that the > device is resumed. Yeah the only thing we do in the 8250_port wakeup() is schedule a resume if needed. Then the 8250 port device driver can call start_pending_tx() at the end of it's runtime PM resume function. > Dead end? I don't think so :) In serial_core we bail out on uart_port_wakeup() errors before register access. But maybe I missed some more moles to whack there :) Regards, Tony