On 21/02/23 21:43, Pierre-Louis Bossart wrote:
>
> On 2/20/23 05:04, Vijendar Mukunda wrote:
>> Add wake enable interrupt support for both the SoundWire manager
>> instances.
>>
>> Signed-off-by: Vijendar Mukunda <Vijendar.Mukunda@xxxxxxx>
>> Signed-off-by: Mastan Katragadda <Mastan.Katragadda@xxxxxxx>
>> ---
>> drivers/soundwire/amd_manager.c | 10 ++++++++++
>> drivers/soundwire/amd_manager.h | 1 +
>> 2 files changed, 11 insertions(+)
>>
>> diff --git a/drivers/soundwire/amd_manager.c b/drivers/soundwire/amd_manager.c
>> index 3322adeca0d8..a7182aa78652 100644
>> --- a/drivers/soundwire/amd_manager.c
>> +++ b/drivers/soundwire/amd_manager.c
>> @@ -932,6 +932,13 @@ static void amd_sdw_update_slave_status(u32 status_change_0to7, u32 status_chang
>> }
>> }
>>
>> +static void amd_sdw_process_wake_event(struct amd_sdw_manager *amd_manager)
>> +{
>> + pm_request_resume(amd_manager->dev);
> is this needed?
>
> In the Intel case, the wakes do not necessarily come as in-band wakes,
> but they can also be notified by the PCI subsystem, so we do have to use
> pm_request_resume.
>
> In the AMD case, what happens if you don't do this? Doesn't the
> interrupt trigger a pm_runtime_resume already?
ACP PCI driver receives soundwire interrupt and soundwire manager
interrupt work queue will be scheduled.
In this work queue, wake interrupt status bit is checked.
As still soundwire manager in D3 state, it required to invoke
pm_request_resume(). Without pm_request_resume() call, pm_runtime_resume
won't be triggered in this scenario.
>
>> + acp_reg_writel(0x00, amd_manager->acp_mmio + ACP_SW_WAKE_EN(amd_manager->instance));
>> + acp_reg_writel(0x00, amd_manager->mmio + ACP_SW_STATE_CHANGE_STATUS_8TO11);
>> +}
> \
