From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752668AbdATOcs (ORCPT ); Fri, 20 Jan 2017 09:32:48 -0500 Received: from foss.arm.com ([217.140.101.70]:53600 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752265AbdATOco (ORCPT ); Fri, 20 Jan 2017 09:32:44 -0500 Subject: Re: [PATCH v3 2/4] dt-bindings: Add TI SCI PM Domains To: Ulf Hansson , Rob Herring , Kevin Hilman References: <20170104205536.15963-1-d-gerlach@ti.com> <20170104205536.15963-3-d-gerlach@ti.com> <20170109175012.sg7eze7llqq7qevd@rob-hp-laptop> <7bd282d9-df6f-f4c6-1f7f-c8ed81c78af3@ti.com> <3bb89649-fd2a-acc6-6968-e54a00842ce2@ti.com> <84d7d49b-933b-8b26-f18a-3a5054738cb1@ti.com> <0eaa9914-83f1-7716-cf04-1e3dd44df647@ti.com> <4cb25cf9-216f-2e18-f45d-ef7e48fa6c5e@ti.com> Cc: Sudeep Holla , Tero Kristo , Dave Gerlach , "Rafael J . Wysocki" , "linux-arm-kernel@lists.infradead.org" , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" , "devicetree@vger.kernel.org" , Nishanth Menon , Keerthy , Russell King , Santosh Shilimkar , Lokesh Vutla From: Sudeep Holla Organization: ARM Message-ID: Date: Fri, 20 Jan 2017 14:18:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/01/17 14:00, Ulf Hansson wrote: > + Sudeep > > On 19 January 2017 at 00:03, Rob Herring wrote: >> >> We could continue to use the power domain binding (maybe we already >> are and that ship has sailed). I'm not totally against the idea even >> if there is no power domain, but I'm not sold on it either. If we do >> go this route, then I still say the id should be a cell in the >> power-domain phandle. >> >> Another option is create something new either common or TI SCI >> specific. It could be just a table of ids and phandles in the SCI >> node. I'm much more comfortable with an isolated property in one node >> than something scattered throughout the DT. > > To me, this seems like the best possible solution. > > However, perhaps we should also consider the SCPI Generic power domain > (drivers/firmware/scpi_pm_domain.c), because I believe it's closely > related. > To change the power state of a device, this PM domain calls > scpi_device_set|get_power_state() (drivers/firmware/arm_scpi.c), which > also needs a device id as a parameter. Very similar to our case with > the TI SCI domain. > > Currently these SCPI device ids lacks corresponding DT bindings, so > the scpi_pm_domain tries to work around it by assigning ids > dynamically at genpd creation time. > IIUC do you mean the binding for the power domain provider to have a list of domain ids ? If so yes, we don't have one. But the idea was to have the range to be continuous and create genpd for the complete range. Though the SCPI specification lacked a command to get the max. no. of domains supported. That's the reason we had to introduce the num-domains(*) which may be optional if we have firmware interface to obtain that information. -- Regards, Sudeep (*) P.S: but it has been considered for SCMI(which is an improvement and more flexible/extensible replacement/upgrade to SCPI) which will be released soon.