Re: [linux-sunxi] Re: sunxi-devel branch updated to 3.15-rc1
On Sunday, 27 April 2014 10:02:41 UTC-3, Hans de Goede wrote: > > Hi, > > On 04/16/2014 03:43 AM, Kenny MacDermid wrote: > > Thanks Hans, > > > > On the mmc stuff, I just tested the latest code and I'm still getting > > errors on my SDXC (64G) card. The SDXC card works fine on an x86 > machine. > > I'm having no issues with SDHC cards. > > > > I'm afraid I've no clue what is causing this :| > > I just tested it with a stock 3.4 kernel and I get the same result, so I guess it's not something new. Is there any other kernel or branch I could test? Anything directly from Allwinner? I can mail you or David this card if it'd help in debugging it. I hope it's not just the card. I haven't heard any complaints from anyone else using SDXC, but then it works in other machines. -- 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: gslx680 driver ported to sunxi
Hi Joe, I have a gsl1680 chip and it is a 4.3" 480x272 display. I used the "firmware/fw_extractor" tool extracted the firmware from the Android binary gslx680.ko for my tablet, but experiencing the same issue Selim had before. dmesg shows the driver successfully loaded, chip probed and firmware also loaded correctly, but evtest shows no output whatsoever. Any help or ideas will be appreciated, thanks in advance. thanks, -Hunter On Tuesday, March 18, 2014 5:03:24 AM UTC-5, Joe Burmeister wrote: > > On 18/03/14 09:03, selim...@gmail.com wrote: > > 17 Mart 2014 Pazartesi 00:52:27 UTC+2 tarihinde Joe Burmeister yazdı: > >> On 14/03/14 15:36, selim...@gmail.com wrote: > >> > >>> 14 Mart 2014 Cuma 17:33:56 UTC+2 tarihinde selim...@gmail.com yazdı: > 13 Mart 2014 Perşembe 14:22:52 UTC+2 tarihinde Joe Burmeister yazdı: > > On 13/03/14 12:05, selim...@gmail.com wrote: > >> 13 Mart 2014 Perşembe 12:20:15 UTC+2 tarihinde Joe Burmeister > yazdı: > >>> On 13/03/14 09:52, selim...@gmail.com wrote: > 27 Ağustos 2013 Salı 22:14:14 UTC+3 tarihinde > joe.a.bu...@gmail.com yazdı: > > Hi, > > For a while I've been working on getting my A13 tablet touch > screen working with GNU/Linux. > > It's now working well enough for my purposes and I figured it > was time to push it out. > > The code can be found at: > > https://gitorious.org/gslx680-for-sunxi > > It would be easy to move it in tree. What is a bit different > from the other touch screen drivers is that it doesn't include the firmware > in the driver. > > I've split the firmware into a separate file that you name in > the fex/script.bin file. > > The reason for this is that the firmware defines things about > the hardware such as resolution and can't be easily modified. So to support > multiple devices you'd need multiple firmware included. Or your have to > build for each driver+firmware combination. Better to have it a seperate > file and which firmware be a configuration thing. That fits better to me > with fex/script.bin or Device Tree. I've also added legacy single touch as > well as multi touch. > > Not sure where we go from here, but no point me sitting on it. > ;-) > > Joe > > > Hi, > I have a A13 tablet (just like this one --> > http://moveontechnology.com/hugoenchina/?p=324) > and while trying to make touchscreen working I came acrross with > this gslx680 driver(https://gitorious.org/gslx680-for-sunxi) > I'm using sunxi-3.4 kernel and compiled the driver successfully > for this kernel. My screen resolution is 800x480 so I'm using the firmware > supplied by the source code. > I can successfully insmod the driver, got the successfull dmesg > messages as expected, but when I try testing the driver with "evtest" tool, > i got totally no output from gslx680 mmodule (/dev/event/event1). > I am completely stuck at this point, any suggestion will be > really helpfull. > Thanks in advance. > selim > >>> Hi Selim, > >>> I've done an update recently that makes the new code work properly > with > >>> X, it was broken at one point. > >>> At this point, as far as I know, I need to start the process of > getting > >>> it into sunxi properly. Maybe add DT and get it fully upstreamed. > Yet to > >>> start that process. > >>> Anyway, no output from evtest tells me the problem is probably the > firmware. > >>> You need to extract the firmware from your android driver. There > is a > >>> python script in the firmware directory called fw_extractor (and > >>> fw_info) that should be able to do this, if the driver is related > to the > >>> Android one with my device. If the firmware isn't in the Android > driver, > >>> then we need to find where it lives on your device and put it into > the > >>> same binary format. > >>> If you feel you aren't getting anywhere, send me the Android > driver and > >>> I'll have a look to see if the firmware is in there and adapt the > script > >>> to find it there too. > >>> We need to start building a database of the firmware for the > gslx680 > >>> chips. If we can work out how to tell which chip needs which > firmware, > >>> we can select the right one automatically. The aim of course is > >>> everything just works. :-) > >>> Joe > >> Joe Hi, > >> Thanks for the quick reply, > >> Indeed I have read in some forum posts that people trying wrong > >> gslx680 firmwares got shifted touch outputs, I haven't seen a post > >> with no output from the driver. > >> I hope its about the wrong firmware. > >> Ok, now I will pull the successfully running driver (gslX680.ko) > >> from running android device and extract the firmware as you > suggested. > >>>
[linux-sunxi] Re: gslx680 Touch screen driver issue.
Hi Nathan, Have you ever figured out what happened? I am having the exact same problem, everything seems fine from dmesg, evtest, just not hardware events. Thanks, -Hunter On Thursday, February 13, 2014 1:14:30 PM UTC-6, Nathan Buckley wrote: > > Hi Guys, I'm hoping someone will be able to help me with an issue I've > been having. For the last few days I've been trying to get a touchscreen > working. The touchscreen is a gslx680. The device is a A13 whitelabel > tablet. I have it booting up into Ubuntu - Xfce4, it's using the 3.4 linux > sunix kernel. > > I'm using the driver source from https://gitorious.org/gslx680-for-sunxiand > dmesg leads me to believe that it was installed (insmod) correctly and > detects the chip. Alas nothing happends when I touch the screen. I tried > evtest and it detects the gslx680 as input device, but again when I test it > doesn't spawn any events. > > Dmsg, Xorg log file and evtest output can be viewed here > http://pastebin.com/5Zi7KqTf > > Fex file that I'm using as script.bin is here http://pastebin.com/pf8CkG6u > > > Any help, or indication how to better debug the issue would be greatly > appreciated. > > More information, I've run i2cdetect and it detects a device at address > 0x40. > > When I try and set a value manually via i2cset or get it does say that the > address is busy. > > Thanks. > -- 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 v5 3/3] ARM: sunxi: Add IR controller support in DT on A20
On Wed, Apr 30, 2014 at 09:16:50PM +0600, Alexander Bersenev wrote:
> This patch adds IR controller in A20 Device-Tree:
> - Two IR devices found in A20 user manual
> - Pins for two devices
> - One IR device physically found on Cubieboard 2
> - One IR device physically found on Cubietruck
>
> Signed-off-by: Alexander Bersenev
> Signed-off-by: Alexsey Shestacov
> ---
> arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 6 ++
> arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 6 ++
> arch/arm/boot/dts/sun7i-a20.dtsi| 31
> +
> 3 files changed, 43 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> index feeff64..2564e8c 100644
> --- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> @@ -164,6 +164,12 @@
> reg = <1>;
> };
> };
> +
> + ir0: ir@01c21800 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ir0_pins_a>;
> + status = "okay";
> + };
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> index e288562..e375e89 100644
> --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> @@ -232,6 +232,12 @@
> reg = <1>;
> };
> };
> +
> + ir0: ir@01c21800 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&ir0_pins_a>;
> + status = "okay";
> + };
> };
>
> leds {
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 0ae2b77..bb655a5 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -724,6 +724,19 @@
> allwinner,drive = <2>;
> allwinner,pull = <0>;
> };
> +
> + ir0_pins_a: ir0@0 {
> + allwinner,pins = "PB3","PB4";
> + allwinner,function = "ir0";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> + ir1_pins_a: ir1@0 {
> + allwinner,pins = "PB22","PB23";
> + allwinner,function = "ir1";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> };
>
> timer@01c20c00 {
> @@ -937,5 +950,23 @@
> #interrupt-cells = <3>;
> interrupts = <1 9 0xf04>;
> };
> +
> + ir0: ir@01c21800 {
This line...
> + compatible = "allwinner,sun7i-a20-ir";
> + clocks = <&apb0_gates 6>, <&ir0_clk>;
> + clock-names = "apb", "ir";
> + interrupts = <0 5 4>;
> + reg = <0x01c21800 0x40>;
> + status = "disabled";
> + };
> +
> + ir1: ir@01c21c00 {
... and this one are indented a tab too far.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH v5 2/3] ARM: sunxi: Add driver for sunxi IR controller
On Wed, Apr 30, 2014 at 09:16:49PM +0600, Alexander Bersenev wrote:
> This patch adds driver for sunxi IR controller.
> It is based on Alexsey Shestacov's work based on the original driver
> supplied by Allwinner.
>
> Signed-off-by: Alexander Bersenev
> Signed-off-by: Alexsey Shestacov
> ---
> drivers/media/rc/Kconfig| 10 ++
> drivers/media/rc/Makefile | 1 +
> drivers/media/rc/sunxi-ir.c | 303
>
> 3 files changed, 314 insertions(+)
> create mode 100644 drivers/media/rc/sunxi-ir.c
>
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index 8fbd377..9427fad 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -343,4 +343,14 @@ config RC_ST
>
>If you're not sure, select N here.
>
> +config IR_SUNXI
> +tristate "SUNXI IR remote control"
> +depends on RC_CORE
> +depends on ARCH_SUNXI
> +---help---
> + Say Y if you want to use sunXi internal IR Controller
> +
> + To compile this driver as a module, choose M here: the module will
> + be called sunxi-ir.
> +
> endif #RC_DEVICES
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index f8b54ff..93cdbe9 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -32,4 +32,5 @@ obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
> obj-$(CONFIG_IR_IGUANA) += iguanair.o
> obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
> obj-$(CONFIG_RC_ST) += st_rc.o
> +obj-$(CONFIG_IR_SUNXI) += sunxi-ir.o
> obj-$(CONFIG_IR_IMG) += img-ir/
> diff --git a/drivers/media/rc/sunxi-ir.c b/drivers/media/rc/sunxi-ir.c
> new file mode 100644
> index 000..f051d94
> --- /dev/null
> +++ b/drivers/media/rc/sunxi-ir.c
> @@ -0,0 +1,303 @@
> +/*
> + * Driver for Allwinner sunXi IR controller
> + *
> + * Copyright (C) 2014 Alexsey Shestacov
> + * Copyright (C) 2014 Alexander Bersenev
> + *
> + * Based on sun5i-ir.c:
> + * Copyright (C) 2007-2012 Daniel Wang
> + * Allwinner Technology Co., Ltd.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define SUNXI_IR_DEV "sunxi-ir"
> +
> +/* Registers */
> +/* IR Control */
> +#define SUNXI_IR_CTL_REG 0x00
> +/* Rx Config */
> +#define SUNXI_IR_RXCTL_REG0x10
> +/* Rx Data */
> +#define SUNXI_IR_RXFIFO_REG 0x20
> +/* Rx Interrupt Enable */
> +#define SUNXI_IR_RXINT_REG0x2C
> +/* Rx Interrupt Status */
> +#define SUNXI_IR_RXSTA_REG0x30
> +/* IR Sample Config */
> +#define SUNXI_IR_CIR_REG 0x34
> +
> +/* Bit Definition of IR_RXINTS_REG Register */
> +#define SUNXI_IR_RXINTS_RXOF BIT(0) /* Rx FIFO Overflow */
> +#define SUNXI_IR_RXINTS_RXPE BIT(1) /* Rx Packet End */
> +#define SUNXI_IR_RXINTS_RXDA BIT(4) /* Rx FIFO Data Available */
> +/* Hardware supported fifo size */
> +#define SUNXI_IR_FIFO_SIZE16
> +/* How much messages in fifo triggers IRQ */
> +#define SUNXI_IR_FIFO_TRIG8
> +/* Required frequency for IR0 or IR1 clock in CIR mode */
> +#define SUNXI_IR_BASE_CLK 800
> +/* Frequency after IR internal divider */
> +#define SUNXI_IR_CLK (SUNXI_IR_BASE_CLK / 64)
> +/* Sample period in ns */
> +#define SUNXI_IR_SAMPLE (10ul / SUNXI_IR_CLK)
> +/* Filter threshold in samples */
> +#define SUNXI_IR_RXFILT 1
> +/* Idle Threshold in samples */
> +#define SUNXI_IR_RXIDLE 20
> +/* Time after which device stops sending data in ms */
> +#define SUNXI_IR_TIMEOUT 120
> +
> +struct sunxi_ir {
> + spinlock_t ir_lock;
> + struct rc_dev *rc;
> + void __iomem*base;
> + int irq;
> + struct clk *clk;
> + struct clk *apb_clk;
> + const char *map_name;
> +};
> +
> +static irqreturn_t sunxi_ir_irq(int irqno, void *dev_id)
> +{
> + unsigned long status;
> + unsigned char dt;
> + unsigned int cnt, rc;
> + struct sunxi_ir *ir = dev_id;
> + DEFINE_IR_RAW_EVENT(rawir);
> +
> + spin_lock_irq(&ir->ir_lock);
> +
> + status = readl(ir->base + SUNXI_IR_RXSTA_REG);
> +
> + /* clean all pending statuses */
> + writel(status | 0xff, ir->base + SUNXI_IR_RXSTA_REG);
> +
> + if (status & SUNXI_IR_RXINTS_RXDA) {
> + /* How much messages in fifo */
> + rc = (status >> 8) & 0x3f;
> + /* Sanity check */
> + rc = rc > SUNXI_IR_FIFO_SIZE ? SUNXI_IR_FIFO_SIZE : rc;
> + /* if we have data */
> + for (cnt = 0; cnt
[linux-sunxi] Re: [PATCH v3] sunxi: Add support for consumer infrared devices
On Wed, Apr 30, 2014 at 02:06:27AM -0700, Александр Берсенев wrote: > Also setting clock-frequency via DT is not implenented yet for sunxi > clocks. I can try to add this functionality too. The clock frequency should be on the device node, not the clock one. On such cases, it's up to the device to call clk_set_rate and not to expect the clock to run at the proper frequency. -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v5 1/3] ARM: sunxi: Add documentation for sunxi consumer infrared devices
On Wed, Apr 30, 2014 at 09:16:48PM +0600, Alexander Bersenev wrote:
> This patch adds documentation for Device-Tree bindings for sunxi IR
> controller.
>
> Signed-off-by: Alexander Bersenev
> Signed-off-by: Alexsey Shestacov
> ---
> .../devicetree/bindings/media/sunxi-ir.txt | 23
> ++
> 1 file changed, 23 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/sunxi-ir.txt
>
> diff --git a/Documentation/devicetree/bindings/media/sunxi-ir.txt
> b/Documentation/devicetree/bindings/media/sunxi-ir.txt
> new file mode 100644
> index 000..d502cf4
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/sunxi-ir.txt
> @@ -0,0 +1,23 @@
> +Device-Tree bindings for SUNXI IR controller found in sunXi SoC family
> +
> +Required properties:
> +- compatible : should be "allwinner,sun7i-a20-ir";
> +- clocks : list of clock specifiers, corresponding to
> + entries in clock-names property;
> +- clock-names: should contain "apb0_ir0" and "ir0" entries;
> +- interrupts : should contain IR IRQ number;
> +- reg: should contain IO map address for IR.
> +
> +Optional properties:
> +- linux,rc-map-name : Remote control map name.
> +
> +Example:
> +
> +ir0: ir@01c21800 {
> + compatible = "allwinner,sun7i-a20-ir";
> + clocks = <&apb0_gates 6>, <&ir0_clk>;
> + clock-names = "apb0_ir0", "ir0";
Most of the time, we use something like "apb" and "ir". The names
being generic, if there ever comes a time where you have a second
controller, you don't have to do anything confusing or inconsistent.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [linux-sunxi] Using usbtv driver on A20
Hi, now i follow all the instructions (i missed to set KLIB_BUILD) and builded drivers (usbtv). it also builded videobuf2 and videodev.ko and compact. So i tryed to use it on A20 with 3.4 kernel but probably there is some of symbols in videodev that are already specified in main kernel, it load only compact module -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi 3/4] mvtwsi: Remove unnecessary twsi_baud_rate and twsi_slave_address globals
These are used only once, so their is no need to have them global.
This also stops mvtwsi from using any bss vars making it easier to use
before dram init (to talk to the pmic to set the dram voltage).
Signed-off-by: Hans de Goede
---
drivers/i2c/mvtwsi.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c
index b449443..5ba0e03 100644
--- a/drivers/i2c/mvtwsi.c
+++ b/drivers/i2c/mvtwsi.c
@@ -219,24 +219,12 @@ static int twsi_stop(int status)
(CONFIG_SYS_TCLK / (10 * (m + 1) * (1 << n)))
/*
- * These are required to be reprogrammed before enabling the controller
- * because a reset loses them.
- * Default values come from the spec, but a twsi_reset will change them.
- * twsi_slave_address left uninitialized lest checkpatch.pl complains.
- */
-
-/* Baudrate generator: m (bits 6..3) = 8, n (bits 2..0) = 4 */
-static u8 twsi_baud_rate = 0x44; /* baudrate at controller reset */
-/* Default slave address is 0 (so is an uninitialized static) */
-static u8 twsi_slave_address;
-
-/*
* Reset controller.
* Called at end of i2c_init unsuccessful i2c transactions.
* Controller reset also resets the baud rate and slave address, so
* re-establish them.
*/
-static void twsi_reset(void)
+static void twsi_reset(u8 baud_rate, u8 slave_address)
{
/* ensure controller will be enabled by any twsi*() function */
twsi_control_flags = MVTWSI_CONTROL_TWSIEN;
@@ -245,9 +233,9 @@ static void twsi_reset(void)
/* wait 2 ms -- this is what the Marvell LSP does */
udelay(2);
/* set baud rate */
- writel(twsi_baud_rate, &twsi->baudrate);
+ writel(baud_rate, &twsi->baudrate);
/* set slave address even though we don't use it */
- writel(twsi_slave_address, &twsi->slave_address);
+ writel(slave_address, &twsi->slave_address);
writel(0, &twsi->xtnd_slave_addr);
/* assert STOP but don't care for the result */
(void) twsi_stop(0);
@@ -275,11 +263,8 @@ void i2c_init(int requested_speed, int slaveadd)
}
}
}
- /* save baud rate and slave for later calls to twsi_reset */
- twsi_baud_rate = baud;
- twsi_slave_address = slaveadd;
/* reset controller */
- twsi_reset();
+ twsi_reset(baud, slaveadd);
}
/*
--
1.9.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] [PATCH u-boot-sunxi 0/4] Use existing mvtwsi code for i2c
Hi All, As a result of upstream review I've been working on moving to using the existing u-boot mvtwsi code for i2c instead of our own sunxi_i2c.c driver. This patch-set implements this. Sofar it has only been tested on a cubietruck, I plan to run some more tests on sun4i and sun5i, and then unless someone objects I'll be pushing this to the u-boot-sunxi git repo. The 2 mvtwsi fixes have also been posted to the u-boot mailinglist. Regards, Hans -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH u-boot-sunxi 1/4] mksunxiboot: Fix loading of files with a size which is not a multiple of 4
We should not be aligning the amount of bytes which we try to read from the
disk, this leads to trying to read more bytes then there are which fails.
file_size is already aligned to BLOCK_SIZE before being stored in
img.header.length, so there is no need for load_size at all.
Signed-off-by: Hans de Goede
---
tools/mksunxiboot.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index da7c9f0..1f0fbae 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -77,7 +77,7 @@ int main(int argc, char *argv[])
{
int fd_in, fd_out;
struct boot_img img;
- unsigned file_size, load_size;
+ unsigned file_size;
int count;
if (argc < 2) {
@@ -101,8 +101,6 @@ int main(int argc, char *argv[])
if (file_size > SRAM_LOAD_MAX_SIZE) {
fprintf(stderr, "ERROR: File too large!\n");
return EXIT_FAILURE;
- } else {
- load_size = ALIGN(file_size, sizeof(int));
}
fd_out = open(argv[2], O_WRONLY | O_CREAT, 0666);
@@ -113,8 +111,8 @@ int main(int argc, char *argv[])
/* read file to buffer to calculate checksum */
lseek(fd_in, 0, SEEK_SET);
- count = read(fd_in, img.code, load_size);
- if (count != load_size) {
+ count = read(fd_in, img.code, file_size);
+ if (count != file_size) {
perror("Reading input image");
return EXIT_FAILURE;
}
@@ -126,7 +124,7 @@ int main(int argc, char *argv[])
& 0x00FF);
memcpy(img.header.magic, BOOT0_MAGIC, 8); /* no '0' termination */
img.header.length =
- ALIGN(load_size + sizeof(struct boot_file_head), BLOCK_SIZE);
+ ALIGN(file_size + sizeof(struct boot_file_head), BLOCK_SIZE);
gen_check_sum(&img.header);
count = write(fd_out, &img, img.header.length);
--
1.9.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] [PATCH u-boot-sunxi 2/4] mvtwsi: Fix clock programming
The TWSI_FREQUENCY macro was wrong in 2 ways: 1) It was casting the result of the calculations to an u8, while i2c clk rates are often >= 100Khz which won't fit in a u8, drop the cast. 2) It had an extra factor of 2 in the divider which neither the datasheet nor the Linux driver have. The comment for the default value was wrongly saying that m lives in bits 4-7, while in reality it is in bits 3-6, as can be seen from the correct shift by 3 used in i2c_init(). While at it remove the unused twsi_actual_speed variable. Signed-off-by: Hans de Goede --- drivers/i2c/mvtwsi.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c index 90c8387..b449443 100644 --- a/drivers/i2c/mvtwsi.c +++ b/drivers/i2c/mvtwsi.c @@ -216,7 +216,7 @@ static int twsi_stop(int status) */ #define TWSI_FREQUENCY(m, n) \ - ((u8) (CONFIG_SYS_TCLK / (10 * (m + 1) * 2 * (1 << n + (CONFIG_SYS_TCLK / (10 * (m + 1) * (1 << n))) /* * These are required to be reprogrammed before enabling the controller @@ -225,10 +225,8 @@ static int twsi_stop(int status) * twsi_slave_address left uninitialized lest checkpatch.pl complains. */ -/* Baudrate generator: m (bits 7..4) =4, n (bits 3..0) =4 */ +/* Baudrate generator: m (bits 6..3) = 8, n (bits 2..0) = 4 */ static u8 twsi_baud_rate = 0x44; /* baudrate at controller reset */ -/* Default frequency corresponding to default m=4, n=4 */ -static u8 twsi_actual_speed = TWSI_FREQUENCY(4, 4); /* Default slave address is 0 (so is an uninitialized static) */ static u8 twsi_slave_address; @@ -279,7 +277,6 @@ void i2c_init(int requested_speed, int slaveadd) } /* save baud rate and slave for later calls to twsi_reset */ twsi_baud_rate = baud; - twsi_actual_speed = highest_speed; twsi_slave_address = slaveadd; /* reset controller */ twsi_reset(); -- 1.9.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] [PATCH u-boot-sunxi 4/4] sunxi: Use existing mvtwsi code for i2c master
Sunxi uses the same i2c controller, so re-use the existing code instead of
having our own duplicate code.
Signed-off-by: Hans de Goede
---
arch/arm/cpu/armv7/sunxi/board.c | 1 +
arch/arm/include/asm/arch-sunxi/i2c.h | 164 +
board/sunxi/board.c | 7 +
drivers/i2c/Makefile | 2 +-
drivers/i2c/mvtwsi.c | 18 +++
drivers/i2c/sunxi_i2c.c | 260 --
include/configs/sunxi-common.h| 7 +-
7 files changed, 36 insertions(+), 423 deletions(-)
delete mode 100644 drivers/i2c/sunxi_i2c.c
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 8147a99..9e5aec2 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -106,6 +106,7 @@ void s_init(void)
clock_init();
timer_init();
gpio_init();
+ i2c_init_board();
#ifdef CONFIG_SPL_BUILD
gd = &gdata;
diff --git a/arch/arm/include/asm/arch-sunxi/i2c.h
b/arch/arm/include/asm/arch-sunxi/i2c.h
index 74c2d18..dc5406b 100644
--- a/arch/arm/include/asm/arch-sunxi/i2c.h
+++ b/arch/arm/include/asm/arch-sunxi/i2c.h
@@ -1,169 +1,15 @@
/*
- * (C) Copyright 2012 Henrik Nordstrom
- *
- * Based on sun4i linux kernle i2c.h
- * (C) Copyright 2007-2012
- * Allwinner Technology Co., Ltd.
- * Tom Cubie
- * Victor Wei
+ * Copyright 2014 - Hans de Goede
*
* SPDX-License-Identifier:GPL-2.0+
*/
#ifndef _SUNXI_I2C_H_
#define _SUNXI_I2C_H_
-struct i2c {
- u32 saddr; /* 31:8bit res,7-1bit for slave addr,0 bit for GCE */
- u32 xsaddr; /* 31:8bit res,7-0bit for second addr in 10bit addr */
- u32 data; /* 31:8bit res, 7-0bit send or receive data byte */
- u32 ctl;/* INT_EN,BUS_EN,M_STA,INT_FLAG,A_ACK */
- u32 status; /* 28 interrupt types + 0xf8 normal type = 29 */
- u32 clkr; /* 31:7bit res,6-3bit,CLK_M,2-0bit CLK_N */
- u32 reset; /* 31:1bit res;0bit,write 1 to clear 0. */
- u32 efr;/* 31:2bit res,1:0 bit data byte follow read comand */
- u32 lctl; /* 31:6bits res 5:0bit for sda&scl control */
-};
-
-/* TWI address register */
-#define TWI_GCE_EN (0x1 << 0) /* gen call addr enable slave mode */
-#define TWI_ADDR_MASK (0x7f << 1) /* 7:1bits */
-#define TWI_XADDR_MASK 0xff/* 7:0bits for extend slave address */
-
-#define TWI_DATA_MASK 0xff/* 7:0bits for send or received */
-
-/* TWI Control Register Bit Fields */
-/* 1:0 bits reserved */
-/* set 1 to send A_ACK,then low level on SDA */
-#define TWI_CTL_ACK(0x1 << 2)
-/* INT_FLAG,interrupt status flag: set '1' when interrupt coming */
-#define TWI_CTL_INTFLG (0x1 << 3)
-#define TWI_CTL_STP(0x1 << 4) /* M_STP,Automatic clear 0 */
-#define TWI_CTL_STA(0x1 << 5) /* M_STA,atutomatic clear 0 */
-#define TWI_CTL_BUSEN (0x1 << 6) /* BUS_EN, mastr mode should be set 1 */
-#define TWI_CTL_INTEN (0x1 << 7) /* INT_EN */
-/* 31:8 bit reserved */
-
-/*
- * TWI Clock Register Bit Fields & Masks,default value:0x_
- * Fin is APB CLOCK INPUT;
- * Fsample = F0 = Fin/2^CLK_N;
- * F1 = F0/(CLK_M+1);
- *
- * Foscl = F1/10 = Fin/(2^CLK_N * (CLK_M+1)*10);
- * Foscl is clock SCL;standard mode:100KHz or fast mode:400KHz
- */
-
-#define TWI_CLK_DIV_M (0xf << 3) /* 6:3bit */
-#define TWI_CLK_DIV_N (0x7 << 0) /* 2:0bit */
-#define TWI_CLK_DIV(N, M) N) & 0xf) << 3) | (((M) & 0x7) << 0))
-
-/* TWI Soft Reset Register Bit Fields & Masks */
-/* write 1 to clear 0, when complete soft reset clear 0 */
-#define TWI_SRST_SRST (0x1 << 0)
-
-/* TWI Enhance Feature Register Bit Fields & Masks */
-/* default -- 0x0 */
-/* 00:no,01: 1byte, 10:2 bytes, 11: 3bytes */
-#define TWI_EFR_MASK (0x3 << 0)
-#define TWI_EFR_WARC_0 (0x0 << 0)
-#define TWI_EFR_WARC_1 (0x1 << 0)
-#define TWI_EFR_WARC_2 (0x2 << 0)
-#define TWI_EFR_WARC_3 (0x3 << 0)
-
-/* twi line control register -default value: 0x_003a */
-/* SDA line state control enable ,1:enable;0:disable */
-#define TWI_LCR_SDA_EN (0x01 << 0)
-/* SDA line state control bit, 1:high level;0:low level */
-#define TWI_LCR_SDA_CTL(0x01 << 1)
-/* SCL line state control enable ,1:enable;0:disable */
-#define TWI_LCR_SCL_EN (0x01 << 2)
-/* SCL line state control bit, 1:high level;0:low level */
-#define TWI_LCR_SCL_CTL(0x01 << 3)
-/* current state of SDA,readonly bit */
-#define TWI_LCR_SDA_STATE_MASK (0x01 << 4)
-/* current state of SCL,readonly bit */
-#define TWI_LCR_SCL_STATE_MASK (0x01 << 5)
-/* 31:6bits reserved */
-#define TWI_LCR_IDLE_STATUS0x3a
-
-/* TWI Status Register Bit Fields & Masks */
-#define TWI_STAT_MASK 0xff
-/* 7:0 bits use only,default is 0xf8 */
-#define TWI_STAT_BUS_ERR 0x00/* BUS ERROR */
-
-/* Master mode
[linux-sunxi] Re: [U-Boot] [PATCH u-boot sunxi 07/12] sunxi: Add i2c support
Hi,
On 03/18/2014 08:54 AM, Heiko Schocher wrote:
> Hello Hans,
>
> Am 18.03.2014 00:00, schrieb Hans de Goede:
>> From: Henrik Nordstrom
>>
>> Based linux-sunxi#sunxi commit d854c4de2f57 "arm: Handle .gnu.hash section in
>> ldscripts" vs v2014.01.
>>
>> As well as the following signed-off-by the sunxi branch shows commits to
>> the sunxi_i2c.c file by:
>>
>> Stefan Roese
>>
>> Signed-off-by: Henrik Nordstrom
>> Signed-off-by: Oliver Schinagl
>> Signed-off-by: Hans de Goede
>> ---
>> arch/arm/cpu/armv7/sunxi/board.c | 6 +
>> arch/arm/include/asm/arch-sunxi/i2c.h | 169 ++
>> drivers/i2c/Makefile | 1 +
>> drivers/i2c/sunxi_i2c.c | 260
>> ++
>> include/configs/sunxi-common.h| 8 ++
>> 5 files changed, 444 insertions(+)
>> create mode 100644 arch/arm/include/asm/arch-sunxi/i2c.h
>> create mode 100644 drivers/i2c/sunxi_i2c.c
>>
> [...]
>> diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
>> index fa3a875..2a44db4 100644
>> --- a/drivers/i2c/Makefile
>> +++ b/drivers/i2c/Makefile
>> @@ -15,6 +15,7 @@ obj-$(CONFIG_PCA9564_I2C) += pca9564_i2c.o
>> obj-$(CONFIG_TSI108_I2C) += tsi108_i2c.o
>> obj-$(CONFIG_U8500_I2C) += u8500_i2c.o
>> obj-$(CONFIG_SH_SH7734_I2C) += sh_sh7734_i2c.o
>> +obj-$(CONFIG_SUNXI_I2C) += sunxi_i2c.o
>
> please use:
>
> CONFIG_SYS_I2C_SUNXI
Ok.
>
>> obj-$(CONFIG_SYS_I2C) += i2c_core.o
>> obj-$(CONFIG_SYS_I2C_FSL) += fsl_i2c.o
>> obj-$(CONFIG_SYS_I2C_FTI2C010) += fti2c010.o
>> diff --git a/drivers/i2c/sunxi_i2c.c b/drivers/i2c/sunxi_i2c.c
>> new file mode 100644
>> index 000..9a542f6
>> --- /dev/null
>> +++ b/drivers/i2c/sunxi_i2c.c
>> @@ -0,0 +1,260 @@
>> +/*
>> + * (C) Copyright 2012 Henrik Nordstrom
>> + *
>> + * SPDX-License-Identifier:GPL-2.0+
>> + */
>> +
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +#include
>> +
>> +static struct i2c __attribute__ ((section(".data"))) *i2c_base =
>> +(struct i2c *)0x1c2ac00;
>
> Please no magic numbers, use a define instead.
>
>> +void i2c_init(int speed, int slaveaddr)
> [...]
>> +int i2c_write(uchar chip, uint addr, int alen, uchar *buffer, int len)
>> +{
>> +int rc = i2c_do_write(chip, addr, alen, buffer, len);
>> +
>> +i2c_stop();
>> +
>> +return rc;
>> +}
>
> Please update to the new i2c multibus/multiadpater framework
>
> Dummy question, there is another "twi" driver in drivers/i2c
>
> bfin-twi_i2c.c
>
> are they compatible?
No, but that is a good point, in the kernel we ended up using the
i2c-mv64xxx driver as that is the same controller. I should have thought
of doing the same for u-boot instead of just taking Allwinner's driver.
I've just completed writing a patch-set which uses the mvtwsi driver
instead of introducing a new driver. While working on this I found 2 issues
in the driver, for which I'll be sending patches shortly.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v5 8/8] ARM: sun7i/sun4i: dt: Add AXP209 support to various boards
On Sat, May 3, 2014 at 3:09 AM, Maxime Ripard
wrote:
> Hi,
>
> On Thu, May 01, 2014 at 02:29:34PM +0200, Carlo Caione wrote:
>> Signed-off-by: Hans de Goede
>> Signed-off-by: Carlo Caione
>> ---
>> arch/arm/boot/dts/sun4i-a10-a1000.dts | 58 ++
>> arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 58 ++
>> arch/arm/boot/dts/sun4i-a10-hackberry.dts | 64
>>
>> arch/arm/boot/dts/sun4i-a10-inet97fv2.dts | 58 ++
>> arch/arm/boot/dts/sun4i-a10-mini-xplus.dts | 65
>> +
>> arch/arm/boot/dts/sun4i-a10-olinuxino-lime.dts | 64
>>
>> arch/arm/boot/dts/sun4i-a10-pcduino.dts | 58 ++
>> arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 59 ++
>> arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 59 ++
>> arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 59 ++
>> 10 files changed, 602 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> b/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> index fa746aea..57d3fb4 100644
>> --- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> +++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
>> @@ -88,6 +88,56 @@
>> pinctrl-names = "default";
>> pinctrl-0 = <&i2c0_pins_a>;
>> status = "okay";
>> +
>> + axp209: pmic@34 {
>> + compatible = "x-powers,axp209";
>> + reg = <0x34>;
>> + interrupts = <0>;
>> +
>> + interrupt-controller;
>> + #interrupt-cells = <1>;
>> +
>> + acin-supply = <®_axp_ipsout>;
>> + vin2-supply = <®_axp_ipsout>;
>> + vin3-supply = <®_axp_ipsout>;
>> + ldo24in-supply = <®_axp_ipsout>;
>> + ldo3in-supply = <®_axp_ipsout>;
>> + ldo5in-supply = <®_axp_ipsout>;
>> +
>> + regulators {
>> + x-powers,dcdc-freq = <1500>;
>> +
>> + axp_vcore_reg: dcdc2 {
>> + regulator-min-microvolt =
>> <70>;
>> + regulator-max-microvolt =
>> <2275000>;
>> + regulator-always-on;
>> + };
>> +
>> + axp_ddr_reg: dcdc3 {
>> + regulator-always-on;
>> + };
>> +
>> + axp_rtc_reg: ldo1 {
>> + regulator-always-on;
>> + };
>> +
>> + axp_analog_reg: ldo2 {
>> + regulator-always-on;
>> + };
>> +
>> + axp_pll_reg: ldo3 {
>> + regulator-always-on;
>> + };
>> +
>> + axp_hdmi_reg: ldo4 {
>> + regulator-always-on;
>> + };
>> +
>> + axp_mic_reg: ldo5 {
>> + regulator-always-on;
>
> Do all these regulators need to be always on? It makes sense for the
> pll and vcore, but I don't get why the mic and hdmi regulators need
> this.
I did this way because I don't have the schematics for all the board
so I thought it was safer to leave all the regulators enabled
--
Carlo Caione
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH] sunxi: fix SRAM_B/SRAM_D memory map
Hi, Thanks, I've applied and pushed all 3 patches. Regards, Hans On 05/02/2014 09:12 PM, Ian Campbell wrote: > From: Marc Zyngier > > Move the B and D SRAM bank to their actual location (or at least > where the documentation pretends they are). > > Signed-off-by: Marc Zyngier > Signed-off-by: Ian Campbell > --- > Reposting since this patch from Marc since it is wanted for the upstream > version. I've confirmed the addresses in both A10 and A20 manuals > --- > arch/arm/include/asm/arch-sunxi/cpu.h | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/include/asm/arch-sunxi/cpu.h > b/arch/arm/include/asm/arch-sunxi/cpu.h > index 9285181..359ff67 100644 > --- a/arch/arm/include/asm/arch-sunxi/cpu.h > +++ b/arch/arm/include/asm/arch-sunxi/cpu.h > @@ -15,8 +15,8 @@ > #define SUNXI_SRAM_A2_BASE 0x4000 /* 16 kiB */ > #define SUNXI_SRAM_A3_BASE 0x8000 /* 13 kiB */ > #define SUNXI_SRAM_A4_BASE 0xb400 /* 3 kiB */ > -#define SUNXI_SRAM_D_BASE0x01c0 > -#define SUNXI_SRAM_B_BASE0x01c0 /* 64 kiB (secure) */ > +#define SUNXI_SRAM_D_BASE0x0001 /* 4 kiB */ > +#define SUNXI_SRAM_B_BASE0x0002 /* 64 kiB (secure) */ > > #define SUNXI_SRAMC_BASE 0x01c0 > #define SUNXI_DRAMC_BASE 0x01c01000 > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH u-boot-sunxi] sunxi: dram: Tweak DEFE port setup to fix A10 screen shaking issue
Thanks,
applied and pushed.
Regards,
Hans
On 04/27/2014 08:50 PM, Siarhei Siamashka wrote:
> When driving a 1920x1080-32@60Hz monitor, framebuffer scanout for
> screen refresh becomes more bandwidth intensive and challening.
> There used to be an old problem, which manifested itself as a
> screen shaking effect when CPU or GPU are doing something memory
> intensive and competing for the memory bandwidth with the display
> controller. A possible explanation for it is that the display
> controller just sends the previous scanline over HDMI in the case
> if it can't read the current one in time.
>
> Framebuffer scanout can be done either by DEBE or by DEFE. It seems
> like DEBE is broken beyond repair. Apparently it is doing isolated
> 32 byte burst reads at regular intervals to scan out the framebuffer
> and send this data over HDMI. The size of this burst is too small.
> And if something else (CPU or GPU) is accessing memory at the same
> time, we easily get bank conflicts with huge penalties. As these
> penalties happen per 32 bytes of data, most of the memory bandwidth
> is wasted. The end result is the screen shaking effect and a
> significant performance loss for the CPU/GPU. This all is happening
> because DEBE is configured to have higher priority than CPU and GPU.
> So it can do these tiny bursts and nobody can do anything about it.
> If we reduce the priority of DEBE, then the screen shaking effect
> becomes much worse.
>
> DEFE is somewhat similar to DEBE. But the key difference is that
> it seems to implement some buffering of data and this buffer does
> not underrun so easily. So it is possible to drop the priority
> of DEFE port and make it the same as CPU/GPU. However in order to
> get really perfect results, we need to also increase the "host port
> command number" parameter. It is currently set to 0x10 by default
> (the same as for CPU and GPU) and from what it looks, it affects
> the bandwidth distribution between the ports with equal priority.
> To experiment with this, I took A10-OLinuXino-LIME board (which
> has a slow 16-bit memory interface) and downclocked DRAM to 408MHz.
> Then used lima-memtester and glmark2-es2 programs to reproduce the
> screen shaking effect. Increasing the "host port command number"
> parameter resulted in a gradual reduction of the image glitches.
> And at 0x50, the shaking effect disappeared completely.
>
> So all that we need to do is a simple change "0x1035 -> 0x5031"
> for the DEFE host port setup. And even A10-OLinuXino-LIME becomes
> able to drive a FullHD monitor at 60Hz and 32bpp without issues
> if "fb0_scaler_mode_enable" is set to 1 in the fex file.
>
> Additionally, for A10-OLinuXino-LIME with DRAM clocked at 480MHz
> and driving a 1920x1080-32@60Hz monitor in "scaler" mode, the
> memset performance improves from 559.3 MB/s to 807.3 MB/s and
> the memcpy performance improves from 299.3 MB/s to 317.9 MB/s
> after this patch. So the memory bandwidth drain becomes smaller
> the the overall system performance improves.
>
> This has been also discussed at:
> https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg04085.html
>
> Signed-off-by: Siarhei Siamashka
> ---
> arch/arm/cpu/armv7/sunxi/dram.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv7/sunxi/dram.c b/arch/arm/cpu/armv7/sunxi/dram.c
> index caf94e9..09bde09 100644
> --- a/arch/arm/cpu/armv7/sunxi/dram.c
> +++ b/arch/arm/cpu/armv7/sunxi/dram.c
> @@ -157,7 +157,7 @@ static u32 hpcr_value[32] = {
> 0x0301, 0x0301, 0, 0,
> 0, 0, 0, 0,
> 0, 0, 0, 0,
> - 0x1031, 0x1031, 0x0735, 0x1035,
> + 0x1031, 0x1031, 0x0735, 0x5031,
> 0x1035, 0x0731, 0x1031, 0x0735,
> 0x1035, 0x1031, 0x0731, 0x1035,
> 0x1031, 0x0301, 0x0301, 0x0731
>
--
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.
