Re: [linux-sunxi] Re: [PATCH 5/5] ARM: sun5i: Add C.H.I.P DTS
On Tue, Sep 22, 2015 at 04:30:04PM +0200, Hans de Goede wrote: > Hi, > > On 22-09-15 16:04, Maxime Ripard wrote: > >On Tue, Sep 22, 2015 at 03:01:58PM +0200, Hans de Goede wrote: > >>>In short, this is not about "power supply" but VBUS detection. IIRC, > >>>if no VBUS detection method is provided, the phy driver just waits a > >>>period of time after an ID pin change and then considers VBUS invalid. > >> > >>Right, but that is a hack for boards with no / broken vbus detection > >>(or vbus control), we really want to use vbus-det where available, > >>so I agree that a TODO comment here would be good. > > > >What's so special in our SoCs that makes that we can't just rely on > >the ID pin ? (which seems to be working just fine here) > > There is nothing special, AFAIK all OTG ports (also for other SoCs) > have some sort of vbus detection mechanism. We need the hack because > vbus-det is broken on some of our boards. > > And where it is not broken we should be using vbus-det normallu. Ah, and most controllers embed that directly into the controller itself and don't rely on a GPIO to do that. Understood. Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 5/5] ARM: sun5i: Add C.H.I.P DTS
Hi, On 22-09-15 16:04, Maxime Ripard wrote: On Tue, Sep 22, 2015 at 03:01:58PM +0200, Hans de Goede wrote: In short, this is not about "power supply" but VBUS detection. IIRC, if no VBUS detection method is provided, the phy driver just waits a period of time after an ID pin change and then considers VBUS invalid. Right, but that is a hack for boards with no / broken vbus detection (or vbus control), we really want to use vbus-det where available, so I agree that a TODO comment here would be good. What's so special in our SoCs that makes that we can't just rely on the ID pin ? (which seems to be working just fine here) There is nothing special, AFAIK all OTG ports (also for other SoCs) have some sort of vbus detection mechanism. We need the hack because vbus-det is broken on some of our boards. And where it is not broken we should be using vbus-det normallu. Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] Re: [PATCH 5/5] ARM: sun5i: Add C.H.I.P DTS
On Tue, Sep 22, 2015 at 03:01:58PM +0200, Hans de Goede wrote: > >In short, this is not about "power supply" but VBUS detection. IIRC, > >if no VBUS detection method is provided, the phy driver just waits a > >period of time after an ID pin change and then considers VBUS invalid. > > Right, but that is a hack for boards with no / broken vbus detection > (or vbus control), we really want to use vbus-det where available, > so I agree that a TODO comment here would be good. What's so special in our SoCs that makes that we can't just rely on the ID pin ? (which seems to be working just fine here) Other SoCs don't need to rely on such a hack as well. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: [PATCH 5/5] ARM: sun5i: Add C.H.I.P DTS
Hi,
On 22-09-15 15:01, Hans de Goede wrote:
Hi,
On 22-09-15 14:57, Chen-Yu Tsai wrote:
On Tue, Sep 22, 2015 at 8:47 PM, Maxime Ripard
wrote:
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&chip_id_det_pin>;
+ status = "okay";
+
+ usb0_id_det-gpio = <&pio 6 2 GPIO_ACTIVE_HIGH>; /* PG2 */
Better leave a comment here saying VBUS detection requires AXP209
usb-power-supply support.
Does it? It can be powered by a battery, with or without VBUS, and
that wouldn't be tied to the fact that the power-supply is USB or
something else.
The AXP209 VBUS / USB power-supply also doubles for VBUS detection,
which on most boards is done using a separate GPIO pin. Hans posted
support for the AXP20X power-supply driver, and support in the usb
phy driver using it for VBUS detection.
Ack.
In short, this is not about "power supply" but VBUS detection. IIRC,
if no VBUS detection method is provided, the phy driver just waits a
period of time after an ID pin change and then considers VBUS invalid.
Right, but that is a hack for boards with no / broken vbus detection
(or vbus control), we really want to use vbus-det where available,
so I agree that a TODO comment here would be good.
The axp209 usb-power-supply has just been merged into
linux-power-supply/next so even better we can simply update axp209.dtsi
with the node, and add do the right thing in the CHIP dts right away.
I'll send out all the dts patches which I've had queued up waiting
for this driver to get merged, including the axp209.dtsi changes.
Regards,
Hans
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] Re: [PATCH 5/5] ARM: sun5i: Add C.H.I.P DTS
Hi,
On 22-09-15 14:57, Chen-Yu Tsai wrote:
On Tue, Sep 22, 2015 at 8:47 PM, Maxime Ripard
wrote:
+&usb_otg {
+ dr_mode = "otg";
+ status = "okay";
+};
+
+&usbphy {
+ pinctrl-names = "default";
+ pinctrl-0 = <&chip_id_det_pin>;
+ status = "okay";
+
+ usb0_id_det-gpio = <&pio 6 2 GPIO_ACTIVE_HIGH>; /* PG2 */
Better leave a comment here saying VBUS detection requires AXP209
usb-power-supply support.
Does it? It can be powered by a battery, with or without VBUS, and
that wouldn't be tied to the fact that the power-supply is USB or
something else.
The AXP209 VBUS / USB power-supply also doubles for VBUS detection,
which on most boards is done using a separate GPIO pin. Hans posted
support for the AXP20X power-supply driver, and support in the usb
phy driver using it for VBUS detection.
Ack.
In short, this is not about "power supply" but VBUS detection. IIRC,
if no VBUS detection method is provided, the phy driver just waits a
period of time after an ID pin change and then considers VBUS invalid.
Right, but that is a hack for boards with no / broken vbus detection
(or vbus control), we really want to use vbus-det where available,
so I agree that a TODO comment here would be good.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-sunxi] Re: [PATCH 5/5] ARM: sun5i: Add C.H.I.P DTS
On Tue, Sep 22, 2015 at 8:47 PM, Maxime Ripard
wrote:
> On Sat, Sep 19, 2015 at 12:41:07AM +0800, Chen-Yu Tsai wrote:
>> On Fri, Sep 18, 2015 at 4:48 PM, Maxime Ripard
>> wrote:
>> > The C.H.I.P. is a small SBC with an Allwinner R8, 8GB of NAND, 512MB of
>> > RAM, USB host and OTG, a wifi / bluetooth combo chip, an audio/video jack
>> > and two connectors to plug additional boards on top of it.
>> >
>> > Signed-off-by: Maxime Ripard
>> > ---
>> > arch/arm/boot/dts/Makefile | 3 +-
>> > arch/arm/boot/dts/sun5i-r8-chip.dts | 261
>> >
>> > 2 files changed, 263 insertions(+), 1 deletion(-)
>> > create mode 100644 arch/arm/boot/dts/sun5i-r8-chip.dts
>> >
>> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> > index b276174b670a..7efd37b907f1 100644
>> > --- a/arch/arm/boot/dts/Makefile
>> > +++ b/arch/arm/boot/dts/Makefile
>> > @@ -599,7 +599,8 @@ dtb-$(CONFIG_MACH_SUN5I) += \
>> > sun5i-a13-inet-98v-rev2.dtb \
>> > sun5i-a13-olinuxino.dtb \
>> > sun5i-a13-olinuxino-micro.dtb \
>> > - sun5i-a13-utoo-p66.dtb
>> > + sun5i-a13-utoo-p66.dtb \
>> > + sun5i-r8-chip.dtb
>> > dtb-$(CONFIG_MACH_SUN6I) += \
>> > sun6i-a31-app4-evb1.dtb \
>> > sun6i-a31-colombus.dtb \
>> > diff --git a/arch/arm/boot/dts/sun5i-r8-chip.dts
>> > b/arch/arm/boot/dts/sun5i-r8-chip.dts
>> > new file mode 100644
>> > index ..6cb3c4f1cd61
>> > --- /dev/null
>> > +++ b/arch/arm/boot/dts/sun5i-r8-chip.dts
>> > @@ -0,0 +1,261 @@
>> > +/*
>> > + * Copyright 2015 Free Electrons
>> > + * Copyright 2015 NextThing Co
>> > + *
>> > + * Maxime Ripard
>> > + *
>> > + * This file is dual-licensed: you can use it either under the terms
>> > + * of the GPL or the X11 license, at your option. Note that this dual
>> > + * licensing only applies to this file, and not this project as a
>> > + * whole.
>> > + *
>> > + * a) This file is free software; you can redistribute it and/or
>> > + * modify it under the terms of the GNU General Public License as
>> > + * published by the Free Software Foundation; either version 2 of the
>> > + * License, or (at your option) any later version.
>> > + *
>> > + * This file is distributed in the hope that it will be useful,
>> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
>> > + * GNU General Public License for more details.
>> > + *
>> > + * Or, alternatively,
>> > + *
>> > + * b) Permission is hereby granted, free of charge, to any person
>> > + * obtaining a copy of this software and associated documentation
>> > + * files (the "Software"), to deal in the Software without
>> > + * restriction, including without limitation the rights to use,
>> > + * copy, modify, merge, publish, distribute, sublicense, and/or
>> > + * sell copies of the Software, and to permit persons to whom the
>> > + * Software is furnished to do so, subject to the following
>> > + * conditions:
>> > + *
>> > + * The above copyright notice and this permission notice shall be
>> > + * included in all copies or substantial portions of the Software.
>> > + *
>> > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
>> > + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
>> > + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
>> > + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
>> > + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
>> > + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
>> > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> > + * OTHER DEALINGS IN THE SOFTWARE.
>> > + */
>> > +
>> > +/dts-v1/;
>> > +#include "sun5i-a13.dtsi"
>> > +
>> > +#include
>> > +#include
>> > +
>> > +/ {
>> > + model = "NextThing C.H.I.P.";
>> > + compatible = "nextthing,chip", "allwinner,sun5i-r8";
>> > +
>> > + aliases {
>> > + i2c0 = &i2c0;
>> > + i2c1 = &i2c1;
>> > + i2c2 = &i2c2;
>> > + serial0 = &uart1;
>> > + serial1 = &uart3;
>> > + };
>> > +
>> > + chosen {
>> > + stdout-path = "serial0:115200n8";
>> > + };
>> > +
>> > + dram_vcc: dram_vcc {
>> > + compatible = "regulator-fixed";
>> > + regulator-name = "dram-vcc";
>> > + regulator-min-microvolt = <160>;
>> > + regulator-max-microvolt = <160>;
>> > + vin-supply = <&ipsout>;
>> > + regulator-always-on;
>> > + };
>>
>> Do we need this if it's not controllable?
>
> Probably not, except if we want a comprehensive regulator tree.
>
>> > +
>> > + ipsout: ipsout {
>> > + compatible = "regulator-fixed";
>> > + regulator-name
