Re: [linux-sunxi] [PATCH u-boot-sunxi] sunxi: axp152: dcdc3 scale is 50mV / step not 25mV / step
Hi,
On 11/23/2014 07:23 PM, Siarhei Siamashka wrote:
On Mon, 13 Oct 2014 14:54:45 +0200
Hans de Goede hdego...@redhat.com wrote:
Currently uboot wrongly uses 25mV / step for dcdc3, this is a copy and paste
error introduced when adding the axp152_mvolt_to_target during review of the
axp152.c driver. This results in u-boot setting Vddr to 2.3V instead of 1.5V.
This commit fixes this.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
drivers/power/axp152.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/power/axp152.c b/drivers/power/axp152.c
index fa4ea05..27c2c4c 100644
--- a/drivers/power/axp152.c
+++ b/drivers/power/axp152.c
@@ -62,7 +62,7 @@ int axp152_set_dcdc2(int mvolt)
int axp152_set_dcdc3(int mvolt)
{
- u8 target = axp152_mvolt_to_target(mvolt, 700, 3500, 25);
+ u8 target = axp152_mvolt_to_target(mvolt, 700, 3500, 50);
return axp152_write(AXP152_DCDC3_VOLTAGE, target);
}
I have no hardware with AXP152 PMIC myself, but based on
http://irclog.whitequark.org/linux-sunxi/2014-10-20#10571381
we got Tested-by: Michal Suchanek hramr...@gmail.com
This patch fixes a regression introduced by the axp code cleanups did a
while back. The regression causes the DRAM voltage to be set to 2.3V
instead of 1.5V, this patch fixes this.
Please apply this to linux-sunxi/u-boot-sunxi ASAP.
You seem to have commit access to https://github.com/linux-sunxi/u-boot-sunxi
Is there any reason why this regression fix has not been pushed
there yet?
When I posted it I was traveling, and I only had upstream u-boot sources on
my laptop, since I knew that u-boot-sunxi has the same issue, I simply did
a git-send-email with the upstream patch to the linux-sunxi list, assuming
someone would quickly pick this important fix up...
Anyways I've pushed it now.
Regards,
Hans
--
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] linux backports
пятница, 21 ноября 2014 г., 22:37:53 UTC+3 пользователь Tim Tisdall написал:
Thanks. I think I was a little confused at how to use the tarballs. I tried
using those but now when I boot up I get plastered with:
compat: exports duplicate symbol clk_disable (owned by kernel)
Remove that code from the end of compat/compat-3.6.c :
/* whoopsie ! */
#ifndef CONFIG_COMMON_CLK
int clk_enable(struct clk *clk)
{
return 0;
}
EXPORT_SYMBOL_GPL(clk_enable);
void clk_disable(struct clk *clk)
{
}
EXPORT_SYMBOL_GPL(clk_disable);
#endif
--
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] [PATCH 3.4] sunxi: g2d: handle noop blits
Am 23.11.2014 22:04, schrieb Siarhei Siamashka:
On Fri, 7 Nov 2014 04:54:10 -0500
Andreas Baierl l...@imkreisrum.de wrote:
From: Andreas Baierl ich...@imkreisrum.de
Zero area blits are technically valid noops and are requested bay
libvdpau. Return 0 when blit area is zero without performing bogus
calculations.
This reverts commit 3303e27 but also catches the zero values
which were leading to failed calculations.
What kind of failed calculations? Do you mean the suspicious
checks like this:
+if(((para-src_rect.x 0)((-para-src_rect.x) para-src_rect.w)) ||
There has no following calculation or if-then-else be done at all if
src_rect.w/h and dst_rect.w/h are zero, because no action has to be
performed on zero sized src or dst areas?
So catching the zero values at the top with returning 0 would be the
better solution, as you mentioned further on.
Which do not catch a special case with negative para-src_rect.x where
(-para-src_rect.x == para-src_rect.w) and this causes troubles
further in the function? Or something else?
The above cases should also be catched to avoid doing mixer_blt this
areas and return 0?
Signed-off-by: Michal Suchanek hramr...@gmail.com
Signed-off-by: Andreas Baierl ich...@imkreisrum.de
---
drivers/char/sunxi_g2d/g2d.c | 27 ---
1 file changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/char/sunxi_g2d/g2d.c b/drivers/char/sunxi_g2d/g2d.c
index 288685a..085ace3 100644
--- a/drivers/char/sunxi_g2d/g2d.c
+++ b/drivers/char/sunxi_g2d/g2d.c
@@ -138,8 +138,7 @@ int g2d_blit(g2d_blt * para)
__s32 err = 0;
/* check the parameter valid */
-if(para-src_rect.w == 0 || para-src_rect.h == 0 ||
- ((para-src_rect.x 0)((-para-src_rect.x) para-src_rect.w)) ||
+if(((para-src_rect.x 0)((-para-src_rect.x) para-src_rect.w)) ||
((para-src_rect.y 0)((-para-src_rect.y) para-src_rect.h)) ||
((para-dst_x 0)((-para-dst_x) para-src_rect.w)) ||
((para-dst_y 0)((-para-dst_y) para-src_rect.h)) ||
@@ -153,6 +152,12 @@ int g2d_blit(g2d_blt * para)
}
else
{
+ if((para-dst_rect.w == 0) || (para-dst_rect.h == 0) ||
+ (para-src_rect.w == 0) || (para-src_rect.h == 0))
+ {
+ printk(KERN_DEBUG User requested g2d blit on zero
region\n);
If zero area blits are technically valid and really used, then spamming
the dmesg log is not a really great idea. It may lead to a severe
performance problems.
I agree.
Wouldn't an early check and return 0 (success) be a much better fix?
Maybe something like this:
if (para-src_rect.w == 0 || para-src_rect.h == 0)
return 0;
Yes, as mentioned above. What are valid and invalid parameters? In which
case we should return 0 or -1?
First of all, we have to ensure, that mixer_blt (and the others) are not
called with a para.src_rect.w(h) == 0 because this may cause problems
here:
https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/drivers/char/sunxi_g2d/g2d_bsp.c#L759
?
Correct me, if I'm wrong :p
Regards
Andreas
+ return err;
+ }
if(((para-src_rect.x 0)((-para-src_rect.x)
para-src_rect.w)))
{
para-src_rect.w = para-src_rect.w + para-src_rect.x;
@@ -205,8 +210,7 @@ int g2d_fill(g2d_fillrect * para)
__s32 err = 0;
/* check the parameter valid */
- if(para-dst_rect.w == 0 || para-dst_rect.h == 0 ||
- ((para-dst_rect.x 0)((-para-dst_rect.x)para-dst_rect.w)) ||
+ if(((para-dst_rect.x 0)((-para-dst_rect.x)para-dst_rect.w)) ||
((para-dst_rect.y 0)((-para-dst_rect.y)para-dst_rect.h)) ||
((para-dst_rect.x 0)(para-dst_rect.x para-dst_image.w - 1))
||
((para-dst_rect.y 0)(para-dst_rect.y para-dst_image.h - 1)))
@@ -216,6 +220,11 @@ int g2d_fill(g2d_fillrect * para)
}
else
{
+ if((para-dst_rect.w == 0) || (para-dst_rect.h == 0))
+ {
+ printk(KERN_DEBUG User requested g2d fill on zero
region\n);
+ return err;
+ }
if(((para-dst_rect.x 0)((-para-dst_rect.x)
para-dst_rect.w)))
{
para-dst_rect.w = para-dst_rect.w + para-dst_rect.x;
@@ -247,9 +256,7 @@ int g2d_stretchblit(g2d_stretchblt * para)
__s32 err = 0;
/* check the parameter valid */
-if(para-src_rect.w == 0 || para-src_rect.h == 0 ||
- para-dst_rect.w == 0 || para-dst_rect.h == 0 ||
- ((para-src_rect.x 0)((-para-src_rect.x) para-src_rect.w)) ||
+if(((para-src_rect.x 0)((-para-src_rect.x) para-src_rect.w)) ||
((para-src_rect.y 0)((-para-src_rect.y) para-src_rect.h)) ||
((para-dst_rect.x 0)((-para-dst_rect.x) para-dst_rect.w)) ||
((para-dst_rect.y 0)((-para-dst_rect.y) para-dst_rect.h)) ||
@@
Re: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
sön 2014-11-23 klockan 22:13 -0800 skrev RFat: Alright, the manual of the A80 is OUT! And looking good. Still several components without documentation, but a long way since A10. Regards Henrik -- 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 3/9] clk: sunxi: Add prcm mod0 clock driver
On Fri, Nov 21, 2014 at 10:13:10AM +0100, Hans de Goede wrote:
Hi,
On 11/21/2014 09:49 AM, Maxime Ripard wrote:
Hi,
On Thu, Nov 20, 2014 at 04:55:22PM +0100, Hans de Goede wrote:
Add a driver for mod0 clocks found in the prcm. Currently there is only
one mod0 clocks in the prcm, the ir clock.
Signed-off-by: Hans de Goede hdego...@redhat.com
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/Makefile| 2 +-
drivers/clk/sunxi/clk-sun6i-prcm-mod0.c | 63
+++
drivers/mfd/sun6i-prcm.c | 14 +
4 files changed, 79 insertions(+), 1 deletion(-)
create mode 100644 drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index ed116df..342c75a 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -56,6 +56,7 @@ Required properties:
allwinner,sun4i-a10-usb-clk - for usb gates + resets on A10 / A20
allwinner,sun5i-a13-usb-clk - for usb gates + resets on A13
allwinner,sun6i-a31-usb-clk - for usb gates + resets on A31
+ allwinner,sun6i-a31-ir-clk - for the ir clock on A31
Required properties for all clocks:
- reg : shall be the control register address for the clock.
diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
index 7ddc2b5..daf8b1c 100644
--- a/drivers/clk/sunxi/Makefile
+++ b/drivers/clk/sunxi/Makefile
@@ -10,4 +10,4 @@ obj-y += clk-sun8i-mbus.o
obj-$(CONFIG_MFD_SUN6I_PRCM) += \
clk-sun6i-ar100.o clk-sun6i-apb0.o clk-sun6i-apb0-gates.o \
- clk-sun8i-apb0.o
+ clk-sun8i-apb0.o clk-sun6i-prcm-mod0.o
diff --git a/drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
b/drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
new file mode 100644
index 000..e80f18e
--- /dev/null
+++ b/drivers/clk/sunxi/clk-sun6i-prcm-mod0.c
@@ -0,0 +1,63 @@
+/*
+ * Allwinner A31 PRCM mod0 clock driver
+ *
+ * Copyright (C) 2014 Hans de Goede hdego...@redhat.com
+ *
+ * This program 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 program 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.
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/platform_device.h
+
+#include clk-factors.h
+#include clk-mod0.h
+
+static const struct of_device_id sun6i_a31_prcm_mod0_clk_dt_ids[] = {
+ { .compatible = allwinner,sun6i-a31-ir-clk },
+ { /* sentinel */ }
+};
+
+static DEFINE_SPINLOCK(sun6i_prcm_mod0_lock);
+
+static int sun6i_a31_prcm_mod0_clk_probe(struct platform_device *pdev)
+{
+ struct device_node *np = pdev-dev.of_node;
+ struct resource *r;
+ void __iomem *reg;
+
+ if (!np)
+ return -ENODEV;
+
+ r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ reg = devm_ioremap_resource(pdev-dev, r);
+ if (IS_ERR(reg))
+ return PTR_ERR(reg);
+
+ sunxi_factors_register(np, sun4i_a10_mod0_data,
+ sun6i_prcm_mod0_lock, reg);
+ return 0;
+}
+
+static struct platform_driver sun6i_a31_prcm_mod0_clk_driver = {
+ .driver = {
+ .name = sun6i-a31-prcm-mod0-clk,
+ .of_match_table = sun6i_a31_prcm_mod0_clk_dt_ids,
+ },
+ .probe = sun6i_a31_prcm_mod0_clk_probe,
+};
+module_platform_driver(sun6i_a31_prcm_mod0_clk_driver);
+
+MODULE_DESCRIPTION(Allwinner A31 PRCM mod0 clock driver);
+MODULE_AUTHOR(Hans de Goede hdego...@redhat.com);
+MODULE_LICENSE(GPL);
I don't think this is the right approach, mainly for two reasons: the
compatible shouldn't change, and you're basically duplicating code
there.
I understand that you need the new compatible in order to avoid a
double probing: one by CLK_OF_DECLARE, and one by the usual mechanism,
and that also implies the second reason.
Not only for that, we need a new compatible also because the mfd framework
needs a separate compatible per sub-node as that is how it finds nodes
to attach to the platform devices, so we need a new compatible anyways,
with your make the mod0 clock driver a platform driver solution we could
use:
We have a single mod0 clock in there, so no, not really.
Plus, that seems like a bogus limitation from MFD, and it really
shouldn't work that way.
compatible = allwinner,sun6i-a31-ir-clk,
allwinner,sun4i-a10-mod0-clk;
To work
[linux-sunxi] cx231xx video capture error
Hello All, I've been trying without success to capture video from a PixelView XCapture USB card, using the cx231xx driver module and ffmpeg on a CubieBoard2 (A20). After loading the driver module successfully, I run ffmpeg that captures one single empty frame. When I quit ffmpeg the kernel issues the following error messages: cx231xx #0: UsbInterface::sendCommand, failed with status --71 cx231xx #0: UsbInterface::sendCommand, failed with status --71 cx231xx #0: cx231xx_stop_stream():: ep_mask = 8 cx231xx #0: can't change interface 4 alt no. to 0 (err=-71) I'm using kernel version 3.4.103, and buildroot to build the root file system. V4L2 where compiled as modules. Some extra information about my system are provided further down. Thanks in advance. Any help would be much appreciated. Regards, Weber # lsmod Module Size Used byNot tainted cx231xx_alsa8081 0 cx2584096576 1 cx231xx 149960 1 cx231xx_alsa cx2341x18988 1 cx231xx videobuf_vmalloc5478 1 cx231xx videobuf_core 20077 2 cx231xx,videobuf_vmalloc v4l2_common 9035 3 cx25840,cx231xx,cx2341x videodev 90988 4 cx25840,cx231xx,cx2341x,v4l2_common rc_core21002 1 cx231xx mali 111750 0 ump51021 1 mali # dmesg [...information truncated ...] [ 20.114304] Linux video capture interface: v2.00 [ 20.322307] cx231xx #0: New device Conexant Corporation VT105B @ 480 Mbps (1554:5014) with 6 interfaces [ 20.340444] cx231xx #0: registering interface 1 [ 20.355726] cx231xx #0: Identified as Pixelview Xcapture USB (card=11) [ 20.500196] cx231xx #0: cx231xx_dif_set_standard: setStandard to [ 20.633024] cx25840 2-0044: cx23102 A/V decoder found @ 0x88 (cx231xx #0) [ 20.675001] cx25840 2-0044: Firmware download size changed to 16 bytes max length [ 22.781357] cx25840 2-0044: loaded v4l-cx231xx-avcore-01.fw firmware (16382 bytes) [ 22.833033] cx231xx #0: cx231xx #0: v4l2 driver version 0.0.2 [ 22.878820] cx231xx #0: cx231xx_dif_set_standard: setStandard to [ 22.937947] cx231xx #0: video_mux : 0 [ 22.950601] cx231xx #0: do_mode_ctrl_overrides : 0xb000 [ 22.965287] cx231xx #0: do_mode_ctrl_overrides NTSC [ 22.987618] cx231xx #0: cx231xx #0/0: registered device video0 [v4l2] [ 23.013709] cx231xx #0: cx231xx #0/0: registered device vbi0 [ 23.029487] cx231xx #0: V4L2 device registered as video0 and vbi0 [ 23.040632] cx231xx #0: EndPoint Addr 0x84, Alternate settings: 5 [ 23.045129] cx231xx #0: Alternate setting 0, max size= 512 [ 23.049566] cx231xx #0: Alternate setting 1, max size= 184 [ 23.060094] cx231xx #0: Alternate setting 2, max size= 728 [ 23.070090] cx231xx #0: Alternate setting 3, max size= 2892 [ 23.084715] cx231xx #0: Alternate setting 4, max size= 1800 [ 23.095242] cx231xx #0: EndPoint Addr 0x85, Alternate settings: 2 [ 23.105238] cx231xx #0: Alternate setting 0, max size= 512 [ 23.115241] cx231xx #0: Alternate setting 1, max size= 512 [ 23.126363] cx231xx #0: EndPoint Addr 0x86, Alternate settings: 2 [ 23.136277] cx231xx #0: Alternate setting 0, max size= 512 [ 23.146187] cx231xx #0: Alternate setting 1, max size= 576 [ 23.157307] cx231xx #0: EndPoint Addr 0x81, Alternate settings: 6 [ 23.167218] cx231xx #0: Alternate setting 0, max size= 512 [ 23.177057] cx231xx #0: Alternate setting 1, max size= 64 [ 23.187573] cx231xx #0: Alternate setting 2, max size= 128 [ 23.197482] cx231xx #0: Alternate setting 3, max size= 316 [ 23.201929] cx231xx #0: Alternate setting 4, max size= 712 [ 23.211830] cx231xx #0: Alternate setting 5, max size= 1424 [ 23.222779] usbcore: registered new interface driver cx231xx [ 23.272446] cx231xx #0: cx231xx-audio.c: probing for cx231xx non standard usbaudio [ 23.300792] cx231xx #0: EndPoint Addr 0x83, Alternate settings: 3 [ 23.325532] cx231xx #0: Alternate setting 0, max size= 512 [ 23.339459] cx231xx #0: Alternate setting 1, max size= 28 [ 23.353201] cx231xx #0: Alternate setting 2, max size= 52 [ 23.366723] cx231xx: Cx231xx Audio Extension initialized [ 53.145845] cx231xx #0: setPowerMode::mode = 48, No Change req. [ 53.227701] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8 [ 53.251282] cx231xx #0: cx231xx_initialize_stream_xfer: set video registers [ 53.270197] cx231xx #0: cx231xx_start_stream():: ep_mask = 8 [ 157.753811] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 157.779297] cx231xx #0: UsbInterface::sendCommand, failed with status --71 [ 157.879895] cx231xx #0: cx231xx_stop_stream():: ep_mask = 8 [ 157.907651] cx231xx #0: can't change interface 4 alt no. to 0 (err=-71) -- 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
Re: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
Thanks Kevin. Feeling more comfortable with AllWinner SoC, particularly the A80. 2015 will be an excellent year for Allwinner, I will include AW on my products and Engineer recommendations. Javqui On Monday, November 24, 2014 1:13:22 AM UTC-5, RFat wrote: Alright, the manual of the A80 is OUT! (https://github.com/allwinner-zh/documents) Thanks a lot Kevin! -R On Tuesday, October 14, 2014 4:39:06 AM UTC+3, Zhao Zhili wrote: You are right. China have suffer too much from idealism. Now they come to the other way. Don't say something too beautiful to them, they don't believe that and think you are a cheater. On Mon, Oct 13, 2014 at 08:11:40AM -0700, jacky lau wrote: I agree with you and Jhon Yi. Developing a soc is not too hard now, getting customers is harder and more important. I hope the market will force all China Soc company more open. But before that happen, I don't think they will become more open. They don't have experience in working with the open source community, if you want them to be more open, you need to do more communicate with them. And remember, to them, neither the law nor the spirit of free software, but making money is paramount. Tell them they will get more customers, make more money and prove it, then they will follow. 在 2014年10月11日星期六UTC+8下午10时53分48秒，Jon Smirl写道： On Sat, Oct 11, 2014 at 10:31 AM, jacky lau i90...@gmail.com javascript: wrote: A big client will buy thousands of chips once. Are there any relation between big client and user manual publishing? No. So they don't think it's necessary to open their private property. When you are a big client, you are VIP, all document and source code is open to you. And if publish all technical documentation, competitors will know some technical secret (e.g. bug;) they don't want them to know. Open world is beautiful, but they will not actively participate if there is no return. Why some China soc company publish some documents and source code now? I think this is mainly for marketing. But no matter how, VIP priority. Right now Allwinner is only good for tablets and STBs because Allwinner supplies turnkey solutions. If documentation were more open other applications could be developed. If customer can't get software working for these other applications, they won't buy thousands of chips. So if Allwinner wants to survive past the end of the tablet fad they have to start developing these other markets. Otherwise when the tablet fad is over it will be the end of Allwinner. You also over estimate the value of technical secrets. What is the point of putting a secret h.264 encode/decode unit on the chip if half of your customers can't get it working? Obviously Rockchip knows how to make h.264 encode/decode since they have a similar unit on their chip. And so does Freescale, TI, ST, etc. -- there is no big secret in making h.264 hardware for people familiar with how to do it (hint, it is an ISO standard). So by keeping the documentation secret you hide nothing significant from your competitors and much, much worse -- you keep your own customers from using the hardware they bought. Think about it --- which is more important - hiding something form a competitor that they probably already know, or getting your customers to ship and buy more chips? Bottom line - which one brings cash in the door - secret documentation or getting as many customers as possible to ship? 在 2014年10月6日星期一UTC+8下午8时55分30秒，RFat写道： Hi Kevin, Publishing the user manuals will certainly increase Allwinner's chips popularity. I was wondering if there is a rough estimate as to when the A80's manual will be made available? Thanks! Raanan On Monday, September 29, 2014 12:46:53 PM UTC+3, ke...@allwinnertech.com wrote: Hi All, I have put the documents on github, and the url is https://github.com/allwinner-zh/documents.git Thanks Simos, Henrik and Luc's suggestion. And other documents will be upated to here when released. Best Regards, kevin.z.m From: HenrikNordström Date: 2014-09-29 08:46 To: linux...@googlegroups.com CC: sh...@allwinnertech.com; Meng Zhang Subject: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s sön 2014-09-28 klockan 02:18 +0200 skrev Luc Verhaegen: Why didn't someone from Allwinner send these documents in him/herself? The current person discussion the matter with Allwiner was Simos, who is part of the linux-sunxi community. Allwinner sent current versions of
Re: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
Thanks Kevin. Feeling more comfortable with AllWinner SoC, particularly the A80. 2015 will be an excellent year for Allwinner, I will include AW on my products and Engineer recommendations. Javqui On Monday, November 24, 2014 1:13:22 AM UTC-5, RFat wrote: Alright, the manual of the A80 is OUT! (https://github.com/allwinner-zh/documents) Thanks a lot Kevin! -- 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.
