On Tue, Sep 3, 2013 at 11:29 AM, Ulf Hansson wrote:
> By optionally putting the pins into sleep state in the .runtime_suspend
> callback we can accomplish two things. One is to minimize current leakage
> from pins and thus save power, second we can prevent the IP from driving
> pins output in an
On Tue, Sep 3, 2013 at 11:29 AM, Ulf Hansson wrote:
> There is no need for every driver to fetch a pinctrl handle and to
> select the default state. Instead this is handled by the device driver
> core, thus we can remove this piece of code from mmci.
>
> Signed-off-by: Ulf Hansson
> Cc: Linus Wa
Hi Prasanna,
You can refer to
http://permalink.gmane.org/gmane.linux.kernel.mmc/15430
Best Regards,
Jaehoon Chung
On 09/03/2013 06:34 PM, Nitin Singla wrote:
> Hi Prasanna,
>
> MMC-Utils open source utility for enabling and disabling features.
> It use ioctl defined in block/card to send comma
On Tue, September 03, 2013, Ulf Hansson wrote:
> On 26 August 2013 09:20, Seungwon Jeon wrote:
> > While speed mode is changed, CMD13 cannot be guaranteed.
> > According to the spec., it is not recommended to use CMD13
> > to check the busy completion of the timing change.
> > If CMD13 is used in
On 3 September 2013 19:04, Chris Ball wrote:
> On Tue, Sep 03 2013, Daniel J Blueman wrote:
>> Please let me know if there's a better vector for reporting and
>> looking into this issue, if you can.
>
> Do you know whether it's ever worked on this hardware? If so, could
> you try bisecting to fin
On 09/02/2013 11:08 PM, Vinod Koul wrote:
> On Thu, Aug 29, 2013 at 06:05:41PM -0500, Joel Fernandes wrote:
>> Process SG-elements in batches of MAX_NR_SG if they are greater
>> than MAX_NR_SG. Due to this, at any given time only those many
>> slots will be used in the given channel no matter how l
On 26 August 2013 09:20, Seungwon Jeon wrote:
> While speed mode is changed, CMD13 cannot be guaranteed.
> According to the spec., it is not recommended to use CMD13
> to check the busy completion of the timing change.
> If CMD13 is used in this case, CRC error must be ignored.
>
> Signed-off-by:
Hi,
On 08/30/2013 10:22 AM, Chris Ball wrote:
> Hi,
>
> On Fri, Aug 02 2013, Jaehoon Chung wrote:
>> Fixed the warning message.(clk_disable/enable didn't pair)
>> [..]
>>
>> Signed-off-by: Jaehoon Chung
>> Signed-off-by: Kyungmin Park
>> Acked-by: Heiko Stuebner
>> Tested-by: Heiko Stuebner
>
After a write to the MMCICLOCK register data cannot be written to this
register for three feedback clock cycles. Writes to the MMCIPOWER
register must be separated by three MCLK cycles. Previously no issues
has been observered, but using higher ARM clock frequencies on STE-
platforms has triggered
On 3 September 2013 11:50, Daniel Lezcano wrote:
> On 09/03/2013 11:29 AM, Ulf Hansson wrote:
>> After a write to the MMCICLOCK register data cannot be written to this
>> register for three feedback clock cycles. Writes to the MMCIPOWER
>> register must be separated by three MCLK cycles. Previousl
On 03.09.2013 13:26, Chris Ball wrote:
Hi,
On Tue, Sep 03 2013, Dirk Behme wrote:
+ if ((cmd.opcode == MMC_SWITCH) && ((cmd.arg >> 24) & 0x3)) {
+ /* In case the IOCTL has modified the EXT_CSD, update
it, i.e. re-read the EXT_CSD */
+ mmc_update_ext_csd(card->e
Hi,
On Tue, Sep 03 2013, Dirk Behme wrote:
> + if ((cmd.opcode == MMC_SWITCH) && ((cmd.arg >> 24) & 0x3)) {
> + /* In case the IOCTL has modified the EXT_CSD, update
> it, i.e. re-read the EXT_CSD */
> + mmc_update_ext_csd(card->ext_csd);
> + }
> +
Your analy
Hi,
On Tue, Sep 03 2013, Seungwon Jeon wrote:
> Please could you apply this updates for mmc-next?
3.11 is released, so it's too late to apply these to the 3.12-rc1
merge, since there would be no time to test them in linux-next. But
it looks like many of them are fixes, so we can just send those
Hi,
using the MMC_SWITCH command via the ioctl to write registers of the
EXT_CSD, it looks to us that in this case the internal ext_csd data
structure isn't updated. Resulting in a mismatch of what the ext_csd
data structure contains and what's written to the real hardware.
We are using the
On Mon, August 26, 2013, Seungwon Jeon wrote:
> While speed mode is changed, CMD13 cannot be guaranteed.
> According to the spec., it is not recommended to use CMD13
> to check the busy completion of the timing change.
> If CMD13 is used in this case, CRC error must be ignored.
>
> Signed-off-by:
On 09/03/2013 11:29 AM, Ulf Hansson wrote:
> If a corresponding power domain exists for the device and it manages
> to cut the domain regulator while the device is runtime suspended,
> the IP loses it's registers context. We restore the context in the
> .runtime_resume callback from the existing re
On 09/03/2013 11:29 AM, Ulf Hansson wrote:
> After a write to the MMCICLOCK register data cannot be written to this
> register for three feedback clock cycles. Writes to the MMCIPOWER
> register must be separated by three MCLK cycles. Previously no issues
> has been observered, but using higher ARM
Hi Prasanna,
MMC-Utils open source utility for enabling and disabling features.
It use ioctl defined in block/card to send commands to host.
git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc-utils.git
Thanks,
Nitin
On Tue, Sep 3, 2013 at 2:28 PM, Prasanna NAVARATNA
wrote:
> Hello Jaehoon,
>
After a write to the MMCICLOCK register data cannot be written to this
register for three feedback clock cycles. Writes to the MMCIPOWER
register must be separated by three MCLK cycles. Previously no issues
has been observered, but using higher ARM clock frequencies on STE-
platforms has triggered
To be able to enter ap_sleep state in cpuidle were the APE power domain
regulator will be cut, a register save and restore mechanism needs to be
implemented. This patchset adapts to these restrictions.
Changes in v3:
- Fold in a new patch, mmc: mmci: Adapt to new pinctrl handling
-
By optionally putting the pins into sleep state in the .runtime_suspend
callback we can accomplish two things. One is to minimize current leakage
from pins and thus save power, second we can prevent the IP from driving
pins output in an uncontrolled manner, which may happen if the power domain
drop
There is no need for every driver to fetch a pinctrl handle and to
select the default state. Instead this is handled by the device driver
core, thus we can remove this piece of code from mmci.
Signed-off-by: Ulf Hansson
Cc: Linus Walleij
---
drivers/mmc/host/mmci.c | 17 -
dri
If a corresponding power domain exists for the device and it manages
to cut the domain regulator while the device is runtime suspended,
the IP loses it's registers context. We restore the context in the
.runtime_resume callback from the existing register caches to adapt
to this siutuation.
We also
Hello Jaehoon,
> Why do you use MMC_CAP2_BKOPS_EN?
Because BKOPS on eMMC4.41 is optional. So the capability is provided for the
platform to either enable/disable this feature (its not mandatory to always
enable BKOPS on 4.41)
> Maybe we had discussed about this point. i know that we can enable th
Hi Chris,
Please could you apply this updates for mmc-next?
Thanks,
Seungwon Jeon
On Sat, August 31, 2013, Seungwon Jeon wrote:
> This patch set includes updates of dw_mmc driver.
>
> - Tuning scheme for high speed mode such as HS200.
> - Support of HS200 mode in exynos host
> - Involved some f
Hi, Anton and all
I update all the patch send.
Kindly for review.
Thanks.
On 09/03/2013 03:33 PM, Haijun Zhang wrote:
Add this file to help detect cpu type in runtime.
These macros will be more favorable for driver
to apply errata and workaround to specified cpu type.
Signed-off-by: Haijun Z
eSDHC host is not a standand host, there is no
SDHCI_CTRL_HISPD bit in SDHCI_HOST_CONTROL register.
Add this quirk to avoid changing the Data transfer width
bit of eSDHC host.
Signed-off-by: Haijun Zhang
---
drivers/mmc/host/sdhci-esdhc.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drive
A-004388: eSDHC DMA might not stop if error occurs on system transaction
eSDHC DMA(SDMA/ADMA) might not stop if an error occurs in the last system
transaction. It may continue initiating additional transactions until
software reset for data/all is issued during error recovery. There is not
any dat
Add this file to help detect cpu type in runtime.
These macros will be more favorable for driver
to apply errata and workaround to specified cpu type.
Signed-off-by: Haijun Zhang
Signed-off-by: Zhao Chenhui
---
arch/powerpc/include/asm/mpc85xx.h | 92 ++
1 fi
In some case, sdhci_reset is need to be invoked in some
platform related workaround. So export it for public use.
Signed-off-by: Haijun Zhang
---
drivers/mmc/host/sdhci.c | 3 ++-
drivers/mmc/host/sdhci.h | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci
Vender version and sdhc spec version of T4240-R1.0-R2.0 is incorrect.
The right value should be VVN=0x13, SVN = 0x1. The wrong version number
will break down the ADMA data transfer. This defect only exist in
T4240-R1.0-R2.0.
Signed-off-by: Haijun Zhang
---
- Depend on patch [1/5]
driver
31 matches
Mail list logo
