Re: [linux-sunxi] Re: [PATCH 2/2] ehci-platform: Add support for controllers with multiple reset lines

[Chen-Yu Tsai]

On Mon, Nov 16, 2015 at 11:42 PM, Alan Stern  wrote:
> On Sun, 15 Nov 2015, Hans de Goede wrote:
>
>> From: Reinder de Haan 
>>
>> At least the EHCI found on the Allwinnner H3 SoC needs multiple reset
>> lines, the controller will not initialize while the reset for its
>> companion OHCI is still asserted, which means we need to de-assert
>> 2 reset-controllers for this EHCI controller to work.
>
> I assume that reset_control_deassert() is smart enough to maintain a
> count of de-assertions, and it doesn't actually turn on the reset line
> until the count drops to 0.  Right?

No it doesn't. That might be a problem when 2 devices (such as EHCI / OHCI
pairs) share a reset line, one probes successfully while the other doesn't.
Hans?

>> Signed-off-by: Reinder de Haan 
>> Signed-off-by: Hans de Goede 
>
> ...
>
>> @@ -229,18 +230,24 @@ static int ehci_platform_probe(struct platform_device 
>> *dev)
>>   break;
>>   }
>>   }
>> - }
>>
>> - priv->rst = devm_reset_control_get_optional(>dev, NULL);
>> - if (IS_ERR(priv->rst)) {
>> - err = PTR_ERR(priv->rst);
>> - if (err == -EPROBE_DEFER)
>> - goto err_put_clks;
>> - priv->rst = NULL;
>> - } else {
>> - err = reset_control_deassert(priv->rst);
>> - if (err)
>> - goto err_put_clks;
>> + for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {
>
> What happens on platforms that don't use OF?  Or if pdata is not equal
> to _platform_defaults?  Can you guarantee that those platforms
> will never need to turn off a reset line?

The reset control framework is OF / DT only at the moment.

Regards
ChenYu

>> + priv->resets[rst] =
>> + of_reset_control_get_by_index(dev->dev.of_node,
>> +   rst);
>
> The style used in this file is to indent continuation lines to 2 two
> stops, not to line things up with an open paren on the previous line.
>
> The rest of the patch looks okay.
>
> Alan Stern
>

-- 
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 v4 04/24] hwmon: pwm-fan: use pwm_get_xxx() helpers where appropriate

[Guenter Roeck]

On 11/16/2015 08:53 AM, Boris Brezillon wrote:

On Mon, 16 Nov 2015 07:59:23 -0800
Guenter Roeck  wrote:


On 11/16/2015 12:56 AM, Boris Brezillon wrote:

Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
Doing that will ease adaptation of the PWM framework to support atomic
update.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

--->8---
virtual patch

@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity((p), e);
|
-(p)->polarity
+pwm_get_polarity((p))


s/((p))/(p)/


|
-(p)->period = e;
+pwm_set_period((p), e);
|
-(p)->period
+pwm_get_period((p))


s/((p))/(p)/


|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle((p), e);


The (p) seems unnecessary here.


I don't get this one. You mean I should drop one the parenthesis around
p, right?



Same as above - s/(p)/p/. It should never be necessary to write
pwm_set_duty_cycle((p), e)
since
pwm_set_duty_cycle(p, e)
should be the same.

On the other side, I did not see this expression used in any of the patches,
though maybe I missed it.

Thanks,
Guenter

--
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 2/2] ehci-platform: Add support for controllers with multiple reset lines

[Philipp Zabel]

Am Montag, den 16.11.2015, 17:49 +0100 schrieb Hans de Goede:
> Hi,
> 
> On 16-11-15 17:04, Chen-Yu Tsai wrote:
> > On Mon, Nov 16, 2015 at 11:42 PM, Alan Stern  
> > wrote:
> >> On Sun, 15 Nov 2015, Hans de Goede wrote:
> >>
> >>> From: Reinder de Haan 
> >>>
> >>> At least the EHCI found on the Allwinnner H3 SoC needs multiple reset
> >>> lines, the controller will not initialize while the reset for its
> >>> companion OHCI is still asserted, which means we need to de-assert
> >>> 2 reset-controllers for this EHCI controller to work.
> >>
> >> I assume that reset_control_deassert() is smart enough to maintain a
> >> count of de-assertions, and it doesn't actually turn on the reset line
> >> until the count drops to 0.  Right?
> >
> > No it doesn't. That might be a problem when 2 devices (such as EHCI / OHCI
> > pairs) share a reset line, one probes successfully while the other doesn't.
> > Hans?
> 
> Ugh, good catch Alan, so I think the best way to solve this is to
> actually make reset_control do a deassert / (re)assert count like
> is done already for clocks, there is bound to be more hardware out there
> which shares a reset line between 2 related blocks.
> 
> I'll whip up a patch for this, submit it and then we'll see.

If there are two devices sharing the same reset line that is initially
held asserted, do the two drivers somehow have to synchronize before
releasing the reset together?

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 v4 13/24] hwmon: pwm-fan: use pwm_get/set_default_xxx() helpers where appropriate

[Guenter Roeck]

On 11/16/2015 12:56 AM, Boris Brezillon wrote:

pwm_set/get_default_xxx() helpers have been introduced to differentiate
the default PWM states (those retrieved through DT, PWM lookup table or
statically assigned by the driver) and the current ones.
Make use of those helpers where appropriate.

Signed-off-by: Boris Brezillon 
---
  drivers/hwmon/pwm-fan.c | 15 +--
  1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 105b964..989d7b4 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -47,8 +47,9 @@ static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long 
pwm)
if (ctx->pwm_value == pwm)
goto exit_set_pwm_err;

-   duty = DIV_ROUND_UP(pwm * (pwm_get_period((ctx->pwm)) - 1), MAX_PWM);
-   ret = pwm_config(ctx->pwm, duty, pwm_get_period((ctx->pwm)));
+   duty = DIV_ROUND_UP(pwm * (pwm_get_default_period((ctx->pwm)) - 1),
+   MAX_PWM);
+   ret = pwm_config(ctx->pwm, duty, pwm_get_default_period((ctx->pwm)));


Same here - please no unnecessary ( ) [ which were first introduced by
the other patch ].

Guenter


if (ret)
goto exit_set_pwm_err;

@@ -234,10 +235,11 @@ static int pwm_fan_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);

/* Set duty cycle to maximum allowed */
-   duty_cycle = pwm_get_period((ctx->pwm)) - 1;
+   duty_cycle = pwm_get_default_period((ctx->pwm)) - 1;
ctx->pwm_value = MAX_PWM;

-   ret = pwm_config(ctx->pwm, duty_cycle, pwm_get_period((ctx->pwm)));
+   ret = pwm_config(ctx->pwm, duty_cycle,
+pwm_get_default_period((ctx->pwm)));
if (ret) {
dev_err(>dev, "Failed to configure PWM\n");
return ret;
@@ -309,9 +311,10 @@ static int pwm_fan_resume(struct device *dev)
if (ctx->pwm_value == 0)
return 0;

-   duty = DIV_ROUND_UP(ctx->pwm_value * (pwm_get_period((ctx->pwm)) - 1),
+   duty = DIV_ROUND_UP(ctx->pwm_value *
+   (pwm_get_default_period((ctx->pwm)) - 1),
MAX_PWM);
-   ret = pwm_config(ctx->pwm, duty, pwm_get_period((ctx->pwm)));
+   ret = pwm_config(ctx->pwm, duty, pwm_get_default_period((ctx->pwm)));
if (ret)
return ret;
return pwm_enable(ctx->pwm);



--
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 v4 05/24] misc: max77693-haptic: use pwm_get_xxx() helpers where appropriate

[Boris Brezillon]

On Mon, 16 Nov 2015 07:55:33 -0800
Guenter Roeck  wrote:

> On 11/16/2015 05:55 AM, Boris Brezillon wrote:
> > Hi Krzysztof,
> >
> > On Mon, 16 Nov 2015 22:10:40 +0900
> > Krzysztof Kozlowski  wrote:
> >
> >> W dniu 16.11.2015 o 17:56, Boris Brezillon pisze:
> >>> Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx 
> >>> field.
> >>> Doing that will ease adaptation of the PWM framework to support atomic
> >>> update.
> >>>
> >>> Signed-off-by: Boris Brezillon 
> >>> ---
> >>> Patch generated with the following coccinelle script:
> >>>
> >>> --->8---
> >>> virtual patch
> >>>
> >>> @@
> >>> struct pwm_device *p;
> >>> expression e;
> >>> @@
> >>> (
> >>> -(p)->polarity = e;
> >>> +pwm_set_polarity((p), e);
> >>> |
> >>> -(p)->polarity
> >>> +pwm_get_polarity((p))
> >>> |
> >>> -(p)->period = e;
> >>> +pwm_set_period((p), e);
> >>> |
> >>> -(p)->period
> >>> +pwm_get_period((p))
> >>> |
> >>> -(p)->duty_cycle = e;
> >>> +pwm_set_duty_cycle((p), e);
> >>> |
> >>> -(p)->duty_cycle
> >>> +pwm_get_duty_cycle((p))
> >>> )
> >>> --->8---
> >>> ---
> >>>   drivers/input/misc/max77693-haptic.c | 7 ---
> >>>   1 file changed, 4 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/drivers/input/misc/max77693-haptic.c 
> >>> b/drivers/input/misc/max77693-haptic.c
> >>> index 6d96bff..a038fb3 100644
> >>> --- a/drivers/input/misc/max77693-haptic.c
> >>> +++ b/drivers/input/misc/max77693-haptic.c
> >>> @@ -70,10 +70,11 @@ struct max77693_haptic {
> >>>
> >>>   static int max77693_haptic_set_duty_cycle(struct max77693_haptic 
> >>> *haptic)
> >>>   {
> >>> - int delta = (haptic->pwm_dev->period + haptic->pwm_duty) / 2;
> >>> + int delta = (pwm_get_period((haptic->pwm_dev)) + haptic->pwm_duty) / 2;
> >>
> >> Double parentheses over argument are not needed so just:
> >> pwm_get_period(haptic->pwm_dev) + ...
> >
> > Actually it was generated with coccinelle, hence I didn't fix existing
> > coding style issues, but I have no problem fixing them.
> >
> There was no existing coding style issue. Your coccinelle script introduces 
> it.
> You might want to consider updating your script and remove the unnecessary (( 
> ))
> from it.

My bad, you are right: my script is buggy. I'll fix that.

Thanks,

Boris


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

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

[linux-sunxi] [PATCH v3 5/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 | 79 +-
 1 file changed, 76 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..91a0fde47fdd 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,79 @@
 
 _rsb {
status = "okay";
+
+   axp22x: pmic@3e3 {
+   compatible = "x-powers,axp223";
+   reg = <0x3e3>;
+   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-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-rtc";
 };
 
  {
-- 
2.6.2

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

[linux-sunxi] [PATCH v3 9/9] ARM: multi_v7_defconfig: Enable RSB and AXP20X related drivers as modules

[Chen-Yu Tsai]

axp20x support has been split into 2 parts, I2C and RSB interface
variants.

Update the MFD_AXP20X symbol for I2C support. Also enable SUNXI_RSB
MFD_AXP20X_RSB to support RSB variants. Build these drivers as
modules.

Keep MFD_AXP20X enabled for now, to ease migration for automated
boot farms while the patches are being merged. This should be
removed in the next release.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/configs/multi_v7_defconfig | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 69a22fdb52a5..bf6dac096bb6 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -169,6 +169,7 @@ CONFIG_DMA_CMA=y
 CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_OMAP_OCP2SCP=y
 CONFIG_SIMPLE_PM_BUS=y
+CONFIG_SUNXI_RSB=m
 CONFIG_MTD=y
 CONFIG_MTD_CMDLINE_PARTS=y
 CONFIG_MTD_BLOCK=y
@@ -253,7 +254,7 @@ CONFIG_TOUCHSCREEN_SUN4I=y
 CONFIG_TOUCHSCREEN_WM97XX=m
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_MPU3050=y
-CONFIG_INPUT_AXP20X_PEK=y
+CONFIG_INPUT_AXP20X_PEK=m
 CONFIG_INPUT_ADXL34X=m
 CONFIG_SERIO_AMBAKMI=y
 CONFIG_SERIAL_8250=y
@@ -366,6 +367,7 @@ CONFIG_BATTERY_MAX17042=m
 CONFIG_CHARGER_MAX14577=m
 CONFIG_CHARGER_MAX77693=m
 CONFIG_CHARGER_TPS65090=y
+CONFIG_AXP20X_POWER=m
 CONFIG_POWER_RESET_AS3722=y
 CONFIG_POWER_RESET_GPIO=y
 CONFIG_POWER_RESET_GPIO_RESTART=y
@@ -397,6 +399,8 @@ CONFIG_MFD_AS3722=y
 CONFIG_MFD_ATMEL_FLEXCOM=y
 CONFIG_MFD_BCM590XX=y
 CONFIG_MFD_AXP20X=y
+CONFIG_MFD_AXP20X_I2C=m
+CONFIG_MFD_AXP20X_RSB=m
 CONFIG_MFD_CROS_EC=y
 CONFIG_MFD_CROS_EC_I2C=m
 CONFIG_MFD_CROS_EC_SPI=y
@@ -417,7 +421,7 @@ CONFIG_REGULATOR_AB8500=y
 CONFIG_REGULATOR_ACT8865=y
 CONFIG_REGULATOR_AS3711=y
 CONFIG_REGULATOR_AS3722=y
-CONFIG_REGULATOR_AXP20X=y
+CONFIG_REGULATOR_AXP20X=m
 CONFIG_REGULATOR_BCM590XX=y
 CONFIG_REGULATOR_DA9210=y
 CONFIG_REGULATOR_FAN53555=y
-- 
2.6.2

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

[linux-sunxi] [PATCH v3 2/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.

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   | 127 +
 drivers/mfd/axp20x.c   | 108 +-
 include/linux/mfd/axp20x.h |  33 +++-
 5 files changed, 183 insertions(+), 100 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 ..75b247af2514
--- /dev/null
+++ b/drivers/mfd/axp20x-i2c.c
@@ -0,0 +1,127 @@
+/*
+ * 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 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 axp20x_i2c_acpi_match[] = {
+   {
+   .id = "INT33F4",
+   .driver_data = AXP288_ID,
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(acpi, axp20x_i2c_acpi_match);
+
+static int axp20x_i2c_match_device(struct axp20x_dev *axp20x,
+  struct device *dev)
+{
+   const struct acpi_device_id *acpi_id;
+   const struct of_device_id *of_id;
+
+   if (dev->of_node) {
+   of_id = of_match_device(axp20x_i2c_of_match, dev);
+   if (!of_id) {
+   dev_err(dev, "Unable to match OF ID\n");
+   return -ENODEV;
+   }
+   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;
+   }
+
+ 

[linux-sunxi] [PATCH v3 6/9] ARM: dts: sun8i: Add simplefb node labels to reference at board level

[Chen-Yu Tsai]

Some boards, such as tablets, have regulators providing power to parts
of the display pipeline, like signal converters and LCD panels.

Add labels to the simplefb device nodes so that we can reference them
in the board dts files to add regulator supply properties.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/boot/dts/sun8i-a23-a33.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/sun8i-a23-a33.dtsi 
b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
index 0c0964d4fa1f..6f88fb0ddbc7 100644
--- a/arch/arm/boot/dts/sun8i-a23-a33.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23-a33.dtsi
@@ -56,7 +56,7 @@
#size-cells = <1>;
ranges;
 
-   framebuffer@0 {
+   simplefb_lcd: framebuffer@0 {
compatible = "allwinner,simple-framebuffer",
 "simple-framebuffer";
allwinner,pipeline = "de_be0-lcd0";
-- 
2.6.2

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

[linux-sunxi] [PATCH v3 0/9] mfd: axp20x: Add support for RSB based AXP223

[Chen-Yu Tsai]

Hi everyone,

This is v3 of the AXP223 PMIC series.

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 splits the axp20x mfd driver into 2 parts, a core library, and
an I2C driver.

Patch 3 adds an RSB based driver for the AXP223.

Patch 4 adds support for the AXP223 regulators

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

Patch 6 adds a label to the simplefb node in the sun8i dts.

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

Patch 8 enables MFD_AXP20X_I2C and MFD_AXP20X_RSB in sunxi_defconfig

Patch 9 enables SUNXI_RSB, MFD_AXP20X_RSB and MFD_AXP20X_RSB in
multi_v7_defconfig, and changes all existing AXP20X related symbols
to M (module).


Regards
ChenYu


Chen-Yu Tsai (9):
  mfd: axp20x: Add AXP223 to list of supported PMICs in DT bindings
  mfd: axp20x: Split the driver into core and i2c bits
  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: Add simplefb node labels to reference at board level
  ARM: dts: sun8i: q8-common: Add AXP223 PMIC device and regulator nodes
  ARM: sunxi_defconfig: Update MFD_AXP20X symbol and enable
MFD_AXP20X_RSB
  ARM: multi_v7_defconfig: Enable RSB and AXP20X related drivers as
modules

 Documentation/devicetree/bindings/mfd/axp20x.txt |   7 +-
 arch/arm/boot/dts/sun8i-a23-a33.dtsi |   2 +-
 arch/arm/boot/dts/sun8i-a33-sinlinx-sina33.dts   |  79 +-
 arch/arm/boot/dts/sun8i-q8-common.dtsi   |  86 ++-
 arch/arm/configs/multi_v7_defconfig  |   8 +-
 arch/arm/configs/sunxi_defconfig |   2 +
 drivers/mfd/Kconfig  |  25 -
 drivers/mfd/Makefile |   2 +
 drivers/mfd/axp20x-i2c.c | 127 +++
 drivers/mfd/axp20x-rsb.c |  93 +
 drivers/mfd/axp20x.c | 110 +++-
 drivers/regulator/axp20x-regulator.c |   3 +
 include/linux/mfd/axp20x.h   |  34 +-
 13 files changed, 467 insertions(+), 111 deletions(-)
 create mode 100644 drivers/mfd/axp20x-i2c.c
 create mode 100644 drivers/mfd/axp20x-rsb.c

-- 
2.6.2

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

[linux-sunxi] [PATCH v3 3/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   | 93 ++
 drivers/mfd/axp20x.c   |  2 +
 include/linux/mfd/axp20x.h |  1 +
 5 files changed, 108 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 ..3ea0d5db37d0
--- /dev/null
+++ b/drivers/mfd/axp20x-rsb.c
@@ -0,0 +1,93 @@
+/*
+ * 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 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 int axp20x_rsb_match_device(struct axp20x_dev *axp20x,
+struct device *dev)
+{
+   const struct of_device_id *of_id;
+
+   of_id = of_match_device(axp20x_rsb_of_match, dev);
+   if (!of_id) {
+   dev_err(dev, "Unable to match OF ID\n");
+   return -ENODEV;
+   }
+   axp20x->variant = (long) of_id->data;
+
+   return axp20x_match_device(axp20x, dev);
+}
+
+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;
+
+   ret = axp20x_rsb_match_device(axp20x, >dev);
+   if (ret)
+   return ret;
+
+   axp20x->dev = >dev;
+   axp20x->irq = rdev->irq;
+   sunxi_rsb_device_set_drvdata(rdev, axp20x);
+
+   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 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 01f139856bf1..8057000da9d6 100644
--- a/drivers/mfd/axp20x.c
+++ b/drivers/mfd/axp20x.c
@@ -32,6 +32,7 @@ 

Re: [linux-sunxi] Re: [PATCH 2/2] ehci-platform: Add support for controllers with multiple reset lines

[Hans de Goede]

Hi,

On 16-11-15 17:04, Chen-Yu Tsai wrote:

On Mon, Nov 16, 2015 at 11:42 PM, Alan Stern  wrote:

On Sun, 15 Nov 2015, Hans de Goede wrote:


From: Reinder de Haan 

At least the EHCI found on the Allwinnner H3 SoC needs multiple reset
lines, the controller will not initialize while the reset for its
companion OHCI is still asserted, which means we need to de-assert
2 reset-controllers for this EHCI controller to work.


I assume that reset_control_deassert() is smart enough to maintain a
count of de-assertions, and it doesn't actually turn on the reset line
until the count drops to 0.  Right?


No it doesn't. That might be a problem when 2 devices (such as EHCI / OHCI
pairs) share a reset line, one probes successfully while the other doesn't.
Hans?


Ugh, good catch Alan, so I think the best way to solve this is to
actually make reset_control do a deassert / (re)assert count like
is done already for clocks, there is bound to be more hardware out there
which shares a reset line between 2 related blocks.

I'll whip up a patch for this, submit it and then we'll see.

Regards,

Hans





Signed-off-by: Reinder de Haan 
Signed-off-by: Hans de Goede 


...


@@ -229,18 +230,24 @@ static int ehci_platform_probe(struct platform_device 
*dev)
   break;
   }
   }
- }

- priv->rst = devm_reset_control_get_optional(>dev, NULL);
- if (IS_ERR(priv->rst)) {
- err = PTR_ERR(priv->rst);
- if (err == -EPROBE_DEFER)
- goto err_put_clks;
- priv->rst = NULL;
- } else {
- err = reset_control_deassert(priv->rst);
- if (err)
- goto err_put_clks;
+ for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {


What happens on platforms that don't use OF?  Or if pdata is not equal
to _platform_defaults?  Can you guarantee that those platforms
will never need to turn off a reset line?


The reset control framework is OF / DT only at the moment.

Regards
ChenYu


+ priv->resets[rst] =
+ of_reset_control_get_by_index(dev->dev.of_node,
+   rst);


The style used in this file is to indent continuation lines to 2 two
stops, not to line things up with an open paren on the previous line.

The rest of the patch looks okay.

Alan Stern



--
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 25/27] ARM: make use of nand_set/get_controller_data() helpers

[Boris Brezillon]

New helpers have been added to avoid directly accessing chip->field. Use
them where appropriate.

Signed-off-by: Boris Brezillon 
---
 arch/arm/mach-ixp4xx/ixdp425-setup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c 
b/arch/arm/mach-ixp4xx/ixdp425-setup.c
index 333b0f9..508c2d7 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -77,7 +77,7 @@ static void
 ixdp425_flash_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
struct nand_chip *this = mtd_to_nand(mtd);
-   int offset = (int)this->priv;
+   int offset = (int)nand_get_controller_data(this);
 
if (ctrl & NAND_CTRL_CHANGE) {
if (ctrl & NAND_NCE) {
@@ -88,7 +88,7 @@ ixdp425_flash_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, 
unsigned int ctrl)
 
offset = (ctrl & NAND_CLE) ? IXDP425_NAND_CMD_BYTE : 0;
offset |= (ctrl & NAND_ALE) ? IXDP425_NAND_ADDR_BYTE : 0;
-   this->priv = (void *)offset;
+   nand_set_controller_data(this, (void *)offset);
}
 
if (cmd != NAND_CMD_NONE)
-- 
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 21/27] staging: mt29f_spinand: remove useless mtd->priv = chip assignment

[Boris Brezillon]

mtd_to_nand_chip() now uses the container_of() approach to transform an
mtd_info pointer into a nand_chip one. Drop useless mtd->priv
assignments from NAND controller drivers.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

---8<
virtual patch

@@
struct mtd_info mtd;
struct mtd_info *mtdptr;
struct nand_chip *chipptr;
expression d;
@@
(
-(mtd).priv = (chipptr);
|
-(mtdptr)->priv = (chipptr);
---8<
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c 
b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 8171b74..b7d429d 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -907,7 +907,6 @@ static int spinand_probe(struct spi_device *spi_nand)
 
dev_set_drvdata(_nand->dev, mtd);
 
-   mtd->priv = chip;
mtd->dev.parent = _nand->dev;
mtd->oobsize = 64;
 
-- 
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 27/27] staging: mt29f_spinand: make use of nand_set/get_controller_data() helpers

[Boris Brezillon]

New helpers have been added to avoid directly accessing chip->field. Use
them where appropriate.

Signed-off-by: Boris Brezillon 
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c 
b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index b7d429d..5b3027a 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -32,7 +32,7 @@
 static inline struct spinand_state *mtd_to_state(struct mtd_info *mtd)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
-   struct spinand_info *info = (struct spinand_info *)chip->priv;
+   struct spinand_info *info = (struct spinand_info 
*)nand_get_controller_data(chip);
struct spinand_state *state = (struct spinand_state *)info->priv;
 
return state;
@@ -633,7 +633,7 @@ static int spinand_read_page_hwecc(struct mtd_info *mtd, 
struct nand_chip *chip,
u8 *p = buf;
int eccsize = chip->ecc.size;
int eccsteps = chip->ecc.steps;
-   struct spinand_info *info = (struct spinand_info *)chip->priv;
+   struct spinand_info *info = (struct spinand_info 
*)nand_get_controller_data(chip);
 
enable_read_hw_ecc = 1;
 
@@ -679,7 +679,7 @@ static u8 spinand_read_byte(struct mtd_info *mtd)
 
 static int spinand_wait(struct mtd_info *mtd, struct nand_chip *chip)
 {
-   struct spinand_info *info = (struct spinand_info *)chip->priv;
+   struct spinand_info *info = (struct spinand_info 
*)nand_get_controller_data(chip);
 
unsigned long timeo = jiffies;
int retval, state = chip->state;
@@ -745,7 +745,7 @@ static void spinand_cmdfunc(struct mtd_info *mtd, unsigned 
int command,
int column, int page)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
-   struct spinand_info *info = (struct spinand_info *)chip->priv;
+   struct spinand_info *info = (struct spinand_info 
*)nand_get_controller_data(chip);
struct spinand_state *state = (struct spinand_state *)info->priv;
 
switch (command) {
@@ -894,7 +894,7 @@ static int spinand_probe(struct spi_device *spi_nand)
 #endif
 
nand_set_flash_node(chip, spi_nand->dev.of_node);
-   chip->priv  = info;
+   nand_set_controller_data(chip, info);
chip->read_buf  = spinand_read_buf;
chip->write_buf = spinand_write_buf;
chip->read_byte = spinand_read_byte;
-- 
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 18/27] mtd: nand: update mtd_to_nand()

[Boris Brezillon]

Now that all drivers are using the mtd instance embedded in the nand_chip
struct we can safely update the mtd_to_nand_chip() implementation to use
the container_of macro instead of returning the content of mtd->priv.
This will allow us to remove mtd->priv = chip assignments done in all
NAND controller drivers.

Signed-off-by: Boris Brezillon 
---
 include/linux/mtd/nand.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 8ec071e..873646d 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -734,7 +734,7 @@ static inline struct device_node 
*nand_get_flash_node(struct nand_chip *chip)
 
 static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
 {
-   return mtd->priv;
+   return container_of(mtd, struct nand_chip, mtd);
 }
 
 static inline struct mtd_info *nand_to_mtd(struct nand_chip *chip)
-- 
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 07/27] mips: nand: make use of mtd_to_nand() where appropriate

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Update all MIPS specific implementations to use this
helper.

Signed-off-by: Boris Brezillon 
---
 arch/mips/alchemy/devboards/db1200.c | 2 +-
 arch/mips/alchemy/devboards/db1300.c | 2 +-
 arch/mips/alchemy/devboards/db1550.c | 2 +-
 arch/mips/pnx833x/common/platform.c  | 2 +-
 arch/mips/rb532/devices.c| 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/mips/alchemy/devboards/db1200.c 
b/arch/mips/alchemy/devboards/db1200.c
index 8c13675..992442a 100644
--- a/arch/mips/alchemy/devboards/db1200.c
+++ b/arch/mips/alchemy/devboards/db1200.c
@@ -200,7 +200,7 @@ static struct i2c_board_info db1200_i2c_devs[] __initdata = 
{
 static void au1200_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
 unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
unsigned long ioaddr = (unsigned long)this->IO_ADDR_W;
 
ioaddr &= 0xff00;
diff --git a/arch/mips/alchemy/devboards/db1300.c 
b/arch/mips/alchemy/devboards/db1300.c
index b580770..d3c087f 100644
--- a/arch/mips/alchemy/devboards/db1300.c
+++ b/arch/mips/alchemy/devboards/db1300.c
@@ -150,7 +150,7 @@ static void __init db1300_gpio_config(void)
 static void au1300_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
 unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
unsigned long ioaddr = (unsigned long)this->IO_ADDR_W;
 
ioaddr &= 0xff00;
diff --git a/arch/mips/alchemy/devboards/db1550.c 
b/arch/mips/alchemy/devboards/db1550.c
index 5740bcf..b518f02 100644
--- a/arch/mips/alchemy/devboards/db1550.c
+++ b/arch/mips/alchemy/devboards/db1550.c
@@ -128,7 +128,7 @@ static struct i2c_board_info db1550_i2c_devs[] __initdata = 
{
 static void au1550_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
 unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
unsigned long ioaddr = (unsigned long)this->IO_ADDR_W;
 
ioaddr &= 0xff00;
diff --git a/arch/mips/pnx833x/common/platform.c 
b/arch/mips/pnx833x/common/platform.c
index b4b774b..3cd3577 100644
--- a/arch/mips/pnx833x/common/platform.c
+++ b/arch/mips/pnx833x/common/platform.c
@@ -180,7 +180,7 @@ static struct platform_device pnx833x_sata_device = {
 static void
 pnx833x_flash_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
unsigned long nandaddr = (unsigned long)this->IO_ADDR_W;
 
if (cmd == NAND_CMD_NONE)
diff --git a/arch/mips/rb532/devices.c b/arch/mips/rb532/devices.c
index 9bd7a2d..0966adc 100644
--- a/arch/mips/rb532/devices.c
+++ b/arch/mips/rb532/devices.c
@@ -148,7 +148,7 @@ static int rb532_dev_ready(struct mtd_info *mtd)
 
 static void rb532_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
unsigned char orbits, nandbits;
 
if (ctrl & NAND_CTRL_CHANGE) {
-- 
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 24/27] mtd: nand: add helpers to access ->priv

[Boris Brezillon]

Add two helpers to access the field reserved for private controller data.
This makes it clearer what this field is reserved for and ease future
refactoring.

Signed-off-by: Boris Brezillon 
---
 include/linux/mtd/nand.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index f12efe1..4afa263 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -739,6 +739,16 @@ static inline struct mtd_info *nand_to_mtd(struct 
nand_chip *chip)
return >mtd;
 }
 
+static inline void *nand_get_controller_data(struct nand_chip *chip)
+{
+   return chip->priv;
+}
+
+static inline void nand_set_controller_data(struct nand_chip *chip, void *priv)
+{
+   chip->priv = priv;
+}
+
 /*
  * NAND Flash Manufacturer ID Codes
  */
-- 
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 17/27] cris: nand: use the mtd instance embedded in struct nand_chip

[Boris Brezillon]

struct nand_chip now embeds an mtd device. Patch all drivers to make use
of this mtd instance instead of using the instance embedded in their
private struct or dynamically allocated.

Signed-off-by: Boris Brezillon 
---
Most of those changes were generate with this coccinelle script:
http://code.bulix.org/5vxuih-89429
---
 arch/cris/arch-v32/drivers/mach-a3/nandflash.c | 3 +--
 arch/cris/arch-v32/drivers/mach-fs/nandflash.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
index db953cf..ad78b97 100644
--- a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
@@ -36,7 +36,6 @@
 #define CE_BIT 12
 
 struct mtd_info_wrapper {
-   struct mtd_info info;
struct nand_chip chip;
 };
 
@@ -148,7 +147,7 @@ struct mtd_info *__init crisv32_nand_flash_probe(void)
 
/* Get pointer to private data */
this = >chip;
-   crisv32_mtd = >info;
+   crisv32_mtd = nand_to_mtd(>chip);
 
/* Link the private data with the MTD structure */
crisv32_mtd->priv = this;
diff --git a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
index 22a6467..00a277b 100644
--- a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
@@ -31,7 +31,6 @@
 #define BY_BIT 7
 
 struct mtd_info_wrapper {
-   struct mtd_info info;
struct nand_chip chip;
 };
 
@@ -129,7 +128,7 @@ struct mtd_info *__init crisv32_nand_flash_probe(void)
 
/* Get pointer to private data */
this = >chip;
-   crisv32_mtd = >info;
+   crisv32_mtd = nand_to_mtd(>chip);
 
pa_oe.oe |= 1 << CE_BIT;
pa_oe.oe |= 1 << ALE_BIT;
-- 
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 15/27] mtd: nand: update the documentation to reflect framework changes

[Boris Brezillon]

The MTD device is now directly embedded in the nand_chip struct. Update the
mtdnand documentation to mention this aspect and fix the different
examples.

Signed-off-by: Boris Brezillon 
---
 Documentation/DocBook/mtdnand.tmpl | 31 +++
 1 file changed, 15 insertions(+), 16 deletions(-)

diff --git a/Documentation/DocBook/mtdnand.tmpl 
b/Documentation/DocBook/mtdnand.tmpl
index 403a7ab..b442921 100644
--- a/Documentation/DocBook/mtdnand.tmpl
+++ b/Documentation/DocBook/mtdnand.tmpl
@@ -162,12 +162,15 @@

Basic defines

-   At least you have to provide a mtd structure and
-   a storage for the ioremap'ed chip address.
-   You can allocate the mtd structure using kmalloc
-   or you can allocate it statically.
-   In case of static allocation you have to allocate
-   a nand_chip structure too.
+   At least you have to provide a nand_chip structure
+   and a storage for the ioremap'ed chip address.
+   You can allocate the nand_chip structure using
+   kmalloc or you can allocate it statically.
+   The NAND chip structure embeds an mtd structure
+   which will be registered to the MTD subsystem.
+   You can extract a pointer to the mtd structure
+   from a nand_chip pointer using the nand_to_mtd()
+   helper.


Kmalloc based example
@@ -180,7 +183,6 @@ static void __iomem *baseaddr;
Static example


-static struct mtd_info board_mtd;
 static struct nand_chip board_chip;
 static void __iomem *baseaddr;

@@ -274,13 +276,15 @@ static int __init board_init (void)
int err = 0;
 
/* Allocate memory for MTD device structure and private data */
-   board_mtd = kzalloc(sizeof(struct mtd_info) + sizeof(struct nand_chip), 
GFP_KERNEL);
-   if (!board_mtd) {
+   this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
+   if (!this) {
printk ("Unable to allocate NAND MTD device structure.\n");
err = -ENOMEM;
goto out;
}
 
+   board_mtd = nand_to_mtd(this);
+
/* map physical address */
baseaddr = ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
if (!baseaddr) {
@@ -289,11 +293,6 @@ static int __init board_init (void)
goto out_mtd;
}
 
-   /* Get pointer to private data */
-   this = (struct nand_chip *) ();
-   /* Link the private data with the MTD structure */
-   board_mtd->priv = this;
-
/* Set address of NAND IO lines */
this->IO_ADDR_R = baseaddr;
this->IO_ADDR_W = baseaddr;
@@ -317,7 +316,7 @@ static int __init board_init (void)
 out_ior:
iounmap(baseaddr);
 out_mtd:
-   kfree (board_mtd);
+   kfree (this);
 out:
return err;
 }
@@ -343,7 +342,7 @@ static void __exit board_cleanup (void)
iounmap(baseaddr);

/* Free the MTD device structure */
-   kfree (board_mtd);
+   kfree (mtd_to_nand(board_mtd));
 }
 module_exit(board_cleanup);
 #endif
-- 
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 14/27] mtd: nand: use the mtd instance embedded in struct nand_chip

[Boris Brezillon]

struct nand_chip now embeds an mtd device. Patch all drivers to make use
of this mtd instance instead of using the instance embedded in their
private struct or dynamically allocated.

Signed-off-by: Boris Brezillon 
Cc: Julia Lawall 
---
Most of those changes were generate with this coccinelle script:
http://code.bulix.org/5vxuih-89429
---
 drivers/mtd/nand/ams-delta.c   | 13 ++--
 drivers/mtd/nand/atmel_nand.c  | 11 ++-
 drivers/mtd/nand/au1550nd.c| 18 ++---
 drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h |  1 -
 drivers/mtd/nand/bcm47xxnflash/main.c  |  7 +-
 drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c   |  2 +-
 drivers/mtd/nand/bf5xx_nand.c  | 14 ++--
 drivers/mtd/nand/brcmnand/brcmnand.c   | 11 ++-
 drivers/mtd/nand/cafe_nand.c   | 10 +--
 drivers/mtd/nand/cmx270_nand.c | 11 ++-
 drivers/mtd/nand/cs553x_nand.c | 13 ++--
 drivers/mtd/nand/davinci_nand.c| 25 +++
 drivers/mtd/nand/denali.c  | 61 +
 drivers/mtd/nand/denali.h  |  1 -
 drivers/mtd/nand/diskonchip.c  | 11 ++-
 drivers/mtd/nand/docg4.c   | 18 +++--
 drivers/mtd/nand/fsl_elbc_nand.c   | 22 +++---
 drivers/mtd/nand/fsl_ifc_nand.c| 23 +++
 drivers/mtd/nand/fsl_upm.c | 26 +++
 drivers/mtd/nand/fsmc_nand.c   | 59 +---
 drivers/mtd/nand/gpio.c| 16 ++---
 drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  2 +-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 20 +++---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  1 -
 drivers/mtd/nand/hisi504_nand.c| 11 ++-
 drivers/mtd/nand/jz4740_nand.c |  9 ++-
 drivers/mtd/nand/lpc32xx_mlc.c |  7 +-
 drivers/mtd/nand/lpc32xx_slc.c |  7 +-
 drivers/mtd/nand/mpc5121_nfc.c |  3 +-
 drivers/mtd/nand/mxc_nand.c|  5 +-
 drivers/mtd/nand/nandsim.c | 12 ++--
 drivers/mtd/nand/ndfc.c| 22 +++---
 drivers/mtd/nand/nuc900_nand.c | 21 +++---
 drivers/mtd/nand/omap2.c   | 94 +++---
 drivers/mtd/nand/orion_nand.c  |  4 +-
 drivers/mtd/nand/pasemi_nand.c | 14 ++--
 drivers/mtd/nand/plat_nand.c   | 14 ++--
 drivers/mtd/nand/pxa3xx_nand.c | 33 -
 drivers/mtd/nand/r852.c| 34 --
 drivers/mtd/nand/r852.h|  1 -
 drivers/mtd/nand/s3c2410.c | 19 +++---
 drivers/mtd/nand/sh_flctl.c|  8 +--
 drivers/mtd/nand/sharpsl.c | 18 ++---
 drivers/mtd/nand/socrates_nand.c   |  5 +-
 drivers/mtd/nand/sunxi_nand.c  | 13 ++--
 drivers/mtd/nand/tmio_nand.c   |  7 +-
 drivers/mtd/nand/txx9ndfmc.c   |  3 +-
 drivers/mtd/nand/vf610_nfc.c   |  5 +-
 include/linux/mtd/sh_flctl.h   |  3 +-
 49 files changed, 383 insertions(+), 385 deletions(-)

diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index b2b49c4..0f638c6 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -183,19 +183,16 @@ static int ams_delta_init(struct platform_device *pdev)
return -ENXIO;
 
/* Allocate memory for MTD device structure and private data */
-   ams_delta_mtd = kzalloc(sizeof(struct mtd_info) +
-   sizeof(struct nand_chip), GFP_KERNEL);
-   if (!ams_delta_mtd) {
+   this = kzalloc(sizeof(struct nand_chip), GFP_KERNEL);
+   if (!this) {
printk (KERN_WARNING "Unable to allocate E3 NAND MTD device 
structure.\n");
err = -ENOMEM;
goto out;
}
 
+   ams_delta_mtd = nand_to_mtd(this);
ams_delta_mtd->owner = THIS_MODULE;
 
-   /* Get pointer to private data */
-   this = (struct nand_chip *) (_delta_mtd[1]);
-
/* Link the private data with the MTD structure */
ams_delta_mtd->priv = this;
 
@@ -256,7 +253,7 @@ out_gpio:
gpio_free(AMS_DELTA_GPIO_PIN_NAND_RB);
iounmap(io_base);
 out_free:
-   kfree(ams_delta_mtd);
+   kfree(this);
  out:
return err;
 }
@@ -276,7 +273,7 @@ static int ams_delta_cleanup(struct platform_device *pdev)
iounmap(io_base);
 
/* Free the MTD device structure */
-   kfree(ams_delta_mtd);
+   kfree(mtd_to_nand(ams_delta_mtd));
 
return 0;
 }
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index f8aac0a..51748b4 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ 

[linux-sunxi] [PATCH 16/27] staging: mt29f_spinand: use the mtd instance embedded in struct nand_chip

[Boris Brezillon]

struct nand_chip now embeds an mtd device, use it instead of allocating
a new one.

Signed-off-by: Boris Brezillon 
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c 
b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 8924a96..8171b74 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -903,9 +903,7 @@ static int spinand_probe(struct spi_device *spi_nand)
chip->options   |= NAND_CACHEPRG;
chip->select_chip = spinand_select_chip;
 
-   mtd = devm_kzalloc(_nand->dev, sizeof(struct mtd_info), GFP_KERNEL);
-   if (!mtd)
-   return -ENOMEM;
+   mtd = nand_to_mtd(chip);
 
dev_set_drvdata(_nand->dev, mtd);
 
-- 
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 22/27] mtd: nand: simplify nand_dt_init() usage

[Boris Brezillon]

nand_dt_init() function requires 3 arguments where it actually needs one
(dn and mtd can both be retrieved from chip). Drop these parameters.

Testing for dn != NULL inside nand_dt_init() also helps simplifying the
caller code.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/nand_base.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 71cc029..2f75eb1 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3937,11 +3937,17 @@ ident_done:
return type;
 }
 
-static int nand_dt_init(struct mtd_info *mtd, struct nand_chip *chip,
-   struct device_node *dn)
+static int nand_dt_init(struct nand_chip *chip)
 {
+   struct device_node *dn = nand_get_flash_node(chip);
int ecc_mode, ecc_strength, ecc_step;
 
+   if (!dn)
+   return 0;
+
+   /* MTD can automatically handle DT partitions, etc. */
+   mtd_set_of_node(nand_to_mtd(chip), dn);
+
if (of_get_nand_bus_width(dn) == 16)
chip->options |= NAND_BUSWIDTH_16;
 
@@ -3989,14 +3995,9 @@ int nand_scan_ident(struct mtd_info *mtd, int maxchips,
struct nand_flash_dev *type;
int ret;
 
-   if (nand_get_flash_node(chip)) {
-   /* MTD can automatically handle DT partitions, etc. */
-   mtd_set_of_node(mtd, nand_get_flash_node(chip));
-
-   ret = nand_dt_init(mtd, chip, nand_get_flash_node(chip));
-   if (ret)
-   return ret;
-   }
+   ret = nand_dt_init(chip);
+   if (ret)
+   return ret;
 
/* Set the default functions */
nand_set_defaults(chip, chip->options & NAND_BUSWIDTH_16);
-- 
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 26/27] mtd: nand: make use of nand_set/get_controller_data() helpers

[Boris Brezillon]

New helpers have been added to avoid directly accessing chip->field. Use
them where appropriate.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/ams-delta.c |  6 +--
 drivers/mtd/nand/atmel_nand.c| 54 ++---
 drivers/mtd/nand/bcm47xxnflash/main.c|  2 +-
 drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c | 16 +++
 drivers/mtd/nand/bf5xx_nand.c|  2 +-
 drivers/mtd/nand/brcmnand/brcmnand.c | 32 ++---
 drivers/mtd/nand/cafe_nand.c | 24 +-
 drivers/mtd/nand/diskonchip.c| 70 ++--
 drivers/mtd/nand/docg4.c | 42 -
 drivers/mtd/nand/fsl_elbc_nand.c | 22 -
 drivers/mtd/nand/fsl_ifc_nand.c  | 26 +--
 drivers/mtd/nand/fsmc_nand.c |  2 +-
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c   | 28 +--
 drivers/mtd/nand/hisi504_nand.c  | 20 
 drivers/mtd/nand/lpc32xx_mlc.c   | 18 +++
 drivers/mtd/nand/lpc32xx_slc.c   | 20 
 drivers/mtd/nand/mpc5121_nfc.c   | 24 +-
 drivers/mtd/nand/mxc_nand.c  | 36 +++---
 drivers/mtd/nand/nandsim.c   |  4 +-
 drivers/mtd/nand/ndfc.c  | 16 +++
 drivers/mtd/nand/orion_nand.c|  4 +-
 drivers/mtd/nand/plat_nand.c |  2 +-
 drivers/mtd/nand/pxa3xx_nand.c   | 22 -
 drivers/mtd/nand/r852.c  |  6 +--
 drivers/mtd/nand/s3c2410.c   |  4 +-
 drivers/mtd/nand/socrates_nand.c | 10 ++--
 drivers/mtd/nand/txx9ndfmc.c |  8 ++--
 27 files changed, 260 insertions(+), 260 deletions(-)

diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 1a18938..68b58c8 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -65,7 +65,7 @@ static struct mtd_partition partition_info[] = {
 static void ams_delta_write_byte(struct mtd_info *mtd, u_char byte)
 {
struct nand_chip *this = mtd_to_nand(mtd);
-   void __iomem *io_base = this->priv;
+   void __iomem *io_base = (void __iomem *)nand_get_controller_data(this);
 
writew(0, io_base + OMAP_MPUIO_IO_CNTL);
writew(byte, this->IO_ADDR_W);
@@ -78,7 +78,7 @@ static u_char ams_delta_read_byte(struct mtd_info *mtd)
 {
u_char res;
struct nand_chip *this = mtd_to_nand(mtd);
-   void __iomem *io_base = this->priv;
+   void __iomem *io_base = (void __iomem *)nand_get_controller_data(this);
 
gpio_set_value(AMS_DELTA_GPIO_PIN_NAND_NRE, 0);
ndelay(40);
@@ -206,7 +206,7 @@ static int ams_delta_init(struct platform_device *pdev)
goto out_free;
}
 
-   this->priv = io_base;
+   nand_set_controller_data(this, (void *)io_base);
 
/* Set address of NAND IO lines */
this->IO_ADDR_R = io_base + OMAP_MPUIO_INPUT_LATCH;
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index aef02d3..769ad8b 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -182,7 +182,7 @@ static void atmel_nand_disable(struct atmel_nand_host *host)
 static void atmel_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int 
ctrl)
 {
struct nand_chip *nand_chip = mtd_to_nand(mtd);
-   struct atmel_nand_host *host = nand_chip->priv;
+   struct atmel_nand_host *host = nand_get_controller_data(nand_chip);
 
if (ctrl & NAND_CTRL_CHANGE) {
if (ctrl & NAND_NCE)
@@ -205,7 +205,7 @@ static void atmel_nand_cmd_ctrl(struct mtd_info *mtd, int 
cmd, unsigned int ctrl
 static int atmel_nand_device_ready(struct mtd_info *mtd)
 {
struct nand_chip *nand_chip = mtd_to_nand(mtd);
-   struct atmel_nand_host *host = nand_chip->priv;
+   struct atmel_nand_host *host = nand_get_controller_data(nand_chip);
 
return gpio_get_value(host->board.rdy_pin) ^
 !!host->board.rdy_pin_active_low;
@@ -215,7 +215,7 @@ static int atmel_nand_device_ready(struct mtd_info *mtd)
 static int atmel_nand_set_enable_ready_pins(struct mtd_info *mtd)
 {
struct nand_chip *chip = mtd_to_nand(mtd);
-   struct atmel_nand_host *host = chip->priv;
+   struct atmel_nand_host *host = nand_get_controller_data(chip);
int res = 0;
 
if (gpio_is_valid(host->board.rdy_pin)) {
@@ -267,7 +267,7 @@ static int atmel_nand_set_enable_ready_pins(struct mtd_info 
*mtd)
 static void atmel_read_buf8(struct mtd_info *mtd, u8 *buf, int len)
 {
struct nand_chip*nand_chip = mtd_to_nand(mtd);
-   struct atmel_nand_host *host = nand_chip->priv;
+   struct atmel_nand_host *host = nand_get_controller_data(nand_chip);
 
if (host->nfc && host->nfc->use_nfc_sram && host->nfc->data_in_sram) {

[linux-sunxi] [PATCH 12/27] mtd: nand: embed an mtd_info structure into nand_chip

[Boris Brezillon]

Currently all NAND controller drivers are providing both the mtd_info and
nand_chip struct and then let the NAND subsystem to initialize a few
things before registering the mtd instance to the MTD layer.
Embed an mtd_info field into nand_chip to add some consistency to all NAND
controller drivers.
This change will also help factorizing boilerplate code copied in all NAND
drivers.

Signed-off-by: Boris Brezillon 
---
 include/linux/mtd/nand.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 056d165..c4e39ff 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -540,6 +540,7 @@ struct nand_buffers {
 
 /**
  * struct nand_chip - NAND Private Flash Chip Data
+ * @mtd:   MTD device registered to the MTD framework
  * @IO_ADDR_R: [BOARDSPECIFIC] address to read the 8 I/O lines of the
  * flash device
  * @IO_ADDR_W: [BOARDSPECIFIC] address to write the 8 I/O lines of the
@@ -640,6 +641,7 @@ struct nand_buffers {
  */
 
 struct nand_chip {
+   struct mtd_info mtd;
void __iomem *IO_ADDR_R;
void __iomem *IO_ADDR_W;
 
-- 
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 10/27] mtd: nand: make use of mtd_to_nand() in NAND drivers

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Update all NAND drivers to use it.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/ams-delta.c |  4 +-
 drivers/mtd/nand/atmel_nand.c| 50 ++---
 drivers/mtd/nand/au1550nd.c  | 22 +-
 drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c | 16 +++
 drivers/mtd/nand/bf5xx_nand.c| 12 ++---
 drivers/mtd/nand/brcmnand/brcmnand.c | 10 ++---
 drivers/mtd/nand/cafe_nand.c | 18 
 drivers/mtd/nand/cmx270_nand.c   |  8 ++--
 drivers/mtd/nand/cs553x_nand.c   | 16 +++
 drivers/mtd/nand/davinci_nand.c  |  8 ++--
 drivers/mtd/nand/diskonchip.c| 66 ++--
 drivers/mtd/nand/docg4.c | 34 +++---
 drivers/mtd/nand/fsl_elbc_nand.c | 14 +++---
 drivers/mtd/nand/fsl_ifc_nand.c  | 18 
 drivers/mtd/nand/fsl_upm.c   |  4 +-
 drivers/mtd/nand/fsmc_nand.c | 10 ++---
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c   | 18 
 drivers/mtd/nand/hisi504_nand.c  | 16 +++
 drivers/mtd/nand/jz4740_nand.c   |  4 +-
 drivers/mtd/nand/lpc32xx_mlc.c   |  6 +--
 drivers/mtd/nand/lpc32xx_slc.c   | 14 +++---
 drivers/mtd/nand/mpc5121_nfc.c   | 24 +-
 drivers/mtd/nand/mxc_nand.c  | 34 +++---
 drivers/mtd/nand/ndfc.c  | 14 +++---
 drivers/mtd/nand/nuc900_nand.c   |  2 +-
 drivers/mtd/nand/omap2.c | 12 ++---
 drivers/mtd/nand/orion_nand.c|  4 +-
 drivers/mtd/nand/pasemi_nand.c   |  6 +--
 drivers/mtd/nand/pxa3xx_nand.c   | 20 -
 drivers/mtd/nand/r852.c  |  2 +-
 drivers/mtd/nand/s3c2410.c   |  6 +--
 drivers/mtd/nand/sharpsl.c   |  2 +-
 drivers/mtd/nand/sm_common.c |  2 +-
 drivers/mtd/nand/socrates_nand.c |  8 ++--
 drivers/mtd/nand/sunxi_nand.c| 26 +--
 drivers/mtd/nand/tmio_nand.c |  2 +-
 drivers/mtd/nand/txx9ndfmc.c | 12 ++---
 drivers/mtd/nand/xway_nand.c |  4 +-
 38 files changed, 274 insertions(+), 274 deletions(-)

diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 842f8fe..b2b49c4 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -64,7 +64,7 @@ static struct mtd_partition partition_info[] = {
 
 static void ams_delta_write_byte(struct mtd_info *mtd, u_char byte)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
void __iomem *io_base = this->priv;
 
writew(0, io_base + OMAP_MPUIO_IO_CNTL);
@@ -77,7 +77,7 @@ static void ams_delta_write_byte(struct mtd_info *mtd, u_char 
byte)
 static u_char ams_delta_read_byte(struct mtd_info *mtd)
 {
u_char res;
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
void __iomem *io_base = this->priv;
 
gpio_set_value(AMS_DELTA_GPIO_PIN_NAND_NRE, 0);
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 6ecc1c1..f8aac0a 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -182,7 +182,7 @@ static void atmel_nand_disable(struct atmel_nand_host *host)
  */
 static void atmel_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int 
ctrl)
 {
-   struct nand_chip *nand_chip = mtd->priv;
+   struct nand_chip *nand_chip = mtd_to_nand(mtd);
struct atmel_nand_host *host = nand_chip->priv;
 
if (ctrl & NAND_CTRL_CHANGE) {
@@ -205,7 +205,7 @@ static void atmel_nand_cmd_ctrl(struct mtd_info *mtd, int 
cmd, unsigned int ctrl
  */
 static int atmel_nand_device_ready(struct mtd_info *mtd)
 {
-   struct nand_chip *nand_chip = mtd->priv;
+   struct nand_chip *nand_chip = mtd_to_nand(mtd);
struct atmel_nand_host *host = nand_chip->priv;
 
return gpio_get_value(host->board.rdy_pin) ^
@@ -215,7 +215,7 @@ static int atmel_nand_device_ready(struct mtd_info *mtd)
 /* Set up for hardware ready pin and enable pin. */
 static int atmel_nand_set_enable_ready_pins(struct mtd_info *mtd)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
struct atmel_nand_host *host = chip->priv;
int res = 0;
 
@@ -267,7 +267,7 @@ static int atmel_nand_set_enable_ready_pins(struct mtd_info 
*mtd)
  */
 static void atmel_read_buf8(struct mtd_info *mtd, u8 *buf, int len)
 {
-   struct nand_chip*nand_chip = mtd->priv;
+   struct nand_chip*nand_chip = mtd_to_nand(mtd);
struct atmel_nand_host *host = nand_chip->priv;
 
if 

[linux-sunxi] [PATCH 20/27] cris: nand: remove useless mtd->priv = chip assignments

[Boris Brezillon]

mtd_to_nand_chip() now uses the container_of() approach to transform an
mtd_info pointer into a nand_chip one. Drop useless mtd->priv
assignments from NAND controller drivers.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

---8<
virtual patch

@@
struct mtd_info mtd;
struct mtd_info *mtdptr;
struct nand_chip *chipptr;
expression d;
@@
(
-(mtd).priv = (chipptr);
|
-(mtdptr)->priv = (chipptr);
---8<
---
 arch/cris/arch-v32/drivers/mach-a3/nandflash.c | 3 ---
 arch/cris/arch-v32/drivers/mach-fs/nandflash.c | 3 ---
 2 files changed, 6 deletions(-)

diff --git a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
index ad78b97..2f65261 100644
--- a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
@@ -149,9 +149,6 @@ struct mtd_info *__init crisv32_nand_flash_probe(void)
this = >chip;
crisv32_mtd = nand_to_mtd(>chip);
 
-   /* Link the private data with the MTD structure */
-   crisv32_mtd->priv = this;
-
/* Set address of NAND IO lines */
this->IO_ADDR_R = read_cs;
this->IO_ADDR_W = write_cs;
diff --git a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
index 00a277b..4ab9d4e 100644
--- a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
@@ -140,9 +140,6 @@ struct mtd_info *__init crisv32_nand_flash_probe(void)
bif_cfg.gated_csp1 = regk_bif_core_wr;
REG_WR(bif_core, regi_bif_core, rw_grp3_cfg, bif_cfg);
 
-   /* Link the private data with the MTD structure */
-   crisv32_mtd->priv = this;
-
/* Set address of NAND IO lines */
this->IO_ADDR_R = read_cs;
this->IO_ADDR_W = write_cs;
-- 
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 09/27] mtd: nand: make use of mtd_to_nand() in NAND core code

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct access to the
mtd->priv field. Update core code to use mtd_to_nand().

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/nand_base.c | 84 ++--
 drivers/mtd/nand/nand_bbt.c  | 32 -
 drivers/mtd/nand/nand_bch.c  |  4 +--
 drivers/mtd/nand/nand_ecc.c  |  4 +--
 drivers/mtd/nand/nandsim.c   | 18 +-
 5 files changed, 71 insertions(+), 71 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 4ac4efe..71cc029 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -106,7 +106,7 @@ DEFINE_LED_TRIGGER(nand_led_trigger);
 static int check_offs_len(struct mtd_info *mtd,
loff_t ofs, uint64_t len)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
int ret = 0;
 
/* Start address must align on block boundary */
@@ -132,7 +132,7 @@ static int check_offs_len(struct mtd_info *mtd,
  */
 static void nand_release_device(struct mtd_info *mtd)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
 
/* Release the controller and the chip */
spin_lock(>controller->lock);
@@ -150,7 +150,7 @@ static void nand_release_device(struct mtd_info *mtd)
  */
 static uint8_t nand_read_byte(struct mtd_info *mtd)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
return readb(chip->IO_ADDR_R);
 }
 
@@ -163,7 +163,7 @@ static uint8_t nand_read_byte(struct mtd_info *mtd)
  */
 static uint8_t nand_read_byte16(struct mtd_info *mtd)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
return (uint8_t) cpu_to_le16(readw(chip->IO_ADDR_R));
 }
 
@@ -175,7 +175,7 @@ static uint8_t nand_read_byte16(struct mtd_info *mtd)
  */
 static u16 nand_read_word(struct mtd_info *mtd)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
return readw(chip->IO_ADDR_R);
 }
 
@@ -188,7 +188,7 @@ static u16 nand_read_word(struct mtd_info *mtd)
  */
 static void nand_select_chip(struct mtd_info *mtd, int chipnr)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
 
switch (chipnr) {
case -1:
@@ -211,7 +211,7 @@ static void nand_select_chip(struct mtd_info *mtd, int 
chipnr)
  */
 static void nand_write_byte(struct mtd_info *mtd, uint8_t byte)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
 
chip->write_buf(mtd, , 1);
 }
@@ -225,7 +225,7 @@ static void nand_write_byte(struct mtd_info *mtd, uint8_t 
byte)
  */
 static void nand_write_byte16(struct mtd_info *mtd, uint8_t byte)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
uint16_t word = byte;
 
/*
@@ -257,7 +257,7 @@ static void nand_write_byte16(struct mtd_info *mtd, uint8_t 
byte)
  */
 static void nand_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
 
iowrite8_rep(chip->IO_ADDR_W, buf, len);
 }
@@ -272,7 +272,7 @@ static void nand_write_buf(struct mtd_info *mtd, const 
uint8_t *buf, int len)
  */
 static void nand_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
 
ioread8_rep(chip->IO_ADDR_R, buf, len);
 }
@@ -287,7 +287,7 @@ static void nand_read_buf(struct mtd_info *mtd, uint8_t 
*buf, int len)
  */
 static void nand_write_buf16(struct mtd_info *mtd, const uint8_t *buf, int len)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
u16 *p = (u16 *) buf;
 
iowrite16_rep(chip->IO_ADDR_W, p, len >> 1);
@@ -303,7 +303,7 @@ static void nand_write_buf16(struct mtd_info *mtd, const 
uint8_t *buf, int len)
  */
 static void nand_read_buf16(struct mtd_info *mtd, uint8_t *buf, int len)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
u16 *p = (u16 *) buf;
 
ioread16_rep(chip->IO_ADDR_R, p, len >> 1);
@@ -320,7 +320,7 @@ static void nand_read_buf16(struct mtd_info *mtd, uint8_t 
*buf, int len)
 static int nand_block_bad(struct mtd_info *mtd, loff_t ofs, int getchip)
 {
int page, chipnr, res = 0, i = 0;
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
u16 bad;
 
if (chip->bbt_options & NAND_BBT_SCANLASTPAGE)
@@ -380,7 +380,7 @@ static int nand_block_bad(struct mtd_info *mtd, loff_t ofs, 
int getchip)
  */
 static int nand_default_block_markbad(struct mtd_info *mtd, loff_t ofs)
 {
-   

[linux-sunxi] [PATCH 23/27] mtd: nand: kill the chip->flash_node field

[Boris Brezillon]

Now that the nand_chip struct directly embeds an mtd_info struct we can
get rid of the ->flash_node field and forward set/get_flash_node requests
to the MTD layer.

As a side effect, we no longer need the mtd_set_of_node() call done in
nand_dt_init().

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/nand_base.c | 3 ---
 include/linux/mtd/nand.h | 7 ++-
 2 files changed, 2 insertions(+), 8 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 2f75eb1..78e5123 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -3945,9 +3945,6 @@ static int nand_dt_init(struct nand_chip *chip)
if (!dn)
return 0;
 
-   /* MTD can automatically handle DT partitions, etc. */
-   mtd_set_of_node(nand_to_mtd(chip), dn);
-
if (of_get_nand_bus_width(dn) == 16)
chip->options |= NAND_BUSWIDTH_16;
 
diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 873646d..f12efe1 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -545,7 +545,6 @@ struct nand_buffers {
  * flash device
  * @IO_ADDR_W: [BOARDSPECIFIC] address to write the 8 I/O lines of the
  * flash device.
- * @flash_node:[BOARDSPECIFIC] device node describing this 
instance
  * @read_byte: [REPLACEABLE] read one byte from the chip
  * @read_word: [REPLACEABLE] read one word from the chip
  * @write_byte:[REPLACEABLE] write a single byte to the chip 
on the
@@ -645,8 +644,6 @@ struct nand_chip {
void __iomem *IO_ADDR_R;
void __iomem *IO_ADDR_W;
 
-   struct device_node *flash_node;
-
uint8_t (*read_byte)(struct mtd_info *mtd);
u16 (*read_word)(struct mtd_info *mtd);
void (*write_byte)(struct mtd_info *mtd, uint8_t byte);
@@ -724,12 +721,12 @@ struct nand_chip {
 static inline void nand_set_flash_node(struct nand_chip *chip,
   struct device_node *np)
 {
-   chip->flash_node = np;
+   mtd_set_of_node(>mtd, np);
 }
 
 static inline struct device_node *nand_get_flash_node(struct nand_chip *chip)
 {
-   return chip->flash_node;
+   return mtd_get_of_node(>mtd);
 }
 
 static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
-- 
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 19/27] mtd: nand: remove useless mtd->priv = chip assignments

[Boris Brezillon]

mtd_to_nand_chip() now uses the container_of() approach to transform an
mtd_info pointer into a nand_chip one. Drop useless mtd->priv
assignments from NAND controller drivers.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

---8<
virtual patch

@@
struct mtd_info mtd;
struct mtd_info *mtdptr;
struct nand_chip *chipptr;
expression d;
@@
(
-(mtd).priv = (chipptr);
|
-(mtdptr)->priv = (chipptr);
---8<
---
 drivers/mtd/nand/ams-delta.c   | 3 ---
 drivers/mtd/nand/atmel_nand.c  | 1 -
 drivers/mtd/nand/bf5xx_nand.c  | 1 -
 drivers/mtd/nand/brcmnand/brcmnand.c   | 1 -
 drivers/mtd/nand/cafe_nand.c   | 1 -
 drivers/mtd/nand/cmx270_nand.c | 1 -
 drivers/mtd/nand/cs553x_nand.c | 1 -
 drivers/mtd/nand/diskonchip.c  | 1 -
 drivers/mtd/nand/docg4.c   | 1 -
 drivers/mtd/nand/fsmc_nand.c   | 1 -
 drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 1 -
 drivers/mtd/nand/hisi504_nand.c| 1 -
 drivers/mtd/nand/jz4740_nand.c | 1 -
 drivers/mtd/nand/lpc32xx_mlc.c | 1 -
 drivers/mtd/nand/lpc32xx_slc.c | 1 -
 drivers/mtd/nand/mpc5121_nfc.c | 1 -
 drivers/mtd/nand/mxc_nand.c| 1 -
 drivers/mtd/nand/omap2.c   | 1 -
 drivers/mtd/nand/orion_nand.c  | 1 -
 drivers/mtd/nand/pasemi_nand.c | 1 -
 drivers/mtd/nand/pxa3xx_nand.c | 1 -
 drivers/mtd/nand/r852.c| 1 -
 drivers/mtd/nand/sh_flctl.c| 1 -
 drivers/mtd/nand/socrates_nand.c   | 1 -
 drivers/mtd/nand/sunxi_nand.c  | 1 -
 drivers/mtd/nand/tmio_nand.c   | 1 -
 drivers/mtd/nand/txx9ndfmc.c   | 2 --
 drivers/mtd/nand/vf610_nfc.c   | 1 -
 28 files changed, 31 deletions(-)

diff --git a/drivers/mtd/nand/ams-delta.c b/drivers/mtd/nand/ams-delta.c
index 0f638c6..1a18938 100644
--- a/drivers/mtd/nand/ams-delta.c
+++ b/drivers/mtd/nand/ams-delta.c
@@ -193,9 +193,6 @@ static int ams_delta_init(struct platform_device *pdev)
ams_delta_mtd = nand_to_mtd(this);
ams_delta_mtd->owner = THIS_MODULE;
 
-   /* Link the private data with the MTD structure */
-   ams_delta_mtd->priv = this;
-
/*
 * Don't try to request the memory region from here,
 * it should have been already requested from the
diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
index 51748b4..aef02d3 100644
--- a/drivers/mtd/nand/atmel_nand.c
+++ b/drivers/mtd/nand/atmel_nand.c
@@ -2126,7 +2126,6 @@ static int atmel_nand_probe(struct platform_device *pdev)
}
 
nand_chip->priv = host; /* link the private data structures */
-   mtd->priv = nand_chip;
mtd->dev.parent = >dev;
 
/* Set address of NAND IO lines */
diff --git a/drivers/mtd/nand/bf5xx_nand.c b/drivers/mtd/nand/bf5xx_nand.c
index 671d983..77d3b11 100644
--- a/drivers/mtd/nand/bf5xx_nand.c
+++ b/drivers/mtd/nand/bf5xx_nand.c
@@ -782,7 +782,6 @@ static int bf5xx_nand_probe(struct platform_device *pdev)
 
/* initialise mtd info data struct */
mtd = nand_to_mtd(>chip);
-   mtd->priv   = chip;
mtd->dev.parent = >dev;
 
/* initialise the hardware */
diff --git a/drivers/mtd/nand/brcmnand/brcmnand.c 
b/drivers/mtd/nand/brcmnand/brcmnand.c
index 20ebf00..a124147 100644
--- a/drivers/mtd/nand/brcmnand/brcmnand.c
+++ b/drivers/mtd/nand/brcmnand/brcmnand.c
@@ -1925,7 +1925,6 @@ static int brcmnand_init_cs(struct brcmnand_host *host)
 
nand_set_flash_node(chip, dn);
chip->priv = host;
-   mtd->priv = chip;
mtd->name = devm_kasprintf(>dev, GFP_KERNEL, "brcmnand.%d",
   host->cs);
mtd->owner = THIS_MODULE;
diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index 1d3a66c..096917a 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -611,7 +611,6 @@ static int cafe_nand_probe(struct pci_dev *pdev,
 
mtd = nand_to_mtd(>nand);
mtd->dev.parent = >dev;
-   mtd->priv = >nand;
 
cafe->nand.priv = cafe;
cafe->pdev = pdev;
diff --git a/drivers/mtd/nand/cmx270_nand.c b/drivers/mtd/nand/cmx270_nand.c
index 84d027e..ca1f9b6 100644
--- a/drivers/mtd/nand/cmx270_nand.c
+++ b/drivers/mtd/nand/cmx270_nand.c
@@ -177,7 +177,6 @@ static int __init cmx270_init(void)
 
/* Link the private data with the MTD structure */
cmx270_nand_mtd->owner = THIS_MODULE;
-   cmx270_nand_mtd->priv = this;
 
/* insert callbacks */
this->IO_ADDR_R = cmx270_nand_io;
diff --git a/drivers/mtd/nand/cs553x_nand.c b/drivers/mtd/nand/cs553x_nand.c
index ea51a9c..3a691d9 100644
--- a/drivers/mtd/nand/cs553x_nand.c
+++ b/drivers/mtd/nand/cs553x_nand.c
@@ -206,7 +206,6 @@ static int __init cs553x_init_one(int cs, int mmio, 
unsigned long adr)
new_mtd = nand_to_mtd(this);
 
/* 

[linux-sunxi] [PATCH 13/27] mtd: nand: add nand_to_mtd() helper

[Boris Brezillon]

Add a new helper to retrieve the MTD device attached to a NAND chip.

Signed-off-by: Boris Brezillon 
---
 include/linux/mtd/nand.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index c4e39ff..8ec071e 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -737,6 +737,11 @@ static inline struct nand_chip *mtd_to_nand(struct 
mtd_info *mtd)
return mtd->priv;
 }
 
+static inline struct mtd_info *nand_to_mtd(struct nand_chip *chip)
+{
+   return >mtd;
+}
+
 /*
  * NAND Flash Manufacturer ID Codes
  */
-- 
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 11/27] staging: mt29f_spinand: make use of mtd_to_nand()

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Use it where appropriate.

Signed-off-by: Boris Brezillon 
---
 drivers/staging/mt29f_spinand/mt29f_spinand.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c 
b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 6536066..8924a96 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -31,7 +31,7 @@
 
 static inline struct spinand_state *mtd_to_state(struct mtd_info *mtd)
 {
-   struct nand_chip *chip = (struct nand_chip *)mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
struct spinand_info *info = (struct spinand_info *)chip->priv;
struct spinand_state *state = (struct spinand_state *)info->priv;
 
@@ -744,7 +744,7 @@ static void spinand_reset(struct spi_device *spi_nand)
 static void spinand_cmdfunc(struct mtd_info *mtd, unsigned int command,
int column, int page)
 {
-   struct nand_chip *chip = (struct nand_chip *)mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
struct spinand_info *info = (struct spinand_info *)chip->priv;
struct spinand_state *state = (struct spinand_state *)info->priv;
 
-- 
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 08/27] sh: nand: make use of mtd_to_nand() where appropriate

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Update all SH specific implementations to use this
helper.

Signed-off-by: Boris Brezillon 
---
 arch/sh/boards/mach-migor/setup.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/sh/boards/mach-migor/setup.c 
b/arch/sh/boards/mach-migor/setup.c
index 29b7c0d..8673f91 100644
--- a/arch/sh/boards/mach-migor/setup.c
+++ b/arch/sh/boards/mach-migor/setup.c
@@ -167,7 +167,7 @@ static struct mtd_partition migor_nand_flash_partitions[] = 
{
 static void migor_nand_flash_cmd_ctl(struct mtd_info *mtd, int cmd,
 unsigned int ctrl)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
 
if (cmd == NAND_CMD_NONE)
return;
-- 
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 06/27] cris: nand: make use of mtd_to_nand() where appropriate

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Update all CRIS specific implementations to use this
helper.

Signed-off-by: Boris Brezillon 
---
 arch/cris/arch-v32/drivers/mach-a3/nandflash.c | 2 +-
 arch/cris/arch-v32/drivers/mach-fs/nandflash.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
index 7fb5212..db953cf 100644
--- a/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-a3/nandflash.c
@@ -52,7 +52,7 @@ static void crisv32_hwcontrol(struct mtd_info *mtd, int cmd,
 {
unsigned long flags;
reg_pio_rw_dout dout;
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
 
local_irq_save(flags);
 
diff --git a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c 
b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
index e032384..22a6467 100644
--- a/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
+++ b/arch/cris/arch-v32/drivers/mach-fs/nandflash.c
@@ -51,7 +51,7 @@ static void crisv32_hwcontrol(struct mtd_info *mtd, int cmd,
 {
unsigned long flags;
reg_gio_rw_pa_dout dout;
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
 
local_irq_save(flags);
 
-- 
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] Re: [PATCH v4 05/24] misc: max77693-haptic: use pwm_get_xxx() helpers where appropriate

[Guenter Roeck]

On 11/16/2015 05:55 AM, Boris Brezillon wrote:

Hi Krzysztof,

On Mon, 16 Nov 2015 22:10:40 +0900
Krzysztof Kozlowski  wrote:


W dniu 16.11.2015 o 17:56, Boris Brezillon pisze:

Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
Doing that will ease adaptation of the PWM framework to support atomic
update.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

--->8---
virtual patch

@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity((p), e);
|
-(p)->polarity
+pwm_get_polarity((p))
|
-(p)->period = e;
+pwm_set_period((p), e);
|
-(p)->period
+pwm_get_period((p))
|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle((p), e);
|
-(p)->duty_cycle
+pwm_get_duty_cycle((p))
)
--->8---
---
  drivers/input/misc/max77693-haptic.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/max77693-haptic.c 
b/drivers/input/misc/max77693-haptic.c
index 6d96bff..a038fb3 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -70,10 +70,11 @@ struct max77693_haptic {

  static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
  {
-   int delta = (haptic->pwm_dev->period + haptic->pwm_duty) / 2;
+   int delta = (pwm_get_period((haptic->pwm_dev)) + haptic->pwm_duty) / 2;


Double parentheses over argument are not needed so just:
pwm_get_period(haptic->pwm_dev) + ...


Actually it was generated with coccinelle, hence I didn't fix existing
coding style issues, but I have no problem fixing them.


There was no existing coding style issue. Your coccinelle script introduces it.
You might want to consider updating your script and remove the unnecessary (( ))
from it.

Guenter


Thanks,

Boris



Beside that patch looks good, so with removing parentheses here and below:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof


int error;

-   error = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
+   error = pwm_config(haptic->pwm_dev, delta,
+  pwm_get_period((haptic->pwm_dev)));
if (error) {
dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
return error;
@@ -245,7 +246,7 @@ static int max77693_haptic_play_effect(struct input_dev 
*dev, void *data,
 * The formula to convert magnitude to pwm_duty as follows:
 * - pwm_duty = (magnitude * pwm_period) / MAX_MAGNITUDE(0x)
 */
-   period_mag_multi = (u64)haptic->pwm_dev->period * haptic->magnitude;
+   period_mag_multi = (u64)pwm_get_period((haptic->pwm_dev)) * 
haptic->magnitude;
haptic->pwm_duty = (unsigned int)(period_mag_multi >>
MAX_MAGNITUDE_SHIFT);










--
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] ehci-platform: Add support for controllers with multiple reset lines

[Alan Stern]

On Sun, 15 Nov 2015, Hans de Goede wrote:

> From: Reinder de Haan 
> 
> At least the EHCI found on the Allwinnner H3 SoC needs multiple reset
> lines, the controller will not initialize while the reset for its
> companion OHCI is still asserted, which means we need to de-assert
> 2 reset-controllers for this EHCI controller to work.

I assume that reset_control_deassert() is smart enough to maintain a 
count of de-assertions, and it doesn't actually turn on the reset line 
until the count drops to 0.  Right?

> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 

...

> @@ -229,18 +230,24 @@ static int ehci_platform_probe(struct platform_device 
> *dev)
>   break;
>   }
>   }
> - }
>  
> - priv->rst = devm_reset_control_get_optional(>dev, NULL);
> - if (IS_ERR(priv->rst)) {
> - err = PTR_ERR(priv->rst);
> - if (err == -EPROBE_DEFER)
> - goto err_put_clks;
> - priv->rst = NULL;
> - } else {
> - err = reset_control_deassert(priv->rst);
> - if (err)
> - goto err_put_clks;
> + for (rst = 0; rst < EHCI_MAX_RESETS; rst++) {

What happens on platforms that don't use OF?  Or if pdata is not equal
to _platform_defaults?  Can you guarantee that those platforms 
will never need to turn off a reset line?

> + priv->resets[rst] =
> + of_reset_control_get_by_index(dev->dev.of_node,
> +   rst);

The style used in this file is to indent continuation lines to 2 two 
stops, not to line things up with an open paren on the previous line.

The rest of the patch looks okay.

Alan Stern

[linux-sunxi] Re: Mainline mmc driver and RT_PREEMPT_FULL issue (4.0.5)

[ankurpawar19]

On Monday, June 29, 2015 at 12:39:37 AM UTC+5:30, carosso...@gmail.com wrote:
> Hello all,
> I'm trying to have a minimally functional mainline RT_PREEMPT_FULL on a 
> olinuxino-A10-lime. Unfortunately there is an issue with the mmc driver. (The 
> crash dump is at bottom). The driver seems to work in the RT_PREEMPT_BASE 
> mode. I've very little knowledge of kernel internals, but after some search 
> and tests I've understood that the problem arises because the 
> mmc_request_done call (which eventually ends up with a re-schedule) is made 
> from interrupt context, instead of from a threaded context. In the 
> linux-sunxi kernel, in fact, a tasklet is used. In the mainline, on top of 
> the sunxi_mmc_finalize_request there's a comment:
> * Called in interrupt context! */
> that makes me think of some issues related to interrupt/non interrupt context.
> What is the relation between mainline driver and linux-sunxi one? Who is the 
> person who wrote the mainline driver? Even without the RT_PREEMPT_FULL, 
> shouln't be the bottom-half run on a threaded context, to avoid latencies?
> Any idea on how to solve the problem, even in un unclean manner?
> Thank you!
> 
> 
> 
> 
> 
> Kernel with default sunxi configuration and RT Patch patch-4.0.5-rt4.patch
> 
> 4.191698] BUG: scheduling while atomic: mountkernfs.sh/94/0x00010001
> [4.191710] CPU: 0 PID: 94 Comm: mountkernfs.sh Not tainted 4.0.5-rt4 #2
> [4.191713] Hardware name: Allwinner A1X (Device Tree)
> [4.191751] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [4.191765] [] (show_stack) from [] 
> (dump_stack+0x80/0xd8)
> [4.191775] [] (dump_stack) from [] 
> (__schedule_bug+0x44/0x5c)
> [4.191785] [] (__schedule_bug) from [] 
> (__schedule+0x388/0x424)
> [4.191793] [] (__schedule) from [] 
> (schedule+0x40/0xdc)
> [4.191803] [] (schedule) from [] 
> (rt_spin_lock_slowlock+0x178/0x2cc)
> [4.191814] [] (rt_spin_lock_slowlock) from [] 
> (__wake_up+0x24/0x50)
> [4.191829] [] (__wake_up) from [] 
> (mmc_request_done+0x44/0x88)
> [4.191846] [] (mmc_request_done) from [] 
> (sunxi_mmc_irq+0x4e4/0x520)
> [4.191863] [] (sunxi_mmc_irq) from [] 
> (handle_irq_event_percpu+0x60/0x14c)
> [4.191875] [] (handle_irq_event_percpu) from [] 
> (handle_irq_event+0x78/0xac)
> [4.191885] [] (handle_irq_event) from [] 
> (handle_fasteoi_irq+0xa8/0x224)
> [4.191895] [] (handle_fasteoi_irq) from [] 
> (generic_handle_irq+0x20/0x30)
> [4.191906] [] (generic_handle_irq) from [] 
> (__handle_domain_irq+0x54/0xb4)
> [4.191915] [] (__handle_domain_irq) from [] 
> (sun4i_handle_irq+0x44/0x60)
> [4.191925] [] (sun4i_handle_irq) from [] 
> (__irq_svc+0x40/0x88)
> [4.191930] Exception stack(0xde81bda8 to 0xde81bdf0)
> [4.191938] bda0:   df8c8b40 df89cb50 0009  
>  df8c8000
> [4.191946] bdc0: b6fd1000 dffeb900 de828744 c04d02c4 0005f89c c0522180 
> b6fcfef8 de81bdf0
> [4.191951] bde0:  c01dbbfc 2113 
> [4.191965] [] (__irq_svc) from [] 
> (copy_page+0x3c/0x80)
> [4.192809] [ cut here ]
> [4.192831] WARNING: CPU: 0 PID: 94 at kernel/irq/handle.c:149 
> handle_irq_event_percpu+0x128/0x14c()
> [4.192841] irq 19 handler sunxi_mmc_irq+0x0/0x520 enabled interrupts
> [4.192851] CPU: 0 PID: 94 Comm: mountkernfs.sh Tainted: GW   
> 4.0.5-rt4 #2
> [4.192853] Hardware name: Allwinner A1X (Device Tree)
> [4.192869] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [4.192879] [] (show_stack) from [] 
> (dump_stack+0x80/0xd8)
> [4.192894] [] (dump_stack) from [] 
> (warn_slowpath_common+0x70/0xac)
> [4.192904] [] (warn_slowpath_common) from [] 
> (warn_slowpath_fmt+0x30/0x40)
> [4.192915] [] (warn_slowpath_fmt) from [] 
> (handle_irq_event_percpu+0x128/0x14c)
> [4.192926] [] (handle_irq_event_percpu) from [] 
> (handle_irq_event+0x78/0xac)
> [4.192937] [] (handle_irq_event) from [] 
> (handle_fasteoi_irq+0xa8/0x224)
> [4.192946] [] (handle_fasteoi_irq) from [] 
> (generic_handle_irq+0x20/0x30)
> [4.192957] [] (generic_handle_irq) from [] 
> (__handle_domain_irq+0x54/0xb4)
> [4.192966] [] (__handle_domain_irq) from [] 
> (sun4i_handle_irq+0x44/0x60)
> [4.192976] [] (sun4i_handle_irq) from [] 
> (__irq_svc+0x40/0x88)
> [4.192980] Exception stack(0xde81bda8 to 0xde81bdf0)
> [4.192987] bda0:   df8c8b40 df89cb50 0009  
>  df8c8000
> [4.192995] bdc0: b6fd1000 dffeb900 de828744 c04d02c4 0005f89c c0522180 
> b6fcfef8 de81bdf0
> [4.193000] bde0:  c01dbbfc 2113 
> [4.193011] [] (__irq_svc) from [] 
> (copy_page+0x3c/0x80)
> [4.193015] ---[ end trace 0002 ]---
> [4.224639] [ cut here ]

I was trying the mainline kernel 3.18.22 with rt patch 3.18.24-rt22 on 
A13-Olinuxino-Micro, and facing the same issue of crash during kernel startup.
I 

[linux-sunxi] Re: [PATCH v4 04/24] hwmon: pwm-fan: use pwm_get_xxx() helpers where appropriate

[Boris Brezillon]

On Mon, 16 Nov 2015 07:59:23 -0800
Guenter Roeck  wrote:

> On 11/16/2015 12:56 AM, Boris Brezillon wrote:
> > Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
> > Doing that will ease adaptation of the PWM framework to support atomic
> > update.
> >
> > Signed-off-by: Boris Brezillon 
> > ---
> > Patch generated with the following coccinelle script:
> >
> > --->8---
> > virtual patch
> >
> > @@
> > struct pwm_device *p;
> > expression e;
> > @@
> > (
> > -(p)->polarity = e;
> > +pwm_set_polarity((p), e);
> > |
> > -(p)->polarity
> > +pwm_get_polarity((p))
> 
> s/((p))/(p)/
> 
> > |
> > -(p)->period = e;
> > +pwm_set_period((p), e);
> > |
> > -(p)->period
> > +pwm_get_period((p))
> 
> s/((p))/(p)/
> 
> > |
> > -(p)->duty_cycle = e;
> > +pwm_set_duty_cycle((p), e);
> 
> The (p) seems unnecessary here.

I don't get this one. You mean I should drop one the parenthesis around
p, right?




-- 
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 1/5] clk: sunxi: Add support for the H3 usb phy clocks

[Rob Herring]

On Sun, Nov 15, 2015 at 08:46:13PM +0100, Hans de Goede wrote:
> From: Reinder de Haan 
> 
> The H3 has a usb-phy clk register which is similar to that of earlier
> SoCs, but with support for a larger number of phys. So we can simply add
> a new set of clk-data and a new compatible and be done with it.
> 
> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 

Acked-by: Rob Herring 

> ---
>  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
>  drivers/clk/sunxi/clk-usb.c   | 12 
>  2 files changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> index d303dec..23e7bce 100644
> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> @@ -70,6 +70,7 @@ Required properties:
>   "allwinner,sun5i-a13-usb-clk" - for usb gates + resets on A13
>   "allwinner,sun6i-a31-usb-clk" - for usb gates + resets on A31
>   "allwinner,sun8i-a23-usb-clk" - for usb gates + resets on A23
> + "allwinner,sun8i-h3-usb-clk" - for usb gates + resets on H3
>   "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on A80
>   "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets on A80
>  
> diff --git a/drivers/clk/sunxi/clk-usb.c b/drivers/clk/sunxi/clk-usb.c
> index 1a72cd6..67b8e38 100644
> --- a/drivers/clk/sunxi/clk-usb.c
> +++ b/drivers/clk/sunxi/clk-usb.c
> @@ -243,3 +243,15 @@ static void __init sun9i_a80_usb_phy_setup(struct 
> device_node *node)
>   sunxi_usb_clk_setup(node, _a80_usb_phy_data, _usb_phy_lock);
>  }
>  CLK_OF_DECLARE(sun9i_a80_usb_phy, "allwinner,sun9i-a80-usb-phy-clk", 
> sun9i_a80_usb_phy_setup);
> +
> +static const struct usb_clk_data sun8i_h3_usb_clk_data __initconst = {
> + .clk_mask =  BIT(19) | BIT(18) | BIT(17) | BIT(16) |
> +  BIT(11) | BIT(10) | BIT(9) | BIT(8),
> + .reset_mask = BIT(3) | BIT(2) | BIT(1) | BIT(0),
> +};
> +
> +static void __init sun8i_h3_usb_setup(struct device_node *node)
> +{
> + sunxi_usb_clk_setup(node, _h3_usb_clk_data, _a10_usb_lock);
> +}
> +CLK_OF_DECLARE(sun8i_h3_usb, "allwinner,sun8i-h3-usb-clk", 
> sun8i_h3_usb_setup);
> -- 
> 2.5.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
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/5] phy-sun4i-usb: Add support for the host usb-phys found on the H3 SoC

[Rob Herring]

On Sun, Nov 15, 2015 at 08:46:14PM +0100, Hans de Goede wrote:
> From: Reinder de Haan 
> 
> Note this commit only adds support for phys 1-3, phy 0, the otg phy, is
> not yet (fully) supported after this commit.
> 
> Signed-off-by: Reinder de Haan 
> Signed-off-by: Hans de Goede 
> ---
>  .../devicetree/bindings/phy/sun4i-usb-phy.txt  |  1 +

Acked-by: Rob Herring 

>  drivers/phy/phy-sun4i-usb.c| 67 
> +-
>  2 files changed, 53 insertions(+), 15 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt 
> b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> index 0cebf74..95736d7 100644
> --- a/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> +++ b/Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
> @@ -9,6 +9,7 @@ Required properties:
>* allwinner,sun7i-a20-usb-phy
>* allwinner,sun8i-a23-usb-phy
>* allwinner,sun8i-a33-usb-phy
> +  * allwinner,sun8i-h3-usb-phy
>  - reg : a list of offset + length pairs
>  - reg-names :
>* "phy_ctrl"
> diff --git a/drivers/phy/phy-sun4i-usb.c b/drivers/phy/phy-sun4i-usb.c
> index b12964b..17f97ab 100644
> --- a/drivers/phy/phy-sun4i-usb.c
> +++ b/drivers/phy/phy-sun4i-usb.c
> @@ -46,6 +46,9 @@
>  #define REG_PHYBIST  0x08
>  #define REG_PHYTUNE  0x0c
>  #define REG_PHYCTL_A33   0x10
> +#define REG_PHY_UNK_H3   0x20
> +
> +#define REG_PMU_UNK_H3   0x10
>  
>  #define PHYCTL_DATA  BIT(7)
>  
> @@ -79,7 +82,7 @@
>  #define PHY_DISCON_TH_SEL0x2a
>  #define PHY_SQUELCH_DETECT   0x3c
>  
> -#define MAX_PHYS 3
> +#define MAX_PHYS 4
>  
>  /*
>   * Note do not raise the debounce time, we must report Vusb high within 100ms
> @@ -88,12 +91,19 @@
>  #define DEBOUNCE_TIMEmsecs_to_jiffies(50)
>  #define POLL_TIMEmsecs_to_jiffies(250)
>  
> +enum sun4i_usb_phy_type {
> + sun4i_a10_phy,
> + sun8i_a33_phy,
> + sun8i_h3_phy
> +};
> +
>  struct sun4i_usb_phy_data {
> + struct device *dev;
>   void __iomem *base;
>   struct mutex mutex;
>   int num_phys;
>   u32 disc_thresh;
> - bool has_a33_phyctl;
> + enum sun4i_usb_phy_type type;
>   struct sun4i_usb_phy {
>   struct phy *phy;
>   void __iomem *pmu;
> @@ -164,12 +174,18 @@ static void sun4i_usb_phy_write(struct sun4i_usb_phy 
> *phy, u32 addr, u32 data,
>  
>   mutex_lock(_data->mutex);
>  
> - if (phy_data->has_a33_phyctl) {
> + switch (phy_data->type) {
> + case sun4i_a10_phy:
> + phyctl = phy_data->base + REG_PHYCTL_A10;
> + break;
> + case sun8i_a33_phy:
>   phyctl = phy_data->base + REG_PHYCTL_A33;
>   /* A33 needs us to set phyctl to 0 explicitly */
>   writel(0, phyctl);
> - } else {
> - phyctl = phy_data->base + REG_PHYCTL_A10;
> + break;
> + case sun8i_h3_phy:
> + dev_err(phy_data->dev, "H3 usb_phy_write is not supported\n");
> + break;
>   }
>  
>   for (i = 0; i < len; i++) {
> @@ -230,6 +246,7 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   struct sun4i_usb_phy *phy = phy_get_drvdata(_phy);
>   struct sun4i_usb_phy_data *data = to_sun4i_usb_phy_data(phy);
>   int ret;
> + u32 val;
>  
>   ret = clk_prepare_enable(phy->clk);
>   if (ret)
> @@ -241,15 +258,26 @@ static int sun4i_usb_phy_init(struct phy *_phy)
>   return ret;
>   }
>  
> - /* Enable USB 45 Ohm resistor calibration */
> - if (phy->index == 0)
> - sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
> + if (data->type == sun8i_h3_phy) {
> + if (phy->index == 0) {
> + val = readl(data->base + REG_PHY_UNK_H3);
> + writel(val & ~1, data->base + REG_PHY_UNK_H3);
> + }
> +
> + val = readl(phy->pmu + REG_PMU_UNK_H3);
> + writel(val & ~2, phy->pmu + REG_PMU_UNK_H3);
> + } else {
> + /* Enable USB 45 Ohm resistor calibration */
> + if (phy->index == 0)
> + sun4i_usb_phy_write(phy, PHY_RES45_CAL_EN, 0x01, 1);
>  
> - /* Adjust PHY's magnitude and rate */
> - sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
> + /* Adjust PHY's magnitude and rate */
> + sun4i_usb_phy_write(phy, PHY_TX_AMPLITUDE_TUNE, 0x14, 5);
>  
> - /* Disconnect threshold adjustment */
> - sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL, data->disc_thresh, 2);
> + /* Disconnect threshold adjustment */
> + sun4i_usb_phy_write(phy, PHY_DISCON_TH_SEL,
> + data->disc_thresh, 2);
> + }
>  
>  

[linux-sunxi] Re: [PATCH v4 04/24] hwmon: pwm-fan: use pwm_get_xxx() helpers where appropriate

[Guenter Roeck]

On 11/16/2015 12:56 AM, Boris Brezillon wrote:

Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
Doing that will ease adaptation of the PWM framework to support atomic
update.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

--->8---
virtual patch

@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity((p), e);
|
-(p)->polarity
+pwm_get_polarity((p))


s/((p))/(p)/


|
-(p)->period = e;
+pwm_set_period((p), e);
|
-(p)->period
+pwm_get_period((p))


s/((p))/(p)/


|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle((p), e);


The (p) seems unnecessary here.


|
-(p)->duty_cycle
+pwm_get_duty_cycle((p))


s/((p))/(p)/


)
--->8---
---
  drivers/hwmon/pwm-fan.c | 13 +++--
  1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 3e23003..105b964 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -47,8 +47,8 @@ static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long 
pwm)
if (ctx->pwm_value == pwm)
goto exit_set_pwm_err;

-   duty = DIV_ROUND_UP(pwm * (ctx->pwm->period - 1), MAX_PWM);
-   ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
+   duty = DIV_ROUND_UP(pwm * (pwm_get_period((ctx->pwm)) - 1), MAX_PWM);
+   ret = pwm_config(ctx->pwm, duty, pwm_get_period((ctx->pwm)));


Please drop all the unnecessary ( ).

Thanks,
Guenter


if (ret)
goto exit_set_pwm_err;

@@ -234,10 +234,10 @@ static int pwm_fan_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);

/* Set duty cycle to maximum allowed */
-   duty_cycle = ctx->pwm->period - 1;
+   duty_cycle = pwm_get_period((ctx->pwm)) - 1;
ctx->pwm_value = MAX_PWM;

-   ret = pwm_config(ctx->pwm, duty_cycle, ctx->pwm->period);
+   ret = pwm_config(ctx->pwm, duty_cycle, pwm_get_period((ctx->pwm)));
if (ret) {
dev_err(>dev, "Failed to configure PWM\n");
return ret;
@@ -309,8 +309,9 @@ static int pwm_fan_resume(struct device *dev)
if (ctx->pwm_value == 0)
return 0;

-   duty = DIV_ROUND_UP(ctx->pwm_value * (ctx->pwm->period - 1), MAX_PWM);
-   ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
+   duty = DIV_ROUND_UP(ctx->pwm_value * (pwm_get_period((ctx->pwm)) - 1),
+   MAX_PWM);
+   ret = pwm_config(ctx->pwm, duty, pwm_get_period((ctx->pwm)));
if (ret)
return ret;
return pwm_enable(ctx->pwm);



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

[linux-sunxi] [PATCH v3 4/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.2

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

[linux-sunxi] [PATCH v3 8/9] ARM: sunxi_defconfig: Update MFD_AXP20X symbol and enable MFD_AXP20X_RSB

[Chen-Yu Tsai]

axp20x support has been split into 2 parts, I2C and RSB interface
variants.

Update the MFD_AXP20X symbol for I2C support, and also enable
MFD_AXP20X_RSB to support RSB variants.

Keep MFD_AXP20X enabled for now, to ease migration for automated boot
farms while the patches are being merged. This should be removed in the
next release.

Signed-off-by: Chen-Yu Tsai 
---
 arch/arm/configs/sunxi_defconfig | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16fcacf..18dbfaddb727 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -89,6 +89,8 @@ CONFIG_CPU_THERMAL=y
 CONFIG_WATCHDOG=y
 CONFIG_SUNXI_WATCHDOG=y
 CONFIG_MFD_AXP20X=y
+CONFIG_MFD_AXP20X_I2C=y
+CONFIG_MFD_AXP20X_RSB=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_AXP20X=y
-- 
2.6.2

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

[linux-sunxi] [PATCH v3 7/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 | 86 +-
 1 file changed, 84 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..01ab47b32d8d 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,85 @@
 
 _rsb {
status = "okay";
+
+   axp22x: pmic@3e3 {
+   compatible = "x-powers,axp223";
+   reg = <0x3e3>;
+   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-always-on;
+   regulator-min-microvolt = <300>;
+   regulator-max-microvolt = <300>;
+   regulator-name = "vcc-rtc";
 };
 
 _uart {
@@ -99,3 +177,7 @@
pinctrl-0 = <_uart_pins_a>;
status = "okay";
 };
+
+_lcd {
+   vcc-lcd-supply = <_dc1sw>;
+};
-- 
2.6.2

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

[linux-sunxi] [PATCH v3 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 
---
 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.2

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

[linux-sunxi] Re: [PATCH v3 5/9] sunxi-tools: refine progress updates by adjusting transfer chunk size

[Bernhard Nortmann]

Hello Alex!

Good catch, the AW_FEL_VERSION request caused by progress_chunk_size() 
might in fact arrive in an untimely manner there.


Basically we'd have to make sure we retrieve the aw_fel_get_sram_info() 
beforehand. I'm not sure there would be a more useful place for that 
even earlier, before aw_write_buffer() - so I'd say you made a sensible 
choice to place it there. I'd just suggest to move it before the "start" 
gettime() call. Will have a closer look at it later.


I'm also considering to move the 'recommended' chunk size information 
over to to soc_sram_info struct, let's say as a "speed" field. That way 
we could get rid of the switch statement in progress_chunk_size(), and 
use the .speed member field instead. If it's unset (value == 0), fall 
back to the slow/default transfer chunk.


Btw: Can you give a ballpark figure for the FEL write speed of the R8, 
or maybe edit https://linux-sunxi.org/FEL/USBBoot#SoC_support_status 
accordingly?


Regards, B. Nortmann

Am 16.11.2015 um 09:17 schrieb Alex Kaplan:

Hi Bernhard,

great work! I like especially the --xgauge in combination with 
multiwrite.
However, I have been testing with an Allwinner R8, and there is  a 
problem with the lazy initialization of the progress chunk size:


In aw_write_buffer() a AW_FEL_1_WRITE request is sent before the 
AW_FEL_VERSION request, which leads to libusb usb_bulk_send error -8.


For testing the rest of the patches, I sneaked in call of 
progress_chunk_size() before sending the AW_FEL_1_WRITE request:


diff --git a/fel.c b/fel.c
index b06d438..6fdd313 100644
--- a/fel.c
+++ b/fel.c
@@ -303,6 +303,7 @@ double aw_write_buffer(libusb_device_handle *usb, 
void *buf, uint32_t offset,

 exit(1);
 }
 double start = gettime();
+progress_chunk_size(usb);
 aw_send_fel_request(usb, AW_FEL_1_WRITE, offset, len);
 aw_usb_write(usb, buf, len, progress);
 aw_read_fel_status(usb);


However, I currently don't have an idea how to do this more elegantly.

Cheers
Alex



--
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 08/19] drm: Add Allwinner A10 Display Engine support

[Daniel Vetter]

On Wed, Nov 11, 2015 at 02:14:12PM -0800, Maxime Ripard wrote:
> Hi Daniel,
> 
> Thanks for your review!

Back from vacation, sorry for the delay.

> 
> On Fri, Oct 30, 2015 at 03:44:09PM +0100, Daniel Vetter wrote:
> > > +static void sun4i_crtc_disable(struct drm_crtc *crtc)
> > > +{
> > > + struct sun4i_crtc *scrtc = drm_crtc_to_sun4i_crtc(crtc);
> > > + struct sun4i_drv *drv = scrtc->drv;
> > > +
> > > + DRM_DEBUG_DRIVER("Disabling the CRTC\n");
> > > +
> > > + if (!scrtc->enabled)
> > > + return;
> > 
> > Please don't do this - the atomic state should always reflect the true hw
> > state (fix that up with either hw state readout or reset in the ->reset
> > callbacks), and the atomic helpers guarantee that they'll never call you
> > when not needed. If you don't trust them do a WARN_ON at least, but no
> > early silent returns.
> > 
> > Personally I'd just rip it out, it's too much trouble. And for debugging
> > the atomic helpers already trace it all (or at least should).
> 
> Ok. Is there a preferred way to do HW state readout, or should I just
> add that to my probe?

There's no preferred way yet (i.e. something supported in a standard
fashion through helpers). I'd place it in your various ->reset hooks
though. The idea from atomic helpers is that ->reset should make sure that
atomic state structures (i.e. drm_crtc/connector/plane_state or your
driver-specific subclasses of them) should match with the hw state. Either
by resetting the hw or by reading out the hw state inte freshly-allocated
structures.

> > > +static int sun4i_drv_connector_plug_all(struct drm_device *drm)
> > 
> > Laurent Pinchart has this as a rfc patch for drm core, please coordinate
> > with him and rebase on top of his patches.
> 
> Ack, I will.
> 
> > > +static int sun4i_drv_enable_vblank(struct drm_device *drm, int pipe)
> > > +{
> > > + struct sun4i_drv *drv = drm->dev_private;
> > > + struct sun4i_tcon *tcon = drv->tcon;
> > > +
> > > + DRM_DEBUG_DRIVER("Enabling VBLANK on pipe %d\n", pipe);
> > > +
> > > + sun4i_tcon_enable_vblank(tcon, true);
> > > +
> > > + return 0;
> > 
> > atomic helpers rely on enable_vblank failing correctly when the pipe is
> > off and vlbanks will never happen. You probably need a correct error code
> > here that checks crtc->state->active (well not that directly but something
> > derived from it, since the pointer chase would be racy).
> 
> Ok.
> 
> > I know it's a bit a mess since we don't have kms-native vblank driver
> > hooks yet and really the drm core should get this right for you. It'll
> > happen eventually, but drm_irq.c is a bit moldy ;-)
> 
> I can't really use drm_irq anyway, since we don't have a single
> interrupt for the VBLANK, but two, that we have to use depending on
> the output.

drm_irq has 2 parts: irq handling, which only supports 1 hw irq line, and
which is totally optional.

2nd part is the vblank support (all the drm_vblank and drm_crtc_vblank_)
functions, which are completely agnostic to how exactly your hw signals a
vblank for a given output. Those are mandatory if you want to support
vblanks (and really, you want to support vblanks). So whether you have 2
hw irq lines or 1 hw irq line with some additional status register doesn't
matter, since the hw irq -> logical drm_crtc mapping for vblank events is
done in the driver.

Yes I know we should split up the various bits in drm_irq, it's on my todo
;-)

> > > +static void sun4i_drv_disable_vblank(struct drm_device *drm, int pipe)
> > > +{
> > > + struct sun4i_drv *drv = drm->dev_private;
> > > + struct sun4i_tcon *tcon = drv->tcon;
> > > +
> > > + DRM_DEBUG_DRIVER("Disabling VBLANK on pipe %d\n", pipe);
> > > +
> > > + sun4i_tcon_enable_vblank(tcon, false);
> > > +}
> > > +
> > > +static int sun4i_drv_load(struct drm_device *drm, unsigned long flags)
> > 
> > load/unload callbacks are depracated since fundamentally racy, and we
> > can't fix that due to the pile of legacy dri1 drivers. Please use
> > drm_dev_alloc/register/unregister/unref functions instead, with the
> > load/unload code placed in between to avoid races with userspace seeing
> > the device/driver (e.g. in sysfs) while it's in a partially defunct state.
> > 
> > Relevant kerneldoc has the details, at least in linux-next.
> 
> Ok.
> 
> > > +static void sun4i_backend_layer_atomic_update(struct drm_plane *plane,
> > > +   struct drm_plane_state *old_state)
> > > +{
> > > + struct sun4i_layer *layer = plane_to_sun4i_layer(plane);
> > > + struct sun4i_drv *drv = layer->drv;
> > > + struct sun4i_backend *backend = drv->backend;
> > > +
> > > + sun4i_backend_update_layer_coord(backend, layer->id, plane);
> > > + sun4i_backend_update_layer_formats(backend, layer->id, plane);
> > > + sun4i_backend_update_layer_buffer(backend, layer->id, plane);
> > > + sun4i_backend_layer_enable(backend, layer->id, true);
> > > + sun4i_backend_commit(backend);
> > 
> > Not idea how exactly your hw works, but the call to 

[linux-sunxi] Re: [PATCH v4 09/24] regulator: pwm: use pwm_get/set_default_xxx() helpers where appropriate

[Boris Brezillon]

Hi Mark,

On Mon, 16 Nov 2015 10:55:58 +
Mark Brown  wrote:

> On Mon, Nov 16, 2015 at 09:56:32AM +0100, Boris Brezillon wrote:
> 
> > +++ b/drivers/regulator/pwm-regulator.c
> > @@ -56,7 +56,7 @@ static int pwm_regulator_set_voltage_sel(struct 
> > regulator_dev *rdev,
> > int dutycycle;
> > int ret;
> >  
> > -   pwm_reg_period = pwm_get_period(drvdata->pwm);
> > +   pwm_reg_period = pwm_get_default_period(drvdata->pwm);
> >  
> > dutycycle = (pwm_reg_period *
> > drvdata->duty_cycle_table[selector].dutycycle) / 100;
> 
> It's not clear to me that we're not looking for the current period here
> or in the other use.  Won't configuring based on a period other than the
> one that has been set give the wrong answer?

Hm, maybe that's naming problem. What I call the 'default' period here
is actually the period configured in your board file (using a PWM lookup
table) or your DT. This value represent the period requested by the PWM
user not a default value specified by the PWM chip driver.

The reason we're not using the 'current' period value is because it may
have been set by the bootloader, and may be inappropriate for our use
case (ie. the period may be to small to represent the different
voltages).
ITOH, we're using the current period value when calculating the current
voltage, because we want to get the correct voltage value, and the PWM
device may still use the configuration set by the bootloader (not the
default one specified in your board or DT files).

I hope this clarifies the differences between the current and default
period, and why we should use the default value here.

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 9/9] ARM: multi_v7_defconfig: Build AXP20X related drivers as modules

[Lee Jones]

On Fri, 13 Nov 2015, Chen-Yu Tsai wrote:

> On Fri, Nov 13, 2015 at 12:04 PM, Chen-Yu Tsai  wrote:
> > axp20x support has been split into 2 parts, I2C and RSB interface
> > variants.
> >
> > Update the MFD_AXP20X symbol for I2C support, and also enable
> > MFD_AXP20X_RSB to support RSB variants. Build these drivers as
> > modules.
> >
> > Keep MFD_AXP20X enabled for now, to ease migration for automated
> > boot farms while the patches are being merged. This should be
> > removed in the next release.
> >
> > Signed-off-by: Chen-Yu Tsai 
> 
> Sorry. This is an old file with an old commit message. Please see the
> other patch 9 ("ARM: multi_v7_defconfig: Enable RSB and AXP20X related
> drivers as modules").

Can you re-submit the set please?

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

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

[linux-sunxi] [PATCH 01/27] mtd: nand: fix drivers abusing mtd->priv

[Boris Brezillon]

The ->priv field of the mtd_info object attached to a nand_chip device
should point to the nand_chip device. The pxa and cafe drivers are
assigning this field their own private structure, which works fine as long
as the nand_chip field is the first one in the driver private struct but
seems a bit fragile.
Fix that by setting mtd->priv to point the nand_chip field and assigning
chip->priv to the private structure head.

Signed-off-by: Boris Brezillon 
---
 drivers/mtd/nand/cafe_nand.c   | 34 ++
 drivers/mtd/nand/pxa3xx_nand.c | 30 +++---
 2 files changed, 41 insertions(+), 23 deletions(-)

diff --git a/drivers/mtd/nand/cafe_nand.c b/drivers/mtd/nand/cafe_nand.c
index 9de78d2..cce3ac4 100644
--- a/drivers/mtd/nand/cafe_nand.c
+++ b/drivers/mtd/nand/cafe_nand.c
@@ -101,7 +101,8 @@ static const char *part_probes[] = { "cmdlinepart", 
"RedBoot", NULL };
 
 static int cafe_device_ready(struct mtd_info *mtd)
 {
-   struct cafe_priv *cafe = mtd->priv;
+   struct nand_chip *chip = mtd->priv;
+   struct cafe_priv *cafe = chip->priv;
int result = !!(cafe_readl(cafe, NAND_STATUS) & 0x4000);
uint32_t irqs = cafe_readl(cafe, NAND_IRQ);
 
@@ -117,7 +118,8 @@ static int cafe_device_ready(struct mtd_info *mtd)
 
 static void cafe_write_buf(struct mtd_info *mtd, const uint8_t *buf, int len)
 {
-   struct cafe_priv *cafe = mtd->priv;
+   struct nand_chip *chip = mtd->priv;
+   struct cafe_priv *cafe = chip->priv;
 
if (usedma)
memcpy(cafe->dmabuf + cafe->datalen, buf, len);
@@ -132,7 +134,8 @@ static void cafe_write_buf(struct mtd_info *mtd, const 
uint8_t *buf, int len)
 
 static void cafe_read_buf(struct mtd_info *mtd, uint8_t *buf, int len)
 {
-   struct cafe_priv *cafe = mtd->priv;
+   struct nand_chip *chip = mtd->priv;
+   struct cafe_priv *cafe = chip->priv;
 
if (usedma)
memcpy(buf, cafe->dmabuf + cafe->datalen, len);
@@ -146,7 +149,8 @@ static void cafe_read_buf(struct mtd_info *mtd, uint8_t 
*buf, int len)
 
 static uint8_t cafe_read_byte(struct mtd_info *mtd)
 {
-   struct cafe_priv *cafe = mtd->priv;
+   struct nand_chip *chip = mtd->priv;
+   struct cafe_priv *cafe = chip->priv;
uint8_t d;
 
cafe_read_buf(mtd, , 1);
@@ -158,7 +162,8 @@ static uint8_t cafe_read_byte(struct mtd_info *mtd)
 static void cafe_nand_cmdfunc(struct mtd_info *mtd, unsigned command,
  int column, int page_addr)
 {
-   struct cafe_priv *cafe = mtd->priv;
+   struct nand_chip *chip = mtd->priv;
+   struct cafe_priv *cafe = chip->priv;
int adrbytes = 0;
uint32_t ctl1;
uint32_t doneint = 0x8000;
@@ -313,7 +318,8 @@ static void cafe_nand_cmdfunc(struct mtd_info *mtd, 
unsigned command,
 
 static void cafe_select_chip(struct mtd_info *mtd, int chipnr)
 {
-   struct cafe_priv *cafe = mtd->priv;
+   struct nand_chip *chip = mtd->priv;
+   struct cafe_priv *cafe = chip->priv;
 
cafe_dev_dbg(>pdev->dev, "select_chip %d\n", chipnr);
 
@@ -328,7 +334,8 @@ static void cafe_select_chip(struct mtd_info *mtd, int 
chipnr)
 static irqreturn_t cafe_nand_interrupt(int irq, void *id)
 {
struct mtd_info *mtd = id;
-   struct cafe_priv *cafe = mtd->priv;
+   struct nand_chip *chip = mtd->priv;
+   struct cafe_priv *cafe = chip->priv;
uint32_t irqs = cafe_readl(cafe, NAND_IRQ);
cafe_writel(cafe, irqs & ~0x9000, NAND_IRQ);
if (!irqs)
@@ -377,7 +384,7 @@ static int cafe_nand_read_oob(struct mtd_info *mtd, struct 
nand_chip *chip,
 static int cafe_nand_read_page(struct mtd_info *mtd, struct nand_chip *chip,
   uint8_t *buf, int oob_required, int page)
 {
-   struct cafe_priv *cafe = mtd->priv;
+   struct cafe_priv *cafe = chip->priv;
unsigned int max_bitflips = 0;
 
cafe_dev_dbg(>pdev->dev, "ECC result %08x SYN1,2 %08x\n",
@@ -519,7 +526,7 @@ static int cafe_nand_write_page_lowlevel(struct mtd_info 
*mtd,
  const uint8_t *buf, int oob_required,
  int page)
 {
-   struct cafe_priv *cafe = mtd->priv;
+   struct cafe_priv *cafe = chip->priv;
 
chip->write_buf(mtd, buf, mtd->writesize);
chip->write_buf(mtd, chip->oob_poi, mtd->oobsize);
@@ -604,7 +611,8 @@ static int cafe_nand_probe(struct pci_dev *pdev,
cafe = (void *)([1]);
 
mtd->dev.parent = >dev;
-   mtd->priv = cafe;
+   mtd->priv = >nand;
+   cafe->nand.priv = cafe;
 
cafe->pdev = pdev;
cafe->mmio = pci_iomap(pdev, 0, 0);
@@ -792,7 +800,8 @@ static int cafe_nand_probe(struct pci_dev *pdev,
 static void cafe_nand_remove(struct pci_dev *pdev)
 {
struct mtd_info *mtd = pci_get_drvdata(pdev);
-   struct cafe_priv *cafe = mtd->priv;
+   struct 

[linux-sunxi] [PATCH 04/27] ARM: nand: make use of mtd_to_nand() where appropriate

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Update all ARM specific implementations to use this
helper.

Signed-off-by: Boris Brezillon 
---
 arch/arm/mach-ep93xx/snappercl15.c   | 4 ++--
 arch/arm/mach-ep93xx/ts72xx.c| 4 ++--
 arch/arm/mach-imx/mach-qong.c| 2 +-
 arch/arm/mach-ixp4xx/ixdp425-setup.c | 2 +-
 arch/arm/mach-omap1/board-nand.c | 2 +-
 arch/arm/mach-orion5x/ts78xx-setup.c | 6 +++---
 arch/arm/mach-pxa/balloon3.c | 2 +-
 arch/arm/mach-pxa/em-x270.c  | 2 +-
 arch/arm/mach-pxa/palmtx.c   | 2 +-
 9 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-ep93xx/snappercl15.c 
b/arch/arm/mach-ep93xx/snappercl15.c
index c490426..b2db791 100644
--- a/arch/arm/mach-ep93xx/snappercl15.c
+++ b/arch/arm/mach-ep93xx/snappercl15.c
@@ -49,7 +49,7 @@
 static void snappercl15_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
  unsigned int ctrl)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
static u16 nand_state = SNAPPERCL15_NAND_WPN;
u16 set;
 
@@ -76,7 +76,7 @@ static void snappercl15_nand_cmd_ctrl(struct mtd_info *mtd, 
int cmd,
 
 static int snappercl15_nand_dev_ready(struct mtd_info *mtd)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
 
return !!(__raw_readw(NAND_CTRL_ADDR(chip)) & SNAPPERCL15_NAND_RDY);
 }
diff --git a/arch/arm/mach-ep93xx/ts72xx.c b/arch/arm/mach-ep93xx/ts72xx.c
index 61f4b5d..45b81a2 100644
--- a/arch/arm/mach-ep93xx/ts72xx.c
+++ b/arch/arm/mach-ep93xx/ts72xx.c
@@ -74,7 +74,7 @@ static void __init ts72xx_map_io(void)
 static void ts72xx_nand_hwcontrol(struct mtd_info *mtd,
  int cmd, unsigned int ctrl)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
 
if (ctrl & NAND_CTRL_CHANGE) {
void __iomem *addr = chip->IO_ADDR_R;
@@ -96,7 +96,7 @@ static void ts72xx_nand_hwcontrol(struct mtd_info *mtd,
 
 static int ts72xx_nand_device_ready(struct mtd_info *mtd)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
void __iomem *addr = chip->IO_ADDR_R;
 
addr += (1 << TS72XX_NAND_BUSY_ADDR_LINE);
diff --git a/arch/arm/mach-imx/mach-qong.c b/arch/arm/mach-imx/mach-qong.c
index a213e7b..5c27646 100644
--- a/arch/arm/mach-imx/mach-qong.c
+++ b/arch/arm/mach-imx/mach-qong.c
@@ -131,7 +131,7 @@ static void qong_init_nor_mtd(void)
  */
 static void qong_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int 
ctrl)
 {
-   struct nand_chip *nand_chip = mtd->priv;
+   struct nand_chip *nand_chip = mtd_to_nand(mtd);
 
if (cmd == NAND_CMD_NONE)
return;
diff --git a/arch/arm/mach-ixp4xx/ixdp425-setup.c 
b/arch/arm/mach-ixp4xx/ixdp425-setup.c
index e7b8bef..333b0f9 100644
--- a/arch/arm/mach-ixp4xx/ixdp425-setup.c
+++ b/arch/arm/mach-ixp4xx/ixdp425-setup.c
@@ -76,7 +76,7 @@ static struct mtd_partition ixdp425_partitions[] = {
 static void
 ixdp425_flash_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
int offset = (int)this->priv;
 
if (ctrl & NAND_CTRL_CHANGE) {
diff --git a/arch/arm/mach-omap1/board-nand.c b/arch/arm/mach-omap1/board-nand.c
index 4d08353..7684f92 100644
--- a/arch/arm/mach-omap1/board-nand.c
+++ b/arch/arm/mach-omap1/board-nand.c
@@ -22,7 +22,7 @@
 
 void omap1_nand_cmd_ctl(struct mtd_info *mtd, int cmd, unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
unsigned long mask;
 
if (cmd == NAND_CMD_NONE)
diff --git a/arch/arm/mach-orion5x/ts78xx-setup.c 
b/arch/arm/mach-orion5x/ts78xx-setup.c
index 1b704d3..96cf6b5 100644
--- a/arch/arm/mach-orion5x/ts78xx-setup.c
+++ b/arch/arm/mach-orion5x/ts78xx-setup.c
@@ -176,7 +176,7 @@ static void ts78xx_ts_rtc_unload(void)
 static void ts78xx_ts_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
 
if (ctrl & NAND_CTRL_CHANGE) {
unsigned char bits;
@@ -200,7 +200,7 @@ static int ts78xx_ts_nand_dev_ready(struct mtd_info *mtd)
 static void ts78xx_ts_nand_write_buf(struct mtd_info *mtd,
const uint8_t *buf, int len)
 {
-   struct nand_chip *chip = mtd->priv;
+   struct nand_chip *chip = mtd_to_nand(mtd);
void __iomem *io_base = chip->IO_ADDR_W;
unsigned long off = ((unsigned long)buf & 3);
int sz;
@@ -227,7 +227,7 @@ static void ts78xx_ts_nand_write_buf(struct mtd_info *mtd,
 static void ts78xx_ts_nand_read_buf(struct mtd_info *mtd,

[linux-sunxi] [PATCH 05/27] blackfin: nand: make use of mtd_to_nand() where appropriate

[Boris Brezillon]

mtd_to_nand() was recently introduced to avoid direct accesses to the
mtd->priv field. Update all blackfin specific implementations to use
this helper.

Signed-off-by: Boris Brezillon 
---
 arch/blackfin/mach-bf537/boards/stamp.c   | 2 +-
 arch/blackfin/mach-bf561/boards/acvilon.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/blackfin/mach-bf537/boards/stamp.c 
b/arch/blackfin/mach-bf537/boards/stamp.c
index 88a19fc..c181543 100644
--- a/arch/blackfin/mach-bf537/boards/stamp.c
+++ b/arch/blackfin/mach-bf537/boards/stamp.c
@@ -404,7 +404,7 @@ static struct mtd_partition bfin_plat_nand_partitions[] = {
 #define BFIN_NAND_PLAT_ALE 1
 static void bfin_plat_nand_cmd_ctrl(struct mtd_info *mtd, int cmd, unsigned 
int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
 
if (cmd == NAND_CMD_NONE)
return;
diff --git a/arch/blackfin/mach-bf561/boards/acvilon.c 
b/arch/blackfin/mach-bf561/boards/acvilon.c
index 6ab9515..37f8f25 100644
--- a/arch/blackfin/mach-bf561/boards/acvilon.c
+++ b/arch/blackfin/mach-bf561/boards/acvilon.c
@@ -267,7 +267,7 @@ static struct mtd_partition bfin_plat_nand_partitions[] = {
 static void bfin_plat_nand_cmd_ctrl(struct mtd_info *mtd, int cmd,
unsigned int ctrl)
 {
-   struct nand_chip *this = mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
 
if (cmd == NAND_CMD_NONE)
return;
-- 
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 00/27] mtd: nand: refactor the NAND subsystem (part 1)

[Boris Brezillon]

Hello,

This huge series aims at clarifying the relationship between the mtd and
nand_chip structures and hiding NAND framework internals to NAND
controller drivers.

The first part of the series provide an mtd_to_nand() helper to hide the
way mtd and nand_chip are linked together.

The second part of the series embeds the mtd structure into the nand_chip
one so that NAND controller drivers don't have to bother allocating the
MTD device and linking it with the NAND chip.

The last part of the series hides accesses to the chip->priv field behind
two helper functions.

This allows removal of some of the boilerplate code done in all NAND
controller drivers, but most importantly, it unifies a bit the way NAND
chip structures are instantiated (even though we still have two different
kinds of drivers: those embedding the nand_chip struct into their private
nand chip representation, and those allocating two different structures
and linking them together with the chip->priv field).

As said in the title, this refactoring is only the first step. I plan to
rework the NAND controller / NAND chip separation for pretty much the same
reasons: clarifying the separation between the two concepts, and getting
rid of more boilerplate code in NAND controller drivers.

Stay tuned ;-).

Best Regards,

Boris

Boris Brezillon (27):
  mtd: nand: fix drivers abusing mtd->priv
  mtd: nand: add an mtd_to_nand() helper
  mtd: nand: update examples in the documentation to use mtd_to_nand()
  ARM: nand: make use of mtd_to_nand() where appropriate
  blackfin: nand: make use of mtd_to_nand() where appropriate
  cris: nand: make use of mtd_to_nand() where appropriate
  mips: nand: make use of mtd_to_nand() where appropriate
  sh: nand: make use of mtd_to_nand() where appropriate
  mtd: nand: make use of mtd_to_nand() in NAND core code
  mtd: nand: make use of mtd_to_nand() in NAND drivers
  staging: mt29f_spinand: make use of mtd_to_nand()
  mtd: nand: embed an mtd_info structure into nand_chip
  mtd: nand: add nand_to_mtd() helper
  mtd: nand: use the mtd instance embedded in struct nand_chip
  mtd: nand: update the documentation to reflect framework changes
  staging: mt29f_spinand: use the mtd instance embedded in struct
nand_chip
  cris: nand: use the mtd instance embedded in struct nand_chip
  mtd: nand: update mtd_to_nand()
  mtd: nand: remove useless mtd->priv = chip assignments
  cris: nand: remove useless mtd->priv = chip assignments
  staging: mt29f_spinand: remove useless mtd->priv = chip assignment
  mtd: nand: simplify nand_dt_init() usage
  mtd: nand: kill the chip->flash_node field
  mtd: nand: add helpers to access ->priv
  ARM: make use of nand_set/get_controller_data() helpers
  mtd: nand: make use of nand_set/get_controller_data() helpers
  staging: mt29f_spinand: make use of nand_set/get_controller_data()
helpers

 Documentation/DocBook/mtdnand.tmpl |  35 +++---
 arch/arm/mach-ep93xx/snappercl15.c |   4 +-
 arch/arm/mach-ep93xx/ts72xx.c  |   4 +-
 arch/arm/mach-imx/mach-qong.c  |   2 +-
 arch/arm/mach-ixp4xx/ixdp425-setup.c   |   6 +-
 arch/arm/mach-omap1/board-nand.c   |   2 +-
 arch/arm/mach-orion5x/ts78xx-setup.c   |   6 +-
 arch/arm/mach-pxa/balloon3.c   |   2 +-
 arch/arm/mach-pxa/em-x270.c|   2 +-
 arch/arm/mach-pxa/palmtx.c |   2 +-
 arch/blackfin/mach-bf537/boards/stamp.c|   2 +-
 arch/blackfin/mach-bf561/boards/acvilon.c  |   2 +-
 arch/cris/arch-v32/drivers/mach-a3/nandflash.c |   8 +-
 arch/cris/arch-v32/drivers/mach-fs/nandflash.c |   8 +-
 arch/mips/alchemy/devboards/db1200.c   |   2 +-
 arch/mips/alchemy/devboards/db1300.c   |   2 +-
 arch/mips/alchemy/devboards/db1550.c   |   2 +-
 arch/mips/pnx833x/common/platform.c|   2 +-
 arch/mips/rb532/devices.c  |   2 +-
 arch/sh/boards/mach-migor/setup.c  |   2 +-
 drivers/mtd/nand/ams-delta.c   |  26 ++---
 drivers/mtd/nand/atmel_nand.c  | 116 ++-
 drivers/mtd/nand/au1550nd.c|  40 +++
 drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h |   1 -
 drivers/mtd/nand/bcm47xxnflash/main.c  |   9 +-
 drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c   |  34 +++---
 drivers/mtd/nand/bf5xx_nand.c  |  27 +++--
 drivers/mtd/nand/brcmnand/brcmnand.c   |  54 +
 drivers/mtd/nand/cafe_nand.c   |  41 ---
 drivers/mtd/nand/cmx270_nand.c |  20 ++--
 drivers/mtd/nand/cs553x_nand.c |  30 +++--
 drivers/mtd/nand/davinci_nand.c|  33 +++---
 drivers/mtd/nand/denali.c  |  61 +-
 drivers/mtd/nand/denali.h  |   1 -
 drivers/mtd/nand/diskonchip.c  | 148 -
 drivers/mtd/nand/docg4.c   |  93 

[linux-sunxi] [PATCH 02/27] mtd: nand: add an mtd_to_nand() helper

[Boris Brezillon]

Some drivers are retrieving the nand_chip pointer using the container_of
macro on a struct wrapping both the nand_chip and the mtd_info struct while
the standard way of retrieving this pointer is through mtd->priv.
Provide an helper to do that.

Signed-off-by: Boris Brezillon 
---
 include/linux/mtd/nand.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 4f7c9b9..056d165 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -730,6 +730,11 @@ static inline struct device_node 
*nand_get_flash_node(struct nand_chip *chip)
return chip->flash_node;
 }
 
+static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
+{
+   return mtd->priv;
+}
+
 /*
  * NAND Flash Manufacturer ID Codes
  */
-- 
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 03/27] mtd: nand: update examples in the documentation to use mtd_to_nand()

[Boris Brezillon]

mtd_to_nand() has been introduced to hide accesses to mtd->priv.
All NAND controller drivers should use it instead of directly accessing
the ->priv field.

Signed-off-by: Boris Brezillon 
---
 Documentation/DocBook/mtdnand.tmpl | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/DocBook/mtdnand.tmpl 
b/Documentation/DocBook/mtdnand.tmpl
index 7da8f04..403a7ab 100644
--- a/Documentation/DocBook/mtdnand.tmpl
+++ b/Documentation/DocBook/mtdnand.tmpl
@@ -235,7 +235,7 @@ static void board_hwcontrol(struct mtd_info *mtd, int cmd)

 static void board_hwcontrol(struct mtd_info *mtd, int cmd)
 {
-   struct nand_chip *this = (struct nand_chip *) mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);
switch(cmd){
case NAND_CTL_SETCLE: this->IO_ADDR_W |= CLE_ADRR_BIT;  break;
case NAND_CTL_CLRCLE: this->IO_ADDR_W = ~CLE_ADRR_BIT; 
break;
@@ -399,7 +399,7 @@ static void board_select_chip (struct mtd_info *mtd, int 
chip)

 static void board_select_chip (struct mtd_info *mtd, int chip)
 {
-   struct nand_chip *this = (struct nand_chip *) mtd->priv;
+   struct nand_chip *this = mtd_to_nand(mtd);

/* Deselect all chips */
this->IO_ADDR_R = ~BOARD_NAND_ADDR_MASK;
-- 
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] Re: [PATCH v4 05/24] misc: max77693-haptic: use pwm_get_xxx() helpers where appropriate

[Boris Brezillon]

Hi Krzysztof,

On Mon, 16 Nov 2015 22:10:40 +0900
Krzysztof Kozlowski  wrote:

> W dniu 16.11.2015 o 17:56, Boris Brezillon pisze:
> > Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
> > Doing that will ease adaptation of the PWM framework to support atomic
> > update.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> > Patch generated with the following coccinelle script:
> > 
> > --->8---
> > virtual patch
> > 
> > @@
> > struct pwm_device *p;
> > expression e;
> > @@
> > (
> > -(p)->polarity = e;
> > +pwm_set_polarity((p), e);
> > |
> > -(p)->polarity
> > +pwm_get_polarity((p))
> > |
> > -(p)->period = e;
> > +pwm_set_period((p), e);
> > |
> > -(p)->period
> > +pwm_get_period((p))
> > |
> > -(p)->duty_cycle = e;
> > +pwm_set_duty_cycle((p), e);
> > |
> > -(p)->duty_cycle
> > +pwm_get_duty_cycle((p))
> > )
> > --->8---
> > ---
> >  drivers/input/misc/max77693-haptic.c | 7 ---
> >  1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/input/misc/max77693-haptic.c 
> > b/drivers/input/misc/max77693-haptic.c
> > index 6d96bff..a038fb3 100644
> > --- a/drivers/input/misc/max77693-haptic.c
> > +++ b/drivers/input/misc/max77693-haptic.c
> > @@ -70,10 +70,11 @@ struct max77693_haptic {
> >  
> >  static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
> >  {
> > -   int delta = (haptic->pwm_dev->period + haptic->pwm_duty) / 2;
> > +   int delta = (pwm_get_period((haptic->pwm_dev)) + haptic->pwm_duty) / 2;
> 
> Double parentheses over argument are not needed so just:
> pwm_get_period(haptic->pwm_dev) + ...

Actually it was generated with coccinelle, hence I didn't fix existing
coding style issues, but I have no problem fixing them.

Thanks,

Boris

> 
> Beside that patch looks good, so with removing parentheses here and below:
> 
> Reviewed-by: Krzysztof Kozlowski 
> 
> Best regards,
> Krzysztof
> 
> > int error;
> >  
> > -   error = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
> > +   error = pwm_config(haptic->pwm_dev, delta,
> > +  pwm_get_period((haptic->pwm_dev)));
> > if (error) {
> > dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
> > return error;
> > @@ -245,7 +246,7 @@ static int max77693_haptic_play_effect(struct input_dev 
> > *dev, void *data,
> >  * The formula to convert magnitude to pwm_duty as follows:
> >  * - pwm_duty = (magnitude * pwm_period) / MAX_MAGNITUDE(0x)
> >  */
> > -   period_mag_multi = (u64)haptic->pwm_dev->period * haptic->magnitude;
> > +   period_mag_multi = (u64)pwm_get_period((haptic->pwm_dev)) * 
> > haptic->magnitude;
> > haptic->pwm_duty = (unsigned int)(period_mag_multi >>
> > MAX_MAGNITUDE_SHIFT);
> >  
> > 
> 



-- 
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 v4 05/24] misc: max77693-haptic: use pwm_get_xxx() helpers where appropriate

[Krzysztof Kozlowski]

W dniu 16.11.2015 o 17:56, Boris Brezillon pisze:
> Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
> Doing that will ease adaptation of the PWM framework to support atomic
> update.
> 
> Signed-off-by: Boris Brezillon 
> ---
> Patch generated with the following coccinelle script:
> 
> --->8---
> virtual patch
> 
> @@
> struct pwm_device *p;
> expression e;
> @@
> (
> -(p)->polarity = e;
> +pwm_set_polarity((p), e);
> |
> -(p)->polarity
> +pwm_get_polarity((p))
> |
> -(p)->period = e;
> +pwm_set_period((p), e);
> |
> -(p)->period
> +pwm_get_period((p))
> |
> -(p)->duty_cycle = e;
> +pwm_set_duty_cycle((p), e);
> |
> -(p)->duty_cycle
> +pwm_get_duty_cycle((p))
> )
> --->8---
> ---
>  drivers/input/misc/max77693-haptic.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/input/misc/max77693-haptic.c 
> b/drivers/input/misc/max77693-haptic.c
> index 6d96bff..a038fb3 100644
> --- a/drivers/input/misc/max77693-haptic.c
> +++ b/drivers/input/misc/max77693-haptic.c
> @@ -70,10 +70,11 @@ struct max77693_haptic {
>  
>  static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
>  {
> - int delta = (haptic->pwm_dev->period + haptic->pwm_duty) / 2;
> + int delta = (pwm_get_period((haptic->pwm_dev)) + haptic->pwm_duty) / 2;

Double parentheses over argument are not needed so just:
pwm_get_period(haptic->pwm_dev) + ...

Beside that patch looks good, so with removing parentheses here and below:

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof

>   int error;
>  
> - error = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
> + error = pwm_config(haptic->pwm_dev, delta,
> +pwm_get_period((haptic->pwm_dev)));
>   if (error) {
>   dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
>   return error;
> @@ -245,7 +246,7 @@ static int max77693_haptic_play_effect(struct input_dev 
> *dev, void *data,
>* The formula to convert magnitude to pwm_duty as follows:
>* - pwm_duty = (magnitude * pwm_period) / MAX_MAGNITUDE(0x)
>*/
> - period_mag_multi = (u64)haptic->pwm_dev->period * haptic->magnitude;
> + period_mag_multi = (u64)pwm_get_period((haptic->pwm_dev)) * 
> haptic->magnitude;
>   haptic->pwm_duty = (unsigned int)(period_mag_multi >>
>   MAX_MAGNITUDE_SHIFT);
>  
> 

-- 
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 v4 00/24] pwm: add support for atomic update

[Heiko Stübner]

Hi Boris,

Am Montag, 16. November 2015, 09:56:23 schrieb Boris Brezillon:
> Hello,
> 
> This series adds support for atomic PWM update, or IOW, the capability
> to update all the parameters of a PWM device (enabled/disabled, period,
> duty and polarity) in one go.

you already include my tested-by tags, but anyway, the series still works 
nicely on 4.4-rc1 on my veyron chromebook.


Heiko

-- 
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 2/2] ehci-platform: Add support for controllers with multiple reset lines

[Hans de Goede]

Hi,

On 16-11-15 18:01, Philipp Zabel wrote:

Am Montag, den 16.11.2015, 17:49 +0100 schrieb Hans de Goede:

Hi,

On 16-11-15 17:04, Chen-Yu Tsai wrote:

On Mon, Nov 16, 2015 at 11:42 PM, Alan Stern  wrote:

On Sun, 15 Nov 2015, Hans de Goede wrote:


From: Reinder de Haan 

At least the EHCI found on the Allwinnner H3 SoC needs multiple reset
lines, the controller will not initialize while the reset for its
companion OHCI is still asserted, which means we need to de-assert
2 reset-controllers for this EHCI controller to work.


I assume that reset_control_deassert() is smart enough to maintain a
count of de-assertions, and it doesn't actually turn on the reset line
until the count drops to 0.  Right?


No it doesn't. That might be a problem when 2 devices (such as EHCI / OHCI
pairs) share a reset line, one probes successfully while the other doesn't.
Hans?


Ugh, good catch Alan, so I think the best way to solve this is to
actually make reset_control do a deassert / (re)assert count like
is done already for clocks, there is bound to be more hardware out there
which shares a reset line between 2 related blocks.

I'll whip up a patch for this, submit it and then we'll see.


If there are two devices sharing the same reset line that is initially
held asserted, do the two drivers somehow have to synchronize before
releasing the reset together?


Not to my knowledge, I suggest that we simply treat this same as
regulators / clocks where the first one to enable it actually gets
it enabled (de-asserted in case of a reset), and the last one
to disable (assert) it (so dropping the usage counter back to 0) leads
to it being asserted again.

This seems to work well enough for clocks / regulators and phys, and
at least for my use-case it should work fine for the shared reset too
(I will test to make sure of course).

So from my pov a simple counter should suffice, does that work for you ?

Regards,

Hans

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

[linux-sunxi] Re: [PATCH v4 09/24] regulator: pwm: use pwm_get/set_default_xxx() helpers where appropriate

[Mark Brown]

On Mon, Nov 16, 2015 at 01:23:59PM +0100, Boris Brezillon wrote:
> Mark Brown  wrote:
> > On Mon, Nov 16, 2015 at 09:56:32AM +0100, Boris Brezillon wrote:

> > > - pwm_reg_period = pwm_get_period(drvdata->pwm);
> > > + pwm_reg_period = pwm_get_default_period(drvdata->pwm);

> > It's not clear to me that we're not looking for the current period here
> > or in the other use.  Won't configuring based on a period other than the
> > one that has been set give the wrong answer?

> Hm, maybe that's naming problem. What I call the 'default' period here
> is actually the period configured in your board file (using a PWM lookup
> table) or your DT. This value represent the period requested by the PWM
> user not a default value specified by the PWM chip driver.

> The reason we're not using the 'current' period value is because it may
> have been set by the bootloader, and may be inappropriate for our use
> case (ie. the period may be to small to represent the different
> voltages).

> ITOH, we're using the current period value when calculating the current
> voltage, because we want to get the correct voltage value, and the PWM
> device may still use the configuration set by the bootloader (not the
> default one specified in your board or DT files).

> I hope this clarifies the differences between the current and default
> period, and why we should use the default value here.

To be honest I'm still a bit confused here.  When do we actually apply
the default setting and why do we keep on having to constantly override
it rather than doing this once at boot?  It feels wrong to be using it
every time we set anything.  I'd expect it to be something we only need
to do at probe time or which would automatically be handled by the PWM
framework (but that'd have issues changing the state and potentially
breaking things if done in an uncoordiated fashion).

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


signature.asc
Description: PGP signature

[linux-sunxi] Re: [PATCH v3 5/9] sunxi-tools: refine progress updates by adjusting transfer chunk size

[Bernhard Nortmann]

I have prepared an alternative version (v4) of this patch, and will 
attach it below. (github is also updated, so you may retrieve the 
patches from https://github.com/linux-sunxi/sunxi-tools/pull/35 
alternatively)


progress_chunk_size() was renamed to get_chunk_size(), als I think that 
makes the 'isolated' call in aw_write_buffer() easier to understand. 
This patch also uses a new field "write_speed" in soc_sram_info, 
eliminating the need to keep track of and update soc_id values in 
get_chunk_size().


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 0048164c530839ed4845d9d5609a0115f4912699 Mon Sep 17 00:00:00 2001
From: Bernhard Nortmann 
Date: Mon, 16 Nov 2015 18:45:54 +0100
Subject: [PATCH v4 5/9] sunxi-tools: refine progress updates by adjusting
 transfer chunk size

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

diff --git a/fel.c b/fel.c
index aa30fa6..176aa1e 100644
--- a/fel.c
+++ b/fel.c
@@ -79,12 +79,18 @@ static void pr_info(const char *fmt, ...)
}
 }
 
-static const int AW_USB_MAX_BULK_SEND = 4 * 1024 * 1024; // 4 MiB per bulk 
request
+static const size_t AW_USB_MAX_BULK_SEND = 4 * 1024 * 1024; // 4 MiB per bulk 
request
+static size_t get_chunk_size(libusb_device_handle *usb); /* forward 
declaration */
 
 void usb_bulk_send(libusb_device_handle *usb, int ep, const void *data,
   size_t length, bool progress)
 {
-   size_t max_chunk = AW_USB_MAX_BULK_SEND; /* maximum chunk size */
+   /*
+* With no progress notifications, we'll use the maximum chunk size.
+* Otherwise, it's useful to lower the value (= have smaller chunks)
+* to get more frequent status updates.
+*/
+   size_t max_chunk = progress ? get_chunk_size(usb) : 
AW_USB_MAX_BULK_SEND;
 
size_t chunk, total = length;
int rc, sent;
@@ -295,6 +301,14 @@ double aw_write_buffer(libusb_device_handle *usb, void 
*buf, uint32_t offset,
uboot_entry, uboot_entry + uboot_size);
exit(1);
}
+
+   /*
+* Calculating chunk size may enforce an AW_FEL_VERSION request. If 
needed,
+* let's get that out of the way - so it doesn't interfere later.
+*/
+   if (progress)
+   get_chunk_size(usb); /* possibly calls aw_fel_get_sram_info() */
+
double start = gettime();
aw_send_fel_request(usb, AW_FEL_1_WRITE, offset, len);
aw_usb_write(usb, buf, len, progress);
@@ -424,6 +438,7 @@ typedef struct {
uint32_t   thunk_addr;   /* Address of the thunk code */
uint32_t   thunk_size;   /* Maximal size of the thunk code */
uint32_t   needs_l2en;   /* Set the L2EN bit */
+   uint32_t   write_speed;  /* approx. FEL write speed, in KiB/s */
sram_swap_buffers *swap_buffers;
 } soc_sram_info;
 
@@ -461,6 +476,7 @@ soc_sram_info soc_sram_info_table[] = {
.thunk_addr   = 0xAE00, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
.needs_l2en   = 1,
+   .write_speed  = 512,
},
{
.soc_id   = 0x1625, /* Allwinner A13 */
@@ -468,12 +484,14 @@ soc_sram_info soc_sram_info_table[] = {
.thunk_addr   = 0xAE00, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
.needs_l2en   = 1,
+   .write_speed  = 512,
},
{
.soc_id   = 0x1651, /* Allwinner A20 */
.scratch_addr = 0x2000,
.thunk_addr   = 0xAE00, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
+   .write_speed  = 512,
},
{
.soc_id   = 0x1650, /* Allwinner A23 */
@@ -486,6 +504,7 @@ soc_sram_info soc_sram_info_table[] = {
.scratch_addr = 0x2000,
.thunk_addr   = 0x46E00, .thunk_size = 0x200,
.swap_buffers = a31_sram_swap_buffers,
+   .write_speed  = 512,
},
{
.soc_id   = 0x1667, /* Allwinner A33 */
@@ -554,6 +573,32 @@ soc_sram_info *aw_fel_get_sram_info(libusb_device_handle 
*usb)
return result;
 }
 
+/*
+ * This function serves to determine a useful "progress chunk" size, based on
+ * the assumption that we aim for at least one update per second approximately.
+ *
+ * As of now, unfortunately this isn't a single, uniform value. Many SoCs have
+ * decent FEL write speeds - but a few experience shortcomings and poor
+ * 

[linux-sunxi] Re: [PATCH v4 02/24] pwm: use pwm_get_xxx() helpers where appropriate

[Boris Brezillon]

Hi Joachim,

On Mon, 16 Nov 2015 18:46:44 +0100
Joachim  Eastwood  wrote:

> Hi Boris
> 
> (Adding Ariel for pwm-lpc18xx-sct)
> 
> On 16 November 2015 at 09:56, Boris Brezillon
>  wrote:
> > Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
> > Doing that will ease adaptation of the PWM framework to support atomic
> > update.
> >
> > Signed-off-by: Boris Brezillon 
> > ---
> > Patch generated with the following coccinelle script:
> >
> > --->8---
> > virtual patch
> >
> > @@
> > struct pwm_device *p;
> > expression e;
> > @@
> > (
> > -(p)->polarity = e;
> > +pwm_set_polarity((p), e);
> > |
> > -(p)->polarity
> > +pwm_get_polarity((p))
> > |
> > -(p)->period = e;
> > +pwm_set_period((p), e);
> > |
> > -(p)->period
> > +pwm_get_period((p))
> > |
> > -(p)->duty_cycle = e;
> > +pwm_set_duty_cycle((p), e);
> > |
> > -(p)->duty_cycle
> > +pwm_get_duty_cycle((p))
> > )
> > --->8---
> > ---
> >  drivers/pwm/pwm-crc.c | 2 +-
> >  drivers/pwm/pwm-lpc18xx-sct.c | 2 +-
> >  2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
> > index 7101c70..2f88543 100644
> > --- a/drivers/pwm/pwm-crc.c
> > +++ b/drivers/pwm/pwm-crc.c
> > @@ -75,7 +75,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct 
> > pwm_device *pwm,
> > return -EINVAL;
> > }
> >
> > -   if (pwm->period != period_ns) {
> > +   if (pwm_get_period((pwm)) != period_ns) {
> > int clk_div;
> >
> > /* changing the clk divisor, need to disable fisrt */
> > diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
> > index 9163085..091fa13 100644
> > --- a/drivers/pwm/pwm-lpc18xx-sct.c
> > +++ b/drivers/pwm/pwm-lpc18xx-sct.c
> > @@ -249,7 +249,7 @@ static int lpc18xx_pwm_enable(struct pwm_chip *chip, 
> > struct pwm_device *pwm)
> >LPC18XX_PWM_EVSTATEMSK(lpc18xx_data->duty_event),
> >LPC18XX_PWM_EVSTATEMSK_ALL);
> >
> > -   if (pwm->polarity == PWM_POLARITY_NORMAL) {
> > +   if (pwm_get_polarity((pwm)) == PWM_POLARITY_NORMAL) {
> 
> What is the deal with the double parentheses?
> 
> Think I saw that in some of the other patches as well.

It comes from a typo in my coccinelle script. I already fixed it and
regenerated the faulty patches, so please ignore this aspect while
reviewing (this will be addressed in the next version).

Thanks,

Boris

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

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

[linux-sunxi] Re: [PATCH v3 5/9] sunxi-tools: refine progress updates by adjusting transfer chunk size

[Alexander Kaplan]

Hi Bernhard,

I observe roughly ~500 KB/s on the R8.
As the R8 is really similar to the A13 (and is also handled as an A13) by
the fel tool, I'm not sure weather it makes sense to update
https://linux-sunxi.org/FEL/USBBoot#SoC_support_status.
However, I'm happy to do so if you consider it useful.

Regards
Alex

On Mon, Nov 16, 2015 at 4:18 AM, Bernhard Nortmann  wrote:

> Hello Alex!
>
> Good catch, the AW_FEL_VERSION request caused by progress_chunk_size()
> might in fact arrive in an untimely manner there.
>
> Basically we'd have to make sure we retrieve the aw_fel_get_sram_info()
> beforehand. I'm not sure there would be a more useful place for that even
> earlier, before aw_write_buffer() - so I'd say you made a sensible choice
> to place it there. I'd just suggest to move it before the "start" gettime()
> call. Will have a closer look at it later.
>
> I'm also considering to move the 'recommended' chunk size information over
> to to soc_sram_info struct, let's say as a "speed" field. That way we could
> get rid of the switch statement in progress_chunk_size(), and use the
> .speed member field instead. If it's unset (value == 0), fall back to the
> slow/default transfer chunk.
>
> Btw: Can you give a ballpark figure for the FEL write speed of the R8, or
> maybe edit https://linux-sunxi.org/FEL/USBBoot#SoC_support_status
> accordingly?
>
> Regards, B. Nortmann
>
>
> Am 16.11.2015 um 09:17 schrieb Alex Kaplan:
>
>> Hi Bernhard,
>>
>> great work! I like especially the --xgauge in combination with multiwrite.
>> However, I have been testing with an Allwinner R8, and there is  a
>> problem with the lazy initialization of the progress chunk size:
>>
>> In aw_write_buffer() a AW_FEL_1_WRITE request is sent before the
>> AW_FEL_VERSION request, which leads to libusb usb_bulk_send error -8.
>>
>> For testing the rest of the patches, I sneaked in call of
>> progress_chunk_size() before sending the AW_FEL_1_WRITE request:
>>
>> diff --git a/fel.c b/fel.c
>> index b06d438..6fdd313 100644
>> --- a/fel.c
>> +++ b/fel.c
>> @@ -303,6 +303,7 @@ double aw_write_buffer(libusb_device_handle *usb,
>> void *buf, uint32_t offset,
>>  exit(1);
>>  }
>>  double start = gettime();
>> +progress_chunk_size(usb);
>>  aw_send_fel_request(usb, AW_FEL_1_WRITE, offset, len);
>>  aw_usb_write(usb, buf, len, progress);
>>  aw_read_fel_status(usb);
>>
>>
>> However, I currently don't have an idea how to do this more elegantly.
>>
>> Cheers
>> Alex
>>
>>
>

-- 
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 v4 09/24] regulator: pwm: use pwm_get/set_default_xxx() helpers where appropriate

[Boris Brezillon]

On Mon, 16 Nov 2015 18:42:38 +
Mark Brown  wrote:

> On Mon, Nov 16, 2015 at 01:23:59PM +0100, Boris Brezillon wrote:
> > Mark Brown  wrote:
> > > On Mon, Nov 16, 2015 at 09:56:32AM +0100, Boris Brezillon wrote:
> 
> > > > -   pwm_reg_period = pwm_get_period(drvdata->pwm);
> > > > +   pwm_reg_period = pwm_get_default_period(drvdata->pwm);
> 
> > > It's not clear to me that we're not looking for the current period here
> > > or in the other use.  Won't configuring based on a period other than the
> > > one that has been set give the wrong answer?
> 
> > Hm, maybe that's naming problem. What I call the 'default' period here
> > is actually the period configured in your board file (using a PWM lookup
> > table) or your DT. This value represent the period requested by the PWM
> > user not a default value specified by the PWM chip driver.
> 
> > The reason we're not using the 'current' period value is because it may
> > have been set by the bootloader, and may be inappropriate for our use
> > case (ie. the period may be to small to represent the different
> > voltages).
> 
> > ITOH, we're using the current period value when calculating the current
> > voltage, because we want to get the correct voltage value, and the PWM
> > device may still use the configuration set by the bootloader (not the
> > default one specified in your board or DT files).
> 
> > I hope this clarifies the differences between the current and default
> > period, and why we should use the default value here.
> 
> To be honest I'm still a bit confused here.  When do we actually apply
> the default setting and why do we keep on having to constantly override
> it rather than doing this once at boot?

That's why I said the 'default' name may be inappropriate. The
default values are actually never directly applied by the PWM framework.
It's the default value for a specific PWM user, so it can be applied by
the PWM user when he wants. It's more here as a reference, nothing
forces the PWM user to use this specific value.

> It feels wrong to be using it
> every time we set anything.  I'd expect it to be something we only need
> to do at probe time or which would automatically be handled by the PWM
> framework (but that'd have issues changing the state and potentially
> breaking things if done in an uncoordiated fashion).

The whole point of this series is to smoothly take over the bootloader
config. This is why we are keeping the PWM untouched until someone
really wants to change the regulator output. We should be able to apply
the 'default' PWM period when probing the device, but this means first
extracting the current voltage from the PWM state and then applying a
new dutycycle and the default period in a single operation. Not sure
it's worth the trouble.

Doing it in the PWM framework is not really possible, because the PWM
lookup table and DT definitions are only defining the 'default' period
value not the 'default' dutycycle, and applying that automatically when
requesting the PWM means generating a glitch on the PWM signal
(dutycycle will be set to 0 until the user changes it using
pwm_config() or pwm_apply_state()) which is exactly what we're trying to
solve here.

Also, note that you have to pass the period anyway when configuring the
PWM, so passing the default one or the current one should be pretty
much the same in term of performances (unless the PWM driver is able
to optimize its setting if the period does not change).

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 v5 2/2] simplefb: Claim and enable regulators

[Chen-Yu Tsai]

This claims and enables regulators listed in the simple framebuffer dt
node. This is needed so that regulators powering the display pipeline
and external hardware, described in the device node and known by the
kernel code, will remain properly enabled.

Signed-off-by: Chen-Yu Tsai 
Acked-by: Mark Brown 
---
 drivers/video/fbdev/simplefb.c | 120 -
 1 file changed, 119 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/simplefb.c b/drivers/video/fbdev/simplefb.c
index 52c5c7e63b52..48ccf6db62a2 100644
--- a/drivers/video/fbdev/simplefb.c
+++ b/drivers/video/fbdev/simplefb.c
@@ -28,7 +28,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
+#include 
+#include 
 
 static struct fb_fix_screeninfo simplefb_fix = {
.id = "simple",
@@ -174,6 +177,10 @@ struct simplefb_par {
int clk_count;
struct clk **clks;
 #endif
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+   u32 regulator_count;
+   struct regulator **regulators;
+#endif
 };
 
 #if defined CONFIG_OF && defined CONFIG_COMMON_CLK
@@ -269,6 +276,110 @@ static int simplefb_clocks_init(struct simplefb_par *par,
 static void simplefb_clocks_destroy(struct simplefb_par *par) { }
 #endif
 
+#if defined CONFIG_OF && defined CONFIG_REGULATOR
+
+#define SUPPLY_SUFFIX "-supply"
+
+/*
+ * Regulator handling code.
+ *
+ * Here we handle the num-supplies and vin*-supply properties of our
+ * "simple-framebuffer" dt node. This is necessary so that we can make sure
+ * that any regulators needed by the display hardware that the bootloader
+ * set up for us (and for which it provided a simplefb dt node), stay up,
+ * for the life of the simplefb driver.
+ *
+ * When the driver unloads, we cleanly disable, and then release the
+ * regulators.
+ *
+ * We only complain about errors here, no action is taken as the most likely
+ * error can only happen due to a mismatch between the bootloader which set
+ * up simplefb, and the regulator definitions in the device tree. Chances are
+ * that there are no adverse effects, and if there are, a clean teardown of
+ * the fb probe will not help us much either. So just complain and carry on,
+ * and hope that the user actually gets a working fb at the end of things.
+ */
+static int simplefb_regulators_init(struct simplefb_par *par,
+   struct platform_device *pdev)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct property *prop;
+   struct regulator *regulator;
+   const char *p;
+   int count = 0, i = 0, ret;
+
+   if (dev_get_platdata(>dev) || !np)
+   return 0;
+
+   /* Count the number of regulator supplies */
+   for_each_property_of_node(np, prop) {
+   p = strstr(prop->name, SUPPLY_SUFFIX);
+   if (p && p != prop->name)
+   count++;
+   }
+
+   if (!count)
+   return 0;
+
+   par->regulators = devm_kcalloc(>dev, count,
+  sizeof(struct regulator *), GFP_KERNEL);
+   if (!par->regulators)
+   return -ENOMEM;
+
+   /* Get all the regulators */
+   for_each_property_of_node(np, prop) {
+   char name[32]; /* 32 is max size of property name */
+
+   p = strstr(prop->name, SUPPLY_SUFFIX);
+   if (!p || p == prop->name)
+   continue;
+
+   strlcpy(name, prop->name,
+   strlen(prop->name) - strlen(SUPPLY_SUFFIX) + 1);
+   regulator = devm_regulator_get_optional(>dev, name);
+   if (IS_ERR(regulator)) {
+   if (PTR_ERR(regulator) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   dev_err(>dev, "regulator %s not found: %ld\n",
+   name, PTR_ERR(regulator));
+   continue;
+   }
+   par->regulators[i++] = regulator;
+   }
+   par->regulator_count = i;
+
+   /* Enable all the regulators */
+   for (i = 0; i < par->regulator_count; i++) {
+   ret = regulator_enable(par->regulators[i]);
+   if (ret) {
+   dev_err(>dev,
+   "failed to enable regulator %d: %d\n",
+   i, ret);
+   devm_regulator_put(par->regulators[i]);
+   par->regulators[i] = NULL;
+   }
+   }
+
+   return 0;
+}
+
+static void simplefb_regulators_destroy(struct simplefb_par *par)
+{
+   int i;
+
+   if (!par->regulators)
+   return;
+
+   for (i = 0; i < par->regulator_count; i++)
+   if (par->regulators[i])
+   regulator_disable(par->regulators[i]);
+}
+#else
+static int simplefb_regulators_init(struct simplefb_par *par,
+   struct platform_device *pdev) { return 0; }
+static 

[linux-sunxi] [PATCH v5 0/2] simplefb: Add regulator handling support

[Chen-Yu Tsai]

Hi everyone,

This is v5 of the simplefb regulator support series. This series adds
regulator claiming and enabling support for simplefb.

Hans, I dropped your Reviewed-by tag from patch 2 since v4.

Changes since v5:
  - Rebased onto v4.4-rc1
  - Dropped dts patches (merged)

Changes since v4:
  - Fixed inverted logic when testing the property name.
  - Fixed regulator supply name string copy length off by 1.
  - Added real world user, MSI Primo 81 dts patches.

Changes since v3:
  - Dropped extra "if" which is always true, leftover from v1.
  - Updated commit message of patch 1

Sometimes the simplefb display output path consits of external conversion
chips and/or LCD drivers and backlights. These devices normally have
GPIOs to turn them on and/or bring them out of reset, and regulators
supplying power to them.

While the kernel does not touch unclaimed GPIOs, the regulator core
happily disables unused regulators. Thus we need simplefb to claim
and enable the regulators used throughout the display pipeline.

The binding supports any named regulator supplies under its device
node. The driver will look through its properties, and claim any
regulators by matching "*-supply", as Mark suggested.

I've not done a generic helper in the regulator core yet, instead doing
the regulator property handling in the simplefb code for now.


Patch 1 adds the regulator properties to the DT binding.

Patch 2 adds code to the simplefb driver to claim and enable regulators.

Regards
ChenYu


Chen-Yu Tsai (2):
  dt-bindings: simplefb: Support regulator supply properties
  simplefb: Claim and enable regulators

 .../bindings/display/simple-framebuffer.txt|  13 ++-
 drivers/video/fbdev/simplefb.c | 120 -
 2 files changed, 128 insertions(+), 5 deletions(-)

-- 
2.6.2

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

[linux-sunxi] [PATCH v5 1/2] dt-bindings: simplefb: Support regulator supply properties

[Chen-Yu Tsai]

The physical display tied to the framebuffer may have regulators
providing power to it, such as power for LCDs or interface conversion
chips.

The number of regulators in use may vary, but the regulator supply
binding can not be a list. Instead just support any named regulator
supply properties under the device node. These should be properly
named to match the device schematics / design. The driver should
take care to go through them all.

Signed-off-by: Chen-Yu Tsai 
Reviewed-by: Hans de Goede 
Acked-by: Mark Brown 
---
 .../devicetree/bindings/display/simple-framebuffer.txt  | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.txt 
b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
index 4474ef6e0b95..8c9e9f515c87 100644
--- a/Documentation/devicetree/bindings/display/simple-framebuffer.txt
+++ b/Documentation/devicetree/bindings/display/simple-framebuffer.txt
@@ -47,10 +47,14 @@ Required properties:
   - a8b8g8r8 (32-bit pixels, d[31:24]=a, d[23:16]=b, d[15:8]=g, d[7:0]=r).
 
 Optional properties:
-- clocks : List of clocks used by the framebuffer. Clocks listed here
-   are expected to already be configured correctly. The OS must
-   ensure these clocks are not modified or disabled while the
-   simple framebuffer remains active.
+- clocks : List of clocks used by the framebuffer.
+- *-supply : Any number of regulators used by the framebuffer. These should
+be named according to the names in the device's design.
+
+  The above resources are expected to already be configured correctly.
+  The OS must ensure they are not modified or disabled while the simple
+  framebuffer remains active.
+
 - display : phandle pointing to the primary display hardware node
 
 Example:
@@ -68,6 +72,7 @@ chosen {
stride = <(1600 * 2)>;
format = "r5g6b5";
clocks = <_gates 36>, <_gates 43>, <_gates 44>;
+   lcd-supply = <_dc1sw>;
display = <>;
};
stdout-path = "display0";
-- 
2.6.2

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

[linux-sunxi] Re: [PATCH 14/27] mtd: nand: use the mtd instance embedded in struct nand_chip

[Brian Norris]

Hi Boris,

On Mon, Nov 16, 2015 at 02:37:47PM +0100, Boris Brezillon wrote:
> struct nand_chip now embeds an mtd device. Patch all drivers to make use
> of this mtd instance instead of using the instance embedded in their
> private struct or dynamically allocated.
> 
> Signed-off-by: Boris Brezillon 
> Cc: Julia Lawall 
> ---
> Most of those changes were generate with this coccinelle script:
> http://code.bulix.org/5vxuih-89429

I appreciate that this patch is mostly autogenerated (a good thing for
preventing errors!), but there are some issues that I don't think play
out very well stylistically. Hopefully the cocci script can be improved
to handle some of this?

I'll try to point out a few snippets below.

Also, in case others are interested in reviewing your cocci script
directly, it might be better to paste it inline than to link to it.
Given the size of the patch, I don't think people would mind a few dozen
extra lines to show how it wsa generated. Or maybe stick some in the
cover letter too, if you end up reusing them in several patches.

> ---
>  drivers/mtd/nand/ams-delta.c   | 13 ++--
>  drivers/mtd/nand/atmel_nand.c  | 11 ++-
>  drivers/mtd/nand/au1550nd.c| 18 ++---
>  drivers/mtd/nand/bcm47xxnflash/bcm47xxnflash.h |  1 -
>  drivers/mtd/nand/bcm47xxnflash/main.c  |  7 +-
>  drivers/mtd/nand/bcm47xxnflash/ops_bcm4706.c   |  2 +-
>  drivers/mtd/nand/bf5xx_nand.c  | 14 ++--
>  drivers/mtd/nand/brcmnand/brcmnand.c   | 11 ++-
>  drivers/mtd/nand/cafe_nand.c   | 10 +--
>  drivers/mtd/nand/cmx270_nand.c | 11 ++-
>  drivers/mtd/nand/cs553x_nand.c | 13 ++--
>  drivers/mtd/nand/davinci_nand.c| 25 +++
>  drivers/mtd/nand/denali.c  | 61 +
>  drivers/mtd/nand/denali.h  |  1 -
>  drivers/mtd/nand/diskonchip.c  | 11 ++-
>  drivers/mtd/nand/docg4.c   | 18 +++--
>  drivers/mtd/nand/fsl_elbc_nand.c   | 22 +++---
>  drivers/mtd/nand/fsl_ifc_nand.c| 23 +++
>  drivers/mtd/nand/fsl_upm.c | 26 +++
>  drivers/mtd/nand/fsmc_nand.c   | 59 +---
>  drivers/mtd/nand/gpio.c| 16 ++---
>  drivers/mtd/nand/gpmi-nand/gpmi-lib.c  |  2 +-
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.c | 20 +++---
>  drivers/mtd/nand/gpmi-nand/gpmi-nand.h |  1 -
>  drivers/mtd/nand/hisi504_nand.c| 11 ++-
>  drivers/mtd/nand/jz4740_nand.c |  9 ++-
>  drivers/mtd/nand/lpc32xx_mlc.c |  7 +-
>  drivers/mtd/nand/lpc32xx_slc.c |  7 +-
>  drivers/mtd/nand/mpc5121_nfc.c |  3 +-
>  drivers/mtd/nand/mxc_nand.c|  5 +-
>  drivers/mtd/nand/nandsim.c | 12 ++--
>  drivers/mtd/nand/ndfc.c| 22 +++---
>  drivers/mtd/nand/nuc900_nand.c | 21 +++---
>  drivers/mtd/nand/omap2.c   | 94 
> +++---
>  drivers/mtd/nand/orion_nand.c  |  4 +-
>  drivers/mtd/nand/pasemi_nand.c | 14 ++--
>  drivers/mtd/nand/plat_nand.c   | 14 ++--
>  drivers/mtd/nand/pxa3xx_nand.c | 33 -

^^ BTW, this file already has a few conflicts. Sorry :(

I'll try to keep any eye out for things like this once we're close to
being able to apply something like this, so I don't merge unnecessary
churn. But for now, I hope we can review this series, and it won't be
too much work to rebase/resend once the bigger things have been worked
out.

>  drivers/mtd/nand/r852.c| 34 --
>  drivers/mtd/nand/r852.h|  1 -
>  drivers/mtd/nand/s3c2410.c | 19 +++---
>  drivers/mtd/nand/sh_flctl.c|  8 +--
>  drivers/mtd/nand/sharpsl.c | 18 ++---
>  drivers/mtd/nand/socrates_nand.c   |  5 +-
>  drivers/mtd/nand/sunxi_nand.c  | 13 ++--
>  drivers/mtd/nand/tmio_nand.c   |  7 +-
>  drivers/mtd/nand/txx9ndfmc.c   |  3 +-
>  drivers/mtd/nand/vf610_nfc.c   |  5 +-
>  include/linux/mtd/sh_flctl.h   |  3 +-
>  49 files changed, 383 insertions(+), 385 deletions(-)
> 

...

> diff --git a/drivers/mtd/nand/atmel_nand.c b/drivers/mtd/nand/atmel_nand.c
> index f8aac0a..51748b4 100644
> --- a/drivers/mtd/nand/atmel_nand.c
> +++ b/drivers/mtd/nand/atmel_nand.c

...

> @@ -318,7 +317,7 @@ static int nfc_set_sram_bank(struct atmel_nand_host 
> *host, unsigned int bank)
>  
>   if (bank) {
>   /* Only for a 2k-page or lower flash, NFC can handle 2 banks */
> - if (host->mtd.writesize > 2048)
> + if 

[linux-sunxi] Re: [PATCH 18/27] mtd: nand: update mtd_to_nand()

[Brian Norris]

On Mon, Nov 16, 2015 at 02:37:51PM +0100, Boris Brezillon wrote:
> Now that all drivers are using the mtd instance embedded in the nand_chip

Do you have a script that verifies this? I thought you did at some
point, and it'd be nice to note it, so I can also use it to verify
things once it gets applied.

> struct we can safely update the mtd_to_nand_chip() implementation to use

Nit: s/mtd_to_nand_chip/mtd_to_nand/

> the container_of macro instead of returning the content of mtd->priv.
> This will allow us to remove mtd->priv = chip assignments done in all
> NAND controller drivers.
> 
> Signed-off-by: Boris Brezillon 
> ---
>  include/linux/mtd/nand.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
> index 8ec071e..873646d 100644
> --- a/include/linux/mtd/nand.h
> +++ b/include/linux/mtd/nand.h
> @@ -734,7 +734,7 @@ static inline struct device_node 
> *nand_get_flash_node(struct nand_chip *chip)
>  
>  static inline struct nand_chip *mtd_to_nand(struct mtd_info *mtd)
>  {
> - return mtd->priv;
> + return container_of(mtd, struct nand_chip, mtd);
>  }
>  
>  static inline struct mtd_info *nand_to_mtd(struct nand_chip *chip)
> -- 
> 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 sunxi-tools v2 3/3] fel: Enable MMU on Allwinner-H3 to improve FEL transfer speed

[Siarhei Siamashka]

When the CPU clock speed is set to 480 MHz by the U-Boot SPL,
the performance of 'sunxi-fel write' transfers to DRAM improves
from ~95 KB/s to ~510 KB/s.

When the CPU clock speed is set to 1008 MHz by the U-Boot SPL,
the performance of 'sunxi-fel write' transfers to DRAM improves
from ~180 KB/s to ~510 KB/s.

This means that the CPU is not a bottleneck for FEL transfers
anymore. Further performance improvements are possible by
increasing the AHB1 clock speed in the U-Boot SPL (up to
something like ~900 KB/s).

Signed-off-by: Siarhei Siamashka 
---
 fel.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fel.c b/fel.c
index 9a08af6..1544d18 100644
--- a/fel.c
+++ b/fel.c
@@ -487,6 +487,7 @@ soc_sram_info soc_sram_info_table[] = {
{
.soc_id   = 0x1680, /* Allwinner H3 */
.scratch_addr = 0x2000,
+   .mmu_tt_addr  = 0x44000,
.thunk_addr   = 0x46E00, .thunk_size = 0x200,
.swap_buffers = a31_sram_swap_buffers,
},
-- 
2.4.10

-- 
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 sunxi-tools v2 0/3] fel: Faster FEL USB boot for Allwinner H3

[Siarhei Siamashka]

Changes in v2:
* The DACR register is now properly initialized when enabling the MMU.
  In the v1 patchset this register was left uninitialized and the
  garbage data in it could cause deadlocks depeding on luck.
* Addressed review comments from Bernhard Nortmann and Peter Korsgaard
  (a typo fix, more comments, redundant aw_fel_write call removal)
* Introduced a new patch with helper functions for reading/writing ARM
  coprocessor registers

Siarhei Siamashka (3):
  fel: Helper functions for reading/writing ARM coprocessor registers
  fel: Support for enabling MMU after running SPL on new SoC variants
  fel: Enable MMU on Allwinner-H3 to improve FEL transfer speed

 fel.c | 191 +-
 1 file changed, 167 insertions(+), 24 deletions(-)

-- 
2.4.10

-- 
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 sunxi-tools v2 1/3] fel: Helper functions for reading/writing ARM coprocessor registers

[Siarhei Siamashka]

This helps to reduce code duplication if we want to read and write
many different kinds of coprocessor registers.

Signed-off-by: Siarhei Siamashka 
---
 fel.c | 70 ---
 1 file changed, 46 insertions(+), 24 deletions(-)

diff --git a/fel.c b/fel.c
index e9f6450..f394916 100644
--- a/fel.c
+++ b/fel.c
@@ -533,6 +533,50 @@ static uint32_t fel_to_spl_thunk[] = {
 #defineDRAM_BASE   0x4000
 #defineDRAM_SIZE   0x8000
 
+uint32_t aw_read_arm_cp_reg(libusb_device_handle *usb, soc_sram_info 
*sram_info,
+   uint32_t coproc, uint32_t opc1, uint32_t crn,
+   uint32_t crm, uint32_t opc2)
+{
+   uint32_t val = 0;
+   uint32_t opcode = 0xEE00 | (1 << 20) | (1 << 4) |
+ ((opc1 & 7) << 21)|
+ ((crn & 15) << 16)|
+ ((coproc & 15) << 8)  |
+ ((opc2 & 7) << 5) |
+ (crm & 15);
+   uint32_t arm_code[] = {
+   htole32(opcode), /* mrc  coproc, opc1, r0, crn, crm, opc2 */
+   htole32(0xe58f), /* str  r0, [pc] */
+   htole32(0xe12fff1e), /* bx   lr   */
+   };
+   aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
+   aw_fel_execute(usb, sram_info->scratch_addr);
+   aw_fel_read(usb, sram_info->scratch_addr + 12, , sizeof(val));
+   return le32toh(val);
+}
+
+void aw_write_arm_cp_reg(libusb_device_handle *usb, soc_sram_info *sram_info,
+uint32_t coproc, uint32_t opc1, uint32_t crn,
+uint32_t crm, uint32_t opc2, uint32_t val)
+{
+   uint32_t opcode = 0xEE00 | (0 << 20) | (1 << 4) |
+ ((opc1 & 7) << 21)|
+ ((crn & 15) << 16)|
+ ((coproc & 15) << 8)  |
+ ((opc2 & 7) << 5) |
+ (crm & 15);
+   uint32_t arm_code[] = {
+   htole32(0xe59f000c), /* ldr  r0, [pc, #12]*/
+   htole32(opcode), /* mcr  coproc, opc1, r0, crn, crm, opc2 */
+   htole32(0xf57ff04f), /* dsb  sy   */
+   htole32(0xf57ff06f), /* isb  sy   */
+   htole32(0xe12fff1e), /* bx   lr   */
+   htole32(val)
+   };
+   aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
+   aw_fel_execute(usb, sram_info->scratch_addr);
+}
+
 void aw_enable_l2_cache(libusb_device_handle *usb, soc_sram_info *sram_info)
 {
uint32_t arm_code[] = {
@@ -586,34 +630,12 @@ void aw_get_stackinfo(libusb_device_handle *usb, 
soc_sram_info *sram_info,
 
 uint32_t aw_get_ttbr0(libusb_device_handle *usb, soc_sram_info *sram_info)
 {
-   uint32_t ttbr0 = 0;
-   uint32_t arm_code[] = {
-   htole32(0xee122f10), /* mrc15, 0, r2, cr2, cr0, {0}  */
-   htole32(0xe58f2008), /* strr2, [pc, #8]  */
-   htole32(0xe12fff1e), /* bx lr*/
-   };
-
-   aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
-   aw_fel_execute(usb, sram_info->scratch_addr);
-   aw_fel_read(usb, sram_info->scratch_addr + 0x14, , sizeof(ttbr0));
-   ttbr0 = le32toh(ttbr0);
-   return ttbr0;
+   return aw_read_arm_cp_reg(usb, sram_info, 15, 0, 2, 0, 0);
 }
 
 uint32_t aw_get_sctlr(libusb_device_handle *usb, soc_sram_info *sram_info)
 {
-   uint32_t sctlr = 0;
-   uint32_t arm_code[] = {
-   htole32(0xee112f10), /* mrc15, 0, r2, cr1, cr0, {0}  */
-   htole32(0xe58f2008), /* strr2, [pc, #8]  */
-   htole32(0xe12fff1e), /* bx lr*/
-   };
-
-   aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
-   aw_fel_execute(usb, sram_info->scratch_addr);
-   aw_fel_read(usb, sram_info->scratch_addr + 0x14, , sizeof(sctlr));
-   sctlr = le32toh(sctlr);
-   return sctlr;
+   return aw_read_arm_cp_reg(usb, sram_info, 15, 0, 1, 0, 0);
 }
 
 uint32_t *aw_backup_and_disable_mmu(libusb_device_handle *usb,
-- 
2.4.10

-- 
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 sunxi-tools v2 2/3] fel: Support for enabling MMU after running SPL on new SoC variants

[Siarhei Siamashka]

The BROM in newer SoC variants doesn't enable MMU by default anymore.
So in order to benefit from e4b3da2b17ee9d7c5cab9b80e708b3a309fc4c96
("fel: Faster USB transfers via 'fel write' to DRAM"), we need to
be able to enable it from the 'sunxi-fel' tool.

This patch can be interpreted as simply reverting the changes done
by Allwinner and bringing back the MMU support in roughly the same
way as it was before. That's why the values in the hardware
registers and the translation table entries replicate the A20 setup.

Additionally, the code is now more defensive and introduces new
"canary" checks for certain known magic values in the coprocessor
registers in order to safeguard against any unpleasant surprises.

MMU tuning for A80 and A64 will probably need a more sophisticated
setup with a second level page table. Because both the SRAM and
the BROM reside in the same 1MB section there and we need finer
granularity. In other words, enabling the MMU on A80 and A64 is
not supported yet.

Signed-off-by: Siarhei Siamashka 
---
 fel.c | 124 --
 1 file changed, 122 insertions(+), 2 deletions(-)

diff --git a/fel.c b/fel.c
index f394916..9a08af6 100644
--- a/fel.c
+++ b/fel.c
@@ -388,6 +388,18 @@ typedef struct {
  * Note: the entries in the 'swap_buffers' tables need to be sorted by 'buf1'
  * addresses. And the 'buf1' addresses are the BROM data buffers, while 'buf2'
  * addresses are the intended backup locations.
+ *
+ * Also for performance reasons, we optionally want to have MMU enabled with
+ * optimal section attributes configured (the code from the BROM should use
+ * I-cache, writing data to the DRAM area should use write combining). The
+ * reason is that the BROM FEL protocol implementation moves data using the
+ * CPU somewhere on the performance critical path when transferring data over
+ * USB. The older SoC variants (A10/A13/A20/A31/A23) already have MMU enabled
+ * and we only need to adjust section attributes. The BROM in newer SoC 
variants
+ * (A33/A83T/H3) doesn't enable MMU anymore, so we need to find some 16K of
+ * spare space in SRAM to place the translation table there and specify it as
+ * the 'mmu_tt_addr' field in the 'soc_sram_info' structure. The 'mmu_tt_addr'
+ * address must be 16K aligned.
  */
 typedef struct {
uint32_t   soc_id;   /* ID of the SoC */
@@ -396,6 +408,7 @@ typedef struct {
uint32_t   thunk_addr;   /* Address of the thunk code */
uint32_t   thunk_size;   /* Maximal size of the thunk code */
uint32_t   needs_l2en;   /* Set the L2EN bit */
+   uint32_t   mmu_tt_addr;  /* MMU translation table address */
sram_swap_buffers *swap_buffers;
 } soc_sram_info;
 
@@ -633,17 +646,80 @@ uint32_t aw_get_ttbr0(libusb_device_handle *usb, 
soc_sram_info *sram_info)
return aw_read_arm_cp_reg(usb, sram_info, 15, 0, 2, 0, 0);
 }
 
+uint32_t aw_get_ttbcr(libusb_device_handle *usb, soc_sram_info *sram_info)
+{
+   return aw_read_arm_cp_reg(usb, sram_info, 15, 0, 2, 0, 2);
+}
+
+uint32_t aw_get_dacr(libusb_device_handle *usb, soc_sram_info *sram_info)
+{
+   return aw_read_arm_cp_reg(usb, sram_info, 15, 0, 3, 0, 0);
+}
+
 uint32_t aw_get_sctlr(libusb_device_handle *usb, soc_sram_info *sram_info)
 {
return aw_read_arm_cp_reg(usb, sram_info, 15, 0, 1, 0, 0);
 }
 
+void aw_set_ttbr0(libusb_device_handle *usb, soc_sram_info *sram_info,
+ uint32_t ttbr0)
+{
+   return aw_write_arm_cp_reg(usb, sram_info, 15, 0, 2, 0, 0, ttbr0);
+}
+
+void aw_set_ttbcr(libusb_device_handle *usb, soc_sram_info *sram_info,
+ uint32_t ttbcr)
+{
+   return aw_write_arm_cp_reg(usb, sram_info, 15, 0, 2, 0, 2, ttbcr);
+}
+
+void aw_set_dacr(libusb_device_handle *usb, soc_sram_info *sram_info,
+uint32_t dacr)
+{
+   aw_write_arm_cp_reg(usb, sram_info, 15, 0, 3, 0, 0, dacr);
+}
+
+void aw_set_sctlr(libusb_device_handle *usb, soc_sram_info *sram_info,
+ uint32_t sctlr)
+{
+   aw_write_arm_cp_reg(usb, sram_info, 15, 0, 1, 0, 0, sctlr);
+}
+
+/*
+ * Reconstruct the same MMU translation table as used by the A20 BROM.
+ * We are basically reverting the changes, introduced in newer SoC
+ * variants. This works fine for the SoC variants with the memory
+ * layout similar to A20 (the SRAM is in the first megabyte of the
+ * address space and the BROM is in the last megabyte of the address
+ * space).
+ */
+uint32_t *aw_generate_mmu_translation_table(void)
+{
+   uint32_t *tt = malloc(4096 * sizeof(uint32_t));
+   uint32_t i;
+
+   /*
+* Direct mapping using 1MB sections with TEXCB=0 (Strongly
+* ordered) for all memory except the first and the last sections,
+* which have TEXCB=00100 (Normal). Domain bits are set to 
+* and AP bits are set to 11, but this is mostly irrelevant.
+*/
+   for 

[linux-sunxi] [PATCH] ARM: sunxi: Re-enable SID driver in sunxi_defconfig

[Timo Sigurdsson]

Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
sunxi_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
in sunxi_defconfig.

While at it, clean up sunxi_defconfig by generating a fresh file via
  make sunxi_defconfig
  make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.

Signed-off-by: Timo Sigurdsson 

diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 3c36e16..904ea52 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -11,14 +11,12 @@ CONFIG_SMP=y
 CONFIG_NR_CPUS=8
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
-CONFIG_HIGHPTE=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPUFREQ_DT=y
 CONFIG_VFP=y
 CONFIG_NEON=y
-CONFIG_PM=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -37,7 +35,6 @@ CONFIG_CAN_SUN4I=y
 # CONFIG_WIRELESS is not set
 CONFIG_DEVTMPFS=y
 CONFIG_DEVTMPFS_MOUNT=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_ATA=y
 CONFIG_AHCI_SUNXI=y
@@ -63,11 +60,10 @@ CONFIG_STMMAC_ETH=y
 # CONFIG_INPUT_MOUSEDEV is not set
 # CONFIG_INPUT_KEYBOARD is not set
 # CONFIG_INPUT_MOUSE is not set
-CONFIG_INPUT_MISC=y
-CONFIG_INPUT_AXP20X_PEK=y
 CONFIG_INPUT_TOUCHSCREEN=y
-CONFIG_KEYBOARD_SUN4I_LRADC=y
 CONFIG_TOUCHSCREEN_SUN4I=y
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AXP20X_PEK=y
 CONFIG_SERIAL_8250=y
 CONFIG_SERIAL_8250_CONSOLE=y
 CONFIG_SERIAL_8250_NR_UARTS=8
@@ -123,6 +119,8 @@ CONFIG_PWM=y
 CONFIG_PWM_SUN4I=y
 CONFIG_PHY_SUN4I_USB=y
 CONFIG_PHY_SUN9I_USB=y
+CONFIG_NVMEM=y
+CONFIG_NVMEM_SUNXI_SID=y
 CONFIG_EXT4_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
-- 
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] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Timo Sigurdsson]

Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
framework") moved the the sunxi SID driver to a new framework, but left
multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
in multi_v7_defconfig.

While at it, clean up multi_v7_defconfig by generating a fresh file via
  make multi_v7_defconfig
  make savedefconfig
While this moves around a few lines and removes unnecessary symbols,
it doesn't introduce any functional changes.

Signed-off-by: Timo Sigurdsson 

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 69a22fd..f712ea3 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -12,7 +12,6 @@ CONFIG_MODULE_UNLOAD=y
 CONFIG_PARTITION_ADVANCED=y
 CONFIG_CMDLINE_PARTITION=y
 CONFIG_ARCH_VIRT=y
-CONFIG_ARCH_ALPINE=y
 CONFIG_ARCH_MVEBU=y
 CONFIG_MACH_ARMADA_370=y
 CONFIG_MACH_ARMADA_375=y
@@ -20,6 +19,7 @@ CONFIG_MACH_ARMADA_38X=y
 CONFIG_MACH_ARMADA_39X=y
 CONFIG_MACH_ARMADA_XP=y
 CONFIG_MACH_DOVE=y
+CONFIG_ARCH_ALPINE=y
 CONFIG_ARCH_AT91=y
 CONFIG_SOC_SAMA5D2=y
 CONFIG_SOC_SAMA5D3=y
@@ -27,9 +27,9 @@ CONFIG_SOC_SAMA5D4=y
 CONFIG_ARCH_BCM=y
 CONFIG_ARCH_BCM_CYGNUS=y
 CONFIG_ARCH_BCM_NSP=y
-CONFIG_ARCH_BCM_21664=y
-CONFIG_ARCH_BCM_281XX=y
 CONFIG_ARCH_BCM_5301X=y
+CONFIG_ARCH_BCM_281XX=y
+CONFIG_ARCH_BCM_21664=y
 CONFIG_ARCH_BRCMSTB=y
 CONFIG_ARCH_BERLIN=y
 CONFIG_MACH_BERLIN_BG2=y
@@ -39,9 +39,9 @@ CONFIG_ARCH_DIGICOLOR=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_HISI=y
 CONFIG_ARCH_HI3xxx=y
-CONFIG_ARCH_HIX5HD2=y
 CONFIG_ARCH_HIP01=y
 CONFIG_ARCH_HIP04=y
+CONFIG_ARCH_HIX5HD2=y
 CONFIG_ARCH_KEYSTONE=y
 CONFIG_ARCH_MESON=y
 CONFIG_ARCH_MXC=y
@@ -53,8 +53,9 @@ CONFIG_SOC_IMX6SL=y
 CONFIG_SOC_IMX6SX=y
 CONFIG_SOC_IMX6UL=y
 CONFIG_SOC_IMX7D=y
-CONFIG_SOC_VF610=y
 CONFIG_SOC_LS1021A=y
+CONFIG_SOC_VF610=y
+CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_OMAP3=y
 CONFIG_ARCH_OMAP4=y
 CONFIG_SOC_OMAP5=y
@@ -62,7 +63,6 @@ CONFIG_SOC_AM33XX=y
 CONFIG_SOC_AM43XX=y
 CONFIG_SOC_DRA7XX=y
 CONFIG_ARCH_QCOM=y
-CONFIG_ARCH_MEDIATEK=y
 CONFIG_ARCH_MSM8X60=y
 CONFIG_ARCH_MSM8960=y
 CONFIG_ARCH_MSM8974=y
@@ -94,30 +94,22 @@ CONFIG_ARCH_TEGRA_2x_SOC=y
 CONFIG_ARCH_TEGRA_3x_SOC=y
 CONFIG_ARCH_TEGRA_114_SOC=y
 CONFIG_ARCH_TEGRA_124_SOC=y
-CONFIG_TEGRA_EMC_SCALING_ENABLE=y
 CONFIG_ARCH_UNIPHIER=y
 CONFIG_ARCH_U8500=y
 CONFIG_MACH_HREFV60=y
 CONFIG_MACH_SNOWBALL=y
-CONFIG_MACH_UX500_DT=y
 CONFIG_ARCH_VEXPRESS=y
-CONFIG_ARCH_VEXPRESS_CA9X4=y
 CONFIG_ARCH_VEXPRESS_TC2_PM=y
 CONFIG_ARCH_WM8850=y
 CONFIG_ARCH_ZYNQ=y
-CONFIG_TRUSTED_FOUNDATIONS=y
-CONFIG_PCI=y
-CONFIG_PCI_HOST_GENERIC=y
-CONFIG_PCI_KEYSTONE=y
 CONFIG_PCI_MSI=y
 CONFIG_PCI_MVEBU=y
 CONFIG_PCI_TEGRA=y
 CONFIG_PCI_RCAR_GEN2=y
 CONFIG_PCI_RCAR_GEN2_PCIE=y
-CONFIG_PCIEPORTBUS=y
+CONFIG_PCI_KEYSTONE=y
 CONFIG_SMP=y
 CONFIG_NR_CPUS=16
-CONFIG_HIGHPTE=y
 CONFIG_CMA=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
@@ -125,12 +117,12 @@ CONFIG_KEXEC=y
 CONFIG_CPU_FREQ=y
 CONFIG_CPU_FREQ_STAT_DETAILS=y
 CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
+CONFIG_CPUFREQ_DT=y
 CONFIG_CPU_IDLE=y
 CONFIG_ARM_CPUIDLE=y
-CONFIG_NEON=y
-CONFIG_KERNEL_MODE_NEON=y
 CONFIG_ARM_ZYNQ_CPUIDLE=y
 CONFIG_ARM_EXYNOS_CPUIDLE=y
+CONFIG_KERNEL_MODE_NEON=y
 CONFIG_NET=y
 CONFIG_PACKET=y
 CONFIG_UNIX=y
@@ -148,13 +140,10 @@ CONFIG_IPV6_MIP6=m
 CONFIG_IPV6_TUNNEL=m
 CONFIG_IPV6_MULTIPLE_TABLES=y
 CONFIG_CAN=y
-CONFIG_CAN_RAW=y
-CONFIG_CAN_BCM=y
-CONFIG_CAN_DEV=y
 CONFIG_CAN_AT91=m
+CONFIG_CAN_SUN4I=y
 CONFIG_CAN_XILINXCAN=y
 CONFIG_CAN_MCP251X=y
-CONFIG_CAN_SUN4I=y
 CONFIG_BT=m
 CONFIG_BT_MRVL=m
 CONFIG_BT_MRVL_SDIO=m
@@ -188,10 +177,8 @@ CONFIG_ATMEL_SSC=m
 CONFIG_APDS9802ALS=y
 CONFIG_ISL29003=y
 CONFIG_EEPROM_AT24=y
-CONFIG_EEPROM_SUNXI_SID=y
 CONFIG_BLK_DEV_SD=y
 CONFIG_BLK_DEV_SR=y
-CONFIG_SCSI_MULTI_LUN=y
 CONFIG_ATA=y
 CONFIG_SATA_AHCI=y
 CONFIG_SATA_AHCI_PLATFORM=y
@@ -202,10 +189,10 @@ CONFIG_SATA_HIGHBANK=y
 CONFIG_SATA_MV=y
 CONFIG_SATA_RCAR=y
 CONFIG_NETDEVICES=y
-CONFIG_HIX5HD2_GMAC=y
 CONFIG_SUN4I_EMAC=y
 CONFIG_MACB=y
 CONFIG_NET_CALXEDA_XGMAC=y
+CONFIG_HIX5HD2_GMAC=y
 CONFIG_IGB=y
 CONFIG_MV643XX_ETH=y
 CONFIG_MVNETA=y
@@ -223,7 +210,6 @@ CONFIG_SMSC_PHY=y
 CONFIG_BROADCOM_PHY=y
 CONFIG_ICPLUS_PHY=y
 CONFIG_MICREL_PHY=y
-CONFIG_FIXED_PHY=y
 CONFIG_USB_PEGASUS=y
 CONFIG_USB_RTL8152=m
 CONFIG_USB_USBNET=y
@@ -239,18 +225,18 @@ CONFIG_INPUT_EVDEV=y
 CONFIG_KEYBOARD_QT1070=m
 CONFIG_KEYBOARD_GPIO=y
 CONFIG_KEYBOARD_TEGRA=y
-CONFIG_KEYBOARD_SPEAR=y
 CONFIG_KEYBOARD_ST_KEYSCAN=y
+CONFIG_KEYBOARD_SPEAR=y
 CONFIG_KEYBOARD_CROS_EC=y
 CONFIG_MOUSE_PS2_ELANTECH=y
 CONFIG_MOUSE_CYAPA=m
 CONFIG_MOUSE_ELAN_I2C=y
 CONFIG_INPUT_TOUCHSCREEN=y
 CONFIG_TOUCHSCREEN_ATMEL_MXT=y
+CONFIG_TOUCHSCREEN_WM97XX=m
 CONFIG_TOUCHSCREEN_ST1232=m
 CONFIG_TOUCHSCREEN_STMPE=y
 CONFIG_TOUCHSCREEN_SUN4I=y
-CONFIG_TOUCHSCREEN_WM97XX=m
 CONFIG_INPUT_MISC=y
 CONFIG_INPUT_MPU3050=y
 CONFIG_INPUT_AXP20X_PEK=y
@@ -295,17 +281,16 

[linux-sunxi] Re: [PATCH] ARM: sunxi: Re-enable SID driver in multi_v7_defconfig

[Krzysztof Kozlowski]

On 17.11.2015 10:49, Timo Sigurdsson wrote:
> Commit 3d0b16a66c8a ("nvmem: sunxi: Move the SID driver to the nvmem
> framework") moved the the sunxi SID driver to a new framework, but left
> multi_v7_defconfig with the deprecated config symbol EEPROM_SUNXI_SID
> instead of the new symbold NVMEM_SUNXI_SID. Hence, re-enable the driver
> in multi_v7_defconfig.
> 
> While at it, clean up multi_v7_defconfig by generating a fresh file via
>   make multi_v7_defconfig
>   make savedefconfig
> While this moves around a few lines and removes unnecessary symbols,
> it doesn't introduce any functional changes.

Split it per change. One change is savedefconfig and second is removing
or enabling other drivers.

On which tree you generated the defconfig? There is a minor nit below
(at least for Exynos platform, I did not checked the others).

> 
> Signed-off-by: Timo Sigurdsson 
> 
> diff --git a/arch/arm/configs/multi_v7_defconfig 
> b/arch/arm/configs/multi_v7_defconfig
> index 69a22fd..f712ea3 100644
> --- a/arch/arm/configs/multi_v7_defconfig
> +++ b/arch/arm/configs/multi_v7_defconfig

(...)

> @@ -450,8 +431,7 @@ CONFIG_MEDIA_CAMERA_SUPPORT=y
>  CONFIG_MEDIA_CONTROLLER=y
>  CONFIG_VIDEO_V4L2_SUBDEV_API=y
>  CONFIG_MEDIA_USB_SUPPORT=y
> -CONFIG_USB_VIDEO_CLASS=y
> -CONFIG_USB_GSPCA=y
> +CONFIG_USB_VIDEO_CLASS=m
>  CONFIG_V4L_PLATFORM_DRIVERS=y
>  CONFIG_SOC_CAMERA=m
>  CONFIG_SOC_CAMERA_PLATFORM=m
> @@ -465,28 +445,25 @@ CONFIG_DRM=y
>  CONFIG_DRM_I2C_ADV7511=m
>  # CONFIG_DRM_I2C_CH7006 is not set
>  # CONFIG_DRM_I2C_SIL164 is not set
> -CONFIG_DRM_NXP_PTN3460=m
> -CONFIG_DRM_PARADE_PS8622=m
>  CONFIG_DRM_NOUVEAU=m
>  CONFIG_DRM_EXYNOS=m
> -CONFIG_DRM_EXYNOS_DSI=y
>  CONFIG_DRM_EXYNOS_FIMD=y
> -CONFIG_DRM_EXYNOS_HDMI=y

I would prefer leaving the EXYNOS_HDMI. Dependencies are now not enabled
but we are fixing it in:
http://www.spinics.net/lists/dri-devel/msg93299.html

Best regards,
Krzysztof

> +CONFIG_DRM_EXYNOS_DSI=y
>  CONFIG_DRM_ROCKCHIP=m
>  CONFIG_ROCKCHIP_DW_HDMI=m
>  CONFIG_DRM_RCAR_DU=m
>  CONFIG_DRM_RCAR_HDMI=y
>  CONFIG_DRM_RCAR_LVDS=y
>  CONFIG_DRM_TEGRA=y
> -CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
>  CONFIG_DRM_PANEL_SIMPLE=y
> +CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0=m
> +CONFIG_DRM_NXP_PTN3460=m
> +CONFIG_DRM_PARADE_PS8622=m
>  CONFIG_FB_ARMCLCD=y
>  CONFIG_FB_WM8505=y
>  CONFIG_FB_SH_MOBILE_LCDC=y
>  CONFIG_FB_SIMPLE=y
>  CONFIG_FB_SH_MOBILE_MERAM=y
> -CONFIG_BACKLIGHT_LCD_SUPPORT=y
> -CONFIG_BACKLIGHT_CLASS_DEVICE=y
>  CONFIG_LCD_PLATFORM=m
>  CONFIG_BACKLIGHT_PWM=y
>  CONFIG_BACKLIGHT_AS3711=y

-- 
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 v4 01/24] pwm: rcar: make use of pwm_is_enabled()

[Boris Brezillon]

Commit 5c31252c4a86 ("pwm: Add the pwm_is_enabled() helper") introduced a
new function to test whether a PWM device is enabled or not without
manipulating PWM internal fields.
Hiding this is necessary if we want to smoothly move to the atomic PWM
config approach without impacting PWM drivers.
Fix this driver to use pwm_is_enabled() instead of directly accessing the
->flags field.

Signed-off-by: Boris Brezillon 
---
 drivers/pwm/pwm-rcar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pwm/pwm-rcar.c b/drivers/pwm/pwm-rcar.c
index 6e99a63..70899c9 100644
--- a/drivers/pwm/pwm-rcar.c
+++ b/drivers/pwm/pwm-rcar.c
@@ -157,7 +157,7 @@ static int rcar_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
return div;
 
/* Let the core driver set pwm->period if disabled and duty_ns == 0 */
-   if (!test_bit(PWMF_ENABLED, >flags) && !duty_ns)
+   if (!pwm_is_enabled(pwm) && !duty_ns)
return 0;
 
rcar_pwm_update(rp, RCAR_PWMCR_SYNC, RCAR_PWMCR_SYNC, RCAR_PWMCR);
-- 
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 v4 00/24] pwm: add support for atomic update

[Boris Brezillon]

Hello,

This series adds support for atomic PWM update, or IOW, the capability
to update all the parameters of a PWM device (enabled/disabled, period,
duty and polarity) in one go.

Best Regards,

Boris

Changes since v3:
- rebased on pwm/for-next after pulling 4.4-rc1
- replace direct access to pwm fields by pwm_get/set_xxx() helpers, thus
  fixing some build errors
- split changes to allow each maintainer to review/ack or take the
  modification through its subsystem

Changes since v2:
- rebased on top of 4.3-rc2
- reintroduced pwm-regulator patches

Changes since v1:
- dropped applied patches
- squashed Heiko's fixes into the rockchip driver changes
- made a few cosmetic changes
- added kerneldoc comments
- added Heiko's patch to display more information in debugfs
- dropped pwm-regulator patches (should be submitted separately)

Boris Brezillon (23):
  pwm: rcar: make use of pwm_is_enabled()
  pwm: use pwm_get_xxx() helpers where appropriate
  clk: pwm: use pwm_get_xxx() helpers where appropriate
  hwmon: pwm-fan: use pwm_get_xxx() helpers where appropriate
  misc: max77693-haptic: use pwm_get_xxx() helpers where appropriate
  pwm: introduce default period and polarity concepts
  pwm: use pwm_get/set_default_xxx() helpers where appropriate
  leds: pwm: use pwm_get/set_default_xxx() helpers where appropriate
  regulator: pwm: use pwm_get/set_default_xxx() helpers where
appropriate
  backlight: pwm: use pwm_get/set_default_xxx() helpers where
appropriate
  fbdev: use pwm_get/set_default_xxx() helpers where appropriate
  misc: max77693: use pwm_get/set_default_xxx() helpers where
appropriate
  hwmon: pwm-fan: use pwm_get/set_default_xxx() helpers where
appropriate
  clk: pwm: use pwm_get/set_default_xxx() helpers where appropriate
  pwm: define a new pwm_state struct
  pwm: move the enabled/disabled info to pwm_state struct
  backlight: pwm_bl: remove useless call to pwm_set_period
  pwm: declare a default PWM state
  pwm: add the PWM initial state retrieval infra
  pwm: add the core infrastructure to allow atomic update
  pwm: rockchip: add initial state retrieval
  pwm: rockchip: add support for atomic update
  regulator: pwm: properly initialize the ->state field

Heiko Stübner (1):
  pwm: add information about polarity, duty cycle and period to debugfs

 drivers/clk/clk-pwm.c|  11 +--
 drivers/hwmon/pwm-fan.c  |  16 ++--
 drivers/input/misc/max77693-haptic.c |   9 +-
 drivers/leds/leds-pwm.c  |   2 +-
 drivers/pwm/core.c   | 169 +++
 drivers/pwm/pwm-crc.c|   2 +-
 drivers/pwm/pwm-lpc18xx-sct.c|   2 +-
 drivers/pwm/pwm-pxa.c|   2 +-
 drivers/pwm/pwm-rcar.c   |   2 +-
 drivers/pwm/pwm-rockchip.c   | 119 +++-
 drivers/pwm/pwm-sun4i.c  |   3 +-
 drivers/regulator/pwm-regulator.c|  30 ++-
 drivers/video/backlight/lm3630a_bl.c |   4 +-
 drivers/video/backlight/pwm_bl.c |  10 ++-
 drivers/video/fbdev/ssd1307fb.c  |   2 +-
 include/linux/pwm.h  |  89 +++---
 16 files changed, 386 insertions(+), 86 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 v4 03/24] clk: pwm: use pwm_get_xxx() helpers where appropriate

[Boris Brezillon]

Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
Doing that will ease adaptation of the PWM framework to support atomic
update.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

--->8---
virtual patch

@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity((p), e);
|
-(p)->polarity
+pwm_get_polarity((p))
|
-(p)->period = e;
+pwm_set_period((p), e);
|
-(p)->period
+pwm_get_period((p))
|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle((p), e);
|
-(p)->duty_cycle
+pwm_get_duty_cycle((p))
)
--->8---
---
 drivers/clk/clk-pwm.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
index 328fcfc..b6306a2 100644
--- a/drivers/clk/clk-pwm.c
+++ b/drivers/clk/clk-pwm.c
@@ -71,22 +71,23 @@ static int clk_pwm_probe(struct platform_device *pdev)
if (IS_ERR(pwm))
return PTR_ERR(pwm);
 
-   if (!pwm->period) {
+   if (!pwm_get_period((pwm))) {
dev_err(>dev, "invalid PWM period\n");
return -EINVAL;
}
 
if (of_property_read_u32(node, "clock-frequency", _pwm->fixed_rate))
-   clk_pwm->fixed_rate = NSEC_PER_SEC / pwm->period;
+   clk_pwm->fixed_rate = NSEC_PER_SEC / pwm_get_period((pwm));
 
-   if (pwm->period != NSEC_PER_SEC / clk_pwm->fixed_rate &&
-   pwm->period != DIV_ROUND_UP(NSEC_PER_SEC, clk_pwm->fixed_rate)) {
+   if (pwm_get_period((pwm)) != NSEC_PER_SEC / clk_pwm->fixed_rate &&
+   pwm_get_period((pwm)) != DIV_ROUND_UP(NSEC_PER_SEC, 
clk_pwm->fixed_rate)) {
dev_err(>dev,
"clock-frequency does not match PWM period\n");
return -EINVAL;
}
 
-   ret = pwm_config(pwm, (pwm->period + 1) >> 1, pwm->period);
+   ret = pwm_config(pwm, (pwm_get_period((pwm)) + 1) >> 1,
+pwm_get_period((pwm)));
if (ret < 0)
return ret;
 
-- 
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 v4 06/24] pwm: introduce default period and polarity concepts

[Boris Brezillon]

When requested by a user, the PWM is assigned a default period and polarity
extracted from the DT, the platform data or statically set by the driver.
Those default values are currently stored in the period and polarity
fields of the pwm_device struct, but they will be stored somewhere else
once we have introduced the architecture allowing for hardware state
retrieval.

The pwm_set_default_polarity and pwm_set_default_period should only be
used by PWM drivers or the PWM core infrastructure to specify the
default period and polarity values.

PWM users might call the pwm_get_default_period to query the default
period value. There is currently no helper to query the default
polarity, but it might be added later on if there is a need for it.

Signed-off-by: Boris Brezillon 
Tested-by: Heiko Stuebner 
---
 include/linux/pwm.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index cfc3ed4..8ba57fc 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -118,11 +118,22 @@ static inline void pwm_set_period(struct pwm_device *pwm, 
unsigned int period)
pwm->period = period;
 }
 
+static inline void pwm_set_default_period(struct pwm_device *pwm,
+ unsigned int period)
+{
+   pwm_set_period(pwm, period);
+}
+
 static inline unsigned int pwm_get_period(const struct pwm_device *pwm)
 {
return pwm ? pwm->period : 0;
 }
 
+static inline unsigned int pwm_get_default_period(const struct pwm_device *pwm)
+{
+   return pwm_get_period(pwm);
+}
+
 static inline void pwm_set_duty_cycle(struct pwm_device *pwm, unsigned int 
duty)
 {
if (pwm)
@@ -139,6 +150,12 @@ static inline unsigned int pwm_get_duty_cycle(const struct 
pwm_device *pwm)
  */
 int pwm_set_polarity(struct pwm_device *pwm, enum pwm_polarity polarity);
 
+static inline void pwm_set_default_polarity(struct pwm_device *pwm,
+   enum pwm_polarity polarity)
+{
+   pwm_set_polarity(pwm, polarity);
+}
+
 static inline enum pwm_polarity pwm_get_polarity(const struct pwm_device *pwm)
 {
return pwm ? pwm->polarity : PWM_POLARITY_NORMAL;
-- 
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 v4 23/24] pwm: rockchip: add support for atomic update

[Boris Brezillon]

Implement the ->apply() function to add support for atomic update.

Signed-off-by: Boris Brezillon 
Tested-by: Heiko Stuebner 
---
 drivers/pwm/pwm-rockchip.c | 53 +-
 1 file changed, 29 insertions(+), 24 deletions(-)

diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 6eab25c..48b814d 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -50,7 +50,8 @@ struct rockchip_pwm_data {
const struct pwm_ops *ops;
 
void (*set_enable)(struct pwm_chip *chip,
-  struct pwm_device *pwm, bool enable);
+  struct pwm_device *pwm, bool enable,
+  enum pwm_polarity polarity);
void (*reset_state)(struct pwm_chip *chip, struct pwm_device *pwm);
 };
 
@@ -60,7 +61,8 @@ static inline struct rockchip_pwm_chip 
*to_rockchip_pwm_chip(struct pwm_chip *c)
 }
 
 static void rockchip_pwm_set_enable_v1(struct pwm_chip *chip,
-  struct pwm_device *pwm, bool enable)
+  struct pwm_device *pwm, bool enable,
+  enum pwm_polarity polarity)
 {
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
u32 enable_conf = PWM_CTRL_OUTPUT_EN | PWM_CTRL_TIMER_EN;
@@ -89,14 +91,15 @@ static void rockchip_pwm_reset_state_v1(struct pwm_chip 
*chip,
 }
 
 static void rockchip_pwm_set_enable_v2(struct pwm_chip *chip,
-  struct pwm_device *pwm, bool enable)
+  struct pwm_device *pwm, bool enable,
+  enum pwm_polarity polarity)
 {
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
u32 enable_conf = PWM_OUTPUT_LEFT | PWM_LP_DISABLE | PWM_ENABLE |
  PWM_CONTINUOUS;
u32 val;
 
-   if (pwm_get_polarity(pwm) == PWM_POLARITY_INVERSED)
+   if (polarity == PWM_POLARITY_INVERSED)
enable_conf |= PWM_DUTY_NEGATIVE | PWM_INACTIVE_POSITIVE;
else
enable_conf |= PWM_DUTY_POSITIVE | PWM_INACTIVE_NEGATIVE;
@@ -165,7 +168,6 @@ static int rockchip_pwm_config(struct pwm_chip *chip, 
struct pwm_device *pwm,
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
unsigned long period, duty;
u64 clk_rate, div;
-   int ret;
 
clk_rate = clk_get_rate(pc->clk);
 
@@ -182,15 +184,8 @@ static int rockchip_pwm_config(struct pwm_chip *chip, 
struct pwm_device *pwm,
do_div(div, pc->data->prescaler * NSEC_PER_SEC);
duty = div;
 
-   ret = clk_enable(pc->clk);
-   if (ret)
-   return ret;
-
writel(period, pc->base + pc->data->regs.period);
writel(duty, pc->base + pc->data->regs.duty);
-   writel(0, pc->base + pc->data->regs.cntr);
-
-   clk_disable(pc->clk);
 
return 0;
 }
@@ -208,43 +203,53 @@ static int rockchip_pwm_set_polarity(struct pwm_chip 
*chip,
return 0;
 }
 
-static int rockchip_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
+static int rockchip_pwm_apply(struct pwm_chip *chip, struct pwm_device *pwm,
+ const struct pwm_state *state)
 {
struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+   bool enabled = pwm_is_enabled(pwm);
int ret;
 
ret = clk_enable(pc->clk);
if (ret)
return ret;
 
-   pc->data->set_enable(chip, pwm, true);
+   if (state->polarity != pwm_get_polarity(pwm) && enabled) {
+   pc->data->set_enable(chip, pwm, false, state->polarity);
+   enabled = false;
+   }
 
-   return 0;
-}
+   ret = rockchip_pwm_config(chip, pwm, state->duty_cycle, state->period);
+   if (ret) {
+   if (enabled != pwm_is_enabled(pwm))
+   pc->data->set_enable(chip, pwm, !enabled,
+state->polarity);
 
-static void rockchip_pwm_disable(struct pwm_chip *chip, struct pwm_device *pwm)
-{
-   struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+   goto out;
+   }
 
-   pc->data->set_enable(chip, pwm, false);
+   if (state->enabled != enabled)
+   pc->data->set_enable(chip, pwm, state->enabled,
+state->polarity);
 
+out:
clk_disable(pc->clk);
+
+   return ret;
 }
 
 static const struct pwm_ops rockchip_pwm_ops_v1 = {
.reset_state = rockchip_pwm_reset_state,
.config = rockchip_pwm_config,
-   .enable = rockchip_pwm_enable,
-   .disable = rockchip_pwm_disable,
+   .apply = rockchip_pwm_apply,
.owner = THIS_MODULE,
 };
 
 static const struct pwm_ops rockchip_pwm_ops_v2 = {
.reset_state = rockchip_pwm_reset_state,
.config = rockchip_pwm_config,
+   

[linux-sunxi] [PATCH v4 22/24] pwm: rockchip: add initial state retrieval

[Boris Brezillon]

Implement the ->reset_state() function to expose initial state.

Signed-off-by: Boris Brezillon 
Tested-by: Heiko Stuebner 
---
 drivers/pwm/pwm-rockchip.c | 66 ++
 1 file changed, 66 insertions(+)

diff --git a/drivers/pwm/pwm-rockchip.c b/drivers/pwm/pwm-rockchip.c
index 7d9cc90..6eab25c 100644
--- a/drivers/pwm/pwm-rockchip.c
+++ b/drivers/pwm/pwm-rockchip.c
@@ -51,6 +51,7 @@ struct rockchip_pwm_data {
 
void (*set_enable)(struct pwm_chip *chip,
   struct pwm_device *pwm, bool enable);
+   void (*reset_state)(struct pwm_chip *chip, struct pwm_device *pwm);
 };
 
 static inline struct rockchip_pwm_chip *to_rockchip_pwm_chip(struct pwm_chip 
*c)
@@ -75,6 +76,18 @@ static void rockchip_pwm_set_enable_v1(struct pwm_chip *chip,
writel_relaxed(val, pc->base + pc->data->regs.ctrl);
 }
 
+static void rockchip_pwm_reset_state_v1(struct pwm_chip *chip,
+   struct pwm_device *pwm)
+{
+   struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+   u32 enable_conf = PWM_CTRL_OUTPUT_EN | PWM_CTRL_TIMER_EN;
+   u32 val;
+
+   val = readl(pc->base + pc->data->regs.ctrl);
+   if ((val & enable_conf) == enable_conf)
+   pwm->state.enabled = true;
+}
+
 static void rockchip_pwm_set_enable_v2(struct pwm_chip *chip,
   struct pwm_device *pwm, bool enable)
 {
@@ -98,6 +111,54 @@ static void rockchip_pwm_set_enable_v2(struct pwm_chip 
*chip,
writel_relaxed(val, pc->base + pc->data->regs.ctrl);
 }
 
+static void rockchip_pwm_reset_state_v2(struct pwm_chip *chip,
+   struct pwm_device *pwm)
+{
+   struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+   u32 enable_conf = PWM_OUTPUT_LEFT | PWM_LP_DISABLE | PWM_ENABLE |
+ PWM_CONTINUOUS;
+   u32 val;
+
+   val = readl(pc->base + pc->data->regs.ctrl);
+   if ((val & enable_conf) != enable_conf)
+   return;
+
+   pwm->state.enabled = true;
+
+   if (!(val & PWM_DUTY_POSITIVE))
+   pwm->state.polarity = PWM_POLARITY_INVERSED;
+}
+
+static void rockchip_pwm_reset_state(struct pwm_chip *chip,
+struct pwm_device *pwm)
+{
+   struct rockchip_pwm_chip *pc = to_rockchip_pwm_chip(chip);
+   unsigned long clk_rate;
+   u64 tmp;
+   int ret;
+
+   ret = clk_enable(pc->clk);
+   if (ret)
+   return;
+
+   clk_rate = clk_get_rate(pc->clk);
+
+   tmp = readl(pc->base + pc->data->regs.period);
+   tmp *= pc->data->prescaler * NSEC_PER_SEC;
+   do_div(tmp, clk_rate);
+   pwm->state.period = tmp;
+
+   tmp = readl(pc->base + pc->data->regs.duty);
+   tmp *= pc->data->prescaler * NSEC_PER_SEC;
+   do_div(tmp, clk_rate);
+   pwm->state.duty_cycle = tmp;
+
+   pc->data->reset_state(chip, chip->pwms);
+
+   if (!pwm_is_enabled(pwm))
+   clk_disable(pc->clk);
+}
+
 static int rockchip_pwm_config(struct pwm_chip *chip, struct pwm_device *pwm,
   int duty_ns, int period_ns)
 {
@@ -171,6 +232,7 @@ static void rockchip_pwm_disable(struct pwm_chip *chip, 
struct pwm_device *pwm)
 }
 
 static const struct pwm_ops rockchip_pwm_ops_v1 = {
+   .reset_state = rockchip_pwm_reset_state,
.config = rockchip_pwm_config,
.enable = rockchip_pwm_enable,
.disable = rockchip_pwm_disable,
@@ -178,6 +240,7 @@ static const struct pwm_ops rockchip_pwm_ops_v1 = {
 };
 
 static const struct pwm_ops rockchip_pwm_ops_v2 = {
+   .reset_state = rockchip_pwm_reset_state,
.config = rockchip_pwm_config,
.set_polarity = rockchip_pwm_set_polarity,
.enable = rockchip_pwm_enable,
@@ -195,6 +258,7 @@ static const struct rockchip_pwm_data pwm_data_v1 = {
.prescaler = 2,
.ops = _pwm_ops_v1,
.set_enable = rockchip_pwm_set_enable_v1,
+   .reset_state = rockchip_pwm_reset_state_v1,
 };
 
 static const struct rockchip_pwm_data pwm_data_v2 = {
@@ -207,6 +271,7 @@ static const struct rockchip_pwm_data pwm_data_v2 = {
.prescaler = 1,
.ops = _pwm_ops_v2,
.set_enable = rockchip_pwm_set_enable_v2,
+   .reset_state = rockchip_pwm_reset_state_v2,
 };
 
 static const struct rockchip_pwm_data pwm_data_vop = {
@@ -219,6 +284,7 @@ static const struct rockchip_pwm_data pwm_data_vop = {
.prescaler = 1,
.ops = _pwm_ops_v2,
.set_enable = rockchip_pwm_set_enable_v2,
+   .reset_state = rockchip_pwm_reset_state_v2,
 };
 
 static const struct of_device_id rockchip_pwm_dt_ids[] = {
-- 
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] [PATCH v4 15/24] pwm: define a new pwm_state struct

[Boris Brezillon]

The PWM state, represented by its period, duty_cycle and polarity,
is currently directly stored in the PWM device.
Declare a pwm_state structure embedding those field so that we can later
use this struct to atomically update all the PWM parameters at once.

Signed-off-by: Boris Brezillon 
---
 drivers/pwm/core.c  |  6 +++---
 include/linux/pwm.h | 30 +++---
 2 files changed, 22 insertions(+), 14 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 59073a1..f1c6769 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -447,8 +447,8 @@ int pwm_config(struct pwm_device *pwm, int duty_ns, int 
period_ns)
if (err)
return err;
 
-   pwm->duty_cycle = duty_ns;
-   pwm->period = period_ns;
+   pwm->state.duty_cycle = duty_ns;
+   pwm->state.period = period_ns;
 
return 0;
 }
@@ -485,7 +485,7 @@ int pwm_set_polarity(struct pwm_device *pwm, enum 
pwm_polarity polarity)
if (err)
goto unlock;
 
-   pwm->polarity = polarity;
+   pwm->state.polarity = polarity;
 
 unlock:
mutex_unlock(>lock);
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 8ba57fc..af42299 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -80,6 +80,18 @@ enum {
PWMF_EXPORTED = 1 << 2,
 };
 
+/*
+ * struct pwm_state - state of a PWM channel
+ * @period: PWM period (in nanoseconds)
+ * @duty_cycle: PWM duty cycle (in nanoseconds)
+ * @polarity: PWM polarity
+ */
+struct pwm_state {
+   unsigned int period;
+   unsigned int duty_cycle;
+   enum pwm_polarity polarity;
+};
+
 /**
  * struct pwm_device - PWM channel object
  * @label: name of the PWM device
@@ -89,9 +101,7 @@ enum {
  * @chip: PWM chip providing this PWM device
  * @chip_data: chip-private data associated with the PWM device
  * @lock: used to serialize accesses to the PWM device where necessary
- * @period: period of the PWM signal (in nanoseconds)
- * @duty_cycle: duty cycle of the PWM signal (in nanoseconds)
- * @polarity: polarity of the PWM signal
+ * @state: curent PWM channel state
  */
 struct pwm_device {
const char *label;
@@ -102,9 +112,7 @@ struct pwm_device {
void *chip_data;
struct mutex lock;
 
-   unsigned int period;
-   unsigned int duty_cycle;
-   enum pwm_polarity polarity;
+   struct pwm_state state;
 };
 
 static inline bool pwm_is_enabled(const struct pwm_device *pwm)
@@ -115,7 +123,7 @@ static inline bool pwm_is_enabled(const struct pwm_device 
*pwm)
 static inline void pwm_set_period(struct pwm_device *pwm, unsigned int period)
 {
if (pwm)
-   pwm->period = period;
+   pwm->state.period = period;
 }
 
 static inline void pwm_set_default_period(struct pwm_device *pwm,
@@ -126,7 +134,7 @@ static inline void pwm_set_default_period(struct pwm_device 
*pwm,
 
 static inline unsigned int pwm_get_period(const struct pwm_device *pwm)
 {
-   return pwm ? pwm->period : 0;
+   return pwm ? pwm->state.period : 0;
 }
 
 static inline unsigned int pwm_get_default_period(const struct pwm_device *pwm)
@@ -137,12 +145,12 @@ static inline unsigned int pwm_get_default_period(const 
struct pwm_device *pwm)
 static inline void pwm_set_duty_cycle(struct pwm_device *pwm, unsigned int 
duty)
 {
if (pwm)
-   pwm->duty_cycle = duty;
+   pwm->state.duty_cycle = duty;
 }
 
 static inline unsigned int pwm_get_duty_cycle(const struct pwm_device *pwm)
 {
-   return pwm ? pwm->duty_cycle : 0;
+   return pwm ? pwm->state.duty_cycle : 0;
 }
 
 /*
@@ -158,7 +166,7 @@ static inline void pwm_set_default_polarity(struct 
pwm_device *pwm,
 
 static inline enum pwm_polarity pwm_get_polarity(const struct pwm_device *pwm)
 {
-   return pwm ? pwm->polarity : PWM_POLARITY_NORMAL;
+   return pwm ? pwm->state.polarity : PWM_POLARITY_NORMAL;
 }
 
 /**
-- 
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 v4 19/24] pwm: add the PWM initial state retrieval infra

[Boris Brezillon]

Add a ->reset_state() function to the pwm_ops struct to let PWM drivers
initialize the PWM state attached to a PWM device.

Signed-off-by: Boris Brezillon 
Tested-by: Heiko Stuebner 
---
 drivers/pwm/core.c  | 3 +++
 include/linux/pwm.h | 4 
 2 files changed, 7 insertions(+)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 6bbda6c..ce8b373 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -271,6 +271,9 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
pwm_set_default_polarity(pwm, polarity);
mutex_init(>lock);
 
+   if (chip->ops->reset_state)
+   chip->ops->reset_state(chip, pwm);
+
radix_tree_insert(_tree, pwm->pwm, pwm);
}
 
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 292e7da..caa0ffe 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -182,6 +182,9 @@ static inline enum pwm_polarity pwm_get_polarity(const 
struct pwm_device *pwm)
  * @set_polarity: configure the polarity of this PWM
  * @enable: enable PWM output toggling
  * @disable: disable PWM output toggling
+ * @reset_state: reset the current PWM state (pwm->state) to the actual
+ *  hardware state. This function is only called once per
+ *  PWM device when the PWM chip is registered.
  * @dbg_show: optional routine to show contents in debugfs
  * @owner: helps prevent removal of modules exporting active PWMs
  */
@@ -194,6 +197,7 @@ struct pwm_ops {
enum pwm_polarity polarity);
int (*enable)(struct pwm_chip *chip, struct pwm_device *pwm);
void (*disable)(struct pwm_chip *chip, struct pwm_device *pwm);
+   void (*reset_state)(struct pwm_chip *chip, struct pwm_device *pwm);
 #ifdef CONFIG_DEBUG_FS
void (*dbg_show)(struct pwm_chip *chip, struct seq_file *s);
 #endif
-- 
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 v4 04/24] hwmon: pwm-fan: use pwm_get_xxx() helpers where appropriate

[Boris Brezillon]

Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
Doing that will ease adaptation of the PWM framework to support atomic
update.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

--->8---
virtual patch

@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity((p), e);
|
-(p)->polarity
+pwm_get_polarity((p))
|
-(p)->period = e;
+pwm_set_period((p), e);
|
-(p)->period
+pwm_get_period((p))
|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle((p), e);
|
-(p)->duty_cycle
+pwm_get_duty_cycle((p))
)
--->8---
---
 drivers/hwmon/pwm-fan.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 3e23003..105b964 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -47,8 +47,8 @@ static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long 
pwm)
if (ctx->pwm_value == pwm)
goto exit_set_pwm_err;
 
-   duty = DIV_ROUND_UP(pwm * (ctx->pwm->period - 1), MAX_PWM);
-   ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
+   duty = DIV_ROUND_UP(pwm * (pwm_get_period((ctx->pwm)) - 1), MAX_PWM);
+   ret = pwm_config(ctx->pwm, duty, pwm_get_period((ctx->pwm)));
if (ret)
goto exit_set_pwm_err;
 
@@ -234,10 +234,10 @@ static int pwm_fan_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);
 
/* Set duty cycle to maximum allowed */
-   duty_cycle = ctx->pwm->period - 1;
+   duty_cycle = pwm_get_period((ctx->pwm)) - 1;
ctx->pwm_value = MAX_PWM;
 
-   ret = pwm_config(ctx->pwm, duty_cycle, ctx->pwm->period);
+   ret = pwm_config(ctx->pwm, duty_cycle, pwm_get_period((ctx->pwm)));
if (ret) {
dev_err(>dev, "Failed to configure PWM\n");
return ret;
@@ -309,8 +309,9 @@ static int pwm_fan_resume(struct device *dev)
if (ctx->pwm_value == 0)
return 0;
 
-   duty = DIV_ROUND_UP(ctx->pwm_value * (ctx->pwm->period - 1), MAX_PWM);
-   ret = pwm_config(ctx->pwm, duty, ctx->pwm->period);
+   duty = DIV_ROUND_UP(ctx->pwm_value * (pwm_get_period((ctx->pwm)) - 1),
+   MAX_PWM);
+   ret = pwm_config(ctx->pwm, duty, pwm_get_period((ctx->pwm)));
if (ret)
return ret;
return pwm_enable(ctx->pwm);
-- 
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 v4 05/24] misc: max77693-haptic: use pwm_get_xxx() helpers where appropriate

[Boris Brezillon]

Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
Doing that will ease adaptation of the PWM framework to support atomic
update.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

--->8---
virtual patch

@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity((p), e);
|
-(p)->polarity
+pwm_get_polarity((p))
|
-(p)->period = e;
+pwm_set_period((p), e);
|
-(p)->period
+pwm_get_period((p))
|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle((p), e);
|
-(p)->duty_cycle
+pwm_get_duty_cycle((p))
)
--->8---
---
 drivers/input/misc/max77693-haptic.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/max77693-haptic.c 
b/drivers/input/misc/max77693-haptic.c
index 6d96bff..a038fb3 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -70,10 +70,11 @@ struct max77693_haptic {
 
 static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
 {
-   int delta = (haptic->pwm_dev->period + haptic->pwm_duty) / 2;
+   int delta = (pwm_get_period((haptic->pwm_dev)) + haptic->pwm_duty) / 2;
int error;
 
-   error = pwm_config(haptic->pwm_dev, delta, haptic->pwm_dev->period);
+   error = pwm_config(haptic->pwm_dev, delta,
+  pwm_get_period((haptic->pwm_dev)));
if (error) {
dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
return error;
@@ -245,7 +246,7 @@ static int max77693_haptic_play_effect(struct input_dev 
*dev, void *data,
 * The formula to convert magnitude to pwm_duty as follows:
 * - pwm_duty = (magnitude * pwm_period) / MAX_MAGNITUDE(0x)
 */
-   period_mag_multi = (u64)haptic->pwm_dev->period * haptic->magnitude;
+   period_mag_multi = (u64)pwm_get_period((haptic->pwm_dev)) * 
haptic->magnitude;
haptic->pwm_duty = (unsigned int)(period_mag_multi >>
MAX_MAGNITUDE_SHIFT);
 
-- 
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 v4 09/24] regulator: pwm: use pwm_get/set_default_xxx() helpers where appropriate

[Boris Brezillon]

pwm_set/get_default_xxx() helpers have been introduced to differentiate
the default PWM states (those retrieved through DT, PWM lookup table or
statically assigned by the driver) and the current ones.
Make use of those helpers where appropriate.

Signed-off-by: Boris Brezillon 
Tested-by: Heiko Stuebner 
---
 drivers/regulator/pwm-regulator.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/regulator/pwm-regulator.c 
b/drivers/regulator/pwm-regulator.c
index 3aca067b..9ffdbd6 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -56,7 +56,7 @@ static int pwm_regulator_set_voltage_sel(struct regulator_dev 
*rdev,
int dutycycle;
int ret;
 
-   pwm_reg_period = pwm_get_period(drvdata->pwm);
+   pwm_reg_period = pwm_get_default_period(drvdata->pwm);
 
dutycycle = (pwm_reg_period *
drvdata->duty_cycle_table[selector].dutycycle) / 100;
@@ -131,7 +131,7 @@ static int pwm_regulator_set_voltage(struct regulator_dev 
*rdev,
 {
struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
unsigned int ramp_delay = rdev->constraints->ramp_delay;
-   unsigned int period = pwm_get_period(drvdata->pwm);
+   unsigned int period = pwm_get_default_period(drvdata->pwm);
int duty_cycle;
int ret;
 
-- 
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 v4 02/24] pwm: use pwm_get_xxx() helpers where appropriate

[Boris Brezillon]

Use pwm_get_xxx() helpers instead of directly accessing the pwm->xxx field.
Doing that will ease adaptation of the PWM framework to support atomic
update.

Signed-off-by: Boris Brezillon 
---
Patch generated with the following coccinelle script:

--->8---
virtual patch

@@
struct pwm_device *p;
expression e;
@@
(
-(p)->polarity = e;
+pwm_set_polarity((p), e);
|
-(p)->polarity
+pwm_get_polarity((p))
|
-(p)->period = e;
+pwm_set_period((p), e);
|
-(p)->period
+pwm_get_period((p))
|
-(p)->duty_cycle = e;
+pwm_set_duty_cycle((p), e);
|
-(p)->duty_cycle
+pwm_get_duty_cycle((p))
)
--->8---
---
 drivers/pwm/pwm-crc.c | 2 +-
 drivers/pwm/pwm-lpc18xx-sct.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/pwm/pwm-crc.c b/drivers/pwm/pwm-crc.c
index 7101c70..2f88543 100644
--- a/drivers/pwm/pwm-crc.c
+++ b/drivers/pwm/pwm-crc.c
@@ -75,7 +75,7 @@ static int crc_pwm_config(struct pwm_chip *c, struct 
pwm_device *pwm,
return -EINVAL;
}
 
-   if (pwm->period != period_ns) {
+   if (pwm_get_period((pwm)) != period_ns) {
int clk_div;
 
/* changing the clk divisor, need to disable fisrt */
diff --git a/drivers/pwm/pwm-lpc18xx-sct.c b/drivers/pwm/pwm-lpc18xx-sct.c
index 9163085..091fa13 100644
--- a/drivers/pwm/pwm-lpc18xx-sct.c
+++ b/drivers/pwm/pwm-lpc18xx-sct.c
@@ -249,7 +249,7 @@ static int lpc18xx_pwm_enable(struct pwm_chip *chip, struct 
pwm_device *pwm)
   LPC18XX_PWM_EVSTATEMSK(lpc18xx_data->duty_event),
   LPC18XX_PWM_EVSTATEMSK_ALL);
 
-   if (pwm->polarity == PWM_POLARITY_NORMAL) {
+   if (pwm_get_polarity((pwm)) == PWM_POLARITY_NORMAL) {
set_event = lpc18xx_pwm->period_event;
clear_event = lpc18xx_data->duty_event;
res_action = LPC18XX_PWM_RES_SET;
-- 
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 v4 16/24] pwm: move the enabled/disabled info to pwm_state struct

[Boris Brezillon]

Prepare the transition to PWM atomic update by moving the enabled/disabled
state into the pwm_state struct. This way we can easily update the whole
PWM state by copying the new state in the ->state field.

Signed-off-by: Boris Brezillon 
Tested-by: Heiko Stuebner 
---
 drivers/pwm/core.c  | 17 +
 include/linux/pwm.h |  7 ---
 2 files changed, 17 insertions(+), 7 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index f1c6769..6bbda6c 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -508,10 +508,10 @@ int pwm_enable(struct pwm_device *pwm)
 
mutex_lock(>lock);
 
-   if (!test_and_set_bit(PWMF_ENABLED, >flags)) {
+   if (!pwm_is_enabled(pwm)) {
err = pwm->chip->ops->enable(pwm->chip, pwm);
-   if (err)
-   clear_bit(PWMF_ENABLED, >flags);
+   if (!err)
+   pwm->state.enabled = true;
}
 
mutex_unlock(>lock);
@@ -526,8 +526,17 @@ EXPORT_SYMBOL_GPL(pwm_enable);
  */
 void pwm_disable(struct pwm_device *pwm)
 {
-   if (pwm && test_and_clear_bit(PWMF_ENABLED, >flags))
+   if (!pwm)
+   return;
+
+   mutex_lock(>lock);
+
+   if (pwm_is_enabled(pwm)) {
pwm->chip->ops->disable(pwm->chip, pwm);
+   pwm->state.enabled = false;
+   }
+
+   mutex_unlock(>lock);
 }
 EXPORT_SYMBOL_GPL(pwm_disable);
 
diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index af42299..398c58c 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -76,8 +76,7 @@ enum pwm_polarity {
 
 enum {
PWMF_REQUESTED = 1 << 0,
-   PWMF_ENABLED = 1 << 1,
-   PWMF_EXPORTED = 1 << 2,
+   PWMF_EXPORTED = 1 << 1,
 };
 
 /*
@@ -85,11 +84,13 @@ enum {
  * @period: PWM period (in nanoseconds)
  * @duty_cycle: PWM duty cycle (in nanoseconds)
  * @polarity: PWM polarity
+ * @enabled: PWM enabled status
  */
 struct pwm_state {
unsigned int period;
unsigned int duty_cycle;
enum pwm_polarity polarity;
+   bool enabled;
 };
 
 /**
@@ -117,7 +118,7 @@ struct pwm_device {
 
 static inline bool pwm_is_enabled(const struct pwm_device *pwm)
 {
-   return test_bit(PWMF_ENABLED, >flags);
+   return pwm->state.enabled;
 }
 
 static inline void pwm_set_period(struct pwm_device *pwm, unsigned int period)
-- 
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 v4 18/24] pwm: declare a default PWM state

[Boris Brezillon]

Prepare the addition of the PWM initial state retrieval by adding a default
state where all the parameters retrieved from DT, platform data or
statically forced by the hardware will be stored.
Once done we will be able to store the initial state in the ->state field
without risking to loose the default parameters.

Update the pwm_set/get_default_xxx helpers accordingly.

Signed-off-by: Boris Brezillon 
Tested-by: Heiko Stuebner 
---
 include/linux/pwm.h | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/include/linux/pwm.h b/include/linux/pwm.h
index 398c58c..292e7da 100644
--- a/include/linux/pwm.h
+++ b/include/linux/pwm.h
@@ -103,6 +103,7 @@ struct pwm_state {
  * @chip_data: chip-private data associated with the PWM device
  * @lock: used to serialize accesses to the PWM device where necessary
  * @state: curent PWM channel state
+ * @default_state: default PWM channel state
  */
 struct pwm_device {
const char *label;
@@ -114,6 +115,7 @@ struct pwm_device {
struct mutex lock;
 
struct pwm_state state;
+   struct pwm_state default_state;
 };
 
 static inline bool pwm_is_enabled(const struct pwm_device *pwm)
@@ -130,7 +132,8 @@ static inline void pwm_set_period(struct pwm_device *pwm, 
unsigned int period)
 static inline void pwm_set_default_period(struct pwm_device *pwm,
  unsigned int period)
 {
-   pwm_set_period(pwm, period);
+   if (pwm)
+   pwm->default_state.period = period;
 }
 
 static inline unsigned int pwm_get_period(const struct pwm_device *pwm)
@@ -140,7 +143,7 @@ static inline unsigned int pwm_get_period(const struct 
pwm_device *pwm)
 
 static inline unsigned int pwm_get_default_period(const struct pwm_device *pwm)
 {
-   return pwm_get_period(pwm);
+   return pwm ? pwm->default_state.period : 0;
 }
 
 static inline void pwm_set_duty_cycle(struct pwm_device *pwm, unsigned int 
duty)
@@ -162,7 +165,8 @@ int pwm_set_polarity(struct pwm_device *pwm, enum 
pwm_polarity polarity);
 static inline void pwm_set_default_polarity(struct pwm_device *pwm,
enum pwm_polarity polarity)
 {
-   pwm_set_polarity(pwm, polarity);
+   if (pwm)
+   pwm->default_state.polarity = polarity;
 }
 
 static inline enum pwm_polarity pwm_get_polarity(const struct pwm_device *pwm)
-- 
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 v4 17/24] backlight: pwm_bl: remove useless call to pwm_set_period

[Boris Brezillon]

The PWM period will be set when calling pwm_config. Remove this useless
call to pwm_set_period, which might mess up with the initial PWM state
once we have added proper support for PWM init state retrieval.

Signed-off-by: Boris Brezillon 
Acked-by: Lee Jones 
---
 drivers/video/backlight/pwm_bl.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index 54d5a03..5ff2976 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -292,12 +292,14 @@ static int pwm_backlight_probe(struct platform_device 
*pdev)
 * period, parsed from the DT, in the PWM device. For the non-DT case,
 * set the period from platform data if it has not already been set
 * via the PWM lookup table.
+* FIXME: This assignment should be dropped as soon as all the boards
+* have moved to the PWM lookup table approach. The same goes for the
+* pb->period field which should be replaced by
+* pwm_get_default_period() calls.
 */
pb->period = pwm_get_default_period(pb->pwm);
-   if (!pb->period && (data->pwm_period_ns > 0)) {
+   if (!pb->period && (data->pwm_period_ns > 0))
pb->period = data->pwm_period_ns;
-   pwm_set_period(pb->pwm, data->pwm_period_ns);
-   }
 
pb->lth_brightness = data->lth_brightness * (pb->period / pb->scale);
 
-- 
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 v4 12/24] misc: max77693: use pwm_get/set_default_xxx() helpers where appropriate

[Boris Brezillon]

pwm_set/get_default_xxx() helpers have been introduced to differentiate
the default PWM states (those retrieved through DT, PWM lookup table or
statically assigned by the driver) and the current ones.
Make use of those helpers where appropriate.

Signed-off-by: Boris Brezillon 
---
 drivers/input/misc/max77693-haptic.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/input/misc/max77693-haptic.c 
b/drivers/input/misc/max77693-haptic.c
index a038fb3..89f5055 100644
--- a/drivers/input/misc/max77693-haptic.c
+++ b/drivers/input/misc/max77693-haptic.c
@@ -70,11 +70,12 @@ struct max77693_haptic {
 
 static int max77693_haptic_set_duty_cycle(struct max77693_haptic *haptic)
 {
-   int delta = (pwm_get_period((haptic->pwm_dev)) + haptic->pwm_duty) / 2;
+   int delta = (pwm_get_default_period((haptic->pwm_dev)) +
+haptic->pwm_duty) / 2;
int error;
 
error = pwm_config(haptic->pwm_dev, delta,
-  pwm_get_period((haptic->pwm_dev)));
+  pwm_get_default_period((haptic->pwm_dev)));
if (error) {
dev_err(haptic->dev, "failed to configure pwm: %d\n", error);
return error;
@@ -246,7 +247,8 @@ static int max77693_haptic_play_effect(struct input_dev 
*dev, void *data,
 * The formula to convert magnitude to pwm_duty as follows:
 * - pwm_duty = (magnitude * pwm_period) / MAX_MAGNITUDE(0x)
 */
-   period_mag_multi = (u64)pwm_get_period((haptic->pwm_dev)) * 
haptic->magnitude;
+   period_mag_multi = (u64)pwm_get_default_period((haptic->pwm_dev)) *
+  haptic->magnitude;
haptic->pwm_duty = (unsigned int)(period_mag_multi >>
MAX_MAGNITUDE_SHIFT);
 
-- 
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 v4 08/24] leds: pwm: use pwm_get/set_default_xxx() helpers where appropriate

[Boris Brezillon]

pwm_set/get_default_xxx() helpers have been introduced to differentiate
the default PWM states (those retrieved through DT, PWM lookup table or
statically assigned by the driver) and the current ones.
Make use of those helpers where appropriate.

Signed-off-by: Boris Brezillon 
Acked-by: Jacek Anaszewski 
---
 drivers/leds/leds-pwm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/leds/leds-pwm.c b/drivers/leds/leds-pwm.c
index 1d07e3e..2c564d1 100644
--- a/drivers/leds/leds-pwm.c
+++ b/drivers/leds/leds-pwm.c
@@ -125,7 +125,7 @@ static int led_pwm_add(struct device *dev, struct 
led_pwm_priv *priv,
if (led_data->can_sleep)
INIT_WORK(_data->work, led_pwm_work);
 
-   led_data->period = pwm_get_period(led_data->pwm);
+   led_data->period = pwm_get_default_period(led_data->pwm);
if (!led_data->period && (led->pwm_period_ns > 0))
led_data->period = led->pwm_period_ns;
 
-- 
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 v4 13/24] hwmon: pwm-fan: use pwm_get/set_default_xxx() helpers where appropriate

[Boris Brezillon]

pwm_set/get_default_xxx() helpers have been introduced to differentiate
the default PWM states (those retrieved through DT, PWM lookup table or
statically assigned by the driver) and the current ones.
Make use of those helpers where appropriate.

Signed-off-by: Boris Brezillon 
---
 drivers/hwmon/pwm-fan.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/hwmon/pwm-fan.c b/drivers/hwmon/pwm-fan.c
index 105b964..989d7b4 100644
--- a/drivers/hwmon/pwm-fan.c
+++ b/drivers/hwmon/pwm-fan.c
@@ -47,8 +47,9 @@ static int  __set_pwm(struct pwm_fan_ctx *ctx, unsigned long 
pwm)
if (ctx->pwm_value == pwm)
goto exit_set_pwm_err;
 
-   duty = DIV_ROUND_UP(pwm * (pwm_get_period((ctx->pwm)) - 1), MAX_PWM);
-   ret = pwm_config(ctx->pwm, duty, pwm_get_period((ctx->pwm)));
+   duty = DIV_ROUND_UP(pwm * (pwm_get_default_period((ctx->pwm)) - 1),
+   MAX_PWM);
+   ret = pwm_config(ctx->pwm, duty, pwm_get_default_period((ctx->pwm)));
if (ret)
goto exit_set_pwm_err;
 
@@ -234,10 +235,11 @@ static int pwm_fan_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, ctx);
 
/* Set duty cycle to maximum allowed */
-   duty_cycle = pwm_get_period((ctx->pwm)) - 1;
+   duty_cycle = pwm_get_default_period((ctx->pwm)) - 1;
ctx->pwm_value = MAX_PWM;
 
-   ret = pwm_config(ctx->pwm, duty_cycle, pwm_get_period((ctx->pwm)));
+   ret = pwm_config(ctx->pwm, duty_cycle,
+pwm_get_default_period((ctx->pwm)));
if (ret) {
dev_err(>dev, "Failed to configure PWM\n");
return ret;
@@ -309,9 +311,10 @@ static int pwm_fan_resume(struct device *dev)
if (ctx->pwm_value == 0)
return 0;
 
-   duty = DIV_ROUND_UP(ctx->pwm_value * (pwm_get_period((ctx->pwm)) - 1),
+   duty = DIV_ROUND_UP(ctx->pwm_value *
+   (pwm_get_default_period((ctx->pwm)) - 1),
MAX_PWM);
-   ret = pwm_config(ctx->pwm, duty, pwm_get_period((ctx->pwm)));
+   ret = pwm_config(ctx->pwm, duty, pwm_get_default_period((ctx->pwm)));
if (ret)
return ret;
return pwm_enable(ctx->pwm);
-- 
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 v4 10/24] backlight: pwm: use pwm_get/set_default_xxx() helpers where appropriate

[Boris Brezillon]

pwm_set/get_default_xxx() helpers have been introduced to differentiate
the default PWM states (those retrieved through DT, PWM lookup table or
statically assigned by the driver) and the current ones.
Make use of those helpers where appropriate.

Signed-off-by: Boris Brezillon 
Acked-by: Lee Jones 
---
 drivers/video/backlight/lm3630a_bl.c | 4 ++--
 drivers/video/backlight/pwm_bl.c | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/video/backlight/lm3630a_bl.c 
b/drivers/video/backlight/lm3630a_bl.c
index 35fe482..449ebc3 100644
--- a/drivers/video/backlight/lm3630a_bl.c
+++ b/drivers/video/backlight/lm3630a_bl.c
@@ -162,7 +162,7 @@ static int lm3630a_intr_config(struct lm3630a_chip *pchip)
 
 static void lm3630a_pwm_ctrl(struct lm3630a_chip *pchip, int br, int br_max)
 {
-   unsigned int period = pwm_get_period(pchip->pwmd);
+   unsigned int period = pwm_get_default_period(pchip->pwmd);
unsigned int duty = br * period / br_max;
 
pwm_config(pchip->pwmd, duty, period);
@@ -425,7 +425,7 @@ static int lm3630a_probe(struct i2c_client *client,
return PTR_ERR(pchip->pwmd);
}
}
-   pchip->pwmd->period = pdata->pwm_period;
+   pwm_set_default_period(pchip->pwmd, pdata->pwm_period);
 
/* interrupt enable  : irq 0 is not allowed */
pchip->irq = client->irq;
diff --git a/drivers/video/backlight/pwm_bl.c b/drivers/video/backlight/pwm_bl.c
index ae3c6b6..54d5a03 100644
--- a/drivers/video/backlight/pwm_bl.c
+++ b/drivers/video/backlight/pwm_bl.c
@@ -293,7 +293,7 @@ static int pwm_backlight_probe(struct platform_device *pdev)
 * set the period from platform data if it has not already been set
 * via the PWM lookup table.
 */
-   pb->period = pwm_get_period(pb->pwm);
+   pb->period = pwm_get_default_period(pb->pwm);
if (!pb->period && (data->pwm_period_ns > 0)) {
pb->period = data->pwm_period_ns;
pwm_set_period(pb->pwm, data->pwm_period_ns);
-- 
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 v4 07/24] pwm: use pwm_get/set_default_xxx() helpers where appropriate

[Boris Brezillon]

pwm_set/get_default_xxx() helpers have been introduced to differentiate
the default PWM states (those retrieved through DT, PWM lookup table or
statically assigned by the driver) and the current PWM ones.
Make use of those helpers where appropriate.

Signed-off-by: Boris Brezillon 
Tested-by: Heiko Stuebner 
Reviewed-by: Alexandre Belloni 
Acked-by: Robert Jarzmik 
---
 drivers/pwm/core.c  | 14 +++---
 drivers/pwm/pwm-pxa.c   |  2 +-
 drivers/pwm/pwm-sun4i.c |  3 ++-
 3 files changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index d24ca5f..59073a1 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -146,12 +146,12 @@ of_pwm_xlate_with_flags(struct pwm_chip *pc, const struct 
of_phandle_args *args)
if (IS_ERR(pwm))
return pwm;
 
-   pwm_set_period(pwm, args->args[1]);
+   pwm_set_default_period(pwm, args->args[1]);
 
if (args->args[2] & PWM_POLARITY_INVERTED)
-   pwm_set_polarity(pwm, PWM_POLARITY_INVERSED);
+   pwm_set_default_polarity(pwm, PWM_POLARITY_INVERSED);
else
-   pwm_set_polarity(pwm, PWM_POLARITY_NORMAL);
+   pwm_set_default_polarity(pwm, PWM_POLARITY_NORMAL);
 
return pwm;
 }
@@ -172,7 +172,7 @@ of_pwm_simple_xlate(struct pwm_chip *pc, const struct 
of_phandle_args *args)
if (IS_ERR(pwm))
return pwm;
 
-   pwm_set_period(pwm, args->args[1]);
+   pwm_set_default_period(pwm, args->args[1]);
 
return pwm;
 }
@@ -268,7 +268,7 @@ int pwmchip_add_with_polarity(struct pwm_chip *chip,
pwm->chip = chip;
pwm->pwm = chip->base + i;
pwm->hwpwm = i;
-   pwm->polarity = polarity;
+   pwm_set_default_polarity(pwm, polarity);
mutex_init(>lock);
 
radix_tree_insert(_tree, pwm->pwm, pwm);
@@ -751,8 +751,8 @@ struct pwm_device *pwm_get(struct device *dev, const char 
*con_id)
if (IS_ERR(pwm))
goto out;
 
-   pwm_set_period(pwm, chosen->period);
-   pwm_set_polarity(pwm, chosen->polarity);
+   pwm_set_default_period(pwm, chosen->period);
+   pwm_set_default_polarity(pwm, chosen->polarity);
 
 out:
mutex_unlock(_lookup_lock);
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index cb2f702..65b80aa 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -160,7 +160,7 @@ pxa_pwm_of_xlate(struct pwm_chip *pc, const struct 
of_phandle_args *args)
if (IS_ERR(pwm))
return pwm;
 
-   pwm_set_period(pwm, args->args[0]);
+   pwm_set_default_period(pwm, args->args[0]);
 
return pwm;
 }
diff --git a/drivers/pwm/pwm-sun4i.c b/drivers/pwm/pwm-sun4i.c
index 67af9f6..f6a7451 100644
--- a/drivers/pwm/pwm-sun4i.c
+++ b/drivers/pwm/pwm-sun4i.c
@@ -354,7 +354,8 @@ static int sun4i_pwm_probe(struct platform_device *pdev)
val = sun4i_pwm_readl(pwm, PWM_CTRL_REG);
for (i = 0; i < pwm->chip.npwm; i++)
if (!(val & BIT_CH(PWM_ACT_STATE, i)))
-   pwm->chip.pwms[i].polarity = PWM_POLARITY_INVERSED;
+   pwm_set_default_polarity(>chip.pwms[i],
+PWM_POLARITY_INVERSED);
clk_disable_unprepare(pwm->clk);
 
return 0;
-- 
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 v4 21/24] pwm: add information about polarity, duty cycle and period to debugfs

[Boris Brezillon]

From: Heiko Stübner 

The pwm-states make it possible to also output the polarity, duty cycle
and period information in the debugfs pwm summary-outout.
This makes it easier to gather overview information about pwms without
needing to walk through the sysfs attributes of every pwm.

Signed-off-by: Heiko Stuebner 
Signed-off-by: Boris Brezillon 
---
 drivers/pwm/core.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index fbc71d3..1619101 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -1035,6 +1035,11 @@ static void pwm_dbg_show(struct pwm_chip *chip, struct 
seq_file *s)
if (pwm_is_enabled(pwm))
seq_puts(s, " enabled");
 
+   seq_printf(s, " period:%uns", pwm_get_period(pwm));
+   seq_printf(s, " duty:%uns", pwm_get_duty_cycle(pwm));
+   seq_printf(s, " polarity:%s", pwm_get_polarity(pwm) ? "inverse"
+   : "normal");
+
seq_puts(s, "\n");
}
 }
-- 
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 v4 24/24] regulator: pwm: properly initialize the ->state field

[Boris Brezillon]

The ->state field is currently initialized to 0, thus referencing the
voltage selector at index 0, which might not reflect the current voltage
value.
If possible, retrieve the current voltage selector from the PWM state, else
return -EINVAL.

Signed-off-by: Boris Brezillon 
Tested-by: Heiko Stuebner 
Acked-by: Mark Brown 
---
 drivers/regulator/pwm-regulator.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/regulator/pwm-regulator.c 
b/drivers/regulator/pwm-regulator.c
index 9ffdbd6..449e3b3 100644
--- a/drivers/regulator/pwm-regulator.c
+++ b/drivers/regulator/pwm-regulator.c
@@ -41,10 +41,35 @@ struct pwm_voltages {
 /**
  * Voltage table call-backs
  */
+static void pwm_regulator_init_state(struct regulator_dev *rdev)
+{
+   struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
+   struct pwm_state pwm_state;
+   unsigned int dutycycle;
+   int i;
+
+   pwm_get_state(drvdata->pwm, _state);
+
+   if (!pwm_state.period)
+   return;
+
+   dutycycle = (pwm_state.duty_cycle * 100) / pwm_state.period;
+
+   for (i = 0; i < rdev->desc->n_voltages; i++) {
+   if (dutycycle == drvdata->duty_cycle_table[i].dutycycle) {
+   drvdata->state = i;
+   return;
+   }
+   }
+}
+
 static int pwm_regulator_get_voltage_sel(struct regulator_dev *rdev)
 {
struct pwm_regulator_data *drvdata = rdev_get_drvdata(rdev);
 
+   if (drvdata->state < 0)
+   pwm_regulator_init_state(rdev);
+
return drvdata->state;
 }
 
@@ -211,6 +236,7 @@ static int pwm_regulator_init_table(struct platform_device 
*pdev,
return ret;
}
 
+   drvdata->state  = -EINVAL;
drvdata->duty_cycle_table   = duty_cycle_table;
pwm_regulator_desc.ops  = _regulator_voltage_table_ops;
pwm_regulator_desc.n_voltages   = length / sizeof(*duty_cycle_table);
-- 
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 v4 14/24] clk: pwm: use pwm_get/set_default_xxx() helpers where appropriate

[Boris Brezillon]

pwm_set/get_default_xxx() helpers have been introduced to differentiate
the default PWM states (those retrieved through DT, PWM lookup table or
statically assigned by the driver) and the current ones.
Make use of those helpers where appropriate.

Signed-off-by: Boris Brezillon 
---
 drivers/clk/clk-pwm.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
index b6306a2..642a49a 100644
--- a/drivers/clk/clk-pwm.c
+++ b/drivers/clk/clk-pwm.c
@@ -71,23 +71,23 @@ static int clk_pwm_probe(struct platform_device *pdev)
if (IS_ERR(pwm))
return PTR_ERR(pwm);
 
-   if (!pwm_get_period((pwm))) {
+   if (!pwm_get_default_period((pwm))) {
dev_err(>dev, "invalid PWM period\n");
return -EINVAL;
}
 
if (of_property_read_u32(node, "clock-frequency", _pwm->fixed_rate))
-   clk_pwm->fixed_rate = NSEC_PER_SEC / pwm_get_period((pwm));
+   clk_pwm->fixed_rate = NSEC_PER_SEC / 
pwm_get_default_period((pwm));
 
-   if (pwm_get_period((pwm)) != NSEC_PER_SEC / clk_pwm->fixed_rate &&
-   pwm_get_period((pwm)) != DIV_ROUND_UP(NSEC_PER_SEC, 
clk_pwm->fixed_rate)) {
+   if (pwm_get_default_period((pwm)) != NSEC_PER_SEC / clk_pwm->fixed_rate 
&&
+   pwm_get_default_period((pwm)) != DIV_ROUND_UP(NSEC_PER_SEC, 
clk_pwm->fixed_rate)) {
dev_err(>dev,
"clock-frequency does not match PWM period\n");
return -EINVAL;
}
 
-   ret = pwm_config(pwm, (pwm_get_period((pwm)) + 1) >> 1,
-pwm_get_period((pwm)));
+   ret = pwm_config(pwm, (pwm_get_default_period((pwm)) + 1) >> 1,
+pwm_get_default_period((pwm)));
if (ret < 0)
return ret;
 
-- 
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 v4 11/24] fbdev: use pwm_get/set_default_xxx() helpers where appropriate

[Boris Brezillon]

pwm_set/get_default_xxx() helpers have been introduced to differentiate
the default PWM states (those retrieved through DT, PWM lookup table or
statically assigned by the driver) and the current ones.
Make use of those helpers where appropriate.

Signed-off-by: Boris Brezillon 
---
 drivers/video/fbdev/ssd1307fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index fa34808..81f4885 100644
--- a/drivers/video/fbdev/ssd1307fb.c
+++ b/drivers/video/fbdev/ssd1307fb.c
@@ -294,7 +294,7 @@ static int ssd1307fb_init(struct ssd1307fb_par *par)
return PTR_ERR(par->pwm);
}
 
-   par->pwm_period = pwm_get_period(par->pwm);
+   par->pwm_period = pwm_get_default_period(par->pwm);
/* Enable the PWM */
pwm_config(par->pwm, par->pwm_period / 2, par->pwm_period);
pwm_enable(par->pwm);
-- 
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.