Re: [linux-sunxi] Re: [PATCH 3.4 00/11] sunxi-disp: hotplug + dpms support
No worries, thanks for the reply. Phil On Tue, Jan 28, 2014 at 3:57 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/27/2014 10:28 PM, Phil Scull wrote: Hans, I still have trouble getting the HDMI monitor to come out of suspend running linaro on CT. Removing the lines that switch the clock off and back on again seems to sort the problem. There is probably a deeper underlying issue tho. Interested if you have any thoughts. I don't have any insights on this I'm afraid. Regards, Hans -- You received this message because you are subscribed to a topic in the Google Groups linux-sunxi group. To unsubscribe from this topic, visit https://groups.google.com/d/ topic/linux-sunxi/XuJweI-19s0/unsubscribe. To unsubscribe from this group and all of its topics, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [RFC PATCH 0/9] mtd: nand: add sunxi NAND Flash Controller support
Hello Rob, On 23/01/2014 16:22, Rob Herring wrote: On Sat, Jan 11, 2014 at 7:38 AM, boris brezillon b.brezil...@overkiz.com wrote: On 08/01/2014 15:21, Boris BREZILLON wrote: Hello, This series add the sunxi NFC support with up to 8 NAND chip connected. I'm still in the early stages drivers development and some key features are missing, but it's usable (I tested it on the cubietruck board). Here's what's missing: - HW ECC support - DMA support - HW randomization support - many more improvements This series depends on Emilio's patch series implementing mod0 clks (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185478.html) + an other patch not yet posted (http://git.elopez.com.ar/linux/commits/5b4eb3ac406b9c98965714d40e8dd6da943d1ab0) During my reasearch regarding the HW ECC and HW randomizer of the Allwinner NAND flash controller I found this document describing the Altera NAND flash controller (which is in turn based on a cadence IP): Which may be similar to drivers/mtd/nand/denali.c as Cadence bought Denali? Actually I was wrong, the sunxi and the cadence IP have nothing in common. This was pointed out by Henrik (see this thread : https://groups.google.com/forum/#!searchin/linux-sunxi/nand/linux-sunxi/x69tFBi95Zk/bNyJlWWOV8oJ https://groups.google.com/forum/#%21searchin/linux-sunxi/nand/linux-sunxi/x69tFBi95Zk/bNyJlWWOV8oJ). Sorry for the false hopes. Best Regards, Boris Rob -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [RFC PATCH 1/9] mtd: nand: retrieve ECC requirements from Hynix READ ID byte 4
Hello Brian, On 23/01/2014 02:49, Brian Norris wrote: + Huang Hi Boris, On Wed, Jan 08, 2014 at 03:21:56PM +0100, Boris BREZILLON wrote: The Hynix nand flashes store their ECC requirements in byte 4 of its id (returned on READ ID command). Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com I haven't verified yet (perhaps Huang can confirm?), but this may be similar to a patch Huang submitted recently. In his case, we found that this table is actually quite unreliable and is likely hard to maintain. You mean these bytes are not reliable within the whole Hynix LP (Large Page) NAND product line ? Why do you need this ECC information, for my reference? Because the NAND flash available on the cubietruck board does not support the ONFI standard, and I thought this could be a option to retrieve the ECC strength requirements. Anyway, I added a new helper function to retrieve ecc informations from device tree (I'll post it in the 2nd version of this series). We'll see if this approach is accepted... Brian -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH v2 2/5] ARM: sun6i: dt: Add PLL6 and SPI module clocks
The module clocks in the A31 are still compatible with the A10 one. Add the SPI
module clocks and the PLL6 in the device tree to allow their use by the SPI
controllers.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 46
1 file changed, 37 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 5256ad9..0eea325 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -73,16 +73,12 @@
clocks = osc24M;
};
- /*
-* This is a dummy clock, to be used as placeholder on
-* other mux clocks when a specific parent clock is not
-* yet implemented. It should be dropped when the driver
-* is complete.
-*/
- pll6: pll6 {
+ pll6: clk@01c20028 {
#clock-cells = 0;
- compatible = fixed-clock;
- clock-frequency = 0;
+ compatible = allwinner,sun6i-a31-pll6-clk;
+ reg = 0x01c20028 0x4;
+ clocks = osc24M;
+ clock-output-names = pll6;
};
cpu: cpu@01c20050 {
@@ -182,6 +178,38 @@
apb2_uart1, apb2_uart2,
apb2_uart3,
apb2_uart4, apb2_uart5;
};
+
+ spi0_clk: clk@01c200a0 {
+ #clock-cells = 0;
+ compatible = allwinner,sun4i-mod0-clk;
+ reg = 0x01c200a0 0x4;
+ clocks = osc24M, pll6;
+ clock-output-names = spi0;
+ };
+
+ spi1_clk: clk@01c200a4 {
+ #clock-cells = 0;
+ compatible = allwinner,sun4i-mod0-clk;
+ reg = 0x01c200a4 0x4;
+ clocks = osc24M, pll6;
+ clock-output-names = spi1;
+ };
+
+ spi2_clk: clk@01c200a8 {
+ #clock-cells = 0;
+ compatible = allwinner,sun4i-mod0-clk;
+ reg = 0x01c200a8 0x4;
+ clocks = osc24M, pll6;
+ clock-output-names = spi2;
+ };
+
+ spi3_clk: clk@01c200ac {
+ #clock-cells = 0;
+ compatible = allwinner,sun4i-mod0-clk;
+ reg = 0x01c200ac 0x4;
+ clocks = osc24M, pll6;
+ clock-output-names = spi3;
+ };
};
soc@01c0 {
--
1.8.4.2
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH v2 4/5] ARM: sun6i: dt: Add SPI controllers to the A31 DTSI
The A31 has 4 SPI controllers. Add them in the DTSI.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
arch/arm/boot/dts/sun6i-a31.dtsi | 40
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 0eea325..57af66f 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -340,6 +340,46 @@
status = disabled;
};
+ spi0: spi@01c68000 {
+ compatible = allwinner,sun6i-a31-spi;
+ reg = 0x01c68000 0x1000;
+ interrupts = 0 65 4;
+ clocks = ahb1_gates 20, spi0_clk;
+ clock-names = ahb, mod;
+ resets = ahb1_rst 20;
+ status = disabled;
+ };
+
+ spi1: spi@01c69000 {
+ compatible = allwinner,sun6i-a31-spi;
+ reg = 0x01c69000 0x1000;
+ interrupts = 0 66 4;
+ clocks = ahb1_gates 21, spi1_clk;
+ clock-names = ahb, mod;
+ resets = ahb1_rst 21;
+ status = disabled;
+ };
+
+ spi2: spi@01c6a000 {
+ compatible = allwinner,sun6i-a31-spi;
+ reg = 0x01c6a000 0x1000;
+ interrupts = 0 67 4;
+ clocks = ahb1_gates 22, spi2_clk;
+ clock-names = ahb, mod;
+ resets = ahb1_rst 22;
+ status = disabled;
+ };
+
+ spi3: spi@01c6b000 {
+ compatible = allwinner,sun6i-a31-spi;
+ reg = 0x01c6b000 0x1000;
+ interrupts = 0 68 4;
+ clocks = ahb1_gates 23, spi3_clk;
+ clock-names = ahb, mod;
+ resets = ahb1_rst 23;
+ status = disabled;
+ };
+
gic: interrupt-controller@01c81000 {
compatible = arm,cortex-a7-gic, arm,cortex-a15-gic;
reg = 0x01c81000 0x1000,
--
1.8.4.2
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH v2 1/5] clk: sunxi: Add support for PLL6 on the A31
The A31 has a slightly different PLL6 clock. Add support for this new clock in
our driver.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
drivers/clk/sunxi/clk-sunxi.c | 45 +++
2 files changed, 46 insertions(+)
diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
b/Documentation/devicetree/bindings/clock/sunxi.txt
index c2cb762..954845c 100644
--- a/Documentation/devicetree/bindings/clock/sunxi.txt
+++ b/Documentation/devicetree/bindings/clock/sunxi.txt
@@ -11,6 +11,7 @@ Required properties:
allwinner,sun6i-a31-pll1-clk - for the main PLL clock on A31
allwinner,sun4i-pll5-clk - for the PLL5 clock
allwinner,sun4i-pll6-clk - for the PLL6 clock
+ allwinner,sun6i-a31-pll6-clk - for the PLL6 clock on A31
allwinner,sun4i-cpu-clk - for the CPU multiplexer clock
allwinner,sun4i-axi-clk - for the AXI clock
allwinner,sun4i-axi-gates-clk - for the AXI gates
diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
index 659e4ea..990ad5d 100644
--- a/drivers/clk/sunxi/clk-sunxi.c
+++ b/drivers/clk/sunxi/clk-sunxi.c
@@ -249,7 +249,38 @@ static void sun4i_get_pll5_factors(u32 *freq, u32
parent_rate,
*n = DIV_ROUND_UP(div, (*k+1));
}
+/**
+ * sun6i_a31_get_pll6_factors() - calculates n, k factors for A31 PLL6
+ * PLL6 rate is calculated as follows
+ * rate = parent_rate * n * (k + 1) / 2
+ * parent_rate is always 24Mhz
+ */
+
+static void sun6i_a31_get_pll6_factors(u32 *freq, u32 parent_rate,
+ u8 *n, u8 *k, u8 *m, u8 *p)
+{
+ u8 div;
+
+ /*
+* We always have 24MHz / 2, so we can just say that our
+* parent clock is 12MHz.
+*/
+ parent_rate = parent_rate / 2;
+
+ /* Normalize value to a parent_rate multiple (24M / 2) */
+ div = *freq / parent_rate;
+ *freq = parent_rate * div;
+
+ /* we were called to round the frequency, we can now return */
+ if (n == NULL)
+ return;
+
+ *k = div / 32;
+ if (*k 3)
+ *k = 3;
+ *n = DIV_ROUND_UP(div, (*k+1));
+}
/**
* sun4i_get_apb1_factors() - calculates m, p factors for APB1
@@ -416,6 +447,13 @@ static struct clk_factors_config sun4i_pll5_config = {
.kwidth = 2,
};
+static struct clk_factors_config sun6i_a31_pll6_config = {
+ .nshift = 8,
+ .nwidth = 5,
+ .kshift = 4,
+ .kwidth = 2,
+};
+
static struct clk_factors_config sun4i_apb1_config = {
.mshift = 0,
.mwidth = 5,
@@ -457,6 +495,12 @@ static const struct factors_data sun4i_pll5_data
__initconst = {
.getter = sun4i_get_pll5_factors,
};
+static const struct factors_data sun6i_a31_pll6_data __initconst = {
+ .enable = 31,
+ .table = sun6i_a31_pll6_config,
+ .getter = sun6i_a31_get_pll6_factors,
+};
+
static const struct factors_data sun4i_apb1_data __initconst = {
.table = sun4i_apb1_config,
.getter = sun4i_get_apb1_factors,
@@ -972,6 +1016,7 @@ free_clkdata:
static const struct of_device_id clk_factors_match[] __initconst = {
{.compatible = allwinner,sun4i-pll1-clk, .data = sun4i_pll1_data,},
{.compatible = allwinner,sun6i-a31-pll1-clk, .data =
sun6i_a31_pll1_data,},
+ {.compatible = allwinner,sun6i-a31-pll6-clk, .data =
sun6i_a31_pll6_data,},
{.compatible = allwinner,sun4i-apb1-clk, .data = sun4i_apb1_data,},
{.compatible = allwinner,sun4i-mod0-clk, .data = sun4i_mod0_data,},
{.compatible = allwinner,sun7i-a20-out-clk, .data =
sun7i_a20_out_data,},
--
1.8.4.2
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH v2 5/5] ARM: sunxi: Enable A31 SPI and SID in the defconfig
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com --- arch/arm/configs/sunxi_defconfig | 3 +++ 1 file changed, 3 insertions(+) diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig index 3e2259b..b5df4a5 100644 --- a/arch/arm/configs/sunxi_defconfig +++ b/arch/arm/configs/sunxi_defconfig @@ -24,6 +24,7 @@ CONFIG_IP_PNP_BOOTP=y # CONFIG_WIRELESS is not set CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y +CONFIG_EEPROM_SUNXI_SID=y CONFIG_NETDEVICES=y CONFIG_SUN4I_EMAC=y # CONFIG_NET_CADENCE is not set @@ -48,6 +49,8 @@ CONFIG_I2C=y # CONFIG_I2C_COMPAT is not set CONFIG_I2C_CHARDEV=y CONFIG_I2C_MV64XXX=y +CONFIG_SPI=y +CONFIG_SPI_SUN6I=y CONFIG_GPIO_SYSFS=y # CONFIG_HWMON is not set CONFIG_WATCHDOG=y -- 1.8.4.2 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
The Allwinner A31 has a new SPI controller IP compared to the older Allwinner
SoCs.
It supports DMA, but the driver only does PIO for now, and DMA will be
supported eventually.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
.../devicetree/bindings/spi/spi-sun6i.txt | 24 ++
drivers/spi/Kconfig| 7 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-sun6i.c| 478 +
4 files changed, 510 insertions(+)
create mode 100644 Documentation/devicetree/bindings/spi/spi-sun6i.txt
create mode 100644 drivers/spi/spi-sun6i.c
diff --git a/Documentation/devicetree/bindings/spi/spi-sun6i.txt
b/Documentation/devicetree/bindings/spi/spi-sun6i.txt
new file mode 100644
index 000..21de73d
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/spi-sun6i.txt
@@ -0,0 +1,24 @@
+Allwinner A31 SPI controller
+
+Required properties:
+- compatible: Should be allwinner,sun6i-a31-spi.
+- reg: Should contain register location and length.
+- interrupts: Should contain interrupt.
+- clocks: phandle to the clocks feeding the SPI controller. Two are
+ needed:
+ - ahb: the gated AHB parent clock
+ - mod: the parent module clock
+- clock-names: Must contain the clock names described just above
+- resets: phandle to the reset controller asserting this device in
+ reset
+
+Example:
+
+spi1: spi@01c69000 {
+ compatible = allwinner,sun6i-a31-spi;
+ reg = 0x01c69000 0x1000;
+ interrupts = 0 66 4;
+ clocks = ahb1_gates 21, spi1_clk;
+ clock-names = ahb, mod;
+ resets = ahb1_rst 21;
+};
diff --git a/drivers/spi/Kconfig b/drivers/spi/Kconfig
index eb1f1ef..004e3b0 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -438,6 +438,13 @@ config SPI_SIRF
help
SPI driver for CSR SiRFprimaII SoCs
+config SPI_SUN6I
+ tristate Allwinner A31 SPI controller
+ depends on ARCH_SUNXI || COMPILE_TEST
+ select PM_RUNTIME
+ help
+ This enables using the SPI controller on the Allwinner A31 SoCs.
+
config SPI_MXS
tristate Freescale MXS SPI controller
depends on ARCH_MXS
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index ab8d864..658ec64 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -69,6 +69,7 @@ obj-$(CONFIG_SPI_SH_HSPI) += spi-sh-hspi.o
obj-$(CONFIG_SPI_SH_MSIOF) += spi-sh-msiof.o
obj-$(CONFIG_SPI_SH_SCI) += spi-sh-sci.o
obj-$(CONFIG_SPI_SIRF) += spi-sirf.o
+obj-$(CONFIG_SPI_SUN6I)+= spi-sun6i.o
obj-$(CONFIG_SPI_TEGRA114) += spi-tegra114.o
obj-$(CONFIG_SPI_TEGRA20_SFLASH) += spi-tegra20-sflash.o
obj-$(CONFIG_SPI_TEGRA20_SLINK)+= spi-tegra20-slink.o
diff --git a/drivers/spi/spi-sun6i.c b/drivers/spi/spi-sun6i.c
new file mode 100644
index 000..32f3fc7
--- /dev/null
+++ b/drivers/spi/spi-sun6i.c
@@ -0,0 +1,478 @@
+/*
+ * Copyright (C) 2012 - 2014 Allwinner Tech
+ * Pan Nan pan...@allwinnertech.com
+ *
+ * Copyright (C) 2014 Maxime Ripard
+ * Maxime Ripard maxime.rip...@free-electrons.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#include linux/clk.h
+#include linux/delay.h
+#include linux/device.h
+#include linux/interrupt.h
+#include linux/io.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/pm_runtime.h
+#include linux/reset.h
+#include linux/workqueue.h
+
+#include linux/spi/spi.h
+
+#define SUN6I_FIFO_DEPTH 128
+
+#define SUN6I_GBL_CTL_REG 0x04
+#define SUN6I_GBL_CTL_BUS_ENABLE BIT(0)
+#define SUN6I_GBL_CTL_MASTER BIT(1)
+#define SUN6I_GBL_CTL_TP BIT(7)
+#define SUN6I_GBL_CTL_RST BIT(31)
+
+#define SUN6I_TFR_CTL_REG 0x08
+#define SUN6I_TFR_CTL_CPHA BIT(0)
+#define SUN6I_TFR_CTL_CPOL BIT(1)
+#define SUN6I_TFR_CTL_SPOL BIT(2)
+#define SUN6I_TFR_CTL_CS_MASK 0x3
+#define SUN6I_TFR_CTL_CS(cs) (((cs) SUN6I_TFR_CTL_CS_MASK)
4)
+#define SUN6I_TFR_CTL_DHB BIT(8)
+#define SUN6I_TFR_CTL_FBS BIT(12)
+#define SUN6I_TFR_CTL_XCH BIT(31)
+
+#define SUN6I_INT_CTL_REG 0x10
+#define SUN6I_INT_CTL_RF_OVF BIT(8)
+#define SUN6I_INT_CTL_TC BIT(12)
+
+#define SUN6I_INT_STA_REG 0x14
+
+#define SUN6I_FIFO_CTL_REG 0x18
+#define SUN6I_FIFO_CTL_RF_RST BIT(15)
+#define SUN6I_FIFO_CTL_TF_RST BIT(31)
+
+#define SUN6I_FIFO_STA_REG 0x1c
Re: [linux-sunxi] pio tool usage message is bogus
On 28 January 2014 16:56, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/28/2014 02:29 PM, Michal Suchanek wrote: Hello, I have the sauce so I can presumably rip out the useful parts and make own tool but here is what I get with pio: root@A13:/sunxi-tools# ./pio print usage: ./pio [-m|-i input] [-o output] pin.. printShow all pins PxxShow pin PxxmodepulldrivedataConfigure pin Pxx=data,driveConfigure GPIO output Pxx*countOscillate GPIO output (mmap mode only) Pxx?pullConfigure GPIO input cleanClean input pins mode 0-7, 0=input, 1=ouput, 2-7 I/O function pull 0=none, 1=up, 2=down drive 0-3, I/O drive level root@A13:/sunxi-tools# ./pio PF02 usage: ./pio [-m|-i input] [-o output] pin.. printShow all pins PxxShow pin PxxmodepulldrivedataConfigure pin Pxx=data,driveConfigure GPIO output Pxx*countOscillate GPIO output (mmap mode only) Pxx?pullConfigure GPIO input cleanClean input pins mode 0-7, 0=input, 1=ouput, 2-7 I/O function pull 0=none, 1=up, 2=down drive 0-3, I/O drive level pio was orignally written to work on mem-dumps, use -m to make it open /dev/mem and directly read / write the real pio settings. That's not what the usage message says. It says nothing at all bout those arguments, actually. And it shows all arguments except pins a s optional but it does not work when neither input file nor mmap is specified. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] sun5i serial driver kills serial output
Hello, I found the problem. I had different settings for debug uart and uart 0. The ones for debug uart worked and when uart0 got initialized it broke. Thanks Michal On 27 January 2014 14:48, Olliver Schinagl oliver+l...@schinagl.nl wrote: On 27-01-14 13:38, jonsm...@gmail.com wrote: Are you running the Fedora image? console doesn't work for me on the Fedora image but it works fine on a Linaro image. I haven't checked but Fedora image probably isn't starting getty on the console. Can't even interact with u-boot etc oliver On Mon, Jan 27, 2014 at 5:23 AM, Olliver Schinagl oliver+l...@schinagl.nl wrote: On 26-01-14 21:50, Michal Suchanek wrote: Hello, I set up a13 with the SD breakout board and while u-boot console and early kernel messages show fine initializing the sunxi serial driver stops any kernel messages from appearing. Disabling the serial driver in script.bin solves the issue but does not allow for communicating with the Linux system over the serial port. Anyone else is seeing such issue? Yes, I noticed the exact same thing on an A13 tablet, it was spewing all the debug stuff as usual, but wouldn't respond to input. I wasn't overly interested so gave up, this was using the mUSB breakout board. oliver Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
On Wed, Jan 29, 2014 at 12:10:48PM +0100, Maxime Ripard wrote:
+config SPI_SUN6I
+ tristate Allwinner A31 SPI controller
+ depends on ARCH_SUNXI || COMPILE_TEST
+ select PM_RUNTIME
+ help
+ This enables using the SPI controller on the Allwinner A31 SoCs.
+
A select of PM_RUNTIME is both surprising and odd - why is that there?
The usual idiom is that the device starts out powered up (flagged using
pm_runtime_set_active()) and then runtime PM then suspends it when it's
compiled in. That way if for some reason people want to avoid runtime
PM they can still use the device.
+static void sun6i_spi_set_cs(struct spi_device *spi, bool enable)
+{
+ struct sun6i_spi *sspi = spi_master_get_devdata(spi-master);
+ u32 reg;
+
+ if (!enable)
+ return;
+
+ reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+ reg = ~SUN6I_TFR_CTL_CS_MASK;
+ reg |= SUN6I_TFR_CTL_CS(spi-chip_select);
+ sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
+}
The !enable means that it'll only ever be able to go one way. Also note
that the documentation was clarified here to make the enable flag be the
absolute logic level, not if chip select was asserted.
+ timeout = wait_for_completion_timeout(sspi-done,
+ msecs_to_jiffies(1000));
+ if (!timeout) {
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
+ sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
This means we can only transfer a single FIFO of data? I didn't see a
check on the transfer length.
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH v3 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
On Tue, Jan 28, 2014 at 10:02:46PM +0100, Carlo Caione wrote: Hi, On Tue, Jan 28, 2014 at 5:41 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: Hi, On Tue, Jan 28, 2014 at 12:02:23PM +0100, Hans de Goede wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 01/28/2014 11:40 AM, Maxime Ripard wrote: Jumping in here to try and clarify things, or so I hope at least :) Sure :) No, the IRQ from the PMIC is a level sensitive IRQ, so it would look like this: Hmm, your mailer seems to have mangled your drawing :( The PMIC irq line won't go low until an i2c write to its irq status registers write-clears all status bits for which the corresponding bit in the irq-mask register is set. Which makes sense too And the only reason the NMI - GIC also goes low is because the unmask operation writes a second ack to the NMI controller in the unmask callback of the NMI controller driver. Yes, and this is exactly what I don't understand. You shouldn't need that ack in first place, since it's been done already right after the unmask. But the first ack is ignored since the IRQ line is still maintained asserted by PMIC. Note that we cannot use edge triggered interrupts here because the PMIC has the typical setup with multiple irq status bits driving a single irq line, so the irq handler does read irq-status, handle stuff, write-clear irq-status. And if any other irq-status bits get set between the read and write-clear the PMIC - NMI line will stay high, as it should since there are more interrupts to handle. Yep, the edge-thing was just the only case I could think of where it could lead to troubles. In what you're saying, which makes total sense, if we don't do the ack, as soon as the irq will be unmasked, since the level is high, the handler will be called again, treat the new interrupts, and so on. I don't see how this is an issue actually. This is exactly why in unmask callback we first ACK and then unmask. So, if the line is still maintained up by PMIC then a new interrupt is raised otherwise nothing happens. But in this case, you would have two events coming from your device (the two rising edges), so you'd expect two interrupts. And in the case of a level triggered interrupt, the device would keep the interrupt line active until it's unmasked, so we wouldn't end up with this either. sunxi_sc_nmi_ack_and_unmask is therefore called (by irq_finalize_oneshot) after the IRQ thread has been executed. After the IRQ thread has ACKed the IRQs on the originating device we can finally ACK and unmask again the NMI. And what happens if you get a new interrupt right between the end of the handler and the unmask? The implicit ack done by the unmask will be ignored if the NMI line is still high, just like the initial ack is ignored (which is why we need the mask), and when the unmask completes the irq will immediately retrigger, as it should. Yeah, but why do we need the ack in the first place? I can't think of a case where the ACK would be doing something useful. Either: - there is no new interrupts between the mask/ack and the unmask, so there's no interrupt to ack. - There's a new interrupt between the mask/ack and the unmask. There's two more cases here: * The interrupt came before the device handler kicked in, and the handler will treat it/ack it: No issue * The interrupt comes right after the handler has been acking its interrupt, the level stays high, your handler is called once again, you can treat it: No issue AFAIU the problem here is that the only ACK that is able to assert the line NMI - GIC is the ACK by the unmask callback. All the others ACKs before that one are ignored by the NMI controller since the line PMIC - NMI is still asserted. So, to sum things up, what you see is something like: handle_level_irq | devicedevice | mask ack handler irq acked unmask | || | | | v vv v v v NMI - GIC: ++ +- ---++-+ PMIC - NMI: +-+ + +- And you get a rogue retrigger because the NMI - GIC level went up again. I'm not exactly sure on how to fix this. Maybe by adding a call to the irqchip's ack just before the unmask in irq_finalize_oneshot? Thomas, what are your thoughts on this? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH v3 1/3] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller
On Wed, Jan 29, 2014 at 1:58 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: So, to sum things up, what you see is something like: handle_level_irq | devicedevice | mask ack handler irq acked unmask | || | | | v vv v v v NMI - GIC: ++ +- ---++-+ PMIC - NMI: +-+ + +- And you get a rogue retrigger because the NMI - GIC level went up again. I'd say something like: handle_level_irq | devicedevice | mask ack handler irq acked unmask | || | | | v vv v v v NMI - GIC: +-+ ---+ +-- PMIC - NMI: +-+ + +- I'm not exactly sure on how to fix this. Maybe by adding a call to the irqchip's ack just before the unmask in irq_finalize_oneshot? That is exactly what the unmask callback in the NMI controller driver does. The unmask_irq() in irq_finalize_oneshot() calls the unmask callback in the driver (sunxi_sc_nmi_ack_and_unmask()) that ACKs the line before unmasking it again. Best, -- 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/groups/opt_out.
[linux-sunxi] Re: [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
On Wed, Jan 29, 2014 at 12:25:20PM +, Mark Brown wrote:
On Wed, Jan 29, 2014 at 12:10:48PM +0100, Maxime Ripard wrote:
+config SPI_SUN6I
+ tristate Allwinner A31 SPI controller
+ depends on ARCH_SUNXI || COMPILE_TEST
+ select PM_RUNTIME
+ help
+ This enables using the SPI controller on the Allwinner A31 SoCs.
+
A select of PM_RUNTIME is both surprising and odd - why is that there?
The usual idiom is that the device starts out powered up (flagged using
pm_runtime_set_active()) and then runtime PM then suspends it when it's
compiled in. That way if for some reason people want to avoid runtime
PM they can still use the device.
Since pm_runtime_set_active and all the pm_runtime* callbacks in
general are defined to pretty much empty functions, how the
suspend/resume callbacks are called then? Obviously, we need them to
be run, hence why I added the select here, but now I'm seeing a
construct like what's following acceptable then?
pm_runtime_enable(pdev-dev);
if (!pm_runtime_enabled(pdev-dev))
sun6i_spi_runtime_resume(pdev-dev);
+static void sun6i_spi_set_cs(struct spi_device *spi, bool enable)
+{
+ struct sun6i_spi *sspi = spi_master_get_devdata(spi-master);
+ u32 reg;
+
+ if (!enable)
+ return;
+
+ reg = sun6i_spi_read(sspi, SUN6I_TFR_CTL_REG);
+ reg = ~SUN6I_TFR_CTL_CS_MASK;
+ reg |= SUN6I_TFR_CTL_CS(spi-chip_select);
+ sun6i_spi_write(sspi, SUN6I_TFR_CTL_REG, reg);
+}
The !enable means that it'll only ever be able to go one way. Also note
that the documentation was clarified here to make the enable flag be the
absolute logic level, not if chip select was asserted.
Actually the IP asserts the CS automatically, the only thing you need
to do is to set which CS to use for your next transfer in some
register (which is what I'm doing after the !enable), and the CS will
be managed directly by the controller. Hence, there's no way to say
wether you want to enable it or not.
The controller allows to control the CS manually also, if that's the
preferred way of doing things.
+ timeout = wait_for_completion_timeout(sspi-done,
+ msecs_to_jiffies(1000));
+ if (!timeout) {
+ ret = -ETIMEDOUT;
+ goto out;
+ }
+
+ sun6i_spi_drain_fifo(sspi, SUN6I_FIFO_DEPTH);
This means we can only transfer a single FIFO of data? I didn't see a
check on the transfer length.
At the moment, indeed. And that's the first thing I check in the
transfer_one function.
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: [linux-sunxi] Video chip in A31 box
On Wed, Jan 29, 2014 at 1:28 AM, Luc Verhaegen l...@skynet.be wrote: On Tue, Jan 28, 2014 at 04:16:00PM -0500, jonsm...@gmail.com wrote: I know that our support for A31 is severely lacking, but please work through the http://linux-sunxi.org/New_Device_howto anyway. Not sure I am going to work on this board. I missed the fact that it doesn't have a SD Card slot when I bough it. So you're not even intending to document your findings about this hardware? I made a page with basic info. http://linux-sunxi.org/CS918S There is a microSD card but it is hard to see, just looks like a crack in case. I only found it by looking at the PCB and seeing the connector. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [RFC PATCH v2 03/14] of: mtd: add documentation for nand-ecc-level property
nand-ecc-level property statically defines NAND chip's ECC requirements. Signed-off-by: Boris BREZILLON b.brezillon@gmail.com --- Documentation/devicetree/bindings/mtd/nand.txt |3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt index 03855c8..0c962296 100644 --- a/Documentation/devicetree/bindings/mtd/nand.txt +++ b/Documentation/devicetree/bindings/mtd/nand.txt @@ -3,5 +3,8 @@ - nand-ecc-mode : String, operation mode of the NAND ecc mode. Supported values are: none, soft, hw, hw_syndrome, hw_oob_first, soft_bch. +- nand-ecc-level : Two cells property defining the ECC level requirements. + The first cell represent the strength and the second cell the ECC block size. + E.g. : nand-ecc-level = 4 512; /* 4 bits / 512 bytes */ - nand-bus-width : 8 or 16 bus width if not present 8 - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false -- 1.7.9.5 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [RFC PATCH v2 06/14] of: mtd: add NAND timing mode retrieval support
Add a function to retrieve NAND timing mode (ONFI timing mode) from a given
DT node.
Signed-off-by: Boris BREZILLON b.brezillon@gmail.com
---
drivers/of/of_mtd.c| 19 +++
include/linux/of_mtd.h |8
2 files changed, 27 insertions(+)
diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
index e8ced61..63155d4 100644
--- a/drivers/of/of_mtd.c
+++ b/drivers/of/of_mtd.c
@@ -108,3 +108,22 @@ bool of_get_nand_on_flash_bbt(struct device_node *np)
return of_property_read_bool(np, nand-on-flash-bbt);
}
EXPORT_SYMBOL_GPL(of_get_nand_on_flash_bbt);
+
+/**
+ * of_get_nand_timings - Get nand timings for the given device_node
+ * @np:Pointer to the given device_node
+ *
+ * return 0 on success errno other wise
+ */
+int of_get_nand_onfi_timing_mode(struct device_node *np)
+{
+ int err;
+ u32 mode;
+
+ err = of_property_read_u32(np, onfi,nand-timing-mode, mode);
+ if (err)
+ return err;
+
+ return mode;
+}
+EXPORT_SYMBOL_GPL(of_get_nand_onfi_timing_mode);
diff --git a/include/linux/of_mtd.h b/include/linux/of_mtd.h
index 3bd8c3b..eb9fda6 100644
--- a/include/linux/of_mtd.h
+++ b/include/linux/of_mtd.h
@@ -9,6 +9,8 @@
#ifndef __LINUX_OF_MTD_H
#define __LINUX_OF_NET_H
+#include linux/mtd/nand.h
+
#ifdef CONFIG_OF_MTD
#include linux/of.h
@@ -16,6 +18,7 @@ int of_get_nand_ecc_mode(struct device_node *np);
int of_get_nand_ecc_level(struct device_node *np, u32 *strengh, u32 *blk_size);
int of_get_nand_bus_width(struct device_node *np);
bool of_get_nand_on_flash_bbt(struct device_node *np);
+int of_get_nand_onfi_timing_mode(struct device_node *np);
#else /* CONFIG_OF_MTD */
@@ -40,6 +43,11 @@ static inline bool of_get_nand_on_flash_bbt(struct
device_node *np)
return false;
}
+static inline int of_get_nand_onfi_timing_mode(struct device_node *np)
+{
+ return -ENOSYS;
+}
+
#endif /* CONFIG_OF_MTD */
#endif /* __LINUX_OF_MTD_H */
--
1.7.9.5
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [RFC PATCH v2 00/14] mtd: nand: add sunxi NAND Flash Controller support
Hello, This series adds support for the sunxi NAND Flash Controller (NFC). This controller supports up to 8 NAND chip connected. I'm still in the early stages drivers development and some key features are missing, but it's usable (I tested it on the cubietruck board). Here's what's missing: - DMA support - HW randomization support - other improvements ? This series depends on Emilio's patch series implementing mod0 clks (http://lists.infradead.org/pipermail/linux-arm-kernel/2013-July/185478.html) + an other patch not yet posted (http://git.elopez.com.ar/linux/commits/5b4eb3ac406b9c98965714d40e8dd6da943d1ab0) Best Regards, Boris Changes since v1: - add HW ECC support - rework NAND timings retrieval (use ONFI timing mode instead of raw timings) - add nand-ecc-level property to specify NAND ECC requirements from DT Boris BREZILLON (14): mtd: nand: retrieve ECC requirements from Hynix READ ID byte 4 of: mtd: add NAND ECC level requirements retrieval of: mtd: add documentation for nand-ecc-level property mtd: nand: define struct nand_timings mtd: nand: add ONFI timing mode to nand_timings converter of: mtd: add NAND timing mode retrieval support of: mtd: add documentation for the ONFI NAND timing mode property mtd: nand: add sunxi NAND flash controller support mtd: nand: add sunxi NFC dt bindings doc ARM: dt/sunxi: add NFC node to Allwinner A20 SoC ARM: dt/sunxi: add NFC pinctrl pin definitions ARM: sunxi/dt: enable NAND on cubietruck board mtd: nand: add sunxi HW ECC support ARM: sunxi/dt: enable HW ECC on cubietruck board Documentation/devicetree/bindings/mtd/nand.txt |8 + .../devicetree/bindings/mtd/sunxi-nand.txt | 46 + arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 31 + arch/arm/boot/dts/sun7i-a20.dtsi | 35 + drivers/mtd/nand/Kconfig |6 + drivers/mtd/nand/Makefile |3 +- drivers/mtd/nand/nand_base.c | 37 + drivers/mtd/nand/nand_timings.c| 248 + drivers/mtd/nand/sunxi_nand.c | 997 drivers/of/of_mtd.c| 44 + include/linux/mtd/nand.h | 53 ++ include/linux/of_mtd.h | 15 + 12 files changed, 1522 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt create mode 100644 drivers/mtd/nand/nand_timings.c create mode 100644 drivers/mtd/nand/sunxi_nand.c -- 1.7.9.5 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [RFC PATCH v2 05/14] mtd: nand: add ONFI timing mode to nand_timings converter
Add a converter to retrieve NAND timings from an ONFI NAND timing mode.
This only support SDR NAND timings for now.
Signed-off-by: Boris BREZILLON b.brezillon@gmail.com
---
drivers/mtd/nand/Makefile |2 +-
drivers/mtd/nand/nand_timings.c | 248 +++
include/linux/mtd/nand.h|4 +
3 files changed, 253 insertions(+), 1 deletion(-)
create mode 100644 drivers/mtd/nand/nand_timings.c
diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile
index 542b568..bbea7a6 100644
--- a/drivers/mtd/nand/Makefile
+++ b/drivers/mtd/nand/Makefile
@@ -2,7 +2,7 @@
# linux/drivers/nand/Makefile
#
-obj-$(CONFIG_MTD_NAND) += nand.o
+obj-$(CONFIG_MTD_NAND) += nand.o nand_timings.o
obj-$(CONFIG_MTD_NAND_ECC) += nand_ecc.o
obj-$(CONFIG_MTD_NAND_BCH) += nand_bch.o
obj-$(CONFIG_MTD_NAND_IDS) += nand_ids.o
diff --git a/drivers/mtd/nand/nand_timings.c b/drivers/mtd/nand/nand_timings.c
new file mode 100644
index 000..f66fe95
--- /dev/null
+++ b/drivers/mtd/nand/nand_timings.c
@@ -0,0 +1,248 @@
+/*
+ * Copyright (C) 2014 Boris BREZILLON b.brezillon@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+#include linux/mtd/nand.h
+
+static const struct nand_sdr_timings onfi_sdr_timings[] = {
+ /* Mode 0 */
+ {
+ .tADL_min = 20,
+ .tALH_min = 2,
+ .tALS_min = 5,
+ .tAR_min = 25000,
+ .tCEA_max = 10,
+ .tCEH_min = 2,
+ .tCH_min = 2,
+ .tCHZ_max = 10,
+ .tCLH_min = 2,
+ .tCLR_min = 2,
+ .tCLS_min = 5,
+ .tCOH_min = 0,
+ .tCS_min = 7,
+ .tDH_min = 2,
+ .tDS_min = 4,
+ .tFEAT_max = 100,
+ .tIR_min = 1,
+ .tITC_max = 100,
+ .tRC_min = 10,
+ .tREA_max = 4,
+ .tREH_min = 3,
+ .tRHOH_min = 0,
+ .tRHW_min = 20,
+ .tRHZ_max = 20,
+ .tRLOH_min = 0,
+ .tRP_min = 5,
+ .tRST_max = 2500,
+ .tWB_max = 20,
+ .tRR_min = 4,
+ .tWC_min = 10,
+ .tWH_min = 3,
+ .tWHR_min = 12,
+ .tWP_min = 5,
+ .tWW_min = 10,
+ },
+ /* Mode 1 */
+ {
+ .tADL_min = 10,
+ .tALH_min = 1,
+ .tALS_min = 25000,
+ .tAR_min = 1,
+ .tCEA_max = 45000,
+ .tCEH_min = 2,
+ .tCH_min = 1,
+ .tCHZ_max = 5,
+ .tCLH_min = 1,
+ .tCLR_min = 1,
+ .tCLS_min = 25000,
+ .tCOH_min = 15000,
+ .tCS_min = 35000,
+ .tDH_min = 1,
+ .tDS_min = 2,
+ .tFEAT_max = 100,
+ .tIR_min = 0,
+ .tITC_max = 100,
+ .tRC_min = 5,
+ .tREA_max = 3,
+ .tREH_min = 15000,
+ .tRHOH_min = 15000,
+ .tRHW_min = 10,
+ .tRHZ_max = 10,
+ .tRLOH_min = 0,
+ .tRP_min = 25000,
+ .tRR_min = 2,
+ .tRST_max = 5,
+ .tWB_max = 10,
+ .tWC_min = 45000,
+ .tWH_min = 15000,
+ .tWHR_min = 8,
+ .tWP_min = 25000,
+ .tWW_min = 10,
+ },
+ /* Mode 2 */
+ {
+ .tADL_min = 10,
+ .tALH_min = 1,
+ .tALS_min = 15000,
+ .tAR_min = 1,
+ .tCEA_max = 3,
+ .tCEH_min = 2,
+ .tCH_min = 1,
+ .tCHZ_max = 5,
+ .tCLH_min = 1,
+ .tCLR_min = 1,
+ .tCLS_min = 15000,
+ .tCOH_min = 15000,
+ .tCS_min = 25000,
+ .tDH_min = 5000,
+ .tDS_min = 15000,
+ .tFEAT_max = 100,
+ .tIR_min = 0,
+ .tITC_max = 100,
+ .tRC_min = 35000,
+ .tREA_max = 25000,
+ .tREH_min = 15000,
+ .tRHOH_min = 15000,
+ .tRHW_min = 10,
+ .tRHZ_max = 10,
+ .tRLOH_min = 0,
+ .tRR_min = 2,
+ .tRST_max = 5,
+ .tWB_max = 10,
+ .tRP_min = 17000,
+
[linux-sunxi] [RFC PATCH v2 02/14] of: mtd: add NAND ECC level requirements retrieval
Some chip do not support automatic retrieval of ECC level requirements.
Provide an helper function to retrieve these requirements from DT.
Signed-off-by: Boris BREZILLON b.brezillon@gmail.com
---
drivers/of/of_mtd.c| 25 +
include/linux/of_mtd.h |7 +++
2 files changed, 32 insertions(+)
diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
index a27ec94..e8ced61 100644
--- a/drivers/of/of_mtd.c
+++ b/drivers/of/of_mtd.c
@@ -50,6 +50,31 @@ int of_get_nand_ecc_mode(struct device_node *np)
EXPORT_SYMBOL_GPL(of_get_nand_ecc_mode);
/**
+ * of_get_nand_ecc_level - Get nand ecc level for the given device_node
+ * @np:Pointer to the given device_node
+ * @strengh: ECC strength
+ * @blk_size: ECC block size
+ *
+ * The function gets ecc level requirements from property 'nand-ecc-level'.
+ * Return 0 on success, -errno otherwise.
+ */
+int of_get_nand_ecc_level(struct device_node *np, u32 *strengh, u32 *blk_size)
+{
+ int err;
+
+ err = of_property_read_u32_index(np, nand-ecc-level, 0, strengh);
+ if (err 0)
+ return err;
+
+ err = of_property_read_u32_index(np, nand-ecc-level, 1, blk_size);
+ if (err 0)
+ return err;
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(of_get_nand_ecc_level);
+
+/**
* of_get_nand_bus_width - Get nand bus witdh for given device_node
* @np:Pointer to the given device_node
*
diff --git a/include/linux/of_mtd.h b/include/linux/of_mtd.h
index 6f10e93..3bd8c3b 100644
--- a/include/linux/of_mtd.h
+++ b/include/linux/of_mtd.h
@@ -13,6 +13,7 @@
#include linux/of.h
int of_get_nand_ecc_mode(struct device_node *np);
+int of_get_nand_ecc_level(struct device_node *np, u32 *strengh, u32 *blk_size);
int of_get_nand_bus_width(struct device_node *np);
bool of_get_nand_on_flash_bbt(struct device_node *np);
@@ -23,6 +24,12 @@ static inline int of_get_nand_ecc_mode(struct device_node
*np)
return -ENOSYS;
}
+static inline int of_get_nand_ecc_level(struct device_node *np, u32 *strengh,
+ u32 *blk_size)
+{
+ return -ENOSYS;
+}
+
static inline int of_get_nand_bus_width(struct device_node *np)
{
return -ENOSYS;
--
1.7.9.5
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
Add the sunxi NAND Flash Controller dt bindings documentation.
Signed-off-by: Boris BREZILLON b.brezillon@gmail.com
---
.../devicetree/bindings/mtd/sunxi-nand.txt | 46
1 file changed, 46 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt
diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
new file mode 100644
index 000..b0e55a3
--- /dev/null
+++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
@@ -0,0 +1,46 @@
+Allwinner NAND Flash Controller (NFC)
+
+Required properties:
+- compatible : allwinner,sun4i-nand.
+- reg : shall contain registers location and length for data and reg.
+- interrupts : shall define the nand controller interrupt.
+- #address-cells: shall be set to 1. Encode the nand CS.
+- #size-cells : shall be set to 0.
+- clocks : shall reference nand controller clocks.
+- clock-names : nand controller internal clock names. Shall contain :
+* ahb_clk : AHB gating clock
+* sclk : nand controller clock
+
+Optional children nodes:
+Children nodes represent the available nand chips.
+
+Optional properties:
+- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI
+ standard.
+- allwinner,rb : shall contain the native Ready/Busy ids.
+ or
+- rb-gpios : shall contain the gpios used as R/B pins.
+
+see Documentation/devicetree/mtd/nand.txt for generic bindings.
+
+
+Examples:
+nfc: nand@01c03000 {
+ compatible = allwinner,sun4i-nand;
+ reg = 0x01c03000 0x1000;
+ interrupts = 0 37 1;
+ clocks = ahb_gates 13, nand_clk;
+ clock-names = ahb_clk, sclk;
+ #address-cells = 1;
+ #size-cells = 0;
+ pinctrl-names = default;
+ pinctrl-0 = nand_pins_a nand_cs0_pins_a nand_rb0_pins_a;
+ status = okay;
+
+ nand@0 {
+ reg = 0;
+ allwinner,rb = 0;
+ nand-ecc-mode = soft_bch;
+ onfi,nand-timing-mode = 4;
+ };
+};
--
1.7.9.5
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [RFC PATCH v2 11/14] ARM: dt/sunxi: add NFC pinctrl pin definitions
Define the NAND pinctrl configs.
Signed-off-by: Boris BREZILLON b.brezillon@gmail.com
---
arch/arm/boot/dts/sun7i-a20.dtsi | 24
1 file changed, 24 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 3b47253..0f6e002 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -389,6 +389,30 @@
allwinner,drive = 0;
allwinner,pull = 0;
};
+
+ nand_pins_a: nand_base0@0 {
+ allwinner,pins = PC0, PC1, PC2,
+ PC5, PC8, PC9, PC10,
+ PC11, PC12, PC13, PC14,
+ PC15, PC16;
+ allwinner,function = nand0;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
+
+ nand_cs0_pins_a: nand_cs@0 {
+ allwinner,pins = PC4;
+ allwinner,function = nand0;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
+
+ nand_rb0_pins_a: nand_rb@0 {
+ allwinner,pins = PC6;
+ allwinner,function = nand0;
+ allwinner,drive = 0;
+ allwinner,pull = 0;
+ };
};
timer@01c20c00 {
--
1.7.9.5
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [RFC PATCH v2 14/14] ARM: sunxi/dt: enable HW ECC on cubietruck board
Signed-off-by: Boris BREZILLON b.brezillon@gmail.com --- arch/arm/boot/dts/sun7i-a20-cubietruck.dts |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts index 031de97..5828923 100644 --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts @@ -29,7 +29,7 @@ #size-cells = 1; reg = 0; allwinner,rb = 0; - nand-ecc-mode = soft_bch; + nand-ecc-mode = hw; /* nand timings */ tCLS-min = 6; -- 1.7.9.5 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Re: [RFC PATCH 0/9] mtd: nand: add sunxi NAND Flash Controller support
On 13 January 2014 10:02, boris brezillon b.brezil...@overkiz.com wrote: Hi Henrik, On 11/01/2014 22:11, Henrik Nordström wrote: bbrezillon thanks for pointing out your documents bbrezillon I'm trying to get the NAND driver with HW ECC (and HW RND) without using DMA at all I tried many things but did not quite get the ECC reading command to return meaningful resuts. But should work somehow. bbrezillon do you have any other information I could use to do this ? Not really. There is no known code to look at using the nand controller without DMA. All allwinner code uses DMA even the boot ROM (BROM). bbrezillon For example, I wonder why there are 2 RAM sectors (the driver I found only make use of RAM0) I think it's used during DMA to fetch next sector while the previous one is transferred by DMA. But not sure. Some feedback on my tests: - I managed to get HW ECC working without any DMA transfer (using CMD = 01): * I only tested the sequential ECC = ECC are stored between 2 data blocks (1024 byte) * Non sequential ECC should work if I store ECC bytes in the OOB area too (I'll just have to send RANDOM_OUT commands to move to the OOB area before sending the ECC cmd and another RANDOM_OUT to go back to the DATA area) - The HW RND (randomizer) works too, I'll just have to figure out how this could be mainlined: * using a simple dt property to tell the controller it should enable the randomizer * provide an interface (like the nand_ecc_ctrl struct ) for other to add their own randomizer implementation (this was requested: https://lkml.org/lkml/2013/12/13/154) The most complicated part is the boot0 partition. Tell me if I'm wrong, but here's what I understood from your work (and yuq's work too): boot 0 part properties: - uses sequential ECC - uses 1024 bytes ECC blocks - boot0 code is stored only on the first ECC block of each page (1024 bytes + ecc bytes) - boot0 code is stored on the first 64 pages of the first block - boot0 uses HW randomizer with a specific rnd seed (0x4a80) It's not that complicated to read/write from/to boot0, but it's a bit more to mainline this implementation: - the nand chip must use the same ECC algorithm and ECC layout on the whole flash (no partition specific config available) - you cannot mark some part of pages as unused = the nand driver will write the whole page, not just the first ECC block (1024 bytes) I thought about manually creating an mtd device that fullfils these needs (in case we encounter the allwinner,nandn-boot property on a nand@X node), but I'm not sure this is the right approach. Any ideas ? Maybe if varying parameters on one MTD device is not acceptable you could export parts of the flash as different MTD devices each with its own parameters. Since the boot0 part is fixed size this should not really be an issue. Existing MTD drivers that share hardware with other devices exist - eg. the MTD driver which exports part of RAM as MDT device. I wonder if it would be good idea to make it possible to use the NAND only for storage without a boot0 area. If this is selected by a DT parameter as suggested changing the parameter will probably make the NAND unreadable. Thanks Michal Best Regards, Boris Regards Henrik -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Re: [RFC PATCH 0/9] mtd: nand: add sunxi NAND Flash Controller support
On 29 January 2014 16:43, boris brezillon dev b.brezillon@gmail.com wrote: Hello Michal, On 29/01/2014 16:11, Michal Suchanek wrote: On 13 January 2014 10:02, boris brezillon b.brezil...@overkiz.com wrote: boot 0 part properties: - uses sequential ECC - uses 1024 bytes ECC blocks - boot0 code is stored only on the first ECC block of each page (1024 bytes + ecc bytes) - boot0 code is stored on the first 64 pages of the first block - boot0 uses HW randomizer with a specific rnd seed (0x4a80) It's not that complicated to read/write from/to boot0, but it's a bit more to mainline this implementation: - the nand chip must use the same ECC algorithm and ECC layout on the whole flash (no partition specific config available) - you cannot mark some part of pages as unused = the nand driver will write the whole page, not just the first ECC block (1024 bytes) I thought about manually creating an mtd device that fullfils these needs (in case we encounter the allwinner,nandn-boot property on a nand@X node), but I'm not sure this is the right approach. Any ideas ? Maybe if varying parameters on one MTD device is not acceptable you could export parts of the flash as different MTD devices each with its own parameters. Since the boot0 part is fixed size this should not really be an issue. Existing MTD drivers that share hardware with other devices exist - eg. the MTD driver which exports part of RAM as MDT device. I considered this option (exposing 2 mtd devices which use the same nand chip: one for the boot partition and the other one for the remaining space). I might give it a try. For the moment I'm trying to use standard partitions and then attach one of these partitions as a sunxi-nand-boot-interface. Something similar to what UBI is doing when attaching to an MTD device. This way we can use the NAND as a standard MTD dev and when one partition is attached as a sunxi-nand-boot-interface you can access the boot0 partition using a char dev (/dev/snbi0 ?). The sunxi-nand-boot-interface will provide the appropriate abstraction to hide the specific boot0 layout... What do you think ? If it works with MTD, sure. The problem the two devices avoid is that with uniform parameters across MTD device the boot0 partition is invalid. I wonder if it would be good idea to make it possible to use the NAND only for storage without a boot0 area. If this is selected by a DT parameter as suggested changing the parameter will probably make the NAND unreadable. Actually the NAND controller supports up to 8 chips. I guess only the first one can be used as a boot device. Reserving space for the boot partition on all of these chips is kind of useless. This actually depends on the BROM. I did not read the BROM code so I don't know what it does. Moreover, we can't tell if the user wants to boot from the NAND or from another storage (MMC for example), in this case we don't need to expose the boot0 partition. It's possible to use the NAND only for storage, sure. However, a NAND on which the boo0 area is reserved would be unreadable without reserving boot0 area in the driver, right? The best we can tell is if user specified to reserve the area in the DT. It might be possible to verify the boot0 area the same way BROM does when booting from it. This might be nice option when you don't know what you have on the chip and want to read it but most of the time you will want to enforce bootable or non-bootable format when writing the NAND. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Re: [RFC PATCH 0/9] mtd: nand: add sunxi NAND Flash Controller support
On 29/01/2014 17:08, Michal Suchanek wrote: On 29 January 2014 16:43, boris brezillon dev b.brezillon@gmail.com wrote: Hello Michal, On 29/01/2014 16:11, Michal Suchanek wrote: On 13 January 2014 10:02, boris brezillon b.brezil...@overkiz.com wrote: boot 0 part properties: - uses sequential ECC - uses 1024 bytes ECC blocks - boot0 code is stored only on the first ECC block of each page (1024 bytes + ecc bytes) - boot0 code is stored on the first 64 pages of the first block - boot0 uses HW randomizer with a specific rnd seed (0x4a80) It's not that complicated to read/write from/to boot0, but it's a bit more to mainline this implementation: - the nand chip must use the same ECC algorithm and ECC layout on the whole flash (no partition specific config available) - you cannot mark some part of pages as unused = the nand driver will write the whole page, not just the first ECC block (1024 bytes) I thought about manually creating an mtd device that fullfils these needs (in case we encounter the allwinner,nandn-boot property on a nand@X node), but I'm not sure this is the right approach. Any ideas ? Maybe if varying parameters on one MTD device is not acceptable you could export parts of the flash as different MTD devices each with its own parameters. Since the boot0 part is fixed size this should not really be an issue. Existing MTD drivers that share hardware with other devices exist - eg. the MTD driver which exports part of RAM as MDT device. I considered this option (exposing 2 mtd devices which use the same nand chip: one for the boot partition and the other one for the remaining space). I might give it a try. For the moment I'm trying to use standard partitions and then attach one of these partitions as a sunxi-nand-boot-interface. Something similar to what UBI is doing when attaching to an MTD device. This way we can use the NAND as a standard MTD dev and when one partition is attached as a sunxi-nand-boot-interface you can access the boot0 partition using a char dev (/dev/snbi0 ?). The sunxi-nand-boot-interface will provide the appropriate abstraction to hide the specific boot0 layout... What do you think ? If it works with MTD, sure. The problem the two devices avoid is that with uniform parameters across MTD device the boot0 partition is invalid. Using partitions we would still have X char devices (X = number of MTD partitions). But indeed, we need to provide a way to configure ECC and randomizer specifically on each partition. I wonder if it would be good idea to make it possible to use the NAND only for storage without a boot0 area. If this is selected by a DT parameter as suggested changing the parameter will probably make the NAND unreadable. Actually the NAND controller supports up to 8 chips. I guess only the first one can be used as a boot device. Reserving space for the boot partition on all of these chips is kind of useless. This actually depends on the BROM. I did not read the BROM code so I don't know what it does. Moreover, we can't tell if the user wants to boot from the NAND or from another storage (MMC for example), in this case we don't need to expose the boot0 partition. It's possible to use the NAND only for storage, sure. However, a NAND on which the boo0 area is reserved would be unreadable without reserving boot0 area in the driver, right? Not exactly: the NAND would still be readable but the blocks reserved for boot0 (boot0 partition) won't be read correctly (ECC layout differs). If you define a partition boot0 with the appropriate size and never access it, the other partitions defined on the same NAND chip will work perfectly. To solve this ECC config issue we might need to provide a way to configure the ECC engine per partition and not on the whole NAND chip. Moreover, IRC, BROM only uses 1K on each page of a given block to store boot0 code and data. And eventually the randomizer config (random seed) is specific for this partition too. Note that the current driver does not support randomization at all. I'm still working on providing a generic framework to support HW and SW randomization (in the same way HW and SW ECC are supported). For all the reasons exposed above we need a specific handling for the boot0 partition. But I'd like to keep the NAND Flash controller driver as simple and as generic as possible. I'd prefer adding a new driver for the sunxi boot0 partition handling than adding this code in the sunxi_nand driver. Atfer all, this boot partition has nothing to do with NAND, this is just a specific format for the sunxi BROM to load code from NAND to RAM, right ? The best we can tell is if user specified to reserve the area in the DT. It might be possible to verify the boot0 area the same way BROM does when booting from it. This might be nice option when you don't know what you have on the chip and want to read it but most of the time you will want to enforce bootable or non-bootable format when writing the
[linux-sunxi] [PATCH boards 3/4] iNet 86VS add extra uart sections to quiet error messages.
From 7c7364e458ea7bca6756cc2d1cd3e1e8c57a9c96 Mon Sep 17 00:00:00 2001 In-Reply-To: a1920c011a6968f4b3b0f2ccfdf98289be301c5e.1391014497.git.hramr...@gmail.com Signed-off-by: Michal Suchanek hramr...@gmail.com --- sys_config/a13/inet_86vs.fex | 14 ++ 1 file changed, 14 insertions(+) diff --git a/sys_config/a13/inet_86vs.fex b/sys_config/a13/inet_86vs.fex index b2a04c2..5850aac 100644 --- a/sys_config/a13/inet_86vs.fex +++ b/sys_config/a13/inet_86vs.fex @@ -131,6 +131,20 @@ uart_type = 2 uart_tx = port:PG0341defaultdefault uart_rx = port:PG0441defaultdefault +[uart_para2] +uart_used = 0 +uart_port = 3 +uart_type = 2 +uart_tx = port:PG0341defaultdefault +uart_rx = port:PG0441defaultdefault + +[uart_para3] +uart_used = 0 +uart_port = 3 +uart_type = 2 +uart_tx = port:PG0341defaultdefault +uart_rx = port:PG0441defaultdefault + [spi1_para] spi_used = 0 spi_cs0 = port:PG092defaultdefaultdefault -- 1.7.10.4 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH boards 1/4] Original fex file from iNet technology 86VS (Manta MID705).
From a1920c011a6968f4b3b0f2ccfdf98289be301c5e Mon Sep 17 00:00:00 2001 Signed-off-by: Michal Suchanek hramr...@gmail.com --- sys_config/a13/inet_86vs.fex | 735 ++ 1 file changed, 735 insertions(+) create mode 100644 sys_config/a13/inet_86vs.fex diff --git a/sys_config/a13/inet_86vs.fex b/sys_config/a13/inet_86vs.fex new file mode 100644 index 000..f1c224f --- /dev/null +++ b/sys_config/a13/inet_86vs.fex @@ -0,0 +1,735 @@ +[product] +version = 1.0 +machine = A13-EVB-V1.0 + +[target] +boot_clock = 1008 +dcdc2_vol = 1400 +dcdc3_vol = 1200 +ldo2_vol = 3000 +ldo3_vol = 3300 +ldo4_vol = 3300 +pll4_freq = 960 +pll6_freq = 720 +power_start = 0 +storage_type = 0 + +[pm_para] +standby_mode = 0 + +[card_boot] +logical_start = 40960 +sprite_gpio0 = + +[card_boot0_para] +card_ctrl = 0 +card_high_speed = 1 +card_line = 4 +sdc_d1 = port:PF0021defaultdefault +sdc_d0 = port:PF0121defaultdefault +sdc_clk = port:PF0221defaultdefault +sdc_cmd = port:PF0321defaultdefault +sdc_d3 = port:PF0421defaultdefault +sdc_d2 = port:PF0521defaultdefault + +[twi_para] +twi_port = 0 +twi_scl = port:PB0021defaultdefault +twi_sda = port:PB0121defaultdefault + +[uart_para] +uart_debug_port = 0 +uart_debug_tx = port:PG0341defaultdefault +uart_debug_rx = port:PG0441defaultdefault + +[jtag_para] +jtag_enable = 0 +jtag_ms = port:PF0041defaultdefault +jtag_ck = port:PF0541defaultdefault +jtag_do = port:PF0341defaultdefault +jtag_di = port:PF0141defaultdefault + +[dram_para] +dram_baseaddr = 0x4000 +dram_clk = 408 +dram_type = 3 +dram_rank_num = 1 +dram_chip_density = 2048 +dram_io_width = 8 +dram_bus_width = 16 +dram_cas = 9 +dram_zq = 0x7b +dram_odt_en = 0 +dram_size = 512 +dram_tpr0 = 0x42d899b7 +dram_tpr1 = 0xa090 +dram_tpr2 = 0x22a00 +dram_tpr3 = 0x0 +dram_tpr4 = 0x0 +dram_tpr5 = 0x0 +dram_emr1 = 0x4 +dram_emr2 = 0x10 +dram_emr3 = 0x0 + +[nand_para] +nand_used = 1 +nand_we = port:PC002defaultdefaultdefault +nand_ale = port:PC012defaultdefaultdefault +nand_cle = port:PC022defaultdefaultdefault +nand_ce1 = port:PC032defaultdefaultdefault +nand_ce0 = port:PC042defaultdefaultdefault +nand_nre = port:PC052defaultdefaultdefault +nand_rb0 = port:PC062defaultdefaultdefault +nand_rb1 = port:PC072defaultdefaultdefault +nand_d0 = port:PC082defaultdefaultdefault +nand_d1 = port:PC092defaultdefaultdefault +nand_d2 = port:PC102defaultdefaultdefault +nand_d3 = port:PC112defaultdefaultdefault +nand_d4 = port:PC122defaultdefaultdefault +nand_d5 = port:PC132defaultdefaultdefault +nand_d6 = port:PC142defaultdefaultdefault +nand_d7 = port:PC152defaultdefaultdefault +nand_wp = +nand_ce2 = +nand_ce3 = +nand_ce4 = +nand_ce5 = +nand_ce6 = +nand_ce7 = +nand_spi = +nand_ndqs = port:PC192defaultdefaultdefault +good_block_ratio = 0 + +[mali_para] +mali_used = 1 +mali_clkdiv = 2 + +[twi0_para] +twi0_used = 1 +twi0_scl = port:PB002defaultdefaultdefault +twi0_sda = port:PB012defaultdefaultdefault + +[twi1_para] +twi1_used = 1 +twi1_scl = port:PB152defaultdefaultdefault +twi1_sda = port:PB162defaultdefaultdefault + +[twi2_para] +twi2_used = 1 +twi2_scl = port:PB172defaultdefaultdefault +twi2_sda = port:PB182defaultdefaultdefault + +[uart_para0] +uart_used = 0 +uart_port = 0 +uart_type = 2 +uart_tx = port:PB1921defaultdefault +uart_rx = port:PB2021defaultdefault + +[uart_para1] +uart_used = 0 +uart_port = 1 +uart_type = 2 +uart_tx = port:PG0341defaultdefault +uart_rx = port:PG0441defaultdefault + +[spi1_para] +spi_used = 0 +spi_cs0 = port:PG092defaultdefaultdefault +spi_cs1 = port:PG132defaultdefaultdefault +spi_sclk = port:PG102defaultdefaultdefault +spi_mosi = port:PG112defaultdefaultdefault +spi_miso = port:PG122defaultdefaultdefault + +[spi2_para] +spi_used = 0 +spi_cs0 = port:PE004defaultdefaultdefault +spi_sclk = port:PE014defaultdefaultdefault +spi_mosi = port:PB024defaultdefaultdefault +spi_miso = port:PB034defaultdefaultdefault + +[rtp_para] +rtp_used = 0 +rtp_screen_size = 5 +rtp_regidity_level = 5 +rtp_press_threshold_enable = 0 +rtp_press_threshold = 0x1f40 +rtp_sensitive_level = 0xf +rtp_exchange_x_y_flag = 0 + +[ctp_para] +ctp_boxchip_type = 2579 +ctp_cob = 1 +ctp_twi_id = 1 +ctp0_used = 1 +ctp0_name = ft5x02 +ctp0_twi_addr = 56 +ctp1_used = 0 +ctp1_name = Goodix-TS +ctp1_twi_addr = 85 +ctp2_used = 1 +ctp2_name = ssd253x-ts +ctp2_twi_addr = 72 +ctp2_ssd_type = 75801 +ctp4_used = 1 +ctp4_name = zet622x-ts +ctp4_twi_addr = 118 +ctp5_used = 1 +ctp5_name = byd693x-ts +ctp5_twi_addr = 82 +ctp8_used = 0 +ctp8_name = gt82x +ctp8_twi_addr = 93 +ctp9_used = 1 +ctp9_name = gt811 +ctp9_twi_addr = 93 +ctp10_used = 1 +ctp10_name = pixcir_cxx +ctp10_twi_addr = 92 +ctp12_used = 1 +ctp12_name = gslx680 +ctp12_twi_addr = 64 +ctp12_gsl_type = 8602 +ctp13_used = 1 +ctp13_name = sitronix_ts +ctp13_twi_addr = 96 +ctp19_used = 1 +ctp19_name = elan_ts +ctp19_twi_addr = 20 +ctp_screen_max_x = 800 +ctp_screen_max_y = 480 +ctp_revert_x_flag = 0 +ctp_revert_y_flag = 0 +ctp_exchange_x_y_flag = 0 +ctp_int_port =
[linux-sunxi] [PATCH boards 2/4] Update iNet 86VS fex with a10-meminfo output.
From 1bb92f91a32c9ed698b0e5cc4aaa48e60d4b46da Mon Sep 17 00:00:00 2001 In-Reply-To: a1920c011a6968f4b3b0f2ccfdf98289be301c5e.1391014497.git.hramr...@gmail.com Signed-off-by: Michal Suchanek hramr...@gmail.com --- sys_config/a13/inet_86vs.fex |8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/sys_config/a13/inet_86vs.fex b/sys_config/a13/inet_86vs.fex index f1c224f..b2a04c2 100644 --- a/sys_config/a13/inet_86vs.fex +++ b/sys_config/a13/inet_86vs.fex @@ -54,19 +54,17 @@ dram_baseaddr = 0x4000 dram_clk = 408 dram_type = 3 dram_rank_num = 1 -dram_chip_density = 2048 -dram_io_width = 8 +dram_chip_density = 4096 +dram_io_width = 16 dram_bus_width = 16 dram_cas = 9 -dram_zq = 0x7b +dram_zq = 0x56b9697b dram_odt_en = 0 dram_size = 512 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 -dram_tpr4 = 0x0 -dram_tpr5 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 -- 1.7.10.4 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] [PATCH tools 2/2] Fix bogus usage message in pio tool.
Looks good. Applied.
tis 2014-01-28 klockan 22:06 +0100 skrev Michal Suchanek:
From c1c9a0432331a59e047a3330f89e2cca27e77b25 Mon Sep 17 00:00:00 2001
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
pio.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/pio.c b/pio.c
index e48a660..7ef4514 100644
--- a/pio.c
+++ b/pio.c
@@ -167,8 +167,11 @@ static const char *argv0;
static void usage(int rc )
{
-
- fprintf(stderr, usage: %s [-m|-i input] [-o output] pin..\n, argv0);
+
+ fprintf(stderr, usage: %s -m|-i input [-o output] pin..\n, argv0);
+ fprintf(stderr, -m mmap - read pin state
from system\n);
+ fprintf(stderr, -i read pin state from
file\n);
+ fprintf(stderr, -o save pin state data to
file\n);
fprintf(stderr, print Show all pins\n);
fprintf(stderr, PxxShow pin\n);
fprintf(stderr, Pxxmodepulldrivedata Configure pin\n);
@@ -179,7 +182,7 @@ static void usage(int rc )
fprintf(stderr, \n mode 0-7, 0=input, 1=ouput, 2-7 I/O
function\n);
fprintf(stderr,pull 0=none, 1=up, 2=down\n);
fprintf(stderr,drive 0-3, I/O drive level\n);
-
+
exit(rc);
}
--
1.7.10.4
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [RFC PATCH v2 08/14] mtd: nand: add sunxi NAND flash controller support
On Wed, Jan 29, 2014 at 03:34:18PM +0100, Boris BREZILLON wrote:
+static int sunxi_nand_chip_init_timings(struct sunxi_nand_chip *chip,
+ struct device_node *np)
+{
+ const struct nand_sdr_timings *timings;
+ u32 min_clk_period = 0;
+ int ret;
+
+ ret = onfi_get_async_timing_mode(chip-nand);
+ if (ret == ONFI_TIMING_MODE_UNKNOWN) {
+ ret = of_get_nand_onfi_timing_mode(np);
+ if (ret 0)
+ return ret;
+ }
[..]
+static int sunxi_nand_chip_init(struct device *dev, struct sunxi_nfc *nfc,
[..]
+ ret = sunxi_nand_chip_init_timings(chip, np);
+ if (ret)
+ return ret;
[..]
+ ret = nand_scan_ident(mtd, nsels, NULL);
This ordering looks a bit problematic, will onfi_get_async_timing_mode
ever return anything other than ONFI_TIMING_MODE_UNKNOWN if it is
called before nand_scan_ident ? What sets clk_rate to non-zero if there
is no DT property?
For a flow that uses onfi_get_async_timing_mode rather than DT the
driver should set the interface to timing mode 0 (slowest) and then
call nand_scan_ident, and then reset the interface to the detected
timing mode.
Maybe this should be implemented in the core code through a new
callback (nand-set_timing_mode ?)
Regards,
Jason
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
Hello Rob, Le 29/01/2014 18:11, Rob Herring a écrit : On Wed, Jan 29, 2014 at 8:34 AM, Boris BREZILLON b.brezillon@gmail.com wrote: Add the sunxi NAND Flash Controller dt bindings documentation. Signed-off-by: Boris BREZILLON b.brezillon@gmail.com --- .../devicetree/bindings/mtd/sunxi-nand.txt | 46 1 file changed, 46 insertions(+) create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt new file mode 100644 index 000..b0e55a3 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt @@ -0,0 +1,46 @@ +Allwinner NAND Flash Controller (NFC) + +Required properties: +- compatible : allwinner,sun4i-nand. +- reg : shall contain registers location and length for data and reg. +- interrupts : shall define the nand controller interrupt. +- #address-cells: shall be set to 1. Encode the nand CS. +- #size-cells : shall be set to 0. +- clocks : shall reference nand controller clocks. +- clock-names : nand controller internal clock names. Shall contain : +* ahb_clk : AHB gating clock +* sclk : nand controller clock + +Optional children nodes: +Children nodes represent the available nand chips. + +Optional properties: For the controller or per nand chip? +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI + standard. Add to generic nand binding. +- allwinner,rb : shall contain the native Ready/Busy ids. + or +- rb-gpios : shall contain the gpios used as R/B pins. Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B pin is an option? Both are optional. In case none of the properties are defined the dev_ready callback is set to NULL and the nand_base waiting loop is used. If so, don't you need some fixed time delay properties like max erase time? This is handled in nand_base (using the chip_delay field), but I guess we could use the information retrieved from nand timings and the operation in progress... rb-gpios could be added to the generic nand binding as well. Sure. Rob -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
Le 29/01/2014 19:02, Gupta, Pekon a écrit : Dear Rob, and other DT maintainers, From: Rob Herring [...] +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI + standard. Add to generic nand binding. +- allwinner,rb : shall contain the native Ready/Busy ids. + or +- rb-gpios : shall contain the gpios used as R/B pins. Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B pin is an option? If so, don't you need some fixed time delay properties like max erase time? rb-gpios could be added to the generic nand binding as well. I do think this should go into generic nand binding, as this is controller specific. Some controllers have dedicated R/B pin (Ready/Busy) while others may use GPIO instead. It's the way a hardware controller is designed. You meant You do not think, right ? If so, I think even if the retrieval and control of the GPIO is done is each NAND controller, we could at least use a common property name for all drivers using a GPIO to detect the R/B state. Request you to please consider Ack from MTD Maintainers 'at-least' for generic NAND DT bindings. There is already a discussion going in a separate thread for which is still not awaiting replies [1]. [1] http://lists.infradead.org/pipermail/linux-mtd/2014-January/051625.html I missed this thread, but I can definitely use the nand-ecc-strength and nand-ecc-step-size instead of the one I defined (nand-ecc-level), as long as there is a proper way to define these informations in the DT. I'll let DT and MTD maintainers decide ;-). Best Regards, Boris with regards, pekon -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
Le 29/01/2014 19:02, Gupta, Pekon a écrit : Dear Rob, and other DT maintainers, From: Rob Herring [...] +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI + standard. Add to generic nand binding. +- allwinner,rb : shall contain the native Ready/Busy ids. + or +- rb-gpios : shall contain the gpios used as R/B pins. Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B pin is an option? If so, don't you need some fixed time delay properties like max erase time? rb-gpios could be added to the generic nand binding as well. I do think this should go into generic nand binding, as this is controller specific. Some controllers have dedicated R/B pin (Ready/Busy) while others may use GPIO instead. It's the way a hardware controller is designed. You meant You do not think, right ? If so, I think even if the retrieval and control of the GPIO is done is each NAND controller, we could at least use a common property name for all drivers using a GPIO to detect the R/B state. Request you to please consider Ack from MTD Maintainers 'at-least' for generic NAND DT bindings. There is already a discussion going in a separate thread for which is still not awaiting replies [1]. [1]http://lists.infradead.org/pipermail/linux-mtd/2014-January/051625.html I missed this thread, but I can definitely use the nand-ecc-strength and nand-ecc-step-size instead of the one I defined (nand-ecc-level), as long as there is a proper way to define these informations in the DT. I'll let DT and MTD maintainers decide ;-). Best Regards, Boris with regards, pekon -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] RE: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
Dear Rob, and other DT maintainers, From: Rob Herring [...] +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI + standard. Add to generic nand binding. +- allwinner,rb : shall contain the native Ready/Busy ids. + or +- rb-gpios : shall contain the gpios used as R/B pins. Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B pin is an option? If so, don't you need some fixed time delay properties like max erase time? rb-gpios could be added to the generic nand binding as well. I do think this should go into generic nand binding, as this is controller specific. Some controllers have dedicated R/B pin (Ready/Busy) while others may use GPIO instead. It's the way a hardware controller is designed. Request you to please consider Ack from MTD Maintainers 'at-least' for generic NAND DT bindings. There is already a discussion going in a separate thread for which is still not awaiting replies [1]. [1] http://lists.infradead.org/pipermail/linux-mtd/2014-January/051625.html with regards, pekon -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] RE: [RFC PATCH v2 09/14] mtd: nand: add sunxi NFC dt bindings doc
Dear Rob, and other DT maintainers, (apologies, fixed typos in earlier mail) From: Rob Herring [...] +- onfi,nand-timing-mode : mandatory if the chip does not support the ONFI + standard. Add to generic nand binding. +- allwinner,rb : shall contain the native Ready/Busy ids. + or +- rb-gpios : shall contain the gpios used as R/B pins. Isn't allwinner,rb implied by a lack of rb-gpios property. Or no R/B pin is an option? If so, don't you need some fixed time delay properties like max erase time? rb-gpios could be added to the generic nand binding as well. I do _not_ think this should go into generic nand binding, as this is controller specific. Some controllers have dedicated R/B pin (Ready/Busy) while others may use GPIO instead. It's the way a hardware controller is designed. Request you to please consider Ack from MTD Maintainers 'at-least' for generic NAND DT bindings. There is already a discussion going in a separate thread for which there are still no replies [1]. [1] http://lists.infradead.org/pipermail/linux-mtd/2014-January/051625.html with regards, pekon -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [RFC PATCH v2 03/14] of: mtd: add documentation for nand-ecc-level property
On Wed, Jan 29, 2014 at 03:34:13PM +0100, Boris BREZILLON wrote: nand-ecc-level property statically defines NAND chip's ECC requirements. Signed-off-by: Boris BREZILLON b.brezillon@gmail.com --- Documentation/devicetree/bindings/mtd/nand.txt |3 +++ 1 file changed, 3 insertions(+) diff --git a/Documentation/devicetree/bindings/mtd/nand.txt b/Documentation/devicetree/bindings/mtd/nand.txt index 03855c8..0c962296 100644 --- a/Documentation/devicetree/bindings/mtd/nand.txt +++ b/Documentation/devicetree/bindings/mtd/nand.txt @@ -3,5 +3,8 @@ - nand-ecc-mode : String, operation mode of the NAND ecc mode. Supported values are: none, soft, hw, hw_syndrome, hw_oob_first, soft_bch. +- nand-ecc-level : Two cells property defining the ECC level requirements. + The first cell represent the strength and the second cell the ECC block size. + E.g. : nand-ecc-level = 4 512; /* 4 bits / 512 bytes */ - nand-bus-width : 8 or 16 bus width if not present 8 - nand-on-flash-bbt: boolean to enable on flash bbt option if not present false Hm.. when was this proposal agreed? It seems I've missed the discussion... FWIW, we've already proposed an equivalent one, but it received no feedback from the devicetree maintainers: http://comments.gmane.org/gmane.linux.drivers.devicetree/58764 Maybe we can discuss about it now? nand-ecc-strength : integer ECC required strength. nand-ecc-size : integer step size associated to the ECC strength. vs. nand-ecc-level : Two cells property defining the ECC level requirements. The first cell represent the strength and the second cell the ECC block size. E.g. : nand-ecc-level = 4 512; /* 4 bits / 512 bytes */ It's really the same proposal but with a different format, right? IMHO, the former is more human-readable, but other than that I see no difference. Brian? DT-guys? -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [RFC PATCH v2 08/14] mtd: nand: add sunxi NAND flash controller support
On Wed, Jan 29, 2014 at 10:56:42AM -0700, Jason Gunthorpe wrote: On Wed, Jan 29, 2014 at 03:34:18PM +0100, Boris BREZILLON wrote: [..] +static int sunxi_nand_chip_init(struct device *dev, struct sunxi_nfc *nfc, [..] + ret = sunxi_nand_chip_init_timings(chip, np); + if (ret) + return ret; [..] + ret = nand_scan_ident(mtd, nsels, NULL); This ordering looks a bit problematic, will onfi_get_async_timing_mode ever return anything other than ONFI_TIMING_MODE_UNKNOWN if it is called before nand_scan_ident ? What sets clk_rate to non-zero if there is no DT property? For a flow that uses onfi_get_async_timing_mode rather than DT the driver should set the interface to timing mode 0 (slowest) and then call nand_scan_ident, and then reset the interface to the detected timing mode. Yes. And I believe this is a requirement from the ONFI 2.1 spec: 4.1.4.3. Source Synchronous to Asynchronous [..] The host shall transition to the asynchronous data interface. Then the host shall issue the Reset (FFh) command described in the previous paragraph using asynchronous timing mode 0, thus the host transitions to the asynchronous data interface prior to issuing the Reset (FFh). A device in any timing mode is required to recognize a Reset (FFh) command issued in asynchronous timing mode 0. [..] After CE# has been pulled high and then transitioned low again, the host should issue a Set Features to select the appropriate asynchronous timing mode. -- Ezequiel García, Free Electrons Embedded Linux, Kernel and Android Engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [RFC PATCH v2 08/14] mtd: nand: add sunxi NAND flash controller support
On Wed, Jan 29, 2014 at 03:46:20PM -0300, Ezequiel Garcia wrote: After CE# has been pulled high and then transitioned low again, the host should issue a Set Features to select the appropriate asynchronous timing mode. Oh, I had forgot you should do a set feature too Boris, I think the core core should handle this dance and the driver should just implement a call back to change the timing mode on the interface.. If I ever get a moment I can work on support for timing setting in the mvebu driver, I have boards here with ONFI NAND.. Regards, Jason -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: A13 Chinese Tablet - ROTATE SCREEN?
On 2014-01-24, neje...@gmail.com neje...@gmail.com wrote: Dear All: So far my A13 chinese tablet works fine. Any idea how to rotate the Screen 90 degrees to have it on Portrait as default? XRANDR does not work, fbcon works on console mode ( echoing 1 to ../rotate_all), I am using lightdm + openbox + lxde. Any help will be appreciated. ALl the best. Nelson. Maybe you can get something with xorg.conf. There are settings for rotation. I have no idea if they work with fbdev/fbturbo driver. HTH Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH u-boot] Add iNet technologies 86VS tablet.
From d8d50b936a98f94f5a216bb99d6b519530778193 Mon Sep 17 00:00:00 2001
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
board/sunxi/Makefile|1 +
board/sunxi/dram_inet86vs.c | 29 +
boards.cfg |2 ++
3 files changed, 32 insertions(+)
create mode 100644 board/sunxi/dram_inet86vs.c
diff --git a/board/sunxi/Makefile b/board/sunxi/Makefile
index e431653..e2327a9 100644
--- a/board/sunxi/Makefile
+++ b/board/sunxi/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_A10S_OLINUXINO_M)+=
dram_a10s_olinuxino_m.o
obj-$(CONFIG_A13_OLINUXINO)+= dram_a13_olinuxino.o
obj-$(CONFIG_A13_OLINUXINOM) += dram_a13_oli_micro.o
obj-$(CONFIG_A13_MID) += dram_a13_mid.o
+obj-$(CONFIG_INET86VS) += dram_inet86vs.o
obj-$(CONFIG_A20_OLINUXINO_M) += dram_a20_olinuxino_m.o
obj-$(CONFIG_AUXTEK_T003) += dram_auxtek_t003.o
# This is not a typo, uses the same mem settings as the a10s-olinuxino-m
diff --git a/board/sunxi/dram_inet86vs.c b/board/sunxi/dram_inet86vs.c
new file mode 100644
index 000..80d1a8e
--- /dev/null
+++ b/board/sunxi/dram_inet86vs.c
@@ -0,0 +1,29 @@
+/* this file is generated, don't edit it yourself */
+
+#include common.h
+#include asm/arch/dram.h
+
+static struct dram_para dram_para = {
+ .clock= 408,
+ .type = 3,
+ .rank_num = 1,
+ .density = 4096,
+ .io_width = 16,
+ .bus_width= 16,
+ .cas = 9,
+ .zq = 0x56b9697b,
+ .odt_en = 0,
+ .size = 512,
+ .tpr0 = 0x42d899b7,
+ .tpr1 = 0xa090,
+ .tpr2 = 0x22a00,
+ .tpr3 = 0x0,
+ .emr1 = 0x4,
+ .emr2 = 0x10,
+ .emr3 = 0x0,
+};
+
+unsigned long sunxi_dram_init(void)
+{
+ return dramc_init(dram_para);
+}
diff --git a/boards.cfg b/boards.cfg
index ef986a7..d04ba31 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -354,6 +354,8 @@ Active arm armv7 sunxi -
sunxi
Active arm armv7 sunxi - sunxi
A13-OLinuXinoM
sun5i:A13_OLINUXINOM,SPL,NO_AXP,STATUSLED=201,CONS_INDEX=2
-
Active arm armv7 sunxi - sunxi
A13-OLinuXinoM_FEL
sun5i:A13_OLINUXINOM,SPL_FEL,NO_AXP,STATUSLED=201,CONS_INDEX=2
-
Active arm armv7 sunxi - sunxi
A13_MID sun5i:A13_MID,SPL,CONS_INDEX=2
-
+Active arm armv7 sunxi - sunxi
INET86VS sun5i:INET86VS,SPL,CONS_INDEX=2
-
+Active arm armv7 sunxi - sunxi
INET86VS_FEL sun5i:INET86VS,SPL_FEL,UART0_PORT_F
-
Active arm armv7 sunxi - sunxi
A20-OLinuXino_MICRO
sun7i:A20_OLINUXINO_M,CONS_INDEX=1,STATUSLED=226,SPL,SUNXI_EMAC
-
Active arm armv7 sunxi - sunxi
A20-OLinuXino_MICRO_FEL
sun7i:A20_OLINUXINO_M,CONS_INDEX=1,STATUSLED=226,SPL_FEL,SUNXI_EMAC
-
Active arm armv7 sunxi - sunxi
Auxtek-T003
sun5i:AUXTEK_T003,SPL,AXP152_POWER,STATUSLED=34
-
--
1.7.10.4
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Uart 6 + 7 Not working
Im Trying to use Uart 6 and Uart7 on PI Ports I see a valid ttl signal on the Input pin of the Uarts Read Pin but I can not read anything in linux On uart7 I can send out data On uart 6 I can neither send nor receive data (measured the ttl signals with scope, no data showing up on writ, valid ttl signal on read) My UART Settings are: [uart_para0] uart_used = 1 uart_port = 0 uart_type = 2 uart_tx = port:PB2221defaultdefault uart_rx = port:PB2321defaultdefault [uart_para1] uart_used = 0 uart_port = 1 uart_type = 8 uart_tx = port:PA1041defaultdefault uart_rx = port:PA1141defaultdefault uart_rts = port:PA1241defaultdefault uart_cts = port:PA1341defaultdefault uart_dtr = port:PA1441defaultdefault uart_dsr = port:PA1541defaultdefault uart_dcd = port:PA1641defaultdefault uart_ring = port:PA1741defaultdefault [uart_para2] uart_used = 1 uart_port = 2 uart_type = 4 uart_tx = port:PI1831defaultdefault uart_rx = port:PI1931defaultdefault uart_rts = port:PI1631defaultdefault uart_cts = port:PI1731defaultdefault [uart_para3] uart_used = 0 uart_port = 3 uart_type = 4 uart_tx = port:PH0041defaultdefault uart_rx = port:PH0141defaultdefault uart_rts = port:PH0241defaultdefault uart_cts = port:PH0341defaultdefault [uart_para4] uart_used = 0 uart_port = 4 uart_type = 2 uart_tx = port:PH0441defaultdefault uart_rx = port:PH0541defaultdefault [uart_para5] uart_used = 0 uart_port = 5 uart_type = 2 uart_tx = port:PH0641defaultdefault uart_rx = port:PH0741defaultdefault [uart_para6] uart_used = 1 uart_port = 6 uart_type = 2 uart_tx = port:PI1231defaultdefault uart_rx = port:PI1331defaultdefault [uart_para7] uart_used = 1 uart_port = 7 uart_type = 2 uart_tx = port:PI2031defaultdefault uart_rx = port:PI2131defaultdefault I verifies the Mux setting for the pins quite a few times (its function 3), also I verified that the PA pins are configured as network and the PI pins are not used anywhere else Can someone verify that UART 6 and UART 7 is working on A10 and thee Pin/settings are correct? Regards -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
Hi Maxime,
El 29/01/14 08:10, Maxime Ripard escribió:
The Allwinner A31 has a new SPI controller IP compared to the older Allwinner
SoCs.
It supports DMA, but the driver only does PIO for now, and DMA will be
supported eventually.
Signed-off-by: Maxime Ripard maxime.rip...@free-electrons.com
---
(snip)
+ struct sun6i_spi *sspi = spi_master_get_devdata(master);
+ int ret;
+
+ ret = clk_prepare_enable(sspi-hclk);
+ if (ret) {
+ dev_err(dev, Couldn't enable clock 'ahb spi'\n);
+ goto out;
+ }
+
+ ret = clk_prepare_enable(sspi-mclk);
+ if (ret) {
+ dev_err(dev, Couldn't enable clock 'ahb spi'\n);
A different message would be nice :)
Cheers,
Emilio
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
