lkml.org 
[lkml]   [2015]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] ARM: dts: Add ddc i2c reference to veyron
From
Date
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@gmail.com> wrote:
> > On Thu, Sep 3, 2015 at 10:18 AM, Russell King - ARM Linux
> > <linux@arm.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/ |



\
 
 \ /
  Last update: 2015-09-03 18:41    [W:0.059 / U:0.560 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site