[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150724105251.GA22787@katana>
Date: Fri, 24 Jul 2015 12:52:51 +0200
From: Wolfram Sang <wsa@...-dreams.de>
To: Andrey Danin <danindrey@...l.ru>
Cc: Stephen Warren <swarren@...dotorg.org>, devicetree@...r.kernel.org,
devel@...uxdriverproject.org, linux-i2c@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-tegra@...r.kernel.org,
linux-kernel@...r.kernel.org, ac100@...ts.launchpad.net,
Laxman Dewangan <ldewangan@...dia.com>,
Rob Herring <robh+dt@...nel.org>,
Pawel Moll <pawel.moll@....com>,
Mark Rutland <mark.rutland@....com>,
Ian Campbell <ijc+devicetree@...lion.org.uk>,
Kumar Gala <galak@...eaurora.org>,
Russell King <linux@....linux.org.uk>,
Thierry Reding <thierry.reding@...il.com>,
Alexandre Courbot <gnurou@...il.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Julian Andres Klode <jak@...-linux.org>,
Marc Dietrich <marvin24@....de>
Subject: Re: [PATCH v3 1/4] i2c: tegra: implement slave mode
> At the begin of my work on this patchset I even denied clock disable call if
> slave is registered (to minimize code that can affect transfer).
I hacked something like this, but it seems it was not enough.
> If only slave mode is used, then this logic is not needed.
This is not sufficent. We shouldn't break being a master only because we
also listen to a slave address (as long as the HW supports that of
course).
> tegra_i2c_init is called on probe and resume. Also it is called in case of
> xfer fail. If xfer is ok, then I think slave addr must be kept unchanged.
This is fragile. Try scanning the bus with i2cdetect and slave setup
will be gone.
> As far as I understand it is a loopback mode. Probably it will not work
> (Stephen Warren already mentioned this).
Just to make clear: I am not saying we should support talking to our own
slave address. But it should still be possible to communicate with other
remote devices on the bus.
Thanks,
Wolfram
Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)
Powered by blists - more mailing lists