From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Archit Taneja <architt@codeaurora.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
Rob Herring <robh+dt@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge.
Date: Tue, 20 Jun 2017 10:31:19 +0300 [thread overview]
Message-ID: <1625582.5PxmiBkabx@avalon> (raw)
In-Reply-To: <8e148170-b626-b426-3c94-b93d2746f4ce@codeaurora.org>
Hi Archit,
On Tuesday 20 Jun 2017 09:18:00 Archit Taneja wrote:
> On 06/16/2017 08:13 PM, Eric Anholt wrote:
> > Archit Taneja <architt@codeaurora.org> writes:
> >> On 06/16/2017 02:11 AM, Eric Anholt wrote:
> >>> If the panel-bridge is being set up after the drm_mode_config_reset(),
> >>> then the connector's state would never get initialized, and we'd
> >>> dereference the NULL in the hotplug path. We also need to register
> >>> the connector, so that userspace can get at it.
> >>
> >> Shouldn't the KMS driver make sure the panel-bridge is set up before
> >> drm_mode_config_reset? Is it the case when we're inserting the
> >> panel-bridge driver as a module?
> >>
> >>
> >> All the connectors that have been added are registered automatically
> >> when drm_dev_register() is called by the KMS driver. Registering a
> >> connector in the middle of setting up our driver is prone to race
> >> conditions if the userspace decides to use them immediately.
> >
> > Yeah, this is fixing initializing panel_bridge at DSI host_attach time,
> > which in the case of a panel module that creates the DSI device
> > (adv7533-style, like you said I should use as a reference) will be after
> > drm_mode_config_reset() and drm_dev_register().
>
> Okay. In the case of the msm kms driver, we defer probe until the
> adv7533 module is inserted, only then we proceed to drm_mode_config_reset()
> and drm_dev_register(). I assumed this was the general practice followed by
> most kms drivers. I.,e the kms driver defers probe until all connector
> related modules are inserted, and only then proceed to create a drm device.
I'd love to see support for a more dynamic approach that would allow
registering outputs at runtime. Until that's implemented, however, I agree
with your statement, drivers should wait until all components are available
before registering the DRM device.
> Feedback from others on this would be appreciated, though.
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: multiple messages have this Message-ID (diff)
From: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To: Archit Taneja <architt@codeaurora.org>
Cc: Eric Anholt <eric@anholt.net>,
dri-devel@lists.freedesktop.org,
Andrzej Hajda <a.hajda@samsung.com>,
Thierry Reding <thierry.reding@gmail.com>,
Rob Herring <robh+dt@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge.
Date: Tue, 20 Jun 2017 10:31:19 +0300 [thread overview]
Message-ID: <1625582.5PxmiBkabx@avalon> (raw)
In-Reply-To: <8e148170-b626-b426-3c94-b93d2746f4ce@codeaurora.org>
Hi Archit,
On Tuesday 20 Jun 2017 09:18:00 Archit Taneja wrote:
> On 06/16/2017 08:13 PM, Eric Anholt wrote:
> > Archit Taneja <architt@codeaurora.org> writes:
> >> On 06/16/2017 02:11 AM, Eric Anholt wrote:
> >>> If the panel-bridge is being set up after the drm_mode_config_reset(),
> >>> then the connector's state would never get initialized, and we'd
> >>> dereference the NULL in the hotplug path. We also need to register
> >>> the connector, so that userspace can get at it.
> >>
> >> Shouldn't the KMS driver make sure the panel-bridge is set up before
> >> drm_mode_config_reset? Is it the case when we're inserting the
> >> panel-bridge driver as a module?
> >>
> >>
> >> All the connectors that have been added are registered automatically
> >> when drm_dev_register() is called by the KMS driver. Registering a
> >> connector in the middle of setting up our driver is prone to race
> >> conditions if the userspace decides to use them immediately.
> >
> > Yeah, this is fixing initializing panel_bridge at DSI host_attach time,
> > which in the case of a panel module that creates the DSI device
> > (adv7533-style, like you said I should use as a reference) will be after
> > drm_mode_config_reset() and drm_dev_register().
>
> Okay. In the case of the msm kms driver, we defer probe until the
> adv7533 module is inserted, only then we proceed to drm_mode_config_reset()
> and drm_dev_register(). I assumed this was the general practice followed by
> most kms drivers. I.,e the kms driver defers probe until all connector
> related modules are inserted, and only then proceed to create a drm device.
I'd love to see support for a more dynamic approach that would allow
registering outputs at runtime. Until that's implemented, however, I agree
with your statement, drivers should wait until all components are available
before registering the DRM device.
> Feedback from others on this would be appreciated, though.
--
Regards,
Laurent Pinchart
next prev parent reply other threads:[~2017-06-20 7:31 UTC|newest]
Thread overview: 56+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-15 20:41 [PATCH 0/7] RPi touchscreen as a panel driver again Eric Anholt
2017-06-15 20:41 ` Eric Anholt
2017-06-15 20:41 ` [PATCH 1/7] drm/bridge: Support hotplugging panel-bridge Eric Anholt
2017-06-15 20:41 ` Eric Anholt
[not found] ` <20170615204130.19255-2-eric-WhKQ6XTQaPysTnJN9+BGXg@public.gmane.org>
2017-06-16 5:43 ` Archit Taneja
2017-06-16 5:43 ` Archit Taneja
2017-06-16 14:43 ` Eric Anholt
2017-06-16 14:43 ` Eric Anholt
[not found] ` <871sqkouvr.fsf-omZaPlIz5HhaEpDpdNBo/KxOck334EZe@public.gmane.org>
2017-06-20 3:48 ` Archit Taneja
2017-06-20 3:48 ` Archit Taneja
2017-06-20 7:31 ` Laurent Pinchart [this message]
2017-06-20 7:31 ` Laurent Pinchart
[not found] ` <8e148170-b626-b426-3c94-b93d2746f4ce-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
2017-06-20 17:31 ` Eric Anholt
2017-06-20 17:31 ` Eric Anholt
[not found] ` <871sqe7ei0.fsf-omZaPlIz5HhaEpDpdNBo/KxOck334EZe@public.gmane.org>
2017-06-22 7:50 ` Benjamin Gaignard
2017-06-22 7:50 ` Benjamin Gaignard
2017-06-22 8:17 ` Archit Taneja
2017-06-22 8:17 ` Archit Taneja
2017-06-22 9:23 ` Boris Brezillon
2017-06-22 9:23 ` Boris Brezillon
2017-06-22 12:29 ` Andrzej Hajda
2017-06-22 12:29 ` Andrzej Hajda
[not found] ` <7ce4f741-309a-2eaa-381c-8033f089651a-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
2017-06-22 12:41 ` Boris Brezillon
2017-06-22 12:41 ` Boris Brezillon
2017-06-22 13:16 ` Andrzej Hajda
2017-06-22 13:16 ` Andrzej Hajda
2017-06-22 13:34 ` Boris Brezillon
2017-06-22 13:34 ` Boris Brezillon
2017-06-23 7:22 ` Andrzej Hajda
2017-06-23 7:22 ` Andrzej Hajda
2017-06-23 7:32 ` Boris Brezillon
2017-06-23 7:32 ` Boris Brezillon
2017-06-23 13:54 ` Archit Taneja
2017-06-23 21:50 ` Eric Anholt
2017-06-23 21:50 ` Eric Anholt
[not found] ` <87o9te1igt.fsf-omZaPlIz5HhaEpDpdNBo/KxOck334EZe@public.gmane.org>
2017-06-27 6:53 ` Archit Taneja
2017-06-27 6:53 ` Archit Taneja
2017-06-22 9:31 ` Philippe CORNU
2017-06-22 9:31 ` Philippe CORNU
2017-06-23 21:36 ` Eric Anholt
2017-06-23 21:36 ` Eric Anholt
2017-06-23 9:04 ` Daniel Vetter
2017-06-23 9:04 ` Daniel Vetter
2017-06-15 20:41 ` [PATCH 2/7] drm/vc4: Fix DSI T_INIT timing Eric Anholt
2017-06-15 20:41 ` Eric Anholt
2017-06-15 20:41 ` [PATCH 3/7] drm/vc4: Fix misleading name of the continuous flag Eric Anholt
2017-06-15 20:41 ` Eric Anholt
2017-06-15 20:41 ` [PATCH 4/7] drm/vc4: Use drm_mode_vrefresh() in DSI fixup, in case vrefresh is 0 Eric Anholt
2017-06-15 20:41 ` Eric Anholt
2017-06-15 20:41 ` [PATCH 5/7] dt-bindings: Document the Raspberry Pi Touchscreen nodes Eric Anholt
2017-06-23 18:44 ` Rob Herring
2017-06-23 18:44 ` Rob Herring
2017-06-15 20:41 ` [PATCH 6/7] drm/panel: Add support for the Raspberry Pi 7" Touchscreen Eric Anholt
2017-06-15 20:41 ` Eric Anholt
2017-06-15 20:41 ` [PATCH 7/7] ARM: dts: bcm2835: Enable the Raspberry Pi touchscreen panel Eric Anholt
2017-06-15 20:41 ` Eric Anholt
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=1625582.5PxmiBkabx@avalon \
--to=laurent.pinchart@ideasonboard.com \
--cc=architt@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=robh+dt@kernel.org \
--cc=thierry.reding@gmail.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 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.