On Mon, Oct 22, 2018 at 07:22:30PM +0300, Ville Syrjälä wrote:
> On Thu, Oct 18, 2018 at 05:25:58PM +0300, Imre Deak wrote:
> > In order to ensure that our system suspend and resume callbacks are
> > called in the correct order wrt. those of the HDA driver add a device
> > link to the HDA driver
On Thu, Oct 18, 2018 at 05:25:58PM +0300, Imre Deak wrote:
> In order to ensure that our system suspend and resume callbacks are
> called in the correct order wrt. those of the HDA driver add a device
> link to the HDA driver during audio component binding time. With i915 as
> the supplier and HDA
On Sat, Oct 20, 2018 at 07:59:09AM +0200, Lukas Wunner wrote:
> On Thu, Oct 18, 2018 at 05:25:58PM +0300, Imre Deak wrote:
> > In order to ensure that our system suspend and resume callbacks are
> > called in the correct order wrt. those of the HDA driver add a device
> > link to the HDA driver
On Thu, Oct 18, 2018 at 05:25:58PM +0300, Imre Deak wrote:
> In order to ensure that our system suspend and resume callbacks are
> called in the correct order wrt. those of the HDA driver add a device
> link to the HDA driver during audio component binding time. With i915 as
> the supplier and HDA
On Thu, 18 Oct 2018 16:25:58 +0200,
Imre Deak wrote:
>
> In order to ensure that our system suspend and resume callbacks are
> called in the correct order wrt. those of the HDA driver add a device
> link to the HDA driver during audio component binding time. With i915 as
> the supplier and HDA as
In order to ensure that our system suspend and resume callbacks are
called in the correct order wrt. those of the HDA driver add a device
link to the HDA driver during audio component binding time. With i915 as
the supplier and HDA as the consumer the PM framework will guarantee
the HDA->i915
