mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alexander Kochetkov <al.kochet@gmail.com>
To: Tony Lindgren <tony@atomide.com>
Cc: Kevin Hilman <khilman@kernel.org>,
	linux-omap@vger.kernel.org, linux-i2c@vger.kernel.org,
	linux-kernel@vger.kernel.org, Felipe Balbi <balbi@ti.com>,
	Wolfram Sang <wsa@the-dreams.de>
Subject: Re: [RFC] i2c: omap: TEST: do IP reset during probe.
Date: Sat, 29 Nov 2014 02:25:29 +0300	[thread overview]
Message-ID: <E4A4FA05-0752-41CB-B86B-84035C6EAF05@gmail.com> (raw)
In-Reply-To: <20141128221350.GW2817@atomide.com>

Hello, Tony!

I just want to know, is multimaster i2c feature is interesting for TI SOC,
so I could send another patches?

Or it's better to leave the thing without changes, as current single master version
well tested and work?

Also I have a draft version of mixed multimaster/slave version. But it could introduce new bugs.
Are we ready for that? Thats because IP behavior, sometimes, doesn't correspond to TRMs[4][5].
It's the one of strange IP I ever seen on TI SOC. And TRM not as detailed as DSP TRMs.

Yes, I test the patch. But  IP handling is really tricky.
So, I doubt.

Looks, like you haven't seen my response in another thread[1].
So, duplicate it here.

24.11.2014 22:47, Tony Lindgren <tony@atomide.com> *:

> If you post a patch, I can test boot with it. Looks like the failing
> ones have i2c rev3.3 on 34xx vs rev4.4 on 36xx.

> So I doubt we just want to change the test for for a higher rev number
> for  OMAP_I2C_REV_ON_3430_3530.

You 100% right here.
My fault.
Thank you for giving right directions.
Thanks Kevin for running test, so I could debug the reason.

Functional mode bits are unimplemented in the SYSTEST register on omap3530.
"10:5 Reserved Write 0s for future compatibility. Read returns 0."
That was the reason. SYSTEST always 0.

It is possible (and I could do it) to implement the bus check using SYSTEST SDA/SCL loopback mode.

One more problem, I found that BB-check from the patch[2] sometimes (very rarely) doesn't work
as expected. Sometimes the master start transfer while bus is in use by another master. 
It happens if another master continuously read from eeprom array of 0xff.

So, one of problems on the way of running IP in a multimaster mode, is BB-bit behavior.
I reported the problem to ti forum[3] and expect some response.

Regards,
Alexander.

[1] http://www.spinics.net/lists/linux-i2c/msg17797.html
[2] http://www.spinics.net/lists/linux-i2c/msg17678.html
[3] http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/537/t/383876.aspx
[4] omap3530 - TRM - spruf98y
[5] AM-DM37x Multimedia Device Silicon Revision 1.x  - sprugn4r


  reply	other threads:[~2014-11-28 23:25 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-20 21:28 [RFC 0/4] i2c: omap: patch series related to multimaster mode Alexander Kochetkov
2014-11-20 21:28 ` [PATCH 1/4] i2c: omap: cleanup register definitions Alexander Kochetkov
2014-11-21 16:08   ` Felipe Balbi
2014-11-20 21:28 ` [PATCH 2/4] i2c: omap: implement workaround for handling invalid BB-bit values Alexander Kochetkov
2014-11-21 16:08   ` Felipe Balbi
2014-11-22 13:23     ` Wolfram Sang
2014-11-22 14:06       ` Alexander Kochetkov
2014-11-22 18:02         ` Wolfram Sang
2014-11-23  4:43           ` Felipe Balbi
2014-11-23 13:18             ` Alexander Kochetkov
2014-11-24 19:08               ` Felipe Balbi
2014-11-24 19:09   ` Felipe Balbi
2014-11-20 21:28 ` [PATCH 3/4] i2c: omap: don't reset controller if Arbitration Lost detected Alexander Kochetkov
2014-11-21 16:08   ` Felipe Balbi
2014-11-21 18:11   ` Wolfram Sang
2014-11-21 22:51   ` [PATCH v2 " Alexander Kochetkov
2014-11-22  1:07     ` Felipe Balbi
2014-11-20 21:28 ` [PATCH 4/4] i2c: omap: add notes related to i2c multimaster mode Alexander Kochetkov
2014-11-21 16:08   ` Felipe Balbi
2014-11-22 19:47 ` [PATCH v3 0/4] i2c: omap: patch series related to " Alexander Kochetkov
2014-11-22 19:47   ` [PATCH v3 1/4] i2c: omap: cleanup register definitions Alexander Kochetkov
2014-11-22 19:47   ` [PATCH v3 2/4] i2c: omap: implement workaround for handling invalid BB-bit values Alexander Kochetkov
2014-11-24 19:08     ` Kevin Hilman
2014-11-24 19:10       ` Felipe Balbi
2014-11-24 19:13         ` Wolfram Sang
2014-11-24 19:25           ` Tony Lindgren
2014-11-24 19:39       ` Alexander Kochetkov
2014-11-24 19:47         ` Tony Lindgren
2014-11-24 20:05           ` Alexander Kochetkov
2014-11-25  0:09             ` Alexander Kochetkov
2014-11-25 15:41               ` Tony Lindgren
2014-11-24 21:08           ` Alexander Kochetkov
2014-11-26 22:30           ` Alexander Kochetkov
2014-11-24 20:33     ` [PATCH] omap: i2c: don't check bus state IP rev3.3 and earlier Alexander Kochetkov
2014-11-24 21:08       ` Tony Lindgren
2014-11-24 22:20         ` [PATCH v2] " Alexander Kochetkov
2014-11-25 14:19           ` Wolfram Sang
2014-11-25 14:38             ` Alexander Kochetkov
2014-11-25 19:13               ` Kevin Hilman
2014-11-26 19:26                 ` Alexander Kochetkov
2014-11-26 21:33                   ` Kevin Hilman
2014-11-25 19:12           ` Kevin Hilman
2014-11-26 19:05     ` [RFC] i2c: omap: TEST: do IP reset during probe Alexander Kochetkov
2014-11-26 21:25       ` Kevin Hilman
2014-11-28 22:13         ` Tony Lindgren
2014-11-28 23:25           ` Alexander Kochetkov [this message]
2014-11-29 22:06             ` Tony Lindgren
2014-11-29  2:14           ` Alexander Kochetkov
2014-11-22 19:47   ` [PATCH v3 3/4] i2c: omap: don't reset controller if Arbitration Lost detected Alexander Kochetkov
2014-11-22 19:47   ` [PATCH v3 4/4] i2c: omap: add notes related to i2c multimaster mode Alexander Kochetkov
2014-11-22 21:08   ` [PATCH v3 0/4] i2c: omap: patch series related to " Wolfram Sang

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=E4A4FA05-0752-41CB-B86B-84035C6EAF05@gmail.com \
    --to=al.kochet@gmail.com \
    --cc=balbi@ti.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

all inboxes | Powered by JetHome®