Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp2186197imw; Wed, 6 Jul 2022 01:22:55 -0700 (PDT) X-Google-Smtp-Source: AGRyM1uNRvpyzEe5uR00jNkGrPcD9h3i0roX9HThXSRJM8ACVzirLOiCUSyAHQSt/9wA054ZJqsh X-Received: by 2002:a17:907:7216:b0:726:d5d5:917e with SMTP id dr22-20020a170907721600b00726d5d5917emr37466423ejc.768.1657095774878; Wed, 06 Jul 2022 01:22:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657095774; cv=none; d=google.com; s=arc-20160816; b=RpedT8ZYy7uBbWv91ri1+n5B40OqOAdjJ9Je3ApvtR/MajsaR4y4pcQUOEz052uMwU sMer9wJMH7Zg+uEjV1GJtu/R7iIXTBVx8O4bJUBSnnTkt2F3k9epWtVSH/tyWAwmgpmR xT9mt4xjb2WplLBvNEcDnAHuKTF3IsanxHfZ0pqHmI2hsAD3Da8UmtqfF8cODOxwr3xp +9WRZWSL8SDpM77ri+DLq5uWFcbVwJlYpok2e0OIRB8ZhogmrFe4PQMZ9H8mIiimWYHo HUF8kGO5pcOw45KY6708eScn90Ar2bpV/8hYPLW6oVhnNx/KcfDOML/pHQQDKkfQr8hx knHw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=lzcYvYnPsuWFBuxfk6Oeh1EnL0RO5R+NwkGeHVOod/o=; b=aB3hoJcSJq0Q2ipDk8Gf0Y5UUnFUpsonxImdeJi3GwzaOpLz2oKtPchPNGL8eWNIbM hhlYHS1+gNjdpIYXzeG2TS8AurA69nb3mhuoYoeJ8ccUFPvPc5e3qoFf6Kii8Hsp10NV 6xLfI8BZTxNMm2ZFX1h5RG3LgxhB3NL/JCdcODsATG1tb8boQMOLwMMo5lHwintzBkKJ yJTv2cQbR5MCIRUT1ojBZazDWDBx/Adx0zuOz3YV1BNAmcF3UmQAJeUka/hWTAku6bx3 O30Z2WrfZBXhK8TZC378aowUGoZxzbaGV5BKRDIyyWGol3qRcX1p7mRC/VjqlTrHWMqM jZXA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ho7-20020a1709070e8700b00726b8b2948csi36087025ejc.703.2022.07.06.01.22.30; Wed, 06 Jul 2022 01:22:54 -0700 (PDT) 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; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230030AbiGFIJ5 (ORCPT + 99 others); Wed, 6 Jul 2022 04:09:57 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51210 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229592AbiGFIJ4 (ORCPT ); Wed, 6 Jul 2022 04:09:56 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7971F18381; Wed, 6 Jul 2022 01:09:55 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3D6E51596; Wed, 6 Jul 2022 01:09:55 -0700 (PDT) Received: from [10.57.42.44] (unknown [10.57.42.44]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8F28C3F792; Wed, 6 Jul 2022 01:09:51 -0700 (PDT) Message-ID: Date: Wed, 6 Jul 2022 09:09:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1 Subject: Re: [PATCH V3 02/20] OPP: Make dev_pm_opp_set_regulators() accept NULL terminated list Content-Language: en-GB To: Viresh Kumar Cc: "Rafael J. Wysocki" , Chanwoo Choi , MyungJoo Ham , Kyungmin Park , Krzysztof Kozlowski , Alim Akhtar , Qiang Yu , Rob Herring , Tomeu Vizoso , Alyssa Rosenzweig , Nishanth Menon , Stephen Boyd , Thierry Reding , Jonathan Hunter , linux-pm@vger.kernel.org, Vincent Guittot , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, linux-samsung-soc@vger.kernel.org, linux-arm-kernel@lists.infradead.org, dri-devel@lists.freedesktop.org, lima@lists.freedesktop.org, linux-tegra@vger.kernel.org References: <9730e011004b7526e79c6f409f5147fb235b414a.1656935522.git.viresh.kumar@linaro.org> <48d865e8-6c0d-99c0-a43b-89793d5c3f85@arm.com> <20220705043439.xlrxusxrhwjupiyt@vireshk-i7> From: Steven Price In-Reply-To: <20220705043439.xlrxusxrhwjupiyt@vireshk-i7> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/07/2022 05:34, Viresh Kumar wrote: > On 04-07-22, 15:35, Steven Price wrote: >> I have to say the 'new improved' list ending with NULL approach doesn't >> work out so well for Panfrost. We already have to have a separate >> 'num_supplies' variable for devm_regulator_bulk_get() / >> regulator_bulk_{en,dis}able(), so the keeping everything in sync >> argument is lost here. >> >> I would suggest added the NULL on the end of the lists in panfrost_drv.c >> but then it would break the use of ARRAY_SIZE() to automagically keep >> the length correct... > > Actually we can still make it work. > >> For now the approach isn't too bad because Panfrost doesn't yet support >> enabling devfreq with more than one supply. But that array isn't going >> to work so nicely when that restriction is removed. >> >> The only sane way I can see of handling this in Panfrost would be >> replicating the loop to count the supplies in the Panfrost code which >> would allow dropping num_supplies from struct panfrost_compatible and >> then supply_names in the same struct could be NULL terminated ready for >> devm_pm_opp_set_regulators(). > > Or doing this, which will simplify both the cases. Yes the below works, it's just a bit ugly having the "- 1", and potentially easy to forgot when adding another. However I don't suppose it would get far in that case so I think it would be spotted quickly when adding a new compatible. It's probably the best solution at the moment. Thanks, Steve > > diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c b/drivers/gpu/drm/panfrost/panfrost_drv.c > index 7fcbc2a5b6cd..b3b55565b8ef 100644 > --- a/drivers/gpu/drm/panfrost/panfrost_drv.c > +++ b/drivers/gpu/drm/panfrost/panfrost_drv.c > @@ -625,24 +625,29 @@ static int panfrost_remove(struct platform_device *pdev) > return 0; > } > > -static const char * const default_supplies[] = { "mali" }; > +/* > + * The OPP core wants the supply names to be NULL terminated, but we need the > + * correct num_supplies value for regulator core. Hence, we NULL terminate here > + * and then initialize num_supplies with ARRAY_SIZE - 1. > + */ > +static const char * const default_supplies[] = { "mali", NULL }; > static const struct panfrost_compatible default_data = { > - .num_supplies = ARRAY_SIZE(default_supplies), > + .num_supplies = ARRAY_SIZE(default_supplies) - 1, > .supply_names = default_supplies, > .num_pm_domains = 1, /* optional */ > .pm_domain_names = NULL, > }; > > static const struct panfrost_compatible amlogic_data = { > - .num_supplies = ARRAY_SIZE(default_supplies), > + .num_supplies = ARRAY_SIZE(default_supplies) - 1, > .supply_names = default_supplies, > .vendor_quirk = panfrost_gpu_amlogic_quirk, > }; > > -static const char * const mediatek_mt8183_supplies[] = { "mali", "sram" }; > +static const char * const mediatek_mt8183_supplies[] = { "mali", "sram", NULL }; > static const char * const mediatek_mt8183_pm_domains[] = { "core0", "core1", "core2" }; > static const struct panfrost_compatible mediatek_mt8183_data = { > - .num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies), > + .num_supplies = ARRAY_SIZE(mediatek_mt8183_supplies) - 1, > .supply_names = mediatek_mt8183_supplies, > .num_pm_domains = ARRAY_SIZE(mediatek_mt8183_pm_domains), > .pm_domain_names = mediatek_mt8183_pm_domains, >