[linux-sunxi] [PATCH v2 0/4] input: Add new sun4i-lradc-keys driver

2014-10-21 Thread Hans de Goede 
Hi All,

After a bit of a pause due to -ENOTIME, here is my 2nd attempt at getting
support for the lradc attached tablet keys found one some Allwinner boards
upstream.

I've dubbed this v2 even though there has been more then one version before
because I've lost count, and as said this represents the 2nd attempt at getting
this upstream.

The major change from the previous attempt is that now the devicetree
description has one subnode per key just like gpio-keys has.

I hope this version is to everyones liking and can be merged soon :) The intend
is for the actual driver to go upstream through Dmitry's tree, where as the
3 dts patches should go upstream through Maxime's tree.

Thanks  Regards,

Hans

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

[linux-sunxi] Re: [PATCH v5 4/4] crypto: Add Allwinner Security System crypto accelerator

2014-10-21 Thread Joe Perches 
On Tue, 2014-10-21 at 02:28 +0300, Vladimir Zapolskiy wrote:
 On 19.10.2014 17:16, LABBE Corentin wrote:
  Add support for the Security System included in Allwinner SoC A20.
  The Security System is a hardware cryptographic accelerator that support 
  AES/MD5/SHA1/DES/3DES/PRNG algorithms.
[]
  diff --git a/drivers/crypto/sunxi-ss/sunxi-ss-core.c 
  b/drivers/crypto/sunxi-ss/sunxi-ss-core.c
[]
  +   cr = clk_get_rate(ss-busclk);
  +   if (cr = cr_ahb)
  +   dev_dbg(pdev-dev, Clock bus %lu (%lu MHz) (must be = 
  %lu)\n,
  +   cr, cr / 100, cr_ahb);
  +   else
  +   dev_warn(pdev-dev, Clock bus %lu (%lu MHz) (must be = 
  %lu)\n,
  +   cr, cr / 100, cr_ahb);
 
 See next comment.
 
  +   cr = clk_get_rate(ss-ssclk);
  +   if (cr = cr_mod)
  +   if (cr  cr_mod)
  +   dev_info(pdev-dev, Clock ss %lu (%lu MHz) (must be 
  = %lu)\n,
  +   cr, cr / 100, cr_mod);
  +   else
  +   dev_dbg(pdev-dev, Clock ss %lu (%lu MHz) (must be = 
  %lu)\n,
  +   cr, cr / 100, cr_mod);
  +   else
  +   dev_warn(pdev-dev, Clock ss is at %lu (%lu MHz) (must be = 
  %lu)\n,
  +   cr, cr / 100, cr_mod);
 
 The management of kernel log levels looks pretty strange. As far as I
 understand there is no error on any clock rate, I'd recommend to keep
 only one information message.

And if not, please add some braces.

 hash_init: initialize request context */
  +int sunxi_hash_init(struct ahash_request *areq)
  +{
  +   const char *hash_type;
  +   struct sunxi_req_ctx *op = ahash_request_ctx(areq);
  +
  +   memset(op, 0, sizeof(struct sunxi_req_ctx));
  +
  +   hash_type = crypto_tfm_alg_name(areq-base.tfm);
  +
  +   if (strcmp(hash_type, sha1) == 0)
  +   op-mode = SS_OP_SHA1;
  +   if (strcmp(hash_type, md5) == 0)
  +   op-mode = SS_OP_MD5;

else if ?

  +   if (op-mode == 0)
  +   return -EINVAL;

maybe this?

if (!strcmp(hash_type, sha1))
op-mode = SS_OP_SHA1;
else if (!strcmp(hash_type, md5))
op-mode = SH_OP_MD5;
else
return -EINVAL;

  +
  +   return 0;
  +}
[]
  +int sunxi_hash_update(struct ahash_request *areq)
  +{
[]
  +   dev_dbg(ss-dev, %s %s bc=%llu len=%u mode=%x bw=%u ww=%u,
  +   __func__, crypto_tfm_alg_name(areq-base.tfm),
  +   op-byte_count, areq-nbytes, op-mode,
  +   op-nbw, op-nwait);

dev_dbg statements generally don't need __func__ as
dynamic_debug can add it.

If you want to keep it, the most common output form for
__func__ is '%s: ..., __func__'

-- 
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] [RFC Patch 2/4] mfd: AXP20x: Add power supply sub-driver

2014-10-21 Thread Bruno Prémont 
Add driver for the power supply features of AXP20x PMIC.

Covered features:
 - backup / RTC battery
 - VBUS/OTG power input
 - AC power input
 - LIon battery charger
---
 drivers/mfd/axp20x.c |  106 +-
 drivers/power/Kconfig|9 +
 drivers/power/Makefile   |1 +
 drivers/power/axp20x_power.c | 1530 ++
 include/linux/mfd/axp20x.h   |5 +
 5 files changed, 1650 insertions(+), 1 deletion(-)
 create mode 100644 drivers/power/axp20x_power.c

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index dee6539..1322489 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -31,10 +31,16 @@
 static const struct regmap_range axp20x_writeable_ranges[] = {
regmap_reg_range(AXP20X_DATACACHE(0), AXP20X_IRQ5_STATE),
regmap_reg_range(AXP20X_DCDC_MODE, AXP20X_FG_RES),
+   regmap_reg_range(AXP20X_OCV(0), AXP20X_OCV(15)),
 };
 
 static const struct regmap_range axp20x_volatile_ranges[] = {
+   regmap_reg_range(AXP20X_PWR_INPUT_STATUS, AXP20X_USB_OTG_STATUS),
+   regmap_reg_range(AXP20X_CHRG_CTRL1, AXP20X_CHRG_CTRL2),
regmap_reg_range(AXP20X_IRQ1_EN, AXP20X_IRQ5_STATE),
+   regmap_reg_range(AXP20X_ACIN_V_ADC_H, AXP20X_IPSOUT_V_HIGH_L),
+   regmap_reg_range(AXP20X_GPIO20_SS, AXP20X_GPIO3_CTRL),
+   regmap_reg_range(AXP20X_FG_RES, AXP20X_RDC_L),
 };
 
 static const struct regmap_access_table axp20x_writeable_table = {
@@ -61,12 +67,106 @@ static struct resource axp20x_pek_resources[] = {
},
 };
 
+static struct resource axp20x_power_resources[] = {
+   {
+   .name   = ACIN_OVER_V,
+   .start  = AXP20X_IRQ_ACIN_OVER_V,
+   .end= AXP20X_IRQ_ACIN_OVER_V,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = ACIN_PLUGIN,
+   .start  = AXP20X_IRQ_ACIN_PLUGIN,
+   .end= AXP20X_IRQ_ACIN_PLUGIN,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = ACIN_REMOVAL,
+   .start  = AXP20X_IRQ_ACIN_REMOVAL,
+   .end= AXP20X_IRQ_ACIN_REMOVAL,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = VBUS_OVER_V,
+   .start  = AXP20X_IRQ_VBUS_OVER_V,
+   .end= AXP20X_IRQ_VBUS_OVER_V,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = VBUS_PLUGIN,
+   .start  = AXP20X_IRQ_VBUS_PLUGIN,
+   .end= AXP20X_IRQ_VBUS_PLUGIN,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = VBUS_REMOVAL,
+   .start  = AXP20X_IRQ_VBUS_REMOVAL,
+   .end= AXP20X_IRQ_VBUS_REMOVAL,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = VBUS_V_LOW,
+   .start  = AXP20X_IRQ_VBUS_V_LOW,
+   .end= AXP20X_IRQ_VBUS_V_LOW,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = BATT_PLUGIN,
+   .start  = AXP20X_IRQ_BATT_PLUGIN,
+   .end= AXP20X_IRQ_BATT_PLUGIN,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = BATT_REMOVAL,
+   .start  = AXP20X_IRQ_BATT_REMOVAL,
+   .end= AXP20X_IRQ_BATT_REMOVAL,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = BATT_ACTIVATE,
+   .start  = AXP20X_IRQ_BATT_ENT_ACT_MODE,
+   .end= AXP20X_IRQ_BATT_ENT_ACT_MODE,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = BATT_ACTIVATED,
+   .start  = AXP20X_IRQ_BATT_EXIT_ACT_MODE,
+   .end= AXP20X_IRQ_BATT_EXIT_ACT_MODE,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = BATT_CHARGING,
+   .start  = AXP20X_IRQ_CHARG,
+   .end= AXP20X_IRQ_CHARG,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = BATT_CHARGED,
+   .start  = AXP20X_IRQ_CHARG_DONE,
+   .end= AXP20X_IRQ_CHARG_DONE,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = BATT_HOT,
+   .start  = AXP20X_IRQ_BATT_TEMP_HIGH,
+   .end= AXP20X_IRQ_BATT_TEMP_HIGH,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = BATT_COLD,
+   .start  = AXP20X_IRQ_BATT_TEMP_LOW,
+   .end= AXP20X_IRQ_BATT_TEMP_LOW,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = BATT_CHG_CURR_LOW,
+   .start  = AXP20X_IRQ_CHARG_I_LOW,
+   .end= AXP20X_IRQ_CHARG_I_LOW,
+   .flags  = IORESOURCE_IRQ,
+   }, {
+   .name   = POWER_LOW_WARN,
+   .start  = AXP20X_IRQ_LOW_PWR_LVL1,
+   .end= AXP20X_IRQ_LOW_PWR_LVL1,
+   .flags  =

[linux-sunxi] Re: [PATCH v5 4/4] crypto: Add Allwinner Security System crypto accelerator

2014-10-21 Thread Vladimir Zapolskiy 
Hello LABBE,

On 19.10.2014 17:16, LABBE Corentin wrote:
 Add support for the Security System included in Allwinner SoC A20.
 The Security System is a hardware cryptographic accelerator that support 
 AES/MD5/SHA1/DES/3DES/PRNG algorithms.
 
 Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
 ---
  drivers/crypto/Kconfig|  17 ++
  drivers/crypto/Makefile   |   1 +
  drivers/crypto/sunxi-ss/Makefile  |   2 +
  drivers/crypto/sunxi-ss/sunxi-ss-cipher.c | 489 
 ++
  drivers/crypto/sunxi-ss/sunxi-ss-core.c   | 318 +++
  drivers/crypto/sunxi-ss/sunxi-ss-hash.c   | 445 +++
  drivers/crypto/sunxi-ss/sunxi-ss.h| 193 
  7 files changed, 1465 insertions(+)
  create mode 100644 drivers/crypto/sunxi-ss/Makefile
  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-core.c
  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.c
  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.h
 
 diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
 index 2fb0fdf..9ba9759 100644
 --- a/drivers/crypto/Kconfig
 +++ b/drivers/crypto/Kconfig
 @@ -436,4 +436,21 @@ config CRYPTO_DEV_QCE
 hardware. To compile this driver as a module, choose M here. The
 module will be called qcrypto.
  
 +config CRYPTO_DEV_SUNXI_SS
 + tristate Support for Allwinner Security System cryptographic 
 accelerator
 + depends on ARCH_SUNXI
 + select CRYPTO_MD5
 + select CRYPTO_SHA1
 + select CRYPTO_AES
 + select CRYPTO_DES
 + select CRYPTO_BLKCIPHER
 + help
 +   Some Allwinner SoC have a crypto accelerator named
 +   Security System. Select this if you want to use it.
 +   The Security System handle AES/DES/3DES ciphers in CBC mode
 +   and SHA1 and MD5 hash algorithms.
 +
 +   To compile this driver as a module, choose M here: the module
 +   will be called sunxi-ss.
 +
  endif # CRYPTO_HW
 diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
 index 3924f93..856545c 100644
 --- a/drivers/crypto/Makefile
 +++ b/drivers/crypto/Makefile
 @@ -25,3 +25,4 @@ obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
  obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
  obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
 +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss/
 diff --git a/drivers/crypto/sunxi-ss/Makefile 
 b/drivers/crypto/sunxi-ss/Makefile
 new file mode 100644
 index 000..8bb287d
 --- /dev/null
 +++ b/drivers/crypto/sunxi-ss/Makefile
 @@ -0,0 +1,2 @@
 +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss.o
 +sunxi-ss-y += sunxi-ss-core.o sunxi-ss-hash.o sunxi-ss-cipher.o
 diff --git a/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c 
 b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
 new file mode 100644
 index 000..8d0416e
 --- /dev/null
 +++ b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
 @@ -0,0 +1,489 @@
 +/*
 + * sunxi-ss-cipher.c - hardware cryptographic accelerator for Allwinner A20 
 SoC
 + *
 + * Copyright (C) 2013-2014 Corentin LABBE clabbe.montj...@gmail.com
 + *
 + * This file add support for AES cipher with 128,192,256 bits
 + * keysize in CBC mode.
 + * Add support also for DES and 3DES in CBC mode.
 + *
 + * You could find the datasheet in Documentation/arm/sunxi/README
 + *
 + * 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 sunxi-ss.h
 +
 +extern struct sunxi_ss_ctx *ss;
 +
 +static int sunxi_ss_cipher(struct ablkcipher_request *areq, u32 mode)
 +{
 + struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
 + struct sunxi_tfm_ctx *op = crypto_ablkcipher_ctx(tfm);
 + const char *cipher_type;
 +
 + if (areq-nbytes == 0)
 + return 0;
 +
 + if (areq-info == NULL) {
 + dev_err(ss-dev, ERROR: Empty IV\n);
 + return -EINVAL;
 + }
 +
 + if (areq-src == NULL || areq-dst == NULL) {
 + dev_err(ss-dev, ERROR: Some SGs are NULL\n);
 + return -EINVAL;
 + }
 +
 + cipher_type = crypto_tfm_alg_name(crypto_ablkcipher_tfm(tfm));
 +
 + if (strcmp(cbc(aes), cipher_type) == 0) {
 + mode |= SS_OP_AES | SS_CBC | SS_ENABLED | op-keymode;
 + return sunxi_ss_aes_poll(areq, mode);
 + }
 +
 + if (strcmp(cbc(des), cipher_type) == 0) {
 + mode |= SS_OP_DES | SS_CBC | SS_ENABLED | op-keymode;
 + return sunxi_ss_des_poll(areq, mode);
 + }
 +
 + if (strcmp(cbc(des3_ede), cipher_type) == 0) {
 + mode |= SS_OP_3DES | SS_CBC | SS_ENABLED | op-keymode;
 + return sunxi_ss_des_poll(areq, mode);
 + }
 +
 + dev_err(ss-dev, ERROR: Cipher %s not handled\n, cipher_type);
 +

[linux-sunxi] [PATCH v2 4/4] ARM: dts: sun7i: Add lradc node

2014-10-21 Thread Hans de Goede 
Signed-off-by: Hans de Goede hdego...@redhat.com
---
 arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts | 48 +
 arch/arm/boot/dts/sun7i-a20.dtsi|  7 
 2 files changed, 55 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts 
b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
index 9d669cdf..85e7194 100644
--- a/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-micro.dts
@@ -14,6 +14,7 @@
 /dts-v1/;
 /include/ sun7i-a20.dtsi
 /include/ sunxi-common-regulators.dtsi
+#include dt-bindings/input/input.h
 
 / {
model = Olimex A20-Olinuxino Micro;
@@ -100,6 +101,53 @@
};
};
 
+   lradc: lradc@01c22800 {
+   vref-supply = reg_vcc3v0;
+   status = okay;
+   button@19 {
+   label = Volume Up;
+   linux,code = KEY_VOLUMEUP;
+   channel = 0;
+   voltage = 191274;
+   };
+   button@39 {
+   label = Volume Down;
+   linux,code = KEY_VOLUMEDOWN;
+   channel = 0;
+   voltage = 392644;
+   };
+   button@60 {
+   label = Menu;
+   linux,code = KEY_MENU;
+   channel = 0;
+   voltage = 601151;
+   };
+   button@80 {
+   label = Enter;
+   linux,code = KEY_SEARCH;
+   channel = 0;
+   voltage = 795090;
+   };
+   button@98 {
+   label = Home;
+   linux,code = KEY_HOME;
+   channel = 0;
+   voltage = 987387;
+   };
+   button@118 {
+   label = Home;
+   linux,code = KEY_ESC;
+   channel = 0;
+   voltage = 1184678;
+   };
+   button@139 {
+   label = Home;
+   linux,code = KEY_ENTER;
+   channel = 0;
+   voltage = 1398804;
+   };
+   };
+
uart0: serial@01c28000 {
pinctrl-names = default;
pinctrl-0 = uart0_pins_a;
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index f0a75c6..219cd57 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -911,6 +911,13 @@
status = disabled;
};
 
+   lradc: lradc@01c22800 {
+   compatible = allwinner,sun4i-lradc-keys;
+   reg = 0x01c22800 0x100;
+   interrupts = 0 31 4;
+   status = disabled;
+   };
+
sid: eeprom@01c23800 {
compatible = allwinner,sun7i-a20-sid;
reg = 0x01c23800 0x200;
-- 
2.1.0

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

[linux-sunxi] [RFC Patch 0/4] mfd: AXP20x: Add power supply sub-driver

2014-10-21 Thread Bruno Prémont 
This series adds a power-supply driver to cover backup/RTC battery
charger, VBUS/OTG power in, AC power in and battery charger features
supported by AXP20x PMIC.

The DT bindings documentation patch depends on the following patch
from Carlo Caione:
  http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267604.html

Note, the reporting of some of the power supply interrupts might need
to be changed to dev_debug instead of dev_info.

For the DT bindings names they might need prefixing in which case
the corresponding prefix declaration patch from Carlo would be needed
as well:
  http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267606.html


Changes since initial posting on linux-sunxi:
 - A few typo fixes in strings/comments
 - Patch splitting

Bruno

-- 
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] [RFC Patch 4/4] mfd: AXP20x: Add backup battery DTS entry for Cubietruck

2014-10-21 Thread Bruno Prémont 

---
 arch/arm/boot/dts/sun7i-a20-cubietruck.dts   |4 +
 1 files changed, 2 insertions(+), 0 deletion(-)

diff --git a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts 
b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
index a6c1a3c..efb65fb 100644
--- a/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
+++ b/arch/arm/boot/dts/sun7i-a20-cubietruck.dts
@@ -125,6 +125,8 @@
 
interrupt-controller;
#interrupt-cells = 1;
+
+   backup = 300 200;
};
};
 
-- 
2.0.4

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

[linux-sunxi] Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation

2014-10-21 Thread Lee Jones 
On Mon, 20 Oct 2014, Bruno Prémont wrote:

 
 ---
 Note: the OCV values seem to have some defaults build into the
 PMIC though may need adjustment if the used battery has a different
 open circuit voltage curve.
 As far as understood (these values are set in vendor driver but not
 mentioned in chip documentation) they represent charge percentage
 for some predefined voltages.
 
 If prefixing these values with x-power, is preferred the following
 patch should becomes a dependency:
   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267606.html
 and users in patch 2/4, 4/4 need adjusting.
 
 
  Documentation/devicetree/bindings/mfd/axp20x.txt |   20 +
  1 files changed, 20 insertions(+), 0 deletion(-)
 
 diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
 b/Documentation/devicetree/bindings/mfd/axp20x.txt
 index cc9e01b..8ea681c 100644
 --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
 +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
 @@ -28,6 +28,20 @@ Required properties:
 (range: 750-1875). Default: 1.5MHz
  
  Optional properties for DCDCs:
 +- backup: Settings for backup/RTC battery charger
 +   (Voltage in µV, current in µA)
 +   If not present, charger will be left untouched
 +- battery.ocv: OCV capacity curve points (16 data values)
 +- battery.resistance: internal battery resistance in mΩ
 +  (defaults to 100mΩ)
 +- battery.capacity: Battery capacity in mAh
 + If this attribute is missing, charger will be disabled
 + unless there is a battery connected.
 +- battery.temp_sensor: Description of temperautre sensor, 3 values
 +- driver current (20µA, 40µA, 60µA or 80µA)
 +- low temperature warning level (in µV)
 +- high temperature warning level (in µV)
 +If missing, temperature sensor gets disabled
  - x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO mode
 Default: AUTO mode
  
 @@ -49,6 +63,12 @@ axp209: pmic@34 {
   ldo3in-supply = axp_ipsout_reg;
   ldo5in-supply = axp_ipsout_reg;
  
 + backup = 300 200;
 + battery.ocv = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0;
 + battery.resistance = 0;
 + battery.capacity = 2000;
 + battery.temp_sensor = 20 100 400;

Since when do we use '.'s in property names?

   regulators {
   x-powers,dcdc-freq = 1500;
  

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog

-- 
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: Resistive Touch Screen For A20 HummingBird Not Working ...!!

2014-10-21 Thread Tintu Thomas 
I checked the connections... But no short connection between any four 
points.  I just connected X1,X2,Y1,Y2 directly to the pins of A20 board as 
described. Does it need any resistor,capacitor in the connection..??? What 
about sunxi-ts.c ??? Is it in proper working condition??? It is found in 
some sites that we have to patch tslib ..??? and there is also some steps 
provided... (
http://www.dimrobotics.com/2013/06/olinuxino-a13-touchscreen-support-in.html)But
 
unfortunately I cannot do the patch... The commands are for ubuntu... I 
have no idea how to patch and insert the patched file into the device.. 
Any idea???

-- 
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 v6 2/2] mtd: nand: add sunxi NFC dt bindings doc

2014-10-21 Thread Boris Brezillon 
Hi Brian,

On Mon, 20 Oct 2014 19:41:34 -0700
Brian Norris computersforpe...@gmail.com wrote:

 Hi Boris,
 
 On Mon, Oct 20, 2014 at 01:45:20PM +0200, Boris Brezillon wrote:
  Add the sunxi NAND Flash Controller dt bindings documentation.
  
  Signed-off-by: Boris Brezillon boris.brezil...@free-electrons.com
  ---
   .../devicetree/bindings/mtd/sunxi-nand.txt | 45 
  ++
   1 file changed, 45 insertions(+)
   create mode 100644 Documentation/devicetree/bindings/mtd/sunxi-nand.txt
  
  diff --git a/Documentation/devicetree/bindings/mtd/sunxi-nand.txt 
  b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
  new file mode 100644
  index 000..0273adb
  --- /dev/null
  +++ b/Documentation/devicetree/bindings/mtd/sunxi-nand.txt
  @@ -0,0 +1,45 @@
  +Allwinner NAND Flash Controller (NFC)
  +
  +Required properties:
  +- compatible : allwinner,sun4i-a10-nand.
  +- reg : shall contain registers location and length for data and reg.
  +- interrupts : shall define the nand controller interrupt.
  +- #address-cells: shall be set to 1. Encode the nand CS.
  +- #size-cells : shall be set to 0.
  +- clocks : shall reference nand controller clocks.
  +- clock-names : nand controller internal clock names. Shall contain :
  +* ahb : AHB gating clock
  +* mod : nand controller clock
  +
  +Optional children nodes:
  +Children nodes represent the available nand chips.
  +
  +Optional properties:
  +- allwinner,rb : shall contain the native Ready/Busy ids.
  + or
  +- rb-gpios : shall contain the gpios used as R/B pins.
 
 I think you're relying on a named GPIO in your driver (nand-rb). That
 should be documented here.

Actually that's the name I assign to the pin when requesting it, this
has nothing to do with a specific property containing pin names for
specific gpio retrieval (as done for clocks with clock-names).

 
  +- nand-ecc-mode : one of the supported ECC modes (hw, hw_syndrome, 
  soft,
  +  soft_bch or none)
 
 I think you're utilizing an undocumented 'nand-name' property for this
 node in your driver too. Please document it. (That also goes for any
 other undocumented properties I may have missed.)

I'll drop this nand-name property and let the NAND core code choose a
name for the MTD device according to the discovered NAND chip.

Thanks,

Boris



-- 
Boris Brezillon, 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.

[linux-sunxi] Re: [PATCH v6 2/2] mtd: nand: add sunxi NFC dt bindings doc

2014-10-21 Thread Ezaul Zillmer 
OK vi agora V7 vou testar

Em terça-feira, 21 de outubro de 2014 11h13min16s UTC-2, Ezaul Zillmer 
escreveu:

 Hello everyone 

 Boris Brezillon 

 downloaded sunxi-nand-v6 now compiled for Cubieboard2 
 https://github.com/bbrezillon/linux-sunxi.git sunxi b-nand-v6 

 u-boot 
 git clone https://github.com/jwrdegoede/u-boot-b sunxi.git sunxi-wip 


 [1.143903] nand: Could not find valid JEDEC parameter page; aborting 
 [1.150369] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7 
 [1.156766] nand: Samsung NAND 4GiB 3.3V 8-bit 
 [1.161214] nand: 4096MiB, MLC, page size: 8192, OOB size: 640 
 [1.167167] sunxi_nand 1c03000.nand: ECC init failed: -22 
 [1.172588] sunxi_nand 1c03000.nand: failed to init nand chips 
 [1.178502] sunxi_nand: probe of 1c03000.nand failed with error -22 

 need some more data?



-- 
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 v6 2/2] mtd: nand: add sunxi NFC dt bindings doc

2014-10-21 Thread Boris Brezillon 
On Tue, 21 Oct 2014 06:13:16 -0700 (PDT)
Ezaul Zillmer ezaulzill...@gmail.com wrote:

 Hello everyone 
 
 Boris Brezillon 
 
 downloaded sunxi-nand-v6 now compiled for Cubieboard2 
 https://github.com/bbrezillon/linux-sunxi.git sunxi b-nand-v6 
 
 u-boot 
 git clone https://github.com/jwrdegoede/u-boot-b sunxi.git sunxi-wip 
 
 
 [1.143903] nand: Could not find valid JEDEC parameter page; aborting 
 [1.150369] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7 
 [1.156766] nand: Samsung NAND 4GiB 3.3V 8-bit 
 [1.161214] nand: 4096MiB, MLC, page size: 8192, OOB size: 640 
 [1.167167] sunxi_nand 1c03000.nand: ECC init failed: -22 
 [1.172588] sunxi_nand 1c03000.nand: failed to init nand chips 
 [1.178502] sunxi_nand: probe of 1c03000.nand failed with error -22 
 
 need some more data?

No, this is still the same problem you had last time you asked:

You haven't defined your NAND chip in the nand_ids table, and thus
strength and size fields of the nand_ecc_ctrl struct are undefined...

You'll have to retrieve the whole READ_ID sequence and add a proper
entry in the nand_ids table (see [1] for an example).

Regards,

Boris

[1]https://github.com/bbrezillon/linux-sunxi/commit/da96d64e6ece81e717bbdcad28caf0e5a9c40995

-- 
Boris Brezillon, 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.

[linux-sunxi] Re: [PATCH v5 4/4] crypto: Add Allwinner Security System crypto accelerator

2014-10-21 Thread Corentin LABBE 
On 10/21/14 01:28, Vladimir Zapolskiy wrote:
 Hello LABBE,
 
 On 19.10.2014 17:16, LABBE Corentin wrote:
 Add support for the Security System included in Allwinner SoC A20.
 The Security System is a hardware cryptographic accelerator that support 
 AES/MD5/SHA1/DES/3DES/PRNG algorithms.

[]
 +
 +/* If we have only one SG, we can use kmap_atomic */
 +if (sg_next(in_sg) == NULL  sg_next(out_sg) == NULL)
 +return sunxi_ss_aes_poll_atomic(areq);
 
 for clarity it might be better to move all mutex_unlock(ss-lock)
 calls from sunxi_ss_aes_poll_atomic() body right to here.
 

Ok
I have moved all mutex_unlock/writel(0, SS_CTL) at the end of function, it is 
cleaner now.

 +
 +};
 +
 +static int sunxi_ss_probe(struct platform_device *pdev)
 +{
 +struct resource *res;
 +u32 v;
 +int err;
 +unsigned long cr;
 +const unsigned long cr_ahb = 24 * 1000 * 1000;
 +const unsigned long cr_mod = 150 * 1000 * 1000;
 +
 +if (!pdev-dev.of_node)
 +return -ENODEV;
 +
 +ss = devm_kzalloc(pdev-dev, sizeof(*ss), GFP_KERNEL);
 +if (ss == NULL)
 +return -ENOMEM;
 
 Why do you dynamically allocate memory for struct sunxi_ss_ctx *ss?
 Since you have a single global pointer, it makes sense to declare
 struct sunxi_ss_ctx ss statically instead.
 
 And even a better solution is to remove a single global pointer.

All other crypto driver I have read use a global structure and it made things 
easy.
Thanks to M. Ripard that pointed to me the talitos driver that solve the global 
device pointer by using alg template and container_of().

But since I think there will never 2 Security System at the same time on the 
same SoC, I do not know if it is worth the cost to add more complexity just to 
remove a pointer.

 
 +
 +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 +ss-base = devm_ioremap_resource(pdev-dev, res);
 +if (IS_ERR(ss-base)) {
 +dev_err(pdev-dev, Cannot request MMIO\n);
 +return PTR_ERR(ss-base);
 +}
 +
 +ss-ssclk = devm_clk_get(pdev-dev, mod);
 +if (IS_ERR(ss-ssclk)) {
 +err = PTR_ERR(ss-ssclk);
 +dev_err(pdev-dev, Cannot get SS clock err=%d\n, err);
 +return err;
 +}
 +dev_dbg(pdev-dev, clock ss acquired\n);
 +
 +ss-busclk = devm_clk_get(pdev-dev, ahb);
 +if (IS_ERR(ss-busclk)) {
 +err = PTR_ERR(ss-busclk);
 +dev_err(pdev-dev, Cannot get AHB SS clock err=%d\n, err);
 +return err;
 +}
 +dev_dbg(pdev-dev, clock ahb_ss acquired\n);
 +
 +/* Enable both clocks */
 +err = clk_prepare_enable(ss-busclk);
 +if (err != 0) {
 +dev_err(pdev-dev, Cannot prepare_enable busclk\n);
 +return err;
 +}
 +err = clk_prepare_enable(ss-ssclk);
 +if (err != 0) {
 +dev_err(pdev-dev, Cannot prepare_enable ssclk\n);
 +clk_disable_unprepare(ss-busclk);
 
 goto somewhere to the end of the function?

OK

 
 +return err;
 +}
 +
 +/*
 + * Check that clock have the correct rates gived in the datasheet
 + * Try to set the clock to the maximum allowed
 + */
 +err = clk_set_rate(ss-ssclk, cr_mod);
 +if (err != 0) {
 +dev_err(pdev-dev, Cannot set clock rate to ssclk\n);
 +clk_disable_unprepare(ss-ssclk);
 +clk_disable_unprepare(ss-busclk);
 
 goto error_md5?

Ok

 
 +return err;
 +}
 +
 +cr = clk_get_rate(ss-busclk);
 +if (cr = cr_ahb)
 +dev_dbg(pdev-dev, Clock bus %lu (%lu MHz) (must be = 
 %lu)\n,
 +cr, cr / 100, cr_ahb);
 +else
 +dev_warn(pdev-dev, Clock bus %lu (%lu MHz) (must be = 
 %lu)\n,
 +cr, cr / 100, cr_ahb);
 
 See next comment.
 
 +cr = clk_get_rate(ss-ssclk);
 +if (cr = cr_mod)
 +if (cr  cr_mod)
 +dev_info(pdev-dev, Clock ss %lu (%lu MHz) (must be 
 = %lu)\n,
 +cr, cr / 100, cr_mod);
 +else
 +dev_dbg(pdev-dev, Clock ss %lu (%lu MHz) (must be = 
 %lu)\n,
 +cr, cr / 100, cr_mod);
 +else
 +dev_warn(pdev-dev, Clock ss is at %lu (%lu MHz) (must be = 
 %lu)\n,
 +cr, cr / 100, cr_mod);
 
 The management of kernel log levels looks pretty strange. As far as I
 understand there is no error on any clock rate, I'd recommend to keep
 only one information message.
 

If clock rate are below the recommended value, the only impact I found was bad 
performance.
So it explain the warn and no error. (yes the info must be warn, ...fixed)

But I will put comment for explain that.

 +/*
 + * Datasheet named it Die Bonding ID
 + * I expect to be a sort of Security System Revision number.
 + * Since the A80 seems to have an other version of SS
 + * this info could be useful
 +

[linux-sunxi] Re: [PATCH v2 1/4] input: Add new sun4i-lradc-keys driver

2014-10-21 Thread Maxime Ripard 
Hi Hans,

Thanks, a lot for respinning this.

On Tue, Oct 21, 2014 at 10:24:47AM +0200, Hans de Goede wrote:
 Allwinnner sunxi SoCs have a low resolution adc (called lradc) which is
 specifically designed to have various (tablet) keys (ie home, back, search,
 etc). attached to it using a resistor network. This adds a driver for this.
 
 There are 2 channels, currently this driver only supports chan0 since there
 are no boards known to use chan1.
 
 This has been tested on an olimex a10s-olinuxino-micro, a13-olinuxino, and
 a20-olinuxino-micro.
 
 Signed-off-by: Hans de Goede hdego...@redhat.com
 --
 Changes in v2:
 -Change devicetree bindings to use a per key subnode, like gpio-keys does
 ---
  .../devicetree/bindings/input/sun4i-lradc-keys.txt |  57 +
  MAINTAINERS|   7 +
  drivers/input/keyboard/Kconfig |  10 +
  drivers/input/keyboard/Makefile|   1 +
  drivers/input/keyboard/sun4i-lradc-keys.c  | 259 
 +
  5 files changed, 334 insertions(+)
  create mode 100644 
 Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
  create mode 100644 drivers/input/keyboard/sun4i-lradc-keys.c
 
 diff --git a/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt 
 b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
 new file mode 100644
 index 000..36a141b
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
 @@ -0,0 +1,57 @@
 +Allwinner sun4i low res adc attached tablet keys
 +
 +
 +Required properties:
 + - compatible: allwinner,sun4i-lradc-keys
 + - reg: mmio address range of the chip
 + - interrupts: interrupt to which the chip is connected
 + - vref-supply: powersupply for the lradc reference voltage
 +
 +Each key is represented as a sub-node of allwinner,sun4i-lradc-keys:
 +
 +Required subnode-properties:
 + - label: Descriptive name of the key.
 + - linux,code: Keycode to emit.
 + - channel: Channel this key is attached to, mut be 0 or 1.
 + - voltage: Voltage in µV at lradc input when this key is pressed.
 +
 +Example:
 +
 +#include dt-bindings/input/input.h
 +
 + lradc: lradc@01c22800 {
 + compatible = allwinner,sun4i-lradc-keys;

You're still using the old pattern for the compatible here, it should
be allwinner,sun4i-a10-lradc-keys.

 + reg = 0x01c22800 0x100;
 + interrupts = 31;
 + vref-supply = reg_vcc3v0;
 + button@19 {

I guess the node address in centivolts aren't really that common,
maybe in mV instead?

 + label = Volume Up;
 + linux,code = KEY_VOLUMEUP;
 + channel = 0;
 + voltage = 191274;
 + };

And a newline between the nodes please.

 + button@39 {
 + label = Volume Down;
 + linux,code = KEY_VOLUMEDOWN;
 + channel = 0;
 + voltage = 392644;
 + };
 + button@60 {
 + label = Menu;
 + linux,code = KEY_MENU;
 + channel = 0;
 + voltage = 601151;
 + };
 + button@80 {
 + label = Enter;
 + linux,code = KEY_ENTER;
 + channel = 0;
 + voltage = 795090;
 + };
 + button@98 {
 + label = Home;
 + linux,code = KEY_HOME;
 + channel = 0;
 + voltage = 987387;
 + };
 + };
 diff --git a/MAINTAINERS b/MAINTAINERS
 index a20df9b..73d1aef 100644
 --- a/MAINTAINERS
 +++ b/MAINTAINERS
 @@ -8932,6 +8932,13 @@ F: arch/m68k/sun3*/
  F:   arch/m68k/include/asm/sun3*
  F:   drivers/net/ethernet/i825xx/sun3*
  
 +SUN4I LOW RES ADC ATTACHED TABLET KEYS DRIVER
 +M:   Hans de Goede hdego...@redhat.com
 +L:   linux-in...@vger.kernel.org
 +S:   Maintained
 +F:   Documentation/devicetree/bindings/input/sun4i-lradc-keys.txt
 +F:   drivers/input/keyboard/sun4i-lradc-keys.c
 +
  SUNDANCE NETWORK DRIVER
  M:   Denis Kirjanov k...@linux-powerpc.org
  L:   net...@vger.kernel.org
 diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
 index a3958c6..2d11b44 100644
 --- a/drivers/input/keyboard/Kconfig
 +++ b/drivers/input/keyboard/Kconfig
 @@ -567,6 +567,16 @@ config KEYBOARD_STMPE
 To compile this driver as a module, choose M here: the module will be
 called stmpe-keypad.
  
 +config KEYBOARD_SUN4I_LRADC
 + tristate Allwinner sun4i low res adc attached tablet keys support
 + depends on ARCH_SUNXI
 + help
 +   This selects support for the Allwinner low res adc attached tablet
 +   keys found on Allwinner sunxi SoCs.
 +
 +   To compile this driver as a module, choose M here: the
 +

[linux-sunxi] Re: [PATCH v5 4/4] crypto: Add Allwinner Security System crypto accelerator

2014-10-21 Thread Vladimir Zapolskiy 
Hi Corentin,

On 21.10.2014 19:25, Corentin LABBE wrote:
 On 10/21/14 01:28, Vladimir Zapolskiy wrote:
 Hello LABBE,

 On 19.10.2014 17:16, LABBE Corentin wrote:
 Add support for the Security System included in Allwinner SoC A20.
 The Security System is a hardware cryptographic accelerator that support 
 AES/MD5/SHA1/DES/3DES/PRNG algorithms.

 []
 +
 +   /* If we have only one SG, we can use kmap_atomic */
 +   if (sg_next(in_sg) == NULL  sg_next(out_sg) == NULL)
 +   return sunxi_ss_aes_poll_atomic(areq);

 for clarity it might be better to move all mutex_unlock(ss-lock)
 calls from sunxi_ss_aes_poll_atomic() body right to here.

 
 Ok
 I have moved all mutex_unlock/writel(0, SS_CTL) at the end of function, it is 
 cleaner now.

please check that sunxi_ss_aes_poll_atomic() has no more mutex_unlock()
calls inside it.

With best wishes,
Vladimir

 +
 +};
 +
 +static int sunxi_ss_probe(struct platform_device *pdev)
 +{
 +   struct resource *res;
 +   u32 v;
 +   int err;
 +   unsigned long cr;
 +   const unsigned long cr_ahb = 24 * 1000 * 1000;
 +   const unsigned long cr_mod = 150 * 1000 * 1000;
 +
 +   if (!pdev-dev.of_node)
 +   return -ENODEV;
 +
 +   ss = devm_kzalloc(pdev-dev, sizeof(*ss), GFP_KERNEL);
 +   if (ss == NULL)
 +   return -ENOMEM;

 Why do you dynamically allocate memory for struct sunxi_ss_ctx *ss?
 Since you have a single global pointer, it makes sense to declare
 struct sunxi_ss_ctx ss statically instead.

 And even a better solution is to remove a single global pointer.
 
 All other crypto driver I have read use a global structure and it made things 
 easy.
 Thanks to M. Ripard that pointed to me the talitos driver that solve the 
 global device pointer by using alg template and container_of().
 
 But since I think there will never 2 Security System at the same time on the 
 same SoC, I do not know if it is worth the cost to add more complexity just 
 to remove a pointer.
 

 +
 +   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 +   ss-base = devm_ioremap_resource(pdev-dev, res);
 +   if (IS_ERR(ss-base)) {
 +   dev_err(pdev-dev, Cannot request MMIO\n);
 +   return PTR_ERR(ss-base);
 +   }
 +
 +   ss-ssclk = devm_clk_get(pdev-dev, mod);
 +   if (IS_ERR(ss-ssclk)) {
 +   err = PTR_ERR(ss-ssclk);
 +   dev_err(pdev-dev, Cannot get SS clock err=%d\n, err);
 +   return err;
 +   }
 +   dev_dbg(pdev-dev, clock ss acquired\n);
 +
 +   ss-busclk = devm_clk_get(pdev-dev, ahb);
 +   if (IS_ERR(ss-busclk)) {
 +   err = PTR_ERR(ss-busclk);
 +   dev_err(pdev-dev, Cannot get AHB SS clock err=%d\n, err);
 +   return err;
 +   }
 +   dev_dbg(pdev-dev, clock ahb_ss acquired\n);
 +
 +   /* Enable both clocks */
 +   err = clk_prepare_enable(ss-busclk);
 +   if (err != 0) {
 +   dev_err(pdev-dev, Cannot prepare_enable busclk\n);
 +   return err;
 +   }
 +   err = clk_prepare_enable(ss-ssclk);
 +   if (err != 0) {
 +   dev_err(pdev-dev, Cannot prepare_enable ssclk\n);
 +   clk_disable_unprepare(ss-busclk);

 goto somewhere to the end of the function?
 
 OK
 

 +   return err;
 +   }
 +
 +   /*
 +* Check that clock have the correct rates gived in the datasheet
 +* Try to set the clock to the maximum allowed
 +*/
 +   err = clk_set_rate(ss-ssclk, cr_mod);
 +   if (err != 0) {
 +   dev_err(pdev-dev, Cannot set clock rate to ssclk\n);
 +   clk_disable_unprepare(ss-ssclk);
 +   clk_disable_unprepare(ss-busclk);

 goto error_md5?
 
 Ok
 

 +   return err;
 +   }
 +
 +   cr = clk_get_rate(ss-busclk);
 +   if (cr = cr_ahb)
 +   dev_dbg(pdev-dev, Clock bus %lu (%lu MHz) (must be = 
 %lu)\n,
 +   cr, cr / 100, cr_ahb);
 +   else
 +   dev_warn(pdev-dev, Clock bus %lu (%lu MHz) (must be = 
 %lu)\n,
 +   cr, cr / 100, cr_ahb);

 See next comment.

 +   cr = clk_get_rate(ss-ssclk);
 +   if (cr = cr_mod)
 +   if (cr  cr_mod)
 +   dev_info(pdev-dev, Clock ss %lu (%lu MHz) (must be 
 = %lu)\n,
 +   cr, cr / 100, cr_mod);
 +   else
 +   dev_dbg(pdev-dev, Clock ss %lu (%lu MHz) (must be = 
 %lu)\n,
 +   cr, cr / 100, cr_mod);
 +   else
 +   dev_warn(pdev-dev, Clock ss is at %lu (%lu MHz) (must be = 
 %lu)\n,
 +   cr, cr / 100, cr_mod);

 The management of kernel log levels looks pretty strange. As far as I
 understand there is no error on any clock rate, I'd recommend to keep
 only one information message.

 
 If clock rate are below the recommended value, the only impact I found was 
 bad performance.
 So it explain the warn and no error. (yes the info must be warn, ...fixed)
 
 But I will put comment for explain that.
 
 +   /*
 +* Datasheet named it Die Bonding ID
 +* I expect to be a sort of Security System

Re: [linux-sunxi] Re: [PATCH 6/9] ARM: sunxi: Add support for R_PIO gpio banks

2014-10-21 Thread Ian Campbell 
On Fri, 2014-10-17 at 22:48 +0800, Chen-Yu Tsai wrote:
 Hi Ian,
 
 On Mon, Oct 13, 2014 at 8:57 PM, Maxime Ripard
 maxime.rip...@free-electrons.com wrote:
  On Sun, Oct 12, 2014 at 04:23:05PM +0800, Chen-Yu Tsai wrote:
  On Sun, Oct 12, 2014 at 12:05 AM, Ian Campbell i...@hellion.org.uk wrote:
   On Tue, 2014-10-07 at 15:11 +0800, Chen-Yu Tsai wrote:
   From: Hans de Goede hdego...@redhat.com
  
   The A31, A23 and later SoCs have an extra pin controller, called 
   CPUs_PIO
   or R_PIO, which handles pin banks L and beyond.
  
   Does it also have enough space for 9 banks? Since you overlay a struct
   sunxi_gpio_reg on it which has a gpio_bank[SUNXI_GPIO_BANKS] over it.
 
  Yes it does, as seen in the latest A31 manuals released by Allwinner.
 
   SUNXI_GPIO_BANKS is now also confusingly named since it is really
   number of banks on the first/original GPIO controller. Eventually
   someone will use it as the actual total and be very sad.
  
   I think it might be best if we retcon some distinct name onto the
   original GPIO controller so we can have SUNXIO_GPIO_BLA_BANKS and
   SUNXI_GPIO_R_BANKS (or even just call them controller 0 and 1 and have
   SUNXI_GPIO0_BANKS and SUNXI_GPIO1_BANKS, if that's not too confusing)
 
  The latest manuals have CPUx-PORT and CPUs-PORT for the respective
  chapters. I'm guessing x is for 0~3 cores, and s is for standby or
  something.
 
  iirc, it was meant for special.
 
 I'd like to keep it as SUNXI_GPIO_BANKS if possible. The GPIO and R_GPIO
 prefixes match what we see in Allwinner's sources and what we use in the
 mainline kernel.

OK, matching the mainline kernel is a sound plan.

 The comment section above it could be made clearer about it.
 
 Also that number would be bumped up for A80, which has pin bank J.
 I will change some of the R_PIO code to check/use the starting pin bank L
 number instead of checking against SUNXI_GPIO_BANKS. Wonder why I didn't
 do it before...

Sounds good.

  Of course it's also confusing that Allwinner's sources use the R_
  prefix for all hardware in that address range, while the datasheet
  lists the GPIO function names as s_something.
 
  We use the same pin convention than in the datasheet in mainline (but
  starting from PL for the special pins). And it's true that we do
  prefix all the functions by s_, once again, just like the datasheet
  does.
 
  The fact that it comes from a different controller is only expressed
  by where the pinctrl pins node is defined in the DT.
 
 I'm a bit undecided about how we should name the pin definitions.
 In the kernel, we named the function s_uart, but the pinconf node
 r_uart.
 
 In u-boot there isn't this separation. I'm wondering which would be
 easier to understand and relate to the underlying peripheral.
 At the moment I prefer R_UART.

Either is fine for me.

Ian.

-- 
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] [PATCH v3 6/6] sunxi: Kconfig: Unify sunxi Kconfig code

2014-10-21 Thread Ian Campbell 
On Sun, 2014-10-12 at 22:17 +0100, Ian Campbell wrote:
  -if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I
  +   default sun4i if TARGET_SUN4I
  +   default sun5i if TARGET_SUN5I
  +   default sun6i if TARGET_SUN5I

There is a typo here which is apparent with MAKEALL -s sunxi, since it
causes Colombus_defconfig not to build.

Patch is below but given the breakage is only in u-boot-sunxi.git#next
right now I think it would be better to fold it into the original patch.

Ian.

8

From 59d0b88a5025b2846227c0bde6ccdbb2e1bf916b Mon Sep 17 00:00:00 2001
From: Ian Campbell i...@hellion.org.uk
Date: Tue, 21 Oct 2014 20:00:28 +0100
Subject: [PATCH] sunxi: Fix build breakage for sun6i

u-boot-sunxi.git#next currently fails with:

In file included from 
/local/scratch/ijc/development/u-boot.git/include/common.h:18:0:
include/config.h:5:22: fatal error: configs/.h: No such file or directory
 #include configs/.h
  ^
This is due to a typo in board/sunxi/Kconfig which causes
CONFIG_SYS_CONFIG_NAME to be undefined for sun6i platforms.

Signed-off-by: Ian Campbell i...@hellion.org.uk
---
 board/sunxi/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 4ac562c..9892a34 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -4,7 +4,7 @@ config SYS_CONFIG_NAME
string
default sun4i if TARGET_SUN4I
default sun5i if TARGET_SUN5I
-   default sun6i if TARGET_SUN5I
+   default sun6i if TARGET_SUN6I
default sun7i if TARGET_SUN7I
 
 config SYS_CPU
-- 
2.1.0



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

[linux-sunxi] Re: [PATCH v5 4/4] crypto: Add Allwinner Security System crypto accelerator

2014-10-21 Thread Maxime Ripard 
Hi Corentin,

Thanks for resending it.

On Sun, Oct 19, 2014 at 04:16:22PM +0200, LABBE Corentin wrote:
 Add support for the Security System included in Allwinner SoC A20.
 The Security System is a hardware cryptographic accelerator that support 
 AES/MD5/SHA1/DES/3DES/PRNG algorithms.
 
 Signed-off-by: LABBE Corentin clabbe.montj...@gmail.com
 ---
  drivers/crypto/Kconfig|  17 ++
  drivers/crypto/Makefile   |   1 +
  drivers/crypto/sunxi-ss/Makefile  |   2 +
  drivers/crypto/sunxi-ss/sunxi-ss-cipher.c | 489 
 ++
  drivers/crypto/sunxi-ss/sunxi-ss-core.c   | 318 +++
  drivers/crypto/sunxi-ss/sunxi-ss-hash.c   | 445 +++
  drivers/crypto/sunxi-ss/sunxi-ss.h| 193 
  7 files changed, 1465 insertions(+)
  create mode 100644 drivers/crypto/sunxi-ss/Makefile
  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-core.c
  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss-hash.c
  create mode 100644 drivers/crypto/sunxi-ss/sunxi-ss.h
 
 diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
 index 2fb0fdf..9ba9759 100644
 --- a/drivers/crypto/Kconfig
 +++ b/drivers/crypto/Kconfig
 @@ -436,4 +436,21 @@ config CRYPTO_DEV_QCE
 hardware. To compile this driver as a module, choose M here. The
 module will be called qcrypto.
  
 +config CRYPTO_DEV_SUNXI_SS
 + tristate Support for Allwinner Security System cryptographic 
 accelerator
 + depends on ARCH_SUNXI
 + select CRYPTO_MD5
 + select CRYPTO_SHA1
 + select CRYPTO_AES
 + select CRYPTO_DES
 + select CRYPTO_BLKCIPHER
 + help
 +   Some Allwinner SoC have a crypto accelerator named
 +   Security System. Select this if you want to use it.
 +   The Security System handle AES/DES/3DES ciphers in CBC mode
 +   and SHA1 and MD5 hash algorithms.
 +
 +   To compile this driver as a module, choose M here: the module
 +   will be called sunxi-ss.
 +
  endif # CRYPTO_HW
 diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
 index 3924f93..856545c 100644
 --- a/drivers/crypto/Makefile
 +++ b/drivers/crypto/Makefile
 @@ -25,3 +25,4 @@ obj-$(CONFIG_CRYPTO_DEV_TALITOS) += talitos.o
  obj-$(CONFIG_CRYPTO_DEV_UX500) += ux500/
  obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
 +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss/
 diff --git a/drivers/crypto/sunxi-ss/Makefile 
 b/drivers/crypto/sunxi-ss/Makefile
 new file mode 100644
 index 000..8bb287d
 --- /dev/null
 +++ b/drivers/crypto/sunxi-ss/Makefile
 @@ -0,0 +1,2 @@
 +obj-$(CONFIG_CRYPTO_DEV_SUNXI_SS) += sunxi-ss.o
 +sunxi-ss-y += sunxi-ss-core.o sunxi-ss-hash.o sunxi-ss-cipher.o
 diff --git a/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c 
 b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
 new file mode 100644
 index 000..8d0416e
 --- /dev/null
 +++ b/drivers/crypto/sunxi-ss/sunxi-ss-cipher.c
 @@ -0,0 +1,489 @@
 +/*
 + * sunxi-ss-cipher.c - hardware cryptographic accelerator for Allwinner A20 
 SoC
 + *
 + * Copyright (C) 2013-2014 Corentin LABBE clabbe.montj...@gmail.com
 + *
 + * This file add support for AES cipher with 128,192,256 bits
 + * keysize in CBC mode.
 + * Add support also for DES and 3DES in CBC mode.
 + *
 + * You could find the datasheet in Documentation/arm/sunxi/README
 + *
 + * 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 sunxi-ss.h
 +
 +extern struct sunxi_ss_ctx *ss;
 +
 +static int sunxi_ss_cipher(struct ablkcipher_request *areq, u32 mode)
 +{
 + struct crypto_ablkcipher *tfm = crypto_ablkcipher_reqtfm(areq);
 + struct sunxi_tfm_ctx *op = crypto_ablkcipher_ctx(tfm);
 + const char *cipher_type;
 +
 + if (areq-nbytes == 0)
 + return 0;
 +
 + if (areq-info == NULL) {
 + dev_err(ss-dev, ERROR: Empty IV\n);
 + return -EINVAL;
 + }
 +
 + if (areq-src == NULL || areq-dst == NULL) {
 + dev_err(ss-dev, ERROR: Some SGs are NULL\n);
 + return -EINVAL;
 + }
 +
 + cipher_type = crypto_tfm_alg_name(crypto_ablkcipher_tfm(tfm));
 +
 + if (strcmp(cbc(aes), cipher_type) == 0) {
 + mode |= SS_OP_AES | SS_CBC | SS_ENABLED | op-keymode;
 + return sunxi_ss_aes_poll(areq, mode);
 + }
 +
 + if (strcmp(cbc(des), cipher_type) == 0) {
 + mode |= SS_OP_DES | SS_CBC | SS_ENABLED | op-keymode;
 + return sunxi_ss_des_poll(areq, mode);
 + }
 +
 + if (strcmp(cbc(des3_ede), cipher_type) == 0) {
 + mode |= SS_OP_3DES | SS_CBC | SS_ENABLED | op-keymode;
 + return sunxi_ss_des_poll(areq, mode);
 + }
 +
 + dev_err(ss-dev, ERROR:

[linux-sunxi] Re: [RFC Patch 1/4] mfd: AXP20x: Add power supply bindings documentation

2014-10-21 Thread Maxime Ripard 
Hi Bruno,

Thanks a lot for working on this!

On Tue, Oct 21, 2014 at 06:09:16PM +0200, Bruno Prémont wrote:
 On Tue, 21 October 2014 Lee Jones lee.jo...@linaro.org wrote:
  On Mon, 20 Oct 2014, Bruno Prémont wrote:
   ---
   Note: the OCV values seem to have some defaults build into the
   PMIC though may need adjustment if the used battery has a different
   open circuit voltage curve.
   As far as understood (these values are set in vendor driver but not
   mentioned in chip documentation) they represent charge percentage
   for some predefined voltages.
   
   If prefixing these values with x-power, is preferred the following
   patch should becomes a dependency:
 
   http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/267606.html
   and users in patch 2/4, 4/4 need adjusting.
   
   
Documentation/devicetree/bindings/mfd/axp20x.txt |   20 +
1 files changed, 20 insertions(+), 0 deletion(-)
   
   diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
   b/Documentation/devicetree/bindings/mfd/axp20x.txt
   index cc9e01b..8ea681c 100644
   --- a/Documentation/devicetree/bindings/mfd/axp20x.txt
   +++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
   @@ -28,6 +28,20 @@ Required properties:
   (range: 750-1875). Default: 1.5MHz

Optional properties for DCDCs:
   +- backup: Settings for backup/RTC battery charger
   +   (Voltage in µV, current in µA)
   +   If not present, charger will be left untouched
   +- battery.ocv: OCV capacity curve points (16 data values)
   +- battery.resistance: internal battery resistance in mΩ
   +  (defaults to 100mΩ)
   +- battery.capacity: Battery capacity in mAh
   + If this attribute is missing, charger will be disabled
   + unless there is a battery connected.
   +- battery.temp_sensor: Description of temperautre sensor, 3 values
   +- driver current (20µA, 40µA, 60µA or 80µA)
   +- low temperature warning level (in µV)
   +- high temperature warning level (in µV)
   +If missing, temperature sensor gets disabled
- x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO mode
   Default: AUTO mode

   @@ -49,6 +63,12 @@ axp209: pmic@34 {
 ldo3in-supply = axp_ipsout_reg;
 ldo5in-supply = axp_ipsout_reg;

   + backup = 300 200;
   + battery.ocv = 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0;
   + battery.resistance = 0;
   + battery.capacity = 2000;
   + battery.temp_sensor = 20 100 400;
  
  Since when do we use '.'s in property names?
 
 I've not found guidelines on this, but whatever is the right way to
 name them, I'm open for suggestions.

You can take a look at the ePAPR specs. Even if it's quite outdated,
it still puts you in the right mindset.

That being said, since they are driver-specific properties, they
should be prefixed by the vendor name (here x-powers).

And I think they all belong in a sub-node, just like what's been done
for the regulators.

Maxime

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


signature.asc
Description: Digital signature

[linux-sunxi] Re: [U-Boot] [PATCH v3 6/6] sunxi: Kconfig: Unify sunxi Kconfig code

2014-10-21 Thread Tom Rini 
On Tue, Oct 21, 2014 at 08:03:59PM +0100, Ian Campbell wrote:
 On Sun, 2014-10-12 at 22:17 +0100, Ian Campbell wrote:
   -if TARGET_SUN4I || TARGET_SUN5I || TARGET_SUN6I || TARGET_SUN7I
   + default sun4i if TARGET_SUN4I
   + default sun5i if TARGET_SUN5I
   + default sun6i if TARGET_SUN5I
 
 There is a typo here which is apparent with MAKEALL -s sunxi, since it
 causes Colombus_defconfig not to build.
 
 Patch is below but given the breakage is only in u-boot-sunxi.git#next
 right now I think it would be better to fold it into the original patch.

Yes, fold it in, thanks!

-- 
Tom


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH v2 1/5] clk: sunxi: make factors clock mux mask configurable

2014-10-21 Thread Maxime Ripard 
On Mon, Oct 20, 2014 at 10:10:26PM +0800, Chen-Yu Tsai wrote:
 Some of the factors-style clocks on the A80 have different widths
 for the mux values in the registers.
 
 Add a .muxmask field to clk_factors_config to make it configurable.
 Passing a bitmask instead of a width parameter will allow reuse
 in case we support table-based muxes in the future.
 
 Signed-off-by: Chen-Yu Tsai w...@csie.org

Applied, 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 v2 2/5] clk: sunxi: Add support for A80 basic bus clocks

2014-10-21 Thread Maxime Ripard 
On Mon, Oct 20, 2014 at 10:10:27PM +0800, Chen-Yu Tsai wrote:
 The A80 SoC has 12 PLL clocks, 3 AHB clocks, 2 APB clocks, and a
 new GT bus, which I assume is some kind of data bus connecting
 the processor cores, memory and various busses. Also there is a
 bus clock for a ARM CCI400 module.
 
 As far as I can tell, the GT bus and CCI400 bus clock must be
 protected.
 
 This patch adds driver support for peripheral related PLLs and
 bus clocks on the A80. The GT and CCI400 clocks are added as well
 as these 2 along with the PLLs they are clocked from must not be
 disabled.
 
 Signed-off-by: Chen-Yu Tsai w...@csie.org

Applied, 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 v2 3/5] clk: sunxi: Add support for bus clock gates on Allwinner A80 SoC

2014-10-21 Thread Maxime Ripard 
On Mon, Oct 20, 2014 at 10:10:28PM +0800, Chen-Yu Tsai wrote:
 This adds the gate clocks for AHB/APB busses on the A80 SoC.
 
 Signed-off-by: Chen-Yu Tsai w...@csie.org

Applied, 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 v2 5/5] ARM: dts: sun9i: Add basic clocks and reset controls

2014-10-21 Thread Maxime Ripard 
On Mon, Oct 20, 2014 at 10:10:30PM +0800, Chen-Yu Tsai wrote:
 Now that we have driver support for the basic clocks, add them to the
 dtsi and update existing peripherals. Also add reset controls to match.
 
 Signed-off-by: Chen-Yu Tsai w...@csie.org

Applied, thanks!

Maxime

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


signature.asc
Description: Digital signature