From: Bjorn Andersson <bjorn.andersson@sonymobile.com>
To: Stephen Boyd <sboyd@codeaurora.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
Wolfram Sang <wsa@the-dreams.de>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
Matt Porter <matt.porter@linaro.org>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
Grant Likely <grant.likely@linaro.org>,
James Ralston <james.d.ralston@intel.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Rob Landley <rob@landley.net>, Pawel Moll <pawel.moll@arm.com>,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>,
Rob Herring <rob.herring@calxeda.com>,
Martin Schwidefsky <schwidefsky@de.ibm.com>,
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->
Subject: Re: [PATCH v2 2/2] i2c: New bus driver for the QUP I2C controller
Date: Fri, 17 Jan 2014 14:19:39 -0800 [thread overview]
Message-ID: <20140117221938.GA14212@sonymobile.com> (raw)
In-Reply-To: <20140117003314.GB13785@codeaurora.org>
On Thu 16 Jan 16:33 PST 2014, Stephen Boyd wrote:
> On 01/16, Bjorn Andersson wrote:
> > On Wed 15 Jan 08:46 PST 2014, Stephen Boyd wrote:
> >
> > > On 01/13, Bjorn Andersson wrote:
> > > > +
> > > > +static int
> > > > +qup_i2c_poll_state(struct qup_i2c_dev *qup, u32 req_state, bool only_valid)
> > > > +{
> > > > + int retries = 0;
> > > > + u32 state;
> > > > +
> > > > + do {
> > > > + state = readl(qup->base + QUP_STATE);
> > > > +
> > > > + /*
> > > > + * If only valid bit needs to be checked, requested state is
> > > > + * 'don't care'
> > > > + */
> > >
> > > It looks like req_state == 0 means only_valid == true. Can we
> > > drop the only_valid argument to this function?
> > >
> >
> > In all cases but the reset in the beginning of qup_i2c_xfer, so it seems that
> > it has to stay.
>
> Oh that's because QUP_RESET_STATE is equal to 0? It looks like
> bits 0 and 1 are the state field and bit 2 is a flag indicating
> that bits 0 and 1 are valid. Why not OR in the QUP_STATE_VALID
> flag into the macros that are passed to this function? Then the
> logic would simply be looping looking for a match of the
> req_state (which is really a mask now).
While it's true that req_state == 0 means only_valid, it is not true that
only_valid means req_state == 0. So there would be no way to differentiate
between "valid and reset" and "valid and don't care about run/pause/reset".
So I could move the logic around, but I don't see how we could reduce the
number of parameters to the function.
// Bjorn
WARNING: multiple messages have this Message-ID (diff)
From: bjorn.andersson@sonymobile.com (Bjorn Andersson)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/2] i2c: New bus driver for the QUP I2C controller
Date: Fri, 17 Jan 2014 14:19:39 -0800 [thread overview]
Message-ID: <20140117221938.GA14212@sonymobile.com> (raw)
In-Reply-To: <20140117003314.GB13785@codeaurora.org>
On Thu 16 Jan 16:33 PST 2014, Stephen Boyd wrote:
> On 01/16, Bjorn Andersson wrote:
> > On Wed 15 Jan 08:46 PST 2014, Stephen Boyd wrote:
> >
> > > On 01/13, Bjorn Andersson wrote:
> > > > +
> > > > +static int
> > > > +qup_i2c_poll_state(struct qup_i2c_dev *qup, u32 req_state, bool only_valid)
> > > > +{
> > > > + int retries = 0;
> > > > + u32 state;
> > > > +
> > > > + do {
> > > > + state = readl(qup->base + QUP_STATE);
> > > > +
> > > > + /*
> > > > + * If only valid bit needs to be checked, requested state is
> > > > + * 'don't care'
> > > > + */
> > >
> > > It looks like req_state == 0 means only_valid == true. Can we
> > > drop the only_valid argument to this function?
> > >
> >
> > In all cases but the reset in the beginning of qup_i2c_xfer, so it seems that
> > it has to stay.
>
> Oh that's because QUP_RESET_STATE is equal to 0? It looks like
> bits 0 and 1 are the state field and bit 2 is a flag indicating
> that bits 0 and 1 are valid. Why not OR in the QUP_STATE_VALID
> flag into the macros that are passed to this function? Then the
> logic would simply be looping looking for a match of the
> req_state (which is really a mask now).
While it's true that req_state == 0 means only_valid, it is not true that
only_valid means req_state == 0. So there would be no way to differentiate
between "valid and reset" and "valid and don't care about run/pause/reset".
So I could move the logic around, but I don't see how we could reduce the
number of parameters to the function.
// Bjorn
next prev parent reply other threads:[~2014-01-17 22:19 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-14 0:30 [PATCH v2 0/2] Qualcomm Universal Peripheral (QUP) I2C controller Bjorn Andersson
2014-01-14 0:30 ` Bjorn Andersson
2014-01-14 0:30 ` [PATCH v2 1/2] i2c: qup: Add device tree bindings information Bjorn Andersson
2014-01-14 0:30 ` Bjorn Andersson
2014-01-14 8:57 ` Ivan T. Ivanov
2014-01-14 8:57 ` Ivan T. Ivanov
2014-01-16 23:20 ` Bjorn Andersson
2014-01-16 23:20 ` Bjorn Andersson
2014-01-16 23:20 ` Bjorn Andersson
2014-01-17 7:40 ` Ivan T. Ivanov
2014-01-17 7:40 ` Ivan T. Ivanov
2014-01-17 7:40 ` Ivan T. Ivanov
2014-01-14 0:30 ` [PATCH v2 2/2] i2c: New bus driver for the QUP I2C controller Bjorn Andersson
2014-01-14 0:30 ` Bjorn Andersson
2014-01-14 13:03 ` Ivan T. Ivanov
2014-01-14 13:03 ` Ivan T. Ivanov
2014-01-15 16:46 ` Stephen Boyd
2014-01-15 16:46 ` Stephen Boyd
[not found] ` <20140115164604.GI14405-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2014-01-16 13:37 ` Ivan T. Ivanov
2014-01-16 13:37 ` Ivan T. Ivanov
2014-01-16 13:37 ` Ivan T. Ivanov
2014-01-17 0:18 ` Bjorn Andersson
2014-01-17 0:18 ` Bjorn Andersson
2014-01-17 0:33 ` Stephen Boyd
2014-01-17 0:33 ` Stephen Boyd
2014-01-17 22:19 ` Bjorn Andersson [this message]
2014-01-17 22:19 ` 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=20140117221938.GA14212@sonymobile.com \
--to=bjorn.andersson@sonymobile.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=bill.e.brown@intel.com \
--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=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=mark.rutland@arm.com \
--cc=matt.porter@linaro.org \
--cc=pawel.moll@arm.com \
--cc=rob.herring@calxeda.com \
--cc=rob@landley.net \
--cc=sboyd@codeaurora.org \
--cc=schwidefsky@de.ibm.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.