Re: [PATCH v3 7/8] qcom: cpuidle: Add cpuidle driver for QCOM cpus
Hi Lina,
Compilation breaks while I try to compile these driver. Find below the
comments.
On Tuesday 19 August 2014 03:53 AM, Lina Iyer wrote:
Add cpuidle driver interface to allow cpus to go into C-States.
Use the cpuidle DT interfacecommon across ARM architectures to provide
the C-State information to the cpuidle framework.
Signed-off-by: Lina Iyer lina.i...@linaro.org
---
drivers/cpuidle/Kconfig.arm| 7 +++
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/cpuidle-qcom.c | 119
+
3 files changed, 127 insertions(+)
create mode 100644 drivers/cpuidle/cpuidle-qcom.c
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index e339c7f..26e31bd 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -63,3 +63,10 @@ config ARM_MVEBU_V7_CPUIDLE
depends on ARCH_MVEBU
help
Select this to enable cpuidle on Armada 370, 38x and XP processors.
+
+config ARM_QCOM_CPUIDLE
+ bool CPU Idle drivers for Qualcomm processors
+ depends on QCOM_PM
+ select DT_IDLE_STATES
I see no reference to this in any patch? Moreover it was not there in
v2. Anything new that you missed to add?
+ help
+ Select this to enable cpuidle for QCOM processors
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 4d177b9..6c222d5 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARM_ZYNQ_CPUIDLE) +=
cpuidle-zynq.o
obj-$(CONFIG_ARM_U8500_CPUIDLE) += cpuidle-ux500.o
obj-$(CONFIG_ARM_AT91_CPUIDLE) += cpuidle-at91.o
obj-$(CONFIG_ARM_EXYNOS_CPUIDLE)+= cpuidle-exynos.o
+obj-$(CONFIG_ARM_QCOM_CPUIDLE) += cpuidle-qcom.o
###
# MIPS drivers
diff --git a/drivers/cpuidle/cpuidle-qcom.c b/drivers/cpuidle/cpuidle-qcom.c
new file mode 100644
index 000..4aae672
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-qcom.c
@@ -0,0 +1,119 @@
+/* Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014, Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU G./8.patch:226:+eneral Public License
version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/cpuidle.h
+#include linux/cpumask.h
+#include linux/slab.h
+#include linux/of_device.h
+
+#include soc/qcom/pm.h
+#include dt_idle_states.h
Did you miss to commit this file? Compilation fails as this file is nowhere.
+
+static enum msm_pm_sleep_mode modes[CPUIDLE_STATE_MAX];
+
+static int qcom_lpm_enter(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
+{
+ return msm_cpu_pm_enter_sleep(modes[index], true);
+}
+
+static struct cpuidle_driver qcom_cpuidle_driver = {
+ .name = qcom_cpuidle,
+ .owner = THIS_MODULE,
+};
+
+static void parse_state_translations(struct cpuidle_driver *drv)
+{
+ struct device_node *state_node, *cpu_node;
+ const char *mode_name;
+ int i, j;
+
+ struct name_map {
+ enum msm_pm_sleep_mode mode;
+ char *name;
+ };
+ static struct name_map c_states[] = {
+ { MSM_PM_SLEEP_MODE_POWER_COLLAPSE_STANDALONE,
+ standalone-pc },
+ { MSM_PM_SLEEP_MODE_WAIT_FOR_INTERRUPT, wfi },
+ };
+
+ cpu_node = of_cpu_device_node_get(cpumask_first(drv-cpumask));
+ if (!cpu_node)
+ return;
+
+ /**
+ * Get the state description from idle-state node entry-method
+ * First state is always WFI, per spec.
+ */
+ modes[0] = MSM_PM_SLEEP_MODE_WAIT_FOR_INTERRUPT;
+ for (i = 1; i drv-state_count; i++) {
+ mode_name = NULL;
+ state_node = of_parse_phandle(cpu_node, cpu-idle-states, i);
+ of_property_read_string(state_node, entry-method,
+ mode_name);
+ for (j = 0; mode_name (j ARRAY_SIZE(c_states)); j++) {
+ if (!strcmp(mode_name, c_states[j].name)) {
+ modes[i] = c_states[j].mode;
+ break;
+ }
+ }
+ }
+}
+
+static int qcom_cpuidle_init(void)
+{
+ struct cpuidle_driver *drv = qcom_cpuidle_driver;
+ int ret;
+ int i;
+
+ drv-cpumask =
[PATCH v2 1/4] mmc: mmci: Support any block sizes for ux500v2 and qcom variant
From: Ulf Hansson ulf.hans...@linaro.org
For the ux500v2 variant of the PL18x block, any block sizes are
supported. This will make it possible to decrease data overhead
for SDIO transfers.
This patch is based on Ulf Hansson patch
http://www.spinics.net/lists/linux-mmc/msg12160.html
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
enabled this support on qcom variant.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
drivers/mmc/host/mmci.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index c11cb05..3089fba 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -77,6 +77,7 @@ static unsigned int fmax = 515633;
* @qcom_fifo: enables qcom specific fifo pio read logic.
* @reversed_irq_handling: handle data irq before cmd irq.
* @qcom_dml: enables qcom specific dma glue for dma transfers.
+ * @any_blksize: true if block any sizes are supported
*/
struct variant_data {
unsigned intclkreg;
@@ -102,6 +103,7 @@ struct variant_data {
boolqcom_fifo;
boolreversed_irq_handling;
boolqcom_dml;
+ boolany_blksize;
};
static struct variant_data variant_arm = {
@@ -194,6 +196,7 @@ static struct variant_data variant_ux500v2 = {
.pwrreg_clkgate = true,
.busy_detect= true,
.pwrreg_nopower = true,
+ .any_blksize= true,
};
static struct variant_data variant_qcom = {
@@ -212,6 +215,7 @@ static struct variant_data variant_qcom = {
.explicit_mclk_control = true,
.qcom_fifo = true,
.qcom_dml = true,
+ .any_blksize= true,
};
static int mmci_card_busy(struct mmc_host *mmc)
@@ -239,10 +243,11 @@ static int mmci_card_busy(struct mmc_host *mmc)
static int mmci_validate_data(struct mmci_host *host,
struct mmc_data *data)
{
+ struct variant_data *variant = host-variant;
+
if (!data)
return 0;
-
- if (!is_power_of_2(data-blksz)) {
+ if (!is_power_of_2(data-blksz) !variant-any_blksize) {
dev_err(mmc_dev(host-mmc),
unsupported block size (%d bytes)\n, data-blksz);
return -EINVAL;
--
1.9.1
--
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 3/4] mmc: mmci: Add sdio enable mask in variant data
This patch adds sdio enable mask in variant data, SOCs like ST have
special bits in datactrl register to enable sdio. Unconditionally setting
this bit in this driver breaks other SOCs like Qualcomm which maps this
bits to something else, so making this enable bit to come from variant
data solves the issue.
Originally the issue is detected while testing WLAN ath6kl on Qualcomm
APQ8064.
Reviewed-by: Linus Walleij linus.wall...@linaro.org
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
drivers/mmc/host/mmci.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 1c99195..fc08203 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -67,6 +67,7 @@ static unsigned int fmax = 515633;
* @blksz_datactrl16: true if Block size is at b16..b30 position in datactrl
register
* @blksz_datactrl4: true if Block size is at b4..b16 position in datactrl
* register
+ * @datactrl_mask_sdio: SDIO enable mask in datactrl register
* @pwrreg_powerup: power up value for MMCIPOWER register
* @f_max: maximum clk frequency supported by the controller.
* @signal_direction: input/out direction of bus signals can be indicated
@@ -89,6 +90,7 @@ struct variant_data {
unsigned intfifohalfsize;
unsigned intdata_cmd_enable;
unsigned intdatactrl_mask_ddrmode;
+ unsigned intdatactrl_mask_sdio;
boolsdio;
boolst_clkdiv;
boolblksz_datactrl16;
@@ -138,6 +140,7 @@ static struct variant_data variant_u300 = {
.clkreg_enable = MCI_ST_U300_HWFCEN,
.clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS,
.datalength_bits= 16,
+ .datactrl_mask_sdio = MCI_ST_DPSM_SDIOEN,
.sdio = true,
.pwrreg_powerup = MCI_PWR_ON,
.f_max = 1,
@@ -151,6 +154,7 @@ static struct variant_data variant_nomadik = {
.fifohalfsize = 8 * 4,
.clkreg = MCI_CLK_ENABLE,
.datalength_bits= 24,
+ .datactrl_mask_sdio = MCI_ST_DPSM_SDIOEN,
.sdio = true,
.st_clkdiv = true,
.pwrreg_powerup = MCI_PWR_ON,
@@ -168,6 +172,7 @@ static struct variant_data variant_ux500 = {
.clkreg_8bit_bus_enable = MCI_ST_8BIT_BUS,
.clkreg_neg_edge_enable = MCI_ST_UX500_NEG_EDGE,
.datalength_bits= 24,
+ .datactrl_mask_sdio = MCI_ST_DPSM_SDIOEN,
.sdio = true,
.st_clkdiv = true,
.pwrreg_powerup = MCI_PWR_ON,
@@ -187,6 +192,7 @@ static struct variant_data variant_ux500v2 = {
.clkreg_neg_edge_enable = MCI_ST_UX500_NEG_EDGE,
.datactrl_mask_ddrmode = MCI_ST_DPSM_DDRMODE,
.datalength_bits= 24,
+ .datactrl_mask_sdio = MCI_ST_DPSM_SDIOEN,
.sdio = true,
.st_clkdiv = true,
.blksz_datactrl16 = true,
@@ -814,16 +820,10 @@ static void mmci_start_data(struct mmci_host *host,
struct mmc_data *data)
if (data-flags MMC_DATA_READ)
datactrl |= MCI_DPSM_DIRECTION;
- /* The ST Micro variants has a special bit to enable SDIO */
if (variant-sdio host-mmc-card)
if (mmc_card_sdio(host-mmc-card)) {
- /*
-* The ST Micro variants has a special bit
-* to enable SDIO.
-*/
u32 clk;
-
- datactrl |= MCI_ST_DPSM_SDIOEN;
+ datactrl |= variant-datactrl_mask_sdio;
/*
* The ST Micro variant for SDIO small write transfers
--
1.9.1
--
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/4] mmc: mmci: move block size validation under relevant code
This code moves a BUG_ON condition to relevant if block, this check is
not necessary for IPs which can set any arbitrary block size in a given
range.
This patch is necessary for SDIO which sets block sizes that are exactly
not power of 2.
Original issue detected while testing WLAN ath6kl on Qualcomm APQ8064 SOC.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
drivers/mmc/host/mmci.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index 3089fba..1c99195 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -800,15 +800,16 @@ static void mmci_start_data(struct mmci_host *host,
struct mmc_data *data)
writel(timeout, base + MMCIDATATIMER);
writel(host-size, base + MMCIDATALENGTH);
- blksz_bits = ffs(data-blksz) - 1;
- BUG_ON(1 blksz_bits != data-blksz);
- if (variant-blksz_datactrl16)
+ if (variant-blksz_datactrl16) {
datactrl = MCI_DPSM_ENABLE | (data-blksz 16);
- else if (variant-blksz_datactrl4)
+ } else if (variant-blksz_datactrl4) {
datactrl = MCI_DPSM_ENABLE | (data-blksz 4);
- else
+ } else {
+ blksz_bits = ffs(data-blksz) - 1;
+ BUG_ON(1 blksz_bits != data-blksz);
datactrl = MCI_DPSM_ENABLE | blksz_bits 4;
+ }
if (data-flags MMC_DATA_READ)
datactrl |= MCI_DPSM_DIRECTION;
--
1.9.1
--
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] mmc: mmci: sdio related fixes
This patchset fixes few sdio related issues encountered while testing WLAN ath6kl via SDIO on IFC6410 board with Qualcomm APQ8064 SOC. Patch: mmc: mmci: Support any block sizes for ux500v2 and qcom variant is a very old patch by Ulf to support IPs which support any size of block sizes. http://www.spinics.net/lists/linux-mmc/msg12160.html I modified the subject line to include qcom. Patches mmc: mmci: move block size validation under relevant code Moves a BUG check to relevant code path. Both of the patches fixes below issues reported while testing sdio. The issue was ath6kl driver was issuing 12 bytes and 24 bytes reads which are caught as part of the error handing in the driver and resulting in failures. Patch mmc: mmci: Add sdio enable mask in variant data adds extra variant parameter to enable sdio. This makes mmci driver more flexible. Patch mmc: mmci: rename sdio flag in vendor data to st_sdio renames sdio flag in vendor data to st_sdio, as this flag is only used to setup st specific sdio logic. All these patches are tested on IFC6410 board with ath6kl WLAN via SDIO. Thanks to Linus W and Russell for comments on RFC. Changes since RFC: - moved sdio flag to st_sdio to simplify the checks. - use Ulf's patch to address IP's which support anysize blocks. Thanks, srini Srinivas Kandagatla (3): mmc: mmci: move block size validation under relevant code mmc: mmci: Add sdio enable mask in variant data mmc: mmci: rename sdio flag in vendor data to st_sdio Ulf Hansson (1): mmc: mmci: Support any block sizes for ux500v2 and qcom variant drivers/mmc/host/mmci.c | 78 ++--- 1 file changed, 42 insertions(+), 36 deletions(-) -- 1.9.1 -- 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/1] iommu-api: Add map_sg/unmap_sg functions
On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote: If the alignment is not correct then iommu_map() will return error. Not sure what other option we have here (and why make it different behavior than iommu_map which just return error when it is not aligned properly). I don't think we want to force any kind of alignment automatically. I would rather have the API tell me I am doing something wrong than having the function aligning the values and possibly undermap or overmap. But sg-offset is an offset into the page (at least it is used that way in the DMA-API and since you do 'page_len = s-offset + s-length' you use it the same way). So when you pass iova + offset the result will no longer be page-aligned. You should force sg-offset == 0 and sg-length to be page-aligned instead. This makes more sense because the IOMMU-API works on (io)-page granularity and not on arbitrary phys-addr ranges like the DMA-API. Yes, I am aware of that. However, several people prefer this than passing in scatterlist. It is not very convenient to pass a scatterlist in some use cases. Someone mentioned a use case where they would have to create a dummy sg list and populate it with the iova just to do an unmap. I believe we would have to do this also. There is no use for sglist when unmapping. However, would like to keep separate API from iommu_unmap() to keep the API function names symmetric (map_sg/unmap_sg). Keeping it symetric is not more complicated, the caller just needs to keep the sg-list used for mapping around. I prefer the unmap_sg call to work in sg-lists too. I thought that was why we added the default fallback and set all the drivers to point to these fallback functions. Several people wanted this so that we don't have to have NULL-check in these functions (and have the functions be simple inline functions). Okay, since you add these call-backs to all drivers I think I can live with not doing a pointer check here. Joerg -- 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/4] mmc: mmci: move block size validation under relevant code
On 19/08/14 12:55, Ulf Hansson wrote: writel(host-size, base + MMCIDATALENGTH); - blksz_bits = ffs(data-blksz) - 1; - BUG_ON(1 blksz_bits != data-blksz); I don't like this BUG_ON at all, I would prefer if we remove it. The original patch mmc: mmci: Support any block sizes for ux500v2, did so as well. Yes, you are right this is redundant check, mmci_validate_data in mmci_request should catch this error anyway. we can remove this check totally and use your original patch. --srini Now, if we still think removing it is fragile, let additional tests in mmci_validate_data() and return and error code from there. -- 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/4] mmc: mmci: Support any block sizes for ux500v2 and qcom variant
On 19 August 2014 13:14, Srinivas Kandagatla
srinivas.kandaga...@linaro.org wrote:
From: Ulf Hansson ulf.hans...@linaro.org
For the ux500v2 variant of the PL18x block, any block sizes are
supported. This will make it possible to decrease data overhead
for SDIO transfers.
This patch is based on Ulf Hansson patch
http://www.spinics.net/lists/linux-mmc/msg12160.html
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
enabled this support on qcom variant.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
drivers/mmc/host/mmci.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/mmci.c b/drivers/mmc/host/mmci.c
index c11cb05..3089fba 100644
--- a/drivers/mmc/host/mmci.c
+++ b/drivers/mmc/host/mmci.c
@@ -77,6 +77,7 @@ static unsigned int fmax = 515633;
* @qcom_fifo: enables qcom specific fifo pio read logic.
* @reversed_irq_handling: handle data irq before cmd irq.
* @qcom_dml: enables qcom specific dma glue for dma transfers.
+ * @any_blksize: true if block any sizes are supported
*/
struct variant_data {
unsigned intclkreg;
@@ -102,6 +103,7 @@ struct variant_data {
boolqcom_fifo;
boolreversed_irq_handling;
boolqcom_dml;
+ boolany_blksize;
};
static struct variant_data variant_arm = {
@@ -194,6 +196,7 @@ static struct variant_data variant_ux500v2 = {
.pwrreg_clkgate = true,
.busy_detect= true,
.pwrreg_nopower = true,
+ .any_blksize= true,
};
There are some prerequisites of the data buffers to supports any block
size, at least for ux500.
Try read up on this discussion:
http://marc.info/?t=13500506242r=2w=2
The conclusion from the above is that we need to adopt
mmci_pio_write() to handle corner cases.
Now, I suppose, unless someone objects, we could go ahead and merge
this patch. Then you will have to fixup mmci_pio_write() later on.
Kind regards
Uffe
--
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/8] qcom: spm: Add Subsystem Power Manager driver (SAW2)
On Aug 18, 2014, at 5:23 PM, Lina Iyer lina.i...@linaro.org wrote:
SPM is a hardware block that controls the peripheral logic surrounding
the application cores (cpu/l$). When the core executes WFI instruction,
the SPM takes over the putting the core in low power state as
configured. The wake up for the SPM is an interrupt at the GIC, which
then completes the rest of low power mode sequence and brings the core
out of low power mode.
Allow drivers to configure the idle mode for the cores in the SPM start
address register.
What is the ‘start address’?
Can we add anything about ‘start address’ and the sequences in the commit
message?
Signed-off-by: Praveen Chidambaram pchid...@codeaurora.org
Signed-off-by: Lina Iyer lina.i...@linaro.org
---
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/spm.c| 176 ++
drivers/soc/qcom/spm_driver.h | 85
3 files changed, 262 insertions(+)
create mode 100644 drivers/soc/qcom/spm.c
create mode 100644 drivers/soc/qcom/spm_driver.h
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 70d52ed..20b329f 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
+obj-$(CONFIG_QCOM_PM)+= spm.o
CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
obj-$(CONFIG_QCOM_SCM) += scm.o scm-boot.o
We should have the Kconfig that adds QCOM_PM as part of this patch so it actual
is buildable.
diff --git a/drivers/soc/qcom/spm.c b/drivers/soc/qcom/spm.c
new file mode 100644
index 000..3e1de43
--- /dev/null
+++ b/drivers/soc/qcom/spm.c
@@ -0,0 +1,176 @@
+/* Copyright (c) 2011-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/delay.h
+#include linux/init.h
+#include linux/io.h
+#include linux/slab.h
+
+#include spm_driver.h
+
+#define NUM_SPM_ENTRY 32
+
+static uint32_t msm_spm_reg_offsets_saw2_v2_1[MSM_SPM_REG_NR] = {
+ [MSM_SPM_REG_SAW2_SECURE] = 0x00,
+ [MSM_SPM_REG_SAW2_ID] = 0x04,
+ [MSM_SPM_REG_SAW2_CFG] = 0x08,
+ [MSM_SPM_REG_SAW2_SPM_STS] = 0x0C,
+ [MSM_SPM_REG_SAW2_AVS_STS] = 0x10,
+ [MSM_SPM_REG_SAW2_PMIC_STS] = 0x14,
+ [MSM_SPM_REG_SAW2_RST] = 0x18,
+ [MSM_SPM_REG_SAW2_VCTL] = 0x1C,
+ [MSM_SPM_REG_SAW2_AVS_CTL] = 0x20,
+ [MSM_SPM_REG_SAW2_AVS_LIMIT]= 0x24,
+ [MSM_SPM_REG_SAW2_AVS_DLY] = 0x28,
+ [MSM_SPM_REG_SAW2_AVS_HYSTERESIS] = 0x2C,
+ [MSM_SPM_REG_SAW2_SPM_CTL] = 0x30,
+ [MSM_SPM_REG_SAW2_SPM_DLY] = 0x34,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_0] = 0x40,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_1] = 0x44,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_2] = 0x48,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_3] = 0x4C,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_4] = 0x50,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_5] = 0x54,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_6] = 0x58,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_7] = 0x5C,
+ [MSM_SPM_REG_SAW2_SEQ_ENTRY]= 0x80,
+ [MSM_SPM_REG_SAW2_VERSION] = 0xFD0,
+};
Why do we need an array for these offsets, can’t they just be #defines?
+
+static void msm_spm_drv_flush_shadow(struct msm_spm_driver_data *dev,
+ unsigned int reg_index)
+{
+ __raw_writel(dev-reg_shadow[reg_index],
+ dev-reg_base_addr + dev-reg_offsets[reg_index]);
+}
+
+static void msm_spm_drv_load_shadow(struct msm_spm_driver_data *dev,
+ unsigned int reg_index)
+{
+ dev-reg_shadow[reg_index] = __raw_readl(dev-reg_base_addr +
+ dev-reg_offsets[reg_index]);
+}
+
+static inline void msm_spm_drv_set_start_addr(
+ struct msm_spm_driver_data *dev, uint32_t addr)
+{
+ addr = 0x7F;
+ addr = 4;
possibly worth a comment why we are shifting addr
+ dev-reg_shadow[MSM_SPM_REG_SAW2_SPM_CTL] = 0xF80F;
+ dev-reg_shadow[MSM_SPM_REG_SAW2_SPM_CTL] |= addr;
+}
+
+inline int msm_spm_drv_set_spm_enable(
+ struct msm_spm_driver_data *dev, bool enable)
+{
+ uint32_t value = enable ? 0x01 : 0x00;
+
+ if
Re: [PATCH v3 4/8] qcom: spm-devices: Add SPM device manager for the SoC
On Tue, Aug 19, 2014 at 02:59:56PM +0530, Pramod Gurav wrote: Hi Lina, On Tuesday 19 August 2014 03:53 AM, Lina Iyer wrote: + +config QCOM_PM + tristate Qualcomm Power Management This does not compile as a module. making CONFIG_QCOM_PM=m causing redefinition of function 'msm_spm_set_low_power_mode' in header. Good point. Let me make it a bool. I dont see a need for this to be a loadable module. drivers/soc/qcom/spm-devices.c:48:5: error: redefinition of ‘msm_spm_set_low_power_mode’ In file included from drivers/soc/qcom/spm-devices.c:25:0: include/soc/qcom/spm.h:30:19: note: previous definition of ‘msm_spm_set_low_power_mode’ was here + depends on PM ARCH_QCOM OF + help + QCOM Platform specific power driver to manage cores and L2 low power + modes. It interface with various system drivers to put the cores in + low power modes. diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile index 20b329f..9457b2a 100644 --- a/drivers/soc/qcom/Makefile +++ b/drivers/soc/qcom/Makefile @@ -1,4 +1,4 @@ obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o -obj-$(CONFIG_QCOM_PM) += spm.o +obj-$(CONFIG_QCOM_PM) += spm.o spm-devices.o CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1) obj-$(CONFIG_QCOM_SCM) += scm.o scm-boot.o -- 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 7/8] qcom: cpuidle: Add cpuidle driver for QCOM cpus
On Tue, Aug 19, 2014 at 01:11:43PM +0530, Pramod Gurav wrote:
Hi Lina,
Compilation breaks while I try to compile these driver. Find below the
comments.
On Tuesday 19 August 2014 03:53 AM, Lina Iyer wrote:
Add cpuidle driver interface to allow cpus to go into C-States.
Use the cpuidle DT interfacecommon across ARM architectures to provide
the C-State information to the cpuidle framework.
Signed-off-by: Lina Iyer lina.i...@linaro.org
---
drivers/cpuidle/Kconfig.arm| 7 +++
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/cpuidle-qcom.c | 119 +
3 files changed, 127 insertions(+)
create mode 100644 drivers/cpuidle/cpuidle-qcom.c
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index e339c7f..26e31bd 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -63,3 +63,10 @@ config ARM_MVEBU_V7_CPUIDLE
depends on ARCH_MVEBU
help
Select this to enable cpuidle on Armada 370, 38x and XP processors.
+
+config ARM_QCOM_CPUIDLE
+ bool CPU Idle drivers for Qualcomm processors
+ depends on QCOM_PM
+ select DT_IDLE_STATES
I see no reference to this in any patch? Moreover it was not there in
v2. Anything new that you missed to add?
Nope. You need to build this patchset on top of Lorenzo's patches
http://marc.info/?l=linux-pmm=140794514812383w=2
+ help
+ Select this to enable cpuidle for QCOM processors
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 4d177b9..6c222d5 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARM_ZYNQ_CPUIDLE)+=
cpuidle-zynq.o
obj-$(CONFIG_ARM_U8500_CPUIDLE) += cpuidle-ux500.o
obj-$(CONFIG_ARM_AT91_CPUIDLE) += cpuidle-at91.o
obj-$(CONFIG_ARM_EXYNOS_CPUIDLE)+= cpuidle-exynos.o
+obj-$(CONFIG_ARM_QCOM_CPUIDLE) += cpuidle-qcom.o
###
# MIPS drivers
diff --git a/drivers/cpuidle/cpuidle-qcom.c b/drivers/cpuidle/cpuidle-qcom.c
new file mode 100644
index 000..4aae672
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-qcom.c
@@ -0,0 +1,119 @@
+/* Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014, Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU G./8.patch:226:+eneral Public License version
2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/cpuidle.h
+#include linux/cpumask.h
+#include linux/slab.h
+#include linux/of_device.h
+
+#include soc/qcom/pm.h
+#include dt_idle_states.h
Did you miss to commit this file? Compilation fails as this file is nowhere.
See link.
+
+static enum msm_pm_sleep_mode modes[CPUIDLE_STATE_MAX];
+
+static int qcom_lpm_enter(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
+{
+ return msm_cpu_pm_enter_sleep(modes[index], true);
+}
+
+static struct cpuidle_driver qcom_cpuidle_driver = {
+ .name = qcom_cpuidle,
+ .owner = THIS_MODULE,
+};
+
+static void parse_state_translations(struct cpuidle_driver *drv)
+{
+ struct device_node *state_node, *cpu_node;
+ const char *mode_name;
+ int i, j;
+
+ struct name_map {
+ enum msm_pm_sleep_mode mode;
+ char *name;
+ };
+ static struct name_map c_states[] = {
+ { MSM_PM_SLEEP_MODE_POWER_COLLAPSE_STANDALONE,
+ standalone-pc },
+ { MSM_PM_SLEEP_MODE_WAIT_FOR_INTERRUPT, wfi },
+ };
+
+ cpu_node = of_cpu_device_node_get(cpumask_first(drv-cpumask));
+ if (!cpu_node)
+ return;
+
+ /**
+* Get the state description from idle-state node entry-method
+* First state is always WFI, per spec.
+*/
+ modes[0] = MSM_PM_SLEEP_MODE_WAIT_FOR_INTERRUPT;
+ for (i = 1; i drv-state_count; i++) {
+ mode_name = NULL;
+ state_node = of_parse_phandle(cpu_node, cpu-idle-states, i);
+ of_property_read_string(state_node, entry-method,
+ mode_name);
+ for (j = 0; mode_name (j ARRAY_SIZE(c_states)); j++) {
+ if (!strcmp(mode_name, c_states[j].name)) {
+ modes[i] = c_states[j].mode;
+ break;
+ }
+ }
+ }
+}
+
+static int
Re: [PATCH v3 7/8] qcom: cpuidle: Add cpuidle driver for QCOM cpus
On Tuesday 19 August 2014 08:24 PM, Lina Iyer wrote: +config ARM_QCOM_CPUIDLE +bool CPU Idle drivers for Qualcomm processors +depends on QCOM_PM +select DT_IDLE_STATES I see no reference to this in any patch? Moreover it was not there in v2. Anything new that you missed to add? Nope. You need to build this patchset on top of Lorenzo's patches http://marc.info/?l=linux-pmm=140794514812383w=2 Ohh. Sure. Shall take them and test yours. -- 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/8] qcom: spm: Add Subsystem Power Manager driver (SAW2)
On Tue, Aug 19, 2014 at 09:07:51AM -0500, Kumar Gala wrote:
On Aug 18, 2014, at 5:23 PM, Lina Iyer lina.i...@linaro.org wrote:
SPM is a hardware block that controls the peripheral logic surrounding
the application cores (cpu/l$). When the core executes WFI instruction,
the SPM takes over the putting the core in low power state as
configured. The wake up for the SPM is an interrupt at the GIC, which
then completes the rest of low power mode sequence and brings the core
out of low power mode.
Allow drivers to configure the idle mode for the cores in the SPM start
address register.
What is the ‘start address’?
Can we add anything about ‘start address’ and the sequences in the commit
message?
Commit message? The start address is just the register's physical
address.
I can definitely add information about the sequences.
Signed-off-by: Praveen Chidambaram pchid...@codeaurora.org
Signed-off-by: Lina Iyer lina.i...@linaro.org
---
drivers/soc/qcom/Makefile | 1 +
drivers/soc/qcom/spm.c| 176 ++
drivers/soc/qcom/spm_driver.h | 85
3 files changed, 262 insertions(+)
create mode 100644 drivers/soc/qcom/spm.c
create mode 100644 drivers/soc/qcom/spm_driver.h
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 70d52ed..20b329f 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_QCOM_GSBI) += qcom_gsbi.o
+obj-$(CONFIG_QCOM_PM) += spm.o
CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
obj-$(CONFIG_QCOM_SCM) += scm.o scm-boot.o
We should have the Kconfig that adds QCOM_PM as part of this patch so it actual
is buildable.
This patch is not useful at all without the spm-devices.c patch. Hence,
the separate patches.
diff --git a/drivers/soc/qcom/spm.c b/drivers/soc/qcom/spm.c
new file mode 100644
index 000..3e1de43
--- /dev/null
+++ b/drivers/soc/qcom/spm.c
@@ -0,0 +1,176 @@
+/* Copyright (c) 2011-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/delay.h
+#include linux/init.h
+#include linux/io.h
+#include linux/slab.h
+
+#include spm_driver.h
+d
+#define NUM_SPM_ENTRY 32
+
+static uint32_t msm_spm_reg_offsets_saw2_v2_1[MSM_SPM_REG_NR] = {
+ [MSM_SPM_REG_SAW2_SECURE] = 0x00,
+ [MSM_SPM_REG_SAW2_ID] = 0x04,
+ [MSM_SPM_REG_SAW2_CFG] = 0x08,
+ [MSM_SPM_REG_SAW2_SPM_STS] = 0x0C,
+ [MSM_SPM_REG_SAW2_AVS_STS] = 0x10,
+ [MSM_SPM_REG_SAW2_PMIC_STS] = 0x14,
+ [MSM_SPM_REG_SAW2_RST] = 0x18,
+ [MSM_SPM_REG_SAW2_VCTL] = 0x1C,
+ [MSM_SPM_REG_SAW2_AVS_CTL] = 0x20,
+ [MSM_SPM_REG_SAW2_AVS_LIMIT]= 0x24,
+ [MSM_SPM_REG_SAW2_AVS_DLY] = 0x28,
+ [MSM_SPM_REG_SAW2_AVS_HYSTERESIS] = 0x2C,
+ [MSM_SPM_REG_SAW2_SPM_CTL] = 0x30,
+ [MSM_SPM_REG_SAW2_SPM_DLY] = 0x34,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_0] = 0x40,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_1] = 0x44,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_2] = 0x48,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_3] = 0x4C,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_4] = 0x50,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_5] = 0x54,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_6] = 0x58,
+ [MSM_SPM_REG_SAW2_PMIC_DATA_7] = 0x5C,
+ [MSM_SPM_REG_SAW2_SEQ_ENTRY]= 0x80,
+ [MSM_SPM_REG_SAW2_VERSION] = 0xFD0,
+};
Why do we need an array for these offsets, can’t they just be #defines?
They could be, but they could change with each rev of hardware. Any
advantage to the #define other than the memory.
+
+static void msm_spm_drv_flush_shadow(struct msm_spm_driver_data *dev,
+ unsigned int reg_index)
+{
+ __raw_writel(dev-reg_shadow[reg_index],
+ dev-reg_base_addr + dev-reg_offsets[reg_index]);
+}
+
+static void msm_spm_drv_load_shadow(struct msm_spm_driver_data *dev,
+ unsigned int reg_index)
+{
+ dev-reg_shadow[reg_index] = __raw_readl(dev-reg_base_addr +
+ dev-reg_offsets[reg_index]);
+}
+
+static inline void msm_spm_drv_set_start_addr(
+ struct msm_spm_driver_data *dev, uint32_t addr)
+{
+ addr = 0x7F;
+ addr =
Re: [PATCH v3 0/8] QCOM 8074 cpuidle driver
On Mon, Aug 18, 2014 at 04:23:26PM -0600, Lina Iyer wrote:
Changes since v2:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10148.html ]
- Prune all the drivers to support basic WFI and power down cpuidle
functionality. Remove debug code.
- Integrate KConfig changes into the drivers' patches.
- Use Lorenzo's ARM idle-states patches as the basis for reading cpuidle
c-states from DT.
Ref: http://marc.info/?l=linux-pmm=140794514812383w=2
- Incorporate review comments
- Rebase on top of 3.16
Changes since v1/RFC:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10065.html ]
- Remove hotplug from the patch series. Will submit it seprately.
- Fix SPM drivers per the review comments
- Modify patch sequence to compile SPM drivers independent of msm-pm, so as to
allow wfi() calls to use SPM even without SoC interface driver.
8074 like any ARM SoC can do architectural clock gating, that helps save on
power, but not enough of leakage power. Leakage power of the SoC can be
further reduced by turning off power to the core. To aid this, every core (cpu
and L2) is accompanied by a Sub-system Power Manager (SPM), that can be
configured to indicate the low power mode, the core would be put into and the
SPM programs the peripheral h/w accordingly to enter low power and turn off the
power rail to the core.
The idle invocation hierarchy -
CPUIDLE
|
cpuidle-qcom.c [CPUIdle driver]
|
-- msm-pm.c [SoC Interface layer for QCOM chipsets]
|
-- spm-devices.c [SPM devices manager]
| |
| -- spm.c [SPM h/w driver]
|
-- scm-boot.c [SCM interface layer]
|
|--
(EL)Secure Monitor Code
|
|
wfi();
|--
(HW)[CPU] {clock gate}
|
- [SPM] {statemachine}
The patchsets do the following -
- Move scm-boot files from arm/mach-qcom to drivers/soc, following convention.
They are based on Stephen Boyd's series of patches
[http://www.spinics.net/lists/linux-arm-msm/msg10482.html]
- Add new Secure Monitor flags to support warmboot of a quad core system.
- Introduce the SPM driver to control power to the core. The SPM h/w IP works
in conjunction with the Krait CPU/L2. When the core executes WFI instruction,
the core is clockgated and the SPM state machine takes over and powers the core
down. An interrupt from GIC, resumes the SPM state machine which brings the cpu
out of the low power mode.
- Add a SPM device manager to configure multiple SPM devices.
- Add the device tree configuration for each of the SPM nodes. There is one for
each cpu. There is one for each cpu.
- Introduce the SoC driver interface layer to configure SPM per the core's idle
state. To power down the cpu core, the SPM h/w needs to be set up correctly
to power down the core, when the core executes WFI. Linux is expected to call
into Secure Monitor to power down the core. At reset, the core will start in
seure mode and will be returned back to Linux.
- Add CPUIDLE driver for QCOM cpus. The cpuidle driver uses the SoC interface
layer to configure the SPM to allow Krait to be powered down. The cpuidle driver
is based on ARM idle-state framework for cpuidle drivers.
- Provide device configuration for 8074 SoC. Current support is for WFI and
standalone power collapse, which powers only the core independent of the
other cores and caches.
Thanks,
Lina
Lina Iyer (8):
msm: scm: Move scm-boot files to drivers/soc and include/soc
msm: scm: Add SCM warmboot flags for quad core targets.
qcom: spm: Add Subsystem Power Manager driver (SAW2)
qcom: spm-devices: Add SPM device manager for the SoC
arm: dts: qcom: Add SPM device bindings for 8974
qcom: msm-pm: Add cpu low power mode functions
qcom: cpuidle: Add cpuidle driver for QCOM cpus
arm: dts: qcom: Add idle states device nodes for 8974
Documentation/devicetree/bindings/arm/msm/spm.txt | 47
arch/arm/boot/dts/qcom-msm8974-pm.dtsi | 69 ++
arch/arm/boot/dts/qcom-msm8974.dtsi| 24 +-
arch/arm/mach-qcom/Makefile| 1 -
arch/arm/mach-qcom/platsmp.c | 2 +-
drivers/cpuidle/Kconfig.arm| 7 +
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/cpuidle-qcom.c | 119 ++
drivers/soc/qcom/Kconfig | 8 +
drivers/soc/qcom/Makefile | 3 +-
drivers/soc/qcom/msm-pm.c | 117 ++
.../arm/mach-qcom = drivers/soc/qcom}/scm-boot.c | 4 +-
drivers/soc/qcom/spm-devices.c
Re: [PATCH v5 1/1] iommu-api: Add map_sg/unmap_sg functions
On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote: On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote: If the alignment is not correct then iommu_map() will return error. Not sure what other option we have here (and why make it different behavior than iommu_map which just return error when it is not aligned properly). I don't think we want to force any kind of alignment automatically. I would rather have the API tell me I am doing something wrong than having the function aligning the values and possibly undermap or overmap. But sg-offset is an offset into the page (at least it is used that way in the DMA-API and since you do 'page_len = s-offset + s-length' you use it the same way). So when you pass iova + offset the result will no longer be page-aligned. You should force sg-offset == 0 and sg-length to be page-aligned instead. This makes more sense because the IOMMU-API works on (io)-page granularity and not on arbitrary phys-addr ranges like the DMA-API. Yes, I am aware of that. However, several people prefer this than passing in scatterlist. It is not very convenient to pass a scatterlist in some use cases. Someone mentioned a use case where they would have to create a dummy sg list and populate it with the iova just to do an unmap. I believe we would have to do this also. There is no use for sglist when unmapping. However, would like to keep separate API from iommu_unmap() to keep the API function names symmetric (map_sg/unmap_sg). Keeping it symetric is not more complicated, the caller just needs to keep the sg-list used for mapping around. I prefer the unmap_sg call to work in sg-lists too. Do we have a use case where the unmap_sg() implementation would be different than a plain iommu_unmap() call ? If not I'd rather remove unmap_sg() completely. I thought that was why we added the default fallback and set all the drivers to point to these fallback functions. Several people wanted this so that we don't have to have NULL-check in these functions (and have the functions be simple inline functions). Okay, since you add these call-backs to all drivers I think I can live with not doing a pointer check here. I suggested doing a if (ops is not NULL) return ops(); else return default_ops(); to avoid modifying all drivers. I'm not sure why that wasn't received with much enthusiasm. -- Regards, Laurent Pinchart -- 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/RFC V2 07/16] scsi: support well known logical units
On Thu, Aug 14, 2014 at 04:30:58PM +0300, Dolev Raviv wrote:
From: Subhash Jadavani subha...@codeaurora.org
REPORT LUNS command has SELECT REPORT field which controls what type of
logical units to be reported by device server. According to UFS device
standard, if this field is set to 0, REPORT LUNS would report only report
standard logical units. If it's set to 1 then it would report only well
known logical unit and if it's set to 2 then device would report both
standard and well known logical units.
Some well-known logical units might not have scsi upper-layer drivers. In
such cases, the runtime PM reference count increased during device
enumeration will not be decreased, causing the parent device (host) to
always be on even during idle.
This change allows the SCSI LLD (Low Level Driver) to choose which type
of logical units should be detected.
Signed-off-by: Subhash Jadavani subha...@codeaurora.org
Signed-off-by: Sujit Reddy Thumma sthu...@codeaurora.org
Signed-off-by: Dolev Raviv dra...@codeaurora.org
diff --git a/drivers/scsi/scsi_scan.c b/drivers/scsi/scsi_scan.c
index 4a6e4ba..5a0e164 100644
--- a/drivers/scsi/scsi_scan.c
+++ b/drivers/scsi/scsi_scan.c
@@ -802,6 +802,14 @@ static int scsi_add_lun(struct scsi_device *sdev,
unsigned char *inq_result,
} else {
sdev-type = (inq_result[0] 0x1f);
sdev-removable = (inq_result[1] 0x80) 7;
+
+ /*
+ * some devices may respond with wrong type for
+ * well-known logical units. Force well-known type
+ * to enumerate them correctly.
+ */
+ if (scsi_is_wlun(sdev-lun) (sdev-type != TYPE_WLUN))
+ sdev-type = TYPE_WLUN;
no need to test for TYPE_WLUN here.
switch (sdev-type) {
@@ -817,6 +825,7 @@ static int scsi_add_lun(struct scsi_device *sdev,
unsigned char *inq_result,
case TYPE_COMM:
case TYPE_RAID:
case TYPE_OSD:
+ case TYPE_WLUN:
sdev-writeable = 1;
break;
case TYPE_ROM:
This switch statements has been removed in 3.17-rc1, please rebase your
series on top of it. While you're at it please make this patch, which
introduceѕ core scsi changes first in the series.
@@ -1412,6 +1421,13 @@ static int scsi_report_lun_scan(struct scsi_target
*starget, int bflags,
*/
memset(scsi_cmd[1], 0, 5);
+ if (shost-report_wlus)
+ /*
+ * Set SELECT REPORT field to 0x2 which will make device to
+ * report well known logical units along with standard LUs.
+ */
+ scsi_cmd[2] = 0x2;
So we're finally getting well known LUN support. I think we should key this
off the SBC compliance level and not have the drivers opt in.
diff --git a/drivers/scsi/scsi_sysfs.c b/drivers/scsi/scsi_sysfs.c
index 5f36788..ba9d0f0 100644
--- a/drivers/scsi/scsi_sysfs.c
+++ b/drivers/scsi/scsi_sysfs.c
@@ -1060,6 +1060,13 @@ int scsi_sysfs_add_sdev(struct scsi_device *sdev)
}
}
+ /*
+ * put runtime pm reference for well-known logical units,
+ * drivers are expected to _get_* again during probe.
+ */
+ if (scsi_is_wlun(sdev-lun))
+ scsi_autopm_put_device(sdev);
Special casing the well known LUNs here seems wrong. Shouldn't we do this
for any devices that don't get a driver attached to them?
--
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 v1 0/3] pinctrl: qcom: Add APQ8084 pinctrl support
This set of patches adds pinctrl support for the Qualcomm APQ8084 platform. The first patch adds the pin definitions. The second patch contains the devicetree documentation. The last patch adds the DT node. Georgi Djakov (3): pinctrl: qcom: Add APQ8084 pinctrl support dt: Document Qualcomm APQ8084 pinctrl binding ARM: dts: Add TLMM DT node for apq8084 .../bindings/pinctrl/qcom,apq8084-pinctrl.txt | 109 ++ arch/arm/boot/dts/qcom-apq8084.dtsi| 10 + drivers/pinctrl/qcom/Kconfig |8 + drivers/pinctrl/qcom/Makefile |1 + drivers/pinctrl/qcom/pinctrl-apq8084.c | 1302 5 files changed, 1430 insertions(+) create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt create mode 100644 drivers/pinctrl/qcom/pinctrl-apq8084.c -- 1.7.9.5 -- 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 v1 2/3] dt: Document Qualcomm APQ8084 pinctrl binding
Define a new binding for the Qualcomm TLMM (Top-Level Mode Mux) based pin
controller inside the APQ8084.
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
.../bindings/pinctrl/qcom,apq8084-pinctrl.txt | 109
1 file changed, 109 insertions(+)
create mode 100644
Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
new file mode 100644
index 000..fa3ee54
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,apq8084-pinctrl.txt
@@ -0,0 +1,109 @@
+Qualcomm APQ8084 TLMM block
+
+Required properties:
+- compatible: qcom,apq8084-pinctrl
+- reg: Should be the base address and length of the TLMM block.
+- interrupts: Should be the parent IRQ of the TLMM block.
+- interrupt-controller: Marks the device node as an interrupt controller.
+- #interrupt-cells: Should be two.
+- gpio-controller: Marks the device node as a GPIO controller.
+- #gpio-cells : Should be two.
+The first cell is the gpio pin number and the
+second cell is used for optional parameters.
+
+Please refer to ../gpio/gpio.txt and ../interrupt-controller/interrupts.txt for
+a general description of GPIO and interrupt bindings.
+
+Please refer to pinctrl-bindings.txt in this directory for details of the
+common pinctrl bindings used by client devices, including the meaning of the
+phrase pin configuration node.
+
+Qualcomm's pin configuration nodes act as a container for an abitrary number of
+subnodes. Each of these subnodes represents some desired configuration for a
+pin, a group, or a list of pins or groups. This configuration can include the
+mux function to select on those pin(s)/group(s), and various pin configuration
+parameters, such as pull-up, drive strength, etc.
+
+The name of each subnode is not important; all subnodes should be enumerated
+and processed purely based on their content.
+
+Each subnode only affects those parameters that are explicitly listed. In
+other words, a subnode that lists a mux function but no pin configuration
+parameters implies no information about any pin configuration parameters.
+Similarly, a pin subnode that describes a pullup parameter implies no
+information about e.g. the mux function.
+
+
+The following generic properties as defined in pinctrl-bindings.txt are valid
+to specify in a pin configuration subnode:
+
+ pins, function, bias-disable, bias-pull-down, bias-pull-up, drive-strength,
+ output-low, output-high.
+
+Non-empty subnodes must specify the 'pins' property.
+Note that not all properties are valid for all pins.
+
+Valid values for pins are:
+ gpio0-gpio142
+Supports mux, bias and drive-strength
+
+ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data
+Supports bias and drive-strength
+
+Valid values for function are:
+adsp_ext, audio_ref, blsp_i2c1, blsp_i2c2, blsp_i2c3, blsp_i2c4, blsp_i2c5,
+blsp_i2c6, blsp_i2c7, blsp_i2c8, blsp_i2c9, blsp_i2c10, blsp_i2c11, blsp_i2c12,
+blsp_spi1, blsp_spi2, blsp_spi3, blsp_spi4, blsp_spi5, blsp_spi6, blsp_spi7,
+blsp_spi8, blsp_spi9, blsp_spi10, blsp_spi11, blsp_spi12, blsp_uart1,
+blsp_uart2, blsp_uart3, blsp_uart3_rx, blsp_uart3_cts_n, blsp_uart4,
blsp_uart5,
+blsp_uart6, blsp_uart7, blsp_uart8, blsp_uart9, blsp_uart10, blsp_uart11,
+blsp_uart12, blsp_uim1, blsp_uim2, blsp_uim3, blsp_uim4, blsp_uim5, blsp_uim6,
+blsp_uim7, blsp_uim8, blsp_uim9, blsp_uim10, blsp_uim11, blsp_uim12, blsp1_spi,
+blsp3_spi, blsp10_spi, blsp11_i2c, blsp11_uart, cam_mclk0, cam_mclk1,
cam_mclk2,
+cam_mclk3, cci_async, cci_async_in0, cci_i2c, cci_timer0, cci_timer1,
+cci_timer2, cci_timer3, cci_timer4, dll_sdc10, dll_sdc11, dll_sdc20, dll_sdc21,
+edp_hot, edp_tpa, gcc_gp1, gcc_gp1_clk_b, gcc_gp2, gcc_gp2_clk_b, gcc_gp3,
+gcc_gp3_clk_b, gcc_obt, gcc_vtt, gp_mn, gp_pdm, gp_pdm_0a, gp_pdm_2a,
gp_pdm_1b,
+gp_pdm_2b, gp0_clk, gp1_clk, gpio, hdmi_cec, hdmi_ddc, hdmi_dtest, hdmi_hot,
+hdmi_rcv, hsic, ldo_en, ldo_update, mdp_vsync, pci_e0, pci_e0_rst, pci_e1,
+pci_e1_rst, pci_e1_rst_n, pci_e1_clkreq_n, pri_mi2s, qdss_cti,
+qdss_cti_trig_out_a, qdss_cti_trig_in_a, qdss_cti_trig_in_b,
qdss_cti_trig_in_c,
+qdss_cti_trig_out_c, qua_mi2s, sata_act, sata_devsleep, sata_devsleep_n,
+sd_write, sdc3, sdc4, sec_mi2s, slimbus, spdif_tx, spkr_i2s, spkr_i2s_ws,
+spss_geni, ter_mi2s, tsif1, tsif2, uim_batt, uim_clk, uim_data, uim_present,
+uim_reset, gpio
+
+Example:
+
+ tlmm: pinctrl@fd51 {
+ compatible = qcom,apq8084-pinctrl;
+ reg = 0xfd51 0x4000;
+ gpio-controller;
+ #gpio-cells = 2;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ interrupts = 0 208 0;
+
+ pinctrl-names = default;
+ pinctrl-0 = uart2_default;
+
+ uart2_default: uart2_default {
+ mux {
+
[PATCH v1 3/3] ARM: dts: Add TLMM DT node for apq8084
This patch adds the TLMM node for the apq8084 platform.
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index b5b156e..21d01e5 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -185,6 +185,16 @@
reg = 0xfc40 0x4000;
};
+ tlmm: pinctrl@fd51 {
+ compatible = qcom,apq8084-pinctrl;
+ reg = 0xfd51 0x4000;
+ gpio-controller;
+ #gpio-cells = 2;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ interrupts = 0 208 0;
+ };
+
serial@f995e000 {
compatible = qcom,msm-uartdm-v1.4, qcom,msm-uartdm;
reg = 0xf995e000 0x1000;
--
1.7.9.5
--
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 v1 1/3] pinctrl: qcom: Add APQ8084 pinctrl support
This patch adds support for the TLMM (Top-Level Mode Mux) block found
in the APQ8084 platform.
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
drivers/pinctrl/qcom/Kconfig |8 +
drivers/pinctrl/qcom/Makefile |1 +
drivers/pinctrl/qcom/pinctrl-apq8084.c | 1302
3 files changed, 1311 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-apq8084.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index d160a71..81275af 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -15,6 +15,14 @@ config PINCTRL_APQ8064
This is the pinctrl, pinmux, pinconf and gpiolib driver for the
Qualcomm TLMM block found in the Qualcomm APQ8064 platform.
+config PINCTRL_APQ8084
+ tristate Qualcomm APQ8084 pin controller driver
+ depends on GPIOLIB OF
+ select PINCTRL_MSM
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm TLMM block found in the Qualcomm APQ8084 platform.
+
config PINCTRL_IPQ8064
tristate Qualcomm IPQ8064 pin controller driver
depends on GPIOLIB OF
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 2a02602..ba8519f 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -1,6 +1,7 @@
# Qualcomm pin control drivers
obj-$(CONFIG_PINCTRL_MSM) += pinctrl-msm.o
obj-$(CONFIG_PINCTRL_APQ8064) += pinctrl-apq8064.o
+obj-$(CONFIG_PINCTRL_APQ8084) += pinctrl-apq8084.o
obj-$(CONFIG_PINCTRL_IPQ8064) += pinctrl-ipq8064.o
obj-$(CONFIG_PINCTRL_MSM8960) += pinctrl-msm8960.o
obj-$(CONFIG_PINCTRL_MSM8X74) += pinctrl-msm8x74.o
diff --git a/drivers/pinctrl/qcom/pinctrl-apq8084.c
b/drivers/pinctrl/qcom/pinctrl-apq8084.c
new file mode 100644
index 000..bc265f9
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-apq8084.c
@@ -0,0 +1,1302 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pinctrl/pinctrl.h
+
+#include pinctrl-msm.h
+
+static const struct pinctrl_pin_desc apq8084_pins[] = {
+ PINCTRL_PIN(0, GPIO_0),
+ PINCTRL_PIN(1, GPIO_1),
+ PINCTRL_PIN(2, GPIO_2),
+ PINCTRL_PIN(3, GPIO_3),
+ PINCTRL_PIN(4, GPIO_4),
+ PINCTRL_PIN(5, GPIO_5),
+ PINCTRL_PIN(6, GPIO_6),
+ PINCTRL_PIN(7, GPIO_7),
+ PINCTRL_PIN(8, GPIO_8),
+ PINCTRL_PIN(9, GPIO_9),
+ PINCTRL_PIN(10, GPIO_10),
+ PINCTRL_PIN(11, GPIO_11),
+ PINCTRL_PIN(12, GPIO_12),
+ PINCTRL_PIN(13, GPIO_13),
+ PINCTRL_PIN(14, GPIO_14),
+ PINCTRL_PIN(15, GPIO_15),
+ PINCTRL_PIN(16, GPIO_16),
+ PINCTRL_PIN(17, GPIO_17),
+ PINCTRL_PIN(18, GPIO_18),
+ PINCTRL_PIN(19, GPIO_19),
+ PINCTRL_PIN(20, GPIO_20),
+ PINCTRL_PIN(21, GPIO_21),
+ PINCTRL_PIN(22, GPIO_22),
+ PINCTRL_PIN(23, GPIO_23),
+ PINCTRL_PIN(24, GPIO_24),
+ PINCTRL_PIN(25, GPIO_25),
+ PINCTRL_PIN(26, GPIO_26),
+ PINCTRL_PIN(27, GPIO_27),
+ PINCTRL_PIN(28, GPIO_28),
+ PINCTRL_PIN(29, GPIO_29),
+ PINCTRL_PIN(30, GPIO_30),
+ PINCTRL_PIN(31, GPIO_31),
+ PINCTRL_PIN(32, GPIO_32),
+ PINCTRL_PIN(33, GPIO_33),
+ PINCTRL_PIN(34, GPIO_34),
+ PINCTRL_PIN(35, GPIO_35),
+ PINCTRL_PIN(36, GPIO_36),
+ PINCTRL_PIN(37, GPIO_37),
+ PINCTRL_PIN(38, GPIO_38),
+ PINCTRL_PIN(39, GPIO_39),
+ PINCTRL_PIN(40, GPIO_40),
+ PINCTRL_PIN(41, GPIO_41),
+ PINCTRL_PIN(42, GPIO_42),
+ PINCTRL_PIN(43, GPIO_43),
+ PINCTRL_PIN(44, GPIO_44),
+ PINCTRL_PIN(45, GPIO_45),
+ PINCTRL_PIN(46, GPIO_46),
+ PINCTRL_PIN(47, GPIO_47),
+ PINCTRL_PIN(48, GPIO_48),
+ PINCTRL_PIN(49, GPIO_49),
+ PINCTRL_PIN(50, GPIO_50),
+ PINCTRL_PIN(51, GPIO_51),
+ PINCTRL_PIN(52, GPIO_52),
+ PINCTRL_PIN(53, GPIO_53),
+ PINCTRL_PIN(54, GPIO_54),
+ PINCTRL_PIN(55, GPIO_55),
+ PINCTRL_PIN(56, GPIO_56),
+ PINCTRL_PIN(57, GPIO_57),
+ PINCTRL_PIN(58, GPIO_58),
+ PINCTRL_PIN(59, GPIO_59),
+ PINCTRL_PIN(60, GPIO_60),
+ PINCTRL_PIN(61, GPIO_61),
+ PINCTRL_PIN(62, GPIO_62),
+ PINCTRL_PIN(63, GPIO_63),
+ PINCTRL_PIN(64, GPIO_64),
+ PINCTRL_PIN(65, GPIO_65),
+ PINCTRL_PIN(66, GPIO_66),
+ PINCTRL_PIN(67, GPIO_67),
+
Re: [RFC 09/10] scsi: sd: Avoid sending medium write commands if device is write protected
On Mon, Aug 11, 2014 at 5:40 AM, Dolev Raviv dra...@codeaurora.org wrote: From: Sujit Reddy Thumma sthu...@codeaurora.org The SYNCHRONIZE_CACHE command is a medium write command and hence can fail when the device is write protected. Avoid sending such commands by making sure that write-cache-enable is disabled even though the device claim to support it. Signed-off-by: Sujit Reddy Thumma sthu...@codeaurora.org Signed-off-by: Dolev Raviv dra...@codeaurora.org Looks good. Setting SWP is defined to flush caches; there is no other reason I could imagine WP media would need a SYNCHRONIZE CACHE. Reviewed-by: Venkatesh Srinivas venkate...@google.com -- vs; -- 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/1] iommu-api: Add map_sg/unmap_sg functions
On 8/19/2014 4:59 AM, Joerg Roedel wrote: On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote: If the alignment is not correct then iommu_map() will return error. Not sure what other option we have here (and why make it different behavior than iommu_map which just return error when it is not aligned properly). I don't think we want to force any kind of alignment automatically. I would rather have the API tell me I am doing something wrong than having the function aligning the values and possibly undermap or overmap. But sg-offset is an offset into the page (at least it is used that way in the DMA-API and since you do 'page_len = s-offset + s-length' you use it the same way). So when you pass iova + offset the result will no longer be page-aligned. You should force sg-offset == 0 and sg-length to be page-aligned instead. This makes more sense because the IOMMU-API works on (io)-page granularity and not on arbitrary phys-addr ranges like the DMA-API. Ok, but I don't think we want to force a specific alignment here (as I discussed earlier with Will D.). So I would just do something like iommu_map(domain, iova + offset, phys, s-length, prot); offset += s-length; Yes, I am aware of that. However, several people prefer this than passing in scatterlist. It is not very convenient to pass a scatterlist in some use cases. Someone mentioned a use case where they would have to create a dummy sg list and populate it with the iova just to do an unmap. I believe we would have to do this also. There is no use for sglist when unmapping. However, would like to keep separate API from iommu_unmap() to keep the API function names symmetric (map_sg/unmap_sg). Keeping it symetric is not more complicated, the caller just needs to keep the sg-list used for mapping around. I prefer the unmap_sg call to work in sg-lists too. So are you looking for something like this then: int iommu_map_sg(struct iommu_domain *domain, unsigned long iova, struct scatterlist *sg, unsigned int nents, int prot, unsigned long flags) int iommu_unmap_sg(struct iommu_domain *domain, unsigned long iova, struct scatterlist *sg, unsigned int nents, unsigned long flags) This makes unmapping code more complicated (and slow) though. For example the way I would implement the fallback would be to iterate through the sglist first to calculate the total length to unmap and then call iommu_unmap(). I know we talked about removing the flag argument in the map call. However, the TLB_NO_INV usage is actually needed for both map and unmap. We have HW that requires TLB invalidate on MAP and TLB inv. is also required if you implement your mapping function to support replacing an existing mapping... Rob, did you have an issue with this API before or was it just an issue with not having the iova in the unmap call? I thought that was why we added the default fallback and set all the drivers to point to these fallback functions. Several people wanted this so that we don't have to have NULL-check in these functions (and have the functions be simple inline functions). Okay, since you add these call-backs to all drivers I think I can live with not doing a pointer check here. Joerg ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Olav -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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/1] iommu-api: Add map_sg/unmap_sg functions
On 8/19/2014 9:11 AM, Laurent Pinchart wrote: On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote: On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote: If the alignment is not correct then iommu_map() will return error. Not sure what other option we have here (and why make it different behavior than iommu_map which just return error when it is not aligned properly). I don't think we want to force any kind of alignment automatically. I would rather have the API tell me I am doing something wrong than having the function aligning the values and possibly undermap or overmap. But sg-offset is an offset into the page (at least it is used that way in the DMA-API and since you do 'page_len = s-offset + s-length' you use it the same way). So when you pass iova + offset the result will no longer be page-aligned. You should force sg-offset == 0 and sg-length to be page-aligned instead. This makes more sense because the IOMMU-API works on (io)-page granularity and not on arbitrary phys-addr ranges like the DMA-API. Yes, I am aware of that. However, several people prefer this than passing in scatterlist. It is not very convenient to pass a scatterlist in some use cases. Someone mentioned a use case where they would have to create a dummy sg list and populate it with the iova just to do an unmap. I believe we would have to do this also. There is no use for sglist when unmapping. However, would like to keep separate API from iommu_unmap() to keep the API function names symmetric (map_sg/unmap_sg). Keeping it symetric is not more complicated, the caller just needs to keep the sg-list used for mapping around. I prefer the unmap_sg call to work in sg-lists too. Do we have a use case where the unmap_sg() implementation would be different than a plain iommu_unmap() call ? If not I'd rather remove unmap_sg() completely. I thought that was why we added the default fallback and set all the drivers to point to these fallback functions. Several people wanted this so that we don't have to have NULL-check in these functions (and have the functions be simple inline functions). Okay, since you add these call-backs to all drivers I think I can live with not doing a pointer check here. I suggested doing a if (ops is not NULL) return ops(); else return default_ops(); to avoid modifying all drivers. I'm not sure why that wasn't received with much enthusiasm. Both Thierry R. and Konrad W. argued for modifying the drivers instead so I implemented what the majority wanted. :-) Olav -- The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- 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 RESEND] usb: chipidea: msm: Use USB PHY API to control PHY state
On Fri, Aug 15, 2014 at 12:21:19PM +0300, Ivan T. Ivanov wrote:
From: Ivan T. Ivanov iiva...@mm-sol.com
PHY drivers keep track of the current state of the hardware,
so don't change PHY settings under it.
Signed-off-by: Ivan T. Ivanov iiva...@mm-sol.com
looks correct to me from a PHY API perspective, so:
Acked-by: Felipe Balbi ba...@ti.com
However, it doesn't look like msm_phy_init() is equivalent to the lines
removes. Care to comment ?
---
drivers/usb/chipidea/ci_hdrc_msm.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c
b/drivers/usb/chipidea/ci_hdrc_msm.c
index d72b9d2..81de834 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -20,13 +20,11 @@
static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci, unsigned event)
{
struct device *dev = ci-gadget.dev.parent;
- int val;
switch (event) {
case CI_HDRC_CONTROLLER_RESET_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_RESET_EVENT received\n);
- writel(0, USB_AHBBURST);
- writel(0, USB_AHBMODE);
+ usb_phy_init(ci-transceiver);
break;
case CI_HDRC_CONTROLLER_STOPPED_EVENT:
dev_dbg(dev, CI_HDRC_CONTROLLER_STOPPED_EVENT received\n);
@@ -34,10 +32,7 @@ static void ci_hdrc_msm_notify_event(struct ci_hdrc *ci,
unsigned event)
* Put the transceiver in non-driving mode. Otherwise host
* may not detect soft-disconnection.
*/
- val = usb_phy_io_read(ci-transceiver, ULPI_FUNC_CTRL);
- val = ~ULPI_FUNC_CTRL_OPMODE_MASK;
- val |= ULPI_FUNC_CTRL_OPMODE_NONDRIVING;
- usb_phy_io_write(ci-transceiver, val, ULPI_FUNC_CTRL);
+ usb_phy_notify_disconnect(ci-transceiver, USB_SPEED_UNKNOWN);
break;
default:
dev_dbg(dev, unknown ci_hdrc event\n);
--
1.8.3.2
--
balbi
signature.asc
Description: Digital signature
[PATCH] genirq: Introduce irq_read_line()
Introduce the irq_read_line() function to allow device drivers to read
the current logical state of an input when the hardware only exposes
this through status bits in the interrupt controller.
The new function is backed by a new callback function in the irq_chip -
irq_read_line() - that can be implemented by irq_chips that owns such
status bits.
Based on rfc patch from April 2011 by Abhijeet.
Cc: Abhijeet Dharmapurikar adhar...@codeaurora.org
Signed-off-by: Bjorn Andersson bjorn.anders...@sonymobile.com
---
Due to address size limitations in the SSBI protocol used to communicate with
various Qualcomm PMICs most accesses are banked. Furthermore the input/status
bits for the adc, battery monitor, charger, gpio, mpp and usb blocks are all
banked as interrupt status bits.
Therefor to be able to implement any of those drivers we need to make a call
into the pm8xxx irq_chip code to acquire the state of those bits - as my first
hack [1] did.
The patch is based on Abhijeet's RFC found here [2], but my reasons for having
this accessor function is different.
[1] https://lkml.org/lkml/2014/7/7/892
[2] http://lists.infradead.org/pipermail/linux-arm-kernel/2011-April/048277.html
include/linux/interrupt.h |1 +
include/linux/irq.h |2 ++
kernel/irq/manage.c | 25 +
3 files changed, 28 insertions(+)
diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 698ad05..8f3af5d 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -361,6 +361,7 @@ static inline int disable_irq_wake(unsigned int irq)
return irq_set_irq_wake(irq, 0);
}
+extern int irq_read_line(unsigned int irq);
#ifdef CONFIG_IRQ_FORCED_THREADING
extern bool force_irqthreads;
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 0d998d8..f656590 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -294,6 +294,7 @@ static inline irq_hw_number_t irqd_to_hwirq(struct irq_data
*d)
* @irq_retrigger: resend an IRQ to the CPU
* @irq_set_type: set the flow type (IRQ_TYPE_LEVEL/etc.) of an IRQ
* @irq_set_wake: enable/disable power-management wake-on of an IRQ
+ * @irq_read_line: read the logical state of an irq line
* @irq_bus_lock: function to lock access to slow bus (i2c) chips
* @irq_bus_sync_unlock:function to sync and unlock slow bus (i2c) chips
* @irq_cpu_online:configure an interrupt source for a secondary CPU
@@ -326,6 +327,7 @@ struct irq_chip {
int (*irq_retrigger)(struct irq_data *data);
int (*irq_set_type)(struct irq_data *data, unsigned int
flow_type);
int (*irq_set_wake)(struct irq_data *data, unsigned int on);
+ int (*irq_read_line)(struct irq_data *data);
void(*irq_bus_lock)(struct irq_data *data);
void(*irq_bus_sync_unlock)(struct irq_data *data);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 3dc6a61..33bf9c7 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -565,6 +565,31 @@ int irq_set_irq_wake(unsigned int irq, unsigned int on)
}
EXPORT_SYMBOL(irq_set_irq_wake);
+/**
+ * irq_read_line - read the logical state of an irq line
+ * @irq: interrupt to read
+ *
+ * This function may be called from IRQ context only when
+ * desc-chip-bus_lock and desc-chip-bus_sync_unlock are NULL !
+ */
+int irq_read_line(unsigned int irq)
+{
+ struct irq_desc *desc;
+ unsigned long flags;
+ int ret = -ENOSYS;
+
+ desc = irq_get_desc_buslock(irq, flags, IRQ_GET_DESC_CHECK_GLOBAL);
+ if (!desc)
+ return -EINVAL;
+
+ if (desc-irq_data.chip-irq_read_line)
+ ret = desc-irq_data.chip-irq_read_line(desc-irq_data);
+
+ irq_put_desc_busunlock(desc, flags);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(irq_read_line);
+
/*
* Internal function that tells the architecture code whether a
* particular irq has been exclusively allocated or is available
--
1.7.9.5
--
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/1] iommu-api: Add map_sg/unmap_sg functions
On Tuesday 19 August 2014 11:40:24 Olav Haugan wrote: On 8/19/2014 9:11 AM, Laurent Pinchart wrote: On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote: On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote: If the alignment is not correct then iommu_map() will return error. Not sure what other option we have here (and why make it different behavior than iommu_map which just return error when it is not aligned properly). I don't think we want to force any kind of alignment automatically. I would rather have the API tell me I am doing something wrong than having the function aligning the values and possibly undermap or overmap. But sg-offset is an offset into the page (at least it is used that way in the DMA-API and since you do 'page_len = s-offset + s-length' you use it the same way). So when you pass iova + offset the result will no longer be page-aligned. You should force sg-offset == 0 and sg-length to be page-aligned instead. This makes more sense because the IOMMU-API works on (io)-page granularity and not on arbitrary phys-addr ranges like the DMA-API. Yes, I am aware of that. However, several people prefer this than passing in scatterlist. It is not very convenient to pass a scatterlist in some use cases. Someone mentioned a use case where they would have to create a dummy sg list and populate it with the iova just to do an unmap. I believe we would have to do this also. There is no use for sglist when unmapping. However, would like to keep separate API from iommu_unmap() to keep the API function names symmetric (map_sg/unmap_sg). Keeping it symetric is not more complicated, the caller just needs to keep the sg-list used for mapping around. I prefer the unmap_sg call to work in sg-lists too. Do we have a use case where the unmap_sg() implementation would be different than a plain iommu_unmap() call ? If not I'd rather remove unmap_sg() completely. I thought that was why we added the default fallback and set all the drivers to point to these fallback functions. Several people wanted this so that we don't have to have NULL-check in these functions (and have the functions be simple inline functions). Okay, since you add these call-backs to all drivers I think I can live with not doing a pointer check here. I suggested doing a if (ops is not NULL) return ops(); else return default_ops(); to avoid modifying all drivers. I'm not sure why that wasn't received with much enthusiasm. Both Thierry R. and Konrad W. argued for modifying the drivers instead so I implemented what the majority wanted. :-) I'm not blaming you :-) I was just wondering what their rationale was. -- Regards, Laurent Pinchart -- 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 v4 0/8] QCOM 8074 cpuidle driver
Changes since v3:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10288.html ]
- Fix CONFIG_QCOM_PM Kconfig as bool
- More clean ups in spm.c and spm-devices.c
- Removed and re-organized data structures to make initialization simple
- Remove export of sequence flush functions
- Updated commit text
- Comments for use of barriers.
- Rebase on top of 3.17-rc1
Changes since v2:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10148.html ]
- Prune all the drivers to support basic WFI and power down cpuidle
functionality. Remove debug code.
- Integrate KConfig changes into the drivers' patches.
- Use Lorenzo's ARM idle-states patches as the basis for reading cpuidle
c-states from DT.
[ http://marc.info/?l=linux-pmm=140794514812383w=2 ]
- Incorporate review comments
- Rebase on top of 3.16
Changes since v1/RFC:
[ https://www.mail-archive.com/linux-arm-msm@vger.kernel.org/msg10065.html ]
- Remove hotplug from the patch series. Will submit it seprately.
- Fix SPM drivers per the review comments
- Modify patch sequence to compile SPM drivers independent of msm-pm, so as to
allow wfi() calls to use SPM even without SoC interface driver.
8074 like any ARM SoC can do architectural clock gating, that helps save on
power, but not enough of leakage power. Leakage power of the SoC can be
further reduced by turning off power to the core. To aid this, every core (cpu
and L2) is accompanied by a Sub-system Power Manager (SPM), that can be
configured to indicate the low power mode, the core would be put into and the
SPM programs the peripheral h/w accordingly to enter low power and turn off the
power rail to the core.
The idle invocation hierarchy -
CPUIDLE
|
cpuidle-qcom.c [CPUIdle driver]
|
-- msm-pm.c [SoC Interface layer for QCOM chipsets]
|
-- spm-devices.c [SPM devices manager]
| |
| -- spm.c [SPM h/w driver]
|
-- scm-boot.c [SCM interface layer]
|
|--
(EL)Secure Monitor Code
|
|
wfi();
|--
(HW)[CPU] {clock gate}
|
- [SPM] {statemachine}
The patchsets do the following -
- Move scm-boot files from arm/mach-qcom to drivers/soc, following convention.
They are based on Stephen Boyd's series of patches
[http://www.spinics.net/lists/linux-arm-msm/msg10482.html]
- Add new Secure Monitor flags to support warmboot of a quad core system.
- Introduce the SPM driver to control power to the core. The SPM h/w IP works
in conjunction with the Krait CPU/L2. When the core executes WFI instruction,
the core is clockgated and the SPM state machine takes over and powers the core
down. An interrupt from GIC, resumes the SPM state machine which brings the cpu
out of the low power mode.
- Add a SPM device manager to configure multiple SPM devices.
- Add the device tree configuration for each of the SPM nodes. There is one for
each cpu. There is one for each cpu.
- Introduce the SoC driver interface layer to configure SPM per the core's idle
state. To power down the cpu core, the SPM h/w needs to be set up correctly
to power down the core, when the core executes WFI. Linux is expected to call
into Secure Monitor to power down the core. At reset, the core will start in
seure mode and will be returned back to Linux.
- Add CPUIDLE driver for QCOM cpus. The cpuidle driver uses the SoC interface
layer to configure the SPM to allow Krait to be powered down. The cpuidle driver
is based on ARM idle-state framework for cpuidle drivers.
- Provide device configuration for 8074 SoC. Current support is for WFI and
standalone power collapse, which powers only the core independent of the
other cores and caches.
Thanks,
Lina
Lina Iyer (8):
msm: scm: Move scm-boot files to drivers/soc and include/soc
msm: scm: Add SCM warmboot flags for quad core targets.
qcom: spm: Add Subsystem Power Manager driver (SAW2)
qcom: spm-devices: Add SPM device manager for the SoC
arm: dts: qcom: Add SPM device bindings for 8974
qcom: msm-pm: Add cpu low power mode functions
qcom: cpuidle: Add cpuidle driver for QCOM cpus
arm: dts: qcom: Add idle states device nodes for 8974
Documentation/devicetree/bindings/arm/msm/spm.txt | 47 +
arch/arm/boot/dts/qcom-msm8974-pm.dtsi | 69 +++
arch/arm/boot/dts/qcom-msm8974.dtsi| 24 ++-
arch/arm/mach-qcom/Makefile| 1 -
arch/arm/mach-qcom/platsmp.c | 2 +-
drivers/cpuidle/Kconfig.arm| 7 +
drivers/cpuidle/Makefile
[PATCH v4 8/8] arm: dts: qcom: Add idle states device nodes for 8974
Add allowable C-States for each cpu using the cpu-idle-states node.
ARM spec dictates WFI as the default idle state at 0. Support standalone
power collapse (power down that does not affect any SoC idle states) for
each cpu.
Signed-off-by: Lina Iyer lina.i...@linaro.org
---
arch/arm/boot/dts/qcom-msm8974.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 0580bc2..fd66afb 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -21,6 +21,7 @@
reg = 0;
next-level-cache = L2;
qcom,acc = acc0;
+ cpu-idle-states = CPU_SPC;
};
CPU1: cpu@1 {
@@ -30,6 +31,7 @@
reg = 1;
next-level-cache = L2;
qcom,acc = acc1;
+ cpu-idle-states = CPU_SPC;
};
CPU2: cpu@2 {
@@ -39,6 +41,7 @@
reg = 2;
next-level-cache = L2;
qcom,acc = acc2;
+ cpu-idle-states = CPU_SPC;
};
CPU3: cpu@3 {
@@ -48,6 +51,7 @@
reg = 3;
next-level-cache = L2;
qcom,acc = acc3;
+ cpu-idle-states = CPU_SPC;
};
L2: l2-cache {
@@ -55,6 +59,16 @@
cache-level = 2;
qcom,saw = saw_l2;
};
+
+ idle-states {
+ CPU_SPC: cpu-sleep-0 {
+ compatible = arm,idle-state;
+ entry-latency-us = 150;
+ exit-latency-us = 200;
+ min-residency-us = 2000;
+ entry-method = standalone-pc;
+ };
+ };
};
cpu-pmu {
--
1.9.1
--
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 v4 5/8] arm: dts: qcom: Add SPM device bindings for 8974
Add SPM device bindings for QCOM 8974 based cpus. SPM is the sub-system
power manager and controls the logic around the cores (cpu and L2).
Each core has an instance of SPM and controls only that core. Each cpu
SPM is configured to support WFI and SPC (standalone-power collapse) and
L2 can do retention (clock-gating).
Signed-off-by: Praveen Chidambaram pchid...@codeaurora.org
Signed-off-by: Lina Iyer lina.i...@linaro.org
---
arch/arm/boot/dts/qcom-msm8974-pm.dtsi | 69 ++
arch/arm/boot/dts/qcom-msm8974.dtsi| 10 +++--
2 files changed, 75 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/boot/dts/qcom-msm8974-pm.dtsi
diff --git a/arch/arm/boot/dts/qcom-msm8974-pm.dtsi
b/arch/arm/boot/dts/qcom-msm8974-pm.dtsi
new file mode 100644
index 000..bbfb1d5
--- /dev/null
+++ b/arch/arm/boot/dts/qcom-msm8974-pm.dtsi
@@ -0,0 +1,69 @@
+/* Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+soc {
+ spm@f9089000 {
+ compatible = qcom,spm-v2.1;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xf9089000 0x1000;
+ qcom,cpu = CPU0;
+ qcom,saw2-clk-div = 0x01;
+ qcom,saw2-delays = 0x3C102800;
+ qcom,saw2-enable = 0x01;
+ qcom,saw2-spm-cmd-wfi = [03 0b 0f];
+ qcom,saw2-spm-cmd-spc = [00 20 80 10 E8 5B 03 3B E8 5B 82 10 0B
+ 30 06 26 30 0F];
+ };
+
+ spm@f9099000 {
+ compatible = qcom,spm-v2.1;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xf9099000 0x1000;
+ qcom,cpu = CPU1;
+ qcom,saw2-clk-div = 0x01;
+ qcom,saw2-delays = 0x3C102800;
+ qcom,saw2-enable = 0x01;
+ qcom,saw2-spm-cmd-wfi = [03 0b 0f];
+ qcom,saw2-spm-cmd-spc = [00 20 80 10 E8 5B 03 3B E8 5B 82 10 0B
+ 30 06 26 30 0F];
+ };
+
+ spm@f90a9000 {
+ compatible = qcom,spm-v2.1;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xf90a9000 0x1000;
+ qcom,cpu = CPU2;
+ qcom,saw2-clk-div = 0x01;
+ qcom,saw2-delays = 0x3C102800;
+ qcom,saw2-enable = 0x01;
+ qcom,saw2-spm-cmd-wfi = [03 0b 0f];
+ qcom,saw2-spm-cmd-spc = [00 20 80 10 E8 5B 03 3B E8 5B 82 10 0B
+ 30 06 26 30 0F];
+ };
+
+ spm@f90b9000 {
+ compatible = qcom,spm-v2.1;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xf90b9000 0x1000;
+ qcom,cpu = CPU3;
+ qcom,saw2-clk-div = 0x01;
+ qcom,saw2-delays = 0x3C102800;
+ qcom,saw2-enable = 0x01;
+ qcom,saw2-spm-cmd-wfi = [03 0b 0f];
+ qcom,saw2-spm-cmd-spc = [00 20 80 10 E8 5B 03 3B E8 5B 82 10 0B
+ 30 06 26 30 0F];
+ };
+};
diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
b/arch/arm/boot/dts/qcom-msm8974.dtsi
index 69dca2a..0580bc2 100644
--- a/arch/arm/boot/dts/qcom-msm8974.dtsi
+++ b/arch/arm/boot/dts/qcom-msm8974.dtsi
@@ -14,7 +14,7 @@
#size-cells = 0;
interrupts = 1 9 0xf04;
- cpu@0 {
+ CPU0: cpu@0 {
compatible = qcom,krait;
enable-method = qcom,kpss-acc-v2;
device_type = cpu;
@@ -23,7 +23,7 @@
qcom,acc = acc0;
};
- cpu@1 {
+ CPU1: cpu@1 {
compatible = qcom,krait;
enable-method = qcom,kpss-acc-v2;
device_type = cpu;
@@ -32,7 +32,7 @@
qcom,acc = acc1;
};
- cpu@2 {
+ CPU2: cpu@2 {
compatible = qcom,krait;
enable-method = qcom,kpss-acc-v2;
device_type = cpu;
@@ -41,7 +41,7 @@
qcom,acc = acc2;
};
- cpu@3 {
+ CPU3: cpu@3 {
compatible = qcom,krait;
enable-method = qcom,kpss-acc-v2;
device_type = cpu;
@@ -238,3 +238,5 @@
};
};
};
+
+#include qcom-msm8974-pm.dtsi
--
1.9.1
--
[PATCH v4 4/8] qcom: spm-devices: Add SPM device manager for the SoC
Each cpu or an L2$ has an SPM device. They are identical instances of
the same SPM block. This allows for multiple instances be grouped and
managed collectively. spm-devices.c is the SPM device manager managing
multiple SPM devices on top of the driver layer.
Device configuration of each SPM is picked up from the DTS. The hardware
configuration of each of the SPM is handled by the spm.c driver.
Signed-off-by: Praveen Chidamabram pchid...@codeaurora.org
Signed-off-by: Murali Nalajala mnala...@codeaurora.org
Signed-off-by: Lina Iyer lina.i...@linaro.org
---
Documentation/devicetree/bindings/arm/msm/spm.txt | 47 +
drivers/soc/qcom/Kconfig | 8 +
drivers/soc/qcom/Makefile | 2 +-
drivers/soc/qcom/spm-devices.c| 198 ++
include/soc/qcom/spm.h| 34
5 files changed, 288 insertions(+), 1 deletion(-)
create mode 100644 Documentation/devicetree/bindings/arm/msm/spm.txt
create mode 100644 drivers/soc/qcom/spm-devices.c
create mode 100644 include/soc/qcom/spm.h
diff --git a/Documentation/devicetree/bindings/arm/msm/spm.txt
b/Documentation/devicetree/bindings/arm/msm/spm.txt
new file mode 100644
index 000..318e024
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/msm/spm.txt
@@ -0,0 +1,47 @@
+* Subsystem Power Manager (SAW2)
+
+S4 generation of MSMs have SPM hardware blocks to control the Application
+Processor Sub-System power. These SPM blocks run individual state machine
+to determine what the core (L2 or Krait/Scorpion) would do when the WFI
+instruction is executed by the core.
+
+The devicetree representation of the SPM block should be:
+
+Required properties
+
+- compatible: Could be one of -
+ qcom,spm-v2.1
+ qcom,spm-v3.0
+- reg: The physical address and the size of the SPM's memory mapped registers
+- qcom,cpu: phandle for the CPU that the SPM block is attached to.
+ This field is required on only for SPMs that control the CPU.
+- qcom,saw2-cfg: SAW2 configuration register
+- qcom,saw2-spm-dly: Provides the values for the SPM delay command in the SPM
+ sequence
+- qcom,saw2-spm-ctl: The SPM control register
+
+Optional properties
+
+- qcom,saw2-spm-cmd-wfi: The WFI command sequence
+- qcom,saw2-spm-cmd-ret: The Retention command sequence
+- qcom,saw2-spm-cmd-spc: The Standalone PC command sequence
+- qcom,saw2-spm-cmd-pc: The Power Collapse command sequence. This sequence may
+ turn off other SoC components.
+- qcom,saw2-spm-cmd-gdhs: GDHS (Globally Distributed Head Switch) command
+ sequence. This sequence will retain the memory but turn off the logic.
+-
+Example:
+ spm@f9089000 {
+ compatible = qcom,spm-v2.1;
+ #address-cells = 1;
+ #size-cells = 1;
+ reg = 0xf9089000 0x1000;
+ qcom,cpu = CPU0;
+ qcom,saw2-cfg = 0x1;
+ qcom,saw2-spm-dly= 0x2400;
+ qcom,saw2-spm-ctl = 0x1;
+ qcom,saw2-spm-cmd-wfi = [03 0b 0f];
+ qcom,saw2-spm-cmd-spc = [00 20 50 80 60 70 10 92
+ a0 b0 03 68 70 3b 92 a0 b0
+ 82 2b 50 10 30 02 22 30 0f];
+ };
diff --git a/drivers/soc/qcom/Kconfig b/drivers/soc/qcom/Kconfig
index 7dcd554..d467767 100644
--- a/drivers/soc/qcom/Kconfig
+++ b/drivers/soc/qcom/Kconfig
@@ -11,3 +11,11 @@ config QCOM_GSBI
config QCOM_SCM
bool
+
+config QCOM_PM
+ bool Qualcomm Power Management
+ depends on PM ARCH_QCOM OF
+ help
+ QCOM Platform specific power driver to manage cores and L2 low power
+ modes. It interface with various system drivers to put the cores in
+ low power modes.
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 20b329f..9457b2a 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
-obj-$(CONFIG_QCOM_PM) += spm.o
+obj-$(CONFIG_QCOM_PM) += spm.o spm-devices.o
CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
obj-$(CONFIG_QCOM_SCM) += scm.o scm-boot.o
diff --git a/drivers/soc/qcom/spm-devices.c b/drivers/soc/qcom/spm-devices.c
new file mode 100644
index 000..2175a81
--- /dev/null
+++ b/drivers/soc/qcom/spm-devices.c
@@ -0,0 +1,198 @@
+/* Copyright (c) 2011-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include
[PATCH v4 2/8] msm: scm: Add SCM warmboot flags for quad core targets.
Quad core targets like APQ8074, APQ8064, APQ8084 need SCM support set up warm boot addresses in the Secure Monitor. Extend the SCM flags to support warmboot addresses for seconday cores. Signed-off-by: Lina Iyer lina.i...@linaro.org --- include/soc/qcom/scm-boot.h | 2 ++ 1 file changed, 2 insertions(+) diff --git a/include/soc/qcom/scm-boot.h b/include/soc/qcom/scm-boot.h index 6aabb24..02b445c 100644 --- a/include/soc/qcom/scm-boot.h +++ b/include/soc/qcom/scm-boot.h @@ -18,6 +18,8 @@ #define SCM_FLAG_COLDBOOT_CPU3 0x20 #define SCM_FLAG_WARMBOOT_CPU0 0x04 #define SCM_FLAG_WARMBOOT_CPU1 0x02 +#define SCM_FLAG_WARMBOOT_CPU2 0x10 +#define SCM_FLAG_WARMBOOT_CPU3 0x40 int scm_set_boot_addr(phys_addr_t addr, int flags); -- 1.9.1 -- 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 v4 6/8] qcom: msm-pm: Add cpu low power mode functions
Add interface layer to abstract and handle hardware specific
functionality for executing various cpu low power modes in QCOM
chipsets.
Signed-off-by: Venkat Devarasetty vdeva...@codeaurora.org
Signed-off-by: Mahesh Sivasubramanian msiva...@codeaurora.org
Signed-off-by: Lina Iyer lina.i...@linaro.org
---
drivers/soc/qcom/Makefile | 2 +-
drivers/soc/qcom/msm-pm.c | 117 ++
include/soc/qcom/pm.h | 38 +++
3 files changed, 156 insertions(+), 1 deletion(-)
create mode 100644 drivers/soc/qcom/msm-pm.c
create mode 100644 include/soc/qcom/pm.h
diff --git a/drivers/soc/qcom/Makefile b/drivers/soc/qcom/Makefile
index 9457b2a..acdd6fa 100644
--- a/drivers/soc/qcom/Makefile
+++ b/drivers/soc/qcom/Makefile
@@ -1,4 +1,4 @@
obj-$(CONFIG_QCOM_GSBI)+= qcom_gsbi.o
-obj-$(CONFIG_QCOM_PM) += spm.o spm-devices.o
+obj-$(CONFIG_QCOM_PM) += spm.o spm-devices.o msm-pm.o
CFLAGS_scm.o :=$(call as-instr,.arch_extension sec,-DREQUIRES_SEC=1)
obj-$(CONFIG_QCOM_SCM) += scm.o scm-boot.o
diff --git a/drivers/soc/qcom/msm-pm.c b/drivers/soc/qcom/msm-pm.c
new file mode 100644
index 000..5a984e3
--- /dev/null
+++ b/drivers/soc/qcom/msm-pm.c
@@ -0,0 +1,117 @@
+/* Copyright (c) 2010-2014, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/init.h
+#include linux/io.h
+#include linux/smp.h
+#include linux/platform_device.h
+#include linux/cpu_pm.h
+#include linux/uaccess.h
+
+#include soc/qcom/spm.h
+#include soc/qcom/pm.h
+#include soc/qcom/scm.h
+#include soc/qcom/scm-boot.h
+
+#include asm/suspend.h
+#include asm/cacheflush.h
+#include asm/cputype.h
+#include asm/system_misc.h
+
+#define SCM_CMD_TERMINATE_PC (0x2)
+#define SCM_FLUSH_FLAG_MASK(0x3)
+
+static int msm_pm_collapse(unsigned long unused)
+{
+ enum msm_pm_l2_scm_flag flag;
+
+ flag = MSM_SCM_L2_ON SCM_FLUSH_FLAG_MASK;
+ scm_call_atomic1(SCM_SVC_BOOT, SCM_CMD_TERMINATE_PC, flag);
+
+ return 0;
+}
+
+static void set_up_boot_address(void *entry, int cpu)
+{
+ static int flags[NR_CPUS] = {
+ SCM_FLAG_WARMBOOT_CPU0,
+ SCM_FLAG_WARMBOOT_CPU1,
+ SCM_FLAG_WARMBOOT_CPU2,
+ SCM_FLAG_WARMBOOT_CPU3,
+ };
+ static DEFINE_PER_CPU(void *, last_known_entry);
+
+ if (entry == per_cpu(last_known_entry, cpu))
+ return;
+
+ per_cpu(last_known_entry, cpu) = entry;
+ scm_set_boot_addr(virt_to_phys(entry), flags[cpu]);
+}
+
+static int do_power_down(void)
+{
+ int ret;
+
+ cpu_pm_enter();
+
+ msm_spm_set_low_power_mode(MSM_SPM_MODE_POWER_COLLAPSE);
+ set_up_boot_address(cpu_resume, raw_smp_processor_id());
+ ret = cpu_suspend(0, msm_pm_collapse);
+
+ cpu_pm_exit();
+
+ return ret;
+}
+
+static inline int do_idle(void)
+{
+ msm_spm_set_low_power_mode(MSM_SPM_MODE_CLOCK_GATING);
+
+ /* Flush and clock-gate */
+ mb();
+ wfi();
+
+ return 0;
+}
+
+/**
+ * msm_cpu_pm_enter_sleep(): Enter a low power mode on current cpu
+ *
+ * @mode - sleep mode to enter
+ * @from_idle - bool to indicate that the mode is exercised during idle/suspend
+ *
+ * The code should be with interrupts disabled and on the core on which the
+ * low power is to be executed.
+ *
+ */
+int msm_cpu_pm_enter_sleep(enum msm_pm_sleep_mode mode, bool from_idle)
+{
+ int ret;
+
+ switch (mode) {
+ case MSM_PM_SLEEP_MODE_POWER_COLLAPSE_STANDALONE:
+ ret = do_power_down();
+ break;
+ default:
+ case MSM_PM_SLEEP_MODE_WAIT_FOR_INTERRUPT:
+ ret = do_idle();
+ break;
+ }
+
+ local_irq_enable();
+
+ return ret;
+}
+EXPORT_SYMBOL(msm_cpu_pm_enter_sleep);
diff --git a/include/soc/qcom/pm.h b/include/soc/qcom/pm.h
new file mode 100644
index 000..7563e09
--- /dev/null
+++ b/include/soc/qcom/pm.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (c) 2009-2014, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * 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
[PATCH v4 7/8] qcom: cpuidle: Add cpuidle driver for QCOM cpus
Add cpuidle driver interface to allow cpus to go into C-States.
Use the cpuidle DT interfacecommon across ARM architectures to provide
the C-State information to the cpuidle framework.
Signed-off-by: Lina Iyer lina.i...@linaro.org
---
drivers/cpuidle/Kconfig.arm| 7 +++
drivers/cpuidle/Makefile | 1 +
drivers/cpuidle/cpuidle-qcom.c | 119 +
3 files changed, 127 insertions(+)
create mode 100644 drivers/cpuidle/cpuidle-qcom.c
diff --git a/drivers/cpuidle/Kconfig.arm b/drivers/cpuidle/Kconfig.arm
index e339c7f..26e31bd 100644
--- a/drivers/cpuidle/Kconfig.arm
+++ b/drivers/cpuidle/Kconfig.arm
@@ -63,3 +63,10 @@ config ARM_MVEBU_V7_CPUIDLE
depends on ARCH_MVEBU
help
Select this to enable cpuidle on Armada 370, 38x and XP processors.
+
+config ARM_QCOM_CPUIDLE
+ bool CPU Idle drivers for Qualcomm processors
+ depends on QCOM_PM
+ select DT_IDLE_STATES
+ help
+ Select this to enable cpuidle for QCOM processors
diff --git a/drivers/cpuidle/Makefile b/drivers/cpuidle/Makefile
index 4d177b9..6c222d5 100644
--- a/drivers/cpuidle/Makefile
+++ b/drivers/cpuidle/Makefile
@@ -17,6 +17,7 @@ obj-$(CONFIG_ARM_ZYNQ_CPUIDLE)+=
cpuidle-zynq.o
obj-$(CONFIG_ARM_U8500_CPUIDLE) += cpuidle-ux500.o
obj-$(CONFIG_ARM_AT91_CPUIDLE) += cpuidle-at91.o
obj-$(CONFIG_ARM_EXYNOS_CPUIDLE)+= cpuidle-exynos.o
+obj-$(CONFIG_ARM_QCOM_CPUIDLE) += cpuidle-qcom.o
###
# MIPS drivers
diff --git a/drivers/cpuidle/cpuidle-qcom.c b/drivers/cpuidle/cpuidle-qcom.c
new file mode 100644
index 000..4aae672
--- /dev/null
+++ b/drivers/cpuidle/cpuidle-qcom.c
@@ -0,0 +1,119 @@
+/* Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ * Copyright (c) 2014, Linaro Limited.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/of.h
+#include linux/cpuidle.h
+#include linux/cpumask.h
+#include linux/slab.h
+#include linux/of_device.h
+
+#include soc/qcom/pm.h
+#include dt_idle_states.h
+
+static enum msm_pm_sleep_mode modes[CPUIDLE_STATE_MAX];
+
+static int qcom_lpm_enter(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv, int index)
+{
+ return msm_cpu_pm_enter_sleep(modes[index], true);
+}
+
+static struct cpuidle_driver qcom_cpuidle_driver = {
+ .name = qcom_cpuidle,
+ .owner = THIS_MODULE,
+};
+
+static void parse_state_translations(struct cpuidle_driver *drv)
+{
+ struct device_node *state_node, *cpu_node;
+ const char *mode_name;
+ int i, j;
+
+ struct name_map {
+ enum msm_pm_sleep_mode mode;
+ char *name;
+ };
+ static struct name_map c_states[] = {
+ { MSM_PM_SLEEP_MODE_POWER_COLLAPSE_STANDALONE,
+ standalone-pc },
+ { MSM_PM_SLEEP_MODE_WAIT_FOR_INTERRUPT, wfi },
+ };
+
+ cpu_node = of_cpu_device_node_get(cpumask_first(drv-cpumask));
+ if (!cpu_node)
+ return;
+
+ /**
+* Get the state description from idle-state node entry-method
+* First state is always WFI, per spec.
+*/
+ modes[0] = MSM_PM_SLEEP_MODE_WAIT_FOR_INTERRUPT;
+ for (i = 1; i drv-state_count; i++) {
+ mode_name = NULL;
+ state_node = of_parse_phandle(cpu_node, cpu-idle-states, i);
+ of_property_read_string(state_node, entry-method,
+ mode_name);
+ for (j = 0; mode_name (j ARRAY_SIZE(c_states)); j++) {
+ if (!strcmp(mode_name, c_states[j].name)) {
+ modes[i] = c_states[j].mode;
+ break;
+ }
+ }
+ }
+}
+
+static int qcom_cpuidle_init(void)
+{
+ struct cpuidle_driver *drv = qcom_cpuidle_driver;
+ int ret;
+ int i;
+
+ drv-cpumask = kzalloc(cpumask_size(), GFP_KERNEL);
+ if (!drv-cpumask)
+ return -ENOMEM;
+ cpumask_copy(drv-cpumask, cpu_possible_mask);
+
+ /**
+* Default to standard for WFI (index = 0)
+* Probe only for other states
+*/
+ ret = dt_init_idle_driver(drv, 1);
+ if (ret 0) {
+ pr_err(%s: failed to initialize idle states\n, __func__);
+
Re: [PATCH v1 1/3] pinctrl: qcom: Add APQ8084 pinctrl support
On Tue 19 Aug 10:22 PDT 2014, Georgi Djakov wrote: This patch adds support for the TLMM (Top-Level Mode Mux) block found in the APQ8084 platform. [...] + +#define NUM_GPIO_PINGROUPS 143 + I think this looks good overall, but in my APQ8084 documentation (80-NG550-2X Rev. B) there are 147 (0..146) gpio pins in the TLMM block. Any suggestion to why there's a discrepancy? 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 v1 3/3] ARM: dts: Add TLMM DT node for apq8084
On Tue 19 Aug 10:22 PDT 2014, Georgi Djakov wrote:
This patch adds the TLMM node for the apq8084 platform.
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
arch/arm/boot/dts/qcom-apq8084.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff --git a/arch/arm/boot/dts/qcom-apq8084.dtsi
b/arch/arm/boot/dts/qcom-apq8084.dtsi
index b5b156e..21d01e5 100644
--- a/arch/arm/boot/dts/qcom-apq8084.dtsi
+++ b/arch/arm/boot/dts/qcom-apq8084.dtsi
@@ -185,6 +185,16 @@
reg = 0xfc40 0x4000;
};
+ tlmm: pinctrl@fd51 {
+ compatible = qcom,apq8084-pinctrl;
+ reg = 0xfd51 0x4000;
+ gpio-controller;
+ #gpio-cells = 2;
+ interrupt-controller;
+ #interrupt-cells = 2;
+ interrupts = 0 208 0;
+ };
+
serial@f995e000 {
compatible = qcom,msm-uartdm-v1.4, qcom,msm-uartdm;
reg = 0xf995e000 0x1000;
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 v5 1/1] iommu-api: Add map_sg/unmap_sg functions
On Tue, Aug 19, 2014 at 10:52:46PM +0200, Laurent Pinchart wrote: On Tuesday 19 August 2014 11:40:24 Olav Haugan wrote: On 8/19/2014 9:11 AM, Laurent Pinchart wrote: On Tuesday 19 August 2014 13:59:54 Joerg Roedel wrote: On Mon, Aug 18, 2014 at 03:47:56PM -0700, Olav Haugan wrote: If the alignment is not correct then iommu_map() will return error. Not sure what other option we have here (and why make it different behavior than iommu_map which just return error when it is not aligned properly). I don't think we want to force any kind of alignment automatically. I would rather have the API tell me I am doing something wrong than having the function aligning the values and possibly undermap or overmap. But sg-offset is an offset into the page (at least it is used that way in the DMA-API and since you do 'page_len = s-offset + s-length' you use it the same way). So when you pass iova + offset the result will no longer be page-aligned. You should force sg-offset == 0 and sg-length to be page-aligned instead. This makes more sense because the IOMMU-API works on (io)-page granularity and not on arbitrary phys-addr ranges like the DMA-API. Yes, I am aware of that. However, several people prefer this than passing in scatterlist. It is not very convenient to pass a scatterlist in some use cases. Someone mentioned a use case where they would have to create a dummy sg list and populate it with the iova just to do an unmap. I believe we would have to do this also. There is no use for sglist when unmapping. However, would like to keep separate API from iommu_unmap() to keep the API function names symmetric (map_sg/unmap_sg). Keeping it symetric is not more complicated, the caller just needs to keep the sg-list used for mapping around. I prefer the unmap_sg call to work in sg-lists too. Do we have a use case where the unmap_sg() implementation would be different than a plain iommu_unmap() call ? If not I'd rather remove unmap_sg() completely. I thought that was why we added the default fallback and set all the drivers to point to these fallback functions. Several people wanted this so that we don't have to have NULL-check in these functions (and have the functions be simple inline functions). Okay, since you add these call-backs to all drivers I think I can live with not doing a pointer check here. I suggested doing a if (ops is not NULL) return ops(); else return default_ops(); to avoid modifying all drivers. I'm not sure why that wasn't received with much enthusiasm. Both Thierry R. and Konrad W. argued for modifying the drivers instead so I implemented what the majority wanted. :-) I'm not blaming you :-) I was just wondering what their rationale was. In my opinion it's much more direct that way. It means that if a driver doesn't implement it, it won't fall back to some default implementation instead. Providing an explicit helper like this makes it obvious that the driver is using a default implementation rather than making things work magically. It's easier to see in the driver that there's the potential to optimize. It also has the side-effect of keeping the core code cleaner in my opinion, since the core iommu_map_sg() and iommu_unmap_sg() functions can now blindly call into drivers directly rather than performing the various checks to see if they implement the required functionality. Thierry pgpzXUar_vTbg.pgp Description: PGP signature
