From: Guennadi Liakhovetski <g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>
To: Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
SH-Linux <linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Grant Likely
<grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>
Subject: Re: [PATCH 2/5] i2c: rcar: get clock rate only once and simplify calculation
Date: Wed, 11 Sep 2013 09:03:27 +0200 (CEST) [thread overview]
Message-ID: <Pine.LNX.4.64.1309110854200.26942@axis700.grange> (raw)
In-Reply-To: <CANqRtoRF8CD4hO4m23dqAtNCKvAqHo-+JhZud43SYePB4w5Ong-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Magnus
Thanks for your comments
On Wed, 11 Sep 2013, Magnus Damm wrote:
> Hi Guennadi,
>
> On Tue, Sep 10, 2013 at 12:55 AM, Guennadi Liakhovetski
> <g.liakhovetski-Mmb7MZpHnFY@public.gmane.org> wrote:
> > There is no need to repeatedly query clock frequency, where it is not
> > expected to change. The complete loop can also trivially be replaced with
> > a simple division. A further loop below the one, being simplified, could
> > also be replaced, but that would get more complicated.
> >
> > Signed-off-by: Guennadi Liakhovetski <g.liakhovetski+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
>
> Thanks for your efforts. What makes you think that you should assume
> that the clock frequency doesn't change?
Sorry, maybe I didn't explain well enough in the patch description.
Please, have a look at the patch. It removes repeated clock rate readings
inside a tight loop. I'm aware that the clock rate can change, but there
should be a way to make sure, that beginning now and until a certain later
point of time the rate doesn't change. Presumably this should be done by
locking the clock. I'm not sure this is currently supported by the clock
API. Neither clk_get(), nor clk_prepare() nor clk_enable() seem to have
the semantics of locking the clock's frequency. Maybe the one who actually
prepared the clock should become its owner, but I don't think this is
currently the expected behaviour. In either case, I don't think calling
clk_get_rate() repeatedly inside _that_ loop makes sense - the rate can
anyway be changed after the loop, so, it doesn't add any security.
Thanks
Guennadi
> As you already know, we want drivers to be reusable across multiple
> SoCs. Assuming it that it would be fixed based on one particular SoC
> doesn't guarantee that that's the case on other SoCs. Which SoCs did
> you take into consideration?
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
next prev parent reply other threads:[~2013-09-11 7:03 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-09 15:55 [PATCH 0/5] i2c: rcar: Device Tree support and clock improvements Guennadi Liakhovetski
2013-09-09 15:55 ` [PATCH 1/5] i2c: rcar: (cosmetic) remove superfluous parenthesis Guennadi Liakhovetski
[not found] ` <1378742120-11135-1-git-send-email-g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>
2013-09-09 15:55 ` [PATCH 2/5] i2c: rcar: get clock rate only once and simplify calculation Guennadi Liakhovetski
2013-09-10 22:37 ` Magnus Damm
[not found] ` <CANqRtoRF8CD4hO4m23dqAtNCKvAqHo-+JhZud43SYePB4w5Ong-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-09-11 7:03 ` Guennadi Liakhovetski [this message]
2013-09-09 15:55 ` [PATCH 5/5] i2c: rcar: use per-device clock Guennadi Liakhovetski
[not found] ` <1378742120-11135-6-git-send-email-g.liakhovetski-Mmb7MZpHnFY@public.gmane.org>
2013-09-10 22:44 ` Magnus Damm
2013-09-11 7:20 ` Guennadi Liakhovetski
2013-09-09 15:55 ` [PATCH 3/5] i2c: rcar: add Device Tree support Guennadi Liakhovetski
2013-09-10 22:40 ` Magnus Damm
[not found] ` <CANqRtoTrCwd=+m6SPO2TqvvSjEO-m4uMrChxSYs_ZxniA-7dwQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-09-10 22:46 ` Laurent Pinchart
2013-09-10 22:49 ` Magnus Damm
2013-09-11 7:37 ` Guennadi Liakhovetski
2013-09-09 15:55 ` [PATCH 4/5] i2c: rcar: fix clk_get() error handling Guennadi Liakhovetski
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=Pine.LNX.4.64.1309110854200.26942@axis700.grange \
--to=g.liakhovetski-mmb7mzphnfy@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=grant.likely-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-sh-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@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 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).