Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp625610pxu; Fri, 23 Oct 2020 09:15:00 -0700 (PDT) X-Google-Smtp-Source: ABdhPJz9yutB+D3NiEd7EMCiaPOpaXyrMNUpxIh5gBvjr3UViFqNnyER2TXyuY1hY6bhHEXMG4x6 X-Received: by 2002:a05:6402:1586:: with SMTP id c6mr3004004edv.84.1603469700585; Fri, 23 Oct 2020 09:15:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603469700; cv=none; d=google.com; s=arc-20160816; b=nwDiGfhHVuLiHJLjxtGLdgy8dqlBQ7rCiUyvoWsKul/Wf2feKYVm/cwkZ3Z+MV8uhN uVCC/mDD2BEDEYMfCOZcgp5Sv4mxMRuwcExElCe9fpOAs6NEBcEm8zqSgvAi0ctAbc9v iPDypSYQeNsPKm6ayuAOghedYgtQFlRQzMcgfkQFVfNiOrSthtlK1bb3ilKQlkgb/3Zv RiT31F/EANejUv17oAGGsMOVCaOhAXle0EZHe/DGxO2W9VXpAl4J+1b66e9ZWRZBDtdO vquHPMCgneKu7kPSt1Ln4/l41mkeWGzwkTmnDqqwQD2iMRbQ1SErYF648LMk3TxnxQAG TJXA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=k/3N5XqKnBBsZDEPGWHNbJO+GCcGlLcInObzuHIt6Qs=; b=0uQwUoLail2JmWfCtcIDJejDlQZzFNXzFs0k42SbxNX0xmK64p9Pv+PDIcPz+MQFkv urZoZ6DNgWDLd+DmdznCNc48bwYg3/3cbWALXh7jKgWHakTM+pRXExhFGKCdv+tD47NH RJ3STBjLALwjQWsOpPtLcmlTtoqcgw1XQDHSGoAYitM01uO1nIVDP9VOZcgGKIStZd+q iO7DHd7jnDcwOARwbMhmQ0WtVqavDmyL6nc/dYV9S+ujtVt++A4sdjNbiS2Bep8GdKQn yuoAdKhF2nIqBZ1L7OsStJ8xsVhgcr5rbiHkSCiFEop6UnNzv7g1ndY0/iJVJb9rA3WN nt8w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lf16si1183820ejb.280.2020.10.23.09.14.36; Fri, 23 Oct 2020 09:15:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S1750195AbgJWN7J (ORCPT + 99 others); Fri, 23 Oct 2020 09:59:09 -0400 Received: from foss.arm.com ([217.140.110.172]:53388 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750190AbgJWN7J (ORCPT ); Fri, 23 Oct 2020 09:59:09 -0400 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 BFE69113E; Fri, 23 Oct 2020 06:59:08 -0700 (PDT) Received: from bogus (unknown [10.57.15.80]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 20BEA3F66B; Fri, 23 Oct 2020 06:59:06 -0700 (PDT) Date: Fri, 23 Oct 2020 14:59:04 +0100 From: Sudeep Holla To: Rob Herring Cc: "linux-kernel@vger.kernel.org" , devicetree@vger.kernel.org, Sudeep Holla , linux-arm-kernel , Viresh Kumar Subject: Re: [PATCH v2 1/2] dt-bindings: arm,scmi: Do not use clocks for SCMI performance domains Message-ID: <20201023135904.ayqznoxocxsvwl6v@bogus> References: <20201021183104.27949-1-sudeep.holla@arm.com> <20201022182233.hklq6j5n5kkqg4yv@bogus> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Oct 23, 2020 at 08:24:06AM -0500, Rob Herring wrote: > On Thu, Oct 22, 2020 at 1:22 PM Sudeep Holla wrote: > > > > On Wed, Oct 21, 2020 at 07:31:03PM +0100, Sudeep Holla wrote: > > > Commit dd461cd9183f ("opp: Allow dev_pm_opp_get_opp_table() to return > > > -EPROBE_DEFER") handles -EPROBE_DEFER for the clock/interconnects within > > > _allocate_opp_table() which is called from dev_pm_opp_add and it > > > now propagates the error back to the caller. > > > > > > SCMI performance domain re-used clock bindings to keep it simple. However > > > with the above mentioned change, if clock property is present in a device > > > node, opps can't be added until clk_get succeeds. So in order to fix the > > > issue, we can register dummy clocks which is completely ugly. > > > > > > Since there are no upstream users for the SCMI performance domain clock > > > bindings, let us introduce separate performance domain bindings for the > > > same. > > > > > > Signed-off-by: Sudeep Holla > > > --- > > > .../devicetree/bindings/arm/arm,scmi.txt | 19 ++++++++++++++++--- > > > 1 file changed, 16 insertions(+), 3 deletions(-) > > > > > > v1[1]->v2: > > > - Changed the generic #perf-domain-cells to more SCMI specific > > > property #arm,scmi-perf-domain-cells > > > > > > > Is more specific #arm,scmi-perf-domain-cells acceptable ? > > Sorry for the rush, but this fixes SCMI cpufreq which is broken after > > commit dd461cd9183f ("opp: Allow dev_pm_opp_get_opp_table() to return > > -EPROBE_DEFER") > > If you are in a rush, you'd better go the dummy clock route. We should > get this binding right and I think that means something common, not > SCMI specific. > Ah OK, I assumed you wanted to make it SCMI specific. It makes sense to have something generic like clocks for OPP domains. There was discussion on the other thread to use empty OPP list for firmware discoverable OPP list. Random thought here is to add domain ID to OPP binding and use that ? -- Regards, Sudeep