From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Adam Ford <aford173@gmail.com>
Cc: "André Roth" <neolynx@gmail.com>,
"Tony Lindgren" <tony@atomide.com>,
Linux-OMAP <linux-omap@vger.kernel.org>,
"Discussions about the Letux Kernel"
<letux-kernel@openphoenux.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Andreas Kemnade" <andreas@kemnade.info>
Subject: Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
Date: Sat, 7 Sep 2019 09:37:39 +0200 [thread overview]
Message-ID: <FA2920FE-B76A-4D44-A264-862A1CCBF7FC@goldelico.com> (raw)
In-Reply-To: <CAHCN7xLW58ggx3CpVL=HdCVHWo6D-MCTB91A_9rtSRoZQ+xJuQ@mail.gmail.com>
Hi Adam,
> Am 02.09.2019 um 23:10 schrieb Adam Ford <aford173@gmail.com>:
>
> On Mon, Sep 2, 2019 at 10:46 AM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>>
>>
>>
>> But my tests show that decoding works now. So you already might give it a try.
>
> I am traveling all this week, but I have an omap3530, DM3730
> (omap3630), and an AM3517 that I use for testing.
now as the omap3430 and omap3630 opp-v2 tables are installed,
we could add am35x7 as well.
What needs to be done:
1. add OPP-v2 table to am3517.dtsi
for example copy skeleton from omap36xx.dtsi
and define reasonable clock speeds. I would think about
150 MHz, 300 MHz, 600MHz.
Debatable is if we need a clock-latency definition.
2. change all voltages to 1.2V
opp-microvolt = <1200000 1200000 1200000>;
There is no point to specify 3 voltages <target min max> here since we
will never need a min and a max value.
opp-microvolt = <1200000>;
should also be ok (AFAIK, parser handles single-value records).
3. AFAIK there is no speed binned eFuse...
But the ti-cpufreq driver always wants to read some eFuse register.
So please check if you can read 0x4800244C and 0x4830A204
like on omap36xx and if they produce stable values (and not
random noise).
If yes, we simply assume that am3517 is similar enough to omap3630,
ignore that there is no eFuse, but read the register anyways and
then ignore the bit if it is 0 or 1.
This means that all OPPs can get
opp-supported-hw = <0xffffffff 0xffffffff>;
There could also be a default handler if this property is missing,
but I have not researched this.
4. add compatible to ti-cpufreq
and share the register offsets, bit masks etc. with omap3630:
{ .compatible = "ti,am33xx", .data = &am3x_soc_data, },
{ .compatible = "ti,am3517", .data = &omap36xx_soc_data, },
{ .compatible = "ti,am43", .data = &am4x_soc_data, },
{ .compatible = "ti,dra7", .data = &dra7_soc_data },
{ .compatible = "ti,omap3430", .data = &omap34xx_soc_data, },
{ .compatible = "ti,omap3630", .data = &omap36xx_soc_data, },
5. configure for CONFIG_ARM_TI_CPUFREQ=y
This should IMHO suffice.
Since I can't test anything I can't define working OPP points
and therefore I can't provide patches myself. Hope you can make
it work this way.
BR,
Nikolaus
next parent reply other threads:[~2019-09-07 7:38 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190801012823.28730-1-neolynx@gmail.com>
[not found] ` <CAHCN7x+nD0J6KZYtfH+0ApQTPO5byO2obMkUwc9Uf4WubyRbTw@mail.gmail.com>
[not found] ` <C04F49BA-1229-4E96-9FCF-4FC662D1DB11@goldelico.com>
[not found] ` <CAHCN7x+Ye6sB_YqO0sAX1OJDw64B-qGS3pL545v3Xk5z914cwQ@mail.gmail.com>
[not found] ` <0C1EF64E-B33C-4BFA-A7D3-471DD1B9EE86@goldelico.com>
[not found] ` <515048DE-138D-4400-8168-F2B7D61F1005@goldelico.com>
[not found] ` <CAHCN7xLPCX9rZ0+7KVBiA_bgZ6tg6VeCXqD-UXu+6iwpFMPVrA@mail.gmail.com>
[not found] ` <7B3D1D77-3E8C-444F-90B9-6DF2641178B8@goldelico.com>
[not found] ` <CAHCN7xLW58ggx3CpVL=HdCVHWo6D-MCTB91A_9rtSRoZQ+xJuQ@mail.gmail.com>
2019-09-07 7:37 ` H. Nikolaus Schaller [this message]
2019-09-09 14:26 ` [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx Adam Ford
2019-09-09 14:56 ` H. Nikolaus Schaller
2019-09-09 16:20 ` Adam Ford
2019-09-09 16:32 ` Adam Ford
2019-09-09 16:32 ` Tony Lindgren
2019-09-09 16:38 ` Adam Ford
2019-09-09 17:03 ` H. Nikolaus Schaller
2019-09-09 16:54 ` H. Nikolaus Schaller
2019-09-09 18:11 ` H. Nikolaus Schaller
2019-09-09 19:13 ` Adam Ford
2019-09-10 16:59 ` H. Nikolaus Schaller
2019-09-10 18:30 ` Adam Ford
2019-09-10 18:51 ` H. Nikolaus Schaller
2019-09-10 19:26 ` H. Nikolaus Schaller
2019-09-10 19:36 ` Adam Ford
2019-09-10 19:55 ` H. Nikolaus Schaller
2019-09-10 20:06 ` Adam Ford
2019-09-11 0:24 ` Adam Ford
2019-09-11 0:41 ` Adam Ford
2019-09-11 5:13 ` H. Nikolaus Schaller
2019-09-11 6:03 ` H. Nikolaus Schaller
2019-09-11 6:49 ` H. Nikolaus Schaller
2019-09-11 12:43 ` Adam Ford
2019-09-11 15:46 ` H. Nikolaus Schaller
2019-09-11 15:56 ` Adam Ford
2019-09-11 16:01 ` H. Nikolaus Schaller
2019-09-11 17:43 ` H. Nikolaus Schaller
2019-09-11 17:49 ` Adam Ford
2019-09-12 13:58 ` Adam Ford
2019-09-12 18:52 ` Adam Ford
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=FA2920FE-B76A-4D44-A264-862A1CCBF7FC@goldelico.com \
--to=hns@goldelico.com \
--cc=aford173@gmail.com \
--cc=andreas@kemnade.info \
--cc=letux-kernel@openphoenux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=neolynx@gmail.com \
--cc=tony@atomide.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).