Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19;
Message-ID: <fa739928-ed1d-ed6f-52c2-541319d9cc2f@gmail.com>
Date:   Mon, 9 May 2022 03:42:05 +0900
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.8.1
Subject: Re: [RFC PATCH 2/2] PM / devfreq: rk3399_dmc: Block PMU during
 transitions
Content-Language: en-US
To:     Heiko Stuebner <heiko@sntech.de>,
        Brian Norris <briannorris@chromium.org>,
        MyungJoo Ham <myungjoo.ham@samsung.com>,
        Kyungmin Park <kyungmin.park@samsung.com>,
        Chanwoo Choi <cw00.choi@samsung.com>
Cc:     linux-kernel@vger.kernel.org,
        Elaine Zhang <zhangqing@rock-chips.com>,
        linux-pm@vger.kernel.org, Doug Anderson <dianders@chromium.org>,
        linux-arm-kernel@lists.infradead.org,
        linux-rockchip@lists.infradead.org
References: <20220406014842.2771799-1-briannorris@chromium.org>
 <582e3645-b24e-356e-7f0f-0d37bb1e32e6@gmail.com>
 <6c6ec0db-111c-e48f-57ce-0e444a0d168e@gmail.com> <44651538.fMDQidcC6G@phil>
From:   Chanwoo Choi <cwchoi00@gmail.com>
In-Reply-To: <44651538.fMDQidcC6G@phil>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 22. 5. 9. 00:07, Heiko Stuebner wrote:
> Am Samstag, 7. Mai 2022, 16:21:59 CEST schrieb Chanwoo Choi:
>> On 22. 4. 14. 08:13, Chanwoo Choi wrote:
>>> On 22. 4. 14. 07:45, Heiko Stübner wrote:
>>>> Hi,
>>>>
>>>> Am Donnerstag, 14. April 2022, 00:14:40 CEST schrieb Chanwoo Choi:
>>>>> On 22. 4. 6. 10:48, Brian Norris wrote:
>>>>>> See the previous patch ("soc: rockchip: power-domain: Manage resource
>>>>>> conflicts with firmware") for a thorough explanation of the conflicts.
>>>>>> While ARM Trusted Firmware may be modifying memory controller and
>>>>>> power-domain states, we need to block the kernel's power-domain driver.
>>>>>>
>>>>>> If the power-domain driver is disabled, there is no resource conflict
>>>>>> and this becomes a no-op.
>>>>>>
>>>>>> Signed-off-by: Brian Norris <briannorris@chromium.org>
>>>>>> ---
>>>>>>
>>>>>>     drivers/devfreq/rk3399_dmc.c | 13 +++++++++++++
>>>>>>     1 file changed, 13 insertions(+)
>>>>>>
>>>>>> diff --git a/drivers/devfreq/rk3399_dmc.c
>>>>>> b/drivers/devfreq/rk3399_dmc.c
>>>>>> index e494d1497d60..daff40702615 100644
>>>>>> --- a/drivers/devfreq/rk3399_dmc.c
>>>>>> +++ b/drivers/devfreq/rk3399_dmc.c
>>>>>> @@ -21,6 +21,7 @@
>>>>>>     #include <linux/rwsem.h>
>>>>>>     #include <linux/suspend.h>
>>>>>> +#include <soc/rockchip/pm_domains.h>
>>>>>>     #include <soc/rockchip/rk3399_grf.h>
>>>>>>     #include <soc/rockchip/rockchip_sip.h>
>>>>>> @@ -93,6 +94,16 @@ static int rk3399_dmcfreq_target(struct device
>>>>>> *dev, unsigned long *freq,
>>>>>>         mutex_lock(&dmcfreq->lock);
>>>>>> +    /*
>>>>>> +     * Ensure power-domain transitions don't interfere with ARM
>>>>>> Trusted
>>>>>> +     * Firmware power-domain idling.
>>>>>> +     */
>>>>>> +    err = rockchip_pmu_block();
>>>>>> +    if (err) {
>>>>>> +        dev_err(dev, "Failed to block PMU: %d\n", err);
>>>>>> +        goto out_unlock;
>>>>>> +    }
>>>>>> +
>>>>>>         /*
>>>>>>          * Some idle parameters may be based on the DDR controller
>>>>>> clock, which
>>>>>>          * is half of the DDR frequency.
>>>>>> @@ -198,6 +209,8 @@ static int rk3399_dmcfreq_target(struct device
>>>>>> *dev, unsigned long *freq,
>>>>>>         dmcfreq->volt = target_volt;
>>>>>>     out:
>>>>>> +    rockchip_pmu_unblock();
>>>>>> +out_unlock:
>>>>>>         mutex_unlock(&dmcfreq->lock);
>>>>>>         return err;
>>>>>>     }
>>>>>
>>>>> Acked-by: Chanwoo Choi <cw00.choi@samsung.com>
>>>>
>>>> so I guess you're ok with me picking up both patches, right?
>>>> [Just making sure :-) ]
>>>
>>> This patch have the dependency of latest devfreq-next branch.
>>> So that need to make the immutable branch between rockchip and devfreq.
>>>
>>
>> Hi Heiko and Brian,
>>
>> Is there any other progress?
>>
>> IMHO, if rockchip maintainer reply the acked-by from patch1
>> and then agree these patches to be applied to devfreq.git,
>> I can take them.
> 
> sounds good to me. Patch1 looks good and correct to me, so
> I've added a Reviewed-by for it and it defintily makes sense for
> both to go through the devfreq tree then, so we don't need
> additional stable-branches :-)

OK. I'll take them with your reviewed-by tag. Thanks.


-- 
Best Regards,
Samsung Electronics
Chanwoo Choi