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
> > --
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
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
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
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
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
> 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
Pierre,
are you comfortable with this ?
Philip
>From 85b200161edac97fc2817ad3f213795df99cd7e8 Mon Sep 17 00:00:00 2001
From: Philip Rakity
Date: Tue, 25 Jan 2011 16:04:42 -0800
Subject: [PATCH] sdhci: sdhci.c: Do not disable global interrupts while waiting
in set_ios
holding the spin_lock wi
On Feb 13, 2011, at 2:25 AM, Pierre Tardy wrote:
> On Sun, Feb 13, 2011 at 6:39 AM, Philip Rakity wrote:
>>
>> Pierre,
>>
>> I am preparing a patch to just diable to interrupt line to the SD controller
>> so global interrupts are not locked out.
> I think I already have seen previous version
On Sun, Feb 13, 2011 at 6:39 AM, Philip Rakity wrote:
>
> Pierre,
>
> I am preparing a patch to just diable to interrupt line to the SD controller
> so global interrupts are not locked out.
I think I already have seen previous version of that patch earlier. It
does not sound like a bad idea. Howe
13 matches
Mail list logo
