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@xxxxxxxxx> wrote: > > On Thu, Sep 3, 2015 at 10:18 AM, Russell King - ARM Linux > > <linux@xxxxxxxxxxxxxxxx> 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 devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
