linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Nishanth Menon <nm@ti.com>, Arnd Bergmann <arnd@kernel.org>,
	Judith Mendez <jm@ti.com>, Will Deacon <will@kernel.org>,
	Bjorn Andersson <quic_bjorande@quicinc.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Neil Armstrong <neil.armstrong@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org,
	Vignesh Raghavendra <vigneshr@ti.com>, Bryan Brattlof <bb@ti.com>
Subject: Re: [RFC PATCH] arm64: defconfig: Set MFD_TPS6594_I2C as built-in
Date: Wed, 21 Aug 2024 11:43:47 +0100	[thread overview]
Message-ID: <ZsXE427Dh6w35wvz@arm.com> (raw)
In-Reply-To: <323cc7c0-8511-4d21-9925-97a6ba94280f@linaro.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


  reply	other threads:[~2024-08-21 10:44 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-19 20:43 [RFC PATCH] arm64: defconfig: Set MFD_TPS6594_I2C as built-in Judith Mendez
2024-08-19 21:01 ` Krzysztof Kozlowski
2024-08-20 11:53   ` Nishanth Menon
2024-08-21  6:33     ` Krzysztof Kozlowski
2024-08-21 10:43       ` Catalin Marinas [this message]
2024-08-21 11:00       ` Nishanth Menon
2024-08-20 16:42 ` Bjorn Andersson
2024-08-21 11:09   ` Nishanth Menon
2024-08-22 22:42     ` Judith Mendez
2024-09-26 20:10     ` Judith Mendez

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZsXE427Dh6w35wvz@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=arnd@kernel.org \
    --cc=bb@ti.com \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=geert+renesas@glider.be \
    --cc=jm@ti.com \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neil.armstrong@linaro.org \
    --cc=nm@ti.com \
    --cc=quic_bjorande@quicinc.com \
    --cc=vigneshr@ti.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).