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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id A3AD1C52D7C for ; Wed, 21 Aug 2024 10:44:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=sTq2dfoKatqrutkA4HzX/3CWFGOEysCalUrRoL3WWpo=; b=rF6Ln3JOAwtID+rAnNQKYrOIHs m8V9hfP+b1LIuPL1jPmMIeofqCOrjgmBAAaCjgr0jbdsa5aNFkfge+D4nd22s0DIQAOnaoNA/0xZp twF3ydMVzlPIOKaoWdT5vtF26VEyIK37zbB1COwmCFgZX6kwfBNw/pU85viPpO6VuynzXZJpiWn4B vRmEm5ClhNSDVIfmP1EEpu5OduOITa0L1xOfCV0XNDPs6yBC7VvUlaGdSJTSjGjmU7fWKvL1KkqAb 8OCwKfWAA8oKw2THGQwye9TKvNUo3r6eom9rOihWOgeg9PDVNqOwXikdZPrbjWeCUio9rAibTpJ0f 1AxwoPVw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgipQ-00000008SgK-3soS; Wed, 21 Aug 2024 10:44:36 +0000 Received: from nyc.source.kernel.org ([2604:1380:45d1:ec00::3]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sgioi-00000008SVm-3yY2 for linux-arm-kernel@lists.infradead.org; Wed, 21 Aug 2024 10:43:54 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 3AFEDA41172; Wed, 21 Aug 2024 10:43:45 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 602D1C32782; Wed, 21 Aug 2024 10:43:49 +0000 (UTC) Date: Wed, 21 Aug 2024 11:43:47 +0100 From: Catalin Marinas To: Krzysztof Kozlowski Cc: Nishanth Menon , Arnd Bergmann , Judith Mendez , Will Deacon , Bjorn Andersson , Geert Uytterhoeven , Dmitry Baryshkov , Neil Armstrong , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Vignesh Raghavendra , Bryan Brattlof Subject: Re: [RFC PATCH] arm64: defconfig: Set MFD_TPS6594_I2C as built-in Message-ID: References: <20240819204352.1423727-1-jm@ti.com> <1a7def3f-a19c-4f1c-845c-a3854c165995@linaro.org> <20240820115331.myibtim7enhpg4cm@mortality> <323cc7c0-8511-4d21-9925-97a6ba94280f@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <323cc7c0-8511-4d21-9925-97a6ba94280f@linaro.org> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240821_034353_069442_3C3CE4F2 X-CRM114-Status: GOOD ( 20.96 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Aug 21, 2024 at 08:33:49AM +0200, Krzysztof Kozlowski wrote: > On 20/08/2024 13:53, Nishanth Menon wrote: > > On 23:01-20240819, Krzysztof Kozlowski wrote: > >> On 19/08/2024 22:43, Judith Mendez wrote: > >>> SK-AM62A-LP is a device targeting automotive front-camera applications > >>> among other use-cases. It utilizes the TPS6593x PMIC (interfaced over I2C) > >>> to power the SoC and various other peripherals on the board [1]. > >>> > >>> MMCSD requires the PMIC to be setup correctly before setting the bus > >>> pins to 1.8V using the TPS6594 driver interfaced over i2c. > >>> > >>> Currently, the following could be seen when booting the am62ax platform: > >>> > >>> "platform fa00000.mmc: deferred probe pending: platform: supplier regulator-5 not ready" > >>> "vdd_mmc1: disabling" > >>> > >>> and a failure to boot the SK-AM62A-LP. > >>> > >>> One solution is to use initramfs [2], but using initramfs increases the > >>> boot time for this automotive solution which requires faster boot time > >>> parameters. > >> > >> This is a defconfig, not a distro/product config, so your product > >> constraints are not really relevant. You are supposed to boot defconfig > >> with proper initramfs with necessary modules. [...] > > I understand that you have provided similar comments for other > > platforms[1] as well, but, I am now wondering if this is a new rule > > we are taking in aarch64 platforms to allow just initramfs and > > force all drivers to be modules (I understand that is the default [...] > There are different point of views. I am presenting here mine and I back > it with arguments, that such changes accumulate and have impact on > developers workflow. > > Defconfig is for developers and as starting point for distros or > products. Not as final product defconfig. Drive-by comment here (defconfig is mostly an arm-soc thing): in general I agree with this position. Just because a product cannot (efficiently) use initramfs, we shouldn't pollute the default built-ins with random drivers. If you want something optimal for your product, just tweak the defconfig or take it up with the distros. I'm fine with built-ins, however, if they are required before reaching the initramfs stage (e.g. interrupt controllers) but that's not the case here. -- Catalin