[PATCH 1/2] mmc: core: Separate the timeout value for cache-ctrl
Turning the cache off implies flushing cache which doesn't define
maximum timeout unlike cache-on. This patch will apply the generic
CMD6 timeout only for cache-on. Additionally the kernel message is
added for checking failure case of cache-on.
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
drivers/mmc/core/core.c | 22 +-
drivers/mmc/core/mmc.c | 12 ++--
2 files changed, 23 insertions(+), 11 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 271efea..481b090 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2270,6 +2270,7 @@ EXPORT_SYMBOL(mmc_flush_cache);
int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
{
struct mmc_card *card = host-card;
+ unsigned int timeout;
int err = 0;
if (!(host-caps2 MMC_CAP2_CACHE_CTRL) ||
@@ -2280,16 +2281,19 @@ int mmc_cache_ctrl(struct mmc_host *host, u8 enable)
(card-ext_csd.cache_size 0)) {
enable = !!enable;
- if (card-ext_csd.cache_ctrl ^ enable)
+ if (card-ext_csd.cache_ctrl ^ enable) {
+ timeout = enable ? card-ext_csd.generic_cmd6_time : 0;
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_CACHE_CTRL, enable, 0);
- if (err)
- pr_err(%s: cache %s error %d\n,
- mmc_hostname(card-host),
- enable ? on : off,
- err);
- else
- card-ext_csd.cache_ctrl = enable;
+ EXT_CSD_CACHE_CTRL, enable, timeout);
+
+ if (err)
+ pr_err(%s: cache %s error %d\n,
+ mmc_hostname(card-host),
+ enable ? on : off,
+ err);
+ else
+ card-ext_csd.cache_ctrl = enable;
+ }
}
return err;
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index a1223bd..1e1dda9 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -1066,14 +1066,22 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
if ((host-caps2 MMC_CAP2_CACHE_CTRL)
card-ext_csd.cache_size 0) {
err = mmc_switch(card, EXT_CSD_CMD_SET_NORMAL,
- EXT_CSD_CACHE_CTRL, 1, 0);
+ EXT_CSD_CACHE_CTRL, 1,
+ card-ext_csd.generic_cmd6_time);
if (err err != -EBADMSG)
goto free_card;
/*
* Only if no error, cache is turned on successfully.
*/
- card-ext_csd.cache_ctrl = err ? 0 : 1;
+ if (err) {
+ pr_warning(%s: Cache is supported,
+ but failed to turn on (%d)\n,
+ mmc_hostname(card-host), err);
+ err = 0;
+ } else {
+ card-ext_csd.cache_ctrl = 1;
+ }
}
if (!oldcard)
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] mmc: core: Add claiming a host during mmc_cache_ctrl
While calling mmc_cache_ctrl() a host is not claimed. This patch
adds the mmc_try_claim_host() for quick response in suspend.
Signed-off-by: Seungwon Jeon tgih@samsung.com
---
drivers/mmc/core/core.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 481b090..703ff11 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2314,7 +2314,13 @@ int mmc_suspend_host(struct mmc_host *host)
cancel_delayed_work(host-disable);
cancel_delayed_work(host-detect);
mmc_flush_scheduled_work();
- err = mmc_cache_ctrl(host, 0);
+ if (mmc_try_claim_host(host)) {
+ err = mmc_cache_ctrl(host, 0);
+ mmc_do_release_host(host);
+ } else {
+ err = -EBUSY;
+ }
+
if (err)
goto out;
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren t...@atomide.com wrote: Note that with device tree things get simpler for muxing as we can get rid of the hardcoded grouping of pins in mux drivers. Instead of hardcoded pingroups, the groups can be created dynamically based on what the driver DT entries have. Yes, I know too little about DT to figure out how these should come in. The reason why we want to avoid hardcoded pin groups is because trying to map all the pad combinations in the pinmux driver is not a scalable way to go. And it's not even possible at least on omaps because of the huge number of combinations with alternative pins and multiple packages. Yes, that's a solid case! FYI I'm playing with a DT based pinmux-simple.c driver that should be pretty generic and work for all kinds of hardware hopefully. I love it. It will be few days before I can post anything though, there are some pinctrl fwk issues to deal with first. Like the hardcoded pinmux_maps that assumes that dev entries are static. This means that multiple instances of pinmux drivers won't work.. I'm not following, but I guess I will understand when I see the patches. The idea behind the current map concept is that you get either a string or struct device * to identify the pin controller and mapped device, that's as far as I thought it out, sorry for any inherent limitations, they're not intentional... Thanks, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
On Wed, Nov 23, 2011 at 1:28 AM, Stephen Warren swar...@nvidia.com wrote: Describing the HW doesn't necessarily mean that each device needs to describe what pinmux pins it uses; one could quite easily have the pinmux describe what settings the various pins should have and which drivers will use those pins. That would map very well to the pinctrl subsystem's mapping table, and at least Tegra's existing pinmux tables, which are both just a big array of settings which end up getting provided to drivers. That sounds true. It's also something that is cleanly cut out as a very well defined and abstract piece of hardware information to live in the device tree and which would be useful for any OS using DT. I'd have to see the device trees and corresponding map bindings before I understand it fully though. Just my €0.01 Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Trying 3.2.0-rc1 with brcmfmac (BCM4329) fails
Hi! I'm trying to get the Exynos 4210 to work with the BCM4329 wifi module, using SDIO, and with the Android kernel for the Exynos, this works nicely, but with the current kernel (3.2.0-rc1) it doesn't. After debugging (together with some devs. from Broadcom) it has been narrowed down to: [ 267.175000] brcmf_sdioh_request_word: rw=1, func=1, addr=0x0bf98, nbytes=4 [ 267.175000] mmc1: starting CMD53 arg 957f3004 flags 01b5 [ 267.175000] mmc1: blksz 4 blocks 1 flags 0100 tsac 1000 ms nsac 0 [ 267.175000] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00208003 [ 267.175000] before mmc_request_done [ 267.175000] mmc1: req done (CMD53): 0: 1000 [ 267.175000] mmc1: 0 bytes transferred: -84 [ 267.175000] after mmc_request_done The interrupt above is really weird because it is masked as both a command and data. Summary is as follows: * 3.2.0-rc1; CMD52 read/write and CMD53 read works. CMD53 write fails * 2.6.35.7(android): CMD52 read/write and CMD53 read/write works. Since the brcmfmac driver doesn't exist in the android-kernel, I tried the bcmdhd-driver from the ICS-kernel (after talking to Broadcom devs), and it is the same. It seems like the error is in something else than the wifi-driver, and I'm out of ideas, so any help at all would be appreciated. In advance, thanks! -- Thomas -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
Hi, * Linus Walleij linus.wall...@linaro.org [24 01:29]: On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren t...@atomide.com wrote: Note that with device tree things get simpler for muxing as we can get rid of the hardcoded grouping of pins in mux drivers. Instead of hardcoded pingroups, the groups can be created dynamically based on what the driver DT entries have. Yes, I know too little about DT to figure out how these should come in. The reason why we want to avoid hardcoded pin groups is because trying to map all the pad combinations in the pinmux driver is not a scalable way to go. And it's not even possible at least on omaps because of the huge number of combinations with alternative pins and multiple packages. Yes, that's a solid case! So far it seems that device tree simplifies things here quite a bit in at least two ways: - We by default have automatically generated 1:1 mapping of devices to groups (of course others can be added too) - We should be able to support new SoC packages with different pin on existing kernels, like distro kernels, just by modifying the the device tree data ;) FYI I'm playing with a DT based pinmux-simple.c driver that should be pretty generic and work for all kinds of hardware hopefully. I love it. Still need few more days with these patches.. It will be few days before I can post anything though, there are some pinctrl fwk issues to deal with first. Like the hardcoded pinmux_maps that assumes that dev entries are static. This means that multiple instances of pinmux drivers won't work.. I'm not following, but I guess I will understand when I see the patches. The idea behind the current map concept is that you get either a string or struct device * to identify the pin controller and mapped device, that's as far as I thought it out, sorry for any inherent limitations, they're not intentional... Yeah we can sort those out afterwards. We should probably pass over the static board specific mapping as platform_data to the pinmux device and make it be part of struct pinctrl_dev. Then new driver instances can have their own pctldev-mapping and we can support both platform_data and device tree based drivers on the same system. Anyways, I'll try to get the initial patches working with just one instance to start with so we have something to play with. Regards, Tony -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V3 1/6] ARM: exynos: Add AFTR mode cpuidle state on EXYNOS4210
On Thu, Nov 24, 2011 at 9:37 AM, Inderpal Singh
inderpal.si...@linaro.org wrote:
Hi Amit,
On 22 November 2011 15:05, Amit Daniel Kachhap amit.kach...@linaro.org
wrote:
This patch adds support AFTR(ARM OFF TOP RUNNING) mode in
cpuidle driver. L2 cache keeps their data in this mode.
This patch ports the code to the latest interfaces to
save/restore CPU state inclusive of CPU PM notifiers, l2
resume and cpu_suspend/resume.
Signed-off-by: Jaecheol Lee jc@samsung.com
Signed-off-by: Lorenzo Pieralisi lorenzo.pieral...@arm.com
Signed-off-by: Amit Daniel Kachhap amit.kach...@linaro.org
---
arch/arm/mach-exynos/cpuidle.c | 152
++-
arch/arm/mach-exynos/include/mach/pmu.h | 2 +
2 files changed, 151 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-exynos/cpuidle.c b/arch/arm/mach-exynos/cpuidle.c
index 21403c8..89afa93 100644
--- a/arch/arm/mach-exynos/cpuidle.c
+++ b/arch/arm/mach-exynos/cpuidle.c
@@ -12,15 +12,37 @@
#include linux/module.h
#include linux/init.h
#include linux/cpuidle.h
+#include linux/cpu_pm.h
#include linux/io.h
#include linux/export.h
#include linux/time.h
#include asm/proc-fns.h
+#include asm/smp_scu.h
+#include asm/suspend.h
+#include asm/unified.h
+#include mach/regs-pmu.h
+#include mach/pmu.h
+
+#include plat/exynos4.h
+#include plat/cpu.h
+
+#define REG_DIRECTGO_ADDR (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM7 : (samsung_rev() == EXYNOS4210_REV_1_0 ?
\
+ (S5P_VA_SYSRAM + 0x24) : S5P_INFORM0))
+#define REG_DIRECTGO_FLAG (samsung_rev() == EXYNOS4210_REV_1_1 ? \
+ S5P_INFORM6 : (samsung_rev() == EXYNOS4210_REV_1_0 ?
\
+ (S5P_VA_SYSRAM + 0x20) : S5P_INFORM1))
+
+#define S5P_CHECK_AFTR (samsung_rev() == EXYNOS4210_REV_1_0 ? \
+ 0xBAD0 : 0xFCBA0D10)
static int exynos4_enter_idle(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
int index);
+static int exynos4_enter_lowpower(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index);
static struct cpuidle_state exynos4_cpuidle_set[] = {
[0] = {
@@ -28,9 +50,17 @@ static struct cpuidle_state exynos4_cpuidle_set[] = {
.exit_latency = 1,
.target_residency = 10,
.flags = CPUIDLE_FLAG_TIME_VALID,
- .name = IDLE,
+ .name = C0,
.desc = ARM clock gating(WFI),
},
+ [1] = {
+ .enter = exynos4_enter_lowpower,
+ .exit_latency = 300,
+ .target_residency = 10,
+ .flags = CPUIDLE_FLAG_TIME_VALID,
+ .name = C1,
+ .desc = ARM power down,
+ },
};
static DEFINE_PER_CPU(struct cpuidle_device, exynos4_cpuidle_device);
@@ -40,9 +70,101 @@ static struct cpuidle_driver exynos4_idle_driver = {
.owner = THIS_MODULE,
};
+/* Ext-GIC nIRQ/nFIQ is the only wakeup source in AFTR */
+static void exynos4_set_wakeupmask(void)
+{
+ __raw_writel(0xff3e, S5P_WAKEUP_MASK);
+}
+
+static unsigned int g_pwr_ctrl, g_diag_reg;
+
+static void save_cpu_arch_register(void)
+{
+ /*read power control register*/
+ asm(mrc p15, 0, %0, c15, c0, 0 : =r(g_pwr_ctrl) : : cc);
+ /*read diagnostic register*/
+ asm(mrc p15, 0, %0, c15, c0, 1 : =r(g_diag_reg) : : cc);
+ return;
+}
+
+static void restore_cpu_arch_register(void)
+{
+ /*write power control register*/
+ asm(mcr p15, 0, %0, c15, c0, 0 : : r(g_pwr_ctrl) : cc);
+ /*write diagnostic register*/
+ asm(mcr p15, 0, %0, c15, c0, 1 : : r(g_diag_reg) : cc);
+ return;
+}
+
+static int idle_finisher(unsigned long flags)
+{
+ cpu_do_idle();
+ return 1;
+}
+
+static int exynos4_enter_core0_aftr(struct cpuidle_device *dev,
+ struct cpuidle_driver *drv,
+ int index)
+{
+ struct timeval before, after;
+ int idle_time;
+ unsigned long tmp;
+
+ local_irq_disable();
+ do_gettimeofday(before);
+
+ exynos4_set_wakeupmask();
+
+ /* Set value of power down register for aftr mode */
+ exynos4_sys_powerdown_conf(SYS_AFTR);
+
+ __raw_writel(BSYM(virt_to_phys(s3c_cpu_resume)),
+ REG_DIRECTGO_ADDR);
+ __raw_writel(S5P_CHECK_AFTR, REG_DIRECTGO_FLAG);
+
+ save_cpu_arch_register();
+
+ /* Setting Central Sequence Register for power down mode */
+
Re: [PATCH V3 0/6] ARM: exynos: Add l2 retention mode cpuidle state
Dear Kukjin Kim, Any comments or feedback on this patchset from your side. I am preparing another version with fixes/issues suggested by Russell and Inder. Thanks, Amit Daniel On Tue, Nov 22, 2011 at 3:05 PM, Amit Daniel Kachhap amit.kach...@linaro.org wrote: Changes since V2: *Implemented the suggestion of MyungJoo Ham and used INFORM0/1 registers for resume for some board versions. *Added back save/restore through CPU PM notifiers as suggested by Lorenzo Pieralisi. This is useful to restore vfp state. *some patch modularization (s5p/exynos) and proper commit logs. Changes since V1: *rebased the whole patch against 3.2-rc1 tree *removed GIC save/restore in AFTR cpuidle state as it is external to cpu powerdomain *Added L2 setup code through device tree *Removed only l2 save/restore registers in sleep This Patch series adds support for AFTR mode cpuidle state based on patch (http://www.spinics.net/lists/arm-kernel/msg132243.html) earlier submitted by Jaecheol Lee jc@samsung.com. This patch uses CPU PM notifiers , common l2 save/restore and new cpu_suspend/resume interfaces and is based on the tip of for-next branch of samsung tree. (git://git.kernel.org/pub/scm/linux/kernel/git/kgene/linux-samsung.git for-next). Amit Daniel Kachhap (6): ARM: exynos: Add support AFTR mode on EXYNOS4210 ARM: s5p: remove useless churn in sleep.S ARM: exynos: save L2 settings during bootup ARM: s5p: add L2 early resume code ARM: exynos: remove useless code to save/restore L2 ARM: exynos: Enable l2 configuration through device tree arch/arm/mach-exynos/cpu.c | 60 +--- arch/arm/mach-exynos/cpuidle.c | 152 ++- arch/arm/mach-exynos/include/mach/pmu.h | 2 + arch/arm/mach-exynos/pm.c | 15 --- arch/arm/plat-s5p/sleep.S | 32 ++- 5 files changed, 226 insertions(+), 35 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
