[linux-sunxi] H3 cpu frequencies and PLL.

2017-06-14 Thread Mark L . 
Hi,While creating the boot configuration (CCU registers) for a Allwinner H3 board, relying on a Cortex a7 quad, came the question of the cpu frequency scale.The reference clock frequency is 24MHz.u-boot has the following codestatic struct {    u32 pll1_cfg;    unsigned int freq;} pll1_para[] = {    /* This array must be ordered by frequency. */    { PLL1_CFG(31, 1, 0, 0), 148800},    { PLL1_CFG(30, 1, 0, 0), 144000},    { PLL1_CFG(29, 1, 0, 0), 139200},    { PLL1_CFG(28, 1, 0, 0), 134400},    { PLL1_CFG(27, 1, 0, 0), 129600},    { PLL1_CFG(26, 1, 0, 0), 124800},    { PLL1_CFG(25, 1, 0, 0), 12},    { PLL1_CFG(24, 1, 0, 0), 115200},    { PLL1_CFG(23, 1, 0, 0), 110400},    { PLL1_CFG(22, 1, 0, 0), 105600},    { PLL1_CFG(21, 1, 0, 0), 100800},    { PLL1_CFG(20, 1, 0, 0), 96000 },    { PLL1_CFG(19, 1, 0, 0), 91200 },    { PLL1_CFG(16, 1, 0, 0), 76800 },    /* Final catchall entry 384MHz*/    { PLL1_CFG(16, 0, 0, 0), 0 },};We can see that we have a lot of working values for our cpu freq.PLL for the CPU is given as:[code](24MHz * N * K) / (M * P) [/code]If I want a cpu running at 960MHz (severe downclock for power saving reasons), I can use [code](24 * 20 * 2) / (1 * 1) = 960[/code]or[code]N * (24 << K) = 20 * (24 << 1) = 960.[/code]NOW, with 0<= N <=31 and 0<= K <= 4 (legal values according to the reference manual), I could also have [code](24 * 10 * 4) / (1 * 1) = 960[/code]or[code]10 *(24<<2) =960 [/code]Can someone tell me the difference between those two strategies at the cpu/board level? Are there known unstable values?I mean, we get the same frequency result, but with different parameters. Any difference at the consumption level? Will it catch me later?Thanks-- Mark



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

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

2017-06-14 Thread Icenowy Zheng 


于 2017年6月15日 GMT+08:00 上午11:54:08, Vinod Koul  写到:
>On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
>> On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
>> > > SoC info is in compatible, so there's no reason to make it a
>property.
>> > 
>> > that's why it would need to be optional for the SoC's that needs
>these..
>> 
>> There's nothing optional about that behaviour, it's mandatory for the
>> SoC that need it, and useless on the SoC that don't.
>
>And why should kernel put strings for each hw behaviour. I am expecting
>DT
>to tell me if this SoC is a special case or not and kernel shall handle
>accordingly

I don't think this kind of behavior should be described in DT.

Rob, do you agree?

>
>> Plus, that would require changing the DT binding, which isn't
>> something we can do.
>
>Any reason why bindings can't change..? I though this was support for
>new
>SoC...

This is a behavior that exists on a SoC that is already
supported (A23/A33).

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

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

2017-06-14 Thread Vinod Koul 
On Wed, Jun 14, 2017 at 11:04:39AM +0200, Maxime Ripard wrote:
> On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
> > > SoC info is in compatible, so there's no reason to make it a property.
> > 
> > that's why it would need to be optional for the SoC's that needs these..
> 
> There's nothing optional about that behaviour, it's mandatory for the
> SoC that need it, and useless on the SoC that don't.

And why should kernel put strings for each hw behaviour. I am expecting DT
to tell me if this SoC is a special case or not and kernel shall handle
accordingly

> Plus, that would require changing the DT binding, which isn't
> something we can do.

Any reason why bindings can't change..? I though this was support for new
SoC...

-- 
~Vinod

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

[linux-sunxi] [PATCH v3] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

2017-06-14 Thread Jonathan Liu 
The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
"As in the general case the DDC bus is accessible by the kernel at the I2C
level, drivers must make all reasonable efforts to expose it as an I2C
adapter and use drm_get_edid() instead of abusing this function."

Exposing the DDC bus as an I2C adapter is more beneficial as it can be used
for purposes other than reading the EDID such as modifying the EDID or
using the HDMI DDC pins as an I2C bus through the I2C dev interface from
userspace (e.g. i2c-tools).

Implement this for A10s.

Signed-off-by: Jonathan Liu 
---
Changes for v3:
 - Explain why drm_do_get_edid should be used and why it's better to expose it
   as an I2C adapter in commit message
 - Reorder bit defines in descending order for consistency
 - Keep old unused macros instead of removing them
 - The v2 algorithm split large transfers into 16 byte transfers but this may
   cause a large single write to be treated as multiple writes causing data
   corruption. The algorithm has been reworked to not split larger transfers
   and make more use of the FIFO to avoid this.
 - Moved the creation of the DDC clock from sun4i_hdmi_enc.c to
   sun4i_hdmi_i2c.c
 - Reformatted code
 - Instead of masking bits that we don't want to check for errors, explicitly
   check the error bits
 - Clear error bits at start of transfer in case of error from previous transfer
 - Poll for completion of FIFO clear after setting FIFO clear bit

Changes for v2:
 - Rebased against Maxime's sunxi-drm/for-next branch
 - Fix up error paths in sun4i_hdmi_bind so that the I2C adapter is deleted if
   any of the calls after the I2C adapter is created fails
 - Remove unnecessary includes in sun4i_hdmi_i2c.c

 drivers/gpu/drm/sun4i/Makefile |   1 +
 drivers/gpu/drm/sun4i/sun4i_hdmi.h |  21 
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 101 ++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 220 +
 4 files changed, 253 insertions(+), 90 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c

diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index e29fd3a2ba9c..43c753cafc88 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -2,6 +2,7 @@ sun4i-drm-y += sun4i_drv.o
 sun4i-drm-y += sun4i_framebuffer.o
 
 sun4i-drm-hdmi-y += sun4i_hdmi_enc.o
+sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
 sun4i-drm-hdmi-y += sun4i_hdmi_ddc_clk.o
 sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 2f2f2ff1ea63..018af9cbb593 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -96,6 +96,7 @@
 #define SUN4I_HDMI_DDC_CTRL_ENABLE BIT(31)
 #define SUN4I_HDMI_DDC_CTRL_START_CMD  BIT(30)
 #define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_MASK  BIT(8)
+#define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_WRITE (1 << 8)
 #define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_READ  (0 << 8)
 #define SUN4I_HDMI_DDC_CTRL_RESET  BIT(0)
 
@@ -105,14 +106,30 @@
 #define SUN4I_HDMI_DDC_ADDR_OFFSET(off)(((off) & 0xff) << 8)
 #define SUN4I_HDMI_DDC_ADDR_SLAVE(addr)((addr) & 0xff)
 
+#define SUN4I_HDMI_DDC_INT_STATUS_REG  0x50c
+#define SUN4I_HDMI_DDC_INT_STATUS_ILLEGAL_FIFO_OPERATION   BIT(7)
+#define SUN4I_HDMI_DDC_INT_STATUS_DDC_RX_FIFO_UNDERFLOWBIT(6)
+#define SUN4I_HDMI_DDC_INT_STATUS_DDC_TX_FIFO_UNDERFLOWBIT(5)
+#define SUN4I_HDMI_DDC_INT_STATUS_FIFO_REQUEST BIT(4)
+#define SUN4I_HDMI_DDC_INT_STATUS_ARBITRATION_ERRORBIT(3)
+#define SUN4I_HDMI_DDC_INT_STATUS_ACK_ERRORBIT(2)
+#define SUN4I_HDMI_DDC_INT_STATUS_BUS_ERRORBIT(1)
+#define SUN4I_HDMI_DDC_INT_STATUS_TRANSFER_COMPLETEBIT(0)
+
 #define SUN4I_HDMI_DDC_FIFO_CTRL_REG   0x510
 #define SUN4I_HDMI_DDC_FIFO_CTRL_CLEAR BIT(31)
 
+#define SUN4I_HDMI_DDC_FIFO_STATUS_REG 0x514
+#define SUN4I_HDMI_DDC_FIFO_STATUS_FULLBIT(6)
+#define SUN4I_HDMI_DDC_FIFO_STATUS_EMPTY   BIT(5)
+
 #define SUN4I_HDMI_DDC_FIFO_DATA_REG   0x518
 #define SUN4I_HDMI_DDC_BYTE_COUNT_REG  0x51c
 
 #define SUN4I_HDMI_DDC_CMD_REG 0x520
 #define SUN4I_HDMI_DDC_CMD_EXPLICIT_EDDC_READ  6
+#define SUN4I_HDMI_DDC_CMD_IMPLICIT_READ   5
+#define SUN4I_HDMI_DDC_CMD_IMPLICIT_WRITE  3
 
 #define SUN4I_HDMI_DDC_CLK_REG 0x528
 #define SUN4I_HDMI_DDC_CLK_M(m)(((m) & 0x7) << 3)
@@ -123,6 +140,7 @@
 #define SUN4I_HDMI_DDC_LINE_CTRL_SCL_ENABLEBIT(8)
 
 #define SUN4I_HDMI_DDC_FIFO_SIZE   16
+#define SUN4I_HDMI_DDC_MAX_TRANSFER_SIZE   1023
 
 enum sun4i_hdmi_pkt_type {
SUN4I_HDMI_PKT_AVI = 2,
@@ -146,6 +164,8 @@ struct sun4i_hdmi {
struct clk  *ddc_clk;
struct clk  *tmds_clk;
 
+   struct i2c_adapter  *i2c;
+
struct sun4i_drv*drv;
 
boolhdmi_monitor;
@@ -153,5 +173,6 @@ struct

[linux-sunxi] [PATCH] drm/sun4i: hdmi: Implement I2C adapter for A10s DDC bus

2017-06-14 Thread Jonathan Liu 
The documentation for drm_do_get_edid in drivers/gpu/drm/drm_edid.c states:
"As in the general case the DDC bus is accessible by the kernel at the I2C
level, drivers must make all reasonable efforts to expose it as an I2C
adapter and use drm_get_edid() instead of abusing this function."

Exposing the DDC bus as an I2C adapter is more beneficial as it can be used
for purposes other than reading the EDID such as modifying the EDID or
using the HDMI DDC pins as an I2C bus through the I2C dev interface from
userspace (e.g. i2c-tools).

Implement this for A10s.

Signed-off-by: Jonathan Liu 
---
Changes for v3:
 - Explain why drm_do_get_edid should be used and why it's better to expose it
   as an I2C adapter in commit message
 - Reorder bit defines in descending order for consistency
 - Keep old unused macros instead of removing them
 - The v2 algorithm split large transfers into 16 byte transfers but this may
   cause a large single write to be treated as multiple writes causing data
   corruption. The algorithm has been reworked to not split larger transfers
   and make more use of the FIFO to avoid this.
 - Moved the creation of the DDC clock from sun4i_hdmi_enc.c to
   sun4i_hdmi_i2c.c
 - Reformatted code
 - Instead of masking bits that we don't want to check for errors, explicitly
   check the error bits
 - Clear error bits at start of transfer in case of error from previous transfer
 - Poll for completion of FIFO clear after setting FIFO clear bit

Changes for v2:
 - Rebased against Maxime's sunxi-drm/for-next branch
 - Fix up error paths in sun4i_hdmi_bind so that the I2C adapter is deleted if
   any of the calls after the I2C adapter is created fails
 - Remove unnecessary includes in sun4i_hdmi_i2c.c

 drivers/gpu/drm/sun4i/Makefile |   1 +
 drivers/gpu/drm/sun4i/sun4i_hdmi.h |  21 
 drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 101 ++-
 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c | 220 +
 4 files changed, 253 insertions(+), 90 deletions(-)
 create mode 100644 drivers/gpu/drm/sun4i/sun4i_hdmi_i2c.c

diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index e29fd3a2ba9c..43c753cafc88 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -2,6 +2,7 @@ sun4i-drm-y += sun4i_drv.o
 sun4i-drm-y += sun4i_framebuffer.o
 
 sun4i-drm-hdmi-y += sun4i_hdmi_enc.o
+sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
 sun4i-drm-hdmi-y += sun4i_hdmi_ddc_clk.o
 sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
 
diff --git a/drivers/gpu/drm/sun4i/sun4i_hdmi.h 
b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
index 2f2f2ff1ea63..018af9cbb593 100644
--- a/drivers/gpu/drm/sun4i/sun4i_hdmi.h
+++ b/drivers/gpu/drm/sun4i/sun4i_hdmi.h
@@ -96,6 +96,7 @@
 #define SUN4I_HDMI_DDC_CTRL_ENABLE BIT(31)
 #define SUN4I_HDMI_DDC_CTRL_START_CMD  BIT(30)
 #define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_MASK  BIT(8)
+#define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_WRITE (1 << 8)
 #define SUN4I_HDMI_DDC_CTRL_FIFO_DIR_READ  (0 << 8)
 #define SUN4I_HDMI_DDC_CTRL_RESET  BIT(0)
 
@@ -105,14 +106,30 @@
 #define SUN4I_HDMI_DDC_ADDR_OFFSET(off)(((off) & 0xff) << 8)
 #define SUN4I_HDMI_DDC_ADDR_SLAVE(addr)((addr) & 0xff)
 
+#define SUN4I_HDMI_DDC_INT_STATUS_REG  0x50c
+#define SUN4I_HDMI_DDC_INT_STATUS_ILLEGAL_FIFO_OPERATION   BIT(7)
+#define SUN4I_HDMI_DDC_INT_STATUS_DDC_RX_FIFO_UNDERFLOWBIT(6)
+#define SUN4I_HDMI_DDC_INT_STATUS_DDC_TX_FIFO_UNDERFLOWBIT(5)
+#define SUN4I_HDMI_DDC_INT_STATUS_FIFO_REQUEST BIT(4)
+#define SUN4I_HDMI_DDC_INT_STATUS_ARBITRATION_ERRORBIT(3)
+#define SUN4I_HDMI_DDC_INT_STATUS_ACK_ERRORBIT(2)
+#define SUN4I_HDMI_DDC_INT_STATUS_BUS_ERRORBIT(1)
+#define SUN4I_HDMI_DDC_INT_STATUS_TRANSFER_COMPLETEBIT(0)
+
 #define SUN4I_HDMI_DDC_FIFO_CTRL_REG   0x510
 #define SUN4I_HDMI_DDC_FIFO_CTRL_CLEAR BIT(31)
 
+#define SUN4I_HDMI_DDC_FIFO_STATUS_REG 0x514
+#define SUN4I_HDMI_DDC_FIFO_STATUS_FULLBIT(6)
+#define SUN4I_HDMI_DDC_FIFO_STATUS_EMPTY   BIT(5)
+
 #define SUN4I_HDMI_DDC_FIFO_DATA_REG   0x518
 #define SUN4I_HDMI_DDC_BYTE_COUNT_REG  0x51c
 
 #define SUN4I_HDMI_DDC_CMD_REG 0x520
 #define SUN4I_HDMI_DDC_CMD_EXPLICIT_EDDC_READ  6
+#define SUN4I_HDMI_DDC_CMD_IMPLICIT_READ   5
+#define SUN4I_HDMI_DDC_CMD_IMPLICIT_WRITE  3
 
 #define SUN4I_HDMI_DDC_CLK_REG 0x528
 #define SUN4I_HDMI_DDC_CLK_M(m)(((m) & 0x7) << 3)
@@ -123,6 +140,7 @@
 #define SUN4I_HDMI_DDC_LINE_CTRL_SCL_ENABLEBIT(8)
 
 #define SUN4I_HDMI_DDC_FIFO_SIZE   16
+#define SUN4I_HDMI_DDC_MAX_TRANSFER_SIZE   1023
 
 enum sun4i_hdmi_pkt_type {
SUN4I_HDMI_PKT_AVI = 2,
@@ -146,6 +164,8 @@ struct sun4i_hdmi {
struct clk  *ddc_clk;
struct clk  *tmds_clk;
 
+   struct i2c_adapter  *i2c;
+
struct sun4i_drv*drv;
 
boolhdmi_monitor;
@@ -153,5 +173,6 @@ struct

[linux-sunxi] [PATCH v3] sun50i: h5: Add initial NanoPi NEO2 support

2017-06-14 Thread Jagan Teki 
From: Jagan Teki 

NanoPi NEO2 is designed and developed by FriendlyElec
using the Allwinner 64-bit H5 SOC.

NanoPi Neo2 key features
- Allwinner H5, Quad-core 64-bit Cortex-A53
- 512MB DDR3 RAM
- microSD slot
- 10/100/1000M Ethernet
- Serial Debug Port
- 5V 2A DC MicroUSB power-supply

Signed-off-by: Jagan Teki 
Tested-by: Jagan Teki 
---
Changes for v3:
- Fix Copy'n'paste error in commit message
Changes for v2:
- Droped memory node
- Remove /soc under regulator
- Tested on neo2 

 arch/arm/dts/Makefile  |  1 +
 arch/arm/dts/sun50i-h5-nanopi-neo2.dts | 86 ++
 board/sunxi/MAINTAINERS|  5 ++
 configs/nanopi_neo2_defconfig  | 16 +++
 4 files changed, 108 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-h5-nanopi-neo2.dts
 create mode 100644 configs/nanopi_neo2_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a6eab75..5d7432f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -319,6 +319,7 @@ dtb-$(CONFIG_MACH_SUN8I_R40) += \
 dtb-$(CONFIG_MACH_SUN8I_V3S) += \
sun8i-v3s-licheepi-zero.dtb
 dtb-$(CONFIG_MACH_SUN50I_H5) += \
+   sun50i-h5-nanopi-neo2.dtb \
sun50i-h5-orangepi-pc2.dtb \
sun50i-h5-orangepi-prime.dtb \
sun50i-h5-orangepi-zero-plus2.dtb
diff --git a/arch/arm/dts/sun50i-h5-nanopi-neo2.dts 
b/arch/arm/dts/sun50i-h5-nanopi-neo2.dts
new file mode 100644
index 000..c08af78
--- /dev/null
+++ b/arch/arm/dts/sun50i-h5-nanopi-neo2.dts
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2017 Icenowy Zheng 
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h5.dtsi"
+
+#include 
+
+/ {
+   model = "FriendlyARM NanoPi NEO 2";
+   compatible = "friendlyarm,nanopi-neo2", "allwinner,sun50i-h5";
+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+};
+
+&mmc0 {
+   compatible = "allwinner,sun50i-h5-mmc",
+"allwinner,sun50i-a64-mmc",
+"allwinner,sun5i-a13-mmc";
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+   vmmc-supply = <®_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+   status = "okay";
+};
+
+&uart0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart0_pins_a>;
+   status = "okay";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 77d8d17..e9f3e35 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -257,6 +257,11 @@ M: Jelle van der Waa 
 S: Maintained
 F: configs/nanopi_neo_defconfig
 
+NANOPI-NEO2 BOARD
+M: Jagan Teki 
+S: Maintained
+F: configs/nanopi_neo2_defc

Re: [linux-sunxi] [PATCH v2] sun50i: h5: Add initial NanoPi NEO2 support

2017-06-14 Thread icenowy 

在 2017-06-13 18:10，Jagan Teki 写道：

From: Jagan Teki 

NanoPi M1 Plus is designed and developed by FriendlyElec
using the Allwinner 64-bit H5 SOC.


Copy'n'paste error?



NanoPi Neo2 key features
- Allwinner H5, Quad-core 64-bit Cortex-A53
- 512MB DDR3 RAM
- microSD slot
- 10/100/1000M Ethernet
- Serial Debug Port
- 5V 2A DC MicroUSB power-supply

Signed-off-by: Jagan Teki 
Tested-by: Jagan Teki 
---
Changes for v2:
- Droped memory node
- Remove /soc under regulator
- Tested on neo2

 arch/arm/dts/Makefile  |  1 +
 arch/arm/dts/sun50i-h5-nanopi-neo2.dts | 86 
++

 board/sunxi/MAINTAINERS|  5 ++
 configs/nanopi_neo2_defconfig  | 16 +++
 4 files changed, 108 insertions(+)
 create mode 100644 arch/arm/dts/sun50i-h5-nanopi-neo2.dts
 create mode 100644 configs/nanopi_neo2_defconfig

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index a6eab75..5d7432f 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -319,6 +319,7 @@ dtb-$(CONFIG_MACH_SUN8I_R40) += \
 dtb-$(CONFIG_MACH_SUN8I_V3S) += \
sun8i-v3s-licheepi-zero.dtb
 dtb-$(CONFIG_MACH_SUN50I_H5) += \
+   sun50i-h5-nanopi-neo2.dtb \
sun50i-h5-orangepi-pc2.dtb \
sun50i-h5-orangepi-prime.dtb \
sun50i-h5-orangepi-zero-plus2.dtb
diff --git a/arch/arm/dts/sun50i-h5-nanopi-neo2.dts
b/arch/arm/dts/sun50i-h5-nanopi-neo2.dts
new file mode 100644
index 000..c08af78
--- /dev/null
+++ b/arch/arm/dts/sun50i-h5-nanopi-neo2.dts
@@ -0,0 +1,86 @@
+/*
+ * Copyright (C) 2017 Icenowy Zheng 
+ * Copyright (C) 2017 Jagan Teki 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of 
the

+ * License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+
+#include "sun50i-h5.dtsi"
+
+#include 
+
+/ {
+   model = "FriendlyARM NanoPi NEO 2";
+   compatible = "friendlyarm,nanopi-neo2", "allwinner,sun50i-h5";
+
+   aliases {
+   serial0 = &uart0;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   reg_vcc3v3: vcc3v3 {
+   compatible = "regulator-fixed";
+   regulator-name = "vcc3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   };
+};
+
+&mmc0 {
+   compatible = "allwinner,sun50i-h5-mmc",
+"allwinner,sun50i-a64-mmc",
+"allwinner,sun5i-a13-mmc";
+   pinctrl-names = "default";
+   pinctrl-0 = <&mmc0_pins_a>, <&mmc0_cd_pin>;
+   vmmc-supply = <®_vcc3v3>;
+   bus-width = <4>;
+   cd-gpios = <&pio 5 6 GPIO_ACTIVE_LOW>; /* PF6 */
+   status = "okay";
+};
+
+&uart0 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart0_pins_a>;
+   status = "okay";
+};
diff --git a/board/sunxi/MAINTAINERS b/board/sunxi/MAINTAINERS
index 77d8d17..e9f3e35 100644
--- a/board/sunxi/MAINTAINERS
+++ b/board/sunxi/MAINTAINERS
@@ -257,6 +257,11 @@ M: Jelle van der Waa 
 S: Maintained
 F: configs/nanopi_neo_defconfig

+NANOPI-NEO2 BOARD
+M: Jagan Teki 
+S: Maintained
+F: configs/nanopi_neo2

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

2017-06-14 Thread Maxime Ripard 
On Wed, Jun 14, 2017 at 02:15:29PM +0530, Vinod Koul wrote:
> > SoC info is in compatible, so there's no reason to make it a property.
> 
> that's why it would need to be optional for the SoC's that needs these..

There's nothing optional about that behaviour, it's mandatory for the
SoC that need it, and useless on the SoC that don't.

Plus, that would require changing the DT binding, which isn't
something we can do.

Maxime

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

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


signature.asc
Description: PGP signature

Re: [linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

2017-06-14 Thread Icenowy Zheng 


于 2017年6月14日 GMT+08:00 下午4:45:29, Vinod Koul  写到:
>On Wed, Jun 14, 2017 at 04:32:57PM +0800, Icenowy Zheng wrote:
>> 
>> 
>> 于 2017年6月14日 GMT+08:00 下午4:32:52, Vinod Koul 
>写到:
>> >On Mon, Jun 05, 2017 at 08:33:47PM +0800, Icenowy Zheng wrote:
>> >> From: Icenowy Zheng 
>> >> 
>> >> Originally we enable a special gate bit when the compatible
>indicates
>> >> A23/33.
>> >> 
>> >> But according to BSP sources and user manuals, more SoCs will need
>> >this
>> >> gate bit.
>> >> 
>> >> So make it a common quirk configured in the config struct.
>> >> 
>> >> Signed-off-by: Icenowy Zheng 
>> >> ---
>> >> Changes since original codec patchset v3:
>> >> - Refactored comments to cover some words found in official
>> >documents.
>> >> - Removed the comments when toggling the gate bit.
>> >> 
>> >>  drivers/dma/sun6i-dma.c | 20 +---
>> >>  1 file changed, 13 insertions(+), 7 deletions(-)
>> >> 
>> >> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
>> >> index a2358780ab2c..252b59c1d1d5 100644
>> >> --- a/drivers/dma/sun6i-dma.c
>> >> +++ b/drivers/dma/sun6i-dma.c
>> >> @@ -101,6 +101,17 @@ struct sun6i_dma_config {
>> >>   u32 nr_max_channels;
>> >>   u32 nr_max_requests;
>> >>   u32 nr_max_vchans;
>> >> + /*
>> >> +  * In the datasheets/user manuals of newer Allwinner SoCs, a
>> >special
>> >> +  * bit (bit 2 at register 0x20) is present.
>> >> +  * It's named "DMA MCLK interface circuit auto gating bit" in
>the
>> >> +  * documents, and the footnote of this register says that this
>bit
>> >> +  * should be set up when initializing the DMA controller.
>> >> +  * Allwinner A23/A33 user manuals do not have this bit
>documented,
>> >> +  * however these SoCs really have and need this bit, as seen in
>the
>> >> +  * BSP kernel source code.
>> >> +  */
>> >> + bool gate_needed;
>> >
>> >Since this is a hw property, why is this not added as an optional DT
>> >property?
>> 
>> As it's SoC-specified.
>> 
>> Some SoCs need it, and some don't.
>
>and that is the reason it should be a property
>
>> 
>> SoC info is in compatible, so there's no reason to make it a
>property.
>
>that's why it would need to be optional for the SoC's that needs
>these..

I don't think it proper to add block-specified properties
that can be bound to compatible.

I added Rob Herring to the recipient list.

Rob, do you think this can be added as a property?

This is SoC-specific and compatibles are also SoC-specific.

>
>> 
>> >
>> >>  };
>> >>  
>> >>  /*
>> >> @@ -1009,6 +1020,7 @@ static struct sun6i_dma_config
>> >sun8i_a23_dma_cfg = {
>> >>   .nr_max_channels = 8,
>> >>   .nr_max_requests = 24,
>> >>   .nr_max_vchans   = 37,
>> >> + .gate_needed = true,
>> >>  };
>> >>  
>> >>  static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
>> >> @@ -1174,13 +1186,7 @@ static int sun6i_dma_probe(struct
>> >platform_device *pdev)
>> >>   goto err_dma_unregister;
>> >>   }
>> >>  
>> >> - /*
>> >> -  * sun8i variant requires us to toggle a dma gating register,
>> >> -  * as seen in Allwinner's SDK. This register is not documented
>> >> -  * in the A23 user manual.
>> >> -  */
>> >> - if (of_device_is_compatible(pdev->dev.of_node,
>> >> - "allwinner,sun8i-a23-dma"))
>> >> + if (sdc->cfg->gate_needed)
>> >>   writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
>> >>  
>> >>   return 0;
>> >> -- 
>> >> 2.12.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/d/optout.

[linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

2017-06-14 Thread Vinod Koul 
On Wed, Jun 14, 2017 at 04:32:57PM +0800, Icenowy Zheng wrote:
> 
> 
> 于 2017年6月14日 GMT+08:00 下午4:32:52, Vinod Koul  写到:
> >On Mon, Jun 05, 2017 at 08:33:47PM +0800, Icenowy Zheng wrote:
> >> From: Icenowy Zheng 
> >> 
> >> Originally we enable a special gate bit when the compatible indicates
> >> A23/33.
> >> 
> >> But according to BSP sources and user manuals, more SoCs will need
> >this
> >> gate bit.
> >> 
> >> So make it a common quirk configured in the config struct.
> >> 
> >> Signed-off-by: Icenowy Zheng 
> >> ---
> >> Changes since original codec patchset v3:
> >> - Refactored comments to cover some words found in official
> >documents.
> >> - Removed the comments when toggling the gate bit.
> >> 
> >>  drivers/dma/sun6i-dma.c | 20 +---
> >>  1 file changed, 13 insertions(+), 7 deletions(-)
> >> 
> >> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> >> index a2358780ab2c..252b59c1d1d5 100644
> >> --- a/drivers/dma/sun6i-dma.c
> >> +++ b/drivers/dma/sun6i-dma.c
> >> @@ -101,6 +101,17 @@ struct sun6i_dma_config {
> >>u32 nr_max_channels;
> >>u32 nr_max_requests;
> >>u32 nr_max_vchans;
> >> +  /*
> >> +   * In the datasheets/user manuals of newer Allwinner SoCs, a
> >special
> >> +   * bit (bit 2 at register 0x20) is present.
> >> +   * It's named "DMA MCLK interface circuit auto gating bit" in the
> >> +   * documents, and the footnote of this register says that this bit
> >> +   * should be set up when initializing the DMA controller.
> >> +   * Allwinner A23/A33 user manuals do not have this bit documented,
> >> +   * however these SoCs really have and need this bit, as seen in the
> >> +   * BSP kernel source code.
> >> +   */
> >> +  bool gate_needed;
> >
> >Since this is a hw property, why is this not added as an optional DT
> >property?
> 
> As it's SoC-specified.
> 
> Some SoCs need it, and some don't.

and that is the reason it should be a property

> 
> SoC info is in compatible, so there's no reason to make it a property.

that's why it would need to be optional for the SoC's that needs these..

> 
> >
> >>  };
> >>  
> >>  /*
> >> @@ -1009,6 +1020,7 @@ static struct sun6i_dma_config
> >sun8i_a23_dma_cfg = {
> >>.nr_max_channels = 8,
> >>.nr_max_requests = 24,
> >>.nr_max_vchans   = 37,
> >> +  .gate_needed = true,
> >>  };
> >>  
> >>  static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
> >> @@ -1174,13 +1186,7 @@ static int sun6i_dma_probe(struct
> >platform_device *pdev)
> >>goto err_dma_unregister;
> >>}
> >>  
> >> -  /*
> >> -   * sun8i variant requires us to toggle a dma gating register,
> >> -   * as seen in Allwinner's SDK. This register is not documented
> >> -   * in the A23 user manual.
> >> -   */
> >> -  if (of_device_is_compatible(pdev->dev.of_node,
> >> -  "allwinner,sun8i-a23-dma"))
> >> +  if (sdc->cfg->gate_needed)
> >>writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
> >>  
> >>return 0;
> >> -- 
> >> 2.12.2
> >> 

-- 
~Vinod

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

[linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

2017-06-14 Thread Icenowy Zheng 


于 2017年6月14日 GMT+08:00 下午4:32:52, Vinod Koul  写到:
>On Mon, Jun 05, 2017 at 08:33:47PM +0800, Icenowy Zheng wrote:
>> From: Icenowy Zheng 
>> 
>> Originally we enable a special gate bit when the compatible indicates
>> A23/33.
>> 
>> But according to BSP sources and user manuals, more SoCs will need
>this
>> gate bit.
>> 
>> So make it a common quirk configured in the config struct.
>> 
>> Signed-off-by: Icenowy Zheng 
>> ---
>> Changes since original codec patchset v3:
>> - Refactored comments to cover some words found in official
>documents.
>> - Removed the comments when toggling the gate bit.
>> 
>>  drivers/dma/sun6i-dma.c | 20 +---
>>  1 file changed, 13 insertions(+), 7 deletions(-)
>> 
>> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
>> index a2358780ab2c..252b59c1d1d5 100644
>> --- a/drivers/dma/sun6i-dma.c
>> +++ b/drivers/dma/sun6i-dma.c
>> @@ -101,6 +101,17 @@ struct sun6i_dma_config {
>>  u32 nr_max_channels;
>>  u32 nr_max_requests;
>>  u32 nr_max_vchans;
>> +/*
>> + * In the datasheets/user manuals of newer Allwinner SoCs, a
>special
>> + * bit (bit 2 at register 0x20) is present.
>> + * It's named "DMA MCLK interface circuit auto gating bit" in the
>> + * documents, and the footnote of this register says that this bit
>> + * should be set up when initializing the DMA controller.
>> + * Allwinner A23/A33 user manuals do not have this bit documented,
>> + * however these SoCs really have and need this bit, as seen in the
>> + * BSP kernel source code.
>> + */
>> +bool gate_needed;
>
>Since this is a hw property, why is this not added as an optional DT
>property?

As it's SoC-specified.

Some SoCs need it, and some don't.

SoC info is in compatible, so there's no reason to make it a property.

>
>>  };
>>  
>>  /*
>> @@ -1009,6 +1020,7 @@ static struct sun6i_dma_config
>sun8i_a23_dma_cfg = {
>>  .nr_max_channels = 8,
>>  .nr_max_requests = 24,
>>  .nr_max_vchans   = 37,
>> +.gate_needed = true,
>>  };
>>  
>>  static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
>> @@ -1174,13 +1186,7 @@ static int sun6i_dma_probe(struct
>platform_device *pdev)
>>  goto err_dma_unregister;
>>  }
>>  
>> -/*
>> - * sun8i variant requires us to toggle a dma gating register,
>> - * as seen in Allwinner's SDK. This register is not documented
>> - * in the A23 user manual.
>> - */
>> -if (of_device_is_compatible(pdev->dev.of_node,
>> -"allwinner,sun8i-a23-dma"))
>> +if (sdc->cfg->gate_needed)
>>  writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
>>  
>>  return 0;
>> -- 
>> 2.12.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/d/optout.

[linux-sunxi] Re: [PATCH 1/2] dmaengine: sun6i: make gate bit in sun8i's DMA engines a common quirk

2017-06-14 Thread Vinod Koul 
On Mon, Jun 05, 2017 at 08:33:47PM +0800, Icenowy Zheng wrote:
> From: Icenowy Zheng 
> 
> Originally we enable a special gate bit when the compatible indicates
> A23/33.
> 
> But according to BSP sources and user manuals, more SoCs will need this
> gate bit.
> 
> So make it a common quirk configured in the config struct.
> 
> Signed-off-by: Icenowy Zheng 
> ---
> Changes since original codec patchset v3:
> - Refactored comments to cover some words found in official documents.
> - Removed the comments when toggling the gate bit.
> 
>  drivers/dma/sun6i-dma.c | 20 +---
>  1 file changed, 13 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/dma/sun6i-dma.c b/drivers/dma/sun6i-dma.c
> index a2358780ab2c..252b59c1d1d5 100644
> --- a/drivers/dma/sun6i-dma.c
> +++ b/drivers/dma/sun6i-dma.c
> @@ -101,6 +101,17 @@ struct sun6i_dma_config {
>   u32 nr_max_channels;
>   u32 nr_max_requests;
>   u32 nr_max_vchans;
> + /*
> +  * In the datasheets/user manuals of newer Allwinner SoCs, a special
> +  * bit (bit 2 at register 0x20) is present.
> +  * It's named "DMA MCLK interface circuit auto gating bit" in the
> +  * documents, and the footnote of this register says that this bit
> +  * should be set up when initializing the DMA controller.
> +  * Allwinner A23/A33 user manuals do not have this bit documented,
> +  * however these SoCs really have and need this bit, as seen in the
> +  * BSP kernel source code.
> +  */
> + bool gate_needed;

Since this is a hw property, why is this not added as an optional DT
property?

>  };
>  
>  /*
> @@ -1009,6 +1020,7 @@ static struct sun6i_dma_config sun8i_a23_dma_cfg = {
>   .nr_max_channels = 8,
>   .nr_max_requests = 24,
>   .nr_max_vchans   = 37,
> + .gate_needed = true,
>  };
>  
>  static struct sun6i_dma_config sun8i_a83t_dma_cfg = {
> @@ -1174,13 +1186,7 @@ static int sun6i_dma_probe(struct platform_device 
> *pdev)
>   goto err_dma_unregister;
>   }
>  
> - /*
> -  * sun8i variant requires us to toggle a dma gating register,
> -  * as seen in Allwinner's SDK. This register is not documented
> -  * in the A23 user manual.
> -  */
> - if (of_device_is_compatible(pdev->dev.of_node,
> - "allwinner,sun8i-a23-dma"))
> + if (sdc->cfg->gate_needed)
>   writel(SUN8I_DMA_GATE_ENABLE, sdc->base + SUN8I_DMA_GATE);
>  
>   return 0;
> -- 
> 2.12.2
> 

-- 
~Vinod

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