dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Tomasz Figa <tomasz.figa@gmail.com>
To: Inki Dae <inki.dae@samsung.com>, Andrzej Hajda <a.hajda@samsung.com>
Cc: "linux-samsung-soc@vger.kernel.org"
	<linux-samsung-soc@vger.kernel.org>,
	Arnd Bergmann <arnd@arndb.de>,
	DRI mailing list <dri-devel@lists.freedesktop.org>,
	Kyungmin Park <kyungmin.park@samsung.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	Marek Szyprowski <m.szyprowski@samsung.com>
Subject: Re: [PATCH v2 1/7] drm/exynos: add super device support
Date: Mon, 07 Apr 2014 17:40:42 +0200	[thread overview]
Message-ID: <5342C6FA.7060201@gmail.com> (raw)
In-Reply-To: <CAAQKjZNf=Lr=9DwFM4KCia8jeUpsVu-6h9RyfFpqK+8kkDsbgA@mail.gmail.com>

On 07.04.2014 17:16, Inki Dae wrote:
> Hi Andrzej,
>
> 2014-04-07 23:18 GMT+09:00 Andrzej Hajda <a.hajda@samsung.com>:
>> Hi Inki and Tomasz,
>>
>> On 04/06/2014 05:15 AM, Inki Dae wrote:
>>
>> (...)
>>> The code creating the list of components to wait for
>>> (exynos_drm_add_components()) doesn't seem to consider which sub-drivers are
>>> actually enabled in kernel config.
>>>
>>> Are you sure?
>>>
>>> exynos_drm_add_components() will try to attach components *added to
>>> component_lists. And these components will be added by only
>>> corresponding sub drivers to the component_lists and
>>> master->components.
>>>
>>> So in this case, if users disabled HDMI support then a commponent
>>> object for HDMI sub driver doesn't exists in the component_lists and
>>> master->components. This means that a component object for HDMI sub
>>> driver *cannot be attached to master object*.
>>>
>>> As a result, component_bind_add() will ignor component_bind call for
>>> HDMI sub driver so HDMI driver will not be bounded. The only
>>> components added by sub drivers will be bound, component->ops->bind().
>>>
>>> For more understanding, it seems like you need to look into below codes,
>>>
>>> static int exynos_drm_add_components(...)
>>> {
>>>          ...
>>>          for (i == 0;; i++) {
>>>                  ...
>>>                  node = of_parse_phandle(np, "ports", i);
>>>                  ...
>>>                  ret = component_master_add_child(m, compare_of, node);
>>>                  ...
>>>          }
>>> }
>>
>> Hmm, In case HDMI driver is not present, HDMI device is not probed and
>> HDMI component is not added, so component_master_add_child returns
>> an error when it tries to add hdmi component and master is never brought
>> up, am I correct?
>>
>
> Ok, after that,
>
> ret = component_master_add(,..)
> if (ret < 0)
>           DRM_DEBUG_KMS("re-tried by last sub driver probed later.\n");
>
> As you can see above, if component_master_add() is failed, return 0,
> *not error*. And then component_add() called by other kms drivers,
> late probing of hdmi or fimd probing - if there is any kms driver
> enabled - will try to bring up master again by calling
> try_to_bring_up_master() from beginning.
>
> And if component_list is empty then it means that there is no any kms
> driver enabled.
>
> Do you still think in that case, exynos drm initialization will be failed?

There will be no HDMI driver to call component_add(), because HDMI sub 
driver will be disabled in kernel config and any previous 
component_master_add_child() for the phandle pointing to HDMI node will 
wail, because such component will never be registered.

The complete failure path is as follows:

exynos_drm_platform_probe()
	component_master_add()
		try_to_bring_up_master()
			exynos_drm_add_components()
				// phandle to HDMI node
				component_master_add_child()
				= -ENXIO
			= -ENXIO
		= 0 // but no call to master->ops->bind(master->dev);
	= 0
= 0 // but Exynos DRM platform is not registered yet

Now if any other late-probed sub-driver comes, the sequence will be as 
follows (let's take FIMD as an example):

fimd_probe()
	component_add()
		try_to_bring_up_masters()
			try_to_bring_up_master()
				exynos_drm_add_components()
					// phandle to HDMI node
					component_master_add_child()
					= -ENXIO
				= -ENXIO
			= 0 // but no call to 	
			    // master->ops->bind(master->dev);
		= 0
	= 0
= 0 // but Exynos DRM platform still not registered

And the same for any late-probed driver, unless HDMI drivers loads, but 
there is no HDMI driver, because it is disabled in kernel config and not 
compiled in.

Best regards,
Tomasz

  reply	other threads:[~2014-04-07 15:40 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-01 12:37 [PATCH v2 0/7] drm/exynos: more cleanup with super device support Inki Dae
2014-04-01 12:37 ` [PATCH v2 1/7] drm/exynos: add " Inki Dae
2014-04-02 14:06   ` Andrzej Hajda
2014-04-03  7:43     ` Inki Dae
2014-04-03  8:36   ` [PATCH v3] " Inki Dae
2014-04-03 11:47     ` [PATCH v4] " Inki Dae
2014-04-03 14:26       ` [PATCH] drm/exynos: separate dpi from fimd Andrzej Hajda
2014-04-03 16:29         ` Inki Dae
2014-04-03 16:35         ` Inki Dae
2014-04-03 17:01           ` Inki Dae
2014-04-04 13:55   ` [PATCH v2 1/7] drm/exynos: add super device support Tomasz Figa
2014-04-04 15:44     ` Inki Dae
2014-04-05 17:32       ` Tomasz Figa
2014-04-05 18:24         ` Russell King - ARM Linux
2014-04-05 18:31           ` Tomasz Figa
2014-04-05 18:52             ` Russell King - ARM Linux
2014-04-05 19:01               ` Tomasz Figa
2014-04-06  4:21             ` Inki Dae
2014-04-06  8:47               ` Russell King - ARM Linux
2014-04-06  9:38                 ` Inki Dae
2014-04-06  3:15         ` Inki Dae
2014-04-07 14:18           ` Andrzej Hajda
2014-04-07 14:24             ` Tomasz Figa
2014-04-07 15:16             ` Inki Dae
2014-04-07 15:40               ` Tomasz Figa [this message]
2014-04-08  8:37                 ` Inki Dae
2014-04-01 12:37 ` [PATCH 2/7] drm/exynos: dpi: fix hotplug fail issue Inki Dae
2014-04-01 12:37 ` [PATCH v2 3/7] drm/exynos: register platform driver at each kms sub drivers Inki Dae
2014-04-01 12:37 ` [PATCH 4/7] ARM: dts: exynos4210-universal: add super device node for exynos drm Inki Dae
2014-04-01 12:38 ` [PATCH 5/7] ARM: dts: exynos4210-trats: " Inki Dae
2014-04-01 12:38 ` [PATCH 6/7] ARM: dts: exynos4412-trats2: " Inki Dae
2014-04-01 12:38 ` [PATCH 7/7] exynos/drm: add DT bindings Inki Dae
2014-04-03  7:43 ` [PATCH v2 0/7] drm/exynos: more cleanup with super device support Andrzej Hajda

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=5342C6FA.7060201@gmail.com \
    --to=tomasz.figa@gmail.com \
    --cc=a.hajda@samsung.com \
    --cc=arnd@arndb.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=inki.dae@samsung.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=m.szyprowski@samsung.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox