* Re: [PATCH v2 2/2] iio: magnetometer: add support for Melexis MLX90393
From: Andy Shevchenko @ 2026-06-19 6:40 UTC (permalink / raw)
To: Nikhil Gautam
Cc: linux-iio, jic23, dlechner, nuno.sa, andy, robh, krzk+dt,
conor+dt, devicetree, linux-kernel
In-Reply-To: <98a08d17-5b70-4f4d-bf52-fe1073fde2b6@gmail.com>
On Fri, Jun 19, 2026 at 02:36:00AM +0530, Nikhil Gautam wrote:
> On 19-06-2026 12:56 am, Andy Shevchenko wrote:
> > On Thu, Jun 18, 2026 at 09:31:41PM +0530, Nikhil Gautam wrote:
>
> Thank you very much for taking the time to do such a thorough review of this
> patch series.
>
> Your detailed comments and suggestions are very helpful.
> I'll address the issues you've pointed out, update the cover letter to
> better explain the design decisions,
> and incorporate the requested coding style and API changes in the next
> revision.
>
> I appreciate your review and feedback.
You're welcome!
...
> > > +config MLX90393
> > > + tristate "MELEXIS MLX90393 3-axis magnetometer sensor"
> > > + depends on I2C
> > Why not a regmap?
> The MLX90393 uses both register-based and command-based transactions.
> Since regmap does not naturally model the command-based interface,
> using it would require workarounds such as virtual registers or bypass
> paths.
> A custom transport abstraction is therefore simpler and better suited for
> this device.
>
> I already discussed this on thread, Link :
> https://lore.kernel.org/linux-iio/20260423121834.4244-1-nikhilgtr@gmail.com/
Right, but please, put a summary in the commit message as it's important
detail of implementation choice.
...
> > > + for (unsigned int i = 0; i < MLX90393_OSR_MAX; i++)
> > > + if (mlx90393_osr_avail[i] == val) {
> > > + *osr = i;
> > > + return 0;
> > > + }
> > Missing {}.
> Agreed, removed intentionally as single statement, will add as per
> guidelines all the places
> where needed
It's also better to have them when it might be ambiguous. And also when even
a single statement takes a few lines. TL;DR: Also apply a common sense.
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: thermal: Add Qualcomm MBG thermal monitor support
From: Sachin Gupta @ 2026-06-19 6:44 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Lee Jones, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Rafael J. Wysocki, Daniel Lezcano, Zhang Rui, Lukasz Luba,
Stephen Boyd, Jishnu Prakash, Kamal Wadhwa, Amit Kucheria,
Thara Gopinath, linux-arm-msm, devicetree, linux-kernel, linux-pm,
Satya Priya Kakitapalli, Ajit Pandey, Imran Shaik, Taniya Das,
Jagadeesh Kona
In-Reply-To: <20260608-sweet-powerful-ibis-8b2adb@quoll>
On 6/8/2026 3:37 PM, Krzysztof Kozlowski wrote:
> On Mon, Jun 01, 2026 at 04:31:18PM +0530, Sachin Gupta wrote:
>> From: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
>>
>> Add bindings for the Qualcomm MBG (Master Bandgap) temperature alarm peripheral
>
> Feels unwrapped.
>
> Please wrap commit message according to Linux coding style / submission
> process (neither too early nor over the limit):
> https://elixir.bootlin.com/linux/v6.4-rc1/source/Documentation/process/submitting-patches.rst#L597
>
I will re-wrap the commit message in the next revision.
>
>> found on the PM8775 PMIC. Unlike the existing SPMI temp alarm peripheral,
>> the MBG peripheral supports both hot and cold threshold monitoring across
>> two programmable levels (LVL1 and LVL2), with interrupt status reported via
>> a fault status register over SPMI.
>>
>> Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
>> Co-developed-by: Sachin Gupta <sachin.gupta@oss.qualcomm.com>
>> Signed-off-by: Sachin Gupta <sachin.gupta@oss.qualcomm.com>
>> ---
>> .../devicetree/bindings/mfd/qcom,spmi-pmic.yaml | 4 ++
>> .../bindings/thermal/qcom-spmi-mbg-tm.yaml | 72 ++++++++++++++++++++++
>> 2 files changed, 76 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
>> index 644c42b5e2e5..5f409fe700b2 100644
>> --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
>> +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.yaml
>> @@ -193,6 +193,10 @@ patternProperties:
>> type: object
>> $ref: /schemas/thermal/qcom,spmi-temp-alarm.yaml#
>>
>> + "^temperature-sensor@[0-9a-f]+$":
>> + type: object
>> + $ref: /schemas/thermal/qcom-spmi-mbg-tm.yaml#
>> +
>> "^typec@[0-9a-f]+$":
>> type: object
>> $ref: /schemas/usb/qcom,pmic-typec.yaml#
>> diff --git a/Documentation/devicetree/bindings/thermal/qcom-spmi-mbg-tm.yaml b/Documentation/devicetree/bindings/thermal/qcom-spmi-mbg-tm.yaml
>> new file mode 100644
>> index 000000000000..a0ecc9f35cf6
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/thermal/qcom-spmi-mbg-tm.yaml
>
> Filename must match compatible.
>
Thanks for the review. I can rename this to match the compatible naming,
but wanted your preference on scope:
Should I use a generic naming scheme (qcom,spmi-mbg-tm.yaml with
matching compatible), or make it PMIC-specific (qcom,pm8775-mbg-tm.yaml).
Thanks,
Sachin
>> @@ -0,0 +1,72 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/thermal/qcom-spmi-mbg-tm.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm's SPMI PMIC MBG Thermal Monitoring
>
> Best regards,
> Krzysztof
>
^ permalink raw reply
* Re: [PATCH 2/2] thermal: qcom: Add support for Qualcomm MBG thermal monitoring
From: Sachin Gupta @ 2026-06-19 6:45 UTC (permalink / raw)
To: Konrad Dybcio, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rafael J. Wysocki, Daniel Lezcano, Zhang Rui,
Lukasz Luba, Stephen Boyd, Jishnu Prakash, Kamal Wadhwa,
Amit Kucheria, Thara Gopinath
Cc: linux-arm-msm, devicetree, linux-kernel, linux-pm,
Satya Priya Kakitapalli, Ajit Pandey, Imran Shaik, Taniya Das,
Jagadeesh Kona
In-Reply-To: <7478c540-a5fc-4238-bba0-5b04547f57c7@oss.qualcomm.com>
On 6/16/2026 3:40 PM, Konrad Dybcio wrote:
> On 6/1/26 1:01 PM, Sachin Gupta wrote:
>> From: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
>>
>> Add driver for the Qualcomm MBG thermal monitoring device. It monitors
>> the die temperature, and when there is a level 1 upper threshold
>> violation, it receives an interrupt over spmi. The driver reads
>> the fault status register and notifies thermal accordingly.
>>
>> Signed-off-by: Satya Priya Kakitapalli <quic_skakitap@quicinc.com>
>> Co-developed-by: Sachin Gupta <sachin.gupta@oss.qualcomm.com>
>> Signed-off-by: Sachin Gupta <sachin.gupta@oss.qualcomm.com>
>> ---
>
> [...]
>
>> +static const struct mbg_map_table map_table[] = {
>> + /* minT vtemp0 tc */
>
> The struct is defined 2 lines above, the reader can tell the names
> of the fields
I will remove this in the next patch series.
>> + { -60000, 4337, 1967 },
>> + { -40000, 4731, 1964 },
>> + { -20000, 5124, 1957 },
>> + { 0, 5515, 1949 },
>> + { 20000, 5905, 1940 },
>> + { 40000, 6293, 1930 },
>> + { 60000, 6679, 1921 },
>> + { 80000, 7064, 1910 },
>> + { 100000, 7446, 1896 },
>> + { 120000, 7825, 1878 },
>> + { 140000, 8201, 1859 },
>> +};
>
> Please add a comment stating this map is not PMIC-specific
>
This table is PMIC-specific and applies only to the PM8775 MBG block.
MBG is used only on PM8775 PMIC.
> [...]
>
>> + /* The HW has a limitation that the trip set must be above 25C */
>> + if (temp > MBG_MIN_TRIP_TEMP && temp < MBG_MAX_SUPPORTED_TEMP) {
>> + ret = regmap_set_bits(chip->map, chip->base + MBG_TEMP_MON2_MISC_CFG,
>> + MON2_UP_THRESH_EN);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = regmap_write(chip->map, chip->base + MON2_LVL1_UP_THRESH,
>> + temp_to_vtemp_mv(temp));
>> + if (ret < 0)
>> + return ret;
>> + } else {
>> + dev_dbg(chip->dev, "Set trip b/w 25C and 160C\n");
>
> Should this be an error print, returning an error condition?
>
Yes, this should be treated as an error path. For out-of-range trip
requests, I will return -ERANGE and update the log to an error-level
message in the next patch series.
>> + ret = regmap_clear_bits(chip->map, chip->base + MBG_TEMP_MON2_MISC_CFG,
>> + MON2_UP_THRESH_EN);
>> + return ret;
>> + }
>> +
>> + /*
>> + * Configure the last_temp one degree higher, to ensure the
>> + * violated temp is returned to thermal framework when it reads
>> + * temperature for the first time after the violation happens.
>> + * This is needed to account for the inaccuracy in the conversion
>> + * formula used which leads to the thermal framework setting back
>> + * the same thresholds in case the temperature it reads does not
>> + * show violation.
>> + */
>> + chip->last_temp = temp + MBG_TEMP_CONSTANT;
>
> Will this work fine if the user tries to set the max temp supported
> by the hardware (i.e. is there headroom for max+1)?
>
In the current implementation, temp == MBG_MAX_SUPPORTED_TEMP is not
accepted (temp < MBG_MAX_SUPPORTED_TEMP), so the last_temp = temp +
MBG_TEMP_CONSTANT path is never taken at absolute max. For accepted
trips (strictly below max), there is headroom for the +1C adjustment.
>> +
>> + return ret;
>> +}
>> +
>> +static const struct thermal_zone_device_ops mbg_tm_ops = {
>> + .get_temp = mbg_tm_get_temp,
>> + .set_trips = mbg_tm_set_trip_temp,
>> +};
>> +
>> +static irqreturn_t mbg_tm_isr(int irq, void *data)
>> +{
>> + struct mbg_tm_chip *chip = data;
>> + int ret, val;
>> +
>> + scoped_guard(mutex, &chip->lock) {
>> + ret = regmap_read(chip->map, chip->base + MBG_TEMP_MON2_FAULT_STATUS, &val);
>> + if (ret < 0)
>> + return IRQ_HANDLED;
>> + }
>> +
>> + if (FIELD_GET(MON_FAULT_STATUS_MASK, val) & MON_FAULT_LVL1_UPR) {
>> + chip->last_thres_crossed = true;
>> + dev_dbg(chip->dev, "Notifying Thermal, fault status=%d\n", val);
>> + thermal_zone_device_update(chip->tz_dev, THERMAL_TRIP_VIOLATED);
>
> Should the assignment and this call also be guarded by the mutex?
>
> Konrad
Yes, agreed. I will update this locking in the next patch series.
Thanks,
Sachin
^ permalink raw reply
* Re: [PATCH 4/5] dmaengine: sun6i-dma: Implement support for Allwinner A733 DMA controller
From: sashiko-bot @ 2026-06-19 7:12 UTC (permalink / raw)
To: Yuanshen Cao
Cc: linux-sunxi, conor+dt, devicetree, vkoul, dmaengine, robh,
Frank.Li
In-Reply-To: <20260619-sun60i-a733-dma-v1-4-da4b649fc72a@gmail.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
Pre-existing issues:
- [Critical] The DMA interrupt handler incorrectly resolves the physical channel (`pchan`) from the interrupt status bit by ignoring the outer loop register index `i`.
- [High] Integer division truncation in loop bounds causes upper hardware channels to be completely ignored, and introduces out-of-bounds MMIO accesses.
--
commit e328a2b422946f5a9b0337a1058273c7077c1ac4
Author: Yuanshen Cao <alex.caoys@gmail.com>
dmaengine: sun6i-dma: Implement support for Allwinner A733 DMA controller
This patch implements the actual support for the Allwinner A733 DMA
controller. It defines the new register offsets and bitfield mappings
required for the A733, which slightly differs from the older sun6i
series.
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index fb1c1a28744bb..9585b4a9e00de 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
[ ... ]
> @@ -1352,6 +1412,33 @@ static struct sun6i_dma_config sun50i_h6_dma_cfg = {
> .has_mbus_clk = true,
> };
>
> +/*
> + * The A733 binding uses the number of dma channels from the
> + * device tree node.
> + */
> +static struct sun6i_dma_config sun60i_a733_dma_cfg = {
> + .clock_autogate_enable = sun6i_enable_clock_autogate_h3,
> + .set_burst_length = sun6i_set_burst_length_h3,
> + .set_drq = sun6i_set_drq_h6,
> + .set_mode = sun6i_set_mode_h6,
> + .set_addr = sun6i_dma_set_addr_a733,
> + .dump_com_regs = sun6i_dma_dump_com_regs_a733,
> + .read_irq_en = sun6i_read_irq_en_a733,
> + .write_irq_en = sun6i_write_irq_en_a733,
> + .read_irq_stat = sun6i_read_irq_stat_a733,
> + .write_irq_stat = sun6i_write_irq_stat_a733,
> + .src_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16),
> + .dst_burst_lengths = BIT(1) | BIT(4) | BIT(8) | BIT(16),
> + .src_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + .dst_addr_widths = BIT(DMA_SLAVE_BUSWIDTH_1_BYTE) |
> + BIT(DMA_SLAVE_BUSWIDTH_2_BYTES) |
> + BIT(DMA_SLAVE_BUSWIDTH_4_BYTES),
> + .num_channels_per_reg = DMA_IRQ_CHAN_NR_A733,
[Severity: Critical]
This is a pre-existing issue, but does setting num_channels_per_reg to 1
(DMA_IRQ_CHAN_NR_A733) break interrupt handling for all A733 channels > 0?
In sun6i_dma_interrupt(), the physical channel is calculated without the outer
loop index i:
for (i = 0; i < sdev->num_pchans / sdev->cfg->num_channels_per_reg; i++) {
...
for (j = 0; (j < sdev->cfg->num_channels_per_reg) && status; j++) {
pchan = sdev->pchans + j;
Since num_channels_per_reg is 1, j is always 0. As a result, every interrupt
on every channel will incorrectly resolve to sdev->pchans[0]. Doesn't this
completely break DMA functionality for all A733 channels except channel 0 by
causing spurious completions on channel 0 and hanging all others?
[Severity: High]
This is a pre-existing issue, but does using integer division truncation for
loop bounds ignore remainder channels and cause out-of-bounds MMIO accesses?
In sun6i_dma_interrupt(), the loop bound is:
i < sdev->num_pchans / sdev->cfg->num_channels_per_reg
For SoCs where the number of channels is not a perfect multiple of
num_channels_per_reg (like H3 with 12 channels and 8 channels per register),
this division truncates (12 / 8 = 1), causing the remainder channels to be
entirely ignored so their interrupts are never serviced.
Additionally, this patch series introduces a similar loop in
sun6i_kill_tasklet():
for (i = 0; i < DMA_MAX_CHANNELS / sdev->cfg->num_channels_per_reg; i++)
Since DMA_MAX_CHANNELS is 16 and num_channels_per_reg is 1 for A733, the loop
evaluates to 16. If the A733 hardware possesses fewer than 16 channels, won't
this cause out-of-bounds MMIO writes which can trigger bus aborts?
> + .has_mbus_clk = true,
> +};
> +
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619-sun60i-a733-dma-v1-0-da4b649fc72a@gmail.com?part=4
^ permalink raw reply
* RE: [PATCH v2 01/10] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3L support
From: Biju Das @ 2026-06-19 7:17 UTC (permalink / raw)
To: Conor Dooley, biju.das.au
Cc: Philipp Zabel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, magnus.damm, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org,
Prabhakar Mahadev Lad
In-Reply-To: <20260616-velcro-collar-3e764c6851da@spud>
Hi Conor,
Thanks for feedback.
> -----Original Message-----
> From: Conor Dooley <conor@kernel.org>
> Sent: 16 June 2026 16:45
> Subject: Re: [PATCH v2 01/10] dt-bindings: reset: renesas,rzg2l-usbphy-ctrl: Document RZ/G3L support
>
> On Tue, Jun 16, 2026 at 11:44:43AM +0100, Biju wrote:
> > From: Biju Das <biju.das.jz@bp.renesas.com>
> >
> > Document Renesas RZ/G3L (r9a08g046) USB PHY controller bindings.
> > The RZ/G3L USB PHY block is similar to RZ/G3S but differs in that each
> > port has its own OTG controller, whereas RZ/G3S only has one on port 1.
> > To reflect this, RZ/G3L uses a regulators sub-node with per-port vbus0
> > and vbus1 entries instead of the single regulator-vbus property used
> > by other compatible SoCs.
> >
> > Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> > ---
> > v1->v2:
> > * Updated commit description.
> > * Added enum instead of const in the compatible section.
> > * Dropped regulator1-vbus and added a regulators group node.
> > * Updated schema check.
> > ---
> > .../reset/renesas,rzg2l-usbphy-ctrl.yaml | 49 +++++++++++++++++--
> > 1 file changed, 46 insertions(+), 3 deletions(-)
> >
> > diff --git
> > a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.ya
> > ml
> > b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.ya
> > ml index c83469a1b379..12da48d069e5 100644
> > ---
> > a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.ya
> > ml
> > +++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctr
> > +++ l.yaml
> > @@ -16,13 +16,17 @@ description:
> > properties:
> > compatible:
> > oneOf:
> > + - items:
> > + - enum:
> > + - renesas,r9a08g045-usbphy-ctrl # RZ/G3S
> > + - renesas,r9a08g046-usbphy-ctrl # RZ/G3L
>
> Looks fine, other than the fact that the "- items: - enum:" construct is the same as just having "-
> enum".
> pw-bot: changes-requested
>
> Fix that problem, and
OK, will fix this in next version.
Cheers,
Biju
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
>
>
> Cheers,
> Conor.
^ permalink raw reply
* Re: [PATCH v4 2/2] clk: amlogic: Add A9 AO clock controller driver
From: Jerome Brunet @ 2026-06-19 7:29 UTC (permalink / raw)
To: Julian Braha
Cc: jian.hu, Neil Armstrong, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <79b1a519-5723-4e0c-904c-b7fdf9564ee1@gmail.com>
On jeu. 18 juin 2026 at 19:56, Julian Braha <julianbraha@gmail.com> wrote:
> Hi Jian,
>
> On 6/18/26 10:49, Jian Hu via B4 Relay wrote:
>
>> +config COMMON_CLK_A9_AO
>> + tristate "Amlogic A9 SoC AO clock controller support"
>> + depends on ARM64 || COMPILE_TEST
>> + default ARCH_MESON
>> + select COMMON_CLK_MESON_REGMAP
>> + select COMMON_CLK_MESON_CLKC_UTILS
>> + select COMMON_CLK_MESON_DUALDIV
>
> Selecting COMMON_CLK_MESON_REGMAP is unnecessary since you're already
> selecting COMMON_CLK_MESON_DUALDIV here.
No, regmap clock are directly used so this is necessary.
Relying on other module dependencies is not enough
>
> - Julian Braha
--
Jerome
^ permalink raw reply
* Re: [PATCH v4 2/2] clk: amlogic: Add A9 AO clock controller driver
From: Jerome Brunet @ 2026-06-19 7:34 UTC (permalink / raw)
To: sashiko-bot
Cc: Jian Hu via B4 Relay, sashiko-reviews, linux-amlogic,
neil.armstrong, robh, devicetree, conor+dt
In-Reply-To: <20260618100341.0A42F1F00A3A@smtp.kernel.org>
On jeu. 18 juin 2026 at 10:03, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Medium] The AO PWM clocks are registered without an `ao_` or `a9_ao_`
> prefix, which will cause global namespace collisions with the main clock
> controller.
> - [Low] Typographical error in the clock name string literal for the RTC
> dualdiv input gate: `ao_rtc_duandiv_in` instead of `ao_rtc_dualdiv_in`.
> - [Low] Missing `#include <linux/module.h>` for `MODULE_*` macros.
> --
>
> commit ef5998ff087b6faed09d9eed4f59078d2b2f0a60
> Author: Jian Hu <jian.hu@amlogic.com>
>
> clk: amlogic: Add A9 AO clock controller driver
>
> Add the Always-on clock controller driver for the Amlogic A9 SoC family.
>
>> diff --git a/drivers/clk/meson/a9-aoclk.c b/drivers/clk/meson/a9-aoclk.c
>> new file mode 100644
>> index 0000000000000..88aa8cf3f5d00
>> --- /dev/null
>> +++ b/drivers/clk/meson/a9-aoclk.c
>> @@ -0,0 +1,488 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only OR MIT)
>> +/*
>> + * Copyright (C) 2026 Amlogic, Inc. All rights reserved
>> + */
>> +
>> +#include <dt-bindings/clock/amlogic,a9-aoclkc.h>
>> +#include <linux/clk-provider.h>
>> +#include <linux/platform_device.h>
>
> [Severity: Low]
> Should this file explicitly include <linux/module.h>?
>
> The file relies on several module macros at the end (such as MODULE_DESCRIPTION,
> MODULE_AUTHOR, and MODULE_LICENSE). Although it currently compiles successfully
> due to transitive includes from <linux/platform_device.h>, standard kernel
> practice is to include the header explicitly.
Yes please fix this
>
> [ ... ]
>
>> +static const struct clk_parent_data a9_ao_pwm_parents[] = {
>> + { .hw = &a9_ao_xtal.hw },
>> + { .fw_name = "fdiv5", },
>> + { .fw_name = "fdiv4", },
>> + { .fw_name = "fdiv3", }
>> +};
>> +
>> +static A9_COMP_SEL(pwm_a, AO_PWM_CLK_A_CTRL, 9, 0x7, a9_ao_pwm_parents);
>
> [Severity: Medium]
> Will this cause a clock name collision with the main clock controller?
>
> Because the A9_COMP_SEL macro uses the #_name stringification operator inside
> MESON_COMP_SEL, this will generate the clock name as exactly "pwm_a_sel"
> (and similarly "pwm_a_div" and "pwm_a" for the others), without any "ao_" or
> "a9_ao_" prefix.
I think AI got it wrong and missed the prefix addition. Unless I missed
something my self, I think you are fine here
>
> If the main clock controller conventionally registers a "pwm_a" clock, failing
> to prefix the Always-On clocks will lead to global namespace collisions in the
> Common Clock Framework and debugfs.
>
>> +static A9_COMP_DIV(pwm_a, AO_PWM_CLK_A_CTRL, 0, 8);
>> +static A9_COMP_GATE(pwm_a, AO_PWM_CLK_A_CTRL, 8);
>> +
>> +static A9_COMP_SEL(pwm_b, AO_PWM_CLK_B_CTRL, 9, 0x7, a9_ao_pwm_parents);
>
> [ ... ]
>
>> +static struct clk_regmap a9_ao_rtc_dualdiv_in = {
>> + .data = &(struct clk_regmap_gate_data){
>> + .offset = AO_RTC_BY_OSCIN_CTRL0,
>> + .bit_idx = 31,
>> + },
>> + .hw.init = &(struct clk_init_data) {
>> + .name = "ao_rtc_duandiv_in",
>
> [Severity: Low]
> This isn't a bug, but there's a typo in the clock name literal. Should
> "ao_rtc_duandiv_in" be "ao_rtc_dualdiv_in"?
Yes
>
>> + .ops = &clk_regmap_gate_ops,
>> + .parent_hws = (const struct clk_hw *[]) {
>> + &a9_ao_xtal.hw
>> + },
--
Jerome
^ permalink raw reply
* Re: [PATCH 0/8] Add PCIe M.2 Key E connector support for NXP i.MX boards
From: Bartosz Golaszewski @ 2026-06-19 7:37 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun, robh, krzk+dt, conor+dt,
Frank.Li, s.hauer, kernel, festevam, amitkumar.karwar,
neeraj.sanjaykale, marcel, luiz.dentz, hongxing.zhu, l.stach,
lpieralisi, kwilczynski, mani, bhelgaas, brgl
In-Reply-To: <20260618101047.4185497-1-sherry.sun@oss.nxp.com>
On Thu, 18 Jun 2026 12:10:39 +0200, "Sherry Sun (OSS)"
<sherry.sun@oss.nxp.com> said:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> This series adds support for NXP Wi-Fi/BT combo chips (88W9098, AW693)
> inserted into PCIe M.2 Key E connectors on several i.MX EVK/MEK boards.
>
> For M.2 cards that rely on PCIe L2 link state and wake-up mechanisms, the
> card must remain powered during suspend. Patch 1 uses the existing
> dw_pcie_rp::skip_pwrctrl_off flag to skip power-off during suspend and skip
> power-on during the init path.
>
> Alsp the btnxpuart driver is extended to obtain a pwrseq descriptor via the
> OF graph on the UART controller device in patch 2.
>
> Sherry Sun (8):
> PCI: imx6: Add skip_pwrctrl_off flag support
> power: sequencing: pcie-m2: Add PCI ID for NXP 88W9098 and AW693
> Bluetooth
Can this be applied independently without build-time issues?
Bart
> Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq
> arm64: dts: imx8mq-evk: Describe the PCIe M.2 Key E connector
> arm64: dts: imx95-19x19-evk: Describe the PCIe M.2 Key E connector
> arm64: dts: imx8dxl-evk: Describe the PCIe M.2 Key E connector
> arm64: dts: imx8qm-mek: Describe the PCIe M.2 Key E connector
> arm64: dts: imx8qxp-mek: Describe the PCIe M.2 Key E connector
>
> arch/arm64/boot/dts/freescale/imx8dxl-evk.dts | 56 +++++++++++++-----
> arch/arm64/boot/dts/freescale/imx8mq-evk.dts | 44 ++++++++++++--
> arch/arm64/boot/dts/freescale/imx8qm-mek.dts | 58 ++++++++++++++-----
> arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 54 ++++++++++++-----
> .../boot/dts/freescale/imx95-19x19-evk.dts | 55 +++++++++++++-----
> drivers/bluetooth/btnxpuart.c | 33 ++++++++++-
> drivers/pci/controller/dwc/pci-imx6.c | 36 +++++++-----
> drivers/power/sequencing/pwrseq-pcie-m2.c | 4 ++
> 8 files changed, 264 insertions(+), 76 deletions(-)
>
> --
> 2.50.1
>
>
^ permalink raw reply
* Re: [PATCH v4 0/2] clk: amlogic: Add A9 AO clock controller
From: Jerome Brunet @ 2026-06-19 7:40 UTC (permalink / raw)
To: Jian Hu via B4 Relay
Cc: Neil Armstrong, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Xianwei Zhao, Kevin Hilman,
Martin Blumenstingl, jian.hu, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel, Conor Dooley
In-Reply-To: <20260618-a9_aoclk-v4-0-569d0425e50c@amlogic.com>
On jeu. 18 juin 2026 at 17:49, Jian Hu via B4 Relay <devnull+jian.hu.amlogic.com@kernel.org> wrote:
> This series adds Amlogic A9 AO clock support, including dt-binding and AO clock driver.
>
> Signed-off-by: Jian Hu <jian.hu@amlogic.com>
A part from the 2 minor problems found by sashiko, This looks good.
> ---
> Changes in v4:
> - Drop CLK_IS_CRITICAL for ao_xtal_in clock.
> - Drop CLK_HW_INIT* and revert to explicit clock declarations.
> - Link to v3: https://lore.kernel.org/r/20260610-a9_aoclk-v3-0-b7592d6c31e2@amlogic.com
>
> Changes in v3:
> - Move COMPILE_TEST after 'depends on ARM64' reported by sashiko-bot.
> - Rename i2c3 to i3c reported by sashiko-bot.
> - Reword the comment describing ao_xtal_in's flags.
> - Use struct clk_init_data to describe ao_xtal_in's hw.init.
> - Link to v2: https://lore.kernel.org/r/20260603-a9_aoclk-v2-0-f47ea616ee78@amlogic.com
>
> Changes in v2:
> - Split the A9 clock driver and send the AO clock separately.
> - Rename aobus to soc.
> - Use CLK_HW_INIT_FW_NAME to describe clk_init_data.
> - Use CLK_HW_INIT_PARENTS_DATA to describe clk_init_data.
> - Use a9_ao prefix for MESON_COMP_SEL.
> - Correct duandiv name.
> - Fix pwm b reg.
> - Link to v1: https://lore.kernel.org/all/20260511-b4-a9_clk-v1-0-41cb4071b7c9@amlogic.com/
>
> ---
> Jian Hu (2):
> dt-bindings: clock: Add Amlogic A9 AO clock controller
> clk: amlogic: Add A9 AO clock controller driver
>
> .../bindings/clock/amlogic,a9-aoclkc.yaml | 76 ++++
> drivers/clk/meson/Kconfig | 13 +
> drivers/clk/meson/Makefile | 1 +
> drivers/clk/meson/a9-aoclk.c | 488 +++++++++++++++++++++
> include/dt-bindings/clock/amlogic,a9-aoclkc.h | 76 ++++
> 5 files changed, 654 insertions(+)
> ---
> base-commit: ca89c88bcf69daca829044c638a8163d5ce47af0
> change-id: 20260603-a9_aoclk-bbf531badc63
>
> Best regards,
--
Jerome
^ permalink raw reply
* Re: [PATCH v6 06/16] iio: core: create local __iio_chan_prefix_emit() for reuse
From: Rodrigo Alencar @ 2026-06-19 7:43 UTC (permalink / raw)
To: Andy Shevchenko, Rodrigo Alencar
Cc: Nuno Sá, rodrigo.alencar, linux-iio, devicetree,
linux-kernel, linux-doc, linux-hardening, Lars-Peter Clausen,
Michael Hennerich, Jonathan Cameron, David Lechner,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Philipp Zabel, Jonathan Corbet, Shuah Khan, Kees Cook,
Gustavo A. R. Silva
In-Reply-To: <ajQ1bZSNHQ96pyJx@ashevche-desk.local>
On 18/06/26 21:14, Andy Shevchenko wrote:
> On Thu, Jun 18, 2026 at 05:14:19PM +0100, Rodrigo Alencar wrote:
> > On 18/06/26 16:06, Nuno Sá wrote:
> > > On Thu, Jun 18, 2026 at 02:27:22PM +0100, Rodrigo Alencar via B4 Relay wrote:
>
> ...
>
> > > > + dev_attr->attr.name = kasprintf(GFP_KERNEL, "%s%s", prefix, postfix);
> > > > + if (!dev_attr->attr.name)
> > > > return -ENOMEM;
> > >
> > > I don't oppose the change. Looks like a nice cleanup.
>
> May I oppose it? I found use scnprintf() is harder to follow in comparison to
> nice kasprintf() that takes care for the dynamically allocated buffer.
In the next patch the function is reused in a sysfs attribute read handler,
a context wich would not be nice to have dynamic allocation. vscnprintf() is
the main building block of sysfs_emit() which limits the buffer length to
a page size, so I used scnprintf() trying not to deviate much from that.
kasprintf() it is still used in the caller, where the logic was a bit confusing
as it tried to avoid multiple allocations.
> Also there is a chance to get a name silently cut due to insufficient space.
> Besides that this function can't be used (again due to 'c') in kasprintf()-like
> wrapper. I do not consider this as a good approach. Have you looked at seq_buf
> instead?
NAME_MAX is not the maximum length a filename can have? I suppose there should be
enough space for the channel-prefix. Indeed, seq_buf can be used and it cleans up
things a bit as it tracks the the position in the buffer.
>
> > > But bear in mind this very sensible as any subtle mistake means ABI breakage.
>
> Which immediately raises a question of test coverage. Do we have one? If not,
> this code must be accompanied with one.
Agreed. Will see to have tests for v7.
> > Yes! I tried to be careful... this is dangerous stuff!
--
Kind regards,
Rodrigo Alencar
^ permalink raw reply
* Re: [PATCH v7 2/2] drm: panel: add support for the Renesas R63419 based dual-DSI video mode Display Panels
From: Neil Armstrong @ 2026-06-19 7:47 UTC (permalink / raw)
To: Doug Anderson
Cc: Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, dri-devel, devicetree, linux-kernel,
linux-renesas-soc, Dmitry Baryshkov, KancyJoe
In-Reply-To: <CAD=FV=W5FgXGznH1+SA74WOfAUXaAggaJi=ds8udqZ69K3i=Ow@mail.gmail.com>
On 6/18/26 19:00, Doug Anderson wrote:
> Hi,
>
> On Fri, Jun 5, 2026 at 7:51 AM Neil Armstrong <neil.armstrong@linaro.org> wrote:
>>
>> From: KancyJoe <kancy2333@outlook.com>
>>
>> Implement support for the Renesas 63419 based dual-DSI video mode
>> Display Panels found in the Ayaneo gaming handled devices.
>>
>> Signed-off-by: KancyJoe <kancy2333@outlook.com>
>
> I notice "Kancy Joe" has a space in the source files, but not in the
> signoff. I guess Signed-off-by isn't necessarily required to be real
> names these days, but still seems odd...
Yeah I kept all the signoff and names as in the the source files,
it wasn't an issue for other patches, so I left it....
>
>
>> +/*
>> + * Helper to switch between DSI links, so we share a single dsi_ctx
>> + * for both links, so in case of an error all writes & sleep for
>> + * both links are ignored.
>> + */
>> +static inline void dsi_link_switch(struct renesas_r63419_panel *ctx,
>> + struct mipi_dsi_multi_context *dsi_ctx,
>> + unsigned int link)
>> +{
>> + dsi_ctx->dsi = ctx->dsi[link];
>> +}
>> +
>> +static int renesas_r63419_on(struct renesas_r63419_panel *ctx)
>> +{
>> + struct mipi_dsi_multi_context dsi_ctx = { 0 };
>> +
>> + /* Panel registers are loaded from DDIC Non Volatile Memory */
>> +
>> + dsi_link_switch(ctx, &dsi_ctx, 0);
>> + mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
>> + dsi_link_switch(ctx, &dsi_ctx, 1);
>> + mipi_dsi_dcs_exit_sleep_mode_multi(&dsi_ctx);
>
> Instead of dsi_link_switch(), can't you use the mipi_dsi_dual()
> function? I think it would be:
>
> mipi_dsi_dual(mipi_dsi_dcs_exit_sleep_mode_multi, dsi_ctx,
> ctx->dsi[0], ctx->dsi[1]);
Right, indeed will switch
>
>
>> +static int renesas_r63419_disable(struct drm_panel *panel)
>> +{
>> + struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
>> + struct mipi_dsi_multi_context dsi_ctx = { 0 };
>> +
>> + dsi_link_switch(ctx, &dsi_ctx, 0);
>> + mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
>> + dsi_link_switch(ctx, &dsi_ctx, 1);
>> + mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
>> + mipi_dsi_msleep(&dsi_ctx, 50);
>> +
>> + dsi_link_switch(ctx, &dsi_ctx, 0);
>> + mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
>> + dsi_link_switch(ctx, &dsi_ctx, 1);
>> + mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
>> + mipi_dsi_msleep(&dsi_ctx, 120);
>> +
>> + return dsi_ctx.accum_err;
>
> I'm not sure we've been terribly consistent, but should the above be
> "return 0"? I'm not actually sure there's any benefit to a panel's
> disable() function returning an error to begin with.
> drm_panel_disable() doesn't return an error, so all this does is skip
> setting "panel->enabled" to false and make it harder for the system to
> recover.
Yep you're right, there's no sense to return the error here.
>
>
>> +static int renesas_r63419_prepare(struct drm_panel *panel)
>> +{
>> + struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
>> + int ret;
>> +
>> + ret = regulator_bulk_enable(ARRAY_SIZE(renesas_r63419_vdd_supplies),
>> + ctx->vdd_supplies);
>> + if (ret < 0)
>> + return ret;
>> +
>> + usleep_range(1000, 2000);
>> +
>> + ret = regulator_bulk_enable(ARRAY_SIZE(renesas_r63419_vcc_supplies),
>> + ctx->vcc_supplies);
>> + if (ret < 0) {
>> + regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vdd_supplies),
>> + ctx->vdd_supplies);
>> + return ret;
>> + }
>> +
>> + usleep_range(1000, 2000);
>> +
>> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
>> +
>> + usleep_range(3000, 4000);
>> +
>> + ret = renesas_r63419_on(ctx);
>> + if (ret < 0) {
>> + dev_err(panel->dev, "Failed to initialize panel: %d\n", ret);
>> +
>> + /* Power off sequence from the r63419 datasheet */
>> + regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vcc_supplies),
>> + ctx->vcc_supplies);
>> + regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vdd_supplies),
>> + ctx->vdd_supplies);
>> +
>> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
>
> To make de-init opposite to init, shouldn't the reset come before you
> turn the regulators off? Depending on the design of the panel, I'd
> imagine this could prevent back-powering some logic?
>
> I'd also expect vdd supplies to be turned off first?
I did follow the DDIC spec here, and yeah Sashiko already
pointed it to me but reset needs to be switched to low _after_
the vdd supplies goes low. Perhaps indeed the vcc one should be
turned off after the reset. I'll do that.
>
>
>> +static int renesas_r63419_unprepare(struct drm_panel *panel)
>> +{
>> + struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
>> +
>> + /* Power off sequence from the r63419 datasheet */
>> + regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vcc_supplies), ctx->vcc_supplies);
>> + regulator_bulk_disable(ARRAY_SIZE(renesas_r63419_vdd_supplies), ctx->vdd_supplies);
>> +
>> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
>
> Similar: shouldn't the reset come before the regulators to make
> power-off the opposite of init.
Yep I'll move vcc disable after the reset to match the spec more closely.
>
>
>> +static int renesas_r63419_get_modes(struct drm_panel *panel,
>> + struct drm_connector *connector)
>> +{
>> + struct renesas_r63419_panel *ctx = to_renesas_r63419_panel(panel);
>> + const struct drm_display_mode *mode = ctx->desc->mode;
>> +
>> + drm_connector_set_panel_orientation(connector, ctx->orientation);
>
> IIRC, the above was a workaround that caused a warning splat. Is your
> panel used on a system that actually needs it? Could your DRM driver
> be fixed rather than persisting this hack? For context, see commit
> 47bef230225b ("drm/panel: panel-edp: Implement .get_orientation
> callback")
No need, I'll drop it
>
>
>> +static int renesas_r63419_probe(struct mipi_dsi_device *dsi)
>> +{
>> + struct mipi_dsi_device_info info = { };
>> + struct device *dev = &dsi->dev;
>> + struct renesas_r63419_panel *ctx;
>> + struct device_node *dsi1_node;
>> + struct mipi_dsi_host *dsi1_host;
>> + int ret, i;
>> +
>> + ctx = devm_drm_panel_alloc(dev, struct renesas_r63419_panel, panel,
>> + &renesas_r63419_panel_funcs, DRM_MODE_CONNECTOR_DSI);
>> + if (IS_ERR(ctx))
>> + return PTR_ERR(ctx);
>> +
>> + ctx->desc = of_device_get_match_data(dev);
>> + if (!ctx->desc)
>> + return dev_err_probe(dev, -ENODEV,
>> + "Failed to get panel description\n");
>> +
>> + ret = devm_regulator_bulk_get_const(&dsi->dev,
>> + ARRAY_SIZE(renesas_r63419_vdd_supplies),
>> + renesas_r63419_vdd_supplies, &ctx->vdd_supplies);
>> + if (ret < 0)
>> + return ret;
>> +
>> + ret = devm_regulator_bulk_get_const(&dsi->dev,
>> + ARRAY_SIZE(renesas_r63419_vcc_supplies),
>> + renesas_r63419_vcc_supplies, &ctx->vcc_supplies);
>> + if (ret < 0)
>> + return ret;
>
> It seems like both sets of supplies are always enabled / disabled
> together with no delay between them. Do you truly need two lists, or
> can this be combined to one list of regulators. That would simplify a
> bunch of logic.
You need a delay between enabling vcc and vdd according to the spec,
this is why I did a split.
>
>
>> + ctx->reset_gpio = devm_gpiod_get(dev, "reset", GPIOD_OUT_HIGH);
>> + if (IS_ERR(ctx->reset_gpio))
>> + return dev_err_probe(dev, PTR_ERR(ctx->reset_gpio),
>> + "Failed to get reset gpio\n");
>> +
>> + /* Get second DSI host */
>> + dsi1_node = of_graph_get_remote_node(dsi->dev.of_node, 1, -1);
>> + if (!dsi1_node)
>> + return dev_err_probe(dev, -ENODEV,
>> + "Failed to get remote node for second DSI\n");
>> +
>> + dsi1_host = of_find_mipi_dsi_host_by_node(dsi1_node);
>> + of_node_put(dsi1_node);
>> + if (!dsi1_host)
>> + return dev_err_probe(dev, -EPROBE_DEFER,
>> + "Failed to find second DSI host\n");
>> +
>> + /* Copy current DSI info, do not provide OF node since no driver needs to be attached */
>> + strscpy(info.type, dsi->name, sizeof(info.type));
>
> Can't you use the two-argument form of strscpy()?
Yeah sure
>
> FWIW, I also notice that the Sashiko AI bot had some comments. Did you
> already look all of those over and decide they don't need fixing? I
> have a vague recollection that there's no need to worry about someone
> calling disable() and then enable() without going through the
> unprepare() / prepare(). If my memory is correct, I guess that would
> be nice to document... I didn't analyze some of the other claims that
> the AI bot had.
Yep I fixed the real issues, the remaining issues are about the init
sequence and some impossible init sequence between drm and dsi.
Thanks,
Neil
>
>
> -Doug
^ permalink raw reply
* Re: [PATCH v4 2/2] clk: amlogic: Add A9 AO clock controller driver
From: Julian Braha @ 2026-06-19 7:48 UTC (permalink / raw)
To: Jerome Brunet
Cc: jian.hu, Neil Armstrong, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <1jbjd7c7ip.fsf@starbuckisacylon.baylibre.com>
Hi Jerome,
On 6/19/26 08:29, Jerome Brunet wrote:
> No, regmap clock are directly used so this is necessary.
> Relying on other module dependencies is not enough
What do you mean it's "not enough"?
Functionally, any user of COMMON_CLK_MESON_DUALDIV can also use
COMMON_CLK_MESON_REGMAP.
Unless you mean for documentation purposes?
- Julian Braha
^ permalink raw reply
* [PATCH] arm64: dts: renesas: r9a08g045: Move max-frequency to SoC dtsi
From: Biju @ 2026-06-19 7:56 UTC (permalink / raw)
To: Geert Uytterhoeven, Magnus Damm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Biju Das, linux-renesas-soc, devicetree, linux-kernel,
Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
Move the max-frequency property for SDHI0/1/2 from the board-level
SMARC dtsi files into the r9a08g045.dtsi SoC file, since these
values reflect controller/SoC limitations rather than board-specific.
This removes the duplicated max-frequency = <125000000> entries for
SDHI0 (both SD and eMMC variants) and SDHI1 in rzg3s-smarc-som.dtsi
and rzg3s-smarc.dtsi, and the max-frequency = <50000000> entry for
SDHI2, consolidating them as defaults in r9a08g045.dtsi instead.
Boards needing a different limit can still override max-frequency
locally.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
arch/arm64/boot/dts/renesas/r9a08g045.dtsi | 3 +++
arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi | 3 ---
arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi | 1 -
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
index 3a69bb246bab..ae92d45ede38 100644
--- a/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a08g045.dtsi
@@ -655,6 +655,7 @@ sdhi0: mmc@11c00000 {
<&cpg CPG_MOD R9A08G045_SDHI0_IMCLK2>,
<&cpg CPG_MOD R9A08G045_SDHI0_ACLK>;
clock-names = "core", "clkh", "cd", "aclk";
+ max-frequency = <125000000>;
resets = <&cpg R9A08G045_SDHI0_IXRST>;
power-domains = <&cpg>;
status = "disabled";
@@ -670,6 +671,7 @@ sdhi1: mmc@11c10000 {
<&cpg CPG_MOD R9A08G045_SDHI1_IMCLK2>,
<&cpg CPG_MOD R9A08G045_SDHI1_ACLK>;
clock-names = "core", "clkh", "cd", "aclk";
+ max-frequency = <125000000>;
resets = <&cpg R9A08G045_SDHI1_IXRST>;
power-domains = <&cpg>;
status = "disabled";
@@ -685,6 +687,7 @@ sdhi2: mmc@11c20000 {
<&cpg CPG_MOD R9A08G045_SDHI2_IMCLK2>,
<&cpg CPG_MOD R9A08G045_SDHI2_ACLK>;
clock-names = "core", "clkh", "cd", "aclk";
+ max-frequency = <50000000>;
resets = <&cpg R9A08G045_SDHI2_IXRST>;
power-domains = <&cpg>;
status = "disabled";
diff --git a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
index b45acfe6288a..9039a927bc46 100644
--- a/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc-som.dtsi
@@ -184,7 +184,6 @@ &sdhi0 {
bus-width = <4>;
sd-uhs-sdr50;
sd-uhs-sdr104;
- max-frequency = <125000000>;
status = "okay";
};
#else
@@ -199,7 +198,6 @@ &sdhi0 {
mmc-hs200-1_8v;
non-removable;
fixed-emmc-driver-type = <1>;
- max-frequency = <125000000>;
status = "okay";
};
#endif
@@ -210,7 +208,6 @@ &sdhi2 {
pinctrl-names = "default";
vmmc-supply = <&vcc_sdhi2>;
bus-width = <4>;
- max-frequency = <50000000>;
status = "okay";
};
#endif
diff --git a/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi b/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
index 70af605168b0..e3821d8c01e3 100644
--- a/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3s-smarc.dtsi
@@ -285,7 +285,6 @@ &sdhi1 {
bus-width = <4>;
sd-uhs-sdr50;
sd-uhs-sdr104;
- max-frequency = <125000000>;
status = "okay";
};
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v4 2/2] clk: amlogic: Add A9 AO clock controller driver
From: Jerome Brunet @ 2026-06-19 8:08 UTC (permalink / raw)
To: Julian Braha
Cc: jian.hu, Neil Armstrong, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Xianwei Zhao,
Kevin Hilman, Martin Blumenstingl, linux-amlogic, linux-clk,
devicetree, linux-kernel, linux-arm-kernel
In-Reply-To: <5af78bca-7c49-48b1-af8a-cfbe55ae26ba@gmail.com>
On ven. 19 juin 2026 at 08:48, Julian Braha <julianbraha@gmail.com> wrote:
> Hi Jerome,
>
> On 6/19/26 08:29, Jerome Brunet wrote:
>> No, regmap clock are directly used so this is necessary.
>> Relying on other module dependencies is not enough
>
> What do you mean it's "not enough"?
>
> Functionally, any user of COMMON_CLK_MESON_DUALDIV can also use
> COMMON_CLK_MESON_REGMAP.
This driver directly use regmap clocks. This is a direct dependency,
required for the build and stated as such. If the module needs it, it
depends on it, simply.
Relying on indirect dependencies is incorrect and fragile.
If those dependencies ever change, the build breaks for no obvious reason.
>
> Unless you mean for documentation purposes?
>
> - Julian Braha
--
Jerome
^ permalink raw reply
* Re: [PATCH v3 2/2] interconnect: qcom: add MSM8x60 NoC driver
From: me @ 2026-06-19 8:10 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Herman van Hazendonk, Georgi Djakov, Bjorn Andersson,
Konrad Dybcio, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-arm-msm, linux-pm, devicetree, linux-kernel
In-Reply-To: <ff72dd25-926b-4a51-99ad-4535f6025dcc@oss.qualcomm.com>
On 2026-06-17 12:36, Konrad Dybcio wrote:
> On 6/6/26 2:34 PM, Herman van Hazendonk wrote:
>> Add a Qualcomm interconnect driver for the MSM8x60 family modelling
>> the
>> four NoC fabrics (APPSS, System, MMSS, Daytona) that connect masters
>> and slaves on these Scorpion-class SoCs. The driver implements the
>> interconnect-provider API to manage bandwidth between specific masters
>> and slaves via the RPM arbitration tables.
>
> [...]
>
>
>> +/*
>> + * Minimum fabric clock rate to prevent bus starvation.
>> + *
>> + * When no consumers request bandwidth, the rate calculation yields
>> 0,
>> + * causing fabric clocks to drop to minimum. This creates bimodal
>> + * performance: fast when other subsystems (like display) happen to
>> + * request bandwidth, slow otherwise.
>> + *
>> + * 384 MHz keeps fabric fast during concurrent MDP display scanout
>> + * and USB gadget traffic. legacy vendor kernel docs: "AXI bus
>> frequency needs to be
>> + * kept at maximum value while USB data transfers are happening."
>> + * 266 MHz was insufficient - USB crashed during display activity.
>> + */
>> +#define MSM8660_FABRIC_MIN_RATE 384000000UL /* 384 MHz */
>
> Can you ensure that through a vote in the USB driver?
>
> Konrad
Hi Konrad,
I'm reworking the interconnect driver based on earlier feedback, but
running
into some regressions I need to tackle first. The driver I had was
stable,
the reworked one has some issues that I'm trying to tackle before
submitting
another version. The minimum rate will probably disappear as a result of
that
anyway.
Thanks,
Herman
^ permalink raw reply
* [PATCH v6 0/4] arm64: dts: renesas: Add RZ/G3E audio enablement
From: John Madieu @ 2026-06-19 8:39 UTC (permalink / raw)
To: geert+renesas, magnus.damm, robh, krzk+dt, conor+dt
Cc: linux-renesas-soc, devicetree, linux-kernel, john.madieu,
biju.das.jz, John Madieu
This is the remainder of the RZ/G3E audio enablement series. In v4, Geert
queued the clock and clock-input groundwork for v7.3, so it is not resent
here:
- dt-bindings: clock: renesas: Add audio clock inputs for RZ/V2H family
-> renesas-clk
- clk: renesas: r9a09g047: Add audio clock and reset support
-> renesas-clk
- arm64: dts: renesas: rzv2h: Add audio clock inputs
-> renesas-devel
- arm64: dts: renesas: rzg3e-smarc-som: Add I2C1 support
-> renesas-devel
This series carries only the four patches that were reviewed but not
queued. The sound node in 1/4 references the audio module clocks and
resets added by the queued clk patches, so this series depends on the
renesas-clk queue and is based on renesas-devel for v7.3.
v6 is a single fix: the Versa3 patch (2/4) now actually drops the
unconnected DIFF2 output from assigned-clocks/assigned-clock-rates, which
in v5 was described in the commit message but left in the DTS. The other
three patches are unchanged from v5.
v5:
- Resend only the four patches not queued for v7.3 (the four above are
dropped from the series).
- Sound node: hexadecimal module clock/reset numbers, lowercase 0x1f000
SSI size, SCU reg extended to 0x20000 to cover the SCU DMAC, per-line
clock/reset comments dropped.
- Versa3: document DIFF1/Ethernet, intended to drop the unconnected
DIFF2 output (the description was updated but the DTS still listed
output 5; fixed in v6).
- Pinmux: hyphenate node names, sort entries by GPIO number.
- Codec: drop the unnecessary #address-cells/#size-cells on codec@1a
(sashiko-bot); add Geert's Reviewed-by.
v4:
- Link to v4 at [1]
- Sound node: dotted clock/reset names moved to hyphenated form, legacy
rcar_sound,* sub-nodes renamed to unprefixed ctu/dvc/mix/src/ssi/ssiu,
clocks/resets reordered ascending, explanatory comment blocks dropped,
dmas continuation lines aligned, commit message corrected (snd_rzg3e).
- Versa3, pinmux, codec: no changes.
v3:
- Sound node: commit description typo fix.
- Versa3, pinmux, codec: no changes.
v2:
- Sound node: drop the 2-cells specifier on the audio DMA assignment and
stop updating DMAC #dma-cells.
- Versa3, pinmux, codec: no changes.
[1] https://lore.kernel.org/r/20260525110603.4018170-1-john.madieu.xa@bp.renesas.com
John Madieu (4):
arm64: dts: renesas: r9a09g047: Add RZ/G3E Sound support
arm64: dts: renesas: rzg3e-smarc-som: Add Versa3 clock generator
arm64: dts: renesas: rzg3e-smarc-som: add audio pinmux definitions
arm64: dts: renesas: r9a09g047e57-smarc: add DA7212 audio codec
support
arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 462 ++++++++++++++++++
.../boot/dts/renesas/r9a09g047e57-smarc.dts | 112 +++++
.../boot/dts/renesas/rzg3e-smarc-som.dtsi | 32 ++
3 files changed, 606 insertions(+)
--
2.25.1
^ permalink raw reply
* [PATCH v6 1/4] arm64: dts: renesas: r9a09g047: Add RZ/G3E Sound support
From: John Madieu @ 2026-06-19 8:39 UTC (permalink / raw)
To: geert+renesas, magnus.damm, robh, krzk+dt, conor+dt
Cc: linux-renesas-soc, devicetree, linux-kernel, john.madieu,
biju.das.jz, John Madieu
In-Reply-To: <20260619083951.3777556-1-john.madieu.xa@bp.renesas.com>
Add the snd_rzg3e node for the RZ/G3E SoC with all sub-components:
- SSI (Serial Sound Interface) units 0-9
- SSIU (Serial Sound Interface Unit) units 0-27
- SRC (Sample Rate Converter) units 0-9
- CTU (Channel Transfer Unit) units 0-7
- DVC (Digital Volume Control) units 0-1
- MIX (Mixer) units 0-1
Sub-node names follow the new RZ/G3E sound binding: unprefixed
'ssi', 'ssiu', 'src', 'dvc', 'mix', 'ctu' wrapper nodes instead of
the legacy 'rcar_sound,xxx' R-Car prefix.
Wire up all 5 DMA controllers (dmac0-dmac4) for each audio sub-node
with repeated channel names, so that the DMA core can pick the first
available controller.
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---
Chqnges:
v6: No changes.
v5:
- Use hexadecimal CPG module clock and reset numbers, for easier
matching with the documentation.
- Use lowercase hex for the SSI reg size (0x1f000).
- Extend the scu reg region to 0x20000 to include the SCU DMAC.
- Drop the per-line clock / reset comments, as clock-names and
reset-names already serve that purpose
arch/arm64/boot/dts/renesas/r9a09g047.dtsi | 462 +++++++++++++++++++++
1 file changed, 462 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
index 1251e329e380..881124f31849 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
+++ b/arch/arm64/boot/dts/renesas/r9a09g047.dtsi
@@ -912,6 +912,468 @@ rsci9: serial@12803000 {
status = "disabled";
};
+ snd_rzg3e: sound@13c00000 {
+ compatible = "renesas,r9a09g047-sound";
+ reg = <0 0x13c00000 0 0x20000>, /* SCU */
+ <0 0x13c20000 0 0x10000>, /* ADG */
+ <0 0x13c30000 0 0x1000>, /* SSIU */
+ <0 0x13c31000 0 0x1f000>, /* SSI */
+ <0 0x13c50000 0 0x10000>; /* Audio DMAC peri peri */
+ reg-names = "scu", "adg", "ssiu", "ssi", "audmapp";
+ clocks = <&cpg CPG_MOD 0xf5>,
+ <&cpg CPG_MOD 0x181>, <&cpg CPG_MOD 0x182>,
+ <&cpg CPG_MOD 0x183>, <&cpg CPG_MOD 0x184>,
+ <&cpg CPG_MOD 0x185>, <&cpg CPG_MOD 0x186>,
+ <&cpg CPG_MOD 0x187>, <&cpg CPG_MOD 0x188>,
+ <&cpg CPG_MOD 0x189>, <&cpg CPG_MOD 0x18a>,
+ <&cpg CPG_MOD 0x174>, <&cpg CPG_MOD 0x175>,
+ <&cpg CPG_MOD 0x176>, <&cpg CPG_MOD 0x177>,
+ <&cpg CPG_MOD 0x178>, <&cpg CPG_MOD 0x179>,
+ <&cpg CPG_MOD 0x17a>, <&cpg CPG_MOD 0x17b>,
+ <&cpg CPG_MOD 0x17c>, <&cpg CPG_MOD 0x17d>,
+ <&cpg CPG_MOD 0x172>, <&cpg CPG_MOD 0x173>,
+ <&cpg CPG_MOD 0x172>, <&cpg CPG_MOD 0x173>,
+ <&cpg CPG_MOD 0x170>, <&cpg CPG_MOD 0x171>,
+ <&cpg CPG_MOD 0xfb>, <&cpg CPG_MOD 0xfc>,
+ <&cpg CPG_MOD 0xfd>, <&cpg CPG_MOD 0xfa>,
+ <&cpg CPG_MOD 0x180>,
+ <&cpg CPG_MOD 0xf6>, <&cpg CPG_MOD 0xf7>,
+ <&cpg CPG_MOD 0x17e>,
+ <&cpg CPG_MOD 0x160>, <&cpg CPG_MOD 0x161>,
+ <&cpg CPG_MOD 0x162>, <&cpg CPG_MOD 0x163>,
+ <&cpg CPG_MOD 0x164>, <&cpg CPG_MOD 0x165>,
+ <&cpg CPG_MOD 0x166>, <&cpg CPG_MOD 0x167>,
+ <&cpg CPG_MOD 0x168>, <&cpg CPG_MOD 0x169>,
+ <&cpg CPG_MOD 0xf8>, <&cpg CPG_MOD 0xf9>;
+ clock-names = "ssi-all",
+ "ssi-0", "ssi-1",
+ "ssi-2", "ssi-3",
+ "ssi-4", "ssi-5",
+ "ssi-6", "ssi-7",
+ "ssi-8", "ssi-9",
+ "src-0", "src-1",
+ "src-2", "src-3",
+ "src-4", "src-5",
+ "src-6", "src-7",
+ "src-8", "src-9",
+ "mix-0", "mix-1",
+ "ctu-0", "ctu-1",
+ "dvc-0", "dvc-1",
+ "audio-clka", "audio-clkb",
+ "audio-clkc", "audio-clki",
+ "ssif_supply",
+ "scu", "scu_x2",
+ "scu_supply",
+ "adg-ssi-0", "adg-ssi-1",
+ "adg-ssi-2", "adg-ssi-3",
+ "adg-ssi-4", "adg-ssi-5",
+ "adg-ssi-6", "adg-ssi-7",
+ "adg-ssi-8", "adg-ssi-9",
+ "audmapp", "adg";
+ power-domains = <&cpg>;
+ resets = <&cpg 0xe1>,
+ <&cpg 0xe2>, <&cpg 0xe3>,
+ <&cpg 0xe4>, <&cpg 0xe5>,
+ <&cpg 0xe6>, <&cpg 0xe7>,
+ <&cpg 0xe8>, <&cpg 0xe9>,
+ <&cpg 0xea>, <&cpg 0xeb>,
+ <&cpg 0xec>, <&cpg 0xee>,
+ <&cpg 0xed>;
+ reset-names = "ssi-all",
+ "ssi-0", "ssi-1",
+ "ssi-2", "ssi-3",
+ "ssi-4", "ssi-5",
+ "ssi-6", "ssi-7",
+ "ssi-8", "ssi-9",
+ "scu", "adg",
+ "audmapp";
+ status = "disabled";
+
+ ctu {
+ ctu00: ctu-0 { };
+ ctu01: ctu-1 { };
+ ctu02: ctu-2 { };
+ ctu03: ctu-3 { };
+ ctu10: ctu-4 { };
+ ctu11: ctu-5 { };
+ ctu12: ctu-6 { };
+ ctu13: ctu-7 { };
+ };
+
+ dvc {
+ dvc0: dvc-0 {
+ dmas = <&dmac0 0x1db3>, <&dmac1 0x1db3>,
+ <&dmac2 0x1db3>, <&dmac3 0x1db3>,
+ <&dmac4 0x1db3>;
+ dma-names = "tx", "tx", "tx", "tx", "tx";
+ };
+ dvc1: dvc-1 {
+ dmas = <&dmac0 0x1db4>, <&dmac1 0x1db4>,
+ <&dmac2 0x1db4>, <&dmac3 0x1db4>,
+ <&dmac4 0x1db4>;
+ dma-names = "tx", "tx", "tx", "tx", "tx";
+ };
+ };
+
+ mix {
+ mix0: mix-0 { };
+ mix1: mix-1 { };
+ };
+
+ src {
+ src0: src-0 {
+ interrupts = <GIC_SPI 902 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1d9f>, <&dmac0 0x1da9>,
+ <&dmac1 0x1d9f>, <&dmac1 0x1da9>,
+ <&dmac2 0x1d9f>, <&dmac2 0x1da9>,
+ <&dmac3 0x1d9f>, <&dmac3 0x1da9>,
+ <&dmac4 0x1d9f>, <&dmac4 0x1da9>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src1: src-1 {
+ interrupts = <GIC_SPI 903 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da0>, <&dmac0 0x1daa>,
+ <&dmac1 0x1da0>, <&dmac1 0x1daa>,
+ <&dmac2 0x1da0>, <&dmac2 0x1daa>,
+ <&dmac3 0x1da0>, <&dmac3 0x1daa>,
+ <&dmac4 0x1da0>, <&dmac4 0x1daa>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src2: src-2 {
+ interrupts = <GIC_SPI 904 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da1>, <&dmac0 0x1dab>,
+ <&dmac1 0x1da1>, <&dmac1 0x1dab>,
+ <&dmac2 0x1da1>, <&dmac2 0x1dab>,
+ <&dmac3 0x1da1>, <&dmac3 0x1dab>,
+ <&dmac4 0x1da1>, <&dmac4 0x1dab>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src3: src-3 {
+ interrupts = <GIC_SPI 905 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da2>, <&dmac0 0x1dac>,
+ <&dmac1 0x1da2>, <&dmac1 0x1dac>,
+ <&dmac2 0x1da2>, <&dmac2 0x1dac>,
+ <&dmac3 0x1da2>, <&dmac3 0x1dac>,
+ <&dmac4 0x1da2>, <&dmac4 0x1dac>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src4: src-4 {
+ interrupts = <GIC_SPI 906 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da3>, <&dmac0 0x1dad>,
+ <&dmac1 0x1da3>, <&dmac1 0x1dad>,
+ <&dmac2 0x1da3>, <&dmac2 0x1dad>,
+ <&dmac3 0x1da3>, <&dmac3 0x1dad>,
+ <&dmac4 0x1da3>, <&dmac4 0x1dad>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src5: src-5 {
+ interrupts = <GIC_SPI 907 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da4>, <&dmac0 0x1dae>,
+ <&dmac1 0x1da4>, <&dmac1 0x1dae>,
+ <&dmac2 0x1da4>, <&dmac2 0x1dae>,
+ <&dmac3 0x1da4>, <&dmac3 0x1dae>,
+ <&dmac4 0x1da4>, <&dmac4 0x1dae>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src6: src-6 {
+ interrupts = <GIC_SPI 908 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da5>, <&dmac0 0x1daf>,
+ <&dmac1 0x1da5>, <&dmac1 0x1daf>,
+ <&dmac2 0x1da5>, <&dmac2 0x1daf>,
+ <&dmac3 0x1da5>, <&dmac3 0x1daf>,
+ <&dmac4 0x1da5>, <&dmac4 0x1daf>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src7: src-7 {
+ interrupts = <GIC_SPI 909 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da6>, <&dmac0 0x1db0>,
+ <&dmac1 0x1da6>, <&dmac1 0x1db0>,
+ <&dmac2 0x1da6>, <&dmac2 0x1db0>,
+ <&dmac3 0x1da6>, <&dmac3 0x1db0>,
+ <&dmac4 0x1da6>, <&dmac4 0x1db0>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src8: src-8 {
+ interrupts = <GIC_SPI 910 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da7>, <&dmac0 0x1db1>,
+ <&dmac1 0x1da7>, <&dmac1 0x1db1>,
+ <&dmac2 0x1da7>, <&dmac2 0x1db1>,
+ <&dmac3 0x1da7>, <&dmac3 0x1db1>,
+ <&dmac4 0x1da7>, <&dmac4 0x1db1>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ src9: src-9 {
+ interrupts = <GIC_SPI 911 IRQ_TYPE_LEVEL_HIGH>;
+ dmas = <&dmac0 0x1da8>, <&dmac0 0x1db2>,
+ <&dmac1 0x1da8>, <&dmac1 0x1db2>,
+ <&dmac2 0x1da8>, <&dmac2 0x1db2>,
+ <&dmac3 0x1da8>, <&dmac3 0x1db2>,
+ <&dmac4 0x1da8>, <&dmac4 0x1db2>;
+ dma-names = "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx";
+ };
+ };
+
+ ssi {
+ ssi0: ssi-0 {
+ interrupts = <GIC_SPI 889 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi1: ssi-1 {
+ interrupts = <GIC_SPI 890 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi2: ssi-2 {
+ interrupts = <GIC_SPI 891 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi3: ssi-3 {
+ interrupts = <GIC_SPI 892 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi4: ssi-4 {
+ interrupts = <GIC_SPI 893 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi5: ssi-5 {
+ interrupts = <GIC_SPI 894 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi6: ssi-6 {
+ interrupts = <GIC_SPI 895 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi7: ssi-7 {
+ interrupts = <GIC_SPI 896 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi8: ssi-8 {
+ interrupts = <GIC_SPI 897 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ ssi9: ssi-9 {
+ interrupts = <GIC_SPI 898 IRQ_TYPE_LEVEL_HIGH>;
+ };
+ };
+
+ ssiu {
+ ssiu00: ssiu-0 {
+ dmas = <&dmac0 0x1d61>, <&dmac0 0x1d62>,
+ <&dmac1 0x1d61>, <&dmac1 0x1d62>,
+ <&dmac2 0x1d61>, <&dmac2 0x1d62>,
+ <&dmac3 0x1d61>, <&dmac3 0x1d62>,
+ <&dmac4 0x1d61>, <&dmac4 0x1d62>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu01: ssiu-1 {
+ dmas = <&dmac0 0x1d63>, <&dmac0 0x1d64>,
+ <&dmac1 0x1d63>, <&dmac1 0x1d64>,
+ <&dmac2 0x1d63>, <&dmac2 0x1d64>,
+ <&dmac3 0x1d63>, <&dmac3 0x1d64>,
+ <&dmac4 0x1d63>, <&dmac4 0x1d64>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu02: ssiu-2 {
+ dmas = <&dmac0 0x1d65>, <&dmac0 0x1d66>,
+ <&dmac1 0x1d65>, <&dmac1 0x1d66>,
+ <&dmac2 0x1d65>, <&dmac2 0x1d66>,
+ <&dmac3 0x1d65>, <&dmac3 0x1d66>,
+ <&dmac4 0x1d65>, <&dmac4 0x1d66>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu03: ssiu-3 {
+ dmas = <&dmac0 0x1d67>, <&dmac0 0x1d68>,
+ <&dmac1 0x1d67>, <&dmac1 0x1d68>,
+ <&dmac2 0x1d67>, <&dmac2 0x1d68>,
+ <&dmac3 0x1d67>, <&dmac3 0x1d68>,
+ <&dmac4 0x1d67>, <&dmac4 0x1d68>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu10: ssiu-4 {
+ dmas = <&dmac0 0x1d69>, <&dmac0 0x1d6a>,
+ <&dmac1 0x1d69>, <&dmac1 0x1d6a>,
+ <&dmac2 0x1d69>, <&dmac2 0x1d6a>,
+ <&dmac3 0x1d69>, <&dmac3 0x1d6a>,
+ <&dmac4 0x1d69>, <&dmac4 0x1d6a>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu11: ssiu-5 {
+ dmas = <&dmac0 0x1d6b>, <&dmac0 0x1d6c>,
+ <&dmac1 0x1d6b>, <&dmac1 0x1d6c>,
+ <&dmac2 0x1d6b>, <&dmac2 0x1d6c>,
+ <&dmac3 0x1d6b>, <&dmac3 0x1d6c>,
+ <&dmac4 0x1d6b>, <&dmac4 0x1d6c>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu12: ssiu-6 {
+ dmas = <&dmac0 0x1d6d>, <&dmac0 0x1d6e>,
+ <&dmac1 0x1d6d>, <&dmac1 0x1d6e>,
+ <&dmac2 0x1d6d>, <&dmac2 0x1d6e>,
+ <&dmac3 0x1d6d>, <&dmac3 0x1d6e>,
+ <&dmac4 0x1d6d>, <&dmac4 0x1d6e>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu13: ssiu-7 {
+ dmas = <&dmac0 0x1d6f>, <&dmac0 0x1d70>,
+ <&dmac1 0x1d6f>, <&dmac1 0x1d70>,
+ <&dmac2 0x1d6f>, <&dmac2 0x1d70>,
+ <&dmac3 0x1d6f>, <&dmac3 0x1d70>,
+ <&dmac4 0x1d6f>, <&dmac4 0x1d70>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu20: ssiu-8 {
+ dmas = <&dmac0 0x1d71>, <&dmac0 0x1d72>,
+ <&dmac1 0x1d71>, <&dmac1 0x1d72>,
+ <&dmac2 0x1d71>, <&dmac2 0x1d72>,
+ <&dmac3 0x1d71>, <&dmac3 0x1d72>,
+ <&dmac4 0x1d71>, <&dmac4 0x1d72>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu21: ssiu-9 {
+ dmas = <&dmac0 0x1d73>, <&dmac0 0x1d74>,
+ <&dmac1 0x1d73>, <&dmac1 0x1d74>,
+ <&dmac2 0x1d73>, <&dmac2 0x1d74>,
+ <&dmac3 0x1d73>, <&dmac3 0x1d74>,
+ <&dmac4 0x1d73>, <&dmac4 0x1d74>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu22: ssiu-10 {
+ dmas = <&dmac0 0x1d75>, <&dmac0 0x1d76>,
+ <&dmac1 0x1d75>, <&dmac1 0x1d76>,
+ <&dmac2 0x1d75>, <&dmac2 0x1d76>,
+ <&dmac3 0x1d75>, <&dmac3 0x1d76>,
+ <&dmac4 0x1d75>, <&dmac4 0x1d76>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu23: ssiu-11 {
+ dmas = <&dmac0 0x1d77>, <&dmac0 0x1d78>,
+ <&dmac1 0x1d77>, <&dmac1 0x1d78>,
+ <&dmac2 0x1d77>, <&dmac2 0x1d78>,
+ <&dmac3 0x1d77>, <&dmac3 0x1d78>,
+ <&dmac4 0x1d77>, <&dmac4 0x1d78>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu30: ssiu-12 {
+ dmas = <&dmac0 0x1d79>, <&dmac0 0x1d7a>,
+ <&dmac1 0x1d79>, <&dmac1 0x1d7a>,
+ <&dmac2 0x1d79>, <&dmac2 0x1d7a>,
+ <&dmac3 0x1d79>, <&dmac3 0x1d7a>,
+ <&dmac4 0x1d79>, <&dmac4 0x1d7a>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu31: ssiu-13 {
+ dmas = <&dmac0 0x1d7b>, <&dmac0 0x1d7c>,
+ <&dmac1 0x1d7b>, <&dmac1 0x1d7c>,
+ <&dmac2 0x1d7b>, <&dmac2 0x1d7c>,
+ <&dmac3 0x1d7b>, <&dmac3 0x1d7c>,
+ <&dmac4 0x1d7b>, <&dmac4 0x1d7c>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu32: ssiu-14 {
+ dmas = <&dmac0 0x1d7d>, <&dmac0 0x1d7e>,
+ <&dmac1 0x1d7d>, <&dmac1 0x1d7e>,
+ <&dmac2 0x1d7d>, <&dmac2 0x1d7e>,
+ <&dmac3 0x1d7d>, <&dmac3 0x1d7e>,
+ <&dmac4 0x1d7d>, <&dmac4 0x1d7e>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu33: ssiu-15 {
+ dmas = <&dmac0 0x1d7f>, <&dmac0 0x1d80>,
+ <&dmac1 0x1d7f>, <&dmac1 0x1d80>,
+ <&dmac2 0x1d7f>, <&dmac2 0x1d80>,
+ <&dmac3 0x1d7f>, <&dmac3 0x1d80>,
+ <&dmac4 0x1d7f>, <&dmac4 0x1d80>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu40: ssiu-16 {
+ dmas = <&dmac0 0x1d81>, <&dmac0 0x1d82>,
+ <&dmac1 0x1d81>, <&dmac1 0x1d82>,
+ <&dmac2 0x1d81>, <&dmac2 0x1d82>,
+ <&dmac3 0x1d81>, <&dmac3 0x1d82>,
+ <&dmac4 0x1d81>, <&dmac4 0x1d82>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu41: ssiu-17 {
+ dmas = <&dmac0 0x1d83>, <&dmac0 0x1d84>,
+ <&dmac1 0x1d83>, <&dmac1 0x1d84>,
+ <&dmac2 0x1d83>, <&dmac2 0x1d84>,
+ <&dmac3 0x1d83>, <&dmac3 0x1d84>,
+ <&dmac4 0x1d83>, <&dmac4 0x1d84>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu42: ssiu-18 {
+ dmas = <&dmac0 0x1d85>, <&dmac0 0x1d86>,
+ <&dmac1 0x1d85>, <&dmac1 0x1d86>,
+ <&dmac2 0x1d85>, <&dmac2 0x1d86>,
+ <&dmac3 0x1d85>, <&dmac3 0x1d86>,
+ <&dmac4 0x1d85>, <&dmac4 0x1d86>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu43: ssiu-19 {
+ dmas = <&dmac0 0x1d87>, <&dmac0 0x1d88>,
+ <&dmac1 0x1d87>, <&dmac1 0x1d88>,
+ <&dmac2 0x1d87>, <&dmac2 0x1d88>,
+ <&dmac3 0x1d87>, <&dmac3 0x1d88>,
+ <&dmac4 0x1d87>, <&dmac4 0x1d88>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu50: ssiu-20 {
+ dmas = <&dmac0 0x1d89>, <&dmac0 0x1d8a>,
+ <&dmac1 0x1d89>, <&dmac1 0x1d8a>,
+ <&dmac2 0x1d89>, <&dmac2 0x1d8a>,
+ <&dmac3 0x1d89>, <&dmac3 0x1d8a>,
+ <&dmac4 0x1d89>, <&dmac4 0x1d8a>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu60: ssiu-21 {
+ dmas = <&dmac0 0x1d8b>, <&dmac0 0x1d8c>,
+ <&dmac1 0x1d8b>, <&dmac1 0x1d8c>,
+ <&dmac2 0x1d8b>, <&dmac2 0x1d8c>,
+ <&dmac3 0x1d8b>, <&dmac3 0x1d8c>,
+ <&dmac4 0x1d8b>, <&dmac4 0x1d8c>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu70: ssiu-22 {
+ dmas = <&dmac0 0x1d8d>, <&dmac0 0x1d8e>,
+ <&dmac1 0x1d8d>, <&dmac1 0x1d8e>,
+ <&dmac2 0x1d8d>, <&dmac2 0x1d8e>,
+ <&dmac3 0x1d8d>, <&dmac3 0x1d8e>,
+ <&dmac4 0x1d8d>, <&dmac4 0x1d8e>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu80: ssiu-23 {
+ dmas = <&dmac0 0x1d8f>, <&dmac0 0x1d90>,
+ <&dmac1 0x1d8f>, <&dmac1 0x1d90>,
+ <&dmac2 0x1d8f>, <&dmac2 0x1d90>,
+ <&dmac3 0x1d8f>, <&dmac3 0x1d90>,
+ <&dmac4 0x1d8f>, <&dmac4 0x1d90>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu90: ssiu-24 {
+ dmas = <&dmac0 0x1d91>, <&dmac0 0x1d92>,
+ <&dmac1 0x1d91>, <&dmac1 0x1d92>,
+ <&dmac2 0x1d91>, <&dmac2 0x1d92>,
+ <&dmac3 0x1d91>, <&dmac3 0x1d92>,
+ <&dmac4 0x1d91>, <&dmac4 0x1d92>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu91: ssiu-25 {
+ dmas = <&dmac0 0x1d93>, <&dmac0 0x1d94>,
+ <&dmac1 0x1d93>, <&dmac1 0x1d94>,
+ <&dmac2 0x1d93>, <&dmac2 0x1d94>,
+ <&dmac3 0x1d93>, <&dmac3 0x1d94>,
+ <&dmac4 0x1d93>, <&dmac4 0x1d94>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu92: ssiu-26 {
+ dmas = <&dmac0 0x1d95>, <&dmac0 0x1d96>,
+ <&dmac1 0x1d95>, <&dmac1 0x1d96>,
+ <&dmac2 0x1d95>, <&dmac2 0x1d96>,
+ <&dmac3 0x1d95>, <&dmac3 0x1d96>,
+ <&dmac4 0x1d95>, <&dmac4 0x1d96>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ ssiu93: ssiu-27 {
+ dmas = <&dmac0 0x1d97>, <&dmac0 0x1d98>,
+ <&dmac1 0x1d97>, <&dmac1 0x1d98>,
+ <&dmac2 0x1d97>, <&dmac2 0x1d98>,
+ <&dmac3 0x1d97>, <&dmac3 0x1d98>,
+ <&dmac4 0x1d97>, <&dmac4 0x1d98>;
+ dma-names = "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx", "tx", "rx";
+ };
+ };
+ };
+
wdt1: watchdog@14400000 {
compatible = "renesas,r9a09g047-wdt", "renesas,r9a09g057-wdt";
reg = <0 0x14400000 0 0x400>;
--
2.25.1
^ permalink raw reply related
* [PATCH v6 2/4] arm64: dts: renesas: rzg3e-smarc-som: Add Versa3 clock generator
From: John Madieu @ 2026-06-19 8:39 UTC (permalink / raw)
To: geert+renesas, magnus.damm, robh, krzk+dt, conor+dt
Cc: linux-renesas-soc, devicetree, linux-kernel, john.madieu,
biju.das.jz, John Madieu
In-Reply-To: <20260619083951.3777556-1-john.madieu.xa@bp.renesas.com>
Add the Renesas 5P35023 (Versa3) programmable clock generator on the
I2C2 bus along with its 24MHz input clock (x2 oscillator) to feed the
audio subsystem.
The Versa3 provides the following clock outputs:
- Output 0: 24MHz (reference)
- Output 1: 12.288MHz (audio, 48kHz family)
- Output 2: 11.2896MHz (audio, 44.1kHz family)
- Output 3: 12.288MHz (audio)
- Output 4: 25MHz (DIFF1, Ethernet)
These clocks are required for the audio codec and the Ethernet
controller found on the RZ/G3E SMARC EVK.
Output 5 (DIFF2) is left out, as it is not connected on this board.
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---
Changes:
v6:
- Actually drop Versa3 output 5 (DIFF2) from assigned-clocks and
assigned-clock-rates; v5 documented the removal in the commit
message but left the entry in the DTS.
v5:
- Document output 4 (DIFF1) in the commit message; it is needed for
Ethernet.
.../boot/dts/renesas/rzg3e-smarc-som.dtsi | 20 +++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi b/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
index 15c22dbf0ad3..455ed35ae5d3 100644
--- a/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
@@ -78,6 +78,12 @@ reg_vdd0p8v_others: regulator-vdd0p8v-others {
regulator-always-on;
};
+ x2: x2-clock {
+ compatible = "fixed-clock";
+ #clock-cells = <0>;
+ clock-frequency = <24000000>;
+ };
+
/* 32.768kHz crystal */
x3: x3-clock {
compatible = "fixed-clock";
@@ -137,6 +143,20 @@ raa215300: pmic@12 {
interrupts-extended = <&pinctrl RZG3E_GPIO(S, 1) IRQ_TYPE_EDGE_FALLING>;
};
+
+ versa3: clock-generator@68 {
+ compatible = "renesas,5p35023";
+ reg = <0x68>;
+ #clock-cells = <1>;
+ clocks = <&x2>;
+
+ assigned-clocks = <&versa3 0>, <&versa3 1>,
+ <&versa3 2>, <&versa3 3>,
+ <&versa3 4>;
+ assigned-clock-rates = <24000000>, <12288000>,
+ <11289600>, <12288000>,
+ <25000000>;
+ };
};
&i3c {
--
2.25.1
^ permalink raw reply related
* [PATCH v6 3/4] arm64: dts: renesas: rzg3e-smarc-som: add audio pinmux definitions
From: John Madieu @ 2026-06-19 8:39 UTC (permalink / raw)
To: geert+renesas, magnus.damm, robh, krzk+dt, conor+dt
Cc: linux-renesas-soc, devicetree, linux-kernel, john.madieu,
biju.das.jz, John Madieu
In-Reply-To: <20260619083951.3777556-1-john.madieu.xa@bp.renesas.com>
Add pinmux definitions for SSI3/SSI4 audio interface on RZ/G3E SMARC SoM:
- sound_clk_pins: AUDIO_CLKB and AUDIO_CLKC clock outputs
- sound_pins: SSI3_SCK, SSI3_WS, SSI3_SDATA (playback) and
SSI4_SDATA (capture)
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---
Changes:
v6: No changes.
v5:
- Rename the sound_clk / sound pinctrl node names to use hyphens
instead of underscores.
- Sort the sound pinmux entries by GPIO number.
arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi | 12 ++++++++++++
1 file changed, 12 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi b/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
index 455ed35ae5d3..0e6dc84e0199 100644
--- a/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
+++ b/arch/arm64/boot/dts/renesas/rzg3e-smarc-som.dtsi
@@ -352,6 +352,18 @@ sd2-pwen {
};
};
+ sound_clk_pins: sound-clk {
+ pinmux = <RZG3E_PORT_PINMUX(4, 2, 8)>, /* AUDIO_CLKB */
+ <RZG3E_PORT_PINMUX(4, 3, 8)>; /* AUDIO_CLKC */
+ };
+
+ sound_pins: sound {
+ pinmux = <RZG3E_PORT_PINMUX(0, 2, 9)>, /* SSI3_SDATA */
+ <RZG3E_PORT_PINMUX(0, 3, 9)>, /* SSI3_SCK */
+ <RZG3E_PORT_PINMUX(0, 4, 9)>, /* SSI3_WS */
+ <RZG3E_PORT_PINMUX(0, 5, 9)>; /* SSI4_SDATA */
+ };
+
xspi_pins: xspi0 {
pinmux = <RZG3E_PORT_PINMUX(M, 0, 0)>, /* XSPI0_IO0 */
<RZG3E_PORT_PINMUX(M, 1, 0)>, /* XSPI0_IO1 */
--
2.25.1
^ permalink raw reply related
* [PATCH v6 4/4] arm64: dts: renesas: r9a09g047e57-smarc: add DA7212 audio codec support
From: John Madieu @ 2026-06-19 8:39 UTC (permalink / raw)
To: geert+renesas, magnus.damm, robh, krzk+dt, conor+dt
Cc: linux-renesas-soc, devicetree, linux-kernel, john.madieu,
biju.das.jz, John Madieu
In-Reply-To: <20260619083951.3777556-1-john.madieu.xa@bp.renesas.com>
RZ/G3E SMARC board has a DA7212 audio codec connected via I2C1 for
sound input/output using SSI3/SSI4 where:
- The codec receives its master clock from the Versa3 clock
generator present on the SoM
- SSI4 shares clock pins with SSI3 to provide a separate data
line for full-duplex audio capture.
Enable audio support on RZ/G3E SMARC2 EVK boards with a DA7212 audio codec.
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: John Madieu <john.madieu.xa@bp.renesas.com>
---
Changes:
v6: No changes.
v5:
- Drop the unnecessary #address-cells / #size-cells from the
codec@1a node; the port child has no unit address or reg, and the
da7212 binding sets unevaluatedProperties: false.
.../boot/dts/renesas/r9a09g047e57-smarc.dts | 112 ++++++++++++++++++
1 file changed, 112 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts b/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
index 6372f582a7c4..ac525b73c1bb 100644
--- a/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
+++ b/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
@@ -32,6 +32,37 @@
#include "rzg3e-smarc-som.dtsi"
#include "renesas-smarc2.dtsi"
+/*
+ * SSI-DA7212
+ *
+ * These commands are required when Playback/Capture
+ *
+ * amixer -q cset name='Aux Switch' on
+ * amixer -q cset name='Mixin Left Aux Left Switch' on
+ * amixer -q cset name='Mixin Right Aux Right Switch' on
+ * amixer -q cset name='ADC Switch' on
+ * amixer -q cset name='Mixout Right Mixin Right Switch' off
+ * amixer -q cset name='Mixout Left Mixin Left Switch' off
+ * amixer -q cset name='Headphone Volume' 70%
+ * amixer -q cset name='Headphone Switch' on
+ * amixer -q cset name='Mixout Left DAC Left Switch' on
+ * amixer -q cset name='Mixout Right DAC Right Switch' on
+ * amixer -q cset name='DAC Left Source MUX' 'DAI Input Left'
+ * amixer -q cset name='DAC Right Source MUX' 'DAI Input Right'
+ * amixer -q sset 'Mic 1 Amp Source MUX' 'MIC_P'
+ * amixer -q sset 'Mic 2 Amp Source MUX' 'MIC_P'
+ * amixer -q sset 'Mixin Left Mic 1' on
+ * amixer -q sset 'Mixin Right Mic 2' on
+ * amixer -q sset 'Mic 1' 90% on
+ * amixer -q sset 'Mic 2' 90% on
+ * amixer -q sset 'Lineout' 80% on
+ * amixer -q set "Headphone" 100% on
+ *
+ * When Capture chained with DVC, use this command to amplify sound
+ * amixer set 'DVC In',0 80%
+ * For playback, use: amixer set 'DVC Out',0 80%
+ */
+
/ {
model = "Renesas SMARC EVK version 2 based on r9a09g047e57";
compatible = "renesas,smarc2-evk", "renesas,rzg3e-smarcm",
@@ -55,6 +86,22 @@ vqmmc_sd1_pvdd: regulator-vqmmc-sd1-pvdd {
gpios-states = <0>;
states = <3300000 0>, <1800000 1>;
};
+
+ sound_card: sound {
+ compatible = "audio-graph-card";
+
+ label = "snd-rzg3e";
+
+ dais = <&rsnd_port0>; /* DA7212 */
+ };
+};
+
+&audio_clkb {
+ clock-frequency = <11289600>;
+};
+
+&audio_clkc {
+ clock-frequency = <12288000>;
};
&canfd {
@@ -99,6 +146,35 @@ &i2c0 {
pinctrl-names = "default";
};
+&i2c1 {
+ da7212: codec@1a {
+ compatible = "dlg,da7212";
+ #sound-dai-cells = <0>;
+ reg = <0x1a>;
+
+ clocks = <&versa3 1>;
+ clock-names = "mclk";
+
+ dlg,micbias1-lvl = <2500>;
+ dlg,micbias2-lvl = <2500>;
+ dlg,dmic-data-sel = "lrise_rfall";
+ dlg,dmic-samplephase = "between_clkedge";
+ dlg,dmic-clkrate = <3000000>;
+
+ VDDA-supply = <®_1p8v>;
+ VDDSP-supply = <®_3p3v>;
+ VDDMIC-supply = <®_3p3v>;
+ VDDIO-supply = <®_1p8v>;
+
+ port {
+ da7212_endpoint: endpoint {
+ remote-endpoint = <&rsnd_endpoint0>;
+ mclk-fs = <256>;
+ };
+ };
+ };
+};
+
&keys {
pinctrl-0 = <&nmi_pins>;
pinctrl-names = "default";
@@ -280,6 +356,42 @@ &sdhi1 {
vqmmc-supply = <&vqmmc_sd1_pvdd>;
};
+&snd_rzg3e {
+ pinctrl-0 = <&sound_clk_pins &sound_pins>;
+ pinctrl-names = "default";
+
+ status = "okay";
+
+ /* audio_clkout */
+ #clock-cells = <0>;
+ clock-frequency = <11289600>;
+
+ /* Multi DAI */
+ #sound-dai-cells = <1>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ rsnd_port0: port@0 {
+ reg = <0>;
+ rsnd_endpoint0: endpoint {
+ remote-endpoint = <&da7212_endpoint>;
+
+ dai-format = "i2s";
+ bitclock-master = <&rsnd_endpoint0>;
+ frame-master = <&rsnd_endpoint0>;
+
+ playback = <&ssi3>, <&src1>, <&dvc1>;
+ capture = <&ssi4>, <&src0>, <&dvc0>;
+ };
+ };
+ };
+};
+
+&ssi4 {
+ shared-pin;
+};
+
&usb3_phy {
status = "okay";
};
--
2.25.1
^ permalink raw reply related
* Re: [PATCH v3 04/21] pinctrl: starfive: Add StarFive JHB100 sys0 controller driver
From: Changhuang Liang @ 2026-06-19 8:41 UTC (permalink / raw)
To: Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Emil Renner Berthing, Paul Walmsley, Albert Ou, Palmer Dabbelt,
Alexandre Ghiti, Philipp Zabel, Bartosz Golaszewski,
linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, linux-riscv@lists.infradead.org,
Lianfeng Ouyang
In-Reply-To: <CAD++jL=Qd8ADR_kX2Q7msM4Dd0xFayPGM4ZzB3uv2ufvkuybtQ@mail.gmail.com>
Hi, Linus
Thanks for the review.
I will first try making revisions according to your suggestions below. It may take some time for
the next version. If I run into any issues during the subsequent revisions, I may bother you then.
Best Regards,
Changhuang
> Hi Changhuang,
>
> thanks for your patch!
>
> On Wed, Jun 3, 2026 at 7:54 AM Changhuang Liang
> <changhuang.liang@starfivetech.com> wrote:
>
> > Add pinctrl driver for StarFive JHB100 SoC System-0(sys0) pinctrl
> > controller.
> >
> > Co-developed-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
> > Signed-off-by: Lianfeng Ouyang <lianfeng.ouyang@starfivetech.com>
> > Signed-off-by: Changhuang Liang <changhuang.liang@starfivetech.com>
>
> This patch adds generic infrastructure "JHB100" that is then used by several
> drivers does it not?
>
> Write something about that and some about the design in the commit
> message.
>
> > +++ b/drivers/pinctrl/starfive/pinctrl-starfive-jhb100-sys0.c
> > @@ -0,0 +1,123 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later
> > +/*
> > + * Pinctrl / GPIO driver for StarFive JHB100 SoC System-0 domain
> > + *
> > + * Copyright (C) 2024 StarFive Technology Co., Ltd.
> > + * Author: Alex Soo <yuklin.soo@starfivetech.com>
>
> Shouldn't this person be in the Signed-off-by?
>
> I guess it's not legally necessary but feels appropriate.
>
> > +static struct config_reg_layout_desc jhb100_sys0_pinctrl_crl_desc[] = {
> > + {
> > + .pin_start = 0,
> > + .pin_cnt = 4,
> > + .drive_strength_2bit = { .shift = 0, .width
> = 2 },
> > + .input_enable = { .shift =
> 2, .width = 1 },
> > + .pull_down = { .shift =
> 3, .width = 1 },
> > + .pull_up = { .shift =
> 4, .width = 1 },
> > + .slew_rate = { .shift =
> 5, .width = 1 },
> > + .schmitt_trigger_select = { .shift = 6, .width =
> 1 },
> > + .reserved = { .shift =
> 7, .width = 8 },
> > + .debounce_width = { .shift =
> 15, .width = 17 },
> > + },
> > + {
> > + .pin_start = 4,
> > + .pin_cnt = 5,
> > + .schmitt_trigger_select = { .shift = 0, .width =
> 1 },
> > + .reserved = { .shift =
> 1, .width = 31 },
> > + },
> > + {
> > + .pin_start = 9,
> > + .pin_cnt = 1,
> > + .drive_strength_2bit = { .shift = 0, .width
> = 2 },
> > + .slew_rate = { .shift =
> 2, .width = 1 },
> > + .reserved = { .shift =
> 3, .width = 29 },
> > + },
> > + {
> > + .pin_start = 10,
> > + .pin_cnt = 1,
> > + .drive_strength_2bit = { .shift = 0, .width
> = 2 },
> > + .input_enable = { .shift =
> 2, .width = 1 },
> > + .pull_down = { .shift =
> 3, .width = 1 },
> > + .pull_up = { .shift =
> 4, .width = 1 },
> > + .slew_rate = { .shift =
> 5, .width = 1 },
> > + .schmitt_trigger_select = { .shift = 6, .width =
> 1 },
> > + .reserved = { .shift =
> 7, .width = 25 },
> > + },
> > + { 0xff },
> > +};
>
> Would it be appropriate to index the different register variants with a enum
> with a good name so it is easy to understand which variant each entry in the
> array is?
>
> > +#include <linux/string.h>
> > +#include <linux/sort.h>
>
> Hm why... I guess I will see.
>
> > +#define JHB100_DEBOUNCE_WIDTH_STAGES_MAX 0x1FFFFU
>
> Is that a GENMASK(16,0)?
>
> Since it seems to have something to do with bitfield widths.
>
> > +/* i2c open-drain pull-up select */
> > +#define JHB100_I2C_OPEN_DRAIN_PU_600_OHMS 0
> > +#define JHB100_I2C_OPEN_DRAIN_PU_900_OHMS 1
> > +#define JHB100_I2C_OPEN_DRAIN_PU_1200_OHMS 2
> > +#define JHB100_I2C_OPEN_DRAIN_PU_2000_OHMS 3
>
> Very nice and to the point! It's easy to read and understand drivers that are
> writing things out explicitly like this!
>
> > +#define JHB100_NR_GPIOS_PER_BANK 32
> (...)
> > +static inline struct jhb100_gpio_bank *jhb100_gc_to_bank(struct
> > +gpio_chip *gc) {
> > + return container_of(gc, struct jhb100_gpio_bank, gc); }
> > +
> > +static unsigned int jhb100_gpio_to_pin(struct gpio_chip *gc, unsigned
> > +int gpio) {
> > + struct jhb100_gpio_bank *bank = jhb100_gc_to_bank(gc);
> > +
> > + return bank->id * JHB100_NR_GPIOS_PER_BANK + gpio; }
>
> This usually tells me that GPIO_GENERIC can be used but maybe this has been
> discussed before...
>
> > +static const struct pinctrl_ops jhb100_pinctrl_ops = {
> > + .get_groups_count = pinctrl_generic_get_group_count,
> > + .get_group_name = pinctrl_generic_get_group_name,
> > + .get_group_pins = pinctrl_generic_get_group_pins,
> > + .dt_node_to_map =
> pinctrl_generic_pins_function_dt_node_to_map,
> > + .dt_free_map = pinctrl_utils_free_map,
> > +};
>
> Nice use of the generic helpers!
>
> > +static void jhb100_set_gpioval(struct jhb100_pinctrl *sfp, unsigned int pin,
> > + unsigned int val) {
> > + const struct jhb100_pinctrl_domain_info *info = sfp->info;
> > + unsigned int offset = 4 * (pin / 32);
> > + unsigned int shift = 1 * (pin % 32);
> > + unsigned int fs_offset = 4 * (pin / 16);
> > + unsigned int fs_shift = 2 * (pin % 16);
> > + u32 func_sel_mask;
> > + u32 dout, doen, fs;
> > + void __iomem *reg_gpio_o;
> > + void __iomem *reg_gpio_oen;
> > + void __iomem *reg_gpio_func_sel;
> > + unsigned long flags;
> > +
> > + reg_gpio_o = sfp->base + info->regs->output + offset;
> > + reg_gpio_oen = sfp->base + info->regs->output_en + offset;
> > + reg_gpio_func_sel = sfp->base + info->regs->func_sel.reg +
> > + fs_offset;
>
> The part from here:
>
> > + func_sel_mask = GENMASK(info->regs->func_sel.width_per_pin -
> > + 1, 0) << fs_shift;
> (...)
> > +
> > + raw_spin_lock_irqsave(&sfp->lock, flags);
> > + fs = readl_relaxed(reg_gpio_func_sel);
> > + if (fs & func_sel_mask) {
> > + fs &= ~func_sel_mask;
> > + writel_relaxed(fs, reg_gpio_func_sel);
> > + }
>
> ..to here seems to reimplement the shortcut
> .gpio_request_enable() in struct pinmux_ops.
>
> Then this:
>
> > + dout = val << shift;
> > + doen = 0;
>
> > + dout |= readl_relaxed(reg_gpio_o) & ~BIT(shift);
> > + writel_relaxed(dout, reg_gpio_o);
> > + doen |= readl_relaxed(reg_gpio_oen) & ~BIT(shift);
> > + writel_relaxed(doen, reg_gpio_oen);
>
> Seems more like the actual code that should be here.
>
> > + raw_spin_unlock_irqrestore(&sfp->lock, flags);
>
> Please use guards for these spinlocks. They make for less bugs.
>
> guard(raw_spinlock_irqsave)(&sfp->lock);
>
> > +static const struct pinmux_ops jhb100_pinmux_ops = {
> > + .get_functions_count = pinmux_generic_get_function_count,
> > + .get_function_name = pinmux_generic_get_function_name,
> > + .get_function_groups = pinmux_generic_get_function_groups,
> > + .set_mux = jhb100_set_mux,
> > +};
>
> Implement .gpio_request_enable() (see above) and
> .gpio_set_direction() see below.
>
> Maybe also .gpio_disable_free() if you need to deconfigure stuff when a pin is
> release from GPIO.
>
> > +static const struct pinconf_ops jhb100_pinconf_ops = {
> > + .pin_config_get = jhb100_pinconf_get,
> > + .pin_config_set = jhb100_pinconf_set,
> > + .pin_config_group_get = jhb100_pinconf_group_get,
> > + .pin_config_group_set = jhb100_pinconf_group_set,
> > + .is_generic = true,
> > +};
>
> Overall this looks nice, good use of the group config!
>
> > +static int jhb100_gpio_get_direction(struct gpio_chip *gc,
> > + unsigned int gpio) {
> > + struct jhb100_gpio_bank *bank = jhb100_gc_to_bank(gc);
> > + struct jhb100_pinctrl *sfp = gpiochip_get_data(gc);
> > + const struct jhb100_pinctrl_domain_info *info = sfp->info;
> > + unsigned int offset = 4 * bank->id;
> > + u32 doen;
> > + void __iomem *reg_gpio_oen;
> > +
> > + reg_gpio_oen = sfp->base + info->regs->output_en + offset;
> > +
> > + doen = (readl_relaxed(reg_gpio_oen) & BIT(gpio)) >> gpio;
> > +
> > + return doen == GPOEN_ENABLE ? GPIO_LINE_DIRECTION_OUT :
> > +GPIO_LINE_DIRECTION_IN; }
> > +
> > +static int jhb100_gpio_direction_input(struct gpio_chip *gc,
> > + unsigned int gpio) {
> > + struct jhb100_pinctrl *sfp = gpiochip_get_data(gc);
> > + struct device *dev = sfp->dev;
> > + struct config_reg_layout_desc *crl_desc;
> > + unsigned int pin = jhb100_gpio_to_pin(gc, gpio);
> > +
> > + crl_desc = get_crl_desc_by_pin(sfp, pin);
> > + if (!crl_desc) {
> > + dev_err(dev, "pin %d can't not found reg layout
> descriptor\n",
> > + pin);
> > + return -EINVAL;
> > + }
> > +
> > + jhb100_padcfg_rmw(sfp, pin,
> > + RL_DESC_GENMASK(crl_desc,
> input_enable) |
> > + RL_DESC_GENMASK(crl_desc,
> schmitt_trigger_select),
> > + RL_DESC_GENMASK(crl_desc,
> input_enable) |
> > + RL_DESC_GENMASK(crl_desc,
> > + schmitt_trigger_select));
>
> Instead of doing these writes directly into the config registers, implement
> .gpio_set_direction() in struct pinmux_ops and call the pinmux generic
> back-end.
>
> > +static int jhb100_gpio_direction_output(struct gpio_chip *gc,
> > + unsigned int gpio, int
> value)
> > +{
> > + struct jhb100_pinctrl *sfp = gpiochip_get_data(gc);
> > + struct device *dev = sfp->dev;
> > + struct config_reg_layout_desc *crl_desc;
> > + unsigned int pin = jhb100_gpio_to_pin(gc, gpio);
> > +
> > + jhb100_set_one_pin_mux(sfp, pin, 0,
> > + value ? GPOUT_HIGH :
> GPOUT_LOW);
> > +
> > + crl_desc = get_crl_desc_by_pin(sfp, pin);
> > + if (!crl_desc) {
> > + dev_err(dev, "pin %d can't not found reg layout
> descriptor\n",
> > + pin);
> > + return -EINVAL;
> > + }
> > +
> > + jhb100_padcfg_rmw(sfp, pin,
> > + RL_DESC_GENMASK(crl_desc,
> input_enable) |
> > + RL_DESC_GENMASK(crl_desc,
> schmitt_trigger_select) |
> > + RL_DESC_GENMASK(crl_desc, pull_down) |
> > + RL_DESC_GENMASK(crl_desc, pull_up),
> > + 0);
>
> Dito.
>
> > +static int jhb100_gpio_get(struct gpio_chip *gc, unsigned int gpio) {
> > + struct jhb100_gpio_bank *bank = jhb100_gc_to_bank(gc);
> > + struct jhb100_pinctrl *sfp = gpiochip_get_data(gc);
> > + const struct jhb100_pinctrl_domain_info *info = sfp->info;
> > + unsigned int offset = 4 * bank->id;
> > + u32 doen = 0;
> > + void __iomem *reg_gpio_oen;
> > + void __iomem *reg;
> > + unsigned long flags;
> > +
> > + reg_gpio_oen = sfp->base + info->regs->output_en + offset;
> > + reg = sfp->base + info->regs->gpio_status + offset;
> > +
> > + raw_spin_lock_irqsave(&sfp->lock, flags);
> > + doen = readl_relaxed(reg_gpio_oen) | BIT(gpio);
> > + writel_relaxed(doen, reg_gpio_oen);
> > + raw_spin_unlock_irqrestore(&sfp->lock, flags);
>
> Why *on* *earth* are you read-modify-writing the output enable register in
> the *get* function? Is this a copy-on-paste error??
>
> > + return !!(readl_relaxed(reg) & BIT(gpio % 32));
>
> Also you never actuall read reg .... ehhhh this is a glaring bug.
>
> > +static int jhb100_gpio_set(struct gpio_chip *gc, unsigned int gpio,
> > +int value) {
> > + struct jhb100_gpio_bank *bank = jhb100_gc_to_bank(gc);
> > + struct jhb100_pinctrl *sfp = gpiochip_get_data(gc);
> > + const struct jhb100_pinctrl_domain_info *info = sfp->info;
> > + unsigned int offset = 4 * bank->id;
> > + void __iomem *reg_dout;
> > + u32 dout;
> > + unsigned long flags;
> > +
> > + reg_dout = sfp->base + info->regs->output + offset;
> > + dout = (value ? GPOUT_HIGH : GPOUT_LOW) << gpio;
> > +
> > + raw_spin_lock_irqsave(&sfp->lock, flags);
> > + dout |= readl_relaxed(reg_dout) & ~BIT(gpio);
> > + writel_relaxed(dout, reg_dout);
> > + raw_spin_unlock_irqrestore(&sfp->lock, flags);
> > +
> > + return 0;
> > +}
>
> This looks right, did you only test output and not input..?
>
> > +static const struct irq_chip jhb100_irq_chip = {
> > + .irq_ack = jhb100_irq_ack,
> > + .irq_mask = jhb100_irq_mask,
> > + .irq_mask_ack = jhb100_irq_mask_ack,
> > + .irq_unmask = jhb100_irq_unmask,
> > + .irq_set_type = jhb100_irq_set_type,
> > + .irq_set_wake = jhb100_irq_set_wake,
> > + .irq_print_chip = jhb100_irq_print_chip,
> > + .flags = IRQCHIP_SET_TYPE_MASKED |
> > + IRQCHIP_IMMUTABLE |
> > + IRQCHIP_ENABLE_WAKEUP_ON_SUSPEND
> |
> > + IRQCHIP_MASK_ON_SUSPEND |
> > + IRQCHIP_SKIP_SET_WAKE,
> > + GPIOCHIP_IRQ_RESOURCE_HELPERS, };
>
> The irqchip looks good!
>
> > +static int field_compare(const void *a, const void *b) {
> > + const struct field_info *fa = (const struct field_info *)a;
> > + const struct field_info *fb = (const struct field_info *)b;
> > +
> > + if (fa->shift < fb->shift)
> > + return -1;
> > +
> > + if (fa->shift > fb->shift)
> > + return 1;
> > +
> > + return 0;
> > +}
>
> Are you sure the kernel doesn't already have a helper like this...
>
> > + sfp->num_banks = DIV_ROUND_UP(sfp->ngpios,
> > + JHB100_NR_GPIOS_PER_BANK);
> > +
> > + for (unsigned int i = 0; i < sfp->num_banks; i++) {
> > + if (sfp->ngpios > (i + 1) *
> JHB100_NR_GPIOS_PER_BANK)
> > + sfp->banks[i].gc.ngpio = (i + 1) *
> JHB100_NR_GPIOS_PER_BANK;
> > + else
> > + sfp->banks[i].gc.ngpio = sfp->ngpios - i *
> > + JHB100_NR_GPIOS_PER_BANK;
>
> This looks completely bananas, shouldn't this be simply:
>
> sfp->banks[i].gc.ngpio = JHB100_NR_GPIOS_PER_BANK;
>
> ???
>
> What is getting assigned to ngpios looks like a gpiochip base, and have all the
> signs of a real bad AI hallucination.
>
> > +
> > + sfp->banks[i].id = i;
> > +
> > + sfp->banks[i].gc.parent = dev;
> > + sfp->banks[i].gc.label = dev_name(dev);
> > + sfp->banks[i].gc.owner = THIS_MODULE;
> > + sfp->banks[i].gc.request = pinctrl_gpio_request;
>
> Use
> gpiochip_generic_request
>
> > + sfp->banks[i].gc.free = pinctrl_gpio_free;
>
> Use
> gpiochip_generic_free
>
> These calls will do what you want, and also check that the right gpio ranges
> are available.
>
> Make sure you add GPIO ranges (the mapping between pin control pins and
> corresponding GPIO offsets) for this to work properly.
>
> I'm pretty sure you can have a generic pin config backend as well.
>
> sfp->banks[i].gc.set_config = gpiochip_generic_config;
>
> This will make config calls to the gpiochip call into the pinctrl backend = what
> you want.
>
> > + sfp->banks[i].gc.get_direction =
> jhb100_gpio_get_direction;
> > + sfp->banks[i].gc.direction_input =
> jhb100_gpio_direction_input;
> > + sfp->banks[i].gc.direction_output =
> jhb100_gpio_direction_output;
> > + sfp->banks[i].gc.get = jhb100_gpio_get;
> > + sfp->banks[i].gc.set = jhb100_gpio_set;
> > + sfp->banks[i].gc.set_config = gpiochip_generic_config;
> > + sfp->banks[i].gc.base = -1;
> > + sfp->banks[i].gc.of_gpio_n_cells = 3;
> > + sfp->banks[i].gc.of_node_instance_match =
> > + starfive_of_node_instance_match;
>
> Since you have a threecell scheme with 32 gpios
> (JHB100_NR_GPIOS_PER_BANK) per instance (right? the ngpios code above
> made me really confused....) you should be able so select GPIO_GENERIC,
> #include <linux/gpio/generic.h> and use the generic GPIO pretty much the
> same way drivers/gpio/gpio-spacemit-k1.c does it, check that driver out
> (especially spacemit_gpio_add_bank()).
>
> Yours,
> Linus Walleij
^ permalink raw reply
* Re: [PATCH 0/5] Shikra: Add DT support for ice, rng and qce
From: Kuldeep Singh @ 2026-06-19 8:43 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Vinod Koul, Thara Gopinath,
Konrad Dybcio, Frank Li, Andy Gross, Eric Biggers
Cc: Harshal Dev, linux-arm-msm, linux-crypto, devicetree,
linux-kernel, dmaengine
In-Reply-To: <20260521-shikra_crypto_changse-v1-0-0154cc9cc0de@oss.qualcomm.com>
On 21-05-2026 18:47, Kuldeep Singh wrote:
> This patchseries attempt to enable sdhc-ice, rng and qce on shikra
> platform similar to other platforms.
>
> Previously, the 3 dt-bindigs/DT changes were sent as individual series
> and with feedback received, clubbed them together as all belong to same
> crypto subsystem.
>
> Here's link to old patchsets.
> QCE: https://lore.kernel.org/lkml/20260515-shikra_qcrypto-v1-0-80f07b345c29@oss.qualcomm.com/
Hi Eric,
As selftests issues for QCE are now fixed[1], so shikra series should be
good to proceed? as your concerns[2] are now addressed.
I am waiting for merge window to end and will send next rev post that.
[1]
https://lore.kernel.org/linux-arm-msm/20260617-qce-fix-self-tests-v3-0-ecc2b4dedcfd@oss.qualcomm.com/
[2] https://lore.kernel.org/lkml/20260522024912.GC5937@quark/
--
Regards
Kuldeep
^ permalink raw reply
* Re: [PATCH v6 4/4] arm64: dts: renesas: r9a09g047e57-smarc: add DA7212 audio codec support
From: sashiko-bot @ 2026-06-19 9:00 UTC (permalink / raw)
To: John Madieu; +Cc: devicetree, wsa+renesas, robh, conor+dt
In-Reply-To: <20260619083951.3777556-5-john.madieu.xa@bp.renesas.com>
Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The `&i2c1` node is missing `status = "okay";`, meaning the I2C controller and the DA7212 audio codec will not be probed.
- [Low] The patch references undefined device tree labels `audio_clkb` and `audio_clkc`, which will result in a fatal `dtc` compilation error.
--
commit e73e5f92dd2a1aa13133b29d66da034cb803fffc
Author: John Madieu <john.madieu.xa@bp.renesas.com>
arm64: dts: renesas: r9a09g047e57-smarc: add DA7212 audio codec support
This commit adds support for the DA7212 audio codec on the RZ/G3E SMARC2 EVK
board. It enables the audio graph card and configures the codec on the I2C1 bus.
> diff --git a/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts b/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
> index 6372f582a7c41..ac525b73c1bb1 100644
> --- a/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
> +++ b/arch/arm64/boot/dts/renesas/r9a09g047e57-smarc.dts
[ ... ]
> + sound_card: sound {
> + compatible = "audio-graph-card";
> +
> + label = "snd-rzg3e";
> +
> + dais = <&rsnd_port0>; /* DA7212 */
> + };
> +};
> +
> +&audio_clkb {
> + clock-frequency = <11289600>;
> +};
> +
> +&audio_clkc {
> + clock-frequency = <12288000>;
> };
[Severity: Low]
Are the audio_clkb and audio_clkc labels defined in the included dtsi files?
It looks like dtc might fail with a compilation error if they are not.
[ ... ]
> &i2c0 {
> pinctrl-names = "default";
> };
>
> +&i2c1 {
> + da7212: codec@1a {
> + compatible = "dlg,da7212";
[Severity: Medium]
Does this node need a status = "okay"; property?
If the I2C controller is disabled by default in the SoC base device tree, it
looks like it will remain disabled and the codec will not be probed.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260619083951.3777556-1-john.madieu.xa@bp.renesas.com?part=4
^ permalink raw reply
* [PATCH v2 0/3] phy: rockchip: inno-csidphy: fix 2500 Mbps support and add clock lane phase tuning
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
This series fixes and extends the Rockchip Innosilicon CSI D-PHY driver
to support data rates up to 2500 Mbps and adds optional board-specific
clock lane phase tuning for signal integrity.
Patch 1 fixes an off-by-one error in the rk1808 hsfreq range table:
the final entry was capped at 2499 Mbps, causing a rejection of the
maximum supported rate of 2500 Mbps.
Patches 2 and 3 add an optional rockchip,clk-lane-phase device tree
property that allows tuning the clock lane sampling phase in ~40 ps
steps to compensate for board-level signal integrity variations.
---
Changes in v2:
- dt-bindings: improve rockchip,clk-lane-phase description wording
(Conor Dooley)
- Link to v1: https://patch.msgid.link/20260617-feature-mipi-csi-dphy-4k60-v1-0-4611ff00b0ff@wolfvision.net
To: Vinod Koul <vkoul@kernel.org>
To: Neil Armstrong <neil.armstrong@linaro.org>
To: Heiko Stuebner <heiko@sntech.de>
To: Rob Herring <robh@kernel.org>
To: Krzysztof Kozlowski <krzk+dt@kernel.org>
To: Conor Dooley <conor+dt@kernel.org>
Cc: linux-phy@lists.infradead.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-rockchip@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
---
Gerald Loacker (3):
phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
dt-bindings: phy: rockchip-inno-csi-dphy: add rockchip,clk-lane-phase property
phy: rockchip: phy-rockchip-inno-csidphy: add clock lane phase tuning
.../bindings/phy/rockchip-inno-csi-dphy.yaml | 9 ++++++++
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 27 +++++++++++++++++++++-
2 files changed, 35 insertions(+), 1 deletion(-)
---
base-commit: 8cd9520d35a6c38db6567e97dd93b1f11f185dc6
change-id: 20260617-feature-mipi-csi-dphy-4k60-9879c3d1fe4f
Best regards,
--
Gerald Loacker <gerald.loacker@wolfvision.net>
^ permalink raw reply
* [PATCH v2 1/3] phy: rockchip: phy-rockchip-inno-csidphy: fix rk1808 hsfreq table
From: Gerald Loacker @ 2026-06-19 9:13 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel,
devicetree, Gerald Loacker
In-Reply-To: <20260619-feature-mipi-csi-dphy-4k60-v2-0-323356c2cc2e@wolfvision.net>
The rk1808 hsfreq table capped at 2499 Mbps, preventing a data rate of
exactly 2500 Mbps. Extend the final entry to 2500 Mbps to support this
rate.
This is essential for RK3588 reusing this array and fully supporting
rates up to 2500 Mbps.
Fixes: bd1f775d6027 ("phy/rockchip: add Innosilicon-based CSI dphy")
Signed-off-by: Gerald Loacker <gerald.loacker@wolfvision.net>
---
drivers/phy/rockchip/phy-rockchip-inno-csidphy.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
index c79fb53d8ee5c..5281f8dea0ad3 100644
--- a/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
+++ b/drivers/phy/rockchip/phy-rockchip-inno-csidphy.c
@@ -170,7 +170,7 @@ static const struct hsfreq_range rk1808_mipidphy_hsfreq_ranges[] = {
{ 299, 0x06}, { 399, 0x08}, { 499, 0x0b}, { 599, 0x0e},
{ 699, 0x10}, { 799, 0x12}, { 999, 0x16}, {1199, 0x1e},
{1399, 0x23}, {1599, 0x2d}, {1799, 0x32}, {1999, 0x37},
- {2199, 0x3c}, {2399, 0x41}, {2499, 0x46}
+ {2199, 0x3c}, {2399, 0x41}, {2500, 0x46}
};
static const struct hsfreq_range rk3326_mipidphy_hsfreq_ranges[] = {
--
2.34.1
^ 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