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

2010-09-29 Thread Ghorai, Sukumar 


 -Original Message-
 From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
 Sent: Wednesday, September 29, 2010 1:35 AM
 To: Ghorai, Sukumar
 Cc: Chris Ball; 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 28/09/10 21:59, ext Ghorai, Sukumar wrote:
  Adrian,
 
  -Original Message-
  From: Adrian Hunter [mailto:adrian.hun...@nokia.com]
  Sent: Wednesday, September 29, 2010 12:03 AM
  To: Ghorai, Sukumar
  Cc: Chris Ball; 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 28/09/10 18:03, Ghorai, Sukumar wrote:
  Chris and Adrian,
 
  [..snip..]
 
  Chris and Adrian,
 
  [..snip..]
 
  -Original Message-
  [..snip..]
  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?
 
  Because I/O requests are made up of segments and every segment can be a
  success or failure.
  [Ghorai] don't you conflict your self for the comments you provide for
 following patch -
  [PATCH] MMC: Refine block layer waiting for card state
  [Adrian].. then why wait for lots of errors before doing it.
 
 That patch needs a lot more work.  Please do not base your
 understanding on it.
[Ghorai] it's the similar problem when read fails and you also suggest how to 
break early. 

 
 
 
 
  2. if data read fail for sector(x) why we have to try for
  sector(x+1, ..x+n)?
 
  See answer to q. 1
 
 
  3. how to inform reader function which sector having the valid data
  out
  of
  (1...n) sectors.
 
  __blk_end_request() does that
  [Ghorai] not true. Please check the code again.
 
 Every time you call __blk_end_request() you specify success or
 failure for the specified numbers of bytes starting from the
 last position.
 
 
 
 
  4. do we have any driver/code in Linux or any other os, which give
  inter-
  leave data and return as success?
 
  Here is the problem with that question.  The *same* I/O request
  can have data for *different*sources.
  [Ghorai] File system does not do that and can you test that once how
 data comes from difference soure?
  Also conflicting your-self for the input you gave for the patch and as -
  [PATCH] MMC: Refine block layer waiting for card state
  [Adrian].. then why wait for lots of errors before doing it.
 
 
 
  [Ghorai] please reply with your input on my/ Russell's suggestion?
  [Ghorai] any input?
 
  I have a question for you.  What use cases do you want to address
 - other than card removal?
 
 Please answer this question.
[Ghorai] say data error (including timeout), ECC error ..

 
  [Ghorai]
  1. can you reply to original input form Russell's on the same thread?
 
 Russell did not make any suggestions.  He pointed out that some drivers,
 but not all (and not omap_hsmmc), indicate how many bytes were transferred.
 However it is difficult for me to explain how this will or will not help
 if
 you won't give more information about your use cases.
[Ghorai] any driver give the interleave data to apps? Can you test if you give 
the interleave data to FS how it behave? Even it can cause the system fault. 
And will spend day and night to find out the issue in which module - memory, 
host, card?

 
 For example, in the case of ECC errors, there are usually only a few
 blocks
 in error, so only a few of the retries timeout, so retrying is not slow.
 That is very different in the case the card has been removed, or has
 become
 unresponsive - in which case every retry fails and has to timeout.
 
 I still plan to address the card removal issue, but I am very busy, so
 don't
 hold your breath.
[Ghorai] so I will wait for your patch forever.
 
  2. can you check if you return the interleave data to FS how it can
 behave?
[Ghorai] any time?
  3. still you don't have any reference driver which provide the
 interleave data.
 
 A single I/O request could have resulted from merging I/O requests from
 two *different* file systems on two *different* partitions.  I provide as
 reference every single linux file system.
[Ghorai] Filesystem never marge two IO in a single request, and if say cache 
did not support (sync mode)?

[Ghorai] thanks that you want to provide the solution in different way and in 
different patch. I will

Re: [PATCH v4 1/4] omap4 hsmmc: Adding card detect support for MMC1

2010-09-29 Thread kishore kadiyala 
Gentle Reminder !

Regards,
Kishore

On Tue, Sep 28, 2010 at 12:22 PM, kishore kadiyala
kishorek.kadiy...@gmail.com wrote:
 Hi Samuel,

 Could you please review this patch which touches mfd/twl6030-irq.c for
 card detect support
 of MMC1 controller on OMAP4.

 Regards,
 Kishore

 On Mon, Sep 27, 2010 at 1:25 PM, kishore kadiyala
 kishorek.kadiy...@gmail.com wrote:
 Cc: Samuel Ortiz sa...@linux.intel.com

 On Fri, Sep 24, 2010 at 10:43 PM, kishore kadiyala
 kishore.kadiy...@ti.com wrote:
 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.

 Cc: Tony Lindgren t...@atomide.com
 Cc: Andrew Morton a...@linux-foundation.org
 Cc: Madhusudhan Chikkature madhu...@ti.com
 Cc: Adrian Hunter adrian.hun...@nokia.com
 Signed-off-by: Kishore Kadiyala kishore.kadiy...@ti.com
 ---
  arch/arm/mach-omap2/board-4430sdp.c |    7 +++-
  drivers/mfd/twl6030-irq.c           |   73 
 +++
  drivers/mmc/host/omap_hsmmc.c       |    4 +-
  include/linux/i2c/twl.h             |   31 +++
  4 files changed, 112 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..2d3bb82 100644
 --- a/drivers/mfd/twl6030-irq.c
 +++ b/drivers/mfd/twl6030-irq.c
 @@ -36,6 +36,7 @@
  #include linux/irq.h
  #include linux/kthread.h
  #include linux/i2c/twl.h
 +#include linux/platform_device.h

  /*
  * TWL6030 (unlike its predecessors, which had two level interrupt handling)
 @@ -223,6 +224,78 @@ 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, 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);
 +       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;
 +}

Re: [PATCH 2/4] esdhc-2 mx51: Modify the MSL codes when upstreaming fsl esdhc driver

2010-09-29 Thread Uwe Kleine-König 
Hello Richard,

On Fri, Sep 24, 2010 at 11:54:25AM +0800, Richard Zhu wrote:
 Modify the machine specific codes and add the eSDHC1 and eSDHC2 support
 on MX51 BBG platform.
 IOMUX, CLOCK, register the device.
 
 Signed-off-by: Richard Zhu r65...@freescale.com
 ---
  arch/arm/mach-mx5/board-mx51_babbage.c  |   38 ++
I think board changes should go in a seperate patch

  arch/arm/mach-mx5/clock-mx51.c  |  193 
 +++
  arch/arm/mach-mx5/devices.c |   46 +++
  arch/arm/mach-mx5/devices.h |2 +
  arch/arm/plat-mxc/include/mach/iomux-mx51.h |   33 +++--
  5 files changed, 298 insertions(+), 14 deletions(-)
 
 diff --git a/arch/arm/mach-mx5/board-mx51_babbage.c 
 b/arch/arm/mach-mx5/board-mx51_babbage.c
 index 6e384d9..e79f8a1 100644
 --- a/arch/arm/mach-mx5/board-mx51_babbage.c
 +++ b/arch/arm/mach-mx5/board-mx51_babbage.c
 @@ -17,6 +17,7 @@
  #include linux/delay.h
  #include linux/io.h
  #include linux/fsl_devices.h
 +#include linux/sdhci-pltfm.h
  
  #include mach/common.h
  #include mach/hardware.h
 @@ -24,6 +25,7 @@
  #include mach/iomux-mx51.h
  #include mach/i2c.h
  #include mach/mxc_ehci.h
 +#include mach/mmc.h
  
  #include asm/irq.h
  #include asm/setup.h
 @@ -33,6 +35,8 @@
  
  #include devices.h
  
 +#define BABBAGE_SDHCI1_WP(0*32 + 1)  /* GPIO_1_1 */
 +#define BABBAGE_SDHCI2_WP(0*32 + 5)  /* GPIO_1_5 */
  #define BABBAGE_USB_HUB_RESET(0*32 + 7)  /* GPIO_1_7 */
  #define BABBAGE_USBH1_STP(0*32 + 27) /* GPIO_1_27 */
  #define BABBAGE_PHY_RESET (1*32 +5)  /* GPIO_2_5 */
 @@ -93,6 +97,24 @@ static struct pad_desc mx51babbage_pads[] = {
  
   /* USB HUB reset line*/
   MX51_PAD_GPIO_1_7__GPIO_1_7,
 +
 + /* SDHCI1 IOMUX */
 + MX51_PAD_SD1_CMD__SD1_CMD,
 + MX51_PAD_SD1_CLK__SD1_CLK,
 + MX51_PAD_SD1_DATA0__SD1_DATA0,
 + MX51_PAD_SD1_DATA1__SD1_DATA1,
 + MX51_PAD_SD1_DATA2__SD1_DATA2,
 + MX51_PAD_SD1_DATA3__SD1_DATA3,
 + MX51_PAD_GPIO_1_1__GPIO_1_1,
 +
 + /* SDHCI2 IOMUX */
 + MX51_PAD_SD2_CMD__SD2_CMD,
 + MX51_PAD_SD2_CLK__SD2_CLK,
 + MX51_PAD_SD2_DATA0__SD2_DATA0,
 + MX51_PAD_SD2_DATA1__SD2_DATA1,
 + MX51_PAD_SD2_DATA2__SD2_DATA2,
 + MX51_PAD_SD2_DATA3__SD2_DATA3,
 + MX51_PAD_GPIO_1_5__GPIO_1_5,
  };
  
  /* Serial ports */
 @@ -240,6 +262,20 @@ static int __init babbage_otg_mode(char *options)
  }
  __setup(otg_mode=, babbage_otg_mode);
  
 +struct sdhci_pltfm_data mmc1_data = {
 + /* Board specified max bus width */
 + .caps = MMC_CAP_4_BIT_DATA,
 + /* GPIO pin number that used as the Write Protect */
This sentence no (complete) verb.

 + .wp_gpio = BABBAGE_SDHCI1_WP,
 +};
 +
 +struct sdhci_pltfm_data mmc2_data = {
 + /* Board specified max bus width */
 + .caps = MMC_CAP_4_BIT_DATA,
 + /* GPIO pin number that used as the Write Protect */
 + .wp_gpio = BABBAGE_SDHCI2_WP,
 +};
 +
  /*
   * Board specific initialization.
   */
 @@ -255,6 +291,8 @@ static void __init mxc_board_init(void)
   mxc_register_device(mxc_i2c_device0, babbage_i2c_data);
   mxc_register_device(mxc_i2c_device1, babbage_i2c_data);
   mxc_register_device(mxc_hsi2c_device, babbage_hsi2c_data);
 + mxc_register_device(mxcsdhc1_device, mmc1_data);
 + mxc_register_device(mxcsdhc2_device, mmc2_data);
  
   if (otg_mode_host)
   mxc_register_device(mxc_usbdr_host_device, dr_utmi_config);
 diff --git a/arch/arm/mach-mx5/clock-mx51.c b/arch/arm/mach-mx5/clock-mx51.c
 index 6af69de..3526fd3 100644
 --- a/arch/arm/mach-mx5/clock-mx51.c
 +++ b/arch/arm/mach-mx5/clock-mx51.c
 @@ -41,6 +41,35 @@ static struct clk usboh3_clk;
  
  #define MAX_DPLL_WAIT_TRIES  1000 /* 1000 * udelay(1) = 1ms */
  
 +static void __calc_pre_post_dividers(u32 div, u32 *pre, u32 *post)
 +{
Can we have a comment please about what this function does?
 + u32 min_pre, temp_pre, old_err, err;
 +
 + if (div = 512) {
 + *pre = 8;
 + *post = 64;
 + } else if (div = 8) {
declare the variables here please.

 + min_pre = (div - 1) / 64 + 1;
 + old_err = 8;
 + for (temp_pre = 8; temp_pre = min_pre; temp_pre--) {
 + err = div % temp_pre;
 + if (err == 0) {
 + *pre = temp_pre;
 + break;
 + }
 + err = temp_pre - err;
 + if (err  old_err) {
 + old_err = err;
 + *pre = temp_pre;
 + }
 + }
 + *post = (div + *pre - 1) / *pre;
 + } else if (div  8) {
This if is unnecessary as the else branch is only hit if !(div = 8)

 + *pre = div;
 + *post = 1;
 + }
 +}
 +
  static int _clk_ccgr_enable(struct clk *clk)
  {
   u32 reg;
 @@ -762,6 +791,160 @@ static struct clk kpp_clk = {

[PATCH V3 0/6] SD/MMC-driver for MX35/51 (and improvements to SDHCI)

2010-09-29 Thread Wolfram Sang 
Okay, here is the next version of my patch series. The first four are
updates/improvements for sdhci and sdhci-pltfm and are of generic interest,
too. I am still hoping for some Acked-by/Tested-by tags ;) Changes from the
previous version are mentioned in the seperate files. I should have addressed
all concerns raised. If not, please speak up.

Thanks,

   Wolfram

Wolfram Sang (6):
  mmc: sdhci-pltfm: Add structure for host-specific data
  mmc: sdhci-pltfm: move .h-file into apropriate subdir
  mmc: sdhci: introduce private get_ro
  mmc: sdhci_pltfm: pass more data on custom init-call
  mmc: sdhci-of-esdhc: factor out common stuff
  mmc: sdhci-pltfm: add pltfm-driver for imx35/51

 drivers/mmc/host/Kconfig   |   10 +++
 drivers/mmc/host/Makefile  |1 +
 drivers/mmc/host/sdhci-cns3xxx.c   |2 +-
 drivers/mmc/host/sdhci-esdhc-imx.c |  143 
 drivers/mmc/host/sdhci-esdhc.h |   81 
 drivers/mmc/host/sdhci-of-esdhc.c  |   70 ++
 drivers/mmc/host/sdhci-pltfm.c |   22 --
 drivers/mmc/host/sdhci-pltfm.h |   10 ++-
 drivers/mmc/host/sdhci.c   |   11 ++-
 drivers/mmc/host/sdhci.h   |1 +
 include/linux/mmc/sdhci-pltfm.h|   35 +
 include/linux/sdhci-pltfm.h|   35 -
 12 files changed, 310 insertions(+), 111 deletions(-)
 create mode 100644 drivers/mmc/host/sdhci-esdhc-imx.c
 create mode 100644 drivers/mmc/host/sdhci-esdhc.h
 create mode 100644 include/linux/mmc/sdhci-pltfm.h
 delete mode 100644 include/linux/sdhci-pltfm.h

--
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 2/6] mmc: sdhci-pltfm: move .h-file into apropriate subdir

2010-09-29 Thread Wolfram Sang 
Make use of the mmc-directory.

Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Acked-by: Anton Vorontsov cbouatmai...@gmail.com
---
 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 ---
 5 files changed, 38 insertions(+), 38 deletions(-)
 create mode 100644 include/linux/mmc/sdhci-pltfm.h
 delete mode 100644 include/linux/sdhci-pltfm.h

diff --git a/drivers/mmc/host/sdhci-cns3xxx.c b/drivers/mmc/host/sdhci-cns3xxx.c
index b7050b3..9ebd1d7 100644
--- a/drivers/mmc/host/sdhci-cns3xxx.c
+++ b/drivers/mmc/host/sdhci-cns3xxx.c
@@ -15,7 +15,7 @@
 #include linux/delay.h
 #include linux/device.h
 #include linux/mmc/host.h
-#include linux/sdhci-pltfm.h
+#include linux/mmc/sdhci-pltfm.h
 #include mach/cns3xxx.h
 #include sdhci.h
 #include sdhci-pltfm.h
diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index 095ca9d..e95b454 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -30,7 +30,7 @@
 #include linux/mmc/host.h
 
 #include linux/io.h
-#include linux/sdhci-pltfm.h
+#include linux/mmc/sdhci-pltfm.h
 
 #include sdhci.h
 #include sdhci-pltfm.h
diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
index 93a0319..562b929 100644
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -13,7 +13,7 @@
 
 #include linux/clk.h
 #include linux/types.h
-#include linux/sdhci-pltfm.h
+#include linux/mmc/sdhci-pltfm.h
 
 struct sdhci_pltfm_host {
struct clk *clk;
diff --git a/include/linux/mmc/sdhci-pltfm.h b/include/linux/mmc/sdhci-pltfm.h
new file mode 100644
index 000..0239bd7
--- /dev/null
+++ b/include/linux/mmc/sdhci-pltfm.h
@@ -0,0 +1,35 @@
+/*
+ * Platform data declarations for the sdhci-pltfm driver.
+ *
+ * Copyright (c) 2010 MontaVista Software, LLC.
+ *
+ * Author: Anton Vorontsov avoront...@ru.mvista.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or (at
+ * your option) any later version.
+ */
+
+#ifndef _SDHCI_PLTFM_H
+#define _SDHCI_PLTFM_H
+
+struct sdhci_ops;
+struct sdhci_host;
+
+/**
+ * struct sdhci_pltfm_data - SDHCI platform-specific information  hooks
+ * @ops: optional pointer to the platform-provided SDHCI ops
+ * @quirks: optional SDHCI quirks
+ * @init: optional hook that is called during device probe, before the
+ *driver tries to access any SDHCI registers
+ * @exit: optional hook that is called during device removal
+ */
+struct sdhci_pltfm_data {
+   struct sdhci_ops *ops;
+   unsigned int quirks;
+   int (*init)(struct sdhci_host *host);
+   void (*exit)(struct sdhci_host *host);
+};
+
+#endif /* _SDHCI_PLTFM_H */
diff --git a/include/linux/sdhci-pltfm.h b/include/linux/sdhci-pltfm.h
deleted file mode 100644
index 0239bd7..000
--- a/include/linux/sdhci-pltfm.h
+++ /dev/null
@@ -1,35 +0,0 @@
-/*
- * Platform data declarations for the sdhci-pltfm driver.
- *
- * Copyright (c) 2010 MontaVista Software, LLC.
- *
- * Author: Anton Vorontsov avoront...@ru.mvista.com
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or (at
- * your option) any later version.
- */
-
-#ifndef _SDHCI_PLTFM_H
-#define _SDHCI_PLTFM_H
-
-struct sdhci_ops;
-struct sdhci_host;
-
-/**
- * struct sdhci_pltfm_data - SDHCI platform-specific information  hooks
- * @ops: optional pointer to the platform-provided SDHCI ops
- * @quirks: optional SDHCI quirks
- * @init: optional hook that is called during device probe, before the
- *driver tries to access any SDHCI registers
- * @exit: optional hook that is called during device removal
- */
-struct sdhci_pltfm_data {
-   struct sdhci_ops *ops;
-   unsigned int quirks;
-   int (*init)(struct sdhci_host *host);
-   void (*exit)(struct sdhci_host *host);
-};
-
-#endif /* _SDHCI_PLTFM_H */
-- 
1.7.1

--
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 3/6] mmc: sdhci: introduce private get_ro

2010-09-29 Thread Wolfram Sang 
Some controllers handle their write-protection differently. Introduce a
callback to be able to handle it, ensuring the same locking takes place
for it.

Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---
 drivers/mmc/host/sdhci.c |   11 +++
 drivers/mmc/host/sdhci.h |1 +
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 96c7f60..129958e 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1229,14 +1229,17 @@ static int sdhci_get_ro(struct mmc_host *mmc)
 
if (host-flags  SDHCI_DEVICE_DEAD)
present = 0;
+   else if (host-ops-get_ro)
+   present = host-ops-get_ro(host);
else
-   present = sdhci_readl(host, SDHCI_PRESENT_STATE);
+   present = !(sdhci_readl(host, SDHCI_PRESENT_STATE)
+SDHCI_WRITE_PROTECT);
 
spin_unlock_irqrestore(host-lock, flags);
 
-   if (host-quirks  SDHCI_QUIRK_INVERTED_WRITE_PROTECT)
-   return !!(present  SDHCI_WRITE_PROTECT);
-   return !(present  SDHCI_WRITE_PROTECT);
+   /* This quirk needs to be replaced by a callback-function later */
+   return host-quirks  SDHCI_QUIRK_INVERTED_WRITE_PROTECT ?
+   !present : present;
 }
 
 static void sdhci_enable_sdio_irq(struct mmc_host *mmc, int enable)
diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
index 112543a..66f83f4 100644
--- a/drivers/mmc/host/sdhci.h
+++ b/drivers/mmc/host/sdhci.h
@@ -336,6 +336,7 @@ 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);
+   unsigned int(*get_ro)(struct sdhci_host *host);
 };
 
 #ifdef CONFIG_MMC_SDHCI_IO_ACCESSORS
-- 
1.7.1

--
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 5/6] mmc: sdhci-of-esdhc: factor out common stuff

2010-09-29 Thread Wolfram Sang 
Put everything which can be shared between the OF and platform version
of this driver into a local .h-file.

Signed-off-by: Wolfram Sang w.s...@pengutronix.de
---

Changes since last version:

* use inline for set_clock()

 drivers/mmc/host/sdhci-esdhc.h|   81 +
 drivers/mmc/host/sdhci-of-esdhc.c |   70 
 2 files changed, 89 insertions(+), 62 deletions(-)
 create mode 100644 drivers/mmc/host/sdhci-esdhc.h

diff --git a/drivers/mmc/host/sdhci-esdhc.h b/drivers/mmc/host/sdhci-esdhc.h
new file mode 100644
index 000..7ccc8cb
--- /dev/null
+++ b/drivers/mmc/host/sdhci-esdhc.h
@@ -0,0 +1,81 @@
+/*
+ * Freescale eSDHC controller driver generics for OF and pltfm.
+ *
+ * Copyright (c) 2007 Freescale Semiconductor, Inc.
+ * Copyright (c) 2009 MontaVista Software, Inc.
+ * Copyright (c) 2010 Pengutronix e.K.
+ *   Author: Wolfram Sang w.s...@pengutronix.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#ifndef _DRIVERS_MMC_SDHCI_ESDHC_H
+#define _DRIVERS_MMC_SDHCI_ESDHC_H
+
+/*
+ * Ops and quirks for the Freescale eSDHC controller.
+ */
+
+#define ESDHC_DEFAULT_QUIRKS   (SDHCI_QUIRK_FORCE_BLK_SZ_2048 | \
+   SDHCI_QUIRK_BROKEN_CARD_DETECTION | \
+   SDHCI_QUIRK_NO_BUSY_IRQ | \
+   SDHCI_QUIRK_NONSTANDARD_CLOCK | \
+   SDHCI_QUIRK_DATA_TIMEOUT_USES_SDCLK | \
+   SDHCI_QUIRK_PIO_NEEDS_DELAY | \
+   SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET | \
+   SDHCI_QUIRK_NO_CARD_NO_RESET)
+
+#define ESDHC_SYSTEM_CONTROL   0x2c
+#define ESDHC_CLOCK_MASK   0xfff0
+#define ESDHC_PREDIV_SHIFT 8
+#define ESDHC_DIVIDER_SHIFT4
+#define ESDHC_CLOCK_PEREN  0x0004
+#define ESDHC_CLOCK_HCKEN  0x0002
+#define ESDHC_CLOCK_IPGEN  0x0001
+
+/* pltfm-specific */
+#define ESDHC_HOST_CONTROL_LE  0x20
+
+/* OF-specific */
+#define ESDHC_DMA_SYSCTL   0x40c
+#define ESDHC_DMA_SNOOP0x0040
+
+#define ESDHC_HOST_CONTROL_RES 0x05
+
+static inline void esdhc_set_clock(struct sdhci_host *host, unsigned int clock)
+{
+   int pre_div = 2;
+   int div = 1;
+   u32 temp;
+
+   temp = sdhci_readl(host, ESDHC_SYSTEM_CONTROL);
+   temp = ~(ESDHC_CLOCK_IPGEN | ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN | 
ESDHC_CLOCK_MASK);
+   sdhci_writel(host, temp, ESDHC_SYSTEM_CONTROL);
+
+   if (clock == 0)
+   goto out;
+
+   while (host-max_clk / pre_div / 16  clock  pre_div  256)
+   pre_div *= 2;
+
+   while (host-max_clk / pre_div / div  clock  div  16)
+   div++;
+
+   dev_dbg(mmc_dev(host-mmc), desired SD clock: %d, actual: %d\n,
+   clock, host-max_clk / pre_div / div);
+
+   pre_div = 1;
+   div--;
+
+   temp = sdhci_readl(host, ESDHC_SYSTEM_CONTROL);
+   temp |= (ESDHC_CLOCK_IPGEN | ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN |
+ (div  ESDHC_DIVIDER_SHIFT) | (pre_div  
ESDHC_PREDIV_SHIFT));
+   sdhci_writel(host, temp, ESDHC_SYSTEM_CONTROL);
+   mdelay(100);
+out:
+   host-clock = clock;
+}
+
+#endif /* _DRIVERS_MMC_SDHCI_ESDHC_H */
diff --git a/drivers/mmc/host/sdhci-of-esdhc.c 
b/drivers/mmc/host/sdhci-of-esdhc.c
index c8623de..277fcb9 100644
--- a/drivers/mmc/host/sdhci-of-esdhc.c
+++ b/drivers/mmc/host/sdhci-of-esdhc.c
@@ -18,23 +18,7 @@
 #include linux/mmc/host.h
 #include sdhci-of.h
 #include sdhci.h
-
-/*
- * Ops and quirks for the Freescale eSDHC controller.
- */
-
-#define ESDHC_DMA_SYSCTL   0x40c
-#define ESDHC_DMA_SNOOP0x0040
-
-#define ESDHC_SYSTEM_CONTROL   0x2c
-#define ESDHC_CLOCK_MASK   0xfff0
-#define ESDHC_PREDIV_SHIFT 8
-#define ESDHC_DIVIDER_SHIFT4
-#define ESDHC_CLOCK_PEREN  0x0004
-#define ESDHC_CLOCK_HCKEN  0x0002
-#define ESDHC_CLOCK_IPGEN  0x0001
-
-#define ESDHC_HOST_CONTROL_RES 0x05
+#include sdhci-esdhc.c
 
 static u16 esdhc_readw(struct sdhci_host *host, int reg)
 {
@@ -68,51 +52,20 @@ static void esdhc_writeb(struct sdhci_host *host, u8 val, 
int reg)
sdhci_be32bs_writeb(host, val, reg);
 }
 
-static void esdhc_set_clock(struct sdhci_host *host, unsigned int clock)
-{
-   int pre_div = 2;
-   int div = 1;
-
-   clrbits32(host-ioaddr + ESDHC_SYSTEM_CONTROL, ESDHC_CLOCK_IPGEN |
- ESDHC_CLOCK_HCKEN | ESDHC_CLOCK_PEREN | ESDHC_CLOCK_MASK);
-
-   if (clock == 0)
-   goto out;
-
-   while (host-max_clk / pre_div / 16  clock  pre_div  256)
-   pre_div *= 2;
-
-   while (host-max_clk / pre_div / div  clock  div  16)
-   div++;
-
-   dev_dbg(mmc_dev(host-mmc), desired SD

[PATCH 6/6] mmc: sdhci-pltfm: add pltfm-driver for imx35/51

2010-09-29 Thread Wolfram Sang 
This driver adds basic support for the esdhc-core found on e.g.
imx35/51. It adds up to the pltfm-core.

Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Acked-by: Anton Vorontsov cbouatmai...@gmail.com
---

Changes since last version:

* some more -imx suffixes added
* reworked the clock-matching. Now matching the pdev

 drivers/mmc/host/Kconfig   |   10 +++
 drivers/mmc/host/Makefile  |1 +
 drivers/mmc/host/sdhci-esdhc-imx.c |  143 
 drivers/mmc/host/sdhci-pltfm.c |3 +
 drivers/mmc/host/sdhci-pltfm.h |1 +
 5 files changed, 158 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mmc/host/sdhci-esdhc-imx.c

diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
index 6f12d5d..3c8c286 100644
--- a/drivers/mmc/host/Kconfig
+++ b/drivers/mmc/host/Kconfig
@@ -143,6 +143,16 @@ config MMC_SDHCI_MV
 
  If unsure, say N.
 
+config MMC_SDHCI_ESDHC_IMX
+   bool SDHCI platform support for the Freescale eSDHC i.MX controller
+   depends on MMC_SDHCI_PLTFM
+   select MMC_SDHCI_IO_ACCESSORS
+   help
+ This selects the Freescale eSDHC controller support on the platform
+ bus, found on platforms like mx35/51.
+
+ If unsure, say N.
+
 config MMC_SDHCI_S3C
tristate SDHCI support on Samsung S3C SoC
depends on MMC_SDHCI  PLAT_SAMSUNG
diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
index ef32c32..5f283b5 100644
--- a/drivers/mmc/host/Makefile
+++ b/drivers/mmc/host/Makefile
@@ -38,6 +38,7 @@ obj-$(CONFIG_MMC_USHC)+= ushc.o
 obj-$(CONFIG_MMC_SDHCI_PLTFM)  += sdhci-platform.o
 sdhci-platform-y   := sdhci-pltfm.o
 sdhci-platform-$(CONFIG_MMC_SDHCI_CNS3XXX) += sdhci-cns3xxx.o
+sdhci-platform-$(CONFIG_MMC_SDHCI_ESDHC_IMX)   += sdhci-esdhc-imx.o
 
 obj-$(CONFIG_MMC_SDHCI_OF) += sdhci-of.o
 sdhci-of-y := sdhci-of-core.o
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
b/drivers/mmc/host/sdhci-esdhc-imx.c
new file mode 100644
index 000..68cf78c
--- /dev/null
+++ b/drivers/mmc/host/sdhci-esdhc-imx.c
@@ -0,0 +1,143 @@
+/*
+ * Freescale eSDHC i.MX controller driver for the platform bus.
+ *
+ * derived from the OF-version.
+ *
+ * Copyright (c) 2010 Pengutronix e.K.
+ *   Author: Wolfram Sang w.s...@pengutronix.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License.
+ */
+
+#include linux/io.h
+#include linux/delay.h
+#include linux/err.h
+#include linux/clk.h
+#include linux/mmc/host.h
+#include linux/mmc/sdhci-pltfm.h
+#include sdhci.h
+#include sdhci-pltfm.h
+#include sdhci-esdhc.h
+
+static inline void esdhc_clrset_le(struct sdhci_host *host, u32 mask, u32 val, 
int reg)
+{
+   void __iomem *base = host-ioaddr + (reg  ~0x3);
+   u32 shift = (reg  0x3) * 8;
+
+   writel(((readl(base)  ~(mask  shift)) | (val  shift)), base);
+}
+
+static u16 esdhc_readw_le(struct sdhci_host *host, int reg)
+{
+   if (unlikely(reg == SDHCI_HOST_VERSION))
+   reg ^= 2;
+
+   return readw(host-ioaddr + reg);
+}
+
+static void esdhc_writew_le(struct sdhci_host *host, u16 val, int reg)
+{
+   struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
+
+   switch (reg) {
+   case SDHCI_TRANSFER_MODE:
+   /*
+* Postpone this write, we must do it together with a
+* command write that is down below.
+*/
+   pltfm_host-scratchpad = val;
+   return;
+   case SDHCI_COMMAND:
+   writel(val  16 | pltfm_host-scratchpad,
+   host-ioaddr + SDHCI_TRANSFER_MODE);
+   return;
+   case SDHCI_BLOCK_SIZE:
+   val = ~SDHCI_MAKE_BLKSZ(0x7, 0);
+   break;
+   }
+   esdhc_clrset_le(host, 0x, val, reg);
+}
+
+static void esdhc_writeb_le(struct sdhci_host *host, u8 val, int reg)
+{
+   u32 new_val;
+
+   switch (reg) {
+   case SDHCI_POWER_CONTROL:
+   /*
+* FSL put some DMA bits here
+* If your board has a regulator, code should be here
+*/
+   return;
+   case SDHCI_HOST_CONTROL:
+   /* FSL messed up here, so we can just keep those two */
+   new_val = val  (SDHCI_CTRL_LED | SDHCI_CTRL_4BITBUS);
+   /* ensure the endianess */
+   new_val |= ESDHC_HOST_CONTROL_LE;
+   /* DMA mode bits are shifted */
+   new_val |= (val  SDHCI_CTRL_DMA_MASK)  5;
+
+   esdhc_clrset_le(host, 0x, new_val, reg);
+   return;
+   }
+   esdhc_clrset_le(host, 0xff, val, reg);
+}
+
+static unsigned int esdhc_pltfm_get_max_clock(struct sdhci_host *host)
+{
+   struct

Re: [PATCH 6/6] mmc: sdhci-pltfm: add pltfm-driver for imx35/51

2010-09-29 Thread Chris Ball 
Hi Wolfram,

On Wed, Sep 29, 2010 at 10:08:04PM +0200, Wolfram Sang wrote:
 This driver adds basic support for the esdhc-core found on e.g.
 imx35/51. It adds up to the pltfm-core.
 
 Signed-off-by: Wolfram Sang w.s...@pengutronix.de
 Acked-by: Anton Vorontsov cbouatmai...@gmail.com
 ---
 
 Changes since last version:
 
 * some more -imx suffixes added
 * reworked the clock-matching. Now matching the pdev
 
  drivers/mmc/host/Kconfig   |   10 +++
  drivers/mmc/host/Makefile  |1 +
  drivers/mmc/host/sdhci-esdhc-imx.c |  143 
 
  drivers/mmc/host/sdhci-pltfm.c |3 +
  drivers/mmc/host/sdhci-pltfm.h |1 +
  5 files changed, 158 insertions(+), 0 deletions(-)
  create mode 100644 drivers/mmc/host/sdhci-esdhc-imx.c
 
 diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
 index 6f12d5d..3c8c286 100644
 --- a/drivers/mmc/host/Kconfig
 +++ b/drivers/mmc/host/Kconfig
 @@ -143,6 +143,16 @@ config MMC_SDHCI_MV
  
 If unsure, say N.
  
 +config MMC_SDHCI_ESDHC_IMX
 + bool SDHCI platform support for the Freescale eSDHC i.MX controller
 + depends on MMC_SDHCI_PLTFM
 + select MMC_SDHCI_IO_ACCESSORS
 + help
 +   This selects the Freescale eSDHC controller support on the platform
 +   bus, found on platforms like mx35/51.
 +
 +   If unsure, say N.
 +
  config MMC_SDHCI_S3C
   tristate SDHCI support on Samsung S3C SoC
   depends on MMC_SDHCI  PLAT_SAMSUNG
 diff --git a/drivers/mmc/host/Makefile b/drivers/mmc/host/Makefile
 index ef32c32..5f283b5 100644
 --- a/drivers/mmc/host/Makefile
 +++ b/drivers/mmc/host/Makefile
 @@ -38,6 +38,7 @@ obj-$(CONFIG_MMC_USHC)  += ushc.o
  obj-$(CONFIG_MMC_SDHCI_PLTFM)+= sdhci-platform.o
  sdhci-platform-y := sdhci-pltfm.o
  sdhci-platform-$(CONFIG_MMC_SDHCI_CNS3XXX)   += sdhci-cns3xxx.o
 +sdhci-platform-$(CONFIG_MMC_SDHCI_ESDHC_IMX) += sdhci-esdhc-imx.o
  
  obj-$(CONFIG_MMC_SDHCI_OF)   += sdhci-of.o
  sdhci-of-y   := sdhci-of-core.o
 diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c 
 b/drivers/mmc/host/sdhci-esdhc-imx.c
 new file mode 100644
 index 000..68cf78c
 --- /dev/null
 +++ b/drivers/mmc/host/sdhci-esdhc-imx.c
 @@ -0,0 +1,143 @@
 +/*
 + * Freescale eSDHC i.MX controller driver for the platform bus.
 + *
 + * derived from the OF-version.
 + *
 + * Copyright (c) 2010 Pengutronix e.K.
 + *   Author: Wolfram Sang w.s...@pengutronix.de
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License.
 + */
 +
 +#include linux/io.h
 +#include linux/delay.h
 +#include linux/err.h
 +#include linux/clk.h
 +#include linux/mmc/host.h
 +#include linux/mmc/sdhci-pltfm.h
 +#include sdhci.h
 +#include sdhci-pltfm.h
 +#include sdhci-esdhc.h
 +
 +static inline void esdhc_clrset_le(struct sdhci_host *host, u32 mask, u32 
 val, int reg)
 +{
 + void __iomem *base = host-ioaddr + (reg  ~0x3);
 + u32 shift = (reg  0x3) * 8;
 +
 + writel(((readl(base)  ~(mask  shift)) | (val  shift)), base);
 +}
 +
 +static u16 esdhc_readw_le(struct sdhci_host *host, int reg)
 +{
 + if (unlikely(reg == SDHCI_HOST_VERSION))
 + reg ^= 2;
 +
 + return readw(host-ioaddr + reg);
 +}
 +
 +static void esdhc_writew_le(struct sdhci_host *host, u16 val, int reg)
 +{
 + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
 +
 + switch (reg) {
 + case SDHCI_TRANSFER_MODE:
 + /*
 +  * Postpone this write, we must do it together with a
 +  * command write that is down below.
 +  */
 + pltfm_host-scratchpad = val;
 + return;
 + case SDHCI_COMMAND:
 + writel(val  16 | pltfm_host-scratchpad,
 + host-ioaddr + SDHCI_TRANSFER_MODE);
 + return;
 + case SDHCI_BLOCK_SIZE:
 + val = ~SDHCI_MAKE_BLKSZ(0x7, 0);
 + break;
 + }
 + esdhc_clrset_le(host, 0x, val, reg);
 +}
 +
 +static void esdhc_writeb_le(struct sdhci_host *host, u8 val, int reg)
 +{
 + u32 new_val;
 +
 + switch (reg) {
 + case SDHCI_POWER_CONTROL:
 + /*
 +  * FSL put some DMA bits here
 +  * If your board has a regulator, code should be here
 +  */
 + return;
 + case SDHCI_HOST_CONTROL:
 + /* FSL messed up here, so we can just keep those two */
 + new_val = val  (SDHCI_CTRL_LED | SDHCI_CTRL_4BITBUS);
 + /* ensure the endianess */
 + new_val |= ESDHC_HOST_CONTROL_LE;
 + /* DMA mode bits are shifted */
 + new_val |= (val  SDHCI_CTRL_DMA_MASK)  5;
 +
 + esdhc_clrset_le(host, 0x, new_val, reg);
 + return;
 + }
 + esdhc_clrset_le(host, 0xff,

Re: [PATCH 1/6] mmc: sdhci-pltfm: Add structure for host-specific data

2010-09-29 Thread Richard Röjfors 

On 09/29/2010 10:07 PM, Wolfram Sang wrote:

We need to carry some information per host, e.g. the clock. Add a
structure for it and initialize it in the generic part. Also do not use
the parent of the platform_device (if it is available), this breaks the
clock-matching on ARM.


The reason it's there is for instance a case when the shdci device is exposed
from a MFD device which sits on top of PCI. Then the parent (PCI device)
is the device that is DMA capable. This patch will break such usage.

What is the purpose of this patch? You allocate space for an extra struct,
which you have a pointer pointing to, but you never use the pointer?



Signed-off-by: Wolfram Sangw.s...@pengutronix.de
Cc: Richard Röjforsrichard.rojfors@mocean-labs.com
---

Changes since last version:

* added types.h


I saw no types.h?


* removed usage of pdev-dev.parent to ensure clk-matching
   Please speak up if this has a use case I failed to see!

  drivers/mmc/host/sdhci-pltfm.c |8 
  drivers/mmc/host/sdhci-pltfm.h |7 +++
  2 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sdhci-pltfm.c b/drivers/mmc/host/sdhci-pltfm.c
index e045e3c..095ca9d 100644
--- a/drivers/mmc/host/sdhci-pltfm.c
+++ b/drivers/mmc/host/sdhci-pltfm.c
@@ -55,6 +55,7 @@ static int __devinit sdhci_pltfm_probe(struct platform_device 
*pdev)
struct sdhci_pltfm_data *pdata = pdev-dev.platform_data;
const struct platform_device_id *platid = platform_get_device_id(pdev);
struct sdhci_host *host;
+   struct sdhci_pltfm_host *pltfm_host;
struct resource *iomem;
int ret;

@@ -71,16 +72,15 @@ static int __devinit sdhci_pltfm_probe(struct 
platform_device *pdev)
dev_err(pdev-dev, Invalid iomem size. You may 
experience problems.\n);

-   if (pdev-dev.parent)
-   host = sdhci_alloc_host(pdev-dev.parent, 0);
-   else
-   host = sdhci_alloc_host(pdev-dev, 0);
+   host = sdhci_alloc_host(pdev-dev, sizeof(*pltfm_host));

if (IS_ERR(host)) {
ret = PTR_ERR(host);
goto err;
}

+   pltfm_host = sdhci_priv(host);
+
host-hw_name = platform;
if (pdata  pdata-ops)
host-ops = pdata-ops;
diff --git a/drivers/mmc/host/sdhci-pltfm.h b/drivers/mmc/host/sdhci-pltfm.h
index 900f329..93a0319 100644
--- a/drivers/mmc/host/sdhci-pltfm.h
+++ b/drivers/mmc/host/sdhci-pltfm.h
@@ -11,8 +11,15 @@
  #ifndef _DRIVERS_MMC_SDHCI_PLTFM_H
  #define _DRIVERS_MMC_SDHCI_PLTFM_H

+#includelinux/clk.h
+#includelinux/types.h
  #includelinux/sdhci-pltfm.h

+struct sdhci_pltfm_host {
+   struct clk *clk;
+   u32 scratchpad; /* to handle quirks across io-accessor calls */
+};
+
  extern struct sdhci_pltfm_data sdhci_cns3xxx_pdata;

  #endif /* _DRIVERS_MMC_SDHCI_PLTFM_H */

--
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 RESEND] sdhci-s3c: support clock enable/disable (clock-gating)

2010-09-29 Thread Chris Ball 
Hi Jaehoon/Adrian,

On Thu, Sep 16, 2010 at 03:46:50PM +0900, Jaehoon Chung wrote:
 Hi all,
   This is a RFC patch that support clock-gating for saving power consumption.
   I found mmc_host_enable/mmc_host_disable function in core.c
   (using MMC_CAP_DSIABLE. i think that use when host enable/disable)
   So, i used that functions and implemented some functions in sdhci-s3c.c  
 sdhci.c
 
 i want any feedback. how do you think about this patch?
 Plz let me know...

A few points:
  * Have you tested this patch?  Did you see a decrease in power
consumption?  How large was the decrease?
  * I don't understand exactly how/when you're expecting to save power
with this approach of defining .{enable,disable}() without then
calling them from your driver code.  Under which circumstances do
you think this will power down the clock?
  * CC'ing Adrian for help with review, since he wrote these callbacks.

Thanks,

- Chris.

 Thank you all
 
  Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
  Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 
 ---
  drivers/mmc/host/sdhci-s3c.c |   36 
  drivers/mmc/host/sdhci.c |   30 ++
  drivers/mmc/host/sdhci.h |4 
  3 files changed, 70 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
 index 71ad416..9b430fb 100644
 --- a/drivers/mmc/host/sdhci-s3c.c
 +++ b/drivers/mmc/host/sdhci-s3c.c
 @@ -47,6 +47,7 @@ struct sdhci_s3c {
   unsigned intcur_clk;
   int ext_cd_irq;
   int ext_cd_gpio;
 + int flag;
  
   struct clk  *clk_io;
   struct clk  *clk_bus[MAX_BUS_CLK];
 @@ -232,10 +233,45 @@ static unsigned int sdhci_s3c_get_min_clock(struct 
 sdhci_host *host)
   return min;
  }
  
 +static int sdhci_s3c_enable_clk(struct sdhci_host *host)
 +{
 + struct sdhci_s3c *sc = to_s3c(host);
 +
 + if (sc-flag != 1) {
 + clk_disable(sc-clk_io);
 + clk_disable(sc-clk_bus[sc-cur_clk]);
 + }
 +
 + if (sc-host-clk_cnt == 0) {
 + clk_enable(sc-clk_io);
 + clk_enable(sc-clk_bus[sc-cur_clk]);
 + sc-host-clk_cnt++;
 + sc-flag = 1;
 + }
 +
 + return 0;
 +}
 +
 +static int sdhci_s3c_disable_clk(struct sdhci_host *host, int lazy)
 +{
 + struct sdhci_s3c *sc = to_s3c(host);
 +
 + if (sc-host-clk_cnt) {
 + clk_disable(sc-clk_io);
 + clk_disable(sc-clk_bus[sc-cur_clk]);
 + if (sc-host-clk_cnt)
 + sc-host-clk_cnt--;
 + }
 +
 + return 0;
 +}
 +
  static struct sdhci_ops sdhci_s3c_ops = {
   .get_max_clock  = sdhci_s3c_get_max_clk,
   .set_clock  = sdhci_s3c_set_clock,
   .get_min_clock  = sdhci_s3c_get_min_clock,
 + .enable = sdhci_s3c_enable_clk,
 + .disable= sdhci_s3c_disable_clk,
  };
  
  static void sdhci_s3c_notify_change(struct platform_device *dev, int state)
 diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
 index 401527d..fa2e55d 100644
 --- a/drivers/mmc/host/sdhci.c
 +++ b/drivers/mmc/host/sdhci.c
 @@ -1245,7 +1245,37 @@ out:
   spin_unlock_irqrestore(host-lock, flags);
  }
  
 +static int sdhci_enable_clk(struct mmc_host *mmc)
 +{
 + struct sdhci_host *host = mmc_priv(mmc);
 + int ret = 0;
 +
 + if (host-old_clock != 0  host-clock == 0) {
 + if (host-ops-enable)
 + ret = host-ops-enable(host);
 + sdhci_set_clock(host, host-old_clock);
 + }
 +
 + return ret;
 +}
 +
 +static int sdhci_disable_clk(struct mmc_host *mmc, int lazy)
 +{
 + struct sdhci_host *host = mmc_priv(mmc);
 + int ret = 0;
 +
 + if (host-clock != 0) {
 + host-old_clock = host-clock;
 + sdhci_set_clock(host, 0);
 + if (host-ops-disable)
 + ret = host-ops-disable(host, lazy);
 + }
 + return ret;
 +}
 +
  static const struct mmc_host_ops sdhci_ops = {
 + .enable = sdhci_enable_clk,
 + .disable= sdhci_disable_clk,
   .request= sdhci_request,
   .set_ios= sdhci_set_ios,
   .get_ro = sdhci_get_ro,
 diff --git a/drivers/mmc/host/sdhci.h b/drivers/mmc/host/sdhci.h
 index d316bc7..0c6f143 100644
 --- a/drivers/mmc/host/sdhci.h
 +++ b/drivers/mmc/host/sdhci.h
 @@ -278,6 +278,8 @@ struct sdhci_host {
   unsigned inttimeout_clk;/* Timeout freq (KHz) */
  
   unsigned intclock;  /* Current clock (MHz) */
 + unsigned intold_clock;  /* Old clock (MHz) */
 + unsigned intclk_cnt;/* Clock user count */
   u8  pwr;/* Current voltage */
  
   struct mmc_request  *mrq;   /*

Re: Hang on Suspend to RAM with 2.6.36-rc4

2010-09-29 Thread Laine Walker-Avina 
On Wed, Sep 22, 2010 at 3:21 PM, Laine Walker-Avina lwalk...@pasco.com wrote:
 On Tue, Sep 14, 2010 at 4:02 PM, Kevin Hilman
 khil...@deeprootsystems.com wrote:
 Laine Walker-Avina lwalk...@pasco.com writes:

 I just pulled the latest changes today from the linux-omap git tree,
 and something appears to have broken suspend to RAM on my OMAP3503
 board.

 Is this on the master branch?  What defconfig?  When was this last
 working for you?  -rc3?
 Yes, on the master branch. I'm using my own config. It was working on
 2.6.35 or so. I tried backporting my board patches to 2.6.36 and it
 fails there too now for some reason. It might be the SD card, I'll
 have to find another one and try it out.

 Looks like you may have your rootfs on MMC.  Do you have
 CONFIG_MMC_UNSAFE_RESUME=y in your .config?
 No

 Kevin

 Here's a log:

 ~$ echo mem  /sys/power/state
 [   23.102416] PM: Syncing filesystems ... done.
 [   29.493927] PM: Preparing system for mem sleep
 [   29.500396] PM: Adding info for No Bus:vcs63
 [   29.506774] PM: Adding info for No Bus:vcsa63
 [   29.547424] mmc0: card bed5 removed
 [   29.550964] PM: Removing info for mmc:mmc0:bed5
 [   37.001373] INFO: task init:1 blocked for more than 5 seconds.
 [   37.007415] echo 0  /proc/sys/kernel/hung_task_timeout_secs
 disables this message.
 [   37.015472] init          D c02a8cb8     0     1      0 0x
 [   37.021942] [c02a8cb8] (schedule+0x320/0x368) from [c0121938]
 (do_get_write_access+0x2bc/0x52c)
 [   37.031250] [c0121938] (do_get_write_access+0x2bc/0x52c) from
 [c0121bcc] (journal_get_write_access+0x24/0x38)
 [   37.041809] [c0121bcc] (journal_get_write_access+0x24/0x38) from
 [c01187d4] (__ext3_journal_get_write_access+0x1c/0x48)
 [   37.053222] [c01187d4]
 (__ext3_journal_get_write_access+0x1c/0x48) from [c010c5a8]
 (ext3_reserve_inode_write+0x3c/0x80)
 [   37.064636] [c010c5a8] (ext3_reserve_inode_write+0x3c/0x80) from
 [c010c61c] (ext3_mark_inode_dirty+0x30/0x54)
 [   37.075164] [c010c61c] (ext3_mark_inode_dirty+0x30/0x54) from
 [c010c768] (ext3_dirty_inode+0x68/0x80)
 [   37.084991] [c010c768] (ext3_dirty_inode+0x68/0x80) from
 [c00d92c0] (__mark_inode_dirty+0x2c/0x188)
 [   37.094665] [c00d92c0] (__mark_inode_dirty+0x2c/0x188) from
 [c00cf610] (touch_atime+0x114/0x140)
 [   37.104064] [c00cf610] (touch_atime+0x114/0x140) from
 [c00952ac] (generic_file_aio_read+0x6e8/0x76c)
 [   37.113830] [c00952ac] (generic_file_aio_read+0x6e8/0x76c) from
 [c00bc0cc] (do_sync_read+0xa0/0xe8)
 [   37.123474] [c00bc0cc] (do_sync_read+0xa0/0xe8) from [c00bcbc8]
 (vfs_read+0xa8/0x130)
 [   37.131896] [c00bcbc8] (vfs_read+0xa8/0x130) from [c00bccfc]
 (sys_read+0x3c/0x68)
 [   37.139984] [c00bccfc] (sys_read+0x3c/0x68) from [c002df40]
 (ret_fast_syscall+0x0/0x3c)
 [   37.148559] 1 lock held by init/1:
 [   37.152008]  #0:  (jbd_handle){+.+...}, at: [c0122290]
 start_this_handle+0x314/0x3c8
 [   37.160247] INFO: task mmcqd:320 blocked for more than 5 seconds.
 [   37.166534] echo 0  /proc/sys/kernel/hung_task_timeout_secs
 disables this message.
 [   37.174560] mmcqd         D c02a8cb8     0   320      2 0x
 [   37.181030] [c02a8cb8] (schedule+0x320/0x368) from [c0204570]
 (__mmc_claim_host+0xbc/0x158)
 [   37.190002] [c0204570] (__mmc_claim_host+0xbc/0x158) from
 [c020b6d0] (mmc_blk_issue_rw_rq+0x38/0x504)
 [   37.199829] [c020b6d0] (mmc_blk_issue_rw_rq+0x38/0x504) from
 [c020c6b0] (mmc_queue_thread+0xdc/0xe0)
 [   37.209564] [c020c6b0] (mmc_queue_thread+0xdc/0xe0) from
 [c006e948] (kthread+0x80/0x88)
 [   37.218200] [c006e948] (kthread+0x80/0x88) from [c002ef90]
 (kernel_thread_exit+0x0/0x8)
 [   37.226776] no locks held by mmcqd/320.
 [   37.230682] INFO: task sh:363 blocked for more than 5 seconds.
 [   37.236694] echo 0  /proc/sys/kernel/hung_task_timeout_secs
 disables this message.
 [   37.244720] sh            D c02a8cb8     0   363      1 0x
 [   37.251220] [c02a8cb8] (schedule+0x320/0x368) from [c01264f8]
 (log_wait_commit+0xb8/0x110)
 [   37.260101] [c01264f8] (log_wait_commit+0xb8/0x110) from
 [c0113e10] (ext3_sync_fs+0x3c/0x44)
 [   37.269134] [c0113e10] (ext3_sync_fs+0x3c/0x44) from [c00dcee4]
 (__sync_filesystem+0x80/0x9c)
 [   37.278289] [c00dcee4] (__sync_filesystem+0x80/0x9c) from
 [c00e5e88] (fsync_bdev+0x18/0x38)
 [   37.287261] [c00e5e88] (fsync_bdev+0x18/0x38) from [c0186b28]
 (invalidate_partition+0x18/0x34)
 [   37.296478] [c0186b28] (invalidate_partition+0x18/0x34) from
 [c010264c] (del_gendisk+0x28/0xd0)
 [   37.305786] [c010264c] (del_gendisk+0x28/0xd0) from [c020b414]
 (mmc_blk_remove+0x20/0x40)
 [   37.314575] [c020b414] (mmc_blk_remove+0x20/0x40) from
 [c0205190] (mmc_bus_remove+0x18/0x20)
 [   37.323608] [c0205190] (mmc_bus_remove+0x18/0x20) from
 [c01d7f6c] (__device_release_driver+0x84/0xd0)
 [   37.333435] [c01d7f6c] (__device_release_driver+0x84/0xd0) from
 [c01d808c] (device_release_driver+0x20/0x2c)
 [   37.343902] [c01d808c] (device_release_driver+0x20/0x2c) from
 [c01d75d8] (bus_remove_device+0xa4/0xb4)
 [

Re: [PATCH] MMC: name mmc queue thread by host index

2010-09-29 Thread Ethan Du 
Anyone interested?
It always takes time to identify a problem with several processes all
named mmcqd there

On Sun, Sep 26, 2010 at 4:34 PM, Ethan Du ethan@gmail.com wrote:
 Usually there are multiple mmc host controllers, rename mmc queue thread
     by host index, so we can easily identify which controller it belongs to

 Signed-off-by: Ethan ethan@gmail.com
 ---
  drivers/mmc/card/queue.c |    3 ++-
  1 files changed, 2 insertions(+), 1 deletions(-)

 diff --git a/drivers/mmc/card/queue.c b/drivers/mmc/card/queue.c
 index e876678..673bbdb 100644
 --- a/drivers/mmc/card/queue.c
 +++ b/drivers/mmc/card/queue.c
 @@ -211,7 +211,8 @@ int mmc_init_queue(struct mmc_queue *mq, struct mmc_card
 *card, spinlock_t *lock

  init_MUTEX(mq-thread_sem);

 -    mq-thread = kthread_run(mmc_queue_thread, mq, mmcqd);
 +    mq-thread = kthread_run(mmc_queue_thread, mq, mmcqd/%d,
 +        host-index);
  if (IS_ERR(mq-thread)) {
      ret = PTR_ERR(mq-thread);
      goto free_bounce_sg;
 --
 1.5.6.5


--
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 5/5] sdhci-s3c: Add support no internal clock divider in host controller

2010-09-29 Thread Kyungmin Park 
On Sat, Sep 18, 2010 at 12:59 AM, Chris Ball c...@laptop.org wrote:
 Hi,

 On Thu, Sep 16, 2010 at 06:08:28PM +0900, Kyungmin Park wrote:
 Well there are two implementations. and no conclusion yet.
 as s5pc210 don't support internal SDHCI clock, DMC overrides the
 function operation itself when s5pc210. System LSI use the quirks.

 Choose any one from MMC maintainer.

 Both approaches are generally acceptable for MMC, so I would want to
 leave it up to the maintainer of the driver in question (which is Ben,
 in this case?) to choose between them.

Hi Chris,

Did you get the opinion from Ben?

I hope this decision will be done before 2.6.37 merge windows start to
support SDHCI support on s5pc210.

Thank you,
Kyungmin Park


 That said, I think my own mild preference is for Jaehoon's approach.

 Thanks,

 - 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: Hang on Suspend to RAM with 2.6.36-rc4

2010-09-29 Thread Kevin Hilman 
Laine Walker-Avina lwalk...@pasco.com writes:

 On Wed, Sep 22, 2010 at 3:21 PM, Laine Walker-Avina lwalk...@pasco.com 
 wrote:
 On Tue, Sep 14, 2010 at 4:02 PM, Kevin Hilman
 khil...@deeprootsystems.com wrote:
 Laine Walker-Avina lwalk...@pasco.com writes:

 I just pulled the latest changes today from the linux-omap git tree,
 and something appears to have broken suspend to RAM on my OMAP3503
 board.

 Is this on the master branch?  What defconfig?  When was this last
 working for you?  -rc3?
 Yes, on the master branch. I'm using my own config. It was working on
 2.6.35 or so. I tried backporting my board patches to 2.6.36 and it
 fails there too now for some reason. It might be the SD card, I'll
 have to find another one and try it out.

 Looks like you may have your rootfs on MMC.  Do you have
 CONFIG_MMC_UNSAFE_RESUME=y in your .config?
 No

[...]


 This appears to be caused by commit 4c2ef25f (mmc: fix all hangs
 related to mmc/sd card insert/removal during suspend/resume). Enabling
 CONFIG_MMC_UNSAFE_RESUME seems to fix it. 

Good.

 Ideally, it would be nice to have the root file-system on a mmc
 regardless of whether or not it's removable or not.

You'll have to take that one up with the MMC core.

I'm sure they would welcome patches to fix it. ;)

Kevin

--
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 5/5] sdhci-s3c: Add support no internal clock divider in host controller

2010-09-29 Thread Chris Ball 
Hi Kyungmin, Ben,

On Thu, Sep 30, 2010 at 10:18:12AM +0900, Kyungmin Park wrote:
 On Sat, Sep 18, 2010 at 12:59 AM, Chris Ball c...@laptop.org wrote:
  Hi,
 
  On Thu, Sep 16, 2010 at 06:08:28PM +0900, Kyungmin Park wrote:
  Well there are two implementations. and no conclusion yet.
  as s5pc210 don't support internal SDHCI clock, DMC overrides the
  function operation itself when s5pc210. System LSI use the quirks.
 
  Choose any one from MMC maintainer.
 
  Both approaches are generally acceptable for MMC, so I would want to
  leave it up to the maintainer of the driver in question (which is Ben,
  in this case?) to choose between them.
 
 Hi Chris,
 
 Did you get the opinion from Ben?
 
 I hope this decision will be done before 2.6.37 merge windows start to
 support SDHCI support on s5pc210.

Hm, I didn't, and Ben's been silent about the urgent sdhci-s3c patches
too.  Ben, are you just dealing with a large backlog, or are you 
interested in nominating someone else to take over sdhci-s3c?

Thanks,

- 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: [RFC RESEND] sdhci-s3c: support clock enable/disable (clock-gating)

2010-09-29 Thread Chris Ball 
Hi,

On Wed, Sep 29, 2010 at 11:42:01PM -0400, Nicolas Pitre wrote:
 As I already said here: 
 
   http://article.gmane.org/gmane.linux.ports.arm.omap/39411
 
 I find those callbacks rather problematic.  Currently, 
 mmc_host_disable() is called by the host driver (currently OMAP) and 
 that's wrong.  Such decision cannot be made in the controller driver -- 
 it has to be made higher up the stack.

I strongly agree.  I hadn't noticed that aspect of this design until
today.  It looked like Linus W had a nice core-integrated clocking
framework almost ready to go a year ago, but it lost out.  (Something
left to do was to give extra time after a request in case we're on a
broken card which requires the card clock to be present during its
writeback.)

I'm not sure where to go from here -- advice welcome.  It would
perhaps be ideal if Linus W and Adrian could work together to make
the current framework look more like Linus' original intent and then
move omap_hsmmc to it as painlessly as possible.  Of course I wouldn't
expect this to happen quickly.

In the meantime, I would suggest that we should not accept any more
users of this framework, which would be a NACK to Jaehoon's patch
(which appears to my reading not to achieve any power-saving anyway).

Adrian, I'm sorry that I'm suggesting reverting -- or at least strongly
modifying -- a framework after it's already shipped in a release; if
you think this is unreasonable, I'll consider your argument carefully.

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: [RFC RESEND] sdhci-s3c: support clock enable/disable (clock-gating)

2010-09-29 Thread Kyungmin Park 
On Thu, Sep 30, 2010 at 1:09 PM, Chris Ball c...@laptop.org wrote:
 Hi,

 On Wed, Sep 29, 2010 at 11:42:01PM -0400, Nicolas Pitre wrote:
 As I already said here:

       http://article.gmane.org/gmane.linux.ports.arm.omap/39411

 I find those callbacks rather problematic.  Currently,
 mmc_host_disable() is called by the host driver (currently OMAP) and
 that's wrong.  Such decision cannot be made in the controller driver --
 it has to be made higher up the stack.

 I strongly agree.  I hadn't noticed that aspect of this design until
 today.  It looked like Linus W had a nice core-integrated clocking
 framework almost ready to go a year ago, but it lost out.  (Something
 left to do was to give extra time after a request in case we're on a
 broken card which requires the card clock to be present during its
 writeback.)

Do you mean this one?
http://www.mail-archive.com/linux-embed...@vger.kernel.org/msg01883.html

In previous time it used for our kernel and find it's difficult to
handle and maintain and can't support the SD card.
So try to find another method and implemente it at SDHCI drivers.


 I'm not sure where to go from here -- advice welcome.  It would
 perhaps be ideal if Linus W and Adrian could work together to make
 the current framework look more like Linus' original intent and then
 move omap_hsmmc to it as painlessly as possible.  Of course I wouldn't
 expect this to happen quickly.

 In the meantime, I would suggest that we should not accept any more
 users of this framework, which would be a NACK to Jaehoon's patch
 (which appears to my reading not to achieve any power-saving anyway).

No, In our case it deduce the about 10mA. so it's mandatory and basic
functionality to reduce the power.

Thank you,
Kyungmin Park

 Adrian, I'm sorry that I'm suggesting reverting -- or at least strongly
 modifying -- a framework after it's already shipped in a release; if
 you think this is unreasonable, I'll consider your argument carefully.

 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

--
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] sdhci: add support for sd 3.0 host and hooks for dual data rate eMMC

2010-09-29 Thread Philip Rakity 

This code has not been tested on mmc-test but has been patched against.  I have 
run it against 2.6.32 (with some minor changes).

I wanted to give folks a chance to comment before making it a formal patch.  
The code add the hooks into the sdhci layer for 
version 3.0 of the controller, including mmc/eMMC dual data rate support (ddr). 
   The next RFC adds support for DDR at the mmc layer

The question is how to provide DDR support.  I punted this and added hooks to 
let the h/w adaption code handle this since
a) tuning may be required and it is unclear what values to set the registers to 
that will work in all cases
b) higher speed single data -- not sure how to handle this


Philip

From 0b03d8838cc4a55f05f1bcad950843024a353d3d Mon Sep 17 00:00:00 2001
From: Philip Rakity prak...@marvell.com
Date: Wed, 29 Sep 2010 20:46:16 -0700
Subject: [RFC] sdhci: add support for sd 3.0 host and hooks for dual data rate 
eMMC
 Signed-off-by: Philip Rakity prak...@marvell.com

---
 drivers/mmc/host/sdhci.c |   81 +++---
 drivers/mmc/host/sdhci.h |   51 +++--
 include/linux/mmc/host.h |1 +
 3 files changed, 118 insertions(+), 15 deletions(-)

diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 401527d..b17e438 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -76,8 +76,10 @@ static void sdhci_dumpregs(struct sdhci_host *host)
printk(KERN_DEBUG DRIVER_NAME : AC12 err: 0x%08x | Slot int: 0x%08x\n,
sdhci_readw(host, SDHCI_ACMD12_ERR),
sdhci_readw(host, SDHCI_SLOT_INT_STATUS));
-   printk(KERN_DEBUG DRIVER_NAME : Caps: 0x%08x | Max curr: 0x%08x\n,
+   printk(KERN_DEBUG DRIVER_NAME : Caps: 0x%08x | Caps1:0x%08x\n,
sdhci_readl(host, SDHCI_CAPABILITIES),
+   sdhci_readl(host, SDHCI_CAPABILITIES_1));
+   printk(KERN_DEBUG DRIVER_NAME : Max curr: 0x%08x\n,
sdhci_readl(host, SDHCI_MAX_CURRENT));
 
if (host-flags  SDHCI_USE_ADMA)
@@ -1001,9 +1003,19 @@ static void sdhci_set_clock(struct sdhci_host *host, 
unsigned int clock)
if (clock == 0)
goto out;
 
-   for (div = 1;div  256;div *= 2) {
-   if ((host-max_clk / div) = clock)
-   break;
+   if (host-version = SDHCI_SPEC_300) {
+   if (host-max_clk = clock)
+   div = 1;
+   else {
+   div = host-max_clk/clock;
+   if (host-max_clk % clock)
+   div++;
+   }
+   } else {
+   for (div = 1;div  256;div *= 2) {
+   if ((host-max_clk / div) = clock)
+   break;
+   }
}
div = 1;
 
@@ -1025,6 +1037,9 @@ static void sdhci_set_clock(struct sdhci_host *host, 
unsigned int clock)
mdelay(1);
}
 
+   clk = (div  SDHCI_CLOCK_DIV_MASK)  SDHCI_DIVIDER_SHIFT;
+   clk |= ((div  SDHCI_CLOCK_DIV_HI_MASK)  SDHCI_CLOCK_DIV_MASK_LEN)
+SDHCI_CLOCK_DIVIDER_HI_SHIFT;
clk |= SDHCI_CLOCK_CARD_EN;
sdhci_writew(host, clk, SDHCI_CLOCK_CONTROL);
 
@@ -1169,11 +1184,13 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
sdhci_set_power(host, ios-vdd);
 
ctrl = sdhci_readb(host, SDHCI_HOST_CONTROL);
-
-   if (ios-bus_width == MMC_BUS_WIDTH_8)
-   ctrl |= SDHCI_CTRL_8BITBUS;
-   else
-   ctrl = ~SDHCI_CTRL_8BITBUS;
+   if (host-version = SDHCI_SPEC_300) {
+   if (ios-bus_width == MMC_BUS_WIDTH_8) {
+   ctrl |= SDHCI_CTRL_8BITBUS;
+   ctrl = ~SDHCI_CTRL_4BITBUS;
+   } else
+   ctrl = ~SDHCI_CTRL_8BITBUS;
+   }
 
if (ios-bus_width == MMC_BUS_WIDTH_4)
ctrl |= SDHCI_CTRL_4BITBUS;
@@ -1189,6 +1206,14 @@ static void sdhci_set_ios(struct mmc_host *mmc, struct 
mmc_ios *ios)
sdhci_writeb(host, ctrl, SDHCI_HOST_CONTROL);
 
/*
+* higher speed data rates need tuning - board specific
+* punt handling these speeds to the adoption layer
+*/
+   if ((host-flags  SDHCI_DATA_RATES_300) 
+   host-ops-program_v3_rate)
+   host-ops-program_v3_rate(host, ios);
+
+   /*
 * Some (ENE) controllers go apeshit on some ios operation,
 * signalling timeout and CRC errors even on CMD0. Resetting
 * it on each ios seems to solve the problem.
@@ -1692,6 +1717,7 @@ int sdhci_add_host(struct sdhci_host *host)
 {
struct mmc_host *mmc;
unsigned int caps;
+   unsigned int caps_1;
int ret;
 
WARN_ON(host == NULL);
@@ -1708,7 +1734,7 @@ int sdhci_add_host(struct sdhci_host *host)
host-version = sdhci_readw(host, SDHCI_HOST_VERSION);
host-version =

RE: [PATCH 5/5] sdhci-s3c: Add support no internal clock divider in host controller

2010-09-29 Thread Jeongbae Seo 
Chris wrote:

 Hi Kyungmin, Ben,
 
 On Thu, Sep 30, 2010 at 10:18:12AM +0900, Kyungmin Park wrote:
  On Sat, Sep 18, 2010 at 12:59 AM, Chris Ball c...@laptop.org wrote:
   Hi,
  
   On Thu, Sep 16, 2010 at 06:08:28PM +0900, Kyungmin Park wrote:
   Well there are two implementations. and no conclusion yet.
   as s5pc210 don't support internal SDHCI clock, DMC overrides the
   function operation itself when s5pc210. System LSI use the quirks.
  
   Choose any one from MMC maintainer.
  
   Both approaches are generally acceptable for MMC, so I would want to
   leave it up to the maintainer of the driver in question (which is Ben,
   in this case?) to choose between them.
 
  Hi Chris,
 
  Did you get the opinion from Ben?
 
  I hope this decision will be done before 2.6.37 merge windows start to
  support SDHCI support on s5pc210.
 
 Hm, I didn't, and Ben's been silent about the urgent sdhci-s3c patches
 too.  Ben, are you just dealing with a large backlog, or are you
 interested in nominating someone else to take over sdhci-s3c?

Hi Chris, Kyungmin

I'd like to let you know that Ben had reviewed and commented for
[PATCH v2 2/2] sdhci-s3c: Add support no internal clock divider in host
controller in 9/21. However, our response was late due to our holidays. I
made a response in 9/28 that why we use this quirk and now we're waiting for
his opinion.

Kyungmin, did you check Ben's review comments for this ? When I saw it, his
approach is just a bit different from you and me. Please let us know if you
have any idea about his comments.

Thanks,
Best Regards
Jeongbae Seo

--
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] sdhci: add support for sd 3.0 host and hooks for dual data rate eMMC

2010-09-29 Thread Chris Ball 
Hi Philip,

On Wed, Sep 29, 2010 at 10:27:12PM -0700, Philip Rakity wrote:
 This code has not been tested on mmc-test but has been patched against.  I 
 have run it against 2.6.32 (with some minor changes).
 
 I wanted to give folks a chance to comment before making it a formal patch.  
 The code add the hooks into the sdhci layer for 
 version 3.0 of the controller, including mmc/eMMC dual data rate support 
 (ddr).The next RFC adds support for DDR at the mmc layer

This doesn't apply against mmc-next, in part because it duplicates code
from Zhangfei's SDHC 3.0 patches in mmc-next here:

http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=90ce6eed919bf30fa545bbe93265bc6c463cedda
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=07f1a246a56b12fe85897580cc696160f41e3983
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commit;h=0bd7f9f081e9131d4d724f3a3bd19a500c10a5e3

and from Hanumath's DDR 4.4 patch, and Adrian's additions to it, which I
haven't merged into -next yet but plan to soon -- I've been waiting for
more feedback on them.  They already add DDR support at the MMC layer:

https://patchwork.kernel.org/patch/177312/
https://patchwork.kernel.org/patch/177332/

If you could study these and rebase your patch on top of all of them,
it would help us see what you're changing.

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