Re: [PATCH 4/5] gpiolib: handle deferral probe error
On Fri, Oct 07, 2011 at 04:09:38PM -0600, Grant Likely wrote: On Fri, Oct 7, 2011 at 4:06 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Fri, 07 Oct 2011 10:33:09 +0500 G, Manjunath Kondaiah manj...@ti.com wrote: The gpio library should return -EPROBE_DEFER in gpio_request if gpio driver is not ready. Why not use the perfectly good existing error codes we have for this ? We have EAGAIN and EUNATCH both of which look sensible. I want a distinct error code for probe deferral so that a) it doesn't overlap with something a driver is already doing, and b) so that all the users can be found again at a later date. That said, I'm not in agreement with this patch. It is fine for gpio lib to have a code that means the pin doesn't exist (yet), but the device driver needs to be the one to decide whether or not it is appropriate to use probe deferral. During gpio_request, driver gpio_request is not available. How can we expect driver to request deferred probe in this case? -M -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] drivercore: add new error value for deferred probe
On Sun, Oct 09, 2011 at 06:06:56PM -0700, Greg KH wrote: On Sun, Oct 09, 2011 at 04:59:31PM -0600, Grant Likely wrote: On Fri, Oct 7, 2011 at 6:12 PM, Greg KH g...@kroah.com wrote: On Fri, Oct 07, 2011 at 07:28:33PM -0400, valdis.kletni...@vt.edu wrote: On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said: On Fri, Oct 7, 2011 at 12:43 AM, Greg KH g...@kroah.com wrote: On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote: +#define EPROBE_DEFER 517 /* restart probe again after some time */ Can we really do this? According to Arnd, yes this is okay. Isn't this some user/kernel api here? What's wrong with just overloading on top of an existing error code? Surely one of the other 516 types could be used here, right? overloading makes it really hard to find the users at a later date. Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That would allow overloading EAGAIN, but still make it easy to tell the usages apart if we need to separate them later... Yes, please do that, it is what USB does for it's internal error code handling. Really? When we've only currently used approximately 2^9 of a 2^31 numberspace? I'm fine with making sure that the number doesn't show up in the userspace headers, but it makes no sense to overload the #defines. Particularly so in this case where it isn't feasible to audit every driver to figure out what probe might possibly return. It is well within the realm of possibility that existing drivers are already returning -EAGAIN. I doubt they are, but you are right, it's really hard to tell. Besides; linux/errno.h *already* has linux-internal error codes that do not get exported out to userspace. There is an #ifdef __KERNEL__ block around ERESTARTSYS through EIOCBRETRY which is filtered out when exporting headers. I can't see any possible reason why we wouldn't add Linux internal error codes here. As long as it stays internal, that's fine, I was worried that this would be exported to userspace. Alan, still object to this? I hope no one has objections to use EPROBE_DEFER -M -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
On Mon, Oct 10, 2011 at 10:37:22AM -0700, Andrei Warkentin wrote: Hi, - Original Message - From: Greg KH g...@kroah.com To: Josh Triplett j...@joshtriplett.org Cc: G, Manjunath Kondaiah manj...@ti.com, linux-arm-ker...@lists.infradead.org, Grant Likely grant.lik...@secretlab.ca, linux-o...@vger.kernel.org, linux-mmc@vger.kernel.org, linux-ker...@vger.kernel.org, Dilan Lee di...@nvidia.com, Mark Brown broo...@opensource.wolfsonmicro.com, manjun...@jasper.es Sent: Saturday, October 8, 2011 11:55:02 AM Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism I'm a bit of a fly on the wall here, but I'm curious how this impacts suspend/resume. device_initialize-device_pm_init are called from device_register, so certainly this patch doesn't also ensure that the PM ordering matches probe ordering, which is bound to break suspend, right? Was this ever tested with the OMAP target? Shouldn't the PM change be also part of this patch set? I don't see why you would want to have this in without the PM changes. suspend/resume handling is already in TODO list: http://permalink.gmane.org/gmane.linux.ports.arm.kernel/135461 -M Maybe I have it all wrong though :-). A -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH] mmc: core: Kill block requests if card is removed
Kill block requests when the host knows that the card is
removed from the slot and is sure that it can no longer
accept any requests.
Kill this silently so that the block layer don't output
error messages unnecessarily.
Signed-off-by: Sujit Reddy Thumma sthu...@codeaurora.org
diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
index fed290e..e1961db 100644
--- a/drivers/mmc/card/queue.c
+++ b/drivers/mmc/card/queue.c
@@ -29,6 +29,8 @@
*/
static int mmc_prep_request(struct request_queue *q, struct request *req)
{
+ struct mmc_queue *mq = q-queuedata;
+
/*
* We only like normal block requests and discards.
*/
@@ -37,6 +39,9 @@ static int mmc_prep_request(struct request_queue *q, struct
request *req)
return BLKPREP_KILL;
}
+ if (mq mq-card !mmc_card_inserted(mq-card))
+ return BLKPREP_KILL;
+
req-cmd_flags |= REQ_DONTPREP;
return BLKPREP_OK;
diff --git a/drivers/mmc/core/bus.c b/drivers/mmc/core/bus.c
index 46b6e84..ea3be5d 100644
--- a/drivers/mmc/core/bus.c
+++ b/drivers/mmc/core/bus.c
@@ -308,6 +308,7 @@ int mmc_add_card(struct mmc_card *card)
mmc_card_ddr_mode(card) ? DDR : ,
type, card-rca);
}
+ mmc_card_set_inserted(card);
#ifdef CONFIG_DEBUG_FS
mmc_add_card_debugfs(card);
@@ -340,6 +341,7 @@ void mmc_remove_card(struct mmc_card *card)
pr_info(%s: card %04x removed\n,
mmc_hostname(card-host), card-rca);
}
+ card-state = ~MMC_STATE_INSERTED;
device_del(card-dev);
}
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 0ea4a06..7cdbc14 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -196,6 +196,7 @@ struct mmc_card {
#define MMC_STATE_HIGHSPEED_DDR (14) /* card is in high speed mode */
#define MMC_STATE_ULTRAHIGHSPEED (15)/* card is in ultra
high speed mode */
#define MMC_CARD_SDXC (16) /* card is SDXC */
+#define MMC_STATE_INSERTED (17) /* card present in the slot */
unsigned intquirks; /* card quirks */
#define MMC_QUIRK_LENIENT_FN0 (10) /* allow SDIO FN0 writes
outside of the VS CCCR range */
#define MMC_QUIRK_BLKSZ_FOR_BYTE_MODE (11) /* use func-cur_blksize */
@@ -344,6 +345,7 @@ static inline void __maybe_unused remove_quirk(struct
mmc_card *card, int data)
#define mmc_card_sdio(c) ((c)-type == MMC_TYPE_SDIO)
#define mmc_card_present(c)((c)-state MMC_STATE_PRESENT)
+#define mmc_card_inserted(c) ((c)-state MMC_STATE_INSERTED)
#define mmc_card_readonly(c) ((c)-state MMC_STATE_READONLY)
#define mmc_card_highspeed(c) ((c)-state MMC_STATE_HIGHSPEED)
#define mmc_card_blockaddr(c) ((c)-state MMC_STATE_BLOCKADDR)
@@ -352,6 +354,7 @@ static inline void __maybe_unused remove_quirk(struct
mmc_card *card, int data)
#define mmc_card_ext_capacity(c) ((c)-state MMC_CARD_SDXC)
#define mmc_card_set_present(c)((c)-state |= MMC_STATE_PRESENT)
+#define mmc_card_set_inserted(c) ((c)-state |= MMC_STATE_INSERTED)
#define mmc_card_set_readonly(c) ((c)-state |= MMC_STATE_READONLY)
#define mmc_card_set_highspeed(c) ((c)-state |= MMC_STATE_HIGHSPEED)
#define mmc_card_set_blockaddr(c) ((c)-state |= MMC_STATE_BLOCKADDR)
--
1.7.3.3
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: mmci: Do not release spinlock in request_end
On Tue, Oct 11, 2011 at 4:06 PM, Ulf Hansson ulf.hans...@stericsson.com wrote: The patch mmc: core: move -request() call from atomic context, is the reason to why this change is possible. This simplifies the error handling code execution path quite a lot and potentially also fixes some error handling hang problems. Signed-off-by: Ulf Hansson ulf.hans...@stericsson.com Adrian do you agree with this? To me it looks correct, Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 0/3] ARM: SAMSUNG: Add support for sdhci clock lookup using generic names
This patchset adds support for sdhci controller clock lookup using generic names. With this patchset, there will be no need to pass clock names in sdhci platform data. This patchset depends on the patchset: Add a common macro for creating struct clk_lookup entries. mmc: sdhci-s3c: add default controller configuration. V2 Changes: - Added HCLK instance for HSMMC instance 1 as suggested by Heiko. - Rebased on UART clkdev patches. So these patches should be applied after UART clkdev patches are applied. V3 Changes: - Removed double registration of hsmmc1 hclk from s3c2416 as suggested by Heiko Rajeshwari Shinde (3): SDHCI: S3C: Use generic clock names for sdhci bus clock options ARM: SAMSUNG: Remove SDHCI bus clocks from platform data ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names arch/arm/mach-exynos4/Makefile |1 - arch/arm/mach-exynos4/clock.c | 88 +-- arch/arm/mach-exynos4/setup-sdhci.c| 22 arch/arm/mach-s3c2416/Makefile |1 - arch/arm/mach-s3c2416/clock.c | 68 ++- arch/arm/mach-s3c2416/setup-sdhci.c| 24 arch/arm/mach-s3c64xx/Makefile |1 - arch/arm/mach-s3c64xx/clock.c | 126 + arch/arm/mach-s3c64xx/setup-sdhci.c| 24 arch/arm/mach-s5pc100/Makefile |1 - arch/arm/mach-s5pc100/clock.c | 130 +- arch/arm/mach-s5pc100/setup-sdhci.c| 23 arch/arm/mach-s5pv210/Makefile |1 - arch/arm/mach-s5pv210/clock.c | 167 +--- arch/arm/mach-s5pv210/setup-sdhci.c| 22 arch/arm/plat-s3c24xx/s3c2443-clock.c | 15 ++- arch/arm/plat-samsung/include/plat/sdhci.h | 31 - drivers/mmc/host/sdhci-s3c.c |6 +- 18 files changed, 361 insertions(+), 390 deletions(-) delete mode 100644 arch/arm/mach-exynos4/setup-sdhci.c delete mode 100644 arch/arm/mach-s3c2416/setup-sdhci.c delete mode 100644 arch/arm/mach-s3c64xx/setup-sdhci.c delete mode 100644 arch/arm/mach-s5pc100/setup-sdhci.c delete mode 100644 arch/arm/mach-s5pv210/setup-sdhci.c -- 1.7.4.4 -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 1/3] SDHCI: S3C: Use generic clock names for sdhci bus clock options
This patch modifies the driver to stop depending on the clock names
being passed from the platform and switch over to bus clock lookup
using generic clock names.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
drivers/mmc/host/sdhci-s3c.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 82709b6..a5fde87 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -435,14 +435,12 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
for (clks = 0, ptr = 0; ptr MAX_BUS_CLK; ptr++) {
struct clk *clk;
- char *name = pdata-clocks[ptr];
+ char name[14];
- if (name == NULL)
- continue;
+ sprintf(name, mmc_busclk.%d, ptr);
clk = clk_get(dev, name);
if (IS_ERR(clk)) {
- dev_err(dev, failed to get clock %s\n, name);
continue;
}
--
1.7.4.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH V3 2/3] ARM: SAMSUNG: Remove SDHCI bus clocks from platform data
The bus clocks previously sent through platform data to SDHCI controller
are removed.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/mach-exynos4/Makefile |1 -
arch/arm/mach-exynos4/setup-sdhci.c| 22 ---
arch/arm/mach-s3c2416/Makefile |1 -
arch/arm/mach-s3c2416/setup-sdhci.c| 24 -
arch/arm/mach-s3c64xx/Makefile |1 -
arch/arm/mach-s3c64xx/setup-sdhci.c| 24 -
arch/arm/mach-s5pc100/Makefile |1 -
arch/arm/mach-s5pc100/setup-sdhci.c| 23
arch/arm/mach-s5pv210/Makefile |1 -
arch/arm/mach-s5pv210/setup-sdhci.c| 22 ---
arch/arm/plat-samsung/include/plat/sdhci.h | 31
11 files changed, 0 insertions(+), 151 deletions(-)
delete mode 100644 arch/arm/mach-exynos4/setup-sdhci.c
delete mode 100644 arch/arm/mach-s3c2416/setup-sdhci.c
delete mode 100644 arch/arm/mach-s3c64xx/setup-sdhci.c
delete mode 100644 arch/arm/mach-s5pc100/setup-sdhci.c
delete mode 100644 arch/arm/mach-s5pv210/setup-sdhci.c
diff --git a/arch/arm/mach-exynos4/Makefile b/arch/arm/mach-exynos4/Makefile
index 2bb18f4..c47aae3 100644
--- a/arch/arm/mach-exynos4/Makefile
+++ b/arch/arm/mach-exynos4/Makefile
@@ -55,7 +55,6 @@ obj-$(CONFIG_EXYNOS4_SETUP_I2C5) += setup-i2c5.o
obj-$(CONFIG_EXYNOS4_SETUP_I2C6) += setup-i2c6.o
obj-$(CONFIG_EXYNOS4_SETUP_I2C7) += setup-i2c7.o
obj-$(CONFIG_EXYNOS4_SETUP_KEYPAD) += setup-keypad.o
-obj-$(CONFIG_EXYNOS4_SETUP_SDHCI) += setup-sdhci.o
obj-$(CONFIG_EXYNOS4_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
obj-$(CONFIG_EXYNOS4_SETUP_USB_PHY)+= setup-usb-phy.o
diff --git a/arch/arm/mach-exynos4/setup-sdhci.c
b/arch/arm/mach-exynos4/setup-sdhci.c
deleted file mode 100644
index 92937b4..000
--- a/arch/arm/mach-exynos4/setup-sdhci.c
+++ /dev/null
@@ -1,22 +0,0 @@
-/* linux/arch/arm/mach-exynos4/setup-sdhci.c
- *
- * Copyright (c) 2010-2011 Samsung Electronics Co., Ltd.
- * http://www.samsung.com
- *
- * EXYNOS4 - Helper functions for settign up SDHCI device(s) (HSMMC)
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include linux/types.h
-
-/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
-
-char *exynos4_hsmmc_clksrcs[4] = {
- [0] = NULL,
- [1] = NULL,
- [2] = sclk_mmc, /* mmc_bus */
- [3] = NULL,
-};
diff --git a/arch/arm/mach-s3c2416/Makefile b/arch/arm/mach-s3c2416/Makefile
index 7b805b2..ca0cd22 100644
--- a/arch/arm/mach-s3c2416/Makefile
+++ b/arch/arm/mach-s3c2416/Makefile
@@ -15,7 +15,6 @@ obj-$(CONFIG_S3C2416_PM) += pm.o
#obj-$(CONFIG_S3C2416_DMA) += dma.o
# Device setup
-obj-$(CONFIG_S3C2416_SETUP_SDHCI) += setup-sdhci.o
obj-$(CONFIG_S3C2416_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
# Machine support
diff --git a/arch/arm/mach-s3c2416/setup-sdhci.c
b/arch/arm/mach-s3c2416/setup-sdhci.c
deleted file mode 100644
index cee5395..000
--- a/arch/arm/mach-s3c2416/setup-sdhci.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/* linux/arch/arm/mach-s3c2416/setup-sdhci.c
- *
- * Copyright 2010 Promwad Innovation Company
- * Yauhen Kharuzhy yauhen.kharu...@promwad.com
- *
- * S3C2416 - Helper functions for settign up SDHCI device(s) (HSMMC)
- *
- * Based on mach-s3c64xx/setup-sdhci.c
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
-*/
-
-#include linux/types.h
-
-/* clock sources for the mmc bus clock, order as for the ctrl2[5..4] */
-
-char *s3c2416_hsmmc_clksrcs[4] = {
- [0] = hsmmc,
- [1] = hsmmc,
- [2] = hsmmc-if,
- /* [3] = 48m, - note not successfully used yet */
-};
diff --git a/arch/arm/mach-s3c64xx/Makefile b/arch/arm/mach-s3c64xx/Makefile
index 902ab9a..94de24b 100644
--- a/arch/arm/mach-s3c64xx/Makefile
+++ b/arch/arm/mach-s3c64xx/Makefile
@@ -32,7 +32,6 @@ obj-$(CONFIG_S3C64XX_SETUP_I2C0) += setup-i2c0.o
obj-$(CONFIG_S3C64XX_SETUP_I2C1) += setup-i2c1.o
obj-$(CONFIG_S3C64XX_SETUP_IDE) += setup-ide.o
obj-$(CONFIG_S3C64XX_SETUP_KEYPAD) += setup-keypad.o
-obj-$(CONFIG_S3C64XX_SETUP_SDHCI) += setup-sdhci.o
obj-$(CONFIG_S3C64XX_SETUP_FB_24BPP) += setup-fb-24bpp.o
obj-$(CONFIG_S3C64XX_SETUP_SDHCI_GPIO) += setup-sdhci-gpio.o
diff --git a/arch/arm/mach-s3c64xx/setup-sdhci.c
b/arch/arm/mach-s3c64xx/setup-sdhci.c
deleted file mode 100644
index c75a71b..000
--- a/arch/arm/mach-s3c64xx/setup-sdhci.c
+++ /dev/null
@@ -1,24 +0,0 @@
-/* linux/arch/arm/mach-s3c64xx/setup-sdhci.c
- *
- * Copyright 2008 Simtec Electronics
- * Copyright 2008 Simtec Electronics
- * Ben Dooks b...@simtec.co.uk
- *
[PATCH V4 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names
Add support for lookup of sdhci-s3c controller clocks using generic names
for s3c2416, s3c64xx, s5pc100, s5pv210 and exynos4 SoC's.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/mach-exynos4/clock.c | 88 ++---
arch/arm/mach-s3c2416/clock.c | 68 +++--
arch/arm/mach-s3c64xx/clock.c | 126 +++--
arch/arm/mach-s5pc100/clock.c | 130 --
arch/arm/mach-s5pv210/clock.c | 167 -
arch/arm/plat-s3c24xx/s3c2443-clock.c | 15 ++-
6 files changed, 359 insertions(+), 235 deletions(-)
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 9f50e33..c6383b9 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -1157,42 +1157,6 @@ static struct clksrc_clk clksrcs[] = {
.reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
}, {
.clk= {
- .name = sclk_mmc,
- .devname= s3c-sdhci.0,
- .parent = clk_dout_mmc0.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit= (1 0),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
- }, {
- .clk= {
- .name = sclk_mmc,
- .devname= s3c-sdhci.1,
- .parent = clk_dout_mmc1.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit= (1 4),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
- }, {
- .clk= {
- .name = sclk_mmc,
- .devname= s3c-sdhci.2,
- .parent = clk_dout_mmc2.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit= (1 8),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
- }, {
- .clk= {
- .name = sclk_mmc,
- .devname= s3c-sdhci.3,
- .parent = clk_dout_mmc3.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit= (1 12),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
- }, {
- .clk= {
.name = sclk_dwmmc,
.parent = clk_dout_mmc4.clk,
.enable = exynos4_clksrc_mask_fsys_ctrl,
@@ -1250,6 +1214,50 @@ static struct clksrc_clk clk_sclk_uart3 = {
.reg_div = { .reg = S5P_CLKDIV_PERIL0, .shift = 12, .size = 4 },
};
+static struct clksrc_clk clk_sclk_mmc0 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.0,
+ .parent = clk_dout_mmc0.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 0),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc1 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.1,
+ .parent = clk_dout_mmc1.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 4),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc2 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.2,
+ .parent = clk_dout_mmc2.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 8),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc3 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.3,
+ .parent = clk_dout_mmc3.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 12),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
+};
+
/* Clock initialization code */
static struct clksrc_clk *sysclks[] = {
clk_mout_apll,
@@ -1289,6 +1297,10 @@ static struct clksrc_clk *clksrc_cdev[] = {
clk_sclk_uart1,
clk_sclk_uart2,
clk_sclk_uart3,
+
Re: [PATCH V4 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names
Hi Rajeshwari,
On 10/12/2011 11:43 AM, Rajeshwari Shinde wrote:
Add support for lookup of sdhci-s3c controller clocks using generic names
for s3c2416, s3c64xx, s5pc100, s5pv210 and exynos4 SoC's.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/mach-exynos4/clock.c | 88 ++---
arch/arm/mach-s3c2416/clock.c | 68 +++--
arch/arm/mach-s3c64xx/clock.c | 126 +++--
arch/arm/mach-s5pc100/clock.c | 130 --
arch/arm/mach-s5pv210/clock.c | 167
-
arch/arm/plat-s3c24xx/s3c2443-clock.c | 15 ++-
6 files changed, 359 insertions(+), 235 deletions(-)
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 9f50e33..c6383b9 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -1157,42 +1157,6 @@ static struct clksrc_clk clksrcs[] = {
.reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
}, {
.clk= {
- .name = sclk_mmc,
- .devname= s3c-sdhci.0,
- .parent = clk_dout_mmc0.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit= (1 0),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
- }, {
- .clk= {
- .name = sclk_mmc,
- .devname= s3c-sdhci.1,
- .parent = clk_dout_mmc1.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit= (1 4),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
- }, {
- .clk= {
- .name = sclk_mmc,
- .devname= s3c-sdhci.2,
- .parent = clk_dout_mmc2.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit= (1 8),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
- }, {
- .clk= {
- .name = sclk_mmc,
- .devname= s3c-sdhci.3,
- .parent = clk_dout_mmc3.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit= (1 12),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
- }, {
- .clk= {
.name = sclk_dwmmc,
.parent = clk_dout_mmc4.clk,
.enable = exynos4_clksrc_mask_fsys_ctrl,
@@ -1250,6 +1214,50 @@ static struct clksrc_clk clk_sclk_uart3 = {
.reg_div = { .reg = S5P_CLKDIV_PERIL0, .shift = 12, .size = 4 },
};
+static struct clksrc_clk clk_sclk_mmc0 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.0,
Would it make sense to drop this 'devname' field here and others
until sclk_mmc3
+ .parent = clk_dout_mmc0.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 0),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc1 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.1,
+ .parent = clk_dout_mmc1.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 4),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc2 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.2,
+ .parent = clk_dout_mmc2.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 8),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc3 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.3,
+ .parent = clk_dout_mmc3.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 12),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
+};
+
/* Clock initialization code */
static struct clksrc_clk *sysclks[] = {
clk_mout_apll,
@@ -1289,6 +1297,10 @@ static
Re: [PATCH] mmc: mmci: Do not release spinlock in request_end
On 12/10/11 12:41, Linus Walleij wrote: On Tue, Oct 11, 2011 at 4:06 PM, Ulf Hansson ulf.hans...@stericsson.com wrote: The patch mmc: core: move -request() call from atomic context, is the reason to why this change is possible. This simplifies the error handling code execution path quite a lot and potentially also fixes some error handling hang problems. Signed-off-by: Ulf Hansson ulf.hans...@stericsson.com Adrian do you agree with this? Yes To me it looks correct, Acked-by: Linus Walleij linus.wall...@linaro.org Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] mmc: core: Kill block requests if card is removed
Hello Sujit,
On 10/12/2011 1:06 PM, Sujit Reddy Thumma wrote:
Kill block requests when the host knows that the card is
removed from the slot and is sure that it can no longer
accept any requests.
Kill this silently so that the block layer don't output
error messages unnecessarily.
Signed-off-by: Sujit Reddy Thumma sthu...@codeaurora.org
snip
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index 0ea4a06..7cdbc14 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -196,6 +196,7 @@ struct mmc_card {
#define MMC_STATE_HIGHSPEED_DDR (14) /* card is in high
speed mode */
#define MMC_STATE_ULTRAHIGHSPEED (15) /* card is in ultra
high speed mode */
#define MMC_CARD_SDXC(16) /* card is SDXC */
+#define MMC_STATE_INSERTED (17) /* card present in the slot
*/
unsigned intquirks; /* card quirks */
#define MMC_QUIRK_LENIENT_FN0(10) /* allow SDIO FN0
writes outside of the VS CCCR range */
#define MMC_QUIRK_BLKSZ_FOR_BYTE_MODE (11) /* use func-cur_blksize */
@@ -344,6 +345,7 @@ static inline void __maybe_unused remove_quirk(struct
mmc_card *card, int data)
#define mmc_card_sdio(c) ((c)-type == MMC_TYPE_SDIO)
#define mmc_card_present(c) ((c)-state MMC_STATE_PRESENT)
+#define mmc_card_inserted(c) ((c)-state MMC_STATE_INSERTED)
#define mmc_card_readonly(c) ((c)-state MMC_STATE_READONLY)
#define mmc_card_highspeed(c)((c)-state MMC_STATE_HIGHSPEED)
#define mmc_card_blockaddr(c)((c)-state MMC_STATE_BLOCKADDR)
@@ -352,6 +354,7 @@ static inline void __maybe_unused remove_quirk(struct
mmc_card *card, int data)
#define mmc_card_ext_capacity(c) ((c)-state MMC_CARD_SDXC)
#define mmc_card_set_present(c) ((c)-state |= MMC_STATE_PRESENT)
+#define mmc_card_set_inserted(c) ((c)-state |= MMC_STATE_INSERTED)
#define mmc_card_set_readonly(c) ((c)-state |= MMC_STATE_READONLY)
#define mmc_card_set_highspeed(c) ((c)-state |= MMC_STATE_HIGHSPEED)
#define mmc_card_set_blockaddr(c) ((c)-state |= MMC_STATE_BLOCKADDR)
Why do we need another flag to indicate card's presence? can not we use
MMC_STATE_PRESENT flag? This flag is set in mmc_add_card(). But not
cleared any where...
Thanks,
Pavan
--
Sent by a consultant of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names
Hi Sylwester,
On Wed, Oct 12, 2011 at 3:54 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
Hi Rajeshwari,
On 10/12/2011 11:43 AM, Rajeshwari Shinde wrote:
Add support for lookup of sdhci-s3c controller clocks using generic names
for s3c2416, s3c64xx, s5pc100, s5pv210 and exynos4 SoC's.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/mach-exynos4/clock.c | 88 ++---
arch/arm/mach-s3c2416/clock.c | 68 +++--
arch/arm/mach-s3c64xx/clock.c | 126 +++--
arch/arm/mach-s5pc100/clock.c | 130 --
arch/arm/mach-s5pv210/clock.c | 167
-
arch/arm/plat-s3c24xx/s3c2443-clock.c | 15 ++-
6 files changed, 359 insertions(+), 235 deletions(-)
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 9f50e33..c6383b9 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -1157,42 +1157,6 @@ static struct clksrc_clk clksrcs[] = {
.reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
}, {
.clk = {
- .name = sclk_mmc,
- .devname = s3c-sdhci.0,
- .parent = clk_dout_mmc0.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit = (1 0),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
- }, {
- .clk = {
- .name = sclk_mmc,
- .devname = s3c-sdhci.1,
- .parent = clk_dout_mmc1.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit = (1 4),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
- }, {
- .clk = {
- .name = sclk_mmc,
- .devname = s3c-sdhci.2,
- .parent = clk_dout_mmc2.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit = (1 8),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
- }, {
- .clk = {
- .name = sclk_mmc,
- .devname = s3c-sdhci.3,
- .parent = clk_dout_mmc3.clk,
- .enable = exynos4_clksrc_mask_fsys_ctrl,
- .ctrlbit = (1 12),
- },
- .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
- }, {
- .clk = {
.name = sclk_dwmmc,
.parent = clk_dout_mmc4.clk,
.enable = exynos4_clksrc_mask_fsys_ctrl,
@@ -1250,6 +1214,50 @@ static struct clksrc_clk clk_sclk_uart3 = {
.reg_div = { .reg = S5P_CLKDIV_PERIL0, .shift = 12, .size = 4 },
};
+static struct clksrc_clk clk_sclk_mmc0 = {
+ .clk = {
+ .name = sclk_mmc,
+ .devname = s3c-sdhci.0,
Would it make sense to drop this 'devname' field here and others
until sclk_mmc3
*** The devname here distinguishes these clocks. So it should be okay
to have a devname for these clocks.
+ .parent = clk_dout_mmc0.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit = (1 0),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc1 = {
+ .clk = {
+ .name = sclk_mmc,
+ .devname = s3c-sdhci.1,
+ .parent = clk_dout_mmc1.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit = (1 4),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc2 = {
+ .clk = {
+ .name = sclk_mmc,
+ .devname = s3c-sdhci.2,
+ .parent = clk_dout_mmc2.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit = (1 8),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc3 = {
+ .clk = {
+ .name = sclk_mmc,
+ .devname = s3c-sdhci.3,
+ .parent = clk_dout_mmc3.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit = (1 12),
+ },
+
[PATCH] mmc: sdhci: fix debug_quirks2 module parameter description
debug_quirks2 module parameter description was inadvertently added as debug_quirks. Signed-off-by: Adrian Hunter adrian.hun...@intel.com --- drivers/mmc/host/sdhci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index f530de6..2cc3ffa 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -3058,4 +3058,4 @@ MODULE_DESCRIPTION(Secure Digital Host Controller Interface core driver); MODULE_LICENSE(GPL); MODULE_PARM_DESC(debug_quirks, Force certain quirks.); -MODULE_PARM_DESC(debug_quirks, Force certain other quirks.); +MODULE_PARM_DESC(debug_quirks2, Force certain other quirks.); -- 1.7.6.4 -- To unsubscribe from this list: send the line unsubscribe linux-mmc 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] mmc: sdhci-s3c: fix wrong error-control
Hi,
On Wed, Oct 12 2011, Jaehoon Chung wrote:
If sc-clk_bus[ptr] is NULL, happen NULL pointer error.
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/host/sdhci-s3c.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 82709b6..3d00e72 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -567,8 +567,10 @@ static int __devinit sdhci_s3c_probe(struct
platform_device *pdev)
err_req_regs:
for (ptr = 0; ptr MAX_BUS_CLK; ptr++) {
- clk_disable(sc-clk_bus[ptr]);
- clk_put(sc-clk_bus[ptr]);
+ if (sc-clk_bus[ptr]) {
+ clk_disable(sc-clk_bus[ptr]);
+ clk_put(sc-clk_bus[ptr]);
+ }
}
err_no_busclks:
Thanks, pushed to mmc-next for 3.2.
- Chris.
--
Chris Ball c...@laptop.org http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mmc: sdhci: fix debug_quirks2 module parameter description
Hi Adrian, On Wed, Oct 12 2011, Adrian Hunter wrote: debug_quirks2 module parameter description was inadvertently added as debug_quirks. Signed-off-by: Adrian Hunter adrian.hun...@intel.com --- drivers/mmc/host/sdhci.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c index f530de6..2cc3ffa 100644 --- a/drivers/mmc/host/sdhci.c +++ b/drivers/mmc/host/sdhci.c @@ -3058,4 +3058,4 @@ MODULE_DESCRIPTION(Secure Digital Host Controller Interface core driver); MODULE_LICENSE(GPL); MODULE_PARM_DESC(debug_quirks, Force certain quirks.); -MODULE_PARM_DESC(debug_quirks, Force certain other quirks.); +MODULE_PARM_DESC(debug_quirks2, Force certain other quirks.); Thanks, I've folded this into the original sdhci-pci: add runtime pm support patch in mmc-next. - Chris. -- Chris Ball c...@laptop.org http://printf.net/ One Laptop Per Child -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH V4 3/3] ARM: SAMSUNG: Add lookup of sdhci-s3c clocks using generic names
On 10/12/2011 02:36 PM, Rajeshwari Birje wrote:
On Wed, Oct 12, 2011 at 3:54 PM, Sylwester Nawrocki
s.nawro...@samsung.com wrote:
Hi Rajeshwari,
On 10/12/2011 11:43 AM, Rajeshwari Shinde wrote:
Add support for lookup of sdhci-s3c controller clocks using generic names
for s3c2416, s3c64xx, s5pc100, s5pv210 and exynos4 SoC's.
Signed-off-by: Rajeshwari Shinde rajeshwar...@samsung.com
---
arch/arm/mach-exynos4/clock.c | 88 ++---
arch/arm/mach-s3c2416/clock.c | 68 +++--
arch/arm/mach-s3c64xx/clock.c | 126 +++--
arch/arm/mach-s5pc100/clock.c | 130 --
arch/arm/mach-s5pv210/clock.c | 167
-
arch/arm/plat-s3c24xx/s3c2443-clock.c | 15 ++-
6 files changed, 359 insertions(+), 235 deletions(-)
diff --git a/arch/arm/mach-exynos4/clock.c b/arch/arm/mach-exynos4/clock.c
index 9f50e33..c6383b9 100644
--- a/arch/arm/mach-exynos4/clock.c
+++ b/arch/arm/mach-exynos4/clock.c
@@ -1157,42 +1157,6 @@ static struct clksrc_clk clksrcs[] = {
.reg_div = { .reg = S5P_CLKDIV_MFC, .shift = 0, .size = 4 },
...
+static struct clksrc_clk clk_sclk_mmc0 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.0,
Would it make sense to drop this 'devname' field here and others
until sclk_mmc3
*** The devname here distinguishes these clocks. So it should be okay
to have a devname for these clocks.
I'm not sure what's Mr Kukjin's opinion on that, but I personally would really
like to see all the devname fields disappear from samsung clk data structures.
Possibly if all involved people would keep that in mind we could achieve this
over time.
+ .parent = clk_dout_mmc0.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 0),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc1 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.1,
+ .parent = clk_dout_mmc1.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 4),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS1, .shift = 24, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc2 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.2,
+ .parent = clk_dout_mmc2.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 8),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 8, .size = 8 },
+};
+
+static struct clksrc_clk clk_sclk_mmc3 = {
+ .clk= {
+ .name = sclk_mmc,
+ .devname= s3c-sdhci.3,
+ .parent = clk_dout_mmc3.clk,
+ .enable = exynos4_clksrc_mask_fsys_ctrl,
+ .ctrlbit= (1 12),
+ },
+ .reg_div = { .reg = S5P_CLKDIV_FSYS2, .shift = 24, .size = 8 },
+};
+
/* Clock initialization code */
static struct clksrc_clk *sysclks[] = {
clk_mout_apll,
@@ -1289,6 +1297,10 @@ static struct clksrc_clk *clksrc_cdev[] = {
clk_sclk_uart1,
clk_sclk_uart2,
clk_sclk_uart3,
+ clk_sclk_mmc0,
+ clk_sclk_mmc1,
+ clk_sclk_mmc2,
+ clk_sclk_mmc3,
..then drop the above 4 lines...
The registration for these clocks are important. The
s3c_register_clksrc() function sets the .ops of this clock and also
its parent. So the registration cannot be dropped.
OK.
};
static struct clk_lookup exynos4_clk_lookup[] = {
@@ -1296,6 +1308,10 @@ static struct clk_lookup exynos4_clk_lookup[] = {
CLKDEV_INIT(exynos4210-uart.1, clk_uart_baud0,
clk_sclk_uart1.clk),
CLKDEV_INIT(exynos4210-uart.2, clk_uart_baud0,
clk_sclk_uart2.clk),
CLKDEV_INIT(exynos4210-uart.3, clk_uart_baud0,
clk_sclk_uart3.clk),
+ CLKDEV_INIT(exynos4-sdhci.0, mmc_busclk.2, clk_sclk_mmc0.clk),
+ CLKDEV_INIT(exynos4-sdhci.1, mmc_busclk.2, clk_sclk_mmc1.clk),
+ CLKDEV_INIT(exynos4-sdhci.2, mmc_busclk.2, clk_sclk_mmc2.clk),
+ CLKDEV_INIT(exynos4-sdhci.3, mmc_busclk.2, clk_sclk_mmc3.clk),
..and add something like:
+ CLKDEV_INIT(s3c-sdhci.0, sclk_mmc, clk_sclk_mmc0.clk),
+ CLKDEV_INIT(s3c-sdhci.1, sclk_mmc, clk_sclk_mmc1.clk),
+ CLKDEV_INIT(s3c-sdhci.2, sclk_mmc, clk_sclk_mmc2.clk),
+ CLKDEV_INIT(s3c-sdhci.3, sclk_mmc, clk_sclk_mmc3.clk),
?
The driver uses a common name for the possible bus clock sources,
that is “mmc_busclk”. This keeps the clock lookup code in the driver
simple. Also, there could be SoC’s which do no use sclk_mmc as the bus
clock name as per the user manual
Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism
On Tue, Oct 11, 2011 at 08:29:18PM +0800, Ming Lei wrote: On Tue, Oct 11, 2011 at 1:37 AM, Andrei Warkentin awarken...@vmware.com wrote: Hi, - Original Message - From: Greg KH g...@kroah.com To: Josh Triplett j...@joshtriplett.org Cc: G, Manjunath Kondaiah manj...@ti.com, linux-arm-ker...@lists.infradead.org, Grant Likely grant.lik...@secretlab.ca, linux-o...@vger.kernel.org, linux-mmc@vger.kernel.org, linux-ker...@vger.kernel.org, Dilan Lee di...@nvidia.com, Mark Brown broo...@opensource.wolfsonmicro.com, manjun...@jasper.es Sent: Saturday, October 8, 2011 11:55:02 AM Subject: Re: [PATCH 2/5] drivercore: Add driver probe deferral mechanism I'm a bit of a fly on the wall here, but I'm curious how this impacts suspend/resume. device_initialize-device_pm_init are called from device_register, so certainly this patch doesn't also ensure that the PM ordering matches probe ordering, which is bound to break suspend, right? Was this ever tested with the OMAP target? Shouldn't the Inside device_add(), device_pm_add is called before bus_probe_device, so the patch can't change the device order in pm list, and just change the driver probe order. That's the way it works now, but can it be reworked? It would be possible to adjust the list order after successful probe. However, I'm not clear on the ordering rules for the dpm_list. Right now it is explicitly ordered to have parents before children, but as already expressed, that doesn't accurately represent ordering constraints for multiple device dependancies. So, reordering the list would probably require maintaining the existing parent-child ordering constraint, but to also shift devices (and any possible children?) to be after drivers that are already probed. That alone will be difficult to implement and get right, but maybe the constraints can be simplified. It needs some further thought. g. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] drivercore: add new error value for deferred probe
On Wed, Oct 12, 2011 at 11:48:23AM +0530, G, Manjunath Kondaiah wrote: On Sun, Oct 09, 2011 at 06:06:56PM -0700, Greg KH wrote: On Sun, Oct 09, 2011 at 04:59:31PM -0600, Grant Likely wrote: On Fri, Oct 7, 2011 at 6:12 PM, Greg KH g...@kroah.com wrote: On Fri, Oct 07, 2011 at 07:28:33PM -0400, valdis.kletni...@vt.edu wrote: On Fri, 07 Oct 2011 16:12:45 MDT, Grant Likely said: On Fri, Oct 7, 2011 at 12:43 AM, Greg KH g...@kroah.com wrote: On Fri, Oct 07, 2011 at 10:33:06AM +0500, G, Manjunath Kondaiah wrote: +#define EPROBE_DEFER 517 /* restart probe again after some time */ Can we really do this? According to Arnd, yes this is okay. Isn't this some user/kernel api here? What's wrong with just overloading on top of an existing error code? Surely one of the other 516 types could be used here, right? overloading makes it really hard to find the users at a later date. Would proposing '#define EPROBE_DEFER EAGAIN' be acceptable to everybody? That would allow overloading EAGAIN, but still make it easy to tell the usages apart if we need to separate them later... Yes, please do that, it is what USB does for it's internal error code handling. Really? When we've only currently used approximately 2^9 of a 2^31 numberspace? I'm fine with making sure that the number doesn't show up in the userspace headers, but it makes no sense to overload the #defines. Particularly so in this case where it isn't feasible to audit every driver to figure out what probe might possibly return. It is well within the realm of possibility that existing drivers are already returning -EAGAIN. I doubt they are, but you are right, it's really hard to tell. Besides; linux/errno.h *already* has linux-internal error codes that do not get exported out to userspace. There is an #ifdef __KERNEL__ block around ERESTARTSYS through EIOCBRETRY which is filtered out when exporting headers. I can't see any possible reason why we wouldn't add Linux internal error codes here. As long as it stays internal, that's fine, I was worried that this would be exported to userspace. Alan, still object to this? I hope no one has objections to use EPROBE_DEFER I say go with that value. If Alan still objects, then he will speak up. g. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] gpiolib: handle deferral probe error
On Wed, Oct 12, 2011 at 11:44:32AM +0530, G, Manjunath Kondaiah wrote: On Fri, Oct 07, 2011 at 04:09:38PM -0600, Grant Likely wrote: On Fri, Oct 7, 2011 at 4:06 AM, Alan Cox a...@lxorguk.ukuu.org.uk wrote: On Fri, 07 Oct 2011 10:33:09 +0500 G, Manjunath Kondaiah manj...@ti.com wrote: The gpio library should return -EPROBE_DEFER in gpio_request if gpio driver is not ready. Why not use the perfectly good existing error codes we have for this ? We have EAGAIN and EUNATCH both of which look sensible. I want a distinct error code for probe deferral so that a) it doesn't overlap with something a driver is already doing, and b) so that all the users can be found again at a later date. That said, I'm not in agreement with this patch. It is fine for gpio lib to have a code that means the pin doesn't exist (yet), but the device driver needs to be the one to decide whether or not it is appropriate to use probe deferral. During gpio_request, driver gpio_request is not available. How can we expect driver to request deferred probe in this case? If gpio_request fails, the driver can then explicitly make the decision to return -EPROBE_DEFER. It isn't forced to pass on the error code from gpio_request(). g. -- To unsubscribe from this list: send the line unsubscribe linux-mmc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
