Re: [PATCH 2/3] pinctrl: qcom: Use platform_irq_count() instead of of_irq_count()

[Bjorn Andersson]

On Wed, Jan 6, 2016 at 5:12 PM, Stephen Boyd  wrote:
> of_irq_count() is not an exported symbol (and it shouldn't be
> used by platform drivers anyway) so use platform_irq_count()
> instead. This allows us to make the qcom pinctrl drivers modular
> again.
>
[..]
> diff --git a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c 
> b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
> index 3ddb4cc38f1c..37ae6b72ea35 100644
> --- a/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
> +++ b/drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c
> @@ -758,16 +758,19 @@ static int pm8xxx_mpp_probe(struct platform_device 
> *pdev)
> struct pinctrl_pin_desc *pins;
> struct pm8xxx_mpp *pctrl;
> int ret;
> -   int i;
> +   int i, npins;
>
> pctrl = devm_kzalloc(>dev, sizeof(*pctrl), GFP_KERNEL);
> if (!pctrl)
> return -ENOMEM;
>
> pctrl->dev = >dev;
> -   pctrl->npins = of_irq_count(pdev->dev.of_node);
> -   if (!pctrl->npins)
> +   npins = of_irq_count(pdev->dev.of_node);

platform_irq_count(pdev)

> +   if (!npins)
> return -EINVAL;
> +   if (npins < 0)
> +   return npins;
> +   pctrl->npins = npins;
>
> pctrl->regmap = dev_get_regmap(pdev->dev.parent, NULL);
> if (!pctrl->regmap) {

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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 linux-arm-msm" 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/4] wcn36xx: Change indication list lock to spinlock

[Bjorn Andersson]

On Mon 28 Dec 15:06 PST 2015, Stephen Hemminger wrote:

> On Sun, 27 Dec 2015 17:34:25 -0800
> Bjorn Andersson <bj...@kryo.se> wrote:
> 
> > In preparation for handling incoming messages from IRQ context, change
> > the indication list lock to a spinlock
> > 
> > Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> > ---
> >  drivers/net/wireless/ath/wcn36xx/smd.c | 12 ++--
> >  drivers/net/wireless/ath/wcn36xx/wcn36xx.h |  2 +-
> >  2 files changed, 7 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
> > b/drivers/net/wireless/ath/wcn36xx/smd.c
> > index 6b5dbe6f0d0a..4307429740a9 100644
> > --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> > +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> > @@ -2165,10 +2165,10 @@ static void wcn36xx_smd_rsp_process(struct wcn36xx 
> > *wcn, void *buf, size_t len)
> > msg_ind->msg_len = len;
> > memcpy(msg_ind->msg, buf, len);
> >  
> > -   mutex_lock(>hal_ind_mutex);
> > +   spin_lock(>hal_ind_lock);
> 
> If you are going to handle messages in IRQ context, that better be a
> spin_lock_irq() or spin_lock_bh().

This function is executed in IRQ context after the next patch, as such I
use spin_lock() here and spin_lock_irqsave() in the worker thread
(wcn36xx_ind_smd_work()).

Is this not how the spin_lock API should be used?

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/4] remoteproc: qcom: Introduce WCNSS peripheral image loader

[Bjorn Andersson]

This introduces the peripheral image loader, for loading WCNSS firmware
and boot the core on e.g. MSM8974. The firmware is verified and booted
with the help of the Peripheral Authentication System (PAS) in
TrustZone.

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

Changes since v1:
- Hard coding SMEM id for crash-reason and firmware name

All dependencies has been merges since v1.

 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 +++
 5 files changed, 784 insertions(+)
 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

diff --git a/drivers/remoteproc/Kconfig b/drivers/remoteproc/Kconfig
index 28c711f0ac6b..f4eb07907851 100644
--- a/drivers/remoteproc/Kconfig
+++ b/drivers/remoteproc/Kconfig
@@ -77,4 +77,15 @@ config DA8XX_REMOTEPROC
  It's safe to say n here if you're not interested in multimedia
  offloading.
 
+config QCOM_MDT_LOADER
+   tristate
+
+config QCOM_WCNSS_PIL
+   tristate "Qualcomm WCNSS Peripheral Image Loader"
+   depends on OF && ARCH_QCOM
+   select REMOTEPROC
+   select QCOM_MDT_LOADER
+   help
+ Peripherial Image Loader for the WCNSS block.
+
 endmenu
diff --git a/drivers/remoteproc/Makefile b/drivers/remoteproc/Makefile
index 81b04d1e2e58..beb9a4be7ffd 100644
--- a/drivers/remoteproc/Makefile
+++ b/drivers/remoteproc/Makefile
@@ -11,3 +11,5 @@ 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_QCOM_MDT_LOADER)  += qcom_mdt_loader.o
+obj-$(CONFIG_QCOM_WCNSS_PIL)   += qcom_wcnss.o
diff --git a/drivers/remoteproc/qcom_mdt_loader.c 
b/drivers/remoteproc/qcom_mdt_loader.c
new file mode 100644
index ..30d67f3e63c1
--- /dev/null
+++ b/drivers/remoteproc/qcom_mdt_loader.c
@@ -0,0 +1,213 @@
+/*
+ * Qualcomm Peripheral Image Loader
+ *
+ * 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 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "remoteproc_internal.h"
+
+#define segment_is_hash(flag) (((flag) & (0x7 << 24)) == (0x2 << 24))
+
+static int segment_is_loadable(const struct elf32_phdr *p)
+{
+   return (p->p_type == PT_LOAD) &&
+  !segment_is_hash(p->p_flags) &&
+  p->p_memsz;
+}
+
+/**
+ * rproc_mdt_sanity_check() - sanity check mdt firmware header
+ * @rproc: the remote processor handle
+ * @fw: the mdt header firmware image
+ *
+ * Returns 0 for a valid header, -EINVAL otherwise.
+ */
+int qcom_mdt_sanity_check(struct rproc *rproc,
+ const struct firmware *fw)
+{
+   struct elf32_hdr *ehdr;
+
+   if (!fw) {
+   dev_err(>dev, "failed to load %s\n", rproc->name);
+   return -EINVAL;
+   }
+
+   if (fw->size < sizeof(struct elf32_hdr)) {
+   dev_err(>dev, "image is too small\n");
+   return -EINVAL;
+   }
+
+   ehdr = (struct elf32_hdr *)fw->data;
+   if (memcmp(ehdr->e_ident, ELFMAG, SELFMAG)) {
+   dev_err(>dev, "image is corrupted (bad magic)\n");
+   return -EINVAL;
+   }
+
+   if (ehdr->e_phnum == 0) {
+   dev_err(>dev, "no loadable segments\n");
+   return -EINVAL;
+   }
+
+   if (sizeof(struct elf32_phdr) * ehdr->e_phnum +
+   sizeof(struct elf32_hdr) > fw->size) {
+   dev_err(>dev, "firmware size is too small\n");
+   return -EINVAL;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(qcom_mdt_sanity_check);
+
+/**
+ * qcom_mdt_find_rsc_table() - provide dummy resource table for remoteproc
+ * @rproc: remoteproc handle
+ * @fw:firmware header
+ * @tablesz:   outgoing size of the table
+ *
+ * Re

[PATCH v2 1/4] remoteproc: core: Make the loaded resource table optional

[Bjorn Andersson]

Remote processors like the ones found in the Qualcomm SoCs does not have
a resource table passed to them, so make it optional by only populating
it if it does exist.

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

Changes since v1:
- None

 drivers/remoteproc/remoteproc_core.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index 3d7d58a109d8..c04a786dc051 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -856,12 +856,8 @@ static int rproc_fw_boot(struct rproc *rproc, const struct 
firmware *fw)
 * copy this information to device memory.
 */
loaded_table = rproc_find_loaded_rsc_table(rproc, fw);
-   if (!loaded_table) {
-   ret = -EINVAL;
-   goto clean_up;
-   }
-
-   memcpy(loaded_table, rproc->cached_table, tablesz);
+   if (loaded_table)
+   memcpy(loaded_table, rproc->cached_table, tablesz);
 
/* power up the remote processor */
ret = rproc->ops->start(rproc);
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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] wcn36xx: Transition driver to SMD client

[Bjorn Andersson]

The wcn36xx wifi driver follows the life cycle of the WLAN_CTRL SMD
channel, as such it should be a SMD client. This patch makes this
transition, now that we have the necessary frameworks available.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 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 |  26 ---
 drivers/net/wireless/ath/wcn36xx/smd.h |   4 ++
 drivers/net/wireless/ath/wcn36xx/wcn36xx.h |  21 ++
 6 files changed, 99 insertions(+), 81 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/Kconfig 
b/drivers/net/wireless/ath/wcn36xx/Kconfig
index 591ebaea8265..394fe5b77c90 100644
--- a/drivers/net/wireless/ath/wcn36xx/Kconfig
+++ b/drivers/net/wireless/ath/wcn36xx/Kconfig
@@ -1,6 +1,6 @@
 config WCN36XX
tristate "Qualcomm Atheros WCN3660/3680 support"
-   depends on MAC80211 && HAS_DMA
+   depends on MAC80211 && HAS_DMA && QCOM_SMD
---help---
  This module adds support for wireless adapters based on
  Qualcomm Atheros WCN3660 and WCN3680 mobile chipsets.
diff --git a/drivers/net/wireless/ath/wcn36xx/dxe.c 
b/drivers/net/wireless/ath/wcn36xx/dxe.c
index f8dfa05b290a..47f3937a7ab9 100644
--- a/drivers/net/wireless/ath/wcn36xx/dxe.c
+++ b/drivers/net/wireless/ath/wcn36xx/dxe.c
@@ -23,6 +23,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include 
+#include 
 #include "wcn36xx.h"
 #include "txrx.h"
 
@@ -150,9 +151,12 @@ int wcn36xx_dxe_alloc_ctl_blks(struct wcn36xx *wcn)
goto out_err;
 
/* Initialize SMSM state  Clear TX Enable RING EMPTY STATE */
-   ret = wcn->ctrl_ops->smsm_change_state(
-   WCN36XX_SMSM_WLAN_TX_ENABLE,
-   WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY);
+   ret = qcom_smem_state_update_bits(wcn->tx_enable_state,
+ WCN36XX_SMSM_WLAN_TX_ENABLE |
+ WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY,
+ WCN36XX_SMSM_WLAN_TX_RINGS_EMPTY);
+   if (ret)
+   goto out_err;
 
return 0;
 
@@ -676,9 +680,9 @@ int wcn36xx_dxe_tx_frame(struct wcn36xx *wcn,
 * notify chip about new frame through SMSM bus.
 */
if (is_low &&  vif_priv->pw_state == WCN36XX_BMPS) {
-   wcn->ctrl_ops->smsm_change_state(
- 0,
- WCN36XX_SMSM_WLAN_TX_ENABLE);
+   qcom_smem_state_update_bits(wcn->tx_rings_empty_state,
+   WCN36XX_SMSM_WLAN_TX_ENABLE,
+   WCN36XX_SMSM_WLAN_TX_ENABLE);
} else {
/* indicate End Of Packet and generate interrupt on descriptor
 * done.
diff --git a/drivers/net/wireless/ath/wcn36xx/main.c 
b/drivers/net/wireless/ath/wcn36xx/main.c
index 7c169abdbafe..8659e3f997d2 100644
--- a/drivers/net/wireless/ath/wcn36xx/main.c
+++ b/drivers/net/wireless/ath/wcn36xx/main.c
@@ -19,6 +19,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include "wcn36xx.h"
 
 unsigned int wcn36xx_dbg_mask;
@@ -981,48 +984,63 @@ static int wcn36xx_init_ieee80211(struct wcn36xx *wcn)
 }
 
 static int wcn36xx_platform_get_resources(struct wcn36xx *wcn,
- struct platform_device *pdev)
+ struct device *dev)
 {
-   struct resource *res;
+   u32 mmio[2];
+   int ret;
+
/* Set TX IRQ */
-   res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
-  "wcnss_wlantx_irq");
-   if (!res) {
+   wcn->tx_irq = irq_of_parse_and_map(dev->of_node, 0);
+   if (!wcn->tx_irq) {
wcn36xx_err("failed to get tx_irq\n");
return -ENOENT;
}
-   wcn->tx_irq = res->start;
 
/* Set RX IRQ */
-   res = platform_get_resource_byname(pdev, IORESOURCE_IRQ,
-  "wcnss_wlanrx_irq");
-   if (!res) {
+   wcn->rx_irq = irq_of_parse_and_map(dev->of_node, 1);
+   if (!wcn->rx_irq) {
wcn36xx_err("failed to get rx_irq\n");
return -ENOENT;
}
-   wcn->rx_irq = res->start;
+
+   /* Acquire SMSM tx enable handle */
+   wcn->tx_enable_state = qcom_smem_state_get(dev, "tx-enable",
+   >tx_enable_state_bit);
+   if (IS_ERR(wcn->tx_enable_state)) {
+   wcn36xx_err("failed to get tx-enable state\n");
+   return -ENOENT;
+ 

[PATCH 1/4] wcn36xx: Fold indication payload into message header

[Bjorn Andersson]

Merge the two allocation instead of separately allocating room for the
indication payload.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 drivers/net/wireless/ath/wcn36xx/smd.c | 15 ++-
 drivers/net/wireless/ath/wcn36xx/smd.h |  2 +-
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c 
b/drivers/net/wireless/ath/wcn36xx/smd.c
index 74f56a81ad9a..6b5dbe6f0d0a 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -2151,14 +2151,8 @@ static void wcn36xx_smd_rsp_process(struct wcn36xx *wcn, 
void *buf, size_t len)
case WCN36XX_HAL_OTA_TX_COMPL_IND:
case WCN36XX_HAL_MISSED_BEACON_IND:
case WCN36XX_HAL_DELETE_STA_CONTEXT_IND:
-   msg_ind = kmalloc(sizeof(*msg_ind), GFP_KERNEL);
-   if (!msg_ind)
-   goto nomem;
-   msg_ind->msg_len = len;
-   msg_ind->msg = kmemdup(buf, len, GFP_KERNEL);
-   if (!msg_ind->msg) {
-   kfree(msg_ind);
-nomem:
+   msg_ind = kmalloc(sizeof(*msg_ind) + len, GFP_KERNEL);
+   if (!msg_ind) {
/*
 * FIXME: Do something smarter then just
 * printing an error.
@@ -2167,6 +2161,10 @@ nomem:
msg_header->msg_type);
break;
}
+
+   msg_ind->msg_len = len;
+   memcpy(msg_ind->msg, buf, len);
+
mutex_lock(>hal_ind_mutex);
list_add_tail(_ind->list, >hal_ind_queue);
queue_work(wcn->hal_ind_wq, >hal_ind_work);
@@ -2217,7 +2215,6 @@ static void wcn36xx_ind_smd_work(struct work_struct *work)
  msg_header->msg_type);
}
list_del(wcn->hal_ind_queue.next);
-   kfree(hal_ind_msg->msg);
kfree(hal_ind_msg);
mutex_unlock(>hal_ind_mutex);
 }
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.h 
b/drivers/net/wireless/ath/wcn36xx/smd.h
index 8361f9e3995b..21cc4ac7b5ca 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.h
+++ b/drivers/net/wireless/ath/wcn36xx/smd.h
@@ -55,8 +55,8 @@ struct wcn36xx_fw_msg_status_rsp_v2 {
 
 struct wcn36xx_hal_ind_msg {
struct list_head list;
-   u8 *msg;
size_t msg_len;
+   u8 msg[];
 };
 
 struct wcn36xx;
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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

[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 linux-arm-msm" 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

[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 linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 1/6] clk: qcom: Add support for SMD-RPM Clocks

[Bjorn Andersson]

On Thu 03 Dec 06:02 PST 2015, Georgi Djakov wrote:

> This adds initial support for clocks controlled by the Resource
> Power Manager (RPM) processor on some Qualcomm SoCs, which use
> the qcom_smd_rpm driver to communicate with RPM.
> Such platforms are msm8916, apq8084 and msm8974.
> 
> The RPM is a dedicated hardware engine for managing the shared
> SoC resources in order to keep the lowest power profile. It
> communicates with other hardware subsystems via shared memory
> and accepts clock requests, aggregates the requests and turns
> the clocks on/off or scales them on demand.
> 
> This driver is based on the codeaurora.org driver:
> https://www.codeaurora.org/cgit/quic/la/kernel/msm-3.10/tree/drivers/clk/qcom/clock-rpm.c
> 
> Signed-off-by: Georgi Djakov 

Hi Georgi,

I added the 8974 clocks to this to make the WNCSS core happy (need
CXO_A2 for XO calibration), but I have a few issues:

*) msm_serial acquires a handle to GCC_BLSP1_UART2_APPS_CLK which is
parented by "xo"; the clock framework returns a clock, as the gcc driver
is probed, but as the rpmcc driver isn't probed clk_get_rate() returns
0.

Do you have any patches in your tree to fix the ordering or making the
clk_get() implement probe deferral in this case?

*) If I let the code call clk_smd_rpm_enable_scaling() my eMMC becomes
very unstable, with a rather high occurrence of timeouts during boot
(like 80% of boots fail to mount my rootfs).


Part of these (unrelated to your code) issues I think this looks good,
and hacking around these two issues allows me to get CXO_A2 ticking :)

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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

[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 linux-arm-msm" 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

[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 linux-arm-msm" 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

[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 linux-arm-msm" 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

[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 linux-arm-msm" 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

[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 linux-arm-msm" 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

[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 linux-arm-msm" 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

[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 linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] net: add Qualcomm IPC router

[Bjorn Andersson]

From: Courtney Cavin 

Add an implementation of Qualcomm's IPC router protocol, used to
communicate with service providing remote processors.

Signed-off-by: Courtney Cavin 
---

Downstream this code also includes a large part of a service discovery
mechanism, controlled through a set of custom ioctls. This functionality is
instead moved to user space, a reference implementation for this can be found
at:

  https://github.com/sonyxperiadev/qrtr

 include/linux/socket.h|   4 +-
 include/uapi/linux/qrtr.h |  12 +
 net/Kconfig   |   1 +
 net/Makefile  |   1 +
 net/qrtr/Kconfig  |  24 ++
 net/qrtr/Makefile |   2 +
 net/qrtr/qrtr.c   | 976 ++
 net/qrtr/qrtr.h   |  31 ++
 net/qrtr/smd.c| 119 ++
 9 files changed, 1169 insertions(+), 1 deletion(-)
 create mode 100644 include/uapi/linux/qrtr.h
 create mode 100644 net/qrtr/Kconfig
 create mode 100644 net/qrtr/Makefile
 create mode 100644 net/qrtr/qrtr.c
 create mode 100644 net/qrtr/qrtr.h
 create mode 100644 net/qrtr/smd.c

diff --git a/include/linux/socket.h b/include/linux/socket.h
index 5bf59c8493b7..10e600db06f1 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -200,7 +200,8 @@ struct ucred {
 #define AF_ALG 38  /* Algorithm sockets*/
 #define AF_NFC 39  /* NFC sockets  */
 #define AF_VSOCK   40  /* vSockets */
-#define AF_MAX 41  /* For now.. */
+#define AF_QIPCRTR 41  /* Qualcomm IPC Router  */
+#define AF_MAX 42  /* For now.. */
 
 /* Protocol families, same as address families. */
 #define PF_UNSPEC  AF_UNSPEC
@@ -246,6 +247,7 @@ struct ucred {
 #define PF_ALG AF_ALG
 #define PF_NFC AF_NFC
 #define PF_VSOCK   AF_VSOCK
+#define PF_QIPCRTR AF_QIPCRTR
 #define PF_MAX AF_MAX
 
 /* Maximum queue length specifiable by listen.  */
diff --git a/include/uapi/linux/qrtr.h b/include/uapi/linux/qrtr.h
new file mode 100644
index ..66c0748d26e2
--- /dev/null
+++ b/include/uapi/linux/qrtr.h
@@ -0,0 +1,12 @@
+#ifndef _LINUX_QRTR_H
+#define _LINUX_QRTR_H
+
+#include 
+
+struct sockaddr_qrtr {
+   __kernel_sa_family_t sq_family;
+   __u32 sq_node;
+   __u32 sq_port;
+};
+
+#endif /* _LINUX_QRTR_H */
diff --git a/net/Kconfig b/net/Kconfig
index 11f8c22af34d..5d9a52ef9a55 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -233,6 +233,7 @@ source "net/mpls/Kconfig"
 source "net/hsr/Kconfig"
 source "net/switchdev/Kconfig"
 source "net/l3mdev/Kconfig"
+source "net/qrtr/Kconfig"
 
 config RPS
bool
diff --git a/net/Makefile b/net/Makefile
index a5d04098dfce..007deb2f17c2 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -77,3 +77,4 @@ endif
 ifneq ($(CONFIG_NET_L3_MASTER_DEV),)
 obj-y  += l3mdev/
 endif
+obj-$(CONFIG_QRTR) += qrtr/
diff --git a/net/qrtr/Kconfig b/net/qrtr/Kconfig
new file mode 100644
index ..f053cc25f621
--- /dev/null
+++ b/net/qrtr/Kconfig
@@ -0,0 +1,24 @@
+# Qualcomm IPC Router configuration
+#
+
+config QRTR
+   bool "Qualcomm IPC Router support"
+   depends on ARCH_QCOM || COMPILE_TEST
+   ---help---
+ Say Y if you intend to use Qualcomm IPC router protocol.  The
+ protocol is used to communicate with services provided by other
+ hardware blocks in the system.
+
+ In order to do service lookups, a userspace daemon is required to
+ maintain a service listing.
+
+if QRTR
+
+config QRTR_SMD
+   tristate "SMD IPC Router channels"
+   depends on QRTR && QCOM_SMD && OF
+   ---help---
+ Say Y here to support SMD based ipcrouter channels.  SMD is the
+ most common transport for IPC Router.
+
+endif # QRTR
diff --git a/net/qrtr/Makefile b/net/qrtr/Makefile
new file mode 100644
index ..e282a84ffc5c
--- /dev/null
+++ b/net/qrtr/Makefile
@@ -0,0 +1,2 @@
+obj-y := qrtr.o
+obj-$(CONFIG_QRTR_SMD) += smd.o
diff --git a/net/qrtr/qrtr.c b/net/qrtr/qrtr.c
new file mode 100644
index ..c96dfb6bfbaf
--- /dev/null
+++ b/net/qrtr/qrtr.c
@@ -0,0 +1,976 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ * Copyright (c) 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 
+#include 
+#include  /* For TIOCINQ/OUTQ */
+
+#include 
+
+#include "qrtr.h"
+
+#define QRTR_PROTO_VER 1

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

[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 linux-arm-msm" 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

[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 linux-arm-msm" in
the body of a message to 

[PATCH] ARM: defconfig: multi_v7: Enable Qualcomm options for Honami

[Bjorn Andersson]

The Honami device does not boot due to the lack of pinctrl support
compiled in with the multi_v7_defconfig. This patch correct this and
enables coincell, sdhci, smsm, smp2p and wcnss_ctrl as well, all found
on a variety of Qualcomm boards.

Reported-by: Kevin Hilman <khil...@kernel.org>
Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---

For next/deconfig.

As Kevin reported the Honami stops booting with the addition of pinctrl
reference in the serial node, simply due to the fact that it references a
pinctrl driver that's not enabled in the defconfig.

The patch sent by Andy is hence not enough to fix the problem.


PS. It would be mighty convenient if savedefconfig could be used on the
multi_v7_defconfig.

 arch/arm/configs/multi_v7_defconfig | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index fa7ba92cfe70..dc30a48374b2 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -186,6 +186,7 @@ CONFIG_AD525X_DPOT_I2C=y
 CONFIG_ATMEL_TCLIB=y
 CONFIG_ICS932S401=y
 CONFIG_ATMEL_SSC=m
+CONFIG_QCOM_COINCELL=m
 CONFIG_APDS9802ALS=y
 CONFIG_ISL29003=y
 CONFIG_EEPROM_AT24=y
@@ -347,6 +348,11 @@ CONFIG_PINCTRL_AS3722=y
 CONFIG_PINCTRL_PALMAS=y
 CONFIG_PINCTRL_APQ8064=y
 CONFIG_PINCTRL_APQ8084=y
+CONFIG_PINCTRL_IPQ8064=y
+CONFIG_PINCTRL_MSM8660=y
+CONFIG_PINCTRL_MSM8960=y
+CONFIG_PINCTRL_MSM8X74=y
+CONFIG_PINCTRL_MSM8916=y
 CONFIG_PINCTRL_QCOM_SPMI_PMIC=y
 CONFIG_PINCTRL_QCOM_SSBI_PMIC=y
 CONFIG_GPIO_SYSFS=y
@@ -580,6 +586,7 @@ CONFIG_MMC_SDHCI_ST=y
 CONFIG_MMC_OMAP=y
 CONFIG_MMC_OMAP_HS=y
 CONFIG_MMC_ATMELMCI=y
+CONFIG_MMC_SDHCI_MSM=y
 CONFIG_MMC_MVSDIO=y
 CONFIG_MMC_SDHI=y
 CONFIG_MMC_DW=y
@@ -668,9 +675,12 @@ CONFIG_NVEC_POWER=y
 CONFIG_NVEC_PAZ00=y
 CONFIG_QCOM_GSBI=y
 CONFIG_QCOM_PM=y
+CONFIG_QCOM_SMEM=y
 CONFIG_QCOM_SMD=y
 CONFIG_QCOM_SMD_RPM=y
-CONFIG_QCOM_SMEM=y
+CONFIG_QCOM_SMP2P=y
+CONFIG_QCOM_SMSM=y
+CONFIG_QCOM_WCNSS_CTRL=m
 CONFIG_COMMON_CLK_QCOM=y
 CONFIG_CHROME_PLATFORMS=y
 CONFIG_CROS_EC_CHARDEV=m
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 4/5] clk: qcom: Add RPM clock controller driver

[Bjorn Andersson]

On Mon, Nov 23, 2015 at 4:59 PM, Stephen Boyd <sb...@codeaurora.org> wrote:
> On 11/21, Bjorn Andersson wrote:
>> On Fri 20 Nov 16:39 PST 2015, Stephen Boyd wrote:
[..]
>> Do you foresee that there will be an implementation of the generic rpmcc
>> or is it just a way to "standardize" the dt binding?
>>
>
> I don't see any problem with implementing the RPM clock
> controller as one file or two files (one for platform bus based
> RPM modules and one for SMD bus RPM modules). The compatible can
> be the same for both struct driver instances, while the bus will
> pick the right driver. I suspect we'll need SoC specific
> compatibles though to export the right set of clocks, so having
> the generic compatible is mostly to find these rpm clock
> controllers so that we know to skip registering the XO clock from
> the GCC driver and not some generic implementation of the driver.
>

Ahh, now I get it. So the generic rpmcc to be able to check if we have
a rpmcc instance and then the specific for the actual implementation.

I'm +1 on that.

> There's probably a subset of the clocks that's always the same
> between devices, so if we had to we could match the generic
> compatible and provide limited functionality.
>

After looking at a couple of platforms I don't think it's worth the
effort of having a common list of rpm clocks. My suggestion is that we
just continue with the suggested approach (having platform specific
rpmcc defines and tables)

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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

[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: <devicet...@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 linux-arm-msm" 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: pmic-gpio/mpp: of_irq_count() == npins

[Bjorn Andersson]

On Wed 18 Nov 11:33 PST 2015, Stephen Boyd wrote:

> The number of interrupts is always equal to the number of pins
> provided by the PMIC gpio and MPP hardware blocks. Count the
> number of irqs to figure out the number of pins instead of adding
> more compatible strings or doing math on the reg property. This
> should make the code more generic and ease the number of changes
> we have to make to the driver for each new pmic revision.
> 
> Cc: "Ivan T. Ivanov" <iiva...@mm-sol.com>
> Cc: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> 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 linux-arm-msm" 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

[Bjorn Andersson]

On Tue 17 Nov 16:52 PST 2015, Stephen Boyd wrote:

> Update the driver and binding for pm8994-mpp devices.
> 
> Cc: <devicet...@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 linux-arm-msm" 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

[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 linux-arm-msm" 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

[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: <devicet...@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 linux-arm-msm" 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

[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: <devicet...@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 linux-arm-msm" 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

[Bjorn Andersson]

On Tue 17 Nov 16:52 PST 2015, Stephen Boyd wrote:

> Update the binding and driver for pm8994-gpio devices.
> 
> Cc: <devicet...@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 linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] MAINTAINERS: Add rules for Qualcomm dts files

[Bjorn Andersson]

Make the get_maintainer script pick up the proper maintainers for the
Qualcomm dts files.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 MAINTAINERS | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index bcf40fdc8178..a11764c15b62 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1406,6 +1406,8 @@ M:David Brown <dav...@codeaurora.org>
 L: linux-arm-msm@vger.kernel.org
 L: linux-...@vger.kernel.org
 S: Maintained
+F: arch/arm/boot/dts/qcom-*.dts
+F: arch/arm/boot/dts/qcom-*.dtsi
 F: arch/arm/mach-qcom/
 F: drivers/soc/qcom/
 F: drivers/tty/serial/msm_serial.h
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 i2c8 node

[Bjorn Andersson]

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

diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi 
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index acd4cdb9c934..777adb9204c7 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -331,6 +331,17 @@
interrupts = <0 208 0>;
};
 
+   blsp_i2c8: i2c@f9964000 {
+   status = "disabled";
+   compatible = "qcom,i2c-qup-v2.1.1";
+   reg = <0xf9964000 0x1000>;
+   interrupts = <0 102 IRQ_TYPE_NONE>;
+   clocks = < GCC_BLSP2_QUP2_I2C_APPS_CLK>, < 
GCC_BLSP2_AHB_CLK>;
+   clock-names = "core", "iface";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   };
+
blsp_i2c11: i2c@f9967000 {
status = "disabled";
compatible = "qcom,i2c-qup-v2.1.1";
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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

[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 linux-arm-msm" 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

[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 linux-arm-msm" 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 4/5] clk: qcom: Add RPM clock controller driver

[Bjorn Andersson]

On Fri 20 Nov 16:39 PST 2015, Stephen Boyd wrote:

> On 11/19, Georgi Djakov wrote:
> > diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt 
> > b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> > new file mode 100644
> > index ..bd0fd0cd50dc
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
> > @@ -0,0 +1,35 @@
> > +Qualcomm RPM Clock Controller Binding
> > +
> > +The RPM is a dedicated hardware engine for managing the shared
> > +SoC resources in order to keep the lowest power profile. It
> > +communicates with other hardware subsystems via shared memory
> > +and accepts clock requests, aggregates the requests and turns
> > +the clocks on/off or scales them on demand.
> > +
> > +Required properties :
> > +- compatible : shall contain only one of the following:
> > +
> > +   "qcom,rpmcc-msm8916"
> 
> We need to add qcom,rpmcc as a generic compatible as well.
> 

The binding is generic and the clock defines global, so this should work
fine on the dt side of things. But how do we implement this?

Which set of clocks does the generic rpmcc actually provide?

Do you foresee that there will be an implementation of the generic rpmcc
or is it just a way to "standardize" the dt binding?

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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: fix qcom ssbi drivers for 64-bit compilation

[Bjorn Andersson]

On Mon 16 Nov 08:41 PST 2015, Arnd Bergmann wrote:

> When building pinctrl-ssbi-gpio and pinctrl-ssbi-mpp for ARM64, we get
> a compile warning about invalid types:
> 
> drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c: In function 'pm8xxx_gpio_probe':
> drivers/pinctrl/qcom/pinctrl-ssbi-gpio.c:675:17: warning: cast from pointer 
> to integer of different size [-Wpointer-to-int-cast]
> drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c: In function 'pm8xxx_mpp_probe':
> drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c:766:17: warning: cast from pointer to 
> integer of different size [-Wpointer-to-int-cast]
> 
> This changes the code so we cast the pointer to 'unsigned long', which
> is the right thing to do here.
> 
> Signed-off-by: Arnd Bergmann <a...@arndb.de>
> 

Thanks Arnd,

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

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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: sdhci-msm: Boost controller core clock

[Bjorn Andersson]

On Fri 06 Nov 00:10 PST 2015, Ulf Hansson wrote:

> On 6 November 2015 at 02:42, Bjorn Andersson <bj...@kryo.se> wrote:
> > On Mon, Jul 6, 2015 at 4:53 AM, Ivan T. Ivanov <ivan.iva...@linaro.org> 
> > wrote:
> >> Ensure SDCC is working with maximum clock otherwise card
> >> detection could be extremely slow, up to 7 seconds.
> >>
> >> Signed-off-by: Ivan T. Ivanov <ivan.iva...@linaro.org>
> >> Reviewed-by: Georgi Djakov <georgi.dja...@linaro.org>
> >> Acked-by: Stephen Boyd <sb...@codeaurora.org>
> >> ---
> >>
> >> Changes since v0:
> >> - s/falied/failed in warning message.
> >>
> >>  drivers/mmc/host/sdhci-msm.c | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> >> index 4a09f76..4bcee03 100644
> >> --- a/drivers/mmc/host/sdhci-msm.c
> >> +++ b/drivers/mmc/host/sdhci-msm.c
> >> @@ -489,6 +489,11 @@ static int sdhci_msm_probe(struct platform_device 
> >> *pdev)
> >> goto pclk_disable;
> >> }
> >>
> >> +   /* Vote for maximum clock rate for maximum performance */
> >> +   ret = clk_set_rate(msm_host->clk, INT_MAX);
> >> +   if (ret)
> >> +   dev_warn(>dev, "core clock boost failed\n");
> >> +
> >
> > On my 8974AC devices this results in GCC_SDCC1_APPS_CLK changing from
> > 100MHz to 200MHz for my eMMC. Unfortunately this results in the
> > following error:
> >
> > [5.103241] mmcblk0: retrying because a re-tune was needed
> > [5.109270] mmcblk0: error -84 transferring data, sector 5816322,
> > nr 2, cmd response 0x900, card status 0xc00
> >
> > Looking at the board specification it's stated that these card should
> > run in DDR50, so I've tried specifying "max-frequency" in the dt. I
> > verified in sdhci_set_clock() that we get a divisor of 4, but the
> > result is a repetition of:
> 
> I don't follow. Are you saying that changing the clock frequency to
> 200MHz caused the card to be initialized in HS200 mode instead of
> DDR50?
> 

No, we clock the sdhci block at 100MHz, the host->max_clk is 200MHz and
the divisor in sdhci_set_clock() becomes 1. So if I read this correctly
we're running HS200 at 100MHz.

Bumping the clock rate to 200MHz at the block doesn't affect the max_clk
and hence we're trying to run the bus at 200MHz.

I therefor tried to just set "max-frequency" to 50MHz, getting the
divider to be 4 and the below error.

So I assume it just happened to work at 100MHz, but 200MHz is way off
from the 50MHz the board is designed and tested for.


Unfortunately I don't have the equipment to measure these assumptions :/

> >
> > [1.702312] mmc1: Switching to 3.3V signalling voltage failed
> > [1.837987] mmc1: power class selection to bus width 8 ddr 0 failed
> > [1.846227] mmc1: error -110 whilst initialising MMC card
> > [1.946303] mmc1: Reset 0x1 never completed.
> >
> > I tried to disable HS200 by specifying SDHCI_QUIRK2_BROKEN_HS200. This
> > makes the card come up nicely again.
> >
> >
> > Is there any other way to force the link to DDR50? Is it acceptable to
> > expose the broken-hs200 quirk in dt so I can use that for now?
> 
> We already have these DT bindings.
> - mmc-ddr-1_8v: eMMC high-speed DDR mode(1.8V I/O) is supported
> - mmc-ddr-1_2v: eMMC high-speed DDR mode(1.2V I/O) is supported
> - mmc-hs200-1_8v: eMMC HS200 mode(1.8V I/O) is supported
> - mmc-hs200-1_2v: eMMC HS200 mode(1.2V I/O) is supported
> 
> Can't we use these instead?
> 

These are all additive and the hardware is correctly advertising that
it's capable of supporting SDR104, which implies HS200. Dropping this
assumption (or unsetting these bits) drops us down to the high-speed
rates and things work again.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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

[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 

Re: [PATCH v2] mmc: sdhci-msm: Boost controller core clock

[Bjorn Andersson]

On Mon, Jul 6, 2015 at 4:53 AM, Ivan T. Ivanov  wrote:
> Ensure SDCC is working with maximum clock otherwise card
> detection could be extremely slow, up to 7 seconds.
>
> Signed-off-by: Ivan T. Ivanov 
> Reviewed-by: Georgi Djakov 
> Acked-by: Stephen Boyd 
> ---
>
> Changes since v0:
> - s/falied/failed in warning message.
>
>  drivers/mmc/host/sdhci-msm.c | 5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index 4a09f76..4bcee03 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -489,6 +489,11 @@ static int sdhci_msm_probe(struct platform_device *pdev)
> goto pclk_disable;
> }
>
> +   /* Vote for maximum clock rate for maximum performance */
> +   ret = clk_set_rate(msm_host->clk, INT_MAX);
> +   if (ret)
> +   dev_warn(>dev, "core clock boost failed\n");
> +

On my 8974AC devices this results in GCC_SDCC1_APPS_CLK changing from
100MHz to 200MHz for my eMMC. Unfortunately this results in the
following error:

[5.103241] mmcblk0: retrying because a re-tune was needed
[5.109270] mmcblk0: error -84 transferring data, sector 5816322,
nr 2, cmd response 0x900, card status 0xc00

Looking at the board specification it's stated that these card should
run in DDR50, so I've tried specifying "max-frequency" in the dt. I
verified in sdhci_set_clock() that we get a divisor of 4, but the
result is a repetition of:

[1.702312] mmc1: Switching to 3.3V signalling voltage failed
[1.837987] mmc1: power class selection to bus width 8 ddr 0 failed
[1.846227] mmc1: error -110 whilst initialising MMC card
[1.946303] mmc1: Reset 0x1 never completed.

I tried to disable HS200 by specifying SDHCI_QUIRK2_BROKEN_HS200. This
makes the card come up nicely again.


Is there any other way to force the link to DDR50? Is it acceptable to
expose the broken-hs200 quirk in dt so I can use that for now?

(The downstream fix used for this was apparently to just remove all
other caps...)

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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/2] drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel

[Bjorn Andersson]

From: Werner Johansson <werner.johans...@sonymobile.com>

This adds support for the Sharp panel found on the Qualcomm
Snapdragon 800 Dragonboard (APQ8074)

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

 drivers/gpu/drm/panel/Kconfig   |   9 +
 drivers/gpu/drm/panel/Makefile  |   1 +
 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 387 
 3 files changed, 397 insertions(+)
 create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c

diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
index 7d4704b1292b..da3b9c7889c4 100644
--- a/drivers/gpu/drm/panel/Kconfig
+++ b/drivers/gpu/drm/panel/Kconfig
@@ -51,4 +51,13 @@ config DRM_PANEL_SHARP_LQ101R1SX01
  To compile this driver as a module, choose M here: the module
  will be called panel-sharp-lq101r1sx01.
 
+config DRM_PANEL_SHARP_LS043T1LE01
+   tristate "Sharp LS043T1LE01 qHD video mode panel"
+   depends on OF
+   depends on DRM_MIPI_DSI
+   depends on BACKLIGHT_CLASS_DEVICE
+   help
+ Say Y here if you want to enable support for Sharp LS043T1LE01 qHD
+ (540x960) DSI panel as found on the Qualcomm APQ8074 Dragonboard
+
 endmenu
diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
index d0f016dd7ddb..53de90aa49cd 100644
--- a/drivers/gpu/drm/panel/Makefile
+++ b/drivers/gpu/drm/panel/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_DRM_PANEL_LG_LG4573) += panel-lg-lg4573.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_LD9040) += panel-samsung-ld9040.o
 obj-$(CONFIG_DRM_PANEL_SAMSUNG_S6E8AA0) += panel-samsung-s6e8aa0.o
 obj-$(CONFIG_DRM_PANEL_SHARP_LQ101R1SX01) += panel-sharp-lq101r1sx01.o
+obj-$(CONFIG_DRM_PANEL_SHARP_LS043T1LE01) += panel-sharp-ls043t1le01.o
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c 
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
new file mode 100644
index ..3aeb0bda4947
--- /dev/null
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -0,0 +1,387 @@
+/*
+ * Copyright (C) 2015 Red Hat
+ * Copyright (C) 2015 Sony Mobile Communications Inc.
+ * Author: Werner Johansson <werner.johans...@sonymobile.com>
+ *
+ * Based on AUO panel driver by Rob Clark <robdcl...@gmail.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.
+ *
+ * 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.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see <http://www.gnu.org/licenses/>.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+struct sharp_nt_panel {
+   struct drm_panel base;
+   struct mipi_dsi_device *dsi;
+
+   struct backlight_device *backlight;
+   struct regulator *supply;
+   struct gpio_desc *reset_gpio;
+
+   bool prepared;
+   bool enabled;
+
+   const struct drm_display_mode *mode;
+};
+
+static inline struct sharp_nt_panel *to_sharp_nt_panel(struct drm_panel *panel)
+{
+   return container_of(panel, struct sharp_nt_panel, base);
+}
+
+static int sharp_nt_panel_init(struct sharp_nt_panel *sharp_nt)
+{
+   struct mipi_dsi_device *dsi = sharp_nt->dsi;
+   int ret;
+
+   dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+   ret = mipi_dsi_dcs_exit_sleep_mode(dsi);
+   if (ret < 0)
+   return ret;
+
+   msleep(120);
+
+   /* Novatek two-lane operation */
+   ret = mipi_dsi_dcs_write(dsi, 0xae, (u8[]){ 0x03 }, 1);
+   if (ret < 0)
+   return ret;
+
+   /* Set both MCU and RGB I/F to 24bpp */
+   ret = mipi_dsi_dcs_set_pixel_format(dsi, MIPI_DCS_PIXEL_FMT_24BIT |
+   (MIPI_DCS_PIXEL_FMT_24BIT << 4));
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static int sharp_nt_panel_on(struct sharp_nt_panel *sharp_nt)
+{
+   struct mipi_dsi_device *dsi = sharp_nt->dsi;
+   int ret;
+
+   dsi->mode_flags |= MIPI_DSI_MODE_LPM;
+
+   ret = mipi_dsi_dcs_set_display_on(dsi);
+   if (ret < 0)
+   return ret;
+
+   return 0;
+}
+
+static int sharp_nt_panel_off(struct sharp_nt_panel *sharp_nt)
+{
+   struct mipi_dsi_device *dsi = sharp_nt->dsi;
+   int ret;
+
+   dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
+
+   ret = mipi_dsi_dcs_set_display_off(dsi);
+   if (ret < 0)
+ 

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

[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 linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] soc: qcom: smd-rpm: Correct size of outgoing message

[Bjorn Andersson]

With the removal of VLAIS the size was incorrectly changed to only cover
the headers of the packet, resulting in "empty" requests being sent to
the RPM. Correct this so the entire message is transfered.

Fixes: 50e1b29b4438 ("soc: qcom: smd: Remove use of VLAIS")
Cc: Stephen Boyd <sb...@codeaurora.org>
Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 drivers/soc/qcom/smd-rpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
index 1ee02d2587b2..2969321e1b09 100644
--- a/drivers/soc/qcom/smd-rpm.c
+++ b/drivers/soc/qcom/smd-rpm.c
@@ -132,7 +132,7 @@ int qcom_rpm_smd_write(struct qcom_smd_rpm *rpm,
pkt->req.data_len = cpu_to_le32(count);
memcpy(pkt->payload, buf, count);
 
-   ret = qcom_smd_send(rpm->rpm_channel, pkt, sizeof(*pkt));
+   ret = qcom_smd_send(rpm->rpm_channel, pkt, size);
if (ret)
goto out;
 
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[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: devicet...@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 linux-arm-msm" 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

[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 linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] soc: qcom: Introduce WCNSS_CTRL SMD client

[Bjorn Andersson]

On Fri, Oct 23, 2015 at 4:37 AM, yfw  wrote:
[..]
> Yes. I meant this remoteproc-wcnss driver. Will you try to upstream it?
>

https://lkml.org/lkml/2015/9/26/10

I thought I got you on the Cc on that series, sorry about that. I will
resend it once we have smsm/smp2p so that the kbuild robot doesn't
have a chance to shoot it down. (But no planned functional change so
far)

>>
>> Left is a mechanism to trigger the thing to boot and shutdown. One
>> potential solution would be to have the module_init/exit call
>> rproc_boot/shutdown from the WiFi & BT drivers. That way if one loads
>> the wcn36xx driver, the core is booted. This would also fit quite nicely
>> for other things - e.g. load the ALSA driver to trigger the ADSP
>> loading.
>>
>> The problem here is that we're then forced to either have a method of
>> deferring the rproc_boot() until the firmware is available or we always
>> must compile these drivers as kernel modules. This because the
>> file system isn't there during boot to provide the firmware.
>
> The firmware file could be put to initrd. That should allow wcn wifi driver
> builtin.
>

We have the same puzzle to solve for adsp, venus and the modem. And
the combined size of all these makes it practically infeasible to do
so.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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] Sony Xperia Z dts

[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 linux-arm-msm" 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] ARM: dts: qcom: apq8064: Introduce gsbi5 and gsbi5 serial node

[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 linux-arm-msm" 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] ARM: dts: qcom: apq8064: Add hwmutex and SMEM nodes

[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 linux-arm-msm" 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

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

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

Re: [PATCH 2/2] drm/panel: Add Sharp LS043T1LE01 MIPI DSI panel

[Bjorn Andersson]

On Tue, Jul 28, 2015 at 6:37 PM, Bjorn Andersson
<bjorn.anders...@sonymobile.com> wrote:
> From: Werner Johansson <werner.johans...@sonymobile.com>
>
> This adds support for the Sharp panel found on the Qualcomm
> Snapdragon 800 Dragonboard (APQ8074)
>
> Signed-off-by: Werner Johansson <werner.johans...@sonymobile.com>
> Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>

Anything holding this back from being merged? I have a bunch more
panel drivers and would like to know if this is acceptable before
pushing more.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] soc: qcom: Introduce WCNSS_CTRL SMD client

[Bjorn Andersson]

On Thu 22 Oct 03:25 PDT 2015, yfw wrote:

> Hi Bjorn,
> 
> On 2015/9/22 1:52, Bjorn Andersson wrote:
[..]
> 
> I have a question: Do you have plan to add the nob to trigger wcnss firmware
> downloading which is also common for wifi and BT?
> 

In caf the wcnss driver is actually two drivers intermingled;
* a SMD client driver, responsible for pushing NV, something related to
  calibration, some power properties and so on

* a platform_driver implementing the wcnss specifics of the PIL through
  some hooks and providing the knob to trigger the PIL.

The first driver is related to the "OS" running on the wcnss, so that
should follow the life cycle of the SMD channel "WCNSS_CTRL". This is
what this patch provides - it loads the NV every time the wcnss core is
booted.


For the second part, I strongly believe that the PIL implementation
should deal with the specifics (e.g. regulator handling and
xo_calibration), rather than having a piece bolted on elsewhere - so
that's in the remoteproc-wcnss driver.


Left is a mechanism to trigger the thing to boot and shutdown. One
potential solution would be to have the module_init/exit call
rproc_boot/shutdown from the WiFi & BT drivers. That way if one loads
the wcn36xx driver, the core is booted. This would also fit quite nicely
for other things - e.g. load the ALSA driver to trigger the ADSP
loading.

The problem here is that we're then forced to either have a method of
deferring the rproc_boot() until the firmware is available or we always
must compile these drivers as kernel modules. This because the
file system isn't there during boot to provide the firmware.

We do have the same thing in e.g. the Broadcom WiFi/BT solution and
there seems to be discussions related to this.


So for now, I punted and put a knob in the wcnss remoteproc driver.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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

[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 linux-arm-msm" 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: ssbi: fix function name typo

[Bjorn Andersson]

On Fri 16 Oct 13:41 PDT 2015, Arnd Bergmann wrote:

> The two newly added qcom ssbi pinctrl drivers have the same bug
> from a function name that apparently got changed in one place
> but not another, resulting in a build error when CONFIG_DEBUG_FS
> is disabled:
> 
> drivers/pinctrl/qcom/pinctrl-ssbi-mpp.c:652:14: error: 'pm8xxx_mpp_dbg_show' 
> undeclared here (not in a function)
> 
> This fixes the two identifiers.

Sorry about this Arnd.

Jonas Gorski found this a few days ago and Linus picked it up today, so
it's in the pipe already.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 7/7] Bluetooth: btqcomsmd: Qualcomm WCNSS HCI driver

[Bjorn Andersson]

On Wed 14 Oct 08:10 PDT 2015, yfw wrote:

[..]
> > diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
[..]
> > +static int btqcomsmd_probe(struct qcom_smd_device *sdev)
> > +{
> > +   struct qcom_smd_channel *acl;
> > +   struct btqcomsmd *btq;
> > +   struct hci_dev *hdev;
> > +   int ret;
> > +
> > +   acl = qcom_smd_open_channel(sdev,
> > +   "APPS_RIVA_BT_ACL",
> > +   btqcomsmd_acl_callback);
> > +   if (IS_ERR(acl))
> > +   return PTR_ERR(acl);
> Do we need to close acl channel in following failure path and
> btqcomsmd_remove?
> 

As the life cycle of the channels implicitly follow the life cycle of
the qcom_smd_device the channel is supposed to be released by the
caller of probe upon failure.

I'll make sure this is documented in qcom_smd_open_channel()


Thanks for the review.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 5/7] soc: qcom: smd: Support opening additional channels

[Bjorn Andersson]

On Wed 14 Oct 08:09 PDT 2015, yfw wrote:

> Hi Bjorn,
> 
> On 2015/10/10 4:48, Bjorn Andersson wrote:
> > With the qcom_smd_open_channel() API we allow SMD devices to open
> > additional SMD channels, to allow implementation of multi-channel SMD
> > devices - like Bluetooth.
> >
> > Channels are opened from the same edge as the calling SMD device is tied
> > to.
> >
[..]
> > +/**
> > + * qcom_smd_open_channel() - claim additional channels on the same edge
> > + * @sdev:  smd_device handle
> > + * @name:  channel name
> > + * @cb:callback method to use for incoming data
> > + *
> > + * Returns a channel handle on success, or -EPROBE_DEFER if the channel 
> > isn't
> > + * ready.
> > + */
> > +struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_device 
> > *sdev,
> > +  const char *name,
> > +  qcom_smd_cb_t cb)
> > +{
> > +   struct qcom_smd_channel *channel;
> > +   struct qcom_smd_edge *edge = sdev->channel->edge;
> > +   int ret;
> > +
> > +   /* Wait up to HZ for the channel to appear */
> > +   ret = wait_event_interruptible_timeout(edge->new_channel_event,
> > +   (channel = qcom_smd_find_channel(edge, name)) != NULL,
> > +   HZ);
> > +   if (!ret)
> > +   return ERR_PTR(-ETIMEDOUT);
> > +
> > +   if (channel->state != SMD_CHANNEL_CLOSED) {
> > +   dev_err(>dev, "channel %s is busy\n", channel->name);
> > +   return ERR_PTR(-EBUSY);
> > +   }
> > +
> > +   channel->qsdev = sdev;
> > +   ret = qcom_smd_channel_open(channel, cb);
> > +   if (ret) {
> > +   channel->qsdev = NULL;
> > +   return ERR_PTR(ret);
> > +   }
> > +
> > +   /*
> > +* Append the list of channel to the channels associated with the sdev
> > +*/
> > +   list_add_tail(>dev_list, >channel->dev_list);
> > +
> > +   return channel;
> > +}
> > +EXPORT_SYMBOL(qcom_smd_open_channel);
> > +
> Do we need qcom_smd_close_channel API here?
> 

On success the channel is associated with the qcom_smd_device, which
tears down all associated channels on destruction.

I have not yet seen any reason for decoupling the life cycle of a
channel further from the device (in most cases it's very must 1:1).

But I will update the comment above to clarify this fact, thanks!

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] soc: qcom: smd-rpm: Correct the active vs sleep state flagging

[Bjorn Andersson]

The BIT() was incorrectly inherited from family A and should not be used
on family B where the state is denoted by an enum.

Reported-by: Georgi Djakov <georgi.dja...@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 drivers/soc/qcom/smd-rpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
index b5feb58dbd9f..2969321e1b09 100644
--- a/drivers/soc/qcom/smd-rpm.c
+++ b/drivers/soc/qcom/smd-rpm.c
@@ -126,7 +126,7 @@ int qcom_rpm_smd_write(struct qcom_smd_rpm *rpm,
pkt->hdr.length = cpu_to_le32(sizeof(struct qcom_rpm_request) + count);
 
pkt->req.msg_id = cpu_to_le32(msg_id++);
-   pkt->req.flags = cpu_to_le32(BIT(state));
+   pkt->req.flags = cpu_to_le32(state);
pkt->req.type = cpu_to_le32(type);
pkt->req.id = cpu_to_le32(id);
pkt->req.data_len = cpu_to_le32(count);
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] soc: qcom: smd: Correct SMEM items for upper channels

[Bjorn Andersson]

On Mon, Oct 12, 2015 at 9:36 AM, Andy Gross <agr...@codeaurora.org> wrote:
> On Fri, Oct 09, 2015 at 09:35:37PM -0700, Bjorn Andersson wrote:
>> Update the SMEM items for the second set of SMD channels, as these where
>> incorrect.
>>
>> Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
>
> Nice.  Good catch.  I verified by counting through the #defines in the
> codeaurora code.
>

I grew tired of resolving that huge enum list, so I created this:
http://elinux.org/Qualcomm_SMEM_Items

Was planning to document the items as I go, but the list of numbers is
the most important part.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] regulator: qcom-smd: Correct set_load() unit

[Bjorn Andersson]

The set_load() op deals with uA while the SMD packets used mA, so
convert as we're building the packet.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 drivers/regulator/qcom_smd-regulator.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/qcom_smd-regulator.c 
b/drivers/regulator/qcom_smd-regulator.c
index b72c693e29ff..6fa0c7d13290 100644
--- a/drivers/regulator/qcom_smd-regulator.c
+++ b/drivers/regulator/qcom_smd-regulator.c
@@ -131,7 +131,7 @@ static int rpm_reg_set_load(struct regulator_dev *rdev, int 
load_uA)
 
req.key = cpu_to_le32(RPM_KEY_MA);
req.nbytes = cpu_to_le32(sizeof(u32));
-   req.value = cpu_to_le32(load_uA);
+   req.value = cpu_to_le32(load_uA / 1000);
 
return rpm_reg_write_active(vreg, , sizeof(req));
 }
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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/7] Qualcomm WCNSS HCI support

[Bjorn Andersson]

After trying to avoid implementing multi-channel support in SMD in v1 of
the HCI driver for Qualcomm WCNSS BT, this new version includes the
necessary SMD refactoring and additon of an API that allows SMD devices
to call back into the SMD core to acquire additonal channels.

The additional channels are tied to the existing SMD device and the life
cycle of the new channel will be tied to, and affect, the original
channel.

With this in place the btqcomsmd driver is refactored into being a
single driver, without global state.

Bjorn Andersson (7):
  soc: qcom: smd: Introduce callback setter
  soc: qcom: smd: Split discovery and state change work
  soc: qcom: smd: Refactor channel open and close handling
  soc: qcom: smd: Support multiple channels per sdev
  soc: qcom: smd: Support opening additional channels
  Bluetooth: Add HCI device identifier for Qualcomm SMD
  Bluetooth: hci_smd: Qualcomm WCNSS HCI driver

 drivers/bluetooth/Kconfig |  11 ++
 drivers/bluetooth/Makefile|   1 +
 drivers/bluetooth/btqcomsmd.c | 198 
 drivers/soc/qcom/smd.c| 228 +++---
 include/linux/soc/qcom/smd.h  |   8 +-
 include/net/bluetooth/hci.h   |   1 +
 6 files changed, 387 insertions(+), 60 deletions(-)
 create mode 100644 drivers/bluetooth/btqcomsmd.c

-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/7] soc: qcom: smd: Support opening additional channels

[Bjorn Andersson]

With the qcom_smd_open_channel() API we allow SMD devices to open
additional SMD channels, to allow implementation of multi-channel SMD
devices - like Bluetooth.

Channels are opened from the same edge as the calling SMD device is tied
to.

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

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c   | 75 
 include/linux/soc/qcom/smd.h |  4 +++
 2 files changed, 79 insertions(+)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 4c55708aac50..3257ba488d3d 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -129,6 +129,8 @@ struct qcom_smd_edge {
 
unsigned smem_available;
 
+   wait_queue_head_t new_channel_event;
+
struct work_struct scan_work;
struct work_struct state_work;
 };
@@ -1042,6 +1044,76 @@ void qcom_smd_driver_unregister(struct qcom_smd_driver 
*qsdrv)
 }
 EXPORT_SYMBOL(qcom_smd_driver_unregister);
 
+static struct qcom_smd_channel *
+qcom_smd_find_channel(struct qcom_smd_edge *edge, const char *name)
+{
+   struct qcom_smd_channel *channel;
+   struct qcom_smd_channel *ret = NULL;
+   unsigned state;
+
+   read_lock(>channels_lock);
+   list_for_each_entry(channel, >channels, list) {
+   if (strcmp(channel->name, name))
+   continue;
+
+   state = GET_RX_CHANNEL_INFO(channel, state);
+   if (state != SMD_CHANNEL_OPENING &&
+   state != SMD_CHANNEL_OPENED)
+   continue;
+
+   ret = channel;
+   break;
+   }
+   read_unlock(>channels_lock);
+
+   return ret;
+}
+
+/**
+ * qcom_smd_open_channel() - claim additional channels on the same edge
+ * @sdev:  smd_device handle
+ * @name:  channel name
+ * @cb:callback method to use for incoming data
+ *
+ * Returns a channel handle on success, or -EPROBE_DEFER if the channel isn't
+ * ready.
+ */
+struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_device *sdev,
+  const char *name,
+  qcom_smd_cb_t cb)
+{
+   struct qcom_smd_channel *channel;
+   struct qcom_smd_edge *edge = sdev->channel->edge;
+   int ret;
+
+   /* Wait up to HZ for the channel to appear */
+   ret = wait_event_interruptible_timeout(edge->new_channel_event,
+   (channel = qcom_smd_find_channel(edge, name)) != NULL,
+   HZ);
+   if (!ret)
+   return ERR_PTR(-ETIMEDOUT);
+
+   if (channel->state != SMD_CHANNEL_CLOSED) {
+   dev_err(>dev, "channel %s is busy\n", channel->name);
+   return ERR_PTR(-EBUSY);
+   }
+
+   channel->qsdev = sdev;
+   ret = qcom_smd_channel_open(channel, cb);
+   if (ret) {
+   channel->qsdev = NULL;
+   return ERR_PTR(ret);
+   }
+
+   /*
+* Append the list of channel to the channels associated with the sdev
+*/
+   list_add_tail(>dev_list, >channel->dev_list);
+
+   return channel;
+}
+EXPORT_SYMBOL(qcom_smd_open_channel);
+
 /*
  * Allocate the qcom_smd_channel object for a newly found smd channel,
  * retrieving and validating the smem items involved.
@@ -1178,6 +1250,8 @@ static void qcom_channel_scan_worker(struct work_struct 
*work)
 
dev_dbg(smd->dev, "new channel found: '%s'\n", 
channel->name);
set_bit(i, edge->allocated[tbl]);
+
+   wake_up_interruptible(>new_channel_event);
}
}
 
@@ -1340,6 +1414,7 @@ static int qcom_smd_probe(struct platform_device *pdev)
for_each_available_child_of_node(pdev->dev.of_node, node) {
edge = >edges[i++];
edge->smd = smd;
+   init_waitqueue_head(>new_channel_event);
 
ret = qcom_smd_parse_edge(>dev, node, edge);
if (ret)
diff --git a/include/linux/soc/qcom/smd.h b/include/linux/soc/qcom/smd.h
index 65a64fcdb1aa..bd51c8a9d807 100644
--- a/include/linux/soc/qcom/smd.h
+++ b/include/linux/soc/qcom/smd.h
@@ -56,4 +56,8 @@ void qcom_smd_driver_unregister(struct qcom_smd_driver *drv);
 
 int qcom_smd_send(struct qcom_smd_channel *channel, const void *data, int len);
 
+struct qcom_smd_channel *qcom_smd_open_channel(struct qcom_smd_device *sdev,
+  const char *name,
+  qcom_smd_cb_t cb);
+
 #endif
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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/7] soc: qcom: smd: Introduce callback setter

[Bjorn Andersson]

Introduce a setter for the callback function pointer to clarify the
locking around the operation and to reduce some duplication.

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

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c   | 25 +
 include/linux/soc/qcom/smd.h |  4 +++-
 2 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 18964f154383..8b401d89b0d0 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -186,7 +186,7 @@ struct qcom_smd_channel {
int fifo_size;
 
void *bounce_buffer;
-   int (*cb)(struct qcom_smd_device *, const void *, size_t);
+   qcom_smd_cb_t cb;
 
spinlock_t recv_lock;
 
@@ -378,6 +378,19 @@ static void qcom_smd_channel_reset(struct qcom_smd_channel 
*channel)
 }
 
 /*
+ * Set the callback for a channel, with appropriate locking
+ */
+static void qcom_smd_channel_set_callback(struct qcom_smd_channel *channel,
+ qcom_smd_cb_t cb)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(>recv_lock, flags);
+   channel->cb = cb;
+   spin_unlock_irqrestore(>recv_lock, flags);
+};
+
+/*
  * Calculate the amount of data available in the rx fifo
  */
 static size_t qcom_smd_channel_get_rx_avail(struct qcom_smd_channel *channel)
@@ -815,8 +828,7 @@ static int qcom_smd_dev_probe(struct device *dev)
if (!channel->bounce_buffer)
return -ENOMEM;
 
-   channel->cb = qsdrv->callback;
-
+   qcom_smd_channel_set_callback(channel, qsdrv->callback);
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENING);
 
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENED);
@@ -832,7 +844,7 @@ static int qcom_smd_dev_probe(struct device *dev)
 err:
dev_err(>dev, "probe failed\n");
 
-   channel->cb = NULL;
+   qcom_smd_channel_set_callback(channel, NULL);
kfree(channel->bounce_buffer);
channel->bounce_buffer = NULL;
 
@@ -851,16 +863,13 @@ static int qcom_smd_dev_remove(struct device *dev)
struct qcom_smd_device *qsdev = to_smd_device(dev);
struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
struct qcom_smd_channel *channel = qsdev->channel;
-   unsigned long flags;
 
qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSING);
 
/*
 * Make sure we don't race with the code receiving data.
 */
-   spin_lock_irqsave(>recv_lock, flags);
-   channel->cb = NULL;
-   spin_unlock_irqrestore(>recv_lock, flags);
+   qcom_smd_channel_set_callback(channel, NULL);
 
/* Wake up any sleepers in qcom_smd_send() */
wake_up_interruptible(>fblockread_event);
diff --git a/include/linux/soc/qcom/smd.h b/include/linux/soc/qcom/smd.h
index d0cb6d189a0a..65a64fcdb1aa 100644
--- a/include/linux/soc/qcom/smd.h
+++ b/include/linux/soc/qcom/smd.h
@@ -26,6 +26,8 @@ struct qcom_smd_device {
struct qcom_smd_channel *channel;
 };
 
+typedef int (*qcom_smd_cb_t)(struct qcom_smd_device *, const void *, size_t);
+
 /**
  * struct qcom_smd_driver - smd driver struct
  * @driver:underlying device driver
@@ -42,7 +44,7 @@ struct qcom_smd_driver {
 
int (*probe)(struct qcom_smd_device *dev);
void (*remove)(struct qcom_smd_device *dev);
-   int (*callback)(struct qcom_smd_device *, const void *, size_t);
+   qcom_smd_cb_t callback;
 };
 
 int qcom_smd_driver_register(struct qcom_smd_driver *drv);
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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/7] soc: qcom: smd: Split discovery and state change work

[Bjorn Andersson]

Split the two steps of channel discovery and state change handling into
two different workers. This allows for new channels to be found while
we're are probing, which is required as we introduce multi-channel
support.

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

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c | 58 +-
 1 file changed, 29 insertions(+), 29 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 8b401d89b0d0..fb5f91efd0da 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -106,9 +106,9 @@ static const struct {
  * @channels:  list of all channels detected on this edge
  * @channels_lock: guard for modifications of @channels
  * @allocated: array of bitmaps representing already allocated channels
- * @need_rescan:   flag that the @work needs to scan smem for new channels
  * @smem_available:last available amount of smem triggering a channel scan
- * @work:  work item for edge house keeping
+ * @scan_work: work item for discovering new channels
+ * @state_work:work item for edge state changes
  */
 struct qcom_smd_edge {
struct qcom_smd *smd;
@@ -123,14 +123,14 @@ struct qcom_smd_edge {
int ipc_bit;
 
struct list_head channels;
-   spinlock_t channels_lock;
+   rwlock_t channels_lock;
 
DECLARE_BITMAP(allocated[SMD_ALLOC_TBL_COUNT], SMD_ALLOC_TBL_SIZE);
 
-   bool need_rescan;
unsigned smem_available;
 
-   struct work_struct work;
+   struct work_struct scan_work;
+   struct work_struct state_work;
 };
 
 /*
@@ -624,13 +624,13 @@ static irqreturn_t qcom_smd_edge_intr(int irq, void *data)
/*
 * Handle state changes or data on each of the channels on this edge
 */
-   spin_lock(>channels_lock);
+   read_lock(>channels_lock);
list_for_each_entry(channel, >channels, list) {
spin_lock(>recv_lock);
kick_worker |= qcom_smd_channel_intr(channel);
spin_unlock(>recv_lock);
}
-   spin_unlock(>channels_lock);
+   read_unlock(>channels_lock);
 
/*
 * Creating a new channel requires allocating an smem entry, so we only
@@ -640,12 +640,11 @@ static irqreturn_t qcom_smd_edge_intr(int irq, void *data)
available = qcom_smem_get_free_space(edge->remote_pid);
if (available != edge->smem_available) {
edge->smem_available = available;
-   edge->need_rescan = true;
kick_worker = true;
}
 
if (kick_worker)
-   schedule_work(>work);
+   schedule_work(>scan_work);
 
return IRQ_HANDLED;
 }
@@ -1101,8 +1100,9 @@ free_name_and_channel:
  * qcom_smd_create_channel() to create representations of these and add
  * them to the edge's list of channels.
  */
-static void qcom_discover_channels(struct qcom_smd_edge *edge)
+static void qcom_channel_scan_worker(struct work_struct *work)
 {
+   struct qcom_smd_edge *edge = container_of(work, struct qcom_smd_edge, 
scan_work);
struct qcom_smd_alloc_entry *alloc_tbl;
struct qcom_smd_alloc_entry *entry;
struct qcom_smd_channel *channel;
@@ -1146,16 +1146,16 @@ static void qcom_discover_channels(struct qcom_smd_edge 
*edge)
if (IS_ERR(channel))
continue;
 
-   spin_lock_irqsave(>channels_lock, flags);
+   write_lock_irqsave(>channels_lock, flags);
list_add(>list, >channels);
-   spin_unlock_irqrestore(>channels_lock, flags);
+   write_unlock_irqrestore(>channels_lock, flags);
 
dev_dbg(smd->dev, "new channel found: '%s'\n", 
channel->name);
set_bit(i, edge->allocated[tbl]);
}
}
 
-   schedule_work(>work);
+   schedule_work(>state_work);
 }
 
 /*
@@ -1163,29 +1163,22 @@ static void qcom_discover_channels(struct qcom_smd_edge 
*edge)
  * then scans all registered channels for state changes that should be handled
  * by creating or destroying smd client devices for the registered channels.
  *
- * LOCKING: edge->channels_lock is not needed to be held during the traversal
- * of the channels list as it's done synchronously with the only writer.
+ * LOCKING: edge->channels_lock only needs to cover the list operations, as the
+ * worker is killed before any channels are deallocated
  */
 static void qcom_channel_state_worker(struct work_struct *work)
 {
struct qcom_smd_channel *channel;
struct qcom_smd_edge *edge = container_of(work,
  struct qcom_smd_edge,
- 

[PATCH v2 7/7] Bluetooth: btqcomsmd: Qualcomm WCNSS HCI driver

[Bjorn Andersson]

The Qualcomm WCNSS chip provides two SMD channels to the BT core; one
for command and one for event packets. This driver exposes the two
channels as a hci device.

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

Changes since v1:
- With the introduction of qcom_smd_open_channel() the two drivers are now one
- No more global state
- Corrected memory management of sk_buffs
- Reverted to __hci_cmd_sync_ev() for set_bdaddr
- Renamed the driver to btqcomsmd
- Split out the addition of HCI_SMD to separate patch

 drivers/bluetooth/Kconfig |  11 +++
 drivers/bluetooth/Makefile|   1 +
 drivers/bluetooth/btqcomsmd.c | 198 ++
 3 files changed, 210 insertions(+)
 create mode 100644 drivers/bluetooth/btqcomsmd.c

diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig
index 62999546a301..1652997e59cc 100644
--- a/drivers/bluetooth/Kconfig
+++ b/drivers/bluetooth/Kconfig
@@ -169,6 +169,17 @@ config BT_HCIUART_QCA
 
  Say Y here to compile support for QCA protocol.
 
+config BT_QCOMSMD
+   tristate "Qualcomm SMD based HCI support"
+   depends on QCOM_SMD
+   help
+ Qualcomm SMD based HCI driver.
+ This driver is used to bridge HCI data onto the shared memory
+ channels to the WCNSS core.
+
+ Say Y here to compile support for HCI over Qualcomm SMD into the
+ kernelor say M to compile as a module.
+
 config BT_HCIBCM203X
tristate "HCI BCM203x USB driver"
depends on USB
diff --git a/drivers/bluetooth/Makefile b/drivers/bluetooth/Makefile
index 07c9cf381e5a..19e313bf8c39 100644
--- a/drivers/bluetooth/Makefile
+++ b/drivers/bluetooth/Makefile
@@ -23,6 +23,7 @@ obj-$(CONFIG_BT_WILINK)   += btwilink.o
 obj-$(CONFIG_BT_BCM)   += btbcm.o
 obj-$(CONFIG_BT_RTL)   += btrtl.o
 obj-$(CONFIG_BT_QCA)   += btqca.o
+obj-$(CONFIG_BT_QCOMSMD)   += btqcomsmd.o
 
 btmrvl-y   := btmrvl_main.o
 btmrvl-$(CONFIG_DEBUG_FS)  += btmrvl_debugfs.o
diff --git a/drivers/bluetooth/btqcomsmd.c b/drivers/bluetooth/btqcomsmd.c
new file mode 100644
index ..4b91c830531e
--- /dev/null
+++ b/drivers/bluetooth/btqcomsmd.c
@@ -0,0 +1,198 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define EDL_NVM_ACCESS_SET_REQ_CMD 0x01
+#define EDL_NVM_ACCESS_OPCODE  0xfc0b
+
+struct btqcomsmd {
+   struct qcom_smd_channel *acl_channel;
+   struct qcom_smd_channel *cmd_channel;
+};
+
+static int btqcomsmd_recv(struct hci_dev *hdev,
+ unsigned type,
+ const void *data,
+ size_t count)
+{
+   struct sk_buff *skb;
+   void *buf;
+
+   /* Use GFP_ATOMIC as we're in IRQ context */
+   skb = bt_skb_alloc(count, GFP_ATOMIC);
+   if (!skb)
+   return -ENOMEM;
+
+   bt_cb(skb)->pkt_type = type;
+
+   /* Use io accessor as data might be ioremapped */
+   buf = skb_put(skb, count);
+   memcpy_fromio(buf, data, count);
+
+   return hci_recv_frame(hdev, skb);
+}
+
+static int btqcomsmd_acl_callback(struct qcom_smd_device *qsdev,
+ const void *data,
+ size_t count)
+{
+   struct hci_dev *hdev = dev_get_drvdata(>dev);
+
+   return btqcomsmd_recv(hdev, HCI_ACLDATA_PKT, data, count);
+}
+
+static int btqcomsmd_cmd_callback(struct qcom_smd_device *qsdev,
+ const void *data,
+ size_t count)
+{
+   struct hci_dev *hdev = dev_get_drvdata(>dev);
+
+   return btqcomsmd_recv(hdev, HCI_EVENT_PKT, data, count);
+}
+
+static int btqcomsmd_send(struct hci_dev *hdev, struct sk_buff *skb)
+{
+   struct btqcomsmd *btq = hci_get_drvdata(hdev);
+   int ret;
+
+   switch (bt_cb(skb)->pkt_type) {
+   case HCI_ACLDATA_PKT:
+   case HCI_SCODATA_PKT:
+   ret = qcom_smd_send(btq->acl_channel, skb->data, skb->len);
+   break;
+   case HCI_COMMAND_PKT:
+   ret = qcom_smd_send(btq->cmd_channel, skb->data, skb->len);
+   break;
+   default:
+   ret = -ENODEV;
+   break;
+   }
+
+   return ret;
+}
+
+static int btqcomsmd_open(struct hci_dev *hdev)
+{
+   set_bit(HCI_RUNNING, >flags);
+ 

[PATCH v2 3/7] soc: qcom: smd: Refactor channel open and close handling

[Bjorn Andersson]

Refactor opening and closing of channels into two separate functions
instead of open coding this in the various places.

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

Changes since v1:
- New patch

 drivers/soc/qcom/smd.c | 62 --
 1 file changed, 40 insertions(+), 22 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index fb5f91efd0da..669bda585dad 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -806,18 +806,12 @@ static int qcom_smd_dev_match(struct device *dev, struct 
device_driver *drv)
 }
 
 /*
- * Probe the smd client.
- *
- * The remote side have indicated that it want the channel to be opened, so
- * complete the state handshake and probe our client driver.
+ * Helper for opening a channel
  */
-static int qcom_smd_dev_probe(struct device *dev)
+static int qcom_smd_channel_open(struct qcom_smd_channel *channel,
+qcom_smd_cb_t cb)
 {
-   struct qcom_smd_device *qsdev = to_smd_device(dev);
-   struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
-   struct qcom_smd_channel *channel = qsdev->channel;
size_t bb_size;
-   int ret;
 
/*
 * Packets are maximum 4k, but reduce if the fifo is smaller
@@ -827,11 +821,44 @@ static int qcom_smd_dev_probe(struct device *dev)
if (!channel->bounce_buffer)
return -ENOMEM;
 
-   qcom_smd_channel_set_callback(channel, qsdrv->callback);
+   qcom_smd_channel_set_callback(channel, cb);
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENING);
-
qcom_smd_channel_set_state(channel, SMD_CHANNEL_OPENED);
 
+   return 0;
+}
+
+/*
+ * Helper for closing and resetting a channel
+ */
+static void qcom_smd_channel_close(struct qcom_smd_channel *channel)
+{
+   qcom_smd_channel_set_callback(channel, NULL);
+
+   kfree(channel->bounce_buffer);
+   channel->bounce_buffer = NULL;
+
+   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
+   qcom_smd_channel_reset(channel);
+}
+
+/*
+ * Probe the smd client.
+ *
+ * The remote side have indicated that it want the channel to be opened, so
+ * complete the state handshake and probe our client driver.
+ */
+static int qcom_smd_dev_probe(struct device *dev)
+{
+   struct qcom_smd_device *qsdev = to_smd_device(dev);
+   struct qcom_smd_driver *qsdrv = to_smd_driver(dev);
+   struct qcom_smd_channel *channel = qsdev->channel;
+   int ret;
+
+   ret = qcom_smd_channel_open(channel, qsdrv->callback);
+   if (ret)
+   return ret;
+
ret = qsdrv->probe(qsdev);
if (ret)
goto err;
@@ -843,11 +870,7 @@ static int qcom_smd_dev_probe(struct device *dev)
 err:
dev_err(>dev, "probe failed\n");
 
-   qcom_smd_channel_set_callback(channel, NULL);
-   kfree(channel->bounce_buffer);
-   channel->bounce_buffer = NULL;
-
-   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
+   qcom_smd_channel_close(channel);
return ret;
 }
 
@@ -884,12 +907,7 @@ static int qcom_smd_dev_remove(struct device *dev)
 * The client is now gone, cleanup and reset the channel state.
 */
channel->qsdev = NULL;
-   kfree(channel->bounce_buffer);
-   channel->bounce_buffer = NULL;
-
-   qcom_smd_channel_set_state(channel, SMD_CHANNEL_CLOSED);
-
-   qcom_smd_channel_reset(channel);
+   qcom_smd_channel_close(channel);
 
return 0;
 }
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 6/7] Bluetooth: Add HCI device identifier for Qualcomm SMD

[Bjorn Andersson]

This patch assigns the next free HCI device identifier to Bluetooth
devices based on the Qualcomm Shared Memory channels.

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

Changes since v1:
- Split out this from the btqcomsmd patch

 include/net/bluetooth/hci.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index e7f938cac7c6..adfb371a19f9 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -60,6 +60,7 @@
 #define HCI_RS232  4
 #define HCI_PCI5
 #define HCI_SDIO   6
+#define HCI_SMD7
 
 /* HCI controller types */
 #define HCI_BREDR  0x00
-- 
2.4.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] soc: qcom: smd: Correct SMEM items for upper channels

[Bjorn Andersson]

Update the SMEM items for the second set of SMD channels, as these where
incorrect.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 drivers/soc/qcom/smd.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 18964f1..e7fb8fa 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -87,8 +87,8 @@ static const struct {
.fifo_base_id = 338
},
{
-   .alloc_tbl_id = 14,
-   .info_base_id = 266,
+   .alloc_tbl_id = 266,
+   .info_base_id = 138,
.fifo_base_id = 202,
},
 };
-- 
2.3.2 (Apple Git-55)

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Bluetooth: hci_smd: Qualcomm WCNSS HCI driver

[Bjorn Andersson]

On Sat 03 Oct 09:55 PDT 2015, Marcel Holtmann wrote:

> Hi Bjorn,
> 
[..]
> >> Especially the kbuild test robot complained loudly.
> >>
> >
> > Sorry, I forgot to mention in the patch that the patch depends on the
> > qcom_smd_id patch - that's available in linux-next. I will take another
> > look, but I think that was the cause of all the issues.
> 
> which means, I can only merge this driver when this other patch has
> hit net-next tree. Unless I take the qcom_smd_id through
> bluetooth-next tree which doesn't look like a good idea.
> 

I was going to suggest that we just wait for -rc1, but the new additions
to SMD adds a bunch of new items on the dependency list.

Perhaps once we agree we can get your Ack and have Andy pull it through
the qcom-soc tree together with the SMD patches?

> >>> obj-$(CONFIG_BT_INTEL)  += btintel.o
> >>> obj-$(CONFIG_BT_ATH3K)  += ath3k.o
> >>> diff --git a/drivers/bluetooth/hci_smd.c b/drivers/bluetooth/hci_smd.c
> > [..]
> >>> +#include 
> >>
> >> The hci.h include is not needed. If you do, then you are doing
> >> something fishy.
> >>
> >
> > Nothing fishy going on here, so I'll drop it.
> >
> >>> +
> >>> +static struct {
> >>> +   struct qcom_smd_channel *acl_channel;
> >>> +   struct qcom_smd_channel *cmd_channel;
> >>> +
> >>> +   struct hci_dev *hci;
> >>> +} smd_hci;
> >>
> >> A driver that only supports a single instance of a device and uses a
> >> global variable to do so is not a good idea. There should be no reason
> >> for this. Why is this done this way.
> >>
> >
> > There's two channels coming up, each probing the associated driver that
> > combines these into 1 hci device.
> >
> > So I have two options;
> >
> > * the original idea was to implement multi-channel-per-device support in
> >  SMD, but as this is the only known case where that's needed I really
> >  don't want to add all the extra complexity to SMD.
> >
> > * I can accept the fact that this is silicon inside the MSM SoC and
> >  should never exist in more than one instance and make this hack. The
> >  first version I implemented had this structure allocated on the first
> >  probe, but that didn't really add any value to the static struct.
> >
> > I picked the second option due to the fact that the patch to SMD was way
> > bigger then this patch, and full of nasty logic.
> 
> Writing a driver that assume it is a single instance of a given device
> is never a good idea. While you might find some instances in the
> kernel if you look hard enough, but that doesn't mean we should keep
> doing this. So this needs addressing.
> 

Fair enough.

> >
> >>> +
> >>> +static int smd_hci_recv(unsigned type, const void *data, size_t count)
> >>> +{
> >>> +   struct sk_buff *skb;
> >>> +   void *buf;
> >>> +   int ret;
> >>> +
> >>> +   skb = bt_skb_alloc(count, GFP_ATOMIC);
> >>
> >> Is it required that this is GFP_ATOMIC or can this actually be
> >> GFP_KERNEL?
> >>
> >
> > This is being called from IRQ context upon receiving data on the
> > channels.
> 
> I wonder why that is needed, but seems an issue in the SMD subsystem.
> So this is fine, might want to add a comment above the bt_skb_alloc to
> remind us.
> 

It's a design choice of mine, to deliver the incoming data directly from
the interrupt handler. Sure enough we could have had a worker thread or
something do it.

I'll add a comment.

> >
> >>> +   if (!skb)
> >>> +   return -ENOMEM;
> >>> +
> >>> +   buf = skb_put(skb, count);
> >>> +   memcpy_fromio(buf, data, count);
> >>
> >> Why is this a memcpy_fromio here?
> >>
> >
> > A memcpy here doesn't seem to work on ARM64, probably because the
> > pointer references ioremapped memory. We are discussing either marking
> > the data __iomem or perhaps using memremap rather then ioremap.
> 
> I would add a comment here as well to remind everybody why this is
> used. And marking up the pointers is a good idea as well.
> 

Yeah, I have this on the todo.
Will put a comment here for now.

[..]

> >>> +
> >>> +   return ret;
> >>> +}
> >>> +
> >>> +static int smd_hci_open(struct hci_dev *hci)
> >>> +{
> >>> +   return 0;
> >>> +}
> >>> +
> >>> +static int smd_hci_close(struct hci_dev *hci)
> >>> +{
> >>> +   return 0;
> >>> +}
> >>
> >> These two need to at least handling the HCI_RUNNING flag setting and
> >> clearing like all the other drivers do.
> >>
> >
> > I'm puzzled to the purpose of this, is this only for indication to user
> > space or am I missing something?
> >
> > I found a couple of others that does nothing but set and clear this bit
> > in their open and close. Would you be open for a framework patch that
> > provides this functionality to drivers that doesn't need anything else?
> 
> This has been in the drivers for as long as the Bluetooth subsystem
> has been merged upstream. So Linux 2.4.6 to be precise. I had plans to
> move this code into the core, but that has not happened yet. So until
> then, lets just include the HCI_RUNNING part.
> 

I'll add the pieces.

> 

Re: [PATCH 1/4] qcom-scm: add ocmem support

[Bjorn Andersson]

On Mon 28 Sep 14:08 PDT 2015, Rob Clark wrote:

> On Mon, Sep 28, 2015 at 4:51 PM, Stephen Boyd  wrote:
> > On 09/28, Rob Clark wrote:
> >> Add interfaces needed for configuring OCMEM.
> >>
> >> Signed-off-by: Rob Clark 
> >> ---
> >>  drivers/firmware/qcom_scm-32.c |  57 ++
> >>  drivers/firmware/qcom_scm-64.c |  16 +++
> >>  drivers/firmware/qcom_scm.c| 106 
> >> +
> >>  drivers/firmware/qcom_scm.h|  13 +
> >>  include/linux/qcom_scm.h   |  10 
> >>  5 files changed, 202 insertions(+)
> >>
> >> diff --git a/drivers/firmware/qcom_scm-32.c 
> >> b/drivers/firmware/qcom_scm-32.c
[..]
> >> +bool qcom_scm_ocmem_secure_available(void)
> >> +{
> >> + int ret = qcom_scm_clk_enable();
> >
> > I doubt we need to enable clocks to figure out if a call is
> > available. Please drop clk stuff here.
> 
> hmm, hdcp did, but pas didn't..  otoh it looks like the call to
> __qcom_scm_pas_supported() *should* be wrapped in clk enable/disable..
> 
> And __qcom_scm_is_call_available() does call qcom_scm_call().  Which
> is, I assume, what needs the clk's..  so not entirely sure if *all*
> the clk enable/disable stuff should be stripped out, or if missing clk
> stuff should be added in qcom_scm_pas_supported()..
> 

The scm clocks here are the crypto engine clocks, they are not needed to
check if TZ implements PAS for a given processor or not.

But it could be argued that this is simply an assumption I make of the
black box we're calling into...

> 
> >> +
> >> + if (ret)
> >> + goto clk_err;
> >> +
> >> + ret = __qcom_scm_is_call_available(QCOM_SCM_OCMEM_SECURE_SVC,
> >> + QCOM_SCM_OCMEM_SECURE_CFG);
> >> +
> >> + qcom_scm_clk_disable();
> >> +
> >> +clk_err:
> >> + return (ret > 0) ? true : false;
> >> +}
> >> +EXPORT_SYMBOL(qcom_scm_ocmem_secure_available);
> >> +
[..]
> >> +int qcom_scm_ocmem_unlock(uint32_t id, uint32_t offset, uint32_t size)
> >> +{
> >> + int ret = qcom_scm_clk_enable();
> >> +
> >> + if (ret)
> >> + return ret;
> >> +
> >> + ret = __qcom_scm_ocmem_unlock(id, offset, size);
> >> + qcom_scm_clk_disable();
> >> +
> >> + return ret;
> >> +}
> >> +EXPORT_SYMBOL(qcom_scm_ocmem_unlock);
> >
> > I don't think we need any clocks for lock/unlock/cfg either. The
> > scm clocks are some crypto clocks that the secure side isn't able
> > to enable and we don't have a device in DT for them. In the ocmem
> > case, we should rely on the ocmem device to get the clocks and
> > turn them on before calling any scm APIs that may require those
> > clocks.
> 
> Hmm, if that is true then we should probably drop the clks for hdcp
> fxns too, and maybe add a comment somewhere since it isn't really
> clear what the clks are for (and when it is unclear, folks will just
> cargo-cult what the existing fxns are doing).  As-is it is hard to
> tell what is required and what is luck..
> 

I would expect hdcp to use the crypto engines in some way and we don't
want people to feel that they should add the random clocks here, so
commenting them is probably the way to go.

> >> diff --git a/include/linux/qcom_scm.h b/include/linux/qcom_scm.h
> >> index 46d41e4..a934457 100644
> >> --- a/include/linux/qcom_scm.h
> >> +++ b/include/linux/qcom_scm.h
> >> @@ -23,10 +23,20 @@ struct qcom_scm_hdcp_req {
> >>   u32 val;
> >>  };
> >>
> >> +extern bool qcom_scm_is_available(void);
> >
> > Is this used? Looks like noise.
> 
> perhaps should be split out into a separate patch..  but I am using
> this, and it seems like a good idea to avoid null ptr deref's of
> __scm.  Probably some of the scm callers should call this first..
> either that or we should make other scm entry points behave better if
> __scm is null..
> 

This is part of Andy's platformication, didn't he export it properly?
I use it as well from the remoteproc.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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

[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 linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/4] WCNSS Peripheral Image Loader

[Bjorn Andersson]

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


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

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

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

-- 
1.8.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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] firmware: qcom: scm: Peripheral Authentication Service

[Bjorn Andersson]

On Thu 24 Sep 12:13 PDT 2015, Stephen Boyd wrote:

> On 09/23, Bjorn Andersson wrote:
> > +
> > +int __qcom_scm_pas_mem_setup(u32 peripheral, phys_addr_t addr, phys_addr_t 
> > size)
> 
> Maybe we should make addr and size u32s as well. Kumar requested
> we take the same approach for other scm calls.
> 

So you're saying that on arm64 we're always going to load firmware in
the lower 32 bits of memory?


Not sure what the benefit of doing this conversion higher up in the
layers are, but sure we could do it...

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 5/5] soc: qcom: smp2p: Qualcomm Shared Memory Point to Point

[Bjorn Andersson]

Introduce the Qualcomm Shard Memory Point to Point driver.

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

Changes since v1:
- Use the newly created smem state helper instead of gpiolib

 drivers/soc/qcom/Kconfig  |   8 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/smp2p.c  | 578 ++
 3 files changed, 587 insertions(+)
 create mode 100644 drivers/soc/qcom/smp2p.c

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 015baf47874c..7fc0d08c6f14 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -52,6 +52,14 @@ config QCOM_SMD_RPM
 config QCOM_SMEM_STATE
bool
 
+config QCOM_SMP2P
+   bool "Qualcomm Shared Memory Point to Point support"
+   depends on QCOM_SMEM
+   select QCOM_SMEM_STATE
+   help
+ Say yes here to support the Qualcomm Shared Memory Point to Point
+ protocol.
+
 config QCOM_SMSM
bool "Qualcomm Shared Memory State Machine"
depends on QCOM_SMEM
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 452c505dafe4..69886e0f7ef8 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -4,4 +4,5 @@ obj-$(CONFIG_QCOM_SMD) +=   smd.o
 obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
 obj-$(CONFIG_QCOM_SMEM) += smem.o
 obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
+obj-$(CONFIG_QCOM_SMP2P)   += smp2p.o
 obj-$(CONFIG_QCOM_SMSM)+= smsm.o
diff --git a/drivers/soc/qcom/smp2p.c b/drivers/soc/qcom/smp2p.c
new file mode 100644
index ..f1eed7f9dd67
--- /dev/null
+++ b/drivers/soc/qcom/smp2p.c
@@ -0,0 +1,578 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * 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:irq_domain for inbound entries
+ * @irq_enabled:bitmap to track enabled irq bits
+ * @irq_rising:bitmap to mark irq bits for rising detection
+ * @irq_falling:bitmap to mark irq bits for falling detection
+ * @state: smem state handl

[PATCH v2 3/5] soc: qcom: Introduce common SMEM state machine code

[Bjorn Andersson]

This implements a common API for handling and exposing SMP2P and SMSM
state information.

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

Changes since v1:
- Introduced this file with stuff we previously got free from gpiolib

 drivers/soc/qcom/Kconfig|   3 +
 drivers/soc/qcom/Makefile   |   1 +
 drivers/soc/qcom/smem_state.c   | 201 
 include/linux/soc/qcom/smem_state.h |  18 
 4 files changed, 223 insertions(+)
 create mode 100644 drivers/soc/qcom/smem_state.c
 create mode 100644 include/linux/soc/qcom/smem_state.h

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 3e4d2133c3d2..68b261677046 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -48,3 +48,6 @@ config QCOM_SMD_RPM
 
  Say M here if you want to include support for the Qualcomm RPM as a
  module. This will build a module called "qcom-smd-rpm".
+
+config QCOM_SMEM_STATE
+   bool
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 10a93d168e0e..d756033a4630 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_QCOM_PM)   +=  spm.o
 obj-$(CONFIG_QCOM_SMD) +=  smd.o
 obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
 obj-$(CONFIG_QCOM_SMEM) += smem.o
+obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
diff --git a/drivers/soc/qcom/smem_state.c b/drivers/soc/qcom/smem_state.c
new file mode 100644
index ..54261decb369
--- /dev/null
+++ b/drivers/soc/qcom/smem_state.c
@@ -0,0 +1,201 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static LIST_HEAD(smem_states);
+static DEFINE_MUTEX(list_lock);
+
+/**
+ * struct qcom_smem_state - state context
+ * @refcount:  refcount for the state
+ * @orphan:boolean indicator that this state has been unregistered
+ * @list:  entry in smem_states list
+ * @of_node:   of_node to use for matching the state in DT
+ * @priv:  implementation private data
+ * @ops:   ops for the state
+ */
+struct qcom_smem_state {
+   struct kref refcount;
+   bool orphan;
+
+   struct list_head list;
+   struct device_node *of_node;
+
+   void *priv;
+
+   struct qcom_smem_state_ops ops;
+};
+
+/**
+ * qcom_smem_state_update_bits() - update the masked bits in state with value
+ * @state: state handle acquired by calling qcom_smem_state_get()
+ * @mask:  bit mask for the change
+ * @value: new value for the masked bits
+ *
+ * Returns 0 on success, otherwise negative errno.
+ */
+int qcom_smem_state_update_bits(struct qcom_smem_state *state,
+   u32 mask,
+   u32 value)
+{
+   if (state->orphan)
+   return -ENXIO;
+
+   if (!state->ops.update_bits)
+   return -ENOTSUPP;
+
+   return state->ops.update_bits(state->priv, mask, value);
+}
+EXPORT_SYMBOL_GPL(qcom_smem_state_update_bits);
+
+static struct qcom_smem_state *of_node_to_state(struct device_node *np)
+{
+   struct qcom_smem_state *state;
+
+   mutex_lock(_lock);
+
+   list_for_each_entry(state, _states, list) {
+   if (state->of_node == np) {
+   kref_get(>refcount);
+   goto unlock;
+   }
+   }
+   state = ERR_PTR(-EPROBE_DEFER);
+
+unlock:
+   mutex_unlock(_lock);
+
+   return state;
+}
+
+/**
+ * qcom_smem_state_get() - acquire handle to a state
+ * @dev:   client device pointer
+ * @con_id:name of the state to lookup
+ * @bit:   flags from the state reference, indicating which bit's affected
+ *
+ * Returns handle to the state, or ERR_PTR(). qcom_smem_state_put() must be
+ * called to release the returned state handle.
+ */
+struct qcom_smem_state *qcom_smem_state_get(struct device *dev,
+   const char *con_id,
+   unsigned *bit)
+{
+   struct qcom_smem_state *state;
+   struct of_phandle_args args;
+   int index = 0;
+   int ret;
+
+   if (con_id) {
+   index = of_property_match_string(dev->of_node,
+"qcom,state-names",
+con_id);
+   i

[PATCH v2 0/5] Qualcomm Shared Memory State Machines

[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 linux-arm-msm" 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 01/10] soc: qcom: documentation: Update SMD/RPM Docs

[Bjorn Andersson]

On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote:

> This patch moves the qcom,smd-rpm.txt to the correct location and splits
> out the smd and rpm documentation.  In addition, a smd-rpm-regulator
> document is added.
> 

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

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 4/5] soc: qcom: smsm: Add driver for Qualcomm SMSM

[Bjorn Andersson]

This driver exposed the Qualcomm Shared Memory State Machine bits.

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

Changes since v1:
- Use the newly created smem state helper instead of gpiolib

 drivers/soc/qcom/Kconfig  |   8 +
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/smsm.c   | 625 ++
 3 files changed, 634 insertions(+)
 create mode 100644 drivers/soc/qcom/smsm.c

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 68b261677046..015baf47874c 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -51,3 +51,11 @@ config QCOM_SMD_RPM
 
 config QCOM_SMEM_STATE
bool
+
+config QCOM_SMSM
+   bool "Qualcomm Shared Memory State Machine"
+   depends on QCOM_SMEM
+   select QCOM_SMEM_STATE
+   help
+ Say yes here to support the Qualcomm Shared Memory State Machine.
+ The state machine is represented by bits in shared memory.
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index d756033a4630..452c505dafe4 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -4,3 +4,4 @@ obj-$(CONFIG_QCOM_SMD) +=   smd.o
 obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
 obj-$(CONFIG_QCOM_SMEM) += smem.o
 obj-$(CONFIG_QCOM_SMEM_STATE) += smem_state.o
+obj-$(CONFIG_QCOM_SMSM)+= smsm.o
diff --git a/drivers/soc/qcom/smsm.c b/drivers/soc/qcom/smsm.c
new file mode 100644
index ..6b777af1bc19
--- /dev/null
+++ b/drivers/soc/qcom/smsm.c
@@ -0,0 +1,625 @@
+/*
+ * 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 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * 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
+ * @state: smem state handle
+ * @lock:  spinlock for read-modify-write of the outgoing state
+ * @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 qcom_smem_state *state;
+
+   spinlock_t lock;
+
+   struct smsm_entry *entries;
+   struct smsm_host *hosts;
+};
+
+/**
+ * struct smsm_entry - per remote processor entry context
+ * @smsm:  back-reference to driver con

[PATCH v2 1/5] dt-binding: soc: qcom: Add Qualcomm SMSM device tree documentation

[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 linux-arm-msm" 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

[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 linux-arm-msm" 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 03/10] arm64: dts: qcom: Add MSM8916 SMEM nodes

[Bjorn Andersson]

On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote:

> This patch adds the nodes necessary to support the SMEM driver on MSM8916
> platforms.
> 

Looks reasonable, I've not reviewed the addresses of things, but I
presume you have :)

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

Reards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] soc: qcom: smd: Reject send of too big packets

[Bjorn Andersson]

Attempting to find room for a packet that's bigger than the fifo will
never succeed and the calling process will be sleeping forever in the
loop, waiting for enough room. So fail early instead.

Reported-by: Courtney Cavin <courtney.ca...@sonymobile.com>
Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
 drivers/soc/qcom/smd.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/soc/qcom/smd.c b/drivers/soc/qcom/smd.c
index 18964f154383..88353bda1ea4 100644
--- a/drivers/soc/qcom/smd.c
+++ b/drivers/soc/qcom/smd.c
@@ -723,6 +723,10 @@ int qcom_smd_send(struct qcom_smd_channel *channel, const 
void *data, int len)
if (channel->info_word && len % 4)
return -EINVAL;
 
+   /* Reject packets that are too big */
+   if (tlen >= channel->fifo_size)
+   return -EINVAL;
+
ret = mutex_lock_interruptible(>tx_lock);
if (ret)
return ret;
-- 
1.8.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 08/10] arm: dts: Add RPM/SMD support on APQ8084

[Bjorn Andersson]

On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote:

> This patch adds support for RPM and SMD nodes that are present on APQ8084
> platforms.
> 

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

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 07/10] arm: dts: Add APQ8084 SMEM nodes

[Bjorn Andersson]

On Thu 24 Sep 12:18 PDT 2015, Andy Gross wrote:

> This patch adds all the required nodes to support SMEM on APQ8084
> 

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

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 02/10] soc: qcom: smd-rpm: Add existing platform support

[Bjorn Andersson]

On Wed 23 Sep 09:53 PDT 2015, Andy Gross wrote:

> This patch adds support for all current Qualcomm platforms which utilize
> RPM over SMD.  This includes both MSM8916 and APQ8084.
> 
> Signed-off-by: Andy Gross <agr...@codeaurora.org>
> ---
>  .../devicetree/bindings/soc/qcom/qcom,smd-rpm.txt  |2 ++
>  drivers/soc/qcom/smd-rpm.c |2 ++
>  2 files changed, 4 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt 
> b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
> index 3710dd5..7d05246 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm.txt
> @@ -20,6 +20,8 @@ resources.
>   Value type: 
>   Definition: must be one of:
>   "qcom,rpm-msm8974"
> + "qcom,rpm-msm8916"
> + "qcom,rpm-apq8084"
>  
>  - qcom,smd-channels:
>   Usage: required
> diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
> index 1392ccf..455083c 100644
> --- a/drivers/soc/qcom/smd-rpm.c
> +++ b/drivers/soc/qcom/smd-rpm.c
> @@ -212,6 +212,8 @@ static void qcom_smd_rpm_remove(struct qcom_smd_device 
> *sdev)
>  
>  static const struct of_device_id qcom_smd_rpm_of_match[] = {
>   { .compatible = "qcom,rpm-msm8974" },
> + { .compatible = "qcom,rpm-msm8916" },
> + { .compatible = "qcom,rpm-apq8084" },
>   {}

This is now how the alphabet works, please update the order and add:

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

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 06/10] regulators: qcom-smd: Add PM8916 support

[Bjorn Andersson]

On Wed 23 Sep 09:53 PDT 2015, Andy Gross wrote:

> This patch adds support and documentation for the PM8916 regulators
> found on MSM8916 platforms.
> 
> Signed-off-by: Andy Gross <agr...@codeaurora.org>
> ---
>  .../bindings/soc/qcom/qcom,smd-rpm-regulator.txt   |   18 ++
>  drivers/regulator/qcom_smd-regulator.c |   64 
> 
>  2 files changed, 82 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt 
> b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
> index 7084474..05dfc1a 100644
> --- a/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
> +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,smd-rpm-regulator.txt
> @@ -18,6 +18,7 @@ Regulator nodes are identified by their compatible:
>   Definition: must be one of:
>   "qcom,rpm-pm8841-regulators"
>   "qcom,rpm-pm8941-regulators"
> + "qcom,rpm-pm8916-regulators"

Alphabetical please

>  
>  - vdd_s1-supply:
>  - vdd_s2-supply:
> @@ -50,6 +51,19 @@ Regulator nodes are identified by their compatible:
>   Definition: reference to regulator supplying the input pin, as
>   described in the data sheet
>  
> +- vdd_s1-supply:
> +- vdd_s2-supply:
> +- vdd_s3-supply:
> +- vdd_s4-supply:
> +- vdd_l1_l2_l3-supply
> +- vdd_l4_l5_l6-supply
> +- vdd_l7-supply

End these with ':' as well

> +- vdd_l8_l9_l10_l11_l12_l13_l14_l15_l16_l17_l18-supply:
> + Usage: optional (pm8916 only)
> + Value type: 
> + Definition: reference to regulator supplying the input pin, as
> + described in the data sheet
> +
[..]
> diff --git a/drivers/regulator/qcom_smd-regulator.c 
> b/drivers/regulator/qcom_smd-regulator.c
[..]
>  static const struct of_device_id rpm_of_match[] = {
> + { .compatible = "qcom,rpm-pm8916-regulators", .data = 
> _pm8916_regulators },

pm8916 > pm8841

>   { .compatible = "qcom,rpm-pm8841-regulators", .data = 
> _pm8841_regulators },
>   { .compatible = "qcom,rpm-pm8941-regulators", .data = 
> _pm8941_regulators },
>   {}

With these nits:

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

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3] firmware: qcom: scm: Peripheral Authentication Service

[Bjorn Andersson]

This adds the Peripheral Authentication Service (PAS) interface to the
Qualcomm SCM interface. The API is used to authenticate and boot a range
of external processors in various Qualcomm platforms.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
Depends on Andy's platformization of the scm code.

Changes since v2:
- Attached the dma allocation in init_image to the scm dev
- Requesting scm clocks
- Fixed some more big endian stuff
- Added stubs for ARM64

Changes since v1:
- Big endian compatibility

 drivers/firmware/qcom_scm-32.c |  82 +
 drivers/firmware/qcom_scm-64.c |  25 
 drivers/firmware/qcom_scm.c| 136 +
 drivers/firmware/qcom_scm.h|  12 
 include/linux/qcom_scm.h   |   6 ++
 5 files changed, 261 insertions(+)

diff --git a/drivers/firmware/qcom_scm-32.c b/drivers/firmware/qcom_scm-32.c
index 29e6850665eb..e9c306bcd371 100644
--- a/drivers/firmware/qcom_scm-32.c
+++ b/drivers/firmware/qcom_scm-32.c
@@ -499,3 +499,85 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 
req_cnt, u32 *resp)
return qcom_scm_call(QCOM_SCM_SVC_HDCP, QCOM_SCM_CMD_HDCP,
req, req_cnt * sizeof(*req), resp, sizeof(*resp));
 }
+
+bool __qcom_scm_pas_supported(u32 peripheral)
+{
+   __le32 out;
+   __le32 in;
+   int ret;
+
+   in = cpu_to_le32(peripheral);
+   ret = qcom_scm_call(QCOM_SCM_SVC_PIL, QCOM_SCM_PAS_IS_SUPPORTED_CMD,
+   , sizeof(in),
+   , sizeof(out));
+
+   return ret ? false : !!out;
+}
+
+int __qcom_scm_pas_init_image(u32 peripheral, dma_addr_t metadata_phys)
+{
+   __le32 scm_ret;
+   int ret;
+   struct {
+   __le32 proc;
+   __le32 image_addr;
+   } request;
+
+   request.proc = cpu_to_le32(peripheral);
+   request.image_addr = cpu_to_le32(metadata_phys);
+
+   ret = qcom_scm_call(QCOM_SCM_SVC_PIL, QCOM_SCM_PAS_INIT_IMAGE_CMD,
+   , sizeof(request),
+   _ret, sizeof(scm_ret));
+
+   return ret ? : le32_to_cpu(scm_ret);
+}
+
+int __qcom_scm_pas_mem_setup(u32 peripheral, phys_addr_t addr, phys_addr_t 
size)
+{
+   __le32 scm_ret;
+   int ret;
+   struct {
+   __le32 proc;
+   __le32 addr;
+   __le32 len;
+   } request;
+
+   request.proc = cpu_to_le32(peripheral);
+   request.addr = cpu_to_le32(addr);
+   request.len = cpu_to_le32(size);
+
+   ret = qcom_scm_call(QCOM_SCM_SVC_PIL, QCOM_SCM_PAS_MEM_SETUP_CMD,
+   , sizeof(request),
+   _ret, sizeof(scm_ret));
+
+   return ret ? : le32_to_cpu(scm_ret);
+}
+
+int __qcom_scm_pas_auth_and_reset(u32 peripheral)
+{
+   __le32 out;
+   __le32 in;
+   int ret;
+
+   in = cpu_to_le32(peripheral);
+   ret = qcom_scm_call(QCOM_SCM_SVC_PIL, QCOM_SCM_PAS_AUTH_AND_RESET_CMD,
+   , sizeof(in),
+   , sizeof(out));
+
+   return ret ? : le32_to_cpu(out);
+}
+
+int __qcom_scm_pas_shutdown(u32 peripheral)
+{
+   __le32 out;
+   __le32 in;
+   int ret;
+
+   in = cpu_to_le32(peripheral);
+   ret = qcom_scm_call(QCOM_SCM_SVC_PIL, QCOM_SCM_PAS_SHUTDOWN_CMD,
+   , sizeof(in),
+   , sizeof(out));
+
+   return ret ? : le32_to_cpu(out);
+}
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index bb6555f6d63b..e64fd927e5ae 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -61,3 +61,28 @@ int __qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 
req_cnt, u32 *resp)
 {
return -ENOTSUPP;
 }
+
+bool __qcom_scm_pas_supported(u32 peripheral)
+{
+   return false;
+}
+
+int __qcom_scm_pas_init_image(u32 peripheral, dma_addr_t metadata_phys)
+{
+   return -ENOTSUPP;
+}
+
+int __qcom_scm_pas_mem_setup(u32 peripheral, phys_addr_t addr, phys_addr_t 
size)
+{
+   return -ENOTSUPP;
+}
+
+int __qcom_scm_pas_auth_and_reset(u32 peripheral)
+{
+   return -ENOTSUPP;
+}
+
+int __qcom_scm_pas_shutdown(u32 peripheral)
+{
+   return -ENOTSUPP;
+}
diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
index 5dd05142069d..118df0ae242b 100644
--- a/drivers/firmware/qcom_scm.c
+++ b/drivers/firmware/qcom_scm.c
@@ -20,6 +20,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -28,6 +29,7 @@
 #include "qcom_scm.h"
 
 struct qcom_scm {
+   struct device *dev;
struct clk *core_clk;
struct clk *iface_clk;
struct clk *bus_clk;
@@ -152,6 +154,138 @@ int qcom_scm_hdcp_req(struct qcom_scm_hdcp_req *req, u32 
req_cnt, u32 *resp)
 EXPORT_SYMBOL(qcom_scm_hdcp_req);
 
 /**
+ * qcom_scm_pas_supported() - Check if the peripheral authentication service is
+ *

Re: [PATCH v2 5/8] soc: qcom: smd: Remove use of VLAIS

[Bjorn Andersson]

On Wed 02 Sep 15:46 PDT 2015, Stephen Boyd wrote:

> Usage of VLAIS prevents clang from compiling this file, and it
> also opens us to the possibility of allocating a large structure
> on the stack to the point that we blow past the limit of the
> kernel stack. Remove the VLAIS and allocate a structure on the
> heap with kmalloc so that we're safer and more clang friendly.
> 
[..]
> diff --git a/drivers/soc/qcom/smd-rpm.c b/drivers/soc/qcom/smd-rpm.c
[..]
>   struct {
>   struct qcom_rpm_header hdr;
>   struct qcom_rpm_request req;
> - u8 payload[count];
> - } pkt;
> + u8 payload[];
> + } *pkt;
> + size_t size = sizeof(*pkt) + count;
>  
[..]
>  
> - ret = qcom_smd_send(rpm->rpm_channel, , sizeof(pkt));
> + ret = qcom_smd_send(rpm->rpm_channel, pkt, sizeof(*pkt));

It would be good if we actually include the request in the packet and
not just the headers :)

s/sizeof(*pkt)/size/

Sorry for not spotting this before, made my device not boot now that it
showed up in linux-next. And oddly the 8974 RPM seems to just ack the
messages, without any indication of the request being truncated...


@Andy, I presume this is only on your -next, can you update the commit?
Or do you want a patch for it?

With this tiny change what we have on next-20150921 seems to work fine.

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] soc: qcom: Introduce WCNSS_CTRL SMD client

[Bjorn Andersson]

The WCNSS_CTRL SMD client is used for among other things upload nv
firmware to a newly booted WCNSS chip.

Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
---
This driver probes on the WCNSS_CTRL SMD channel as it comes up upon loading
the wcnss firmware, it currenly request version information from the wcnss and
downloads the nv binary.

This is needed for bringing up the individual functions of the wcnss chip.

 drivers/soc/qcom/Kconfig  |   7 ++
 drivers/soc/qcom/Makefile |   1 +
 drivers/soc/qcom/wcnss_ctrl.c | 272 ++
 3 files changed, 280 insertions(+)
 create mode 100644 drivers/soc/qcom/wcnss_ctrl.c

diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index ba47b70f4d85..453ceb1af682 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -48,3 +48,10 @@ config QCOM_SMEM
  Say y here to enable support for the Qualcomm Shared Memory Manager.
  The driver provides an interface to items in a heap shared among all
  processors in a Qualcomm platform.
+
+config QCOM_WCNSS_CTRL
+   tristate "Qualcomm WCNSS control driver"
+   depends on QCOM_SMD
+   help
+ Client driver for the WCNSS_CTRL SMD channel, used to download nv
+ firmware to a newly booted WCNSS chip.
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 10a93d168e0e..9823103ea843 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -3,3 +3,4 @@ obj-$(CONFIG_QCOM_PM)   +=  spm.o
 obj-$(CONFIG_QCOM_SMD) +=  smd.o
 obj-$(CONFIG_QCOM_SMD_RPM) += smd-rpm.o
 obj-$(CONFIG_QCOM_SMEM) += smem.o
+obj-$(CONFIG_QCOM_WCNSS_CTRL) += wcnss_ctrl.o
diff --git a/drivers/soc/qcom/wcnss_ctrl.c b/drivers/soc/qcom/wcnss_ctrl.c
new file mode 100644
index ..7a986f881d5c
--- /dev/null
+++ b/drivers/soc/qcom/wcnss_ctrl.c
@@ -0,0 +1,272 @@
+/*
+ * Copyright (c) 2015, Sony Mobile Communications Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+#include 
+#include 
+#include 
+#include 
+
+#define WCNSS_REQUEST_TIMEOUT  (5 * HZ)
+
+#define NV_FRAGMENT_SIZE   3072
+#define NVBIN_FILE "wlan/prima/WCNSS_qcom_wlan_nv.bin"
+
+/**
+ * struct wcnss_ctrl - driver context
+ * @dev:   device handle
+ * @channel:   SMD channel handle
+ * @ack:   completion for outstanding requests
+ * @ack_status:status of the outstanding request
+ * @download_nv_work: worker for uploading nv binary
+ */
+struct wcnss_ctrl {
+   struct device *dev;
+   struct qcom_smd_channel *channel;
+
+   struct completion ack;
+   int ack_status;
+
+   struct work_struct download_nv_work;
+};
+
+/* message types */
+enum {
+   WCNSS_VERSION_REQ = 0x0100,
+   WCNSS_VERSION_RESP,
+   WCNSS_DOWNLOAD_NV_REQ,
+   WCNSS_DOWNLOAD_NV_RESP,
+   WCNSS_UPLOAD_CAL_REQ,
+   WCNSS_UPLOAD_CAL_RESP,
+   WCNSS_DOWNLOAD_CAL_REQ,
+   WCNSS_DOWNLOAD_CAL_RESP,
+};
+
+/**
+ * struct wcnss_msg_hdr - common packet header for requests and responses
+ * @type:  packet message type
+ * @len:   total length of the packet, including this header
+ */
+struct wcnss_msg_hdr {
+   u32 type;
+   u32 len;
+} __packed;
+
+/**
+ * struct wcnss_version_resp - version request response
+ * @hdr:   common packet wcnss_msg_hdr header
+ */
+struct wcnss_version_resp {
+   struct wcnss_msg_hdr hdr;
+   u8 major;
+   u8 minor;
+   u8 version;
+   u8 revision;
+} __packed;
+
+/**
+ * struct wcnss_download_nv_req - firmware fragment request
+ * @hdr:   common packet wcnss_msg_hdr header
+ * @seq:   sequence number of this fragment
+ * @last:  boolean indicator of this being the last fragment of the binary
+ * @frag_size: length of this fragment
+ * @fragment:  fragment data
+ */
+struct wcnss_download_nv_req {
+   struct wcnss_msg_hdr hdr;
+   u16 seq;
+   u16 last;
+   u32 frag_size;
+   u8 fragment[];
+} __packed;
+
+/**
+ * struct wcnss_download_nv_resp - firmware download response
+ * @hdr:   common packet wcnss_msg_hdr header
+ * @status:boolean to indicate success of the download
+ */
+struct wcnss_download_nv_resp {
+   struct wcnss_msg_hdr hdr;
+   u8 status;
+} __packed;
+
+/**
+ * wcnss_ctrl_smd_callback() - handler from SMD responses
+ * @qsdev: smd device handle
+ * @data:  pointer to the incoming data packet
+ * @count: size of the incoming data packet
+ *
+ * Handles any incoming packets from the

Re: [PATCH v2 0/2] Add initial support for RPM clocks

[Bjorn Andersson]

On Mon 03 Aug 09:48 PDT 2015, Georgi Djakov wrote:

> This patchset adds initial support for the clocks controlled by
> the RPM (Resource Power Manager) processor on Qualcomm platforms.
> It depends on Bjorn's Qualcomm SMD & RPM patches, that are now in
> linux-next: https://lkml.org/lkml/2015/7/27/1125
> 
> The first patch implements the RPM clock operations, which are
> using a shared memory for sending requests to the RPM processor.
> The second patch adds the support of RPM clocks on the MSM8916
> platform.
> 

I pulled this set into my local tree and added a MSM8974 driver; so I
could enable cxo_a2 and load the WCNSS firmware. This works great.

I do however have a problem that if I revise the gcc and mmcc drivers to
be rooted in cxo_clk_src (like you have for 8916) the clk_set_rate() in
msm_serial messes up my uart - way before the rpmcc driver is loaded.
I have not debugged this further (as it wasn't needed for my usecase),
but have you seen any issues related to this?


Will you be able to send out v3 anytime soon, so I can rebase my 8974
patch and send that out? Or would you be interested in me sending you my
8974 and you can include that in your series later?

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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

[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 linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2 3/4] power: Add Qualcomm SMBB driver

[Bjorn Andersson]

On Tue 15 Sep 05:43 PDT 2015, Sebastian Reichel wrote:

> Hi,
> 
> On Thu, Jul 30, 2015 at 10:53:56AM -0700, Bjorn Andersson wrote:
> > From: Courtney Cavin <courtney.ca...@sonymobile.com>
> > 
> > Add the Qualcomm Switch-Mode Battery Charger and Boost driver, found in
> > pm8941.
> > 
> > Signed-off-by: Courtney Cavin <courtney.ca...@sonymobile.com>
> > Signed-off-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
> > ---
> > 
> > Changes since v1:
> > - Corrected authorship
> > - Dropped MODULE_ALIAS
> 
> Acked-By: Sebastian Reichel <s...@kernel.org>
> 
> I think the first patch made it into 4.3, so I can simply queue this
> patch together with the DT binding?
> 

That is correct, sorry for it not being mentioned in the thread.

Thanks,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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] firmware: qcom: scm: Add function stubs for ARM64

[Bjorn Andersson]

On Fri 11 Sep 14:01 PDT 2015, Andy Gross wrote:

> This patch adds stubs for the SCM functions exposed in the QCOM SCM API.
> 
> Signed-off-by: Andy Gross <agr...@codeaurora.org>
> ---
>  drivers/firmware/Kconfig   |8 +
>  drivers/firmware/Makefile  |3 +-
>  drivers/firmware/qcom_scm-64.c |   63 
> 
>  3 files changed, 73 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/firmware/qcom_scm-64.c
> 
> diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
> index 99c69a3..72720eb 100644
> --- a/drivers/firmware/Kconfig
> +++ b/drivers/firmware/Kconfig
> @@ -136,6 +136,14 @@ config QCOM_SCM
>   bool
>   depends on ARM || ARM64
>  
> +config QCOM_SCM_32
> + def_bool y
> + depends on QCOM_SCM && ARM
> +
> +config QCOM_SCM_64
> + def_bool y
> + depends on QCOM_SCM && ARM64
> +

So if QCOM_SCM is selected by a consumer then the dependencies here will
be met and the correct implementation will be chosen, as these aren't
possible to deselect?


I guess that's an okay approach, so:

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

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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

[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 linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] soc: qcom: smem: Move RPM message ram out of smem DT node

[Bjorn Andersson]

On Tue 08 Sep 15:20 PDT 2015, Stephen Boyd wrote:

> SMEM is a software construct built on top of a DDR carveout and
> sometimes a device memory called RPM message ram. Having the RPM
> message ram in the smem DT node's reg property leads to the smem
> node being located in different places depending on if the
> message ram is being used or not. Let's add a qcom specific
> property, qcom,rpm-msg-ram, and point to the device memory from
> the SMEM node via a phandle. This allows us to always have the
> SMEM node at the root of the DT regardless of whether it's using
> the message ram or not.
> 

Based on the codeaurora limit of 99 aux-mem regions I figured this had
to be more generic. But I think this makes sense and we can easily
extend it with other specific regions (if we ever find any of those
other 98 supported aux-mems).


Can you update the dt binding document as well?

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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] clk: qcom: Add support for RPM Clocks

[Bjorn Andersson]

On Thu 03 Sep 08:40 PDT 2015, Georgi Djakov wrote:

> Hi Stephen,
> 
> On 09/02/2015 11:31 PM, Stephen Boyd wrote:
> > On 08/03, Georgi Djakov wrote:
> >> diff --git a/drivers/clk/qcom/clk-smd-rpm.c 
> >> b/drivers/clk/qcom/clk-smd-rpm.c
> >> new file mode 100644
> >> index ..e564673ec3a5
> >> --- /dev/null
> >> +++ b/drivers/clk/qcom/clk-smd-rpm.c
> 
> [..]
> 
> >> +static int clk_smd_rpm_set_rate(struct clk_hw *hw, unsigned long rate,
> >> +  unsigned long parent_rate)
> >> +{
> >> +  struct clk_smd_rpm *r = to_clk_smd_rpm(hw);
> >> +  int ret = 0;
> >> +
> >> +  if (r->enabled) {
> >> +  u32 value;
> >> +  struct clk_smd_rpm *peer = r->peer;
> >> +
> >> +  /* Take peer clock's rate into account only if it's enabled. */
> >> +  if (peer->enabled)
> > 
> > This peer stuff almost doesn't even matter because we're only
> > sending active set requests. Why can't this code be updated to
> > send both active and sleep set requests? The sleep set stuff
> > won't be cached, etc., but I don't see a problem in doing both.
> > Otherwise we should drop all the peer stuff until we introduce
> > active only clocks.
> 
> Initially I tried sending both active and sleep sets, but as they are
> not cached like in downstream (yet) i got hangs during boot. Disabling
> caching in downstream kernel also caused the same hangs, so i left
> this out for now. Will try debugging it further.
> 

This sounds odd, although I presume the downstream code is rarely/never
tested with the caching disabled.

Can you please retry this with [1] applied (should be in -next), the RPM
fifo is tiny, so I would not be surprised if this could be your problem.

[1] https://lkml.org/lkml/2015/8/24/756

Regards,
Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 8/8] regulator: qcom_smd: Handle big endian CPUs

[Bjorn Andersson]

On Wed 02 Sep 15:46 PDT 2015, Stephen Boyd wrote:

> The smd rpm structures are always in little endian, but this
> driver is not capable of being used on big endian CPUs. Annotate
> the little endian data members and update the code to do the
> proper byte swapping.
> 
Reviewed-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 5/8] soc: qcom: smd: Remove use of VLAIS

[Bjorn Andersson]

On Wed 02 Sep 15:46 PDT 2015, Stephen Boyd wrote:

> Usage of VLAIS prevents clang from compiling this file, and it
> also opens us to the possibility of allocating a large structure
> on the stack to the point that we blow past the limit of the
> kernel stack. Remove the VLAIS and allocate a structure on the
> heap with kmalloc so that we're safer and more clang friendly.
> 
Reviewed-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 2/8] soc: qcom: smem: Handle big endian CPUs

[Bjorn Andersson]

On Wed 02 Sep 15:46 PDT 2015, Stephen Boyd wrote:

> The contents of smem are always in little endian, but the smem
> driver is not capable of being used on big endian CPUs. Annotate
> the little endian data members and update the code to do the
> proper byte swapping.
> 
Reviewed-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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/8] soc: qcom: Make qcom_smem_get() return a pointer

[Bjorn Andersson]

On Wed 02 Sep 15:46 PDT 2015, Stephen Boyd wrote:

> Passing a void ** almost always requires a cast at the call site.
> Instead of littering the code with casts every time this function
> is called, have qcom_smem_get() return a void pointer to the
> location of the smem item. This frees the caller from having to
> cast the pointer.
> 
Reviewed-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 7/8] soc: qcom: smd_rpm: Handle big endian CPUs

[Bjorn Andersson]

On Wed 02 Sep 15:46 PDT 2015, Stephen Boyd wrote:

> The smd rpm structures are always in little endian, but this
> driver is not capable of being used on big endian CPUs. Annotate
> the little endian data members and update the code to do the
> proper byte swapping.
> 
Reviewed-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" 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 6/8] soc: qcom: smd: Handle big endian CPUs

[Bjorn Andersson]

On Wed 02 Sep 15:46 PDT 2015, Stephen Boyd wrote:

> The smd structures are always in little endian, but the smd
> driver is not capable of being used on big endian CPUs. Annotate
> the little endian data members and update the code to do the
> proper byte swapping.
> 
Reviewed-by: Bjorn Andersson <bjorn.anders...@sonymobile.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html