All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephen Warren <swarren-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
To: Mark Zhang <markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Cc: "linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org"
	<linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	"linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH] ARM: dt: tegra: ventana: define pinmux for ddc
Date: Thu, 25 Oct 2012 09:37:22 -0600	[thread overview]
Message-ID: <50895CB2.8040103@wwwdotorg.org> (raw)
In-Reply-To: <5088DCF2.7030000-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>

On 10/25/2012 12:32 AM, Mark Zhang wrote:
> On 10/23/2012 01:14 AM, Stephen Warren wrote:
...
>> I don't recall why pta was defined to be HDMI. The issue isn't that this
>> patch changes the pinmux selection for the pta pingroup, but simply that
>> both the pinctrl node's state definition, and the new I2C mux node's
>> state definition both attempt to configure pingroup pta. The solution is
>> most likely to simply remove the pta configuration from the main pinctrl
>> node.
> 
> Understood. I tried to remove the hdmi function definition of pta
> pingroup yesterday then found HDMI can't work anymore. The EDID of HDMI
> monitor can't be fetched. After some debugging, I have found that it's
> caused by "i2c-mux-pinctrl" driver is loaded after drm driver. That
> makes drm driver can't get EDID data via this i2c mux adapter because it
> doesn't exist at that time. So I think we need to promote the load level
> of "i2c-mux-pinctrl" driver. Any other ideas?

(BTW, your message that I'm replying to wasn't word-wrapped correctly)

No, i2c-mux-pinctrl shouldn't need to change. It sounds like tegra-drm
isn't supporting deferred probe correctly; when it needs access to an
I2C adapter that doesn't exist, it should defer its own probe until the
I2C adapter does exist.

WARNING: multiple messages have this Message-ID (diff)
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: dt: tegra: ventana: define pinmux for ddc
Date: Thu, 25 Oct 2012 09:37:22 -0600	[thread overview]
Message-ID: <50895CB2.8040103@wwwdotorg.org> (raw)
In-Reply-To: <5088DCF2.7030000@nvidia.com>

On 10/25/2012 12:32 AM, Mark Zhang wrote:
> On 10/23/2012 01:14 AM, Stephen Warren wrote:
...
>> I don't recall why pta was defined to be HDMI. The issue isn't that this
>> patch changes the pinmux selection for the pta pingroup, but simply that
>> both the pinctrl node's state definition, and the new I2C mux node's
>> state definition both attempt to configure pingroup pta. The solution is
>> most likely to simply remove the pta configuration from the main pinctrl
>> node.
> 
> Understood. I tried to remove the hdmi function definition of pta
> pingroup yesterday then found HDMI can't work anymore. The EDID of HDMI
> monitor can't be fetched. After some debugging, I have found that it's
> caused by "i2c-mux-pinctrl" driver is loaded after drm driver. That
> makes drm driver can't get EDID data via this i2c mux adapter because it
> doesn't exist at that time. So I think we need to promote the load level
> of "i2c-mux-pinctrl" driver. Any other ideas?

(BTW, your message that I'm replying to wasn't word-wrapped correctly)

No, i2c-mux-pinctrl shouldn't need to change. It sounds like tegra-drm
isn't supporting deferred probe correctly; when it needs access to an
I2C adapter that doesn't exist, it should defer its own probe until the
I2C adapter does exist.

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Mark Zhang <markz@nvidia.com>
Cc: "linux@arm.linux.org.uk" <linux@arm.linux.org.uk>,
	"linux-tegra@vger.kernel.org" <linux-tegra@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] ARM: dt: tegra: ventana: define pinmux for ddc
Date: Thu, 25 Oct 2012 09:37:22 -0600	[thread overview]
Message-ID: <50895CB2.8040103@wwwdotorg.org> (raw)
In-Reply-To: <5088DCF2.7030000@nvidia.com>

On 10/25/2012 12:32 AM, Mark Zhang wrote:
> On 10/23/2012 01:14 AM, Stephen Warren wrote:
...
>> I don't recall why pta was defined to be HDMI. The issue isn't that this
>> patch changes the pinmux selection for the pta pingroup, but simply that
>> both the pinctrl node's state definition, and the new I2C mux node's
>> state definition both attempt to configure pingroup pta. The solution is
>> most likely to simply remove the pta configuration from the main pinctrl
>> node.
> 
> Understood. I tried to remove the hdmi function definition of pta
> pingroup yesterday then found HDMI can't work anymore. The EDID of HDMI
> monitor can't be fetched. After some debugging, I have found that it's
> caused by "i2c-mux-pinctrl" driver is loaded after drm driver. That
> makes drm driver can't get EDID data via this i2c mux adapter because it
> doesn't exist at that time. So I think we need to promote the load level
> of "i2c-mux-pinctrl" driver. Any other ideas?

(BTW, your message that I'm replying to wasn't word-wrapped correctly)

No, i2c-mux-pinctrl shouldn't need to change. It sounds like tegra-drm
isn't supporting deferred probe correctly; when it needs access to an
I2C adapter that doesn't exist, it should defer its own probe until the
I2C adapter does exist.

  parent reply	other threads:[~2012-10-25 15:37 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-19  5:58 [PATCH] ARM: dt: tegra: ventana: define pinmux for ddc Mark Zhang
2012-10-19  5:58 ` Mark Zhang
2012-10-19  5:58 ` Mark Zhang
     [not found] ` <1350626311-18131-1-git-send-email-markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-10-19 15:48   ` Stephen Warren
2012-10-19 15:48     ` Stephen Warren
2012-10-19 15:48     ` Stephen Warren
     [not found]     ` <50817668.6020709-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-10-22  7:29       ` Mark Zhang
2012-10-22  7:29         ` Mark Zhang
2012-10-22  7:29         ` Mark Zhang
     [not found]         ` <5084F5D1.7050005-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-10-22 17:14           ` Stephen Warren
2012-10-22 17:14             ` Stephen Warren
2012-10-22 17:14             ` Stephen Warren
     [not found]             ` <50857EEF.2070707-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-10-25  6:32               ` Mark Zhang
2012-10-25  6:32                 ` Mark Zhang
2012-10-25  6:32                 ` Mark Zhang
     [not found]                 ` <5088DCF2.7030000-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
2012-10-25 15:37                   ` Stephen Warren [this message]
2012-10-25 15:37                     ` Stephen Warren
2012-10-25 15:37                     ` Stephen Warren
     [not found]                     ` <50895CB2.8040103-3lzwWm7+Weoh9ZMKESR00Q@public.gmane.org>
2012-10-26  6:28                       ` Mark Zhang
2012-10-26  6:28                         ` Mark Zhang
2012-10-26  6:28                         ` Mark Zhang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50895CB2.8040103@wwwdotorg.org \
    --to=swarren-3lzwwm7+weoh9zmkesr00q@public.gmane.org \
    --cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
    --cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org \
    --cc=linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=markz-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.