From: siarhei.siamashka@gmail.com (Siarhei Siamashka)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-sunxi] [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2
Date: Mon, 5 Oct 2015 08:58:53 +0300 [thread overview]
Message-ID: <20151005085853.2dd2373b@i7> (raw)
In-Reply-To: <20151005083940.78d04f63@i7>
On Mon, 5 Oct 2015 08:39:40 +0300
Siarhei Siamashka <siarhei.siamashka@gmail.com> wrote:
> On Mon, 5 Oct 2015 09:55:28 +0800
> Chen-Yu Tsai <wens@csie.org> wrote:
>
> > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > <siarhei.siamashka@gmail.com> wrote:
> > > The pcDuino1 board does not use any power switches at all for its
> > > two USB host ports and the VBUS pins are always connected to 5V.
> > >
> > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > resistor. So that the USB power is still enabled by default even
> > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > firmware.
> >
> > Seems like it would be better if you had a regulator controlled
> > by PD2. At least can shut down VBUS power when it wants to?
>
> That's a good question.
>
> Describing the regulator controlled by PD2 in the dts file is surely
> the right solution for pcDuino2 boards. But in the case of using this
> dts for pcDuino1, the kernel would think that it can shut down VBUS
> power, while in fact this is not true.
>
> The RT9701GB switch also provides the current limiting feature in
> addition to the ability to enable/disable the VBUS power. Probably
> this was a real reason why it was added to the board.
>
> Everything boils down to the question whether we want to have a
> common dts file for pcDuino1 and pcDuino2 or decide to split them.
> Based on the schematics comparison, there do not seem to be any
> substantial differences between these boards if we ignore the PD2
> pin altogether. LinkSprite says that "Ubuntu images are same for
> both pcDuino1 and pcDuino2" at their website:
> http://www.linksprite.com/?page_id=809
>
> And I actually like their decision to have the PD2 pin pulled-up.
I'm not sure if everyone would like this, but the following trick
works. If we configure the PD2 pin as input with pull-down on the SoC
side and read it, then it still reads as 1 on pcDuino2. Which means
that the pull-up is apparently stronger (by how much and whether this
is really reliable is another question). It should read as 0 on
pcDuino1 and we might use this to detect the board type at runtime.
Still it is probably an overkill for just this really minor thing :-)
--
Best regards,
Siarhei Siamashka
WARNING: multiple messages have this Message-ID (diff)
From: Siarhei Siamashka <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Siarhei Siamashka
<siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: wens-jdAy2FN1RRM@public.gmane.org,
Maxime Ripard
<maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>,
linux-arm-kernel
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
devicetree <devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
linux-sunxi <linux-sunxi-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>,
Zoltan HERPAI <wigyori-1V5s5g7wVVk@public.gmane.org>
Subject: Re: [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2
Date: Mon, 5 Oct 2015 08:58:53 +0300 [thread overview]
Message-ID: <20151005085853.2dd2373b@i7> (raw)
In-Reply-To: <20151005083940.78d04f63@i7>
On Mon, 5 Oct 2015 08:39:40 +0300
Siarhei Siamashka <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> On Mon, 5 Oct 2015 09:55:28 +0800
> Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
>
> > On Mon, Oct 5, 2015 at 2:58 AM, Siarhei Siamashka
> > <siarhei.siamashka-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> > > The pcDuino1 board does not use any power switches at all for its
> > > two USB host ports and the VBUS pins are always connected to 5V.
> > >
> > > The pcDuino2 board uses the RT9701GB power switch for its single
> > > USB host port, but the USB_EN pin (PD2) is pulled up with a 10K
> > > resistor. So that the USB power is still enabled by default even
> > > if nobody bothers to configure the PD2 pin or runs the pcDuino1
> > > firmware.
> >
> > Seems like it would be better if you had a regulator controlled
> > by PD2. At least can shut down VBUS power when it wants to?
>
> That's a good question.
>
> Describing the regulator controlled by PD2 in the dts file is surely
> the right solution for pcDuino2 boards. But in the case of using this
> dts for pcDuino1, the kernel would think that it can shut down VBUS
> power, while in fact this is not true.
>
> The RT9701GB switch also provides the current limiting feature in
> addition to the ability to enable/disable the VBUS power. Probably
> this was a real reason why it was added to the board.
>
> Everything boils down to the question whether we want to have a
> common dts file for pcDuino1 and pcDuino2 or decide to split them.
> Based on the schematics comparison, there do not seem to be any
> substantial differences between these boards if we ignore the PD2
> pin altogether. LinkSprite says that "Ubuntu images are same for
> both pcDuino1 and pcDuino2" at their website:
> http://www.linksprite.com/?page_id=809
>
> And I actually like their decision to have the PD2 pin pulled-up.
I'm not sure if everyone would like this, but the following trick
works. If we configure the PD2 pin as input with pull-down on the SoC
side and read it, then it still reads as 1 on pcDuino2. Which means
that the pull-up is apparently stronger (by how much and whether this
is really reliable is another question). It should read as 0 on
pcDuino1 and we might use this to detect the board type at runtime.
Still it is probably an overkill for just this really minor thing :-)
--
Best regards,
Siarhei Siamashka
next prev parent reply other threads:[~2015-10-05 5:58 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-04 18:58 [PATCH 0/3] ARM: dts: sun4i: USB DRC and voltage-scaling for pcDuino1/2 Siarhei Siamashka
2015-10-04 18:58 ` Siarhei Siamashka
2015-10-04 18:58 ` [PATCH 1/3] ARM: dts: sun4i: Allow to use the PH6 pin for GPIO on pcDuino1/2 Siarhei Siamashka
2015-10-04 18:58 ` Siarhei Siamashka
2015-10-05 1:55 ` [linux-sunxi] " Chen-Yu Tsai
2015-10-05 1:55 ` Chen-Yu Tsai
2015-10-05 5:39 ` [linux-sunxi] " Siarhei Siamashka
2015-10-05 5:39 ` Siarhei Siamashka
2015-10-05 5:58 ` Siarhei Siamashka [this message]
2015-10-05 5:58 ` Siarhei Siamashka
2015-10-07 5:11 ` [linux-sunxi] " Siarhei Siamashka
2015-10-07 5:11 ` Siarhei Siamashka
2015-10-05 12:49 ` [linux-sunxi] " Maxime Ripard
2015-10-05 12:49 ` Maxime Ripard
2015-10-07 4:27 ` [linux-sunxi] " Siarhei Siamashka
2015-10-07 4:27 ` Siarhei Siamashka
2015-10-04 18:58 ` [PATCH 2/3] ARM: dts: sun4i: Enable USB DRC " Siarhei Siamashka
2015-10-04 18:58 ` Siarhei Siamashka
2015-10-04 18:58 ` [PATCH 3/3] ARM: dts: sun4i: Add AXP209 PMU regulators for pcDuino1/2 Siarhei Siamashka
2015-10-04 18:58 ` Siarhei Siamashka
2015-10-05 12:56 ` Maxime Ripard
2015-10-05 12:56 ` Maxime Ripard
2015-10-05 12:38 ` [PATCH 0/3] ARM: dts: sun4i: USB DRC and voltage-scaling " Maxime Ripard
2015-10-05 12:38 ` Maxime Ripard
2015-10-07 4:06 ` Siarhei Siamashka
2015-10-07 4:06 ` Siarhei Siamashka
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=20151005085853.2dd2373b@i7 \
--to=siarhei.siamashka@gmail.com \
--cc=linux-arm-kernel@lists.infradead.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.