From: Heiko Stuebner <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
To: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
Cc: mark.rutland-5wv7dgnIgG8@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Eddie Cai
<eddie.cai.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Subject: Re: [PATCH] ARM: dts: rockchip: correct regular setting for act8846
Date: Wed, 24 May 2017 13:34:36 +0200 [thread overview]
Message-ID: <1743163.DHHxsEJfsI@phil> (raw)
In-Reply-To: <010ca6dc-e1f7-fb6d-7a22-056d4e1eeef2-5wv7dgnIgG8@public.gmane.org>
Am Mittwoch, 24. Mai 2017, 11:26:10 CEST schrieb Robin Murphy:
> On 24/05/17 09:17, Heiko Stuebner wrote:
> > Hi Eddie,
> >
> > Am Mittwoch, 24. Mai 2017, 15:33:41 CEST schrieb Eddie Cai:
> >> the previous setting of act8846 is just copy from firefly board. but
> >> the reload board is a little different from firefly board. let's correct
> >> it.
> >>
> >> Signed-off-by: Eddie Cai <eddie.cai.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> >> ---
> >> arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 21 +++++++++++----------
> >> 1 file changed, 11 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> >> index 8134966..4cfa109 100644
> >> --- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> >> +++ b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> >> @@ -179,6 +179,7 @@
> >> regulator-name = "vccio_sd";
> >> regulator-min-microvolt = <3300000>;
> >> regulator-max-microvolt = <3300000>;
> >> + regulator-always-on;
> >
> > the rest below looks pretty straight forward, but why does vccio_sd
> > need to be always on?
> >
> > I've checked the reload's schematics but did not find any further users
> > of vccio_sd that may warant this attribute.
>
> It looks like the card detect line is pulled up externally to vcc_sd,
> which isn't always-on either, so you probably do want this - on the
> (unrelated) rk3288 TV box I've been hacking on, I discovered that
> powering off the sdmmc-supply domain also kills the internal pull-up and
> leaves sdmmc_cd floating. The resulting stochastic card polling
> mechanism is amusing, but probably undesirable ;)
Hmm, are you mixing up vcc_sd and vccio_sd?
vccio_sd is the io supply (vqmmc in mmc-terms) to the mmc-host itself
while vcc_sd is the actual card supply (vmmc in mmc-terms).
After looking through some schematics, the pull-up to vcc_sd seems to be
the common pattern for rk3288 devices. So I guess this means the fixed
regulator vcc_sd should get an regulator-always-on instead to stabilize
the card-detect?
Heiko
> >
> >
> > Heiko
> >
> >
> >> };
> >>
> >> vdd10_lcd: REG6 {
> >> @@ -187,24 +188,23 @@
> >> regulator-max-microvolt = <1000000>;
> >> };
> >>
> >> - vcca_18: REG7 {
> >> - regulator-name = "vcca_18";
> >> - regulator-min-microvolt = <1800000>;
> >> - regulator-max-microvolt = <1800000>;
> >> - regulator-always-on;
> >> + vcca_33: REG7 {
> >> + regulator-name = "vcca_33";
> >> + regulator-min-microvolt = <3300000>;
> >> + regulator-max-microvolt = <3300000>;
> >> };
> >>
> >> - vcca_33: REG8 {
> >> - regulator-name = "vcca_33";
> >> + vcc_lan: REG8 {
> >> + regulator-name = "vcc_lan";
> >> regulator-min-microvolt = <3300000>;
> >> regulator-max-microvolt = <3300000>;
> >> - regulator-always-on;
> >> };
> >>
> >> - vcc_lan: REG9 {
> >> - regulator-name = "vcca_lan";
> >> + vccio_pmu: REG9 {
> >> + regulator-name = "vccio_pmu";
> >> regulator-min-microvolt = <3300000>;
> >> regulator-max-microvolt = <3300000>;
> >> + regulator-always-on;
> >> };
> >>
> >> vdd_10: REG10 {
> >> @@ -218,6 +218,7 @@
> >> regulator-name = "vcc_18";
> >> regulator-min-microvolt = <1800000>;
> >> regulator-max-microvolt = <1800000>;
> >> + regulator-always-on;
> >> };
> >>
> >> vcc18_lcd: REG12 {
> >>
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: heiko@sntech.de (Heiko Stuebner)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dts: rockchip: correct regular setting for act8846
Date: Wed, 24 May 2017 13:34:36 +0200 [thread overview]
Message-ID: <1743163.DHHxsEJfsI@phil> (raw)
In-Reply-To: <010ca6dc-e1f7-fb6d-7a22-056d4e1eeef2@arm.com>
Am Mittwoch, 24. Mai 2017, 11:26:10 CEST schrieb Robin Murphy:
> On 24/05/17 09:17, Heiko Stuebner wrote:
> > Hi Eddie,
> >
> > Am Mittwoch, 24. Mai 2017, 15:33:41 CEST schrieb Eddie Cai:
> >> the previous setting of act8846 is just copy from firefly board. but
> >> the reload board is a little different from firefly board. let's correct
> >> it.
> >>
> >> Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
> >> ---
> >> arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 21 +++++++++++----------
> >> 1 file changed, 11 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> >> index 8134966..4cfa109 100644
> >> --- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> >> +++ b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> >> @@ -179,6 +179,7 @@
> >> regulator-name = "vccio_sd";
> >> regulator-min-microvolt = <3300000>;
> >> regulator-max-microvolt = <3300000>;
> >> + regulator-always-on;
> >
> > the rest below looks pretty straight forward, but why does vccio_sd
> > need to be always on?
> >
> > I've checked the reload's schematics but did not find any further users
> > of vccio_sd that may warant this attribute.
>
> It looks like the card detect line is pulled up externally to vcc_sd,
> which isn't always-on either, so you probably do want this - on the
> (unrelated) rk3288 TV box I've been hacking on, I discovered that
> powering off the sdmmc-supply domain also kills the internal pull-up and
> leaves sdmmc_cd floating. The resulting stochastic card polling
> mechanism is amusing, but probably undesirable ;)
Hmm, are you mixing up vcc_sd and vccio_sd?
vccio_sd is the io supply (vqmmc in mmc-terms) to the mmc-host itself
while vcc_sd is the actual card supply (vmmc in mmc-terms).
After looking through some schematics, the pull-up to vcc_sd seems to be
the common pattern for rk3288 devices. So I guess this means the fixed
regulator vcc_sd should get an regulator-always-on instead to stabilize
the card-detect?
Heiko
> >
> >
> > Heiko
> >
> >
> >> };
> >>
> >> vdd10_lcd: REG6 {
> >> @@ -187,24 +188,23 @@
> >> regulator-max-microvolt = <1000000>;
> >> };
> >>
> >> - vcca_18: REG7 {
> >> - regulator-name = "vcca_18";
> >> - regulator-min-microvolt = <1800000>;
> >> - regulator-max-microvolt = <1800000>;
> >> - regulator-always-on;
> >> + vcca_33: REG7 {
> >> + regulator-name = "vcca_33";
> >> + regulator-min-microvolt = <3300000>;
> >> + regulator-max-microvolt = <3300000>;
> >> };
> >>
> >> - vcca_33: REG8 {
> >> - regulator-name = "vcca_33";
> >> + vcc_lan: REG8 {
> >> + regulator-name = "vcc_lan";
> >> regulator-min-microvolt = <3300000>;
> >> regulator-max-microvolt = <3300000>;
> >> - regulator-always-on;
> >> };
> >>
> >> - vcc_lan: REG9 {
> >> - regulator-name = "vcca_lan";
> >> + vccio_pmu: REG9 {
> >> + regulator-name = "vccio_pmu";
> >> regulator-min-microvolt = <3300000>;
> >> regulator-max-microvolt = <3300000>;
> >> + regulator-always-on;
> >> };
> >>
> >> vdd_10: REG10 {
> >> @@ -218,6 +218,7 @@
> >> regulator-name = "vcc_18";
> >> regulator-min-microvolt = <1800000>;
> >> regulator-max-microvolt = <1800000>;
> >> + regulator-always-on;
> >> };
> >>
> >> vcc18_lcd: REG12 {
> >>
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel at lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
>
>
WARNING: multiple messages have this Message-ID (diff)
From: Heiko Stuebner <heiko@sntech.de>
To: Robin Murphy <robin.murphy@arm.com>
Cc: Eddie Cai <eddie.cai.linux@gmail.com>,
mark.rutland@arm.com, devicetree@vger.kernel.org,
linux@armlinux.org.uk, linux-kernel@vger.kernel.org,
linux-rockchip@lists.infradead.org, robh+dt@kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] ARM: dts: rockchip: correct regular setting for act8846
Date: Wed, 24 May 2017 13:34:36 +0200 [thread overview]
Message-ID: <1743163.DHHxsEJfsI@phil> (raw)
In-Reply-To: <010ca6dc-e1f7-fb6d-7a22-056d4e1eeef2@arm.com>
Am Mittwoch, 24. Mai 2017, 11:26:10 CEST schrieb Robin Murphy:
> On 24/05/17 09:17, Heiko Stuebner wrote:
> > Hi Eddie,
> >
> > Am Mittwoch, 24. Mai 2017, 15:33:41 CEST schrieb Eddie Cai:
> >> the previous setting of act8846 is just copy from firefly board. but
> >> the reload board is a little different from firefly board. let's correct
> >> it.
> >>
> >> Signed-off-by: Eddie Cai <eddie.cai.linux@gmail.com>
> >> ---
> >> arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi | 21 +++++++++++----------
> >> 1 file changed, 11 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> >> index 8134966..4cfa109 100644
> >> --- a/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> >> +++ b/arch/arm/boot/dts/rk3288-firefly-reload-core.dtsi
> >> @@ -179,6 +179,7 @@
> >> regulator-name = "vccio_sd";
> >> regulator-min-microvolt = <3300000>;
> >> regulator-max-microvolt = <3300000>;
> >> + regulator-always-on;
> >
> > the rest below looks pretty straight forward, but why does vccio_sd
> > need to be always on?
> >
> > I've checked the reload's schematics but did not find any further users
> > of vccio_sd that may warant this attribute.
>
> It looks like the card detect line is pulled up externally to vcc_sd,
> which isn't always-on either, so you probably do want this - on the
> (unrelated) rk3288 TV box I've been hacking on, I discovered that
> powering off the sdmmc-supply domain also kills the internal pull-up and
> leaves sdmmc_cd floating. The resulting stochastic card polling
> mechanism is amusing, but probably undesirable ;)
Hmm, are you mixing up vcc_sd and vccio_sd?
vccio_sd is the io supply (vqmmc in mmc-terms) to the mmc-host itself
while vcc_sd is the actual card supply (vmmc in mmc-terms).
After looking through some schematics, the pull-up to vcc_sd seems to be
the common pattern for rk3288 devices. So I guess this means the fixed
regulator vcc_sd should get an regulator-always-on instead to stabilize
the card-detect?
Heiko
> >
> >
> > Heiko
> >
> >
> >> };
> >>
> >> vdd10_lcd: REG6 {
> >> @@ -187,24 +188,23 @@
> >> regulator-max-microvolt = <1000000>;
> >> };
> >>
> >> - vcca_18: REG7 {
> >> - regulator-name = "vcca_18";
> >> - regulator-min-microvolt = <1800000>;
> >> - regulator-max-microvolt = <1800000>;
> >> - regulator-always-on;
> >> + vcca_33: REG7 {
> >> + regulator-name = "vcca_33";
> >> + regulator-min-microvolt = <3300000>;
> >> + regulator-max-microvolt = <3300000>;
> >> };
> >>
> >> - vcca_33: REG8 {
> >> - regulator-name = "vcca_33";
> >> + vcc_lan: REG8 {
> >> + regulator-name = "vcc_lan";
> >> regulator-min-microvolt = <3300000>;
> >> regulator-max-microvolt = <3300000>;
> >> - regulator-always-on;
> >> };
> >>
> >> - vcc_lan: REG9 {
> >> - regulator-name = "vcca_lan";
> >> + vccio_pmu: REG9 {
> >> + regulator-name = "vccio_pmu";
> >> regulator-min-microvolt = <3300000>;
> >> regulator-max-microvolt = <3300000>;
> >> + regulator-always-on;
> >> };
> >>
> >> vdd_10: REG10 {
> >> @@ -218,6 +218,7 @@
> >> regulator-name = "vcc_18";
> >> regulator-min-microvolt = <1800000>;
> >> regulator-max-microvolt = <1800000>;
> >> + regulator-always-on;
> >> };
> >>
> >> vcc18_lcd: REG12 {
> >>
> >
> >
> >
> > _______________________________________________
> > linux-arm-kernel mailing list
> > linux-arm-kernel@lists.infradead.org
> > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> >
>
>
>
next prev parent reply other threads:[~2017-05-24 11:34 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-24 7:33 [PATCH] ARM: dts: rockchip: correct regular setting for act8846 Eddie Cai
2017-05-24 7:33 ` Eddie Cai
[not found] ` <1495611221-6749-1-git-send-email-eddie.cai.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-05-24 8:17 ` Heiko Stuebner
2017-05-24 8:17 ` Heiko Stuebner
2017-05-24 8:17 ` Heiko Stuebner
2017-05-24 8:44 ` Eddie Cai
2017-05-24 8:44 ` Eddie Cai
2017-05-24 8:47 ` Heiko Stuebner
2017-05-24 8:47 ` Heiko Stuebner
2017-05-24 8:47 ` Heiko Stuebner
2017-05-24 8:50 ` Eddie Cai
2017-05-24 8:50 ` Eddie Cai
2017-05-24 8:50 ` Eddie Cai
[not found] ` <CAJrj+DMU5XP9vHt60F8Uf7BTfv13DQQUoVXs0Fv2nKbWH8xKYw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2017-05-24 8:55 ` Heiko Stuebner
2017-05-24 8:55 ` Heiko Stuebner
2017-05-24 8:55 ` Heiko Stuebner
2017-05-24 10:26 ` Robin Murphy
2017-05-24 10:26 ` Robin Murphy
[not found] ` <010ca6dc-e1f7-fb6d-7a22-056d4e1eeef2-5wv7dgnIgG8@public.gmane.org>
2017-05-24 11:34 ` Heiko Stuebner [this message]
2017-05-24 11:34 ` Heiko Stuebner
2017-05-24 11:34 ` Heiko Stuebner
2017-05-24 12:27 ` Robin Murphy
2017-05-24 12:27 ` Robin Murphy
2017-05-24 12:27 ` Robin Murphy
2017-05-26 8:35 ` Eddie Cai
2017-05-26 8:35 ` Eddie Cai
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=1743163.DHHxsEJfsI@phil \
--to=heiko-4mtyjxux2i+zqb+pc5nmwq@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=eddie.cai.linux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=linux-I+IVW8TIWO2tmTQ+vhA3Yw@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=mark.rutland-5wv7dgnIgG8@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=robin.murphy-5wv7dgnIgG8@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.