Re: [PATCH] drm/bridge: sii902x: Add Power Management hooks with audio context

["Wang, Sen" <sen@ti.com>]

On 4/9/2026 10:11 AM, Devarsh Thakkar wrote:
> Hi Sen,
> 
> Thanks for looking into this.
> 
> On 04/04/26 23:11, Sen Wang wrote:
>> On 4/2/26 02:07, Thakkar, Devarsh wrote:
>>> Hi Sen,
>>>
>>> Thanks for the update.
>>>
>>> On 02/04/26 05:03, Sen Wang wrote:
>>>> On 4/1/26 09:42, Thakkar, Devarsh wrote:
>>>>> Hi Sen,
>>>>>
>>>>> On 01/04/26 07:07, Sen Wang wrote:
>>>>>
>>>>> Sorry but this is not very clear, is this a V2 to
>>>>> https://lore.kernel.org/all/e6497541-f3e7-4533-
>>>>> a188-9d422cb34d74@ti.com/ ?
>>>>>
>>>>> In that case, the subject should mention it as PATCH v2 along with
>>>>> changelog as documented in kernel patch guidelines :
>>>>> https://docs.kernel.org/process/submitting-patches.html
>>>>>
>>>> Hi Devarsh, Thanks for your review.
>>>>
>>>> This new patch encompasses more features than the previous patch to
>>>> warrant it being a separate patch. But nonetheless my apologies for
>>>> not stating the indirection in my commit message.
>>>>
>>>
>>> I don't think this qualifies to make it an independent patch altogether,
>>> as long as goal of the patch is same as the initial one posted, this
>>> should be labelled as a V2 with linkage to V1 in changelog. And the
>>> follow up patch should be labelled V3.
>>>
>>> The changelog should capture the changes under ---:
>>>
>>> V1->V2 : What changed
>>> V2->V3 : What changed
>>>
>>> along with links for V1 and V2.
>>>
>>> This gives the reviewer necessary context on architecture and reasoning
>>> behind new changes/approaches even if it means the new patch contains
>>> some extra feature which was not present in previous patch.
>>>
>>> Regards
>>> Devarsh
>>>
>>>
>> Understood Devarsh, thank you for the detailed explanation. Deeply 
>> appreciated.
>>
>> I also dug more into the datasheet with your comments in mind and 
>> wanted to gather some feedback on the proposal before sending a proper 
>> V3 patch.
>>
>> Here's my proposal, TL;DR:
>>
>> - Runtime suspend to use D2 (Sleep) for a quick bringup
>> - System suspend to use D3 Hot for a complete power-off/on scheme
>>
>> For the full summary:
>>
>> (per Datasheet's powerstate, Table 3.8)
>> D0     - Full power
>> D2     - Quiet Power Down (i2c accessible)
>> D3 Hot  - Complete Power Down (via HPD or RSEN wkup)
>> D3 Cold - Complete Power Down (HPD)
>>
>> Runtime suspend on sii902x should NOT use the same flow as System suspend
>>
>> - Runtime suspend to use D2 for a quick bringup
> 
> If D3 mode resume latency is faster and comparable to D2 and no obvious 
> tradeoffs then maybe we could use D3 for runtime resume too?
> 
D2 resume presumably will be a lot faster because it's a shallow sleep. 
Also for backwards compatibility, D3 requires a full context switch and 
I can't guarantee runtime resume would preserve all the states that user 
relies on. Currently we only restore the essential registers needed for 
video and audio context.

>> - System suspend to use D3 Hot for a complete power-off/on scheme
>>      + Hot vs Cold: even though Cold use marginally less power, it can 
>> only be entered and wkup via HPD event (Hotplug detect), which is not 
>> a software-controlled event.
>>
> 
> For system suspend, anyway the system resume will mostly be done with 
> system wakeup sources so I am not sure if we really need the extra 
> wakeup present in D3 Hot as compared to D3 cold, so probably would be 
> better to stick to D3 cold if no obvious tradeoffs.
> 
Well we can't use D3 cold in system suspend. D3 cold only triggers via 
HDMI wakeup, so it's a passive mechanism rather than the PM's active 
trigger.

That does bring up an alternative approach. Rather than using PM 
framework I'm more familiar with, we could rely on DRM atomic KMS. Since 
it handles hotplug detection and we're offloading impl to the core DRM 
helper APIs. This way no system resume/suspend is needed, but we still 
get the benefits of D2 runtime resume.

> Also could you please measure resume back latencies for each of the D2 
> and D3 modes and we can then maybe compare that with the power table to 
> get latency vs power tradeoff view and decide ?
> 
Compatibility is the biggest concern I have, rather be safe than sorry.
And I don't think it's worthwhile to focus so much on sporadic events 
that runtime PM handles, when the narrative is on the overarching power 
management.

>>
>> In such case, only system suspend needs to cache TPI and audio 
>> context, reset & initalise the hardware. Whereas runtime suspend 
>> should just be in a D2 state where all reg values are preserved. Thus 
>> providing faster response time for runtime resume, especially when we 
>> don't have autosuspend (yet), and avoids latency for spontaneous 
>> events in the DRM framework.
> 
> I think we probably should add auto-suspend support too w.r. runtime 
> suspend as don't want to go to suspend too frequently if the 
> initialization latency (along with power rampup sequences) is too high.
> 

Okay I can do that.

> Regards
> Devarsh
>