mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jean Delvare <khali@linux-fr.org>
To: Daniel Kurtz <djkurtz@chromium.org>
Cc: Ben Dooks <ben-linux@fluff.org>,
	Wolfram Sang <w.sang@pengutronix.de>,
	Seth Heasley <seth.heasley@intel.com>,
	Olof Johansson <olof@lixom.net>,
	Benson Leung <bleung@chromium.org>,
	linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 7/8 v3] i2c: i801: enable irq for i801 smbus transactions
Date: Fri, 6 Jul 2012 13:55:00 +0200	[thread overview]
Message-ID: <20120706135500.44b17c42@endymion.delvare> (raw)
In-Reply-To: <CAGS+omAgVLumYvOssHfdjELXixMdfRSxSj003xPzQ5v4h_D-mA@mail.gmail.com>

Hi Daniel,

On Fri, 6 Jul 2012 18:28:28 +0800, Daniel Kurtz wrote:
> On Thu, Jul 5, 2012 at 4:10 PM, Jean Delvare <khali@linux-fr.org> wrote:
> > On Thu, 5 Jul 2012 12:31:11 +0800, Daniel Kurtz wrote:
> >> The logic for clearing the STATUS_FLAGS was simply that they all
> >> indicate the end of a transaction, so there won't be any further
> >> interrupts.  Thus, it is safe to clear it in the irq, since the irq
> >> will be followed by exactly one wait_event, which can read and process
> >> saved status.
> >
> > It is safe if and only if someone is actually listening to the event.
> > This was not the case for me yesterday. Even if we don't mix interrupts
> > and polling, i801_isr() might still get called when we aren't
> > listening. Not only because the IRQ may be shared, but also for events
> > we don't yet handle, such as an SMBus Alert. Not sure about slave
> > mode.
> 
> The real reason for clearing the flag in the hard irq is that
> otherwise, we end up with an infinite irq loop.  The interrupt is
> apparently level triggered, and must be cleared before exiting the
> ISR.

Oh, OK. If we have to do it that way, then we do.

> Unfortunately, I only had time today to discover this, but not time to fix it.
> Next week I will be away, so I won't have a chance to provide more
> patches for the next 10 days.
> 
> I think the 6 patches you have already make a complete set, however,
> and shouldn't be waiting for the interrupt patch(es) which can follow
> at some future date.

Agreed, that's why they are already in linux-next waiting for the next
merge window to open.

That being said, I would hate to miss that merge window for interrupt
support patches, as this is really a great performance improvement. So,
if you have no objection, I propose to fix your patches myself today of
tomorrow, test them, and if I find no problem, post them and push them
to linux-next. You can review and test them when you return.

-- 
Jean Delvare

  reply	other threads:[~2012-07-06 11:55 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-06-27 13:54 [PATCH 0/8 v3] i2c: i801: enable irq Daniel Kurtz
2012-06-27 13:54 ` [PATCH 1/8 v3] i2c: i801: refactor use of LAST_BYTE i801_block_transaction_byte_by_byte Daniel Kurtz
2012-06-27 14:39   ` Jean Delvare
2012-06-27 13:54 ` [PATCH 2/8 v3] i2c: i801: optimize waiting for HWPEC to finish Daniel Kurtz
2012-06-27 14:58   ` Jean Delvare
2012-06-27 13:54 ` [PATCH 3/8 v3] i2c: i801: check INTR after every transaction Daniel Kurtz
2012-06-27 16:07   ` Jean Delvare
2012-06-28  7:51     ` Daniel Kurtz
2012-06-28 11:36       ` Jean Delvare
2012-07-01 21:20     ` Jean Delvare
2012-07-02  1:19       ` Daniel Kurtz
2012-07-02 10:08         ` Jean Delvare
2012-07-02 15:16           ` Jean Delvare
2012-06-27 13:54 ` [PATCH 4/8 v3] i2c: i801: check and return errors during byte-by-byte transfers Daniel Kurtz
2012-06-27 16:51   ` Jean Delvare
2012-06-28  3:46     ` Daniel Kurtz
2012-06-28  7:08       ` Jean Delvare
2012-06-27 13:54 ` [PATCH 5/8 v3] i2c: i801: rename some SMBHSTCNT bit constants Daniel Kurtz
2012-06-27 17:01   ` Jean Delvare
2012-06-27 13:54 ` [PATCH 6/8 v3] i2c: i801: drop ENABLE_INT9 Daniel Kurtz
2012-06-28  7:04   ` Jean Delvare
2012-06-27 13:54 ` [PATCH 7/8 v3] i2c: i801: enable irq for i801 smbus transactions Daniel Kurtz
2012-07-04 15:48   ` Jean Delvare
2012-07-04 20:16   ` Jean Delvare
2012-07-05  4:31     ` Daniel Kurtz
2012-07-05  8:10       ` Jean Delvare
2012-07-05 10:29         ` Jean Delvare
2012-07-06 10:28         ` Daniel Kurtz
2012-07-06 11:55           ` Jean Delvare [this message]
2012-06-27 13:54 ` [PATCH 8/8 v3] i2c: i801: enable irq for byte_by_byte transactions Daniel Kurtz
2012-07-05 14:46   ` Jean Delvare
2012-07-08 11:53   ` Jean Delvare

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=20120706135500.44b17c42@endymion.delvare \
    --to=khali@linux-fr.org \
    --cc=ben-linux@fluff.org \
    --cc=bleung@chromium.org \
    --cc=djkurtz@chromium.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=olof@lixom.net \
    --cc=seth.heasley@intel.com \
    --cc=w.sang@pengutronix.de \
    /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

all inboxes | Powered by JetHome®