Re: [linux-sunxi] Chipone icn85xx TS polling driver

[sergk . inbox]

In addition: 

Actually - yes reading x,y differs between 8318 and 8528.
Regards, 
  Serge Kolotylo.

On Wednesday, May 4, 2016 at 6:02:32 AM UTC, sergk...@gmail.com wrote:
> Hi, 
> Sorry for brief answer - built in did not work for me.
> As minimum in case of Chuwi Vi10 icn8528 you should load firmware with all 
> related to this stuff + irq mode is still under development, under standard 
> things irg/gpio was not getted automatically and there is no enough info at 
> the moment to use irq mode.
> Regarding whether communication part are the same - I do not compare, from 
> the 1st look - looks different, not sure, have no time at the moment to 
> compare.
> Regards,  
>     Serge.
> 
> On Wednesday, May 4, 2016 at 4:26:02 AM UTC, Priit Laes wrote:On Tue, 
> 2016-05-03 at 14:30 -0700, sergk...@gmail.com wrote:
> 
> > Hi all, 
> 
> > ;-) At least I am releasing my icn85xx (tested on icn8528 on Chuvi
> 
> > Vi10, Baytrail) kernel space driver.
> 
> > It is unfortunately polling mode, but at the moment I am happy with
> 
> > it and have no enough time to dig in with irq mode.
> 
> > https://gitlab.com/SergK/icn85xx/tree/master
> 
> 
> 
> 
> 
> Are there any protocol differences between 8318 (already present in
> 
> mainline kernel) and 85xx?
> 
> 
> 
> > My special thanks for their helpto: 
> 
> > Gregor Riepl
> 
> > Mika Westerberg
> 
> > linux-input
> 
> > 
> 
> > Kind regards, 
> 
> >                    Serge Kolotylo.
> 
> > -- 
> 
> > 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...@googlegroups.com.
> 
> > For more options, visit https://groups.google.com/d/optout.

-- 
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 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Christo Radev]

Hi Oliver,

I start performance tests for eMMC, SD/MMC, USB, SATA SSD devices and will 
post the result when ready.

As a beginning I can say that eMMC is accessed via 4-bit bus without matter 
of the patch used.
There you are the content of /sys/kernel/debug/mmcX/ios (where X is number 
of eMMC or SD/MMC device).
Booted from SD card with 8-bit patched kernel
root@egpr:~# dmesg | grep mmc
[3.599625] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[3.631883] sunxi-mmc 1c0f000.mmc: base:0xf08da000 irq:26
[3.669058] mmc0: host does not support reading read-only switch, 
assuming write-enable
[3.671674] sunxi-mmc 1c11000.mmc: base:0xf08de000 irq:27
[3.672064] mmc0: new high speed SDHC card at address 0007
[3.673068] mmcblk0: mmc0:0007 SD04G 3.71 GiB
[3.674785]  mmcblk0: p1
[3.682261] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RTO !!
[3.689280] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.690146] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.690977] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.691808] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.745505] mmc1: MAN_BKOPS_EN bit is not set
[3.749187] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RD EBE !!
[3.749229] sunxi-mmc 1c11000.mmc: data error, sending stop command
[3.749247] sunxi-mmc 1c11000.mmc: send stop command failed
[3.749268] mmc1: switch to bus width 2 failed
[3.753586] mmc1: new high speed MMC card at address 0001
[3.754479] mmcblk1: mmc1:0001 P1 3.60 GiB
[3.754961] mmcblk1boot0: mmc1:0001 P1 partition 1 16.0 MiB
[3.755604] mmcblk1boot1: mmc1:0001 P1 partition 2 16.0 MiB
[3.757045]  mmcblk1: p1
[4.216879] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data 
mode. Opts: (null)
[7.907002] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=
remount-ro

root@egpr:~# cat /sys/kernel/debug/mmc0/ios
clock:  5000 Hz
vdd:21 (3.3 ~ 3.4 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  2 (4 bits)
timing spec:2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type:0 (driver type B)
root@egpr:~# cat /sys/kernel/debug/mmc1/ios
clock:  5000 Hz
vdd:21 (3.3 ~ 3.4 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  2 (4 bits)
timing spec:1 (mmc high-speed)
signal voltage: 0 (3.30 V)
driver type:0 (driver type B)

Booted from SATA SSD with 4-bit patched kernel
[3.598868] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[3.631154] sunxi-mmc 1c0f000.mmc: base:0xf08da000 irq:26
[3.668313] mmc0: host does not support reading read-only switch, 
assuming write-enable
[3.670908] sunxi-mmc 1c11000.mmc: base:0xf08de000 irq:27
[3.671324] mmc0: new high speed SDHC card at address 0007
[3.672302] mmcblk0: mmc0:0007 SD04G 3.71 GiB
[3.674067]  mmcblk0: p1
[3.681882] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RTO !!
[3.686129] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.686996] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.687843] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.688672] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.724762] mmc1: MAN_BKOPS_EN bit is not set
[3.731196] mmc1: new high speed MMC card at address 0001
[3.732141] mmcblk1: mmc1:0001 P1 3.60 GiB
[3.732553] mmcblk1boot0: mmc1:0001 P1 partition 1 16.0 MiB
[3.732960] mmcblk1boot1: mmc1:0001 P1 partition 2 16.0 MiB
[3.734186]  mmcblk1: p1

root@egpr:~# cat /sys/kernel/debug/mmc0/ios
clock:  5000 Hz
vdd:21 (3.3 ~ 3.4 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  2 (4 bits)
timing spec:2 (sd high-speed)
signal voltage: 0 (3.30 V)
driver type:0 (driver type B)
root@egpr:~# cat /sys/kernel/debug/mmc1/ios
clock:  5000 Hz
vdd:21 (3.3 ~ 3.4 V)
bus mode:   2 (push-pull)
chip select:0 (don't care)
power mode: 2 (on)
bus width:  2 (4 bits)
timing spec:1 (mmc high-speed)
signal voltage: 0 (3.30 V)
driver type:0 (driver type B)

The brief performance test using dd shows the similar results to both 4- 
and 8-bit patches
eMMC 8-bit patch R/W test with dd
root@egpr:/mnt# dd if=/dev/zero of=1GBfile bs=1M count=1K
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 79.9305 s, 13.4 MB/s
root@egpr:/mnt# dd of=/dev/null if=1GBfile
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 49.5899 s, 21.7 MB/s

eMMC 4-bit patch R/W test with dd
root@egpr:/mnt# dd if=/dev/zero of=1GBfile bs=1M count=1K
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 78.7925 s, 13.6 MB/s
root@egpr:/mnt# dd of=/dev/null if=1GBfile
2097152+0 records in
2097152+0 records out
1073741824 bytes (1.1 GB) copied, 53.8002 s, 20.0 MB/s

In my opinion 8-bit access to eMMC is broken in 

[linux-sunxi] Re: [PATCHv3] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Maxime Ripard]

On Wed, May 04, 2016 at 03:17:33PM +0200, Olliver Schinagl wrote:
> There are 3 kinds of OLinuXino Lime2 boards.
> One without any on board storage, one with NAND storage and one with
> eMMC storage. This patch adds the eMMC variant of boards.
> 
> eMMC storage is different from a regular SD card in that it is soldered
> on the board and cannot be changed. Additionally, it shares pins with
> the NAND module and with the second SPI port.
> 
> Signed-off-by: Olliver Schinagl 

As a general comment, having a log of the changes helps a lot,
especially when you roll new versions quiclky.

> ---
>  .../boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts| 81 
> ++
>  1 file changed, 81 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> 
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts 
> b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> new file mode 100644
> index 000..9680fcb
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
> @@ -0,0 +1,81 @@
> + /*
> + * Copyright 2015 - Ultimaker B.V.
> + * Author Olliver Schinagl 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +#include "sun7i-a20-olinuxino-lime2.dts"
> +
> +/ {
> + model = "Olimex A20-OLinuXino-LIME2-eMMC";

You should have a compatible here too.

Thanks!
Maxime

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 2/2] ARM: sun7i: dt: Add pll3 and pll7 clocks

[Maxime Ripard]

Hi,

On Tue, May 03, 2016 at 08:14:19PM +0300, Priit Laes wrote:
> Enable pll3 and pll7 clocks that are needed by display clocks.

Missing signed-off-by

> ---
>  arch/arm/boot/dts/sun7i-a20.dtsi | 41 
> 
>  1 file changed, 41 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi 
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index bf5d056..2688512 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -187,6 +187,15 @@
>   clock-output-names = "osc24M";
>   };
>  
> + osc3M: osc3M_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-factor-clock";
> + clock-div = <8>;
> + clock-mult = <1>;
> + clocks = <>;
> + clock-output-names = "osc3M";
> + };
> +
>   osc32k: clk@0 {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
> @@ -211,6 +220,22 @@
>"pll2-4x", "pll2-8x";
>   };
>  
> + pll3: clk@01c20010 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-pll3-clk";
> + reg = <0x01c20010 0x4>;
> + clock = <>;
> + clock-output-names = "pll3";
> +};

The indentation is off.

> +
> + pll3x2: pll3x2_clk {
> + #clock-cells = <0>;
> + compatible = "fixed-factor-clock";
> + clock-div = <1>;
> + clock-mult = <2>;
> + clock-output-names = "pll3-2x";
> + };
> +
>   pll4: clk@01c20018 {
>   #clock-cells = <0>;
>   compatible = "allwinner,sun7i-a20-pll4-clk";
> @@ -236,6 +261,22 @@
>"pll6_div_4";
>   };
>  
> + pll7: clk@01c20030 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-pll3-clk";
> + reg = <0x01c20030 0x4>;
> + clock = <>;
> + clock-output-names = "pll7";
> +};

Ditto.

Thanks!
Maxime

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH 1/2] ARM: sun4i: dt: Add pll3 and pll7 clocks

[Maxime Ripard]

Hi,

On Tue, May 03, 2016 at 08:14:18PM +0300, Priit Laes wrote:
> Enable pll3 and pll7 clocks that are needed to drive display clocks.
> 
> Signed-off-by: Priit Laes 
> ---
>  arch/arm/boot/dts/sun4i-a10.dtsi | 44 
> 
>  1 file changed, 44 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi 
> b/arch/arm/boot/dts/sun4i-a10.dtsi
> index 268a150..c893744 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -184,6 +184,15 @@
>   clock-output-names = "osc24M";
>   };
>  
> + osc3M: osc3M_clk {
> + compatible = "fixed-factor-clock";
> + #clock-cells = <0>;
> + clock-div = <8>;
> + clock-mult = <1>;
> + clocks = <>;
> + clock-output-names = "osc3M";
> + };
> +
>   osc32k: clk@0 {
>   #clock-cells = <0>;
>   compatible = "fixed-clock";
> @@ -208,6 +217,24 @@
>"pll2-4x", "pll2-8x";
>   };
>  
> + pll3: clk@01c20010 {
> + #clock-cells = <0>;
> + compatible = "allwinner,sun4i-a10-pll3-clk";
> + reg = <0x01c20010 0x4>;
> + clocks = <>;
> + clock-output-names = "pll3";
> + };
> +
> + pll3x2: pll3x2_clk {
> + compatible = "fixed-factor-clock";
> + #clock-cells = <0>;
> + clock-div = <1>;
> + clock-mult = <2>;
> + clocks = <>;
> + clock-output-names = "pll3-x2";

We usually call them -2x

> + };
> +
> +

One newline too many.

Fixed it and applied the patch.

Thanks!
Maxime

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH v2 1/1] add missing UARTs pins and I2C entriesfor AllWinner H3 DTSI

[martinayotte]

Bonjour Maxime,

On Monday, May 2, 2016 at 2:46:57 AM UTC-4, Maxime Ripard wrote:
> Hi,
> 
> On Tue, Apr 19, 2016 at 03:50:39PM -0400, Martin Ayotte wrote:
> > Hi everyone,
> > 
> > This patch is submit to provide endusers access to additional UARTs on
> > AllWinner H3 SoC along with I2C ports.
> 
> Unfortunately, your patch cannot be applied in its current form, both
> because of process and technical reasons:
> 
>   * Every commits should have a commit title and log. While you do
> have a title, you used the log to store your cover letter. This is
> an issue, because that will be kept in the git history, which is
> obviously something we don't want.
> If you want to make a cover letter, you can either send it as a
> separate mail, or after the "---" below that will be ignored when
> applying the mails.
> On the other hand, the commit log should be used to say why ýour
> doing this patch and why it was needed.
> 
>   * You do not have a Signed-off-by tag in your commit log. This and
> the point above is documented in Documentation/SubmittingPatches,
> please make sure to read that first.
> 
>   * Your mailer completely corrupted the patch when you sent it,
> replacing all tabs by spaces, and wrapping the longer lines. That
> means that the patch cannot be applied anymore. Please fix your
> mailer, or use one that just works, like git send-email.
> 
>   * Finally, like Chen-Yu already told you, you're doing several
> different things here in a single patch, while you should have
> done separate patches. From what I can see, you're adding pinctrl
> groups for the uart and i2c pins, and adding the i2c controller
> nodes. That should have been ideally 3 patches: 1 for the uart
> pinctrl groups, 1 for the i2c pinctrl groups, 1 for the i2c
> controller nodes. We also don't take pinctrl groups that are not
> enabled on any boards to keep the DT size as small as possible.
> 
> Thanks,
> Maxime
> 
> -- 
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com

Thanks for your help and make me understanding more the process.

I've now prepared a new v3 for that, and just send it.
Strangely, it seems that the 3 patches been sent separately. 
I will try to figure out what happened.

Regards,
Martin.

-- 
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] [PATCH v3 3/3] dts: sun8i-h3: add i2c0/i2c1/i2c2 soc peripherals

[Martin Ayotte]

dts sun8i-h3: add i2c0/i2c1/i2c2 soc peripherals

Signed-off-by: Martin Ayotte 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 33 +
 1 file changed, 33 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 79a3af6..c947360d 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -668,6 +668,39 @@
status = "disabled";
};
 
+   i2c0: i2c@01c2ac00 {
+   compatible = "allwinner,sun6i-a31-i2c";
+   reg = <0x01c2ac00 0x400>;
+   interrupts = ;
+   clocks = <_gates 96>;
+   resets = <_rst 0>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   i2c1: i2c@01c2b000 {
+   compatible = "allwinner,sun6i-a31-i2c";
+   reg = <0x01c2b000 0x400>;
+   interrupts = ;
+   clocks = <_gates 97>;
+   resets = <_rst 1>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
+   i2c2: i2c@01c2b400 {
+   compatible = "allwinner,sun6i-a31-i2c";
+   reg = <0x01c2b400 0x400>;
+   interrupts = ;
+   clocks = <_gates 98>;
+   resets = <_rst 2>;
+   status = "disabled";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
gic: interrupt-controller@01c81000 {
compatible = "arm,cortex-a7-gic", "arm,cortex-a15-gic";
reg = <0x01c81000 0x1000>,
-- 
2.7.4

-- 
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] [PATCH v3 2/3] dts: sun8i-h3: add i2c0/i2c1/i2c2 pins definitions

[Martin Ayotte]

dts: sun8i-h3: add i2c0/i2c1/i2c2 pins definitions

Signed-off-by: Martin Ayotte 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 292ed59..79a3af6 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -529,6 +529,27 @@
allwinner,pull = ;
};
 
+   i2c0_pins_a: i2c0@0 {
+   allwinner,pins = "PA11", "PA12";
+   allwinner,function = "i2c0";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   i2c1_pins_a: i2c1@0 {
+   allwinner,pins = "PA18", "PA19";
+   allwinner,function = "i2c1";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   i2c2_pins_a: i2c2@0 {
+   allwinner,pins = "PE12", "PE13";
+   allwinner,function = "i2c2";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
mmc0_pins_a: mmc0@0 {
allwinner,pins = "PF0", "PF1", "PF2", "PF3",
 "PF4", "PF5";
-- 
2.7.4

-- 
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] [PATCH v3 1/3] dts: sun8i-h3: add uart1/uart2/uart3 pins definitions

[Martin Ayotte]

dts: sun8i-h3: add uart1/uart2/uart3 pins definitions

Signed-off-by: Martin Ayotte 
---
 arch/arm/boot/dts/sun8i-h3.dtsi | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
index 4a4926b..292ed59 100644
--- a/arch/arm/boot/dts/sun8i-h3.dtsi
+++ b/arch/arm/boot/dts/sun8i-h3.dtsi
@@ -508,6 +508,27 @@
allwinner,pull = ;
};
 
+   uart1_pins_a: uart1@0 {
+   allwinner,pins = "PG6", "PG7";
+   allwinner,function = "uart1";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   uart2_pins_a: uart2@0 {
+   allwinner,pins = "PA0", "PA1";
+   allwinner,function = "uart2";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
+   uart3_pins_a: uart3@0 {
+   allwinner,pins = "PA13", "PA14";
+   allwinner,function = "uart3";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+
mmc0_pins_a: mmc0@0 {
allwinner,pins = "PF0", "PF1", "PF2", "PF3",
 "PF4", "PF5";
-- 
2.7.4

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH v2 2/6] mfd: axp20x: Add register bits for axp20x-ac-power

[Maxime Ripard]

Hi,

On Mon, May 02, 2016 at 09:35:01AM +0800, Chen-Yu Tsai wrote:
> On Sun, May 1, 2016 at 10:24 PM, Michael Haas  
> wrote:
> > On 05/01/2016 11:48 AM, Chen-Yu Tsai wrote:
> >> Hi,
> >>
> >> On Sun, May 1, 2016 at 4:57 PM, Michael Haas  
> >> wrote:
> >>> This change adds some register bit definitions used by the
> >>> axp20x-ac-power driver.
> >>>
> >>> Signed-off-by: Michael Haas 
> >>> ---
> >>>  include/linux/mfd/axp20x.h | 11 +++
> >>>  1 file changed, 11 insertions(+)
> >>>
> >>> diff --git a/include/linux/mfd/axp20x.h b/include/linux/mfd/axp20x.h
> >>> index d82e7d5..c4c6dfa 100644
> >>> --- a/include/linux/mfd/axp20x.h
> >>> +++ b/include/linux/mfd/axp20x.h
> >>> @@ -90,6 +90,17 @@ enum {
> >>>  #define AXP22X_ALDO3_V_OUT 0x2a
> >>>  #define AXP22X_CHRG_CTRL3  0x35
> >>>
> >>> +
> >>> +/* Fields of AXP20X_PWR_INPUT_STATUS */
> >>> +#define AXP20X_PWR_STATUS_AC_PRESENT BIT(7)
> >>> +#define AXP20X_PWR_STATUS_AC_AVAILABLE   BIT(6)
> >>> +#define AXP20X_PWR_STATUS_AC_VBUS_SHORT  BIT(1)
> >>> +#define AXP20X_PWR_STATUS_AC_VBUS_SELBIT(0)
> >>> +
> >>> +/* Fields of AXP20X_ADC_EN1 */
> >>> +#define AXP20X_ADC_EN1_ACIN_VOLT BIT(5)
> >>> +#define AXP20X_ADC_EN1_ACIN_CURR BIT(4)
> >>> +
> >>
> >> We keep the bit definitions of each register in each separate driver.
> >> The drivers only define the ones they use.
> >>
> >> ChenYu
> >
> > Hi ChenYu,
> >
> > i believe Maxime Ripard requested that these defines be moved to the
> > header: https://groups.google.com/d/msg/linux-sunxi/nEUg87cV6KI/TvdB6MBZBAAJ
> >
> > What do you think?
> 
> My argument is kind of weak, and really comes down to preference.
> 
> Currently the register bit definitions are scattered in various drivers,
> which is fine given they are really specific to the part of hardware the
> driver supports. Gathering them all together might increase the size of
> the header file substantially. As I see it the chanses that bits from
> one part are going to be used in another are rather small.
> 
> Some register address macros are shared, such as for the 2 power supply
> drivers, and for the regmap definitions. So those would need to go in a
> shared header anyway.

Sorry for the misunderstanding. I was assuming that having all the
registers and associated bits would be better off in a common header
where all the drivers could refer to, but you're the maintainer on
that on, so it's up to you ;)

Maxime

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

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH v4 00/11] drm: Add Allwinner A10 display engine support

[Maxime Ripard]

On Mon, Apr 25, 2016 at 03:22:41PM +0200, Maxime Ripard wrote:
> Hi everyone,
> 
> The Allwinner SoCs (except for the very latest ones) all share the
> same set of controllers, loosely coupled together to form the display
> pipeline.
> 
> Depending on the SoC, the number of instances of the controller will
> change (2 instances of each in the A10, only one in the A13, for
> example), and the output availables will change too (HDMI, composite,
> VGA on the A20, none of them on the A13).
> 
> On most featured SoCs, it looks like that:
> 
> ++
> |RAM |
> ++
>   ||  ||
>   v|  |v
> ++ |  | ++
> |Frontend| |  | |Frontend|
> ++ |  | ++
> |  |  | |
> v  |  | v
> ++ |  | ++
> |Backend |<+  +>|Backend |
> ++  ++
> |   |
> v   v
> ++  ++---> LVDS
> |  TCON  |  |  TCON  |---> RGB
> ++  ++
>   |   +---+   +---+  |
>   |   |   |  |
>   v   v   v  v
> ++  ++  ++---> VGA
> | TV Encoder |  |HDMI|  | TV Encoder |---> Composite
> ++  ++  ++
> 
> The current code only assumes that there is a single instance of all
> the controllers. It also supports only the RGB and Composite
> interfaces.
> 
> Let me know what you think,
> Maxime
> 
> Changes from v3:
>   - Fixed a circular dependency issue found when building as a module
>   - Changed a bit the mode_valid checks
>   - Fixed an issue with the timings generated by the display engine
> 
>   - Changed the DT bindings according to Rob feedback (removed the
> allwinner,panel property, documented the endpoints indices, always
> use the frontend as the pipeline entrypoint)
> 
>   - Changed the display clocks according to Stephen comments (marked
> structures as const, changed a variable name)
> 
> Changes from v2:
>   - Rebased on top of next-20160318
> 
>   - Dropped the generic clock regmap conversion and implemented a
> custom clock for our pixel clock, backed by a regmap
>   - Added the reset bits for the tcon channel 0 and display clocks
>   - Used the new generic gates compatible for the DRAM gates
>   - Few clock fixes (missing iounmap, return error checks, etc)
>   - Found out that the TCON channel 1 clock was not operating properly
> because of some weird rounding down and up between the various
> generic clocks involved. Rewrote it using custom operations
> 
>   - Removed some TODO that were still there
>   - Converted our panel DT description to the OF graph instead of a
> custom property
>   - Tested the driver on a setup where U-Boot was not initialising the
> display, or initialising it on a different output, and fixed a
> number of associated bugs (mostly related to missing
> initialisation bits, missing reset handles, and so on)
>   - Fixed the layer code that was assuming that the X and Y
> coordinates were in pixels, leading to a miscalculation of the
> buffer address when those coordinates where set.
>   - Added the missing EXPORT_SYMBOL calls
> 
>   - Fixed our VBLANK interrupt code that was completely broken (and
> not usable, which is why it was unnoticed)
> 
> Changes from v1:
>   - Rebased on top of 4.4
> 
>   - Merged the clock drivers for the display and TCON channel 0 clocks
>   - Replaced the container_of calls in the display reset clocks to an
> inline function
>   - Checked the return code of of_clk_parent_fill in the clocks
> drivers
>   - Checked the return code of of_clk_add_provider in the tcon-ch1 and
> PLL3 clocks
>   - Added missing clocks headers
>   - Created a composite clock unregister function
> 
>   - Moved the binding documentation to
> Documentation/devicetree/bindings/display
>   - Added the clocks binding documentation
>   - Added the Olimex vendor to the list of DT vendors
>   - Moved to the OF graph representation and the component framework
> 
>   - Moved the reset cells count check into the reset framework to
> avoid duplicating the code in every xlate implementation.
>   - Made the reset_ops const
> 
>   - Reworked the DRM cmdline mode parsing code to allow named mode
>   - Fixed the TV mode lookup when the mode name is not present (for
> example because it was given by the userspace)
> 
>   - Made the driver outputs optional (to avoid crashing when a board
> doesn't have either a panel or a composite 

Re: [linux-sunxi] [PATCH] musb: sunxi: Ignore VBus errors in host-only mode

[Christo Radev]

Hi to All,

There you are the final patch I have used against kernel 4.5.2 to enable 
'host' only mode on USB OTG on A20-Olinuxino-Lime2-eMMC:
diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts b/arch/arm/boot
/dts/sun7i-a20-olinuxino-lime2.dts
index d5c796c..d09cebe 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -215,20 +215,6 @@
 allwinner,pull = ;
 };
 
-usb0_id_detect_pin: usb0_id_detect_pin@0 {
-allwinner,pins = "PH4";
-allwinner,function = "gpio_in";
-allwinner,drive = ;
-allwinner,pull = ;
-};
-
-usb0_vbus_detect_pin: usb0_vbus_detect_pin@0 {
-allwinner,pins = "PH5";
-allwinner,function = "gpio_in";
-allwinner,drive = ;
-allwinner,pull = ;
-};
-
 usb0_vbus_pin_lime2: usb0_vbus_pin@0 {
 allwinner,pins = "PC17";
 allwinner,function = "gpio_out";
@@ -264,15 +250,11 @@
 };
 
 _otg {
-dr_mode = "otg";
+dr_mode = "host";
 status = "okay";
 };
 
  {
-pinctrl-names = "default";
-pinctrl-0 = <_id_detect_pin>, <_vbus_detect_pin>;
-usb0_id_det-gpio = < 7 4 GPIO_ACTIVE_HIGH>; /* PH4 */
-usb0_vbus_det-gpio = < 7 5 GPIO_ACTIVE_HIGH>; /* PH5 */
 usb0_vbus-supply = <_usb0_vbus>;
 usb1_vbus-supply = <_usb1_vbus>;
 usb2_vbus-supply = <_usb2_vbus>;

Corresponding boot messages:
[3.917976] usb_phy_generic.0.auto supply vcc not found, using dummy 
regulator
[3.918578] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[3.918598] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned 
bus number 5
[3.918979] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002
[3.918993] usb usb5: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[3.919004] usb usb5: Product: MUSB HDRC host driver
[3.919013] usb usb5: Manufacturer: Linux 4.5.2-sunxi musb-hcd
[3.919022] usb usb5: SerialNumber: musb-hdrc.1.auto

And messages after connecting of USB Flash via USB OTG to Host cable:
[ 1356.542871] usb 5-1: new high-speed USB device number 2 using musb-hdrc
[ 1356.684880] usb 5-1: New USB device found, idVendor=090c, idProduct=1000
[ 1356.684917] usb 5-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[ 1356.684935] usb 5-1: Product: Flash Voyager
[ 1356.684952] usb 5-1: Manufacturer: Corsair
[ 1356.684968] usb 5-1: SerialNumber: AA001460
[ 1356.686555] usb-storage 5-1:1.0: USB Mass Storage device detected
[ 1356.689189] scsi host1: usb-storage 5-1:1.0
[ 1356.755118] usbcore: registered new interface driver uas

Any ideas how to enable full USB OTG functionality?

Best regards
Chris



-- 
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 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Christo Radev]

Hi Oliver,

I have just tested your patch and the access to eMMC is working.
There you are complete patch I have applied against kernel 4.5.2:
index d5c796c..1f5339d 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
@@ -188,6 +188,15 @@
 status = "okay";
 };
 
+ {
+pinctrl-names = "default";
+pinctrl-0 = <_pins_a>;
+vmmc-supply = <_vcc3v3>;
+bus-width = <8>;
+non-removable;
+status = "okay";
+};
+
  {
 status = "okay";
 };
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 3d5087b..78668aa 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -504,7 +504,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
*ext_csd)
 pr_info("%s: MAN_BKOPS_EN bit is not set\n",
 mmc_hostname(card->host));
 }
-
+#if 0
 /* check whether the eMMC card supports HPI */
 if (!broken_hpi && (ext_csd[EXT_CSD_HPI_FEATURES] & 0x1)) {
 card->ext_csd.hpi = 1;
@@ -519,7 +519,7 @@ static int mmc_decode_ext_csd(struct mmc_card *card, u8 
*ext_csd)
 card->ext_csd.out_of_int_time =
 ext_csd[EXT_CSD_OUT_OF_INTERRUPT_TIME] * 10;
 }
-
+#endif
 card->ext_csd.rel_param = ext_csd[EXT_CSD_WR_REL_PARAM];
 card->ext_csd.rst_n_function = ext_csd[EXT_CSD_RST_N_FUNCTION];
 
diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c b/drivers/pinctrl/
sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..9fc12d2 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -314,19 +314,23 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = 
{
 SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
   SUNXI_FUNCTION(0x0, "gpio_in"),
   SUNXI_FUNCTION(0x1, "gpio_out"),
-  SUNXI_FUNCTION(0x2, "nand0")),/* NDQ4 */
+  SUNXI_FUNCTION(0x2, "nand0"),/* NDQ4 */
+  SUNXI_FUNCTION(0x3, "mmc2")), /* D4 */
 SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
   SUNXI_FUNCTION(0x0, "gpio_in"),
   SUNXI_FUNCTION(0x1, "gpio_out"),
-  SUNXI_FUNCTION(0x2, "nand0")),/* NDQ5 */
+  SUNXI_FUNCTION(0x2, "nand0"),/* NDQ5 */
+  SUNXI_FUNCTION(0x3, "mmc2")), /* D5 */
 SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
   SUNXI_FUNCTION(0x0, "gpio_in"),
   SUNXI_FUNCTION(0x1, "gpio_out"),
-  SUNXI_FUNCTION(0x2, "nand0")),/* NDQ6 */
+  SUNXI_FUNCTION(0x2, "nand0"),/* NDQ6 */
+  SUNXI_FUNCTION(0x3, "mmc2")), /* D6 */
 SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
   SUNXI_FUNCTION(0x0, "gpio_in"),
   SUNXI_FUNCTION(0x1, "gpio_out"),
-  SUNXI_FUNCTION(0x2, "nand0")),/* NDQ7 */
+  SUNXI_FUNCTION(0x2, "nand0"),/* NDQ7 */
+  SUNXI_FUNCTION(0x3, "mmc2")), /* D7 */
 SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 16),
   SUNXI_FUNCTION(0x0, "gpio_in"),
   SUNXI_FUNCTION(0x1, "gpio_out"),

And the boot messages:
[3.598495] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[3.631826] sunxi-mmc 1c0f000.mmc: base:0xf08da000 irq:26
[3.668943] mmc0: host does not support reading read-only switch, 
assuming write-enable
[3.671887] sunxi-mmc 1c11000.mmc: base:0xf08de000 irq:27
[3.671935] mmc0: new high speed SDHC card at address 0007
[3.672939] mmcblk0: mmc0:0007 SD04G 3.71 GiB
[3.674799]  mmcblk0: p1
[3.682634] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RTO !!
[3.687921] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.688785] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.689643] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.690477] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[3.725492] mmc1: MAN_BKOPS_EN bit is not set
[3.729187] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RD EBE !!
[3.729228] sunxi-mmc 1c11000.mmc: data error, sending stop command
[3.729247] sunxi-mmc 1c11000.mmc: send stop command failed
[3.729270] mmc1: switch to bus width 2 failed
[3.733592] mmc1: new high speed MMC card at address 0001
[3.734478] mmcblk1: mmc1:0001 P1 3.60 GiB
[3.734889] mmcblk1boot0: mmc1:0001 P1 partition 1 16.0 MiB
[3.735305] mmcblk1boot1: mmc1:0001 P1 partition 2 16.0 MiB
[3.736551]  mmcblk1: p1
[4.155620] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data 
mode. Opts: (null)
[8.163191] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=
remount-ro
where mmc0 is SD/MMC card and mmc1 is eMMC on my A20-Olinuxino-Lime2-eMMC 
board.

Fortunately or not the same error and fail messages can be observed in my 
board log.

How can I verify how wide is the eMMC bus used in real?

Best regards
Chris


On Wednesday, May 4, 2016 at 6:09:44 PM UTC+3, Olliver Schinagl wrote:
>
> Christo,
>
> On 04-05-16 16:31, Christo Radev wrote:
>
> Tanks Oliver,
>
> It could be the problem to get 8-bit access working.
>
> Unfortunately, 

Re: [linux-sunxi] USB OTG on A20 Lime2 board does not work with mainline kernel

[Christo Radev]

Thanks David,

I take a brief look on your .config file and do not see any important 
differences around USB OTG.

In my opinion the problem most probably comes from device tree 
configuration or some recent changes in the driver (I use kernel 4.5.2).

Could you send me yor dtb file used at boot time together with the kernel?
You can find it as /boot/dtb/sun7i-a20-cubietruck.dtb on the board's rootfs.

Best regards
Chris

On Wednesday, May 4, 2016 at 7:07:05 PM UTC+3, ddis...@gmail.com wrote:
>
> On Wednesday, May 4, 2016 at 4:24:32 PM UTC+2, Christo Radev wrote: 
> > Hi to All, 
> > 
> > Following Michal Suchanek's post and applying Maxime Ripard's advice USB 
> OTG started working in host only mode. 
> > 
> > Unfortunately, it solves the problem in a half so any ideas are welcome. 
>
> A different A20 board (cubietruck), but might still be useful... 
> USB OTG device mode worked fine with a vanilla 4.4.0-rc4 kernel 
> for a recent project: 
> (http://blog.elastocloud.org/2015/12/ceph-usb-storage-gateway.html). 
>
> The kernel config that I used can be found at: 
> https://raw.githubusercontent.com/ddiss/ceph_usb_gateway/master/.config 
>
> Cheers, David

-- 
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] USB OTG on A20 Lime2 board does not work with mainline kernel

[ddiss . dev]

On Wednesday, May 4, 2016 at 4:24:32 PM UTC+2, Christo Radev wrote:
> Hi to All,
> 
> Following Michal Suchanek's post and applying Maxime Ripard's advice USB OTG 
> started working in host only mode.
> 
> Unfortunately, it solves the problem in a half so any ideas are welcome.

A different A20 board (cubietruck), but might still be useful...
USB OTG device mode worked fine with a vanilla 4.4.0-rc4 kernel
for a recent project:
(http://blog.elastocloud.org/2015/12/ceph-usb-storage-gateway.html).

The kernel config that I used can be found at:
https://raw.githubusercontent.com/ddiss/ceph_usb_gateway/master/.config

Cheers, David

-- 
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 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Christo Radev]

Thanks Oliver,

I find it and will be back with the test results.

Best regards
Chris

On Wednesday, May 4, 2016 at 6:09:44 PM UTC+3, Olliver Schinagl wrote:
>
> Christo,
>
> On 04-05-16 16:31, Christo Radev wrote:
>
> Tanks Oliver,
>
> It could be the problem to get 8-bit access working.
>
> Unfortunately, I do not see where to make this changes because original 
> dts files 
> 
>  
> are used in Armbian build.
> I also see '*SUNXI_PINCTRL_PIN*' and '*SUNXI_FUNCTION*' may require some 
> patches in addition.
>
> check out drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
>
> my patch should still work aginst that.
>
>
> I am ready to make 8-bit eMMC access tests again so could you help me with 
> the needed staff it has to be used.
>
> I don't mind, but lets take it off list for that :)
>
> Olliver
>
>
> Best regards
> Chris
>
> On Wednesday, May 4, 2016 at 4:59:52 PM UTC+3, Olliver Schinagl wrote: 
>>
>> Hey Christo,
>>
>> On 04-05-16 15:32, Christo Radev wrote:
>>
>> Hi Oliver,
>>
>> I do: that 
>> http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7359
>> The syntax error seen there was fixed and the result is: 
>> http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7361
>>
>> Nope, you are still forgetting and seeing an 'unsupported function' error 
>> because of it.
>>
>> You forgot to add:
>>
>> >>>*  SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
>> *>>>*SUNXI_FUNCTION(0x0, "gpio_in"),
>> *>>>*SUNXI_FUNCTION(0x1, "gpio_out"),
>> *>>>* - SUNXI_FUNCTION(0x2, "nand0")),/* NDQ4 */
>> *>>>* + SUNXI_FUNCTION(0x2, "nand0"), /* NDQ4 */
>> *>>>* + SUNXI_FUNCTION(0x3, "mmc2")), /* D4 */
>> *>>>*  SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
>> *>>>*SUNXI_FUNCTION(0x0, "gpio_in"),
>> *>>>*SUNXI_FUNCTION(0x1, "gpio_out"),
>> *>>>* - SUNXI_FUNCTION(0x2, "nand0")),/* NDQ5 */
>> *>>>* + SUNXI_FUNCTION(0x2, "nand0"), /* NDQ5 */
>> *>>>* + SUNXI_FUNCTION(0x3, "mmc2")), /* D5 */
>> *>>>*  SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
>> *>>>*SUNXI_FUNCTION(0x0, "gpio_in"),
>> *>>>*SUNXI_FUNCTION(0x1, "gpio_out"),
>> *>>>* - SUNXI_FUNCTION(0x2, "nand0")),/* NDQ6 */
>> *>>>* + SUNXI_FUNCTION(0x2, "nand0"), /* NDQ6 */
>> *>>>* + SUNXI_FUNCTION(0x3, "mmc2")), /* D6 */
>> *>>>*  SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
>> *>>>*SUNXI_FUNCTION(0x0, "gpio_in"),
>> *>>>*SUNXI_FUNCTION(0x1, "gpio_out"),
>> *>>>* - SUNXI_FUNCTION(0x2, "nand0")),/* NDQ7 */
>> *>>>* + SUNXI_FUNCTION(0x2, "nand0"), /* NDQ7 */
>> *>>>* + SUNXI_FUNCTION(0x3, "mmc2")), /* D7 */*
>>
>>
>> to actually get the pin functions.
>>
>>
>> The same tests was done on legacy kernel 3.4.111 modifying fex file and 
>> the result is the same: 
>> http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7265
>>
>>
>> Best regards
>> Chris
>>
>>
>> On Wednesday, May 4, 2016 at 4:19:20 PM UTC+3, Olliver Schinagl wrote: 
>>>
>>> Hey Christo,
>>>
>>> On 04-05-16 15:07, Christo Radev wrote:
>>>
>>> Hi Olliver,
>>>
>>> I have already test it a few weeks ago and definitely can say that 8-bit 
>>> bus did not work on A20-Olinuxino-Lime2-eMMC with mainline kernel.
>>> See may post here 
>>> 
>>> .
>>>
>>> I saw, but you forgot to define the pins for 4.x :)
>>>
>>> See my patch from earlier: 
>>> 
>>> http://lists.infradead.org/
>>> pipermail/linux-arm-kernel/2015-September/368887.html
>>>
>>> Olliver
>>>
>>>
>>> Best regards
>>>
>>> Chris
>>>
>>> On Wednesday, May 4, 2016 at 3:52:17 PM UTC+3, Olliver Schinagl wrote: 

 Hey Radoslav, 

 On 04-05-16 14:30, Radoslav Kolev wrote: 
 > 2016-05-03 10:25 GMT+03:00 Chen-Yu Tsai : 
 >> On Tue, May 3, 2016 at 3:21 PM, Olliver Schinagl  
 wrote: 
 > +   bus-width = <4>; 
  Only 4 bits? We normally see eMMC with 8 bits. 4 bits are some 
 kind of 
  embedded SD card. 
 >>> On A20 as well? Our investigations so far have concluded that the 
 A10 and 
 >>> A20 have those pins not mapped out to pads. The IP does support it 
 however 
 >>> we assume. 
 >> You're right. My bad. First time A10/A20 sees eMMC support. 
 > I can't say anything about A10/A20, but I have a board with A13 and 
 > the same eMMC chip 

[linux-sunxi] Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Olliver Schinagl]

Christo,

On 04-05-16 16:31, Christo Radev wrote:

Tanks Oliver,

It could be the problem to get 8-bit access working.

Unfortunately, I do not see where to make this changes because 
original dts files 
 
are used in Armbian build.
I also see '/SUNXI_PINCTRL_PIN/' and '/SUNXI_FUNCTION/' may require 
some patches in addition.

check out drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c

my patch should still work aginst that.


I am ready to make 8-bit eMMC access tests again so could you help me 
with the needed staff it has to be used.

I don't mind, but lets take it off list for that :)

Olliver


Best regards
Chris

On Wednesday, May 4, 2016 at 4:59:52 PM UTC+3, Olliver Schinagl wrote:

Hey Christo,

On 04-05-16 15:32, Christo Radev wrote:

Hi Oliver,

I do: that

http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7359


The syntax error seen there was fixed and the result is:

http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7361



Nope, you are still forgetting and seeing an 'unsupported
function' error because of it.

You forgot to add:

>>>/SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12), />>>/SUNXI_FUNCTION(0x0, "gpio_in"), />>>/SUNXI_FUNCTION(0x1, "gpio_out"), />>>/- SUNXI_FUNCTION(0x2, "nand0")), /* NDQ4 */ />>>/+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ4 */ />>>/+ SUNXI_FUNCTION(0x3, "mmc2")), /* D4 */ />>>/SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13), />>>/SUNXI_FUNCTION(0x0, "gpio_in"), 
/>>>/SUNXI_FUNCTION(0x1, "gpio_out"), />>>/- SUNXI_FUNCTION(0x2, "nand0")), /* NDQ5 */ />>>/+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ5 */ />>>/+ SUNXI_FUNCTION(0x3, "mmc2")), /* D5 */ />>>/SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14), />>>/SUNXI_FUNCTION(0x0, "gpio_in"), />>>/SUNXI_FUNCTION(0x1, "gpio_out"), />>>/- SUNXI_FUNCTION(0x2, "nand0")), /* NDQ6 */ 
/>>>/+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ6 */ />>>/+ SUNXI_FUNCTION(0x3, "mmc2")), /* D6 */ />>>/SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15), />>>/SUNXI_FUNCTION(0x0, "gpio_in"), />>>/SUNXI_FUNCTION(0x1, "gpio_out"), />>>/- SUNXI_FUNCTION(0x2, "nand0")), /* NDQ7 */ />>>/+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ7 */ />>>/+ SUNXI_FUNCTION(0x3, "mmc2")), /* D7 *//


to actually get the pin functions.


The same tests was done on legacy kernel 3.4.111 modifying fex
file and the result is the same:

http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7265




Best regards
Chris


On Wednesday, May 4, 2016 at 4:19:20 PM UTC+3, Olliver Schinagl
wrote:

Hey Christo,

On 04-05-16 15:07, Christo Radev wrote:

Hi Olliver,

I have already test it a few weeks ago and definitely can
say that 8-bit bus did not work on A20-Olinuxino-Lime2-eMMC
with mainline kernel.
See may post here

.

I saw, but you forgot to define the pins for 4.x :)

See my patch from earlier:

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/368887.html



Olliver



Best regards

Chris

On Wednesday, May 4, 2016 at 3:52:17 PM UTC+3, Olliver
Schinagl wrote:

Hey Radoslav,

On 04-05-16 14:30, Radoslav Kolev wrote:
> 2016-05-03 10:25 GMT+03:00 Chen-Yu Tsai :
>> On Tue, May 3, 2016 at 3:21 PM, Olliver Schinagl
 wrote:
> +   bus-width = <4>;
 Only 4 bits? We normally see eMMC with 8 bits. 4
bits are some kind of
 embedded SD card.
>>> On A20 as well? Our investigations so far have
concluded that the A10 and
>>> A20 have those pins not mapped out to pads. The IP
does support it however
>>> we assume.
>> You're right. My bad. First time A10/A20 sees eMMC
support.
> I can't say anything about A10/A20, but I have a board
with A13 and
> the same eMMC chip and it works fine in 8 bit mode.
Yep, sun5i actually brings them all out to pads, the A20
however does
not :( We first thought that the A20 would also be an
8bitter, because
the mmc IP appears to be the same as sun5i, but initial
tests show it is
not. As for A10, it has older 

[linux-sunxi] Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Christo Radev]

Tanks Oliver,

It could be the problem to get 8-bit access working.

Unfortunately, I do not see where to make this changes because original dts 
files 

 
are used in Armbian build.
I also see '*SUNXI_PINCTRL_PIN*' and '*SUNXI_FUNCTION*' may require some 
patches in addition.

I am ready to make 8-bit eMMC access tests again so could you help me with 
the needed staff it has to be used.

Best regards
Chris

On Wednesday, May 4, 2016 at 4:59:52 PM UTC+3, Olliver Schinagl wrote:
>
> Hey Christo,
>
> On 04-05-16 15:32, Christo Radev wrote:
>
> Hi Oliver,
>
> I do: that 
> http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7359
> The syntax error seen there was fixed and the result is: 
> http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7361
>
> Nope, you are still forgetting and seeing an 'unsupported function' error 
> because of it.
>
> You forgot to add:
>
> >>>*  SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12),
> *>>>*SUNXI_FUNCTION(0x0, "gpio_in"),
> *>>>*SUNXI_FUNCTION(0x1, "gpio_out"),
> *>>>* - SUNXI_FUNCTION(0x2, "nand0")),/* NDQ4 */
> *>>>* + SUNXI_FUNCTION(0x2, "nand0"), /* NDQ4 */
> *>>>* + SUNXI_FUNCTION(0x3, "mmc2")), /* D4 */
> *>>>*  SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13),
> *>>>*SUNXI_FUNCTION(0x0, "gpio_in"),
> *>>>*SUNXI_FUNCTION(0x1, "gpio_out"),
> *>>>* - SUNXI_FUNCTION(0x2, "nand0")),/* NDQ5 */
> *>>>* + SUNXI_FUNCTION(0x2, "nand0"), /* NDQ5 */
> *>>>* + SUNXI_FUNCTION(0x3, "mmc2")), /* D5 */
> *>>>*  SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14),
> *>>>*SUNXI_FUNCTION(0x0, "gpio_in"),
> *>>>*SUNXI_FUNCTION(0x1, "gpio_out"),
> *>>>* - SUNXI_FUNCTION(0x2, "nand0")),/* NDQ6 */
> *>>>* + SUNXI_FUNCTION(0x2, "nand0"), /* NDQ6 */
> *>>>* + SUNXI_FUNCTION(0x3, "mmc2")), /* D6 */
> *>>>*  SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15),
> *>>>*SUNXI_FUNCTION(0x0, "gpio_in"),
> *>>>*SUNXI_FUNCTION(0x1, "gpio_out"),
> *>>>* - SUNXI_FUNCTION(0x2, "nand0")),/* NDQ7 */
> *>>>* + SUNXI_FUNCTION(0x2, "nand0"), /* NDQ7 */
> *>>>* + SUNXI_FUNCTION(0x3, "mmc2")), /* D7 */*
>
>
> to actually get the pin functions.
>
>
> The same tests was done on legacy kernel 3.4.111 modifying fex file and 
> the result is the same: 
> http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7265
>
>
> Best regards
> Chris
>
>
> On Wednesday, May 4, 2016 at 4:19:20 PM UTC+3, Olliver Schinagl wrote: 
>>
>> Hey Christo,
>>
>> On 04-05-16 15:07, Christo Radev wrote:
>>
>> Hi Olliver,
>>
>> I have already test it a few weeks ago and definitely can say that 8-bit 
>> bus did not work on A20-Olinuxino-Lime2-eMMC with mainline kernel.
>> See may post here 
>> 
>> .
>>
>> I saw, but you forgot to define the pins for 4.x :)
>>
>> See my patch from earlier: 
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/368887.html
>>
>> Olliver
>>
>>
>> Best regards
>>
>> Chris
>>
>> On Wednesday, May 4, 2016 at 3:52:17 PM UTC+3, Olliver Schinagl wrote: 
>>>
>>> Hey Radoslav, 
>>>
>>> On 04-05-16 14:30, Radoslav Kolev wrote: 
>>> > 2016-05-03 10:25 GMT+03:00 Chen-Yu Tsai : 
>>> >> On Tue, May 3, 2016 at 3:21 PM, Olliver Schinagl  
>>> wrote: 
>>> > +   bus-width = <4>; 
>>>  Only 4 bits? We normally see eMMC with 8 bits. 4 bits are some kind 
>>> of 
>>>  embedded SD card. 
>>> >>> On A20 as well? Our investigations so far have concluded that the 
>>> A10 and 
>>> >>> A20 have those pins not mapped out to pads. The IP does support it 
>>> however 
>>> >>> we assume. 
>>> >> You're right. My bad. First time A10/A20 sees eMMC support. 
>>> > I can't say anything about A10/A20, but I have a board with A13 and 
>>> > the same eMMC chip and it works fine in 8 bit mode. 
>>> Yep, sun5i actually brings them all out to pads, the A20 however does 
>>> not :( We first thought that the A20 would also be an 8bitter, because 
>>> the mmc IP appears to be the same as sun5i, but initial tests show it is 
>>> not. As for A10, it has older IP and it might not even support 8 bit 
>>> mode, let alone bring out the pins. 
>>>
>>> But with A20's + eMMC being available via the lime2, others may repeat 
>>> my experiments! The lime2 is 8 bit connected. 
>>>
>>> Olliver 
>>> > 
>>> > Regards, 
>>> > Radoslav 
>>>
>>>
>>
>

-- 
You received this message 

[linux-sunxi] Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Olliver Schinagl]

Hey Christo,

On 04-05-16 15:32, Christo Radev wrote:

Hi Oliver,

I do: that 
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7359
The syntax error seen there was fixed and the result is: 
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7361
Nope, you are still forgetting and seeing an 'unsupported function' 
error because of it.


You forgot to add:


/SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 12), />>>/SUNXI_FUNCTION(0x0, "gpio_in"), />>>/SUNXI_FUNCTION(0x1, "gpio_out"), />>>/- SUNXI_FUNCTION(0x2, "nand0")), /* NDQ4 */ />>>/+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ4 */ />>>/+ SUNXI_FUNCTION(0x3, "mmc2")), /* D4 */ />>>/SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 13), />>>/SUNXI_FUNCTION(0x0, "gpio_in"), 
/>>>/SUNXI_FUNCTION(0x1, "gpio_out"), />>>/- SUNXI_FUNCTION(0x2, "nand0")), /* NDQ5 */ />>>/+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ5 */ />>>/+ SUNXI_FUNCTION(0x3, "mmc2")), /* D5 */ />>>/SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 14), />>>/SUNXI_FUNCTION(0x0, "gpio_in"), />>>/SUNXI_FUNCTION(0x1, "gpio_out"), />>>/- SUNXI_FUNCTION(0x2, "nand0")), /* NDQ6 
*/ />>>/+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ6 */ />>>/+ SUNXI_FUNCTION(0x3, "mmc2")), /* D6 */ />>>/SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 15), />>>/SUNXI_FUNCTION(0x0, "gpio_in"), />>>/SUNXI_FUNCTION(0x1, "gpio_out"), />>>/- SUNXI_FUNCTION(0x2, "nand0")), /* NDQ7 */ />>>/+ SUNXI_FUNCTION(0x2, "nand0"), /* NDQ7 */ />>>/+ SUNXI_FUNCTION(0x3, 
"mmc2")), /* D7 *//



to actually get the pin functions.


The same tests was done on legacy kernel 3.4.111 modifying fex file 
and the result is the same: 
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7265



Best regards
Chris


On Wednesday, May 4, 2016 at 4:19:20 PM UTC+3, Olliver Schinagl wrote:

Hey Christo,

On 04-05-16 15:07, Christo Radev wrote:

Hi Olliver,

I have already test it a few weeks ago and definitely can say
that 8-bit bus did not work on A20-Olinuxino-Lime2-eMMC with
mainline kernel.
See may post here

.

I saw, but you forgot to define the pins for 4.x :)

See my patch from earlier:

http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/368887.html



Olliver



Best regards

Chris

On Wednesday, May 4, 2016 at 3:52:17 PM UTC+3, Olliver Schinagl
wrote:

Hey Radoslav,

On 04-05-16 14:30, Radoslav Kolev wrote:
> 2016-05-03 10:25 GMT+03:00 Chen-Yu Tsai :
>> On Tue, May 3, 2016 at 3:21 PM, Olliver Schinagl
 wrote:
> +   bus-width = <4>;
 Only 4 bits? We normally see eMMC with 8 bits. 4 bits
are some kind of
 embedded SD card.
>>> On A20 as well? Our investigations so far have concluded
that the A10 and
>>> A20 have those pins not mapped out to pads. The IP does
support it however
>>> we assume.
>> You're right. My bad. First time A10/A20 sees eMMC support.
> I can't say anything about A10/A20, but I have a board with
A13 and
> the same eMMC chip and it works fine in 8 bit mode.
Yep, sun5i actually brings them all out to pads, the A20
however does
not :( We first thought that the A20 would also be an
8bitter, because
the mmc IP appears to be the same as sun5i, but initial tests
show it is
not. As for A10, it has older IP and it might not even
support 8 bit
mode, let alone bring out the pins.

But with A20's + eMMC being available via the lime2, others
may repeat
my experiments! The lime2 is 8 bit connected.

Olliver
>
> Regards,
> Radoslav





--
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 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Christo Radev]

Hi Oliver,

I do: that 
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7359
The syntax error seen there was fixed and the result is: 
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7361

The same tests was done on legacy kernel 3.4.111 modifying fex file and the 
result is the same: 
http://forum.armbian.com/index.php/topic/853-armbian-customization/page-2#entry7265


Best regards
Chris


On Wednesday, May 4, 2016 at 4:19:20 PM UTC+3, Olliver Schinagl wrote:
>
> Hey Christo,
>
> On 04-05-16 15:07, Christo Radev wrote:
>
> Hi Olliver,
>
> I have already test it a few weeks ago and definitely can say that 8-bit 
> bus did not work on A20-Olinuxino-Lime2-eMMC with mainline kernel.
> See may post here 
> 
> .
>
> I saw, but you forgot to define the pins for 4.x :)
>
> See my patch from earlier: 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/368887.html
>
> Olliver
>
>
> Best regards
>
> Chris
>
> On Wednesday, May 4, 2016 at 3:52:17 PM UTC+3, Olliver Schinagl wrote: 
>>
>> Hey Radoslav, 
>>
>> On 04-05-16 14:30, Radoslav Kolev wrote: 
>> > 2016-05-03 10:25 GMT+03:00 Chen-Yu Tsai : 
>> >> On Tue, May 3, 2016 at 3:21 PM, Olliver Schinagl  
>> wrote: 
>> > +   bus-width = <4>; 
>>  Only 4 bits? We normally see eMMC with 8 bits. 4 bits are some kind 
>> of 
>>  embedded SD card. 
>> >>> On A20 as well? Our investigations so far have concluded that the A10 
>> and 
>> >>> A20 have those pins not mapped out to pads. The IP does support it 
>> however 
>> >>> we assume. 
>> >> You're right. My bad. First time A10/A20 sees eMMC support. 
>> > I can't say anything about A10/A20, but I have a board with A13 and 
>> > the same eMMC chip and it works fine in 8 bit mode. 
>> Yep, sun5i actually brings them all out to pads, the A20 however does 
>> not :( We first thought that the A20 would also be an 8bitter, because 
>> the mmc IP appears to be the same as sun5i, but initial tests show it is 
>> not. As for A10, it has older IP and it might not even support 8 bit 
>> mode, let alone bring out the pins. 
>>
>> But with A20's + eMMC being available via the lime2, others may repeat 
>> my experiments! The lime2 is 8 bit connected. 
>>
>> Olliver 
>> > 
>> > Regards, 
>> > Radoslav 
>>
>>
>

-- 
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 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Olliver Schinagl]

Hey Christo,

On 04-05-16 15:07, Christo Radev wrote:

Hi Olliver,

I have already test it a few weeks ago and definitely can say that 
8-bit bus did not work on A20-Olinuxino-Lime2-eMMC with mainline kernel.
See may post here 
.

I saw, but you forgot to define the pins for 4.x :)

See my patch from earlier: 
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-September/368887.html


Olliver



Best regards

Chris

On Wednesday, May 4, 2016 at 3:52:17 PM UTC+3, Olliver Schinagl wrote:

Hey Radoslav,

On 04-05-16 14:30, Radoslav Kolev wrote:
> 2016-05-03 10:25 GMT+03:00 Chen-Yu Tsai :
>> On Tue, May 3, 2016 at 3:21 PM, Olliver Schinagl
 wrote:
> +   bus-width = <4>;
 Only 4 bits? We normally see eMMC with 8 bits. 4 bits are
some kind of
 embedded SD card.
>>> On A20 as well? Our investigations so far have concluded that
the A10 and
>>> A20 have those pins not mapped out to pads. The IP does
support it however
>>> we assume.
>> You're right. My bad. First time A10/A20 sees eMMC support.
> I can't say anything about A10/A20, but I have a board with A13 and
> the same eMMC chip and it works fine in 8 bit mode.
Yep, sun5i actually brings them all out to pads, the A20 however does
not :( We first thought that the A20 would also be an 8bitter,
because
the mmc IP appears to be the same as sun5i, but initial tests show
it is
not. As for A10, it has older IP and it might not even support 8 bit
mode, let alone bring out the pins.

But with A20's + eMMC being available via the lime2, others may
repeat
my experiments! The lime2 is 8 bit connected.

Olliver
>
> Regards,
> Radoslav



--
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] [PATCHv3] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Olliver Schinagl]

There are 3 kinds of OLinuXino Lime2 boards.
One without any on board storage, one with NAND storage and one with
eMMC storage. This patch adds the eMMC variant of boards.

eMMC storage is different from a regular SD card in that it is soldered
on the board and cannot be changed. Additionally, it shares pins with
the NAND module and with the second SPI port.

Signed-off-by: Olliver Schinagl 
---
 .../boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts| 81 ++
 1 file changed, 81 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts 
b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
new file mode 100644
index 000..9680fcb
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2-emmc.dts
@@ -0,0 +1,81 @@
+ /*
+ * Copyright 2015 - Ultimaker B.V.
+ * Author Olliver Schinagl 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#include "sun7i-a20-olinuxino-lime2.dts"
+
+/ {
+   model = "Olimex A20-OLinuXino-LIME2-eMMC";
+
+   mmc2_pwrseq: pwrseq {
+   pinctrl-0 = <_pins_nrst>;
+   pinctrl-names = "default";
+   compatible = "mmc-pwrseq-emmc";
+   reset-gpios = < 2 16 GPIO_ACTIVE_LOW>;
+   };
+};
+
+ {
+   mmc2_pins_nrst: mmc2@0 {
+   allwinner,pins = "PC16";
+   allwinner,function = "gpio_out";
+   allwinner,drive = ;
+   allwinner,pull = ;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   vmmc-supply = <_vcc3v3>;
+   vqmmc-supply = <_vcc3v3>;
+   bus-width = <4>;
+   non-removable;
+   mmc-pwrseq = <_pwrseq>;
+   status = "okay";
+
+   emmc: emmc@0 {
+   reg = <0>;
+   compatible = "mmc-card";
+   broken-hpi;
+   };
+};
-- 
2.8.1

-- 
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 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Christo Radev]

Hi Olliver,

I have already test it a few weeks ago and definitely can say that 8-bit 
bus did not work on A20-Olinuxino-Lime2-eMMC with mainline kernel.
See may post here 

.

Best regards

Chris

On Wednesday, May 4, 2016 at 3:52:17 PM UTC+3, Olliver Schinagl wrote:
>
> Hey Radoslav, 
>
> On 04-05-16 14:30, Radoslav Kolev wrote: 
> > 2016-05-03 10:25 GMT+03:00 Chen-Yu Tsai : 
> >> On Tue, May 3, 2016 at 3:21 PM, Olliver Schinagl  > wrote: 
> > +   bus-width = <4>; 
>  Only 4 bits? We normally see eMMC with 8 bits. 4 bits are some kind 
> of 
>  embedded SD card. 
> >>> On A20 as well? Our investigations so far have concluded that the A10 
> and 
> >>> A20 have those pins not mapped out to pads. The IP does support it 
> however 
> >>> we assume. 
> >> You're right. My bad. First time A10/A20 sees eMMC support. 
> > I can't say anything about A10/A20, but I have a board with A13 and 
> > the same eMMC chip and it works fine in 8 bit mode. 
> Yep, sun5i actually brings them all out to pads, the A20 however does 
> not :( We first thought that the A20 would also be an 8bitter, because 
> the mmc IP appears to be the same as sun5i, but initial tests show it is 
> not. As for A10, it has older IP and it might not even support 8 bit 
> mode, let alone bring out the pins. 
>
> But with A20's + eMMC being available via the lime2, others may repeat 
> my experiments! The lime2 is 8 bit connected. 
>
> Olliver 
> > 
> > Regards, 
> > Radoslav 
>
>

-- 
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 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Olliver Schinagl]

Hey Radoslav,

On 04-05-16 14:30, Radoslav Kolev wrote:

2016-05-03 10:25 GMT+03:00 Chen-Yu Tsai :

On Tue, May 3, 2016 at 3:21 PM, Olliver Schinagl  wrote:

+   bus-width = <4>;

Only 4 bits? We normally see eMMC with 8 bits. 4 bits are some kind of
embedded SD card.

On A20 as well? Our investigations so far have concluded that the A10 and
A20 have those pins not mapped out to pads. The IP does support it however
we assume.

You're right. My bad. First time A10/A20 sees eMMC support.

I can't say anything about A10/A20, but I have a board with A13 and
the same eMMC chip and it works fine in 8 bit mode.
Yep, sun5i actually brings them all out to pads, the A20 however does 
not :( We first thought that the A20 would also be an 8bitter, because 
the mmc IP appears to be the same as sun5i, but initial tests show it is 
not. As for A10, it has older IP and it might not even support 8 bit 
mode, let alone bring out the pins.


But with A20's + eMMC being available via the lime2, others may repeat 
my experiments! The lime2 is 8 bit connected.


Olliver


Regards,
Radoslav


--
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] musb: sunxi: Ignore VBus errors in host-only mode

[Christo Radev]

Thanks again Michal,

Proposed solution makes USB OTG to work in host only mode.
"usb0-vbus: disabling" message is gone and usb0-vbus goes hi at boot.

Unfortunately, it solves the problem on a half.
Where could be the rest of the problem - USB OTG to work as device at 
dr_mode = "otg"?

Thanks a lot and best regards
Chris

On Wednesday, May 4, 2016 at 1:26:14 PM UTC+3, Michal Suchanek wrote:
>
> On 14 September 2015 at 22:25, Maxime Ripard 
>  wrote: 
> > On Thu, Sep 10, 2015 at 08:38:38PM +0200, Hans de Goede wrote: 
> >> Hi, 
> >> 
> >> On 10-09-15 20:30, Maxime Ripard wrote: 
> >> >On Thu, Sep 10, 2015 at 08:23:23PM +0200, Hans de Goede wrote: 
> >> >>Hi, 
> >> >> 
> >> >>On 04-09-15 08:43, Olliver Schinagl wrote: 
> >> >>>Hey Hans, 
> >> >>> 
> >> >>>On 07-08-15 10:45, Olliver Schinagl wrote: 
> >>  
> >> >If you change the dr_mode to host then you _must_ also remove any 
> id_det and vbus_det 
> >> >gpio settings from the usb_phy node in the dts, as the sun4i phy 
> code detects 
> >> >host vs otg mode by checking for the presence of these. 
> >> Yes, this fixes it and makes it work. Thanks. 
> >>  
> >> >>>I've been going back to this and am wondering if this is something I 
> can look into to fix properly? E.g. if the dts sets dr_mode = host, can we 
> simply ignore the pins and treat them as unset? 
> >> >> 
> >> >>AFAIK you cannot unset something in dts. The only solution I 
> >> >>can comeup with is to add a dr_mode argument to the phy like 
> >> >>we already have for the otg controller itself. 
> >> >> 
> >> >>This is something which we likely need to do anyways to add 
> >> >>support for peripheral only mode, which we seem to need for 
> >> >>some "hdmi sticks". 
> >> > 
> >> >I haven't really followed the rest of the discussion, so sorry if you 
> >> >already talked about that, but why can't you just set the dr_mode to 
> >> >peripheral in such a case? 
> >> 
> >> This is about the usbphy code not the musb-controller code, which are 
> >> 2 different dts nodes, atm only the musb-controller node has a 
> >> dr_mode property, and the phy code decides between host-only 
> >> and otg mode based on whether an id pin is assigned or not. 
> >> 
> >> My proposal is to get rid of the id-pin hack to determine the mode 
> >> and add a dr_mode property to the usbphy dts node. 
> > 
> > I agree that we should get rid of that hack, especially since a lack 
> > of an ID pin might also be used on a peripheral-only device. 
> > 
> > However, we already have that information in the musb node, and 
> > duplicating the info seems error prone. We already have a custom 
> > function, maybe that's a case for another one, and that would allow to 
> > handle "hard" cases more easily (like CONFIG_USB_MUSB_HOST selected, 
> > with the otg node set to otg). 
> > 
>
> Hello, 
>
> was this solved somehow? 
>
> What problem is there with referencing the phy node? 
>
> Just like pinmux setting nodes and whatnot it can be named and 
> referenced by name. 
>
> Thanks 
>
> Michal 
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH] musb: sunxi: Ignore VBus errors in host-only mode

[Christo Radev]

On Wednesday, August 5, 2015 at 12:26:18 AM UTC+3, Hans de Goede wrote:
>
> For some unclear reason sometimes we get VBus errors in host-only mode, 
> even though we do not have any vbus-detection then. Ignore these. 
>
> Signed-off-by: Hans de Goede  
> --- 
>  drivers/usb/musb/sunxi.c | 4  
>  1 file changed, 4 insertions(+) 
>
> diff --git a/drivers/usb/musb/sunxi.c b/drivers/usb/musb/sunxi.c 
> index f9f6304..34ce5df 100644 
> --- a/drivers/usb/musb/sunxi.c 
> +++ b/drivers/usb/musb/sunxi.c 
> @@ -194,6 +194,10 @@ static irqreturn_t sunxi_musb_interrupt(int irq, void 
> *__hci) 
>  musb_writeb(musb->mregs, MUSB_FADDR, 0); 
>  } 
>   
> +/*  Ignore Vbus errors when in host only mode */ 
> +if (musb->port_mode == MUSB_PORT_MODE_HOST) 
> +musb->int_usb &= ~MUSB_INTR_VBUSERROR; 
> + 
>  musb->int_tx = readw(musb->mregs + SUNXI_MUSB_INTRTX); 
>  if (musb->int_tx) 
>  writew(musb->int_tx, musb->mregs + SUNXI_MUSB_INTRTX); 
> -- 
> 2.4.3 
>
>

-- 
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 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Radoslav Kolev]

2016-05-03 10:25 GMT+03:00 Chen-Yu Tsai :
> On Tue, May 3, 2016 at 3:21 PM, Olliver Schinagl  wrote:
 +   bus-width = <4>;
>>>
>>> Only 4 bits? We normally see eMMC with 8 bits. 4 bits are some kind of
>>> embedded SD card.
>>
>> On A20 as well? Our investigations so far have concluded that the A10 and
>> A20 have those pins not mapped out to pads. The IP does support it however
>> we assume.
>
> You're right. My bad. First time A10/A20 sees eMMC support.

I can't say anything about A10/A20, but I have a board with A13 and
the same eMMC chip and it works fine in 8 bit mode.

Regards,
Radoslav

-- 
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] musb: sunxi: Ignore VBus errors in host-only mode

[Christo Radev]

Thanks Michal,

I will test proposed solution and will post the results.
But in general I prefer to get full USB OTG functionality.

For the moment:
root@egpr:~# cat /boot/config-4.5.2-sunxi | grep CONFIG_USB_MUSB_HOST
# CONFIG_USB_MUSB_HOST is not set

and:

usb@01c13000 {
compatible = "allwinner,sun4i-a10-musb";
reg = <0x1c13000 0x400>;
clocks = <0x3 0x0>;
interrupts = <0x0 0x26 0x4>;
interrupt-names = "mc";
phys = <0x23 0x0>;
phy-names = "usb";
extcon = <0x23 0x0>;
allwinner,sram = <0x24 0x1>;
status = "okay";
dr_mode = "host";
};

phy@01c13400 {
#phy-cells = <0x1>;
compatible = "allwinner,sun7i-a20-usb-phy";
reg = <0x1c13400 0x10 0x1c14800 0x4 0x1c1c800 0x4>;
reg-names = "phy_ctrl", "pmu1", "pmu2";
clocks = <0x25 0x8>;
clock-names = "usb_phy";
resets = <0x25 0x0 0x25 0x1 0x25 0x2>;
reset-names = "usb0_reset", "usb1_reset", 
"usb2_reset";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <0x26 0x27>;
usb0_id_det-gpio = <0x1e 0x7 0x4 0x0>;
usb0_vbus_det-gpio = <0x1e 0x7 0x5 0x0>;
usb0_vbus-supply = <0x28>;
usb1_vbus-supply = <0x29>;
usb2_vbus-supply = <0x2a>;
linux,phandle = <0x23>;
phandle = <0x23>;
};


pinctrl@01c20800 {
...
usb0_id_detect_pin@0 {
allwinner,pins = "PH4";
allwinner,function = "gpio_in";
allwinner,drive = <0x0>;
allwinner,pull = <0x1>;
linux,phandle = <0x26>;
phandle = <0x26>;
};

usb0_vbus_detect_pin@0 {
allwinner,pins = "PH5";
allwinner,function = "gpio_in";
allwinner,drive = <0x0>;
allwinner,pull = <0x2>;
linux,phandle = <0x27>;
phandle = <0x27>;
};
};
...
usb0-vbus {
compatible = "regulator-fixed";
pinctrl-names = "default";
pinctrl-0 = <0x3d>;
regulator-name = "usb0-vbus";
regulator-min-microvolt = <0x4c4b40>;
regulator-max-microvolt = <0x4c4b40>;
enable-active-high;
gpio = <0x1e 0x2 0x11 0x0>;
status = "okay";
linux,phandle = <0x28>;
phandle = <0x28>;
};


sorry for the above code but I have used re-compiled dtb file for testing 
purposes.

Best regards
Chris

On Wednesday, May 4, 2016 at 1:26:14 PM UTC+3, Michal Suchanek wrote:
>
> On 14 September 2015 at 22:25, Maxime Ripard 
>  wrote: 
> > On Thu, Sep 10, 2015 at 08:38:38PM +0200, Hans de Goede wrote: 
> >> Hi, 
> >> 
> >> On 10-09-15 20:30, Maxime Ripard wrote: 
> >> >On Thu, Sep 10, 2015 at 08:23:23PM +0200, Hans de Goede wrote: 
> >> >>Hi, 
> >> >> 
> >> >>On 04-09-15 08:43, Olliver Schinagl wrote: 
> >> >>>Hey Hans, 
> >> >>> 
> >> >>>On 07-08-15 10:45, Olliver Schinagl wrote: 
> >>  
> >> >If you change the dr_mode to host then you _must_ also remove any 
> id_det and vbus_det 
> >> >gpio settings from the usb_phy node in the dts, as the sun4i phy 
> code detects 
> >> >host vs otg mode by checking for the presence of these. 
> >> Yes, this fixes it and makes it work. Thanks. 
> >>  
> >> >>>I've been going back to this and am wondering if this is something I 
> can look into to fix properly? E.g. if the dts sets dr_mode = host, can we 
> simply ignore the pins and treat them as unset? 
> >> >> 
> >> >>AFAIK you cannot unset something in dts. The only solution I 
> >> >>can comeup with is to add a dr_mode argument to the phy like 
> >> >>we already have for the otg controller itself. 
> >> >> 
> >> >>This is something which we likely need to do anyways to add 
> >> >>support for peripheral only mode, which we seem to need for 
> >> >>some "hdmi sticks". 
> >> > 
> >> >I haven't really followed the rest of the discussion, so sorry if you 
> >> >already talked about that, but why can't you just set the dr_mode to 
> >> 

Re: [linux-sunxi] USB OTG on A20 Lime2 board does not work with mainline kernel

[Christo Radev]

Thanks CodeKipper,

Yes, all the are ok:
root@egpr:~# cat /boot/config-4.5.2-sunxi | grep CONFIG_USB_MUSB_HDRC
CONFIG_USB_MUSB_HDRC=y
root@egpr:~# cat /boot/config-4.5.2-sunxi | grep CONFIG_USB_MUSB_SUNXI
CONFIG_USB_MUSB_SUNXI=y
root@egpr:~# CONFIG_NOP_USB_XCEIV^C
root@egpr:~# cat /boot/config-4.5.2-sunxi | grep CONFIG_NOP_USB_XCEIV
CONFIG_NOP_USB_XCEIV=y
root@egpr:~# cat /boot/config-4.5.2-sunxi | grep CONFIG_USB_GADGET
CONFIG_USB_GADGET=y
# CONFIG_USB_GADGET_DEBUG is not set
# CONFIG_USB_GADGET_DEBUG_FILES is not set
# CONFIG_USB_GADGET_DEBUG_FS is not set
CONFIG_USB_GADGET_VBUS_DRAW=200
CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS=2
# CONFIG_USB_GADGET_XILINX is not set
CONFIG_USB_GADGETFS=m
# CONFIG_USB_GADGET_TARGET is not set
In Armbian build scripts is used linux-sunxi-next.config as kernel config 
and the only change done by me in testing process is to add.
CONFIG_USB_GPIO_VBUS=y
which was not set by default but did not help.

Best regards
Chris

On Wednesday, May 4, 2016 at 1:48:40 PM UTC+3, CodeKipper wrote:
>
> On 4 May 2016 at 11:44, Christo Radev  
> wrote: 
> > Hi to All, 
> > 
> > 
> > I am trying to use USB OTG on A20-Olinuxino-Lime2-eMMC with own build of 
> > Armbian 5.11, U-Boot 2016.05--rec1, mainline kernel 4.5.2 and Debian 
> Jessie 
> > without success. I have tested: 
>
> I don't think Wens changes for OTG is in 4.5.2. 
> The following should be in arch/arm/configs/sunxi_defconfig 
>
> CONFIG_USB_MUSB_HDRC=y 
> CONFIG_USB_MUSB_SUNXI=y 
> CONFIG_NOP_USB_XCEIV=y 
> CONFIG_USB_GADGET=y 
>
> They're in linux-next, 
>
> CK 
>
> > 
> > both 'host' and 'otg' types for dr_mode in device tree; 
> > connect USB OTG to other board's USB Host; 
> > attach USB mass storage and other devices; 
> > attach other self powered devices; 
> > try to load modules like extcon_gpio, extcon_usb_gpio, u_serial, 
> u_ether; 
> > rebuild kernel with CONFIG_USB_GPIO_VBUS=y and many others without any 
> > success. 
> > 
> > I have verified the HW is working fine as 'host' and 'device' with 
> latest 
> > Olimex image with Debian Jessie and kermel 3.4.103. 
> > 
> > Some time ago I have also tested it to work with Armbian 5.07 and kernel 
> > 3.4.111 (with modified fex file). 
> > 
> > I have also verify that device tree seams to be o.k. according to posts 
> in 
> > this forum. 
> > 
> > 
> > In the boot messages USB OTG is recognized by sunxi musb driver but 
> > usb0-vbus is finally disabled. 
> > 
> > There are few confusing messages as well: 
> > 
> > 
> > [3.254996] reg-fixed-voltage usb0-vbus: could not find pctldev for 
> node 
> > /soc@01c0/pinctrl@01c20800 usb0_vbus_pin@0, deferring probe 
> > [3.255033] reg-fixed-voltage usb1-vbus: could not find pctldev for 
> node 
> > /soc@01c0/pinctrl@01c20800/usb1_vbus_pin@0, deferring probe 
> > [3.255067] reg-fixed-voltage usb2-vbus: could not find pctldev for 
> node 
> > /soc@01c0/pinctrl@01c20800/usb2_vbus_pin@0, deferring probe 
> > [3.257948] usbcore: registered new interface driver usbfs 
> > [3.258023] usbcore: registered new interface driver hub 
> > [3.258127] usbcore: registered new device driver usb 
> > [3.369469] sun4i-usb-phy 1c13400.phy: could not find pctldev for 
> node 
> > /soc@01c0/pinctrl@01c20800/usb0_id_detect_pin@0, deferring probe 
> > 
> > 
> > ... 
> > 
> > 
> > [3.846532] usb_phy_generic.0.auto supply vcc not found, using dummy 
> > regulator 
> > [3.847087] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver 
> > [3.847109] musb-hdrc musb-hdrc.1.auto: new USB bus registered, 
> assigned 
> > bus number 5 
> > [3.847554] usb usb5: New USB device found, idVendor=1d6b, 
> idProduct=0002 
> > [3.847569] usb usb5: New USB device strings: Mfr=3, Product=2, 
> > SerialNumber=1 
> > [3.847579] usb usb5: Product: MUSB HDRC host driver 
> > [3.847588] usb usb5: Manufacturer: Linux 4.5.2-sunxi musb-hcd 
> > [3.847598] usb usb5: SerialNumber: musb-hdrc.1.auto 
> > [3.848439] hub 5-0:1.0: USB hub found 
> > [3.848513] hub 5-0:1.0: 1 port detected 
> > [3.877070] usb0-vbus: disabling 
> > 
> > 
> > I have also verified usb0_id_det and usb0_vbus_det wotk fine as inputs 
> (cat 
> > /sys/kernel/debug/gpio) 
> > 
> > GPIOs 0-287, platform/1c20800.pinctrl, 1c20800.pinctrl: 
> >  gpio-50  (|sysfs   ) in  hi 
> >  gpio-67  (|ahci-5v ) out hi 
> >  gpio-81  (|usb0-vbus   ) out lo 
> >  gpio-87  (|sysfs   ) out lo 
> >  gpio-88  (|sysfs   ) out hi 
> >  gpio-225 (|cd  ) in  hi IRQ 
> >  gpio-226 (|?   ) out hi 
> >  gpio-227 (|usb2-vbus   ) out hi 
> >  gpio-228 (|usb0_id_det ) in  hi IRQ 
> >  gpio-229 (|usb0_vbus_det   ) in  lo IRQ 
> >  gpio-230 (  

Re: [linux-sunxi] USB OTG on A20 Lime2 board does not work with mainline kernel

[Code Kipper]

On 4 May 2016 at 11:44, Christo Radev  wrote:
> Hi to All,
>
>
> I am trying to use USB OTG on A20-Olinuxino-Lime2-eMMC with own build of
> Armbian 5.11, U-Boot 2016.05--rec1, mainline kernel 4.5.2 and Debian Jessie
> without success. I have tested:

I don't think Wens changes for OTG is in 4.5.2.
The following should be in arch/arm/configs/sunxi_defconfig

CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_MUSB_SUNXI=y
CONFIG_NOP_USB_XCEIV=y
CONFIG_USB_GADGET=y

They're in linux-next,

CK

>
> both 'host' and 'otg' types for dr_mode in device tree;
> connect USB OTG to other board's USB Host;
> attach USB mass storage and other devices;
> attach other self powered devices;
> try to load modules like extcon_gpio, extcon_usb_gpio, u_serial, u_ether;
> rebuild kernel with CONFIG_USB_GPIO_VBUS=y and many others without any
> success.
>
> I have verified the HW is working fine as 'host' and 'device' with latest
> Olimex image with Debian Jessie and kermel 3.4.103.
>
> Some time ago I have also tested it to work with Armbian 5.07 and kernel
> 3.4.111 (with modified fex file).
>
> I have also verify that device tree seams to be o.k. according to posts in
> this forum.
>
>
> In the boot messages USB OTG is recognized by sunxi musb driver but
> usb0-vbus is finally disabled.
>
> There are few confusing messages as well:
>
>
> [3.254996] reg-fixed-voltage usb0-vbus: could not find pctldev for node
> /soc@01c0/pinctrl@01c20800 usb0_vbus_pin@0, deferring probe
> [3.255033] reg-fixed-voltage usb1-vbus: could not find pctldev for node
> /soc@01c0/pinctrl@01c20800/usb1_vbus_pin@0, deferring probe
> [3.255067] reg-fixed-voltage usb2-vbus: could not find pctldev for node
> /soc@01c0/pinctrl@01c20800/usb2_vbus_pin@0, deferring probe
> [3.257948] usbcore: registered new interface driver usbfs
> [3.258023] usbcore: registered new interface driver hub
> [3.258127] usbcore: registered new device driver usb
> [3.369469] sun4i-usb-phy 1c13400.phy: could not find pctldev for node
> /soc@01c0/pinctrl@01c20800/usb0_id_detect_pin@0, deferring probe
>
>
> ...
>
>
> [3.846532] usb_phy_generic.0.auto supply vcc not found, using dummy
> regulator
> [3.847087] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
> [3.847109] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned
> bus number 5
> [3.847554] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002
> [3.847569] usb usb5: New USB device strings: Mfr=3, Product=2,
> SerialNumber=1
> [3.847579] usb usb5: Product: MUSB HDRC host driver
> [3.847588] usb usb5: Manufacturer: Linux 4.5.2-sunxi musb-hcd
> [3.847598] usb usb5: SerialNumber: musb-hdrc.1.auto
> [3.848439] hub 5-0:1.0: USB hub found
> [3.848513] hub 5-0:1.0: 1 port detected
> [3.877070] usb0-vbus: disabling
>
>
> I have also verified usb0_id_det and usb0_vbus_det wotk fine as inputs (cat
> /sys/kernel/debug/gpio)
>
> GPIOs 0-287, platform/1c20800.pinctrl, 1c20800.pinctrl:
>  gpio-50  (|sysfs   ) in  hi
>  gpio-67  (|ahci-5v ) out hi
>  gpio-81  (|usb0-vbus   ) out lo
>  gpio-87  (|sysfs   ) out lo
>  gpio-88  (|sysfs   ) out hi
>  gpio-225 (|cd  ) in  hi IRQ
>  gpio-226 (|?   ) out hi
>  gpio-227 (|usb2-vbus   ) out hi
>  gpio-228 (|usb0_id_det ) in  hi IRQ
>  gpio-229 (|usb0_vbus_det   ) in  lo IRQ
>  gpio-230 (|usb1-vbus   ) out hi
> but usb0-vbus is always low and the USB OTG behaves like a dead.
>
> The only reaction was when USB OTG with dr_mode = 'host' was connected (by
> error) to other board USB Host.
>
> In this situation USB OTG enumeration try was registered at both sides but
> finished with error (probably because of support lack).
>
>
> Please, help me to find a solution.
>
>
> Best regards
>
> Chris
>
>
> --
> 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.

-- 
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] musb: sunxi: Ignore VBus errors in host-only mode

[Michal Suchanek]

On 14 September 2015 at 22:25, Maxime Ripard
 wrote:
> On Thu, Sep 10, 2015 at 08:38:38PM +0200, Hans de Goede wrote:
>> Hi,
>>
>> On 10-09-15 20:30, Maxime Ripard wrote:
>> >On Thu, Sep 10, 2015 at 08:23:23PM +0200, Hans de Goede wrote:
>> >>Hi,
>> >>
>> >>On 04-09-15 08:43, Olliver Schinagl wrote:
>> >>>Hey Hans,
>> >>>
>> >>>On 07-08-15 10:45, Olliver Schinagl wrote:
>> 
>> >If you change the dr_mode to host then you _must_ also remove any 
>> >id_det and vbus_det
>> >gpio settings from the usb_phy node in the dts, as the sun4i phy code 
>> >detects
>> >host vs otg mode by checking for the presence of these.
>> Yes, this fixes it and makes it work. Thanks.
>> 
>> >>>I've been going back to this and am wondering if this is something I can 
>> >>>look into to fix properly? E.g. if the dts sets dr_mode = host, can we 
>> >>>simply ignore the pins and treat them as unset?
>> >>
>> >>AFAIK you cannot unset something in dts. The only solution I
>> >>can comeup with is to add a dr_mode argument to the phy like
>> >>we already have for the otg controller itself.
>> >>
>> >>This is something which we likely need to do anyways to add
>> >>support for peripheral only mode, which we seem to need for
>> >>some "hdmi sticks".
>> >
>> >I haven't really followed the rest of the discussion, so sorry if you
>> >already talked about that, but why can't you just set the dr_mode to
>> >peripheral in such a case?
>>
>> This is about the usbphy code not the musb-controller code, which are
>> 2 different dts nodes, atm only the musb-controller node has a
>> dr_mode property, and the phy code decides between host-only
>> and otg mode based on whether an id pin is assigned or not.
>>
>> My proposal is to get rid of the id-pin hack to determine the mode
>> and add a dr_mode property to the usbphy dts node.
>
> I agree that we should get rid of that hack, especially since a lack
> of an ID pin might also be used on a peripheral-only device.
>
> However, we already have that information in the musb node, and
> duplicating the info seems error prone. We already have a custom
> function, maybe that's a case for another one, and that would allow to
> handle "hard" cases more easily (like CONFIG_USB_MUSB_HOST selected,
> with the otg node set to otg).
>

Hello,

was this solved somehow?

What problem is there with referencing the phy node?

Just like pinmux setting nodes and whatnot it can be named and
referenced by name.

Thanks

Michal

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH] musb: sunxi: Ignore VBus errors in host-only mode

[Christo Radev]

Hi to All,


Sorry, for posting on this old thread but I am new here and do not know how 
to address other people's attention to help me.


I have just open a new thread about my problem to use USB OTG on 
A20-Olinuxino-Lime2-eMMC with mainline kernel 4.5.2 
.


Please, help me to solve my problem.


Best regards

Chris


-- 
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] USB OTG on A20 Lime2 board does not work with mainline kernel

[Christo Radev]

 

Hi to All,


I am trying to use USB OTG on A20-Olinuxino-Lime2-eMMC with own build of 
Armbian 5.11, U-Boot 2016.05--rec1, mainline kernel 4.5.2 and Debian Jessie 
without success. I have tested: 

   - both 'host' and 'otg' types for dr_mode in device tree;
   - connect USB OTG to other board's USB Host;
   - attach USB mass storage and other devices;
   - attach other self powered devices;
   - try to load modules like extcon_gpio, extcon_usb_gpio, u_serial, 
   u_ether;
   - rebuild kernel with CONFIG_USB_GPIO_VBUS=y and many others without any 
   success.

I have verified the HW is working fine as 'host' and 'device' with latest 
Olimex image with Debian Jessie and kermel 3.4.103. 

Some time ago I have also tested it to work with Armbian 5.07 and kernel 
3.4.111 (with modified fex file). 

I have also verify that device tree seams to be o.k. according to posts in 
this forum.


In the boot messages USB OTG is recognized by sunxi musb driver but 
usb0-vbus is finally disabled. 

There are few confusing messages as well:


[3.254996] reg-fixed-voltage usb0-vbus: could not find pctldev for node 
/soc@01c0/pinctrl@01c20800 usb0_vbus_pin@0, deferring probe
[3.255033] reg-fixed-voltage usb1-vbus: could not find pctldev for node 
/soc@01c0/pinctrl@01c20800/usb1_vbus_pin@0, deferring probe
[3.255067] reg-fixed-voltage usb2-vbus: could not find pctldev for node 
/soc@01c0/pinctrl@01c20800/usb2_vbus_pin@0, deferring probe
[3.257948] usbcore: registered new interface driver usbfs
[3.258023] usbcore: registered new interface driver hub
[3.258127] usbcore: registered new device driver usb
[3.369469] sun4i-usb-phy 1c13400.phy: could not find pctldev for node /
soc@01c0/pinctrl@01c20800/usb0_id_detect_pin@0, deferring probe

...

[3.846532] usb_phy_generic.0.auto supply vcc not found, using dummy 
regulator
[3.847087] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver
[3.847109] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned 
bus number 5
[3.847554] usb usb5: New USB device found, idVendor=1d6b, idProduct=0002
[3.847569] usb usb5: New USB device strings: Mfr=3, Product=2, 
SerialNumber=1
[3.847579] usb usb5: Product: MUSB HDRC host driver
[3.847588] usb usb5: Manufacturer: Linux 4.5.2-sunxi musb-hcd
[3.847598] usb usb5: SerialNumber: musb-hdrc.1.auto
[3.848439] hub 5-0:1.0: USB hub found
[3.848513] hub 5-0:1.0: 1 port detected
[3.877070] usb0-vbus: disabling


I have also verified usb0_id_det and usb0_vbus_det wotk fine as inputs (cat 
/sys/kernel/debug/gpio)

GPIOs 0-287, platform/1c20800.pinctrl, 1c20800.pinctrl:
 gpio-50  (|sysfs   ) in  hi
 gpio-67  (|ahci-5v ) out hi
 gpio-81  (|usb0-vbus   ) out lo
 gpio-87  (|sysfs   ) out lo
 gpio-88  (|sysfs   ) out hi
 gpio-225 (|cd  ) in  hi IRQ
 gpio-226 (|?   ) out hi
 gpio-227 (|usb2-vbus   ) out hi
 gpio-228 (|usb0_id_det ) in  hi IRQ
 gpio-229 (|usb0_vbus_det   ) in  lo IRQ
 gpio-230 (|usb1-vbus   ) out hi
but usb0-vbus is always low and the USB OTG behaves like a dead.

The only reaction was when USB OTG with dr_mode = 'host' was connected (by 
error) to other board USB Host.

In this situation USB OTG enumeration try was registered at both sides but 
finished with error (probably because of support lack).


Please, help me to find a solution.


Best regards

Chris


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH 1/1] ARM: dts: sunxi: Add a olinuxino-lime2-emmc

[Christo Radev]

Exactly, the site is finally updated.

On Wednesday, May 4, 2016 at 8:13:05 AM UTC+3, Priit Laes wrote:
>
> On Tue, 2016-05-03 at 17:52 +0200, Olliver Schinagl wrote: 
> > Hey all, 
> > 
> > On 03-05-16 17:02, christ...@gmail.com  wrote: 
> > > On Tuesday, May 3, 2016 at 4:14:41 PM UTC+3, Maxime Ripard wrote: 
> > > > Hi, 
> > > > 
> > > > On Tue, May 03, 2016 at 4:12:06 PM UTC+3, Christo Radev wrote: 
> > > > > Hi to All, 
> > > > > 
> > > > > I have already solved and tested this issue on Armbian build. 
> > > > >  Find 
> > > > > patches for both legacy (3.4.111) and mainline (4.5.2) kernels 
> > > > > on: 
> > > > > http://forum.armbian.com/index.php/topic/853-armbian-customizat 
> > > > > ion/page-2#entry7494 
> > > > > There it is also described how to do eMMC bootable and much 
> > > > > more. 
> > > > > 
> > > > > About the board - Olimex already sold all 3 kinds after 
> > > > > migration to 
> > > > > their HW rev. E. One have to specify Lime2-eMMC as 
> > > > > A20-Olinuxino-Lime2-eMMC instead of their old 2 options 
> > > > > A20-Olinuxino-Lime2(-4GB). 
> > > > Interesting, you have a link to that device? 
>
> I guess, it is this one: 
>
> https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-LIME2-eMMC/ 
> open-source-hardware 
> 
>  
>
> > > > 
> > > > Thanks, 
> > > > Maxime 
> > > > 
> > > > -- 
> > > > Maxime Ripard, Free Electrons 
> > > > Embedded Linux, Kernel and Android engineering 
> > > > http://free-electrons.com 
> > > I have really 2 boards delivered by their local distributor. 
> > > 
> > > Unfortunately, they do not update their site. Use the link for NAND 
> > > option: 
> > > https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXIno-LIME2-4 
> > > GB/open-source-hardware 
> > > There you can find Users Manual where it is described that eMMC 
> > > option is available from HW rev. D. The schematic for HW rev. E is 
> > > also available on their repository: 
> > > https://github.com/OLIMEX/OLINUXINO/tree/master/HARDWARE/A20-OLinuX 
> > > ino-LIME2 
> > > 
> > > On the board both 4GB NAND and eMMC Flash chips can be placed 
> > > alternatively on the same place. There is difference in some other 
> > > components as well. 
> > > 
> > > If one want to order it from the site probably has to order A20 
> > > -Olinuxino-Lime2-4GB with note that eMMC option is required. The 
> > > price is the same. 
> > Sorry for the late reply, but yeah the board exists, we asked Olimex 
> > to 
> > develop the eMMC variant for us. I currently have a dozen or so on my 
> > desk :) 
> > 
> > I don't know when Olimex will update their webshop with the new 
> > designs, 
> > but they simply might not have enough eMMC chips available yet? 
> > 
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: [PATCH 2/2] ARM: dts: sunxi: Add pll3 and pll7 clock to sun[47]i.dtsi

[Luc Verhaegen]

On Wed, May 04, 2016 at 09:55:47AM +0200, Alexander Syring wrote:
> 
> 
> 
> 
> -- 

I think i should've marked this one as spam instead. My mistake, sorry.

Alexander: plain text emails, like sane people.

Luc Verhaegen.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH 2/2] ARM: dts: sunxi: Add pll3 and pll7 clock to sun[47]i.dtsi

[Alexander Syring]

 Hi Priit,I found two typos in your sun7i-a20.dtsi patch.>‎ Enable pll3 and pll7 clocks that are needed by display clocks.>--- > arch/arm/boot/dts/sun7i-a20.dtsi | 41 > ‎> 1 file changed, 41 insertions(+) ‎>>diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi >b/arch/arm/boot/dts/sun7i-a20.dtsi >index bf5d056..2688512 100644 >--- a/arch/arm/boot/dts/sun7i-a20.dtsi >+++ b/arch/arm/boot/dts/sun7i-a20.dtsi ‎>@@ -187,6 +187,15 @@ ‎>                         clock-output-names = "osc24M"; >                 }; >  ‎>+osc3M: osc3M_clk { >+#clock-cells = <0>; >+compatible = "fixed-factor-clock"; >+clock-div = <8>; >+clock-mult = <1>; >+clocks = <>; >+clock-output-names = "osc3M"; >+}; >+‎ >                 osc32k: clk@0 { >                         #clock-cells = <0>; >                         compatible = "fixed-clock"; >@@ -211,6 +220,22 @@ >                                  "pll2-4x", "pll2-8x"; ‎>                 }; >  >+pll3: clk@01c20010 { >+#clock-cells = <0>; >+compatible = "allwinner,sun4i-a10-pll3-clk"; >+reg = <0x01c20010 0x4>; >+clock = <>; ‎I think it should be clocks with a s.>+clock-output-names = "pll3"; ‎>+}; >+ >+pll3x2: pll3x2_clk { >+#clock-cells = <0>; ‎>+compatible = "fixed-factor-clock"; >+clock-div = <1>; >+clock-mult = <2>; >+clock-output-names = "pll3-2x"; >+}; >+‎ >                 pll4: clk@01c20018 { >                         #clock-cells = <0>; >                         compatible = "allwinner,sun7i-a20-pll4-clk"; >@@ -236,6 +261,22 @@ >                                  "pll6_div_4"; >                 }; >  ‎>+pll7: clk@01c20030 { >+#clock-cells = <0>; >+compatible = "allwinner,sun4i-a10-pll3-clk"; >+reg = <0x01c20030 0x4>; >+clock = <>; ‎And here a s too.>+clock-output-names = "pll7"; >+}; ‎>+ >+pll7x2: pll7x2_clk { >+#clock-cells = <0>; >+compatible = "fixed-factor-clock"; >+clock-div = <1>; >+clock-mult = <2>; >+clock-output-names = "pll7-2x"; >+}; >+ >                 pll8: clk@01c20040 { >                         #clock-cells = <0>; >                         compatible = "allwinner,sun7i-a20-pll4-clk"; >-- ‎>2.8.1 BestAlex



-- 
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] Does anyone have interest in porting allwinner cedarx decoder to vlc player？

[Mehmet Kurnaz]

Hello Wills,

I want to use your cedar plugin on android. I got a few problems. On of 
them BLOCK_FLAG_END_OF_STREAM, there is no define in include/vlc_block.h. 
Another problem is cedarfb. Can I use cedar with XCB?

Best regards
Mehmet

27 Ekim 2012 Cumartesi 07:54:42 UTC+3 tarihinde Wills Wang yazdı:
>
> I want to push it into github.
> I hope more people will join the development.
>
> BTW, how to post message into arm-n...@lists.phcomp.co.uk ?
> My mail seems to be filtered out.
>
> 在 2012年10月26日星期五UTC+8下午8时26分32秒，npeacock写道：
>>
>> I am very interested.  Do you have the code posted somewhere?
>> On Oct 26, 2012 6:03 AM, "wills"  wrote:
>>
>>> Hi, All,
>>>
>>> I am porting allwinner cedarx decoder to native vlc player(direct render 
>>> to linuxfb, not android version), does anyone have interest in it?
>>> This porting based on libcedarx(a wrapper library used libvecore, 
>>> instead of libcedarv, lower level API than libcedarv).
>>>
>>> Best Regards
>>> WIlls
>>>
>>> -- 
>>>  
>>>  
>>>
>>

-- 
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] Chipone icn85xx TS polling driver

[sergk . admin]

Hi, 
Sorry for brief answer - built in did not work for me.
As minimum in case of Chuwi Vi10 icn8528 you should load firmware with all 
related to this stuff + irq mode is still under development, under standard 
things irg/gpio was not getted automatically and there is no enough info at 
the moment to use irq mode.
Regarding whether communication part are the same - I do not compare, from 
the 1st look - looks different, not sure, have no time at the moment to 
compare.
Regards,  
Serge.

On Wednesday, May 4, 2016 at 4:26:02 AM UTC, Priit Laes wrote:
>
> On Tue, 2016-05-03 at 14:30 -0700, sergk...@gmail.com  
> wrote: 
> > Hi all, 
> > ;-) At least I am releasing my icn85xx (tested on icn8528 on Chuvi 
> > Vi10, Baytrail) kernel space driver. 
> > It is unfortunately polling mode, but at the moment I am happy with 
> > it and have no enough time to dig in with irq mode. 
> > https://gitlab.com/SergK/icn85xx/tree/master 
>
>
> Are there any protocol differences between 8318 (already present in 
> mainline kernel) and 85xx? 
>
> > My special thanks for their helpto: 
> > Gregor Riepl 
> > Mika Westerberg 
> > linux-input 
> > 
> > Kind regards, 
> >Serge Kolotylo. 
> > -- 
> > 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...@googlegroups.com . 
> > For more options, visit https://groups.google.com/d/optout. 
>

-- 
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.