All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@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 17:32:43 +0300	[thread overview]
Message-ID: <5ee3f964-39ec-f6e2-5a01-230532a8b17e@gmail.com> (raw)
In-Reply-To: <YY5HfUUSmnr6qQSU@orome.fritz.box>

12.11.2021 13:52, Thierry Reding пишет:
> 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.

I don't understand what do you mean by "hot-pluggable", panel is static.
Please either clarify more or type the patch.

Keep in mind that fix should be simple and portable because stable
kernels are wrecked.

> 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.

BTW, I see now that DPAUX I2C transfer helper may access
aux->drm_device. Hence v1 patch isn't correct anyways.

For now I'll try to test more the ad-hoc variant with Thomas and send it
as v2 if we won't have a better solution.

WARNING: multiple messages have this Message-ID (diff)
From: Dmitry Osipenko <digetx@gmail.com>
To: Thierry Reding <thierry.reding@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 17:32:43 +0300	[thread overview]
Message-ID: <5ee3f964-39ec-f6e2-5a01-230532a8b17e@gmail.com> (raw)
In-Reply-To: <YY5HfUUSmnr6qQSU@orome.fritz.box>

12.11.2021 13:52, Thierry Reding пишет:
> 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.

I don't understand what do you mean by "hot-pluggable", panel is static.
Please either clarify more or type the patch.

Keep in mind that fix should be simple and portable because stable
kernels are wrecked.

> 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.

BTW, I see now that DPAUX I2C transfer helper may access
aux->drm_device. Hence v1 patch isn't correct anyways.

For now I'll try to test more the ad-hoc variant with Thomas and send it
as v2 if we won't have a better solution.

  reply	other threads:[~2021-11-12 14:32 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
2021-11-12 10:52                   ` Thierry Reding
2021-11-12 14:32                   ` Dmitry Osipenko [this message]
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=5ee3f964-39ec-f6e2-5a01-230532a8b17e@gmail.com \
    --to=digetx@gmail.com \
    --cc=airlied@linux.ie \
    --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=thierry.reding@gmail.com \
    --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.