Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Andersson <andersson@kernel.org>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>,
	Bjorn Andersson <quic_bjorande@quicinc.com>,
	Will Deacon <will@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-arm-msm@vger.kernel.org
Subject: Re: [PATCH 3/5] arm64: defconfig: Build interconnect driver for QCM2290
Date: Wed, 24 May 2023 16:14:41 -0700	[thread overview]
Message-ID: <20230524231441.5zcdp2vms6s7giz7@ripper> (raw)
In-Reply-To: <179b8c7e-d355-4051-beb4-ac44808bdaaf@app.fastmail.com>

On Wed, May 24, 2023 at 08:36:20AM +0200, Arnd Bergmann wrote:
> On Tue, May 23, 2023, at 23:11, Dmitry Baryshkov wrote:
> > On 23/05/2023 20:30, Konrad Dybcio wrote:
> >> 
> >> 
> >> On 23.05.2023 18:54, Vladimir Zapolskiy wrote:
> >>> Build Qualcomm QCM2290 interconnect driver.
> >>>
> >>> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
> >>> ---
> >> Do we know why some are =y and some are =m?
> >> 
> >> I'm for =y either way, if we can.
> >
> > I think this might change from platform to platform. What is the 
> > condition for selecting 'y' or 'm' for the core drivers? Is it 'should 
> > boot to rootfs without modules' or 'should boot to UART and load initrd 
> > without modules' ?
> 
> I think we are a bit inconsistent here. I'm generally fine taking
> changes that are required to boot into rootfs without initramfs,
> but would like everything else to be loadable modules.
> 
> Android tends to want everything as modules and require an initramfs
> for loading them, so I think platforms that are mostly Android
> specific lean towards that even for core drivers.
> 

I (any many other in the Qcom community) do most of my (our) testing and
development using a ramdisk-only approach and if systemd isn't provided
a valid /dev/console at launch, things doesn't work as expected...

So the inconsistency here relates to the fact that not all platforms has
the UART defined to depend on interconnect, once this is populated in
DT, we tend to be forced to move them to =y, together with GCC and
pinctrl-msm.


Looking to storage etc on a modern Qualcomm platform, the dependency
tree is growing quite a bit (regulators, genpd providers etc), and we
have UFS, SDHCI and NVME to support. So I think it's reasonable to have
the generic defconfig require that you use a initramfs to get further
(on the Qualcomm platforms).

Regards,
Bjorn

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-05-24 23:11 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-23 16:54 [PATCH 0/5] arm64: defconfig: build some essential Qualcomm platform drivers Vladimir Zapolskiy
2023-05-23 16:54 ` [PATCH 1/5] arm64: defconfig: Build MSM power manager driver Vladimir Zapolskiy
2023-05-23 17:29   ` Konrad Dybcio
2023-05-23 16:54 ` [PATCH 2/5] arm64: defconfig: Build Global Clock Controller driver for QCM2290 Vladimir Zapolskiy
2023-05-23 17:30   ` Konrad Dybcio
2023-05-23 16:54 ` [PATCH 3/5] arm64: defconfig: Build interconnect " Vladimir Zapolskiy
2023-05-23 17:30   ` Konrad Dybcio
2023-05-23 21:11     ` Dmitry Baryshkov
2023-05-24  6:36       ` Arnd Bergmann
2023-05-24 23:14         ` Bjorn Andersson [this message]
2023-05-25  4:28   ` Bjorn Andersson
2023-05-23 16:54 ` [PATCH 4/5] arm64: defconfig: Build display clock controller " Vladimir Zapolskiy
2023-05-23 17:30   ` Konrad Dybcio
2023-05-23 16:54 ` [PATCH 5/5] arm64: defconfig: Build SM6115 display and GPU clock controller drivers Vladimir Zapolskiy

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=20230524231441.5zcdp2vms6s7giz7@ripper \
    --to=andersson@kernel.org \
    --cc=arnd@arndb.de \
    --cc=dmitry.baryshkov@linaro.org \
    --cc=konrad.dybcio@linaro.org \
    --cc=krzysztof.kozlowski@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=quic_bjorande@quicinc.com \
    --cc=vladimir.zapolskiy@linaro.org \
    --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