Re: [PATCH v2 2/3] interconnect: qcom: x1e80100: enable QoS configuration

[Marc Zyngier]

On Mon, 07 Sep 2026 14:20:26 +0100,
Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxxxx> wrote:
> 
> On 9/7/26 10:49 AM, Marc Zyngier wrote:
> > On Mon, 07 Sep 2026 09:18:38 +0100,
> > Raviteja Laggyshetty <raviteja.laggyshetty@xxxxxxxxxxxxxxxx> wrote:
> >>
> >>
> >>
> >> On 9/7/2026 1:39 PM, Marc Zyngier wrote:
> >>> On Wed, 02 Sep 2026 14:00:52 +0100,
> >>> Mostafa Saleh <smostafa@xxxxxxxxxx> wrote:
> >>>>
> >>>> On Wed, May 27, 2026 at 05:37:10AM +0000, Raviteja Laggyshetty wrote:
> >>>>> Enable QoS configuration for master ports with predefined priority
> >>>>> and urgency forwarding.
> 
> [...]
> 
> >>> I'm also seeing spurious resets on my "X1E001DE Snapdragon Devkit for
> >>> Windows" when doing large file transfers over the network (30GB+).
> >>> With this patch reverted on top of 7.3-rc1, both machines are as solid
> >>> as they were before it.
> >>>
> >> The current patch enable QoS for Hamoa SoC, which get programmed only during
> >> driver probe. This shouldn't impact or cause any spurious resets once the 
> >> device is booted up and probe is successful.
> > 
> > And yet it absolutely does break things.
> > 
> > With this patch applied, the box resets within 5GB of heavy network
> > traffic, probably because some transaction get delayed, and a watchdog
> > fires. With the patch reverted, the box keeps receiving packets, and
> > everything is hunky dory (100GB+ so far).
> > 
> > Which makes me think that the set of hardcoded parameters in this
> > patch is not universal at all.
> 
> They are, provided the configuration is for the right SoC..

Is x1e001de different from x1e80100? AFAIK, it is only a binned
version of the same SoC. How do you explain the above regression?

> Turns out Purwa has a slightly different topology and that went
> unnoticed as the platform was brought up upstream.
> 
> I'll send a fix.

That'd be good.

	M.

-- 
Without deviation from the norm, progress is not possible.