[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPDyKFps4GbHYA7LkVXhhXyG_wUxH9U-2giap2Y1Qdk2ssfmWg@mail.gmail.com>
Date: Fri, 15 Nov 2019 11:38:12 +0100
From: Ulf Hansson <ulf.hansson@...aro.org>
To: Wolfram Sang <wsa@...-dreams.de>
Cc: Eugeniu Rosca <erosca@...adit-jv.com>,
Wolfram Sang <wsa+renesas@...g-engineering.com>,
Yoshihiro Shimoda <yoshihiro.shimoda.uh@...esas.com>,
Niklas Söderlund <niklas.soderlund@...natech.se>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Simon Horman <horms+renesas@...ge.net.au>,
"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux-Renesas <linux-renesas-soc@...r.kernel.org>,
Eugeniu Rosca <roscaeugeniu@...il.com>,
Harish Jenny K N <harish_kandiga@...tor.com>,
Andrew Gabbasov <andrew_gabbasov@...tor.com>
Subject: Re: [PATCH] mmc: renesas_sdhi_internal_dmac: Add MMC_CAP_ERASE to
Gen3 SoCs
On Fri, 15 Nov 2019 at 11:12, Wolfram Sang <wsa@...-dreams.de> wrote:
>
>
> > I think using a workqueue for scheduling a reset work with a timeout
> > of 5 s, as in your case.
>
> Sorry, I didn't get it. You think what exactly? Is it good / bad / ok
> for now / ok in general?
Sorry.
It's good for now!
If/when you start implementing support for HW busy detection, then you
need to adjust to the timeout value according to cmd->busy_timeout
from the core.
Kind regards
Uffe
Powered by blists - more mailing lists