Re: [linux-sunxi] Storage issue on linux-sunxi.org
On Tue, Jun 16, 2015 at 10:18:33AM +0300, 'Simos Xenitellis' via linux-sunxi wrote: Hi All, One of the partitions on linux-sunxi.org got full and requires attention. When you visit the website, it shows at the bottom of each page Warning: Unknown: write failed: No space left on device (28) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5) in Unknown on line 0 Simos As you noticed, you should poke people on irc next time: likely candidates: mnemoc, turl, libv, ... Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support
Hi Pantelis, On Sun, Jun 14, 2015 at 09:16:21PM +0300, Pantelis Antoniou wrote: I think we need to discuss this with Pantelis and what is his feeling about this. Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope? There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment. I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?) First of all, the quirks interface is at an RFC stage (new name suggested is ‘variants’); getting that out of the way this seems like what it is designed to do. The idea of the DT quirks is to drastically cut down on the number of different DTs required, each different for each board with minute differences from one another. We're on the same page then :) In your case you have boards that have no way to be probed about what they ‘are’, but that’s no big problem. You can easily pass the board variant in the kernel command line and use that to select the quirk to apply. Hans actually pointed out that this would just move the logic somewhere else, but not remove it. In our case, that would mean U-Boot (Hans being the U-Boot maintainer for the SoCs that are used in this particular board). That would still require us to have a different configuration and to add some logic to pass that extra parameter to the kernel. I'd be glad to have less stuff in the kernel, but I can understand that he doesn't want more stuff either. In fact the original patchset does contain a command line quirk for enabling and disabling the onboard emmc hdmi of the beaglebone black for capes that need to use those signals. Ah. I somehow overlooked that when reading it. Saying that, if you’re in a hurry I’d say go with a different DTSs for now, since that’s going to go in a near kernel cycle; DT quirks will be discussed at plumber’s in a couple of months, and then we’ll if it will go in and in what form. Ok. I won't be here this year, but if you could raise the topic of how to handle non-discoverable boards then, it would be great. Hans, I guess we can go for your suggestion then: apply a generic DT for the board right now, we're going to need it anyway. Then, when will have real display support, depending on the current state of the discussion for the quirks, we will either merge a different DT including the generic one, or if the quirks have something that work for both of us then, use the quirks. Sounds good? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] [RFC PATCH V3] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
The MSI Primo81 is an A31s based tablet, with 1G RAM, 16G NAND,
1024x768 IPS LCD display, mono speaker, 0.3 MP front camera, 2.0 MP
rear camera, 3500 mAh battery, gt911 touchscreen, mma8452 accelerometer
and rtl8188etv usb wifi. Has power, volume+ and volume- buttons
(both volume buttons are also connected to the UBOOT_SEL pin). The
external connectors are represented by MicroSD slot, MiniHDMI, MicroUSB
OTG and 3.5mm headphone jack. More details are available at
http://linux-sunxi.org/MSI_Primo81
This initial dts file only provides support for mmc, wifi and uart
(there is no external connector for uart though). Graphics can be used
via simplefb. However, without usb otg, there are no reasonable means
to handle user input yet.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Signed-off-by: Karsten Merker mer...@debian.org
---
.../devicetree/bindings/vendor-prefixes.txt| 1 +
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/sun6i-a31s-primo81.dts | 94 ++
3 files changed, 97 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 6a99dda..c415c2b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -127,6 +127,7 @@ mitsubishi Mitsubishi Electric Corporation
mosaixtech Mosaix Technologies, Inc.
moxa Moxa
mplMPL AG
+msiMicro-Star International Co. Ltd.
mtiImagination Technologies Ltd. (formerly MIPS Technologies Inc.)
mundoreaderMundo Reader S.L.
murata Murata Manufacturing Co., Ltd.
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 867e6e3..31686c7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -552,7 +552,8 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-i7.dtb \
sun6i-a31-m9.dtb \
sun6i-a31-mele-a1000g-quad.dtb \
- sun6i-a31s-cs908.dtb
+ sun6i-a31s-cs908.dtb \
+ sun6i-a31s-primo81.dtb
dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-bananapi.dtb \
sun7i-a20-bananapro.dtb \
diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
new file mode 100644
index 000..9c9b4bf
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
@@ -0,0 +1,94 @@
+/*
+ * Copyright 2014 Siarhei Siamashka siarhei.siamas...@gmail.com
+ * Copyright 2015 Karsten Merker mer...@debian.org
+ *
+ * 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.
+ *
+ * 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 sun6i-a31s.dtsi
+#include sunxi-common-regulators.dtsi
+
+/ {
+ model = MSI Primo81 tablet;
+ compatible = msi,primo81, allwinner,sun6i-a31s;
+
+ aliases {
+ serial0 = uart0;
+ };
+
+ chosen {
+ stdout-path = serial0:115200n8;
+ };
+
+};
+
+ehci0 {
+ /* rtl8188etv wifi is connected here */
+ status = okay;
+};
+
+mmc0 {
+
[linux-sunxi] [RFC PATCH V3] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
On Tue, Jun 16, 2015 at 11:40:27AM +0200, Maxime Ripard wrote:
What I meant in my previous review was to use the syntax
uart0 {
some-property;
};
Instead of duplicating the tree structure like you're doing
here. We've converted all the DT to that, so you can look around and
see how it's done in other boards (note that the nodes should be
sorted by alphabetical order).
Ah, sorry, I had misunderstood your original email in this regard.
Following is a reworked version of the patch.
Changelog:
Version 1
=
- Original patch by Siarhei Siamashka
Version 2
=
- Use symbolic instead of numeric pinctrl values.
- Change the include syntax from /include/ to #include to make
the dts build with current kernels.
Version 3
=
- Use labels for nodes with modifications in relation to the dtsi
instead of replicating the tree structure.
- Remove the FSF address from the license header as done in
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-May/340437.html
for the other dts files to remove a checkpatch warning.
- Add msi to the vendor prefix list.
- Remove earlyprintk from the default kernel commandline.
- Replace the console kernel commandline parameter by a
/chosen/stdout-path node and add an alias serial0 - uart0.
I have tagged this patch RFC as I am unsure what to do with the
/chosen/stdout-path node. For now, I have set Siarhei's original
choice (first serial port), but I am unsure whether this is the
right thing to do as the Primo81 does by default not have a
user-accessible serial port. The only way to get a serial
console is to either break the case open and find some test
points that carry the RX/TX lines (which with the Primo81 case
poses a high risk of breaking the display glass), or to use an SD
card breakout board and change the pinmuxing for the SD card pins
to the serial function. The latter would not work without
modifying the dts, so the SD-breakout case doesn't really count
for setting the default stdout-path in the general use case.
On the other hand, setting stdout-path to the serial port does
not seem to influence getting a a boot console on the LCD when
booting from a simplefb-capable u-boot, so there is probably no
harm in doing it.
Comments welcome :-).
Regards,
Karsten
--
Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
Werbung sowie der Markt- oder Meinungsforschung.
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v2 6/6] ARM: sun8i: dts: Add Ippo-q8h v1.2 with A33 and 1024x600 lcd support
Hi Maxime, On Jun 16, 2015, at 20:55 , Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi Pantelis, On Sun, Jun 14, 2015 at 09:16:21PM +0300, Pantelis Antoniou wrote: I think we need to discuss this with Pantelis and what is his feeling about this. Pantelis, to sum things up, we have a case of a tablet that comes with the exact same board, but coming in two flavours with two differents screen resolutions. It looks like a great case for your DT quirks work, but we have no way of runtime detecting the difference between the two variants. What do you think about this? Should we go with using the DT quirks or is this simply out of scope? There's not so much example of similar cases in the kernel, and none of them use quirks so far (obviously) but they all boil down to either the solution you were suggesting in that patch or adding the alternate configuration as a comment. I don't think the latter would work for you, and I agree with that, so I guess that depending on what Pantelis says, either we go with a better solution using the quirks, or we end up using what you suggested (with a nitpick though, I'd prefer if you used the display standard instead of the resolution, which would make it xga I guess?) First of all, the quirks interface is at an RFC stage (new name suggested is ‘variants’); getting that out of the way this seems like what it is designed to do. The idea of the DT quirks is to drastically cut down on the number of different DTs required, each different for each board with minute differences from one another. We're on the same page then :) Heh :) In your case you have boards that have no way to be probed about what they ‘are’, but that’s no big problem. You can easily pass the board variant in the kernel command line and use that to select the quirk to apply. Hans actually pointed out that this would just move the logic somewhere else, but not remove it. In our case, that would mean U-Boot (Hans being the U-Boot maintainer for the SoCs that are used in this particular board). That would still require us to have a different configuration and to add some logic to pass that extra parameter to the kernel. I'd be glad to have less stuff in the kernel, but I can understand that he doesn't want more stuff either. Well, I don’t know the specifics of your board, but if you have a configuration subset that works for all the boards and makes it at least possible to load a kernel (i.e. ram, serial, storage) you can keep a single bootloader that’s not full featured, but at least can boot any kind of variant. Afterwards you can just update the bootargs variable to the correct one for a given board. In fact the original patchset does contain a command line quirk for enabling and disabling the onboard emmc hdmi of the beaglebone black for capes that need to use those signals. Ah. I somehow overlooked that when reading it. Saying that, if you’re in a hurry I’d say go with a different DTSs for now, since that’s going to go in a near kernel cycle; DT quirks will be discussed at plumber’s in a couple of months, and then we’ll if it will go in and in what form. Ok. I won't be here this year, but if you could raise the topic of how to handle non-discoverable boards then, it would be great. Hans, I guess we can go for your suggestion then: apply a generic DT for the board right now, we're going to need it anyway. Then, when will have real display support, depending on the current state of the discussion for the quirks, we will either merge a different DT including the generic one, or if the quirks have something that work for both of us then, use the quirks. Sounds good? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com Regards — Pantelis -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Storage issue on linux-sunxi.org
Hi All, One of the partitions on linux-sunxi.org got full and requires attention. When you visit the website, it shows at the bottom of each page Warning: Unknown: write failed: No space left on device (28) in Unknown on line 0 Warning: Unknown: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/var/lib/php5) in Unknown on line 0 Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] New CedarX API documentation
On Mon, Jun 15, 2015 at 9:27 PM, Manuel Braga mul.br...@gmail.com wrote: I presume, i didn't tested, that those binaries in this dump are armhf. They are armhf. Simos -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: 2015 SBC survey by Linux Foundation/LinuxGizmos
On 16 June 2015 at 10:16, Carlo Caione carlo.cai...@gmail.com wrote: On Tue, Jun 16, 2015 at 10:14 AM, Michal Suchanek hramr...@gmail.com wrote: On 16 June 2015 at 10:09, Carlo Caione ca...@caione.org wrote: On Fri, Jun 12, 2015 at 3:52 PM, 'Simos Xenitellis' via linux-sunxi linux-sunxi@googlegroups.com wrote: What the RPi and ODroid do really well, is that they have a great active community, and that includes support even in non-technical levels. Even the ODROID-C1 does not fully support yet the mainline Linux kernel, http://forum.odroid.com/viewtopic.php?f=111t=8288 but the person working at the forum is there to answer honestly with Because the C1 Kernel had been heavily customized too much by SoC vendor, it is not easy to port the mainline kernel. If you really want to run the mainline Kernel, do NOT buy our C1 board. Sorry about that. With such an honest answer, I would go buy an ODROID-C1. Well, it was the same a couple of years ago for Allwinner, so I don't know why discouraging people to try to mainline the Amlogic SoCs. Amlogic SDK is a pain in the ass, but at least Amlogic is _extremely_ responsive (not at all like Allwinner, at the beginning at least) and usually the engineers are willing to provide datasheets and information (they wrote a datasheet from scratch just for me when I asked for some more info on clock trees). Last time I looked I had to sign a NDA to access the SDK so that's a no-go for me. this one? http://openlinux.amlogic.com:8000/download/ARM/kernel/ Maybe things have changed since then. When it was big news that Amlogic set up a developer community site I looked at it and I was required to register to access anything and had to sign a NDA to register. If they fixed the NDA thing then that's a good news. Some of the Amlogic chips look good spec-wise. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: 2015 SBC survey by Linux Foundation/LinuxGizmos
On 16 June 2015 at 10:09, Carlo Caione ca...@caione.org wrote: On Fri, Jun 12, 2015 at 3:52 PM, 'Simos Xenitellis' via linux-sunxi linux-sunxi@googlegroups.com wrote: What the RPi and ODroid do really well, is that they have a great active community, and that includes support even in non-technical levels. Even the ODROID-C1 does not fully support yet the mainline Linux kernel, http://forum.odroid.com/viewtopic.php?f=111t=8288 but the person working at the forum is there to answer honestly with Because the C1 Kernel had been heavily customized too much by SoC vendor, it is not easy to port the mainline kernel. If you really want to run the mainline Kernel, do NOT buy our C1 board. Sorry about that. With such an honest answer, I would go buy an ODROID-C1. Well, it was the same a couple of years ago for Allwinner, so I don't know why discouraging people to try to mainline the Amlogic SoCs. Amlogic SDK is a pain in the ass, but at least Amlogic is _extremely_ responsive (not at all like Allwinner, at the beginning at least) and usually the engineers are willing to provide datasheets and information (they wrote a datasheet from scratch just for me when I asked for some more info on clock trees). Last time I looked I had to sign a NDA to access the SDK so that's a no-go for me. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: 2015 SBC survey by Linux Foundation/LinuxGizmos
On Tue, Jun 16, 2015 at 10:21 AM, Michal Suchanek hramr...@gmail.com wrote: this one? http://openlinux.amlogic.com:8000/download/ARM/kernel/ Maybe things have changed since then. When it was big news that Amlogic set up a developer community site I looked at it and I was required to register to access anything and had to sign a NDA to register. You have to sign a NDA to access Android sources and (unfortunately) datasheets. This sucks, I agree. But at least you have free access to the kernel and u-boot sources (+ buildroot stuff and more). If they fixed the NDA thing then that's a good news. Some of the Amlogic chips look good spec-wise. Yep :) Sorry for the OT, -- Carlo Caione -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 00/20] ARM: dts: Add USB and OTG related nodes and enable on various boards
On Wed, Jun 10, 2015 at 03:27:08PM +0200, Hans de Goede wrote: Hi, On 08-06-15 12:03, Maxime Ripard wrote: Hi Hans, On Fri, Jun 05, 2015 at 09:02:03PM +0200, Hans de Goede wrote: Hi Maxime, Here is a patch-set with all the otg / sun8i-usb-host related dts patches I've accumulated. These are intended for 4.3, and go hand in hand with the outstanding musb-sunxi / phy-sun4i-usb patches, which I expect to be merged as is for 4.3 . I'm fine with these patches. Do you have a branch somewhere that I can pull (without the one that you wanted me to drop, obviously)? I've just created a branch with just these patches directly on top of sunxi/for-next for you: https://github.com/jwrdegoede/linux-sunxi/commits/otg-dts-for-maxime Queued for 4.3, thanks! While preparing this branch I noticed that the dts for the ippo q8h a33 tablets is not yet merged: http://www.spinics.net/lists/devicetree/msg82149.html You suggested to use the DT quirks interface instead of creating a separate dts for each board variant, and in the end I agreed, and asked you to merge it renamed to a more generic name without the lcd1024x600 bit in there. I can make it more generic and resend it myself. Do you want me to squash in the otg changes when I resend it, or shall I keep those separate ? Sorry for being so late on that, let's discuss this in the other thread. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH V2] ARM: dts: sun6i: Add dts file for MSI Primo81 tablet
Hi Karsten,
On Sun, Jun 14, 2015 at 08:55:06PM +0200, Karsten Merker wrote:
The MSI Primo81 is an A31s based tablet, with 1G RAM, 16G NAND,
1024x768 IPS LCD display, mono speaker, 0.3 MP front camera, 2.0 MP
rear camera, 3500 mAh battery, gt911 touchscreen, mma8452 accelerometer
and rtl8188etv usb wifi. Has power, volume+ and volume- buttons
(both volume buttons are also connected to the UBOOT_SEL pin). The
external connectors are represented by MicroSD slot, MiniHDMI, MicroUSB
OTG and 3.5mm headphone jack. More details are available at
http://linux-sunxi.org/MSI_Primo81
This initial dts file only provides support for mmc, wifi and uart
(there is no external connector for uart though). Graphics can be used
via simplefb. However, without usb otg, there are no reasonable means
to handle user input yet.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Signed-off-by: Karsten Merker mer...@debian.org
---
Changes since V1:
- Use symbolic instead of numeric pinctrl values as requested
by Maxime Ripard.
- Change the include syntax from /include/ to #include to make
the dts build with current kernels.
arch/arm/boot/dts/Makefile | 3 +-
arch/arm/boot/dts/sun6i-a31s-primo81.dts | 96
2 files changed, 98 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/boot/dts/sun6i-a31s-primo81.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 867e6e3..31686c7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -552,7 +552,8 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31-i7.dtb \
sun6i-a31-m9.dtb \
sun6i-a31-mele-a1000g-quad.dtb \
- sun6i-a31s-cs908.dtb
+ sun6i-a31s-cs908.dtb \
+ sun6i-a31s-primo81.dtb
dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-bananapi.dtb \
sun7i-a20-bananapro.dtb \
diff --git a/arch/arm/boot/dts/sun6i-a31s-primo81.dts
b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
new file mode 100644
index 000..8ac0bdd
--- /dev/null
+++ b/arch/arm/boot/dts/sun6i-a31s-primo81.dts
@@ -0,0 +1,96 @@
+/*
+ * Copyright 2014 Siarhei Siamashka siarhei.siamas...@gmail.com
+ * Copyright 2015 Karsten Merker mer...@debian.org
+ *
+ * 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 sun6i-a31s.dtsi
+#include sunxi-common-regulators.dtsi
+
+/ {
+ model = MSI Primo81 tablet;
+ compatible = msi,primo81, allwinner,sun6i-a31s;
+
+ chosen {
+ bootargs = earlyprintk console=ttyS0,115200;
earlyprintk should be removed from the default bootargs, and the
default console is set up using the stdout-path property these days.
+ };
+
+ soc@01c0 {
+ mmc0: mmc@01c0f000 {
+
