From: Stefan Roese <sr-ynQEQJNshbs@public.gmane.org>
To: Bhupesh SHARMA <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
Cc: "linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
spear-devel <spear-devel-nkJGhpqTU55BDgjK7y7TUQ@public.gmane.org>,
"ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org"
<ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org>
Subject: Re: [PATCH] i2c: designware: Add support for 16bit register access
Date: Wed, 14 Mar 2012 08:58:00 +0100 [thread overview]
Message-ID: <201203140858.00472.sr@denx.de> (raw)
In-Reply-To: <D5ECB3C7A6F99444980976A8C6D896384FA2BA250F-8vAmw3ZAcdzhJTuQ9jeba9BPR1lH4CV8@public.gmane.org>
Hi Bhupesh,
On Wednesday 14 March 2012 04:29:23 Bhupesh SHARMA wrote:
> > -----Original Message-----
> > From: Stefan Roese [mailto:sr-ynQEQJNshbs@public.gmane.org]
> > Sent: Tuesday, March 13, 2012 9:24 PM
> > To: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> > Cc: spear-devel; ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org
> > Subject: [PATCH] i2c: designware: Add support for 16bit register access
> >
> > The STM SPEAr platform can only access the i2c controller register
> > via 16bit read/write functions. This patch adds support to
> > automatically detect this 16bit access mode.
> >
> > Signed-off-by: Stefan Roese <sr-ynQEQJNshbs@public.gmane.org>
> > ---
> >
> > drivers/i2c/busses/i2c-designware-core.c | 22 ++++++++++++++++++++--
> > drivers/i2c/busses/i2c-designware-core.h | 1 +
> > 2 files changed, 21 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-designware-core.c
> > b/drivers/i2c/busses/i2c-designware-core.c
> > index df87992..d1facbc 100644
> > --- a/drivers/i2c/busses/i2c-designware-core.c
> > +++ b/drivers/i2c/busses/i2c-designware-core.c
> > @@ -164,7 +164,14 @@ static char *abort_sources[] = {
> >
> > u32 dw_readl(struct dw_i2c_dev *dev, int offset)
> > {
> >
> > - u32 value = readl(dev->base + offset);
> > + u32 value;
> > +
> > + if (dev->access_16bit) {
> > + value = readw(dev->base + offset) |
> > + (readw(dev->base + offset + 2) << 16);
> > + } else {
> > + value = readl(dev->base + offset);
> > + }
>
> We can do away with '{' parenthesis as these are single line
> of code inside both the 'if-else' blocks.
It's not a single-line statement. The first block extends spans 2 lines. At
least that how I interpret this CodingStyle recommendation.
> > if (dev->swab)
> >
> > return swab32(value);
> >
> > @@ -177,7 +184,12 @@ void dw_writel(struct dw_i2c_dev *dev, u32 b, int
> > offset)
> >
> > if (dev->swab)
> >
> > b = swab32(b);
> >
> > - writel(b, dev->base + offset);
> > + if (dev->access_16bit) {
> > + writew((u16)b, dev->base + offset);
> > + writew((u16)(b >> 16), dev->base + offset + 2);
> > + } else {
> > + writel(b, dev->base + offset);
> > + }
> >
> > }
> >
> > static u32
> >
> > @@ -258,6 +270,12 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
> >
> > reg = DW_IC_COMP_TYPE_VALUE;
> >
> > }
> >
> > + /* Configure register access mode 16bit */
> > + if (reg == (DW_IC_COMP_TYPE_VALUE & 0x0000ffff)) {
> > + dev->access_16bit = 1;
>
> Can we use a suitable macro for 0x0000ffff?
Hmmm. Wouldn't that make it more complex? 0x0000ffff is easy to understand. A
marco would "hide" this value. I would prefer to keep the value.
> Also, if dev->access_16bit is bool we can simply set:
> dev->access_16bit = true;
>
> more on that below...
>
> > + reg = DW_IC_COMP_TYPE_VALUE;
> > + }
> > +
> >
> > if (reg != DW_IC_COMP_TYPE_VALUE) {
> >
> > dev_err(dev->dev, "Unknown Synopsys component type: "
> >
> > "0x%08x\n", reg);
> >
> > diff --git a/drivers/i2c/busses/i2c-designware-core.h
> > b/drivers/i2c/busses/i2c-designware-core.h
> > index 02d1a2d..f5af101 100644
> > --- a/drivers/i2c/busses/i2c-designware-core.h
> > +++ b/drivers/i2c/busses/i2c-designware-core.h
> > @@ -83,6 +83,7 @@ struct dw_i2c_dev {
> >
> > u32 abort_source;
> > int irq;
> > int swab;
> >
> > + int access_16bit;
>
> ...
> int?? Probably we are better off with making this as bool.
I'm not a big fan of bool's. But I have no strong preference here. My
reasoning here was consistency. As we already have "int swab" for a similar
issue.
So basically, I would prefer to not make the changes you suggested. But in the
end its the decision of the maintainer(s).
Thanks,
Stefan
next prev parent reply other threads:[~2012-03-14 7:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-03-13 15:54 [PATCH] i2c: designware: Add support for 16bit register access Stefan Roese
[not found] ` <1331654061-5322-1-git-send-email-sr-ynQEQJNshbs@public.gmane.org>
2012-03-14 3:29 ` Bhupesh SHARMA
[not found] ` <D5ECB3C7A6F99444980976A8C6D896384FA2BA250F-8vAmw3ZAcdzhJTuQ9jeba9BPR1lH4CV8@public.gmane.org>
2012-03-14 7:58 ` Stefan Roese [this message]
[not found] ` <201203140858.00472.sr-ynQEQJNshbs@public.gmane.org>
2012-03-14 8:19 ` Bhupesh SHARMA
[not found] ` <D5ECB3C7A6F99444980976A8C6D896384FA2BA2675-8vAmw3ZAcdzhJTuQ9jeba9BPR1lH4CV8@public.gmane.org>
2012-03-14 8:43 ` Jean Delvare
[not found] ` <20120314094346.3d6e167f-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2012-03-14 8:51 ` Bhupesh SHARMA
2012-03-14 9:05 ` Stefan Roese
[not found] ` <201203141005.40531.sr-ynQEQJNshbs@public.gmane.org>
2012-03-23 8:29 ` Stefan Roese
2012-04-17 18:27 ` Wolfram Sang
2012-04-17 18:33 ` 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=201203140858.00472.sr@denx.de \
--to=sr-ynqeqjnshbs@public.gmane.org \
--cc=ben-linux-elnMNo+KYs3YtjvyW6yDsg@public.gmane.org \
--cc=bhupesh.sharma-qxv4g6HH51o@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=spear-devel-nkJGhpqTU55BDgjK7y7TUQ@public.gmane.org \
/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;
as well as URLs for NNTP newsgroup(s).