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

[Devarsh Thakkar <devarsht@ti.com>]

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?

> - 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.

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 ?

> 
> 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.

Regards
Devarsh