From: Max Schwarz <max.schwarz-BGeptl67XyCzQB+pC5nmwQ@public.gmane.org>
To: "Heiko Stübner" <heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org>
Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Rob Herring <robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: [PATCH] i2c: add driver for Rockchip RK3xxx SoC I2C adapter
Date: Mon, 28 Apr 2014 00:39:19 +0200 [thread overview]
Message-ID: <4500103.Z38Pp35WUa@typ> (raw)
In-Reply-To: <2533407.kJCGHuX10p@diego>
Hello Heiko,
thanks for your comments.
> both the grf as well as the bus-idx are rockchip specific, so they should be
> prefixed (rockchip,grf, etc) and from my personal taste I would hope we
> could invest in an "n" and "e", to make it a full bus-index ;-)
I will change the names to rockchip,grf and rockchip,bus-index.
> the convention seems to be "clock-frequency" for the desired bus speed
> (checked i2c-sirf, i2c-exynos, i2c-at91and i2c-qup).
Thanks for looking that up, will change.
> > + * Driver for I2C unit in Rockchip RK3188 SoC
>
> RK3188 -> RK3xxx?
yes, of course.
> > +static inline void i2c_writel(struct rk3x_i2c *i2c, u32 value,
> > + unsigned int offset)
> > +{
> > + writel(value, i2c->regs + offset);
> > +}
> > +
> > +static inline u32 i2c_readl(struct rk3x_i2c *i2c, unsigned int offset)
> > +{
> > + return readl(i2c->regs + offset);
> > +}
>
> I'm not sure what the policy here is, but is this indirection really
> necessary when it's only doing a normal readl/writel?
I saw that pattern in several device drivers (a quick grep for
"static inline void .*_writel" turns up quite a bit of those). Obviously, it
doesn't hurt performance-wise as they are just inline functions. I personally
think that
i2c_writel(i2c, val, REG_CON);
is a bit more concise than
writel(val, i2c->regs + REG_CON);
And it makes tracing easier by giving me a single function were I can trace
all register accesses, if needed.
But as you said, there might be some policy I don't know about. If you feel
strongly about it or someone else also votes for plain readl/writel, I will
happily change it.
Thanks,
Max
WARNING: multiple messages have this Message-ID (diff)
From: Max Schwarz <max.schwarz@online.de>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Wolfram Sang <wsa@the-dreams.de>,
Grant Likely <grant.likely@linaro.org>,
Rob Herring <robh+dt@kernel.org>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org
Subject: Re: [PATCH] i2c: add driver for Rockchip RK3xxx SoC I2C adapter
Date: Mon, 28 Apr 2014 00:39:19 +0200 [thread overview]
Message-ID: <4500103.Z38Pp35WUa@typ> (raw)
In-Reply-To: <2533407.kJCGHuX10p@diego>
Hello Heiko,
thanks for your comments.
> both the grf as well as the bus-idx are rockchip specific, so they should be
> prefixed (rockchip,grf, etc) and from my personal taste I would hope we
> could invest in an "n" and "e", to make it a full bus-index ;-)
I will change the names to rockchip,grf and rockchip,bus-index.
> the convention seems to be "clock-frequency" for the desired bus speed
> (checked i2c-sirf, i2c-exynos, i2c-at91and i2c-qup).
Thanks for looking that up, will change.
> > + * Driver for I2C unit in Rockchip RK3188 SoC
>
> RK3188 -> RK3xxx?
yes, of course.
> > +static inline void i2c_writel(struct rk3x_i2c *i2c, u32 value,
> > + unsigned int offset)
> > +{
> > + writel(value, i2c->regs + offset);
> > +}
> > +
> > +static inline u32 i2c_readl(struct rk3x_i2c *i2c, unsigned int offset)
> > +{
> > + return readl(i2c->regs + offset);
> > +}
>
> I'm not sure what the policy here is, but is this indirection really
> necessary when it's only doing a normal readl/writel?
I saw that pattern in several device drivers (a quick grep for
"static inline void .*_writel" turns up quite a bit of those). Obviously, it
doesn't hurt performance-wise as they are just inline functions. I personally
think that
i2c_writel(i2c, val, REG_CON);
is a bit more concise than
writel(val, i2c->regs + REG_CON);
And it makes tracing easier by giving me a single function were I can trace
all register accesses, if needed.
But as you said, there might be some policy I don't know about. If you feel
strongly about it or someone else also votes for plain readl/writel, I will
happily change it.
Thanks,
Max
next prev parent reply other threads:[~2014-04-27 22:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-27 19:38 [PATCH] i2c: add driver for Rockchip RK3xxx SoC I2C adapter Max Schwarz
2014-04-27 19:38 ` Max Schwarz
2014-04-27 20:23 ` Heiko Stübner
2014-04-27 20:23 ` Heiko Stübner
2014-04-27 22:39 ` Max Schwarz [this message]
2014-04-27 22:39 ` Max Schwarz
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=4500103.Z38Pp35WUa@typ \
--to=max.schwarz-bgeptl67xyczqb+pc5nmwq@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=heiko-4mtYJXux2i+zQB+pC5nmwQ@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=robh+dt-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=wsa-z923LK4zBo2bacvFa/9K2g@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.