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 B2F0AC74A5B for ; Wed, 29 Mar 2023 19:25:23 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230194AbjC2TZW (ORCPT ); Wed, 29 Mar 2023 15:25:22 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36954 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229504AbjC2TZW (ORCPT ); Wed, 29 Mar 2023 15:25:22 -0400 Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 79A32F4 for ; Wed, 29 Mar 2023 12:25:20 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id x17so21610363lfu.5 for ; Wed, 29 Mar 2023 12:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680117919; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=3wpiy16R/8+GdOV9YH/3sovb1Ren/VC9veLHKx7+T4U=; b=mpumkhpOwENrYVhzJyze4CBQpIu9AzQ1DdLnH41oDNzz8O1+qEz92f3i4VDv6NGeXi z8q29cPruFvJ2i4yE/xzwKEHKSROKEwQy3Sa0h9NWCsWneaYTvyIJ/jQxhxLi2FVZ9sr uklx1F8j7wlKzGSC8JL/b5e5JbbPH5I9aWDP9/hatz6LWUx5fdpXAQpPA+L1nncpVOxt LhRlIASsMqkvrP6o1qrqAvMsZVN5TAehTxDjQ8cM1QcpA2bXQAh/sbxV3KfqgQ6tx8W+ xp5nYNIwVmb7xIolNMZrcgojaQRT2Usth9dOeDRKEaUTsvpE5DJevo88RgEghPPa6fwS Btmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680117919; h=content-transfer-encoding:in-reply-to:references:cc:to:from :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=3wpiy16R/8+GdOV9YH/3sovb1Ren/VC9veLHKx7+T4U=; b=lrTOek3QIe4rhNuQcXEMBvfeK9dI+98oKrfdFP2DAAxFzEJPaXfYiXknWt9FpnP9L9 E5FnhhS7fahfeRBtk4xb4VQWZeIatQ3NasMO6srgmJHE9s3YTjqxo4pqPMCd7P9K86ta SUAFKJgtbvYPfjGStDcS5pZek/IaiQshAZC7AiarPsNTOfGcZTow0UgXWvo9jzSbO2Qt VunpCFtcd1emkMc832/8RMvl351fSUoYtN9uve/JT+Ibpfg39P0pE4CcBw4bx80KVBFM 5vrB8upkC4+zP6d9+Y5C2y5aNTBSQS/CAQfaR2J53+Ar3yhwLCRcbhwBx+wPBm9mEbW6 hLCQ== X-Gm-Message-State: AAQBX9flnqMV8J30sefnx3TjdCNRns7Gu0AtPlfbbpgIMyqxsNyPddNR InNDPqr145CzLG7czKiw3L2GFQ== X-Google-Smtp-Source: AKy350YFaKBJCmSEfs4xiSiYMlttEKoeZnWZhi/9ekX3U4AKOErM5tEXQz+yUyLvo3zGNoksJ8ujrw== X-Received: by 2002:ac2:43b3:0:b0:4dc:537c:9230 with SMTP id t19-20020ac243b3000000b004dc537c9230mr6195266lfl.8.1680117918722; Wed, 29 Mar 2023 12:25:18 -0700 (PDT) Received: from [192.168.1.101] (abxj225.neoplus.adsl.tpnet.pl. [83.9.3.225]) by smtp.gmail.com with ESMTPSA id a16-20020a056512021000b004e845954a81sm5558088lfo.296.2023.03.29.12.25.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Mar 2023 12:25:18 -0700 (PDT) Message-ID: <5d8a7b76-482b-99fe-c55b-6d3e3d2d8394@linaro.org> Date: Wed, 29 Mar 2023 21:25:16 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH 3/3] arm64: dts: qcom: Split out SA8155P and use correct RPMh power domains Content-Language: en-US From: Konrad Dybcio To: Bjorn Andersson Cc: linux-arm-msm@vger.kernel.org, agross@kernel.org, krzysztof.kozlowski@linaro.org, marijn.suijten@somainline.org, Rob Herring , Krzysztof Kozlowski , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org References: <20230214095435.2192153-1-konrad.dybcio@linaro.org> <20230214095435.2192153-3-konrad.dybcio@linaro.org> <20230314001052.7qvgbwkl73x22oll@ripper> <20230315230024.wxuqthay74i5zgrq@ripper> <3d3117d2-b3eb-1174-7061-b899cdcdf6ce@linaro.org> <20230320021957.yzg6zhrhjr36rcz4@ripper> <6ae97b26-b1e7-b382-b6f6-053afe26a1a2@linaro.org> In-Reply-To: <6ae97b26-b1e7-b382-b6f6-053afe26a1a2@linaro.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: devicetree@vger.kernel.org On 20.03.2023 11:39, Konrad Dybcio wrote: > > > On 20.03.2023 03:19, Bjorn Andersson wrote: >> On Thu, Mar 16, 2023 at 12:50:49AM +0100, Konrad Dybcio wrote: >>> On 16.03.2023 00:00, Bjorn Andersson wrote: >>>> On Tue, Mar 14, 2023 at 12:41:45PM +0100, Konrad Dybcio wrote: >>>>> >>>>> >>>>> On 14.03.2023 12:36, Konrad Dybcio wrote: >>>>>> >>>>>> >>>>>> On 14.03.2023 01:10, Bjorn Andersson wrote: >>>>>>> On Tue, Feb 14, 2023 at 10:54:35AM +0100, Konrad Dybcio wrote: >>>>>>>> The RPMhPD setup on SA8155P is different compared to SM8150. Correct >>>>>>>> it to ensure the platform will not try accessing forbidden/missing >>>>>>>> RPMh entries at boot, as a bad vote will hang the machine. >>>>>>>> >>>>>>> >>>>>>> I don't see that this will scale, as soon as someone adds a new device >>>>>>> in sm8150.dtsi that has the need to scale a power rail this will be >>>>>>> forgotten and we will have a mix of references to the SM8150 and SA8155P >>>>>>> value space. >>>>>>> >>>>>>> That said, I think it's reasonable to avoid duplicating the entire >>>>>>> sm8150.dtsi. >>>>>> Yeah, this problem has no obvious good solutions and even though it's >>>>>> not very elegant, this seems to be the less bad one.. >>>>>> >>>>>>> >>>>>>> How about making the SA8155P_* macros match the SM8150_* macros? >>>>>>> That way things will fail gracefully if a device node references a >>>>>>> resource not defined for either platform... >>>>>> Okay, let's do that >>>>> Re-thinking it, it's good that the indices don't match, as this way the >>>>> board will (should) refuse to function properly if there's an oversight, >>>>> which may have gone unnoticed if they were matching, so this only guards >>>>> us against programmer error which is not great :/ >>>>> >>>> >>>> Right, ensuring that the resource indices never collides would be a good >>>> way to capture this issue, as well as copy-paste errors etc. My >>>> pragmatic proposal is that we make SA8155P_x == SM8150_x where a match >>>> exist, and for the ones that doesn't match we pick numbers that doesn't >>>> collide between the platforms. >>>> >>>> The alternative is to start SA8155P_x at 11, but it's different and >>>> forces sa8155p.dtsi to redefine every single power-domains property... >>>> >>>> >>>> This does bring back the feeling that it was a mistake to include the >>>> platform name in these defines in the first place... Not sure if it's >>>> worth mixing generic defines into the picture at this point, given that >>>> we I don't see a way to use them on any existing platform. >>> TBF we could, think: >>> >>> sm1234_rpmpds[] = { >>> [CX] = &foobar1, >>> [CX_AO] = &foobar1_ao, >>> >>> [...] >>> >>> /* Legacy DT bindings */ >>> [SM1234_CX] = &foobar1, >>> [SM1234_CX_AO] = &foobar1_ao, >>> }; >>> >>> WDYT? >> >> Given that every platform got these defines different we'd have to start >> at the new generic list at 17 (which would throw away 136 bytes per >> platform), if we're going to allow the scheme for existing platforms. >> Which I don't fancy. >> >> It's not super-pretty to mix and match, but I think I would be okay >> switching to this scheme for new platforms. >> >> PS. We'd better prefix the defines with something (perhaps RPM_?) > Perhaps just VDD_{CX/MX/..}? We reference the rpm(h)pd's phandle > each time it's used, anyway. So, back to this patch.. do you want me to make any changes or should we take it as-is to fix 8155? Konrad > > Konrad >> >> Regards, >> Bjorn