diff options
author | Daniel Vetter <daniel.vetter@ffwll.ch> | 2017-01-25 09:26:47 +0300 |
---|---|---|
committer | Daniel Vetter <daniel.vetter@ffwll.ch> | 2017-01-25 18:22:42 +0300 |
commit | ef40cbf9998528e4f4457df52624d56ae95a7dee (patch) | |
tree | c1f53982ba584df5c47932e051ceb6757cbd5b8e /drivers/gpu/drm/drm_irq.c | |
parent | 940eba2d58a7dad5cb5dd90458c682e4d929e6f2 (diff) | |
download | linux-ef40cbf9998528e4f4457df52624d56ae95a7dee.tar.xz |
drm/core: Use recommened kerneldoc for struct member refs
I just learned that &struct_name.member_name works and looks pretty
even. It doesn't (yet) link to the member directly though, which would
be really good for big structures or vfunc tables (where the
per-member kerneldoc tends to be long).
Also some minor drive-by polish where it makes sense, I read a lot
of docs ...
v2: Review from Gustavo.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Gustavo Padovan <gustavo.padovan@collabora.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170125062657.19270-6-daniel.vetter@ffwll.ch
Diffstat (limited to 'drivers/gpu/drm/drm_irq.c')
-rw-r--r-- | drivers/gpu/drm/drm_irq.c | 19 |
1 files changed, 9 insertions, 10 deletions
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c index 88c69e71102e..87a85f976d40 100644 --- a/drivers/gpu/drm/drm_irq.c +++ b/drivers/gpu/drm/drm_irq.c @@ -95,7 +95,7 @@ static void store_vblank(struct drm_device *dev, unsigned int pipe, * * Only to be called from drm_crtc_vblank_on(). * - * Note: caller must hold dev->vbl_lock since this reads & writes + * Note: caller must hold &drm_device.vbl_lock since this reads & writes * device vblank fields. */ static void drm_reset_vblank_timestamp(struct drm_device *dev, unsigned int pipe) @@ -142,7 +142,7 @@ static void drm_reset_vblank_timestamp(struct drm_device *dev, unsigned int pipe * Only necessary when going from off->on, to account for frames we * didn't get an interrupt for. * - * Note: caller must hold dev->vbl_lock since this reads & writes + * Note: caller must hold &drm_device.vbl_lock since this reads & writes * device vblank fields. */ static void drm_update_vblank_count(struct drm_device *dev, unsigned int pipe, @@ -449,7 +449,7 @@ static void drm_irq_vgaarb_nokms(void *cookie, bool state) * * This is the simplified helper interface provided for drivers with no special * needs. Drivers which need to install interrupt handlers for multiple - * interrupts must instead set drm_device->irq_enabled to signal the DRM core + * interrupts must instead set &drm_device.irq_enabled to signal the DRM core * that vblank interrupts are available. * * Returns: @@ -519,7 +519,7 @@ EXPORT_SYMBOL(drm_irq_install); * Calls the driver's irq_uninstall() function and unregisters the IRQ handler. * This should only be called by drivers which used drm_irq_install() to set up * their interrupt handler. Other drivers must only reset - * drm_device->irq_enabled to false. + * &drm_device.irq_enabled to false. * * Note that for kernel modesetting drivers it is a bug if this function fails. * The sanity checks are only to catch buggy user modesetting drivers which call @@ -982,12 +982,11 @@ static void send_vblank_event(struct drm_device *dev, * period. This helper function implements exactly the required vblank arming * behaviour. * - * NOTE: Drivers using this to send out the event in &struct drm_crtc_state - * as part of an atomic commit must ensure that the next vblank happens at - * exactly the same time as the atomic commit is committed to the hardware. This - * function itself does **not** protect again the next vblank interrupt racing - * with either this function call or the atomic commit operation. A possible - * sequence could be: + * NOTE: Drivers using this to send out the &drm_crtc_state.event as part of an + * atomic commit must ensure that the next vblank happens at exactly the same + * time as the atomic commit is committed to the hardware. This function itself + * does **not** protect again the next vblank interrupt racing with either this + * function call or the atomic commit operation. A possible sequence could be: * * 1. Driver commits new hardware state into vblank-synchronized registers. * 2. A vblank happens, committing the hardware state. Also the corresponding |