| Message ID | 54280AA7.1090401@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Sun, Sep 28, 2014 at 02:18:31PM +0100, Iain Paton wrote: > This adds support for the Olimex A20-OLinuXino-Lime2 > https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2 > > Differences to previous Lime boards are 1GB RAM and gigabit ethernet > > Signed-off-by: Iain Paton <ipaton0@gmail.com> > --- > > I'd like to see this go in with the dual license, but not really > sure if that's appropriate while sunxi-common-regulators.dtsi is still > GPL only. Thanks for the remainder, and yes, it should be fine even though sunxi-common-regulators is only GPL (but the resulting binary would be GPL-only). > Happy to resend with single license header if it's deemed > better for now though. > > arch/arm/boot/dts/Makefile | 1 + > arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 178 ++++++++++++++++++++++++ > 2 files changed, 179 insertions(+) > create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts > > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile > index 2f42b18..ea6c672 100644 > --- a/arch/arm/boot/dts/Makefile > +++ b/arch/arm/boot/dts/Makefile > @@ -420,6 +420,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \ > sun7i-a20-hummingbird.dtb \ > sun7i-a20-i12-tvbox.dtb \ > sun7i-a20-olinuxino-lime.dtb \ > + sun7i-a20-olinuxino-lime2.dtb \ > sun7i-a20-olinuxino-micro.dtb \ > sun7i-a20-pcduino3.dtb > dtb-$(CONFIG_MACH_SUN8I) += \ > diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts > new file mode 100644 > index 0000000..14fbc43 > --- /dev/null > +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts > @@ -0,0 +1,178 @@ > +/* > + * Copyright 2014 - Iain Paton <ipaton0@gmail.com> > + * > + * 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 library 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 library 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. > + * > + * You should have received a copy of the GNU General Public > + * License along with this library; if not, write to the Free > + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, > + * MA 02110-1301 USA > + * > + * 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/ "sun7i-a20.dtsi" > +/include/ "sunxi-common-regulators.dtsi" > + > +/ { > + model = "Olimex A20-OLinuXino-LIME2"; > + compatible = "olimex,a20-olinuxino-lime2", "allwinner,sun7i-a20"; > + > + soc@01c00000 { > + > + ahci: sata@01c18000 { > + target-supply = <®_ahci_5v>; > + status = "okay"; > + }; > + > + ehci0: usb@01c14000 { > + status = "okay"; > + }; > + > + ehci1: usb@01c1c000 { > + status = "okay"; > + }; > + > + gmac: ethernet@01c50000 { > + pinctrl-names = "default"; > + pinctrl-0 = <&gmac_pins_rgmii_a>; > + phy = <&phy1>; > + phy-mode = "rgmii"; > + status = "okay"; > + > + phy1: ethernet-phy@1 { > + reg = <1>; > + }; > + }; > + > + i2c0: i2c@01c2ac00 { > + pinctrl-names = "default"; > + pinctrl-0 = <&i2c0_pins_a>; > + status = "okay"; > + > + axp209: pmic@34 { > + compatible = "x-powers,axp209"; > + reg = <0x34>; > + interrupt-parent = <&nmi_intc>; > + interrupts = <0 8>; > + > + interrupt-controller; > + #interrupt-cells = <1>; It would be greate if you could add the regulators used on the board here. You might want to hold off a bit until the merge window is out, since some patches useful for this are still pending, or based your patch on top of linux-next > + }; > + > + }; > + > + i2c1: i2c@01c2b000 { > + pinctrl-names = "default"; > + pinctrl-0 = <&i2c1_pins_a>; > + status = "okay"; > + }; > + > + mmc0: mmc@01c0f000 { > + pinctrl-names = "default"; > + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>; > + vmmc-supply = <®_vcc3v3>; > + bus-width = <4>; > + cd-gpios = <&pio 7 1 0>; /* PH1 */ > + cd-inverted; > + status = "okay"; > + }; > + > + ohci0: usb@01c14400 { > + status = "okay"; > + }; > + > + ohci1: usb@01c1c400 { > + status = "okay"; > + }; > + > + uart0: serial@01c28000 { > + pinctrl-names = "default"; > + pinctrl-0 = <&uart0_pins_a>; > + status = "okay"; > + }; > + > + usbphy: phy@01c13400 { > + usb1_vbus-supply = <®_usb1_vbus>; > + usb2_vbus-supply = <®_usb2_vbus>; > + status = "okay"; > + }; > + > + pinctrl@01c20800 { > + ahci_pwr_pin_olinuxinolime: ahci_pwr_pin@1 { > + allwinner,pins = "PC3"; > + allwinner,function = "gpio_out"; > + allwinner,drive = <0>; > + allwinner,pull = <0>; > + }; > + > + led_pins_olinuxinolime: led_pins@0 { > + allwinner,pins = "PH2"; > + allwinner,function = "gpio_out"; > + allwinner,drive = <1>; > + allwinner,pull = <0>; > + }; > + }; > + }; > + > + leds { > + compatible = "gpio-leds"; > + pinctrl-names = "default"; > + pinctrl-0 = <&led_pins_olinuxinolime>; > + > + green { > + label = "a20-olinuxino-lime2:green:usr"; > + gpios = <&pio 7 2 0>; > + default-state = "on"; > + }; > + }; > + > + reg_ahci_5v: ahci-5v { > + pinctrl-0 = <&ahci_pwr_pin_olinuxinolime>; > + gpio = <&pio 2 3 0>; > + status = "okay"; > + }; > + > + reg_usb1_vbus: usb1-vbus { > + status = "okay"; > + }; > + > + reg_usb2_vbus: usb2-vbus { > + status = "okay"; > + }; > +}; > -- > 1.8.5.1 > It looks fine otherwise, thanks! Maxime
On 28/09/14 17:43, Maxime Ripard wrote: > On Sun, Sep 28, 2014 at 02:18:31PM +0100, Iain Paton wrote: >> + >> + i2c0: i2c@01c2ac00 { >> + pinctrl-names = "default"; >> + pinctrl-0 = <&i2c0_pins_a>; >> + status = "okay"; >> + >> + axp209: pmic@34 { >> + compatible = "x-powers,axp209"; >> + reg = <0x34>; >> + interrupt-parent = <&nmi_intc>; >> + interrupts = <0 8>; >> + >> + interrupt-controller; >> + #interrupt-cells = <1>; > > It would be greate if you could add the regulators used on the board > here. > > You might want to hold off a bit until the merge window is out, since > some patches useful for this are still pending, or based your patch on > top of linux-next I'll take a bash at it, although as there seems to be no binding doc for the driver and I can't find any other board that has axp209 regulators defined I may need a bit of help to get this right. What additional patches are we talking about? The following: regulator: axp20x: Use parent device as regulator configuration device i2c: mv64xxx: continue probe when clock-frequency is missing or are there others I'd need to pick out of linux-next? linux-next 20140926 doesn't build for me: LD init/built-in.o kernel/built-in.o: In function `cputime_adjust': :(.text+0x25588): undefined reference to `__bad_cmpxchg' :(.text+0x255f8): undefined reference to `__bad_cmpxchg' /data/linux/source/linux-next-org/Makefile:956: recipe for target 'vmlinux' failed I suppose as a result of https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/kernel/sched/cputime.c?id=eb1b4af0a64ac7bb0ee36f579c1c7cefcbc3ac2c having reverted that one, the resulting kernel doesn't want to talk to my SD card. Both your tree and 3.16 work fine though. Anyway, v2 on it's way.
On Mon, Sep 29, 2014 at 01:56:49PM +0100, Iain Paton wrote: > On 28/09/14 17:43, Maxime Ripard wrote: > > On Sun, Sep 28, 2014 at 02:18:31PM +0100, Iain Paton wrote: > > >> + > >> + i2c0: i2c@01c2ac00 { > >> + pinctrl-names = "default"; > >> + pinctrl-0 = <&i2c0_pins_a>; > >> + status = "okay"; > >> + > >> + axp209: pmic@34 { > >> + compatible = "x-powers,axp209"; > >> + reg = <0x34>; > >> + interrupt-parent = <&nmi_intc>; > >> + interrupts = <0 8>; > >> + > >> + interrupt-controller; > >> + #interrupt-cells = <1>; > > > > It would be greate if you could add the regulators used on the board > > here. > > > > You might want to hold off a bit until the merge window is out, since > > some patches useful for this are still pending, or based your patch on > > top of linux-next > > I'll take a bash at it, although as there seems to be no binding doc > for the driver and I can't find any other board that has axp209 > regulators defined I may need a bit of help to get this right. Hmmm, that's odd. I was 100% sure it had one, but now that you mention it, I can't find it either. I should find where that patch went, and merge it then... > What additional patches are we talking about? The following: > regulator: axp20x: Use parent device as regulator configuration device > i2c: mv64xxx: continue probe when clock-frequency is missing > or are there others I'd need to pick out of linux-next? http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288901.html > linux-next 20140926 doesn't build for me: > > LD init/built-in.o > kernel/built-in.o: In function `cputime_adjust': > :(.text+0x25588): undefined reference to `__bad_cmpxchg' > :(.text+0x255f8): undefined reference to `__bad_cmpxchg' > /data/linux/source/linux-next-org/Makefile:956: recipe for target 'vmlinux' failed > > I suppose as a result of https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/kernel/sched/cputime.c?id=eb1b4af0a64ac7bb0ee36f579c1c7cefcbc3ac2c > > having reverted that one, the resulting kernel doesn't want to talk > to my SD card. Both your tree and 3.16 work fine though. Leave it out then. If you have no way to test it, it's going to be very bug prone, and we can always add it later. The SD card issue is more troublesome. We'll have to look into it. Thanks! Maxime
On 29/09/14 14:25, Maxime Ripard wrote: > On Mon, Sep 29, 2014 at 01:56:49PM +0100, Iain Paton wrote: >> What additional patches are we talking about? The following: >> regulator: axp20x: Use parent device as regulator configuration device >> i2c: mv64xxx: continue probe when clock-frequency is missing >> or are there others I'd need to pick out of linux-next? > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288901.html Ok, I'll pull those on top of something not quite as bleeding edge as linux-next > Leave it out then. If you have no way to test it, it's going to be > very bug prone, and we can always add it later. I moved my root disk to a SATA drive, so only a minor inconvenience. dmesg shows the following with the regulators node as in the v2 patch, the bottom half being mostly what I'd expect [ 0.868607] sunxi-rtc 1c20d00.rtc: RTC enabled [ 0.877062] Adding alias for supply acin,(null) -> acin,0-0034 [ 0.882948] Adding alias for supply vin2,(null) -> vin2,0-0034 [ 0.888775] Adding alias for supply vin3,(null) -> vin3,0-0034 [ 0.894612] Adding alias for supply ldo24in,(null) -> ldo24in,0-0034 [ 0.900956] Adding alias for supply ldo3in,(null) -> ldo3in,0-0034 [ 0.907160] Adding alias for supply ldo5in,(null) -> ldo5in,0-0034 [ 0.914029] LDO1: 1300 mV [ 0.917428] LDO2: 1800 <--> 3300 mV at 3000 mV [ 0.922483] LDO3: 700 <--> 3500 mV at 2275 mV [ 0.927136] LDO4: 1250 <--> 3300 mV at 2800 mV [ 0.932334] LDO5: 1800 <--> 3300 mV at 2800 mV [ 0.937308] DCDC2: 1400 mV [ 0.940552] DCDC3: 1250 mV [ 0.943474] axp20x 0-0034: AXP20X driver loaded > The SD card issue is more troublesome. We'll have to look into it. dmesg shows the mmc driver loading: [ 0.957716] sdhci: Secure Digital Host Controller Interface driver [ 0.963963] sdhci: Copyright(c) Pierre Ossman [ 0.968843] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found [ 0.974918] sunxi-mmc 1c0f000.mmc: Got CD GPIO [ 1.012036] sunxi-mmc 1c0f000.mmc: base:0xf00ac000 irq:64 [ 1.017623] sdhci-pltfm: SDHCI platform and OF driver helper however on an older, working, kernel I get a number on the end of the 'Got CD GPIO' line like this: [ 0.896271] sunxi-mmc 1c0f000.mmc: Got CD GPIO #225. when I remove the SD card I see: [ 20.147667] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 8, RTO !! [ 20.157319] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !! [ 20.163796] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !! [ 20.170268] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !! [ 20.176743] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 55, RTO !! [ 20.183250] sunxi-mmc 1c0f000.mmc: smc 0 err, cmd 1, RTO !! Which gives the impression that it's seeing CD inverted, however I tried taking the cd-inverted; line out of the dts with no change. No messages at all on card insertion. I'll try the same kernel on an A10-lime later, if it has the same problem it'll rule out something in this new dts. Iain
On Mon, Sep 29, 2014 at 03:32:43PM +0100, Iain Paton wrote: > On 29/09/14 14:25, Maxime Ripard wrote: > > On Mon, Sep 29, 2014 at 01:56:49PM +0100, Iain Paton wrote: > > >> What additional patches are we talking about? The following: > >> regulator: axp20x: Use parent device as regulator configuration device > >> i2c: mv64xxx: continue probe when clock-frequency is missing > >> or are there others I'd need to pick out of linux-next? > > > > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288901.html > > Ok, I'll pull those on top of something not quite as bleeding edge as linux-next > > > Leave it out then. If you have no way to test it, it's going to be > > very bug prone, and we can always add it later. > > I moved my root disk to a SATA drive, so only a minor inconvenience. > > dmesg shows the following with the regulators node as in the v2 patch, > the bottom half being mostly what I'd expect > > [ 0.868607] sunxi-rtc 1c20d00.rtc: RTC enabled > [ 0.877062] Adding alias for supply acin,(null) -> acin,0-0034 > [ 0.882948] Adding alias for supply vin2,(null) -> vin2,0-0034 > [ 0.888775] Adding alias for supply vin3,(null) -> vin3,0-0034 > [ 0.894612] Adding alias for supply ldo24in,(null) -> ldo24in,0-0034 > [ 0.900956] Adding alias for supply ldo3in,(null) -> ldo3in,0-0034 > [ 0.907160] Adding alias for supply ldo5in,(null) -> ldo5in,0-0034 > [ 0.914029] LDO1: 1300 mV > [ 0.917428] LDO2: 1800 <--> 3300 mV at 3000 mV > [ 0.922483] LDO3: 700 <--> 3500 mV at 2275 mV > [ 0.927136] LDO4: 1250 <--> 3300 mV at 2800 mV > [ 0.932334] LDO5: 1800 <--> 3300 mV at 2800 mV > [ 0.937308] DCDC2: 1400 mV > [ 0.940552] DCDC3: 1250 mV > [ 0.943474] axp20x 0-0034: AXP20X driver loaded No, it's not. You don't have the parenting relationship between the regulators, and you shouldn't use the aliases anymore. Like I said, you'd better drop that part until things settle down. > > The SD card issue is more troublesome. We'll have to look into it. > > dmesg shows the mmc driver loading: > > [ 0.957716] sdhci: Secure Digital Host Controller Interface driver > [ 0.963963] sdhci: Copyright(c) Pierre Ossman > [ 0.968843] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found > [ 0.974918] sunxi-mmc 1c0f000.mmc: Got CD GPIO > [ 1.012036] sunxi-mmc 1c0f000.mmc: base:0xf00ac000 irq:64 > [ 1.017623] sdhci-pltfm: SDHCI platform and OF driver helper > > however on an older, working, kernel I get a number on the end of > the 'Got CD GPIO' line like this: > > [ 0.896271] sunxi-mmc 1c0f000.mmc: Got CD GPIO #225. That's interesting. It seems like it might be related to the recent breakages in the boot farm on the A31. These breakages were not happening on the arm-soc branch, but on linux-next only, so it must be coming from somewhere else, which is not that great, but rules out the DTS. I'll bisect it this weekend, but don't worry too much about it. Maxime
Hello Maxim, Iain, On Thu, Oct 2, 2014 at 2:48 PM, Maxime Ripard <maxime.ripard@free-electrons.com> wrote: > On Mon, Sep 29, 2014 at 03:32:43PM +0100, Iain Paton wrote: >> On 29/09/14 14:25, Maxime Ripard wrote: >> > On Mon, Sep 29, 2014 at 01:56:49PM +0100, Iain Paton wrote: >> >> >> What additional patches are we talking about? The following: >> >> regulator: axp20x: Use parent device as regulator configuration device >> >> i2c: mv64xxx: continue probe when clock-frequency is missing >> >> or are there others I'd need to pick out of linux-next? >> > >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288901.html >> >> Ok, I'll pull those on top of something not quite as bleeding edge as linux-next >> >> > Leave it out then. If you have no way to test it, it's going to be >> > very bug prone, and we can always add it later. >> >> I moved my root disk to a SATA drive, so only a minor inconvenience. >> >> dmesg shows the following with the regulators node as in the v2 patch, >> the bottom half being mostly what I'd expect >> >> [ 0.868607] sunxi-rtc 1c20d00.rtc: RTC enabled >> [ 0.877062] Adding alias for supply acin,(null) -> acin,0-0034 >> [ 0.882948] Adding alias for supply vin2,(null) -> vin2,0-0034 >> [ 0.888775] Adding alias for supply vin3,(null) -> vin3,0-0034 >> [ 0.894612] Adding alias for supply ldo24in,(null) -> ldo24in,0-0034 >> [ 0.900956] Adding alias for supply ldo3in,(null) -> ldo3in,0-0034 >> [ 0.907160] Adding alias for supply ldo5in,(null) -> ldo5in,0-0034 >> [ 0.914029] LDO1: 1300 mV >> [ 0.917428] LDO2: 1800 <--> 3300 mV at 3000 mV >> [ 0.922483] LDO3: 700 <--> 3500 mV at 2275 mV >> [ 0.927136] LDO4: 1250 <--> 3300 mV at 2800 mV >> [ 0.932334] LDO5: 1800 <--> 3300 mV at 2800 mV >> [ 0.937308] DCDC2: 1400 mV >> [ 0.940552] DCDC3: 1250 mV >> [ 0.943474] axp20x 0-0034: AXP20X driver loaded > > No, it's not. You don't have the parenting relationship between the > regulators, and you shouldn't use the aliases anymore. > > Like I said, you'd better drop that part until things settle down. > >> > The SD card issue is more troublesome. We'll have to look into it. >> >> dmesg shows the mmc driver loading: >> >> [ 0.957716] sdhci: Secure Digital Host Controller Interface driver >> [ 0.963963] sdhci: Copyright(c) Pierre Ossman >> [ 0.968843] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found >> [ 0.974918] sunxi-mmc 1c0f000.mmc: Got CD GPIO >> [ 1.012036] sunxi-mmc 1c0f000.mmc: base:0xf00ac000 irq:64 >> [ 1.017623] sdhci-pltfm: SDHCI platform and OF driver helper >> >> however on an older, working, kernel I get a number on the end of >> the 'Got CD GPIO' line like this: >> >> [ 0.896271] sunxi-mmc 1c0f000.mmc: Got CD GPIO #225. > > That's interesting. It seems like it might be related to the recent > breakages in the boot farm on the A31. These breakages were not > happening on the arm-soc branch, but on linux-next only, so it must be > coming from somewhere else, which is not that great, but rules out the > DTS. > > I'll bisect it this weekend, but don't worry too much about it. > The problem you are facing is because commit 98e90de ("mmc: host: switch OF parser to use gpio descriptors") changed the semantics when the mmc cd and wp properties were converted to use the GPIO descriptor based API so card detection is not working on your board. I reported the issue to Linus W. and he provided a fix [0] which should land in linux-next soon. > Maxime > Best regards, Javier [0]: https://www.mail-archive.com/linux-mmc@vger.kernel.org/msg28751.html
Hi Javier, On Mon, Oct 06, 2014 at 10:56:50AM +0200, Javier Martinez Canillas wrote: > Hello Maxim, Iain, > > On Thu, Oct 2, 2014 at 2:48 PM, Maxime Ripard > <maxime.ripard@free-electrons.com> wrote: > > On Mon, Sep 29, 2014 at 03:32:43PM +0100, Iain Paton wrote: > >> On 29/09/14 14:25, Maxime Ripard wrote: > >> > On Mon, Sep 29, 2014 at 01:56:49PM +0100, Iain Paton wrote: > >> > >> >> What additional patches are we talking about? The following: > >> >> regulator: axp20x: Use parent device as regulator configuration device > >> >> i2c: mv64xxx: continue probe when clock-frequency is missing > >> >> or are there others I'd need to pick out of linux-next? > >> > > >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2014-September/288901.html > >> > >> Ok, I'll pull those on top of something not quite as bleeding edge as linux-next > >> > >> > Leave it out then. If you have no way to test it, it's going to be > >> > very bug prone, and we can always add it later. > >> > >> I moved my root disk to a SATA drive, so only a minor inconvenience. > >> > >> dmesg shows the following with the regulators node as in the v2 patch, > >> the bottom half being mostly what I'd expect > >> > >> [ 0.868607] sunxi-rtc 1c20d00.rtc: RTC enabled > >> [ 0.877062] Adding alias for supply acin,(null) -> acin,0-0034 > >> [ 0.882948] Adding alias for supply vin2,(null) -> vin2,0-0034 > >> [ 0.888775] Adding alias for supply vin3,(null) -> vin3,0-0034 > >> [ 0.894612] Adding alias for supply ldo24in,(null) -> ldo24in,0-0034 > >> [ 0.900956] Adding alias for supply ldo3in,(null) -> ldo3in,0-0034 > >> [ 0.907160] Adding alias for supply ldo5in,(null) -> ldo5in,0-0034 > >> [ 0.914029] LDO1: 1300 mV > >> [ 0.917428] LDO2: 1800 <--> 3300 mV at 3000 mV > >> [ 0.922483] LDO3: 700 <--> 3500 mV at 2275 mV > >> [ 0.927136] LDO4: 1250 <--> 3300 mV at 2800 mV > >> [ 0.932334] LDO5: 1800 <--> 3300 mV at 2800 mV > >> [ 0.937308] DCDC2: 1400 mV > >> [ 0.940552] DCDC3: 1250 mV > >> [ 0.943474] axp20x 0-0034: AXP20X driver loaded > > > > No, it's not. You don't have the parenting relationship between the > > regulators, and you shouldn't use the aliases anymore. > > > > Like I said, you'd better drop that part until things settle down. > > > >> > The SD card issue is more troublesome. We'll have to look into it. > >> > >> dmesg shows the mmc driver loading: > >> > >> [ 0.957716] sdhci: Secure Digital Host Controller Interface driver > >> [ 0.963963] sdhci: Copyright(c) Pierre Ossman > >> [ 0.968843] sunxi-mmc 1c0f000.mmc: No vqmmc regulator found > >> [ 0.974918] sunxi-mmc 1c0f000.mmc: Got CD GPIO > >> [ 1.012036] sunxi-mmc 1c0f000.mmc: base:0xf00ac000 irq:64 > >> [ 1.017623] sdhci-pltfm: SDHCI platform and OF driver helper > >> > >> however on an older, working, kernel I get a number on the end of > >> the 'Got CD GPIO' line like this: > >> > >> [ 0.896271] sunxi-mmc 1c0f000.mmc: Got CD GPIO #225. > > > > That's interesting. It seems like it might be related to the recent > > breakages in the boot farm on the A31. These breakages were not > > happening on the arm-soc branch, but on linux-next only, so it must be > > coming from somewhere else, which is not that great, but rules out the > > DTS. > > > > I'll bisect it this weekend, but don't worry too much about it. > > > > The problem you are facing is because commit 98e90de ("mmc: host: > switch OF parser to use gpio descriptors") changed the semantics when > the mmc cd and wp properties were converted to use the GPIO descriptor > based API so card detection is not working on your board. > > I reported the issue to Linus W. and he provided a fix [0] which > should land in linux-next soon. Yeah, I ended up bisecting this weekend, and found this commit, but I wasn't aware of such a fix. Thanks! Maxime
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile index 2f42b18..ea6c672 100644 --- a/arch/arm/boot/dts/Makefile +++ b/arch/arm/boot/dts/Makefile @@ -420,6 +420,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \ sun7i-a20-hummingbird.dtb \ sun7i-a20-i12-tvbox.dtb \ sun7i-a20-olinuxino-lime.dtb \ + sun7i-a20-olinuxino-lime2.dtb \ sun7i-a20-olinuxino-micro.dtb \ sun7i-a20-pcduino3.dtb dtb-$(CONFIG_MACH_SUN8I) += \ diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts new file mode 100644 index 0000000..14fbc43 --- /dev/null +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts @@ -0,0 +1,178 @@ +/* + * Copyright 2014 - Iain Paton <ipaton0@gmail.com> + * + * 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 library 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 library 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. + * + * You should have received a copy of the GNU General Public + * License along with this library; if not, write to the Free + * Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, + * MA 02110-1301 USA + * + * 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/ "sun7i-a20.dtsi" +/include/ "sunxi-common-regulators.dtsi" + +/ { + model = "Olimex A20-OLinuXino-LIME2"; + compatible = "olimex,a20-olinuxino-lime2", "allwinner,sun7i-a20"; + + soc@01c00000 { + + ahci: sata@01c18000 { + target-supply = <®_ahci_5v>; + status = "okay"; + }; + + ehci0: usb@01c14000 { + status = "okay"; + }; + + ehci1: usb@01c1c000 { + status = "okay"; + }; + + gmac: ethernet@01c50000 { + pinctrl-names = "default"; + pinctrl-0 = <&gmac_pins_rgmii_a>; + phy = <&phy1>; + phy-mode = "rgmii"; + status = "okay"; + + phy1: ethernet-phy@1 { + reg = <1>; + }; + }; + + i2c0: i2c@01c2ac00 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c0_pins_a>; + status = "okay"; + + axp209: pmic@34 { + compatible = "x-powers,axp209"; + reg = <0x34>; + interrupt-parent = <&nmi_intc>; + interrupts = <0 8>; + + interrupt-controller; + #interrupt-cells = <1>; + }; + + }; + + i2c1: i2c@01c2b000 { + pinctrl-names = "default"; + pinctrl-0 = <&i2c1_pins_a>; + status = "okay"; + }; + + mmc0: mmc@01c0f000 { + pinctrl-names = "default"; + pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin_reference_design>; + vmmc-supply = <®_vcc3v3>; + bus-width = <4>; + cd-gpios = <&pio 7 1 0>; /* PH1 */ + cd-inverted; + status = "okay"; + }; + + ohci0: usb@01c14400 { + status = "okay"; + }; + + ohci1: usb@01c1c400 { + status = "okay"; + }; + + uart0: serial@01c28000 { + pinctrl-names = "default"; + pinctrl-0 = <&uart0_pins_a>; + status = "okay"; + }; + + usbphy: phy@01c13400 { + usb1_vbus-supply = <®_usb1_vbus>; + usb2_vbus-supply = <®_usb2_vbus>; + status = "okay"; + }; + + pinctrl@01c20800 { + ahci_pwr_pin_olinuxinolime: ahci_pwr_pin@1 { + allwinner,pins = "PC3"; + allwinner,function = "gpio_out"; + allwinner,drive = <0>; + allwinner,pull = <0>; + }; + + led_pins_olinuxinolime: led_pins@0 { + allwinner,pins = "PH2"; + allwinner,function = "gpio_out"; + allwinner,drive = <1>; + allwinner,pull = <0>; + }; + }; + }; + + leds { + compatible = "gpio-leds"; + pinctrl-names = "default"; + pinctrl-0 = <&led_pins_olinuxinolime>; + + green { + label = "a20-olinuxino-lime2:green:usr"; + gpios = <&pio 7 2 0>; + default-state = "on"; + }; + }; + + reg_ahci_5v: ahci-5v { + pinctrl-0 = <&ahci_pwr_pin_olinuxinolime>; + gpio = <&pio 2 3 0>; + status = "okay"; + }; + + reg_usb1_vbus: usb1-vbus { + status = "okay"; + }; + + reg_usb2_vbus: usb2-vbus { + status = "okay"; + }; +};
This adds support for the Olimex A20-OLinuXino-Lime2 https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2 Differences to previous Lime boards are 1GB RAM and gigabit ethernet Signed-off-by: Iain Paton <ipaton0@gmail.com> --- I'd like to see this go in with the dual license, but not really sure if that's appropriate while sunxi-common-regulators.dtsi is still GPL only. Happy to resend with single license header if it's deemed better for now though. arch/arm/boot/dts/Makefile | 1 + arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts | 178 ++++++++++++++++++++++++ 2 files changed, 179 insertions(+) create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts