From: "H. Nikolaus Schaller" <hns@goldelico.com>
To: Tony Lindgren <tony@atomide.com>
Cc: "Adam Ford" <aford173@gmail.com>,
"André Roth" <neolynx@gmail.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>,
"Nishanth Menon" <nm@ti.com>
Subject: Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx
Date: Mon, 9 Sep 2019 20:11:13 +0200 [thread overview]
Message-ID: <F8F08882-8011-441C-9581-ECCE9772EC21@goldelico.com> (raw)
In-Reply-To: <E001F74D-724E-4C50-9265-CBD33C4F2918@goldelico.com>
> Am 09.09.2019 um 18:54 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
>
> Hi Tony,
>
>> Am 09.09.2019 um 18:32 schrieb Tony Lindgren <tony@atomide.com>:
>>
>> Hi,
>>
>> * H. Nikolaus Schaller <hns@goldelico.com> [190909 14:57]:
>>> Another question that came up by private mail from André was if we
>>> should better disable the turbo OPPs of omap34xx and 36xx by default
>>> (status = "disabled";) because there are concerns about overheating
>>> the chips and we have no thermal regulation like for omap4 & 5.
>>>
>>> But this would mean that every board DTS would have to set it explicitly
>>> to "enabled".
>>
>> Yes I started thinking about that too. I think there is a requirement
>> to do the scaling via the voltage processor for the higher modes.
>
> It depends on how you read the little footnotes...
>
> Table 4-18. Processor Voltages Without SmartReflex:
>
> • This table defines the safe VDD1 (vdd_mpu_iva) voltage ranges to be used before using the SmartReflex AVS feature for OPPs calibration.
> • Values are defined when SmartReflexTM feature is deactivated. They can be lower when SmartReflexTM is activated.
> • OPP130 and OPP1G are not available above TJ of 90C.
> • (6) OPP1G is a high performance operating point which has following requirements:
> • – ABB LDO must be set to FBB (Forward Body Bias) mode when switching to this OPP. It requires having a 1 F capacitor connected to cap_vdd_bb_mpu_iva.
> • – AVS (Adaptive Voltage Scaling) power technique must be used to achieve optimum operating voltage.
>
> So I read this as:
>
> * OPP130 and OPP1G should be guarded by 90°C thermal framework
> * OPP1G should also set the ABB LDO to FBB mode
> * AVS does only reduce voltage levels (to save energy = heat = problem)
> * only if we want "optimum operating voltage" (read as: "lowest possible voltage" = "highest energy saving") we must use AVS
>
> I.e. we do not necessarily need AVS or SmartReflex or help from the
> twl4030 (except for changing the voltage).
>
>> And there needs to be some way to automatically change to a lower
>> OPP in some cases.
>
> That should probably be done through the thermal framework like
> on omap4 & omap5?
>
>>
>> For normal OPPs, using the twl regulator directly should be OK.
>
> Maybe for the turbo OPPs as well.
>
>> For the higher modes, maybe we could pass the callback functions
>> from arch/arm/mach-omap2/voltage.c for the twl regulator so the
>> voltage processor hardware can handle them directly. Or add a
>> separate regulator driver operating the voltages like Nishanth
>> posted patches for earlier.
>
> So in my (limited) understanding it would suffice to set the ABB LDO
> to FBB mode for OPP1G.
Ok, we have to check if the ti,abb-v2 "LDO" driver
drivers/regulator/ti-abb-regulator.c
can handle that with a DT entry similar to:
https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/omap5.dtsi#L365
Needs a little time to add to a new version of the patch set.
> And make sure that the TJ does not exceed 90°C by reducing the cpufreq
> through the thermal framework. But: the thermal sensors of the omap3
> are quite odd (they seem to jump up by 10° after first use).
I'll leave this out for the moment for future study.
BR and thanks,
Nikolaus
next prev parent reply other threads:[~2019-09-09 18:11 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 ` [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx H. Nikolaus Schaller
2019-09-09 14:26 ` 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 [this message]
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=F8F08882-8011-441C-9581-ECCE9772EC21@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=nm@ti.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).