[linux-sunxi] Re: [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
Hi Kevin, On Thu, Jan 30, 2014 at 03:52:16PM -0800, Kevin Hilman wrote: > On Wed, Jan 29, 2014 at 5:32 AM, Maxime Ripard > wrote: > > 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? > > Even with your 'select', The runtime PM callbacks will never be called > in the current driver. pm_runtime_enable() doesn't do any runtime PM > transitions. It just allows transitions to happen when they're > triggered by _get()/_put()/etc. Actually, pm_runtime_get_sync is called by the SPI framework whenever the device needs to be used. And pm_runtime_put whenever it's not used anymore, so the callbacks are actually called. > > > pm_runtime_enable(&pdev->dev); > > if (!pm_runtime_enabled(&pdev->dev)) > >sun6i_spi_runtime_resume(&pdev->dev); > > Similarily here, it's not the pm_runtime_enable that will fail when > runtime PM is disabled (or not built-in), it's a pm_runtime_get_sync() > that will fail. In the case where pm_runtime is disabled, pm_runtime_enabled will only return false, and hence the resume callback will be called. get_sync will fail too when the framework will call it, but since the device is already initialized, it's fine I guess. > What you want is something like this in ->probe() > >sun6i_spi_runtime_resume(); >/* now, device is always activated whether or not runtime PM is enabled */ >pm_runtime_enable(); >pm_runtime_set_active(); /* tells runtime PM core device is > already active */ >pm_runtime_get_sync(); > > This 'get' will increase the usecount, but not actually call the > callbacks because we told the RPM core that the device was already > activated with _set_active(). > > And then, in ->remove(), you'll want > >pm_runtime_put(); >pm_runtime_disable(); > > And if runtime PM is not enabled in the kernel, then the device will > be left on (which is kinda what you want if you didn't build runtime > PM into the kernel.) Yes, but that also mean that the device is actually on after the probe, even if it's never going to be used. From what I got reading the pm_runtime code, the suspend callback is called only whenever you call _put, so the device will be suspended only after it's been used the first time, right? Wouldn't it be better if it was suspended by default, and just waken up whenever the framework needs it? Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Re: How to port ubuntu in my A20 board.
HI , I used some previous rootfs which is used for my A10 board. Now UBUNTU is booting fine. But Once i play 720p video , the video is not playing smoothly(playing like slow motion). i tried with installing mali.ko and ump.ko. But not yet worked. kindly suggest me what will be issue. Regards Punith -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Olimex A13-OLinuXino-WIFI MOD-RS232 setup
Hello, I have A13-OLinuXino-WIFI board with uext mod -rs232 interface. My problem is MOD-RS232. How to use MOD-RS232 ? Thanks. -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH v3 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
---
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 v3 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
---
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 v3 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
---
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 v3 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
---
.../devicetree/bindings/spi/spi-sun6i.txt | 24 ++
drivers/spi/Kconfig| 6 +
drivers/spi/Makefile | 1 +
drivers/spi/spi-sun6i.c| 473 +
4 files changed, 504 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 5072b71..24f3b85 100644
--- a/drivers/spi/Kconfig
+++ b/drivers/spi/Kconfig
@@ -446,6 +446,12 @@ config SPI_SIRF
help
SPI driver for CSR SiRFprimaII SoCs
+config SPI_SUN6I
+ tristate "Allwinner A31 SPI controller"
+ depends on ARCH_SUNXI || COMPILE_TEST
+ 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 95af48d..13b6ccf 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -70,6 +70,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..1747892
--- /dev/null
+++ b/drivers/spi/spi-sun6i.c
@@ -0,0 +1,473 @@
+/*
+ * Copyright (C) 2012 - 2014 Allwinner Tech
+ * Pan Nan
+ *
+ * Copyright (C) 2014 Maxime Ripard
+ * Maxime Ripard
+ *
+ * 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
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+#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_CS_MANUALBIT(6)
+#define SUN6I_TFR_CTL_CS_LEVEL BIT(7)
+#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
+#define SUN6I_FIFO_STA_RF_CNT_MASK 0x7f
+#define SUN6I_FIFO_STA_RF_CNT_BITS 0
+#define SUN6I_FIFO_STA_TF_CNT
[linux-sunxi] [PATCH v3 0/5] Add Allwinner A31 SPI controller support
Hi everyone, This patchset brings support for the SPI controller found in the Allwinner A31 SoC. Even though the controller supports DMA, the driver only supports PIO mode for now. This driver will be used to bring up and test DMA on the SoC, so support for the DMA will come eventually. It doesn't support transfer larger than the FIFO size (128 bytes) for now, I expect it to be fixed in the future. Thanks! Maxime Changes from v2: - Removed the select on runtime_pm - Fixed the clock error messages - Trigger the CS manually, and honour the enable bit in set_cs - Convert to devm_* functions - Remove useless clk_disable_unprepare in probe Changes from v1: - Switched to using the transfer_one and set_cs callbacks - Switched to using runtime_pm - Report an error when we try to do a transfer larger than the FIFO size, instead of silently timeouting. - Added a Kconfig symbol - Move the clock ratio change at transfer time - Fixed the PLL6 cell size in the DTSI - A few fixes here and there: typos, etc. Maxime Ripard (5): clk: sunxi: Add support for PLL6 on the A31 ARM: sun6i: dt: Add PLL6 and SPI module clocks spi: sunxi: Add Allwinner A31 SPI controller driver ARM: sun6i: dt: Add SPI controllers to the A31 DTSI ARM: sunxi: Enable A31 SPI and SID in the defconfig Documentation/devicetree/bindings/clock/sunxi.txt | 1 + .../devicetree/bindings/spi/spi-sun6i.txt | 24 ++ arch/arm/boot/dts/sun6i-a31.dtsi | 86 +++- arch/arm/configs/sunxi_defconfig | 3 + drivers/clk/sunxi/clk-sunxi.c | 45 ++ drivers/spi/Kconfig| 6 + drivers/spi/Makefile | 1 + drivers/spi/spi-sun6i.c| 473 + 8 files changed, 630 insertions(+), 9 deletions(-) create mode 100644 Documentation/devicetree/bindings/spi/spi-sun6i.txt create mode 100644 drivers/spi/spi-sun6i.c -- 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 v3 5/5] ARM: sunxi: Enable A31 SPI and SID in the defconfig
Signed-off-by: Maxime Ripard --- 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] Re: [PATCH v3 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
On Fri, Jan 31, 2014 at 11:55:50AM +0100, Maxime Ripard wrote:
> + master = devm_spi_alloc_master(&pdev->dev, sizeof(struct sun6i_spi));
> + if (!master) {
> + dev_err(&pdev->dev, "Unable to allocate SPI Master\n");
> + return -ENOMEM;
> + }
This now depends on your other series which as I said doesn't look like
the best approach.
> + pm_runtime_enable(&pdev->dev);
> + if (!pm_runtime_enabled(&pdev->dev)) {
> + ret = sun6i_spi_runtime_resume(&pdev->dev);
> + if (ret) {
> + dev_err(&pdev->dev, "Couldn't resume the device\n");
> + return ret;
> + }
> + }
No, as discussed don't do this - notice how other drivers aren't written
this way either. Like I said leave the device powered on startup and
then let it be idled by runtime PM.
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH v2 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
On Thu, Jan 30, 2014 at 6:29 PM, Felipe Balbi wrote: > Hi, > > On Thu, Jan 30, 2014 at 03:52:16PM -0800, Kevin Hilman wrote: >> On Wed, Jan 29, 2014 at 5:32 AM, Maxime Ripard >> wrote: >> > 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? >> >> Even with your 'select', The runtime PM callbacks will never be called >> in the current driver. pm_runtime_enable() doesn't do any runtime PM >> transitions. It just allows transitions to happen when they're >> triggered by _get()/_put()/etc. >> >> > pm_runtime_enable(&pdev->dev); >> > if (!pm_runtime_enabled(&pdev->dev)) >> >sun6i_spi_runtime_resume(&pdev->dev); >> >> Similarily here, it's not the pm_runtime_enable that will fail when >> runtime PM is disabled (or not built-in), it's a pm_runtime_get_sync() >> that will fail. >> >> What you want is something like this in ->probe() >> >>sun6i_spi_runtime_resume(); >>/* now, device is always activated whether or not runtime PM is enabled */ >>pm_runtime_enable(); >>pm_runtime_set_active(); /* tells runtime PM core device is >> already active */ > > shouldn't this be done before pm_runtime_enable() ? hmm, possibly yes. I was doing this from the top of my head without looking to closely at the code. >>pm_runtime_get_sync(); >> >> This 'get' will increase the usecount, but not actually call the >> callbacks because we told the RPM core that the device was already >> activated with _set_active(). >> >> And then, in ->remove(), you'll want >> >>pm_runtime_put(); > > in ->remove() you actually want a put_sync() right ? You don't want to > schedule anything since you're just about to disable pm_runtime. Yes, you're correct. Thanks for the corrections. Kevin -- 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 5:32 AM, Maxime Ripard wrote: > 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? Even with your 'select', The runtime PM callbacks will never be called in the current driver. pm_runtime_enable() doesn't do any runtime PM transitions. It just allows transitions to happen when they're triggered by _get()/_put()/etc. > pm_runtime_enable(&pdev->dev); > if (!pm_runtime_enabled(&pdev->dev)) >sun6i_spi_runtime_resume(&pdev->dev); Similarily here, it's not the pm_runtime_enable that will fail when runtime PM is disabled (or not built-in), it's a pm_runtime_get_sync() that will fail. What you want is something like this in ->probe() sun6i_spi_runtime_resume(); /* now, device is always activated whether or not runtime PM is enabled */ pm_runtime_enable(); pm_runtime_set_active(); /* tells runtime PM core device is already active */ pm_runtime_get_sync(); This 'get' will increase the usecount, but not actually call the callbacks because we told the RPM core that the device was already activated with _set_active(). And then, in ->remove(), you'll want pm_runtime_put(); pm_runtime_disable(); And if runtime PM is not enabled in the kernel, then the device will be left on (which is kinda what you want if you didn't build runtime PM into the kernel.) Kevin -- 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
Hi, On Thu, Jan 30, 2014 at 03:52:16PM -0800, Kevin Hilman wrote: > On Wed, Jan 29, 2014 at 5:32 AM, Maxime Ripard > wrote: > > 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? > > Even with your 'select', The runtime PM callbacks will never be called > in the current driver. pm_runtime_enable() doesn't do any runtime PM > transitions. It just allows transitions to happen when they're > triggered by _get()/_put()/etc. > > > pm_runtime_enable(&pdev->dev); > > if (!pm_runtime_enabled(&pdev->dev)) > >sun6i_spi_runtime_resume(&pdev->dev); > > Similarily here, it's not the pm_runtime_enable that will fail when > runtime PM is disabled (or not built-in), it's a pm_runtime_get_sync() > that will fail. > > What you want is something like this in ->probe() > >sun6i_spi_runtime_resume(); >/* now, device is always activated whether or not runtime PM is enabled */ >pm_runtime_enable(); >pm_runtime_set_active(); /* tells runtime PM core device is > already active */ shouldn't this be done before pm_runtime_enable() ? >pm_runtime_get_sync(); > > This 'get' will increase the usecount, but not actually call the > callbacks because we told the RPM core that the device was already > activated with _set_active(). > > And then, in ->remove(), you'll want > >pm_runtime_put(); in ->remove() you actually want a put_sync() right ? You don't want to schedule anything since you're just about to disable pm_runtime. -- balbi signature.asc Description: Digital signature
[linux-sunxi] Missing DVB symbols version
Hi, I'm trying to compile the vtunerc (http://code.google.com/p/vtuner/) kernel module for my cubieboard2 (sunxi-kernel 3.4.75). Although it's built ok, when I try to load it with "modprobe vtunerc" I get unkown symbols errors: [117972.229485] vtunerc: no symbol version for dvb_dmxdev_init [117972.234314] vtunerc: Unknown symbol dvb_dmxdev_init (err -22) [117972.239343] vtunerc: no symbol version for dvb_register_adapter [117972.244553] vtunerc: Unknown symbol dvb_register_adapter (err -22) [117972.249803] vtunerc: no symbol version for dvb_dmx_swfilter_packets [117972.255332] vtunerc: Unknown symbol dvb_dmx_swfilter_packets (err -22) If I force the load (modprobe -f vtunerc), the module gets loaded and works normally: [118031.114349] virtual DVB adapter driver, version 1.4, (c) 2010-12 Honza Petrous, SmartImp.cz [118031.131771] DVB: registering new adapter (vTuner proxy) [118031.137102] vtunerc: registered /dev/vtunerc0 Reading the file Module.symvers I see that there are no DVB symbols exported. However, my laptop's kernel (3.7.10) does have those symbols exported in Module.symvers: 0x dvb_dmxdev_init vmlinux EXPORT_SYMBOL 0x dvb_register_adaptervmlinux EXPORT_SYMBOL 0x dvb_dmx_swfilter_packetsvmlinux EXPORT_SYMBOL How do I add this symbols? -- Cheers -- 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 Fri, Jan 31, 2014 at 09:11:47AM +0100, Maxime Ripard wrote: > Wouldn't it be better if it was suspended by default, and just waken > up whenever the framework needs it? The aim should be to come out of probe in that state if runtime PM is enabled but don't do it with these hacks, do it by idling the device at the end of probe for example. Apart from anything else this code just looks ugly. signature.asc Description: Digital signature
[linux-sunxi] [PATCH u-boot] sunxi: correct CLK_DLY configuration loop
It seems that the intention was to index the dqs_dly array with dqs_i and not
clk_i. Using clk_i means that dqs_i is unused in the loop and also causes us to
run off the end of the dqs_dly array resulting in:
In file included from dram.c:34:0:
dram.c: In function ‘dramc_init’:
dram.c:314:15: warning: iteration 7u invokes undefined behavior
[-Waggressive-loop-optimizations]
(dqs_dly[clk_i] & 0x4f) << 14);
(clk_i runs to <15, dqs_i to <7 and dqs_dly[] has 8 entries)
I have not run this on actual hardware. I'm not sure when it is even used
because it is gated on "para->tpr3 & (0x1 << 31)" and AFAICT all
board/sunxi/dram_* files currently in the tree set trp3 to zero.
Signed-off-by: Ian Campbell
---
arch/arm/cpu/armv7/sunxi/dram.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram.c b/arch/arm/cpu/armv7/sunxi/dram.c
index 94a3657..4d570a0 100644
--- a/arch/arm/cpu/armv7/sunxi/dram.c
+++ b/arch/arm/cpu/armv7/sunxi/dram.c
@@ -311,7 +311,7 @@ static int dramc_scan_dll_para(void)
for (cr_i = 1; cr_i < 5; cr_i++) {
clrsetbits_le32(&dram->dllcr[cr_i],
0x4f << 14,
- (dqs_dly[clk_i] & 0x4f) << 14);
+ (dqs_dly[dqs_i] & 0x4f) << 14);
}
udelay(2);
if (dramc_scan_readpipe() == 0)
--
1.8.5.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] [PATCH u-boot] cmd_gpio: fix warning with GPIO_OSCILLATE
In do_gpio value is not initialised in the GPIO_OSCILLATE case:
cmd_gpio.c: In function ‘do_gpio’:
cmd_gpio.c:92:2: warning: ‘value’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
return value;
^
Returning 0 in this case seems fairly logical.
Signed-off-by: Ian Campbell
Cc: Henrik Nordstrom
---
common/cmd_gpio.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/common/cmd_gpio.c b/common/cmd_gpio.c
index d551415..a43e89e 100644
--- a/common/cmd_gpio.c
+++ b/common/cmd_gpio.c
@@ -75,6 +75,7 @@ static int do_gpio(cmd_tbl_t *cmdtp, int flag, int argc, char
* const argv[])
gpio_set_value(gpio, i&1);
}
gpio_direction_input(gpio);
+ value = 0;
} else {
switch (sub_cmd) {
case GPIO_SET:value = 1; break;
--
1.8.5.3
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] [PATCH] tools: correct proftool build rule
On Fri, 2014-01-31 at 17:07 +, Ian Campbell wrote: > The incorrect substitution made it rebuild every time. I sent this to linux-sunxi@ instead of the u-boot list by mistake. Sorry! Will resend to the correct place shortly... -- 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] tools: correct proftool build rule
The incorrect substitution made it rebuild every time. Signed-off-by: Ian Campbell Cc: Tom Rini Cc: Simon Glass --- tools/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/Makefile b/tools/Makefile index 323d408..602b2e5 100644 --- a/tools/Makefile +++ b/tools/Makefile @@ -59,7 +59,7 @@ BIN_FILES-$(CONFIG_MX28) += mxsboot$(SFX) BIN_FILES-$(CONFIG_NETCONSOLE) += ncb$(SFX) BIN_FILES-$(CONFIG_SHA1_CHECK_UB_IMG) += ubsha1$(SFX) BIN_FILES-$(CONFIG_KIRKWOOD) += kwboot$(SFX) -BIN_FILES-y += proftool(SFX) +BIN_FILES-y += proftool$(SFX) # Source files which exist outside the tools directory EXT_OBJ_FILES-$(CONFIG_BUILD_ENVCRC) += common/env_embedded.o @@ -182,7 +182,7 @@ $(obj)bmp_logo$(SFX): $(obj)bmp_logo.o $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ $(HOSTSTRIP) $@ -$(obj)proftool(SFX): $(obj)proftool.o +$(obj)proftool$(SFX): $(obj)proftool.o $(HOSTCC) $(HOSTCFLAGS) $(HOSTLDFLAGS) -o $@ $^ $(HOSTSTRIP) $@ -- 1.8.5.3 -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] Re: [RFC PATCH v2 00/11] mtd: nand: add sunxi NAND Flash Controller support
Hi all,
Some feedback based on my tests of the HW randomizer available in the
NFC controller
(you might already know what I found :-)):
- the HW randomizer uses a Fibonacci LFSR with the x^15 + x^14 + 1
feedback polynomial
(see http://en.wikipedia.org/wiki/Linear_feedback_shift_register for
more informations
on LFSR)
- the NFC controller resets the LSFR state each time a new TRANSFER CMD
is launched.
In my driver this means the LFSR is resetted to the specified SEED
value on each ECC step
size block transfer. I'm not sure this is the case for PAGE CMDs, did
someone already
checked this ?
The Fibonacci LFSR is pretty simple to implement, and I should be able
to propose a generic
interface to support randomizers in the NAND core code (including a SW
implementation of
a Fibonacci LFSR and the sunxi HW one) in the same way ECC handling is
exposed...
I'd also like to have your opinion on some of my reflexions.
If I understand correctly (tell me if I'm wrong), some MLC NANDs need to
scramble DATA
to avoid spurious bitflips when writing the same pattern on NAND pages
(see
http://etrij.etri.re.kr/Cyber/Download/PublishedPaper/3501/etrij.feb2013.0166.pdf).
The bitflips occurs when writing or reading on pages. These bitflips
always appears on pages
of the block being read or written, right ?
I guess this is why the base sunxi driver uses a seed table (to avoid
similar patterns on different
pages of a given block when writting the same pattern on the whole block).
Please tell me if you think I'm mistaken (I'm new to this whole MLC NAND
things).
I also thought about a nice way to define the randomizer seed table from
the DT(instead of
statically embedding it in the sunxi driver).
Here's what I came with:
nfc@xxx {
nand@0 {
allwinner,nand-randomizer-seeds = ;
};
};
The boot0 partition problem still remains, as the seed table differs in
this specific partition (always
uses 0x4A80)...
To solve this we might consider defining the seed table per partition
instead of defining it for the
whole flash.
Please feel free to share you knowledge and thoughts.
Best Regards,
Boris
On 15/01/2014 10:51, 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:
- 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)
This a pre v2 version (some rework asked by Jason Gunthorpe are not integrated
yet), hence why I only send this series to the sunxi dev ML.
Best Regards,
Boris
Changes since v1:
- add HW ECC support
Boris BREZILLON (11):
mtd: nand: retrieve ECC requirements from Hynix READ ID byte 4
mtd: nand: define struct nand_timings
of: mtd: add NAND timings retrieval support
of: mtd: add NAND timings bindings documentation
mtd: nand: add sunxi NFC 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 | 34 +
.../devicetree/bindings/mtd/sunxi-nand.txt | 78 ++
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 |1 +
drivers/mtd/nand/nand_base.c | 37 +
drivers/mtd/nand/sunxi_nand.c | 957
drivers/of/of_mtd.c| 47 +
include/linux/mtd/nand.h | 44 +
include/linux/of_mtd.h |9 +
11 files changed, 1279 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt
create mode 100644 drivers/mtd/nand/sunxi_nand.c
--
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 v5 14/14] ARM: sun7i: dts: Add ahci / sata support
On Wed, Jan 22, 2014 at 08:04:49PM +0100, Hans de Goede wrote:
> This patch adds sunxi sata support to A20 boards that have such a connector.
> Some boards also feature a regulator via a GPIO and support for this is also
> added.
>
> Signed-off-by: Olliver Schinagl
> Signed-off-by: Hans de Goede
> ---
> arch/arm/boot/dts/sun7i-a20-cubieboard2.dts | 6 ++
> arch/arm/boot/dts/sun7i-a20-cubietruck.dts | 20
> arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 6 ++
> arch/arm/boot/dts/sun7i-a20.dtsi| 8
> 4 files changed, 40 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> index 48777cd..1cab521 100644
> --- a/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-cubieboard2.dts
> @@ -13,6 +13,7 @@
>
> /dts-v1/;
> /include/ "sun7i-a20.dtsi"
> +/include/ "sunxi-ahci-reg.dtsi"
>
> / {
> model = "Cubietech Cubieboard2";
> @@ -28,6 +29,11 @@
> status = "okay";
> };
>
> + ahci: sata@01c18000 {
> + target-supply = <®_ahci_5v>;
> + status = "okay";
> + };
> +
> pinctrl@01c20800 {
> mmc0_cd_pin_cubieboard2: mmc0_cd_pin@0 {
> allwinner,pins = "PH1";
> diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> index 2684f27..1247ea1 100644
> --- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
> @@ -13,6 +13,7 @@
>
> /dts-v1/;
> /include/ "sun7i-a20.dtsi"
> +/include/ "sunxi-ahci-reg.dtsi"
>
> / {
> model = "Cubietech Cubietruck";
> @@ -28,6 +29,11 @@
> status = "okay";
> };
>
> + ahci: sata@01c18000 {
> + target-supply = <®_ahci_5v>;
> + status = "okay";
> + };
> +
> pinctrl@01c20800 {
> mmc0_cd_pin_cubietruck: mmc0_cd_pin@0 {
> allwinner,pins = "PH1";
> @@ -36,6 +42,13 @@
> allwinner,pull = <0>;
> };
>
> + ahci_pwr_pin_cubietruck: ahci_pwr_pin@1 {
> + allwinner,pins = "PH12";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
> +
> led_pins_cubietruck: led_pins@0 {
> allwinner,pins = "PH7", "PH11", "PH20", "PH21";
> allwinner,function = "gpio_out";
> @@ -84,4 +97,11 @@
> gpios = <&pio 7 7 0>;
> };
> };
> +
> + regulators {
> + reg_ahci_5v: ahci-5v {
> + pinctrl-0 = <&ahci_pwr_pin_cubietruck>;
> + gpio = <&pio 7 12 0>;
> + };
> + };
> };
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> index bf6f6c8..f135886 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
> @@ -13,6 +13,7 @@
>
> /dts-v1/;
> /include/ "sun7i-a20.dtsi"
> +/include/ "sunxi-ahci-reg.dtsi"
>
> / {
> model = "Olimex A20-Olinuxino Micro";
> @@ -37,6 +38,11 @@
> status = "okay";
> };
>
> + ahci: sata@01c18000 {
> + target-supply = <®_ahci_5v>;
> + status = "okay";
> + };
> +
> pinctrl@01c20800 {
> mmc0_cd_pin_olinuxinom: mmc0_cd_pin@0 {
> allwinner,pins = "PH1";
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index c9c123a..0657bad 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -347,6 +347,14 @@
> status = "disabled";
> };
>
> + ahci: sata@01c18000 {
> + compatible = "allwinner,sun4i-a10-ahci";
> + reg = <0x01c18000 0x1000>;
> + interrupts = <0 56 1>;
This is supposed to be a level triggered interrupt, not an edge
triggered one.
Thanks for your work!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[linux-sunxi] Re: [PATCH v5 13/14] ARM: sun4i: dts: Add ahci / sata support
Hi Hans,
On Wed, Jan 22, 2014 at 08:04:48PM +0100, Hans de Goede wrote:
> From: Oliver Schinagl
>
> This patch adds sunxi sata support to A10 boards that have such a connector.
> Some boards also feature a regulator via a GPIO and support for this is also
> added.
>
> Signed-off-by: Olliver Schinagl
> Signed-off-by: Hans de Goede
> ---
> arch/arm/boot/dts/sun4i-a10-a1000.dts | 4
> arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 6 +
> arch/arm/boot/dts/sun4i-a10.dtsi | 8 +++
> arch/arm/boot/dts/sunxi-ahci-reg.dtsi | 38
> ++
I'm still half convinced about this at the moment, given the number of
platforms we support, we can always change it back if things become too messy.
> 4 files changed, 56 insertions(+)
> create mode 100644 arch/arm/boot/dts/sunxi-ahci-reg.dtsi
>
> diff --git a/arch/arm/boot/dts/sun4i-a10-a1000.dts
> b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> index aef8207..3fb7305 100644
> --- a/arch/arm/boot/dts/sun4i-a10-a1000.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-a1000.dts
> @@ -48,6 +48,10 @@
> status = "okay";
> };
>
> + ahci: sata@01c18000 {
> + status = "okay";
> + };
> +
> pinctrl@01c20800 {
> mmc0_cd_pin_a1000: mmc0_cd_pin@0 {
> allwinner,pins = "PH1";
> diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> index f50fb2b..6ae1110 100644
> --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> @@ -12,6 +12,7 @@
>
> /dts-v1/;
> /include/ "sun4i-a10.dtsi"
> +/include/ "sunxi-ahci-reg.dtsi"
>
> / {
> model = "Cubietech Cubieboard";
> @@ -51,6 +52,11 @@
> status = "okay";
> };
>
> + ahci: sata@01c18000 {
> + target-supply = <®_ahci_5v>;
> + status = "okay";
> + };
> +
> pinctrl@01c20800 {
> mmc0_cd_pin_cubieboard: mmc0_cd_pin@0 {
> allwinner,pins = "PH1";
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi
> b/arch/arm/boot/dts/sun4i-a10.dtsi
> index 4736dd2..198dcda 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -331,6 +331,14 @@
> status = "disabled";
> };
>
> + ahci: sata@01c18000 {
> + compatible = "allwinner,sun4i-a10-ahci";
To be consistent with the rest of the sun4i devices compatible, It
should be sun4i-ahci.
However, since these devices don't use the same compatible pattern as
their own machine compatible, and are consisent with the rest of the
compatibles for the other SoCs, we can probably make this a go to
transition progressively to this pattern.
I'll cook up some patches for the other devices.
> + reg = <0x01c18000 0x1000>;
> + interrupts = <56>;
> + clocks = <&pll6 0>, <&ahb_gates 25>;
> + status = "disabled";
> + };
> +
> intc: interrupt-controller@01c20400 {
> compatible = "allwinner,sun4i-ic";
> reg = <0x01c20400 0x400>;
> diff --git a/arch/arm/boot/dts/sunxi-ahci-reg.dtsi
> b/arch/arm/boot/dts/sunxi-ahci-reg.dtsi
> new file mode 100644
> index 000..955b197
> --- /dev/null
> +++ b/arch/arm/boot/dts/sunxi-ahci-reg.dtsi
> @@ -0,0 +1,38 @@
> +/*
> + * sunxi boards sata target power supply common code
> + *
> + * Copyright 2014 - Hans de Goede
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + */
> +
> +/ {
> + soc@01c0 {
> + ahci_pwr_pin_a: ahci_pwr_pin@0 {
> + allwinner,pins = "PB8";
> + allwinner,function = "gpio_out";
> + allwinner,drive = <0>;
> + allwinner,pull = <0>;
> + };
This should be under the pinctrl node.
Thanks!
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 3/5] spi: sunxi: Add Allwinner A31 SPI controller driver
On Fri, Jan 31, 2014 at 12:48:09PM +, Mark Brown wrote:
> On Fri, Jan 31, 2014 at 11:55:50AM +0100, Maxime Ripard wrote:
>
> > + master = devm_spi_alloc_master(&pdev->dev, sizeof(struct sun6i_spi));
> > + if (!master) {
> > + dev_err(&pdev->dev, "Unable to allocate SPI Master\n");
> > + return -ENOMEM;
> > + }
>
> This now depends on your other series which as I said doesn't look like
> the best approach.
Indeed, I forgot to mention it in the cover letter. My bad.
>
> > + pm_runtime_enable(&pdev->dev);
> > + if (!pm_runtime_enabled(&pdev->dev)) {
> > + ret = sun6i_spi_runtime_resume(&pdev->dev);
> > + if (ret) {
> > + dev_err(&pdev->dev, "Couldn't resume the device\n");
> > + return ret;
> > + }
> > + }
>
> No, as discussed don't do this - notice how other drivers aren't written
> this way either. Like I said leave the device powered on startup and
> then let it be idled by runtime PM.
Well, some SPI drivers are actually written like that (all the tegra
SPI drivers for example). It's not an excuse, but waking up the device
only to put it back in suspend right away seems kind of
inefficient. Plus, the pm_runtime_idle callback you suggested are
actually calling runtime_idle, while we want to call runtime_suspend.
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
[linux-sunxi] Mainline and Headless devices
Is mainline "workable" as a headless device ? I don't need any GUI, as long as I have SSH to login. :-) Thanks, R -- 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] Mainline and Headless devices
Hi, On Fri, Jan 31, 2014 at 02:51:21PM -0800, Rosimildo DaSilva wrote: > Is mainline "workable" as a headless device ? > I don't need any GUI, as long as I have SSH to login. :-) Yes and no. It depends on which SoC you use, and what features you expect. If you want to use either an A10, A10s, A13 or A20, network will work, some other features might not. Could you provide a bit more informations here? Thanks, Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Mainline and Headless devices
Thanks Maxime. I'd like to run on Mele/CB1/Cubietruck. A CT would be my first choice. All I need is: Network, wired and/or wi-fi. RootFS from SD card or Nand, whatever it is easier. And finally USB functionality. This I need to plug some cheap camera, and use ffmpeg to send a stream out. Nothing major. R On Friday, January 31, 2014 5:11:35 PM UTC-6, Maxime Ripard wrote: > > Hi, > > On Fri, Jan 31, 2014 at 02:51:21PM -0800, Rosimildo DaSilva wrote: > > Is mainline "workable" as a headless device ? > > I don't need any GUI, as long as I have SSH to login. :-) > > Yes and no. > > It depends on which SoC you use, and what features you expect. > > If you want to use either an A10, A10s, A13 or A20, network will work, > some other features might not. > > Could you provide a bit more informations here? > > Thanks, > Maxime > > -- > Maxime Ripard, Free Electrons > Embedded Linux, Kernel and Android engineering > http://free-electrons.com > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[linux-sunxi] new version of TabletWM
Hi all: Today I released a new version of TabletWM, the minimalistic window manager oriented to tablets (I developed it to be used with my A13-based tablet). It can be found at my git repository: https://github.com/rastersoft/tabletwm -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.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.
