date:20140102


Hi,

On 01/02/2014 12:57 AM, Siarhei Siamashka wrote:

snip


Maybe just send a mail to the relevant upstream list explaining
we've an ip block which (seems) to be limited to dma below
256MB and needs cma, so we want a cma block below 256MB, but we
don't want to set the DMA_ZONE for the entire system to that as
other ip blocks in the SoC don't have this limit, and see what
kind of solutions get suggested ?


CMA is quite flexible, and it is possible to have multiple CMA
areas in different places. So that we can have a dedicated area
for cedar below 256MB, and separate CMA area somewhere else for
disp and g2d.

DMA_ZONE is just one of the ways to specify an upper limit. And because
sun7i was already using DMA_ZONE (for whatever reason), there is some
additional value in unification between sun4i/sun5i/sun7i.


Ok.


And by the way, the 256MB cedar addressing limitation got confirmed.
It just seems to be inconsistent for different supported media formats:
 http://irclog.whitequark.org/linux-sunxi/2013-12-27#5993708;
So I have not been fighting with windmills after all ;)


Note I realize we won't have cedar support upstream any time
soon,


Why not? Cedar appears to be a relatively simple hardware and
needs a relatively simple driver. This of course does not make
the reverse engineering achievement less impressive.


Oh, I'm all in favor of getting cedar support upstream, I was just
thinking that since we also lack any display output capability atm,
getting it upstream would be something to do later.


but it seems like a good idea to get this discussion started,
and maybe a solution created, well before we even start looking
into upstream cedar support.


The biggest design problem of the current allwiner cedar kernel driver
is total lack of any security.

Now an interesting question is what kind of frameworks are mandatory
in the kernel for safely sharing the buffers between different
drivers and the userspace. And whether they are going to skyrocket
the complexity and hinder performance.


I think the cedar is best exported to userspace as a v4l2 mem 2 mem
device. the v4l2 api is quite efficient wrt sending large amounts
of buffers. And the v4l2 core has code to make v4l2 buffers accessible
through dmabuf, so that they could for example be shared with the
gpu.


But first we can do a better VDPAU integration with X11 for sunxi-3.4
kernel. So that the end users can become really happy sooner. And this
kind of research/prototyping work is not a wasted effort anyway.


Agreed.

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/groups/opt_out.

[linux-sunxi] Re: [PATCH 1/4] input: Add new sun4i-lradc-keys drivers


Hi,

On 01/01/2014 09:56 PM, Dmitry Torokhov wrote:

Hi Hans,

On Wed, Jan 01, 2014 at 08:30:07PM +0100, Hans de Goede wrote:

+Required properties:
+ - compatible: allwinner,sun4i-lradc-keys
+ - reg: mmio address range of the chip
+ - interrupts: interrupt to which the chip is connected
+ - allwinner,chan0-step: step in mV between keys must be 150 or 200
+ - allwinner,chan0-keycodes: array of include/uapi/linux/input.h KEY_ codes


I think this should be linux,chan0-keycodes.


Right, because the codes are Linux specific, will fix in v2.

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/groups/opt_out.

[linux-sunxi] Explain the contents of bootloader...

2014-01-02 Thread Puneet B

Hi i flashed the cubieboard image to sd card from this link.

https://docs.google.com/file/d/0B-bAEPML8fwlUFd5OHVOaFJIRmc/edit.

then in Volumn(bootlaoder)  folder of sdcard i got fallowing binaries.

1.boot.axf 
2.boot_signature.axf  
3.drv_hdmi.drv  
4.font32.sft  
5.magic.bin  
6.prvt.axf
7.script.bin
8.boot.ini  
9.drv_de.drv   
10.font24.sft   
11.linux   - linux.bmp  linux.ini  u-boot.bin (sub contents).  
12.os_show   -bat0.bmp   bat2.bmp  bat5.bmp  bat8.bmp bempty.bmp
full.bmplinux2.bmp   melis2.bmp   wince1.bmp
  bat10.bmp  bat3.bmp  bat6.bmp  bat9.bmp bootlogo.bmp  
head.bmplow_pwr.bmp  startup.bmp  wince2.bmp
  bat1.bmp   bat4.bmp  bat7.bmp  battery.bmp  empty.bmp 
linux1.bmp  melis1.bmp   tail.bmp

 
13.script0.bin  
14.sprite.axf


Out of these i know script.bin , and u-boot.bin (but i flashed to /dev/sdc 
).

Kindly tell what will be purpose of remaining binaries.

and tell me what will be difference between boot0 ,boot1 and sunxi-spl.bin 
,u-boot.bin.

Regards
Punith

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH v2 0/4] input: Add new sun4i-lradc-keys driver

Hi Dimitri et al,

Here is v2 of the sun4i-lradc-keys driver, changes since v1:

- Use include/dt-bindings/input/input.h
- Rename the keycodes property to linux,chan0-keycodes

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/groups/opt_out.

[linux-sunxi] [PATCH v2 3/4] ARM: dts: sun5i: Add lradc node

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts | 8 
 arch/arm/boot/dts/sun5i-a10s.dtsi| 7 +++
 arch/arm/boot/dts/sun5i-a13-olinuxino.dts| 8 
 arch/arm/boot/dts/sun5i-a13.dtsi | 7 +++
 4 files changed, 30 insertions(+)

diff --git a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
index e53fb12..d93318a 100644
--- a/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun5i-a10s-olinuxino-micro.dts
@@ -13,6 +13,7 @@
 
 /dts-v1/;
 /include/ sun5i-a10s.dtsi
+#include dt-bindings/input/input.h
 
 / {
model = Olimex A10s-Olinuxino Micro;
@@ -75,6 +76,13 @@
};
};
 
+   lradc: lradc@01c22800 {
+   allwinner,chan0-step = 200;
+   linux,chan0-keycodes = KEY_VOLUMEUP KEY_VOLUMEDOWN
+   KEY_MENU KEY_ENTER KEY_HOME;
+   status = okay;
+   };
+
uart0: serial@01c28000 {
pinctrl-names = default;
pinctrl-0 = uart0_pins_a;
diff --git a/arch/arm/boot/dts/sun5i-a10s.dtsi 
b/arch/arm/boot/dts/sun5i-a10s.dtsi
index 34dd303..8775bad 100644
--- a/arch/arm/boot/dts/sun5i-a10s.dtsi
+++ b/arch/arm/boot/dts/sun5i-a10s.dtsi
@@ -404,6 +404,13 @@
reg = 0x01c20c90 0x10;
};
 
+   lradc: lradc@01c22800 {
+   compatible = allwinner,sun4i-lradc-keys;
+   reg = 0x01c22800 0x100;
+   interrupts = 31;
+   status = disabled;
+   };
+
sid: eeprom@01c23800 {
compatible = allwinner,sun4i-sid;
reg = 0x01c23800 0x10;
diff --git a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts 
b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
index ab566f7..4e99f43 100644
--- a/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
+++ b/arch/arm/boot/dts/sun5i-a13-olinuxino.dts
@@ -13,6 +13,7 @@
 
 /dts-v1/;
 /include/ sun5i-a13.dtsi
+#include dt-bindings/input/input.h
 
 / {
model = Olimex A13-Olinuxino;
@@ -55,6 +56,13 @@
};
};
 
+   lradc: lradc@01c22800 {
+   allwinner,chan0-step = 200;
+   linux,chan0-keycodes = KEY_VOLUMEUP KEY_VOLUMEDOWN
+   KEY_MENU KEY_ENTER KEY_HOME;
+   status = okay;
+   };
+
uart1: serial@01c28400 {
pinctrl-names = default;
pinctrl-0 = uart1_pins_b;
diff --git a/arch/arm/boot/dts/sun5i-a13.dtsi b/arch/arm/boot/dts/sun5i-a13.dtsi
index 264cfa4..90c1ed3 100644
--- a/arch/arm/boot/dts/sun5i-a13.dtsi
+++ b/arch/arm/boot/dts/sun5i-a13.dtsi
@@ -362,6 +362,13 @@
reg = 0x01c20c90 0x10;
};
 
+   lradc: lradc@01c22800 {
+   compatible = allwinner,sun4i-lradc-keys;
+   reg = 0x01c22800 0x100;
+   interrupts = 31;
+   status = disabled;
+   };
+
sid: eeprom@01c23800 {
compatible = allwinner,sun4i-sid;
reg = 0x01c23800 0x10;
-- 
1.8.4.2

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH v2 4/4] ARM: dts: sun7i: Add lradc node

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 9 +
 arch/arm/boot/dts/sun7i-a20.dtsi| 7 +++
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index 0ee2641..2c9a38f 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -13,6 +13,7 @@
 
 /dts-v1/;
 /include/ sun7i-a20.dtsi
+#include dt-bindings/input/input.h
 
 / {
model = Olimex A20-Olinuxino Micro;
@@ -86,6 +87,14 @@
};
};
 
+   lradc: lradc@01c22800 {
+   allwinner,chan0-step = 200;
+   linux,chan0-keycodes = KEY_VOLUMEUP KEY_VOLUMEDOWN
+   KEY_MENU KEY_SEARCH KEY_HOME
+   KEY_ESC KEY_ENTER;
+   status = okay;
+   };
+
uart0: serial@01c28000 {
pinctrl-names = default;
pinctrl-0 = uart0_pins_a;
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 68e825a..3484275 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -531,6 +531,13 @@
interrupts = 0 24 1;
};
 
+   lradc: lradc@01c22800 {
+   compatible = allwinner,sun4i-lradc-keys;
+   reg = 0x01c22800 0x100;
+   interrupts = 0 31 4;
+   status = disabled;
+   };
+
sid: eeprom@01c23800 {
compatible = allwinner,sun7i-a20-sid;
reg = 0x01c23800 0x200;
-- 
1.8.4.2

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH v2 1/4] input: Add new sun4i-lradc-keys driver

Allwinnner sunxi SoCs have a low resolution adc (called lradc) which is
specifically designed to have various (tablet) keys (ie home, back, search,
etc). attached to it using a resistor network. This adds a driver for this.

There are 2 channels, currently this driver only supports chan0 since there
are no boards known to use chan1. The devicetree properties are already
prefixed with chan0 as preparation for chan1 support in the future.

This has been tested on an olimex a10s-olinuxino-micro, a13-olinuxino, and
a20-olinuxino-micro.

Signed-off-by: Hans de Goede hdego...@redhat.com
---
 .../devicetree/bindings/input/sun4i-lradc-keys.txt |  22 ++
 drivers/input/keyboard/Kconfig |  10 +
 drivers/input/keyboard/Makefile|   1 +
 drivers/input/keyboard/sun4i-lradc-keys.c  | 243 +
 4 files changed, 276 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
 create mode 100644 drivers/input/keyboard/sun4i-lradc-keys.c

diff --git a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt 
b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
new file mode 100644
index 000..7801264
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
@@ -0,0 +1,22 @@
+Allwinner sun4i low res adc attached tablet keys
+
+
+Required properties:
+ - compatible: allwinner,sun4i-lradc-keys
+ - reg: mmio address range of the chip
+ - interrupts: interrupt to which the chip is connected
+ - allwinner,chan0-step: step in mV between keys must be 150 or 200
+ - linux,chan0-keycodes: array of dt-bindings/input/input.h KEY_ codes
+
+Example:
+
+#include dt-bindings/input/input.h
+
+   lradc: lradc@01c22800 {
+   compatible = allwinner,sun4i-lradc-keys;
+   reg = 0x01c22800 0x100;
+   interrupts = 31;
+   allwinner,chan0-step = 200;
+   linux,chan0-keycodes = KEY_VOLUMEUP KEY_VOLUMEDOWN
+   KEY_MENU KEY_ENTER KEY_HOME;
+   };
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index bb174c1..d95e6e4 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -544,6 +544,16 @@ config KEYBOARD_STMPE
  To compile this driver as a module, choose M here: the module will be
  called stmpe-keypad.
 
+config KEYBOARD_SUN4I_LRADC
+   tristate Allwinner sun4i low res adc attached tablet keys support
+   depends on ARCH_SUNXI
+   help
+ This selects support for the Allwinner low res adc attached tablet
+ keys found on Allwinner sunxi SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sun4i-lradc-keys.
+
 config KEYBOARD_DAVINCI
tristate TI DaVinci Key Scan
depends on ARCH_DAVINCI_DM365
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index a699b61..f3265bd 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -50,6 +50,7 @@ obj-$(CONFIG_KEYBOARD_SH_KEYSC)   += sh_keysc.o
 obj-$(CONFIG_KEYBOARD_SPEAR)   += spear-keyboard.o
 obj-$(CONFIG_KEYBOARD_STMPE)   += stmpe-keypad.o
 obj-$(CONFIG_KEYBOARD_STOWAWAY)+= stowaway.o
+obj-$(CONFIG_KEYBOARD_SUN4I_LRADC) += sun4i-lradc-keys.o
 obj-$(CONFIG_KEYBOARD_SUNKBD)  += sunkbd.o
 obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
 obj-$(CONFIG_KEYBOARD_TEGRA)   += tegra-kbc.o
diff --git a/drivers/input/keyboard/sun4i-lradc-keys.c 
b/drivers/input/keyboard/sun4i-lradc-keys.c
new file mode 100644
index 000..5c55e17
--- /dev/null
+++ b/drivers/input/keyboard/sun4i-lradc-keys.c
@@ -0,0 +1,243 @@
+/*
+ * Allwinner sun4i low res adc attached tablet keys 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.
+ */
+
+/*
+ * Allwinnner sunxi SoCs have a lradc which is specifically designed to have
+ * various (tablet) keys (ie home, back, search, etc). attached to it using
+ * a resistor network. This driver is for the keys on such boards.
+ *
+ * There are 2 channels, currently this driver only supports chan0 since there
+ * are no boards known to use chan1. The devicetree properties are already
+ * prefixed with chan0 as preparation for chan1 support in the future.
+ */
+
+#include linux/err.h
+#include

Re: [linux-sunxi] ARM: PSCI: fix PSCI DT nodes generation failure


Hi,

On 01/02/2014 06:42 AM, Ma Haijun wrote:

Hi,

This patch fix non-boot CPU bringing up failure due to lack of PSCI node,
which is reported by Tim Fletcher.
It is patched against the sunxi-next branch of
https://github.com/jwrdegoede/u-boot-sunxi.git


Thanks, added to my sunxi-next branch and pushed to the above repository.

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/groups/opt_out.

[linux-sunxi] [PATCH] sunxi: Add Inet K70HC device

Signed-off-by: Luc Verhaegen l...@skynet.be
---
 board/sunxi/Makefile  |1 +
 board/sunxi/dram_inet_k70hc.c |   31 +++
 boards.cfg|1 +
 3 files changed, 33 insertions(+), 0 deletions(-)
 create mode 100644 board/sunxi/dram_inet_k70hc.c

diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 7fefdf0..f274a1d 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_HACKBERRY)   += dram_hackberry.o
 obj-$(CONFIG_A7HD) += dram_sun4i_360_1024_iow8.o
 obj-$(CONFIG_INTERRA3) += dram_mk802ii_a20.o
 obj-$(CONFIG_INET97F_II)   += dram_sun4i_408_512.o
+obj-$(CONFIG_INET_K70HC)   += dram_inet_k70hc.o
 obj-$(CONFIG_JESURUN_Q5)   += dram_sun4i_312_1024_iow8.o
 obj-$(CONFIG_K1001L1C) += dram_a20_olinuxino_m.o
 obj-$(CONFIG_MEFAFEIS_A08) += dram_megafeis_a08.o
diff --git a/board/sunxi/dram_inet_k70hc.c b/board/sunxi/dram_inet_k70hc.c
new file mode 100644
index 000..d5ddc13
--- /dev/null
+++ b/board/sunxi/dram_inet_k70hc.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include common.h
+#include asm/arch/dram.h
+
+static struct dram_para dram_para = {
+   .clock = 384,
+   .type = 3,
+   .rank_num = 1,
+   .density = 4096,
+   .io_width = 16,
+   .bus_width = 32,
+   .cas = 9,
+   .zq = 0x12331a7f,
+   .odt_en = 0,
+   .size = 1024,
+   .tpr0 = 0x42d899b7,
+   .tpr1 = 0xa090,
+   .tpr2 = 0x22a00,
+   .tpr3 = 0,
+   .tpr4 = 1,
+   .tpr5 = 0,
+   .emr1 = 0x4,
+   .emr2 = 0x10,
+   .emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+   return dramc_init(dram_para);
+}
diff --git a/boards.cfg b/boards.cfg
index 7eeb17a..eda05de 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -380,6 +380,7 @@ Active  arm armv7  sunxi   -
   sunxi
 Active  arm armv7  sunxi   -   sunxi   
Hyundai_A7HD sun4i:A7HD,SPL 

   -
 Active  arm armv7  sunxi   -   sunxi   
Interra-3
sun7i:INTERRA3,SPL,SUNXI_GMAC,FAST_MBUS,MMC_SUNXI_SLOT=2
  -
 Active  arm armv7  sunxi   -   sunxi   
INet97F-II   sun4i:INET97F_II,SPL   

   -
+Active  arm armv7  sunxi   -   sunxi   
INet_K70HC   sun7i:INET_K70HC,SPL   

   -
 Active  arm armv7  sunxi   -   sunxi   
Jesurun-Q5   
sun4i:JESURUN_Q5,SPL,SUNXI_EMAC,STATUSLED=244   
  -
 Active  arm armv7  sunxi   -   sunxi   
K1001L1C sun7i:K1001L1C,SPL 

   -
 Active  arm armv7  sunxi   -   sunxi   
Marsboard_A10
sun4i:MARSBOARD_A10,SPL,SUNXI_EMAC,NO_AXP   
  -
-- 
1.7.7

-- 
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/groups/opt_out.

[linux-sunxi] [PATCH] add inet k70hc

Signed-off-by: Luc Verhaegen l...@skynet.be
---
 sys_config/a20/inet_k70hc.fex | 1008 +
 1 files changed, 1008 insertions(+), 0 deletions(-)
 create mode 100644 sys_config/a20/inet_k70hc.fex

diff --git a/sys_config/a20/inet_k70hc.fex b/sys_config/a20/inet_k70hc.fex
new file mode 100644
index 000..66fd3cc
--- /dev/null
+++ b/sys_config/a20/inet_k70hc.fex
@@ -0,0 +1,1008 @@
+[product]
+version = 100
+machine = K701HC
+
+[platform]
+eraseflag = 1
+
+[target]
+boot_clock = 912
+dcdc2_vol = 1400
+dcdc3_vol = 1250
+ldo2_vol = 3000
+ldo3_vol = 2800
+ldo4_vol = 2800
+power_start = 0
+storage_type = -1
+
+[clock]
+pll3 = 297
+pll4 = 300
+pll6 = 600
+pll7 = 297
+pll8 = 336
+
+[card_boot]
+logical_start = 40960
+sprite_gpio0 =
+
+[card0_boot_para]
+card_ctrl = 0
+card_high_speed = 1
+card_line = 4
+sdc_d1 = port:PF0021defaultdefault
+sdc_d0 = port:PF0121defaultdefault
+sdc_clk = port:PF0221defaultdefault
+sdc_cmd = port:PF0321defaultdefault
+sdc_d3 = port:PF0421defaultdefault
+sdc_d2 = port:PF0521defaultdefault
+
+[card2_boot_para]
+card_ctrl = 2
+card_high_speed = 1
+card_line = 4
+sdc_cmd = port:PC0631defaultdefault
+sdc_clk = port:PC0731defaultdefault
+sdc_d0 = port:PC0831defaultdefault
+sdc_d1 = port:PC0931defaultdefault
+sdc_d2 = port:PC1031defaultdefault
+sdc_d3 = port:PC1131defaultdefault
+
+[twi_para]
+twi_port = 0
+twi_scl = port:PB002defaultdefaultdefault
+twi_sda = port:PB012defaultdefaultdefault
+
+[uart_para]
+uart_debug_port = 0
+uart_debug_tx = port:PB2221defaultdefault
+uart_debug_rx = port:PB2321defaultdefault
+
+[uart_force_debug]
+uart_debug_port = 0
+uart_debug_tx = port:PF0241defaultdefault
+uart_debug_rx = port:PF0441defaultdefault
+
+[jtag_para]
+jtag_enable = 0
+jtag_ms = port:PB143defaultdefaultdefault
+jtag_ck = port:PB153defaultdefaultdefault
+jtag_do = port:PB163defaultdefaultdefault
+jtag_di = port:PB173defaultdefaultdefault
+
+[pm_para]
+standby_mode = 1
+
+[dram_para]
+dram_baseaddr = 0x4000
+dram_clk = 384
+dram_type = 3
+dram_rank_num = -1
+dram_chip_density = -1
+dram_io_width = -1
+dram_bus_width = -1
+dram_cas = 9
+dram_zq = 0x7f
+dram_odt_en = 0
+dram_size = -1
+dram_tpr0 = 0x42d899b7
+dram_tpr1 = 0xa090
+dram_tpr2 = 0x22a00
+dram_tpr3 = 0x0
+dram_tpr4 = 0x1
+dram_tpr5 = 0x0
+dram_emr1 = 0x4
+dram_emr2 = 0x10
+dram_emr3 = 0x0
+
+[mali_para]
+mali_used = 1
+mali_clkdiv = 1
+
+[emac_para]
+emac_used = 0
+emac_rxd3 = port:PA002defaultdefaultdefault
+emac_rxd2 = port:PA012defaultdefaultdefault
+emac_rxd1 = port:PA022defaultdefaultdefault
+emac_rxd0 = port:PA032defaultdefaultdefault
+emac_txd3 = port:PA042defaultdefaultdefault
+emac_txd2 = port:PA052defaultdefaultdefault
+emac_txd1 = port:PA062defaultdefaultdefault
+emac_txd0 = port:PA072defaultdefaultdefault
+emac_rxclk = port:PA082defaultdefaultdefault
+emac_rxerr = port:PA092defaultdefaultdefault
+emac_rxdV = port:PA102defaultdefaultdefault
+emac_mdc = port:PA112defaultdefaultdefault
+emac_mdio = port:PA122defaultdefaultdefault
+emac_txen = port:PA132defaultdefaultdefault
+emac_txclk = port:PA142defaultdefaultdefault
+emac_crs = port:PA152defaultdefaultdefault
+emac_col = port:PA162defaultdefaultdefault
+emac_reset = port:PA171defaultdefaultdefault
+
+[twi0_para]
+twi0_used = 1
+twi0_scl = port:PB002defaultdefaultdefault
+twi0_sda = port:PB012defaultdefaultdefault
+
+[twi1_para]
+twi1_used = 1
+twi1_scl = port:PB182defaultdefaultdefault
+twi1_sda = port:PB192defaultdefaultdefault
+
+[twi2_para]
+twi2_used = 1
+twi2_scl = port:PB202defaultdefaultdefault
+twi2_sda = port:PB212defaultdefaultdefault
+
+[uart_para0]
+uart_used = 1
+uart_port = 0
+uart_type = 2
+uart_tx = port:PB2221defaultdefault
+uart_rx = port:PB2321defaultdefault
+
+[uart_para1]
+uart_used = 0
+uart_port = 1
+uart_type = 8
+uart_tx = port:PA1041defaultdefault
+uart_rx = port:PA1141defaultdefault
+uart_rts = port:PA1241defaultdefault
+uart_cts = port:PA1341defaultdefault
+uart_dtr = port:PA1441defaultdefault
+uart_dsr = port:PA1541defaultdefault
+uart_dcd = port:PA1641defaultdefault
+uart_ring = port:PA1741defaultdefault
+
+[uart_para2]
+uart_used = 0
+uart_port = 2
+uart_type = 4
+uart_tx = port:PI1831defaultdefault
+uart_rx = port:PI1931defaultdefault
+uart_rts = port:PI1631defaultdefault
+uart_cts = port:PI1731defaultdefault
+
+[uart_para3]
+uart_used = 0
+uart_port = 3
+uart_type = 4
+uart_tx = port:PH0041defaultdefault
+uart_rx = port:PH0141defaultdefault
+uart_rts = port:PH0241defaultdefault
+uart_cts = port:PH0341defaultdefault
+
+[uart_para4]
+uart_used = 0
+uart_port = 4
+uart_type = 2
+uart_tx = port:PH0441defaultdefault
+uart_rx = port:PH0541defaultdefault
+
+[uart_para5]
+uart_used = 0
+uart_port = 5
+uart_type = 2
+uart_tx = port:PH0641defaultdefault
+uart_rx = port:PH0741defaultdefault
+
+[uart_para6]
+uart_used = 0
+uart_port = 6
+uart_type = 2
+uart_tx = port:PA1231defaultdefault
+uart_rx = port:PA1331defaultdefault
+
+[uart_para7]
+uart_used = 0
+uart_port = 7
+uart_type = 2
+uart_tx =

Re: [linux-sunxi] USB issues in linux-sunxi 3.4.x

2014-01-02 Thread EGM

I am sorry that I have not respond sooner, but I was quite busy.

It seems that it's related only to A20, since Michal could reproduce it on 
CT, but it seems OK on CB1. I tested it today on CB2 with following 
versions:
v3.4.61-r1 -- broken
v3.4.67-r1 -- broken

I used RTL8188 dongle for testing. It sticks in connected state when 
disconnected. Reconnecting the device while stuck (showed in lsusb) 
results in kernel oops.

If you need further information, I have access to Cubieboard2, Cubietruck 
and Hackberry boards.

Thanks!

Dne středa, 6. listopadu 2013 21:09:48 UTC+1 Michal Suchanek napsal(a):

 On 14 October 2013 13:48, EGM di...@strasil.net javascript: wrote: 
  While using sunxi-3.4.43 on Cubieboard2 board, I noticed some odd 
 behavior 
  of USB devices. 
  
  For certain devices, it seems like kernel does not register 
 disconnection of 
  that USB device (or registers it, but does not do reset/cleanup for the 
  device). So for example, when I connect wifi dongle (RTL8188-based) and 
  disconnect it, it will be still shown in lsusb as a device, in iwconfig 
 as a 
  wlan# and so on. What makes the device disappear as expected is removing 
 the 
  kernel module using rmmod. 
  
  I talked about it with guys on IRC today (thanks for help), and tested 
 it 
  out of few more versions of kernel. So I can confirm that this happens 
 in 
  3.4.43-r2, stage/sunxi-3.4 and sunxi-3.4 (not sure about revision right 
 now, 
  but I can retest it using the latest one). I used kernel configuration 
 shown 
  here: http://sprunge.us/SFMD 
  
  When using hramrach's wheezy image 
  (
 http://dl.linux-sunxi.org/users/hramrach/cubieboard2-linux3.3-SD-card-image/) 

  or just kernel 3.3.0 from his repository 
  (https://github.com/hramrach/linux-sunxi/commits/sunxi-3.3-cb2), USB 
 devices 
  works as expected (ie. disconnection is detected and handled properly). 
  
  What is really odd is fact, that I am able to workaround this problem 
 using 
  external USB hub (D-Link DUB-H4, enumerates as ActionStar with VID/PID 
  2101:8500 and 2101:8501). When I connect devices to this hub, everything 
  works as expected, but when I disconnect the hub from Cubieboard, it 
 will 
  stuck in connected state as I described above. When I disconnect the 
 hub 
  and replug it, I got following messages in dmesg: 
  
  ehci_irq: port change detect 
  3hub 3-0:1.0: port 1 disabled by hub (EMI?), re-enabling... 
  6usb 3-1: USB disconnect, device number 5 
  6usb 3-1.1: USB disconnect, device number 6 
  6usb 3-1: new high-speed USB device number 7 using sw-ehci 
  6hub 3-1:1.0: USB hub found 
  6hub 3-1:1.0: 5 ports detected 
  6usb 3-1.1: new high-speed USB device number 8 using sw-ehci 
  6generic-usb 0003:2101:8501.0003: hiddev0,hidraw0: USB HID v1.11 
 Device 
  [Action Star USB HID] on usb-sw-ehci-1.1/input0 

 It appears that port change does not get delivered for the AW EHCI 
 controller ports (but works for OHCI - usb1 devices). 

 The hub manages its ports fine so the port change gets delivered for 
 those. I can reproduce on CT with an USB Ethernet (high-spped) but not 
 with an USB serial convertor (full speed). 3.4.67+ #6 SMP PREEMPT Sun 
 Nov 3 11:50:44 CET 2013 armv7l GNU/Linux 

 It's not broken on cb1 3.4.61+ #15 PREEMPT Tue Sep 17 19:11:17 CEST 
 2013 armv7l GNU/Linux 


 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/groups/opt_out.

Re: [linux-sunxi] Re: [PATCH 04/10] net: stmmac: sunxi platfrom extensions for GMAC in Allwinner A20 SoC's

2014-01-02 Thread srinivas kandagatla

Hi Chen,

On 24/12/13 03:27, Chen-Yu Tsai wrote:
 Srinivas,
 
 Let's keep platform data as of_data, so SoC compatibles can pass
 hardware feature flags for cores that don't support auto-detection.

I understand your concern here, But making platform_data as of_data
would just open a wide door for other hacky stuff too. So other glue
drivers would just use this interface instead, ignoring standard
interfaces. Also there would be issues on who takes the priority if the
parameters are specified in multiple places.


Can't this field/s be one of the variable in the struct stmmac_of_data
rather than reusing platform data?

 
 We can adjust the callbacks as you suggested, and I added a .free
 to complement .setup. Driver private data and platform data are
 off limits to the callbacks. My version of the callbacks:
 
 void (*fix_mac_speed)(void *priv, unsigned int speed);
 void (*bus_setup)(void __iomem *ioaddr);

In reply to your question in last email:
bus_setup this is something very specific to ST which configures the bus
parameters of AMBA-to-STBUS converter. This register falls inside the
memory map of stmmac.

 void *(*setup)(struct platform_device *pdev);
 void (*free)(struct platform_device *pdev, void *priv);
 int (*init)(struct platform_device *pdev, void *priv);
 void (*exit)(struct platform_device *pdev, void *priv);
 

The callbacks to Ok to me, unless Peppe has more comments on this.

Thanks,
srini


 
 Cheers,
 
 ChenYu

-- 
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/groups/opt_out.

Re: [linux-sunxi] [PATCH] add inet k70hc

On Thu, Jan 02, 2014 at 01:23:22PM +0100, Luc Verhaegen wrote:
 Signed-off-by: Luc Verhaegen l...@skynet.be
 ---
  sys_config/a20/inet_k70hc.fex | 1008 
 +
  1 files changed, 1008 insertions(+), 0 deletions(-)
  create mode 100644 sys_config/a20/inet_k70hc.fex

Hold off on this, i need to adjust the .fex file for 8188eu.

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/groups/opt_out.

Re: [linux-sunxi] Re: The realistic Cortex-A7 clock frequency limit for Allwinner A20 (CubieBoard2)?

2014-01-02 Thread nilsnuls0

четверг, 2 января 2014 г., 3:11:31 UTC+4 пользователь Siarhei Siamashka написал:
 On Fri, 27 Dec 2013 06:47:42 -0800 (PST)
 
 nils wrote:
 
 
 
  пятница, 27 декабря 2013 г., 14:56:11 UTC+4 пользователь Oliver Schinagl 
  написал:
 
   On 12/25/13 13:28, nils@gmail.com wrote:
 
   
 
With default 1.4V it segfaults.
 
   
 
   Do you mean you are UNDERvolting it? that seems a little strange ...
 
   
 
   
 
  Yes,I think that without heatsink, compilation segfaults due to overheating 
  .
 
  
 
  1,008/1.4V - segfaults .
 
  1,008/1.275V - gcc compiled ok, takes about 5 hours.
 
  1,056/1.325V - system freezes .
 
  Back to 1,008Gz/1.275V - gcc compiled ok again.
 
  
 
  Also i have Mele A100(A10/512) with heatsink, gcc compilation allways 
  segfaults
 
  on it with any freq ,probably due to overclocked(480) ram.
 
 
 
 It seems like you are either having extremely bad luck (2 bad devices
 
 out of 2 is impressive), or something is really messed up on the
 
 software side.
 
 
 
 I have 4 devices with Allwinner-A10/Allwinner-A20. All of them are
 
 working fine when used with the normal default configuration (the
 
 unmodified linux sunxi-3.4 kernel, sunxi u-boot and fex files).
 
 
 
 -- 
 
 Best regards,
 
 Siarhei Siamashka

Hardware without box, like cubie, may perform better as it better cooled on 
open air. I have tested Mele M3 as is(in box, and without heatsink), so 
overheating comes quicker. 
Yes, with default 912Mhz/1.4V it probably works ok, but i am not tried this. 
For now with 1,008Ghz/1.275V and governor perfomance, it absolutely stable. 
Tried compilation of gcc-gentoo-4.7.3-r1, gcc-linaro-4.6.4, gcc-linaro-4.7.4, 
sunxi-3.0, sunxi-3.4 and other code sources with no errors.
Ordered 20x20x10mm heatsink, i think A20 can more when better cooled.

As for A10(Mele A100 with heatsink), my problem was OVERvolting that  i used 
previously, eg 1.200Ghz/1.65V .
Get it stable with 1.200Ghz/1.5V. No segfaults more.
Tested with sunxi-3.4.75/Gentoo, sunxi-3.0.101/ICS. 

Just for information - A10 stable minimal freq/volt combinations i've found on 
my hardware :
{.freq = 12, .volt = 1500},
{.freq = 115200, .volt = 1450},
{.freq = 110400, .volt = 1400},
{.freq = 105600, .volt = 1350},
{.freq = 100800, .volt = 1300},

-- 
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/groups/opt_out.

[linux-sunxi] Re: [PATCH 1/4] input: Add new sun4i-lradc-keys drivers


Hi,

On 01/02/2014 12:59 PM, Heiko Stübner wrote:

Hi Hans, Dmitry,

Am Donnerstag, 2. Januar 2014, 10:37:47 schrieb Hans de Goede:

Hi,

On 01/01/2014 09:56 PM, Dmitry Torokhov wrote:

Hi Hans,

On Wed, Jan 01, 2014 at 08:30:07PM +0100, Hans de Goede wrote:

+Required properties:
+ - compatible: allwinner,sun4i-lradc-keys
+ - reg: mmio address range of the chip
+ - interrupts: interrupt to which the chip is connected
+ - allwinner,chan0-step: step in mV between keys must be 150 or 200
+ - allwinner,chan0-keycodes: array of include/uapi/linux/input.h KEY_
codes

I think this should be linux,chan0-keycodes.


Right, because the codes are Linux specific, will fix in v2.


but the property with its chan0- thingy would be allwinner-specific if I'm
not mistaken.


Correct, but denoting that this is linux only is more important, so as to
avoid namespace collisions.



Also, instead of inventing yet another vendor-specific property, why not re-use
a button binding similar to gpio-keys like:

lradc: lradc@01c22800 {
compatible = allwinner,sun4i-lradc-keys;
reg = 0x01c22800 0x100;
interrupts = 31;
allwinner,chan0-step = 200;

#address-cells = 1;
#size-cells = 0;

button@0 {
reg = 0; /* your channel index from above */
linux,code = 115; /* already used as dt-property */
};

button@1 {
reg = 1;
linux,code = 114;
};


Ugh no. Having a vendor specific property which is KISS certainly beats this,
both wrt ease of writing dts files as well as wrt the dts parsing code in the 
driver.

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/groups/opt_out.

Re: [linux-sunxi] Sd card partition for A20 booting...

2014-01-02 Thread Puneet B

Hi arete74,

Can you tell what problem you are facing while booting android 4.2 over sd 
card.

Regards
Punith 

-- 
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/groups/opt_out.

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

2014-01-02 Thread Arend van Spriel

On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote:
 Hi,
 
 On Fri, Dec 27, 2013 at 7:47 PM, Arend van Spriel ar...@broadcom.com wrote:
 On 12/26/2013 05:13 PM, Chen-Yu Tsai wrote:
 Hi,

 On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai w...@csie.org wrote:
 Hi,

 On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai w...@csie.org wrote:
 Hi,

 On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel ar...@broadcom.com 
 wrote:
 On 12/18/2013 02:12 PM, Hans de Goede wrote:
 Hi,

 On 12/18/2013 11:31 AM, Arend van Spriel wrote:
 On 12/05/2013 10:46 PM, Julian Calaby wrote:
 Firstly, are there any plans to support the BCM43362 chipset with the
 brcmfmac driver in the near future?

 Hi Julian,

 I am working on a patch to support this chip. It is looking promising.
 Just have to go after a firmware image to be sure.

 Cool. Do you have a cubietruck? With my latest wip tree:
 https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next

 No cubietruck here. I googled the term last week because it came up and
 found embeddedcomputer.nl selling it.

 We've mmc/sdio controller support on top of 3.13-rc4, it would be
 nice if we could also get the wifi and bluetooth to work here.

 I got the chip to respond to probing. It is BCM43362 for sure.

   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
   0xa962
   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
   0x02d0

 Vendor ID is Broadcom. Device ID is 43362.
 But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
 if this is normal or not.

 There might be three devices/functions. The last digit of the device
 indicates the SDIO function number. Function 1 allows access to F1
 registers in the SDIO core of the device and F2 is for WLAN
 functionality. F3 could be providing BT functionality, but I am not
 familiar with that part.

 Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline
 brcmfmac driver. I only tested managed mode. Monitor mode does not work.
 You can use firmware from CubieTech images.

 brcmfmac does not support monitor mode. It does support AP mode and P2P
 modes.

 Things missing:

   1. output clock is using default 32KHz from 24M / 750.
  need to find some place to put clk_set_rate call.

 What clock is this? You mean there is a clock output driven by the
 AP6210 module or Cubieboard provides it to the module.
 
 Cubieboard provides it to the module.
 
 BCM43362 (WiFi) and BCM20710 (BT) both accept an external 32768 Hz
 clock as low power clock. They can also use internal oscillator for
 this, so it is optional. But according to BCM20710 datasheet, this
 external clock is required to auto-detect the frequency of the main
 oscillator if it's not the default 20MHz. On the CubieTruck, it is
 26 MHz. For just WiFi, I think we don't need it.
 
   2. BCM43362 out-of-band interrupts not supported.
  OOB interrupt in brcmfmac is set using platform data.
  Need to put this is board code, or add device tree support.

 It would be good to add device tree support so the driver can first look
 for device tree data and have platform data and in-band as backup mechanism.
 
 I'm not sure how to add support. Add a child node to the SD/MMC
 controller, perhaps? I thought SDIO devices were like USB, in
 that the system scans the bus and detects them.
 
 Core ID and addresses were found using bcmdhd driver debug output.
 Arend might want to take a look at the patch:

   
 https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865

 I have different addresses from the chip documentation, but my test spin
 went poorly. So much for hardware documentation. I will give these
 values a try. In my patch there is also bcm43362 specific SDIO drive
 strength programming (see attachment). The patch won't apply as my tree
 is a bit different due to some rework in the SDIO part of brcmfmac. So
 you probably need to pick the missing part from it.
 
 Maybe it's a remarked chip? (is that possible?)
 The firmware CubieTech has is for a BCM40181 though.
 
 Added the drive strength programming by hand. Changed the table variable
 name to match the others. Pushed on to my tree. Beware there are some
 hacks trying to get BT to work. :p
 

 Working tree:

   https://github.com/wens/linux/tree/wip/sunxi-next-wifi

 Comments welcome :)

 No comment, but: Nice work!
 
 Thanks. BTW, who should submit the patch? :)

Hi Chen-Yu,

I confirmed the patch is working with a revision 0 of the device. What
chip revision does it give in your log (need to load brcmfmac with
module parameter debug=4).

Regards,
Arend



 Bluetooth still isn't responding.

 Bluetooth still not working. :(
 Has anyone had any luck with this?


 I'm certainly willing to give some patches for this a try. Do you
 have an example of what the dts file for a board with broadcom sdio
 wifi looks like ?

 I am still struggling with dts changes for a Pandaboard. As I understood
 the cubietruck uses AP6210 module and the dts really depends on how

[linux-sunxi] Re: Upstreaming sunxi mmc support

Hi,

On 01/02/2014 02:09 AM, David Lanzendörfer wrote:

Hi Hans, Maxime et al,
I've made a first approach to incorporate the changes we've disscussed.
I'm not quite done yet.
You can have a look at it under:
http://git.o2s.ch/?p=linux-next.git;a=shortlog;h=refs/heads/20131224

My recent issue: I appear to be missing certain patchsets which haven't
been merged into linux-next yet. Mainly some subfunction for the clock.
I always get 0 when I try to round a clock frequency,
which of course makes testing of my code impossible.
It would be great if someone would take the time and would have a look
through the commitlog...
Or maybe Maxime?
Do you have an idea where the problem with clk_round_rate could come from?

Thanks for working on this. I've merged your updated version of the
patches into the sunxi-devel branch. That branch has several sunxi-clk
commits which are not in -next (and I don't know when they will be send
there, Emilio?).

With those patches your updated version of the mmc driver works fine for
me. I think it would be a good idea for you to use sunxi-devel as a base
for your work, you can just checkout:
https://github.com/linux-sunxi/linux-sunxi/commit/c213f86956991b20f847dca9846e7cd112032f67

As a start point for further work, that gives you all the bits I believe
to be headed for 3.14 + the few extra patches you need from Emilio + your
work sofar.

I've also taken a quick look at your patches, I've one remark about:
https://github.com/linux-sunxi/linux-sunxi/commit/796b36502919bd4327029d0f0b10180af279c72e

For newer soc models where the ip-block is unchanged you should use
the same compatible string as the first model with that version of the ip-block.

IOW for sun5i-a10s and sun7i-a20 the compatible string should be
allwinner,sun5i-a13-mmc

And more in general when making changes to the dts files, please do one commit
for each of sun4i, sun5i and sun7i, that will making squashing things together
later much easier.

Thanks Regards,

Hans

p.s.

If you run out of time and/or steam please let me know and I can do a v2 of
this patch-set
if you want me to. In that case, I assume it is ok I add a
Signed-off-by: David Lanzendörfer david.lanzendoer...@o2s.ch
to all the patches ?

--
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/groups/opt_out.

[linux-sunxi] sunxi-devel branch updated to 3.13-rc6


Hi All,

I've just updated: 
https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel
to 3.13-rc6. Also new is an updated version of the mmc driver (mostly cosmetic 
fixes
to get it ready for upstream) and a sun4i-lradc-keys driver

The sunxi-devel branch now contains 3.13-rc6

+ the following, which should all go upstream for 3.14:

  https://github.com/mripard/linux/commits/sunxi-clk-for-3.13
  https://github.com/mripard/linux/commits/sunxi-drivers-for-3.14
  https://github.com/mripard/linux/commits/sunxi-core-for-3.14
  https://github.com/mripard/linux/commits/sunxi-dt-for-3.14
  sunxi-bits of:
   
https://git.linaro.org/people/daniel.lezcano/linux.git/shortlog/refs/heads/clockevents/next
  Emilio's [PATCH v3 00/13] clk: sunxi: add PLL5 and PLL6 support series
  Chen's external oscillator work
  sun4i-ts resisitive touchscreen controller + temp sensor driver
  sun4i-lradc-keys driver

+ the following which is not quite ready for 3.14 yet, but people
are working hard to get it ready so hopefully we will see some of
it in 3.14, and the rest should make 3.15:

  Emilio's sunxi-clk branch: patches not part of the above set
  David's and mine sunxi-mmc work
  Chen's gmac work
  Oliver's ahci work
  Arokux' ehci work

Note for this to work properly on sun7i and sun5i you also need my
sunxi-next u-boot branch:
https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-next

Enjoy,

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/groups/opt_out.

Re: [linux-sunxi] [PATCH] sunxi: Add Inet K70HC device


Hi,

On 01/02/2014 12:37 PM, Luc Verhaegen wrote:

Signed-off-by: Luc Verhaegen l...@skynet.be


Thanks, added to the u-boot-sunxi git repo sunxi branch.

Regards,

Hans


---
  board/sunxi/Makefile  |1 +
  board/sunxi/dram_inet_k70hc.c |   31 +++
  boards.cfg|1 +
  3 files changed, 33 insertions(+), 0 deletions(-)
  create mode 100644 board/sunxi/dram_inet_k70hc.c

diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index 7fefdf0..f274a1d 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_HACKBERRY)   += dram_hackberry.o
  obj-$(CONFIG_A7HD)+= dram_sun4i_360_1024_iow8.o
  obj-$(CONFIG_INTERRA3)+= dram_mk802ii_a20.o
  obj-$(CONFIG_INET97F_II)  += dram_sun4i_408_512.o
+obj-$(CONFIG_INET_K70HC)   += dram_inet_k70hc.o
  obj-$(CONFIG_JESURUN_Q5)  += dram_sun4i_312_1024_iow8.o
  obj-$(CONFIG_K1001L1C)+= dram_a20_olinuxino_m.o
  obj-$(CONFIG_MEFAFEIS_A08)+= dram_megafeis_a08.o
diff --git a/board/sunxi/dram_inet_k70hc.c b/board/sunxi/dram_inet_k70hc.c
new file mode 100644
index 000..d5ddc13
--- /dev/null
+++ b/board/sunxi/dram_inet_k70hc.c
@@ -0,0 +1,31 @@
+/* this file is generated, don't edit it yourself */
+
+#include common.h
+#include asm/arch/dram.h
+
+static struct dram_para dram_para = {
+   .clock = 384,
+   .type = 3,
+   .rank_num = 1,
+   .density = 4096,
+   .io_width = 16,
+   .bus_width = 32,
+   .cas = 9,
+   .zq = 0x12331a7f,
+   .odt_en = 0,
+   .size = 1024,
+   .tpr0 = 0x42d899b7,
+   .tpr1 = 0xa090,
+   .tpr2 = 0x22a00,
+   .tpr3 = 0,
+   .tpr4 = 1,
+   .tpr5 = 0,
+   .emr1 = 0x4,
+   .emr2 = 0x10,
+   .emr3 = 0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+   return dramc_init(dram_para);
+}
diff --git a/boards.cfg b/boards.cfg
index 7eeb17a..eda05de 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -380,6 +380,7 @@ Active  arm armv7  sunxi   -
   sunxi
  Active  arm armv7  sunxi   -   sunxi  
 Hyundai_A7HD sun4i:A7HD,SPL

-
  Active  arm armv7  sunxi   -   sunxi  
 Interra-3
sun7i:INTERRA3,SPL,SUNXI_GMAC,FAST_MBUS,MMC_SUNXI_SLOT=2
  -
  Active  arm armv7  sunxi   -   sunxi  
 INet97F-II   sun4i:INET97F_II,SPL  

-
+Active  arm armv7  sunxi   -   sunxi   
INet_K70HC   sun7i:INET_K70HC,SPL   

   -
  Active  arm armv7  sunxi   -   sunxi  
 Jesurun-Q5   
sun4i:JESURUN_Q5,SPL,SUNXI_EMAC,STATUSLED=244   
  -
  Active  arm armv7  sunxi   -   sunxi  
 K1001L1C sun7i:K1001L1C,SPL

-
  Active  arm armv7  sunxi   -   sunxi  
 Marsboard_A10
sun4i:MARSBOARD_A10,SPL,SUNXI_EMAC,NO_AXP   
  -



--
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/groups/opt_out.

Re: [linux-sunxi] FOSDEM 2014, what do we want


Hi,

On 01/01/2014 10:55 PM, Oliver Schinagl wrote:

On 01/01/14 14:13, Tim Fletcher wrote:

On 01/01/14 13:06, Oliver Schinagl wrote:

Hey list,

as you should remember, I applied for FOSDEM and got accepted. As I'm
working on the presentation, I am curious what you guys think others
would be interested in hearing about.

So please, pretend this is a blank slate, and suggest whatever should be
mentioned during FOSDEM and I will try to take that into account.


I think that a lot of people aren't aware of how far the sunxi project
has come towards making the allwinner SoCs well supported and part of
the main line kernel. I know I wasn't aware of it until I read Rich's
blog post about the cubietruck and KVM.

Well the status of the sunxi community obviously should be one of the main 
reasons for holding this talk :)


Hehe, I too think it would be could to spend most of the talk on upstream
progress. If possible I would also add maybe one sheet about the android
derived 3.4 kernel, where you can basically summarize things by saying that
everything more or less works :)

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/groups/opt_out.

Re: [linux-sunxi] FOSDEM 2014, what do we want

2014-01-02 Thread Olliver Schinagl


On 02-01-14 15:26, Luc Verhaegen wrote:

On Thu, Jan 02, 2014 at 03:18:58PM +0100, Hans de Goede wrote:

Hi,

On 01/01/2014 10:55 PM, Oliver Schinagl wrote:

Hehe, I too think it would be could to spend most of the talk on upstream
progress. If possible I would also add maybe one sheet about the android
derived 3.4 kernel, where you can basically summarize things by saying that
everything more or less works :)

Regards,

Hans


I do not agree. Upstream linux kernel support is not what this talk is
about, and the talk should very broadly cover many aspects of the
linux-sunxi project.

If you wanted an upstream linux kernel talk for sunxi, you should've
filed a separate talk.
I think this subject is so broad, that all (kernel) directions should 
and could be talked about. 3.4 is interesting, 3.10 is interesting, 
mainline is interesting. 3.0 btw is not, but even talking a little about 
3.3 is important to the crowd to know what's out there (and what to avoid).


This is about new people that don't know what's going on here, all 
information is good :)


oliver




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/groups/opt_out.

Re: [linux-sunxi] Explain the contents of bootloader...

2014-01-02 Thread Olliver Schinagl


On 02-01-14 10:49, Puneet B wrote:

Hi i flashed the cubieboard image to sd card from this link.

https://docs.google.com/file/d/0B-bAEPML8fwlUFd5OHVOaFJIRmc/edit.

then in Volumn(bootlaoder)  folder of sdcard i got fallowing binaries.

1.boot.axf
This is the allwinner 'battery charging app' that also chainloads u-boot 
if need so.

2.boot_signature.axf

this is some sort of signature required by boot.axf i assume

3.drv_hdmi.drv

this is the HDMI driver to output over ... hdmi yes

4.font32.sft

a font

5.magic.bin

some secret sauce

6.prvt.axf

some private data

7.script.bin

the famous script.bin/fex

8.boot.ini

a dos file for boot.axf to parse to decide what to boot

9.drv_de.drv

display engine driver

10.font24.sft

a nother font!

11.linux   - linux.bmp  linux.ini  u-boot.bin (sub contents).
the linux splash screen (android actually) an ini file to tell boot.axf 
what and how to boot it (it being u-boot).
u-boot here is the lichee-u-boot, one that does NOT init dram, but DOES 
support NAND

12.os_show   -bat0.bmp   bat2.bmp  bat5.bmp  bat8.bmp bempty.bmp
full.bmplinux2.bmp   melis2.bmp   wince1.bmp
   bat10.bmp  bat3.bmp  bat6.bmp  bat9.bmp
bootlogo.bmp  head.bmplow_pwr.bmp  startup.bmp  wince2.bmp
   bat1.bmp   bat4.bmp  bat7.bmp  battery.bmp
empty.bmp linux1.bmp  melis1.bmp   tail.bmp
boot.axf image files (like empty battery, charging, some pics they 
intended to use as boot selector that never happened.



13.script0.bin

backup copy of script.bin, in case 1 is broken it tries to read this one

14.sprite.axf

helper program to handle the loading of bitmaps it would seem.



Out of these i know script.bin , and u-boot.bin (but i flashed to
/dev/sdc ).
you cannot flash that u-boot to a SD card, it works only on nand, and 
you shouldn't mess with it.


Kindly tell what will be purpose of remaining binaries.

and tell me what will be difference between boot0 ,boot1 and
sunxi-spl.bin ,u-boot.bin.

YOu really don't know this yet? Have you ever looked at our wiki?

boot0 is allwinner's version of what we call u-boot-sunxi-spl. boot1 is 
allwinners variant of what we call u-boot.bin boot0/1 is what we call 
u-boot-sunxi-with-spl.bin which is inteded to be flashed to an mmc card, 
starting at the 8k marker.


Oliver


Regards
Punith

--
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/groups/opt_out.


--
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/groups/opt_out.

Re: [linux-sunxi] sunxi-devel branch updated to 3.13-rc6

Hi,

Would you like to merge v2 of the gmac series as it is now?
It has proper MII/RGMII support, so it doesn't need u-boot.

https://github.com/wens/linux/tree/wip/stmmac-v2


Cheers,
ChenYu

On Thu, Jan 2, 2014 at 10:12 PM, Hans de Goede hdego...@redhat.com wrote:
 Hi All,

 I've just updated:
 https://github.com/linux-sunxi/linux-sunxi/commits/sunxi-devel
 to 3.13-rc6. Also new is an updated version of the mmc driver (mostly
 cosmetic fixes
 to get it ready for upstream) and a sun4i-lradc-keys driver

 The sunxi-devel branch now contains 3.13-rc6

 + the following, which should all go upstream for 3.14:

   https://github.com/mripard/linux/commits/sunxi-clk-for-3.13
   https://github.com/mripard/linux/commits/sunxi-drivers-for-3.14
   https://github.com/mripard/linux/commits/sunxi-core-for-3.14
   https://github.com/mripard/linux/commits/sunxi-dt-for-3.14
   sunxi-bits of:

 https://git.linaro.org/people/daniel.lezcano/linux.git/shortlog/refs/heads/clockevents/next
   Emilio's [PATCH v3 00/13] clk: sunxi: add PLL5 and PLL6 support series
   Chen's external oscillator work
   sun4i-ts resisitive touchscreen controller + temp sensor driver
   sun4i-lradc-keys driver

 + the following which is not quite ready for 3.14 yet, but people
 are working hard to get it ready so hopefully we will see some of
 it in 3.14, and the rest should make 3.15:

   Emilio's sunxi-clk branch: patches not part of the above set
   David's and mine sunxi-mmc work
   Chen's gmac work
   Oliver's ahci work
   Arokux' ehci work

 Note for this to work properly on sun7i and sun5i you also need my
 sunxi-next u-boot branch:
 https://github.com/jwrdegoede/u-boot-sunxi/commits/sunxi-next

 Enjoy,

 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/groups/opt_out.

-- 
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/groups/opt_out.

[linux-sunxi] Re: [PATCH 1/4] input: Add new sun4i-lradc-keys drivers

2014-01-02 Thread Heiko Stübner

Hi Hans, Dmitry,

Am Donnerstag, 2. Januar 2014, 10:37:47 schrieb Hans de Goede:
 Hi,
 
 On 01/01/2014 09:56 PM, Dmitry Torokhov wrote:
  Hi Hans,
  
  On Wed, Jan 01, 2014 at 08:30:07PM +0100, Hans de Goede wrote:
  +Required properties:
  + - compatible: allwinner,sun4i-lradc-keys
  + - reg: mmio address range of the chip
  + - interrupts: interrupt to which the chip is connected
  + - allwinner,chan0-step: step in mV between keys must be 150 or 200
  + - allwinner,chan0-keycodes: array of include/uapi/linux/input.h KEY_
  codes 
  I think this should be linux,chan0-keycodes.
 
 Right, because the codes are Linux specific, will fix in v2.

but the property with its chan0- thingy would be allwinner-specific if I'm 
not mistaken.

Also, instead of inventing yet another vendor-specific property, why not re-use 
a button binding similar to gpio-keys like:

   lradc: lradc@01c22800 {
   compatible = allwinner,sun4i-lradc-keys;
   reg = 0x01c22800 0x100;
   interrupts = 31;
   allwinner,chan0-step = 200;

#address-cells = 1;
#size-cells = 0;

button@0 {
reg = 0; /* your channel index from above */
linux,code = 115; /* already used as dt-property */
};

button@1 {
reg = 1;
linux,code = 114;
};

...

   };

But I may be on the wrong track here, so I've included the devicetree-people 
for help, which I guess should've been included from the beginning.


Heiko

-- 
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/groups/opt_out.

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

2014-01-02 Thread Michal Suchanek

Hello,

On 19 December 2013 11:12, Chen-Yu Tsai w...@csie.org wrote:
 Hi,

 On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai w...@csie.org wrote:
 Hi,

 On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel ar...@broadcom.com 
 wrote:
 On 12/18/2013 02:12 PM, Hans de Goede wrote:
 Hi,

 On 12/18/2013 11:31 AM, Arend van Spriel wrote:
 On 12/05/2013 10:46 PM, Julian Calaby wrote:
 Firstly, are there any plans to support the BCM43362 chipset with the
 brcmfmac driver in the near future?

 Hi Julian,

 I am working on a patch to support this chip. It is looking promising.
 Just have to go after a firmware image to be sure.

 Cool. Do you have a cubietruck? With my latest wip tree:
 https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next

 No cubietruck here. I googled the term last week because it came up and
 found embeddedcomputer.nl selling it.

 We've mmc/sdio controller support on top of 3.13-rc4, it would be
 nice if we could also get the wifi and bluetooth to work here.

 I got the chip to respond to probing. It is BCM43362 for sure.

   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
   0xa962
   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
   0x02d0

 Vendor ID is Broadcom. Device ID is 43362.
 But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
 if this is normal or not.

 Bluetooth still isn't responding.


Well, bluetooth is supposed to be attached to an UART, not SDIO.
That's what the datasheets of the chip I found looked like.

Not sure how firmware is supposed to fit in in this case but this
would not be the first serial BT chip requiring firmware, would it?

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/groups/opt_out.

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

Hi,

On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel ar...@broadcom.com wrote:
[snip]
 Hi Chen-Yu,

 I confirmed the patch is working with a revision 0 of the device. What
 chip revision does it give in your log (need to load brcmfmac with
 module parameter debug=4).

Mine is revision 1. Managed mode confirmed working.

Logs:
brcmfmac: F1 signature read @0x1800=0x1591a962
brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1
brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore
rev/type=10/0x829


ChenYu

-- 
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/groups/opt_out.

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

Hi,

On Fri, Jan 3, 2014 at 12:52 AM, Michal Suchanek hramr...@gmail.com wrote:
 Hello,

 On 19 December 2013 11:12, Chen-Yu Tsai w...@csie.org wrote:
[snip]
 Bluetooth still isn't responding.


 Well, bluetooth is supposed to be attached to an UART, not SDIO.
 That's what the datasheets of the chip I found looked like.

Correct. CubieTruck schematics indicate it's connected to UART2.

 Not sure how firmware is supposed to fit in in this case but this
 would not be the first serial BT chip requiring firmware, would it?

Broadcom has a utility called brcm_patchram_plus that loads the
firmware. However I can't get my chip to respond to its first
reset command.


ChenYu

-- 
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/groups/opt_out.

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

2014-01-02 Thread Rosimildo DaSilva

It would be nice to be precise about what is working:

a) Wifi + BT
b) WIFI only
c) BT only

Reading the thread, it seems you got (a) WIFI + BT working. Is this correct 
?

R


On Thursday, January 2, 2014 11:09:12 AM UTC-6, Chen-Yu Tsai wrote:

 Hi, 

 On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel 
 ar...@broadcom.comjavascript: 
 wrote: 
 [snip] 
  Hi Chen-Yu, 
  
  I confirmed the patch is working with a revision 0 of the device. What 
  chip revision does it give in your log (need to load brcmfmac with 
  module parameter debug=4). 

 Mine is revision 1. Managed mode confirmed working. 

 Logs: 
 brcmfmac: F1 signature read @0x1800=0x1591a962 
 brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1 
 brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore 
 rev/type=10/0x829 


 ChenYu 


-- 
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/groups/opt_out.

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

2014-01-02 Thread Michal Suchanek

On 2 January 2014 20:22, Rosimildo DaSilva rosimi...@gmail.com wrote:
 It would be nice to be precise about what is working:

 a) Wifi + BT
 b) WIFI only
 c) BT only

 Reading the thread, it seems you got (a) WIFI + BT working. Is this correct

No, it's b)

There is some bit missing for BT. Possibly setting the power and reset
gpio pins correctly. Or maybe the uart is set up with wrong
parameters.

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/groups/opt_out.

[linux-sunxi] [PATCH] wireless:rtl8188eu: add usb id for rtl8188etv

Signed-off-by: Luc Verhaegen l...@skynet.be
---
 .../net/wireless/rtl8188eu/os_dep/linux/usb_intf.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c 
b/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c
index 8b85338..fbe0a7f 100644
--- a/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c
+++ b/drivers/net/wireless/rtl8188eu/os_dep/linux/usb_intf.c
@@ -186,6 +186,7 @@ static struct usb_device_id rtw_usb_id_tbl[] ={
 #ifdef CONFIG_RTL8188E
/*=== Realtek demoboard ===*/   
{USB_DEVICE(USB_VENDER_ID_REALTEK, 0x8179)},//Default ID
+   {USB_DEVICE(USB_VENDER_ID_REALTEK, 0x0179)},//RTL8188ETV
 #endif
{}  /* Terminating entry */
 };
-- 
1.7.7

-- 
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/groups/opt_out.

[linux-sunxi] sunxi-3.4: make life easier for rtl8188etv users.

This trivial patch is several times over present in our wiki, but no-one
apparently has bothered with just sending it as an actual git patch for
inclusion in  our sunxi-3.4 branch, or when it did happen, it just sat
rotting on our ML.

Please fasttrack it, there is no point in putting this trivial change which
affects only a single driver in the stage branch. There is nothing that can
break which cannot be either build tested or which could be a regression.

With this change in sunxi-3.4 some wiki cleanup will take place.

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/groups/opt_out.

[linux-sunxi] Re: [PATCH 1/4] input: Add new sun4i-lradc-keys drivers

2014-01-02 Thread Maxime Ripard

On Thu, Jan 02, 2014 at 02:45:29PM +0100, Hans de Goede wrote:
 Also, instead of inventing yet another vendor-specific property, why not 
 re-use
 a button binding similar to gpio-keys like:
 
 lradc: lradc@01c22800 {
 compatible = allwinner,sun4i-lradc-keys;
 reg = 0x01c22800 0x100;
 interrupts = 31;
 allwinner,chan0-step = 200;
 
  #address-cells = 1;
  #size-cells = 0;
 
  button@0 {
  reg = 0; /* your channel index from above */
  linux,code = 115; /* already used as dt-property */
  };
 
  button@1 {
  reg = 1;
  linux,code = 114;
  };
 
 Ugh no. Having a vendor specific property which is KISS certainly
 beats this, both wrt ease of writing dts files as well as wrt the
 dts parsing code in the driver.

I'd agree with Heiko here. This is pretty much the same construct
that's already in use in other input drivers, like gpio-keys.

This is also something that can really easily be made generic, since
this is something that is rather common.

Speaking of which. I believe this should actually come in two
different drivers:
  - The ADC driver itself, using IIO
  - A generic button handler driver on top of IIO.

The fact that on most board this adc is used for buttons doesn't make
any difference, it's actually a hardware designer choice, we should
support that choice, but we should also be able to use it just as an
ADC.

Carlo Caione already started to work on an IIO driver for the LRADC:
https://github.com/carlocaione/linux/tree/sunxi-lradc
maybe you can take over his work.

I also wonder wether it would be possible in that case to use reg as
the button voltage, to get rid of both the chan0-step property, and
those big fat arrays in the driver.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

2014-01-02 Thread Arend van Spriel

On 01/02/2014 08:22 PM, Rosimildo DaSilva wrote:
 It would be nice to be precise about what is working:
 
 a) Wifi + BT
 b) WIFI only
 c) BT only
 
 Reading the thread, it seems you got (a) WIFI + BT working. Is this correct 
 ?

I think you need to read the thread once more. Wifi is working, no life
sign from the BT using UART, ie. (b).

Gr. AvS

 R
 
 
 On Thursday, January 2, 2014 11:09:12 AM UTC-6, Chen-Yu Tsai wrote:

 Hi, 

 On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel 
 ar...@broadcom.comjavascript: 
 wrote: 
 [snip] 
 Hi Chen-Yu, 

 I confirmed the patch is working with a revision 0 of the device. What 
 chip revision does it give in your log (need to load brcmfmac with 
 module parameter debug=4). 

 Mine is revision 1. Managed mode confirmed working. 

 Logs: 
 brcmfmac: F1 signature read @0x1800=0x1591a962 
 brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1 
 brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore 
 rev/type=10/0x829 


 ChenYu 

 

-- 
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/groups/opt_out.

Re: [linux-sunxi] FOSDEM 2014, what do we want

2014-01-02 Thread Patrick Wood



On Wednesday, January 1, 2014 8:13:12 AM UTC-5, Tim Fletcher wrote:

 On 01/01/14 13:06, Oliver Schinagl wrote: 
  Hey list, 
  
  as you should remember, I applied for FOSDEM and got accepted. As I'm 
  working on the presentation, I am curious what you guys think others 
  would be interested in hearing about. 
  
  So please, pretend this is a blank slate, and suggest whatever should be 
  mentioned during FOSDEM and I will try to take that into account. 

 I think that a lot of people aren't aware of how far the sunxi project 
 has come towards making the allwinner SoCs well supported and part of 
 the main line kernel. I know I wasn't aware of it until I read Rich's 
 blog post about the cubietruck and KVM. 

 Being able to point people towards a few good cheap boards they can get 
 Linux up and running on quickly and easily would help too. Too many (to 
 my mind) of the postings on the debian-arm list are about bodging debian 
 onto ancient arm5 devices. 

 I think you should put up a slide or two comparing the AW SoCs with other 
low-cost, high-integration ARM SoCs out there, like Rockchip, Broadcom, 
AMLogic, and maybe Freescale. Include things like HW features, current 
level of FOS support (or lack thereof) for IP blocks, level of kernel 
support (or lack thereof) from the manufacturer, status of 
reverse-engineered blocks, etc.  Also include a high-end SoC like Tegra 
or OMAP as a reference.  Rhombus Tech has some useful information comparing 
different SoCs.

-- 
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/groups/opt_out.

[linux-sunxi] Re: [PATCH 1/4] input: Add new sun4i-lradc-keys drivers


Hi,

On 01/02/2014 09:20 PM, Maxime Ripard wrote:

On Thu, Jan 02, 2014 at 02:45:29PM +0100, Hans de Goede wrote:

Also, instead of inventing yet another vendor-specific property, why not re-use
a button binding similar to gpio-keys like:

lradc: lradc@01c22800 {
compatible = allwinner,sun4i-lradc-keys;
reg = 0x01c22800 0x100;
interrupts = 31;
allwinner,chan0-step = 200;

#address-cells = 1;
#size-cells = 0;

button@0 {
reg = 0; /* your channel index from above */
linux,code = 115; /* already used as dt-property */
};

button@1 {
reg = 1;
linux,code = 114;
};


Ugh no. Having a vendor specific property which is KISS certainly
beats this, both wrt ease of writing dts files as well as wrt the
dts parsing code in the driver.


I'd agree with Heiko here. This is pretty much the same construct
that's already in use in other input drivers, like gpio-keys.


In the gpio case there is a 1 on 1 relation between a single hw
entity (the gpio-pin) and a single keycode. Here there is 1 hw entity
which maps to an array of key-codes, certainly using an array rather
then a much more complicated construct is the correct data-structure
to represent this.



This is also something that can really easily be made generic, since
this is something that is rather common.

Speaking of which. I believe this should actually come in two
different drivers:
   - The ADC driver itself, using IIO
   - A generic button handler driver on top of IIO.


 The fact that on most board this adc is used for buttons doesn't make
 any difference, it's actually a hardware designer choice, we should
 support that choice, but we should also be able to use it just as an
 ADC.

No, this is not a generic adc, as mentioned in the commit msg, this
adc is specifically designed to be used this way.

The adc won't start sampling data, and won't generate any interrupts
until a button is pressed. That is until the input voltage drops below
2/3 of Vref, this is checked through a built-in analog comparator, which
hooks into the control logic.

It has button down and button up interrupts, and can detect long
presses (unused) and generate a second type of down interrupt for those.

This really is an input device, which happens to use an adc.


Carlo Caione already started to work on an IIO driver for the LRADC:
https://github.com/carlocaione/linux/tree/sunxi-lradc
maybe you can take over his work.


That won't work because the adc won't sample if the input gets above
2/3 of Vref. There may be some other mode which does not do that, but
that is not clearly documented.

Even if an IIO driver turns out to be doable, I strongly believe that
having a separate input driver for this is best, since this device
was designed to be used as such. Building input on top of IIO would
mean polling the adc, while with my driver it actually generates
button down / up interrupts without any polling being involved.

And no boards I know of are using this as a generic analog input,
where as many boards are using it as designed.

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/groups/opt_out.

Re: [linux-sunxi] [PATCH] sunxi: Add Inet K70HC device

On Thu, Jan 02, 2014 at 03:17:16PM +0100, Hans de Goede wrote:
 Hi,

 On 01/02/2014 12:37 PM, Luc Verhaegen wrote:
 Signed-off-by: Luc Verhaegen l...@skynet.be

 Thanks, added to the u-boot-sunxi git repo sunxi branch.

 Regards,

 Hans

Thanks!

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/groups/opt_out.

Re: [linux-sunxi] [PATCH] a20: fix up inet_k70hc wifi

On Fri, Jan 03, 2014 at 02:01:54AM +0100, Luc Verhaegen wrote:
 Signed-off-by: Luc Verhaegen l...@skynet.be
 ---
  sys_config/a20/inet_k70hc.fex |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)

With this patch on top, i think that the inet k70hc is well enough 
supported to be included in sunxi-boards.

The OTG port is still useless, but i will document that for the time 
being. I will have to get back to this soon, as i rather rely on g_ether 
for doing development while travelling at 300+kmph. But first i have to 
buy myself a male micro usb connector where i can solder a wire to the 
id pin.

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/groups/opt_out.

Re: [linux-sunxi] Re: Upstreaming sunxi mmc support