Re: [PATCH] mmc: add SDHCI driver for STM platforms (V2)

2010-09-22 Thread Peppe CAVALLARO 
On 09/22/2010 04:35 PM, Peppe CAVALLARO wrote:
> 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?


Hello!
I've just something working on my ST Linux box (ST40 CPU).
I mean that I'm using the sdhci-pltfm driver with some of the
modifications discussed in this thread.

I'll post some patches asap.

Pepep
--
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

2010-09-22 Thread kishore kadiyala 
Hi Hari,

On Thu, Sep 23, 2010 at 1:19 AM, Kanigeri, Hari  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.



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

Re: [PATCH] sdhci: print out controller name for register debug

2010-09-22 Thread Chris Ball 
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 
> ---
>  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  
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

[PATCH] sdhci: print out controller name for register debug

2010-09-22 Thread Philip Rakity 
>From 928a3fef14d44f4179cfe075380ad760720fea9e Mon Sep 17 00:00:00 2001
From: Philip Rakity 
Date: Wed, 22 Sep 2010 15:22:25 -0700
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 
---
 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),
-- 
1.6.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 v3 1/4] omap4 hsmmc: Adding card detect support for MMC1

2010-09-22 Thread Kanigeri, Hari 
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.

> + default:
> + pr_err("Unkown MMC controller %d in %s\n", pdev->id,
> __func__);


Thank you,
Best regards,
Hari


--
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 2/4] omap4 hsmmc: Fix the init if CONFIG_MMC_OMAP_HS is not set

2010-09-22 Thread Sergei Shtylyov 

Hello.

kishore kadiyala wrote:


From: Benoit Cousson 



Avoid possible crash if CONFIG_MMC_OMAP_HS is not set



Signed-off-by: Benoit Cousson 
Signed-off-by: Kishore Kadiyala 
---
 arch/arm/mach-omap2/board-4430sdp.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index a49f285..ac8541c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -240,8 +240,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device 
*dev)

 static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
 {
-   struct omap_mmc_platform_data *pdata = dev->platform_data;
+   struct omap_mmc_platform_data *pdata;

+   /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
+   if (!dev) {
+   pr_err("Failed omap4_twl6030_hsmmc_set_late_init\n");


   pr_err("Failed %s\n", __func__);

WBR, Sergei
--
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

2010-09-22 Thread Chris Ball 
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  
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] OMAP4: HSMMC cmd line reset change

2010-09-22 Thread Madhusudhan 


> -Original Message-
> From: Tony Lindgren [mailto:t...@atomide.com]
> Sent: Tuesday, September 21, 2010 9:47 AM
> To: Madhusudhan
> Cc: c...@laptop.org; linux-mmc@vger.kernel.org; linux-o...@vger.kernel.org;
> santosh.shilim...@ti.com
> Subject: Re: [PATCH] OMAP4: HSMMC cmd line reset change
> 
> * Madhusudhan  [100920 09:06]:
> > >
> > > Please don't use cpu_is_omap tests in the drivers, drivers
> > > should be generic.
> > >
> > > Instead, just pass a feature flag in the platform_data for this
> > > feature like HSMMC_REVERSE_RESET_LOGIC or similar.
> > >
> >
> > This is not a feature. It is like an ERRATA fix. I am yet to receive an
> > errata number though. How about dealing with this like an errata fix
> similar
> > to the way in arch/mach-omap2/serial.c done for the uart case?
> 
> Yes setting some HSMMC_ERRATA_XYZ flag works too.
> 
> > The mmc ip revision will not help because it really does not change to
> > distinguish such issues.
> 
> OK. Then I guess your only option is to pass the errata flag in
> the platform_data.
> 
Chris,

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.

Regards,
Madhu

> Regards,
> 
> Tony

--
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

2010-09-22 Thread kishore kadiyala 
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 
---
 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

[PATCH v3 3/4] omap4 hsmmc: Register offset handling

2010-09-22 Thread kishore kadiyala 
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 
Cc: Benoit Cousson 
Signed-off-by: Kishore Kadiyala 
---
 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 1/4] omap4 hsmmc: Adding card detect support for MMC1

2010-09-22 Thread kishore kadiyala 
Adding card detect callback function and card detect configuration
function for MMC1 Controller on OMAP4.

Card detect configuration function does initial configuration of the
MMC Control & PullUp-PullDown registers of Phoenix.

For MMC1 Controller, card detect interrupt source is
twl6030 which is non-gpio. The card detect call back function provides
card present/absent status by reading MMC Control register present
on twl6030.

Since OMAP4 doesn't use any GPIO line as used in OMAP3 for card detect,
the suspend/resume initialization which was done in omap_hsmmc_gpio_init
previously is moved to the probe thus making it generic for both OMAP3 & OMAP4.

Signed-off-by: Kishore Kadiyala 
---
 arch/arm/mach-omap2/board-4430sdp.c |7 +++-
 drivers/mfd/twl6030-irq.c   |   72 +++
 drivers/mmc/host/omap_hsmmc.c   |4 +-
 include/linux/i2c/twl.h |   31 +++
 4 files changed, 111 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index 9447644..a49f285 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -227,9 +227,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device 
*dev)
struct omap_mmc_platform_data *pdata = dev->platform_data;

/* Setting MMC1 Card detect Irq */
-   if (pdev->id == 0)
+   if (pdev->id == 0) {
+   ret = twl6030_mmc_card_detect_config();
+   if (ret)
+   pr_err("Failed configuring MMC1 card detect\n");
pdata->slots[0].card_detect_irq = TWL6030_IRQ_BASE +
MMCDETECT_INTR_OFFSET;
+   pdata->slots[0].card_detect = twl6030_mmc_card_detect;
+   }
return ret;
 }

diff --git a/drivers/mfd/twl6030-irq.c b/drivers/mfd/twl6030-irq.c
index 10bf228..d065899 100644
--- a/drivers/mfd/twl6030-irq.c
+++ b/drivers/mfd/twl6030-irq.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 

 /*
  * TWL6030 (unlike its predecessors, which had two level interrupt handling)
@@ -223,6 +224,77 @@ 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 */
+   twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+   REG_INT_MSK_LINE_B);
+   twl6030_interrupt_unmask(TWL6030_MMCDETECT_INT_MASK,
+   REG_INT_MSK_STS_B);
+   /*
+* Intially Configuring MMC_CTRL for receving interrupts &
+* Card status on TWL6030 for MMC1
+*/
+   ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_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, ®_val,
+   TWL6030_CFG_INPUT_PUPD3);
+   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);
+   if (ret < 0) {
+   pr_err("twl6030: Failed to write CFG_INPUT_PUPD3, error %d\n",
+   ret);
+   return ret;
+   }
+   return 0;
+}
+EXPORT_SYMBOL(twl6030_mmc_card_detect_config);
+
+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;
+   default:
+   pr_err("Unkown MMC controller %d in %s\n", pdev->id, __func__);
+   }
+   return ret;
+}
+EXPORT_SYMBOL(twl6030_mmc_card_detect);
+
 int twl6030_init_irq(int irq_num, unsigned irq_base, u

[PATCH v3 2/4] omap4 hsmmc: Fix the init if CONFIG_MMC_OMAP_HS is not set

2010-09-22 Thread kishore kadiyala 
From: Benoit Cousson 

Avoid possible crash if CONFIG_MMC_OMAP_HS is not set

Signed-off-by: Benoit Cousson 
Signed-off-by: Kishore Kadiyala 
---
 arch/arm/mach-omap2/board-4430sdp.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/arm/mach-omap2/board-4430sdp.c 
b/arch/arm/mach-omap2/board-4430sdp.c
index a49f285..ac8541c 100644
--- a/arch/arm/mach-omap2/board-4430sdp.c
+++ b/arch/arm/mach-omap2/board-4430sdp.c
@@ -240,8 +240,14 @@ static int omap4_twl6030_hsmmc_late_init(struct device 
*dev)

 static __init void omap4_twl6030_hsmmc_set_late_init(struct device *dev)
 {
-   struct omap_mmc_platform_data *pdata = dev->platform_data;
+   struct omap_mmc_platform_data *pdata;

+   /* dev can be null if CONFIG_MMC_OMAP_HS is not set */
+   if (!dev) {
+   pr_err("Failed omap4_twl6030_hsmmc_set_late_init\n");
+   return;
+   }
+   pdata = dev->platform_data;
pdata->init =   omap4_twl6030_hsmmc_late_init;
 }

-- 
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 0/4] omap4 hsmmc: Card detect and Register offset handling

2010-09-22 Thread kishore kadiyala 
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

Re: [PATCH] mmc: add SDHCI driver for STM platforms (V2)

2010-09-22 Thread Peppe CAVALLARO 
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

Re: [PATCH] mmc: add SDHCI driver for STM platforms (V2)

2010-09-22 Thread Wolfram Sang 
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!

>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.

> 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.

> 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?

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)

2010-09-22 Thread Peppe CAVALLARO 
On 09/21/2010 11:44 AM, Wolfram Sang wrote:
> On Tue, Sep 21, 2010 at 11:21:48AM +0200, Peppe CAVALLARO wrote:
>> On 09/20/2010 10:38 AM, Wolfram Sang wrote:
>>> On Mon, Sep 20, 2010 at 10:20:17AM +0200, Giuseppe CAVALLARO wrote:
 This patch adds the Arasan MMC/SD/SDIO driver
 for the STM ST40 platforms. It is based on the
 SDHCI driver.
 It has been tested on the STx7106/STx7108/STx5289
 platforms.

 Signed-off-by: Giuseppe Cavallaro 
>>>
>>> Looks to me that you could just use the sdhci-pltfm driver?
>>>
>>
>> Hello Wolfram,
>> some weeks ago I discussed about this driver and I reworked it according
>> to the changes required. This is the meaning of this patch.
>>
>> At any rate, I can look at the sdhci-pltfm driver: at first glance, it
>> could actually help on our platforms. This could take a while.
> 
> Sorry, I didn't spot the first version of your patch. I would have said
> the same then, simply to avoid the code duplication. Oh, and no need to
> hurry from my side :)

Hi Wolfran,
I agree that it's a good idea to reduce duplicated code when possible
(i.e. the probe function that, at first glance, is almost equal for
several sdhci drivers based).

Maybe, I could use on our ST boxes the sdhci_pltfm but I have the
following questions and ideas. Welcome advice and feedback.

1) I've already a patch to add the suspend/resume in the sdhci_pltfm
   driver. Please note this is mandatory for me.

   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.

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.

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.
   };

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

RE: [PATCH] mmc: failure of block read wait for long time

2010-09-22 Thread Ghorai, Sukumar 
Chris,

> -Original Message-
> From: Chris Ball [mailto:c...@laptop.org]
> Sent: Wednesday, September 22, 2010 6:13 PM
> To: Ghorai, Sukumar
> Cc: Adrian Hunter; linux-mmc@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; Russell King - ARM Linux
> Subject: Re: [PATCH] mmc: failure of block read wait for long time
> 
> On Wed, Sep 22, 2010 at 11:02:08AM +0530, Ghorai, Sukumar wrote:
> > Would you please review and merge this patch [1] (attached too)?
> > [1] http://comments.gmane.org/gmane.linux.kernel.mmc/2714
> 
> I've been following the thread.  I believe Adrian has NACKed this patch,
> by saying "It is absolutely unacceptable to return I/O errors to the
> upper layers for segments that do not have errors."

[Ghorai] 
I think Russell also mentioned his opinion. Would you please add your idea too?

1. I would prefer Adrian to explain again what this statement means, in the 
context - data read fail and how we make it success? 

2. if data read fail for sector(x) why we have to try for sector(x+1, ..x+n)?

3. how to inform reader function which sector having the valid data out of 
(1...n) sectors.

4. do we have any driver/code in Linux or any other os, which give inter-leave 
data and return as success?  

> 
> I think it's possible to merge patches to improve the situation (such
> as the idea of noticing a card disappearing earlier), but your initial
> patch is not the patch to do that.  You should continue to work with
> Adrian -- when he's happy that a patch does not break the semantics
> above, we can consider merging it.
> 
> Thanks,
> 
> --
> Chris Ball  
> 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: failure of block read wait for long time

2010-09-22 Thread Chris Ball 
On Wed, Sep 22, 2010 at 11:02:08AM +0530, Ghorai, Sukumar wrote:
> Would you please review and merge this patch [1] (attached too)?
> [1] http://comments.gmane.org/gmane.linux.kernel.mmc/2714

I've been following the thread.  I believe Adrian has NACKed this patch,
by saying "It is absolutely unacceptable to return I/O errors to the
upper layers for segments that do not have errors."

I think it's possible to merge patches to improve the situation (such
as the idea of noticing a card disappearing earlier), but your initial
patch is not the patch to do that.  You should continue to work with
Adrian -- when he's happy that a patch does not break the semantics
above, we can consider merging it.

Thanks,

-- 
Chris Ball  
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 v2 1/4] omap4 hsmmc: Adding card detect support for MMC1

2010-09-22 Thread kishore kadiyala 
Hi balbi,

On Wed, Sep 22, 2010 at 2:21 PM, Felipe Balbi  wrote:
> 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 ?

It can only be a 6030 class.
as twl6030_mmc_card_detect_config is called only in board file I can
remove the check.

>
>> +       /*
>> +        * Intially Configuring MMC_CTRL for receving interrupts &
>> +        * Card status on TWL6030 for MMC1
>> +        */
>> +       ret = twl_i2c_read_u8(TWL6030_MODULE_ID0, ®_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, ®_val,
>> +                                               TWL6030_CFG_INPUT_PUPD3);
>
> is this a gpio ? Could gpiolib take care of this ?

This is not a gpio but an interrupt line from twl6030 to MMC controller

>
>> +       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.
This is not a gpio
>
>> +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);

ok will use this .

>
>> 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 ?

I've just moved the initialization of suspend & resume which was
previously done in omap_hsmmc_gpio_init.
Ok will update in the log

>
>> @@ -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 ??

ok will update with pr_debug

>
>> +/* 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.

ok will update with pr_debug

>
> --
> balbi

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

Re: [PATCH 2/4] mmc: sdhci-pltfm: move .h-file into apropriate subdir

2010-09-22 Thread Wolfram Sang 
On Wed, Sep 22, 2010 at 02:20:11AM +0100, Ben Dooks wrote:
> On Tue, Sep 21, 2010 at 02:30:08PM +0200, Wolfram Sang wrote:
> > Make use of the mmc-directory.
> > 
> > Signed-off-by: Wolfram Sang 
> > ---
> >  drivers/mmc/host/sdhci-cns3xxx.c |2 +-
> >  drivers/mmc/host/sdhci-pltfm.c   |2 +-
> >  drivers/mmc/host/sdhci-pltfm.h   |2 +-
> >  include/linux/mmc/sdhci-pltfm.h  |   35 +++
> >  include/linux/sdhci-pltfm.h  |   35 ---
> 
> hmm, you lost rename detection... best enable it to make these diffs clearer.

Do you mean just for the diffstat or for the whole patch? I am
reluctant to do the latter because you can't apply patches with plain
'patch' anymore. Or are git-patches considered standard meanwhile?

Regards,

   Wolfram

-- 
Pengutronix e.K.   | Wolfram Sang|
Industrial Linux Solutions | http://www.pengutronix.de/  |


signature.asc
Description: Digital signature

Re: [PATCH] sdhci: allow for eMMC 74 clock generation by controller

2010-09-22 Thread Wolfram Sang 
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 v2 1/4] omap4 hsmmc: Adding card detect support for MMC1

2010-09-22 Thread Felipe Balbi 

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, ®_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, ®_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

2010-09-22 Thread Adrian Hunter 

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 Rakity
Subject: [PATCH] sdhci: allow for eMMC 74 clock generation by controller
Signed-off-by: Philip Rakity

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