All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ivan T. Ivanov" <iivanov@mm-sol.com>
To: Bjorn Andersson <bjorn@kryo.se>
Cc: Mark Rutland <mark.rutland@arm.com>,
	"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
	"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
	Matt Porter <matt.porter@linaro.org>,
	Wolfram Sang <wsa@the-dreams.de>,
	Bjorn Andersson <bjorn.andersson@sonymobile.com>,
	Grant Likely <grant.likely@linaro.org>,
	James Ralston <james.d.ralston@intel.com>,
	"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
	Pawel Moll <pawel.moll@arm.com>,
	Ian Campbell <ijc+devicetree@hellion.org.uk>,
	linux-arm-msm <linux-arm-msm@vger.kernel.org>,
	Rob Herring <rob.herring@calxeda.com>,
	Jean Delvare <khali@linux-fr.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Bill Brown <bill.e.brown@intel.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vge>
Subject: Re: [PATCH v3 0/2] Qualcomm Universal Peripheral (QUP) I2C controller
Date: Thu, 30 Jan 2014 17:30:11 +0200	[thread overview]
Message-ID: <1391095811.3275.17.camel@iivanov-dev> (raw)
In-Reply-To: <CAJAp7Oj_D1QvG9nBWTVrW1QVEpqi2cTTc9c6Um25DDzidCjW1w@mail.gmail.com>


Hi Bjorn,

On Wed, 2014-01-29 at 08:32 -0800, Bjorn Andersson wrote: 
> On Wed, Jan 29, 2014 at 12:14 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote:
> >
> > Hi Bjorn,
> >
> > On Fri, 2014-01-17 at 15:03 -0800, Bjorn Andersson wrote:
> >> Continuing on Ivans i2c-qup series.
> >>
> >
> > Do you plan to send v4 of this driver? I would like to address
> > the remaining errors and suggestions and send a new version.
> >
> Hi Ivan,
> 
> Yes I'm planning to send out a new revision of the patch set.
> 
> I've incorporated fixes from the review comments here and my colleague
> concluded through some testing that block read did not work, so we've
> fixed that as well.

Busted. I have not test it.

> 
> What have been holding me from submitting a new patchset is the 3
> functions that does polling of state and status updates;
> * qup_i2c_poll_state() reads the state register up to 1000 times,
> hoping we reach the expected state, will delay 100uS and then continue
> with 1000 more retries.
>   According to the data sheet a state transition is supposed to take
> up to 2 bus cycles. Only time I can see that this would take longer
> time are all error states, but the data sheet is not very clear
> regarding this.
> 
> * qup_i2c_wait_idle() reads the status register up to 1000 times,
> hoping the fifo gets drained and the bus go idle, if that fails it
> sleeps for the time we expect it to take to drain a full fifo and then
> loops another 1000 times. This waits for the fifo to have drained and
> the bus to go idle. On a read we get to this state if we issue the
> write and then hit the error state, so we would reset the entire
> block. On write we will only wait for the buffer not to be full before
> returning.
> 
> * qup_i2c_wait_clock_ready() waits up to 300 bus-clocks for the i2c
> bus to go idle or forced low, I don't know why it retries 300 times.
> This is called at the end of a write, possibly to wait for the fifo to
> drain.
> 
> 
> All three loops are in line with how it's been in codeaurora since the
> beginning of time, but I at least need to figure out some good names
> for those "magic numbers".


Sure. I have keep them this way, just because I don't have information
for internal trickery of the block.

Thanks, 
Ivan


> 
> Regards,
> Bjorn

WARNING: multiple messages have this Message-ID (diff)
From: iivanov@mm-sol.com (Ivan T. Ivanov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/2] Qualcomm Universal Peripheral (QUP) I2C controller
Date: Thu, 30 Jan 2014 17:30:11 +0200	[thread overview]
Message-ID: <1391095811.3275.17.camel@iivanov-dev> (raw)
In-Reply-To: <CAJAp7Oj_D1QvG9nBWTVrW1QVEpqi2cTTc9c6Um25DDzidCjW1w@mail.gmail.com>


Hi Bjorn,

On Wed, 2014-01-29 at 08:32 -0800, Bjorn Andersson wrote: 
> On Wed, Jan 29, 2014 at 12:14 AM, Ivan T. Ivanov <iivanov@mm-sol.com> wrote:
> >
> > Hi Bjorn,
> >
> > On Fri, 2014-01-17 at 15:03 -0800, Bjorn Andersson wrote:
> >> Continuing on Ivans i2c-qup series.
> >>
> >
> > Do you plan to send v4 of this driver? I would like to address
> > the remaining errors and suggestions and send a new version.
> >
> Hi Ivan,
> 
> Yes I'm planning to send out a new revision of the patch set.
> 
> I've incorporated fixes from the review comments here and my colleague
> concluded through some testing that block read did not work, so we've
> fixed that as well.

Busted. I have not test it.

> 
> What have been holding me from submitting a new patchset is the 3
> functions that does polling of state and status updates;
> * qup_i2c_poll_state() reads the state register up to 1000 times,
> hoping we reach the expected state, will delay 100uS and then continue
> with 1000 more retries.
>   According to the data sheet a state transition is supposed to take
> up to 2 bus cycles. Only time I can see that this would take longer
> time are all error states, but the data sheet is not very clear
> regarding this.
> 
> * qup_i2c_wait_idle() reads the status register up to 1000 times,
> hoping the fifo gets drained and the bus go idle, if that fails it
> sleeps for the time we expect it to take to drain a full fifo and then
> loops another 1000 times. This waits for the fifo to have drained and
> the bus to go idle. On a read we get to this state if we issue the
> write and then hit the error state, so we would reset the entire
> block. On write we will only wait for the buffer not to be full before
> returning.
> 
> * qup_i2c_wait_clock_ready() waits up to 300 bus-clocks for the i2c
> bus to go idle or forced low, I don't know why it retries 300 times.
> This is called at the end of a write, possibly to wait for the fifo to
> drain.
> 
> 
> All three loops are in line with how it's been in codeaurora since the
> beginning of time, but I at least need to figure out some good names
> for those "magic numbers".


Sure. I have keep them this way, just because I don't have information
for internal trickery of the block.

Thanks, 
Ivan


> 
> Regards,
> Bjorn

  reply	other threads:[~2014-01-30 15:30 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-17 23:03 [PATCH v3 0/2] Qualcomm Universal Peripheral (QUP) I2C controller Bjorn Andersson
2014-01-17 23:03 ` Bjorn Andersson
2014-01-17 23:03 ` [PATCH v3 1/2] i2c: qup: Add device tree bindings information Bjorn Andersson
2014-01-17 23:03   ` Bjorn Andersson
2014-01-20 14:10   ` Rob Herring
2014-01-20 14:10     ` Rob Herring
2014-01-20 14:10     ` Rob Herring
2014-01-21  2:40     ` Stephen Boyd
2014-01-21  2:40       ` Stephen Boyd
2014-01-24  7:18       ` Andy Gross
2014-01-24  7:18         ` Andy Gross
2014-01-23 19:11     ` Matthew Locke
2014-01-23 19:11       ` Matthew Locke
2014-01-23 19:50       ` Arnd Bergmann
2014-01-23 19:50         ` Arnd Bergmann
2014-01-23 20:22       ` Bjorn Andersson
2014-01-23 20:22         ` Bjorn Andersson
2014-01-17 23:03 ` [PATCH v3 2/2] i2c: New bus driver for the QUP I2C controller Bjorn Andersson
2014-01-17 23:03   ` Bjorn Andersson
2014-01-21  2:22   ` Stephen Boyd
2014-01-21  2:22     ` Stephen Boyd
2014-01-24  1:25   ` Philip Elcan
2014-01-24  1:25     ` Philip Elcan
     [not found] ` <1389999819-10648-1-git-send-email-bjorn.andersson-/MT0OVThwyLZJqsBc5GL+g@public.gmane.org>
2014-01-29  8:14   ` [PATCH v3 0/2] Qualcomm Universal Peripheral (QUP) " Ivan T. Ivanov
2014-01-29  8:14     ` Ivan T. Ivanov
2014-01-29  8:14     ` Ivan T. Ivanov
2014-01-29 16:32     ` Bjorn Andersson
2014-01-29 16:32       ` Bjorn Andersson
2014-01-30 15:30       ` Ivan T. Ivanov [this message]
2014-01-30 15:30         ` Ivan T. Ivanov
2014-01-30 23:27         ` Bjorn Andersson
2014-01-30 23:27           ` Bjorn Andersson
  -- strict thread matches above, loose matches on Subject: below --
2014-02-21  0:38 Bjorn Andersson
2014-02-21  0:38 ` Bjorn Andersson
2014-02-21  0:38 ` Bjorn Andersson

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=1391095811.3275.17.camel@iivanov-dev \
    --to=iivanov@mm-sol.com \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bill.e.brown@intel.com \
    --cc=bjorn.andersson@sonymobile.com \
    --cc=bjorn@kryo.se \
    --cc=devicetree@vger.kernel.org \
    --cc=grant.likely@linaro.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ijc+devicetree@hellion.org.uk \
    --cc=james.d.ralston@intel.com \
    --cc=khali@linux-fr.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-kernel@vge \
    --cc=mark.rutland@arm.com \
    --cc=matt.porter@linaro.org \
    --cc=pawel.moll@arm.com \
    --cc=rob.herring@calxeda.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 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.