[linux-sunxi] [PATCH V2 1/2] sunxi: A20-Olimex-SOM-EVB defconfig: enable mmc3

[Karsten Merker]

The Olimex A20-SOM-EVB is an evaluation board for the Olimex
A20-SOM system-on-module. The baseboard provides a full-size SD
socket (connected to mmc3) in addition to the micro-SD socket on
the SOM itself (which is connected to mmc0).

Enable the mmc3 controller in the board defconfig.

Signed-off-by: Karsten Merker 
---
 configs/A20-Olimex-SOM-EVB_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/A20-Olimex-SOM-EVB_defconfig 
b/configs/A20-Olimex-SOM-EVB_defconfig
index 5166c06..34b3f36 100644
--- a/configs/A20-Olimex-SOM-EVB_defconfig
+++ b/configs/A20-Olimex-SOM-EVB_defconfig
@@ -3,6 +3,9 @@ CONFIG_ARCH_SUNXI=y
 CONFIG_MACH_SUN7I=y
 CONFIG_DRAM_CLK=480
 CONFIG_MMC0_CD_PIN="PH1"
+CONFIG_MMC3_CD_PIN="PH0"
+CONFIG_MMC3_PINS="PH"
+CONFIG_MMC_SUNXI_SLOT_EXTRA=3
 CONFIG_USB0_VBUS_PIN="PB9"
 CONFIG_USB0_VBUS_DET="PH5"
 CONFIG_DEFAULT_DEVICE_TREE="sun7i-a20-olimex-som-evb"
-- 
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/2] sunxi: support for a second SD card socket

[Karsten Merker]

Hello,

this patchset enables the full-size SD card socket on the
A20-Olimex-SOM-EVB baseboard in u-boot and adds support for
including this kind of secondary socket into the boot environment
provided by config_distro_bootcmd.h on sunxi-based systems.

The latter is particularly useful on the A20-Olimex-SOM-EVB as
changing the card in the primary micro-SD socket is kind of
fiddly when the SOM is plugged into the baseboard.

Changes since V1:
I had botched the patch generation for V1 so that the posted
patch was incomplete. This is now the complete patch.

Regards,
Karsten

Karsten Merker (2):
  sunxi: A20-Olimex-SOM-EVB defconfig: enable mmc3
  sunxi: Enable a second mmc socket as boot target in the environment

 configs/A20-Olimex-SOM-EVB_defconfig | 3 +++
 include/configs/sunxi-common.h   | 7 +++
 2 files changed, 10 insertions(+)

-- 
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.

Re: [linux-sunxi] Re: [PATCH v6] sun4i-codec: Add FM, Line and Mic inputs

[Danny Milosavljevic]

Hi Maxime,

On Wed, 16 Dec 2015 11:47:36 +0100
Maxime Ripard  wrote:

> > Because SUN4I_CODEC_AC_MIC_PHONE_CAL is sun7i-specific.
> 
> Yet, you're using it in both cases (A10 vs A20).

Yes. I'm trying to keep complexity and duplication down.
I figured it wouldn't be bad to have unused registers in the regmap.

(Technially .max_register = MAX(max_register_a10, max_register_a20) would be 
 better. Should we do that?)

If it's bad in this case, we have to split it up, but frankly the 
*codec_probe() 
function is much too long now and this would make it even longer.

Also, it was that way before, so I'm mostly using it in both cases because 
previously it was also used in both cases (with the too-large max-register), 
apparently without problems. 

Should I duplicate and adapt the structure?

> You can also have the defines on top, and everything just works :)

The idea is to make the compiler complain when I try to use a sun7i define in a 
generic sun4i function (or struct, in this case) - because that would probably 
be causing problems at runtime, too. Better to catch problems earlier.
So I kept the sun7i-specific things closely together and as much to the bottom 
of the file as possible - as a poor-mans modularity. 
If I kept the sun7i defines at the top I could use them anywhere with impunity 
- 
also in the A10 case - and it would not complain.

But it's mostly to make the life of the developer easier, so feel free to 
choose 
otherwise. (not sarcasm)

> > Or is it better to rename it to "SUN7I_CODEC_AC_DAC_CAL" rather than delete?
> 
> You can rename it if you want, but it's not like it's of the highest
> importance :)

The only somewhat important part of the name is the "7". 
If you use a "7"-register on an A10, it's not going to work at runtime, or 
worse: 
do something else that wasn't intended. Right now it has a "4" although it isn't
an A10 register. This separation should be visible somewhere in the source 
code, 
or problems are going to slip through later.

I agree it's not at all important right now because the register is unused 
by us :P
(But it's actually an interesting register, it contains DAC bias calibration 
data. Cool that that can be modified)

> > Note: the newest original ASoC sun4i-codec has a variable
> >   "struct sun4i_codec *scodec;"
> > as well in the same function (which is a different thing).
> 
> I don't know what you're refering to with "newest" and "original".

Oops, sorry, by "newest" I meant "I checked the tree online right before I 
wrote 
the mail".
By "original" I meant "not of my patch".

> But two different variables with two different names doesn't seem so
> bad, does it?

For the computer? No.

Two different variables with almost the same name for humans? Welll. 

But it's fine, just wanted to point it out because you can't see it in the 
patch.

Thanks,
   Danny

-- 
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] sunxi-tools: some trivial fixes

[Siarhei Siamashka]

On Wed, 16 Dec 2015 12:14:10 +0100
Bernhard Nortmann  wrote:

> Am 16.12.2015 um 08:16 schrieb Siarhei Siamashka:
> > [...]
> > After this change, now both "spl" and "uboot" commands always execute
> > U-Boot in the end :-(
> >
> > Right now I'm playing with AR100 (an extra OpenRISC core in H3) and a
> > properly working "spl" command in "sunxi-fel" is quite useful for
> > initializing DRAM before uploading and running some OpenRISC code.
> >
> > [...]
> >
> > Well, last minute changes are always a sort of a lottery. It would
> > have been a bit nicer if we did not include this bug into a "release
> > point" ;-)  
> 
> Ouch. Well, I guess it kind of proves your point... :-P Fix attached.
> 
> Regards, B. Nortmann

Thanks, reviewed and pushed to sunxi-tools git.

-- 
Best regards,
Siarhei Siamashka

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

[linux-sunxi] Re: [PATCH 1/2] sunxi-tools: some trivial fixes

[Bernhard Nortmann]

Am 16.12.2015 um 08:16 schrieb Siarhei Siamashka:

[...]
After this change, now both "spl" and "uboot" commands always execute
U-Boot in the end :-(

Right now I'm playing with AR100 (an extra OpenRISC core in H3) and a
properly working "spl" command in "sunxi-fel" is quite useful for
initializing DRAM before uploading and running some OpenRISC code.

[...]

Well, last minute changes are always a sort of a lottery. It would
have been a bit nicer if we did not include this bug into a "release
point" ;-)


Ouch. Well, I guess it kind of proves your point... :-P Fix attached.

Regards, B. Nortmann

--
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
>From 7c61032b503ab8cded6dc49e5b960d7030229525 Mon Sep 17 00:00:00 2001
From: Bernhard Nortmann 
Date: Wed, 16 Dec 2015 11:25:46 +0100
Subject: [PATCH sunxi-tools] fel: bugfix - revert autostart change from
 d99d59c

Commit d99d59c introduces a bug when the "spl" command is used with a
file that contains a U-Boot binary. "spl" will now try to execute it,
while it's not supposed to. (The command should only start the SPL.)

This patch brings back the `uboot_autostart` flag, which is meant to
remain `false` for the "spl" command, and gets set by "uboot" only.

Signed-off-by: Bernhard Nortmann 
---
 fel.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fel.c b/fel.c
index df96f4d..12eae4d 100644
--- a/fel.c
+++ b/fel.c
@@ -1271,6 +1271,7 @@ static unsigned int file_upload(libusb_device_handle 
*handle, size_t count,
 
 int main(int argc, char **argv)
 {
+   bool uboot_autostart = false; /* flag for "uboot" command = U-Boot 
autostart */
bool pflag_active = false; /* -p switch, causing "write" to output 
progress */
int rc;
libusb_device_handle *handle = NULL;
@@ -1416,7 +1417,8 @@ int main(int argc, char **argv)
skip=2;
} else if (strcmp(argv[1], "uboot") == 0 && argc > 2) {
aw_fel_process_spl_and_uboot(handle, argv[2]);
-   if (!uboot_entry)
+   uboot_autostart = (uboot_entry > 0 && uboot_size > 0);
+   if (!uboot_autostart)
printf("Warning: \"uboot\" command failed to 
detect image! Can't execute U-Boot.\n");
skip=2;
} else {
@@ -1428,7 +1430,7 @@ int main(int argc, char **argv)
}
 
// auto-start U-Boot if requested (by the "uboot" command)
-   if (uboot_entry > 0 && uboot_size > 0) {
+   if (uboot_autostart) {
pr_info("Starting U-Boot (0x%08X).\n", uboot_entry);
aw_fel_execute(handle, uboot_entry);
}
-- 
2.4.6

[linux-sunxi] Re: [PATCH v2 1/3] reset: Add shared reset_control_[de]assert variants

[Philipp Zabel]

Hi Maxime,

Am Mittwoch, den 16.12.2015, 11:29 +0100 schrieb Maxime Ripard:
> On Mon, Dec 14, 2015 at 10:50:55AM +0100, Philipp Zabel wrote:
> > Am Montag, den 14.12.2015, 10:36 +0100 schrieb Maxime Ripard:
> > > Hi,
> > > 
> > > On Fri, Dec 11, 2015 at 04:41:58PM +0100, Hans de Goede wrote:
> > > > diff --git a/include/linux/reset.h b/include/linux/reset.h
> > > > index c4c097d..1cca8ce 100644
> > > > --- a/include/linux/reset.h
> > > > +++ b/include/linux/reset.h
> > > > @@ -11,6 +11,8 @@ int reset_control_reset(struct reset_control *rstc);
> > > >  int reset_control_assert(struct reset_control *rstc);
> > > >  int reset_control_deassert(struct reset_control *rstc);
> > > >  int reset_control_status(struct reset_control *rstc);
> > > > +int reset_control_assert_shared(struct reset_control *rstc);
> > > > +int reset_control_deassert_shared(struct reset_control *rstc);
> > > 
> > > Shouldn't that be handled in reset_control_get directly?

I think I see your point now. Maybe we should add a flags parameter to
reset_control_get and/or wrap it in two versions,
reset_control_get_exclusive and reset_control_get_shared (or just add
the _shared variant). Then reset_control_get(_exclusive) could return
-EBUSY if a reset line is already in use.

> > This is about different expectations of the caller.
> > A driver calling reset_control_assert expects the reset line to be
> > asserted after the call.
> 
> Is that behaviour documented explicitly somewhere?

/** 
  
 * reset_control_assert - asserts the reset line
 * @rstc: reset controller
 */

Also, that expected behavior matches the function name, which I like.
So I still welcome adding new API calls for the shared/refcounting
variant.

> > A driver calling reset_control_assert_shared
> > just signals that it doesn't care about the state of the reset line
> > anymore.
> > We could just as well call the two new functions
> > reset_control_deassert_get and reset_control_deassert_put.
> 
> What happens if you mix them? What happens if you have several drivers
> ignoring this API?

The core should give useful error messages and disallow non-shared reset
calls on shared lines.

> The current default API totally allows to have several drivers getting
> the same reset line, and happily poking that reset line without any
> way for the others to A) know they're not the single users B) let them
> know their device has been reset.

That's why I'd like the WARN_ON and error return in reset_control_* when
the reset_line reference count is > 1.

> And not being able to tell at the consumer level if and when our
> device is going to be reset behind our back is a big issue. Because
> then, we simply have to expect it can be reset at any point in time,
> good luck writing a driver with that expectation.

Yes, that is unacceptable.

> The reset framework should make sure that the shared case is an
> exception, and not the default case (and make sure that it cannot
> happen in the default case). Just like for any other framework with
> similar resources constraints.

regards
Philipp

-- 
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] sun4i-codec: Add FM, Line and Mic inputs

[Maxime Ripard]

Hi,

On Tue, Dec 15, 2015 at 02:52:08AM +0100, Danny Milosavljevic wrote:
> Hi Maxime,
> 
> On Sun, 13 Dec 2015 21:58:39 +0100
> Maxime Ripard  wrote:
> 
> > This is not the branch you should be basing your patch on. This is an
> > ASoC patch, base it on the ASoC tree.
> 
> Okay, will do. To the branch "sunxi-next" in 
> , right?
> 
> [...]
> > > -static const struct regmap_config sun4i_codec_regmap_config = {
> > > - .reg_bits   = 32,
> > > - .reg_stride = 4,
> > > - .val_bits   = 32,
> > > - .max_register   = SUN4I_CODEC_AC_MIC_PHONE_CAL,
> > > -};
> > > -
> > 
> > Why is this moved?
> 
> Because SUN4I_CODEC_AC_MIC_PHONE_CAL is sun7i-specific.

Yet, you're using it in both cases (A10 vs A20).

> Note: I also renamed it and moved the #define in the course of grouping 
> together sun7i-specific things:
> 
> > +/* sun7i-specific things: */
> > +/* MIC_PHONE_CAL register offsets and bit fields (A20 only) */
> > +#define SUN7I_CODEC_AC_MIC_PHONE_CAL   (0x3c)
> [...]
> > +static const struct regmap_config sun4i_codec_regmap_config = {
> > +   .reg_bits   = 32,
> > +   .reg_stride = 4,
> > +   .val_bits   = 32,
> > +   .max_register   = SUN7I_CODEC_AC_MIC_PHONE_CAL,
> > +};
> > +/* end sun7i-specific things */
> 
> I thought about also renaming sun4i_codec_regmap_config but decided against 
> it 
> since it's fine to use it on A10 and I think it's best if the name reflects 
> the minimum required hardware.
> 
> On the other hand, once I moved the define, sun4i-codec won't compile if 
> sun4i_codec_regmap_config is left at the top. So I had to move it, too.

You can also have the defines on top, and everything just works :)

> It will be clearer once I post a patch doing just the preparation of the 
> A10/A20 split.
> 
> I just checked A10 vs A20 some more:
> There's also SUN4I_CODEC_AC_SYS_VERI 0x38 present in original ASoC and in 
> 4.4-rc2.
> It's unused by us, not mentioned in the A10 User manual V1.5 20130820, and 
> called 
> "AC_DAC_CAL" in the A20 User Manual v1.4 20150510. Ok to delete? 
> Or is it better to rename it to "SUN7I_CODEC_AC_DAC_CAL" rather than delete?

You can rename it if you want, but it's not like it's of the highest
importance :)

> 
> > >  static int sun4i_codec_probe(struct platform_device *pdev)
> > >  {
> > >   struct snd_soc_card *card;
> > > @@ -593,6 +740,7 @@ static int sun4i_codec_probe(struct platform_device 
> > > *pdev)
> > >   struct resource *res;
> > >   void __iomem *base;
> > >   int ret;
> > > + const struct snd_soc_codec_driver* codec_codec;
> > 
> > I guess a single codec is enough :)
> 
> Modeled after the name of the original variable, see below :)
> 
> But OK, I'll rename it to "codec".
> 
> Note: the newest original ASoC sun4i-codec has a variable
>   "struct sun4i_codec *scodec;"
> as well in the same function (which is a different thing).

I don't know what you're refering to with "newest" and "original".

But two different variables with two different names doesn't seem so
bad, does it?

Thanks!
Maxime

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

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


signature.asc
Description: Digital signature

[linux-sunxi] [PATCH sunxi-tools] fel: fix memory leak, properly shut down USB library

[Bernhard Nortmann]

The aw_fel_process_spl_and_uboot() was missing a free() for the file
buffer. This patch also adds a proper libusb cleanup/shutdown.

Signed-off-by: Bernhard Nortmann 
---
 fel.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fel.c b/fel.c
index fdd6d35..59f0f72 100644
--- a/fel.c
+++ b/fel.c
@@ -1137,6 +1137,7 @@ void aw_fel_process_spl_and_uboot(libusb_device_handle 
*usb,
/* check for optional main U-Boot binary (and transfer it, if 
applicable) */
if (size > SPL_LEN_LIMIT)
aw_fel_write_uboot_image(usb, buf + SPL_LEN_LIMIT, size - 
SPL_LEN_LIMIT);
+   free(buf);
 }
 
 /*
@@ -1440,6 +1441,8 @@ int main(int argc, char **argv)
if (iface_detached >= 0)
libusb_attach_kernel_driver(handle, iface_detached);
 #endif
+   libusb_close(handle);
+   libusb_exit(NULL);
 
return 0;
 }
-- 
2.4.6

-- 
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 v6 4/9] mfd: axp20x: Split the driver into core and i2c bits

[Chen-Yu Tsai]

The axp20x driver assumes the device is i2c based. This is not the
case with later chips, which use a proprietary 2 wire serial bus
by Allwinner called "Reduced Serial Bus".

This patch follows the example of mfd/wm831x and splits it into
an interface independent core, and an i2c specific glue layer.
MFD_AXP20X and the new MFD_AXP20X_I2C are changed to tristate
symbols, allowing the driver to be built as modules.

Whitespace and other style errors in the moved i2c specific code
have been fixed. Included but unused header files are removed as
well.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/mfd/Kconfig|  14 ---
 drivers/mfd/Makefile   |   1 +
 drivers/mfd/axp20x-i2c.c   | 102 +
 drivers/mfd/axp20x.c   |  88 +++---
 include/linux/mfd/axp20x.h |  33 ++-
 5 files changed, 158 insertions(+), 80 deletions(-)
 create mode 100644 drivers/mfd/axp20x-i2c.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 4d92df6ef9fe..804cd3dcce32 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -91,14 +91,18 @@ config MFD_BCM590XX
  Support for the BCM590xx PMUs from Broadcom
 
 config MFD_AXP20X
-   bool "X-Powers AXP20X"
+   tristate
select MFD_CORE
-   select REGMAP_I2C
select REGMAP_IRQ
-   depends on I2C=y
+
+config MFD_AXP20X_I2C
+   tristate "X-Powers AXP series PMICs with I2C"
+   select MFD_AXP20X
+   select REGMAP_I2C
+   depends on I2C
help
- If you say Y here you get support for the X-Powers AXP202, AXP209 and
- AXP288 power management IC (PMIC).
+ If you say Y here you get support for the X-Powers AXP series power
+ management ICs (PMICs) controlled with I2C.
  This driver include only the core APIs. You have to select individual
  components like regulators or the PEK (Power Enable Key) under the
  corresponding menus.
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a8b76b81b467..a6913007d667 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_PMIC_DA9052)   += da9052-core.o
 obj-$(CONFIG_MFD_DA9052_SPI)   += da9052-spi.o
 obj-$(CONFIG_MFD_DA9052_I2C)   += da9052-i2c.o
 obj-$(CONFIG_MFD_AXP20X)   += axp20x.o
+obj-$(CONFIG_MFD_AXP20X_I2C)   += axp20x-i2c.o
 
 obj-$(CONFIG_MFD_LP3943)   += lp3943.o
 obj-$(CONFIG_MFD_LP8788)   += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-i2c.c b/drivers/mfd/axp20x-i2c.c
new file mode 100644
index ..b54205677bb2
--- /dev/null
+++ b/drivers/mfd/axp20x-i2c.c
@@ -0,0 +1,102 @@
+/*
+ * axp20x-i2c.c - I2C driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK 
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the I2C variants.
+ *
+ * Author: Carlo Caione 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int axp20x_i2c_probe(struct i2c_client *i2c,
+   const struct i2c_device_id *id)
+{
+   struct axp20x_dev *axp20x;
+   int ret;
+
+   axp20x = devm_kzalloc(>dev, sizeof(*axp20x), GFP_KERNEL);
+   if (!axp20x)
+   return -ENOMEM;
+
+   axp20x->dev = >dev;
+   axp20x->irq = i2c->irq;
+   dev_set_drvdata(axp20x->dev, axp20x);
+
+   ret = axp20x_match_device(axp20x);
+   if (ret)
+   return ret;
+
+   axp20x->regmap = devm_regmap_init_i2c(i2c, axp20x->regmap_cfg);
+   if (IS_ERR(axp20x->regmap)) {
+   ret = PTR_ERR(axp20x->regmap);
+   dev_err(>dev, "regmap init failed: %d\n", ret);
+   return ret;
+   }
+
+   return axp20x_device_probe(axp20x);
+}
+
+static int axp20x_i2c_remove(struct i2c_client *i2c)
+{
+   struct axp20x_dev *axp20x = i2c_get_clientdata(i2c);
+
+   return axp20x_device_remove(axp20x);
+}
+
+static const struct of_device_id axp20x_i2c_of_match[] = {
+   { .compatible = "x-powers,axp152", .data = (void *)AXP152_ID },
+   { .compatible = "x-powers,axp202", .data = (void *)AXP202_ID },
+   { .compatible = "x-powers,axp209", .data = (void *)AXP209_ID },
+   { .compatible = "x-powers,axp221", .data = (void *)AXP221_ID },
+   { },
+};
+MODULE_DEVICE_TABLE(of, axp20x_i2c_of_match);
+
+/*
+ * This is useless for OF-enabled devices, but it is needed by I2C subsystem
+ */
+static const struct i2c_device_id axp20x_i2c_id[] = {
+   { },
+};
+MODULE_DEVICE_TABLE(i2c, axp20x_i2c_id);
+
+static const struct acpi_device_id 

[linux-sunxi] [PATCH v6 7/9] regulator: axp20x: Support new AXP223 PMIC

[Chen-Yu Tsai]

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Mark Brown 
---
 drivers/regulator/axp20x-regulator.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/regulator/axp20x-regulator.c 
b/drivers/regulator/axp20x-regulator.c
index 35de22fdb7a0..55cce8125716 100644
--- a/drivers/regulator/axp20x-regulator.c
+++ b/drivers/regulator/axp20x-regulator.c
@@ -244,6 +244,7 @@ static int axp20x_set_dcdc_freq(struct platform_device 
*pdev, u32 dcdcfreq)
step = 75;
break;
case AXP221_ID:
+   case AXP223_ID:
min = 1800;
max = 4050;
def = 3000;
@@ -322,6 +323,7 @@ static int axp20x_set_dcdc_workmode(struct regulator_dev 
*rdev, int id, u32 work
break;
 
case AXP221_ID:
+   case AXP223_ID:
if (id < AXP22X_DCDC1 || id > AXP22X_DCDC5)
return -EINVAL;
 
@@ -360,6 +362,7 @@ static int axp20x_regulator_probe(struct platform_device 
*pdev)
nregulators = AXP20X_REG_ID_MAX;
break;
case AXP221_ID:
+   case AXP223_ID:
regulators = axp22x_regulators;
nregulators = AXP22X_REG_ID_MAX;
break;
-- 
2.6.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 v6 5/9] mfd: axp20x: Whitespace, open parenthesis alignment code style fixes

[Chen-Yu Tsai]

This fixes some leftover code style issues in the axp20x core.

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

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 631ad64ddf69..54a00168da26 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -591,14 +591,14 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
dev_err(dev, "Unable to match OF ID\n");
return -ENODEV;
}
-   axp20x->variant = (long) of_id->data;
+   axp20x->variant = (long)of_id->data;
} else {
acpi_id = acpi_match_device(dev->driver->acpi_match_table, dev);
if (!acpi_id || !acpi_id->driver_data) {
dev_err(dev, "Unable to match ACPI ID and data\n");
return -ENODEV;
}
-   axp20x->variant = (long) acpi_id->driver_data;
+   axp20x->variant = (long)acpi_id->driver_data;
}
 
switch (axp20x->variant) {
@@ -632,7 +632,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
return -EINVAL;
}
dev_info(dev, "AXP20x variant %s found\n",
-   axp20x_model_names[axp20x->variant]);
+axp20x_model_names[axp20x->variant]);
 
return 0;
 }
@@ -652,7 +652,7 @@ int axp20x_device_probe(struct axp20x_dev *axp20x)
}
 
ret = mfd_add_devices(axp20x->dev, -1, axp20x->cells,
-   axp20x->nr_cells, NULL, 0, NULL);
+ axp20x->nr_cells, NULL, 0, NULL);
 
if (ret) {
dev_err(axp20x->dev, "failed to add MFD devices: %d\n", ret);
-- 
2.6.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 v6 0/9] mfd: axp20x: Add support for RSB based AXP223

[Chen-Yu Tsai]

Hi everyone,

This is v6 of the AXP223 PMIC series. v6 fixes the address of the AXP223
in the DT. Hope this series makes it into 4.5, and we can then support
even more AXP PMICs in 4.6+.

Lee, can you take the first 7 patches. Once they're in, Maxime can take
the DTS patches.

Changes since v5:

  - Correct AXP223 address to 0x3a3.

Changes since v4:

  - Get rid of second parameter of axp20x_match_device() (new patch 2)

  - Match against dev->driver->of_match_table, so the entirety of
axp20x_match_device() can be kept in the core. (new patch 3)

  - Move *_device_id tables to bottom of the driver, right above driver
declaration. (patch 4 & 6)

  - Remove extra whitespaces while moving i2c specific code (patch 4)

  - Remove leftover whitespace and code style issues in axp20x core
(new patch 5)

  - Remove extra whitespaces in rsb specific code (patch 6)

Changes since v3:

  - Removed settings for axp223 reg_rtc_ldo from board dts files that
are already in axp22x.dtsi. The name is kept.

  - Dropped simplefb label and defconfig patches, as they are merged.

Changes since v2:

  - s/It's/Its/ for the commit messages of patches 5 and 7

  - Add Rob's Acked-by for patch 1

Changes since v1:

  - Dropped NMI interrupt controller dts patch (Merged)

  - Change MFD_AXP20X to represent the axp20x core, and drop MFD_AXP20X_CORE
  
  - Keep the axp20x core bits named axp20x.c

  - Add patch 7 to add AXP223 to sun8i-q8-common.dtsi

  - Add patch 8 & 9 to update defconfigs

  - Make axp20x drivers tristate and buildable as modules

  - Drop "_sunxi" substring from identifiers in axp20x-rsb driver


This series adds support for the Reduced Serial Bus based AXP223 PMIC.
The AXP223 is functionally identical to the AXP221, which we already
support. Only some default values for the regulators are different.
The defaults fit their recommended application, paired with different
SoCs.

Patch 1 adds AXP223 to the list of supported chips in the DT binding.

Patch 2 gets rid of the extra "struct device *" parameter from
axp20x_match_device().

Patch 3 makes axp20x_match_device() use dev->driver->of_match_table,
so the function can be library-ized without modification.

Patch 4 splits the axp20x mfd driver into 2 parts, a core library, and
an I2C driver.

Patch 5 cleans up some leftover whitespace issues in axp20x core.

Patch 6 adds an RSB based driver for the AXP223.

Patch 7 adds support for the AXP223 regulators

Patch 8 enables the AXP223 PMIC and its regulators for the Sinlinx
SinA33.

Patch 9 enables the AXP223 PMIC and its regulators for A23/A33 based
Q8 tablet devices.


Regards
ChenYu


Chen-Yu Tsai (9):
  mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings
  mfd: axp20x: Remove second struct device * parameter for
axp20x_match_device()
  mfd: axp20x: use dev->driver->of_match_table in axp20x_match_device()
  mfd: axp20x: Split the driver into core and i2c bits
  mfd: axp20x: Whitespace, open parenthesis alignment code style fixes
  mfd: axp20x: Add support for RSB based AXP223 PMIC
  regulator: axp20x: Support new AXP223 PMIC
  ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator
nodes
  ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes

 Documentation/devicetree/bindings/mfd/axp20x.txt |   7 +-
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts   |  76 -
 arch/arm/boot/dts/sun8i-q8-common.dtsi   |  83 +-
 drivers/mfd/Kconfig  |  25 --
 drivers/mfd/Makefile |   2 +
 drivers/mfd/axp20x-i2c.c | 102 +++
 drivers/mfd/axp20x-rsb.c |  78 +
 drivers/mfd/axp20x.c | 101 +-
 drivers/regulator/axp20x-regulator.c |   3 +
 include/linux/mfd/axp20x.h   |  34 +++-
 10 files changed, 418 insertions(+), 93 deletions(-)
 create mode 100644 drivers/mfd/axp20x-i2c.c
 create mode 100644 drivers/mfd/axp20x-rsb.c

-- 
2.6.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 v6 9/9] ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes

[Chen-Yu Tsai]

A23/A33 Q8 tablets have an X-Powers AXP223 PMIC connected via RSB. Its
regulators provide power to various parts of the SoC and the board.

Also add lcd regulator supply for simplefb and update the existing
vmmc-supply for mmc0.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-q8-common.dtsi | 83 +-
 1 file changed, 81 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-q8-common.dtsi 
b/arch/arm/boot/dts/sun8i-q8-common.dtsi
index 1a69231d2da5..9d2b7e2f5975 100644
--- a/arch/arm/boot/dts/sun8i-q8-common.dtsi
+++ b/arch/arm/boot/dts/sun8i-q8-common.dtsi
@@ -56,7 +56,6 @@
brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
default-brightness-level = <8>;
enable-gpios = < 7 6 GPIO_ACTIVE_HIGH>; /* PH6 */
-   /* backlight is powered by AXP223 DC1SW */
};
 
chosen {
@@ -67,7 +66,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin_q8>;
-   vmmc-supply = <_vcc3v0>;
+   vmmc-supply = <_dcdc1>;
bus-width = <4>;
cd-gpios = < 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
cd-inverted;
@@ -92,6 +91,82 @@
 
 _rsb {
status = "okay";
+
+   axp22x: pmic@3a3 {
+   compatible = "x-powers,axp223";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   eldoin-supply = <_dcdc1>;
+   };
+};
+
+#include "axp22x.dtsi"
+
+_aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-io";
+};
+
+_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <235>;
+   regulator-max-microvolt = <265>;
+   regulator-name = "vdd-dll";
+};
+
+_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <270>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-pll-avcc";
+};
+
+_dc1sw {
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-lcd";
+};
+
+_dc5ldo {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpus";
+};
+
+_dcdc1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-3v0";
+};
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-sys";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc5 {
+   regulator-always-on;
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "vcc-dram";
+};
+
+_rtc_ldo {
+   regulator-name = "vcc-rtc";
 };
 
 _uart {
@@ -99,3 +174,7 @@
pinctrl-0 = <_uart_pins_a>;
status = "okay";
 };
+
+_lcd {
+   vcc-lcd-supply = <_dc1sw>;
+};
-- 
2.6.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 v6 8/9] ARM: dts: sun8i: sinlinx-sina33: Add AXP223 PMIC device and regulator nodes

[Chen-Yu Tsai]

This board has a X-Powers AXP223 PMIC connected via RSB. Its regulators
provide power to various parts of the SoC and the board.

Also update the regulator supply phandles.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts | 76 +-
 1 file changed, 73 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts 
b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
index 13ce68f06dd6..8af38a9719ca 100644
--- a/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
+++ b/arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts
@@ -68,7 +68,7 @@
 };
 
  {
-   vref-supply = <_vcc3v0>;
+   vref-supply = <_dcdc1>;
status = "okay";
 
button@200 {
@@ -96,7 +96,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_pins_a>, <_cd_pin_sina33>;
-   vmmc-supply = <_vcc3v0>;
+   vmmc-supply = <_dcdc1>;
bus-width = <4>;
cd-gpios = < 1 4 GPIO_ACTIVE_HIGH>; /* PB4 */
cd-inverted;
@@ -106,7 +106,7 @@
  {
pinctrl-names = "default";
pinctrl-0 = <_8bit_pins>;
-   vmmc-supply = <_vcc3v0>;
+   vmmc-supply = <_dcdc1>;
bus-width = <8>;
non-removable;
status = "okay";
@@ -132,6 +132,76 @@
 
 _rsb {
status = "okay";
+
+   axp22x: pmic@3a3 {
+   compatible = "x-powers,axp223";
+   reg = <0x3a3>;
+   interrupt-parent = <_intc>;
+   interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+   eldoin-supply = <_dcdc1>;
+   };
+};
+
+#include "axp22x.dtsi"
+
+_aldo1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-io";
+};
+
+_aldo2 {
+   regulator-always-on;
+   regulator-min-microvolt = <235>;
+   regulator-max-microvolt = <265>;
+   regulator-name = "vdd-dll";
+};
+
+_aldo3 {
+   regulator-always-on;
+   regulator-min-microvolt = <270>;
+   regulator-max-microvolt = <330>;
+   regulator-name = "vcc-pll-avcc";
+};
+
+_dc5ldo {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpus";
+};
+
+_dcdc1 {
+   regulator-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-3v0";
+};
+
+_dcdc2 {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-sys";
+};
+
+_dcdc3 {
+   regulator-always-on;
+   regulator-min-microvolt = <90>;
+   regulator-max-microvolt = <140>;
+   regulator-name = "vdd-cpu";
+};
+
+_dcdc5 {
+   regulator-always-on;
+   regulator-min-microvolt = <150>;
+   regulator-max-microvolt = <150>;
+   regulator-name = "vcc-dram";
+};
+
+_rtc_ldo {
+   regulator-name = "vcc-rtc";
 };
 
  {
-- 
2.6.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 v6 3/9] mfd: axp20x: use dev->driver->of_match_table in axp20x_match_device()

[Chen-Yu Tsai]

In axp20x_match_device(), match the of_device_id table bound to the
device driver instead of pointing to axp20x_of_match directly. This
will allow us to keep axp20x_match_device() unmodified when we expand
the axp20x driver into multiple ones covering different interface
types.

of_device_get_match_data() cannot be used here as we need to know if
it failed to get a match, or if the match data value just happened to
be 0, as it is for the AXP152.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/mfd/axp20x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 685a78614f83..3e186f2dcac3 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -613,7 +613,7 @@ static int axp20x_match_device(struct axp20x_dev *axp20x)
const struct of_device_id *of_id;
 
if (dev->of_node) {
-   of_id = of_match_device(axp20x_of_match, dev);
+   of_id = of_match_device(dev->driver->of_match_table, dev);
if (!of_id) {
dev_err(dev, "Unable to match OF ID\n");
return -ENODEV;
-- 
2.6.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 v6 2/9] mfd: axp20x: Remove second struct device * parameter for axp20x_match_device()

[Chen-Yu Tsai]

The first argument passed to axp20x_match_device(), struct axp20x_dev *,
already contains a pointer to the device. By rearranging some code,
moving the assignment of the pointer before axp20x_match_device() is
called, we can eliminate the second parameter.

Suggested-by: Andy Shevchenko 
Signed-off-by: Chen-Yu Tsai 
---
 drivers/mfd/axp20x.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 9842199e2e6c..685a78614f83 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -606,8 +606,9 @@ static void axp20x_power_off(void)
 AXP20X_OFF);
 }
 
-static int axp20x_match_device(struct axp20x_dev *axp20x, struct device *dev)
+static int axp20x_match_device(struct axp20x_dev *axp20x)
 {
+   struct device *dev = axp20x->dev;
const struct acpi_device_id *acpi_id;
const struct of_device_id *of_id;
 
@@ -673,14 +674,14 @@ static int axp20x_i2c_probe(struct i2c_client *i2c,
if (!axp20x)
return -ENOMEM;
 
-   ret = axp20x_match_device(axp20x, >dev);
-   if (ret)
-   return ret;
-
axp20x->i2c_client = i2c;
axp20x->dev = >dev;
dev_set_drvdata(axp20x->dev, axp20x);
 
+   ret = axp20x_match_device(axp20x);
+   if (ret)
+   return ret;
+
axp20x->regmap = devm_regmap_init_i2c(i2c, axp20x->regmap_cfg);
if (IS_ERR(axp20x->regmap)) {
ret = PTR_ERR(axp20x->regmap);
-- 
2.6.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 v6 6/9] mfd: axp20x: Add support for RSB based AXP223 PMIC

[Chen-Yu Tsai]

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai 
---
 drivers/mfd/Kconfig| 11 +++
 drivers/mfd/Makefile   |  1 +
 drivers/mfd/axp20x-rsb.c   | 78 ++
 drivers/mfd/axp20x.c   |  2 ++
 include/linux/mfd/axp20x.h |  1 +
 5 files changed, 93 insertions(+)
 create mode 100644 drivers/mfd/axp20x-rsb.c

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 804cd3dcce32..13c565103e96 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -107,6 +107,17 @@ config MFD_AXP20X_I2C
  components like regulators or the PEK (Power Enable Key) under the
  corresponding menus.
 
+config MFD_AXP20X_RSB
+   tristate "X-Powers AXP series PMICs with RSB"
+   select MFD_AXP20X
+   depends on SUNXI_RSB
+   help
+ If you say Y here you get support for the X-Powers AXP series power
+ management ICs (PMICs) controlled with RSB.
+ This driver include only the core APIs. You have to select individual
+ components like regulators or the PEK (Power Enable Key) under the
+ corresponding menus.
+
 config MFD_CROS_EC
tristate "ChromeOS Embedded Controller"
select MFD_CORE
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index a6913007d667..caea6637d5e8 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -108,6 +108,7 @@ obj-$(CONFIG_MFD_DA9052_SPI)+= da9052-spi.o
 obj-$(CONFIG_MFD_DA9052_I2C)   += da9052-i2c.o
 obj-$(CONFIG_MFD_AXP20X)   += axp20x.o
 obj-$(CONFIG_MFD_AXP20X_I2C)   += axp20x-i2c.o
+obj-$(CONFIG_MFD_AXP20X_RSB)   += axp20x-rsb.o
 
 obj-$(CONFIG_MFD_LP3943)   += lp3943.o
 obj-$(CONFIG_MFD_LP8788)   += lp8788.o lp8788-irq.o
diff --git a/drivers/mfd/axp20x-rsb.c b/drivers/mfd/axp20x-rsb.c
new file mode 100644
index ..76ff02b96df0
--- /dev/null
+++ b/drivers/mfd/axp20x-rsb.c
@@ -0,0 +1,78 @@
+/*
+ * axp20x-rsb.c - RSB driver for the X-Powers' Power Management ICs
+ *
+ * AXP20x typically comprises an adaptive USB-Compatible PWM charger, BUCK 
DC-DC
+ * converters, LDOs, multiple 12-bit ADCs of voltage, current and temperature
+ * as well as configurable GPIOs.
+ *
+ * This driver supports the RSB variants.
+ *
+ * Author: Chen-Yu Tsai 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static int axp20x_rsb_probe(struct sunxi_rsb_device *rdev)
+{
+   struct axp20x_dev *axp20x;
+   int ret;
+
+   axp20x = devm_kzalloc(>dev, sizeof(*axp20x), GFP_KERNEL);
+   if (!axp20x)
+   return -ENOMEM;
+
+   axp20x->dev = >dev;
+   axp20x->irq = rdev->irq;
+   sunxi_rsb_device_set_drvdata(rdev, axp20x);
+
+   ret = axp20x_match_device(axp20x);
+   if (ret)
+   return ret;
+
+   axp20x->regmap = devm_regmap_init_sunxi_rsb(rdev, axp20x->regmap_cfg);
+   if (IS_ERR(axp20x->regmap)) {
+   ret = PTR_ERR(axp20x->regmap);
+   dev_err(>dev, "regmap init failed: %d\n", ret);
+   return ret;
+   }
+
+   return axp20x_device_probe(axp20x);
+}
+
+static int axp20x_rsb_remove(struct sunxi_rsb_device *rdev)
+{
+   struct axp20x_dev *axp20x = sunxi_rsb_device_get_drvdata(rdev);
+
+   return axp20x_device_remove(axp20x);
+}
+
+static const struct of_device_id axp20x_rsb_of_match[] = {
+   { .compatible = "x-powers,axp223", .data = (void *)AXP223_ID },
+   { },
+};
+MODULE_DEVICE_TABLE(of, axp20x_rsb_of_match);
+
+static struct sunxi_rsb_driver axp20x_rsb_driver = {
+   .driver = {
+   .name   = "axp20x-rsb",
+   .of_match_table = of_match_ptr(axp20x_rsb_of_match),
+   },
+   .probe  = axp20x_rsb_probe,
+   .remove = axp20x_rsb_remove,
+};
+module_sunxi_rsb_driver(axp20x_rsb_driver);
+
+MODULE_DESCRIPTION("PMIC MFD sunXi RSB driver for AXP20X");
+MODULE_AUTHOR("Chen-Yu Tsai ");
+MODULE_LICENSE("GPL v2");
diff --git a/drivers/mfd/axp20x.c b/drivers/mfd/axp20x.c
index 54a00168da26..968d77fb95d8 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -33,6 +33,7 @@ static const char * const axp20x_model_names[] = {
"AXP202",
"AXP209",
"AXP221",
+   "AXP223",
"AXP288",
 };
 
@@ -616,6 +617,7 @@ int axp20x_match_device(struct axp20x_dev *axp20x)
axp20x->regmap_irq_chip = _regmap_irq_chip;
break;
case AXP221_ID:
+   case AXP223_ID:
axp20x->nr_cells = ARRAY_SIZE(axp22x_cells);
axp20x->cells = axp22x_cells;
   

[linux-sunxi] [PATCH v6 1/9] mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings

[Chen-Yu Tsai]

The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
It is functionally identical to AXP221; only the regulator default
voltage/status and the external host interface are different.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Maxime Ripard 
Acked-by: Rob Herring 
Acked-by: Lee Jones 
---
 Documentation/devicetree/bindings/mfd/axp20x.txt | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt 
b/Documentation/devicetree/bindings/mfd/axp20x.txt
index a474359dd206..fd39fa54571b 100644
--- a/Documentation/devicetree/bindings/mfd/axp20x.txt
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -5,11 +5,12 @@ axp152 (X-Powers)
 axp202 (X-Powers)
 axp209 (X-Powers)
 axp221 (X-Powers)
+axp223 (X-Powers)
 
 Required properties:
 - compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
- "x-powers,axp221"
-- reg: The I2C slave address for the AXP chip
+ "x-powers,axp221", "x-powers,axp223"
+- reg: The I2C slave address or RSB hardware address for the AXP chip
 - interrupt-parent: The parent interrupt controller
 - interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
 - interrupt-controller: The PMIC has its own internal IRQs
@@ -51,7 +52,7 @@ LDO3  : LDO   : ldo3in-supply
 LDO4   : LDO   : ldo24in-supply: shared supply
 LDO5   : LDO   : ldo5in-supply
 
-AXP221 regulators, type, and corresponding input supply names:
+AXP221/AXP223 regulators, type, and corresponding input supply names:
 
 RegulatorTypeSupply Name Notes
 ---- -
-- 
2.6.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.

Re: [linux-sunxi] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support

[Hans de Goede]

Hi,

On 16-12-15 08:35, Siarhei Siamashka wrote:

On Thu, 10 Dec 2015 04:31:05 -0800 (PST)
Thomas Kaiser  wrote:


Hi,

Hans de Goede wrote:


? if I understand things correctly your patch make lima-memtester pass
at 672 MHz (which is our current configured speed) on both your
and Siarhei's boards, to me that seems that it fixes things.



A few more boards were tested but 672 MHz seem still questionable:

http://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit
http://www.orangepi.org/orangepibbsen/forum.php?mod=redirect=findpost=257=7465


Yes, the 672 MHz DRAM clock speed does not look like a good choice
for Orange Pi PC. Either we find better delays & zq settings and
improve reliability, or the DRAM clock speed needs to be decreased
(also ensuring a little bit of safety headroom).


(the latter interesting since he uses a huge 35x35x25mm heatsink that
covers also DRAM)


Some outliers are always possible and we have only one sample, which
can be clocked somewhat higher than the others. It is hard to make any
conclusions with the available data and the heatsink may be unrelated.

Unless we get more test results in a few days which radically change
the statistics, probably using 624 MHz for DRAM on Orange Pi PC would
be reasonable.


Reducing the DRAM speed to 624 seems like a good idea to me, can someone
send me a patch for this please?

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.

Re: [linux-sunxi] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support

[Peter Korsgaard]

> "Siarhei" == Siarhei Siamashka  writes:

Hi,

 > Some outliers are always possible and we have only one sample, which
 > can be clocked somewhat higher than the others. It is hard to make any
 > conclusions with the available data and the heatsink may be unrelated.

Yeah, I'm not sure what makes my board perform better than the rest. The
heatsink is just a cheap 14x14mm rpi one.

 > Unless we get more test results in a few days which radically change
 > the statistics, probably using 624 MHz for DRAM on Orange Pi PC would
 > be reasonable.

Sounds sensible.

-- 
Bye, Peter Korsgaard

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

Re: [linux-sunxi] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support

[Siarhei Siamashka]

On Thu, 10 Dec 2015 10:29:52 +0100
Jens Kuske  wrote:

> On 10/12/15 03:13, Siarhei Siamashka wrote:
> > Hello,
> > 
> > On Wed, 9 Dec 2015 19:29:49 +0100
> > Jens Kuske  wrote:
> >   
> >> On 09/12/15 09:40, Siarhei Siamashka wrote:  
> >> The read delays (except for dqs) are doubled in boot0 before
> >> writing them to the registers. Looks like they suddenly needed
> >> higher values than possible with 4 bit. The register seems to
> >> take 6 bit wide values.  
> > 
> > Well, we can always change the layout of data in this struct and
> > allocate 8 bits per each delay value instead of 4 bits:
> > 
> > struct dram_para para = {
> > .read_delays = 0x7979,
> > .write_delays = 0x6aaa,
> > .dual_rank = 0,
> > .bus_width = 32,
> > .row_bits = 15,
> > .page_size = 4096,
> > };
> > 
> > Are they originally the 'tpr11' and 'tpr12' parameters from FEX?  
> 
> Yes, they are. I just gave them meaningful names.
> Each nibble represents delay of one byte lane, the lower 4 for the DQ
> lines, the upper 4 for the DQS/DQS# lines.
> 
> > Maybe they belong in Kconfig, with a comment about how to do all
> > the needed conversion from FEX (multiplication by 2)?  
> 
> If it turns out that they should be different between boards, sure. But
> all FEX files I checked had the same values. Maybe the board vendors
> don't even know about these, Allwinner provided these somewhat strange
> numbers (why does lane 4 have a much shorter dqs write delay) and they
> adopted them...

It looks like exactly the same story as with A10/A13/A20. All the device
vendors are using the same set of settings, while these settings are
not necessarily optimal (or even good) specifically for their hardware.

> Maybe something like this would be a good idea:
> 
> CONFIG_DRAM_DQ_READ_DELAY = 0x0e120e12
> CONFIG_DRAM_DQS_READ_DELAY = 0x
> CONFIG_DRAM_DQ_WRITE_DELAY = 0x
> CONFIG_DRAM_DQS_WRITE_DELAY = 0x060a0a0a
> 
> Or we find values that work well on all boards.

This may be tricky. H3 still needs some automation. Because just
randomly trying different settings in a manual way is not a very
productive use of anyone's time.

Also active users engagement is critical, or we have no chance to
collect enough statistics from different board samples. Fortunately
Orange Pi PC seems to be quite popular, so it is likely to be one of
the best supported and well configured boards.

Another alternative is the board manufacturer's engagement.

> > BTW, do these delays serve a somewhat similar purpose as the 'tpr3'
> > parameter in A10/A13/A20? Later we could adapt the a10-tpr3-scan
> > script and make a h3 variant of it for bruteforce searching optimal
> > values of these delays.  
> 
> I think they are comparable with tpr3. The hardware would even support
> individual delays for each bit, but the combinations get endless then.

Yes, A10/A13/A20 also had many configuration knobs. Some configuration
knobs appear to be more important than the others in practice. This
needs to be figured out in an experimental way.

The Orange Pi PC has DDR3L-1600 memory chips. If the H3 DRAM controller
configuration is the only limiting factor, then there may be potentially
a way up to clock DRAM up to 800 MHz. And there is never too much
memory bandwidth for graphics and multimedia :-) Still the first
priority is of course trying to ensure reliable operation at the
specified/advertised ~667 MHz.

But I'm not sure if I want to do any work on this myself, unless enough
people register their interest and at least promise to participate in
testing.

> > 
> > With the lima-memtester test failures, we have already discovered
> > in an experimental way that correctly configuring these delays
> > apparently affects reliability :-)
> >   
> >> After fixing that, lima-memtester doesn't fail at 672 MHz anymore
> >> on my Orange Pi Plus. Before it failed at 552 and higher.
> >> Patch below.  
> > 
> > Thanks. With this U-Boot patch, lima-memtester does not fail anymore
> > at 672 MHz on my Orange Pi PC board too. That's a major improvement
> > over what is in U-boot 2016.01-rc2. If you are going to submit this
> > patch to U-Boot, you can have my
> > 
> > Tested-by: Siarhei Siamashka   
> 
> Should I submit it as a fix? I mean, it seems it doesn't really fix it
> at least on some Orange Pi PCs, but only improves the situation.
> My OPi Plus now passes 744 MHz too (maybe even higher, didn't try), so
> there are definitely differences between the boards.

We can always have this patch and also reduce the DRAM clock speed to
a safer level.

-- 
Best regards,
Siarhei Siamashka

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

Re: [linux-sunxi] Re: [PATCH 0/6] ARM: sunxi: Introduce Allwinner H3 support

[Thomas Kaiser]

Siarhei Siamashka wrote:

> Unless we get more test results in a few days which radically change
> the statistics, probably using 624 MHz for DRAM on Orange Pi PC would
> be reasonable.

I second that while also asking the overclocker community for help:

http://www.orangepi.org/orangepibbsen/forum.php?mod=viewthread=847
 

(but doubt that we get any useful feedback from there)

Regards,

Thomas




-- 
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 1/3] reset: Add shared reset_control_[de]assert variants

[Maxime Ripard]

On Mon, Dec 14, 2015 at 10:50:55AM +0100, Philipp Zabel wrote:
> Am Montag, den 14.12.2015, 10:36 +0100 schrieb Maxime Ripard:
> > Hi,
> > 
> > On Fri, Dec 11, 2015 at 04:41:58PM +0100, Hans de Goede wrote:
> > > diff --git a/include/linux/reset.h b/include/linux/reset.h
> > > index c4c097d..1cca8ce 100644
> > > --- a/include/linux/reset.h
> > > +++ b/include/linux/reset.h
> > > @@ -11,6 +11,8 @@ int reset_control_reset(struct reset_control *rstc);
> > >  int reset_control_assert(struct reset_control *rstc);
> > >  int reset_control_deassert(struct reset_control *rstc);
> > >  int reset_control_status(struct reset_control *rstc);
> > > +int reset_control_assert_shared(struct reset_control *rstc);
> > > +int reset_control_deassert_shared(struct reset_control *rstc);
> > 
> > Shouldn't that be handled in reset_control_get directly?
> 
> This is about different expectations of the caller.
> A driver calling reset_control_assert expects the reset line to be
> asserted after the call.

Is that behaviour documented explicitly somewhere?

> A driver calling reset_control_assert_shared
> just signals that it doesn't care about the state of the reset line
> anymore.
> We could just as well call the two new functions
> reset_control_deassert_get and reset_control_deassert_put.

What happens if you mix them? What happens if you have several drivers
ignoring this API?

The current default API totally allows to have several drivers getting
the same reset line, and happily poking that reset line without any
way for the others to A) know they're not the single users B) let them
know their device has been reset.

And not being able to tell at the consumer level if and when our
device is going to be reset behind our back is a big issue. Because
then, we simply have to expect it can be reset at any point in time,
good luck writing a driver with that expectation.

The reset framework should make sure that the shared case is an
exception, and not the default case (and make sure that it cannot
happen in the default case). Just like for any other framework with
similar resources constraints.

Maxime

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

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


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH v4] spi: dts: sun4i: Add support for wait time between word transmissions

[Maxime Ripard]

Hi,

On Mon, Dec 14, 2015 at 09:11:14AM +0100, Marcus Weseloh wrote:
> Adds a new property "spi-word-wait-ns" to the spi-bus binding that allows
> SPI slave devices to set a wait time between the transmission of words.
> Modifies the spi_device struct and slave device probing to read and store
> the new property.
> 
> Also modifies the sun4i SPI master driver to make use of the new property.
> This specific SPI controller needs 3 clock cycles to set up the delay,
> which makes the minimum non-zero wait time on this hardware 4 clock cycles.
> 
> Signed-off-by: Marcus Weseloh 

It looks mostly fine, however, please try to make only one thing in
one patch.

In this case, it would mean having one patch to add the DT property
and support in the SPI core in a first one, and then add support for
it in your driver.

I also have a minor comment below

> ---
> Changes from v1:
>  * renamed the property for more clarity
>  * wait time is set in nanoseconds instead of number of clock cycles
>  * transparently handle the 3 setup clock cycles
> 
> Changes from v2:
>  * fixed typo in comment
>  * moved parameter to spi-bus binding, dropping the vendor prefix
>  * changed commit summary and description to reflect the changes
> 
> Changes from v3:
>  * remove reference to "hardware" in comments and description, as the wait
>time could also be implemented in software
>  * read and set property value in spi core
> 
> As I am now changing SPI core, the sun4i driver and the spi-bus binding, I
> should probably split the patch into smaller parts (spi core + binding,
> sun4i changes). I will do that as soon as you are satisfied with the actual
> approach.
> ---
>  Documentation/devicetree/bindings/spi/spi-bus.txt |  2 ++
>  drivers/spi/spi-sun4i.c   | 23 
> +++
>  drivers/spi/spi.c |  2 ++
>  include/linux/spi/spi.h   |  2 ++
>  4 files changed, 29 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/spi/spi-bus.txt 
> b/Documentation/devicetree/bindings/spi/spi-bus.txt
> index bbaa857..434d321 100644
> --- a/Documentation/devicetree/bindings/spi/spi-bus.txt
> +++ b/Documentation/devicetree/bindings/spi/spi-bus.txt
> @@ -61,6 +61,8 @@ contain the following properties.
>used for MOSI. Defaults to 1 if not present.
>  - spi-rx-bus-width - (optional) The bus width(number of data wires) that
>used for MISO. Defaults to 1 if not present.
> +- spi-word-wait-ns - (optional) Delay between transmission of words
> +  in nanoseconds
>  
>  Some SPI controllers and devices support Dual and Quad SPI transfer mode.
>  It allows data in the SPI system to be transferred in 2 wires(DUAL) or 4 
> wires(QUAD).
> diff --git a/drivers/spi/spi-sun4i.c b/drivers/spi/spi-sun4i.c
> index f60a6d6..c1a33dc 100644
> --- a/drivers/spi/spi-sun4i.c
> +++ b/drivers/spi/spi-sun4i.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -84,6 +85,7 @@ struct sun4i_spi {
>   const u8*tx_buf;
>   u8  *rx_buf;
>   int len;
> + u32 word_wait_ns;
>  };
>  
>  static inline u32 sun4i_spi_read(struct sun4i_spi *sspi, u32 reg)
> @@ -173,6 +175,8 @@ static int sun4i_spi_transfer_one(struct spi_master 
> *master,
>   unsigned int tx_len = 0;
>   int ret = 0;
>   u32 reg;
> + int wait_clk = 0;
> + int clk_ns = 0;
>  
>   /* We don't support transfer larger than the FIFO */
>   if (tfr->len > SUN4I_FIFO_DEPTH)
> @@ -261,6 +265,25 @@ static int sun4i_spi_transfer_one(struct spi_master 
> *master,
>  
>   sun4i_spi_write(sspi, SUN4I_CLK_CTL_REG, reg);
>  
> + /*
> +  * Setup wait time between words.
> +  *
> +  * Wait time is set in SPI_CLK cycles. The SPI hardware needs 3
> +  * additional cycles to setup the wait counter, so the minimum delay
> +  * time is 4 cycles.
> +  */
> + if (spi->word_wait_ns) {
> + clk_ns = DIV_ROUND_UP(10, tfr->speed_hz);
> + wait_clk = DIV_ROUND_UP(spi->word_wait_ns, clk_ns) - 3;
> + if (wait_clk < 1) {
> + wait_clk = 1;
> + dev_info(>dev,
> +  "using minimum of 4 word wait cycles (%uns)",
> +  4 * clk_ns);

Logging it at the info loglevel seems a bit too high. debug seems more
appropriate.

Thanks!
Maxime

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

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

[linux-sunxi] pcduino nano3lite for 15usd

[Benjamin Henrion]

pcduino nano3lite for 15usd, with gigabit and sata:

http://www.cnx-software.com/2015/12/16/15-pcduino-nano3-lite-includes-gigabit-ethernet-and-a-real-sata-port/

--
Benjamin Henrion 
FFII Brussels - +32-484-566109 - +32-2-3500762
"In July 2005, after several failed attempts to legalise software
patents in Europe, the patent establishment changed its strategy.
Instead of explicitly seeking to sanction the patentability of
software, they are now seeking to create a central European patent
court, which would establish and enforce patentability rules in their
favor, without any possibility of correction by competing courts or
democratically elected legislators."

-- 
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.