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

From: Doug Anderson
Date: Wed Sep 02 2015 - 20:23:06 EST


On Wed, Sep 2, 2015 at 5:13 PM, Rob Herring <robherring2@xxxxxxxxx> wrote:
> On Wed, Sep 2, 2015 at 4:25 PM, Douglas Anderson <dianders@xxxxxxxxxxxx> wrote:
>> The ddc-i2c-bus property was missing from the veyron dtsi file since
>> downstream the ddc-i2c-bus was still being specified in rk3288.dtsi and
>> nobody noticed when the veyron dtsi was sent upstream. Add it.
>> Signed-off-by: Douglas Anderson <dianders@xxxxxxxxxxxx>
>> ---
>> Note: I noticed that this was wrong but I don't currently have
>> graphics up and running on upstream on veyron. Posting this anyway
>> since it's pretty clear that it's needed. If someone else wants to
>> try it out that'd be nice, otherwise I'll put it on my list to figure
>> out how to get myself setup for graphics upstream. ;)
> Based on your other patch, this is temporary, right?

Yes, though since I'm not personally working on the other patch series
upstream I can't say for how long the "temporary" is.. I mostly
posted the 2nd patch because it was clearly correct to add some
pinmuxing states and could land any time, so I thought I'd be helpful.

You're right that in the Chrome OS tree I turned right around and
effectively removed the "ddc-i2c-bus", but having it land first adds a
much better logical progression (make it the same as everyone else and
_then_ change it). It also provides a revert path if something goes
wrong. :)

> I've been looking at DRM a lot lately. I think specifying the i2c bus
> in the hdmi chip or IP block node is wrong. If the I2C host is
> separate from the HDMI block, then it's only connection is to the HDMI
> connector. So the I2C host to the connector relationship is what the
> DT should describe. HPD gpio is similar. Now if the HDMI bridge
> controls DDC and HPD directly, then we don't need to describe those
> connections.

I will say that I know very very little about DRM. Mostly I just
visit it when there's some bug I'm running into that I can't find a
better suited owner for. ;)

I'm not sure I followed your whole paragraph. Could you give a
fragment of DTS for how you'd imagine this ought to work? Also: the
patch I submitted does match the current bindings if I understand it
right. is typical with device tree, if we want to change the
bindings we've got to have a really good reason because we'd either
need to figure out how to deal with existing DTBs in the field that
need to run with newer kernels (if those exist).

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at