[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ce75662b-20ee-a879-5004-57d6cc2c29a5@arm.com>
Date: Fri, 15 Jun 2018 14:27:15 +0100
From: Sudeep Holla <sudeep.holla@....com>
To: Amit Kucheria <amit.kucheria@...durent.com>,
Taniya Das <tdas@...eaurora.org>
Cc: Sudeep Holla <sudeep.holla@....com>,
LKML <linux-kernel@...r.kernel.org>,
Linux PM list <linux-pm@...r.kernel.org>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Viresh Kumar <viresh.kumar@...aro.org>,
Stephen Boyd <sboyd@...nel.org>,
Rajendra Nayak <rnayak@...eaurora.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, Rob Herring <robh@...nel.org>,
Saravana Kannan <skannan@...eaurora.org>
Subject: Re: [PATCH v4 1/2] dt-bindings: cpufreq: Introduce QCOM CPUFREQ FW
bindings
On 15/06/18 12:59, Amit Kucheria wrote:
> On Thu, Jun 14, 2018 at 9:24 PM, Taniya Das <tdas@...eaurora.org> wrote:
>
[...]
>>
>> Yes I do understand the intent of mapping the whole register space, but as
>> per the HW specs these 3 registers would be the only ones required for now.
>> I do not think this hardware engine has any information on the power
>> numbers.
>
> "For now" - I think this is exactly the point that Sudeep is trying to make.
>
> A future version of the HW engine, or more likely, a firmware
> revision, will make more functionality available. Say, this needs
> access to another register or two. This will require changing the DT
> bindings. Instead, if you map the entire address space, you can just
> add offsets to the new registers.
>
> So in this case, I think you should define the following addresses
> (size 0x1400) for the two frequency domains
>
> 0x17d43000, 0x1400 (power cluster)
> 0x17d45800, 0x1400 (perf cluster)
>
> And in the driver simply add offsets as follows:
>
> #define ENABLE_OFFSET 0x0
> #define LUT_OFFSET 0x110
> #define PERF_DESIRED_OFFSET 0x920
>
> This will allow you add any new registers in the future w/o modifying
> the DT binding and reduce qcom_cpu_resources_init() to a handful of
> lines since you no longer need so many OF string matches, and
> devm_ioremap()s.
>
Thanks Amit for such nice and detailed explanation. I was lazy to write
in such details, but was hoping Taniya to understand the point. Anyways
thanks again for doing this.
--
Regards,
Sudeep
Powered by blists - more mailing lists