* Re: [PATCH v4 05/13] dt-bindings: mfd: s2mps11: add documentation for S2MU005 PMIC
From: Krzysztof Kozlowski @ 2026-04-15 14:27 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <DHTSO9L6YZTQ.WYM9ERXBGNGB@disroot.org>
On 15/04/2026 16:22, Kaustabh Chakraborty wrote:
> On 2026-04-15 09:17 +02:00, Krzysztof Kozlowski wrote:
>> On Tue, Apr 14, 2026 at 12:02:57PM +0530, Kaustabh Chakraborty wrote:
>>>
>>> clocks:
>>> $ref: /schemas/clock/samsung,s2mps11.yaml
>>> description:
>>> Child node describing clock provider.
>>>
>>> + charger:
>>> + $ref: /schemas/power/supply/samsung,s2mu005-charger.yaml
>>> + description:
>>> + Child node describing battery charger device.
>>> +
>>> + extcon:
>>
>> You got comment to drop extcon naming. If this stays, it's muic for
>> example.
>>
>>> + $ref: /schemas/extcon/samsung,s2mu005-muic.yaml
>>> + description:
>>> + Child node describing extcon device.
>>> +
>>> + flash:
>>> + $ref: /schemas/leds/samsung,s2mu005-flash.yaml
>>> + description:
>>> + Child node describing flash LEDs.
>>> +
>>
>> Please make it a separate binding file.
>
> What do you mean by that?
I mean, S2MU005 should go to its own file.
>
>>
>>> interrupts:
>>> maxItems: 1
>>>
>>> @@ -43,6 +59,11 @@ properties:
>>> description:
>>> List of child nodes that specify the regulators.
>>>
>>> + rgb:
>>
>> led
>
> Well flash ones are also LEDs. Would you rather have `flash { ... }` and
> `rgb { ... }` under `led { ... }` instead?
There is no approved name "rgb" for LEDs. What is the name for flash LEDs?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 1/3] riscv: add UltraRISC SoC family Kconfig support
From: Conor Dooley @ 2026-04-15 14:28 UTC (permalink / raw)
To: Jia Wang
Cc: Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti,
Lorenzo Pieralisi, Krzysztof Wilczyński,
Manivannan Sadhasivam, Rob Herring, Bjorn Helgaas, Jingoo Han,
Xincheng Zhang, Krzysztof Kozlowski, Conor Dooley, linux-riscv,
linux-kernel, linux-pci, devicetree
In-Reply-To: <20260415-ultrarisc-pcie-v3-1-73f06e972616@ultrarisc.com>
[-- Attachment #1: Type: text/plain, Size: 934 bytes --]
On Wed, Apr 15, 2026 at 03:21:17PM +0800, Jia Wang wrote:
> The first SoC in the UltraRISC series is UR-DP1000, containing octa
> UltraRISC CP100 cores.
>
> Signed-off-by: Jia Wang <wangjia@ultrarisc.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
> ---
> arch/riscv/Kconfig.socs | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index d621b85dd63b..0b4d06a7b4bf 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -84,6 +84,12 @@ config ARCH_THEAD
> help
> This enables support for the RISC-V based T-HEAD SoCs.
>
> +config ARCH_ULTRARISC
> + bool "UltraRISC RISC-V SoCs"
> + help
> + This enables support for UltraRISC SoC platform hardware,
> + including boards based on the UR-DP1000.
> +
> config ARCH_VIRT
> bool "QEMU Virt Machine"
> select POWER_RESET
>
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v2 02/11] ASoC: meson: aiu-encoder-i2s: use gx_iface and gx_stream structures
From: Jerome Brunet @ 2026-04-15 14:28 UTC (permalink / raw)
To: Mark Brown
Cc: Valerio Setti, Liam Girdwood, Jaroslav Kysela, Takashi Iwai,
Neil Armstrong, Kevin Hilman, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-sound,
linux-arm-kernel, linux-amlogic, devicetree
In-Reply-To: <58d1df89-7c97-4e2f-af15-93d1f7bce5a7@sirena.org.uk>
On mar. 14 avril 2026 at 17:13, Mark Brown <broonie@kernel.org> wrote:
> On Sat, Apr 11, 2026 at 04:57:27PM +0200, Valerio Setti wrote:
>
>> @@ -200,13 +200,17 @@ static int aiu_encoder_i2s_hw_params(struct snd_pcm_substream *substream,
>
>> - aiu_encoder_i2s_divider_enable(component, true);
>> + ret = gx_stream_set_cont_clocks(ts, iface->fmt);
>> + if (ret)
>> + dev_err(dai->dev, "failed to apply continuous clock setting\n");
>> +
>> + aiu_encoder_i2s_divider_enable(component, 1);
>
> If we're checking the error here we should probably return it as well.
> Including the error code in the log message is also generally helpful.
>
>> @@ -214,16 +218,20 @@ static int aiu_encoder_i2s_hw_params(struct snd_pcm_substream *substream,
>> static int aiu_encoder_i2s_hw_free(struct snd_pcm_substream *substream,
>> struct snd_soc_dai *dai)
>> {
>> + struct gx_stream *ts = snd_soc_dai_get_dma_data(dai, substream);
>> struct snd_soc_component *component = dai->component;
>>
>> - aiu_encoder_i2s_divider_enable(component, false);
>> -
>> - return 0;
>> + /* This is the last substream open and that is going to be closed. */
>> + if (snd_soc_dai_active(dai) <= 1)
>> + aiu_encoder_i2s_divider_enable(component, 0);
>> + return gx_stream_set_cont_clocks(ts, 0);
>> }
>
> Note that we only hw_free() if we preprared, but we enable in
> hw_params().
Huh interresting, I had not thought of that. Valerio and I discussed the
clock part a lot for this rework. It is the crux since since the
interface and clock setting lives in the AIU subsys but serves both the
AIU and AUDIN subsys.
Valerio maybe you could keep function above just to set the rate, but
enabling the clocks through a DAPM supply widget ? This is kind of what
the AXG is doing.
what do you think ?
(actually in the AXG the each formatter widget call CCF
clk_prepare_enable() but a supply widget poking the register would do
the same thing)
>
>> @@ -284,6 +295,8 @@ static int aiu_encoder_i2s_set_sysclk(struct snd_soc_dai *dai, int clk_id,
>> if (ret)
>> dev_err(dai->dev, "Failed to set sysclk to %uHz", freq);
>>
>> + aiu->i2s.iface.mclk_rate = freq;
>> +
>> return ret;
>> }
>
> This means we store the new rate even if the set above failed.
--
Jerome
^ permalink raw reply
* Re: [PATCH 0/5] Exynos850 APM-to-AP mailbox support
From: Alexey Klimov @ 2026-04-15 14:32 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Sylwester Nawrocki, Chanwoo Choi, Alim Akhtar, Sam Protsenko,
Michael Turquette, Stephen Boyd, Rob Herring, Conor Dooley,
Tudor Ambarus, Jassi Brar, Krzysztof Kozlowski, Peter Griffin,
linux-samsung-soc, linux-arm-kernel, linux-clk, devicetree,
linux-kernel
In-Reply-To: <5d645bb0-22cd-4e96-b8b6-15c4bb83d87d@kernel.org>
On Thu Apr 2, 2026 at 7:43 AM BST, Krzysztof Kozlowski wrote:
> On 02/04/2026 04:19, Alexey Klimov wrote:
>> On Sat Mar 21, 2026 at 10:44 AM GMT, Krzysztof Kozlowski wrote:
>>> On Fri, Mar 20, 2026 at 09:15:12PM +0000, Alexey Klimov wrote:
>>>> Hi all,
>>>>
>>>> This patch series introduces support for the APM-to-AP mailbox on the
>>>> Exynos850 SoC. This mailbox is required for communicating with the APM
>>>> co-processor using ACPM.
>>>>
>>>> The Exynos850 mailbox operates similarly to the existing gs101
>>>> implementation, but the register offsets and IRQ mask bits differ.
>>>> This series abstracts these differences into platform-specific data
>>>> structures matched via the device tree.
>>>>
>>>> Also, it requires APM-to-AP mailbox clock in CMU_APM block.
>>>>
>>>> In theory this can be split into two series with correct dependecies:
>>>> device tree node requires clock changes to be merged. The suggestion
>>>> is to let this go through Samsung SoC tree with corresponding acks
>>>> if it is okay.
>>>
>>> I don't understand why this cannot be split into two seris
>>> *practically*. What is exactly the dependency between mailbox and DTS,
>>> that it had to be combined here?
>>
>> Do you suggest to send 3 single patches with proper dependencies
>> description? DT bindings change first, then mailbox change that specifically
>> depends on dt-bindings change and then dts update (which will depend on both)?
>>
>> I thought that mbox driver change depends implicitly on bindings update?
>
> Please don't answer to a question with a question. Actually three
> questions. If you cannot give argument why there is a dependency, feels
> to me like you send something you do not understand.
Sorry. You're right on the first part. Couldn't say anything about last part.
So I saw series where DTS enablement changes are included in the series
after changes in drivers were introduced. I guess it is more preferred
to split out DTS changes (also considering that kernel without these
changes should be able to boot with new DTS and vice versa). I can split
out DTS change(s), yes. There should/must be no dependency. Thanks.
Best regards,
Alexey
^ permalink raw reply
* Re: [PATCH v4 04/13] dt-bindings: power: supply: document Samsung S2M series PMIC charger device
From: Krzysztof Kozlowski @ 2026-04-15 14:39 UTC (permalink / raw)
To: Kaustabh Chakraborty
Cc: Lee Jones, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, MyungJoo Ham, Chanwoo Choi, Sebastian Reichel,
André Draszik, Alexandre Belloni, Jonathan Corbet,
Shuah Khan, Nam Tran, Łukasz Lebiedziński, linux-leds,
devicetree, linux-kernel, linux-pm, linux-samsung-soc, linux-rtc,
linux-doc
In-Reply-To: <DHTS9H2EIM2D.2TC17F9WBOOR1@disroot.org>
On 15/04/2026 16:03, Kaustabh Chakraborty wrote:
> On 2026-04-15 09:18 +02:00, Krzysztof Kozlowski wrote:
>> On Tue, Apr 14, 2026 at 12:02:56PM +0530, Kaustabh Chakraborty wrote:
>>> +description: |
>>> + The Samsung S2M series PMIC battery charger manages power interfacing
>>> + of the USB port. It may supply power, as done in USB OTG operation
>>> + mode, or it may accept power and redirect it to the battery fuelgauge
>>> + for charging.
>>> +
>>> + This is a part of device tree bindings for S2M and S5M family of Power
>>> + Management IC (PMIC).
>>> +
>>> + See also Documentation/devicetree/bindings/mfd/samsung,s2mps11.yaml for
>>> + additional information and example.
>>> +
>>> +allOf:
>>> + - $ref: power-supply.yaml#
>>> +
>>> +properties:
>>> + compatible:
>>> + enum:
>>> + - samsung,s2mu005-charger
>>> +
>>> + port:
>>> + $ref: /schemas/graph.yaml#/properties/port
>>
>> That port is internal part of the device, thus should be dropped which
>> leaves you with only one property - monitored battery - and therefore
>> fold the node into the parent node.
>
> And that monitored-battery belongs to power-supply.yaml. Do I then
> include the allOf block in the mfd/samsung,s2mps11.yaml under the
> s2mu005 compatible?
allOf does not go under the compatible. The entire device schema should
have $ref to power-supply.yaml, just like many other devices have that
or different $ref.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] docs: dt: writing-bindings: Extend compatible fallbacks guideline
From: Conor Dooley @ 2026-04-15 14:46 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, devicetree,
linux-kernel
In-Reply-To: <20260415082113.22775-2-krzysztof.kozlowski@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 2024 bytes --]
On Wed, Apr 15, 2026 at 10:21:14AM +0200, Krzysztof Kozlowski wrote:
> Extend the guidelines when to use fallback compatibles to cover to
> common review responses. Devices are most likely compatible and should
> use fallbacks when having:
>
> 1. Compatible programming interface, meaning one is a subset, and Linux
> device drivers can use the subset to correctly match/bind and still
> operate with the subset features.
>
> 2. Device variant discovery through some means, like registers.
>
> Devices are incompatible and fallback is not suitable when that
> fallback cannot be used by the drivers to match/bind.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
> Documentation/devicetree/bindings/writing-bindings.rst | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/writing-bindings.rst b/Documentation/devicetree/bindings/writing-bindings.rst
> index 667816dd7d50..03e29e2d50af 100644
> --- a/Documentation/devicetree/bindings/writing-bindings.rst
> +++ b/Documentation/devicetree/bindings/writing-bindings.rst
> @@ -53,7 +53,12 @@ Properties
> - DON'T use wildcards or device-family names in compatible strings.
>
> - DO use fallback compatibles when devices are the same as or a superset of
> - prior implementations.
> + prior implementations. Fallback compatibles are applicable especially
> + when sharing a programming interface or when able to discover the
> + variants.
> +
> + - DON'T add fake fallback compatibles when software cannot use such to match
> + and bind to a device, and still operate correctly.
>
> - DO add new compatibles in case there are new features or bugs.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
- DO use the commit message explain why devices that may appear
compatible in a diff (e.g. no differences in property use) but
are not compatible, are not compatible.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/1] dt-bindings: usb: Fix EIC7700 USB reset's issue
From: Conor Dooley @ 2026-04-15 14:47 UTC (permalink / raw)
To: caohang
Cc: gregkh, robh, krzk+dt, conor+dt, Thinh.Nguyen, p.zabel,
linux-kernel, linux-usb, devicetree, ningyu, linmin,
pinkesh.vaghela
In-Reply-To: <20260415064238.1784-1-caohang@eswincomputing.com>
[-- Attachment #1: Type: text/plain, Size: 956 bytes --]
On Wed, Apr 15, 2026 at 02:42:38PM +0800, caohang@eswincomputing.com wrote:
> From: Hang Cao <caohang@eswincomputing.com>
>
> The EIC7700 USB requires a USB PHY reset operation; otherwise, the USB
> will not work. The reason why the USB driver that was applied can work
> properly is that the USB PHY has already been reset in ESWIN's U-Boot.
>
> However, the proper functioning of the USB driver should not be dependent
> on the bootloader. Therefore, it is necessary to incorporate the USB PHY
> reset signal into the DT bindings.
>
> This patch does not introduce any backward incompatibility since the dts
> is not upstream yet. As array of reset operations are used in the driver,
> no modifications to the USB controller driver are needed.
>
> Fixes: c640a4239db5 ("dt-bindings: usb: Add ESWIN EIC7700 USB controller")
> Signed-off-by: Hang Cao <caohang@eswincomputing.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH RFC v2 00/11] Add support for AUDIN driver in Amlogic GXBB
From: Jerome Brunet @ 2026-04-15 14:49 UTC (permalink / raw)
To: Valerio Setti
Cc: Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Neil Armstrong, Kevin Hilman, Martin Blumenstingl, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-kernel, linux-sound,
linux-arm-kernel, linux-amlogic, devicetree
In-Reply-To: <20260411-audin-rfc-v2-0-4c8a6ec5fcab@baylibre.com>
On sam. 11 avril 2026 at 16:57, Valerio Setti <vsetti@baylibre.com> wrote:
> This series adds support for I2S audio input (AUDIN) on the Amlogic GXBB
> platform.
>
> It has been largely reshaped compared to what proposed in v1. Instead of
> adding an HACK commit to allow AIU to export its clock so that also
> AUDIN can control it, now the design closely follows what was implemented
> in the Meson AXG platform. "aiu-encoder-i2s" becomes the shared interface
> for playback/capture and it controls pins and clocks; data formatting
> is implemented in formatters which are named "aiu-formatter-i2s" and
> "audin-decoder-i2s" [1].
> Formatters are DAPM widgets which are dynamically attached/detached to
> the streams when the latters starts/stop, respectively.
>
> As of now only I2S input is supported, because it's the only one
> I could physically test in my setup, but other input sources (ex: SPDIF)
> are also allowed according to the SOC's manual and can be added in the
> future.
> This series was tested on an OdroidC2 board (Amlogic S905 SOC) with an
> NXP SGTL5000 codec connected to its I2S input port.
>
> Since this work brings GX platform very close to the AXG one, once this
> series is accepted, follow up work will be done in order to unify
> GX and AXG formatters so as to minimize the number of implementations.
>
> The series a bit long and it includes changes to drivers, dt-bindings and
> device-tree. Of course this only happens because this is an RFC and I
> wanted to give a full overview of what will be the final design. If no
> objection is raised, this patch series will be split into 3: one for
> reshaping AIU and introducing formatters, one to add AUDIN driver and its
> dt-bindings, one for the device-tree changes.
>
> [1]: Different naming for the aiu part is related to the fact that
> "aiu-encoder-i2s" is already used for the interface and the goal
> of this series was to introduce the minimum amount of changes that allow
> I2S capture to work. Renaming can be implemented in the future as follow up
> activity.
Thanks a lot for this awesome work Valerio. I know this was a lot of
effort. With Mark and Krzysztof comments addressed
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
For the next revision, I think you can drop the RFC tag and split the
series.
You have spent a lot of time studying the existing amlogic audio driver
support. If you feel like it, you could add yourself as a reviewer or
maintainer of the Amlogic audio drivers. :)
>
> v1 -> v2:
> - Reshaped design so that GX platforms will use the same design
> pattern of AXG ones. This helped removing the need for an HACK commit.
>
> --
> 2.39.5
>
> ---
> Valerio Setti (11):
> ASoC: meson: gx: add gx-formatter and gx-interface
> ASoC: meson: aiu-encoder-i2s: use gx_iface and gx_stream structures
> ASoC: meson: aiu: introduce I2S output formatter
> ASoC: meson: aiu: use aiu-formatter-i2s to format I2S output data
> ASoC: dt-bindings: amlogic: add schema for audin-formatter and audin-toddr
> ASoC: meson: gx: add AUDIN I2S Decoder driver
> ASoC: meson: gx: add AUDIN FIFO driver
> ASoC: meson: aiu: add I2S Capture DAI
> ASoC: meson: gx-card: add support for AUDIN FIFO
> arm64: dts: amlogic: gx: add nodes for AUDIN decoder and FIFO
> arm64: dts: amlogic: odroid-c2: add support for I2S audio input
>
> .../sound/amlogic,meson-gx-audin-decoder-i2s.yaml | 49 +++
> .../sound/amlogic,meson-gx-audin-fifo.yaml | 63 +++
> arch/arm64/boot/dts/amlogic/meson-gx.dtsi | 32 ++
> .../arm64/boot/dts/amlogic/meson-gxbb-odroidc2.dts | 34 ++
> arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 26 ++
> sound/soc/meson/Kconfig | 17 +
> sound/soc/meson/Makefile | 6 +
> sound/soc/meson/aiu-encoder-i2s.c | 219 +++++++----
> sound/soc/meson/aiu-formatter-i2s.c | 106 +++++
> sound/soc/meson/aiu.c | 37 +-
> sound/soc/meson/aiu.h | 4 +
> sound/soc/meson/audin-decoder-i2s.c | 218 +++++++++++
> sound/soc/meson/audin-fifo.c | 432 +++++++++++++++++++++
> sound/soc/meson/gx-card.c | 14 +-
> sound/soc/meson/gx-formatter.c | 304 +++++++++++++++
> sound/soc/meson/gx-formatter.h | 47 +++
> sound/soc/meson/gx-interface.h | 50 +++
> 17 files changed, 1567 insertions(+), 91 deletions(-)
> ---
> base-commit: 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f
> change-id: 20260410-audin-rfc-243bcbf95e43
>
> Best regards,
--
Jerome
^ permalink raw reply
* Re: [PATCH v5 2/4] ASoC: codecs: Add TAS67524 quad-channel audio amplifier driver
From: Wang, Sen @ 2026-04-15 14:50 UTC (permalink / raw)
To: Mark Brown
Cc: linux-sound, lgirdwood, robh, krzk+dt, conor+dt, devicetree,
perex, tiwai, shenghao-ding, kevin-lu, baojun.xu, niranjan.hy,
l-badrinarayanan, devarsht, v-singh1, linux-kernel
In-Reply-To: <dd740c4c-e0bc-4140-961d-6c6c604a594d@sirena.org.uk>
On 4/14/2026 1:08 PM, Mark Brown wrote:
> On Fri, Apr 10, 2026 at 12:56:47PM -0500, Sen Wang wrote:
>> On 4/10/26 09:02, Mark Brown wrote:
>
>>> This looks mostly good, but one issue I see is that AFAICT we only stop
>>> fault_check_work during runtime suspsend - if runtime PM is disabled, or
>>> if the driver is removed, the work will be left running.
>> (snip)
>> Do you think the DAPM fallback would suffice, or is the current approach
>> (poll until removal) acceptable given the hardware behavior? Any other
>> suggestions would be greatly appreciated!
>
> It's fine to keep on checking for faults if there's faults that can be
> generated, the only reason I mentioned runtime PM there was that it's
> the only thing that stops the polling in the current version. So long
> as everything is stopped when the device is removed it's fine. No need
> for a DAPM fallback.
Understood, will make sure services (check_work/IRQ) are canceled when
driver is removed for the next version.
Best,
Sen Wang
^ permalink raw reply
* Re: [PATCH v7 0/8] Add support for handling PCIe M.2 Key E connectors in devicetree
From: Herve Codina @ 2026-04-15 14:56 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Andy Shevchenko, Manivannan Sadhasivam, Manivannan Sadhasivam,
Rob Herring, Greg Kroah-Hartman, Jiri Slaby, Nathan Chancellor,
Nicolas Schier, Hans de Goede, Ilpo Järvinen, Mark Pearson,
Derek J. Clark, Krzysztof Kozlowski, Conor Dooley,
Marcel Holtmann, Luiz Augusto von Dentz, Bartosz Golaszewski,
Bartosz Golaszewski, linux-serial, linux-kernel, linux-kbuild,
platform-driver-x86, linux-pci, devicetree, linux-arm-msm,
linux-bluetooth, linux-pm, Stephan Gerhold, Dmitry Baryshkov,
linux-acpi, Hans de Goede, Bartosz Golaszewski, Luca Ceresoli
In-Reply-To: <CAGXv+5EPA29G-fsH=wWOD8AK6TZFezFhsE0NHPYj_Pt3nT+d_w@mail.gmail.com>
Hi Chen, all,
...
>
> I'm not arguing for a even more generic "M.2" connector. The "key" is
> already described in the compatible. I'm saying we should have some way
> of describing the individual interfaces (PCIe, SDIO, USB, UART, I2S, I2C)
> on the connector so further nodes or properties can be attached to them,
> either with overlays or dynamically within the kernel. Right now the
> are only described as individual ports, but we can't actually tie a
> device to a OF graph port.
>
> But maybe I'm overthinking the representation part. AFAICT for Qualcomm's
> UART-based BT bit part, Mani just had the driver create a device node
> under the UART (by traversing the OF graph to find the UART). If that's
> the desired way then the connector binding should mention it. And that
> works for me. But I think it's messier and also we're missing an
> opportunity to make the M.2 connector a standardized attachment point
> for overlays.
>
> Mani, could you also chime in a bit on what you envisioned?
>
> (Added Luca from Bootlin to CC, as I think there are parallels to the
> "Hotplug of Non-discoverable Hardware" work)
>
Related to "Hotplug of Non-discoverable Hardware",
I would add entries for busses in the connector without using an OF graph.
For I2C and later SPI, this was is done.
You already have an i2c-parent property but no node where an i2c device
can be added.
The last discussion related to hotplug, connectors and DT led to the RFC
series [1].
It is a huge series. The last patch give a real example of representation:
https://lore.kernel.org/all/20260112142009.1006236-78-herve.codina@bootlin.com/
In your case I would see some thing like:
connector {
compatible = "pcie-m2-e-connector";
vpcie3v3-supply = <&vreg_wcn_3p3>;
vpcie1v8-supply = <&vreg_l15b_1p8>;
/*
* If those GPIOs have to be used by components available in
* the connected board, a Nexus node should be used.
*/
w-disable1-gpios = <&tlmm 115 GPIO_ACTIVE_LOW>;
w-disable2-gpios = <&tlmm 116 GPIO_ACTIVE_LOW>;
viocfg-gpios = <&tlmm 117 GPIO_ACTIVE_HIGH>;
uart-wake-gpios = <&tlmm 118 GPIO_ACTIVE_LOW>;
sdio-wake-gpios = <&tlmm 119 GPIO_ACTIVE_LOW>;
sdio-reset-gpios = <&tlmm 120 GPIO_ACTIVE_LOW>;
conn-i2c {
i2c-parent = <&i2c0>;
/*
* Here i2c devices available on the board
* connected to the connector can be described.
*/
};
/* Same kind to description for other busses */
conn-pcie {
pci-parent = <&xxxxx>;
/*
* The PCIe bus has abilities to discover devices.
* Not sure this node is needed.
*
* If a PCI device need a DT description to describe
* stuffs behind the device, what has been done for LAN966x
* could be re-used [2] and [3]
*/
};
conn_uart {
uart-parent = <&uart-ctrl>;
/* uart child (maybe a serdes) should be describe here
};
...
};
Of course, some DT symbols need to be exported in order to have them usable from
the DT describing the connected board.
This notion of exported symbol is not yet available upstream and is the purpose of
the RFC series [1].
[1] https://lore.kernel.org/all/20260112142009.1006236-1-herve.codina@bootlin.com/
[2] https://elixir.bootlin.com/linux/v7.0/source/drivers/misc/lan966x_pci.c
[3] https://elixir.bootlin.com/linux/v7.0/source/drivers/misc/lan966x_pci.dtso
Feel free to ask for more specific question if needed.
Best regards,
Hervé
>
> Thanks
> ChenYu
>
>
> > > The latter part is solvable, but we likely need child nodes under the
> > > connector for the different interfaces. Properties that make sense for
> > > one type might not make sense for another.
> > >
> > > P.S. We could also just add child device nodes under the controller to
> > > put the generic properties, but that's splitting the description into
> > > multiple parts. Let's not go there if at all possible.
> >
> > --
> > With Best Regards,
> > Andy Shevchenko
> >
> >
--
Hervé Codina, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-bindings: gpio: Add EIO GPIO compatible to gpio-zynq
From: Conor Dooley @ 2026-04-15 15:01 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-kernel, git, shubhrajyoti.datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260415105628.957689-3-shubhrajyoti.datta@amd.com>
[-- Attachment #1: Type: text/plain, Size: 1784 bytes --]
On Wed, Apr 15, 2026 at 04:26:27PM +0530, Shubhrajyoti Datta wrote:
> EIO (Extended IO) is a GPIO block found on xa2ve3288 silicon..
Why does the compatible have a "1.0" when it is in silicon?
Why doesn't the compatible contain "xa2ve3288"?
Why is this device not compatible with existing ones, since
gpio-lines-names appears to be the sole difference?
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
> ---
>
> Changes in v2:
> - Add description of EIO block in the dt-bindings patch
>
> .../devicetree/bindings/gpio/gpio-zynq.yaml | 14 +++++++++++++-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> index 30a7f836c341..1ca067217509 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml
> @@ -12,6 +12,7 @@ maintainers:
> properties:
> compatible:
> enum:
> + - xlnx,eio-gpio-1.0
> - xlnx,pmc-gpio-1.0
> - xlnx,versal-gpio-1.0
> - xlnx,zynq-gpio-1.0
> @@ -30,7 +31,7 @@ properties:
>
> gpio-line-names:
> description: strings describing the names of each gpio line
> - minItems: 58
> + minItems: 52
> maxItems: 174
>
> interrupt-controller: true
> @@ -89,6 +90,17 @@ allOf:
> minItems: 116
> maxItems: 116
>
> + - if:
> + properties:
> + compatible:
> + enum:
> + - xlnx,eio-gpio-1.0
> + then:
> + properties:
> + gpio-line-names:
> + minItems: 52
> + maxItems: 52
> +
> required:
> - compatible
> - reg
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/3] dt-bindings: gpio: zynq: Sort compatible strings alphabetically
From: Conor Dooley @ 2026-04-15 15:01 UTC (permalink / raw)
To: Shubhrajyoti Datta
Cc: linux-kernel, git, shubhrajyoti.datta, Srinivas Neeli,
Michal Simek, Linus Walleij, Bartosz Golaszewski, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-gpio, devicetree,
linux-arm-kernel
In-Reply-To: <20260415105628.957689-2-shubhrajyoti.datta@amd.com>
[-- Attachment #1: Type: text/plain, Size: 264 bytes --]
On Wed, Apr 15, 2026 at 04:26:26PM +0530, Shubhrajyoti Datta wrote:
> Sort the compatible string alphabetically.
>
> Signed-off-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH v3 0/2] Configuring DMA threshold value for DW-MMC controllers
From: Kaustabh Chakraborty @ 2026-04-15 15:02 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jaehoon Chung, Shawn Lin, Krzysztof Kozlowski, Alim Akhtar
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, Kaustabh Chakraborty
In Samsung Exynos 7870 devices with Broadcom Wi-Fi, it has been observed
that small sized DMA transfers are unreliable and are not written
properly, which renders the cache incoherent.
Experimental observations say that DMA transfer sizes of somewhere
around 64 to 512 are intolerable. We must thus implement a mechanism to
fall back to PIO transfer in this case. One such approach, which this
series implements is allowing the DMA transfer threshold, which is
already defined in the driver, to be configurable.
Note that this patch is likely to be labelled as a workaround. These
smaller transfers seem to be successful from downstream kernels,
however efforts to figure out how so went in vain. It is also very
possible that the downstream Broadcom Wi-Fi SDIO driver uses PIO
transfers as well.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
Changes in v3:
- Move host->dma_threshold default to dw_mci_alloc_host() (Shawn Lin)
- Move comment to document struct dw_mci::dma_threshold (Shawn Lin)
- Link to v2: https://lore.kernel.org/r/20260414-dwmmc-dma-thr-v2-0-4058078f5361@disroot.org
Changes in v2:
- Remove dt-binding to set DMA threshold (Krzysztof Kozlowski)
- Add comment to describe struct dw_mci::dma_threshold (Shawn Lin)
- Set DMA threshold in Exynos 7870 DW-MMC driver (Krzysztof Kozlowski)
- Link to v1: https://lore.kernel.org/r/20260412-dwmmc-dma-thr-v1-0-75a2f658eee3@disroot.org
---
Kaustabh Chakraborty (2):
mmc: dw_mmc: implement option for configuring DMA threshold
mmc: dw_mmc: exynos: increase DMA threshold value for exynos7870
drivers/mmc/host/dw_mmc-exynos.c | 1 +
drivers/mmc/host/dw_mmc.c | 4 ++--
drivers/mmc/host/dw_mmc.h | 2 ++
3 files changed, 5 insertions(+), 2 deletions(-)
---
base-commit: 1c7cc4904160c6fc6377564140062d68a3dc93a0
change-id: 20260412-dwmmc-dma-thr-1090d8285ea7
Best regards,
--
Kaustabh Chakraborty <kauschluss@disroot.org>
^ permalink raw reply
* [PATCH v3 1/2] mmc: dw_mmc: implement option for configuring DMA threshold
From: Kaustabh Chakraborty @ 2026-04-15 15:02 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jaehoon Chung, Shawn Lin, Krzysztof Kozlowski, Alim Akhtar
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, Kaustabh Chakraborty
In-Reply-To: <20260415-dwmmc-dma-thr-v3-0-31014d36b6ee@disroot.org>
Some controllers, such as certain Exynos SDIO ones, are unable to
perform DMA transfers of small amount of bytes properly. Following the
device tree schema, implement the property to define the DMA transfer
threshold (from a hard coded value of 16 bytes) so that lesser number of
bytes can be transferred safely skipping DMA in such controllers. The
value of 16 bytes stays as the default for controllers which do not
define it. This value can be overridden by implementation-specific init
sequences.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
drivers/mmc/host/dw_mmc.c | 4 ++--
drivers/mmc/host/dw_mmc.h | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 20193ee7b73eb..3b4157f34d11f 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -40,7 +40,6 @@
SDMMC_INT_RESP_ERR | SDMMC_INT_HLE)
#define DW_MCI_ERROR_FLAGS (DW_MCI_DATA_ERROR_FLAGS | \
DW_MCI_CMD_ERROR_FLAGS)
-#define DW_MCI_DMA_THRESHOLD 16
#define DW_MCI_FREQ_MAX 200000000 /* unit: HZ */
#define DW_MCI_FREQ_MIN 100000 /* unit: HZ */
@@ -821,7 +820,7 @@ static int dw_mci_pre_dma_transfer(struct dw_mci *host,
* non-word-aligned buffers or lengths. Also, we don't bother
* with all the DMA setup overhead for short transfers.
*/
- if (data->blocks * data->blksz < DW_MCI_DMA_THRESHOLD)
+ if (data->blocks * data->blksz < host->dma_threshold)
return -EINVAL;
if (data->blksz & 3)
@@ -3185,6 +3184,7 @@ struct dw_mci *dw_mci_alloc_host(struct device *dev)
host = mmc_priv(mmc);
host->mmc = mmc;
host->dev = dev;
+ host->dma_threshold = 16;
return host;
}
diff --git a/drivers/mmc/host/dw_mmc.h b/drivers/mmc/host/dw_mmc.h
index 42e58be74ce09..f29d40158dc59 100644
--- a/drivers/mmc/host/dw_mmc.h
+++ b/drivers/mmc/host/dw_mmc.h
@@ -107,6 +107,7 @@ struct dw_mci_dma_slave {
* @ciu_clk: Pointer to card interface unit clock instance.
* @fifo_depth: depth of FIFO.
* @data_addr_override: override fifo reg offset with this value.
+ * @dma_threshold: data threshold value in bytes to carry out a DMA transfer.
* @wm_aligned: force fifo watermark equal with data length in PIO mode.
* Set as true if alignment is needed.
* @data_shift: log2 of FIFO item size.
@@ -163,6 +164,7 @@ struct dw_mci {
void __iomem *regs;
void __iomem *fifo_reg;
u32 data_addr_override;
+ u32 dma_threshold;
bool wm_aligned;
struct scatterlist *sg;
--
2.53.0
^ permalink raw reply related
* [PATCH v3 2/2] mmc: dw_mmc: exynos: increase DMA threshold value for exynos7870
From: Kaustabh Chakraborty @ 2026-04-15 15:02 UTC (permalink / raw)
To: Ulf Hansson, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jaehoon Chung, Shawn Lin, Krzysztof Kozlowski, Alim Akhtar
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, Kaustabh Chakraborty
In-Reply-To: <20260415-dwmmc-dma-thr-v3-0-31014d36b6ee@disroot.org>
Exynos 7870 compatible controllers, such as SDIO ones are not able to
perform DMA transfers for small sizes of data (~16 to ~512 bytes),
resulting in cache issues in subsequent transfers. Increase the DMA
transfer threshold to 512 to allow the shorter transfers to take place,
bypassing DMA.
Signed-off-by: Kaustabh Chakraborty <kauschluss@disroot.org>
---
drivers/mmc/host/dw_mmc-exynos.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mmc/host/dw_mmc-exynos.c b/drivers/mmc/host/dw_mmc-exynos.c
index 261344d3a8cfe..4b76b997ddc15 100644
--- a/drivers/mmc/host/dw_mmc-exynos.c
+++ b/drivers/mmc/host/dw_mmc-exynos.c
@@ -141,6 +141,7 @@ static int dw_mci_exynos_priv_init(struct dw_mci *host)
priv->ctrl_type == DW_MCI_TYPE_EXYNOS7870_SMU) {
/* Quirk needed for certain Exynos SoCs */
host->quirks |= DW_MMC_QUIRK_FIFO64_32;
+ host->dma_threshold = 512;
}
if (priv->ctrl_type == DW_MCI_TYPE_ARTPEC8) {
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RFC 4/4] arm64: dts: qcom: Enable GPU & GMU on Glymur CRD
From: Rob Clark @ 2026-04-15 15:04 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Akhil P Oommen, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Sean Paul, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, linux-arm-msm, devicetree, linux-kernel,
dri-devel, freedreno
In-Reply-To: <17b2ff60-d2e7-4f88-b2ae-f4dcad44fc33@oss.qualcomm.com>
On Wed, Apr 15, 2026 at 2:12 AM Konrad Dybcio
<konrad.dybcio@oss.qualcomm.com> wrote:
>
> On 4/4/26 11:03 PM, Akhil P Oommen wrote:
> > Enable the necessary DT nodes to add support for GPU on the Glymur CRD.
> > The Glymur CRD boots Linux at EL2, which means it doesn't require the
> > secure GPU firmware (zap fw).
> >
> > Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> > ---
>
> This isn't a blocker per se, but since there is no more zap, do you
> think we can just enable the GPU and GMU by default (i.e. no status=
> "disabled" in SoC DTSI)?
Agreed.. I'm pretty sure zap was the only reason for disabling by default.
BR,
-R
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
>
> Konrad
^ permalink raw reply
* Re: [PATCH v4 1/2] dt-bindings: pwm: dwc: add reset optional
From: Conor Dooley @ 2026-04-15 15:09 UTC (permalink / raw)
To: dongxuyang
Cc: ukleinek, robh, krzk+dt, conor+dt, ben-linux, ben.dooks, p.zabel,
linux-pwm, devicetree, linux-kernel, ningyu, linmin, xuxiang,
wangguosheng, pinkesh.vaghela
In-Reply-To: <20260415095020.1597-1-dongxuyang@eswincomputing.com>
[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]
On Wed, Apr 15, 2026 at 05:50:20PM +0800, dongxuyang@eswincomputing.com wrote:
> From: Xuyang Dong <dongxuyang@eswincomputing.com>
>
> The DesignWare PWM includes separate reset signals dedicated to each clock
> domain:
> The presetn signal resets logic in pclk domain.
> The timer_N_resetn signal resets logic in the timer_N_clk domain.
> The resets are active-low.
>
> Signed-off-by: Xuyang Dong <dongxuyang@eswincomputing.com>
This commit implies that your hardware differs from existing devices,
I think you should add a device-specific compatible.
> ---
> .../devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> index 7523a89a1773..a8bbad0360f8 100644
> --- a/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> +++ b/Documentation/devicetree/bindings/pwm/snps,dw-apb-timers-pwm2.yaml
> @@ -43,6 +43,9 @@ properties:
> - const: bus
> - const: timer
>
> + resets:
> + maxItems: 2
> +
> snps,pwm-number:
> $ref: /schemas/types.yaml#/definitions/uint32
> description: The number of PWM channels configured for this instance
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/4] dt-bindings: soc: amlogic: clk-measure: Add A1 and T7 compatible
From: Conor Dooley @ 2026-04-15 15:10 UTC (permalink / raw)
To: jian.hu
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Neil Armstrong,
Kevin Hilman, Jerome Brunet, Martin Blumenstingl, devicetree,
linux-arm-kernel, linux-amlogic, linux-kernel
In-Reply-To: <20260415-clkmsr_a1_t7-v2-1-02b6314427e6@amlogic.com>
[-- Attachment #1: Type: text/plain, Size: 1212 bytes --]
On Wed, Apr 15, 2026 at 04:33:41PM +0800, Jian Hu via B4 Relay wrote:
> From: Jian Hu <jian.hu@amlogic.com>
>
> Add the Amlogic A1 and T7 compatible for the clk-measurer IP.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
In the future, please note why fallback compatibles are not suitable in
patches like this.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
> ---
> .../devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
> index 39d4637c2d08..b1200e6940ac 100644
> --- a/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
> +++ b/Documentation/devicetree/bindings/soc/amlogic/amlogic,meson-gx-clk-measure.yaml
> @@ -24,6 +24,8 @@ properties:
> - amlogic,meson-sm1-clk-measure
> - amlogic,c3-clk-measure
> - amlogic,s4-clk-measure
> + - amlogic,a1-clk-measure
> + - amlogic,t7-clk-measure
>
> reg:
> maxItems: 1
>
> --
> 2.47.1
>
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v29 1/4] dt-bindings: i2c: Split AST2600 binding into a new YAML
From: Conor Dooley @ 2026-04-15 15:16 UTC (permalink / raw)
To: Ryan Chen
Cc: jk, andriy.shevchenko, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Rayn Chen, Philipp Zabel, linux-i2c,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, openbmc
In-Reply-To: <20260415-upstream_i2c-v29-1-317c1a905ae1@aspeedtech.com>
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]
On Wed, Apr 15, 2026 at 01:14:02PM +0800, Ryan Chen wrote:
> The AST2600 I2C controller introduces a completely new register layout
> with separate controller and target register blocks, unlike the mixed
> register layout used by AST2400/AST2500.
>
> Move AST2600 I2C binding from aspeed,i2c.yaml to a dedicated
> aspeed,ast2600-i2c.yaml schema.
>
> Besides the split, this also adjusts for AST2600-specific requirements.
> - require two reg regions (controller register block + buffer block)
> - use clock-frequency for bus speed description
> - interrupts are required on AST2600
> - use correct DTS coding style in example
>
> No compatible strings are changed.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v29 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs properties
From: Conor Dooley @ 2026-04-15 15:19 UTC (permalink / raw)
To: Ryan Chen
Cc: jk, andriy.shevchenko, Andi Shyti, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Rayn Chen, Philipp Zabel, linux-i2c,
devicetree, linux-arm-kernel, linux-aspeed, linux-kernel, openbmc
In-Reply-To: <20260415-upstream_i2c-v29-2-317c1a905ae1@aspeedtech.com>
[-- Attachment #1: Type: text/plain, Size: 2088 bytes --]
On Wed, Apr 15, 2026 at 01:14:03PM +0800, Ryan Chen wrote:
> Add the aspeed,global-regs phandle to reference the AST2600 global
> registers syscon node, containing the SoC-common I2C register set.
>
> These properties apply only to the AST2600 binding. Legacy DTs remain
> unchanged.
>
> Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
I hate to do it to you on v29, but can you please explain what this
"soc-common i2c register set" actually is/does in your commit message.
The patch seems fine, so with that
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
> ---
> Changes in v29:
> - remove aspeed,enable-dma properties.
>
> Changes in v28:
> - update commit message correspond with aspeed,enable-dma.
> - remove aspeed,transfer-mode and add aspeed,enable-dma property and
> description.
> - Fix aspeed,enable-dma description to reflect hardware capability rather
> than software behavior
>
> Changes in v27:
> - change aspeed,transfer-mode to aspeed,enable-dma.
> ---
> Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> index de2c359037da..0c769efb76a5 100644
> --- a/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> +++ b/Documentation/devicetree/bindings/i2c/aspeed,ast2600-i2c.yaml
> @@ -37,6 +37,12 @@ properties:
> resets:
> maxItems: 1
>
> + aspeed,global-regs:
> + $ref: /schemas/types.yaml#/definitions/phandle
> + description:
> + Phandle reference to the i2c global syscon node, containing the
> + SoC-common i2c register set.
> +
> required:
> - reg
> - compatible
> @@ -59,4 +65,5 @@ examples:
> resets = <&syscon ASPEED_RESET_I2C>;
> clock-frequency = <100000>;
> interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_HIGH>;
> + aspeed,global-regs = <&i2c_global>;
> };
>
> --
> 2.34.1
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* [PATCH 0/9] ASoC: mediatek: mt2701: HDMI audio support
From: Daniel Golle @ 2026-04-15 15:23 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Kuninori Morimoto, Daniel Golle, Nícolas F. R. A. Prado,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
This series wires up on-chip HDMI audio on MT2701 and MT7623, from the
DRM bridge down through the AFE into a small machine driver that binds
the AFE HDMI BE to the HDMI TX codec already exposed by the
mediatek-drm-hdmi driver. Bindings, DT and a BananaPi R2 board node
are included.
In order to survive vblank or late hotplug of the monitor, the fix
submitted separately [1] is required as well.
Everything here was developed for and tested on a BananaPi R2
(MT7623N), which turns ten years old this year -- a nice occasion to
finally land native HDMI audio for a SoC which was truly ahead of its
time.
[1]: https://patchwork.kernel.org/project/linux-mediatek/patch/a3e22cbae528c9a38d854a586d1736b860998d41.1776265222.git.daniel@makrotopia.org/
Daniel Golle (9):
dt-bindings: sound: mt2701-afe-pcm: add HDMI audio path clocks
dt-bindings: sound: add mediatek,mt2701-hdmi-audio machine binding
ASoC: mediatek: mt2701: add AFE HDMI register definitions
ASoC: mediatek: mt2701: add optional HDMI audio path clocks
ASoC: mediatek: mt2701: add HDMI audio memif, FE and BE DAIs
ASoC: mediatek: mt2701: add machine driver for on-chip HDMI codec
ARM: dts: mediatek: mt2701: wire HDMI audio path clocks into AFE
ARM: dts: mediatek: mt7623: wire HDMI audio path clocks into AFE
ARM: dts: mediatek: mt7623n-bananapi-bpi-r2: add HDMI audio machine
node
.../bindings/sound/mediatek,mt2701-audio.yaml | 10 +
.../sound/mediatek,mt2701-hdmi-audio.yaml | 47 +++
arch/arm/boot/dts/mediatek/mt2701.dtsi | 21 +-
arch/arm/boot/dts/mediatek/mt7623.dtsi | 21 +-
.../dts/mediatek/mt7623n-bananapi-bpi-r2.dts | 7 +
sound/soc/mediatek/Kconfig | 10 +
sound/soc/mediatek/mt2701/Makefile | 1 +
.../mediatek/mt2701/mt2701-afe-clock-ctrl.c | 22 ++
sound/soc/mediatek/mt2701/mt2701-afe-common.h | 6 +
sound/soc/mediatek/mt2701/mt2701-afe-pcm.c | 281 +++++++++++++++++-
sound/soc/mediatek/mt2701/mt2701-hdmi.c | 114 +++++++
sound/soc/mediatek/mt2701/mt2701-reg.h | 35 +++
12 files changed, 564 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
create mode 100644 sound/soc/mediatek/mt2701/mt2701-hdmi.c
--
2.53.0
^ permalink raw reply
* [PATCH 1/9] dt-bindings: sound: mt2701-afe-pcm: add HDMI audio path clocks
From: Daniel Golle @ 2026-04-15 15:23 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Kuninori Morimoto, Daniel Golle, Nícolas F. R. A. Prado,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1776265610.git.daniel@makrotopia.org>
Document four additional optional clocks feeding the HDMI audio
output path on MT2701 and MT7623N: the HADDS2 PLL (root of the
HDMI audio clock tree), the HDMI audio and S/PDIF interface power
gates, and the audio APLL root gate. Older device trees that do
not wire these up remain valid via minItems.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
.../bindings/sound/mediatek,mt2701-audio.yaml | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
index 45382c4d86aa3..9d4fc542cd72c 100644
--- a/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-audio.yaml
@@ -32,6 +32,7 @@ properties:
maxItems: 1
clocks:
+ minItems: 34
items:
- description: audio infra sys clock
- description: top audio mux 1
@@ -67,8 +68,13 @@ properties:
- description: top audio a1 sys pd
- description: top audio a2 sys pd
- description: audio merge interface pd
+ - description: HADDS2 PLL 294 MHz (HDMI audio path root)
+ - description: HDMI audio interface pd
+ - description: S/PDIF interface pd
+ - description: audio APLL root pd
clock-names:
+ minItems: 34
items:
- const: infra_sys_audio_clk
- const: top_audio_mux1_sel
@@ -104,6 +110,10 @@ properties:
- const: audio_a1sys_pd
- const: audio_a2sys_pd
- const: audio_mrgif_pd
+ - const: hadds2pll_294m
+ - const: audio_hdmi_pd
+ - const: audio_spdf_pd
+ - const: audio_apll_pd
required:
- compatible
--
2.53.0
^ permalink raw reply related
* [PATCH 2/9] dt-bindings: sound: add mediatek,mt2701-hdmi-audio machine binding
From: Daniel Golle @ 2026-04-15 15:23 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Kuninori Morimoto, Daniel Golle, Nícolas F. R. A. Prado,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1776265610.git.daniel@makrotopia.org>
Describe the ASoC machine compatible used to wire the MT2701/MT7623N
AFE HDMI playback path to the on-chip HDMI transmitter acting as the
generic HDMI audio codec. MT7623N boards carry the same IP and use
the mt7623n- compatible as a fallback to mt2701-.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
.../sound/mediatek,mt2701-hdmi-audio.yaml | 47 +++++++++++++++++++
1 file changed, 47 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
diff --git a/Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml b/Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
new file mode 100644
index 0000000000000..d08aee447b471
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/mediatek,mt2701-hdmi-audio.yaml
@@ -0,0 +1,47 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/mediatek,mt2701-hdmi-audio.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: MediaTek MT2701 HDMI audio machine driver
+
+maintainers:
+ - Daniel Golle <daniel@makrotopia.org>
+
+description:
+ ASoC machine driver binding the MT2701 AFE HDMI playback path to
+ the on-chip HDMI transmitter via the generic HDMI audio codec.
+ The same HDMI audio IP is present on MT7623N.
+
+properties:
+ compatible:
+ oneOf:
+ - const: mediatek,mt2701-hdmi-audio
+ - items:
+ - const: mediatek,mt7623n-hdmi-audio
+ - const: mediatek,mt2701-hdmi-audio
+
+ mediatek,platform:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle of the MT2701/MT7623N AFE platform node.
+
+ mediatek,audio-codec:
+ $ref: /schemas/types.yaml#/definitions/phandle
+ description: Phandle of the HDMI transmitter acting as audio codec.
+
+required:
+ - compatible
+ - mediatek,platform
+ - mediatek,audio-codec
+
+additionalProperties: false
+
+examples:
+ - |
+ sound-hdmi {
+ compatible = "mediatek,mt7623n-hdmi-audio",
+ "mediatek,mt2701-hdmi-audio";
+ mediatek,platform = <&afe>;
+ mediatek,audio-codec = <&hdmi0>;
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH 3/9] ASoC: mediatek: mt2701: add AFE HDMI register definitions
From: Daniel Golle @ 2026-04-15 15:23 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Kuninori Morimoto, Daniel Golle, Nícolas F. R. A. Prado,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1776265610.git.daniel@makrotopia.org>
Add register offsets and bit defines for the MT2701/MT7623N AFE
HDMI audio output path: the HDMI BCK divider in AUDIO_TOP_CON3,
the HDMI output memif control and descriptor registers, the 8-bit
AFE_HDMI_CONN0 interconnect, and the AFE_8CH_I2S_OUT_CON engine
that drives the HDMI TX serial link. These are a prerequisite for
adding an HDMI playback path to the mt2701 AFE driver and have no
behavioural effect on their own.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
sound/soc/mediatek/mt2701/mt2701-reg.h | 35 ++++++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/sound/soc/mediatek/mt2701/mt2701-reg.h b/sound/soc/mediatek/mt2701/mt2701-reg.h
index c84d14cdd7ae8..b7a25bfb58662 100644
--- a/sound/soc/mediatek/mt2701/mt2701-reg.h
+++ b/sound/soc/mediatek/mt2701/mt2701-reg.h
@@ -10,10 +10,17 @@
#define _MT2701_REG_H_
#define AUDIO_TOP_CON0 0x0000
+#define AUDIO_TOP_CON3 0x000c
#define AUDIO_TOP_CON4 0x0010
#define AUDIO_TOP_CON5 0x0014
#define AFE_DAIBT_CON0 0x001c
#define AFE_MRGIF_CON 0x003c
+#define AFE_HDMI_OUT_CON0 0x0370
+#define AFE_HDMI_OUT_BASE 0x0374
+#define AFE_HDMI_OUT_CUR 0x0378
+#define AFE_HDMI_OUT_END 0x037c
+#define AFE_HDMI_CONN0 0x0390
+#define AFE_8CH_I2S_OUT_CON 0x0394
#define ASMI_TIMING_CON1 0x0100
#define ASMO_TIMING_CON1 0x0104
#define PWR1_ASM_CON1 0x0108
@@ -125,6 +132,34 @@
#define AFE_MEMIF_PBUF_SIZE_DLM_BYTE_MASK (0x3 << 12)
#define AFE_MEMIF_PBUF_SIZE_DLM_32BYTES (0x1 << 12)
+/* AUDIO_TOP_CON0 (0x0000) -- HDMI audio clock gating */
+#define AUDIO_TOP_CON0_PDN_HDMI_CK (0x1 << 20)
+#define AUDIO_TOP_CON0_PDN_SPDIF_CK (0x1 << 21)
+#define AUDIO_TOP_CON0_PDN_SPDIF2_CK (0x1 << 22)
+#define AUDIO_TOP_CON0_PDN_APLL_CK (0x1 << 23)
+
+/* AUDIO_TOP_CON3 (0x000c) -- HDMI BCK divider */
+#define AUDIO_TOP_CON3_HDMI_BCK_DIV_MASK (0x3f << 8)
+#define AUDIO_TOP_CON3_HDMI_BCK_DIV(x) (((x) & 0x3f) << 8)
+
+/* AFE_HDMI_OUT_CON0 (0x0370) */
+#define AFE_HDMI_OUT_CON0_OUT_ON (0x1 << 0)
+#define AFE_HDMI_OUT_CON0_BIT_WIDTH_MASK (0x1 << 1)
+#define AFE_HDMI_OUT_CON0_BIT_WIDTH_16 (0x0 << 1)
+#define AFE_HDMI_OUT_CON0_BIT_WIDTH_32 (0x1 << 1)
+#define AFE_HDMI_OUT_CON0_CH_NUM_MASK (0xf << 4)
+#define AFE_HDMI_OUT_CON0_CH_NUM(x) (((x) & 0xf) << 4)
+
+/* AFE_8CH_I2S_OUT_CON (0x0394) -- on-SoC 8-channel I2S that feeds HDMI TX */
+#define AFE_8CH_I2S_OUT_CON_EN (0x1 << 0)
+#define AFE_8CH_I2S_OUT_CON_BCK_INV (0x1 << 1)
+#define AFE_8CH_I2S_OUT_CON_LRCK_INV (0x1 << 2)
+#define AFE_8CH_I2S_OUT_CON_I2S_DELAY (0x1 << 3)
+#define AFE_8CH_I2S_OUT_CON_WLEN_MASK (0x3 << 4)
+#define AFE_8CH_I2S_OUT_CON_WLEN_16BIT (0x1 << 4)
+#define AFE_8CH_I2S_OUT_CON_WLEN_24BIT (0x2 << 4)
+#define AFE_8CH_I2S_OUT_CON_WLEN_32BIT (0x3 << 4)
+
/* I2S in/out register bit control */
#define ASYS_I2S_CON_FS (0x1f << 8)
#define ASYS_I2S_CON_FS_SET(x) ((x) << 8)
--
2.53.0
^ permalink raw reply related
* [PATCH 4/9] ASoC: mediatek: mt2701: add optional HDMI audio path clocks
From: Daniel Golle @ 2026-04-15 15:23 UTC (permalink / raw)
To: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Matthias Brugger, AngeloGioacchino Del Regno,
Jaroslav Kysela, Takashi Iwai, Cyril Chao, Arnd Bergmann,
Kuninori Morimoto, Daniel Golle, Nícolas F. R. A. Prado,
Eugen Hristev, linux-sound, devicetree, linux-kernel,
linux-arm-kernel, linux-mediatek
In-Reply-To: <cover.1776265610.git.daniel@makrotopia.org>
The HDMI audio output path on MT2701/MT7623N is rooted in HADDS2PLL
and gated by the audio_hdmi, audio_spdf and audio_apll power gates.
Acquire these four clocks from device tree using devm_clk_get_optional
so that existing platforms which do not wire up HDMI audio keep
probing unchanged. Actual clock enable/prepare is deferred to the
upcoming HDMI DAI startup path.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
---
.../mediatek/mt2701/mt2701-afe-clock-ctrl.c | 22 +++++++++++++++++++
sound/soc/mediatek/mt2701/mt2701-afe-common.h | 4 ++++
2 files changed, 26 insertions(+)
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
index ae620890bb3ac..5a2bcf027b4fb 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-clock-ctrl.c
@@ -95,6 +95,28 @@ int mt2701_init_clock(struct mtk_base_afe *afe)
afe_priv->mrgif_ck = NULL;
}
+ /*
+ * Optional HDMI audio clocks. Platforms that do not wire up the
+ * HDMI output (e.g. MT2701 devkits using only the I2S BE DAIs)
+ * may omit these; in that case the HDMI BE DAI simply cannot be
+ * enabled, but the rest of the AFE still probes.
+ */
+ afe_priv->hadds2pll_ck = devm_clk_get_optional(afe->dev, "hadds2pll_294m");
+ if (IS_ERR(afe_priv->hadds2pll_ck))
+ return PTR_ERR(afe_priv->hadds2pll_ck);
+
+ afe_priv->audio_hdmi_ck = devm_clk_get_optional(afe->dev, "audio_hdmi_pd");
+ if (IS_ERR(afe_priv->audio_hdmi_ck))
+ return PTR_ERR(afe_priv->audio_hdmi_ck);
+
+ afe_priv->audio_spdf_ck = devm_clk_get_optional(afe->dev, "audio_spdf_pd");
+ if (IS_ERR(afe_priv->audio_spdf_ck))
+ return PTR_ERR(afe_priv->audio_spdf_ck);
+
+ afe_priv->audio_apll_ck = devm_clk_get_optional(afe->dev, "audio_apll_pd");
+ if (IS_ERR(afe_priv->audio_apll_ck))
+ return PTR_ERR(afe_priv->audio_apll_ck);
+
return 0;
}
diff --git a/sound/soc/mediatek/mt2701/mt2701-afe-common.h b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
index 32bef5e2a56d9..7b15283d6351e 100644
--- a/sound/soc/mediatek/mt2701/mt2701-afe-common.h
+++ b/sound/soc/mediatek/mt2701/mt2701-afe-common.h
@@ -90,6 +90,10 @@ struct mt2701_afe_private {
struct mt2701_i2s_path *i2s_path;
struct clk *base_ck[MT2701_BASE_CLK_NUM];
struct clk *mrgif_ck;
+ struct clk *hadds2pll_ck;
+ struct clk *audio_hdmi_ck;
+ struct clk *audio_spdf_ck;
+ struct clk *audio_apll_ck;
bool mrg_enable[MTK_STREAM_NUM];
const struct mt2701_soc_variants *soc;
--
2.53.0
^ permalink raw reply related
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