On Tue, Dec 17, 2024 at 01:50:00AM +0000, Xin Ji wrote: > > -----Original Message----- > > From: Pin-yen Lin <[email protected]> > > Sent: Monday, December 16, 2024 8:05 PM > > To: Dmitry Baryshkov <[email protected]> > > Cc: Xin Ji <[email protected]>; Andrzej Hajda <[email protected]>; > > Neil Armstrong <[email protected]>; Robert Foss <[email protected]>; > > Laurent Pinchart <[email protected]>; Jonas Karlman > > <[email protected]>; Jernej Skrabec <[email protected]>; Maarten > > Lankhorst <[email protected]>; Maxime Ripard > > <[email protected]>; Thomas Zimmermann <[email protected]>; David > > Airlie <[email protected]>; Simona Vetter <[email protected]>; Bernie Liang > > <[email protected]>; Qilin Wen <[email protected]>; > > [email protected]; [email protected]; linux- > > [email protected] > > Subject: Re: [PATCH v3] drm/bridge:anx7625: Update HDCP status at > > atomic_enable() > > > > > > Hi Dmitry, > > > > On Mon, Dec 16, 2024 at 7:59 PM Dmitry Baryshkov > > <[email protected]> wrote: > > > > > > On Mon, Dec 16, 2024 at 08:33:23AM +0000, Xin Ji wrote: > > > > > -----Original Message----- > > > > > From: Dmitry Baryshkov <[email protected]> > > > > > Sent: Friday, December 13, 2024 9:17 PM > > > > > To: Xin Ji <[email protected]> > > > > > Cc: Andrzej Hajda <[email protected]>; Neil Armstrong > > > > > <[email protected]>; Robert Foss <[email protected]>; > > > > > Laurent Pinchart <[email protected]>; Jonas > > > > > Karlman <[email protected]>; Jernej Skrabec > > > > > <[email protected]>; Maarten Lankhorst > > > > > <[email protected]>; Maxime Ripard > > > > > <[email protected]>; Thomas Zimmermann <[email protected]>; > > > > > David Airlie <[email protected]>; Simona Vetter <[email protected]>; > > > > > Bernie Liang <[email protected]>; Qilin Wen > > > > > <[email protected]>; [email protected]; > > > > > [email protected]; linux- [email protected] > > > > > Subject: Re: [PATCH v3] drm/bridge:anx7625: Update HDCP status at > > > > > atomic_enable() > > > > > > > > > > CAUTION: This email originated from outside of the organization. > > > > > Please do not click links or open attachments unless you recognize > > > > > the sender, and know the content is safe. > > > > > > > > > > > > > > > On Fri, 13 Dec 2024 at 13:00, Xin Ji <[email protected]> wrote: > > > > > > > > > > > > Hi Dmitry, sorry, I didn't clear describe the reason. > > > > > > > > > > Please. Do not top-post. Please paste your answer under the > > > > > question, not somewhere at the top of the email. This allows us to > > > > > have a more constructive dialog. Additional bonus if you can fix > > > > > your email client to insert sensible quoting information instead of > > > > > dumping > > the headers of the original email. > > > > Hi Dmitry, OK, sorry about it. Currently, we have problem to fetch > > > > email from Microsoft on Ubuntu. I'll try to fix it later. > > > > > > > > > > > > > > > > > Anx7625 implement DSI to DP convert behind USB Type-C port, when > > > > > > user plug into USB Type-C Dongle with DP monitor, the user space > > > > > > will enable HDCP feature, then kernel do HDCP and output display > > > > > > and set HDCP content to ENABLE, but the issue happened if user > > > > > > manually change the > > > > > monitor's resolution later. > > > > > > > > > > > > Each time user change the resolution, kernel will call bridge > > > > > > interface .atomic_disable() and .atomic_enable(), the old driver > > > > > > will keep HDCP state to ENABLE, this is a BUG, when user change > > > > > > the resolution, kernel must change HDCP content too (mustn't > > > > > > keep to ENABLE), > > > > > > > > > > Why? Could you please point me to the corresponding documentation > > > > > or a code path in the other driver? Preferably i915, AMD or Nouveau. > > > > As > > https://elixir.bootlin.com/linux/v6.12.5/source/drivers/gpu/drm/drm_connecto > > r.c#L1423: > > > > - ENABLED -> DESIRED (termination of authentication) As > > > > there is no other interface to tell anx7625 bridge driver, so the I > > > > think best place to handle ENABLE -> DESIRED in .atomic_disable(). > > > > > > I was looking for something like cdns_mhdp_connector_atomic_check(), > > > which switches to UNDESIRED if there is no new CRTC. Likewise i915 > > > driver performs this in intel_hdcp_atomic_check() if there is a need > > > for modeset. > Hi Dmitry, the bridge driver is different with i915, anx7625 bridge driver > only implement some passive callback interface. There is no HDCP status > checking while do resolution switch.
Does that mean that you _have_ to reestablish HDCP after mode switching in order for it to work? > > > > I believe you mean "DESIRED" here. > > > > > > For the "termination of authentication" case see > > > cdns_mhdp_hdcp_check_link(), which detects if the HDCP got disabled by > > > HW and then updates the status accordingly. > > > > > > > > > > > > > > > > > > as DRM doc said, kernel cannot change from ENABLE to UNDESIRE, > > > > > > so next patch, I'll change it to DESIRE in .atomic_disable(). > > > > > > This e.g. will result in HDCP being restarted for all modesets. Is > > > this an expected behaviour? > > > > The bridge could be powered off between .atomic_disable() > > and .atomic_enable(), though I'm not sure if this would be a concern for > > anx7625. I'll let Xin to comment on this. > The flow of resolution switch is: > -> .atomic_disable(). > -> .atomic_enable(). > -> HDCP status check and enable. > As resolution switch is triggered by user space, at this moment, the HDCP > works fine(cannot get disabled event from HW). > So, I think, .atomic_disable() is > the best place to do termination of authentication (turn HDCP status to > DESIRED). > This is the only entrance which can do termination of authentication, I cannot > find others. I'm probably still missing a reference to the standard (please excuse me, I don't know it by heart). Is it a standard requirement to reauthenticate on the mode switch? BTW, while reading the anx7625 code, I noticed that there is a possible race between .atomic_enable() / .atomic_disable() which set ctx->connector and the hdcp_check_work_func() which reads ctx->connector without any protection. -- With best wishes Dmitry
