[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=XkkKRJN+Vv6+nf8EjXoCuO-0MG923v-0HKPMYg=mdZww@mail.gmail.com>
Date: Mon, 13 May 2019 13:21:23 -0700
From: Doug Anderson <dianders@...omium.org>
To: Mark Brown <broonie@...nel.org>
Cc: Benson Leung <bleung@...omium.org>,
Enric Balletbo i Serra <enric.balletbo@...labora.com>,
"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
Nicolas Boichat <drinkcat@...omium.org>,
Guenter Roeck <groeck@...omium.org>,
Brian Norris <briannorris@...omium.org>,
Matthias Kaehlcke <mka@...omium.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 4/4] Revert "platform/chrome: cros_ec_spi: Transfer
messages at high priority"
Hi,
On Mon, May 13, 2019 at 9:47 AM, Mark Brown <broonie@...nel.org> wrote:
> On Mon, May 13, 2019 at 09:03:28AM -0700, Doug Anderson wrote:
> > On Mon, May 13, 2019 at 9:02 AM Mark Brown <broonie@...nel.org> wrote:
>
> > > I'm not saying the other changes aren't helping, I'm saying that it's
> > > not clear that this revert is improving things.
>
> > If I add a call to force the pumping to happen on the SPI thread then
> > the commit I'm reverting here is useless though, isn't it?
>
> Well, I'm not convinced that that change is ideal anyway and it does
> leave you vulnerable to further changes in the SPI core pushing things
> out to calling context which feels like it isn't going to be helping
> robustness.
OK. Here's my plan: in v2 I've still included this revert and you can
see how things look. If you hate it as much as you think you will
then let me know and I'll send a v3 that avoids to forcing and re-adds
the realtime thread to cros_ec.
One note just so you're aware: For my particular device I'm not nearly
as concerned with latency / throughput as I am concerned with
transfers not getting interrupted once started. I've added this
explicitly in the commit message now, too. :-)
-Doug
Powered by blists - more mailing lists