From: Laxman Dewangan <ldewangan-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
To: Marc Dietrich <marvin24-Mmb7MZpHnFY@public.gmane.org>
Cc: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>,
"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: question on possible i2c slave configuration
Date: Mon, 19 Aug 2013 12:16:07 +0530 [thread overview]
Message-ID: <5211BF2F.1010309@nvidia.com> (raw)
In-Reply-To: <1674757.GDNdpd4ScH-D3pzGp0ZKuDWZbiwp4sFPyrtisivX6KghOMvlBiLbJSELgA04lAiVw@public.gmane.org>
Hi Marc,
Sorry for late response, I was on vacation.
On Tuesday 13 August 2013 07:46 PM, Marc Dietrich wrote:
> Hi Laxman,
>
> Stephen and me were discussing about the possible configuration of the i2c
> slave controller. The question here is if the slave and the master controller
> of the same port (or instance) can act in parallel.
Yes, they can work in parallel. Infact we also tested the loopback
(internal) from master to slave for same instance controller.
Bot engine (Master and slave) shared the interrupt number, clock bit and
clock source, reset bit, and some controller registers.
So if we handle the sharing of this stuff then it is fine to use in
parallel.
>
> This is of particular interest when it comes to device tree representation.
> The Tegra3 TRM mentions a that the master can address its own slave for
> testing purposes. Also the i2c block diagram suggests that there are two
> controllers (for master and slave) connected to the same bus.
Yes, this is very much supported and we have simple testcases for this.
> If this is the case, master and slave mode is not exclusive, or in other
> words, the i2c master and slave need to share their resources.
Yes, it is not exclusive and share some common resources as mentioned above.
> Another question is (because this would add a lot of code complexity) if we
> want to allow such a configuration at all.
In Tegra context, we did not use the master and slave together as these
makes the sw unnecessarily complex. We used in either in master or in
slave only.
next prev parent reply other threads:[~2013-08-19 6:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-13 14:16 question on possible i2c slave configuration Marc Dietrich
[not found] ` <1674757.GDNdpd4ScH-D3pzGp0ZKuDWZbiwp4sFPyrtisivX6KghOMvlBiLbJSELgA04lAiVw@public.gmane.org>
2013-08-19 6:46 ` Laxman Dewangan [this message]
[not found] ` <5211BF2F.1010309-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2013-08-21 21:34 ` Marc Dietrich
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=5211BF2F.1010309@nvidia.com \
--to=ldewangan-ddmlm1+adcrqt0dzr+alfa@public.gmane.org \
--cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marvin24-Mmb7MZpHnFY@public.gmane.org \
--cc=swarren-3lzwWm7+Weoh9ZMKESR00Q@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.