linux-kernel - Re: [PATCH] ARM: dts: Add ddc i2c reference to veyron

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1441296838.3102.12.camel@pengutronix.de>
Date:	Thu, 03 Sep 2015 18:13:58 +0200
From:	Lucas Stach <l.stach@...gutronix.de>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Rob Herring <robherring2@...il.com>,
	Mark Rutland <mark.rutland@....com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Russell King - ARM Linux <linux@....linux.org.uk>,
	Heiko Stuebner <heiko@...ech.de>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Brian Norris <briannorris@...omium.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	Rob Herring <robh+dt@...nel.org>,
	Yakir Yang <ykk@...k-chips.com>,
	Kumar Gala <galak@...eaurora.org>,
	姚智情 <mark.yao@...k-chips.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	Alexandru Stan <amstan@...omium.org>
Subject: Re: [PATCH] ARM: dts: Add ddc i2c reference to veyron

Am Donnerstag, den 03.09.2015, 09:04 -0700 schrieb Doug Anderson:
> Hi,
> 
> On Thu, Sep 3, 2015 at 8:46 AM, Rob Herring <robherring2@...il.com> wrote:
> > On Thu, Sep 3, 2015 at 10:18 AM, Russell King - ARM Linux
> > <linux@....linux.org.uk> wrote:
> >> On Thu, Sep 03, 2015 at 09:46:38AM -0500, Rob Herring wrote:
> >>> Yes, that is fairly common (ADV75xx is same), and we would not
> >>> describe an I2C bus in DT in that case. Same with HPD directly handled
> >>> vs. a GPIO line. That is no different than what Doug has said:
> >>> ddc-i2c-bus is present if using the SOC's I2C host and absent if using
> >>> the HDMI block's DDC functionality. I'm only questioning the location
> >>> of the property.
> >>
> >> No, I don't think that's what Doug wants.  Doug wants the bridge's
> >> internal I2C host to be exposed, so he can number it through a DT
> >> alias.
> >
> > See his earlier reply and other patch[1] which states once the dw_hdmi
> > built-in I2C controller support is added in mainline, then this
> > property is not needed. For now, the SOC's general purpose I2C
> > controller is used.
> >
> > Rob
> >
> > [1] https://lkml.org/lkml/2015/9/2/571
> 
> Hmmm, I think we're getting all mixed up here.  To summarize:
> 
> 1. On rk3288 you can mux the same pins on the SoC to _either_ be
> controlled by a generic rk3288 i2c controller (i2c5) or controlled by
> the dw_hdmi's i2c block.
> 
> 2. At the moment, there's no code in mainline to handle the dw_hdmi's i2c block.
> 
> 3. Right now there _is_ code in mainline to handle specifying
> "ddc-i2c-bus" and have it point to the generic rk3288 i2c controller.
> 
> 4. So in mainline if you want to read an EDID, you've got to configure
> the pinmux as "i2c5" and add a "ddc-i2c-bus" reference to the HDMI
> section of the device tree.  That's what most rk3288 boards do and (as
> far as I understand) matches existing bindings.  The only reason
> veyron didn't have this reference was due to a small oversight when
> sending the DTS file upstream.
> 
> 5. There are apparently benefits to using the builtin i2c controller
> in dw_hdmi.  There's an outstanding patch add code to support the
> dw_hdmi's i2c block.
> 
> 6. Once you start using the dw_hdmi's i2c block with the currently
> posted patch against mainline (to do this you not only need the patch
> but you need to remove the ddc-i2c-bus property, set the pinmux, and
> disable i2c5) then you'll see a bonafide i2c bus exposed to Linux.  In
> my case this stole i2c0 away from the builtin SoC I2C bus and caused
> the SoC I2C bus to fail to probe.  Doh.
> 
This shouldn't happen. I don't know if the patches landed yet, but I
know Wolfram (i2c maintainer) had patches to reserve the range of bus
numbers that are fixed by alias nodes and don't hand out those numbers
to adapters with a dynamic bus number allocation.

> 7. I was trying to solve #6 by adding an "of_node" to the i2c bus
> which allowed me to give it a (non-conflicting) bus ID.
> 
This should not be needed.

Regards,
Lucas

-- 
Pengutronix e.K.             | Lucas Stach                 |
Industrial Linux Solutions   | http://www.pengutronix.de/  |

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/