All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: Jonathan Hunter <jonathanh@nvidia.com>,
	Lyude Paul <lyude@redhat.com>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Maxime Ripard <mripard@kernel.org>,
	Thomas Zimmermann <tzimmermann@suse.de>,
	David Airlie <airlied@linux.ie>,
	Thomas Graichen <thomas.graichen@gmail.com>,
	dri-devel@lists.freedesktop.org, linux-tegra@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v1 2/2] drm/tegra: Use drm_dp_aux_register_ddc/chardev() helpers
Date: Fri, 12 Nov 2021 11:52:45 +0100	[thread overview]
Message-ID: <YY5HfUUSmnr6qQSU@orome.fritz.box> (raw)
In-Reply-To: <49ffd29b-eb64-e0ca-410c-44074673d740@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

On Tue, Nov 09, 2021 at 05:39:02PM +0300, Dmitry Osipenko wrote:
> 09.11.2021 17:17, Dmitry Osipenko пишет:
> > 09.11.2021 17:08, Dmitry Osipenko пишет:
> >>> +static void host1x_drm_dev_deinit(struct host1x_device *dev)
> >>> +{
> >>> +	struct drm_device *drm = dev_get_drvdata(&dev->dev);
> >> And platform_unregister_drivers() should be moved here.
> >>
> > 
> > Nah, that should cause deadlock. This ad-hoc is too lame.
> 
> Actually, there is no problem here as I see now. The host1x driver
> populates DT nodes after host1x_register() [1], meaning that Host1x DRM
> will be always inited first.
> 
> [1]
> https://elixir.bootlin.com/linux/v5.15/source/drivers/gpu/host1x/dev.c#L475
> 
> Still I'm not a fan of the ad-hoc solution.

Could we not fix this by making the panel "hot-pluggable"? I don't think
there's anything inherent to the driver that would prevent doing so. The
original reason for why things are as intertwined as they are now is
because back at the time deferred framebuffer creation didn't exist. In
fact I added deferred framebuffer support with Daniel's help precisely
to fix a similar issue for things like HDMI and DP.

With HDMI and DP it's slightly less critical, because a lack of mode
support would've created a 1024x768 framebuffer, which most HDMI/DP
monitors support. However, with panels we need to ensure that the exact
mode from the panel is used to create the framebuffer, so it can only be
created when the panel is available.

But, given that deferred framebuffer creation works now (which allows
the framebuffer console to show up at the preferred resolution for HDMI
and DP), even if a monitor is attached only after the driver has probed
already, we should be able to make something like that work with panels
as well.

Thierry

> > Another solution is to defer probing of DP AUX driver while
> > tegra_drm_device() returns NULL, but it's icky.
> > 
> > Reverting the original DP AUX DDC registration order is the best option
> > so far, IMO.
> > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Thierry Reding <thierry.reding@gmail.com>
To: Dmitry Osipenko <digetx@gmail.com>
Cc: David Airlie <airlied@linux.ie>,
	Thomas Graichen <thomas.graichen@gmail.com>,
	linux-kernel@vger.kernel.org,
	Jonathan Hunter <jonathanh@nvidia.com>,
	dri-devel@lists.freedesktop.org,
	Thomas Zimmermann <tzimmermann@suse.de>,
	linux-tegra@vger.kernel.org
Subject: Re: [PATCH v1 2/2] drm/tegra: Use drm_dp_aux_register_ddc/chardev() helpers
Date: Fri, 12 Nov 2021 11:52:45 +0100	[thread overview]
Message-ID: <YY5HfUUSmnr6qQSU@orome.fritz.box> (raw)
In-Reply-To: <49ffd29b-eb64-e0ca-410c-44074673d740@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2050 bytes --]

On Tue, Nov 09, 2021 at 05:39:02PM +0300, Dmitry Osipenko wrote:
> 09.11.2021 17:17, Dmitry Osipenko пишет:
> > 09.11.2021 17:08, Dmitry Osipenko пишет:
> >>> +static void host1x_drm_dev_deinit(struct host1x_device *dev)
> >>> +{
> >>> +	struct drm_device *drm = dev_get_drvdata(&dev->dev);
> >> And platform_unregister_drivers() should be moved here.
> >>
> > 
> > Nah, that should cause deadlock. This ad-hoc is too lame.
> 
> Actually, there is no problem here as I see now. The host1x driver
> populates DT nodes after host1x_register() [1], meaning that Host1x DRM
> will be always inited first.
> 
> [1]
> https://elixir.bootlin.com/linux/v5.15/source/drivers/gpu/host1x/dev.c#L475
> 
> Still I'm not a fan of the ad-hoc solution.

Could we not fix this by making the panel "hot-pluggable"? I don't think
there's anything inherent to the driver that would prevent doing so. The
original reason for why things are as intertwined as they are now is
because back at the time deferred framebuffer creation didn't exist. In
fact I added deferred framebuffer support with Daniel's help precisely
to fix a similar issue for things like HDMI and DP.

With HDMI and DP it's slightly less critical, because a lack of mode
support would've created a 1024x768 framebuffer, which most HDMI/DP
monitors support. However, with panels we need to ensure that the exact
mode from the panel is used to create the framebuffer, so it can only be
created when the panel is available.

But, given that deferred framebuffer creation works now (which allows
the framebuffer console to show up at the preferred resolution for HDMI
and DP), even if a monitor is attached only after the driver has probed
already, we should be able to make something like that work with panels
as well.

Thierry

> > Another solution is to defer probing of DP AUX driver while
> > tegra_drm_device() returns NULL, but it's icky.
> > 
> > Reverting the original DP AUX DDC registration order is the best option
> > so far, IMO.
> > 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2021-11-12 10:52 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-07 23:08 [PATCH v1 1/2] drm/dp: Add drm_dp_aux_register_ddc/chardev() helpers Dmitry Osipenko
2021-11-07 23:08 ` Dmitry Osipenko
2021-11-07 23:08 ` [PATCH v1 2/2] drm/tegra: Use " Dmitry Osipenko
2021-11-07 23:08   ` Dmitry Osipenko
2021-11-08 15:17   ` Daniel Vetter
2021-11-08 15:17     ` Daniel Vetter
2021-11-08 18:16     ` Dmitry Osipenko
2021-11-09  9:19       ` Daniel Vetter
2021-11-09  9:19         ` Daniel Vetter
2021-11-09 13:52         ` Dmitry Osipenko
2021-11-09 14:08           ` Dmitry Osipenko
2021-11-09 14:17             ` Dmitry Osipenko
2021-11-09 14:39               ` Dmitry Osipenko
2021-11-12 10:52                 ` Thierry Reding [this message]
2021-11-12 10:52                   ` Thierry Reding
2021-11-12 14:32                   ` Dmitry Osipenko
2021-11-12 14:32                     ` Dmitry Osipenko
2021-11-12 20:26                     ` Lyude Paul
2021-11-12 20:26                       ` Lyude Paul
2021-11-12 20:45                       ` Dmitry Osipenko
2021-11-12 20:45                         ` Dmitry Osipenko

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=YY5HfUUSmnr6qQSU@orome.fritz.box \
    --to=thierry.reding@gmail.com \
    --cc=airlied@linux.ie \
    --cc=digetx@gmail.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=jonathanh@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-tegra@vger.kernel.org \
    --cc=lyude@redhat.com \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=mripard@kernel.org \
    --cc=thomas.graichen@gmail.com \
    --cc=tzimmermann@suse.de \
    /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.