From: "Timo Sigurdsson" <public_timo.s@silentcreek.de>
To: robh+dt@kernel.org, pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, galak@codeaurora.org,
linux@arm.linux.org.uk, maxime.ripard@free-electrons.com,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-sunxi@googlegroups.com,
hdegoede@redhat.com
Cc: wens@csie.org
Subject: Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi
Date: Tue, 28 Jul 2015 11:02:09 +0200 (CEST) [thread overview]
Message-ID: <20150728090209.1D7BC6C80542@dd34104.kasserver.com> (raw)
In-Reply-To: <55B62768.6040403@redhat.com>
Hi,
Hans de Goede schrieb am 27.07.2015 14:43:
>>> I've a simular patch here:
>>>
>>> https://github.com/jwrdegoede/linux-sunxi/commit/6a30b7d5be6012b81e5e1439a444e41c0ac1afc1
>>>
>>> I did not submit this upstream yet as it is part of a series to enable the
>>> otg
>>> controller on the bananapi which needs axp-usb-power-supply support for which
>>> the actual powersupply driver changes are still pending.
>> Oops, I see. Are you planning to submit this for 4.3 or later?
>
> I plan to submit this for 4.3.
Ok, then I guess we can drop my patch.
>>> IMHO we should just stick with the standard operating points unless we know
>>> that there are stability issues with them (such as e.g. on the A10 OlinuxIno
>>> Lime).
>> I'd be fine with that as I don't have any stability issues with the lower
>> voltages. What about the 1008MHz operating point that I "reintroduced"? It was
>> dropped here [1] because there was no regulator support.
>
> That is in essence an overclocked setting, the max CPU voltage officially is
> 1.4V, I do not think that we should provide any overclocked settings in the
> official dts files. If people really want to overclock they will have to
> modify there dts themselves IMHO.
Personally, I would be fine with that. Even though I think, it might be good to
have them in the official files just for convenience and because people who are
used to the sunxi-3.4 kernels are used to having the 1008MHz opp (and it was in
mainline for a short while, too). For those who don't want to use that setting,
it's easier to limit the maximum in userspace compared to compiling a new
device tree blob. But I do understand your point, so I guess it's just
something that maintainers have to make a decision for. As I said, either way
is fine for me.
> > Can this be reenabled
>> on board level (which means overriding the defaults inherited from
>> sun7i-a20.dtsi) or should this be done at SOC level for all boards (which
>> means we have to add regulator nodes for all boards in the first place)?
>
> Technically this is possible, but I do not think that it is a good idea.
I guess the same applies here, too. It's something maintainers should have a
common understanding on. I don't know how much variation there is among the
A20 boards in terms of frequencies and voltages. If there is a lot, I'd say
it would be desireable to have board-specific opp. The downside I see in my
approach is that it impacts readability of the dts(i) files when settings
are overridden further down the tree.
Thanks and regards,
Timo
next prev parent reply other threads:[~2015-07-28 9:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-27 1:28 Timo Sigurdsson
2015-07-27 8:07 ` [linux-sunxi] " Hans de Goede
2015-07-27 12:09 ` public_timo.s
2015-07-27 12:43 ` Hans de Goede
2015-07-28 9:02 ` Timo Sigurdsson [this message]
2015-07-28 12:55 ` Maxime Ripard
2015-07-28 14:57 ` Timo Sigurdsson
2015-07-28 12:49 ` Maxime Ripard
2015-07-28 14:24 ` Hans de Goede
2015-07-28 15:09 ` Timo Sigurdsson
2015-07-28 15:29 ` Hans de Goede
2015-08-02 22:00 ` Timo Sigurdsson
2015-07-28 14:45 ` Timo Sigurdsson
2015-07-27 12:36 ` public_timo.s
2015-07-27 12:54 ` Hans de Goede
[not found] ` <CAGb2v65ApKvrj6K+kw43u=0q6=auTsmQjCXhibgZkW+vd5nDqA@mail.gmail.com>
2015-07-28 9:02 ` Timo Sigurdsson
2015-07-28 12:55 ` Maxime Ripard
2015-07-28 15:01 ` Timo Sigurdsson
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=20150728090209.1D7BC6C80542@dd34104.kasserver.com \
--to=public_timo.s@silentcreek.de \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=hdegoede@redhat.com \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sunxi@googlegroups.com \
--cc=linux@arm.linux.org.uk \
--cc=mark.rutland@arm.com \
--cc=maxime.ripard@free-electrons.com \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.org \
--cc=wens@csie.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
all inboxes | Powered by JetHome®