[linux-sunxi] [PATCH 0/3] regulators: axp20x: Rename AXP221 DC1SW and DC5LDO supply names

2015-09-15 Thread Chen-Yu Tsai 
Hi everyone,

This series renames regulator supply names for DC1SW and DC5LDO for
the AXP221. These 2 are secondary outputs for DCDC1 and DCDC5 buck
regulators, respectively, so they are connected to them internally.
There's no external input pin to name the supplies after.

When I originally did the support, I used the parent regulator's name
for the supply name. However this results in a misleading dts:

axp221: pmic@68 {
dcdc1-supply = <>;
dcdc5-supply = <>;

dcdc1: dcdc1 {
...
};

...
};

At first glance, one might interpret it as "DCDC1 supplies itself".
Indeed, Maxime raised this issue.

This series renames the supply names to the regulator names themselves,
or "dc1sw-supply" and "dc5ldo-supply" respectively:

axp221: pmic@68 {
dc1sw-supply = <>;
dc5ldo-supply = <>;
...
};

Renaming these shouldn't result in any problems in the real world.
All the board designs we've seen have DCDC1 supplying a common 3/3.3V
rail, and DCDC5 supplying 1.5V for DDR3 SDRAM. These 2 would have
"always-on" set, so even if the rename results in the secondary
regulator outputs being decoupled from the primary in the software
implementation, it would just be a representation issue. Function-wise,
it would function as before. On the Linux side, no one is actually
using the secondary outputs yet.

Patch 1 renames the supply names in the axp20x DT bindings.

Patch 2 updates the axp20x regulator driver.

Patch 3 updates the only dts, the Hummingbird A31, that uses these
bindings.

If everything's ok, could we merge the first 2 patches through the
regulator tree, and the 3rd through the sunxi tree?

Thanks.


Regards,
ChenYu


Chen-Yu Tsai (3):
  mfd: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO
regulators
  regulators: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO
  ARM: dts: sun6i: hummingbird: Rename AXP221 DC1SW and DC5LDO supply
names

 Documentation/devicetree/bindings/mfd/axp20x.txt | 4 ++--
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts  | 4 ++--
 drivers/regulator/axp20x-regulator.c | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

-- 
2.5.1

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

[linux-sunxi] [PATCH 3/3] ARM: dts: sun6i: hummingbird: Rename AXP221 DC1SW and DC5LDO supply names

2015-09-15 Thread Chen-Yu Tsai 
"dcdc1-supply" and "dcdc5-supply" are renamed to "dc1sw-supply" and
"dc5ldo-supply" respectively. Update the dts to reflect the new supply
names for the regulators.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun6i-a31-hummingbird.dts | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts 
b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
index 06d9391ca30e..144f563a3d6d 100644
--- a/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
+++ b/arch/arm/boot/dts/sun6i-a31-hummingbird.dts
@@ -178,8 +178,8 @@
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
#interrupt-cells = <1>;
-   dcdc1-supply = <_3v0>;
-   dcdc5-supply = <_dram>;
+   dc1sw-supply = <_3v0>;
+   dc5ldo-supply = <_dram>;
 
regulators {
x-powers,dcdc-freq = <3000>;
-- 
2.5.1

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

[linux-sunxi] [PATCH 2/3] regulators: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO

2015-09-15 Thread Chen-Yu Tsai 
The DC1SW and DC5LDO regulators in the AXP221 are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property. This causes
some confusion when we actually use it in the dts:

axp221 {
/* self supplying? */
dcdc1-supply = <>;
dcdc5-supply = <>;

dcdc1: dcdc1 {
...
};

dcdc5: dcdc5 {
...
};
};

Change them to the downstream regulator names, or "dc1sw" and "dc5ldo"
respectively.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/regulator/axp20x-regulator.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 01bf3476a791..27ebee8e224c 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -196,10 +196,10 @@ static const struct regulator_desc axp22x_regulators[] = {
AXP_DESC(AXP22X, DCDC5, "dcdc5", "vin5", 1000, 2550, 50,
 AXP22X_DCDC5_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(4)),
/* secondary switchable output of DCDC1 */
-   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", "dcdc1", 1600, 3400, 100,
+   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", "dc1sw", 1600, 3400, 100,
AXP22X_DCDC1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL2, BIT(7)),
/* LDO regulator internally chained to DCDC5 */
-   AXP_DESC(AXP22X, DC5LDO, "dc5ldo", "dcdc5", 700, 1400, 100,
+   AXP_DESC(AXP22X, DC5LDO, "dc5ldo", "dc5ldo", 700, 1400, 100,
 AXP22X_DC5LDO_V_OUT, 0x7, AXP22X_PWR_OUT_CTRL1, BIT(0)),
AXP_DESC(AXP22X, ALDO1, "aldo1", "aldoin", 700, 3300, 100,
 AXP22X_ALDO1_V_OUT, 0x1f, AXP22X_PWR_OUT_CTRL1, BIT(6)),
-- 
2.5.1

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

[linux-sunxi] [PATCH 1/3] mfd: axp20x: Rename supply names for AXP221 DC1SW and DC5LDO regulators

2015-09-15 Thread Chen-Yu Tsai 
The DC1SW and DC5LDO regulators in the AXP221 are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property. This causes
some confusion when we actually use it in the dts:

axp221 {
/* self supplying? */
dcdc1-supply = <>;
dcdc5-supply = <>;

dcdc1: dcdc1 {
...
};

dcdc5: dcdc5 {
...
};
};

Change them to the downstream regulator names, or "dc1sw" and "dc5ldo"
respectively.

Signed-off-by: Chen-Yu Tsai 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index 41811223e5be..8e79252b1e7c 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -60,8 +60,8 @@ DCDC2 : DC-DC buck: vin2-supply
 DCDC3  : DC-DC buck: vin3-supply
 DCDC4  : DC-DC buck: vin4-supply
 DCDC5  : DC-DC buck: vin5-supply
-DC1SW  : On/Off Switch : dcdc1-supply  : DCDC1 secondary output
-DC5LDO : LDO   : dcdc5-supply  : input from DCDC5
+DC1SW  : On/Off Switch : dc1sw-supply  : DCDC1 secondary output
+DC5LDO : LDO   : dc5ldo-supply : input from DCDC5
 ALDO1  : LDO   : aldoin-supply : shared supply
 ALDO2  : LDO   : aldoin-supply : shared supply
 ALDO3  : LDO   : aldoin-supply : shared supply
-- 
2.5.1

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

[linux-sunxi] Re: [PATCH 1/4] ARM:dts:sun7i: Add keypad clk node

2015-09-15 Thread Maxime Ripard 
On Wed, Sep 16, 2015 at 12:05:54AM +1000, yassinjaf...@gmail.com wrote:
> From: Yassin Jaffer 
> 
> This patch add support to the keypad clock on sun7i
> 
> Signed-off-by: Yassin Jaffer 

Applied, 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/d/optout.


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH v2 2/3] sunxi-tools: factor out persistent version and sram_info information

2015-09-15 Thread Siarhei Siamashka 
On Tue, 15 Sep 2015 14:02:28 +0200
Bernhard Nortmann  wrote:

> Am 14.09.2015 um 11:55 schrieb Bernhard Nortmann:
> > Hello Siarhei!
> >
> > Am 13.09.2015 um 23:42 schrieb Siarhei Siamashka:
> >> With this change, we are going to print "Warning: no 'soc_sram_info'
> >> data for your SoC" message regardless of what kind of FEL command
> >> is requested in the command line. Simple FEL commands don't need any
> >> SoC-specific information, so we are going to be nagging the users
> >> of the new SoC variants.
> >>
> >> On the other hand, maybe this is not too bad?
> >
> > Good catch. I also think we could "get away" with that, but it may
> > not be the nicest way to deal with it. I would think that handling
> > this might be achieved by initializing sram_info to NULL, and only
> > call aw_fel_get_sram_info() later when sram_info is actually needed
> > ("spl"/"uboot", or script transfer with "write")? It leads to slightly
> > more complicated code, but seems reasonable.
>
> It might be preferable to actually make "fel_version" global.
> aw_fel_get_sram_info() could operate on that data, and cache its result,
> so the soc_sram_info pointer gets initialized only once (upon the first
> request that makes actual use of sram_info). This way it's safe to call
> the function multiple times / wherever needed.
> 
> What do you think?

Yes, caching the pointer inside of aw_fel_get_sram_info() function and
avoiding repeated usb requests is a good idea. Just make it a static
variable instead of global.

-- 
Best regards,
Siarhei Siamashka

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

[linux-sunxi] Re: [PATCH 4/4] devicetree: bindings:Allwinner sun4i keypad

2015-09-15 Thread Maxime Ripard 
On Wed, Sep 16, 2015 at 12:05:57AM +1000, yassinjaf...@gmail.com wrote:
> From: Yassin Jaffer 
> 
> Signed-off-by: Yassin Jaffer 
> ---
>  .../devicetree/bindings/input/sun4i-keypad.txt | 56 
> ++
>  1 file changed, 56 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/input/sun4i-keypad.txt
> 
> diff --git a/Documentation/devicetree/bindings/input/sun4i-keypad.txt 
> b/Documentation/devicetree/bindings/input/sun4i-keypad.txt
> new file mode 100644
> index 000..60ed0f2
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/sun4i-keypad.txt
> @@ -0,0 +1,56 @@
> +Allwinner sun4i keypad
> +
> +
> +Required properties:
> + - compatible: "allwinner,sun4i-a10-keypad"
> + - reg: mmio address range of the chip
> + - interrupts: interrupt to which the chip is connected
> + - clocks : shall reference keypad controller clocks.
> + - clock-names : keypad controller internal clock names. Shall contain :
> +* "apb" : APB gating clock
> +* "keypad" : keypad controller clock
> +
> +Required Board Specific Properties:
> +- pinctrl-names: The definition can be found at
> +pinctrl/pinctrl-bindings.txt.
> +
> +- pinctrl-0: The definition can be found at
> +pinctrl/pinctrl-bindings.txt.
> +
> +- linux,keymap: The definition can be found at
> +bindings/input/matrix-keymap.txt.
> +
> +Optional properties:
> + - scan-cycle: device specific scan cycle
> + - debounce-cycle: device specific debounce cycle
> + - autorepeat: If specified device will autorepeat

Are those properties generic? I couldn't find them defined anywhere.

In which units are those properties?

> +
> +Example:
> +
> +#include 
> +
> + kp: kp@01c23000 {
> + compatible = "allwinner,sun4i-a10-keypad";
> + reg = <0x01c23000 0x400>;
> + interrupts = ;
> + clocks = <_gates 10>, <_clk>;
> + clock-names = "apb", "keypad";
> + pinctrl-names = "default";
> + pinctrl-0 = <_rows>, <_cols>;
> + linux,keymap = <0x0067  /* KEY_UP */
> + 0x0001006c  /* KEY_DOWN */
> + 0x00020072  /* KEY_VOLUMEDOWN */
> + 0x00030066  /* KEY_HOME */
> + 0x016a  /* KEY_RIGHT */
> + 0x01010069  /* KEY_LEFT */
> + 0x0102001c  /* KEY_ENTER */
> + 0x01030073  /* KEY_VOLUMEUP */
> + 0x0240  /* KEY_F6 */
> + 0x02010042  /* KEY_F8 */
> + 0x02020043  /* KEY_F9 */
> + 0x02030044  /* KEY_F10 */
> + 0x033b  /* KEY_F1 */
> + 0x0301003c  /* KEY_F2 */
> + 0x0302003d  /* KEY_F3 */
> + 0x03030074>;/* KEY_POWER */

You don't seem to use the header you just told us to include.

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/d/optout.


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH v2 2/3] sunxi-tools: factor out persistent version and sram_info information

2015-09-15 Thread Bernhard Nortmann 

It might be preferable to actually make "fel_version" global.
aw_fel_get_sram_info() could operate on that data, and cache its result,
so the soc_sram_info pointer gets initialized only once (upon the first
request that makes actual use of sram_info). This way it's safe to call
the function multiple times / wherever needed.

What do you think?

Regards, B. Nortmann


Am 14.09.2015 um 11:55 schrieb Bernhard Nortmann:

Hello Siarhei!

Am 13.09.2015 um 23:42 schrieb Siarhei Siamashka:

With this change, we are going to print "Warning: no 'soc_sram_info'
data for your SoC" message regardless of what kind of FEL command
is requested in the command line. Simple FEL commands don't need any
SoC-specific information, so we are going to be nagging the users
of the new SoC variants.

On the other hand, maybe this is not too bad?


Good catch. I also think we could "get away" with that, but it may
not be the nicest way to deal with it. I would think that handling
this might be achieved by initializing sram_info to NULL, and only
call aw_fel_get_sram_info() later when sram_info is actually needed
("spl"/"uboot", or script transfer with "write")? It leads to slightly
more complicated code, but seems reasonable.

Regards, B. Nortmann


--
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.
>From f53935b6d95930a2c0e4597165f5324451e1a70e Mon Sep 17 00:00:00 2001
From: Bernhard Nortmann 
Date: Wed, 9 Sep 2015 13:37:36 +0200
Subject: [RFC PATCH v3 2/3] sunxi-tools: factor out persistent version and
 sram_info information

FEL version information and SoC-specific memory layout are used
across several places in the fel utility code. To avoid having
to retrieve this information repeatedly, this patch introduces
a global variable that holds a struct aw_fel_version, and makes
aw_fel_get_sram_info() cache its result.

Signed-off-by: Bernhard Nortmann 
---
 fel.c | 50 --
 1 file changed, 28 insertions(+), 22 deletions(-)

diff --git a/fel.c b/fel.c
index 52b785f..48c0add 100644
--- a/fel.c
+++ b/fel.c
@@ -60,6 +60,7 @@ struct aw_fel_version {
 static const int AW_USB_READ = 0x11;
 static const int AW_USB_WRITE = 0x12;
 
+static struct aw_fel_version fel_version; /* global FEL/SoC version info */
 static int AW_USB_FEL_BULK_EP_OUT;
 static int AW_USB_FEL_BULK_EP_IN;
 static int timeout = 6;
@@ -222,13 +223,10 @@ void aw_fel_get_version(libusb_device_handle *usb, struct 
aw_fel_version *buf)
buf->pad[1] = le32toh(buf->pad[1]);
 }
 
-void aw_fel_print_version(libusb_device_handle *usb)
+void aw_fel_print_version(struct aw_fel_version *buf)
 {
-   struct aw_fel_version buf;
-   aw_fel_get_version(usb, );
-
const char *soc_name="unknown";
-   switch (buf.soc_id) {
+   switch (buf->soc_id) {
case 0x1623: soc_name="A10";break;
case 0x1625: soc_name="A13";break;
case 0x1633: soc_name="A31";break;
@@ -241,9 +239,9 @@ void aw_fel_print_version(libusb_device_handle *usb)
}
 
printf("%.8s soc=%08x(%s) %08x ver=%04x %02x %02x scratchpad=%08x %08x 
%08x\n",
-   buf.signature, buf.soc_id, soc_name, buf.unknown_0a,
-   buf.protocol, buf.unknown_12, buf.unknown_13,
-   buf.scratchpad, buf.pad[0], buf.pad[1]);
+   buf->signature, buf->soc_id, soc_name, buf->unknown_0a,
+   buf->protocol, buf->unknown_12, buf->unknown_13,
+   buf->scratchpad, buf->pad[0], buf->pad[1]);
 }
 
 void aw_fel_read(libusb_device_handle *usb, uint32_t offset, void *buf, size_t 
len)
@@ -501,20 +499,25 @@ soc_sram_info generic_sram_info = {
.swap_buffers = generic_sram_swap_buffers,
 };
 
-soc_sram_info *aw_fel_get_sram_info(libusb_device_handle *usb)
+soc_sram_info *aw_fel_get_sram_info(void)
 {
-   int i;
-   struct aw_fel_version buf;
-
-   aw_fel_get_version(usb, );
-
-   for (i = 0; soc_sram_info_table[i].swap_buffers; i++)
-   if (soc_sram_info_table[i].soc_id == buf.soc_id)
-   return _sram_info_table[i];
+   /* persistent sram_info, retrieves result pointer once and caches it */
+   static soc_sram_info *result = NULL;
+   if (result == NULL) {
+   int i;
+   for (i = 0; soc_sram_info_table[i].swap_buffers; i++)
+   if (soc_sram_info_table[i].soc_id == 
fel_version.soc_id) {
+   result = _sram_info_table[i];
+   break;
+   }
 
-   printf("Warning: no 'soc_sram_info' data for your SoC (id=%04X)\n",
-  buf.soc_id);
-   return _sram_info;
+   if (!result) {
+

[linux-sunxi] [PATCH 3/4] input: Add new sun4i-keypad driver

2015-09-15 Thread yassinjaffer 
From: Yassin Jaffer 

Allwinnner SUN4i Keypad controller is used to interface a SoC
with a matrix-typekeypad device.
The keypad controller supports multiple row and column lines.
A key can be placed at each intersection of a unique
row and a unique column.
The keypad controller can sense a key-press and key-release and report the
event using a interrupt to the cpu.
This patch adds a driver support to this.
The keypad controller driver does not give proper information
if more that two keys are selected.

Signed-off-by: Yassin Jaffer 
---
 drivers/input/keyboard/Kconfig|  11 ++
 drivers/input/keyboard/Makefile   |   1 +
 drivers/input/keyboard/sun4i-keypad.c | 361 ++
 3 files changed, 373 insertions(+)
 create mode 100644 drivers/input/keyboard/sun4i-keypad.c

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 2e80107..4f2f3f8 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -590,6 +590,17 @@ config KEYBOARD_SUN4I_LRADC
  To compile this driver as a module, choose M here: the
  module will be called sun4i-lradc-keys.
 
+config KEYBOARD_SUN4I_KEYPAD
+   tristate "Allwinner sun4i keypad support"
+   depends on ARCH_SUNXI
+   select INPUT_MATRIXKMAP
+   help
+ This selects support for the Allwinner keypad
+ on Allwinner sunxi SoCs.
+
+ To compile this driver as a module, choose M here: the
+ module will be called sun4i-keypad.
+
 config KEYBOARD_DAVINCI
tristate "TI DaVinci Key Scan"
depends on ARCH_DAVINCI_DM365
diff --git a/drivers/input/keyboard/Makefile b/drivers/input/keyboard/Makefile
index 1d416dd..d9f54b4 100644
--- a/drivers/input/keyboard/Makefile
+++ b/drivers/input/keyboard/Makefile
@@ -57,6 +57,7 @@ obj-$(CONFIG_KEYBOARD_STMPE)  += stmpe-keypad.o
 obj-$(CONFIG_KEYBOARD_STOWAWAY)+= stowaway.o
 obj-$(CONFIG_KEYBOARD_ST_KEYSCAN)  += st-keyscan.o
 obj-$(CONFIG_KEYBOARD_SUN4I_LRADC) += sun4i-lradc-keys.o
+obj-$(CONFIG_KEYBOARD_SUN4I_KEYPAD)+= sun4i-keypad.o
 obj-$(CONFIG_KEYBOARD_SUNKBD)  += sunkbd.o
 obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o
 obj-$(CONFIG_KEYBOARD_TEGRA)   += tegra-kbc.o
diff --git a/drivers/input/keyboard/sun4i-keypad.c 
b/drivers/input/keyboard/sun4i-keypad.c
new file mode 100644
index 000..995f9665
--- /dev/null
+++ b/drivers/input/keyboard/sun4i-keypad.c
@@ -0,0 +1,361 @@
+/*
+ * Allwinner sun4i keypad Controller driver
+ *
+ * Copyright (C) 2015 Yassin Jaffer 
+ *
+ * Parts of this software are based on (derived from):
+ * Copyright (C) 2013-2015 lim...@allwinnertech.com,
+ *  qys
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Keypad Controller registers
+ */
+#define KP_CTL 0x00  /* Keypad Control register */
+#define KP_TIMING  0x04  /* Keypad Timing register */
+#define KP_INT_CFG 0x08  /* Keypad interrupt Config register */
+#define KP_INT_STA 0x0c  /* Keypad interrupt Status register */
+
+#define KP_IN_OFFSET   0x10 /* Keypad Input Data register 0 */
+#define KP_INX_OFFSET(reg_n)   (KP_IN_OFFSET + 4 * (reg_n))
+
+/* KP_CTL bits */
+#define ENABLE(x)  ((x) << 0)
+#define COLMASK(x) ((~x & 0xff) << 8)
+#define ROWMASK(x) ((~x & 0xff) << 16)
+
+/* KP_TIMING bits */
+#define SCAN_CYCLE(x)  ((x) << 0)
+#define DBC_CYCLE(x)   ((x) << 16)
+
+/* KP_INT_CFG bits */
+#define KP_IRQ_FEDGE   BIT(0)
+#defineKP_IRQ_REDGEBIT(1)
+
+/* KP_INT_STA bits */
+#define KP_STA_FEDGE   BIT(0)
+#defineKP_STA_REDGEBIT(1)
+
+#define KP_MAX_ROWS8
+#define KP_MAX_COLS8
+#define N_ROWS_REG 2
+#define KP_ROW_SHIFT   3
+#define KP_BIT_SHIFT32
+
+#define MAX_MATRIX_KEY_NUM (KP_MAX_ROWS * KP_MAX_COLS)
+
+#define KP_BASE_CLK100
+#define MIN_CYCLE  0x10
+#define MIN_SCAN_CYCLE 0x100
+#define MIN_DBC_CYCLE  0x200
+
+/*
+ * keypad Controller structure: stores sunxi keypad controller information
+ *
+ * @dev:   parent device
+ * @input: pointer to input device

[linux-sunxi] NEW SUN4i KEYPAD DRIVER

2015-09-15 Thread yassinjaffer 
This series adds support for the sun4i keypad Controller
I've tested the driver in a A20 custom board (4x4) only
Allwinner keypad controller does not seem to handle more
than two key press

Please test and report bugs. Thank you in advance

[PATCH 1/4] ARM:dts:sun7i: Add keypad clk node
[PATCH 2/4] ARM: dts: sun7i: Add keypad node to Allwinner A20 SoC
[PATCH 3/4] input: Add new sun4i-keypad driver
[PATCH 4/4] devicetree: bindings:Allwinner sun4i keypad

-- 
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 1/4] ARM:dts:sun7i: Add keypad clk node

2015-09-15 Thread yassinjaffer 
From: Yassin Jaffer 

This patch add support to the keypad clock on sun7i

Signed-off-by: Yassin Jaffer 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 2bebaa2..333604a 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -465,6 +465,14 @@
clock-output-names = "ir1";
};
 
+   keypad_clk: clk@01c200c4 {
+   #clock-cells = <0>;
+   compatible = "allwinner,sun4i-a10-mod0-clk";
+   reg = <0x01c200c4 0x4>;
+   clocks = <>;
+   clock-output-names = "keypad";
+   };
+
usb_clk: clk@01c200cc {
#clock-cells = <1>;
#reset-cells = <1>;
-- 
1.9.1

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

[linux-sunxi] [PATCH 4/4] devicetree: bindings:Allwinner sun4i keypad

2015-09-15 Thread yassinjaffer 
From: Yassin Jaffer 

Signed-off-by: Yassin Jaffer 
---
 .../devicetree/bindings/input/sun4i-keypad.txt | 56 ++
 1 file changed, 56 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/sun4i-keypad.txt

diff --git a/Documentation/devicetree/bindings/input/sun4i-keypad.txt 
b/Documentation/devicetree/bindings/input/sun4i-keypad.txt
new file mode 100644
index 000..60ed0f2
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/sun4i-keypad.txt
@@ -0,0 +1,56 @@
+Allwinner sun4i keypad
+
+
+Required properties:
+ - compatible: "allwinner,sun4i-a10-keypad"
+ - reg: mmio address range of the chip
+ - interrupts: interrupt to which the chip is connected
+ - clocks : shall reference keypad controller clocks.
+ - clock-names : keypad controller internal clock names. Shall contain :
+* "apb" : APB gating clock
+* "keypad" : keypad controller clock
+
+Required Board Specific Properties:
+- pinctrl-names: The definition can be found at
+pinctrl/pinctrl-bindings.txt.
+
+- pinctrl-0: The definition can be found at
+pinctrl/pinctrl-bindings.txt.
+
+- linux,keymap: The definition can be found at
+bindings/input/matrix-keymap.txt.
+
+Optional properties:
+ - scan-cycle: device specific scan cycle
+ - debounce-cycle: device specific debounce cycle
+ - autorepeat: If specified device will autorepeat
+
+Example:
+
+#include 
+
+   kp: kp@01c23000 {
+   compatible = "allwinner,sun4i-a10-keypad";
+   reg = <0x01c23000 0x400>;
+   interrupts = ;
+   clocks = <_gates 10>, <_clk>;
+   clock-names = "apb", "keypad";
+   pinctrl-names = "default";
+   pinctrl-0 = <_rows>, <_cols>;
+   linux,keymap = <0x0067  /* KEY_UP */
+   0x0001006c  /* KEY_DOWN */
+   0x00020072  /* KEY_VOLUMEDOWN */
+   0x00030066  /* KEY_HOME */
+   0x016a  /* KEY_RIGHT */
+   0x01010069  /* KEY_LEFT */
+   0x0102001c  /* KEY_ENTER */
+   0x01030073  /* KEY_VOLUMEUP */
+   0x0240  /* KEY_F6 */
+   0x02010042  /* KEY_F8 */
+   0x02020043  /* KEY_F9 */
+   0x02030044  /* KEY_F10 */
+   0x033b  /* KEY_F1 */
+   0x0301003c  /* KEY_F2 */
+   0x0302003d  /* KEY_F3 */
+   0x03030074>;/* KEY_POWER */
+   };
-- 
1.9.1

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

[linux-sunxi] A20 GMAC rx_coe and bugged_jumbo in dwmac-sunxi.c

2015-09-15 Thread db260179 
Hi All,

A quick background of what I’m trying to achieve and if possible?

So, having messed about with the TX and RX delay in the U-boot for a Lamobo R1 
board, there appears to be some form of effect going on with the network speed 
measurements.

It has been recorded that this board uses the GMAC to talk to the Broadcom 
BCM53125 PHY - A TX Delay is needed to compensate for differing PCB lengths.

My query from looking at the stmmac source code, is what can be the possible 
causes for a 50% reduction of speed in gigabit mode compared to its little 
brother of BananaPi A20 (using a realtek PHY)?

Is the DMA being used in the stmmac driver for GMAC?

Why isnt the rx_coe of bugged_jumbo not being used? (sunxi 3.4 show's it be 
initiated?)

I've noticed on the /proc/softirqs that the RX has large values and TX having 
small increments?

What area should I be looking at to diagnose or debug further?

Thanks for any assistance.
David Bentham

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

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

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

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


Stefan

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