From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05BB2C433EF for ; Sun, 3 Oct 2021 21:21:47 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CBA3F611F2 for ; Sun, 3 Oct 2021 21:21:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231484AbhJCVXd (ORCPT ); Sun, 3 Oct 2021 17:23:33 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45068 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231440AbhJCVXc (ORCPT ); Sun, 3 Oct 2021 17:23:32 -0400 Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B1285C0613EC for ; Sun, 3 Oct 2021 14:21:44 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id p1so6747649pfh.8 for ; Sun, 03 Oct 2021 14:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=plZi8lBtdV0KgYUjR+I3eRchFTjTIheuKyQUsE0OFbw=; b=l7+Xg2mftK1gsYMAz+0hXZVKIoiHW/UAv947A868utUNg1BAzcEqqdbBm0SfRFCStO ps4+7XEqCfHP03Zl3NpTNDYyVNQAxhSiA43YjybJxRp80Uq6MKY9q5TtM+1Is2nts8JE Oy2J57R+RYpCHeKXZDASvzqfIf0BcMeAJox3QwtGAnNORW+VDutlIdmQSRo4GYWG5Wru mt0IlBApPDr42nNoOA8/sE0+Z+8UwwfDqzdhZPiLYUDxk+BRWj32VV4EgCra1OsDs7tv RcyTl4KW8AHqQKb7Rf8qMDCGJSaWARfNY15wZserOIt5U2sNoA5ZAddlnyiZobaGsaF/ mB6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=plZi8lBtdV0KgYUjR+I3eRchFTjTIheuKyQUsE0OFbw=; b=m81MxGCn0Zaqz3FleBAR0PS9HToGL1NGgtHXojfeRLpl2BjqA5COOJmInRxu+7WHhv DwMRYMfVz26YxJu5KVQoDzwTPUNj1etTwLh8dZr11VZPkcNJgGrs79ufnjxX+VvFXXR7 iBl1V1Yj2niDIeCvVblBPwgV1ETG1+HWzCw10r927wFepm3HSQswjfuAfMptqFFaujlP ZnVwSfpKuB0sAA8bHBqp1GDPJj9o0Uu0fVs7EioJ381KPgDv8xc7U7screzlyOPhfBRF iCVjybgDeSHSKXnZBQqiU2IfDCShm8m1jEKaEEUdIepiuUGK/p4TRMEPI2WJjbYobISH YBKA== X-Gm-Message-State: AOAM53326xlTAbVBNmEf7JX2Z7w/TaQb+GRSrOBFQroX2YjxaFFDbBxg HpErk7uh6fTWl/4X6FOx3D1CRH9W7z2ZdY5x/jDOAA== X-Google-Smtp-Source: ABdhPJwNnqTXi7W6TvlURrnvArtvJXKWp7Gj2NOFptSa5HsyS9LJlDDVymd9YS7otpu21OpXFt6kqXG3rwomRLm8XC0= X-Received: by 2002:a63:6f42:: with SMTP id k63mr8000554pgc.358.1633296103854; Sun, 03 Oct 2021 14:21:43 -0700 (PDT) MIME-Version: 1.0 References: <20210910202640.980366-1-l.stach@pengutronix.de> <20210910202640.980366-15-l.stach@pengutronix.de> <21bef8f0351a8a6c65e38f7ba80b98b34aec7b73.camel@pengutronix.de> In-Reply-To: From: Tim Harvey Date: Sun, 3 Oct 2021 14:21:31 -0700 Message-ID: Subject: Re: [PATCH v4 14/18] arm64: dts: imx8mm: add GPC node To: Lucas Stach Cc: Shawn Guo , Rob Herring , Fabio Estevam , NXP Linux Team , Adam Ford , Frieder Schrempf , Marek Vasut , Device Tree Mailing List , Linux ARM Mailing List , Sascha Hauer , patchwork-lst@pengutronix.de Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On Sun, Oct 3, 2021 at 12:44 PM Lucas Stach wrote: > > Am Sonntag, dem 03.10.2021 um 10:17 -0700 schrieb Tim Harvey: > > On Sat, Oct 2, 2021 at 5:51 AM Lucas Stach wrote: > > > > > > Hi Tim, > > > > > > Am Freitag, dem 01.10.2021 um 19:43 -0700 schrieb Tim Harvey: > > > > > > > > > > > [...] > > > > > > > > > Lucas, > > > > > > > > > > > > > > > > > > I've been using your 'i.MX8MM GPC improvements and BLK_CTRL driver' > > > > > > > > > series for imx8mm-venice* and imx8mn-venice* boards. Thank you for > > > > > > > > > this work and I hope to see it merged soon! > > > > > > > > > > > > > > > > > > I have found that on the imx8mm-venice-gw7901 board which does not use > > > > > > > > > MIPI and thus does not connect VDD_MIPI_1P8, VDD_MIPI_1P2, > > > > > > > > > VDD_MIPI_0P9, MIPI_VREG_CAP pins on the IMX8MM hangs with this > > > > > > > > > particular patch. If I comment out the pgc_mipi domain and subsequent > > > > > > > > > disp_blk_ctrl node from a later patch it resolves the hang. Is this > > > > > > > > > behavior expected and what would your recommendation be to work around > > > > > > > > > it? > > > > > > > > > > > > > > > > No, this isn't expected. If there are no active devices in the MIPI > > > > > > > > domain, the power domain should not be touched, as we treat all of them > > > > > > > > as disabled initially. If we don't touch the domain I would expect that > > > > > > > > the power supply not being present shouldn't be an issue. > > > > > > > > > > > > > > > > Can you check if something in your system causes this power domain to > > > > > > > > be powered up? Easiest way is probably to sprinkle a > > > > > > > > printk("%s\n, genpd->name) in both imx8m_blk_ctrl_power_on() and > > > > > > > > imx_gpc_power_on(). > > > > > > > > > > > > > > > > > > > > > > Lucas, > > > > > > > > > > > > > > Here's what I see before I hang (debug print on both power on/off > > > > > > > followed by a msleep(1000) to make sure I see it before I hang): > > > > > > > [ 0.518319] imx_pgc_power_up hsiomix > > > > > > > [ 0.624031] imx_pgc_power_down hsiomix > > > > > > > [ 0.731879] imx_pgc_power_up hsiomix > > > > > > > [ 0.839906] imx_pgc_power_down hsiomix > > > > > > > [ 0.947875] imx_pgc_power_up hsiomix > > > > > > > [ 1.055859] imx_pgc_power_down hsiomix > > > > > > > [ 1.057296] imx_pgc_power_up gpumix > > > > > > > [ 1.167884] imx_pgc_power_down gpumix > > > > > > > [ 0.518513] imx_pgc_power_up hsiomix > > > > > > > [ 0.519933] imx_pgc_power_up gpumix > > > > > > > > > > > > > > > > > > > The board also has IMX8MM VDD_GPU pins not connected so it makes sense > > > > > > that we hang here I suppose. Yet if I add the folloiwng to > > > > > > imx8mm-venice-gw7901.dts it still tries to enable them and hangs: > > > > > > &gpu_2d { > > > > > > status = "disabled"; > > > > > > }; > > > > > > > > > > > > &gpu_3d { > > > > > > status = "disabled"; > > > > > > }; > > > > > > > > > > > > &vpu_blk_ctrl { > > > > > > status = "disabled"; > > > > > > }; > > > > > > > > > > The pgc_gpu is a "active" consumer of the pgc_gpumix domain while the > > > > > driver gets probed, so the driver core will power up the gpumix domain > > > > > for a moment during kernel init. To avoid this you must at least set > > > > > the status of the pgc_gpu node to disabled. > > > > > > > > > > > > > I've tried that and it doesn't work either. > > > > > > > > &gpu_2d { > > > > status = "disabled"; > > > > }; > > > > > > > > &gpu_3d { > > > > status = "disabled"; > > > > }; > > > > > > > > &vpu_blk_ctrl { > > > > status = "disabled"; > > > > }; > > > > > > > > &pgc_gpumix { > > > > status = "disabled"; > > > > }; > > > > > > > > &pgc_gpu { > > > > status = "disabled"; > > > > }; > > > > > > > > The interesting thing is that the first patch that causes this is > > > > 'arm64: dts: imx8mm: add GPC node' which just adds the gpc node and is > > > > before the addition of the other nodes. Therefore these are being > > > > enabled by default regardless of the above nodes being disabled (or > > > > not even added yet to imx8mm.dtsi). > > > > > > My bad, I didn't think about the fact that the power domain devices are > > > not instantiated via the common OF populate code. For the status > > > property to work as expected the GPCv2 code needs to check this > > > property. I've just sent a patch to make this happen. Can you give it > > > another try with your DT changes and this patch applied? > > > > > > > Yes, this makes sense and resolves it with only disabling pgc_gpumix in my dts. > > > > I believe it is fine for me to not specifically disable gpu_2d and > > gpu_3d as they are not enabled by default in imx8mm.dtsi and I don't > > believe that will change and I don't 'currently' need to disable > > disp_blk_ctrl or pgc_mipi but wondering if I should as the MIPI rails > > are not hooked up either? (ie will something added in the future try > > to use them?) > > > I think it would be better to disable the GPU devices in your DT. They > don't have a status property and thus are enabled by default. They > won't probe without the power domain being available, but it will cause > those devices to stay in probe deferred state forever, which may > confuse some users. So I guess it would be good style to disable the > GPU nodes. > it still tries to power the pgc_gpumix domain if I 'only' disable gpu_2d and gpu_3d. I have to disable 'pgc_gpumix' specifically - is that what you expect here? > One consequence of disabling the MIPI power domain is that the disp- > blk-ctrl driver won't probe anymore, as it needs all the referenced > power domains to be available. Do you think this might be an issue? Is > there a valid system configuration where you would use devices from > from the display power domain, but not the MIPI domain? If that's a > valid case we might need to make this configuration possible in the > disp-blk-ctrl driver. In the case of imx8mm I don't see that you can have any display without MIPI however the imx8mp can have HDMI display without needing MIPI so in general that should be allowed. > > > What needs to be done to get this series merged? I suppose it's too > > late to get it into 5.13? > > 5.13? Way too late, even the 5.15 merge window is long closed. The > series is almost completely reviewed and the DT bindings are also good > to go. So if no one happens to run into any real showstopper, Shawn may > be willing to pick up the series and stage it for the 5.16 merge > window. oops... I meant 5.15 but yes, seems too late for that. We seem to have time to get this into 5.16 however. I'm not sure what Shawn's cut-off is there. Tim From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 97AFCC433F5 for ; Sun, 3 Oct 2021 21:24:11 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4F96561372 for ; Sun, 3 Oct 2021 21:24:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 4F96561372 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=gateworks.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=ydI8WCL93JMmOK098A/QBJHjGRzJMuDNZztd4tIj3CY=; b=A8bRxaXsriBOUc jcjStH/W2HAYbU9pPCMntkwiaGciqYX5iF6o91wXlZb4XDETP/znPWj7VfIxn9tbyq6xJBuMfhuHy GtuIjqV1J90vo5XVj9m0uKDwI6xxWD0tKmmoTV3b1GFHtSgvE7dM/pg9K5OafEeLgz8JItnA21r39 lF3/bTaL8R1GJVBqJ7eGGO0zpxi5H6HFPcfH1Xr5Ig9yKabdsIJL/YL6suZl3bHBp6XAVm8nZ5f/X G0zRzdWrpHkxtOGUC3GqOonPkdGj3OYtpBYjMradJgudDW2tSzMn9TzGJApyX0mzDMLbkRGItDyj8 oK2SVQ25YBg8rjrOEU6Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1mX8vd-004XGL-5e; Sun, 03 Oct 2021 21:21:49 +0000 Received: from mail-pf1-x42a.google.com ([2607:f8b0:4864:20::42a]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1mX8vY-004XFY-TF for linux-arm-kernel@lists.infradead.org; Sun, 03 Oct 2021 21:21:46 +0000 Received: by mail-pf1-x42a.google.com with SMTP id m26so12823987pff.3 for ; Sun, 03 Oct 2021 14:21:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gateworks-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=plZi8lBtdV0KgYUjR+I3eRchFTjTIheuKyQUsE0OFbw=; b=l7+Xg2mftK1gsYMAz+0hXZVKIoiHW/UAv947A868utUNg1BAzcEqqdbBm0SfRFCStO ps4+7XEqCfHP03Zl3NpTNDYyVNQAxhSiA43YjybJxRp80Uq6MKY9q5TtM+1Is2nts8JE Oy2J57R+RYpCHeKXZDASvzqfIf0BcMeAJox3QwtGAnNORW+VDutlIdmQSRo4GYWG5Wru mt0IlBApPDr42nNoOA8/sE0+Z+8UwwfDqzdhZPiLYUDxk+BRWj32VV4EgCra1OsDs7tv RcyTl4KW8AHqQKb7Rf8qMDCGJSaWARfNY15wZserOIt5U2sNoA5ZAddlnyiZobaGsaF/ mB6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=plZi8lBtdV0KgYUjR+I3eRchFTjTIheuKyQUsE0OFbw=; b=ipuA3ywuPreyuW4J9Q7KxsH1NBu6Mq9430XaXeBLqDW4lIwucL6N4Q2SsQ6Dra9U5/ ZbGuDXIDlDEwYp+el1A7QM+a0+jsAFVtL2PUpyOT602Th5t9y8H78VY2XqWpz7Y4ZeL6 Y1OpZDkb95kcQvzUPwh8uBl0gcRLsu7+zVLPepdqd2KV31JruBUhHoLC7v1LSqHE9J5l p1BcaHaxfBKpo1hxn2FNGbO79IVieuSY2zbI6BZ4/ew8C6ANnhSG31g3cLTxlmLXAK13 C4dsMWwnzoTO+wWRsMnxjZbXXsAh9CoDVOx69FWrqvELe5JDIjCx64bl1FjWc/ePMFuK c/Sg== X-Gm-Message-State: AOAM531Ux+ST7m1jfhXQXqUaefFtPWhNKpcHBRtDBk2DUKhB0fDXgWAS g70V/tWfg/HM4eNx9ZyxKhXrdWFiAXILdaAnRJjqtA== X-Google-Smtp-Source: ABdhPJwNnqTXi7W6TvlURrnvArtvJXKWp7Gj2NOFptSa5HsyS9LJlDDVymd9YS7otpu21OpXFt6kqXG3rwomRLm8XC0= X-Received: by 2002:a63:6f42:: with SMTP id k63mr8000554pgc.358.1633296103854; Sun, 03 Oct 2021 14:21:43 -0700 (PDT) MIME-Version: 1.0 References: <20210910202640.980366-1-l.stach@pengutronix.de> <20210910202640.980366-15-l.stach@pengutronix.de> <21bef8f0351a8a6c65e38f7ba80b98b34aec7b73.camel@pengutronix.de> In-Reply-To: From: Tim Harvey Date: Sun, 3 Oct 2021 14:21:31 -0700 Message-ID: Subject: Re: [PATCH v4 14/18] arm64: dts: imx8mm: add GPC node To: Lucas Stach Cc: Shawn Guo , Rob Herring , Fabio Estevam , NXP Linux Team , Adam Ford , Frieder Schrempf , Marek Vasut , Device Tree Mailing List , Linux ARM Mailing List , Sascha Hauer , patchwork-lst@pengutronix.de X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20211003_142145_025458_8D630517 X-CRM114-Status: GOOD ( 59.83 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Sun, Oct 3, 2021 at 12:44 PM Lucas Stach wrote: > > Am Sonntag, dem 03.10.2021 um 10:17 -0700 schrieb Tim Harvey: > > On Sat, Oct 2, 2021 at 5:51 AM Lucas Stach wrote: > > > > > > Hi Tim, > > > > > > Am Freitag, dem 01.10.2021 um 19:43 -0700 schrieb Tim Harvey: > > > > > > > > > > > [...] > > > > > > > > > Lucas, > > > > > > > > > > > > > > > > > > I've been using your 'i.MX8MM GPC improvements and BLK_CTRL driver' > > > > > > > > > series for imx8mm-venice* and imx8mn-venice* boards. Thank you for > > > > > > > > > this work and I hope to see it merged soon! > > > > > > > > > > > > > > > > > > I have found that on the imx8mm-venice-gw7901 board which does not use > > > > > > > > > MIPI and thus does not connect VDD_MIPI_1P8, VDD_MIPI_1P2, > > > > > > > > > VDD_MIPI_0P9, MIPI_VREG_CAP pins on the IMX8MM hangs with this > > > > > > > > > particular patch. If I comment out the pgc_mipi domain and subsequent > > > > > > > > > disp_blk_ctrl node from a later patch it resolves the hang. Is this > > > > > > > > > behavior expected and what would your recommendation be to work around > > > > > > > > > it? > > > > > > > > > > > > > > > > No, this isn't expected. If there are no active devices in the MIPI > > > > > > > > domain, the power domain should not be touched, as we treat all of them > > > > > > > > as disabled initially. If we don't touch the domain I would expect that > > > > > > > > the power supply not being present shouldn't be an issue. > > > > > > > > > > > > > > > > Can you check if something in your system causes this power domain to > > > > > > > > be powered up? Easiest way is probably to sprinkle a > > > > > > > > printk("%s\n, genpd->name) in both imx8m_blk_ctrl_power_on() and > > > > > > > > imx_gpc_power_on(). > > > > > > > > > > > > > > > > > > > > > > Lucas, > > > > > > > > > > > > > > Here's what I see before I hang (debug print on both power on/off > > > > > > > followed by a msleep(1000) to make sure I see it before I hang): > > > > > > > [ 0.518319] imx_pgc_power_up hsiomix > > > > > > > [ 0.624031] imx_pgc_power_down hsiomix > > > > > > > [ 0.731879] imx_pgc_power_up hsiomix > > > > > > > [ 0.839906] imx_pgc_power_down hsiomix > > > > > > > [ 0.947875] imx_pgc_power_up hsiomix > > > > > > > [ 1.055859] imx_pgc_power_down hsiomix > > > > > > > [ 1.057296] imx_pgc_power_up gpumix > > > > > > > [ 1.167884] imx_pgc_power_down gpumix > > > > > > > [ 0.518513] imx_pgc_power_up hsiomix > > > > > > > [ 0.519933] imx_pgc_power_up gpumix > > > > > > > > > > > > > > > > > > > The board also has IMX8MM VDD_GPU pins not connected so it makes sense > > > > > > that we hang here I suppose. Yet if I add the folloiwng to > > > > > > imx8mm-venice-gw7901.dts it still tries to enable them and hangs: > > > > > > &gpu_2d { > > > > > > status = "disabled"; > > > > > > }; > > > > > > > > > > > > &gpu_3d { > > > > > > status = "disabled"; > > > > > > }; > > > > > > > > > > > > &vpu_blk_ctrl { > > > > > > status = "disabled"; > > > > > > }; > > > > > > > > > > The pgc_gpu is a "active" consumer of the pgc_gpumix domain while the > > > > > driver gets probed, so the driver core will power up the gpumix domain > > > > > for a moment during kernel init. To avoid this you must at least set > > > > > the status of the pgc_gpu node to disabled. > > > > > > > > > > > > > I've tried that and it doesn't work either. > > > > > > > > &gpu_2d { > > > > status = "disabled"; > > > > }; > > > > > > > > &gpu_3d { > > > > status = "disabled"; > > > > }; > > > > > > > > &vpu_blk_ctrl { > > > > status = "disabled"; > > > > }; > > > > > > > > &pgc_gpumix { > > > > status = "disabled"; > > > > }; > > > > > > > > &pgc_gpu { > > > > status = "disabled"; > > > > }; > > > > > > > > The interesting thing is that the first patch that causes this is > > > > 'arm64: dts: imx8mm: add GPC node' which just adds the gpc node and is > > > > before the addition of the other nodes. Therefore these are being > > > > enabled by default regardless of the above nodes being disabled (or > > > > not even added yet to imx8mm.dtsi). > > > > > > My bad, I didn't think about the fact that the power domain devices are > > > not instantiated via the common OF populate code. For the status > > > property to work as expected the GPCv2 code needs to check this > > > property. I've just sent a patch to make this happen. Can you give it > > > another try with your DT changes and this patch applied? > > > > > > > Yes, this makes sense and resolves it with only disabling pgc_gpumix in my dts. > > > > I believe it is fine for me to not specifically disable gpu_2d and > > gpu_3d as they are not enabled by default in imx8mm.dtsi and I don't > > believe that will change and I don't 'currently' need to disable > > disp_blk_ctrl or pgc_mipi but wondering if I should as the MIPI rails > > are not hooked up either? (ie will something added in the future try > > to use them?) > > > I think it would be better to disable the GPU devices in your DT. They > don't have a status property and thus are enabled by default. They > won't probe without the power domain being available, but it will cause > those devices to stay in probe deferred state forever, which may > confuse some users. So I guess it would be good style to disable the > GPU nodes. > it still tries to power the pgc_gpumix domain if I 'only' disable gpu_2d and gpu_3d. I have to disable 'pgc_gpumix' specifically - is that what you expect here? > One consequence of disabling the MIPI power domain is that the disp- > blk-ctrl driver won't probe anymore, as it needs all the referenced > power domains to be available. Do you think this might be an issue? Is > there a valid system configuration where you would use devices from > from the display power domain, but not the MIPI domain? If that's a > valid case we might need to make this configuration possible in the > disp-blk-ctrl driver. In the case of imx8mm I don't see that you can have any display without MIPI however the imx8mp can have HDMI display without needing MIPI so in general that should be allowed. > > > What needs to be done to get this series merged? I suppose it's too > > late to get it into 5.13? > > 5.13? Way too late, even the 5.15 merge window is long closed. The > series is almost completely reviewed and the DT bindings are also good > to go. So if no one happens to run into any real showstopper, Shawn may > be willing to pick up the series and stage it for the 5.16 merge > window. oops... I meant 5.15 but yes, seems too late for that. We seem to have time to get this into 5.16 however. I'm not sure what Shawn's cut-off is there. Tim _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel