On 17.09.2015 01:18, Russell King - ARM Linux wrote:
> On Wed, Sep 16, 2015 at 02:56:57PM -0700, Doug Anderson wrote:
>> Yes, I'd expect 100kHz and 400kHz.
>>
>> I agree that 50ms is non-trivial, but it's also not something you're
>> doing lots of. I'd expect that the EDID is read over this channe
Hi Doug,
On 03.09.2015 02:19, Doug Anderson wrote:
> Russell,
>
> On Wed, Sep 2, 2015 at 4:04 PM, Russell King - ARM Linux
> wrote:
Also, is it appropriate to hook non-DDC devices to a DDC bus? I suspect
that's asking for trouble.
>>>
>>> I doubt it's appropriate. Why do you ask?
>>
Hi Doug,
On 16.09.2015 23:04, Doug Anderson wrote:
> Hi,
>
> On Sun, Aug 30, 2015 at 2:34 PM, Vladimir Zapolskiy
> wrote:
>> The change adds support of internal HDMI I2C master controller, this
>> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
>>
>> The main purpose of th
On Wed, Sep 16, 2015 at 02:56:57PM -0700, Doug Anderson wrote:
> Yes, I'd expect 100kHz and 400kHz.
>
> I agree that 50ms is non-trivial, but it's also not something you're
> doing lots of. I'd expect that the EDID is read over this channel at
> cable plugin time and then not used much after that
Hi,
On Wed, Sep 16, 2015 at 2:16 PM, Vladimir Zapolskiy
wrote:
> Hi Doug,
>
> On 03.09.2015 02:19, Doug Anderson wrote:
>> Russell,
>>
>> On Wed, Sep 2, 2015 at 4:04 PM, Russell King - ARM Linux
>> wrote:
> Also, is it appropriate to hook non-DDC devices to a DDC bus? I suspect
> that's
Vladimir,
On Wed, Sep 16, 2015 at 1:58 PM, Vladimir Zapolskiy
wrote:
>>> +static void dw_hdmi_i2c_init(struct dw_hdmi *hdmi)
>>> +{
>>> + /* Set Fast Mode speed */
>>> + hdmi_writeb(hdmi, 0x0b, HDMI_I2CM_DIV);
>>
>> If you're going to hardcode to something, it seems like hardcoding to
Hi,
On Sun, Aug 30, 2015 at 2:34 PM, Vladimir Zapolskiy
wrote:
> The change adds support of internal HDMI I2C master controller, this
> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
>
> The main purpose of this functionality is to support reading EDID from
> an HDMI monit
> Wolfram, do you know of any cases where adapter->dev.of_node would not
> be the same as adapter->dev.parent->of_node?
i2c-muxes, I'd say. dev.parent is the device of the parent I2C adapter,
while the devices get populated from the of_node of the muxing device.
-- next part
On Thu, Sep 03, 2015 at 10:19:00AM +0100, Russell King - ARM Linux wrote:
> On Wed, Sep 02, 2015 at 04:43:38PM -0700, Doug Anderson wrote:
> > Russell,
> >
> > On Wed, Sep 2, 2015 at 3:50 PM, Russell King - ARM Linux
> > wrote:
> > > Never copy the of_node from one device to another. That allows
On Wed, Sep 02, 2015 at 04:43:38PM -0700, Doug Anderson wrote:
> Russell,
>
> On Wed, Sep 2, 2015 at 3:50 PM, Russell King - ARM Linux
> wrote:
> > Never copy the of_node from one device to another. That allows the
> > bus matching to unintentionally match the of_node against the wrong
> > drive
Thierry,
On Thu, Sep 3, 2015 at 2:39 AM, Thierry Reding wrote:
> Perhaps the I2C core needs to be taught to look at the adapter's
> ->dev.parent->of_node in of_find_i2c_adapter_by_node(). As I understand
> it the purpose for registering a separate struct device for each I2C
> controller is so tha
On Wed, Sep 02, 2015 at 04:00:07PM -0700, Doug Anderson wrote:
> Russell,
>
> On Wed, Sep 2, 2015 at 3:50 PM, Russell King - ARM Linux
> wrote:
> >> I think you may want to add "adap->dev.of_node = hdmi->dev->of_node;"
> >> here. That will allow device trees to specify the i2c bus by using an
>
On Wed, Sep 02, 2015 at 03:07:49PM -0700, Doug Anderson wrote:
> Hi,
>
> On Sun, Aug 30, 2015 at 2:34 PM, Vladimir Zapolskiy
> wrote:
> > +static struct i2c_adapter *dw_hdmi_i2c_adapter(struct dw_hdmi *hdmi)
> > +{
> > + struct i2c_adapter *adap;
> > + struct dw_hdmi_i2c *i2c;
> > +
Russell,
On Wed, Sep 2, 2015 at 3:50 PM, Russell King - ARM Linux
wrote:
> Never copy the of_node from one device to another. That allows the
> bus matching to unintentionally match the of_node against the wrong
> driver.
Can you be more specific about what problems you'd expect. It seems
like
Russell,
On Wed, Sep 2, 2015 at 4:04 PM, Russell King - ARM Linux
wrote:
>> > Also, is it appropriate to hook non-DDC devices to a DDC bus? I suspect
>> > that's asking for trouble.
>>
>> I doubt it's appropriate. Why do you ask?
>
> To find out why you want to "specify the I2C bus".
>
> Surely
Russell,
On Wed, Sep 2, 2015 at 3:50 PM, Russell King - ARM Linux
wrote:
>> I think you may want to add "adap->dev.of_node = hdmi->dev->of_node;"
>> here. That will allow device trees to specify the i2c bus by using an
>> alias.
>
> Never copy the of_node from one device to another. That allows
Hi,
On Sun, Aug 30, 2015 at 2:34 PM, Vladimir Zapolskiy
wrote:
> +static struct i2c_adapter *dw_hdmi_i2c_adapter(struct dw_hdmi *hdmi)
> +{
> + struct i2c_adapter *adap;
> + struct dw_hdmi_i2c *i2c;
> + int ret;
> +
> + i2c = devm_kzalloc(hdmi->dev, sizeof(*i2c), GFP_KERNE
Hi Vladimir,
Am Montag, den 31.08.2015, 00:34 +0300 schrieb Vladimir Zapolskiy:
> The change adds support of internal HDMI I2C master controller, this
> subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
I think this should be mentioned in
Documentation/devicetree/bindings/drm
The change adds support of internal HDMI I2C master controller, this
subdevice is used by default, if "ddc-i2c-bus" DT property is omitted.
The main purpose of this functionality is to support reading EDID from
an HDMI monitor on boards, which don't have an I2C bus connected to
DDC pins.
The curr
19 matches
Mail list logo
