[PATCH 4/4] dt-binding: remoteproc: Introduce Qualcomm WCNSS loader binding

[Bjorn Andersson]

The document defines the binding for a component that loads firmware for
and boots the Qualcomm WCNSS core.

Signed-off-by: Bjorn Andersson 
---
 .../bindings/remoteproc/qcom,wcnss-pil.txt | 107 +
 1 file changed, 107 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt

diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt 
b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
new file mode 100644
index ..9fbaf564662e
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
@@ -0,0 +1,107 @@
+Qualcomm WCNSS Peripheral Image Loader
+
+This document defines the binding for a component that loads and boots firmware
+on the Qualcomm WCNSS core.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,riva-pil",
+   "qcom,pronto-v1-pil",
+   "qcom,pronto-v2-pil"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: base address and size of riva/pronto PMU registers
+
+- interrupts-extended:
+   Usage: required
+   Value type: 
+   Definition: should specify the watchdog, fatal, ready, handover and
+   stop-ack IRQs, in order.
+
+- interrupt-names:
+   Usage: required
+   Value type: 
+   Definition: should be "wdog", "fatal", "ready", "handover", "stop-ack"
+
+- clocks:
+   Usage: required
+   Value type: 
+   Definition: should specify the xo clock and optionally the rf_clk
+
+- clock-names:
+   Usage: requireduired
+   Value type: 
+   Definition: should be "xo", optionally followed by "rf"
+
+- qcom,firmware-name:
+   Usage: required
+   Value type: 
+   Definition: name of the firmware to be loaded
+
+- qcom,crash-reason:
+   Usage: required
+   Value type: 
+   Definition: SMEM item used by WCNSS for storing the error messages upon
+   a fatal exception
+
+- qcom,iris-vddxo-supply:
+- qcom,iris-vddrfa-supply:
+- qcom,iris-vddpa-supply:
+- qcom,iris-vdddig-supply:
+- qcom,pronto-vddmx-supply:
+- qcom,pronto-vddcx-supply:
+- qcom,pronto-vddpx-supply:
+   Usage: required
+   Value type: 
+   Definition: reference to the regulators to be held on behalf of the
+   booting of the WCNSS core
+
+- qcom,state:
+   Usage: required
+   Value type: 
+   Definition: reference to the SMEM state used to indicate to WCNSS that
+   it should shut down
+
+- qcom,state-names:
+   Usage: required
+   Value type: 
+   Definition: should be "stop"
+
+= EXAMPLE
+
+pronto_rproc@fb21b000 {
+   compatible = "qcom,pronto-v2-pil";
+   reg = <0xfb21b000 0x3000>;
+
+   interrupts-extended = <&intc 0 149 1>,
+ <&wcnss_smp2p_slave 0 0>,
+ <&wcnss_smp2p_slave 1 0>,
+ <&wcnss_smp2p_slave 2 0>,
+ <&wcnss_smp2p_slave 3 0>;
+   interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
+
+   clocks = <&rpmcc RPM_CXO_CLK_SRC>, <&rpmcc RPM_CXO_A2>;
+   clock-names = "xo", "rf";
+
+   qcom,firmware-name = "wcnss";
+
+   qcom,crash-reason = <422>;
+
+   qcom,iris-vddxo-supply = <&pm8941_l6>;
+   qcom,iris-vddrfa-supply = <&pm8941_l11>;
+   qcom,iris-vddpa-supply = <&pm8941_l19>;
+   qcom,iris-vdddig-supply = <&pm8941_s3>;
+   qcom,pronto-vddmx-supply = <&pm8841_s1>;
+   qcom,pronto-vddcx-supply = <&pm8841_s2>;
+   qcom,pronto-vddpx-supply = <&pm8941_s3>;
+
+   qcom,state = <&wcnss_smp2p_out 0>;
+   qcom,state-names = "stop";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <&wcnss_pin_a>;
+};
-- 
1.8.2.2

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

[PATCH 0/4] WCNSS Peripheral Image Loader

[Bjorn Andersson]

This series provides the minimum changes needed to use remotproc on the
Qualcomm platform, it then introduces the Peripheral Image Loader for
the WCNSS core.


The implementation depends on https://lkml.org/lkml/2015/9/24/723

Bjorn Andersson (4):
  remoteproc: core: Make the loaded resource table optional
  remoteproc: Add additional crash reasons
  remoteproc: qcom: Introduce WCNSS peripheral image loader
  dt-binding: remoteproc: Introduce Qualcomm WCNSS loader binding

 .../bindings/remoteproc/qcom,wcnss-pil.txt | 107 
 drivers/remoteproc/Kconfig |  11 +
 drivers/remoteproc/Makefile|   2 +
 drivers/remoteproc/qcom_mdt_loader.c   | 213 +++
 drivers/remoteproc/qcom_mdt_loader.h   |   8 +
 drivers/remoteproc/qcom_wcnss.c| 615 +
 drivers/remoteproc/remoteproc_core.c   |  10 +-
 include/linux/remoteproc.h |   4 +
 8 files changed, 964 insertions(+), 6 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
 create mode 100644 drivers/remoteproc/qcom_mdt_loader.c
 create mode 100644 drivers/remoteproc/qcom_mdt_loader.h
 create mode 100644 drivers/remoteproc/qcom_wcnss.c

-- 
1.8.2.2

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

Re: [PATCH 0/5] ARM: dts: fix cpu compatible values

[Shawn Guo]

On Fri, Sep 25, 2015 at 08:35:06PM +0300, Vladimir Zapolskiy wrote:
> The changeset corrects severeal cpu compatible properties
> to defined ones in Documentation/devicetree/bindings/arm/cpus.txt
> 
> Vladimir Zapolskiy (5):
>   ARM: dts: i.MX31: fix cpu compatible value
>   ARM: dts: i.MX35: fix cpu compatible value

Applied these two, thanks.

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

Re: [PATCH v2 1/2] mmc: sdhci-of-arasan: add phy support for sdhci-of-arasan

[Sören Brinkmann]

On Tue, 2015-09-15 at 09:07AM +0800, Shawn Lin wrote:
> On 2015/9/14 23:07, Sören Brinkmann wrote:
> >Hi Shawn,
> >
> >overall, it looks good to me. I have some questions though.
> >
> >On Mon, 2015-09-14 at 02:29PM +0800, Shawn Lin wrote:
> 
> [...]
> 
> >>+err_phy_exit:
> >>+   phy_init(phy);
> >
> >Just to confirm, are these actions in the error path correct? E.g.
> >if the power_off() call fails, is it safe to call power_on()? Isn't
> >the phy still powered on? (this would apply to other error paths too)
> >
> 
> Cool question!
> 
> While writing this, I had read generic phy stuffs deliberately to find a
> solution for a case: how to deal with ping-pong fails? In another word, if
> power_off call fails, then we should call power_on, but unfortunately it
> fails again then we call power_off... so endless nested err handling... No
> answer yet.
> 
> So, I assumed two cases happened when power_off call fails:
> (1) *real power_off* is done, but some other stuffs in the calling path
> fail, so phy is really power_off in theory. We need to power_on it again,
> but if it fail, we don't know PHY is on or off since we don't know power_on
> fails for what? *real power on* ? some other stuffs?
> 
> (2) *real power_off* isn't completed, so indeed it's *still* in power_on
> state. The reason we never need to check the return value of power_on cross
> the err handling is that whether power_on call successfully or not, it's
> always make phy in power_on state.
> 
> Now, let's think about case(1).
> After reading dozens of sample codes(such as USB, UFS, MBUS) that adopt
> generic phy framework for PHY management, real thing should be like that:
> they NEVER deal with case(1).
> 
> It's a trick of sub-phy drivers themself. power_on/off calling path return
> err for two case:
> <1>  phy_runtime callback fails. It's after *real power on/off*, so
> definitely *real power on/off* is conpleted. That is the case(2) I mentioned
> above.
> <2>  sub-phy drivers return err for  phy->ops->power_off(phy); Look
> into all the sub-phy drivers twice, we find that they always return success
> for phy->ops->power_off hook. Why? Because all of them
> write registers to enable/disable something, always consider things going
> well. Actually if we write value into a register, we have to think that it's
> functional.
> 
> Anyway, back to this patch.
> Indeed we also write value into arasan phy's register to do
> phy_power_on/off/init/exit to make things work. Right, we return success
> state for all of these them just as all the other sub-phy drivers do.
> 
> Feel free to let me know if I make mistakes or misunderstanding above.
> 
> >>+   return ret;
> >>+}
> 
> [...]
> 
> >>+   }
> >>+   }
> >
> >I assume you looked at options for having the error paths in a
> >consolidated location? I guess this may be the nicest solution since all
> >of this is in this conditional block?
> >
> 
> yep, otherwise we should add some *if* statements to check sdhci_arasan->phy
> cross the err handles. And I intent to strictly limit
> the phy stuffs under the scope of arasan,sdhci-5.1 currently.
> 
> >Feel free to add my
> >Acked-by: Sören Brinkmann 
> >
> 
> Thanks, Sören. :)

Makes all sense to me. Thanks for all the details.

Sören
--
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

Re: [PATCH net-next v3] net: Fix Hisilicon Network Subsystem Support Compilation

[David Miller]

From: huangdaode 
Date: Fri, 25 Sep 2015 16:29:50 +0800

> @@ -191,9 +191,12 @@ static void hns_rcb_ring_init(struct ring_pair_cb 
> *ring_pair, int ring_type)
>   if (ring_type == RX_RING) {
>   dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_L_REG,
>  (u32)dma);
> +#ifdef CONFIG_64BIT
>   dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_H_REG,
>  (u32)(dma >> 32));
> -
> +#else
> + dsaf_write_dev(q, RCB_RING_RX_RING_BASEADDR_H_REG, 0);
> +#endif
>   dsaf_write_dev(q, RCB_RING_RX_RING_BD_LEN_REG,
>  bd_size_type);
>   dsaf_write_dev(q, RCB_RING_RX_RING_BD_NUM_REG,

CONFIG_64BIT doesn't tell you if _DMA_ addresses are 64-bit or not.

Furthermore there is a portable way to shift a 32-bit value down
32-bits whilst avoiding warnings.

(x >> 31) >> 1

So you should definitely use that instead of the CONFIG_64BIT test.
--
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

drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:610:33: sparse: symbol 'pxtal_data' was not declared. Should it be static?

[kbuild test robot]

Hi Enric,

FYI, build test results on v4.3-rc2 (pls ignore if it's inappropriate base for 
your patch).

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


sparse warnings: (new ones prefixed by >>)

>> drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:610:33: sparse: symbol 
>> 'pxtal_data' was not declared. Should it be static?
>> drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:643:6: sparse: symbol 
>> 'sp_tx_initialization' was not declared. Should it be static?
>> drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:2188:6: sparse: symbol 
>> 'sp_initialization' was not declared. Should it be static?
>> drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:649:30: sparse: cast 
>> truncates bits from constant value (ff7f becomes 7f)
   drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:2129:30: sparse: cast 
truncates bits from constant value (ff7f becomes 7f)
>> drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c:2140:38: sparse: cast 
>> truncates bits from constant value (ff1f becomes 1f)

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
--
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

[PATCH linux-review] drm: bridge: anx78xx: pxtal_data[] can be static

[kbuild test robot]

Signed-off-by: Fengguang Wu 
---
 slimport_tx_drv.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c 
b/drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
index 7721326..9afebab 100644
--- a/drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
+++ b/drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
@@ -607,7 +607,7 @@ static void hdmi_rx_initialization(struct anx78xx *anx78xx)
hdmi_rx_set_termination(anx78xx, 0);
 }
 
-struct anx78xx_clock_data const pxtal_data[XTAL_CLK_NUM] = {
+static struct anx78xx_clock_data const pxtal_data[XTAL_CLK_NUM] = {
{19, 192},
{24, 240},
{25, 250},
@@ -640,7 +640,7 @@ static void xtal_clk_sel(struct anx78xx *anx78xx)
((pxtal_data[XTAL_27M].xtal_clk >> 1) - 2) << 3);
 }
 
-void sp_tx_initialization(struct anx78xx *anx78xx)
+static void sp_tx_initialization(struct anx78xx *anx78xx)
 {
sp_write_reg(anx78xx, TX_P0, AUX_CTRL2, 0x30);
sp_write_reg_or(anx78xx, TX_P0, AUX_CTRL2, 0x08);
@@ -2185,7 +2185,7 @@ static void sp_config_audio_output(struct anx78xx 
*anx78xx)
 
 /**End Audio process/
 
-void sp_initialization(struct anx78xx *anx78xx)
+static void sp_initialization(struct anx78xx *anx78xx)
 {
/* Waitting Hot plug event! */
if (!(sp.common_int_status.common_int[3] & PLUG))
--
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

Re: [PATCH v6 6/6] pinctrl: freescale: imx: imx7d iomuxc-lpsr devicetree bindings

[Shawn Guo]

On Fri, Sep 25, 2015 at 04:06:02PM -0500, Adrian Alonso wrote:
> +Examples:
> +While iomuxc-lpsr is intended to be used by dedicated peripherals to take
> +advantages of LPSR power mode, is also possible that an IP to use pads from
> +any of the iomux controllers. For example the I2C1 IP can use SCL pad from
> +iomuxc-lpsr controller and SDA pad from iomuxc controller as:
> +
> +i2c1: i2c@30a2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_i2c1_1 &pinctrl_i2c1_2>;
> + status = "okay";
> +};
> +
> +iomuxc-lpsr@302c {
> + compatible = "fsl,imx7d-iomuxc-lpsr";
> + reg = <0x302c 0x1>;
> + fsl,input-sel = <&iomuxc>;
> +
> + pinctrl_i2c1_1: i2c1grp-1 {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x407f
> + >;
> + };
> +};
> +
> +iomuxc@3033 {
> + compatible = "fsl,imx7d-iomuxc";
> + reg = <0x3033 0x1>;
> +
> + pinctrl_i2c1_2: i2c1grp-2 {
> + fsl,pins = <
> + MX7D_PAD_I2C1_SCL__I2C1_SCL 0x407f

I thought you have fixed this, as I have pointed it out during the last
review.  The example doesn't make sense.  There is no reason you need to
have two pads on the same function I2C1_SCL.  One of them should be
I2C1_SDA.

Shawn

> + >;
> + };
> +};
> -- 
> 2.1.4
> 
--
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

Re: [PATCH v6 3/6] pinctrl: freescale: imx: allow mux_reg offset zero

[Shawn Guo]

On Fri, Sep 25, 2015 at 04:05:59PM -0500, Adrian Alonso wrote:
> Allow mux_reg offset zero to be a valid pin_id, on imx7d
> mux_conf reg offset is zero for iomuxc-lspr controller
> 
> Signed-off-by: Adrian Alonso 

For #3 ~ #6,

Acked-by: Shawn Guo 
--
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

Re: [PATCH v6 2/6] ARM: dts: imx: imx7d-sbd add iomuxc-lpsr hoggrp-2 pads

[Shawn Guo]

On Fri, Sep 25, 2015 at 04:05:58PM -0500, Adrian Alonso wrote:
> Add imx7d-sdb iomuxc-lpsr hoggrp-2 default pads settings
> 
> Signed-off-by: Adrian Alonso 

Looked at this patch again, and please see comments below.

> ---
> Changes for V2: Resend
> Changes for V3: Resend
> Changes for V4: Resend
> Changes for V5: Resend
> Changes for V6:
> - Add wdog pinctrl group, add comments for hog2 group gpios
> 
>  arch/arm/boot/dts/imx7d-sdb.dts | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
> index 8059458..2da704a 100644
> --- a/arch/arm/boot/dts/imx7d-sdb.dts
> +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> @@ -419,3 +419,23 @@
>  
>   };
>  };
> +
> +&iomuxc_lpsr {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_hog_2>;
> +
> + imx7d-sdb {
> + pinctrl_hog_2: hoggrp-2 {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO05__GPIO1_IO50x14  /* 
> usb_otg1_pwr */

Shouldn't this be handled by a pinctrl of regulator@0 ...

> + MX7D_PAD_GPIO1_IO07__GPIO1_IO70x59  /* 
> sensor_int_b */

... and this by a pinctrl of regulator@2?

> + >;
> + };
> +
> + pinctrl_wdog: wdoggrp {
> + fsl,pins = <
> + MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
> + >;
> + };

Add this only when you have a user for it.

Shawn

> + };
> +};
> -- 
> 2.1.4
> 
--
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

Re: [PATCH v6 1/6] ARM: dts: imx: imx7d add iomuxc lpsr device node

[Shawn Guo]

On Fri, Sep 25, 2015 at 04:05:57PM -0500, Adrian Alonso wrote:
> Add device tree node to support iomuxc-lpsr controller, fsl,iput-sel

s/fsl,iput-sel/fsl,input-sel

> phandle allows to get input select register base address which is
> shared from main iomuxc controller.
> 
> Signed-off-by: Adrian Alonso 

I fixed above typo and applied the patch.

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

Re: [PATCH v6 1/6] ARM: dts: imx: imx7d add iomuxc lpsr device node

[Shawn Guo]

On Fri, Sep 25, 2015 at 04:05:57PM -0500, Adrian Alonso wrote:
> Add device tree node to support iomuxc-lpsr controller, fsl,iput-sel
> phandle allows to get input select register base address which is
> shared from main iomuxc controller.
> 
> Signed-off-by: Adrian Alonso 

For the series,

Acked-by: Shawn Guo 
--
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

Re: [PATCH v4 0/2] pwm: Broadcom BCM7038 PWM controller (v4)

[Florian Fainelli]

On 14/09/15 16:47, Florian Fainelli wrote:
> Hi,
> 
> This patch series add PWM support for the Broadcom BCM7xxx
> chips which feature one or more PWM controllers capable of
> output periods from 148ns to ~622ms using a combination of
> variable and fixed frequency settings.

Thierry, are you happy with this version of the patches? Thanks.

> 
> The controller does not support setting a polarity.
> 
> This is based on Thierry's pwm/next branch.
> 
> Florian Fainelli (2):
>   Documentation: dt: add Broadcom BCM7038 PWM controller binding
>   pwm: Add Broadcom BCM7038 PWM controller support
> 
>  .../devicetree/bindings/pwm/brcm,bcm7038-pwm.txt   |  20 ++
>  drivers/pwm/Kconfig|  10 +
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-brcmstb.c  | 345 
> +
>  4 files changed, 376 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.txt
>  create mode 100644 drivers/pwm/pwm-brcmstb.c
> 


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

Re: [PATCH] of: add vendor prefix for Socionext Inc.

[Rob Herring]

On Wed, Sep 9, 2015 at 3:04 AM, Lee Jones  wrote:
> On Wed, 09 Sep 2015, Masahiro Yamada wrote:
>> 2015-08-25 0:11 GMT+09:00 Rob Herring :
>> > On Mon, Aug 24, 2015 at 1:57 AM, Lee Jones  wrote:
>> >> On Wed, 29 Jul 2015, Masahiro Yamada wrote:
>> >>
>> >>> Signed-off-by: Masahiro Yamada 
>> >>> ---
>> >>>
>> >>>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>> >>>  1 file changed, 1 insertion(+)
>> >>
>> >> Patch has been around for nearly a month and is pretty trivial, so I'm
>> >> just going to go ahead an apply it.
>> >
>> > Okay. I just added it now going thru my backlog, but will drop it.
>> >
>> > Rob
>> >
>>
>> So, where has this patch gone?
>>
>> I've not seen it anywhere.
>
> That's a very good question.  I must have mis-applied it some how.
>
> Sorry for this.  I will try to get it into v4.3 by hook or by crook.

I've applied this and it is in Linus' tree now.

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

[PATCH 1/3] Docs: dt: fsl-mc: update binding to include msi-parent

[Stuart Yoder]

The Freescale Management Complex and all associated objects
use message interrupts, and thus an msi-parent is required.

Signed-off-by: Stuart Yoder 
---
 Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index c7a26ca..6aac955 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -30,11 +30,17 @@ Required properties:
 region may not be present in some scenarios, such
 as in the device tree presented to a virtual machine.
 
+- msi-parent
+Value type: 
+Definition: Must be present and point to the MSI controller node
+handling message interrupts for the MC.
+
 Example:
 
 fsl_mc: fsl-mc@80c00 {
 compatible = "fsl,qoriq-mc";
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
+msi-parent = <&its>;
 };
 
-- 
2.3.3

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

Re: [PATCH linux-next v10 2/3] mfd: devicetree: add bindings for Atmel Flexcom

[Lee Jones]

On Thu, 24 Sep 2015, Cyrille Pitchen wrote:

> This patch documents the DT bindings for the Atmel Flexcom which will be
> introduced by sama5d2x SoCs. These bindings will be used by the actual
> Flexcom driver to be sent in another patch.
> 
> Signed-off-by: Cyrille Pitchen 
> Acked-by: Boris Brezillon 
> Acked-by: Alexandre Belloni 
> Acked-by: Nicolas Ferre 
> ---
>  .../devicetree/bindings/mfd/atmel-flexcom.txt  | 67 
> ++
>  1 file changed, 67 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> 
> diff --git a/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt 
> b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> new file mode 100644
> index ..fc3511e41542
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/atmel-flexcom.txt
> @@ -0,0 +1,67 @@
> +* Device tree bindings for Atmel Flexcom (Flexible Serial Communication Unit)
> +
> +The Atmel Flexcom is just a wrapper which embeds a SPI controller, an I2C
> +controller and an USART. Only one function can be used at a time and is 
> chosen
> +at boot time according to the device tree.
> +
> +Required properties:
> +- compatible:Should be "atmel,sama5d2-flexcom"
> +- reg:   Should be the offset/length value for Flexcom 
> dedicated
> + I/O registers (without USART, TWI or SPI registers).
> +- clocks:Should be the Flexcom peripheral clock from PMC.
> +- #address-cells:Should be <1>
> +- #size-cells:   Should be <1>
> +- ranges:Should be one range for the full I/O register region
> + (including USART, TWI and SPI registers).
> +- atmel,flexcom-mode:Should be one of the 3 following macros as 
> defined in

They're not macros.

> + include/dt-bindings/mfd/atmel-flexcom.h:

This is Linux specific.  Please remove it from the binding document.

> + - ATMEL_FLEXCOM_MODE_USART for USART
> + - ATMEL_FLEXCOM_MODE_SPI for SPI
> + - ATMEL_FLEXCOM_MODE_TWI for I2C
> +
> +Required child:
> +a single child device of type matching the "atmel,flexcom-mode" property.

s/a/A/

> +The reg property of this child should be:
> +- <0x200 0x200> for USART
> +- <0x400 0x200> for SPI
> +- <0x600 0x200> for I2C

Address/offset information doesn't belong in the binding document.

> +The phandle provided by the clocks property of the child is the same as one 
> for
> +the Flexcom parent.
> +
> +Other properties remain unchanged. See documentation of the respective 
> device:

Unchanged since when?

> +- ../serial/atmel-usart.txt
> +- ../spi/spi_atmel.txt
> +- ../i2c/i2c-at91.txt
> +
> +Example:
> +
> +flexcom@f8034000 {
> + compatible = "atmel,sama5d2-flexcom";
> + reg = <0xf8034000 0x200>;
> + clocks = <&flx0_clk>;
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges = <0x0 0xf8034000 0x800>;
> + atmel,flexcom-mode = ;
> +
> + spi@400 {
> + compatible = "atmel,at91rm9200-spi";
> + reg = <0x400 0x200>;
> + interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&pinctrl_flx0_default>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clocks = <&flx0_clk>;
> + clock-names = "spi_clk";
> + atmel,fifo-size = <32>;
> +
> + mtd_dataflash@0 {
> + compatible = "atmel,at25f512b";
> + reg = <0>;
> + spi-max-frequency = <2000>;
> + };
> + };
> +};

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Re: [PATCH linux-next v10 1/3] mfd: atmel-flexcom: create include file with macros used by DT bindings

[Lee Jones]

On Thu, 24 Sep 2015, Cyrille Pitchen wrote:

> This patch defines some macros to be used as value for the
> "atmel,flexcom-mode" DT property. This value is then written into
> the Operating Mode (OPMODE) bit field of the Flexcom Mode Register.
> 
> Signed-off-by: Cyrille Pitchen 
> Acked-by: Nicolas Ferre 
> ---
>  include/dt-bindings/mfd/atmel-flexcom.h | 16 
>  1 file changed, 16 insertions(+)
>  create mode 100644 include/dt-bindings/mfd/atmel-flexcom.h
> 
> diff --git a/include/dt-bindings/mfd/atmel-flexcom.h 
> b/include/dt-bindings/mfd/atmel-flexcom.h
> new file mode 100644
> index ..6728f2851b4d
> --- /dev/null
> +++ b/include/dt-bindings/mfd/atmel-flexcom.h
> @@ -0,0 +1,16 @@
> +/*
> + * This header provides macros for Atmel Flexcom DT bindings.
> + *
> + * Copyright (C) 2015 Cyrille Pitchen 
> + *
> + * GPLv2 only

I'm not sure this constitutes as a proper licence statement.

> + */
> +
> +#ifndef __DT_BINDINGS_ATMEL_FLEXCOM_H__
> +#define __DT_BINDINGS_ATMEL_FLEXCOM_H__
> +
> +#define ATMEL_FLEXCOM_MODE_USART 1
> +#define ATMEL_FLEXCOM_MODE_SPI   2
> +#define ATMEL_FLEXCOM_MODE_TWI   3
> +
> +#endif /* __DT_BINDINGS_ATMEL_FLEXCOM_H__ */

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Re: [PATCH v3 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC

[Lee Jones]

On Fri, 25 Sep 2015, Andrew F. Davis wrote:

> On 09/25/2015 11:50 AM, Lee Jones wrote:
> >On Thu, 24 Sep 2015, Andrew F. Davis wrote:
> >
> >>This patch adds support for TPS65912 mfd device. It provides
> >>communication through the I2C and SPI interfaces. It contains
> >>the following components:
> >>
> >>  - Regulators
> >>  - GPIO controller
> >>
> >>Signed-off-by: Andrew F. Davis 
> >>---
> >>  drivers/mfd/Kconfig  |  24 +++
> >>  drivers/mfd/Makefile |   3 +
> >>  drivers/mfd/tps65912-core.c  | 114 +
> >>  drivers/mfd/tps65912-i2c.c   |  86 ++
> >>  drivers/mfd/tps65912-spi.c   |  85 ++
> >>  include/linux/mfd/tps65912.h | 393 
> >> +++
> >>  6 files changed, 705 insertions(+)
> >>  create mode 100644 drivers/mfd/tps65912-core.c
> >>  create mode 100644 drivers/mfd/tps65912-i2c.c
> >>  create mode 100644 drivers/mfd/tps65912-spi.c
> >>  create mode 100644 include/linux/mfd/tps65912.h
> >
> >[...]
> >
> >>+#define TPS65912_IRQ(_name, _reg, _offset) \
> >>+   [TPS65912_IRQ_ ## _name] = {\
> >>+   .mask = TPS65912_ ## _reg ## _ ## _name,\
> >>+   .reg_offset = _offset,  \
> >>+   }
> >
> >I told you about this already.
> >
> >If you want this set to be merged for v4.3 then you'll need commit
> >b4fe8ba ("regmap: Add generic macro to define regmap_irq") from my
> >tree.
> 
> You asked me to submit this to Mark Brown, I didn't realize you also
> wanted me to use the one in your tree. Using yours will make my lines
> over 80 chars and so it kind of defeats the purpose but I'll do it
> for v4.

I asked two of you to upstream a generic incarnation of your
implementation.  The other guy got there first.  Now I want everyone
to use it instead of hand-rolling their own.

> >[...]
> >
> >>+static struct i2c_driver tps65912_i2c_driver = {
> >>+   .driver = {
> >>+   .name   = "tps65912",
> >>+   .of_match_table = tps65912_i2c_of_match_table,
> >
> >of_match_ptr()
> >
> 
> Why? tps65912_i2c_of_match_table is always compiled in.

But it needn't be.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

[PATCH 2/3] Docs: dt: fsl-mc update binding to include definition of ranges

[Stuart Yoder]

Define a ranges property to specify the mapping between
the MC address space and the system address space.

Signed-off-by: Stuart Yoder 
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 30 +-
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 6aac955..848975f 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -35,6 +35,26 @@ Required properties:
 Definition: Must be present and point to the MSI controller node
 handling message interrupts for the MC.
 
+- ranges
+Value type: 
+Definition: A standard property.  Defines the mapping between the child
+MC address space and the parent system address space.
+
+The MC address space is defined by 3 components:
+ 
+
+Valid values for region type are
+   0x0 - MC portals
+   0x1 - QBMAN portals
+
+- #address-cells
+Value type: 
+Definition: Must be 3.  (see definition in 'ranges' property)
+
+- #size-cells
+Value type: 
+Definition: Must be 1.
+
 Example:
 
 fsl_mc: fsl-mc@80c00 {
@@ -42,5 +62,13 @@ Example:
 reg = <0x0008 0x0c00 0 0x40>,/* MC portal base */
   <0x 0x0834 0 0x4>; /* MC control reg */
 msi-parent = <&its>;
-};
+#address-cells = <3>;
+#size-cells = <1>;
 
+/*
+ * Region type 0x0 - MC portals
+ * Region type 0x1 - QBMAN portals
+ */
+ranges = <0x0 0x0 0x0 0x8 0x0c00 0x400
+  0x1 0x0 0x0 0x8 0x1800 0x800>;
+};
-- 
2.3.3

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

[PATCH v6 6/6] pinctrl: freescale: imx: imx7d iomuxc-lpsr devicetree bindings

[Adrian Alonso]

Add iomuxc-lpsr devicetree bindings documentation
Provide documentation context as well an example on
pheriperals that could use pad from either iomuxc controller
supported by iMX7D SoC

Signed-off-by: Adrian Alonso 
---
Changes for V2: New patch on imx7d iomuxc-lpsr patch series
Changes for V3: Add shared input select register notes
Changes for V4: Resend
Changes for V5:
- Fix spell error
- Remove references of SHARE_INPUT_SELECT_REG flag
Changes for v6: Resend

 .../bindings/pinctrl/fsl,imx7d-pinctrl.txt | 63 +-
 1 file changed, 62 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt 
b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
index 8bbf25d..aae069f 100644
--- a/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
+++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx7d-pinctrl.txt
@@ -1,16 +1,42 @@
 * Freescale i.MX7 Dual IOMUX Controller
 
+iMX7D supports two iomuxc controllers, fsl,imx7d-iomuxc controller is similar
+as previous iMX SoC generation and fsl,imx7d-iomuxc-lpsr which provides low
+power state retention capabilities on gpios that are part of iomuxc-lpsr
+(GPIO1_IO7..GPIO1_IO0). While iomuxc-lpsr provides its own set of registers for
+mux and pad control settings, it shares the input select register from main
+iomuxc controller for daisy chain settings, the fsl,input-sel property extends
+fsl,imx-pinctrl driver to support iomuxc-lpsr controller.
+
+iomuxc_lpsr: iomuxc-lpsr@302c {
+   compatible = "fsl,imx7d-iomuxc-lpsr";
+   reg = <0x302c 0x1>;
+   fsl,input-sel = <&iomuxc>;
+};
+
+iomuxc: iomuxc@3033 {
+   compatible = "fsl,imx7d-iomuxc";
+   reg = <0x3033 0x1>;
+};
+
+Pheriparials using pads from iomuxc-lpsr support low state retention power
+state, under LPSR mode GPIO's state of pads are retain.
+
 Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
 and usage.
 
 Required properties:
-- compatible: "fsl,imx7d-iomuxc"
+- compatible: "fsl,imx7d-iomuxc" for main IOMUXC controller, or
+  "fsl,imx7d-iomuxc-lpsr" for Low Power State Retention IOMUXC controller.
 - fsl,pins: each entry consists of 6 integers and represents the mux and config
   setting for one pin.  The first 5 integers  are specified using a PIN_FUNC_ID macro, which can be found in
   imx7d-pinfunc.h under device tree source folder.  The last integer CONFIG is
   the pad setting value like pull-up on this pin.  Please refer to i.MX7 Dual
   Reference Manual for detailed CONFIG settings.
+- fsl,input-sel: required property for iomuxc-lpsr controller, this property is
+  a phandle for main iomuxc controller which shares the input select register 
for
+  daisy chain settings.
 
 CONFIG bits definition:
 PAD_CTL_PUS_100K_DOWN   (0 << 5)
@@ -25,3 +51,38 @@ PAD_CTL_DSE_X1  (0 << 0)
 PAD_CTL_DSE_X2  (1 << 0)
 PAD_CTL_DSE_X3  (2 << 0)
 PAD_CTL_DSE_X4  (3 << 0)
+
+Examples:
+While iomuxc-lpsr is intended to be used by dedicated peripherals to take
+advantages of LPSR power mode, is also possible that an IP to use pads from
+any of the iomux controllers. For example the I2C1 IP can use SCL pad from
+iomuxc-lpsr controller and SDA pad from iomuxc controller as:
+
+i2c1: i2c@30a2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_i2c1_1 &pinctrl_i2c1_2>;
+   status = "okay";
+};
+
+iomuxc-lpsr@302c {
+   compatible = "fsl,imx7d-iomuxc-lpsr";
+   reg = <0x302c 0x1>;
+   fsl,input-sel = <&iomuxc>;
+
+   pinctrl_i2c1_1: i2c1grp-1 {
+   fsl,pins = <
+   MX7D_PAD_GPIO1_IO04__I2C1_SCL 0x407f
+   >;
+   };
+};
+
+iomuxc@3033 {
+   compatible = "fsl,imx7d-iomuxc";
+   reg = <0x3033 0x1>;
+
+   pinctrl_i2c1_2: i2c1grp-2 {
+   fsl,pins = <
+   MX7D_PAD_I2C1_SCL__I2C1_SCL 0x407f
+   >;
+   };
+};
-- 
2.1.4

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

[PATCH 0/3] Docs: dt: update binding for Freescale Management Complex

[Stuart Yoder]

Update the binding for the Freescale Management Complex to include definition
of ranges, msi-parent, and dpmac subnodes.

Stuart Yoder (3):
  Docs: dt: fsl-mc: update binding to include msi-parent
  Docs: dt: fsl-mc update binding to include definition of ranges
  Docs: dt: fsl-mc: update binding to define dpmac subnodes

 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 81 +-
 1 file changed, 80 insertions(+), 1 deletion(-)

-- 
2.3.3

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

[PATCH 3/3] Docs: dt: fsl-mc: update binding to define dpmac subnodes

[Stuart Yoder]

The fsl-mc node may optionally have dpmac sub-nodes that describe
the relationship between the Ethernet MACs which belong to the MC
and the Ethernet PHYs on the system board.

Signed-off-by: Stuart Yoder 
---
 .../devicetree/bindings/misc/fsl,qoriq-mc.txt  | 45 ++
 1 file changed, 45 insertions(+)

diff --git a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt 
b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
index 848975f..6611a7c 100644
--- a/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,qoriq-mc.txt
@@ -55,6 +55,40 @@ Required properties:
 Value type: 
 Definition: Must be 1.
 
+Sub-nodes:
+
+The fsl-mc node may optionally have dpmac sub-nodes that describe
+the relationship between the Ethernet MACs which belong to the MC
+and the Ethernet PHYs on the system board.
+
+The dpmac nodes must be under a node named "dpmacs" which contains
+the following properties:
+
+- #address-cells
+  Value type: 
+  Definition: Must be present if dpmac sub-nodes are defined and 
must
+  have a value of 1.
+
+- #size-cells
+  Value type: 
+  Definition: Must be present if dpmac sub-nodes are defined and 
must
+  have a value of 0.
+
+These nodes must have the following properties:
+
+- compatible
+  Value type: 
+  Definition: Must be "fsl,qoriq-mc-dpmac".
+
+- reg
+  Value type: 
+  Definition: Specifies the id of the dpmac.
+
+- phy-handle
+  Value type: 
+  Definition: Specifies the phandle to the PHY device node 
associated
+  with the this dpmac.
+
 Example:
 
 fsl_mc: fsl-mc@80c00 {
@@ -71,4 +105,15 @@ Example:
  */
 ranges = <0x0 0x0 0x0 0x8 0x0c00 0x400
   0x1 0x0 0x0 0x8 0x1800 0x800>;
+
+dpmacs {
+#address-cells = <1>;
+#size-cells = <0>;
+
+dpmac@1 {
+compatible = "fsl,qoriq-mc-dpmac";
+reg = <1>;
+phy-handle = <&mdio0_phy0>;
+}
+}
 };
-- 
2.3.3

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

RE: [PATCH v6 4/9] Input: goodix - write configuration data to device

[Tirdea, Irina]

> -Original Message-
> From: Bastien Nocera [mailto:had...@hadess.net]
> Sent: 25 September, 2015 17:41
> To: Tirdea, Irina; Dmitry Torokhov; Aleksei Mamlin; 
> linux-in...@vger.kernel.org
> Cc: Mark Rutland; Purdila, Octavian; linux-ker...@vger.kernel.org; 
> devicetree@vger.kernel.org
> Subject: Re: [PATCH v6 4/9] Input: goodix - write configuration data to device
> 
> On Tue, 2015-09-15 at 17:31 +0300, Irina Tirdea wrote:
> > Goodix devices can be configured by writing custom data to the device
> > at
> > init. The configuration data is read with request_firmware from
> > "goodix__cfg.bin", where  is the product id read from the
> > device
> > (e.g.: goodix_911_cfg.bin for Goodix GT911, goodix_9271_cfg.bin for
> > GT9271).
> >
> > The configuration information has a specific format described in the
> > Goodix
> > datasheet. It includes X/Y resolution, maximum supported touch
> > points,
> > interrupt flags, various sesitivity factors and settings for advanced
> 
> sensitivity.

Will fix this in next version of the patches. I will wait for you reply on
the gpio issue before sending a new version.

Thanks,
Irina

N�r��yb�X��ǧv�^�)޺{.n�+���z��z��z)w*jg����ݢj/���z�ޖ��2�ޙ&�)ߡ�a�����G���h��j:+v���w��٥

[PATCH v6 2/6] ARM: dts: imx: imx7d-sbd add iomuxc-lpsr hoggrp-2 pads

[Adrian Alonso]

Add imx7d-sdb iomuxc-lpsr hoggrp-2 default pads settings

Signed-off-by: Adrian Alonso 
---
Changes for V2: Resend
Changes for V3: Resend
Changes for V4: Resend
Changes for V5: Resend
Changes for V6:
- Add wdog pinctrl group, add comments for hog2 group gpios

 arch/arm/boot/dts/imx7d-sdb.dts | 20 
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d-sdb.dts b/arch/arm/boot/dts/imx7d-sdb.dts
index 8059458..2da704a 100644
--- a/arch/arm/boot/dts/imx7d-sdb.dts
+++ b/arch/arm/boot/dts/imx7d-sdb.dts
@@ -419,3 +419,23 @@
 
};
 };
+
+&iomuxc_lpsr {
+   pinctrl-names = "default";
+   pinctrl-0 = <&pinctrl_hog_2>;
+
+   imx7d-sdb {
+   pinctrl_hog_2: hoggrp-2 {
+   fsl,pins = <
+   MX7D_PAD_GPIO1_IO05__GPIO1_IO50x14  /* 
usb_otg1_pwr */
+   MX7D_PAD_GPIO1_IO07__GPIO1_IO70x59  /* 
sensor_int_b */
+   >;
+   };
+
+   pinctrl_wdog: wdoggrp {
+   fsl,pins = <
+   MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
+   >;
+   };
+   };
+};
-- 
2.1.4

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

[PATCH v6 3/6] pinctrl: freescale: imx: allow mux_reg offset zero

[Adrian Alonso]

Allow mux_reg offset zero to be a valid pin_id, on imx7d
mux_conf reg offset is zero for iomuxc-lspr controller

Signed-off-by: Adrian Alonso 
---
Changes for V2: Resend
Changes for V3: Resend
Changes for V4: Simplify pin_id assigment when ZERO_OFFSET_VALID is set
Changes for V5:
- Drop patch pinctrl: freescale: imx: add ZERO_OFFSET_VALID flag
- Allow mux_reg ZERO OFFSET as pin_id
Changes for V6: Restore ZERO_OFFSET_VALID flag

 drivers/pinctrl/freescale/pinctrl-imx.c | 5 -
 drivers/pinctrl/freescale/pinctrl-imx.h | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c 
b/drivers/pinctrl/freescale/pinctrl-imx.c
index b9c6deb..151d50d 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -542,6 +542,9 @@ static int imx_pinctrl_parse_groups(struct device_node *np,
struct imx_pin_reg *pin_reg;
struct imx_pin *pin = &grp->pins[i];
 
+   if (!(info->flags & ZERO_OFFSET_VALID) && !mux_reg)
+   mux_reg = -1;
+
if (info->flags & SHARE_MUX_CONF_REG) {
conf_reg = mux_reg;
} else {
@@ -550,7 +553,7 @@ static int imx_pinctrl_parse_groups(struct device_node *np,
conf_reg = -1;
}
 
-   pin_id = mux_reg ? mux_reg / 4 : conf_reg / 4;
+   pin_id = (mux_reg != -1) ? mux_reg / 4 : conf_reg / 4;
pin_reg = &info->pin_regs[pin_id];
pin->pin = pin_id;
grp->pin_ids[i] = pin_id;
diff --git a/drivers/pinctrl/freescale/pinctrl-imx.h 
b/drivers/pinctrl/freescale/pinctrl-imx.h
index 2a5fe72..2a592f6 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.h
+++ b/drivers/pinctrl/freescale/pinctrl-imx.h
@@ -85,6 +85,7 @@ struct imx_pinctrl_soc_info {
 };
 
 #define SHARE_MUX_CONF_REG 0x1
+#define ZERO_OFFSET_VALID  0x2
 
 #define NO_MUX 0x0
 #define NO_PAD 0x0
-- 
2.1.4

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

[PATCH v6 5/6] pinctrl: freescale: imx7d: support iomux lpsr controller

[Adrian Alonso]

iMX7D has two iomuxc controllers, iomuxc controller similar as
previous iMX SoC generation and iomuxc-lpsr which provides low
power state rentetion capabilities on gpios that are part of
iomuxc-lpsr

Add iomuxc-lpsr gpio group id's

Signed-off-by: Adrian Alonso 
---
Changes for V2: Add imx7d_lpsr_pads enums
Changes for V3: Resend
Changes for V4: Resend
Changes for V5: Remove flags SHARE_INPUT_SELECT_REG and 
 ZERO_OFFSET_VALID.
Changes for V6: Restore ZERO_OFFSET_VALID flag.

 drivers/pinctrl/freescale/pinctrl-imx7d.c | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx7d.c 
b/drivers/pinctrl/freescale/pinctrl-imx7d.c
index 1fa7530..16dc925 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx7d.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx7d.c
@@ -174,6 +174,17 @@ enum imx7d_pads {
MX7D_PAD_ENET1_COL = 154,
 };
 
+enum imx7d_lpsr_pads {
+   MX7D_PAD_GPIO1_IO00 = 0,
+   MX7D_PAD_GPIO1_IO01 = 1,
+   MX7D_PAD_GPIO1_IO02 = 2,
+   MX7D_PAD_GPIO1_IO03 = 3,
+   MX7D_PAD_GPIO1_IO04 = 4,
+   MX7D_PAD_GPIO1_IO05 = 5,
+   MX7D_PAD_GPIO1_IO06 = 6,
+   MX7D_PAD_GPIO1_IO07 = 7,
+};
+
 /* Pad names for the pinmux subsystem */
 static const struct pinctrl_pin_desc imx7d_pinctrl_pads[] = {
IMX_PINCTRL_PIN(MX7D_PAD_RESERVE0),
@@ -333,13 +344,32 @@ static const struct pinctrl_pin_desc imx7d_pinctrl_pads[] 
= {
IMX_PINCTRL_PIN(MX7D_PAD_ENET1_COL),
 };
 
+/* Pad names for the pinmux subsystem */
+static const struct pinctrl_pin_desc imx7d_lpsr_pinctrl_pads[] = {
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO00),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO01),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO02),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO03),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO04),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO05),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO06),
+   IMX_PINCTRL_PIN(MX7D_PAD_GPIO1_IO07),
+};
+
 static struct imx_pinctrl_soc_info imx7d_pinctrl_info = {
.pins = imx7d_pinctrl_pads,
.npins = ARRAY_SIZE(imx7d_pinctrl_pads),
 };
 
+static struct imx_pinctrl_soc_info imx7d_lpsr_pinctrl_info = {
+   .pins = imx7d_lpsr_pinctrl_pads,
+   .npins = ARRAY_SIZE(imx7d_lpsr_pinctrl_pads),
+   .flags = ZERO_OFFSET_VALID,
+};
+
 static struct of_device_id imx7d_pinctrl_of_match[] = {
{ .compatible = "fsl,imx7d-iomuxc", .data = &imx7d_pinctrl_info, },
+   { .compatible = "fsl,imx7d-iomuxc-lpsr", .data = 
&imx7d_lpsr_pinctrl_info },
{ /* sentinel */ }
 };
 
-- 
2.1.4

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

[PATCH v6 4/6] pinctrl: freescale: imx: add shared input select reg support

[Adrian Alonso]

- Add shared input select register support
- imx7d has two iomux controllers iomuxc and iomuxc-lpsr
  which share select_input register for daisy chain settings

Signed-off-by: Adrian Alonso 
---
Changes for V2: Resend
Changes for V3:
- Use of_parse_phandle instead of of_get_child_by_name to get input select
  base register address
Changes for V4: Resend
Changes for V5:
- Remove SHARE_INPUT_SELECT_REG flag
- Use fsl,input-sel to check if shared input select register support is used
Changes for V6: Resend

 drivers/pinctrl/freescale/pinctrl-imx.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c 
b/drivers/pinctrl/freescale/pinctrl-imx.c
index 151d50d..a5bb939 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -39,6 +40,7 @@ struct imx_pinctrl {
struct device *dev;
struct pinctrl_dev *pctl;
void __iomem *base;
+   void __iomem *input_sel_base;
const struct imx_pinctrl_soc_info *info;
 };
 
@@ -254,7 +256,12 @@ static int imx_pmx_set(struct pinctrl_dev *pctldev, 
unsigned selector,
 * Regular select input register can never be at offset
 * 0, and we only print register value for regular case.
 */
-   writel(pin->input_val, ipctl->base + pin->input_reg);
+   if (ipctl->input_sel_base)
+   writel(pin->input_val, ipctl->input_sel_base +
+   pin->input_reg);
+   else
+   writel(pin->input_val, ipctl->base +
+   pin->input_reg);
dev_dbg(ipctl->dev,
"==>select_input: offset 0x%x val 0x%x\n",
pin->input_reg, pin->input_val);
@@ -685,6 +692,8 @@ static int imx_pinctrl_probe_dt(struct platform_device 
*pdev,
 int imx_pinctrl_probe(struct platform_device *pdev,
  struct imx_pinctrl_soc_info *info)
 {
+   struct device_node *dev_np = pdev->dev.of_node;
+   struct device_node *np;
struct imx_pinctrl *ipctl;
struct resource *res;
int ret, i;
@@ -715,6 +724,23 @@ int imx_pinctrl_probe(struct platform_device *pdev,
if (IS_ERR(ipctl->base))
return PTR_ERR(ipctl->base);
 
+   if (of_property_read_bool(dev_np, "fsl,input-sel")) {
+   np = of_parse_phandle(dev_np, "fsl,input-sel", 0);
+   if (np) {
+   ipctl->input_sel_base = of_iomap(np, 0);
+   if (IS_ERR(ipctl->input_sel_base)) {
+   of_node_put(np);
+   dev_err(&pdev->dev,
+   "iomuxc input select base address not 
found\n");
+   return PTR_ERR(ipctl->input_sel_base);
+   }
+   } else {
+   dev_err(&pdev->dev, "iomuxc fsl,input-sel property not 
found\n");
+   return -EINVAL;
+   }
+   of_node_put(np);
+   }
+
imx_pinctrl_desc.name = dev_name(&pdev->dev);
imx_pinctrl_desc.pins = info->pins;
imx_pinctrl_desc.npins = info->npins;
-- 
2.1.4

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

[PATCH v6 1/6] ARM: dts: imx: imx7d add iomuxc lpsr device node

[Adrian Alonso]

Add device tree node to support iomuxc-lpsr controller, fsl,iput-sel
phandle allows to get input select register base address which is
shared from main iomuxc controller.

Signed-off-by: Adrian Alonso 
---
Changes for V2: Resend
Changes for V3: Add phandle to get input select register base address
Changes for V4: Resend
Changes for V5: Rename property to fsl,input-sel
Changes for V6: Resend

 arch/arm/boot/dts/imx7d.dtsi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/arch/arm/boot/dts/imx7d.dtsi b/arch/arm/boot/dts/imx7d.dtsi
index 15c2193..92ef0a9 100644
--- a/arch/arm/boot/dts/imx7d.dtsi
+++ b/arch/arm/boot/dts/imx7d.dtsi
@@ -446,6 +446,12 @@
status = "disabled";
};
 
+   iomuxc_lpsr: iomuxc-lpsr@302c {
+   compatible = "fsl,imx7d-iomuxc-lpsr";
+   reg = <0x302c 0x1>;
+   fsl,input-sel = <&iomuxc>;
+   };
+
gpt1: gpt@302d {
compatible = "fsl,imx7d-gpt", "fsl,imx6sx-gpt";
reg = <0x302d 0x1>;
-- 
2.1.4

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

RE: [PATCH v3 1/5] Input: goodix - reset device at init

[Tirdea, Irina]

> -Original Message-
> From: Bastien Nocera [mailto:had...@hadess.net]
> Sent: 25 September, 2015 17:44
> To: Tirdea, Irina; linux-in...@vger.kernel.org
> Cc: linux-ker...@vger.kernel.org; Rob Herring; Pawel Moll; Ian Campbell; 
> Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark
> Rutland; devicetree@vger.kernel.org
> Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init
> 
> On Thu, 2015-09-10 at 14:04 +, Tirdea, Irina wrote:
> >
> > > -Original Message-
> > > From: Bastien Nocera [mailto:had...@hadess.net]
> > > Sent: 09 September, 2015 20:03
> > > To: Tirdea, Irina; linux-in...@vger.kernel.org
> > > Cc: linux-ker...@vger.kernel.org; Rob Herring; Pawel Moll; Ian
> > > Campbell; Kumar Gala; Purdila, Octavian; Dmitry Torokhov; Mark
> > > Rutland; devicetree@vger.kernel.org
> > > Subject: Re: [PATCH v3 1/5] Input: goodix - reset device at init
> > >
> > > On Thu, 2015-07-30 at 11:27 +, Tirdea, Irina wrote:
> > > > I can send some additional patches that will simplify testing the
> > > > configuration update to the Goodix device. I think this feature
> > > > is
> > > > the easiest
> > > > to test so we can determine if writing to the interrupt pin
> > > > actually
> > > > works.
> > > > However, even if it is a BIOS problem and the code will work, the
> > > > warning
> > > > will still be printed in dmesg.
> > >
> > >
> > > Somehow missed this mail before replying to the current patchset.
> > > I'd
> > > be fine with that, though it's still not clear to me whether the
> > > BIOS/hardware is at fault, or the code that's being added to the
> > > driver
> > > ;)
> > >
> >
> > The reset procedure is described in the Goodix GT911 datasheet [1]
> > and is
> > used for power-on reset and power management. The power-on sequence
> > is described in chapter 6.1. I2C Timing, in the Power-on Timing
> > diagram.
> > The sequence for putting the device to sleep is described in chapter
> > 7.1. Operating Modes, c) Sleep mode. These sequences use the
> > interrupt
> > pin as output.
> >
> > The warning you mentioned comes from the following code in the goodix
> > driver, which sets the interrupt to be used as output:
> >
> > +   error = gpiod_direction_output(ts->gpiod_int, ts->client-
> > >addr == 0x14);
> >
> > The gpiod_direction_output() call ends up in
> > drivers/pinctrl/intel/pinctrl-baytrail.c:
> > /*
> >  * Before making any direction modifications, do a check if gpio
> >  * is set for direct IRQ.  On baytrail, setting GPIO to output does
> >  * not make sense, so let's at least warn the caller before they
> > shoot
> >  * themselves in the foot.
> >  */
> > WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN,
> > "Potential Error: Setting GPIO with direct_irq_en to output");
> >
> > So the problem comes from using the gpio interrupt pin as output,
> > which
> > should not work on Baytrail if BYT_DIRECT_IRQ_EN is set by BIOS.
> > The above warning is introduced and discussed in [2] and [3]. As I
> > mentioned,
> > this could be a real HW issue or the BIOS sets BYT_DIRECT_IRQ_EN when
> > it should not. I have also tested these patches on a Baytrail
> > plarform
> > (that uses the same pinctrl driver), but I did not see any issues
> > since
> > BYT_DIRECT_IRQ_EN is not set in my case for the interrupt gpio pin.
> 
> Do we have a way to work-around this in the GPIO driver?
> 
> > To determine if using the interrupt pin as output works, you can test
> > updating
> > the goodix configuration [4].
> 
> Right, the problem being that it's a later patch in the branch, and
> that the driver will fail to probe if there's an error from the GPIO
> call.
> 

The warning from your dmesg output will not cause probe to fail.
If you look at the code for byt_gpio_direction_output, it will just print
a warning and continue [1]:
WARN(readl(conf_reg) & BYT_DIRECT_IRQ_EN,
"Potential Error: Setting GPIO with direct_irq_en to output");
I thought probe finishes successfully, but due to the warning in dmesg you
are not sure whether the IRQ GPIO pin can be used as output.
If probe fails, it must be for another reason than the direct_irq_en warning.

> Would you have a patch for me to test that would bypass this error, or
> at least fallback gracefully to not resetting, not probing GPIOs if
> they're badly setup?

If the driver fails to initialize the GPIOs, it will at least print some
"Failed to get GPIO" warnings in dmesg. Do you have such messages in
dmesg or any additional information on why probe fails?

The current code will ignore GPIOs if they are not defined in ACPI
(see the check for -ENOENT), but does not ignore other error codes.
If you want to bypass all GPIO errors, you can use the code below.

Thanks,
Irina

diff --git a/drivers/input/touchscreen/goodix.c 
b/drivers/input/touchscreen/goodix.c
index 9c58583..f7ec0ba 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -528,9 +528,7 @@ static int goodix_ts_probe(struct i2c_client *

Re: [PATCH v5 4/7] pinctrl: freescale: imx: allow mux_reg offset zero

[Shawn Guo]

On Fri, Sep 25, 2015 at 07:16:49PM +, Alonso Adrian wrote:
> > Ah, sorry, I'm screwed on the previous review.  So we still need the flag
> > ZERO_OFFSET_VALID to convert invalid 0 mux_reg to -1.
> > 
> > @Adrian,
> > 
> > Will the following change just work for you?
> @Shawn, yes the change will work, do you want me to prepare a new patch 
> series?

Most of the patches in this series will go to Linus.  So that's his
call, but I suggest you resend.

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

[PATCH v3] Documentation: DT: twl-charger: document new iio properties

[Marek Belisko]

Document added iio properties to avoid using direct function call from 
twl4030-madc
driver.

Signed-off-by: Marek Belisko 
---
 Documentation/devicetree/bindings/power/twl-charger.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/power/twl-charger.txt 
b/Documentation/devicetree/bindings/power/twl-charger.txt
index 3b4ea1b..e198650 100644
--- a/Documentation/devicetree/bindings/power/twl-charger.txt
+++ b/Documentation/devicetree/bindings/power/twl-charger.txt
@@ -19,12 +19,18 @@ Required properties:
 Optional properties:
 - ti,bb-uvolt: microvolts for charging the backup battery.
 - ti,bb-uamp: microamps for charging the backup battery.
+- io-channels: Should contain following: <&twl4030_madc 11>
+- io-channel-names: Should contains following value:
+   * "vac" - ADC channel for measuring the voltage of the external AC 
charger
+If io properties aren't provided then functionality of accesory charger 
doesn't work.
 
 Examples:
 
 bci {
compatible = "ti,twl4030-bci";
interrupts = <9>, <2>;
+   io-channels = <&twl4030_madc 11>;
+   io-channel-name = "vac";
ti,bb-uvolt = <320>;
ti,bb-uamp = <150>;
 };
-- 
1.9.1

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

[PATCH v3] ARM: dts: twl4030: Add iio properties for bci subnode

[Marek Belisko]

Added new iio properties which are required for twl4030-charger driver and
allow to use twl4030-madc indirectly.

Signed-off-by: Marek Belisko 
---
 arch/arm/boot/dts/twl4030.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/twl4030.dtsi b/arch/arm/boot/dts/twl4030.dtsi
index 36ae916..482b7aa 100644
--- a/arch/arm/boot/dts/twl4030.dtsi
+++ b/arch/arm/boot/dts/twl4030.dtsi
@@ -22,6 +22,8 @@
charger: bci {
compatible = "ti,twl4030-bci";
interrupts = <9>, <2>;
+   io-channels = <&twl4030_madc 11>;
+   io-channel-name = "vac";
bci3v1-supply = <&vusb3v1>;
};
 
-- 
1.9.1

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

[PATCH v3] drivers: power: twl4030_charger: fix link problems when building as module

[Marek Belisko]

If either twl4030_charger or twl4030_madc is configured as MODULE,
we get build (link) errors.

To solve, the direct call of twl4030_get_madc_conversion() is replaced
by a call to iio_read_channel_processed().

Signed-off-by: H. Nikolaus Schaller 
Signed-off-by: Marek Belisko 
---
changes from v2: make iio propries optional to keep functionality for old DT 
also
changes from V1: added missing iio_channel_release + document and add new DT 
bindings
 drivers/power/twl4030_charger.c | 45 -
 1 file changed, 31 insertions(+), 14 deletions(-)

diff --git a/drivers/power/twl4030_charger.c b/drivers/power/twl4030_charger.c
index f4f2c1f..82e2a05 100644
--- a/drivers/power/twl4030_charger.c
+++ b/drivers/power/twl4030_charger.c
@@ -22,7 +22,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 #define TWL4030_BCIMDEN0x00
 #define TWL4030_BCIMDKEY   0x01
@@ -91,21 +91,23 @@
 #define TWL4030_MSTATEC_COMPLETE1  0x0b
 #define TWL4030_MSTATEC_COMPLETE4  0x0e
 
-#if IS_ENABLED(CONFIG_TWL4030_MADC)
 /*
  * If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
  * then AC is available.
  */
-static inline int ac_available(void)
+static inline int ac_available(struct iio_channel *channel_vac)
 {
-   return twl4030_get_madc_conversion(11) > 4500;
-}
-#else
-static inline int ac_available(void)
-{
-   return 0;
+   int val, err;
+
+   if (!channel_vac)
+   return 0;
+
+   err = iio_read_channel_processed(channel_vac, &val);
+   if (err < 0)
+   return 0;
+   return val > 4500;
 }
-#endif
+
 static bool allow_usb;
 module_param(allow_usb, bool, 0644);
 MODULE_PARM_DESC(allow_usb, "Allow USB charge drawing default current");
@@ -128,6 +130,7 @@ struct twl4030_bci {
 */
unsigned intichg_eoc, ichg_lo, ichg_hi;
unsigned intusb_cur, ac_cur;
+   struct iio_channel  *channel_vac;
boolac_is_active;
int usb_mode, ac_mode; /* charging mode requested */
 #defineCHARGE_OFF  0
@@ -278,7 +281,7 @@ static int twl4030_charger_update_current(struct 
twl4030_bci *bci)
 * If AC (Accessory Charger) voltage exceeds 4.5V (MADC 11)
 * and AC is enabled, set current for 'ac'
 */
-   if (ac_available()) {
+   if (ac_available(bci->channel_vac)) {
cur = bci->ac_cur;
bci->ac_is_active = true;
} else {
@@ -1048,6 +1051,12 @@ static int twl4030_bci_probe(struct platform_device 
*pdev)
return ret;
}
 
+   bci->channel_vac = iio_channel_get(&pdev->dev, "vac");
+   if (IS_ERR(bci->channel_vac)) {
+   bci->channel_vac = NULL;
+   dev_warn(&pdev->dev, "could not request vac iio channel");
+   }
+
INIT_WORK(&bci->work, twl4030_bci_usb_work);
INIT_DELAYED_WORK(&bci->current_worker, twl4030_current_worker);
 
@@ -1061,8 +1070,10 @@ static int twl4030_bci_probe(struct platform_device 
*pdev)
bci->transceiver = devm_usb_get_phy_by_node(
bci->dev, phynode, &bci->usb_nb);
if (IS_ERR(bci->transceiver) &&
-   PTR_ERR(bci->transceiver) == -EPROBE_DEFER)
-   return -EPROBE_DEFER;
+   PTR_ERR(bci->transceiver) == -EPROBE_DEFER) {
+   ret = -EPROBE_DEFER;
+   goto fail;
+   }
}
}
 
@@ -1073,7 +1084,7 @@ static int twl4030_bci_probe(struct platform_device *pdev)
   TWL4030_INTERRUPTS_BCIIMR1A);
if (ret < 0) {
dev_err(&pdev->dev, "failed to unmask interrupts: %d\n", ret);
-   return ret;
+   goto fail;
}
 
reg = ~(u32)(TWL4030_VBATOV | TWL4030_VBUSOV | TWL4030_ACCHGOV);
@@ -1106,6 +1117,10 @@ static int twl4030_bci_probe(struct platform_device 
*pdev)
twl4030_charger_enable_backup(0, 0);
 
return 0;
+fail:
+   iio_channel_release(bci->channel_vac);
+
+   return ret;
 }
 
 static int __exit twl4030_bci_remove(struct platform_device *pdev)
@@ -1116,6 +1131,8 @@ static int __exit twl4030_bci_remove(struct 
platform_device *pdev)
twl4030_charger_enable_usb(bci, false);
twl4030_charger_enable_backup(0, 0);
 
+   iio_channel_release(bci->channel_vac);
+
device_remove_file(&bci->usb->dev, &dev_attr_max_current);
device_remove_file(&bci->usb->dev, &dev_attr_mode);
device_remove_file(&bci->ac->dev, &dev_attr_max_current);
-- 
1.9.1

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

Re: [PATCH v3 4/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC

[Andrew F. Davis]

On 09/25/2015 01:05 PM, Mark Brown wrote:

On Thu, Sep 24, 2015 at 09:52:53AM -0500, Andrew F. Davis wrote:


+static int tps65912_regulator_probe(struct platform_device *pdev)
+{
+   struct tps65912 *tps = dev_get_drvdata(pdev->dev.parent);
+   struct regulator_init_data *init_data;
+   const struct tps_info *template;
+   struct regulator_dev *rdev;
+   const struct of_device_id *match;
+   struct regulator_config config = { };
+   int id;
+
+   match = of_match_device(tps65912_regulator_of_match_table, &pdev->dev);
+   if (!match)
+   return -ENODEV;
+
+   template = match->data;
+   id = template->id;
+   init_data = of_get_regulator_init_data(&pdev->dev, pdev->dev.of_node,
+  ®ulators[id]);


Don't open code this stuff, use the core DT matching in the
regulator_desc instead.



I assume you are referring to your additions in a0c7b164ad11? If so I'm not
sure that will save me anything as my probe function is called with a DT
match already, so no searching is needed.


Please also use subject lines mathcing the style for the subsystem.



I'm not sure I know what you mean? What is wrong with my subject line, it looks
like the others I've looked at?
--
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

[PATCHv4 1/3] of: Add vendor prefix for Analogix Semiconductor, Inc.

[Enric Balletbo i Serra]

Analogix Semiconductor develops analog and mixed-signal devices for digital
media and communications interconnect applications.

Signed-off-by: Enric Balletbo i Serra 
Acked-by: Rob Herring 
---
 Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index ac5f0c3..e914a02 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -22,6 +22,7 @@ ampireAmpire Co., Ltd.
 amsAMS AG
 amstaosAMS-Taos Inc.
 apmApplied Micro Circuits Corporation (APM)
+analogix   Analogix Semiconductor, Inc.
 aptina Aptina Imaging
 arasan Arasan Chip Systems
 armARM Ltd.
-- 
2.1.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

[PATCHv4 2/3] devicetree: Add new ANX7814 SlimPort transmitter binding.

[Enric Balletbo i Serra]

The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.

You can add support to your board with current binding.

Example:

anx7814: anx7814@38 {
compatible = "analogix,anx7814";
reg = <0x38>;
pd-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
reset-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
};

Signed-off-by: Enric Balletbo i Serra 
---
 .../devicetree/bindings/video/bridge/anx7814.txt   | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt

diff --git a/Documentation/devicetree/bindings/video/bridge/anx7814.txt 
b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
new file mode 100644
index 000..a8cc746
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/bridge/anx7814.txt
@@ -0,0 +1,22 @@
+Analogix ANX7814 SlimPort (Full-HD Transmitter)
+---
+
+The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
+designed for portable devices.
+
+Required properties:
+
+ - compatible  : "analogix,anx7814"
+ - reg : I2C address of the device
+ - pd-gpios: Which GPIO to use for power down
+ - reset-gpios : Which GPIO to use for reset
+
+Example:
+
+   anx7814: anx7814@38 {
+   compatible = "analogix,anx7814";
+   reg = <0x38>;
+   pd-gpios = <&gpio0 1 GPIO_ACTIVE_HIGH>;
+   reset-gpios = <&gpio0 2 GPIO_ACTIVE_HIGH>;
+   };
+
-- 
2.1.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

[PATCHv4 3/3] drm: bridge: anx78xx: Add anx78xx driver support by analogix.

[Enric Balletbo i Serra]

At the moment it only supports ANX7814.

The ANX7814 is an ultra-low power Full-HD (1080p60) SlimPort transmitter
designed for portable devices.

This driver adds initial support and supports HDMI to DP pass-through mode.

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/gpu/drm/bridge/Kconfig   |2 +
 drivers/gpu/drm/bridge/Makefile  |1 +
 drivers/gpu/drm/bridge/anx78xx/Kconfig   |7 +
 drivers/gpu/drm/bridge/anx78xx/Makefile  |4 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx.h |   41 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c|  228 ++
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c | 3148 ++
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h |  214 ++
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h |  807 ++
 9 files changed, 4452 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Makefile
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 2de52a5..aa6fe12 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -29,4 +29,6 @@ config DRM_PARADE_PS8622
---help---
  Parade eDP-LVDS bridge chip driver.
 
+source "drivers/gpu/drm/bridge/anx78xx/Kconfig"
+
 endmenu
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index e2eef1c..e5bd38b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -3,3 +3,4 @@ ccflags-y := -Iinclude/drm
 obj-$(CONFIG_DRM_DW_HDMI) += dw_hdmi.o
 obj-$(CONFIG_DRM_NXP_PTN3460) += nxp-ptn3460.o
 obj-$(CONFIG_DRM_PARADE_PS8622) += parade-ps8622.o
+obj-$(CONFIG_DRM_ANX78XX) += anx78xx/
diff --git a/drivers/gpu/drm/bridge/anx78xx/Kconfig 
b/drivers/gpu/drm/bridge/anx78xx/Kconfig
new file mode 100644
index 000..08f9c08
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/Kconfig
@@ -0,0 +1,7 @@
+config DRM_ANX78XX
+   tristate "Analogix ANX78XX bridge"
+   help
+   ANX78XX is a HD video transmitter chip over micro-USB
+   connector for smartphone device.
+
+
diff --git a/drivers/gpu/drm/bridge/anx78xx/Makefile 
b/drivers/gpu/drm/bridge/anx78xx/Makefile
new file mode 100644
index 000..a843733
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/Makefile
@@ -0,0 +1,4 @@
+obj-${CONFIG_DRM_ANX78XX} :=  anx78xx.o
+
+anx78xx-y += anx78xx_main.o
+anx78xx-y += slimport_tx_drv.o
diff --git a/drivers/gpu/drm/bridge/anx78xx/anx78xx.h 
b/drivers/gpu/drm/bridge/anx78xx/anx78xx.h
new file mode 100644
index 000..f62c8e7
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/anx78xx.h
@@ -0,0 +1,41 @@
+/*
+ * Copyright(c) 2015, Analogix Semiconductor. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#ifndef __ANX78xx_H
+#define __ANX78xx_H
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct anx78xx_platform_data {
+   struct gpio_desc *gpiod_pd;
+   struct gpio_desc *gpiod_reset;
+   spinlock_t lock;
+};
+
+struct anx78xx {
+   struct i2c_client *client;
+   struct anx78xx_platform_data *pdata;
+   struct delayed_work work;
+   struct workqueue_struct *workqueue;
+   struct mutex lock;
+};
+
+void anx78xx_poweron(struct anx78xx *data);
+void anx78xx_poweroff(struct anx78xx *data);
+
+#endif
diff --git a/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c 
b/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
new file mode 100644
index 000..1e4a87e
--- /dev/null
+++ b/drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
@@ -0,0 +1,228 @@
+/*
+ * Copyright(c) 2015, Analogix Semiconductor. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#

[PATCHv4 0/3] Add initial support for slimport anx78xx

[Enric Balletbo i Serra]

Hi all,

This is the fouth version with fixes suggested by Nicolas Boichat and Dan 
Carpenter.

See the changelog below for details.

The following series add initial support for the Slimport ANX7814 transmitter, a
ultra-low power Full-HD (1080p60) transmitter designed for portable device.

The driver was originally created and based from the work of Junhua Xia from
Analogix. This driver is a refactor of the original driver and fixes different
coding style lines, and different errors/warnings reported by checkpatch. Also
there were things that I noticed that we need to change like:

 - Convert the numbered GPIO API to the new descriptor based GPIO API.
 - Review the DT binding
 - Add missing MODULE_DEVICE_TABLE(of, ...);
 - Fix Makefiles and Kconfig to build conditionally.
 - Use SIMPLE_DEV_PM_OPS() instead of the deprecated i2c .suspend and
  .resume callbacks.
 - Move to use managed device resources.
 - Remove dead/unused code.
 - And others ...

Changes since v3:

Nicolas Boichat: 
 - Integrate sp_edid_header_result with sp_check_edid_data
 - Fix loop forever.
 - Use meaningful messages and variable names
 - Replace some 'while' loops and use a for loop.
 - Might be clearer to say >= LINK_6P75G
 - Convert a function to void function because always return 0
 - Remove some magic numbers and refactor sp_tx_pclk_calc
 - Replace sp_read_reg(SP_TX_LINK_BW_SET_REG) for sp_tx_get_link_bw.
 - Mask bits 4:0. Bit 5 has another purpose, and 7:6 are reserved.
 - Use ARRAY_SIZE.
 - Use memset for initialization.
 - Simply condition if (!(c1 & POLLING_EN) || (c & POLLING_ERR))
 - Don not use a temporal variable write the value directly.
 - Fix various typos
 - Return directly PTR_ERR.

Dan Carpenter: 
 - Refactor while loop removing the earlier condition and do while (--c) instead
 - Simplify double negative and fix alignment
 - Remove the superflous casts to u16 and parens
 - Remove debug printks and use ftrace instead.
 - Flip this condition around and pull the code in one indent level.
 - Fix return value 'ret' that should be an int. It causes a signedness bug 
later.
 - Use better style for devm_kzalloc
 - Get rid of AUX_*.  They aren't used much and we could easily use normal 
error codes instead.

Enric Balletbo
 - Fix errors reported by scripts/checkpatch.pl --strict --subjective
 - Remove XTAL_CLK_M10 XTAL_CLK definitions
 - replace ulong for unsigned long
 - remove some magic numbers and refactor sp_tx_enable_audio_output
 - remove some magic numbers and refactor sp_tx_phy_auto_test

Changes since v2 (requested by Daniel Kurtz):
 - clean up the typos, and little nits requested by Dan.
 - move to the drm/bridge directory
 - rename the files, variables, types, etc. to anx78xx
 - plumb through the context struct to all functions that act on the device
 - use proper messaging (dev_ rather than pr_, _dbg/_err rather than _info)

Changes since v1:
 - As requested by Greg, move from staging to a subsystem.

Best regards,

Enric Balletbo i Serra (3):
  of: Add vendor prefix for Analogix Semiconductor, Inc.
  devicetree: Add new ANX7814 SlimPort transmitter binding.
  drm: bridge: anx78xx: Add anx78xx driver support by analogix.

 .../devicetree/bindings/vendor-prefixes.txt|1 +
 .../devicetree/bindings/video/bridge/anx7814.txt   |   22 +
 drivers/gpu/drm/bridge/Kconfig |2 +
 drivers/gpu/drm/bridge/Makefile|1 +
 drivers/gpu/drm/bridge/anx78xx/Kconfig |7 +
 drivers/gpu/drm/bridge/anx78xx/Makefile|4 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx.h   |   41 +
 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c  |  228 ++
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c   | 3148 
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h   |  214 ++
 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h   |  807 +
 11 files changed, 4475 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/video/bridge/anx7814.txt
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Kconfig
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/Makefile
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/anx78xx_main.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.c
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_drv.h
 create mode 100644 drivers/gpu/drm/bridge/anx78xx/slimport_tx_reg.h

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

RE: [PATCH v5 4/7] pinctrl: freescale: imx: allow mux_reg offset zero

[Alonso Adrian]

> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: Friday, September 25, 2015 2:07 PM
> To: Markus Pargmann 
> Cc: Alonso Lazcano Adrian-B38018 ; linux-arm-
> ker...@lists.infradead.org; shawn@linaro.org; linus.wall...@linaro.org;
> lzn...@gmail.com; devicetree@vger.kernel.org; Li Frank-B20596
> ; Garg Nitin-B37173 ;
> Huang Yongcai-B20788 ; linux-
> g...@vger.kernel.org; robh...@kernel.org; ker...@pengutronix.de; Gong
> Yibin-B38343 
> Subject: Re: [PATCH v5 4/7] pinctrl: freescale: imx: allow mux_reg offset zero
> 
> On Fri, Sep 25, 2015 at 12:47:26PM +0200, Markus Pargmann wrote:
> > On Thu, Sep 24, 2015 at 03:54:00PM -0500, Adrian Alonso wrote:
> > > Allow mux_reg offset zero to be a valid pin_id, on imx7d mux_conf
> > > reg offset is zero for iomuxc-lspr controller
> > >
> > > Signed-off-by: Adrian Alonso 
> > > ---
> > > Changes for V2: Resend
> > > Changes for V3: Resend
> > > Changes for V4: Simplify pin_id assigment when ZERO_OFFSET_VALID is
> > > set Changes for V5:
> > > - Drop patch pinctrl: freescale: imx: add ZERO_OFFSET_VALID flag
> > > - Allow mux_reg ZERO OFFSET as pin_id
> > >
> > >  drivers/pinctrl/freescale/pinctrl-imx.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
> > > b/drivers/pinctrl/freescale/pinctrl-imx.c
> > > index b9c6deb..23348d8 100644
> > > --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> > > +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> > > @@ -550,7 +550,7 @@ static int imx_pinctrl_parse_groups(struct
> device_node *np,
> > >   conf_reg = -1;
> > >   }
> > >
> > > - pin_id = mux_reg ? mux_reg / 4 : conf_reg / 4;
> > > + pin_id = (mux_reg != -1) ? mux_reg / 4 : conf_reg / 4;
> >
> > This will break compatibility with imx35 and imx25 pinctrl drivers.
> > They have definitions where mux_reg can be 0x0. See imx35-pinfunc.h
> > and
> > imx25-pinfunc.h:
> >
> > git grep -E "0x0+ 0x.* 0x.* 0x.* 0x.*"
> >
> > This mux_reg behaviour was not described in the DT binding
> > documentation. But it is used by some platforms. So even if you change
> > the pincfunc headers to use "-1", it would break devicetrees compiled
> > with earlier kernel versions.
> 
> Ah, sorry, I'm screwed on the previous review.  So we still need the flag
> ZERO_OFFSET_VALID to convert invalid 0 mux_reg to -1.
> 
> @Adrian,
> 
> Will the following change just work for you?
@Shawn, yes the change will work, do you want me to prepare a new patch series?
> 
> Shawn
> 
> diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c
> b/drivers/pinctrl/freescale/pinctrl-imx.c
> index d7b98ba36825..ae801ba7e226 100644
> --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> @@ -542,6 +542,9 @@ static int imx_pinctrl_parse_groups(struct device_node
> *np,
> struct imx_pin_reg *pin_reg;
> struct imx_pin *pin = &grp->pins[i];
> 
> +   if (!(info->flags & ZERO_OFFSET_VALID) && !mux_reg)
> +   mux_reg = -1;
> +
> if (info->flags & SHARE_MUX_CONF_REG) {
> conf_reg = mux_reg;
> } else {
> @@ -550,7 +553,7 @@ static int imx_pinctrl_parse_groups(struct device_node
> *np,
> conf_reg = -1;
> }
> 
> -   pin_id = mux_reg ? mux_reg / 4 : conf_reg / 4;
> +   pin_id = (mux_reg != -1) ? mux_reg / 4 : conf_reg / 4;
> pin_reg = &info->pin_regs[pin_id];
> pin->pin = pin_id;
> grp->pin_ids[i] = pin_id;

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

Re: [PATCH v3 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC

[Andrew F. Davis]

On 09/25/2015 11:50 AM, Lee Jones wrote:

On Thu, 24 Sep 2015, Andrew F. Davis wrote:


This patch adds support for TPS65912 mfd device. It provides
communication through the I2C and SPI interfaces. It contains
the following components:

  - Regulators
  - GPIO controller

Signed-off-by: Andrew F. Davis 
---
  drivers/mfd/Kconfig  |  24 +++
  drivers/mfd/Makefile |   3 +
  drivers/mfd/tps65912-core.c  | 114 +
  drivers/mfd/tps65912-i2c.c   |  86 ++
  drivers/mfd/tps65912-spi.c   |  85 ++
  include/linux/mfd/tps65912.h | 393 +++
  6 files changed, 705 insertions(+)
  create mode 100644 drivers/mfd/tps65912-core.c
  create mode 100644 drivers/mfd/tps65912-i2c.c
  create mode 100644 drivers/mfd/tps65912-spi.c
  create mode 100644 include/linux/mfd/tps65912.h


[...]


+#define TPS65912_IRQ(_name, _reg, _offset) \
+   [TPS65912_IRQ_ ## _name] = {\
+   .mask = TPS65912_ ## _reg ## _ ## _name,\
+   .reg_offset = _offset,  \
+   }


I told you about this already.

If you want this set to be merged for v4.3 then you'll need commit
b4fe8ba ("regmap: Add generic macro to define regmap_irq") from my
tree.



You asked me to submit this to Mark Brown, I didn't realize you also
wanted me to use the one in your tree. Using yours will make my lines
over 80 chars and so it kind of defeats the purpose but I'll do it
for v4.


[...]


+static struct i2c_driver tps65912_i2c_driver = {
+   .driver = {
+   .name   = "tps65912",
+   .of_match_table = tps65912_i2c_of_match_table,


of_match_ptr()



Why? tps65912_i2c_of_match_table is always compiled in.


[...]


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

Re: [PATCH v5 1/7] pinctrl: freescale: imx: fix system crash if enable two pinctl instances

[Shawn Guo]

On Thu, Sep 24, 2015 at 03:53:57PM -0500, Adrian Alonso wrote:
> From: Robin Gong 
> 
> Fix system chrash caused by groups whose number is smaller than the number
> of groups of the last pinctl instance which is not initialized.
> 
> iMX7D supports two iomux controllers (iomuxc-lpsr and iomuxc) on probing
> the second instance (iomuxc) the chrash below occurs.
> 
> Uncompressing Linux... done, booting the kernel.
> [0.00] Booting Linux on physical CPU 0x0
> [0.00] Linux version 4.2.0-next-20150901-6-gebfa43c 
> (aalonso@bluefly)
> [0.00] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7)
> [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasin 
> instruction cache
> [0.00] Machine model: Freescale i.MX7 SabreSD Board
> [0.661012] [<802a6cb0>] (strcmp) from [<802cc80c>] 
> (imx_dt_node_to_map+0x58/0x208)
> [0.668879] [<802cc80c>] (imx_dt_node_to_map) from [<802cbe24>] 
> (pinctrl_dt_to_map+0x174/0x2b0)
> [0.677654] [<802cbe24>] (pinctrl_dt_to_map) from [<802c8f18>] 
> (pinctrl_get+0x100/0x424)
> [0.685878] [<802c8f18>] (pinctrl_get) from [<802c9510>] 
> (pinctrl_register+0x26c/0x480)
> [0.694104] [<802c9510>] (pinctrl_register) from [<802ccf3c>] 
> (imx_pinctrl_probe+0x580/0x6e8)
> [0.702706] [<802ccf3c>] (imx_pinctrl_probe) from [<80351b58>] 
> (platform_drv_probe+0x44/0xa4)
> [0.711455] [<80351b58>] (platform_drv_probe) from [<803503ec>] 
> (driver_probe_device+0x174/0x2b4)
> [0.720405] [<803503ec>] (driver_probe_device) from [<803505fc>] 
> (__driver_attach+0x8c/0x90)
> [0.728982] [<803505fc>] (__driver_attach) from [<8034e930>] 
> (bus_for_each_dev+0x6c/0xa0)
> [0.737381] [<8034e930>] (bus_for_each_dev) from [<8034fb88>] 
> (bus_add_driver+0x148/0x1f0)
> [0.745804] [<8034fb88>] (bus_add_driver) from [<80350c00>] 
> (driver_register+0x78/0xf8)
> [0.753880] [<80350c00>] (driver_register) from [<800097d0>] 
> (do_one_initcall+0x8c/0x1d4)
> [0.762282] [<800097d0>] (do_one_initcall) from [<80987dac>] 
> (kernel_init_freeable+0x144/0x1e4)
> [0.771061] [<80987dac>] (kernel_init_freeable) from [<806d9c7c>] 
> (kernel_init+0x8/0xe8)
> [0.779285] [<806d9c7c>] (kernel_init) from [<8000f628>] 
> (ret_from_fork+0x14/0x2c)
> [0.786981] Code: e352 e5e32001 1afb e12fff1e (e4d03001)
> 
> Signed-off-by: Robin Gong 
> Signed-off-by: Adrian Alonso 

Acked-by: Shawn Guo 
--
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

Re: [PATCH v5 4/7] pinctrl: freescale: imx: allow mux_reg offset zero

[Shawn Guo]

On Fri, Sep 25, 2015 at 12:47:26PM +0200, Markus Pargmann wrote:
> On Thu, Sep 24, 2015 at 03:54:00PM -0500, Adrian Alonso wrote:
> > Allow mux_reg offset zero to be a valid pin_id, on imx7d
> > mux_conf reg offset is zero for iomuxc-lspr controller
> > 
> > Signed-off-by: Adrian Alonso 
> > ---
> > Changes for V2: Resend
> > Changes for V3: Resend
> > Changes for V4: Simplify pin_id assigment when ZERO_OFFSET_VALID is set
> > Changes for V5:
> > - Drop patch pinctrl: freescale: imx: add ZERO_OFFSET_VALID flag
> > - Allow mux_reg ZERO OFFSET as pin_id
> > 
> >  drivers/pinctrl/freescale/pinctrl-imx.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c 
> > b/drivers/pinctrl/freescale/pinctrl-imx.c
> > index b9c6deb..23348d8 100644
> > --- a/drivers/pinctrl/freescale/pinctrl-imx.c
> > +++ b/drivers/pinctrl/freescale/pinctrl-imx.c
> > @@ -550,7 +550,7 @@ static int imx_pinctrl_parse_groups(struct device_node 
> > *np,
> > conf_reg = -1;
> > }
> >  
> > -   pin_id = mux_reg ? mux_reg / 4 : conf_reg / 4;
> > +   pin_id = (mux_reg != -1) ? mux_reg / 4 : conf_reg / 4;
> 
> This will break compatibility with imx35 and imx25 pinctrl drivers. They
> have definitions where mux_reg can be 0x0. See imx35-pinfunc.h and
> imx25-pinfunc.h:
> 
>   git grep -E "0x0+ 0x.* 0x.* 0x.* 0x.*"
> 
> This mux_reg behaviour was not described in the DT binding
> documentation. But it is used by some platforms. So even if you change
> the pincfunc headers to use "-1", it would break devicetrees compiled
> with earlier kernel versions.

Ah, sorry, I'm screwed on the previous review.  So we still need the
flag ZERO_OFFSET_VALID to convert invalid 0 mux_reg to -1.

@Adrian,

Will the following change just work for you?

Shawn

diff --git a/drivers/pinctrl/freescale/pinctrl-imx.c 
b/drivers/pinctrl/freescale/pinctrl-imx.c
index d7b98ba36825..ae801ba7e226 100644
--- a/drivers/pinctrl/freescale/pinctrl-imx.c
+++ b/drivers/pinctrl/freescale/pinctrl-imx.c
@@ -542,6 +542,9 @@ static int imx_pinctrl_parse_groups(struct device_node *np,
struct imx_pin_reg *pin_reg;
struct imx_pin *pin = &grp->pins[i];
 
+   if (!(info->flags & ZERO_OFFSET_VALID) && !mux_reg)
+   mux_reg = -1;
+
if (info->flags & SHARE_MUX_CONF_REG) {
conf_reg = mux_reg;
} else {
@@ -550,7 +553,7 @@ static int imx_pinctrl_parse_groups(struct device_node *np,
conf_reg = -1;
}
 
-   pin_id = mux_reg ? mux_reg / 4 : conf_reg / 4;
+   pin_id = (mux_reg != -1) ? mux_reg / 4 : conf_reg / 4;
pin_reg = &info->pin_regs[pin_id];
pin->pin = pin_id;
grp->pin_ids[i] = pin_id;

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

Re: [PATCH 09/14] ARM: dts: ifc6410: Add missing pinctrl to gsbi7 uart

[Kevin Hilman]

Hi Srini,

On Fri, Sep 18, 2015 at 5:31 AM, Srinivas Kandagatla
 wrote:
> This patch adds missing 2pin uart pinctrl property to gsbi7 uart on
> IFC6410.
>
> Signed-off-by: Srinivas Kandagatla 

kernelci.org found some new boot failures in -next on 8064[1].  I
bisected it down to this patch, which landed in linux next in the form
of commit d3a578ed4310 ARM: dts: ifc6410: Add missing pinctrl to gsbi7
uart.

Kevin

[1] 
http://kernelci.org/boot/qcom-apq8064-ifc6410/job/next/kernel/next-20150925/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5605083c59b51466d26c3250
--
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

Re: [PATCH 1/2] of: thermal: Fix inconsitency between cooling-*-state and cooling-*-level

[Rob Herring]

On Tue, Sep 8, 2015 at 6:20 AM, Punit Agrawal  wrote:
> The device trees in the kernel as well as the binding description in
> Documentation/devicetree/bindings/cpufreq/cpufreq-dt.txt use the
> cooling-{min,max}-level property.
>
> Fix the inconsistency with the binding description in
> Documentation/devicetree/bindings/thermal/thermal.txt by changing
> cooling-*-state properties to cooling-*-level.
>
> Signed-off-by: Punit Agrawal 
> Cc: Eduardo Valentin 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Ian Campbell 
> Cc: Kumar Gala 

Both patches applied. Thanks.

Rob

> ---
>  Documentation/devicetree/bindings/thermal/thermal.txt | 14 +++---
>  1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/thermal/thermal.txt 
> b/Documentation/devicetree/bindings/thermal/thermal.txt
> index 8a49362..8320186 100644
> --- a/Documentation/devicetree/bindings/thermal/thermal.txt
> +++ b/Documentation/devicetree/bindings/thermal/thermal.txt
> @@ -55,16 +55,16 @@ of heat dissipation). For example a fan's cooling states 
> correspond to
>  the different fan speeds possible. Cooling states are referred to by
>  single unsigned integers, where larger numbers mean greater heat
>  dissipation. The precise set of cooling states associated with a device
> -(as referred to be the cooling-min-state and cooling-max-state
> +(as referred to by the cooling-min-level and cooling-max-level
>  properties) should be defined in a particular device's binding.
>  For more examples of cooling devices, refer to the example sections below.
>
>  Required properties:
> -- cooling-min-state:   An integer indicating the smallest
> +- cooling-min-level:   An integer indicating the smallest
>Type: unsigned   cooling state accepted. Typically 0.
>Size: one cell
>
> -- cooling-max-state:   An integer indicating the largest
> +- cooling-max-level:   An integer indicating the largest
>Type: unsigned   cooling state accepted.
>Size: one cell
>
> @@ -225,8 +225,8 @@ cpus {
> 396000  95
> 198000  85
> >;
> -   cooling-min-state = <0>;
> -   cooling-max-state = <3>;
> +   cooling-min-level = <0>;
> +   cooling-max-level = <3>;
> #cooling-cells = <2>; /* min followed by max */
> };
> ...
> @@ -240,8 +240,8 @@ cpus {
>  */
> fan0: fan@0x48 {
> ...
> -   cooling-min-state = <0>;
> -   cooling-max-state = <9>;
> +   cooling-min-level = <0>;
> +   cooling-max-level = <9>;
> #cooling-cells = <2>; /* min followed by max */
> };
>  };
> --
> 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

Re: [PATCH v2] gpio: mention in DT binding doc that -gpio is deprecated

[Rob Herring]

On Mon, Sep 21, 2015 at 7:57 AM, Javier Martinez Canillas
 wrote:
> The gpiolib supports parsing DT properties of the form -gpio but it
> was only added for compatibility with older DT bindings that got it wrong
> and should not be used in newer bindings.
>
> The commit that added support for this was:
>
> dd34c37aa3e8 ("gpio: of: Allow -gpio suffix for property names")
>
> but didn't update the documentation to explain this so it's been a source
> of confusion. So let's make this clear in the GPIO DT binding doc.
>
> Signed-off-by: Javier Martinez Canillas 

Applied. Thanks.

Rob

>
> ---
>
> Changes in v2:
> - Explain that -gpio is deprecated instead of saying that is
>   supported. Suggested by Alexandre Courbot.
>
>  Documentation/devicetree/bindings/gpio/gpio.txt | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt 
> b/Documentation/devicetree/bindings/gpio/gpio.txt
> index 5788d5cf1252..82d40e2505f6 100644
> --- a/Documentation/devicetree/bindings/gpio/gpio.txt
> +++ b/Documentation/devicetree/bindings/gpio/gpio.txt
> @@ -16,7 +16,9 @@ properties, each containing a 'gpio-list':
>  GPIO properties should be named "[-]gpios", with  being the 
> purpose
>  of this GPIO for the device. While a non-existent  is considered valid
>  for compatibility reasons (resolving to the "gpios" property), it is not 
> allowed
> -for new bindings.
> +for new bindings. Also, GPIO properties named "[-]gpio" are valid and 
> old
> +bindings use it, but are only supported for compatibility reasons and should 
> not
> +be used for newer bindings since it has been deprecated.
>
>  GPIO properties can contain one or more GPIO phandles, but only in 
> exceptional
>  cases should they contain more than one. If your device uses several GPIOs 
> with
> --
> 2.4.3
>
--
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

Re: [PATCH] Documentation: arm: Fix typo in the idle-states bindings examples

[Rob Herring]

On Thu, Sep 24, 2015 at 9:53 AM, Lorenzo Pieralisi
 wrote:
> The idle-states bindings mandate that the entry-method string
> in the idle-states node must be "psci" for ARM v8 64-bit systems,
> but the examples in the bindings report a wrong entry-method string.
> Owing to this typo, some dts in the kernel wrongly defined the
> entry-method property, since they likely cut and pasted the example
> definition without paying attention to the bindings definitions.
>
> This patch fixes the typo in the DT idle states bindings examples and
> respective dts in the kernel so that the bindings and related dts
> files are made compliant.
>
> Signed-off-by: Lorenzo Pieralisi 
> Cc: Howard Chen 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Heiko Stuebner 

Applied. Thanks.

Rob

> ---
>  Documentation/devicetree/bindings/arm/idle-states.txt | 2 +-
>  arch/arm64/boot/dts/mediatek/mt8173.dtsi  | 2 +-
>  arch/arm64/boot/dts/rockchip/rk3368.dtsi  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt 
> b/Documentation/devicetree/bindings/arm/idle-states.txt
> index a8274ea..b8e41c1 100644
> --- a/Documentation/devicetree/bindings/arm/idle-states.txt
> +++ b/Documentation/devicetree/bindings/arm/idle-states.txt
> @@ -497,7 +497,7 @@ cpus {
> };
>
> idle-states {
> -   entry-method = "arm,psci";
> +   entry-method = "psci";
>
> CPU_RETENTION_0_0: cpu-retention-0-0 {
> compatible = "arm,idle-state";
> diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi 
> b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> index d18ee42..06a1564 100644
> --- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> +++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
> @@ -81,7 +81,7 @@
> };
>
> idle-states {
> -   entry-method = "arm,psci";
> +   entry-method = "psci";
>
> CPU_SLEEP_0: cpu-sleep-0 {
> compatible = "arm,idle-state";
> diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi 
> b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> index a712bea..cc093a4 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
> @@ -106,7 +106,7 @@
> };
>
> idle-states {
> -   entry-method = "arm,psci";
> +   entry-method = "psci";
>
> cpu_sleep: cpu-sleep-0 {
> compatible = "arm,idle-state";
> --
> 2.5.1
>
--
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

Re: [PATCH v2 0/2] ASoC: atmel-classd: add driver for Atmel CLASSD

[Mark Brown]

On Thu, Sep 24, 2015 at 01:41:25PM +0800, Songjun Wu wrote:

> Songjun Wu (2):
>   ASoC: atmel-classd: add the Audio Class D Amplifier
>   ASoC: atmel-classd: DT binding for Class D audio amplifier driver

I don't seem to have the second patch with the binding documentation.


signature.asc
Description: Digital signature

Re: [PATCH v3 4/5] regulators: tps65912: Add regulator driver for the TPS65912 PMIC

[Mark Brown]

On Thu, Sep 24, 2015 at 09:52:53AM -0500, Andrew F. Davis wrote:

> +static int tps65912_regulator_probe(struct platform_device *pdev)
> +{
> + struct tps65912 *tps = dev_get_drvdata(pdev->dev.parent);
> + struct regulator_init_data *init_data;
> + const struct tps_info *template;
> + struct regulator_dev *rdev;
> + const struct of_device_id *match;
> + struct regulator_config config = { };
> + int id;
> +
> + match = of_match_device(tps65912_regulator_of_match_table, &pdev->dev);
> + if (!match)
> + return -ENODEV;
> +
> + template = match->data;
> + id = template->id;
> + init_data = of_get_regulator_init_data(&pdev->dev, pdev->dev.of_node,
> +®ulators[id]);

Don't open code this stuff, use the core DT matching in the
regulator_desc instead.

Please also use subject lines mathcing the style for the subsystem.


signature.asc
Description: Digital signature

Re: [PATCH] edac: xgene: Fix possible sprintf overflow issue

[Loc Ho]

Hi,

>
> All 5 applied.
>
> I've merged the last hunk changing xgene_edac_l3_create_debugfs_nodes
> into the second patch which adds the L3 support.


Thanks you... Next I would like to get the ACPI APEI supported. But
unlike x86 which as NMI interface, APM hardware don't support this NMI
interface. In order to make this works, we need an method to trigger
the OS to indicate that the APEI table is available. For this, we are
thinking about writing an separate APEI driver that wires up the IRQ
to trigger the OS. Before we get going with this, I would like to run
by you to see if you have any suggestion?

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

Re: [PATCH 2/3] Documentation: DT: Add binding documentation for NVIDIA ADMA

[Mark Rutland]

On Fri, Sep 25, 2015 at 03:56:39PM +0100, Jon Hunter wrote:
> Add device-tree binding documentation for the Tegra210 Audio DMA
> controller.
> 
> Signed-off-by: Jon Hunter 
> ---
>  .../devicetree/bindings/dma/tegra210-adma.txt  | 47 
> ++
>  1 file changed, 47 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/dma/tegra210-adma.txt
> 
> diff --git a/Documentation/devicetree/bindings/dma/tegra210-adma.txt 
> b/Documentation/devicetree/bindings/dma/tegra210-adma.txt
> new file mode 100644
> index ..af04b3c5a557
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/dma/tegra210-adma.txt
> @@ -0,0 +1,47 @@
> +* NVIDIA Tegra Audio DMA controller
> +
> +Required properties:
> +- compatible: Should be "nvidia,-adma"

Where  can be?

> +- reg: Should contain DMA registers location and length. This should include
> +  all of the per-channel registers.

This is one contiguous bank?

> +- interrupt-parent: Phandle to the interrupt parent controller.
> +- interrupts: Should contain all of the per-channel DMA interrupts.

In which particular order?

> +- clocks: Must contain two entries, one for the power-domain clock and one
> +  for the module clock. See ../clocks/clock-bindings.txt for details.

The example dts and driver rely on clock-names.

Please define the set of clock-names, and define clocks in terms of
clock-names.

> +- dma-channels: Number of DMA channels supported by the controller.
> +- #dma-cells : Must be <0>.

As others have pointed out, this doesn't seem right.

Thanks,
Mark.
--
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

Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags

[Nishanth Menon]

On 09/25/2015 11:15 AM, santosh shilimkar wrote:
> 9/25/2015 9:01 AM, Nishanth Menon wrote:
>> On 09/25/2015 10:18 AM, santosh shilimkar wrote:
>>> On 9/25/2015 7:50 AM, Nishanth Menon wrote:
>> [...]
 But, how about userspace
 needing to know which SoC they are on, without needing to depend on
 board->soc mapping? How do we help resolve that?

>>> Why the user space should care about exact SOC ?
>>
>> examples vary - trivial one is: debug tools like omapconf[1] or testing
>> tools like opentest[2] need some standard way to ensure Linux kernel is
>> functional - trusting the least set of parameters is usually what we
>> would prefer. while building a generic distro such as debian or yocto,
>> one prefers NOT to need to do a package build per SoC/perboard - that
>> never scales. instead, you'd like the same application run on different
>> systems dynamically.
>>
> I guessed omapconf example is coming though Keystone has no such tool

:) That is true - as of now. maynot be the case for future.

> yet ;-). Opentest shouldn't need that info either.

we did debate this on opentest, but we could not implement anything
since we did not have a consistent solution yet.

> I do agree that having a soc along with board is useful in
> longer run to accommodation more boards and variants.
> And only on that merit, I am willing to take these patches.
> 
> Please refresh the series commit messages based on the
> discussion so far and repost. Will pick it up then.
> 
Thanks. I will do so (probably early next week)..


-- 
Regards,
Nishanth Menon
--
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

[PATCH 3/5] ARM: dts: S3C2416: fix cpu compatible value

[Vladimir Zapolskiy]

The change corrects cpu compatible property to a defined one,
see Documentation/devicetree/bindings/arm/cpus.txt

Signed-off-by: Vladimir Zapolskiy 
Cc: Kukjin Kim 
Cc: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/s3c2416.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/s3c2416.dtsi b/arch/arm/boot/dts/s3c2416.dtsi
index a5184ff..80f0075 100644
--- a/arch/arm/boot/dts/s3c2416.dtsi
+++ b/arch/arm/boot/dts/s3c2416.dtsi
@@ -25,7 +25,7 @@
#size-cells = <0>;
 
cpu {
-   compatible = "arm,arm926ejs";
+   compatible = "arm,arm926ej-s";
};
};
 
-- 
2.1.4

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

[PATCH 4/5] ARM: dts: TI-Nspire: fix cpu compatible value

[Vladimir Zapolskiy]

The change corrects cpu compatible property to a defined one,
see Documentation/devicetree/bindings/arm/cpus.txt

Signed-off-by: Vladimir Zapolskiy 
---
 arch/arm/boot/dts/nspire.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/nspire.dtsi b/arch/arm/boot/dts/nspire.dtsi
index 390c91a..ee5a0bb 100644
--- a/arch/arm/boot/dts/nspire.dtsi
+++ b/arch/arm/boot/dts/nspire.dtsi
@@ -16,7 +16,7 @@
 
cpus {
cpu@0 {
-   compatible = "arm,arm926ejs";
+   compatible = "arm,arm926ej-s";
};
};
 
-- 
2.1.4

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

[PATCH 1/5] ARM: dts: i.MX31: fix cpu compatible value

[Vladimir Zapolskiy]

The change corrects cpu compatible property to a defined one,
see Documentation/devicetree/bindings/arm/cpus.txt

Signed-off-by: Vladimir Zapolskiy 
Cc: Shawn Guo 
Cc: Sascha Hauer 
---
 arch/arm/boot/dts/imx31.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx31.dtsi b/arch/arm/boot/dts/imx31.dtsi
index c34f825..5fdb222 100644
--- a/arch/arm/boot/dts/imx31.dtsi
+++ b/arch/arm/boot/dts/imx31.dtsi
@@ -25,7 +25,7 @@
#size-cells = <0>;
 
cpu {
-   compatible = "arm,arm1136";
+   compatible = "arm,arm1136jf-s";
device_type = "cpu";
};
};
-- 
2.1.4

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

[PATCH 2/5] ARM: dts: i.MX35: fix cpu compatible value

[Vladimir Zapolskiy]

The change corrects cpu compatible property to a defined one,
see Documentation/devicetree/bindings/arm/cpus.txt

Signed-off-by: Vladimir Zapolskiy 
Cc: Shawn Guo 
Cc: Sascha Hauer 
---
 arch/arm/boot/dts/imx35.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/imx35.dtsi b/arch/arm/boot/dts/imx35.dtsi
index e6540b5..ed3dc33 100644
--- a/arch/arm/boot/dts/imx35.dtsi
+++ b/arch/arm/boot/dts/imx35.dtsi
@@ -29,7 +29,7 @@
#size-cells = <0>;
 
cpu {
-   compatible = "arm,arm1136";
+   compatible = "arm,arm1136jf-s";
device_type = "cpu";
};
};
-- 
2.1.4

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

[PATCH 5/5] ARM: dts: WM8750: fix cpu compatible value

[Vladimir Zapolskiy]

The change corrects cpu compatible property to a defined one,
see Documentation/devicetree/bindings/arm/cpus.txt

Signed-off-by: Vladimir Zapolskiy 
---
 arch/arm/boot/dts/wm8750.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/wm8750.dtsi b/arch/arm/boot/dts/wm8750.dtsi
index 557a9c2a..46d076d 100644
--- a/arch/arm/boot/dts/wm8750.dtsi
+++ b/arch/arm/boot/dts/wm8750.dtsi
@@ -17,7 +17,7 @@
 
cpu {
device_type = "cpu";
-   compatible = "arm,arm1176ej-s";
+   compatible = "arm,arm1176jzf";
};
};
 
-- 
2.1.4

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

[PATCH 0/5] ARM: dts: fix cpu compatible values

[Vladimir Zapolskiy]

The changeset corrects severeal cpu compatible properties
to defined ones in Documentation/devicetree/bindings/arm/cpus.txt

Vladimir Zapolskiy (5):
  ARM: dts: i.MX31: fix cpu compatible value
  ARM: dts: i.MX35: fix cpu compatible value
  ARM: dts: S3C2416: fix cpu compatible value
  ARM: dts: TI-Nspire: fix cpu compatible value
  ARM: dts: WM8750: fix cpu compatible value

 arch/arm/boot/dts/imx31.dtsi   | 2 +-
 arch/arm/boot/dts/imx35.dtsi   | 2 +-
 arch/arm/boot/dts/nspire.dtsi  | 2 +-
 arch/arm/boot/dts/s3c2416.dtsi | 2 +-
 arch/arm/boot/dts/wm8750.dtsi  | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

-- 
2.1.4

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

Re: [PATCH v5 3/7] ARM: dts: imx: imx7d-sbd add iomuxc-lpsr hoggrp-2 pads

[Shawn Guo]

On Fri, Sep 25, 2015 at 12:49:22PM +0200, Markus Pargmann wrote:
> On Thu, Sep 24, 2015 at 03:53:59PM -0500, Adrian Alonso wrote:
> > Add imx7d-sdb iomuxc-lpsr hoggrp-2 default pads settings
> > 
> > Signed-off-by: Adrian Alonso 
> > ---
> > Changes for V2: Resend
> > Changes for V3: Resend
> > Changes for V4: Resend
> > Changes for V5: Resend
> > 
> >  arch/arm/boot/dts/imx7d-sdb.dts | 15 +++
> >  1 file changed, 15 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/imx7d-sdb.dts 
> > b/arch/arm/boot/dts/imx7d-sdb.dts
> > index 8059458..c8a178c 100644
> > --- a/arch/arm/boot/dts/imx7d-sdb.dts
> > +++ b/arch/arm/boot/dts/imx7d-sdb.dts
> > @@ -419,3 +419,18 @@
> >  
> > };
> >  };
> > +
> > +&iomuxc_lpsr {
> > +   pinctrl-names = "default";
> > +   pinctrl-0 = <&pinctrl_hog_2>;
> > +
> > +   imx7d-sdb {
> > +   pinctrl_hog_2: hoggrp-2 {
> > +   fsl,pins = <
> > +   MX7D_PAD_GPIO1_IO05__GPIO1_IO50x14
> > +   MX7D_PAD_GPIO1_IO07__GPIO1_IO70x59
> > +   MX7D_PAD_GPIO1_IO00__WDOD1_WDOG_B 0x74
> 
> In my opinion this should still be in the pincontrol for the watchdog
> instead of hogging. Also it is not obvious what the GPIOs are for.

+1

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

Re: [PATCH v4 1/2] pinctrl: Add driver for Alphascale asm9260 pinctrl

[Linus Walleij]

On Tue, Sep 8, 2015 at 10:55 PM, Oleksij Rempel  wrote:
> [Me]
>> Why is it necessary for the driver to copy one description of
>> the pin into another?
>
> If i understand it correctly, pinctrl_pin_desc is essential part of
> pinmux framework. Theoretically i should define just statical array of
> this struct, but by this number of pins and functions it hard to keep it
> readable and error free. So i decided to create asm9260_mux_table which
> contains every thing i need. The side effect is higher memory usage
> since i need to create pinctrl_pin_desc on fly.
>
> May be i miss some thing?

I don't see how having code copying data from one data container
to another makes things "more readable and error free". Go for *one*
static definition. Also the memory waste is a total no-no.

Yours,
Linus Walleij
--
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

Re: [PATCH v4 16/22] pinctrl: Probe pinctrl devices on demand

[Linus Walleij]

On Mon, Sep 7, 2015 at 5:23 AM, Tomeu Vizoso  wrote:

> When looking up a pin controller through its OF node, probe it if it
> hasn't already.
>
> The goal is to reduce deferred probes to a minimum, as it makes it very
> cumbersome to find out why a device failed to probe, and can introduce
> very big delays in when a critical device is probed.
>
> Signed-off-by: Tomeu Vizoso 
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None

Acked-by: Linus Walleij 

Yours,
Linus Walleij
--
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

Re: [PATCH v4 06/22] gpio: Probe pinctrl devices on demand

[Linus Walleij]

On Mon, Sep 7, 2015 at 5:23 AM, Tomeu Vizoso  wrote:

Nit: prefix patch with "pinctrl:"

> When looking up a pin controller through its OF node, probe it if it
> hasn't already.
>
> The goal is to reduce deferred probes to a minimum, as it makes it very
> cumbersome to find out why a device failed to probe, and can introduce
> very big delays in when a critical device is probed.
>
> Signed-off-by: Tomeu Vizoso 
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None

Acked-by: Linus Walleij 

Yours,
Linus Walleij
--
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

Re: [PATCH v4 05/22] gpio: Probe GPIO drivers on demand

[Linus Walleij]

On Mon, Sep 7, 2015 at 5:23 AM, Tomeu Vizoso  wrote:

> When looking up a gpiochip through its firmware node, probe it if it
> hasn't already.
>
> The goal is to reduce deferred probes to a minimum, as it makes it very
> cumbersome to find out why a device failed to probe, and can introduce
> very big delays in when a critical device is probed.
>
> Signed-off-by: Tomeu Vizoso 
> ---
>
> Changes in v4: None
> Changes in v3: None
> Changes in v2: None

Acked-by: Linus Walleij 

That is if the whole thing goes in as-is for the GPIO parts.

Yours,
Linus Walleij
--
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

Re: [PATCH v3 2/5] mfd: tps65912: Remove old driver in preparation for new driver

[Lee Jones]

On Thu, 24 Sep 2015, Andrew F. Davis wrote:

> The old tps65912 driver is being replaced, delete old driver.
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  drivers/gpio/Kconfig   |   6 -
>  drivers/gpio/Makefile  |   1 -
>  drivers/gpio/gpio-tps65912.c   | 153 --
>  drivers/mfd/Kconfig|  26 --
>  drivers/mfd/Makefile   |   4 -
>  drivers/mfd/tps65912-core.c| 175 ---
>  drivers/mfd/tps65912-i2c.c | 139 -
>  drivers/mfd/tps65912-irq.c | 217 -
>  drivers/mfd/tps65912-spi.c | 141 -
>  drivers/regulator/Kconfig  |   6 -
>  drivers/regulator/Makefile |   1 -
>  drivers/regulator/tps65912-regulator.c | 541 
> -
>  include/linux/mfd/tps65912.h   | 328 
>  13 files changed, 1738 deletions(-)
>  delete mode 100644 drivers/gpio/gpio-tps65912.c
>  delete mode 100644 drivers/mfd/tps65912-core.c
>  delete mode 100644 drivers/mfd/tps65912-i2c.c
>  delete mode 100644 drivers/mfd/tps65912-irq.c
>  delete mode 100644 drivers/mfd/tps65912-spi.c
>  delete mode 100644 drivers/regulator/tps65912-regulator.c
>  delete mode 100644 include/linux/mfd/tps65912.h

I initially thought it was a bad idea due to bisectability blah blah
blah, but as the next patch adds a completely new incarnation I
thought this point to be moot.

Acked-by: Lee Jones 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Re: [PATCH v3 3/5] mfd: tps65912: Add driver for the TPS65912 PMIC

[Lee Jones]

On Thu, 24 Sep 2015, Andrew F. Davis wrote:

> This patch adds support for TPS65912 mfd device. It provides
> communication through the I2C and SPI interfaces. It contains
> the following components:
> 
>  - Regulators
>  - GPIO controller
> 
> Signed-off-by: Andrew F. Davis 
> ---
>  drivers/mfd/Kconfig  |  24 +++
>  drivers/mfd/Makefile |   3 +
>  drivers/mfd/tps65912-core.c  | 114 +
>  drivers/mfd/tps65912-i2c.c   |  86 ++
>  drivers/mfd/tps65912-spi.c   |  85 ++
>  include/linux/mfd/tps65912.h | 393 
> +++
>  6 files changed, 705 insertions(+)
>  create mode 100644 drivers/mfd/tps65912-core.c
>  create mode 100644 drivers/mfd/tps65912-i2c.c
>  create mode 100644 drivers/mfd/tps65912-spi.c
>  create mode 100644 include/linux/mfd/tps65912.h

[...]

> +#define TPS65912_IRQ(_name, _reg, _offset)   \
> + [TPS65912_IRQ_ ## _name] = {\
> + .mask = TPS65912_ ## _reg ## _ ## _name,\
> + .reg_offset = _offset,  \
> + }

I told you about this already.

If you want this set to be merged for v4.3 then you'll need commit
b4fe8ba ("regmap: Add generic macro to define regmap_irq") from my
tree.

[...]

> +static struct i2c_driver tps65912_i2c_driver = {
> + .driver = {
> + .name   = "tps65912",
> + .of_match_table = tps65912_i2c_of_match_table,

of_match_ptr()

[...]

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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

Re: [PATCH v5 1/7] pinctrl: freescale: imx: fix system crash if enable two pinctl instances

[Linus Walleij]

On Thu, Sep 24, 2015 at 1:53 PM, Adrian Alonso  wrote:

> From: Robin Gong 
>
> Fix system chrash caused by groups whose number is smaller than the number
> of groups of the last pinctl instance which is not initialized.
>
> iMX7D supports two iomux controllers (iomuxc-lpsr and iomuxc) on probing
> the second instance (iomuxc) the chrash below occurs.

Looks like this is not a regression so should not be applied separately
for fixes?

I am waiting for one of the Freescale maintainers to review this, Markus
is raising issues with the DT handling and so the SoC maintainers need
to be involved in this: Shawn and/or Sascha.

Yours,
Linus Walleij
--
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

Re: [PATCH] ARM: dts: Add am335x-bonegreen

[Robert Nelson]

>>
>> Would still work when https://patchwork.kernel.org/patch/6394821/ gets in?
>
> That will still work, but we need to extend the board identification
> to "board-name" + "board-revision", as the Green choose the "A335BNLT"
> board name in the eeprom to remain compatible with older 3.8.x images
> from last year.. (most of the clones i've talked too want to support
> the old image too)...
>
> So with the 1st byte of the board-revision:
> All BeagleBone Black's have: 0x30
> Seeed's using 0x1A (with the potential to increment the A)

I should add, we have an official-ish list at the top of (1), to help
keep track of this...

1: https://github.com/beagleboard/image-builder/blob/master/readme.md

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
--
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

Re: [PATCH] ARM: dts: Add am335x-bonegreen

[Robert Nelson]

On Fri, Sep 25, 2015 at 11:03 AM, Nishanth Menon  wrote:
> On 09/25/2015 10:10 AM, Robert Nelson wrote:
>> SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) 
>> minus
>> the HDMI port and addition of two Grove connectors (i2c2 and usart2).
>>
>> This board can be identified by the 1A value after A335BNLT (BBB) in the 
>> at24 eeprom:
>> 1A: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]
>>
>> http://beagleboard.org/green
>> http://www.seeedstudio.com/wiki/Beaglebone_green
>>
>> Signed-off-by: Robert Nelson 
>> CC: Tony Lindgren 
>> CC: Jason Kridner 
>> ---
>>  arch/arm/boot/dts/Makefile |  1 +
>>  arch/arm/boot/dts/am335x-bonegreen.dts | 53 
>> ++
>>  2 files changed, 54 insertions(+)
>>  create mode 100644 arch/arm/boot/dts/am335x-bonegreen.dts
>>
>> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
>> index 233159d..e45d771 100644
>> --- a/arch/arm/boot/dts/Makefile
>> +++ b/arch/arm/boot/dts/Makefile
>> @@ -446,6 +446,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
>>   am335x-base0033.dtb \
>>   am335x-bone.dtb \
>>   am335x-boneblack.dtb \
>> + am335x-bonegreen.dtb \
>>   am335x-sl50.dtb \
>>   am335x-evm.dtb \
>>   am335x-evmsk.dtb \
>> diff --git a/arch/arm/boot/dts/am335x-bonegreen.dts 
>> b/arch/arm/boot/dts/am335x-bonegreen.dts
>> new file mode 100644
>> index 000..0f65bda
>> --- /dev/null
>> +++ b/arch/arm/boot/dts/am335x-bonegreen.dts
>> @@ -0,0 +1,53 @@
>> +/*
>> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>> + *
>> + * 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.
>> + */
>> +/dts-v1/;
>> +
>> +#include "am33xx.dtsi"
>> +#include "am335x-bone-common.dtsi"
>> +
>> +/ {
>> + model = "TI AM335x BeagleBone Green";
>> + compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", 
>> "ti,am335x-bone", "ti,am33xx";
>> +};
>> +
>> +&ldo3_reg {
>> + regulator-min-microvolt = <180>;
>> + regulator-max-microvolt = <180>;
>> + regulator-always-on;
>> +};
>> +
>> +&mmc1 {
>> + vmmc-supply = <&vmmcsd_fixed>;
>> +};
>> +
>> +&mmc2 {
>> + vmmc-supply = <&vmmcsd_fixed>;
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&emmc_pins>;
>> + bus-width = <8>;
>> + status = "okay";
>> +};
>> +
>> +&am33xx_pinmux {
>> + uart2_pins: uart2_pins {
>> + pinctrl-single,pins = <
>> + 0x150 (PIN_INPUT | MUX_MODE1)   /* spi0_sclk.uart2_rxd 
>> */
>> + 0x154 (PIN_OUTPUT | MUX_MODE1)  /* spi0_d0.uart2_txd */
>> + >;
>> + };
>> +};
>> +
>> +&uart2 {
>> + pinctrl-names = "default";
>> + pinctrl-0 = <&uart2_pins>;
>> + status = "okay";
>> +};
>> +
>> +&rtc {
>> + system-power-controller;
>> +};
>>
>
>
> Would still work when https://patchwork.kernel.org/patch/6394821/ gets in?

That will still work, but we need to extend the board identification
to "board-name" + "board-revision", as the Green choose the "A335BNLT"
board name in the eeprom to remain compatible with older 3.8.x images
from last year.. (most of the clones i've talked too want to support
the old image too)...

So with the 1st byte of the board-revision:
All BeagleBone Black's have: 0x30
Seeed's using 0x1A (with the potential to increment the A)

Regards,

-- 
Robert Nelson
https://rcn-ee.com/
--
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

Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags

[santosh shilimkar]

9/25/2015 9:01 AM, Nishanth Menon wrote:

On 09/25/2015 10:18 AM, santosh shilimkar wrote:

On 9/25/2015 7:50 AM, Nishanth Menon wrote:

[...]

But, how about userspace
needing to know which SoC they are on, without needing to depend on
board->soc mapping? How do we help resolve that?


Why the user space should care about exact SOC ?


examples vary - trivial one is: debug tools like omapconf[1] or testing
tools like opentest[2] need some standard way to ensure Linux kernel is
functional - trusting the least set of parameters is usually what we
would prefer. while building a generic distro such as debian or yocto,
one prefers NOT to need to do a package build per SoC/perboard - that
never scales. instead, you'd like the same application run on different
systems dynamically.


I guessed omapconf example is coming though Keystone has no such tool
yet ;-). Opentest shouldn't need that info either.

I do agree that having a soc along with board is useful in
longer run to accommodation more boards and variants.
And only on that merit, I am willing to take these patches.

Please refresh the series commit messages based on the
discussion so far and repost. Will pick it up then.

Regards,
Santosh
--
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

Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags

[Nishanth Menon]

On 09/25/2015 10:18 AM, santosh shilimkar wrote:
> On 9/25/2015 7:50 AM, Nishanth Menon wrote:
[...]
>> But, how about userspace
>> needing to know which SoC they are on, without needing to depend on
>> board->soc mapping? How do we help resolve that?
>>
> Why the user space should care about exact SOC ?

examples vary - trivial one is: debug tools like omapconf[1] or testing
tools like opentest[2] need some standard way to ensure Linux kernel is
functional - trusting the least set of parameters is usually what we
would prefer. while building a generic distro such as debian or yocto,
one prefers NOT to need to do a package build per SoC/perboard - that
never scales. instead, you'd like the same application run on different
systems dynamically.


[1] https://github.com/omapconf/omapconf
[2] http://arago-project.org/wiki/index.php/Opentest
-- 
Regards,
Nishanth Menon
--
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

Re: [PATCH] ARM: dts: Add am335x-bonegreen

[Nishanth Menon]

On 09/25/2015 10:10 AM, Robert Nelson wrote:
> SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) 
> minus
> the HDMI port and addition of two Grove connectors (i2c2 and usart2).
> 
> This board can be identified by the 1A value after A335BNLT (BBB) in the at24 
> eeprom:
> 1A: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]
> 
> http://beagleboard.org/green
> http://www.seeedstudio.com/wiki/Beaglebone_green
> 
> Signed-off-by: Robert Nelson 
> CC: Tony Lindgren 
> CC: Jason Kridner 
> ---
>  arch/arm/boot/dts/Makefile |  1 +
>  arch/arm/boot/dts/am335x-bonegreen.dts | 53 
> ++
>  2 files changed, 54 insertions(+)
>  create mode 100644 arch/arm/boot/dts/am335x-bonegreen.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 233159d..e45d771 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -446,6 +446,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
>   am335x-base0033.dtb \
>   am335x-bone.dtb \
>   am335x-boneblack.dtb \
> + am335x-bonegreen.dtb \
>   am335x-sl50.dtb \
>   am335x-evm.dtb \
>   am335x-evmsk.dtb \
> diff --git a/arch/arm/boot/dts/am335x-bonegreen.dts 
> b/arch/arm/boot/dts/am335x-bonegreen.dts
> new file mode 100644
> index 000..0f65bda
> --- /dev/null
> +++ b/arch/arm/boot/dts/am335x-bonegreen.dts
> @@ -0,0 +1,53 @@
> +/*
> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
> + *
> + * 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.
> + */
> +/dts-v1/;
> +
> +#include "am33xx.dtsi"
> +#include "am335x-bone-common.dtsi"
> +
> +/ {
> + model = "TI AM335x BeagleBone Green";
> + compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", 
> "ti,am335x-bone", "ti,am33xx";
> +};
> +
> +&ldo3_reg {
> + regulator-min-microvolt = <180>;
> + regulator-max-microvolt = <180>;
> + regulator-always-on;
> +};
> +
> +&mmc1 {
> + vmmc-supply = <&vmmcsd_fixed>;
> +};
> +
> +&mmc2 {
> + vmmc-supply = <&vmmcsd_fixed>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&emmc_pins>;
> + bus-width = <8>;
> + status = "okay";
> +};
> +
> +&am33xx_pinmux {
> + uart2_pins: uart2_pins {
> + pinctrl-single,pins = <
> + 0x150 (PIN_INPUT | MUX_MODE1)   /* spi0_sclk.uart2_rxd 
> */
> + 0x154 (PIN_OUTPUT | MUX_MODE1)  /* spi0_d0.uart2_txd */
> + >;
> + };
> +};
> +
> +&uart2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart2_pins>;
> + status = "okay";
> +};
> +
> +&rtc {
> + system-power-controller;
> +};
> 


Would still work when https://patchwork.kernel.org/patch/6394821/ gets in?


-- 
Regards,
Nishanth Menon
--
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

[PATCH v7 12/15] power: bq24257: Allow input current limit sysfs access

[Andreas Dannenberg]

This patch allows reading and writing of the input current limit through
the power supply's input_current_limit sysfs property. This allows
userspace to see what charger was detected (if the D+/D- USB signal-
based charger type detection is enabled) and to re-configure the maximum
current drawn from the external supply at runtime based on system-level
knowledge or user input. Note that upon charger disconnection and
re-connection the limit configured through firmware becomes active again
(or the D+/D- USB signal-based charger detection will be run again).

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 85 ++---
 1 file changed, 79 insertions(+), 6 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 2a76009..73fcf89 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -267,6 +267,47 @@ enum bq24257_fault {
FAULT_INPUT_LDO_LOW,
 };
 
+static int bq24257_get_input_current_limit(struct bq24257_device *bq,
+  union power_supply_propval *val)
+{
+   int ret;
+
+   ret = bq24257_field_read(bq, F_IILIMIT);
+   if (ret < 0)
+   return ret;
+
+   /*
+* The "External ILIM" and "Production & Test" modes are not exposed
+* through this driver and not being covered by the lookup table.
+* Should such a mode have become active let's return an error rather
+* than exceeding the bounds of the lookup table and returning
+* garbage.
+*/
+   if (ret >= BQ24257_IILIMIT_MAP_SIZE)
+   return -ENODATA;
+
+   val->intval = bq24257_iilimit_map[ret];
+
+   return 0;
+}
+
+static int bq24257_set_input_current_limit(struct bq24257_device *bq,
+   const union power_supply_propval *val)
+{
+   /*
+* Address the case where the user manually sets an input current limit
+* while the charger auto-detection mechanism is is active. In this
+* case we want to abort and go straight to the user-specified value.
+*/
+   if (bq->iilimit_autoset_enable)
+   cancel_delayed_work_sync(&bq->iilimit_setup_work);
+
+   return bq24257_field_write(bq, F_IILIMIT,
+  bq24257_find_idx(val->intval,
+   bq24257_iilimit_map,
+   BQ24257_IILIMIT_MAP_SIZE));
+}
+
 static int bq24257_power_supply_get_property(struct power_supply *psy,
 enum power_supply_property psp,
 union power_supply_propval *val)
@@ -351,6 +392,9 @@ static int bq24257_power_supply_get_property(struct 
power_supply *psy,
val->intval = bq24257_iterm_map[bq->init_data.iterm];
break;
 
+   case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+   return bq24257_get_input_current_limit(bq, val);
+
default:
return -EINVAL;
}
@@ -358,6 +402,31 @@ static int bq24257_power_supply_get_property(struct 
power_supply *psy,
return 0;
 }
 
+static int bq24257_power_supply_set_property(struct power_supply *psy,
+   enum power_supply_property prop,
+   const union power_supply_propval *val)
+{
+   struct bq24257_device *bq = power_supply_get_drvdata(psy);
+
+   switch (prop) {
+   case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+   return bq24257_set_input_current_limit(bq, val);
+   default:
+   return -EINVAL;
+   }
+}
+
+static int bq24257_power_supply_property_is_writeable(struct power_supply *psy,
+   enum power_supply_property psp)
+{
+   switch (psp) {
+   case POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT:
+   return true;
+   default:
+   return false;
+   }
+}
+
 static int bq24257_get_chip_state(struct bq24257_device *bq,
  struct bq24257_state *state)
 {
@@ -559,13 +628,14 @@ static void bq24257_handle_state_change(struct 
bq24257_device *bq,
ret = bq24257_field_write(bq, F_DPDM_EN, 1);
if (ret < 0)
goto error;
-
-   /* reset input current limit */
-   ret = bq24257_field_write(bq, F_IILIMIT,
- bq->init_data.iilimit);
-   if (ret < 0)
-   goto error;
}
+   /*
+* When power is removed always return to the default input
+* current limit as configured during probe.
+*/
+   ret = bq24257_field_write(bq, F_IILIMIT, bq->init_data.iilim

[PATCH v7 03/15] power: bq24257: Streamline input current limit setup

[Andreas Dannenberg]

The maximum amount of input current the charger should draw is dependent
on the power supply and should only be (re-)configured when the power
supply gets connected and disconnected. However the driver was also
lowering the bq24257's input current limit setting to 500mA when the
battery was removed and restored the previous setting according to the
power supply capabilities when the battery was reconnected although
these events are not impacting the amount of power that can be drawn
from the supply. Furthermore, a re-configuration of the input current
limit to 500mA when the battery gets disconnected is actually dangerous
if the limit was set higher previously and the system draws more than
500mA in which case the system voltage would be reduced in order to
maintain 500mA which could result in the system getting too low of a
supply to maintain operation. Last but not least the mechanism itself
used for battery re-connection detection did not work in corner cases
such as when the device's input current loop becomes active and the
bq24257 device clears its battery fault error resulting in incorrectly
reporting that the battery got reconnected.

This patches removes the impact the battery removal/insertion has on the
input current limit configured for the bq24257 and simplifies the
associated handler routine.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 29 +++--
 1 file changed, 11 insertions(+), 18 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 69b53d0..d2d077c 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -448,14 +448,13 @@ static void bq24257_handle_state_change(struct 
bq24257_device *bq,
 {
int ret;
struct bq24257_state old_state;
-   bool reset_iilimit = false;
-   bool config_iilimit = false;
 
mutex_lock(&bq->lock);
old_state = bq->state;
mutex_unlock(&bq->lock);
 
-   if (!new_state->power_good) {/* power removed */
+   if (!new_state->power_good) {
+   dev_dbg(bq->dev, "Power removed\n");
cancel_delayed_work_sync(&bq->iilimit_setup_work);
 
/* activate D+/D- port detection algorithm */
@@ -463,26 +462,20 @@ static void bq24257_handle_state_change(struct 
bq24257_device *bq,
if (ret < 0)
goto error;
 
-   reset_iilimit = true;
-   } else if (!old_state.power_good) { /* power inserted */
-   config_iilimit = true;
-   } else if (new_state->fault == FAULT_NO_BAT) { /* battery removed */
-   cancel_delayed_work_sync(&bq->iilimit_setup_work);
-
-   reset_iilimit = true;
-   } else if (old_state.fault == FAULT_NO_BAT) {/* battery connected */
-   config_iilimit = true;
-   } else if (new_state->fault == FAULT_TIMER) { /* safety timer expired */
-   dev_err(bq->dev, "Safety timer expired! Battery dead?\n");
-   }
-
-   if (reset_iilimit) {
+   /* reset input current limit */
ret = bq24257_field_write(bq, F_IILIMIT, IILIMIT_500);
if (ret < 0)
goto error;
-   } else if (config_iilimit) {
+   } else if (!old_state.power_good) {
+   dev_dbg(bq->dev, "Power inserted\n");
+
+   /* configure input current limit */
schedule_delayed_work(&bq->iilimit_setup_work,
  msecs_to_jiffies(BQ24257_ILIM_SET_DELAY));
+   } else if (new_state->fault == FAULT_NO_BAT) {
+   dev_warn(bq->dev, "Battery removed\n");
+   } else if (new_state->fault == FAULT_TIMER) {
+   dev_err(bq->dev, "Safety timer expired! Battery dead?\n");
}
 
return;
-- 
1.9.1

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

[PATCH v7 08/15] power: bq24257: Allow manual setting of input current limit

[Andreas Dannenberg]

A new optional device property called "ti,current-limit" is introduced
to allow disabling the D+/D- USB signal-based charger type auto-
detection algorithm used to set the input current limit and instead to
use a fixed input current limit.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 93 +
 1 file changed, 75 insertions(+), 18 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 93f7582..7bbff80 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -77,6 +77,7 @@ struct bq24257_init_data {
u8 ichg;/* charge current  */
u8 vbat;/* regulation voltage  */
u8 iterm;   /* termination current */
+   u8 iilimit; /* input current limit */
 };
 
 struct bq24257_state {
@@ -103,6 +104,8 @@ struct bq24257_device {
struct bq24257_state state;
 
struct mutex lock; /* protect state data */
+
+   bool iilimit_autoset_enable;
 };
 
 static bool bq24257_is_volatile_reg(struct device *dev, unsigned int reg)
@@ -191,6 +194,12 @@ static const u32 bq24257_iterm_map[] = {
 
 #define BQ24257_ITERM_MAP_SIZE ARRAY_SIZE(bq24257_iterm_map)
 
+static const u32 bq24257_iilimit_map[] = {
+   10, 15, 50, 90, 150, 200
+};
+
+#define BQ24257_IILIMIT_MAP_SIZE   ARRAY_SIZE(bq24257_iilimit_map)
+
 static int bq24257_field_read(struct bq24257_device *bq,
  enum bq24257_fields field_id)
 {
@@ -480,24 +489,32 @@ static void bq24257_handle_state_change(struct 
bq24257_device *bq,
old_state = bq->state;
mutex_unlock(&bq->lock);
 
+   /*
+* Handle BQ2425x state changes observing whether the D+/D- based input
+* current limit autoset functionality is enabled.
+*/
if (!new_state->power_good) {
dev_dbg(bq->dev, "Power removed\n");
-   cancel_delayed_work_sync(&bq->iilimit_setup_work);
-
-   /* activate D+/D- port detection algorithm */
-   ret = bq24257_field_write(bq, F_DPDM_EN, 1);
-   if (ret < 0)
-   goto error;
-
-   /* reset input current limit */
-   ret = bq24257_field_write(bq, F_IILIMIT, IILIMIT_500);
-   if (ret < 0)
-   goto error;
+   if (bq->iilimit_autoset_enable) {
+   cancel_delayed_work_sync(&bq->iilimit_setup_work);
+
+   /* activate D+/D- port detection algorithm */
+   ret = bq24257_field_write(bq, F_DPDM_EN, 1);
+   if (ret < 0)
+   goto error;
+
+   /* reset input current limit */
+   ret = bq24257_field_write(bq, F_IILIMIT,
+ bq->init_data.iilimit);
+   if (ret < 0)
+   goto error;
+   }
} else if (!old_state.power_good) {
dev_dbg(bq->dev, "Power inserted\n");
 
-   /* configure input current limit */
-   schedule_delayed_work(&bq->iilimit_setup_work,
+   if (bq->iilimit_autoset_enable)
+   /* configure input current limit */
+   schedule_delayed_work(&bq->iilimit_setup_work,
  msecs_to_jiffies(BQ24257_ILIM_SET_DELAY));
} else if (new_state->fault == FAULT_NO_BAT) {
dev_warn(bq->dev, "Battery removed\n");
@@ -577,7 +594,16 @@ static int bq24257_hw_init(struct bq24257_device *bq)
bq->state = state;
mutex_unlock(&bq->lock);
 
-   if (!state.power_good)
+   if (!bq->iilimit_autoset_enable) {
+   dev_dbg(bq->dev, "manually setting iilimit = %u\n",
+   bq->init_data.iilimit);
+
+   /* program fixed input current limit */
+   ret = bq24257_field_write(bq, F_IILIMIT,
+ bq->init_data.iilimit);
+   if (ret < 0)
+   return ret;
+   } else if (!state.power_good)
/* activate D+/D- detection algorithm */
ret = bq24257_field_write(bq, F_DPDM_EN, 1);
else if (state.fault != FAULT_NO_BAT)
@@ -641,6 +667,7 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
int ret;
u32 property;
 
+   /* Required properties */
ret = device_property_read_u32(bq->dev, "ti,charge-current", &property);
if (ret < 0)
return ret;
@@ -664,6 +691,24 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
bq->init_data.iterm = bq24257_find_idx(property, bq24257_iterm_map,
   BQ24257_ITERM_MAP_SIZE);
 
+   /* Optional properties. If not provided use reasonable default. *

[PATCH v7 06/15] power: bq24257: Add basic support for bq24250/bq24251

[Andreas Dannenberg]

This patch adds basic support for bq24250 and bq24251 which are very
similar to the bq24257 the driver was originally written for. Basic
support means the ability to select a device through Kconfig, DT and
ACPI, an instance variable allowing to check which chip is active, and
the reporting back of the selected device through the model_name power
supply sysfs property.

This patch by itself is not sufficient to actually use those two added
devices in a real-world setting due to some feature differences which
are addressed by other patches in this series.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/Kconfig   |  5 ++--
 drivers/power/bq24257_charger.c | 52 ++---
 2 files changed, 52 insertions(+), 5 deletions(-)

diff --git a/drivers/power/Kconfig b/drivers/power/Kconfig
index eeb5776..9e68853 100644
--- a/drivers/power/Kconfig
+++ b/drivers/power/Kconfig
@@ -409,12 +409,13 @@ config CHARGER_BQ24190
  Say Y to enable support for the TI BQ24190 battery charger.
 
 config CHARGER_BQ24257
-   tristate "TI BQ24257 battery charger driver"
+   tristate "TI BQ24250/24251/24257 battery charger driver"
depends on I2C
depends on GPIOLIB || COMPILE_TEST
depends on REGMAP_I2C
help
- Say Y to enable support for the TI BQ24257 battery charger.
+ Say Y to enable support for the TI BQ24250, BQ24251, and BQ24257 
battery
+ chargers.
 
 config CHARGER_BQ24735
tristate "TI BQ24735 battery charger support"
diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 060f754..b0c8533 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -13,6 +13,10 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
  *
+ * Datasheets:
+ * http://www.ti.com/product/bq24250
+ * http://www.ti.com/product/bq24251
+ * http://www.ti.com/product/bq24257
  */
 
 #include 
@@ -40,6 +44,22 @@
 
 #define BQ24257_ILIM_SET_DELAY 1000/* msec */
 
+/*
+ * When adding support for new devices make sure that enum bq2425x_chip and
+ * bq2425x_chip_name[] always stay in sync!
+ */
+enum bq2425x_chip {
+   BQ24250,
+   BQ24251,
+   BQ24257,
+};
+
+static const char *const bq2425x_chip_name[] = {
+   "bq24250",
+   "bq24251",
+   "bq24257",
+};
+
 enum bq24257_fields {
F_WD_FAULT, F_WD_EN, F_STAT, F_FAULT,   /* REG 1 */
F_RESET, F_IILIMIT, F_EN_STAT, F_EN_TERM, F_CE, F_HZ_MODE,  /* REG 2 */
@@ -70,6 +90,8 @@ struct bq24257_device {
struct device *dev;
struct power_supply *charger;
 
+   enum bq2425x_chip chip;
+
struct regmap *rmap;
struct regmap_field *rmap_fields[F_MAX_FIELDS];
 
@@ -248,6 +270,10 @@ static int bq24257_power_supply_get_property(struct 
power_supply *psy,
val->strval = BQ24257_MANUFACTURER;
break;
 
+   case POWER_SUPPLY_PROP_MODEL_NAME:
+   val->strval = bq2425x_chip_name[bq->chip];
+   break;
+
case POWER_SUPPLY_PROP_ONLINE:
val->intval = state.power_good;
break;
@@ -561,6 +587,7 @@ static int bq24257_hw_init(struct bq24257_device *bq)
 
 static enum power_supply_property bq24257_power_supply_props[] = {
POWER_SUPPLY_PROP_MANUFACTURER,
+   POWER_SUPPLY_PROP_MODEL_NAME,
POWER_SUPPLY_PROP_STATUS,
POWER_SUPPLY_PROP_ONLINE,
POWER_SUPPLY_PROP_HEALTH,
@@ -644,6 +671,7 @@ static int bq24257_probe(struct i2c_client *client,
 {
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
struct device *dev = &client->dev;
+   const struct acpi_device_id *acpi_id;
struct bq24257_device *bq;
int ret;
int i;
@@ -660,6 +688,18 @@ static int bq24257_probe(struct i2c_client *client,
bq->client = client;
bq->dev = dev;
 
+   if (ACPI_HANDLE(dev)) {
+   acpi_id = acpi_match_device(dev->driver->acpi_match_table,
+   &client->dev);
+   if (!acpi_id) {
+   dev_err(dev, "Failed to match ACPI device\n");
+   return -ENODEV;
+   }
+   bq->chip = (enum bq2425x_chip)acpi_id->driver_data;
+   } else {
+   bq->chip = (enum bq2425x_chip)id->driver_data;
+   }
+
mutex_init(&bq->lock);
 
bq->rmap = devm_regmap_init_i2c(client, &bq24257_regmap_config);
@@ -722,7 +762,7 @@ static int bq24257_probe(struct i2c_client *client,
bq24257_irq_handler_thread,
IRQF_TRIGGER_FALLING |
IRQF_TRIGGER_RISING | IRQF_ONESHOT,
-   "bq24257", bq);
+   bq2425x_chip_name[bq->chip], bq);
   

[PATCH v7 13/15] power: bq24257: Add various device-specific sysfs properties

[Andreas Dannenberg]

This patch adds support for enabling/disabling optional device specific
features through sysfs properties at runtime.

* High-impedance mode enable/disable
* Sysoff enable/disable

Refer to the respective device datasheets for more information:

http://www.ti.com/product/bq24250
http://www.ti.com/product/bq24251
http://www.ti.com/product/bq24257

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 53 +
 1 file changed, 53 insertions(+)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 73fcf89..19a0962 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -791,12 +791,65 @@ static ssize_t bq24257_show_in_dpm_voltage(struct device 
*dev,
 bq24257_vindpm_map[bq->init_data.vindpm]);
 }
 
+static ssize_t bq24257_sysfs_show_enable(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct power_supply *psy = dev_get_drvdata(dev);
+   struct bq24257_device *bq = power_supply_get_drvdata(psy);
+   int ret;
+
+   if (strcmp(attr->attr.name, "high_impedance_enable") == 0)
+   ret = bq24257_field_read(bq, F_HZ_MODE);
+   else if (strcmp(attr->attr.name, "sysoff_enable") == 0)
+   ret = bq24257_field_read(bq, F_SYSOFF);
+   else
+   return -EINVAL;
+
+   if (ret < 0)
+   return ret;
+
+   return scnprintf(buf, PAGE_SIZE, "%d\n", ret);
+}
+
+static ssize_t bq24257_sysfs_set_enable(struct device *dev,
+   struct device_attribute *attr,
+   const char *buf,
+   size_t count)
+{
+   struct power_supply *psy = dev_get_drvdata(dev);
+   struct bq24257_device *bq = power_supply_get_drvdata(psy);
+   long val;
+   int ret;
+
+   if (kstrtol(buf, 10, &val) < 0)
+   return -EINVAL;
+
+   if (strcmp(attr->attr.name, "high_impedance_enable") == 0)
+   ret = bq24257_field_write(bq, F_HZ_MODE, (bool)val);
+   else if (strcmp(attr->attr.name, "sysoff_enable") == 0)
+   ret = bq24257_field_write(bq, F_SYSOFF, (bool)val);
+   else
+   return -EINVAL;
+
+   if (ret < 0)
+   return ret;
+
+   return count;
+}
+
 static DEVICE_ATTR(ovp_voltage, S_IRUGO, bq24257_show_ovp_voltage, NULL);
 static DEVICE_ATTR(in_dpm_voltage, S_IRUGO, bq24257_show_in_dpm_voltage, NULL);
+static DEVICE_ATTR(high_impedance_enable, S_IWUSR | S_IRUGO,
+  bq24257_sysfs_show_enable, bq24257_sysfs_set_enable);
+static DEVICE_ATTR(sysoff_enable, S_IWUSR | S_IRUGO,
+  bq24257_sysfs_show_enable, bq24257_sysfs_set_enable);
 
 static struct attribute *bq24257_charger_attr[] = {
&dev_attr_ovp_voltage.attr,
&dev_attr_in_dpm_voltage.attr,
+   &dev_attr_high_impedance_enable.attr,
+   &dev_attr_sysoff_enable.attr,
NULL,
 };
 
-- 
1.9.1

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

[PATCH v7 14/15] power: bq24257: Add platform data based initialization

[Andreas Dannenberg]

The patch adds a way to setup and initialize the device through the use
of platform data with configuration options equivalent to when using
device firmware (DT or ACPI) for systems where this is not available.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c   | 39 +--
 include/linux/power/bq24257_charger.h | 25 ++
 2 files changed, 62 insertions(+), 2 deletions(-)
 create mode 100644 include/linux/power/bq24257_charger.h

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 19a0962..3b1a3b6 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -27,10 +27,13 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
 
+#include 
+
 #define BQ24257_REG_1  0x00
 #define BQ24257_REG_2  0x01
 #define BQ24257_REG_3  0x02
@@ -885,6 +888,36 @@ static void bq24257_pg_gpio_probe(struct bq24257_device 
*bq)
dev_dbg(bq->dev, "probed PG pin = %d\n", desc_to_gpio(bq->pg));
 }
 
+static void bq24257_pdata_probe(struct bq24257_device *bq,
+   struct bq24257_platform_data *pdata)
+{
+   bq->init_data.ichg = bq24257_find_idx(pdata->ichg,
+ bq24257_ichg_map,
+ BQ24257_ICHG_MAP_SIZE);
+
+   bq->init_data.vbat = bq24257_find_idx(pdata->vbat,
+ bq24257_vbat_map,
+ BQ24257_VBAT_MAP_SIZE);
+
+   bq->init_data.iterm = bq24257_find_idx(pdata->iterm,
+  bq24257_iterm_map,
+  BQ24257_ITERM_MAP_SIZE);
+
+   bq->init_data.iilimit = bq24257_find_idx(pdata->iilimit,
+bq24257_iilimit_map,
+BQ24257_IILIMIT_MAP_SIZE);
+
+   bq->init_data.vovp = bq24257_find_idx(pdata->vovp,
+ bq24257_vovp_map,
+ BQ24257_VOVP_MAP_SIZE);
+
+   bq->init_data.vindpm = bq24257_find_idx(pdata->vindpm,
+   bq24257_vindpm_map,
+   BQ24257_VINDPM_MAP_SIZE);
+
+   bq->iilimit_autoset_enable = pdata->iilimit_autoset_enable;
+}
+
 static int bq24257_fw_probe(struct bq24257_device *bq)
 {
int ret;
@@ -960,6 +993,7 @@ static int bq24257_probe(struct i2c_client *client,
struct i2c_adapter *adapter = to_i2c_adapter(client->dev.parent);
struct device *dev = &client->dev;
const struct acpi_device_id *acpi_id;
+   struct bq24257_platform_data *pdata = client->dev.platform_data;
struct bq24257_device *bq;
int ret;
int i;
@@ -1009,14 +1043,15 @@ static int bq24257_probe(struct i2c_client *client,
 
i2c_set_clientdata(client, bq);
 
-   if (!dev->platform_data) {
+   if (!pdata) {
ret = bq24257_fw_probe(bq);
if (ret < 0) {
dev_err(dev, "Cannot read device properties.\n");
return ret;
}
} else {
-   return -ENODEV;
+   dev_dbg(dev, "init using platform data\n");
+   bq24257_pdata_probe(bq, pdata);
}
 
/*
diff --git a/include/linux/power/bq24257_charger.h 
b/include/linux/power/bq24257_charger.h
new file mode 100644
index 000..c131c5d
--- /dev/null
+++ b/include/linux/power/bq24257_charger.h
@@ -0,0 +1,25 @@
+/*
+ * Platform data for the TI bq24257 battery charger driver.
+ *
+ * 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.
+ */
+
+#ifndef _BQ24257_CHARGER_H_
+#define _BQ24257_CHARGER_H_
+
+#include 
+#include 
+
+struct bq24257_platform_data {
+   u32 ichg;  /* charge current (uA) */
+   u32 vbat;  /* regulation voltage (uV) */
+   u32 iterm;/* termination current (uA) */
+   u32 iilimit;  /* input current limit (uA) */
+   u32 vovp; /* over voltage protection voltage (uV) */
+   u32 vindpm;  /* VDMP input threshold voltage (uV) */
+   bool iilimit_autoset_enable;/* auto-detect of input current limit */
+};
+
+#endif /* _BQ24257_CHARGER_H_ */
-- 
1.9.1

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

[PATCH v7 15/15] Documentation: power: bq24257: Document exported sysfs entries

[Andreas Dannenberg]

Document the settings exported by bq24257 charger driver through sysfs
entries:
- ovp_voltage
- in_dpm_voltage
- high_impedance_enable
- sysoff_enable

Signed-off-by: Andreas Dannenberg 
---
 Documentation/ABI/testing/sysfs-class-power | 58 +
 1 file changed, 58 insertions(+)

diff --git a/Documentation/ABI/testing/sysfs-class-power 
b/Documentation/ABI/testing/sysfs-class-power
index 369d2a2..d96b5fc 100644
--- a/Documentation/ABI/testing/sysfs-class-power
+++ b/Documentation/ABI/testing/sysfs-class-power
@@ -74,3 +74,61 @@ Description:
 
Valid values:
- 0 - 70 (minutes), step by 10 (rounded down)
+
+What:  /sys/class/power_supply/bq24257-charger/ovp_voltage
+Date:  September 2015
+KernelVersion: 4.3.0
+Contact:   Andreas Dannenberg 
+Description:
+   This entry configures the overvoltage protection feature of 
bq24257-
+   type charger devices. This feature protects the device and other
+   components against damage from overvoltage on the input supply. 
See
+   device datasheet for details.
+
+   Valid values:
+   - 600, 650, 700, 800, 900, 950, 
1000,
+ 1050 (all uV)
+
+What:  /sys/class/power_supply/bq24257-charger/in_dpm_voltage
+Date:  September 2015
+KernelVersion: 4.3.0
+Contact:   Andreas Dannenberg 
+Description:
+   This entry configures the input dynamic power path management 
voltage of
+   bq24257-type charger devices. Once the supply drops to the 
configured
+   voltage, the input current limit is reduced down to prevent the 
further
+   drop of the supply. When the IC enters this mode, the charge 
current is
+   lower than the set value. See device datasheet for details.
+
+   Valid values:
+   - 420, 428, 436, 444, 452, 460, 468,
+ 476 (all uV)
+
+What:  /sys/class/power_supply/bq24257-charger/high_impedance_enable
+Date:  September 2015
+KernelVersion: 4.3.0
+Contact:   Andreas Dannenberg 
+Description:
+   This entry allows enabling the high-impedance mode of 
bq24257-type
+   charger devices. If enabled, it places the charger IC into low 
power
+   standby mode with the switch mode controller disabled. When 
disabled,
+   the charger operates normally. See device datasheet for details.
+
+   Valid values:
+   - 1: enabled
+   - 0: disabled
+
+What:  /sys/class/power_supply/bq24257-charger/sysoff_enable
+Date:  September 2015
+KernelVersion: 4.3.0
+Contact:   Andreas Dannenberg 
+Description:
+   This entry allows enabling the sysoff mode of bq24257-type 
charger
+   devices. If enabled and the input is removed, the internal 
battery FET
+   is turned off in order to reduce the leakage from the BAT pin 
to less
+   than 1uA. Note that on some devices/systems this disconnects 
the battery
+   from the system. See device datasheet for details.
+
+   Valid values:
+   - 1: enabled
+   - 0: disabled
-- 
1.9.1

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

[PATCH v7 07/15] power: bq24257: Add bit definition for temp sense enable

[Andreas Dannenberg]

Adding a missing bit definition for the sake of consistency device model
vs. bit field representation. No change in functionality.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index b0c8533..93f7582 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -66,7 +66,7 @@ enum bq24257_fields {
F_VBAT, F_USB_DET,  /* REG 3 */
F_ICHG, F_ITERM,/* REG 4 */
F_LOOP_STATUS, F_LOW_CHG, F_DPDM_EN, F_CE_STATUS, F_VINDPM, /* REG 5 */
-   F_X2_TMR_EN, F_TMR, F_SYSOFF, F_TS_STAT,/* REG 6 */
+   F_X2_TMR_EN, F_TMR, F_SYSOFF, F_TS_EN, F_TS_STAT,   /* REG 6 */
F_VOVP, F_CLR_VDP, F_FORCE_BATDET, F_FORCE_PTM, /* REG 7 */
 
F_MAX_FIELDS
@@ -156,6 +156,7 @@ static const struct reg_field bq24257_reg_fields[] = {
[F_X2_TMR_EN]   = REG_FIELD(BQ24257_REG_6, 7, 7),
[F_TMR] = REG_FIELD(BQ24257_REG_6, 5, 6),
[F_SYSOFF]  = REG_FIELD(BQ24257_REG_6, 4, 4),
+   [F_TS_EN]   = REG_FIELD(BQ24257_REG_6, 3, 3),
[F_TS_STAT] = REG_FIELD(BQ24257_REG_6, 0, 2),
/* REG 7 */
[F_VOVP]= REG_FIELD(BQ24257_REG_7, 5, 7),
-- 
1.9.1

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

[PATCH v7 01/15] dt: power: bq24257-charger: Cover additional devices

[Andreas Dannenberg]

Extend the bq24257 charger's device tree documentation to cover the
bq24250 and bq24251 devices as well feature additions.

Signed-off-by: Andreas Dannenberg 
---
 .../devicetree/bindings/power/bq24257.txt  | 53 --
 1 file changed, 48 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/power/bq24257.txt 
b/Documentation/devicetree/bindings/power/bq24257.txt
index 5c9d394..6c376ef 100644
--- a/Documentation/devicetree/bindings/power/bq24257.txt
+++ b/Documentation/devicetree/bindings/power/bq24257.txt
@@ -1,21 +1,64 @@
-Binding for TI bq24257 Li-Ion Charger
+Binding for TI bq24250/bq24251/bq24257 Li-Ion Charger
 
 Required properties:
 - compatible: Should contain one of the following:
+ * "ti,bq24250"
+ * "ti,bq24251"
  * "ti,bq24257"
-- reg:integer, i2c address of the device.
+- reg: integer, i2c address of the device.
+- interrupt-parent: Should be the phandle for the interrupt controller. Use in
+conjunction with "interrupts".
+- interrupts: Interrupt mapping for GPIO IRQ (configure for both edges). Use in
+conjunction with "interrupt-parent".
 - ti,battery-regulation-voltage: integer, maximum charging voltage in uV.
-- ti,charge-current:  integer, maximum charging current in uA.
-- ti,termination-current:  integer, charge will be terminated when current in
-  constant-voltage phase drops below this value (in 
uA).
+- ti,charge-current: integer, maximum charging current in uA.
+- ti,termination-current: integer, charge will be terminated when current in
+constant-voltage phase drops below this value (in uA).
+
+Optional properties:
+- pg-gpios: GPIO used for connecting the bq2425x device PG (Power Good) pin.
+This pin is not available on all devices however it should be used if
+possible as this is the recommended way to obtain the charger's input PG
+state. If this pin is not specified a software-based approach for PG
+detection is used.
+- ti,current-limit: The maximum current to be drawn from the charger's input
+(in uA). If this property is not specified a USB D+/D- signal based charger
+type detection is used (if available) and the input limit current is set
+accordingly. If the D+/D- based detection is not available on a given 
device
+a default of 500,000 is used (=500mA).
+- ti,ovp-voltage: Configures the over voltage protection voltage (in uV). If
+not specified a default of 6,5000,000 (=6.5V) is used.
+- ti,in-dpm-voltage: Configures the threshold input voltage for the dynamic
+power path management (in uV). If not specified a default of 4,360,000
+(=4.36V) is used.
 
 Example:
 
 bq24257 {
compatible = "ti,bq24257";
reg = <0x6a>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <16 IRQ_TYPE_EDGE_BOTH>;
+
+   pg-gpios = <&gpio1 28 GPIO_ACTIVE_HIGH>;
 
ti,battery-regulation-voltage = <420>;
ti,charge-current = <100>;
ti,termination-current = <5>;
 };
+
+Example:
+
+bq24250 {
+   compatible = "ti,bq24250";
+   reg = <0x6a>;
+   interrupt-parent = <&gpio1>;
+   interrupts = <16 IRQ_TYPE_EDGE_BOTH>;
+
+   ti,battery-regulation-voltage = <420>;
+   ti,charge-current = <50>;
+   ti,termination-current = <5>;
+   ti,current-limit = <90>;
+   ti,ovp-voltage = <950>;
+   ti,in-dpm-voltage = <444>;
+};
-- 
1.9.1

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

[PATCH v7 10/15] power: bq24257: Add over voltage protection setting support

[Andreas Dannenberg]

A new optional device property called "ti,ovp-voltage" is introduced to
allow configuring the input over voltage protection setting.

This commit also adds the basic sysfs support for custom properties
which is being used to allow userspace to read the current ovp-voltage
setting.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 67 +++--
 1 file changed, 64 insertions(+), 3 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 5800697..fd4d2da 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -78,6 +78,7 @@ struct bq24257_init_data {
u8 vbat;/* regulation voltage  */
u8 iterm;   /* termination current */
u8 iilimit; /* input current limit */
+   u8 vovp;/* over voltage protection voltage */
 };
 
 struct bq24257_state {
@@ -200,6 +201,13 @@ static const u32 bq24257_iilimit_map[] = {
 
 #define BQ24257_IILIMIT_MAP_SIZE   ARRAY_SIZE(bq24257_iilimit_map)
 
+static const u32 bq24257_vovp_map[] = {
+   600, 650, 700, 800, 900, 950, 1000,
+   1050
+};
+
+#define BQ24257_VOVP_MAP_SIZE  ARRAY_SIZE(bq24257_vovp_map)
+
 static int bq24257_field_read(struct bq24257_device *bq,
  enum bq24257_fields field_id)
 {
@@ -415,6 +423,17 @@ enum bq24257_in_ilimit {
IILIMIT_NONE,
 };
 
+enum bq24257_vovp {
+   VOVP_6000,
+   VOVP_6500,
+   VOVP_7000,
+   VOVP_8000,
+   VOVP_9000,
+   VOVP_9500,
+   VOVP_1,
+   VOVP_10500
+};
+
 enum bq24257_port_type {
PORT_TYPE_DCP,  /* Dedicated Charging Port */
PORT_TYPE_CDP,  /* Charging Downstream Port */
@@ -586,7 +605,8 @@ static int bq24257_hw_init(struct bq24257_device *bq)
} init_data[] = {
{F_ICHG, bq->init_data.ichg},
{F_VBAT, bq->init_data.vbat},
-   {F_ITERM, bq->init_data.iterm}
+   {F_ITERM, bq->init_data.iterm},
+   {F_VOVP, bq->init_data.vovp},
};
 
/*
@@ -656,6 +676,28 @@ static const struct power_supply_desc 
bq24257_power_supply_desc = {
.get_property = bq24257_power_supply_get_property,
 };
 
+static ssize_t bq24257_show_ovp_voltage(struct device *dev,
+   struct device_attribute *attr,
+   char *buf)
+{
+   struct power_supply *psy = dev_get_drvdata(dev);
+   struct bq24257_device *bq = power_supply_get_drvdata(psy);
+
+   return scnprintf(buf, PAGE_SIZE, "%u\n",
+bq24257_vovp_map[bq->init_data.vovp]);
+}
+
+static DEVICE_ATTR(ovp_voltage, S_IRUGO, bq24257_show_ovp_voltage, NULL);
+
+static struct attribute *bq24257_charger_attr[] = {
+   &dev_attr_ovp_voltage.attr,
+   NULL,
+};
+
+static const struct attribute_group bq24257_attr_group = {
+   .attrs = bq24257_charger_attr,
+};
+
 static int bq24257_power_supply_init(struct bq24257_device *bq)
 {
struct power_supply_config psy_cfg = { .drv_data = bq, };
@@ -731,6 +773,15 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
 bq24257_iilimit_map,
 BQ24257_IILIMIT_MAP_SIZE);
 
+   ret = device_property_read_u32(bq->dev, "ti,ovp-voltage",
+  &property);
+   if (ret < 0)
+   bq->init_data.vovp = VOVP_6500;
+   else
+   bq->init_data.vovp = bq24257_find_idx(property,
+ bq24257_vovp_map,
+ BQ24257_VOVP_MAP_SIZE);
+
return 0;
 }
 
@@ -854,10 +905,18 @@ static int bq24257_probe(struct i2c_client *client,
}
 
ret = bq24257_power_supply_init(bq);
-   if (ret < 0)
+   if (ret < 0) {
dev_err(dev, "Failed to register power supply\n");
+   return ret;
+   }
 
-   return ret;
+   ret = sysfs_create_group(&bq->charger->dev.kobj, &bq24257_attr_group);
+   if (ret < 0) {
+   dev_err(dev, "Can't create sysfs entries\n");
+   return ret;
+   }
+
+   return 0;
 }
 
 static int bq24257_remove(struct i2c_client *client)
@@ -867,6 +926,8 @@ static int bq24257_remove(struct i2c_client *client)
if (bq->iilimit_autoset_enable)
cancel_delayed_work_sync(&bq->iilimit_setup_work);
 
+   sysfs_remove_group(&bq->charger->dev.kobj, &bq24257_attr_group);
+
bq24257_field_write(bq, F_RESET, 1); /* reset to defaults */
 
return 0;
-- 
1.9.1

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

[PATCH v7 05/15] power: bq24257: Simplify bq24257_power_supply_init()

[Andreas Dannenberg]

Eliminate a few lines of code by using the PTR_ERR_OR_ZERO() macro.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 6757b41..060f754 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -594,10 +594,7 @@ static int bq24257_power_supply_init(struct bq24257_device 
*bq)
 &bq24257_power_supply_desc,
 &psy_cfg);
 
-   if (IS_ERR(bq->charger))
-   return PTR_ERR(bq->charger);
-
-   return 0;
+   return PTR_ERR_OR_ZERO(bq->charger);
 }
 
 static int bq24257_pg_gpio_probe(struct bq24257_device *bq)
-- 
1.9.1

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

[PATCH v7 00/15] power: bq24257: Add support for bq24250/bq24251

[Andreas Dannenberg]

This patch series extends the driver to also support bq24250/bq24251.

The bq24250/251/257 devices have a very similar feature set and are
virtually identical from a control register point of view so it made
sense to extend the existing driver rather than submitting a new driver.
In addition to the new device support the driver is also extended to
allow access to some device features previously hidden. Basic and
potentially dangerous charger config parameters affecting the actual
charging of the Li-Ion battery are only configurable through firmware
rather than sysfs properties. However some newly introduced properties
are exposed through sysfs properties as access to them may be desired
from userspace. For example, it is now possible to manually configure
the maximum current drawn from the input source to accommodate different
chargers (0.5A, 1.5A, 2.0A and so on) based on system knowledge a
userspace application may have rather than rely on the auto-detection
mechanism that may not work in all possible scenarios.

Note that most patches have dependencies on other patches in the series.

v7:
- Fixed an issue that would have impacted running bisect on the series
  and double checked the entire series builds one by one by running
  a git rebase -i --exec="make ..." ... on the Kernel tree
- Minor simplification of a return from a function

v6:
- Removed the ability to configure the IRQ through "stat-gpios"
- Allow re-configuring the input_current_limit via sysfs also when
  charger auto-detection is enabled
- Use gpiod interface for initialization as a platform device (nice
  GPIO setup simplification)
- Document all newly introduced sysfs nodes
- Streamlined/fixed/simplified charger state handling as it relates
  to battery removal/insertion and the associated handling of the
  input current limit setting
- Minor simplifications/cleanup
- Rebased onto git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-
  power-supply.git (branch "next") and completely retested

v5:
- Added patch to use the managed version of power supply register which
  also fixes a code flow issue that was introduced
- Minor fixes / consistency cleanup (Krzysztof's feedback)

v4:
- Removed configurability of the safety timer multiplier through DT

v3:
- Dropped the driver/symbol rename patch from v2 due to anticipated
  issues with upcoming bq2425x family additions
- Reverted additional mutex coverage for I2C access due to regmap
  built-in mutex protection being sufficient
- Removed support for trickle charging due to being a rare/uncommon
  use case
- Fixed most checkpatch.pl --strict alignment issues (except where
  the line length would exceed 80 chars)
- Fixed an issue with how the return value of gpio_to_desc() was
  handled
- Fixed an issue with the definition of bq24257_of_match[]
- Reordered the patch series to put the DT doc changes to the
  beginning

v2:
- Aligned DT bindings better with existing "ti,*" charger bindings
- Dropped patch that improperly reported a missing battery as a dead
  battery
- Fixed (hopefully, that is -- still waiting for my test platform)
  issue with how the private ACPI driver_data used to identify which
  bq2425x device to use
- Removed boolean DT/ACPI properties mostly by replacing them with more
  intelligent handling in the driver
- Rework/clarification of DT bindings doc
- Renamed/refactored filenames/symbols from bq24257 to bq2425x to
  better reflect that multiple devices are covered. Despite initial
  hesitation I feel this is a good opportunity for some clean-up as
  the driver is still very new in the Kernel so the change should be
  low risk. This also addresses one of Andrew Davis' feedback items.
  Plus, it makes for a nice alignment with the existing bq2415x_charger
  driver.

v1:
- Initial submission

Andreas Dannenberg (15):
  dt: power: bq24257-charger: Cover additional devices
  power: bq24257: Remove IRQ config through stat-gpios
  power: bq24257: Streamline input current limit setup
  power: bq24257: Use managed power supply register
  power: bq24257: Simplify bq24257_power_supply_init()
  power: bq24257: Add basic support for bq24250/bq24251
  power: bq24257: Add bit definition for temp sense enable
  power: bq24257: Allow manual setting of input current limit
  power: bq24257: Add SW-based approach for Power Good determination
  power: bq24257: Add over voltage protection setting support
  power: bq24257: Add input DPM voltage threshold setting support
  power: bq24257: Allow input current limit sysfs access
  power: bq24257: Add various device-specific sysfs properties
  power: bq24257: Add platform data based initialization
  Documentation: power: bq24257: Document exported sysfs entries

 Documentation/ABI/testing/sysfs-class-power|  58 +++
 .../devicetree/bindings/power/bq24257.txt  |  53 ++-
 drivers/power/Kconfig  |   5 +-
 drivers/power/bq24257_charger.c| 518 ++---
 include/linux/power/bq2

[PATCH v7 11/15] power: bq24257: Add input DPM voltage threshold setting support

[Andreas Dannenberg]

A new optional device property called "ti,in-dpm-voltage" is introduced
to allow configuring the input voltage threshold for the devices'
dynamic power path management (DPM) feature. In short, it can be used to
prevent the input voltage from dropping below a certain value as current
is drawn to charge the battery or supply the system.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 43 +
 1 file changed, 43 insertions(+)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index fd4d2da..2a76009 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -79,6 +79,7 @@ struct bq24257_init_data {
u8 iterm;   /* termination current */
u8 iilimit; /* input current limit */
u8 vovp;/* over voltage protection voltage */
+   u8 vindpm;  /* VDMP input threshold voltage */
 };
 
 struct bq24257_state {
@@ -208,6 +209,13 @@ static const u32 bq24257_vovp_map[] = {
 
 #define BQ24257_VOVP_MAP_SIZE  ARRAY_SIZE(bq24257_vovp_map)
 
+static const u32 bq24257_vindpm_map[] = {
+   420, 428, 436, 444, 452, 460, 468,
+   476
+};
+
+#define BQ24257_VINDPM_MAP_SIZEARRAY_SIZE(bq24257_vindpm_map)
+
 static int bq24257_field_read(struct bq24257_device *bq,
  enum bq24257_fields field_id)
 {
@@ -434,6 +442,17 @@ enum bq24257_vovp {
VOVP_10500
 };
 
+enum bq24257_vindpm {
+   VINDPM_4200,
+   VINDPM_4280,
+   VINDPM_4360,
+   VINDPM_4440,
+   VINDPM_4520,
+   VINDPM_4600,
+   VINDPM_4680,
+   VINDPM_4760
+};
+
 enum bq24257_port_type {
PORT_TYPE_DCP,  /* Dedicated Charging Port */
PORT_TYPE_CDP,  /* Charging Downstream Port */
@@ -607,6 +626,7 @@ static int bq24257_hw_init(struct bq24257_device *bq)
{F_VBAT, bq->init_data.vbat},
{F_ITERM, bq->init_data.iterm},
{F_VOVP, bq->init_data.vovp},
+   {F_VINDPM, bq->init_data.vindpm},
};
 
/*
@@ -687,10 +707,23 @@ static ssize_t bq24257_show_ovp_voltage(struct device 
*dev,
 bq24257_vovp_map[bq->init_data.vovp]);
 }
 
+static ssize_t bq24257_show_in_dpm_voltage(struct device *dev,
+  struct device_attribute *attr,
+  char *buf)
+{
+   struct power_supply *psy = dev_get_drvdata(dev);
+   struct bq24257_device *bq = power_supply_get_drvdata(psy);
+
+   return scnprintf(buf, PAGE_SIZE, "%u\n",
+bq24257_vindpm_map[bq->init_data.vindpm]);
+}
+
 static DEVICE_ATTR(ovp_voltage, S_IRUGO, bq24257_show_ovp_voltage, NULL);
+static DEVICE_ATTR(in_dpm_voltage, S_IRUGO, bq24257_show_in_dpm_voltage, NULL);
 
 static struct attribute *bq24257_charger_attr[] = {
&dev_attr_ovp_voltage.attr,
+   &dev_attr_in_dpm_voltage.attr,
NULL,
 };
 
@@ -782,6 +815,16 @@ static int bq24257_fw_probe(struct bq24257_device *bq)
  bq24257_vovp_map,
  BQ24257_VOVP_MAP_SIZE);
 
+   ret = device_property_read_u32(bq->dev, "ti,in-dpm-voltage",
+  &property);
+   if (ret < 0)
+   bq->init_data.vindpm = VINDPM_4360;
+   else
+   bq->init_data.vindpm =
+   bq24257_find_idx(property,
+bq24257_vindpm_map,
+BQ24257_VINDPM_MAP_SIZE);
+
return 0;
 }
 
-- 
1.9.1

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

[PATCH v7 09/15] power: bq24257: Add SW-based approach for Power Good determination

[Andreas Dannenberg]

A software-based approach for determining the charger's input voltage
"Power Good" state is introduced for devices like the bq24250 which
don't have a dedicated hardware pin for that purpose. This SW-based
approach is also used for other devices (with dedicated PG pin) as a
fall back solution if that pin is not configured to be used through
"pg-gpios".

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 49 -
 1 file changed, 39 insertions(+), 10 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 7bbff80..5800697 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -359,7 +359,26 @@ static int bq24257_get_chip_state(struct bq24257_device 
*bq,
 
state->fault = ret;
 
-   state->power_good = !gpiod_get_value_cansleep(bq->pg);
+   if (bq->pg)
+   state->power_good = !gpiod_get_value_cansleep(bq->pg);
+   else
+   /*
+* If we have a chip without a dedicated power-good GPIO or
+* some other explicit bit that would provide this information
+* assume the power is good if there is no supply related
+* fault - and not good otherwise. There is a possibility for
+* other errors to mask that power in fact is not good but this
+* is probably the best we can do here.
+*/
+   switch (state->fault) {
+   case FAULT_INPUT_OVP:
+   case FAULT_INPUT_UVLO:
+   case FAULT_INPUT_LDO_LOW:
+   state->power_good = false;
+   break;
+   default:
+   state->power_good = true;
+   }
 
return 0;
 }
@@ -651,15 +670,18 @@ static int bq24257_power_supply_init(struct 
bq24257_device *bq)
return PTR_ERR_OR_ZERO(bq->charger);
 }
 
-static int bq24257_pg_gpio_probe(struct bq24257_device *bq)
+static void bq24257_pg_gpio_probe(struct bq24257_device *bq)
 {
-   bq->pg = devm_gpiod_get_index(bq->dev, BQ24257_PG_GPIO, 0, GPIOD_IN);
+   bq->pg = devm_gpiod_get_optional(bq->dev, BQ24257_PG_GPIO, GPIOD_IN);
+
if (IS_ERR(bq->pg)) {
-   dev_err(bq->dev, "could not probe PG pin\n");
-   return PTR_ERR(bq->pg);
+   dev_err(bq->dev, "error probing PG pin\n");
+   bq->pg = NULL;
+   return;
}
 
-   return 0;
+   if (bq->pg)
+   dev_dbg(bq->dev, "probed PG pin = %d\n", desc_to_gpio(bq->pg));
 }
 
 static int bq24257_fw_probe(struct bq24257_device *bq)
@@ -789,10 +811,17 @@ static int bq24257_probe(struct i2c_client *client,
INIT_DELAYED_WORK(&bq->iilimit_setup_work,
  bq24257_iilimit_setup_work);
 
-   /* we can only check Power Good status by probing the PG pin */
-   ret = bq24257_pg_gpio_probe(bq);
-   if (ret < 0)
-   return ret;
+   /*
+* The BQ24250 doesn't have a dedicated Power Good (PG) pin so let's
+* not probe for it and instead use a SW-based approach to determine
+* the PG state. We also use a SW-based approach for all other devices
+* if the PG pin is either not defined or can't be probed.
+*/
+   if (bq->chip != BQ24250)
+   bq24257_pg_gpio_probe(bq);
+
+   if (!bq->pg)
+   dev_info(bq->dev, "using SW-based power-good detection\n");
 
/* reset all registers to defaults */
ret = bq24257_field_write(bq, F_RESET, 1);
-- 
1.9.1

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

[PATCH v7 02/15] power: bq24257: Remove IRQ config through stat-gpios

[Andreas Dannenberg]

At the time the driver was written GpioInt resources in ACPI were not
passed to the driver in client->irq, as opposed to DT enumeration. To
accommodate this use case, a "stat-gpios" property was introduced to
allow configuring the IRQ.

However this issue with ACPI was fixed in commit "845c877 i2c / ACPI:
Assign IRQ for devices that have GpioInt automatically" and makes this
workaround no longer necessary, hence we can remove the support for the
"stat-gpios" property and the associated code from the bq24257 driver.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 28 
 1 file changed, 4 insertions(+), 24 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index 5859bc7..69b53d0 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -36,7 +36,6 @@
 #define BQ24257_REG_7  0x06
 
 #define BQ24257_MANUFACTURER   "Texas Instruments"
-#define BQ24257_STAT_IRQ   "stat"
 #define BQ24257_PG_GPIO"pg"
 
 #define BQ24257_ILIM_SET_DELAY 1000/* msec */
@@ -606,19 +605,6 @@ static int bq24257_power_supply_init(struct bq24257_device 
*bq)
return 0;
 }
 
-static int bq24257_irq_probe(struct bq24257_device *bq)
-{
-   struct gpio_desc *stat_irq;
-
-   stat_irq = devm_gpiod_get_index(bq->dev, BQ24257_STAT_IRQ, 0, GPIOD_IN);
-   if (IS_ERR(stat_irq)) {
-   dev_err(bq->dev, "could not probe stat_irq pin\n");
-   return PTR_ERR(stat_irq);
-   }
-
-   return gpiod_to_irq(stat_irq);
-}
-
 static int bq24257_pg_gpio_probe(struct bq24257_device *bq)
 {
bq->pg = devm_gpiod_get_index(bq->dev, BQ24257_PG_GPIO, 0, GPIOD_IN);
@@ -740,21 +726,15 @@ static int bq24257_probe(struct i2c_client *client,
return ret;
}
 
-   if (client->irq <= 0)
-   client->irq = bq24257_irq_probe(bq);
-
-   if (client->irq < 0) {
-   dev_err(dev, "no irq resource found\n");
-   return client->irq;
-   }
-
ret = devm_request_threaded_irq(dev, client->irq, NULL,
bq24257_irq_handler_thread,
IRQF_TRIGGER_FALLING |
IRQF_TRIGGER_RISING | IRQF_ONESHOT,
-   BQ24257_STAT_IRQ, bq);
-   if (ret)
+   "bq24257", bq);
+   if (ret) {
+   dev_err(dev, "Failed to request IRQ #%d\n", client->irq);
return ret;
+   }
 
ret = bq24257_power_supply_init(bq);
if (ret < 0)
-- 
1.9.1

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

[PATCH v7 04/15] power: bq24257: Use managed power supply register

[Andreas Dannenberg]

Use the devm_* managed version of the function to register the power
supply and remove the associated unregister function.

Signed-off-by: Andreas Dannenberg 
---
 drivers/power/bq24257_charger.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/power/bq24257_charger.c b/drivers/power/bq24257_charger.c
index d2d077c..6757b41 100644
--- a/drivers/power/bq24257_charger.c
+++ b/drivers/power/bq24257_charger.c
@@ -590,8 +590,10 @@ static int bq24257_power_supply_init(struct bq24257_device 
*bq)
psy_cfg.supplied_to = bq24257_charger_supplied_to;
psy_cfg.num_supplicants = ARRAY_SIZE(bq24257_charger_supplied_to);
 
-   bq->charger = power_supply_register(bq->dev, &bq24257_power_supply_desc,
-   &psy_cfg);
+   bq->charger = devm_power_supply_register(bq->dev,
+&bq24257_power_supply_desc,
+&psy_cfg);
+
if (IS_ERR(bq->charger))
return PTR_ERR(bq->charger);
 
@@ -742,8 +744,6 @@ static int bq24257_remove(struct i2c_client *client)
 
cancel_delayed_work_sync(&bq->iilimit_setup_work);
 
-   power_supply_unregister(bq->charger);
-
bq24257_field_write(bq, F_RESET, 1); /* reset to defaults */
 
return 0;
-- 
1.9.1

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

Re: [PATCH 3/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Arnd Bergmann]

On Friday 25 September 2015 16:38:55 Jon Hunter wrote:
> On 25/09/15 16:17, Jon Hunter wrote:
> > 
> > On 25/09/15 16:03, Arnd Bergmann wrote:
> >> On Friday 25 September 2015 15:56:40 Jon Hunter wrote:
> >>> +   case DMA_MEM_TO_DEV:
> >>> +   burst_size = fls(tdc->config.dst_maxburst);
> >>> +   ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(num_bufs - 1);
> >>> +   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_MEM_TO_AHUB) |
> >>> +   ADMA_CH_CTRL_TX_REQ(tdc->config.slave_id);
> >>> +   ch_regs->src_addr = buf_addr;
> >>> +   break;
> >>> +
> >>> +   case DMA_DEV_TO_MEM:
> >>> +   burst_size = fls(tdc->config.src_maxburst);
> >>> +   ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(num_bufs - 1);
> >>> +   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_AHUB_TO_MEM) |
> >>> +   ADMA_CH_CTRL_RX_REQ(tdc->config.slave_id);
> >>> +   ch_regs->trg_addr = buf_addr;
> >>> +   break;
> >>
> >> Do not use the 'slave_id' field here to identify the slave device, that
> >> concept is broken. Instead, put the slave identification into the
> >> dma specifier in DT and read it out in your xlate function.
> > 
> > Why is it broken?
> > 
> > What happens if I don't know the slave-id? In other words, the slave-id
> > can be dynamically allocated and associated with a given slave.
> 
> I guess thinking about it some more, the driver could assign an id
> itself to a given channel and I could avoid using slave_id here. There
> are 22 channels and 10 tx and 10 rx requests.

This sounds roughly right. So you could pick the ch_regs->ctrl value
when you allocate the tegra_adma_chan structure, and then map it to
the slave in the xlate() function.

> However, I could also
> statically assign a mapping in DT for the clients if that is preferred.

That's not what I was looking for, the DT should contain the information
that the DMA master uses to identify a device, not a setting that it
can freely choose.

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

Re: [PATCH 3/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Stephen Warren]

On 09/25/2015 09:38 AM, Jon Hunter wrote:


On 25/09/15 16:17, Jon Hunter wrote:


On 25/09/15 16:03, Arnd Bergmann wrote:

On Friday 25 September 2015 15:56:40 Jon Hunter wrote:

+   case DMA_MEM_TO_DEV:
+   burst_size = fls(tdc->config.dst_maxburst);
+   ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(num_bufs - 1);
+   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_MEM_TO_AHUB) |
+   ADMA_CH_CTRL_TX_REQ(tdc->config.slave_id);
+   ch_regs->src_addr = buf_addr;
+   break;
+
+   case DMA_DEV_TO_MEM:
+   burst_size = fls(tdc->config.src_maxburst);
+   ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(num_bufs - 1);
+   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_AHUB_TO_MEM) |
+   ADMA_CH_CTRL_RX_REQ(tdc->config.slave_id);
+   ch_regs->trg_addr = buf_addr;
+   break;


Do not use the 'slave_id' field here to identify the slave device, that
concept is broken. Instead, put the slave identification into the
dma specifier in DT and read it out in your xlate function.


Why is it broken?

What happens if I don't know the slave-id? In other words, the slave-id
can be dynamically allocated and associated with a given slave.


I guess thinking about it some more, the driver could assign an id
itself to a given channel and I could avoid using slave_id here. There
are 22 channels and 10 tx and 10 rx requests. However, I could also
statically assign a mapping in DT for the clients if that is preferred.


The channel IDs should be dynamically assigned at run-time.

DT should provide the slave ID (if there is one) for each client.

The two concepts are completely orthogonal.
--
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

Re: [PATCH 3/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Jon Hunter]

On 25/09/15 16:17, Jon Hunter wrote:
> 
> On 25/09/15 16:03, Arnd Bergmann wrote:
>> On Friday 25 September 2015 15:56:40 Jon Hunter wrote:
>>> +   case DMA_MEM_TO_DEV:
>>> +   burst_size = fls(tdc->config.dst_maxburst);
>>> +   ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(num_bufs - 1);
>>> +   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_MEM_TO_AHUB) |
>>> +   ADMA_CH_CTRL_TX_REQ(tdc->config.slave_id);
>>> +   ch_regs->src_addr = buf_addr;
>>> +   break;
>>> +
>>> +   case DMA_DEV_TO_MEM:
>>> +   burst_size = fls(tdc->config.src_maxburst);
>>> +   ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(num_bufs - 1);
>>> +   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_AHUB_TO_MEM) |
>>> +   ADMA_CH_CTRL_RX_REQ(tdc->config.slave_id);
>>> +   ch_regs->trg_addr = buf_addr;
>>> +   break;
>>
>> Do not use the 'slave_id' field here to identify the slave device, that
>> concept is broken. Instead, put the slave identification into the
>> dma specifier in DT and read it out in your xlate function.
> 
> Why is it broken?
> 
> What happens if I don't know the slave-id? In other words, the slave-id
> can be dynamically allocated and associated with a given slave.

I guess thinking about it some more, the driver could assign an id
itself to a given channel and I could avoid using slave_id here. There
are 22 channels and 10 tx and 10 rx requests. However, I could also
statically assign a mapping in DT for the clients if that is preferred.

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

Re: [PATCH 3/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Arnd Bergmann]

On Friday 25 September 2015 16:17:29 Jon Hunter wrote:
> On 25/09/15 16:03, Arnd Bergmann wrote:
> > On Friday 25 September 2015 15:56:40 Jon Hunter wrote:
> >> +   case DMA_MEM_TO_DEV:
> >> +   burst_size = fls(tdc->config.dst_maxburst);
> >> +   ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(num_bufs - 1);
> >> +   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_MEM_TO_AHUB) |
> >> +   ADMA_CH_CTRL_TX_REQ(tdc->config.slave_id);
> >> +   ch_regs->src_addr = buf_addr;
> >> +   break;
> >> +
> >> +   case DMA_DEV_TO_MEM:
> >> +   burst_size = fls(tdc->config.src_maxburst);
> >> +   ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(num_bufs - 1);
> >> +   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_AHUB_TO_MEM) |
> >> +   ADMA_CH_CTRL_RX_REQ(tdc->config.slave_id);
> >> +   ch_regs->trg_addr = buf_addr;
> >> +   break;
> > 
> > Do not use the 'slave_id' field here to identify the slave device, that
> > concept is broken. Instead, put the slave identification into the
> > dma specifier in DT and read it out in your xlate function.
> 
> Why is it broken?

This requires the slave driver to pass a slave id through the
dmaengine_slave_config() interface, but we don't want the driver
to know how it is connected to the dma engine. That information is
not a property of the slave itself but rather of the connection
between the slave and the master, and it belongs into DT, similar
to how we deal with IRQ or GPIO numbers.

> What happens if I don't know the slave-id? In other words, the slave-id
> can be dynamically allocated and associated with a given slave.

How do you identify the slave that the slave-id is associated with?

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

Re: [PATCH 1/3] Documentation: dt: keystone: provide SoC specific compatible flags

[santosh shilimkar]

On 9/25/2015 7:50 AM, Nishanth Menon wrote:

On 09/24/2015 10:54 AM, Murali Karicheri wrote:
[...]

ti,omap3 is the family of omap3 devices similar to keystone. ti,omap3450
is required if there is an exceptional treatment required for ti,omap3450.

In keystone case so far there is no case of exceptional treatment
required in the code for a specific SoC. So a generic name, ti,keystone
is used. When exceptional treatment is needed in the future, for example
k2hk Soc, we should introduce SoC specific string in the following order.


Did you do a grep on the code to see?
$ git grep ti,omap3 arch/arm/mach-omap2/
arch/arm/mach-omap2/board-generic.c:"ti,omap3430",
arch/arm/mach-omap2/board-generic.c:"ti,omap3",
arch/arm/mach-omap2/board-generic.c:"ti,omap36xx",
arch/arm/mach-omap2/board-generic.c:"ti,omap3-beagle",

This is the same as keystone's device support. even though only 36xx was
needed, we introduced other SoC specific compatibility match.


"ti,k2hk-evm", "ti,k2hk", "ti,keystone"

So unless there is an exception, there is no need for a SoC specific
string in the compatibility string list. So this can be added later if
there is need for exceptional treatment. Did I get it wrong?



I see both your views seem to be "if we dont need a compatible" dont add
it. My view was based on "be accurate in the hardware description"

OK - i will probably agree on the topic. But, how about userspace
needing to know which SoC they are on, without needing to depend on
board->soc mapping? How do we help resolve that?


Why the user space should care about exact SOC ?
--
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

Re: [PATCH 3/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Jon Hunter]

On 25/09/15 16:03, Arnd Bergmann wrote:
> On Friday 25 September 2015 15:56:40 Jon Hunter wrote:
>> +   case DMA_MEM_TO_DEV:
>> +   burst_size = fls(tdc->config.dst_maxburst);
>> +   ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(num_bufs - 1);
>> +   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_MEM_TO_AHUB) |
>> +   ADMA_CH_CTRL_TX_REQ(tdc->config.slave_id);
>> +   ch_regs->src_addr = buf_addr;
>> +   break;
>> +
>> +   case DMA_DEV_TO_MEM:
>> +   burst_size = fls(tdc->config.src_maxburst);
>> +   ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(num_bufs - 1);
>> +   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_AHUB_TO_MEM) |
>> +   ADMA_CH_CTRL_RX_REQ(tdc->config.slave_id);
>> +   ch_regs->trg_addr = buf_addr;
>> +   break;
> 
> Do not use the 'slave_id' field here to identify the slave device, that
> concept is broken. Instead, put the slave identification into the
> dma specifier in DT and read it out in your xlate function.

Why is it broken?

What happens if I don't know the slave-id? In other words, the slave-id
can be dynamically allocated and associated with a given slave.

Cheers
Jon
--
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

Re: [PATCH v2] ARM: dts: sunxi: Add regulators for LeMaker BananaPi

[Timo Sigurdsson]

Hi Kevin,

Kevin Hilman schrieb am 25. Sept 2015 01:57:

> On Tue, Aug 18, 2015 at 8:36 AM, Maxime Ripard
>  wrote:
>> On Sun, Aug 02, 2015 at 06:18:25PM +0200, Timo Sigurdsson wrote:
>>> sun7i-a20-bananapi.dts doesn't contain regulator nodes for the AXP209
>>> PMU
>>> driver, so add them to allow for voltage-scaling with cpufreq-dt.
>>>
>>> Signed-off-by: Timo Sigurdsson 
>>
>> Queued, thanks!
>> Maxime
> 
> kernelci.org started finding boot faiulres[1] on bananapi linux-next
> around next-20150918, but it was only failing in some labs and not
> others.  I finally bisected it down to this patch, which landed in
> linux-next in the form of 2d665a8a8350 ARM: dts: sunxi: Add regulators
> for LeMaker BananaPi.  Reverting that commit on top of next-20150923
> gets my bananapi booting again.
> 
> Note it's kind of an interesting boot failure.  The kernel boots fully
> to a shell, but panics after running a few commands.  In particular
> 'dmesg -n1' seems to trigger it usually[2].
> 
> Kevin
> 
> [1]
> http://kernelci.org/boot/sun7i-a20-bananapi/job/next/kernel/next-20150923/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5602504359b514be146c326f
> [2]
> http://storage.kernelci.org/next/next-20150923/arm-multi_v7_defconfig/lab-khilman/boot-sun7i-a20-bananapi.html
> 

Thanks for your feedback. I'm traveling at the moment, so I can't do any 
testing but just guess wildly. I know, though, that I used dmesg frequently 
when I did my own testing before submitting the patch and could not see such 
behavior.

Before this commit, the CPU of your BananaPi runs at 1.4 volts constantly. With 
this commit applied, the CPU voltage should vary between 1.0-1.4 volts 
depending on the frequency and defined operating points. Hence, one of my 
guesses would be that your CPU is not stable at the lower voltages. Could you 
modify the voltages for the defined frequencies in sun7i-a20.dtsi and test if 
that solves your issue? Say, raise the voltage by 0.1 volts for each operating 
point (but no higher than 1.4). I actually had a different patch that applied 
slightly higher voltages taken from the original fex for by LeMaker, but the 
feedback was, unless there are actual reports about boards not running stable 
at the current settings, we just keep them instead. So, I'm curious if you 
happen to have a board that requires slightly higher voltages to run stable.

Regards, 

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

[PATCH] ARM: dts: Add am335x-bonegreen

[Robert Nelson]

SeeedStudio BeagleBone Green (BBG) is clone of the BeagleBone Black (BBB) minus
the HDMI port and addition of two Grove connectors (i2c2 and usart2).

This board can be identified by the 1A value after A335BNLT (BBB) in the at24 
eeprom:
1A: [aa 55 33 ee 41 33 33 35  42 4e 4c 54 1a 00 00 00 |.U3.A335BNLT|]

http://beagleboard.org/green
http://www.seeedstudio.com/wiki/Beaglebone_green

Signed-off-by: Robert Nelson 
CC: Tony Lindgren 
CC: Jason Kridner 
---
 arch/arm/boot/dts/Makefile |  1 +
 arch/arm/boot/dts/am335x-bonegreen.dts | 53 ++
 2 files changed, 54 insertions(+)
 create mode 100644 arch/arm/boot/dts/am335x-bonegreen.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 233159d..e45d771 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -446,6 +446,7 @@ dtb-$(CONFIG_SOC_AM33XX) += \
am335x-base0033.dtb \
am335x-bone.dtb \
am335x-boneblack.dtb \
+   am335x-bonegreen.dtb \
am335x-sl50.dtb \
am335x-evm.dtb \
am335x-evmsk.dtb \
diff --git a/arch/arm/boot/dts/am335x-bonegreen.dts 
b/arch/arm/boot/dts/am335x-bonegreen.dts
new file mode 100644
index 000..0f65bda
--- /dev/null
+++ b/arch/arm/boot/dts/am335x-bonegreen.dts
@@ -0,0 +1,53 @@
+/*
+ * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * 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.
+ */
+/dts-v1/;
+
+#include "am33xx.dtsi"
+#include "am335x-bone-common.dtsi"
+
+/ {
+   model = "TI AM335x BeagleBone Green";
+   compatible = "ti,am335x-bone-green", "ti,am335x-bone-black", 
"ti,am335x-bone", "ti,am33xx";
+};
+
+&ldo3_reg {
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   regulator-always-on;
+};
+
+&mmc1 {
+   vmmc-supply = <&vmmcsd_fixed>;
+};
+
+&mmc2 {
+   vmmc-supply = <&vmmcsd_fixed>;
+   pinctrl-names = "default";
+   pinctrl-0 = <&emmc_pins>;
+   bus-width = <8>;
+   status = "okay";
+};
+
+&am33xx_pinmux {
+   uart2_pins: uart2_pins {
+   pinctrl-single,pins = <
+   0x150 (PIN_INPUT | MUX_MODE1)   /* spi0_sclk.uart2_rxd 
*/
+   0x154 (PIN_OUTPUT | MUX_MODE1)  /* spi0_d0.uart2_txd */
+   >;
+   };
+};
+
+&uart2 {
+   pinctrl-names = "default";
+   pinctrl-0 = <&uart2_pins>;
+   status = "okay";
+};
+
+&rtc {
+   system-power-controller;
+};
-- 
2.5.3

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

Re: [PATCH 1/3] dmaengine: of: Allow #dma-cells to be zero

[Arnd Bergmann]

On Friday 25 September 2015 15:56:38 Jon Hunter wrote:
> Currently, the #dma-cells property must be 1 or more. However, for some
> DMA controllers, where DMA clients may use any DMA channel and it is not
> necessary to specify any other DMA information in the device-tree DMA
> binding, setting #dma-cells to 0 is desirable. The Tegra210 ADMA
> controller is an example of a DMA controller where neither the DMA
> channel or the hardware request signal need to be encoded in the
> device-tree binding.
> 
> By allowing DMA controllers to set #dma-cells to 0, means that the
> "dma-names" property for these controllers is not needed. Therefore,
> update the of_dma_request_slave_channel() and of_dma_match_channel()
> functions to ignore this property if no name is provided.
> 
> Signed-off-by: Jon Hunter 

Sorry, but this makes no sense. #dma-cells=0 would imply that there
is only one slave per DMA controller, but that is not the case here.
As commented in patch 3, you actually support multiple slaves, you
just use the wrong interface.

Arnd

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

Re: [PATCH 3/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Arnd Bergmann]

On Friday 25 September 2015 15:56:40 Jon Hunter wrote:
> +   case DMA_MEM_TO_DEV:
> +   burst_size = fls(tdc->config.dst_maxburst);
> +   ch_regs->config = ADMA_CH_CONFIG_SRC_BUF(num_bufs - 1);
> +   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_MEM_TO_AHUB) |
> +   ADMA_CH_CTRL_TX_REQ(tdc->config.slave_id);
> +   ch_regs->src_addr = buf_addr;
> +   break;
> +
> +   case DMA_DEV_TO_MEM:
> +   burst_size = fls(tdc->config.src_maxburst);
> +   ch_regs->config = ADMA_CH_CONFIG_TRG_BUF(num_bufs - 1);
> +   ch_regs->ctrl = ADMA_CH_CTRL_XFER_DIR(ADMA_AHUB_TO_MEM) |
> +   ADMA_CH_CTRL_RX_REQ(tdc->config.slave_id);
> +   ch_regs->trg_addr = buf_addr;
> +   break;

Do not use the 'slave_id' field here to identify the slave device, that
concept is broken. Instead, put the slave identification into the
dma specifier in DT and read it out in your xlate function.

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

[PATCH 3/3] dmaengine: tegra-adma: Add support for Tegra210 ADMA

[Jon Hunter]

Add support for the Tegra210 Audio DMA controller that is used for
transferring data between system memory and the Audio sub-system.
The driver only supports cyclic transfers because this is being solely
used for audio.

This driver is based upon the work by Dara Ramesh .

Signed-off-by: Jon Hunter 
---
 drivers/dma/Kconfig |  13 +
 drivers/dma/Makefile|   1 +
 drivers/dma/tegra210-adma.c | 820 
 3 files changed, 834 insertions(+)
 create mode 100644 drivers/dma/tegra210-adma.c

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index b4584757dae0..5721fc9aae32 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -463,6 +463,19 @@ config TEGRA20_APB_DMA
  This DMA controller transfers data from memory to peripheral fifo
  or vice versa. It does not support memory to memory data transfer.
 
+config TEGRA210_ADMA
+   bool "NVIDIA Tegra210 ADMA support"
+   depends on ARCH_TEGRA
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Support for the NVIDIA Tegra210 ADMA controller driver. The
+ DMA controller has multiple DMA channels and is used to service
+ various audio clients in the Tegra210 audio processing engine
+ (APE). This DMA controller transfers data from memory to
+ peripheral and vice versa. It does not support memory to
+ memory data transfer.
+
 config TIMB_DMA
tristate "Timberdale FPGA DMA support"
depends on MFD_TIMBERDALE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 7711a7180726..4d88c7efc4e1 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -59,6 +59,7 @@ obj-$(CONFIG_STE_DMA40) += ste_dma40.o ste_dma40_ll.o
 obj-$(CONFIG_S3C24XX_DMAC) += s3c24xx-dma.o
 obj-$(CONFIG_TXX9_DMAC) += txx9dmac.o
 obj-$(CONFIG_TEGRA20_APB_DMA) += tegra20-apb-dma.o
+obj-$(CONFIG_TEGRA210_ADMA) += tegra210-adma.o
 obj-$(CONFIG_TIMB_DMA) += timb_dma.o
 obj-$(CONFIG_TI_CPPI41) += cppi41.o
 obj-$(CONFIG_TI_DMA_CROSSBAR) += ti-dma-crossbar.o
diff --git a/drivers/dma/tegra210-adma.c b/drivers/dma/tegra210-adma.c
new file mode 100644
index ..73013fa5fed2
--- /dev/null
+++ b/drivers/dma/tegra210-adma.c
@@ -0,0 +1,820 @@
+/*
+ * ADMA driver for Nvidia's Tegra210 ADMA controller.
+ *
+ * Copyright (c) 2015, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "dmaengine.h"
+#include "virt-dma.h"
+
+#define ADMA_CH_CMD0x00
+#define ADMA_CH_STATUS 0x0c
+#define ADMA_CH_STATUS_XFER_EN BIT(0)
+
+#define ADMA_CH_INT_STATUS 0x10
+#define ADMA_CH_INT_STATUS_XFER_DONE   BIT(0)
+
+#define ADMA_CH_INT_CLEAR  0x1c
+#define ADMA_CH_CTRL   0x24
+#define ADMA_CH_CTRL_TX_REQ(val)   (((val) & 0xf) << 28)
+#define ADMA_CH_CTRL_RX_REQ(val)   (((val) & 0xf) << 24)
+#define ADMA_CH_CTRL_XFER_DIR(val) (((val) & 0xf) << 12)
+#define ADMA_CH_CTRL_XFER_MODE_CONTINUOUS  (2 << 8)
+#define ADMA_CH_CTRL_XFER_FLOWCTRL_EN  BIT(1)
+
+#define ADMA_CH_CONFIG 0x28
+#define ADMA_CH_CONFIG_SRC_BUF(val)(((val) & 0x7) << 28)
+#define ADMA_CH_CONFIG_TRG_BUF(val)(((val) & 0x7) << 24)
+#define ADMA_CH_CONFIG_BURST_SIZE(val) (((val) & 0x7) << 20)
+#define ADMA_CH_CONFIG_WEIGHT_FOR_WRR(val) ((val) & 0xf)
+#define ADMA_CH_CONFIG_MAX_BUFS8
+
+#define ADMA_CH_FIFO_CTRL  0x2c
+#define ADMA_CH_FIFO_CTRL_OVRFW_THRES(val) (((val) & 0xf) << 24)
+#define ADMA_CH_FIFO_CTRL_STARV_THRES(val) (((val) & 0xf) << 16)
+#define ADMA_CH_FIFO_CTRL_TX_SIZE(val) (((val) & 0xf) << 8)
+#define ADMA_CH_FIFO_CTRL_RX_SIZE(val) ((val) & 0xf)
+
+#define ADMA_CH_TC_STATUS  0x30
+#define ADMA_CH_LOWER_SRC_ADDR   

[PATCH 0/3] Add support for Tegra210 ADMA

[Jon Hunter]

Add support for the Tegra210 Audio DMA (ADMA) controller. This was
originally distributed as an RFC [0] based upon the existing tegra
APB-DMA driver. Since then the driver has been significantly
re-worked to remove a lot of the unused/unnecessary functionality
that was carried over from the APB-DMA. This version is no longer
derived from the APB-DMA driver and has been updated to use the
virt-dma helpers.

[0] https://lkml.org/lkml/2015/8/18/237

Jon Hunter (3):
  dmaengine: of: Allow #dma-cells to be zero
  Documentation: DT: Add binding documentation for NVIDIA ADMA
  dmaengine: tegra-adma: Add support for Tegra210 ADMA

 Documentation/devicetree/bindings/dma/dma.txt  |  12 +-
 .../devicetree/bindings/dma/tegra210-adma.txt  |  47 ++
 drivers/dma/Kconfig|  13 +
 drivers/dma/Makefile   |   1 +
 drivers/dma/of-dma.c   |  23 +-
 drivers/dma/tegra210-adma.c| 820 +
 6 files changed, 904 insertions(+), 12 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/dma/tegra210-adma.txt
 create mode 100644 drivers/dma/tegra210-adma.c

-- 
2.1.4

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

[PATCH 2/3] Documentation: DT: Add binding documentation for NVIDIA ADMA

[Jon Hunter]

Add device-tree binding documentation for the Tegra210 Audio DMA
controller.

Signed-off-by: Jon Hunter 
---
 .../devicetree/bindings/dma/tegra210-adma.txt  | 47 ++
 1 file changed, 47 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/tegra210-adma.txt

diff --git a/Documentation/devicetree/bindings/dma/tegra210-adma.txt 
b/Documentation/devicetree/bindings/dma/tegra210-adma.txt
new file mode 100644
index ..af04b3c5a557
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/tegra210-adma.txt
@@ -0,0 +1,47 @@
+* NVIDIA Tegra Audio DMA controller
+
+Required properties:
+- compatible: Should be "nvidia,-adma"
+- reg: Should contain DMA registers location and length. This should include
+  all of the per-channel registers.
+- interrupt-parent: Phandle to the interrupt parent controller.
+- interrupts: Should contain all of the per-channel DMA interrupts.
+- clocks: Must contain two entries, one for the power-domain clock and one
+  for the module clock. See ../clocks/clock-bindings.txt for details.
+- dma-channels: Number of DMA channels supported by the controller.
+- #dma-cells : Must be <0>.
+
+Examples:
+
+adma: adma@702e2000 {
+   compatible = "nvidia,tegra210-adma";
+   reg = <0x0 0x702e2000 0x0 0x2000>;
+   interrupt-parent = <&tegra_agic>;
+   interrupts = ,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+,
+;
+   clocks = <&tegra_car TEGRA210_CLK_D_AUDIO>,
+<&tegra_car TEGRA210_CLK_ADMA_APE>;
+   clock-names = "adma", "adma.ape";
+   dma-channels = <22>;
+   #dma-cells = <0>;
+};
-- 
2.1.4

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

[PATCH 1/3] dmaengine: of: Allow #dma-cells to be zero

[Jon Hunter]

Currently, the #dma-cells property must be 1 or more. However, for some
DMA controllers, where DMA clients may use any DMA channel and it is not
necessary to specify any other DMA information in the device-tree DMA
binding, setting #dma-cells to 0 is desirable. The Tegra210 ADMA
controller is an example of a DMA controller where neither the DMA
channel or the hardware request signal need to be encoded in the
device-tree binding.

By allowing DMA controllers to set #dma-cells to 0, means that the
"dma-names" property for these controllers is not needed. Therefore,
update the of_dma_request_slave_channel() and of_dma_match_channel()
functions to ignore this property if no name is provided.

Signed-off-by: Jon Hunter 
---
 Documentation/devicetree/bindings/dma/dma.txt | 12 
 drivers/dma/of-dma.c  | 23 +++
 2 files changed, 23 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/dma.txt 
b/Documentation/devicetree/bindings/dma/dma.txt
index 6312fb00ce8d..4d73916fc879 100644
--- a/Documentation/devicetree/bindings/dma/dma.txt
+++ b/Documentation/devicetree/bindings/dma/dma.txt
@@ -8,9 +8,12 @@ controller.
 * DMA controller
 
 Required property:
-- #dma-cells:  Must be at least 1. Used to provide DMA controller
-   specific information. See DMA client binding below for
-   more details.
+- #dma-cells:  Used to provide DMA controller specific information.
+   Can be 0 for DMA controllers where clients may use
+   any channel and any DMA specific information, such
+   as a hardware request signal, does not need to be
+   encoded in the binding. See DMA client binding below
+   for more details.
 
 Optional properties:
 - dma-channels:Number of DMA channels supported by the controller.
@@ -79,7 +82,8 @@ Required property:
are defined in the binding of the DMA client device.
Multiple DMA specifiers can be used to represent
alternatives and in this case the dma-names for those
-   DMA specifiers must be identical (see examples).
+   DMA specifiers must be identical (see examples). This
+   is optional for DMA controllers where #dma-cells is 0.
 
 Examples:
 
diff --git a/drivers/dma/of-dma.c b/drivers/dma/of-dma.c
index 1e1f2986eba8..ef3d260610ea 100644
--- a/drivers/dma/of-dma.c
+++ b/drivers/dma/of-dma.c
@@ -214,11 +214,13 @@ static int of_dma_match_channel(struct device_node *np, 
const char *name,
 {
const char *s;
 
-   if (of_property_read_string_index(np, "dma-names", index, &s))
-   return -ENODEV;
+   if (name) {
+   if (of_property_read_string_index(np, "dma-names", index, &s))
+   return -ENODEV;
 
-   if (strcmp(name, s))
-   return -ENODEV;
+   if (strcmp(name, s))
+   return -ENODEV;
+   }
 
if (of_parse_phandle_with_args(np, "dmas", "#dma-cells", index,
   dma_spec))
@@ -230,7 +232,7 @@ static int of_dma_match_channel(struct device_node *np, 
const char *name,
 /**
  * of_dma_request_slave_channel - Get the DMA slave channel
  * @np:device node to get DMA request from
- * @name:  name of desired channel
+ * @name:  name of desired channel (optional)
  *
  * Returns pointer to appropriate DMA channel on success or an error pointer.
  */
@@ -243,8 +245,8 @@ struct dma_chan *of_dma_request_slave_channel(struct 
device_node *np,
int count, i;
int ret_no_channel = -ENODEV;
 
-   if (!np || !name) {
-   pr_err("%s: not enough information provided\n", __func__);
+   if (!np) {
+   pr_err("%s: device node is not valid\n", __func__);
return ERR_PTR(-ENODEV);
}
 
@@ -252,7 +254,12 @@ struct dma_chan *of_dma_request_slave_channel(struct 
device_node *np,
if (!of_find_property(np, "dmas", NULL))
return ERR_PTR(-ENODEV);
 
-   count = of_property_count_strings(np, "dma-names");
+   /*
+* If a name is not provided, then assume that there is one
+* DMA specifier in the list for the client and so set the
+* count to 1 and see if this matches.
+*/
+   count = name ? of_property_count_strings(np, "dma-names") : 1;
if (count < 0) {
pr_err("%s: dma-names property of node '%s' missing or empty\n",
__func__, np->full_name);
-- 
2.1.4

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