Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <3b5b6271-9611-9884-f0de-5b3f7c3d7b72@linaro.org>
Date:   Mon, 29 May 2023 13:01:13 +0300
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Subject: Re: [PATCH 0/5] MDSS reg bus interconnect
Content-Language: en-GB
To:     Konrad Dybcio <konrad.dybcio@linaro.org>
Cc:     Rob Clark <robdclark@gmail.com>,
        Abhinav Kumar <quic_abhinavk@quicinc.com>,
        Sean Paul <sean@poorly.run>, David Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>,
        Rob Herring <robh+dt@kernel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Krishna Manikandan <quic_mkrishn@quicinc.com>,
        Marijn Suijten <marijn.suijten@somainline.org>,
        linux-arm-msm@vger.kernel.org, dri-devel@lists.freedesktop.org,
        freedreno@lists.freedesktop.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org
References: <20230417-topic-dpu_regbus-v1-0-06fbdc1643c0@linaro.org>
 <CAA8EJpo8X7KrrXoButyW0d1Lz=a5Stw2inFGt2R7KJ+2NTX6wA@mail.gmail.com>
 <74a817ff-5850-330d-8cac-f551be6fa35c@linaro.org>
 <254cd131-4ad1-44c9-2653-862580503c15@linaro.org>
 <e99a9fe9-21e4-fc56-d400-4f6e9df2eaed@linaro.org>
From:   Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
In-Reply-To: <e99a9fe9-21e4-fc56-d400-4f6e9df2eaed@linaro.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 29/05/2023 12:08, Konrad Dybcio wrote:
> 
> 
> On 29.05.2023 10:47, Dmitry Baryshkov wrote:
>> On 29/05/2023 10:42, Konrad Dybcio wrote:
>>>
>>>
>>> On 29.05.2023 04:42, Dmitry Baryshkov wrote:
>>>> On Mon, 17 Apr 2023 at 18:30, Konrad Dybcio <konrad.dybcio@linaro.org> wrote:
>>>>>
>>>>> Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
>>>>> another path that needs to be handled to ensure MDSS functions properly,
>>>>> namely the "reg bus", a.k.a the CPU-MDSS interconnect.
>>>>>
>>>>> Gating that path may have a variety of effects.. from none to otherwise
>>>>> inexplicable DSI timeouts..
>>>>>
>>>>> This series tries to address the lack of that.
>>>>>
>>>>> Example path:
>>>>>
>>>>> interconnects = <&bimc MASTER_AMPSS_M0 0 &config_noc SLAVE_DISPLAY_CFG 0>;
>>>>
>>>> If we are going to touch the MDSS interconnects, could you please also
>>>> add the rotator interconnect to the bindings?
>>>> We do not need to touch it at this time, but let's not have to change
>>>> bindings later again.
>>>>
>>> Ack
>>
>> Also, several points noted from the mdss fbdev driver:
>>
>> - All possible clents vote for the low bw setting. This includes DSI, HDMI, MDSS itself and INTF
> As in, "you need NUM_CLIENTS * MIN_VOTE" or as in "any client necessitates
> a vote"?

Each client has separate vote

> 
>> - SMMU also casts such vote, which I do not think should be necessary, unless there is a separate MDSS SMMU?
> There's one on 8996, pre-845 SoCs often have a MMSS MMU, 845 and
> later have a MMSS-specific TBU which (theoretically) requires a
> vote for access to 0x400-0x7ff SIDs

Ack.

> 
>> - PINGPONG cacsts high bw setting for the sake of speeding up the LUT tables if required.
> Hm, I think is would be a separate topic.

I think so. I'd do a single vote from mdp5/dpu1. Then we can cast higher 
vote from PP/DSPP/etc.

-- 
With best wishes
Dmitry