public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@google.com>
To: J.Weitzel@phytec.de
Cc: Evgeniy Polyakov <zbr@ioremap.net>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [RFC] w1: Disable irqs in critical section
Date: Tue, 13 Sep 2011 15:41:42 -0700	[thread overview]
Message-ID: <20110913154142.f14b2c4c.akpm@google.com> (raw)
In-Reply-To: <1315460781.4396.10.camel@lws-weitzel>

On Thu, 08 Sep 2011 07:46:21 +0200
Jan Weitzel <J.Weitzel@phytec.de> wrote:

> Am Mittwoch, den 07.09.2011, 21:50 +0400 schrieb Evgeniy Polyakov:
> > On Wed, Sep 07, 2011 at 10:48:32AM +0200, Jan Weitzel (j.weitzel@phytec.de) wrote:
> > > Interrupting w1_delay in w1_read_bit results in missing the low level
> > > on the w1 line and receiving "1" instead of "0".
> > > Adding local_irq_save / local_irq_restore around the critical section
> > 
> > This means that CPU will be essentially stuck for 15 useconds for every
> > bit transferred, doesn't really look like a good idea.
> > 
> > Are you absolutely sure that missing bit is because of timings and not
> > some other bug?
> > 
> 
> I trigger a gpio line after the samplepoint. I case of a wrong bit the
> sample is taken after the "0 gap". The cycle time (samplt to sample)is
> increased form about 80__s to 95__s. 
> I did the measurement with the w1-gpio driver on a OMAP4 board.
> 

I'm not clear on how w1 actually works.  Is it a bit-banging
protocol in which the timing is provided by the host CPU?  If so then
yes, we should carefully disable interrupts in places where an
interrupt would disrupt critical timing.  (But what to do about NMIs
and SMIs?)

Disabling interrupts for 15us is pretty obnoxious, but there's a 55us
delay there with interrupts enabled, so the overall effect shouldn't be
too bad.

Finally, can we fine-tune the interrupt-disabled section a bit?  For
example, can the local_irq_disable() be moved to after the
write_bit(..., 0)?


  reply	other threads:[~2011-09-13 22:42 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-07  8:48 [RFC] w1: Disable irqs in critical section Jan Weitzel
2011-09-07 17:50 ` Evgeniy Polyakov
2011-09-08  5:46   ` Jan Weitzel
2011-09-13 22:41     ` Andrew Morton [this message]
2011-09-14 12:23       ` Jan Weitzel
2011-09-14 19:45         ` Evgeniy Polyakov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110913154142.f14b2c4c.akpm@google.com \
    --to=akpm@google.com \
    --cc=J.Weitzel@phytec.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zbr@ioremap.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox