Message-ID: <CAGXv+5Ge-uZHKATOvqQF25DRTcHFJkopUk-JUXDtpEen=BwCiA@mail.gmail.com>
Date: Thu, 30 Oct 2025 16:21:35 +0800
From: Chen-Yu Tsai <wenst@...omium.org>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com>
Cc: mathieu.poirier@...aro.org, linux-remoteproc@...r.kernel.org, 
	arnd@...db.de, andersson@...nel.org, matthias.bgg@...il.com, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-mediatek@...ts.infradead.org, kernel@...labora.com
Subject: Re: [PATCH v2] remoteproc: mtk_scp: Construct FW path if
 firmware-name not present

On Wed, Oct 29, 2025 at 7:05 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.com> wrote:
>
> Il 29/10/25 10:14, Chen-Yu Tsai ha scritto:
> > On Wed, Oct 15, 2025 at 4:41 PM AngeloGioacchino Del Regno
> > <angelogioacchino.delregno@...labora.com> wrote:
> >>
> >> After a reply on the mailing lists [1] it emerged that the DT
> >> property "firmware-name" should not be relied on because of
> >> possible issues with firmware versions.
> >> For MediaTek SCP, there has never been any firmware version vs
> >> driver version desync issue but, regardless, the firmwares are
> >> always using the same name and they're always located in a path
> >> with a specific pattern.
> >>
> >> Instead of unconditionally always relying on the firmware-name
> >> devicetree property to get a path to the SCP FW file, drivers
> >> should construct a name based on what firmware it knows and
> >> what hardware it is running on.
> >>
> >> In order to do that, add a `scp_get_default_fw_path()` function
> >> that constructs the path and filename based on two of the infos
> >> that the driver can get:
> >>   1. The compatible string with the highest priority (so, the
> >>      first one at index 0); and
> >>   2. The type of SCP HW - single-core or multi-core.
> >>
> >> This means that the default firmware path is generated as:
> >>   - Single core SCP: mediatek/(soc_model)/scp.img
> >>     for example:     mediatek/mt8183/scp.img;
> >>
> >>   - Multi core SCP:  mediatek/(soc_model)/scp_c(core_number).img
> >>     for example:     mediatek/mt8188/scp_c0.img for Core 0, and
> >>                      mediatek/mt8188/scp_c1.img for Core 1.
> >
> > I know this patch has been applied, but this scheme doesn't actually
> > follow what is already in the linux-firmware repository.
> >
> > For all the supported platforms, the first core, even for multi core SCP,
> > already have their firmware uploaded as just "scp.img". Multicore SCP
> > is seen in MT8195 and MT8188.
>
> The only one that is affected is MT8188, which needs a rename or a symlink in
> linux-firmware.
>
> MT8195 is not affected by this change, because the SCP is used as single-core,
> hence this code will look for scp.img and not for scp_c0.img.
>
> >
> > I guess I can send a followup patch?
>
> The only followup patch that I deem to be necessary is one adding a symlink
> or renaming for MT8188's SCP and nothing else.

The firmware was uploaded in March of 2025, and is packaged in Debian
Trixie, and was also backported to Bookworm. Either adding a symlink or
renaming it won't trickle down to users for some time. So this seems
like a possible ABI break, where the ABI is the file name.

Or maybe you don't consider it as such because SCP hasn't been enabled
in the kernel in any release yet?

> Please remember that some of those SoCs (including MT8195) allow the SCP to be
> configured as *either* single-core *or* dual-core - and usually firmwares for
> single-core configurations are not compatible with dual-core ones, because of
> the SRAM carveout/usage.

For MT8188, whether the current blob is dual core compatible needs to be
checked. The blob upstreamed to linux-firmware was built locally by
MediaTek engineers and is not what we ship with ChromeOS devices.


ChenYu

Powered by blists - more mailing lists