Re: [PATCH v2 1/2] clk: qcom: Add support for RPM Clocks

2015-09-03 Thread Georgi Djakov 
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.

Will fix the rest according to your comments. Thank you!

BR,
Georgi
--
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 3/6] ARM: dts: apq8064-ifc6410: add notify led support.

2015-09-03 Thread Srinivas Kandagatla 



On 25/08/15 22:36, Stephen Boyd wrote:

On 08/18/2015 06:10 AM, Srinivas Kandagatla wrote:

diff --git a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
index b1f9ddb..08daafe 100644
--- a/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
+++ b/arch/arm/boot/dts/qcom-apq8064-ifc6410.dts
@@ -221,6 +221,18 @@
  status = "okay";
  };
+leds {
+compatible = "gpio-leds";
+pinctrl-names = "default";
+pinctrl-0 = <_led>;
+
+led@1 {
+label = "apq8064:green:user1";
+gpios = <_gpio 18 GPIO_ACTIVE_HIGH>;
+default-state = "on";
+};
+};


Wrong place. Should be in root, not soc node.

yep, Will move it to the root.



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

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

[PATCH] drm/msm/dsi: Parse lane swap information from DT

2015-09-03 Thread Hai Li 
Lane swap configuration is based on the board design.
This change allows the DSI host to get this information
from device tree, instead of hardcoding in driver.

Signed-off-by: Hai Li 
---
 Documentation/devicetree/bindings/drm/msm/dsi.txt | 13 ++
 drivers/gpu/drm/msm/dsi/dsi_host.c| 49 +--
 2 files changed, 49 insertions(+), 13 deletions(-)

diff --git a/Documentation/devicetree/bindings/drm/msm/dsi.txt 
b/Documentation/devicetree/bindings/drm/msm/dsi.txt
index d56923c..febcc51 100644
--- a/Documentation/devicetree/bindings/drm/msm/dsi.txt
+++ b/Documentation/devicetree/bindings/drm/msm/dsi.txt
@@ -44,6 +44,17 @@ Optional properties:
 - port: DSI controller output port. This contains one endpoint subnode, with 
its
   remote-endpoint set to the phandle of the connected panel's endpoint.
   See Documentation/devicetree/bindings/graph.txt for device graph info.
+- qcom,dsi-logical-lane-swap: Character string to swap logical lane to physical
+  lane mapping. Supported lane mappings:
+  "0123": Logic 0->Phys 0; Logic 1->Phys 1; Logic 2->Phys 2; Logic 3->Phys 3;
+  "3012": Logic 3->Phys 0; Logic 0->Phys 1; Logic 1->Phys 2; Logic 2->Phys 3;
+  "2301": Logic 2->Phys 0; Logic 3->Phys 1; Logic 0->Phys 2; Logic 1->Phys 3;
+  "1230": Logic 1->Phys 0; Logic 2->Phys 1; Logic 3->Phys 2; Logic 0->Phys 3;
+  "0321": Logic 0->Phys 0; Logic 3->Phys 1; Logic 2->Phys 2; Logic 1->Phys 3;
+  "1032": Logic 1->Phys 0; Logic 0->Phys 1; Logic 3->Phys 2; Logic 2->Phys 3;
+  "2103": Logic 2->Phys 0; Logic 1->Phys 1; Logic 0->Phys 2; Logic 3->Phys 3;
+  "3210": Logic 3->Phys 0; Logic 2->Phys 1; Logic 1->Phys 2; Logic 0->Phys 3;
+  Default value is "0123", which means no lane swap.
 
 DSI PHY:
 Required properties:
@@ -129,6 +140,8 @@ Example:
remote-endpoint = <_in>;
};
};
+
+   qcom,dsi-logical-lane-swap = "0123";
};
 
mdss_dsi_phy0: qcom,mdss_dsi_phy@fd922a00 {
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 8d82973f..eaba417 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -131,6 +131,7 @@ struct msm_dsi_host {
enum mipi_dsi_pixel_format format;
unsigned long mode_flags;
 
+   u32 dlane_swap;
u32 dma_cmd_ctrl_restore;
 
bool registered;
@@ -684,19 +685,9 @@ static void dsi_ctrl_config(struct msm_dsi_host *msm_host, 
bool enable,
data = DSI_CTRL_CLK_EN;
 
DBG("lane number=%d", msm_host->lanes);
-   if (msm_host->lanes == 2) {
-   data |= DSI_CTRL_LANE1 | DSI_CTRL_LANE2;
-   /* swap lanes for 2-lane panel for better performance */
-   dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL,
-   DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(LANE_SWAP_1230));
-   } else {
-   /* Take 4 lanes as default */
-   data |= DSI_CTRL_LANE0 | DSI_CTRL_LANE1 | DSI_CTRL_LANE2 |
-   DSI_CTRL_LANE3;
-   /* Do not swap lanes for 4-lane panel */
-   dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL,
-   DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(LANE_SWAP_0123));
-   }
+   data |= ((DSI_CTRL_LANE0 << msm_host->lanes) - DSI_CTRL_LANE0);
+   dsi_write(msm_host, REG_DSI_LANE_SWAP_CTRL,
+   DSI_LANE_SWAP_CTRL_DLN_SWAP_SEL(msm_host->dlane_swap));
 
if (!(flags & MIPI_DSI_CLOCK_NON_CONTINUOUS))
dsi_write(msm_host, REG_DSI_LANE_CTRL,
@@ -1289,6 +1280,9 @@ static int dsi_host_attach(struct mipi_dsi_host *host,
struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
int ret;
 
+   if (dsi->lanes > 4 || dsi->channel > 3)
+   return -EINVAL;
+
msm_host->channel = dsi->channel;
msm_host->lanes = dsi->lanes;
msm_host->format = dsi->format;
@@ -1344,6 +1338,33 @@ static struct mipi_dsi_host_ops dsi_host_ops = {
.transfer = dsi_host_transfer,
 };
 
+static void dsi_parse_dlane_swap(struct msm_dsi_host *msm_host,
+   struct device_node *np)
+{
+   const char *lane_swap;
+
+   lane_swap = of_get_property(np, "qcom,dsi-logical-lane-swap", NULL);
+
+   if (!lane_swap)
+   msm_host->dlane_swap = LANE_SWAP_0123;
+   else if (!strncmp(lane_swap, "3012", 5))
+   msm_host->dlane_swap = LANE_SWAP_3012;
+   else if (!strncmp(lane_swap, "2301", 5))
+   msm_host->dlane_swap = LANE_SWAP_2301;
+   else if (!strncmp(lane_swap, "1230", 5))
+   msm_host->dlane_swap = LANE_SWAP_1230;
+   else if (!strncmp(lane_swap, "0321", 5))
+   msm_host->dlane_swap = LANE_SWAP_0321;
+   else if (!strncmp(lane_swap, "1032", 5))
+   msm_host->dlane_swap = LANE_SWAP_1032;
+   else if (!strncmp(lane_swap, "2103", 5))
+   msm_host->dlane_swap =

Re: [PATCH v2 8/8] regulator: qcom_smd: Handle big endian CPUs

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

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

2015-09-03 Thread Stephen Boyd 
On 09/03, 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.

Ok. That's mildly concerning.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

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

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

2015-09-03 Thread 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 
--
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 5/9] clk: qcom: gcc-msm8960: add child devices support.

2015-09-03 Thread Stephen Boyd 
On 09/02, Rajendra Nayak wrote:
> Stephen,
> 
> >Also, I don't like having a subnode in DT. Why can't we use the
> >same node as the GCC node and create a virtual child device here
> >for tsens? We can assign the same of_node that this platform
> >device has so that DT keeps working correctly.
> >>>
> >>>So the current driver looks up data based on compatible strings.
> >>
> >>The tsens device is always the same piece of hardware. The only
> >
> >Well, not always. The one in 8960 does need additional initializations,
> >requires you to save/restore context as it can be powered off
> >not being in an always powered on domain etc.
> >
> >>thing that's changing is the qfprom data and the number of
> >>sensors. So we should be looking at the qfprom compatible string
> >
> >How? Tsens uses nvmem framework apis to read the qfprom atleast
> >in this series.
> >
> >>to figure out how to interpret the qfprom data which would
> >>include the number of sensors and how the data is encoded.
> >>
> >>>So you suggesting to create a virtual child device for gcc and
> >>>associate the gcc DT node to it? (And have the tsens compatible
> >>>mentioned as part of the gcc DT node?)
> >>
> >>No. The driver should work just fine without having to
> >>interrogate the device's compatible string. If we still need the
> >>compatible check for some reason, then we can always match based
> >>on qcom,gcc-msm8960, qcom,gcc-apq8064, etc. But I don't see why
> >
> >Thats not quite possible I guess. 2 drivers (gcc and tsens) matching
> >the same compatibles? Will it not just depend on which ends up being
> >the first match?
> 
> Any thoughts on how to move forward with this?
> 
> I tried what you were suggesting, and here's what I had to do to get
> things working
> 
> * Created a gcc node in DT with gcc and tsens compatibles, with gcc and
> tsens properties

This is not what I had in mind. This is what's should be in DT

 clock-controller@f000 {
compatible = "qcom,gcc-msm8916";
reg = <0xf000 ...>;

 };

> * gcc driver probes the device/node first given gcc is registered with
> a core_initcall()
> * creates a virtual child device attaching the same of_node (having
> both gcc and tsens compatibles)
> * gcc ends up probing the virtual device/node _again_ (due to the gcc
> compatible match), fails
> * At a later point, tsens driver gets registered (using module_initcall)
> ends up probing the virtual child node and succeeds

Yeah this might happen though because we've assigned the of_node
pointer to the tsens device before we register it on the platform
bus. The other way to pass that data down from gcc to tsens would
be to not have an of_node assigned to the tsens device, and check
for that case in the tsens driver. If there isn't an of_node,
then we look at the parent device's of_node to figure out which
gcc it is (if this even matters) and parse DT properties.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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

2015-09-03 Thread 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 
--
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/6] ARM: dts: ifc6410: Add pwrseq support for WLAN

2015-09-03 Thread Srinivas Kandagatla 



On 25/08/15 22:33, Stephen Boyd wrote:

On 08/18/2015 06:06 AM, Srinivas Kandagatla wrote:

@@ -10,6 +11,20 @@
  serial1 = _serial;
  };
+pwrseq {
+#address-cells = <1>;
+#size-cells = <1>;
+ranges;


Why do we need any of these three properties?


Yep, you are right I will remove it and give it a try.


+compatible = "simple-bus";
+
+sdcc4_pwrseq: sdcc4_pwrseq {
+pinctrl-names = "default";
+pinctrl-0 = <_default_gpios>;
+compatible = "mmc-pwrseq-simple";
+reset-gpios = <_gpio 43 GPIO_ACTIVE_LOW>;


Especially because this node doesn't have a reg property.


--
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] spmi-pmic-arb: support configurable number of peripherals

2015-09-03 Thread Stephen Boyd 
On 09/03, Gilad Avidov wrote:
> +  supported by HW. Default (minimum supported) is 128.
> +
> +Example V1 PMIC-Arbiter:
>  
>   spmi {
>   compatible = "qcom,spmi-pmic-arb";
> @@ -62,4 +66,32 @@ Example:
>  
>   interrupt-controller;
>   #interrupt-cells = <4>;
> +
> + qcom,max-peripherals = <256>;

If it's v1 isn't it always 128? So having 256 here is just
confusing.

> + };
> +
> @@ -129,14 +131,15 @@ struct spmi_pmic_arb_dev {
>   u8  channel;
>   int irq;
>   u8  ee;
> - u8  min_apid;
> - u8  max_apid;
> - u32 mapping_table[SPMI_MAPPING_TABLE_LEN];
> + u16 min_irq_apid;
> + u16 max_irq_apid;
> + u16 max_apid;
> + u32 *mapping_table;
>   struct irq_domain   *domain;
>   struct spmi_controller  *spmic;
> - u16 apid_to_ppid[256];
> + u16 *irq_apid_to_ppid;

Please drop all this renaming noise, or at the least, put it in a
different patch. More than half the patch is just changing the
names of these variables for what seems like no reason.

>   const struct pmic_arb_ver_ops *ver_ops;
> - u8  *ppid_to_chan;
> + u16 *ppid_to_chan;
>  };
>  
>   struct spmi_pmic_arb_dev *pa = irq_get_handler_data(irq);
>   struct irq_chip *chip = irq_get_chip(irq);
>   void __iomem *intr = pa->intr;
> - int first = pa->min_apid >> 5;
> - int last = pa->max_apid >> 5;
> + int first = pa->min_irq_apid >> 5;
> + int last = pa->max_irq_apid >> 5;
>   u32 status;
>   int i, id;
>  
> @@ -903,14 +915,30 @@ static int spmi_pmic_arb_probe(struct platform_device 
> *pdev)
>  
>   pa->ee = ee;
>  
> - for (i = 0; i < ARRAY_SIZE(pa->mapping_table); ++i)
> - pa->mapping_table[i] = readl_relaxed(
> - pa->cnfg + SPMI_MAPPING_TABLE_REG(i));
> + pa->irq_apid_to_ppid = devm_kzalloc(>dev, pa->max_apid *
> + sizeof(*pa->irq_apid_to_ppid),
> + GFP_KERNEL);
> + if (!pa->irq_apid_to_ppid) {
> + err = -ENOMEM;
> + goto err_put_ctrl;
> + }
> +
> + pa->mapping_table = devm_kzalloc(>dev,
> + (pa->max_apid - 1) * sizeof(u32),
> + GFP_KERNEL);
> + if (!pa->mapping_table) {
> + err = -ENOMEM;
> + goto err_put_ctrl;
> + }
> +
> + for (i = 0; i < (pa->max_apid - 1); ++i)
> + pa->mapping_table[i] = readl_relaxed(pa->cnfg +
> +   SPMI_MAPPING_TABLE_REG(i));

Maybe we should stop doing this during probe and always allocate
an empty cache of size 128 on v1 and 512 on v2 chips? So when
we're searching through the mapping table we can cache the value
from the register if the entry isn't 0. This delays the
processing to when we're mapping irqs, hopefully speeding up
probe for the case where you have a handful of irqs to map.

The DT property wouldn't be necessary then. Arguably it's being
added there to optimize the size of the mapping table and isn't
really necessary otherwise.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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] spmi-pmic-arb: support configurable number of peripherals

2015-09-03 Thread Gilad Avidov 
The current driver implementation supports only 128 peripherals.
Adding support for configurable number of peripherals since the
spmi-pmic-arb v2 HW has sub-versions which support from 128 to 512
PMIC peripherals.

Signed-off-by: Gilad Avidov 
Reviewed-by: Sagar Dharia 
---
 .../bindings/spmi/qcom,spmi-pmic-arb.txt   | 34 -
 drivers/spmi/spmi-pmic-arb.c   | 88 ++
 2 files changed, 91 insertions(+), 31 deletions(-)

diff --git a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt 
b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
index e16b9b5..fba7915 100644
--- a/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
+++ b/Documentation/devicetree/bindings/spmi/qcom,spmi-pmic-arb.txt
@@ -42,7 +42,11 @@ Required properties:
 cell 4: interrupt flags indicating level-sense information, as defined in
 dt-bindings/interrupt-controller/irq.h
 
-Example:
+Optional properties:
+- qcom,max-peripherals : number of PMIC peripherals (same as maximum APID)
+supported by HW. Default (minimum supported) is 128.
+
+Example V1 PMIC-Arbiter:
 
spmi {
compatible = "qcom,spmi-pmic-arb";
@@ -62,4 +66,32 @@ Example:
 
interrupt-controller;
#interrupt-cells = <4>;
+
+   qcom,max-peripherals = <256>;
+   };
+
+Example V2 PMIC-Arbiter:
+
+   spmi_bus: qcom,spmi@200f000 {
+   compatible = "qcom,spmi-pmic-arb";
+   reg-names = "core", "chnls", "obsrvr", "intr", "cnfg";
+   reg = <0x200f000 0x1000>,
+   <0x240 0x40>,
+   <0x2c0 0x40>,
+   <0x380 0x20>,
+   <0x200a000 0x2100>;
+
+   interrupt-names = "periph_irq";
+   interrupts = <0 190 0>;
+
+   qcom,ee = <0>;
+   qcom,channel = <0>;
+
+   #address-cells = <2>;
+   #size-cells = <0>;
+
+   interrupt-controller;
+   #interrupt-cells = <4>;
+
+   qcom,max-peripherals = <256>;
};
diff --git a/drivers/spmi/spmi-pmic-arb.c b/drivers/spmi/spmi-pmic-arb.c
index d7119db..ae0f05d 100644
--- a/drivers/spmi/spmi-pmic-arb.c
+++ b/drivers/spmi/spmi-pmic-arb.c
@@ -47,9 +47,8 @@
 #define SPMI_MAPPING_BIT_IS_1_FLAG(X)  (((X) >> 8) & 0x1)
 #define SPMI_MAPPING_BIT_IS_1_RESULT(X)(((X) >> 0) & 0xFF)
 
-#define SPMI_MAPPING_TABLE_LEN 255
 #define SPMI_MAPPING_TABLE_TREE_DEPTH  16  /* Maximum of 16-bits */
-#define PPID_TO_CHAN_TABLE_SZ  BIT(12) /* PPID is 12bit chan is 1byte*/
+#define PMIC_ARB_MAX_PPID  BIT(12) /* PPID is 12bit */
 
 /* Ownership Table */
 #define SPMI_OWNERSHIP_TABLE_REG(N)(0x0700 + (4 * (N)))
@@ -84,9 +83,8 @@ enum pmic_arb_cmd_op_code {
PMIC_ARB_OP_ZERO_WRITE = 16,
 };
 
-/* Maximum number of support PMIC peripherals */
-#define PMIC_ARB_MAX_PERIPHS   256
-#define PMIC_ARB_MAX_CHNL  128
+/* Default (can override in config) max number of support PMIC peripherals */
+#define PMIC_ARB_MAX_APID_DEFAULT  128
 #define PMIC_ARB_PERIPH_ID_VALID   (1 << 15)
 #define PMIC_ARB_TIMEOUT_US100
 #define PMIC_ARB_MAX_TRANS_BYTES   (8)
@@ -110,12 +108,16 @@ struct pmic_arb_ver_ops;
  * @channel:   execution environment channel to use for accesses.
  * @irq:   PMIC ARB interrupt.
  * @ee:the current Execution Environment
- * @min_apid:  minimum APID (used for bounding IRQ search)
- * @max_apid:  maximum APID
+ * @min_irq_apid:  minimum APID with requested IRQ (used for bounding IRQ
+ *  search).
+ * @max_irq_apid:  maximum APID with requested IRQ (used for bounding IRQ
+ *  search).
+ * max_apid:   maximum APID supported by HW.
  * @mapping_table: in-memory copy of PPID -> APID mapping table.
  * @domain:irq domain object for PMIC IRQ domain
  * @spmic: SPMI controller object
- * @apid_to_ppid:  in-memory copy of APID -> PPID mapping table.
+ * @irq_apid_to_ppid:  table which keeps track of APID -> PPID mapping for
+   peripherals which IRQ was requested for.
  * @ver_ops:   version dependent operations.
  * @ppid_to_chan   in-memory copy of PPID -> channel (APID) mapping table.
  * v2 only.
@@ -129,14 +131,15 @@ struct spmi_pmic_arb_dev {
u8  channel;
int irq;
u8  ee;
-   u8  min_apid;
-   u8  max_apid;
-   u32 mapping_table[SPMI_MAPPING_TABLE_LEN];
+   u16 min_irq_apid;
+   u16 max_irq_apid;
+   u16

Re: [PATCH] firmware: qcom: scm: Convert to platform driver

2015-09-03 Thread Stephen Boyd 
On 07/20, Andy Gross wrote:
> This patch creates a platform driver for the SCM so that we can adequately
> manage resources.  This removes clients having to carry the necessary
> clocks to use the SCM resources.
> 
> Signed-off-by: Andy Gross 
> ---

It would be nice if we could use this platform device for doing
the DMAish memory allocations that we do in this driver too. I
guess one complication there is that we would need to allocate
memory with the DMA APIs before CPUs are brought up
(early_initcall level).

> diff --git a/drivers/firmware/qcom_scm.c b/drivers/firmware/qcom_scm.c
> index 45c008d..5dd0514 100644
> --- a/drivers/firmware/qcom_scm.c
> +++ b/drivers/firmware/qcom_scm.c
> @@ -15,14 +15,57 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>   * 02110-1301, USA.
>   */
> -
> +#include 
> +#include 
> +#include 

This include is here twice.

>  #include 
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
[...]
> +
> +/**
> + * qcom_scm_is_available() - Checks if SCM is available
> + */
> +bool qcom_scm_is_available(void)
> +{
> + return !!__scm;
> +}
> +EXPORT_SYMBOL(qcom_scm_is_available);
> +
> +static int qcom_scm_remove(struct platform_device *pdev)
> +{
> + __scm = NULL;
> +
> + return 0;
> +}

Maybe we just shouldn't allow this? The firmware isn't going
anywhere at runtime, and this driver is currently marked as
bool in the Kconfig.

> +
> +static const struct of_device_id qcom_scm_dt_match[] = {
> + { .compatible = "qcom,scm",},
> + {},
> +};
> +
> +MODULE_DEVICE_TABLE(of, qcom_scm_dt_match);
> +
> +static struct platform_driver qcom_scm_driver = {
> + .driver = {
> + .name   = "scm",

Maybe 'qcom_scm' ?

> + .of_match_table = qcom_scm_dt_match,
> + },
> + .probe = qcom_scm_probe,
> + .remove = qcom_scm_remove,
> +};
> +
> +module_platform_driver(qcom_scm_driver);

Isn't there some sort of builtin_platform_driver() macro for
builtin modules?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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