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

[Akash Kumar]

On 05-11-2026 21:11, Konrad Dybcio wrote:
> On 11/5/26 11:02 AM, 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
> Can we scale this depending of the real speed of the connected
> device adjusted for the real data throughput? i.e. if we walk
> the tree and min/max as appropriate, we end up with say 10G
> wire speed, out of which we can shave off some static overhead
>
> 4500 MB/s is 36 Gb/s which is way beyond what USB3 can do, in
> any configuration.
>
> Konrad
>
> Hi Konrad,
>
> Two things worth separating here:
>
> 1) The ICC vote is not a USB wire-speed requirement, so it
> shouldn't be compared directly against the USB3 line rate. This
> number is a DDR/memory-interconnect bandwidth vote; the platform's
> interconnect/OPP table is what maps a given vote to a DDR
> frequency/voltage corner. 4500 MB/s doesn't mean we expect 36 Gb/s
> on the wire - it means we want the memory subsystem's bus matrix to
> have enough headroom that the platform's table picks the higher
> in-corner DDR frequency instead of pinning it at the lower one. The
> vote intentionally carries margin for the aggregate memory traffic
> of the whole USB subsystem (descriptors, buffering, concurrent
> audio capture/playback, etc.), not just the raw bulk payload of one
> device, which is why it doesn't map 1:1 to link speed.
>
> 2) We do already have a speed-based split for this, just not a
> per-device dynamic one. dwc3_qcom_interconnect_init() picks between
> the HS and SS vote pairs based on usb_get_maximum_speed() of the
> controller:
>
>      max_speed = usb_get_maximum_speed(qcom->dwc.dev);
>      if (max_speed >= USB_SPEED_SUPER || max_speed == USB_SPEED_UNKNOWN)
>              ret = icc_set_bw(qcom->icc_path_ddr,
>                              USB_MEMORY_AVG_SS_BW, USB_MEMORY_PEAK_SS_BW);
>      else
>              ret = icc_set_bw(qcom->icc_path_ddr,
>                              USB_MEMORY_AVG_HS_BW, USB_MEMORY_PEAK_HS_BW);
>
> This patch only touches the SS tier's peak value; a controller
> whose maximum speed is HS is unaffected. It's set once at probe
> based on the controller's maximum capability rather than walking
> the topology for the actually-negotiated speed of whatever is
> plugged in at a given moment, so it's intentionally a worst-case
> value rather than a precise per-device figure - which is also why
> it's sized for the glitch we saw under concurrent audio+bulk load
> rather than for a single device's best-case throughput.
>
> Thanks,
> Akash