drm/i915/audio/ASoC/SOF: Add flag to skip device link creation for audio component#5458
Conversation
…nent When there is no direct dependency between audio and display there is no reason to add device link, which forces indirect PM dependency between the independent (in power and clock sense) subsystems. The audio stack takes care of powering up the display codec when needed, but during suspend and resume there is really no need to serialize the two devices. There are still cases when the dependency is valid, like on discrete gfx cards. The default behavior remains the same: device link is added, which can be revised if desired. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
The hdac_bus->audio_component is used as a pointer to a 'struct drm_audio_component' or to 'struct i915_audio_component' while it's type is 'struct drm_audio_component'. Convert it to void* to avoid this abuse. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
…ay audio i915_no_device_link can be set by audio stacks where there is no direct hardware dependency exist between display and HDA. The flag will be passed to acomp->no_device_link for the display stack to skip the creation of the display link if it is set. By default the link creation will remain to ensure that it is skipped only when it is possible by the architecture. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
In systems where SOF is used there is no direct dependency between HDA controller and the display stack, there is no need to create the device link. Without the device link it will be allowed to suspend and resume the display and audio hardware in parallel. Signed-off-by: Peter Ujfalusi <peter.ujfalusi@linux.intel.com>
ujfalusi
requested review from
bardliao,
dbaluta,
kv2019i,
lgirdwood,
plbossart and
ranj063
as code owners
|
Replaces: #5433 |
|
I've been doing some spot testing, and this seems to work for all cases I've tried. The get_power() via component framework is covering basicly all SOF needs. It would be good to understand why this is ok now and mention it in the commit message.. The original link was not added for discrete-gfx cases (Intel had none in 2018). If you look at Imre's commit, aef9f33 , it refers to ensuring system resume/suspend ordering. Looking at the 2018 code in i915, I can't directly say what is the problem prevented here (on display side). I believe the volume/dominant platforms at the time (Coffee and Sky Lake) had the audio controller on a separate PCI device (see HDA_CONTROLLER_IN_GPU() macro in hda_intel for exceptions), so the link was not added just for HDA_CONTROLLER_IN_GPU platforms. This would be seem some dependency on display side. For audio, if get_power() via component framework is guaranteed to work even if the system suspend/resume ordering can be different (or fully parallel), then this PR should be ok. If display side is ok ti proceed, I'm ok as well. |
lgirdwood
left a comment
lgirdwood
left a comment
There was a problem hiding this comment.
LGTM - I would add in a commit message showing the improvement to resume time.
4 participants
When there is no direct dependency between audio and display there is no
reason to add device link, which forces indirect PM dependency between
the independent (in power and clock sense) subsystems.
The audio stack takes care of powering up the display codec when needed,
but during suspend and resume there is really no need to serialize the two
devices.
There are still cases when the dependency is valid, like on discrete gfx
cards. The default behavior remains the same: device link is added, which
can be revised if desired.