RE: MMC/SD cards hotplug scenario

2008-05-21 Thread Madhusudhan Chikkature Rajashekar
 

 -Original Message-
 From: Russell King - ARM Linux [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, May 21, 2008 1:00 PM
 To: Madhusudhan Chikkature Rajashekar
 Cc: 'Pierre Ossman'; linux-omap@vger.kernel.org; 
 [EMAIL PROTECTED]
 Subject: Re: MMC/SD cards hotplug scenario
 
 On Wed, May 21, 2008 at 11:42:04AM +0530, Madhusudhan 
 Chikkature Rajashekar wrote:
  After the end of the I/O errors I can umount the partition that was
  mounted and I reinsert the card.
 
 That's rather expected - outstanding IO has to be errored when the
 medium is removed.
Yes. I got your point. But can this be made to through few I/O errors and stop 
instead of resulting in I/O errors for the rest of
the data?
In the case where data copied is huge, for eg 500MB, the I/O errors are quite 
lot.

 
  It seem not to work very well consistently.
 
 Vague handwaving comment with no useful information.  What 
 precisely is
 the problem that you're seeing?
 
What I meant here is that reinsertion of the card does not seem to result in 
reinitialization of the card consistently.

Details of few things I noticed is listed below stepwise and to start with card 
is detected and mounted on mount point /mnt/mmc dir.

1. Start copy of data.
2. Removed the card in the middle of transfer. At the controller driver level 
this generated card removed interrupt. The
mmc_detect_change fn called.
3. I/O Errors generated.
4. Reinsert the card. This generated card inserted interrupt. The mmc_detect_fn 
called. But the card does not seem to be
reinitialized correctly.
   cat /proc/partitions does not list mmc partitions.

The attached log shows that out of 3 trails, it seem to work fine correctly 2 
times and failed the third time.

So my question is for the above scenario does the MMC/SD core need to take care 
of anything explicitely or should this be fixed at
the controller
driver level?

Regards,
Madhu
p -a      cp -a /etc/ /mnt/mmc/

 + MMC CARD REMOVED + 
mmc0: card 981b removed
mmcblk0: error -110 sending read/write command
end_request: I/O error, dev mmcblk0, sector 3928
mmcblk0: error -110 sending read/write command
end_request: I/O error, dev mmcblk0, sector 48
Buffer I/O error on device mmcblk0p1, logical block 4
lost page write due to I/O error on mmcblk0p1
mmcblk0: error -110 sending read/write command
end_request: I/O error, dev mmcblk0, sector 16
Buffer I/O error on device mmcblk0p1, logical block 0
lost page write due to I/O error on mmcblk0p1
end_request: I/O error, dev mmcblk0, sector 24
Buffer I/O error on device mmcblk0p1, logical block 1
lost page write due to I/O error on mmcblk0p1
mmcblk0: error -110 sending read/write command
WARNING: at fs/buffer.c:1169 mark_buffer_dirty()
[c0033400] (dump_stack+0x0/0x14) from [c00d21ac] 
(mark_buffer_dirty+0x44/0xb8)
[c00d2168] (mark_buffer_dirty+0x0/0xb8) from [c0108ae4] 
(group_adjust_blocks+0x38/0x3c)
 r5:0008 r4:
[c0108aac] (group_adjust_blocks+0x0/0x3c) from [c0109778] 
(ext2_new_blocks+0x3fc/0x5cc)
[c010937c] (ext2_new_blocks+0x0/0x5cc) from [c010d100] 
(ext2_get_block+0x2bc/0x69c)
[c010ce44] (ext2_get_block+0x0/0x69c) from [c00d2f70] 
(__block_prepare_write+0x18c/0x414)
[c00d2de4] (__block_prepare_write+0x0/0x414) from [c00d32e4] 
(block_write_begin+0x90/0x108)
[c00d3254] (block_write_begin+0x0/0x108) from [c010cdf4] 
(__ext2_write_begin+0x3c/0x48)
[c010cdb8] (__ext2_write_begin+0x0/0x48) from [c010ce3c] 
(ext2_write_begin+0x3c/0x44)
[c010ce00] (ext2_write_begin+0x0/0x44) from [c009185c] 
(generic_file_buffered_write+0x10c/0x5f0)
[c0091750] (generic_file_buffered_write+0x0/0x5f0) from [c0092168] 
(__generic_file_aio_write_nolock+0x428/0x478)
[c0091d40] (__generic_file_aio_write_nolock+0x0/0x478) from [c009222c] 
(generic_file_aio_write+0x74/0xe8)
[c00921b8] (generic_file_aio_write+0x0/0xe8) from [c00b08d0] 
(do_sync_write+0xbc/0x10c)
[c00b0814] (do_sync_write+0x0/0x10c) from [c00b11b8] (vfs_write+0xb8/0x148)
[c00b1100] (vfs_write+0x0/0x148) from [c00b1784] (sys_write+0x44/0x70)
 r7:1000 r6:c7c1ff20 r5: r4:
[c00b1740] (sys_write+0x0/0x70) from [c002ee60] (ret_fast_syscall+0x0/0x2c)
 r8:c002f66c r7:0004 r6:0004 r5:be8aa148 r4:1000
end_request: I/O error, dev mmcblk0, sector 1048592
Buffer I/O error on device mmcblk0p1, logical block 131072
lost page write due to I/O error on mmcblk0p1
end_request: I/O error, dev mmcblk0, sector 1048600
Buffer I/O error on device mmcblk0p1, logical block 131073
lost page write due to I/O error on mmcblk0p1
end_request: I/O error, dev mmcblk0, sector 1048608
Buffer I/O error on device mmcblk0p1, logical block 131074
lost page write due to I/O error on mmcblk0p1
end_request: I/O error, dev mmcblk0, sector 1048616
Buffer I/O error on device mmcblk0p1, logical block 131075
lost page write due to I/O error on mmcblk0p1
end_request: I/O error, dev mmcblk0, sector 1048624
Buffer I/O error on device mmcblk0p1, logical block 131076
lost page write due

RE: sdio cmd53 doesn't work on omap 2430sdp

2008-05-21 Thread Madhusudhan Chikkature Rajashekar
Hi,

Please use the vger list.

It seems like you are getting DTO on CMD53.

One thing you might want to check is did the card configuration path went fine 
before you issue CMD53.
Before your card driver issues CMD53, I guess the SDIO core issues a series of 
CMD52 to read the card capabilities and
Setup the bus width etc... Does these go through fine for the card you are 
using? Does the core detect the new SDIO card?

Regards,
Madhu




 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On 
 Behalf Of Dmitriy Chumak
 Sent: Wednesday, May 21, 2008 5:51 PM
 To: [EMAIL PROTECTED]
 Subject: sdio cmd53 doesn't work on omap 2430sdp
 
 Hi *,
 
 I write an SDIO driver on OMAP 2430SDP platform.
 
 I have two question related to MMC subsystem:
 
 1. When I issue sdio_readw (or other function that ends up
using CMD53 sdio command) - it hangs. This happens because func
mmc_wait_for_req waits for request completion that 
 should be signaled
by calling mmc_wait_done. mmc_wait_done is indirectly 
 called from
mmc_omap_cmd_done if condition host-data == NULL || 
 cmd-error
(file: drivers/mmc/host/omap_hsmmc.c, line: 273) is 
 true. In my case
the above condition is not true because host-data is 
 not NULL and
cmd-error is NULL. Why this could be happen. Which 
 code is responsible
for setting host-data to NULL in case of successful 
 sdio command
completion?
 
 2. Also when I issue sdio_readw - I get an error status 108001 in
mmc_omap_irq. If I've decoded it correctly it means CC, ERR and
DATA_TIMEOUT. What does it means and when this could 
 be happened?

 
 Best regards,
 
 Dmitriy
 ___
 Linux-omap-open-source mailing list
 [EMAIL PROTECTED]
 http://linux.omap.com/mailman/listinfo/linux-omap-open-source
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [RFC/PATCH] BQ27000/BQ27200 battery monitoring driver for OMAP34xx

2008-04-29 Thread Madhusudhan Chikkature Rajashekar
 

 -Original Message-
 From: Felipe Balbi [mailto:[EMAIL PROTECTED] 
 Sent: Monday, April 28, 2008 5:17 PM
 To: Madhusudhan Chikkature Rajashekar
 Cc: Tony Lindgren; linux-omap@vger.kernel.org
 Subject: RE: [RFC/PATCH] BQ27000/BQ27200 battery monitoring 
 driver for OMAP34xx
 
 
 
 On Mon, 28 Apr 2008 17:11:51 +0530, Madhusudhan Chikkature 
 Rajashekar
 [EMAIL PROTECTED] wrote:
  Hi Felipe,
  
  Thanks for the comments. I will fix them and resend the patch.
  
  Please note my view on the below point.
  
   -pdev = platform_device_alloc(omap-bq2700-battery, id);
   +pdev = platform_device_alloc(bq27000-bat, id);
 
  do you really need to change the name here?
  It seems that this change doesn't belong to this patch.
  
  I will make this as a separate patch.As BQ27000 chip is not omap
 specific,
  I guess the above name is not correct. Hence I intend to make that
 change.
 
 Ok, works for me :-)
 
 I guess bq2700-battery is ok, just remove omap- from the 
 previous name??
Yes. I will correct the name and resend the patch. I will send this one as a 
separate patch and followed by it will
be the battery driver patch.

 
 
 -- 
 Best Regards,
 
 Felipe Balbi
 http://felipebalbi.com
 [EMAIL PROTECTED]
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Resending: [PATCH] BQ27000/BQ27200 battery monitoring driver for OMAP34xx

2008-04-29 Thread Madhusudhan Chikkature Rajashekar
Hi,

I am resending the patch after fixing the comments provided by Felipe.

Regards,
Madhu

This patch provides the battery driver to support BQ27000 and BQ27200 chips.

Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]

---
 drivers/power/Kconfig   |   21 +
 drivers/power/Makefile  |1 
 drivers/power/bq27x00_battery.c |  564 
 3 files changed, 586 insertions(+)

Index: linux-omap-2.6/drivers/power/bq27x00_battery.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux-omap-2.6/drivers/power/bq27x00_battery.c  2008-04-29 
11:27:42.962321458 +0530
@@ -0,0 +1,564 @@
+/*
+ * linux/drivers/power/bq27x00_battery.c
+ *
+ * BQ27000/BQ27200 battery driver
+ *
+ * Copyright (C) 2008 Texas Instruments, Inc.
+ *
+ * Author: Texas Instruments
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ */
+#include linux/module.h
+#include linux/param.h
+#include linux/jiffies.h
+#include linux/workqueue.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+
+#ifdef CONFIG_BATTERY_BQ27000
+#include ../w1/w1.h
+#endif
+#ifdef CONFIG_BATTERY_BQ27200
+#include linux/i2c.h
+#endif
+
+#define BQ27x00_REG_TEMP   0x06
+#define BQ27x00_REG_VOLT   0x08
+#define BQ27x00_REG_RSOC   0x0B /* Relative State-of-Charge */
+#define BQ27x00_REG_AI 0x14
+#define BQ27x00_REG_FLAGS  0x0A
+#define HIGH_BYTE(A)   ((A)  8)
+
+#ifdef CONFIG_BATTERY_BQ27000
+extern int w1_bq27000_read(struct device *dev, u8 reg);
+#endif
+
+struct bq27x00_device_info;
+struct bq27x00_access_methods {
+   int (*read)(u8 reg, int *rt_value, int b_single,
+   struct bq27x00_device_info *di);
+};
+
+struct bq27x00_device_info {
+   struct device   *dev;
+#ifdef CONFIG_BATTERY_BQ27000
+   struct device   *w1_dev;
+#endif
+#ifdef CONFIG_BATTERY_BQ27200
+   struct i2c_client *client;
+#endif
+   unsigned long   update_time;
+   int voltage_uV;
+   int current_uA;
+   int temp_C;
+   int charge_rsoc;
+   struct bq27x00_access_methods   *bus;
+   struct power_supply bat;
+   struct delayed_work monitor_work;
+};
+
+static unsigned int cache_time = 6;
+module_param(cache_time, uint, 0644);
+MODULE_PARM_DESC(cache_time, cache time in milliseconds);
+
+static enum power_supply_property bq27x00_battery_props[] = {
+   POWER_SUPPLY_PROP_PRESENT,
+   POWER_SUPPLY_PROP_VOLTAGE_NOW,
+   POWER_SUPPLY_PROP_CURRENT_NOW,
+   POWER_SUPPLY_PROP_CHARGE_NOW,
+   POWER_SUPPLY_PROP_CAPACITY,
+   POWER_SUPPLY_PROP_TEMP,
+};
+
+static int bq27x00_read(u8 reg, int *rt_value, int b_single,
+   struct bq27x00_device_info *di);
+
+#ifdef CONFIG_BATTERY_BQ27000
+static int bq27000_battery_probe(struct platform_device *dev);
+static int bq27000_battery_remove(struct platform_device *dev);
+#ifdef CONFIG_PM
+static int bq27000_battery_suspend(struct platform_device *dev,
+   pm_message_t state);
+static int bq27000_battery_resume(struct platform_device *dev);
+#endif /* CONFIG_PM */
+
+static struct platform_driver bq27000_battery_driver = {
+   .probe = bq27000_battery_probe,
+   .remove = bq27000_battery_remove,
+#ifdef CONFIG_PM
+   .suspend = bq27000_battery_suspend,
+   .resume = bq27000_battery_resume,
+#endif /* CONFIG_PM */
+   .driver = {
+   .name = bq27000-battery,
+   },
+};
+#endif /* CONFIG_BATTERY_BQ27000 */
+
+#ifdef CONFIG_BATTERY_BQ27200
+static int bq27200_battery_probe(struct i2c_client *client);
+static int bq27200_battery_remove(struct i2c_client *client);
+#ifdef CONFIG_PM
+static int bq27200_battery_suspend(struct i2c_client *client,
+   pm_message_t mesg);
+static int bq27200_battery_resume(struct i2c_client *client);
+#endif /* CONFIG_PM */
+static struct i2c_driver bq27200_battery_driver = {
+   .driver = {
+   .name   = bq27200-bat,
+   },
+   .probe  = bq27200_battery_probe,
+   .remove = bq27200_battery_remove,
+#ifdef CONFIG_PM
+   .suspend = bq27200_battery_suspend,
+   .resume = bq27200_battery_resume,
+#endif /* CONFIG_PM */
+};
+#endif /* CONFIG_BATTERY_BQ27200 */
+
+/*
+ * Return the battery temperature in Celcius degrees
+ * Or  0 if something fails.
+ */
+static int bq27x00_battery_temperature(struct 

[RFC/PATCH] BQ27000/BQ27200 battery monitoring driver for OMAP34xx

2008-04-25 Thread Madhusudhan Chikkature Rajashekar
This patch provides the battery monitoring driver to monitor batteries with 
BQ27000(HDQ) or BQ27200(i2C) chips.
On omap 3430 sdp BQ27000 battery is tested through the HDQ interface which uses 
the earlier posted HDQ and BQ slave drivers. 
The BQ27200 support is an extension to the BQ27000 driver as the register set 
between BQ27000 and BQ27200 is the same.

Thanks to Klaus.K Pedersen and Mikko Ylinen for the suggestions to add support 
for BQ27200 chip as part of
this driver.


Signed-off-by: Madhusudhan Chikkature[EMAIL PROTECTED]

---
 drivers/power/Kconfig   |   21 +
 drivers/power/Makefile  |1 
 drivers/power/bq27x00_battery.c |  556 
 drivers/w1/slaves/w1_bq27000.c  |2 
 4 files changed, 579 insertions(+), 1 deletion(-)

Index: linux-omap-2.6/drivers/power/bq27x00_battery.c
===
--- /dev/null   1970-01-01 00:00:00.0 +
+++ linux-omap-2.6/drivers/power/bq27x00_battery.c  2008-04-24 
10:50:53.631358952 +0530
@@ -0,0 +1,556 @@
+/*
+ * linux/drivers/power/bq27x00_battery.c
+ *
+ * BQ27000/BQ27200 battery driver
+ *
+ * Copyright (C) 2008 Texas Instruments, Inc.
+ *
+ * Author: Texas Instruments
+ *
+ * This package is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * THIS PACKAGE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
+ * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
+ * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
+ *
+ */
+#include linux/module.h
+#include linux/param.h
+#include linux/jiffies.h
+#include linux/workqueue.h
+#include linux/delay.h
+#include linux/platform_device.h
+#include linux/power_supply.h
+
+#if defined(CONFIG_BATTERY_BQ27000)
+#define BATTERY_BQ27000
+#include ../w1/w1.h
+#endif
+#if defined(CONFIG_BATTERY_BQ27200)
+#define BATTERY_BQ27200
+#include linux/i2c.h
+#endif
+
+#define BQ27x00_REG_TEMP   0x06
+#define BQ27x00_REG_VOLT   0x08
+#define BQ27x00_REG_RSOC   0x0B /* Relative State-of-Charge */
+#define BQ27x00_REG_AI 0x14
+#define BQ27x00_REG_FLAGS  0x0A
+#define HIGH_BYTE(A)   ((A)  8)
+
+#if defined(BATTERY_BQ27000)
+extern int w1_bq27000_read(struct device *dev, u8 reg);
+#endif
+
+struct bq27x00_device_info;
+struct bq27x00_access_methods {
+   int (*read)(u8 reg, int *rt_value, int b_single,
+   struct bq27x00_device_info *di);
+};
+
+struct bq27x00_device_info {
+   struct device   *dev;
+#if defined(BATTERY_BQ27000)
+   struct device   *w1_dev;
+#endif
+#if defined(BATTERY_BQ27200)
+   struct i2c_client *client;
+#endif
+   unsigned long   update_time;
+   int voltage_uV;
+   int current_uA;
+   int temp_C;
+   int charge_rsoc;
+   struct bq27x00_access_methods   *bus;
+   struct power_supply bat;
+   struct delayed_work monitor_work;
+};
+
+static unsigned int cache_time = 6;
+module_param(cache_time, uint, 0644);
+MODULE_PARM_DESC(cache_time, cache time in milliseconds);
+
+static enum power_supply_property bq27x00_battery_props[] = {
+   POWER_SUPPLY_PROP_PRESENT,
+   POWER_SUPPLY_PROP_VOLTAGE_NOW,
+   POWER_SUPPLY_PROP_CURRENT_NOW,
+   POWER_SUPPLY_PROP_CHARGE_NOW,
+   POWER_SUPPLY_PROP_CAPACITY,
+   POWER_SUPPLY_PROP_TEMP,
+};
+
+static int bq27x00_read(u8 reg, int *rt_value, int b_single,
+   struct bq27x00_device_info *di);
+
+#if defined(BATTERY_BQ27000)
+static int bq27000_battery_probe(struct platform_device *dev);
+static int bq27000_battery_remove(struct platform_device *dev);
+#ifdef CONFIG_PM
+static int bq27000_battery_suspend(struct platform_device *dev,
+   pm_message_t state);
+static int bq27000_battery_resume(struct platform_device *dev);
+#endif
+
+static struct platform_driver bq27000_battery_driver = {
+   .probe = bq27000_battery_probe,
+   .remove = bq27000_battery_remove,
+#ifdef CONFIG_PM
+   .suspend = bq27000_battery_suspend,
+   .resume = bq27000_battery_resume,
+#endif
+   .driver = {
+   .name = bq27000-bat,
+   },
+};
+#endif
+
+#if defined(BATTERY_BQ27200)
+static int bq27200_battery_probe(struct i2c_client *client);
+static int bq27200_battery_remove(struct i2c_client *client);
+static int bq27200_battery_suspend(struct i2c_client *client,
+   pm_message_t mesg);
+static int bq27200_battery_resume(struct i2c_client *client);
+static struct i2c_driver bq27200_battery_driver = {
+   .driver = {
+   .name   = bq27200-bat,
+   },
+   .probe  = bq27200_battery_probe,
+   .remove = bq27200_battery_remove,
+#ifdef CONFIG_PM
+   .suspend = bq27200_battery_suspend,
+ 

RE: [RFC/PATH] OMAP: HSMMC: Fixes for 1.8V MMC2 interface

2008-04-01 Thread Madhusudhan Chikkature Rajashekar
Hi,

I did not see any board level code to power up the second slot along with this 
patch.
Where is the code that enables 1.8V to the second slot?

Regards,
Madhu 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Seth Forshee
 Sent: Tuesday, April 01, 2008 6:22 AM
 To: Francisco Alecrim
 Cc: linux-omap@vger.kernel.org
 Subject: Re: [RFC/PATH] OMAP: HSMMC: Fixes for 1.8V MMC2 interface
 
 On Mon, Mar 31, 2008 at 11:45:21PM +0300, Francisco Alecrim wrote:
  Hello Seth,
 It's fine and work for 3430! Maybe you should resend 
 changing the 
  commit message. It's too big.
  
  Remove RFC from subject.
  
  What do you think?
  
  if(changes)
 Acked-by: Francisco Alecrim [EMAIL PROTECTED]
 
 Thank you for reviewing/testing.  I wanted to get 
 verification for OMAP3430
 before I officially submitted the patch, and since you have 
 done that I will
 submit it now.
 --
 To unsubscribe from this list: send the line unsubscribe 
 linux-omap in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [RFC/PATH] OMAP: HSMMC: Fixes for 1.8V MMC2 interface

2008-04-01 Thread Madhusudhan Chikkature Rajashekar
 

 -Original Message-
 From: Francisco Alecrim [mailto:[EMAIL PROTECTED] 
 Sent: Wednesday, April 02, 2008 6:17 AM
 To: Madhusudhan Chikkature Rajashekar; linux-omap@vger.kernel.org
 Subject: Re: [RFC/PATH] OMAP: HSMMC: Fixes for 1.8V MMC2 interface
 
 ext Seth Forshee wrote:
  On Tue, Apr 01, 2008 at 08:44:47PM +0530, Madhusudhan 
 Chikkature Rajashekar wrote:

  Hi,
 
  I did not see any board level code to power up the second 
 slot along with this patch.
  Where is the code that enables 1.8V to the second slot?
  
 
  I am working with a custom board that isn't supported in 
 the git repo, and I
  don't have access to any other board that I could test such 
 changes with.
  These are just the chages I found were necessary to support 
 the 1.8V-only
  host, regardless of whatever board support is needed.
 
 That's the same problem here!! I have a custom board too!! However, 
 pushing patches [1] and [2] we will be able to enable the second 
 controller with some modifications in board-sdp-mmc.c.

Yes. ThatÂ’s what I meant. Some changes in the sdp board file would be required 
to
Enable power to slot2 through triton LDOs. Currently I am tied up with some 
work,
I will patch that when I get some time unless someone else sends a patch by 
then.

 
 [1] - OMAP: HSMMC: Fixes for 1.8V MMC2 interface
 [2] - [PATCH 1/1] PLAT: OMAP: Add device configuration to 
 support second 
 HSMMC slot on OMAP 2430 and 3430 boards.
 
 -- 
 Francisco Keppler Silva Alecrim - INdT
 Phone: +55 92 2126-1017
 Mobile: +55 92 9152-7000
 
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: [PATCH 1/1] MMC: OMAP: Fix HSMMC driver name at host driver.

2008-03-23 Thread Madhusudhan Chikkature Rajashekar
 

 -Original Message-
 From: [EMAIL PROTECTED] 
 [mailto:[EMAIL PROTECTED] On Behalf Of Felipe Balbi
 Sent: Friday, March 21, 2008 4:25 AM
 To: Carlos Aguiar
 Cc: Tony Lindgren; linux-omap@vger.kernel.org
 Subject: Re: [PATCH 1/1] MMC: OMAP: Fix HSMMC driver name at 
 host driver.
 
 On Thu, Mar 20, 2008 at 04:24:30PM -0400, Carlos Aguiar wrote:
  From: Carlos Eduardo Aguiar [EMAIL PROTECTED]
  
  This patch fixes the HSMMC driver name at host driver.
  
  Signed-off-by: Carlos Eduardo Aguiar [EMAIL PROTECTED]
  ---
   drivers/mmc/host/omap_hsmmc.c |2 +-
   1 files changed, 1 insertions(+), 1 deletions(-)
  
  diff --git a/drivers/mmc/host/omap_hsmmc.c 
 b/drivers/mmc/host/omap_hsmmc.c
  index 047c64d..0e7ee20 100644
  --- a/drivers/mmc/host/omap_hsmmc.c
  +++ b/drivers/mmc/host/omap_hsmmc.c
  @@ -92,7 +92,7 @@
   #define OMAP_MMC_DATADIR_WRITE 2
   #define MMC_TIMEOUT_MS 20
   #define OMAP_MMC_MASTER_CLOCK  9600
  -#define DRIVER_NAMEmmci-omap
  +#define DRIVER_NAMEhsmmc-omap
 
 stupid question :-p
 what does the 'i' means?
I think it is a simple mistake. The change you have done makes sense for the 
HSMMC driver.

 
 -- 
 Best Regards,
 
 Felipe Balbi
 [EMAIL PROTECTED]
 http://blog.felipebalbi.com
 --
 To unsubscribe from this list: send the line unsubscribe 
 linux-omap in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 

--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html