On Feb 14, 2011, at 1:29 AM, Pierre Tardy wrote:
> On Mon, Feb 14, 2011 at 6:50 AM, Philip Rakity wrote:
>>
>> Pierre,
>>
>> are you comfortable with this ?
> The mmc_delay() looks hackish at the first sight. Looks like Pierre
> Ossman was the author, he must have his reasons.
>
> It looks li
On Feb 14, 2011, at 3:27 PM, Chris Ball wrote:
> Hi,
>
>>> Noticed that this patch ([PATCH 3/3] in "mmc: core: misc bug
>>> fixes") and [PATCH 1/4] in "mmc: sdhci: Dual Data Rate Support"
>>> do the same thing differently -- please followup to the one of
>>> them that's redundant mentioning that
On Mon, Feb 14, 2011 at 2:22 PM, Arnd Bergmann wrote:
>>
>> As I mentioned, I am checking with T right now on whether we can use
>> suggestion (1) or
>> suggestion (2) or if they need to be combined. The documentation we
>> got was open to interpretation and the patch created from that did
>> both
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() sequence. If it is
>> not defined then sdio card will be considered
>> "removable" and
Pierre,
The spin_lock may not be needed if the same thread cannot be re-entered.
That was the reason for the assumptions. Sorry about not being clear.
Philip
On Feb 14, 2011, at 10:41 AM, Tardy, Pierre wrote:
> Philip,
>>> And, more important, you will do cond_resched while holding you
>>> s
On Monday 14 February 2011 20:29:59 Andrei Warkentin wrote:
> On Sun, Feb 13, 2011 at 11:39 AM, Arnd Bergmann wrote:
>
> Ah sorry, I had to look that one up myself, I thought it was the local
> jargon associated with the problem space :-). Program/Erase cycle.
Ok, makes sense.
> >> So T suggeste
According to Zhangfei Gao -- android crashes when we are code to handle dual
data rate because of the mdelay of 5ms that
is needed for the voltage to become stable. (see my ddr patch)
I have never seen this problem with android.
The dual data rate code is in another patch; it adds another c
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() sequence. If it is
> not defined then sdio card will be considered
> "removable" and on resume mmc_sdio_init_card() will be always called.
>
> static int mmc_
On Sun, Feb 13, 2011 at 11:39 AM, Arnd Bergmann wrote:
> I don't think it needs to be boot-time, it can easily be run-time
> tuneable using sysfs, where you can configure it using an init script
> or some other logic from user space.
True, definitely expose the controls through sysfs.
>
> Yes.
Hi Chris,
On Sat, Feb 12, 2011 at 9:22 AM, Chris Ball wrote:
> Hi Dmitry,
>
> On Sat, Feb 12, 2011 at 12:33:33AM +, Dmitry Shmidt wrote:
>> Recently new check was added to core.c function mmc_rescan():
>> if (host->bus_ops && host->bus_ops->detect && !host->bus_dead
>> && mmc_card
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
> ---
No need to do assumptions, schedule
On Feb 14, 2011, at 1:29 AM, Pierre Tardy wrote:
> On Mon, Feb 14, 2011 at 6:50 AM, Philip Rakity wrote:
>>
>> Pierre,
>>
>> are you comfortable with this ?
> The mmc_delay() looks hackish at the first sight. Looks like Pierre
> Ossman was the author, he must have his reasons.
>
> It looks li
On Sun, 13 Feb 2011, Philip Rakity wrote:
>
> 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 | 1207
> ++-
> 1 files chang
The two patches that use this change are enclosed -- submitted to linux-mmc
mailing list.
MMP2 / PXA168 / PXA910 have private registers that allow us to fine grain
adjust the
SD clock internal delay and method of feedback. RESET_ALL clears the private
registers so they need resetting. The valu
I wonder if I can remove the locking (spin_lock). The disable and enable irq
should be enough.
Thoughts ..
Philip
On Feb 14, 2011, at 1:55 AM, Wolfram Sang wrote:
>
>> It looks like the mdelay are not in the fastpath, so why bother.
>
> On embedded systems, we had audio streaming or CAN
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:
> + cmd->resp[0] = readl(host->base + HW_SSP_SDRESP0);
> +
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 transfer.
>
> Signed-off-by: Shawn Guo
While trying, I got this lockdep-warning and
On Sun, Feb 13, 2011 at 10:56:22PM -0800, Philip Rakity wrote:
>
> Set timing for brownstone for SD/MMC cards to enable detection
> timing adjustments are needed when speed > 25MHz
> remove limitation on maximum speed of 25MHz
>
> Signed-off-by: Philip Rakity
> ---
> arch/arm/mach-mmp/brownston
> 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
>
> If unsure, say N.
>
> +config MMC_MXS
> + tristate "Freescale MXS Multimedia
On Monday 14 February 2011, Philip Rakity wrote:
> +
> + gpio_direction_output(poweron, 1);
> + mdelay (20);
> + gpio_direction_output(reset, 0);
> + mdelay (20);
> + gpio_direction_output(reset, 1);
> + gpio_free(reset);
> + gpio_free(poweron);
mdelay is
On 12/02/11 08:22, ext Chuanxiao Dong wrote:
max_discard_sectors value is UINT_MAX which means kernel block layer can pass
down unlimited sectors to MMC driver to erase. But erasing so many sectors may
delay some other important I/O requests. This is not preferred.
So use 'pref_erase' to set a s
On Monday 14 February 2011, Philip Rakity wrote:
> took old mmp2_defconfig --
> did make menuconfig
> changed to CPU_MMP2
> added brownstone as supported board
>
> Signed-off-by: Philip Rakity
You should not use full .config files as defconfig any more these days.
Please use 'make defconfig' as
On Monday 14 February 2011, Philip Rakity wrote:
> The following items are fixed:
>
> a) inconsistent behavior when board is selected and if
> menu item is reselected board has disappeard
>
> b) Ability to select options that will not build
> MMP2 and say PXA168
>
> The behavior maps wha
On Monday 14 February 2011, Dong, Chuanxiao wrote:
> When I do trim with a 32GB eMMC card in my platform, sometimes I can get the
> 10s
> timeout errors but sometimes not. I am not much clear about the "discarding
> partial
> AU will take a lot longer". If this action is hide for driver, then I t
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-slot-power: %d\n", ret);
> + return;
> + }
> +
> + re
> It looks like the mdelay are not in the fastpath, so why bother.
On embedded systems, we had audio streaming or CAN communication or similar
running in parallel. Currently, those mdelays (there are a couple, sadly)
produce significant latencies, e.g. when inserting/removing a card. The latter
g
On Mon, Feb 14, 2011 at 6:50 AM, Philip Rakity wrote:
>
> Pierre,
>
> are you comfortable with this ?
The mmc_delay() looks hackish at the first sight. Looks like Pierre
Ossman was the author, he must have his reasons.
It looks like the mdelay are not in the fastpath, so why bother.
And, more im
Hi Ohad,
I will modify the patch accordingly.
Regards,
Pandu.
- Original Message -
From: "Ohad Ben-Cohen"
To: "Mallireddy, Panduranga"
Cc: "Coelho, Luciano" ; ;
; ; "Gabay, Benzy"
; "Gurumath, Pradeep" ; "Mahaveer,
Vishal" ; "Boudet, Xavier" ; "Jain, Naveen"
; "Savoy, Pavan" ; "
28 matches
Mail list logo
