Re: [PATCH] mmc: core: Clean up after mmc_pre_req if card was removed

2012-03-02 Thread Ulf Hansson 

Hi Jaehoon,

I did not know this. Which host driver are you using? I would very much 
appreciate of you could debug and share some result.


Thanks!

BR
Ulf Hansson

On 03/02/2012 09:28 AM, Jaehoon Chung wrote:

Hi Ulf.

I tested with this patch.
But in my environment, this patch didn't work fine before.
1) When remove/insert, didn't entered the suspend.
2) When removed during something write,
[   50.755067] FAT-fs (mmcblk1p1): Directory bread(block 8254) failed
[   50.761235] FAT-fs (mmcblk1p1): Directory bread(block 8255) failed
then at next-time, didn't detect sd-card.

Did you know this?
If you want more information, i will debug, and share the result.

Best Regards,
Jaehoon Chung

On 03/02/2012 12:44 AM, Ulf Hansson wrote:


Make sure mmc_start_req cancel the prepared job, if the request
was prevented to be started due to the card has been removed.

This bug was introduced in commit:
mmc: allow upper layers to know immediately if card has been removed

Signed-off-by: Ulf Hanssonulf.hans...@stericsson.com
---
  drivers/mmc/core/core.c |   35 +++
  1 files changed, 15 insertions(+), 20 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b317f0..9e562ab 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -249,16 +249,17 @@ static void mmc_wait_done(struct mmc_request *mrq)
complete(mrq-completion);
  }

-static void __mmc_start_req(struct mmc_host *host, struct mmc_request *mrq)
+static int __mmc_start_req(struct mmc_host *host, struct mmc_request *mrq)
  {
init_completion(mrq-completion);
mrq-done = mmc_wait_done;
if (mmc_card_removed(host-card)) {
mrq-cmd-error = -ENOMEDIUM;
complete(mrq-completion);
-   return;
+   return -ENOMEDIUM;
}
mmc_start_request(host, mrq);
+   return 0;
  }

  static void mmc_wait_for_req_done(struct mmc_host *host,
@@ -342,6 +343,7 @@ struct mmc_async_req *mmc_start_req(struct mmc_host *host,
struct mmc_async_req *areq, int *error)
  {
int err = 0;
+   int start_err = 0;
struct mmc_async_req *data = host-areq;

/* Prepare a new request */
@@ -351,30 +353,23 @@ struct mmc_async_req *mmc_start_req(struct mmc_host *host,
if (host-areq) {
mmc_wait_for_req_done(host, host-areq-mrq);
err = host-areq-err_check(host-card, host-areq);
-   if (err) {
-   /* post process the completed failed request */
-   mmc_post_req(host, host-areq-mrq, 0);
-   if (areq)
-   /*
-* Cancel the new prepared request, because
-* it can't run until the failed
-* request has been properly handled.
-*/
-   mmc_post_req(host, areq-mrq, -EINVAL);
-
-   host-areq = NULL;
-   goto out;
-   }
}

-   if (areq)
-   __mmc_start_req(host, areq-mrq);
+   if (!err  areq)
+   start_err = __mmc_start_req(host, areq-mrq);

if (host-areq)
mmc_post_req(host, host-areq-mrq, 0);

-   host-areq = areq;
- out:
+   if (err || start_err) {
+   if (areq)
+   /* The prepared request was not started, cancel it. */
+   mmc_post_req(host, areq-mrq, -EINVAL);
+   host-areq = NULL;
+   } else {
+   host-areq = areq;
+   }
+
if (error)
*error = err;
return data;






--
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] ARM: OMAP: hsmmc: add max_freq field

2012-03-02 Thread S, Venkatraman 
On Fri, Mar 2, 2012 at 12:41 PM, S, Venkatraman svenk...@ti.com wrote:
 +Chris queues all MMC patches including omap_hsmmc.
 Ping ?

Just realized that it's already queued in mmc-next
http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commitdiff;h=25d6ba8171995230b3757c78c7470fa76a931b98



 On Fri, Mar 2, 2012 at 5:41 AM, Tony Lindgren t...@atomide.com wrote:
 Hi,

 * Daniel Mack zon...@gmail.com [120217 05:13]:
 ping? Could anyone care for queueing this please?

 I suggest Rajendra queue up omap_hsmmc.c patches as he's already
 patching it.

 Regards,

 Tony


 On Thu, Dec 29, 2011 at 2:22 PM, Daniel Mack zon...@gmail.com wrote:
  On 12/23/2011 04:40 PM, T Krishnamoorthy, Balaji wrote:
  On Wed, Dec 14, 2011 at 6:52 PM, Daniel Mack zon...@gmail.com wrote:
  diff --git a/drivers/mmc/host/omap_hsmmc.c 
  b/drivers/mmc/host/omap_hsmmc.c
  index 101cd31..8215ef9 100644
  --- a/drivers/mmc/host/omap_hsmmc.c
  +++ b/drivers/mmc/host/omap_hsmmc.c
  @@ -1927,8 +1927,12 @@ static int __init omap_hsmmc_probe(struct 
  platform_device *pdev)
         if (mmc_slot(host).vcc_aux_disable_is_sleep)
                 mmc_slot(host).no_off = 1;
 
  -       mmc-f_min      = OMAP_MMC_MIN_CLOCK;
  -       mmc-f_max      = OMAP_MMC_MAX_CLOCK;
  +       mmc-f_min = OMAP_MMC_MIN_CLOCK;
 
  Stray change for f_min ?
 
  No, this was intended. The indentation doesn't make sense anymore when
  not grouped with the f_max assignment.
 
  Other than that, what is necessary to get this picked? Tony? :)
 
 
  Thanks,
  Daniel
 --
 To unsubscribe from this list: send the line unsubscribe linux-mmc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] gpiolib: Add gpiochip_find_by_name() and gpio_find_by_chip_name()

2012-03-02 Thread Grant Likely 
On Thu, 01 Mar 2012 10:55:24 -0800, Tony Lindgren t...@atomide.com wrote:
 Currently there is no way for drivers to request a GPIO on a particular
 gpio chip. This makes it hard to support multiple GPIO controllers
 with dynamic GPIO and interrupt numbering, such as with CONFIG_SPARSE_IRQ.
 
 Make it easier for device drivers to find GPIOs on a specific gpio_chip
 by adding two functions: gpiochip_find_by_name() and gpio_find_by_chip_name().
 
 Note that as gpiochip_find() is already exported, we may as well
 export gpiochip_find_by_name() too.

How is the device going to know the name of the gpio controller?  I
don't particularly like interfaces that find devices by-names since
I don't think device names can be relied to be stable when devices
are instantiated from device tree data.

 
 Cc: Grant Likely grant.lik...@secretlab.ca
 Cc: Linus Walleij linus.wall...@stericsson.com
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Rajendra Nayak rna...@ti.com
 Signed-off-by: Tony Lindgren t...@atomide.com
 ---
  drivers/gpio/gpiolib.c |   47 
 
  include/asm-generic/gpio.h |3 ++-
  2 files changed, 49 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
 index 17fdf4b..0e5bf55 100644
 --- a/drivers/gpio/gpiolib.c
 +++ b/drivers/gpio/gpiolib.c
 @@ -1173,6 +1173,53 @@ struct gpio_chip *gpiochip_find(void *data,
  }
  EXPORT_SYMBOL_GPL(gpiochip_find);
  
 +static int match_name(struct gpio_chip *chip, void *data)

Even though this is a static, please keep the prefix to avoid
namespace conflicts.  gpiochip_match_name()

 +{
 + const char *name = data;

This is unnecessary; the void* can be passed directly to sysfs_streq...
but why is sysfs_streq being used here instead of strcmp?  This is 
not sysfs related code.

 +
 + return sysfs_streq(name, chip-label);
 +}
 +
 +/**
 + * gpiochip_find_by_name() - iterator for locating a gpio_chip by name
 + * @name: name of the gpio_chip
 + *
 + * Similar to bus_find_device_by_name. It returns a reference to the
 + * first gpio_chip with matching name. It ignores NULL and empty names.
 + * If you need to do something more complex, then use gpiochip_find.
 + */
 +struct gpio_chip *gpiochip_find_by_name(const char *name)
 +{
 + if (!name || !strcmp(name, ))
 + return NULL;
 +
 + return gpiochip_find((void *)name, match_name);

Nasty cast.  Can the signature for gpiochip_find be changed to accept
a (const void *)?

 +}
 +EXPORT_SYMBOL_GPL(gpiochip_find_by_name);
 +
 +/**
 + * gpio_find_by_chip_name() - find a gpio on a specific gpio_chip
 + * @chip_name: name of the gpio_chip
 + * @gpio_offset: offset of the gpio on the gpio_chip
 + *
 + * Note that gpiochip_find_by_name returns the first matching
 + * gpio_chip name. For more complex matching, see gpio_find.
 + */
 +int gpio_find_by_chip_name(const char *chip_name, unsigned gpio_offset)
 +{
 + struct gpio_chip *chip;
 + int gpio, res;
 +
 + chip = gpiochip_find_by_name(chip_name);
 + if (!chip)
 + return -ENODEV;
 +
 + gpio = chip-base + gpio_offset;
 +
 + return gpio;
 +}
 +EXPORT_SYMBOL_GPL(gpio_find_by_chip_name);
 +
  /* These optional allocation calls help prevent drivers from stomping
   * on each other, and help provide better diagnostics in debugfs.
   * They're called even less than the set direction calls.
 diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
 index 1ff4e22..d7a2100 100644
 --- a/include/asm-generic/gpio.h
 +++ b/include/asm-generic/gpio.h
 @@ -145,7 +145,8 @@ extern int __must_check gpiochip_remove(struct gpio_chip 
 *chip);
  extern struct gpio_chip *gpiochip_find(void *data,
   int (*match)(struct gpio_chip *chip,
void *data));
 -
 +extern struct gpio_chip *gpiochip_find_by_name(const char *name);
 +extern int gpio_find_by_chip_name(const char *chip_name, unsigned 
 gpio_offset);
  
  /* Always use the library code for GPIO management calls,
   * or when sleeping may be involved.
 

-- 
email sent from notmuch.vim plugin
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 4/4] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect

2012-03-02 Thread Samuel Ortiz 
Hi Tony,

On Thu, Mar 01, 2012 at 10:55:35AM -0800, Tony Lindgren wrote:
 There's no need to use callbacks for this, we can
 do it directly between MMC driver and twl6030.
 
 Cc: Samuel Ortiz sa...@linux.intel.com
Acked-by: Samuel Ortiz sa...@linux.intel.com

Cheers,
Samuel.

-- 
Intel Open Source Technology Centre
http://oss.intel.com/
--
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: core: Fixup suspend/resume issues for UHS-I cards

2012-03-02 Thread Subhash Jadavani 

Tested-by: Subhash Jadavani subha...@codeaurora.org

On 3/2/2012 12:27 AM, Philip Rakity wrote:

acked-by: Philip Rakityprak...@marvell.com

On Mar 1, 2012, at 4:18 AM, Ulf Hansson wrote:


Even if cards supports 1.8V I/O voltage those should anyway be
initialized at 3.3V I/O according to (e)MMC, SD and SDIO specs.
Some eMMC and embedded SDIO devices are able to be initialized
at 1.8V as well, but it is better to be safe.

Do note that initialization in this context means that the card
has been completely powered off, otherwise the card will remain
at the last I/O voltage level that were negotitiated.

Due to the above being taken care of the suspend/resume issues
for UHS-I SD-cards has been fixed.

Change-Id: Ia906f69d44b5be8374b0b536881190f67757b03e
Signed-off-by: Ulf Hanssonulf.hans...@stericsson.com
---
drivers/mmc/core/core.c |3 +++
drivers/mmc/core/mmc.c  |3 +++
drivers/mmc/core/sd.c   |8 +++-
drivers/mmc/core/sdio.c |9 +
4 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b317f0..faa0af1 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2074,6 +2074,9 @@ static int mmc_rescan_try_freq(struct mmc_host *host, 
unsigned freq)
 */
mmc_hw_reset_for_init(host);

+   /* Initialization should be done at 3.3 V I/O voltage. */
+   mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
+
/*
 * sdio_reset sends CMD52 to reset card.  Since we do not know
 * if the card is being re-initialized, just send it.  CMD52
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 6b13776..6defddd 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -830,6 +830,9 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
if (!mmc_host_is_spi(host))
mmc_set_bus_mode(host, MMC_BUSMODE_OPENDRAIN);

+   /* Initialization should be done at 3.3 V I/O voltage. */
+   mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
+
/*
 * Since we're changing the OCR value, we seem to
 * need to tell some cards to go back to the idle
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 5017f93..c272c686 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -911,6 +911,9 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 ocr,
BUG_ON(!host);
WARN_ON(!host-claimed);

+   /* The initialization should be done at 3.3 V I/O voltage. */
+   mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
+
err = mmc_sd_get_cid(host, ocr, cid,rocr);
if (err)
return err;
@@ -1156,11 +1159,6 @@ int mmc_attach_sd(struct mmc_host *host)
BUG_ON(!host);
WARN_ON(!host-claimed);

-   /* Make sure we are at 3.3V signalling voltage */
-   err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, false);
-   if (err)
-   return err;
-
/* Disable preset value enable if already set since last time */
if (host-ops-enable_preset_value) {
mmc_host_clk_hold(host);
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 12cde6e..dac2e23 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -585,6 +585,10 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 
ocr,
 * Inform the card of the voltage
 */
if (!powered_resume) {
+
+   /* The initialization should be done at 3.3 V I/O voltage. */
+   mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
+
err = mmc_send_io_op_cond(host, host-ocr,ocr);
if (err)
goto err;
@@ -996,6 +1000,11 @@ static int mmc_sdio_power_restore(struct mmc_host *host)
 * With these steps taken, mmc_select_voltage() is also required to
 * restore the correct voltage setting of the card.
 */
+
+   if (!mmc_card_keep_power(host))
+   /* The initialization should be done at 3.3 V I/O voltage. */
+   mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
+
sdio_reset(host);
mmc_go_idle(host);
mmc_send_if_cond(host, host-ocr_avail);
--
1.7.7.2

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


--
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 v5 2/2] mmc: core: Support packed command for eMMC4.5 device

2012-03-02 Thread merez 
Hi,

Our tests showed that the write packing improved the performance of the
write sequential operations:

Long write operation:
--
no-packing: 15.8 MB/s
packed commands patch (both READ and WRITE packing are enabled): 23.3 MB/s

Several parallel write operations (sum of all the write throughputs):
---
no-packing: 17.1 MB/s
packed commands patch(both READ and WRITE packing are enabled): 25 MB/s

Parallel long read and long write operations (write throughput):
-
no-packing: 12.2 MB/s
packed commands patch (both READ and WRITE packing are enabled): 16.3 MB/s

Parallel short read and long write operations (write throughput):
-
no-packing: 15.4 MB/s
packed commands patch (both READ and WRITE packing are enabled): 16.4 MB/s

Several Parallel short read and short write operations (sum of all the
write throughputs):
--
no-packing: 12.5 MB/s
packed commands patch (both READ and WRITE packing are enabled): 15.5 MB/s


Random read and random write:
--
I checked the random read and random write IOPs by using the IOZONE
application. There was a slight degradation in the read results due to the
packing and no improvements in the write results.

The results are:

IOZONE file size of 100M:
no-packing: random read: 4675, random write: 729
packed commands patch (both READ and WRITE packing are enabled): random
read: 4557 random write: 723

IOZONE file size of 256M:
no-packing: random read: 4632, random write: 744
packed commands patch (both READ and WRITE packing are enabled): random
read: 4498, random write: 742

Thanks,
Maya Erez
Consultant for Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

 Hi. merez.

 Would you share random read speed with us ?

 And Write speed also..

 Thanks.

 2012/3/1  me...@codeaurora.org:
 This patch supports packed command of eMMC4.5 device.
 Several reads(or writes) can be grouped in packed command
 and all data of the individual commands can be sent in a
 single transfer on the bus.

 Signed-off-by: Seungwon Jeon tgih@samsung.com
 ---
  drivers/mmc/card/block.c   |  496
 +--
  drivers/mmc/card/queue.c   |   48 -
  drivers/mmc/card/queue.h   |   13 ++
  drivers/mmc/core/mmc_ops.c |    1 +
  include/linux/mmc/core.h   |    4 +
  5 files changed, 535 insertions(+), 27 deletions(-)

 Hi,

 We ran performance tests on the packed commands patch. We found out that
 enabling the read packing didn't improve the performance in any of the
 scenarios we ran (see the detailed results below).
 Therefore, we suggest to move the read packing code to a different patch
 and approve only the write packing code for now. The read packing adds
 complexity to the code and we don't see a point in adding it while the
 intention is to disable it.

 Test results:

 Long read operation:
 --
 no-packing: 39.5 MB/s
 packed commands patch (both READ and WRITE packing are enabled): 39.5
 MB/s
 packed commands patch + enabling only READ packing: 39.5 MB/s

 Several parallel read operations (sum of all the read throughputs):
 ---
 no-packing: 42.6 MB/s
 packed commands patch(both READ and WRITE packing are enabled): 38 MB/s
 packed commands patch + enabling only READ packing: 38.2 MB/s

 Parallel long read and long write operations (read throughput):
 -
 no-packing: 23.8 MB/s
 packed commands patch (both READ and WRITE packing are enabled): 12.6
 MB/s
 packed commands patch + enabling only READ packing: 12.5 MB/s

 Parallel short read and long write operations (read throughput):
 -
 no-packing: 22.9 MB/s
 packed commands patch (both READ and WRITE packing are enabled): 8.4
 MB/s
 packed commands patch + enabling only READ packing: 8.6 MB/s

 Several Parallel short read and short write operations (sum of all the
 read throughputs):
 --
 no-packing: 41.6 MB/s
 packed commands patch (both READ and WRITE packing are enabled): 35 MB/s
 packed commands patch + enabling only READ packing: 36 MB/s

 Thanks,
 Maya Erez
 Consultant for Qualcomm Innovation Center, Inc.
 Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum





 --
 To unsubscribe from this list: send the line unsubscribe linux-mmc in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 --
 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

Re: [RESEND PATCH] mmc: core: Fixup suspend/resume issues for UHS-I cards

2012-03-02 Thread Ulf Hansson 

Hi,

The reason for the RESEND was due to a missed removal of a gerrit 
change id. The patch has not change as such.


Br
Ulf Hansson

On 03/01/2012 04:48 PM, Ulf HANSSON wrote:

Even if cards supports 1.8V I/O voltage those should anyway be
initialized at 3.3V I/O according to (e)MMC, SD and SDIO specs.
Some eMMC and embedded SDIO devices are able to be initialized
at 1.8V as well, but it is better to be safe.

Do note that initialization in this context means that the card
has been completely powered off, otherwise the card will remain
at the last I/O voltage level that were negotitiated.

Due to the above being taken care of the suspend/resume issues
for UHS-I SD-cards has been fixed.

Signed-off-by: Ulf Hanssonulf.hans...@stericsson.com
---
  drivers/mmc/core/core.c |3 +++
  drivers/mmc/core/mmc.c  |3 +++
  drivers/mmc/core/sd.c   |8 +++-
  drivers/mmc/core/sdio.c |9 +
  4 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 0b317f0..faa0af1 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2074,6 +2074,9 @@ static int mmc_rescan_try_freq(struct mmc_host *host, 
unsigned freq)
 */
mmc_hw_reset_for_init(host);

+   /* Initialization should be done at 3.3 V I/O voltage. */
+   mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
+
/*
 * sdio_reset sends CMD52 to reset card.  Since we do not know
 * if the card is being re-initialized, just send it.  CMD52
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 6b13776..6defddd 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -830,6 +830,9 @@ static int mmc_init_card(struct mmc_host *host, u32 ocr,
if (!mmc_host_is_spi(host))
mmc_set_bus_mode(host, MMC_BUSMODE_OPENDRAIN);

+   /* Initialization should be done at 3.3 V I/O voltage. */
+   mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
+
/*
 * Since we're changing the OCR value, we seem to
 * need to tell some cards to go back to the idle
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 5017f93..c272c686 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -911,6 +911,9 @@ static int mmc_sd_init_card(struct mmc_host *host, u32 ocr,
BUG_ON(!host);
WARN_ON(!host-claimed);

+   /* The initialization should be done at 3.3 V I/O voltage. */
+   mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
+
err = mmc_sd_get_cid(host, ocr, cid,rocr);
if (err)
return err;
@@ -1156,11 +1159,6 @@ int mmc_attach_sd(struct mmc_host *host)
BUG_ON(!host);
WARN_ON(!host-claimed);

-   /* Make sure we are at 3.3V signalling voltage */
-   err = mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, false);
-   if (err)
-   return err;
-
/* Disable preset value enable if already set since last time */
if (host-ops-enable_preset_value) {
mmc_host_clk_hold(host);
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 12cde6e..dac2e23 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -585,6 +585,10 @@ static int mmc_sdio_init_card(struct mmc_host *host, u32 
ocr,
 * Inform the card of the voltage
 */
if (!powered_resume) {
+
+   /* The initialization should be done at 3.3 V I/O voltage. */
+   mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
+
err = mmc_send_io_op_cond(host, host-ocr,ocr);
if (err)
goto err;
@@ -996,6 +1000,11 @@ static int mmc_sdio_power_restore(struct mmc_host *host)
 * With these steps taken, mmc_select_voltage() is also required to
 * restore the correct voltage setting of the card.
 */
+
+   if (!mmc_card_keep_power(host))
+   /* The initialization should be done at 3.3 V I/O voltage. */
+   mmc_set_signal_voltage(host, MMC_SIGNAL_VOLTAGE_330, 0);
+
sdio_reset(host);
mmc_go_idle(host);
mmc_send_if_cond(host, host-ocr_avail);


--
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: core: Clean up after mmc_pre_req if card was removed

2012-03-02 Thread Per Förlin 
On 03/02/2012 09:51 AM, Ulf HANSSON wrote:
 Hi Jaehoon,
 
 I did not know this. Which host driver are you using? I would very much 
 appreciate of you could debug and share some result.
 
 Thanks!
 
 BR
 Ulf Hansson
 
 On 03/02/2012 09:28 AM, Jaehoon Chung wrote:
 Hi Ulf.

 I tested with this patch.
 But in my environment, this patch didn't work fine before.
 1) When remove/insert, didn't entered the suspend.
 2) When removed during something write,
 [   50.755067] FAT-fs (mmcblk1p1): Directory bread(block 8254) failed
 [   50.761235] FAT-fs (mmcblk1p1): Directory bread(block 8255) failed
 then at next-time, didn't detect sd-card.

 Did you know this?
 If you want more information, i will debug, and share the result.

 Best Regards,
 Jaehoon Chung

 On 03/02/2012 12:44 AM, Ulf Hansson wrote:

 Make sure mmc_start_req cancel the prepared job, if the request
 was prevented to be started due to the card has been removed.

 This bug was introduced in commit:
 mmc: allow upper layers to know immediately if card has been removed

 Signed-off-by: Ulf Hanssonulf.hans...@stericsson.com
 ---
   drivers/mmc/core/core.c |   35 +++
   1 files changed, 15 insertions(+), 20 deletions(-)

 diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
 index 0b317f0..9e562ab 100644
 --- a/drivers/mmc/core/core.c
 +++ b/drivers/mmc/core/core.c
 @@ -249,16 +249,17 @@ static void mmc_wait_done(struct mmc_request *mrq)
 complete(mrq-completion);
   }

 -static void __mmc_start_req(struct mmc_host *host, struct mmc_request *mrq)
 +static int __mmc_start_req(struct mmc_host *host, struct mmc_request *mrq)
   {
 init_completion(mrq-completion);
 mrq-done = mmc_wait_done;
 if (mmc_card_removed(host-card)) {
 mrq-cmd-error = -ENOMEDIUM;
 complete(mrq-completion);
 -   return;
 +   return -ENOMEDIUM;
 }
 mmc_start_request(host, mrq);
 +   return 0;
   }

   static void mmc_wait_for_req_done(struct mmc_host *host,
 @@ -342,6 +343,7 @@ struct mmc_async_req *mmc_start_req(struct mmc_host 
 *host,
 struct mmc_async_req *areq, int *error)
   {
 int err = 0;
 +   int start_err = 0;
 struct mmc_async_req *data = host-areq;

 /* Prepare a new request */
 @@ -351,30 +353,23 @@ struct mmc_async_req *mmc_start_req(struct mmc_host 
 *host,
 if (host-areq) {
 mmc_wait_for_req_done(host, host-areq-mrq);
 err = host-areq-err_check(host-card, host-areq);
 -   if (err) {
 -   /* post process the completed failed request */
 -   mmc_post_req(host, host-areq-mrq, 0);
 -   if (areq)
 -   /*
 -* Cancel the new prepared request, because
 -* it can't run until the failed
 -* request has been properly handled.
 -*/
 -   mmc_post_req(host, areq-mrq, -EINVAL);
 -
 -   host-areq = NULL;
 -   goto out;
 -   }
 }

 -   if (areq)
 -   __mmc_start_req(host, areq-mrq);
 +   if (!err  areq)
 +   start_err = __mmc_start_req(host, areq-mrq);

 if (host-areq)
 mmc_post_req(host, host-areq-mrq, 0);

 -   host-areq = areq;
 - out:
 +   if (err || start_err) {
 +   if (areq)
 +   /* The prepared request was not started, cancel it. */
 +   mmc_post_req(host, areq-mrq, -EINVAL);
 +   host-areq = NULL;
There seems to be an issue when setting host-areq=NULL when __mmc_start_req 
fails. host-areq == NULL indicates there are no ongoing transfers.
host-areq is used in block.c to check if there are pending requests. 

This seem to work:
...
if (err || start_err) {
if (areq)
/* The prepared request was not started, cancel it. */
mmc_post_req(host, areq-mrq, -EINVAL);
}

if (err)
host-areq = NULL;
else
host-areq = areq;
...

This issue will be addressed in version 2. How to resolve it is not decided 
yet. 

Feel free to comment,
Per
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] gpiolib: Add gpiochip_find_by_name() and gpio_find_by_chip_name()

2012-03-02 Thread Tony Lindgren 
Hi,

Correcting a typo in the LKML address..

* Grant Likely grant.lik...@secretlab.ca [120302 01:00]:
 On Thu, 01 Mar 2012 10:55:24 -0800, Tony Lindgren t...@atomide.com wrote:
  Currently there is no way for drivers to request a GPIO on a particular
  gpio chip. This makes it hard to support multiple GPIO controllers
  with dynamic GPIO and interrupt numbering, such as with CONFIG_SPARSE_IRQ.
  
  Make it easier for device drivers to find GPIOs on a specific gpio_chip
  by adding two functions: gpiochip_find_by_name() and 
  gpio_find_by_chip_name().
  
  Note that as gpiochip_find() is already exported, we may as well
  export gpiochip_find_by_name() too.
 
 How is the device going to know the name of the gpio controller?  I
 don't particularly like interfaces that find devices by-names since
 I don't think device names can be relied to be stable when devices
 are instantiated from device tree data.

The gpio_chip name + gpio offset is coming from pdata until things
are converted over to use DT.

For DT, this should not be needed, this is needed for removing callbacks
in pdata so we can clean up some drivers and keep them working with
both pdata and DT until things are converted over to DT.

  +static int match_name(struct gpio_chip *chip, void *data)
 
 Even though this is a static, please keep the prefix to avoid
 namespace conflicts.  gpiochip_match_name()
 
  +{
  +   const char *name = data;
 
 This is unnecessary; the void* can be passed directly to sysfs_streq...
 but why is sysfs_streq being used here instead of strcmp?  This is 
 not sysfs related code.

That comes from the bus code, will take a look.
 
  +
  +   return sysfs_streq(name, chip-label);
  +}
  +
  +/**
  + * gpiochip_find_by_name() - iterator for locating a gpio_chip by name
  + * @name: name of the gpio_chip
  + *
  + * Similar to bus_find_device_by_name. It returns a reference to the
  + * first gpio_chip with matching name. It ignores NULL and empty names.
  + * If you need to do something more complex, then use gpiochip_find.
  + */
  +struct gpio_chip *gpiochip_find_by_name(const char *name)
  +{
  +   if (!name || !strcmp(name, ))
  +   return NULL;
  +
  +   return gpiochip_find((void *)name, match_name);
 
 Nasty cast.  Can the signature for gpiochip_find be changed to accept
 a (const void *)?

I think so, this too comes from the bus code.

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

Re: [PATCH 2/4] mmc: omap_hsmmc: Use gpio_find_by_chip_name() for omap_hsmmc_gpio_init()

2012-03-02 Thread Tony Lindgren 
* Rajendra Nayak rna...@ti.com [120301 21:23]:
 On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
 Use gpio_find_by_chip_name() to find the GPIO pins as they can
 be dynamically allocated on various gpio_chips.
 
 Note that we don't want to touch the platform data as it can
 now specify the GPIO offset on a named gpio_chip.
 
 This removes the need to use callbacks to set the GPIO pins
 in platform data.
 
 While one of the reasons for those callbacks was to set the GPIO
 pins in platform data, I guess the other and more important one
 was to make sure the init sequencing between twl4030-gpio and the
 mmc device depending on it was done rightly. Doesn't this patch now
 leave the sequencing to work by luck (in the absence of something
 like deferred probe being in place) like is the case of twl6030 and
 mmc init sequence on OMAP4 already?

Nope :) The difference is that  we can exit and produce a sensible
error to the user about the particular gpio_chip not being available.

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

Re: [PATCH 2/4] mmc: omap_hsmmc: Use gpio_find_by_chip_name() for omap_hsmmc_gpio_init()

2012-03-02 Thread Tony Lindgren 
* Rajendra Nayak rna...@ti.com [120301 22:54]:
 On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
 +if (slot-gpiochip_cd) {
 +pr_warning(MMC %s card detect GPIO chip %s 
 unavailable\n,
 +slot-name, slot-gpiochip_cd);
 +ret = -ENODEV;
 +goto err_free_sp;
 
 This should just return -ENODEV, nothing really to free here.

Thanks, will correct.
 
 @@ -2093,8 +2123,7 @@ err1:
  platform_set_drvdata(pdev, NULL);
  mmc_free_host(mmc);
   err_alloc:
 -omap_hsmmc_gpio_free(pdata);
 -err:
 +omap_hsmmc_gpio_free(host);
 
 This error handling needs to be fixed up. In case
 omap_hsmmc_gpio_init() fails, which already frees up
 any requested gpios, omap_hsmmc_gpio_free() again tries
 freeing gpios.

Hmm that sounds like a separate patch that should be a fixed
before this series?

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

Re: [PATCH 3/4] mmc: omap_hsmmc: Use GPIO offset for external GPIO chips

2012-03-02 Thread Tony Lindgren 
* Rajendra Nayak rna...@ti.com [120301 21:31]:
 On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
 --- a/arch/arm/mach-omap2/board-3430sdp.c
 +++ b/arch/arm/mach-omap2/board-3430sdp.c
 @@ -231,14 +231,16 @@ static struct omap2_hsmmc_info mmc[] = {
   * so the SIM card isn't used; else 4 bits.
   */
  .caps   = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
 +.gpiochip_cd= twl4030_gpio,
 +.gpio_cd= 0,/* mmc0_cd offset in twl4030 */
  .gpio_wp= 4,
 -.deferred   = true,
 
 Shouldn't this patch completely get rid of all the 'deferred'
 infrastructure that was put in place, including the
 omap_hsmmc_late_init() function, since there is no need for it
 anymore?

Yes, that was needed as a fix so unfortunately there's a little
bit going back and forth. But now we can get rid of other stuff
too in addition to deferred omap_hsmmc_late_init(), we can remove
init and cleanup callbacks for hsmmc. I'll do another patch for
that.

 --- a/arch/arm/mach-omap2/board-omap3pandora.c
 +++ b/arch/arm/mach-omap2/board-omap3pandora.c
 @@ -270,19 +270,19 @@ static struct omap2_hsmmc_info omap3pandora_mmc[] = {
  {
  .mmc= 1,
  .caps   = MMC_CAP_4_BIT_DATA,
 -.gpio_cd= -EINVAL,
 +.gpiochip_cd= twl4030_gpio,
 +.gpio_cd= 0,/* mmc0_cd offset in twl4030 */
  .gpio_wp= 126,
  .ext_clock  = 0,
 -.deferred   = true,
  },
  {
  .mmc= 2,
  .caps   = MMC_CAP_4_BIT_DATA,
 -.gpio_cd= -EINVAL,
 +.gpiochip_cd= twl4030_gpio,
 +.gpio_cd= 0,/* mmc0_cd offset in twl4030 */
 
 This one should be gpio_cd = 1,

Thanks, will correct.

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

Re: [PATCH 4/4] mmc: omap_hsmmc: Simplify init for twl6030 MMC card detect

2012-03-02 Thread Tony Lindgren 
* Rajendra Nayak rna...@ti.com [120301 21:38]:
 On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
 --- a/arch/arm/mach-omap2/board-omap4panda.c
 +++ b/arch/arm/mach-omap2/board-omap4panda.c
 @@ -153,8 +153,8 @@ static struct omap2_hsmmc_info mmc[] = {
  {
  .mmc= 1,
  .caps   = MMC_CAP_4_BIT_DATA | MMC_CAP_8_BIT_DATA,
 -.gpio_wp= -EINVAL,
  .gpio_cd= -EINVAL,
 +.gpio_wp= -EINVAL,
 
 stray change.

Hmm I'd like to keep this change before this ordering gets copied
to ten other board files that we may have in testing-board for a while..
I'll add a comment to the patch description about that.

 --- a/drivers/mmc/host/omap_hsmmc.c
 +++ b/drivers/mmc/host/omap_hsmmc.c
 @@ -34,6 +34,7 @@
   #includelinux/gpio.h
   #includelinux/regulator/consumer.h
   #includelinux/pm_runtime.h
 +#includelinux/i2c/twl.h
   #includeplat/dma.h
   #includemach/hardware.h
   #includeplat/board.h
 @@ -578,6 +579,32 @@ static void omap_hsmmc_gpio_free(struct omap_hsmmc_host 
 *host)
  gpio_free(host-gpio_cd);
   }
 
 +#ifdef CONFIG_TWL4030_CORE
 +static int omap_hsmmc_init_twl6030(struct omap_hsmmc_host *host)
 +{
 +struct omap_mmc_platform_data *pdata = host-pdata;
 +struct omap_mmc_slot_data *slot =pdata-slots[0];
 +int irq;
 +
 +if (gpio_is_valid(host-gpio_cd) || host-id)
 
 I have a series, which I am asking Chris to pull, which completely
 gets rid of all host-id based hard-codings' in the driver.
 Isn't there a better way to do this than rely on the device instance?

Yes I was thinking about that too. I guess we need to pass some
flag in pdata for twl6030 card detect. I was thinking about using
the gpiochip_cd, but twl6030 is not gpio based card detect, so
a separate flag is better.

BTW, with -rc5, looks like re-inserting omap_hsmmc on omap4 fails
to detect any cards, and then fails to unload. This works on omap3
just fine. Any ideas why that would be?

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

Re: [PATCH 0/4] Start getting rid of pdata callbacks with gpio_find_by_chip_name()

2012-03-02 Thread Tony Lindgren 
* Rajendra Nayak rna...@ti.com [120302 00:35]:
 Hi Tony,
 
 On Friday 02 March 2012 12:25 AM, Tony Lindgren wrote:
 Hi all,
 
 This series adds gpio_find_by_name() that allows finding
 GPIOs on specific gpio_chips. As the GPIO numbers can be
 dynamic, it's hard to find the GPIO numbers from drivers
 using them directly.
 
 So far we've dealt with this using platform specific callbacks,
 but that is messy. This series removes the needs for these
 callbacks for omap hsmmc driver. Further callbacks can be
 removed people are OK with adding gpio_find_by_name().
 
 This series is based on the omap fixes-non-critical that's
 needed for the arch/arm/mach-omap2 parts of this series.
 
 I tested these on my beagle/panda/omap4sdp and they seem to
 work fine, also fixing the broken panda card detect (due to
 missing card_detect_irq in the board file). There are still
 issues however when I build twl4030-gpio as a module, which I
 already commented on, and the fact that the init sequence now
 works by luck :)

Hmm it should not be luck based, loading omap_hsmmc module
should fail with a sensible error if the configured card detect
or write protect is not available.

I guess this is with twl6030 non-gpio based card detect?

If so, I'll add something to pass the twl6030 card detect from
pdata so we can fail with a sensible error in that case too.

Also, sounds like twl as module and mmc built in case won't
work without deferred probe. But at least there is a sensible
error for that. And maybe we can prevent that in Kconfig.

 The other issue also is that the multiple insmod/rmmod test
 suggested by Russell still fails, since the second time around
 the gpio_requests in the board callback fail because they are
 not freed when you do a module unload/unbind.
 That would need this patch from me to add the .teardown
 hooks
 http://marc.info/?l=linux-omapm=133007767831297w=2

Yes let's add the teardown patch as a fix for now, but let's
plan on getting rid of the twl_setup callback function
completely.

With these patches LCD and WLAN too can request the twl gpios
directly from the driver based on gpio_chip + gpio offset.

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

Re: [PATCH 1/4] gpiolib: Add gpiochip_find_by_name() and gpio_find_by_chip_name()

2012-03-02 Thread Tony Lindgren 
* Tony Lindgren t...@atomide.com [120302 08:31]:
 * Grant Likely grant.lik...@secretlab.ca [120302 01:00]:
  On Thu, 01 Mar 2012 10:55:24 -0800, Tony Lindgren t...@atomide.com wrote:
   +
   +/**
   + * gpiochip_find_by_name() - iterator for locating a gpio_chip by name
   + * @name: name of the gpio_chip
   + *
   + * Similar to bus_find_device_by_name. It returns a reference to the
   + * first gpio_chip with matching name. It ignores NULL and empty names.
   + * If you need to do something more complex, then use gpiochip_find.
   + */
   +struct gpio_chip *gpiochip_find_by_name(const char *name)
   +{
   + if (!name || !strcmp(name, ))
   + return NULL;
   +
   + return gpiochip_find((void *)name, match_name);
  
  Nasty cast.  Can the signature for gpiochip_find be changed to accept
  a (const void *)?
 
 I think so, this too comes from the bus code.

Looks like it can't be const as of_node_to_gpiochip uses it with
a struct device_node * that for of_get_named_gpio_flags comes from
of_parse_phandle_with_args.

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

Re: [PATCH 2/4] mmc: omap_hsmmc: Use gpio_find_by_chip_name() for omap_hsmmc_gpio_init()

2012-03-02 Thread Tony Lindgren 
* Tony Lindgren t...@atomide.com [120302 08:38]:
 * Rajendra Nayak rna...@ti.com [120301 22:54]:

  @@ -2093,8 +2123,7 @@ err1:
 platform_set_drvdata(pdev, NULL);
 mmc_free_host(mmc);
err_alloc:
  -  omap_hsmmc_gpio_free(pdata);
  -err:
  +  omap_hsmmc_gpio_free(host);
  
  This error handling needs to be fixed up. In case
  omap_hsmmc_gpio_init() fails, which already frees up
  any requested gpios, omap_hsmmc_gpio_free() again tries
  freeing gpios.
 
 Hmm that sounds like a separate patch that should be a fixed
 before this series?

Nope, I was confused. The error handling needs to change
as the omap_hsmmc_gpio_init() got moved later so host is
initialized. Will fix.

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

Re: [PATCH 1/4] gpiolib: Add gpiochip_find_by_name() and gpio_find_by_chip_name()

2012-03-02 Thread Grant Likely 
On Fri, 2 Mar 2012 10:08:48 -0800, Tony Lindgren t...@atomide.com wrote:
 * Tony Lindgren t...@atomide.com [120302 08:31]:
  * Grant Likely grant.lik...@secretlab.ca [120302 01:00]:
   On Thu, 01 Mar 2012 10:55:24 -0800, Tony Lindgren t...@atomide.com 
   wrote:
+
+/**
+ * gpiochip_find_by_name() - iterator for locating a gpio_chip by name
+ * @name: name of the gpio_chip
+ *
+ * Similar to bus_find_device_by_name. It returns a reference to the
+ * first gpio_chip with matching name. It ignores NULL and empty names.
+ * If you need to do something more complex, then use gpiochip_find.
+ */
+struct gpio_chip *gpiochip_find_by_name(const char *name)
+{
+   if (!name || !strcmp(name, ))
+   return NULL;
+
+   return gpiochip_find((void *)name, match_name);
   
   Nasty cast.  Can the signature for gpiochip_find be changed to accept
   a (const void *)?
  
  I think so, this too comes from the bus code.
 
 Looks like it can't be const as of_node_to_gpiochip uses it with
 a struct device_node * that for of_get_named_gpio_flags comes from
 of_parse_phandle_with_args.

Really? It sees to work fine here:

---

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index d773540..e633a2a 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1152,8 +1152,9 @@ EXPORT_SYMBOL_GPL(gpiochip_remove);
  * non-zero, this function will return to the caller and not iterate over any
  * more gpio_chips.
  */
-struct gpio_chip *gpiochip_find(void *data,
-   int (*match)(struct gpio_chip *chip, void 
*data))
+struct gpio_chip *gpiochip_find(const void *data,
+   int (*match)(struct gpio_chip *chip,
+const void *data))
 {
struct gpio_chip *chip = NULL;
unsigned long flags;
diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index e034b38..bba8121 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -229,7 +229,7 @@ void of_gpiochip_remove(struct gpio_chip *chip)
 }
 
 /* Private function for resolving node pointer to gpio_chip */
-static int of_gpiochip_is_match(struct gpio_chip *chip, void *data)
+static int of_gpiochip_is_match(struct gpio_chip *chip, const void *data)
 {
return chip-of_node == data;
 }
diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
index 1ff4e22..5f52690 100644
--- a/include/asm-generic/gpio.h
+++ b/include/asm-generic/gpio.h
@@ -142,9 +142,9 @@ extern int __must_check gpiochip_reserve(int start, int 
ngpio);
 /* add/remove chips */
 extern int gpiochip_add(struct gpio_chip *chip);
 extern int __must_check gpiochip_remove(struct gpio_chip *chip);
-extern struct gpio_chip *gpiochip_find(void *data,
+extern struct gpio_chip *gpiochip_find(const void *data,
int (*match)(struct gpio_chip *chip,
-void *data));
+const void *data));
 
 
 /* Always use the library code for GPIO management calls,

--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/4] gpiolib: Add gpiochip_find_by_name() and gpio_find_by_chip_name()

2012-03-02 Thread Tony Lindgren 
* Grant Likely grant.lik...@secretlab.ca [120302 10:16]:
 On Fri, 2 Mar 2012 10:08:48 -0800, Tony Lindgren t...@atomide.com wrote:
  * Tony Lindgren t...@atomide.com [120302 08:31]:
   * Grant Likely grant.lik...@secretlab.ca [120302 01:00]:
On Thu, 01 Mar 2012 10:55:24 -0800, Tony Lindgren t...@atomide.com 
wrote:
 +
 +/**
 + * gpiochip_find_by_name() - iterator for locating a gpio_chip by 
 name
 + * @name: name of the gpio_chip
 + *
 + * Similar to bus_find_device_by_name. It returns a reference to the
 + * first gpio_chip with matching name. It ignores NULL and empty 
 names.
 + * If you need to do something more complex, then use gpiochip_find.
 + */
 +struct gpio_chip *gpiochip_find_by_name(const char *name)
 +{
 + if (!name || !strcmp(name, ))
 + return NULL;
 +
 + return gpiochip_find((void *)name, match_name);

Nasty cast.  Can the signature for gpiochip_find be changed to accept
a (const void *)?
   
   I think so, this too comes from the bus code.
  
  Looks like it can't be const as of_node_to_gpiochip uses it with
  a struct device_node * that for of_get_named_gpio_flags comes from
  of_parse_phandle_with_args.
 
 Really? It sees to work fine here:

Hmm right you are. I must have missed adding the const to
of_gpiochip_is_match, that's good news :)

Want to do that as a separate patch or want me to fold it in?

Tony
 
 ---
 
 diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
 index d773540..e633a2a 100644
 --- a/drivers/gpio/gpiolib.c
 +++ b/drivers/gpio/gpiolib.c
 @@ -1152,8 +1152,9 @@ EXPORT_SYMBOL_GPL(gpiochip_remove);
   * non-zero, this function will return to the caller and not iterate over any
   * more gpio_chips.
   */
 -struct gpio_chip *gpiochip_find(void *data,
 - int (*match)(struct gpio_chip *chip, void 
 *data))
 +struct gpio_chip *gpiochip_find(const void *data,
 + int (*match)(struct gpio_chip *chip,
 +  const void *data))
  {
   struct gpio_chip *chip = NULL;
   unsigned long flags;
 diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
 index e034b38..bba8121 100644
 --- a/drivers/of/gpio.c
 +++ b/drivers/of/gpio.c
 @@ -229,7 +229,7 @@ void of_gpiochip_remove(struct gpio_chip *chip)
  }
  
  /* Private function for resolving node pointer to gpio_chip */
 -static int of_gpiochip_is_match(struct gpio_chip *chip, void *data)
 +static int of_gpiochip_is_match(struct gpio_chip *chip, const void *data)
  {
   return chip-of_node == data;
  }
 diff --git a/include/asm-generic/gpio.h b/include/asm-generic/gpio.h
 index 1ff4e22..5f52690 100644
 --- a/include/asm-generic/gpio.h
 +++ b/include/asm-generic/gpio.h
 @@ -142,9 +142,9 @@ extern int __must_check gpiochip_reserve(int start, int 
 ngpio);
  /* add/remove chips */
  extern int gpiochip_add(struct gpio_chip *chip);
  extern int __must_check gpiochip_remove(struct gpio_chip *chip);
 -extern struct gpio_chip *gpiochip_find(void *data,
 +extern struct gpio_chip *gpiochip_find(const void *data,
   int (*match)(struct gpio_chip *chip,
 -  void *data));
 +  const void *data));
  
  
  /* Always use the library code for GPIO management calls,
 
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc sdhci i.MX5: make mmc cards work

2012-03-02 Thread Chris Ball 
Hi,

On Mon, Feb 20 2012, Shawn Guo wrote:
 On 21 February 2012 02:41, Sascha Hauer s.ha...@pengutronix.de wrote:
 On Mon, Feb 20, 2012 at 02:31:36PM +0800, Shawn Guo wrote:
 I do not have a mmc card to test the patch, but I tested it and
 confirmed it does not break anything about SD support.

 On Fri, Feb 17, 2012 at 11:51:49AM +0100, Sascha Hauer wrote:
  On i.MX53 we have to write a special SDHCI_CMD_ABORTCMD to the

 Is this i.MX53 only?

 Don't know. I don't think I have ever explicitely tested MMC cards on
 !i.MX53 boards.


  SDHCI_TRANSFER_MODE register during a MMC_STOP_TRANSMISSION
  command. This works for SD cards. However, with MMC cards
  the MMC_SET_BLOCK_COUNT command is used instead, but this needs
  the same handling. Fix MMC cards by testing for the
  MMC_SET_BLOCK_COUNT command aswell. Tested on a custom i.MX53
  board with a Transcend MMC+ card and eMMC.
 
 I did not find the similar handling in FSL internal tree, but I think
 that FSL QA team should have tested it with MMC/eMMC card.

 Which kernel did they test this on? The mmc core uses the
 MMC_SET_BLOCK_COUNT command since v3.0-rc1. Earlier kernels
 probably worked.

 FSL internal tree was recently upgraded to v3.0, and I just knew from
 QA team that they tested the new tree with a Sandisk eMMC card and it
 worked, but have not found a Transcend card to test.  Since you are
 fixing a problem you are actually seeing and the patch does not break
 anything with my testing, so

 Acked-by: Shawn Guo shawn@linaro.org

Thanks, pushed to mmc-next for 3.3.  It sounds like you'd like this to
go to 3.{0,1,2}-stable, too?

- Chris.
-- 
Chris Ball   c...@laptop.org   http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support

2012-03-02 Thread Chris Ball 
Hi,

On Wed, Feb 22 2012, Mark Brown wrote:
 On Tue, Feb 21, 2012 at 08:17:41AM -0500, Chris Ball wrote:

 Pushed to mmc-next, thanks.  (I'm expecting that you'll do the merge
 to Linus.)

 I've been sending patches adding runtime PM support to this driver for a
 while with no response - are there any issues with those?

I don't have s3c hardware, so I've been waiting for a Tested-by or ACK
from someone who does -- Kukjin, any objection if I take this into
mmc-next with a plan to merge it, to provoke some testing?  Is it
possible for you to test/review the patch?

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: [PATCH] mmc: fix regression: set default clock gating delay to 0

2012-03-02 Thread Chris Ball 
Hi,

On Thu, Feb 23 2012, Guennadi Liakhovetski wrote:
 A recent commit mmc: core: Use delayed work in clock gating framework
 introduced a default 200ms delay before clock gating actually takes place.
 This means, that every time an MMC interface becomes idle it first stays
 on for 200ms before gating its clock. This leads to increased power
 consumption and is therefore a clear regression. This patch restores the
 original behaviour by setting the default delay to 0. Users,
 prioritising throughput over power efficiency can still modify the delay
 via sysfs.

 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---

 As discussed in this thread

 http://thread.gmane.org/gmane.linux.kernel.mmc/12307

 this is one of the ways to fix the regression. Please, push for 3.3.

  drivers/mmc/core/host.c |4 ++--
  1 files changed, 2 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
 index 30055f2..c3704e2 100644
 --- a/drivers/mmc/core/host.c
 +++ b/drivers/mmc/core/host.c
 @@ -238,10 +238,10 @@ static inline void mmc_host_clk_init(struct mmc_host 
 *host)
   /* Hold MCI clock for 8 cycles by default */
   host-clk_delay = 8;
   /*
 -  * Default clock gating delay is 200ms.
 +  * Default clock gating delay is 0ms to avoid wasting power.
* This value can be tuned by writing into sysfs entry.
*/
 - host-clkgate_delay = 200;
 + host-clkgate_delay = 0;
   host-clk_gated = false;
   INIT_DELAYED_WORK(host-clk_gate_work, mmc_host_clk_gate_work);
   spin_lock_init(host-clk_lock);

Thanks, will push this to 3.3 this week.

- Chris.
-- 
Chris Ball   c...@laptop.org   http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] mmc: core: remove waiting time when clkgate_delay is set

2012-03-02 Thread Chris Ball 
Hi,

On Wed, Feb 29 2012, Chanho Park wrote:
 Since recent commit(mmc: core: Use delayed work in clock gating
 framework:597dd9d79cfbbb1), we always wait unnecessary default
 clock delay(8 cycles). Actually, we don't need it if clkgate_delay
 (unit:ms) is set because we already wait sufficient time to change
 the clock due to delayed_workqueue.
 This patch removes duplicated waiting time when clkgate_delay is set.

 Signed-off-by: Chanho Park chanho61.p...@samsung.com
 Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
 ---
  drivers/mmc/core/host.c |7 +--
  1 files changed, 5 insertions(+), 2 deletions(-)

 diff --git a/drivers/mmc/core/host.c b/drivers/mmc/core/host.c
 index c3704e2..d710ce0 100644
 --- a/drivers/mmc/core/host.c
 +++ b/drivers/mmc/core/host.c
 @@ -109,8 +109,11 @@ static void mmc_host_clk_gate_delayed(struct mmc_host 
 *host)
*/
   if (!host-clk_requests) {
   spin_unlock_irqrestore(host-clk_lock, flags);
 - tick_ns = DIV_ROUND_UP(10, freq);
 - ndelay(host-clk_delay * tick_ns);
 + /* wait only when clk_gate_delay is 0*/
 + if (!host-clkgate_delay) {
 + tick_ns = DIV_ROUND_UP(10, freq);
 + ndelay(host-clk_delay * tick_ns);
 + }
   } else {
   /* New users appeared while waiting for this work */
   spin_unlock_irqrestore(host-clk_lock, flags);

Have you seen Guennadi's patch?

http://git.kernel.org/?p=linux/kernel/git/cjb/mmc.git;a=commitdiff;h=63871af54a0f0053de6534afe8da101b988b86b6

- Chris.
-- 
Chris Ball   c...@laptop.org   http://printf.net/
One Laptop Per Child
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 0/6] mmc: sdhci-s3c: Rework platform data and add device tree support

2012-03-02 Thread Kukjin Kim 

On 03/03/12 05:40, Chris Ball wrote:

Hi,

On Wed, Feb 22 2012, Mark Brown wrote:

On Tue, Feb 21, 2012 at 08:17:41AM -0500, Chris Ball wrote:


Pushed to mmc-next, thanks.  (I'm expecting that you'll do the merge
to Linus.)


I've been sending patches adding runtime PM support to this driver for a
while with no response - are there any issues with those?


I don't have s3c hardware, so I've been waiting for a Tested-by or ACK
from someone who does -- Kukjin, any objection if I take this into
mmc-next with a plan to merge it, to provoke some testing?  Is it
possible for you to test/review the patch?


Hi Chris,

Maybe I lost Mark's runtime PM supporting patches. I couldn't find it in 
my mail box. Sorry for that :(


Mark, could you please send it to me again?

Thanks.

Best regards,
Kgene.
--
Kukjin Kim kgene@samsung.com, Senior Engineer,
SW Solution Development Team, Samsung Electronics Co., Ltd.
--
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 1/2] mmc: sdhci-s3c: Use CONFIG_PM_SLEEP to ifdef system suspend

2012-03-02 Thread Mark Brown 
This matches current best practice as one can have runtime PM enabled
without system sleep and CONFIG_PM is defined for both.

Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
 drivers/mmc/host/sdhci-s3c.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index ea0767e..46152d6 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -22,6 +22,7 @@
 #include linux/module.h
 #include linux/of.h
 #include linux/of_gpio.h
+#include linux/pm.h
 
 #include linux/mmc/host.h
 
@@ -807,8 +808,7 @@ static int __devexit sdhci_s3c_remove(struct 
platform_device *pdev)
return 0;
 }
 
-#ifdef CONFIG_PM
-
+#ifdef CONFIG_PM_SLEEP
 static int sdhci_s3c_suspend(struct device *dev)
 {
struct sdhci_host *host = dev_get_drvdata(dev);
@@ -822,10 +822,11 @@ static int sdhci_s3c_resume(struct device *dev)
 
return sdhci_resume_host(host);
 }
+#endif
 
+#ifdef CONFIG_PM
 static const struct dev_pm_ops sdhci_s3c_pmops = {
-   .suspend= sdhci_s3c_suspend,
-   .resume = sdhci_s3c_resume,
+   SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
 };
 
 #define SDHCI_S3C_PMOPS (sdhci_s3c_pmops)
-- 
1.7.9.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 2/2] mmc: sdhci-s3c: Enable runtime power management

2012-03-02 Thread Mark Brown 
Since most of the work is already done by the core we just need to add
runtime suspend methods and tell the PM core that runtime PM is enabled
for this device.

Signed-off-by: Mark Brown broo...@opensource.wolfsonmicro.com
---
 drivers/mmc/host/sdhci-s3c.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/drivers/mmc/host/sdhci-s3c.c b/drivers/mmc/host/sdhci-s3c.c
index 46152d6..6926ac9 100644
--- a/drivers/mmc/host/sdhci-s3c.c
+++ b/drivers/mmc/host/sdhci-s3c.c
@@ -23,6 +23,7 @@
 #include linux/of.h
 #include linux/of_gpio.h
 #include linux/pm.h
+#include linux/pm_runtime.h
 
 #include linux/mmc/host.h
 
@@ -721,6 +722,11 @@ static int __devinit sdhci_s3c_probe(struct 
platform_device *pdev)
if (pdata-host_caps2)
host-mmc-caps2 |= pdata-host_caps2;
 
+   pm_runtime_enable(pdev-dev);
+   pm_runtime_set_autosuspend_delay(pdev-dev, 50);
+   pm_runtime_use_autosuspend(pdev-dev);
+   pm_suspend_ignore_children(pdev-dev, 1);
+
ret = sdhci_add_host(host);
if (ret) {
dev_err(dev, sdhci_add_host() failed\n);
@@ -740,6 +746,8 @@ static int __devinit sdhci_s3c_probe(struct platform_device 
*pdev)
 
  err_add_host:
release_resource(sc-ioarea);
+   pm_runtime_forbid(pdev-dev);
+   pm_runtime_get_noresume(pdev-dev);
kfree(sc-ioarea);
 
  err_req_regs:
@@ -784,6 +792,8 @@ static int __devexit sdhci_s3c_remove(struct 
platform_device *pdev)
 
sdhci_remove_host(host, 1);
 
+   pm_runtime_disable(pdev-dev);
+
for (ptr = 0; ptr  3; ptr++) {
if (sc-clk_bus[ptr]) {
clk_disable(sc-clk_bus[ptr]);
@@ -824,9 +834,27 @@ static int sdhci_s3c_resume(struct device *dev)
 }
 #endif
 
+#ifdef CONFIG_PM_RUNTIME
+static int sdhci_s3c_runtime_suspend(struct device *dev)
+{
+   struct sdhci_host *host = dev_get_drvdata(dev);
+
+   return sdhci_runtime_suspend_host(host);
+}
+
+static int sdhci_s3c_runtime_resume(struct device *dev)
+{
+   struct sdhci_host *host = dev_get_drvdata(dev);
+
+   return sdhci_runtime_resume_host(host);
+}
+#endif
+
 #ifdef CONFIG_PM
 static const struct dev_pm_ops sdhci_s3c_pmops = {
SET_SYSTEM_SLEEP_PM_OPS(sdhci_s3c_suspend, sdhci_s3c_resume)
+   SET_RUNTIME_PM_OPS(sdhci_s3c_runtime_suspend, sdhci_s3c_runtime_resume,
+  NULL)
 };
 
 #define SDHCI_S3C_PMOPS (sdhci_s3c_pmops)
-- 
1.7.9.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

Re: [PATCH v6 0/2] patch set about the MXS-DMA

2012-03-02 Thread Huang Shijie 
hi,

On Sat, Mar 3, 2012 at 4:50 AM, Chris Ball c...@laptop.org wrote:
 Hi,

 On Wed, Feb 29 2012, Huang Shijie wrote:
 Pushed both to l2-mtd.git tree, thanks. I am worried that it touches
 other subsystems like dma, sound, and mmc and there are no acks for
 those. Would be nice to get them somehow.

 I ever thought Vinod could accept this patch set.

 To Vinod  Chris:
       Could you give the ack to the first patch?

 Yes -- for the first patch:

 Acked-by: Chris Ball c...@laptop.org


thanks a lot.

Huang Shijie


 (I think Shawn's ACK is sufficient for the second patch.)

 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