Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp3590499rwb; Mon, 16 Jan 2023 09:59:45 -0800 (PST) X-Google-Smtp-Source: AMrXdXtGcYZBnD9XBLXzBKwBZyaa35XnBuS2pI070f5XRnfQHD/nbL1JQYZHDjRiB5SNhZcLwMI+ X-Received: by 2002:a17:902:720a:b0:193:25b6:71bc with SMTP id ba10-20020a170902720a00b0019325b671bcmr632817plb.25.1673891985256; Mon, 16 Jan 2023 09:59:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673891985; cv=none; d=google.com; s=arc-20160816; b=nwYmgujCKmVvs4k+8h0EiG1RTGgX2m2ZWkAv7Qwf6UAJl44zkScUbflbuAH23VXWRz dAK6DrGlikLZrlvnwLu3oaHRdw5YtbS9kv4FeLmqwNdS1GbCu7P/VJj8iqz8GjykDKJd MqQqgsL46KSA0wYzAgNfv7y0KAnNHxFyvv3WS92EbdR9Bl4qjtHfof7JqkPZ0L2ZjDk9 96GQrr5lbW+yhVqZrb9VUHBlAjyr2l20Da7hi3hc6D6aA1k/WFJ42DJ3AojCTGoOrxAR wlaVw5q+UYVYlx2I0E7AvCp0jZzreAShQkTErsfbq5BRumhvIEbQMutyBT2T1x/roGqt SIrA== 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=vXs+rSdP4+vynZ+zQxHeP5RRw5UHsLaGOOR/elts5AU=; b=l7JLdc0CdTYopNMR48n6MOAVC9tyEm2wW/JzgSTvCSBUwwJJJ4jyT+pq1othSQiXAk lVh4++Vvk8tYYuDdVVNqXKk1Xhwcu3xWvGPlpU7iDp+ZcA1HEO/PhHTnJGunVcuOKh3Q W2jZrzETgpQjoLzX/RdTH2ih0cnhIw980Wev4OhKl1O/Z3zUv/vX22F03e5OAn1V+FgP LLOJyp57cnsdP0XZ+FICV4RNXiJsuAz7XC9bh42/ZGuI5X8zHJSmlrMZ0+qmo3GOwuCj PxhJw+qgKUnKJh1q+sV6HEXL2nRCoDthZwdr8+JCqv4bNwRazUhkqCThbLJXAYr67oKY ewEA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id p15-20020a170902e74f00b00190fb8f9e0bsi427753plf.490.2023.01.16.09.59.39; Mon, 16 Jan 2023 09:59:45 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234523AbjAPRQL (ORCPT + 50 others); Mon, 16 Jan 2023 12:16:11 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38674 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234497AbjAPRP2 (ORCPT ); Mon, 16 Jan 2023 12:15:28 -0500 Received: from muru.com (muru.com [72.249.23.125]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id B18A52BEE4; Mon, 16 Jan 2023 08:56:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id C0C1A8108; Mon, 16 Jan 2023 16:56:25 +0000 (UTC) Date: Mon, 16 Jan 2023 18:56:24 +0200 From: Tony Lindgren To: Andreas Kemnade Cc: Adam Ford , bcousson@baylibre.com, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, linux-omap@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, "H. Nikolaus Schaller" Subject: Re: [PATCH] ARM: dts: gta04: fix excess dma channel usage Message-ID: References: <20230113211151.2314874-1-andreas@kemnade.info> <20230116173922.585904bf@aktux> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230116173922.585904bf@aktux> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Andreas Kemnade [230116 16:39]: > On Mon, 16 Jan 2023 16:51:57 +0200 > Tony Lindgren wrote: > > > Hi, > > > > * Adam Ford [230116 14:16]: > > > Would it make sense to make this default in the omap3.dtsi file and > > > enable them in the individual boards that need it? > > > > In general disabling the unused devices by default for omaps will break > > the power management. The disabled devices are completely ignored by the > > kernel, and the devices are left to whatever the bootloader state might > > be. > > > hmm, shouldn't ti-sysc keep things disabled in most cases? It is still a bit > known because there is no status = "disabled" in the target-module@xxx node. Oh right, if the child device is tagged disabled (instead of the the parent ti-sysc tagged disabled) the module should get idled just fine as long as the module related quirks are implemented for ti-sysc.c. But still, I'd rather not start tagging devices disabled by default and then re-enabling everywhere since we never needed it before. It just adds a lot of pointless status tinkering, see commit 12afc0cf8121 ("ARM: dts: Drop pointless status changing for am3 musb"). So considering things, IMO it's best to set only the child device with status disabled, and set it at the board specific dts file in this case. Also note that the dma channels could be freed with /delete-property/ at the board specific dts file even for devices that are usable if not really needed. Regards, Tony