* Re: [PATCH RFC 4/9] net: stmmac: qcom-ethqos: add per-platform NOC clock voting
From: Mohd Ayaan Anwar @ 2026-06-16 16:17 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <45d7faac-7c0f-4f89-808e-06129e8420e4@oss.qualcomm.com>
Hi Konrad,
On Mon, Jun 15, 2026 at 02:13:05PM +0200, Konrad Dybcio wrote:
> On 6/11/26 8:37 PM, Mohd Ayaan Anwar wrote:
> > Some SoCs gate the EMAC's path to the System NOC behind dedicated clocks
> > that must be enabled before the DMA can reach memory. Add
> > ethqos_noc_clk_cfg and the corresponding fields in the driver-data and
> > runtime structs so each compatible can declare its own set with per-clock
> > rates. The clocks are acquired during probe and enabled/disabled
> > alongside the existing link clock in ethqos_clks_config().
>
> Sounds like we should use an OPP table instead, we can't just do
> set_rate() on qcom, as that will not propagate the required perf
> state to the clock controller's supplier power domain (i.e. VDDCX)
>
Understood, I will test this out for v2.
Ayaan
^ permalink raw reply
* Re: [PATCH v2] dt-bindings: display: Add Solomon SSD1351 OLED controller
From: Javier Martinez Canillas @ 2026-06-16 16:27 UTC (permalink / raw)
To: Conor Dooley, Amit Barzilai
Cc: robh, krzk+dt, conor+dt, devicetree, dri-devel, linux-kernel,
airlied, maarten.lankhorst, mripard, simona, tzimmermann
In-Reply-To: <20260616-nautical-obstinate-a92fd80ef483@spud>
Conor Dooley <conor@kernel.org> writes:
Hello Conor,
> On Mon, Jun 15, 2026 at 08:56:20PM +0300, Amit Barzilai wrote:
>> Add a device tree binding for the Solomon SSD1351, a 128x128 65k-color
>> RGB OLED display controller driven over a 4-wire SPI bus. The binding
>> builds on the shared solomon,ssd-common.yaml properties already used by
>> the other Solomon display controllers.
>>
>> Assisted-by: Claude:claude-opus-4-8
>> Signed-off-by: Amit Barzilai <amit.barzilai22@gmail.com>
>> ---
>> Changes since v1:
>> - Drop solomon,width / solomon,height: both are deducible from the
>> compatible and are already declared (as optional) by the referenced
>> solomon,ssd-common.yaml, so a local override is unnecessary.
>> - Drop the rotation property: it has no consumer (rotation is being removed from the driver).
>> - Use dt-bindings/gpio/gpio.h flag defines in the example
>> (reset-gpios active-low, dc-gpios active-high).
>
> The user for this appears to be in staging. As far as I understand, the
> policy is that we only add bindings for staging things when they move
> out of staging.
> Sure, this is straightforward but why should an exception be made here?
> Are you working on moving this out of staging?
>
This DT binding was part of a series to add support for "solomon,ssd1351"
to drivers/gpu/drm/solomon/ DRM driver. Amit only sent a v2 of the binding
schema because he had some questions about the driver:
https://lore.kernel.org/dri-devel/87cxxqzwxn.fsf@ocarina.mail-host-address-is-not-set/
But yes, I agree that it would had been better for him to post this as a
part of v2 (and I still expect him to do it), otherwise it is confusing.
Specially since as you pointed out, there is an existing fbdev driver for
the same device in staging.
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
^ permalink raw reply
* Re: [PATCH RFC 3/9] net: stmmac: qcom-ethqos: fix RGMII_ID mode to use DLL bypass
From: Mohd Ayaan Anwar @ 2026-06-16 16:32 UTC (permalink / raw)
To: Andrew Lunn
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <82705420-771d-41bf-a4d9-ed94dff86ff0@lunn.ch>
On Mon, Jun 15, 2026 at 06:48:55PM +0200, Andrew Lunn wrote:
> > > I'm curious how this works at the moment? Do no boards make use of
> > > RGMII ID? Are all current boards broken?
> >
> > Searching through the DTS, I found that we have two boards using "rgmii"
> > (qcs404-evb-4000.dts and sa8155-adp.dts) and another board using
> > "rgmii-txid" (sa8540p-ride.dts). No board which uses RGMII ID.
>
> So this causes problems. We cannot break existing boards, yet it would
> be good to fix the current broken behaviour.
I am trying to track down the sa8155-adp and sa8540p-ride boards. The
EMAC on QCS404 is extremely similar to QCS615 Ride [0], and I got that
board to work with this series (with RGMII ID mode). So I am fairly
confident that QCS404 would not break (if its even booting up with the
upstream kernel currently). Also, I think we could change the phy-mode
for QCS404 to "rgmii-id" from "rgmii" if these fixes go in.
> It could be the best way forward is that you issue a warning when
> "rgmii" is found and pass rgmii-id to the PHY. And you also change the
> two boards to use rgmii-id. Lets think about the rgmii-txid case once
> we better understand it.
>
As Konrad mentioned, it would be great to know if we can test out these
boards. Looking at the different versions of the ETHQOS programming
guide, stopping MAC side delay should be as simple as what we are doing
in this commit. But whether the two boards work directly with the
default PHY delays is unknown.
Ayaan
[0] The proposed RGMII fixes would help enable ethernet on QCS615 Ride
as well. I see that the original series had a lot of issues:
https://lore.kernel.org/all/20250121-dts_qcs615-v3-0-fa4496950d8a@quicinc.com/
^ permalink raw reply
* Re: [PATCH RFC 8/9] arm64: dts: qcom: shikra-cqs-evk: Enable ethernet0
From: Mohd Ayaan Anwar @ 2026-06-16 16:50 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Richard Cochran, Bjorn Andersson, Konrad Dybcio, Maxime Coquelin,
Alexandre Torgue, Russell King, linux-arm-msm, netdev, devicetree,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <2cb658f3-f564-4396-884d-d025eaa674a1@oss.qualcomm.com>
On Tue, Jun 16, 2026 at 11:50:26AM +0200, Konrad Dybcio wrote:
> On 6/11/26 8:37 PM, Mohd Ayaan Anwar wrote:
>
> > +&tlmm {
> > + ethernet0_defaults: ethernet0-defaults-state {
>
> s/defaults/default
>
> Please move this definition to shikra.dtsi
>
The CQM and CQS variants have identical GPIO mapping but the IQS is
different. So should I keep this in shikra.dtsi and overwrite for IQS in
shikra-iqs-evk.dts?
> > +
> > + emac0_phy_en_hog: emac0-phy-en-hog {
> > + gpio-hog;
> > + gpios = <149 GPIO_ACTIVE_HIGH>;
> > + output-high;
> > + line-name = "emac0-phy-en";
> > + };
>
> This looks like a hack - what does this pin actually do?
>
The power supply to both PHYs on Shikra is gated by a GPIO pin. I am
unsure whether they should be modelled as a fixed, enable-on-boot
regulator or just like this. They need to be powered on early so that
MDIO can detect them.
Thank you for the review. I will fix the stylistic issues in v2.
Ayaan
^ permalink raw reply
* Re: [PATCH 0/4] iio: adc: new ti-ads112c14 driver
From: Kurt Borja @ 2026-06-16 17:26 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <d3270250-ae18-4c0f-a0fe-e0fdabfce046@baylibre.com>
On Tue Jun 16, 2026 at 10:21 AM -05, David Lechner wrote:
> On 6/15/26 7:18 PM, Kurt Borja wrote:
>> Hi David,
>>
>> On Mon Jun 15, 2026 at 4:59 PM -05, David Lechner (TI) wrote:
>>> This adds support for TI ADS112C14 and ADS122C14 ADC chips.
>>>
>>> The closest thing we've seen to this in the kernel already is ads124s08.
>>> However, that has a completely different register map and the DT
>>> bindings are incomplete and the driver is extremely basic. So I've just
>>> started from scratch here.
>>>
>>> We've also had a similar submission recently for ADS1220 [1]. That chip
>>> is in a similar situation to ads124s08 in that it has a different
>>> register map (but the submitted DT bindings are better than the ones for
>>> ads124s08, even if still a bit incomplete). And literally as I was
>>> writing the previous sentence, another series [2] was sent for yet
>>> another similar family of chips (ADS1262). That one is even more complex
>>> in the feature set than the ones I am working on. I was going to polish
>>> up the driver a bit more before submitting it, but now it seems more
>>> urgent to coordinate with the other two series to align on how we would
>>> like to handle all of these.
>>>
>>> [1]: https://lore.kernel.org/linux-iio/20260610151342.44274-1-zizuzacker@gmail.com/
>>> [2]: https://lore.kernel.org/linux-iio/20260612-ads126x-v1-0-894c788d03ed@gmail.com/
>>>
>>> All of these chips have in common that they are designed for use with
>>> RTDs and thermocouples and so they look very similar to each other in
>>> terms of wiring and feature set, even if the register maps are
>>> different. They are in the gray area where we could either keep them
>>> separate because they are just different enough, or we could do like
>>> we've done before with ad_sigma_delta and have a bit of an abstraction
>>> layer for the register differences and otherwise try to share as much
>>> code as possible. Normally, I would lean towards keeping them separate,
>>> but in this case, I'm considering trying to share code because the
>>> devicetree bindings for the inputs is complex and is going to be mostly
>>> the same across all of these chips.
>>
>> The channel configuration is indeed very similar for the three chips.
>> All three have IDAC, BOC and VREF configurations.
>
> Hmm... I forgot to include the burnout current in the DT bindings. Following
> the channel = "conditions for measurement" pattern that I have set out here
> I guess that would mean that we would need to have the same inputs twice
> when using the burnout. One "channel" would be the one used to do a "precision"
> measurement and the other would be the one to do open/short circuit detection.
>
>
> i2c {
> #address-cells = <1>;
> #size-cells = <0>;
>
> adc@40 {
> compatible = "ti,ads112c14";
> reg = <0x40>;
>
> avdd-supply = <&avdd>;
> dvdd-supply = <&dvdd>;
>
> refp-supply = <&avdd>;
>
> #address-cells = <1>;
> #size-cells = <0>;
>
> channel@0 {
> reg = <0>;
> diff-channels = <1>, <2>;
> excitation-channels = <0>, <3>;
> excitation-current-microamp = <500>;
> current-chopping;
> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> label = "rtd-precision";
> };
>
> channel@1 {
> reg = <0>;
> diff-channels = <1>, <2>;
> excitation-channels = <0>, <3>;
> excitation-current-microamp = <500>;
> burnout-current-nanoamp = <1000>;
> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
> label = "rtd-diagnostic";
> };
This would mean we wouldn't be able to use iio_chan_spec .channel and
.channel2 to describe inputs because of duplicate sysfs attributes, no?
> };
> };
>
>>
>>>
>>> If we decide to go the route of sharing code, we could still merge this
>>> series as-is and then do the refactoring to add the abstraction layer in
>>> a follow-up series that also adds support for the first of the other
>>> chips.
>>
>> Do you have a proposal of how such an abstraction would look like? I do
>> like the idea of abstracting the firmware parsing, scales and shared
>> calculations.
>
> As mentioned, it would look a bit like the ad_sigma_delta ADC driver.
> Basically, each chip (family with same registers) would still have it's
> own driver that include the chip-specific const info structs. In this
> case, these would also include function pointers for all of the functions
> that need to access registers. And there will be lots of supports_... bool
> flags for the shared code to use.
>
>>
>>>
>>> This series includes just basic support for reading single measurements
>>> from the ADC and gain selection via the scale attribute. I plan to
>>> follow this up with additional series to add support for buffered reads,
>>> filtering/oversampling configuration, event support, gpio controller
>>> support and perhaps a few other things that are slipping my mind right
>>> now.
>>>
>>> The most interesting part about this (that I alluded to above) is the
>>> way channels are handled. These are multipling ADCs with differential
>>> and single-ended inputs. But what sets them apart from other similar
>>> chips is that since they are designed for use with RTDs, there can also
>>> be a current output required to excite the RTD and this current output
>>> might be different for different channels. So the way I conceptualized
>>> the channels is that the devicetree specifies the conditions needed
>>> to take a particular measurement rather than being purely a physical
>>> channel.
>>>
>>> This makes things more flexible, but does make the driver a bit more
>>> complex. For example, knowing when the current output needs to be
>>> enabled or disabled. For now, I have chosen a lazy-enable where they
>>> are not turned on until the first measurement is taken that requires
>>> them, but then they stay on until another measurement is taken that
>>> doesn't require them. This can lead to some oddness with the diagnostic
>>> channels that may be measuring something that indirectly requires the
>>> current output (i.e. the external reference voltage when it is connected
>>> to a resistor rather than a power supply). This means you need to take
>>> a measurement that requires the current output to be enabled before the
>>> diagnostic channels will give accurate readings.
>>
>> This is the same approach I took around the BOC, it feels kinda hacky
>> but it makes sense. Just an idea I thought about just now: What if we
>> have an additional write-only "_enable" sysfs attribute for these
>> channels?
>
> I would not want to make a write-only attribute, we always want to be
> able to read back what the current state is.
Yeah, I don't know why I said WO. Reading would be fine too.
>
> Do you mean an _enable for just the BOC? I think I would do it like I
> suggested above instead.
No, no just the BOC. The BOC, IDAC and rest of side effects. Thinking
about it some more, it would be a bit redundant but clearer if proper
documentation is provided.
>
>>
>> The approach I took for the IDAC was to have a single configuration that
>> it's enabled for all channels. This makes some sense in my device when
>> thinking about optimal software sequencial reads, because of the
>> register layout, but I also see the value in having per-channel IDAC
>> configuration. I think I will take your approach, so we have the same
>> channel configuration around this.
>
> There are only two IDACs but on chips with 8 AIN pins we could have two
> RTDs wired up and if both require 2 IDACs, then we can't have a fixed
> setting for the IDACs. This is why I made it per-channel.
I'll make it per-channel too.
>
>>
>> Have you thought about how to implement the BOC? In the ADS1262 the
>> feature can be found "Sensor Bias". What I did was add per channel DT
>> properties for this too.
>
> See above.
>
>>
>> Another question. When you implement power management in the future,
>> will you enable autosuspend? IDAC currents will be lost if autosuspend
>> is enabled. Is this acceptable? In my case I did enable autosuspend, but
>> I have some doubts about this.
>
> I don't like to implement power management unless I have an application
> that actually requires it. Otherwise, I consider it premature optimization.
> It is difficult to know if we would be implementing it in a way that is
> actually useful for a real-world use case. These chips seem like they
> would mostly be used in an industrial setting, not in battery powered
> applications, so I'm not sure anyone is going to worry about saving a few
> milliamps.
Makes sense. I can probably drop the autosuspend in that case.
>
>>
>>>
>>> I have also pushed a branch to [3] that contains the start of some
>>> documentation for this driver that can give some more insight into how
>>> the implementation works. It still needs some work and also documents
>>> some things that haven't been implemented yet, so I haven't included it
>>> in this series yet.
>>>
>>> [3]: https://github.com/dlech/linux/blob/b4/iio-adc-ti-ads122c14/Documentation/iio/ads112c14.rst
>>>
>>> Signed-off-by: David Lechner <dlechner@baylibre.com>
>>> ---
>>> David Lechner (TI) (4):
>>> dt-bindings: iio: adc: add ti,ads122c14
>>> iio: adc: add ti-ads112c14 driver
>>> iio: adc: ti-ads112c14: implement gain on internal short SYS_MON channel
>>> iio: adc: ti-ads112c14: add measurement channel support
>>>
>>> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++
>>> MAINTAINERS | 8 +
>>> drivers/iio/adc/Kconfig | 12 +
>>> drivers/iio/adc/Makefile | 1 +
>>> drivers/iio/adc/ti-ads112c14.c | 1053 ++++++++++++++++++++
>>> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
>>> 6 files changed, 1309 insertions(+)
>>> ---
>>> base-commit: ec039126b7fac4e3af35ebccaa7c6f9b6875ba81
>>> change-id: 20260514-iio-adc-ti-ads122c14-d0b92479334e
>>>
>>> Best regards,
>>> --
>>> David Lechner (TI) <dlechner@baylibre.com>
>>
--
Thanks,
~ Kurt
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: serial: maxim,max310x: describe per-channel rs485 subnodes
From: Rob Herring (Arm) @ 2026-06-16 17:28 UTC (permalink / raw)
To: Tapio Reijonen
Cc: linux-serial, Conor Dooley, Hugo Villeneuve, Jiri Slaby,
linux-kernel, Greg Kroah-Hartman, devicetree, Krzysztof Kozlowski
In-Reply-To: <20260615-b4-max310x-rs485-dt-v3-2-7e79f064bdd7@vaisala.com>
On Mon, 15 Jun 2026 10:27:36 +0000, Tapio Reijonen wrote:
> The MAX310x is a family of one- (max3107, max3108), two- (max3109) and
> four-channel (max14830) UARTs. The binding pulls in
> /schemas/serial/rs485.yaml at the chip level, describing a single set of
> RS-485 properties - enough for the single-channel parts, but a
> multi-channel chip can wire RS-485 differently on each channel.
>
> Split the binding per compatible:
>
> - single-channel parts (max3107, max3108): the chip node is itself the
> serial port and carries the RS-485 properties, as before;
>
> - multi-channel parts (max3109, max14830): the chip node is only a
> container and is no longer a serial node; each channel is a "serial@N"
> subnode that carries the standard serial.yaml/rs485.yaml properties
> (and may host a serial slave device). max3109 has channels 0-1,
> max14830 has 0-3.
>
> This avoids a chip node that is simultaneously a serial node and the
> parent of serial nodes. The driver still reads chip-level RS-485 for
> single-channel and legacy device trees, so existing users are unaffected.
>
> Signed-off-by: Tapio Reijonen <tapio.reijonen@vaisala.com>
> ---
> .../devicetree/bindings/serial/maxim,max310x.yaml | 92 +++++++++++++++++++++-
> 1 file changed, 90 insertions(+), 2 deletions(-)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: Kurt Borja @ 2026-06-16 17:31 UTC (permalink / raw)
To: David Lechner, Kurt Borja, Jonathan Cameron, Nuno Sá,
Andy Shevchenko, Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <88f29dc3-7929-4d94-a1bc-6268c41ee3dd@baylibre.com>
On Tue Jun 16, 2026 at 10:22 AM -05, David Lechner wrote:
> On 6/15/26 7:26 PM, Kurt Borja wrote:
>> On Mon Jun 15, 2026 at 4:59 PM -05, David Lechner (TI) wrote:
>>> Add new bindings for ti,ads122c14 and similar devices.
>>>
>>> This is an ADC that is primarily intended for use with temperature
>>> sensors. There are a few unusual properties because of this. In
>>> particular, the reference voltage source and current output requirements
>>> can be different for each measurement, so these are included in the
>>> channel bindings.
>>>
>>> The REFP/REFN reference voltage is usually just connected to a resistor
>>> that is being driven by the ADC's current outputs, so there is special
>>> property for this case rather than requiring a regulator to be defined
>>> to represent that.
>>>
>>> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
>>> have preferred an enum of strings).
>>>
>>> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
>>> ---
>>> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
>>> MAINTAINERS | 7 +
>>> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
>>> 3 files changed, 242 insertions(+)
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>>> new file mode 100644
>>> index 000000000000..dc7f37cad772
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>>> @@ -0,0 +1,224 @@
>>
>> [...]
>>
>>> +patternProperties:
>>> + ^channel@[0-7]$:
>>> + $ref: adc.yaml
>>> +
>>> + unevaluatedProperties: false
>>> +
>>> + properties:
>>> + reg:
>>> + maximum: 16 # arbitrary limit, channel@ can be any combination of AIN0-AIN7
>>> +
>>> + single-channel:
>>> + maximum: 7
>>> +
>>> + diff-channels:
>>> + items:
>>> + maximum: 7
>>> +
>>> + bipolar:
>>> + description:
>>> + Set this flag if the differential input can be negative.
>>> +
>>> + excitation-channels:
>>
>> I noticed this doesn't have the "ti," prefix. Is your plan to add this
>> to adc.yaml?
>
> I hadn't really though about it. I guess it could make sense.
I think it would be valuable, given that TI is producing quite a few of
this kind of devices.
>
>>
>> Also, do you think excitation-pins might be a better name?
>
> I used -channels to match e.g. diff-channels. The same values apply to
> both properties.
>
>>
>>> + description: AINx pins used as current output.
>>> + $ref: /schemas/types.yaml#/definitions/uint32-array
>>> + minItems: 1
>>> + maxItems: 2
>>> + items:
>>> + maximum: 7
>>> +
>>> + excitation-current-microamp:
>>> + description: The current output of the excitation channels in microamps.
>>> + minimum: 1
>>> + maximum: 1000
>>> +
>>> + current-chopping:
>>
>> If you agree with the above comment, I think this too should be added.
>> In that case, can we call this something like
>> excitation-current-rotation for less ambiguity?
>
> I think excitation-channel-rotation would be fine.
I like it.
>
>>
>> I say this because my device has an "IDAC rotation mode", but it also has
>> a "Chop Mode" which rotates analog inputs and averages consecutive
>> conversions.
>
> And this one sounds like it could be named input-channel-rotation. Would
> this also need a 2nd set of single-channel or diff-channels to the extra
> inputs?
No, just one set. It rotates the positive and negative inputs.
I'll go with input-channel-rotation then!
>
>>
>>> + $ref: /schemas/types.yaml#/definitions/flag
>>> + description:
>>> + If provided, the two excitation channels are to be used with current
>>> + chopping enabled.
>>> +
>>> + ti,vref-source:
>>> + description: |
>>> + Indicates the source for the reference voltage for this channel.
>>> + 0 - Internal 2.5V reference
>>> + 1 - Internal 1.25V reference
>>> + 2 - External reference (REFP-REFN)
>>> + 3 - AVDD as reference
>>> +
>>> + For convenience, macros for these values are available in
>>> + dt-bindings/iio/adc/ti,ads112c14.h.
>>> + $ref: /schemas/types.yaml#/definitions/uint32
>>> + maximum: 3
>>> + default: 0
>>> +
>>> + dependencies:
>>> + excitation-channels: [ excitation-current-microamp ]
>>> + excitation-current-microamp: [ excitation-channels ]
>>> + current-chopping: [ excitation-channels ]
>>> +
>>> + oneOf:
>>> + - required: [ single-channel ]
>>> + - required: [ diff-channels ]
>>
>> [...]
>>
--
Thanks,
~ Kurt
^ permalink raw reply
* [PATCH v2 0/2] arm64: dts: renesas: Describe GPU on D3
From: Niklas Söderlund @ 2026-06-16 17:58 UTC (permalink / raw)
To: Marek Vasut, Geert Uytterhoeven, Conor Dooley, David Airlie,
Frank Binns, Krzysztof Kozlowski, Maarten Lankhorst, Magnus Damm,
Matt Coster, Maxime Ripard, Rob Herring, Simona Vetter,
Thomas Zimmermann, devicetree, dri-devel, linux-renesas-soc
Cc: Niklas Söderlund
Hello,
This series adds the needed bindings to operate the PowerVR GPU on R-Car
D3 SoC.
Together with the D3 clock changes [1] and a still OOT patch for the PVR
driver [2], I'm able to load firmware.
powervr fd000000.gpu: [drm] loaded firmware powervr/rogue_22.67.54.30_v1.fw
powervr fd000000.gpu: [drm] FW version v1.0 (build 6889268 OS)
powervr fd000000.gpu: [drm] Unsupported quirks in firmware image
powervr fd000000.gpu: [drm] Unsupported enhancements in firmware image
powervr fd000000.gpu: [drm] Unsupported features in firmware image
[drm] Initialized powervr 1.0.0 for fd000000.gpu on minor 1
I can run vulkaninfo from mesa (need to add the driver to
pvr_drm_configs):
$ PVR_I_WANT_A_BROKEN_VULKAN_DRIVER=1 meson devenv -C builddir vulkaninfo --summary
WARNING: powervr is not a conformant Vulkan implementation, testing use only.
MESA: warning: Warning: The available RAM is below the minimum required by the Vulkan specification!
MESA: warning: ../src/imagination/vulkan/pvr_border.c:117: FINISHME: Devices without tpu_border_colour_enhanced require entries for compressed formats to be stored in the table pre-compressed.
==========
VULKANINFO
==========
Vulkan Instance Version: 1.4.335
Instance Extensions: count = 20
-------------------------------
VK_EXT_debug_report : extension revision 10
VK_EXT_debug_utils : extension revision 2
VK_EXT_headless_surface : extension revision 1
VK_EXT_surface_maintenance1 : extension revision 1
VK_EXT_swapchain_colorspace : extension revision 5
VK_KHR_device_group_creation : extension revision 1
VK_KHR_display : extension revision 23
VK_KHR_external_fence_capabilities : extension revision 1
VK_KHR_external_memory_capabilities : extension revision 1
VK_KHR_external_semaphore_capabilities : extension revision 1
VK_KHR_get_display_properties2 : extension revision 1
VK_KHR_get_physical_device_properties2 : extension revision 2
VK_KHR_get_surface_capabilities2 : extension revision 1
VK_KHR_portability_enumeration : extension revision 1
VK_KHR_surface : extension revision 25
VK_KHR_surface_protected_capabilities : extension revision 1
VK_KHR_wayland_surface : extension revision 6
VK_KHR_xcb_surface : extension revision 6
VK_KHR_xlib_surface : extension revision 6
VK_LUNARG_direct_driver_loading : extension revision 1
Instance Layers:
----------------
Devices:
========
GPU0:
apiVersion = 1.2.330
driverVersion = 25.99.99
vendorID = 0x1010
deviceID = 0x22054030
deviceType = PHYSICAL_DEVICE_TYPE_INTEGRATED_GPU
deviceName = PowerVR Rogue GE8300
driverID = DRIVER_ID_IMAGINATION_OPEN_SOURCE_MESA
driverName = Imagination open-source Mesa driver
driverInfo = Mesa 26.0.0-devel (git-8fb0621f2d)
conformanceVersion = 1.3.8.4
deviceUUID = 19031a08-e22f-9565-d78b-ddda8240380a
driverUUID = 48685174-7bd0-6840-5716-9d00003566aa
GPU1:
apiVersion = 1.4.330
driverVersion = 25.99.99
vendorID = 0x10005
deviceID = 0x0000
deviceType = PHYSICAL_DEVICE_TYPE_CPU
deviceName = llvmpipe (LLVM 21.1.4, 128 bits)
driverID = DRIVER_ID_MESA_LLVMPIPE
driverName = llvmpipe
driverInfo = Mesa 26.0.0-devel (git-8fb0621f2d) (LLVM 21.1.4)
conformanceVersion = 1.3.1.1
deviceUUID = 6d657361-3236-2e30-2e30-2d6465766500
driverUUID = 6c6c766d-7069-7065-5555-494400000000
I can't run test Vulkan applications such as gears as the PVR driver do
not support all features need for GE8300, for example
simple_internal_parameter_format_v1, see [3].
1. https://lore.kernel.org/linux-renesas-soc/20260616175247.2104891-1-niklas.soderlund+renesas@ragnatech.se
2. https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/38211#note_3177232
3. https://gitlab.freedesktop.org/imagination/mesa/-/issues/13
Niklas Söderlund (2):
dt-bindings: gpu: img,powervr-rogue: Document GE8300 GPU in Renesas
R-Car D3
arm64: dts: renesas: r8a77995: Add GE8300 GPU node
.../bindings/gpu/img,powervr-rogue.yaml | 14 ++++++++++----
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 15 +++++++++++++++
2 files changed, 25 insertions(+), 4 deletions(-)
--
2.54.0
^ permalink raw reply
* [PATCH v2 1/2] dt-bindings: gpu: img,powervr-rogue: Document GE8300 GPU in Renesas R-Car D3
From: Niklas Söderlund @ 2026-06-16 17:58 UTC (permalink / raw)
To: Marek Vasut, Geert Uytterhoeven, Conor Dooley, David Airlie,
Frank Binns, Krzysztof Kozlowski, Maarten Lankhorst, Magnus Damm,
Matt Coster, Maxime Ripard, Rob Herring, Simona Vetter,
Thomas Zimmermann, devicetree, dri-devel, linux-renesas-soc
Cc: Niklas Söderlund
In-Reply-To: <20260616175835.2109336-1-niklas.soderlund+renesas@ragnatech.se>
Document Imagination Technologies PowerVR Rogue GE8300 BNVC 22.67.54.30
present in Renesas R-Car R8A77995 D3 SoCs.
Compared to other R-Car Gen3 SoCs the D3 only have one power domain and
it is always on. Extend the list of special cases for this to also cover
R8A77995 and update the description of it.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
---
* Changes since v1
- Sort img,img-ge8300 after img,img-ge7800.
- Fold special case for power domain into an existing one and update the
description.
---
.../devicetree/bindings/gpu/img,powervr-rogue.yaml | 14 ++++++++++----
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
index a1f54dbae3f3..b93f49f1fa0a 100644
--- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
+++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
@@ -25,6 +25,11 @@ properties:
- renesas,r8a779a0-gpu
- const: img,img-ge7800
- const: img,img-rogue
+ - items:
+ - enum:
+ - renesas,r8a77995-gpu
+ - const: img,img-ge8300
+ - const: img,img-rogue
- items:
- enum:
- ti,am62-gpu
@@ -114,6 +119,7 @@ allOf:
contains:
enum:
- img,img-ge7800
+ - img,img-ge8300
- img,img-gx6250
- thead,th1520-gpu
then:
@@ -159,14 +165,14 @@ allOf:
- if:
properties:
compatible:
- contains:
- const: thead,th1520-gpu
+ enum:
+ - renesas,r8a77995-gpu
+ - thead,th1520-gpu
then:
properties:
power-domains:
items:
- - description: The single, unified power domain for the GPU on the
- TH1520 SoC, integrating all internal IP power domains.
+ - description: The single, unified power domain for the GPU.
power-domain-names: false
required:
- power-domains
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/2] arm64: dts: renesas: r8a77995: Add GE8300 GPU node
From: Niklas Söderlund @ 2026-06-16 17:58 UTC (permalink / raw)
To: Marek Vasut, Geert Uytterhoeven, Conor Dooley, David Airlie,
Frank Binns, Krzysztof Kozlowski, Maarten Lankhorst, Magnus Damm,
Matt Coster, Maxime Ripard, Rob Herring, Simona Vetter,
Thomas Zimmermann, devicetree, dri-devel, linux-renesas-soc
Cc: Niklas Söderlund
In-Reply-To: <20260616175835.2109336-1-niklas.soderlund+renesas@ragnatech.se>
Describe Imagination Technologies PowerVR Rogue GE8300 BNVC 22.67.54.30
present in Renesas R-Car R8A77995 D3 SoC.
Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
---
* Changes since v1
- Use SPI 119 instead of SPI 223.
---
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
index 5f3fcef7560c..c42d96540ce7 100644
--- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
@@ -1295,6 +1295,21 @@ gic: interrupt-controller@f1010000 {
resets = <&cpg 408>;
};
+ gpu: gpu@fd000000 {
+ compatible = "renesas,r8a77995-gpu",
+ "img,img-ge8300",
+ "img,img-rogue";
+ reg = <0 0xfd000000 0 0x40000>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&cpg CPG_CORE R8A77995_CLK_ZG>,
+ <&cpg CPG_CORE R8A77995_CLK_S3D1>,
+ <&cpg CPG_MOD 112>;
+ clock-names = "core", "mem", "sys";
+ power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
+ resets = <&cpg 112>;
+ status = "disabled";
+ };
+
vspbs: vsp@fe960000 {
compatible = "renesas,vsp2";
reg = <0 0xfe960000 0 0x8000>;
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 3/9] firmware: imx: ele: Add API functions for OCOTP fuse access
From: Frieder Schrempf @ 2026-06-16 17:59 UTC (permalink / raw)
To: Frank Li, Frieder Schrempf, Pankaj Gupta
Cc: Srinivas Kandagatla, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Frank Li, Sascha Hauer, Pengutronix Kernel Team,
Fabio Estevam, Shawn Guo, devicetree, imx, linux-arm-kernel,
linux-kernel
In-Reply-To: <ajFtkysqxuLV8GgF@SMW015318>
On 16.06.26 17:36, Frank Li wrote:
> On Tue, Jun 16, 2026 at 01:52:18PM +0200, Frieder Schrempf wrote:
>> From: Frieder Schrempf <frieder.schrempf@kontron.de>
>>
>> The ELE S400 API provides read and write access to the OCOTP fuse
>> registers. This adds the necessary API functions imx_se_read_fuse()
>> and imx_se_write_fuse() to be used by other drivers such as the
>> OCOTP S400 NVMEM driver.
>>
>> This is ported from the downstream vendor kernel.
>>
>> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
>> ---
>> drivers/firmware/imx/ele_base_msg.c | 122 ++++++++++++++++++++++++++++++++++++
>> drivers/firmware/imx/ele_base_msg.h | 6 ++
>> include/linux/firmware/imx/se_api.h | 3 +
>> 3 files changed, 131 insertions(+)
>>
> ...
>> +++ b/include/linux/firmware/imx/se_api.h
>> @@ -11,4 +11,7 @@
>> #define SOC_ID_OF_IMX8ULP 0x084d
>> #define SOC_ID_OF_IMX93 0x9300
>>
>> +int imx_se_read_fuse(void *se_if_data, uint16_t fuse_id, u32 *value);
>> +int imx_se_write_fuse(void *se_if_data, uint16_t fuse_id, u32 value);
>> +
>
> This API should implement in fuse drivers. Other consume should use standard
> fuse API to get value. If put here, it may bypass fuse driver.
The reason this is here, is the downstream implementation in linux-imx
and the current code organization. I thought there is some good reason
to have shared functions and it looks like Pankaj structured it like
this so all API functions live in ele_base_msg.c and the internal
structs and defines in ele_base_msg.h and se_ctrl.h are not exposed to
other drivers.
If I would move this into imx-ocotp-ele.c, then I would also need to
change how the code is organized and make the internal se_api functions
exposed to other drivers. I don't know if that is really a good idea.
I get your point but it looks like this contradicts the intention of
having a clean API in the firmware driver.
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: gpu: img,powervr-rogue: Document GE8300 GPU in Renesas R-Car D3
From: sashiko-bot @ 2026-06-16 18:05 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: devicetree, robh, dri-devel, conor+dt, wsa+renesas
In-Reply-To: <20260616175835.2109336-2-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Incorrect use of `enum:` instead of `contains: enum:` in an `if` block breaks schema matching for `compatible` arrays, bypassing power domain validation.
--
commit 911441282d51eed161459bbab16231d9b1fcbca8
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
dt-bindings: gpu: img, powervr-rogue: Document GE8300 GPU in Renesas R-Car D3
This commit documents the GE8300 GPU present in the Renesas R-Car R8A77995 D3
SoCs. It also updates the power domain constraints to account for the D3
having only one power domain that is always on.
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> index a1f54dbae3f31..b93f49f1fa0a6 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
[ ... ]
> @@ -159,14 +165,14 @@ allOf:
> - if:
> properties:
> compatible:
> - contains:
> - const: thead,th1520-gpu
> + enum:
> + - renesas,r8a77995-gpu
> + - thead,th1520-gpu
[Severity: Medium]
Does this change break the schema matching for these compatible strings?
In Device Tree bindings, the compatible property evaluates as an array of
strings. Using "enum:" directly on the compatible array checks if the entire
array itself equals one of the scalar string values, which will always
evaluate to false.
Should this use "contains:" along with "enum:"? By dropping the "contains:"
keyword during the transition from a single const to an enum, this condition
might silently fail to match both the newly added renesas,r8a77995-gpu and
the preexisting thead,th1520-gpu strings. This would bypass the power domain
validation constraints intended by the block.
> then:
> properties:
> power-domains:
> items:
> - - description: The single, unified power domain for the GPU on the
> - TH1520 SoC, integrating all internal IP power domains.
> + - description: The single, unified power domain for the GPU.
> power-domain-names: false
> required:
> - power-domains
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616175835.2109336-1-niklas.soderlund+renesas@ragnatech.se?part=1
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64: dts: renesas: r8a77995: Add GE8300 GPU node
From: sashiko-bot @ 2026-06-16 18:11 UTC (permalink / raw)
To: Niklas Söderlund; +Cc: conor+dt, dri-devel, devicetree, wsa+renesas, robh
In-Reply-To: <20260616175835.2109336-3-niklas.soderlund+renesas@ragnatech.se>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added GPU node references core clock R8A77995_CLK_ZG and module clock 112, but neither is implemented in the R8A77995 CPG MSSR clock controller driver.
--
commit cb323f9d0762b84aa5d75f999bf135e4920caed4
Author: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
arm64: dts: renesas: r8a77995: Add GE8300 GPU node
This commit describes the Imagination Technologies PowerVR Rogue GE8300 GPU
node for the Renesas R-Car R8A77995 D3 SoC.
> diff --git a/arch/arm64/boot/dts/renesas/r8a77995.dtsi b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> index 5f3fcef7560cb..c42d96540ce73 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77995.dtsi
> @@ -1295,6 +1295,21 @@ gic: interrupt-controller@f1010000 {
> resets = <&cpg 408>;
> };
>
> + gpu: gpu@fd000000 {
> + compatible = "renesas,r8a77995-gpu",
> + "img,img-ge8300",
> + "img,img-rogue";
> + reg = <0 0xfd000000 0 0x40000>;
> + interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&cpg CPG_CORE R8A77995_CLK_ZG>,
> + <&cpg CPG_CORE R8A77995_CLK_S3D1>,
> + <&cpg CPG_MOD 112>;
[Severity: Medium]
Will this result in a probe failure when the node is enabled by a board?
The newly added GPU node requests the core clock R8A77995_CLK_ZG and module
clock 112, but neither appears to be defined in the R8A77995 CPG MSSR clock
controller driver (drivers/clk/renesas/r8a77995-cpg-mssr.c).
If R8A77995_CLK_ZG is missing from r8a77995_core_clks and index 112 is
missing from r8a77995_mod_clks, the clock requests will return -ENOENT and
prevent the GPU driver from probing successfully.
> + clock-names = "core", "mem", "sys";
> + power-domains = <&sysc R8A77995_PD_ALWAYS_ON>;
> + resets = <&cpg 112>;
> + status = "disabled";
> + };
> +
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260616175835.2109336-1-niklas.soderlund+renesas@ragnatech.se?part=2
^ permalink raw reply
* Re: [PATCH 1/3] of/fdt: fix misleading elfcorehdr reservation success message
From: Sang-Heon Jeon @ 2026-06-16 18:13 UTC (permalink / raw)
To: Rob Herring
Cc: Saravana Kannan, Huacai Chen, WANG Xuerui, Thomas Bogendoerfer,
devicetree, loongarch, linux-mips
In-Reply-To: <20260616131945.GA2236977-robh@kernel.org>
On Tue, Jun 16, 2026 at 10:19 PM Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Jun 15, 2026 at 01:15:01AM +0900, Sang-Heon Jeon wrote:
> > fdt_reserve_elfcorehdr() does not check the return value of
> > memblock_reserve(), so a success message is falsely printed when the
> > reservation fails.
> >
> > Check the return value and warn on failure instead.
> >
> > Signed-off-by: Sang-Heon Jeon <ekffu200098@gmail.com>
> > ---
> > drivers/of/fdt.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> > index 26f66046cc32..d985c07d7c5c 100644
> > --- a/drivers/of/fdt.c
> > +++ b/drivers/of/fdt.c
> > @@ -479,7 +479,10 @@ static void __init fdt_reserve_elfcorehdr(void)
> > return;
> > }
> >
> > - memblock_reserve(elfcorehdr_addr, elfcorehdr_size);
> > + if (memblock_reserve(elfcorehdr_addr, elfcorehdr_size)) {
> > + pr_warn("Failed to reserve memory for elfcorehdr\n");
>
> I would think memblock_reserve() should always succeed and if not it
> should print a message rather than having every caller print a message.
Thanks for reviewing, Rob.
You're right. After taking a closer look, memblock_reserve() either
succeeds or panics before memblock_allow_resize() called.
So the check that I added in this patchset is totally unreachable.
Please drop this patchset. I'll be more careful when sending patches next time.
> Rob
Best Regards,
Sang-Heon Jeon
^ permalink raw reply
* Re: [PATCH 0/4] iio: adc: new ti-ads112c14 driver
From: David Lechner @ 2026-06-16 18:16 UTC (permalink / raw)
To: Kurt Borja, Jonathan Cameron, Nuno Sá, Andy Shevchenko,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <DJANEYYA4QTA.1JBN2L78PNXDD@gmail.com>
On 6/16/26 12:26 PM, Kurt Borja wrote:
> On Tue Jun 16, 2026 at 10:21 AM -05, David Lechner wrote:
>> On 6/15/26 7:18 PM, Kurt Borja wrote:
>>> On Mon Jun 15, 2026 at 4:59 PM -05, David Lechner (TI) wrote:
...
>>>> All of these chips have in common that they are designed for use with
>>>> RTDs and thermocouples and so they look very similar to each other in
>>>> terms of wiring and feature set, even if the register maps are
>>>> different. They are in the gray area where we could either keep them
>>>> separate because they are just different enough, or we could do like
>>>> we've done before with ad_sigma_delta and have a bit of an abstraction
>>>> layer for the register differences and otherwise try to share as much
>>>> code as possible. Normally, I would lean towards keeping them separate,
>>>> but in this case, I'm considering trying to share code because the
>>>> devicetree bindings for the inputs is complex and is going to be mostly
>>>> the same across all of these chips.
>>>
>>> The channel configuration is indeed very similar for the three chips.
>>> All three have IDAC, BOC and VREF configurations.
>>
>> Hmm... I forgot to include the burnout current in the DT bindings. Following
>> the channel = "conditions for measurement" pattern that I have set out here
>> I guess that would mean that we would need to have the same inputs twice
>> when using the burnout. One "channel" would be the one used to do a "precision"
>> measurement and the other would be the one to do open/short circuit detection.
>>
>>
>> i2c {
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> adc@40 {
>> compatible = "ti,ads112c14";
>> reg = <0x40>;
>>
>> avdd-supply = <&avdd>;
>> dvdd-supply = <&dvdd>;
>>
>> refp-supply = <&avdd>;
>>
>> #address-cells = <1>;
>> #size-cells = <0>;
>>
>> channel@0 {
>> reg = <0>;
>> diff-channels = <1>, <2>;
>> excitation-channels = <0>, <3>;
>> excitation-current-microamp = <500>;
>> current-chopping;
>> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
>> label = "rtd-precision";
>> };
>>
>> channel@1 {
>> reg = <0>;
>> diff-channels = <1>, <2>;
>> excitation-channels = <0>, <3>;
>> excitation-current-microamp = <500>;
>> burnout-current-nanoamp = <1000>;
>> ti,vref-source = <ADS112C14_VREF_SOURCE_EXTERNAL>;
>> label = "rtd-diagnostic";
>> };
>
> This would mean we wouldn't be able to use iio_chan_spec .channel and
> .channel2 to describe inputs because of duplicate sysfs attributes, no?
>
Yes, that is a bit unfortunate. At least there the labels to tell them
apart. I guess we would just need to use consecutive channel and channel2
when dynamically allocating the channels to avoid conflict.
>>>> This makes things more flexible, but does make the driver a bit more
>>>> complex. For example, knowing when the current output needs to be
>>>> enabled or disabled. For now, I have chosen a lazy-enable where they
>>>> are not turned on until the first measurement is taken that requires
>>>> them, but then they stay on until another measurement is taken that
>>>> doesn't require them. This can lead to some oddness with the diagnostic
>>>> channels that may be measuring something that indirectly requires the
>>>> current output (i.e. the external reference voltage when it is connected
>>>> to a resistor rather than a power supply). This means you need to take
>>>> a measurement that requires the current output to be enabled before the
>>>> diagnostic channels will give accurate readings.
>>>
>>> This is the same approach I took around the BOC, it feels kinda hacky
>>> but it makes sense. Just an idea I thought about just now: What if we
>>> have an additional write-only "_enable" sysfs attribute for these
>>> channels?
>>
>> I would not want to make a write-only attribute, we always want to be
>> able to read back what the current state is.
>
> Yeah, I don't know why I said WO. Reading would be fine too.
>
>>
>> Do you mean an _enable for just the BOC? I think I would do it like I
>> suggested above instead.
>
> No, no just the BOC. The BOC, IDAC and rest of side effects. Thinking
> about it some more, it would be a bit redundant but clearer if proper
> documentation is provided.
>
I would be interested to see what Jonathan has to say about this too.
Generally, his advice has been to avoid attributes that power things
on and off if we can help it.
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: gpu: img,powervr-rogue: Document GE8300 GPU in Renesas R-Car D3
From: Niklas Söderlund @ 2026-06-16 18:28 UTC (permalink / raw)
To: Marek Vasut, Geert Uytterhoeven, Conor Dooley, David Airlie,
Frank Binns, Krzysztof Kozlowski, Maarten Lankhorst, Magnus Damm,
Matt Coster, Maxime Ripard, Rob Herring, Simona Vetter,
Thomas Zimmermann, devicetree, dri-devel, linux-renesas-soc
In-Reply-To: <20260616175835.2109336-2-niklas.soderlund+renesas@ragnatech.se>
On 2026-06-16 19:58:34 +0200, Niklas Söderlund wrote:
> Document Imagination Technologies PowerVR Rogue GE8300 BNVC 22.67.54.30
> present in Renesas R-Car R8A77995 D3 SoCs.
>
> Compared to other R-Car Gen3 SoCs the D3 only have one power domain and
> it is always on. Extend the list of special cases for this to also cover
> R8A77995 and update the description of it.
>
> Signed-off-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> * Changes since v1
> - Sort img,img-ge8300 after img,img-ge7800.
> - Fold special case for power domain into an existing one and update the
> description.
> ---
> .../devicetree/bindings/gpu/img,powervr-rogue.yaml | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> index a1f54dbae3f3..b93f49f1fa0a 100644
> --- a/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> +++ b/Documentation/devicetree/bindings/gpu/img,powervr-rogue.yaml
> @@ -25,6 +25,11 @@ properties:
> - renesas,r8a779a0-gpu
> - const: img,img-ge7800
> - const: img,img-rogue
> + - items:
> + - enum:
> + - renesas,r8a77995-gpu
> + - const: img,img-ge8300
> + - const: img,img-rogue
> - items:
> - enum:
> - ti,am62-gpu
> @@ -114,6 +119,7 @@ allOf:
> contains:
> enum:
> - img,img-ge7800
> + - img,img-ge8300
> - img,img-gx6250
> - thead,th1520-gpu
> then:
> @@ -159,14 +165,14 @@ allOf:
> - if:
> properties:
> compatible:
> - contains:
The 'contains' node should have been kept, my bad. I wonder why 'make
dt_binding_check' or `make dtbs_check' did not catch it. Sorry for the
noise.
> - const: thead,th1520-gpu
> + enum:
> + - renesas,r8a77995-gpu
> + - thead,th1520-gpu
> then:
> properties:
> power-domains:
> items:
> - - description: The single, unified power domain for the GPU on the
> - TH1520 SoC, integrating all internal IP power domains.
> + - description: The single, unified power domain for the GPU.
> power-domain-names: false
> required:
> - power-domains
> --
> 2.54.0
>
--
Kind Regards,
Niklas Söderlund
^ permalink raw reply
* Re: [PATCH 1/4] ASoC: qcom: audioreach: compute active channel maps from channel_map
From: Srinivas Kandagatla @ 2026-06-16 18:52 UTC (permalink / raw)
To: Neil Armstrong, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kancy2333, linux-sound, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <a35d7f95-c158-46d1-b136-b901dcfbf101@linaro.org>
On 6/16/26 4:12 PM, Neil Armstrong wrote:
> On 6/16/26 16:59, Srinivas Kandagatla wrote:
>>
>>
>> On 6/15/26 2:54 PM, Neil Armstrong wrote:
>>> On 6/15/26 11:36, Srinivas Kandagatla wrote:
>>>> On 6/15/26 10:31 AM, Neil Armstrong wrote:
>>>>> On 6/15/26 10:38, Srinivas Kandagatla wrote:
>>>>>>
>>>>>>
>>>>>> On 6/10/26 8:41 AM, Neil Armstrong wrote:
>>>>>>> The Qualcom SM8650 based Ayaneo Pocket S2 gaming device has a set
>>>>>>> of 2 WSA speakers connected on the WSA2 lines.
>>>>>>>
>>>>>>> But the Audioreach DSP only handles WSA2 in pair with the WSA
>>>>>>> interface by using the upper bits of the active_channels_mask
>>>>>>> for WSA2 and the lower bits for WSA:
>>>>>>>
>>>>>>> /-------------------------------------------------\
>>>>>>> | Bits | 3 | 2 | 1 | 0 |
>>>>>>> |-------------------------------------------------|
>>>>>>> | Line | WSA2 Ch2 | WSA2 Ch1 | WSA Ch2 | WSA Ch1 |
>>>>>>> \-------------------------------------------------/
>>>>>>>
>>>>>> No, this is not totally correct, if the setup only has WSA2, then
>>>>>> channel 0 and 1 should be WSA2 channels.
>>>>>>
>>>>>> What is the backend dai id that is in DT, it should be
>>>>>>
>>>>>> sound-dai = <&q6apmbedai WSA2_CODEC_DMA_RX_0>;
>>>>>>
>
> Yeah 0xC0 for active_channels_mask and channel_mapping =
> { PCM_CHANNEL_FL, PCM_CHANNEL_FR };
>
> I tried to keep the leading 0, but since the channel_mapping table is
> allocated with
> the size of the num_channels parameter, you can ony have 2 entries.
>
>>
>> From DSP docs:
>> https://github.com/AudioReach/audioreach-engine/blob/master/fwk/api/
>> modules/media_fmt_api_basic.h#L780
>>
>> Channel[i] mapping describes channel i. Each element i of the array
>> describes channel i inside the buffer where i is less than num_channels.
>> An unused channel is set to 0.
>>
>>
>> So unused channels should be set to zero, but the patch padding the
>> channels starting form zero.
>
> My understanding in my trial and error is that the DSP will map each
> entry of the channel_mapping to the active_channels_mask bits in order
> so you can have a non linear active_channels_mask like b10101010 which
> has 4 channels active and pass a channel_mapping table with 4 entries.
>
You are correct, I was mis-interpreting some of the comments from
modules/media_fmt_api_basic.h specially the channel map comment.
Also confirmed this internally so we are good,
I tested this on T14s,
Tested-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
--srini
> The is what I implemented here, and it gives a lot of flexibility on how
> to connect speakers to the interface.
>
> Neil
^ permalink raw reply
* Re: [PATCH 2/4] ASoC: qcom: sc8280xp: add Ayaneo Pocket S2 card with special WSA channel mapping
From: Srinivas Kandagatla @ 2026-06-16 18:54 UTC (permalink / raw)
To: Neil Armstrong, Srinivas Kandagatla, Liam Girdwood, Mark Brown,
Jaroslav Kysela, Takashi Iwai, Bjorn Andersson, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: kancy2333, linux-sound, linux-arm-msm, linux-kernel, devicetree
In-Reply-To: <20260610-topic-sm8650-ayaneo-pocket-s2-wsa2-fix-v1-2-18bb19c5ca22@linaro.org>
On 6/10/26 8:41 AM, Neil Armstrong wrote:
> The WSA Speakers are connected on the WSA2 interface, but the
> WSA and WSA2 links are handled as a single dai and DSP interface, so
> we need to specify the channel mapping of the Ayaneo Pocket S2 for the
> WSA dai in order to have functional playback and avoid DSP errors.
>
> Let's add a special entry for the Ayaneo Pocket S2 adding a prepare
> callback in order to set the proper channel mapping.
>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
> ---
lgtm,
Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
--srini
> sound/soc/qcom/sc8280xp.c | 56 +++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 56 insertions(+)
>
> diff --git a/sound/soc/qcom/sc8280xp.c b/sound/soc/qcom/sc8280xp.c
> index 1f3afc6d015c..2f1688c9f317 100644
> --- a/sound/soc/qcom/sc8280xp.c
> +++ b/sound/soc/qcom/sc8280xp.c
> @@ -14,6 +14,7 @@
> #include "qdsp6/q6afe.h"
> #include "qdsp6/q6apm.h"
> #include "qdsp6/q6prm.h"
> +#include "qdsp6/q6dsp-common.h"
> #include "common.h"
> #include "sdw.h"
>
> @@ -49,6 +50,7 @@ struct snd_soc_common {
> bool codec_sysclk_set;
> bool mi2s_mclk_enable;
> bool mi2s_bclk_enable;
> + int (*snd_prepare)(struct snd_pcm_substream *substream);
> };
>
> struct sc8280xp_snd_data {
> @@ -193,12 +195,58 @@ static int sc8280xp_snd_hw_params(struct snd_pcm_substream *substream,
> return 0;
> }
>
> +/*
> + * WSA and WSA2 are handled as a single interface with the
> + * following channels mask:
> + * __________________________________________________
> + * | Bits | 3 | 2 | 1 | 0 |
> + * ---------------------------------------------------
> + * | Line | WSA2 Ch2 | WSA2 Ch1 | WSA Ch2 | WSA Ch1 |
> + * ---------------------------------------------------
> + *
> + * The Ayaneo Pocket S2 speakers are connected only to
> + * the WSA2 interface and the WSA interface is not enabled.
> + *
> + * Set the channel mapping on the WSA2 channels only.
> + */
> +static const unsigned int ayaneo_ps2_channels_mapping[] = {
> + 0, /* WSA Ch1 */
> + 0, /* WSA Ch2 */
> + PCM_CHANNEL_FL, /* WSA2 Ch1 */
> + PCM_CHANNEL_FR /* WSA2 Ch2 */
> +};
> +
> +static int ayaneo_ps2_snd_prepare(struct snd_pcm_substream *substream)
> +{
> + struct snd_soc_pcm_runtime *rtd = snd_soc_substream_to_rtd(substream);
> + struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
> + unsigned int channels = substream->runtime->channels;
> +
> + if (cpu_dai->id != WSA_CODEC_DMA_RX_0)
> + return 0;
> +
> + if (channels != 2)
> + return -EINVAL;
> +
> + return snd_soc_dai_set_channel_map(cpu_dai, 0, NULL,
> + ARRAY_SIZE(ayaneo_ps2_channels_mapping),
> + ayaneo_ps2_channels_mapping);
> +}
> +
> static int sc8280xp_snd_prepare(struct snd_pcm_substream *substream)
> {
> struct snd_soc_pcm_runtime *rtd = snd_soc_substream_to_rtd(substream);
> struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0);
> struct sc8280xp_snd_data *data = snd_soc_card_get_drvdata(rtd->card);
>
> + if (data->snd_soc_common_priv->snd_prepare) {
> + int ret;
> +
> + ret = data->snd_soc_common_priv->snd_prepare(substream);
> + if (ret)
> + return ret;
> + }
> +
> return qcom_snd_sdw_prepare(substream, &data->stream_prepared[cpu_dai->id]);
> }
>
> @@ -273,6 +321,13 @@ static int sc8280xp_platform_probe(struct platform_device *pdev)
> return devm_snd_soc_register_card(dev, card);
> }
>
> +static struct snd_soc_common ayaneo_ps2_priv_data = {
> + .driver_name = "ayaneo-ps2",
> + .dapm_widgets = sc8280xp_dapm_widgets,
> + .num_dapm_widgets = ARRAY_SIZE(sc8280xp_dapm_widgets),
> + .snd_prepare = ayaneo_ps2_snd_prepare,
> +};
> +
> static struct snd_soc_common kaanapali_priv_data = {
> .driver_name = "kaanapali",
> .dapm_widgets = sc8280xp_dapm_widgets,
> @@ -341,6 +396,7 @@ static struct snd_soc_common sm8750_priv_data = {
> };
>
> static const struct of_device_id snd_sc8280xp_dt_match[] = {
> + {.compatible = "ayaneo,pocket-s2-sndcard", .data = &ayaneo_ps2_priv_data},
> {.compatible = "qcom,kaanapali-sndcard", .data = &kaanapali_priv_data},
> {.compatible = "qcom,qcm6490-idp-sndcard", .data = &qcm6490_priv_data},
> {.compatible = "qcom,qcs615-sndcard", .data = &qcs615_priv_data},
>
^ permalink raw reply
* [PATCH] dt-bindings: sound: add toshiba,apb-dummy-codec binding
From: Pablo D. Bergamasco @ 2026-06-16 18:56 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Vaibhav Agarwal, Mark Greer, Liam Girdwood, Mark Brown,
linux-sound, devicetree, linux-kernel, Pablo D. Bergamasco
Add device tree binding documentation for the Toshiba APBridge
dummy ALSA SoC codec used in the Greybus audio framework.
Fixes the following checkpatch warning:
WARNING: DT compatible string appears un-documented
Signed-off-by: Pablo D. Bergamasco <danpablo@gmail.com>
---
.../sound/toshiba,apb-dummy-codec.yaml | 33 +++++++++++++++++++
MAINTAINERS | 1 +
2 files changed, 34 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/toshiba,apb-dummy-codec.yaml
diff --git a/Documentation/devicetree/bindings/sound/toshiba,apb-dummy-codec.yaml b/Documentation/devicetree/bindings/sound/toshiba,apb-dummy-codec.yaml
new file mode 100644
index 000000000000..e0542feeb980
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/toshiba,apb-dummy-codec.yaml
@@ -0,0 +1,33 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/sound/toshiba,apb-dummy-codec.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Toshiba APBridge Dummy ALSA SoC Codec
+
+maintainers:
+ - Vaibhav Agarwal <vaibhav.agarwal@linaro.org>
+
+description:
+ The APBridge dummy codec is part of the Greybus audio framework,
+ used in Project Ara modular phone hardware. It provides a dummy
+ ALSA SoC codec driver for the APBridge audio interface, enabling
+ audio streaming between Greybus modules and the host processor
+ via the APBridge protocol.
+
+properties:
+ compatible:
+ const: toshiba,apb-dummy-codec
+
+required:
+ - compatible
+
+additionalProperties: false
+
+examples:
+ - |
+ codec {
+ compatible = "toshiba,apb-dummy-codec";
+ };
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index b2040011a386..b6b4b488c0f7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11077,6 +11077,7 @@ GREYBUS AUDIO PROTOCOLS DRIVERS
M: Vaibhav Agarwal <vaibhav.sr@gmail.com>
M: Mark Greer <mgreer@animalcreek.com>
S: Maintained
+F: Documentation/devicetree/bindings/sound/toshiba,apb-dummy-codec.yaml
F: drivers/staging/greybus/audio_apbridgea.c
F: drivers/staging/greybus/audio_apbridgea.h
F: drivers/staging/greybus/audio_codec.c
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v7 9/9] arm64: dts: mediatek: Add MediaTek MT6392 PMIC dtsi
From: Rob Herring @ 2026-06-16 18:57 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: linux-mediatek, Val Packett, Dmitry Torokhov, Krzysztof Kozlowski,
Conor Dooley, Sen Chu, Sean Wang, Macpaul Lin, Lee Jones,
Matthias Brugger, AngeloGioacchino Del Regno, Liam Girdwood,
Mark Brown, Linus Walleij, Louis-Alexis Eyraud, Julien Massot,
Fabien Parent, Akari Tsuyukusa, Chen Zhong, linux-input,
devicetree, linux-kernel, linux-pm, linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2LiMHnaTK6QnsLxJDtw0fZ_N9LELw0iCorOZwHuWXus0g@mail.gmail.com>
On Tue, Jun 16, 2026 at 10:32 AM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> > > arch/arm64/boot/dts/mediatek/mt6392.dtsi | 75 ++++++++++++++++++++++++
> >
> > Nothing is using this so it is a dead file that doesn't get tested.
>
> Hi, it's not referenced as the dtsi inclusion was removed in the
> original patch from 2019 for an easier merging of support for mt8516
> pumpkin boards [1][2].
> If you prefer in the next revision I can add another patch to readd it
> to the existing pumpkin board.
That or move this patch to the series for the board(s). If the board
is already upstream, then add the include in *this* patch.
Rob
^ permalink raw reply
* Re: [PATCH 3/4] input: misc: Add Qualcomm SPMI PMIC haptics driver
From: Dmitry Torokhov @ 2026-06-16 19:22 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Fenglin Wu, linux-arm-msm, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Lee Jones, Stephen Boyd, Bjorn Andersson,
Konrad Dybcio, David Collins, Subbaraman Narayanamurthy,
Kamal Wadhwa, kernel, linux-input, devicetree, linux-kernel
In-Reply-To: <eb693705-c0c3-427b-a924-5aa907fd65bb@oss.qualcomm.com>
On Tue, Jun 16, 2026 at 12:25:55PM +0200, Konrad Dybcio wrote:
> On 6/16/26 12:08 PM, Fenglin Wu wrote:
> > Add an initial driver for the Qualcomm PMIH010x PMIC haptics module,
> > named as HAP530_HV. This module supports several play modes, including
> > DIRECT_PLAY, FIFO, PAT_MEM, and SWR, each with distinct data sourcing
> > and hardware data handling logic. Currently, the driver provides support
> > for two play modes using the input force-feedback framework: FF_CONSTANT
> > effect for DIRECT_PLAY mode and FF_PERIODIC effect with FF_CUSTOM
> > waveform for FIFO mode.
> >
> > Assisted-by: Claude:claude-4-6-sonnet
> > Signed-off-by: Fenglin Wu <fenglin.wu@oss.qualcomm.com>
> > ---
>
> [...]
>
> > +static int cfg_write(struct qcom_haptics *h, u32 off, u32 val)
>
> static inline
No, let compiler do its job and decide whether it should be inlined or
not.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 3/5] ASoC: qcom: qdsp6: q6prm: add the missing MCLK clock IDs
From: Srinivas Kandagatla @ 2026-06-16 19:41 UTC (permalink / raw)
To: Hongyang Zhao, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Daniel Drake, Katsuhiro Suzuki,
Matteo Martelli, Binbin Zhou, Srinivas Kandagatla,
Jaroslav Kysela, Takashi Iwai, Bjorn Andersson, Konrad Dybcio
Cc: linux-sound, devicetree, linux-kernel, linux-arm-msm,
mohammad.rafi.shaik, rosh, Neil Armstrong, Srinivas Kandagatla
In-Reply-To: <20260607-rubikpi-next-20260605-v1-3-7f334e16fea6@thundersoft.com>
On 6/6/26 7:58 PM, Hongyang Zhao wrote:
> From: Neil Armstrong <neil.armstrong@linaro.org>
>
> Add the missing MCLK ids for the q6prm DSP interface.
>
> Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
> Signed-off-by: Neil Armstrong <neil.armstrong@linaro.org>
please add your signed-off here
for more info take a look at
Documentation/process/submitting-patches.rst
> ---
> sound/soc/qcom/qdsp6/q6prm-clocks.c | 5 +++++
> sound/soc/qcom/qdsp6/q6prm.h | 11 +++++++++++
> 2 files changed, 16 insertions(+)
>
> diff --git a/sound/soc/qcom/qdsp6/q6prm-clocks.c b/sound/soc/qcom/qdsp6/q6prm-clocks.c
> index 4c574b48ab00..51b131fa9531 100644
> --- a/sound/soc/qcom/qdsp6/q6prm-clocks.c
> +++ b/sound/soc/qcom/qdsp6/q6prm-clocks.c
> @@ -42,6 +42,11 @@ static const struct q6dsp_clk_init q6prm_clks[] = {
> Q6PRM_CLK(LPASS_CLK_ID_INT5_MI2S_IBIT),
> Q6PRM_CLK(LPASS_CLK_ID_INT6_MI2S_IBIT),
> Q6PRM_CLK(LPASS_CLK_ID_QUI_MI2S_OSR),
> + Q6PRM_CLK(LPASS_CLK_ID_MCLK_1),
> + Q6PRM_CLK(LPASS_CLK_ID_MCLK_2),
> + Q6PRM_CLK(LPASS_CLK_ID_MCLK_3),
> + Q6PRM_CLK(LPASS_CLK_ID_MCLK_4),
> + Q6PRM_CLK(LPASS_CLK_ID_MCLK_5),
> Q6PRM_CLK(LPASS_CLK_ID_WSA_CORE_MCLK),
> Q6PRM_CLK(LPASS_CLK_ID_WSA_CORE_NPL_MCLK),
> Q6PRM_CLK(LPASS_CLK_ID_VA_CORE_MCLK),
> diff --git a/sound/soc/qcom/qdsp6/q6prm.h b/sound/soc/qcom/qdsp6/q6prm.h
> index a988a32086fe..6917e70bcb8a 100644
> --- a/sound/soc/qcom/qdsp6/q6prm.h
> +++ b/sound/soc/qcom/qdsp6/q6prm.h
> @@ -52,6 +52,17 @@
> /* Clock ID for QUINARY MI2S OSR CLK */
> #define Q6PRM_LPASS_CLK_ID_QUI_MI2S_OSR 0x116
>
> +/* Clock ID for MCLK1 */
> +#define Q6PRM_LPASS_CLK_ID_MCLK_1 0x300
> +/* Clock ID for MCLK2 */
> +#define Q6PRM_LPASS_CLK_ID_MCLK_2 0x301
> +/* Clock ID for MCLK3 */
> +#define Q6PRM_LPASS_CLK_ID_MCLK_3 0x302
> +/* Clock ID for MCLK4 */
> +#define Q6PRM_LPASS_CLK_ID_MCLK_4 0x303
> +/* Clock ID for MCLK5 */
> +#define Q6PRM_LPASS_CLK_ID_MCLK_5 0x304
> +
> #define Q6PRM_LPASS_CLK_ID_WSA_CORE_MCLK 0x305
> #define Q6PRM_LPASS_CLK_ID_WSA_CORE_NPL_MCLK 0x306
>
>
^ permalink raw reply
* Re: [PATCH 1/4] dt-bindings: iio: adc: add ti,ads122c14
From: David Lechner @ 2026-06-16 19:54 UTC (permalink / raw)
To: Conor Dooley
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Kurt Borja, Nguyen Minh Tien,
linux-iio, devicetree, linux-kernel
In-Reply-To: <20260616-spoon-ducky-b05e9bf7e999@spud>
On 6/16/26 11:07 AM, Conor Dooley wrote:
> On Mon, Jun 15, 2026 at 04:59:59PM -0500, David Lechner (TI) wrote:
>> Add new bindings for ti,ads122c14 and similar devices.
>>
>> This is an ADC that is primarily intended for use with temperature
>> sensors. There are a few unusual properties because of this. In
>> particular, the reference voltage source and current output requirements
>> can be different for each measurement, so these are included in the
>> channel bindings.
>>
>> The REFP/REFN reference voltage is usually just connected to a resistor
>> that is being driven by the ADC's current outputs, so there is special
>> property for this case rather than requiring a regulator to be defined
>> to represent that.
>>
>> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
>> have preferred an enum of strings).
>>
>> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
>> ---
>> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 224 +++++++++++++++++++++
>> MAINTAINERS | 7 +
>> include/dt-bindings/iio/adc/ti,ads112c14.h | 11 +
>> 3 files changed, 242 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>> new file mode 100644
>> index 000000000000..dc7f37cad772
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>> @@ -0,0 +1,224 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Texas Instruments' ADS112C14 and similar ADC chips
>> +
>> +description: |
>> + Supports the following Texas Instruments' ADC chips:
>> + - ADS112C14 (16-bit)
>> + - ADS122C14 (24-bit)
>> +
>> + https://www.ti.com/lit/ds/symlink/ads122c14.pdf
>> +
>> + These chips are primarily designed for use with temperature sensors such as
>> + RTDs and thermocouples. The channel bindings reflect this in that each channel
>> + represents the conditions required to make a measurement rather than strictly
>> + just the physical input channels.
>> +
>> +maintainers:
>> + - David Lechner <dlechner@baylibre.com>
>> +
>> +unevaluatedProperties: false
>
> Weird positioning of this.
IIRC, Rob asked that I do it in this order on another binding a while
ago (the reasoning being that it was too far away from properties:
otherwise), so I've done it like this on a few bindings now. It doesn't
make much difference to me though.
>
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - ti,ads112c14
>> + - ti,ads122c14
>> +
>> + reg:
>> + items:
>> + - minimum: 0x40
>> + maximum: 0x47
>> +
>> + clocks:
>> + maxItems: 1
>> + description: Optional external clock connected to GPIO3 pin.
>> +
>> + avdd-supply: true
>> + dvdd-supply: true
>> +
>> + refp-supply: true
>> + refn-supply: true
>> +
>> + refp-refn-resistor-ohms:
>
> Missing prefix here and elsewhere.
I thought we didn't need a prefix when using standard units.
>> + ti,vref-source:
>> + description: |
>> + Indicates the source for the reference voltage for this channel.
>> + 0 - Internal 2.5V reference
>> + 1 - Internal 1.25V reference
>> + 2 - External reference (REFP-REFN)
>> + 3 - AVDD as reference
>
> My usual complaint here about things you have to make macros for, could
> these just be strings from the get-go?
As in the commit message, this is an existing property name, so I didn't want
to change the type. But I agree that strings are better for this kind of thing
so perhaps I should just use a different property name instead so we can do
it better.
^ permalink raw reply
* Re: [PATCH 2/13] dt-bindings: sound: Add Qualcomm QAIF binding
From: Srinivas Kandagatla @ 2026-06-16 19:59 UTC (permalink / raw)
To: Harendra Gautam, Srinivas Kandagatla
Cc: Mark Brown, Liam Girdwood, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-sound, linux-arm-msm, devicetree,
linux-kernel
In-Reply-To: <20260605103739.3557573-3-harendra.gautam@oss.qualcomm.com>
On 6/5/26 11:37 AM, Harendra Gautam wrote:
> Add a Devicetree binding for the Qualcomm Audio Interface (QAIF) CPU DAI
> controller used on the Shikra audio platform.
>
> QAIF moves PCM data between system memory and external serial audio
> interfaces through the AIF path, and between memory and the internal Bolero
> digital codec through the CIF path. The controller needs a binding so
> platform Devicetree files can describe its MMIO region, DMA IOMMU stream,
> clocks, interrupt, DAI cells and per-interface AIF configuration.
>
> Describe the single register region, one EE interrupt, the required GCC
> LPASS and audio core clocks, the DMA IOMMU mapping, and 'aif-interface@N'
> child nodes used for static PCM, TDM or MI2S configuration.
>
> Signed-off-by: Harendra Gautam <harendra.gautam@oss.qualcomm.com>
> ---
> .../devicetree/bindings/sound/qcom,qaif.yaml | 353 ++++++++++++++++++
> 1 file changed, 353 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/qcom,qaif.yaml
>
> diff --git a/Documentation/devicetree/bindings/sound/qcom,qaif.yaml b/Documentation/devicetree/bindings/sound/qcom,qaif.yaml
Pl run dt-bindings checks before posting.
> new file mode 100644
> index 000000000000..5b385e05a650
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/qcom,qaif.yaml
> @@ -0,0 +1,361 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/sound/qcom,qaif.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Audio Interface (QAIF) CPU DAI Controller
> +
> +maintainers:
> + - Harendra Gautam <harendra.gautam@oss.qualcomm.com>
> +
> +description:
> + |
> + The Qualcomm Audio Interface (QAIF) is a fully configurable DMA-based
> + audio subsystem controller. It serialises and deserialises PCM audio
> + between system memory and external serial audio peripherals (PCM, TDM,
> + I2S, MI2S) through the AIF path, and transfers parallel audio between
> + memory and an internal WCD codec through the CIF path.
> +
> + AIF (Audio Interface): up to 13 multi-lane Unified Audio Interfaces,
> + each supporting up to 8 independent data lanes. Each lane is individually
> + configurable as TX (output/speaker) or RX (input/mic). All lanes of an
> + interface share a single bit clock and frame sync. Supported modes are
> + PCM (short/long sync), TDM, and MI2S (stereo/mono). Per-interface
> + configuration includes sync source (master/slave), sync mode, sync delay,
> + sync inversion, slot width (8/16/24/32-bit), sample width, active slot
> + masks (up to 32 slots), bits-per-lane frame size, lane enable/direction
> + masks, loopback, output-enable control, and full-cycle path support for
> + long chip-to-chip connections.
> +
> + CIF (Codec Interface): up to 32 RDDMA (playback) and 32 WRDMA (capture)
> + channels connecting to an internal codec over a parallel bus. Each channel
> + supports active-channel enable mask (up to 16 channels), frame-sync
> + selection, frame-sync delay, frame-sync output gating, dynamic clock
> + gating, and 16-bit packing/unpacking.
> +
> + Note on RX/TX naming convention: in QAIF, RX refers to the capture path
> + (audio received from the interface into memory) and TX refers to the
> + playback path (audio transmitted from memory to the interface). This
> + applies to both AIF lane directions and CIF slot/mask properties.
> +
> + DMA engine: RDDMA fetches audio from DDR/TCM/LPM into a shared SRAM
> + latency buffer (SHRAM) and drains it to the interface. WRDMA collects
> + data from the interface into SHRAM and writes it to memory. Each DMA
> + owns a private SHRAM region defined by start address and length registers.
> + Burst sizes of 1/2/4/8/16 beats (64-bit) are supported with up to 4
> + outstanding transactions per DMA. Two QSB master ports (QXM0 for TCM,
> + QXM1 for DDR/LPM) provide the memory interface.
> +
> + Resources are partitioned among up to 5 Execution Engines (EEs) via
> + EE map registers. Each EE owns a set of DMAs, audio interfaces, and
> + interface groups, and receives its own independent interrupt output.
> + The interrupt hierarchy has a two-level structure: a summary register
> + identifies the event class (DMA period, underflow/overflow, error
> + response, audio interface underflow/overflow, group done, rate detector,
> + VFR), and per-resource status registers identify the specific channel.
> +
> + Interface grouping (bonding) allows up to 6 groups of audio and codec
> + interfaces to start synchronously and align their DMA period interrupts
> + within half a frame duration using the RDDMA padding feature.
> +
> + Two rate detector blocks measure the frequency of incoming frame sync or
> + word select signals and generate interrupts on rate change, undetected
> + rate, or sync timeout.
> +
> + Block diagram::
> +
> + System Memory (DDR / LPM / TCM)
> + +---------------------------------+
> + | Circular Buffers (ping-pong) |
> + +----------+----------+-----------+
> + | ^
> + 64-bit AXI 64-bit AXI
> + | |
> + +----------v----------+-----------+
> + | QSB Master Ports |
> + | +----------+ +----------+ |
> + | | QXM0 | | QXM1 | |
> + | +----+-----+ +-----+----+ |
> + +-------|--------------|----------+
> + | |
> + +-------v--------------v----------+
> + | Shared RAM (SHRAM) |
> + | +------------+ +------------+ |
> + | | QXM0 Read | | QXM0 Write | |
> + | | SHRAM | | SHRAM | |
> + | +------------+ +------------+ |
> + | +------------+ +------------+ |
> + | | QXM1 Read | | QXM1 Write | |
> + | | SHRAM | | SHRAM | |
> + | +------------+ +------------+ |
> + +---+--------+--------+-------+---+
> + | | | |
> + +---v--+ +--v---+ +--v---+ +-v----+
> + |RDDMA | |RDDMA | |WRDMA | |WRDMA |
> + | AIF | | CIF | | AIF | | CIF |
> + |[0..n]| |[0..n]| |[0..n]| |[0..n]|
> + +--+---+ +--+---+ +--+---+ +-+----+
> + | | ^ ^
> + | TX | TX | RX | RX
> + v v | |
> + +--+--------------------+ +----+----------+
> + | Unified Audio Intf | | Codec DMA |
> + | (AIF 0..12) | | Interface |
> + | | | (CIF) |
> + | AUD_INTFa block: | | |
> + | - Serializer (TX) | | RDDMA: DDR -> |
> + | - De-serializer (RX) | | internal |
> + | - Sync gen/detect | | codec |
> + | - Up to 8 data lanes | | WRDMA: codec |
> + | - PCM / TDM / MI2S | | -> DDR |
> + | - Near Pad Logic | | Up to 16 ch |
> + +--+--------------------+ +----+----------+
> + | Lane 0..7 (TX/RX) | Parallel bus
> + | Bit clk + Frame sync | + Frame sync
> + v v
> + +--+--------+ +------+------+
> + | External | | Internal |
> + | Serial | | Digital |
> + | Peripherals| | Codec |
> + | (PCM/TDM/ | | (Bolero/ |
> + | MI2S) | | WCD) |
> + +-----------+ +-------------+
> +
> +properties:
> + compatible:
> + enum:
> + - qcom,shikra-qaif-cpu
> +
> + reg:
> + maxItems: 1
> +
> + iommus:
> + maxItems: 1
> +
> + clocks:
> + minItems: 15
> + maxItems: 15
> +
> + clock-names:
> + items:
> + - const: lpass_config_clk
> + - const: lpass_core_axim_clk
> + - const: aud_dma_clk
> + - const: aud_dma_mem_clk
> + - const: bus_clk
> + - const: aif_if0_ebit_clk
> + - const: aif_if0_ibit_clk
> + - const: aif_if1_ebit_clk
> + - const: aif_if1_ibit_clk
> + - const: aif_if2_ebit_clk
> + - const: aif_if2_ibit_clk
> + - const: aif_if3_ebit_clk
> + - const: aif_if3_ibit_clk
> + - const: ext_mclka_clk
> + - const: ext_mclkb_clk
Also do we really need to specify these 15 clocks even though I use only
one aif interface on my board.
should some of these clocks belong to each aif child node instead of
global qaif-cpu?
> +
> + interrupts:
> + maxItems: 1
> +
> + '#sound-dai-cells':
> + const: 1
> +
> + '#address-cells':
> + const: 1
> +
> + '#size-cells':
> + const: 0
> +
> + status: true
> +
> +patternProperties:
> + "^aif-interface@[0-9a-f]+$":
> + type: object
> + description:
> + AIF interface configuration child node. The compatible string
> + identifies the serial protocol the interface is wired for on the
> + board. The unit address matches the hardware AIF interface index.
> + properties:
> + compatible:
> + enum:
> + - qcom,qaif-pcm-dai
> + - qcom,qaif-tdm-dai
> + - qcom,qaif-mi2s-dai
> + reg:
> + maxItems: 1
> + description: |
> + Hardware AIF interface index (AUD_INTFa block index). This value
> + also serves as the ALSA DAI ID; it corresponds directly to the
> + QAIF_MI2S_TDM_AIFn constants in <dt-bindings/sound/qcom,qaif.h>
> + (e.g. reg = <2> selects QAIF_MI2S_TDM_AIF2).
> + qcom,qaif-aif-sync-mode:
> + $ref: /schemas/types.yaml#/definitions/uint32
These should be enum instead of uint32, simillar comments apply to some
of the properties that have only few supported values.
> + description:
> + Sync mode. Use QAIF_AIF_SYNC_MODE_SHORT (0) for short (pulse)
> + sync or QAIF_AIF_SYNC_MODE_LONG (1) for long (level) sync.
> + qcom,qaif-aif-sync-src:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Sync source. Use QAIF_AIF_SYNC_SRC_SLAVE (0) for slave mode
> + or QAIF_AIF_SYNC_SRC_MASTER (1) for master mode.
> + qcom,qaif-aif-invert-sync:
> + type: boolean
> + description: Invert the frame sync polarity.
> + qcom,qaif-aif-sync-delay:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description: Number of bit-clock cycles to delay the data relative to sync.
This looks redundant to qcom,qaif-aif-sync-mode, which already indicates
the delay information?
> + qcom,qaif-aif-slot-width-rx:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + RX slot width in bits. This is a board-specific hardware constraint
> + determined by the wiring of the serial audio interface.
> + qcom,qaif-aif-slot-width-tx:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + TX slot width in bits. This is a board-specific hardware constraint
> + determined by the wiring of the serial audio interface.
> + qcom,qaif-aif-slot-en-rx-mask:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Bitmask of active RX slots. Board-specific — determined by which
> + TDM slots the codec is wired to on this board.
> + qcom,qaif-aif-slot-en-tx-mask:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Bitmask of active TX slots. Board-specific — determined by which
> + TDM slots the codec is wired to on this board.
> + qcom,qaif-aif-loopback:
> + type: boolean
> + description: Enable loopback mode (presence enables loopback).
What is this mode used for, testing ?
> + qcom,qaif-aif-ctrl-data-oe:
> + type: boolean
> + description: Enable output drive on the control/data line.
will this be ever false?
> + qcom,qaif-aif-lane-config:
> + $ref: /schemas/types.yaml#/definitions/uint32-matrix
> + description:
> + Lane configuration matrix. Each row is a pair <enable direction>
> + for one lane starting from lane 0, up to 8 lanes. Use
> + QAIF_AIF_LANE_ENABLE (1) or QAIF_AIF_LANE_DISABLE (0) for enable.
> + Use QAIF_AIF_LANE_DIR_TX (0) for TX (speaker) or QAIF_AIF_LANE_DIR_RX
> + (1) for RX (mic). TX and RX lanes should each be grouped contiguously.
what do you mean ? can you elobrate how can you enforce this?
> + maxItems: 8
> + items:
> + items:
> + - description: Lane enable (0 = disabled, 1 = enabled)
> + enum: [0, 1]
> + - description: Lane direction (0 = TX/speaker, 1 = RX/mic)
> + enum: [0, 1]
> + qcom,qaif-aif-full-cycle-en:
> + type: boolean
> + description: Enable full-cycle sync (effective in sync master mode).
> + qcom,qaif-aif-bits-per-lane:
> + $ref: /schemas/types.yaml#/definitions/uint32
> + description:
> + Number of slots per lane. The frame length is computed as
bits per lane?
> + slot-width multiplied by bits-per-lane.
> + if:
> + properties:
> + compatible:
> + const: qcom,qaif-mi2s-dai
> + then:
> + description:
> + MI2S interface. Sync mode and slot-enable masks are fixed by the
> + MI2S protocol and must not be set in DT. Mono/stereo mode is
> + determined at runtime from the stream channel count.
> + properties:
> + qcom,qaif-aif-sync-mode: false
> + qcom,qaif-aif-slot-en-rx-mask: false
> + qcom,qaif-aif-slot-en-tx-mask: false
> + else:
> + description:
> + PCM or TDM interface. Sync mode and slot-enable masks are
> + board-specific and must be provided. Mono mode does not apply.
> + required:
> + - qcom,qaif-aif-sync-mode
> + - qcom,qaif-aif-slot-en-rx-mask
> + - qcom,qaif-aif-slot-en-tx-mask
> +
> + required:
> + - compatible
> + - reg
> + additionalProperties: false
> +
> +required:
> + - compatible
> + - reg
> + - iommus
do we
> + - clocks
> + - clock-names
> + - interrupts
> + - '#sound-dai-cells'
> +
> +additionalProperties: false
> +
> +examples:
> + - |
> + /* Shikra platform example */
> + #include <dt-bindings/interrupt-controller/arm-gic.h>
> + #include <dt-bindings/interrupt-controller/irq.h>
> + #include <dt-bindings/sound/qcom,qaif.h>
> + #include <dt-bindings/clock/qcom,shikra-audiocorecc.h>
> + #include <dt-bindings/clock/qcom,gcc-shikra.h>
> +
> + qaif_cpu: audio@a000000 {
> + compatible = "qcom,shikra-qaif-cpu";
> + reg = <0x0 0x0a000000 0x0 0x20000>;
> + iommus = <&apps_smmu 0x1c0 0x0>;
> + clocks = <&gcc GCC_LPASS_CONFIG_CLK>,
> + <&gcc GCC_LPASS_CORE_AXIM_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_AUD_DMA_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_AUD_DMA_MEM_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_BUS_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_AIF_IF0_EBIT_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_AIF_IF0_IBIT_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_AIF_IF1_EBIT_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_AIF_IF1_IBIT_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_AIF_IF2_EBIT_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_AIF_IF2_IBIT_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_AIF_IF3_EBIT_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_AIF_IF3_IBIT_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_EXT_MCLKA_OUT_CLK>,
> + <&audiocorecc AUDIO_CORE_CC_EXT_MCLKB_OUT_CLK>;
> + clock-names = "lpass_config_clk",
> + "lpass_core_axim_clk",
> + "aud_dma_clk",
> + "aud_dma_mem_clk",
> + "bus_clk",
> + "aif_if0_ebit_clk",
> + "aif_if0_ibit_clk",
> + "aif_if1_ebit_clk",
> + "aif_if1_ibit_clk",
> + "aif_if2_ebit_clk",
> + "aif_if2_ibit_clk",
> + "aif_if3_ebit_clk",
> + "aif_if3_ibit_clk",
> + "ext_mclka_clk",
> + "ext_mclkb_clk";
> + #sound-dai-cells = <1>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + interrupts = <GIC_SPI 331 IRQ_TYPE_LEVEL_HIGH>;
> + status = "okay";
> +
> + qaif_aif_if2: aif-interface@2 {
> + compatible = "qcom,qaif-tdm-dai";
> + reg = <QAIF_MI2S_TDM_AIF2>;
> + qcom,qaif-aif-sync-mode = <QAIF_AIF_SYNC_MODE_LONG>;
> + qcom,qaif-aif-sync-src = <QAIF_AIF_SYNC_SRC_MASTER>;
> + qcom,qaif-aif-sync-delay = <1>;
> + qcom,qaif-aif-slot-width-rx = <32>;
> + qcom,qaif-aif-slot-width-tx = <32>;
> + qcom,qaif-aif-slot-en-rx-mask = <0x3>;
> + qcom,qaif-aif-slot-en-tx-mask = <0x3>;
> + qcom,qaif-aif-ctrl-data-oe;
> + /* Lane 0: RX (mic); Lane 1: TX (speaker) */
> + qcom,qaif-aif-lane-config = <QAIF_AIF_LANE_ENABLE QAIF_AIF_LANE_DIR_RX>,
> + <QAIF_AIF_LANE_ENABLE QAIF_AIF_LANE_DIR_TX>;
> + /* frame length = slot-width (32) * bits-per-lane (2) = 64 bits */
> + qcom,qaif-aif-bits-per-lane = <2>;
> + };
> + };
^ permalink raw reply
* Re: [PATCH 3/9] firmware: imx: ele: Add API functions for OCOTP fuse access
From: Frank Li @ 2026-06-16 20:05 UTC (permalink / raw)
To: Frieder Schrempf
Cc: Frieder Schrempf, Pankaj Gupta, Srinivas Kandagatla, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Shawn Guo, devicetree,
imx, linux-arm-kernel, linux-kernel
In-Reply-To: <cea74ed4-1003-419e-8da3-1c62b1ace726@kontron.de>
On Tue, Jun 16, 2026 at 07:59:54PM +0200, Frieder Schrempf wrote:
> On 16.06.26 17:36, Frank Li wrote:
> > On Tue, Jun 16, 2026 at 01:52:18PM +0200, Frieder Schrempf wrote:
> >> From: Frieder Schrempf <frieder.schrempf@kontron.de>
> >>
> >> The ELE S400 API provides read and write access to the OCOTP fuse
> >> registers. This adds the necessary API functions imx_se_read_fuse()
> >> and imx_se_write_fuse() to be used by other drivers such as the
> >> OCOTP S400 NVMEM driver.
> >>
> >> This is ported from the downstream vendor kernel.
> >>
> >> Signed-off-by: Frieder Schrempf <frieder.schrempf@kontron.de>
> >> ---
> >> drivers/firmware/imx/ele_base_msg.c | 122 ++++++++++++++++++++++++++++++++++++
> >> drivers/firmware/imx/ele_base_msg.h | 6 ++
> >> include/linux/firmware/imx/se_api.h | 3 +
> >> 3 files changed, 131 insertions(+)
> >>
> > ...
> >> +++ b/include/linux/firmware/imx/se_api.h
> >> @@ -11,4 +11,7 @@
> >> #define SOC_ID_OF_IMX8ULP 0x084d
> >> #define SOC_ID_OF_IMX93 0x9300
> >>
> >> +int imx_se_read_fuse(void *se_if_data, uint16_t fuse_id, u32 *value);
> >> +int imx_se_write_fuse(void *se_if_data, uint16_t fuse_id, u32 value);
> >> +
> >
> > This API should implement in fuse drivers. Other consume should use standard
> > fuse API to get value. If put here, it may bypass fuse driver.
>
> The reason this is here, is the downstream implementation in linux-imx
> and the current code organization.
Downstream may not good enough, sometime, it is quick solution.
> I thought there is some good reason
> to have shared functions and it looks like Pankaj structured it like
> this so all API functions live in ele_base_msg.c and the internal
> structs and defines in ele_base_msg.h and se_ctrl.h are not exposed to
> other drivers.
>
> If I would move this into imx-ocotp-ele.c, then I would also need to
> change how the code is organized and make the internal se_api functions
> exposed to other drivers. I don't know if that is really a good idea.
>
> I get your point but it looks like this contradicts the intention of
> having a clean API in the firmware driver.
You can refer imx-ocotp-scu.c, structure should be similar, only difference
is that lower transfer APIs.
Frank
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox