* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Vladimir Zapolskiy @ 2026-03-31 10:43 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20260331091721.61613-3-krzysztof.kozlowski@oss.qualcomm.com>
On 3/31/26 12:17, Krzysztof Kozlowski wrote:
> The static 'struct qcom_cc_driver_data' contains probe match-like data
> and is not modified: neither by the driver defining it nor by common.c
> code using it.
>
> Make it const for code safety and code readability.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2 5/7] phy: ti: gmii-sel: add support for J722S SoC family
From: Nora Schiffer @ 2026-03-31 10:35 UTC (permalink / raw)
To: Vladimir Oltean
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <20260330223741.pmrx25cslrlpbcea@skbuf>
On Tue, 2026-03-31 at 01:37 +0300, Vladimir Oltean wrote:
> Hi Nora,
>
> On Tue, Mar 24, 2026 at 01:29:41PM +0100, Nora Schiffer wrote:
> > The J722S gmii-sel is mostly identical to the AM64's, but additionally
> > supports SGMII.
> >
> > Signed-off-by: Nora Schiffer <nora.schiffer@ew.tq-group.com>
> > ---
> > drivers/phy/ti/phy-gmii-sel.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/drivers/phy/ti/phy-gmii-sel.c b/drivers/phy/ti/phy-gmii-sel.c
> > index 6213c2b6005a5..4e242b1892334 100644
> > --- a/drivers/phy/ti/phy-gmii-sel.c
> > +++ b/drivers/phy/ti/phy-gmii-sel.c
> > @@ -251,6 +251,13 @@ struct phy_gmii_sel_soc_data phy_gmii_sel_soc_am654 = {
> > .regfields = phy_gmii_sel_fields_am654,
> > };
> >
> > +static const
> > +struct phy_gmii_sel_soc_data phy_gmii_sel_soc_j722s = {
> > + .use_of_data = true,
> > + .regfields = phy_gmii_sel_fields_am654,
> > + .extra_modes = BIT(PHY_INTERFACE_MODE_SGMII),
>
> I'm not familiar with the hardware, but "mostly identical to AM64, but
> additionally supports SGMII" does not explain why j722s does not inherit
> the features that am654 has (PHY_GMII_SEL_RGMII_ID_MODE and
> BIT(PHY_GMII_SEL_FIXED_TX_DELAY).
>
> The phy-gmii-sel from j722s does support RGMII, right? Because in lack
> of the PHY_GMII_SEL_RGMII_ID_MODE feature, phy_gmii_sel_mode() will just
> silently skip the regmap_field_write(regfield, rgmii_id) call, and
> return successfully despite an incomplete configuration.
>
> We have the phy_validate() call and phy_ops::validate() through which
> the PHY can report to the Ethernet controller which phy_interface_t it
> supports and which it doesn't. If the j722s doesn't support RGMII, maybe
> it should implement this method.
Thanks for noticing this, PHY_GMII_SEL_RGMII_ID_MODE and
PHY_GMII_SEL_FIXED_TX_DELAY are missing indeed - will fix in v3. I made the
mistake to rebase from an older kernel version where these flags didn't exist
yet and neglected to double check when the rebase went through without
conflicts. I assume I didn't notice any issues because our bootloader left the
controller in the correct state.
Best,
Nora
>
> > +};
> > +
--
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
https://www.tq-group.com/
^ permalink raw reply
* Re: [PATCH v11 03/22] drm: Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-03-31 10:33 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Maxime Ripard, Harry Wentland, Leo Li, Rodrigo Siqueira,
Alex Deucher, Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Thomas Zimmermann, Andrzej Hajda,
Neil Armstrong, Robert Foss, Laurent Pinchart, Jonas Karlman,
Jernej Skrabec, Sandy Huang, Heiko Stübner, Andy Yan,
Jani Nikula, Rodrigo Vivi, Joonas Lahtinen, Tvrtko Ursulin,
Dmitry Baryshkov, Sascha Hauer, Rob Herring, Jonathan Corbet,
Shuah Khan, kernel, amd-gfx, dri-devel, linux-kernel,
linux-arm-kernel, linux-rockchip, intel-gfx, intel-xe, linux-doc,
Werner Sembach, Andri Yngvason, Marius Vlad
In-Reply-To: <acsNoCDsPtEhtkRn@intel.com>
On Tuesday, 31 March 2026 01:56:16 Central European Summer Time Ville Syrjälä wrote:
> On Sat, Mar 28, 2026 at 02:49:04AM +0200, Ville Syrjälä wrote:
> > On Fri, Mar 27, 2026 at 01:56:06PM +0100, Nicolas Frattaroli wrote:
> > > On Thursday, 26 March 2026 18:58:25 Central European Standard Time Ville Syrjälä wrote:
> > > > On Thu, Mar 26, 2026 at 06:02:47PM +0100, Maxime Ripard wrote:
> > > > > On Wed, Mar 25, 2026 at 08:43:15PM +0200, Ville Syrjälä wrote:
> > > > > > On Wed, Mar 25, 2026 at 03:56:58PM +0100, Maxime Ripard wrote:
> > > > > > > On Wed, Mar 25, 2026 at 01:03:07PM +0200, Ville Syrjälä wrote:
> > > > > > > > On Wed, Mar 25, 2026 at 09:24:27AM +0100, Maxime Ripard wrote:
> > > > > > > > > On Tue, Mar 24, 2026 at 09:53:35PM +0200, Ville Syrjälä wrote:
> > > > > > > > > > On Tue, Mar 24, 2026 at 08:10:11PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > On Tuesday, 24 March 2026 18:00:45 Central European Standard Time Ville Syrjälä wrote:
> > > > > > > > > > > > On Tue, Mar 24, 2026 at 05:01:07PM +0100, Nicolas Frattaroli wrote:
> > > > > > > > > > > > > +enum drm_connector_color_format {
> > > > > > > > > > > > > + /**
> > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_AUTO: The driver or display protocol
> > > > > > > > > > > > > + * helpers should pick a suitable color format. All implementations of a
> > > > > > > > > > > > > + * specific display protocol must behave the same way with "AUTO", but
> > > > > > > > > > > > > + * different display protocols do not necessarily have the same "AUTO"
> > > > > > > > > > > > > + * semantics.
> > > > > > > > > > > > > + *
> > > > > > > > > > > > > + * For HDMI, "AUTO" picks RGB, but falls back to YCbCr 4:2:0 if the
> > > > > > > > > > > > > + * bandwidth required for full-scale RGB is not available, or the mode
> > > > > > > > > > > > > + * is YCbCr 4:2:0-only, as long as the mode and output both support
> > > > > > > > > > > > > + * YCbCr 4:2:0.
> > > > > > > > > > > > > + *
> > > > > > > > > > > > > + * For display protocols other than HDMI, the recursive bridge chain
> > > > > > > > > > > > > + * format selection picks the first chain of bridge formats that works,
> > > > > > > > > > > > > + * as has already been the case before the introduction of the "color
> > > > > > > > > > > > > + * format" property. Non-HDMI bridges should therefore either sort their
> > > > > > > > > > > > > + * bus output formats by preference, or agree on a unified auto format
> > > > > > > > > > > > > + * selection logic that's implemented in a common state helper (like
> > > > > > > > > > > > > + * how HDMI does it).
> > > > > > > > > > > > > + */
> > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_AUTO = 0,
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + /**
> > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_RGB444: RGB output format
> > > > > > > > > > > > > + */
> > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_RGB444,
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + /**
> > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR444: YCbCr 4:4:4 output format (ie.
> > > > > > > > > > > > > + * not subsampled)
> > > > > > > > > > > > > + */
> > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR444,
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + /**
> > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR422: YCbCr 4:2:2 output format (ie.
> > > > > > > > > > > > > + * with horizontal subsampling)
> > > > > > > > > > > > > + */
> > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR422,
> > > > > > > > > > > > > +
> > > > > > > > > > > > > + /**
> > > > > > > > > > > > > + * @DRM_CONNECTOR_COLOR_FORMAT_YCBCR420: YCbCr 4:2:0 output format (ie.
> > > > > > > > > > > > > + * with horizontal and vertical subsampling)
> > > > > > > > > > > > > + */
> > > > > > > > > > > > > + DRM_CONNECTOR_COLOR_FORMAT_YCBCR420,
> > > > > > > > > > > >
> > > > > > > > > > > > Seems like this should document what the quantization range
> > > > > > > > > > > > should be for each format.
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I don't think so? If you want per-component bit depth values,
> > > > > > > > > > > DRM_FORMAT_* defines would be the appropriate values to use. This
> > > > > > > > > > > enum is more abstract than that, and is there to communicate
> > > > > > > > > > > YUV vs. RGB and chroma subsampling, with bit depth being handled
> > > > > > > > > > > by other properties.
> > > > > > > > > > >
> > > > > > > > > > > If you mean the factor used for subsampling, then that'd only be
> > > > > > > > > > > relevant if YCBCR410 was supported where one chroma plane isn't
> > > > > > > > > > > halved but quartered in resolution. I suspect 4:1:0 will never
> > > > > > > > > > > be added; no digital display protocol standard supports it to my
> > > > > > > > > > > knowledge, and hopefully none ever will.
> > > > > > > > > >
> > > > > > > > > > No, I mean the quantization range (16-235 vs. 0-255 etc).
> > > > > > > > > >
> > > > > > > > > > The i915 behaviour is that YCbCr is always limited range,
> > > > > > > > > > RGB can either be full or limited range depending on the
> > > > > > > > > > "Broadcast RGB" property and other related factors.
> > > > > > > > >
> > > > > > > > > So far the HDMI state has both the format and quantization range as
> > > > > > > > > different fields. I'm not sure we need to document the range in the
> > > > > > > > > format field, maybe only mention it's not part of the format but has a
> > > > > > > > > field of its own?
> > > > > > > >
> > > > > > > > I think we only have it for RGB (on some drivers only?). For YCbCr
> > > > > > > > I think the assumption is limited range everywhere.
> > > > > > > >
> > > > > > > > But I'm not really concerned about documenting struct members.
> > > > > > > > What I'm talking about is the *uapi* docs. Surely userspace
> > > > > > > > will want to know what the new property actually does so the
> > > > > > > > uapi needs to be documented properly. And down the line some
> > > > > > > > new driver might also implement the wrong behaviour if there
> > > > > > > > is no clear specification.
> > > > > > >
> > > > > > > Ack
> > > > > > >
> > > > > > > > So I'm thinking (or perhaps hoping) the rule might be something like:
> > > > > > > > - YCbCr limited range
> > > > > > > > - RGB full range if "Broadcast RGB" property is not present
> > > > > > >
> > > > > > > Isn't it much more complicated than that for HDMI though? My
> > > > > > > recollection was that any VIC but VIC1 would be limited range, and
> > > > > > > anything else full range?
> > > > > >
> > > > > > Do we have some driver that implements the CTA-861 CE vs. IT mode
> > > > > > logic but doesn't expose the "Broadcast RGB" property? I was hoping
> > > > > > those would always go hand in hand now.
> > > > >
> > > > > I'm not sure. i915 and the HDMI state helpers handle it properly (I
> > > > > think?) but it looks like only vc4 registers the Broadcast RGB property
> > > > > and uses the HDMI state helpers.
> > > > >
> > > > > And it looks like amdgpu registers Broadcast RGB but doesn't use
> > > > > drm_default_rgb_quant_range() which seems suspicious?
> > > >
> > > > If they want just manual full vs. limited then they should
> > > > limit the property to not expose the "auto" option at all.
> > > >
> > > > amdgpu also ties this in with the "colorspace" property, which
> > > > originally in i915 only controlled the infoframes/etc. But on
> > > > amdgpu it now controls various aspects of output color
> > > > transformation. The end result is that the property is a complete
> > > > mess with most of the values making no sense. And for whatever
> > > > reason everyone involved refused to remove/deprecate the
> > > > nonsensical values :/
> > > >
> > > > Looks like this series should make sure the documentation for
> > > > the "colorspace" property is in sync with the new property
> > > > as well. Currently now it's giving conflicting information.
> > > >
> > >
> > > I take it the problematic information is in
> > >
> > > * DOC: standard connector properties
> > > *
> > > * Colorspace:
> > >
> > > and probably specifically BT2020_YCC's (and BT2020_RGB's?) insistence
> > > that they "produce RGB content".
> > >
> > > I think we probably just have to change the statement "The variants
> > > BT2020_RGB and BT2020_YCC are equivalent and the driver chooses between
> > > RGB and YCbCr on its own."
> > >
> > > The "on its own" here would get turned into "based on the color format
> > > property".
> > >
> > > Speaking of i915, that patch is one of the very few (5) patches in
> > > this series still lacking a review (hint hint nudge nudge). I'd like
> > > to get some more feedback on the remaining patches before I send out
> > > another revision, so that it's hopefully not just docs changes (I
> > > know better than to think those patches must be perfect and won't
> > > need revision.)
> >
> > The i915 code around this is already a big mess, and I don't really
> > adding to that mess. So I think we'll need to do some refactoring before
> > we add anything there. I already started typing something and so far
> > it looks fairly straightforward, so I should have something soon.
>
> OK, posted something
> https://lore.kernel.org/intel-gfx/20260330235339.29479-1-ville.syrjala@linux.intel.com/T/#m7c349478ca6c856fbc68d5e2178f1aa31678a05f
Thanks! I'll take a look at this today to get a more solid idea of
where the pain points you highlighted are.
I'll also rebase/reimplement my i915 color format implementation
(sans the DP-MST part, as discussed) on top of this on the next
revision. I was never fully happy with the current one due to the
logic being shoehorned into the already existing i915 fallback
format logic, so I'm quite happy to have another opportunity to
implement it with less historic baggage.
> Are the wayland/compositor/color management folks on board with
> these new properties? I don't think I see the usual suspects on
> the cc list.
I don't know which precise group of people you refer to, but at
least from the Collabora side of things, the userspace Wayland
people are on board with these new properties. In Weston, we use
it to implement the Weston frontend's "color-format" option in a
WIP branch at
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1859
I've also been made aware that LibreELEC is aware, and will look
into making use of it rather than their own kernel patches.
Kind regards,
Nicolas Frattaroli
> >
> > While doing that several questions came to my mind though:
> >
> > * More interactions with the colorspace property, but I sent
> > a separate mail already about that
> >
> > * Which conversion matrix to use, and the answer I suspect
> > should be "ask the colorspace property", as mentioned in the
> > other mail
> >
> > * Should we flat out reject color formats (and I suppose also
> > colorspace prop values) the sink doesn't claim to support?
> >
> > If yes, then I think we'll have to forget about adding anything
> > to i915 MST code. The way the MST stuff works is that if one
> > stream needs a modeset then all the related streams get modeset
> > as well. Thus if the user replaces a monitor getting fed with a
> > YCbCr stream just as another stream is being modeset, then the
> > entire atomic commit could fail due to the YCbCr stream getting
> > rejected.
> >
> > I think eventually we might have to invent some mechanism where
> > all the input into the modeset computation is cached somehow,
> > and said cache updated only on explicit userspace modesets.
> > Either that or we have to come up with a way to skip some of
> > the calculations that depend on external factors. Either way
> > it's going to be a pain.
> >
> > OTOH if we don't mind feeding the sink with stuff it can't
> > understand, then I suppose we might add YCbCr 4:4:4 support
> > for MST. It shouldn't be any different from RGB apart from
> > the RGB->YCbCr conversion, which is handled elsewhere. But
> > YCbCr 4:2:0 is definitely out either way, the MST code has
> > no support for that currently.
> >
>
>
^ permalink raw reply
* [PATCH net-next] net: airoha: Set REG_RX_CPU_IDX() once in airoha_qdma_fill_rx_queue()
From: Lorenzo Bianconi @ 2026-03-31 10:33 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Lorenzo Bianconi
Cc: linux-arm-kernel, linux-mediatek, netdev
It is not necessary to update REG_RX_CPU_IDX register for each iteration
of the descriptor loop in airoha_qdma_fill_rx_queue routine.
Move REG_RX_CPU_IDX configuration out of the descriptor loop and rely on
the last queue head value updated in the descriptor loop.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 82e53c60f561f6314fbf201ba8bc8711e40edc68..e09442580f376b6810b6e4023794e93f63dac209 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -572,11 +572,12 @@ static int airoha_qdma_fill_rx_queue(struct airoha_queue *q)
WRITE_ONCE(desc->msg1, 0);
WRITE_ONCE(desc->msg2, 0);
WRITE_ONCE(desc->msg3, 0);
+ }
+ if (nframes)
airoha_qdma_rmw(qdma, REG_RX_CPU_IDX(qid),
RX_RING_CPU_IDX_MASK,
FIELD_PREP(RX_RING_CPU_IDX_MASK, q->head));
- }
return nframes;
}
---
base-commit: 93d04e76bcf1e81f36f5ea7ad620a07747f1527c
change-id: 20260331-airoha-cpu-idx-out-off-loop-41ea4b99404c
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH 2/2] clk: qcom: Constify list of critical CBCR registers
From: Konrad Dybcio @ 2026-03-31 10:30 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <20260331091721.61613-4-krzysztof.kozlowski@oss.qualcomm.com>
On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
> The static array 'xxx_critical_cbcrs' contains probe match-like data and
> is not modified: neither by the driver defining it nor by common.c code
> using it.
>
> Make it const for code safety and code readability.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Konrad Dybcio @ 2026-03-31 10:30 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <7fece0e7-31b0-4b92-855e-bd9e210cc651@oss.qualcomm.com>
On 3/31/26 12:20 PM, Krzysztof Kozlowski wrote:
> On 31/03/2026 12:13, Krzysztof Kozlowski wrote:
>> On 31/03/2026 12:10, Konrad Dybcio wrote:
>>> On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
>>>> On 31/03/2026 11:33, Konrad Dybcio wrote:
>>>>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>>>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>>>>> and is not modified: neither by the driver defining it nor by common.c
>>>>>> code using it.
>>>>>>
>>>>>> Make it const for code safety and code readability.
>>>>>>
>>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>> --- a/drivers/clk/qcom/common.h
>>>>>> +++ b/drivers/clk/qcom/common.h
>>>>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>>>>> size_t num_icc_hws;
>>>>>> unsigned int icc_first_node_id;
>>>>>> bool use_rpm;
>>>>>> - struct qcom_cc_driver_data *driver_data;
>>>>>> + const struct qcom_cc_driver_data *driver_data;
>>>>>
>>>>> This can be a const ptr to const data, even
>>>>
>>>> None of other elements in 'qcom_cc_desc' is const pointer, even though
>>>> they also could. If doing this change, let's make it consistent - so
>>>> shall all of them be const?
>>>
>>> I thought about it, but then it turns out that videocc-sm8550.c has:
>>>
>>> video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
>>>
>>> So we'd have to duplicate the entire struct
>>
>> No, that's not a problem. Pointer is not modified and we speak here
>> about const pointer.
>>
>
> So to clarify what the code is doing now: I constified the pointed data.
> Not the pointer. If you ask me to constify the pointer itself, it's
> fine, it will compile/work as well, but do you want it?
>
> It allows only definition with initialization, no further changes later.
> All existing drivers would be fine with it, so just confirm that's your
> preferred expression.
I'm actually a little on the verge. Maybe let's keep the current
iteration of this patch after all, as it'd be a mess to undo if it turned
out to be useful
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* [PATCH 0/2] Fix active-low handling of MIPI CSI resets on i.MX8MQ
From: Robby Cai @ 2026-03-31 10:13 UTC (permalink / raw)
To: p.zabel, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam
Cc: devicetree, kernel, imx, linux-arm-kernel, linux-kernel,
aisheng.dong
Hi all,
This series updates the Device Tree bindings and reset controller driver
to correctly reflect the active-low polarity of the MIPI CSI reset lines
on i.MX8MQ.
The MIPI CSI reset signals are active-low, but the original reset
identifiers and driver implementation did not clearly indicate or handle
this polarity. Patch 1 updates the DT binding header to add *_RESET_N
variants for the MIPI CSI reset definitions, while keeping the old names
temporarily for DT ABI compatibility. Patch 2 updates the imx7 reset
controller driver to correctly treat these resets as active-low.
Thanks,
Robby
Robby Cai (2):
dt-bindings: reset: imx8mq: Add _N suffix to
IMX8MQ_RESET_MIPI_CSI*_RESET
reset: imx7: Fix handling of MIPI CSI resets on i.MX8MQ
drivers/reset/reset-imx7.c | 18 ++++++++++++------
include/dt-bindings/reset/imx8mq-reset.h | 18 ++++++++++++------
2 files changed, 24 insertions(+), 12 deletions(-)
--
2.37.1
^ permalink raw reply
* [PATCH 2/2] reset: imx7: Fix handling of MIPI CSI resets on i.MX8MQ
From: Robby Cai @ 2026-03-31 10:13 UTC (permalink / raw)
To: p.zabel, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam
Cc: devicetree, kernel, imx, linux-arm-kernel, linux-kernel,
aisheng.dong
In-Reply-To: <20260331101331.1405588-1-robby.cai@nxp.com>
The MIPI CSI reset signals on i.MX8MQ are active-low, but the reset
controller driver previously treated them as active-high, resulting in
incorrect assert/deassert behavior. Update the reset handling logic to
correctly process these active-low reset lines.
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
drivers/reset/reset-imx7.c | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/drivers/reset/reset-imx7.c b/drivers/reset/reset-imx7.c
index dd01fe11c5cb..b7048e1f10df 100644
--- a/drivers/reset/reset-imx7.c
+++ b/drivers/reset/reset-imx7.c
@@ -202,12 +202,12 @@ static const struct imx7_src_signal imx8mq_src_signals[IMX8MQ_RESET_NUM] = {
[IMX8MQ_RESET_PCIEPHY2_PERST] = { SRC_PCIE2_RCR, BIT(3) },
[IMX8MQ_RESET_PCIE2_CTRL_APPS_EN] = { SRC_PCIE2_RCR, BIT(6) },
[IMX8MQ_RESET_PCIE2_CTRL_APPS_TURNOFF] = { SRC_PCIE2_RCR, BIT(11) },
- [IMX8MQ_RESET_MIPI_CSI1_CORE_RESET] = { SRC_MIPIPHY1_RCR, BIT(0) },
- [IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET] = { SRC_MIPIPHY1_RCR, BIT(1) },
- [IMX8MQ_RESET_MIPI_CSI1_ESC_RESET] = { SRC_MIPIPHY1_RCR, BIT(2) },
- [IMX8MQ_RESET_MIPI_CSI2_CORE_RESET] = { SRC_MIPIPHY2_RCR, BIT(0) },
- [IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET] = { SRC_MIPIPHY2_RCR, BIT(1) },
- [IMX8MQ_RESET_MIPI_CSI2_ESC_RESET] = { SRC_MIPIPHY2_RCR, BIT(2) },
+ [IMX8MQ_RESET_MIPI_CSI1_CORE_RESET_N] = { SRC_MIPIPHY1_RCR, BIT(0) },
+ [IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET_N] = { SRC_MIPIPHY1_RCR, BIT(1) },
+ [IMX8MQ_RESET_MIPI_CSI1_ESC_RESET_N] = { SRC_MIPIPHY1_RCR, BIT(2) },
+ [IMX8MQ_RESET_MIPI_CSI2_CORE_RESET_N] = { SRC_MIPIPHY2_RCR, BIT(0) },
+ [IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET_N] = { SRC_MIPIPHY2_RCR, BIT(1) },
+ [IMX8MQ_RESET_MIPI_CSI2_ESC_RESET_N] = { SRC_MIPIPHY2_RCR, BIT(2) },
[IMX8MQ_RESET_DDRC1_PRST] = { SRC_DDRC_RCR, BIT(0) },
[IMX8MQ_RESET_DDRC1_CORE_RESET] = { SRC_DDRC_RCR, BIT(1) },
[IMX8MQ_RESET_DDRC1_PHY_RESET] = { SRC_DDRC_RCR, BIT(2) },
@@ -236,6 +236,12 @@ static int imx8mq_reset_set(struct reset_controller_dev *rcdev,
case IMX8MQ_RESET_PCIE_CTRL_APPS_EN:
case IMX8MQ_RESET_PCIE2_CTRL_APPS_EN:
+ case IMX8MQ_RESET_MIPI_CSI1_CORE_RESET_N:
+ case IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET_N:
+ case IMX8MQ_RESET_MIPI_CSI1_ESC_RESET_N:
+ case IMX8MQ_RESET_MIPI_CSI2_CORE_RESET_N:
+ case IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET_N:
+ case IMX8MQ_RESET_MIPI_CSI2_ESC_RESET_N:
case IMX8MQ_RESET_MIPI_DSI_PCLK_RESET_N:
case IMX8MQ_RESET_MIPI_DSI_ESC_RESET_N:
case IMX8MQ_RESET_MIPI_DSI_DPI_RESET_N:
--
2.37.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: reset: imx8mq: Add _N suffix to IMX8MQ_RESET_MIPI_CSI*_RESET
From: Robby Cai @ 2026-03-31 10:13 UTC (permalink / raw)
To: p.zabel, robh, krzk+dt, conor+dt, Frank.Li, s.hauer, festevam
Cc: devicetree, kernel, imx, linux-arm-kernel, linux-kernel,
aisheng.dong
In-Reply-To: <20260331101331.1405588-1-robby.cai@nxp.com>
The assert logic of the MIPI CSI reset signals is active-low on i.MX8MQ,
but the existing names do not indicate this explicitly. To improve
consistency and clarity, append the _N suffix to all
IMX8MQ_RESET_MIPI_CSI*_RESET definitions. The deprecated
IMX8MQ_RESET_MIPI_CSI*_RESET versions remain temporarily for DT ABI
compatibility and will be removed at an appropriate time in the future.
Signed-off-by: Robby Cai <robby.cai@nxp.com>
---
include/dt-bindings/reset/imx8mq-reset.h | 18 ++++++++++++------
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/include/dt-bindings/reset/imx8mq-reset.h b/include/dt-bindings/reset/imx8mq-reset.h
index 705870693ec2..83a155dbbd4a 100644
--- a/include/dt-bindings/reset/imx8mq-reset.h
+++ b/include/dt-bindings/reset/imx8mq-reset.h
@@ -46,12 +46,18 @@
#define IMX8MQ_RESET_PCIEPHY2_PERST 35 /* i.MX8MM/i.MX8MN does NOT support */
#define IMX8MQ_RESET_PCIE2_CTRL_APPS_EN 36 /* i.MX8MM/i.MX8MN does NOT support */
#define IMX8MQ_RESET_PCIE2_CTRL_APPS_TURNOFF 37 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET 38 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET 39 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI1_ESC_RESET 40 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI2_CORE_RESET 41 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET 42 /* i.MX8MM/i.MX8MN does NOT support */
-#define IMX8MQ_RESET_MIPI_CSI2_ESC_RESET 43 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET 38 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI1_CORE_RESET_N 38 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET 39 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI1_PHY_REF_RESET_N 39 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI1_ESC_RESET 40 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI1_ESC_RESET_N 40 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI2_CORE_RESET 41 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI2_CORE_RESET_N 41 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET 42 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI2_PHY_REF_RESET_N 42 /* i.MX8MM/i.MX8MN does NOT support */
+#define IMX8MQ_RESET_MIPI_CSI2_ESC_RESET 43 /* Deprecated. Use *_RESET_N instead */
+#define IMX8MQ_RESET_MIPI_CSI2_ESC_RESET_N 43 /* i.MX8MM/i.MX8MN does NOT support */
#define IMX8MQ_RESET_DDRC1_PRST 44 /* i.MX8MN does NOT support */
#define IMX8MQ_RESET_DDRC1_CORE_RESET 45 /* i.MX8MN does NOT support */
#define IMX8MQ_RESET_DDRC1_PHY_RESET 46 /* i.MX8MN does NOT support */
--
2.37.1
^ permalink raw reply related
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Krzysztof Kozlowski @ 2026-03-31 10:20 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Maxime Coquelin, Alexandre Torgue, linux-arm-msm, linux-clk,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <445a53e3-f467-40fc-9b01-dc776555c3fb@oss.qualcomm.com>
On 31/03/2026 12:13, Krzysztof Kozlowski wrote:
> On 31/03/2026 12:10, Konrad Dybcio wrote:
>> On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
>>> On 31/03/2026 11:33, Konrad Dybcio wrote:
>>>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>>>> and is not modified: neither by the driver defining it nor by common.c
>>>>> code using it.
>>>>>
>>>>> Make it const for code safety and code readability.
>>>>>
>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> --- a/drivers/clk/qcom/common.h
>>>>> +++ b/drivers/clk/qcom/common.h
>>>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>>>> size_t num_icc_hws;
>>>>> unsigned int icc_first_node_id;
>>>>> bool use_rpm;
>>>>> - struct qcom_cc_driver_data *driver_data;
>>>>> + const struct qcom_cc_driver_data *driver_data;
>>>>
>>>> This can be a const ptr to const data, even
>>>
>>> None of other elements in 'qcom_cc_desc' is const pointer, even though
>>> they also could. If doing this change, let's make it consistent - so
>>> shall all of them be const?
>>
>> I thought about it, but then it turns out that videocc-sm8550.c has:
>>
>> video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
>>
>> So we'd have to duplicate the entire struct
>
> No, that's not a problem. Pointer is not modified and we speak here
> about const pointer.
>
So to clarify what the code is doing now: I constified the pointed data.
Not the pointer. If you ask me to constify the pointer itself, it's
fine, it will compile/work as well, but do you want it?
It allows only definition with initialization, no further changes later.
All existing drivers would be fine with it, so just confirm that's your
preferred expression.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH net V2 0/2] Correct BD length masks and BQL accounting for multi-BD TX packets
From: patchwork-bot+netdevbpf @ 2026-03-31 10:20 UTC (permalink / raw)
To: Suraj Gupta
Cc: radhey.shyam.pandey, andrew+netdev, davem, edumazet, kuba, pabeni,
michal.simek, sean.anderson, daniel, ariane.keller, netdev,
linux-arm-kernel, linux-kernel
In-Reply-To: <20260327073238.134948-1-suraj.gupta2@amd.com>
Hello:
This series was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Fri, 27 Mar 2026 13:02:36 +0530 you wrote:
> This patch series fixes two issues in the Xilinx AXI Ethernet driver:
> 1. Corrects the BD length masks to match the AXIDMA IP spec.
> 2. Fixes BQL accounting for multi-BD TX packets.
>
> ---
> Changes in V2:
> - Define BD length masks with GENMASK(25, 0) per PG021.
> - Credit BQL using skb->len on packet completion instead of summing
> per-BD actual lengths from descriptor status.
>
> [...]
Here is the summary with links:
- [net,V2,1/2] net: xilinx: axienet: Correct BD length masks to match AXIDMA IP spec
https://git.kernel.org/netdev/net/c/393e0b4f178e
- [net,V2,2/2] net: xilinx: axienet: Fix BQL accounting for multi-BD TX packets
https://git.kernel.org/netdev/net/c/d1978d03e867
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] KVM: arm64: Don't populate TPIDR_EL2 in finalise_el2()
From: Mark Rutland @ 2026-03-31 10:18 UTC (permalink / raw)
To: Will Deacon
Cc: kvmarm, linux-arm-kernel, Oliver Upton, Marc Zyngier,
Catalin Marinas
In-Reply-To: <20260330152927.26300-1-will@kernel.org>
On Mon, Mar 30, 2026 at 04:29:26PM +0100, Will Deacon wrote:
> When running with VHE, TPIDR_EL2 is only used for the percpu offset once
> the ARM64_HAS_VIRT_HOST_EXTN capability has been detected, at which
> point cpu_copy_el2regs() will populate its contents from TPIDR_EL1.
>
> Remove the redundant initialisation of TPIDR_EL2 from finalise_el2().
It wasn't clear to me how this worked for both the boot CPU and
secondaries, since they both call finalise_el2(). How about a slightly
more elaborate commit message, e.g.
| Currently, it is not necessary for __finalise_el2() to configure
| TPIDR_EL2:
|
| * The hyp stub code does not consume the value of TPIDR_EL2.
|
| * On the boot cpu, TPIDR_EL1 is used for the percpu offset until the
| ARM64_HAS_VIRT_HOST_EXTN cpucap is detected and boot alternatives
| are patched. Before boot alternatives are patched,
| cpu_copy_el2regs() will copy TPIDR_EL1 into TPIDR_EL2. It is not
| necessary for __finalise_el2() to initialise TPIDR_EL2 before this.
|
| * Secondary CPUs are brought up after boot alternatives have been
| patched, and __secondary_switched() will initialize TPIDR_EL2 in
| 'init_cpu_task', after finalise_el2() calls __finalise_el2()
|
| * KVM hyp code which may consume TPIDR_EL2 is brought up after all
| secondaries have been booted, once TPIDR_El2 has been configured on
| all CPUs.
|
| Remove the redundant initialisation from __finalise_el2().
> Cc: Oliver Upton <oupton@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Signed-off-by: Will Deacon <will@kernel.org>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Mark.
> ---
>
> I spotted this by inspection as part of an ill-fated (abandoned) attempt
> at repurposing tpidr_elx for something else.
>
> arch/arm64/kernel/hyp-stub.S | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/hyp-stub.S b/arch/arm64/kernel/hyp-stub.S
> index 085bc9972f6b..8b8614c0b9a5 100644
> --- a/arch/arm64/kernel/hyp-stub.S
> +++ b/arch/arm64/kernel/hyp-stub.S
> @@ -105,11 +105,9 @@ SYM_CODE_START_LOCAL(__finalise_el2)
> msr_hcr_el2 x0
> isb
>
> - // Use the EL1 allocated stack, per-cpu offset
> + // Use the EL1 allocated stack
> mrs x0, sp_el1
> mov sp, x0
> - mrs x0, tpidr_el1
> - msr tpidr_el2, x0
>
> // FP configuration, vectors
> mrs_s x0, SYS_CPACR_EL12
> --
> 2.53.0.1018.g2bb0e51243-goog
>
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Konrad Dybcio @ 2026-03-31 10:17 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <445a53e3-f467-40fc-9b01-dc776555c3fb@oss.qualcomm.com>
On 3/31/26 12:13 PM, Krzysztof Kozlowski wrote:
> On 31/03/2026 12:10, Konrad Dybcio wrote:
>> On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
>>> On 31/03/2026 11:33, Konrad Dybcio wrote:
>>>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>>>> and is not modified: neither by the driver defining it nor by common.c
>>>>> code using it.
>>>>>
>>>>> Make it const for code safety and code readability.
>>>>>
>>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> --- a/drivers/clk/qcom/common.h
>>>>> +++ b/drivers/clk/qcom/common.h
>>>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>>>> size_t num_icc_hws;
>>>>> unsigned int icc_first_node_id;
>>>>> bool use_rpm;
>>>>> - struct qcom_cc_driver_data *driver_data;
>>>>> + const struct qcom_cc_driver_data *driver_data;
>>>>
>>>> This can be a const ptr to const data, even
>>>
>>> None of other elements in 'qcom_cc_desc' is const pointer, even though
>>> they also could. If doing this change, let's make it consistent - so
>>> shall all of them be const?
>>
>> I thought about it, but then it turns out that videocc-sm8550.c has:
>>
>> video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
>>
>> So we'd have to duplicate the entire struct
>
> No, that's not a problem. Pointer is not modified and we speak here
> about const pointer.
Right, I already had constifying the various struct members in mind
Konrad
^ permalink raw reply
* Re: [PATCH v4 1/9] dt-bindings: mfd: mt6397: Add MT6392 PMIC
From: Chen-Yu Tsai @ 2026-03-31 10:15 UTC (permalink / raw)
To: Luca Leonardo Scorcia
Cc: Krzysztof Kozlowski, linux-mediatek, Fabien Parent, Val Packett,
Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sen Chu, Sean Wang, Macpaul Lin, Lee Jones, Matthias Brugger,
AngeloGioacchino Del Regno, Linus Walleij, Liam Girdwood,
Mark Brown, Louis-Alexis Eyraud, Gary Bisson, Julien Massot,
Chen Zhong, linux-input, devicetree, linux-kernel, linux-pm,
linux-arm-kernel, linux-gpio
In-Reply-To: <CAORyz2+1bc9Z-opoNqyUU_WFzyXZKGQmR_Ur=4UonOC=AWtQ8w@mail.gmail.com>
On Tue, Mar 31, 2026 at 4:36 PM Luca Leonardo Scorcia
<l.scorcia@gmail.com> wrote:
>
> > > - required:
> > > - - compatible
> >
> > Not really, this affects existing ABI and might make the child schema
> > being applied. Basically regulators node can be anything now.
> >
> > This is definitely not a binding we want. The syntax for parent schema
> > when listing only compatibles is requiring this compatible. You cannot
> > have here whatever empty node.
>
> Hi, it felt quite strange to me too, but that's what I thought you
> meant with your previous suggestion [1].
> To keep the required attribute I would be happy to reintroduce the
> compatible here, in the regulator schema and the pmic dtsi.
>
> Before I do that and resubmit, could you please help me understand
> what you meant before?
I think the point is that compatibles for regulator sub-nodes on MFDs
is no longer accepted.
Instead if you want to have a separate binding for the regulator part,
you would need to reference the binding directly.
Say the binding is at bindings/regulator/mt6392.yaml, in this patch
you would have something after the "additionalProperties: false" like:
allOf:
- if:
properties:
"compatible":
contains:
const: mediatek,mt6392
then:
properties:
regulators:
$ref: /schemas/regulator/mt6392.yaml
else:
properties:
regulators:
required:
- compatible
And drop the "required: - compatible" part from the common regulator
node bits of the binding.
ChenYu
> Thank you!
>
> [1] https://lists.infradead.org/pipermail/linux-mediatek/2026-March/105060.html
> --
> Luca Leonardo Scorcia
> l.scorcia@gmail.com
>
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Krzysztof Kozlowski @ 2026-03-31 10:13 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Maxime Coquelin, Alexandre Torgue, linux-arm-msm, linux-clk,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <51a05279-1759-4c03-8bba-835a9e972ccb@oss.qualcomm.com>
On 31/03/2026 12:10, Konrad Dybcio wrote:
> On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
>> On 31/03/2026 11:33, Konrad Dybcio wrote:
>>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>>> and is not modified: neither by the driver defining it nor by common.c
>>>> code using it.
>>>>
>>>> Make it const for code safety and code readability.
>>>>
>>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> --- a/drivers/clk/qcom/common.h
>>>> +++ b/drivers/clk/qcom/common.h
>>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>>> size_t num_icc_hws;
>>>> unsigned int icc_first_node_id;
>>>> bool use_rpm;
>>>> - struct qcom_cc_driver_data *driver_data;
>>>> + const struct qcom_cc_driver_data *driver_data;
>>>
>>> This can be a const ptr to const data, even
>>
>> None of other elements in 'qcom_cc_desc' is const pointer, even though
>> they also could. If doing this change, let's make it consistent - so
>> shall all of them be const?
>
> I thought about it, but then it turns out that videocc-sm8550.c has:
>
> video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
>
> So we'd have to duplicate the entire struct
No, that's not a problem. Pointer is not modified and we speak here
about const pointer.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v8 01/10] dt-bindings: mfd: add support for the NXP SIUL2 module
From: Arnd Bergmann @ 2026-03-31 10:11 UTC (permalink / raw)
To: Khristine Andreea Barbulescu, Krzysztof Kozlowski,
Ghennadi Procopciuc
Cc: Linus Walleij, Bartosz Golaszewski, Krzysztof Kozlowski,
Conor Dooley, Chester Lin, Matthias Brugger, Ghennadi Procopciuc,
Larisa Grigore, Lee Jones, Shawn Guo, Sascha Hauer, Fabio Estevam,
Aisheng Dong, Jacky Bai, Greg Kroah-Hartman, Rafael J . Wysocki,
Alberto Ruiz, Christophe Lizzi, devicetree, Enric Balletbo,
Eric Chanudet, imx, linux-arm-kernel, open list:GPIO SUBSYSTEM,
linux-kernel, NXP S32 Linux Team, Pengutronix Kernel Team,
Vincent Guittot, Rob Herring
In-Reply-To: <4c46909d-641b-4389-bc4a-29394cb1d46d@oss.nxp.com>
On Tue, Mar 31, 2026, at 09:48, Khristine Andreea Barbulescu wrote:
>
> With the current layout, the SIUL2 node itself now contains the two
> MMIO ranges directly, while the remaining child node is only the
> pinctrl/GPIO function.
The thread started by saying this is an MFD "It can export information
about the SoC, configure the pinmux&pinconf for pins and it is also
a GPIO controller with interrupt capability." Having a combined
pinctrl/gpio/irqchip driver is normal, but can you clarify what
you plan to do with the "information about the SoC" part?
Was this a "soc_device" driver, or something else? Have you
concluded now that this is not going to be needed at all?
In that case, I guess having a monolithic driver is
indeed simpler than an MFD.
What I wonder about then is whether the binding needs to be changed
at all. With the current nxp,s32g2-siul2-pinctrl.yaml binding
and pinctrl-s32g2.c implementation, you seem to have a monolithic
device already, though missing the gpio functionality. Rather
than completely replacing this, I assume the easiest way then
would be to add the PGPD registers into this device node, right?
It is still a bit weird to list the individual register areas
inside of the larger device here, but that still seems better
than an incompatible binding change.
Arnd
^ permalink raw reply
* Re: [PATCH v2 2/2] mfd: tps65219: Make poweroff handler conditional on system-power-controller
From: Lee Jones @ 2026-03-31 10:12 UTC (permalink / raw)
To: Akashdeep Kaur
Cc: praneeth, nm, afd, vigneshr, kristo, robh, krzk+dt, conor+dt,
aaro.koskinen, andreas, khilman, rogerq, tony, linux-arm-kernel,
devicetree, linux-kernel, linux-omap, s-ramamoorthy, vishalm,
sebin.francis, d-gole, k-willis
In-Reply-To: <20260324101419.95616-3-a-kaur@ti.com>
---
On Tue, 24 Mar 2026, Akashdeep Kaur wrote:
> Currently, the TPS65219 driver unconditionally registers a poweroff
> handler. This causes issues on systems where a different component
> (such as TF-A firmware) should handle system poweroff instead.
>
> Make the poweroff handler registration conditional based on the
> "system-power-controller" device tree property. This follows the
> standard kernel pattern where only the designated power controller
> registers for system poweroff operations.
>
> On systems where the property is absent, the PMIC will not register
> a poweroff handler, allowing other poweroff mechanisms to function.
>
> Signed-off-by: Akashdeep Kaur <a-kaur@ti.com>
> ---
> drivers/mfd/tps65219.c | 14 ++++++++------
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/mfd/tps65219.c b/drivers/mfd/tps65219.c
> index 7275dcdb7c44..6fa202339a0c 100644
> --- a/drivers/mfd/tps65219.c
> +++ b/drivers/mfd/tps65219.c
> @@ -541,13 +541,15 @@ static int tps65219_probe(struct i2c_client *client)
> return ret;
> }
>
> - ret = devm_register_power_off_handler(tps->dev,
> - tps65219_power_off_handler,
> - tps);
> - if (ret) {
> - dev_err(tps->dev, "failed to register power-off handler: %d\n", ret);
> - return ret;
> + if (of_device_is_system_power_controller(tps->dev->of_node)) {
> + ret = devm_register_power_off_handler(tps->dev,
> + tps65219_power_off_handler,
> + tps);
> + if (ret)
> + return dev_err_probe(tps->dev, ret,
> + "failed to register power-off handler\n");
Couple of nits to fix.
The `"` should be aligned with the `(` and the `failed` should be capitalised.
> }
> +
> return 0;
> }
>
> --
> 2.34.1
>
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH 3/3] drm: lcdif: Wait for vblank before disabling DMA
From: Krzysztof Hałasa @ 2026-03-31 10:11 UTC (permalink / raw)
To: Paul Kocialkowski
Cc: dri-devel, imx, linux-arm-kernel, linux-kernel, Marek Vasut,
Stefan Agner, Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
David Airlie, Simona Vetter, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Lucas Stach, Marco Felsch,
Liu Ying
In-Reply-To: <20260330224619.2620782-4-paulk@sys-base.io>
Hi Paul,
Paul Kocialkowski writes:
> It is necessary to wait for the full frame to finish streaming
> through the DMA engine before we can safely disable it by removing
> the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> hardware confused and unable to resume streaming for the next frame.
>
> This causes the FIFO underrun and empty status bits to be set and
> a single solid color to be shown on the display, coming from one of
> the pixels of the previous frame. The issue occurs sporadically when
> a new mode is set, which triggers the crtc disable and enable paths.
>
> Setting the shadow load bit and waiting for it to be cleared by the
> DMA engine allows waiting for completion.
>
> The NXP BSP driver addresses this issue with a hardcoded 25 ms sleep.
...or "addressed" in the previous version :-)
Test results: it works for me: at 1080p60 and 2160p30. I.e. it fixed the
underrun problem. It's interesting how a CRTC shutdown can affect it's
subsequent start following an SW_RESET.
Or... perhaps it has something to do with the clocks? Also see below.
If somehow the DMA engine was "running" with it's clock disabled, it
would result in an underrun, or worse.
BTW apparently something converted your tab characters into spaces.
> --- a/drivers/gpu/drm/mxsfb/lcdif_kms.c
> +++ b/drivers/gpu/drm/mxsfb/lcdif_kms.c
> @@ -393,6 +393,22 @@ static void lcdif_disable_controller(struct lcdif_drm_private *lcdif)
> if (ret)
> drm_err(lcdif->drm, "Failed to disable controller!\n");
>
> + /*
> + * It is necessary to wait for the full frame to finish streaming
> + * through the DMA engine before we can safely disable it by removing
> + * the DISP_PARA_DISP_ON bit. Disabling it in-flight can leave the
> + * hardware confused and unable to resume streaming for the next frame.
> + */
> + reg = readl(lcdif->base + LCDC_V8_CTRLDESCL0_5);
> + reg |= CTRLDESCL0_5_SHADOW_LOAD_EN;
> + writel(reg, lcdif->base + LCDC_V8_CTRLDESCL0_5);
> +
> + ret = readl_poll_timeout(lcdif->base + LCDC_V8_CTRLDESCL0_5,
> + reg, !(reg & CTRLDESCL0_5_SHADOW_LOAD_EN),
> + 0, 36000); /* Wait ~2 frame times max */
I guess this comment is not necessarily correct - at 2160p30 one frame =
ca. 33 ms. Still works, though (I guess anything more than one frame is
enough). I don't know how long a frame on HDMI (or LVDS, MIPI etc.) can
take. 30 FPS on 2160p is common because the i.MX8MP can't display 2160p60.
Also, found an issue. Perhaps unrelated? Powered the board without HDMI
connected. Then connected 1080p60 display. It came in 1024x768, console
64x24 :-)
Run weston. Pressed ctrl-alt-backspace. It deadlocked. Sysrq (serial
console, show blocked state) showed (with *lcdif* in it):
task:systemd-logind state:D stack:0 pid:253 tgid:253 ppid:1 task_flags:0x400100 flags:0x00000800
Call trace:
...
schedule+0x34/0x118
rpm_resume+0x188/0x678
__pm_runtime_resume+0x4c/0x98
clk_pm_runtime_get.part.0.isra.0+0x1c/0x94
clk_core_set_rate_nolock+0xd0/0x2fc
clk_set_rate+0x38/0x158
lcdif_crtc_atomic_enable+0x74/0x8d0
drm_atomic_helper_commit_crtc_enable+0xac/0x104
drm_atomic_helper_commit_tail_rpm+0x68/0xd8
commit_tail+0xa4/0x1a4
drm_atomic_helper_commit+0x178/0x1a0
drm_atomic_commit+0x8c/0xcc
drm_client_modeset_commit_atomic+0x1f8/0x25c
drm_client_modeset_commit_locked+0x60/0x17c
__drm_fb_helper_restore_fbdev_mode_unlocked.part.0+0x2c/0x8c
drm_fb_helper_set_par+0x5c/0x78
fb_set_var+0x190/0x35c
fbcon_blank+0x178/0x24c
do_unblank_screen+0xa8/0x19c
vt_ioctl+0x4fc/0x14c0
tty_ioctl+0x228/0xb88
__arm64_sys_ioctl+0x90/0xe4
...
This is reproducible, though not always.
It seems it locks on some mutex - the shell works until I do 'cat
log.txt' or similar. Now (with std output/error redirection?), weston
doesn't even start.
dmesg doesn't show anything of interest.
weston: 14.0.2
using /dev/dri/card1
DRM: supports atomic modesetting
DRM: supports GBM modifiers
DRM: does not support Atomic async page flip
DRM: supports picture aspect ratio
Loading module '/usr/lib64/libweston-14/gl-renderer.so'
Using rendering device: /dev/dri/renderD128
EGL version: 1.5
EGL vendor: Mesa Project
EGL client APIs: OpenGL OpenGL_ES
...
Registered plugin API 'weston_drm_output_api_v1' of size 40
Registered plugin API 'weston_drm_virtual_output_api_v2' of size 48
Color manager: no-op
protocol support: no
Output 'HDMI-A-1' attempts EOTF mode SDR and colorimetry mode default.
Output 'HDMI-A-1' using color profile: stock sRGB color profile
Chosen EGL config details: id: 17 rgba: 8 8 8 0 buf: 24 dep: 0 stcl: 0 int: 1-1 type: win vis_id: XRGB8
)
Output HDMI-A-1 (crtc 37) video modes:
1920x1080@60.0, preferred, current, 148.5 MHz
Output 'HDMI-A-1' enabled with head(s) HDMI-A-1
Loading module '/usr/lib64/weston/desktop-shell.so'
launching '/usr/libexec/weston-keyboard'
launching '/usr/libexec/weston-desktop-shell'
Warning: computed repaint delay for output [HDMI-A-1] is abnormal: -69164 msec (happens always)
could not load cursor 'dnd-copy'
could not load cursor 'dnd-copy'
could not load cursor 'dnd-none'
could not load cursor 'dnd-none'
Why all these clk* mutexes? Perhaps something didn't work out as it
should there? clk_set_rate isn't supposed to take much time, is it?
$ grep clk /tmp/minicom.cap -C1
[ 728.310054] __pm_runtime_resume+0x4c/0x98
[ 728.310059] clk_pm_runtime_get.part.0.isra.0+0x1c/0x94
[ 728.310065] clk_core_set_rate_nolock+0xd0/0x2fc
[ 728.310071] clk_set_rate+0x38/0x158
[ 728.310076] lcdif_crtc_atomic_enable+0x74/0x8d0
--
[ 728.310210] mutex_lock+0x48/0x58
[ 728.310216] clk_prepare_lock+0x80/0xc0
[ 728.310223] clk_unprepare+0x28/0x44
[ 728.310227] fsl_samsung_hdmi_phy_suspend+0x24/0x40
--
[ 728.310344] mutex_lock+0x48/0x58
[ 728.310350] clk_prepare_lock+0x80/0xc0
[ 728.310359] clk_unprepare+0x28/0x44
[ 728.310364] etnaviv_gpu_clk_disable.isra.0+0x28/0x80
[ 728.310372] etnaviv_gpu_rpm_suspend+0x78/0x1dc
--
[ 728.310494] mutex_lock+0x48/0x58
[ 728.310499] clk_prepare_lock+0x80/0xc0
[ 728.310506] clk_unprepare+0x28/0x44
[ 728.310512] sdhci_esdhc_runtime_suspend+0x7c/0x198
--
[ 728.310627] mutex_lock+0x48/0x58
[ 728.310632] clk_prepare_lock+0x80/0xc0
[ 728.310639] clk_round_rate+0x38/0x1d8
[ 728.310646] dev_pm_opp_set_rate+0xe4/0x2e0
--
[ 728.310760] mutex_lock+0x48/0x58
[ 728.310765] clk_prepare_lock+0x80/0xc0
[ 728.310771] clk_prepare+0x1c/0x50
[ 728.310778] sdhci_esdhc_runtime_resume+0x34/0x180
--
[ 728.311286] mutex_lock+0x48/0x58
[ 728.311292] clk_prepare_lock+0x80/0xc0
[ 728.311298] clk_prepare+0x1c/0x50
[ 728.311303] sdhci_esdhc_runtime_resume+0x34/0x180
Something fishy here.
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
^ permalink raw reply
* Re: [PATCH v4] coresight: tpdm: add traceid_show for checking traceid
From: James Clark @ 2026-03-31 10:10 UTC (permalink / raw)
To: Jie Gan, Suzuki K Poulose
Cc: coresight, linux-arm-kernel, linux-kernel, Mao Jinlong,
Mike Leach, Leo Yan, Alexander Shishkin, Tingwei Zhang
In-Reply-To: <20260331-add-traceid-show-for-tpdm-v4-1-ed3dda24a562@oss.qualcomm.com>
On 31/03/2026 11:05 am, Jie Gan wrote:
> Save the trace ID in drvdata during TPDM enablement and expose it
> to userspace to support trace data parsing.
>
> The TPDM device’s trace ID corresponds to the trace ID allocated
> to the connected TPDA device.
>
> Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
> ---
> Changes in v4:
> 1. Return -EINVAL if the traceid is 0.
> - Link to v3: https://lore.kernel.org/r/20260325-add-traceid-show-for-tpdm-v3-1-0eb836d4ec30@oss.qualcomm.com
>
> Changes in v3:
> 1. Only allow user to read the traceid while the TPDM device is enabled.
> - Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-for-tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
>
> Changes in V2:
> 1. Use sysfs_emit instead of sprintf.
> Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
> ---
> .../ABI/testing/sysfs-bus-coresight-devices-tpdm | 10 +++++++
> drivers/hwtracing/coresight/coresight-tpdm.c | 34 +++++++++++++++++++++-
> drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
> 3 files changed, 45 insertions(+), 1 deletion(-)
>
Reviewed-by: James Clark <james.clark@linaro.org>
> diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> index f8016df64532..bc36ba32c900 100644
> --- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> +++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
> @@ -278,3 +278,13 @@ Date: Aug 2025
> KernelVersion 6.18
> Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
> Description: (Read) Show hardware context information of device.
> +
> +What: /sys/bus/coresight/devices/<tpdm-name>/traceid
> +Date: March 2026
> +KernelVersion: 7.1
> +Contact: Jie Gan <jie.gan@oss.qualcomm.com>
> +Description:
> + (R) Show the trace ID that will appear in the trace stream
> + coming from this TPDM. The trace ID is inherited from the
> + connected TPDA device and is fixed for the lifetime of the
> + device. Returns -EINVAL if the device has not been enabled yet.
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
> index da77bdaad0a4..9b16f368a58b 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.c
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.c
> @@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata *drvdata)
>
> static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
> enum cs_mode mode,
> - __maybe_unused struct coresight_path *path)
> + struct coresight_path *path)
> {
> struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>
> @@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
> }
>
> __tpdm_enable(drvdata);
> + drvdata->traceid = path->trace_id;
> drvdata->enable = true;
> spin_unlock(&drvdata->spinlock);
>
> @@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
> .attrs = tpdm_attrs,
> };
>
> +static ssize_t traceid_show(struct device *dev,
> + struct device_attribute *attr, char *buf)
> +{
> + unsigned long val;
> + struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
> +
> + val = drvdata->traceid;
> + if (!val)
> + return -EINVAL;
> +
> + return sysfs_emit(buf, "%#lx\n", val);
> +}
> +static DEVICE_ATTR_RO(traceid);
> +
> +static struct attribute *traceid_attrs[] = {
> + &dev_attr_traceid.attr,
> + NULL,
> +};
> +
> +static struct attribute_group traceid_attr_grp = {
> + .attrs = traceid_attrs,
> +};
> +
> static ssize_t dsb_mode_show(struct device *dev,
> struct device_attribute *attr,
> char *buf)
> @@ -1367,6 +1391,12 @@ static const struct attribute_group *tpdm_attr_grps[] = {
> &tpdm_cmb_patt_grp,
> &tpdm_cmb_msr_grp,
> &tpdm_mcmb_attr_grp,
> + &traceid_attr_grp,
> + NULL,
> +};
> +
> +static const struct attribute_group *static_tpdm_attr_grps[] = {
> + &traceid_attr_grp,
> NULL,
> };
>
> @@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev, struct resource *res)
> desc.access = CSDEV_ACCESS_IOMEM(base);
> if (res)
> desc.groups = tpdm_attr_grps;
> + else
> + desc.groups = static_tpdm_attr_grps;
> drvdata->csdev = coresight_register(&desc);
> if (IS_ERR(drvdata->csdev))
> return PTR_ERR(drvdata->csdev);
> diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/hwtracing/coresight/coresight-tpdm.h
> index 2867f3ab8186..11da64e1ade8 100644
> --- a/drivers/hwtracing/coresight/coresight-tpdm.h
> +++ b/drivers/hwtracing/coresight/coresight-tpdm.h
> @@ -300,6 +300,7 @@ struct cmb_dataset {
> * @cmb Specifics associated to TPDM CMB.
> * @dsb_msr_num Number of MSR supported by DSB TPDM
> * @cmb_msr_num Number of MSR supported by CMB TPDM
> + * @traceid Trace ID of the path.
> */
>
> struct tpdm_drvdata {
> @@ -313,6 +314,7 @@ struct tpdm_drvdata {
> struct cmb_dataset *cmb;
> u32 dsb_msr_num;
> u32 cmb_msr_num;
> + u8 traceid;
> };
>
> /* Enumerate members of various datasets */
>
> ---
> base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
> change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
>
> Best regards,
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Konrad Dybcio @ 2026-03-31 10:10 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Maxime Coquelin, Alexandre Torgue, linux-arm-msm,
linux-clk, linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <6ca492d7-c041-42b0-8f41-cd29ab7b4bab@oss.qualcomm.com>
On 3/31/26 12:09 PM, Krzysztof Kozlowski wrote:
> On 31/03/2026 11:33, Konrad Dybcio wrote:
>> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>>> and is not modified: neither by the driver defining it nor by common.c
>>> code using it.
>>>
>>> Make it const for code safety and code readability.
>>>
>>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> --- a/drivers/clk/qcom/common.h
>>> +++ b/drivers/clk/qcom/common.h
>>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>>> size_t num_icc_hws;
>>> unsigned int icc_first_node_id;
>>> bool use_rpm;
>>> - struct qcom_cc_driver_data *driver_data;
>>> + const struct qcom_cc_driver_data *driver_data;
>>
>> This can be a const ptr to const data, even
>
> None of other elements in 'qcom_cc_desc' is const pointer, even though
> they also could. If doing this change, let's make it consistent - so
> shall all of them be const?
I thought about it, but then it turns out that videocc-sm8550.c has:
video_cc_sm8550_driver_data.clk_cbcrs = video_cc_sm8650_critical_cbcrs
So we'd have to duplicate the entire struct
Konrad
^ permalink raw reply
* Re: [PATCH 1/2] clk: qcom: Constify qcom_cc_driver_data
From: Krzysztof Kozlowski @ 2026-03-31 10:09 UTC (permalink / raw)
To: Konrad Dybcio, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Maxime Coquelin, Alexandre Torgue, linux-arm-msm, linux-clk,
linux-kernel, linux-stm32, linux-arm-kernel
In-Reply-To: <a746be68-4f5d-4792-a896-bb693d029ea4@oss.qualcomm.com>
On 31/03/2026 11:33, Konrad Dybcio wrote:
> On 3/31/26 11:17 AM, Krzysztof Kozlowski wrote:
>> The static 'struct qcom_cc_driver_data' contains probe match-like data
>> and is not modified: neither by the driver defining it nor by common.c
>> code using it.
>>
>> Make it const for code safety and code readability.
>>
>> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>> ---
>
> [...]
>
>> --- a/drivers/clk/qcom/common.h
>> +++ b/drivers/clk/qcom/common.h
>> @@ -49,7 +49,7 @@ struct qcom_cc_desc {
>> size_t num_icc_hws;
>> unsigned int icc_first_node_id;
>> bool use_rpm;
>> - struct qcom_cc_driver_data *driver_data;
>> + const struct qcom_cc_driver_data *driver_data;
>
> This can be a const ptr to const data, even
None of other elements in 'qcom_cc_desc' is const pointer, even though
they also could. If doing this change, let's make it consistent - so
shall all of them be const?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] mailbox: Fix NULL message support in mbox_send_message()
From: Joonwon Kang @ 2026-03-31 10:08 UTC (permalink / raw)
To: jassisinghbrar
Cc: andersson, dianders, joonwonkang, linux-arm-kernel, linux-kernel,
maz, shawn.guo, tglx
In-Reply-To: <20260327220040.53326-1-jassisinghbrar@gmail.com>
> The active_req field serves double duty as both the "is a TX in
> flight" flag (NULL means idle) and the storage for the in-flight
> message pointer. When a client sends NULL via mbox_send_message(),
> active_req is set to NULL, which the framework misinterprets as
> "no active request". This breaks the TX state machine by:
>
> - tx_tick() short-circuits on (!mssg), skipping the tx_done
> callback and the tx_complete completion
> - txdone_hrtimer() skips the channel entirely since active_req
> is NULL, so poll-based TX-done detection never fires.
>
> Fix this by introducing a MBOX_NO_MSG sentinel value that means
> "no active request," freeing NULL to be valid message data. The
> sentinel is defined in the subsystem-internal mailbox.h so that
> controller drivers within drivers/mailbox/ can reference it, but
> it is not exposed to clients outside the subsystem.
>
> Fifteen in-tree callers send NULL (doorbell-style IPCs on Qualcomm,
> Tegra, TI, Xilinx, i.MX, SCMI, and PCC platforms). All were
> audited for regression:
>
> - Most already work around the bug via knows_txdone=true with a
> manual mbox_client_txdone() call, making the framework's
> tracking irrelevant. These are unaffected.
>
> - Poll-based callers (Xilinx zynqmp/r5) are strictly better off:
> the poll timer now correctly detects NULL-active channels
> instead of silently skipping them.
>
> - irq-qcom-mpm.c was a pre-existing bug -- the only Qualcomm
> caller that omitted the knows_txdone + mbox_client_txdone()
> pattern. Fixed in a companion commit ("irqchip/qcom-mpm: Fix
> missing mailbox TX done acknowledgment").
>
> - No caller sets both a tx_done callback and sends NULL, nor
> combines tx_block=true with NULL sends, so the newly reachable
> callback/completion paths are never exercised.
>
> Also update tegra-hsp's flush callback, which directly inspects
> active_req to wait for the channel to drain: the old "!= NULL"
> check becomes "!= MBOX_NO_MSG", otherwise flush spins until
> timeout since the sentinel is non-NULL.
>
> The only tradeoff is that 'MBOX_NO_MSG' can not be used as a message
> by clients.
>
> Reported-by: Joonwon Kang <joonwonkang@google.com>
> Reviewed-by: Douglas Anderson <dianders@chromium.org>
> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
Do you have plans to backport this patch to other stable versions?
If not, I can send the backport for you to the stable versions that are in my needs.
Thanks,
Joonwon Kang
^ permalink raw reply
* [PATCH v4] coresight: tpdm: add traceid_show for checking traceid
From: Jie Gan @ 2026-03-31 10:05 UTC (permalink / raw)
To: Suzuki K Poulose, Mike Leach, James Clark, Leo Yan,
Alexander Shishkin, Tingwei Zhang
Cc: coresight, linux-arm-kernel, linux-kernel, Jie Gan, Mao Jinlong
Save the trace ID in drvdata during TPDM enablement and expose it
to userspace to support trace data parsing.
The TPDM device’s trace ID corresponds to the trace ID allocated
to the connected TPDA device.
Signed-off-by: Jie Gan <jie.gan@oss.qualcomm.com>
---
Changes in v4:
1. Return -EINVAL if the traceid is 0.
- Link to v3: https://lore.kernel.org/r/20260325-add-traceid-show-for-tpdm-v3-1-0eb836d4ec30@oss.qualcomm.com
Changes in v3:
1. Only allow user to read the traceid while the TPDM device is enabled.
- Link to v2: https://lore.kernel.org/r/20260316-add-traceid-show-for-tpdm-v2-1-1dec2a67e4ed@oss.qualcomm.com
Changes in V2:
1. Use sysfs_emit instead of sprintf.
Link to V1 - https://lore.kernel.org/all/20260306-add-traceid-show-for-tpdm-v1-1-0658a8edb972@oss.qualcomm.com/
---
.../ABI/testing/sysfs-bus-coresight-devices-tpdm | 10 +++++++
drivers/hwtracing/coresight/coresight-tpdm.c | 34 +++++++++++++++++++++-
drivers/hwtracing/coresight/coresight-tpdm.h | 2 ++
3 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
index f8016df64532..bc36ba32c900 100644
--- a/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
+++ b/Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
@@ -278,3 +278,13 @@ Date: Aug 2025
KernelVersion 6.18
Contact: Mao Jinlong <quic_jinlmao@quicinc.com>
Description: (Read) Show hardware context information of device.
+
+What: /sys/bus/coresight/devices/<tpdm-name>/traceid
+Date: March 2026
+KernelVersion: 7.1
+Contact: Jie Gan <jie.gan@oss.qualcomm.com>
+Description:
+ (R) Show the trace ID that will appear in the trace stream
+ coming from this TPDM. The trace ID is inherited from the
+ connected TPDA device and is fixed for the lifetime of the
+ device. Returns -EINVAL if the device has not been enabled yet.
diff --git a/drivers/hwtracing/coresight/coresight-tpdm.c b/drivers/hwtracing/coresight/coresight-tpdm.c
index da77bdaad0a4..9b16f368a58b 100644
--- a/drivers/hwtracing/coresight/coresight-tpdm.c
+++ b/drivers/hwtracing/coresight/coresight-tpdm.c
@@ -481,7 +481,7 @@ static void __tpdm_enable(struct tpdm_drvdata *drvdata)
static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
enum cs_mode mode,
- __maybe_unused struct coresight_path *path)
+ struct coresight_path *path)
{
struct tpdm_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
@@ -497,6 +497,7 @@ static int tpdm_enable(struct coresight_device *csdev, struct perf_event *event,
}
__tpdm_enable(drvdata);
+ drvdata->traceid = path->trace_id;
drvdata->enable = true;
spin_unlock(&drvdata->spinlock);
@@ -693,6 +694,29 @@ static struct attribute_group tpdm_attr_grp = {
.attrs = tpdm_attrs,
};
+static ssize_t traceid_show(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ unsigned long val;
+ struct tpdm_drvdata *drvdata = dev_get_drvdata(dev->parent);
+
+ val = drvdata->traceid;
+ if (!val)
+ return -EINVAL;
+
+ return sysfs_emit(buf, "%#lx\n", val);
+}
+static DEVICE_ATTR_RO(traceid);
+
+static struct attribute *traceid_attrs[] = {
+ &dev_attr_traceid.attr,
+ NULL,
+};
+
+static struct attribute_group traceid_attr_grp = {
+ .attrs = traceid_attrs,
+};
+
static ssize_t dsb_mode_show(struct device *dev,
struct device_attribute *attr,
char *buf)
@@ -1367,6 +1391,12 @@ static const struct attribute_group *tpdm_attr_grps[] = {
&tpdm_cmb_patt_grp,
&tpdm_cmb_msr_grp,
&tpdm_mcmb_attr_grp,
+ &traceid_attr_grp,
+ NULL,
+};
+
+static const struct attribute_group *static_tpdm_attr_grps[] = {
+ &traceid_attr_grp,
NULL,
};
@@ -1425,6 +1455,8 @@ static int tpdm_probe(struct device *dev, struct resource *res)
desc.access = CSDEV_ACCESS_IOMEM(base);
if (res)
desc.groups = tpdm_attr_grps;
+ else
+ desc.groups = static_tpdm_attr_grps;
drvdata->csdev = coresight_register(&desc);
if (IS_ERR(drvdata->csdev))
return PTR_ERR(drvdata->csdev);
diff --git a/drivers/hwtracing/coresight/coresight-tpdm.h b/drivers/hwtracing/coresight/coresight-tpdm.h
index 2867f3ab8186..11da64e1ade8 100644
--- a/drivers/hwtracing/coresight/coresight-tpdm.h
+++ b/drivers/hwtracing/coresight/coresight-tpdm.h
@@ -300,6 +300,7 @@ struct cmb_dataset {
* @cmb Specifics associated to TPDM CMB.
* @dsb_msr_num Number of MSR supported by DSB TPDM
* @cmb_msr_num Number of MSR supported by CMB TPDM
+ * @traceid Trace ID of the path.
*/
struct tpdm_drvdata {
@@ -313,6 +314,7 @@ struct tpdm_drvdata {
struct cmb_dataset *cmb;
u32 dsb_msr_num;
u32 cmb_msr_num;
+ u8 traceid;
};
/* Enumerate members of various datasets */
---
base-commit: b84a0ebe421ca56995ff78b66307667b62b3a900
change-id: 20260316-add-traceid-show-for-tpdm-88d040651f00
Best regards,
--
Jie Gan <jie.gan@oss.qualcomm.com>
^ permalink raw reply related
* [PATCH 2/2] arm64: dts: imx952: Describe Mali G310 GPU
From: Guangliu Ding @ 2026-03-31 10:12 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding, Jiyu Yang
In-Reply-To: <20260331-master-v1-0-65c8e318d462@nxp.com>
Support Mali G310 GPU on i.MX952 board. Describe this GPU in the DT.
Include dummy GPU voltage regulator and OPP tables.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
---
arch/arm64/boot/dts/freescale/imx952.dtsi | 36 +++++++++++++++++++++++++++++++
1 file changed, 36 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx952.dtsi b/arch/arm64/boot/dts/freescale/imx952.dtsi
index 91fe4916ac04..0bd3e7fc0674 100644
--- a/arch/arm64/boot/dts/freescale/imx952.dtsi
+++ b/arch/arm64/boot/dts/freescale/imx952.dtsi
@@ -318,6 +318,28 @@ usbphynop2: usbphynop2 {
clock-names = "main_clk";
};
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ opp-hz-real = /bits/ 64 <500000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-800000000 {
+ opp-hz = /bits/ 64 <800000000>;
+ opp-hz-real = /bits/ 64 <800000000>;
+ opp-microvolt = <920000>;
+ };
+
+ opp-1000000000 {
+ opp-hz = /bits/ 64 <1000000000>;
+ opp-hz-real = /bits/ 64 <1000000000>;
+ opp-microvolt = <920000>;
+ };
+ };
+
soc {
compatible = "simple-bus";
#address-cells = <2>;
@@ -1262,5 +1284,19 @@ usbmisc2: usbmisc@4c200200 {
reg = <0x0 0x4c200200 0x0 0x200>,
<0x0 0x4c010014 0x0 0x4>;
};
+
+ gpu: gpu@4d900000 {
+ compatible = "nxp,imx952-mali", "arm,mali-valhall-csf";
+ reg = <0 0x4d900000 0 0x480000>;
+ interrupts = <GIC_SPI 288 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 289 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 290 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "gpu", "job", "mmu";
+ clocks = <&scmi_clk IMX952_CLK_GPU>;
+ clock-names = "core";
+ power-domains = <&scmi_devpd IMX952_PD_GPU>;
+ operating-points-v2 = <&gpu_opp_table>;
+ dynamic-power-coefficient = <1013>;
+ };
};
};
--
2.34.1
^ permalink raw reply related
* [PATCH 1/2] dt-bindings: gpu: mali-valhall-csf: Document i.MX952 support
From: Guangliu Ding @ 2026-03-31 10:12 UTC (permalink / raw)
To: Daniel Almeida, Alice Ryhl, Boris Brezillon, Steven Price,
Liviu Dudau, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam
Cc: dri-devel, devicetree, linux-kernel, imx, linux-arm-kernel,
Guangliu Ding, Jiyu Yang
In-Reply-To: <20260331-master-v1-0-65c8e318d462@nxp.com>
Add compatible string of Mali G310 GPU on i.MX952 board.
Signed-off-by: Guangliu Ding <guangliu.ding@nxp.com>
Reviewed-by: Jiyu Yang <jiyu.yang@nxp.com>
---
Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
index 8eccd4338a2b..6a10843a26e2 100644
--- a/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
+++ b/Documentation/devicetree/bindings/gpu/arm,mali-valhall-csf.yaml
@@ -20,6 +20,7 @@ properties:
- enum:
- mediatek,mt8196-mali
- nxp,imx95-mali # G310
+ - nxp,imx952-mali # G310
- rockchip,rk3588-mali
- const: arm,mali-valhall-csf # Mali Valhall GPU model/revision is fully discoverable
--
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