Hi Wolfram,
> -Original Message-
> From: Wolfram Sang [mailto:w.s...@pengutronix.de]
> Sent: Tuesday, February 15, 2011 3:46 PM
> To: Nath, Arindam
> Cc: c...@laptop.org; linux-mmc@vger.kernel.org; Su, Henry; Lu, Aaron;
> anath@gmail.com
> Subject: Re: [PATCH 02/12] mmc: sd: add suppor
If we need some quirks, maybe add quirks in future
But now, quirks value set to integer..later we should be confused..
So i think that need bit-shift control.
And If we need not any quirks, we didn't set anything..
(Need not DW_MCI_QUIRK_NONE)
Signed-off-by: Jaehoon Chung
---
include/linux/mmc/
On Tue, Feb 15 2011, Russell King - ARM Linux wrote:
> This patch is for RFC only; it needs splitting up somewhat. However, I
> wanted to get it out there for some comment.
Just for kicks, I applied this and ran it on an MSM target (8x50). It
seems to cause lots of:
mmc0: Data timeout
mmc0
This patch is for RFC only; it needs splitting up somewhat. However, I
wanted to get it out there for some comment.
The patch basically improves all round the error handling with MMC block
transfers. I've considered several scenarios, from lost or bad CRCs on
the initial commands (both causing n
V2 Changes
==
Delete spin_lock as not needed. disable/enable irq
should be enough to interlock bewteen the isr and
the main thread.
V1
===
holding the spin_lock with all interrupts disabled
is not good form when doing mdelay.
set_ios calls routines that need to delay for power to
stabali
Use mfd_data for passing information from mfd drivers to mfd
clients. The mfd_cell's driver_data field is being phased out.
Clients that were using driver_data now access .mfd_data
via mfd_get_data(). This changes tmio-mmc only; mfd drivers with
other cells are not modified.
Signed-off-by: Andr
On 16-02-2011 0:55, Philip Rakity wrote:
V2
==
Use make savedefconfigconfig to produce reduced size defconfig
per suggestion of Nico Pitre.
V1
==
The log of the patch changes should go under the --- tear line.
took old pxa910_defconfig --
did make menuconfig
changed to CPU_PXA910
Si
V2
==
Use make savedefconfigconfig to produce reduced size defconfig
per suggestion of Nico Pitre.
V1
==
took old pxa910_defconfig --
did make menuconfig
changed to CPU_PXA910
Signed-off-by: Philip Rakity
---
arch/arm/configs/pxa910_defconfig |6 +-
1 files changed, 1 insertions(+), 5
V2
==
Use make savedefconfigconfig to produce reduced size defconfig
per suggestion of Nico Pitre.
V1
took old pxa168_defconfig --
did make menuconfig
Signed-off-by: Philip Rakity
---
arch/arm/configs/pxa168_defconfig |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/a
V2
==
Use make savedefconfigconfig to produce reduced size defconfig
per suggestion of Nico Pitre.
V1
==
took old mmp2_defconfig --
did make menuconfig
changed to CPU_MMP2
added brownstone as supported board
Signed-off-by: Philip Rakity
---
arch/arm/configs/mmp2_defconfig |7 ++-
1 fil
On Tue, 15 Feb 2011, Arindam Nath wrote:
> @@ -1340,11 +1342,76 @@ out:
> spin_unlock_irqrestore(&host->lock, flags);
> }
>
> +static int sdhci_start_signal_voltage_switch(struct mmc_host *mmc)
> +{
> + struct sdhci_host *host;
> + u8 pwr;
> + u16 clk, ctrl;
> + u32 presen
On Tue, 15 Feb 2011, Arindam Nath wrote:
> Host Controller v3.00 and later support Auto CMD23 in the Transfer
> Mode register. Since Auto CMD23 can be used with or without DMA,
> and if used with DMA, it should _only_ be ADMA, we check against
> SDHCI_USE_SDMA not being set. This flag is reset whe
Hi Arindam,
On Tue, Feb 15, 2011 at 03:04:58PM +0530, Arindam Nath wrote:
> The patches below add support for Host Controller v3.00 as per the
> spec v3.00. It also adds support for UHS-I cards as per Physical
> Layer Specification v3.01.
Thanks for the patchset! It might take us some time to re
On 02/15/2011 10:08 AM, Dmitry Shmidt wrote:
> mmc: core: Allow sdio operations in other thread during sdio_add_func()
>
> This is important when wlan driver is doing sdio operations from another
> thread during initialization.
> This behavior was introduced as a side-effect in patch
> 807e8e40673d
On Tue, Feb 15, 2011 at 11:26 AM, Andy Ross wrote:
> On 02/15/2011 10:08 AM, Dmitry Shmidt wrote:
>> mmc: core: Allow sdio operations in other thread during sdio_add_func()
>>
>> This is important when wlan driver is doing sdio operations from another
>> thread during initialization.
>> This behav
[Cc += Andy]
On Fri, Feb 11, 2011 at 6:34 PM, Dmitry Shmidt wrote:
> On Fri, Feb 11, 2011 at 4:25 PM, Dmitry Shmidt wrote:
>> commit 9cb71a1eb86a2acf0762d31af633984cf9e24d32
>> Author: Dmitry Shmidt
>> Date: Fri Feb 11 16:10:33 2011 -0800
>>
>> mmc: core: Allow sdio operations in other thr
Hi,
[Cc += Ohad]
On Mon, Feb 14, 2011 at 1:54 PM, Dmitry Shmidt wrote:
> Hi Chris,
>
> On Mon, Feb 14, 2011 at 11:40 AM, Chris Ball wrote:
>> Hi Dmitry,
>>
>> [Cc += Nico]
>>
>> On Mon, Feb 14, 2011 at 11:04:13AM -0800, Dmitry Shmidt wrote:
>>> MMC_UNSAFE_RESUME is affecting mmc_sdio_resume() se
On Tue, Feb 15, 2011 at 06:29:48PM +0100, Wolfram Sang wrote:
> On Tue, Feb 15, 2011 at 05:19:17PM +, Russell King - ARM Linux wrote:
> > On Tue, Feb 15, 2011 at 06:13:41PM +0100, Wolfram Sang wrote:
> > > MMC fails for me (note: the card works fine with an mx35-based board)
> > >
> > > mmc0
On Tue, Feb 15, 2011 at 05:19:17PM +, Russell King - ARM Linux wrote:
> On Tue, Feb 15, 2011 at 06:13:41PM +0100, Wolfram Sang wrote:
> >
> > > Ah, yes. I can also see the problem here after turning on
> > > DEBUG_SPINLOCK.
> >
> > Ah, okay. After turning it off, it works a lot better :)
>
On Tue, Feb 15, 2011 at 06:13:41PM +0100, Wolfram Sang wrote:
>
> > Ah, yes. I can also see the problem here after turning on
> > DEBUG_SPINLOCK.
>
> Ah, okay. After turning it off, it works a lot better :)
That doesn't mean the problem is fixed. The spinlock debugging is there
to find broken
On Monday 14 February 2011, Andrei Warkentin wrote:
> > There are multiple ways how this could be implemented:
> >
> > 1. Have one exception cache for all "special" blocks. This would normally
> > be for FAT32 subdirectory updates, which always write to the same
> > few blocks. This means you c
> Ah, yes. I can also see the problem here after turning on
> DEBUG_SPINLOCK.
Ah, okay. After turning it off, it works a lot better :)
SD seems to work:
mmc0: new high speed SD card at address b368
mmcblk0: mmc0:b368 NCard 1.86 GiB
mmcblk0: p1
mmc0: card b368
On Mon, Feb 14, 2011 at 11:26:46AM +0100, Wolfram Sang wrote:
> Shawn,
>
> > +/* mmc */
> > +static void __init mx28evk_mmc_slot_poweron(int gpio)
> > +{
> > + int ret;
> > +
> > + ret = gpio_request(gpio, "mmc-slot-power");
> > + if (ret) {
> > + pr_err("Failed to request gpio mmc
Hi Wolfram,
On Mon, Feb 14, 2011 at 05:59:58PM +0100, Wolfram Sang wrote:
> On Mon, Feb 14, 2011 at 10:32:20AM +0800, Shawn Guo wrote:
> > This adds the mmc host driver for Freescale MXS-based SoC i.MX23/28.
> > The driver calls into mxs-dma via generic dmaengine api for both pio
> > and data tran
On Mon, Feb 14, 2011 at 04:59:59PM +, Russell King - ARM Linux wrote:
> On Mon, Feb 14, 2011 at 10:32:20AM +0800, Shawn Guo wrote:
> > + switch (mmc_resp_type(cmd)) {
> > + case MMC_RSP_NONE:
> > + break;
> > + case MMC_RSP_R1:
> > + case MMC_RSP_R1B:
> > + case MMC_RSP_R3:
On Wed, Feb 16, 2011 at 06:03:12AM +0800, Shawn Guo wrote:
> On Mon, Feb 14, 2011 at 04:59:59PM +, Russell King - ARM Linux wrote:
> > You really should be testing for MMC_RSP_PRESENT and MMC_RSP_136
> > here. The response types are made up of a bitfield which allows
> > you to detect what's r
Hi Wolfram,
On Mon, Feb 14, 2011 at 04:39:52PM +0100, Wolfram Sang wrote:
> > diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig
> > index afe8c6f..42a9e21 100644
> > --- a/drivers/mmc/host/Kconfig
> > +++ b/drivers/mmc/host/Kconfig
> > @@ -319,6 +319,15 @@ config MMC_MXC
> >
> >
On Sun, Feb 13, 2011 at 11:35:54PM +0100, Arnd Bergmann wrote:
> On Sunday 13 February 2011, Chris Ball wrote:
> > On Mon, Feb 14, 2011 at 10:32:20AM +0800, Shawn Guo wrote:
> > > This adds the mmc host driver for Freescale MXS-based SoC i.MX23/28.
> > > The driver calls into mxs-dma via generic dm
Hi Chris,
On Sun, Feb 13, 2011 at 07:26:09PM +, Chris Ball wrote:
> Hi Shawn,
>
> On Mon, Feb 14, 2011 at 10:32:20AM +0800, Shawn Guo wrote:
> > This adds the mmc host driver for Freescale MXS-based SoC i.MX23/28.
> > The driver calls into mxs-dma via generic dmaengine api for both pio
> > an
On Tue, Feb 15, 2011 at 03:05:00PM +0530, Arindam Nath wrote:
> Host Controller v3.00 adds another Capabilities register. We can
> directly read this register without any version checking since the
> new register bits will be considred as reserved in older controllers,
> and will be read as 0.
I
Host Controller v3.00 can support retuning modes 1,2 or 3 depending on
the bits 46-47 of the Capabilities register. Also, the timer count for
retuning is indicated by bits 40-43 of the same register. We initialize
timer_list for retuning after successfull UHS-I initialization. Since
retuning mode 1
Host Controller v3.00 supports programmable clock mode as an optional
feature. The support for this mode is indicated by non-zero value in
bits 48-55 of the Capabilities register. If supported, the actual
value of Clock Multiplier is one more than the value provided in the
bit fields. We only set C
According to the Host Controller spec v3.00, setting Preset Value Enable
in the Host Control2 register lets SDCLK Frequency Select, Clock Generator
Select and Driver Strength Select to be set automatically by the Host
Controller based on the UHS-I mode set. This patch enables this feature. We
also
This patch adds support for setting driver strength during UHS-I
initialization prcedure. Since UHS-I cards set S18A (bit 24) in
response to ACMD41, we use this as a base for UHS-I initialization.
We modify the parameter list of mmc_sd_get_cid() so that we can save
the ROCR from ACMD41 to check whe
Host Controller needs tuning during initialization to operate SDR50
and SDR104 UHS-I cards. Whether SDR50 mode actually needs tuning is
indicated by bit 45 of the Host Controller Capabilities register.
A new command CMD19 has been defined in the Physical Layer spec v3.01
to request the card to send
Since only UHS-I cards respond with S18A set in response to ACMD41,
we set the card as ultra-high-speed after successfull initialization.
We can have SDHC or SDXC UHS-I cards, so we need to decide based on
C_SIZE field of CSDv2.0 register. According to Physical Layer spec v3.01,
the minimum value o
We decide on the current limit to be set for the card based on the
Capability of Host Controller to provide current at 1.8V signalling,
and the maximum current limit of the card as indicated by CMD6 mode 0.
We then set the current limit for the card using CMD6 mode 1.
Signed-off-by: Arindam Nath
This patch adds support for setting UHS-I bus speed mode during UHS-I
initialization procedure. Since both the host and card can support
more than one bus speed, we select the highest speed based on both of
their capabilities. First we set the bus speed mode for the card using
CMD6 mode 1, and then
SD cards which conform to Physical Layer Spec v3.01 can support
additional Bus Speed Modes, Driver Strength, and Current Limit
other than the default values. We use CMD6 mode 0 to read these
additional card functions. The values read here will be used during
UHS-I initialization steps.
Signed-off-
As per Host Controller spec v3.00, we reset SDCLK before setting
High Speed Enable, and then set it back to avoid generating clock
gliches.
Signed-off-by: Arindam Nath
---
drivers/mmc/host/sdhci.c | 25 ++---
1 files changed, 22 insertions(+), 3 deletions(-)
diff --git a/d
Host Controller v3.00 adds another Capabilities register. We can
directly read this register without any version checking since the
new register bits will be considred as reserved in older controllers,
and will be read as 0. Apart from other things, this new register
indicates whether the Host Cont
Host Controller v3.00 and later support Auto CMD23 in the Transfer
Mode register. Since Auto CMD23 can be used with or without DMA,
and if used with DMA, it should _only_ be ADMA, we check against
SDHCI_USE_SDMA not being set. This flag is reset when SDHCI_USE_ADMA
is set.
A new definition for SDH
The patches below add support for Host Controller v3.00 as per the
spec v3.00. It also adds support for UHS-I cards as per Physical
Layer Specification v3.01.
Thanks for review.
Regards,
Arindam
Arindam Nath (12):
[PATCH 01/12] mmc: sdhci: add support for auto CMD23
[PATCH 02/12] mmc: sd: ad
On Mon, Feb 14, 2011 at 09:27:52AM -0800, Philip Rakity wrote:
>
> I wonder if I can remove the locking (spin_lock). The disable and enable irq
> should be enough.
I discussed this shortly with Sascha yesterday and we agree the core serializes
requests to the host (by means of mmc_claim_host
On Mon, Feb 14, 2011 at 06:41:47PM +, Tardy, Pierre wrote:
> Philip,
> > > And, more important, you will do cond_resched while holding you
> > > spinlock, which is *bad*.
> > > What if the mmc stack will call you again from another thread? deadlock...
>
> > Assumptions -- Please Confirm
> > --
From: Kishore Kadiyala
OMAP4 supports up to 5 MMC controllers, but only 3 of these were
initialized. MMC5 is used by wl12xx chip. So initialize MMC4 and MMC5.
Signed-off-by: Kishore Kadiyala
Signed-off-by: Panduranga Mallireddy
---
arch/arm/mach-omap2/hsmmc.c |5 +
drivers/mmc/host/
Fixes from V1:
1. Removing the pull up of WLAN IRQ line, since it is always held up by wl127x
device.
Adding support for WLAN on Panda board using wl12xx and mac80211 drivers
Patches were tested on Panda board.
These patches add software control for emulating card detect events,
add board confi
Add MMC5 support on PANDA, which has the wl1271 device hardwired to.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Based on the patch for mmc3/wl1271 device support for zoom by Ohad
Ben-Cohen
Signed-off-by
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Based on the patch for zoom by Ohad Ben-Cohen
Signed-off-by: Panduranga Mallireddy
---
arch/arm/mach-omap2/board-omap4panda.c | 34
1 files changed, 34 insertions(+), 0 deleti
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc5 (fifth mmc controller) on the PANDA.
Based on the wlan board muxing for zoom3 by Ohad Ben-Cohen
Signed-off-by: Panduranga Mallireddy
---
arch/arm/mach-omap2/board-omap4panda.c | 13 +
1 files changed, 13 in
Power to the wl12xx wlan device is controlled by a fixed regulator.
Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE.
Signed-off-by: Panduranga Mallireddy
---
arch/arm/mach-omap2/Kconfig |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2
51 matches
Mail list logo
