Re: [PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

2015-12-29 Thread Bjorn Andersson 
On Tue 29 Dec 10:34 PST 2015, Rob Herring wrote:

> On Sun, Dec 27, 2015 at 05:34:27PM -0800, Bjorn Andersson wrote:
> > Add binding representing the Qualcomm wcn3620/60/80 WiFi block.
> > Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> > ---
> >  .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 
> > ++
> >  1 file changed, 76 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
> > b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > new file mode 100644
> > index ..7b314b9f30af
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
> > @@ -0,0 +1,76 @@
> > +Qualcomm WCN36xx WiFi Binding
> > +
> > +This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware 
> > block
> > +is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a 
> > variety
> > +of Qualcomm platforms.
> 
> Are BT/FM functions completely separate? If so, separate bindings are 
> okay. If not, then we need to describe the full chip.
> 

It's three different hardware blocks (WiFi, BT and FM-radio) with shared
RF-hardware and an ARM core for control logic.

There seems to be some control commands going towards the BT part that
controls coexistence properties of the RF-hardware, but other than that
I see it as logically separate blocks.


So I think it's fine to model this as separate pieces in DT.

Regards,
Bjorn
--
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: [RESEND v4 1/6] remoteproc: dt: Provide bindings for ST's Remote Processor Controller driver

2015-12-28 Thread Bjorn Andersson 
On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones <lee.jo...@linaro.org> wrote:
> Signed-off-by: Ludovic Barre <ludovic.ba...@st.com>
> Signed-off-by: Lee Jones <lee.jo...@linaro.org>
> ---

Acked-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Regards,
Bjorn

>  .../devicetree/bindings/remoteproc/st-rproc.txt| 41 
> ++
>  1 file changed, 41 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/remoteproc/st-rproc.txt
>
> diff --git a/Documentation/devicetree/bindings/remoteproc/st-rproc.txt 
> b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> new file mode 100644
> index 000..1031bcd
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/remoteproc/st-rproc.txt
> @@ -0,0 +1,41 @@
> +STMicroelectronics Co-Processor Bindings
> +
> +
> +This binding provides support for adjunct processors found on ST SoCs.
> +
> +Co-processors can be controlled from the bootloader or the primary OS. If
> +the bootloader starts a co-processor, the primary OS must detect its state
> +and act accordingly.
> +
> +Required properties:
> +- compatible   Should be one of:
> +   "st,st231-rproc"
> +   "st,st40-rproc"
> +- memory-regionReserved memory (See: 
> ../reserved-memory/reserved-memory.txt)
> +- resets   Reset lines (See: ../reset/reset.txt)
> +- reset-names  Must be "sw_reset" and "pwr_reset"
> +- clocks   Clock for co-processor (See: 
> ../clock/clock-bindings.txt)
> +- clock-frequency  Clock frequency to set co-processor at if the 
> bootloader
> +   hasn't already done so
> +- st,syscfgSystem configuration register which holds the boot 
> vector
> +   for the co-processor
> +   1st cell: Phandle to syscon block
> +   2nd cell: Boot vector register offset
> +
> +Example:
> +
> +   audio_reserved: rproc@4200 {
> +   compatible = "shared-dma-pool";
> +   reg = <0x4200 0x0100>;
> +   no-map;
> +   };
> +
> +   st231-audio {
> +   compatible  = "st,st231-rproc";
> +   memory-region   = <_reserved>;
> +   resets  = < STIH407_ST231_AUD_SOFTRESET>;
> +   reset-names = "sw_reset";
> +   clocks  = <_s_c0_flexgen CLK_ST231_AUD_0>;
> +   clock-frequency = <6>;
> +   st,syscfg   = <_core 0x228>;
> +   };
> --
> 1.9.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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: [RESEND v4 3/6] remoteproc: Supply controller driver for ST's Remote Processors

2015-12-28 Thread Bjorn Andersson 
On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones <lee.jo...@linaro.org> wrote:
> Signed-off-by: Ludovic Barre <ludovic.ba...@st.com>
> Signed-off-by: Lee Jones <lee.jo...@linaro.org>
> ---

Acked-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Regards,
Bjorn

>  drivers/remoteproc/Kconfig |   9 ++
>  drivers/remoteproc/Makefile|   1 +
>  drivers/remoteproc/st_remoteproc.c | 297 
> +
>  3 files changed, 307 insertions(+)
>  create mode 100644 drivers/remoteproc/st_remoteproc.c
>
> diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
> index 28c711f..72e97d7 100644
> --- a/drivers/remoteproc/Kconfig
> +++ b/drivers/remoteproc/Kconfig
> @@ -77,4 +77,13 @@ config DA8XX_REMOTEPROC
>   It's safe to say n here if you're not interested in multimedia
>   offloading.
>
> +config ST_REMOTEPROC
> +   tristate "ST remoteproc support"
> +   depends on ARCH_STI
> +   select REMOTEPROC
> +   help
> + Say y here to support ST's adjunct processors via the remote
> + processor framework.
> + This can be either built-in or a loadable module.
> +
>  endmenu
> diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
> index 81b04d1..279cb2e 100644
> --- a/drivers/remoteproc/Makefile
> +++ b/drivers/remoteproc/Makefile
> @@ -11,3 +11,4 @@ obj-$(CONFIG_OMAP_REMOTEPROC) += omap_remoteproc.o
>  obj-$(CONFIG_STE_MODEM_RPROC)  += ste_modem_rproc.o
>  obj-$(CONFIG_WKUP_M3_RPROC)+= wkup_m3_rproc.o
>  obj-$(CONFIG_DA8XX_REMOTEPROC) += da8xx_remoteproc.o
> +obj-$(CONFIG_ST_REMOTEPROC)+= st_remoteproc.o
> diff --git a/drivers/remoteproc/st_remoteproc.c 
> b/drivers/remoteproc/st_remoteproc.c
> new file mode 100644
> index 000..6bb04d4
> --- /dev/null
> +++ b/drivers/remoteproc/st_remoteproc.c
> @@ -0,0 +1,297 @@
> +/*
> + * ST's Remote Processor Control Driver
> + *
> + * Copyright (C) 2015 STMicroelectronics - All Rights Reserved
> + *
> + * Author: Ludovic Barre <ludovic.ba...@st.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.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct st_rproc_config {
> +   boolsw_reset;
> +   boolpwr_reset;
> +   unsigned long   bootaddr_mask;
> +};
> +
> +struct st_rproc {
> +   struct st_rproc_config  *config;
> +   struct reset_control*sw_reset;
> +   struct reset_control*pwr_reset;
> +   struct clk  *clk;
> +   u32 clk_rate;
> +   struct regmap   *boot_base;
> +   u32 boot_offset;
> +};
> +
> +static int st_rproc_start(struct rproc *rproc)
> +{
> +   struct st_rproc *ddata = rproc->priv;
> +   int err;
> +
> +   regmap_update_bits(ddata->boot_base, ddata->boot_offset,
> +  ddata->config->bootaddr_mask, rproc->bootaddr);
> +
> +   err = clk_enable(ddata->clk);
> +   if (err) {
> +   dev_err(>dev, "Failed to enable clock\n");
> +   return err;
> +   }
> +
> +   if (ddata->config->sw_reset) {
> +   err = reset_control_deassert(ddata->sw_reset);
> +   if (err) {
> +   dev_err(>dev, "Failed to deassert S/W 
> Reset\n");
> +   goto sw_reset_fail;
> +   }
> +   }
> +
> +   if (ddata->config->pwr_reset) {
> +   err = reset_control_deassert(ddata->pwr_reset);
> +   if (err) {
> +   dev_err(>dev, "Failed to deassert Power 
> Reset\n");
> +   goto pwr_reset_fail;
> +   }
> +   }
> +
> +   dev_info(>dev, "Started from 0x%x\n", rproc->bootaddr);
> +
> +   return 0;
> +
> +
> +pwr_reset_fail:
> +   if (ddata->config->pwr_reset)
> +   reset_control_assert(ddata->sw_reset);
> +sw_reset_fail:
> +   clk_disable(ddata->clk);
> +
> +   return err;
> +}
> +
> +static int st_rproc_stop(struct rproc *rproc)
> +{
> +   struct st_rproc *ddata = rproc->priv;
&g

Re: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

2015-12-28 Thread Bjorn Andersson 
On Fri, Dec 4, 2015 at 12:24 AM, Lee Jones  wrote:
> On Thu, 03 Dec 2015, Arnd Bergmann wrote:
>
>> On Thursday 03 December 2015 17:28:30 Lee Jones wrote:
>> > >
>> > > Ah, interesting. I haven't tried myself, and just tried to read the
>> > > code. Maybe glibc already catches zero-length writes before it gets
>> > > into the kernel, or I just missed the part of the syscall that checks
>> > > for this.
>> >
>> > Glibc is responsible indeed:
>> >
>> >   http://osxr.org/glibc/source/io/write.c
>>
>> Ok, so an attacker can force the stack overflow by calling
>> syscall(__NR_write, fd, p, 0) if that has any potential value,
>> but normal users won't hit this case.
>
> Right.  I have fixed the issue (and another one I found) anyway, if
> only to rid the GCC warning.
>

Sorry, but I'm unable to find a new version of this patch, did I miss
it or could you resend it?


Also, as I looked at this again, we should probably return an error if
count >= sizeof(buf) rather than just acknowledging the input (same in
the other debugfs write function in this file).

Regards,
Bjorn
--
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: [RESEND v4 0/6] remoteproc: Add driver for STMicroelectronics platforms

2015-12-28 Thread Bjorn Andersson 
On Thu, Nov 26, 2015 at 1:32 AM, Ohad Ben-Cohen  wrote:
> On Thu, Nov 26, 2015 at 11:10 AM, Lee Jones  wrote:
>> On Thu, 26 Nov 2015, Ohad Ben-Cohen wrote:
>>> On Tue, Nov 24, 2015 at 3:14 PM, Lee Jones  wrote:
>>> > ST's platforms often have multiple co-processors (usually ST40s or ST231s)
>>> > on-board.  This provides the Linux-side infrastructure to flash and boot
>>> > them successfully.
>>> >
>>> > This set has been tested on an STiH410-B2120.
>>>
>>> It would be nice if you could get at least one Reviewed-by tag coming
>>> outside of ST (e.g., Suman or Bjorn who are actively using and
>>> improving remoteproc).
>>
>> If you require reviews by these guys, shouldn't they be Maintainers?
>
> Additional review isn't a requirement, but it's a plus.
>
>> Please be aware that
>> the DTS(I) changes are applied to this set for your information only
>> and are not to be applied through the RemoteProc tree.  The usual
>> process to which we conform is that Maxime (the STi Maintainer) will
>> apply the DT changes *after* the main driver has been applied, in this
>> case by you.
>
> Ok, great, so I will not take patches 5 and 6.
>

I interpreted this as you picked patch 1-4 and didn't pay more
attention to them, but I can't find them in your kernel.org trees. So
I've looked through them again.

Please apply patch 1, 3 and 4 to your tree Ohad. I was unable to find
a v5 of patch 2, but it's unrelated so no need to wait for a new
version of that.

Regards,
Bjorn
--
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 v2 0/4] Qualcomm WCNSS Peripheral Image Loader

2015-12-27 Thread Bjorn Andersson 
This series provides the minimum changes needed to use remotproc on the
Qualcomm platform and then introduces the Peripheral Image Loader for
the WCNSS core.

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

 .../bindings/remoteproc/qcom,wcnss-pil.txt |  92 
 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| 550 +
 drivers/remoteproc/remoteproc_core.c   |  10 +-
 include/linux/remoteproc.h |   4 +
 8 files changed, 884 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

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

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

2015-12-27 Thread 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 <bjorn.anders...@sonymobile.com>
---

Changes since v1:
- Dropped custom properties for firmware-name and crash-reason

 .../bindings/remoteproc/qcom,wcnss-pil.txt | 92 ++
 1 file changed, 92 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 ..e69bd415106b
--- /dev/null
+++ b/Documentation/devicetree/bindings/remoteproc/qcom,wcnss-pil.txt
@@ -0,0 +1,92 @@
+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,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 = < 0 149 1>,
+ <_smp2p_slave 0 0>,
+ <_smp2p_slave 1 0>,
+ <_smp2p_slave 2 0>,
+ <_smp2p_slave 3 0>;
+   interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
+
+   clocks = < RPM_CXO_CLK_SRC>, < RPM_CXO_A2>;
+   clock-names = "xo", "rf";
+
+   qcom,iris-vddxo-supply = <_l6>;
+   qcom,iris-vddrfa-supply = <_l11>;
+   qcom,iris-vddpa-supply = <_l19>;
+   qcom,iris-vdddig-supply = <_s3>;
+   qcom,pronto-vddmx-supply = <_s1>;
+   qcom,pronto-vddcx-supply = <_s2>;
+   qcom,pronto-vddpx-supply = <_s3>;
+
+   qcom,state = <_smp2p_out 0>;
+   qcom,state-names = "stop";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_a>;
+};
-- 
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

[PATCH 0/4] WCN36xx convert to mainline SMD interface

2015-12-27 Thread Bjorn Andersson 
The mainline kernel now has the necessary implementations for SMD, SMSM and
WCNSS_CTRL. This series provides the changes necessary for the wcn36xx driver
to utilize this infrastructure and make this driver work in mainline.


A driver for loading the WCNSS firmware, through remoteproc, has been posted
here [1]. Upon starting this the necessary SMD channels will be registered,
which triggers the probe of the wcn36xx driver.

With this, the only missing piece for having fully working Qualcomm WiFi in
mainline is the RPM clock-controller, needed by the remoteproc driver for doing
XO calibration during boot of the WCNSS core. This is being worked on
separately.

[1] https://lkml.org/lkml/2015/12/27/185

Bjorn Andersson (4):
  wcn36xx: Fold indication payload into message header
  wcn36xx: Change indication list lock to spinlock
  wcn36xx: Transition driver to SMD client
  dt: binding: Add Qualcomm wcn36xx WiFi binding

 .../bindings/net/wireless/qcom,wcn36xx-wifi.txt|  76 ++
 drivers/net/wireless/ath/wcn36xx/Kconfig   |   2 +-
 drivers/net/wireless/ath/wcn36xx/dxe.c |  16 +--
 drivers/net/wireless/ath/wcn36xx/main.c| 111 -
 drivers/net/wireless/ath/wcn36xx/smd.c |  51 +-
 drivers/net/wireless/ath/wcn36xx/smd.h |   6 +-
 drivers/net/wireless/ath/wcn36xx/wcn36xx.h |  23 ++---
 7 files changed, 188 insertions(+), 97 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt

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

[PATCH 4/4] dt: binding: Add Qualcomm wcn36xx WiFi binding

2015-12-27 Thread Bjorn Andersson 
Add binding representing the Qualcomm wcn3620/60/80 WiFi block.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 .../bindings/net/wireless/qcom,wcn36xx-wifi.txt| 76 ++
 1 file changed, 76 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt

diff --git 
a/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt 
b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
new file mode 100644
index ..7b314b9f30af
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,wcn36xx-wifi.txt
@@ -0,0 +1,76 @@
+Qualcomm WCN36xx WiFi Binding
+
+This binding describes the Qualcomm WCN36xx WiFi hardware. The hardware block
+is part of the Qualcomm WCNSS core, a WiFi/BT/FM combo chip, found in a variety
+of Qualcomm platforms.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,wcn3620-wlan",
+   "qcom,wcn3660-wlan",
+   "qcom,wcn3680-wlan"
+
+- qcom,smd-channel:
+   Usage: required
+   Value type: 
+   Definition: standard SMD property specifying the SMD channel used for
+   communication with the WiFi firmware
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: should specify the two IRQs for tx and rx respectively
+
+- qcom,wcnss-mmio:
+   Usage: required
+   Value type: 
+   Definition: should specify base address and size of the WiFi related
+   registers of WCNSS
+
+- qcom,state:
+   Usage: required
+   Value type: 
+   Definition: should specify the tx-enable and tx-ring-empty state
+   references
+
+- qcom,state-names:
+   Usage: required
+   Value type: 
+   Definition: name of the states, must be "tx-enable", "tx-rings-empty";
+
+- local-mac-address:
+   Usage: optional
+   Value type:  encoded as array of hex numbers
+   Definition: specifies MAC address that was assigned to the network
+   device described by the node containing this property.
+
+= EXAMPLE
+The following example represents a SMD node, with one edge representing the
+"pronto" subsystem, with the wcn3680 WiFi device described; as found on the
+8974 platform.
+
+smd {
+   compatible = "qcom,smd";
+
+   pronto {
+   interrupts = <0 142 1>;
+
+   qcom,ipc = < 8 17>;
+   qcom,smd-edge = <6>;
+
+   wifi {
+   compatible = "qcom,wcn3680-wlan";
+   qcom,smd-channels = "WLAN_CTRL";
+
+   interrupts = <0 145 0>, <0 146 0>;
+   interrupt-names = "tx", "rx";
+
+   qcom,wcnss-mmio = <0xfb00 0x21b000>;
+
+   qcom,state = <_smsm 10>, <_smsm 9>;
+   qcom,state-names = "tx-enable", "tx-rings-empty";
+   };
+   };
+};
-- 
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

[PATCH] ARM: dts: qcom: msm8974: Add additional reserved regions

2015-12-27 Thread Bjorn Andersson 
This adds the additional reserved regions found on 8974 based devices.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 arch/arm/boot/dts/qcom-msm8974.dtsi | 40 +
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 578fa77ae331..3f6b8f2022c4 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -14,10 +14,50 @@
#size-cells = <1>;
ranges;
 
+   mpss@0800 {
+   reg = <0x0800 0x510>;
+   no-map;
+   };
+
+   mba@00d10 {
+   reg = <0x0d10 0x10>;
+   no-map;
+   };
+
+   reserved@0d20 {
+   reg = <0x0d20 0xa0>;
+   no-map;
+   };
+
+   adsp@0dc0 {
+   reg = <0x0dc0 0x190>;
+   no-map;
+   };
+
+   venus@0f50 {
+   reg = <0x0f50 0x50>;
+   no-map;
+   };
+
smem_region: smem@fa0 {
reg = <0xfa0 0x20>;
no-map;
};
+
+   tz@0fc0 {
+   reg = <0x0fc0 0x16>;
+   no-map;
+   };
+
+   efs@0fd60 {
+   reg = <0x0fd6 0x1a>;
+   no-map;
+   };
+
+   unused@0ff0 {
+   reg = <0x0ff0 0x1010>;
+   no-map;
+   };
};
 
firmware {
-- 
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 v5 3/5] PCI: qcom: Add Qualcomm PCIe controller driver

2015-12-20 Thread Bjorn Andersson 
On Fri, Dec 18, 2015 at 5:44 AM, kbuild test robot  wrote:
> Hi Stanimir,
>
> [auto build test WARNING on next-20151218]
> [also build test WARNING on v4.4-rc5]
> [cannot apply to pci/next robh/for-next v4.4-rc5 v4.4-rc4 v4.4-rc3]
>
> url:
> https://github.com/0day-ci/linux/commits/Stanimir-Varbanov/Qualcomm-PCIe-driver-and-designware-fixes/20151218-205427
>
>
> coccinelle warnings: (new ones prefixed by >>)
>
>>> drivers/pci/host/pcie-qcom.c:188:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>drivers/pci/host/pcie-qcom.c:220:1-3: WARNING: PTR_ERR_OR_ZERO can be used
>
> Please review and possibly fold the followup patch.
>

I disagree with this "recommendation" as it's only outcome will be asymmetry.

I think this script should be changed to only warn if there's a single
IS_ERR/PTR_ERR at the end of the function, not if there's a list of
them and this would replace the last one.

Regards,
Bjorn
--
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 5/5] ARM: dts: ifc6410: enable pcie dt node for this board

2015-12-17 Thread Bjorn Andersson 
On Thu 03 Dec 05:35 PST 2015, Stanimir Varbanov wrote:

> Enable pcie dt node and fill pcie dt node with regulator, pinctrl
> and reset gpio, to use the pcie on the ifc6410 board.
> 
> Signed-off-by: Stanimir Varbanov 
> ---
>  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |   26 ++
>  1 file changed, 26 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
> b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> index 11ac608b6d50..f203b94ee460 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
> @@ -47,6 +47,18 @@
>   bias-disable;
>   };
>   };
> +
> + pcie_pins: pcie_pinmux {
> + mux {
> + pins = "gpio27";
> + function = "gpio";
> + };
> + conf {
> + pins = "gpio27";
> + drive-strength = <12>;
> + bias-disable;
> + };
> + };
>   };
>  
>   rpm@108000 {
> @@ -123,6 +135,10 @@
>   pm8921_lvs1: lvs1 {
>   bias-pull-down;
>   };
> +
> + pm8921_lvs6: lvs6 {
> + bias-pull-down;
> + };

Please don't duplicate the labels in the dts files.

>   };
>   };
>  

Regards,
Bjorn
--
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 2/3] power: qcom_smbb: Add otg regulator for control of vbus

2015-12-15 Thread Bjorn Andersson 
On Tue 15 Dec 11:52 PST 2015, Tim Bird wrote:

> Add a regulator to control the OTG chargepath switch.  This
> is used by USB code to control VBUS direction - out for host mode
> on the OTG port, and in for charging mode.
> 
> Signed-off-by: Tim Bird <tim.b...@sonymobile.com>
> ---
> Changes since v3:
>  - changed DT node name to otg-vbus
>  - removed fixed-voltage setup from otg regulator rdesc
> Changes since v1:
>  - changed name of supply to remove underscores
> ---

Acked-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Regards,
Bjorn
--
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/3] dt-binding: power: Add otg regulator binding

2015-12-15 Thread Bjorn Andersson 
On Tue 15 Dec 11:52 PST 2015, Tim Bird wrote:

> Add a binding for the regulator which controls the OTG chargepath switch.
> The OTG switch gets its power from pm8941_5vs1, and that should be
> expressed as a usb_otg_in-supply property in the DT node for the
> charger driver.  The regulator name is "otg-vbus".
> 
> Signed-off-by: Tim Bird <tim.b...@sonymobile.com>
> ---
> Changes since v3
>  - switch supply name to have underscores instead of dashes
>- (switched back to match the name used in data sheets)

Thanks, now it matches the datasheet again.

>  - switch regulator node name to otg-vbus
> Changes since v1
>  - switch supply name to have dashes instead of underscores
>  - remove superfluous DT explanations in the otg node description
> ---

Acked-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Regards,
Bjorn
--
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 3/3] ARM: dts: qcom: add charger otg regulator

2015-12-15 Thread Bjorn Andersson 
On Tue 15 Dec 11:52 PST 2015, Tim Bird wrote:

> Add the otg regulator provided by the charger block.
> 
> Signed-off-by: Tim Bird <tim.b...@sonymobile.com>
> ---
> Changes since V3:
>  - change name of charger regulator to "otg-vbus"
> ---
>  arch/arm/boot/dts/qcom-pm8941.dtsi | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi 
> b/arch/arm/boot/dts/qcom-pm8941.dtsi
> index b0d4439..d0ffca7 100644
> --- a/arch/arm/boot/dts/qcom-pm8941.dtsi
> +++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
> @@ -45,6 +45,10 @@
> "chg-gone",
> "usb-valid",
> "dc-valid";
> +
> + usb_otg_in-supply = <_5vs1>;

Although this could be coming from some other supply I think it's
perfectly fine that we define this on a platform level.

> +
> +         chg_otg: otg-vbus { };
>   };
>  
>   pm8941_gpios: gpios@c000 {

Reviewed-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Regards,
Bjorn
--
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: [RFC][PATCH] misc: Introduce reboot_reason driver

2015-12-14 Thread Bjorn Andersson 
On Wed 09 Dec 17:32 PST 2015, John Stultz wrote:

> On Tue, Dec 8, 2015 at 2:07 PM, Bjorn Andersson
> <bjorn.anders...@sonymobile.com> wrote:
> > On Tue 08 Dec 13:29 PST 2015, John Stultz wrote:
> >> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts 
> >> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> >> index 5183d18..ee5dcb7 100644
> >> --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> >> +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> >> @@ -282,6 +282,15 @@
> >>   };
> >>   };
> >>
> >> + reboot_reason: reboot_reason@2a03f65c {
> >> + compatible  = "reboot_reason";
> >> + reg = <0x2A03F65C 0x4>;
> >> + reason,none = <0x77665501>;
> >> + reason,bootloader   = <0x77665500>;
> >> + reason,recovery = <0x77665502>;
> >> + reason,oem  = <0x6f656d00>;
> >> + };
> >> +
> >
> > This address refers to IMEM, which is shared with a number of other
> > uses. So I think we should have a simple-mfd (and syscon) with this
> > within.
> 
> So talking with Arnd some more it looked like IMEM was really just
> SRAM. Is that not the case, or is there something else special about
> it?  Does it really need simple-mfd and syscon? I'm still fuzzy on how
> to use those for this.
> 

I'm pretty sure it's just SRAM, but I hadn't looked at that binding
before, sounds like a conceptually better fit.

The part that I was looking for was the convenience of having a regmap
available for the uses that we will find later on, but I guess sram
provides similar means of accessing various pieces of the memory.

> >> + /* initialize specified reasons from DT */
> >> + if (!of_property_read_u32(pdev->dev.of_node, "reason,none", ))
> >> + reasons[NONE] = val;
> >> + if (!of_property_read_u32(pdev->dev.of_node, "reason,bootloader", 
> >> ))
> >> + reasons[BOOTLOADER] = val;
> >> + if (!of_property_read_u32(pdev->dev.of_node, "reason,recovery", 
> >> ))
> >> + reasons[RECOVERY] = val;
> >> + if (!of_property_read_u32(pdev->dev.of_node, "reason,oem", ))
> >> + reasons[OEM] = val;
> >
> > I would like for this to be less hard coded.
> 
> So thinking of this more. Is having something like:
> 
> cmds = "default", "bootloader", "recovery";
> vals  = <0xmagic1>, <0xmagic2>, <0xmagic3>;
> 
> what you're thinking about?

As these are normally just ascii strings I was thinking we could have
them as individual properties and then use for_each_property_of_node()
on the implementation side. But it doesn't really matter.

> 
> This wouldn't quite handle the "oem-N" options as simply, but they
> could define each oem- case explicitly in the DT to support it.
> 

If we have a reasonably dynamic way of defining these there's little to
no reason to treat oem-N specially from the others.

Regards,
Bjorn
--
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/4] arm: dts: qcom-apq8064: add smem and hwspinlock support

2015-12-11 Thread Bjorn Andersson 
On Fri 11 Dec 10:26 PST 2015, Srinivas Kandagatla wrote:

> Hi Andy, 
> 
> Here are 3 patches for smem/hwspinlock which I have tested with QDSP on 
> IFC6410.
> Also a fix from Ivan which I think can be taken aswell.
> 

As far as I can tell my patch for adding smem and hwmutex are already in
linux-next, via Andy's tree. Am I missing something?

Regards,
Bjorn
--
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: [RFC][PATCH] devicetree: Add DTS file to support the Nexus7 2013 (flo) device.

2015-12-11 Thread Bjorn Andersson 
On Fri 04 Dec 20:36 PST 2015, John Stultz wrote:

> This patch adds a dts file to support the Nexus7 2013
> device. Its based off of the qcom-apq8064-ifc6410.dts
> which is similar hardware.
> 
> Also includes some comments and context folded in
> from Vinay Simha BN 
> 
> This is my first DTS submission, so thoughts or feedback
> on would be appreciated.

Please remove this from the commit message ;)

[..]

> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 30bbc37..c0f9076a 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -502,6 +502,7 @@ dtb-$(CONFIG_ARCH_PRIMA2) += \
>  dtb-$(CONFIG_ARCH_QCOM) += \
>   qcom-apq8064-cm-qs600.dtb \
>   qcom-apq8064-ifc6410.dtb \
> + qcom-apq8064-nexus7-flo.dtb \

The format for the Sony products are -sony-.dts, I
think we should try to follow this for other devices as well.

>   qcom-apq8074-dragonboard.dtb \
>   qcom-apq8084-ifc6540.dtb \
>   qcom-apq8084-mtp.dtb \
> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts 
> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> new file mode 100644
> index 000..5183d18
> --- /dev/null
> +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> @@ -0,0 +1,306 @@
> +#include "qcom-apq8064-v2.0.dtsi"
> +#include 
> +#include 
> +#include 
> +/ {
> + model = "Qualcomm APQ8064/Nexus7(flo)";
> + compatible = "qcom,apq8064-nexus7-flo", "qcom,apq8064";

The Nexus7 isn't a Qualcomm product, so you should omit that from the
model and I believe the compatible should be "asus,something-flo",
"qcom,apq8064".

> +
> + aliases {
> + serial0 = _serial;
> + serial1 = _serial;
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + soc {
> + rpm@108000 {
> + regulators {
> + vdd_l1_l2_l12_l18-supply = <_s4>;
> + vin_lvs1_3_6-supply = <_s4>;
> + vin_lvs4_5_7-supply = <_s4>;
> +
> +
> + vdd_l24-supply = <_s1>;
> + vdd_l25-supply = <_s1>;
> + vin_lvs2-supply = <_s1>;
> +
> + vdd_l26-supply = <_s7>;
> + vdd_l27-supply = <_s7>;
> + vdd_l28-supply = <_s7>;
> +
> + vdd_ncp-supply = <_l6>;
> +
> + /* Buck SMPS */
> + pm8921_s1: s1 {

These nodes already have labels, from the dtsi. So please omit the
labels.

> + regulator-always-on;
> + regulator-min-microvolt = <1225000>;
> + regulator-max-microvolt = <1225000>;
> + qcom,switch-mode-frequency = <320>;
> + bias-pull-down;
> + };
> +
[..]
> + };
> +
> + ext_3p3v: regulator-fixed@1 {

This regulator does not sit on the mmio bus should as such be moved
outside of the soc {}.

> + compatible = "regulator-fixed";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + regulator-name = "ext_3p3v";
> + regulator-type = "voltage";
> + startup-delay-us = <0>;
> + gpio = <_pinmux 77 GPIO_ACTIVE_HIGH>;
> + enable-active-high;
> + regulator-boot-on;
> + };
> +
> + gsbi3: gsbi@1620 {

Please omit this label.

> + status = "okay";
> + qcom,mode = ;
> + i2c3: i2c@1628 {

Please omit this label.

> + status = "okay";
> + clock-frequency = <20>;
> + pinctrl-0 = <_pins>;
> + pinctrl-names = "default";
> +
> + trackpad: trackpad@10 {

Please omit this label.

> + compatible = "elan,ekth3500";
> + reg = <0x10>;
> + interrupt-parent = <_pinmux>;
> + interrupts = <6 IRQ_TYPE_EDGE_FALLING>;
> + };
> + };
> + };
[..]
> +
> + /* OTG */
> + usb1_phy: phy@1250 {

Please omit this label.

> + status  = "okay";
> + vddcx-supply= <_s3>;
> + v3p3-supply = <_l3>;
> + v1p8-supply = <_l4>;
> + };
> +
> + usb3_phy: phy@1252 {

Please omit this label.

> +

Re: [PATCH v2 1/3] dt-binding: power: Add otg regulator binding

2015-12-09 Thread Bjorn Andersson 
On Wed 09 Dec 06:36 PST 2015, Rob Herring wrote:

> On Wed, Dec 9, 2015 at 6:55 AM, Tim Bird  wrote:
> > On 12/08/2015 08:11 PM, Rob Herring wrote:
> >> On Tue, Dec 08, 2015 at 04:40:16PM -0800, Tim Bird wrote:
> >>> Add a binding for the regulator which controls the OTG chargepath switch.
> >>> The OTG switch gets its power from pm8941_5vs1, and that should be
> >>> expressed as a usb-otg-in-supply property in the DT node for the
> >>> charger driver.  The regulator name is "otg".
> 
> [...]
> 
> >>> +child nodes:
> >>> +- otg:
> >>> +  Usage: optional
> >>> +  Description: This node defines a regulator used to control the 
> >>> direction
> >>> +   of VBUS voltage - specifically: whether to supply voltage
> >>> +   to VBUS for host mode operation of the OTG port, or allow
> >>> +   input voltage from external VBUS for charging.  In the
> >>> +   hardware, the supply for this regulator comes from
> >>> +   usb-otg-in-supply.
> >>
> >> Doesn't this regulator need to have a name defined?
> >
> > I'm not sure what you mean.  The regulator name is "otg", defined by the DT 
> > node
> > name. The code requires that the DT node name be "otg", and defines a 
> > regulator
> > with the same name.
> >
> > As far as I know, you have to define a DT label for the node, in order
> > to reference this regulator with a phandle.  Is that what you are referring 
> > to?
> > I usually use "chg_otg" as the label.  Are you asking that this be reflected
> > in the example?
> 
> You need a regulator-name property. Also, should should define valid
> values for regulator-min-microvolt and regulator-max-microvolt.
> 

The regulator has a name, derived from the node name, and this is
significant. If the developer wants an additional human readable name
for some reason they can use the optional regulator-name property.

The regulator is a simple switch and as such inherits voltage properties
from its supply. It should therefor not have any specified voltage
range.

> Thinking about this some more, the node name should be generic, so
> just "regulator". The label does not need to be generic.
> 

The name of the node is significant, as it's used for matching the
regulator to an implementation.

Regards,
Bjorn
--
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: [RFC][PATCH] misc: Introduce reboot_reason driver

2015-12-08 Thread Bjorn Andersson 
On Tue 08 Dec 13:29 PST 2015, John Stultz wrote:

> This patch adds a basic driver to allow for commands like
> "reboot bootloader" and "reboot recovery" to communicate this
> reboot-reason to the bootloader.
> 
> This is commonly done on Android devices, in order to reboot
> the device into fastboot or recovery mode. It also supports
> custom OEM specific commands, via "reboot oem-".
> 
> This driver pulls the phys memory address from DT as well as
> the magic reason values that are written to the address for
> each mode.
> 
> For an example, this patch also adds the DT support for
> the nexus7 device via its dts (which is not yet upstream).
> 
> Thoughts and feedback would be appreciated!
> 

Good to see some work on this, I want it too :)

I do however think this is Qualcomm specific in its implementation, so
adding Andy and linux-arm-msm.

[..]
> diff --git a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts 
> b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> index 5183d18..ee5dcb7 100644
> --- a/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> +++ b/arch/arm/boot/dts/qcom-apq8064-nexus7-flo.dts
> @@ -282,6 +282,15 @@
>   };
>   };
>  
> + reboot_reason: reboot_reason@2a03f65c {
> + compatible  = "reboot_reason";
> + reg = <0x2A03F65C 0x4>;
> + reason,none = <0x77665501>;
> + reason,bootloader   = <0x77665500>;
> + reason,recovery = <0x77665502>;
> + reason,oem  = <0x6f656d00>;
> + };
> +

This address refers to IMEM, which is shared with a number of other
uses. So I think we should have a simple-mfd (and syscon) with this
within.


I like the fact that you don't hard code the magics in the
implementation, as I've seen additions from multiple places - so perhaps
it should be made even more flexible.

OMAP seems to use strings here instead of magics, but the delivery
mechanism looks to be the same. But I think of this as Qualcomm
specific.

>   gpio-keys {
>   compatible = "gpio-keys";
>   power {
[..]
> diff --git a/drivers/misc/reboot_reason.c b/drivers/misc/reboot_reason.c
[..]
> +
> +static int reboot_reason(struct notifier_block *nb, unsigned long action,
> + void *data)
> +{
> + char *cmd = (char *)data;
> + long reason = reasons[NONE];
> +
> + if (!reboot_reason_addr)
> + return NOTIFY_DONE;
> +
> + if (cmd != NULL) {
> + if (!strncmp(cmd, "bootloader", 10))
> + reason = reasons[BOOTLOADER];
> + else if (!strncmp(cmd, "recovery", 8))
> + reason = reasons[RECOVERY];
> + else if (!strncmp(cmd, "oem-", 4)) {
> + unsigned long code;
> +
> + if (!kstrtoul(cmd+4, 0, ))
> + reason = reasons[OEM] | (code & 0xff);
> + }
> + }

In the case where we didn't find a match you should write the "normal"
reason here, otherwise I think you will end up in recovery when recovery
issues a reboot (in Android that is).

> +
> + if (reason != -1)
> + writel(reason, reboot_reason_addr);
> + return NOTIFY_DONE;
> +}
> +
> +static int reboot_reason_probe(struct platform_device *pdev)
> +{
> + struct resource *res;
> + u32 val;
> + int i;
> +
> + /* initialize the reasons */
> + for (i = 0; i < MAX_REASONS; i++)
> + reasons[i] = -1;
> +
> + /* Try to grab the reason io address */
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + reboot_reason_addr = devm_ioremap_resource(>dev, res);
> + if (IS_ERR(reboot_reason_addr))
> + return PTR_ERR(reboot_reason_addr);
> +

Please acquire this memory from a syscon (preferably the the parent
simple-mfd).

> + /* initialize specified reasons from DT */
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,none", ))
> + reasons[NONE] = val;
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,bootloader", ))
> + reasons[BOOTLOADER] = val;
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,recovery", ))
> + reasons[RECOVERY] = val;
> + if (!of_property_read_u32(pdev->dev.of_node, "reason,oem", ))
> + reasons[OEM] = val;

I would like for this to be less hard coded.

> +
> + /* Install the notifier */
> + restart_nb.notifier_call = reboot_reason;
> + restart_nb.priority = 256;
> + if (register_restart_handler(_nb)) {
> + dev_err(>dev,
> + "failed to setup restart handler.\n");
> + }
> + return 0;
> +}
> +

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to

Re: [RFC][PATCH] misc: Introduce reboot_reason driver

2015-12-08 Thread Bjorn Andersson 
On Tue 08 Dec 13:52 PST 2015, Arnd Bergmann wrote:

> On Tuesday 08 December 2015 13:29:22 John Stultz wrote:
> 
[..]
> > +static int reboot_reason(struct notifier_block *nb, unsigned long action,
> > +   void *data)
> > +{
> > +   char *cmd = (char *)data;
> > +   long reason = reasons[NONE];
> > +
> > +   if (!reboot_reason_addr)
> > +   return NOTIFY_DONE;
> > +
> > +   if (cmd != NULL) {
> > +   if (!strncmp(cmd, "bootloader", 10))
> > +   reason = reasons[BOOTLOADER];
> > +   else if (!strncmp(cmd, "recovery", 8))
> > +   reason = reasons[RECOVERY];
> > +   else if (!strncmp(cmd, "oem-", 4)) {
> > +   unsigned long code;
> > +
> > +   if (!kstrtoul(cmd+4, 0, ))
> > +   reason = reasons[OEM] | (code & 0xff);
> > +   }
> > +   }
> > +
> > +   if (reason != -1)
> > +   writel(reason, reboot_reason_addr);
> > +   return NOTIFY_DONE;
> > +}
> 
> Will this reboot the machine?
> 

It will store the magic in IMEM, that is then read by the boot loader
after the reboot to make it trigger alternative boot flows - e.g. the
recovery/update path or enter fastboot mode.

> > +   /* Install the notifier */
> > +   restart_nb.notifier_call = reboot_reason;
> > +   restart_nb.priority = 256;
> > +   if (register_restart_handler(_nb)) {
> 
> If not, you should use register_reboot_notifier() rather than
> register_restart_handler(). The former gets called to do something
> just before rebooting, while the latter attempts to actually reboot
> the machine.
> 

It should be a reboot_notifier, sorry for missing this in my answer.

> > +static int __init reboot_reason_init(void)
> > +{
> > +   return platform_driver_register(_reason_driver);
> > +}
> > +arch_initcall(reboot_reason_init);
> 
> Why this early? If it can be a normal device_initcall, you can use
> module_platform_driver().
> 

Not represented in this patch is that several Android vendors uses this
mechanism to communicate a panic() to the boot loader; to let the system
enter some sort of memory dump state.

Adding support for that would be convenient and mandate the early,
otherwise it's just userspace that will trigger this so module would be
fine.

Regards,
Bjorn
--
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: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

2015-12-03 Thread Bjorn Andersson 
On Thu, Dec 3, 2015 at 1:12 PM, Arnd Bergmann  wrote:
> On Thursday 03 December 2015 17:28:30 Lee Jones wrote:
>> >
>> > Ah, interesting. I haven't tried myself, and just tried to read the
>> > code. Maybe glibc already catches zero-length writes before it gets
>> > into the kernel, or I just missed the part of the syscall that checks
>> > for this.
>>
>> Glibc is responsible indeed:
>>
>>   http://osxr.org/glibc/source/io/write.c
>
> Ok, so an attacker can force the stack overflow by calling
> syscall(__NR_write, fd, p, 0) if that has any potential value,
> but normal users won't hit this case.
>

It seems glibc might be the only libc implementation with this protection.

Regards,
Bjorn
--
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 v2] libfdt: check for potential overrun in _fdt_splice()

2015-12-01 Thread Bjorn Andersson 
From: Courtney Cavin <courtney.ca...@sonymobile.com>

This patch catches the conditions where:
 - 'splicepoint' is set to a point outside of [ fdt, fdt_totalsize(fdt) )
 - 'newlen' is negative, or 'splicepoint' plus 'newlen' results in overflow

Either of these cases can be caused by math which overflows in calling
functions, or by sizes specified through dynamic means.

Signed-off-by: Courtney Cavin <courtney.ca...@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 libfdt/fdt_rw.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libfdt/fdt_rw.c b/libfdt/fdt_rw.c
index 70adec6c371b..8be02b1f68f3 100644
--- a/libfdt/fdt_rw.c
+++ b/libfdt/fdt_rw.c
@@ -101,6 +101,8 @@ static int _fdt_splice(void *fdt, void *splicepoint, int 
oldlen, int newlen)
 
if (((p + oldlen) < p) || ((p + oldlen) > end))
return -FDT_ERR_BADOFFSET;
+   if ((p < (char *)fdt) || ((end - oldlen + newlen) < (char *)fdt))
+   return -FDT_ERR_BADOFFSET;
if ((end - oldlen + newlen) > ((char *)fdt + fdt_totalsize(fdt)))
return -FDT_ERR_NOSPACE;
memmove(p + newlen, p + oldlen, end - p - oldlen);
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe devicetree-compiler" 
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/7] ARM: dts: qcom: msm8974-honami: Define pinctrl state for blsp_uart2

2015-11-30 Thread Bjorn Andersson 
On Mon, Nov 30, 2015 at 11:23 AM, Kevin Hilman <khil...@kernel.org> wrote:
> On Tue, Oct 20, 2015 at 9:57 PM, Bjorn Andersson
> <bjorn.anders...@sonymobile.com> wrote:
>> Make sure the blsp1_uart2 pins are in the correct state for the uart.
>>
>> Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
>
> kernelci.org has been detecting boot failures on my z1 since
> next-20151120[1] and I finally got around to bisecting, which pointed
> to this patch which is in next in the for of commit 14cd83b824aa ARM:
> dts: qcom: msm8974-honami: Define pinctrl state for blsp_uart2
>
> That commit doesn't revert cleanly on top of next-20151130, but
> manually removing the stuff added in this patch, next-20151130 boots
> fine on the z1.
>
> Kevin
>
> [1] 
> http://kernelci.org/boot/qcom-msm8974-sony-xperia-honami/job/next/kernel/next-20151127/defconfig/multi_v7_defconfig/lab/lab-khilman/?_id=5658061359b5140196b5fd2f

Thanks Kevin,

I did see these too. But at the same time, as far as I can see, the
qcom_defconfig boots just fine - indicating that this particular
commit would not be the cause.

I'll fire up some builds to figure out what's going on.


PS. I believe earlycon would be more helpful than earlyprintk on the
multi platform build command line...

Regards,
Bjorn
--
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: [RESEND v4 2/6] remoteproc: debugfs: Add ability to boot remote processor using debugfs

2015-11-27 Thread Bjorn Andersson 
On Tue, Nov 24, 2015 at 5:14 AM, Lee Jones <lee.jo...@linaro.org> wrote:
> This functionality is especially useful during the testing phase.  When
> used in conjunction with Mailbox's Test Framework we can trivially conduct
> end-to-end testing i.e. boot co-processor, send and receive messages to
> the co-processor, then shut it down again (repeat as required).
>

I want this too!

> Signed-off-by: Ludovic Barre <ludovic.ba...@st.com>
> Signed-off-by: Lee Jones <lee.jo...@linaro.org>
> ---
>  drivers/remoteproc/remoteproc_debugfs.c | 34 
> +
>  1 file changed, 34 insertions(+)
>
> diff --git a/drivers/remoteproc/remoteproc_debugfs.c 
> b/drivers/remoteproc/remoteproc_debugfs.c
> index 9d30809..8113c18 100644
> --- a/drivers/remoteproc/remoteproc_debugfs.c
> +++ b/drivers/remoteproc/remoteproc_debugfs.c
> @@ -88,8 +88,42 @@ static ssize_t rproc_state_read(struct file *filp, char 
> __user *userbuf,
> return simple_read_from_buffer(userbuf, count, ppos, buf, i);
>  }
>
> +static ssize_t rproc_state_write(struct file *filp, const char __user 
> *userbuf,
> +size_t count, loff_t *ppos)
> +{
> +   struct rproc *rproc = filp->private_data;
> +   char buf[10];
> +   int ret;
> +
> +   if (count > sizeof(buf))
> +   return count;
> +
> +   ret = copy_from_user(buf, userbuf, count);
> +   if (ret)
> +   return -EFAULT;
> +
> +   if (buf[count - 1] == '\n')
> +   buf[count - 1] = '\0';

I believe you can get here with count = 0.

> +
> +   if (!strncmp(buf, "start", count)) {
> +   ret = rproc_boot(rproc);
> +   if (ret) {
> +   dev_err(>dev, "Boot failed: %d\n", ret);
> +   return ret;
> +   }
> +   } else if (!strncmp(buf, "stop", count)) {
> +   rproc_shutdown(rproc);
> +   } else {
> +   dev_err(>dev, "Unrecognised option: %s\n", buf);

Unrecognized

> +   return -EINVAL;
> +   }
> +
> +   return count;
> +}
> +
>  static const struct file_operations rproc_state_ops = {
> .read = rproc_state_read,
> +   .write = rproc_state_write,
> .open = simple_open,
> .llseek = generic_file_llseek,
>  };

Part of these nits

Acked-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Regards,
Bjorn
--
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: qcom: Add generic PMIC gpio/MPP compat strings

2015-11-23 Thread Bjorn Andersson 
On Fri 20 Nov 17:49 PST 2015, Stephen Boyd wrote:

> Add the generic compatible strings for the PMIC gpio and MPP
> modules found on qcom based PMICs.
> 
> Cc: <devicetree@vger.kernel.org>
> Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
> Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> Cc: Rob Herring <r...@kernel.org>
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>

Reviewed-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Regards,
Bjorn
--
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/6] DT: PCI: qcom: Document PCIe devicetree bindings

2015-11-23 Thread Bjorn Andersson 
On Mon 23 Nov 01:29 PST 2015, Stanimir Varbanov wrote:

> From: Stanimir Varbanov 
> 
> Document Qualcomm PCIe driver devicetree bindings.
> 
> Signed-off-by: Stanimir Varbanov 
> Signed-off-by: Stanimir Varbanov 
> ---
>  .../devicetree/bindings/pci/qcom,pcie.txt  |  231 
> 
>  1 file changed, 231 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pci/qcom,pcie.txt
> 
> diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt 
> b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> new file mode 100644
> index ..d7640d45fa31
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt
> @@ -0,0 +1,231 @@
> +* Qualcomm PCI express root complex
> +
> +- compatible:
> + Usage: required
> + Value type: 
> + Definition: Value shall include
> + - "qcom,pcie-v0" for apq/ipq8064
> + - "qcom,pcie-v1" for apq8084

Do you know if we have the same v1 of this block in 8994?

[..]
> +- clock-names:
> + Usage: required
> + Value type: 
> + Definition: Should contain the following entries
> + * should be populated for v0 and v1
> + - "iface"  Configuration AHB clock
> +
> + * should be populated for v0
> + - "core"   Clocks the pcie hw block
> + - "phy"Clocks the pcie PHY block
> +
> + * should be populated for v1
> + - "aux"Auxiliary (AUX) clock
> + - "bus_master" Master AXI clock
> + - "bus_slave"  Slave AXI clock

You have white spaces among your tabs here.

[..]
> +- -supply:
> + Usage: required
> + Value type: 
> + Definition: List of phandles to the power supply regulator(s)
> + * should be populated for v0 and v1
> + - "vdda"core analog power supply
> +
> + * should be populated for v0
> + - "vdda_phy"analog power supply for PHY
> + - "vdda_refclk" analog power supply for IC which 
> generate
> + reference clock

Exploding these into 3 different property descriptions would make it
easier to read, and you can say "required for v0" for the latter
two and simply "required" on the vdda.

[..]
> +- -gpio:
> + Usage: optional
> + Value type: 
> + Definition: List of phandle and gpio specifier pairs. Should contain
> + - "perst"  PCIe endpoint reset signal line
> + - "pewake" PCIe endpoint wake signal line

This property should be pluralized, i.e. it's -gpios.

Are these identifiers coming from some data sheet? Or could we simply
name them "reset" and "wakeup"?

> +
> +- pinctrl-0:
> + Usage: required
> + Value type: 
> + Definition: List of phandles pointing at a pin(s) configuration

This is not required and as it's a property applicable to all devices we
normally don't mention them.

> +
> +- pinctrl-names
> + Usage: required
> + Value type: 
> + Definition: List of names of pinctrl-0 state
> +

dito

Regards,
Bjorn
--
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: [RFC/PATCH] pinctrl: qcom: Add generic ssbi and spmi GPIO/MPP bindings

2015-11-23 Thread Bjorn Andersson 
On Tue 17 Nov 17:00 PST 2015, Stephen Boyd wrote:

> The drivers don't really need to know which PMIC they're for, so
> make a generic binding for them. This alleviates us from updating
> the drivers every time a new PMIC comes out. It's still
> recommended that we update the binding with new PMIC models and
> always specify the specific model for the MPPs and gpios before
> the generic compatible string in devicetree, but this at least
> cuts down on adding more and more compatible strings to the
> drivers until we actually need them.
> 
> Cc: <devicetree@vger.kernel.org>
> Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
> Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> ---
> 

I must say that when it comes to writing dts files I much prefer the msm
way of denoting functions over the pmic one. But because of that
decision this makes perfect sense!

Reviewed-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Regards,
Bjorn
--
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] pinctrl: qcom: Add msm8996 pinctrl driver

2015-11-23 Thread Bjorn Andersson 
On Tue 17 Nov 16:35 PST 2015, Stephen Boyd wrote:

> From: Joonwoo Park <joonw...@codeaurora.org>
> 
> Add initial pinctrl driver to support pin configuration with
> pinctrl framework for msm8996.
> 
> Cc: <devicetree@vger.kernel.org>
> Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> Signed-off-by: Joonwoo Park <joonw...@codeaurora.org>
> [sb...@codeaurora.org: Remove duplicate entries and enums]
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> ---

Acked-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Regards,
Bjorn
--
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/2] pinctrl: qcom: spmi-mpp: Add pm8994 mpp support

2015-11-23 Thread Bjorn Andersson 
On Tue 17 Nov 16:52 PST 2015, Stephen Boyd wrote:

> Update the driver and binding for pm8994-mpp devices.
> 
> Cc: <devicetree@vger.kernel.org>
> Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
> Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>
> ---

Acked-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Regards,
Bjorn
--
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] pinctrl: qcom: spmi-gpio: Add pm8994 gpio support

2015-11-23 Thread Bjorn Andersson 
On Tue 17 Nov 16:52 PST 2015, Stephen Boyd wrote:

> Update the binding and driver for pm8994-gpio devices.
> 
> Cc: <devicetree@vger.kernel.org>
> Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
> Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> Signed-off-by: Stephen Boyd <sb...@codeaurora.org>

Acked-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Regards,
Bjorn
--
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: qcom: msm8974: Disable wled and move it to honami

2015-11-23 Thread Bjorn Andersson 
The properties specified in the wled node could harm connected hardware,
so move the properties to Honami and disable the platform node.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts | 13 +
 arch/arm/boot/dts/qcom-pm8941.dtsi|  9 ++---
 2 files changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index 37741725b7bd..a0398b69f4f2 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -403,4 +403,17 @@
qcom,vset-millivolts = <3000>;
};
};
+
+   pm8941@1 {
+   wled@d800 {
+   status = "ok";
+
+   qcom,cs-out;
+   qcom,current-limit = <20>;
+   qcom,current-boost-limit = <805>;
+   qcom,switching-freq = <1600>;
+   qcom,ovp = <29>;
+   qcom,num-strings = <2>;
+   };
+   };
 };
diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi 
b/arch/arm/boot/dts/qcom-pm8941.dtsi
index b0d443999fcc..b73fee57cf18 100644
--- a/arch/arm/boot/dts/qcom-pm8941.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
@@ -159,17 +159,12 @@
#address-cells = <1>;
#size-cells = <0>;
 
-   wled@d800 {
+   pm8941_wled: wled@d800 {
compatible = "qcom,pm8941-wled";
reg = <0xd800 0x100>;
label = "backlight";
 
-   qcom,cs-out;
-   qcom,current-limit = <20>;
-   qcom,current-boost-limit = <805>;
-   qcom,switching-freq = <1600>;
-   qcom,ovp = <29>;
-   qcom,num-strings = <2>;
+   status = "disabled";
};
};
 };
-- 
2.4.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 v4 2/3] usb: phy: msm: fix connect/disconnect bug for dragonboard OTG port

2015-11-21 Thread Bjorn Andersson 
On Fri 20 Nov 15:47 PST 2015, Tim Bird wrote:

> Add support for async_irq to wake up driver from low power mode.
> Without this, the power management code never calls resume.
> Remove a spurious interrupt enable in the driver resume function.
> 
> Signed-off-by: Tim Bird 

Sorry Tim for missing these things and not jumping into the discussion
before.

> ---
>  drivers/usb/phy/phy-msm-usb.c | 17 -
>  include/linux/usb/msm_hsusb.h |  1 +
>  2 files changed, 17 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/usb/phy/phy-msm-usb.c b/drivers/usb/phy/phy-msm-usb.c
[..]
> @@ -1732,6 +1731,12 @@ static int msm_otg_probe(struct platform_device *pdev)
>   return motg->irq;
>   }
>  
> + motg->async_irq = platform_get_irq_byname(pdev, "async");
> + if (motg->async_irq < 0) {
> + dev_err(>dev, "platform_get_irq for async irq failed\n");

This is optional, so I must object to this being dev_err(). Except for
development purposes logging this is useless, can't we make it a
dev_dbg?

> + motg->async_irq = 0;
> + }
> +
[..]
> diff --git a/include/linux/usb/msm_hsusb.h b/include/linux/usb/msm_hsusb.h
> index 8c8f685..08c67a3 100644
> --- a/include/linux/usb/msm_hsusb.h
> +++ b/include/linux/usb/msm_hsusb.h
> @@ -164,6 +164,7 @@ struct msm_otg {
>   struct usb_phy phy;
>   struct msm_otg_platform_data *pdata;
>   int irq;
> + int async_irq;

This should be added to the kerneldoc above.

>   struct clk *clk;
>   struct clk *pclk;
>   struct clk *core_clk;

Regards,
Bjorn
--
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 4/5] PCI: qcom: Add Qualcomm PCIe controller driver

2015-11-06 Thread Bjorn Andersson 
On Mon 04 May 05:42 PDT 2015, Stanimir Varbanov wrote:

> The PCIe driver reuse the Designware common code for host
> and MSI initialization, and also program the Qualcomm
> application specific registers.
> 

I want to get the ethernet on the ifc6410 running and this seems like
the last patchset for the PCIe.

> Signed-off-by: Stanimir Varbanov 
[..]
> diff --git a/drivers/pci/host/pcie-qcom.c b/drivers/pci/host/pcie-qcom.c
> new file mode 100644
> index 000..4f083c6
> --- /dev/null
> +++ b/drivers/pci/host/pcie-qcom.c
> @@ -0,0 +1,677 @@
> +/*
> + * Copyright (c) 2014, The Linux Foundation. All rights reserved.

Bump the year, it's the future now :)

> + *
> + * 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.
> + */
> +
[..]
> +
> +struct qcom_pcie {
> + struct pcie_port pp;
> + struct device *dev;

You already have this device pointer in pp->dev.

> + union pcie_resources res;
> + void __iomem *parf;
> + void __iomem *dbi;
> + void __iomem *elbi;
> + struct phy *phy;
> + struct gpio_desc *reset;
> + unsigned int version;
> +};
> +
> +#define to_qcom_pcie(x)  container_of(x, struct qcom_pcie, pp)
> +
> +static inline void
> +writel_masked(void __iomem *addr, u32 clear_mask, u32 set_mask)
> +{
> + u32 val = readl(addr);
> +
> + val &= ~clear_mask;
> + val |= set_mask;
> + writel(val, addr);
> +}

There are no case where you do clear and set, so I would like that you
just inline this function where you need it. It adds 2 extra lines at a
few places, but a lot of clarity.

> +
> +static void qcom_ep_reset_assert_deassert(struct qcom_pcie *pcie, int assert)
> +{
> + int val, active_low;
> +
> + if (IS_ERR_OR_NULL(pcie->reset))
> + return;

This will be NULL or valid here, never ERR. So it's fine to call
gpiod_set_value() with this pointer without the check.

> +
> + active_low = gpiod_is_active_low(pcie->reset);
> +

gpiod_set_value() checks for FLAG_ACTIVE_LOW and will invert the value
first thing. So you do not need to do this manually.

> + if (assert)
> + val = !!active_low;
> + else
> + val = !active_low;
> +
> + gpiod_set_value(pcie->reset, val);
> +
> + usleep_range(PERST_DELAY_MIN_US, PERST_DELAY_MAX_US);

This doesn't seem to be called in a hot path, so you should be able to
simply msleep(1) here.

> +}
> +
> +static void qcom_ep_reset_assert(struct qcom_pcie *pcie)
> +{
> + qcom_ep_reset_assert_deassert(pcie, 1);

If we're down to this function just being a gpiod_set_value() and a
sleep we can inline it here instead of having this proxy function.

> +}
> +
> +static void qcom_ep_reset_deassert(struct qcom_pcie *pcie)
> +{
> + qcom_ep_reset_assert_deassert(pcie, 0);

Same here.

> +}
> +
> +static irqreturn_t qcom_pcie_msi_irq_handler(int irq, void *arg)
> +{
> + struct pcie_port *pp = arg;
> +
> + return dw_handle_msi_irq(pp);
> +}
> +
> +static int qcom_pcie_link_up(struct pcie_port *pp)
> +{
> + struct qcom_pcie *pcie = to_qcom_pcie(pp);
> + u32 val = readl(pcie->dbi + PCIE20_CAP_LINKCTRLSTATUS);
> +
> + return val & BIT(29) ? 1 : 0;

return !!(val & BIT(29));

Do we know what this bit 29 is?

> +}
> +
[..]
> +
> +static int qcom_pcie_get_resources_v1(struct qcom_pcie *pcie)
> +{
> + struct qcom_pcie_resources_v1 *res = >res.v1;
> + struct device *dev = pcie->dev;
> +
> + res->vdda = devm_regulator_get(dev, "vdda");
> + if (IS_ERR(res->vdda))
> + return PTR_ERR(res->vdda);
> +
> + res->iface = devm_clk_get(dev, "iface");
> + if (IS_ERR(res->iface))
> + return PTR_ERR(res->iface);
> +
> + res->aux = devm_clk_get(dev, "aux");
> + if (IS_ERR(res->aux) && PTR_ERR(res->aux) == -EPROBE_DEFER)

PTR_ERR() == x implies IS_ERR(), so you don't need both.

> + return -EPROBE_DEFER;
> + else if (IS_ERR(res->aux))
> + res->aux = NULL;
> +
> + res->master_bus = devm_clk_get(dev, "master_bus");
> + if (IS_ERR(res->master_bus))
> + return PTR_ERR(res->master_bus);
> +
> + res->slave_bus = devm_clk_get(dev, "slave_bus");
> + if (IS_ERR(res->slave_bus))
> + return PTR_ERR(res->slave_bus);
> +
> + res->core = devm_reset_control_get(dev, "core");
> + if (IS_ERR(res->core))
> + return PTR_ERR(res->core);
> +
> + return 0;
> +}
> +
> +static int qcom_pcie_enable_link_training(struct pcie_port *pp)
> +{
> + struct qcom_pcie *pcie = to_qcom_pcie(pp);
> + struct device

[PATCH v2 1/2] drm/panel: Add Sharp LS043T1LE01 panel binding documentation

2015-10-30 Thread Bjorn Andersson 
From: Werner Johansson <werner.johans...@sonymobile.com>

Signed-off-by: Werner Johansson <werner.johans...@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---

Change since v1:
- Dropped -vid suffix from compatible

 .../bindings/display/panel/sharp,ls043t1le01.txt   | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt

diff --git 
a/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt 
b/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt
new file mode 100644
index ..b3d4e073930a
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/sharp,ls043t1le01.txt
@@ -0,0 +1,22 @@
+Sharp Microelectronics 4.3" qHD TFT LCD panel
+
+Required properties:
+- compatible: should be "sharp,ls043t1le01-qhd"
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+- reset-gpios: a GPIO spec for the reset pin
+
+Example:
+
+   mdss_dsi@fd922800 {
+   panel@0 {
+   compatible = "sharp,ls043t1le01-qhd";
+   reg = <0>;
+   avdd-supply = <_l22>;
+   backlight = <_wled>;
+   reset-gpios = <_gpios 19 GPIO_ACTIVE_HIGH>;
+   };
+   };
-- 
2.4.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 v2 1/3] devicetree: mfd: Add binding for the TI LM3533

2015-10-30 Thread Bjorn Andersson 
On Fri 30 Oct 13:18 PDT 2015, Rob Herring wrote:

> On Fri, Oct 30, 2015 at 2:41 PM, Bjorn Andersson
> <bjorn.anders...@sonymobile.com> wrote:
> > On Fri 30 Oct 11:42 PDT 2015, Lee Jones wrote:
> >
> > Rob, please see the discussion regarding ti,boost-freq-khz below. Should
> > we both specify unit at the same time as we use standard units? (This is
> > not the first time I have to change this back and forth)
> >
> >> On Tue, 27 Oct 2015, Bjorn Andersson wrote:
> >>
[..]
> > The ti,boost-low-freq from the bq25890 binding is the only other
> > property I can find that describes the same thing. So I'm not sure I
> > follow you here.
> >
> >> Perhaps we need to create a set of generic bindings.
> >>
> >> Also, we usually measure DT bindings in HZ, not kHz.
> 
> Surprisingly, there are not enough examples to draw much conclusion.
> 
> > I thought we had defined frequencies to be in HZ and HZ only, but then
> > Rob's comment that I need to actually specify the unit doesn't make any
> > sense.
> 
> I don't think we decided, but let's decide now. Go with Hz.
> 

+1

> Really, I first prefer the property name has units and second having
> standardized units. But if there is a common property without units, I
> prefer that even more.
> 

You can find this property in a variety of hardware, but I don't think
it would make much sense to define this single property in a common
place today.

This seems to be the first case where we specify the unit on one of
these properties though.

> > Do we want these properties in a standard unit or do we want them
> > specifying the unit? Having both seems excessive.
> 
> You mean "freq" would imply the units? No, we want the actual units in
> the property.
> 

You're right, frequency can be measured in other units than Hz, I can't
think of one that would be applicable here though.

Either way, I'll slap on a unit to the property name - Hz that is...

Thanks for your input.

Regards,
Bjorn
--
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 1/3] devicetree: mfd: Add binding for the TI LM3533

2015-10-30 Thread Bjorn Andersson 
Add the binding for the Texas Instruments LM3533 lighting power
solution.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---

Changes since v2:
- Drop vendor prefix of vendor properties
- Specify unit of various properties
- Fix reference paths

Changes since v1:
- Added unit to boost-freq and als-resistance (as the frequency now comes with
  a unit specifier I changed it to be expressed in kHz)

 Documentation/devicetree/bindings/mfd/lm3533.txt | 184 +++
 1 file changed, 184 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt

diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt 
b/Documentation/devicetree/bindings/mfd/lm3533.txt
new file mode 100644
index ..963cee153a4d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
@@ -0,0 +1,184 @@
+Texas Instruments LM3533 binding
+
+This binding describes the Texas Instruments LM3533, a lighting power solution
+for smartphone handsets. The common properties are described directly in the
+node, while each individual component are described in an optional subnode.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be:
+   "ti,lm3533"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: i2c address of the LM3533 chip
+
+- als-supply:
+   Usage: optional
+   Value type: 
+   Definition: reference to regulator powering the V_als input; as
+   specified in "../regulator/regulator.txt"
+
+- hwen-gpios:
+   Usage: required
+   Value type: 
+   Definition: reference to gpio pin connected to the HWEN input; as
+   specified in "../gpio/gpio.txt"
+
+- ti,boost-freq-hz:
+   Usage: required
+   Value type: 
+   Definition: switch-frequency of the boost converter, must be either:
+   50 or 100
+
+- ti,boost-ovp-mv:
+   Usage: required
+   Value type: 
+   Definition: over-voltage protection limit, in mV. Must be one of:
+   16000, 24000, 32000 or 4
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 0
+
+= ALS SUBNODE
+The ambient light sensor subnode must be named "als", it carries the light
+sensor related properties.
+
+- ti,als-resistance-ohm:
+   Usage: required (unless ti,pwm-mode is specified)
+   Value type: 
+   Definition: specifies the resistor value (R_als), in Ohm. Valid values
+   ranges from 20 to 1574 Ohm.
+
+- ti,pwm-mode:
+   Usage: optional
+   Value type: 
+   Definition: specifies, if present, that the als should operate in PWM
+   mode - rather than analog mode
+
+= BACKLIGHT NODES
+Backlight subnodes must be named "backlight", they carry the backlight related
+properties.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies which of the two backlights this node corresponds
+   to
+
+- default-brightness:
+   Usage: optional
+   Value type: <32>
+   Definition: specifies the default brightness for the backlight, in
+   units of brightness [0-255]
+
+- label:
+   Usage: required
+   Value type: 
+   Definition: specifies a name of this backlight
+
+- led-max-microamp:
+   Usage: required
+   Value type: 
+   Definition: specifies the max current for this backlight, in uA, as
+   described in "../leds/common.txt"
+
+- ti,pwm-zones:
+   Usage: optional
+   Value type: 
+   Definition: lists the ALS zones to be PWM controlled for this backlight,
+   the values in the list are in the range [0 - 4]
+
+= LED NODES
+LED subnodes must be named "led", they carry the LED related properties.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies which of the four LEDs this node corresponds to
+
+- linux,default-trigger:
+   Usage: optional
+   Value type: 
+   Definition: specifies the default trigger for the LED, as described in
+   "../leds/common.txt"
+
+- label:
+   Usage: required
+   Value type: 
+   Definition: specifies a name of this LED, as described in
+   "../leds/common.txt"
+
+- led-max-microamp:
+   Usage: required
+   Value type: 
+   Definition: specifies the max current for this LED, in uA, as described
+   in "../leds/common.txt"
+
+- ti,pwm-zones:
+   Usage: optional
+   Value type: 
+   Definition: lists the ALS zones to be PWM controlled for this LED, the
+   values in the list are in the range [0 - 4]
+
+= EXAMPLE
+
+i2c@1246 {
+   compatible = "

Re: [PATCH v2 1/3] devicetree: mfd: Add binding for the TI LM3533

2015-10-30 Thread Bjorn Andersson 
On Fri 30 Oct 11:42 PDT 2015, Lee Jones wrote:

Rob, please see the discussion regarding ti,boost-freq-khz below. Should
we both specify unit at the same time as we use standard units? (This is
not the first time I have to change this back and forth)

> On Tue, 27 Oct 2015, Bjorn Andersson wrote:
> 
[..]
> > +- ti,hwen-gpios:
> > +   Usage: required
> > +   Value type: 
> > +   Definition: reference to gpio pin connected to the HWEN input; as
> > +   specified in "gpio/gpio.txt"
> 
> Why have you made this a vendor binding?
> 
> *-gpios is a generic property.
> 

Because the hwen gpio is a ti lm3533 specific thing, but I get what
you're saying. Will drop the prefix.

> > +- ti,als-supply:
> > +   Usage: optional
> > +   Value type: 
> > +   Definition: reference to regulator powering the V_als input; as
> > +   specified in "regulator/regulator.txt"
> 
> Same goes for *-supply.
> 

Same here

> > +- ti,boost-freq-khz:
> > +   Usage: required
> > +   Value type: 
> > +   Definition: switch-frequency of the boost converter, must be either:
> > +   500 or 1000
> 
> Quite a few vendors are using 'boost' now.
> 

The ti,boost-low-freq from the bq25890 binding is the only other
property I can find that describes the same thing. So I'm not sure I
follow you here.

> Perhaps we need to create a set of generic bindings.
> 
> Also, we usually measure DT bindings in HZ, not kHz.
> 

I thought we had defined frequencies to be in HZ and HZ only, but then
Rob's comment that I need to actually specify the unit doesn't make any
sense.

Do we want these properties in a standard unit or do we want them
specifying the unit? Having both seems excessive.

> > +- ti,boost-ovp:
> > +   Usage: required
> > +   Value type: 
> > +   Definition: over voltage protection limit, must be one of: 16, 24, 32
> > +   or 40
> 
> Is this in volts?  If so, it should be microvolts.
> 

Okay, will update.

[..]
> > += ALS SUBNODE
> > +The als subnode must be named "als", it carries the als related properties.
> 
> Perfect time to tell us what ALS is/means.
> 

You're right, I'll expand this.

> > +- ti,als-resistance-ohm:
> > +   Usage: required (unless ti,pwm-mode is specified)
> > +   Value type: 
> > +   Definition: specifies the resistor value (R_als), in Ohm. Valid values
> > +   ranges from 200kOhm to 1574Ohm.
> 
> Might be worth specifying the values which you are actually going to
> use here i.e. "200kOhm" is not a valid u32.
> 

I'll drop the units.

> > +- ti,pwm-mode:
> > +   Usage: optional
> > +   Value type: 
> > +   Definition: specifies, if present, that the als should operate in pwm
> 
> Suggest s/pwm/PWM/
> 

OK

[..]
> > +- ti,pwm-zones:
> > +   Usage: optional
> > +   Value type: 
> > +   Definition: lists the ALS zones to be PWM controlled for this backlight,
> > +   the values in the list are in the range [0 - 4]
> > +
> 
> It's usually a good idea to point to where all of the aforementioned
> generic properties are documented.  I personally like the format
> (See: ..//.txt)
> 

OK

> > += LED NODES

Regards,
Bjorn
--
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 v2 1/3] devicetree: mfd: Add binding for the TI LM3533

2015-10-27 Thread Bjorn Andersson 
Add the binding for the Texas Instruments LM3533 lighting power
solution.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---

Changes since v1:
- Added unit to boost-freq and als-resistance (as the frequency now comes with
  a unit specifier I changed it to be expressed in kHz)

 Documentation/devicetree/bindings/mfd/lm3533.txt | 183 +++
 1 file changed, 183 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt

diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt 
b/Documentation/devicetree/bindings/mfd/lm3533.txt
new file mode 100644
index ..399df39ec7e7
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
@@ -0,0 +1,183 @@
+Texas Instruments LM3533 binding
+
+This binding describes the Texas Instruments LM3533, a lighting power solution
+for smartphone handsets. The common properties are described directly in the
+node, while each individual component are described in an optional subnode.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be:
+   "ti,lm3533"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: i2c address of the LM3533 chip
+
+- ti,hwen-gpios:
+   Usage: required
+   Value type: 
+   Definition: reference to gpio pin connected to the HWEN input; as
+   specified in "gpio/gpio.txt"
+
+- ti,als-supply:
+   Usage: optional
+   Value type: 
+   Definition: reference to regulator powering the V_als input; as
+   specified in "regulator/regulator.txt"
+
+- ti,boost-freq-khz:
+   Usage: required
+   Value type: 
+   Definition: switch-frequency of the boost converter, must be either:
+   500 or 1000
+
+- ti,boost-ovp:
+   Usage: required
+   Value type: 
+   Definition: over voltage protection limit, must be one of: 16, 24, 32
+   or 40
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 0
+
+= ALS SUBNODE
+The als subnode must be named "als", it carries the als related properties.
+
+- ti,als-resistance-ohm:
+   Usage: required (unless ti,pwm-mode is specified)
+   Value type: 
+   Definition: specifies the resistor value (R_als), in Ohm. Valid values
+   ranges from 200kOhm to 1574Ohm.
+
+- ti,pwm-mode:
+   Usage: optional
+   Value type: 
+   Definition: specifies, if present, that the als should operate in pwm
+   mode - rather than analog mode
+
+= BACKLIGHT NODES
+Backlight subnodes must be named "backlight", they carry the backlight related
+properties.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies which of the two backlights this node corresponds
+   to
+
+- default-brightness:
+   Usage: optional
+   Value type: <32>
+   Definition: specifies the default brightness for the backlight, in
+   units of brightness [0-255]
+
+- label:
+   Usage: required
+   Value type: 
+   Definition: specifies a name of this backlight
+
+- led-max-microamp:
+   Usage: required
+   Value type: 
+   Definition: specifies the max current for this backlight, in uA, as
+   described in "leds/common.txt"
+
+- ti,pwm-zones:
+   Usage: optional
+   Value type: 
+   Definition: lists the ALS zones to be PWM controlled for this backlight,
+   the values in the list are in the range [0 - 4]
+
+= LED NODES
+LED subnodes must be named "led", they carry the LED related properties.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies which of the four LEDs this node corresponds to
+
+- linux,default-trigger:
+   Usage: optional
+   Value type: 
+   Definition: specifies the default trigger for the LED, as described in
+   "leds/common.txt"
+
+- label:
+   Usage: required
+   Value type: 
+   Definition: specifies a name of this LED, as described in
+   "leds/common.txt"
+
+- led-max-microamp:
+   Usage: required
+   Value type: 
+   Definition: specifies the max current for this LED, in uA, as described
+   in "leds/common.txt"
+
+- ti,pwm-zones:
+   Usage: optional
+   Value type: 
+   Definition: lists the ALS zones to be PWM controlled for this LED, the
+   values in the list are in the range [0 - 4]
+
+= EXAMPLE
+
+i2c@1246 {
+   compatible = "qcom,i2c-qup-v1.1.1";
+   ...
+
+   lm3533@36 {
+   compatible = "ti,lm3533";
+   reg = <0x36>;
+
+   ti,hwen-gpios = <

Re: [PATCH 04/14] devicetree: Add hardware rng entry to qcom-apq8064.dtsi

2015-10-26 Thread Bjorn Andersson 
On Fri 18 Sep 05:31 PDT 2015, Srinivas Kandagatla wrote:

> From: John Stultz <john.stu...@linaro.org>
> 
> Add devicetree data to add support for hw_rng support
> to the apq8064 dts.
> 
> Tested on the Nexus7 (2013).
> 
> Cc: Kumar Gala <ga...@codeaurora.org>
> Cc: Stephen Boyd <sb...@codeaurora.org>
> Cc: Srinivas Kandagatla <srinivas.kandaga...@linaro.org>
> Cc: devicetree@vger.kernel.org

Reviewed-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

> Reviewed-by: Stephen Boyd <sb...@codeaurora.org>
> Signed-off-by: John Stultz <john.stu...@linaro.org>

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

[RESEND PATCH v2] backlight: pm8941-wled: Add default-brightness property

2015-10-26 Thread Bjorn Andersson 
Default the brightness to 2048 and add possibility to override this in
device tree.

Suggested-by: Rob Clark <robdcl...@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---

Resend of v2, with updated backlight dt binding location.

 Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt | 2 ++
 drivers/video/backlight/pm8941-wled.c| 8 
 2 files changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt 
b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
index 424f8444a6cd..e5b294dafc58 100644
--- a/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/leds/backlight/pm8941-wled.txt
@@ -5,6 +5,8 @@ Required properties:
 - reg: slave address
 
 Optional properties:
+- default-brightness: brightness value on boot, value from: 0-4095
+   default: 2048
 - label: The name of the backlight device
 - qcom,cs-out: bool; enable current sink output
 - qcom,cabc: bool; enable content adaptive backlight control
diff --git a/drivers/video/backlight/pm8941-wled.c 
b/drivers/video/backlight/pm8941-wled.c
index c704c3236034..e1298147bcbb 100644
--- a/drivers/video/backlight/pm8941-wled.c
+++ b/drivers/video/backlight/pm8941-wled.c
@@ -17,6 +17,9 @@
 #include 
 #include 
 
+/* From DT binding */
+#define PM8941_WLED_DEFAULT_BRIGHTNESS 2048
+
 #define PM8941_WLED_REG_VAL_BASE   0x40
 #define  PM8941_WLED_REG_VAL_MAX   0xFFF
 
@@ -373,6 +376,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
struct backlight_device *bl;
struct pm8941_wled *wled;
struct regmap *regmap;
+   u32 val;
int rc;
 
regmap = dev_get_regmap(pdev->dev.parent, NULL);
@@ -395,8 +399,12 @@ static int pm8941_wled_probe(struct platform_device *pdev)
if (rc)
return rc;
 
+   val = PM8941_WLED_DEFAULT_BRIGHTNESS;
+   of_property_read_u32(pdev->dev.of_node, "default-brightness", );
+
memset(, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
+   props.brightness = val;
props.max_brightness = PM8941_WLED_REG_VAL_MAX;
bl = devm_backlight_device_register(>dev, wled->name,
>dev, wled,
-- 
2.4.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 1/3] devicetree: mfd: Add binding for the TI LM3533

2015-10-25 Thread Bjorn Andersson 
Add the binding for the Texas Instruments LM3533 lighting power
solution.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 Documentation/devicetree/bindings/mfd/lm3533.txt | 183 +++
 1 file changed, 183 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mfd/lm3533.txt

diff --git a/Documentation/devicetree/bindings/mfd/lm3533.txt 
b/Documentation/devicetree/bindings/mfd/lm3533.txt
new file mode 100644
index ..3cc41695a544
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/lm3533.txt
@@ -0,0 +1,183 @@
+Texas Instruments LM3533 binding
+
+This binding describes the Texas Instruments LM3533, a lighting power solution
+for smartphone handsets. The common properties are described directly in the
+node, while each individual component are described in an optional subnode.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be:
+   "ti,lm3533"
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: i2c address of the LM3533 chip
+
+- ti,hwen-gpios:
+   Usage: required
+   Value type: 
+   Definition: reference to gpio pin connected to the HWEN input; as
+   specified in "gpio/gpio.txt"
+
+- ti,als-supply:
+   Usage: optional
+   Value type: 
+   Definition: reference to regulator powering the V_als input; as
+   specified in "regulator/regulator.txt"
+
+- ti,boost-freq:
+   Usage: required
+   Value type: 
+   Definition: switch-frequency of the boost converter, must be either:
+   50 or 100
+
+- ti,boost-ovp:
+   Usage: required
+   Value type: 
+   Definition: over voltage protection limit, must be one of: 16, 24, 32
+   or 40
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 0
+
+= ALS SUBNODE
+The als subnode must be named "als", it carries the als related properties.
+
+- ti,als-resistance:
+   Usage: required (unless ti,pwm-mode is specified)
+   Value type: 
+   Definition: specifies the resistor value (R_als), in Ohm. Valid values
+   ranges from 200kOhm to 1574Ohm.
+
+- ti,pwm-mode:
+   Usage: optional
+   Value type: 
+   Definition: specifies, if present, that the als should operate in pwm
+   mode - rather than analog mode
+
+= BACKLIGHT NODES
+Backlight subnodes must be named "backlight", they carry the backlight related
+properties.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies which of the two backlights this node corresponds
+   to
+
+- default-brightness:
+   Usage: optional
+   Value type: <32>
+   Definition: specifies the default brightness for the backlight, in
+   units of brightness [0-255]
+
+- label:
+   Usage: required
+   Value type: 
+   Definition: specifies a name of this backlight
+
+- led-max-microamp:
+   Usage: required
+   Value type: 
+   Definition: specifies the max current for this backlight, in uA, as
+   described in "leds/common.txt"
+
+- ti,pwm-zones:
+   Usage: optional
+   Value type: 
+   Definition: lists the ALS zones to be PWM controlled for this backlight,
+   the values in the list are in the range [0 - 4]
+
+= LED NODES
+LED subnodes must be named "led", they carry the LED related properties.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies which of the four LEDs this node corresponds to
+
+- linux,default-trigger:
+   Usage: optional
+   Value type: 
+   Definition: specifies the default trigger for the LED, as described in
+   "leds/common.txt"
+
+- label:
+   Usage: required
+   Value type: 
+   Definition: specifies a name of this LED, as described in
+   "leds/common.txt"
+
+- led-max-microamp:
+   Usage: required
+   Value type: 
+   Definition: specifies the max current for this LED, in uA, as described
+   in "leds/common.txt"
+
+- ti,pwm-zones:
+   Usage: optional
+   Value type: 
+   Definition: lists the ALS zones to be PWM controlled for this LED, the
+   values in the list are in the range [0 - 4]
+
+= EXAMPLE
+
+i2c@1246 {
+   compatible = "qcom,i2c-qup-v1.1.1";
+   ...
+
+   lm3533@36 {
+   compatible = "ti,lm3533";
+   reg = <0x36>;
+
+   ti,hwen-gpios = <_gpio 26 GPIO_ACTIVE_HIGH>;
+   ti,als-supply = <_l11>;
+
+   ti,boost-freq = <50>;
+   ti,boost-ovp =

[PATCH 0/4] Sony Xperia Z dts

2015-10-22 Thread Bjorn Andersson 
This series starts by adding hwspinlock, smem, gsbi5 and cleans up the
8064 regulator definitions.

Based on this it adds the necessary nodes for booting the Sony Xperia Z
(APQ8064 based) to userspace, with UART, eMMC, uSD, USB gadget and hw
buttons.

Bjorn Andersson (4):
  ARM: dts: qcom: apq8064: Add hwmutex and SMEM nodes
  ARM: dts: qcom: apq8064: Declare all pm8921 regulators
  ARM: dts: qcom: apq8064: Introduce gsbi5 and gsbi5 serial node
  ARM: dts: qcom: apq8064: Introduce Sony Xperia Z dts

 arch/arm/boot/dts/Makefile |   1 +
 arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts|  16 +-
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts |  20 +-
 .../arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts | 436 +
 arch/arm/boot/dts/qcom-apq8064.dtsi|  97 +
 5 files changed, 552 insertions(+), 18 deletions(-)
 create mode 100644 arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts

-- 
2.4.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 2/4] ARM: dts: qcom: apq8064: Declare all pm8921 regulators

2015-10-22 Thread Bjorn Andersson 
Consolidate all labeling of regulators into the core 8064 dtsi file to
make them available from all other dts files.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts | 16 +-
 arch/arm/boot/dts/qcom-apq8064-ifc6410.dts  | 20 ++---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 46 +
 3 files changed, 64 insertions(+), 18 deletions(-)

diff --git a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts 
b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
index 03784f1366e5..21095dad7741 100644
--- a/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-cm-qs600.dts
@@ -54,7 +54,7 @@
 
 
/* Buck SMPS */
-   pm8921_s1: s1 {
+   s1 {
regulator-always-on;
regulator-min-microvolt = <1225000>;
regulator-max-microvolt = <1225000>;
@@ -62,43 +62,43 @@
bias-pull-down;
};
 
-   pm8921_s3: s3 {
+   s3 {
regulator-min-microvolt = <100>;
regulator-max-microvolt = <140>;
qcom,switch-mode-frequency = <480>;
};
 
-   pm8921_s4: s4 {
+   s4 {
regulator-min-microvolt = <180>;
regulator-max-microvolt = <180>;
qcom,switch-mode-frequency = <320>;
};
 
-   pm8921_s7: s7 {
+   s7 {
regulator-min-microvolt = <130>;
regulator-max-microvolt = <130>;
qcom,switch-mode-frequency = <320>;
};
 
-   pm8921_l3: l3 {
+   l3 {
regulator-min-microvolt = <305>;
regulator-max-microvolt = <330>;
bias-pull-down;
};
 
-   pm8921_l4: l4 {
+   l4 {
regulator-min-microvolt = <100>;
regulator-max-microvolt = <180>;
bias-pull-down;
};
 
-   pm8921_l5: l5 {
+   l5 {
regulator-min-microvolt = <275>;
regulator-max-microvolt = <300>;
bias-pull-down;
};
 
-   pm8921_l23: l23 {
+   l23 {
regulator-min-microvolt = <170>;
regulator-max-microvolt = <190>;
bias-pull-down;
diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index 11ac608b6d50..f40e93f09673 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -64,7 +64,7 @@
 
 
/* Buck SMPS */
-   pm8921_s1: s1 {
+   s1 {
regulator-always-on;
regulator-min-microvolt = <1225000>;
regulator-max-microvolt = <1225000>;
@@ -72,55 +72,55 @@
bias-pull-down;
};
 
-   pm8921_s3: s3 {
+   s3 {
regulator-min-microvolt = <100>;
regulator-max-microvolt = <140>;
qcom,switch-mode-frequency = <480>;
};
 
-   pm8921_s4: s4 {
+   s4 {
regulator-min-microvolt = <180>

[PATCH 1/4] ARM: dts: qcom: apq8064: Add hwmutex and SMEM nodes

2015-10-22 Thread Bjorn Andersson 
Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 29 +
 1 file changed, 29 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index a4c1762b53ea..1b64723bd8a0 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -11,6 +11,17 @@
compatible = "qcom,apq8064";
interrupt-parent = <>;
 
+   reserved-memory {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   smem_region: smem@8000 {
+   reg = <0x8000 0x20>;
+   no-map;
+   };
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -80,6 +91,19 @@
interrupts = <1 10 0x304>;
};
 
+   sfpb_mutex: hwmutex {
+   compatible = "qcom,sfpb-mutex";
+   syscon = <_wrapper_mutex 0x604 0x4>;
+   #hwlock-cells = <1>;
+   };
+
+   smem {
+   compatible = "qcom,smem";
+   memory-region = <_region>;
+
+   hwlocks = <_mutex 3>;
+   };
+
soc: soc {
#address-cells = <1>;
#size-cells = <1>;
@@ -156,6 +180,11 @@
};
};
 
+   sfpb_wrapper_mutex: syscon@120 {
+   compatible = "syscon";
+   reg = <0x0120 0x8000>;
+   };
+
intc: interrupt-controller@200 {
compatible = "qcom,msm-qgic2";
interrupt-controller;
-- 
2.4.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 4/4] ARM: dts: qcom: apq8064: Introduce Sony Xperia Z dts

2015-10-22 Thread Bjorn Andersson 
This introduces initial support for the Sony Xperia Z smartphone, including
support for UART, MMC, USB gadget and physical buttons.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 arch/arm/boot/dts/Makefile |   1 +
 .../arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts | 436 +
 2 files changed, 437 insertions(+)
 create mode 100644 arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 7d3e495c0897..42a9370d4ad1 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -500,6 +500,7 @@ dtb-$(CONFIG_ARCH_PRIMA2) += \
 dtb-$(CONFIG_ARCH_QCOM) += \
qcom-apq8064-cm-qs600.dtb \
qcom-apq8064-ifc6410.dtb \
+   qcom-apq8064-sony-xperia-yuga.dtb \
qcom-apq8074-dragonboard.dtb \
qcom-apq8084-ifc6540.dtb \
qcom-apq8084-mtp.dtb \
diff --git a/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts 
b/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts
new file mode 100644
index ..06b3c76c3e41
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-apq8064-sony-xperia-yuga.dts
@@ -0,0 +1,436 @@
+#include "qcom-apq8064-v2.0.dtsi"
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   model = "Sony Xperia Z";
+   compatible = "sony,xperia-yuga", "qcom,apq8064";
+
+   aliases {
+   serial0 = _serial;
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   gpio-keys {
+   compatible = "gpio-keys";
+   input-name = "gpio-keys";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_keys_pin_a>;
+
+   camera-focus {
+   label = "camera_focus";
+   gpios = <_gpio 3 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+
+   camera-snapshot {
+   label = "camera_snapshot";
+   gpios = <_gpio 4 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+
+   volume-down {
+   label = "volume_down";
+   gpios = <_gpio 29 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+
+   volume-up {
+   label = "volume_up";
+   gpios = <_gpio 35 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+   };
+
+   soc {
+   pinctrl@80 {
+   gsbi5_uart_pin_a: gsbi5-uart-pin-active {
+   rx {
+   pins = "gpio52";
+   function = "gsbi5";
+   drive-strength = <2>;
+   bias-pull-up;
+   };
+
+   tx {
+   pins = "gpio51";
+   function = "gsbi5";
+   drive-strength = <4>;
+   bias-disable;
+   };
+   };
+
+   sdcc1_pin_a: sdcc1-pin-active {
+   clk {
+   pins = "sdc1_clk";
+   drive-strengh = <16>;
+   bias-disable;
+   };
+
+   cmd {
+   pins = "sdc1_cmd";
+   drive-strengh = <10>;
+   bias-pull-up;
+   };
+
+   data {
+   pins = "sdc1_data";
+   drive-strengh = <10>;
+   bias-pull-up;
+   };
+   };
+
+   sdcc3_pin_a: sdcc3-pin-active {
+   clk {
+   pins = "sdc3_clk";
+   drive-strengh = <8>;
+   bias-disable;
+   };
+
+   cmd {
+   pins = "sdc3_cmd"

[PATCH 3/4] ARM: dts: qcom: apq8064: Introduce gsbi5 and gsbi5 serial node

2015-10-22 Thread Bjorn Andersson 
Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 arch/arm/boot/dts/qcom-apq8064.dtsi | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-apq8064.dtsi 
b/arch/arm/boot/dts/qcom-apq8064.dtsi
index 1bc6c4039dea..fa3053c14532 100644
--- a/arch/arm/boot/dts/qcom-apq8064.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8064.dtsi
@@ -320,6 +320,28 @@
};
};
 
+   gsbi5: gsbi@1a20 {
+   status = "disabled";
+   compatible = "qcom,gsbi-v1.0.0";
+   cell-index = <5>;
+   reg = <0x1a20 0x03>;
+   clocks = < GSBI5_H_CLK>;
+   clock-names = "iface";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   gsbi5_serial: serial@1a24 {
+   compatible = "qcom,msm-uartdm-v1.3", 
"qcom,msm-uartdm";
+   reg = <0x1a24 0x100>,
+ <0x1a20 0x03>;
+   interrupts = <0 154 0x0>;
+   clocks = < GSBI5_UART_CLK>, < 
GSBI5_H_CLK>;
+   clock-names = "core", "iface";
+   status = "disabled";
+   };
+   };
+
gsbi6: gsbi@1650 {
status = "disabled";
compatible = "qcom,gsbi-v1.0.0";
-- 
2.4.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 2/7] ARM: dts: qcom: msm8974-honami: Add regulator nodes for Honami

2015-10-20 Thread Bjorn Andersson 
Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---

This patch was previously submitted standalone, minor updates has been
done to correct the 8841 voltage ranges and the logic surrounding
vreg_boost.

l20 is marked for 200mA current consumption to force the eMMC supply
into HPM, to allow reliable mounting.

 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   | 226 +
 1 file changed, 226 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index 6f7e4ef4ccf7..5768c97bb124 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -1,6 +1,8 @@
 #include "qcom-msm8974.dtsi"
 #include "qcom-pm8841.dtsi"
 #include "qcom-pm8941.dtsi"
+#include 
+#include 
 
 / {
model = "Sony Xperia Z1";
@@ -18,6 +20,223 @@
reg = <0 0x4000>, <0x4000 0x4000>;
device_type = "memory";
};
+
+   smd {
+   rpm {
+   rpm_requests {
+   pm8841-regulators {
+   s1 {
+   regulator-min-microvolt = 
<675000>;
+   regulator-max-microvolt = 
<105>;
+   };
+
+   s2 {
+   regulator-min-microvolt = 
<50>;
+   regulator-max-microvolt = 
<105>;
+   };
+
+   s3 {
+   regulator-min-microvolt = 
<50>;
+   regulator-max-microvolt = 
<105>;
+   };
+
+   s4 {
+   regulator-min-microvolt = 
<50>;
+   regulator-max-microvolt = 
<105>;
+   };
+   };
+
+   pm8941-regulators {
+   vdd_l1_l3-supply = <_s1>;
+   vdd_l2_lvs1_2_3-supply = <_s3>;
+   vdd_l4_l11-supply = <_s1>;
+   vdd_l5_l7-supply = <_s2>;
+   vdd_l6_l12_l14_l15-supply = 
<_s2>;
+   vdd_l9_l10_l17_l22-supply = 
<_boost>;
+   vdd_l13_l20_l23_l24-supply = 
<_boost>;
+   vdd_l21-supply = <_boost>;
+   vin_5vs-supply = <_5v>;
+
+   s1 {
+   regulator-min-microvolt = 
<130>;
+   regulator-max-microvolt = 
<130>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   s2 {
+   regulator-min-microvolt = 
<215>;
+   regulator-max-microvolt = 
<215>;
+   regulator-boot-on;
+   };
+
+   s3 {
+   regulator-min-microvolt = 
<180>;
+   regulator-max-microvolt = 
<180>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   s4 {
+   regulator-min-microvolt = 
<500>;
+   regulator-max-microvolt = 
<500>;
+   };
+
+   l1 {
+   regulator-min-microvolt = 
<1225000>;
+   regulator-max-microvolt = 
<1225000>;
+
+   regulator-always-on;
+   regulator-boot-on;
+

[PATCH 7/7] ARM: defconfig: Update qcom_defconfig

2015-10-20 Thread Bjorn Andersson 
This enables smem, smd, rpm, regulators, pmic pinctrl and hwspinlock as
these platform features are now merged. It enables gpio-keys as this is
used by most boards and enables fhandle and cgroups, so we can boot
systemd.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---

MSM_IOMMU is marked as BROKEN as of next-20151020, the other options
that is disabled are done so because they are now default on.

 arch/arm/configs/qcom_defconfig | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/arch/arm/configs/qcom_defconfig b/arch/arm/configs/qcom_defconfig
index ff7985ba226e..0efe0741b5be 100644
--- a/arch/arm/configs/qcom_defconfig
+++ b/arch/arm/configs/qcom_defconfig
@@ -1,8 +1,10 @@
 CONFIG_SYSVIPC=y
+CONFIG_FHANDLE=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_IKCONFIG=y
 CONFIG_IKCONFIG_PROC=y
+CONFIG_CGROUPS=y
 CONFIG_BLK_DEV_INITRD=y
 CONFIG_SYSCTL_SYSCALL=y
 CONFIG_KALLSYMS_ALL=y
@@ -25,7 +27,6 @@ CONFIG_SMP=y
 CONFIG_PREEMPT=y
 CONFIG_AEABI=y
 CONFIG_HIGHMEM=y
-CONFIG_HIGHPTE=y
 CONFIG_CLEANCACHE=y
 CONFIG_ARM_APPENDED_DTB=y
 CONFIG_ARM_ATAG_DTB_COMPAT=y
@@ -78,6 +79,7 @@ CONFIG_USB_USBNET=y
 # CONFIG_USB_NET_ZAURUS is not set
 CONFIG_INPUT_EVDEV=y
 # CONFIG_KEYBOARD_ATKBD is not set
+CONFIG_KEYBOARD_GPIO=y
 # CONFIG_MOUSE_PS2 is not set
 CONFIG_INPUT_JOYSTICK=y
 CONFIG_INPUT_TOUCHSCREEN=y
@@ -99,16 +101,21 @@ CONFIG_PINCTRL_APQ8084=y
 CONFIG_PINCTRL_IPQ8064=y
 CONFIG_PINCTRL_MSM8960=y
 CONFIG_PINCTRL_MSM8X74=y
+CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
+CONFIG_PINCTRL_QCOM_SSBI_PMIC=y
 CONFIG_GPIOLIB=y
 CONFIG_DEBUG_GPIO=y
 CONFIG_GPIO_SYSFS=y
+CONFIG_CHARGER_QCOM_SMBB=y
 CONFIG_POWER_RESET=y
 CONFIG_POWER_RESET_MSM=y
 CONFIG_THERMAL=y
 CONFIG_MFD_QCOM_RPM=y
+CONFIG_MFD_SPMI_PMIC=y
 CONFIG_REGULATOR=y
 CONFIG_REGULATOR_FIXED_VOLTAGE=y
 CONFIG_REGULATOR_QCOM_RPM=y
+CONFIG_REGULATOR_QCOM_SMD_RPM=y
 CONFIG_MEDIA_SUPPORT=y
 CONFIG_FB=y
 CONFIG_SOUND=y
@@ -145,16 +152,17 @@ CONFIG_MSM_GCC_8660=y
 CONFIG_MSM_LCC_8960=y
 CONFIG_MSM_MMCC_8960=y
 CONFIG_MSM_MMCC_8974=y
-CONFIG_MSM_IOMMU=y
+CONFIG_HWSPINLOCK_QCOM=y
 CONFIG_QCOM_GSBI=y
 CONFIG_QCOM_PM=y
+CONFIG_QCOM_SMEM=y
+CONFIG_QCOM_SMD=y
+CONFIG_QCOM_SMD_RPM=y
 CONFIG_PHY_QCOM_APQ8064_SATA=y
 CONFIG_PHY_QCOM_IPQ806X_SATA=y
 CONFIG_EXT2_FS=y
 CONFIG_EXT2_FS_XATTR=y
 CONFIG_EXT3_FS=y
-# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set
-CONFIG_EXT4_FS=y
 CONFIG_FUSE_FS=y
 CONFIG_VFAT_FS=y
 CONFIG_TMPFS=y
-- 
2.4.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 6/7] ARM: dts: qcom: msm8974-honami: Specify charging parameters

2015-10-20 Thread Bjorn Andersson 
Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---

Echoing a reasonable limit into [1] is required as there's currently no
way for this value to be propagated from the USB stack to the charging
driver.  Otherwise the block will pull maximum 100mA off USB, which is
not enough to actually charge the running platform.

[1] /sys/class/power_supply/smbb-usbin/charge_control_limit

 arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index 113cc18ee2f5..1cf455fff3c2 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -371,6 +371,17 @@
 
 _bus {
pm8941@0 {
+   charger@1000 {
+   qcom,fast-charge-safe-current = <150>;
+   qcom,fast-charge-current-limit = <150>;
+   qcom,dc-current-limit = <180>;
+   qcom,fast-charge-safe-voltage = <440>;
+   qcom,fast-charge-high-threshold-voltage = <435>;
+   qcom,fast-charge-low-threshold-voltage = <340>;
+   qcom,auto-recharge-threshold-voltage = <420>;
+   qcom,minimum-input-voltage = <430>;
+   };
+
gpios@c000 {
boost_bypass_n_pin: boost-bypass {
pins = "gpio21";
-- 
2.4.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 5/7] ARM: dts: qcom: msm8974-honami: Add uSD slot nodes

2015-10-20 Thread Bjorn Andersson 
Add and enable the sdhci2 slot, the pinctrl configuration and card
detect.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   | 37 ++
 1 file changed, 37 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index de3529d1a8ca..113cc18ee2f5 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -290,6 +290,20 @@
pinctrl-0 = <_pin_a>;
};
 
+   sdhci@f98a4900 {
+   status = "ok";
+
+   bus-width = <4>;
+
+   vmmc-supply = <_l21>;
+   vqmmc-supply = <_l13>;
+
+   cd-gpios = < 62 GPIO_ACTIVE_LOW>;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_a>, <_cd_pin_a>;
+   };
+
serial@f991e000 {
status = "ok";
 
@@ -329,6 +343,29 @@
bias-pull-up;
};
};
+
+   sdhc2_cd_pin_a: sdhc2-cd-pin-active {
+   pins = "gpio62";
+   function = "gpio";
+
+   drive-strength = <2>;
+   bias-disable;
+};
+
+   sdhc2_pin_a: sdhc2-pin-active {
+   clk {
+   pins = "sdc2_clk";
+   drive-strength = <10>;
+   bias-disable;
+   };
+
+   cmd-data {
+   pins = "sdc2_cmd", "sdc2_data";
+   drive-strength = <6>;
+   bias-pull-up;
+   };
+   };
+
};
 };
 
-- 
2.4.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 4/7] ARM: dts: qcom: msm8974-honami: Add sdhci1 node

2015-10-20 Thread Bjorn Andersson 
Introduce the eMMC sdhci node and its pinctrl state.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   | 27 ++
 1 file changed, 27 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index 8c0753a32b20..de3529d1a8ca 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -277,6 +277,19 @@
 };
 
  {
+   sdhci@f9824900 {
+   status = "ok";
+
+   vmmc-supply = <_l20>;
+   vqmmc-supply = <_s3>;
+
+   bus-width = <8>;
+   non-removable;
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin_a>;
+   };
+
serial@f991e000 {
status = "ok";
 
@@ -302,6 +315,20 @@
bias-disable;
};
};
+
+   sdhc1_pin_a: sdhc1-pin-active {
+   clk {
+   pins = "sdc1_clk";
+   drive-strength = <16>;
+   bias-disable;
+   };
+
+   cmd-data {
+   pins = "sdc1_cmd", "sdc1_data";
+   drive-strength = <10>;
+   bias-pull-up;
+   };
+   };
};
 };
 
-- 
2.4.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 1/7] ARM: dts: qcom: msm8974-honami: Define pinctrl state for blsp_uart2

2015-10-20 Thread Bjorn Andersson 
Make sure the blsp1_uart2 pins are in the correct state for the uart.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   | 23 ++
 1 file changed, 23 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index 016f9ad9392a..6f7e4ef4ccf7 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -23,6 +23,29 @@
  {
serial@f991e000 {
status = "ok";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_uart2_pin_a>;
+   };
+
+   pinctrl@fd51 {
+   blsp1_uart2_pin_a: blsp1-uart2-pin-active {
+   rx {
+   pins = "gpio5";
+   function = "blsp_uart2";
+
+   drive-strength = <2>;
+   bias-pull-up;
+   };
+
+   tx {
+   pins = "gpio4";
+   function = "blsp_uart2";
+
+   drive-strength = <4>;
+   bias-disable;
+   };
+   };
};
 };
 
-- 
2.4.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 3/7] ARM: dts: qcom: msm8974-honami: Introduce gpio-keys

2015-10-20 Thread Bjorn Andersson 
Introduce a gpio-keys node defining the physical keys of the Honami and
the associated pinctrl state.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 .../boot/dts/qcom-msm8974-sony-xperia-honami.dts   | 45 ++
 1 file changed, 45 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts 
b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
index 5768c97bb124..8c0753a32b20 100644
--- a/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
+++ b/arch/arm/boot/dts/qcom-msm8974-sony-xperia-honami.dts
@@ -2,6 +2,7 @@
 #include "qcom-pm8841.dtsi"
 #include "qcom-pm8941.dtsi"
 #include 
+#include 
 #include 
 
 / {
@@ -16,6 +17,42 @@
stdout-path = "serial0:115200n8";
};
 
+   gpio-keys {
+   compatible = "gpio-keys";
+   input-name = "gpio-keys";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_keys_pin_a>;
+
+   volume-down {
+   label = "volume_down";
+   gpios = <_gpios 2 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+
+   camera-snapshot {
+   label = "camera_snapshot";
+   gpios = <_gpios 3 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+
+   camera-focus {
+   label = "camera_focus";
+   gpios = <_gpios 4 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+
+   volume-up {
+   label = "volume_up";
+   gpios = <_gpios 5 GPIO_ACTIVE_LOW>;
+   linux,input-type = <1>;
+   linux,code = ;
+   };
+   };
+
memory@0 {
reg = <0 0x4000>, <0x4000 0x4000>;
device_type = "memory";
@@ -275,6 +312,14 @@
pins = "gpio21";
function = "normal";
};
+
+   gpio_keys_pin_a: gpio-keys-active {
+   pins = "gpio2", "gpio3", "gpio4", "gpio5";
+   function = "normal";
+
+   bias-pull-up;
+   power-source = ;
+   };
};
 
coincell@2800 {
-- 
2.4.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 1/2] dt-bindings: drm/msm: Update bindings for MDP5

2015-10-17 Thread Bjorn Andersson 
On Fri, Oct 16, 2015 at 5:06 AM, Archit Taneja  wrote:
> MDP5 has a different compatible string (which causes checkpatch warnings
> when we try to add MDP5 device nodes). It also has different list of
> clocks.
>
> Update the bindings for MDP5.
>
> Signed-off-by: Archit Taneja 
> ---
>  Documentation/devicetree/bindings/drm/msm/mdp.txt | 23 
> ---
>  1 file changed, 16 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/drm/msm/mdp.txt 
> b/Documentation/devicetree/bindings/drm/msm/mdp.txt
> index 1a0598e..e926daa 100644
> --- a/Documentation/devicetree/bindings/drm/msm/mdp.txt
> +++ b/Documentation/devicetree/bindings/drm/msm/mdp.txt
> @@ -3,18 +3,27 @@ Qualcomm adreno/snapdragon display controller
>  Required properties:
>  - compatible:
>* "qcom,mdp" - mdp4
> +  * "qcom,mdss_mdp" - mdp5

Wouldn't it be better to name these "qcom,mdp4" and "qcom,mdp5" so
that we don't have to rely on some magic detection mechanism to
support future versions?

Regards,
Bjorn
--
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] mmc: core: Allow specifying current consumption

2015-10-17 Thread Bjorn Andersson 
On Fri 16 Oct 05:55 PDT 2015, Ulf Hansson wrote:

> On 13 October 2015 at 03:00, Bjorn Andersson
> <bjorn.anders...@sonymobile.com> wrote:
> > This allows us to specify expected current consumption of the vmmc and
> > vqmmc regulators. This is needed to bring the supplying regulators out
> > of their low-power-mode while accessing the mmc.
> 
> This indeed makes sense, still I need to think a bit more on this.
> 

Thanks.

We can currently work around this by using "regulator-system-load" on
the vmmc regulator, but a proper fix would be nice.

> For example, can we allow these regulators to enter low power again at
> some times? If so, when and what should that current value be.
> 

The regulator framework recalculates the total load on a regulator upon
enable/disable, but currently it doesn't depend on the state of the
regulator.

I talked to Mark about this a while back and he was positive to us
correcting this, so disabled regulators wouldn't count towards the total
load of a regulator. (So that still is on my todo)


The second option would be to do what is done in the Qualcomm codeaurora
kernels, where the regulators are never disabled and there's a smaller
current specified for the suspend case.

This would require bigger changes to the mmc core I presume, but the
naming of the dt properties support such future adaption.

> Moreover, wouldn't vmmc|vqmmc-active-current be depending what eMMC/SD
> card that is attached?
> 

I would say so, I do however not know how to acquire or encode that
information. Any suggestions here are welcome.

Regards,
Bjorn
--
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 v2] mmc: core: Allow specifying current consumption

2015-10-12 Thread Bjorn Andersson 
This allows us to specify expected current consumption of the vmmc and
vqmmc regulators. This is needed to bring the supplying regulators out
of their low-power-mode while accessing the mmc.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---

The sd specification states that if the host can provide more than 150mA this
should be indicated in the "XPC value in the argument of ACMD41" for SDXC
cards. Should this be tied in with the added property as well?

Changes since v1:
- Property name and description updated to clarify intention

 Documentation/devicetree/bindings/mmc/mmc.txt | 2 ++
 drivers/mmc/core/core.c   | 6 ++
 drivers/mmc/core/host.c   | 4 
 include/linux/mmc/host.h  | 2 ++
 4 files changed, 14 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt 
b/Documentation/devicetree/bindings/mmc/mmc.txt
index 0384fc3f64e8..7514083a9f55 100644
--- a/Documentation/devicetree/bindings/mmc/mmc.txt
+++ b/Documentation/devicetree/bindings/mmc/mmc.txt
@@ -47,6 +47,8 @@ Optional properties:
 - mmc-hs400-1_2v: eMMC HS400 mode(1.2V I/O) is supported
 - dsr: Value the card's (optional) Driver Stage Register (DSR) should be
   programmed with. Valid range: [0 .. 0x].
+- vmmc-active-current: current required from the vmmc regulator, in uA
+- vqmmc-active-current: current required from the vqmmc regulator, in uA
 
 *NOTE* on CD and WP polarity. To use common for all SD/MMC host controllers 
line
 polarity properties, we have to fix the meaning of the "normal" and "inverted"
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 23fa221ce803..603f40136306 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -1469,12 +1469,18 @@ int mmc_regulator_get_supply(struct mmc_host *mmc)
mmc->ocr_avail = ret;
else
dev_warn(dev, "Failed getting OCR mask: %d\n", ret);
+
+   if (mmc->supply.vmmc_current)
+   regulator_set_load(mmc->supply.vmmc, 
mmc->supply.vmmc_current);
}
 
if (IS_ERR(mmc->supply.vqmmc)) {
if (PTR_ERR(mmc->supply.vqmmc) == -EPROBE_DEFER)
return -EPROBE_DEFER;
dev_info(dev, "No vqmmc regulator found\n");
+   } else {
+   if (mmc->supply.vqmmc_current)
+   regulator_set_load(mmc->supply.vqmmc, 
mmc->supply.vqmmc_current);
}
 
return 0;
diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
index 970e6906930b..ede508d63fb5 100644
--- a/drivers/mmc/core/host.c
+++ b/drivers/mmc/core/host.c
@@ -235,6 +235,10 @@ int mmc_of_parse(struct mmc_host *host)
host->caps2 |= MMC_CAP2_CD_ACTIVE_HIGH;
}
 
+   /* Parse regulator load requests */
+   of_property_read_u32(np, "vmmc-active-current", 
>supply.vmmc_current);
+   of_property_read_u32(np, "vqmmc-active-current", 
>supply.vqmmc_current);
+
/* Parse Write Protection */
ro_cap_invert = of_property_read_bool(np, "wp-inverted");
 
diff --git a/include/linux/mmc/host.h b/include/linux/mmc/host.h
index 8673ffe3d86e..640d8dbb8559 100644
--- a/include/linux/mmc/host.h
+++ b/include/linux/mmc/host.h
@@ -197,6 +197,8 @@ struct mmc_pwrseq;
 struct mmc_supply {
struct regulator *vmmc; /* Card power supply */
struct regulator *vqmmc;/* Optional Vccq supply */
+   u32 vmmc_current;   /* Requested current for vmmc */
+   u32 vqmmc_current;  /* Requested current for vqmmc */
 };
 
 struct mmc_host {
-- 
2.4.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

2015-09-25 Thread 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

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

2015-09-25 Thread 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 <bjorn.anders...@sonymobile.com>
---
 .../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 = < 0 149 1>,
+ <_smp2p_slave 0 0>,
+ <_smp2p_slave 1 0>,
+ <_smp2p_slave 2 0>,
+ <_smp2p_slave 3 0>;
+   interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack";
+
+   clocks = < RPM_CXO_CLK_SRC>, < RPM_CXO_A2>;
+   clock-names = "xo", "rf";
+
+   qcom,firmware-name = "wcnss";
+
+   qcom,crash-reason = <422>;
+
+   qcom,iris-vddxo-supply = <_l6>;
+   qcom,iris-vddrfa-supply = <_l11>;
+   qcom,iris-vddpa-supply = <_l19>;
+   qcom,iris-vdddig-supply = <_s3>;
+   qcom,pronto-vddmx-supply = <_s1>;
+   qcom,pronto-vddcx-supply = <_s2>;
+   qcom,pronto-vddpx-supply = <_s3>;
+
+   qcom,state = <_smp2p_out 0>;
+   qcom,state-names = "stop";
+
+   pinctrl-names = "default";
+   pinctrl-0 = <_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 v2 0/5] Qualcomm Shared Memory State Machines

2015-09-24 Thread Bjorn Andersson 
This series implements the two different mechanisms for propagating single bit
state information, used on the various Qualcomm platforms.

The system was traditionally used by the modem and application processor to
convey information about boot progress, power states, error handling and so on.
This was implemented as SMSM, with status bits representing a single local
state.

As the complexity of the SoC grew the state bits array grew and the need for
targeting specific state information at specific remote processors appeared.
SMP2P solves this by having separate shared memory regions per processor-pair.

This state information is e.g. used to convey progress and status of remote
firmware loading. Individual bits maps to various stages of the boot and error
states.

Changed since v1:
- The series moved away from representing outgoing bits as gpios

Bjorn Andersson (5):
  dt-binding: soc: qcom: Add Qualcomm SMSM device tree documentation
  dt-binding: soc: qcom: Introduce qcom,smp2p binding documentation
  soc: qcom: Introduce common SMEM state machine code
  soc: qcom: smsm: Add driver for Qualcomm SMSM
  soc: qcom: smp2p: Qualcomm Shared Memory Point to Point

 .../devicetree/bindings/soc/qcom/qcom,smp2p.txt| 104 
 .../devicetree/bindings/soc/qcom/qcom,smsm.txt | 104 
 drivers/soc/qcom/Kconfig   |  19 +
 drivers/soc/qcom/Makefile  |   3 +
 drivers/soc/qcom/smem_state.c  | 201 +++
 drivers/soc/qcom/smp2p.c   | 578 +++
 drivers/soc/qcom/smsm.c| 625 +
 include/linux/soc/qcom/smem_state.h|  18 +
 8 files changed, 1652 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt
 create mode 100644 drivers/soc/qcom/smem_state.c
 create mode 100644 drivers/soc/qcom/smp2p.c
 create mode 100644 drivers/soc/qcom/smsm.c
 create mode 100644 include/linux/soc/qcom/smem_state.h

-- 
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 v2 2/5] dt-binding: soc: qcom: Introduce qcom,smp2p binding documentation

2015-09-24 Thread Bjorn Andersson 
Introduce binding documentation for the Qualcomm Shared Memory Point 2 Point
protocol.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---

Changes since v1:
- No longer representing outgoing state as gpio-controller

 .../devicetree/bindings/soc/qcom/qcom,smp2p.txt| 104 +
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
new file mode 100644
index ..5cc82b8353d8
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smp2p.txt
@@ -0,0 +1,104 @@
+Qualcomm Shared Memory Point 2 Point binding
+
+The Shared Memory Point to Point (SMP2P) protocol facilitates communication of
+a single 32-bit value between two processors.  Each value has a single writer
+(the local side) and a single reader (the remote side).  Values are uniquely
+identified in the system by the directed edge (local processor ID to remote
+processor ID) and a string identifier.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,smp2p"
+
+- interrupts:
+   Usage: required
+   Value type: 
+   Definition: one entry specifying the smp2p notification interrupt
+
+- qcom,ipc:
+   Usage: required
+   Value type: 
+   Definition: three entries specifying the outgoing ipc bit used for
+   signaling the remote end of the smp2p edge:
+   - phandle to a syscon node representing the apcs registers
+   - u32 representing offset to the register within the syscon
+   - u32 representing the ipc bit within the register
+
+- qcom,smem:
+   Usage: required
+   Value type: 
+   Definition: two identifiers of the inbound and outbound smem items used
+   for this edge
+
+- qcom,local-pid:
+   Usage: required
+   Value type: 
+   Definition: specifies the identfier of the local endpoint of this edge
+
+- qcom,remote-pid:
+   Usage: required
+   Value type: 
+   Definition: specifies the identfier of the remote endpoint of this edge
+
+= SUBNODES
+Each SMP2P pair contain a set of inbound and outbound entries, these are
+described in subnodes of the smp2p device node. The node names are not
+important.
+
+- qcom,entry-name:
+   Usage: required
+   Value type: 
+   Definition: specifies the name of this entry, for inbound entries this
+   will be used to match against the remotely allocated entry
+   and for outbound entries this name is used for allocating
+   entries
+
+- interrupt-controller:
+   Usage: required for incoming entries
+   Value type: 
+   Definition: marks the entry as inbound; the node should be specified
+   as a two cell interrupt-controller as defined in
+   "../interrupt-controller/interrupts.txt"
+   If not specified this node will denote the outgoing entry
+
+- #interrupt-cells:
+   Usage: required for incoming entries
+   Value type: 
+   Definition: must be 2 - denoting the bit in the entry and IRQ flags
+
+- #qcom,state-cells:
+   Usage: required for outgoing entries
+   Value type: 
+   Definition: must be 1 - denoting the bit in the entry
+
+= EXAMPLE
+The following example shows the SMP2P setup with the wireless processor,
+defined from the 8974 apps processor's point-of-view. It encompasses one
+inbound and one outbound entry:
+
+wcnss-smp2p {
+   compatible = "qcom,smp2p";
+   qcom,smem = <431>, <451>;
+
+   interrupts = <0 143 1>;
+
+   qcom,ipc = < 8 18>;
+
+   qcom,local-pid = <0>;
+   qcom,remote-pid = <4>;
+
+   wcnss_smp2p_out: master-kernel {
+   qcom,entry-name = "master-kernel";
+
+   #qcom,state-cells = <1>;
+   };
+
+   wcnss_smp2p_in: slave-kernel {
+   qcom,entry-name = "slave-kernel";
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+};
-- 
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 v2 1/5] dt-binding: soc: qcom: Add Qualcomm SMSM device tree documentation

2015-09-24 Thread Bjorn Andersson 
This documents a device tree binding for the Qualcomm Shared Memory
State Machine.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---

Changes since v1:
- No longer representing outgoing state as gpio-controller

 .../devicetree/bindings/soc/qcom/qcom,smsm.txt | 104 +
 1 file changed, 104 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt
new file mode 100644
index ..a6634c70850d
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smsm.txt
@@ -0,0 +1,104 @@
+Qualcomm Shared Memory State Machine
+
+The Shared Memory State Machine facilitates broadcasting of single bit state
+information between the processors in a Qualcomm SoC. Each processor is
+assigned 32 bits of state that can be modified. A processor can through a
+matrix of bitmaps signal subscription of notifications upon changes to a
+certain bit owned by a certain remote processor.
+
+- compatible:
+   Usage: required
+   Value type: 
+   Definition: must be one of:
+   "qcom,smsm"
+
+- qcom,ipc-N:
+   Usage: required
+   Value type: 
+   Definition: three entries specifying the outgoing ipc bit used for
+   signaling the N:th remote processor
+   - phandle to a syscon node representing the apcs registers
+   - u32 representing offset to the register within the syscon
+   - u32 representing the ipc bit within the register
+
+- qcom,local-host:
+   Usage: optional
+   Value type: 
+   Definition: identifier of the local processor in the list of hosts, or
+   in other words specifier of the column in the subscription
+   matrix representing the local processor
+   defaults to host 0
+
+- #address-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 1
+
+- #size-cells:
+   Usage: required
+   Value type: 
+   Definition: must be 0
+
+= SUBNODES
+Each processor's state bits are described by a subnode of the smsm device node.
+Nodes can either be flagged as an interrupt-controller to denote a remote
+processor's state bits or the local processors bits.  The node names are not
+important.
+
+- reg:
+   Usage: required
+   Value type: 
+   Definition: specifies the offset, in words, of the first bit for this
+   entry
+
+- #qcom,state-cells:
+   Usage: required for local entry
+   Value type: 
+   Definition: must be 1 - denotes bit number
+
+- interrupt-controller:
+   Usage: required for remote entries
+   Value type: 
+   Definition: marks the entry as a interrupt-controller and the state bits
+   to belong to a remote processor
+
+- #interrupt-cells:
+   Usage: required for remote entries
+   Value type: 
+   Definition: must be 2 - denotes bit number and IRQ flags
+
+- interrupts:
+   Usage: required for remote entries
+   Value type: 
+   Definition: one entry specifying remote IRQ used by the remote processor
+   to signal changes of its state bits
+
+
+= EXAMPLE
+The following example shows the SMEM setup for controlling properties of the
+wireless processor, defined from the 8974 apps processor's point-of-view. It
+encompasses one outbound entry and the outgoing interrupt for the wireless
+processor.
+
+smsm {
+   compatible = "qcom,smsm";
+
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   qcom,ipc-3 = < 8 19>;
+
+   apps_smsm: apps@0 {
+   reg = <0>;
+
+   #qcom,state-cells = <1>;
+   };
+
+   wcnss_smsm: wcnss@7 {
+   reg = <7>;
+   interrupts = <0 144 1>;
+
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   };
+};
-- 
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 v2 1/2] input: Add Qualcomm PM8941 power key driver

2015-09-20 Thread Bjorn Andersson 
On Tue 15 Sep 04:36 PDT 2015, Ivan T. Ivanov wrote:

> 
> On Fri, 2015-01-23 at 16:19 -0800, Bjorn Andersson wrote:
> > From: Courtney Cavin ca...@sonymobile.com>
> > 
> > Signed-off-by: Courtney Cavin ca...@sonymobile.com>
> > Signed-off-by: Bjorn Andersson anders...@sonymobile.com>
> > 
> 
> 
> 
> > 
> > +config INPUT_PM8941_PWRKEY
> > +   tristate "Qualcomm PM8941 power key support"
> > +   depends on MFD_SPMI_PMIC
> > +   help
> > +   Say Y here if you want support for the power key 
> > usually found
> > +   on boards using a Qualcomm PM8941 compatible PMIC.
> > +
> 
> Hi Bjorn, Courtney, 
> 
> Do you plan to extend this driver to support RESIN_N PMIC input?
>  

It's way down on the todo-list, so not right now.

> It looks like the same downstream "qcom,qpnp-power-on" handle
> this functionality for recent PMIC versions.
> 

Right, it seems to be functionality in the PON block.

> What will be the best way to add this new functionality, extend
> this driver, write new one...?
> 

Perhaps the naming of the driver isn't the best in the end, but I think
it should be implemented by the same driver...

Regards,
Bjorn
--
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/4] Qualcomm Shared Memory State Machines

2015-09-08 Thread Bjorn Andersson 
On Tue 08 Sep 05:20 PDT 2015, Linus Walleij wrote:

> On Thu, Aug 27, 2015 at 7:37 PM, Bjorn Andersson
> <bjorn.anders...@sonymobile.com> wrote:
> 
> Let's discuss this a bit, looping in Mark Brown.
> 
> > As some of these states on some platforms are passed as physical signals
> > instead, the two drivers are modelled as gpio- and interrupt-controllers -
> > providing a nice abstraction both in device tree sense and Linux 
> > implementation
> > sense.
> 
> I have unfortunately repeatedly encountered an argument of the type
> "GPIO has nice infrastructure so let's call X 'a kind of GPIO' so
> we can use that nice infrastructure".
> 

I guess that's what you get for maintaining a subsystem with "general
purpose" in the name ;)

Sorry for adding one more item to your list.

> I'm not pleased with something that is not really general purpose
> input/output being called GPIO. It fits badly with the GPIO subsystem
> when we support things like open drain and cross-mappings to
> the pin control subsystem that will never be applicable to these
> new users. It's more like "special purpose input/output" or
> something.
> 

Right, this doesn't match at all with the electrical properties.

What it does give is the nice symmetry with the irq bits and existing
apis for poking and peeking.

> This happened with syscon LEDs for example, and was the reason
> I implemented syscon-leds. The original proposal was to say the LEDs
> register was "a kind of GPIO" on top of regmap and then use gpio-leds
> on top of that. Instead I insisted it was a syscon/regmap and the
> LEDs go directly to that, bypassing one layer of abstraction.
> 
> I also imagine creating syscon-keys.c for input from arbitrary keys
> in a syscon register actually. Just didn't get around to that yet.
> 

The difference with those two cases is that the pieces didn't fit
together, so we tried to use the gpio framework as an adaptor to make it
work.

I picked the gpio framework because:
* the DT nicely represent the structure of the memory and relationship
  between the individual components.

* the implementation needs to be able to set and clear individual bits,
  as well as register handlers for state changes.

* I'm told the SMP2P entries are on some platform (I've never seen)
  actual gpio lines.

> I also see some of the stuff GPIO does out-of-the-box being useful,
> for example in MFD: some of these are interrupt controllers and
> basically duplicate the kind of code I have in gpiolib for
> GPIOLIB_IRQCHIP.
> 

I do learn about new helper functions every time I touch these things.

> So we need to figure out what is really needed.
> 
> While sparsely documented: what about regmap (maybe in the
> form of syscon) and drivers/base/regmap/regmap-irq.c for the
> interrupt handling?
> 

regmap-irq looks good and reasonable.

The problem is that for SMSM I need custom masking operations and on
SMP2P I have multiple regmaps sharing one incoming IRQ. So it doesn't
look applicable for my use cases.

> I cannot claim to understand regmap-irq.c, but I just intuitively
> think it deserves consideration, such that drivers who need one
> of these misc registers can read/write their bits with regmap
> accessors and also get IRQs by way of regmap-irq.
> 

I was expecting some push back from you, but as it was the cleanest
abstraction I would come up with I gave it a shot :)

I'll rewrite the outgoing part based on regmaps instead. Thanks for
reviewing.

Regards,
Bjorn
--
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/4] dt-binding: gpio: Add Qualcomm SMSM device tree documentation

2015-09-01 Thread Bjorn Andersson 
On Tue 01 Sep 01:18 PDT 2015, Stanimir Varbanov wrote:

> On 08/27/2015 08:37 PM, Bjorn Andersson wrote:
> > This documents a device tree binding for exposing the Qualcomm Shared
> > Memory State Machine as a set of gpio- and interrupt-controllers.
> > 
> > Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> > ---
> >  .../devicetree/bindings/gpio/qcom,smsm.txt | 114 
> > +
> 
> 
> 
> > += EXAMPLE
> > +The following example shows the SMEM setup for controlling properties of 
> > the
> > +wireless processor, defined from the 8974 apps processor's point-of-view. 
> > It
> > +encompasses one outbound entry and the outgoing interrupt for the wireless
> > +processor.
> > +
> > +smsm {
> > +   compatible = "qcom,smsm";
> > +
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   qcom,ipc-3 = < 8 19>;
> 
> Can we use something more descriptive here, for example
> 
> qcom,ipc-rpm = < 8 19>;

Not really, because in the view of smsm we don't now which host the rpm
would represent. But most likely 3 would mean WCNSS, per the enum in
caf.

> 
> and replace these magic numbers with defines?
> 

I don't know what those defines would be named, what you have here is
bit 19 in the 8th byte - straight from the register documentation.

> > +
> > +   apps_smsm: apps@0 {
> > +   reg = <0>;
> > +
> > +   gpio-controller;
> > +   #gpio-cells = <2>;
> > +   };
> > +
> > +   wcnss_smsm: wcnss@7 {
> > +   reg = <7>;
> > +   interrupts = <0 144 1>;
> > +
> > +   interrupt-controller;
> > +   #interrupt-cells = <2>;
> > +   };
> > +};

Regards,
Bjorn
--
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/4] dt-binding: gpio: Add Qualcomm SMSM device tree documentation

2015-08-31 Thread Bjorn Andersson 
On Mon 31 Aug 08:43 PDT 2015, Rob Herring wrote:

> On Thu, Aug 27, 2015 at 12:37 PM, Bjorn Andersson
> <bjorn.anders...@sonymobile.com> wrote:
> > This documents a device tree binding for exposing the Qualcomm Shared
> > Memory State Machine as a set of gpio- and interrupt-controllers.
> >
> > Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> > ---
> >  .../devicetree/bindings/gpio/qcom,smsm.txt | 114 
> > +
> 
> >  drivers/gpio/Kconfig   |   8 ++
> >  drivers/gpio/Makefile  |   1 +
> 
> Presumably this goes in patch 2.
> 

Of course, my git-fu let me down.

> >  3 files changed, 123 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smsm.txt
> >
> > diff --git a/Documentation/devicetree/bindings/gpio/qcom,smsm.txt 
> > b/Documentation/devicetree/bindings/gpio/qcom,smsm.txt
> > new file mode 100644
> > index ..06201ba76594
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/gpio/qcom,smsm.txt
> > @@ -0,0 +1,114 @@
> > +Qualcomm Shared Memory State Machine
> > +
> > +The Shared Memory State Machine facilitates broadcasting of single bit 
> > state
> > +information between the processors in a Qualcomm SoC. Each processor is
> > +assigned 32 bits of state that can be modified. A processor can through a
> > +matrix of bitmaps signal subscription of notifications upon changes to a
> > +certain bit owned by a certain remote processor.
> 
> Are all the bits s/w driven, but somehow fixed in their functional definition?
> 

There's a wide range of systems implementing this, but I think it's all
software. The definition of the individual bits used to be defined by
one large enum, but it looks like Qualcomm ran out of bits and started
to re-use them.

But the functions are always well defined for a given platform.

> > +This document defines the binding for a driver that implements and exposes 
> > this
> > +a GPIO controller and a set of interrupt controllers.
> 
> I imagine Linus will have thoughts about that.
> 

Looking forward to hearing his comments :)

I have not been able to find any other suitable framework to expose this
functionality with and I am hoping to not be forced to create a new one
as this one fits the purpose well.

> > +
> > +- compatible:
> > +   Usage: required
> > +   Value type: 
> > +   Definition: must be one of:
> > +   "qcom,smsm"
> 
> There are not versions of the h/w?
> 

There are basically 2 versions; the original version comprised the
application cpu and the modem cpu, sometime around 2008-2009 this was
replaced with something called "N-way SMSM" - i.e. this implementation.
The only change since then is in the number of entries and number of
hosts - which we can determine in runtime if it's not compatible with
the original sizes.


So I have not been able to find any reasons to be more specific.


Thanks for taking a look.

Regards,
Bjorn
--
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/4] dt-binding: gpio: Add Qualcomm SMSM device tree documentation

2015-08-27 Thread Bjorn Andersson 
This documents a device tree binding for exposing the Qualcomm Shared
Memory State Machine as a set of gpio- and interrupt-controllers.

Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
 .../devicetree/bindings/gpio/qcom,smsm.txt | 114 +
 drivers/gpio/Kconfig   |   8 ++
 drivers/gpio/Makefile  |   1 +
 3 files changed, 123 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smsm.txt

diff --git a/Documentation/devicetree/bindings/gpio/qcom,smsm.txt 
b/Documentation/devicetree/bindings/gpio/qcom,smsm.txt
new file mode 100644
index ..06201ba76594
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/qcom,smsm.txt
@@ -0,0 +1,114 @@
+Qualcomm Shared Memory State Machine
+
+The Shared Memory State Machine facilitates broadcasting of single bit state
+information between the processors in a Qualcomm SoC. Each processor is
+assigned 32 bits of state that can be modified. A processor can through a
+matrix of bitmaps signal subscription of notifications upon changes to a
+certain bit owned by a certain remote processor.
+
+This document defines the binding for a driver that implements and exposes this
+a GPIO controller and a set of interrupt controllers.
+
+- compatible:
+   Usage: required
+   Value type: string
+   Definition: must be one of:
+   qcom,smsm
+
+- qcom,ipc-N:
+   Usage: required
+   Value type: prop-encoded-array
+   Definition: three entries specifying the outgoing ipc bit used for
+   signaling the N:th remote processor
+   - phandle to a syscon node representing the apcs registers
+   - u32 representing offset to the register within the syscon
+   - u32 representing the ipc bit within the register
+
+- qcom,local-host:
+   Usage: optional
+   Value type: u32
+   Definition: identifier of the local processor in the list of hosts, or
+   in other words specifier of the column in the subscription
+   matrix representing the local processor
+   defaults to host 0
+
+- #address-cells:
+   Usage: required
+   Value type: u32
+   Definition: must be 1
+
+- #size-cells:
+   Usage: required
+   Value type: u32
+   Definition: must be 0
+
+= SUBNODES
+Each processor's state bits are described by a subnode of the smsm device node.
+A node can either be a gpio-controller - denoting the local processors bits -
+or an interrupt-controller - denoting a remote processors state bits.  The node
+names are not important.
+
+- reg:
+   Usage: required
+   Value type: u32
+   Definition: specifies the offset, in words, of the first bit for this
+   entry
+
+- gpio-controller:
+   Usage: required for local entry
+   Value type: empty
+   Definition: marks the entry as a gpio-controller and the state bits to
+   belong to the local processor
+
+- #gpio-cells:
+   Usage: required for local entry
+   Value type: u32
+   Definition: must be 2 - denotes bit number and GPIO flags
+
+- interrupt-controller:
+   Usage: required for remote entries
+   Value type: empty
+   Definition: marks the entry as a interrupt-controller and the state bits
+   to belong to a remote processor
+
+- #interrupt-cells:
+   Usage: required for remote entries
+   Value type: u32
+   Definition: must be 2 - denotes bit number and IRQ flags
+
+- interrupts:
+   Usage: required for remote entries
+   Value type: prop-encoded-array
+   Definition: one entry specifying remote IRQ used by the remote processor
+   to signal changes of its state bits
+
+
+= EXAMPLE
+The following example shows the SMEM setup for controlling properties of the
+wireless processor, defined from the 8974 apps processor's point-of-view. It
+encompasses one outbound entry and the outgoing interrupt for the wireless
+processor.
+
+smsm {
+   compatible = qcom,smsm;
+
+   #address-cells = 1;
+   #size-cells = 0;
+
+   qcom,ipc-3 = apcs 8 19;
+
+   apps_smsm: apps@0 {
+   reg = 0;
+
+   gpio-controller;
+   #gpio-cells = 2;
+   };
+
+   wcnss_smsm: wcnss@7 {
+   reg = 7;
+   interrupts = 0 144 1;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+};
diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index b4fc9e4d24c6..0e57b60faae8 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -354,6 +354,14 @@ config GPIO_PXA
help
  Say yes here to support the PXA GPIO device
 
+config GPIO_QCOM_SMSM
+   bool Qualcomm Shared Memory State Machine
+   depends on QCOM_SMEM
+   help
+ Say yes here to support the Qualcomm Shared Memory State Machine

[PATCH 0/4] Qualcomm Shared Memory State Machines

2015-08-27 Thread Bjorn Andersson 
This series implements the two different mechanisms for propagating single bit
state information, used on the various Qualcomm platforms.

The system was traditionally used by the modem and application processor to
convey information about boot progress, power states, error handling and so on.
This was implemented as SMSM, with status bits representing a single local
state.

As the complexity of the SoC grew the state bits array grew and the need for
targeting specific state information at specific remote processors appeared.
SMP2P solves this by having separate shared memory regions per processor-pair.

This state information is e.g. used to convey progress and status of remote
firmware loading. Individual bits maps to various stages of the boot and error
states.

As some of these states on some platforms are passed as physical signals
instead, the two drivers are modelled as gpio- and interrupt-controllers -
providing a nice abstraction both in device tree sense and Linux implementation
sense.

Bjorn Andersson (4):
  dt-binding: gpio: Add Qualcomm SMSM device tree documentation
  gpio: qcom-smsm: Add driver for Qualcomm SMSM
  dt-binding: gpio: Introduce qcom,smp2p binding documentation
  gpio: qcom-smp2p: Qualcomm Shared Memory Point to Point

 .../devicetree/bindings/gpio/qcom,smp2p.txt| 112 
 .../devicetree/bindings/gpio/qcom,smsm.txt | 114 
 drivers/gpio/Kconfig   |  15 +
 drivers/gpio/Makefile  |   2 +
 drivers/gpio/gpio-qcom-smp2p.c | 601 
 drivers/gpio/gpio-qcom-smsm.c  | 631 +
 6 files changed, 1475 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smp2p.txt
 create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smsm.txt
 create mode 100644 drivers/gpio/gpio-qcom-smp2p.c
 create mode 100644 drivers/gpio/gpio-qcom-smsm.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

[PATCH 3/4] dt-binding: gpio: Introduce qcom,smp2p binding documentation

2015-08-27 Thread Bjorn Andersson 
Introduce binding documentation for the Qualcomm Shared Memory Point 2 Point
protocol implemented as gpio and interrupt controllers.

Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
 .../devicetree/bindings/gpio/qcom,smp2p.txt| 112 +
 1 file changed, 112 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/gpio/qcom,smp2p.txt

diff --git a/Documentation/devicetree/bindings/gpio/qcom,smp2p.txt 
b/Documentation/devicetree/bindings/gpio/qcom,smp2p.txt
new file mode 100644
index ..532c7d3ce3d2
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/qcom,smp2p.txt
@@ -0,0 +1,112 @@
+Qualcomm Shared Memory Point 2 Point binding
+
+The Shared Memory Point to Point (SMP2P) protocol facilitates communication of
+a single 32-bit value between two processors.  Each value has a single writer
+(the local side) and a single reader (the remote side).  Values are uniquely
+identified in the system by the directed edge (local processor ID to remote
+processor ID) and a string identifier. This documents defines the binding for a
+driver that implements and exposes this protocol as a set of GPIO and interrupt
+controllers.
+
+- compatible:
+   Usage: required
+   Value type: string
+   Definition: must be one of:
+   qcom,smp2p
+
+- interrupts:
+   Usage: required
+   Value type: prop-encoded-array
+   Definition: one entry specifying the smp2p notification interrupt
+
+- qcom,ipc:
+   Usage: required
+   Value type: prop-encoded-array
+   Definition: three entries specifying the outgoing ipc bit used for
+   signaling the remote end of the smp2p edge:
+   - phandle to a syscon node representing the apcs registers
+   - u32 representing offset to the register within the syscon
+   - u32 representing the ipc bit within the register
+
+- qcom,smem:
+   Usage: required
+   Value type: u32 array
+   Definition: two identifiers of the inbound and outbound smem items used
+   for this edge
+
+- qcom,local-pid:
+   Usage: required
+   Value type: u32
+   Definition: specifies the identfier of the local endpoint of this edge
+
+- qcom,remote-pid:
+   Usage: required
+   Value type: u32
+   Definition: specifies the identfier of the remote endpoint of this edge
+
+= SUBNODES
+Each SMP2P pair contain a set of inbound and outbound entries, these are
+described in subnodes of the smp2p device node. The node names are not
+important.
+
+- qcom,entry-name:
+   Usage: required
+   Value type: string
+   Definition: specifies the name of this entry, for inbound entries this
+   will be used to match against the remotely allocated entry
+   and for outbound entries this name is used for allocating
+   entries
+
+- interrupt-controller:
+   Usage: required for incoming entries
+   Value type: empty
+   Definition: marks the entry as inbound; the node should be specified
+   as a two cell interrupt-controller as defined in 
+   ../interrupt-controller/interrupts.txt
+
+- #interrupt-cells:
+   Usage: required for incoming entries
+   Value type: u32
+   Definition: must be 2 - denoting the bit in the entry and IRQ flags
+
+- gpio-controller:
+   Usage: required for outgoing entries
+   Value type: empty
+   Definition: marks the entry as outbound; the node should be specified
+   as a two cell gpio-controller as defined in gpio.txt
+
+- #gpio-cells:
+   Usage: required for outgoing entries
+   Value type: u32
+   Definition: must be 2 - denoting the bit in the entry and GPIO flags
+
+= EXAMPLE
+The following example shows the SMP2P setup with the wireless processor,
+defined from the 8974 apps processor's point-of-view. It encompasses one
+inbound and one outbound entry:
+
+wcnss-smp2p {
+   compatible = qcom,smp2p;
+   qcom,smem = 431, 451;
+
+   interrupts = 0 143 1;
+
+   qcom,ipc = apcs 8 18;
+
+   qcom,local-pid = 0;
+   qcom,remote-pid = 4;
+
+   wcnss_smp2p_out: master-kernel {
+   qcom,entry-name = master-kernel;
+
+   gpio-controller;
+   #gpio-cells = 2;
+   };
+
+   wcnss_smp2p_in: slave-kernel {
+   qcom,entry-name = slave-kernel;
+
+   interrupt-controller;
+   #interrupt-cells = 2;
+   };
+};
-- 
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 2/4] gpio: qcom-smsm: Add driver for Qualcomm SMSM

2015-08-27 Thread Bjorn Andersson 
This driver exposed the Qualcomm Shared Memory State Machine bits as
GPIOs to the system.

Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
 drivers/gpio/gpio-qcom-smsm.c | 631 ++
 1 file changed, 631 insertions(+)
 create mode 100644 drivers/gpio/gpio-qcom-smsm.c

diff --git a/drivers/gpio/gpio-qcom-smsm.c b/drivers/gpio/gpio-qcom-smsm.c
new file mode 100644
index ..4b3f28c469b6
--- /dev/null
+++ b/drivers/gpio/gpio-qcom-smsm.c
@@ -0,0 +1,631 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ * Copyright (c) 2012-2013, The Linux Foundation. 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 linux/gpio.h
+#include linux/interrupt.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/of_irq.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/soc/qcom/smem.h
+
+/*
+ * This driver implements the Qualcomm Shared Memory State Machine, a mechanism
+ * for communicating single bit state information to remote processors.
+ *
+ * The implementation is based on two sections of shared memory; the first
+ * holding the state bits and the second holding a matrix of subscription bits.
+ *
+ * The state bits are structured in entries of 32 bits, each belonging to one
+ * system in the SoC. The entry belonging to the local system is considered
+ * read-write, while the rest should be considered read-only.
+ *
+ * The subscription matrix consists of N bitmaps per entry, denoting interest
+ * in updates of the entry for each of the N hosts. Upon updating a state bit
+ * each host's subscription bitmap should be queried and the remote system
+ * should be interrupted if they request so.
+ *
+ * The subscription matrix is laid out in entry-major order:
+ * entry0: [host0 ... hostN]
+ * .
+ * .
+ * entryM: [host0 ... hostN]
+ *
+ * A third, optional, shared memory region might contain information regarding
+ * the number of entries in the state bitmap as well as number of columns in
+ * the subscription matrix.
+ */
+
+/*
+ * Shared memory identifiers, used to acquire handles to respective memory
+ * region.
+ */
+#define SMEM_SMSM_SHARED_STATE 85
+#define SMEM_SMSM_CPU_INTR_MASK333
+#define SMEM_SMSM_SIZE_INFO419
+
+/*
+ * Default sizes, in case SMEM_SMSM_SIZE_INFO is not found.
+ */
+#define SMSM_DEFAULT_NUM_ENTRIES   8
+#define SMSM_DEFAULT_NUM_HOSTS 3
+
+struct smsm_entry;
+struct smsm_host;
+
+/**
+ * struct qcom_smsm - smsm driver context
+ * @dev:   smsm device pointer
+ * @local_host:column in the subscription matrix representing this 
system
+ * @num_hosts: number of columns in the subscription matrix
+ * @num_entries: number of entries in the state map and rows in the 
subscription
+ * matrix
+ * @local_state: pointer to the local processor's state bits
+ * @subscription: pointer to local processor's row in subscription matrix
+ * @chip:  gpio_chip for interfacing the state bits
+ * @entries:   context for each of the entries
+ * @hosts: context for each of the hosts
+ */
+struct qcom_smsm {
+   struct device *dev;
+
+   u32 local_host;
+
+   u32 num_hosts;
+   u32 num_entries;
+
+   u32 *local_state;
+   u32 *subscription;
+   struct gpio_chip chip;
+
+   struct smsm_entry *entries;
+   struct smsm_host *hosts;
+};
+
+/**
+ * struct smsm_entry - per remote processor entry context
+ * @smsm:  back-reference to driver context
+ * @domain:IRQ domain for this entry, if representing a remote system
+ * @irq_enabled: bitmap of which state bits IRQs are enabled
+ * @irq_rising:bitmap tracking if rising bits should be propagated
+ * @irq_falling: bitmap tracking if falling bits should be propagated
+ * @last_value:snapshot of state bits last time the interrupts where 
propagated
+ * @remote_state: pointer to this entry's state bits
+ * @subscription: pointer to a row in the subscription matrix representing this
+ * entry
+ */
+struct smsm_entry {
+   struct qcom_smsm *smsm;
+
+   struct irq_domain *domain;
+   DECLARE_BITMAP(irq_enabled, 32);
+   DECLARE_BITMAP(irq_rising, 32);
+   DECLARE_BITMAP(irq_falling, 32);
+   u32 last_value;
+
+   u32 *remote_state;
+   u32 *subscription;
+};
+
+/**
+ * struct smsm_host - representation of a remote host
+ * @ipc_regmap:regmap for outgoing interrupt
+ * @ipc_offset:offset in @ipc_regmap for outgoing interrupt

[PATCH 4/4] gpio: qcom-smp2p: Qualcomm Shared Memory Point to Point

2015-08-27 Thread Bjorn Andersson 
Introduce the Qualcomm Shard Memory Point to Point driver, exposing bits
from the SMP2P protocol as gpio and interrupt controllers.

Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
 drivers/gpio/Kconfig   |   7 +
 drivers/gpio/Makefile  |   1 +
 drivers/gpio/gpio-qcom-smp2p.c | 601 +
 3 files changed, 609 insertions(+)
 create mode 100644 drivers/gpio/gpio-qcom-smp2p.c

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 0e57b60faae8..82c61ce5af8f 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -354,6 +354,13 @@ config GPIO_PXA
help
  Say yes here to support the PXA GPIO device
 
+config GPIO_QCOM_SMP2P
+   bool Qualcomm Shared Memory Point to Point support
+   depends on QCOM_SMEM
+   help
+ Say yes here to support the Qualcomm Shared Memory Point to Point
+ protocol, exposed to the system as GPIOs.
+
 config GPIO_QCOM_SMSM
bool Qualcomm Shared Memory State Machine
depends on QCOM_SMEM
diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
index 0fd213892403..fdab869a7212 100644
--- a/drivers/gpio/Makefile
+++ b/drivers/gpio/Makefile
@@ -75,6 +75,7 @@ obj-$(CONFIG_GPIO_PCF857X)+= gpio-pcf857x.o
 obj-$(CONFIG_GPIO_PCH) += gpio-pch.o
 obj-$(CONFIG_GPIO_PL061)   += gpio-pl061.o
 obj-$(CONFIG_GPIO_PXA) += gpio-pxa.o
+obj-$(CONFIG_GPIO_QCOM_SMP2P)  += gpio-qcom-smp2p.o
 obj-$(CONFIG_GPIO_QCOM_SMSM)   += gpio-qcom-smsm.o
 obj-$(CONFIG_GPIO_RC5T583) += gpio-rc5t583.o
 obj-$(CONFIG_GPIO_RDC321X) += gpio-rdc321x.o
diff --git a/drivers/gpio/gpio-qcom-smp2p.c b/drivers/gpio/gpio-qcom-smp2p.c
new file mode 100644
index ..f2eb2f095cc0
--- /dev/null
+++ b/drivers/gpio/gpio-qcom-smp2p.c
@@ -0,0 +1,601 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications AB.
+ * Copyright (c) 2012-2013, The Linux Foundation. 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 linux/gpio.h
+#include linux/interrupt.h
+#include linux/list.h
+#include linux/mfd/syscon.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/soc/qcom/smem.h
+#include linux/spinlock.h
+
+/*
+ * The Shared Memory Point to Point (SMP2P) protocol facilitates communication
+ * of a single 32-bit value between two processors.  Each value has a single
+ * writer (the local side) and a single reader (the remote side). Values are
+ * uniquely identified in the system by the directed edge (local processor ID
+ * to remote processor ID) and a string identifier.
+ *
+ * Each processor is responsible for creating the outgoing SMEM items and each
+ * item is writable by the local processor and readable by the remote
+ * processor.  By using two separate SMEM items that are single-reader and
+ * single-writer, SMP2P does not require any remote locking mechanisms.
+ *
+ * The driver uses the Linux GPIO and interrupt framework to expose a virtual
+ * GPIO for each outbound entry and a virtual interrupt controller for each
+ * inbound entry.
+ */
+
+#define SMP2P_MAX_ENTRY 16
+#define SMP2P_MAX_ENTRY_NAME 16
+
+#define SMP2P_FEATURE_SSR_ACK 0x1
+
+#define SMP2P_MAGIC 0x504d5324
+
+/**
+ * struct smp2p_smem_item - in memory communication structure
+ * @magic: magic number
+ * @version:   version - must be 1
+ * @features:  features flag - currently unused
+ * @local_pid: processor id of sending end
+ * @remote_pid:processor id of receiving end
+ * @total_entries: number of entries - always SMP2P_MAX_ENTRY
+ * @valid_entries: number of allocated entries
+ * @flags:
+ * @entries:   individual communication entries
+ * @name:  name of the entry
+ * @value: content of the entry
+ */
+struct smp2p_smem_item {
+   u32 magic;
+   u8 version;
+   unsigned features:24;
+   u16 local_pid;
+   u16 remote_pid;
+   u16 total_entries;
+   u16 valid_entries;
+   u32 flags;
+
+   struct {
+   u8 name[SMP2P_MAX_ENTRY_NAME];
+   u32 value;
+   } entries[SMP2P_MAX_ENTRY];
+} __packed;
+
+/**
+ * struct smp2p_entry - driver context matching one entry
+ * @node:  list entry to keep track of allocated entries
+ * @smp2p: reference to the device driver context
+ * @name:  name of the entry, to match against smp2p_smem_item
+ * @value: pointer to smp2p_smem_item entry value
+ * @last_value:last handled value
+ * @domain

Re: [PATCH v2] qcom: ipq40xx: Add basic board/dts support for IPQ40XX SoC

2015-08-21 Thread Bjorn Andersson 
On Fri 21 Aug 03:32 PDT 2015, Varadarajan Narayanan wrote:

 Add initial dts files and SoC support for IPQ40XX
 
 Signed-off-by: Varadarajan Narayanan var...@codeaurora.org
 ---
 Changes in v2:
   - Added devicetree bindings documentation
 
  .../devicetree/bindings/clock/qca,gcnt.txt | 14 
  Documentation/devicetree/bindings/ipq.txt  | 16 
  arch/arm/boot/dts/Makefile |  3 +-
  arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts| 33 +
  arch/arm/boot/dts/qcom-ipq40xx.dtsi| 86 
 ++
  arch/arm/configs/ipq_defconfig |  1 +
  arch/arm/mach-qcom/Kconfig |  4 +
  arch/arm/mach-qcom/board.c |  1 +
  8 files changed, 157 insertions(+), 1 deletion(-)
  create mode 100644 Documentation/devicetree/bindings/clock/qca,gcnt.txt
  create mode 100644 Documentation/devicetree/bindings/ipq.txt
  create mode 100644 arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
  create mode 100644 arch/arm/boot/dts/qcom-ipq40xx.dtsi
 
 diff --git a/Documentation/devicetree/bindings/clock/qca,gcnt.txt 
 b/Documentation/devicetree/bindings/clock/qca,gcnt.txt
 new file mode 100644
 index 000..dd0d71e
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/clock/qca,gcnt.txt
 @@ -0,0 +1,14 @@
 +QCA Global Counter

I don't think I've seen the global counter blocks before, what is it?
What does it do? Do you have a upcoming driver for it? (Have I just
missed it?)

You add it to the dts below, but don't seem to reference it. What is
its purpose?

Also, you should split this definition into its own patch.

 +
 +
 +Required properties :
 +- compatible : qcom,qca-gcnt
 +
 +- reg : shall contain base register location and length
 +
 +Example:
 +
 + counter {
 + compatible = qcom,qca-gcnt;
 + reg = 0x004a1000 0x4;

Most of the time when there's a device consuming one register it turns
out to be part of some larger hw block and down the road things get
complicated from the fact that we mapped 4 bytes in the middle.

Is this part of a larger block? Can we better implement that as a
simple-mfd or syscon?

 + };
 diff --git a/Documentation/devicetree/bindings/ipq.txt 
 b/Documentation/devicetree/bindings/ipq.txt
 new file mode 100644
 index 000..7d56bd0
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/ipq.txt

This doesn't really follow the general pattern of this directory. There
are some files like this, but then you should probably name it
qualcomm.txt.

 @@ -0,0 +1,16 @@
 +Qualcomm IPQ device tree bindings
 +-
 +
 +System on Chip
 +
 +Device tree must specify which SoC it uses, with one of the
 +following compatible strings
 +
 +   qcom,ipq40xx
 +
 +Platform
 +
 +Device tree must specify which Platform it uses, with one of the
 +following compatible strings
 +
 +   qcom,ipq40xx-r3pc

I would expect an ipq.txt to contain qcom,ipq8064-ap148 and
qcom,ipq8064 as well.

 diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
 index 246473a..6b4caee 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -477,7 +477,8 @@ dtb-$(CONFIG_ARCH_QCOM) += \
   qcom-ipq8064-ap148.dtb \
   qcom-msm8660-surf.dtb \
   qcom-msm8960-cdp.dtb \
 - qcom-msm8974-sony-xperia-honami.dtb
 + qcom-msm8974-sony-xperia-honami.dtb \
 + qcom-ipq40xx-r3pc.dtb

Please insert your entry alphabetically.

  dtb-$(CONFIG_ARCH_REALVIEW) += \
   arm-realview-pb1176.dtb
  dtb-$(CONFIG_ARCH_ROCKCHIP) += \
 diff --git a/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts 
 b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
 new file mode 100644
 index 000..7e4e629
 --- /dev/null
 +++ b/arch/arm/boot/dts/qcom-ipq40xx-r3pc.dts
 @@ -0,0 +1,33 @@
 +/* Copyright (c) 2014, The Linux Foundation. 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 qcom-ipq40xx.dtsi
 +
 +/ {
 + model = Qualcomm Technologies, Inc. IPQ40XX R3PC;
 + compatible = qcom,ipq40xx-r3pc, qcom,ipq40xx;
 +
 + memory {
 + device_type = memory;
 + reg = 0x8000 0x2000; /* 512MB */
 + };
 +
 + chosen {
 + bootargs = root=/dev/ram rw init=/init 
 console=ttyMSM0,115200n8 initrd=0x8200,0x000E2246;
 + };
 +
 + soc {
 + serial@78b {
 + status = ok;
 + };
 + };
 +};

This part looks good.

 diff --git

Re: [PATCH v4 2/3] ARM: qcom: add SMEM device node to IPQ806x dts

2015-08-19 Thread Bjorn Andersson 
On Tue 18 Aug 14:04 PDT 2015, Mathieu Olivari wrote:

 SMEM is used on IPQ806x to store various board related information such
 as boot device and flash partition layout. We'll declare it as a device
 so we can make use of it thanks to the new SMEM soc driver.
 

Reviewed-by: Bjorn Andersson bjorn.anders...@sonymobile.com

 Signed-off-by: Mathieu Olivari math...@codeaurora.org
 ---
 
 Notes:
 v2:
 *Rename smem tag into smem_region
 
  arch/arm/boot/dts/qcom-ipq8064.dtsi | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
 b/arch/arm/boot/dts/qcom-ipq8064.dtsi
 index 8d366ae..9834c94 100644
 --- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
 +++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
 @@ -55,7 +55,7 @@
   no-map;
   };
  
 - smem@4100 {
 + smem_region: smem@4100 {
   reg = 0x4100 0x20;
   no-map;
   };
 @@ -341,4 +341,10 @@
  
   #hwlock-cells = 1;
   };
 +
 + smem {
 + compatible = qcom,smem;
 + memory-region = smem_region;
 + hwlocks = sfpb_mutex 3;
 + };
  };
 -- 
 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 v4 1/3] ARM: qcom: add SFPB nodes to IPQ806x dts

2015-08-19 Thread Bjorn Andersson 
On Tue 18 Aug 14:04 PDT 2015, Mathieu Olivari wrote:

 Add one new node to the ipq806x.dtsi file to declare  register the
 hardware spinlock devices. This mechanism is required to be used by
 other drivers such as SMEM.
 

Still looks good, but you should have added:

Reviewed-by: Bjorn Andersson bjorn.anders...@sonymobile.com
 Signed-off-by: Mathieu Olivari math...@codeaurora.org
 ---
  arch/arm/boot/dts/qcom-ipq8064.dtsi | 11 +++
  1 file changed, 11 insertions(+)
 
 diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
 b/arch/arm/boot/dts/qcom-ipq8064.dtsi
 index 9f727d8..8d366ae 100644
 --- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
 +++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
 @@ -329,5 +329,16 @@
   #reset-cells = 1;
   };
  
 + sfpb_mutex_block: syscon@1200600 {
 + compatible = syscon;
 + reg = 0x01200600 0x100;
 + };
 + };
 +
 + sfpb_mutex: sfpb-mutex {
 + compatible = qcom,sfpb-mutex;
 + syscon = sfpb_mutex_block 4 4;
 +
 + #hwlock-cells = 1;
   };
  };
 -- 
 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 v4 3/3] mtd: add SMEM parser for QCOM platforms

2015-08-19 Thread Bjorn Andersson 
On Tue 18 Aug 14:04 PDT 2015, Mathieu Olivari wrote:

 On QCOM platforms using MTD devices storage (such as IPQ806x), SMEM is
 used to store partition layout. This new parser can now be used to read
 SMEM and use it to register an MTD layout according to its content.
 

Still looks good, but you should have added:

Acked-by: Bjorn Andersson bjorn.anders...@sonymobile.com

 Signed-off-by: Mathieu Olivari math...@codeaurora.org
 ---
 
 Notes:
 v2:
 *Release the SPI device reference after looking it up (put_device())
 *Represent SMEM data as __le32 rather than u32
 *Move new DT nodes in their proper respective location
 *Address readability concerns in MTD parser
 
 v3:
 *Redefine SMEM functions prototypes for better readability
 *Duplicate MTD name instead of pointing to SMEM string location in case
  mtd layer tries to free it
 *Rework some of the comments
 
 v4:
 *Fix case in the license string
 
  drivers/mtd/Kconfig  |   7 ++
  drivers/mtd/Makefile |   1 +
  drivers/mtd/qcom_smem_part.c | 246 
 +++
  3 files changed, 254 insertions(+)
  create mode 100644 drivers/mtd/qcom_smem_part.c
 
 diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
 index a03ad29..debc887 100644
 --- a/drivers/mtd/Kconfig
 +++ b/drivers/mtd/Kconfig
 @@ -155,6 +155,13 @@ config MTD_BCM47XX_PARTS
 This provides partitions parser for devices based on BCM47xx
 boards.
  
 +config MTD_QCOM_SMEM_PARTS
 + tristate QCOM SMEM partitioning support
 + depends on QCOM_SMEM
 + help
 +   This provides partitions parser for QCOM devices using SMEM
 +   such as IPQ806x.
 +
  comment User Modules And Translation Layers
  
  #
 diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
 index 99bb9a1..b3c7de4 100644
 --- a/drivers/mtd/Makefile
 +++ b/drivers/mtd/Makefile
 @@ -13,6 +13,7 @@ obj-$(CONFIG_MTD_AFS_PARTS) += afs.o
  obj-$(CONFIG_MTD_AR7_PARTS)  += ar7part.o
  obj-$(CONFIG_MTD_BCM63XX_PARTS)  += bcm63xxpart.o
  obj-$(CONFIG_MTD_BCM47XX_PARTS)  += bcm47xxpart.o
 +obj-$(CONFIG_MTD_QCOM_SMEM_PARTS) += qcom_smem_part.o
  
  # 'Users' - code which presents functionality to userspace.
  obj-$(CONFIG_MTD_BLKDEVS)+= mtd_blkdevs.o
 diff --git a/drivers/mtd/qcom_smem_part.c b/drivers/mtd/qcom_smem_part.c
 new file mode 100644
 index 000..b4f8acc
 --- /dev/null
 +++ b/drivers/mtd/qcom_smem_part.c
 @@ -0,0 +1,246 @@
 +/*
 + * Copyright (c) 2015, The Linux Foundation. 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 linux/kernel.h
 +#include linux/device.h
 +#include linux/slab.h
 +
 +#include linux/mtd/mtd.h
 +#include linux/mtd/partitions.h
 +#include linux/spi/spi.h
 +#include linux/module.h
 +
 +#include linux/soc/qcom/smem.h
 +
 +/* Processor/host identifier for the application processor */
 +#define QCOM_SMEM_GLOBAL 0
 +
 +/* SMEM items index */
 +#define SMEM_AARM_PARTITION_TABLE9
 +#define SMEM_BOOT_FLASH_TYPE 421
 +#define SMEM_BOOT_FLASH_BLOCK_SIZE   424
 +
 +/* SMEM Flash types */
 +#define SMEM_FLASH_NAND  2
 +#define SMEM_FLASH_SPI   6
 +
 +#define SMEM_PART_NAME_SZ16
 +#define SMEM_PARTS_MAX   32
 +
 +struct smem_partition {
 + char name[SMEM_PART_NAME_SZ];
 + __le32 start;
 + __le32 size;
 + __le32 attr;
 +};
 +
 +struct smem_partition_table {
 + u8 magic[8];
 + __le32 version;
 + __le32 len;
 + struct smem_partition parts[SMEM_PARTS_MAX];
 +};
 +
 +/* SMEM Magic values in partition table */
 +static const u8 SMEM_PTABLE_MAGIC[] = {
 + 0xaa, 0x73, 0xee, 0x55,
 + 0xdb, 0xbd, 0x5e, 0xe3,
 +};
 +
 +static int qcom_smem_get_flash_blksz(void)
 +{
 + int ret;
 + size_t size;
 + u64 *smem_blksz;
 +
 + ret = qcom_smem_get(QCOM_SMEM_GLOBAL, SMEM_BOOT_FLASH_BLOCK_SIZE,
 + (void **) smem_blksz, size);
 +
 + if (ret  0) {
 + pr_err(Unable to read flash blksz from SMEM\n);
 + return -ENOENT;
 + }
 +
 + if (size != sizeof(*smem_blksz)) {
 + pr_err(Invalid flash blksz size in SMEM\n);
 + return -EINVAL;
 + }
 +
 + /* Sanity check block size value before casting it */
 + if (*smem_blksz  INT_MAX) {
 + pr_err(Invalid flash block size in SMEM\n);
 + return -EINVAL;
 + }
 +
 + return (int) *smem_blksz;
 +}
 +
 +static int qcom_smem_get_flash_type(void

Re: [PATCH v3 3/3] mtd: add SMEM parser for QCOM platforms

2015-08-18 Thread Bjorn Andersson 
On Mon 17 Aug 16:47 PDT 2015, Mathieu Olivari wrote:

 On QCOM platforms using MTD devices storage (such as IPQ806x), SMEM is
 used to store partition layout. This new parser can now be used to read
 SMEM and use it to register an MTD layout according to its content.

Looks good, but the license string should be GPL v2 (lower case v).
Just as a hint...I made checkpatch warn you about that a while back ;)

The rest is

Acked-by: Bjorn Andersson bjorn.anders...@sonymobile.com

[..]

 +
 +MODULE_LICENSE(GPL V2);

Regards,
Bjorn
--
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/3] ARM: qcom: add SFPB nodes to IPQ806x dts

2015-08-18 Thread Bjorn Andersson 
On Mon 17 Aug 16:47 PDT 2015, Mathieu Olivari wrote:

 Add one new node to the ipq806x.dtsi file to declare  register the
 hardware spinlock devices. This mechanism is required to be used by
 other drivers such as SMEM.
 

Reviewed-by: Bjorn Andersson bjorn.anders...@sonymobile.com

 Signed-off-by: Mathieu Olivari math...@codeaurora.org
 ---
  arch/arm/boot/dts/qcom-ipq8064.dtsi | 11 +++
  1 file changed, 11 insertions(+)
 
 diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
 b/arch/arm/boot/dts/qcom-ipq8064.dtsi
 index 9f727d8..8d366ae 100644
 --- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
 +++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
 @@ -329,5 +329,16 @@
   #reset-cells = 1;
   };
  
 + sfpb_mutex_block: syscon@1200600 {
 + compatible = syscon;
 + reg = 0x01200600 0x100;

I have this block listed to start at 0x120 and used 0x604 as offset
when testing this. In my docs there's nothing in those first 0x600 bytes
though, so this works fine for me.

 + };
 + };
 +
 + sfpb_mutex: sfpb-mutex {
 + compatible = qcom,sfpb-mutex;
 + syscon = sfpb_mutex_block 4 4;
 +
 + #hwlock-cells = 1;
   };
  };

Regards,
Bjorn
--
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/3] ARM: qcom: add SMEM device node to IPQ806x dts

2015-08-18 Thread Bjorn Andersson 
On Mon 17 Aug 16:47 PDT 2015, Mathieu Olivari wrote:

 SMEM is used on IPQ806x to store various board related information such
 as boot device and flash partition layout. We'll declare it as a device
 so we can make use of it thanks to the new SMEM soc driver.
 
 Signed-off-by: Mathieu Olivari math...@codeaurora.org
 ---
  arch/arm/boot/dts/qcom-ipq8064.dtsi | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)
 
 diff --git a/arch/arm/boot/dts/qcom-ipq8064.dtsi 
 b/arch/arm/boot/dts/qcom-ipq8064.dtsi
 index 8d366ae..85dbccf 100644
 --- a/arch/arm/boot/dts/qcom-ipq8064.dtsi
 +++ b/arch/arm/boot/dts/qcom-ipq8064.dtsi
 @@ -55,7 +55,7 @@
   no-map;
   };
  
 - smem@4100 {
 + smem: smem@4100 {

I would preferred if you used a name like smem_region, although I
don't think we will use the phandle name smem for anything else...

   reg = 0x4100 0x20;
   no-map;
   };
 @@ -341,4 +341,10 @@
  
   #hwlock-cells = 1;
   };
 +
 + smem {
 + compatible = qcom,smem;
 + memory-region = smem;
 + hwlocks = sfpb_mutex 3;
 + };
  };

Acked-by: Bjorn Andersson bjorn.anders...@sonymobile.com

Regards,
Bjorn
--
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] regulator: Introduce property to flag set-load support

2015-08-18 Thread Bjorn Andersson 
Introduce regulator-allow-set-load property to make it possible to
flag in the board configuration that a regulator is allowed to have the
load requirements changed.

Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
 Documentation/devicetree/bindings/regulator/regulator.txt | 1 +
 drivers/regulator/of_regulator.c  | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/regulator/regulator.txt 
b/Documentation/devicetree/bindings/regulator/regulator.txt
index 24bd422cecd5..1d112fc456aa 100644
--- a/Documentation/devicetree/bindings/regulator/regulator.txt
+++ b/Documentation/devicetree/bindings/regulator/regulator.txt
@@ -11,6 +11,7 @@ Optional properties:
 - regulator-always-on: boolean, regulator should never be disabled
 - regulator-boot-on: bootloader/firmware enabled regulator
 - regulator-allow-bypass: allow the regulator to go into bypass mode
+- regulator-allow-set-load: allow the regulator performance level to be 
configured
 - name-supply: phandle to the parent supply/regulator node
 - regulator-ramp-delay: ramp delay for regulator(in uV/uS)
   For hardware which supports disabling ramp rate, it should be explicitly
diff --git a/drivers/regulator/of_regulator.c b/drivers/regulator/of_regulator.c
index 250700c853bf..499e437c7e91 100644
--- a/drivers/regulator/of_regulator.c
+++ b/drivers/regulator/of_regulator.c
@@ -76,6 +76,9 @@ static void of_get_regulation_constraints(struct device_node 
*np,
if (of_property_read_bool(np, regulator-allow-bypass))
constraints-valid_ops_mask |= REGULATOR_CHANGE_BYPASS;
 
+   if (of_property_read_bool(np, regulator-allow-set-load))
+   constraints-valid_ops_mask |= REGULATOR_CHANGE_DRMS;
+
ret = of_property_read_u32(np, regulator-ramp-delay, pval);
if (!ret) {
if (pval)
-- 
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 3/3] mtd: add SMEM parser for QCOM platforms

2015-08-14 Thread Bjorn Andersson 
On Fri 14 Aug 17:46 PDT 2015, Mathieu Olivari wrote:

 On QCOM platforms using MTD devices storage (such as IPQ806x), SMEM is
 used to store partition layout. This new parser can now be used to read
 SMEM and use it to register an MTD layout according to its content.
 

Nice to see another user of the smem code :)

 diff --git a/drivers/mtd/qcom_smem_part.c b/drivers/mtd/qcom_smem_part.c
[..]
 +
 +/* Processor/host identifier for the application processor */
 +#define SMEM_HOST_APPS   0

This makes me wonder if there will ever be an apps partition. I would
have picked QCOM_SMEM_HOST_ANY, but I don't know what future platforms
might hold for us.


And as a side note, I think I will propose that we rename that define
QCOM_SMEM_GLOBAL.

 +
 +/* SMEM items index */
 +#define SMEM_AARM_PARTITION_TABLE9
 +#define SMEM_BOOT_FLASH_TYPE 421
 +#define SMEM_BOOT_FLASH_BLOCK_SIZE   424
 +
 +/* SMEM Flash types */
 +#define SMEM_FLASH_NAND  2
 +#define SMEM_FLASH_SPI   6
 +
 +#define SMEM_PART_NAME_SZ16
 +#define SMEM_PARTS_MAX   32
 +
 +struct smem_partition {
 + char name[SMEM_PART_NAME_SZ];
 + __le32 start;
 + __le32 size;
 + __le32 attr;
 +};
 +
 +struct smem_partition_table {
 + u8 magic[8];
 + __le32 version;
 + __le32 len;
 + struct smem_partition parts[SMEM_PARTS_MAX];
 +};
 +
 +/* SMEM Magic values in partition table */
 +static const u8 SMEM_PTABLE_MAGIC[] = {
 + 0xaa, 0x73, 0xee, 0x55,
 + 0xdb, 0xbd, 0x5e, 0xe3,
 +};
 +
 +static int qcom_smem_get_flash_blksz(u64 **smem_blksz)

Instead of passing pointers around I think you should just make this
function return  0 for errors and = 0 for the requested data. You can
probably still have it as an int, as the current values are well below
the size of the int.

 +{
 + int ret;
 + size_t size;
 +
 + ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_BOOT_FLASH_BLOCK_SIZE,
 + (void **) smem_blksz, size);
 +
 + if (ret  0) {
 + pr_err(Unable to read flash blksz from SMEM\n);
 + return -ENOENT;
 + }
 +
 + if (size != sizeof(**smem_blksz)) {
 + pr_err(Invalid flash blksz size in SMEM\n);
 + return -EINVAL;
 + }
 +
 + return 0;
 +}
 +
 +static int qcom_smem_get_flash_type(u64 **smem_flash_type)

Same as above.

 +{
 + int ret;
 + size_t size;
 +
 + ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_BOOT_FLASH_TYPE,
 + (void **) smem_flash_type, size);
 +
 + if (ret  0) {
 + pr_err(Unable to read flash type from SMEM\n);
 + return -ENOENT;
 + }
 +
 + if (size != sizeof(**smem_flash_type)) {
 + pr_err(Invalid flash type size in SMEM\n);
 + return -EINVAL;
 + }
 +
 + return 0;
 +}
 +
 +static int qcom_smem_get_flash_partitions(struct smem_partition_table 
 **pparts)
 +{
 + int ret;
 + size_t size;
 +
 + ret = qcom_smem_get(SMEM_HOST_APPS, SMEM_AARM_PARTITION_TABLE,
 + (void **) pparts, size);
 +

If you don't care about the size just pass NULL as the last argument.

 + if (ret  0) {
 + pr_err(Unable to read partition table from SMEM\n);
 + return -ENOENT;
 + }

I think it would be cleaner if you had this function check the magic and
version and then return the partition pointer. That is:

static smem_partition *qcom_smem_get_flash_partitions(size_t *count)


And make *count = le32_to_cpu(table-len); so you don't have to care
about that below.

(And use NULL or ERR_PTR for the error paths)

 +
 + return 0;
 +}
 +
 +static int of_dev_node_match(struct device *dev, void *data)
 +{
 + return dev-of_node == data;
 +}
 +
 +static bool is_spi_device(struct device_node *np)
 +{
 + struct device *dev;
 +
 + dev = bus_find_device(spi_bus_type, NULL, np, of_dev_node_match);
 + if (!dev)
 + return false;
 +
 + put_device(dev);
 + return true;
 +}
 +
 +static int parse_qcom_smem_partitions(struct mtd_info *master,
 +   struct mtd_partition **pparts,
 +   struct mtd_part_parser_data *data)
 +{
 + struct smem_partition_table *smem_parts;
 + u64 *smem_flash_type, *smem_blksz;
 + struct mtd_partition *mtd_parts;
 + struct device_node *of_node = data-of_node;
 + int i, ret;
 +
 + /*
 +  * SMEM will only store the partition table of the boot device.
 +  * If this is not the boot device, do not return any partition.
 +  */

I guess this is the result of below checks, but it's not describing
what's actually done here. I think it should say only parse
partitions on the specified memory type or something like that.

 + ret = qcom_smem_get_flash_type(smem_flash_type);
 + if (ret  0)
 + return ret;
 +
 + if ((*smem_flash_type == SMEM_FLASH_NAND

Re: [PATCH RFC 08/10] hwspinlock: qcom: Lock #7 is special lock, uses dynamic proc_id

2015-08-12 Thread Bjorn Andersson 
On Wed 05 Aug 09:32 PDT 2015, Lina Iyer wrote:

 Hwspinlocks are widely used between processors in an SoC, and also
 between elevation levels within in the same processor.  QCOM SoC's use
 hwspinlock to serialize entry into a low power mode when the context
 switches from Linux to secure monitor.
 
 Lock #7 has been assigned for this purpose. In order to differentiate
 between one cpu core holding a lock while another cpu is contending for
 the same lock, the proc id written into the lock is (128 + cpu id). This
 makes it unique value among the cpu cores and therefore when a core
 locks the hwspinlock, other cores would wait for the lock to be released
 since they would have a different proc id.  This value is specific for
 the lock #7 only.
 

As I was thinking about this, I came to the conclusion that my argument
that it's system configuration and not a property of the block that lock
#7 is special is actually biting myself.

Just as #7 is system configuration, so is the fact that 1 is the lock
value for all other locks.

I've been meaning to answer you, but I haven't come to a good conclusion
in this matter. I think that both of these properties should be possible
to express in DT, but I don't know how.


Perhaps we should just list each lock that we expose as a subnode in DT
with a property to indicate the lock value - with the possibility of
indicating cpu_id.

Something like:

tcsr-mutex {
compatible = qcom,tcsr-mutex;
syscon = tcsr_mutex_block 0 0x80;

#hwlock-cells = 1;
#address-cells = 1;
#size-cells = 0;

smem-lock@3 {
reg = 3;
qcom,lock-value = 1;
};

scm-lock@7 {
reg = 7;
qcom,lock-value-from-cpu-id;
qcom,lock-raw;
};
};

As we don't reference most of these locks anyways I don't think this
would still be reasonable. And if reg is an array it's quite compact.

 Declare lock #7 as raw capable, so the hwspinlock framework would not
 enfore acquiring a s/w spinlock before acquiring the hwspinlock.
 

I'm fine with this part!


Sorry for the extremely slow response, but this took some time to
process...

Regards,
Bjorn
--
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 v1 7/7] ARM: dts: ifc6410: add inforce LVDS panel support

2015-08-10 Thread Bjorn Andersson 
On Tue 28 Jul 05:54 PDT 2015, Srinivas Kandagatla wrote:

 This patch adds LVDS panel for IFC6410.
 

My ifc6410 doesn't have a LVDS display, so I don't think these nodes
belong in this dts file.

I was thinking we could have a variant including this dts file adding
the panel, but I assume that you can mount other panels than the auo
panel defined below?


Either way, I think we should keep this file to define the stuff that's
on the IFC6410 itself and then figure out how to aid people in adding
the rest of their additions...

Regards,
Bjorn
--
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 RFC 1/5] drm/msm/hdmi: deprecate non standard gpio properties.

2015-08-10 Thread Bjorn Andersson 
On Mon 10 Aug 15:07 PDT 2015, Rob Herring wrote:

[..]
  -- qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin
  -- qcom,hdmi-tx-ddc-data-gpio: ddc data pin
  -- qcom,hdmi-tx-hpd-gpio: hpd pin
  +- qcom,hdmi-tx-ddc-clk-gpios: ddc clk pin
  +- qcom,hdmi-tx-ddc-data-gpios: ddc data pin
 
 The driver doesn't appear to do anything other than set these gpios
 high. Presumably you would ultimately do a bit-bang i2c bus for these?
 At that point, aren't you going to want to use the i2c-gpio binding?
 
 I think this binding has bigger issues like why is it not using the
 hdmi-connector binding which has a standard hpd-gpios property
 already. I can't really single out this binding though. There's a lot
 of crap when it comes to DRM related bindings.
 

Shouldn't these pins just be muxed to the hdmi block in pinctl?

I know Rob had something wrt the detect pin (hdp), but the others should
never be gpios(?) Isn't this just a reminder of the codeaurora tree
gpio_requesting all pins just to be safe?

  +- qcom,hdmi-tx-hpd-gpios: hpd pin
   - core-vdda-supply: phandle to supply regulator
   - hdmi-mux-supply: phandle to mux regulator
 
  +- qcom,hdmi-tx-ddc-clk-gpio: (deprecated) use
  + qcom,hdmi-tx-ddc-clk-gpios instead
  +- qcom,hdmi-tx-ddc-data-gpio: (deprecated) use
  + qcom,hdmi-tx-ddc-data-gpios instead
  +- qcom,hdmi-tx-hpd-gpio: (deprecated) use
  + qcom,hdmi-tx-hpd-gpios instead
  +
   Optional properties:
  -- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
  -- qcom,hdmi-tx-mux-sel-gpio: hdmi mux select pin
  +- qcom,hdmi-tx-mux-en-gpios: hdmi mux enable pin
  +- qcom,hdmi-tx-mux-sel-gpios: hdmi mux select pin
  +
  +- qcom,hdmi-tx-mux-en-gpio: (deprecated) use qcom,hdmi-tx-mux-en-gpios
  + instead
  +- qcom,hdmi-tx-mux-sel-gpio: (deprecated) use qcom,hdmi-tx-mux-sel-gpio
  + instead
   - pinctrl-names: the pin control state names; should contain default
   - pinctrl-0: the default pinctrl state (active)
   - pinctrl-1: the sleep pinctrl state
 
  I don't see much use in listing that these properties are deprecated. We
  already have code to catch the deprecated names, so having them in the
  binding will at best be distracting.
 
  Anyway, I don't know if there's been any advice on this from the device
  tree bindings maintainers, so adding devicetree@vger.kernel.org for
  visibility.
 
 If they need to be maintained, then marking them deprecated is
 perfectly fine IMO. Also, if the maintainers of platforms using this
 are okay with it, you can just switch it. Given there are no in tree
 dts files using this, it can be argued that there is no ABI.
 

Part of some dev trees floating around no-one should have used these. So
I think we should just document the proper ones and have the drivers
support Rob's old properties until he's comfortable dropping them.

That way we have a documented way forward and Rob can run his backports
of this code without forking it.

Regards,
Bjorn
--
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 v2] backlight: pm8941-wled: Add default-brightness property

2015-08-10 Thread Bjorn Andersson 
Default the brightness to 2048 and add possibility to override this in
device tree.

Suggested-by: Rob Clark robdcl...@gmail.com
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---

After going back and forth on this one I decided that the best unit of this
property (which could become a common backlight property) would be to use
units of brightness. The value will either come from the boot loader picking
a value in some way or from a user finding a good value by tweaking sysfs -
both which will be in units of brightness.

 Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 2 ++
 drivers/video/backlight/pm8941-wled.c | 8 
 2 files changed, 10 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt 
b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
index 424f8444a6cd..e5b294dafc58 100644
--- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
@@ -5,6 +5,8 @@ Required properties:
 - reg: slave address
 
 Optional properties:
+- default-brightness: brightness value on boot, value from: 0-4095
+   default: 2048
 - label: The name of the backlight device
 - qcom,cs-out: bool; enable current sink output
 - qcom,cabc: bool; enable content adaptive backlight control
diff --git a/drivers/video/backlight/pm8941-wled.c 
b/drivers/video/backlight/pm8941-wled.c
index c704c3236034..e1298147bcbb 100644
--- a/drivers/video/backlight/pm8941-wled.c
+++ b/drivers/video/backlight/pm8941-wled.c
@@ -17,6 +17,9 @@
 #include linux/of_device.h
 #include linux/regmap.h
 
+/* From DT binding */
+#define PM8941_WLED_DEFAULT_BRIGHTNESS 2048
+
 #define PM8941_WLED_REG_VAL_BASE   0x40
 #define  PM8941_WLED_REG_VAL_MAX   0xFFF
 
@@ -373,6 +376,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
struct backlight_device *bl;
struct pm8941_wled *wled;
struct regmap *regmap;
+   u32 val;
int rc;
 
regmap = dev_get_regmap(pdev-dev.parent, NULL);
@@ -395,8 +399,12 @@ static int pm8941_wled_probe(struct platform_device *pdev)
if (rc)
return rc;
 
+   val = PM8941_WLED_DEFAULT_BRIGHTNESS;
+   of_property_read_u32(pdev-dev.of_node, default-brightness, val);
+
memset(props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
+   props.brightness = val;
props.max_brightness = PM8941_WLED_REG_VAL_MAX;
bl = devm_backlight_device_register(pdev-dev, wled-name,
pdev-dev, wled,
-- 
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] backlight: pm8941-wled: Add default-brightness property

2015-07-30 Thread Bjorn Andersson 
On Thu 30 Jul 08:26 PDT 2015, Rob Herring wrote:

 On Wed, Jul 29, 2015 at 6:51 PM, Bjorn Andersson
 bjorn.anders...@sonymobile.com wrote:
  On Fri 24 Jul 08:29 PDT 2015, Rob Herring wrote:
[..]
  As we're trying to specify a default brightness within the range [0,
  max_brightness) the latter doesn't make much sense.
 
  Therefor my suggestion is that we make the default-brightness the
  common property and we define it as a percentage of [0,max_brightness).
 
 Okay.
 
 I wonder if we should have units such as
 default-brightness-percentage or default-brightness-% so it is
 clear. Otherwise, we might have some people doing a range of [0,max].
 The former is a bit long and the latter is a bit unusual.
 

I discussed this further with my colleague and gave it some though over
the night;

If the boot loader sets the brightness, it would need to convert this to
a percentage just to have the kernel convert it back - with a expected
lack of precision (especially w/ non-linear brightness ranges or odd
step-sizes).

In the case where it's manually tweaked by the developer he/she would
most likely modify the brightness through sysfs until a reasonable value
is found; and we have that extra step again of converting this to a
percentage.


Therefor I think it's better to just specify this in units of
brightness - which would be a unit-less property.

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

[PATCHv2 0/4] Qualcomm Switch-Mode Battery Charger and Boost

2015-07-30 Thread Bjorn Andersson 
This series adds bindings and a device driver for the Qualcomm Switch-Mode
Battery Charger and Boost block found in pm8941.

Changes since v1:
- Corrected authorship of the patches
- Gave dt properties qcom vendor prefix
- Updated names of dt properties
- Dropped MODULE_ALIAS

Courtney Cavin (4):
  spmi: pmic-arb: add support for irq_get_irqchip_state
  dt-binding: power: Add Qualcomm SMBB binding
  power: Add Qualcomm SMBB driver
  ARM: dts: qcom-pm8941: Add charger node

 .../devicetree/bindings/power_supply/qcom_smbb.txt | 131 +++
 arch/arm/boot/dts/qcom-pm8941.dtsi |  21 +
 drivers/power/Kconfig  |  12 +
 drivers/power/Makefile |   1 +
 drivers/power/qcom_smbb.c  | 951 +
 drivers/spmi/spmi-pmic-arb.c   |  17 +
 6 files changed, 1133 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
 create mode 100644 drivers/power/qcom_smbb.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

[PATCHv2 4/4] ARM: dts: qcom-pm8941: Add charger node

2015-07-30 Thread Bjorn Andersson 
From: Courtney Cavin courtney.ca...@sonymobile.com

Signed-off-by: Courtney Cavin courtney.ca...@sonymobile.com
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---

Changes since v1:
- Corrected authorship

 arch/arm/boot/dts/qcom-pm8941.dtsi | 21 +
 1 file changed, 21 insertions(+)

diff --git a/arch/arm/boot/dts/qcom-pm8941.dtsi 
b/arch/arm/boot/dts/qcom-pm8941.dtsi
index aa774e685018..6063c7ddda0f 100644
--- a/arch/arm/boot/dts/qcom-pm8941.dtsi
+++ b/arch/arm/boot/dts/qcom-pm8941.dtsi
@@ -26,6 +26,27 @@
bias-pull-up;
};
 
+   charger@1000 {
+   compatible = qcom,pm8941-charger;
+   reg = 0x1000 0x700;
+   interrupts = 0x0 0x10 7 IRQ_TYPE_EDGE_BOTH,
+0x0 0x10 5 IRQ_TYPE_EDGE_BOTH,
+0x0 0x10 4 IRQ_TYPE_EDGE_BOTH,
+0x0 0x12 1 IRQ_TYPE_EDGE_BOTH,
+0x0 0x12 0 IRQ_TYPE_EDGE_BOTH,
+0x0 0x13 2 IRQ_TYPE_EDGE_BOTH,
+0x0 0x13 1 IRQ_TYPE_EDGE_BOTH,
+0x0 0x14 1 IRQ_TYPE_EDGE_BOTH;
+   interrupt-names = chg-done,
+ chg-fast,
+ chg-trkl,
+ bat-temp-ok,
+ bat-present,
+ chg-gone,
+ usb-valid,
+ dc-valid;
+   };
+
pm8941_gpios: gpios@c000 {
compatible = qcom,pm8941-gpio;
reg = 0xc000 0x2400;
-- 
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

[PATCHv2 2/4] dt-binding: power: Add Qualcomm SMBB binding

2015-07-30 Thread Bjorn Andersson 
From: Courtney Cavin courtney.ca...@sonymobile.com

Add the Qualcomm Switch-Mode Battery Charger and Boost device tree
binding.

Signed-off-by: Courtney Cavin courtney.ca...@sonymobile.com
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---

Changes since v1:
- Corrected authorship

 .../devicetree/bindings/power_supply/qcom_smbb.txt | 131 +
 1 file changed, 131 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/power_supply/qcom_smbb.txt

diff --git a/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt 
b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
new file mode 100644
index ..65b88fac854b
--- /dev/null
+++ b/Documentation/devicetree/bindings/power_supply/qcom_smbb.txt
@@ -0,0 +1,131 @@
+Qualcomm Switch-Mode Battery Charger and Boost
+
+PROPERTIES
+- compatible:
+  Usage: required
+  Value type: stringlist
+  Description: Must be one of:
+   - qcom,pm8941-charger
+
+- reg:
+  Usage: required
+  Value type: prop-encoded-array
+  Description: Base address of registers for SMBB block
+
+- interrupts:
+  Usage: required
+  Value type: prop-encoded-array
+  Description: The format of the specifier is defined by the binding document
+   describing the node's interrupt parent.  Must contain one
+   specifier for each of the following interrupts, in order:
+   - charge done
+   - charge fast mode
+   - charge trickle mode
+   - battery temperature ok
+   - battery present
+   - charger disconnected
+   - USB-in valid
+   - DC-in valid
+
+- interrupt-names:
+  Usage: required
+  Value type: stringlist
+  Description: Must contain the following list, strictly ordered:
+   chg-done,
+   chg-fast,
+   chg-trkl,
+   bat-temp-ok,
+   bat-present,
+   chg-gone,
+   usb-valid,
+   dc-valid
+
+- qcom,fast-charge-current-limit:
+  Usage: optional (default: 1A, or pre-configured value)
+  Value type: u32; uA; range [100mA : 3A]
+  Description: Maximum charge current; May be clamped to safety limits.
+
+- qcom,fast-charge-low-threshold-voltage:
+  Usage: optional (default: 3.2V, or pre-configured value)
+  Value type: u32; uV; range [2.1V : 3.6V]
+  Description: Battery voltage limit above which fast charging may operate;
+   Below this value linear or switch-mode auto-trickle-charging
+   will operate.
+
+- qcom,fast-charge-high-threshold-voltage:
+  Usage: optional (default: 4.2V, or pre-configured value)
+  Value type: u32; uV; range [3.24V : 5V]
+  Description: Battery voltage limit below which fast charging may operate;
+   The fast charger will attempt to charge the battery to this
+   voltage.  May be clamped to safety limits.
+
+- qcom,fast-charge-safe-voltage:
+  Usage: optional (default: 4.2V, or pre-configured value)
+  Value type: u32; uV; range [3.24V : 5V]
+  Description: Maximum safe battery voltage; May be pre-set by bootloader, in
+   which case, setting this will harmlessly fail. The property
+   'fast-charge-high-watermark' will be clamped by this value.
+
+- qcom,fast-charge-safe-current:
+  Usage: optional (default: 1A, or pre-configured value)
+  Value type: u32; uA; range [100mA : 3A]
+  Description: Maximum safe battery charge current; May pre-set by bootloader,
+   in which case, setting this will harmlessly fail. The property
+   'qcom,fast-charge-current-limit' will be clamped by this value.
+
+- qcom,auto-recharge-threshold-voltage:
+  Usage: optional (default: 4.1V, or pre-configured value)
+  Value type: u32; uV; range [3.24V : 5V]
+  Description: Battery voltage limit below which auto-recharge functionality
+   will restart charging after end-of-charge;  The high cutoff
+   limit for auto-recharge is 5% above this value.
+
+- qcom,minimum-input-voltage:
+  Usage: optional (default: 4.3V, or pre-configured value)
+  Value type: u32; uV; range [4.2V : 9.6V]
+  Description: Input voltage level above which charging may operate
+
+- qcom,dc-current-limit:
+  Usage: optional (default: 100mA, or pre-configured value)
+  Value type: u32; uA; range [100mA : 2.5A]
+  Description: Default DC charge current limit
+
+- qcom,disable-dc:
+  Usage: optional (default: false)
+  Value type: boolean: u32 or empty
+  Description: Disable DC charger
+
+- qcom,jeita-extended-temp-range:
+  Usage: optional (default: false)
+  Value type: boolean: u32 or empty
+  Description: Enable JEITA extended temperature range;  This does *not*
+   adjust the maximum charge voltage or current in the extended
+   temperature range.  It only allows charging when the battery
+   is in the extended temperature range.  Voltage/current
+   regulation must

Re: [PATCH] backlight: pm8941-wled: Add default-brightness property

2015-07-29 Thread Bjorn Andersson 
On Fri 24 Jul 10:41 PDT 2015, Rob Clark wrote:

 On Fri, Jul 24, 2015 at 11:39 AM, Rob Herring robherri...@gmail.com wrote:
  On Fri, Jul 24, 2015 at 8:10 AM, Rob Clark robdcl...@gmail.com wrote:
  On Thu, Jul 23, 2015 at 3:52 PM, Bjorn Andersson
  bjorn.anders...@sonymobile.com wrote:
  Add the possibility of specifying the default brightness in DT.
 
  Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
  ---
 
  This depends on the patch moving pm8941-wled to backlight [1]. The dt 
  property
  is used by several other backlight drivers, so I considered this to be a
  common property and it's hence not prefixed with qcom,.
 
  [1] https://lkml.org/lkml/2015/7/21/906
 
   Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 1 +
   drivers/video/backlight/pm8941-wled.c | 4 
  
   2 files changed, 5 insertions(+)
 
  diff --git 
  a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt 
  b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
  index 424f8444a6cd..37503f8c3620 100644
  --- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
  +++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
  @@ -5,6 +5,7 @@ Required properties:
   - reg: slave address
 
   Optional properties:
  +- default-brightness: value from: 0-4095
   - label: The name of the backlight device
   - qcom,cs-out: bool; enable current sink output
   - qcom,cabc: bool; enable content adaptive backlight control
  diff --git a/drivers/video/backlight/pm8941-wled.c 
  b/drivers/video/backlight/pm8941-wled.c
  index c704c3236034..b875e58df0fc 100644
  --- a/drivers/video/backlight/pm8941-wled.c
  +++ b/drivers/video/backlight/pm8941-wled.c
  @@ -373,6 +373,7 @@ static int pm8941_wled_probe(struct platform_device 
  *pdev)
  struct backlight_device *bl;
  struct pm8941_wled *wled;
  struct regmap *regmap;
  +   u32 val = 0;
  int rc;
 
  as discussed on IRC, it would be better if the default read back the
  current settings (so-as to inherit bootloader splash smoothly..
  drm/msm supports a memory-region phandle, for example, so it can take
  over the bootloader splash-screen as stolen-mem)
 
  and it would I think be useful to have a comment in the bindings file
  explaining that you *should* use the default-brightness property to
  set a sane default if bootloader isn't putting up a splash, and you
  should *not* use the property if it is..
 
  +1
 
  What if you have neither? Set to max brightness? 75%?
 
 I did chat w/ Bjorn a bit about that on irc..  his concern was some
 arbitrary percentage (like 50%) might be more or less bright depending
 on the device (although that implies to me that maybe we should have
 min and max bindings as well, rather than just assuming hw limits?
 idk)
 

But this issue could easily be solved by having the boot loader pass an
appropriate value to the kernel through the dt property, overriding any
default from the implementation.

Or in the case when the boot does not touch the backlight the dt writer
still have the possibility of picking a better value.

 my preference is the default is somehow at least not 0%.. possibly
 motivated by the expectation that when people see a dark screen at
 boot they assume the display driver is broken :-P
 

Right

  This could also be used for the bootloader to communicate to the
  kernel what the current level is if it is not readable. I've seen one
  backlight recently which you change the level by doing some number of
  pulses on a gpio and a long pulse to turn off. So there is no way to
  know current level without turning off the backlight (unless you
  hardcode the bootloader's level in the kernel like the vendor did).
 

Right and even in the case of this driver I feel it's just adding
accidental complexity.


50% would solve Rob's problem and we're through the dt property
providing the necessary means of changing this, either to match boot
loader set levels or developers preferences.

I'll rephrase the binding document and update the driver.

Regards,
Bjorn
--
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] backlight: pm8941-wled: Add default-brightness property

2015-07-29 Thread Bjorn Andersson 
On Fri 24 Jul 08:29 PDT 2015, Rob Herring wrote:

 On Thu, Jul 23, 2015 at 2:52 PM, Bjorn Andersson
 bjorn.anders...@sonymobile.com wrote:
  Add the possibility of specifying the default brightness in DT.
 
  Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
  ---
 
  This depends on the patch moving pm8941-wled to backlight [1]. The dt 
  property
  is used by several other backlight drivers, so I considered this to be a
  common property and it's hence not prefixed with qcom,.
 
 Well, we have default-brightness and default-brightness-level used
 by 1 driver each. But default-brightness-level is much more commonly
 used (in dts files) since it is in the pwm backlight binding, so we
 should go with it. I'd like to see this moved to a common backlight
 doc.
 

As I looked at these, the default-brightness used in tps65217 is a value
between 0 and 100, so that can be interpreted as a percentage.

The pwm binding however uses a separate array of brightness-levels and
then default-brightness-level is supposed to be an index into that
array.


As we're trying to specify a default brightness within the range [0,
max_brightness) the latter doesn't make much sense.

Therefor my suggestion is that we make the default-brightness the
common property and we define it as a percentage of [0,max_brightness).

 Really, I think all the backlight documentation should be merged with
 LEDs docs. Things like default-on are common. But I won't ask to do
 that here.

I think the backlight framework should be merged with the LED framework.
There's several hw blocks that are split between the two, with an mfd
tying them together...

Regards,
Bjorn
--
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 v1 1/7] ARM: dts: ifc6410: Add pwrseq support for WLAN

2015-07-29 Thread Bjorn Andersson 
On Tue 28 Jul 05:53 PDT 2015, Srinivas Kandagatla wrote:

 This patch adds pwrseq for WLAN which resets the WLAN just before the
 SDIO bus is up.
 

Does this mean that we have the !power-of-2 patch in mmc on the way?

 Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
 ---
  arch/arm/boot/dts/qcom-apq8064-ifc6410.dts | 24 
  1 file changed, 24 insertions(+)
 
 diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts 
 b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
 index 88d6655..df560cf 100644
 --- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
 +++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
 @@ -1,5 +1,6 @@
  #include qcom-apq8064-v2.0.dtsi
  #include dt-bindings/gpio/gpio.h
 +#include dt-bindings/pinctrl/qcom,pmic-gpio.h
  
  / {
   model = Qualcomm APQ8064/IFC6410;
 @@ -206,6 +207,28 @@
   status = okay;
   };
  
 + qcom,ssbi@50 {
 + pmicintc: pmic@0 {
 + pm8921_gpio: gpio@150 {

These should already be labeled in the apq8064 dtsi (or in a
qcom-pm8921.dtsi).

 + pinctrl-names = default;
 + pinctrl-0 = wlan_default_gpios;

Please move these to the pwrseq node, as that's the consumer of this.

 + wlan_default_gpios: wlan-gpios {
 + pios {
 + pins = gpio43;
 + function = normal;
 + bias-disable;
 + power-source = 
 PM8921_GPIO_S4;
 + };
 + };
 + };
 + };
 + };

Regards,
Bjorn
--
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/2] drm/panel: Add Sharp LS043T1LE01 panel binding documentation

2015-07-28 Thread Bjorn Andersson 
From: Werner Johansson werner.johans...@sonymobile.com

Signed-off-by: Werner Johansson werner.johans...@sonymobile.com
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
 .../bindings/panel/sharp,ls043t1le01.txt   | 22 ++
 1 file changed, 22 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt

diff --git a/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt 
b/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt
new file mode 100644
index ..758d48d33e46
--- /dev/null
+++ b/Documentation/devicetree/bindings/panel/sharp,ls043t1le01.txt
@@ -0,0 +1,22 @@
+Sharp Microelectronics 4.3 qHD TFT LCD panel
+
+Required properties:
+- compatible: should be sharp,ls043t1le01-qhd-vid
+- reg: DSI virtual channel of the peripheral
+- power-supply: phandle of the regulator that provides the supply voltage
+
+Optional properties:
+- backlight: phandle of the backlight device attached to the panel
+- reset-gpios: a GPIO spec for the reset pin
+
+Example:
+
+   mdss_dsi0: qcom,mdss_dsi@fd922800 {
+   panel: panel@0 {
+   compatible = sharp,ls043t1le01-qhd-vid;
+   reg = 0;
+   avdd-supply = pm8941_l22;
+   backlight = pm8941_wled;
+   reset-gpios = pm8941_gpios 19 GPIO_ACTIVE_HIGH;
+   };
+   };
-- 
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] of: Add vendor prefix for Sharp Microelectronics

2015-07-28 Thread Bjorn Andersson 
On Wed, Jul 1, 2015 at 10:41 AM, Rob Herring robherri...@gmail.com wrote:
 On Wed, Jul 1, 2015 at 7:01 AM, Thierry Reding thierry.red...@gmail.com 
 wrote:
 On Mon, Oct 13, 2014 at 01:54:09PM +0200, Thierry Reding wrote:
 On Fri, Aug 01, 2014 at 03:50:44PM +0200, Thierry Reding wrote:
  From: Thierry Reding tred...@nvidia.com
 
  Use sharp as the vendor prefix for Sharp Microelectronics in device
  tree compatible strings.
 
  Signed-off-by: Thierry Reding tred...@nvidia.com
  ---
   Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
   1 file changed, 1 insertion(+)

 Ping?

 Rob, I just stumbled across this in my stack of patches that never got
 merged. Can you ack this?

 Sorry, missed this one. I've flagged it now to apply for 4.2 or you
 can if you prefer:

 Acked-by: Rob Herring r...@kernel.org


Sorry for jumping in late, but found this as I was about to submit a
patch for the same addition.

Except that from what I can find the real name is Sharp
Microelectronics of the Americas (or Europe...), which is a division
of Sharp Electronics Corporation, a subsidiary of Sharp Corporation -
the latter which is what's used in the data sheets for my e.g. the
lp855x.

So I think the patch should instead be adding:
sharp   Sharp Corporation

Regards,
Bjorn
--
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 0/5] Qualcomm Shared Memory RPM drivers

2015-07-27 Thread Bjorn Andersson 
The third iteration of the patches to add support for the regulators provided
by the RPM on family B Qualcomm devices.

This depends on the SMEM implementation that Andy already picked up.

Changes since v2:
- Made smd copy functions work on words for the word access channels
- Corrected access of smem items from secure heap
- Updated error handling path in RPM driver
- Moved init of smd to postcore and rpm to arch
- Minor nits from Georgi on the SMD code
- Moved rpm driver from mfd to soc

Bjorn Andersson (5):
  soc: qcom: Add device tree binding for Shared Memory Device
  soc: qcom: Add Shared Memory Driver
  devicetree: soc: Add Qualcomm SMD based RPM DT binding
  soc: qcom: Driver for the Qualcomm RPM over SMD
  regulator: Regulator driver for the Qualcomm RPM

 .../devicetree/bindings/soc/qcom,smd-rpm.txt   |  117 ++
 .../devicetree/bindings/soc/qcom/qcom,smd.txt  |   79 ++
 drivers/regulator/Kconfig  |   12 +
 drivers/regulator/Makefile |1 +
 drivers/regulator/qcom_smd-regulator.c |  349 ++
 drivers/soc/qcom/Kconfig   |   22 +
 drivers/soc/qcom/Makefile  |2 +
 drivers/soc/qcom/smd-rpm.c |  244 
 drivers/soc/qcom/smd.c | 1319 
 include/linux/soc/qcom/smd-rpm.h   |   35 +
 include/linux/soc/qcom/smd.h   |   46 +
 11 files changed, 2226 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
 create mode 100644 drivers/regulator/qcom_smd-regulator.c
 create mode 100644 drivers/soc/qcom/smd-rpm.c
 create mode 100644 drivers/soc/qcom/smd.c
 create mode 100644 include/linux/soc/qcom/smd-rpm.h
 create mode 100644 include/linux/soc/qcom/smd.h

-- 
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 v3 1/5] soc: qcom: Add device tree binding for Shared Memory Device

2015-07-27 Thread Bjorn Andersson 
Add device tree binding documentation for the Qualcomm Shared Memory
Device, used for communication between the various CPUs in the Qualcomm
SoCs.

Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---

No changes since v2

 .../devicetree/bindings/soc/qcom/qcom,smd.txt  | 79 ++
 1 file changed, 79 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt

diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt 
b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
new file mode 100644
index ..f65c76db9859
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd.txt
@@ -0,0 +1,79 @@
+Qualcomm Shared Memory Driver (SMD) binding
+
+This binding describes the Qualcomm Shared Memory Driver, a fifo based
+communication channel for sending data between the various subsystems in
+Qualcomm platforms.
+
+- compatible:
+   Usage: required
+   Value type: stringlist
+   Definition: must be qcom,smd
+
+= EDGES
+
+Each subnode of the SMD node represents a remote subsystem or a remote
+processor of some sort - or in SMD language an edge. The name of the edges
+are not important.
+The edge is described by the following properties:
+
+- interrupts:
+   Usage: required
+   Value type: prop-encoded-array
+   Definition: should specify the IRQ used by the remote processor to
+   signal this processor about communication related updates
+
+- qcom,ipc:
+   Usage: required
+   Value type: prop-encoded-array
+   Definition: three entries specifying the outgoing ipc bit used for
+   signaling the remote processor:
+   - phandle to a syscon node representing the apcs registers
+   - u32 representing offset to the register within the syscon
+   - u32 representing the ipc bit within the register
+
+- qcom,smd-edge:
+   Usage: required
+   Value type: u32
+   Definition: the identifier of the remote processor in the smd channel
+   allocation table
+
+= SMD DEVICES
+
+In turn, subnodes of the edges represent devices tied to SMD channels on that
+edge. The names of the devices are not important. The properties of these
+nodes are defined by the individual bindings for the SMD devices - but must
+contain the following property:
+
+- qcom,smd-channels:
+   Usage: required
+   Value type: stringlist
+   Definition: a list of channels tied to this device, used for matching
+   the device to channels
+
+= EXAMPLE
+
+The following example represents a smd node, with one edge representing the
+rpm subsystem. For the rpm subsystem we have a device tied to the
+rpm_request channel.
+
+   apcs: syscon@f9011000 {
+   compatible = syscon;
+   reg = 0xf9011000 0x1000;
+   };
+
+   smd {
+   compatible = qcom,smd;
+
+   rpm {
+   interrupts = 0 168 1;
+   qcom,ipc = apcs 8 0;
+   qcom,smd-edge = 15;
+
+   rpm_requests {
+   compatible = qcom,rpm-msm8974;
+   qcom,smd-channels = rpm_requests;
+
+   ...
+   };
+   };
+   };
-- 
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 v3 3/5] devicetree: soc: Add Qualcomm SMD based RPM DT binding

2015-07-27 Thread Bjorn Andersson 
Add binding documentation for the Qualcomm Resource Power Manager (RPM)
using shared memory (Qualcomm SMD) as transport mechanism. This is found
in 8974 and newer based devices.

The binding currently describes the rpm itself and the regulator
subnodes.

Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---

Changes since v2:
- Moved from mfd

 .../devicetree/bindings/soc/qcom,smd-rpm.txt   | 117 +
 1 file changed, 117 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt

diff --git a/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt 
b/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
new file mode 100644
index ..e27f5c4c54fd
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/qcom,smd-rpm.txt
@@ -0,0 +1,117 @@
+Qualcomm Resource Power Manager (RPM) over SMD
+
+This driver is used to interface with the Resource Power Manager (RPM) found in
+various Qualcomm platforms. The RPM allows each component in the system to vote
+for state of the system resources, such as clocks, regulators and bus
+frequencies.
+
+- compatible:
+   Usage: required
+   Value type: string
+   Definition: must be one of:
+   qcom,rpm-msm8974
+
+- qcom,smd-channels:
+   Usage: required
+   Value type: stringlist
+   Definition: Shared Memory channel used for communication with the RPM
+
+= SUBDEVICES
+
+The RPM exposes resources to its subnodes. The below bindings specify the set
+of valid subnodes that can operate on these resources.
+
+== Regulators
+
+Regulator nodes are identified by their compatible:
+
+- compatible:
+   Usage: required
+   Value type: string
+   Definition: must be one of:
+   qcom,rpm-pm8841-regulators
+   qcom,rpm-pm8941-regulators
+
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_s4-supply:
+- vdd_s5-supply:
+- vdd_s6-supply:
+- vdd_s7-supply:
+- vdd_s8-supply:
+   Usage: optional (pm8841 only)
+   Value type: phandle
+   Definition: reference to regulator supplying the input pin, as
+   described in the data sheet
+
+- vdd_s1-supply:
+- vdd_s2-supply:
+- vdd_s3-supply:
+- vdd_l1_l3-supply:
+- vdd_l2_lvs1_2_3-supply:
+- vdd_l4_l11-supply:
+- vdd_l5_l7-supply:
+- vdd_l6_l12_l14_l15-supply:
+- vdd_l8_l16_l18_l19-supply:
+- vdd_l9_l10_l17_l22-supply:
+- vdd_l13_l20_l23_l24-supply:
+- vdd_l21-supply:
+- vin_5vs-supply:
+   Usage: optional (pm8941 only)
+   Value type: phandle
+   Definition: reference to regulator supplying the input pin, as
+   described in the data sheet
+
+The regulator node houses sub-nodes for each regulator within the device. Each
+sub-node is identified using the node's name, with valid values listed for each
+of the pmics below.
+
+pm8841:
+   s1, s2, s3, s4, s5, s6, s7, s8
+
+pm8941:
+   s1, s2, s3, s4, l1, l2, l3, l4, l5, l6, l7, l8, l9, l10, l11, l12, l13,
+   l14, l15, l16, l17, l18, l19, l20, l21, l22, l23, l24, lvs1, lvs2,
+   lvs3, 5vs1, 5vs2
+
+The content of each sub-node is defined by the standard binding for regulators 
-
+see regulator.txt.
+
+= EXAMPLE
+
+   smd {
+   compatible = qcom,smd;
+
+   rpm {
+   interrupts = 0 168 1;
+   qcom,ipc = apcs 8 0;
+   qcom,smd-edge = 15;
+
+   rpm_requests {
+   compatible = qcom,rpm-msm8974;
+   qcom,smd-channels = rpm_requests;
+
+   pm8941-regulators {
+   compatible = 
qcom,rpm-pm8941-regulators;
+   vdd_l13_l20_l23_l24-supply = 
pm8941_boost;
+
+   pm8941_s3: s3 {
+   regulator-min-microvolt = 
180;
+   regulator-max-microvolt = 
180;
+   };
+
+   pm8941_boost: s4 {
+   regulator-min-microvolt = 
500;
+   regulator-max-microvolt = 
500;
+   };
+
+   pm8941_l20: l20 {
+   regulator-min-microvolt = 
295;
+   regulator-max-microvolt = 
295;
+   };
+   };
+   };
+   };
+   };
+
-- 
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] backlight: pm8941-wled: Add default-brightness property

2015-07-23 Thread Bjorn Andersson 
Add the possibility of specifying the default brightness in DT.

Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---

This depends on the patch moving pm8941-wled to backlight [1]. The dt property
is used by several other backlight drivers, so I considered this to be a
common property and it's hence not prefixed with qcom,.

[1] https://lkml.org/lkml/2015/7/21/906

 Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt | 1 +
 drivers/video/backlight/pm8941-wled.c | 4 
 2 files changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt 
b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
index 424f8444a6cd..37503f8c3620 100644
--- a/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
@@ -5,6 +5,7 @@ Required properties:
 - reg: slave address
 
 Optional properties:
+- default-brightness: value from: 0-4095
 - label: The name of the backlight device
 - qcom,cs-out: bool; enable current sink output
 - qcom,cabc: bool; enable content adaptive backlight control
diff --git a/drivers/video/backlight/pm8941-wled.c 
b/drivers/video/backlight/pm8941-wled.c
index c704c3236034..b875e58df0fc 100644
--- a/drivers/video/backlight/pm8941-wled.c
+++ b/drivers/video/backlight/pm8941-wled.c
@@ -373,6 +373,7 @@ static int pm8941_wled_probe(struct platform_device *pdev)
struct backlight_device *bl;
struct pm8941_wled *wled;
struct regmap *regmap;
+   u32 val = 0;
int rc;
 
regmap = dev_get_regmap(pdev-dev.parent, NULL);
@@ -395,8 +396,11 @@ static int pm8941_wled_probe(struct platform_device *pdev)
if (rc)
return rc;
 
+   of_property_read_u32(pdev-dev.of_node, default-brightness, val);
+
memset(props, 0, sizeof(struct backlight_properties));
props.type = BACKLIGHT_RAW;
+   props.brightness = val;
props.max_brightness = PM8941_WLED_REG_VAL_MAX;
bl = devm_backlight_device_register(pdev-dev, wled-name,
pdev-dev, wled,
-- 
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 v2 05/11] mfd: devicetree: bindings: Add Qualcomm SMD based RPM DT binding

2015-07-23 Thread Bjorn Andersson 
On Thu 23 Jul 06:31 PDT 2015, Lee Jones wrote:

 On Mon, 13 Jul 2015, Bjorn Andersson wrote:
 
  On Tue 07 Jul 05:16 PDT 2015, Lee Jones wrote:
  
   FAO Mark and DT chaps,
   
From: Bjorn Andersson bjorn.anders...@sonymobile.com

Add binding documentation for the Qualcomm Resource Power Manager (RPM)
using shared memory (Qualcomm SMD) as transport mechanism. This is found
in 8974 and newer based devices.

The binding currently describes the rpm itself and the regulator
subnodes.

Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
 .../devicetree/bindings/mfd/qcom-rpm-smd.txt   | 117 
+
 include/dt-bindings/mfd/qcom-smd-rpm.h |  28 +
 2 files changed, 145 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
 create mode 100644 include/dt-bindings/mfd/qcom-smd-rpm.h

diff --git a/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt 
b/Documentation/devicetree/bindings/mfd/qcom-rpm-smd.txt
  
  [..]
  
+- qcom,smd-channels:
+   Usage: required
+   Value type: stringlist
+   Definition: Shared Memory channel used for communication with 
the RPM
   
   This is going to require a DT Ack.
   
   Also, I don't see it being used anywhere.
  
  It's a common property of all smd devices, defining the smd channel this
  driver should bind to.
 
 Well it's not in the kernel and I can't find the patch that uses it,
 so my points still stand.
 

Patch 3 in this series defines the binding and patch 4 is an
implementation of this binding.

+= EXAMPLE
+
+   smd {
+   compatible = qcom,smd;
   
   Is an SMD (Shared Memory Device?) real hardware?
   
  
  SMD is a mechanism for using shared memory for point-to-point
  communication channels with remote processors in all Qualcomm platforms.
  
  So it's not hardware, it's the control mechanism for communicating with
  real hardware.
 
 Then you can't have a node for it.  Virtual nodes which do not
 represent real h/w are not allowed in Device Tree.
 

It represent the structure of a Qualcomm platform, but there's not a 1:1
mapping between this node and a discrete component. And without the
information it carries there's no way for us to reach e.g. the RPM -
which is a discrete physical component.

But I understand that this discussion should be held on patch 3 and with
the DT maintainers.

+   rpm {
+   interrupts = 0 168 1;
+   qcom,ipc = apcs 8 0;
+   qcom,smd-edge = 15;
   
   The child node won't probe without a compatible string.  Shouldn't
   qcom,rpm-msm8974 be in here instead?
   
  
  These sub-nodes represents a logical grouping of the various channels
  that exist to this remote processor. For the rpm there is only the
  rpm_requests channel - used for sending regulator  clock requests.
 
 Again, if it's not real h/w and don't have a proper driver, there
 should be no reason for this node to exist.
 

We need to get hold of the interrupts and that regmap to be able to
communicate with the RPM. If this information is not in DT there will be
no communication - further we can not move it into the RPM node as with
all other remote processors (WiFi, DSP etc) these resources are shared
between a number of drivers.

+   rpm_requests {
   
   This node appears to be undocumented.
  
  This is the actual rpm device node, the smd  rpm nodes above are
  included for completeness of the example.
  
  They should perhaps be dropped to make this clearer.
  
   Does it represent real h/w?
   
  
  The other end of this smd channel is a micro controller that handles
  regulator and clock requests for the platform - so this is hardware.
  
  This is equivalent to the qcom_rpm driver, but instead of a hardware
  like register window this uses the same packet based messaging mechanism
  that's used for other remote peripherals in the Qualcomm platform.
 
 This needs a good review by the DT guys.
 

Sure

+   compatible = qcom,rpm-msm8974;
+   qcom,smd-channels = rpm_requests;
+
+   pm8941-regulators {
+   compatible = 
qcom,rpm-pm8941-regulators;
+   vdd_l13_l20_l23_l24-supply = 
pm8941_boost;
   
   I'd like Mark to glance at this.
   
  
  Right.
  
+   pm8941_s3: s3 {
+   regulator-min-microvolt 
= 180;
+   regulator-max-microvolt 
= 180;
   
   Aren't these fixed regulators?
   
  
  In this system configuration most of the regulators have fixed values,
  but the regulators (hw) are not fixed

[PATCH v2] backlight: pm8941-wled: Move PM8941 WLED driver to backlight

2015-07-21 Thread Bjorn Andersson 
The Qualcomm PM8941 WLED block is used for backlight and should therefor
be in the backlight framework and not in the LED framework. This moves
the driver and adapts to the backlight api instead.

Acked-by: Jacek Anaszewski j.anaszew...@samsung.com
Tested-by: Rob Clark robdcl...@gmail.com
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
 .../backlight/pm8941-wled.txt} |  5 +-
 drivers/leds/Kconfig   |  8 ---
 drivers/leds/Makefile  |  1 -
 drivers/video/backlight/Kconfig|  7 +++
 drivers/video/backlight/Makefile   |  1 +
 .../backlight/pm8941-wled.c}   | 60 ++
 6 files changed, 35 insertions(+), 47 deletions(-)
 rename Documentation/devicetree/bindings/{leds/leds-pm8941-wled.txt = 
video/backlight/pm8941-wled.txt} (84%)
 rename drivers/{leds/leds-pm8941-wled.c = video/backlight/pm8941-wled.c} (90%)

diff --git a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt 
b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
similarity index 84%
rename from Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
rename to Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
index a85a964d61f5..424f8444a6cd 100644
--- a/Documentation/devicetree/bindings/leds/leds-pm8941-wled.txt
+++ b/Documentation/devicetree/bindings/video/backlight/pm8941-wled.txt
@@ -5,10 +5,7 @@ Required properties:
 - reg: slave address
 
 Optional properties:
-- label: The label for this led
-  See Documentation/devicetree/bindings/leds/common.txt
-- linux,default-trigger: Default trigger assigned to the LED
-  See Documentation/devicetree/bindings/leds/common.txt
+- label: The name of the backlight device
 - qcom,cs-out: bool; enable current sink output
 - qcom,cabc: bool; enable content adaptive backlight control
 - qcom,ext-gen: bool; use externally generated modulator signal to dim
diff --git a/drivers/leds/Kconfig b/drivers/leds/Kconfig
index 9ad35f72ab4c..b8d4b965ca2a 100644
--- a/drivers/leds/Kconfig
+++ b/drivers/leds/Kconfig
@@ -578,14 +578,6 @@ config LEDS_VERSATILE
  This option enabled support for the LEDs on the ARM Versatile
  and RealView boards. Say Y to enabled these.
 
-config LEDS_PM8941_WLED
-   tristate LED support for the Qualcomm PM8941 WLED block
-   depends on LEDS_CLASS
-   select REGMAP
-   help
- This option enables support for the 'White' LED block
- on Qualcomm PM8941 PMICs.
-
 comment LED Triggers
 source drivers/leds/trigger/Kconfig
 
diff --git a/drivers/leds/Makefile b/drivers/leds/Makefile
index 8d6a24a2f513..abe96d960ebe 100644
--- a/drivers/leds/Makefile
+++ b/drivers/leds/Makefile
@@ -63,7 +63,6 @@ obj-$(CONFIG_LEDS_BLINKM) += leds-blinkm.o
 obj-$(CONFIG_LEDS_SYSCON)  += leds-syscon.o
 obj-$(CONFIG_LEDS_VERSATILE)   += leds-versatile.o
 obj-$(CONFIG_LEDS_MENF21BMC)   += leds-menf21bmc.o
-obj-$(CONFIG_LEDS_PM8941_WLED) += leds-pm8941-wled.o
 obj-$(CONFIG_LEDS_KTD2692) += leds-ktd2692.o
 
 # LED SPI Drivers
diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 0505b796d743..5ffa4b4e26c0 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -299,6 +299,13 @@ config BACKLIGHT_TOSA
  If you have an Sharp SL-6000 Zaurus say Y to enable a driver
  for its backlight
 
+config BACKLIGHT_PM8941_WLED
+   tristate Qualcomm PM8941 WLED Driver
+   select REGMAP
+   help
+ If you have the Qualcomm PM8941, say Y to enable a driver for the
+ WLED block.
+
 config BACKLIGHT_SAHARA
tristate Tabletkiosk Sahara Touch-iT Backlight Driver
depends on X86
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index d67073f9d421..16ec534cff30 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_BACKLIGHT_OMAP1) += omap1_bl.o
 obj-$(CONFIG_BACKLIGHT_OT200)  += ot200_bl.o
 obj-$(CONFIG_BACKLIGHT_PANDORA)+= pandora_bl.o
 obj-$(CONFIG_BACKLIGHT_PCF50633)   += pcf50633-backlight.o
+obj-$(CONFIG_BACKLIGHT_PM8941_WLED)+= pm8941-wled.o
 obj-$(CONFIG_BACKLIGHT_PWM)+= pwm_bl.o
 obj-$(CONFIG_BACKLIGHT_SAHARA) += kb3886_bl.o
 obj-$(CONFIG_BACKLIGHT_SKY81452)   += sky81452-backlight.o
diff --git a/drivers/leds/leds-pm8941-wled.c 
b/drivers/video/backlight/pm8941-wled.c
similarity index 90%
rename from drivers/leds/leds-pm8941-wled.c
rename to drivers/video/backlight/pm8941-wled.c
index bf64a593fbf1..c704c3236034 100644
--- a/drivers/leds/leds-pm8941-wled.c
+++ b/drivers/video/backlight/pm8941-wled.c
@@ -11,7 +11,7 @@
  */
 
 #include linux/kernel.h
-#include linux/leds.h
+#include linux/backlight.h
 #include linux/module.h
 #include linux/of.h
 #include linux

Re: [PATCH v2] backlight: pm8941-wled: Move PM8941 WLED driver to backlight

2015-07-21 Thread Bjorn Andersson 
On Tue 21 Jul 17:44 PDT 2015, Bjorn Andersson wrote:

 The Qualcomm PM8941 WLED block is used for backlight and should therefor
 be in the backlight framework and not in the LED framework. This moves
 the driver and adapts to the backlight api instead.
 
 Acked-by: Jacek Anaszewski j.anaszew...@samsung.com
 Tested-by: Rob Clark robdcl...@gmail.com
 Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
 ---

Sorry, forgot the changelog.

Changed since v1:
- Moved dt binding document to backlight
- Dropped LED_CLASS as dependency

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

  1   2   3   4   5   >