On 3 December 2014 at 14:43, Ludovic Desroches
ludovic.desroc...@atmel.com wrote:
Use SET_RUNTIME_PM_OPS() since SET_PM_RUNTIME_PM_OPS() has been dropped.
Signed-off-by: Ludovic Desroches ludovic.desroc...@atmel.com
Rafael have solved the issue in linux-next by:
#define SET_PM_RUNTIME_PM_OPS
Hi Ulf,
We have decided to drop this patch.
Thanks,
Avinash
From: Avinash Patil
Sent: Tuesday, December 02, 2014 2:55 PM
To: Ulf Hansson
Cc: linux-mmc; linux-wirel...@vger.kernel.org; Amitkumar Karwar; Cathy Luo;
Marc Yang; Xinming Hu;
Hi Lee,
this patch can be applied if you think it is ok, it doesn't depends
other patches.
regards.
micky.
On 12/05/2014 01:54 PM, micky_ch...@realsil.com.cn wrote:
From: Micky Ching micky_ch...@realsil.com.cn
Add helper function to write u32 to registers, if we want to put u32
value to 4
On 5 December 2014 at 10:24, Avinash Patil pat...@marvell.com wrote:
Hi Ulf,
We have decided to drop this patch.
Why?
Kind regards
Uffe
Thanks,
Avinash
From: Avinash Patil
Sent: Tuesday, December 02, 2014 2:55 PM
To: Ulf Hansson
Cc: linux-mmc;
On 5 December 2014 at 07:41, Suneel G suneelgarap...@gmail.com wrote:
Hello Ulf/Chris,
mmc-utils.git seems to be limited and handles specific eMMC commands from
userspace.
That's not a limit. It's per design.
Can you help me with info/web links to repos/utils which help in issuing
To be able to use mmc_send_tuning() prior the struct mmc_card has been
allocated, let's convert it to take the struct mmc_host* as parameter
instead.
Suggested-by: Stephen Boyd sb...@codeaurora.org
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
drivers/mmc/core/mmc_ops.c | 7 +++
The commit 0718e59ae259 (mmc: sdhci: move FSL ESDHC reset handling quirk into
esdhc code) states that Freescale esdhc is the only controller which needs
the interrupt registers restored after a reset. So it moves
SDHCI_QUIRK_RESTORE_IRQS_AFTER_RESET quirk handling code into the
esdhc-imx driver
On Mon, Dec 01, 2014 at 05:02:07PM +0100, Ulf Hansson wrote:
Instead of having a local function taking care of sending the tuning
command, let's use the common mmc_send_tuning() API provided by the mmc
core. In this way the request will be handled as any other request by
sdhci core.
As an
On Thu, Dec 04, 2014 at 12:50:02PM -0800, Stephen Boyd wrote:
On 12/01/2014 08:02 AM, Ulf Hansson wrote:
Due to commit mmc: core: add core-level function for sending tuning
commands,
the mmc core provides an API to send the tuning command and as well compare
the
response pattern.
Instead of having a local hack taking care of sending the tuning
command and as well to verify the response pattern, let's convert to
the common mmc_send_tuning() API.
This change affects the Exynos variant, since it's the only one which
support the dw_mmc's -execute_tuning() callback.
Changes in v2:
Rebased on latest next branch, which means the mmc_send_tuning() has
changed to take the struct mmc_host as parameter instead of the struct
mmc_card.
Due to commit mmc: core: add core-level function for sending tuning commands,
the mmc core provides an API
Instead of having a local function taking care of sending the tuning
command, let's use the common mmc_send_tuning() API provided by the mmc
core. In this way the request will be handled as any other request by
sdhci core.
As an effect of this change, the pm_runtime_get_sync() call at
Instead of having a local hack taking care of sending the tuning
command and as well to verify the response pattern, let's convert to
the common mmc_send_tuning() API instead.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
Changes in v2:
Rebased, to get latest version of the
Since previous patches removed the need for the tuning block patterns
to be exported, let's move them close to the mmc_send_tuning() API.
Those are now intended to be used only by the mmc core.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
---
Changes in v2:
None.
---
On 5 December 2014 at 12:11, Dong Aisheng b29...@freescale.com wrote:
On Mon, Dec 01, 2014 at 05:02:07PM +0100, Ulf Hansson wrote:
Instead of having a local function taking care of sending the tuning
command, let's use the common mmc_send_tuning() API provided by the mmc
core. In this way the
On Fri, Dec 5, 2014 at 5:58 PM, Alessio Igor Bogani
alessio.bog...@elettra.eu wrote:
The commit 0718e59ae259 (mmc: sdhci: move FSL ESDHC reset handling quirk into
esdhc code) states that Freescale esdhc is the only controller which needs
the interrupt registers restored after a reset. So it
On 12/05/2014 01:59 PM, Ulf Hansson wrote:
Instead of having a local hack taking care of sending the tuning
command and as well to verify the response pattern, let's convert to
the common mmc_send_tuning() API instead.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Hi Ulf,
Tuning works
The tuning timer is always used if the tuning mode
is 1 and there is a tuning count, irrespective of
whether this is the first call, or any subsequent
call. Consequently the logic to start the timer
can be simplified.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
Re-tuning requires that the maximum data length
is limited to 4MiB. The code currently changes
max_blk_count in an attempt to achieve that.
This is wrong because max_blk_count is a different
limit, but it is also un-necessary because
max_req_size is 512KiB anyway. Consequently, the
changes to
A 'goto' can be used to save duplicating unlocking
and returning.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
drivers/mmc/host/sdhci.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index b3d68e0..2efa7fe
Hi
Here is V2 of patches to disable re-tuning for HS400.
As described in patch 4, re-tuning for HS400 has to be done
in HS200 mode, but there is no support for that, so re-tuning
needs to be disabled until support is added.
Changes in V2:
Added mmc: sdhci: Simplify use of tuning timer
Re-tuning for HS400 mode must be done in HS200
mode. Currently there is no support for that.
That needs to be reflected in the code.
Specifically, if tuning is executed in HS400 mode
then return an error, and do not start the
tuning timer if HS200 tuning is being done prior
to switching to HS400.
Possibly a command is failing because re-tuning is needed.
Use mmc_retune_retry() to check re-tuning. At that point
re-tuning is held, at least by the request, so
mmc_retune_retry() does a mmc_retune_release() and
mmc_retune_hold().
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
Both callers of mmc_start_request() call mmc_card_removed()
so move that call into mmc_start_request().
This patch is preparation for adding re-tuning support.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
drivers/mmc/core/core.c | 32
1 file changed,
Hold re-tuning during switch commands to prevent
it from conflicting with the busy state or the CMD13
verification.
Signed-off-by: Adrian Hunter adrian.hun...@intel.com
---
drivers/mmc/core/mmc_ops.c | 31 +--
1 file changed, 21 insertions(+), 10 deletions(-)
diff
Make use of mmc core support for re-tuning instead
of doing it all in the sdhci driver.
This patch also changes to flag the need for re-tuning
always after runtime suspend when tuning has been used
at initialization. Previously it was only done if
the re-tuning timer was in use.
Signed-off-by:
Currently, there is core support for tuning during
initialization. There can also be a need to re-tune
periodically (e.g. sdhci) or to re-tune after the
host controller is powered off (e.g. after PM
runtime suspend / resume) or to re-tune in response
to CRC errors.
The main requirements for
Hi
Here are some patches to move re-tuning support out of
sdhci and into the core, and add support for HS400
re-tuning.
Currently sdhci does re-tuning transparently by
calling sdhci_execute_tuning() from its -request()
function.
The problem with HS400 re-tuning is that it must be
done in HS200
Re-tuning is done before a request is sent to the card.
Host controller drivers can choose to enable re-tuning
when tuning is done during card initialization. To
ensure that re-tuning gets disabled, add disabling to
mmc_set_initial_state() which is called whenever the
card is powered on, off, or
On 12/05/2014 02:41 AM, Ulf Hansson wrote:
To be able to use mmc_send_tuning() prior the struct mmc_card has been
allocated, let's convert it to take the struct mmc_host* as parameter
instead.
Suggested-by: Stephen Boyd sb...@codeaurora.org
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
On 12/05/2014 03:59 AM, Ulf Hansson wrote:
Since previous patches removed the need for the tuning block patterns
to be exported, let's move them close to the mmc_send_tuning() API.
Those are now intended to be used only by the mmc core.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
On 12/05/2014 03:59 AM, Ulf Hansson wrote:
Instead of having a local hack taking care of sending the tuning
command and as well to verify the response pattern, let's convert to
the common mmc_send_tuning() API instead.
Signed-off-by: Ulf Hansson ulf.hans...@linaro.org
Reviewed-by: Stephen
Seems like the BROKEN_DTO also affects EVENT_DATA_COMPLETE, sometimes we don't
see that (but we do see EVENT_XFER_COMPLETE), leave the state machine and never
come back to it to timeout. I have this happening on emmc specifically, haven't
seen it on sdmmc yet.
The fix is to also start the timer
33 matches
Mail list logo
