* Re: [PATCH v6 0/3] Add Efinix FPGA configuration support
From: Xu Yilun @ 2026-03-30 10:38 UTC (permalink / raw)
To: iansdannapel
Cc: linux-fpga, devicetree, linux-kernel, mdf, yilun.xu, trix, robh,
krzk+dt, conor+dt, neil.armstrong, heiko, marex,
prabhakar.mahadev-lad.rj, dev
In-Reply-To: <20260327114842.1300284-1-iansdannapel@gmail.com>
On Fri, Mar 27, 2026 at 12:48:38PM +0100, iansdannapel@gmail.com wrote:
> From: Ian Dannapel <iansdannapel@gmail.com>
>
> Hi all,
>
> This is v6 of the series adding support for programming Efinix FPGAs
> over SPI using the fpga-mgr subsystem.
Sorry, I'm on vacation and cannot make it in v7.0-rc, though I assume it
should be neat as a v6.
Will try to merge it in v7.1-rc, thanks.
^ permalink raw reply
* Re: [PATCH v4 3/4] thermal/qcom/lmh: support SDM670 and its CPU clusters
From: Dmitry Baryshkov @ 2026-03-30 10:59 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Richard Acayan, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Amit Kucheria, Thara Gopinath, Bjorn Andersson, Konrad Dybcio,
linux-arm-msm, linux-pm, devicetree
In-Reply-To: <91af3fa3-85ba-44b8-8725-032f77c846de@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 12:32:29PM +0200, Konrad Dybcio wrote:
> On 3/29/26 12:44 PM, Dmitry Baryshkov wrote:
> > On Fri, Mar 27, 2026 at 09:40:40PM -0400, Richard Acayan wrote:
> >> The LMh driver was made for Qualcomm SoCs with clusters of 4 CPUs, but
> >> some SoCs divide the CPUs into different sizes of clusters. In SDM670,
> >> the first 6 CPUs are in the little cluster and the next 2 are in the big
> >> cluster. Define the clusters in the match data and define the different
> >> cluster configuration for SDM670.
> >>
> >> Currently, this only supports 8 CPUs and tolerates linking to any CPU in
> >> the cluster.
> >>
> >> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> >> ---
> >> drivers/thermal/qcom/lmh.c | 69 +++++++++++++++++++++++++++++++-------
> >> 1 file changed, 56 insertions(+), 13 deletions(-)
> >>
> >> +static const struct lmh_soc_data sdm670_lmh_data = {
> >> + .enable_algos = true,
> >> + .node_ids = {
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER1_NODE_ID,
> >> + LMH_CLUSTER1_NODE_ID,
> >> + },
> >> +};
> >> +
> >> +static const struct lmh_soc_data sdm845_lmh_data = {
> >> + .enable_algos = true,
> >> + .node_ids = {
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER1_NODE_ID,
> >> + LMH_CLUSTER1_NODE_ID,
> >> + LMH_CLUSTER1_NODE_ID,
> >> + LMH_CLUSTER1_NODE_ID,
> >> + },
> >> +};
> >
> > These tables made me wonder, can we determine this information from the
> > DT? For example, by reading the qcom,freq-domain property. But...
> >
> >> +
> >> +static const struct lmh_soc_data sm8150_lmh_data = {
> >> + .enable_algos = false,
> >> + .node_ids = {
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER0_NODE_ID,
> >> + LMH_CLUSTER1_NODE_ID,
> >> + LMH_CLUSTER1_NODE_ID,
> >> + LMH_CLUSTER1_NODE_ID,
> >> + LMH_CLUSTER1_NODE_ID,
> >> + },
> >> +};
> >
> > ... this might be problematic, unless this entry is broken. On SM8150 we
> > have three freq domains, but up to now we were programming two clustern
> > nodes. Of course it is possible to define that node_id is 0 for freq
> > domain 0 and 1 for domains 1 and 2.
>
> The third cluster situation on 8150 is not super good - we e.g. only have
> a single LMH irq that's shared between the big and prime cores. That
> was fixed with later SoCs (which is why it's not wired up in the DT today)
Thanks!
Anyway, from your point of view, would it be better to define mappings
in the driver (like it's done with this patch) or parse the DT?
> Funnily enough the bigger 8180 didn't have that problem because it only had
> 2 freq domains
Yep.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v8 02/10] dt-bindings: power: samsung: add google,gs101-pd
From: André Draszik @ 2026-03-30 10:59 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm
In-Reply-To: <b66d7230-a495-40a4-ac75-378d0727afed@kernel.org>
On Mon, 2026-03-30 at 12:55 +0200, Krzysztof Kozlowski wrote:
> On 30/03/2026 12:52, André Draszik wrote:
> > > Your patchset is organized in odd way - first patch for me, then not for
> > > me, then again two patches for me. Please keep it consistent. Or better,
> > > decouple since there are no dependencies according to cover letter.
> >
> > I'll update the cover letter to describe the dependencies. 4 depends on 2,
>
>
> How 4 (soc) patch depends on 2 (pm domains)? What is exactly the dependency?
4 updates the soc-level pmu binding of gs101 to have gs101-power-domain
child-nodes, which are introduced in 2
A.
^ permalink raw reply
* [PATCH] media: dt-bindings: media: renesas,vsp1: Document RZ/G3L VSPD
From: Biju @ 2026-03-30 10:56 UTC (permalink / raw)
To: Laurent Pinchart, Kieran Bingham, Mauro Carvalho Chehab,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm
Cc: Biju Das, linux-media, linux-renesas-soc, devicetree,
linux-kernel, Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
The VSPD block on the RZ/G3L SoC is identical to the one found on the
RZ/G2L SoC. Document RZ/G3L VSPD.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
Documentation/devicetree/bindings/media/renesas,vsp1.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
index 07a97dd87a5b..5447b9b78930 100644
--- a/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
+++ b/Documentation/devicetree/bindings/media/renesas,vsp1.yaml
@@ -25,6 +25,7 @@ properties:
- enum:
- renesas,r9a07g043u-vsp2 # RZ/G2UL
- renesas,r9a07g054-vsp2 # RZ/V2L
+ - renesas,r9a08g046-vsp2 # RZ/G3L
- renesas,r9a09g056-vsp2 # RZ/V2N
- renesas,r9a09g057-vsp2 # RZ/V2H(P)
- const: renesas,r9a07g044-vsp2 # RZ/G2L fallback
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v8 07/10] pmdomain: samsung: add support for google,gs101-pd
From: André Draszik @ 2026-03-30 10:55 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <177409897341.266364.10743294916208405425.b4-review@b4>
On Sat, 2026-03-21 at 14:16 +0100, Krzysztof Kozlowski wrote:
> On Wed, 18 Mar 2026 15:27:52 +0000, André Draszik <andre.draszik@linaro.org> wrote:
> > On Google gs101, direct mmio register access to the PMU registers
> > doesn't work and access must happen via a regmap created by the PMU
> > driver instead.
> >
> > Add a flag to the device match data to denote this case, and obtain
> > the regmap using the parent node in DT if true, while keeping to use
> > the traditional direct mmio regmap otherwise.
> >
> > Additionally, the status is just one bit on gs101.
> >
> > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com>
> > Signed-off-by: André Draszik <andre.draszik@linaro.org>
>
> There are few reviews from Sashiko which seem legitimate. Please check
> them. If they are false positives, just reply that you carefully went
> through them.
Thanks for pointing out Sashiko, seems like a useful tool! I'll go
through it.
A.
^ permalink raw reply
* Re: [PATCH v8 02/10] dt-bindings: power: samsung: add google,gs101-pd
From: Krzysztof Kozlowski @ 2026-03-30 10:55 UTC (permalink / raw)
To: André Draszik
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm
In-Reply-To: <6f0be0a71c74e7a7959e9ad02e93aff1cb8ef712.camel@linaro.org>
On 30/03/2026 12:52, André Draszik wrote:
>> Your patchset is organized in odd way - first patch for me, then not for
>> me, then again two patches for me. Please keep it consistent. Or better,
>> decouple since there are no dependencies according to cover letter.
>
> I'll update the cover letter to describe the dependencies. 4 depends on 2,
How 4 (soc) patch depends on 2 (pm domains)? What is exactly the dependency?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 3/3] arm64: dts: qcom: Add Samsung Galaxy Book4 Edge DTS/DTSI
From: Dmitry Baryshkov @ 2026-03-30 10:54 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Maxim Storetvedt, andersson, robh, krzk+dt, conor+dt, marcus,
marijn.suijten, linux-arm-msm, devicetree, linux-kernel,
abel.vesa, abel.vesa, johan, konradybcio, kirill
In-Reply-To: <12ee3569-16a6-4787-a874-bc802a50175f@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 12:41:57PM +0200, Konrad Dybcio wrote:
> On 3/26/26 7:30 PM, Maxim Storetvedt wrote:
> >
> >
> > On 3/26/26 12:33, Konrad Dybcio wrote:
> >> On 3/25/26 7:30 PM, Maxim Storetvedt wrote:
> >>>
> >>>
> >>> On 3/23/26 13:17, Konrad Dybcio wrote:
> >>>> On 3/22/26 5:03 PM, Maxim Storetvedt wrote:
> >>>>> Adds devicetrees for the 14-inch and 16-inch SKUs of the Samsung Galaxy Book4 Edge.
> >>>>>
> >>>>> These use a common dtsi derived from nodes that were able to work on Linux
> >>>>> from the initial Galaxy Book4 Edge DTS by Marcus:
> >>>>>
> >>>>> Link: https://lore.kernel.org/all/p3mhtj2rp6y2ezuwpd2gu7dwx5cbckfu4s4pazcudi4j2wogtr@4yecb2bkeyms/
> >>>>>
> >>>>> combined with the ongoing patch for the Honor Magicbook Art 14, and its downstream by
> >>>>> Valentin Manea, which shares device similarities:
> >>>>
> >>>> [...]
> >>>>
> >>>>> +&i2c8 {
> >>>>> + clock-frequency = <400000>;
> >>>>> +
> >>>>> + status = "okay";
> >>>>> +
> >>>>> + touchscreen@5d {
> >>>>> + compatible = "hid-over-i2c";
> >>>>> + reg = <0x5d>;
> >>>>> +
> >>>>> + hid-descr-addr = <0x1>;
> >>>>> + interrupts-extended = <&tlmm 34 IRQ_TYPE_LEVEL_LOW>;
> >>>>> +
> >>>>> + vdd-supply = <&vreg_misc_3p3>;
> >>>>> + /* Lower power supply is not enoug to work. */
> >>>>> + // vddl-supply = <&vreg_l15b_1p8>;
> >>>>
> >>>> How should we interpret that?
> >>>>
> >>>
> >>> This was in the original patch, but using that same regulator appears to
> >>> be enough to also get touchscreen working on the 16" book4e. That said,
> >>> it still does not work on the 14". Something to revisit later...
> >>>
> >>>>
> >>>> [...]
> >>>>
> >>>>> +&panel {
> >>>>> + compatible = "samsung,atna40cu07", "samsung,atna33xc20";
> >>>>
> >>>> I think it'd make sense to move the compatible from 'common' to the
> >>>> 16in DTS then too
> >>>>
> >>>>> + enable-gpios = <&pmc8380_3_gpios 4 GPIO_ACTIVE_HIGH>;
> >>>>
> >>>> this matches the common definition
> >>>>
> >>>>> + power-supply = <&vreg_edp_3p3>;
> >>>>
> >>>> ditto
> >>>>
> >>>>> + no-hpd;
> >>>>
> >>>> really??
> >>>>
> >>> One less thing to debug while previously attempting to work around the
> >>> "illegal link rate" error, which turned out to be related to eDP 1.4
> >>> (similar to the sp11). I've kept it as-is in case other SKUs attempt
> >>> booting from this dts, such as the x1e80100 16" (as it might be getting
> >>> a black screen using the current x1e84100 16" dts, though this is not
> >>> fully tested).
> >>
> >> So do the 80100 and 84100-equipped SKUs of the laptop come with different
> >> displays?
> >>
> >> Konrad
> >
> > So far assumed both 16" variants to be fairly similar, though one
> > valiant 16" 80100 user over in the debug thread did try to boot via the
> > 84100 dts, with no success. Instead having the screen go dark after the
> > first post-tux kernel prints.
>
> Does switching to the generic edp-panel compatible (which will parse the
> EDID and try not to be overly smart about it) help here?
I think it was not possible because those panels need special treatment.
>
> > This was strapped together via WSL though, so could be there was
> > something else at fault, but strange it didn't at least fall back to a
> > visible initramfs shell.
>
> You mean the kernel had been compiled via WSL? That shouldn't be a problem..
>
> Konrad
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Krzysztof Kozlowski @ 2026-03-30 10:53 UTC (permalink / raw)
To: Jian Hu
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <ebc6da60-d49f-4a44-9ecb-3ae70413a248@kernel.org>
On 30/03/2026 12:48, Krzysztof Kozlowski wrote:
> On 30/03/2026 12:44, Jian Hu wrote:
>>
>> On 3/27/2026 3:23 PM, Krzysztof Kozlowski wrote:
>>> [ EXTERNAL EMAIL ]
>>>
>>> On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
>>>> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>>>>
>>>> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
>>> Please run scripts/checkpatch.pl on the patches and fix reported
>>> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
>>> patches and (probably) fix more warnings. Some warnings can be ignored,
>>> especially from --strict run, but the code here looks like it needs a
>>> fix. Feel free to get in touch if the warning is not clear.
>>
>>
>> Thanks for your review.
>>
>>
>> This series is based on the clk-next branch (version v7.0-rc1).
>>
>>
>> Here are the check results without --strict:
>>
>
> I checked before. Now I double checked:
>
> b4 shazam...
> git format-patch -3
> scripts/checkpatch.pl 0*
>
> Clearly a warning, also on v7.0-rc1.
>
> So maybe you don't do it on the kernel you are claiming or just doing it
> on different code than you sent.
>
It looks like it is b4 shazam problem which duplicates the Fixes tag. I
don't quite get why the tag is duplicated. I don't see anything on the
lists which would add wrong tag.
Well, that will be problem when applying, but nothing to be fixed here, so:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 05/10] pmdomain: samsung: convert to using regmap
From: André Draszik @ 2026-03-30 10:53 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm, Marek Szyprowski
In-Reply-To: <177409897341.266364.2957933304869869135.b4-review@b4>
On Sat, 2026-03-21 at 14:16 +0100, Krzysztof Kozlowski wrote:
> On Wed, 18 Mar 2026 15:27:50 +0000, André Draszik <andre.draszik@linaro.org> wrote:
> > diff --git a/drivers/pmdomain/samsung/exynos-pm-domains.c b/drivers/pmdomain/samsung/exynos-pm-domains.c
> > index 5c3aa8983087..68b1e7ba8729 100644
> > --- a/drivers/pmdomain/samsung/exynos-pm-domains.c
> > +++ b/drivers/pmdomain/samsung/exynos-pm-domains.c
> > @@ -120,9 +140,26 @@ static int exynos_pd_probe(struct platform_device *pdev)
> > [ ... skip 20 lines ... ]
> > +
> > + reg_config.max_register = resource_size(res) - reg_config.reg_stride;
> > + pd->regmap = devm_regmap_init_mmio(dev, base, ®_config);
> > + if (IS_ERR(pd->regmap))
> > + return dev_err_probe(dev, PTR_ERR(base),
> > + "failed to init regmap\n");
>
> PTR_ERR(pd->regmap)
Thanks!
A.
^ permalink raw reply
* Re: [PATCH v2 6/7] dt-bindings: PCI: intel,lgm-pcie: Make atu resource mandatory
From: Florian Eckert @ 2026-03-30 10:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Johan Hovold,
Sajid Dalvi, Ajay Agarwal, Krzysztof Kozlowski, Conor Dooley,
Rahul Tanwar, linux-pci, linux-kernel, devicetree, Eckert.Florian,
ms
In-Reply-To: <b8c60db1-7b72-410e-95a1-f13052af7256@kernel.org>
On 2026-03-30 11:50, Krzysztof Kozlowski wrote:
> On 30/03/2026 11:07, Florian Eckert wrote:
>> The ATU information is already set in the dwc core if it is specified
>> in
>> the DTS. The driver uses its own value here [1]. This information is
>> hardware specific and should therefore be maintained in the DTS rather
>> than in the source.
>>
>> Backwards compatibility is not an issue here [5], as the driver is
>> exclusively used by Maxlinear.
>
> What does that mean exactly? It is not used outside of Maxlinear
> company, so it is purely internal device and no one outside of
> Maxlinear
> has it?
Background information:
The PCIe IP core is only available for Maxlinear’s URX851 and
URX850 SoCs. However, the chip was originally developed by Intel when
they acquired Lantiq’s home networking division in 2015 [1] for this
SoCs. In 2020 the home network division was sold to Maxlinear [2].
Since then, Maxlinear has been responsible for the driver. However,
their SDK is outdated and based on kernel 5.15. Other than that, not
much is happening! Even the developers listed as maintainers can no
longer be reached. When it came to the patch set, the email couldn't
be delivered to the responsible developer
'Chuanhua Lei <lchuanhua@maxlinear.com>' either. The email bounced
back.
The company I work for is using the chip and is currently in the
process of extracting the key components from the SDK so that the
SoC URX851/URX850 can work again with a mainline kernel again.
[1]
https://www.intc.com/news-events/press-releases/detail/364/intel-to-acquire-lantiq-advancing-the-connected-home
[2]
https://investors.maxlinear.com/press-releases/detail/395/maxlinear-to-acquire-intels-home-gateway-platform
> Then we can as well remove it and I don't quite get why you are working
> on this (since no one can use it outside of Maxlinear...).
Maxlinear continues to sell that SoC. They are *not' EOL.
It’s just that their Board Support Package (SDK) is no longer
up to date.
>>
>> Old DTS entry for PCIe:
>>
>> reg = <0xd1000000 0x1000>,
>> <0xd3000000 0x20000>,
>> <0xd0c41000.0x1000>;
>> reg-names = "dbi", "config", "app";
>>
>> New DTS entry for PCIe:
>>
>> reg = <0xd1000000 0x1000>,
>> <0xd10c0000 0x1000>,
>> <0xd3000000 0x20000>,
>> <0xd0c41000.0x1000>;
>> reg-names = "dbi", "atu", "config", "app";
>
> Drop, irrelevant. You still break all users of this binding.
As noted in link [3], a Maxlinear developer has stated that
backwards compatibility is not necessary here, as the IP core
is used exclusively by Maxlinear`s URX851 and URX850 SoC`s.
We use these SoCs in our Produkt for internet home gateway
routers.
[3]
https://lore.kernel.org/all/BY3PR19MB507667CE7531D863E1E5F8AEBDD82@BY3PR19MB5076.namprd19.prod.outlook.com/
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v8 02/10] dt-bindings: power: samsung: add google,gs101-pd
From: André Draszik @ 2026-03-30 10:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Alim Akhtar, Rob Herring, Conor Dooley, Krzysztof Kozlowski,
Ulf Hansson, Liam Girdwood, Mark Brown, Peter Griffin,
Tudor Ambarus, Juan Yescas, Will McVicker, kernel-team,
linux-arm-kernel, linux-samsung-soc, devicetree, linux-kernel,
linux-pm
In-Reply-To: <177409897339.266364.69715997034739052.b4-review@b4>
Hi Krzysztof,
On Sat, 2026-03-21 at 14:16 +0100, Krzysztof Kozlowski wrote:
> On Wed, 18 Mar 2026 15:27:47 +0000, André Draszik <andre.draszik@linaro.org> wrote:
> > diff --git a/Documentation/devicetree/bindings/power/pd-samsung.yaml b/Documentation/devicetree/bindings/power/pd-samsung.yaml
> > index 9c2c51133457..3f1a2dc17862 100644
> > --- a/Documentation/devicetree/bindings/power/pd-samsung.yaml
> > +++ b/Documentation/devicetree/bindings/power/pd-samsung.yaml
> > @@ -44,11 +45,28 @@ properties:
> > power-domains:
> > maxItems: 1
> >
> > + samsung,dtzpc:
> > + $ref: /schemas/types.yaml#/definitions/phandle
> > + description:
> > + Distributed TrustZone Protection Control (DTZPC) node.
>
> For what purpose?
It is part of the domain.
Furthermore, TZ configuration is lost as part of power-domain power
cycle, so this allows a driver to take necessary actions (inform the
EL3 firmware). I believe this handle to be similar to e.g. the existing
samsung,sysreg
> Your patchset is organized in odd way - first patch for me, then not for
> me, then again two patches for me. Please keep it consistent. Or better,
> decouple since there are no dependencies according to cover letter.
I'll update the cover letter to describe the dependencies. 4 depends on 2,
and 2 depends on 1, hence the ordering.
Cheers,
Andre
^ permalink raw reply
* Re: [PATCH v2] arm64: dts: monaco: extend fastrpc compute cb
From: Konrad Dybcio @ 2026-03-30 10:50 UTC (permalink / raw)
To: Srinivas Kandagatla, andersson, konradybcio, robh, krzk+dt,
conor+dt, Ekansh Gupta, Dmitry Baryshkov
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <3419a58c-c099-4dda-a019-4900419aea9b@oss.qualcomm.com>
On 3/30/26 10:38 AM, Srinivas Kandagatla wrote:
> On 3/27/26 1:10 PM, Konrad Dybcio wrote:
>> On 3/26/26 4:41 PM, Srinivas Kandagatla wrote:
>>> For some reason we ended up adding only 4 out of 11 compute cb's for
>>> CDSP, add the missing compute cb. This will also improve the end
>>> user-experience by enabling running multiple AI usecases in parallel.
>>>
>>> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
>>> ---
>>> arch/arm64/boot/dts/qcom/monaco.dtsi | 49 ++++++++++++++++++++++++++++
>>> 1 file changed, 49 insertions(+)
>>>
>>> diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
>>> index 10e799dd4a78..38fbd44c7d8f 100644
>>> --- a/arch/arm64/boot/dts/qcom/monaco.dtsi
>>> +++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
>>> @@ -7739,6 +7739,55 @@ compute-cb@4 {
>>> <&apps_smmu 0x1964 0x0400>;
>>> dma-coherent;
>>> };
>>> +
>>> + compute-cb@5 {
>>> + compatible = "qcom,fastrpc-compute-cb";
>>> + reg = <5>;
>>> + iommus = <&apps_smmu 0x19c5 0x0400>;
>>
>> I see that the other CBs have 2 iommu streams, the other one
>> having "DMA" in the name - could you shed some light on that?
>
> AFAIU, These DMA streams are relevant when NPU dma engine is in the
> picture, examples can be data pipelines which involve transferring data
> buffers(in/out) in-cordination with different IP blocks outside DSP. May
> be something like camera/video streams directly to NPU without CPU
> involving...
>
> Personally I have not tested such usecases, but for upstream fastrpc
> clients AFAIK only application streams matter as clients will explicitly
> allocate the data buffers, even for sharing across ip-blocks.
This would be nice to confirm somewhere, perhaps even denote in bindings
+Ekansh could you confirm/speak more about this?
+Dmitry for awareness
Konrad
^ permalink raw reply
* [PATCH 5/7] dt-bindings: cache: ax45mp-cache: rename ax45mp-cache to llcache
From: Hui Min Mina Chou @ 2026-03-30 10:27 UTC (permalink / raw)
To: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc
Cc: tim609, alex749, az70021, Hui Min Mina Chou
In-Reply-To: <20260330102724.1012470-1-minachou@andestech.com>
The AX45MP-specific cache binding is renamed to a generic Last Level
Cache (LLC) schema, as the driver now supports more Andes CPU cores
beyond just AX45MP.
Updated compatible strings:
andestech,qilai-ax45mp-cache -> andestech,qilai-llcache
renesas,r9a07g043f-ax45mp-cache -> renesas,r9a07g043f-llcache
andestech,ax45mp-cache -> andestech,llcache
Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
---
...ache.yaml => andestech,andes-llcache.yaml} | 20 +++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
rename Documentation/devicetree/bindings/cache/{andestech,ax45mp-cache.yaml => andestech,andes-llcache.yaml} (76%)
diff --git a/Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml b/Documentation/devicetree/bindings/cache/andestech,andes-llcache.yaml
similarity index 76%
rename from Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml
rename to Documentation/devicetree/bindings/cache/andestech,andes-llcache.yaml
index b135ffa4ab6b..5b97625edd37 100644
--- a/Documentation/devicetree/bindings/cache/andestech,ax45mp-cache.yaml
+++ b/Documentation/devicetree/bindings/cache/andestech,andes-llcache.yaml
@@ -2,17 +2,17 @@
# Copyright (C) 2023 Renesas Electronics Corp.
%YAML 1.2
---
-$id: http://devicetree.org/schemas/cache/andestech,ax45mp-cache.yaml#
+$id: http://devicetree.org/schemas/cache/andestech,llcache.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Andestech AX45MP L2 Cache Controller
+title: Andestech Last Level Cache Controller
maintainers:
- Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
description:
- A level-2 cache (L2C) is used to improve the system performance by providing
- a large amount of cache line entries and reasonable access delays. The L2C
+ A last level cache (LLC) is used to improve the system performance by providing
+ a large amount of cache line entries and reasonable access delays. The LLC
is shared between cores, and a non-inclusive non-exclusive policy is used.
select:
@@ -20,7 +20,7 @@ select:
compatible:
contains:
enum:
- - andestech,ax45mp-cache
+ - andestech,llcache
required:
- compatible
@@ -29,9 +29,9 @@ properties:
compatible:
items:
- enum:
- - andestech,qilai-ax45mp-cache
- - renesas,r9a07g043f-ax45mp-cache
- - const: andestech,ax45mp-cache
+ - andestech,qilai-llcache
+ - renesas,r9a07g043f-llcache
+ - const: andestech,llcache
- const: cache
reg:
@@ -73,7 +73,7 @@ allOf:
properties:
compatible:
contains:
- const: andestech,qilai-ax45mp-cache
+ const: andestech,qilai-llcache
then:
properties:
@@ -91,7 +91,7 @@ examples:
#include <dt-bindings/interrupt-controller/irq.h>
cache-controller@13400000 {
- compatible = "renesas,r9a07g043f-ax45mp-cache", "andestech,ax45mp-cache",
+ compatible = "renesas,r9a07g043f-llcache", "andestech,llcache",
"cache";
reg = <0x13400000 0x100000>;
interrupts = <508 IRQ_TYPE_LEVEL_HIGH>;
--
2.34.1
^ permalink raw reply related
* [PATCH 7/7] MAINTAINERS: Add maintainers for Andes cache driver
From: Hui Min Mina Chou @ 2026-03-30 10:27 UTC (permalink / raw)
To: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc
Cc: tim609, alex749, az70021, Hui Min Mina Chou
In-Reply-To: <20260330102724.1012470-1-minachou@andestech.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="y", Size: 832 bytes --]
Here add maintainer information for Andes cache driver.
Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
---
MAINTAINERS | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 23d88c825175..e95efbcd6d39 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1863,6 +1863,14 @@ S: Supported
F: Documentation/devicetree/bindings/spi/andestech,ae350-spi.yaml
F: drivers/spi/spi-atcspi200.c
+ANDES CACHE DRIVER
+M: Alex Chun-Ju Lin <alex749@andestech.com>
+M: Leo Yu-Chi Liang <ycliang@andestech.com>
+M: Mina Hui Min Chou <minachou@andestech.com>
+S: Supported
+F: Documentation/devicetree/bindings/cache/andestech,andes-llcache.yaml
+F: drivers/cache/andes_llcache.c
+
ANDROID DRIVERS
M: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M: Arve Hjønnevåg <arve@android.com>
--
2.34.1
^ permalink raw reply related
* [PATCH 4/7] cache: andes_llcache: centralize cache ops and use native WBINVAL
From: Hui Min Mina Chou @ 2026-03-30 10:27 UTC (permalink / raw)
To: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc
Cc: tim609, alex749, az70021, Hui Min Mina Chou
In-Reply-To: <20260330102724.1012470-1-minachou@andestech.com>
Introduce andes_cpu_cache_operation() to centralize address
translation, alignment, and IRQ handling, removing the redundant
wrappers andes_cpu_dcache_wb_range and andes_cpu_dcache_inval_range.
This refactoring includes the following refinements:
- Consolidates address translation, boundary alignment, and IRQ handling
(local_irq_save/restore) into the central function.
- Make IRQ handling per cache line instead of across the entire cache
operation.
- Cleans up redundant intermediate wrapper functions
(andes_cpu_dcache_wb_range, andes_cpu_dcache_inval_range).
- wback_inv was chaining wback + inv separately; use the hardware's
native WBINVAL CCTL instead, which does both in one shot.
Signed-off-by: Alex Chun-Ju Lin <alex749@andestech.com>
Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
---
drivers/cache/andes_llcache.c | 63 ++++++++++++-----------------------
1 file changed, 21 insertions(+), 42 deletions(-)
diff --git a/drivers/cache/andes_llcache.c b/drivers/cache/andes_llcache.c
index 57f666bc537a..0efa6e9c80bd 100644
--- a/drivers/cache/andes_llcache.c
+++ b/drivers/cache/andes_llcache.c
@@ -69,21 +69,29 @@ static inline uint32_t andes_cpu_llc_get_cctl_status(void)
return readl_relaxed(andes_priv.llc_base + ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0);
}
-static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
- unsigned int l1_op, unsigned int llc_op)
+static void andes_cpu_cache_operation(phys_addr_t paddr, size_t size,
+ unsigned int l1_op, unsigned int llc_op)
{
unsigned long line_size = andes_priv.andes_cache_line_size;
void __iomem *base = andes_priv.llc_base;
+ unsigned long start = (unsigned long)phys_to_virt(paddr);
+ unsigned long end = start + size;
+ unsigned long flags;
unsigned long pa;
int mhartid = 0;
+ start = ALIGN_DOWN(start, line_size);
+ end = ALIGN(end, line_size);
+
if (IS_ENABLED(CONFIG_SMP))
mhartid = cpuid_to_hartid_map(get_cpu());
else
mhartid = cpuid_to_hartid_map(0);
mb(); /* complete earlier memory accesses before the cache flush */
- while (end > start) {
+ for (; start < end; start += line_size) {
+ local_irq_save(flags);
+
csr_write(CSR_UCCTLBEGINADDR, start);
csr_write(CSR_UCCTLCOMMAND, l1_op);
@@ -95,7 +103,7 @@ static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
ANDES_LLC_CCTL_STATUS_IDLE)
;
- start += line_size;
+ local_irq_restore(flags);
}
mb(); /* issue later memory accesses after the cache flush */
@@ -103,60 +111,31 @@ static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
put_cpu();
}
-/* Write-back L1 and LLC entry */
-static inline void andes_cpu_dcache_wb_range(unsigned long start, unsigned long end)
-{
- andes_cpu_cache_operation(start, end, ANDES_L1D_CCTL_VA_WB,
- ANDES_LLC_CCTL_PA_WB);
-}
-
-/* Invalidate the L1 and LLC entry */
-static inline void andes_cpu_dcache_inval_range(unsigned long start, unsigned long end)
-{
- andes_cpu_cache_operation(start, end, ANDES_L1D_CCTL_VA_INVAL,
- ANDES_LLC_CCTL_PA_INVAL);
-}
-
static void andes_dma_cache_inv(phys_addr_t paddr, size_t size)
{
- unsigned long start = (unsigned long)phys_to_virt(paddr);
- unsigned long end = start + size;
- unsigned long line_size = andes_priv.andes_cache_line_size;
- unsigned long flags;
-
if (unlikely(!size))
return;
- start = ALIGN_DOWN(start, line_size);
- end = ALIGN(end, line_size);
-
- local_irq_save(flags);
- andes_cpu_dcache_inval_range(start, end);
- local_irq_restore(flags);
+ andes_cpu_cache_operation(paddr, size, ANDES_L1D_CCTL_VA_INVAL,
+ ANDES_LLC_CCTL_PA_INVAL);
}
static void andes_dma_cache_wback(phys_addr_t paddr, size_t size)
{
- unsigned long start = (unsigned long)phys_to_virt(paddr);
- unsigned long end = start + size;
- unsigned long line_size = andes_priv.andes_cache_line_size;
- unsigned long flags;
-
if (unlikely(!size))
return;
- start = ALIGN_DOWN(start, line_size);
- end = ALIGN(end, line_size);
-
- local_irq_save(flags);
- andes_cpu_dcache_wb_range(start, end);
- local_irq_restore(flags);
+ andes_cpu_cache_operation(paddr, size, ANDES_L1D_CCTL_VA_WB,
+ ANDES_LLC_CCTL_PA_WB);
}
static void andes_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
{
- andes_dma_cache_wback(paddr, size);
- andes_dma_cache_inv(paddr, size);
+ if (unlikely(!size))
+ return;
+
+ andes_cpu_cache_operation(paddr, size, ANDES_L1D_CCTL_VA_WBINVAL,
+ ANDES_LLC_CCTL_PA_WBINVAL);
}
static int andes_get_llc_line_size(struct device_node *np)
--
2.34.1
^ permalink raw reply related
* [PATCH 3/7] cache: andes_llcache: improve performance of LLC operation
From: Hui Min Mina Chou @ 2026-03-30 10:27 UTC (permalink / raw)
To: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc
Cc: tim609, alex749, az70021, Hui Min Mina Chou, Leo Yu-Chi Liang
In-Reply-To: <20260330102724.1012470-1-minachou@andestech.com>
Eliminate get_cpu() on !CONFIG_SMP and switch readl/writel to their
relaxed variants to remove unnecessary fence instructions on I/O
memory access. The platform specification defines all I/O regions are
on channel 0 (point-to-point strongly ordered), so explicit fences are
not required [1][2][3]. Explicit memory barriers (mb) are added before
and after the CCTL loop to ensure overall memory consistency.
Also fix hart ID mapping by switching to cpuid_to_hartid_map() instead
of using the logical CPU ID directly. In AMP setups (e.g. Linux on
Hart 1, RTOS on Hart 0), Linux sees itself as CPU 0 but must access
Hart 1's CCTL registers, so using the logical ID would cause accidental
interference with other cores.
[1] platform spec 2.1.1: https://github.com/riscvarchive/riscv-platform-specs/blob/main/riscv-platform-spec.adoc?plain=1#L169
[2] privileged spec 3.6.5: https://github.com/riscv/riscv-isa-manual/blob/main/src/machine.adoc?plain=1#L2835
[3] riscv: asm/mmio.h: https://gitea.andestech.com/RD-SW/linux/src/branch/ast-v5_4_0-branch/arch/riscv/include/asm/mmio.h#L105
Signed-off-by: Leo Yu-Chi Liang <ycliang@andestech.com>
Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
---
drivers/cache/andes_llcache.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/drivers/cache/andes_llcache.c b/drivers/cache/andes_llcache.c
index d318b8009f7f..57f666bc537a 100644
--- a/drivers/cache/andes_llcache.c
+++ b/drivers/cache/andes_llcache.c
@@ -66,7 +66,7 @@ static struct andes_priv andes_priv;
/* LLC operations */
static inline uint32_t andes_cpu_llc_get_cctl_status(void)
{
- return readl(andes_priv.llc_base + ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0);
+ return readl_relaxed(andes_priv.llc_base + ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0);
}
static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
@@ -74,16 +74,22 @@ static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
{
unsigned long line_size = andes_priv.andes_cache_line_size;
void __iomem *base = andes_priv.llc_base;
- int mhartid = smp_processor_id();
unsigned long pa;
+ int mhartid = 0;
+ if (IS_ENABLED(CONFIG_SMP))
+ mhartid = cpuid_to_hartid_map(get_cpu());
+ else
+ mhartid = cpuid_to_hartid_map(0);
+
+ mb(); /* complete earlier memory accesses before the cache flush */
while (end > start) {
csr_write(CSR_UCCTLBEGINADDR, start);
csr_write(CSR_UCCTLCOMMAND, l1_op);
pa = virt_to_phys((void *)start);
- writel(pa, base + ANDES_LLC_REG_CCTL_ACC_OFFSET_BY_CORE(mhartid));
- writel(llc_op, base + ANDES_LLC_REG_CCTL_CMD_OFFSET_BY_CORE(mhartid));
+ writel_relaxed(pa, base + ANDES_LLC_REG_CCTL_ACC_OFFSET_BY_CORE(mhartid));
+ writel_relaxed(llc_op, base + ANDES_LLC_REG_CCTL_CMD_OFFSET_BY_CORE(mhartid));
while ((andes_cpu_llc_get_cctl_status() &
ANDES_LLC_CCTL_STATUS_MASK_BY_CORE(mhartid)) !=
ANDES_LLC_CCTL_STATUS_IDLE)
@@ -91,6 +97,10 @@ static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
start += line_size;
}
+ mb(); /* issue later memory accesses after the cache flush */
+
+ if (IS_ENABLED(CONFIG_SMP))
+ put_cpu();
}
/* Write-back L1 and LLC entry */
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Krzysztof Kozlowski @ 2026-03-30 10:48 UTC (permalink / raw)
To: Jian Hu
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <9830ff89-a145-41d1-98e9-1412f497d3f2@amlogic.com>
On 30/03/2026 12:44, Jian Hu wrote:
>
> On 3/27/2026 3:23 PM, Krzysztof Kozlowski wrote:
>> [ EXTERNAL EMAIL ]
>>
>> On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
>>> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>>>
>>> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
>> Please run scripts/checkpatch.pl on the patches and fix reported
>> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
>> patches and (probably) fix more warnings. Some warnings can be ignored,
>> especially from --strict run, but the code here looks like it needs a
>> fix. Feel free to get in touch if the warning is not clear.
>
>
> Thanks for your review.
>
>
> This series is based on the clk-next branch (version v7.0-rc1).
>
>
> Here are the check results without --strict:
>
I checked before. Now I double checked:
b4 shazam...
git format-patch -3
scripts/checkpatch.pl 0*
Clearly a warning, also on v7.0-rc1.
So maybe you don't do it on the kernel you are claiming or just doing it
on different code than you sent.
Especially the second case would be a waste of my time to investigate
and read this patch.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH 2/7] cache: andes_llcache: refactor initialization and cache operations
From: Hui Min Mina Chou @ 2026-03-30 10:27 UTC (permalink / raw)
To: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc
Cc: tim609, alex749, az70021, Hui Min Mina Chou
In-Reply-To: <20260330102724.1012470-1-minachou@andestech.com>
This patch cleans up the Andes LLC cache driver:
- improved error handling in andes_cache_init() by using goto labels
- updated andes_dma_cache_inv/wback() to check for !size instead of
start == end
- cache-line-size mismatch from an error to a warning
- Use ALIGN and ALIGN_DOWN helpers instead of the alignment logic in
andes_dma_cache_inv() and andes_dma_cache_wback().
Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
---
drivers/cache/andes_llcache.c | 56 ++++++++++++++++++-----------------
1 file changed, 29 insertions(+), 27 deletions(-)
diff --git a/drivers/cache/andes_llcache.c b/drivers/cache/andes_llcache.c
index d5e382f3c801..d318b8009f7f 100644
--- a/drivers/cache/andes_llcache.c
+++ b/drivers/cache/andes_llcache.c
@@ -111,21 +111,17 @@ static void andes_dma_cache_inv(phys_addr_t paddr, size_t size)
{
unsigned long start = (unsigned long)phys_to_virt(paddr);
unsigned long end = start + size;
- unsigned long line_size;
+ unsigned long line_size = andes_priv.andes_cache_line_size;
unsigned long flags;
- if (unlikely(start == end))
+ if (unlikely(!size))
return;
- line_size = andes_priv.andes_cache_line_size;
-
- start = start & (~(line_size - 1));
- end = ((end + line_size - 1) & (~(line_size - 1)));
+ start = ALIGN_DOWN(start, line_size);
+ end = ALIGN(end, line_size);
local_irq_save(flags);
-
andes_cpu_dcache_inval_range(start, end);
-
local_irq_restore(flags);
}
@@ -133,15 +129,15 @@ static void andes_dma_cache_wback(phys_addr_t paddr, size_t size)
{
unsigned long start = (unsigned long)phys_to_virt(paddr);
unsigned long end = start + size;
- unsigned long line_size;
+ unsigned long line_size = andes_priv.andes_cache_line_size;
unsigned long flags;
- if (unlikely(start == end))
+ if (unlikely(!size))
return;
- line_size = andes_priv.andes_cache_line_size;
- start = start & (~(line_size - 1));
- end = ((end + line_size - 1) & (~(line_size - 1)));
+ start = ALIGN_DOWN(start, line_size);
+ end = ALIGN(end, line_size);
+
local_irq_save(flags);
andes_cpu_dcache_wb_range(start, end);
local_irq_restore(flags);
@@ -159,14 +155,13 @@ static int andes_get_llc_line_size(struct device_node *np)
ret = of_property_read_u32(np, "cache-line-size", &andes_priv.andes_cache_line_size);
if (ret) {
- pr_err("Failed to get cache-line-size, defaulting to 64 bytes\n");
+ pr_err("Cache: Failed to get cache-line-size\n");
return ret;
}
if (andes_priv.andes_cache_line_size != ANDES_CACHE_LINE_SIZE) {
- pr_err("Expected cache-line-size to be 64 bytes (found:%u)\n",
- andes_priv.andes_cache_line_size);
- return -EINVAL;
+ pr_warn("Cache: Expected cache-line-size to be 64 bytes (found:%u)\n",
+ andes_priv.andes_cache_line_size);
}
return 0;
@@ -186,16 +181,18 @@ static const struct of_device_id andes_cache_ids[] = {
static int __init andes_cache_init(void)
{
struct resource res;
- int ret;
+ int ret = 0;
struct device_node *np __free(device_node) =
of_find_matching_node(NULL, andes_cache_ids);
- if (!of_device_is_available(np))
- return -ENODEV;
+ if (!of_device_is_available(np)) {
+ ret = -ENODEV;
+ goto err_ret;
+ }
ret = of_address_to_resource(np, 0, &res);
if (ret)
- return ret;
+ goto err_ret;
/*
* If IOCP is present on the Andes AX45MP core riscv_cbom_block_size
@@ -208,17 +205,22 @@ static int __init andes_cache_init(void)
return 0;
andes_priv.llc_base = ioremap(res.start, resource_size(&res));
- if (!andes_priv.llc_base)
- return -ENOMEM;
+ if (!andes_priv.llc_base) {
+ ret = -ENOMEM;
+ goto err_ret;
+ }
ret = andes_get_llc_line_size(np);
- if (ret) {
- iounmap(andes_priv.llc_base);
- return ret;
- }
+ if (ret)
+ goto err_unmap;
riscv_noncoherent_register_cache_ops(&andes_cmo_ops);
return 0;
+
+err_unmap:
+ iounmap(andes_priv.llc_base);
+err_ret:
+ return ret;
}
early_initcall(andes_cache_init);
--
2.34.1
^ permalink raw reply related
* [PATCH 1/7] cache: ax45mp_cache: refactor cache driver for generic Andes platform support
From: Hui Min Mina Chou @ 2026-03-30 10:27 UTC (permalink / raw)
To: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc
Cc: tim609, alex749, az70021, Hui Min Mina Chou, charles
In-Reply-To: <20260330102724.1012470-1-minachou@andestech.com>
Andes cache driver is not only usable with the AX45MP CPU but can also be
applied to other CPU within Andes platform (such as A27L2).
To improve maintainability and support future SoCs, this patch performs a
comprehensive refactoring to move away from model-specific naming.
key changes include:
- replaced AX45MP-specific Kconfig and function names with generic "ANDES"
prefixes to support multiple CPU types
- updated all L2-related identifiers, structs, and prefixes to "LLC"
to accurately reflect its role as the system's last-level cache
- moved UCCTL* CSR definitions to <linux/soc/andes/csr.h>
- standardized L1D and LLC macro prefixes (ANDES_L1D_* and ANDES_LLC_*)
for better clarity
- renamed compatible strings from ax45mp-cache to generic llcache
- rename ax45mp_cache.c to andes_llcache.c
This is a structural refactoring; no functional behavior is changed.
Signed-off-by: charles <dminus@andestech.com>
Signed-off-by: Hui Min Mina Chou <minachou@andestech.com>
---
arch/riscv/Kconfig.errata | 2 +-
drivers/cache/Kconfig | 6 +-
drivers/cache/Makefile | 2 +-
drivers/cache/andes_llcache.c | 224 ++++++++++++++++++++++++++++++++++
drivers/cache/ax45mp_cache.c | 217 --------------------------------
drivers/soc/renesas/Kconfig | 2 +-
include/linux/soc/andes/csr.h | 12 ++
7 files changed, 242 insertions(+), 223 deletions(-)
create mode 100644 drivers/cache/andes_llcache.c
delete mode 100644 drivers/cache/ax45mp_cache.c
create mode 100644 include/linux/soc/andes/csr.h
diff --git a/arch/riscv/Kconfig.errata b/arch/riscv/Kconfig.errata
index 3c945d086c7d..e32f1563ce3a 100644
--- a/arch/riscv/Kconfig.errata
+++ b/arch/riscv/Kconfig.errata
@@ -1,7 +1,7 @@
menu "CPU errata selection"
config ERRATA_ANDES
- bool "Andes AX45MP errata"
+ bool "Andes errata"
depends on RISCV_ALTERNATIVE && RISCV_SBI
help
All Andes errata Kconfig depend on this Kconfig. Disabling
diff --git a/drivers/cache/Kconfig b/drivers/cache/Kconfig
index 1518449d47b5..78142189f45c 100644
--- a/drivers/cache/Kconfig
+++ b/drivers/cache/Kconfig
@@ -10,11 +10,11 @@ menuconfig CACHEMAINT_FOR_DMA
if CACHEMAINT_FOR_DMA
-config AX45MP_L2_CACHE
- bool "Andes Technology AX45MP L2 Cache controller"
+config ANDES_CACHE
+ bool "Andes platform CPUs Cache controller"
select RISCV_NONSTANDARD_CACHE_OPS
help
- Support for the L2 cache controller on Andes Technology AX45MP platforms.
+ Support for the L1 and LLC (last level cache) controller on Andes platform CPUs.
config SIFIVE_CCACHE
bool "Sifive Composable Cache controller"
diff --git a/drivers/cache/Makefile b/drivers/cache/Makefile
index b3362b15d6c1..4a218ad6cec0 100644
--- a/drivers/cache/Makefile
+++ b/drivers/cache/Makefile
@@ -1,6 +1,6 @@
# SPDX-License-Identifier: GPL-2.0
-obj-$(CONFIG_AX45MP_L2_CACHE) += ax45mp_cache.o
+obj-$(CONFIG_ANDES_CACHE) += andes_llcache.o
obj-$(CONFIG_SIFIVE_CCACHE) += sifive_ccache.o
obj-$(CONFIG_STARFIVE_STARLINK_CACHE) += starfive_starlink_cache.o
diff --git a/drivers/cache/andes_llcache.c b/drivers/cache/andes_llcache.c
new file mode 100644
index 000000000000..d5e382f3c801
--- /dev/null
+++ b/drivers/cache/andes_llcache.c
@@ -0,0 +1,224 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * non-coherent cache operations for Andes Platform CPUs.
+ *
+ * Copyright (C) 2023 Renesas Electronics Corp.
+ */
+
+#include <linux/cacheflush.h>
+#include <linux/cacheinfo.h>
+#include <linux/dma-direction.h>
+#include <linux/of_address.h>
+#include <linux/of_platform.h>
+#include <linux/soc/andes/csr.h>
+
+#include <asm/dma-noncoherent.h>
+
+/* L1 D-cache operation encoding */
+#define ANDES_L1D_CCTL_VA_INVAL 0x0 /* Invalidate an L1D cacheline */
+#define ANDES_L1D_CCTL_VA_WB 0x1 /* Write-back an L1D cacheline */
+#define ANDES_L1D_CCTL_VA_WBINVAL 0x2 /* Flush an L1D cacheline */
+#define ANDES_L1D_CCTL_WBINVAL_ALL 0x6 /* Flush the entire L1D cache */
+
+/* LLC registers */
+#define ANDES_LLC_REG_CFG_OFFSET 0x0
+#define ANDES_LLC_REG_CTRL_OFFSET 0x8
+#define ANDES_LLC_REG_ASYNC_ERR_OFFSET 0x30
+#define ANDES_LLC_REG_ERR_OFFSET 0x38
+#define ANDES_LLC_REG_CCTL_CMD_OFFSET_C0 0x40
+#define ANDES_LLC_REG_CCTL_ACC_OFFSET_C0 0x48
+#define ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0 0x80
+
+/* LLC CCTL status encoding */
+#define ANDES_LLC_CCTL_STATUS_IDLE 0x0
+#define ANDES_LLC_CCTL_STATUS_RUNNING 0x1
+#define ANDES_LLC_CCTL_STATUS_ILLEGAL 0x2
+
+/* LLC CCTL status core 0 mask */
+#define ANDES_LLC_CCTL_STATUS_MASK_C0 GENMASK(3, 0)
+
+/* LLC operation encoding */
+#define ANDES_LLC_CCTL_PA_INVAL 0x8 /* Invalidate an LLC cacheline */
+#define ANDES_LLC_CCTL_PA_WB 0x9 /* Write-back an LLC cacheline */
+#define ANDES_LLC_CCTL_PA_WBINVAL 0xa /* Flush an LLC cacheline */
+#define ANDES_LLC_CCTL_WBINVAL_ALL 0x12 /* Flush the entire LLC cache */
+
+/* LLC CCTL registers and fields by core */
+#define ANDES_LLC_REG_PER_CORE_OFFSET 0x10
+#define ANDES_CCTL_LLC_STATUS_PER_CORE_OFFSET 0x4
+
+#define ANDES_LLC_REG_CCTL_CMD_OFFSET_BY_CORE(n) \
+ (ANDES_LLC_REG_CCTL_CMD_OFFSET_C0 + ((n) * ANDES_LLC_REG_PER_CORE_OFFSET))
+#define ANDES_LLC_REG_CCTL_ACC_OFFSET_BY_CORE(n) \
+ (ANDES_LLC_REG_CCTL_ACC_OFFSET_C0 + ((n) * ANDES_LLC_REG_PER_CORE_OFFSET))
+#define ANDES_LLC_CCTL_STATUS_MASK_BY_CORE(n) \
+ (ANDES_LLC_CCTL_STATUS_MASK_C0 << ((n) * ANDES_CCTL_LLC_STATUS_PER_CORE_OFFSET))
+
+#define ANDES_CACHE_LINE_SIZE 64
+
+struct andes_priv {
+ void __iomem *llc_base;
+ u32 andes_cache_line_size;
+};
+
+static struct andes_priv andes_priv;
+
+/* LLC operations */
+static inline uint32_t andes_cpu_llc_get_cctl_status(void)
+{
+ return readl(andes_priv.llc_base + ANDES_LLC_REG_CCTL_STATUS_OFFSET_C0);
+}
+
+static void andes_cpu_cache_operation(unsigned long start, unsigned long end,
+ unsigned int l1_op, unsigned int llc_op)
+{
+ unsigned long line_size = andes_priv.andes_cache_line_size;
+ void __iomem *base = andes_priv.llc_base;
+ int mhartid = smp_processor_id();
+ unsigned long pa;
+
+ while (end > start) {
+ csr_write(CSR_UCCTLBEGINADDR, start);
+ csr_write(CSR_UCCTLCOMMAND, l1_op);
+
+ pa = virt_to_phys((void *)start);
+ writel(pa, base + ANDES_LLC_REG_CCTL_ACC_OFFSET_BY_CORE(mhartid));
+ writel(llc_op, base + ANDES_LLC_REG_CCTL_CMD_OFFSET_BY_CORE(mhartid));
+ while ((andes_cpu_llc_get_cctl_status() &
+ ANDES_LLC_CCTL_STATUS_MASK_BY_CORE(mhartid)) !=
+ ANDES_LLC_CCTL_STATUS_IDLE)
+ ;
+
+ start += line_size;
+ }
+}
+
+/* Write-back L1 and LLC entry */
+static inline void andes_cpu_dcache_wb_range(unsigned long start, unsigned long end)
+{
+ andes_cpu_cache_operation(start, end, ANDES_L1D_CCTL_VA_WB,
+ ANDES_LLC_CCTL_PA_WB);
+}
+
+/* Invalidate the L1 and LLC entry */
+static inline void andes_cpu_dcache_inval_range(unsigned long start, unsigned long end)
+{
+ andes_cpu_cache_operation(start, end, ANDES_L1D_CCTL_VA_INVAL,
+ ANDES_LLC_CCTL_PA_INVAL);
+}
+
+static void andes_dma_cache_inv(phys_addr_t paddr, size_t size)
+{
+ unsigned long start = (unsigned long)phys_to_virt(paddr);
+ unsigned long end = start + size;
+ unsigned long line_size;
+ unsigned long flags;
+
+ if (unlikely(start == end))
+ return;
+
+ line_size = andes_priv.andes_cache_line_size;
+
+ start = start & (~(line_size - 1));
+ end = ((end + line_size - 1) & (~(line_size - 1)));
+
+ local_irq_save(flags);
+
+ andes_cpu_dcache_inval_range(start, end);
+
+ local_irq_restore(flags);
+}
+
+static void andes_dma_cache_wback(phys_addr_t paddr, size_t size)
+{
+ unsigned long start = (unsigned long)phys_to_virt(paddr);
+ unsigned long end = start + size;
+ unsigned long line_size;
+ unsigned long flags;
+
+ if (unlikely(start == end))
+ return;
+
+ line_size = andes_priv.andes_cache_line_size;
+ start = start & (~(line_size - 1));
+ end = ((end + line_size - 1) & (~(line_size - 1)));
+ local_irq_save(flags);
+ andes_cpu_dcache_wb_range(start, end);
+ local_irq_restore(flags);
+}
+
+static void andes_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
+{
+ andes_dma_cache_wback(paddr, size);
+ andes_dma_cache_inv(paddr, size);
+}
+
+static int andes_get_llc_line_size(struct device_node *np)
+{
+ int ret;
+
+ ret = of_property_read_u32(np, "cache-line-size", &andes_priv.andes_cache_line_size);
+ if (ret) {
+ pr_err("Failed to get cache-line-size, defaulting to 64 bytes\n");
+ return ret;
+ }
+
+ if (andes_priv.andes_cache_line_size != ANDES_CACHE_LINE_SIZE) {
+ pr_err("Expected cache-line-size to be 64 bytes (found:%u)\n",
+ andes_priv.andes_cache_line_size);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static const struct riscv_nonstd_cache_ops andes_cmo_ops __initconst = {
+ .wback = &andes_dma_cache_wback,
+ .inv = &andes_dma_cache_inv,
+ .wback_inv = &andes_dma_cache_wback_inv,
+};
+
+static const struct of_device_id andes_cache_ids[] = {
+ { .compatible = "andestech,llcache" },
+ { /* sentinel */ }
+};
+
+static int __init andes_cache_init(void)
+{
+ struct resource res;
+ int ret;
+
+ struct device_node *np __free(device_node) =
+ of_find_matching_node(NULL, andes_cache_ids);
+ if (!of_device_is_available(np))
+ return -ENODEV;
+
+ ret = of_address_to_resource(np, 0, &res);
+ if (ret)
+ return ret;
+
+ /*
+ * If IOCP is present on the Andes AX45MP core riscv_cbom_block_size
+ * will be 0 for sure, so we can definitely rely on it. If
+ * riscv_cbom_block_size = 0 we don't need to handle CMO using SW any
+ * more so we just return success here and only if its being set we
+ * continue further in the probe path.
+ */
+ if (!riscv_cbom_block_size)
+ return 0;
+
+ andes_priv.llc_base = ioremap(res.start, resource_size(&res));
+ if (!andes_priv.llc_base)
+ return -ENOMEM;
+
+ ret = andes_get_llc_line_size(np);
+ if (ret) {
+ iounmap(andes_priv.llc_base);
+ return ret;
+ }
+
+ riscv_noncoherent_register_cache_ops(&andes_cmo_ops);
+
+ return 0;
+}
+early_initcall(andes_cache_init);
diff --git a/drivers/cache/ax45mp_cache.c b/drivers/cache/ax45mp_cache.c
deleted file mode 100644
index 934c5087ec2b..000000000000
--- a/drivers/cache/ax45mp_cache.c
+++ /dev/null
@@ -1,217 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-/*
- * non-coherent cache functions for Andes AX45MP
- *
- * Copyright (C) 2023 Renesas Electronics Corp.
- */
-
-#include <linux/cacheflush.h>
-#include <linux/cacheinfo.h>
-#include <linux/dma-direction.h>
-#include <linux/of_address.h>
-#include <linux/of_platform.h>
-
-#include <asm/dma-noncoherent.h>
-
-/* L2 cache registers */
-#define AX45MP_L2C_REG_CTL_OFFSET 0x8
-
-#define AX45MP_L2C_REG_C0_CMD_OFFSET 0x40
-#define AX45MP_L2C_REG_C0_ACC_OFFSET 0x48
-#define AX45MP_L2C_REG_STATUS_OFFSET 0x80
-
-/* D-cache operation */
-#define AX45MP_CCTL_L1D_VA_INVAL 0 /* Invalidate an L1 cache entry */
-#define AX45MP_CCTL_L1D_VA_WB 1 /* Write-back an L1 cache entry */
-
-/* L2 CCTL status */
-#define AX45MP_CCTL_L2_STATUS_IDLE 0
-
-/* L2 CCTL status cores mask */
-#define AX45MP_CCTL_L2_STATUS_C0_MASK 0xf
-
-/* L2 cache operation */
-#define AX45MP_CCTL_L2_PA_INVAL 0x8 /* Invalidate an L2 cache entry */
-#define AX45MP_CCTL_L2_PA_WB 0x9 /* Write-back an L2 cache entry */
-
-#define AX45MP_L2C_REG_PER_CORE_OFFSET 0x10
-#define AX45MP_CCTL_L2_STATUS_PER_CORE_OFFSET 4
-
-#define AX45MP_L2C_REG_CN_CMD_OFFSET(n) \
- (AX45MP_L2C_REG_C0_CMD_OFFSET + ((n) * AX45MP_L2C_REG_PER_CORE_OFFSET))
-#define AX45MP_L2C_REG_CN_ACC_OFFSET(n) \
- (AX45MP_L2C_REG_C0_ACC_OFFSET + ((n) * AX45MP_L2C_REG_PER_CORE_OFFSET))
-#define AX45MP_CCTL_L2_STATUS_CN_MASK(n) \
- (AX45MP_CCTL_L2_STATUS_C0_MASK << ((n) * AX45MP_CCTL_L2_STATUS_PER_CORE_OFFSET))
-
-#define AX45MP_CCTL_REG_UCCTLBEGINADDR_NUM 0x80b
-#define AX45MP_CCTL_REG_UCCTLCOMMAND_NUM 0x80c
-
-#define AX45MP_CACHE_LINE_SIZE 64
-
-struct ax45mp_priv {
- void __iomem *l2c_base;
- u32 ax45mp_cache_line_size;
-};
-
-static struct ax45mp_priv ax45mp_priv;
-
-/* L2 Cache operations */
-static inline uint32_t ax45mp_cpu_l2c_get_cctl_status(void)
-{
- return readl(ax45mp_priv.l2c_base + AX45MP_L2C_REG_STATUS_OFFSET);
-}
-
-static void ax45mp_cpu_cache_operation(unsigned long start, unsigned long end,
- unsigned int l1_op, unsigned int l2_op)
-{
- unsigned long line_size = ax45mp_priv.ax45mp_cache_line_size;
- void __iomem *base = ax45mp_priv.l2c_base;
- int mhartid = smp_processor_id();
- unsigned long pa;
-
- while (end > start) {
- csr_write(AX45MP_CCTL_REG_UCCTLBEGINADDR_NUM, start);
- csr_write(AX45MP_CCTL_REG_UCCTLCOMMAND_NUM, l1_op);
-
- pa = virt_to_phys((void *)start);
- writel(pa, base + AX45MP_L2C_REG_CN_ACC_OFFSET(mhartid));
- writel(l2_op, base + AX45MP_L2C_REG_CN_CMD_OFFSET(mhartid));
- while ((ax45mp_cpu_l2c_get_cctl_status() &
- AX45MP_CCTL_L2_STATUS_CN_MASK(mhartid)) !=
- AX45MP_CCTL_L2_STATUS_IDLE)
- ;
-
- start += line_size;
- }
-}
-
-/* Write-back L1 and L2 cache entry */
-static inline void ax45mp_cpu_dcache_wb_range(unsigned long start, unsigned long end)
-{
- ax45mp_cpu_cache_operation(start, end, AX45MP_CCTL_L1D_VA_WB,
- AX45MP_CCTL_L2_PA_WB);
-}
-
-/* Invalidate the L1 and L2 cache entry */
-static inline void ax45mp_cpu_dcache_inval_range(unsigned long start, unsigned long end)
-{
- ax45mp_cpu_cache_operation(start, end, AX45MP_CCTL_L1D_VA_INVAL,
- AX45MP_CCTL_L2_PA_INVAL);
-}
-
-static void ax45mp_dma_cache_inv(phys_addr_t paddr, size_t size)
-{
- unsigned long start = (unsigned long)phys_to_virt(paddr);
- unsigned long end = start + size;
- unsigned long line_size;
- unsigned long flags;
-
- if (unlikely(start == end))
- return;
-
- line_size = ax45mp_priv.ax45mp_cache_line_size;
-
- start = start & (~(line_size - 1));
- end = ((end + line_size - 1) & (~(line_size - 1)));
-
- local_irq_save(flags);
-
- ax45mp_cpu_dcache_inval_range(start, end);
-
- local_irq_restore(flags);
-}
-
-static void ax45mp_dma_cache_wback(phys_addr_t paddr, size_t size)
-{
- unsigned long start = (unsigned long)phys_to_virt(paddr);
- unsigned long end = start + size;
- unsigned long line_size;
- unsigned long flags;
-
- if (unlikely(start == end))
- return;
-
- line_size = ax45mp_priv.ax45mp_cache_line_size;
- start = start & (~(line_size - 1));
- end = ((end + line_size - 1) & (~(line_size - 1)));
- local_irq_save(flags);
- ax45mp_cpu_dcache_wb_range(start, end);
- local_irq_restore(flags);
-}
-
-static void ax45mp_dma_cache_wback_inv(phys_addr_t paddr, size_t size)
-{
- ax45mp_dma_cache_wback(paddr, size);
- ax45mp_dma_cache_inv(paddr, size);
-}
-
-static int ax45mp_get_l2_line_size(struct device_node *np)
-{
- int ret;
-
- ret = of_property_read_u32(np, "cache-line-size", &ax45mp_priv.ax45mp_cache_line_size);
- if (ret) {
- pr_err("Failed to get cache-line-size, defaulting to 64 bytes\n");
- return ret;
- }
-
- if (ax45mp_priv.ax45mp_cache_line_size != AX45MP_CACHE_LINE_SIZE) {
- pr_err("Expected cache-line-size to be 64 bytes (found:%u)\n",
- ax45mp_priv.ax45mp_cache_line_size);
- return -EINVAL;
- }
-
- return 0;
-}
-
-static const struct riscv_nonstd_cache_ops ax45mp_cmo_ops __initdata = {
- .wback = &ax45mp_dma_cache_wback,
- .inv = &ax45mp_dma_cache_inv,
- .wback_inv = &ax45mp_dma_cache_wback_inv,
-};
-
-static const struct of_device_id ax45mp_cache_ids[] = {
- { .compatible = "andestech,ax45mp-cache" },
- { /* sentinel */ }
-};
-
-static int __init ax45mp_cache_init(void)
-{
- struct resource res;
- int ret;
-
- struct device_node *np __free(device_node) =
- of_find_matching_node(NULL, ax45mp_cache_ids);
- if (!of_device_is_available(np))
- return -ENODEV;
-
- ret = of_address_to_resource(np, 0, &res);
- if (ret)
- return ret;
-
- /*
- * If IOCP is present on the Andes AX45MP core riscv_cbom_block_size
- * will be 0 for sure, so we can definitely rely on it. If
- * riscv_cbom_block_size = 0 we don't need to handle CMO using SW any
- * more so we just return success here and only if its being set we
- * continue further in the probe path.
- */
- if (!riscv_cbom_block_size)
- return 0;
-
- ax45mp_priv.l2c_base = ioremap(res.start, resource_size(&res));
- if (!ax45mp_priv.l2c_base)
- return -ENOMEM;
-
- ret = ax45mp_get_l2_line_size(np);
- if (ret) {
- iounmap(ax45mp_priv.l2c_base);
- return ret;
- }
-
- riscv_noncoherent_register_cache_ops(&ax45mp_cmo_ops);
-
- return 0;
-}
-early_initcall(ax45mp_cache_init);
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 1e50dc7c31cd..e0319c8236ee 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -447,7 +447,7 @@ config ARCH_R9A07G043
depends on !RISCV_ISA_ZICBOM
depends on RISCV_SBI
select ARCH_RZG2L
- select AX45MP_L2_CACHE
+ select ANDES_CACHE
select CACHEMAINT_FOR_DMA
select DMA_GLOBAL_POOL
select ERRATA_ANDES
diff --git a/include/linux/soc/andes/csr.h b/include/linux/soc/andes/csr.h
new file mode 100644
index 000000000000..3214b4b08a46
--- /dev/null
+++ b/include/linux/soc/andes/csr.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2026 Andes Technology Corporation.
+ */
+#ifndef __LINUX_SOC_ANDES_CSR_H
+#define __LINUX_SOC_ANDES_CSR_H
+
+/* User mode control registers */
+#define CSR_UCCTLBEGINADDR 0x80b
+#define CSR_UCCTLCOMMAND 0x80c
+
+#endif /* !__LINUX_SOC_ANDES_CSR_H */
--
2.34.1
^ permalink raw reply related
* [PATCH 0/7] refactor Andes cache driver for generic platform support
From: Hui Min Mina Chou @ 2026-03-30 10:27 UTC (permalink / raw)
To: pjw, palmer, aou, alex, geert+renesas, prabhakar.mahadev-lad.rj,
magnus.damm, ben717, robh, krzk+dt, conor+dt, jonathan.cameron,
devicetree, linux-riscv, linux-kernel, linux-renesas-soc
Cc: tim609, alex749, az70021, Hui Min Mina Chou
This series refactors the Andes cache driver from an AX45MP-specific
implementation to a generic Last Level Cache (LLC) driver that supports
a broader range of Andes CPU cores.
The main motivation is to decouple the driver from AX45MP-specific
naming and assumptions, making it easier to support future Andes
platforms without duplicating code.
Changes in this series:
- Refactor the ax45mp_cache driver into a generic andes_llcache driver,
introducing support for multiple Andes CPU cores and updating the
compatible strings accordingly
- Improve initialization by centralizing cache operations
- Improve LLC operation performance by switching to relaxed I/O
accessors and eliminating unnecessary fence instructions on I/O
memory, leveraging the platform's point-to-point strongly ordered
channel guarantee. Also fix hart ID mapping to use
cpuid_to_hartid_map() for correct behavior in AMP setups
- Centralize cache operations and adopt native WBINVAL support,
simplifying the cache flush/invalidate path
- Rename DT binding schema from andestech,ax45mp-cache to
andestech,llcache and update all compatible strings in the RISC-V DTS
files accordingly
- Add MAINTAINERS entry for the Andes cache driver
Hui Min Mina Chou (7):
cache: ax45mp_cache: refactor cache driver for generic Andes platform
support
cache: andes_llcache: refactor initialization and cache operations
cache: andes_llcache: improve performance of LLC operation
cache: andes_llcache: centralize cache ops and use native WBINVAL
dt-bindings: cache: ax45mp-cache: rename ax45mp-cache to llcache
dts: riscv: update cache compatible strings to LLC
MAINTAINERS: Add maintainers for Andes cache driver
...ache.yaml => andestech,andes-llcache.yaml} | 20 +-
MAINTAINERS | 8 +
arch/riscv/Kconfig.errata | 2 +-
arch/riscv/boot/dts/andes/qilai.dtsi | 4 +-
arch/riscv/boot/dts/renesas/r9a07g043f.dtsi | 2 +-
drivers/cache/Kconfig | 6 +-
drivers/cache/Makefile | 2 +-
drivers/cache/andes_llcache.c | 215 +++++++++++++++++
drivers/cache/ax45mp_cache.c | 217 ------------------
drivers/soc/renesas/Kconfig | 2 +-
include/linux/soc/andes/csr.h | 12 +
11 files changed, 254 insertions(+), 236 deletions(-)
rename Documentation/devicetree/bindings/cache/{andestech,ax45mp-cache.yaml => andestech,andes-llcache.yaml} (76%)
create mode 100644 drivers/cache/andes_llcache.c
delete mode 100644 drivers/cache/ax45mp_cache.c
create mode 100644 include/linux/soc/andes/csr.h
--
2.34.1
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: clock: amlogic: Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
From: Jian Hu @ 2026-03-30 10:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Jerome Brunet, Neil Armstrong, Kevin Hilman, Martin Blumenstingl,
Stephen Boyd, Michael Turquette, robh+dt, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Ronald Claveau, devicetree,
linux-clk, linux-amlogic, linux-kernel, linux-arm-kernel,
Ferass El Hafidi
In-Reply-To: <20260327-rough-spry-hyrax-8236de@quoll>
On 3/27/2026 3:23 PM, Krzysztof Kozlowski wrote:
> [ EXTERNAL EMAIL ]
>
> On Thu, Mar 26, 2026 at 05:26:43PM +0800, Jian Hu wrote:
>> Fix redundant hyphen in "amlogic,t7-gp1--pll" string.
>>
>> Fixes: 5437753728ac ("dt-bindings: clock: add Amlogic T7 PLL clock controller")
> Please run scripts/checkpatch.pl on the patches and fix reported
> warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
> patches and (probably) fix more warnings. Some warnings can be ignored,
> especially from --strict run, but the code here looks like it needs a
> fix. Feel free to get in touch if the warning is not clear.
Thanks for your review.
This series is based on the clk-next branch (version v7.0-rc1).
Here are the check results without --strict:
$ ./scripts/checkpatch.pl
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch
total: 0 errors, 0 warnings, 8 lines checked
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch
total: 0 errors, 0 warnings, 46 lines checked
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl
0003-arm64-dts-amlogic-t7-Add-clock-controller-nodes.patch
total: 0 errors, 0 warnings, 149 lines checked
Here are the check results with --strict (I had also checked them with
this script before submitting these patches):
$ ./scripts/checkpatch.pl --strict
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch
total: 0 errors, 0 warnings, 0 checks, 8 lines checked
0001-dt-bindings-clock-amlogic-Fix-redundant-hyphen-in-am.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl --strict
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch
total: 0 errors, 0 warnings, 0 checks, 46 lines checked
0002-dt-bindings-clock-amlogic-t7-Add-missing-mpll3-paren.patch has no
obvious style problems and is ready for submission.
$ ./scripts/checkpatch.pl --strict
0003-arm64-dts-amlogic-t7-Add-clock-controller-nodes.patch
total: 0 errors, 0 warnings, 0 checks, 149 lines checked
0003-arm64-dts-amlogic-t7-Add-clock-controller-nodes.patch has no
obvious style problems and is ready for submission.
I have also run the script on the latest v7.0-rc5, and no warnings are
reported.
Could you tell me which version of the checkpatch script you are using?
If you are using a locally modified script, kindly let me know which
warnings I need to fix.
>> Signed-off-by: Ronald Claveau <linux-kernel-dev@aliel.fr>
>> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH v6 3/3] arm64: dts: qcom: Add Samsung Galaxy Book4 Edge DTS/DTSI
From: Konrad Dybcio @ 2026-03-30 10:41 UTC (permalink / raw)
To: Maxim Storetvedt, andersson, robh, krzk+dt, conor+dt
Cc: marcus, marijn.suijten, linux-arm-msm, devicetree, linux-kernel,
abel.vesa, abel.vesa, johan, konradybcio, kirill
In-Reply-To: <f6323f22-27c8-4ae5-83d3-59831b62b5da@cern.ch>
On 3/26/26 7:30 PM, Maxim Storetvedt wrote:
>
>
> On 3/26/26 12:33, Konrad Dybcio wrote:
>> On 3/25/26 7:30 PM, Maxim Storetvedt wrote:
>>>
>>>
>>> On 3/23/26 13:17, Konrad Dybcio wrote:
>>>> On 3/22/26 5:03 PM, Maxim Storetvedt wrote:
>>>>> Adds devicetrees for the 14-inch and 16-inch SKUs of the Samsung Galaxy Book4 Edge.
>>>>>
>>>>> These use a common dtsi derived from nodes that were able to work on Linux
>>>>> from the initial Galaxy Book4 Edge DTS by Marcus:
>>>>>
>>>>> Link: https://lore.kernel.org/all/p3mhtj2rp6y2ezuwpd2gu7dwx5cbckfu4s4pazcudi4j2wogtr@4yecb2bkeyms/
>>>>>
>>>>> combined with the ongoing patch for the Honor Magicbook Art 14, and its downstream by
>>>>> Valentin Manea, which shares device similarities:
>>>>
>>>> [...]
>>>>
>>>>> +&i2c8 {
>>>>> + clock-frequency = <400000>;
>>>>> +
>>>>> + status = "okay";
>>>>> +
>>>>> + touchscreen@5d {
>>>>> + compatible = "hid-over-i2c";
>>>>> + reg = <0x5d>;
>>>>> +
>>>>> + hid-descr-addr = <0x1>;
>>>>> + interrupts-extended = <&tlmm 34 IRQ_TYPE_LEVEL_LOW>;
>>>>> +
>>>>> + vdd-supply = <&vreg_misc_3p3>;
>>>>> + /* Lower power supply is not enoug to work. */
>>>>> + // vddl-supply = <&vreg_l15b_1p8>;
>>>>
>>>> How should we interpret that?
>>>>
>>>
>>> This was in the original patch, but using that same regulator appears to
>>> be enough to also get touchscreen working on the 16" book4e. That said,
>>> it still does not work on the 14". Something to revisit later...
>>>
>>>>
>>>> [...]
>>>>
>>>>> +&panel {
>>>>> + compatible = "samsung,atna40cu07", "samsung,atna33xc20";
>>>>
>>>> I think it'd make sense to move the compatible from 'common' to the
>>>> 16in DTS then too
>>>>
>>>>> + enable-gpios = <&pmc8380_3_gpios 4 GPIO_ACTIVE_HIGH>;
>>>>
>>>> this matches the common definition
>>>>
>>>>> + power-supply = <&vreg_edp_3p3>;
>>>>
>>>> ditto
>>>>
>>>>> + no-hpd;
>>>>
>>>> really??
>>>>
>>> One less thing to debug while previously attempting to work around the
>>> "illegal link rate" error, which turned out to be related to eDP 1.4
>>> (similar to the sp11). I've kept it as-is in case other SKUs attempt
>>> booting from this dts, such as the x1e80100 16" (as it might be getting
>>> a black screen using the current x1e84100 16" dts, though this is not
>>> fully tested).
>>
>> So do the 80100 and 84100-equipped SKUs of the laptop come with different
>> displays?
>>
>> Konrad
>
> So far assumed both 16" variants to be fairly similar, though one
> valiant 16" 80100 user over in the debug thread did try to boot via the
> 84100 dts, with no success. Instead having the screen go dark after the
> first post-tux kernel prints.
Does switching to the generic edp-panel compatible (which will parse the
EDID and try not to be overly smart about it) help here?
> This was strapped together via WSL though, so could be there was
> something else at fault, but strange it didn't at least fall back to a
> visible initramfs shell.
You mean the kernel had been compiled via WSL? That shouldn't be a problem..
Konrad
^ permalink raw reply
* Re: [PATCH] dt-bindings: phy: qcom,snps-eusb2: Document the Eliza Synopsys eUSB2 PHY
From: Konrad Dybcio @ 2026-03-30 10:40 UTC (permalink / raw)
To: Abel Vesa, Vinod Koul, Neil Armstrong, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Abel Vesa
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel
In-Reply-To: <20260327-eliza-bindings-phy-eusb2-v1-1-1f8a9ad6a033@oss.qualcomm.com>
On 3/27/26 3:14 PM, Abel Vesa wrote:
> The Synopsys eUSB2 PHY found on the Eliza SoC is fully compatible with the
> one found the SM8550.
>
> So document it by adding the compatible to the list that has the SM8550
> one as fallback.
>
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH v2] dts: riscv: spacemit: k3: add P1 PMIC regulator tree
From: Yixun Lan @ 2026-03-30 10:40 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Paul Walmsley,
Palmer Dabbelt, Albert Ou, Alexandre Ghiti, Yixun Lan
Cc: devicetree, linux-riscv, spacemit, linux-kernel
In-Reply-To: <20260327-02-k3-i2c-v2-1-9c6b374470c6@kernel.org>
On Fri, 27 Mar 2026 11:51:18 +0000, Yixun Lan wrote:
> Add the P1 PMIC's regulator topology tree for pico-itx board.
>
>
Applied, thanks!
[1/1] dts: riscv: spacemit: k3: add P1 PMIC regulator tree
https://github.com/spacemit-com/linux/commit/af62a095eb0c3359d477b55ef72d2afd94c83c8f
Best regards,
--
Yixun Lan <dlan@kernel.org>
^ permalink raw reply
* Re: [PATCH v5 1/2] dt-bindings: phy: qcom: Add CSI2 C-PHY/DPHY schema
From: Vladimir Zapolskiy @ 2026-03-30 10:39 UTC (permalink / raw)
To: Bryan O'Donoghue, Neil Armstrong, Konrad Dybcio, Vinod Koul,
Kishon Vijay Abraham I, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Bryan O'Donoghue, linux-arm-msm, linux-phy, linux-media,
devicetree, linux-kernel
In-Reply-To: <456ded59-d13e-4b61-975b-97ca48b5e771@linaro.org>
On 3/30/26 12:02, Bryan O'Donoghue wrote:
> On 30/03/2026 08:49, Neil Armstrong wrote:
>> On 3/27/26 18:42, Bryan O'Donoghue wrote:
>>> On 27/03/2026 15:28, Neil Armstrong wrote:
>>>>> To be frankly honest you can make an argument for it either way.
>>>>> However my honestly held position is analysing other upstream
>>>>> implementations connecting to the PHY means we can't make the PHY
>>>>> device a drivers/phy device - it would have to be a V4L2 device and
>>>>> then for me the question is why is that even required ?
>>>>
>>>> This is plain wrong, DT definition is different from software
>>>> implementation, you can do whatever you want if you describe HW
>>>> accurately.
>>>
>>> I'm not sure what point it is you are trying to make here. Are you
>>> trying to say drivers/phy is OK with you but you want an endpoint ? If
>>> so, please just say so.
>>
>> I'm against using the "phys = <>" property in the CAMSS to reference the
>> PHYs, a "PHY" in the classic terminology is tied to a single consumer,
>> and if it can be shared to multiple consumer you must model a mux or
>> whatever in the middle.
>
> The CSIPHY-to-CSID routing is runtime-configurable and is already
> managed by the media controller framework.
>
> DT describes static hardware connections. The dynamic mux is a software
> concern, not a hardware description concern.
>
>
>> The PHY API as an internal software implementation is probably fine,
>> even if it makes implementation of split mode much much harder and
>> doesn't really solve anything, you can just call init()/poweron()/
>> poweroff()/exit() directly from the CSIPHY media callbacks.
>
> Great.
>
>>> I can see an argument for that hence my response to Konrad, I just
>>> don't see why its a Qualcomm specific argument and of course
>>> understood stuff bubbles up in review, we have a public debate and
>>> come to a consensus - that's a good thing.
>>>
>>> However, I'd want wider buy-in and understanding that endpoints in the
>>> PHYs is a more accurate description of the data-flow.
>>
>> It is, and it was designed for that, and extensively used in the media
>> DT representation, so I wonder here you would not use it...
>> In an ideal world, you would add nodes for each CAMSS hw elements and
>> adds port/endpoints links between all nodes to describe the data graph,
>> this would be used to construct the media controller graph, and make it
>> much easier supporting new hardware.
>
> Yes but be pragmatic Neil. The first step in making the monolith into
> sub-nodes is the CSIPHY.
>
> Once the CSIPHY is in, we can follow on with adding new nodes that way
> IPE, BPS, ICP, JPEG whatever and also work on implementing the old stuff
> in that new way.
>
>
>>
>>>
>>> We've been applying DT bindings aplenty without that so far. So we
>>> would establish new CSI2 PHY bindings should represent the sensor
>>> endpoints.
>>
>> We've been using a dummy representation of CAMM in a single node with
>> only endpoints connecting to the sensors and hiding all the hardware
>> layout in code, it doesn't scale and makes supporting new HW hard.
>> I mean this is common sense, why would we continue to stick to the
>> current CAMSS bindings ???
>
> We _won't_ I just don't support a big bang integration. Progressive
> changes over a longer timeline make the transition manageable, without
> accepting endless sub-standard stuff in the meantime or holding up all
> new SoC submission unless/until.
>
> I mean there is a CAMSS meeting which I've been running for nearly a
> year now that both you and Vlad are invited to where we have been
> discussing this for months...
The established process of Linux kernel development is based on email
discussions, the sent changes including CSIPHY dt bindings were plainly
ignored by the maintainer, because it's a NIH material or whatever.
There was a chance to discuss CSIPHY dt bindings changes one year ago,
now it might be not a coincidence that eventually after the series of
updates the new CSIPHY dt bindings will be very close to the once
displayed ones, it took a year, but still this is a good progress IMO.
--
Best wishes,
Vladimir
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox