[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAD=FV=W8gt+xgsJ5pPz1uCXGubDHkOnXoDz0mq--cDvkdf-j9g@mail.gmail.com>
Date: Fri, 1 Jul 2016 10:05:50 -0700
From: Doug Anderson <dianders@...omium.org>
To: Mark Brown <broonie@...nel.org>
Cc: apronin@...omium.org,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
linux-spi <linux-spi@...r.kernel.org>
Subject: Re: [PATCH 1/4] spi: Add option to wake a device by toggling CS
Hi,
On Fri, Jul 1, 2016 at 1:21 AM, Mark Brown <broonie@...nel.org> wrote:
> On Thu, Jun 30, 2016 at 09:23:26PM -0700, Doug Anderson wrote:
>
>> Also, something doesn't seem terribly robust about this, buy maybe I'm
>> being paranoid. If something happens where the timer hasn't fired
>> quickly enough then you might not know that you need to assert the
>> wakeup, right? I don't think there's a 100% guarantee that a timer
>> will fire and finish running within a certain period of time, is
>> there?
>
> No, or at least a minimum bound on accuracy - you'd need to set the
> timer for something lower than the actual limit.
I'm curious why you you need a timer at all. Can't you just keep
track of the jiffies that you last sent and do subtraction? ...or you
could get even more accurate and use a ktime_t. That avoids a whole
lot of synchronization / locking issues too...
Also: presumably you'll need to make sure that there's some margin in
this whole thing. I'd imagine that if the timeout is 10000
nanoseconds and you do the calculation and you last sent 9999
nanoseconds ago then you might decide that the other side isn't asleep
yet. ...but by the time the transfer starts it might be asleep...
-Doug
Powered by blists - more mailing lists