Re: [linux-sunxi] [PATCH 0/2] ASoC: Add support for the Allwinner A10 codec

2015-09-30 Thread Mark Brown 
On Tue, Sep 29, 2015 at 11:13:56PM +0200, Hans de Goede wrote:

> On both A10 and A20 I need to enable to following for things to work:

> unmute Pre-Amplifier DAC
> unmute Pre-Amplifier Mute

> I guess this is just a question if adding some mixer defaults to
> the alsa userspace somewhere ?

Yes, you're looking for something in /usr/share/alsa/cards here (shipped
in alsa-lib).

-- 
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][PATCH v5] ARM: sun7i: dt: Add new Olimex A20 EVB device

2015-09-30 Thread codekipper 
From: Marcus Cooper 

The A20-SOM-EVB is a reference design of a 2-layer board for the
A20-SOM.
It expands the features of A20-SOM by adding VGA connector, HDMI
connector, audio In/Out, LCD connector, 2 Mpix camera, gigabit
Ethernet, SATA, USB-OTG and 2 USB hosts.

Signed-off-by: Marcus Cooper 
---
Changes since v4:
- removed reg_usb0_vbus which will return when usb otg is added.
Changes since v3:
- removed i2c1 as it's not used
- removed axp_ipsout regulator
Changes since v2:
- changed dcdc2 to have max voltage of 1.4V
Changes since v1:
- renamed dts from sun7i-a20-olinuxino-evb to sun7i-a20-olimex-som-evb
- added "axp209 dtsi"
- change regulator settings
---
 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts | 198 +
 2 files changed, 199 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index cce5468..19d39a9 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -619,6 +619,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-i12-tvbox.dtb \
sun7i-a20-m3.dtb \
sun7i-a20-mk808c.dtb \
+   sun7i-a20-olimex-som-evb.dtb \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
sun7i-a20-olinuxino-micro.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts 
b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
new file mode 100644
index 000..f6c37cd
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-olimex-som-evb.dts
@@ -0,0 +1,198 @@
+/*
+ * Copyright 2015 - Marcus Cooper 
+ *
+ * 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 file 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 file 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 "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+
+/ {
+   model = "Olimex A20-Olimex-SOM-EVB";
+   compatible = "olimex,a20-olimex-som-evb", "allwinner,sun7i-a20";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   leds {
+   compatible = "gpio-leds";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_olimex_som_evb>;
+
+   green {
+   label = "a20-olimex-som-evb:green:usr";
+   gpios = < 7 2 GPIO_ACTIVE_HIGH>;
+   default-state = "on";
+   };
+   };
+};
+
+ {
+   target-supply = <_ahci_5v>;
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   status = "okay";
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_rgmii_a>;
+   phy = <>;
+   phy-mode = "rgmii";
+   status = "okay";
+
+   phy1: ethernet-phy@1 {
+   reg = <1>;
+   };
+};
+
+ {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+
+   axp209: pmic@34 {
+   reg = <0x34>;
+

[linux-sunxi] Re: [PATCH 2/2] mtd: sunxi: nand: refactor ->read_page()/->write_page() code

2015-09-30 Thread Brian Norris 
On Wed, Sep 16, 2015 at 09:46:37AM +0200, Boris Brezillon wrote:
> Most of the logic to read/write pages with the HW ECC engine enabled
> is common to the HW_ECC and NAND_ECC_HW_SYNDROME scheme.
> Refactor the code to avoid code duplication.

Hmm, a benign commit description to describe a somewhat complicated
patch. This seems to do several different types of refactoring all at
once, and it makes it a bit hard to review. Can you perhaps refactor
this into 2 or more patches? e.g., I think the NFC_USER_DATA_TO_BUF()
stuff can be orthogonal from the introduction of
sunxi_nfc_hw_ecc_read_chunk() and sunxi_nfc_hw_ecc_read_extra_oob().

> Signed-off-by: Boris Brezillon 
> ---
>  drivers/mtd/nand/sunxi_nand.c | 404 
> ++
>  1 file changed, 212 insertions(+), 192 deletions(-)
> 
> diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> index dc44435..640b96c 100644
> --- a/drivers/mtd/nand/sunxi_nand.c
> +++ b/drivers/mtd/nand/sunxi_nand.c
> @@ -159,6 +159,13 @@
>  /* NFC_USER_DATA helper macros */
>  #define NFC_BUF_TO_USER_DATA(buf)((buf)[0] | ((buf)[1] << 8) | \
>   ((buf)[2] << 16) | ((buf)[3] << 24))
> +#define NFC_USER_DATA_TO_BUF(buf, val)   \
> + {   \
> + (buf)[0] = val; \
> + (buf)[1] = val >> 8;\
> + (buf)[2] = val >> 16;   \
> + (buf)[3] = val >> 24;   \
> + }

Two things about this macro:

  1) you should probably wrap 'val' in parentheses

  2) the use of 'val' 4 times in this macro means it will be evaluated 4
  times; this *can* be OK, except the 'val' parameter as used in context
  is actually a register read (readl()). Is this intentional? Anyway,
  such a construct kinda hides the actual behavior, whether or not it's
  intentional.

To kill off all concerns, perhaps this should be a static inline
function instead. And we might do the same with NFC_BUF_TO_USER_DATA()
then, to match.

Brian

>  
>  #define NFC_DEFAULT_TIMEOUT_MS   1000
>  

[snip rest of patch]

-- 
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 v2 4/4] ASOC: sunxi: Add support for the spdif block

2015-09-30 Thread kbuild test robot 
Hi Marcus,

[auto build test results on next-20150930 -- if it's inappropriate base, please 
ignore]

reproduce:
  # apt-get install sparse
  make ARCH=x86_64 allmodconfig
  make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> sound/soc/sunxi/sun4i-spdif.c:207:6: sparse: symbol 'sun4i_snd_txctrl_on' 
>> was not declared. Should it be static?
>> sound/soc/sunxi/sun4i-spdif.c:231:6: sparse: symbol 'sun4i_snd_txctrl_off' 
>> was not declared. Should it be static?
>> sound/soc/sunxi/sun4i-spdif.c:451:28: sparse: incorrect type in initializer 
>> (different base types)
   sound/soc/sunxi/sun4i-spdif.c:451:28:expected unsigned long long 
[unsigned] [usertype] formats
   sound/soc/sunxi/sun4i-spdif.c:451:28:got restricted snd_pcm_format_t

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

-- 
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] mtd: nand: sunxi: rework macros

2015-09-30 Thread Brian Norris 
On Wed, Sep 16, 2015 at 09:46:36AM +0200, Boris Brezillon wrote:
> Suffix mask macros with _MSK and add new helper macros to avoid manually
> shifting values.
> 
> Signed-off-by: Boris Brezillon 

Pushed patch 1 to l2-mtd.git

-- 
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 2/2] mtd: sunxi: nand: refactor ->read_page()/->write_page() code

2015-09-30 Thread Boris Brezillon 
Hi Brian,

On Wed, 30 Sep 2015 11:36:27 -0700
Brian Norris  wrote:

> On Wed, Sep 16, 2015 at 09:46:37AM +0200, Boris Brezillon wrote:
> > Most of the logic to read/write pages with the HW ECC engine enabled
> > is common to the HW_ECC and NAND_ECC_HW_SYNDROME scheme.
> > Refactor the code to avoid code duplication.
> 
> Hmm, a benign commit description to describe a somewhat complicated
> patch. This seems to do several different types of refactoring all at
> once, and it makes it a bit hard to review. Can you perhaps refactor
> this into 2 or more patches?

Fair enough, I'll try to split it in several pieces.

> e.g., I think the NFC_USER_DATA_TO_BUF()
> stuff can be orthogonal from the introduction of
> sunxi_nfc_hw_ecc_read_chunk() and sunxi_nfc_hw_ecc_read_extra_oob().

Yes, it is, even if I doubt removing this small piece of code can make
the patch more readable ;-).

> 
> > Signed-off-by: Boris Brezillon 
> > ---
> >  drivers/mtd/nand/sunxi_nand.c | 404 
> > ++
> >  1 file changed, 212 insertions(+), 192 deletions(-)
> > 
> > diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
> > index dc44435..640b96c 100644
> > --- a/drivers/mtd/nand/sunxi_nand.c
> > +++ b/drivers/mtd/nand/sunxi_nand.c
> > @@ -159,6 +159,13 @@
> >  /* NFC_USER_DATA helper macros */
> >  #define NFC_BUF_TO_USER_DATA(buf)  ((buf)[0] | ((buf)[1] << 8) | \
> > ((buf)[2] << 16) | ((buf)[3] << 24))
> > +#define NFC_USER_DATA_TO_BUF(buf, val) \
> > +   {   \
> > +   (buf)[0] = val; \
> > +   (buf)[1] = val >> 8;\
> > +   (buf)[2] = val >> 16;   \
> > +   (buf)[3] = val >> 24;   \
> > +   }
> 
> Two things about this macro:
> 
>   1) you should probably wrap 'val' in parentheses

Yep ...

> 
>   2) the use of 'val' 4 times in this macro means it will be evaluated 4
>   times; this *can* be OK, except the 'val' parameter as used in context
>   is actually a register read (readl()). Is this intentional? Anyway,
>   such a construct kinda hides the actual behavior, whether or not it's
>   intentional.

... and no, it's not intentional.

> 
> To kill off all concerns, perhaps this should be a static inline
> function instead. And we might do the same with NFC_BUF_TO_USER_DATA()
> then, to match.

I like this idea (I'll use lower cases if I convert them to inline
functions).

Best Regards,

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] [PATCH v2 4/4] ASOC: sunxi: Add support for the spdif block

2015-09-30 Thread codekipper 
From: Marcus Cooper 

The sun4i, sun6i and sun7i SoC families have an SPDIF
block which is capable of playback and capture.

This patch enables the playback of this block for
the sun4i and sun7i families.

Signed-off-by: Marcus Cooper 
---
 sound/soc/sunxi/Kconfig   |  12 +
 sound/soc/sunxi/Makefile  |   4 +
 sound/soc/sunxi/sun4i-spdif.c | 612 ++
 3 files changed, 628 insertions(+)
 create mode 100644 sound/soc/sunxi/sun4i-spdif.c

diff --git a/sound/soc/sunxi/Kconfig b/sound/soc/sunxi/Kconfig
index 84c72ec..2ebf43d 100644
--- a/sound/soc/sunxi/Kconfig
+++ b/sound/soc/sunxi/Kconfig
@@ -8,4 +8,16 @@ config SND_SUN4I_CODEC
  Select Y or M to add support for the Codec embedded in the Allwinner
  A10 and affiliated SoCs.
 
+config SND_SOC_SUNXI_DAI_SPDIF
+tristate
+   depends on OF
+select SND_SOC_GENERIC_DMAENGINE_PCM
+select REGMAP_MMIO
+
+config SND_SOC_SUNXI_MACHINE_SPDIF
+tristate "APB on-chip sun4i/sun5i/sun7i SPDIF"
+   depends on OF
+select SND_SOC_SUNXI_DAI_SPDIF
+help
+  Say Y if you want to add support for SoC S/PDIF audio as simple 
audio card.
 endmenu
diff --git a/sound/soc/sunxi/Makefile b/sound/soc/sunxi/Makefile
index ea8a08c..c8c0a00 100644
--- a/sound/soc/sunxi/Makefile
+++ b/sound/soc/sunxi/Makefile
@@ -1,2 +1,6 @@
 obj-$(CONFIG_SND_SUN4I_CODEC) += sun4i-codec.o
 
+snd-soc-sunxi-dai-spdif-objs := sun4i-spdif.o
+obj-$(CONFIG_SND_SOC_SUNXI_DAI_SPDIF) += snd-soc-sunxi-dai-spdif.o
+snd-soc-sunxi-machine-spdif-objs := sunxi-machine-spdif.o
+obj-$(CONFIG_SND_SOC_SUNXI_MACHINE_SPDIF) += snd-soc-sunxi-machine-spdif.o
diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
new file mode 100644
index 000..5fff6f6
--- /dev/null
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -0,0 +1,612 @@
+/*
+ * ALSA SoC SPDIF Audio Layer
+ *
+ * Copyright 2015 Andrea Venturi 
+ * Copyright 2015 Marcus Cooper 
+ *
+ * Based on the Allwinner SDK driver, released under the GPL.
+ *
+ * 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.
+ */
+
+/*
+ * this is SPDIF sun4i simple audio card DAI driver that uses the codec
+ * "dummy driver" as per sound/soc/fsl/imx-spdif.c
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#defineSUN4I_SPDIF_CTL (0x00)
+   #define SUN4I_SPDIF_CTL_MCLKDIV(v)  ((v) << 4) /* v even */
+   #define SUN4I_SPDIF_CTL_MCLKOUTEN   BIT(2)
+   #define SUN4I_SPDIF_CTL_GEN BIT(1)
+   #define SUN4I_SPDIF_CTL_RESET   BIT(0)
+
+#define SUN4I_SPDIF_TXCFG  (0x04)
+   #define SUN4I_SPDIF_TXCFG_SINGLEMOD BIT(31)
+   #define SUN4I_SPDIF_TXCFG_ASS   BIT(17)
+   #define SUN4I_SPDIF_TXCFG_NONAUDIO  BIT(16)
+   #define SUN4I_SPDIF_TXCFG_TXRATIO(v)((v) << 4)
+   #define SUN4I_SPDIF_TXCFG_TXRATIO_MASK  GENMASK(8, 4)
+   #define SUN4I_SPDIF_TXCFG_FMTRVDGENMASK(3, 2)
+   #define SUN4I_SPDIF_TXCFG_FMT16BIT  (0 << 2)
+   #define SUN4I_SPDIF_TXCFG_FMT20BIT  (1 << 2)
+   #define SUN4I_SPDIF_TXCFG_FMT24BIT  (2 << 2)
+   #define SUN4I_SPDIF_TXCFG_CHSTMODE  BIT(1)
+   #define SUN4I_SPDIF_TXCFG_TXEN  BIT(0)
+
+#define SUN4I_SPDIF_RXCFG  (0x08)
+   #define SUN4I_SPDIF_RXCFG_LOCKFLAG  BIT(4)
+   #define SUN4I_SPDIF_RXCFG_CHSTSRC   BIT(3)
+   #define SUN4I_SPDIF_RXCFG_CHSTCPBIT(1)
+   #define SUN4I_SPDIF_RXCFG_RXEN  BIT(0)
+
+#define SUN4I_SPDIF_TXFIFO (0x0C)
+
+#define SUN4I_SPDIF_RXFIFO (0x10)
+
+#define SUN4I_SPDIF_FCTL   (0x14)
+   #define SUN4I_SPDIF_FCTL_FIFOSRCBIT(31)
+   #define SUN4I_SPDIF_FCTL_FTXBIT(17)
+   #define SUN4I_SPDIF_FCTL_FRXBIT(16)
+   #define SUN4I_SPDIF_FCTL_TXTL(v)((v) << 8)
+   #define SUN4I_SPDIF_FCTL_TXTL_MASK  GENMASK(12, 8)
+   #define SUN4I_SPDIF_FCTL_RXTL(v)((v) << 3)
+   #define SUN4I_SPDIF_FCTL_RXTL_MASK  GENMASK(7, 3)
+   #define SUN4I_SPDIF_FCTL_TXIM   BIT(2)
+   #define

[linux-sunxi] [PATCH v2 3/4] ASoC: sunxi: Add S/PDIF machine driver.

2015-09-30 Thread codekipper 
From: Marcus Cooper 

Signed-off-by: Marcus Cooper 
---
 sound/soc/sunxi/sunxi-machine-spdif.c | 108 ++
 1 file changed, 108 insertions(+)
 create mode 100644 sound/soc/sunxi/sunxi-machine-spdif.c

diff --git a/sound/soc/sunxi/sunxi-machine-spdif.c 
b/sound/soc/sunxi/sunxi-machine-spdif.c
new file mode 100644
index 000..2adb727
--- /dev/null
+++ b/sound/soc/sunxi/sunxi-machine-spdif.c
@@ -0,0 +1,108 @@
+/*
+ * Copyright (C) 2015 Andrea Venturi 
+ * From code by (C) 2013 Freescale Semiconductor, Inc.
+ * (sound/soc/fsl/imx-spdif.c)
+ *
+ * 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 
+
+struct sunxi_machine_spdif_data {
+   struct snd_soc_dai_link dai;
+   struct snd_soc_card card;
+};
+
+static int sunxi_machine_spdif_audio_probe(struct platform_device *pdev)
+{
+   struct device_node *spdif_np, *np = pdev->dev.of_node;
+   struct sunxi_machine_spdif_data *data;
+   int ret = 0;
+
+   dev_dbg(>dev, "%s: Looking for spdif-controller\n", __func__);
+   spdif_np = of_parse_phandle(np, "spdif-controller", 0);
+   if (!spdif_np) {
+   dev_err(>dev, "failed to find spdif-controller\n");
+   ret = -EINVAL;
+   goto end;
+   }
+
+   data = devm_kzalloc(>dev, sizeof(*data), GFP_KERNEL);
+   if (!data) {
+   ret = -ENOMEM;
+   goto end;
+   }
+
+   data->dai.name = "S/PDIF PCM";
+   data->dai.stream_name = "S/PDIF PCM";
+   data->dai.codec_dai_name = "snd-soc-dummy-dai";
+   data->dai.codec_name = "snd-soc-dummy";
+   data->dai.cpu_of_node = spdif_np;
+   data->dai.platform_of_node = spdif_np;
+   data->dai.playback_only = true;
+   data->dai.capture_only = true;
+
+   if (of_property_read_bool(np, "spdif-out"))
+   data->dai.capture_only = false;
+
+   if (of_property_read_bool(np, "spdif-in"))
+   data->dai.playback_only = false;
+
+   if (data->dai.playback_only && data->dai.capture_only) {
+   dev_err(>dev, "no enabled S/PDIF DAI link\n");
+   goto end;
+   }
+
+   data->card.dev = >dev;
+   data->card.dai_link = >dai;
+   data->card.num_links = 1;
+   data->card.owner = THIS_MODULE;
+
+   ret = snd_soc_of_parse_card_name(>card, "model");
+   if (ret)
+   goto end;
+
+   ret = devm_snd_soc_register_card(>dev, >card);
+   if (ret) {
+   dev_err(>dev, "snd_soc_register_card failed: %d\n", ret);
+   goto end;
+   }
+
+   platform_set_drvdata(pdev, data);
+
+end:
+   of_node_put(spdif_np);
+
+   return ret;
+}
+
+static const struct of_device_id sunxi_machine_spdif_dt_ids[] = {
+   { .compatible = "allwinner,sunxi-audio-spdif", },
+   { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, sunxi_machine_spdif_dt_ids);
+
+static struct platform_driver sunxi_machine_spdif_driver = {
+   .driver = {
+   .name = "sunxi-machine-spdif",
+   .of_match_table = sunxi_machine_spdif_dt_ids,
+   },
+   .probe = sunxi_machine_spdif_audio_probe,
+};
+
+module_platform_driver(sunxi_machine_spdif_driver);
+
+MODULE_AUTHOR("Marcus Cooper ");
+MODULE_AUTHOR("Andrea Venturi, ");
+MODULE_DESCRIPTION("Allwinner sunxi S/PDIF machine driver");
+MODULE_LICENSE("GPL v2");
-- 
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 v2 2/4] dt-binding: Add sunxi S/PDIF machine driver

2015-09-30 Thread codekipper 
From: Marcus Cooper 

Add device tree bindings for the SPDIF machine driver for Allwinner SoC
devices.

Signed-off-by: Marcus Cooper 
---
 .../bindings/sound/sunxi-audio-spdif.txt   | 36 ++
 1 file changed, 36 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/sound/sunxi-audio-spdif.txt

diff --git a/Documentation/devicetree/bindings/sound/sunxi-audio-spdif.txt 
b/Documentation/devicetree/bindings/sound/sunxi-audio-spdif.txt
new file mode 100644
index 000..b9e8152
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sunxi-audio-spdif.txt
@@ -0,0 +1,36 @@
+Allwinner audio complex with S/PDIF transceiver
+
+Required properties:
+
+  - compatible : "Allwinner,sunxi-audio-spdif"
+
+  - model  : The user-visible name of this sound complex
+
+  - spdif-controller   : The phandle of the Allwinner S/PDIF controller
+
+
+Optional properties:
+
+  - spdif-out  : This is a boolean property. If present, the
+ transmitting function of S/PDIF will be enabled,
+ indicating there's a physical S/PDIF out connector
+ or jack on the board or it's connecting to some
+ other IP block, such as an HDMI encoder or
+ display-controller.
+
+  - spdif-in   : This is a boolean property. If present, the receiving
+ function of S/PDIF will be enabled, indicating there
+ is a physical S/PDIF in connector/jack on the board.
+
+* Note: At least one of these two properties should be set in the DT binding.
+
+
+Example:
+
+sound-spdif {
+   compatible = "allwinner,sunxi-audio-spdif";
+   model = "sunxi-spdif";
+   spdif-controller = <>;
+   spdif-out;
+   spdif-in;
+};
-- 
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 v2 1/4] dt-bindings: add sunxi SPDIF transceiver bindings

2015-09-30 Thread codekipper 
From: Marcus Cooper 

Add devicetree bindings for the SPDIF transceiver found on
found on Allwinners A10, A20 and A31 SoCs.

Signed-off-by: Marcus Cooper 
---
 .../devicetree/bindings/sound/sunxi,spdif.txt  | 49 ++
 1 file changed, 49 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/sunxi,spdif.txt

diff --git a/Documentation/devicetree/bindings/sound/sunxi,spdif.txt 
b/Documentation/devicetree/bindings/sound/sunxi,spdif.txt
new file mode 100644
index 000..1868722
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/sunxi,spdif.txt
@@ -0,0 +1,49 @@
+Allwinner Sony/Philips Digital Interface Format (S/PDIF) Controller
+
+The Allwinner S/PDIF audio block is a transceiver that allows the
+processor to receive and transmit digital audio via an coaxial cable or
+a fibre cable.
+
+Required properties:
+
+  - compatible : should be one of the following:
+- "allwinner,sun4i-a10-spdif": for the Allwinner A10 SoC
+- "allwinner,sun7i-a20-spdif": for the Allwinner A20 SoC
+- "allwinner,sun6i-a31-spdif": for the Allwinner A31 SoC
+
+  - reg: Offset and length of the register set for the 
device.
+
+  - interrupts : Contains the spdif interrupt.
+
+  - dmas   : Generic dma devicetree binding as described in
+ Documentation/devicetree/bindings/dma/dma.txt.
+
+  - dma-names  : Two dmas have to be defined, "tx" and "rx".
+
+  - clocks : Contains an entry for each entry in clock-names.
+
+  - clock-names: Includes the following entries:
+   "apb" clock for the spdif bus.
+   "audio"   clock from the audio pll.
+   "spdif"   clock for spdif controller.
+
+Optional:
+
+  - spdif-in   : Enable block for capturing an SPDIF signal.
+
+  - spdif-out  : Enable block for transmitting an SPDIF signal.
+
+Example:
+
+spdif: spdif@01c21000 {
+   compatible = "allwinner,sun4i-a10-spdif";
+   reg = <0x01c21000 0x40>;
+   interrupts = <13>;
+   clocks = <_gates 1>, < 0>, <_clk>;
+   clock-names = "apb", "audio", "spdif";
+   dmas = < 0 2>, < 0 2>;
+   dma-names = "rx", "tx";
+   spdif-in = "disabled";
+   spdif-out = "okay";
+   status = "okay";
+};
-- 
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] [RFC PATCH] ASOC: sunxi: sun4i_snd_txctrl_on() can be static

2015-09-30 Thread kbuild test robot 

Signed-off-by: Fengguang Wu 
---
 sun4i-spdif.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/sound/soc/sunxi/sun4i-spdif.c b/sound/soc/sunxi/sun4i-spdif.c
index 5fff6f6..cf0ed80 100644
--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -204,7 +204,7 @@ static void sun4i_spdif_configure(struct sun4i_spdif_dev 
*host)
 
 }
 
-void sun4i_snd_txctrl_on(struct snd_pcm_substream *substream,
+static void sun4i_snd_txctrl_on(struct snd_pcm_substream *substream,
struct sun4i_spdif_dev *host)
 {
if (substream->runtime->channels == 1)
@@ -228,7 +228,7 @@ void sun4i_snd_txctrl_on(struct snd_pcm_substream 
*substream,
SUN4I_SPDIF_CTL_GEN);
 }
 
-void sun4i_snd_txctrl_off(struct snd_pcm_substream *substream,
+static void sun4i_snd_txctrl_off(struct snd_pcm_substream *substream,
struct sun4i_spdif_dev *host)
 {
/* SPDIF TX DISABLE */

-- 
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 0/2] mtd: nand: sunxi: cleanup

2015-09-30 Thread Boris Brezillon 
Hi Brian,

On Wed, 30 Sep 2015 11:11:35 -0700
Brian Norris  wrote:

> On Wed, Sep 30, 2015 at 08:36:34AM +0200, Boris Brezillon wrote:
> > On Tue, 29 Sep 2015 15:21:44 -0700
> > Brian Norris  wrote:
> > 
> > > On Wed, Sep 16, 2015 at 09:46:35AM +0200, Boris Brezillon wrote:
> > > > Hello,
> > > > 
> > > > Those two patches aim at cleaning up the sunxi_nand driver by first 
> > > > adding
> > > > some consistency in the macro definitions, and then factorizing the code
> > > > duplicated code found in hw_ecc and hw_syndrome_ecc implementations.
> > > > 
> > > > Best Regards,
> > > > 
> > > > Boris
> > > 
> > > I believe this series no longer applies cleanly
> > 
> > Hm, actually it depends on fixes you have in your linux-mtd tree and
> > features in your l2-mtd tree.
> > 
> > I don't know how you usually deal with those problems (merging the
> > linux-mtd/master branch into the l2-mtd/master one, or merging
> > last linus' -rc into l2-mtd/master should work), but I'd really
> > like to have this in 4.4 :-).
> 
> linux-mtd.git is prepped for a pull request. I'll do that before the
> week ends. And I'll either merge that back into l2-mtd.git at that time,
> or just pull in v4.3-rc4.

Perfect.

> 
> > I still have the patch using the nand_check_erased_ecc_chunk() function
> > which depends on those 2 patches, and I'd like to have it in 4.4 too.
> > 
> > I know I'm asking a lot, but as explained earlier, I still have a
> > bunch of patches on top of those already posted (mainly to support
> > the hardware randomizer), and I'd like the trivial ones to be merged
> > quickly.
> 
> I'll see what I can apply after pulling together all the latest, but if
> I'm still missing things then, feel free to resend.

Apparently I have a few things to rework in patch 2, so I'll resend
it ;-).

> 
> BTW, I thought there were some things to address on the erased ECC stuff
> still. I'll re-check that series too.

AFAIR, I had a few things to fix, and we were waiting for some feedback.
I also told you I would test the series on an atmel platform (which I
haven't done yet :-/).

Best Regards,

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 v2 4/4] ASOC: sunxi: Add support for the spdif block

2015-09-30 Thread kbuild test robot 
Hi Marcus,

[auto build test results on next-20150930 -- if it's inappropriate base, please 
ignore]


coccinelle warnings: (new ones prefixed by >>)

>> sound/soc/sunxi/sun4i-spdif.c:599:3-8: No need to set .owner here. The core 
>> will do it.

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation

-- 
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 0/2] mtd: nand: sunxi: cleanup

2015-09-30 Thread Brian Norris 
On Wed, Sep 30, 2015 at 08:36:34AM +0200, Boris Brezillon wrote:
> On Tue, 29 Sep 2015 15:21:44 -0700
> Brian Norris  wrote:
> 
> > On Wed, Sep 16, 2015 at 09:46:35AM +0200, Boris Brezillon wrote:
> > > Hello,
> > > 
> > > Those two patches aim at cleaning up the sunxi_nand driver by first adding
> > > some consistency in the macro definitions, and then factorizing the code
> > > duplicated code found in hw_ecc and hw_syndrome_ecc implementations.
> > > 
> > > Best Regards,
> > > 
> > > Boris
> > 
> > I believe this series no longer applies cleanly
> 
> Hm, actually it depends on fixes you have in your linux-mtd tree and
> features in your l2-mtd tree.
> 
> I don't know how you usually deal with those problems (merging the
> linux-mtd/master branch into the l2-mtd/master one, or merging
> last linus' -rc into l2-mtd/master should work), but I'd really
> like to have this in 4.4 :-).

linux-mtd.git is prepped for a pull request. I'll do that before the
week ends. And I'll either merge that back into l2-mtd.git at that time,
or just pull in v4.3-rc4.

> I still have the patch using the nand_check_erased_ecc_chunk() function
> which depends on those 2 patches, and I'd like to have it in 4.4 too.
> 
> I know I'm asking a lot, but as explained earlier, I still have a
> bunch of patches on top of those already posted (mainly to support
> the hardware randomizer), and I'd like the trivial ones to be merged
> quickly.

I'll see what I can apply after pulling together all the latest, but if
I'm still missing things then, feel free to resend.

BTW, I thought there were some things to address on the erased ECC stuff
still. I'll re-check that series too.

Brian

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

[linux-sunxi] [PATCH] ASOC: sunxi: fix platform_no_drv_owner.cocci warnings

2015-09-30 Thread kbuild test robot 
sound/soc/sunxi/sun4i-spdif.c:599:3-8: No need to set .owner here. The core 
will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Marcus Cooper 
Signed-off-by: Fengguang Wu 
---

 sun4i-spdif.c |1 -
 1 file changed, 1 deletion(-)

--- a/sound/soc/sunxi/sun4i-spdif.c
+++ b/sound/soc/sunxi/sun4i-spdif.c
@@ -596,7 +596,6 @@ static int sun4i_spdif_remove(struct pla
 static struct platform_driver sun4i_spdif_driver = {
.driver = {
.name   = "sun4i-spdif",
-   .owner  = THIS_MODULE,
.of_match_table = of_match_ptr(sun4i_spdif_of_match),
},
.probe  = sun4i_spdif_probe,

-- 
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 v2 3/3] ARM: dts: sun6i: hummingbird: Drop AXP221 DC1SW and DC5LDO supplies

2015-09-30 Thread Chen-Yu Tsai 
"dcdc1-supply" and "dcdc5-supply" have been dropped, as they are
internally connected and should not be represented in the device
tree.

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

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

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

[linux-sunxi] [PATCH v2 2/3] regulator: axp20x: set supply names for AXP22X DC1SW/DC5LDO internally

2015-09-30 Thread Chen-Yu Tsai 
The DC1SW and DC5LDO regulators in the AXP22X are internally chained
to DCDC1 and DCDC5, hence the names. The original bindings used the
parent regulator names for the supply regulator property.

Since they are internally connected, the relationship should not be
represented in the device tree, but handled internally by the driver.

This patch has the driver remember the regulator names for the parent
DCDC1/DCDC5, and use them as supply names for DC1SW/DC5LDO.

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

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index a9567af7cec0..35de22fdb7a0 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(5)),
/* secondary switchable output of DCDC1 */
-   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", "dcdc1", 1600, 3400, 100,
+   AXP_DESC_SW(AXP22X, DC1SW, "dc1sw", NULL, 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", NULL, 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)),
@@ -350,6 +350,8 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
};
int ret, i, nregulators;
u32 workmode;
+   const char *axp22x_dc1_name = axp22x_regulators[AXP22X_DCDC1].name;
+   const char *axp22x_dc5_name = axp22x_regulators[AXP22X_DCDC5].name;
 
switch (axp20x->variant) {
case AXP202_ID:
@@ -371,8 +373,37 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
axp20x_regulator_parse_dt(pdev);
 
for (i = 0; i < nregulators; i++) {
-   rdev = devm_regulator_register(>dev, [i],
-  );
+   const struct regulator_desc *desc = [i];
+   struct regulator_desc *new_desc;
+
+   /*
+* Regulators DC1SW and DC5LDO are connected internally,
+* so we have to handle their supply names separately.
+*
+* We always register the regulators in proper sequence,
+* so the supply names are correctly read. See the last
+* part of this loop to see where we save the DT defined
+* name.
+*/
+   if (regulators == axp22x_regulators) {
+   if (i == AXP22X_DC1SW) {
+   new_desc = devm_kzalloc(>dev,
+   sizeof(*desc),
+   GFP_KERNEL);
+   *new_desc = regulators[i];
+   new_desc->supply_name = axp22x_dc1_name;
+   desc = new_desc;
+   } else if (i == AXP22X_DC5LDO) {
+   new_desc = devm_kzalloc(>dev,
+   sizeof(*desc),
+   GFP_KERNEL);
+   *new_desc = regulators[i];
+   new_desc->supply_name = axp22x_dc5_name;
+   desc = new_desc;
+   }
+   }
+
+   rdev = devm_regulator_register(>dev, desc, );
if (IS_ERR(rdev)) {
dev_err(>dev, "Failed to register %s\n",
regulators[i].name);
@@ -388,6 +419,21 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
dev_err(>dev, "Failed to set workmode on 
%s\n",
rdev->desc->name);
}
+
+   /*
+* Save AXP22X DCDC1 / DCDC5 regulator names for later.
+*/
+   if (regulators == axp22x_regulators) {
+   /* Can we use rdev->constraints->name instead? */
+   if (i == AXP22X_DCDC1)
+   of_property_read_string(rdev->dev.of_node,
+   "regulator-name",
+   _dc1_name);
+   else if (i == AXP22X_DCDC5)
+

[linux-sunxi] [PATCH v2 1/3] mfd: axp20x: Drop AXP221 DC1SW and DC5LDO regulator supplies from bindings

2015-09-30 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 {
...
};
};

Since they are internally connected within the PMIC, their relationships
should not be visible in the device tree.

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..a474359dd206 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 :   : DCDC1 secondary output
+DC5LDO : LDO   :   : input from DCDC5
 ALDO1  : LDO   : aldoin-supply : shared supply
 ALDO2  : LDO   : aldoin-supply : shared supply
 ALDO3  : LDO   : aldoin-supply : shared supply
-- 
2.5.3

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

[linux-sunxi] [PATCH v2 0/3] regulator: axp20x: Drop AXP221 DC1SW/DC5LDO supplies from bindings

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

This is v2 of "regulators: axp20x: Rename AXP221 DC1SW and DC5LDO supply
names". v2 removes the regulator supply properties for AXP221 DC1SW
and DC5LDO, instead of renaming them. These 2 regulators are secondary
outputs for DCDC1 and DCDC5 buck regulators, respectively, so they are
connected to them internally. This relationship should not be represented
in the device tree.


Patch 1 drops the AXP22X DC1SW/DC5LDO supply properties from 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 this for 4.4?

Thanks.


Regards,
ChenYu


Chen-Yu Tsai (3):
  mfd: axp20x: Drop AXP221 DC1SW and DC5LDO regulator supplies from
bindings
  regulator: axp20x: set supply names for AXP22X DC1SW/DC5LDO internally
  ARM: dts: sun6i: hummingbird: Drop AXP221 DC1SW and DC5LDO supplies

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

-- 
2.5.3

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

[linux-sunxi] Re: [PATCH 0/2] mtd: nand: sunxi: cleanup

2015-09-30 Thread Boris Brezillon 
Hi Brian,

On Tue, 29 Sep 2015 15:21:44 -0700
Brian Norris  wrote:

> On Wed, Sep 16, 2015 at 09:46:35AM +0200, Boris Brezillon wrote:
> > Hello,
> > 
> > Those two patches aim at cleaning up the sunxi_nand driver by first adding
> > some consistency in the macro definitions, and then factorizing the code
> > duplicated code found in hw_ecc and hw_syndrome_ecc implementations.
> > 
> > Best Regards,
> > 
> > Boris
> 
> I believe this series no longer applies cleanly

Hm, actually it depends on fixes you have in your linux-mtd tree and
features in your l2-mtd tree.

I don't know how you usually deal with those problems (merging the
linux-mtd/master branch into the l2-mtd/master one, or merging
last linus' -rc into l2-mtd/master should work), but I'd really
like to have this in 4.4 :-).
I still have the patch using the nand_check_erased_ecc_chunk() function
which depends on those 2 patches, and I'd like to have it in 4.4 too.

I know I'm asking a lot, but as explained earlier, I still have a
bunch of patches on top of those already posted (mainly to support
the hardware randomizer), and I'd like the trivial ones to be merged
quickly.

Best Regards,

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.

Re: [fedora-arm] [linux-sunxi] cpufreq scaling broken on cubietruck

2015-09-30 Thread Clive Messer 
On Wed, 2015-09-30 at 04:29 +0100, Peter Robinson wrote:

> > This is already fixed by this patch:
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
> > mit/drivers/regulator/axp20x
> > -regulator.c?id=d4ea7d86457a8d0ea40ce77bdeda1fc966cc35ec
> 
> I've pulled this patch into the F-23/4.2.x kernel, it'll be in the
> 4.2.2 build, it's already in rawhide.

Thanks, Peter.

One other thing to think about. Although the cpufreq-dt module will
autoload from dt ref, it needs to be in the initramfs image created by
dracut. This doesn't happen automatically. Currently have created a
/etc/dracut.conf.d/sunxi.conf with...


##
## Need to make sure these are in the initramfs image and they
##  will be automatically loaded via DT reference
##
add_drivers+="cpufreq-dt sunxi-wdt"


Regards

Clive
-- 
Clive Messer 

-- 
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: [fedora-arm] [linux-sunxi] cpufreq scaling broken on cubietruck

2015-09-30 Thread Peter Robinson 
>> > This is already fixed by this patch:
>> >
>> > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/com
>> > mit/drivers/regulator/axp20x
>> > -regulator.c?id=d4ea7d86457a8d0ea40ce77bdeda1fc966cc35ec
>>
>> I've pulled this patch into the F-23/4.2.x kernel, it'll be in the
>> 4.2.2 build, it's already in rawhide.
>
> Thanks, Peter.
>
> One other thing to think about. Although the cpufreq-dt module will
> autoload from dt ref, it needs to be in the initramfs image created by
> dracut. This doesn't happen automatically. Currently have created a
> /etc/dracut.conf.d/sunxi.conf with...

Weird, it appears to load and work post initrd with the BeagleBone.

In /sys/devices/system/cpu/cpu0/cpufreq I get all the bits I would
expect with cur/max/mon freqs etc.

I'll have a look when I get a spare moment on a A20 device.

Peter

-- 
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] DCDC2 (VDD-SYS) voltage for A23/A33?

2015-09-30 Thread Hans de Goede 

Hi,

On 30-09-15 03:52, wens Tsai wrote:

Hi,

I've been looking into AXP223 usage as part of the RSB patches.
I found that the recommended voltage for VDD-SYS is 1.1V, but
we default to 1.2V in U-boot. Among the fex files, some use
1.1V and some use 1.2V.


Right, I happened to be looking the same thing recently.

I've recently bought a bunch of 2nd hand q8 tablets, and I've
pushed all the fex files I got from them to sunxi-boards yesterday.

Looking at A23 devices only the ippo_q8h_v1.0.fex and
ippo_q8h_v1.2.fex files set VDD-SYS to 1.2 volt, the other
7 use the recommended 1.1V value. Also note that the gt90h-v4
tablet which I have does not work with a VDD-SYS of 1.2 volt,
it only works with a VDD-SYS of 1.1 volt.

I've tested my ippo_q8h_v1.2 and it works fine with a VDD-SYS
of 1.1 volt.

Looking at A33 devices there are 2 outliers the TZX-723Qa4 and
astar_mid756.fex both set VDD-SYS to 1.26 V, rather then to 1.1 V.
The other 6 all use 1.1V so I believe that 1.1V indeed is a better
default.


Perhaps we could update the defconfigs with the values from
the fex files.


I think that we should switch the default to 1.1V and then if we see
any issues set it to 1.2V in individual defconfig-s.


One thing that we have to be careful of is matching the settings
in U-boot and the kernel, or alternatively, not use a fixed value
but the recommended range for the VDD-SYS regulator. Accidentally
dropping the voltage on VDD-SYS results in some logic errors,
which likely lead to a crash.


I think it is best to set a range in the dts file and the kernel
just inherit whatever u-boot has set up, this way we don't end
up changing vdd-sys half-way through boot, and we only have one
place where to tweak it if necessary.

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] Autoload sun4i-dma module from DT

2015-09-30 Thread Clive Messer 
Can we have the sun4i-dma module auto-loading from the DT reference, please?


-- 
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: Clive Messer 
Subject: Autoload sun4i-dma module

--- a/drivers/dma/sun4i-dma.c	2015-09-30 11:31:13.0 +0100
+++ b/drivers/dma/sun4i-dma.c	2015-09-30 11:34:57.759414791 +0100
@@ -1271,6 +1271,7 @@
 	{ .compatible = "allwinner,sun4i-a10-dma" },
 	{ /* sentinel */ },
 };
+MODULE_DEVICE_TABLE(of, sun4i_dma_match);
 
 static struct platform_driver sun4i_dma_driver = {
 	.probe	= sun4i_dma_probe,

[linux-sunxi] [PATCH v2 6/7] mtd: nand: sunxi: replace the NFC_BUF_TO_USER_DATA() macro by an inline function

2015-09-30 Thread Boris Brezillon 
sunxi_nfc_user_data_to_buf() is exposed as an inline function, replace the
NFC_BUF_TO_USER_DATA() macro by an inline function to be consistent.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index a9061a0..a76eb51 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -156,10 +156,6 @@
 #define NFC_ECC_PAT_FOUND(x)   BIT(x + 16)
 #define NFC_ECC_ERR_CNT(b, x)  (((x) >> ((b) * 8)) & 0xff)
 
-/* NFC_USER_DATA helper macros */
-#define NFC_BUF_TO_USER_DATA(buf)  ((buf)[0] | ((buf)[1] << 8) | \
-   ((buf)[2] << 16) | ((buf)[3] << 24))
-
 #define NFC_DEFAULT_TIMEOUT_MS 1000
 
 #define NFC_SRAM_SIZE  1024
@@ -657,6 +653,11 @@ static void sunxi_nfc_hw_ecc_read_extra_oob(struct 
mtd_info *mtd,
*cur_off = mtd->oobsize + mtd->writesize;
 }
 
+static inline u32 sunxi_nfc_buf_to_user_data(const u8 *buf)
+{
+   return buf[0] | (buf[1] << 8) | (buf[2] << 16) | (buf[3] << 24);
+}
+
 static int sunxi_nfc_hw_ecc_write_chunk(struct mtd_info *mtd,
const u8 *data, int data_off,
const u8 *oob, int oob_off,
@@ -673,7 +674,8 @@ static int sunxi_nfc_hw_ecc_write_chunk(struct mtd_info 
*mtd,
sunxi_nfc_write_buf(mtd, data, ecc->size);
 
/* Fill OOB data in */
-   writel(NFC_BUF_TO_USER_DATA(oob), nfc->regs + NFC_REG_USER_DATA(0));
+   writel(sunxi_nfc_buf_to_user_data(oob),
+  nfc->regs + NFC_REG_USER_DATA(0));
 
if (data_off + ecc->bytes != oob_off)
nand->cmdfunc(mtd, NAND_CMD_RNDIN, oob_off, -1);
-- 
2.1.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] [PATCH v2 0/7] mtd: nand: sunxi: cleanup and improvements

2015-09-30 Thread Boris Brezillon 
Hello,

This patch series aims at cleaning up the sunxi_nand driver by factorizing
the duplicated code found in hw_ecc and hw_syndrome_ecc implementations.

It also adds support for OOB bytes protection (only on a limited amount of
OOB bytes), and add code to correctly handle the 'bitflips in erased pages'
case.

Best Regards,

Boris

Changes since v1:
- drop the first patch (already applied)
- split the second patch to ease the review
- add the 'fix bitflips in erased pages' patch

Boris Brezillon (7):
  mtd: nand: sunxi: create sunxi_nfc_hw_ecc_enable()/disable() functions
  mtd: nand: sunxi: introduce sunxi_nfc_hw_ecc_read/write_chunk()
  mtd: nand: sunxi: make use of sunxi_nfc_hw_ecc_read/write_chunk()
  mtd: nand: sunxi: factorize extra OOB bytes handling
  mtd: nand: sunxi: retrieve corrected OOB bytes
  mtd: nand: sunxi: replace the NFC_BUF_TO_USER_DATA() macro by an
inline function
  mtd: nand: sunxi: fix bitflips in erased pages

 drivers/mtd/nand/sunxi_nand.c | 416 ++
 1 file changed, 220 insertions(+), 196 deletions(-)

-- 
2.1.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] [PATCH v2 2/7] mtd: nand: sunxi: introduce sunxi_nfc_hw_ecc_read/write_chunk()

2015-09-30 Thread Boris Brezillon 
The logic behind normal and syndrome ECC handling is pretty much the same,
the only difference is the ECC bytes placement.
Create two functions to read/write ECC chunks. Those functions will later
be used by the sunxi_nfc_hw_ecc_read/write_page() and
sunxi_nfc_hw_syndrome_ecc_read/write_page() functions.

Signed-off-by: Boris Brezillon 
---
Brian,

Introducing those two functions without making use of them is the only
solution I found to make the patch more readable, but this also means
that this commit generates compilation warnings (unused static functions)
which are only fixed by the next commit.

Let me know if you see a more elegant solution.

Best Regards,

Boris
---
 drivers/mtd/nand/sunxi_nand.c | 92 +++
 1 file changed, 92 insertions(+)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 471fc2b..9d8cf06 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -567,6 +567,98 @@ static void sunxi_nfc_hw_ecc_disable(struct mtd_info *mtd)
   nfc->regs + NFC_REG_ECC_CTL);
 }
 
+static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
+  u8 *data, int data_off,
+  u8 *oob, int oob_off,
+  int *cur_off,
+  unsigned int *max_bitflips)
+{
+   struct nand_chip *nand = mtd->priv;
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct nand_ecc_ctrl *ecc = >ecc;
+   u32 status;
+   int ret;
+
+   if (*cur_off != data_off)
+   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, data_off, -1);
+
+   sunxi_nfc_read_buf(mtd, data, ecc->size);
+
+   if (data_off + ecc->bytes != oob_off)
+   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
+
+   ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
+   if (ret)
+   return ret;
+
+   writel(NFC_DATA_TRANS | NFC_DATA_SWAP_METHOD | NFC_ECC_OP,
+  nfc->regs + NFC_REG_CMD);
+
+   ret = sunxi_nfc_wait_int(nfc, NFC_CMD_INT_FLAG, 0);
+   if (ret)
+   return ret;
+
+   status = readl(nfc->regs + NFC_REG_ECC_ST);
+   ret = NFC_ECC_ERR_CNT(0, readl(nfc->regs + NFC_REG_ECC_ERR_CNT(0)));
+
+   memcpy_fromio(data, nfc->regs + NFC_RAM0_BASE, ecc->size);
+
+   nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
+   sunxi_nfc_read_buf(mtd, oob, ecc->bytes + 4);
+
+   if (status & NFC_ECC_ERR(0))
+   ret = -EIO;
+
+   if (ret < 0) {
+   mtd->ecc_stats.failed++;
+   } else {
+   mtd->ecc_stats.corrected += ret;
+   *max_bitflips = max_t(unsigned int, *max_bitflips, ret);
+   }
+
+   *cur_off = oob_off + ecc->bytes + 4;
+
+   return 0;
+}
+
+static int sunxi_nfc_hw_ecc_write_chunk(struct mtd_info *mtd,
+   const u8 *data, int data_off,
+   const u8 *oob, int oob_off,
+   int *cur_off)
+{
+   struct nand_chip *nand = mtd->priv;
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct nand_ecc_ctrl *ecc = >ecc;
+   int ret;
+
+   if (data_off != *cur_off)
+   nand->cmdfunc(mtd, NAND_CMD_RNDIN, data_off, -1);
+
+   sunxi_nfc_write_buf(mtd, data, ecc->size);
+
+   /* Fill OOB data in */
+   writel(NFC_BUF_TO_USER_DATA(oob), nfc->regs + NFC_REG_USER_DATA(0));
+
+   if (data_off + ecc->bytes != oob_off)
+   nand->cmdfunc(mtd, NAND_CMD_RNDIN, oob_off, -1);
+
+   ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
+   if (ret)
+   return ret;
+
+   writel(NFC_DATA_TRANS | NFC_DATA_SWAP_METHOD |
+  NFC_ACCESS_DIR | NFC_ECC_OP,
+  nfc->regs + NFC_REG_CMD);
+
+   ret = sunxi_nfc_wait_int(nfc, NFC_CMD_INT_FLAG, 0);
+   if (ret)
+   return ret;
+
+   *cur_off = oob_off + ecc->bytes + 4;
+
+   return 0;
+}
+
 static int sunxi_nfc_hw_ecc_read_page(struct mtd_info *mtd,
  struct nand_chip *chip, uint8_t *buf,
  int oob_required, int page)
-- 
2.1.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] [PATCH v2 5/7] mtd: nand: sunxi: retrieve corrected OOB bytes

2015-09-30 Thread Boris Brezillon 
The ECC engine is protecting a few OOB bytes. Retrieve them from the
USER_DATA register instead of reading them in raw mode (ie without the ECC
protection).

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 45b74fc..a9061a0 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -567,6 +567,14 @@ static void sunxi_nfc_hw_ecc_disable(struct mtd_info *mtd)
   nfc->regs + NFC_REG_ECC_CTL);
 }
 
+static inline void sunxi_nfc_user_data_to_buf(u32 user_data, u8 *buf)
+{
+   buf[0] = user_data;
+   buf[1] = user_data >> 8;
+   buf[2] = user_data >> 16;
+   buf[3] = user_data >> 24;
+}
+
 static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
   u8 *data, int data_off,
   u8 *oob, int oob_off,
@@ -606,8 +614,16 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info 
*mtd,
nand->cmdfunc(mtd, NAND_CMD_RNDOUT, oob_off, -1);
sunxi_nfc_read_buf(mtd, oob, ecc->bytes + 4);
 
-   if (status & NFC_ECC_ERR(0))
+   if (status & NFC_ECC_ERR(0)) {
ret = -EIO;
+   } else {
+   /*
+* The engine protects 4 bytes of OOB data per chunk.
+* Retrieve the corrected OOB bytes.
+*/
+   sunxi_nfc_user_data_to_buf(readl(nfc->regs + 
NFC_REG_USER_DATA(0)),
+  oob);
+   }
 
if (ret < 0) {
mtd->ecc_stats.failed++;
-- 
2.1.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] [PATCH v2 7/7] mtd: nand: sunxi: fix bitflips in erased pages

2015-09-30 Thread Boris Brezillon 
Use the nand_check_erased_ecc_chunk() function to test if the ECC error
was triggered by an erased page containing a few bitflips.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index a76eb51..92245a3 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -611,7 +611,9 @@ static int sunxi_nfc_hw_ecc_read_chunk(struct mtd_info *mtd,
sunxi_nfc_read_buf(mtd, oob, ecc->bytes + 4);
 
if (status & NFC_ECC_ERR(0)) {
-   ret = -EIO;
+   ret = nand_check_erased_ecc_chunk(data, ecc->size,
+ oob, ecc->bytes + 4,
+ NULL, 0, ecc->strength);
} else {
/*
 * The engine protects 4 bytes of OOB data per chunk.
-- 
2.1.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] [PATCH v2 3/7] mtd: nand: sunxi: make use of sunxi_nfc_hw_ecc_read/write_chunk()

2015-09-30 Thread Boris Brezillon 
The sunxi_nfc_hw_ecc_read/write_chunk() functions have been created to
factorize the code in the normal and syndrome ECC implementation.
Make use of them where appropriate.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand.c | 168 ++
 1 file changed, 40 insertions(+), 128 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index 9d8cf06..176d0f0 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -663,61 +663,25 @@ static int sunxi_nfc_hw_ecc_read_page(struct mtd_info 
*mtd,
  struct nand_chip *chip, uint8_t *buf,
  int oob_required, int page)
 {
-   struct sunxi_nfc *nfc = to_sunxi_nfc(chip->controller);
struct nand_ecc_ctrl *ecc = >ecc;
-   struct nand_ecclayout *layout = ecc->layout;
unsigned int max_bitflips = 0;
+   int ret, i, cur_off = 0;
int offset;
-   int ret;
-   u32 tmp;
-   int i;
int cnt;
 
sunxi_nfc_hw_ecc_enable(mtd);
 
for (i = 0; i < ecc->steps; i++) {
-   if (i)
-   chip->cmdfunc(mtd, NAND_CMD_RNDOUT, i * ecc->size, -1);
-
-   offset = mtd->writesize + layout->eccpos[i * ecc->bytes] - 4;
-
-   chip->read_buf(mtd, NULL, ecc->size);
-
-   chip->cmdfunc(mtd, NAND_CMD_RNDOUT, offset, -1);
-
-   ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
+   int data_off = i * ecc->size;
+   int oob_off = i * (ecc->bytes + 4);
+   u8 *data = buf + data_off;
+   u8 *oob = chip->oob_poi + oob_off;
+
+   ret = sunxi_nfc_hw_ecc_read_chunk(mtd, data, data_off, oob,
+ oob_off + mtd->writesize,
+ _off, _bitflips);
if (ret)
return ret;
-
-   tmp = NFC_DATA_TRANS | NFC_DATA_SWAP_METHOD | NFC_ECC_OP;
-   writel(tmp, nfc->regs + NFC_REG_CMD);
-
-   ret = sunxi_nfc_wait_int(nfc, NFC_CMD_INT_FLAG, 0);
-   if (ret)
-   return ret;
-
-   memcpy_fromio(buf + (i * ecc->size),
- nfc->regs + NFC_RAM0_BASE, ecc->size);
-
-   if (readl(nfc->regs + NFC_REG_ECC_ST) & NFC_ECC_ERR(0)) {
-   mtd->ecc_stats.failed++;
-   } else {
-   tmp = readl(nfc->regs + NFC_REG_ECC_ERR_CNT(0));
-   mtd->ecc_stats.corrected += NFC_ECC_ERR_CNT(0, tmp);
-   max_bitflips = max_t(unsigned int, max_bitflips, tmp);
-   }
-
-   if (oob_required) {
-   chip->cmdfunc(mtd, NAND_CMD_RNDOUT, offset, -1);
-
-   ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
-   if (ret)
-   return ret;
-
-   offset -= mtd->writesize;
-   chip->read_buf(mtd, chip->oob_poi + offset,
- ecc->bytes + 4);
-   }
}
 
if (oob_required) {
@@ -740,40 +704,22 @@ static int sunxi_nfc_hw_ecc_write_page(struct mtd_info 
*mtd,
   struct nand_chip *chip,
   const uint8_t *buf, int oob_required)
 {
-   struct sunxi_nfc *nfc = to_sunxi_nfc(chip->controller);
struct nand_ecc_ctrl *ecc = >ecc;
-   struct nand_ecclayout *layout = ecc->layout;
+   int ret, i, cur_off = 0;
int offset;
-   int ret;
-   u32 tmp;
-   int i;
int cnt;
 
sunxi_nfc_hw_ecc_enable(mtd);
 
for (i = 0; i < ecc->steps; i++) {
-   if (i)
-   chip->cmdfunc(mtd, NAND_CMD_RNDIN, i * ecc->size, -1);
-
-   chip->write_buf(mtd, buf + (i * ecc->size), ecc->size);
-
-   offset = layout->eccpos[i * ecc->bytes] - 4 + mtd->writesize;
-
-   /* Fill OOB data in */
-   writel(NFC_BUF_TO_USER_DATA(chip->oob_poi +
-   layout->oobfree[i].offset),
-  nfc->regs + NFC_REG_USER_DATA(0));
-
-   chip->cmdfunc(mtd, NAND_CMD_RNDIN, offset, -1);
-
-   ret = sunxi_nfc_wait_cmd_fifo_empty(nfc);
-   if (ret)
-   return ret;
-
-   tmp = NFC_DATA_TRANS | NFC_DATA_SWAP_METHOD | NFC_ACCESS_DIR |
- NFC_ECC_OP;
-   writel(tmp, nfc->regs + NFC_REG_CMD);
-   ret = sunxi_nfc_wait_int(nfc, NFC_CMD_INT_FLAG, 0);
+   int data_off = i * ecc->size;
+   int oob_off = i * (ecc->bytes + 4);
+   const u8 *data = buf + data_off;
+   const u8 *oob = chip->oob_poi +

[linux-sunxi] [PATCH v2 1/7] mtd: nand: sunxi: create sunxi_nfc_hw_ecc_enable()/disable() functions

2015-09-30 Thread Boris Brezillon 
The code used to enable/disable the hardware ECC engine is repeated in a
lot of places. Create two functions to avoid code duplication.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/sunxi_nand.c | 70 ---
 1 file changed, 32 insertions(+), 38 deletions(-)

diff --git a/drivers/mtd/nand/sunxi_nand.c b/drivers/mtd/nand/sunxi_nand.c
index dc44435..471fc2b 100644
--- a/drivers/mtd/nand/sunxi_nand.c
+++ b/drivers/mtd/nand/sunxi_nand.c
@@ -543,6 +543,30 @@ static void sunxi_nfc_cmd_ctrl(struct mtd_info *mtd, int 
dat,
sunxi_nfc_wait_int(nfc, NFC_CMD_INT_FLAG, 0);
 }
 
+static void sunxi_nfc_hw_ecc_enable(struct mtd_info *mtd)
+{
+   struct nand_chip *nand = mtd->priv;
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+   struct sunxi_nand_hw_ecc *data = nand->ecc.priv;
+   u32 ecc_ctl;
+
+   ecc_ctl = readl(nfc->regs + NFC_REG_ECC_CTL);
+   ecc_ctl &= ~(NFC_ECC_MODE_MSK | NFC_ECC_PIPELINE |
+NFC_ECC_BLOCK_SIZE_MSK);
+   ecc_ctl |= NFC_ECC_EN | NFC_ECC_MODE(data->mode) | NFC_ECC_EXCEPTION;
+
+   writel(ecc_ctl, nfc->regs + NFC_REG_ECC_CTL);
+}
+
+static void sunxi_nfc_hw_ecc_disable(struct mtd_info *mtd)
+{
+   struct nand_chip *nand = mtd->priv;
+   struct sunxi_nfc *nfc = to_sunxi_nfc(nand->controller);
+
+   writel(readl(nfc->regs + NFC_REG_ECC_CTL) & ~NFC_ECC_EN,
+  nfc->regs + NFC_REG_ECC_CTL);
+}
+
 static int sunxi_nfc_hw_ecc_read_page(struct mtd_info *mtd,
  struct nand_chip *chip, uint8_t *buf,
  int oob_required, int page)
@@ -550,7 +574,6 @@ static int sunxi_nfc_hw_ecc_read_page(struct mtd_info *mtd,
struct sunxi_nfc *nfc = to_sunxi_nfc(chip->controller);
struct nand_ecc_ctrl *ecc = >ecc;
struct nand_ecclayout *layout = ecc->layout;
-   struct sunxi_nand_hw_ecc *data = ecc->priv;
unsigned int max_bitflips = 0;
int offset;
int ret;
@@ -558,11 +581,7 @@ static int sunxi_nfc_hw_ecc_read_page(struct mtd_info *mtd,
int i;
int cnt;
 
-   tmp = readl(nfc->regs + NFC_REG_ECC_CTL);
-   tmp &= ~(NFC_ECC_MODE_MSK | NFC_ECC_PIPELINE | NFC_ECC_BLOCK_SIZE_MSK);
-   tmp |= NFC_ECC_EN | NFC_ECC_MODE(data->mode) | NFC_ECC_EXCEPTION;
-
-   writel(tmp, nfc->regs + NFC_REG_ECC_CTL);
+   sunxi_nfc_hw_ecc_enable(mtd);
 
for (i = 0; i < ecc->steps; i++) {
if (i)
@@ -620,10 +639,7 @@ static int sunxi_nfc_hw_ecc_read_page(struct mtd_info *mtd,
}
}
 
-   tmp = readl(nfc->regs + NFC_REG_ECC_CTL);
-   tmp &= ~NFC_ECC_EN;
-
-   writel(tmp, nfc->regs + NFC_REG_ECC_CTL);
+   sunxi_nfc_hw_ecc_disable(mtd);
 
return max_bitflips;
 }
@@ -635,18 +651,13 @@ static int sunxi_nfc_hw_ecc_write_page(struct mtd_info 
*mtd,
struct sunxi_nfc *nfc = to_sunxi_nfc(chip->controller);
struct nand_ecc_ctrl *ecc = >ecc;
struct nand_ecclayout *layout = ecc->layout;
-   struct sunxi_nand_hw_ecc *data = ecc->priv;
int offset;
int ret;
u32 tmp;
int i;
int cnt;
 
-   tmp = readl(nfc->regs + NFC_REG_ECC_CTL);
-   tmp &= ~(NFC_ECC_MODE_MSK | NFC_ECC_PIPELINE | NFC_ECC_BLOCK_SIZE_MSK);
-   tmp |= NFC_ECC_EN | NFC_ECC_MODE(data->mode) | NFC_ECC_EXCEPTION;
-
-   writel(tmp, nfc->regs + NFC_REG_ECC_CTL);
+   sunxi_nfc_hw_ecc_enable(mtd);
 
for (i = 0; i < ecc->steps; i++) {
if (i)
@@ -686,10 +697,7 @@ static int sunxi_nfc_hw_ecc_write_page(struct mtd_info 
*mtd,
}
}
 
-   tmp = readl(nfc->regs + NFC_REG_ECC_CTL);
-   tmp &= ~NFC_ECC_EN;
-
-   writel(tmp, nfc->regs + NFC_REG_ECC_CTL);
+   sunxi_nfc_hw_ecc_disable(mtd);
 
return 0;
 }
@@ -701,7 +709,6 @@ static int sunxi_nfc_hw_syndrome_ecc_read_page(struct 
mtd_info *mtd,
 {
struct sunxi_nfc *nfc = to_sunxi_nfc(chip->controller);
struct nand_ecc_ctrl *ecc = >ecc;
-   struct sunxi_nand_hw_ecc *data = ecc->priv;
unsigned int max_bitflips = 0;
uint8_t *oob = chip->oob_poi;
int offset = 0;
@@ -710,11 +717,7 @@ static int sunxi_nfc_hw_syndrome_ecc_read_page(struct 
mtd_info *mtd,
u32 tmp;
int i;
 
-   tmp = readl(nfc->regs + NFC_REG_ECC_CTL);
-   tmp &= ~(NFC_ECC_MODE_MSK | NFC_ECC_PIPELINE | NFC_ECC_BLOCK_SIZE_MSK);
-   tmp |= NFC_ECC_EN | NFC_ECC_MODE(data->mode) | NFC_ECC_EXCEPTION;
-
-   writel(tmp, nfc->regs + NFC_REG_ECC_CTL);
+   sunxi_nfc_hw_ecc_enable(mtd);
 
for (i = 0; i < ecc->steps; i++) {
chip->read_buf(mtd, NULL, ecc->size);
@@ -755,8 +758,7 @@ static int sunxi_nfc_hw_syndrome_ecc_read_page(struct 
mtd_info *mtd,
}
}
 
-   writel(readl(nfc->regs + NFC_REG_ECC_CTL) & ~NFC_ECC_EN,
-  nfc->regs +