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 575A8C433EF for ; Tue, 28 Jun 2022 10:08:48 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1344858AbiF1KIq (ORCPT ); Tue, 28 Jun 2022 06:08:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39948 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245666AbiF1KIo (ORCPT ); Tue, 28 Jun 2022 06:08:44 -0400 Received: from madras.collabora.co.uk (madras.collabora.co.uk [46.235.227.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1C9A22F393; Tue, 28 Jun 2022 03:08:43 -0700 (PDT) Received: from [192.168.2.145] (109-252-118-164.nat.spd-mgts.ru [109.252.118.164]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) (Authenticated sender: dmitry.osipenko) by madras.collabora.co.uk (Postfix) with ESMTPSA id 0C21966015BF; Tue, 28 Jun 2022 11:08:40 +0100 (BST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=collabora.com; s=mail; t=1656410921; bh=4SmhwJ59cYNwGa9/uAOmjkCzl5Kwd4RkrU6slG6AY6c=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=gBcsZ9sToRUM8cKdvaAO72/zDI2G3Kl2iaVhdyvOxLtKDzWiVt3MBPV9oeKUhssOi 62COElRol0rewHQCq5aLavu4HrwWozFJA0T6/XTjCyKEGJI+BZDli/VzJ/hui00gjE i/FI7Yx7Y+jHenRhurJ+RtU/QFwGVq7wnYmgmjSHrqM5yN1k4fsTdwktEDjORqgoab +Ss7jDoo002EMMU0Nt/ZG8an7mVtncv4k0kIoBCjzpIcOpEqKrpMUPJTi8Ro6t7fV0 TCU3XOjLd6zZ66MOZUsfG9URyZSk/aebQQvUblK2QjoPpJH5CojSW3mctDn264kGhp uiYWKUDHGukNw== Message-ID: Date: Tue, 28 Jun 2022 13:08:38 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH 22/31] soc/tegra: Migrate to dev_pm_opp_set_config() Content-Language: en-US To: Viresh Kumar , Jonathan Hunter , Dmitry Osipenko Cc: Thierry Reding , linux-pm@vger.kernel.org, Vincent Guittot , Rafael Wysocki , Stephen Boyd , Nishanth Menon , Krzysztof Kozlowski , linux-tegra@vger.kernel.org, linux-kernel@vger.kernel.org References: <449b344f037c7ef1970bc84d31e0d4c4cb4d2951.1653564321.git.viresh.kumar@linaro.org> <20220624004831.po35sowzfo4c47b3@vireshk-i7> <20220624005700.oj4etaajbutvsym7@vireshk-i7> <73d39022-c6fc-0c21-cb68-9714846f02bf@gmail.com> <20220627064526.2nkezq4nufpkl4y2@vireshk-i7> <20220627072104.ir7kujhezxhzl6a7@vireshk-i7> <20220628070943.5tfyad63rh6niq6x@vireshk-i7> From: Dmitry Osipenko In-Reply-To: <20220628070943.5tfyad63rh6niq6x@vireshk-i7> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/28/22 10:09, Viresh Kumar wrote: > On 27-06-22, 12:51, Viresh Kumar wrote: >> On 27-06-22, 10:14, Dmitry Osipenko wrote: >>> 27.06.2022 09:45, Viresh Kumar пишет: >>>>> Looks okay. If you'll solve the cpufreq problem where OPP config is set >>>>> by two drivers for the same cpu device >>>> This is supported, there is some early freeing of resources on the >>>> removal path though, the reasoning for which I already gave in another >>>> email. Though, I am open to sorting that out as well, but nothing >>>> breaks the code for now AFAICT. >>>> >>> >>> In case of Tegra, we use tegra-cpufreq driver that sets supported_hw and >>> registers cpufreq-dt. If cpufreq-dt driver defers the probe, then the >>> supported_hw will be lost on the re-probe. I haven't checked yet, but I >>> suppose that cpufreq-dt driver defers on Tegra30 because of the CPU >>> regulator and that's why we get the "OPP table is missing" error. >> >> Aha, I get it now. I see, this is a real problem. Will fix it. Give me >> some time to think. Thanks. > > Okay, I fixed this in opp/linux-next, can you or Jon please give it a > go on tegra30 to see if the issue is fixed ? > > FWIW, I have fixed this with the IDR API and the OPP core will only > free the resources in clear-config, that the corresponding set-config > has configured. I have tested it with the clk API only though. > > Once you confirm, I will resend all the patches and hope no issues are > left here. > > Thanks for helping out guys. Really appreciate it. > The opp/linux-next works fine, thank you. Tested-by: Dmitry Osipenko BTW, the idr_alloc() is obsoleted by xa_alloc(). -- Best regards, Dmitry