Re: [PATCH] mmc : Use wait_for_completion_timeout() instead of wait_for_completion in case of write.
Namjae Jeon wrote: host controller can not rise timeout interrupt in write not read in DMA status. because host can just know whether card is finish to program to use busy line. If unstable card is keep holding busy line while writing using DMA. hang problem happen by wait_for_completion. so I think that mmc driver need some exception to avoid this problem. I suggest to use wait_for_completion_timeout instead of wait_for_completion. I see what you are trying to solve, but you can never calculate the timeout for this type of operation in such a way. Your timeout involves the entire data write operation, how can you ever know how long this will take? I think a much better approach is to make you host driver not using busy signaling (if that is possible), thus when the DMA job is done call mmc_request_done to finalize the data transfer. The mmc framework will then send a CMD13 (SEND_STATUS) to make sure the data is written before issuing the next request. BR Ulf Hansson -- 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 : Use wait_for_completion_timeout() instead of wait_for_completion in case of write.
On Tue, Sep 20, 2011 at 1:09 PM, Ulf Hansson ulf.hans...@stericsson.com wrote: Namjae Jeon wrote: host controller can not rise timeout interrupt in write not read in DMA status. because host can just know whether card is finish to program to use busy line. If unstable card is keep holding busy line while writing using DMA. hang problem happen by wait_for_completion. so I think that mmc driver need some exception to avoid this problem. I suggest to use wait_for_completion_timeout instead of wait_for_completion. I see what you are trying to solve, but you can never calculate the timeout for this type of operation in such a way. Your timeout involves the entire data write operation, how can you ever know how long this will take? I think a much better approach is to make you host driver not using busy signaling (if that is possible), thus when the DMA job is done call mmc_request_done to finalize the data transfer. The mmc framework will then send a CMD13 (SEND_STATUS) to make sure the data is written before issuing the next request. BR Ulf Hansson To add to what Hansson mentioned, the timeout mechanism should not be implemented at the MMC core layer. If the core layer simply times out like this, the host controller driver still remains in the same state which is not right. If such a timeout mechanism is needed, it is best to implement in the host controller driver layer and inform the core layer by calling mmc_request_done() when the time out happens. This will also give a chance to the host controller driver to do any required clean up at the controller layer so that it is in a known good state to handle further requests from the core layer. Regards, Murali Krishna -- 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 : Use wait_for_completion_timeout() instead of wait_for_completion in case of write.
2011/9/20 Murali Krishna Palnati palnati.muralikris...@gmail.com: On Tue, Sep 20, 2011 at 1:09 PM, Ulf Hansson ulf.hans...@stericsson.com wrote: Namjae Jeon wrote: host controller can not rise timeout interrupt in write not read in DMA status. because host can just know whether card is finish to program to use busy line. If unstable card is keep holding busy line while writing using DMA. hang problem happen by wait_for_completion. so I think that mmc driver need some exception to avoid this problem. I suggest to use wait_for_completion_timeout instead of wait_for_completion. I see what you are trying to solve, but you can never calculate the timeout for this type of operation in such a way. Your timeout involves the entire data write operation, how can you ever know how long this will take? I think a much better approach is to make you host driver not using busy signaling (if that is possible), thus when the DMA job is done call mmc_request_done to finalize the data transfer. The mmc framework will then send a CMD13 (SEND_STATUS) to make sure the data is written before issuing the next request. BR Ulf Hansson To add to what Hansson mentioned, the timeout mechanism should not be implemented at the MMC core layer. If the core layer simply times out like this, the host controller driver still remains in the same state which is not right. If such a timeout mechanism is needed, it is best to implement in the host controller driver layer and inform the core layer by calling mmc_request_done() when the time out happens. This will also give a chance to the host controller driver to do any required clean up at the controller layer so that it is in a known good state to handle further requests from the core layer. Regards, Murali Krishna yes, I knew. But if card keep holding busy line(data 0) in the middle of DMA operation(multi blocks write), host driver layer can not know card status in this situation. addtionally, After timeout happen, host driver should send stop cmd to card for putting out busyline. and we should reset/cleanup host contoller to intialize DMA controller. and it should be impremented in host driver. so after returing write fail, host can access card again. Write_timeout is calculated by the R2W_FACTOR field * mult in the CSD. but it is timeout about only one block. so I think that timeout value is multiplied with number of blocks. I will modify v2 patch by adding this code. timeout_us = (mrq-data-timeout_ns * mrq-data-blocks) / 1000; I think that this exception should be like this. If write 128KB request - timeout is calculated to 6.4 sec if it spend 250ms per block - timeout error happen - mmc core send stop cmd - mmc core try to call host reset/cleanup - return write cmd error. How do you think ? -- 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 : Use wait_for_completion_timeout() instead of wait_for_completion in case of write.
On Tue, Sep 20, 2011 at 4:05 PM, NamJae Jeon linkinj...@gmail.com wrote: yes, I knew. But if card keep holding busy line(data 0) in the middle of DMA operation(multi blocks write), host driver layer can not know card status in this situation. The host driver shall start a software timer and indpendently needs to watch out for the expiry of the timeout. If the host doesn't hear back from the controller/DMA engine even after waiting for the specified timeout, then the timer handler that gets invoked can then do the necessary cleanup and inform the MMC core layer that the request failed. Does this sound feasible? -- 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] mmc: card: modify mmc_getgeo function
In the earlier code the cylinder, sector and head are assigned
independently. Current patch generates the cylinder number
with the values of sector and head.
This patch only makes they cylinder value to be dependent on
the sector and head.
Signed-off-by: Girish K S girish.shivananja...@linaro.org
---
drivers/mmc/card/block.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index 1ff5486..bebb13b 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
@@ -226,9 +226,10 @@ static int mmc_blk_release(struct gendisk *disk, fmode_t
mode)
static int
mmc_blk_getgeo(struct block_device *bdev, struct hd_geometry *geo)
{
- geo-cylinders = get_capacity(bdev-bd_disk) / (4 * 16);
geo-heads = 4;
geo-sectors = 16;
+ geo-cylinders = get_capacity(bdev-bd_disk) /
+ (geo-heads * geo-sectors);
return 0;
}
--
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
Re: [PATCH] mmc : export hw reset function info to user
On 18/09/11 18:20, Namjae Jeon wrote:
user app should know whether hw reset function is enable to use it.
so I try to add sysfs file of hw reset function like enhanced area.
This conflicts with my patches:
http://marc.info/?l=linux-mmcm=131462534514277w=2
http://marc.info/?l=linux-mmcm=131462534614281w=2
http://marc.info/?l=linux-mmcm=131462534714284w=2
http://marc.info/?l=linux-mmcm=131462534814287w=2
http://marc.info/?l=linux-mmcm=131462535014290w=2
http://marc.info/?l=linux-mmcm=131462535214297w=2
Signed-off-by: Namjae Jeonlinkinj...@gmail.com
---
drivers/mmc/core/mmc.c |6 ++
include/linux/mmc/card.h |1 +
include/linux/mmc/mmc.h |1 +
3 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
index 10f5a19..06c3ffc 100644
--- a/drivers/mmc/core/mmc.c
+++ b/drivers/mmc/core/mmc.c
@@ -355,6 +355,10 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8
*ext_csd)
card-ext_csd.raw_trim_mult =
ext_csd[EXT_CSD_TRIM_MULT];
if (card-ext_csd.rev= 4) {
+ /* HW reset function feature support.
+ /* user can know it is enable through sysfs interface.
+ card-ext_csd.raw_hw_reset_function =
+ ext_csd[EXT_CSD_RST_FUNCTION];
/*
* Enhanced area feature support -- check whether the eMMC
* card has the Enhanced area enabled. If so, export enhanced
@@ -499,6 +503,7 @@ MMC_DEV_ATTR(serial, 0x%08x\n, card-cid.serial);
MMC_DEV_ATTR(enhanced_area_offset, %llu\n,
card-ext_csd.enhanced_area_offset);
MMC_DEV_ATTR(enhanced_area_size, %u\n, card-ext_csd.enhanced_area_size);
+MMC_DEV_ATTR(raw_hw_reset_function, 0x%02x\n,
card-ext_csd.raw_hw_reset_function);
static struct attribute *mmc_std_attrs[] = {
dev_attr_cid.attr,
@@ -514,6 +519,7 @@ static struct attribute *mmc_std_attrs[] = {
dev_attr_serial.attr,
dev_attr_enhanced_area_offset.attr,
dev_attr_enhanced_area_size.attr,
+ dev_attr_raw_hw_reset_function.attr,
NULL,
};
diff --git a/include/linux/mmc/card.h b/include/linux/mmc/card.h
index b460fc2..237bceb 100644
--- a/include/linux/mmc/card.h
+++ b/include/linux/mmc/card.h
@@ -65,6 +65,7 @@ struct mmc_ext_csd {
unsigned intenhanced_area_size; /* Units: KB */
unsigned intboot_size; /* in bytes */
u8 raw_partition_support; /* 160 */
+ u8 raw_hw_reset_function; /* 162 */
u8 raw_erased_mem_count; /* 181 */
u8 raw_ext_csd_structure; /* 194 */
u8 raw_card_type; /* 196 */
diff --git a/include/linux/mmc/mmc.h b/include/linux/mmc/mmc.h
index 5a794cb..233c932 100644
--- a/include/linux/mmc/mmc.h
+++ b/include/linux/mmc/mmc.h
@@ -272,6 +272,7 @@ struct _mmc_csd {
#define EXT_CSD_PARTITION_ATTRIBUTE 156 /* R/W */
#define EXT_CSD_PARTITION_SUPPORT 160 /* RO */
+#define EXT_CSD_RST_FUNCTION 162 /* R/W */
#define EXT_CSD_WR_REL_PARAM 166 /* RO */
#define EXT_CSD_ERASE_GROUP_DEF 175 /* R/W */
#define EXT_CSD_PART_CONFIG 179 /* R/W */
--
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 : Use wait_for_completion_timeout() instead of wait_for_completion in case of write.
2011/9/20 Murali Krishna Palnati palnati.muralikris...@gmail.com: On Tue, Sep 20, 2011 at 4:05 PM, NamJae Jeon linkinj...@gmail.com wrote: yes, I knew. But if card keep holding busy line(data 0) in the middle of DMA operation(multi blocks write), host driver layer can not know card status in this situation. The host driver shall start a software timer and indpendently needs to watch out for the expiry of the timeout. If the host doesn't hear back from the controller/DMA engine even after waiting for the specified timeout, then the timer handler that gets invoked can then do the necessary cleanup and inform the MMC core layer that the request failed. Does this sound feasible? It may be no good choice that sw timer is on host driver. also I don't know what is different. It is the same as the ata driver's dma_map_sg. dma_map_sg is repectively called in mmc host driver. but it is being processed in ata core of ata driver. because it is common routine, ata core have called it instead of host driver. if it is processed in mmc core, there is no need to modify several hosts.(except dma controller reset) -- 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 : Use wait_for_completion_timeout() instead of wait_for_completion in case of write.
On Tue, Sep 20, 2011 at 7:52 PM, NamJae Jeon linkinj...@gmail.com wrote: It may be no good choice that sw timer is on host driver. also I don't know what is different. It helps to have this functionality implemented at host controller layer so that the host layer is informed about this. If we just end the request from the MMC core layer, host controller driver doesnt even kow about that and it remains in the same state processing the request (that already got timed out at core layer). It is good to have the host layer trigger this timeout, do necessary clean up and then duly end the request by informing the core layer by calling mmc_request_done(). Let me put the question in this way. If the core layer times out (because of wait_for_completion_timeout) then in the patch that you have submitted, i dont see how the host layer knows about it. Apologize, if i sound like a broken record saying the same thing again and again. -- 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 REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
The bindings were recently updated to have separate properties for each
type of GPIO. Update the Device Tree source to match that.
Signed-off-by: Stephen Warren swar...@nvidia.com
Acked-by: Olof Johansson o...@lixom.net
---
I'd previously sent these to Grant assuming they'd go in his dt/next branch,
but perhaps these should go in through Arnd's arm-soc next/dt branch?
arch/arm/boot/dts/tegra-harmony.dts | 12 ++--
arch/arm/boot/dts/tegra-seaboard.dts |6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/tegra-harmony.dts
b/arch/arm/boot/dts/tegra-harmony.dts
index 4c05334..e581866 100644
--- a/arch/arm/boot/dts/tegra-harmony.dts
+++ b/arch/arm/boot/dts/tegra-harmony.dts
@@ -57,14 +57,14 @@
};
sdhci@c8000200 {
- gpios = gpio 69 0, /* cd, gpio PI5 */
- gpio 57 0, /* wp, gpio PH1 */
- gpio 155 0; /* power, gpio PT3 */
+ cd-gpios = gpio 69 0; /* gpio PI5 */
+ wp-gpios = gpio 57 0; /* gpio PH1 */
+ power-gpios = gpio 155 0; /* gpio PT3 */
};
sdhci@c8000600 {
- gpios = gpio 58 0, /* cd, gpio PH2 */
- gpio 59 0, /* wp, gpio PH3 */
- gpio 70 0; /* power, gpio PI6 */
+ cd-gpios = gpio 58 0; /* gpio PH2 */
+ wp-gpios = gpio 59 0; /* gpio PH3 */
+ power-gpios = gpio 70 0; /* gpio PI6 */
};
};
diff --git a/arch/arm/boot/dts/tegra-seaboard.dts
b/arch/arm/boot/dts/tegra-seaboard.dts
index 1940cae..64cedca 100644
--- a/arch/arm/boot/dts/tegra-seaboard.dts
+++ b/arch/arm/boot/dts/tegra-seaboard.dts
@@ -21,8 +21,8 @@
};
sdhci@c8000400 {
- gpios = gpio 69 0, /* cd, gpio PI5 */
- gpio 57 0, /* wp, gpio PH1 */
- gpio 70 0; /* power, gpio PI6 */
+ cd-gpios = gpio 69 0; /* gpio PI5 */
+ wp-gpios = gpio 57 0; /* gpio PH1 */
+ power-gpios = gpio 70 0; /* gpio PI6 */
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH REPOST 2/2] arm/dt: Tegra: Add support-8bit to SDHCI nodes
For Seaboard's internal eMMC, this makes the difference between a
5.5MB/s and 10.2MB/s transfer rate. On Harmony, there wasn't any
measurable difference on my cheap/slow ~2MB/s card.
Signed-off-by: Stephen Warren swar...@nvidia.com
---
arch/arm/boot/dts/tegra-harmony.dts |1 +
arch/arm/boot/dts/tegra-seaboard.dts |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra-harmony.dts
b/arch/arm/boot/dts/tegra-harmony.dts
index e581866..0e225b8 100644
--- a/arch/arm/boot/dts/tegra-harmony.dts
+++ b/arch/arm/boot/dts/tegra-harmony.dts
@@ -66,5 +66,6 @@
cd-gpios = gpio 58 0; /* gpio PH2 */
wp-gpios = gpio 59 0; /* gpio PH3 */
power-gpios = gpio 70 0; /* gpio PI6 */
+ support-8bit;
};
};
diff --git a/arch/arm/boot/dts/tegra-seaboard.dts
b/arch/arm/boot/dts/tegra-seaboard.dts
index 64cedca..a72299b 100644
--- a/arch/arm/boot/dts/tegra-seaboard.dts
+++ b/arch/arm/boot/dts/tegra-seaboard.dts
@@ -25,4 +25,8 @@
wp-gpios = gpio 57 0; /* gpio PH1 */
power-gpios = gpio 70 0; /* gpio PI6 */
};
+
+ sdhci@c8000600 {
+ support-8bit;
+ };
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
On Tue, Sep 20, 2011 at 10:46:25AM -0600, Stephen Warren wrote:
The bindings were recently updated to have separate properties for each
type of GPIO. Update the Device Tree source to match that.
Signed-off-by: Stephen Warren swar...@nvidia.com
Acked-by: Olof Johansson o...@lixom.net
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
I'd previously sent these to Grant assuming they'd go in his dt/next branch,
but perhaps these should go in through Arnd's arm-soc next/dt branch?
Yes, they should probably go via Arnd's tree.
g.
arch/arm/boot/dts/tegra-harmony.dts | 12 ++--
arch/arm/boot/dts/tegra-seaboard.dts |6 +++---
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/tegra-harmony.dts
b/arch/arm/boot/dts/tegra-harmony.dts
index 4c05334..e581866 100644
--- a/arch/arm/boot/dts/tegra-harmony.dts
+++ b/arch/arm/boot/dts/tegra-harmony.dts
@@ -57,14 +57,14 @@
};
sdhci@c8000200 {
- gpios = gpio 69 0, /* cd, gpio PI5 */
- gpio 57 0, /* wp, gpio PH1 */
- gpio 155 0; /* power, gpio PT3 */
+ cd-gpios = gpio 69 0; /* gpio PI5 */
+ wp-gpios = gpio 57 0; /* gpio PH1 */
+ power-gpios = gpio 155 0; /* gpio PT3 */
};
sdhci@c8000600 {
- gpios = gpio 58 0, /* cd, gpio PH2 */
- gpio 59 0, /* wp, gpio PH3 */
- gpio 70 0; /* power, gpio PI6 */
+ cd-gpios = gpio 58 0; /* gpio PH2 */
+ wp-gpios = gpio 59 0; /* gpio PH3 */
+ power-gpios = gpio 70 0; /* gpio PI6 */
};
};
diff --git a/arch/arm/boot/dts/tegra-seaboard.dts
b/arch/arm/boot/dts/tegra-seaboard.dts
index 1940cae..64cedca 100644
--- a/arch/arm/boot/dts/tegra-seaboard.dts
+++ b/arch/arm/boot/dts/tegra-seaboard.dts
@@ -21,8 +21,8 @@
};
sdhci@c8000400 {
- gpios = gpio 69 0, /* cd, gpio PI5 */
- gpio 57 0, /* wp, gpio PH1 */
- gpio 70 0; /* power, gpio PI6 */
+ cd-gpios = gpio 69 0; /* gpio PI5 */
+ wp-gpios = gpio 57 0; /* gpio PH1 */
+ power-gpios = gpio 70 0; /* gpio PI6 */
};
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
On Tuesday 20 September 2011, Stephen Warren wrote: The bindings were recently updated to have separate properties for each type of GPIO. Update the Device Tree source to match that. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Olof Johansson o...@lixom.net --- I'd previously sent these to Grant assuming they'd go in his dt/next branch, but perhaps these should go in through Arnd's arm-soc next/dt branch? Which tree has the update that changed the bindings? I think it should go into the same one. If it's already upstream, I can take it into the fixes branch. Arnd -- 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 REPOST 2/2] arm/dt: Tegra: Add support-8bit to SDHCI nodes
On Tue, Sep 20, 2011 at 10:46:26AM -0600, Stephen Warren wrote:
For Seaboard's internal eMMC, this makes the difference between a
5.5MB/s and 10.2MB/s transfer rate. On Harmony, there wasn't any
measurable difference on my cheap/slow ~2MB/s card.
Signed-off-by: Stephen Warren swar...@nvidia.com
Acked-by: Grant Likely grant.lik...@secretlab.ca
---
arch/arm/boot/dts/tegra-harmony.dts |1 +
arch/arm/boot/dts/tegra-seaboard.dts |4
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra-harmony.dts
b/arch/arm/boot/dts/tegra-harmony.dts
index e581866..0e225b8 100644
--- a/arch/arm/boot/dts/tegra-harmony.dts
+++ b/arch/arm/boot/dts/tegra-harmony.dts
@@ -66,5 +66,6 @@
cd-gpios = gpio 58 0; /* gpio PH2 */
wp-gpios = gpio 59 0; /* gpio PH3 */
power-gpios = gpio 70 0; /* gpio PI6 */
+ support-8bit;
};
};
diff --git a/arch/arm/boot/dts/tegra-seaboard.dts
b/arch/arm/boot/dts/tegra-seaboard.dts
index 64cedca..a72299b 100644
--- a/arch/arm/boot/dts/tegra-seaboard.dts
+++ b/arch/arm/boot/dts/tegra-seaboard.dts
@@ -25,4 +25,8 @@
wp-gpios = gpio 57 0; /* gpio PH1 */
power-gpios = gpio 70 0; /* gpio PI6 */
};
+
+ sdhci@c8000600 {
+ support-8bit;
+ };
};
--
1.7.0.4
--
To unsubscribe from this list: send the line unsubscribe linux-mmc in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
Arnd Bergmann wrote at Tuesday, September 20, 2011 11:43 AM: On Tuesday 20 September 2011, Stephen Warren wrote: The bindings were recently updated to have separate properties for each type of GPIO. Update the Device Tree source to match that. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Olof Johansson o...@lixom.net --- I'd previously sent these to Grant assuming they'd go in his dt/next branch, but perhaps these should go in through Arnd's arm-soc next/dt branch? Which tree has the update that changed the bindings? I think it should go into the same one. If it's already upstream, I can take it into the fixes branch. Chris applied them to the mmc-next tree: git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git which appears to be temporarily at: git://dev.laptop.org/users/cjb/mmc -- nvpublic -- 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 REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
On Tue, Sep 20, 2011 at 07:43:29PM +0200, Arnd Bergmann wrote: On Tuesday 20 September 2011, Stephen Warren wrote: The bindings were recently updated to have separate properties for each type of GPIO. Update the Device Tree source to match that. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Olof Johansson o...@lixom.net --- I'd previously sent these to Grant assuming they'd go in his dt/next branch, but perhaps these should go in through Arnd's arm-soc next/dt branch? Which tree has the update that changed the bindings? I think it should go into the same one. If it's already upstream, I can take it into the fixes branch. Already upstream g. -- 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 REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
Hi, On Tue, Sep 20 2011, Stephen Warren wrote: Arnd Bergmann wrote at Tuesday, September 20, 2011 11:43 AM: On Tuesday 20 September 2011, Stephen Warren wrote: The bindings were recently updated to have separate properties for each type of GPIO. Update the Device Tree source to match that. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Olof Johansson o...@lixom.net --- I'd previously sent these to Grant assuming they'd go in his dt/next branch, but perhaps these should go in through Arnd's arm-soc next/dt branch? Which tree has the update that changed the bindings? I think it should go into the same one. If it's already upstream, I can take it into the fixes branch. Chris applied them to the mmc-next tree: git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git which appears to be temporarily at: git://dev.laptop.org/users/cjb/mmc Sending these via Arnd's next/dt sounds good to me. I know we'd usually take changes that require an atomic update through the same tree, but Stephen said in https://lkml.org/lkml/2011/8/30/352 : I don't think there's actually any need for that; initializing Tegra's SDHCI from device-tree has never worked in mainline to date; it relies on patch 1 being there. And if patch 2 was there without patch 3, the worst that will happen is some port runs in 4-bit mode instead of 8-bit, which evidently works fine since I didn't even notice 8-bit support was missing... 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 REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
On Tuesday 20 September 2011, Grant Likely wrote: On Tue, Sep 20, 2011 at 07:43:29PM +0200, Arnd Bergmann wrote: On Tuesday 20 September 2011, Stephen Warren wrote: The bindings were recently updated to have separate properties for each type of GPIO. Update the Device Tree source to match that. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Olof Johansson o...@lixom.net --- I'd previously sent these to Grant assuming they'd go in his dt/next branch, but perhaps these should go in through Arnd's arm-soc next/dt branch? Which tree has the update that changed the bindings? I think it should go into the same one. If it's already upstream, I can take it into the fixes branch. Already upstream Ok, I see. I've applied both patches to the fixes branch and will send it out with the next pull request for 3.1 to Linus then. Thanks, Arnd -- 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 hangs related to insert/remove of cards
On Tue, Sep 13, 2011 at 3:02 PM, Ulf Hansson ulf.hans...@stericsson.com wrote: During a rescan operation mmc_attach(sd|mmc|sdio) functions are called. The error handling in these function can trigger a detach of the bus, which also meant a power off. This is not notified by the rescan operation which then continues to the next attach function. If a power off has been done, the framework must never send any new commands to the host driver, without first doing a new power up. This will most likely trigger any host driver to hang. Moving power off out of detach and instead handle power off separately when it is actually needed, solves the issue. Signed-off-by: Ulf Hansson ulf.hans...@stericsson.com Acked-by: Linus Walleij linus.wall...@linaro.org Thanks, Linus Walleij -- 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 REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
On Tuesday 20 September 2011, Arnd Bergmann wrote: On Tuesday 20 September 2011, Grant Likely wrote: On Tue, Sep 20, 2011 at 07:43:29PM +0200, Arnd Bergmann wrote: On Tuesday 20 September 2011, Stephen Warren wrote: The bindings were recently updated to have separate properties for each type of GPIO. Update the Device Tree source to match that. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Olof Johansson o...@lixom.net --- I'd previously sent these to Grant assuming they'd go in his dt/next branch, but perhaps these should go in through Arnd's arm-soc next/dt branch? Which tree has the update that changed the bindings? I think it should go into the same one. If it's already upstream, I can take it into the fixes branch. Already upstream Ok, I see. I've applied both patches to the fixes branch and will send it out with the next pull request for 3.1 to Linus then. Sorry, I just noticed that the second patch is not a bug fix, so I took it out again and kept only patch 1/2 in the fixes branch for 3.1. Should I take the other one as well? It's probably better to let that go the proper way through the tegra tree for 3.2, right? Arnd -- 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 REPOST 1/2] arm/dt: Tegra: Update SDHCI nodes to match bindings
On Tue, Sep 20, 2011 at 2:01 PM, Arnd Bergmann a...@arndb.de wrote: On Tuesday 20 September 2011, Arnd Bergmann wrote: On Tuesday 20 September 2011, Grant Likely wrote: On Tue, Sep 20, 2011 at 07:43:29PM +0200, Arnd Bergmann wrote: On Tuesday 20 September 2011, Stephen Warren wrote: The bindings were recently updated to have separate properties for each type of GPIO. Update the Device Tree source to match that. Signed-off-by: Stephen Warren swar...@nvidia.com Acked-by: Olof Johansson o...@lixom.net --- I'd previously sent these to Grant assuming they'd go in his dt/next branch, but perhaps these should go in through Arnd's arm-soc next/dt branch? Which tree has the update that changed the bindings? I think it should go into the same one. If it's already upstream, I can take it into the fixes branch. Already upstream Ok, I see. I've applied both patches to the fixes branch and will send it out with the next pull request for 3.1 to Linus then. Sorry, I just noticed that the second patch is not a bug fix, so I took it out again and kept only patch 1/2 in the fixes branch for 3.1. Should I take the other one as well? It's probably better to let that go the proper way through the tegra tree for 3.2, right? Given that you have a public tree right now, and I don't (since kernel.org is down), please feel free to start a tegra/for-3.2 branch for me and apply it there. I'll base further work on top of that if needed. (There also aren't a whole lot of other patches queued for 3.2 right now). -Olof -- 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 : Use wait_for_completion_timeout() instead of wait_for_completion in case of write.
2011/9/21 Murali Krishna Palnati palnati.muralikris...@gmail.com:
On Tue, Sep 20, 2011 at 7:52 PM, NamJae Jeon linkinj...@gmail.com wrote:
It may be no good choice that sw timer is on host driver. also I don't
know what is different.
It helps to have this functionality implemented at host controller
layer so that the host layer is informed about this. If we just end
the request from the MMC core layer, host controller driver doesnt
even kow about that and it remains in the same state processing the
request (that already got timed out at core layer). It is good to have
the host layer trigger this timeout, do necessary clean up and then
duly end the request by informing the core layer by calling
mmc_request_done().
Let me put the question in this way. If the core layer times out
(because of wait_for_completion_timeout) then in the patch that you
have submitted, i dont see how the host layer knows about it.
Apologize, if i sound like a broken record saying the same thing again
and again.
I understand what you want. So I will add emergency_cleanup for host
driver like this.
struct mmc_host_ops {
.
void (*emergency_cleanup)(struct mmc_host *host);
}
When timeout error happen, mmc core will call this function as soon as
sending stop cmd.
And when timeout error happen by wait_for_completion_timeout, calling
mmc_request_done is not needed.
Thanks.
--
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 : Use wait_for_completion_timeout() instead of wait_for_completion in case of write.
2011/9/21 NamJae Jeon linkinj...@gmail.com:
2011/9/21 Murali Krishna Palnati palnati.muralikris...@gmail.com:
On Tue, Sep 20, 2011 at 7:52 PM, NamJae Jeon linkinj...@gmail.com wrote:
It may be no good choice that sw timer is on host driver. also I don't
know what is different.
It helps to have this functionality implemented at host controller
layer so that the host layer is informed about this. If we just end
the request from the MMC core layer, host controller driver doesnt
even kow about that and it remains in the same state processing the
request (that already got timed out at core layer). It is good to have
the host layer trigger this timeout, do necessary clean up and then
duly end the request by informing the core layer by calling
mmc_request_done().
Let me put the question in this way. If the core layer times out
(because of wait_for_completion_timeout) then in the patch that you
have submitted, i dont see how the host layer knows about it.
Apologize, if i sound like a broken record saying the same thing again
and again.
I understand what you want. So I will add emergency_cleanup for host
driver like this.
struct mmc_host_ops {
.
void (*emergency_cleanup)(struct mmc_host *host);
}
When timeout error happen, mmc core will call this function as soon as
sending stop cmd.
And when timeout error happen by wait_for_completion_timeout, calling
mmc_request_done is not needed.
Thanks.
I'll follow the opinion of chris.
Thanks.
--
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
