linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eran Duchan <pavius-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: "Håvard Skinnemoen"
	<hskinnemoen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Grant Likely
	<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Subject: Re: i2c-gpio performance issue w/MPC8xx @ 50 MHz
Date: Mon, 2 May 2011 11:48:00 +0300	[thread overview]
Message-ID: <BANLkTi=+JxbLfvjrh8A_KQ58CeJJB0wKjw@mail.gmail.com> (raw)
In-Reply-To: <BANLkTik_mBMHJt-MzcSQfdnAhseBM5KwFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>

Hey guys,

Thanks for taking a look.

> Hmm. i2c-gpio overrides the udelay specified by the platform? That
> shouldn't happen. It does try to come up with some reasonable defaults
> if the platform doesn't specify any though.

Yep, only this scheme explicitly disallows a udelay of 0. It's not too
problematic, I guess, seeing how close 1 is to 0 in terms of timing.

> I haven't investigated this in depth, but I'd say it's probably caused
> by the extra indirection added by gpiolib, assuming the gpio framework
> on your platform uses it. I guess it's one of the downsides of greatly
> reducing the amount of platform-specific code.

Indeed. Tracing the platform gpio code does not show it to be overly
complex at all; simply a matter of mapping the gpio # to a chip (which
is mapped to a port bank), mapping to the specific bit in the bank,
some locking, setting and unlocking. The only problem is that while
this is straightforward, it does introduce unwanted latency. I did not
get to profiling the code, though.

>> While I don't expect all users of i2c-algo-bit to be converted to such
>> a platform driver, it may indeed be useful in some cases, so I have no
>> objection.

Nor would I expect this to be the case. i2c-algo-bit obviously works
well on most platforms when paired to the gpio facility. It just isn't
tight enough for environments low on processing power.

> You can probably create a minimal i2c-platform driver which just
> passes the platform-specific callbacks to i2c-algo-bit. I think it
> should be a new bus driver though...

This is where I kind of lost you. I implemented a bus driver specific
to my platform (compiled in in drivers/i2c/busses) and then
instantiated it in my platform module. I thought about adding a
generic bus driver that would receive callbacks from the platform
module (for example, drivers/i2c/busses/i2c-gpio-direct, or something)
and simply pass these on to i2c-bit-algo. This would allow other
platforms to do the same without having to create a platform specific
bus driver each time like I did. I can submit something generic like
this, if you think this it conforms to the model.

Eran

  parent reply	other threads:[~2011-05-02  8:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-04-19 20:53 i2c-gpio performance issue w/MPC8xx @ 50 MHz Eran Duchan
     [not found] ` <BANLkTikaS8yOTcO+OChvutB0syWdVBsh8g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-01  8:26   ` Jean Delvare
     [not found]     ` <20110501102603.7993da58-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2011-05-01 22:04       ` Håvard Skinnemoen
     [not found]         ` <BANLkTik_mBMHJt-MzcSQfdnAhseBM5KwFg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-02  8:48           ` Eran Duchan [this message]
     [not found]             ` <BANLkTi=+JxbLfvjrh8A_KQ58CeJJB0wKjw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-05 18:54               ` Håvard Skinnemoen
     [not found]                 ` <BANLkTikaifXi9+G-3=QAihqxZqPAuBSuGw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2011-05-05 19:48                   ` Jean Delvare
2011-05-04 21:50           ` Ben Dooks
     [not found]             ` <20110504215049.GX15795-SMNkleLxa3Z6Wcw2j4pizdi2O/JbrIOy@public.gmane.org>
2011-05-05 18:42               ` Håvard Skinnemoen

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='BANLkTi=+JxbLfvjrh8A_KQ58CeJJB0wKjw@mail.gmail.com' \
    --to=pavius-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
    --cc=hskinnemoen-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
    --cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@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).