From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 15A7BC7EE29 for ; Fri, 2 Jun 2023 21:05:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234860AbjFBVFv (ORCPT ); Fri, 2 Jun 2023 17:05:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234452AbjFBVFu (ORCPT ); Fri, 2 Jun 2023 17:05:50 -0400 Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com [IPv6:2607:f8b0:4864:20::b2c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B2402E4E for ; Fri, 2 Jun 2023 14:05:39 -0700 (PDT) Received: by mail-yb1-xb2c.google.com with SMTP id 3f1490d57ef6-bacf685150cso2708368276.3 for ; Fri, 02 Jun 2023 14:05:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1685739939; x=1688331939; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=bGtOFR2mphGb3w/SKqqatTcmK2Pjhu9d+mT6IMF2bsA=; b=O8cWtf9dK3IVBtCzRm56Bvob5Vhhmtc5jm/bwtrzzNg5NFGeACg0/roonLuhnaKj9w l9zK+/K1wWpvLNvKbUMpYKoE5GSPi2MzMfZLq2V8rYqnQdDI79ckTFzhENhOotuajVBx rZLnuOHFhJdTfuviF+xyrGeIZowEG6c591jS++W2CWKFRNVKmG8W4l6ucVyIz0hqICLn 1SJduWUuUDVhlUWYgc8KpFRBJyi/pdoJtLxorMHFCbmjaHgvsxBC8jZMAsTfAOIcK9Ta rxXWbKQojO6qVCNjmvwICCaFkBklLVyIxuyXU1of/N+71b5mF2YPzLb5Uln13dIpUknZ feUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685739939; x=1688331939; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=bGtOFR2mphGb3w/SKqqatTcmK2Pjhu9d+mT6IMF2bsA=; b=Iv+WX17LvTckVWcjr4G24SAL+3PWrzjw6cc4PjU4AasZy/vfvapz9ktonJBDdfONcG klGccPpD13Oar1f4uw3pgAUM796IM7GNNiHYxoHcqPOty8KfgjdfLZ1ZJ1z8PJWK74MB qkGdkSfte5kZMig+nHNT6qYjqWhykH602L/L5m+MEtz0hlShiKj/eG6kZSN+GKem2Lze WclGWu6cbpbolBl18Ef88jRS+7nKKUQYHD5mJ4bMIPBYJ4LOHMuYz2fBnyQqQsD9qWac i4C94XQtRBJhwxC0pz54mZ+B+nSsLQjwzdKn7ddDx+j+bOiLo2lb3NzEy6JjcKYWA94M TcOA== X-Gm-Message-State: AC+VfDxzUPgkU3aNqtsx9PKxt/PM3SQ7gHDkOx2V4XZja19KrelGj8Za W0TFa3xcagD08u1mck24Rc+lKldaRUUMDQqFzWP0Vw== X-Google-Smtp-Source: ACHHUZ7Gn7c4DGB7V9sdrivTf8wBNtf7tCUcHwzPgc4kwSOC01IapgteGYaVZI1W8k3JxzfxAXKuXpFOGHc0YMbxFh8= X-Received: by 2002:a25:768a:0:b0:ba9:6b90:e551 with SMTP id r132-20020a25768a000000b00ba96b90e551mr4566101ybc.50.1685739938909; Fri, 02 Jun 2023 14:05:38 -0700 (PDT) MIME-Version: 1.0 References: <1685464318-25031-1-git-send-email-quic_khsieh@quicinc.com> <1685464318-25031-3-git-send-email-quic_khsieh@quicinc.com> <157e8219-7af2-c7ed-6d99-3caa6fbc11ba@quicinc.com> <32aa41ee-4ab0-0915-a77f-5b0d6874b3e1@quicinc.com> In-Reply-To: <32aa41ee-4ab0-0915-a77f-5b0d6874b3e1@quicinc.com> From: Dmitry Baryshkov Date: Sat, 3 Jun 2023 00:05:27 +0300 Message-ID: Subject: Re: [Freedreno] [PATCH v1 2/3] drm/msm/dpu: retrieve DSI DSC struct at atomic_check() To: Kuogee Hsieh Cc: freedreno@lists.freedesktop.org, "open list:DRM DRIVER FOR MSM ADRENO GPU" , Rob Clark , Sean Paul , Stephen Boyd , Douglas Anderson , Vinod Koul , Daniel Vetter , Dave Airlie , Andy Gross , Bjorn Andersson , Abhinav Kumar , Jessica Zhang , Sankeerth Billakanti , Marijn Suijten , "open list:DRM DRIVER FOR MSM ADRENO GPU" , open list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org Generic note: please use reply-to-all instead of any other options to answer the email. You have dropped all recipients (except the freedreno@) in the message (and it was left unnoticed). On Fri, 2 Jun 2023 at 20:00, Kuogee Hsieh wrote: > >> There is one option which is keep current > >> > >> 1) keep struct drm_dsc_config *msm_dsi_get_dsc_config(struct msm_dsi > >> *msm_dsi) at dsi.c > >> > >> 2) use struct msm_display_info *disp_info saved at dpu_enc to locate > >> struct msm_dsi from priv->dsi[] list (see item #3) > >> > >> 3) info.dsc = msm_dsi_get_dsc_config(priv->dsi[info.h_tile_instance[0]]); > >> > >> 4) ballistically, keep original code but move info.dsc = > >> msm_dsi_get_dsc_config(priv->dsi[i]); to other place sush as > >> atomic_check() and atomic_enable(). > >> > > 5) leave drm_dsc_config handling as is, update the dsc config from the > > DP driver as suitable. If DSC is not supported, set > > dsc->dsc_version_major = 0 and dsc->dsc_version_minor = 0 on the DP > > side. In DPU driver verify that dsc->dsc_version_major/_minor != 0. > > I am confusing with item 5) > > Currently, msm_dsi_get_dsc_config() of dsi side return dsc pointer if > dsc enabled and NULL if dsc not enabled. > > Should checking dsc == NULL is good enough to differentiate between dsc > is supported and not supported? This is called a "shared memory area". Instead of either providing a dynamic data pointer, one can provide a pointer to the static area which is filled by DP or DSI. If there is no DSC available, one flags 'data not valid' by setting major,minor to 0. > > Why need to set both dsc->dsc_version_major = 0 and > dsc->dsc_version_minor = 0 for dsc is not supported? 6) Another option (which is more in style of what is done in the vendor kernel, if I'm not mistaken): Enhance struct drm_display_mode to contain a pointer to the DSC config. Use this pointer to check whether DSC should be enabled for the particular mode or not. The panels with the static DSC configuration can use a static data pointer. -- With best wishes Dmitry