From: Wolfram Sang <wsa@the-dreams.de>
To: Fabrizio Castro <fabrizio.castro@bp.renesas.com>
Cc: Peter Rosin <peda@axentia.se>,
"linux-i2c@vger.kernel.org" <linux-i2c@vger.kernel.org>,
"linux-renesas-soc@vger.kernel.org"
<linux-renesas-soc@vger.kernel.org>,
Chris Paterson <Chris.Paterson2@renesas.com>,
Biju Das <biju.das@bp.renesas.com>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Simon Horman <simon@horms.net>
Subject: Re: Delay between stop condition and start condition
Date: Wed, 17 Oct 2018 16:23:47 +0200 [thread overview]
Message-ID: <20181017142347.GA5141@kunai> (raw)
In-Reply-To: <TY1PR01MB177036EC6AEADEED8ECFA21FC0FF0@TY1PR01MB1770.jpnprd01.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
> The passthrough mode is not default, it gets activated by the driver so that
> drm_get_edid can then fetch the EDID. One other nasty thing is that to end the conversation
> with the monitor you are supposed to write 0x00 to register 0x1a of the HDMI transmitter,
> which means the SoC puts address 0x39 on the bus, but the HDMI transmitter lets that
> through, the monitor NACKs the address (because its address is 0x50), and from that
> moment on the control is back with the HDMI transmitter.
> Unfortunately I don't have any other slave on the same bus, but I wonder what happens
> if someone else tries to use the same bus while the pass through mode is operating...
Wouldn't all this really speak for an i2c gate? Do all enablement stuff
in select(), all disablement stuff in deselect(), and make sure
deselect() is called after every transfer. That would mean the
passthrough is only active when the EDID eeprom is accessed. Would that
work? Given the above, it looks quite sane to do it like that in order
to avoid side-effects of the open passthrough.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-10-17 22:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-15 9:10 Delay between stop condition and start condition Fabrizio Castro
2018-10-17 10:32 ` Wolfram Sang
2018-10-17 11:27 ` Fabrizio Castro
2018-10-17 11:44 ` Peter Rosin
2018-10-17 12:16 ` Wolfram Sang
2018-10-17 12:21 ` Wolfram Sang
2018-10-17 12:31 ` Geert Uytterhoeven
2018-10-17 14:03 ` Fabrizio Castro
2018-10-17 14:23 ` Wolfram Sang [this message]
2018-10-17 16:44 ` Fabrizio Castro
2018-10-17 12:55 ` Peter Rosin
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=20181017142347.GA5141@kunai \
--to=wsa@the-dreams.de \
--cc=Chris.Paterson2@renesas.com \
--cc=biju.das@bp.renesas.com \
--cc=fabrizio.castro@bp.renesas.com \
--cc=geert+renesas@glider.be \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-renesas-soc@vger.kernel.org \
--cc=peda@axentia.se \
--cc=simon@horms.net \
/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.