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 BDF69C00140 for ; Fri, 5 Aug 2022 21:39:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238046AbiHEVjo (ORCPT ); Fri, 5 Aug 2022 17:39:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59908 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232791AbiHEVjn (ORCPT ); Fri, 5 Aug 2022 17:39:43 -0400 Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8E7B46D578 for ; Fri, 5 Aug 2022 14:39:42 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id z4so4310770ljn.8 for ; Fri, 05 Aug 2022 14:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc; bh=Ib6oNoeC1y7DWmUGX1sKZNT4F0DH8JMdm8hi9j96RuE=; b=dEwdegAtlsp946F0kCYkkcY24jSOKl3+Nqut8Wt1pdvXqyUYl7/7FfTPIOiIoLjar/ DYbjlHAYIyNqczQqwxycAnMkcX7157CtSuvG5YrOXLaFAuPs30i0V6VnHZFjm59svJE6 8XjJ4BFWc3xhN7WHSCCHbdkFK2R2GVrzJ8kqERdvxnU3hvmIi9gQxCJLqDqSBpPD+KKX 2Xa6r999PQDA+QEH0Cx0+OPdVhDnJ6d6c+5zA6C9QIUKfp37Tfz7zo9mGYfqM3FH6dW7 jSXKSlgvCcHkFrRQr34NM5Za7WI8zy2RbYQXhDux00NYvRsFBMOzmw3m5RmkO4DNhIt2 c8/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc; bh=Ib6oNoeC1y7DWmUGX1sKZNT4F0DH8JMdm8hi9j96RuE=; b=nZhCzNeQ5Jo8gBsmrYYuVDzUgAKEenO/HqTR2/cIEkPN6FyXR2tSa8fbE5prIh3w20 oiiOjCmDKlUOTt9VBiIV/MNeM2/TAiqd4aMa7fKdWRYhFn40Fs3MEzsXN59sdU4hu6kg WW128gjTL4p3yRFV+sokQiR7rD6gcSzJ5FAVoXT0OzHEkQ+BzMQUPjzkBY7PUufUBatW pN2hRNiDvPPJ8DzoAAivhPg4m1viaz/LUQPePNKJlkYSr3Db+lx+bcPeca/dKwo2/OYv ubE2TVzRP+0iQvl0EUlj98Epf/+BAi7RvvKNWPGh3GUqZEtsr3DkvFeo0ZpHfqaOHWo1 FSLQ== X-Gm-Message-State: ACgBeo23VnPRh5dvuiyDmgyrKfDGQlokgHU5Cd3xvb5qG43PESv8dGJg 0SYjuNx89D1qpnOmh6M4VW/rIQ== X-Google-Smtp-Source: AA6agR7mXVPjX6BpjKrzHQR728WlcEp54YPNDbHE4HL+JwWX1mBqH/QF6PbWCziisye51GE1kIgDhA== X-Received: by 2002:a2e:2e1a:0:b0:25e:4c40:48f4 with SMTP id u26-20020a2e2e1a000000b0025e4c4048f4mr2388553lju.421.1659735580908; Fri, 05 Aug 2022 14:39:40 -0700 (PDT) Received: from [192.168.1.211] ([37.153.55.125]) by smtp.gmail.com with ESMTPSA id f1-20020a056512360100b0048afe02c925sm584278lfs.219.2022.08.05.14.39.40 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 05 Aug 2022 14:39:40 -0700 (PDT) Message-ID: <9a53b01f-e112-314b-faa1-13f0ed36f595@linaro.org> Date: Sat, 6 Aug 2022 00:39:39 +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: PSCI domains without OSI support Content-Language: en-GB To: Sudeep Holla , Ulf Hansson Cc: linux-arm-msm@vger.kernel.org, Bjorn Andersson , Vinod Koul , Linux PM References: <20220727111410.bglx2u26456ray2u@bogus> <20220728084012.jjbmycplye3zuaok@bogus> <20220805160020.fc5s3hv3u5h4gcmv@bogus> From: Dmitry Baryshkov In-Reply-To: <20220805160020.fc5s3hv3u5h4gcmv@bogus> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-arm-msm@vger.kernel.org On 05/08/2022 19:00, Sudeep Holla wrote: > On Fri, Aug 05, 2022 at 04:12:42PM +0200, Ulf Hansson wrote: >> On Thu, 28 Jul 2022 at 10:40, Sudeep Holla wrote: >>> >>> On Wed, Jul 27, 2022 at 04:24:22PM +0300, Dmitry Baryshkov wrote: >>>> On Wed, 27 Jul 2022 at 14:14, Sudeep Holla wrote: >>>>> >>>>> On Wed, Jul 27, 2022 at 12:09:27PM +0300, Dmitry Baryshkov wrote: >>>>>> - Allow DTS forcing the PSCI power domains even if OSI enablement fails? >>>>> >>>>> Meaning DTS flag for this ? If OSI enable fails, why would you want to >>>>> still proceed. It is non-compliant and must be fixed if the firmware >>>>> supports OSI and expects OSPM to use the same. >>>> >>>> I'm not sure at this moment. PSCI firmware reports that OSI mode is >>>> supported, but then when psci_pd_try_set_osi_mode() tries to switch >>>> into OSI mode, it gets NOT_SUPPORTED. >>> >>> Yikes, fix the damn broken firmware. That is utter non-sense. I don't >>> understand why would the firmware authors enable some feature before it >>> is ready. >> >> I certainly agree that the FW is broken and should really have been >> fixed, but that seems unlikely to happen when moving forward. >> >> On the other hand, it's quite common that we try to add workarounds at >> the Linux side to fix FW issues. Of course, it depends on what kind of >> hacks it means for us to carry. >> >> In this particular case, I am of the opinion that it looks like the >> "hack" may be worth it. Unless I have underestimated the problem, it >> seems like a new DT property/flag and a simple if-clause in >> psci_pd_try_set_osi_mode() should do the trick for us. >> > > I don't like the idea of new property/flag for this for simple reason. > Once you have that it is impossible to control if downstream new platforms > are using it and they will expect it to be maintained once they ship the > product. According to my quick research the requested issue was present on platforms revealed from 2015 (2013?) to 2017. Since sdm845 (December 2017) the issue is not present. So this is a part of history rather than current platforms being in need of this quirk. > >> I wouldn't mind maintaining such small parts, when going forward - and >> of course I think we should also reject any newer platforms from using >> it. >> > > The only way that we can achieve this IMO is to have quirks based on > platform compatible which needs to be updated and can be rejected for > newer platforms. New flags means new feature which is expected to be > supported for long and hard to control newer platforms not using them. I see your point. However from my point of view, the DT property allows more finer-grained control. Compare the semantics: - Proprety: assume that the platform is in OSI mode, do not call psci_osi_set_mode(). - Platform compat list: If the psci_osi_set_mode() has failed, ignore the error. I would not dare to blindly assume that e.g. all msm8996 devices are in OSI mode. [skipped] >> To me, it seems like a pity, if we just decided to leave all those >> devices out there in the field, lacking support for deeper idle >> states. Don't you think? >> > > Sure, but I don't like new flags for handling this for reasons stated > above. Unless DT maintainers expect to take "new flag/property" for > some reasons that I am not aware of, I prefer the check on existing > platform compatible to deal with this problem so that this problem > doesn't trickle down to newer platforms as well. Thoughts ? > > And please add that we can't add any compatibles that are added later > than certain date to that list when we are adding this support. Then we are ruling out existing platforms, which are not yet supported by Linux. Hopefully you meant that we can not extend this list with platforms developed/announced after certain date (I might be slightly wrong here, but I estimate that the end of 2018 as a safe boundary). Newer platforms (sdm845, 2018, qcs404, 2019, etc) report SET_SUSPEND as supported (and return DENIED in attempt to set the PC mode). -- With best wishes Dmitry