[linux-sunxi] Re: Updated os for Cubieboard 2

['Stefan Monnier' via linux-sunxi]

> I tried and failed with Fedora, see 
> https://ask.fedoraproject.org/t/install-fedora-in-a-cubieboard-2/18633 , 
> but I'm having problems because it doesn't boot.

AFAIK, CB2 is fully supported by vanilla kernels (except for the onboard
flash, I think), so there should be no problem booting any of the
distributions that support armhf, assuming you boot via SATA or SD card.
So please give details about "it doesn't boot", including how you try
to boot it.


Stefan

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/jwvv908h16v.fsf-monnier%2Bgmane.comp.hardware.netbook.arm.sunxi%40gnu.org.

[linux-sunxi] Re: [PATCH v10 00/15] Add Allwinner H3/H5/H6/A64 HDMI audio

[Stefan Monnier]

>> Yay!
> Note that this doesn't bring HDMI audio card just yet. Another driver will be
> needed for that.

That's what I suspected, but thanks for clarifying.

>> Now, I wonder: will that make it easier to add support for HDMI-Audio for
>> the A10/A20?
> No, A10/A20 HDMI audio uses completely different interface.

Oh, well!

> IIUC original author left Olimex, so work stalled.

Aha, so that's what happened.
I wish I had the energy to take his patch and adapt it.


Stefan

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/jwvft5v8i9b.fsf-monnier%2Bgmane.comp.hardware.netbook.arm.sunxi%40gnu.org.

[linux-sunxi] Re: [PATCH v10 00/15] Add Allwinner H3/H5/H6/A64 HDMI audio

[Stefan Monnier]

>> This series add H6 I2S support and the I2S node missing to support
>> HDMI audio in different Allwinner SoC.
> Applied to
>https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-next

Yay!

Now, I wonder: will that make it easier to add support for HDMI-Audio for
the A10/A20?

(there was a patch for that submitted earlier this year by Stefan
Mavrodiev , but it seems there hasn't been any
progress on it since then (I think the last message on it concluded that
it should be rewritten to use ALSA instead of ASoC)).

[ To clarify, don't know what's the difference between ALSA and ASoC;
  I'm only interested here as an owner of an A20 box on which I'd
  love to be able to use the HDMI-Audio.  ]


-- Stefan

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/jwv361va1g9.fsf-monnier%2Bgmane.comp.hardware.netbook.arm.sunxi%40gnu.org.

[linux-sunxi] Re: Odd "jump" when playing music on A10 and A20

[Stefan Monnier]

Stefan Monnier [2020-08-31 15:51:21] wrote:
> Stefan Monnier [2020-08-21 13:18:33] wrote:
>> Enable the display pipeline and HDMI output.
> Hmm... it turns out this patch (appended below) introduces artifacts to
> the audio output on my Mele A1000.

Side note: I can avoid those artefacts if I blacklist the `sun4i-drm` module.


Stefan

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/jwvimcxqxkw.fsf-monnier%2Bgmane.comp.hardware.netbook.arm.sunxi%40gnu.org.

[linux-sunxi] Odd "jump" when playing music on A10 and A20

[Stefan Monnier]

Stefan Monnier [2020-08-21 13:18:33] wrote:
> Enable the display pipeline and HDMI output.

Hmm... it turns out this patch (appended below) introduces artifacts to
the audio output on my Mele A1000.

It's the same artifacts that I had encountered two years ago on my
Orange Pi mini which were also triggered by adding the HDMI and display
engine nodes to the DTS.

So the problem I had assumed was specific to the Orange Pi mini seems to
be a lot more widespread and might affect many more machines.

For the record, here's the description I had posted back then, it
describes exactly the symptoms I see now (except it's on a Mele A1000):

I've been using an Orange Pi mini for a while now as home server,
including playing the role of jukebox (via MPD).

Recently this isn't working well any more: every 10s or so the music
"jumps" for a fraction of a second.  If I try to use `ogg123`
instead of `mpd`, I also get artifacts every 10s or so (tho it
sounds more like loud scratches in that case).

They occur regularly (every 10s, as mentioned) but they don't occur
at the same place in the music every time (e.g. if I start `ogg123`
the first scratch may occur after 4 second, and if I kill the
process and restart, the first scratch will occur after a different
amount of time).

The effect is heard on the "plain audio" output, which in the case of
the Mele A100 comes out on left/right RCA/cinch connectors (on the
Orange Pi mini it was on a 2.5mm headphone jack).

I don't have any device with which to test whether the HDMI audio output
is also affected.


Stefan


> Signed-off-by: Stefan Monnier 
> ---
>  arch/arm/boot/dts/sun4i-a10-a1000.dts | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts 
> b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> index 8692b11a83c3..af8ab736fd3c 100644
> --- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> @@ -60,6 +60,17 @@
>   stdout-path = "serial0:115200n8";
>   };
>  
> + hdmi-connector {
> + compatible = "hdmi-connector";
> + type = "a";
> +
> + port {
> + hdmi_con_in: endpoint {
> + remote-endpoint = <_out_con>;
> + };
> + };
> + };
> +
>   leds {
>   compatible = "gpio-leds";
>  
> @@ -133,6 +144,20 @@
>   status = "okay";
>  };
>  
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> +_out {
> + hdmi_out_con: endpoint {
> + remote-endpoint = <_con_in>;
> + };
> +};
> +
>   {
>   status = "okay";

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/jwvy2lutxgp.fsf-monnier%2Bgmane.comp.hardware.netbook.arm.sunxi%40gnu.org.

[linux-sunxi] [PATCH] ARM: dts: sun4i: Enable HDMI support on the Mele A1000

[Stefan Monnier]

Enable the display pipeline and HDMI output.

Signed-off-by: Stefan Monnier 
---
 arch/arm/boot/dts/sun4i-a10-a1000.dts | 25 +
 1 file changed, 25 insertions(+)

diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts 
b/arch/arm/boot/dts/sun4i-a10-a1000.dts
index 8692b11a83c3..af8ab736fd3c 100644
--- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
+++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
@@ -60,6 +60,17 @@
stdout-path = "serial0:115200n8";
};
 
+   hdmi-connector {
+   compatible = "hdmi-connector";
+   type = "a";
+
+   port {
+   hdmi_con_in: endpoint {
+   remote-endpoint = <_out_con>;
+   };
+   };
+   };
+
leds {
compatible = "gpio-leds";
 
@@ -133,6 +144,20 @@
status = "okay";
 };
 
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+_out {
+   hdmi_out_con: endpoint {
+   remote-endpoint = <_con_in>;
+   };
+};
+
  {
status = "okay";
 
-- 
2.20.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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/20200821171833.28177-1-monnier%40iro.umontreal.ca.

[linux-sunxi] Help bringing up a new A10s board

[Stefan Monnier]

Still not having any success with my reko-smartbox.

I compared my config files (the DTS and the file in `configs`) with
those of the other A10s boards supported, and consulted my fex file to
try and figure out which pins should be used where.

I have now a file which seems reasonable to me (given my limited
understanding of what's going on), but I still get nothing.
More specifically, here's what I do:

- make A10s-reko-smartbox_defconfig
- make
- dd bs=1024 seek=8 /dev/sdc
- put the 猶D card into the slot
- plug the power

At that point what happens is:

- The (sole) led goes red
- Nothing else.  Most importantly, nothing shows up on the screen over HDMI.

The machine does work: I can boot into its Android image stored on the
NAND flash if I plug the power without any SD card (or with an SD card
without the U-Boot cookie).

See below the patch I'm currently using (which includes the FEX file
for reference).  I tried it with U-Boot's `master` as well as with the
`v2018.11` version (the last one where I don't get a warning about
CONFIG_DM_VIDEO during the build) with the same result.

Any hint about what might prevent me from seeing a boot message on my
screen would be greatly appreciated.


Stefan


diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index d36447d18d..24b66ec78d 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -284,6 +284,7 @@ dtb-$(CONFIG_MACH_SUN5I) += \
sun5i-a10s-mk802.dtb \
sun5i-a10s-olinuxino-micro.dtb \
sun5i-a10s-r7-tv-dongle.dtb \
+sun5i-a10s-reko-smartbox.dtb \
sun5i-a10s-wobo-i5.dtb \
sun5i-a13-ampe-a76.dtb \
sun5i-a13-difrnce-dit4350.dtb \
diff --git a/arch/arm/dts/sun5i-a10s-reko-smartbox.dts 
b/arch/arm/dts/sun5i-a10s-reko-smartbox.dts
new file mode 100644
index 00..68112a61ee
--- /dev/null
+++ b/arch/arm/dts/sun5i-a10s-reko-smartbox.dts
@@ -0,0 +1,995 @@
+/*
+ * Copyright 2014 Hans de Goede 
+ *
+ * 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.
+ */
+
+/* This for a box that was sold as "Reko mk801", but the device itself is
+ * marked "Reko" and "Smartbox".  It uses the same form factor as the
+ * "mini-X".  It has an HDMI plug, a 2.5mm jack for line-out, another 2.5mm
+ * jack apparently for composite video, a normal USB-A, another USB-A
+ * labeled as OTG, and a 猶D slot between the two.
+ * The chips I found inside are:
+ * - A10s SoC.
+ * - AXP152 PMU.
+ * - RTL8189es wifi chip.
+ * - 4x Elixir DRAM chips with markings: 1320  N2cb2g80gn-cg  218078roth.
+ * - One Sk Hynix flash with marking h27ubg8t2btr.
+ * It was sold as having 1GB of RAM, which seems consistent with the DRAM
+ * chips found, but the Android image with which it comes only sees 512MB.
+ */
+
+/dts-v1/;
+#include "sun5i-a10s.dtsi"
+#include "sunxi-common-regulators.dtsi"
+#include 
+/* #include  */
+
+/ {
+   model = "Reko SmartBox A10s, mini-X form factor";
+   compatible = "allwinner,reko-smartbox", "allwinner,sun5i-a10s";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   

[linux-sunxi] Re: Installation procedure for mainline U-Boot

[Stefan Monnier]

> $ ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- make savedefconfig
> This command will create defconfig file.

Could you take a look at my recent post on "Submitting new A10s board"
and answer there, since I think it will clarify what is my problem.


Stefan

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/jwvtux9uug3.fsf-monnier%2Bgmane.comp.hardware.netbook.arm.sunxi%40gnu.org.

[linux-sunxi] Re: Installation procedure for mainline U-Boot

[Stefan Monnier]

> i am not sure where is the issue but here are my tips how i built new 
> mainline u-boot few months ago...
> https://linux-sunxi.org/Mainline_U-Boot
> Install additional packages:
> $ apt-get install swig python-dev python3-dev
> Build HowTo:
> $ git clone git://git.denx.de/u-boot.git
> $ git checkout v2020.04
>   # or whatever is latest
> $ make CROSS_COMPILE=arm-linux-gnueabihf- A20-OLinuXino_MICRO-eMMC_defconfig

So far so good, this matches what I do (tho I'm building it on an armhf
box so I don't need to cross compile).

> $ make CROSS_COMPILE=arm-linux-gnueabihf- _defconfig# at
> this point i created new branch and create default configuration for my
> custom tcs-7Zoll device using the 'savedefconfig' method (this is only
> optional step).

Can you provide some more details about what you did at this step?

> # voilaaa u-boot-sunxi-with-splbin is here

Oh, duh!  Indeed it is built but on `v2020.04` (and earlier), it
appeared as:

  BINMAN  u-boot-sunxi-with-spl.bin

in `make`s output, whereas with `master` I instead see:

  BINMAN  all

and the lack of `u-boot-sunxi-with-spl.bin` in this output made me think
the file was not built.  Sorry 'bout the noise. and Thanks!

[ So now I'm back at the other problem of creating the right
  `sun5i-a10s-reko-smartbox.dts` and `A10s-reko-smartbox_defconfig` files
  (see the "Submitting new A10s board" thread).  ]


Stefan

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/jwv1rkdyjah.fsf-monnier%2Bgmane.comp.hardware.netbook.arm.sunxi%40gnu.org.

[linux-sunxi] Installation procedure for mainline U-Boot

[Stefan Monnier]

http://linux-sunxi.org/Bootable_SD_card says that to install U-Boot
coming wither from mainline of legacy should be done with:

dd if=u-boot-sunxi-with-spl.bin of=${card} bs=1024 seek=8

[ except for U-Boot v2013.07 or earlier.  ]

But when I build U-Boot from the mainline's `master` branch, I don't get
any `u-boot-sunxi-with-spl.bin` file.

Did the procedure change?  Where is it documented now?


Stefan

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/jwvk0y73791.fsf-monnier%2Bgmane.comp.hardware.netbook.arm.sunxi%40gnu.org.

[linux-sunxi] Re: Submitting new A10s board

[Stefan Monnier]

Back in 2013, I wrote:
> I just received a box that's externally like a Mini-X, but with an A10s
> inside.  It's sold as a "Reko mk801" 
> (http://dx.com/p/reko-mk801-android-4-0-4-mini-pc-google-tv-player-w-antenna-1gb-ram-4gb-rom-av-hdmi-blue-208095).
>   It has 1024MB of RAM (at least
> I see 4 Elixir chips which, according to the website, should each hold
> 2Gb), tho the stock Android only sees 512MB.

I got it working back then, but since then I have lost that U-Boot and
I'm now trying to bring this little box back to life using the U-Boot
mainline but without success.

Admittedly, it's not as simple because I can't just use the "fex" file
that came with the Android install and furthermore U-Boot has changed
a lot since then, the mini-x-a10s option got lost along the way, and I'm
a bit lost myself.

I tried to create some `foo_defconfig` and `foo.dts` files inspired from
the a10s-olinuxino and r7-tv-dongle ones, but that's not giving me
anything (the led goes red when I put the power and that's that) and I'm
not really surprised, because I don't really know what I'm doing.

Could someone help me?  I've appended my current diff against U-Boot's
`master`.


Stefan


-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/jwvlfio9z7i.fsf-monnier%2Bgmane.comp.hardware.netbook.arm.sunxi%40gnu.org.
diff --git a/arch/arm/dts/sun5i-a10s-reko-smartbox.dts b/arch/arm/dts/sun5i-a10s-reko-smartbox.dts
new file mode 100644
index 00..11d8505277
--- /dev/null
+++ b/arch/arm/dts/sun5i-a10s-reko-smartbox.dts
@@ -0,0 +1,163 @@
+/*
+ * Copyright 2014 Hans de Goede 
+ *
+ * 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.
+ */
+
+/dts-v1/;
+#include "sun5i-a10s.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+
+/ {
+	model = "Reko SmartBox A10s, mini-X form factor";
+	compatible = "allwinner,reko-smartbox", "allwinner,sun5i-a10s";
+
+	aliases {
+		serial0 = 
+	};
+
+	chosen {
+		stdout-path = "serial0:115200n8";
+	};
+
+	connector {
+		compatible = "hdmi-connector";
+		type = "a";
+
+		port {
+			hdmi_con_in: endpoint {
+remote-endpoint = <_out_con>;
+			};
+		};
+	};
+	leds {
+		compatible = "gpio-leds";
+		pinctrl-names = "default";
+		pinctrl-0 = <_pins_reko>;
+
+		green {
+			label = "reko-smartbox:green:usr";
+			gpios = < 1 2 GPIO_ACTIVE_HIGH>;
+			default-state = "on";
+		};
+	};
+};
+
+ {
+	status = "okay";
+};
+
+ {
+	status = "okay";
+};
+
+_out {
+	hdmi_out_con: endpoint {
+		remote-endpoint = <_con_in>;
+	};
+};
+
+ {
+	pinctrl-names = "default";
+	pinctrl-0 = <_pins_a>, <_cd_pin_reko>;
+	vmmc-supply = <_vcc3v3>;
+	bus-width = <4>;
+	cd-gpios = < 6 1 GPIO_ACTIVE_LOW>; /* PG1 */
+	status = "okay";
+};
+
+ {
+	pinctrl-names = "default";
+	pinctrl-0 = <_pins_a>;
+	vmmc-supply = <_vcc3v3>;
+	bus-width = <4>;
+	non-removable;
+	status = "okay";
+};
+
+ {

[linux-sunxi] Re: [PATCH v2] arm64: dts: allwinner: h6: orangepi-3: Add eMMC node

[Stefan Monnier]

Question:

> OrangePi 3 can optionally have 8 GiB eMMC (soldered on board). Because
> those pins are dedicated to eMMC exclusively, node can be added for both
> variants (with and without eMMC). Kernel will then scan bus for presence
> of eMMC and act accordingly.

Is it just me or would this kind of explanation be better placed inside
the .dts file?


Stefan

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/jwvr1z2qqug.fsf-monnier%2Bgmane.comp.hardware.netbook.arm.sunxi%40gnu.org.

[linux-sunxi] Re: [PATCH 1/3] media: cedrus: Properly signal size in mode register

[Stefan Monnier]

> Do you know if we have a way to report some estimation of the maximum supported
> fps to userspace? It would be useful to let userspace decide whether it's a
> better fit than software decoding.

Even if the fps ends up too low for the player's taste, I can't imagine
why software decoding would be preferable: it seems it could be only
even (substantially) slower.  Or are there speed-up options in software
decoding not available in hardware decoding (such as playing only every
N'th frame, maybe?).


Stefan

[linux-sunxi] Re: [RFC PATCH] drivers: ata: ahci_sunxi: Increased SATA/AHCI DMA TX/RX FIFOs

[Stefan Monnier]

> Increasing the SATA/AHCI DMA TX/RX FIFOs (P0DMACR.TXTS and .RXTS) from
> default 0x0 each to 0x3 each gives a write performance boost of 120MB/s
> from lame 36MB/s to 45MB/s previously. Read performance is about 200MB/s
> [tested on SSD using dd bs=4K count=512K].

Such a simple patch to fix such a long-standing performance problem that
everyone [ well, apparently not quite everyone ] assumed was a hardware
limitation...

And yet, April 1st is long gone.

Is it really for real?


Stefan

-- 
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.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/linux-sunxi/jwvk1ex6rvb.fsf-monnier%2Bgmane.comp.hardware.netbook.arm.sunxi%40gnu.org.
For more options, visit https://groups.google.com/d/optout.

Reboot and audio on Orange Pi mini (was: [linux-sunxi] Re: [PATCH v3 0/9] Stop AXP from crashing when enabling LDO3)

[Stefan Monnier]

> Well, f you have the hardware, then there's only one way to find out:
>
> 1) Apply patchset
> 2) Add following into boards defconfig:
> CONFIG_AXP_ALDO3_INRUSH_QUIRK=y
> 3) If it still fails to reboot, add following
> CONFIG_AXP_ALDO3_VOLT_SLOPE_08=y

Hmm... I tried it and it worked: it now reboots flawlessly.
I tried it first with both setting, then only with the first...
... then without any
... then back with my old U-Boot
and now I can't reproduce the hang that normally happens at almost every
reboot.  Not sure if I should rejoice or what.

One thing I noticed along the way: on my Orange Pi mini, there's
a regression in U-Boot that happened between 2015.07 and 2015.10.
All version I tried starting with 2015.10 cause a constant "humming" on
the audio output (the plain old TRRS plug audio output).

During a reboot, the humming briefly disappears after Linux causes the
reboot and before U-Boot has fully started, but it quickly comes
pretty loudly.  As soon as U-Boot passes the control to the Linux kernel
the humming gets a bit less loud, but remains there.
Playing a song doesn't seem to affect the humming.

Interestingly, if I boot a Linux kernel with HDMI support, then at some
point during the Linux boot, the humming disappears.  But sadly, I need
to use a DTB with the HDMI output disabled because of some unexplained
interaction with the normal audio codec (see the «Odd "jump" when
playing music on A20» thread in the linux-sunxi mainling list, spanning
July to October).


Stefan "back at U-Boot 2015.07"

-- 
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 v3 0/9] Stop AXP from crashing when enabling LDO3

[Stefan Monnier]

> When powering up an AXP209, the default value for LDO3 output is
> enabled.  This works fine.  However if for whatever reason, LDO3 is
> disabled, for example by OS during reboot and u-boot enables LDO3
> again, the PMIC shuts down (without setting an interrupt) causing the
> board to hang.  This behavior has been seen from Linux as well, u-boot
> disables LDO3 as a default value, the kernel enables it per its DTS,
> the kernel hangs as the PMIC gets shut down.

Hmm... I've never had any problems booting my Orange Pi mini, but it
(almost) always hangs on reboot (right after the final message from the
OS and before the first message from U-boot).
Any chance this is the same problem?


Stefan

-- 
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 v3 6/9] power: axp209: Add support for voltage rate control on LDO3

[Stefan Monnier]

> + Increases the voltage by 1.6 mV per uS until the final voltage has
> + been reached. Note that the scaling is in 25 mV steps and thus
> + the slew rate in reality is about 25 mV/31.250 uS.
[...]
> + Increases the voltage by 0.8 mV per uS until the final voltage has
> + been reached. Note that the scaling is in 25 mV steps however and thus
> + the slew rate in reality is about 25 mV/15.625 uS.
> + This is the slowest supported rate.

The numbers 31.25 and 15.625 should be swapped, IIUC.


Stefan

-- 
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 01/15] ARM: dts: sun8i-a33: Remove heading 0 in video-codec unit address

[Stefan Monnier]

> This cosmetic change removes the heading 0 in the video-codec unit
   ^

I think you meant "leading 0" (this applies to the title as well, and
to the other patch for H3 as well).


Stefan

-- 
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 9/9] [DO NOT MERGE] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check

[Stefan Monnier]

> it might also break some panels that currently work and won't now,

Could you give a scenario where this happens?  My reading of the patch
says that it should only cause the display to be ON in more
circumstances (i.e. in cases where it previously would stay OFF because
of MODE_CLOCK_LOW or MODE_CLOCK_HIGH).


Stefan

-- 
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: Odd "jump" when playing music on A20

[Stefan Monnier]

No idea what to do with this problem, but FWIW I just confirmed that the
problem was not magically fixed in kernel 4.18.

OTOH I was able to run the same test on a BananaPi and couldn't
reproduce the problem there, so it seems the problem doesn't affect all
A20 systems: it might be specific to the Orange Pi mini.

I'm currently running with the 4.18 kernel using the DTS from 4.16, which
circumvents the problem by disabling the sun4i-drm (which then falls
back on simple-framebuffer, IIUC).


Stefan


Stefan Monnier  writes:

>> Could you try to revert the sigma delta patch? 
>>
>> git revert de34485
>>
>> Or try to set cpufreq on performance govenor.
>
> Bisecting gave me the following culprit:
>
> commit e3dd25ae0a910b77d049a8cda586a17d8661689d
> Author: Stefan Monnier 
> Date:   Fri Feb 16 15:52:09 2018 -0500
> 
> ARM: dts: sun7i: Enable HDMI support on the Orange Pi mini
> 
> Enable the display pipeline and HDMI output for the Orange Pi mini
> 
> Signed-off-by: Stefan Monnier 
> Signed-off-by: Maxime Ripard 
>
> [ That's right, it's a problem of my own doing, apparently.  ]
>
> bisecting proved to be much faster than expected because it turns out
> that the problem comes from the DT only (and indeed the above commit
> only touches the sun7i-a20-orangepi-mini.dts file) so I didn't need to
> build all those kernels after all:
> - Kernel 4.17 running with the DTB of 4.16 works fine.
> - Kernel e3dd25ae0a910b77d049a8cda586a17d8661689d with its own DTB shows
>   the problematic behavior.
> - Kernel e3dd25ae0a910b77d049a8cda586a17d8661689d with the DTB of
>   the previous commit works fine.
> - Same results with kernel 4.16.
>
> Now, this culprit only enables HDMI output so in theory it
> shouldn't affect the audio codec, yet obviously it does.
>
> When I submitted this patch I didn't notice any adverse effects, but
> I mostly used it on my other machine (bananapi) where I don't use the
> audio codec.
>
> Anyway, any idea what might be going on and how to fix it?
>
>
> Stefan

-- 
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: Odd "jump" when playing music on A20

[Stefan Monnier]

> Could you try to revert the sigma delta patch? 
>
> git revert de34485
>
> Or try to set cpufreq on performance govenor.

Bisecting gave me the following culprit:

commit e3dd25ae0a910b77d049a8cda586a17d8661689d
    Author: Stefan Monnier 
Date:   Fri Feb 16 15:52:09 2018 -0500

ARM: dts: sun7i: Enable HDMI support on the Orange Pi mini

Enable the display pipeline and HDMI output for the Orange Pi mini

Signed-off-by: Stefan Monnier 
Signed-off-by: Maxime Ripard 

[ That's right, it's a problem of my own doing, apparently.  ]

bisecting proved to be much faster than expected because it turns out
that the problem comes from the DT only (and indeed the above commit
only touches the sun7i-a20-orangepi-mini.dts file) so I didn't need to
build all those kernels after all:
- Kernel 4.17 running with the DTB of 4.16 works fine.
- Kernel e3dd25ae0a910b77d049a8cda586a17d8661689d with its own DTB shows
  the problematic behavior.
- Kernel e3dd25ae0a910b77d049a8cda586a17d8661689d with the DTB of
  the previous commit works fine.
- Same results with kernel 4.16.

Now, this culprit only enables HDMI output so in theory it
shouldn't affect the audio codec, yet obviously it does.

When I submitted this patch I didn't notice any adverse effects, but
I mostly used it on my other machine (bananapi) where I don't use the
audio codec.

Anyway, any idea what might be going on and how to fix it?


Stefan

-- 
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: Using sun4i-drm on a BananaPi

[Stefan Monnier]

[...]
> I've compiled the mainline 4.15rc2 kernel with the patch below for the
> bananapi's DTS (ported from the patch that was applied for the
> cubietruck), but when I boot the sun4i-drm module is not loaded.

Duh!  Of course, I didn't `make dtbs`, so I ended up still using the old
DTB without the hdmi-related entries.
After fixing this it all works fine.
Thank you and sorry,


Stefan

-- 
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: Using sun4i-drm on a BananaPi

[Stefan Monnier]

> sun4i-drm is the overall DRM driver, but each separate component in
> the display pipeline has its own module as well. If you look at your
> config above you'll see DRM_SUN4I_HDMI, DRM_SUN4I_BACKEND. However
> if you have the modules installed correctly the kernel should be
> able to load them automatically. If not and you are loading them
> by hand, you need to load the following:

>   - sun4i-tcon
>   - sun4i-backend
>   - sun4i-hdmi
>   - sun4i-drm

[ I don't have a sun4i-hdmi, but I do have a sun4i-drm-hdmi, so I assume
  this was just a typo.  ]

I just did:

modprobe -r sun4i-drm
modprobe sun4i-tcon
modprobe sun4i-backend
modprobe sun4i-drm-hdmi
modprobe sun4i-drm

and all four modules loaded fine (according to `lsmod`), but I get
nothing in dmesg, and /sys/class/drm still only contains `version` :-(

Also, what could cause those modules not to be loaded automatically?


Stefan

-- 
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] Using sun4i-drm on a BananaPi

[Stefan Monnier]

I've compiled the mainline 4.15rc2 kernel with the patch below for the
bananapi's DTS (ported from the patch that was applied for the
cubietruck), but when I boot the sun4i-drm module is not loaded.

My kernel config is based on that Debian's, with most things compiled as
modules:

% grep -i sun4i .config
CONFIG_MACH_SUN4I=y
CONFIG_CAN_SUN4I=m
CONFIG_SUN4I_EMAC=m
CONFIG_MDIO_SUN4I=y
CONFIG_KEYBOARD_SUN4I_LRADC=m
CONFIG_TOUCHSCREEN_SUN4I=m
CONFIG_SERIO_SUN4I_PS2=m
CONFIG_SPI_SUN4I=m
CONFIG_PINCTRL_SUN4I_A10=y
CONFIG_MFD_SUN4I_GPADC=m
CONFIG_DRM_SUN4I=m
CONFIG_DRM_SUN4I_HDMI=m
CONFIG_DRM_SUN4I_HDMI_CEC=y
CONFIG_DRM_SUN4I_BACKEND=m
CONFIG_SND_SUN4I_CODEC=m
CONFIG_SND_SUN4I_I2S=m
CONFIG_SND_SUN4I_SPDIF=m
CONFIG_DMA_SUN4I=y
CONFIG_SUN4I_A10_CCU=y
CONFIG_SUN4I_TIMER=y
CONFIG_SUN4I_GPADC=m
CONFIG_PWM_SUN4I=m
CONFIG_PHY_SUN4I_USB=m
CONFIG_CRYPTO_DEV_SUN4I_SS=m
CONFIG_CRYPTO_DEV_SUN4I_SS_PRNG=y
%

I can `modprobe sun4i_drm` but that gives me nothing in `dmesg` and
while /sys/class/drm exists, it remains sadly empty (my BananaPi is
connected via HDMI to a screen where I do get a framebuffer console but
it's presumably still using the simplefb code).

Is there something missing in my kernel config?  Or DTS?  Or do I need
to do something else/more than loading sun4i0-drm?  Or did I just
slaughter the wrong goat?


Stefan


index 88a1c2363c6c..45da8a282288 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -63,6 +63,17 @@
stdout-path = "serial0:115200n8";
};
 
+ hdmi-connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <_out_con>;
+ };
+ };
+ };
+
leds {
compatible = "gpio-leds";
pinctrl-names = "default";
@@ -109,6 +120,10 @@
>;
 };
 
+ {
+ status = "okay";
+};
+
  {
status = "okay";
 };
@@ -130,6 +145,16 @@
};
 };
 
+ {
+ status = "okay";
+};
+
+_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <_con_in>;
+ };
+};
+
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>;

-- 
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 v8] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

[Stefan Monnier]

> Thanks for your work on this, I've queued it in 3.14.
> It will appear in my branches and next as soon as 3.13-rc1 is out.

I presume you meant "4." instead of "3." above,


Stefan

-- 
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: A33 Suspend

[Stefan Monnier]

> I updated the instructions on the wiki to update the commit tag.  You
> shouldn't need to switch branches if the commit tag is correct.  It looks
> like the old commit tag disappeared.  I tested with the new commit tag on
> sina-a33 and it appears to work. (make sure to use correct u-boot config
> and dtb)  If this commit tag disappears, the patch should apply to anything
> close to 4.12-rc1 in the sunxi-next branch.

If it's anything like linux-next (i.e. it's regularly rebased), the
commit on sunxi-next will likely disappear again soon.


Stefan

-- 
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 10/15] drm/sun4i: tcon: Switch mux on only for composite

[Stefan Monnier]

>> +   if (encoder->encoder_type == DRM_MODE_ENCODER_TVDAC)
>> +   val = 1;
>> +   else
>> +   val = 0;

Isn't this better written as

   val = (encoder->encoder_type == DRM_MODE_ENCODER_TVDAC);


-- Stefan

-- 
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 0/15] drm: sun4i: Add support for the HDMI controller

[Stefan Monnier]

> Here is an attempt at getting the HDMI controller running.
> This HDMI controller is found on a number of old Allwinner SoCs (A10, A10s,
> A20, A31).

Thank you thank you thank you.


Stefan "I need it on the A20, so we're not quite
there yet, but it's great to see progress on this front"

-- 
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 RFC] drm/sun4i: rgb: Add 5% tolerance to dot clock frequency check

[Stefan Monnier]

> So we're back to where we started. What is a reasonable tolerance to set in
> the driver if we don't know the tolerances of the panel?

Can you manually fudge the min/max settings from the guessed timing to
which you apply a 5% tolerance?

IOW, the 5% tolerance is not in the driver's code but in the "script"
(or human) used to create the panel description.


Stefan

-- 
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 4/8] drm/sun4i: add support for sun8i DE2 mixers and display engines

[Stefan Monnier]

>  drivers/gpu/drm/sun4i/Kconfig   |   8 +
>  drivers/gpu/drm/sun4i/Makefile  |   1 +
>  drivers/gpu/drm/sun4i/sun4i_crtc.c  |   6 +-
>  drivers/gpu/drm/sun4i/sun4i_drv.c   |  38 +++-
>  drivers/gpu/drm/sun4i/sun4i_drv.h   |   1 +
>  drivers/gpu/drm/sun4i/sun4i_layer.c |  92 ++--
>  drivers/gpu/drm/sun4i/sun4i_layer.h |   1 +
>  drivers/gpu/drm/sun4i/sun8i_mixer.c | 417 
> 
>  drivers/gpu/drm/sun4i/sun8i_mixer.h | 133 

Should the drm/sun4i directory be renamed to drm/sunxi then?


Stefan

-- 
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: Whither the DRM driver for A20?

[Stefan Monnier]

> It works, but IIRC noone has submitted device patches to mainline (or
> noone has bothered to update Wiki).
>
> Some work with A20 Olinuxino Lime and Micro:
> https://github.com/net147/linux/branches

Hmm... so looking briefly at those patches, it seems that it indeed
reuses the display engine driver of A13, good.

I'd be great to see those patches merged into mainline.

> And I have a WIP LVDS support for a Gemei G9 tablet (which still relies
> on u-boot to set up LVDS gating):
> https://github.com/plaes/linux/tree/sun4i-lvds-wip

All the info I find refers to LVDS.  Any hope to see HDMI support?


Stefan

-- 
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] Whither the DRM driver for A20?

[Stefan Monnier]

I was very happy several months ago to see a preliminary patch that added
a DRM driver for the A10/A20.  But when I look at
http://linux-sunxi.org/Linux_mainlining_effort the status of DRM support
for A20 says "Nobody works on it, but it should be compatible with
already done drivers".

Oddly enough that same page says that the A13's DRM driver was mainlined
into Linux-4.7.  I thought A13's display engine is basically the same
(or a subset) of that of the A10/A20.

So could someone clarify the situation for the state of the support of
the A20's display engine?


Stefan

-- 
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: OpenFirmare / OpenBoot for A13

[Stefan Monnier]

>> PS: Even tho the cards are "old/small" they're much larger than the 
>> U-Boot they hold, so I have a slight feeling of "waste". 
> A SPI Flash can work without wasting a lot.

So I heard, indeed.  But I don't have any SPI Flashes lying around,
don't know of any friends who have some, and I don't think the local
drugstore has them either.  And if did get my hand on some, I wouldn't
know how to connect them to my BananaPi, nor how to connect them to my
laptop/desktop to program them :-(


Stefan

-- 
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: OpenFirmare / OpenBoot for A13

[Stefan Monnier]

> The reason why i wish to use this one is that i'm actually looking towards 
> having the A13 being able to boot gnu/linux from usb hard disk and or usb 
> cd/dvd as if it were a powermac, a sun machine or an olpc.

FWIW, my A20 machines boot this way, using U-Boot: I use an old/small
(μ)SD card to hold a plain unconfigured U-Boot install (it doesn't even
have a partition).

That installation by default looks for U-Boot boot script in various
places, including the SD card, the network, any USB-connected drive, or
in my case the SATA connected hard-drives, where I placed my usual /boot
partition as partition 1.


Stefan


PS: Even tho the cards are "old/small" they're much larger than the
U-Boot they hold, so I have a slight feeling of "waste".

-- 
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 v9 0/2] sun4i-codec: Add Line-In, FM-In, Mic 2, Capture Source, Differential Line-In

[Stefan Monnier]

>  - rename "Line-In" to "Line".

Curious: why?


Stefan

-- 
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: Problems with Orange Pi mini

[Stefan Monnier]

> Can you try if that works:
> echo b > /proc/sysrq-trigger
> That's the hardcore version of "reboot" which does wait any process to
> nicely terminate, including filesystems.

I just tried it, but it doesn't work either: the machine just hangs there.


Stefan


PS: FWIW, in this "frozen state", the network interface is off
(according to the little "lan" light on my modem).

-- 
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] Problems with Orange Pi mini

[Stefan Monnier]

I recently noticed two problems with my Orange Pi mini running Debian's
stock 4.6.0-1-armmp kernel:

- Reboot doesn't work.  I think this has been the case "for ever", but
  I just noticed that it's still the same (in the last few months
  I never rebooted this machine, so I didn't notice the problem very
  much): if I do "reboot" the machine does most of the shutdown
  procedure (at least, according to the sound of the HDD), but it
  then gets stuck there waiting for something.
  The same works fine with the same rootfs on a BananaPi.

- I can't use the OTG in host mode.

cat /sys/devices/platform/soc@01c0/1c13000.usb/musb-hdrc.1.auto/mode

  says `b_idle` regardless of what I plug into the OTG connector.
  I also tried

echo host > /sys/devices/.../musb-hdrc.1.auto/mode

  but it made no difference (including no message in dmesg).

Before I go and try and dig deeper (which is rather inconvenient since
this acts now as my main home router, so whenever I turn it off someone is
bound to be annoyed).  Does this ring a bell to anyone?


Stefan

-- 
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] Mainline under Debian!

[Stefan Monnier]

Just a little thank you note: with the introduction of the 4.6
kernels in Debian testing, I can finally use stock kernels on all my
little ARM boxes (used as NAS-style servers, so all based on A20).

[ With 4.4 I could use the stock kernels already, but I still needed
  a hand-built DTB to use the audio output on my OrangePi-mini, then
  with 4.5 I had trouble with the network interface.  4.6 seems to be
  the ticket!  ]

BTW, the OTG support comes really handy to provide a kind of "second
network interface".


Stefan

-- 
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: sunxi_usb_udc

[Stefan Monnier]

> Hello! I am trying to create my own USB gadget based on sunxi_usb_udc and
> GadgetFS. I can't find any details about sunxi_usb_udc and after successful
> startup detection I am unable to get data sent by host side. How can
> I proceed?.

IIUC, sunxi_usb_udc is the driver used in Allwinner's kernels.
This mailing list is about the mainline support for sunxi, where the
driver is completely different (IIRC the module name is musb-hdrc).

If at all possible, I strongly recommend you try to use a recent
mainline kernel, because the OTG support there is much more reliable
than what's in Allwinner's kernels in my experience (at least for A20
boards).


Stefan

-- 
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: Reliability of A20 boards

[Stefan Monnier]

> My cubietruck with battery and Samsung HDD has been up for 79 days using
> this power supply:

BTW, by "reliability" I don't mean "time between reboots" but "time
before hardware failure".  So far my experience with sunxi hardware
running 24/7 (mostly used as NAS) has been rather mixed:
- Cubietruck: dead after a bit less than a year (DRAM not recognized by
  U-Boot any more).
- BananaPi: it took me a week to find a micro-USB cable that would be
  able to provide enough power.  And after about a year, the power
  supply weakened, so it wasn't booting any more (and it seems to have
  caused HDD corruption).  I'm in the process of getting another power
  supply and it seems the board is actually not faulty.
- OrangePi-mini: not yet up to a year, but working OK so far (fewer
  power problems largely thanks to the experience gained earlier with
  the BananaPi I guess).
- Mele-A2000: this one actually still works, with the original power
  supply, tho it's having some non-deterministic boot failures which
  could be explained by power supply issues.

I really love these little buggers because they consume very little power
but offer all the resources I need.  I just wished I could feel more
confident that it won't die on me when I'm away for a few weeks.


Stefan

-- 
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] Unreliable boot on Mele-A2000

[Stefan Monnier]

> So this happens right after spinning up the disk, which is the
> moment when the disk uses significantly more power then during
> normal operation.

Actually, according to the noises I hear, the spin up happens about 1 or
2 seconds before getting to the "Found U-Boot script /boot.scr" message
and the "timeout exit!" message comes long after that.

> I would try replacing your power-supply with a more powerful one.

Yes, I find it's incredibly hard to find reliable 5V power supplies for
those puppies.  Actually, the whole reason why I'm setting up this Mele
A2000 box is because the power supply for my Banana Pi is "dead" (it's
worked fine for a year, and now it still pretends to give 5V, but it
only gets me to the SPL "DRAM:" message or so before the system
stops/locksup).


Stefan

-- 
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] Unreliable boot on Mele-A2000

[Stefan Monnier]

>> But this last step often fails with timeouts or bad CRC checksums or
>> other errors (the exact errors vary from time to time).  I'd estimate
>> that the boot succeeds about 1/3 of the time.
> Could you post some logs on how it fails?

Here's one example (hand-copied, so may include some typos):

Scanning scsi 0:0...
Found U-Boot script /boot.scr
853 bytes read in 21 ms
## Executing script at 4310
scanning bus for devices...
  Device 0: (0:0) Vendor: ATA Prod.: ST912082 Rev: 3.06
Type: Hard Disk
Capacity: 114473.4 MB = 111.7 GB
Found 1 devic(s).
timeout exit!
timeout exit!
3636648 bytes read in 20153 ms (175.8 KiB/s)
timout exit!
bad MBR sector signature 0xf55a
** Invalid partition 1**
timout exit!
bad MBR sector signature 0x
** Invalid partition 1**


Stefan

-- 
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: Unreliable boot on Mele-A2000

[Stefan Monnier]

> Could you post some logs on how it fails?

For some reason my UART<->USB adapter doesn't want to cooperate (it is
getting long in the tooth), so while I wait to receive the new one, I'll
have to hand-copy it from the HDMI output.  Will do that tomorrow when
I'll get a chance to reboot the machine.


Stefan

-- 
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] Reliability of A20 boards

[Stefan Monnier]

I like to use A20 boards for little NAS-style servers, because of their
very low power consumption.

But so far I'm not impressed w.r.t reliability (large part of the
problem being to get a reliable enough power adapter, it seems).

So, I'm looking for recommendations for an A20 board (with SATA) where
the main issue is for it to be reliable (i.e. where I should be able to
expect it to keep on running 24/7 for 5 to 10 years, like my old ASUS
WL-700gE).


Stefan

-- 
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] Unreliable boot on Mele-A2000

[Stefan Monnier]

I recently took out an old Mele-A2000 and set it up with an HDD
connected (an old 120GB 2.5" laptop drive) via SATA to boot into Debian.

Things mostly work correctly, except that the early boot is unreliable.
More specifically:
- I use a recent U-Boot (v2016.05) compiled with default flags for
  "Mele_A1000_defconfig".
- This U-Boot is installed in an SD card with nothing else on it (so
  the boot script).
- So the boot procedure looks for some boot.scr and should end up
  finding it on the HDD's /dev/sda.
- It usually finds it OK, which causes loading of vmlinuz and
  uinitrd.img.

But this last step often fails with timeouts or bad CRC checksums or
other errors (the exact errors vary from time to time).  I'd estimate
that the boot succeeds about 1/3 of the time.

Once booted, the machine seems to work reliably, (including heavy disk
and CPU use).  This is using Debian's stock kernel 4.6.0-1-armmp.

What could be going on?


Stefan

-- 
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: CedarX Encoder Demo

[Stefan Monnier]

> I have added "V4l2" sources to the CedarX encoder demo.
> This is basically the "Camera" sources from AW demo that was around for 
> A20...

IOW a complete waste of time.
I'd encourage you instead to work with the Cedrus library, which has the
philosophical/ethical advantage of being Free Software, and the
technical advantages of not being a dead-end black-box.


Stefan

-- 
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] dma: sun4i: expose block size and wait cycle configuration to DMA users

[Stefan Monnier]

>>> Why does dmaengine need to wait? Can you explain that
[...]
> I see 2 possible reasons why waiting till checking for drq can help:

Any chance something similar is causing the "max 50MB/s" limit on SATA
transfers for A10/A20?


Stefan

-- 
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: random decryption errors with sun4i-ss on dm-crypt

[Stefan Monnier]

> Thanks, I installed your cryptotest suite including your new lukstest
> tool and ran some tests on a Banana Pi tonight. The results were all
> good. After a first successful run of lukstest, I modified the script
> and increased the sample size by a factor of 100 (and the image file,
> too). Even with the increased sample size, I didn't see any errors
> (because of the increased test duration, I ran only 5 iterations,
> though). Tests were done on an Armbian installation with Kernel 4.4.1
> (with your patch "Add missing state size" on top of it) in order to
> resemble the original reporters conditions more closely. I was
> planning to do tests with 4.4.2 as well, but since all tests succeeded
> so far, I don't think that would change anything.

[ Just a random shot in the dark from someone who knows nothing about
  these things.  ]

My guess is that to reproduce the problem, you need to have maybe the
same intertwined sequence of decryption and disk access (who I have no
idea what kind of disk he's using).
IOW it could be linked to some interference from the disk's interrupts
or something.


Stefan

-- 
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: allwinner-zh/media-codec demo

[Stefan Monnier]

> He is looking for an Encoder and libvdpau-sunxi providers a decoder 
> functionality.
> I don't think there is any RE encoder code, except this stupidity that AW 
> released, very incomplete. There is a PoC of a H264 encoder, but that is 
> not available for anything beyond A10/A20, I guess.

I know libvdpau-sunxi won't do what he wants right now, which is why I said:
> > It needs a lot of work, but  at least it's cleaner and will benefit
> > more people in the long run.


Stefan

-- 
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: allwinner-zh/media-codec demo

[Stefan Monnier]

Don't waste your time with allwinner-zh/media-codec.
Try and use the libvdpau-sunxi instead.  It needs a lot of work, but
at least it's cleaner and will benefit more people in the long run.


Stefan


> "@lex" == @lex   writes:

> Hi,
> I am trying to make the vencoder demo works, the sample provided in 
> media-codec from allwinner.
> Bear in mind i am new to the encoding process, let's see if what i want is 
> possible and if i am doing the right way and if you can help.

> I would like to convert a 720p YUV420 image i grabbed from my camera into 
> JPEG image, that is all i need, the fastest way possible using less CPU.
> I managed to compile the demo and the framework, so i changed the following:

> src_width = 1280;
> src_height = 720;
> dst_width = 1280;
> dst_height = 720;

> codecType = VENC_CODED_JPEG;
> baseConfig.eInpuFormat = VENC_PIXEL_YUV420SP;

> I get "segmentation fault" with this parameters.

> So, the questions are:
> a) Is my understanding that i can use this to encode my YUV to JPEG correct?
> b) Has anyone tested, used or checked if the framework really works?
> c) Can you share a piece of code to achieve this simple task? or even share 
> a YUV sample image that works with the demo?

> @lex






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

[linux-sunxi] Re: Rotated video playback on A20

[Stefan Monnier]

> Can you give advice on how to approach this? Is it at all possible to do
> rotation with the CedarX driver?

I'd recommend you try it with the libvdpau-sunxi since it's at least
a code base that is amenable to improvements.


Stefan

-- 
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: Rotated video playback on A20

[Stefan Monnier]

> the video engine is able to rotate the video while decoding, but its not
> possible to export this feature with vdpau.
> vdpau doesn't provide the information that it needs a rotated video at
> decoding time, but only later at render time. You would have to look
> into the future to do rotate at decoding time.

Hmm... that sucks.  I think it deserves a bug report to "the vdpau
designers/maintainers"?
In the mean time, is there some way to hack around this problem by
retro-feeding the "rotate" request to the decoder when the render
gets it?
Obviously, that means applying the rotation request to the wrong frames
But if the same rotation is applied for the duration of a complete movie
(which is rather likely), it means just the first few frames would
be incorrect.
Obviously, a "major ugly hack", but if it can be made to work, it might
just be good enough in practice, while we wait for vdpau to fix
this problem.


Stefan

-- 
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] ARM: dts: sun7i: Add dts file for the lamobo-r1 board

[Stefan Monnier]

> The lamobo-r1 board, sometimes called the BPI-R1 but not labelled as such
> on the PCB, is meant as a A20 based router board. As such the board comes
> with a built-in switch chip giving it 5 gigabit ethernet boards, and it
> has a large empty area on the pcb with mounting holes which will fit a
> 2.5 inch harddisk. To complete its networking features it has a
> Realtek RTL8192CU for WiFi 802.11 b/g/n.

When I looked for a DTS file for this board, I was told that the
bananapi DTS works just fine, the only difference being the ethernet
switch chip, which is not supported by mainline anyway (because the
only driver for it is in OpenWRT, using a framework that was never
accepted into mainline).

So is there some way to share the bulk of this file with that of
the bananapi?


Stefan

-- 
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 sunxi-tools 2/2] fel: Enable MMU on Allwinner-H3

[Stefan Monnier]

> When the CPU clock speed is set to 480 MHz by the U-Boot SPL,
   ^^^
You mean MBUS?

> the performance improvement for 'sunxi-fel write' transfers
> to DRAM is ~95 KB/s -> ~510 KB/s.

> When the CPU clock speed is set to 1008 MHz by the U-Boot SPL,
> the performance improvement for 'sunxi-fel write' transfers
> to DRAM is ~180 KB/s -> ~510 KB/s.

I don't understand the relation between the above 2 improvements.
What change causes the speed to go from 95KB/s to 180KB/s?


Stefan

-- 
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: audio codec: input/output error from aplay if "Pre-Amplifier DAC" and "Pre-Amplifier Mute" are off

[Stefan Monnier]

> AFAIK this is the behavior of ALSA.  If there's no valid output path
> for the default soundcard/route, it'll block instead of just dropping
> output.  Can't say if this is the "correct" behavior though.  You should
> probably ask the ALSA maintainers.

I guess the main issue (which is sunxi-specific) is that the default
settings of sunxi's mixer should enable an output path.


Stefan

-- 
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: audio codec: input/output error from aplay if "Pre-Amplifier DAC" and "Pre-Amplifier Mute" are off

[Stefan Monnier]

>> I guess the main issue (which is sunxi-specific) is that the default
>> settings of sunxi's mixer should enable an output path.
> Yes.  Hans already raised the issue.  This is a userspace setting, which
> is in alsa-lib and not part of kernel proper.
> See https://lkml.org/lkml/2015/9/30/867

Is there a patch for that available somewhere?


Stefan

-- 
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] ARM: dts: sun7i: Enable audio codec on pcDuino

[Stefan Monnier]

BTW, I've been using successfully the same additions in
sun7i-a20-bananapi.dts and sun7i-a20-orangepi-mini.dts.


Stefan


> "Hans" == Hans de Goede  writes:

> From: Jelle van der Waa 
> Enable the on-chip audio codec

> Signed-off-by: Jelle van der Waa 
> Signed-off-by: Hans de Goede 
> ---
>  arch/arm/boot/dts/sun7i-a20-pcduino3.dts | 5 +
>  1 file changed, 5 insertions(+)

> diff --git a/arch/arm/boot/dts/sun7i-a20-pcduino3.dts 
> b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
> index 861a4a6..067f365 100644
> --- a/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-pcduino3.dts
> @@ -111,6 +111,11 @@
>   allwinner,pins = "PH2";
>  };
 
> +
> + {
> + status = "okay";
> +};
> +
>   {
>   cpu-supply = <_dcdc2>;
>  };
> -- 
> 2.5.0


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

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

[Stefan Monnier]

> The current code only assumes that there is a single instance of all
> the controllers. It also supports only the RGB and Composite
> interfaces.

Sorry for the offtopic question, but: you seem to have spent a fair bit
of time on PAL/NTSC support.  In my own little world, devices using
those things have disappeared about ten years ago, so I'm curious in
which kinds of circumstances they're still in use.


Stefan

-- 
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: Is this mailing list dead?

[Stefan Monnier]

> I'm asking here questions about linux-sunxi and didn't get any answers at 
> all.

Do you really expect an answer in less than an hour?

On which planet do you live?


Stefan

-- 
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: Help to find "SUNXI USB2.0 Dual Role Controller support" in menuconfig?

[Stefan Monnier]

> However, in current menuconfig (of sunxi)

Which kernel are you using?  3.4 or mainline?


Stefan

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

[linux-sunxi] Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Stefan Monnier]

> @Maxime: How should we handle this? In its current form, the patch applies
> only to the BananaPi dts by overriding the inherited opp from the SoC dtsi.
> In an earlier discussion, it was said that this can be done, even though it
> might not be the most elegant approach. But then again, I think it
> shouldn't be necessary to change the opp in the sun7i-a20.dtsi for all A20
> boards since this is - to my knowledge - the first and only report that an
> A20 board has stability issues at the lower voltages (although not too many
> boards use voltage scaling yet).

IIUC this setting doesn't affect signals external to the A20, so it
seems like it should be board-agnostic.


Stefan

-- 
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: Allwinner A20 SMP issue

[Stefan Monnier]

> We are trying to port Windows CE on to Marsboard (A20).

So why are you asking here rather than asking Allwinner?


Stefan

-- 
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: U-boot fails to read my SD cards

[Stefan Monnier]

 => load mmc 0 0x4400 uImage
 ** ext4fs_devread read error - block
>>> Bummer, so can you read uImage from this card using the Linux kernel
>>> once booted ?
>> Yes,
> Can you try my sunxi-wip branch? This one has some fixes which
> might fix this.

Indeed, I just tried it and it was able to read my "vmlinuz" file just
fine (tho only at 246kB/s, which is rather slow, even for an old 256MB
SD card).
Yay!  Thanks!


Stefan

-- 
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: U-boot fails to read my SD cards

[Stefan Monnier]

 => load mmc 0 0x4400 uImage
 ** ext4fs_devread read error - block
>>> Bummer, so can you read uImage from this card using the Linux kernel
>>> once booted ?
>> Yes,
> Can you try my sunxi-wip branch? This one has some fixes which
> might fix this.

I'll try it as soon as I get back to the corresponding machines.


Stefan

-- 
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: U-boot fails to read my SD cards

[Stefan Monnier]

 = load mmc 0 0x4400 uImage
 ** ext4fs_devread read error - block
 Bummer, so can you read uImage from this card using the Linux kernel
 once booted ?

Yes,


Stefan

-- 
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: U-boot fails to read my SD cards

[Stefan Monnier]

 IIUC there's a general sentiments that most SD cards are crap (and
 indeed mine are all oldcheap), but I find it striking that they work
 everywhere *except* for U-boot reading a large file.
 What sunxi board(s) are you using ?
 I have a Mele A2000, a pair of cheap mini-x style a10s box,
 a BananaPi, an OrangePi-mini, and a Cubietruck, but in this present
 round of (involuntary) tests, I used the BananaPi and the OrangePi-mini.
 So both A20 devices, I did a fix recently(ish) to properly set the sample
 clock phase for the mmc clock in u-boot. Are you using a recent u-boot ?
 Also I see in the fex files for these boards that they are using 1.3V
 instead of 1.25V for dcdc3, something else you can test is to edit
 board/sunxi/board.c and then change:

 power_failed |= axp209_set_dcdc3(1250);

 into:

 power_failed |= axp209_set_dcdc3(1300);

 Built u-boot that way and see if it helps.

I just tried with a U-boot built from the latest (as of this morning)
master branch, with the patch below applied (the part_dos.c part of
the patch shouldn't make any difference, tho), but I still get the same:

= load mmc 0 0x4400 uImage
 ** ext4fs_devread read error - block


-- Stefan


diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index f85e825..dfbc4c4 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -429,7 +429,7 @@ void sunxi_board_init(void)
 #ifdef CONFIG_AXP209_POWER
power_failed |= axp209_init();
power_failed |= axp209_set_dcdc2(1400);
-   power_failed |= axp209_set_dcdc3(1250);
+   power_failed |= axp209_set_dcdc3(1300);
power_failed |= axp209_set_ldo2(3000);
power_failed |= axp209_set_ldo3(2800);
power_failed |= axp209_set_ldo4(2800);
diff --git a/disk/part_dos.c b/disk/part_dos.c
index cf1a36e..f7134ae 100644
--- a/disk/part_dos.c
+++ b/disk/part_dos.c
@@ -25,7 +25,7 @@
 
 /* Convert char[4] in little endian format to the host format integer
  */
-static inline int le32_to_int(unsigned char *le32)
+static inline unsigned int le32_to_int(unsigned char *le32)
 {
 return ((le32[3]  24) +
(le32[2]  16) +
@@ -46,13 +46,13 @@ static inline int is_bootable(dos_partition_t *p)
return p-boot_ind == 0x80;
 }
 
-static void print_one_part(dos_partition_t *p, int ext_part_sector,
+static void print_one_part(dos_partition_t *p, lbaint_t ext_part_sector,
   int part_num, unsigned int disksig)
 {
-   int lba_start = ext_part_sector + le32_to_int (p-start4);
-   int lba_size  = le32_to_int (p-size4);
+   lbaint_t lba_start = ext_part_sector + le32_to_int (p-start4);
+   lbaint_t lba_size  = le32_to_int (p-size4);
 
-   printf(%3d\t%-10d\t%-10d\t%08x-%02x\t%02x%s%s\n,
+   printf(%3d\t%-10lu\t%-10lu\t%08x-%02x\t%02x%s%s\n,
part_num, lba_start, lba_size, disksig, part_num, p-sys_ind,
(is_extended(p-sys_ind) ?  Extd : ),
(is_bootable(p) ?  Boot : ));
@@ -101,7 +101,8 @@ int test_part_dos (block_dev_desc_t *dev_desc)
 /*  Print a partition that is relative to its Extended partition table
  */
 static void print_partition_extended(block_dev_desc_t *dev_desc,
-int ext_part_sector, int relative,
+lbaint_t ext_part_sector,
+lbaint_t relative,
 int part_num, unsigned int disksig)
 {
ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc-blksz);
@@ -109,7 +110,7 @@ static void print_partition_extended(block_dev_desc_t 
*dev_desc,
int i;
 
if (dev_desc-block_read(dev_desc-dev, ext_part_sector, 1, (ulong *) 
buffer) != 1) {
-   printf (** Can't read partition table on %d:%d **\n,
+   printf (** Can't read partition table on %d:%lu **\n,
dev_desc-dev, ext_part_sector);
return;
}
@@ -148,7 +149,8 @@ static void print_partition_extended(block_dev_desc_t 
*dev_desc,
pt = (dos_partition_t *) (buffer + DOS_PART_TBL_OFFSET);
for (i = 0; i  4; i++, pt++) {
if (is_extended (pt-sys_ind)) {
-   int lba_start = le32_to_int (pt-start4) + relative;
+   lbaint_t lba_start
+   = le32_to_int (pt-start4) + relative;
 
print_partition_extended(dev_desc, lba_start,
ext_part_sector == 0  ? lba_start : relative,
@@ -162,8 +164,9 @@ static void print_partition_extended(block_dev_desc_t 
*dev_desc,
 
 /*  Print a partition that is relative to its Extended partition table
  */
-static int get_partition_info_extended (block_dev_desc_t *dev_desc, int 
ext_part_sector,
-int relative, int part_num,
+static int get_partition_info_extended (block_dev_desc_t *dev_desc,
+lbaint_t ext_part_sector,
+ 

[linux-sunxi] Re: U-boot fails to read my SD cards

[Stefan Monnier]

 IIUC there's a general sentiments that most SD cards are crap (and
 indeed mine are all oldcheap), but I find it striking that they work
 everywhere *except* for U-boot reading a large file.
 What sunxi board(s) are you using ?

I have a Mele A2000, a pair of cheap mini-x style a10s box,
a BananaPi, an OrangePi-mini, and a Cubietruck, but in this present
round of (involuntary) tests, I used the BananaPi and the OrangePi-mini.


Stefan

-- 
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 v8] dma: sun4i: Add support for the DMA engine on sun[457]i SoCs

[Stefan Monnier]

 Applied with subsystem name fixed

Yay!


Stefan

-- 
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] U-boot fails to read my SD cards

[Stefan Monnier]

With my recent effort to move all my remaining 3.4 machines to
(almost)mainline, I saw a strange pattern:
Many of the SD cards I have can't be read by U-boot.  Yet, they work
fine elsewhere.

More specifically, more than half of the SD cards I've tried show the
following behavior:
- I can put U-boot on them and the A20 boots fine.
- The U-boot code loaded from the card (mainline U-boot 2014-07) can
  read the card's partition table, root directory, and load the
  boot.scr script.
- Once booted, Linux can read all the files on the card via
  /dev/mmcblk0p1.
- All 3 USB card readers I have can readwrite to those cards without
  any problem.
- But U-boot can't load the vmlinuz/uImage files (I get ext4 errors).

IIUC there's a general sentiments that most SD cards are crap (and
indeed mine are all oldcheap), but I find it striking that they work
everywhere *except* for U-boot reading a large file.

Of course, this problem pushed me to change my machines's setup so
U-boot reads the kernelinitrd directly from the hard-disk, so to some
extent I don't care that much about it any more, but still.  I think the
MMC code used in our U-boot has a bug.


Stefan

-- 
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: [RFC] ARM: dts: sunxi: Add regulators and board-specific operating points for LeMaker BananaPi

[Stefan Monnier]

 IMHO for a common maximum opp that's a good approach. But for the lowest
 frequency setting, it would seem more logical to me, to raise the voltage
 to a point where all boards will run fine with them, unless those boards
 cannot handle the frequency regardless of the higher voltage.

I generally agre, tho IIRC some measurements seem to indicate that the
lowest frequency settings did not bring much (if any) reduction in power
consumption, making them rather useless.


Stefan

-- 
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: Further Allwinner misbehaviour.

[Stefan Monnier]

 It is time to extend the negative marketing campaign to some of 
 Allwinners customers, and truly hit Allwinner where it hurts.
 While I do think that a large-scale boycott could really make a change here
 and force Allwinner to release code and comply with licenses, I also think
 that the community utterly lacks the means to achieve an effective boycott.

Rather than getting them to release existing code (which IIUC doesn't
integrate well with GNU/Linux and the mainline kernel anyway), I'd much
rather we try to get them to work on helping the mainlining effort (on
the kernel side) and helping develop Cedrus (on the CedarX side).


Stefan

-- 
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: TRRS on Banana Pro and Orange Pi

[Stefan Monnier]

 No idea about Orange Pi. But if you can confirm the Banana Pro's pinout it 
 would help if you add this stuff 
 to http://linux-sunxi.org/Banana_Pro#Tips.2C_Tricks.2C_Caveats

Thanks.  I can't confirm it yet, but I added the corresponding info on
that page.


Stefan

-- 
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] TRRS on Banana Pro and Orange Pi

[Stefan Monnier]

The new SBCs seem to all be moving to using a TRRS connector for
combined composite+audio output.  That makes a fair bit of sense, but
the lack of standard makes it unclear which cable to use.

Could someone comment on the mutual compatibility between these board
and other systems (e.g. the new Raspberry Pi, which also moved to using
a TRRS), or even point to cables that they know work?


Stefan who only needs the audio, really

-- 
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] [OFFTOPIC] Why use USB over SDIO

[Stefan Monnier]

While comparing the OrangePi Mini and the Banana Pro, I noticed that the
Banana Pro connects its wifi chip via SDIO whereas the OrangePi Mini
uses a USB connection.

My naive understanding is that the BananaPro choice is better since the
A20 already provides the SDIO connection, whereas the OrangePi Mini ends
up needing a USB hub (an FE1.1s chip, apparently) where only 2 of the
4 outputs is used.

Also, http://www.orangepi.org/orangepimini/index.html states:

  USB  |   2 USB 2.0 host, 1 USB 2.0 OTG (all direct from A20 chip)

but if I understand the schematics, that's not true since one of the
two USB host ports of the A20 gets fed to the FE1.1s hub.
Am I missing something?

One more thing: I couldn't find schematics for the BananaPro.
Did I just not look at the right place, or does LeMaker really fail to
distribute that info (which would suck)?


Stefan

-- 
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: [OFFTOPIC] Why use USB over SDIO

[Stefan Monnier]

 Newer wifi is too fast for USB 2.0. For example 5Ghz or 11ac.

Hard to believe.  I never managed to go any further than 5MB/s over wifi
(in real-life usage), so in my world 30MB/s is still a long way ahead.
But in any case, this argues in favor of SDIO, which again makes me
wonder why the OrangePi guys went with USB.

 If you only care about 2.4Ghz wifi the USB based modules are usually cheaper.

But cheaper enough to pay for the extra USB hub?


Stefan

-- 
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: [OFFTOPIC] Why use USB over SDIO

[Stefan Monnier]

 https://linux-sunxi.org/Banana_Pro contains a link to the schematics
 at the bottom of the page.

Thanks!


Stefan

-- 
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: [OFFTOPIC] Why use USB over SDIO

[Stefan Monnier]

 Top end 11AC will do 175MB/s = 1.4Gb/s

Right, but has anyone actually seen anywhere near that bandwidth in real
life?  E.g. I haven't even been able to get past 3MB/s with 11n at home.

This said, the SDIO info I found seem to say that it only reaches 200Mb/s.

 But cheaper enough to pay for the extra USB hub?
 That hub chip is about $0.30.

So is a USB wifi chip really more then $0.30 cheaper than an SDIO wifi chip?


Stefan

-- 
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] ERROR: sun4i_usb_phy_set_squelch_detect [drivers/usb/musb/sunxi.ko] undefined

[Stefan Monnier]

That's the error I get when I tried to compile Hans's sunxi-wip branch with

   CONFIG_USB_MUSB_SUNXI=m
   CONFIG_PHY_SUN4I_USB=m

If I change them to =y the compilation error doesn't show up (haven't
tried to change only one of the two).


Stefan

-- 
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: Trying 4.1 on a Mele-A2000

[Stefan Monnier]

 I have compered our configs and I think you should try to enable these
 modules. One of them should resolve your issue.
 CONFIG_REGULATOR_DEBUG=y
 CONFIG_REGULATOR_VIRTUAL_CONSUMER=y
 CONFIG_REGULATOR_USERSPACE_CONSUMER=y
 CONFIG_PWM_SUN4I=y

Indeed, after enabling those 4, my ethernet is now working.  Thanks.
I haven't tried to enable only a subset of them, so I don't know which
one of those is actually needed.

By the sound of it, CONFIG_PWM_SUN4I=y seems unrelated and
CONFIG_REGULATOR_DEBUG=y should not make a difference, and between the
remaining two I'd guess that the one that matters is
CONFIG_REGULATOR_VIRTUAL_CONSUMER=y.

Thanks.  Now on to adding sunxi-codec,


Stefan

-- 
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: testing sunxi-codec on Cubieboard A10

[Stefan Monnier]

 Right the patches for the Mele A1000 where still floating around on the
 list, I've picked them up now and added them to my sunxi-wip branch,
 so you may want to give things another try copying the relevant bits from
 the sun4i-a10-a1000.dts file to the sun4i-a10-cubieboard.dts one.

I just tried your sunxi-wip branch in my Mele A2000, and the audio codec
doesn't quite work.

More specifically, the sunxi-codec loads fine, I see the following in
the dmesg:

[5.115895] sunxi-codec 1c22c00.codec: Codec - 1c22c00.codec mapping ok

and I see the following:

   # cat /proc/asound/devices 
 2: [ 0]   : control
 3: [ 0- 0]: digital audio playback
 4: [ 0- 0]: digital audio capture
33:: timer
   # cat /dev/sndstat   
   Sound Driver:3.8.1a-980706 (ALSA emulation code)
   Kernel: Linux server 4.1.0-rc1-00208-g29675ef #10 SMP Wed Jun 10 15:29:18 
EDT 2015 armv7l
   Config options: 0
   
   Installed drivers: 
   Type 10: ALSA emulation
   
   Card config: 
   sunxi-codec
   
   Audio devices: NOT ENABLED IN CONFIG
   
   Synth devices: NOT ENABLED IN CONFIG
   
   Midi devices: NOT ENABLED IN CONFIG
   
   Timers:
   31: system timer
   
   Mixers: NOT ENABLED IN CONFIG
   #

But I'm not sure what that means: alsamixer doesn't find any device and
neither does mpd.

In the patch against 3.16 from Emilio that I've been using so far, the
above output is pretty much the same (actually without the digital
audio playback line), and alsamixer doesn't find any device either, but
mpd works fine (including mixer control of a Master output).


Stefan

-- 
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: testing sunxi-codec on Cubieboard A10

[Stefan Monnier]

 i started testing the 4.1rcX kernel 
 from https://github.com/jwrdegoede/linux-sunxi/blob/sunxi-wip/ to check how 
 the sunxi-codec was working on my Cubieboard A10 board.

Great.  I'm about to do the same (I'm first trying to get the mainline
4.1 to work on my Mele-A2000 (see other thread where I'm having
problems with the ethernet port) before adding the codec) to replace my
3.16.0-rc5 kernel.

 BTW i've been told that this codec has been tested also on Mele A1000 
 that's A10 based STB too, but i failed to see any  trace of it in the 
 sunxi-wip so don't know if this report has been done.

Yes, I've been using a 3.16 kernel with codec patches on my Mele A2000.
But it seems that my patch to the corresponding dts files got lost
somewhere along the way (I really didn't write the patch anyway, I just
took someone else's and tweaked it without knowing what I was doing).

FWIW, here are the two patches I'm using (the one I got from Marcus
Cooper and then the one I added by hand) for the 3.16 kernel (IIUC the
DMA and codec code has changed since then, so it might require some
adjustments).

My audio needs are very simple (I use it with an MPD daemon and
loudspeakers plugged into the line-out connectors of my Mele), but it
works OK (there are cases where it skips every ~23s for reasons that
escape me, but it seems those reasons tend to disappear after a while or
after a reboot) and the mixer works normally.


Stefan


% git show fb3ae87c7e8cba95d6b1b993923b53367fe3949c 
71af6414aad688cf901a4b6e1aaa0076e467c01f
commit fb3ae87c7e8cba95d6b1b993923b53367fe3949c
Author: Stefan Monnier monn...@iro.umontreal.ca
Date:   Tue Oct 7 22:04:27 2014 -0400

Fix up sun4i-a10.dtsi to match sun7i-as0.dtsi

diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index ff2ee3e..51f65a5 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -82,11 +82,11 @@
};
 
pll2: clk@01c20008 {
-   #clock-cells = 1;
-   compatible = allwinner,sun4i-a10-b-pll2-clk;
+   #clock-cells = 0;
+   compatible = allwinner,sun4i-a10-pll2-clk;
reg = 0x01c20008 0x4;
clocks = osc24M;
-   clock-output-names = pll2, pll2x2, pll2x4, pll2x8
+   clock-output-names = pll2;
};
 
pll4: clk@01c20018 {
@@ -344,7 +344,7 @@
#clock-cells = 0;
compatible = allwinner,sun4i-a10-codec-clk;
reg = 0x01c20140 0x4;
-   clocks = pll2 0;
+   clocks = pll2;
clock-output-names = codec;
};
 
@@ -697,9 +697,9 @@
#sound-dai-cells = 0;
compatible = allwinner,sun4i-a10-codec;
reg = 0x01c22c00 0x40;
-   interrupts = 0 30 4;
-   clocks = pll2 0, apb0_gates 0, codec_clk;
-   clock-names = pll, apb, codec;
+   interrupts = 30;
+   clocks = pll2, apb0_gates 0, codec_clk;
+   clock-names = pll2, apb, codec;
dmas = dma 0 19, dma 0 19;
dma-names = rx, tx;
routing =

commit 71af6414aad688cf901a4b6e1aaa0076e467c01f
Author: Marcus Cooper codekip...@gmail.com
Date:   Mon Oct 6 12:51:16 2014 -0400

Add DT sound support for Mele-A1000

diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts b/arch/arm/boot/dts/sun4i-a10
index 9e99ade..a052343 100644
--- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
+++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
@@ -94,6 +94,10 @@
status = okay;
};
 
+   codec@01c22c00 {
+   status = okay;
+   };
+
uart0: serial@01c28000 {
pinctrl-names = default;
pinctrl-0 = uart0_pins_a;
diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi b/arch/arm/boot/dts/sun4i-a10.dtsi
index faf41e3..ff2ee3e 100644
--- a/arch/arm/boot/dts/sun4i-a10.dtsi
+++ b/arch/arm/boot/dts/sun4i-a10.dtsi
@@ -81,6 +81,14 @@
clock-output-names = pll1;
};
 
+   pll2: clk@01c20008 {
+   #clock-cells = 1;
+   compatible = allwinner,sun4i-a10-b-pll2-clk;
+   reg = 0x01c20008 0x4;
+   clocks = osc24M;
+   clock-output-names = pll2, pll2x2, pll2x4, pll2x8
+   };
+
pll4: clk@01c20018 {
#clock-cells = 0;
compatible = allwinner,sun4i-a10-pll1-clk;
@@ -331,6 +339,15 @@
clocks = osc24M, pll6 1, pll5 1;
clock-output

[linux-sunxi] Re: Trying 4.1 on a Mele-A2000

[Stefan Monnier]

 Having the whole .config and all the boot logs would help, but did you
 enable CONFIG_MDIO_SUN4I?

Hmm... so it turned out that yes, that was enabled.  And, comparing with
Jarosław's .config I don't see anything that rings a bell.
For the record, here's my dmesg and my .config.


Stefan

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


dmesg.out.gz
Description: application/gzip


config-4.1.0-rc6-00044-g8cd9234.gz
Description: application/gzip

[linux-sunxi] Re: tv-in documentation from allwinner?

[Stefan Monnier]

 the lack of parts (DVB tuners) that can feed a TS to the A20 so no 
 proper integration with a DVB linux subsystem has been done.

Oh, I missed the fact that the onboard part only does the TS part.
If you need an external tuner, then indeed it's probably not worth
the trouble.


Stefan

-- 
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: tv-in documentation from allwinner?

[Stefan Monnier]

 There is quite a bit of documentation on the MPEG-TS part.  And some
 people have been looking into writing a driver, but lack of commonly
 available hardware to develop on slows things down.

I suspect that lack of driver for that part is also a reason for the
lack of boards that provide access to the DVB functionality :-(

With good mali+cedar+ts drivers, the A20 would be a great platform to
run Kodi, but sadly none of those three has seen much activity.


Stefan

-- 
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: Banana R1 router german article

[Stefan Monnier]

 http://www.pc-magazin.de/ratgeber/banana-pi-r1-router-anleitung-openwrt-bananian-3021511.html
 
 Anyone has ever tested this router? I heard they had problems to make
 the BCM switch working properly.

 Someone ported the BCM switch driver to mainline:
 https://github.com/Dh0mp5eur/BCM53125-Mainline-Patches
 https://github.com/ptolts/BCM53125-Mainline-Port/tree/master/linux

So, all that's needed to make it work on mainline is the *.dts file?


Stefan

-- 
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 0/2] sun4i spi dma support

[Stefan Monnier]

 So is the dmaengine going to get anywhere

Depends if someone pushes it or not, IIUC.


Stefan

-- 
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 0/3] Using SPI NOR flah on sunxi.

[Stefan Monnier]

 The SPI driver returns an error when more than 64 bytes are
 transferred at once due to lack of DMA support.

Have you tried the dmaengine patch and make the SPI driver use it?


Stefan

-- 
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: A20 DMA engine patch and GMAC

[Stefan Monnier]

 When SATA uses it's own DMA code this could explain why writing to SATA disk
 is up to 5 times slower than reading.

I don't see why.  The SATA code in mainline for Allwinner uses the same
code (including DMA) as used on many other platforms, AFAIK.

But yes, I'm also very curious why SATA write speed seems limited to
about 40MB/s.


Stefan

-- 
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: Devices naming consistency in U-Boot, Linux, sunxi-boards and the linux-sunxi wiki

[Stefan Monnier]

 I can think of a couple of exceptions which might resolve that (based
 around device name includes vendor or is clearly linked to a specific
 vendor) but TBH I think if there are loads of exceptions then the
 benefits of the cleanups is watered down somewhat.

Agreed.  I'm not sure it's terribly important to have a very strong
naming convention on that side.  The important part of the naming
consistency is to make sure that the exact same name is used everywhere
(u-boot, dts, wiki, ...).


Stefan

-- 
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: sunxi-kms driver

[Stefan Monnier]

 Also copyright like this looks weird:
  * Copyright (C) 2015-2020 Allwinner Technology Co., Ltd.
 Living in the future? :)
 I'm granting all the copyright to my newly written code to Allwinner so no...
 It's 2015 and the copyright goes 5 years... Am I wrong? ^^'

Yes, you're wrong: the copyright statement is about when the copyright
starts, basically, so it can't be in the future.  The duration of the
copyright is then defined based on this information combined with the
law (which is not 5 years, but more like 75 years, or maybe even 75
years after the death of the author, and has changed over the time,
with the tendency being to extend copyright towards infinity, since
those decisions are mostly taken by people who have personal financial
incentives to extend the coverage as much as they can get away with (or
are close to people who have such)).


Stefan

-- 
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: HDCP support in sunxi for A20

[Stefan Monnier]

 further only in encrypted form. How is that a denial for freedom?  Surely,
 you are not saying that proprietary content should never be transmitted
 using any open source product.

Open Source doesn't really care about Freedom, indeed, but Free Software
does.


Stefan

-- 
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: HDCP support in sunxi for A20

[Stefan Monnier]

 I working on a pretty basic STB model, where proprietary content needs to 
 be downloaded and played on tv. Its a requirement to encrypt the content :( 
 ( i know hdcp gets a lot of hate, but such is the nature of the beast)

I think if you're implementing such Freedom-denying code, you'd be
better off asking for help somewhere else.


Stefan

-- 
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: Allwinner strips symbols from latest cedar binaries.

[Stefan Monnier]

 My vote is to completely forget about any CedarX binary releases from
 Allwinner, and focus on the reverse engineered driver. Nothing good is
 likely to come from the Allwinner binary driver. To continue discussions
 about the binary driver only makes things worse for everyone involved.

(with-aol-mode
  Agreed!)


Stefan

-- 
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: Annoucement about Allwinner's CedarX Software Licensing

[Stefan Monnier]

 Recently, there have been some questions about CedarX's software
 licensing. To clear up any misconceptions about Allwinner's support
 and respect for the open source community, the CedarX media codec
 framework is now released with full open source code under the LGPL
 license. Everyone can get the complete source code from github:
 https://github.com/allwinner-zh/media-codec.

libvdecoder.so and libvencoder.so don't sound very much like
source code.


Stefan

-- 
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: Directions for video engine support (CedarX)

[Stefan Monnier]

 The way I understood all these was that there are short-term and
 long-term goals for better support with the video engine.

As an end user, I think that having mainline support (not just for the
kernel, but the rest of the stack as well) for something like Kodi (nee
XBMC) would be great.

Ever since the first Android TV sticks came out, I have hoped to use one
of those beasts as a media-center.  But so far I haven't been able to do
that: when using GNU/Linux the video playback sucks for lack of VPU
support, and when using Android I'm faced with the problem that there's
no DVD player software available in Android (there are lots of players
which advertise support for playing DVDs, but they actually don't
support playing from an optical drive).


Stefan

-- 
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: Directions for video engine support (CedarX)

[Stefan Monnier]

 I'm interested in this as well.
 When I've tried manually mounting in Android they still fail.  It looks like
 the data coming off is still in a format the software can't take.
 Does someone have step by step instructions for Android?

Additionally to mounting, I think it is necessary to perform some extra
steps to unlock the data (not sure if it's got to do with the DVD
regions or the DVDCSS part), unless the DVD is not copy protected.

GNU/Linux players know how to do that, but for some reason Android
players don't (even though AFAIK they should be able to just use the
same code as on GNU/Linux, since it's a kernel-level API).


Stefan

-- 
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: [RFC] Serial number on sunxi devices

[Stefan Monnier]

 if necessary truncate the SID somehow.

Or hash it,


Stefan

-- 
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: sunxi otg usb code for mainline (wip) available now

[Stefan Monnier]

 I'm happy to report that after a lot of poking at the Allwinner
 musb code I've it working reliable in both host and peripheral mode,
 as well as automatically switching between the 2 depending on which
 cable gets plugged.

Yay!


Stefan

-- 
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: Communication with Allwinner

[Stefan Monnier]

 What are the violation claims? Is it documented somewhere so that I can
 learn more about the issue?
 http://linux-sunxi.org/GPL_Violations

BTW, most of those are violations in Allwinner's SDK/kernel, whereas
most of the code that gets integrated into mainline is actually
different, AFAICT (using Allwinner's code as documentation rather than
as a starting point).

So while the two are emotionally connected, the technical connection is
less serious.  I think most people would be happy if Allwinner helped
get (GPL-clean, of course) code into mainline even if they don't fix the
GPL violations in the old SDKs.


Stefan

-- 
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: Allwinner A20 SMP Issue

[Stefan Monnier]

   Though this is not related to Linux, I hope to get your expertise support
 to solve a A20 related issue.  We are trying to port Windows C E on to
 Marsboard (A20).

Now, that's new.  Why don't you ask the vendor?

Or better: why don't you first release the Windows CE code as Free
Software so we can also benefit from that expertise?


Stefan

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