| Message ID | 20250117145145.3093352-1-guanyulin@google.com |
|---|---|
| Headers | show |
| Series | Support system sleep with offloaded usb transfers | expand |
>>> 2. Power Management Adjustment: Modifications to the USB driver stack >>> (dwc3 controller driver, xhci host controller driver, and USB device >>> drivers) allow the system to sleep without disrupting co-processor managed >>> USB transfers. This involves adding conditional checks to bypass some >>> power management operations. >> >> This is even more confusing, initially the point was to prevent the controller from sleeping while there are offloaded transactions, but now the goal would be to allow the system to sleep while there are offloaded transactions. This isn't the same problem, is it? >> > > The purpose of this series is to allow offloaded usb transfers happen > during system sleep. In order to achieve this, we need to prevent the > controller from sleeping when there's offloaded usb transfer ongoing, > specifically when the system is sleeping. > Without this series, the system could still allow offloaded usb > traffic when the system is active, but the system would put the > controller to sleep when the system is going to sleep, thus we're not > able to suspend the system when we have offloaded usb transfers in the > current system. I am not following, sorry. Is the desired outcome to a) prevent the system from entering S3 if there is an active USB audio offloaded stream? or b) allow offloaded transactions even when the system is in S3? which is it? a) would be rather interesting, but currently we don't have any such behavior supported. When the system enters S3 all audio stops. The stream will resume when the system goes back to S0. Do we really want the battery to drain in S3? b) seems rather complicated, once the on-going DMA transfers complete then who's going to refill buffers for the USB offloaded streams? Allowing the lowest level to operate even in S3 is only a small part of the puzzle, someone's got to provide data at some point. Unless the data is generated also by a side DSP having access to mass storage or wireless interfaces?
On Tue, Jan 28, 2025 at 11:22 PM Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> wrote: > > I am not following, sorry. > > Is the desired outcome to > > a) prevent the system from entering S3 if there is an active USB audio offloaded stream? > > or b) allow offloaded transactions even when the system is in S3? > > > which is it? > > a) would be rather interesting, but currently we don't have any such behavior supported. When the system enters S3 all audio stops. The stream will resume when the system goes back to S0. Do we really want the battery to drain in S3? > > b) seems rather complicated, once the on-going DMA transfers complete then who's going to refill buffers for the USB offloaded streams? Allowing the lowest level to operate even in S3 is only a small part of the puzzle, someone's got to provide data at some point. Unless the data is generated also by a side DSP having access to mass storage or wireless interfaces? Thanks for the question, the intent of our proposal should be (b), to allow offloaded transactions even when the system is in S3. In our design, the DSP wakes the system before the buffers are fully drained. This patchset enables the USB controller for offloaded transfers during system suspend (S3). To be precise, this patchset focuses solely on enabling the USB controller in S3 and does not include other necessary components for continuous offloaded USB transfers. I'll revise the commit message/cover letter to reflect this.Thanks for highlighting the potential ambiguity. Regards, Guan-Yu
On 2/2/25 20:57, Guan-Yu Lin wrote: > On Tue, Jan 28, 2025 at 11:22 PM Pierre-Louis Bossart > <pierre-louis.bossart@linux.dev> wrote: >> >> I am not following, sorry. >> >> Is the desired outcome to >> >> a) prevent the system from entering S3 if there is an active USB audio offloaded stream? >> >> or b) allow offloaded transactions even when the system is in S3? >> >> >> which is it? >> >> a) would be rather interesting, but currently we don't have any such behavior supported. When the system enters S3 all audio stops. The stream will resume when the system goes back to S0. Do we really want the battery to drain in S3? >> >> b) seems rather complicated, once the on-going DMA transfers complete then who's going to refill buffers for the USB offloaded streams? Allowing the lowest level to operate even in S3 is only a small part of the puzzle, someone's got to provide data at some point. Unless the data is generated also by a side DSP having access to mass storage or wireless interfaces? > > Thanks for the question, the intent of our proposal should be (b), to > allow offloaded transactions even when the system is in S3. > In our design, the DSP wakes the system before the buffers are fully > drained. This patchset enables the USB controller for offloaded > transfers during system suspend (S3). To be precise, this patchset > focuses solely on enabling the USB controller in S3 and does not > include other necessary components for continuous offloaded USB > transfers. I'll revise the commit message/cover letter to reflect > this.Thanks for highlighting the potential ambiguity. Thanks for the precision. It was my understanding that anything above S1 could incur a hardware/software latency of two seconds or more to go back to S0. That would imply a buffering scheme that's significantly larger than usual offloaded solutions. In "typical" offload implementations it's rare to go beyond 100s of ms, since at some point you run into user-experience issues when applying volume changes or when changing tracks. It's usually a no-go if the user has to wait for a perceivable amount of time while the buffers drain. Not to mention that quite a few platforms no longer support S3, since 'Modern Standby' aka "S0 Low Power Idle" or 's2idle' was introduced in the Windows 10 days S3 became largely a legacy feature gradually dropped since no one really uses it.
On 2/7/25 04:54, Guan-Yu Lin wrote: > On Tue, Feb 4, 2025 at 7:57 AM Pierre-Louis Bossart > <pierre-louis.bossart@linux.dev> wrote: >> >> On 2/2/25 20:57, Guan-Yu Lin wrote: >>> On Tue, Jan 28, 2025 at 11:22 PM Pierre-Louis Bossart >>> <pierre-louis.bossart@linux.dev> wrote: >>>> >>>> I am not following, sorry. >>>> >>>> Is the desired outcome to >>>> >>>> a) prevent the system from entering S3 if there is an active USB audio offloaded stream? >>>> >>>> or b) allow offloaded transactions even when the system is in S3? >>>> >>>> >>>> which is it? >>>> >>>> a) would be rather interesting, but currently we don't have any such behavior supported. When the system enters S3 all audio stops. The stream will resume when the system goes back to S0. Do we really want the battery to drain in S3? >>>> >>>> b) seems rather complicated, once the on-going DMA transfers complete then who's going to refill buffers for the USB offloaded streams? Allowing the lowest level to operate even in S3 is only a small part of the puzzle, someone's got to provide data at some point. Unless the data is generated also by a side DSP having access to mass storage or wireless interfaces? >>> >>> Thanks for the question, the intent of our proposal should be (b), to >>> allow offloaded transactions even when the system is in S3. >>> In our design, the DSP wakes the system before the buffers are fully >>> drained. This patchset enables the USB controller for offloaded >>> transfers during system suspend (S3). To be precise, this patchset >>> focuses solely on enabling the USB controller in S3 and does not >>> include other necessary components for continuous offloaded USB >>> transfers. I'll revise the commit message/cover letter to reflect >>> this.Thanks for highlighting the potential ambiguity. >> >> Thanks for the precision. >> >> It was my understanding that anything above S1 could incur a hardware/software latency of two seconds or more to go back to S0. That would imply a buffering scheme that's significantly larger than usual offloaded solutions. In "typical" offload implementations it's rare to go beyond 100s of ms, since at some point you run into user-experience issues when applying volume changes or when changing tracks. It's usually a no-go if the user has to wait for a perceivable amount of time while the buffers drain. >> >> Not to mention that quite a few platforms no longer support S3, since 'Modern Standby' aka "S0 Low Power Idle" or 's2idle' was introduced in the Windows 10 days S3 became largely a legacy feature gradually dropped since no one really uses it. > > I think for mobile devices, the S3 state is still used since the > hardware/software latency wouldn't be as big as you described, so > mobile devices could still use S3 for power saving. How about using a > "knob" to isolate the feature to specific devices? "Knob" could be > dynamically switched by some functions, or we could statically > determine it as a dts attribute or build config. Will a "knob" address > your concern for this feature? Do you have a preference on the "knob" > design? My recollection of mobile devices is that they only relied on S0 platform substates, e.g. S0i1, S0i2, so that the device was always 'active' from a pm_runtime perspective. I have never seen a case where the device was 'active' in S3, I don't think this can work with the current system/pm_runtime power management, can it? In other words, audio streaming was supported in S0/D0, S0ix/D0ix but S3/D0ix was not a supported configuration. That said, if you managed to make this work, at the very least this should be a device-specific property, not an unconditional blanket enablement of a capability that raises quite a few questions.