* RE: [PATCH v7 2/2] iio: dac: ad5706r: Add support for AD5706R DAC
From: Torreno, Alexis Czezar @ 2026-04-13 7:15 UTC (permalink / raw)
To: David Lechner, Lars-Peter Clausen, Hennerich, Michael,
Jonathan Cameron, Sa, Nuno, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-iio@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, Andy Shevchenko
In-Reply-To: <cdfb9deb-2439-413b-8c20-3c6ad6a81ce3@baylibre.com>
> > +static int ad5706r_regmap_write(void *context, const void *data,
> > +size_t count) {
> > + struct ad5706r_state *st = context;
> > + unsigned int num_bytes, val;
> > + u16 reg;
> > +
> > + if (count != 4)
> > + return -EINVAL;
> > +
> > + reg = get_unaligned_be16(data);
> > + num_bytes = ad5706r_reg_len(reg);
> > +
> > + struct spi_transfer xfer = {
> > + .tx_buf = st->tx_buf,
> > + .len = num_bytes + 2,
> > + };
> > +
> > + val = get_unaligned_be32(data);
> > + put_unaligned_be32(val, &st->tx_buf[0]);
>
> Can't we just do memcpy() instead of swapping the byte order twice?
This was memcpy before, was changed to this for consistency as per Andy's
suggestion. It was during v5.
Removal of this plus the other mem* commands allowed removal of string.h
in the headers.
>
> > +
> > + /* For single byte, copy the data to the correct position */
> > + if (num_bytes == AD5706R_SINGLE_BYTE_LEN)
> > + st->tx_buf[2] = st->tx_buf[3];
> > +
> > + return spi_sync_transfer(st->spi, &xfer, 1);
>
> There isn't any special paramters in the xfer struct, so spi_write() should work
> here and save a bit of code.
>
> return spi_write(st->spi, data, num_bytes);
Back in v3-v4, Joathan suggested this to be spi_write_then_read() as it was much safer,
but I requested to keep it this way since I would be adding more features to this driver
like changing spi_speeds, which cannot be done if using spi_write_then_read
>
> > +}
> > +
> > +static int ad5706r_regmap_read(void *context, const void *reg_buf,
> > + size_t reg_size, void *val_buf, size_t val_size) {
> > + struct ad5706r_state *st = context;
> > + unsigned int num_bytes;
> > + u16 reg, cmd, val;
> > + int ret;
> > +
> > + if (reg_size != 2 || val_size != 2)
> > + return -EINVAL;
> > +
> > + reg = get_unaligned_be16(reg_buf);
> > + num_bytes = ad5706r_reg_len(reg);
> > +
> > + /* Full duplex, device responds immediately after command */
> > + struct spi_transfer xfer = {
> > + .tx_buf = st->tx_buf,
> > + .rx_buf = st->rx_buf,
> > + .len = 2 + num_bytes,
> > + };
> > +
> > + cmd = AD5706R_RD_MASK | (reg & AD5706R_ADDR_MASK);
> > + put_unaligned_be16(cmd, &st->tx_buf[0]);
> > + put_unaligned_be16(0, &st->tx_buf[2]);
>
> Do we actually need to write 0s while reading?
>
> Usually, we would just do a spi_write_then_read for something like this.
Technically it's a don't care data, zero just makes it cleaner signals during debug
Discussed spi_write_then_read in a comment above
>
> > +
> > + ret = spi_sync_transfer(st->spi, &xfer, 1);
> > + if (ret)
> > + return ret;
> > +
>
>
> > + /* Extract value from response (skip 2-byte command echo) */
> > + if (num_bytes == AD5706R_SINGLE_BYTE_LEN)
> > + val = st->rx_buf[2];
> > + else if (num_bytes == AD5706R_DOUBLE_BYTE_LEN)
> > + val = get_unaligned_be16(&st->rx_buf[2]);
> > + else
> > + return -EINVAL;
> > +
> > + put_unaligned_be16(val, val_buf);
>
> Can't this all be simplified to memcpy(val_buf, &st->rx_buf[2], num_bytes); ?
>
> Or the whole thing simplified to:
>
> return spi_write_then_read(st->spi, reg_buf, 2, val_buf, num_bytes);
>
as discussed above about mem* and spi_write_then_read
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Krzysztof Kozlowski @ 2026-04-13 7:12 UTC (permalink / raw)
To: Akhil R
Cc: Frank.Li, acpica-devel, alexandre.belloni, conor+dt, devicetree,
ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon, linux-i3c,
linux-kernel, linux, miquel.raynal, p.zabel, rafael, robh,
sakari.ailus, wsa+renesas, smangipudi
In-Reply-To: <20260413065747.31834-1-akhilrajeev@nvidia.com>
On 13/04/2026 08:57, Akhil R wrote:
>>> Isn't I3C needed for SPD5118. Otherwise I understand even less from this
>>> rationale - why I3C is being enabled here?
>>>
>>> And before author asks what do I want to here: no, it is author's job to
>>> convince me to accept I3C in defconfig. Not mine.
>>
>> BTW, all this was asked at v1 and author did not improve the commit msg
>> beside giving quite broad/unspecific "Vera".
>
> If I am not wrong, the ask in v1 was to specify the product which this is
> getting used - 'Vera' it is. I do not know why you would think it is
> unspecific.
I already said why. Because I Googled it and Google told me it can be
"architecture". And no, you do not use SPD5118 on architecture.
>
> As Thierry and Guenter mentioned, the lack of policy and 'mix of both' in
> the defconfig makes it quite difficult to understand what could genuinely
> be convincing other than putting down every little detail or do a trial
> and error.
I think the main problem is that people forgot that commits must answer
WHY you are doing this. Now my assumption is that people sending
defconfigs do not understand why they are doing it, therefore they
cannot explain "why" in commit msg.
Look, find me in following nvidia patches any answers to why this change
is needed:
https://lore.kernel.org/all/20260409131340.168556-7-pshete@nvidia.com/
https://lore.kernel.org/all/20240829134252.49661-1-jonathanh@nvidia.com/
https://lore.kernel.org/all/20240509215808.126217-1-bwicaksono@nvidia.com/
I understand that I can clarify what sort of answers to "why?" I expect.
but lack of such clarification is not excuse to not provide ANY
explanation in commit msg.
Basically it is logic like:
"Uh, I don't how to explain this change, why do we need it, why is it
good, why am I doing that...anyway, let's send it!"
Why doing something in the first place if one does not know the reason
behind?
Best regards,
Krzysztof
^ permalink raw reply
* Re: Phandles
From: Kyle Bonnici @ 2026-04-13 7:10 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Herve Codina, devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree@vger.kernel.org
In-Reply-To: <00f0d18e-feba-45cd-af92-f737c9b965ef@kernel.org>
> On 13 Apr 2026, at 08:37, Krzysztof Kozlowski <krzk@kernel.org> wrote:
>
> On 12/04/2026 18:37, Kyle Bonnici wrote:
>>>>> Case 1:
>>>>> / {
>>>>> node1 {
>>>>> pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
>>>>>
>>>>> Here the first cell '1' is not a phandle.
>>>>
>>>> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.
>>>
>>> I think the purpose of 'select: true' is to have the binding always applied:
>>> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15
>>>
>>
>>
>> I’m having trouble finding where the Devicetree Specification (v0.4) mandates that all binding systems must extend dt-schema.
>> Since this requirement isn't explicitly in the spec, it follows that the WARNING_PROPERTY_PHANDLE_CELLS validation belongs in dt-validate rather than within dtc itself.
>
>
> So you want to have a property with values not being phandle? The spec
> defines that properties like "pwm" must contain "value of properties
> with a phandle value type". Therefore what does '1' represents in your
> example?
I am just building and maintaining an LSP to assists Zephyr and Linux developers alike and what is technically
allowed in Zephyr is not allowed in Linux. The issue here is that DTC is warning zephyr users about it.
I also find my self in the wrong to enforce these types for Zephyr dts usage given all documentation I have seen
so far.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH RFC 3/4] clk: qcom: tcsrcc-glymur: Migrate tcsr_pcie_N_clkref_en to clk_ref common helper
From: Qiang Yu @ 2026-04-13 7:06 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Taniya Das, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, johan,
linux-arm-msm, linux-clk, devicetree, linux-kernel
In-Reply-To: <adem2WKh2B-Leivq@baldur>
On Thu, Apr 09, 2026 at 08:19:41AM -0500, Bjorn Andersson wrote:
> On Wed, Apr 01, 2026 at 09:47:38PM -0700, Qiang Yu wrote:
> > On Wed, Apr 01, 2026 at 10:05:12PM +0530, Taniya Das wrote:
> > > On 4/1/2026 12:05 PM, Qiang Yu wrote:
> > > > diff --git a/drivers/clk/qcom/tcsrcc-glymur.c b/drivers/clk/qcom/tcsrcc-glymur.c
> [..]
> > > > +static const char * const tcsr_pcie_4_regulators[] = {
> > > > + "vdda-refgen-0p9",
> > > > + "vdda-refgen-1p2",
> > > > + "vdda-qreftx1-0p9",
> > > > + "vdda-qrefrpt0-0p9",
> > > > + "vdda-qrefrpt1-0p9",
> > > > + "vdda-qrefrpt2-0p9",
> > > > + "vdda-qrefrx2-0p9",
> > > > +};
> > > > +
> > >
> > > TCSR clock refs are just not for PCIe alone, they would have supplies
> > > for all the ref clocks. These supplies can also be shared across other
> > > clock refs. I think it is not the correct way to handle the supplies, as
> > > TCSR does not have the complete supplies map.
> > >
> > We have complete supplies map. You can get it on ipcatlog. Here is example
> > for other instances eg USB and EDP:
> > - Glymur (eDP): CXO PAD -> TX0 -> RPT0 -> RX0 -> eDP
> > - Glymur (USB4_2): CXO PAD -> TX0 -> RPT0 -> RPT1 -> RX1 -> USB4_2
> > - Glymur (USB3): CXO PAD -> TX0 -> RPT3 -> RPT4 -> RX4 -> USB3_SS3
> >
> > I only add supplies for PCIe in this series because USB and EDP vote these
> > LDO in their PHY driver. They can remove them in PHY dts node and add same
> > regulator list here.
> >
>
> The regulators are reference counted. Can't we add the USB and eDP
> handling here as well now, and then after they are voted here we remove
> them from the PHY?
>
For USB, I’m not yet sure which tcsr_*_clkref_en each USB instance in the
QREF diagram is tied to. I need to confirm that mapping first, I'm
checking with Wesley Cheng.
For eDP, there is only one instance, so I can add it.
- Qiang Yu
> Regards,
> Bjorn
>
> > - Qiang Yu
> > >
> > > > +static const struct qcom_clk_ref_desc tcsr_cc_glymur_clk_descs[] = {
> > > > + [TCSR_EDP_CLKREF_EN] = {
> > > > + .name = "tcsr_edp_clkref_en",
> > > > + .offset = 0x60,
> > > > },
> > > > -};
> > > >
> > >
> > >
> > > --
> > > Thanks,
> > > Taniya Das
> > >
^ permalink raw reply
* Re: [PATCH v2 13/13] arm64: defconfig: Enable I3C and SPD5118 hwmon
From: Akhil R @ 2026-04-13 6:57 UTC (permalink / raw)
To: krzk
Cc: Frank.Li, acpica-devel, akhilrajeev, alexandre.belloni, conor+dt,
devicetree, ebiggers, krzk+dt, lenb, linux-acpi, linux-hwmon,
linux-i3c, linux-kernel, linux, miquel.raynal, p.zabel, rafael,
robh, sakari.ailus, wsa+renesas, smangipudi
In-Reply-To: <d62130c6-c503-479d-99d8-b4f0f0582a4b@kernel.org>
On Sun, 12 Apr 2026 15:33:42 +0200, Krzysztof Kozlowski
> On 12/04/2026 15:32, Krzysztof Kozlowski wrote:
>> On 11/04/2026 09:20, Guenter Roeck wrote:
>>> On 4/10/26 22:34, Akhil R wrote:
>>> [ ... ]
>>>>>>> And it
>>>>>>> should bring me clear rule what I can or cannot remove from defconfig,
>>>>>>> if in 2 years I come and start pruning it from symbols.
>>>>
>>>> I am still a little confused on what information would likely accept (and
>>>> keep) these configs in the defconfig. Would updating the commit message
>>>> as below work?
>>>>
>>>> "These configs enable the support for SPD5118 within the
>>>> Small-Outline-Compression-Attached Memory Modules (SOCAMM) LPDDR5X found
>>>> in the NVIDIA Vera CPUs. The Vera CPU uses ACPI and is part of platforms
>>>> such as Vera Rubin."
>>>>
>>>
>>> It is quite interesting that we argue about SPD5118 which is mandatory in
>>> DDR5 systems. At the same time, CONFIG_IGB_HWMON, CONFIG_SENSORS_MACSMC_HWMON,
>>> CONFIG_SENSORS_RASPBERRYPI_HWMON, and CONFIG_RTC_DRV_DS3232_HWMON _are_
>>> enabled in arm64:defconfig. CONFIG_IGB_HWMON is even built-in.
>>
>> Why CONFIG_SENSORS_MACSMC_HWMON is weird? It is part of the soc using
>> the defconfig?
>>
>> The author here has troubles bringing any arguments why his drivers
>> should be defconfig and keeps asking what do I want to hear. If one
>> cannot make an argument why a change is needed, then maybe the change
>> should not be sent?
>>
>> It's the job of the author to convince why the community needs this
>> change, unless it is obvious, ofc.
>>
>>>
>>> It is kind of difficult to understand why those are more important than
>>> the temperature sensor on DDR5 modules (or the temperature sensor on DDR4
>>> modules, for that matter).
>>
>> No one discussed this. I have no clue what is SPD5118 and commit msg did
>> not explain that. Did not even provide accurate user of that.
>>
>>>
>>> I don't know what the policy for defconfig is, but just based on that it does
>>> seem to lack consistency.
>>
>> No wonder... people write poor commits and send that to upstream. And
>> when asked "why do we want this" they got stuck.
>>
>>>
>>> A separate question is if it is time to enable I3C in default configurations.
>>> I'd think so - more and more chip vendors support it, and presumably they would
>>> not invest in it if there was no demand, but that is just my personal opinion.
>>
>> Isn't I3C needed for SPD5118. Otherwise I understand even less from this
>> rationale - why I3C is being enabled here?
>>
>> And before author asks what do I want to here: no, it is author's job to
>> convince me to accept I3C in defconfig. Not mine.
>
> BTW, all this was asked at v1 and author did not improve the commit msg
> beside giving quite broad/unspecific "Vera".
If I am not wrong, the ask in v1 was to specify the product which this is
getting used - 'Vera' it is. I do not know why you would think it is
unspecific.
As Thierry and Guenter mentioned, the lack of policy and 'mix of both' in
the defconfig makes it quite difficult to understand what could genuinely
be convincing other than putting down every little detail or do a trial
and error.
Anyway, I will describe where each config is getting used in the next
revision - hoping that would help.
Regards,
Akhil
^ permalink raw reply
* Re: [PATCH v2 07/10] dt-bindings: timer: renesas,rz-mtu3: document RZ/{T2H,N2H}
From: Krzysztof Kozlowski @ 2026-04-13 6:54 UTC (permalink / raw)
To: Cosmin Tanislav
Cc: Biju Das, Daniel Lezcano, Thomas Gleixner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, Michael Turquette, Stephen Boyd, Lee Jones,
Philipp Zabel, linux-iio, linux-renesas-soc, linux-kernel,
devicetree, linux-clk
In-Reply-To: <20260410163530.383818-8-cosmin-gabriel.tanislav.xa@renesas.com>
On Fri, Apr 10, 2026 at 07:35:27PM +0300, Cosmin Tanislav wrote:
> Compared to the previously supported SoCs, the Renesas RZ/T2H and RZ/N2H
> SoCs do not have a reset line.
>
> Add support for them by moving the required reset into a conditional
> matching all compatibles for the existing SoCs. Disable the resets for
> RZ/T2H and RZ/N2H.
>
> Document RZ/T2H and RZ/N2H, and use the generic compatible as a
> fallback, as functionality is the same.
>
> Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
> ---
>
> V2:
> * squash "move required resets to conditional" into this
> * disable the resets in the else branch of the condition
>
> .../bindings/timer/renesas,rz-mtu3.yaml | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/2] dt-bindings: display: waveshare,dsp2dpi: describe DSI2LVDS setup
From: Krzysztof Kozlowski @ 2026-04-13 6:51 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, dri-devel,
devicetree, linux-kernel
In-Reply-To: <20260412-ws-lcd-v3-1-db22c2631828@oss.qualcomm.com>
On Sun, Apr 12, 2026 at 08:32:24PM +0300, Dmitry Baryshkov wrote:
> Several the Waveshare DSI LCD panel kits use DSI2LVDS ICN6202 bridge
> together with the LVDS panels. Define new compatible for the on-kit
> bridge setup (it is not itmized and it uses Waveshare prefix since the
> rest of the integration details are not known).
>
> Note: the ICN6202 / ICN6211 bridges are completely handled by the board
> itself, they should not be programmed by the host (which otherwise might
> override correct params), etc. As such, it doesn't make sense to use
> those in the compat strings. I consider those to be an internal detail
> of the setup.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
> ---
> .../devicetree/bindings/display/bridge/waveshare,dsi2dpi.yaml | 9 ++++++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/3] ASoC: renesas: fsi: Fix hang by enabling SPU clock
From: Bui Duc Phuc @ 2026-04-13 6:45 UTC (permalink / raw)
To: Kuninori Morimoto
Cc: broonie, lgirdwood, robh, krzk+dt, conor+dt, geert+renesas,
magnus.damm, perex, tiwai, linux-sound, linux-renesas-soc,
devicetree, linux-kernel
In-Reply-To: <87fr56vu4f.wl-kuninori.morimoto.gx@renesas.com>
Hi Morimoto-san, Geert,
Thanks for the feedback.
To keep things moving, I will send v2 shortly, focusing on the sequence
reordering and SPU Clock control to fix the system hang, which has been
confirmed to work.
Regarding the fsidiv clock provider, I will prepare it as a separate
patch after
confirmation from Geert, and will consider the appropriate approach for its
implementation.
Best regards,
Phuc
On Wed, Apr 8, 2026 at 1:33 PM Kuninori Morimoto
<kuninori.morimoto.gx@renesas.com> wrote:
>
>
> Hi Bui, Geert
>
> > > Hmm... fsi_dai_trigger() seems strange.
> > > It seems (A) stops clock, and (B) sets register after that.
> > > Is this the reason why you get error ? I think (A) and (B) should be
> > > reversed. The balance between SNDRV_PCM_TRIGGER_START, and with
> > > __fsi_suspend() are also not good.
> > > If so, can you use hw_start/stop() ?
> >
> > Thank you for the guidance. After reordering the sequence and moving the
> > SPU power control to fsi_hw_start/shutdown, the system hang is now resolved.
>
> Nice !
>
> > By the way, I’d like to discuss the fsidiv clock handling.
> > In the legacy implementation, it was handled here:
> > https://elixir.bootlin.com/linux/v7.0-rc7/source/drivers/sh/clk/cpg.c.
> > Currently, this has not been ported to the Common Clock Framework (CCF) for
> > R8A7740, and it resides in a different register range from the core CPG.
> > For v2, would you prefer that I implement a small clock provider for
> > fsidiv within
> > the FSI driver, or should it be added under drivers/clk/renesas/?
>
> I think it should be under drivers/clk/renesas, but Geert ?
>
> Thank you for your help !!
>
> Best regards
> ---
> Kuninori Morimoto
^ permalink raw reply
* Re: Phandles
From: Krzysztof Kozlowski @ 2026-04-13 6:37 UTC (permalink / raw)
To: Kyle Bonnici, Herve Codina
Cc: devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree@vger.kernel.org
In-Reply-To: <163D807F-0F83-4282-B182-7A18B124D3E6@hotmail.com>
On 12/04/2026 18:37, Kyle Bonnici wrote:
>>>> Case 1:
>>>> / {
>>>> node1 {
>>>> pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
>>>>
>>>> Here the first cell '1' is not a phandle.
>>>
>>> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.
>>
>> I think the purpose of 'select: true' is to have the binding always applied:
>> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15
>>
>
>
> I’m having trouble finding where the Devicetree Specification (v0.4) mandates that all binding systems must extend dt-schema.
> Since this requirement isn't explicitly in the spec, it follows that the WARNING_PROPERTY_PHANDLE_CELLS validation belongs in dt-validate rather than within dtc itself.
So you want to have a property with values not being phandle? The spec
defines that properties like "pwm" must contain "value of properties
with a phandle value type". Therefore what does '1' represents in your
example?
Best regards,
Krzysztof
^ permalink raw reply
* Re: Phandles
From: Krzysztof Kozlowski @ 2026-04-13 6:33 UTC (permalink / raw)
To: Herve Codina, Kyle Bonnici
Cc: devicetree-compiler@vger.kernel.org, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, devicetree
In-Reply-To: <20260412173916.7a971a45@bootlin.com>
On 12/04/2026 17:40, Herve Codina wrote:
> Hi Kyle,
>
> +Cc Kernel device-tree maintainers
>
> On Sun, 12 Apr 2026 13:51:35 +0000
> Kyle Bonnici <kylebonnici@hotmail.com> wrote:
>
>>> On 12 Apr 2026, at 14:51, Herve Codina <herve.codina@bootlin.com> wrote:
>>>
>>> Hi Kyle,
>>>
>>> On Sat, 11 Apr 2026 18:33:33 +0000
>>> Kyle Bonnici <kylebonnici@hotmail.com> wrote:
>>>
>>>> Hi
>>>>
>>>> I have been looking at the the code for the compiler and I am wondering which specifications marks the below properties MUST BE Nexus Properties hence the validation.
>>>>
>>>> WARNING_PROPERTY_PHANDLE_CELLS(clocks, "clocks", "#clock-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(cooling_device, "cooling-device", "#cooling-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(dmas, "dmas", "#dma-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(hwlocks, "hwlocks", "#hwlock-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(interrupts_extended, "interrupts-extended", "#interrupt-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(io_channels, "io-channels", "#io-channel-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(iommus, "iommus", "#iommu-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(mboxes, "mboxes", "#mbox-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(msi_parent, "msi-parent", "#msi-cells", true);
>>>> WARNING_PROPERTY_PHANDLE_CELLS(mux_controls, "mux-controls", "#mux-control-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(phys, "phys", "#phy-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(power_domains, "power-domains", "#power-domain-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(pwms, "pwms", "#pwm-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(resets, "resets", "#reset-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(sound_dai, "sound-dai", "#sound-dai-cells");
>>>> WARNING_PROPERTY_PHANDLE_CELLS(thermal_sensors, "thermal-sensors", "#thermal-sensor-cells");
>>>
>>> All of those properties are defined as phandles.
>>>
>>> For instance, the 'pwms' property available in a node means the the node is
>>> a pwm consumer. It must follow the pwm consumer binding [1] and so a phandle
>>> is involved.
>>>
>>> This phandle can have arguments and the number of argument is defined by the
>>> #pwm-cells property set in the pwm provider node [2], [3].
>>>
>>> [1] https://elixir.bootlin.com/zephyr/v4.4.0-rc3/source/dts/bindings/pwm/pwm-controller.yaml
>>> [2] https://github.com/zephyrproject-rtos/zephyr/blob/main/dts/bindings/pwm/pwm-controller.yaml
>>> [3] https://elixir.bootlin.com/linux/v7.0-rc7/source/Documentation/devicetree/bindings/pwm/pwm.yaml
>>>
>>>>
>>>>
>>>> These can be found here: https://github.com/dgibson/dtc/blob/main/checks.c#L1498 this is relevant for https://github.com/zephyrproject-rtos/zephyr/issues/107066
>>>
>>> Examples provided in the zephyrproject issue link are, in my opinion, incorrect.
>>>
>>> Case 1:
>>> / {
>>> node1 {
>>> pwms = <1 &pwm0 1 20 PWM_POLARITY_NORMAL>;
>>>
>>> Here the first cell '1' is not a phandle.
>>
>> Here the compiler is making an assumption here that all `pwms` properties must be specifier properties and all use `pwm` specifier.
>
> I think the purpose of 'select: true' is to have the binding always applied:
> https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/pwm/pwm-consumer.yaml#L15
>
> If this is confirmed, DTC performs correct checks as this binding must always
> be applied and so the 'pwms' property must be a phandle-array property.
>
> Device-tree maintainers, can you confirm the purpose of 'select: true' set
> in a DT binding ?
The quoted parts were mentioning Zephyr. Here you mentioned DTC, but ask
about "select: true", so dtschema. I don't get the context... dtschema
has nothing to do with DTC and Zephyr.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 2/2] dt-bindings: leds: Document LTC3208 Multidisplay LED Driver
From: Krzysztof Kozlowski @ 2026-04-13 6:30 UTC (permalink / raw)
To: Roleda, Jan carlo
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, devicetree@vger.kernel.org
In-Reply-To: <BN8PR03MB4977C3A5917167F9B8BE6A3E96272@BN8PR03MB4977.namprd03.prod.outlook.com>
On 13/04/2026 01:37, Roleda, Jan carlo wrote:
> Hello Krzysztof,
>
> Thank you again for the review.
>
> For clarification,
>
>> -----Original Message-----
>> From: Krzysztof Kozlowski <krzk@kernel.org>
>> Sent: Tuesday, April 7, 2026 2:58 PM
>> To: Roleda, Jan carlo <Jancarlo.Roleda@analog.com>
>> Cc: Lee Jones <lee@kernel.org>; Pavel Machek <pavel@kernel.org>; Rob
>> Herring <robh@kernel.org>; Krzysztof Kozlowski <krzk+dt@kernel.org>; Conor
>> Dooley <conor+dt@kernel.org>; linux-kernel@vger.kernel.org; linux-
>> leds@vger.kernel.org; devicetree@vger.kernel.org
>> Subject: Re: [PATCH v3 2/2] dt-bindings: leds: Document LTC3208 Multidisplay
>> LED Driver
>>
>> [External]
>>
>> On Mon, Apr 06, 2026 at 03:17:06PM +0800, Jan Carlo Roleda wrote:
>>> Add Documentation for LTC3208 Multidisplay LED Driver.
>>>
>>> Signed-off-by: Jan Carlo Roleda <jancarlo.roleda@analog.com>
>>> ---
>>
>> Still incorrect order.
You still did not correct the order of patches. I already asked you at v2.
>>
>> ...
>>
>>> +
>>> + led-controller@1b {
>>> + compatible = "adi,ltc3208";
>>> + reg = <0x1b>;
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + adi,disable-camhl-pin;
>>> + adi,cfg-enrgbs-pin;
>>> + adi,disable-rgb-aux4-dropout;
>>> +
>>> + led@0 {
>>> + reg = <0>;
>>
>> I still expect this to be complete, so at least function and color.
>>
>> Best regards,
>> Krzysztof
>
> Are you referring here to keep the led@0-6,
> but instead of only the reg I should include other LED properties (i.e. function and color)?
> If so, I will add them as such in the next patch.
>
> Do let me know if this is correct.
Make the example complete.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v3 5/5] arch: arm64: dts: qcom: Add support for PCIe3a
From: Qiang Yu @ 2026-04-13 6:26 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260412-glymur_gen5x8_phy_0413-v3-0-affcebc16b8b@oss.qualcomm.com>
Describe PCIe3a controller and PHY. Also add required system resources
like regulators, clocks, interrupts and registers configuration for PCIe3a.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 316 ++++++++++++++++++++++++++++++++++-
1 file changed, 315 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index f23cf81ddb77a4138deeb4e00dd8b316930a2feb..c15f87c37ecbad72076a6c731f4959a1a8bd8425 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -736,7 +736,7 @@ gcc: clock-controller@100000 {
<0>, /* USB 2 Phy PCIE PIPEGMUX */
<0>, /* USB 2 Phy PIPEGMUX */
<0>, /* USB 2 Phy SYS PCIE PIPEGMUX */
- <0>, /* PCIe 3a */
+ <&pcie3a_phy>, /* PCIe 3a */
<&pcie3b_phy>, /* PCIe 3b */
<&pcie4_phy>, /* PCIe 4 */
<&pcie5_phy>, /* PCIe 5 */
@@ -3640,6 +3640,320 @@ pcie3b_port0: pcie@0 {
};
};
+ pcie3a: pci@1c10000 {
+ device_type = "pci";
+ compatible = "qcom,glymur-pcie", "qcom,pcie-x1e80100";
+ reg = <0x0 0x01c10000 0x0 0x3000>,
+ <0x0 0x70000000 0x0 0xf20>,
+ <0x0 0x70000f40 0x0 0xa8>,
+ <0x0 0x70001000 0x0 0x4000>,
+ <0x0 0x70100000 0x0 0x100000>,
+ <0x0 0x01c13000 0x0 0x1000>;
+ reg-names = "parf",
+ "dbi",
+ "elbi",
+ "atu",
+ "config",
+ "mhi";
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges = <0x01000000 0x0 0x00000000 0x0 0x70200000 0x0 0x100000>,
+ <0x02000000 0x0 0x70000000 0x0 0x70300000 0x0 0x3d00000>,
+ <0x03000000 0x7 0x00000000 0x7 0x00000000 0x0 0x40000000>,
+ <0x43000000 0x70 0x00000000 0x70 0x00000000 0x10 0x00000000>;
+
+ bus-range = <0 0xff>;
+
+ dma-coherent;
+
+ linux,pci-domain = <3>;
+ num-lanes = <8>;
+
+ operating-points-v2 = <&pcie3a_opp_table>;
+
+ msi-map = <0x0 &gic_its 0xb0000 0x10000>;
+ iommu-map = <0x0 &pcie_smmu 0x30000 0x10000>;
+
+ interrupts = <GIC_SPI 948 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 949 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 844 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 845 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 194 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 846 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 847 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 942 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "msi0",
+ "msi1",
+ "msi2",
+ "msi3",
+ "msi4",
+ "msi5",
+ "msi6",
+ "msi7",
+ "global";
+
+ #interrupt-cells = <1>;
+ interrupt-map-mask = <0 0 0 0x7>;
+ interrupt-map = <0 0 0 1 &intc 0 0 0 848 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 0 849 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 0 850 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 0 851 IRQ_TYPE_LEVEL_HIGH>;
+
+ clocks = <&gcc GCC_PCIE_3A_AUX_CLK>,
+ <&gcc GCC_PCIE_3A_CFG_AHB_CLK>,
+ <&gcc GCC_PCIE_3A_MSTR_AXI_CLK>,
+ <&gcc GCC_PCIE_3A_SLV_AXI_CLK>,
+ <&gcc GCC_PCIE_3A_SLV_Q2A_AXI_CLK>,
+ <&gcc GCC_AGGRE_NOC_PCIE_3A_WEST_SF_AXI_CLK>;
+ clock-names = "aux",
+ "cfg",
+ "bus_master",
+ "bus_slave",
+ "slave_q2a",
+ "noc_aggr";
+
+ assigned-clocks = <&gcc GCC_PCIE_3A_AUX_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ interconnects = <&pcie_west_anoc MASTER_PCIE_3A QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
+ <&hsc_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ALWAYS
+ &pcie_west_slv_noc SLAVE_PCIE_3A QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "pcie-mem",
+ "cpu-pcie";
+
+ resets = <&gcc GCC_PCIE_3A_BCR>,
+ <&gcc GCC_PCIE_3A_LINK_DOWN_BCR>;
+ reset-names = "pci",
+ "link_down";
+
+ power-domains = <&gcc GCC_PCIE_3A_GDSC>;
+
+ eq-presets-8gts = /bits/ 16 <0x5555 0x5555 0x5555 0x5555
+ 0x5555 0x5555 0x5555 0x5555>;
+ eq-presets-16gts = /bits/ 8 <0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55>;
+ eq-presets-32gts = /bits/ 8 <0x55 0x55 0x55 0x55 0x55 0x55 0x55 0x55>;
+
+ status = "disabled";
+
+ pcie3a_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ /* GEN 1 x1 */
+ opp-2500000-1 {
+ opp-hz = /bits/ 64 <2500000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <250000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 1 x2 */
+ opp-5000000-1 {
+ opp-hz = /bits/ 64 <5000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <500000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 1 x4 */
+ opp-10000000-1 {
+ opp-hz = /bits/ 64 <10000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <1000000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 1 x8 */
+ opp-20000000-1 {
+ opp-hz = /bits/ 64 <20000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <2000000 1>;
+ opp-level = <1>;
+ };
+
+ /* GEN 2 x1 */
+ opp-5000000-2 {
+ opp-hz = /bits/ 64 <5000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <500000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 2 x2 */
+ opp-10000000-2 {
+ opp-hz = /bits/ 64 <10000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <1000000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 2 x4 */
+ opp-20000000-2 {
+ opp-hz = /bits/ 64 <20000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <2000000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 2 x8 */
+ opp-40000000-2 {
+ opp-hz = /bits/ 64 <40000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <4000000 1>;
+ opp-level = <2>;
+ };
+
+ /* GEN 3 x1 */
+ opp-8000000-3 {
+ opp-hz = /bits/ 64 <8000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <984500 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 3 x2 */
+ opp-16000000-3 {
+ opp-hz = /bits/ 64 <16000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <1969000 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 3 x4 */
+ opp-32000000-3 {
+ opp-hz = /bits/ 64 <32000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <3938000 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 3 x8 */
+ opp-64000000-3 {
+ opp-hz = /bits/ 64 <64000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <7876000 1>;
+ opp-level = <3>;
+ };
+
+ /* GEN 4 x1 */
+ opp-16000000-4 {
+ opp-hz = /bits/ 64 <16000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <1969000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 4 x2 */
+ opp-32000000-4 {
+ opp-hz = /bits/ 64 <32000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <3938000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 4 x4 */
+ opp-64000000-4 {
+ opp-hz = /bits/ 64 <64000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <7876000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 4 x8 */
+ opp-128000000-4 {
+ opp-hz = /bits/ 64 <128000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <15753000 1>;
+ opp-level = <4>;
+ };
+
+ /* GEN 5 x1 */
+ opp-32000000-5 {
+ opp-hz = /bits/ 64 <32000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <3938000 1>;
+ opp-level = <5>;
+ };
+
+ /* GEN 5 x2 */
+ opp-64000000-5 {
+ opp-hz = /bits/ 64 <64000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <7876000 1>;
+ opp-level = <5>;
+ };
+
+ /* GEN 5 x4 */
+ opp-128000000-5 {
+ opp-hz = /bits/ 64 <128000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <15753000 1>;
+ opp-level = <5>;
+ };
+
+ /* GEN 5 x8 */
+ opp-256000000-5 {
+ opp-hz = /bits/ 64 <256000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <31506000 1>;
+ opp-level = <5>;
+ };
+ };
+
+ pcie3a_port0: pcie@0 {
+ device_type = "pci";
+ reg = <0x0 0x0 0x0 0x0 0x0>;
+ bus-range = <0x01 0xff>;
+
+ phys = <&pcie3a_phy>;
+
+ #address-cells = <3>;
+ #size-cells = <2>;
+ ranges;
+ };
+ };
+
+ pcie3a_phy: phy@f00000 {
+ compatible = "qcom,glymur-qmp-gen5x8-pcie-phy";
+ reg = <0 0x00f00000 0 0x10000>;
+
+ clocks = <&gcc GCC_PCIE_PHY_3A_AUX_CLK>,
+ <&gcc GCC_PCIE_3A_CFG_AHB_CLK>,
+ <&tcsr TCSR_PCIE_3_CLKREF_EN>,
+ <&gcc GCC_PCIE_3A_PHY_RCHNG_CLK>,
+ <&gcc GCC_PCIE_3A_PIPE_CLK>,
+ <&gcc GCC_PCIE_PHY_3B_AUX_CLK>;
+ clock-names = "aux",
+ "cfg_ahb",
+ "ref",
+ "rchng",
+ "pipe",
+ "phy_b_aux";
+
+ resets = <&gcc GCC_PCIE_3A_PHY_BCR>,
+ <&gcc GCC_PCIE_3A_NOCSR_COM_PHY_BCR>,
+ <&gcc GCC_PCIE_3B_PHY_BCR>,
+ <&gcc GCC_PCIE_3B_NOCSR_COM_PHY_BCR>;
+ reset-names = "phy",
+ "phy_nocsr",
+ "phy_b",
+ "phy_b_nocsr";
+
+ assigned-clocks = <&gcc GCC_PCIE_3A_PHY_RCHNG_CLK>;
+ assigned-clock-rates = <100000000>;
+
+ power-domains = <&gcc GCC_PCIE_3A_PHY_GDSC>,
+ <&gcc GCC_PCIE_3B_PHY_GDSC>;
+
+ #clock-cells = <0>;
+ clock-output-names = "pcie3a_pipe_clk";
+
+ #phy-cells = <0>;
+
+ status = "disabled";
+ };
+
pcie3b_phy: phy@f10000 {
compatible = "qcom,glymur-qmp-gen5x4-pcie-phy";
reg = <0x0 0x00f10000 0x0 0x10000>;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 4/5] phy: qcom: qmp-pcie: Add Gen5 8-lanes mode for Glymur
From: Qiang Yu @ 2026-04-13 6:25 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu,
Abel Vesa, Dmitry Baryshkov
In-Reply-To: <20260412-glymur_gen5x8_phy_0413-v3-0-affcebc16b8b@oss.qualcomm.com>
The third PCIe controller on Glymur SoC supports 8-lane operation via
bifurcation of two PHYs (each requires separate power domian, resets and
aux clk).
Add dedicated reset/no_csr reset list ("phy_b", "phy_b_nocsr") and
clock ("phy_b_aux") required for 8-lane operation. Introduce new
glymur_qmp_gen5x8_pciephy_cfg configuration to enable PCIe Gen5 x8 mode.
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 30 +++++++++++++++++++++++++++++-
1 file changed, 29 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 51db9eea41255bad0034bbcfbfdc36894c2bc95f..e872b50b11da50e6317ce7e1acf6385925f92cdb 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -3376,7 +3376,7 @@ static inline void qphy_clrbits(void __iomem *base, u32 offset, u32 val)
/* list of clocks required by phy */
static const char * const qmp_pciephy_clk_l[] = {
- "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux",
+ "aux", "cfg_ahb", "ref", "refgen", "rchng", "phy_aux", "phy_b_aux",
};
/* list of regulators */
@@ -3401,6 +3401,14 @@ static const char * const sm8550_pciephy_nocsr_reset_l[] = {
"phy_nocsr",
};
+static const char * const glymur_pciephy_reset_l[] = {
+ "phy", "phy_b"
+};
+
+static const char * const glymur_pciephy_nocsr_reset_l[] = {
+ "phy_nocsr", "phy_b_nocsr",
+};
+
static const struct qmp_pcie_offsets qmp_pcie_offsets_qhp = {
.serdes = 0,
.pcs = 0x1800,
@@ -4705,6 +4713,23 @@ static const struct qmp_phy_cfg glymur_qmp_gen4x2_pciephy_cfg = {
.phy_status = PHYSTATUS_4_20,
};
+static const struct qmp_phy_cfg glymur_qmp_gen5x8_pciephy_cfg = {
+ .lanes = 8,
+
+ .offsets = &qmp_pcie_offsets_v8_50,
+
+ .reset_list = glymur_pciephy_reset_l,
+ .num_resets = ARRAY_SIZE(glymur_pciephy_reset_l),
+ .nocsr_reset_list = glymur_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(glymur_pciephy_nocsr_reset_l),
+ .vreg_list = qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+
+ .regs = pciephy_v8_50_regs_layout,
+
+ .phy_status = PHYSTATUS_4_20,
+};
+
static void qmp_pcie_init_port_b(struct qmp_pcie *qmp, const struct qmp_phy_cfg_tbls *tbls)
{
const struct qmp_phy_cfg *cfg = qmp->cfg;
@@ -5483,6 +5508,9 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
}, {
.compatible = "qcom,glymur-qmp-gen5x4-pcie-phy",
.data = &glymur_qmp_gen5x4_pciephy_cfg,
+ }, {
+ .compatible = "qcom,glymur-qmp-gen5x8-pcie-phy",
+ .data = &glymur_qmp_gen5x8_pciephy_cfg,
}, {
.compatible = "qcom,ipq6018-qmp-pcie-phy",
.data = &ipq6018_pciephy_cfg,
--
2.34.1
^ permalink raw reply related
* [PATCH v3 3/5] phy: qcom: qmp-pcie: Support multiple nocsr resets
From: Qiang Yu @ 2026-04-13 6:25 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260412-glymur_gen5x8_phy_0413-v3-0-affcebc16b8b@oss.qualcomm.com>
Refactor nocsr reset handling to support multiple nocsr resets required
for PHY configurations with bifurcated operation modes.
The Glymur SoC's 3rd PCIe instance supports 8-lane mode using two PHYs
in bifurcation, where each PHY requires its own nocsr reset to be
controlled simultaneously. The current implementation only supports a
single nocsr reset per PHY configuration.
Add num_nocsr and nocsr_list fields to struct qmp_phy_cfg to represent the
number and names of a group of nocsr reset names. Initialize these fields
for all PHYs that have nocsr resets, allowing the driver to correctly
acquire multiple nocsr resets during probe and control them as an array
by using reset_control_bulk APIs.
The refactoring maintains backward compatibility for existing single
nocsr reset configurations while enabling support for multi-PHY
scenarios like Glymur's 8-lane bifurcation mode.
Additionally, introduces x1e80100_qmp_gen3x2_pciephy_cfg as a separate
configuration from sm8550_qmp_gen3x2_pciephy_cfg since the x1e80100 Gen3x2
PHY requires nocsr reset support while the sm8550 Gen3x2 PHY does not.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 87 ++++++++++++++++++++++++++++----
1 file changed, 77 insertions(+), 10 deletions(-)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index 424c935e27a8766e1e26762bd3d7df527c1520e3..51db9eea41255bad0034bbcfbfdc36894c2bc95f 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -3281,6 +3281,11 @@ struct qmp_phy_cfg {
/* resets to be requested */
const char * const *reset_list;
int num_resets;
+
+ /* nocsr resets to be requested */
+ const char * const *nocsr_reset_list;
+ int num_nocsr_resets;
+
/* regulators to be requested */
const char * const *vreg_list;
int num_vregs;
@@ -3327,7 +3332,7 @@ struct qmp_pcie {
int num_pipe_clks;
struct reset_control_bulk_data *resets;
- struct reset_control *nocsr_reset;
+ struct reset_control_bulk_data *nocsr_reset;
struct regulator_bulk_data *vregs;
struct phy *phy;
@@ -3392,6 +3397,10 @@ static const char * const sdm845_pciephy_reset_l[] = {
"phy",
};
+static const char * const sm8550_pciephy_nocsr_reset_l[] = {
+ "phy_nocsr",
+};
+
static const struct qmp_pcie_offsets qmp_pcie_offsets_qhp = {
.serdes = 0,
.pcs = 0x1800,
@@ -4348,6 +4357,8 @@ static const struct qmp_phy_cfg sm8550_qmp_gen4x2_pciephy_cfg = {
},
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = sm8550_qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(sm8550_qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4380,6 +4391,8 @@ static const struct qmp_phy_cfg sm8650_qmp_gen4x2_pciephy_cfg = {
},
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = sm8550_qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(sm8550_qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4480,6 +4493,35 @@ static const struct qmp_phy_cfg sa8775p_qmp_gen4x4_pciephy_cfg = {
.phy_status = PHYSTATUS_4_20,
};
+static const struct qmp_phy_cfg x1e80100_qmp_gen3x2_pciephy_cfg = {
+ .lanes = 2,
+
+ .offsets = &qmp_pcie_offsets_v5,
+
+ .tbls = {
+ .serdes = sm8550_qmp_gen3x2_pcie_serdes_tbl,
+ .serdes_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_serdes_tbl),
+ .tx = sm8550_qmp_gen3x2_pcie_tx_tbl,
+ .tx_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_tx_tbl),
+ .rx = sm8550_qmp_gen3x2_pcie_rx_tbl,
+ .rx_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_rx_tbl),
+ .pcs = sm8550_qmp_gen3x2_pcie_pcs_tbl,
+ .pcs_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_pcs_tbl),
+ .pcs_misc = sm8550_qmp_gen3x2_pcie_pcs_misc_tbl,
+ .pcs_misc_num = ARRAY_SIZE(sm8550_qmp_gen3x2_pcie_pcs_misc_tbl),
+ },
+ .reset_list = sdm845_pciephy_reset_l,
+ .num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
+ .vreg_list = qmp_phy_vreg_l,
+ .num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
+ .regs = pciephy_v5_regs_layout,
+
+ .pwrdn_ctrl = SW_PWRDN | REFCLK_DRV_DSBL,
+ .phy_status = PHYSTATUS,
+};
+
static const struct qmp_phy_cfg x1e80100_qmp_gen4x2_pciephy_cfg = {
.lanes = 2,
@@ -4502,6 +4544,8 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x2_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4535,6 +4579,8 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x4_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4566,6 +4612,8 @@ static const struct qmp_phy_cfg x1e80100_qmp_gen4x8_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4581,6 +4629,8 @@ static const struct qmp_phy_cfg qmp_v6_gen4x4_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = pciephy_v6_regs_layout,
@@ -4609,6 +4659,8 @@ static const struct qmp_phy_cfg qmp_v8_gen3x2_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
.regs = pciephy_v8_regs_layout,
@@ -4624,6 +4676,8 @@ static const struct qmp_phy_cfg glymur_qmp_gen5x4_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
@@ -4640,6 +4694,8 @@ static const struct qmp_phy_cfg glymur_qmp_gen4x2_pciephy_cfg = {
.reset_list = sdm845_pciephy_reset_l,
.num_resets = ARRAY_SIZE(sdm845_pciephy_reset_l),
+ .nocsr_reset_list = sm8550_pciephy_nocsr_reset_l,
+ .num_nocsr_resets = ARRAY_SIZE(sm8550_pciephy_nocsr_reset_l),
.vreg_list = qmp_phy_vreg_l,
.num_vregs = ARRAY_SIZE(qmp_phy_vreg_l),
@@ -4768,7 +4824,7 @@ static int qmp_pcie_init(struct phy *phy)
}
}
- ret = reset_control_assert(qmp->nocsr_reset);
+ ret = reset_control_bulk_assert(cfg->num_nocsr_resets, qmp->nocsr_reset);
if (ret) {
dev_err(qmp->dev, "no-csr reset assert failed\n");
goto err_assert_reset;
@@ -4805,7 +4861,7 @@ static int qmp_pcie_exit(struct phy *phy)
const struct qmp_phy_cfg *cfg = qmp->cfg;
if (qmp->nocsr_reset)
- reset_control_assert(qmp->nocsr_reset);
+ reset_control_bulk_assert(cfg->num_nocsr_resets, qmp->nocsr_reset);
else
reset_control_bulk_assert(cfg->num_resets, qmp->resets);
@@ -4849,7 +4905,7 @@ static int qmp_pcie_power_on(struct phy *phy)
if (ret)
return ret;
- ret = reset_control_deassert(qmp->nocsr_reset);
+ ret = reset_control_bulk_deassert(cfg->num_nocsr_resets, qmp->nocsr_reset);
if (ret) {
dev_err(qmp->dev, "no-csr reset deassert failed\n");
goto err_disable_pipe_clk;
@@ -4998,14 +5054,25 @@ static int qmp_pcie_reset_init(struct qmp_pcie *qmp)
for (i = 0; i < cfg->num_resets; i++)
qmp->resets[i].id = cfg->reset_list[i];
- ret = devm_reset_control_bulk_get_exclusive(dev, cfg->num_resets, qmp->resets);
+ ret = devm_reset_control_bulk_get_exclusive(dev, cfg->num_resets,
+ qmp->resets);
if (ret)
return dev_err_probe(dev, ret, "failed to get resets\n");
- qmp->nocsr_reset = devm_reset_control_get_optional_exclusive(dev, "phy_nocsr");
- if (IS_ERR(qmp->nocsr_reset))
- return dev_err_probe(dev, PTR_ERR(qmp->nocsr_reset),
- "failed to get no-csr reset\n");
+ if (!cfg->num_nocsr_resets)
+ return 0;
+ qmp->nocsr_reset = devm_kcalloc(dev, cfg->num_nocsr_resets,
+ sizeof(*qmp->nocsr_reset), GFP_KERNEL);
+ if (!qmp->nocsr_reset)
+ return -ENOMEM;
+
+ for (i = 0; i < cfg->num_nocsr_resets; i++)
+ qmp->nocsr_reset[i].id = cfg->nocsr_reset_list[i];
+
+ ret = devm_reset_control_bulk_get_exclusive(dev, cfg->num_nocsr_resets,
+ qmp->nocsr_reset);
+ if (ret)
+ return dev_err_probe(dev, ret, "failed to get no-csr reset\n");
return 0;
}
@@ -5520,7 +5587,7 @@ static const struct of_device_id qmp_pcie_of_match_table[] = {
.data = &sm8750_qmp_gen3x2_pciephy_cfg,
}, {
.compatible = "qcom,x1e80100-qmp-gen3x2-pcie-phy",
- .data = &sm8550_qmp_gen3x2_pciephy_cfg,
+ .data = &x1e80100_qmp_gen3x2_pciephy_cfg,
}, {
.compatible = "qcom,x1e80100-qmp-gen4x2-pcie-phy",
.data = &x1e80100_qmp_gen4x2_pciephy_cfg,
--
2.34.1
^ permalink raw reply related
* [PATCH v3 2/5] phy: qcom: qmp-pcie: Add multiple power-domains support
From: Qiang Yu @ 2026-04-13 6:25 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu,
Dmitry Baryshkov
In-Reply-To: <20260412-glymur_gen5x8_phy_0413-v3-0-affcebc16b8b@oss.qualcomm.com>
The Glymur SoC's 3rd PCIe instance supports 8-lane mode using two PHYs in
a bifurcated configuration. Each PHY has its own power domain (phy_gdsc)
that must be powered on before initialization per hardware requirements.
Current PHY power management assumes a single power domain per PHY,
preventing proper setup for this dual-PHY scenario. Add support for
multiple power domains by using devm_pm_domain_attach_list() to attach
power domains manually, while maintaining compatibility with single
power domain PHYs.
Enable runtime PM to allow power domain control when the PCIe driver
calls phy_power_on/phy_power_off:
- Single power domain: QMP PHY platform device directly attaches to
power domain and controls it during runtime resume/suspend
- Multiple power domains: devm_pm_domain_attach_list() creates virtual
devices as power domain suppliers, linked to the QMP PHY platform
device as consumer
This ensures power domains are properly attached and turned on/off
for both single and multiple power domain configurations.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
index fed2fc9bb31108d51f88d34f3379c7744681f485..424c935e27a8766e1e26762bd3d7df527c1520e3 100644
--- a/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
+++ b/drivers/phy/qualcomm/phy-qcom-qmp-pcie.c
@@ -17,6 +17,7 @@
#include <linux/phy/pcie.h>
#include <linux/phy/phy.h>
#include <linux/platform_device.h>
+#include <linux/pm_domain.h>
#include <linux/regmap.h>
#include <linux/regulator/consumer.h>
#include <linux/reset.h>
@@ -5329,6 +5330,7 @@ static int qmp_pcie_parse_dt(struct qmp_pcie *qmp)
static int qmp_pcie_probe(struct platform_device *pdev)
{
+ struct dev_pm_domain_list *pd_list;
struct device *dev = &pdev->dev;
struct phy_provider *phy_provider;
struct device_node *np;
@@ -5348,6 +5350,16 @@ static int qmp_pcie_probe(struct platform_device *pdev)
WARN_ON_ONCE(!qmp->cfg->pwrdn_ctrl);
WARN_ON_ONCE(!qmp->cfg->phy_status);
+ ret = devm_pm_domain_attach_list(dev, NULL, &pd_list);
+ if (ret < 0 && ret != -EEXIST) {
+ dev_err(dev, "Failed to attach power domain\n");
+ return ret;
+ }
+
+ ret = devm_pm_runtime_enable(dev);
+ if (ret)
+ return ret;
+
ret = qmp_pcie_clk_init(qmp);
if (ret)
return ret;
--
2.34.1
^ permalink raw reply related
* [PATCH v3 1/5] dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
From: Qiang Yu @ 2026-04-13 6:25 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu
In-Reply-To: <20260412-glymur_gen5x8_phy_0413-v3-0-affcebc16b8b@oss.qualcomm.com>
The Glymur SoC has pcie3a and pcie3b PHYs that can operate in two modes:
1. Independent 4-lane mode: Each PHY operates as a separate PCIe Gen5
4-lane interface, compatible with qcom,glymur-qmp-gen5x4-pcie-phy
2. Bifurcation mode (8-lane): pcie3a phy acts as leader and pcie3b phy as
follower to form a single 8-lane PCIe Gen5 interface
In bifurcation mode, the hardware design requires controlling additional
resources beyond the standard pcie3a PHY configuration:
- pcie3b's aux_clk (phy_b_aux)
- pcie3b's phy_gdsc power domain
- pcie3b's bcr/nocsr reset
Add qcom,glymur-qmp-gen5x8-pcie-phy compatible string to document this
8-lane bifurcation configuration.
The phy_b_aux clock is used as the 6th clock instead of pipediv2,
requiring the clock-names enum to be extended to support both
[phy_b_aux, pipediv2] options at index 5. This follows the existing
pattern used for [rchng, refgen] clocks at index 3.
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
.../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 53 ++++++++++++++++++----
1 file changed, 45 insertions(+), 8 deletions(-)
diff --git a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
index 3a35120a77ec0ceb814a1cdcacff32fef32b4f7b..14eba5d705b1956c1bb00cc8c95171ed6488299b 100644
--- a/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
+++ b/Documentation/devicetree/bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml
@@ -18,6 +18,7 @@ properties:
enum:
- qcom,glymur-qmp-gen4x2-pcie-phy
- qcom,glymur-qmp-gen5x4-pcie-phy
+ - qcom,glymur-qmp-gen5x8-pcie-phy
- qcom,kaanapali-qmp-gen3x2-pcie-phy
- qcom,qcs615-qmp-gen3x1-pcie-phy
- qcom,qcs8300-qmp-gen4x2-pcie-phy
@@ -68,20 +69,27 @@ properties:
- const: ref
- enum: [rchng, refgen]
- const: pipe
- - const: pipediv2
+ - enum: [phy_b_aux, pipediv2]
power-domains:
- maxItems: 1
+ minItems: 1
+ items:
+ - description: PCIe PHY power domain. For PHYs supporting
+ bifurcation mode, this is the leader PHY power domain.
+ - description: Additional PCIe PHY power domain for PHYs supporting
+ bifurcation mode, used by the follower PHY.
resets:
minItems: 1
- maxItems: 2
+ maxItems: 4
reset-names:
minItems: 1
items:
- const: phy
- const: phy_nocsr
+ - const: phy_b
+ - const: phy_b_nocsr
vdda-phy-supply: true
@@ -183,6 +191,7 @@ allOf:
enum:
- qcom,glymur-qmp-gen4x2-pcie-phy
- qcom,glymur-qmp-gen5x4-pcie-phy
+ - qcom,glymur-qmp-gen5x8-pcie-phy
- qcom,qcs8300-qmp-gen4x2-pcie-phy
- qcom,sa8775p-qmp-gen4x2-pcie-phy
- qcom,sa8775p-qmp-gen4x4-pcie-phy
@@ -201,6 +210,21 @@ allOf:
clock-names:
minItems: 6
+ - if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-qmp-gen5x8-pcie-phy
+ then:
+ properties:
+ power-domains:
+ minItems: 2
+ else:
+ properties:
+ power-domains:
+ maxItems: 1
+
- if:
properties:
compatible:
@@ -223,11 +247,24 @@ allOf:
reset-names:
minItems: 2
else:
- properties:
- resets:
- maxItems: 1
- reset-names:
- maxItems: 1
+ if:
+ properties:
+ compatible:
+ contains:
+ enum:
+ - qcom,glymur-qmp-gen5x8-pcie-phy
+ then:
+ properties:
+ resets:
+ minItems: 4
+ reset-names:
+ minItems: 4
+ else:
+ properties:
+ resets:
+ maxItems: 1
+ reset-names:
+ maxItems: 1
- if:
properties:
--
2.34.1
^ permalink raw reply related
* [PATCH v3 0/5] phy: qcom: qmp-pcie: Add PCIe Gen5 8-lane bifurcation support for Glymur
From: Qiang Yu @ 2026-04-13 6:25 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Philipp Zabel, Bjorn Andersson, Konrad Dybcio
Cc: linux-arm-msm, linux-phy, devicetree, linux-kernel, Qiang Yu,
Dmitry Baryshkov, Abel Vesa
This patch series adds support for PCIe Gen5 8-lane bifurcation mode on
the Glymur SoC's third PCIe controller. In this configuration, pcie3a PHY
acts as leader and pcie3b PHY as follower to form a single 8-lane PCIe
Gen5 interface.
To support 8-lanes mode, this patch series add multiple power domain and
multi nocsr reset infrastructure as the hardware programming guide
specifies a strict initialization sequence for bifurcation mode that
requires coordinated multi-PHY resource management:
1. Turn on both pcie3a_phy_gdsc and pcie3b_phy_gdsc power domains
2. Assert both pcie3a and pcie3b nocsr resets, then deassert them together
3. Enable all pcie3a PHY clocks and pcie3b PHY aux clock (phy_b_aux)
4. Poll for PHY ready status
Changes Overview:
Patch 1: Updates dt-bindings to add qcom,glymur-qmp-gen5x8-pcie-phy
compatible string with proper validation rules for the unique clock
sequence and multiple power domains/resets required for bifurcation mode.
Patch 2: Extends the QMP PCIe driver to support multiple power domains
using devm_pm_domain_attach_list() and enables runtime PM for proper power
domain control during phy_power_on/phy_power_off operations.
Patch 3: Adds infrastructure for handling multiple nocsr resets by
introducing num_nocsr_resets and nocsr_reset_list fields to qmp_phy_cfg,
allowing the driver to manage arrays of nocsr resets using
reset_control_bulk APIs.
Patch 4: Implements the complete Gen5 8-lane configuration for Glymur by
adding the glymur_qmp_gen5x8_pciephy_cfg with proper reset lists, clock
configuration.
Patch 5: Add PCIe3a device tree node and required system resources in
glymur.dtsi. PCIe3a slot is not present on Glymur CRD, so there is no
changes to glymur-crd.dts.
Changes in v3:
- Add description of each power-domain.
- Add 64bit prefetchable memory range required by some EPs eg. AI100 ultra.
- Move PCIe3a after PCIe3b and move PCIe3a PHY before PCIe3b PHY.
- Link to v2: https://lore.kernel.org/all/20260323-glymur_gen5x8_phy_0323-v2-0-ce0fc07f0e52@oss.qualcomm.com/
Changes in v2:
- Remove pd_list from qmp_pcie struct as it is not used in phy driver.
- align clk-names on "
- Link to v1: https://lore.kernel.org/all/20260304-glymur_gen5x8_phy-v1-0-849e9a72e125@oss.qualcomm.com/
Signed-off-by: Qiang Yu <qiang.yu@oss.qualcomm.com>
---
Qiang Yu (5):
dt-bindings: phy: qcom,sc8280xp-qmp-pcie-phy: Add support for glymur Gen5 x8 bifurcation mode
phy: qcom: qmp-pcie: Add multiple power-domains support
phy: qcom: qmp-pcie: Support multiple nocsr resets
phy: qcom: qmp-pcie: Add Gen5 8-lanes mode for Glymur
arch: arm64: dts: qcom: Add support for PCIe3a
.../bindings/phy/qcom,sc8280xp-qmp-pcie-phy.yaml | 53 +++-
arch/arm64/boot/dts/qcom/glymur.dtsi | 316 ++++++++++++++++++++-
drivers/phy/qualcomm/phy-qcom-qmp-pcie.c | 129 ++++++++-
3 files changed, 478 insertions(+), 20 deletions(-)
---
base-commit: 66672af7a095d89f082c5327f3b15bc2f93d558e
change-id: 20260412-glymur_gen5x8_phy_0413-7dd33c953da7
Best regards,
--
Qiang Yu <qiang.yu@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH v2 2/3] hte: tegra194: Add Tegra264 GTE support
From: Dipen Patel @ 2026-04-13 6:23 UTC (permalink / raw)
To: Suneel Garapati, jonathanh, thierry.reding, krzk+dt, conor+dt,
amhetre, sheetal, kkartik, robh, pshete, timestamp, devicetree,
linux-tegra, linux-kernel
In-Reply-To: <20260408212413.217692-3-suneelg@nvidia.com>
On 4/8/26 2:24 PM, Suneel Garapati wrote:
> Add AON-GTE mapping and LIC GTE instance support for the Tegra264.
> Move TSC clock parameters from macros to members of SoC data
> as values differ for Tegra264 chip.
>
> Signed-off-by: Suneel Garapati <suneelg@nvidia.com>
> ---
> drivers/hte/hte-tegra194.c | 133 +++++++++++++++++++++++++++++++++++--
> 1 file changed, 128 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/hte/hte-tegra194.c b/drivers/hte/hte-tegra194.c
> index 690eb9be30fb..4a7702b32b24 100644
> --- a/drivers/hte/hte-tegra194.c
> +++ b/drivers/hte/hte-tegra194.c
> @@ -20,10 +20,11 @@
>
> #define HTE_SUSPEND 0
>
> -/* HTE source clock TSC is 31.25MHz */
> +/* HTE source clock TSC is 1GHz for T264 and 31.25MHz for others */
> #define HTE_TS_CLK_RATE_HZ 31250000ULL
> +#define HTE_TS_CLK_RATE_1G 1000000000ULL
> #define HTE_CLK_RATE_NS 32
> -#define HTE_TS_NS_SHIFT __builtin_ctz(HTE_CLK_RATE_NS)
> +#define HTE_CLK_RATE_NS_1G 1
>
> #define NV_AON_SLICE_INVALID -1
> #define NV_LINES_IN_SLICE 32
> @@ -120,6 +121,8 @@ struct tegra_hte_data {
> u32 slices;
> u32 map_sz;
> u32 sec_map_sz;
> + u64 tsc_clkrate_hz;
> + u32 tsc_clkrate_ns;
> const struct tegra_hte_line_mapped *map;
> const struct tegra_hte_line_mapped *sec_map;
> };
> @@ -317,6 +320,94 @@ static const struct tegra_hte_line_mapped tegra234_aon_gpio_sec_map[] = {
> [40] = {2, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
> };
>
> +static const struct tegra_hte_line_mapped tegra264_aon_gpio_map[] = {
> + /* gpio, slice, bit_index */
> + /* AA port */
> + [0] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
> + [1] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
> + [2] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
> + [3] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
> + [4] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
> + [5] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
> + [6] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
> + [7] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
> + /* BB port */
> + [8] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
> + [9] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
> + /* CC port */
> + [10] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
> + [11] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
> + [12] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
> + [13] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
> + [14] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
> + [15] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
> + [16] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
> + [17] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
> + /* DD port */
> + [18] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
> + [19] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
> + [20] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
> + [21] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
> + [22] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
> + [23] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
> + [24] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
> + [25] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
> + /* EE port */
> + [26] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
> + [27] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
> + [28] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
> + [29] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
> +};
> +
> +static const struct tegra_hte_line_mapped tegra264_aon_gpio_sec_map[] = {
> + /* gpio, slice, bit_index */
> + /* AA port */
> + [0] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_29},
> + [1] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_28},
> + [2] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_27},
> + [3] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_26},
> + [4] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_25},
> + [5] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_24},
> + [6] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_23},
> + [7] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_22},
> + /* BB port */
> + [8] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_21},
> + [9] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_20},
> + [10] = {NV_AON_SLICE_INVALID, 0},
> + [11] = {NV_AON_SLICE_INVALID, 0},
> + [12] = {NV_AON_SLICE_INVALID, 0},
> + [13] = {NV_AON_SLICE_INVALID, 0},
> + [14] = {NV_AON_SLICE_INVALID, 0},
> + [15] = {NV_AON_SLICE_INVALID, 0},
> + /* CC port */
> + [16] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_19},
> + [17] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_18},
> + [18] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_17},
> + [19] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_16},
> + [20] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_15},
> + [21] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_14},
> + [22] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_13},
> + [23] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_12},
> + /* DD port */
> + [24] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_11},
> + [25] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_10},
> + [26] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_9},
> + [27] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_8},
> + [28] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_7},
> + [29] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_6},
> + [30] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_5},
> + [31] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_4},
> + /* EE port */
> + [32] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_3},
> + [33] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_2},
> + [34] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_1},
> + [35] = {3, NV_AON_HTE_SLICE2_IRQ_GPIO_0},
> + [36] = {NV_AON_SLICE_INVALID, 0},
> + [37] = {NV_AON_SLICE_INVALID, 0},
> + [38] = {NV_AON_SLICE_INVALID, 0},
> + [39] = {NV_AON_SLICE_INVALID, 0},
> +};
> +
> static const struct tegra_hte_data t194_aon_hte = {
> .map_sz = ARRAY_SIZE(tegra194_aon_gpio_map),
> .map = tegra194_aon_gpio_map,
> @@ -324,6 +415,8 @@ static const struct tegra_hte_data t194_aon_hte = {
> .sec_map = tegra194_aon_gpio_sec_map,
> .type = HTE_TEGRA_TYPE_GPIO,
> .slices = 3,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> };
>
> static const struct tegra_hte_data t234_aon_hte = {
> @@ -333,6 +426,19 @@ static const struct tegra_hte_data t234_aon_hte = {
> .sec_map = tegra234_aon_gpio_sec_map,
> .type = HTE_TEGRA_TYPE_GPIO,
> .slices = 3,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> +};
> +
> +static const struct tegra_hte_data t264_aon_hte = {
> + .map_sz = ARRAY_SIZE(tegra264_aon_gpio_map),
> + .map = tegra264_aon_gpio_map,
> + .sec_map_sz = ARRAY_SIZE(tegra264_aon_gpio_sec_map),
> + .sec_map = tegra264_aon_gpio_sec_map,
> + .type = HTE_TEGRA_TYPE_GPIO,
> + .slices = 4,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_1G,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS_1G,
> };
>
> static const struct tegra_hte_data t194_lic_hte = {
> @@ -340,6 +446,8 @@ static const struct tegra_hte_data t194_lic_hte = {
> .map = NULL,
> .type = HTE_TEGRA_TYPE_LIC,
> .slices = 11,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> };
>
> static const struct tegra_hte_data t234_lic_hte = {
> @@ -347,6 +455,17 @@ static const struct tegra_hte_data t234_lic_hte = {
> .map = NULL,
> .type = HTE_TEGRA_TYPE_LIC,
> .slices = 17,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_HZ,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS,
> +};
> +
> +static const struct tegra_hte_data t264_lic_hte = {
> + .map_sz = 0,
> + .map = NULL,
> + .type = HTE_TEGRA_TYPE_LIC,
> + .slices = 10,
> + .tsc_clkrate_hz = HTE_TS_CLK_RATE_1G,
> + .tsc_clkrate_ns = HTE_CLK_RATE_NS_1G,
> };
>
> static inline u32 tegra_hte_readl(struct tegra_hte_soc *hte, u32 reg)
> @@ -574,12 +693,12 @@ static int tegra_hte_release(struct hte_chip *chip, struct hte_ts_desc *desc,
> static int tegra_hte_clk_src_info(struct hte_chip *chip,
> struct hte_clk_info *ci)
> {
> - (void)chip;
> + struct tegra_hte_soc *hte_dev = chip->data;
>
> if (!ci)
> return -EINVAL;
>
> - ci->hz = HTE_TS_CLK_RATE_HZ;
> + ci->hz = hte_dev->prov_data->tsc_clkrate_hz;
> ci->type = CLOCK_MONOTONIC;
>
> return 0;
> @@ -602,8 +721,10 @@ static void tegra_hte_read_fifo(struct tegra_hte_soc *gs)
> {
> u32 tsh, tsl, src, pv, cv, acv, slice, bit_index, line_id;
> u64 tsc;
> + u8 tsc_ns_shift;
> struct hte_ts_data el;
>
> + tsc_ns_shift = __builtin_ctz(gs->prov_data->tsc_clkrate_ns);
> while ((tegra_hte_readl(gs, HTE_TESTATUS) >>
> HTE_TESTATUS_OCCUPANCY_SHIFT) &
> HTE_TESTATUS_OCCUPANCY_MASK) {
> @@ -621,7 +742,7 @@ static void tegra_hte_read_fifo(struct tegra_hte_soc *gs)
> while (acv) {
> bit_index = __builtin_ctz(acv);
> line_id = bit_index + (slice << 5);
> - el.tsc = tsc << HTE_TS_NS_SHIFT;
> + el.tsc = tsc << tsc_ns_shift;
> el.raw_level = tegra_hte_get_level(gs, line_id);
> hte_push_ts_ns(gs->chip, line_id, &el);
> acv &= ~BIT(bit_index);
> @@ -656,6 +777,8 @@ static const struct of_device_id tegra_hte_of_match[] = {
> { .compatible = "nvidia,tegra194-gte-aon", .data = &t194_aon_hte},
> { .compatible = "nvidia,tegra234-gte-lic", .data = &t234_lic_hte},
> { .compatible = "nvidia,tegra234-gte-aon", .data = &t234_aon_hte},
> + { .compatible = "nvidia,tegra264-gte-lic", .data = &t264_lic_hte},
> + { .compatible = "nvidia,tegra264-gte-aon", .data = &t264_aon_hte},
> { }
> };
> MODULE_DEVICE_TABLE(of, tegra_hte_of_match);
Reviewed-by: Dipen Patel <dipenp@nvidia.com>
^ permalink raw reply
* [PATCH v4 2/2] riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
From: Sandie Cao @ 2026-04-13 6:07 UTC (permalink / raw)
To: Yixun Lan, Troy Mitchell
Cc: Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heinrich Schuchardt, Michael Opdenacker, Guodong Xu,
Hendrik Hamerlinck, Yangyu Chen, spacemit, linux-riscv,
devicetree, linux-kernel, Sandie Cao
In-Reply-To: <20260413060524.1235982-1-sandie.cao@deepcomputing.io>
The FML13V05 board from DeepComputing incorporates a SpacemiT K3 RISC-V
SoC.It is a mainboard designed for the Framework Laptop 13 Chassis,
which has (Framework) SKU FRANHQ0001.
The FML13V05 board features:
- SpacemiT K3 RISC-V SoC
- LPDDR5 16GB or 32GB
- eMMC 32GB ~128GB (Optional)
- UFS 3.1 256G (Optional)
- QSPI Flash
- MicroSD Slot
- PCIe-based Wi-Fi
- 4 USB-C Ports
- Port 1: PD 3.0 (65W Max), USB 3.2 Gen 1
- Port 2: PD 3.0 (65W Max), USB 3.2 Gen 1, DP 1.4 (4K@60Hz)
- Port 3 & 4: USB 3.2 Gen 1
This minimal device tree enables booting into a serial console with UART
output.
Signed-off-by: Sandie Cao <sandie.cao@deepcomputing.io>
---
arch/riscv/boot/dts/spacemit/Makefile | 1 +
.../spacemit/k3-deepcomputing-fml13v05.dts | 31 +++++++++++++++++++
2 files changed, 32 insertions(+)
create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
diff --git a/arch/riscv/boot/dts/spacemit/Makefile b/arch/riscv/boot/dts/spacemit/Makefile
index 7e2b87702571..acb993c452ba 100644
--- a/arch/riscv/boot/dts/spacemit/Makefile
+++ b/arch/riscv/boot/dts/spacemit/Makefile
@@ -4,4 +4,5 @@ dtb-$(CONFIG_ARCH_SPACEMIT) += k1-milkv-jupiter.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-musepi-pro.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-r2s.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k1-orangepi-rv2.dtb
+dtb-$(CONFIG_ARCH_SPACEMIT) += k3-deepcomputing-fml13v05.dtb
dtb-$(CONFIG_ARCH_SPACEMIT) += k3-pico-itx.dtb
diff --git a/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
new file mode 100644
index 000000000000..b5d5112de358
--- /dev/null
+++ b/arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
@@ -0,0 +1,31 @@
+// SPDX-License-Identifier: (GPL-2.0 OR MIT)
+/*
+ * Copyright (C) 2026 DeepComputing (HK) Limited
+ */
+
+#include "k3.dtsi"
+#include "k3-pinctrl.dtsi"
+
+/ {
+ model = "DeepComputing FML13V05";
+ compatible = "deepcomputing,fml13v05", "spacemit,k3";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0";
+ };
+
+ memory@100000000 {
+ device_type = "memory";
+ reg = <0x1 0x00000000 0x4 0x00000000>;
+ };
+};
+
+&uart0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_0_cfg>;
+ status = "okay";
+};
--
2.43.0
^ permalink raw reply related
* [PATCH v4 1/2] dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
From: Sandie Cao @ 2026-04-13 6:06 UTC (permalink / raw)
To: Yixun Lan, Troy Mitchell
Cc: Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heinrich Schuchardt, Michael Opdenacker, Guodong Xu,
Hendrik Hamerlinck, Yangyu Chen, spacemit, linux-riscv,
devicetree, linux-kernel, Sandie Cao, Conor Dooley
In-Reply-To: <20260413060524.1235982-1-sandie.cao@deepcomputing.io>
Document the compatible string for the Deepcomputing fml13v05.
It's based on the SpacemiT K3 RISC-V SoC and is designed for the Framework
Laptop 13 Chassis, which has (Framework) SKU FRANHQ0001.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Sandie Cao <sandie.cao@deepcomputing.io>
---
Documentation/devicetree/bindings/riscv/spacemit.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/riscv/spacemit.yaml b/Documentation/devicetree/bindings/riscv/spacemit.yaml
index b958b94a924d..af8030242bdc 100644
--- a/Documentation/devicetree/bindings/riscv/spacemit.yaml
+++ b/Documentation/devicetree/bindings/riscv/spacemit.yaml
@@ -29,6 +29,7 @@ properties:
- const: spacemit,k1
- items:
- enum:
+ - deepcomputing,fml13v05
- spacemit,k3-pico-itx
- const: spacemit,k3
--
2.43.0
^ permalink raw reply related
* [PATCH v4 0/2] Add DeepComputing FML13V05 board dts
From: Sandie Cao @ 2026-04-13 6:05 UTC (permalink / raw)
To: Yixun Lan, Troy Mitchell
Cc: Conor Dooley, Emil Renner Berthing, Rob Herring,
Krzysztof Kozlowski, Paul Walmsley, Palmer Dabbelt, Albert Ou,
Heinrich Schuchardt, Michael Opdenacker, Guodong Xu,
Hendrik Hamerlinck, Yangyu Chen, spacemit, linux-riscv,
devicetree, linux-kernel, Sandie Cao
This series updates Device Tree related files to introduce the
FML13V05 board from DeepComputing, which incorporates a Spacemit
K3 SoC. This board is designed for use on the Framework Laptop 13
Chassis, which has (Framework) SKU FRANHQ0001.
The series is rebased on k1/dt-for-next.
v4:
- Patch 1:
Add Acked-by Conor Dooley.
- Patch 2:
Copyright begins from 2026.
v3:
rebased on k1/dt-for-next.
- Patch 1:
Use formal format user name.
Remove Reviewed-by Heinrich Schuchardt from internal system.
- Patch 2:
Use formal format user name.
Remove Reviewed-by Heinrich Schuchardt from internal system.
Add uart0 pinctrl.
Link to v3: https://lore.kernel.org/all/20260407055557.1202713-1-sandie.cao@deepcomputing.io/
v2 (deprecated):
Link to v2: https://lore.kernel.org/all/20260331071110.68321-1-sandie.cao@deepcomputing.io/
v1:
Link to v1: https://lore.kernel.org/all/20260331034423.67142-1-sandie.cao@deepcomputing.io/
Sandie Cao (2):
dt-bindings: riscv: spacemit: add deepcomputing,fml13v05
riscv: dts: spacemit: add DeepComputing FML13V05 board device tree
.../devicetree/bindings/riscv/spacemit.yaml | 1 +
arch/riscv/boot/dts/spacemit/Makefile | 1 +
.../spacemit/k3-deepcomputing-fml13v05.dts | 31 +++++++++++++++++++
3 files changed, 33 insertions(+)
create mode 100644 arch/riscv/boot/dts/spacemit/k3-deepcomputing-fml13v05.dts
base-commit: af62a095eb0c3359d477b55ef72d2afd94c83c8f
--
2.43.0
^ permalink raw reply
* [PATCH v1] arm64: dts: qcom: lemans: Enable DISPLAY-PORT
From: Kumar Anurag @ 2026-04-13 4:37 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel, Kumar Anurag
Add dailinks for DISPLAY-PORT to enable audio functionality
on edp0.
Signed-off-by: Kumar Anurag <kumar.singh@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/lemans-evk.dts | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/lemans-evk.dts b/arch/arm64/boot/dts/qcom/lemans-evk.dts
index 90fce947ca7e..daed18b1e6f5 100644
--- a/arch/arm64/boot/dts/qcom/lemans-evk.dts
+++ b/arch/arm64/boot/dts/qcom/lemans-evk.dts
@@ -130,6 +130,22 @@ platform {
sound-dai = <&q6apm>;
};
};
+
+ dp0-dai-link {
+ link-name = "DisplayPort0 Playback";
+
+ cpu {
+ sound-dai = <&q6apmbedai DISPLAY_PORT_RX_0>;
+ };
+
+ codec {
+ sound-dai = <&mdss0_dp0>;
+ };
+
+ platform {
+ sound-dai = <&q6apm>;
+ };
+ };
};
vbus_supply_regulator_0: regulator-vbus-supply-0 {
--
2.34.1
^ permalink raw reply related
* RE: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Ryan Chen @ 2026-04-13 1:57 UTC (permalink / raw)
To: Ryan Chen, Jeremy Kerr, Krzysztof Kozlowski
Cc: andriy.shevchenko@linux.intel.com, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <TY2PPF5CB9A1BE64B7988CD85A7189164E1F253A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
> > Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add
> > global-regs and enable-dma properties
> >
> > Hi Ryan,
> >
> > > > Sounds reasonable, but before you do so, how are you planning to
> > > > manage the allocation of DMA channels across multiple i2c peripherals?
> > > >
> > > The AST2600 I2C hardware has only one can use DMA at a time.
> > > To avoid the complexity of managing DMA channel contention, I plan
> > > to use buffer mode by default for all controllers, which still
> > > provides better performance than byte mode without requiring DMA
> > > channel
> > allocation.
> >
> > OK, but your wording there ("by default") implies that DMA is still
> > selectable for one controller peripheral. In which case: you still
> > have the problem of managing DMA channel contention, but now it's at
> runtime instead.
> >
> > So my question still stands: how are you planning to enforce that DMA
> > is only enabled for one controller?
> >
> > Or are you planning to disable I2C DMA entirely on AST2600?
> Yes, This is my intent to do.
> Disable I2C DMA entirely on AST2600.
> If I remove DMA, should can I keep byte and buffer for sysfs?
Hello Rob,
On the AST2600, we have a single-channel constraint, which makes DMA
support across all controllers difficult to implement without some kind of
predefined configuration. That would be a bit of a misuse of a DT property.
For future platforms such as the AST2700, DMA support should be much
more straightforward. DMA capability can be inferred from the compatible
string.
Unless there are any objections, I will rework this series to use buffer mode
only on the AST2600, and add AST2700 DMA support separately.
Ryan
^ permalink raw reply
* Re: [PATCH v3 5/5] arm64: dts: qcom: qcs8550: add QCS8550 RB5Gen2 board support
From: Dmitry Baryshkov @ 2026-04-13 1:39 UTC (permalink / raw)
To: Joe Sandom
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260409-rb5gen2-dts-v3-5-be736355d4b4@axon.com>
On Thu, Apr 09, 2026 at 04:26:57PM +0100, Joe Sandom wrote:
> The RB5gen2 is an embedded development platform for the
> QCS8550, based on the Snapdragon 8 Gen 2 SoC (SM8550).
>
> This change implements the main board, the vision mezzanine
> will be supported in a follow up patch.
>
> The main board has the following features:
> - Qualcomm Dragonwing QCS8550 SoC
> - Adreno GPU 740
> - Spectra ISP
> - Adreno VPU 8550
> - Adreno DPU 1295
> - 1 x 1GbE Ethernet (USB Ethernet)
> - WIFI 7 + Bluetooth 5.4
> - 1 x USB 2.0 Micro B (Debug)
> - 1 x USB 3.0 Type C (ADB, DP out)
> - 2 x USB 3.0 Type A
> - 1 x HDMI 1.4 Type A
> - 1 x DP 1.4 Type C
> - 2 x WSA8845 Speaker amplifiers
> - 2 x Speaker connectors
> - 1 x On Board PDM MIC
> - Accelerometer + Gyro Sensor
> - 96Boards compatible low-speed and high-speed connectors [1]
> - 7 x LED indicators (4 user, 2 radio, 1 power)
> - Buttons for power, volume up/down, force USB boot
> - 3 x Dip switches
>
> On-Board PMICs:
> - PMK8550 2.1
> - PM8550 2.0
> - PM8550VS 2.0 x4
> - PM8550VE 2.0
> - PM8550B 2.0
> - PMR735D 2.0
> - PM8010 1.1 x2
>
> Product Page: [2]
>
> [1] https://www.96boards.org/specifications/
> [2] https://www.thundercomm.com/product/qualcomm-rb5-gen-2-development-kit
>
> The default msi-map from sm8550.dtsi is deleted for both pcie0 and
> pcie1. The QPS615 PCIe switch on each port exposes more than two
> devices (1 USP + 3 DSPs), but Gunyah currently limits ITS device
> mappings to two per root complex to save memory. With msi-map
> present, the ITS MAPD command times out.
>
> Deleting msi-map causes the DWC controller to fall back to its
> internal iMSI-RX module, which handles MSIs without this limitation.
>
> Signed-off-by: Joe Sandom <jsandom@axon.com>
> ---
> arch/arm64/boot/dts/qcom/Makefile | 1 +
> arch/arm64/boot/dts/qcom/qcs8550-rb5gen2.dts | 1573 ++++++++++++++++++++++++++
> 2 files changed, 1574 insertions(+)
>
> +
> + lt9611_1v2: lt9611-regulator-1v2 {
I think that comes from the RB5 or something similar. Could you please
rename the nodes to follow the pattern used by other regulators
(regulator-foo-bar) and place these supplies accordingly.
> + compatible = "regulator-fixed";
> + regulator-name = "LT9611_1V2";
> +
> + regulator-min-microvolt = <1200000>;
> + regulator-max-microvolt = <1200000>;
> +
> + vin-supply = <&vreg_l14b_3p2>;
> + };
> +
> + lt9611_3v3: lt9611-regulator-3v3 {
> + compatible = "regulator-fixed";
> + regulator-name = "LT9611_3V3";
> +
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> +
> + vin-supply = <&vreg_l14b_3p2>;
> + };
> +
> + pmic-glink {
> + compatible = "qcom,sm8550-pmic-glink", "qcom,pmic-glink";
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + connector@0 {
> + compatible = "usb-c-connector";
> + reg = <0>;
> + power-role = "dual";
> + data-role = "dual";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + pmic_glink_hs_in: endpoint {
> + remote-endpoint = <&usb_1_dwc3_hs>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + pmic_glink_ss_in: endpoint {
> + remote-endpoint = <&redriver_usb_con_ss>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + pmic_glink_sbu_in: endpoint {
> + remote-endpoint = <&redriver_usb_con_sbu>;
> + };
> + };
> + };
> + };
> + };
> +
> + pcie_upd_1p05: regulator-pcie-upd-1p05 {
> + compatible = "regulator-fixed";
> + regulator-name = "PCIE_UPD_1P05";
> + gpio = <&tlmm 179 GPIO_ACTIVE_HIGH>;
> + vin-supply = <&vdd_ntn_0p9>;
> + regulator-min-microvolt = <1050000>;
> + regulator-max-microvolt = <1050000>;
> + enable-active-high;
> + regulator-enable-ramp-delay = <5000>;
> + pinctrl-0 = <&upd_1p05_en>;
> + pinctrl-names = "default";
> + };
> +
> + pcie_upd_3p3: regulator-pcie-upd-3p3 {
> + compatible = "regulator-fixed";
> + regulator-name = "PCIE_UPD_3P3";
> + gpio = <&tlmm 13 GPIO_ACTIVE_HIGH>;
> + vin-supply = <&pcie_upd_1p05>;
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + enable-active-high;
> + regulator-enable-ramp-delay = <10000>;
> + pinctrl-0 = <&upd_3p3_en>;
> + pinctrl-names = "default";
> + };
> +
> + vdd_ntn_0p9: regulator-vdd-ntn-0p9 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDD_NTN_0P9";
> + vin-supply = <&vdd_ntn_1p8>;
> + regulator-min-microvolt = <899400>;
> + regulator-max-microvolt = <899400>;
> + regulator-enable-ramp-delay = <4300>;
> + };
> +
> + vdd_ntn_1p8: regulator-vdd-ntn-1p8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDD_NTN_1P8";
> + gpio = <&tlmm 67 GPIO_ACTIVE_HIGH>;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + enable-active-high;
> + pinctrl-0 = <&ntn0_en>;
> + pinctrl-names = "default";
> + regulator-enable-ramp-delay = <10000>;
> + };
> +
> + vdd_ntn1_0p9: regulator-vdd-ntn1-0p9 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDD_NTN1_0P9";
> + vin-supply = <&vdd_ntn1_1p8>;
> + regulator-min-microvolt = <899400>;
> + regulator-max-microvolt = <899400>;
> + regulator-enable-ramp-delay = <4300>;
> + };
> +
> + vdd_ntn1_1p8: regulator-vdd-ntn1-1p8 {
> + compatible = "regulator-fixed";
> + regulator-name = "VDD_NTN1_1P8";
> + gpio = <&tlmm 42 GPIO_ACTIVE_HIGH>;
> + regulator-min-microvolt = <1800000>;
> + regulator-max-microvolt = <1800000>;
> + enable-active-high;
> + pinctrl-0 = <&ntn1_en>;
> + pinctrl-names = "default";
> + regulator-enable-ramp-delay = <10000>;
> + };
> +
> + vph_pwr: regulator-vph-pwr {
> + compatible = "regulator-fixed";
> + regulator-name = "vph_pwr";
> + regulator-min-microvolt = <3700000>;
> + regulator-max-microvolt = <3700000>;
> +
> + regulator-always-on;
> + regulator-boot-on;
> + };
> +
> + sound {
> + compatible = "qcom,sm8550-sndcard", "qcom,sm8450-sndcard";
> + model = "QCS8550-RB5Gen2";
> + audio-routing = "SpkrLeft IN", "WSA_SPK1 OUT",
> + "SpkrRight IN", "WSA_SPK2 OUT",
> + "VA DMIC0", "vdd-micb",
> + "VA DMIC1", "vdd-micb";
> +
> + wsa-dai-link {
> + link-name = "WSA Playback";
> +
> + cpu {
> + sound-dai = <&q6apmbedai WSA_CODEC_DMA_RX_0>;
> + };
> +
> + codec {
codec < cpu
> + sound-dai = <&left_spkr>, <&right_spkr>,
> + <&swr0 0>, <&lpass_wsamacro 0>;
> + };
> +
> + platform {
> + sound-dai = <&q6apm>;
> + };
> + };
> +
> + va-dai-link {
> + link-name = "VA Capture";
> +
> + cpu {
> + sound-dai = <&q6apmbedai VA_CODEC_DMA_TX_0>;
> + };
> +
> + codec {
> + sound-dai = <&lpass_vamacro 0>;
> + };
> +
> + platform {
> + sound-dai = <&q6apm>;
> + };
> + };
> + };
> +
> +
> +&i2c_hub_3_gpio {
> + clock-frequency = <400000>;
> +
> + status = "okay";
> +
> + lt9611_codec: hdmi-bridge@2b {
> + compatible = "lontium,lt9611uxc";
> + reg = <0x2b>;
> +
> + interrupts-extended = <&tlmm 40 IRQ_TYPE_EDGE_FALLING>;
> + reset-gpios = <&tlmm 7 GPIO_ACTIVE_HIGH>;
> +
> + vdd-supply = <<9611_1v2>;
> + vcc-supply = <<9611_3v3>;
> +
> + pinctrl-0 = <<9611_irq_pin <9611_rst_pin>;
pinctrl-0 = <<9611_irq_pin>, <<9611_rst_pin>;
> + pinctrl-names = "default";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + lt9611_a: endpoint {
> + remote-endpoint = <&mdss_dsi0_out>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> +
> + lt9611_out: endpoint {
> + remote-endpoint = <&hdmi_con>;
> + };
> + };
> + };
> + };
> +};
> +
> +
> +&remoteproc_adsp {
> + firmware-name = "qcom/qcs8550/adsp.mbn",
> + "qcom/qcs8550/adsp_dtb.mbn";
Sound and GPU firmware is under qcom/sm8550/. Let's don't multiply
entities and keep all firmware in the same subdir (including the IPA
firmware too).
> + status = "okay";
> +};
> +
> +&remoteproc_cdsp {
> + firmware-name = "qcom/qcs8550/cdsp.mbn",
> + "qcom/qcs8550/cdsp_dtb.mbn";
> + status = "okay";
> +};
> +
> +&remoteproc_mpss {
> + firmware-name = "qcom/qcs8550/modem.mbn",
> + "qcom/qcs8550/modem_dtb.mbn";
> + status = "okay";
> +};
> +
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 20/21] dt-bindings: gpio: describe Waveshare GPIO controller
From: Dmitry Baryshkov @ 2026-04-13 0:56 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Linus Walleij, Bartosz Golaszewski, dri-devel, devicetree,
linux-kernel, linux-gpio, Riccardo Mereu
In-Reply-To: <20260412-diligent-ginger-flamingo-f5059d@quoll>
On Sun, Apr 12, 2026 at 11:48:46AM +0200, Krzysztof Kozlowski wrote:
> On Sat, Apr 11, 2026 at 03:10:40PM +0300, Dmitry Baryshkov wrote:
> > The Waveshare DSI TOUCH family of panels has separate on-board GPIO
> > controller, which controls power supplies to the panel and the touch
> > screen and provides reset pins for both the panel and the touchscreen.
> > Also it provides a simple PWM controller for panel backlight.
> >
> > Add bindings for these GPIO controllers. As overall integration might be
> > not very obvious (and it differs significantly from the bindings used by
> > the original drivers), provide complete example with the on-board
> > regulators and the DSI panel.
> >
> > Tested-by: Riccardo Mereu <r.mereu@arduino.cc>
>
> You cannot test a binding, it is not possible. Otherwise explain me how
> did you copy it to the device and what sort of device runs YAML.
I'll drop it from the next iteration.
>
> The tag was given here explicitly, so I really do not understand this. I
> could imagine tags coming from a reply to the cover letter, but adding
> tag here? That's just fake test.
>
> Best regards,
> Krzysztof
>
--
With best wishes
Dmitry
^ 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