linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
To: Kuogee Hsieh <quic_khsieh@quicinc.com>
Cc: robdclark@gmail.com, sean@poorly.run, swboyd@chromium.org,
	vkoul@kernel.org, daniel@ffwll.ch, airlied@linux.ie,
	agross@kernel.org, bjorn.andersson@linaro.org,
	quic_abhinavk@quicinc.com, quic_aravindh@quicinc.com,
	freedreno@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-arm-msm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drm/msm: populate intf_audio_select() base on hardware capability
Date: Tue, 15 Feb 2022 00:00:26 +0300	[thread overview]
Message-ID: <369073e5-4311-a752-786e-e5132b202796@linaro.org> (raw)
In-Reply-To: <3b6cd2c2-5ebb-97a2-f9af-3c32d0899cd8@quicinc.com>

On 14/02/2022 20:55, Kuogee Hsieh wrote:
> 
> On 2/11/2022 3:36 PM, Dmitry Baryshkov wrote:
>> On Sat, 12 Feb 2022 at 02:23, Kuogee Hsieh<quic_khsieh@quicinc.com>  wrote:
>>> intf_audio_select() callback function use to configure
>>> HDMI_DP_CORE_SELECT to decide audio output routes to HDMI or DP
>>> interface. HDMI is obsoleted at newer chipset. To keep supporting
>>> legacy hdmi application, intf_audio_select call back function have
>>> to be populated base on hardware chip capability where legacy
>>> chipsets have has_audio_select flag set to true.
>>>
>>> Signed-off-by: Kuogee Hsieh<quic_khsieh@quicinc.com>
>>> ---
>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 ++
>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 1 +
>>>   drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c     | 9 ++++++---
>>>   3 files changed, 9 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>> index 272b14b..23680e7 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
>>> @@ -201,6 +201,7 @@ static const struct dpu_caps sdm845_dpu_caps = {
>>>          .has_dim_layer = true,
>>>          .has_idle_pc = true,
>>>          .has_3d_merge = true,
>>> +       .has_audio_select = true,
>>>          .max_linewidth = DEFAULT_DPU_OUTPUT_LINE_WIDTH,
>>>          .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
>>>          .max_hdeci_exp = MAX_HORZ_DECIMATION,
>>> @@ -229,6 +230,7 @@ static const struct dpu_caps sm8150_dpu_caps = {
>>>          .has_dim_layer = true,
>>>          .has_idle_pc = true,
>>>          .has_3d_merge = true,
>>> +       .has_audio_select = true,
>>>          .max_linewidth = 4096,
>>>          .pixel_ram_size = DEFAULT_PIXEL_RAM_SIZE,
>>>          .max_hdeci_exp = MAX_HORZ_DECIMATION,
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>>> index e5a96d6..b33f91b 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
>>> @@ -357,6 +357,7 @@ struct dpu_caps {
>>>          bool has_dim_layer;
>>>          bool has_idle_pc;
>>>          bool has_3d_merge;
>>> +       bool has_audio_select;
>> I'd suggest adding a bit to dpu_mdp_cfg's features instead, following
>> the example of other hardware blocks.
> 
> it may cause mis leading if we put this in hardware level since 
> MDP_HDMI_DP_SELECT  bit has not be connected
> 
> to logic for a while even it still present at ipcat. Also this bit but 
> will be  removed at next release.

I'm sorry, I can't quite catch you. Why would you like to remove this 
bit at the next release?

> 
> Is dpu_caps level more proper than in hardware feature level?

A priciple of the least surprise. In other hardware-dependent virtual 
functions selection we use block's caps->features rather than boolean flags.

> 
> 
>>>          /* SSPP limits */
>>>          u32 max_linewidth;
>>>          u32 pixel_ram_size;
>>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
>>> index 282e3c6..e608f4d 100644
>>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
>>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_top.c
>>> @@ -261,14 +261,17 @@ static void dpu_hw_intf_audio_select(struct dpu_hw_mdp *mdp)
>>>   }
>>>
>>>   static void _setup_mdp_ops(struct dpu_hw_mdp_ops *ops,
>>> -               unsigned long cap)
>>> +               unsigned long cap,
>>> +               const struct dpu_mdss_cfg *m)
>>>   {
>>>          ops->setup_split_pipe = dpu_hw_setup_split_pipe;
>>>          ops->setup_clk_force_ctrl = dpu_hw_setup_clk_force_ctrl;
>>>          ops->get_danger_status = dpu_hw_get_danger_status;
>>>          ops->setup_vsync_source = dpu_hw_setup_vsync_source;
>>>          ops->get_safe_status = dpu_hw_get_safe_status;
>>> -       ops->intf_audio_select = dpu_hw_intf_audio_select;
>>> +
>>> +       if (m->caps->has_audio_select)
>>> +               ops->intf_audio_select = dpu_hw_intf_audio_select;
>>>   }
>>>
>>>   static const struct dpu_mdp_cfg *_top_offset(enum dpu_mdp mdp,
>>> @@ -320,7 +323,7 @@ struct dpu_hw_mdp *dpu_hw_mdptop_init(enum dpu_mdp idx,
>>>           */
>>>          mdp->idx = idx;
>>>          mdp->caps = cfg;
>>> -       _setup_mdp_ops(&mdp->ops, mdp->caps->features);
>>> +       _setup_mdp_ops(&mdp->ops, mdp->caps->features, m);
>>>
>>>          return mdp;
>>>   }


-- 
With best wishes
Dmitry

  parent reply	other threads:[~2022-02-14 21:00 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-11 23:23 [PATCH] drm/msm: populate intf_audio_select() base on hardware capability Kuogee Hsieh
2022-02-11 23:36 ` Dmitry Baryshkov
     [not found]   ` <3b6cd2c2-5ebb-97a2-f9af-3c32d0899cd8@quicinc.com>
2022-02-14 21:00     ` Dmitry Baryshkov [this message]
2022-02-12  0:08 ` Dmitry Baryshkov
2022-02-12  0:59   ` Abhinav Kumar
2022-02-12 16:16     ` Dmitry Baryshkov
2022-02-16  2:26 ` Stephen Boyd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=369073e5-4311-a752-786e-e5132b202796@linaro.org \
    --to=dmitry.baryshkov@linaro.org \
    --cc=agross@kernel.org \
    --cc=airlied@linux.ie \
    --cc=bjorn.andersson@linaro.org \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=freedreno@lists.freedesktop.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=quic_abhinavk@quicinc.com \
    --cc=quic_aravindh@quicinc.com \
    --cc=quic_khsieh@quicinc.com \
    --cc=robdclark@gmail.com \
    --cc=sean@poorly.run \
    --cc=swboyd@chromium.org \
    --cc=vkoul@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).