devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>,
	Maxime Ripard
	<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
Cc: linux-sunxi <linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>,
	devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	linux-arm-kernel
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Including empty regulator nodes in axp209.dtsi is a BAD idea
Date: Tue, 13 Jan 2015 10:39:01 +0100	[thread overview]
Message-ID: <54B4E7B5.6060304@redhat.com> (raw)

Hi ChenYu, Maxime,

During the review of a few dts files for new boards Maxime asked me to use
axp209.dtsi to avoid the standard axp209 "boilerplate" present in most
boards using the axp209 pmic.

But axp209.dtsi includes empty regulator nodes, e.g. :

                 reg_dcdc3: dcdc3 {
                         regulator-name = "dcdc3";
                 };

This is a BAD idea, the presence of these empty nodes causes the
axp20x-regulator driver to actually register regulators for them,
and then on late_init the regulator subsys turns them off, since
they have absolutely no constraints set (nor users registered)
and the regulator subsys assumes that when devicetree is used their
is always a compete set of constraints and that thus turning them
off is safe.

So when I switched to using axp209.dtsi for the bananapro.dts,
and booted the bananapro this is the last message I got from the
kernel while booting:

[    2.314014] dcdc3: disabling

And away went our DRAM power-supply, oops.

So for dcdc2 (CPU) and dcdc3 (DRAM), the boilerplate
should contain reasonable constraints (eg the operating range
from the datasheet) and an always-on property.

The ldo-s are trickier, since we simply do not know how those
are used, I think ldo2 is used for Avcc on most boards, so it
too should be always on, since almost any board will have some
analog parts on it (be it the ir receiver, lradc, rtp, lvds, vga,
or analog audio in/out). Assuming that we're willing to assume
that ldo2 is used this way, we should give it matching constraints
and always mark it always-on.

As for ldo3 - 5 I've no idea when / for what these are used, but
if we do not know it is better to just leave them be then to turn
them off IMHO, so we should remove the nodes for these from axp209.dtsi

Anyways sorting this all out is going to take some time, so I'm
not going to use axp209.dtsi in dts files for new boards for now.

Regards,

Hans

             reply	other threads:[~2015-01-13  9:39 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-13  9:39 Hans de Goede [this message]
     [not found] ` <54B4E7B5.6060304-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-01-13 16:46   ` Including empty regulator nodes in axp209.dtsi is a BAD idea Maxime Ripard
2015-01-14  7:42     ` Hans de Goede
     [not found]       ` <54B61DD3.6010105-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2015-01-14  8:11         ` Michal Suchanek
2015-01-15 16:54         ` Chen-Yu Tsai
     [not found]           ` <CAGb2v67uGV2HBKciRVGhf-vb7K=whruiaUvv8L7Lqz=8=kBnQQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-15 22:04             ` Maxime Ripard
2015-01-16  0:58               ` Chen-Yu Tsai
2015-01-16  7:42               ` Hans de Goede
2015-01-15 21:57         ` Maxime Ripard
2015-01-14 10:18     ` Lars Doelle
     [not found]       ` <5312007.HNApKlEIe7-01DtBWzyqXQXpj0+iOhflA@public.gmane.org>
2015-01-15 16:48         ` Chen-Yu Tsai
     [not found]           ` <CAGb2v66Go1z-V8spwHvLHQC1R=vgDsk1nQ6iZWTsy+OMF1kK0w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-01-15 21:51             ` Maxime Ripard
2015-01-15 23:41             ` Lars Doelle

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=54B4E7B5.6060304@redhat.com \
    --to=hdegoede-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org \
    --cc=maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org \
    --cc=wens-jdAy2FN1RRM@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;
as well as URLs for NNTP newsgroup(s).