Jaehoon / James
On Fri, Oct 18, 2013 at 2:51 AM, Jaehoon Chung wrote:
>> In this case it'd only be a space and code complexity thing I think. I
>> suppose in some cases the benefit of finer-grained locking is probably
>> pretty marginal, but there's a good case for it here. It might be
>> worth r
On 10/17/2013 05:23 AM, James Hogan wrote:
> Hi Doug,
>
> On 16 October 2013 17:43, Doug Anderson wrote:
>> On Wed, Oct 16, 2013 at 2:49 AM, James Hogan wrote:
We can't just use the standard host->lock since that lock is not irq
safe and mmc_signal_sdio_irq() (called from interrupt con
Hi Doug,
On 16 October 2013 17:43, Doug Anderson wrote:
> On Wed, Oct 16, 2013 at 2:49 AM, James Hogan wrote:
>>> We can't just use the standard host->lock since that lock is not irq
>>> safe and mmc_signal_sdio_irq() (called from interrupt context) calls
>>> dw_mci_enable_sdio_irq(). Add a new
James,
On Wed, Oct 16, 2013 at 2:49 AM, James Hogan wrote:
>> We can't just use the standard host->lock since that lock is not irq
>> safe and mmc_signal_sdio_irq() (called from interrupt context) calls
>> dw_mci_enable_sdio_irq(). Add a new irq-safe lock to protect INTMASK.
>>
>> An alternate s
Hi Doug.
Nice catch.
On 15/10/13 23:39, Doug Anderson wrote:
> We're running into cases where our enabling of the SDIO interrupt in
> dw_mmc doesn't actually take effect. Specifically, adding patch like
> this:
>
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -1076,6 +1076,9 @@ static void dw_mci_ena
We're running into cases where our enabling of the SDIO interrupt in
dw_mmc doesn't actually take effect. Specifically, adding patch like
this:
+++ b/drivers/mmc/host/dw_mmc.c
@@ -1076,6 +1076,9 @@ static void dw_mci_enable_sdio_irq(struct mmc_host *mmc,
int enb)
mci_writel(host, INTMAS
6 matches
Mail list logo
