Re: [PATCH] sdhci: allow for eMMC 74 clock generation by controller
On 21/09/10 18:06, Philip Rakity wrote:
Our hardware needs to be programmed to handle this case. The host-ops option
is only needed from h/w that does not handle this.
If you can suggest a way to do this in the mmc layer I would welcome
implementing it.
No, I misunderstood sorry :(. The 74-clocks requirement is standard and
drivers handle it via set_ios.
I looked and the solution requires a call into the driver from the mmc layer
after the all setting POWER_ON call. This was more intrusive than doing it in
the driver but if you think this makes sense I can do a patch for that.
eg
/*
* Apply power to the MMC stack. This is a two-stage process.
* First, we enable power to the card without the clock running.
* We then wait a bit for the power to stabilise. Finally,
* enable the bus drivers and clock to the card.
*
* We must _NOT_ enable the clock prior to power stablising.
*
* If a host does all the power sequencing itself, ignore the
* initial MMC_POWER_UP stage.
*/
static void mmc_power_up(struct mmc_host *host)
{
int bit = fls(host-ocr_avail) - 1;
host-ios.vdd = bit;
if (mmc_host_is_spi(host)) {
host-ios.chip_select = MMC_CS_HIGH;
host-ios.bus_mode = MMC_BUSMODE_PUSHPULL;
} else {
host-ios.chip_select = MMC_CS_DONTCARE;
host-ios.bus_mode = MMC_BUSMODE_OPENDRAIN;
}
host-ios.power_mode = MMC_POWER_UP;
host-ios.bus_width = MMC_BUS_WIDTH_1;
host-ios.timing = MMC_TIMING_LEGACY;
mmc_set_ios(host);
/* CALL INTO DRIVER HERE TO SEND 74 CLOCKS */==
Philip
On Sep 20, 2010, at 11:04 PM, Adrian Hunter wrote:
On 21/09/10 08:43, ext Philip Rakity wrote:
Wolfram,
I generated the patch for eMMC 74 clocks. I do not know if you want to
incorporate into your submission or let it stand on its own.
Wouldn't it be better to fix it in MMC core rather than duplicate it in every
driver?
regards,
Philip
From: Philip Rakityprak...@marvell.com
Subject: [PATCH] sdhci: allow for eMMC 74 clock generation by controller
Signed-off-by: Philip Rakityprak...@marvell.com
Patch is below and sample usage in sdhci-.c adaption code is below.
/*
* eMMC spec calls for the host to send 74 clocks to the card
* during initialization, right after voltage stabilization.
* create the clocks manually right here.
*/
void generate_init_clocks_A0(struct sdhci_host *host, u8 power_mode)
{
struct sdhci_mmc_slot *slot = sdhci_priv(host);
DBG (%s: ENTER %s: slot-power_mode = %d, ios-power_mode = %d\n,
__func__,
mmc_hostname(host-mmc),
slot-power_mode,
power_mode);
if (slot-power_mode == MMC_POWER_UP
power_mode == MMC_POWER_ON) {
/* controller specific code here */
/* slot-power_mode holds previous power setting */
}
slot-power_mode = power_mode;
}
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 401527d..6aadd0f 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1168,6 +1168,9 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
else
sdhci_set_power(host, ios-vdd);
+ if (host-ops-platform_generate_initial_74_clocks)
+ host-ops-platform_generate_initial_74_clocks(host,
ios-power_mode);
+
ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
if (ios-bus_width == MMC_BUS_WIDTH_8)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index d316bc7..70c5806 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -323,6 +323,8 @@ struct sdhci_ops {
unsigned int(*get_max_clock)(struct sdhci_host *host);
unsigned int(*get_min_clock)(struct sdhci_host *host);
unsigned int(*get_timeout_clock)(struct sdhci_host *host);
+ void(*platform_generate_initial_74_clocks)(struct
sdhci_host *host,
+ u8 power_mode);
};
#ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
--
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
--
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 v2 1/4] omap4 hsmmc: Adding card detect support for MMC1
Hi,
On Sat, Sep 18, 2010 at 11:33:56AM -0500, kishore kadiyala wrote:
@@ -223,6 +224,81 @@ int twl6030_interrupt_mask(u8 bit_mask, u8 offset)
}
EXPORT_SYMBOL(twl6030_interrupt_mask);
+int twl6030_mmc_card_detect_config(void)
+{
+ int ret;
+ u8 reg_val = 0;
+
+ /* Unmasking the Card detect Interrupt line for MMC1 from Phoenix */
+ if (twl_class_is_6030()) {
which other class can this be ?
+ /*
+* Intially Configuring MMC_CTRL for receving interrupts
+* Card status on TWL6030 for MMC1
+*/
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ pr_err(twl6030: Failed to read MMCCTRL, error %d\n, ret);
+ return ret;
+ }
+ reg_val = ~VMMC_AUTO_OFF;
+ reg_val |= SW_FC;
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val, TWL6030_MMCCTRL);
+ if (ret 0) {
+ pr_err(twl6030: Failed to write MMCCTRL, error %d\n, ret);
+ return ret;
+ }
+
+ /* Configuring PullUp-PullDown register */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
is this a gpio ? Could gpiolib take care of this ?
+ if (ret 0) {
+ pr_err(twl6030: Failed to read CFG_INPUT_PUPD3, error %d\n,
+ ret);
+ return ret;
+ }
+ reg_val = ~(MMC_PU | MMC_PD);
+ ret = twl_i2c_write_u8(TWL6030_MODULE_ID0, reg_val,
+ TWL6030_CFG_INPUT_PUPD3);
ditto.
+int twl6030_mmc_card_detect(struct device *dev, int slot)
+{
+ int ret = -EIO;
+ u8 read_reg = 0;
+ struct platform_device *pdev = container_of(dev,
+ struct platform_device, dev);
how about:
struct platform_device *pdev = to_platform_device(dev);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 562dbbb..a51894d 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -466,8 +466,6 @@ static int omap_hsmmc_gpio_init(struct
omap_mmc_platform_data *pdata)
int ret;
if (gpio_is_valid(pdata-slots[0].switch_pin)) {
- pdata-suspend = omap_hsmmc_suspend_cdirq;
- pdata-resume = omap_hsmmc_resume_cdirq;
if (pdata-slots[0].cover)
pdata-slots[0].get_cover_state =
omap_hsmmc_get_cover_state;
@@ -2211,6 +2209,8 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
Unable to grab MMC CD IRQ\n);
goto err_irq_cd;
}
+ pdata-suspend = omap_hsmmc_suspend_cdirq;
+ pdata-resume = omap_hsmmc_resume_cdirq;
this doesn't look to be part of $SUBJECT, care to explain ?
@@ -173,6 +183,27 @@ int twl_i2c_read(u8 mod_no, u8 *value, u8 reg, unsigned
num_bytes);
int twl6030_interrupt_unmask(u8 bit_mask, u8 offset);
int twl6030_interrupt_mask(u8 bit_mask, u8 offset);
+/* Card detect Configuration for MMC1 Controller on OMAP4 */
+#ifdef CONFIG_TWL4030_CORE
+int twl6030_mmc_card_detect_config(void);
+#else
+static inline int twl6030_mmc_card_detect_config(void)
+{
+ pr_err(twl6030_mmc_card_detect_config not supported\n);
pr_debug() would be better ??
+/* MMC1 Controller on OMAP4 uses Phoenix irq for Card detect */
+#ifdef CONFIG_TWL4030_CORE
+int twl6030_mmc_card_detect(struct device *dev, int slot);
+#else
+static inline int twl6030_mmc_card_detect(struct device *dev, int slot)
+{
+ pr_err(Call back twl6030_mmc_card_detect not supported\n);
ditto.
--
balbi
--
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] sdhci: allow for eMMC 74 clock generation by controller
Hi, Patch attached. We are in a chicken and egg situation. The controller needs data to cause the clock to start and the first command sent by the mmc layer is CMD0 -- mmc_go_idle(). This is sent without the eMMC chip seeing the 74 clocks but since there are NOW clocks the chip see's this. It is not able to parse the command and we are struck. Okay, and some host-ops-generate_initial_74_clocks() could help you out, it seems. If it is a controller specific issue, the approach seems in general sensible to me, unless I am missing some details. Regards, Wolfram -- Pengutronix e.K. | Wolfram Sang| Industrial Linux Solutions | http://www.pengutronix.de/ | signature.asc Description: Digital signature
Re: [PATCH] mmc: add SDHCI driver for STM platforms (V2)
On 09/22/2010 04:12 PM, Wolfram Sang wrote:
Hi Peppe,
1) I've already a patch to add the suspend/resume in the sdhci_pltfm
driver. Please note this is mandatory for me.
Great, improvements to the generic pltfm-driver are most welcome!
Good! I'm happy to contribute on it. I'll start soon and post the
patches asap.
Note: I'd like to look at the wake-up on card that should be nice to
have in the future. IIUC, it is missing in the sdhci. Please correct
me if I'm wrong.
It is not in sdhci yet. Please make sure to send very early RFC-patches
here, so we can see what you are aiming for.
OK!
2) sdhci_pltfm_data has a quirk flag but IMO the quirk macros, that
currently are in linux-2.6/drivers/mmc/host/sdhci.h, should be
moved in a separate file:
include/linux/mmc/sdhci.h or
include/linux/mmc/sdhci-quirk.h or ...
I don't know if it has been already done but I could create a patch
for this too. Let me know the name convention you like, eventually.
Otherwise, in my platforms, where I need to set this flag (e.g. the
sdhci-stm needs: SDHCI_QUIRK_NO_ENDATTR_IN_NOPDESC), I should include
drivers/mmc/host/sdhci.h?!? I don't like it :-(
Please, correct me if I've missed something.
You are correct. So far, all users of the quirk-flags happened to be
inside the host-directory. If you happen to have a controller which only
needs quirk-flags and no custom functions (congrats! ;)), then those
quirk-flags really need to be moved, so your platform code can find it.
I'd go for sdhci.h as the name. Be sure to catch all users of the quirks
to include your new file.
OK! I like shdci.h too ;-)
I'll pay attention to add this header file in the other drivers based on
sdhci.
3) In the end, another hook could be added in the sdhci_pltfm_data to
invoke specific own functions for claiming resources etc.
For example, I need an extra callback to invoke the STM pad manager
that's used for managing clocks, PIO lines and syscfg registers.
I'm thinking about something like this:
struct sdhci_pltfm_data {
struct sdhci_ops *ops;
unsigned int quirks;
int (*init)(struct sdhci_host *host);
void (*exit)(struct sdhci_host *host);
int (*claim_resource)(struct platform_device *pdev);
|
|_ we can use another name.
};
And init() is too late?
No it's not late but I need the dev structure from the platform_device.
We could add the struct device dev; in the sdhci_host structure
instead of.
In this case the sdhci_host should be moved within the new
include/linux/mmc/sdhci.h file.
Indeed, this could make sense because the drivers/mmc/host/sdhci.h will
only have the HW register configuration. Shared macros (quirks) and
structures among sdhci driver based could be moved in
include/linux/mmc/sdhci.h header.
What do you think?
Regards,
Peppe
--
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/4] omap4 hsmmc: Card detect and Register offset handling
The patch series is based on mainline 2.6.36-rc5. The series is tested on OMAP3430SDP and OMAP4430SDP and has dependency on http://www.mail-archive.com/linux-o...@vger.kernel.org/msg34718.html V2: http://www.mail-archive.com/linux-o...@vger.kernel.org/msg35135.html V1: http://www.mail-archive.com/linux-o...@vger.kernel.org/msg34040.html Kishore Kadiyala (3): omap4 hsmmc : Adding card detect support for MMC1 omap4 hsmmc: Register offset handling omap4 hsmmc: Update ocr mask for MMC2 for regulator to use Benoit Cousson (1); omap4 hsmmc: Fix the init if CONFIG_MMC_OMAP_HS is not set arch/arm/mach-omap2/board-4430sdp.c | 16 ++- arch/arm/mach-omap2/devices.c |8 +-- arch/arm/mach-omap2/hsmmc.c |4 ++ arch/arm/plat-omap/include/plat/mmc.h |3 + drivers/mfd/twl6030-irq.c | 72 + drivers/mmc/host/omap_hsmmc.c | 18 +++- include/linux/i2c/twl.h | 31 ++ 7 files changed, 143 insertions(+), 9 deletions(-) -- 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 3/4] omap4 hsmmc: Register offset handling
In OMAP4, as per new PM programming model, the legacy registers
which were there in OMAP3 are all shifted by 0x100 while new one's
are added from offset 0 to 0x10.
For OMAP4, the register offset appending of 0x100 done in devices.c
currently, is moved to driver file.This change fits in for current
implementation as well as once the driver undergoes hwmod adaptation.
Cc: Kevin Hilman khil...@deeprootsystems.com
Cc: Benoit Cousson b-cous...@ti.com
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/devices.c |8 +++-
arch/arm/mach-omap2/hsmmc.c |4
arch/arm/plat-omap/include/plat/mmc.h |3 +++
drivers/mmc/host/omap_hsmmc.c |2 ++
4 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 2dbb265..bb7ec13 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -745,13 +745,13 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data
**mmc_data,
case 3:
if (!cpu_is_omap44xx())
return;
- base = OMAP4_MMC4_BASE + OMAP4_MMC_REG_OFFSET;
+ base = OMAP4_MMC4_BASE;
irq = OMAP44XX_IRQ_MMC4;
break;
case 4:
if (!cpu_is_omap44xx())
return;
- base = OMAP4_MMC5_BASE + OMAP4_MMC_REG_OFFSET;
+ base = OMAP4_MMC5_BASE;
irq = OMAP44XX_IRQ_MMC5;
break;
default:
@@ -762,10 +762,8 @@ void __init omap2_init_mmc(struct omap_mmc_platform_data
**mmc_data,
size = OMAP2420_MMC_SIZE;
name = mmci-omap;
} else if (cpu_is_omap44xx()) {
- if (i 3) {
- base += OMAP4_MMC_REG_OFFSET;
+ if (i 3)
irq += OMAP44XX_IRQ_GIC_START;
- }
size = OMAP4_HSMMC_SIZE;
name = mmci-omap-hs;
} else {
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index c8f647b..49d76a7 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -261,6 +261,10 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info
*controllers)
mmc-slots[0].wires = c-wires;
mmc-slots[0].internal_clock = !c-ext_clock;
mmc-dma_mask = 0x;
+ if (cpu_is_omap44xx())
+ mmc-reg_offset = OMAP4_MMC_REG_OFFSET;
+ else
+ mmc-reg_offset = 0;
mmc-get_context_loss_count = hsmmc_get_context_loss;
diff --git a/arch/arm/plat-omap/include/plat/mmc.h
b/arch/arm/plat-omap/include/plat/mmc.h
index 9b89ec6..4e6ef07 100644
--- a/arch/arm/plat-omap/include/plat/mmc.h
+++ b/arch/arm/plat-omap/include/plat/mmc.h
@@ -71,6 +71,9 @@ struct omap_mmc_platform_data {
u64 dma_mask;
+ /* Register offset deviation */
+ u16 reg_offset;
+
struct omap_mmc_slot_data {
/* 4 wire signaling is optional, and is used for SD/SDIO/HSMMC;
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index a51894d..8cb007c 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -2009,6 +2009,8 @@ static int __init omap_hsmmc_probe(struct platform_device
*pdev)
if (res == NULL || irq 0)
return -ENXIO;
+ res-start += pdata-reg_offset;
+ res-end += pdata-reg_offset;
res = request_mem_region(res-start, res-end - res-start + 1,
pdev-name);
if (res == NULL)
--
1.7.0.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 4/4] omap4 hsmmc: Update ocr mask for MMC2 for regulator to use
On OMAP4, MMC2 controller has eMMC which draws power from VAUX regulator
on TWL. Though the eMMC supports dual voltage[1.8v/3v] as per ocr register,
its VCC is fixed at 3V for operation. With this once the mmc core selects
the minimum voltage[1.8] supported based on the ocr value read from OCR
register,
eMMC will not get detected. Thus the platform data for MMC2 is updated with ocr
mask and same will be communicated to core which will set the regulator to
always operate at 3V when ever turned ON.
Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
---
arch/arm/mach-omap2/board-4430sdp.c |1 +
drivers/mmc/host/omap_hsmmc.c | 12
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-4430sdp.c
b/arch/arm/mach-omap2/board-4430sdp.c
index ac8541c..9fd1044 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -202,6 +202,7 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_cd= -EINVAL,
.gpio_wp= -EINVAL,
.nonremovable = true,
+ .ocr_mask = MMC_VDD_29_30,
},
{} /* Terminator */
};
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index 8cb007c..f629acf 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -364,6 +364,7 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
{
struct regulator *reg;
int ret = 0;
+ int ocr_value = 0;
switch (host-id) {
case OMAP_MMC1_DEVID:
@@ -396,6 +397,17 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
}
} else {
host-vcc = reg;
+ ocr_value = mmc_regulator_get_ocrmask(reg);
+ if (!mmc_slot(host).ocr_mask) {
+ mmc_slot(host).ocr_mask = ocr_value;
+ } else {
+ if (!(mmc_slot(host).ocr_mask ocr_value)) {
+ pr_err(MMC%d ocrmask %x is not supported\n,
+ host-id, mmc_slot(host).ocr_mask);
+ mmc_slot(host).ocr_mask = 0;
+ return -EINVAL;
+ }
+ }
mmc_slot(host).ocr_mask = mmc_regulator_get_ocrmask(reg);
/* Allow an aux regulator */
--
1.7.0.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] OMAP4: HSMMC cmd line reset change
Hi Madhu, On Wed, Sep 22, 2010 at 12:13:51PM -0500, Madhusudhan wrote: Can you please drop this patch? Sorry, I spoke bit too early on this patch. I need to sort out some stuff internally (seems like it will not be released as an errata). I will post a revised version a bit later. No problem, I dropped this after seeing Tony's comments. I'll keep an eye out for a new patch with his ACK. Thanks, -- 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] sdhci: print out controller name for register debug
Hi Philip,
On Wed, Sep 22, 2010 at 03:25:13PM -0700, Philip Rakity wrote:
Subject: [PATCH] sdhci: print out controller name for register debug
In a multi-controller environment it is helpful to know which controller
has problems.
Signed-off-by: Philip Rakity prak...@marvell.com
---
drivers/mmc/host/sdhci.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index e2b1f32..6b8ca32 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -47,7 +47,8 @@ static void sdhci_finish_command(struct sdhci_host *);
static void sdhci_dumpregs(struct sdhci_host *host)
{
- printk(KERN_DEBUG DRIVER_NAME : == REGISTER DUMP
==\n);
+ printk(KERN_DEBUG DRIVER_NAME : === REGISTER DUMP
(%s)===\n,
+ mmc_hostname(host-mmc));
printk(KERN_DEBUG DRIVER_NAME : Sys addr: 0x%08x | Version: 0x%08x\n,
sdhci_readl(host, SDHCI_DMA_ADDRESS),
Thanks, pushed to mmc-next; I'm surprised no-one noticed this before. :)
--
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 v3 1/4] omap4 hsmmc: Adding card detect support for MMC1
Hi Hari,
On Thu, Sep 23, 2010 at 1:19 AM, Kanigeri, Hari h-kanige...@ti.com wrote:
Kishore,
+int twl6030_mmc_card_detect(struct device *dev, int slot)
+{
+ int ret = -EIO;
+ u8 read_reg = 0;
+ struct platform_device *pdev = to_platform_device(dev);
+
+ switch (pdev-id) {
+ case 0:
+ /*
+ * BIT0 of REG_MMC_CTRL
+ * 0 - Card not present ,1 - Card present
+ */
+ ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, read_reg,
+ TWL6030_MMCCTRL);
+ if (ret = 0)
+ ret = read_reg STS_MMC;
+ break;
nitpick: may be you don't need a switch statement for only one case.
From future perspective,since there are 5 MMC controllers on OMAP4
and current patch supports card detect feature only for one controller i.e MMC1
as of now. Once the interfaces connected on the remaining 4 MMC controllers
are defined further additions will be required for respective cases.
snip
Regards,
Kishore
--
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
