[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56534CFA.7070403@linaro.org>
Date: Mon, 23 Nov 2015 12:29:30 -0500
From: Jorge Ramirez-Ortiz <jorge.ramirez-ortiz@...aro.org>
To: Doug Anderson <dianders@...omium.org>
Cc: Jaehoon Chung <jh80.chung@...sung.com>,
Ulf Hansson <ulf.hansson@...aro.org>,
Alim Akhtar <alim.akhtar@...sung.com>,
Sonny Rao <sonnyrao@...omium.org>,
Andrew Bresticker <abrestic@...omium.org>,
Heiko Stübner <heiko@...ech.de>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>
Subject: Re: dw_mmc: HLE errors
On 11/23/2015 11:57 AM, Doug Anderson wrote:
> Jorge,
>
> On Mon, Nov 23, 2015 at 6:10 AM, Jorge Ramirez-Ortiz
> <jorge.ramirez-ortiz@...aro.org> wrote:
>> Doug/Jaehoon,
>>
>> Were there any follow ups to this thread [1] from March 30, 2015?
>> We are seeing HLE errors on 3.18 and we are trying to determine if a solution
>> was ever delivered.
>> On inspection, I can't find anything specific in recent kernels that address
>> this particular issue (was the actual root cause identified?)
>>
>> I put together a possible work-around that avoids the HLE storm from occurring
>> for this specific SoC [2].
>> However we'd rather not merge this -or any other similar fix- if there is a
>> generic solution already that we can pick up from mainline.
> Nothing landed that I'm aware of. Are you on SDIO, SD or eMMC?
> Trying to do UHS?
SD even without UHS (yet, that is coming now)
>
> I know that this patch mattered for me for UHS:
>
> 7c5209c315ea mmc: core: Increase delay for voltage to stabilize from
> 3.3V to 1.8V
>
>
> Also important for UHS (for at least some folks) were patches like:
>
> 9c85f37a2984 mmc: core: Add mmc_regulator_set_vqmmc()
>
> ...that attempted to get voltages more proper...
ack
>
>
> In the ChromeOS tree we did just land treating HLE errors as data and
> cmd errors <https://patchwork.kernel.org/patch/5978711/>. It's not
> wonderful but it's better than letting an interrupt go off forever...
Yes I did try this patch on 3.18 but it didn't seem to be enough for us.
Even though it would prevent the interrupt storm from flooding the kernel, once
the event triggered and the interrupt was handled no more card
insertions/ejections would be detected.
ok, thanks for the info!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists