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 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.