public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Felipe Balbi <balbi@ti.com>
To: Alexander Kochetkov <al.kochet@gmail.com>
Cc: <balbi@ti.com>, Kevin Hilman <khilman@kernel.org>,
	Tony Lindgren <tony@atomide.com>,
	Wolfram Sang <wsa@the-dreams.de>,
	linux-omap <linux-omap@vger.kernel.org>,
	<linux-i2c@vger.kernel.org>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: Question about patch "i2c: omap: resize fifos before each message"
Date: Wed, 3 Dec 2014 13:38:26 -0600	[thread overview]
Message-ID: <20141203193826.GK16138@saruman> (raw)
In-Reply-To: <7602A84A-43B2-4C22-ACFA-FEA0640A6B7D@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]

Hi,

On Wed, Dec 03, 2014 at 10:01:33PM +0300, Alexander Kochetkov wrote:
> 03 дек. 2014 г., в 20:49, Felipe Balbi <balbi@ti.com> написал(а):
> 
> 
> >  It can also be a master receiver and a
> > slave transmitter. 
> Agree, but this unrelated to races.
> 
> >  Note also that MST bit does *not* auto clear.
> 
> Yes, it *does* auto clear!
> MST bit automatically clear when IP receive AL.
> See TRM [1]. All other TRMs (omap3530, omap3430, 
> omap4, omap5) has the same picture.
> 
> From TRM:
> 2Ci.I2C_CON[10] MST bits are cleared by hardware
> 
> And MST bit clear after IP send STP (success transfer).
> 
> Did you see what value is in CON register after successful master
> transfer?  Apply my patch and see that.
> It doesn't have MST bit set. That mean IP is in slave mode (receiver
> or transmitter - doesn't matter) after *any* master transfer.
> 
> And simple test show that. IP respond to GC address (address 0).
> And respond to SA address (if programmed).
> 
> And TRM[1] figure has comment for 'end' state:
> "I2C controller goes into slave receiver mode."

had completely missed that comment. Right, IP will switch over into
slave mode. Still, as of today, this can't happen because Multimaster
isn't supported :-)

> And IP keeps into slave mode until 'suspend'.
> 
> Then, after 'resume' IP initialized into slave receiver mode. There is
> short time after resume and master start initialize new transfer.
> 
> So, then we start new transfer IP could start receiving slave command.

you'd first receive an interrupt which would let you figure out if the
interrupt was for Slave or Master modes. Then you can do anything you
want (set a flag that you're going into slave mode and return -EAGAIN on
any master transfer request for example).

> > Also,
> > the IP won't do anything (considering it's always in master mode) until
> > STT bit is set again
> Yes, it do slave reception or tranmittion with STT bit set to 0.
> 
> You could set STT bit to 1, and then it got cleared to 0, you
> now, that IP received Start condition with slave transfer.
> 
> You could leave STT bit set to 0, but IP still respond to slave transfer.
> (at least the IP on dm3730).
> 
> And we can't set MST bit again after master transfer to leave IP in the
> master mode. We must disable IP (clear EN bit) before transfers to
> disable slave mode, or we must handle slave interrupts.

then handle slave interrupts :-) But handle them so that it won't race
with a master transfer request. Moving omap_i2c_xfer() inside the IRQ
handler isn't the best way to do it, however.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2014-12-03 19:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-03 15:11 Question about patch "i2c: omap: resize fifos before each message" Alexander Kochetkov
2014-12-03 15:49 ` Felipe Balbi
2014-12-03 17:34   ` Alexander Kochetkov
2014-12-03 17:49     ` Felipe Balbi
2014-12-03 19:01       ` Alexander Kochetkov
2014-12-03 19:38         ` Felipe Balbi [this message]
2014-12-03 20:04           ` Alexander Kochetkov

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=20141203193826.GK16138@saruman \
    --to=balbi@ti.com \
    --cc=al.kochet@gmail.com \
    --cc=khilman@kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=tony@atomide.com \
    --cc=wsa@the-dreams.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