All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Andreas Färber" <andreas.faerber@web.de>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: Tony Lindgren <tony@atomide.com>,
	qemu-devel@nongnu.org, Blue Swirl <blauwirbel@gmail.com>,
	Alex Horn <alex.horn@cs.ox.ac.uk>,
	Anthony Liguori <anthony@codemonkey.ws>
Subject: Re: [Qemu-devel] [PATCH 1/2] omap_i2c: Clear SBD bit in STAT register on DATA read
Date: Thu, 13 Dec 2012 18:04:41 +0100	[thread overview]
Message-ID: <50CA0AA9.1030503@web.de> (raw)
In-Reply-To: <CAFEAcA8nWWQwK+s1cWTUtSCDrV9dSh_5WO58Wnt0ChC1RS2uXw@mail.gmail.com>

Am 13.12.2012 15:45, schrieb Peter Maydell:
> On 12 December 2012 06:29, Andreas Färber <andreas.faerber@web.de> wrote:
>> After reading a single-byte I2C response such as the tmp105's response
>> to 0x01 0x00, the SBD status bit would not get reset on next read, still
>> indicating validity of only a single byte. Clear it on next word read.
> 
> This doesn't seem to correspond to what the OMAP1510 manual describes
> as the condition for this bit to be zeroed:

I don't have the manual, just Andrzej's omap_i2c code. n800/n810 seems
to be OMAP2420 btw.

> "This bit is cleared to 0 by the core when the local host reads the
> I2C_IV register if INTCODE is register access ready."

    case 0x0c:	/* I2C_IV */
        if (s->revision >= OMAP2_INTR_REV)
            break;

And our s->revision == OMAP2_INTR_REV (0x34), so reading IV is a no-op.
It reads as related to interrupt handling, which I was otherwise not
touching on.

There was no other comment saying "SBD" anywhere or touching "1 << 15"
of s->stat, so to me it seems nothing resets this bit today.

I don't get any hit for "SBD" in the Linux driver either, i2c-omap.c in
torvalds/linux.git seems to unconditionally read both bytes in
omap_i2c_receive_data() if the device has a 16-bit register. CC'ing the
Linux OMAP maintainer.

I could try to simply ignore SBD and rely on my own counting. I already
moved it to its own libqos source file last night.

> The manual also says for I2C_DATA:
> "In case of an odd number of bytes received to read, the upper byte of
> the last access always reads as 0x00. The local host must check the SBD
> status bit in I2C_STAT register to flush this null byte."
> 
> ...which to a naive reading implies that the high byte has
> to be jammed to all-zeroes until I2C_STAT is read, but that
> seems a little implausible.

To me that just says I need to check SBD to decide whether the high byte
last read is valid.

Andreas

> (interestingly the SBD bit is always 0 for omap3 because the data
> FIFO is 8 bits wide and so data is always read byte at at time)
> 
> -- PMM

  reply	other threads:[~2012-12-13 17:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-12  6:29 [Qemu-devel] [PATCH 0/2] tmp105: qtest support Andreas Färber
2012-12-12  6:29 ` [Qemu-devel] [PATCH 1/2] omap_i2c: Clear SBD bit in STAT register on DATA read Andreas Färber
2012-12-13 14:45   ` Peter Maydell
2012-12-13 17:04     ` Andreas Färber [this message]
2012-12-13 17:10       ` Peter Maydell
2012-12-12  6:29 ` [Qemu-devel] [PATCH 2/2] tests: Add tmp105 unit test Andreas Färber
2012-12-12 14:44   ` Alex Horn
2012-12-15 17:44     ` Andreas Färber
2012-12-12 19:43   ` Blue Swirl
2012-12-12 23:17     ` Andreas Färber

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=50CA0AA9.1030503@web.de \
    --to=andreas.faerber@web.de \
    --cc=alex.horn@cs.ox.ac.uk \
    --cc=anthony@codemonkey.ws \
    --cc=blauwirbel@gmail.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=tony@atomide.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.