On Wed, 31 May 2023 at 18:41, Kuogee Hsieh <quic_khsieh@xxxxxxxxxxx> wrote:got it.
I'd say, get it during atomic_check (and don't store it anywhere).
where can drm_dsc_config be stored?+ if (dpu_enc->disp_info.intf_type == DRM_MODE_ENCODER_DSI) {INTF_DSI
+ struct drm_bridge *bridge;This condition is not correct. We should be updating the DSC even if
+
+ if (!dpu_enc->dsc) {
there is one.
+ bridge = drm_bridge_chain_get_first_bridge(drm_enc);This approach will not work for the hot-pluggable outputs. The dpu_enc
+ dpu_enc->dsc = msm_dsi_bridge_get_dsc_config(bridge);
is not a part of the state. It should not be touched before
atomic_commit actually commits changes.
Then get it during atomic_enable (and save in dpu_enc).
So, for this DSI-to-DP bridge will get_bridge_dsc() return DSCAlso, I don't think I like the API. It makes it impossible for theForm my understanding, a bridge contains two interfaces.
driver to check that the bridge is the actually our DSI bridge or not.
Once you add DP here, the code will explode.
I think instead we should extend the drm_bridge API to be able to get
the DSC configuration from it directly. Additional care should be put
to design an assymetrical API. Theoretically a drm_bridge can be both
DSC source and DSC sink. Imagine a DSI-to-DP or DSI-to-HDMI bridge,
supporting DSC on the DSI side too.
Therefore I would think only one bridge for dsi-to-dp bridge? and this
bridge should represent the bridge chip?
I am thinking adding an ops function, get_bridge_dsc() to struct
drm_bridge_funcs to retrieve drm_dsc_config.
configuration for the DSI or for the DP side of the bridge?
Do you have other suggestion?Let me think about it for a few days.