From: Jani Nikula <jani.nikula@intel.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/irq: remove check on dev->dev_private
Date: Tue, 11 Feb 2020 18:42:49 +0200 [thread overview]
Message-ID: <874kvxyt12.fsf@intel.com> (raw)
In-Reply-To: <20200211151219.GF2363188@phenom.ffwll.local>
On Tue, 11 Feb 2020, Daniel Vetter <daniel@ffwll.ch> wrote:
> On Tue, Feb 11, 2020 at 04:47:53PM +0200, Jani Nikula wrote:
>> There is no real reason to require drivers to set and use
>> dev->dev_private. Indeed, the current recommendation, as documented in
>> drm_device.h, is to embed struct drm_device in the per-device struct
>> instead of using dev_private.
>>
>> Remove the requirement for dev_private to have been set to indicate
>> driver initialization.
>
> Yeah this is nonsense. Also, drm_irq_install is purely optional
> semi-midlayer (it's not really a midlayer for the legacy drivers, but
> whatever, who cares about those).
>
> Now there might be some hilarious races this papers over, but:
>
> - Proper drivers should only call drm_dev_register once everything is set
> up, including this stuff here. No race possible with anything else
> really.
>
> - Slightly more wobbly drivers, including the legacy ones, all use
> drm_global_mutex. This was the former BKL, which means that it was
> impossible for soeone to go through the load/unload/reload (between
> lastclose and firstopen) paths and also run the ioctl. But the ioctl had
> to be made unlocked because blocking there killed X:
>
> commit 8f4ff2b06afcd6f151868474a432c603057eaf56
> Author: Ilija Hadzic <ihadzic@research.bell-labs.com>
> Date: Mon Oct 31 17:46:18 2011 -0400
>
> drm: do not sleep on vblank while holding a mutex
>
> The even more legacy DRM_CONTROL ioctl stayed fully locked. But the file
> open/close paths are still fully locked, and that's the only place
> legacy drivers should call drm_irq_install/uninstall, so should all
> still be fully ordered and protected and happy.
>
> Feel free to quote or not quote the above in the commit message.
>
>> Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> Cc: Daniel Vetter <daniel@ffwll.ch>
>> Signed-off-by: Jani Nikula <jani.nikula@intel.com>
>>
>> ---
>>
>> Any ideas for something else drm_irq_install() could/should check to
>> ensure "Driver must have been initialized"?
>>
>> There are only a few instances of dev_private uses in i915, also to be
>> removed, and we could stop initializing dev_private altogether. We could
>> in fact do that without this patch too, as we don't use
>> drm_irq_install(). But it would be cleaner to not have any checks for
>> driver private stuff outside of drivers.
>
> I hope my review above answers your question here. Patch, as-is:
>
> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Many thanks, pushed to drm-misc-next with the details addded to commit
message.
BR,
Jani.
>
>> ---
>> drivers/gpu/drm/drm_irq.c | 4 ----
>> 1 file changed, 4 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
>> index 03bce566a8c3..588be45abd7a 100644
>> --- a/drivers/gpu/drm/drm_irq.c
>> +++ b/drivers/gpu/drm/drm_irq.c
>> @@ -111,10 +111,6 @@ int drm_irq_install(struct drm_device *dev, int irq)
>> if (irq == 0)
>> return -EINVAL;
>>
>> - /* Driver must have been initialized */
>> - if (!dev->dev_private)
>> - return -EINVAL;
>> -
>> if (dev->irq_enabled)
>> return -EBUSY;
>> dev->irq_enabled = true;
>> --
>> 2.20.1
>>
--
Jani Nikula, Intel Open Source Graphics Center
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
prev parent reply other threads:[~2020-02-11 16:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-11 14:47 [PATCH] drm/irq: remove check on dev->dev_private Jani Nikula
2020-02-11 15:12 ` Daniel Vetter
2020-02-11 16:42 ` Jani Nikula [this message]
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=874kvxyt12.fsf@intel.com \
--to=jani.nikula@intel.com \
--cc=daniel@ffwll.ch \
--cc=dri-devel@lists.freedesktop.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.