Message-ID: <323cc7c0-8511-4d21-9925-97a6ba94280f@linaro.org>
Date: Wed, 21 Aug 2024 08:33:49 +0200
From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To: Nishanth Menon <nm@...com>, Arnd Bergmann <arnd@...nel.org>
Cc: Judith Mendez <jm@...com>, Catalin Marinas <catalin.marinas@....com>,
 Will Deacon <will@...nel.org>, Bjorn Andersson <quic_bjorande@...cinc.com>,
 Geert Uytterhoeven <geert+renesas@...der.be>,
 Dmitry Baryshkov <dmitry.baryshkov@...aro.org>,
 Neil Armstrong <neil.armstrong@...aro.org>,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 Vignesh Raghavendra <vigneshr@...com>, Bryan Brattlof <bb@...com>
Subject: Re: [RFC PATCH] arm64: defconfig: Set MFD_TPS6594_I2C as built-in

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 don't get why people mistake defconfig with their product stuff...
>>
>>>
>>> Another solution is to change MFD_TPS6594_I2C to built-in, that way the
>>> PMIC is setup and the regulators are ready before MMCSD switches to UHS
>>> mode, this is the preferred solution since it does not increase boot time
>>> like the initramfs solution does.
>>
>> Use initramfs. Several devices, e.g. most Android ones, have fixed size
>> of boot partition, so size of kernel is important.
> 
> am62a products do not use android in general. Standard distros such

But I (and others) use sometimes devices with Android partitioning so
the size of vmlinux is important. I want to be able to enable KASAN. If
each person brings their modules into built-in, I won't be.

> as debian etc usage are limited as well. These products tend to have
> limited resources just sufficient for the normal operations.

So defconfig is not suitable for them in the first place.

> 
> While I understand that we do keep the product usage model separate
> from what upstream defconfig looks like, we have been very careful
> to only enable the basic configurations necessary for default system
> startup. During the initial days of K3, we had considered going down
> the initramfs route, but realized that this was not a practical
> option for developers to sustain and iterate quickly for triage or
> development. Till date, we have maintained nfs and sd card boot as
> default to allow for automated testing of upstream kernel.

I don't understand what is here not practical. Entire Qualcomm Landing
team for all products uses initramfs, my Exynos development uses
initramfs. There is no difference in building the kernel, no practical
impact, the same effort (after setting up the scripts, but we all are
scripting). I know, that 10 years ago many of developers, including
myself, did not want to switch to initramfs, but things change.

> 
> 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

It's not particularly new. The use of modules for multi_v7 and
arm64/defconfig was since years.

> preference in android, but that is not true in other ecosystems). I am
> curious if this was some sort of conclusion in the list (my search of
> public-inbox seems to fail me here).

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.

>  
> [1] https://lore.kernel.org/linux-arm-kernel/e08e6325-4b2b-c1ce-b33a-877de2c0babe@linaro.org/

Best regards,
Krzysztof

Powered by blists - more mailing lists