From: Lucas Stach <dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
To: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Cc: linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH 4/4] ARM: tegra: correct Colibri T20 regulator settings
Date: Tue, 23 Jul 2013 22:35:52 +0200 [thread overview]
Message-ID: <1374611752.1712.6.camel@tellur> (raw)
In-Reply-To: <51EEC669.9050703-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
Am Dienstag, den 23.07.2013, 11:07 -0700 schrieb Stephen Warren:
> On 07/21/2013 02:28 PM, Lucas Stach wrote:
> > Core and CPU voltage settings were a bit on the safe side. The actually
> > used chips on the Colibri allow for lower voltages and work just fine
> > this way.
>
> That sounds like a non-critical issue. Shouldn't that part be separated
> out into a patch for 3.12?
Hm, yes.
>
> > SM2 is not a the parent of LDO regs, but actually the DDR regulator. The
> > Colibri uses a different version of the TPS with other voltage mapping
> > tables for SM2, currently we cheat by setting a fake 3,2V which results
> > in 1,8V physical.
>
> That's quite unfortunate. Since DT is supposed to be an ABI, the
> existing DT should continue to work for arbitrary kernels, and the
> modified DT should also work for arbitrary kernels. Clearly that isn't
> possible if we start putting incorrect voltage values into the DT. Isn't
> there some way to make an isolated fix to the PMIC driver itself so that
> it actually programs the HW correctly? Even if that patch is larger than
> this patch, it still seems more likely to be acceptable for 3.11.
>
I'm a bit one the fence here. One the one hand it's a severe issue as
the DDR ram gets overvolted by a fair bit and should be fixed by putting
the correct voltage in the DT and getting this into stable. On the other
hand this will prevent older kernels from working correctly as with 1,8V
set on this rail the regulator driver will just plainly refuse to probe.
Thinking again about this maybe it really the best thing to get the DT
right first with CC stable and then changing the regulator driver and
try and see if stable also accepts this patch. I don't really want to
leave people with a supposedly working system, but constantly
overvolting their RAM.
> But is this a regression? If not, how far back in CC: stable should this
> change go?
This is not a regression. It was introduced with the original Colibri
T20 commit and was caused by Toradex not providing any schematics for
the Module plus me not physically checking this voltage rail before
pushing things out.
Regards,
Lucas
next prev parent reply other threads:[~2013-07-23 20:35 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-21 21:28 [PATCH 0/4] Colibri T20 fixes for 3.11 Lucas Stach
[not found] ` <1374442132-24040-1-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2013-07-21 21:28 ` [PATCH 1/4] ASOC: tegra: move AC97 clock defines to the controller node Lucas Stach
2013-07-21 23:36 ` Mark Brown
[not found] ` <20130721233651.GZ9858-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-22 7:08 ` Lucas Stach
2013-07-22 9:46 ` Mark Brown
[not found] ` <20130722094627.GK9858-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
2013-07-22 16:26 ` Lucas Stach
2013-07-24 9:44 ` Mark Brown
[not found] ` <1374442132-24040-2-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2013-07-23 16:47 ` Stephen Warren
[not found] ` <51EEB3A6.1060507-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-07-23 20:37 ` Lucas Stach
2013-07-21 21:28 ` [PATCH 2/4] ASOC: tegra: fix matching of AC97 components Lucas Stach
[not found] ` <1374442132-24040-3-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2013-07-23 16:49 ` Stephen Warren
2013-07-21 21:28 ` [PATCH 3/4] ARM: tegra: enable ULPI phy on Colibri T20 Lucas Stach
[not found] ` <1374442132-24040-4-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2013-07-23 16:53 ` Stephen Warren
2013-07-21 21:28 ` [PATCH 4/4] ARM: tegra: correct Colibri T20 regulator settings Lucas Stach
[not found] ` <1374442132-24040-5-git-send-email-dev-8ppwABl0HbeELgA04lAiVw@public.gmane.org>
2013-07-23 18:07 ` Stephen Warren
[not found] ` <51EEC669.9050703-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2013-07-23 20:35 ` Lucas Stach [this message]
2013-07-23 20:53 ` Stephen Warren
2013-07-28 22:06 ` Stefan Agner
2013-08-15 11:05 ` Thierry Reding
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=1374611752.1712.6.camel@tellur \
--to=dev-8ppwabl0hbeelga04laivw@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org \
/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