[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOuDEK0QomQfXqzmP6g8QRdbE5dXob2cuhM3viErUoDHURaB-Q@mail.gmail.com>
Date: Tue, 15 Oct 2024 00:19:00 +0800
From: Guan-Yu Lin <guanyulin@...gle.com>
To: Mathias Nyman <mathias.nyman@...ux.intel.com>
Cc: Thinh.Nguyen@...opsys.com, gregkh@...uxfoundation.org,
mathias.nyman@...el.com, stern@...land.harvard.edu, yajun.deng@...ux.dev,
sumit.garg@...aro.org, kekrby@...il.com, oneukum@...e.com,
dianders@...omium.org, perex@...ex.cz, tiwai@...e.com, niko.mauno@...sala.com,
andreyknvl@...il.com, christophe.jaillet@...adoo.fr, tj@...nel.org,
stanley_chang@...ltek.com, quic_jjohnson@...cinc.com, ricardo@...liere.net,
linux-usb@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-sound@...r.kernel.org, badhri@...gle.com, albertccwang@...gle.com,
quic_wcheng@...cinc.com, pumahsu@...gle.com
Subject: Re: [PATCH v5 5/5] usb: host: enable sideband transfer during system sleep
On Mon, Oct 14, 2024 at 9:06 PM Mathias Nyman
<mathias.nyman@...ux.intel.com> wrote:
>
> On 14.10.2024 11.50, Guan-Yu Lin wrote:
> > Sharing a USB controller with another entity via xhci-sideband driver
> > creates power management complexities. To prevent the USB controller
> > from being inadvertently deactivated while in use by the other entity, a
> > usage-count based mechanism is implemented. This allows the system to
> > manage power effectively, ensuring the controller remains available
> > whenever needed.
>
> I don't think all this is needed to prevent USB controller from being
> deactivated while sideband is in use. The modified audio class driver
> that uses sideband is still bound to a usb interface device, and all
> normal pm reference counting should work.
>
> To me it looks like this code is tricking pm framework into believing
> the usb device and host controller have successfully suspended during
> system suspend when they in reality are fully up and running.
>
> I'm not sure I fully understand the case this series is solving.
>
> Thanks
> Mathias
>
Your understanding is correct; this series aims to keep necessary
devices running while the system is suspended. The goal is to keep USB
transfer available via sideband when the main system is asleep. Since
we're offloading some USB transfers to another audio DSP, the Linux
driver is not involved in queueing transfer TRBs, handling event TRBs,
etc., in some specific "offloaded" USB endpoints. The sideband might
be bound to a USB interface device to prevent the device from going
into runtime suspend, but it seems this doesn't prevent devices from
suspending when the system goes into system-wide suspend. So the main
purpose of this series is to prevent some related devices being
suspended during system suspend.
Regards,
Guan-Yu
Powered by blists - more mailing lists