Date: Tue, 28 Jul 2015 14:55:00 +0200
From: Maxime Ripard <maxime.ripard@free-electrons.com>
To: Timo Sigurdsson <public_timo.s@silentcreek.de>
Cc: 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, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org,
        linux-sunxi@googlegroups.com, hdegoede@redhat.com, wens@csie.org
Subject: Re: [linux-sunxi] [RFC] ARM: dts: sunxi: Add regulators and
 board-specific operating points for LeMaker BananaPi
Message-ID: <20150728125500.GB2564@lukather>
References: <1437960486-2809-1-git-send-email-public_timo.s@silentcreek.de>
 <55B5E6DB.8020009@redhat.com>
 <20150727120918.191F76C82FB4@dd34104.kasserver.com>
 <55B62768.6040403@redhat.com>
 <20150728090209.1D7BC6C80542@dd34104.kasserver.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="L5xhH6lUAPIS347H"
Content-Disposition: inline
In-Reply-To: <20150728090209.1D7BC6C80542@dd34104.kasserver.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 4823
Lines: 130


--L5xhH6lUAPIS347H
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jul 28, 2015 at 11:02:09AM +0200, Timo Sigurdsson wrote:
> Hi,
>=20
> Hans de Goede schrieb am 27.07.2015 14:43:
> >>> I've a simular patch here:
> >>>
> >>> https://github.com/jwrdegoede/linux-sunxi/commit/6a30b7d5be6012b81e5e=
1439a444e41c0ac1afc1
> >>>
> >>> I did not submit this upstream yet as it is part of a series to enabl=
e the
> >>> otg
> >>> controller on the bananapi which needs axp-usb-power-supply support f=
or which
> >>> the actual powersupply driver changes are still pending.
> >> Oops, I see. Are you planning to submit this for 4.3 or later?
> >=20
> > I plan to submit this for 4.3.
>
> Ok, then I guess we can drop my patch.

Please don't.

> >>> IMHO we should just stick with the standard operating points unless w=
e know
> >>> that there are stability issues with them (such as e.g. on the A10 Ol=
inuxIno
> >>> Lime).
> >> I'd be fine with that as I don't have any stability issues with the lo=
wer
> >> voltages. What about the 1008MHz operating point that I "reintroduced"=
? It was
> >> dropped here [1]  because there was no regulator support.
> >=20
> > That is in essence an overclocked setting, the max CPU voltage official=
ly 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.
>=20
> 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).

It was used in mainline, and reverted because it was not stable
enough.

There's a lot of things we do differently in mainline, it's one of
them. If someone can provide an OPP for 1008MHz that is stable for all
the boards and within the operating limits of the SoC, I'd be totally
fine with that, but we didn't find it so far.

> 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.

Except that the kernel should not rely on the userspace to be stable
and harmless for the hardware. It should just work reliably by itself.

> 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.
>=20
> > > 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 (wh=
ich
> >> means we have to add regulator nodes for all boards in the first place=
)?
> >=20
> > Technically this is possible, but I do not think that it is a good idea.
>=20
> I guess the same applies here, too. It's something maintainers should hav=
e a
> common understanding on. I don't know how much variation there is among t=
he
> A20 boards in terms of frequencies and voltages.

If you look at the FEX file, a lot. But most of them are just
variations of the same OPP.

I value much more a set of OPPs that has been tested on a wide range
of device, that we know are working reliably on all of them, over a
FEX file providing a set of OPPs that for some of them have never even
been tested before because the 3.4 kernel simply ignored them.

Maxime

--=20
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

--L5xhH6lUAPIS347H
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJVt3ukAAoJEBx+YmzsjxAgyjgP/Aw5rA3eiQvs3ZtQrJ+I2D9b
qFogoDaLSChhl7+M8nVSxrm4HSybii4e7YNP3KDHKXLm1XTwoBVZlaQndaEL0EDD
IcdMj848cuFi4tt70n+6KcLdTbAaQiPUoQkeW4VNWwIpeK1Qg2rZB2B1cPbEls/E
1gyqVIGUejzDa7FXOn/Sy2VBzofJYkvqg7dvd8UwEbEImpFdgAsclbPsW4wpPZXe
Cd8hMBKHVvYHExLOsdTH3IzwM+Oc6iAkA9CZ50hU7C4ox68GFamuahvHEhywLfcP
xwscSTytHmHs/R5UnU4TjskU9UiuY80IDFN+SFWLL5ie0TV0NT0wSboXyWyKJiR1
lVOoISShh7bCWowiobfOCKk+Mj9PKGS4w04XtsngAYuRNzTrJWDfOU2Jw867J7MH
dL6N91NVf0LZKttYZt21uLQ0px0w9TGf4vKqIY0pqh3FSuMnz7HJ/nCShsvqH1Iv
09FDF+FWNh9GwLNDonFsGdIit/WrbZG3+rr6ZEkHW8TYFvMXOoq4PUra+Kal9+Vj
Z/RQ01YWWCYQuWbGb/55MSSW3uCjWeZ6RM7Qv1SEZwkZaQkDZoT++G7qisqSL8jj
UdY7oSlGOjDaJuQDC4mhv8yXCH3T6MbYCxbIlq5s1Ir+xpi1F/wmTwl6HFBKrXW/
Ze0ajvzYK7hOBIhRj/zI
=mZ7U
-----END PGP SIGNATURE-----

--L5xhH6lUAPIS347H--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/