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: <3b81d875-7f4b-446a-565b-189ad6c8d9dc@quicinc.com>
Date:   Tue, 8 Nov 2022 11:29:42 +0530
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
 Thunderbird/91.9.0
Subject: Re: [PATCH] clk: qcom: Update the force mem core bit for GPU clocks
Content-Language: en-US
To:     Doug Anderson <dianders@chromium.org>
CC:     Stephen Boyd <swboyd@chromium.org>, Andy Gross <agross@kernel.org>,
        "Bjorn Andersson" <andersson@kernel.org>,
        <linux-arm-msm@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
        <quic_tdas@quicinc.com>, <linux-clk@vger.kernel.org>
References: <1666159535-6447-1-git-send-email-quic_c_skakit@quicinc.com>
 <CAE-0n52N6oxSLoU_=Cq1xK9bVX7H+AvPsR3dLepMNjKywdffvQ@mail.gmail.com>
 <21cd992c-334e-3a28-f3ac-68a49a4ef00b@quicinc.com>
 <CAD=FV=WRCJ6d6jTHH2ZHvuh+c4yTeXhS_D5LZcvfMn1c4NP2aA@mail.gmail.com>
From:   "Satya Priya Kakitapalli (Temp)" <quic_c_skakit@quicinc.com>
In-Reply-To: <CAD=FV=WRCJ6d6jTHH2ZHvuh+c4yTeXhS_D5LZcvfMn1c4NP2aA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Doug,


On 11/7/2022 10:30 PM, Doug Anderson wrote:
> Hi,
>
> On Sun, Nov 6, 2022 at 9:38 PM Satya Priya Kakitapalli (Temp)
> <quic_c_skakit@quicinc.com> wrote:
>>
>> On 10/28/2022 5:54 AM, Stephen Boyd wrote:
>>> Quoting Satya Priya (2022-10-18 23:05:35)
>>>> From: Taniya Das <quic_tdas@quicinc.com>
>>>>
>>>> There are few GPU clocks which are powering up the memories
>>>> and thus enable the FORCE_MEM_PERIPH always for these clocks
>>>> to force the periph_on signal to remain active during halt
>>>> state of the clock.
>>> I take it that missing this causes GPU to lose state when it suspends
>>> and that confuses the driver?
>>
>> It is more related to GPU SMMU states and the stability issues that are
>> encountered.
> I see a very similar code sequence for sc7180. Is any similar fix
> needed for sc7180, or is this something unique for sc7280?


This is not needed for sc7180, it is related to sc7280 only.