Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp3589368rwb; Mon, 16 Jan 2023 09:58:32 -0800 (PST) X-Google-Smtp-Source: AMrXdXs67V7zqaHO6ypTAUrbSbz1gH1a5TdVh2S1KZB3nFRxZVZROVUnaFaFXOjHjj2Olt+hLpjr X-Received: by 2002:a05:6402:e87:b0:491:6897:c5cb with SMTP id h7-20020a0564020e8700b004916897c5cbmr69173eda.41.1673891912251; Mon, 16 Jan 2023 09:58:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1673891912; cv=none; d=google.com; s=arc-20160816; b=nYOIcxXBkfgtYtMHBLYqFjHLjQnOfDg362vhwOaEn3zBTAZULqdGXXuDrNCfSdQ/bN 5IEAVA1NEuqCN7j/80qHoSRobpxyoyGjjcb5FUqFRoQVzSxYQMdlHy4Z4o3ViNyF/f/U Yt6I2jdZzK2j1M4vfVPlxdtcrgUNifhc8yRvNOTGHMJ7xbsqEkdj7ZZnyF6n9a5dOx7V 679Dae011nnoGkG+O7HU+6yUufeFaK2RIfmkz/RxFuTy/GgtPhHJuJCI0HOJm5tT7wp1 L0wbeEzagT7L5tKsrB6i2sJPUeD5CH4L1ruweLL0RjbxT21x63JbqxbRpTpCc31J3Rko 0Tsg== 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=mF9taCKxzg2DknY3C+8k65UCnJbJfADyR61/K5Wivrc=; b=j5LqCUxI7Orrgwte6knNdW6KqN+noqTjnDQIZmemfelEeCEcJHQks597IFbwzs0yGh l37GokY2ZuezxfsGtKbngNK7MxjvtAhtssI9Id335hqPnaBQiIJYNWnsYJR69QRY9BtF k9foNiHnE58uGVVN43O5dr1bKdbICSjZXpx4mtjFb7JmfM3l5MYHK3OSjgYqGkS8nkmu 0SpXTkoZOd5zxLH0tO1qW06/XyOKXjJS/P3E3MLQx3vOsHZBY3kplNlXqy95z1+g7wPb gUq54TiwFxw8A9KLB7E+Dh8pAK/2NsPcIPN7iyBfb7rigL6sT7GNzhs2AGMgypL7YrQR coCA== 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 j6-20020a508a86000000b004912ada1d97si30741741edj.173.2023.01.16.09.58.19; Mon, 16 Jan 2023 09:58:32 -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 S234668AbjAPRXR (ORCPT + 50 others); Mon, 16 Jan 2023 12:23:17 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234623AbjAPRWg (ORCPT ); Mon, 16 Jan 2023 12:22:36 -0500 Received: from muru.com (muru.com [72.249.23.125]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 449CE36FE9; Mon, 16 Jan 2023 09:00:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by muru.com (Postfix) with ESMTPS id AB5638108; Mon, 16 Jan 2023 17:00:31 +0000 (UTC) Date: Mon, 16 Jan 2023 19:00:30 +0200 From: Tony Lindgren To: "H. Nikolaus Schaller" Cc: Adam Ford , Andreas Kemnade , =?utf-8?Q?Beno=C3=AEt?= Cousson , robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, linux-omap@vger.kernel.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] ARM: dts: gta04: fix excess dma channel usage Message-ID: References: <20230113211151.2314874-1-andreas@kemnade.info> <4EFDE2C4-0BBB-4804-AA46-C40EB0D97AC4@goldelico.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4EFDE2C4-0BBB-4804-AA46-C40EB0D97AC4@goldelico.com> 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 * H. Nikolaus Schaller [230116 15:29]: > Hi, > > > Am 16.01.2023 um 15:51 schrieb Tony Lindgren : > > > > 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. > > Yes, indeed. See my further clarification based on what Adam commented too, I was thinking status = "disabled" at the ti-sysc parent level. > > For SoCs using firmware to manage devices it's a bit different story > > however. The firmware can still idle disabled devices based on a > > late_initcall for example, even if the kernel knows nothing about the > > disabled devices. > > But how can we then handle all devices being "okay" by default and > eating up more dma channels than are available? 1. Set the child device (not the ti-sysc node) with status = "disabled" in the board specific file as needed 2. Use /delete-property/ for dma channels in the board specific file if the device is in use but does not need dma 3. Or if this is a generic problem, we could disable dma by default for some devices > We can't put all under power management AND dma by default. > > Or can dma channel usage be postponed until the device is really used? Sure. Regards, Tony