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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7B2EFC55179 for ; Fri, 23 Oct 2020 14:27:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 31BF620780 for ; Fri, 23 Oct 2020 14:27:38 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750594AbgJWO1h (ORCPT ); Fri, 23 Oct 2020 10:27:37 -0400 Received: from foss.arm.com ([217.140.110.172]:53910 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750553AbgJWO1f (ORCPT ); Fri, 23 Oct 2020 10:27:35 -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 5A6F1113E; Fri, 23 Oct 2020 07:27:34 -0700 (PDT) Received: from bogus (unknown [10.57.15.80]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D1E9C3F66B; Fri, 23 Oct 2020 07:27:32 -0700 (PDT) Date: Fri, 23 Oct 2020 15:27:30 +0100 From: Sudeep Holla To: Rob Herring Cc: "linux-kernel@vger.kernel.org" , devicetree@vger.kernel.org, linux-arm-kernel , Sudeep Holla , Viresh Kumar Subject: Re: [PATCH 1/2] dt-bindings: arm,scmi: Do not use clocks for SCMI performance domains Message-ID: <20201023142730.ru4rfoj3atxyinww@bogus> References: <20201020203710.10100-1-sudeep.holla@arm.com> <20201021181951.xu2igea2qbca3alf@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:34:05AM -0500, Rob Herring wrote: > On Wed, Oct 21, 2020 at 1:19 PM Sudeep Holla wrote: > > > > On Wed, Oct 21, 2020 at 11:20:27AM -0500, Rob Herring wrote: > > > On Tue, Oct 20, 2020 at 3:37 PM Sudeep Holla wrote: > > > > > > > > [...] > > > > > > > > When is this not 1 (IOW, you only need this if variable)? How would it > > > be used outside SCMI (given it has a generic name)? > > > > > > > + > > > > +* Property arm,scmi-perf-domain > > > > > [...] > > > > > Really though, why can't you give SCMI a CPUs MPIDR and get its domain? > > > > > > > Now I remembered why we can't use MPIDR. The spec talks about perf domains > > for devices in generic. CPU is just a special device. We will still need > > a mechanism to get device performance domain. So MPIDR idea was dropped to > > keep it uniform across all the devices. > > What implications to the binding are there for non-CPU devices? Do > they need more cells? How does this integrate our plethora of other PM > related bindings? > Ideally it is just a device perf domain ID. SCMI f/w will just assign perf domain IDs for both CPUs and other devices like GPUs sequentially without any distinction. However, I can't speak about other aspects of PM especially on wild variety of platforms we have on Arm. Today even with SCMI each device/cpu needs to track clock or performance, reset, power, voltage, ...etc domains and their IDs needs to be passed via DT. We are thinking of making all these device ID centric in future. It means if the device tree had scmi device ID for each of them, we must be able to perform any power management or configuration management on that device. SCMI f/w must then abstract everything at device level. Just a thought as of now and it aligns with some of the ACPI concepts. > So somewhere in the firmware we're defining device X is domain 0, > device Y is domain 1, etc. Then we do this again in DT. Seems fragile > to define this information twice. I guess that's true for any number > space SCMI defines. > Correct and agreed on your point. Any ideas to make this discoverable ? Atleast with SCMI, we have been able to reduce the amount of information just to that ID(though there are multiple ID space today for each aspects of PM and config management). As I mentioned we would like to make it device centric. Any thoughts on making IDs discoverable is appreciated. We thought about names and other things during initial days of the spec evolution, but we circled back to how does OS provide that info and we go back to DT/ACPI which was not too bad at that time. We can see if we can improve anything there. -- Regards, Sudeep 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 X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 58348C4363A for ; Fri, 23 Oct 2020 14:29:29 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id A014221527 for ; Fri, 23 Oct 2020 14:29:28 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="ruTSoeAo" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A014221527 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject:To:From:Date:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=u6Gv7yaLKO7pHIkqe0i5/7i1spCl8c9WqErsdj+EAqk=; b=ruTSoeAoqIV+ZZ5967flqCGA8 BJp5NbipmPGzZv2ZGH/GL2J806u414GsgXDWrXfVVbUzegciPTjALSlLaHseaP6dK93M+e61Vk0Fp zO86O/vMkhEWhMvsKsGbqTIJBC0U4jnc4eG2ahCWJgNLYjSZE6+ER6brWK8RsbvvCGhe9bjPD6tYu m0uKQf7h5dnEZc7aqcz743GhX8+4Ofx1XFhkRmyLKV/G2kMe6Yn6FO8WUGcnRjBw19gyU5NDS4FZT /POSjAujvKUUn9BMP9CVPlDzsLRpJUBGauenTv+PG+7tyLX+y6qUS6S0LsZWMgJyjTaqS0T2L9ftN syCliFgcw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVy2d-0002JB-Fs; Fri, 23 Oct 2020 14:27:39 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kVy2a-0002Ia-DB for linux-arm-kernel@lists.infradead.org; Fri, 23 Oct 2020 14:27:37 +0000 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 5A6F1113E; Fri, 23 Oct 2020 07:27:34 -0700 (PDT) Received: from bogus (unknown [10.57.15.80]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id D1E9C3F66B; Fri, 23 Oct 2020 07:27:32 -0700 (PDT) Date: Fri, 23 Oct 2020 15:27:30 +0100 From: Sudeep Holla To: Rob Herring Subject: Re: [PATCH 1/2] dt-bindings: arm,scmi: Do not use clocks for SCMI performance domains Message-ID: <20201023142730.ru4rfoj3atxyinww@bogus> References: <20201020203710.10100-1-sudeep.holla@arm.com> <20201021181951.xu2igea2qbca3alf@bogus> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201023_102736_534795_B677FC59 X-CRM114-Status: GOOD ( 25.14 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: devicetree@vger.kernel.org, Viresh Kumar , "linux-kernel@vger.kernel.org" , linux-arm-kernel , Sudeep Holla Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Oct 23, 2020 at 08:34:05AM -0500, Rob Herring wrote: > On Wed, Oct 21, 2020 at 1:19 PM Sudeep Holla wrote: > > > > On Wed, Oct 21, 2020 at 11:20:27AM -0500, Rob Herring wrote: > > > On Tue, Oct 20, 2020 at 3:37 PM Sudeep Holla wrote: > > > > > > > > [...] > > > > > > > > When is this not 1 (IOW, you only need this if variable)? How would it > > > be used outside SCMI (given it has a generic name)? > > > > > > > + > > > > +* Property arm,scmi-perf-domain > > > > > [...] > > > > > Really though, why can't you give SCMI a CPUs MPIDR and get its domain? > > > > > > > Now I remembered why we can't use MPIDR. The spec talks about perf domains > > for devices in generic. CPU is just a special device. We will still need > > a mechanism to get device performance domain. So MPIDR idea was dropped to > > keep it uniform across all the devices. > > What implications to the binding are there for non-CPU devices? Do > they need more cells? How does this integrate our plethora of other PM > related bindings? > Ideally it is just a device perf domain ID. SCMI f/w will just assign perf domain IDs for both CPUs and other devices like GPUs sequentially without any distinction. However, I can't speak about other aspects of PM especially on wild variety of platforms we have on Arm. Today even with SCMI each device/cpu needs to track clock or performance, reset, power, voltage, ...etc domains and their IDs needs to be passed via DT. We are thinking of making all these device ID centric in future. It means if the device tree had scmi device ID for each of them, we must be able to perform any power management or configuration management on that device. SCMI f/w must then abstract everything at device level. Just a thought as of now and it aligns with some of the ACPI concepts. > So somewhere in the firmware we're defining device X is domain 0, > device Y is domain 1, etc. Then we do this again in DT. Seems fragile > to define this information twice. I guess that's true for any number > space SCMI defines. > Correct and agreed on your point. Any ideas to make this discoverable ? Atleast with SCMI, we have been able to reduce the amount of information just to that ID(though there are multiple ID space today for each aspects of PM and config management). As I mentioned we would like to make it device centric. Any thoughts on making IDs discoverable is appreciated. We thought about names and other things during initial days of the spec evolution, but we circled back to how does OS provide that info and we go back to DT/ACPI which was not too bad at that time. We can see if we can improve anything there. -- Regards, Sudeep _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel