e
non-removable device and boot fast.
Signed-off-by: Heiko Schocher
---
Dirk Behme tried to bring this in, last mail I found:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
where Dirk worked in Arnds suggestion to use the
"/aliases" device node"
The last a
On 26.11.2013 22:22, Chris Ball wrote:
Hi Dirk,
On Fri, Nov 01 2013, Dirk Behme wrote:
On 16.07.2013 09:38, Shawn Guo wrote:
Hi Dirk,
On Tue, Jul 16, 2013 at 08:36:11AM +0200, Dirk Behme wrote:
In case of SDHCI_TIMEOUT_CONTROL write only 4 bits and not the
whole byte to avoid touching other
On 16.07.2013 09:38, Shawn Guo wrote:
Hi Dirk,
On Tue, Jul 16, 2013 at 08:36:11AM +0200, Dirk Behme wrote:
In case of SDHCI_TIMEOUT_CONTROL write only 4 bits and not the
whole byte to avoid touching other unrelated bits in the i.MX6
SYS_CTRL register. E.g. IPP_RST_N shouldn't be to
Hi Fabio,
Am 18.09.2013 02:06, schrieb Fabio Estevam:
Hi Dirk,
On Tue, Sep 17, 2013 at 3:04 PM, Fabio Estevam wrote:
Hi Dirk,
I have adapted your patch at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
and tested it on 3.12-rc1 on a mx6qsabresd board.
Do you h
Am 20.09.2013 19:03, schrieb Stephen Warren:
On 09/20/2013 10:37 AM, Dirk Behme wrote:
Am 20.09.2013 18:05, schrieb Stephen Warren:
On 09/18/2013 11:22 PM, Dirk Behme wrote:
...
If you have an embedded system were you just care a little about boot
time you don't want to do anything l
Am 20.09.2013 18:05, schrieb Stephen Warren:
On 09/18/2013 11:22 PM, Dirk Behme wrote:
...
If you have an embedded system were you just care a little about boot
time you don't want to do anything like U-Boot's "part uuid" every time
you boot. Or even worse, you just have
Am 18.09.2013 19:13, schrieb Stephen Warren:
On 09/18/2013 11:01 AM, Dirk Behme wrote:
Am 18.09.2013 17:17, schrieb Stephen Warren:
On 09/17/2013 12:04 PM, Fabio Estevam wrote:
Hi Dirk,
I have adapted your patch at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
Am 18.09.2013 17:17, schrieb Stephen Warren:
On 09/17/2013 12:04 PM, Fabio Estevam wrote:
Hi Dirk,
I have adapted your patch at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
and tested it on 3.12-rc1 on a mx6qsabresd board.
Do you have plans to submit it? Maybe
Hi Fabio,
Am 17.09.2013 20:04, schrieb Fabio Estevam:
Hi Dirk,
I have adapted your patch at:
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-July/111022.html
and tested it on 3.12-rc1 on a mx6qsabresd board.
Do you have plans to submit it? Maybe as a RFC?
It solves the mmcblkX ord
commands afterwards use the then (wrong)
card->ext_csd.part_config. Resulting in an undo of the initial mmc bootpart
enable.
Fix this by updating the ext_csd in case of an EXT_CSD update ioctl.
Signed-off-by: Dirk Behme
---
Notes:
This fixes the issue discussed in
http://marc.info/?l=linux-m
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_u
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
In case of SDHCI_TIMEOUT_CONTROL write only 4 bits and not the
whole byte to avoid touching other unrelated bits in the i.MX6
SYS_CTRL register. E.g. IPP_RST_N shouldn't be touched accidently.
Signed-off-by: Dirk Behme
---
drivers/mmc/host/sdhci-esdhc-imx.c | 12
1 file change
On 02.06.2013 08:38, Oded Gabbay wrote:
This patch adds support of recognizing hard-wired (permanent) cards
to Freescale's SDHC host driver. This is done by adding the option
"fsl,card-wired" to the SDHC device-tree entry. Detection of this
option is done in the probe function. Update documentati
Using some recent Hynix eMMC devices [1] on our Freescale i.MX6 boards
we get harmless (?), but annoying access timeouts accessing the RPMB
partition:
mmcblk1rpmb: error -110 transferring data, sector 0, nr 32, cmd response
0x900, card status 0xb00
mmcblk1rpmb: retrying using single block r
|8 +-
drivers/mmc/host/sdhci.h |2 +-
include/linux/platform_data/mmc-esdhc-imx.h |1 +
9 files changed, 101 insertions(+), 31 deletions(-)
Whole series:
Tested-by: Dirk Behme
Tested on i.MX6.
Thanks
Dirk
--
To unsubscribe from this list
Tested-by: Dirk Behme
Tested on i.MX6.
Thanks
Dirk
---
drivers/mmc/host/sdhci-esdhc-imx.c | 40 ++--
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc-imx.c
b/drivers/mmc/host/sdhci-esdhc-imx.c
index 322eabf
On 15.01.2013 16:36, Shawn Guo wrote:
SDHCI_CTRL_D3CD is not a standard SDHCI_HOST_CONTROL, so there is no
need to check it in SDHCI_HOST_CONTROL write at all. Remove it.
Signed-off-by: Shawn Guo
Tested-by: Dirk Behme
Tested on i.MX6.
Thanks
Dirk
---
drivers/mmc/host/sdhci-esdhc
Hi Chris,
On 06.08.2012 17:31, Chris Ball wrote:
Hi,
On Mon, Aug 06 2012, Dirk Behme wrote:
On embedded devices, often there is a combination of removable mmc
devices (e.g. MMC/SD cards) and hard wired ones (e.g. eMMC).
Depending on the hardware configuration, the 'mmcblkN' node mi
e has a long history. One prominent one is e.g. from the
Maemo based Nokia N810 device:
https://bugs.maemo.org/show_bug.cgi?id=2747
Signed-off-by: Dirk Behme
CC: Jassi Brar
CC: Chris Ball
---
drivers/mmc/card/block.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/dri
With the previous patch "mmc: block: mmcblkN: use slot index instead of
dynamic name index" name_idx is not needed any more.
Signed-off-by: Dirk Behme
CC: Jassi Brar
CC: Chris Ball
---
drivers/mmc/card/block.c | 16
1 files changed, 0 insertions(+), 16 deletion
On 20.07.2012 13:56, Jassi Brar wrote:
On 20 July 2012 17:00, Dirk Behme wrote:
On 19.07.2012 22:45, Jassi Brar wrote:
This problem can occur on many devices with embedded MMC and removable
SD,
e.g. smart phones. So I think we should find an solution to define MMC
scan
order or device
On 19.07.2012 15:13, Arnd Bergmann wrote:
On Wednesday 18 July 2012, Dirk Behme wrote:
Any idea how we could influence the initialization order of the mmc
block devices using a DT based kernel? Ensuring that the internal, hard
wired mmc card is always mapped to mmcblk0?
I think the best
On 19.07.2012 22:45, Jassi Brar wrote:
On 18 July 2012 19:41, Knut Wohlrab wrote:
On 07/18/2012 03:47 PM, Jassi Brar wrote:
On 18 July 2012 15:19, Knut Wohlrab wrote:
If a SD card is inserted at boot time, its "mmcblk0", the embedded
MMC (eMMC) device "mmcblk1". This makes it difficult to
Similar to [1] we have a device which has two mmc block devices
connected: One external removable and a second internal hard wired one.
Depending on the availability of the external removable mmc card at boot
time, the internal hard wired device becomes mmcblk1 (external mmc card
available ==
From: RichardZhu
Some SD cards insertions will cause a glitch on SD dat1
which is also a card interrupt signal. Thus the wrongly
generated card interrupt will make system panic because
there's no registered sdio interrupt handler.
This patch fixes this issue.
Note: This is a workaround for i.MX6
From: RichardZhu
Some SD cards insertions will cause a glitch on SD dat1
which is also a card interrupt signal. Thus the wrongly
generated card interrupt will make system panic because
there's no registered sdio interrupt handler.
This patch fixes this issue.
Note: This is a workaround for i.MX6
We need the following 4 patches to get SDHCI working on the i.MX6.
The first two patches add 8 bit and 1.8V support. Patches 3 + 4 are
workarounds for i.MX6 1.0 silicon hardware issues.
These patches are tested on the i.MX6 SabreLite board with kernel
3.4-rc6.
Please note that I'm not the author
From: RichardZhu
On i.MX6, if the TC interrupt bit is set but the DMA interrupt bit is cleared,
read the status register again in case the DMA interrupt will come in next
time cycle.
Note: This is a workaround for i.MX6 version 1.0 silicon. It's fixed in
hardware in
version 1.1 silicon.
From: RichardZhu
Enable 8 bit MMC mode according to mmc stack.
Signed-off-by: RichardZhu
Signed-off-by: Philipp Ahmann
---
drivers/mmc/host/sdhci-esdhc-imx.c | 33 -
1 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/host/sdhci-esdhc-
From: Eric Miao
This fix is due to 1.8V not supported from board design, yet the SDHCI
controller capabilities do not reflect this, and the existing SD core driver
is assuming 1.8V by checking MMC_CAP_UHS_* bits only.
Signed-off-by: Eric Miao
Signed-off-by: Philipp Ahmann
---
arch/arm/plat-mx
On 21.12.2009 17:46, Mike Rapoport wrote:
Hi,
Phaneendra Kumar Alapati wrote:
This patch adds SDIO IRQ support for OMAP35xx. Tested on OMAP3530EVM
with Marvell 88W8686 card and below are the observed throughput results
(ttcp utility): 13Mbps (Downlink), 10.5 Mbps(Uplink)
Signed-off-by: Phaneen
:
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Dirk Behme
Sent: Monday, October 19, 2009 1:17 PM
To: linux-o...@vger.kernel.org
Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Richard'; linux-
m...@vger.kernel.org; &#x
Madhusudhan wrote:
-Original Message-
From: linux-mmc-ow...@vger.kernel.org [mailto:linux-mmc-
ow...@vger.kernel.org] On Behalf Of Dirk Behme
Sent: Monday, October 19, 2009 1:17 PM
To: linux-o...@vger.kernel.org
Cc: Madhusudhan; 'John Rigby'; 'Woodruff, Ric
Rigby [mailto:jcri...@gmail.com]
*Sent:* Sunday, October 18, 2009 7:24 PM
*To:* Woodruff, Richard
*Cc:* Dirk Behme; Chikkature Rajashekar, Madhusudhan;
linux-mmc@vger.kernel.org; linux-o...@vger.kernel.org; Steve Sakoman
*Subject:* Re: MMC_CAP_SDIO_IRQ for omap 3430
Ok I was going to ask where you
[mailto:jcri...@gmail.com]
Sent: Sunday, October 18, 2009 7:24 PM
To: Woodruff, Richard
Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan;
linux-mmc@vger.kernel.org; linux-o...@vger.kernel.org; Steve Sakoman
Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430
Ok I was going to ask where you found that
18, 2009 7:24 PM
To: Woodruff, Richard
Cc: Dirk Behme; Chikkature Rajashekar, Madhusudhan;
linux-mmc@vger.kernel.org; linux-o...@vger.kernel.org; Steve Sakoman
Subject: Re: MMC_CAP_SDIO_IRQ for omap 3430
Ok I was going to ask where you found that but I just rechecked the TRM and
there it is in
Woodruff, Richard wrote:
From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-
ow...@vger.kernel.org] On Behalf Of Dirk Behme
Sent: Sunday, October 18, 2009 11:45 AM
It would be funny if the TRM was wrong and the CIRQ bit is really
cleared by writing 1 to it. I'll try that.
A
don't have a function calling order issue)?
- your HW design has a pull up on DAT1 line (as required by the SD physical
spec)?
Best regards
Dirk
On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan wrote:
-----Original Message-
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent:
Many thanks and best regards
Dirk
On Sat, Oct 17, 2009 at 12:30 AM, Dirk Behme wrote:
John Rigby wrote:
It appears to never get cleared in the status register.
In the OMAP status register, correct? (just to get the correct
understanding)
I added some printks to sdio_irq.c to print the pe
n calling order
issue)?
- your HW design has a pull up on DAT1 line (as required by the SD
physical spec)?
Best regards
Dirk
On Fri, Oct 16, 2009 at 3:14 PM, Madhusudhan wrote:
-Original Message-----
From: Dirk Behme [mailto:dirk.be...@googlemail.com]
Sent: Friday, October 16,
Madhusudhan Chikkature wrote:
Hi Dirk,
I am inlining the patch so that it helps review.
...
@@ -1165,8 +1178,15 @@ static void omap_hsmmc_set_ios(struct mm
break;
case MMC_BUS_WIDTH_4:
OMAP_HSMMC_WRITE(host->base, CON, con & ~DW8);
- OMAP_H
42 matches
Mail list logo
