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

[Krishna Kurapati <krishna.kurapati@oss.qualcomm.com>]

On 11/8/2026 12:52 PM, Akash Kumar wrote:
> 
> 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);
>>

Hi Akash,

  Rather than relying on DT parameter to determine ICC bandwidth, we can 
do the following:

  a) In host mode, we can register notifier to usb core and based on 
device connection speed at runtime, we can modify the ICC bandwidth. If 
its High-Speed, we can scale back to SVS. This reference is present in 
downstream.

  b) For device mode, we can register a post-conndone glue hook to dwc3 
core and depending on connection speed (DSTS regsiter read), we can set 
appropriate ICC vote. This is not tried on downstream but I think it 
must work fine.

Regards,
Krishna,

>> 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
>