Hi, Doug
I have two cards which are easy to get "Timeout sending command":
one is ADATA uhs-1 SDR50, another is Kingston uhs-1 SDR104.
After merge three patches:
--
* mmc: dw_mmc: Don't start commands while busy
https://patchwork.kernel.org/patch/5858221/
* mmc: dw_mmc: Make sure we only
Hi, Doug
I have two cards which are easy to get Timeout sending command:
one is ADATA uhs-1 SDR50, another is Kingston uhs-1 SDR104.
After merge three patches:
--
* mmc: dw_mmc: Don't start commands while busy
https://patchwork.kernel.org/patch/5858221/
* mmc: dw_mmc: Make sure we only adjust
a
data transfer again if we got DRTO and EBE interrupt.
After this patch, all mmc_test cases can pass on RK3288-Pink2 board.
Signed-off-by: Addy Ke
---
Changes in v2:
- DRTO and EBE are both set, should not send abort command too,
suggested by Doug Anderson.
drivers/mmc/host/dw_mmc.c | 10
resume test.
Reviewed-by: Doug Anderson
Signed-off-by: Addy Ke
---
Changes in v2:
- add this capability for all 4 slots, suggested by Doug Anderson.
drivers/mmc/host/dw_mmc-rockchip.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
b/drivers/mmc/host
Hi, Javier and Alim
These days are Spring Festival holiday.
Sorry for late reply.
On 2015/2/15 19:41, Javier Martinez Canillas wrote:
> Hello Addy,
>
> On Sat, Feb 14, 2015 at 7:17 AM, Addy Ke wrote:
>> patch 1: This patch can fix bug that controller is still data busy after
&g
Hi, Alim
Sorry for late reply.
On 2015/2/16 07:28, Alim Akhtar wrote:
> Hi Addy,
>
> On Sat, Feb 14, 2015 at 11:47 AM, Addy Ke wrote:
>> As show in mmc_power_up(), in MMC_POWER_UP state, the voltage isn't
>> stable and we may get 'data busy' which can't be cleaned by re
Hi, Alim
Sorry for late reply.
On 2015/2/16 07:28, Alim Akhtar wrote:
Hi Addy,
On Sat, Feb 14, 2015 at 11:47 AM, Addy Ke addy...@rock-chips.com wrote:
As show in mmc_power_up(), in MMC_POWER_UP state, the voltage isn't
stable and we may get 'data busy' which can't be cleaned by resetting
Hi, Javier and Alim
These days are Spring Festival holiday.
Sorry for late reply.
On 2015/2/15 19:41, Javier Martinez Canillas wrote:
Hello Addy,
On Sat, Feb 14, 2015 at 7:17 AM, Addy Ke addy...@rock-chips.com wrote:
patch 1: This patch can fix bug that controller is still data busy after
a
data transfer again if we got DRTO and EBE interrupt.
After this patch, all mmc_test cases can pass on RK3288-Pink2 board.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- DRTO and EBE are both set, should not send abort command too,
suggested by Doug Anderson.
drivers/mmc
resume test.
Reviewed-by: Doug Anderson diand...@chromium.org
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- add this capability for all 4 slots, suggested by Doug Anderson.
drivers/mmc/host/dw_mmc-rockchip.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mmc
We should wait until unbusy before the next request.
But this does't need if the command is CMD13, which can access
SD Status register regardless of data busy.
Signed-off-by: Addy Ke
---
Changes in v4:
- CMD13 doesn't need wait until unbusy.
drivers/mmc/host/dw_mmc.c | 4
1 file changed
and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke
Changes in v4:
- Retry to wait and reset all blocks until data unbusy.
I have a sd card, which need retry 2 times to change to unbusy state.
---
drivers
: This patch fix bug that there is data busy before sdio send CMD53.
But This patch is necessary for sd and mmc too.
Addy Ke (3):
mmc: dw_mmc: update clock after host reach a stable voltage
mmc: dw_mmc: fix bug that cause 'Timeout sending command'
mmc: dw_mmc: Don't start command
As show in mmc_power_up(), in MMC_POWER_UP state, the voltage isn't
stable and we may get 'data busy' which can't be cleaned by resetting
all blocks. So we should not send command to update clock in this state.
Signed-off-by: Addy Ke
---
drivers/mmc/host/dw_mmc.c | 3 ++-
1 file changed, 2
We should wait for data busy here in non-volt-switch state.
This may happend when sdio sends CMD53.
Signed-off-by: Addy Ke
---
drivers/mmc/host/dw_mmc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index f0d9da5..23507c9 100644
and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke
---
drivers/mmc/host/dw_mmc.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc
: This patch fix bug that there is data busy before sdio send CMD53.
But This patch is necessary for sd and mmc too.
Addy Ke (3):
mmc: dw_mmc: update clock after host reach a stable voltage
mmc: dw_mmc: fix bug that cause 'Timeout sending command'
mmc: dw_mmc: Don't start command
As show in mmc_power_up(), in MMC_POWER_UP state, the voltage isn't
stable and we may get 'data busy' which can't be cleaned by resetting
all blocks. So we should not send command to update clock in this state.
Signed-off-by: Addy Ke
---
drivers/mmc/host/dw_mmc.c | 3 ++-
1 file changed, 2
On 2015/2/12 21:59, Alim Akhtar wrote:
> On Thu, Feb 12, 2015 at 4:40 PM, Andrzej Hajda wrote:
>> On 02/12/2015 03:28 AM, addy ke wrote:
>>> Hi Andrzej and Alim
>>>
>>> On 2015/2/12 07:20, Alim Akhtar wrote:
>>>> Hi Andrzej,
>>>>
On 2015/2/12 21:59, Alim Akhtar wrote:
On Thu, Feb 12, 2015 at 4:40 PM, Andrzej Hajda a.ha...@samsung.com wrote:
On 02/12/2015 03:28 AM, addy ke wrote:
Hi Andrzej and Alim
On 2015/2/12 07:20, Alim Akhtar wrote:
Hi Andrzej,
On Wed, Feb 11, 2015 at 5:28 PM, Andrzej Hajda a.ha
As show in mmc_power_up(), in MMC_POWER_UP state, the voltage isn't
stable and we may get 'data busy' which can't be cleaned by resetting
all blocks. So we should not send command to update clock in this state.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 3
that there is data busy before sdio send CMD53.
But This patch is necessary for sd and mmc too.
Addy Ke (3):
mmc: dw_mmc: update clock after host reach a stable voltage
mmc: dw_mmc: fix bug that cause 'Timeout sending command'
mmc: dw_mmc: Don't start command while data busy
We should wait for data busy here in non-volt-switch state.
This may happend when sdio sends CMD53.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index
and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/mmc/host
We should wait until unbusy before the next request.
But this does't need if the command is CMD13, which can access
SD Status register regardless of data busy.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v4:
- CMD13 doesn't need wait until unbusy.
drivers/mmc/host/dw_mmc.c | 4
and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke addy...@rock-chips.com
Changes in v4:
- Retry to wait and reset all blocks until data unbusy.
I have a sd card, which need retry 2 times to change to unbusy
that there is data busy before sdio send CMD53.
But This patch is necessary for sd and mmc too.
Addy Ke (3):
mmc: dw_mmc: update clock after host reach a stable voltage
mmc: dw_mmc: fix bug that cause 'Timeout sending command'
mmc: dw_mmc: Don't start command while data busy
As show in mmc_power_up(), in MMC_POWER_UP state, the voltage isn't
stable and we may get 'data busy' which can't be cleaned by resetting
all blocks. So we should not send command to update clock in this state.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 3
resume test.
Signed-off-by: Addy Ke
---
drivers/mmc/host/dw_mmc-rockchip.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
b/drivers/mmc/host/dw_mmc-rockchip.c
index e2a726a..e5f57b5 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
+++ b/drivers/mmc
resume test.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc-rockchip.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc-rockchip.c
b/drivers/mmc/host/dw_mmc-rockchip.c
index e2a726a..e5f57b5 100644
--- a/drivers/mmc/host/dw_mmc-rockchip.c
will be in busy state. This should not happend when mmc controller
>>>>> send command to update card clocks. If this happends, mci_send_cmd will
>>>>> be failed and we will get 'Timeout sending command', and then system will
>>>>> be blocked. To avoid t
Hi Andrzej and Alim
On 2015/2/12 07:20, Alim Akhtar wrote:
Hi Andrzej,
On Wed, Feb 11, 2015 at 5:28 PM, Andrzej Hajda a.ha...@samsung.com wrote:
Hi Alim,
On 02/11/2015 03:57 AM, Addy wrote:
On 2015/02/10 23:22, Alim Akhtar wrote:
Hi Addy,
On Mon, Feb 9, 2015 at 12:55 PM, Addy Ke addy
On 2015/2/9 15:04, Jaehoon Chung wrote:
> On 02/09/2015 03:56 PM, Addy wrote:
>>
>>
>> On 2015.02.09 12:51, Ulf Hansson wrote:
>>> On 5 February 2015 at 12:13, Addy Ke wrote:
>>>> Because of some uncertain factors, such as worse card or worse h
On 2015/2/9 15:04, Jaehoon Chung wrote:
On 02/09/2015 03:56 PM, Addy wrote:
On 2015.02.09 12:51, Ulf Hansson wrote:
On 5 February 2015 at 12:13, Addy Ke addy...@rock-chips.com wrote:
Because of some uncertain factors, such as worse card or worse hardware,
DAT[3:0](the data lines) may
We should wait for data busy here in non-volt-switch state.
This may happend when sdio sends CMD53.
Signed-off-by: Addy Ke
---
drivers/mmc/host/dw_mmc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b0b57e3..b40080d 100644
Addy Ke (2):
mmc: dw_mmc: fix bug that cause 'Timeout sending command'
mmc: dw_mmc: Don't start command while data busy
drivers/mmc/host/dw_mmc.c | 35 +++
1 file changed, 35 insertions(+)
--
Changes in v2:
- add new patch to handle data busy when start
and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke
---
drivers/mmc/host/dw_mmc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host
Addy Ke (2):
mmc: dw_mmc: fix bug that cause 'Timeout sending command'
mmc: dw_mmc: Don't start command while data busy
drivers/mmc/host/dw_mmc.c | 35 +++
1 file changed, 35 insertions(+)
--
Changes in v2:
- add new patch to handle data busy when start
and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 28
1 file changed, 28 insertions(+)
diff --git a/drivers/mmc/host
We should wait for data busy here in non-volt-switch state.
This may happend when sdio sends CMD53.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index
Signed-off-by: Addy Ke
---
Changes in v2:
- fix some typo
Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
drivers/mmc/core/host.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt
b/Documentation/devicetree
and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke
---
drivers/mmc/host/dw_mmc.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host
Signed-off-by: Addy Ke
---
Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++
drivers/mmc/core/host.c | 2 ++
2 files changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt
b/Documentation/devicetree/bindings/mmc/mmc.txt
index
and we will get 'Timeout sending command', and then system will
be blocked. To avoid this, we need reset mmc controller.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/mmc/host/dw_mmc.c b
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- fix some typo
Documentation/devicetree/bindings/mmc/mmc.txt | 1 +
drivers/mmc/core/host.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt
b
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Documentation/devicetree/bindings/mmc/mmc.txt | 11 +++
drivers/mmc/core/host.c | 2 ++
2 files changed, 13 insertions(+)
diff --git a/Documentation/devicetree/bindings/mmc/mmc.txt
b/Documentation/devicetree
a
data transfer again if we got DRTO and EBE interrupt.
After this patch, all mmc_test cases can pass on RK3288-Pink2 board.
Signed-off-by: Addy Ke
---
drivers/mmc/host/dw_mmc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc
We need to take the card pointer in execute_tuning() for mmc_send_status(),
but mmc->card is NULL in tuning state. So we need change the first parameter
of execute_tuning() to card pointer(struct mmc_card * card).
Signed-off-by: Addy Ke
---
drivers/mmc/core/core.c | 2 +-
drivers/
This patch based on Alex's patch:
https://patchwork.kernel.org/patch/5516411/
Signed-off-by: Addy Ke
---
drivers/mmc/core/mmc_ops.h | 1 -
drivers/mmc/host/dw_mmc.c | 48 --
include/linux/mmc/card.h | 2 ++
3 files changed, 44 insertions(+), 7
Addy Ke (2):
mmc: core: use card pointer as the first parameter of execute_tuning()
mmc: dw_mmc: wait until card ready if tuning fails
drivers/mmc/core/core.c | 2 +-
drivers/mmc/core/mmc_ops.h| 1 -
drivers/mmc/host/dw_mmc.c | 51
We need to take the card pointer in execute_tuning() for mmc_send_status(),
but mmc-card is NULL in tuning state. So we need change the first parameter
of execute_tuning() to card pointer(struct mmc_card * card).
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/core/core.c
This patch based on Alex's patch:
https://patchwork.kernel.org/patch/5516411/
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/core/mmc_ops.h | 1 -
drivers/mmc/host/dw_mmc.c | 48 --
include/linux/mmc/card.h | 2 ++
3 files changed
Addy Ke (2):
mmc: core: use card pointer as the first parameter of execute_tuning()
mmc: dw_mmc: wait until card ready if tuning fails
drivers/mmc/core/core.c | 2 +-
drivers/mmc/core/mmc_ops.h| 1 -
drivers/mmc/host/dw_mmc.c | 51
a
data transfer again if we got DRTO and EBE interrupt.
After this patch, all mmc_test cases can pass on RK3288-Pink2 board.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host
we have this problem, but we need it to fix this problem now.
And I will post a follow up change when we find the root cause.
Signed-off-by: Addy Ke
---
Changes in v2:
- fix some typo.
- remove extra timeout value (250ms).
- remove dw_mci_dto_start_monitor func.
- use "broken-dto" for
we have this problem, but we need it to fix this problem now.
And I will post a follow up change when we find the root cause.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- fix some typo.
- remove extra timeout value (250ms).
- remove dw_mci_dto_start_monitor func.
- use broken
we have this problem, but we need it to fix this problem now.
And I will post a follow up change when we find the root cause.
Signed-off-by: Addy Ke
---
Changes in v2:
- fix some typo.
- remove extra timeout value (250ms).
- remove dw_mci_dto_start_monitor func.
- use "broken-dto" for
we have this problem, but we need it to fix this problem now.
And I will post a follow up change when we find the root cause.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- fix some typo.
- remove extra timeout value (250ms).
- remove dw_mci_dto_start_monitor func.
- use broken
-review.googlesource.com/#/c/232774/
Signed-off-by: Addy Ke
---
Changes in v2:
- merged the patch that Doug submitted to chromium project
Changes in v3:
- merged the patch that Doug submitted to chromium to projectchange bindins
see: https://chromium-review.googlesource.com/#/c/232774/
Changes
-review.googlesource.com/#/c/232774/
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- merged the patch that Doug submitted to chromium project
Changes in v3:
- merged the patch that Doug submitted to chromium to projectchange bindins
see: https://chromium-review.googlesource.com
. see:
https://chromium-review.googlesource.com/#/c/232774/
Signed-off-by: Addy Ke
---
Changes in v2:
- merged the patch that Doug submitted to chromium project
Changes in v3:
- merged the patch that Doug submitted to chromium to projectchange bindins
see: https://chromium-review.googlesource.com
. see:
https://chromium-review.googlesource.com/#/c/232774/
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- merged the patch that Doug submitted to chromium project
Changes in v3:
- merged the patch that Doug submitted to chromium to projectchange bindins
see: https://chromium
idx = active = thrd->req_runnig = 0 -->
descdone = thrd->req[0] = NULL -->
list_add_tail(>rqd, >req_done); -->
got NULL pointer!!!
Signed-off-by: Addy Ke
---
drivers/dma/pl330.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/dma/pl330.c
callback are all called,
but step 10 and step 18 go wrong.
2) before commit dfac17:
idx = active = thrd-req_runnig = 0 --
descdone = thrd-req[0] = NULL --
list_add_tail(descdone-rqd, pl330-req_done); --
got NULL pointer!!!
Signed-off-by: Addy Ke addy...@rock
On 2014/12/8 10:59, Addy Ke wrote:
> high_ns calculated from the low division of CLKDIV register is the sum
> of actual measured high_ns and rise_ns. The rise time which related to
> external pull-up resistor can be up to the maximum rise time in I2C spec.
>
> In my test, if e
for signals from the device tree.
This allows us to more accurately calculate timings. see:
https://chromium-review.googlesource.com/#/c/232774/
Signed-off-by: Addy Ke
---
Changes in v2:
- merged the patch that Doug submitted to chromium
Changes in v3:
- merged the patch that Doug submitted
for signals from the device tree.
This allows us to more accurately calculate timings. see:
https://chromium-review.googlesource.com/#/c/232774/
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- merged the patch that Doug submitted to chromium
Changes in v3:
- merged the patch
On 2014/12/8 10:59, Addy Ke wrote:
high_ns calculated from the low division of CLKDIV register is the sum
of actual measured high_ns and rise_ns. The rise time which related to
external pull-up resistor can be up to the maximum rise time in I2C spec.
In my test, if external pull-up resistor
was based on this freequency point.
Signed-off-by: Addy Ke
---
arch/arm/boot/dts/rk3288.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index acb6a2f..9c35a1d 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm
was based on this freequency point.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
arch/arm/boot/dts/rk3288.dtsi | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index acb6a2f..9c35a1d 100644
--- a/arch/arm/boot/dts/rk3288
we find the root cause.
Signed-off-by: Addy Ke
---
Changes in v2:
- fix some typo.
- remove extra timeout value (250ms).
- remove dw_mci_dto_start_monitor func.
- use "broken-dto" for new quirk and change Subject for it.
Changes in v3:
- Remove dts for broken-dto, just add
for signals from the device tree.
This allows us to more accurately calculate timings. see:
https://chromium-review.googlesource.com/#/c/232774/
Signed-off-by: Addy Ke
---
Changes in v2:
- merged the patch that Doug submitted to chromium
Documentation/devicetree/bindings/i2c/i2c-rk3x.txt | 10
for signals from the device tree.
This allows us to more accurately calculate timings. see:
https://chromium-review.googlesource.com/#/c/232774/
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- merged the patch that Doug submitted to chromium
Documentation/devicetree/bindings
we find the root cause.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- fix some typo.
- remove extra timeout value (250ms).
- remove dw_mci_dto_start_monitor func.
- use broken-dto for new quirk and change Subject for it.
Changes in v3:
- Remove dts for broken-dto, just add
Hi,
On 2014/11/27 06:46, Doug Anderson wrote:
> Hi,
>
> On Tue, Nov 25, 2014 at 12:10 AM, Addy Ke wrote:
>> This patch add a new quirk to add a s/w timer to notify the driver
>> to terminate current transfer and report a data timeout to the core,
>> if DTO int
Hi,
On 2014/11/27 06:46, Doug Anderson wrote:
Hi,
On Tue, Nov 25, 2014 at 12:10 AM, Addy Ke addy...@rock-chips.com wrote:
This patch add a new quirk to add a s/w timer to notify the driver
to terminate current transfer and report a data timeout to the core,
if DTO interrupt does NOT come
that host should get DRTO and DTO interrupt.
But we really don't get any data-related interrupt in RK3X SoCs.
And driver can't get data transfer state, it can do nothing but wait for.
Signed-off-by: Addy Ke
---
- fix some typo.
- remove extra timeout value (250ms).
- remove dw_mci_dto_start_monitor
that host should get DRTO and DTO interrupt.
But we really don't get any data-related interrupt in RK3X SoCs.
And driver can't get data transfer state, it can do nothing but wait for.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
- fix some typo.
- remove extra timeout value (250ms).
- remove
Hi, Jaehoon
On 2014/11/19 13:56, addy ke wrote:
> Hi Jaehoon
>
> On 2014/11/19 09:22, Jaehoon Chung Wrote:
>> Hi, Addy.
>>
>> On 11/18/2014 09:32 AM, Addy wrote:
>>>
>>> On 2014年11月14日 21:18, Jaehoon Chung wrote:
>>>> Hi, Addy.
>>&g
Hi, Jaehoon
On 2014/11/19 13:56, addy ke wrote:
Hi Jaehoon
On 2014/11/19 09:22, Jaehoon Chung Wrote:
Hi, Addy.
On 11/18/2014 09:32 AM, Addy wrote:
On 2014年11月14日 21:18, Jaehoon Chung wrote:
Hi, Addy.
Did you use the DW_MCI_QUIRK_IDMAC_DTO?
I'm not sure, but i wonder if you get what
interrupts
>> come,
>> and interrupt handle function(dw_mci_interrupt) will not be called. So we
>> need a
>> timer to handle this case.
>>
>> So I think SDMMC_INT_DATA_OVER is not suitable for this case, and we need a
>> new
>> quirk.
>>
>
at next week.
Thanks for your efforts.
Best Regards,
Jaehoon Chung
On 11/14/2014 10:05 PM, Addy Ke wrote:
From: Addy addy...@rock-chips.com
This patch add a new quirk to notify the driver to teminate
current transfer and report a data timeout to the core,
if data over interrupt does
From: Addy
This patch add a new quirk to notify the driver to teminate
current transfer and report a data timeout to the core,
if data over interrupt does NOT come within the given time.
dw_mmc call mmc_request_done func to finish transfer depends on
data over interrupt. If data over interrupt
From: Addy addy...@rock-chips.com
This patch add a new quirk to notify the driver to teminate
current transfer and report a data timeout to the core,
if data over interrupt does NOT come within the given time.
dw_mmc call mmc_request_done func to finish transfer depends on
data over interrupt.
On 2014/11/13 02:04, Doug Anderson wrote:
> Ulf,
>
> On Tue, Nov 11, 2014 at 12:52 AM, Ulf Hansson wrote:
>> On 11 November 2014 05:02, Addy Ke wrote:
>>> SD2.0 cards need vqmmc and vmmc to be the same.
>>
>> No, that's not correct.
>>
>>
On 2014/11/13 02:04, Doug Anderson wrote:
Ulf,
On Tue, Nov 11, 2014 at 12:52 AM, Ulf Hansson ulf.hans...@linaro.org wrote:
On 11 November 2014 05:02, Addy Ke addy...@rock-chips.com wrote:
SD2.0 cards need vqmmc and vmmc to be the same.
No, that's not correct.
If I remember the spec
)
Signed-off-by: Addy Ke
---
drivers/mmc/host/dw_mmc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b4c3044..a8b70b5 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1163,8
)
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/mmc/host/dw_mmc.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index b4c3044..a8b70b5 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host
the actual measured high_ns is about 3900ns, which is less than 4000ns
(the minimum high_ns in I2C spec).
Signed-off-by: Addy Ke
---
drivers/i2c/busses/i2c-rk3x.c | 58 +++
1 file changed, 37 insertions(+), 21 deletions(-)
diff --git a/drivers/i2c/busses/i2c
the actual measured high_ns is about 3900ns, which is less than 4000ns
(the minimum high_ns in I2C spec).
Signed-off-by: Addy Ke addy...@rock-chips.com
---
drivers/i2c/busses/i2c-rk3x.c | 58 +++
1 file changed, 37 insertions(+), 21 deletions(-)
diff --git
The bit of sdio interrupt is 16 in designware implementation,
but it is 24 on Rockchip SoCs.This patch add sdio_id0 for the
number of slot0 in the SDIO interrupt registers.
Signed-off-by: Addy Ke
---
Changes in v2:
- rebase on http://git.linaro.org/git/people/ulf.hansson/mmc.git, next branch
The bit of sdio interrupt is 16 in designware implementation,
but it is 24 on Rockchip SoCs.This patch add sdio_id0 for the
number of slot0 in the SDIO interrupt registers.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- rebase on http://git.linaro.org/git/people/ulf.hansson
Hi, Jaehoo
On 2014/11/3 16:59, Jaehoon Chung wrote:
> Hi, Addy.
>
> On 11/03/2014 10:20 AM, Addy Ke wrote:
>> The bit of sdio interrupt is 16 in designware implementation,
>> but it is 24 on Rockchip SoCs.This patch add sdio_id0 for the
>> number of slot0 in t
Hi, Jaehoo
On 2014/11/3 16:59, Jaehoon Chung wrote:
Hi, Addy.
On 11/03/2014 10:20 AM, Addy Ke wrote:
The bit of sdio interrupt is 16 in designware implementation,
but it is 24 on Rockchip SoCs.This patch add sdio_id0 for the
number of slot0 in the SDIO interrupt registers.
Signed-off
The bit of sdio interrupt is 16 in designware implementation,
but it is 24 on Rockchip SoCs.This patch add sdio_id0 for the
number of slot0 in the SDIO interrupt registers.
Signed-off-by: Addy Ke
---
Changes in v2:
- rebase on http://git.linaro.org/git/people/ulf.hansson/mmc.git, next branch
On 2014/10/31 18:43, Heiko Stübner wrote:
> Am Freitag, 31. Oktober 2014, 11:50:09 schrieb Addy Ke:
>> The bit of sdio interrupt is 16 in designware implementation,
>> but it is 24 in RK3288. This patch add sdio_id0 for the number
>> of slot0 in the SDIO interrupt regist
On 2014/10/31 18:43, Heiko Stübner wrote:
Am Freitag, 31. Oktober 2014, 11:50:09 schrieb Addy Ke:
The bit of sdio interrupt is 16 in designware implementation,
but it is 24 in RK3288. This patch add sdio_id0 for the number
of slot0 in the SDIO interrupt registers, which can be set in
platform
The bit of sdio interrupt is 16 in designware implementation,
but it is 24 on Rockchip SoCs.This patch add sdio_id0 for the
number of slot0 in the SDIO interrupt registers.
Signed-off-by: Addy Ke addy...@rock-chips.com
---
Changes in v2:
- rebase on http://git.linaro.org/git/people/ulf.hansson
The bit of sdio interrupt is 16 in designware implementation,
but it is 24 in RK3288. This patch add sdio_id0 for the number
of slot0 in the SDIO interrupt registers, which can be set in
platform DT table, such as:
- rockchip,sdio-interrupt-slot0 = <8>;
Signed-off-by: Addy Ke
---
Changes
On 2014/10/30 19:17, Jaehoon Chung wrote:
> On 10/30/2014 08:11 PM, Ulf Hansson wrote:
>> On 30 October 2014 11:50, Addy Ke wrote:
>>> The bit of sdio interrupt is 16 in designware implementation,
>>> but it is 24 in RK3288. This patch add sdio_id0 for the numb
1 - 100 of 218 matches
Mail list logo
