Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp926797imm; Wed, 18 Jul 2018 13:11:51 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfy/ncgiIb30uK0W54cJWM6vWMs+DNK7brNIkBsov4XXymdX0kJIuhb4gDRr/l0bk43Ipxd X-Received: by 2002:a63:a619:: with SMTP id t25-v6mr6953251pge.288.1531944711846; Wed, 18 Jul 2018 13:11:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531944711; cv=none; d=google.com; s=arc-20160816; b=UEELyXHtR6pC2biZQ2ALg+PYstWgelJYSQyedP+BVBH0Jk+Vv4jtdbgBYebF8e4ogF 7fzRAlWn1SUjZ56vcmjxJ72kiF6yRf53cPU6Yss3pZbwQy9WpGko8lXb4tT+W810Z6Nz gVEVtpygX7x9cSn242+kW5ugJrCvABQeWehgJ3DphcCEQkBYnEgPhahNFZ5Z624H4xhC dyvY7oMDM8WKo2oZymYnl87aItl+7+z/8syOqSK1u/UKw3k9aav59FUXdeaKGk3yu/m6 t8u5BkM5OPs94trakkL1Csb3F9sLcBaommctWA1PoQyl7+nk/UVLLBd6XRE1o3m38j0b NA0g== 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:mime-version :organization:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=RKeFE7DAnwOtCWtMyGPCTe7O2exVwnfR2BzDPjpGnxs=; b=FdFZF5yUy2G6+BfPAlCAelf9Dxa92epgjX4KeSo6ffDW1/8XCc97dijTSiQ0H5OutA 3VMEiCVclp2f5iYiwByvsKLBXMUPy1FjuuGtsZKVxNnWkSNWQEBDDUTuCOyNp4FtH3dG cGZjE2u7HxPLrtfaussV9mCWFFOVpYyGPNfCoGnIBl6OlnHzbqtsqBvu3ZQXP14Bq3gJ 4war4KLo7gpHIz84ipA3wbCXR3HJwbnxBWTGCIuF1vLDTcVC/yrkTEqmw1qOZ4MuOkrA jh1oKiff76Q/ImUitwD5k8jlFNZyXsT9dFXWtTbLEMEFEqsV45TW+qEQ0V+OxZ85apP0 V7aA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b18-v6si4089411pgd.185.2018.07.18.13.11.37; Wed, 18 Jul 2018 13:11:51 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730248AbeGRUub (ORCPT + 99 others); Wed, 18 Jul 2018 16:50:31 -0400 Received: from mail-qt0-f195.google.com ([209.85.216.195]:46293 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729262AbeGRUub (ORCPT ); Wed, 18 Jul 2018 16:50:31 -0400 Received: by mail-qt0-f195.google.com with SMTP id d4-v6so5219352qtn.13 for ; Wed, 18 Jul 2018 13:11:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:organization:mime-version:content-transfer-encoding; bh=RKeFE7DAnwOtCWtMyGPCTe7O2exVwnfR2BzDPjpGnxs=; b=qoTNY+NF/Qh18oZxMKaBryMJYUQNSOBVkdPcEouuaE/jkT/g+6U3jg+UiQfuggkPSl 4h0iRsUsEqt3EU/uJmGAUPJtws/IRBPplBPqyojos5NDrREr4pKWxFj0w4bmljeOjbHY F/qtyLGoOlvCLXrbDN9UzkKkzkCsr+Snhr99XupanrnQQcznWKNP9jjaxl83OZz7W0wk bU63fU8AlWrIr1+bSFJ8wDtMX4NkfimhFMajc9BrNNDZvii5+48rhEDn5Qnxn99QxwMI A9dy5OMoJVYpYKUpkd81KY1lbhjWBqegJr3iaNCPfrObzq8QdnPyF9LAs0005g0E2EXf mp1w== X-Gm-Message-State: AOUpUlGHB+5oKciPariU8EYlp1aJm7VGaukLDT8uCe9MUnsu09X5vV+3 CTicZ8j4piQ7rKZmUu99+68org== X-Received: by 2002:ac8:2f84:: with SMTP id l4-v6mr7175209qta.83.1531944661591; Wed, 18 Jul 2018 13:11:01 -0700 (PDT) Received: from dhcp-10-20-1-11.bss.redhat.com ([144.121.20.162]) by smtp.gmail.com with ESMTPSA id f11-v6sm2698777qkb.43.2018.07.18.13.11.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 Jul 2018 13:11:00 -0700 (PDT) Message-ID: <2724dd5eee8a1e4e523e43915fa184ad5afe1c59.camel@redhat.com> Subject: Re: [Nouveau] [PATCH 1/5] drm/nouveau: Prevent RPM callback recursion in suspend/resume paths From: Lyude Paul To: Lukas Wunner , "Rafael J. Wysocki" Cc: nouveau@lists.freedesktop.org, David Airlie , Linux Kernel Mailing List , dri-devel , Ben Skeggs , Linux PM Date: Wed, 18 Jul 2018 16:11:00 -0400 In-Reply-To: <20180718083601.GC16072@wunner.de> References: <20180716235936.11268-1-lyude@redhat.com> <20180716235936.11268-2-lyude@redhat.com> <20180717071641.GA5411@wunner.de> <20180717182041.GA18363@wunner.de> <20180718082505.GB16072@wunner.de> <20180718083601.GC16072@wunner.de> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.3 (3.28.3-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2018-07-18 at 10:36 +0200, Lukas Wunner wrote: > On Wed, Jul 18, 2018 at 10:25:05AM +0200, Lukas Wunner wrote: > > The GPU contains an i2c subdevice for each connector with DDC lines. > > I believe those are modelled as children of the GPU's PCI device as > > they're accessed via mmio of the PCI device. > > > > The problem here is that when the GPU's PCI device runtime suspends, > > its i2c child device needs to be runtime active to suspend the MST > > topology. Catch-22. > > > > I don't know whether or not it's necessary to suspend the MST topology. > > I'm not an expert on DisplayPort MultiStream transport. > > > > BTW Lyude, in patch 4 and 5 of this series, you're runtime resuming > > pad->i2c->subdev.device->dev. Is this the PCI device or is it the i2c > > device? I'm always confused by nouveau's structs. In nvkm_i2c_bus_ctor() > > I can see that the device you're runtime resuming is the parent of the > > i2c_adapter: > > > > struct nvkm_device *device = pad->i2c->subdev.device; > > [...] > > bus->i2c.dev.parent = device->dev; > > > > If the i2c_adapter is a child of the PCI device, it's sufficient > > to runtime resume the i2c_adapter, i.e. bus->i2c.dev, and this will > > implicitly runtime resume its parent. > > Actually, having written all this I just remembered that we have this > in the documentation: > > 8. "No-Callback" Devices > > Some "devices" are only logical sub-devices of their parent and cannot > be > power-managed on their own. [...] > > Subsystems can tell the PM core about these devices by calling > pm_runtime_no_callbacks(). > > So it might actually be sufficient to just call pm_runtime_no_callbacks() I would have hoped so, but unfortunately it seems that pm_runtime_no_callbacks() is already called by default for i2c adapters in i2c_register_adapter(). Unfortunately this really can't fix the problem though, because it will still try to runtime resume the parent device of the i2c adapter, which still leads to deadlocking in the runtime suspend/resume path. Additionally; I did play around with ignore_children, but unfortunately this isn't good enough either as it just means that our i2c devices won't wake the GPU up on access. I'm pretty stumped here on trying to figure out any clean way to handle this in the PM core if recursive resume calls are off the table. The only possible solution I could see to this is if we could disable execution of runtime callbacks in the context of a certain task (while all other tasks have to honor the runtime PM callbacks), do what we need to do in suspend, then re- enable them > for the i2c devices... > > Lukas -- Cheers, Lyude Paul