[PATCH v7 0/2] mmc: sdhci-msm: Add support for MSM chipsets
This patchset adds basic support of the Secure Digital Host Controller Interface compliant controller found in Qualcomm MSM chipsets. Tested with SD card on APQ8074 Dragonboard. Patchset applies to mmc-next, as it depends on: 4525181 mmc: sdhci: add hooks for platform specific tuning Changes from v6: - Fixed wrong pointer in sdhci_msm_pwr_irq(). - Added platform_execute_tuning() callback as the MSM SDHC does not support tuning as in SDHC 3.0 spec and will need custom implementation in order to support SDR104, HS200 and HS400. - Removed the always-on devicetree property - if the regulator is configured as always-on, it will not be disabled anyway. - Removed devm_pinctrl_get_select_default() - the default pins are already set from the device core. - Removed wrapper function sdhci_msm_set_vdd_io_vol() and enum vdd_io_level and now calling regulator_set_voltage() directly. - Converted #defines to use BIT() macro. - Added IS_ERR(vreg-reg) check at the beginning of sdhci_msm_vreg functions. - Do not print errors when regulators init return -EPROBE_DEFER as the deffered init is not an actual error. - Handle each power irq status bit separately in sdhci_msm_pwr_irq(). - Ensure that any pending power irq is acknowledged before enabling it, otherwise the irq handler will be fired prematurely. - Minor changes. Changes from v5: - Driver is split into multiple patches - Do not initialize variables that are assigned later in code - Remove some useless comments - Use shorter variable names - Change pr_err() to dev_err() - Optimized sdhci_msm_setup_vreg() - Some code alignment fixes - Improved DT values sanity check - Added dev_dbg print for sdhci controller version in probe() - Added usleep_range() after SW reset - it can take some time - Added SDHCI_QUIRK_SINGLE_POWER_WRITE - power handled by PMIC - Renamed DT property vdd-io to vddio Changes from v4: - Simplified sdhci_msm_vreg_disable() and sdhci_msm_set_vdd_io_vol() - Use devm_ioremap_resource() instead of devm_ioremap() - Converted IS_ERR_OR_NULL to IS_ERR - Disable regulators in sdhci_msm_remove() - Check for DT node at the beginning in sdhci_msm_probe() - Removed more redundant code - Changes in some error messages - Minor fixes Changes from v3: - Allocate memory for all required structs at once - Added termination entry in sdhci_msm_dt_match[] - Fixed a missing sdhci_pltfm_free() in probe() - Removed redundant of_match_ptr - Removed the unneeded function sdhci_msm_vreg_reset() Changes from v2: - Added DT bindings for clocks - Moved voltage regulators data to platform data - Removed unneeded includes - Removed obsolete and wrapper functions - Removed error checking where unnecessary - Removed redundant _clk suffix from clock names - Just return instead of goto where possible - Minor fixes Changes from v1: - GPIO references are replaced by pinctrl - DT parsing is done mostly by mmc_of_parse() - Use of_match_device() for DT matching - A few minor changes Georgi Djakov (2): mmc: sdhci-msm: Initial SDHCI MSM driver documentation mmc: sdhci-msm: Initial support for MSM chipsets .../devicetree/bindings/mmc/sdhci-msm.txt | 93 +++ drivers/mmc/host/Kconfig | 13 + drivers/mmc/host/Makefile |1 + drivers/mmc/host/sdhci-msm.c | 655 4 files changed, 762 insertions(+) create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt create mode 100644 drivers/mmc/host/sdhci-msm.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 v7 2/2] mmc: sdhci-msm: Initial support for MSM chipsets
This platform driver adds the initial support of Secure
Digital Host Controller Interface compliant controller
found in Qualcomm MSM chipsets.
Signed-off-by: Georgi Djakov gdja...@mm-sol.com
---
drivers/mmc/host/Kconfig | 13 +
drivers/mmc/host/Makefile|1 +
drivers/mmc/host/sdhci-msm.c | 651 ++
3 files changed, 665 insertions(+)
create mode 100644 drivers/mmc/host/sdhci-msm.c
diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 7fc5099..e8da488 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -322,6 +322,19 @@ config MMC_ATMELMCI
If unsure, say N.
+config MMC_SDHCI_MSM
+ tristate Qualcomm SDHCI Controller Support
+ depends on ARCH_MSM
+ depends on MMC_SDHCI_PLTFM
+ help
+ This selects the Secure Digital Host Controller Interface (SDHCI)
+ support present in MSM SOCs from Qualcomm. The controller
+ supports SD/MMC/SDIO devices.
+
+ If you have a controller with this interface, say Y or M here.
+
+ If unsure, say N.
+
config MMC_MSM
tristate Qualcomm SDCC Controller Support
depends on MMC ARCH_MSM
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index c41d0c3..5faed14 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_MMC_SDHCI_OF_ESDHC) += sdhci-of-esdhc.o
obj-$(CONFIG_MMC_SDHCI_OF_HLWD)+= sdhci-of-hlwd.o
obj-$(CONFIG_MMC_SDHCI_BCM_KONA) += sdhci-bcm-kona.o
obj-$(CONFIG_MMC_SDHCI_BCM2835)+= sdhci-bcm2835.o
+obj-$(CONFIG_MMC_SDHCI_MSM)+= sdhci-msm.o
ifeq ($(CONFIG_CB710_DEBUG),y)
CFLAGS-cb710-mmc+= -DDEBUG
diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
new file mode 100644
index 000..57eba64
--- /dev/null
+++ b/drivers/mmc/host/sdhci-msm.c
@@ -0,0 +1,651 @@
+/*
+ * drivers/mmc/host/sdhci-msm.c - Qualcomm MSM SDHCI Platform
+ * driver source file
+ *
+ * Copyright (c) 2013, The Linux Foundation. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ */
+
+#include linux/module.h
+#include linux/of_device.h
+#include linux/regulator/consumer.h
+#include linux/delay.h
+
+#include sdhci-pltfm.h
+
+#define CORE_HC_MODE 0x78
+#define HC_MODE_EN 0x1
+
+#define CORE_POWER 0x0
+#define CORE_SW_RSTBIT(7)
+
+#define CORE_PWRCTL_STATUS 0xdc
+#define CORE_PWRCTL_MASK 0xe0
+#define CORE_PWRCTL_CLEAR 0xe4
+#define CORE_PWRCTL_CTL0xe8
+
+#define CORE_PWRCTL_BUS_OFFBIT(0)
+#define CORE_PWRCTL_BUS_ON BIT(1)
+#define CORE_PWRCTL_IO_LOW BIT(2)
+#define CORE_PWRCTL_IO_HIGHBIT(3)
+
+#define CORE_PWRCTL_BUS_SUCCESSBIT(0)
+#define CORE_PWRCTL_BUS_FAIL BIT(1)
+#define CORE_PWRCTL_IO_SUCCESS BIT(2)
+#define CORE_PWRCTL_IO_FAILBIT(3)
+
+#define INT_MASK 0xf
+
+
+/* This structure keeps information per regulator */
+struct sdhci_msm_reg_data {
+ struct regulator *reg;
+ const char *name;
+ /* Voltage level values */
+ u32 low_vol_level;
+ u32 high_vol_level;
+ /* Load values for low power and high power mode */
+ u32 lpm_uA;
+ u32 hpm_uA;
+ /* Regulator should be kept in low power mode */
+ bool lpm_sup;
+};
+
+struct sdhci_msm_pltfm_data {
+ u32 caps; /* Supported UHS-I Modes */
+ u32 caps2; /* More capabilities */
+ struct sdhci_msm_reg_data vdd; /* VDD/VCC regulator info */
+ struct sdhci_msm_reg_data vdd_io; /* VDD IO regulator info */
+};
+
+struct sdhci_msm_host {
+ struct platform_device *pdev;
+ void __iomem *core_mem; /* MSM SDCC mapped address */
+ int pwr_irq;/* power irq */
+ struct clk *clk;/* main SD/MMC bus clock */
+ struct clk *pclk; /* SDHC peripheral bus clock */
+ struct clk *bus_clk;/* SDHC bus voter clock */
+ struct sdhci_msm_pltfm_data pdata;
+ struct mmc_host *mmc;
+ struct sdhci_pltfm_data sdhci_msm_pdata;
+};
+
+/* MSM platform specific tuning */
+int sdhci_msm_execute_tuning(struct sdhci_host *host, u32 opcode)
+{
+ return 0;
+}
+
+#define MAX_PROP_SIZE 32
+static int sdhci_msm_dt_parse_vreg_info(struct device *dev,
+ struct sdhci_msm_reg_data *vreg,
+ const char
Re: [PATCH] staging: zsmalloc: Ensure handle is never 0 on success
On Wed, Nov 06, 2013 at 01:09:59PM -0800, Nitin Gupta wrote:
On Tue, Nov 5, 2013 at 5:56 PM, Greg KH gre...@linuxfoundation.org wrote:
On Tue, Nov 05, 2013 at 04:54:12PM -0800, Olav Haugan wrote:
zsmalloc encodes a handle using the page pfn and an object
index. On some hardware platforms the pfn could be 0 and this
causes the encoded handle to be 0 which is interpreted as an
allocation failure.
What platforms specifically have this issue?
To prevent this false error we ensure that the encoded handle
will not be 0 when allocation succeeds.
Change-Id: Ifff930dcf254915b497aec5cb36f152a5e5365d6
What is this? What can anyone do with it?
Signed-off-by: Olav Haugan ohau...@codeaurora.org
---
drivers/staging/zsmalloc/zsmalloc-main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
b/drivers/staging/zsmalloc/zsmalloc-main.c
index 523b937..0e32c0f 100644
--- a/drivers/staging/zsmalloc/zsmalloc-main.c
+++ b/drivers/staging/zsmalloc/zsmalloc-main.c
@@ -441,7 +441,7 @@ static void *obj_location_to_handle(struct page *page,
unsigned long obj_idx)
}
handle = page_to_pfn(page) OBJ_INDEX_BITS;
- handle |= (obj_idx OBJ_INDEX_MASK);
+ handle |= ((obj_idx + 1) OBJ_INDEX_MASK);
return (void *)handle;
}
@@ -451,7 +451,7 @@ static void obj_handle_to_location(unsigned long
handle, struct page **page,
unsigned long *obj_idx)
{
*page = pfn_to_page(handle OBJ_INDEX_BITS);
- *obj_idx = handle OBJ_INDEX_MASK;
+ *obj_idx = (handle OBJ_INDEX_MASK) - 1;
}
I need someone who knows how to test this code to ack it before I can
take it...
And I thought we were deleting zsmalloc anyway, why are you using this
code? Isn't it no longer needed anymore?
zsmalloc is used by zram. Other zstuff has switched to zbud since they
need to do shrinking which is much easier to implement with simpler
design of zbud. For zram, which is a block device, we don't do such
active shrinking, so uses zsmalloc which provides much better density.
Ok, so what's the plan of getting these other things out of staging?
I'm getting really tired of them hanging around in here for many years
now...
Should I just remove them if no one is working on getting them merged
properly?
thanks,
greg k-h
--
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] staging: zsmalloc: Ensure handle is never 0 on success
On Wed, Nov 6, 2013 at 2:10 PM, Greg KH gre...@linuxfoundation.org wrote:
On Wed, Nov 06, 2013 at 01:09:59PM -0800, Nitin Gupta wrote:
On Tue, Nov 5, 2013 at 5:56 PM, Greg KH gre...@linuxfoundation.org wrote:
On Tue, Nov 05, 2013 at 04:54:12PM -0800, Olav Haugan wrote:
zsmalloc encodes a handle using the page pfn and an object
index. On some hardware platforms the pfn could be 0 and this
causes the encoded handle to be 0 which is interpreted as an
allocation failure.
What platforms specifically have this issue?
To prevent this false error we ensure that the encoded handle
will not be 0 when allocation succeeds.
Change-Id: Ifff930dcf254915b497aec5cb36f152a5e5365d6
What is this? What can anyone do with it?
Signed-off-by: Olav Haugan ohau...@codeaurora.org
---
drivers/staging/zsmalloc/zsmalloc-main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c
b/drivers/staging/zsmalloc/zsmalloc-main.c
index 523b937..0e32c0f 100644
--- a/drivers/staging/zsmalloc/zsmalloc-main.c
+++ b/drivers/staging/zsmalloc/zsmalloc-main.c
@@ -441,7 +441,7 @@ static void *obj_location_to_handle(struct page
*page, unsigned long obj_idx)
}
handle = page_to_pfn(page) OBJ_INDEX_BITS;
- handle |= (obj_idx OBJ_INDEX_MASK);
+ handle |= ((obj_idx + 1) OBJ_INDEX_MASK);
return (void *)handle;
}
@@ -451,7 +451,7 @@ static void obj_handle_to_location(unsigned long
handle, struct page **page,
unsigned long *obj_idx)
{
*page = pfn_to_page(handle OBJ_INDEX_BITS);
- *obj_idx = handle OBJ_INDEX_MASK;
+ *obj_idx = (handle OBJ_INDEX_MASK) - 1;
}
I need someone who knows how to test this code to ack it before I can
take it...
And I thought we were deleting zsmalloc anyway, why are you using this
code? Isn't it no longer needed anymore?
zsmalloc is used by zram. Other zstuff has switched to zbud since they
need to do shrinking which is much easier to implement with simpler
design of zbud. For zram, which is a block device, we don't do such
active shrinking, so uses zsmalloc which provides much better density.
Ok, so what's the plan of getting these other things out of staging?
Other zstuff: zswap and zcache
1) zswap (along with zbud allocator, frontcache, cleancache) is
already out of staging into mm/ (by Seth Jennings)
2) zcache seems to have been completely removed (not sure if Dan ever
wants to reintroduce it)
I'm getting really tired of them hanging around in here for many years
now...
Minchan has tried many times to promote zram out of staging. This was
his most recent attempt:
https://lkml.org/lkml/2013/8/21/54
There he provided arguments for zram inclusion, how it can help in
situations where zswap can't and why generalizing /dev/ramX would
not be a great idea. So, cannot say why it wasn't picked up
for inclusion at that time.
Should I just remove them if no one is working on getting them merged
properly?
Please refer the mail thread (link above) and see Minchan's
justifications for zram.
If they don't sound convincing enough then please remove zram+zsmalloc
from staging.
Nitin
--
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] staging: zsmalloc: Ensure handle is never 0 on success
On 11/6/2013 12:56 PM, Nitin Gupta wrote: On Tue, Nov 5, 2013 at 5:17 PM, David Cohen david.a.co...@linux.intel.com wrote: Hi Olav, On 11/05/2013 04:54 PM, Olav Haugan wrote: zsmalloc encodes a handle using the page pfn and an object index. On some hardware platforms the pfn could be 0 and this causes the encoded handle to be 0 which is interpreted as an allocation failure. To prevent this false error we ensure that the encoded handle will not be 0 when allocation succeeds. Change-Id: Ifff930dcf254915b497aec5cb36f152a5e5365d6 Signed-off-by: Olav Haugan ohau...@codeaurora.org --- drivers/staging/zsmalloc/zsmalloc-main.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/zsmalloc/zsmalloc-main.c b/drivers/staging/zsmalloc/zsmalloc-main.c index 523b937..0e32c0f 100644 --- a/drivers/staging/zsmalloc/zsmalloc-main.c +++ b/drivers/staging/zsmalloc/zsmalloc-main.c @@ -441,7 +441,7 @@ static void *obj_location_to_handle(struct page *page, unsigned long obj_idx) } handle = page_to_pfn(page) OBJ_INDEX_BITS; - handle |= (obj_idx OBJ_INDEX_MASK); + handle |= ((obj_idx + 1) OBJ_INDEX_MASK); As suggestion you could use a macro instead of hardcoded 1. I am not familiar with this code, but if it's a valid test to verify if the resulting address is page aligned, you might want to set this offset macro to a page aligned value as well. Using a hardcoded 1 looks fine in this case. But the patch description should also be added as a comment for this function. Otherwise, the patch looks good to me. Sure, I can add a comment above obj_location_to_handle() and obj_handle_to_location(). Olav Haugan -- 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] staging: zsmalloc: Ensure handle is never 0 on success
On 11/5/2013 5:56 PM, Greg KH wrote: On Tue, Nov 05, 2013 at 04:54:12PM -0800, Olav Haugan wrote: zsmalloc encodes a handle using the page pfn and an object index. On some hardware platforms the pfn could be 0 and this causes the encoded handle to be 0 which is interpreted as an allocation failure. What platforms specifically have this issue? Currently some of Qualcomm SoC's have physical memory that starts at address 0x0 which causes this problem. I believe this could be a problem on any platforms if memory is configured to be starting at physical address 0x0 for these platforms. To prevent this false error we ensure that the encoded handle will not be 0 when allocation succeeds. Change-Id: Ifff930dcf254915b497aec5cb36f152a5e5365d6 What is this? What can anyone do with it? This is an identifier used by Gerrit Code Review to track changes to the same patch. I will remove it. Olav Haugan -- 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 05/11] ARM: Introduce CPU_METHOD_OF_DECLARE() for cpu hotplug/smp
Hey Stephen-
Nit/suggestion below:
On Fri, Nov 01, 2013 at 03:08:53PM -0700, Stephen Boyd wrote:
[..]
diff --git a/arch/arm/include/asm/smp.h b/arch/arm/include/asm/smp.h
index a8cae71c..c27ec55 100644
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -112,6 +112,15 @@ struct smp_operations {
#endif
};
+struct of_cpu_method {
+ const char *method;
+ struct smp_operations *ops;
+};
+
+#define CPU_METHOD_OF_DECLARE(name, _method, _ops) \
+ static const struct of_cpu_method __cpu_method_of_table_##name \
+ __used __section(__cpu_method_of_table) \
+ = { .method = _method, .ops = _ops }
/*
* set platform specific SMP operations
*/
diff --git a/arch/arm/kernel/devtree.c b/arch/arm/kernel/devtree.c
index f35906b..71a8592 100644
--- a/arch/arm/kernel/devtree.c
+++ b/arch/arm/kernel/devtree.c
@@ -25,6 +25,7 @@
#include asm/smp_plat.h
#include asm/mach/arch.h
#include asm/mach-types.h
+#include asm/smp.h
void __init early_init_dt_add_memory_arch(u64 base, u64 size)
{
@@ -63,6 +64,36 @@ void __init arm_dt_memblock_reserve(void)
}
}
+#ifdef CONFIG_SMP
+extern struct of_cpu_method __cpu_method_of_table[];
+
+static const struct of_cpu_method __cpu_method_of_table_sentinel
+ __used __section(__cpu_method_of_table_end);
Having a sentinel allocated into the linked image makes a lot of sense
in other cases (IRQCHIP/CLOCKSOURCE_OF_DECLARE, etc), where it's used to
terminate an of_device_id table (as is expected by of_match_table and
friends).
In this case, however, you aren't building a match table, so having a
sentinel allocated isn't necessary. I'd suggest bookending the table
with a VMLINUX_SYMBOL(__cpu_method_of_table_end) instead.
A whole 2 pointers worth of savings!
--
The Qualcomm Innovation Center, Inc. is a member of the 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] staging: zsmalloc: Ensure handle is never 0 on success
On Wed, Nov 06, 2013 at 03:46:19PM -0800, Nitin Gupta wrote: I'm getting really tired of them hanging around in here for many years now... Minchan has tried many times to promote zram out of staging. This was his most recent attempt: https://lkml.org/lkml/2013/8/21/54 There he provided arguments for zram inclusion, how it can help in situations where zswap can't and why generalizing /dev/ramX would not be a great idea. So, cannot say why it wasn't picked up for inclusion at that time. Should I just remove them if no one is working on getting them merged properly? Please refer the mail thread (link above) and see Minchan's justifications for zram. If they don't sound convincing enough then please remove zram+zsmalloc from staging. You don't need to be convincing me, you need to be convincing the maintainers of the area of the kernel you are working with. And since the last time you all tried to get this merged was back in August, I'm feeling that you all have given up, so it needs to be deleted. I'll go do that for 3.14, and if someone wants to pick it up and merge it properly, they can easily revert it. thanks, greg k-h -- 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] staging: zsmalloc: Ensure handle is never 0 on success
On Wed, Nov 06, 2013 at 04:00:02PM -0800, Olav Haugan wrote: On 11/5/2013 5:56 PM, Greg KH wrote: On Tue, Nov 05, 2013 at 04:54:12PM -0800, Olav Haugan wrote: zsmalloc encodes a handle using the page pfn and an object index. On some hardware platforms the pfn could be 0 and this causes the encoded handle to be 0 which is interpreted as an allocation failure. What platforms specifically have this issue? Currently some of Qualcomm SoC's have physical memory that starts at address 0x0 which causes this problem. Then say this, and list the exact SoC's that can have this problem so people know how to evaluate the bugfix and see if it is relevant for their systems. I believe this could be a problem on any platforms if memory is configured to be starting at physical address 0x0 for these platforms. Have you seen this be a problem? So it's just a theoretical issue at this point in time? To prevent this false error we ensure that the encoded handle will not be 0 when allocation succeeds. Change-Id: Ifff930dcf254915b497aec5cb36f152a5e5365d6 What is this? What can anyone do with it? This is an identifier used by Gerrit Code Review to track changes to the same patch. I will remove it. Please do so, it has no place in kernel patches submitted for acceptance. Please fix up the changelog, and the rest based on the other comments and resend. thanks, greg k-h -- 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
