Re: [PATCH v2] usb: dwc3: Update nominal max votes for qcom usb

[Peter Chen]

On 26-11-10 18:11:31, Akash Kumar wrote:
> 
> On 09-11-2026 14:30, Peter Chen wrote:
> > On 26-11-05 15:32:16, Akash Kumar wrote:
> > > Increase the nominal max USB memory bandwidth vote to let DDR scale
> > > higher within its nominal corner, fixing glitches seen during
> > > simultaneous USB audio use cases.
> > > 
> > > USB_MEMORY_PEAK_SS_BW is raised from 2500 MB/s to 4500 MB/s (+2000
> > > MB/s, ~1.8x). This ICC vote does not by itself determine DDR
> > > frequency; the vote-to-frequency mapping is platform-specific and
> > > comes from each target's interconnect/OPP table. On the tested
> > > targets, the old vote kept DDR pinned at 1 GHz within the nominal
> > > corner, even though DDR can run at 1.5 GHz (+50%) within the same
> > > corner. At 1 GHz, glitches were observed during multiple concurrent
> > > USB audio use cases.
> > How we decide which value is suitable, eg, you set 4500 here?
> > If DDR can run higher, and we have more stress test case like UAS
> > transfer + UVC transfer, do we need this value to be higher?
> > 
> > Is it okay we just set the highest value for USB, there is a platform
> > OPP table, and we let ICC choose the highest value for USB at specific
> > platform?
> > 
> > Peter
> > 
> Hi Peter,
> 
> 4500 MB/s was arrived at empirically, not computed: we swept the peak SS
> vote on each tested target and read back the committed DDR frequency.
> 2500 MB/s capped every target at 1 GHz; 4500 MB/s is the smallest common
> vote that reliably crosses into the 1.5 GHz nominal step on all of
> them without pushing any target into the next corner above nominal.
> 1.5 GHz is also the DDR frequency our power team's KPI bandwidth table
> accepts as nominal, so this vote keeps us inside the power budget they've
> signed off on, not just inside a technically-valid corner.
> 
> We've additionally run isochronous endpoint use cases with this change —
> mobile platform passes the full MJPEG test suite at this vote with no regressions.
> We've also verified UAC+UVC concurrently: for that combination,
> DDR is bumped at runtime on demand by the userspace application
> rather than relying on this static floor vote alone.
> 
> That's also why we didn't just vote the platform max and let ICC pick:
> not every USB use case needs or should force DDR to its ceiling.
> If we voted max unconditionally for all USB activity, DDR would sit
> pinned at the highest corner any time a SS device is attached, which shows up
> directly as a regression on the power dashboard across every platform using
> this shared driver. The static vote here is sized for the common case;
> use cases that genuinely need more (like UAC+UVC) bump DDR explicitly at
> runtime instead of paying that cost unconditionally.
> 
> In Future, we have a plan to make  it configurable from device tree which can
> be done based on target.
> 

Akash, thanks for detail explanation. I had not considered power consumption affect.
So, we set a default value for balance performance and power at most platforms,
in future, we could configure it through device tree or use space according to
scenario.

-- 

Thanks,
Peter Chen