* [PATCH 01/28] drm: Polish fbdev helper struct docs
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 10:45 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 02/28] drm: Move LEAVE/ENTER_ATOMIC_MODESET to fbdev helpers Daniel Vetter
` (26 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter
Mostly this is just adding extensive docs for the callbacks, but also
a few other additions.
v2: Use FIXME comments to annotate helper hooks that should be
replaced.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
include/drm/drm_fb_helper.h | 92 ++++++++++++++++++++++++++++++++++++++-------
1 file changed, 79 insertions(+), 13 deletions(-)
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 87b090c4b730..5ce033e36039 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -74,25 +74,76 @@ struct drm_fb_helper_surface_size {
/**
* struct drm_fb_helper_funcs - driver callbacks for the fbdev emulation library
- * @gamma_set: Set the given gamma lut register on the given crtc.
- * @gamma_get: Read the given gamma lut register on the given crtc, used to
- * save the current lut when force-restoring the fbdev for e.g.
- * kdbg.
- * @fb_probe: Driver callback to allocate and initialize the fbdev info
- * structure. Furthermore it also needs to allocate the drm
- * framebuffer used to back the fbdev.
- * @initial_config: Setup an initial fbdev display configuration
*
* Driver callbacks used by the fbdev emulation helper library.
*/
struct drm_fb_helper_funcs {
+ /**
+ * @gamma_set:
+ *
+ * Set the given gamma lut register on the given crtc.
+ *
+ * This callback is optional.
+ *
+ * FIXME:
+ *
+ * This callback is functionally redundant with the core gamma table
+ * support and simply exists because the fbdev hasn't yet been
+ * refactored to use the core gamma table interfaces.
+ */
void (*gamma_set)(struct drm_crtc *crtc, u16 red, u16 green,
u16 blue, int regno);
+ /**
+ * @gamma_get:
+ *
+ * Read the given gamma lut register on the given crtc, used to save the
+ * current lut when force-restoring the fbdev for e.g. kdbg.
+ *
+ * This callback is optional.
+ *
+ * FIXME:
+ *
+ * This callback is functionally redundant with the core gamma table
+ * support and simply exists because the fbdev hasn't yet been
+ * refactored to use the core gamma table interfaces.
+ */
void (*gamma_get)(struct drm_crtc *crtc, u16 *red, u16 *green,
u16 *blue, int regno);
+ /**
+ * @fb_probe:
+ *
+ * Driver callback to allocate and initialize the fbdev info structure.
+ * Furthermore it also needs to allocate the drm framebuffer used to
+ * back the fbdev.
+ *
+ * This callback is mandatory.
+ *
+ * RETURNS:
+ *
+ * The driver should return 0 on success and a negative error code on
+ * failure.
+ */
int (*fb_probe)(struct drm_fb_helper *helper,
struct drm_fb_helper_surface_size *sizes);
+
+ /**
+ * @initial_config:
+ *
+ * Driver callback to setup an initial fbdev display configuration.
+ * Drivers can use this callback to tell the fbdev emulation what the
+ * preferred initial configuration is. This is useful to implement
+ * smooth booting where the fbdev (and subsequently all userspace) never
+ * changes the mode, but always inherits the existing configuration.
+ *
+ * This callback is optional.
+ *
+ * RETURNS:
+ *
+ * The driver should return true if a suitable initial configuration has
+ * been filled out and false when the fbdev helper should fall back to
+ * the default probing logic.
+ */
bool (*initial_config)(struct drm_fb_helper *fb_helper,
struct drm_fb_helper_crtc **crtcs,
struct drm_display_mode **modes,
@@ -105,18 +156,22 @@ struct drm_fb_helper_connector {
};
/**
- * struct drm_fb_helper - helper to emulate fbdev on top of kms
+ * struct drm_fb_helper - main structure to emulate fbdev on top of kms
* @fb: Scanout framebuffer object
* @dev: DRM device
* @crtc_count: number of possible CRTCs
* @crtc_info: per-CRTC helper state (mode, x/y offset, etc)
* @connector_count: number of connected connectors
* @connector_info_alloc_count: size of connector_info
+ * @connector_info: array of per-connector information
* @funcs: driver callbacks for fb helper
* @fbdev: emulated fbdev device info struct
* @pseudo_palette: fake palette of 16 colors
- * @kernel_fb_list: list_head in kernel_fb_helper_list
- * @delayed_hotplug: was there a hotplug while kms master active?
+ *
+ * This is the main structure used by the fbdev helpers. Drivers supporting
+ * fbdev emulation should embedded this into their overall driver structure.
+ * Drivers must also fill out a struct &drm_fb_helper_funcs with a few
+ * operations.
*/
struct drm_fb_helper {
struct drm_framebuffer *fb;
@@ -129,10 +184,21 @@ struct drm_fb_helper {
const struct drm_fb_helper_funcs *funcs;
struct fb_info *fbdev;
u32 pseudo_palette[17];
+
+ /**
+ * @kernel_fb_list:
+ *
+ * Entry on the global kernel_fb_helper_list, used for kgdb entry/exit.
+ */
struct list_head kernel_fb_list;
- /* we got a hotplug but fbdev wasn't running the console
- delay until next set_par */
+ /**
+ * @delayed_hotplug:
+ *
+ * A hotplug was received while fbdev wasn't in control of the drm
+ * device, i.e. another kms master was active. The output configuration
+ * needs to be reprobe when fbdev is in control again.
+ */
bool delayed_hotplug;
/**
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 01/28] drm: Polish fbdev helper struct docs
2015-12-04 8:45 ` [PATCH 01/28] drm: Polish fbdev helper struct docs Daniel Vetter
@ 2015-12-07 10:45 ` Thierry Reding
2015-12-07 11:50 ` Daniel Vetter
0 siblings, 1 reply; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 10:45 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 5198 bytes --]
On Fri, Dec 04, 2015 at 09:45:42AM +0100, Daniel Vetter wrote:
> Mostly this is just adding extensive docs for the callbacks, but also
> a few other additions.
>
> v2: Use FIXME comments to annotate helper hooks that should be
> replaced.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> include/drm/drm_fb_helper.h | 92 ++++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 79 insertions(+), 13 deletions(-)
>
> diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> index 87b090c4b730..5ce033e36039 100644
> --- a/include/drm/drm_fb_helper.h
> +++ b/include/drm/drm_fb_helper.h
> @@ -74,25 +74,76 @@ struct drm_fb_helper_surface_size {
>
> /**
> * struct drm_fb_helper_funcs - driver callbacks for the fbdev emulation library
> - * @gamma_set: Set the given gamma lut register on the given crtc.
> - * @gamma_get: Read the given gamma lut register on the given crtc, used to
> - * save the current lut when force-restoring the fbdev for e.g.
> - * kdbg.
> - * @fb_probe: Driver callback to allocate and initialize the fbdev info
> - * structure. Furthermore it also needs to allocate the drm
> - * framebuffer used to back the fbdev.
> - * @initial_config: Setup an initial fbdev display configuration
> *
> * Driver callbacks used by the fbdev emulation helper library.
> */
> struct drm_fb_helper_funcs {
> + /**
> + * @gamma_set:
> + *
> + * Set the given gamma lut register on the given crtc.
> + *
> + * This callback is optional.
> + *
> + * FIXME:
> + *
> + * This callback is functionally redundant with the core gamma table
> + * support and simply exists because the fbdev hasn't yet been
> + * refactored to use the core gamma table interfaces.
> + */
> void (*gamma_set)(struct drm_crtc *crtc, u16 red, u16 green,
> u16 blue, int regno);
Pardon my ignorance, but is there a way to document parameters with this
new syntax?
> + /**
> + * @gamma_get:
> + *
> + * Read the given gamma lut register on the given crtc, used to save the
> + * current lut when force-restoring the fbdev for e.g. kdbg.
> + *
> + * This callback is optional.
> + *
> + * FIXME:
> + *
> + * This callback is functionally redundant with the core gamma table
> + * support and simply exists because the fbdev hasn't yet been
> + * refactored to use the core gamma table interfaces.
> + */
> void (*gamma_get)(struct drm_crtc *crtc, u16 *red, u16 *green,
> u16 *blue, int regno);
Nit: While at it, perhaps (here and in the @gamma_set documentation):
s/lut/LUT/ and s/crtc/CRTC/?
>
> + /**
> + * @fb_probe:
> + *
> + * Driver callback to allocate and initialize the fbdev info structure.
> + * Furthermore it also needs to allocate the drm framebuffer used to
> + * back the fbdev.
> + *
> + * This callback is mandatory.
> + *
> + * RETURNS:
> + *
> + * The driver should return 0 on success and a negative error code on
> + * failure.
> + */
> int (*fb_probe)(struct drm_fb_helper *helper,
> struct drm_fb_helper_surface_size *sizes);
Nit: s/drm/DRM/
> /**
> - * struct drm_fb_helper - helper to emulate fbdev on top of kms
> + * struct drm_fb_helper - main structure to emulate fbdev on top of kms
s/kms/KMS
> * @fb: Scanout framebuffer object
> * @dev: DRM device
There seems to be an extra space between the : and the description. That
was already there, but maybe worth a follow-up.
> * @crtc_count: number of possible CRTCs
> * @crtc_info: per-CRTC helper state (mode, x/y offset, etc)
> * @connector_count: number of connected connectors
> * @connector_info_alloc_count: size of connector_info
> + * @connector_info: array of per-connector information
> * @funcs: driver callbacks for fb helper
> * @fbdev: emulated fbdev device info struct
> * @pseudo_palette: fake palette of 16 colors
> - * @kernel_fb_list: list_head in kernel_fb_helper_list
> - * @delayed_hotplug: was there a hotplug while kms master active?
> + *
> + * This is the main structure used by the fbdev helpers. Drivers supporting
> + * fbdev emulation should embedded this into their overall driver structure.
> + * Drivers must also fill out a struct &drm_fb_helper_funcs with a few
> + * operations.
> */
> struct drm_fb_helper {
> struct drm_framebuffer *fb;
> @@ -129,10 +184,21 @@ struct drm_fb_helper {
> const struct drm_fb_helper_funcs *funcs;
> struct fb_info *fbdev;
> u32 pseudo_palette[17];
> +
> + /**
> + * @kernel_fb_list:
> + *
> + * Entry on the global kernel_fb_helper_list, used for kgdb entry/exit.
> + */
> struct list_head kernel_fb_list;
>
> - /* we got a hotplug but fbdev wasn't running the console
> - delay until next set_par */
> + /**
> + * @delayed_hotplug:
> + *
> + * A hotplug was received while fbdev wasn't in control of the drm
> + * device, i.e. another kms master was active. The output configuration
> + * needs to be reprobe when fbdev is in control again.
s/drm/DRM/, s/kms/KMS/
Otherwise looks really good.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 01/28] drm: Polish fbdev helper struct docs
2015-12-07 10:45 ` Thierry Reding
@ 2015-12-07 11:50 ` Daniel Vetter
2015-12-07 11:53 ` Thierry Reding
0 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-07 11:50 UTC (permalink / raw)
To: Thierry Reding
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
On Mon, Dec 07, 2015 at 11:45:22AM +0100, Thierry Reding wrote:
> On Fri, Dec 04, 2015 at 09:45:42AM +0100, Daniel Vetter wrote:
> > Mostly this is just adding extensive docs for the callbacks, but also
> > a few other additions.
> >
> > v2: Use FIXME comments to annotate helper hooks that should be
> > replaced.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> > include/drm/drm_fb_helper.h | 92 ++++++++++++++++++++++++++++++++++++++-------
> > 1 file changed, 79 insertions(+), 13 deletions(-)
> >
> > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > index 87b090c4b730..5ce033e36039 100644
> > --- a/include/drm/drm_fb_helper.h
> > +++ b/include/drm/drm_fb_helper.h
> > @@ -74,25 +74,76 @@ struct drm_fb_helper_surface_size {
> >
> > /**
> > * struct drm_fb_helper_funcs - driver callbacks for the fbdev emulation library
> > - * @gamma_set: Set the given gamma lut register on the given crtc.
> > - * @gamma_get: Read the given gamma lut register on the given crtc, used to
> > - * save the current lut when force-restoring the fbdev for e.g.
> > - * kdbg.
> > - * @fb_probe: Driver callback to allocate and initialize the fbdev info
> > - * structure. Furthermore it also needs to allocate the drm
> > - * framebuffer used to back the fbdev.
> > - * @initial_config: Setup an initial fbdev display configuration
> > *
> > * Driver callbacks used by the fbdev emulation helper library.
> > */
> > struct drm_fb_helper_funcs {
> > + /**
> > + * @gamma_set:
> > + *
> > + * Set the given gamma lut register on the given crtc.
> > + *
> > + * This callback is optional.
> > + *
> > + * FIXME:
> > + *
> > + * This callback is functionally redundant with the core gamma table
> > + * support and simply exists because the fbdev hasn't yet been
> > + * refactored to use the core gamma table interfaces.
> > + */
> > void (*gamma_set)(struct drm_crtc *crtc, u16 red, u16 green,
> > u16 blue, int regno);
>
> Pardon my ignorance, but is there a way to document parameters with this
> new syntax?
Unfortunately not. Doing that would be quite a bit more rework of the
entire kerneldoc toolchain I think.
>
> > + /**
> > + * @gamma_get:
> > + *
> > + * Read the given gamma lut register on the given crtc, used to save the
> > + * current lut when force-restoring the fbdev for e.g. kdbg.
> > + *
> > + * This callback is optional.
> > + *
> > + * FIXME:
> > + *
> > + * This callback is functionally redundant with the core gamma table
> > + * support and simply exists because the fbdev hasn't yet been
> > + * refactored to use the core gamma table interfaces.
> > + */
> > void (*gamma_get)(struct drm_crtc *crtc, u16 *red, u16 *green,
> > u16 *blue, int regno);
>
> Nit: While at it, perhaps (here and in the @gamma_set documentation):
> s/lut/LUT/ and s/crtc/CRTC/?
Yeah I thought about our inconsistency wrt upper-case of abbrevations in
the docs. I think we should do this as a trivial patch thing for newbies.
> > + /**
> > + * @fb_probe:
> > + *
> > + * Driver callback to allocate and initialize the fbdev info structure.
> > + * Furthermore it also needs to allocate the drm framebuffer used to
> > + * back the fbdev.
> > + *
> > + * This callback is mandatory.
> > + *
> > + * RETURNS:
> > + *
> > + * The driver should return 0 on success and a negative error code on
> > + * failure.
> > + */
> > int (*fb_probe)(struct drm_fb_helper *helper,
> > struct drm_fb_helper_surface_size *sizes);
>
> Nit: s/drm/DRM/
>
> > /**
> > - * struct drm_fb_helper - helper to emulate fbdev on top of kms
> > + * struct drm_fb_helper - main structure to emulate fbdev on top of kms
>
> s/kms/KMS
>
> > * @fb: Scanout framebuffer object
> > * @dev: DRM device
>
> There seems to be an extra space between the : and the description. That
> was already there, but maybe worth a follow-up.
I think fix that up while applying, same for the others.
-Daniel
>
> > * @crtc_count: number of possible CRTCs
> > * @crtc_info: per-CRTC helper state (mode, x/y offset, etc)
> > * @connector_count: number of connected connectors
> > * @connector_info_alloc_count: size of connector_info
> > + * @connector_info: array of per-connector information
> > * @funcs: driver callbacks for fb helper
> > * @fbdev: emulated fbdev device info struct
> > * @pseudo_palette: fake palette of 16 colors
> > - * @kernel_fb_list: list_head in kernel_fb_helper_list
> > - * @delayed_hotplug: was there a hotplug while kms master active?
> > + *
> > + * This is the main structure used by the fbdev helpers. Drivers supporting
> > + * fbdev emulation should embedded this into their overall driver structure.
> > + * Drivers must also fill out a struct &drm_fb_helper_funcs with a few
> > + * operations.
> > */
> > struct drm_fb_helper {
> > struct drm_framebuffer *fb;
> > @@ -129,10 +184,21 @@ struct drm_fb_helper {
> > const struct drm_fb_helper_funcs *funcs;
> > struct fb_info *fbdev;
> > u32 pseudo_palette[17];
> > +
> > + /**
> > + * @kernel_fb_list:
> > + *
> > + * Entry on the global kernel_fb_helper_list, used for kgdb entry/exit.
> > + */
> > struct list_head kernel_fb_list;
> >
> > - /* we got a hotplug but fbdev wasn't running the console
> > - delay until next set_par */
> > + /**
> > + * @delayed_hotplug:
> > + *
> > + * A hotplug was received while fbdev wasn't in control of the drm
> > + * device, i.e. another kms master was active. The output configuration
> > + * needs to be reprobe when fbdev is in control again.
>
> s/drm/DRM/, s/kms/KMS/
>
> Otherwise looks really good.
>
> Thierry
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 01/28] drm: Polish fbdev helper struct docs
2015-12-07 11:50 ` Daniel Vetter
@ 2015-12-07 11:53 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:53 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
[-- Attachment #1.1: Type: text/plain, Size: 3814 bytes --]
On Mon, Dec 07, 2015 at 12:50:24PM +0100, Daniel Vetter wrote:
> On Mon, Dec 07, 2015 at 11:45:22AM +0100, Thierry Reding wrote:
> > On Fri, Dec 04, 2015 at 09:45:42AM +0100, Daniel Vetter wrote:
> > > Mostly this is just adding extensive docs for the callbacks, but also
> > > a few other additions.
> > >
> > > v2: Use FIXME comments to annotate helper hooks that should be
> > > replaced.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > > ---
> > > include/drm/drm_fb_helper.h | 92 ++++++++++++++++++++++++++++++++++++++-------
> > > 1 file changed, 79 insertions(+), 13 deletions(-)
> > >
> > > diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
> > > index 87b090c4b730..5ce033e36039 100644
> > > --- a/include/drm/drm_fb_helper.h
> > > +++ b/include/drm/drm_fb_helper.h
> > > @@ -74,25 +74,76 @@ struct drm_fb_helper_surface_size {
> > >
> > > /**
> > > * struct drm_fb_helper_funcs - driver callbacks for the fbdev emulation library
> > > - * @gamma_set: Set the given gamma lut register on the given crtc.
> > > - * @gamma_get: Read the given gamma lut register on the given crtc, used to
> > > - * save the current lut when force-restoring the fbdev for e.g.
> > > - * kdbg.
> > > - * @fb_probe: Driver callback to allocate and initialize the fbdev info
> > > - * structure. Furthermore it also needs to allocate the drm
> > > - * framebuffer used to back the fbdev.
> > > - * @initial_config: Setup an initial fbdev display configuration
> > > *
> > > * Driver callbacks used by the fbdev emulation helper library.
> > > */
> > > struct drm_fb_helper_funcs {
> > > + /**
> > > + * @gamma_set:
> > > + *
> > > + * Set the given gamma lut register on the given crtc.
> > > + *
> > > + * This callback is optional.
> > > + *
> > > + * FIXME:
> > > + *
> > > + * This callback is functionally redundant with the core gamma table
> > > + * support and simply exists because the fbdev hasn't yet been
> > > + * refactored to use the core gamma table interfaces.
> > > + */
> > > void (*gamma_set)(struct drm_crtc *crtc, u16 red, u16 green,
> > > u16 blue, int regno);
> >
> > Pardon my ignorance, but is there a way to document parameters with this
> > new syntax?
>
> Unfortunately not. Doing that would be quite a bit more rework of the
> entire kerneldoc toolchain I think.
Yes, that was my suspicion as well.
> > > + /**
> > > + * @gamma_get:
> > > + *
> > > + * Read the given gamma lut register on the given crtc, used to save the
> > > + * current lut when force-restoring the fbdev for e.g. kdbg.
> > > + *
> > > + * This callback is optional.
> > > + *
> > > + * FIXME:
> > > + *
> > > + * This callback is functionally redundant with the core gamma table
> > > + * support and simply exists because the fbdev hasn't yet been
> > > + * refactored to use the core gamma table interfaces.
> > > + */
> > > void (*gamma_get)(struct drm_crtc *crtc, u16 *red, u16 *green,
> > > u16 *blue, int regno);
> >
> > Nit: While at it, perhaps (here and in the @gamma_set documentation):
> > s/lut/LUT/ and s/crtc/CRTC/?
>
> Yeah I thought about our inconsistency wrt upper-case of abbrevations in
> the docs. I think we should do this as a trivial patch thing for newbies.
Fair enough.
Thierry
> > > * @fb: Scanout framebuffer object
> > > * @dev: DRM device
> >
> > There seems to be an extra space between the : and the description. That
> > was already there, but maybe worth a follow-up.
>
> I think fix that up while applying, same for the others.
Okay, either way, this is a good improvement, so:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 02/28] drm: Move LEAVE/ENTER_ATOMIC_MODESET to fbdev helpers
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
2015-12-04 8:45 ` [PATCH 01/28] drm: Polish fbdev helper struct docs Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 11:00 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 03/28] drm: Reorganize helper vtables and their docs Daniel Vetter
` (25 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development
This is only used for kgdb (and previously panic) handlers in
the fbdev emulation, so belongs there.
Note that this means we'll leave behind a forward declaration, but
once all the helper vtables are consolidated (in the next patch) that
will make more sense.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/nouveau/nv50_display.c | 1 +
include/drm/drm_crtc_helper.h | 5 +----
include/drm/drm_fb_helper.h | 5 +++++
3 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c b/drivers/gpu/drm/nouveau/nv50_display.c
index 12f23eede8c6..da277a69a859 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -28,6 +28,7 @@
#include <drm/drm_crtc_helper.h>
#include <drm/drm_plane_helper.h>
#include <drm/drm_dp_helper.h>
+#include <drm/drm_fb_helper.h>
#include <nvif/class.h>
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index e22ab29d2d00..26cc978f79e7 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -41,10 +41,7 @@
#include <drm/drm_crtc.h>
-enum mode_set_atomic {
- LEAVE_ATOMIC_MODE_SET,
- ENTER_ATOMIC_MODE_SET,
-};
+enum mode_set_atomic;
/**
* struct drm_crtc_helper_funcs - helper operations for CRTCs
diff --git a/include/drm/drm_fb_helper.h b/include/drm/drm_fb_helper.h
index 5ce033e36039..51782e765ed2 100644
--- a/include/drm/drm_fb_helper.h
+++ b/include/drm/drm_fb_helper.h
@@ -34,6 +34,11 @@ struct drm_fb_helper;
#include <linux/kgdb.h>
+enum mode_set_atomic {
+ LEAVE_ATOMIC_MODE_SET,
+ ENTER_ATOMIC_MODE_SET,
+};
+
struct drm_fb_offset {
int x, y;
};
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 02/28] drm: Move LEAVE/ENTER_ATOMIC_MODESET to fbdev helpers
2015-12-04 8:45 ` [PATCH 02/28] drm: Move LEAVE/ENTER_ATOMIC_MODESET to fbdev helpers Daniel Vetter
@ 2015-12-07 11:00 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:00 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 671 bytes --]
On Fri, Dec 04, 2015 at 09:45:43AM +0100, Daniel Vetter wrote:
> This is only used for kgdb (and previously panic) handlers in
> the fbdev emulation, so belongs there.
>
> Note that this means we'll leave behind a forward declaration, but
> once all the helper vtables are consolidated (in the next patch) that
> will make more sense.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/nouveau/nv50_display.c | 1 +
> include/drm/drm_crtc_helper.h | 5 +----
> include/drm/drm_fb_helper.h | 5 +++++
> 3 files changed, 7 insertions(+), 4 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 03/28] drm: Reorganize helper vtables and their docs
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
2015-12-04 8:45 ` [PATCH 01/28] drm: Polish fbdev helper struct docs Daniel Vetter
2015-12-04 8:45 ` [PATCH 02/28] drm: Move LEAVE/ENTER_ATOMIC_MODESET to fbdev helpers Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 11:00 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 04/28] drm: Make helper vtable pointers type-safe Daniel Vetter
` (24 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter
Currently we have 4 helper libraries (probe, crtc, plane & atomic)
that all use the same helper vtables. And that's by necessity since we
don't want to litter the core structs with one ops pointer per helper
library. Also often the reuse the same hooks (like atomic does, to
facilite conversion from existing drivers using crtc and plane
helpers).
Given all that it doesn't make sense to put the docs for these next to
specific helpers. Instead extract them into a new header file and
section in the docbook, and add references to them everywhere.
Unfortunately kernel-doc complains when an include directive doesn't
find anything (and it does by dumping crap into the output file). We
have to remove the now empty includes to avoid that, instead of leaving
them in for future proofing.
v2: More OCD in ordering functions.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
Documentation/DocBook/gpu.tmpl | 6 +-
drivers/gpu/drm/drm_atomic_helper.c | 6 +
drivers/gpu/drm/drm_crtc_helper.c | 5 +
drivers/gpu/drm/drm_plane_helper.c | 4 +
drivers/gpu/drm/drm_probe_helper.c | 3 +
include/drm/drm_crtc_helper.h | 158 +------------------
include/drm/drm_modeset_helper_vtables.h | 252 +++++++++++++++++++++++++++++++
include/drm/drm_plane_helper.h | 38 +----
8 files changed, 277 insertions(+), 195 deletions(-)
create mode 100644 include/drm/drm_modeset_helper_vtables.h
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index e6735d2b6ae8..9952d6ff052f 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -2303,8 +2303,12 @@ void intel_crt_init(struct drm_device *dev)
!Edrivers/gpu/drm/drm_atomic_helper.c
</sect2>
<sect2>
+ <title>Modeset Helper Reference for Common Vtables</title>
+!Iinclude/drm/drm_modeset_helper_vtables.h
+!Pinclude/drm/drm_modeset_helper_vtables.h overview
+ </sect2>
+ <sect2>
<title>Modeset Helper Functions Reference</title>
-!Iinclude/drm/drm_crtc_helper.h
!Edrivers/gpu/drm/drm_crtc_helper.c
!Pdrivers/gpu/drm/drm_crtc_helper.c overview
</sect2>
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index d9053ebf4903..2cf8ab7dbc8c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -52,6 +52,12 @@
* drm_atomic_helper_disable_plane(), drm_atomic_helper_disable_plane() and the
* various functions to implement set_property callbacks. New drivers must not
* implement these functions themselves but must use the provided helpers.
+ *
+ * The atomic helper uses the same function table structures as all other
+ * modesetting helpers. See the documentation for struct &drm_crtc_helper_funcs,
+ * struct &drm_encoder_helper_funcs and struct &drm_connector_helper_funcs. It
+ * also shares the struct &drm_plane_helper_funcs function table with the plane
+ * helpers.
*/
static void
drm_atomic_helper_plane_changed(struct drm_atomic_state *state,
diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index 10d0989db273..077e48d3cac2 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -62,6 +62,11 @@
* converting to the plane helpers). New drivers must not use these functions
* but need to implement the atomic interface instead, potentially using the
* atomic helpers for that.
+ *
+ * The these legacy modeset helpers use the same function table structures as
+ * all other modesetting helpers. See the documentation for struct
+ * &drm_crtc_helper_funcs, struct &drm_encoder_helper_funcs and struct
+ * &drm_connector_helper_funcs.
*/
MODULE_AUTHOR("David Airlie, Jesse Barnes");
MODULE_DESCRIPTION("DRM KMS helper");
diff --git a/drivers/gpu/drm/drm_plane_helper.c b/drivers/gpu/drm/drm_plane_helper.c
index a6983d41920d..8455e996dd9c 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -57,6 +57,10 @@
* by the atomic helpers.
*
* Again drivers are strongly urged to switch to the new interfaces.
+ *
+ * The plane helpers share the function table structures with other helpers,
+ * specifically also the atomic helpers. See struct &drm_plane_helper_funcs for
+ * the details.
*/
/*
diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index b7bdf12c54a5..dcd7c0289e03 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -53,6 +53,9 @@
* This helper library can be used independently of the modeset helper library.
* Drivers can also overwrite different parts e.g. use their own hotplug
* handling code to avoid probing unrelated outputs.
+ *
+ * The probe helpers share the function table structures with other display
+ * helper libraries. See struct &drm_connector_helper_funcs for the details.
*/
static bool drm_kms_helper_poll = true;
diff --git a/include/drm/drm_crtc_helper.h b/include/drm/drm_crtc_helper.h
index 26cc978f79e7..f94ff54ae25e 100644
--- a/include/drm/drm_crtc_helper.h
+++ b/include/drm/drm_crtc_helper.h
@@ -40,145 +40,7 @@
#include <linux/fb.h>
#include <drm/drm_crtc.h>
-
-enum mode_set_atomic;
-
-/**
- * struct drm_crtc_helper_funcs - helper operations for CRTCs
- * @dpms: set power state
- * @prepare: prepare the CRTC, called before @mode_set
- * @commit: commit changes to CRTC, called after @mode_set
- * @mode_fixup: try to fixup proposed mode for this CRTC
- * @mode_set: set this mode
- * @mode_set_nofb: set mode only (no scanout buffer attached)
- * @mode_set_base: update the scanout buffer
- * @mode_set_base_atomic: non-blocking mode set (used for kgdb support)
- * @load_lut: load color palette
- * @disable: disable CRTC when no longer in use
- * @enable: enable CRTC
- * @atomic_check: check for validity of an atomic state
- * @atomic_begin: begin atomic update
- * @atomic_flush: flush atomic update
- *
- * The helper operations are called by the mid-layer CRTC helper.
- *
- * Note that with atomic helpers @dpms, @prepare and @commit hooks are
- * deprecated. Used @enable and @disable instead exclusively.
- *
- * With legacy crtc helpers there's a big semantic difference between @disable
- * and the other hooks: @disable also needs to release any resources acquired in
- * @mode_set (like shared PLLs).
- */
-struct drm_crtc_helper_funcs {
- /*
- * Control power levels on the CRTC. If the mode passed in is
- * unsupported, the provider must use the next lowest power level.
- */
- void (*dpms)(struct drm_crtc *crtc, int mode);
- void (*prepare)(struct drm_crtc *crtc);
- void (*commit)(struct drm_crtc *crtc);
-
- /* Provider can fixup or change mode timings before modeset occurs */
- bool (*mode_fixup)(struct drm_crtc *crtc,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode);
- /* Actually set the mode */
- int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode, int x, int y,
- struct drm_framebuffer *old_fb);
- /* Actually set the mode for atomic helpers, optional */
- void (*mode_set_nofb)(struct drm_crtc *crtc);
-
- /* Move the crtc on the current fb to the given position *optional* */
- int (*mode_set_base)(struct drm_crtc *crtc, int x, int y,
- struct drm_framebuffer *old_fb);
- int (*mode_set_base_atomic)(struct drm_crtc *crtc,
- struct drm_framebuffer *fb, int x, int y,
- enum mode_set_atomic);
-
- /* reload the current crtc LUT */
- void (*load_lut)(struct drm_crtc *crtc);
-
- void (*disable)(struct drm_crtc *crtc);
- void (*enable)(struct drm_crtc *crtc);
-
- /* atomic helpers */
- int (*atomic_check)(struct drm_crtc *crtc,
- struct drm_crtc_state *state);
- void (*atomic_begin)(struct drm_crtc *crtc,
- struct drm_crtc_state *old_crtc_state);
- void (*atomic_flush)(struct drm_crtc *crtc,
- struct drm_crtc_state *old_crtc_state);
-};
-
-/**
- * struct drm_encoder_helper_funcs - helper operations for encoders
- * @dpms: set power state
- * @save: save connector state
- * @restore: restore connector state
- * @mode_fixup: try to fixup proposed mode for this connector
- * @prepare: part of the disable sequence, called before the CRTC modeset
- * @commit: called after the CRTC modeset
- * @mode_set: set this mode, optional for atomic helpers
- * @get_crtc: return CRTC that the encoder is currently attached to
- * @detect: connection status detection
- * @disable: disable encoder when not in use (overrides DPMS off)
- * @enable: enable encoder
- * @atomic_check: check for validity of an atomic update
- *
- * The helper operations are called by the mid-layer CRTC helper.
- *
- * Note that with atomic helpers @dpms, @prepare and @commit hooks are
- * deprecated. Used @enable and @disable instead exclusively.
- *
- * With legacy crtc helpers there's a big semantic difference between @disable
- * and the other hooks: @disable also needs to release any resources acquired in
- * @mode_set (like shared PLLs).
- */
-struct drm_encoder_helper_funcs {
- void (*dpms)(struct drm_encoder *encoder, int mode);
- void (*save)(struct drm_encoder *encoder);
- void (*restore)(struct drm_encoder *encoder);
-
- bool (*mode_fixup)(struct drm_encoder *encoder,
- const struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode);
- void (*prepare)(struct drm_encoder *encoder);
- void (*commit)(struct drm_encoder *encoder);
- void (*mode_set)(struct drm_encoder *encoder,
- struct drm_display_mode *mode,
- struct drm_display_mode *adjusted_mode);
- struct drm_crtc *(*get_crtc)(struct drm_encoder *encoder);
- /* detect for DAC style encoders */
- enum drm_connector_status (*detect)(struct drm_encoder *encoder,
- struct drm_connector *connector);
- void (*disable)(struct drm_encoder *encoder);
-
- void (*enable)(struct drm_encoder *encoder);
-
- /* atomic helpers */
- int (*atomic_check)(struct drm_encoder *encoder,
- struct drm_crtc_state *crtc_state,
- struct drm_connector_state *conn_state);
-};
-
-/**
- * struct drm_connector_helper_funcs - helper operations for connectors
- * @get_modes: get mode list for this connector
- * @mode_valid: is this mode valid on the given connector? (optional)
- * @best_encoder: return the preferred encoder for this connector
- * @atomic_best_encoder: atomic version of @best_encoder
- *
- * The helper operations are called by the mid-layer CRTC helper.
- */
-struct drm_connector_helper_funcs {
- int (*get_modes)(struct drm_connector *connector);
- enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
- struct drm_display_mode *mode);
- struct drm_encoder *(*best_encoder)(struct drm_connector *connector);
- struct drm_encoder *(*atomic_best_encoder)(struct drm_connector *connector,
- struct drm_connector_state *connector_state);
-};
+#include <drm/drm_modeset_helper_vtables.h>
extern void drm_helper_disable_unused_functions(struct drm_device *dev);
extern int drm_crtc_helper_set_config(struct drm_mode_set *set);
@@ -196,24 +58,6 @@ extern void drm_helper_move_panel_connectors_to_head(struct drm_device *);
extern void drm_helper_mode_fill_fb_struct(struct drm_framebuffer *fb,
const struct drm_mode_fb_cmd2 *mode_cmd);
-static inline void drm_crtc_helper_add(struct drm_crtc *crtc,
- const struct drm_crtc_helper_funcs *funcs)
-{
- crtc->helper_private = funcs;
-}
-
-static inline void drm_encoder_helper_add(struct drm_encoder *encoder,
- const struct drm_encoder_helper_funcs *funcs)
-{
- encoder->helper_private = funcs;
-}
-
-static inline void drm_connector_helper_add(struct drm_connector *connector,
- const struct drm_connector_helper_funcs *funcs)
-{
- connector->helper_private = funcs;
-}
-
extern void drm_helper_resume_force_mode(struct drm_device *dev);
int drm_helper_crtc_mode_set(struct drm_crtc *crtc, struct drm_display_mode *mode,
diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
new file mode 100644
index 000000000000..35c5a1c4e7ba
--- /dev/null
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -0,0 +1,252 @@
+/*
+ * Copyright © 2015 Intel Corporation
+ * Daniel Vetter <daniel.vetter@ffwll.ch>
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef __DRM_MODESET_HELPER_VTABLES_H__
+#define __DRM_MODESET_HELPER_VTABLES_H__
+
+#include <drm/drm_crtc.h>
+
+/**
+ * DOC: overview
+ *
+ * The DRM mode setting helper functions are common code for drivers to use if
+ * they wish. Drivers are not forced to use this code in their
+ * implementations but it would be useful if the code they do use at least
+ * provides a consistent interface and operation to userspace. Therefore it is
+ * highly recommended to use the provided helpers as much as possible.
+ *
+ * Because there is only one pointer per modeset object to hold a vfunc table
+ * for helper libraries they are by necessity shared among the different
+ * helpers.
+ *
+ * To make this clear all the helper vtables are pulled together in this location here.
+ */
+
+enum mode_set_atomic;
+
+/**
+ * struct drm_crtc_helper_funcs - helper operations for CRTCs
+ * @dpms: set power state
+ * @prepare: prepare the CRTC, called before @mode_set
+ * @commit: commit changes to CRTC, called after @mode_set
+ * @mode_fixup: try to fixup proposed mode for this CRTC
+ * @mode_set: set this mode
+ * @mode_set_nofb: set mode only (no scanout buffer attached)
+ * @mode_set_base: update the scanout buffer
+ * @mode_set_base_atomic: non-blocking mode set (used for kgdb support)
+ * @load_lut: load color palette
+ * @disable: disable CRTC when no longer in use
+ * @enable: enable CRTC
+ * @atomic_check: check for validity of an atomic state
+ * @atomic_begin: begin atomic update
+ * @atomic_flush: flush atomic update
+ *
+ * The helper operations are called by the mid-layer CRTC helper.
+ *
+ * Note that with atomic helpers @dpms, @prepare and @commit hooks are
+ * deprecated. Used @enable and @disable instead exclusively.
+ *
+ * With legacy crtc helpers there's a big semantic difference between @disable
+ * and the other hooks: @disable also needs to release any resources acquired in
+ * @mode_set (like shared PLLs).
+ */
+struct drm_crtc_helper_funcs {
+ /*
+ * Control power levels on the CRTC. If the mode passed in is
+ * unsupported, the provider must use the next lowest power level.
+ */
+ void (*dpms)(struct drm_crtc *crtc, int mode);
+ void (*prepare)(struct drm_crtc *crtc);
+ void (*commit)(struct drm_crtc *crtc);
+
+ /* Provider can fixup or change mode timings before modeset occurs */
+ bool (*mode_fixup)(struct drm_crtc *crtc,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode);
+ /* Actually set the mode */
+ int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode, int x, int y,
+ struct drm_framebuffer *old_fb);
+ /* Actually set the mode for atomic helpers, optional */
+ void (*mode_set_nofb)(struct drm_crtc *crtc);
+
+ /* Move the crtc on the current fb to the given position *optional* */
+ int (*mode_set_base)(struct drm_crtc *crtc, int x, int y,
+ struct drm_framebuffer *old_fb);
+ int (*mode_set_base_atomic)(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb, int x, int y,
+ enum mode_set_atomic);
+
+ /* reload the current crtc LUT */
+ void (*load_lut)(struct drm_crtc *crtc);
+
+ void (*disable)(struct drm_crtc *crtc);
+ void (*enable)(struct drm_crtc *crtc);
+
+ /* atomic helpers */
+ int (*atomic_check)(struct drm_crtc *crtc,
+ struct drm_crtc_state *state);
+ void (*atomic_begin)(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_crtc_state);
+ void (*atomic_flush)(struct drm_crtc *crtc,
+ struct drm_crtc_state *old_crtc_state);
+};
+
+/**
+ * drm_crtc_helper_add - sets the helper vtable for a crtc
+ * @crtc: DRM CRTC
+ * @funcs: helper vtable to set for @crtc
+ */
+static inline void drm_crtc_helper_add(struct drm_crtc *crtc,
+ const struct drm_crtc_helper_funcs *funcs)
+{
+ crtc->helper_private = funcs;
+}
+
+/**
+ * struct drm_encoder_helper_funcs - helper operations for encoders
+ * @dpms: set power state
+ * @save: save connector state
+ * @restore: restore connector state
+ * @mode_fixup: try to fixup proposed mode for this connector
+ * @prepare: part of the disable sequence, called before the CRTC modeset
+ * @commit: called after the CRTC modeset
+ * @mode_set: set this mode, optional for atomic helpers
+ * @get_crtc: return CRTC that the encoder is currently attached to
+ * @detect: connection status detection
+ * @disable: disable encoder when not in use (overrides DPMS off)
+ * @enable: enable encoder
+ * @atomic_check: check for validity of an atomic update
+ *
+ * The helper operations are called by the mid-layer CRTC helper.
+ *
+ * Note that with atomic helpers @dpms, @prepare and @commit hooks are
+ * deprecated. Used @enable and @disable instead exclusively.
+ *
+ * With legacy crtc helpers there's a big semantic difference between @disable
+ * and the other hooks: @disable also needs to release any resources acquired in
+ * @mode_set (like shared PLLs).
+ */
+struct drm_encoder_helper_funcs {
+ void (*dpms)(struct drm_encoder *encoder, int mode);
+ void (*save)(struct drm_encoder *encoder);
+ void (*restore)(struct drm_encoder *encoder);
+
+ bool (*mode_fixup)(struct drm_encoder *encoder,
+ const struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode);
+ void (*prepare)(struct drm_encoder *encoder);
+ void (*commit)(struct drm_encoder *encoder);
+ void (*mode_set)(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adjusted_mode);
+ struct drm_crtc *(*get_crtc)(struct drm_encoder *encoder);
+ /* detect for DAC style encoders */
+ enum drm_connector_status (*detect)(struct drm_encoder *encoder,
+ struct drm_connector *connector);
+ void (*disable)(struct drm_encoder *encoder);
+
+ void (*enable)(struct drm_encoder *encoder);
+
+ /* atomic helpers */
+ int (*atomic_check)(struct drm_encoder *encoder,
+ struct drm_crtc_state *crtc_state,
+ struct drm_connector_state *conn_state);
+};
+
+/**
+ * drm_encoder_helper_add - sets the helper vtable for a encoder
+ * @encoder: DRM encoder
+ * @funcs: helper vtable to set for @encoder
+ */
+static inline void drm_encoder_helper_add(struct drm_encoder *encoder,
+ const struct drm_encoder_helper_funcs *funcs)
+{
+ encoder->helper_private = funcs;
+}
+
+/**
+ * struct drm_connector_helper_funcs - helper operations for connectors
+ * @get_modes: get mode list for this connector
+ * @mode_valid: is this mode valid on the given connector? (optional)
+ * @best_encoder: return the preferred encoder for this connector
+ * @atomic_best_encoder: atomic version of @best_encoder
+ *
+ * The helper operations are called by the mid-layer CRTC helper.
+ */
+struct drm_connector_helper_funcs {
+ int (*get_modes)(struct drm_connector *connector);
+ enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
+ struct drm_display_mode *mode);
+ struct drm_encoder *(*best_encoder)(struct drm_connector *connector);
+ struct drm_encoder *(*atomic_best_encoder)(struct drm_connector *connector,
+ struct drm_connector_state *connector_state);
+};
+
+/**
+ * drm_connector_helper_add - sets the helper vtable for a connector
+ * @connector: DRM connector
+ * @funcs: helper vtable to set for @connector
+ */
+static inline void drm_connector_helper_add(struct drm_connector *connector,
+ const struct drm_connector_helper_funcs *funcs)
+{
+ connector->helper_private = funcs;
+}
+
+/**
+ * struct drm_plane_helper_funcs - helper operations for CRTCs
+ * @prepare_fb: prepare a framebuffer for use by the plane
+ * @cleanup_fb: cleanup a framebuffer when it's no longer used by the plane
+ * @atomic_check: check that a given atomic state is valid and can be applied
+ * @atomic_update: apply an atomic state to the plane (mandatory)
+ * @atomic_disable: disable the plane
+ *
+ * The helper operations are called by the mid-layer CRTC helper.
+ */
+struct drm_plane_helper_funcs {
+ int (*prepare_fb)(struct drm_plane *plane,
+ const struct drm_plane_state *new_state);
+ void (*cleanup_fb)(struct drm_plane *plane,
+ const struct drm_plane_state *old_state);
+
+ int (*atomic_check)(struct drm_plane *plane,
+ struct drm_plane_state *state);
+ void (*atomic_update)(struct drm_plane *plane,
+ struct drm_plane_state *old_state);
+ void (*atomic_disable)(struct drm_plane *plane,
+ struct drm_plane_state *old_state);
+};
+
+/**
+ * drm_plane_helper_add - sets the helper vtable for a plane
+ * @plane: DRM plane
+ * @funcs: helper vtable to set for @plane
+ */
+static inline void drm_plane_helper_add(struct drm_plane *plane,
+ const struct drm_plane_helper_funcs *funcs)
+{
+ plane->helper_private = funcs;
+}
+
+#endif
diff --git a/include/drm/drm_plane_helper.h b/include/drm/drm_plane_helper.h
index 5a7f9d4efb1d..4421f3f4ca8d 100644
--- a/include/drm/drm_plane_helper.h
+++ b/include/drm/drm_plane_helper.h
@@ -26,6 +26,7 @@
#include <drm/drm_rect.h>
#include <drm/drm_crtc.h>
+#include <drm/drm_modeset_helper_vtables.h>
/*
* Drivers that don't allow primary plane scaling may pass this macro in place
@@ -36,46 +37,9 @@
*/
#define DRM_PLANE_HELPER_NO_SCALING (1<<16)
-/**
- * DOC: plane helpers
- *
- * Helper functions to assist with creation and handling of CRTC primary
- * planes.
- */
-
int drm_crtc_init(struct drm_device *dev, struct drm_crtc *crtc,
const struct drm_crtc_funcs *funcs);
-/**
- * drm_plane_helper_funcs - helper operations for CRTCs
- * @prepare_fb: prepare a framebuffer for use by the plane
- * @cleanup_fb: cleanup a framebuffer when it's no longer used by the plane
- * @atomic_check: check that a given atomic state is valid and can be applied
- * @atomic_update: apply an atomic state to the plane (mandatory)
- * @atomic_disable: disable the plane
- *
- * The helper operations are called by the mid-layer CRTC helper.
- */
-struct drm_plane_helper_funcs {
- int (*prepare_fb)(struct drm_plane *plane,
- const struct drm_plane_state *new_state);
- void (*cleanup_fb)(struct drm_plane *plane,
- const struct drm_plane_state *old_state);
-
- int (*atomic_check)(struct drm_plane *plane,
- struct drm_plane_state *state);
- void (*atomic_update)(struct drm_plane *plane,
- struct drm_plane_state *old_state);
- void (*atomic_disable)(struct drm_plane *plane,
- struct drm_plane_state *old_state);
-};
-
-static inline void drm_plane_helper_add(struct drm_plane *plane,
- const struct drm_plane_helper_funcs *funcs)
-{
- plane->helper_private = funcs;
-}
-
int drm_plane_helper_check_update(struct drm_plane *plane,
struct drm_crtc *crtc,
struct drm_framebuffer *fb,
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 03/28] drm: Reorganize helper vtables and their docs
2015-12-04 8:45 ` [PATCH 03/28] drm: Reorganize helper vtables and their docs Daniel Vetter
@ 2015-12-07 11:00 ` Thierry Reding
2015-12-07 11:59 ` Daniel Vetter
0 siblings, 1 reply; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:00 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 4317 bytes --]
On Fri, Dec 04, 2015 at 09:45:44AM +0100, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
> index 10d0989db273..077e48d3cac2 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -62,6 +62,11 @@
> * converting to the plane helpers). New drivers must not use these functions
> * but need to implement the atomic interface instead, potentially using the
> * atomic helpers for that.
> + *
> + * The these legacy modeset helpers use the same function table structures as
s/The these/The/
> diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
> new file mode 100644
> index 000000000000..35c5a1c4e7ba
> --- /dev/null
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -0,0 +1,252 @@
> +/*
> + * Copyright © 2015 Intel Corporation
> + * Daniel Vetter <daniel.vetter@ffwll.ch>
Perhaps inherit the copyright statements from the includes that you
extracted these from?
> +/**
> + * DOC: overview
> + *
> + * The DRM mode setting helper functions are common code for drivers to use if
> + * they wish. Drivers are not forced to use this code in their
> + * implementations but it would be useful if the code they do use at least
> + * provides a consistent interface and operation to userspace. Therefore it is
> + * highly recommended to use the provided helpers as much as possible.
> + *
> + * Because there is only one pointer per modeset object to hold a vfunc table
> + * for helper libraries they are by necessity shared among the different
> + * helpers.
> + *
> + * To make this clear all the helper vtables are pulled together in this location here.
Perhaps drop the "here" at the end of that sentence. Also maybe wrap the
last line because it stands out as much longer than the above.
> + */
> +
> +enum mode_set_atomic;
> +
> +/**
> + * struct drm_crtc_helper_funcs - helper operations for CRTCs
> + * @dpms: set power state
> + * @prepare: prepare the CRTC, called before @mode_set
> + * @commit: commit changes to CRTC, called after @mode_set
> + * @mode_fixup: try to fixup proposed mode for this CRTC
> + * @mode_set: set this mode
> + * @mode_set_nofb: set mode only (no scanout buffer attached)
> + * @mode_set_base: update the scanout buffer
> + * @mode_set_base_atomic: non-blocking mode set (used for kgdb support)
> + * @load_lut: load color palette
> + * @disable: disable CRTC when no longer in use
> + * @enable: enable CRTC
> + * @atomic_check: check for validity of an atomic state
> + * @atomic_begin: begin atomic update
> + * @atomic_flush: flush atomic update
> + *
> + * The helper operations are called by the mid-layer CRTC helper.
> + *
> + * Note that with atomic helpers @dpms, @prepare and @commit hooks are
> + * deprecated. Used @enable and @disable instead exclusively.
I /think/ it would be more correct to say: "Use @enable and @disable
exclusively instead."
> + *
> + * With legacy crtc helpers there's a big semantic difference between @disable
s/crtc/CRTC/, there's a couple more places where the casing is
inconsistent, I'll refrain from pointing them out explicitly since your
editor will be much better at finding them.
> +/**
> + * struct drm_encoder_helper_funcs - helper operations for encoders
> + * @dpms: set power state
> + * @save: save connector state
> + * @restore: restore connector state
> + * @mode_fixup: try to fixup proposed mode for this connector
> + * @prepare: part of the disable sequence, called before the CRTC modeset
> + * @commit: called after the CRTC modeset
> + * @mode_set: set this mode, optional for atomic helpers
> + * @get_crtc: return CRTC that the encoder is currently attached to
> + * @detect: connection status detection
> + * @disable: disable encoder when not in use (overrides DPMS off)
> + * @enable: enable encoder
> + * @atomic_check: check for validity of an atomic update
> + *
> + * The helper operations are called by the mid-layer CRTC helper.
> + *
> + * Note that with atomic helpers @dpms, @prepare and @commit hooks are
> + * deprecated. Used @enable and @disable instead exclusively.
Same comment as for the CRTC helper functions.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH 03/28] drm: Reorganize helper vtables and their docs
2015-12-07 11:00 ` Thierry Reding
@ 2015-12-07 11:59 ` Daniel Vetter
2015-12-07 12:26 ` Thierry Reding
0 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-07 11:59 UTC (permalink / raw)
To: Thierry Reding
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
On Mon, Dec 07, 2015 at 12:00:09PM +0100, Thierry Reding wrote:
> On Fri, Dec 04, 2015 at 09:45:44AM +0100, Daniel Vetter wrote:
> [...]
> > diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
> > index 10d0989db273..077e48d3cac2 100644
> > --- a/drivers/gpu/drm/drm_crtc_helper.c
> > +++ b/drivers/gpu/drm/drm_crtc_helper.c
> > @@ -62,6 +62,11 @@
> > * converting to the plane helpers). New drivers must not use these functions
> > * but need to implement the atomic interface instead, potentially using the
> > * atomic helpers for that.
> > + *
> > + * The these legacy modeset helpers use the same function table structures as
>
> s/The these/The/
>
> > diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
> > new file mode 100644
> > index 000000000000..35c5a1c4e7ba
> > --- /dev/null
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -0,0 +1,252 @@
> > +/*
> > + * Copyright © 2015 Intel Corporation
> > + * Daniel Vetter <daniel.vetter@ffwll.ch>
>
> Perhaps inherit the copyright statements from the includes that you
> extracted these from?
Done for the above two - all the stuff below is just moved and would
conflict massively with later patches. So left that as per our irc
discussion.
-Daniel
>
> > +/**
> > + * DOC: overview
> > + *
> > + * The DRM mode setting helper functions are common code for drivers to use if
> > + * they wish. Drivers are not forced to use this code in their
> > + * implementations but it would be useful if the code they do use at least
> > + * provides a consistent interface and operation to userspace. Therefore it is
> > + * highly recommended to use the provided helpers as much as possible.
> > + *
> > + * Because there is only one pointer per modeset object to hold a vfunc table
> > + * for helper libraries they are by necessity shared among the different
> > + * helpers.
> > + *
> > + * To make this clear all the helper vtables are pulled together in this location here.
>
> Perhaps drop the "here" at the end of that sentence. Also maybe wrap the
> last line because it stands out as much longer than the above.
>
> > + */
> > +
> > +enum mode_set_atomic;
> > +
> > +/**
> > + * struct drm_crtc_helper_funcs - helper operations for CRTCs
> > + * @dpms: set power state
> > + * @prepare: prepare the CRTC, called before @mode_set
> > + * @commit: commit changes to CRTC, called after @mode_set
> > + * @mode_fixup: try to fixup proposed mode for this CRTC
> > + * @mode_set: set this mode
> > + * @mode_set_nofb: set mode only (no scanout buffer attached)
> > + * @mode_set_base: update the scanout buffer
> > + * @mode_set_base_atomic: non-blocking mode set (used for kgdb support)
> > + * @load_lut: load color palette
> > + * @disable: disable CRTC when no longer in use
> > + * @enable: enable CRTC
> > + * @atomic_check: check for validity of an atomic state
> > + * @atomic_begin: begin atomic update
> > + * @atomic_flush: flush atomic update
> > + *
> > + * The helper operations are called by the mid-layer CRTC helper.
> > + *
> > + * Note that with atomic helpers @dpms, @prepare and @commit hooks are
> > + * deprecated. Used @enable and @disable instead exclusively.
>
> I /think/ it would be more correct to say: "Use @enable and @disable
> exclusively instead."
>
> > + *
> > + * With legacy crtc helpers there's a big semantic difference between @disable
>
> s/crtc/CRTC/, there's a couple more places where the casing is
> inconsistent, I'll refrain from pointing them out explicitly since your
> editor will be much better at finding them.
>
> > +/**
> > + * struct drm_encoder_helper_funcs - helper operations for encoders
> > + * @dpms: set power state
> > + * @save: save connector state
> > + * @restore: restore connector state
> > + * @mode_fixup: try to fixup proposed mode for this connector
> > + * @prepare: part of the disable sequence, called before the CRTC modeset
> > + * @commit: called after the CRTC modeset
> > + * @mode_set: set this mode, optional for atomic helpers
> > + * @get_crtc: return CRTC that the encoder is currently attached to
> > + * @detect: connection status detection
> > + * @disable: disable encoder when not in use (overrides DPMS off)
> > + * @enable: enable encoder
> > + * @atomic_check: check for validity of an atomic update
> > + *
> > + * The helper operations are called by the mid-layer CRTC helper.
> > + *
> > + * Note that with atomic helpers @dpms, @prepare and @commit hooks are
> > + * deprecated. Used @enable and @disable instead exclusively.
>
> Same comment as for the CRTC helper functions.
>
> Thierry
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH 03/28] drm: Reorganize helper vtables and their docs
2015-12-07 11:59 ` Daniel Vetter
@ 2015-12-07 12:26 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 12:26 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
[-- Attachment #1.1: Type: text/plain, Size: 1557 bytes --]
On Mon, Dec 07, 2015 at 12:59:33PM +0100, Daniel Vetter wrote:
> On Mon, Dec 07, 2015 at 12:00:09PM +0100, Thierry Reding wrote:
> > On Fri, Dec 04, 2015 at 09:45:44AM +0100, Daniel Vetter wrote:
> > [...]
> > > diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
> > > index 10d0989db273..077e48d3cac2 100644
> > > --- a/drivers/gpu/drm/drm_crtc_helper.c
> > > +++ b/drivers/gpu/drm/drm_crtc_helper.c
> > > @@ -62,6 +62,11 @@
> > > * converting to the plane helpers). New drivers must not use these functions
> > > * but need to implement the atomic interface instead, potentially using the
> > > * atomic helpers for that.
> > > + *
> > > + * The these legacy modeset helpers use the same function table structures as
> >
> > s/The these/The/
> >
> > > diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
> > > new file mode 100644
> > > index 000000000000..35c5a1c4e7ba
> > > --- /dev/null
> > > +++ b/include/drm/drm_modeset_helper_vtables.h
> > > @@ -0,0 +1,252 @@
> > > +/*
> > > + * Copyright © 2015 Intel Corporation
> > > + * Daniel Vetter <daniel.vetter@ffwll.ch>
> >
> > Perhaps inherit the copyright statements from the includes that you
> > extracted these from?
>
> Done for the above two - all the stuff below is just moved and would
> conflict massively with later patches. So left that as per our irc
> discussion.
For the record, I'm fine with leave the below as-is and fix it up in a
follow-up patch.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 04/28] drm: Make helper vtable pointers type-safe
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (2 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 03/28] drm: Reorganize helper vtables and their docs Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 11:01 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 05/28] drm: Merge helper docbook into kerneldoc comments Daniel Vetter
` (23 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter
Originally the idea behind void* was to allow different sets of
helpers. But now we have that (with probe, plane, crtc and atomic
helpers) and we still just use the same set of vtables. That's the
only way to make the individual helpers modular and allow drivers to
pick&choose and transition between them. So this flexibility isn't
really needed. Also we have lots of non-vtable data meanwhile in core
structures too, this is not the first one at all.
Given that the void * is only trouble since gcc can't warn you if you
mix them up. Let's fix that and make them typesafe.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
include/drm/drm_crtc.h | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 4765df331002..e8f8e4e9a6a1 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -254,6 +254,11 @@ struct drm_plane;
struct drm_bridge;
struct drm_atomic_state;
+struct drm_crtc_helper_funcs;
+struct drm_encoder_helper_funcs;
+struct drm_connector_helper_funcs;
+struct drm_plane_helper_funcs;
+
/**
* struct drm_crtc_state - mutable CRTC state
* @crtc: backpointer to the CRTC
@@ -467,7 +472,7 @@ struct drm_crtc {
uint16_t *gamma_store;
/* if you are using the helper */
- const void *helper_private;
+ const struct drm_crtc_helper_funcs *helper_private;
struct drm_object_properties properties;
@@ -597,7 +602,7 @@ struct drm_encoder {
struct drm_crtc *crtc;
struct drm_bridge *bridge;
const struct drm_encoder_funcs *funcs;
- const void *helper_private;
+ const struct drm_encoder_helper_funcs *helper_private;
};
/* should we poll this connector for connects and disconnects */
@@ -702,7 +707,7 @@ struct drm_connector {
/* requested DPMS state */
int dpms;
- const void *helper_private;
+ const struct drm_connector_helper_funcs *helper_private;
/* forced on connector */
struct drm_cmdline_mode cmdline_mode;
@@ -870,7 +875,7 @@ struct drm_plane {
enum drm_plane_type type;
- const void *helper_private;
+ const struct drm_plane_helper_funcs *helper_private;
struct drm_plane_state *state;
};
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 04/28] drm: Make helper vtable pointers type-safe
2015-12-04 8:45 ` [PATCH 04/28] drm: Make helper vtable pointers type-safe Daniel Vetter
@ 2015-12-07 11:01 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:01 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 903 bytes --]
On Fri, Dec 04, 2015 at 09:45:45AM +0100, Daniel Vetter wrote:
> Originally the idea behind void* was to allow different sets of
> helpers. But now we have that (with probe, plane, crtc and atomic
> helpers) and we still just use the same set of vtables. That's the
> only way to make the individual helpers modular and allow drivers to
> pick&choose and transition between them. So this flexibility isn't
> really needed. Also we have lots of non-vtable data meanwhile in core
> structures too, this is not the first one at all.
>
> Given that the void * is only trouble since gcc can't warn you if you
> mix them up. Let's fix that and make them typesafe.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> include/drm/drm_crtc.h | 13 +++++++++----
> 1 file changed, 9 insertions(+), 4 deletions(-)
Very good:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 05/28] drm: Merge helper docbook into kerneldoc comments
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (3 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 04/28] drm: Make helper vtable pointers type-safe Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 11:15 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 06/28] drm/bridge: Improve kerneldoc Daniel Vetter
` (22 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter
Duplication is bad, luckily both help texts highlighted different
issues so the kerneldoc gained quite a bit!
While at it also sprinkle more references to the vtable structs around
and make it clear that legacy CRTC helpers are deprecated and which
functions to use instead.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
Documentation/DocBook/gpu.tmpl | 80 +-------------------------------------
drivers/gpu/drm/drm_crtc_helper.c | 47 +++++++++++++++++++---
drivers/gpu/drm/drm_probe_helper.c | 27 ++++++++++---
3 files changed, 65 insertions(+), 89 deletions(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 9952d6ff052f..8b298fc2dd4d 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1830,83 +1830,7 @@ void intel_crt_init(struct drm_device *dev)
entities.
</para>
<sect2>
- <title>Helper Functions</title>
- <itemizedlist>
- <listitem>
- <synopsis>int drm_crtc_helper_set_config(struct drm_mode_set *set);</synopsis>
- <para>
- The <function>drm_crtc_helper_set_config</function> helper function
- is a CRTC <methodname>set_config</methodname> implementation. It
- first tries to locate the best encoder for each connector by calling
- the connector <methodname>best_encoder</methodname> helper
- operation.
- </para>
- <para>
- After locating the appropriate encoders, the helper function will
- call the <methodname>mode_fixup</methodname> encoder and CRTC helper
- operations to adjust the requested mode, or reject it completely in
- which case an error will be returned to the application. If the new
- configuration after mode adjustment is identical to the current
- configuration the helper function will return without performing any
- other operation.
- </para>
- <para>
- If the adjusted mode is identical to the current mode but changes to
- the frame buffer need to be applied, the
- <function>drm_crtc_helper_set_config</function> function will call
- the CRTC <methodname>mode_set_base</methodname> helper operation. If
- the adjusted mode differs from the current mode, or if the
- <methodname>mode_set_base</methodname> helper operation is not
- provided, the helper function performs a full mode set sequence by
- calling the <methodname>prepare</methodname>,
- <methodname>mode_set</methodname> and
- <methodname>commit</methodname> CRTC and encoder helper operations,
- in that order.
- </para>
- </listitem>
- <listitem>
- <synopsis>void drm_helper_connector_dpms(struct drm_connector *connector, int mode);</synopsis>
- <para>
- The <function>drm_helper_connector_dpms</function> helper function
- is a connector <methodname>dpms</methodname> implementation that
- tracks power state of connectors. To use the function, drivers must
- provide <methodname>dpms</methodname> helper operations for CRTCs
- and encoders to apply the DPMS state to the device.
- </para>
- <para>
- The mid-layer doesn't track the power state of CRTCs and encoders.
- The <methodname>dpms</methodname> helper operations can thus be
- called with a mode identical to the currently active mode.
- </para>
- </listitem>
- <listitem>
- <synopsis>int drm_helper_probe_single_connector_modes(struct drm_connector *connector,
- uint32_t maxX, uint32_t maxY);</synopsis>
- <para>
- The <function>drm_helper_probe_single_connector_modes</function> helper
- function is a connector <methodname>fill_modes</methodname>
- implementation that updates the connection status for the connector
- and then retrieves a list of modes by calling the connector
- <methodname>get_modes</methodname> helper operation.
- </para>
- <para>
- If the helper operation returns no mode, and if the connector status
- is connector_status_connected, standard VESA DMT modes up to
- 1024x768 are automatically added to the modes list by a call to
- <function>drm_add_modes_noedid</function>.
- </para>
- <para>
- The function then filters out modes larger than
- <parameter>max_width</parameter> and <parameter>max_height</parameter>
- if specified. It finally calls the optional connector
- <methodname>mode_valid</methodname> helper operation for each mode in
- the probed list to check whether the mode is valid for the connector.
- </para>
- </listitem>
- </itemizedlist>
- </sect2>
- <sect2>
- <title>CRTC Helper Operations</title>
+ <title>Legacy CRTC Helper Operations</title>
<itemizedlist>
<listitem id="drm-helper-crtc-mode-fixup">
<synopsis>bool (*mode_fixup)(struct drm_crtc *crtc,
@@ -2308,7 +2232,7 @@ void intel_crt_init(struct drm_device *dev)
!Pinclude/drm/drm_modeset_helper_vtables.h overview
</sect2>
<sect2>
- <title>Modeset Helper Functions Reference</title>
+ <title>Legacy CRTC/Modeset Helper Functions Reference</title>
!Edrivers/gpu/drm/drm_crtc_helper.c
!Pdrivers/gpu/drm/drm_crtc_helper.c overview
</sect2>
diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
index 077e48d3cac2..c4fbcf8e6664 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -51,6 +51,11 @@
* the same callbacks which drivers can use to e.g. restore the modeset
* configuration on resume with drm_helper_resume_force_mode().
*
+ * Note that this helper library doesn't track the current power state of CRTCs
+ * and encoders. It can callbacks like ->dpms() even though the hardware is
+ * already in the desired state. This deficiency has been fixed in the atomic
+ * helpers.
+ *
* The driver callbacks are mostly compatible with the atomic modeset helpers,
* except for the handling of the primary plane: Atomic helpers require that the
* primary plane is implemented as a real standalone plane and not directly tied
@@ -450,11 +455,33 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
* drm_crtc_helper_set_config - set a new config from userspace
* @set: mode set configuration
*
- * Setup a new configuration, provided by the upper layers (either an ioctl call
- * from userspace or internally e.g. from the fbdev support code) in @set, and
- * enable it. This is the main helper functions for drivers that implement
- * kernel mode setting with the crtc helper functions and the assorted
- * ->prepare(), ->modeset() and ->commit() helper callbacks.
+ * The drm_crtc_helper_set_config() helper function implements the set_config
+ * callback of struct &drm_crtc_funcs for drivers using the legacy CRTC helpers.
+ *
+ * It first tries to locate the best encoder for each connector by calling the
+ * connector best_encoder (struct &drm_connector_helper_funcs) helper operation.
+ *
+ * After locating the appropriate encoders, the helper function will call the
+ * mode_fixup encoder and CRTC helper operations to adjust the requested mode,
+ * or reject it completely in which case an error will be returned to the
+ * application. If the new configuration after mode adjustment is identical to
+ * the current configuration the helper function will return without performing
+ * any other operation.
+ *
+ * If the adjusted mode is identical to the current mode but changes to the
+ * frame buffer need to be applied, the drm_crtc_helper_set_config function will
+ * call the CRTC mode_set_base (struct &drm_crtc_helper_funcs) helper operation.
+ *
+ * If the adjusted mode differs from the current mode, or if the mode_set_base
+ * helper operation is not provided, the helper function performs a full mode
+ * set sequence by calling the prepare, mode_set and commit CRTC and encoder
+ * helper operations, in that order. Alternatively it can also use the dpms and
+ * disable helper operations. For details see struct &drm_crtc_helper_funcs and
+ * struct &drm_encoder_helper_funcs.
+ *
+ * This function is deprecated. New drivers must implement atomic modeset
+ * support, for which this function is unsuitable. Instead drivers should use
+ * drm_atomic_helper_set_config().
*
* Returns:
* Returns 0 on success, negative errno numbers on failure.
@@ -763,10 +790,18 @@ static int drm_helper_choose_crtc_dpms(struct drm_crtc *crtc)
* @connector: affected connector
* @mode: DPMS mode
*
+ * The drm_helper_connector_dpms() helper function implements the dpms
+ * callback of struct &drm_connector_funcs for drivers using the legacy CRTC helpers.
+ *
* This is the main helper function provided by the crtc helper framework for
* implementing the DPMS connector attribute. It computes the new desired DPMS
* state for all encoders and crtcs in the output mesh and calls the ->dpms()
- * callback provided by the driver appropriately.
+ * callbacks provided by the driver in struct &drm_crtc_helper_funcs and struct
+ * &drm_encoder_helper_funcs appropriately.
+ *
+ * This function is deprecated. New drivers must implement atomic modeset
+ * support, for which this function is unsuitable. Instead drivers should use
+ * drm_atomic_helper_connector_dpms().
*
* Returns:
* Always returns 0.
diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
index dcd7c0289e03..62889249cbf8 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -272,15 +272,29 @@ prune:
* @maxX: max width for modes
* @maxY: max height for modes
*
- * Based on the helper callbacks implemented by @connector try to detect all
- * valid modes. Modes will first be added to the connector's probed_modes list,
- * then culled (based on validity and the @maxX, @maxY parameters) and put into
- * the normal modes list.
+ * Based on the helper callbacks implemented by @connector in struct
+ * &drm_connector_helper_funcs try to detect all valid modes. Modes will first
+ * be added to the connector's probed_modes list, then culled (based on validity
+ * and the @maxX, @maxY parameters) and put into the normal modes list.
*
* Intended to be use as a generic implementation of the ->fill_modes()
* @connector vfunc for drivers that use the crtc helpers for output mode
* filtering and detection.
*
+ * If the helper operation returns no mode, and if the connector status is
+ * connector_status_connected, standard VESA DMT modes up to 1024x768 are
+ * automatically added to the modes list by a call to
+ * drm_add_modes_noedid().
+ *
+ * The function then filters out modes larger than
+ * @maxX and maxY if specified. It finally calls the optional connector
+ * mode_valid helper operation for each mode in the probed list to check whether
+ * the mode is valid for the connector.
+ *
+ * Compared to drm_helper_probe_single_connector_modes_nomerge() this function
+ * merged the mode bits for the preferred mode, as a hack to work around some
+ * quirky issues on funky hardware.
+ *
* Returns:
* The number of modes found on @connector.
*/
@@ -297,8 +311,11 @@ EXPORT_SYMBOL(drm_helper_probe_single_connector_modes);
* @maxX: max width for modes
* @maxY: max height for modes
*
- * This operates like drm_hehlper_probe_single_connector_modes except it
+ * This operates like drm_hehlper_probe_single_connector_modes() except it
* replaces the mode bits instead of merging them for preferred modes.
+ *
+ * Returns:
+ * The number of modes found on @connector.
*/
int drm_helper_probe_single_connector_modes_nomerge(struct drm_connector *connector,
uint32_t maxX, uint32_t maxY)
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 05/28] drm: Merge helper docbook into kerneldoc comments
2015-12-04 8:45 ` [PATCH 05/28] drm: Merge helper docbook into kerneldoc comments Daniel Vetter
@ 2015-12-07 11:15 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:15 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 5377 bytes --]
On Fri, Dec 04, 2015 at 09:45:46AM +0100, Daniel Vetter wrote:
[...]
> diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c
> index 077e48d3cac2..c4fbcf8e6664 100644
> --- a/drivers/gpu/drm/drm_crtc_helper.c
> +++ b/drivers/gpu/drm/drm_crtc_helper.c
> @@ -51,6 +51,11 @@
> * the same callbacks which drivers can use to e.g. restore the modeset
> * configuration on resume with drm_helper_resume_force_mode().
> *
> + * Note that this helper library doesn't track the current power state of CRTCs
> + * and encoders. It can callbacks like ->dpms() even though the hardware is
Perhaps "It can {call,run,execute} callbacks like ->dpms() ..."
> @@ -450,11 +455,33 @@ drm_crtc_helper_disable(struct drm_crtc *crtc)
> * drm_crtc_helper_set_config - set a new config from userspace
> * @set: mode set configuration
> *
> - * Setup a new configuration, provided by the upper layers (either an ioctl call
> - * from userspace or internally e.g. from the fbdev support code) in @set, and
> - * enable it. This is the main helper functions for drivers that implement
> - * kernel mode setting with the crtc helper functions and the assorted
> - * ->prepare(), ->modeset() and ->commit() helper callbacks.
> + * The drm_crtc_helper_set_config() helper function implements the set_config
> + * callback of struct &drm_crtc_funcs for drivers using the legacy CRTC helpers.
> + *
> + * It first tries to locate the best encoder for each connector by calling the
> + * connector best_encoder (struct &drm_connector_helper_funcs) helper operation.
Perhaps "->best_encoder()"? Or is the above required to get formatting
right with the new hypertext/markdown additions?
> + *
> + * After locating the appropriate encoders, the helper function will call the
> + * mode_fixup encoder and CRTC helper operations to adjust the requested mode,
Again, "->mode_fixup()"?
> + * or reject it completely in which case an error will be returned to the
> + * application. If the new configuration after mode adjustment is identical to
> + * the current configuration the helper function will return without performing
> + * any other operation.
> + *
> + * If the adjusted mode is identical to the current mode but changes to the
> + * frame buffer need to be applied, the drm_crtc_helper_set_config function will
Parentheses after "drm_crtc_helper_set_config" to get it marked up as
function?
> + * call the CRTC mode_set_base (struct &drm_crtc_helper_funcs) helper operation.
"->mode_set_base()"?
> + *
> + * If the adjusted mode differs from the current mode, or if the mode_set_base
"->mode_set_base()"?
> + * helper operation is not provided, the helper function performs a full mode
> + * set sequence by calling the prepare, mode_set and commit CRTC and encoder
"->prepare(), ->mode_set() and ->commit()"?
> @@ -763,10 +790,18 @@ static int drm_helper_choose_crtc_dpms(struct drm_crtc *crtc)
> * @connector: affected connector
> * @mode: DPMS mode
> *
> + * The drm_helper_connector_dpms() helper function implements the dpms
"->dpms()"?
> + * callback of struct &drm_connector_funcs for drivers using the legacy CRTC helpers.
> + *
> * This is the main helper function provided by the crtc helper framework for
s/crtc/CRTC/?
> * implementing the DPMS connector attribute. It computes the new desired DPMS
> * state for all encoders and crtcs in the output mesh and calls the ->dpms()
s/crtcs/CRTCs/?
> - * callback provided by the driver appropriately.
> + * callbacks provided by the driver in struct &drm_crtc_helper_funcs and struct
> + * &drm_encoder_helper_funcs appropriately.
Perhaps s/appropriately./, respectively./?
> diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c
> index dcd7c0289e03..62889249cbf8 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -272,15 +272,29 @@ prune:
> * @maxX: max width for modes
> * @maxY: max height for modes
> *
> - * Based on the helper callbacks implemented by @connector try to detect all
> - * valid modes. Modes will first be added to the connector's probed_modes list,
> - * then culled (based on validity and the @maxX, @maxY parameters) and put into
> - * the normal modes list.
> + * Based on the helper callbacks implemented by @connector in struct
> + * &drm_connector_helper_funcs try to detect all valid modes. Modes will first
> + * be added to the connector's probed_modes list, then culled (based on validity
> + * and the @maxX, @maxY parameters) and put into the normal modes list.
> *
> * Intended to be use as a generic implementation of the ->fill_modes()
s/be use/be used/
> * @connector vfunc for drivers that use the crtc helpers for output mode
s/crtc/CRTC/
> * filtering and detection.
> *
> + * If the helper operation returns no mode, and if the connector status is
> + * connector_status_connected, standard VESA DMT modes up to 1024x768 are
> + * automatically added to the modes list by a call to
> + * drm_add_modes_noedid().
> + *
> + * The function then filters out modes larger than
Why wrap here? There's a lot of empty space left on the above line.
> + * @maxX and maxY if specified. It finally calls the optional connector
> + * mode_valid helper operation for each mode in the probed list to check whether
"->mode_valid()"?
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 06/28] drm/bridge: Improve kerneldoc
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (4 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 05/28] drm: Merge helper docbook into kerneldoc comments Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-04 10:43 ` Archit Taneja
2015-12-07 11:31 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 07/28] drm: Update drm_plane_funcs kerneldoc Daniel Vetter
` (21 subsequent siblings)
27 siblings, 2 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development
Especially document the assumptions and semantics of the callbacks
carefully. Just a warm-up excercise really.
v2: Spelling fixes (Eric).
v3: Consolidate more with existing docs:
- Remove the overview section explaining the bridge funcs, that's
now all in the drm_bridge_funcs kerneldoc in much more detail.
- Use & to reference structs so that kerneldoc automatically inserts
hyperlinks.
Cc: Eric Anholt <eric@anholt.net>
Cc: Archit Taneja <architt@codeaurora.org>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/drm_bridge.c | 69 +++++++++++------------------
include/drm/drm_crtc.h | 102 ++++++++++++++++++++++++++++++++++++++++---
2 files changed, 122 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
index 6b8f7211e543..26dd1cfb6078 100644
--- a/drivers/gpu/drm/drm_bridge.c
+++ b/drivers/gpu/drm/drm_bridge.c
@@ -31,14 +31,14 @@
/**
* DOC: overview
*
- * drm_bridge represents a device that hangs on to an encoder. These are handy
- * when a regular drm_encoder entity isn't enough to represent the entire
+ * struct &drm_bridge represents a device that hangs on to an encoder. These are
+ * handy when a regular &drm_encoder entity isn't enough to represent the entire
* encoder chain.
*
- * A bridge is always associated to a single drm_encoder at a time, but can be
+ * A bridge is always associated to a single &drm_encoder at a time, but can be
* either connected to it directly, or through an intermediate bridge:
*
- * encoder ---> bridge B ---> bridge A
+ * encoder ---> bridge B ---> bridge A
*
* Here, the output of the encoder feeds to bridge B, and that furthers feeds to
* bridge A.
@@ -46,11 +46,16 @@
* The driver using the bridge is responsible to make the associations between
* the encoder and bridges. Once these links are made, the bridges will
* participate along with encoder functions to perform mode_set/enable/disable
- * through the ops provided in drm_bridge_funcs.
+ * through the ops provided in &drm_bridge_funcs.
*
* drm_bridge, like drm_panel, aren't drm_mode_object entities like planes,
- * crtcs, encoders or connectors. They just provide additional hooks to get the
- * desired output at the end of the encoder chain.
+ * crtcs, encoders or connectors and hence are not visible to userspace. They
+ * just provide additional hooks to get the desired output at the end of the
+ * encoder chain.
+ *
+ * Bridges can also be chained up using the next pointer in struct &drm_bridge.
+ *
+ * Both legacy CRTC helpers and the new atomic modeset helpers support bridges.
*/
static DEFINE_MUTEX(bridge_lock);
@@ -122,34 +127,12 @@ EXPORT_SYMBOL(drm_bridge_attach);
/**
* DOC: bridge callbacks
*
- * The drm_bridge_funcs ops are populated by the bridge driver. The drm
- * internals(atomic and crtc helpers) use the helpers defined in drm_bridge.c
- * These helpers call a specific drm_bridge_funcs op for all the bridges
+ * The &drm_bridge_funcs ops are populated by the bridge driver. The drm
+ * internals (atomic and crtc helpers) use the helpers defined in drm_bridge.c
+ * These helpers call a specific &drm_bridge_funcs op for all the bridges
* during encoder configuration.
*
- * When creating a bridge driver, one can implement drm_bridge_funcs op with
- * the help of these rough rules:
- *
- * pre_enable: this contains things needed to be done for the bridge before
- * its clock and timings are enabled by its source. For a bridge, its source
- * is generally the encoder or bridge just before it in the encoder chain.
- *
- * enable: this contains things needed to be done for the bridge once its
- * source is enabled. In other words, enable is called once the source is
- * ready with clock and timing needed by the bridge.
- *
- * disable: this contains things needed to be done for the bridge assuming
- * that its source is still enabled, i.e. clock and timings are still on.
- *
- * post_disable: this contains things needed to be done for the bridge once
- * its source is disabled, i.e. once clocks and timings are off.
- *
- * mode_fixup: this should fixup the given mode for the bridge. It is called
- * after the encoder's mode fixup. mode_fixup can also reject a mode completely
- * if it's unsuitable for the hardware.
- *
- * mode_set: this sets up the mode for the bridge. It assumes that its source
- * (an encoder or a bridge) has set the mode too.
+ * For detailed specification of the bridge callbacks see &drm_bridge_funcs.
*/
/**
@@ -159,7 +142,7 @@ EXPORT_SYMBOL(drm_bridge_attach);
* @mode: desired mode to be set for the bridge
* @adjusted_mode: updated mode that works for this bridge
*
- * Calls 'mode_fixup' drm_bridge_funcs op for all the bridges in the
+ * Calls 'mode_fixup' &drm_bridge_funcs op for all the bridges in the
* encoder chain, starting from the first bridge to the last.
*
* Note: the bridge passed should be the one closest to the encoder
@@ -186,11 +169,11 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
EXPORT_SYMBOL(drm_bridge_mode_fixup);
/**
- * drm_bridge_disable - calls 'disable' drm_bridge_funcs op for all
+ * drm_bridge_disable - calls 'disable' &drm_bridge_funcs op for all
* bridges in the encoder chain.
* @bridge: bridge control structure
*
- * Calls 'disable' drm_bridge_funcs op for all the bridges in the encoder
+ * Calls 'disable' &drm_bridge_funcs op for all the bridges in the encoder
* chain, starting from the last bridge to the first. These are called before
* calling the encoder's prepare op.
*
@@ -208,11 +191,11 @@ void drm_bridge_disable(struct drm_bridge *bridge)
EXPORT_SYMBOL(drm_bridge_disable);
/**
- * drm_bridge_post_disable - calls 'post_disable' drm_bridge_funcs op for
+ * drm_bridge_post_disable - calls 'post_disable' &drm_bridge_funcs op for
* all bridges in the encoder chain.
* @bridge: bridge control structure
*
- * Calls 'post_disable' drm_bridge_funcs op for all the bridges in the
+ * Calls 'post_disable' &drm_bridge_funcs op for all the bridges in the
* encoder chain, starting from the first bridge to the last. These are called
* after completing the encoder's prepare op.
*
@@ -236,7 +219,7 @@ EXPORT_SYMBOL(drm_bridge_post_disable);
* @mode: desired mode to be set for the bridge
* @adjusted_mode: updated mode that works for this bridge
*
- * Calls 'mode_set' drm_bridge_funcs op for all the bridges in the
+ * Calls 'mode_set' &drm_bridge_funcs op for all the bridges in the
* encoder chain, starting from the first bridge to the last.
*
* Note: the bridge passed should be the one closest to the encoder
@@ -256,11 +239,11 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
EXPORT_SYMBOL(drm_bridge_mode_set);
/**
- * drm_bridge_pre_enable - calls 'pre_enable' drm_bridge_funcs op for all
+ * drm_bridge_pre_enable - calls 'pre_enable' &drm_bridge_funcs op for all
* bridges in the encoder chain.
* @bridge: bridge control structure
*
- * Calls 'pre_enable' drm_bridge_funcs op for all the bridges in the encoder
+ * Calls 'pre_enable' &drm_bridge_funcs op for all the bridges in the encoder
* chain, starting from the last bridge to the first. These are called
* before calling the encoder's commit op.
*
@@ -278,11 +261,11 @@ void drm_bridge_pre_enable(struct drm_bridge *bridge)
EXPORT_SYMBOL(drm_bridge_pre_enable);
/**
- * drm_bridge_enable - calls 'enable' drm_bridge_funcs op for all bridges
+ * drm_bridge_enable - calls 'enable' &drm_bridge_funcs op for all bridges
* in the encoder chain.
* @bridge: bridge control structure
*
- * Calls 'enable' drm_bridge_funcs op for all the bridges in the encoder
+ * Calls 'enable' &drm_bridge_funcs op for all the bridges in the encoder
* chain, starting from the first bridge to the last. These are called
* after completing the encoder's commit op.
*
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index e8f8e4e9a6a1..ec3632e62b3f 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -883,24 +883,114 @@ struct drm_plane {
/**
* struct drm_bridge_funcs - drm_bridge control functions
* @attach: Called during drm_bridge_attach
- * @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
- * @disable: Called right before encoder prepare, disables the bridge
- * @post_disable: Called right after encoder prepare, for lockstepped disable
- * @mode_set: Set this mode to the bridge
- * @pre_enable: Called right before encoder commit, for lockstepped commit
- * @enable: Called right after encoder commit, enables the bridge
*/
struct drm_bridge_funcs {
int (*attach)(struct drm_bridge *bridge);
+
+ /**
+ * @mode_fixup:
+ *
+ * This callback is used to validate and adjust a mode. The paramater
+ * mode is the display mode that should be fed to the next element in
+ * the display chain, either the final &drm_connector or the next
+ * &drm_bridge. The parameter adjusted_mode is the input mode the bridge
+ * requires. It can be modified by this callback and does not need to
+ * match mode.
+ *
+ * This is the only hook that allows a bridge to reject a modeset. If
+ * this function passes all other callbacks must succeed for this
+ * configuration.
+ *
+ * NOTE:
+ *
+ * This function is called in the check phase of atomic modesets, which
+ * can be aborted for any reason (including on userspace's request to
+ * just check whether a configuration would be possible). Drivers MUST
+ * NOT touch any persistent state (hardware or software) or data
+ * structures except the passed in adjusted_mode parameter.
+ *
+ * RETURNS:
+ *
+ * True if an acceptable configuration is possible, false if the modeset
+ * operation should be rejected.
+ */
bool (*mode_fixup)(struct drm_bridge *bridge,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+ /**
+ * @disable:
+ *
+ * This callback should disable the bridge. It is called right before
+ * the preceding element in the display pipe is disabled. If the
+ * preceding element is a bridge this means it's called before that
+ * bridge's ->disaable function. If the preceding element is a
+ * &drm_encoder it's called right before the encoder's ->disable,
+ * ->prepare or ->dpms hook from struct &drm_encoder_helper_funcs.
+ *
+ * The bridge can assume that the display pipe (i.e. clocks and timing
+ * signals) feeding it is still running when this callback is called.
+ */
void (*disable)(struct drm_bridge *bridge);
+
+ /**
+ * @post_disable:
+ *
+ * This callback should disable the bridge. It is called right after
+ * the preceding element in the display pipe is disabled. If the
+ * preceding element is a bridge this means it's called after that
+ * bridge's ->post_disaable function. If the preceding element is a
+ * &drm_encoder it's called right after the encoder's ->disable,
+ * ->prepare or ->dpms hook from struct &drm_encoder_helper_funcs.
+ *
+ * The bridge must assume that the display pipe (i.e. clocks and timing
+ * singals) feeding it is no longer running when this callback is
+ * called.
+ */
void (*post_disable)(struct drm_bridge *bridge);
+
+ /**
+ * @mode_set:
+ *
+ * This callback should set the given mode on the bridge. It is called
+ * after the ->mode_set callback for the preceding element in the
+ * display pipeline has been called already. The display pipe (i.e.
+ * clocks and timing signals) is off when this function is called.
+ */
void (*mode_set)(struct drm_bridge *bridge,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+ /**
+ * @pre_enable:
+ *
+ * This callback should enable the bridge. It is called right before
+ * the preceding element in the display pipe is enabled. If the
+ * preceding element is a bridge this means it's called before that
+ * bridge's ->pre_enable function. If the preceding element is a
+ * &drm_encoder it's called right before the encoder's ->enable,
+ * ->commit or ->dpms hook from struct &drm_encoder_helper_funcs.
+ *
+ * The display pipe (i.e. clocks and timing signals) feeding this bridge
+ * will not yet be running when this callback is called. The bridge must
+ * not enable the display link feeding the next bridge in the chain (if
+ * there is one) when this callback is called.
+ */
void (*pre_enable)(struct drm_bridge *bridge);
+
+ /**
+ * @enable:
+ *
+ * This callback should enable the bridge. It is called right after
+ * the preceding element in the display pipe is enabled. If the
+ * preceding element is a bridge this means it's called after that
+ * bridge's ->enable function. If the preceding element is a
+ * &drm_encoder it's called right after the encoder's ->enable,
+ * ->commit or ->dpms hook from struct &drm_encoder_helper_funcs.
+ *
+ * The bridge can assume that the display pipe (i.e. clocks and timing
+ * signals) feeding it is running when this callback is called. This
+ * callback must enable the display link feeding the next bridge in the
+ * chain if there is one.
+ */
void (*enable)(struct drm_bridge *bridge);
};
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 06/28] drm/bridge: Improve kerneldoc
2015-12-04 8:45 ` [PATCH 06/28] drm/bridge: Improve kerneldoc Daniel Vetter
@ 2015-12-04 10:43 ` Archit Taneja
2015-12-07 11:31 ` Thierry Reding
1 sibling, 0 replies; 81+ messages in thread
From: Archit Taneja @ 2015-12-04 10:43 UTC (permalink / raw)
To: Daniel Vetter, DRI Development; +Cc: Eric Anholt, Intel Graphics Development
On 12/04/2015 02:15 PM, Daniel Vetter wrote:
> Especially document the assumptions and semantics of the callbacks
> carefully. Just a warm-up excercise really.
>
> v2: Spelling fixes (Eric).
>
> v3: Consolidate more with existing docs:
>
> - Remove the overview section explaining the bridge funcs, that's
> now all in the drm_bridge_funcs kerneldoc in much more detail.
>
> - Use & to reference structs so that kerneldoc automatically inserts
> hyperlinks.
Reviewed-by: Archit Taneja <architt@codeaurora.org>
>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Archit Taneja <architt@codeaurora.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/drm_bridge.c | 69 +++++++++++------------------
> include/drm/drm_crtc.h | 102 ++++++++++++++++++++++++++++++++++++++++---
> 2 files changed, 122 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 6b8f7211e543..26dd1cfb6078 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -31,14 +31,14 @@
> /**
> * DOC: overview
> *
> - * drm_bridge represents a device that hangs on to an encoder. These are handy
> - * when a regular drm_encoder entity isn't enough to represent the entire
> + * struct &drm_bridge represents a device that hangs on to an encoder. These are
> + * handy when a regular &drm_encoder entity isn't enough to represent the entire
> * encoder chain.
> *
> - * A bridge is always associated to a single drm_encoder at a time, but can be
> + * A bridge is always associated to a single &drm_encoder at a time, but can be
> * either connected to it directly, or through an intermediate bridge:
> *
> - * encoder ---> bridge B ---> bridge A
> + * encoder ---> bridge B ---> bridge A
> *
> * Here, the output of the encoder feeds to bridge B, and that furthers feeds to
> * bridge A.
> @@ -46,11 +46,16 @@
> * The driver using the bridge is responsible to make the associations between
> * the encoder and bridges. Once these links are made, the bridges will
> * participate along with encoder functions to perform mode_set/enable/disable
> - * through the ops provided in drm_bridge_funcs.
> + * through the ops provided in &drm_bridge_funcs.
> *
> * drm_bridge, like drm_panel, aren't drm_mode_object entities like planes,
> - * crtcs, encoders or connectors. They just provide additional hooks to get the
> - * desired output at the end of the encoder chain.
> + * crtcs, encoders or connectors and hence are not visible to userspace. They
> + * just provide additional hooks to get the desired output at the end of the
> + * encoder chain.
> + *
> + * Bridges can also be chained up using the next pointer in struct &drm_bridge.
> + *
> + * Both legacy CRTC helpers and the new atomic modeset helpers support bridges.
> */
>
> static DEFINE_MUTEX(bridge_lock);
> @@ -122,34 +127,12 @@ EXPORT_SYMBOL(drm_bridge_attach);
> /**
> * DOC: bridge callbacks
> *
> - * The drm_bridge_funcs ops are populated by the bridge driver. The drm
> - * internals(atomic and crtc helpers) use the helpers defined in drm_bridge.c
> - * These helpers call a specific drm_bridge_funcs op for all the bridges
> + * The &drm_bridge_funcs ops are populated by the bridge driver. The drm
> + * internals (atomic and crtc helpers) use the helpers defined in drm_bridge.c
> + * These helpers call a specific &drm_bridge_funcs op for all the bridges
> * during encoder configuration.
> *
> - * When creating a bridge driver, one can implement drm_bridge_funcs op with
> - * the help of these rough rules:
> - *
> - * pre_enable: this contains things needed to be done for the bridge before
> - * its clock and timings are enabled by its source. For a bridge, its source
> - * is generally the encoder or bridge just before it in the encoder chain.
> - *
> - * enable: this contains things needed to be done for the bridge once its
> - * source is enabled. In other words, enable is called once the source is
> - * ready with clock and timing needed by the bridge.
> - *
> - * disable: this contains things needed to be done for the bridge assuming
> - * that its source is still enabled, i.e. clock and timings are still on.
> - *
> - * post_disable: this contains things needed to be done for the bridge once
> - * its source is disabled, i.e. once clocks and timings are off.
> - *
> - * mode_fixup: this should fixup the given mode for the bridge. It is called
> - * after the encoder's mode fixup. mode_fixup can also reject a mode completely
> - * if it's unsuitable for the hardware.
> - *
> - * mode_set: this sets up the mode for the bridge. It assumes that its source
> - * (an encoder or a bridge) has set the mode too.
> + * For detailed specification of the bridge callbacks see &drm_bridge_funcs.
> */
>
> /**
> @@ -159,7 +142,7 @@ EXPORT_SYMBOL(drm_bridge_attach);
> * @mode: desired mode to be set for the bridge
> * @adjusted_mode: updated mode that works for this bridge
> *
> - * Calls 'mode_fixup' drm_bridge_funcs op for all the bridges in the
> + * Calls 'mode_fixup' &drm_bridge_funcs op for all the bridges in the
> * encoder chain, starting from the first bridge to the last.
> *
> * Note: the bridge passed should be the one closest to the encoder
> @@ -186,11 +169,11 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
> EXPORT_SYMBOL(drm_bridge_mode_fixup);
>
> /**
> - * drm_bridge_disable - calls 'disable' drm_bridge_funcs op for all
> + * drm_bridge_disable - calls 'disable' &drm_bridge_funcs op for all
> * bridges in the encoder chain.
> * @bridge: bridge control structure
> *
> - * Calls 'disable' drm_bridge_funcs op for all the bridges in the encoder
> + * Calls 'disable' &drm_bridge_funcs op for all the bridges in the encoder
> * chain, starting from the last bridge to the first. These are called before
> * calling the encoder's prepare op.
> *
> @@ -208,11 +191,11 @@ void drm_bridge_disable(struct drm_bridge *bridge)
> EXPORT_SYMBOL(drm_bridge_disable);
>
> /**
> - * drm_bridge_post_disable - calls 'post_disable' drm_bridge_funcs op for
> + * drm_bridge_post_disable - calls 'post_disable' &drm_bridge_funcs op for
> * all bridges in the encoder chain.
> * @bridge: bridge control structure
> *
> - * Calls 'post_disable' drm_bridge_funcs op for all the bridges in the
> + * Calls 'post_disable' &drm_bridge_funcs op for all the bridges in the
> * encoder chain, starting from the first bridge to the last. These are called
> * after completing the encoder's prepare op.
> *
> @@ -236,7 +219,7 @@ EXPORT_SYMBOL(drm_bridge_post_disable);
> * @mode: desired mode to be set for the bridge
> * @adjusted_mode: updated mode that works for this bridge
> *
> - * Calls 'mode_set' drm_bridge_funcs op for all the bridges in the
> + * Calls 'mode_set' &drm_bridge_funcs op for all the bridges in the
> * encoder chain, starting from the first bridge to the last.
> *
> * Note: the bridge passed should be the one closest to the encoder
> @@ -256,11 +239,11 @@ void drm_bridge_mode_set(struct drm_bridge *bridge,
> EXPORT_SYMBOL(drm_bridge_mode_set);
>
> /**
> - * drm_bridge_pre_enable - calls 'pre_enable' drm_bridge_funcs op for all
> + * drm_bridge_pre_enable - calls 'pre_enable' &drm_bridge_funcs op for all
> * bridges in the encoder chain.
> * @bridge: bridge control structure
> *
> - * Calls 'pre_enable' drm_bridge_funcs op for all the bridges in the encoder
> + * Calls 'pre_enable' &drm_bridge_funcs op for all the bridges in the encoder
> * chain, starting from the last bridge to the first. These are called
> * before calling the encoder's commit op.
> *
> @@ -278,11 +261,11 @@ void drm_bridge_pre_enable(struct drm_bridge *bridge)
> EXPORT_SYMBOL(drm_bridge_pre_enable);
>
> /**
> - * drm_bridge_enable - calls 'enable' drm_bridge_funcs op for all bridges
> + * drm_bridge_enable - calls 'enable' &drm_bridge_funcs op for all bridges
> * in the encoder chain.
> * @bridge: bridge control structure
> *
> - * Calls 'enable' drm_bridge_funcs op for all the bridges in the encoder
> + * Calls 'enable' &drm_bridge_funcs op for all the bridges in the encoder
> * chain, starting from the first bridge to the last. These are called
> * after completing the encoder's commit op.
> *
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index e8f8e4e9a6a1..ec3632e62b3f 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -883,24 +883,114 @@ struct drm_plane {
> /**
> * struct drm_bridge_funcs - drm_bridge control functions
> * @attach: Called during drm_bridge_attach
> - * @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
> - * @disable: Called right before encoder prepare, disables the bridge
> - * @post_disable: Called right after encoder prepare, for lockstepped disable
> - * @mode_set: Set this mode to the bridge
> - * @pre_enable: Called right before encoder commit, for lockstepped commit
> - * @enable: Called right after encoder commit, enables the bridge
> */
> struct drm_bridge_funcs {
> int (*attach)(struct drm_bridge *bridge);
> +
> + /**
> + * @mode_fixup:
> + *
> + * This callback is used to validate and adjust a mode. The paramater
> + * mode is the display mode that should be fed to the next element in
> + * the display chain, either the final &drm_connector or the next
> + * &drm_bridge. The parameter adjusted_mode is the input mode the bridge
> + * requires. It can be modified by this callback and does not need to
> + * match mode.
> + *
> + * This is the only hook that allows a bridge to reject a modeset. If
> + * this function passes all other callbacks must succeed for this
> + * configuration.
> + *
> + * NOTE:
> + *
> + * This function is called in the check phase of atomic modesets, which
> + * can be aborted for any reason (including on userspace's request to
> + * just check whether a configuration would be possible). Drivers MUST
> + * NOT touch any persistent state (hardware or software) or data
> + * structures except the passed in adjusted_mode parameter.
> + *
> + * RETURNS:
> + *
> + * True if an acceptable configuration is possible, false if the modeset
> + * operation should be rejected.
> + */
> bool (*mode_fixup)(struct drm_bridge *bridge,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode);
> + /**
> + * @disable:
> + *
> + * This callback should disable the bridge. It is called right before
> + * the preceding element in the display pipe is disabled. If the
> + * preceding element is a bridge this means it's called before that
> + * bridge's ->disaable function. If the preceding element is a
> + * &drm_encoder it's called right before the encoder's ->disable,
> + * ->prepare or ->dpms hook from struct &drm_encoder_helper_funcs.
> + *
> + * The bridge can assume that the display pipe (i.e. clocks and timing
> + * signals) feeding it is still running when this callback is called.
> + */
> void (*disable)(struct drm_bridge *bridge);
> +
> + /**
> + * @post_disable:
> + *
> + * This callback should disable the bridge. It is called right after
> + * the preceding element in the display pipe is disabled. If the
> + * preceding element is a bridge this means it's called after that
> + * bridge's ->post_disaable function. If the preceding element is a
> + * &drm_encoder it's called right after the encoder's ->disable,
> + * ->prepare or ->dpms hook from struct &drm_encoder_helper_funcs.
> + *
> + * The bridge must assume that the display pipe (i.e. clocks and timing
> + * singals) feeding it is no longer running when this callback is
> + * called.
> + */
> void (*post_disable)(struct drm_bridge *bridge);
> +
> + /**
> + * @mode_set:
> + *
> + * This callback should set the given mode on the bridge. It is called
> + * after the ->mode_set callback for the preceding element in the
> + * display pipeline has been called already. The display pipe (i.e.
> + * clocks and timing signals) is off when this function is called.
> + */
> void (*mode_set)(struct drm_bridge *bridge,
> struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode);
> + /**
> + * @pre_enable:
> + *
> + * This callback should enable the bridge. It is called right before
> + * the preceding element in the display pipe is enabled. If the
> + * preceding element is a bridge this means it's called before that
> + * bridge's ->pre_enable function. If the preceding element is a
> + * &drm_encoder it's called right before the encoder's ->enable,
> + * ->commit or ->dpms hook from struct &drm_encoder_helper_funcs.
> + *
> + * The display pipe (i.e. clocks and timing signals) feeding this bridge
> + * will not yet be running when this callback is called. The bridge must
> + * not enable the display link feeding the next bridge in the chain (if
> + * there is one) when this callback is called.
> + */
> void (*pre_enable)(struct drm_bridge *bridge);
> +
> + /**
> + * @enable:
> + *
> + * This callback should enable the bridge. It is called right after
> + * the preceding element in the display pipe is enabled. If the
> + * preceding element is a bridge this means it's called after that
> + * bridge's ->enable function. If the preceding element is a
> + * &drm_encoder it's called right after the encoder's ->enable,
> + * ->commit or ->dpms hook from struct &drm_encoder_helper_funcs.
> + *
> + * The bridge can assume that the display pipe (i.e. clocks and timing
> + * signals) feeding it is running when this callback is called. This
> + * callback must enable the display link feeding the next bridge in the
> + * chain if there is one.
> + */
> void (*enable)(struct drm_bridge *bridge);
> };
>
>
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum, hosted by The Linux Foundation
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 06/28] drm/bridge: Improve kerneldoc
2015-12-04 8:45 ` [PATCH 06/28] drm/bridge: Improve kerneldoc Daniel Vetter
2015-12-04 10:43 ` Archit Taneja
@ 2015-12-07 11:31 ` Thierry Reding
1 sibling, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:31 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 7445 bytes --]
On Fri, Dec 04, 2015 at 09:45:47AM +0100, Daniel Vetter wrote:
> Especially document the assumptions and semantics of the callbacks
> carefully. Just a warm-up excercise really.
>
> v2: Spelling fixes (Eric).
>
> v3: Consolidate more with existing docs:
>
> - Remove the overview section explaining the bridge funcs, that's
> now all in the drm_bridge_funcs kerneldoc in much more detail.
>
> - Use & to reference structs so that kerneldoc automatically inserts
> hyperlinks.
>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Archit Taneja <architt@codeaurora.org>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/drm_bridge.c | 69 +++++++++++------------------
> include/drm/drm_crtc.h | 102 ++++++++++++++++++++++++++++++++++++++++---
> 2 files changed, 122 insertions(+), 49 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> index 6b8f7211e543..26dd1cfb6078 100644
> --- a/drivers/gpu/drm/drm_bridge.c
> +++ b/drivers/gpu/drm/drm_bridge.c
> @@ -31,14 +31,14 @@
> /**
> * DOC: overview
> *
> - * drm_bridge represents a device that hangs on to an encoder. These are handy
> - * when a regular drm_encoder entity isn't enough to represent the entire
> + * struct &drm_bridge represents a device that hangs on to an encoder. These are
> + * handy when a regular &drm_encoder entity isn't enough to represent the entire
> * encoder chain.
> *
> - * A bridge is always associated to a single drm_encoder at a time, but can be
> + * A bridge is always associated to a single &drm_encoder at a time, but can be
I think I've seen either "associated with" or "attached to", but the
above sounds strange to me. Anyway, it's nothing you've introduced in
this patch, so might as well stay the way it is.
> * either connected to it directly, or through an intermediate bridge:
> *
> - * encoder ---> bridge B ---> bridge A
> + * encoder ---> bridge B ---> bridge A
> *
> * Here, the output of the encoder feeds to bridge B, and that furthers feeds to
> * bridge A.
> @@ -46,11 +46,16 @@
> * The driver using the bridge is responsible to make the associations between
> * the encoder and bridges. Once these links are made, the bridges will
> * participate along with encoder functions to perform mode_set/enable/disable
> - * through the ops provided in drm_bridge_funcs.
> + * through the ops provided in &drm_bridge_funcs.
> *
> * drm_bridge, like drm_panel, aren't drm_mode_object entities like planes,
> - * crtcs, encoders or connectors. They just provide additional hooks to get the
> - * desired output at the end of the encoder chain.
> + * crtcs, encoders or connectors and hence are not visible to userspace. They
s/crtcs/CRTCs/
> @@ -122,34 +127,12 @@ EXPORT_SYMBOL(drm_bridge_attach);
> /**
> * DOC: bridge callbacks
> *
> - * The drm_bridge_funcs ops are populated by the bridge driver. The drm
> - * internals(atomic and crtc helpers) use the helpers defined in drm_bridge.c
> - * These helpers call a specific drm_bridge_funcs op for all the bridges
> + * The &drm_bridge_funcs ops are populated by the bridge driver. The drm
s/drm/DRM/
> + * internals (atomic and crtc helpers) use the helpers defined in drm_bridge.c
s/crtc/CRTC/
> /**
> @@ -159,7 +142,7 @@ EXPORT_SYMBOL(drm_bridge_attach);
> * @mode: desired mode to be set for the bridge
> * @adjusted_mode: updated mode that works for this bridge
> *
> - * Calls 'mode_fixup' drm_bridge_funcs op for all the bridges in the
> + * Calls 'mode_fixup' &drm_bridge_funcs op for all the bridges in the
"->mode_fixup()"?
> @@ -186,11 +169,11 @@ bool drm_bridge_mode_fixup(struct drm_bridge *bridge,
> EXPORT_SYMBOL(drm_bridge_mode_fixup);
>
> /**
> - * drm_bridge_disable - calls 'disable' drm_bridge_funcs op for all
> + * drm_bridge_disable - calls 'disable' &drm_bridge_funcs op for all
> * bridges in the encoder chain.
> * @bridge: bridge control structure
> *
> - * Calls 'disable' drm_bridge_funcs op for all the bridges in the encoder
> + * Calls 'disable' &drm_bridge_funcs op for all the bridges in the encoder
"->disable()"? Perhaps not worth it because there's a bunch of these in
this file.
> struct drm_bridge_funcs {
> int (*attach)(struct drm_bridge *bridge);
> +
> + /**
> + * @mode_fixup:
> + *
> + * This callback is used to validate and adjust a mode. The paramater
> + * mode is the display mode that should be fed to the next element in
> + * the display chain, either the final &drm_connector or the next
> + * &drm_bridge. The parameter adjusted_mode is the input mode the bridge
> + * requires. It can be modified by this callback and does not need to
> + * match mode.
> + *
> + * This is the only hook that allows a bridge to reject a modeset. If
> + * this function passes all other callbacks must succeed for this
> + * configuration.
> + *
> + * NOTE:
> + *
> + * This function is called in the check phase of atomic modesets, which
> + * can be aborted for any reason (including on userspace's request to
> + * just check whether a configuration would be possible). Drivers MUST
> + * NOT touch any persistent state (hardware or software) or data
> + * structures except the passed in adjusted_mode parameter.
> + *
> + * RETURNS:
> + *
> + * True if an acceptable configuration is possible, false if the modeset
> + * operation should be rejected.
> + */
> bool (*mode_fixup)(struct drm_bridge *bridge,
> const struct drm_display_mode *mode,
> struct drm_display_mode *adjusted_mode);
> + /**
> + * @disable:
> + *
> + * This callback should disable the bridge. It is called right before
> + * the preceding element in the display pipe is disabled. If the
> + * preceding element is a bridge this means it's called before that
> + * bridge's ->disaable function. If the preceding element is a
s/->disaable/->disable()/?
> + * &drm_encoder it's called right before the encoder's ->disable,
> + * ->prepare or ->dpms hook from struct &drm_encoder_helper_funcs.
->disable(), ->prepare() or ->dpms()?
> + *
> + * The bridge can assume that the display pipe (i.e. clocks and timing
> + * signals) feeding it is still running when this callback is called.
> + */
> void (*disable)(struct drm_bridge *bridge);
> +
> + /**
> + * @post_disable:
> + *
> + * This callback should disable the bridge. It is called right after
> + * the preceding element in the display pipe is disabled. If the
> + * preceding element is a bridge this means it's called after that
> + * bridge's ->post_disaable function. If the preceding element is a
> + * &drm_encoder it's called right after the encoder's ->disable,
> + * ->prepare or ->dpms hook from struct &drm_encoder_helper_funcs.
Same comments as for ->disable(). Perhaps this should also say what the
difference is to ->disable()? But maybe that's more suitable for a
follow-up patch.
> + *
> + * The bridge must assume that the display pipe (i.e. clocks and timing
> + * singals) feeding it is no longer running when this callback is
"signals". I guess this is the difference. Perhaps mention in the above
paragraph that ->post_disable() is called after ->disable(), though that
much should be obvious.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 07/28] drm: Update drm_plane_funcs kerneldoc
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (5 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 06/28] drm/bridge: Improve kerneldoc Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 11:46 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 08/28] drm/noveau: Ditch NULL save/restore hook assignments Daniel Vetter
` (20 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter
- Merge the docbook into the kerneldoc comments.
- Spec in detail the precise semantics of the callbacks.
- For consistency in wording and easier review roll out kerneldoc also
for crtc, encoder and connector for the standard hooks they share
with planes.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
Documentation/DocBook/gpu.tmpl | 104 ---------
include/drm/drm_crtc.h | 494 ++++++++++++++++++++++++++++++++++++++---
2 files changed, 458 insertions(+), 140 deletions(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 8b298fc2dd4d..23ad100c2bf5 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1279,28 +1279,12 @@ int max_width, max_height;</synopsis>
<title>Miscellaneous</title>
<itemizedlist>
<listitem>
- <synopsis>void (*set_property)(struct drm_crtc *crtc,
- struct drm_property *property, uint64_t value);</synopsis>
- <para>
- Set the value of the given CRTC property to
- <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
- for more information about properties.
- </para>
- </listitem>
- <listitem>
<synopsis>void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
uint32_t start, uint32_t size);</synopsis>
<para>
Apply a gamma table to the device. The operation is optional.
</para>
</listitem>
- <listitem>
- <synopsis>void (*destroy)(struct drm_crtc *crtc);</synopsis>
- <para>
- Destroy the CRTC when not needed anymore. See
- <xref linkend="drm-kms-init"/>.
- </para>
- </listitem>
</itemizedlist>
</sect4>
</sect3>
@@ -1357,52 +1341,6 @@ int max_width, max_height;</synopsis>
primary plane with standard capabilities.
</para>
</sect3>
- <sect3>
- <title>Plane Operations</title>
- <itemizedlist>
- <listitem>
- <synopsis>int (*update_plane)(struct drm_plane *plane, struct drm_crtc *crtc,
- struct drm_framebuffer *fb, int crtc_x, int crtc_y,
- unsigned int crtc_w, unsigned int crtc_h,
- uint32_t src_x, uint32_t src_y,
- uint32_t src_w, uint32_t src_h);</synopsis>
- <para>
- Enable and configure the plane to use the given CRTC and frame buffer.
- </para>
- <para>
- The source rectangle in frame buffer memory coordinates is given by
- the <parameter>src_x</parameter>, <parameter>src_y</parameter>,
- <parameter>src_w</parameter> and <parameter>src_h</parameter>
- parameters (as 16.16 fixed point values). Devices that don't support
- subpixel plane coordinates can ignore the fractional part.
- </para>
- <para>
- The destination rectangle in CRTC coordinates is given by the
- <parameter>crtc_x</parameter>, <parameter>crtc_y</parameter>,
- <parameter>crtc_w</parameter> and <parameter>crtc_h</parameter>
- parameters (as integer values). Devices scale the source rectangle to
- the destination rectangle. If scaling is not supported, and the source
- rectangle size doesn't match the destination rectangle size, the
- driver must return a -<errorname>EINVAL</errorname> error.
- </para>
- </listitem>
- <listitem>
- <synopsis>int (*disable_plane)(struct drm_plane *plane);</synopsis>
- <para>
- Disable the plane. The DRM core calls this method in response to a
- DRM_IOCTL_MODE_SETPLANE ioctl call with the frame buffer ID set to 0.
- Disabled planes must not be processed by the CRTC.
- </para>
- </listitem>
- <listitem>
- <synopsis>void (*destroy)(struct drm_plane *plane);</synopsis>
- <para>
- Destroy the plane when not needed anymore. See
- <xref linkend="drm-kms-init"/>.
- </para>
- </listitem>
- </itemizedlist>
- </sect3>
</sect2>
<sect2>
<title>Encoders (struct <structname>drm_encoder</structname>)</title>
@@ -1459,27 +1397,6 @@ int max_width, max_height;</synopsis>
encoders they want to use to a CRTC.
</para>
</sect3>
- <sect3>
- <title>Encoder Operations</title>
- <itemizedlist>
- <listitem>
- <synopsis>void (*destroy)(struct drm_encoder *encoder);</synopsis>
- <para>
- Called to destroy the encoder when not needed anymore. See
- <xref linkend="drm-kms-init"/>.
- </para>
- </listitem>
- <listitem>
- <synopsis>void (*set_property)(struct drm_plane *plane,
- struct drm_property *property, uint64_t value);</synopsis>
- <para>
- Set the value of the given plane property to
- <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
- for more information about properties.
- </para>
- </listitem>
- </itemizedlist>
- </sect3>
</sect2>
<sect2>
<title>Connectors (struct <structname>drm_connector</structname>)</title>
@@ -1683,27 +1600,6 @@ int max_width, max_height;</synopsis>
connector_status_unknown.
</para>
</sect4>
- <sect4>
- <title>Miscellaneous</title>
- <itemizedlist>
- <listitem>
- <synopsis>void (*set_property)(struct drm_connector *connector,
- struct drm_property *property, uint64_t value);</synopsis>
- <para>
- Set the value of the given connector property to
- <parameter>value</parameter>. See <xref linkend="drm-kms-properties"/>
- for more information about properties.
- </para>
- </listitem>
- <listitem>
- <synopsis>void (*destroy)(struct drm_connector *connector);</synopsis>
- <para>
- Destroy the connector when not needed anymore. See
- <xref linkend="drm-kms-init"/>.
- </para>
- </listitem>
- </itemizedlist>
- </sect4>
</sect3>
</sect2>
<sect2>
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index ec3632e62b3f..340d750f1364 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -322,21 +322,12 @@ struct drm_crtc_state {
* struct drm_crtc_funcs - control CRTCs for a given device
* @save: save CRTC state
* @restore: restore CRTC state
- * @reset: reset CRTC after state has been invalidated (e.g. resume)
* @cursor_set: setup the cursor
* @cursor_set2: setup the cursor with hotspot, superseeds @cursor_set if set
* @cursor_move: move the cursor
* @gamma_set: specify color ramp for CRTC
- * @destroy: deinit and free object
- * @set_property: called when a property is changed
* @set_config: apply a new CRTC configuration
* @page_flip: initiate a page flip
- * @atomic_duplicate_state: duplicate the atomic state for this CRTC
- * @atomic_destroy_state: destroy an atomic state for this CRTC
- * @atomic_set_property: set a property on an atomic state for this CRTC
- * (do not call directly, use drm_atomic_crtc_set_property())
- * @atomic_get_property: get a property on an atomic state for this CRTC
- * (do not call directly, use drm_atomic_crtc_get_property())
*
* The drm_crtc_funcs structure is the central CRTC management structure
* in the DRM. Each CRTC controls one or more connectors (note that the name
@@ -352,7 +343,17 @@ struct drm_crtc_funcs {
void (*save)(struct drm_crtc *crtc); /* suspend? */
/* Restore CRTC state */
void (*restore)(struct drm_crtc *crtc); /* resume? */
- /* Reset CRTC state */
+
+ /**
+ * @reset:
+ *
+ * Reset CRTC hardware and software state to off. This function isn't
+ * called by the core directly, only through drm_mode_config_reset().
+ * It's not a helper hook only for historical reasons.
+ *
+ * Atomic drivers can use drm_atomic_helper_crtc_reset() to reset
+ * atomic state using this hook.
+ */
void (*reset)(struct drm_crtc *crtc);
/* cursor controls */
@@ -366,7 +367,14 @@ struct drm_crtc_funcs {
/* Set gamma on the CRTC */
void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
uint32_t start, uint32_t size);
- /* Object destroy routine */
+
+ /**
+ * @destroy:
+ *
+ * Clean up CRTC resources. This is only called at driver unload time
+ * through drm_mode_config_cleanup(), but can also be called at runtime
+ * when a CRTC is being hot-unplugged.
+ */
void (*destroy)(struct drm_crtc *crtc);
int (*set_config)(struct drm_mode_set *set);
@@ -385,17 +393,130 @@ struct drm_crtc_funcs {
struct drm_pending_vblank_event *event,
uint32_t flags);
+ /**
+ * @set_property:
+ *
+ * This is the legacy entry point to update a property attach to the
+ * CRTC.
+ *
+ * Drivers implementing atomic modeset should use
+ * drm_atomic_helper_crtc_set_property() to implement this hook.
+ *
+ * This callback is optional if the driver does not support any legacy
+ * driver-private properties.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*set_property)(struct drm_crtc *crtc,
struct drm_property *property, uint64_t val);
- /* atomic update handling */
+ /**
+ * @atomic_duplicate_state:
+ *
+ * Duplicate the current atomic state for this CRTC and return it.
+ * The core and helpers gurantee that any atomic state duplicated with
+ * this hook and still owned by the caller (i.e. not transferred to the
+ * driver by calling ->atomic_commit() from struct
+ * &drm_mode_config_funcs) will be cleaned up by calling the
+ * @atomic_destroy_state hook in this structure.
+ *
+ * Atomic drivers which don't subclass struct &drm_crtc should use
+ * drm_atomic_helper_crtc_duplicate_state(). Drivers that subclass the
+ * state structure to extend it with driver-private state should use
+ * __drm_atomic_helper_crtc_duplicate_state() to make sure shared state is
+ * duplicated in a consisten fashion across drivers.
+ *
+ * It is an error to call this hook before crtc->state has been
+ * initialized correctly.
+ *
+ * NOTE:
+ *
+ * If the duplicate state references refcounted resources this hook must
+ * acquire a reference for each of them. The driver must release these
+ * references again in @atomic_destroy_state.
+ *
+ * RETURNS:
+ *
+ * Duplicated atomic state or NULL when the allocation failed.
+ */
struct drm_crtc_state *(*atomic_duplicate_state)(struct drm_crtc *crtc);
+
+ /**
+ * @atomic_destroy_state:
+ *
+ * Destroy a state duplicated with @atomic_duplicate_state and release
+ * or unreference all resources it references
+ */
void (*atomic_destroy_state)(struct drm_crtc *crtc,
struct drm_crtc_state *state);
+
+ /**
+ * @atomic_set_property:
+ *
+ * Decode a driver-private property value and store the decoded value
+ * into the passed-in state structure. Since the atomic core decodes all
+ * standardized properties (even for extensions beyond the core set of
+ * properties which might not be implemented by all drivers) this
+ * requires drivers to subclass the state structure.
+ *
+ * Such driver-private properties should really only implemented for
+ * truly hardware/vendor specific state. Instead it is preferred to
+ * standardize atomic extension and decode the properties used to expose
+ * such an extension in the core.
+ *
+ * Do not call this function directly, use
+ * drm_atomic_crtc_set_property() instead.
+ *
+ * This callback is optional if the driver does not support any
+ * driver-private atomic properties.
+ *
+ * NOTE:
+ *
+ * This function is called in the state assembly phase of atomic
+ * modesets, which can be aborted for any reason (including on
+ * userspace's request to just check whether a configuration would be
+ * possible). Drivers MUST NOT touch any persistent state (hardware or
+ * software) or data structures except the passed in adjusted_mode
+ * parameter.
+ *
+ * Also since userspace controls in which order properties are set this
+ * function must not do any input validation (since the state update is
+ * incompletely and hence likely inconsistent). Instead any such input
+ * validation must be done in the various atomic_check callbacks.
+ *
+ * RETURNS:
+ *
+ * 0 if the property has been found, -EINVAL if the property isn't
+ * implemented by the driver (which shouldn't ever happen, the core only
+ * asks for properties attached to this CRTC). No other
+ * validation is allowed by the driver. The core checks that the
+ * property value is within the range (integer, valid enum value, ...)
+ * the driver set when registering the property already.
+ */
int (*atomic_set_property)(struct drm_crtc *crtc,
struct drm_crtc_state *state,
struct drm_property *property,
uint64_t val);
+ /**
+ * @atomic_get_property:
+ *
+ * Reads out the decoded driver-private property. This is used to
+ * implement the GETCRTC ioctl.
+ *
+ * Do not call this function directly, use
+ * drm_atomic_crtc_get_property() instead.
+ *
+ * This callback is optional if the driver does not support any
+ * driver-private atomic properties.
+ *
+ * RETURNS:
+ *
+ * 0 on success, -EINVAL if ther property isn't implemented by the
+ * driver (which shouldn't ever happen, the core only asks for
+ * properties attached on this CRTC).
+ */
int (*atomic_get_property)(struct drm_crtc *crtc,
const struct drm_crtc_state *state,
struct drm_property *property,
@@ -507,18 +628,9 @@ struct drm_connector_state {
* @dpms: set power state
* @save: save connector state
* @restore: restore connector state
- * @reset: reset connector after state has been invalidated (e.g. resume)
* @detect: is this connector active?
* @fill_modes: fill mode list for this connector
- * @set_property: property for this connector may need an update
- * @destroy: make object go away
* @force: notify the driver that the connector is forced on
- * @atomic_duplicate_state: duplicate the atomic state for this connector
- * @atomic_destroy_state: destroy an atomic state for this connector
- * @atomic_set_property: set a property on an atomic state for this connector
- * (do not call directly, use drm_atomic_connector_set_property())
- * @atomic_get_property: get a property on an atomic state for this connector
- * (do not call directly, use drm_atomic_connector_get_property())
*
* Each CRTC may have one or more connectors attached to it. The functions
* below allow the core DRM code to control connectors, enumerate available modes,
@@ -528,6 +640,17 @@ struct drm_connector_funcs {
int (*dpms)(struct drm_connector *connector, int mode);
void (*save)(struct drm_connector *connector);
void (*restore)(struct drm_connector *connector);
+
+ /**
+ * @reset:
+ *
+ * Reset connector hardware and software state to off. This function isn't
+ * called by the core directly, only through drm_mode_config_reset().
+ * It's not a helper hook only for historical reasons.
+ *
+ * Atomic drivers can use drm_atomic_helper_connector_reset() to reset
+ * atomic state using this hook.
+ */
void (*reset)(struct drm_connector *connector);
/* Check to see if anything is attached to the connector.
@@ -539,19 +662,142 @@ struct drm_connector_funcs {
enum drm_connector_status (*detect)(struct drm_connector *connector,
bool force);
int (*fill_modes)(struct drm_connector *connector, uint32_t max_width, uint32_t max_height);
+
+ /**
+ * @set_property:
+ *
+ * This is the legacy entry point to update a property attach to the
+ * connector.
+ *
+ * Drivers implementing atomic modeset should use
+ * drm_atomic_helper_connector_set_property() to implement this hook.
+ *
+ * This callback is optional if the driver does not support any legacy
+ * driver-private properties.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*set_property)(struct drm_connector *connector, struct drm_property *property,
uint64_t val);
+
+ /**
+ * @destroy:
+ *
+ * Clean up connector resources. This is only called at driver unload time
+ * through drm_mode_config_cleanup(), but can also be called at runtime
+ * when a connector is being hot-unplugged.
+ */
void (*destroy)(struct drm_connector *connector);
void (*force)(struct drm_connector *connector);
- /* atomic update handling */
+ /**
+ * @atomic_duplicate_state:
+ *
+ * Duplicate the current atomic state for this connector and return it.
+ * The core and helpers gurantee that any atomic state duplicated with
+ * this hook and still owned by the caller (i.e. not transferred to the
+ * driver by calling ->atomic_commit() from struct
+ * &drm_mode_config_funcs) will be cleaned up by calling the
+ * @atomic_destroy_state hook in this structure.
+ *
+ * Atomic drivers which don't subclass struct &drm_connector_state should use
+ * drm_atomic_helper_connector_duplicate_state(). Drivers that subclass the
+ * state structure to extend it with driver-private state should use
+ * __drm_atomic_helper_connector_duplicate_state() to make sure shared state is
+ * duplicated in a consisten fashion across drivers.
+ *
+ * It is an error to call this hook before connector->state has been
+ * initialized correctly.
+ *
+ * NOTE:
+ *
+ * If the duplicate state references refcounted resources this hook must
+ * acquire a reference for each of them. The driver must release these
+ * references again in @atomic_destroy_state.
+ *
+ * RETURNS:
+ *
+ * Duplicated atomic state or NULL when the allocation failed.
+ */
struct drm_connector_state *(*atomic_duplicate_state)(struct drm_connector *connector);
+
+ /**
+ * @atomic_destroy_state:
+ *
+ * Destroy a state duplicated with @atomic_duplicate_state and release
+ * or unreference all resources it references
+ */
void (*atomic_destroy_state)(struct drm_connector *connector,
struct drm_connector_state *state);
+
+ /**
+ * @atomic_set_property:
+ *
+ * Decode a driver-private property value and store the decoded value
+ * into the passed-in state structure. Since the atomic core decodes all
+ * standardized properties (even for extensions beyond the core set of
+ * properties which might not be implemented by all drivers) this
+ * requires drivers to subclass the state structure.
+ *
+ * Such driver-private properties should really only implemented for
+ * truly hardware/vendor specific state. Instead it is preferred to
+ * standardize atomic extension and decode the properties used to expose
+ * such an extension in the core.
+ *
+ * Do not call this function directly, use
+ * drm_atomic_connector_set_property() instead.
+ *
+ * This callback is optional if the driver does not support any
+ * driver-private atomic properties.
+ *
+ * NOTE:
+ *
+ * This function is called in the state assembly phase of atomic
+ * modesets, which can be aborted for any reason (including on
+ * userspace's request to just check whether a configuration would be
+ * possible). Drivers MUST NOT touch any persistent state (hardware or
+ * software) or data structures except the passed in adjusted_mode
+ * parameter.
+ *
+ * Also since userspace controls in which order properties are set this
+ * function must not do any input validation (since the state update is
+ * incompletely and hence likely inconsistent). Instead any such input
+ * validation must be done in the various atomic_check callbacks.
+ *
+ * RETURNS:
+ *
+ * 0 if the property has been found, -EINVAL if the property isn't
+ * implemented by the driver (which shouldn't ever happen, the core only
+ * asks for properties attached to this connector). No other
+ * validation is allowed by the driver. The core checks that the
+ * property value is within the range (integer, valid enum value, ...)
+ * the driver set when registering the property already.
+ */
int (*atomic_set_property)(struct drm_connector *connector,
struct drm_connector_state *state,
struct drm_property *property,
uint64_t val);
+
+ /**
+ * @atomic_get_property:
+ *
+ * Reads out the decoded driver-private property. This is used to
+ * implement the GETCONNECTOR ioctl.
+ *
+ * Do not call this function directly, use
+ * drm_atomic_connector_get_property() instead.
+ *
+ * This callback is optional if the driver does not support any
+ * driver-private atomic properties.
+ *
+ * RETURNS:
+ *
+ * 0 on success, -EINVAL if ther property isn't implemented by the
+ * driver (which shouldn't ever happen, the core only asks for
+ * properties attached on this connector).
+ */
int (*atomic_get_property)(struct drm_connector *connector,
const struct drm_connector_state *state,
struct drm_property *property,
@@ -560,13 +806,25 @@ struct drm_connector_funcs {
/**
* struct drm_encoder_funcs - encoder controls
- * @reset: reset state (e.g. at init or resume time)
- * @destroy: cleanup and free associated data
*
* Encoders sit between CRTCs and connectors.
*/
struct drm_encoder_funcs {
+ /**
+ * @reset:
+ *
+ * Reset encoder hardware and software state to off. This function isn't
+ * called by the core directly, only through drm_mode_config_reset().
+ * It's not a helper hook only for historical reasons.
+ */
void (*reset)(struct drm_encoder *encoder);
+
+ /**
+ * @destroy:
+ *
+ * Clean up encoder resources. This is only called at driver unload time
+ * through drm_mode_config_cleanup() since encoder cannot be hotplugged in DRM.
+ */
void (*destroy)(struct drm_encoder *encoder);
};
@@ -787,40 +1045,203 @@ struct drm_plane_state {
/**
* struct drm_plane_funcs - driver plane control functions
- * @update_plane: update the plane configuration
- * @disable_plane: shut down the plane
- * @destroy: clean up plane resources
- * @reset: reset plane after state has been invalidated (e.g. resume)
- * @set_property: called when a property is changed
- * @atomic_duplicate_state: duplicate the atomic state for this plane
- * @atomic_destroy_state: destroy an atomic state for this plane
- * @atomic_set_property: set a property on an atomic state for this plane
- * (do not call directly, use drm_atomic_plane_set_property())
- * @atomic_get_property: get a property on an atomic state for this plane
- * (do not call directly, use drm_atomic_plane_get_property())
*/
struct drm_plane_funcs {
+ /**
+ * @update_plane:
+ *
+ * This is the legacy entry point to enable and configure the plane for
+ * the given CRTC and framebuffer. It is never called to disable the
+ * plane, i.e. the passed-in crtc and fb paramters are never NULL.
+ *
+ * The source rectangle in frame buffer memory coordinates is given by
+ * the src_x, src_y, src_w and src_h parameters (as 16.16 fixed point
+ * values). Devices that don't support subpixel plane coordinates can
+ * ignore the fractional part.
+ *
+ * The destination rectangle in CRTC coordinates is given by the
+ * crtc_x, crtc_y, crtc_w and crtc_h parameters (as integer values).
+ * Devices scale the source rectangle to the destination rectangle. If
+ * scaling is not supported, and the source rectangle size doesn't match
+ * the destination rectangle size, the driver must return a
+ * -<errorname>EINVAL</errorname> error.
+ *
+ * Drivers implementing atomic modeset should use
+ * drm_atomic_helper_update_plane() to implement this hook.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*update_plane)(struct drm_plane *plane,
struct drm_crtc *crtc, struct drm_framebuffer *fb,
int crtc_x, int crtc_y,
unsigned int crtc_w, unsigned int crtc_h,
uint32_t src_x, uint32_t src_y,
uint32_t src_w, uint32_t src_h);
+
+ /**
+ * @disable_plane:
+ *
+ * This is the legacy entry point to disable the plane. The DRM core
+ * calls this method in response to a DRM_IOCTL_MODE_SETPLANE ioctl call
+ * with the frame buffer ID set to 0. Disabled planes must not be
+ * processed by the CRTC.
+ *
+ * Drivers implementing atomic modeset should use
+ * drm_atomic_helper_disable_plane() to implement this hook.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*disable_plane)(struct drm_plane *plane);
+
+ /**
+ * @destroy:
+ *
+ * Clean up plane resources. This is only called at driver unload time
+ * through drm_mode_config_cleanup() since plane cannot be hotplugged in DRM.
+ */
void (*destroy)(struct drm_plane *plane);
+
+ /**
+ * @reset:
+ *
+ * Reset plane hardware and software state to off. This function isn't
+ * called by the core directly, only through drm_mode_config_reset().
+ * It's not a helper hook only for historical reasons.
+ *
+ * Atomic drivers can use drm_atomic_helper_plane_reset() to reset
+ * atomic state using this hook.
+ */
void (*reset)(struct drm_plane *plane);
+ /**
+ * @set_property:
+ *
+ * This is the legacy entry point to update a property attach to the
+ * plane.
+ *
+ * Drivers implementing atomic modeset should use
+ * drm_atomic_helper_plane_set_property() to implement this hook.
+ *
+ * This callback is optional if the driver does not support any legacy
+ * driver-private properties.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*set_property)(struct drm_plane *plane,
struct drm_property *property, uint64_t val);
- /* atomic update handling */
+ /**
+ * @atomic_duplicate_state:
+ *
+ * Duplicate the current atomic state for this plane and return it.
+ * The core and helpers gurantee that any atomic state duplicated with
+ * this hook and still owned by the caller (i.e. not transferred to the
+ * driver by calling ->atomic_commit() from struct
+ * &drm_mode_config_funcs) will be cleaned up by calling the
+ * @atomic_destroy_state hook in this structure.
+ *
+ * Atomic drivers which don't subclass struct &drm_plane_state should use
+ * drm_atomic_helper_plane_duplicate_state(). Drivers that subclass the
+ * state structure to extend it with driver-private state should use
+ * __drm_atomic_helper_plane_duplicate_state() to make sure shared state is
+ * duplicated in a consisten fashion across drivers.
+ *
+ * It is an error to call this hook before plane->state has been
+ * initialized correctly.
+ *
+ * NOTE:
+ *
+ * If the duplicate state references refcounted resources this hook must
+ * acquire a reference for each of them. The driver must release these
+ * references again in @atomic_destroy_state.
+ *
+ * RETURNS:
+ *
+ * Duplicated atomic state or NULL when the allocation failed.
+ */
struct drm_plane_state *(*atomic_duplicate_state)(struct drm_plane *plane);
+
+ /**
+ * @atomic_destroy_state:
+ *
+ * Destroy a state duplicated with @atomic_duplicate_state and release
+ * or unreference all resources it references
+ */
void (*atomic_destroy_state)(struct drm_plane *plane,
struct drm_plane_state *state);
+
+ /**
+ * @atomic_set_property:
+ *
+ * Decode a driver-private property value and store the decoded value
+ * into the passed-in state structure. Since the atomic core decodes all
+ * standardized properties (even for extensions beyond the core set of
+ * properties which might not be implemented by all drivers) this
+ * requires drivers to subclass the state structure.
+ *
+ * Such driver-private properties should really only implemented for
+ * truly hardware/vendor specific state. Instead it is preferred to
+ * standardize atomic extension and decode the properties used to expose
+ * such an extension in the core.
+ *
+ * Do not call this function directly, use
+ * drm_atomic_plane_set_property() instead.
+ *
+ * This callback is optional if the driver does not support any
+ * driver-private atomic properties.
+ *
+ * NOTE:
+ *
+ * This function is called in the state assembly phase of atomic
+ * modesets, which can be aborted for any reason (including on
+ * userspace's request to just check whether a configuration would be
+ * possible). Drivers MUST NOT touch any persistent state (hardware or
+ * software) or data structures except the passed in adjusted_mode
+ * parameter.
+ *
+ * Also since userspace controls in which order properties are set this
+ * function must not do any input validation (since the state update is
+ * incompletely and hence likely inconsistent). Instead any such input
+ * validation must be done in the various atomic_check callbacks.
+ *
+ * RETURNS:
+ *
+ * 0 if the property has been found, -EINVAL if the property isn't
+ * implemented by the driver (which shouldn't ever happen, the core only
+ * asks for properties attached to this plane). No other
+ * validation is allowed by the driver. The core checks that the
+ * property value is within the range (integer, valid enum value, ...)
+ * the driver set when registering the property already.
+ */
int (*atomic_set_property)(struct drm_plane *plane,
struct drm_plane_state *state,
struct drm_property *property,
uint64_t val);
+
+ /**
+ * @atomic_get_property:
+ *
+ * Reads out the decoded driver-private property. This is used to
+ * implement the GETPLANE ioctl.
+ *
+ * Do not call this function directly, use
+ * drm_atomic_plane_get_property() instead.
+ *
+ * This callback is optional if the driver does not support any
+ * driver-private atomic properties.
+ *
+ * RETURNS:
+ *
+ * 0 on success, -EINVAL if ther property isn't implemented by the
+ * driver (which shouldn't ever happen, the core only asks for
+ * properties attached on this plane).
+ */
int (*atomic_get_property)(struct drm_plane *plane,
const struct drm_plane_state *state,
struct drm_property *property,
@@ -833,6 +1254,7 @@ enum drm_plane_type {
DRM_PLANE_TYPE_CURSOR,
};
+
/**
* struct drm_plane - central DRM plane control structure
* @dev: DRM device this plane belongs to
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 07/28] drm: Update drm_plane_funcs kerneldoc
2015-12-04 8:45 ` [PATCH 07/28] drm: Update drm_plane_funcs kerneldoc Daniel Vetter
@ 2015-12-07 11:46 ` Thierry Reding
2015-12-07 12:34 ` Daniel Vetter
0 siblings, 1 reply; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:46 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 4782 bytes --]
On Fri, Dec 04, 2015 at 09:45:48AM +0100, Daniel Vetter wrote:
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
[...]
> + /**
> + * @destroy:
> + *
> + * Clean up CRTC resources. This is only called at driver unload time
Perhaps drop "only" because there are more than a single potential
usage?
> + /**
> + * @set_property:
> + *
> + * This is the legacy entry point to update a property attach to the
"attached to"
> - /* atomic update handling */
> + /**
> + * @atomic_duplicate_state:
> + *
> + * Duplicate the current atomic state for this CRTC and return it.
> + * The core and helpers gurantee that any atomic state duplicated with
> + * this hook and still owned by the caller (i.e. not transferred to the
> + * driver by calling ->atomic_commit() from struct
> + * &drm_mode_config_funcs) will be cleaned up by calling the
> + * @atomic_destroy_state hook in this structure.
> + *
> + * Atomic drivers which don't subclass struct &drm_crtc should use
> + * drm_atomic_helper_crtc_duplicate_state(). Drivers that subclass the
> + * state structure to extend it with driver-private state should use
> + * __drm_atomic_helper_crtc_duplicate_state() to make sure shared state is
> + * duplicated in a consisten fashion across drivers.
"consistent"
> + /**
> + * @atomic_set_property:
> + *
> + * Decode a driver-private property value and store the decoded value
> + * into the passed-in state structure. Since the atomic core decodes all
> + * standardized properties (even for extensions beyond the core set of
> + * properties which might not be implemented by all drivers) this
> + * requires drivers to subclass the state structure.
> + *
> + * Such driver-private properties should really only implemented for
"be implemented"
> + * This function is called in the state assembly phase of atomic
> + * modesets, which can be aborted for any reason (including on
> + * userspace's request to just check whether a configuration would be
> + * possible). Drivers MUST NOT touch any persistent state (hardware or
> + * software) or data structures except the passed in adjusted_mode
Copy-paste error? Should be "... the passed in @state parameter."
> + *
> + * Also since userspace controls in which order properties are set this
> + * function must not do any input validation (since the state update is
> + * incompletely and hence likely inconsistent). Instead any such input
"incomplete"
> + * validation must be done in the various atomic_check callbacks.
> + *
> + * RETURNS:
> + *
> + * 0 if the property has been found, -EINVAL if the property isn't
> + * implemented by the driver (which shouldn't ever happen, the core only
s/shouldn't ever/should never/?
> + * asks for properties attached to this CRTC). No other
Seems like you could put more text on the above line.
> + * validation is allowed by the driver. The core checks that the
> + * property value is within the range (integer, valid enum value, ...)
> + * the driver set when registering the property already.
I'd put the "already" after "The core", otherwise it reads weird in my
opinion.
> + */
> int (*atomic_set_property)(struct drm_crtc *crtc,
> struct drm_crtc_state *state,
> struct drm_property *property,
> uint64_t val);
> + /**
> + * @atomic_get_property:
> + *
> + * Reads out the decoded driver-private property. This is used to
> + * implement the GETCRTC ioctl.
> + *
> + * Do not call this function directly, use
> + * drm_atomic_crtc_get_property() instead.
> + *
> + * This callback is optional if the driver does not support any
> + * driver-private atomic properties.
> + *
> + * RETURNS:
> + *
> + * 0 on success, -EINVAL if ther property isn't implemented by the
s/ther/the/
> + * driver (which shouldn't ever happen, the core only asks for
s/shouldn't ever/should never/?
> + * properties attached on this CRTC).
"attached to"
> @@ -539,19 +662,142 @@ struct drm_connector_funcs {
> enum drm_connector_status (*detect)(struct drm_connector *connector,
> bool force);
> int (*fill_modes)(struct drm_connector *connector, uint32_t max_width, uint32_t max_height);
> +
> + /**
> + * @set_property:
> + *
> + * This is the legacy entry point to update a property attach to the
"attached to"
> + /**
> + * @destroy:
> + *
> + * Clean up connector resources. This is only called at driver unload time
> + * through drm_mode_config_cleanup(), but can also be called at runtime
> + * when a connector is being hot-unplugged.
Again, perhaps drop the "only" because it's inconsistent when followed
by "but can also".
Most of the comments on the CRTC helpers do apply to the connector
helpers as well, so I haven't repeated them.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 07/28] drm: Update drm_plane_funcs kerneldoc
2015-12-07 11:46 ` Thierry Reding
@ 2015-12-07 12:34 ` Daniel Vetter
2015-12-07 12:43 ` Thierry Reding
0 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-07 12:34 UTC (permalink / raw)
To: Thierry Reding
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
On Mon, Dec 07, 2015 at 12:46:38PM +0100, Thierry Reding wrote:
> On Fri, Dec 04, 2015 at 09:45:48AM +0100, Daniel Vetter wrote:
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> [...]
> > + /**
> > + * @destroy:
> > + *
> > + * Clean up CRTC resources. This is only called at driver unload time
>
> Perhaps drop "only" because there are more than a single potential
> usage?
It's for driver unload only since you can't hotplug planes. The only
hotpluggable thing in drm atm are connectors, and I've added these blurbs
to highlight that.
>
> > + /**
> > + * @set_property:
> > + *
> > + * This is the legacy entry point to update a property attach to the
>
> "attached to"
>
> > - /* atomic update handling */
> > + /**
> > + * @atomic_duplicate_state:
> > + *
> > + * Duplicate the current atomic state for this CRTC and return it.
> > + * The core and helpers gurantee that any atomic state duplicated with
> > + * this hook and still owned by the caller (i.e. not transferred to the
> > + * driver by calling ->atomic_commit() from struct
> > + * &drm_mode_config_funcs) will be cleaned up by calling the
> > + * @atomic_destroy_state hook in this structure.
> > + *
> > + * Atomic drivers which don't subclass struct &drm_crtc should use
> > + * drm_atomic_helper_crtc_duplicate_state(). Drivers that subclass the
> > + * state structure to extend it with driver-private state should use
> > + * __drm_atomic_helper_crtc_duplicate_state() to make sure shared state is
> > + * duplicated in a consisten fashion across drivers.
>
> "consistent"
>
> > + /**
> > + * @atomic_set_property:
> > + *
> > + * Decode a driver-private property value and store the decoded value
> > + * into the passed-in state structure. Since the atomic core decodes all
> > + * standardized properties (even for extensions beyond the core set of
> > + * properties which might not be implemented by all drivers) this
> > + * requires drivers to subclass the state structure.
> > + *
> > + * Such driver-private properties should really only implemented for
>
> "be implemented"
>
> > + * This function is called in the state assembly phase of atomic
> > + * modesets, which can be aborted for any reason (including on
> > + * userspace's request to just check whether a configuration would be
> > + * possible). Drivers MUST NOT touch any persistent state (hardware or
> > + * software) or data structures except the passed in adjusted_mode
>
> Copy-paste error? Should be "... the passed in @state parameter."
>
> > + *
> > + * Also since userspace controls in which order properties are set this
> > + * function must not do any input validation (since the state update is
> > + * incompletely and hence likely inconsistent). Instead any such input
>
> "incomplete"
>
> > + * validation must be done in the various atomic_check callbacks.
> > + *
> > + * RETURNS:
> > + *
> > + * 0 if the property has been found, -EINVAL if the property isn't
> > + * implemented by the driver (which shouldn't ever happen, the core only
>
> s/shouldn't ever/should never/?
>
> > + * asks for properties attached to this CRTC). No other
>
> Seems like you could put more text on the above line.
>
> > + * validation is allowed by the driver. The core checks that the
> > + * property value is within the range (integer, valid enum value, ...)
> > + * the driver set when registering the property already.
>
> I'd put the "already" after "The core", otherwise it reads weird in my
> opinion.
>
> > + */
> > int (*atomic_set_property)(struct drm_crtc *crtc,
> > struct drm_crtc_state *state,
> > struct drm_property *property,
> > uint64_t val);
> > + /**
> > + * @atomic_get_property:
> > + *
> > + * Reads out the decoded driver-private property. This is used to
> > + * implement the GETCRTC ioctl.
> > + *
> > + * Do not call this function directly, use
> > + * drm_atomic_crtc_get_property() instead.
> > + *
> > + * This callback is optional if the driver does not support any
> > + * driver-private atomic properties.
> > + *
> > + * RETURNS:
> > + *
> > + * 0 on success, -EINVAL if ther property isn't implemented by the
>
> s/ther/the/
>
> > + * driver (which shouldn't ever happen, the core only asks for
>
> s/shouldn't ever/should never/?
>
> > + * properties attached on this CRTC).
>
> "attached to"
>
> > @@ -539,19 +662,142 @@ struct drm_connector_funcs {
> > enum drm_connector_status (*detect)(struct drm_connector *connector,
> > bool force);
> > int (*fill_modes)(struct drm_connector *connector, uint32_t max_width, uint32_t max_height);
> > +
> > + /**
> > + * @set_property:
> > + *
> > + * This is the legacy entry point to update a property attach to the
>
> "attached to"
>
> > + /**
> > + * @destroy:
> > + *
> > + * Clean up connector resources. This is only called at driver unload time
> > + * through drm_mode_config_cleanup(), but can also be called at runtime
> > + * when a connector is being hot-unplugged.
>
> Again, perhaps drop the "only" because it's inconsistent when followed
> by "but can also".
Yeah here the only is wrong so removed it. Also reworded the 2nd part
slightly to add DP MST as an expample and make it clear that you need a
driver which can hotplug connectors for this.
> Most of the comments on the CRTC helpers do apply to the connector
> helpers as well, so I haven't repeated them.
Yeah, I think I found all 3 instances of each.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 07/28] drm: Update drm_plane_funcs kerneldoc
2015-12-07 12:34 ` Daniel Vetter
@ 2015-12-07 12:43 ` Thierry Reding
2015-12-07 13:00 ` Daniel Vetter
0 siblings, 1 reply; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 12:43 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
[-- Attachment #1.1: Type: text/plain, Size: 1697 bytes --]
On Mon, Dec 07, 2015 at 01:34:16PM +0100, Daniel Vetter wrote:
> On Mon, Dec 07, 2015 at 12:46:38PM +0100, Thierry Reding wrote:
> > On Fri, Dec 04, 2015 at 09:45:48AM +0100, Daniel Vetter wrote:
> > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > [...]
> > > + /**
> > > + * @destroy:
> > > + *
> > > + * Clean up CRTC resources. This is only called at driver unload time
> >
> > Perhaps drop "only" because there are more than a single potential
> > usage?
>
> It's for driver unload only since you can't hotplug planes. The only
> hotpluggable thing in drm atm are connectors, and I've added these blurbs
> to highlight that.
The complete hunk is this:
+ * Clean up CRTC resources. This is only called at driver unload time
+ * through drm_mode_config_cleanup(), but can also be called at runtime
+ * when a CRTC is being hot-unplugged.
If you say CRTCs aren't hotpluggable then the above is very confusing.
So either it is only called at driver unload time (which is what you're
saying, since CRTCs aren't hotpluggable) or it can be called in other
circumstances, in which case "only" is wrong.
So I think either drop the last subsentence to reflect the current
capabilities of the subsystem, or make it something like the following
to clarify:
The DRM subsystem doesn't currently support hotplugging CRTCs,
but eventually that feature might be added, at which point this
callback will be called when a CRTC in hot-unplugged.
But since nobody knows when this will happen it's somewhat premature, in
my opinion, to have such documentation. kerneldoc should document facts,
not the roadmap.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH 07/28] drm: Update drm_plane_funcs kerneldoc
2015-12-07 12:43 ` Thierry Reding
@ 2015-12-07 13:00 ` Daniel Vetter
0 siblings, 0 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-07 13:00 UTC (permalink / raw)
To: Thierry Reding
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
On Mon, Dec 07, 2015 at 01:43:49PM +0100, Thierry Reding wrote:
> On Mon, Dec 07, 2015 at 01:34:16PM +0100, Daniel Vetter wrote:
> > On Mon, Dec 07, 2015 at 12:46:38PM +0100, Thierry Reding wrote:
> > > On Fri, Dec 04, 2015 at 09:45:48AM +0100, Daniel Vetter wrote:
> > > > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > > [...]
> > > > + /**
> > > > + * @destroy:
> > > > + *
> > > > + * Clean up CRTC resources. This is only called at driver unload time
> > >
> > > Perhaps drop "only" because there are more than a single potential
> > > usage?
> >
> > It's for driver unload only since you can't hotplug planes. The only
> > hotpluggable thing in drm atm are connectors, and I've added these blurbs
> > to highlight that.
>
> The complete hunk is this:
>
> + * Clean up CRTC resources. This is only called at driver unload time
> + * through drm_mode_config_cleanup(), but can also be called at runtime
> + * when a CRTC is being hot-unplugged.
>
> If you say CRTCs aren't hotpluggable then the above is very confusing.
> So either it is only called at driver unload time (which is what you're
> saying, since CRTCs aren't hotpluggable) or it can be called in other
> circumstances, in which case "only" is wrong.
>
> So I think either drop the last subsentence to reflect the current
> capabilities of the subsystem, or make it something like the following
> to clarify:
>
> The DRM subsystem doesn't currently support hotplugging CRTCs,
> but eventually that feature might be added, at which point this
> callback will be called when a CRTC in hot-unplugged.
>
> But since nobody knows when this will happen it's somewhat premature, in
> my opinion, to have such documentation. kerneldoc should document facts,
> not the roadmap.
Oh dear I've been blind. Copy-pasta fail, the hotplugging stuff should
only be for connectors. Everything else (crtc, plane & encoder) is not
hopluggable. I also inserted a missing "a" while at it in these
paragraphs.
I made a total mess between plane, CRTC & connector here ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 08/28] drm/noveau: Ditch NULL save/restore hook assignments
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (6 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 07/28] drm: Update drm_plane_funcs kerneldoc Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 11:47 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 09/28] drm/qxl: Drop dummy save/restore hooks Daniel Vetter
` (19 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs
gcc does this for us, and these hooks will be gone soon.
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/nouveau/nouveau_connector.c | 6 ------
1 file changed, 6 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_connector.c b/drivers/gpu/drm/nouveau/nouveau_connector.c
index 2e7cbe933533..5dd1d0111cac 100644
--- a/drivers/gpu/drm/nouveau/nouveau_connector.c
+++ b/drivers/gpu/drm/nouveau/nouveau_connector.c
@@ -898,8 +898,6 @@ nouveau_connector_helper_funcs = {
static const struct drm_connector_funcs
nouveau_connector_funcs = {
.dpms = drm_helper_connector_dpms,
- .save = NULL,
- .restore = NULL,
.detect = nouveau_connector_detect,
.destroy = nouveau_connector_destroy,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -910,8 +908,6 @@ nouveau_connector_funcs = {
static const struct drm_connector_funcs
nouveau_connector_funcs_lvds = {
.dpms = drm_helper_connector_dpms,
- .save = NULL,
- .restore = NULL,
.detect = nouveau_connector_detect_lvds,
.destroy = nouveau_connector_destroy,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -944,8 +940,6 @@ nouveau_connector_dp_dpms(struct drm_connector *connector, int mode)
static const struct drm_connector_funcs
nouveau_connector_funcs_dp = {
.dpms = nouveau_connector_dp_dpms,
- .save = NULL,
- .restore = NULL,
.detect = nouveau_connector_detect,
.destroy = nouveau_connector_destroy,
.fill_modes = drm_helper_probe_single_connector_modes,
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 08/28] drm/noveau: Ditch NULL save/restore hook assignments
2015-12-04 8:45 ` [PATCH 08/28] drm/noveau: Ditch NULL save/restore hook assignments Daniel Vetter
@ 2015-12-07 11:47 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:47 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, Ben Skeggs, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 219 bytes --]
On Fri, Dec 04, 2015 at 09:45:49AM +0100, Daniel Vetter wrote:
> gcc does this for us, and these hooks will be gone soon.
In the subject: s/noveau/nouveau/, otherwise:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 09/28] drm/qxl: Drop dummy save/restore hooks
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (7 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 08/28] drm/noveau: Ditch NULL save/restore hook assignments Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 11:47 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 10/28] drm/virtio: Drop dummy save/restore functions Daniel Vetter
` (18 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Dave Airlie
These hooks will be gone soon.
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/qxl/qxl_display.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c b/drivers/gpu/drm/qxl/qxl_display.c
index cddba079197f..ebf7f3946a65 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -876,16 +876,6 @@ static const struct drm_connector_helper_funcs qxl_connector_helper_funcs = {
.best_encoder = qxl_best_encoder,
};
-static void qxl_conn_save(struct drm_connector *connector)
-{
- DRM_DEBUG("\n");
-}
-
-static void qxl_conn_restore(struct drm_connector *connector)
-{
- DRM_DEBUG("\n");
-}
-
static enum drm_connector_status qxl_conn_detect(
struct drm_connector *connector,
bool force)
@@ -932,8 +922,6 @@ static void qxl_conn_destroy(struct drm_connector *connector)
static const struct drm_connector_funcs qxl_connector_funcs = {
.dpms = drm_helper_connector_dpms,
- .save = qxl_conn_save,
- .restore = qxl_conn_restore,
.detect = qxl_conn_detect,
.fill_modes = drm_helper_probe_single_connector_modes_nomerge,
.set_property = qxl_conn_set_property,
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 09/28] drm/qxl: Drop dummy save/restore hooks
2015-12-04 8:45 ` [PATCH 09/28] drm/qxl: Drop dummy save/restore hooks Daniel Vetter
@ 2015-12-07 11:47 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:47 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Dave Airlie, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 350 bytes --]
On Fri, Dec 04, 2015 at 09:45:50AM +0100, Daniel Vetter wrote:
> These hooks will be gone soon.
>
> Cc: Dave Airlie <airlied@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 12 ------------
> 1 file changed, 12 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 10/28] drm/virtio: Drop dummy save/restore functions
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (8 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 09/28] drm/qxl: Drop dummy save/restore hooks Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 11:47 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 11/28] drm/vmwgfx: Drop dummy save/restore hooks Daniel Vetter
` (17 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Dave Airlie
These hooks will be gone soon.
Cc: Dave Airlie <airlied@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/virtio/virtgpu_display.c | 12 ------------
1 file changed, 12 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_display.c b/drivers/gpu/drm/virtio/virtgpu_display.c
index 8e6044d7660a..623c98cf024d 100644
--- a/drivers/gpu/drm/virtio/virtgpu_display.c
+++ b/drivers/gpu/drm/virtio/virtgpu_display.c
@@ -374,16 +374,6 @@ static const struct drm_connector_helper_funcs virtio_gpu_conn_helper_funcs = {
.best_encoder = virtio_gpu_best_encoder,
};
-static void virtio_gpu_conn_save(struct drm_connector *connector)
-{
- DRM_DEBUG("\n");
-}
-
-static void virtio_gpu_conn_restore(struct drm_connector *connector)
-{
- DRM_DEBUG("\n");
-}
-
static enum drm_connector_status virtio_gpu_conn_detect(
struct drm_connector *connector,
bool force)
@@ -409,8 +399,6 @@ static void virtio_gpu_conn_destroy(struct drm_connector *connector)
static const struct drm_connector_funcs virtio_gpu_connector_funcs = {
.dpms = drm_atomic_helper_connector_dpms,
- .save = virtio_gpu_conn_save,
- .restore = virtio_gpu_conn_restore,
.detect = virtio_gpu_conn_detect,
.fill_modes = drm_helper_probe_single_connector_modes_nomerge,
.destroy = virtio_gpu_conn_destroy,
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 10/28] drm/virtio: Drop dummy save/restore functions
2015-12-04 8:45 ` [PATCH 10/28] drm/virtio: Drop dummy save/restore functions Daniel Vetter
@ 2015-12-07 11:47 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:47 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Dave Airlie, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 357 bytes --]
On Fri, Dec 04, 2015 at 09:45:51AM +0100, Daniel Vetter wrote:
> These hooks will be gone soon.
>
> Cc: Dave Airlie <airlied@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/virtio/virtgpu_display.c | 12 ------------
> 1 file changed, 12 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 11/28] drm/vmwgfx: Drop dummy save/restore hooks
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (9 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 10/28] drm/virtio: Drop dummy save/restore functions Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 11:48 ` Thierry Reding
2015-12-08 11:55 ` Thomas Hellstrom
2015-12-04 8:45 ` [PATCH 12/28] drm/gma500: Move to private " Daniel Vetter
` (16 subsequent siblings)
27 siblings, 2 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Thomas Hellstrom
These hooks will be gone soon.
Cc: Thomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16 ----------------
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 ----
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ----
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ----
4 files changed, 28 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index e38db35132ed..d50596153679 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -1331,14 +1331,6 @@ static int vmw_du_update_layout(struct vmw_private *dev_priv, unsigned num,
return 0;
}
-void vmw_du_crtc_save(struct drm_crtc *crtc)
-{
-}
-
-void vmw_du_crtc_restore(struct drm_crtc *crtc)
-{
-}
-
void vmw_du_crtc_gamma_set(struct drm_crtc *crtc,
u16 *r, u16 *g, u16 *b,
uint32_t start, uint32_t size)
@@ -1360,14 +1352,6 @@ int vmw_du_connector_dpms(struct drm_connector *connector, int mode)
return 0;
}
-void vmw_du_connector_save(struct drm_connector *connector)
-{
-}
-
-void vmw_du_connector_restore(struct drm_connector *connector)
-{
-}
-
enum drm_connector_status
vmw_du_connector_detect(struct drm_connector *connector, bool force)
{
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
index bb63e4d795fa..c1c09b338cc1 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
@@ -295,8 +295,6 @@ static int vmw_ldu_crtc_set_config(struct drm_mode_set *set)
}
static struct drm_crtc_funcs vmw_legacy_crtc_funcs = {
- .save = vmw_du_crtc_save,
- .restore = vmw_du_crtc_restore,
.cursor_set = vmw_du_crtc_cursor_set,
.cursor_move = vmw_du_crtc_cursor_move,
.gamma_set = vmw_du_crtc_gamma_set,
@@ -329,8 +327,6 @@ static void vmw_ldu_connector_destroy(struct drm_connector *connector)
static struct drm_connector_funcs vmw_legacy_connector_funcs = {
.dpms = vmw_du_connector_dpms,
- .save = vmw_du_connector_save,
- .restore = vmw_du_connector_restore,
.detect = vmw_du_connector_detect,
.fill_modes = vmw_du_connector_fill_modes,
.set_property = vmw_du_connector_set_property,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index b96d1ab610c5..26dfed6b0c48 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -531,8 +531,6 @@ out_no_fence:
}
static struct drm_crtc_funcs vmw_screen_object_crtc_funcs = {
- .save = vmw_du_crtc_save,
- .restore = vmw_du_crtc_restore,
.cursor_set = vmw_du_crtc_cursor_set,
.cursor_move = vmw_du_crtc_cursor_move,
.gamma_set = vmw_du_crtc_gamma_set,
@@ -565,8 +563,6 @@ static void vmw_sou_connector_destroy(struct drm_connector *connector)
static struct drm_connector_funcs vmw_sou_connector_funcs = {
.dpms = vmw_du_connector_dpms,
- .save = vmw_du_connector_save,
- .restore = vmw_du_connector_restore,
.detect = vmw_du_connector_detect,
.fill_modes = vmw_du_connector_fill_modes,
.set_property = vmw_du_connector_set_property,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
index b1fc1c02792d..05375a8cc129 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
@@ -1041,8 +1041,6 @@ out_finish:
* Screen Target CRTC dispatch table
*/
static struct drm_crtc_funcs vmw_stdu_crtc_funcs = {
- .save = vmw_du_crtc_save,
- .restore = vmw_du_crtc_restore,
.cursor_set = vmw_du_crtc_cursor_set,
.cursor_move = vmw_du_crtc_cursor_move,
.gamma_set = vmw_du_crtc_gamma_set,
@@ -1101,8 +1099,6 @@ static void vmw_stdu_connector_destroy(struct drm_connector *connector)
static struct drm_connector_funcs vmw_stdu_connector_funcs = {
.dpms = vmw_du_connector_dpms,
- .save = vmw_du_connector_save,
- .restore = vmw_du_connector_restore,
.detect = vmw_du_connector_detect,
.fill_modes = vmw_du_connector_fill_modes,
.set_property = vmw_du_connector_set_property,
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 11/28] drm/vmwgfx: Drop dummy save/restore hooks
2015-12-04 8:45 ` [PATCH 11/28] drm/vmwgfx: Drop dummy save/restore hooks Daniel Vetter
@ 2015-12-07 11:48 ` Thierry Reding
2015-12-08 11:55 ` Thomas Hellstrom
1 sibling, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:48 UTC (permalink / raw)
To: Daniel Vetter
Cc: Intel Graphics Development, Thomas Hellstrom, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 519 bytes --]
On Fri, Dec 04, 2015 at 09:45:52AM +0100, Daniel Vetter wrote:
> These hooks will be gone soon.
>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16 ----------------
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 ----
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ----
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ----
> 4 files changed, 28 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH 11/28] drm/vmwgfx: Drop dummy save/restore hooks
2015-12-04 8:45 ` [PATCH 11/28] drm/vmwgfx: Drop dummy save/restore hooks Daniel Vetter
2015-12-07 11:48 ` Thierry Reding
@ 2015-12-08 11:55 ` Thomas Hellstrom
1 sibling, 0 replies; 81+ messages in thread
From: Thomas Hellstrom @ 2015-12-08 11:55 UTC (permalink / raw)
To: Daniel Vetter, DRI Development
Cc: Intel Graphics Development, linux-graphics-maintainer
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
On 12/04/2015 09:45 AM, Daniel Vetter wrote:
> These hooks will be gone soon.
>
> Cc: Thomas Hellstrom <thellstrom@vmware.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 16 ----------------
> drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c | 4 ----
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 4 ----
> drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 4 ----
> 4 files changed, 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> index e38db35132ed..d50596153679 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
> @@ -1331,14 +1331,6 @@ static int vmw_du_update_layout(struct vmw_private *dev_priv, unsigned num,
> return 0;
> }
>
> -void vmw_du_crtc_save(struct drm_crtc *crtc)
> -{
> -}
> -
> -void vmw_du_crtc_restore(struct drm_crtc *crtc)
> -{
> -}
> -
> void vmw_du_crtc_gamma_set(struct drm_crtc *crtc,
> u16 *r, u16 *g, u16 *b,
> uint32_t start, uint32_t size)
> @@ -1360,14 +1352,6 @@ int vmw_du_connector_dpms(struct drm_connector *connector, int mode)
> return 0;
> }
>
> -void vmw_du_connector_save(struct drm_connector *connector)
> -{
> -}
> -
> -void vmw_du_connector_restore(struct drm_connector *connector)
> -{
> -}
> -
> enum drm_connector_status
> vmw_du_connector_detect(struct drm_connector *connector, bool force)
> {
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> index bb63e4d795fa..c1c09b338cc1 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c
> @@ -295,8 +295,6 @@ static int vmw_ldu_crtc_set_config(struct drm_mode_set *set)
> }
>
> static struct drm_crtc_funcs vmw_legacy_crtc_funcs = {
> - .save = vmw_du_crtc_save,
> - .restore = vmw_du_crtc_restore,
> .cursor_set = vmw_du_crtc_cursor_set,
> .cursor_move = vmw_du_crtc_cursor_move,
> .gamma_set = vmw_du_crtc_gamma_set,
> @@ -329,8 +327,6 @@ static void vmw_ldu_connector_destroy(struct drm_connector *connector)
>
> static struct drm_connector_funcs vmw_legacy_connector_funcs = {
> .dpms = vmw_du_connector_dpms,
> - .save = vmw_du_connector_save,
> - .restore = vmw_du_connector_restore,
> .detect = vmw_du_connector_detect,
> .fill_modes = vmw_du_connector_fill_modes,
> .set_property = vmw_du_connector_set_property,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> index b96d1ab610c5..26dfed6b0c48 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
> @@ -531,8 +531,6 @@ out_no_fence:
> }
>
> static struct drm_crtc_funcs vmw_screen_object_crtc_funcs = {
> - .save = vmw_du_crtc_save,
> - .restore = vmw_du_crtc_restore,
> .cursor_set = vmw_du_crtc_cursor_set,
> .cursor_move = vmw_du_crtc_cursor_move,
> .gamma_set = vmw_du_crtc_gamma_set,
> @@ -565,8 +563,6 @@ static void vmw_sou_connector_destroy(struct drm_connector *connector)
>
> static struct drm_connector_funcs vmw_sou_connector_funcs = {
> .dpms = vmw_du_connector_dpms,
> - .save = vmw_du_connector_save,
> - .restore = vmw_du_connector_restore,
> .detect = vmw_du_connector_detect,
> .fill_modes = vmw_du_connector_fill_modes,
> .set_property = vmw_du_connector_set_property,
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> index b1fc1c02792d..05375a8cc129 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c
> @@ -1041,8 +1041,6 @@ out_finish:
> * Screen Target CRTC dispatch table
> */
> static struct drm_crtc_funcs vmw_stdu_crtc_funcs = {
> - .save = vmw_du_crtc_save,
> - .restore = vmw_du_crtc_restore,
> .cursor_set = vmw_du_crtc_cursor_set,
> .cursor_move = vmw_du_crtc_cursor_move,
> .gamma_set = vmw_du_crtc_gamma_set,
> @@ -1101,8 +1099,6 @@ static void vmw_stdu_connector_destroy(struct drm_connector *connector)
>
> static struct drm_connector_funcs vmw_stdu_connector_funcs = {
> .dpms = vmw_du_connector_dpms,
> - .save = vmw_du_connector_save,
> - .restore = vmw_du_connector_restore,
> .detect = vmw_du_connector_detect,
> .fill_modes = vmw_du_connector_fill_modes,
> .set_property = vmw_du_connector_set_property,
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 12/28] drm/gma500: Move to private save/restore hooks
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (10 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 11/28] drm/vmwgfx: Drop dummy save/restore hooks Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 11:51 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 13/28] drm/nouveau: Use " Daniel Vetter
` (15 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter
I want to remove the core ones since with atomic drivers system
suspend/resume is solved much differently. And there's only 2 drivers
(nouveau besides gma500) really using them.
Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/gma500/cdv_device.c | 2 ++
drivers/gpu/drm/gma500/cdv_intel_display.c | 2 --
drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 5 +++--
drivers/gpu/drm/gma500/cdv_intel_lvds.c | 4 ++--
drivers/gpu/drm/gma500/mdfld_device.c | 2 ++
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 5 +++--
drivers/gpu/drm/gma500/oaktrail_device.c | 2 ++
drivers/gpu/drm/gma500/psb_device.c | 22 ++++++++++++----------
drivers/gpu/drm/gma500/psb_drv.h | 2 ++
drivers/gpu/drm/gma500/psb_intel_display.c | 2 --
drivers/gpu/drm/gma500/psb_intel_drv.h | 3 +++
drivers/gpu/drm/gma500/psb_intel_lvds.c | 5 +++--
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 5 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 --
14 files changed, 37 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/gma500/cdv_device.c b/drivers/gpu/drm/gma500/cdv_device.c
index 3531f90e53d0..8745971a7680 100644
--- a/drivers/gpu/drm/gma500/cdv_device.c
+++ b/drivers/gpu/drm/gma500/cdv_device.c
@@ -619,6 +619,8 @@ const struct psb_ops cdv_chip_ops = {
.init_pm = cdv_init_pm,
.save_regs = cdv_save_display_registers,
.restore_regs = cdv_restore_display_registers,
+ .save_crtc = gma_crtc_save,
+ .restore_crtc = gma_crtc_restore,
.power_down = cdv_power_down,
.power_up = cdv_power_up,
.update_wm = cdv_update_wm,
diff --git a/drivers/gpu/drm/gma500/cdv_intel_display.c b/drivers/gpu/drm/gma500/cdv_intel_display.c
index 7d47b3d5cc0d..6126546295e9 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_display.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_display.c
@@ -983,8 +983,6 @@ const struct drm_crtc_helper_funcs cdv_intel_helper_funcs = {
};
const struct drm_crtc_funcs cdv_intel_crtc_funcs = {
- .save = gma_crtc_save,
- .restore = gma_crtc_restore,
.cursor_set = gma_crtc_cursor_set,
.cursor_move = gma_crtc_cursor_move,
.gamma_set = gma_crtc_gamma_set,
diff --git a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
index 6b1d3340ba14..e7b1e99fe2cc 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_hdmi.c
@@ -270,8 +270,6 @@ static const struct drm_connector_helper_funcs
static const struct drm_connector_funcs cdv_hdmi_connector_funcs = {
.dpms = drm_helper_connector_dpms,
- .save = cdv_hdmi_save,
- .restore = cdv_hdmi_restore,
.detect = cdv_hdmi_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = cdv_hdmi_set_property,
@@ -306,6 +304,9 @@ void cdv_hdmi_init(struct drm_device *dev,
connector = &gma_connector->base;
connector->polled = DRM_CONNECTOR_POLL_HPD;
+ gma_connector->save = cdv_hdmi_save;
+ gma_connector->restore = cdv_hdmi_restore;
+
encoder = &gma_encoder->base;
drm_connector_init(dev, connector,
&cdv_hdmi_connector_funcs,
diff --git a/drivers/gpu/drm/gma500/cdv_intel_lvds.c b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
index 211069b2b951..9e648bcb81a7 100644
--- a/drivers/gpu/drm/gma500/cdv_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/cdv_intel_lvds.c
@@ -530,8 +530,6 @@ static const struct drm_connector_helper_funcs
static const struct drm_connector_funcs cdv_intel_lvds_connector_funcs = {
.dpms = drm_helper_connector_dpms,
- .save = cdv_intel_lvds_save,
- .restore = cdv_intel_lvds_restore,
.detect = cdv_intel_lvds_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = cdv_intel_lvds_set_property,
@@ -643,6 +641,8 @@ void cdv_intel_lvds_init(struct drm_device *dev,
gma_encoder->dev_priv = lvds_priv;
connector = &gma_connector->base;
+ gma_connector->save = cdv_intel_lvds_save;
+ gma_connector->restore = cdv_intel_lvds_restore;
encoder = &gma_encoder->base;
diff --git a/drivers/gpu/drm/gma500/mdfld_device.c b/drivers/gpu/drm/gma500/mdfld_device.c
index 265ad0de44a6..e2ab858122f9 100644
--- a/drivers/gpu/drm/gma500/mdfld_device.c
+++ b/drivers/gpu/drm/gma500/mdfld_device.c
@@ -546,6 +546,8 @@ const struct psb_ops mdfld_chip_ops = {
.save_regs = mdfld_save_registers,
.restore_regs = mdfld_restore_registers,
+ .save_crtc = gma_crtc_save,
+ .restore_crtc = gma_crtc_restore,
.power_down = mdfld_power_down,
.power_up = mdfld_power_up,
};
diff --git a/drivers/gpu/drm/gma500/mdfld_dsi_output.c b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
index 89f705c3a5eb..d8f7bc2233aa 100644
--- a/drivers/gpu/drm/gma500/mdfld_dsi_output.c
+++ b/drivers/gpu/drm/gma500/mdfld_dsi_output.c
@@ -405,8 +405,6 @@ static struct drm_encoder *mdfld_dsi_connector_best_encoder(
/*DSI connector funcs*/
static const struct drm_connector_funcs mdfld_dsi_connector_funcs = {
.dpms = /*drm_helper_connector_dpms*/mdfld_dsi_connector_dpms,
- .save = mdfld_dsi_connector_save,
- .restore = mdfld_dsi_connector_restore,
.detect = mdfld_dsi_connector_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = mdfld_dsi_connector_set_property,
@@ -563,6 +561,9 @@ void mdfld_dsi_output_init(struct drm_device *dev,
connector = &dsi_connector->base.base;
+ connector->save = mdfld_dsi_connector_save;
+ connector->restore = mdfld_dsi_connector_restore;
+
drm_connector_init(dev, connector, &mdfld_dsi_connector_funcs,
DRM_MODE_CONNECTOR_LVDS);
drm_connector_helper_add(connector, &mdfld_dsi_connector_helper_funcs);
diff --git a/drivers/gpu/drm/gma500/oaktrail_device.c b/drivers/gpu/drm/gma500/oaktrail_device.c
index 368a03ae3010..ba30b43a3412 100644
--- a/drivers/gpu/drm/gma500/oaktrail_device.c
+++ b/drivers/gpu/drm/gma500/oaktrail_device.c
@@ -568,6 +568,8 @@ const struct psb_ops oaktrail_chip_ops = {
.save_regs = oaktrail_save_display_registers,
.restore_regs = oaktrail_restore_display_registers,
+ .save_crtc = gma_crtc_save,
+ .restore_crtc = gma_crtc_restore,
.power_down = oaktrail_power_down,
.power_up = oaktrail_power_up,
diff --git a/drivers/gpu/drm/gma500/psb_device.c b/drivers/gpu/drm/gma500/psb_device.c
index 07df7d4eea72..dc0f8527570c 100644
--- a/drivers/gpu/drm/gma500/psb_device.c
+++ b/drivers/gpu/drm/gma500/psb_device.c
@@ -181,7 +181,7 @@ static int psb_save_display_registers(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc;
- struct drm_connector *connector;
+ struct gma_connector *connector;
struct psb_state *regs = &dev_priv->regs.psb;
/* Display arbitration control + watermarks */
@@ -198,12 +198,12 @@ static int psb_save_display_registers(struct drm_device *dev)
drm_modeset_lock_all(dev);
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
if (drm_helper_crtc_in_use(crtc))
- crtc->funcs->save(crtc);
+ dev_priv->ops->save_crtc(crtc);
}
- list_for_each_entry(connector, &dev->mode_config.connector_list, head)
- if (connector->funcs->save)
- connector->funcs->save(connector);
+ list_for_each_entry(connector, &dev->mode_config.connector_list, base.head)
+ if (connector->save)
+ connector->save(&connector->base);
drm_modeset_unlock_all(dev);
return 0;
@@ -219,7 +219,7 @@ static int psb_restore_display_registers(struct drm_device *dev)
{
struct drm_psb_private *dev_priv = dev->dev_private;
struct drm_crtc *crtc;
- struct drm_connector *connector;
+ struct gma_connector *connector;
struct psb_state *regs = &dev_priv->regs.psb;
/* Display arbitration + watermarks */
@@ -238,11 +238,11 @@ static int psb_restore_display_registers(struct drm_device *dev)
drm_modeset_lock_all(dev);
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
if (drm_helper_crtc_in_use(crtc))
- crtc->funcs->restore(crtc);
+ dev_priv->ops->restore_crtc(crtc);
- list_for_each_entry(connector, &dev->mode_config.connector_list, head)
- if (connector->funcs->restore)
- connector->funcs->restore(connector);
+ list_for_each_entry(connector, &dev->mode_config.connector_list, base.head)
+ if (connector->restore)
+ connector->restore(&connector->base);
drm_modeset_unlock_all(dev);
return 0;
@@ -354,6 +354,8 @@ const struct psb_ops psb_chip_ops = {
.init_pm = psb_init_pm,
.save_regs = psb_save_display_registers,
.restore_regs = psb_restore_display_registers,
+ .save_crtc = gma_crtc_save,
+ .restore_crtc = gma_crtc_restore,
.power_down = psb_power_down,
.power_up = psb_power_up,
};
diff --git a/drivers/gpu/drm/gma500/psb_drv.h b/drivers/gpu/drm/gma500/psb_drv.h
index 3bd2c726dd61..b74372760d7f 100644
--- a/drivers/gpu/drm/gma500/psb_drv.h
+++ b/drivers/gpu/drm/gma500/psb_drv.h
@@ -653,6 +653,8 @@ struct psb_ops {
void (*init_pm)(struct drm_device *dev);
int (*save_regs)(struct drm_device *dev);
int (*restore_regs)(struct drm_device *dev);
+ void (*save_crtc)(struct drm_crtc *crtc);
+ void (*restore_crtc)(struct drm_crtc *crtc);
int (*power_up)(struct drm_device *dev);
int (*power_down)(struct drm_device *dev);
void (*update_wm)(struct drm_device *dev, struct drm_crtc *crtc);
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c b/drivers/gpu/drm/gma500/psb_intel_display.c
index b2d483ccc88e..45a3206be051 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -439,8 +439,6 @@ const struct drm_crtc_helper_funcs psb_intel_helper_funcs = {
};
const struct drm_crtc_funcs psb_intel_crtc_funcs = {
- .save = gma_crtc_save,
- .restore = gma_crtc_restore,
.cursor_set = gma_crtc_cursor_set,
.cursor_move = gma_crtc_cursor_move,
.gamma_set = gma_crtc_gamma_set,
diff --git a/drivers/gpu/drm/gma500/psb_intel_drv.h b/drivers/gpu/drm/gma500/psb_intel_drv.h
index 860dd2177ca1..2a3b7c684db2 100644
--- a/drivers/gpu/drm/gma500/psb_intel_drv.h
+++ b/drivers/gpu/drm/gma500/psb_intel_drv.h
@@ -140,6 +140,9 @@ struct gma_encoder {
struct gma_connector {
struct drm_connector base;
struct gma_encoder *encoder;
+
+ void (*save)(struct drm_connector *connector);
+ void (*restore)(struct drm_connector *connector);
};
struct psb_intel_crtc_state {
diff --git a/drivers/gpu/drm/gma500/psb_intel_lvds.c b/drivers/gpu/drm/gma500/psb_intel_lvds.c
index ce0645d0c1e5..0d6143702b86 100644
--- a/drivers/gpu/drm/gma500/psb_intel_lvds.c
+++ b/drivers/gpu/drm/gma500/psb_intel_lvds.c
@@ -653,8 +653,6 @@ const struct drm_connector_helper_funcs
const struct drm_connector_funcs psb_intel_lvds_connector_funcs = {
.dpms = drm_helper_connector_dpms,
- .save = psb_intel_lvds_save,
- .restore = psb_intel_lvds_restore,
.detect = psb_intel_lvds_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = psb_intel_lvds_set_property,
@@ -715,6 +713,9 @@ void psb_intel_lvds_init(struct drm_device *dev,
gma_encoder->dev_priv = lvds_priv;
connector = &gma_connector->base;
+ gma_connector->save = psb_intel_lvds_save;
+ gma_connector->restore = psb_intel_lvds_restore;
+
encoder = &gma_encoder->base;
drm_connector_init(dev, connector,
&psb_intel_lvds_connector_funcs,
diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
index 58529cea575d..86f28ac1e673 100644
--- a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
+++ b/drivers/gpu/drm/gma500/psb_intel_sdvo.c
@@ -1837,8 +1837,6 @@ static const struct drm_encoder_helper_funcs psb_intel_sdvo_helper_funcs = {
static const struct drm_connector_funcs psb_intel_sdvo_connector_funcs = {
.dpms = drm_helper_connector_dpms,
- .save = psb_intel_sdvo_save,
- .restore = psb_intel_sdvo_restore,
.detect = psb_intel_sdvo_detect,
.fill_modes = drm_helper_probe_single_connector_modes,
.set_property = psb_intel_sdvo_set_property,
@@ -2021,6 +2019,9 @@ psb_intel_sdvo_connector_init(struct psb_intel_sdvo_connector *connector,
connector->base.base.doublescan_allowed = 0;
connector->base.base.display_info.subpixel_order = SubPixelHorizontalRGB;
+ connector->base.save = psb_intel_sdvo_save;
+ connector->base.restore = psb_intel_sdvo_restore;
+
gma_connector_attach_encoder(&connector->base, &encoder->base);
drm_connector_register(&connector->base.base);
}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
index 26dfed6b0c48..5379dc4bbcac 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c
@@ -563,8 +563,6 @@ static void vmw_sou_connector_destroy(struct drm_connector *connector)
static struct drm_connector_funcs vmw_sou_connector_funcs = {
.dpms = vmw_du_connector_dpms,
- .detect = vmw_du_connector_detect,
- .fill_modes = vmw_du_connector_fill_modes,
.set_property = vmw_du_connector_set_property,
.destroy = vmw_sou_connector_destroy,
};
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 12/28] drm/gma500: Move to private save/restore hooks
2015-12-04 8:45 ` [PATCH 12/28] drm/gma500: Move to private " Daniel Vetter
@ 2015-12-07 11:51 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:51 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 1288 bytes --]
On Fri, Dec 04, 2015 at 09:45:53AM +0100, Daniel Vetter wrote:
> I want to remove the core ones since with atomic drivers system
> suspend/resume is solved much differently. And there's only 2 drivers
> (nouveau besides gma500) really using them.
>
> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> drivers/gpu/drm/gma500/cdv_device.c | 2 ++
> drivers/gpu/drm/gma500/cdv_intel_display.c | 2 --
> drivers/gpu/drm/gma500/cdv_intel_hdmi.c | 5 +++--
> drivers/gpu/drm/gma500/cdv_intel_lvds.c | 4 ++--
> drivers/gpu/drm/gma500/mdfld_device.c | 2 ++
> drivers/gpu/drm/gma500/mdfld_dsi_output.c | 5 +++--
> drivers/gpu/drm/gma500/oaktrail_device.c | 2 ++
> drivers/gpu/drm/gma500/psb_device.c | 22 ++++++++++++----------
> drivers/gpu/drm/gma500/psb_drv.h | 2 ++
> drivers/gpu/drm/gma500/psb_intel_display.c | 2 --
> drivers/gpu/drm/gma500/psb_intel_drv.h | 3 +++
> drivers/gpu/drm/gma500/psb_intel_lvds.c | 5 +++--
> drivers/gpu/drm/gma500/psb_intel_sdvo.c | 5 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 2 --
> 14 files changed, 37 insertions(+), 26 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 13/28] drm/nouveau: Use private save/restore hooks
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (11 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 12/28] drm/gma500: Move to private " Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-04 14:31 ` Ilia Mirkin
2015-12-04 16:13 ` [PATCH] drm/nouveau: Use private save/restore hooks for CRTCs Daniel Vetter
2015-12-04 8:45 ` [PATCH 14/28] drm: Remove crtc/connector->save/restore hooks Daniel Vetter
` (14 subsequent siblings)
27 siblings, 2 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs, Daniel Vetter
I want to remove the core ones since with atomic drivers system
suspend/resume is solved much differently. And there's only 2 drivers
(gma500 besides nouveau) really using them.
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 5 +++--
drivers/gpu/drm/nouveau/dispnv04/disp.c | 11 ++++++-----
drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 +++
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index dab24066fa21..bb9e9cb14b9d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1081,8 +1081,6 @@ nouveau_crtc_set_config(struct drm_mode_set *set)
}
static const struct drm_crtc_funcs nv04_crtc_funcs = {
- .save = nv_crtc_save,
- .restore = nv_crtc_restore,
.cursor_set = nv04_crtc_cursor_set,
.cursor_move = nv04_crtc_cursor_move,
.gamma_set = nv_crtc_gamma_set,
@@ -1123,6 +1121,9 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
nv_crtc->index = crtc_num;
nv_crtc->last_dpms = NV_DPMS_CLEARED;
+ nv_crtc->save = nv_crtc_save;
+ nv_crtc->restore = nv_crtc_restore;
+
drm_crtc_init(dev, &nv_crtc->base, &nv04_crtc_funcs);
drm_crtc_helper_add(&nv_crtc->base, &nv04_crtc_helper_funcs);
drm_mode_crtc_set_gamma_size(&nv_crtc->base, 256);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 9e650081c357..ebd9430e0628 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -39,7 +39,7 @@ nv04_display_create(struct drm_device *dev)
struct dcb_table *dcb = &drm->vbios.dcb;
struct drm_connector *connector, *ct;
struct drm_encoder *encoder;
- struct drm_crtc *crtc;
+ struct nouveau_crtc *crtc;
struct nv04_display *disp;
int i, ret;
@@ -107,8 +107,8 @@ nv04_display_create(struct drm_device *dev)
}
/* Save previous state */
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- crtc->funcs->save(crtc);
+ list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
+ crtc->save(crtc);
list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
const struct drm_encoder_helper_funcs *func = encoder->helper_private;
@@ -128,6 +128,7 @@ nv04_display_destroy(struct drm_device *dev)
struct nouveau_drm *drm = nouveau_drm(dev);
struct drm_encoder *encoder;
struct drm_crtc *crtc;
+ struct nouveau_crtc *nv_crtc;
/* Turn every CRTC off. */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
@@ -145,8 +146,8 @@ nv04_display_destroy(struct drm_device *dev)
func->restore(encoder);
}
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- crtc->funcs->restore(crtc);
+ list_for_each_entry(nv_crtc, &dev->mode_config.crtc_list, base.head)
+ nv_crtc->restore(crtc);
nouveau_hw_save_vga_fonts(dev, 0);
diff --git a/drivers/gpu/drm/nouveau/nouveau_crtc.h b/drivers/gpu/drm/nouveau/nouveau_crtc.h
index f19cb1c5fc5a..863f10b8d818 100644
--- a/drivers/gpu/drm/nouveau/nouveau_crtc.h
+++ b/drivers/gpu/drm/nouveau/nouveau_crtc.h
@@ -73,6 +73,9 @@ struct nouveau_crtc {
int (*set_dither)(struct nouveau_crtc *crtc, bool update);
int (*set_scale)(struct nouveau_crtc *crtc, bool update);
int (*set_color_vibrance)(struct nouveau_crtc *crtc, bool update);
+
+ void (*save)(struct drm_crtc *crtc);
+ void (*restore)(struct drm_crtc *crtc);
};
static inline struct nouveau_crtc *nouveau_crtc(struct drm_crtc *crtc)
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 13/28] drm/nouveau: Use private save/restore hooks
2015-12-04 8:45 ` [PATCH 13/28] drm/nouveau: Use " Daniel Vetter
@ 2015-12-04 14:31 ` Ilia Mirkin
2015-12-04 16:06 ` Daniel Vetter
2015-12-04 16:13 ` [PATCH] drm/nouveau: Use private save/restore hooks for CRTCs Daniel Vetter
1 sibling, 1 reply; 81+ messages in thread
From: Ilia Mirkin @ 2015-12-04 14:31 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs, DRI Development
On Fri, Dec 4, 2015 at 3:45 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> I want to remove the core ones since with atomic drivers system
> suspend/resume is solved much differently. And there's only 2 drivers
> (gma500 besides nouveau) really using them.
>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 5 +++--
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 11 ++++++-----
> drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 +++
> 3 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> index dab24066fa21..bb9e9cb14b9d 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> @@ -1081,8 +1081,6 @@ nouveau_crtc_set_config(struct drm_mode_set *set)
> }
>
> static const struct drm_crtc_funcs nv04_crtc_funcs = {
> - .save = nv_crtc_save,
> - .restore = nv_crtc_restore,
> .cursor_set = nv04_crtc_cursor_set,
> .cursor_move = nv04_crtc_cursor_move,
> .gamma_set = nv_crtc_gamma_set,
> @@ -1123,6 +1121,9 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
> nv_crtc->index = crtc_num;
> nv_crtc->last_dpms = NV_DPMS_CLEARED;
>
> + nv_crtc->save = nv_crtc_save;
> + nv_crtc->restore = nv_crtc_restore;
> +
> drm_crtc_init(dev, &nv_crtc->base, &nv04_crtc_funcs);
> drm_crtc_helper_add(&nv_crtc->base, &nv04_crtc_helper_funcs);
> drm_mode_crtc_set_gamma_size(&nv_crtc->base, 256);
> diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> index 9e650081c357..ebd9430e0628 100644
> --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> @@ -39,7 +39,7 @@ nv04_display_create(struct drm_device *dev)
> struct dcb_table *dcb = &drm->vbios.dcb;
> struct drm_connector *connector, *ct;
> struct drm_encoder *encoder;
> - struct drm_crtc *crtc;
> + struct nouveau_crtc *crtc;
> struct nv04_display *disp;
> int i, ret;
>
> @@ -107,8 +107,8 @@ nv04_display_create(struct drm_device *dev)
> }
>
> /* Save previous state */
> - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> - crtc->funcs->save(crtc);
> + list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
> + crtc->save(crtc);
Won't this warn about incompatible types? (function wants drm_crtc,
but you're giving it nouveau_crtc)?
>
> list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
> const struct drm_encoder_helper_funcs *func = encoder->helper_private;
> @@ -128,6 +128,7 @@ nv04_display_destroy(struct drm_device *dev)
> struct nouveau_drm *drm = nouveau_drm(dev);
> struct drm_encoder *encoder;
> struct drm_crtc *crtc;
> + struct nouveau_crtc *nv_crtc;
>
> /* Turn every CRTC off. */
> list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> @@ -145,8 +146,8 @@ nv04_display_destroy(struct drm_device *dev)
> func->restore(encoder);
> }
>
> - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> - crtc->funcs->restore(crtc);
> + list_for_each_entry(nv_crtc, &dev->mode_config.crtc_list, base.head)
> + nv_crtc->restore(crtc);
Why is this OK? Don't you want to use nv_crtc here as the function argument?
>
> nouveau_hw_save_vga_fonts(dev, 0);
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_crtc.h b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> index f19cb1c5fc5a..863f10b8d818 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_crtc.h
> +++ b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> @@ -73,6 +73,9 @@ struct nouveau_crtc {
> int (*set_dither)(struct nouveau_crtc *crtc, bool update);
> int (*set_scale)(struct nouveau_crtc *crtc, bool update);
> int (*set_color_vibrance)(struct nouveau_crtc *crtc, bool update);
> +
> + void (*save)(struct drm_crtc *crtc);
> + void (*restore)(struct drm_crtc *crtc);
> };
>
> static inline struct nouveau_crtc *nouveau_crtc(struct drm_crtc *crtc)
> --
> 2.5.1
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 13/28] drm/nouveau: Use private save/restore hooks
2015-12-04 14:31 ` Ilia Mirkin
@ 2015-12-04 16:06 ` Daniel Vetter
0 siblings, 0 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 16:06 UTC (permalink / raw)
To: Ilia Mirkin
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs,
DRI Development, Daniel Vetter
On Fri, Dec 04, 2015 at 09:31:01AM -0500, Ilia Mirkin wrote:
> On Fri, Dec 4, 2015 at 3:45 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > I want to remove the core ones since with atomic drivers system
> > suspend/resume is solved much differently. And there's only 2 drivers
> > (gma500 besides nouveau) really using them.
> >
> > Cc: Ben Skeggs <bskeggs@redhat.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> > ---
> > drivers/gpu/drm/nouveau/dispnv04/crtc.c | 5 +++--
> > drivers/gpu/drm/nouveau/dispnv04/disp.c | 11 ++++++-----
> > drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 +++
> > 3 files changed, 12 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > index dab24066fa21..bb9e9cb14b9d 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
> > @@ -1081,8 +1081,6 @@ nouveau_crtc_set_config(struct drm_mode_set *set)
> > }
> >
> > static const struct drm_crtc_funcs nv04_crtc_funcs = {
> > - .save = nv_crtc_save,
> > - .restore = nv_crtc_restore,
> > .cursor_set = nv04_crtc_cursor_set,
> > .cursor_move = nv04_crtc_cursor_move,
> > .gamma_set = nv_crtc_gamma_set,
> > @@ -1123,6 +1121,9 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
> > nv_crtc->index = crtc_num;
> > nv_crtc->last_dpms = NV_DPMS_CLEARED;
> >
> > + nv_crtc->save = nv_crtc_save;
> > + nv_crtc->restore = nv_crtc_restore;
> > +
> > drm_crtc_init(dev, &nv_crtc->base, &nv04_crtc_funcs);
> > drm_crtc_helper_add(&nv_crtc->base, &nv04_crtc_helper_funcs);
> > drm_mode_crtc_set_gamma_size(&nv_crtc->base, 256);
> > diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > index 9e650081c357..ebd9430e0628 100644
> > --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
> > @@ -39,7 +39,7 @@ nv04_display_create(struct drm_device *dev)
> > struct dcb_table *dcb = &drm->vbios.dcb;
> > struct drm_connector *connector, *ct;
> > struct drm_encoder *encoder;
> > - struct drm_crtc *crtc;
> > + struct nouveau_crtc *crtc;
> > struct nv04_display *disp;
> > int i, ret;
> >
> > @@ -107,8 +107,8 @@ nv04_display_create(struct drm_device *dev)
> > }
> >
> > /* Save previous state */
> > - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> > - crtc->funcs->save(crtc);
> > + list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
> > + crtc->save(crtc);
>
> Won't this warn about incompatible types? (function wants drm_crtc,
> but you're giving it nouveau_crtc)?
Because I misapplied a hunk and it's in the next nouveau patch ;-)
>
> >
> > list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
> > const struct drm_encoder_helper_funcs *func = encoder->helper_private;
> > @@ -128,6 +128,7 @@ nv04_display_destroy(struct drm_device *dev)
> > struct nouveau_drm *drm = nouveau_drm(dev);
> > struct drm_encoder *encoder;
> > struct drm_crtc *crtc;
> > + struct nouveau_crtc *nv_crtc;
> >
> > /* Turn every CRTC off. */
> > list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
> > @@ -145,8 +146,8 @@ nv04_display_destroy(struct drm_device *dev)
> > func->restore(encoder);
> > }
> >
> > - list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
> > - crtc->funcs->restore(crtc);
> > + list_for_each_entry(nv_crtc, &dev->mode_config.crtc_list, base.head)
> > + nv_crtc->restore(crtc);
>
> Why is this OK? Don't you want to use nv_crtc here as the function argument?
Total bullocks and embarrassing. Will resend both.
-Daniel
>
> >
> > nouveau_hw_save_vga_fonts(dev, 0);
> >
> > diff --git a/drivers/gpu/drm/nouveau/nouveau_crtc.h b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> > index f19cb1c5fc5a..863f10b8d818 100644
> > --- a/drivers/gpu/drm/nouveau/nouveau_crtc.h
> > +++ b/drivers/gpu/drm/nouveau/nouveau_crtc.h
> > @@ -73,6 +73,9 @@ struct nouveau_crtc {
> > int (*set_dither)(struct nouveau_crtc *crtc, bool update);
> > int (*set_scale)(struct nouveau_crtc *crtc, bool update);
> > int (*set_color_vibrance)(struct nouveau_crtc *crtc, bool update);
> > +
> > + void (*save)(struct drm_crtc *crtc);
> > + void (*restore)(struct drm_crtc *crtc);
> > };
> >
> > static inline struct nouveau_crtc *nouveau_crtc(struct drm_crtc *crtc)
> > --
> > 2.5.1
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH] drm/nouveau: Use private save/restore hooks for CRTCs
2015-12-04 8:45 ` [PATCH 13/28] drm/nouveau: Use " Daniel Vetter
2015-12-04 14:31 ` Ilia Mirkin
@ 2015-12-04 16:13 ` Daniel Vetter
2015-12-07 11:51 ` Thierry Reding
1 sibling, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 16:13 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs,
Ilia Mirkin, Daniel Vetter
I want to remove the core ones since with atomic drivers system
suspend/resume is solved much differently. And there's only 2 drivers
(gma500 besides nouveau) really using them.
v2: Fixup bugs Ilia spotted.
Cc: Ben Skeggs <bskeggs@redhat.com>
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/nouveau/dispnv04/crtc.c | 5 +++--
drivers/gpu/drm/nouveau/dispnv04/disp.c | 11 ++++++-----
drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 +++
3 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index dab24066fa21..bb9e9cb14b9d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -1081,8 +1081,6 @@ nouveau_crtc_set_config(struct drm_mode_set *set)
}
static const struct drm_crtc_funcs nv04_crtc_funcs = {
- .save = nv_crtc_save,
- .restore = nv_crtc_restore,
.cursor_set = nv04_crtc_cursor_set,
.cursor_move = nv04_crtc_cursor_move,
.gamma_set = nv_crtc_gamma_set,
@@ -1123,6 +1121,9 @@ nv04_crtc_create(struct drm_device *dev, int crtc_num)
nv_crtc->index = crtc_num;
nv_crtc->last_dpms = NV_DPMS_CLEARED;
+ nv_crtc->save = nv_crtc_save;
+ nv_crtc->restore = nv_crtc_restore;
+
drm_crtc_init(dev, &nv_crtc->base, &nv04_crtc_funcs);
drm_crtc_helper_add(&nv_crtc->base, &nv04_crtc_helper_funcs);
drm_mode_crtc_set_gamma_size(&nv_crtc->base, 256);
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 9e650081c357..59242ff767ea 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -39,7 +39,7 @@ nv04_display_create(struct drm_device *dev)
struct dcb_table *dcb = &drm->vbios.dcb;
struct drm_connector *connector, *ct;
struct drm_encoder *encoder;
- struct drm_crtc *crtc;
+ struct nouveau_crtc *crtc;
struct nv04_display *disp;
int i, ret;
@@ -107,8 +107,8 @@ nv04_display_create(struct drm_device *dev)
}
/* Save previous state */
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- crtc->funcs->save(crtc);
+ list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
+ crtc->save(&crtc->base);
list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
const struct drm_encoder_helper_funcs *func = encoder->helper_private;
@@ -128,6 +128,7 @@ nv04_display_destroy(struct drm_device *dev)
struct nouveau_drm *drm = nouveau_drm(dev);
struct drm_encoder *encoder;
struct drm_crtc *crtc;
+ struct nouveau_crtc *nv_crtc;
/* Turn every CRTC off. */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, head) {
@@ -145,8 +146,8 @@ nv04_display_destroy(struct drm_device *dev)
func->restore(encoder);
}
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- crtc->funcs->restore(crtc);
+ list_for_each_entry(nv_crtc, &dev->mode_config.crtc_list, base.head)
+ nv_crtc->restore(&nv_crtc->base);
nouveau_hw_save_vga_fonts(dev, 0);
diff --git a/drivers/gpu/drm/nouveau/nouveau_crtc.h b/drivers/gpu/drm/nouveau/nouveau_crtc.h
index f19cb1c5fc5a..863f10b8d818 100644
--- a/drivers/gpu/drm/nouveau/nouveau_crtc.h
+++ b/drivers/gpu/drm/nouveau/nouveau_crtc.h
@@ -73,6 +73,9 @@ struct nouveau_crtc {
int (*set_dither)(struct nouveau_crtc *crtc, bool update);
int (*set_scale)(struct nouveau_crtc *crtc, bool update);
int (*set_color_vibrance)(struct nouveau_crtc *crtc, bool update);
+
+ void (*save)(struct drm_crtc *crtc);
+ void (*restore)(struct drm_crtc *crtc);
};
static inline struct nouveau_crtc *nouveau_crtc(struct drm_crtc *crtc)
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH] drm/nouveau: Use private save/restore hooks for CRTCs
2015-12-04 16:13 ` [PATCH] drm/nouveau: Use private save/restore hooks for CRTCs Daniel Vetter
@ 2015-12-07 11:51 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:51 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 733 bytes --]
On Fri, Dec 04, 2015 at 05:13:38PM +0100, Daniel Vetter wrote:
> I want to remove the core ones since with atomic drivers system
> suspend/resume is solved much differently. And there's only 2 drivers
> (gma500 besides nouveau) really using them.
>
> v2: Fixup bugs Ilia spotted.
>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Cc: Ilia Mirkin <imirkin@alum.mit.edu>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> drivers/gpu/drm/nouveau/dispnv04/crtc.c | 5 +++--
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 11 ++++++-----
> drivers/gpu/drm/nouveau/nouveau_crtc.h | 3 +++
> 3 files changed, 12 insertions(+), 7 deletions(-)
Looks good to me:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 14/28] drm: Remove crtc/connector->save/restore hooks
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (12 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 13/28] drm/nouveau: Use " Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 11:55 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 15/28] drm: Move encoder->save/restore into nouveau Daniel Vetter
` (13 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter
They're not how system suspend/resume should be done with atomic
(there's new helpers for that developed by Thierry Redding), and for
legacy drivers this really should be a helper hook and not a core one.
But there's not even helper code to use them, and only 2 drivers
(which now have their own private hooks) set them. Ditch them.
Saves me typing some kerneldoc, too ;-)
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
include/drm/drm_crtc.h | 11 -----------
1 file changed, 11 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 340d750f1364..6c92da82f8c5 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -320,8 +320,6 @@ struct drm_crtc_state {
/**
* struct drm_crtc_funcs - control CRTCs for a given device
- * @save: save CRTC state
- * @restore: restore CRTC state
* @cursor_set: setup the cursor
* @cursor_set2: setup the cursor with hotspot, superseeds @cursor_set if set
* @cursor_move: move the cursor
@@ -339,11 +337,6 @@ struct drm_crtc_state {
* bus accessors.
*/
struct drm_crtc_funcs {
- /* Save CRTC state */
- void (*save)(struct drm_crtc *crtc); /* suspend? */
- /* Restore CRTC state */
- void (*restore)(struct drm_crtc *crtc); /* resume? */
-
/**
* @reset:
*
@@ -626,8 +619,6 @@ struct drm_connector_state {
/**
* struct drm_connector_funcs - control connectors on a given device
* @dpms: set power state
- * @save: save connector state
- * @restore: restore connector state
* @detect: is this connector active?
* @fill_modes: fill mode list for this connector
* @force: notify the driver that the connector is forced on
@@ -638,8 +629,6 @@ struct drm_connector_state {
*/
struct drm_connector_funcs {
int (*dpms)(struct drm_connector *connector, int mode);
- void (*save)(struct drm_connector *connector);
- void (*restore)(struct drm_connector *connector);
/**
* @reset:
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 14/28] drm: Remove crtc/connector->save/restore hooks
2015-12-04 8:45 ` [PATCH 14/28] drm: Remove crtc/connector->save/restore hooks Daniel Vetter
@ 2015-12-07 11:55 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:55 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 690 bytes --]
On Fri, Dec 04, 2015 at 09:45:55AM +0100, Daniel Vetter wrote:
> They're not how system suspend/resume should be done with atomic
> (there's new helpers for that developed by Thierry Redding), and for
s/Redding/Reding/ =)
> legacy drivers this really should be a helper hook and not a core one.
>
> But there's not even helper code to use them, and only 2 drivers
> (which now have their own private hooks) set them. Ditch them.
>
> Saves me typing some kerneldoc, too ;-)
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> include/drm/drm_crtc.h | 11 -----------
> 1 file changed, 11 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 15/28] drm: Move encoder->save/restore into nouveau
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (13 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 14/28] drm: Remove crtc/connector->save/restore hooks Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-04 16:14 ` [PATCH] " Daniel Vetter
2015-12-04 8:45 ` [PATCH 16/28] drm: Document drm_atomic_*_get_property Daniel Vetter
` (12 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs, Daniel Vetter
Nouveau is the only user, and atomic drivers should do state
save/restoring differently. So move it into noveau.
Saves me typing some kerneldoc, too ;-)
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/nouveau/dispnv04/dac.c | 7 +++----
drivers/gpu/drm/nouveau/dispnv04/dfp.c | 7 +++----
drivers/gpu/drm/nouveau/dispnv04/disp.c | 34 ++++++++++++-------------------
drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 5 +++--
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 5 +++--
drivers/gpu/drm/nouveau/nouveau_encoder.h | 3 +++
include/drm/drm_modeset_helper_vtables.h | 4 ----
7 files changed, 28 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dac.c b/drivers/gpu/drm/nouveau/dispnv04/dac.c
index 78cb033bc015..6c442def403d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dac.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dac.c
@@ -504,8 +504,6 @@ static void nv04_dac_destroy(struct drm_encoder *encoder)
static const struct drm_encoder_helper_funcs nv04_dac_helper_funcs = {
.dpms = nv04_dac_dpms,
- .save = nv04_dac_save,
- .restore = nv04_dac_restore,
.mode_fixup = nv04_dac_mode_fixup,
.prepare = nv04_dac_prepare,
.commit = nv04_dac_commit,
@@ -515,8 +513,6 @@ static const struct drm_encoder_helper_funcs nv04_dac_helper_funcs = {
static const struct drm_encoder_helper_funcs nv17_dac_helper_funcs = {
.dpms = nv04_dac_dpms,
- .save = nv04_dac_save,
- .restore = nv04_dac_restore,
.mode_fixup = nv04_dac_mode_fixup,
.prepare = nv04_dac_prepare,
.commit = nv04_dac_commit,
@@ -545,6 +541,9 @@ nv04_dac_create(struct drm_connector *connector, struct dcb_output *entry)
nv_encoder->dcb = entry;
nv_encoder->or = ffs(entry->or) - 1;
+ nv_encoder->enc_save = nv04_dac_save;
+ nv_encoder->enc_restore = nv04_dac_restore;
+
if (nv_gf4_disp_arch(dev))
helper = &nv17_dac_helper_funcs;
else
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index 429ab5e3025a..4c5fb89d74db 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -652,8 +652,6 @@ static void nv04_tmds_slave_init(struct drm_encoder *encoder)
static const struct drm_encoder_helper_funcs nv04_lvds_helper_funcs = {
.dpms = nv04_lvds_dpms,
- .save = nv04_dfp_save,
- .restore = nv04_dfp_restore,
.mode_fixup = nv04_dfp_mode_fixup,
.prepare = nv04_dfp_prepare,
.commit = nv04_dfp_commit,
@@ -663,8 +661,6 @@ static const struct drm_encoder_helper_funcs nv04_lvds_helper_funcs = {
static const struct drm_encoder_helper_funcs nv04_tmds_helper_funcs = {
.dpms = nv04_tmds_dpms,
- .save = nv04_dfp_save,
- .restore = nv04_dfp_restore,
.mode_fixup = nv04_dfp_mode_fixup,
.prepare = nv04_dfp_prepare,
.commit = nv04_dfp_commit,
@@ -701,6 +697,9 @@ nv04_dfp_create(struct drm_connector *connector, struct dcb_output *entry)
if (!nv_encoder)
return -ENOMEM;
+ nv_encoder->enc_save = nv04_dfp_save;
+ nv_encoder->enc_restore = nv04_dfp_restore;
+
encoder = to_drm_encoder(nv_encoder);
nv_encoder->dcb = entry;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index ebd9430e0628..449d92a2175e 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -39,6 +39,7 @@ nv04_display_create(struct drm_device *dev)
struct dcb_table *dcb = &drm->vbios.dcb;
struct drm_connector *connector, *ct;
struct drm_encoder *encoder;
+ struct nouveau_encoder *nv_encoder;
struct nouveau_crtc *crtc;
struct nv04_display *disp;
int i, ret;
@@ -108,13 +109,10 @@ nv04_display_create(struct drm_device *dev)
/* Save previous state */
list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
- crtc->save(crtc);
+ crtc->save(&crtc->base);
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
- const struct drm_encoder_helper_funcs *func = encoder->helper_private;
-
- func->save(encoder);
- }
+ list_for_each_entry(nv_encoder, &dev->mode_config.encoder_list, base.base.head)
+ nv_encoder->enc_save(&nv_encoder->base.base);
nouveau_overlay_init(dev);
@@ -126,7 +124,7 @@ nv04_display_destroy(struct drm_device *dev)
{
struct nv04_display *disp = nv04_display(dev);
struct nouveau_drm *drm = nouveau_drm(dev);
- struct drm_encoder *encoder;
+ struct nouveau_encoder *encoder;
struct drm_crtc *crtc;
struct nouveau_crtc *nv_crtc;
@@ -140,11 +138,8 @@ nv04_display_destroy(struct drm_device *dev)
}
/* Restore state */
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
- const struct drm_encoder_helper_funcs *func = encoder->helper_private;
-
- func->restore(encoder);
- }
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.base.head)
+ encoder->enc_restore(&encoder->base.base);
list_for_each_entry(nv_crtc, &dev->mode_config.crtc_list, base.head)
nv_crtc->restore(crtc);
@@ -160,8 +155,8 @@ nv04_display_destroy(struct drm_device *dev)
int
nv04_display_init(struct drm_device *dev)
{
- struct drm_encoder *encoder;
- struct drm_crtc *crtc;
+ struct nouveau_encoder *encoder;
+ struct nouveau_crtc *crtc;
/* meh.. modeset apparently doesn't setup all the regs and depends
* on pre-existing state, for now load the state of the card *before*
@@ -171,14 +166,11 @@ nv04_display_init(struct drm_device *dev)
* save/restore "pre-load" state, but more general so we can save
* on suspend too.
*/
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
- const struct drm_encoder_helper_funcs *func = encoder->helper_private;
-
- func->restore(encoder);
- }
+ list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
+ crtc->save(&crtc->base);
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- crtc->funcs->restore(crtc);
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.base.head)
+ encoder->enc_save(&encoder->base.base);
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c b/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
index 5345eb5378a8..91d689400d2e 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
@@ -192,8 +192,6 @@ static const struct drm_encoder_funcs nv04_tv_funcs = {
static const struct drm_encoder_helper_funcs nv04_tv_helper_funcs = {
.dpms = nv04_tv_dpms,
- .save = drm_i2c_encoder_save,
- .restore = drm_i2c_encoder_restore,
.mode_fixup = drm_i2c_encoder_mode_fixup,
.prepare = nv04_tv_prepare,
.commit = nv04_tv_commit,
@@ -228,6 +226,9 @@ nv04_tv_create(struct drm_connector *connector, struct dcb_output *entry)
drm_encoder_init(dev, encoder, &nv04_tv_funcs, DRM_MODE_ENCODER_TVDAC);
drm_encoder_helper_add(encoder, &nv04_tv_helper_funcs);
+ nv_encoder->enc_save = drm_i2c_encoder_save;
+ nv_encoder->enc_restore = drm_i2c_encoder_restore;
+
encoder->possible_crtcs = entry->heads;
encoder->possible_clones = 0;
nv_encoder->dcb = entry;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index b734195d80a0..ff8c55866b18 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -771,8 +771,6 @@ static void nv17_tv_destroy(struct drm_encoder *encoder)
static struct drm_encoder_helper_funcs nv17_tv_helper_funcs = {
.dpms = nv17_tv_dpms,
- .save = nv17_tv_save,
- .restore = nv17_tv_restore,
.mode_fixup = nv17_tv_mode_fixup,
.prepare = nv17_tv_prepare,
.commit = nv17_tv_commit,
@@ -820,6 +818,9 @@ nv17_tv_create(struct drm_connector *connector, struct dcb_output *entry)
drm_encoder_helper_add(encoder, &nv17_tv_helper_funcs);
to_encoder_slave(encoder)->slave_funcs = &nv17_tv_slave_funcs;
+ tv_enc->base.enc_save = nv17_tv_save;
+ tv_enc->base.enc_restore = nv17_tv_restore;
+
encoder->possible_crtcs = entry->heads;
encoder->possible_clones = 0;
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index b37da95105b0..c38a86408363 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -63,6 +63,9 @@ struct nouveau_encoder {
u32 datarate;
} dp;
};
+
+ void (*enc_save)(struct drm_encoder *encoder);
+ void (*enc_restore)(struct drm_encoder *encoder);
};
struct nouveau_encoder *
diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
index 35c5a1c4e7ba..bc731754fc70 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -126,8 +126,6 @@ static inline void drm_crtc_helper_add(struct drm_crtc *crtc,
/**
* struct drm_encoder_helper_funcs - helper operations for encoders
* @dpms: set power state
- * @save: save connector state
- * @restore: restore connector state
* @mode_fixup: try to fixup proposed mode for this connector
* @prepare: part of the disable sequence, called before the CRTC modeset
* @commit: called after the CRTC modeset
@@ -149,8 +147,6 @@ static inline void drm_crtc_helper_add(struct drm_crtc *crtc,
*/
struct drm_encoder_helper_funcs {
void (*dpms)(struct drm_encoder *encoder, int mode);
- void (*save)(struct drm_encoder *encoder);
- void (*restore)(struct drm_encoder *encoder);
bool (*mode_fixup)(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* [PATCH] drm: Move encoder->save/restore into nouveau
2015-12-04 8:45 ` [PATCH 15/28] drm: Move encoder->save/restore into nouveau Daniel Vetter
@ 2015-12-04 16:14 ` Daniel Vetter
2015-12-07 11:59 ` Thierry Reding
0 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 16:14 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs,
Ilia Mirkin, Daniel Vetter
Nouveau is the only user, and atomic drivers should do state
save/restoring differently. So move it into noveau.
Saves me typing some kerneldoc, too ;-)
v2: Move misplaced hunk into earlier nouveau patch.
Cc: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/nouveau/dispnv04/dac.c | 7 +++----
drivers/gpu/drm/nouveau/dispnv04/dfp.c | 7 +++----
drivers/gpu/drm/nouveau/dispnv04/disp.c | 32 ++++++++++++-------------------
drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 5 +++--
drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 5 +++--
drivers/gpu/drm/nouveau/nouveau_encoder.h | 3 +++
include/drm/drm_modeset_helper_vtables.h | 4 ----
7 files changed, 27 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dac.c b/drivers/gpu/drm/nouveau/dispnv04/dac.c
index 78cb033bc015..6c442def403d 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dac.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dac.c
@@ -504,8 +504,6 @@ static void nv04_dac_destroy(struct drm_encoder *encoder)
static const struct drm_encoder_helper_funcs nv04_dac_helper_funcs = {
.dpms = nv04_dac_dpms,
- .save = nv04_dac_save,
- .restore = nv04_dac_restore,
.mode_fixup = nv04_dac_mode_fixup,
.prepare = nv04_dac_prepare,
.commit = nv04_dac_commit,
@@ -515,8 +513,6 @@ static const struct drm_encoder_helper_funcs nv04_dac_helper_funcs = {
static const struct drm_encoder_helper_funcs nv17_dac_helper_funcs = {
.dpms = nv04_dac_dpms,
- .save = nv04_dac_save,
- .restore = nv04_dac_restore,
.mode_fixup = nv04_dac_mode_fixup,
.prepare = nv04_dac_prepare,
.commit = nv04_dac_commit,
@@ -545,6 +541,9 @@ nv04_dac_create(struct drm_connector *connector, struct dcb_output *entry)
nv_encoder->dcb = entry;
nv_encoder->or = ffs(entry->or) - 1;
+ nv_encoder->enc_save = nv04_dac_save;
+ nv_encoder->enc_restore = nv04_dac_restore;
+
if (nv_gf4_disp_arch(dev))
helper = &nv17_dac_helper_funcs;
else
diff --git a/drivers/gpu/drm/nouveau/dispnv04/dfp.c b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
index 429ab5e3025a..4c5fb89d74db 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/dfp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/dfp.c
@@ -652,8 +652,6 @@ static void nv04_tmds_slave_init(struct drm_encoder *encoder)
static const struct drm_encoder_helper_funcs nv04_lvds_helper_funcs = {
.dpms = nv04_lvds_dpms,
- .save = nv04_dfp_save,
- .restore = nv04_dfp_restore,
.mode_fixup = nv04_dfp_mode_fixup,
.prepare = nv04_dfp_prepare,
.commit = nv04_dfp_commit,
@@ -663,8 +661,6 @@ static const struct drm_encoder_helper_funcs nv04_lvds_helper_funcs = {
static const struct drm_encoder_helper_funcs nv04_tmds_helper_funcs = {
.dpms = nv04_tmds_dpms,
- .save = nv04_dfp_save,
- .restore = nv04_dfp_restore,
.mode_fixup = nv04_dfp_mode_fixup,
.prepare = nv04_dfp_prepare,
.commit = nv04_dfp_commit,
@@ -701,6 +697,9 @@ nv04_dfp_create(struct drm_connector *connector, struct dcb_output *entry)
if (!nv_encoder)
return -ENOMEM;
+ nv_encoder->enc_save = nv04_dfp_save;
+ nv_encoder->enc_restore = nv04_dfp_restore;
+
encoder = to_drm_encoder(nv_encoder);
nv_encoder->dcb = entry;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c b/drivers/gpu/drm/nouveau/dispnv04/disp.c
index 59242ff767ea..b4a6bc433ef5 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c
@@ -39,6 +39,7 @@ nv04_display_create(struct drm_device *dev)
struct dcb_table *dcb = &drm->vbios.dcb;
struct drm_connector *connector, *ct;
struct drm_encoder *encoder;
+ struct nouveau_encoder *nv_encoder;
struct nouveau_crtc *crtc;
struct nv04_display *disp;
int i, ret;
@@ -110,11 +111,8 @@ nv04_display_create(struct drm_device *dev)
list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
crtc->save(&crtc->base);
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
- const struct drm_encoder_helper_funcs *func = encoder->helper_private;
-
- func->save(encoder);
- }
+ list_for_each_entry(nv_encoder, &dev->mode_config.encoder_list, base.base.head)
+ nv_encoder->enc_save(&nv_encoder->base.base);
nouveau_overlay_init(dev);
@@ -126,7 +124,7 @@ nv04_display_destroy(struct drm_device *dev)
{
struct nv04_display *disp = nv04_display(dev);
struct nouveau_drm *drm = nouveau_drm(dev);
- struct drm_encoder *encoder;
+ struct nouveau_encoder *encoder;
struct drm_crtc *crtc;
struct nouveau_crtc *nv_crtc;
@@ -140,11 +138,8 @@ nv04_display_destroy(struct drm_device *dev)
}
/* Restore state */
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
- const struct drm_encoder_helper_funcs *func = encoder->helper_private;
-
- func->restore(encoder);
- }
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.base.head)
+ encoder->enc_restore(&encoder->base.base);
list_for_each_entry(nv_crtc, &dev->mode_config.crtc_list, base.head)
nv_crtc->restore(&nv_crtc->base);
@@ -160,8 +155,8 @@ nv04_display_destroy(struct drm_device *dev)
int
nv04_display_init(struct drm_device *dev)
{
- struct drm_encoder *encoder;
- struct drm_crtc *crtc;
+ struct nouveau_encoder *encoder;
+ struct nouveau_crtc *crtc;
/* meh.. modeset apparently doesn't setup all the regs and depends
* on pre-existing state, for now load the state of the card *before*
@@ -171,14 +166,11 @@ nv04_display_init(struct drm_device *dev)
* save/restore "pre-load" state, but more general so we can save
* on suspend too.
*/
- list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) {
- const struct drm_encoder_helper_funcs *func = encoder->helper_private;
-
- func->restore(encoder);
- }
+ list_for_each_entry(crtc, &dev->mode_config.crtc_list, base.head)
+ crtc->save(&crtc->base);
- list_for_each_entry(crtc, &dev->mode_config.crtc_list, head)
- crtc->funcs->restore(crtc);
+ list_for_each_entry(encoder, &dev->mode_config.encoder_list, base.base.head)
+ encoder->enc_save(&encoder->base.base);
return 0;
}
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c b/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
index 5345eb5378a8..91d689400d2e 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv04.c
@@ -192,8 +192,6 @@ static const struct drm_encoder_funcs nv04_tv_funcs = {
static const struct drm_encoder_helper_funcs nv04_tv_helper_funcs = {
.dpms = nv04_tv_dpms,
- .save = drm_i2c_encoder_save,
- .restore = drm_i2c_encoder_restore,
.mode_fixup = drm_i2c_encoder_mode_fixup,
.prepare = nv04_tv_prepare,
.commit = nv04_tv_commit,
@@ -228,6 +226,9 @@ nv04_tv_create(struct drm_connector *connector, struct dcb_output *entry)
drm_encoder_init(dev, encoder, &nv04_tv_funcs, DRM_MODE_ENCODER_TVDAC);
drm_encoder_helper_add(encoder, &nv04_tv_helper_funcs);
+ nv_encoder->enc_save = drm_i2c_encoder_save;
+ nv_encoder->enc_restore = drm_i2c_encoder_restore;
+
encoder->possible_crtcs = entry->heads;
encoder->possible_clones = 0;
nv_encoder->dcb = entry;
diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
index b734195d80a0..ff8c55866b18 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c
@@ -771,8 +771,6 @@ static void nv17_tv_destroy(struct drm_encoder *encoder)
static struct drm_encoder_helper_funcs nv17_tv_helper_funcs = {
.dpms = nv17_tv_dpms,
- .save = nv17_tv_save,
- .restore = nv17_tv_restore,
.mode_fixup = nv17_tv_mode_fixup,
.prepare = nv17_tv_prepare,
.commit = nv17_tv_commit,
@@ -820,6 +818,9 @@ nv17_tv_create(struct drm_connector *connector, struct dcb_output *entry)
drm_encoder_helper_add(encoder, &nv17_tv_helper_funcs);
to_encoder_slave(encoder)->slave_funcs = &nv17_tv_slave_funcs;
+ tv_enc->base.enc_save = nv17_tv_save;
+ tv_enc->base.enc_restore = nv17_tv_restore;
+
encoder->possible_crtcs = entry->heads;
encoder->possible_clones = 0;
diff --git a/drivers/gpu/drm/nouveau/nouveau_encoder.h b/drivers/gpu/drm/nouveau/nouveau_encoder.h
index b37da95105b0..c38a86408363 100644
--- a/drivers/gpu/drm/nouveau/nouveau_encoder.h
+++ b/drivers/gpu/drm/nouveau/nouveau_encoder.h
@@ -63,6 +63,9 @@ struct nouveau_encoder {
u32 datarate;
} dp;
};
+
+ void (*enc_save)(struct drm_encoder *encoder);
+ void (*enc_restore)(struct drm_encoder *encoder);
};
struct nouveau_encoder *
diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
index 35c5a1c4e7ba..bc731754fc70 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -126,8 +126,6 @@ static inline void drm_crtc_helper_add(struct drm_crtc *crtc,
/**
* struct drm_encoder_helper_funcs - helper operations for encoders
* @dpms: set power state
- * @save: save connector state
- * @restore: restore connector state
* @mode_fixup: try to fixup proposed mode for this connector
* @prepare: part of the disable sequence, called before the CRTC modeset
* @commit: called after the CRTC modeset
@@ -149,8 +147,6 @@ static inline void drm_crtc_helper_add(struct drm_crtc *crtc,
*/
struct drm_encoder_helper_funcs {
void (*dpms)(struct drm_encoder *encoder, int mode);
- void (*save)(struct drm_encoder *encoder);
- void (*restore)(struct drm_encoder *encoder);
bool (*mode_fixup)(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH] drm: Move encoder->save/restore into nouveau
2015-12-04 16:14 ` [PATCH] " Daniel Vetter
@ 2015-12-07 11:59 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 11:59 UTC (permalink / raw)
To: Daniel Vetter
Cc: Daniel Vetter, Intel Graphics Development, Ben Skeggs, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 972 bytes --]
On Fri, Dec 04, 2015 at 05:14:07PM +0100, Daniel Vetter wrote:
> Nouveau is the only user, and atomic drivers should do state
> save/restoring differently. So move it into noveau.
>
> Saves me typing some kerneldoc, too ;-)
>
> v2: Move misplaced hunk into earlier nouveau patch.
>
> Cc: Ilia Mirkin <imirkin@alum.mit.edu>
> Cc: Ben Skeggs <bskeggs@redhat.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> drivers/gpu/drm/nouveau/dispnv04/dac.c | 7 +++----
> drivers/gpu/drm/nouveau/dispnv04/dfp.c | 7 +++----
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 32 ++++++++++++-------------------
> drivers/gpu/drm/nouveau/dispnv04/tvnv04.c | 5 +++--
> drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 5 +++--
> drivers/gpu/drm/nouveau/nouveau_encoder.h | 3 +++
> include/drm/drm_modeset_helper_vtables.h | 4 ----
> 7 files changed, 27 insertions(+), 36 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 16/28] drm: Document drm_atomic_*_get_property
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (14 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 15/28] drm: Move encoder->save/restore into nouveau Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 12:01 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 17/28] drm: Document drm_connector_funcs Daniel Vetter
` (11 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development
Yes these are internal functions and not exported and we generally
don't document them. But for symmetry with the _set_property functions
(which are exported for the atomic helpers) I'd like to document them.
Upcoming vtable kerneldoc will reference both the set and get_property
functions.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
Documentation/DocBook/gpu.tmpl | 1 +
drivers/gpu/drm/drm_atomic.c | 33 ++++++++++++++++++++++++++++++---
2 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 23ad100c2bf5..02c7d44f517c 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -946,6 +946,7 @@ int max_width, max_height;</synopsis>
<sect2>
<title>Atomic Mode Setting Function Reference</title>
!Edrivers/gpu/drm/drm_atomic.c
+!Idrivers/gpu/drm/drm_atomic.c
</sect2>
<sect2>
<title>Frame Buffer Creation</title>
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index ef5f7663a718..7426d40017a0 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -429,11 +429,20 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
}
EXPORT_SYMBOL(drm_atomic_crtc_set_property);
-/*
+/**
+ * drm_atomic_crtc_get_property - get property value from CRTC state
+ * @crtc: the drm CRTC to set a property on
+ * @state: the state object to get the property value from
+ * @property: the property to set
+ * @val: pointer to where the value should be written to
+ *
* This function handles generic/core properties and calls out to
* driver's ->atomic_get_property() for driver properties. To ensure
* consistent behavior you must call this function rather than the
* driver hook directly.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
*/
static int
drm_atomic_crtc_get_property(struct drm_crtc *crtc,
@@ -616,11 +625,20 @@ int drm_atomic_plane_set_property(struct drm_plane *plane,
}
EXPORT_SYMBOL(drm_atomic_plane_set_property);
-/*
+/**
+ * drm_atomic_plane_get_property - get property value from plane state
+ * @plane: the drm plane to set a property on
+ * @state: the state object to get the property value from
+ * @property: the property to set
+ * @val: pointer to where the value should be written to
+ *
* This function handles generic/core properties and calls out to
* driver's ->atomic_get_property() for driver properties. To ensure
* consistent behavior you must call this function rather than the
* driver hook directly.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
*/
static int
drm_atomic_plane_get_property(struct drm_plane *plane,
@@ -872,11 +890,20 @@ int drm_atomic_connector_set_property(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_atomic_connector_set_property);
-/*
+/**
+ * drm_atomic_connector_get_property - get property value from connector state
+ * @connector: the drm connector to set a property on
+ * @state: the state object to get the property value from
+ * @property: the property to set
+ * @val: pointer to where the value should be written to
+ *
* This function handles generic/core properties and calls out to
* driver's ->atomic_get_property() for driver properties. To ensure
* consistent behavior you must call this function rather than the
* driver hook directly.
+ *
+ * RETURNS:
+ * Zero on success, error code on failure
*/
static int
drm_atomic_connector_get_property(struct drm_connector *connector,
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 16/28] drm: Document drm_atomic_*_get_property
2015-12-04 8:45 ` [PATCH 16/28] drm: Document drm_atomic_*_get_property Daniel Vetter
@ 2015-12-07 12:01 ` Thierry Reding
2015-12-07 12:51 ` Daniel Vetter
0 siblings, 1 reply; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 12:01 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 1925 bytes --]
On Fri, Dec 04, 2015 at 09:45:57AM +0100, Daniel Vetter wrote:
> Yes these are internal functions and not exported and we generally
> don't document them. But for symmetry with the _set_property functions
> (which are exported for the atomic helpers) I'd like to document them.
> Upcoming vtable kerneldoc will reference both the set and get_property
> functions.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> Documentation/DocBook/gpu.tmpl | 1 +
> drivers/gpu/drm/drm_atomic.c | 33 ++++++++++++++++++++++++++++++---
> 2 files changed, 31 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 23ad100c2bf5..02c7d44f517c 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -946,6 +946,7 @@ int max_width, max_height;</synopsis>
> <sect2>
> <title>Atomic Mode Setting Function Reference</title>
> !Edrivers/gpu/drm/drm_atomic.c
> +!Idrivers/gpu/drm/drm_atomic.c
> </sect2>
> <sect2>
> <title>Frame Buffer Creation</title>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index ef5f7663a718..7426d40017a0 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -429,11 +429,20 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> }
> EXPORT_SYMBOL(drm_atomic_crtc_set_property);
>
> -/*
> +/**
> + * drm_atomic_crtc_get_property - get property value from CRTC state
> + * @crtc: the drm CRTC to set a property on
> + * @state: the state object to get the property value from
> + * @property: the property to set
> + * @val: pointer to where the value should be written to
Nit: I find this difficult to write and read, and I prefer the wording
"return location for the property value". But either way:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* Re: [PATCH 16/28] drm: Document drm_atomic_*_get_property
2015-12-07 12:01 ` Thierry Reding
@ 2015-12-07 12:51 ` Daniel Vetter
0 siblings, 0 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-07 12:51 UTC (permalink / raw)
To: Thierry Reding; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
On Mon, Dec 07, 2015 at 01:01:35PM +0100, Thierry Reding wrote:
> On Fri, Dec 04, 2015 at 09:45:57AM +0100, Daniel Vetter wrote:
> > Yes these are internal functions and not exported and we generally
> > don't document them. But for symmetry with the _set_property functions
> > (which are exported for the atomic helpers) I'd like to document them.
> > Upcoming vtable kerneldoc will reference both the set and get_property
> > functions.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > ---
> > Documentation/DocBook/gpu.tmpl | 1 +
> > drivers/gpu/drm/drm_atomic.c | 33 ++++++++++++++++++++++++++++++---
> > 2 files changed, 31 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> > index 23ad100c2bf5..02c7d44f517c 100644
> > --- a/Documentation/DocBook/gpu.tmpl
> > +++ b/Documentation/DocBook/gpu.tmpl
> > @@ -946,6 +946,7 @@ int max_width, max_height;</synopsis>
> > <sect2>
> > <title>Atomic Mode Setting Function Reference</title>
> > !Edrivers/gpu/drm/drm_atomic.c
> > +!Idrivers/gpu/drm/drm_atomic.c
> > </sect2>
> > <sect2>
> > <title>Frame Buffer Creation</title>
> > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > index ef5f7663a718..7426d40017a0 100644
> > --- a/drivers/gpu/drm/drm_atomic.c
> > +++ b/drivers/gpu/drm/drm_atomic.c
> > @@ -429,11 +429,20 @@ int drm_atomic_crtc_set_property(struct drm_crtc *crtc,
> > }
> > EXPORT_SYMBOL(drm_atomic_crtc_set_property);
> >
> > -/*
> > +/**
> > + * drm_atomic_crtc_get_property - get property value from CRTC state
> > + * @crtc: the drm CRTC to set a property on
> > + * @state: the state object to get the property value from
> > + * @property: the property to set
> > + * @val: pointer to where the value should be written to
>
> Nit: I find this difficult to write and read, and I prefer the wording
> "return location for the property value". But either way:
Yeah that reads much better. Changed all 3 places in drm_atomic. We might
want to have a style guide for DRM docs for these things ...
-Daniel
>
> Reviewed-by: Thierry Reding <treding@nvidia.com>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 17/28] drm: Document drm_connector_funcs
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (15 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 16/28] drm: Document drm_atomic_*_get_property Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 12:05 ` Thierry Reding
2015-12-04 8:45 ` [PATCH 18/28] drm: connector->dpms is not optional Daniel Vetter
` (10 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter
The special case here is that both ->detect and ->force are actually
functions only called by the probe helpers and hence really shouldn't
be here. But since they've used by pretty much every driver I figured
it's better to just document this for now instead of holding this doc
patch hostage until that's all fixed. For that reason also group force
right next to detect.
v2: Use FIXME comments to annotate where we should move a hook to
helpers.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
include/drm/drm_crtc.h | 84 ++++++++++++++++++++++++++++++++++++++++++++------
1 file changed, 74 insertions(+), 10 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 6c92da82f8c5..fbfe617bc492 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -618,16 +618,28 @@ struct drm_connector_state {
/**
* struct drm_connector_funcs - control connectors on a given device
- * @dpms: set power state
- * @detect: is this connector active?
- * @fill_modes: fill mode list for this connector
- * @force: notify the driver that the connector is forced on
*
* Each CRTC may have one or more connectors attached to it. The functions
* below allow the core DRM code to control connectors, enumerate available modes,
* etc.
*/
struct drm_connector_funcs {
+ /**
+ * @dpms:
+ *
+ * Legacy entry point to set the per-connector DPMS state. Legacy DPMS
+ * is exposed as a standard property on the connector, but diverted to
+ * this callback in the drm core. Note that atomic drivers don't
+ * implement the 4 level DPMS support on the connector any more, but
+ * instead only have an on/off "ACTIVE" property on the CRTC object.
+ *
+ * Drivers implementing atomic modeset should use
+ * drm_atomic_helper_connector_dpms() to implement this hook.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*dpms)(struct drm_connector *connector, int mode);
/**
@@ -642,14 +654,67 @@ struct drm_connector_funcs {
*/
void (*reset)(struct drm_connector *connector);
- /* Check to see if anything is attached to the connector.
- * @force is set to false whilst polling, true when checking the
- * connector due to user request. @force can be used by the driver
- * to avoid expensive, destructive operations during automated
- * probing.
+ /**
+ * @detect:
+ *
+ * Check to see if anything is attached to the connector. The parameter
+ * force is set to false whilst polling, true when checking the
+ * connector due to a user request. force can be used by the driver to
+ * avoid expensive, destructive operations during automated probing.
+ *
+ * FIXME:
+ *
+ * Note that this hook is only called by the probe helper. It's not in
+ * the helper library vtable purely for historical reasons. The only DRM
+ * core entry point to probe connector state is @fill_modes.
+ *
+ * RETURNS:
+ *
+ * drm_connector_status indicating the connector's status.
*/
enum drm_connector_status (*detect)(struct drm_connector *connector,
bool force);
+
+ /**
+ * @force:
+ *
+ * This function is called to update internal encoder state when the
+ * connector is forced to a certain state by userspace, either through
+ * the sysfs interfaces or on the kernel cmdline. In that case the
+ * @detect callback isn't called.
+ *
+ * FIXME:
+ *
+ * Note that this hook is only called by the probe helper. It's not in
+ * the helper library vtable purely for historical reasons. The only DRM
+ * core entry point to probe connector state is @fill_modes.
+ */
+ void (*force)(struct drm_connector *connector);
+
+ /**
+ * @fill_modes:
+ *
+ * Entry point for output detection and basic mode validation. The
+ * driver should reprobe the output if needed (e.g. when hotplug
+ * handling is unreliable), add all detected modes to connector->modes
+ * and filter out any the device can't support in any configuration. It
+ * also needs to filter out any modes wider or higher than the
+ * parameters max_width and max_height indicate.
+ *
+ * The drivers must also prune any modes no longer valid from
+ * connector->modes. Furthermore it must update connector->status and
+ * connector->edid. If no EDID has been received for this output
+ * connector->edid must be NULL.
+ *
+ * Drivers using the probe helpers should use
+ * drm_helper_probe_single_connector_modes() or
+ * drm_helper_probe_single_connector_modes_nomerge() to implement this
+ * function.
+ *
+ * RETURNS:
+ *
+ * The number of modes detected and filled into connector->modes.
+ */
int (*fill_modes)(struct drm_connector *connector, uint32_t max_width, uint32_t max_height);
/**
@@ -679,7 +744,6 @@ struct drm_connector_funcs {
* when a connector is being hot-unplugged.
*/
void (*destroy)(struct drm_connector *connector);
- void (*force)(struct drm_connector *connector);
/**
* @atomic_duplicate_state:
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 17/28] drm: Document drm_connector_funcs
2015-12-04 8:45 ` [PATCH 17/28] drm: Document drm_connector_funcs Daniel Vetter
@ 2015-12-07 12:05 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 12:05 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 797 bytes --]
On Fri, Dec 04, 2015 at 09:45:58AM +0100, Daniel Vetter wrote:
> The special case here is that both ->detect and ->force are actually
> functions only called by the probe helpers and hence really shouldn't
> be here. But since they've used by pretty much every driver I figured
> it's better to just document this for now instead of holding this doc
> patch hostage until that's all fixed. For that reason also group force
> right next to detect.
>
> v2: Use FIXME comments to annotate where we should move a hook to
> helpers.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> include/drm/drm_crtc.h | 84 ++++++++++++++++++++++++++++++++++++++++++++------
> 1 file changed, 74 insertions(+), 10 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 18/28] drm: connector->dpms is not optional
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (16 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 17/28] drm: Document drm_connector_funcs Daniel Vetter
@ 2015-12-04 8:45 ` Daniel Vetter
2015-12-07 12:06 ` Thierry Reding
2015-12-04 8:46 ` [PATCH 19/28] drm: document drm_crtc_funcs Daniel Vetter
` (9 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:45 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development
We always register the DPMS property, it's really a fundamental
part of a display driver. So don't check whether the vfunc is there,
it's non-optional
Yes I've audited all the almost 100 drm_connector_funcs we have, no
one botched this ;-)
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/drm_crtc.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 40ec79e3f0fc..92ca63335a8d 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -4785,9 +4785,7 @@ static int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
/* Do DPMS ourselves */
if (property == connector->dev->mode_config.dpms_property) {
- ret = 0;
- if (connector->funcs->dpms)
- ret = (*connector->funcs->dpms)(connector, (int)value);
+ ret = (*connector->funcs->dpms)(connector, (int)value);
} else if (connector->funcs->set_property)
ret = connector->funcs->set_property(connector, property, value);
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 18/28] drm: connector->dpms is not optional
2015-12-04 8:45 ` [PATCH 18/28] drm: connector->dpms is not optional Daniel Vetter
@ 2015-12-07 12:06 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 12:06 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 534 bytes --]
On Fri, Dec 04, 2015 at 09:45:59AM +0100, Daniel Vetter wrote:
> We always register the DPMS property, it's really a fundamental
> part of a display driver. So don't check whether the vfunc is there,
> it's non-optional
>
> Yes I've audited all the almost 100 drm_connector_funcs we have, no
> one botched this ;-)
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/drm_crtc.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 19/28] drm: document drm_crtc_funcs
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (17 preceding siblings ...)
2015-12-04 8:45 ` [PATCH 18/28] drm: connector->dpms is not optional Daniel Vetter
@ 2015-12-04 8:46 ` Daniel Vetter
2015-12-07 12:25 ` Thierry Reding
2015-12-04 8:46 ` [PATCH 20/28] drm: Add kerneldoc for drm_framebuffer_funcs Daniel Vetter
` (8 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:46 UTC (permalink / raw)
To: DRI Development
Cc: Daniel Vetter, Daniel Vetter, Intel Graphics Development, Eric Anholt
And merge any docbook we have into the kerneldoc comments.
Since it's a legacy entry point with only two implementation (one each
in atomic and legacy crtc helpers) I've made the documentation for
set_config fairly sparse - no one should ever need to look at this
again, all the ABI we have is baked into code.
For ->page_flip otoh I kept all the extensive docs from the docbook
and even extended it where it was lacking: Currently we have a pile of
legacy page_flip implemantations, and even for atomic drivers there's
not yet a standard implementation in the helpers. Which means every
driver needs to implement this itself, and precise specs are really
valuable.
Otherwise there's just cursor, which really just boils down to "use at
least universal planes". And gamma tables (where we have a bit a mess
with the fbdev helper gamma hooks).
v2: Spelling fixes (Eric).
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
Documentation/DocBook/gpu.tmpl | 117 +----------------------------
include/drm/drm_crtc.h | 164 +++++++++++++++++++++++++++++++++++++----
2 files changed, 149 insertions(+), 132 deletions(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 02c7d44f517c..5312f5a05798 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1174,121 +1174,6 @@ int max_width, max_height;</synopsis>
pointer to CRTC functions.
</para>
</sect3>
- <sect3 id="drm-kms-crtcops">
- <title>CRTC Operations</title>
- <sect4>
- <title>Set Configuration</title>
- <synopsis>int (*set_config)(struct drm_mode_set *set);</synopsis>
- <para>
- Apply a new CRTC configuration to the device. The configuration
- specifies a CRTC, a frame buffer to scan out from, a (x,y) position in
- the frame buffer, a display mode and an array of connectors to drive
- with the CRTC if possible.
- </para>
- <para>
- If the frame buffer specified in the configuration is NULL, the driver
- must detach all encoders connected to the CRTC and all connectors
- attached to those encoders and disable them.
- </para>
- <para>
- This operation is called with the mode config lock held.
- </para>
- <note><para>
- Note that the drm core has no notion of restoring the mode setting
- state after resume, since all resume handling is in the full
- responsibility of the driver. The common mode setting helper library
- though provides a helper which can be used for this:
- <function>drm_helper_resume_force_mode</function>.
- </para></note>
- </sect4>
- <sect4>
- <title>Page Flipping</title>
- <synopsis>int (*page_flip)(struct drm_crtc *crtc, struct drm_framebuffer *fb,
- struct drm_pending_vblank_event *event);</synopsis>
- <para>
- Schedule a page flip to the given frame buffer for the CRTC. This
- operation is called with the mode config mutex held.
- </para>
- <para>
- Page flipping is a synchronization mechanism that replaces the frame
- buffer being scanned out by the CRTC with a new frame buffer during
- vertical blanking, avoiding tearing. When an application requests a page
- flip the DRM core verifies that the new frame buffer is large enough to
- be scanned out by the CRTC in the currently configured mode and then
- calls the CRTC <methodname>page_flip</methodname> operation with a
- pointer to the new frame buffer.
- </para>
- <para>
- The <methodname>page_flip</methodname> operation schedules a page flip.
- Once any pending rendering targeting the new frame buffer has
- completed, the CRTC will be reprogrammed to display that frame buffer
- after the next vertical refresh. The operation must return immediately
- without waiting for rendering or page flip to complete and must block
- any new rendering to the frame buffer until the page flip completes.
- </para>
- <para>
- If a page flip can be successfully scheduled the driver must set the
- <code>drm_crtc->fb</code> field to the new framebuffer pointed to
- by <code>fb</code>. This is important so that the reference counting
- on framebuffers stays balanced.
- </para>
- <para>
- If a page flip is already pending, the
- <methodname>page_flip</methodname> operation must return
- -<errorname>EBUSY</errorname>.
- </para>
- <para>
- To synchronize page flip to vertical blanking the driver will likely
- need to enable vertical blanking interrupts. It should call
- <function>drm_vblank_get</function> for that purpose, and call
- <function>drm_vblank_put</function> after the page flip completes.
- </para>
- <para>
- If the application has requested to be notified when page flip completes
- the <methodname>page_flip</methodname> operation will be called with a
- non-NULL <parameter>event</parameter> argument pointing to a
- <structname>drm_pending_vblank_event</structname> instance. Upon page
- flip completion the driver must call <methodname>drm_send_vblank_event</methodname>
- to fill in the event and send to wake up any waiting processes.
- This can be performed with
- <programlisting><![CDATA[
- spin_lock_irqsave(&dev->event_lock, flags);
- ...
- drm_send_vblank_event(dev, pipe, event);
- spin_unlock_irqrestore(&dev->event_lock, flags);
- ]]></programlisting>
- </para>
- <note><para>
- FIXME: Could drivers that don't need to wait for rendering to complete
- just add the event to <literal>dev->vblank_event_list</literal> and
- let the DRM core handle everything, as for "normal" vertical blanking
- events?
- </para></note>
- <para>
- While waiting for the page flip to complete, the
- <literal>event->base.link</literal> list head can be used freely by
- the driver to store the pending event in a driver-specific list.
- </para>
- <para>
- If the file handle is closed before the event is signaled, drivers must
- take care to destroy the event in their
- <methodname>preclose</methodname> operation (and, if needed, call
- <function>drm_vblank_put</function>).
- </para>
- </sect4>
- <sect4>
- <title>Miscellaneous</title>
- <itemizedlist>
- <listitem>
- <synopsis>void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
- uint32_t start, uint32_t size);</synopsis>
- <para>
- Apply a gamma table to the device. The operation is optional.
- </para>
- </listitem>
- </itemizedlist>
- </sect4>
- </sect3>
</sect2>
<sect2>
<title>Planes (struct <structname>drm_plane</structname>)</title>
@@ -1305,7 +1190,7 @@ int max_width, max_height;</synopsis>
<listitem>
DRM_PLANE_TYPE_PRIMARY represents a "main" plane for a CRTC. Primary
planes are the planes operated upon by CRTC modesetting and flipping
- operations described in <xref linkend="drm-kms-crtcops"/>.
+ operations described in the page_flip hook in <structname>drm_crtc_funcs</structname>.
</listitem>
<listitem>
DRM_PLANE_TYPE_CURSOR represents a "cursor" plane for a CRTC. Cursor
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index fbfe617bc492..72a7e096dd42 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -320,12 +320,6 @@ struct drm_crtc_state {
/**
* struct drm_crtc_funcs - control CRTCs for a given device
- * @cursor_set: setup the cursor
- * @cursor_set2: setup the cursor with hotspot, superseeds @cursor_set if set
- * @cursor_move: move the cursor
- * @gamma_set: specify color ramp for CRTC
- * @set_config: apply a new CRTC configuration
- * @page_flip: initiate a page flip
*
* The drm_crtc_funcs structure is the central CRTC management structure
* in the DRM. Each CRTC controls one or more connectors (note that the name
@@ -349,15 +343,86 @@ struct drm_crtc_funcs {
*/
void (*reset)(struct drm_crtc *crtc);
- /* cursor controls */
+ /**
+ * @cursor_set:
+ *
+ * Update the cursor image. The cursor position is relative to the CRTC
+ * and can be partially or fully outside of the visible area.
+ *
+ * Note that contrary to all other KMS function the legacy cursor entry
+ * points don't take a framebuffer object, but instead take directly a
+ * raw buffer object id from the driver's buffer manager (which is
+ * either GEM or TTM for current drivers).
+ *
+ * This entry point is deprecated, drivers should instead implement
+ * universal plane support and register a proper cursor plane using
+ * drm_crtc_init_with_planes().
+ *
+ * This callback is optional
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*cursor_set)(struct drm_crtc *crtc, struct drm_file *file_priv,
uint32_t handle, uint32_t width, uint32_t height);
+
+ /**
+ * @cursor_set2:
+ *
+ * Update the cursor image, including hotspot information. The hotspot
+ * must not affect the cursor position in CRTC coordinates, but is only
+ * meant as a hint for virtualized display hardware to coordinate the
+ * guests and hosts cursor position. The cursor hotspot is relative to
+ * the cursor image. Otherwise this works exactly like @cursor_set.
+ *
+ * This entry point is deprecated, drivers should instead implement
+ * universal plane support and register a proper cursor plane using
+ * drm_crtc_init_with_planes().
+ *
+ * This callback is optional
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*cursor_set2)(struct drm_crtc *crtc, struct drm_file *file_priv,
uint32_t handle, uint32_t width, uint32_t height,
int32_t hot_x, int32_t hot_y);
+
+ /**
+ * @cursor_move:
+ *
+ * Update the cursor position. The cursor does not need to be visible
+ * when this hook is called.
+ *
+ * This entry point is deprecated, drivers should instead implement
+ * universal plane support and register a proper cursor plane using
+ * drm_crtc_init_with_planes().
+ *
+ * This callback is optional
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*cursor_move)(struct drm_crtc *crtc, int x, int y);
- /* Set gamma on the CRTC */
+ /**
+ * @gamma_set:
+ *
+ * Set gamma on the CRTC.
+ *
+ * This callback is optional.
+ *
+ * NOTE:
+ *
+ * Drivers that support gamma tables and also fbdev emulation through
+ * the provided helper library need to take care to fill out the gamma
+ * hooks for both. Currently there's a bit an unfortunate duplication
+ * going on, which should eventually be unified to just one set of
+ * hooks.
+ */
void (*gamma_set)(struct drm_crtc *crtc, u16 *r, u16 *g, u16 *b,
uint32_t start, uint32_t size);
@@ -370,16 +435,83 @@ struct drm_crtc_funcs {
*/
void (*destroy)(struct drm_crtc *crtc);
+ /**
+ * @set_config:
+ *
+ * This is the main legacy entry point to change the modeset state on a
+ * CRTC. All the details of the desired configuration are passed in a
+ * struct &drm_mode_set - see there for details.
+ *
+ * Drivers implementing atomic modeset should use
+ * drm_atomic_helper_set_config() to implement this hook.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*set_config)(struct drm_mode_set *set);
- /*
- * Flip to the given framebuffer. This implements the page
- * flip ioctl described in drm_mode.h, specifically, the
- * implementation must return immediately and block all
- * rendering to the current fb until the flip has completed.
- * If userspace set the event flag in the ioctl, the event
- * argument will point to an event to send back when the flip
- * completes, otherwise it will be NULL.
+ /**
+ * @page_flip:
+ *
+ * Legacy entry point to schedule a flip to the given framebuffer.
+ *
+ * Page flipping is a synchronization mechanism that replaces the frame
+ * buffer being scanned out by the CRTC with a new frame buffer during
+ * vertical blanking, avoiding tearing (except when requested otherwise
+ * through the DRM_MODE_PAGE_FLIP_ASYN flag). When an application
+ * requests a page flip the DRM core verifies that the new frame buffer is large
+ * enough to be scanned out by the CRTC in the currently configured mode
+ * and then calls the CRTC page_flip operation with a pointer to the new
+ * frame buffer.
+ *
+ * The driver must wait for any pending rendering to the new framebuffer
+ * to complete before executing the flip. It should also wait for any
+ * pending rendering from other drivers if the underlying buffer is a
+ * shared dma-buf.
+ *
+ * An application can request to be notified when the page flip has
+ * completed. The drm core will supply a struct &drm_event in the event
+ * parameter in this case. This can be handled by the
+ * drm_crtc_send_vblank_event() function, which the driver should call on
+ * the provided event upon completion of the flip. Note that if
+ * the driver supports vblank signalling and timestamping the vblank
+ * counters and timestamps must agree with the ones returned from page
+ * flip events. With the current vblank helper infrastructure this can
+ * be achieved by holding a vblank reference while the page flip is
+ * pending, acquired through drm_crtc_vblank_get() and released with
+ * drm_crtc_vblank_put(). Drivers are free to implement their own vblank
+ * counter and timestamp tracking though, e.g. if they have accurate
+ * timestamp registers in hardware.
+ *
+ * FIXME:
+ *
+ * Up to that point drivers need to manage events themselves and can use
+ * even->base.list freely for that. Specifically they need to ensure
+ * that they don't send out page flip (or vblank) events for which the
+ * corresponding drm file has been closed already. The drm core
+ * unfortunately does not (yet) take care of that. Therefore drivers
+ * currently must clean up and release pending events in their
+ * ->preclose driver function.
+ *
+ * This callback is optional.
+ *
+ * NOTE:
+ *
+ * Very early versions of the KMS ABI mandated that the driver must
+ * block (but not reject) any rendering to the old framebuffer until the
+ * flip operation has completed and the old framebuffer is not longer
+ * visible. This requirement has been lifted, and userspace is instead
+ * expected to request delivery of a event and wait with recycling old
+ * buffers until such has been received.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure. Note that if a
+ * page_flip operation is already pending the callback should return
+ * -EBUSY. Pageflips on a disabled CRTC (either by setting a NULL mode
+ * or just runtime disabled through DPMS respectively the new atomic
+ * "ACTIVE" state) should result in an -EINVAL error code.
*/
int (*page_flip)(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 19/28] drm: document drm_crtc_funcs
2015-12-04 8:46 ` [PATCH 19/28] drm: document drm_crtc_funcs Daniel Vetter
@ 2015-12-07 12:25 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 12:25 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 5199 bytes --]
On Fri, Dec 04, 2015 at 09:46:00AM +0100, Daniel Vetter wrote:
[...]
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index fbfe617bc492..72a7e096dd42 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -320,12 +320,6 @@ struct drm_crtc_state {
>
> /**
> * struct drm_crtc_funcs - control CRTCs for a given device
> - * @cursor_set: setup the cursor
> - * @cursor_set2: setup the cursor with hotspot, superseeds @cursor_set if set
> - * @cursor_move: move the cursor
> - * @gamma_set: specify color ramp for CRTC
> - * @set_config: apply a new CRTC configuration
> - * @page_flip: initiate a page flip
> *
> * The drm_crtc_funcs structure is the central CRTC management structure
> * in the DRM. Each CRTC controls one or more connectors (note that the name
> @@ -349,15 +343,86 @@ struct drm_crtc_funcs {
> */
> void (*reset)(struct drm_crtc *crtc);
>
> - /* cursor controls */
> + /**
> + * @cursor_set:
> + *
> + * Update the cursor image. The cursor position is relative to the CRTC
> + * and can be partially or fully outside of the visible area.
> + *
> + * Note that contrary to all other KMS function the legacy cursor entry
"functions"
> + /**
> + * @cursor_move:
> + *
> + * Update the cursor position. The cursor does not need to be visible
> + * when this hook is called.
> + *
> + * This entry point is deprecated, drivers should instead implement
> + * universal plane support and register a proper cursor plane using
> + * drm_crtc_init_with_planes().
> + *
> + * This callback is optional
Nit: Append a full-stop here and in the above ->cursor_*() callback
descriptions.
> - /*
> - * Flip to the given framebuffer. This implements the page
> - * flip ioctl described in drm_mode.h, specifically, the
> - * implementation must return immediately and block all
> - * rendering to the current fb until the flip has completed.
> - * If userspace set the event flag in the ioctl, the event
> - * argument will point to an event to send back when the flip
> - * completes, otherwise it will be NULL.
> + /**
> + * @page_flip:
> + *
> + * Legacy entry point to schedule a flip to the given framebuffer.
> + *
> + * Page flipping is a synchronization mechanism that replaces the frame
> + * buffer being scanned out by the CRTC with a new frame buffer during
> + * vertical blanking, avoiding tearing (except when requested otherwise
> + * through the DRM_MODE_PAGE_FLIP_ASYN flag). When an application
"DRM_MODE_PAGE_FLIP_ASYNC"
> + * requests a page flip the DRM core verifies that the new frame buffer is large
This line looks odd because it is wider than all the others.
> + * enough to be scanned out by the CRTC in the currently configured mode
> + * and then calls the CRTC page_flip operation with a pointer to the new
"->page_flip()"?
> + * frame buffer.
> + *
> + * The driver must wait for any pending rendering to the new framebuffer
> + * to complete before executing the flip. It should also wait for any
> + * pending rendering from other drivers if the underlying buffer is a
> + * shared dma-buf.
> + *
> + * An application can request to be notified when the page flip has
> + * completed. The drm core will supply a struct &drm_event in the event
> + * parameter in this case. This can be handled by the
> + * drm_crtc_send_vblank_event() function, which the driver should call on
> + * the provided event upon completion of the flip. Note that if
> + * the driver supports vblank signalling and timestamping the vblank
> + * counters and timestamps must agree with the ones returned from page
> + * flip events. With the current vblank helper infrastructure this can
> + * be achieved by holding a vblank reference while the page flip is
> + * pending, acquired through drm_crtc_vblank_get() and released with
> + * drm_crtc_vblank_put(). Drivers are free to implement their own vblank
> + * counter and timestamp tracking though, e.g. if they have accurate
> + * timestamp registers in hardware.
> + *
> + * FIXME:
> + *
> + * Up to that point drivers need to manage events themselves and can use
> + * even->base.list freely for that. Specifically they need to ensure
> + * that they don't send out page flip (or vblank) events for which the
> + * corresponding drm file has been closed already. The drm core
> + * unfortunately does not (yet) take care of that. Therefore drivers
> + * currently must clean up and release pending events in their
> + * ->preclose driver function.
> + *
> + * This callback is optional.
> + *
> + * NOTE:
> + *
> + * Very early versions of the KMS ABI mandated that the driver must
> + * block (but not reject) any rendering to the old framebuffer until the
> + * flip operation has completed and the old framebuffer is not longer
"no longer"
> + * visible. This requirement has been lifted, and userspace is instead
> + * expected to request delivery of a event and wait with recycling old
"an event"
Otherwise:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 20/28] drm: Add kerneldoc for drm_framebuffer_funcs
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (18 preceding siblings ...)
2015-12-04 8:46 ` [PATCH 19/28] drm: document drm_crtc_funcs Daniel Vetter
@ 2015-12-04 8:46 ` Daniel Vetter
2015-12-07 12:37 ` Thierry Reding
2015-12-04 8:46 ` [PATCH 21/28] drm: Kerneldoc for drm_mode_config_funcs Daniel Vetter
` (7 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:46 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development
While typing these I noticed that ->dirty is a bit a can of worms
and even supports blt/fill semantics ... shocked me a bit.
Oh well it's defined in a way that nothing bad (just a bit of inefficiency)
will happen for drivers which supports this. So I didn't bother copying
the detailed spec into the new kerneldoc.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
include/drm/drm_crtc.h | 50 +++++++++++++++++++++++++++++++++++++++++---------
1 file changed, 41 insertions(+), 9 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 72a7e096dd42..551484fb55e5 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -162,23 +162,55 @@ struct drm_tile_group {
u8 group_data[8];
};
+/**
+ * struct drm_framebuffer_funcs - framebuffer hooks
+ */
struct drm_framebuffer_funcs {
- /* note: use drm_framebuffer_remove() */
+ /**
+ * @destroy:
+ *
+ * Clean up framebuffer resources, specifically also unreference the
+ * backing storage. The core guarantees to call this function for every
+ * framebuffer succesfully created by fb_create in
+ * &drm_mode_config_funcs.
+ */
void (*destroy)(struct drm_framebuffer *framebuffer);
+
+ /**
+ * @create_handle:
+ *
+ * Create a buffer handle in the driver-specific buffer manager (either
+ * GEM or TTM) valid for the passed-in struct &drm_file. This is used by
+ * the core to implement the GETFB ioctl, which returns (for
+ * sufficiently priviledged user) also a native buffer handle. This can
+ * be used for seamless transitions between modesetting clients by
+ * copying the current screen contents to a private buffer and blending
+ * between that and the new contents.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*create_handle)(struct drm_framebuffer *fb,
struct drm_file *file_priv,
unsigned int *handle);
- /*
+ /**
+ * @dirty:
+ *
* Optional callback for the dirty fb ioctl.
*
- * Userspace can notify the driver via this callback
- * that a area of the framebuffer has changed and should
- * be flushed to the display hardware.
+ * Userspace can notify the driver via this callback that a area of the
+ * framebuffer has changed and should be flushed to the display
+ * hardware. This can also be used internally, e.g. by the fbdev
+ * emulation, though that's not (yet) the case currently.
+ *
+ * See documentation in drm_mode.h for the struct drm_mode_fb_dirty_cmd
+ * for more information as all the semantics and arguments have a one to
+ * one mapping on this function.
*
- * See documentation in drm_mode.h for the struct
- * drm_mode_fb_dirty_cmd for more information as all
- * the semantics and arguments have a one to one mapping
- * on this function.
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
*/
int (*dirty)(struct drm_framebuffer *framebuffer,
struct drm_file *file_priv, unsigned flags,
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 20/28] drm: Add kerneldoc for drm_framebuffer_funcs
2015-12-04 8:46 ` [PATCH 20/28] drm: Add kerneldoc for drm_framebuffer_funcs Daniel Vetter
@ 2015-12-07 12:37 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 12:37 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 3215 bytes --]
On Fri, Dec 04, 2015 at 09:46:01AM +0100, Daniel Vetter wrote:
> While typing these I noticed that ->dirty is a bit a can of worms
> and even supports blt/fill semantics ... shocked me a bit.
>
> Oh well it's defined in a way that nothing bad (just a bit of inefficiency)
> will happen for drivers which supports this. So I didn't bother copying
> the detailed spec into the new kerneldoc.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> include/drm/drm_crtc.h | 50 +++++++++++++++++++++++++++++++++++++++++---------
> 1 file changed, 41 insertions(+), 9 deletions(-)
>
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 72a7e096dd42..551484fb55e5 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -162,23 +162,55 @@ struct drm_tile_group {
> u8 group_data[8];
> };
>
> +/**
> + * struct drm_framebuffer_funcs - framebuffer hooks
> + */
> struct drm_framebuffer_funcs {
> - /* note: use drm_framebuffer_remove() */
> + /**
> + * @destroy:
> + *
> + * Clean up framebuffer resources, specifically also unreference the
> + * backing storage. The core guarantees to call this function for every
> + * framebuffer succesfully created by fb_create in
"successfully" and "->fb_create()"?
> + /**
> + * @create_handle:
> + *
> + * Create a buffer handle in the driver-specific buffer manager (either
> + * GEM or TTM) valid for the passed-in struct &drm_file. This is used by
> + * the core to implement the GETFB ioctl, which returns (for
s/ioctl/IOCTL/?
> + * sufficiently priviledged user) also a native buffer handle. This can
"users"
> + * be used for seamless transitions between modesetting clients by
> + * copying the current screen contents to a private buffer and blending
> + * between that and the new contents.
> + *
> + * RETURNS:
> + *
> + * 0 on success or a negative error code on failure.
> + */
> int (*create_handle)(struct drm_framebuffer *fb,
> struct drm_file *file_priv,
> unsigned int *handle);
> - /*
> + /**
> + * @dirty:
> + *
> * Optional callback for the dirty fb ioctl.
> *
> - * Userspace can notify the driver via this callback
> - * that a area of the framebuffer has changed and should
> - * be flushed to the display hardware.
> + * Userspace can notify the driver via this callback that a area of the
"an area"
> + * framebuffer has changed and should be flushed to the display
> + * hardware. This can also be used internally, e.g. by the fbdev
> + * emulation, though that's not (yet) the case currently.
Nit: I'd drop "(yet) " because of "currently".
> + *
> + * See documentation in drm_mode.h for the struct drm_mode_fb_dirty_cmd
> + * for more information as all the semantics and arguments have a one to
> + * one mapping on this function.
Perhaps "for more information on struct drm_mode_fb_dirty_cmd as all the
...". Oh and I guess also &drm_mode_fb_dirty_cmd for the cross-reference?
Again, fine if this is all fixed-up in a follow-up patch, since this is
all from moving the documentation:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 21/28] drm: Kerneldoc for drm_mode_config_funcs
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (19 preceding siblings ...)
2015-12-04 8:46 ` [PATCH 20/28] drm: Add kerneldoc for drm_framebuffer_funcs Daniel Vetter
@ 2015-12-04 8:46 ` Daniel Vetter
2015-12-07 13:14 ` Thierry Reding
2015-12-04 8:46 ` [PATCH 22/28] drm/atomic-helper: Reject attempts at re-stealing encoders Daniel Vetter
` (6 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:46 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Eric Anholt
The meat here is definitely the detailed specs for what atomic_check
and atomic_commit are supposed to do.
And another candidate for a core vfunc that should be in a helper really
(output_poll_changed this time around).
v2: Feedback from Eric on irc:
- spelling fixes.
- spec what async should do
- copy the event related paragraphs from page_flip and adjust
- make it clear that a successful async commit is not allowed to leave
the pipe dead or disabled.
v3: Use FIXME comments to annotate functions that we should move to
some helpers.
Cc: Eric Anholt <eric@anholt.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
include/drm/drm_crtc.h | 241 +++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 233 insertions(+), 8 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 551484fb55e5..37cff64a26ef 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1715,31 +1715,256 @@ struct drm_mode_set {
/**
* struct drm_mode_config_funcs - basic driver provided mode setting functions
- * @fb_create: create a new framebuffer object
- * @output_poll_changed: function to handle output configuration changes
- * @atomic_check: check whether a given atomic state update is possible
- * @atomic_commit: commit an atomic state update previously verified with
- * atomic_check()
- * @atomic_state_alloc: allocate a new atomic state
- * @atomic_state_clear: clear the atomic state
- * @atomic_state_free: free the atomic state
*
* Some global (i.e. not per-CRTC, connector, etc) mode setting functions that
* involve drivers.
*/
struct drm_mode_config_funcs {
+ /**
+ * @fb_create:
+ *
+ * Create a new framebuffer object. The core does basic checks on the
+ * requested metadata, but most of that is left to the driver. See
+ * struct &drm_mode_fb_cmd2 for details.
+ *
+ * RETURNS:
+ *
+ * A new framebuffer with an initial refernce count of 1 or a negative
+ * error code encoded with ERR_PTR().
+ */
struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
struct drm_file *file_priv,
const struct drm_mode_fb_cmd2 *mode_cmd);
+
+ /**
+ * @output_poll_changed:
+ *
+ * Callback used by helpers to inform the driver of output configuration
+ * changes.
+ *
+ * Drivers implementing fbdev emulation with the helpers can call
+ * drm_fb_helper_hotplug_changed from this hook to inform the fbdev
+ * helper of output changes.
+ *
+ * FIXME:
+ *
+ * Except that there's no vtable for device-level helper callbacks
+ * there's no reason this is a core function.
+ */
void (*output_poll_changed)(struct drm_device *dev);
+ /**
+ * @atomic_check:
+ *
+ * This is the only hook to validate an atomic modeset update. This
+ * function must reject any modeset and state changes which the hardware
+ * or driver doesn't support. This includes but is of course not limited
+ * to:
+ *
+ * - Checking that the modes, framebuffers, scaling and placement
+ * requirements and so on are within the limits of the hardware.
+ *
+ * - Checking that any hidden shared resources are not oversubscribed.
+ * This can be shared PLLs, shared lanes, overall memory bandwidth,
+ * display fifo space (where shared between planes or maybe even
+ * CRTCs).
+ *
+ * - Checking that virtualized resources exported to userspace are not
+ * oversubscribed. For various reasons it can make sense to expose
+ * more planes, crtcs or encoders than which are physically there. One
+ * example is dual-pipe operations (which generally should be hidden
+ * from userspace if when lockstepped in hardware, otherwise exposed),
+ * where a plane might need 1 hardware plane (if it's just on one
+ * pipe), 2 hardware planes (when it spans both pipes) or maybe even
+ * shared a hardware plane with a 2nd plane (if there's a compatible
+ * plane requested on the area handled by the other pipe).
+ *
+ * - Check that any transitional state is possible and that if
+ * requested, the update can indeed be done in the vblank period
+ * without temporarily disabling some functions.
+ *
+ * - Check any other constraints the driver or hardware might have.
+ *
+ * - This callback also needs to correctly fill out the &drm_crtc_state
+ * in this update to make sure that drm_atomic_crtc_needs_modeset()
+ * reflects the nature of the possible update and returns true if and
+ * only if the update cannot be applied without tearing within one
+ * vblank on that CRTC. The core uses that information to reject
+ * updates which require a full modeset (i.e. blanking the screen, or
+ * at least pausing updates for a substantial amount of time) if
+ * userspace has disallowed that in its request.
+ *
+ * - The driver also does not need to repeat basic input validation
+ * like done for the corresponding legacy entry points. The core does
+ * that before calling this hook.
+ *
+ * See the documentation of @atomic_commit for an exhaustive list of
+ * error conditions which are allowed to not be checked in this
+ * callback.
+ *
+ * See the documentation for struct &drm_atomic_state for how exactly
+ * an atomic modeset update is described.
+ *
+ * Drivers using the atomic helpers can implement this hook using
+ * drm_atomic_helper_check(), or one of the exported sub-functions of
+ * it.
+ *
+ * RETURNS:
+ *
+ * 0 on success or one of the below negative error codes:
+ *
+ * - -EINVAL, if any of the above constraints are violated.
+ *
+ * - -EDEADLK, when returned from an attempt to acquire an additional
+ * &drm_modeset_lock through drm_modeset_lock().
+ *
+ * - -ENOMEM, if allocating additional state sub-structures failed due
+ * to lack of memory.
+ *
+ * - -EINTR, -EAGAIN or -ERESTARTSYS, if the ioctl should be restarted.
+ * This can either be due to a pending signal, or because the driver
+ * needs to completely bail out to recover from an exceptional
+ * situation like a gpu hang. From a userspace point all errors are
+ * treated equally.
+ */
int (*atomic_check)(struct drm_device *dev,
struct drm_atomic_state *a);
+
+ /**
+ * @atomic_commit:
+ *
+ * This is the only hook to commit an atomic modeset update. The core
+ * guarantees that @atomic_check has been called successfully before
+ * calling this function, and that nothing has been changed in the
+ * interim.
+ *
+ * See the documentation for struct &drm_atomic_state for how exactly
+ * an atomic modeset update is described.
+ *
+ * Drivers using the atomic helpers can implement this hook using
+ * drm_atomic_helper_commit(), or one of the exported sub-functions of
+ * it.
+ *
+ * Asynchronous commits (as indicated with the async parameter) must
+ * do any preparatory work which might result in an unsuccessful commit
+ * in the context of this callback. The only exception is hardware
+ * errors resulting in -EIO. But even in that case the driver must
+ * ensure that the display pipe is at least running, to avoid
+ * compositors crashing when pageflips don't work. Anything else,
+ * specifically committing the update to the hardware, should be done
+ * without blocking the caller. For updates which do not require a
+ * modeset this must be guaranteed.
+ *
+ * The driver must wait for any pending rendering to the new
+ * framebuffers to complete before executing the flip. It should also
+ * wait for any pending rendering from other drivers if the underlying
+ * buffer is a shared dma-buf. Asynchronous commits must not wait for
+ * rendering in the context of this callback.
+ *
+ * An application can request to be notified when the atomic commit has
+ * completed. These events are per-CRTC and can be distinguished by the
+ * CRTC index supplied in &drm_event to userspace.
+ *
+ * The drm core will supply a struct &drm_event in the event
+ * member of each CRTC's &drm_crtc_state structure. This can be handled by the
+ * drm_crtc_send_vblank_event() function, which the driver should call on
+ * the provided event upon completion of the atomic commit. Note that if
+ * the driver supports vblank signalling and timestamping the vblank
+ * counters and timestamps must agree with the ones returned from page
+ * flip events. With the current vblank helper infrastructure this can
+ * be achieved by holding a vblank reference while the page flip is
+ * pending, acquired through drm_crtc_vblank_get() and released with
+ * drm_crtc_vblank_put(). Drivers are free to implement their own vblank
+ * counter and timestamp tracking though, e.g. if they have accurate
+ * timestamp registers in hardware.
+ *
+ * NOTE:
+ *
+ * Drivers are not allowed to shut down any display pipe successfully
+ * enabled through an atomic commit on their own. Doing so can result in
+ * compositors crashing if a page flip is suddenly reject because the
+ * pipe is off.
+ *
+ * RETURNS:
+ *
+ * 0 on success or one of the below negative error codes:
+ *
+ * - -EBUSY, if an asynchronous updated is requested and there is
+ * currently an earlier updated still pending. Drivers are allowed to
+ * support a queue of outstanding updates, but currently no driver
+ * supports that. Note that drivers must wait for preceding updates
+ * to complete if a synchronous update is requested, they are not
+ * allowed to fail the commit in that case.
+ *
+ * - -ENOMEM, if the driver failed to allocate memory. Specifically
+ * this can happen when trying to pin framebuffers, which must only
+ * be done when committing the state.
+ *
+ * - -ENOSPC, as a refinement of the more generic -ENOMEM to indicate
+ * that the driver has run out of vram, iommu space or similar gpu
+ * address space needed for framebuffer.
+ *
+ * - -EIO, if the hardware completely died.
+ *
+ * - -EINTR, -EAGAIN or -ERESTARTSYS, if the ioctl should be restarted.
+ * This can either be due to a pending signal, or because the driver
+ * needs to completely bail out to recover from an exceptional
+ * situation like a gpu hang. From a userspace point of view all errors are
+ * treated equally.
+ *
+ * This list is exhaustive. Specifically this hook is not allowed to
+ * return -EINVAL (any invalid requests should be caught in
+ * @atomic_check) or -EDEADLK (this function must not acquire
+ * additional modeset locks). The core will also reject any async
+ * atomic flips with -EINVAL already (for matching semantics in this
+ * case with legacy page flips).
+ */
int (*atomic_commit)(struct drm_device *dev,
struct drm_atomic_state *a,
bool async);
+
+ /**
+ * @atomic_state_alloc:
+ *
+ * This optional hook can be used by drivers who want to subclass struct
+ * &drm_atomic_state to be able to track their own driver-private global
+ * state easily. If this hook is implemented, drivers must also
+ * implement @atomic_state_clear and @atomic_state_free.
+ *
+ * RETURNS:
+ *
+ * A new &drm_atomic_state on success or NULL on failure.
+ */
struct drm_atomic_state *(*atomic_state_alloc)(struct drm_device *dev);
+
+ /**
+ * @atomic_state_clear:
+ *
+ * This hook must clear any driver private state duplicated into the
+ * passed-in &drm_atomic_state. This hook is called when the caller
+ * encountered a &drm_modeset_lock deadlock and needs to drop all
+ * already acquired locks as part of the deadlock avoidance dance
+ * implemented in drm_modeset_lock_backoff().
+ *
+ * Any duplicated state must be invalidated since a concurrent atomic
+ * update might change it, and the drm atomic interfaces always apply
+ * updates as relative changes to the current state.
+ *
+ * Drivers who implement this must call drm_atomic_state_default_clear()
+ * to clear common state.
+ */
void (*atomic_state_clear)(struct drm_atomic_state *state);
+
+ /**
+ * @atomic_state_free:
+ *
+ * This hook needs driver private resources and the &drm_atomic_state
+ * itself. Note that the core first calls drm_atomic_state_clear to
+ * avoid code duplicate between the clear and free hooks.
+ *
+ * Drivers who implement this must call drm_atomic_state_default_free()
+ * to release common resources.
+ */
void (*atomic_state_free)(struct drm_atomic_state *state);
};
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 21/28] drm: Kerneldoc for drm_mode_config_funcs
2015-12-04 8:46 ` [PATCH 21/28] drm: Kerneldoc for drm_mode_config_funcs Daniel Vetter
@ 2015-12-07 13:14 ` Thierry Reding
2015-12-07 13:34 ` Daniel Vetter
0 siblings, 1 reply; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 13:14 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 12236 bytes --]
On Fri, Dec 04, 2015 at 09:46:02AM +0100, Daniel Vetter wrote:
[...]
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
[...]
> struct drm_mode_config_funcs {
> + /**
> + * @fb_create:
> + *
> + * Create a new framebuffer object. The core does basic checks on the
> + * requested metadata, but most of that is left to the driver. See
> + * struct &drm_mode_fb_cmd2 for details.
> + *
> + * RETURNS:
> + *
> + * A new framebuffer with an initial refernce count of 1 or a negative
"reference"
> + * error code encoded with ERR_PTR().
> + */
> struct drm_framebuffer *(*fb_create)(struct drm_device *dev,
> struct drm_file *file_priv,
> const struct drm_mode_fb_cmd2 *mode_cmd);
> +
> + /**
> + * @output_poll_changed:
> + *
> + * Callback used by helpers to inform the driver of output configuration
> + * changes.
> + *
> + * Drivers implementing fbdev emulation with the helpers can call
> + * drm_fb_helper_hotplug_changed from this hook to inform the fbdev
> + * helper of output changes.
> + *
> + * FIXME:
> + *
> + * Except that there's no vtable for device-level helper callbacks
> + * there's no reason this is a core function.
> + */
> void (*output_poll_changed)(struct drm_device *dev);
>
> + /**
> + * @atomic_check:
> + *
> + * This is the only hook to validate an atomic modeset update. This
> + * function must reject any modeset and state changes which the hardware
> + * or driver doesn't support. This includes but is of course not limited
> + * to:
> + *
> + * - Checking that the modes, framebuffers, scaling and placement
> + * requirements and so on are within the limits of the hardware.
> + *
> + * - Checking that any hidden shared resources are not oversubscribed.
> + * This can be shared PLLs, shared lanes, overall memory bandwidth,
> + * display fifo space (where shared between planes or maybe even
> + * CRTCs).
> + *
> + * - Checking that virtualized resources exported to userspace are not
> + * oversubscribed. For various reasons it can make sense to expose
> + * more planes, crtcs or encoders than which are physically there. One
> + * example is dual-pipe operations (which generally should be hidden
> + * from userspace if when lockstepped in hardware, otherwise exposed),
"hidden from userspace when lockstepped in hardware, exposed otherwise"?
> + * where a plane might need 1 hardware plane (if it's just on one
> + * pipe), 2 hardware planes (when it spans both pipes) or maybe even
> + * shared a hardware plane with a 2nd plane (if there's a compatible
> + * plane requested on the area handled by the other pipe).
> + *
> + * - Check that any transitional state is possible and that if
> + * requested, the update can indeed be done in the vblank period
> + * without temporarily disabling some functions.
> + *
> + * - Check any other constraints the driver or hardware might have.
> + *
> + * - This callback also needs to correctly fill out the &drm_crtc_state
> + * in this update to make sure that drm_atomic_crtc_needs_modeset()
> + * reflects the nature of the possible update and returns true if and
> + * only if the update cannot be applied without tearing within one
> + * vblank on that CRTC. The core uses that information to reject
> + * updates which require a full modeset (i.e. blanking the screen, or
> + * at least pausing updates for a substantial amount of time) if
> + * userspace has disallowed that in its request.
> + *
> + * - The driver also does not need to repeat basic input validation
> + * like done for the corresponding legacy entry points. The core does
> + * that before calling this hook.
> + *
> + * See the documentation of @atomic_commit for an exhaustive list of
> + * error conditions which are allowed to not be checked in this
> + * callback.
I think this is confusing. Perhaps "list of error conditions which don't
have to be checked at the ->atomic_check() stage."?
> + *
> + * See the documentation for struct &drm_atomic_state for how exactly
> + * an atomic modeset update is described.
> + *
> + * Drivers using the atomic helpers can implement this hook using
> + * drm_atomic_helper_check(), or one of the exported sub-functions of
> + * it.
> + *
> + * RETURNS:
> + *
> + * 0 on success or one of the below negative error codes:
> + *
> + * - -EINVAL, if any of the above constraints are violated.
> + *
> + * - -EDEADLK, when returned from an attempt to acquire an additional
> + * &drm_modeset_lock through drm_modeset_lock().
> + *
> + * - -ENOMEM, if allocating additional state sub-structures failed due
> + * to lack of memory.
> + *
> + * - -EINTR, -EAGAIN or -ERESTARTSYS, if the ioctl should be restarted.
> + * This can either be due to a pending signal, or because the driver
> + * needs to completely bail out to recover from an exceptional
> + * situation like a gpu hang. From a userspace point all errors are
> + * treated equally.
> + */
> int (*atomic_check)(struct drm_device *dev,
> struct drm_atomic_state *a);
> +
> + /**
> + * @atomic_commit:
> + *
> + * This is the only hook to commit an atomic modeset update. The core
> + * guarantees that @atomic_check has been called successfully before
> + * calling this function, and that nothing has been changed in the
> + * interim.
> + *
> + * See the documentation for struct &drm_atomic_state for how exactly
> + * an atomic modeset update is described.
> + *
> + * Drivers using the atomic helpers can implement this hook using
> + * drm_atomic_helper_commit(), or one of the exported sub-functions of
> + * it.
> + *
> + * Asynchronous commits (as indicated with the async parameter) must
> + * do any preparatory work which might result in an unsuccessful commit
> + * in the context of this callback. The only exception is hardware
"The only exception are hardware errors"
> + * errors resulting in -EIO. But even in that case the driver must
> + * ensure that the display pipe is at least running, to avoid
> + * compositors crashing when pageflips don't work. Anything else,
> + * specifically committing the update to the hardware, should be done
> + * without blocking the caller. For updates which do not require a
> + * modeset this must be guaranteed.
> + *
> + * The driver must wait for any pending rendering to the new
> + * framebuffers to complete before executing the flip. It should also
> + * wait for any pending rendering from other drivers if the underlying
> + * buffer is a shared dma-buf. Asynchronous commits must not wait for
> + * rendering in the context of this callback.
> + *
> + * An application can request to be notified when the atomic commit has
> + * completed. These events are per-CRTC and can be distinguished by the
> + * CRTC index supplied in &drm_event to userspace.
> + *
> + * The drm core will supply a struct &drm_event in the event
> + * member of each CRTC's &drm_crtc_state structure. This can be handled by the
> + * drm_crtc_send_vblank_event() function, which the driver should call on
> + * the provided event upon completion of the atomic commit. Note that if
> + * the driver supports vblank signalling and timestamping the vblank
> + * counters and timestamps must agree with the ones returned from page
> + * flip events. With the current vblank helper infrastructure this can
> + * be achieved by holding a vblank reference while the page flip is
> + * pending, acquired through drm_crtc_vblank_get() and released with
> + * drm_crtc_vblank_put(). Drivers are free to implement their own vblank
> + * counter and timestamp tracking though, e.g. if they have accurate
> + * timestamp registers in hardware.
> + *
> + * NOTE:
> + *
> + * Drivers are not allowed to shut down any display pipe successfully
> + * enabled through an atomic commit on their own. Doing so can result in
> + * compositors crashing if a page flip is suddenly reject because the
"rejected"
> + * pipe is off.
> + *
> + * RETURNS:
> + *
> + * 0 on success or one of the below negative error codes:
> + *
> + * - -EBUSY, if an asynchronous updated is requested and there is
"update"
> + * currently an earlier updated still pending. Drivers are allowed to
"update", also I'd drop the "currently" and "still" because they are
somewhat redundant: "... and an earlier update is pending."
> + * support a queue of outstanding updates, but currently no driver
> + * supports that. Note that drivers must wait for preceding updates
> + * to complete if a synchronous update is requested, they are not
> + * allowed to fail the commit in that case.
> + *
> + * - -ENOMEM, if the driver failed to allocate memory. Specifically
> + * this can happen when trying to pin framebuffers, which must only
> + * be done when committing the state.
> + *
> + * - -ENOSPC, as a refinement of the more generic -ENOMEM to indicate
> + * that the driver has run out of vram, iommu space or similar gpu
> + * address space needed for framebuffer.
> + *
> + * - -EIO, if the hardware completely died.
> + *
> + * - -EINTR, -EAGAIN or -ERESTARTSYS, if the ioctl should be restarted.
s/ioctl/IOCTL/
> + * This can either be due to a pending signal, or because the driver
> + * needs to completely bail out to recover from an exceptional
> + * situation like a gpu hang. From a userspace point of view all errors are
s/gpu/GPU/
> + * treated equally.
> + *
> + * This list is exhaustive. Specifically this hook is not allowed to
> + * return -EINVAL (any invalid requests should be caught in
> + * @atomic_check) or -EDEADLK (this function must not acquire
> + * additional modeset locks). The core will also reject any async
> + * atomic flips with -EINVAL already (for matching semantics in this
> + * case with legacy page flips).
Can you elaborate on this last assertion? Why does the core reject async
atomic flips? I don't see where it does that.
> + */
> int (*atomic_commit)(struct drm_device *dev,
> struct drm_atomic_state *a,
Why is the state variable called "a" here? Why not "state"? Same for
->atomic_check() above.
> + /**
> + * @atomic_state_alloc:
> + *
> + * This optional hook can be used by drivers who want to subclass struct
"... drivers that want ..."
> + * &drm_atomic_state to be able to track their own driver-private global
> + * state easily. If this hook is implemented, drivers must also
> + * implement @atomic_state_clear and @atomic_state_free.
> + *
> + * RETURNS:
> + *
> + * A new &drm_atomic_state on success or NULL on failure.
> + */
> struct drm_atomic_state *(*atomic_state_alloc)(struct drm_device *dev);
> +
> + /**
> + * @atomic_state_clear:
> + *
> + * This hook must clear any driver private state duplicated into the
> + * passed-in &drm_atomic_state. This hook is called when the caller
> + * encountered a &drm_modeset_lock deadlock and needs to drop all
> + * already acquired locks as part of the deadlock avoidance dance
> + * implemented in drm_modeset_lock_backoff().
> + *
> + * Any duplicated state must be invalidated since a concurrent atomic
> + * update might change it, and the drm atomic interfaces always apply
> + * updates as relative changes to the current state.
> + *
> + * Drivers who implement this must call drm_atomic_state_default_clear()
"Drivers that implement ..."
> + * to clear common state.
> + */
> void (*atomic_state_clear)(struct drm_atomic_state *state);
> +
> + /**
> + * @atomic_state_free:
> + *
> + * This hook needs driver private resources and the &drm_atomic_state
Did you mean "This hook frees ..."?
> + * itself. Note that the core first calls drm_atomic_state_clear to
Parentheses after drm_atomic_state_clear?
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 21/28] drm: Kerneldoc for drm_mode_config_funcs
2015-12-07 13:14 ` Thierry Reding
@ 2015-12-07 13:34 ` Daniel Vetter
0 siblings, 0 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-07 13:34 UTC (permalink / raw)
To: Thierry Reding; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
On Mon, Dec 07, 2015 at 02:14:48PM +0100, Thierry Reding wrote:
> On Fri, Dec 04, 2015 at 09:46:02AM +0100, Daniel Vetter wrote:
> > + * This list is exhaustive. Specifically this hook is not allowed to
> > + * return -EINVAL (any invalid requests should be caught in
> > + * @atomic_check) or -EDEADLK (this function must not acquire
> > + * additional modeset locks). The core will also reject any async
> > + * atomic flips with -EINVAL already (for matching semantics in this
> > + * case with legacy page flips).
>
> Can you elaborate on this last assertion? Why does the core reject async
> atomic flips? I don't see where it does that.
Was an ongoing discussion with Daniels Stone about what exactly we should
do here. Separate patch, not yet resolved so I dropped that sentence for
now - currently core code does indeed not do that.
All other suggestions applied, thanks.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 22/28] drm/atomic-helper: Reject attempts at re-stealing encoders
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (20 preceding siblings ...)
2015-12-04 8:46 ` [PATCH 21/28] drm: Kerneldoc for drm_mode_config_funcs Daniel Vetter
@ 2015-12-04 8:46 ` Daniel Vetter
2015-12-07 13:26 ` Thierry Reding
2015-12-04 8:46 ` [PATCH 23/28] drm: Document drm_plane_helper_funcs Daniel Vetter
` (5 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:46 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter
This can happen when we run out of encoders for a multi-crtc modeset,
or also when userspace is silly and tries to clone multiple connectors
that need the same encoder on the same crtc.
Reported-and-Tested-and-Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
drivers/gpu/drm/drm_atomic_helper.c | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 2cf8ab7dbc8c..ab275499d2a3 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -86,6 +86,27 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state *state,
}
}
+static bool
+check_pending_encoder_assignment(struct drm_atomic_state *state,
+ struct drm_encoder *new_encoder,
+ struct drm_connector *new_connector)
+{
+ struct drm_connector *connector;
+ struct drm_connector_state *conn_state;
+ int i;
+
+ for_each_connector_in_state(state, connector, conn_state, i) {
+ if (conn_state->best_encoder != new_encoder)
+ continue;
+
+ /* encoder already assigned and we're trying to re-steal it! */
+ if (connector->state->best_encoder != conn_state->best_encoder)
+ return false;
+ }
+
+ return true;
+}
+
static struct drm_crtc *
get_current_crtc_for_encoder(struct drm_device *dev,
struct drm_encoder *encoder)
@@ -235,6 +256,13 @@ update_connector_routing(struct drm_atomic_state *state, int conn_idx)
return 0;
}
+ if (!check_pending_encoder_assignment(state, new_encoder, connector)) {
+ DRM_DEBUG_ATOMIC("Encoder for [CONNECTOR:%d:%s] already assigned\n",
+ connector->base.id,
+ connector->name);
+ return -EINVAL;
+ }
+
encoder_crtc = get_current_crtc_for_encoder(state->dev,
new_encoder);
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 22/28] drm/atomic-helper: Reject attempts at re-stealing encoders
2015-12-04 8:46 ` [PATCH 22/28] drm/atomic-helper: Reject attempts at re-stealing encoders Daniel Vetter
@ 2015-12-07 13:26 ` Thierry Reding
2015-12-07 13:40 ` Daniel Vetter
0 siblings, 1 reply; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 13:26 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 1598 bytes --]
On Fri, Dec 04, 2015 at 09:46:03AM +0100, Daniel Vetter wrote:
> This can happen when we run out of encoders for a multi-crtc modeset,
> or also when userspace is silly and tries to clone multiple connectors
> that need the same encoder on the same crtc.
>
> Reported-and-Tested-and-Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 28 ++++++++++++++++++++++++++++
> 1 file changed, 28 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 2cf8ab7dbc8c..ab275499d2a3 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -86,6 +86,27 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state *state,
> }
> }
>
> +static bool
> +check_pending_encoder_assignment(struct drm_atomic_state *state,
> + struct drm_encoder *new_encoder,
> + struct drm_connector *new_connector)
new_connector seems to be unused.
> +{
> + struct drm_connector *connector;
> + struct drm_connector_state *conn_state;
> + int i;
> +
> + for_each_connector_in_state(state, connector, conn_state, i) {
> + if (conn_state->best_encoder != new_encoder)
> + continue;
> +
> + /* encoder already assigned and we're trying to re-steal it! */
> + if (connector->state->best_encoder != conn_state->best_encoder)
Was this supposed to be new_connector->state->best_encoder?
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 22/28] drm/atomic-helper: Reject attempts at re-stealing encoders
2015-12-07 13:26 ` Thierry Reding
@ 2015-12-07 13:40 ` Daniel Vetter
0 siblings, 0 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-07 13:40 UTC (permalink / raw)
To: Thierry Reding
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
On Mon, Dec 07, 2015 at 02:26:04PM +0100, Thierry Reding wrote:
> On Fri, Dec 04, 2015 at 09:46:03AM +0100, Daniel Vetter wrote:
> > This can happen when we run out of encoders for a multi-crtc modeset,
> > or also when userspace is silly and tries to clone multiple connectors
> > that need the same encoder on the same crtc.
> >
> > Reported-and-Tested-and-Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
> > Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Oops that patch shouldn't have been in here. And it's already merged -
somehow I botched the rebase before sending out this series and it didn't
drop out. I'll address your feedback with a follow-up patch.
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 28 ++++++++++++++++++++++++++++
> > 1 file changed, 28 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> > index 2cf8ab7dbc8c..ab275499d2a3 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -86,6 +86,27 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state *state,
> > }
> > }
> >
> > +static bool
> > +check_pending_encoder_assignment(struct drm_atomic_state *state,
> > + struct drm_encoder *new_encoder,
> > + struct drm_connector *new_connector)
>
> new_connector seems to be unused.
>
> > +{
> > + struct drm_connector *connector;
> > + struct drm_connector_state *conn_state;
> > + int i;
> > +
> > + for_each_connector_in_state(state, connector, conn_state, i) {
> > + if (conn_state->best_encoder != new_encoder)
> > + continue;
> > +
> > + /* encoder already assigned and we're trying to re-steal it! */
> > + if (connector->state->best_encoder != conn_state->best_encoder)
>
> Was this supposed to be new_connector->state->best_encoder?
Nah, new_connector was just leftovers from an earlier, broken version of
this. The function really only checks whether the given encoder has
alreaddy been reassigned in this update. That's enough to decide that
there's a conflict and reject the modeset. I'll do a patch to drop the
superflous argument.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 23/28] drm: Document drm_plane_helper_funcs
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (21 preceding siblings ...)
2015-12-04 8:46 ` [PATCH 22/28] drm/atomic-helper: Reject attempts at re-stealing encoders Daniel Vetter
@ 2015-12-04 8:46 ` Daniel Vetter
2015-12-07 14:27 ` Thierry Reding
2015-12-04 8:46 ` [PATCH 24/28] drm: Document drm_connector_helper_funcs Daniel Vetter
` (4 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:46 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter
Plus related hooks used to do atomic plane updates since they only
really make sense as a package.
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
include/drm/drm_modeset_helper_vtables.h | 209 +++++++++++++++++++++++++++++--
1 file changed, 198 insertions(+), 11 deletions(-)
diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
index bc731754fc70..66b78c14154e 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -57,9 +57,6 @@ enum mode_set_atomic;
* @load_lut: load color palette
* @disable: disable CRTC when no longer in use
* @enable: enable CRTC
- * @atomic_check: check for validity of an atomic state
- * @atomic_begin: begin atomic update
- * @atomic_flush: flush atomic update
*
* The helper operations are called by the mid-layer CRTC helper.
*
@@ -103,11 +100,95 @@ struct drm_crtc_helper_funcs {
void (*disable)(struct drm_crtc *crtc);
void (*enable)(struct drm_crtc *crtc);
- /* atomic helpers */
+ /**
+ * @atomic_check:
+ *
+ * Drivers should check plane-update related CRTC constraints in this
+ * hook. They can also check mode related limitations but need to be
+ * aware of the calling order, since this hook is used by
+ * drm_atomic_helper_check_planes() whereas the prepartions needed to
+ * check output routing and the display mode is done in
+ * drm_atomic_helper_check_modeset(). Therefore drivers who want to
+ * check output routing and display mode contstraints in this callback
+ * mus ensure that drm_atomic_helper_check_modeset() has been called
+ * beforehand.
+ *
+ * When using drm_atomic_helper_check_planes CRTC's ->atomic_check()
+ * hooks are called after the ones for palnes, which allows drivers to
+ * assign shared resources requested by planes in the CRTC callback
+ * here. For more complicated depencies the driver can call the provided
+ * check helpers multiple times until the computed state has a final
+ * configuration and everything has been checked.
+ *
+ * This function is also allowed to inspect any other object's state and
+ * can add more state objects to the atomic commit if needed. Care must
+ * be taken though to ensure that state check&compute functions for
+ * these added states are all called, and derived state in other objects
+ * all updated. Again the recommendation is to just call check helpers
+ * until a maximal configuration is reached.
+ *
+ * This callback is used by the atomic modeset helpers and by the
+ * transitional plane helpers, but it is optional.
+ *
+ * NOTE:
+ *
+ * This function is called in the check phase of an atomic update. The
+ * driver is not allowed to change anything outside of the free-standing
+ * state objects passed-in or assembled in the overall &drm_atomic_state
+ * update tracking structure.
+ *
+ * RETURNS:
+ *
+ * 0 on success, -EINVAL if the state or the transition can't be
+ * support, -ENOMEM on memory allocation failure and -EDEADLK if an
+ * attempt to obtain another state object ran into a &drm_modeset_lock
+ * deadlock.
+ */
int (*atomic_check)(struct drm_crtc *crtc,
struct drm_crtc_state *state);
+
+ /**
+ * @atomic_begin:
+ *
+ * Drivers should prepare for an atomic update of multiple planes on
+ * a CRTC in this hook. Depending upon hardware this might be vblank
+ * evasion, blocking updates by setting bits or doing prepatory work for
+ * e.g. manual update display.
+ *
+ * This hook is called before any plane commit functions are called.
+ *
+ * Note that the power state of the display pipe when this function is
+ * called depends upon the exact helpers and calling sequence the driver
+ * has picked. See drm_atomic_commit_planes for a discussion of the
+ * tradeoffs and variants of plane commit helpers.
+ *
+ * This callback is used by the atomic modeset helpers and by the
+ * transitional plane helpers, but it is optional.
+ */
void (*atomic_begin)(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state);
+ /**
+ * @atomic_flush:
+ *
+ * Drivers should prepare for an atomic update of multiple planes on
+ * a CRTC in this hook. Depending upon hardware this might include
+ * checking that vblank evasion was successful, unblocking updates by
+ * setting bits or setting the GO bit to flush out all updates.
+ *
+ * Simple hardware or hardware with special requirements can commit and
+ * flush out all updates for all planes from this hook and forgo all the
+ * other commit hooks for plane updates.
+ *
+ * This hook is called after any plane commit functions are called.
+ *
+ * Note that the power state of the display pipe when this function is
+ * called depends upon the exact helpers and calling sequence the driver
+ * has picked. See drm_atomic_commit_planes for a discussion of the
+ * tradeoffs and variants of plane commit helpers.
+ *
+ * This callback is used by the atomic modeset helpers and by the
+ * transitional plane helpers, but it is optional.
+ */
void (*atomic_flush)(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state);
};
@@ -211,25 +292,131 @@ static inline void drm_connector_helper_add(struct drm_connector *connector,
}
/**
- * struct drm_plane_helper_funcs - helper operations for CRTCs
- * @prepare_fb: prepare a framebuffer for use by the plane
- * @cleanup_fb: cleanup a framebuffer when it's no longer used by the plane
- * @atomic_check: check that a given atomic state is valid and can be applied
- * @atomic_update: apply an atomic state to the plane (mandatory)
- * @atomic_disable: disable the plane
+ * struct drm_plane_helper_funcs - helper operations for planes
*
- * The helper operations are called by the mid-layer CRTC helper.
+ * These functions are used by the atomic helpers and by the transitional plane
+ * helpers.
*/
struct drm_plane_helper_funcs {
+ /**
+ * @prepare_fb:
+ *
+ * This hook is to prepare a framebuffer for scanout by e.g. pinning
+ * it's backing storage or relocating it into a contiguous block of
+ * vram. Other possible preparatory work includes flushing caches.
+ *
+ * This function must not block for outstanding rendering, since it is
+ * called in the context of the atomic IOCTL even for async commits to
+ * be able to return any errors to userspace. Instead the recommended
+ * why is to fill out the fence member of the passed-in
+ * &drm_plane_state. If the driver doesn't support native fences then
+ * equivalent functionality should be implemented through private
+ * members in the plane structure.
+ *
+ * The helpers will call @cleanup_fb with matching arguments for every
+ * successful call to this hook.
+ *
+ * This callback is used by the atomic modeset helpers and by the
+ * transitional plane helpers, but it is optional.
+ *
+ * RETURNS:
+ *
+ * 0 on sucess or one of the following negative error codes allowed by
+ * the atomic_commit hook in &drm_mode_config_funcs. When using helpers
+ * this callback is the only one which can fail an atomic commit,
+ * everything else must complete successfully.
+ */
int (*prepare_fb)(struct drm_plane *plane,
const struct drm_plane_state *new_state);
+ /**
+ * @cleanup_fb:
+ *
+ * This hook is called to clean up any resources allocated for the given
+ * framebuffer and plane configuration in @prepare_fb.
+ *
+ * This callback is used by the atomic modeset helpers and by the
+ * transitional plane helpers, but it is optional.
+ */
void (*cleanup_fb)(struct drm_plane *plane,
const struct drm_plane_state *old_state);
+ /**
+ * @atomic_check:
+ *
+ * Drivers should check plane specific constraints in this hook.
+ *
+ * When using drm_atomic_helper_check_planes plane's ->atomic_check()
+ * hooks are called before the ones for CRTCs, which allows drivers to
+ * request shared resources that the CRTC controls here. For more
+ * complicated depencies the driver can call the provided check helpers
+ * multiple times until the computed state has a final configuration and
+ * everything has been checked.
+ *
+ * This function is also allowed to inspect any other object's state and
+ * can add more state objects to the atomic commit if needed. Care must
+ * be taken though to ensure that state check&compute functions for
+ * these added states are all called, and derived state in other objects
+ * all updated. Again the recommendation is to just call check helpers
+ * until a maximal configuration is reached.
+ *
+ * This callback is used by the atomic modeset helpers and by the
+ * transitional plane helpers, but it is optional.
+ *
+ * NOTE:
+ *
+ * This function is called in the check phase of an atomic update. The
+ * driver is not allowed to change anything outside of the free-standing
+ * state objects passed-in or assembled in the overall &drm_atomic_state
+ * update tracking structure.
+ *
+ * RETURNS:
+ *
+ * 0 on success, -EINVAL if the state or the transition can't be
+ * support, -ENOMEM on memory allocation failure and -EDEADLK if an
+ * attempt to obtain another state object ran into a &drm_modeset_lock
+ * deadlock.
+ */
int (*atomic_check)(struct drm_plane *plane,
struct drm_plane_state *state);
+
+ /**
+ * @atomic_update:
+ *
+ * Drivers should use this function to update the plane state. This
+ * hook is called in-between the ->atomic_begin and
+ * ->atomic_flush() of &drm_crtc_helper_funcs.
+ *
+ * Note that the power state of the display pipe when this function is
+ * called depends upon the exact helpers and calling sequence the driver
+ * has picked. See drm_atomic_commit_planes for a discussion of the
+ * tradeoffs and variants of plane commit helpers.
+ *
+ * This callback is used by the atomic modeset helpers and by the
+ * transitional plane helpers, but it is optional.
+ */
void (*atomic_update)(struct drm_plane *plane,
struct drm_plane_state *old_state);
+ /**
+ * @atomic_disable:
+ *
+ * Drivers should use this function to unconditionally disable a plane.
+ * This hook is called in-between the ->atomic_begin and
+ * ->atomic_flush() of &drm_crtc_helper_funcs. It is an alternative to
+ * @atomic_update, which will be called for disabling planes, too, if
+ * the @atomic_disable hook isn't implemented.
+ *
+ * This hook is also useful to disable planes in preration of a modeset,
+ * by calling drm_atomic_helper_disable_planes_on_crtc() from the
+ * ->disable hook in &drm_crtc_helper_funcs.
+ *
+ * Note that the power state of the display pipe when this function is
+ * called depends upon the exact helpers and calling sequence the driver
+ * has picked. See drm_atomic_commit_planes for a discussion of the
+ * tradeoffs and variants of plane commit helpers.
+ *
+ * This callback is used by the atomic modeset helpers and by the
+ * transitional plane helpers, but it is optional.
+ */
void (*atomic_disable)(struct drm_plane *plane,
struct drm_plane_state *old_state);
};
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 23/28] drm: Document drm_plane_helper_funcs
2015-12-04 8:46 ` [PATCH 23/28] drm: Document drm_plane_helper_funcs Daniel Vetter
@ 2015-12-07 14:27 ` Thierry Reding
2015-12-07 14:43 ` Daniel Vetter
0 siblings, 1 reply; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 14:27 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 12605 bytes --]
On Fri, Dec 04, 2015 at 09:46:04AM +0100, Daniel Vetter wrote:
> Plus related hooks used to do atomic plane updates since they only
> really make sense as a package.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> include/drm/drm_modeset_helper_vtables.h | 209 +++++++++++++++++++++++++++++--
> 1 file changed, 198 insertions(+), 11 deletions(-)
>
> diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
> index bc731754fc70..66b78c14154e 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -57,9 +57,6 @@ enum mode_set_atomic;
> * @load_lut: load color palette
> * @disable: disable CRTC when no longer in use
> * @enable: enable CRTC
> - * @atomic_check: check for validity of an atomic state
> - * @atomic_begin: begin atomic update
> - * @atomic_flush: flush atomic update
> *
> * The helper operations are called by the mid-layer CRTC helper.
> *
> @@ -103,11 +100,95 @@ struct drm_crtc_helper_funcs {
> void (*disable)(struct drm_crtc *crtc);
> void (*enable)(struct drm_crtc *crtc);
>
> - /* atomic helpers */
> + /**
> + * @atomic_check:
> + *
> + * Drivers should check plane-update related CRTC constraints in this
> + * hook. They can also check mode related limitations but need to be
> + * aware of the calling order, since this hook is used by
> + * drm_atomic_helper_check_planes() whereas the prepartions needed to
"preparations"
> + * check output routing and the display mode is done in
> + * drm_atomic_helper_check_modeset(). Therefore drivers who want to
"drivers that want to"
> + * check output routing and display mode contstraints in this callback
"constraints"
> + * mus ensure that drm_atomic_helper_check_modeset() has been called
> + * beforehand.
Perhaps mention that the default drm_atomic_helper_check()
implementation calls them in the right order?
> + *
> + * When using drm_atomic_helper_check_planes CRTC's ->atomic_check()
Parentheses after the function name? Also, technically I think it would
need to be "CRTCs'" since it relates to multiple CRTCs. Perhaps just
leaving out the 's would work as well.
> + * hooks are called after the ones for palnes, which allows drivers to
"planes"
> + * assign shared resources requested by planes in the CRTC callback
> + * here. For more complicated depencies the driver can call the provided
"dependencies"
> + * check helpers multiple times until the computed state has a final
> + * configuration and everything has been checked.
> + *
> + * This function is also allowed to inspect any other object's state and
> + * can add more state objects to the atomic commit if needed. Care must
> + * be taken though to ensure that state check&compute functions for
> + * these added states are all called, and derived state in other objects
> + * all updated. Again the recommendation is to just call check helpers
> + * until a maximal configuration is reached.
> + *
> + * This callback is used by the atomic modeset helpers and by the
> + * transitional plane helpers, but it is optional.
> + *
> + * NOTE:
> + *
> + * This function is called in the check phase of an atomic update. The
> + * driver is not allowed to change anything outside of the free-standing
> + * state objects passed-in or assembled in the overall &drm_atomic_state
> + * update tracking structure.
> + *
> + * RETURNS:
> + *
> + * 0 on success, -EINVAL if the state or the transition can't be
> + * support, -ENOMEM on memory allocation failure and -EDEADLK if an
"supported"
> + * attempt to obtain another state object ran into a &drm_modeset_lock
> + * deadlock.
> + */
> int (*atomic_check)(struct drm_crtc *crtc,
> struct drm_crtc_state *state);
> +
> + /**
> + * @atomic_begin:
> + *
> + * Drivers should prepare for an atomic update of multiple planes on
> + * a CRTC in this hook. Depending upon hardware this might be vblank
> + * evasion, blocking updates by setting bits or doing prepatory work for
"preparatory"
> + * e.g. manual update display.
> + *
> + * This hook is called before any plane commit functions are called.
> + *
> + * Note that the power state of the display pipe when this function is
> + * called depends upon the exact helpers and calling sequence the driver
> + * has picked. See drm_atomic_commit_planes for a discussion of the
Parentheses to highlight the function?
> + * tradeoffs and variants of plane commit helpers.
> + *
> + * This callback is used by the atomic modeset helpers and by the
> + * transitional plane helpers, but it is optional.
> + */
> void (*atomic_begin)(struct drm_crtc *crtc,
> struct drm_crtc_state *old_crtc_state);
> + /**
> + * @atomic_flush:
> + *
> + * Drivers should prepare for an atomic update of multiple planes on
> + * a CRTC in this hook. Depending upon hardware this might include
The first sentence here is the exact same as for ->atomic_begin(), but
it clearly has a different purpose. Perhaps:
"Drivers should finalize an atomic update of multiple planes on
a CRTC in this hook. ..."
?
> + * checking that vblank evasion was successful, unblocking updates by
> + * setting bits or setting the GO bit to flush out all updates.
> + *
> + * Simple hardware or hardware with special requirements can commit and
> + * flush out all updates for all planes from this hook and forgo all the
> + * other commit hooks for plane updates.
> + *
> + * This hook is called after any plane commit functions are called.
> + *
> + * Note that the power state of the display pipe when this function is
> + * called depends upon the exact helpers and calling sequence the driver
> + * has picked. See drm_atomic_commit_planes for a discussion of the
Again, parentheses after the function name for highlighting.
> + * tradeoffs and variants of plane commit helpers.
> + *
> + * This callback is used by the atomic modeset helpers and by the
> + * transitional plane helpers, but it is optional.
> + */
> void (*atomic_flush)(struct drm_crtc *crtc,
> struct drm_crtc_state *old_crtc_state);
> };
> @@ -211,25 +292,131 @@ static inline void drm_connector_helper_add(struct drm_connector *connector,
> }
>
> /**
> - * struct drm_plane_helper_funcs - helper operations for CRTCs
> - * @prepare_fb: prepare a framebuffer for use by the plane
> - * @cleanup_fb: cleanup a framebuffer when it's no longer used by the plane
> - * @atomic_check: check that a given atomic state is valid and can be applied
> - * @atomic_update: apply an atomic state to the plane (mandatory)
> - * @atomic_disable: disable the plane
> + * struct drm_plane_helper_funcs - helper operations for planes
> *
> - * The helper operations are called by the mid-layer CRTC helper.
> + * These functions are used by the atomic helpers and by the transitional plane
> + * helpers.
> */
> struct drm_plane_helper_funcs {
> + /**
> + * @prepare_fb:
> + *
> + * This hook is to prepare a framebuffer for scanout by e.g. pinning
> + * it's backing storage or relocating it into a contiguous block of
> + * vram. Other possible preparatory work includes flushing caches.
"VRAM"
> + *
> + * This function must not block for outstanding rendering, since it is
> + * called in the context of the atomic IOCTL even for async commits to
> + * be able to return any errors to userspace. Instead the recommended
> + * why is to fill out the fence member of the passed-in
s/why/way/?
> + * &drm_plane_state. If the driver doesn't support native fences then
> + * equivalent functionality should be implemented through private
> + * members in the plane structure.
> + *
> + * The helpers will call @cleanup_fb with matching arguments for every
> + * successful call to this hook.
> + *
> + * This callback is used by the atomic modeset helpers and by the
> + * transitional plane helpers, but it is optional.
> + *
> + * RETURNS:
> + *
> + * 0 on sucess or one of the following negative error codes allowed by
"success"
> + * the atomic_commit hook in &drm_mode_config_funcs. When using helpers
> + * this callback is the only one which can fail an atomic commit,
> + * everything else must complete successfully.
> + */
> int (*prepare_fb)(struct drm_plane *plane,
> const struct drm_plane_state *new_state);
> + /**
> + * @cleanup_fb:
> + *
> + * This hook is called to clean up any resources allocated for the given
> + * framebuffer and plane configuration in @prepare_fb.
> + *
> + * This callback is used by the atomic modeset helpers and by the
> + * transitional plane helpers, but it is optional.
> + */
> void (*cleanup_fb)(struct drm_plane *plane,
> const struct drm_plane_state *old_state);
>
> + /**
> + * @atomic_check:
> + *
> + * Drivers should check plane specific constraints in this hook.
> + *
> + * When using drm_atomic_helper_check_planes plane's ->atomic_check()
Parentheses after the function name.
> + * hooks are called before the ones for CRTCs, which allows drivers to
> + * request shared resources that the CRTC controls here. For more
> + * complicated depencies the driver can call the provided check helpers
"dependencies"
> + * multiple times until the computed state has a final configuration and
> + * everything has been checked.
> + *
> + * This function is also allowed to inspect any other object's state and
> + * can add more state objects to the atomic commit if needed. Care must
> + * be taken though to ensure that state check&compute functions for
> + * these added states are all called, and derived state in other objects
> + * all updated. Again the recommendation is to just call check helpers
> + * until a maximal configuration is reached.
> + *
> + * This callback is used by the atomic modeset helpers and by the
> + * transitional plane helpers, but it is optional.
> + *
> + * NOTE:
> + *
> + * This function is called in the check phase of an atomic update. The
> + * driver is not allowed to change anything outside of the free-standing
> + * state objects passed-in or assembled in the overall &drm_atomic_state
> + * update tracking structure.
> + *
> + * RETURNS:
> + *
> + * 0 on success, -EINVAL if the state or the transition can't be
> + * support, -ENOMEM on memory allocation failure and -EDEADLK if an
"supported"
> + * attempt to obtain another state object ran into a &drm_modeset_lock
> + * deadlock.
> + */
> int (*atomic_check)(struct drm_plane *plane,
> struct drm_plane_state *state);
> +
> + /**
> + * @atomic_update:
> + *
> + * Drivers should use this function to update the plane state. This
> + * hook is called in-between the ->atomic_begin and
"->atomic_begin()"
> + * ->atomic_flush() of &drm_crtc_helper_funcs.
> + *
> + * Note that the power state of the display pipe when this function is
> + * called depends upon the exact helpers and calling sequence the driver
> + * has picked. See drm_atomic_commit_planes for a discussion of the
Parentheses.
> + * tradeoffs and variants of plane commit helpers.
> + *
> + * This callback is used by the atomic modeset helpers and by the
> + * transitional plane helpers, but it is optional.
> + */
> void (*atomic_update)(struct drm_plane *plane,
> struct drm_plane_state *old_state);
> + /**
> + * @atomic_disable:
> + *
> + * Drivers should use this function to unconditionally disable a plane.
> + * This hook is called in-between the ->atomic_begin and
> + * ->atomic_flush() of &drm_crtc_helper_funcs. It is an alternative to
> + * @atomic_update, which will be called for disabling planes, too, if
> + * the @atomic_disable hook isn't implemented.
> + *
> + * This hook is also useful to disable planes in preration of a modeset,
"preparation"
> + * by calling drm_atomic_helper_disable_planes_on_crtc() from the
> + * ->disable hook in &drm_crtc_helper_funcs.
"->disable()"
> + *
> + * Note that the power state of the display pipe when this function is
> + * called depends upon the exact helpers and calling sequence the driver
> + * has picked. See drm_atomic_commit_planes for a discussion of the
Parentheses.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 23/28] drm: Document drm_plane_helper_funcs
2015-12-07 14:27 ` Thierry Reding
@ 2015-12-07 14:43 ` Daniel Vetter
0 siblings, 0 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-07 14:43 UTC (permalink / raw)
To: Thierry Reding
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
On Mon, Dec 07, 2015 at 03:27:59PM +0100, Thierry Reding wrote:
> On Fri, Dec 04, 2015 at 09:46:04AM +0100, Daniel Vetter wrote:
> > + * mus ensure that drm_atomic_helper_check_modeset() has been called
> > + * beforehand.
>
> Perhaps mention that the default drm_atomic_helper_check()
> implementation calls them in the right order?
Good idea, added a sentence with reference to drm_atomic_helper_check().
>
> > + *
> > + * When using drm_atomic_helper_check_planes CRTC's ->atomic_check()
>
> Parentheses after the function name? Also, technically I think it would
> need to be "CRTCs'" since it relates to multiple CRTCs. Perhaps just
> leaving out the 's would work as well.
I went with CRTCs'.
> > void (*atomic_begin)(struct drm_crtc *crtc,
> > struct drm_crtc_state *old_crtc_state);
> > + /**
> > + * @atomic_flush:
> > + *
> > + * Drivers should prepare for an atomic update of multiple planes on
> > + * a CRTC in this hook. Depending upon hardware this might include
>
> The first sentence here is the exact same as for ->atomic_begin(), but
> it clearly has a different purpose. Perhaps:
>
> "Drivers should finalize an atomic update of multiple planes on
> a CRTC in this hook. ..."
>
> ?
Sounds good, simply forgotten to update that part.
All other suggestions applied, thanks a lot for all your careful comments.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 24/28] drm: Document drm_connector_helper_funcs
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (22 preceding siblings ...)
2015-12-04 8:46 ` [PATCH 23/28] drm: Document drm_plane_helper_funcs Daniel Vetter
@ 2015-12-04 8:46 ` Daniel Vetter
2015-12-07 14:42 ` Thierry Reding
2015-12-04 8:46 ` [PATCH 25/28] drm/atomic-helper: Mention the new system/resume helpers the docs Daniel Vetter
` (3 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:46 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development
Nothing special, except the somewhat awkard split in probe helper
callbacks between here and drm_crtc_funcs.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
include/drm/drm_modeset_helper_vtables.h | 106 +++++++++++++++++++++++++++++--
1 file changed, 101 insertions(+), 5 deletions(-)
diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
index 66b78c14154e..22cc51b278fb 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -264,18 +264,114 @@ static inline void drm_encoder_helper_add(struct drm_encoder *encoder,
/**
* struct drm_connector_helper_funcs - helper operations for connectors
- * @get_modes: get mode list for this connector
- * @mode_valid: is this mode valid on the given connector? (optional)
- * @best_encoder: return the preferred encoder for this connector
- * @atomic_best_encoder: atomic version of @best_encoder
*
- * The helper operations are called by the mid-layer CRTC helper.
+ * These functions are used by the atomic and legacy modeset helpers and by the
+ * probe helpers.
*/
struct drm_connector_helper_funcs {
+ /**
+ * @get_modes:
+ *
+ * This function should fill in all modes currently valid for the sink
+ * into the connector->probe_modes function. It should also update the
+ * EDID property by calling drm_mode_connector_update_edid_property().
+ *
+ * The usual way to implement this is to cache the EDID retrieved in the
+ * probe callback somewhere in the driver-private connector structure.
+ * In this function drivers then parse the modes in the EDID and add it
+ * by calling drm_add_edid_modes(). But connectors that driver a fixed
+ * panel can also manually add specific modes using
+ * drm_mode_probed_add(). Finally drivers that support audio propably
+ * want to update the ELD data, too, using drm_edid_to_eld().
+ *
+ * This function is only called after the ->detect() hook has indicated
+ * that a sink is connected and when the EDID isn't overriden through
+ * sysfs or the kernel commandline.
+ *
+ * This callback is used by the probe helpers in e.g.
+ * drm_helper_probe_single_connector_modes().
+ *
+ * RETURNS:
+ *
+ * The number of modes added by calling drm_mode_probed_add().
+ */
int (*get_modes)(struct drm_connector *connector);
+
+ /**
+ * @mode_valid:
+ *
+ * Callback to validate a mode for a connector, irrespective of the
+ * specific display configuration.
+ *
+ * This callback is used by the probe helpers to filter the mode list
+ * (which is usually derived from the EDID data block from the sink).
+ * See e.g. drm_helper_probe_single_connector_modes().
+ *
+ * NOTE:
+ *
+ * This only filters the mode list supplied to userspace in the
+ * GETCONNECOTR ioctl. Userspace is free to create modes of its own and
+ * ask the kernel to use it. It this case the atomic helpers or legacy
+ * CRTC heleprs will not call this function. Drivers therefore must
+ * still fully validate any mode passed in in a modeset request.
+ *
+ * RETURNS:
+ *
+ * Either DRM_MODE_OK or one of the failure reasons in enum
+ * &drm_mode_status.
+ */
enum drm_mode_status (*mode_valid)(struct drm_connector *connector,
struct drm_display_mode *mode);
+ /**
+ * @best_encoder:
+ *
+ * This function should select the best encoder for the given connector.
+ *
+ * This function is used by both the atomic helpers (in the
+ * drm_atomic_helper_check_modeset() function) and in the legacy CRTC
+ * helpers.
+ *
+ * NOTE:
+ *
+ * In atomic drivers this function is called in the check phase of an
+ * atomic update. The driver is not allowed to change or inspect
+ * anything outside of arguments passed-in. Atomic drivers which need to
+ * inspect dynamic configuration state should instead use
+ * @atomic_best_encoder.
+ *
+ * RETURNS:
+ *
+ * Encoder that should be used for the given connector and connector
+ * state, or NULL if no suitable encoder exists. Note that the helpers
+ * will ensure that encoders aren't used twice, drivers should not check
+ * for this.
+ */
struct drm_encoder *(*best_encoder)(struct drm_connector *connector);
+
+ /**
+ * @atomic_best_encoder:
+ *
+ * This is the atomic version of @best_encoder for atomic drivers which
+ * need to select the best encoder depending upon the desired
+ * configuration and can't select it statically.
+ *
+ * This function is used by drm_atomic_helper_check_modeset() and either
+ * this or @best_encoder is required.
+ *
+ * NOTE:
+ *
+ * This function is called in the check phase of an atomic update. The
+ * driver is not allowed to change anything outside of the free-standing
+ * state objects passed-in or assembled in the overall &drm_atomic_state
+ * update tracking structure.
+ *
+ * RETURNS:
+ *
+ * Encoder that should be used for the given connector and connector
+ * state, or NULL if no suitable encoder exists. Note that the helpers
+ * will ensure that encoders aren't used twice, drivers should not check
+ * for this.
+ */
struct drm_encoder *(*atomic_best_encoder)(struct drm_connector *connector,
struct drm_connector_state *connector_state);
};
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 24/28] drm: Document drm_connector_helper_funcs
2015-12-04 8:46 ` [PATCH 24/28] drm: Document drm_connector_helper_funcs Daniel Vetter
@ 2015-12-07 14:42 ` Thierry Reding
2015-12-07 14:48 ` Daniel Vetter
0 siblings, 1 reply; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 14:42 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 3247 bytes --]
On Fri, Dec 04, 2015 at 09:46:05AM +0100, Daniel Vetter wrote:
> Nothing special, except the somewhat awkard split in probe helper
"awkward"
> callbacks between here and drm_crtc_funcs.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> include/drm/drm_modeset_helper_vtables.h | 106 +++++++++++++++++++++++++++++--
> 1 file changed, 101 insertions(+), 5 deletions(-)
>
> diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
> index 66b78c14154e..22cc51b278fb 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -264,18 +264,114 @@ static inline void drm_encoder_helper_add(struct drm_encoder *encoder,
>
> /**
> * struct drm_connector_helper_funcs - helper operations for connectors
> - * @get_modes: get mode list for this connector
> - * @mode_valid: is this mode valid on the given connector? (optional)
> - * @best_encoder: return the preferred encoder for this connector
> - * @atomic_best_encoder: atomic version of @best_encoder
> *
> - * The helper operations are called by the mid-layer CRTC helper.
> + * These functions are used by the atomic and legacy modeset helpers and by the
> + * probe helpers.
> */
> struct drm_connector_helper_funcs {
> + /**
> + * @get_modes:
> + *
> + * This function should fill in all modes currently valid for the sink
> + * into the connector->probe_modes function. It should also update the
What's probe_modes? I've never heard of it. Did you mean ->fill_modes()?
Also it's strange to say "fill into the ... function". Perhaps "pass
into the ... function" instead?
> + * EDID property by calling drm_mode_connector_update_edid_property().
> + *
> + * The usual way to implement this is to cache the EDID retrieved in the
> + * probe callback somewhere in the driver-private connector structure.
> + * In this function drivers then parse the modes in the EDID and add it
"add them"?
> + * by calling drm_add_edid_modes(). But connectors that driver a fixed
"drive"
> + * panel can also manually add specific modes using
> + * drm_mode_probed_add(). Finally drivers that support audio propably
"probably"
> + /**
> + * @mode_valid:
> + *
> + * Callback to validate a mode for a connector, irrespective of the
> + * specific display configuration.
> + *
> + * This callback is used by the probe helpers to filter the mode list
> + * (which is usually derived from the EDID data block from the sink).
> + * See e.g. drm_helper_probe_single_connector_modes().
> + *
> + * NOTE:
> + *
> + * This only filters the mode list supplied to userspace in the
> + * GETCONNECOTR ioctl. Userspace is free to create modes of its own and
"GETCONNECTOR IOCTL"
> + * ask the kernel to use it. It this case the atomic helpers or legacy
"to use them"
> + * CRTC heleprs will not call this function. Drivers therefore must
"helpers"
> + * still fully validate any mode passed in in a modeset request.
> + *
> + * RETURNS:
> + *
> + * Either DRM_MODE_OK or one of the failure reasons in enum
The enum value is MODE_OK, without the DRM_ prefix.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 24/28] drm: Document drm_connector_helper_funcs
2015-12-07 14:42 ` Thierry Reding
@ 2015-12-07 14:48 ` Daniel Vetter
2015-12-07 15:27 ` Thierry Reding
0 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-07 14:48 UTC (permalink / raw)
To: Thierry Reding; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
On Mon, Dec 07, 2015 at 03:42:22PM +0100, Thierry Reding wrote:
> On Fri, Dec 04, 2015 at 09:46:05AM +0100, Daniel Vetter wrote:
> > Nothing special, except the somewhat awkard split in probe helper
>
> "awkward"
>
> > callbacks between here and drm_crtc_funcs.
> >
> > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > ---
> > include/drm/drm_modeset_helper_vtables.h | 106 +++++++++++++++++++++++++++++--
> > 1 file changed, 101 insertions(+), 5 deletions(-)
> >
> > diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
> > index 66b78c14154e..22cc51b278fb 100644
> > --- a/include/drm/drm_modeset_helper_vtables.h
> > +++ b/include/drm/drm_modeset_helper_vtables.h
> > @@ -264,18 +264,114 @@ static inline void drm_encoder_helper_add(struct drm_encoder *encoder,
> >
> > /**
> > * struct drm_connector_helper_funcs - helper operations for connectors
> > - * @get_modes: get mode list for this connector
> > - * @mode_valid: is this mode valid on the given connector? (optional)
> > - * @best_encoder: return the preferred encoder for this connector
> > - * @atomic_best_encoder: atomic version of @best_encoder
> > *
> > - * The helper operations are called by the mid-layer CRTC helper.
> > + * These functions are used by the atomic and legacy modeset helpers and by the
> > + * probe helpers.
> > */
> > struct drm_connector_helper_funcs {
> > + /**
> > + * @get_modes:
> > + *
> > + * This function should fill in all modes currently valid for the sink
> > + * into the connector->probe_modes function. It should also update the
>
> What's probe_modes? I've never heard of it. Did you mean ->fill_modes()?
> Also it's strange to say "fill into the ... function". Perhaps "pass
> into the ... function" instead?
connector->probe*d*_modes *list* is what it should read. Fixed.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 24/28] drm: Document drm_connector_helper_funcs
2015-12-07 14:48 ` Daniel Vetter
@ 2015-12-07 15:27 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 15:27 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 2162 bytes --]
On Mon, Dec 07, 2015 at 03:48:37PM +0100, Daniel Vetter wrote:
> On Mon, Dec 07, 2015 at 03:42:22PM +0100, Thierry Reding wrote:
> > On Fri, Dec 04, 2015 at 09:46:05AM +0100, Daniel Vetter wrote:
> > > Nothing special, except the somewhat awkard split in probe helper
> >
> > "awkward"
> >
> > > callbacks between here and drm_crtc_funcs.
> > >
> > > Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> > > ---
> > > include/drm/drm_modeset_helper_vtables.h | 106 +++++++++++++++++++++++++++++--
> > > 1 file changed, 101 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
> > > index 66b78c14154e..22cc51b278fb 100644
> > > --- a/include/drm/drm_modeset_helper_vtables.h
> > > +++ b/include/drm/drm_modeset_helper_vtables.h
> > > @@ -264,18 +264,114 @@ static inline void drm_encoder_helper_add(struct drm_encoder *encoder,
> > >
> > > /**
> > > * struct drm_connector_helper_funcs - helper operations for connectors
> > > - * @get_modes: get mode list for this connector
> > > - * @mode_valid: is this mode valid on the given connector? (optional)
> > > - * @best_encoder: return the preferred encoder for this connector
> > > - * @atomic_best_encoder: atomic version of @best_encoder
> > > *
> > > - * The helper operations are called by the mid-layer CRTC helper.
> > > + * These functions are used by the atomic and legacy modeset helpers and by the
> > > + * probe helpers.
> > > */
> > > struct drm_connector_helper_funcs {
> > > + /**
> > > + * @get_modes:
> > > + *
> > > + * This function should fill in all modes currently valid for the sink
> > > + * into the connector->probe_modes function. It should also update the
> >
> > What's probe_modes? I've never heard of it. Did you mean ->fill_modes()?
> > Also it's strange to say "fill into the ... function". Perhaps "pass
> > into the ... function" instead?
>
> connector->probe*d*_modes *list* is what it should read. Fixed.
As with all the other patches, with this and the nits fixed:
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 25/28] drm/atomic-helper: Mention the new system/resume helpers the docs
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (23 preceding siblings ...)
2015-12-04 8:46 ` [PATCH 24/28] drm: Document drm_connector_helper_funcs Daniel Vetter
@ 2015-12-04 8:46 ` Daniel Vetter
2015-12-07 14:45 ` Thierry Reding
2015-12-04 8:46 ` [PATCH 26/28] drm: Move drm_display_mode an related docs into kerneldoc Daniel Vetter
` (2 subsequent siblings)
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:46 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development
They have pretty kerneldoc already, but better to link to that in
one of the overview sections.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/drm_atomic_helper.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index ab275499d2a3..110f3db8dd05 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2405,6 +2405,12 @@ EXPORT_SYMBOL(drm_atomic_helper_connector_dpms);
* The simpler solution is to just reset the software state to everything off,
* which is easiest to do by calling drm_mode_config_reset(). To facilitate this
* the atomic helpers provide default reset implementations for all hooks.
+ *
+ * On the upside the precise state tracking of atomic simplifies system suspend
+ * and resume a lot. For drivers using drm_mode_config_reset() a complete recipe
+ * is implemented in drm_atomic_helper_suspend() and drm_atomic_helper_resume().
+ * For other drivers the building blocks are split out, see the documentation
+ * for these functions.
*/
/**
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 25/28] drm/atomic-helper: Mention the new system/resume helpers the docs
2015-12-04 8:46 ` [PATCH 25/28] drm/atomic-helper: Mention the new system/resume helpers the docs Daniel Vetter
@ 2015-12-07 14:45 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 14:45 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 373 bytes --]
On Fri, Dec 04, 2015 at 09:46:06AM +0100, Daniel Vetter wrote:
> They have pretty kerneldoc already, but better to link to that in
> one of the overview sections.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: Thierry Reding <treding@nvidia.com>
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 26/28] drm: Move drm_display_mode an related docs into kerneldoc
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (24 preceding siblings ...)
2015-12-04 8:46 ` [PATCH 25/28] drm/atomic-helper: Mention the new system/resume helpers the docs Daniel Vetter
@ 2015-12-04 8:46 ` Daniel Vetter
2015-12-07 13:39 ` Ville Syrjälä
2015-12-07 15:02 ` Thierry Reding
2015-12-04 8:46 ` [PATCH 27/28] drm: Document drm_encoder/crtc_helper_funcs Daniel Vetter
2015-12-04 8:46 ` [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe Daniel Vetter
27 siblings, 2 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:46 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Vetter
This was in the documentation for modeset helper hooks, where it is a
bit misplaced.
v2: Reindent the drm_mode_status enum, inspired by Ville.
Cc: ville.syrjala@linux.intel.com
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
---
Documentation/DocBook/gpu.tmpl | 192 -----------------------
drivers/gpu/drm/drm_modes.c | 3 +-
include/drm/drm_modes.h | 342 +++++++++++++++++++++++++++++++++++------
3 files changed, 297 insertions(+), 240 deletions(-)
diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
index 5312f5a05798..86e5b12a49ba 100644
--- a/Documentation/DocBook/gpu.tmpl
+++ b/Documentation/DocBook/gpu.tmpl
@@ -1758,198 +1758,6 @@ void intel_crt_init(struct drm_device *dev)
<function>drm_add_edid_modes</function> manually in that case.
</para>
<para>
- When adding modes manually the driver creates each mode with a call to
- <function>drm_mode_create</function> and must fill the following fields.
- <itemizedlist>
- <listitem>
- <synopsis>__u32 type;</synopsis>
- <para>
- Mode type bitmask, a combination of
- <variablelist>
- <varlistentry>
- <term>DRM_MODE_TYPE_BUILTIN</term>
- <listitem><para>not used?</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_TYPE_CLOCK_C</term>
- <listitem><para>not used?</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_TYPE_CRTC_C</term>
- <listitem><para>not used?</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>
- DRM_MODE_TYPE_PREFERRED - The preferred mode for the connector
- </term>
- <listitem>
- <para>not used?</para>
- </listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_TYPE_DEFAULT</term>
- <listitem><para>not used?</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_TYPE_USERDEF</term>
- <listitem><para>not used?</para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_TYPE_DRIVER</term>
- <listitem>
- <para>
- The mode has been created by the driver (as opposed to
- to user-created modes).
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
- Drivers must set the DRM_MODE_TYPE_DRIVER bit for all modes they
- create, and set the DRM_MODE_TYPE_PREFERRED bit for the preferred
- mode.
- </para>
- </listitem>
- <listitem>
- <synopsis>__u32 clock;</synopsis>
- <para>Pixel clock frequency in kHz unit</para>
- </listitem>
- <listitem>
- <synopsis>__u16 hdisplay, hsync_start, hsync_end, htotal;
- __u16 vdisplay, vsync_start, vsync_end, vtotal;</synopsis>
- <para>Horizontal and vertical timing information</para>
- <screen><![CDATA[
- Active Front Sync Back
- Region Porch Porch
- <-----------------------><----------------><-------------><-------------->
-
- //////////////////////|
- ////////////////////// |
- ////////////////////// |.................. ................
- _______________
-
- <----- [hv]display ----->
- <------------- [hv]sync_start ------------>
- <--------------------- [hv]sync_end --------------------->
- <-------------------------------- [hv]total ----------------------------->
-]]></screen>
- </listitem>
- <listitem>
- <synopsis>__u16 hskew;
- __u16 vscan;</synopsis>
- <para>Unknown</para>
- </listitem>
- <listitem>
- <synopsis>__u32 flags;</synopsis>
- <para>
- Mode flags, a combination of
- <variablelist>
- <varlistentry>
- <term>DRM_MODE_FLAG_PHSYNC</term>
- <listitem><para>
- Horizontal sync is active high
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_NHSYNC</term>
- <listitem><para>
- Horizontal sync is active low
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_PVSYNC</term>
- <listitem><para>
- Vertical sync is active high
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_NVSYNC</term>
- <listitem><para>
- Vertical sync is active low
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_INTERLACE</term>
- <listitem><para>
- Mode is interlaced
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_DBLSCAN</term>
- <listitem><para>
- Mode uses doublescan
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_CSYNC</term>
- <listitem><para>
- Mode uses composite sync
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_PCSYNC</term>
- <listitem><para>
- Composite sync is active high
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_NCSYNC</term>
- <listitem><para>
- Composite sync is active low
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_HSKEW</term>
- <listitem><para>
- hskew provided (not used?)
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_BCAST</term>
- <listitem><para>
- not used?
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_PIXMUX</term>
- <listitem><para>
- not used?
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_DBLCLK</term>
- <listitem><para>
- not used?
- </para></listitem>
- </varlistentry>
- <varlistentry>
- <term>DRM_MODE_FLAG_CLKDIV2</term>
- <listitem><para>
- ?
- </para></listitem>
- </varlistentry>
- </variablelist>
- </para>
- <para>
- Note that modes marked with the INTERLACE or DBLSCAN flags will be
- filtered out by
- <function>drm_helper_probe_single_connector_modes</function> if
- the connector's <structfield>interlace_allowed</structfield> or
- <structfield>doublescan_allowed</structfield> field is set to 0.
- </para>
- </listitem>
- <listitem>
- <synopsis>char name[DRM_DISPLAY_MODE_LEN];</synopsis>
- <para>
- Mode name. The driver must call
- <function>drm_mode_set_name</function> to fill the mode name from
- <structfield>hdisplay</structfield>,
- <structfield>vdisplay</structfield> and interlace flag after
- filling the corresponding fields.
- </para>
- </listitem>
- </itemizedlist>
- </para>
- <para>
The <structfield>vrefresh</structfield> value is computed by
<function>drm_helper_probe_single_connector_modes</function>.
</para>
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index 5f79b9334a38..041138f5acc9 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -708,7 +708,8 @@ void drm_mode_set_name(struct drm_display_mode *mode)
}
EXPORT_SYMBOL(drm_mode_set_name);
-/** drm_mode_hsync - get the hsync of a mode
+/**
+ * drm_mode_hsync - get the hsync of a mode
* @mode: mode
*
* Returns:
diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
index f9115aee43f4..cd3c42256ab8 100644
--- a/include/drm/drm_modes.h
+++ b/include/drm/drm_modes.h
@@ -35,46 +35,91 @@
* structures).
*/
+/**
+ * enum drm_mode_status - hardware support status of a mode
+ * @MODE_OK: Mode OK
+ * @MODE_HSYNC: hsync out of range
+ * @MODE_VSYNC: vsync out of range
+ * @MODE_H_ILLEGAL: mode has illegal horizontal timings
+ * @MODE_V_ILLEGAL: mode has illegal horizontal timings
+ * @MODE_BAD_WIDTH: requires an unsupported linepitch
+ * @MODE_NOMODE: no mode with a matching name
+ * @MODE_NO_INTERLACE: interlaced mode not supported
+ * @MODE_NO_DBLESCAN: doublescan mode not supported
+ * @MODE_NO_VSCAN: multiscan mode not supported
+ * @MODE_MEM: insufficient video memory
+ * @MODE_VIRTUAL_X: mode width too large for specified virtual size
+ * @MODE_VIRTUAL_Y: mode height too large for specified virtual size
+ * @MODE_MEM_VIRT: insufficient video memory given virtual size
+ * @MODE_NOCLOCK: no fixed clock available
+ * @MODE_CLOCK_HIGH: clock required is too high
+ * @MODE_CLOCK_LOW: clock required is too low
+ * @MODE_CLOCK_RANGE: clock/mode isn't in a ClockRange
+ * @MODE_BAD_HVALUE: horizontal timing was out of range
+ * @MODE_BAD_VVALUE: vertical timing was out of range
+ * @MODE_BAD_VSCAN: VScan value out of range
+ * @MODE_HSYNC_NARROW: horizontal sync too narrow
+ * @MODE_HSYNC_WIDE: horizontal sync too wide
+ * @MODE_HBLANK_NARROW: horizontal blanking too narrow
+ * @MODE_HBLANK_WIDE: horizontal blanking too wide
+ * @MODE_VSYNC_NARROW: vertical sync too narrow
+ * @MODE_VSYNC_WIDE: vertical sync too wide
+ * @MODE_VBLANK_NARROW: vertical blanking too narrow
+ * @MODE_VBLANK_WIDE: vertical blanking too wide
+ * @MODE_PANEL: exceeds panel dimensions
+ * @MODE_INTERLACE_WIDTH: width too large for interlaced mode
+ * @MODE_ONE_WIDTH: only one width is supported
+ * @MODE_ONE_HEIGHT: only one height is supported
+ * @MODE_ONE_SIZE: only one resolution is supported
+ * @MODE_NO_REDUCED: monitor doesn't accept reduced blanking
+ * @MODE_NO_STEREO: stereo modes not supported
+ * @MODE_UNVERIFIED: mode needs to reverified
+ * @MODE_BAD: unspecified reason
+ * @MODE_ERROR: error condition
+ *
+ * This enum is used to filter out modes not supported by the driver/hardware
+ * combination.
+ */
enum drm_mode_status {
- MODE_OK = 0, /* Mode OK */
- MODE_HSYNC, /* hsync out of range */
- MODE_VSYNC, /* vsync out of range */
- MODE_H_ILLEGAL, /* mode has illegal horizontal timings */
- MODE_V_ILLEGAL, /* mode has illegal horizontal timings */
- MODE_BAD_WIDTH, /* requires an unsupported linepitch */
- MODE_NOMODE, /* no mode with a matching name */
- MODE_NO_INTERLACE, /* interlaced mode not supported */
- MODE_NO_DBLESCAN, /* doublescan mode not supported */
- MODE_NO_VSCAN, /* multiscan mode not supported */
- MODE_MEM, /* insufficient video memory */
- MODE_VIRTUAL_X, /* mode width too large for specified virtual size */
- MODE_VIRTUAL_Y, /* mode height too large for specified virtual size */
- MODE_MEM_VIRT, /* insufficient video memory given virtual size */
- MODE_NOCLOCK, /* no fixed clock available */
- MODE_CLOCK_HIGH, /* clock required is too high */
- MODE_CLOCK_LOW, /* clock required is too low */
- MODE_CLOCK_RANGE, /* clock/mode isn't in a ClockRange */
- MODE_BAD_HVALUE, /* horizontal timing was out of range */
- MODE_BAD_VVALUE, /* vertical timing was out of range */
- MODE_BAD_VSCAN, /* VScan value out of range */
- MODE_HSYNC_NARROW, /* horizontal sync too narrow */
- MODE_HSYNC_WIDE, /* horizontal sync too wide */
- MODE_HBLANK_NARROW, /* horizontal blanking too narrow */
- MODE_HBLANK_WIDE, /* horizontal blanking too wide */
- MODE_VSYNC_NARROW, /* vertical sync too narrow */
- MODE_VSYNC_WIDE, /* vertical sync too wide */
- MODE_VBLANK_NARROW, /* vertical blanking too narrow */
- MODE_VBLANK_WIDE, /* vertical blanking too wide */
- MODE_PANEL, /* exceeds panel dimensions */
- MODE_INTERLACE_WIDTH, /* width too large for interlaced mode */
- MODE_ONE_WIDTH, /* only one width is supported */
- MODE_ONE_HEIGHT, /* only one height is supported */
- MODE_ONE_SIZE, /* only one resolution is supported */
- MODE_NO_REDUCED, /* monitor doesn't accept reduced blanking */
- MODE_NO_STEREO, /* stereo modes not supported */
- MODE_UNVERIFIED = -3, /* mode needs to reverified */
- MODE_BAD = -2, /* unspecified reason */
- MODE_ERROR = -1 /* error condition */
+ MODE_OK = 0,
+ MODE_HSYNC,
+ MODE_VSYNC,
+ MODE_H_ILLEGAL,
+ MODE_V_ILLEGAL,
+ MODE_BAD_WIDTH,
+ MODE_NOMODE,
+ MODE_NO_INTERLACE,
+ MODE_NO_DBLESCAN,
+ MODE_NO_VSCAN,
+ MODE_MEM,
+ MODE_VIRTUAL_X,
+ MODE_VIRTUAL_Y,
+ MODE_MEM_VIRT,
+ MODE_NOCLOCK,
+ MODE_CLOCK_HIGH,
+ MODE_CLOCK_LOW,
+ MODE_CLOCK_RANGE,
+ MODE_BAD_HVALUE,
+ MODE_BAD_VVALUE,
+ MODE_BAD_VSCAN,
+ MODE_HSYNC_NARROW,
+ MODE_HSYNC_WIDE,
+ MODE_HBLANK_NARROW,
+ MODE_HBLANK_WIDE,
+ MODE_VSYNC_NARROW,
+ MODE_VSYNC_WIDE,
+ MODE_VBLANK_NARROW,
+ MODE_VBLANK_WIDE,
+ MODE_PANEL,
+ MODE_INTERLACE_WIDTH,
+ MODE_ONE_WIDTH,
+ MODE_ONE_HEIGHT,
+ MODE_ONE_SIZE,
+ MODE_NO_REDUCED,
+ MODE_NO_STEREO,
+ MODE_UNVERIFIED = -3,
+ MODE_BAD = -2,
+ MODE_ERROR = -1
};
#define DRM_MODE_TYPE_CLOCK_CRTC_C (DRM_MODE_TYPE_CLOCK_C | \
@@ -96,17 +141,124 @@ enum drm_mode_status {
#define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
+/**
+ * struct drm_display_mode - DRM kernel-internal display mode structure
+ * @hdisplay: horizontal display size
+ * @hsync_start: horizontal sync start
+ * @hsync_end: horizontal sync end
+ * @htotal: horizontal total size
+ * @hskew: horizontal skew?!
+ * @vdisplay: vertical display size
+ * @vsync_start: vertical sync start
+ * @vsync_end: vertical sync end
+ * @vtotal: vertical total size
+ * @vscan: vertical scan?!
+ * @crtc_hdisplay: hardware modehorizontal display size
+ * @crtc_hsync_start: hardware modehorizontal sync start
+ * @crtc_hsync_end: hardware modehorizontal sync end
+ * @crtc_htotal: hardware modehorizontal total size
+ * @crtc_hskew: hardware modehorizontal skew?!
+ * @crtc_vdisplay: hardware modevertical display size
+ * @crtc_vsync_start: hardware modevertical sync start
+ * @crtc_vsync_end: hardware modevertical sync end
+ * @crtc_vtotal: hardware modevertical total size
+ * @crtc_vscan: hardware modevertical scan?!
+ *
+ * The horizontal an vertical timings are defined per the following diagram:
+ *
+ *
+ * Active Front Sync Back
+ * Region Porch Porch
+ * <-----------------------><----------------><-------------><-------------->
+ *
+ * //////////////////////|
+ * ////////////////////// |
+ * ////////////////////// |.................. ................
+ * _______________
+ *
+ * <----- [hv]display ----->
+ * <------------- [hv]sync_start ------------>
+ * <--------------------- [hv]sync_end --------------------->
+ * <-------------------------------- [hv]total ----------------------------->*
+ *
+ * This structure contains two copies of timings. First are the plain timings,
+ * which specify the logical mode, as it would be for a progressive 1:1 scanout
+ * at the refresh rate userspace can observe through vblank timestamps. Then
+ * there's the hardware timings, which are corrected for interlacing,
+ * double-clocking and similar things. They are provided as a convience, and can
+ * be appropriately computed using drm_mode_set_crtcinfo().
+ */
struct drm_display_mode {
- /* Header */
+ /**
+ * @head:
+ *
+ * struct list_head for mode lists.
+ */
struct list_head head;
+
+ /**
+ * @base:
+ *
+ * A display mode is a normal modeset object, possibly including public
+ * userspace id.
+ *
+ * FIXME:
+ *
+ * This can probably be removed since the entire concept of userspace
+ * managing modes explicitly hasn't ever landed in upstream kernel mode
+ * setting support.
+ */
struct drm_mode_object base;
+ /**
+ * @name:
+ *
+ * Human-readable name of the mode, filled out with drm_mode_set_name().
+ */
char name[DRM_DISPLAY_MODE_LEN];
+ /**
+ * @status:
+ *
+ * Status of the mode, used to filter out modes not supported by the
+ * hardware. See enum &drm_mode_status.
+ */
enum drm_mode_status status;
+
+ /**
+ * @type:
+ *
+ * A bitmask of flags, mostly about the source of a mode. Possible flags
+ * are:
+ *
+ * - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, effectively
+ * unused.
+ * - DRM_MODE_TYPE_PREFERRED: Preferred mode, usually the native
+ * resolution of an LCD panel. There should only be one preferred
+ * mode per connector at any given time.
+ * - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
+ * them really. Drivers must set this bit for all modes they create
+ * and expose to userspace.
+ *
+ * Plus a big list of flags which shouldn't be used at all, but are
+ * still around since these flags are also used in the userspace ABI:
+ *
+ * - DRM_MODE_TYPE_DEFAULT: Again a leftover, use
+ * DRM_MODE_TYPE_PREFERRED instead.
+ * - DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
+ * which are stuck around for hysterical raisins only. No one has an
+ * idea what they where meant for. Don't use.
+ * - DRM_MODE_TYPE_USERDEF: Mode defined by userspace, again a vestige
+ * from older kms designs where userspace had to first add a custom
+ * mode to the kernel's mode list before it could use it. Don't use.
+ */
unsigned int type;
- /* Proposed mode values */
+ /**
+ * @clock:
+ *
+ * Pixel clock in kHz.
+ */
int clock; /* in kHz */
int hdisplay;
int hsync_start;
@@ -118,14 +270,74 @@ struct drm_display_mode {
int vsync_end;
int vtotal;
int vscan;
+ /**
+ * @flags:
+ *
+ * Sync and timing flags:
+ *
+ * - DRM_MODE_FLAG_PHSYNC: horizontal sync is active high.
+ * - DRM_MODE_FLAG_NHSYNC: horizontal sync is active low.
+ * - DRM_MODE_FLAG_PVSYNC: vertical sync is active high.
+ * - DRM_MODE_FLAG_NVSYNC: vertical sync is active low.
+ * - DRM_MODE_FLAG_INTERLACE: mode is interlaced.
+ * - DRM_MODE_FLAG_DBLSCAN: mode uses doublescan.
+ * - DRM_MODE_FLAG_CSYNC: mode uses composite sync.
+ * - DRM_MODE_FLAG_PCSYNC: composite sync is active high.
+ * - DRM_MODE_FLAG_NCSYNC: composite sync is active low.
+ * - DRM_MODE_FLAG_HSKEW: hskew provided (not used?).
+ * - DRM_MODE_FLAG_BCAST: not used?
+ * - DRM_MODE_FLAG_PIXMUX: not used?
+ * - DRM_MODE_FLAG_DBLCLK: double-clocked mode.
+ * - DRM_MODE_FLAG_CLKDIV2: half-clocked mode.
+ *
+ * Additionally there's flags to specify how 3D modes are packed:
+ *
+ * - DRM_MODE_FLAG_3D_NONE: normal, non-3D mode.
+ * - DRM_MODE_FLAG_3D_FRAME_PACKING: 2 full frames for left and right.
+ * - DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE: interleaved like fields.
+ * - DRM_MODE_FLAG_3D_LINE_ALTERNATIVE: interleaved lines.
+ * - DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL: side-by-side full frames.
+ * - DRM_MODE_FLAG_3D_L_DEPTH: ?
+ * - DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH: ?
+ * - DRM_MODE_FLAG_3D_TOP_AND_BOTTOM: frame split into top and bottom
+ * parts.
+ * - DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF: frame split into left and
+ * right parts.
+ */
unsigned int flags;
- /* Addressable image size (may be 0 for projectors, etc.) */
+ /**
+ * @width_mm:
+ *
+ * Addressable size of the output in mm, projectors should set this to
+ * 0.
+ */
int width_mm;
+
+ /**
+ * @height_mm:
+ *
+ * Addressable size of the output in mm, projectors should set this to
+ * 0.
+ */
int height_mm;
- /* Actual mode we give to hw */
- int crtc_clock; /* in KHz */
+ /**
+ * @crtc_clock:
+ *
+ * Actual pixel or dot clock in the hardware. This differs from the
+ * logical @clock when e.g. using interlacing, double-clocking, stereo
+ * modes or other fancy stuff that changes the timings and signals
+ * actually sent over the wire.
+ *
+ * This is again in kHz.
+ *
+ * Note that with digital outputs like HDMI or DP there's usually a
+ * massive confusion between the dot clock and the signal clock at the
+ * bit encoding level. Especially when a 8b/10b encoding is used and the
+ * differences is exactly a factor of 10.
+ */
+ int crtc_clock;
int crtc_hdisplay;
int crtc_hblank_start;
int crtc_hblank_end;
@@ -140,12 +352,48 @@ struct drm_display_mode {
int crtc_vsync_end;
int crtc_vtotal;
- /* Driver private mode info */
+ /**
+ * @private:
+ *
+ * Pointer for driver private data. This can only be used for mode
+ * objects passed to drivers in modeset operations. It shouldn't be used
+ * by atomic drivers since they can store any additional data by
+ * subclassing state structures.
+ */
int *private;
+
+ /**
+ * @private_flags:
+ *
+ * Similar to @private, but just an integer.
+ */
int private_flags;
- int vrefresh; /* in Hz */
- int hsync; /* in kHz */
+ /**
+ * @vrefresh:
+ *
+ * Vertical refresh rate, for debug output in human readable form. Not
+ * used in a functional way.
+ *
+ * This value is in Hz.
+ */
+ int vrefresh;
+
+ /**
+ * @hsync:
+ *
+ * Horizontal refresh rate, for debug output in human readable form. Not
+ * used in a functional way.
+ *
+ * This value is in kHz.
+ */
+ int hsync;
+
+ /**
+ * @picture_aspect_ratio:
+ *
+ * Filed for setting the HDMI picture aspect ratio of a mode.
+ */
enum hdmi_picture_aspect picture_aspect_ratio;
};
--
2.5.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 26/28] drm: Move drm_display_mode an related docs into kerneldoc
2015-12-04 8:46 ` [PATCH 26/28] drm: Move drm_display_mode an related docs into kerneldoc Daniel Vetter
@ 2015-12-07 13:39 ` Ville Syrjälä
2015-12-07 15:02 ` Thierry Reding
1 sibling, 0 replies; 81+ messages in thread
From: Ville Syrjälä @ 2015-12-07 13:39 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
On Fri, Dec 04, 2015 at 09:46:07AM +0100, Daniel Vetter wrote:
> This was in the documentation for modeset helper hooks, where it is a
> bit misplaced.
>
> v2: Reindent the drm_mode_status enum, inspired by Ville.
>
> Cc: ville.syrjala@linux.intel.com
> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
> ---
> Documentation/DocBook/gpu.tmpl | 192 -----------------------
> drivers/gpu/drm/drm_modes.c | 3 +-
> include/drm/drm_modes.h | 342 +++++++++++++++++++++++++++++++++++------
> 3 files changed, 297 insertions(+), 240 deletions(-)
>
> diff --git a/Documentation/DocBook/gpu.tmpl b/Documentation/DocBook/gpu.tmpl
> index 5312f5a05798..86e5b12a49ba 100644
> --- a/Documentation/DocBook/gpu.tmpl
> +++ b/Documentation/DocBook/gpu.tmpl
> @@ -1758,198 +1758,6 @@ void intel_crt_init(struct drm_device *dev)
> <function>drm_add_edid_modes</function> manually in that case.
> </para>
> <para>
> - When adding modes manually the driver creates each mode with a call to
> - <function>drm_mode_create</function> and must fill the following fields.
> - <itemizedlist>
> - <listitem>
> - <synopsis>__u32 type;</synopsis>
> - <para>
> - Mode type bitmask, a combination of
> - <variablelist>
> - <varlistentry>
> - <term>DRM_MODE_TYPE_BUILTIN</term>
> - <listitem><para>not used?</para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_TYPE_CLOCK_C</term>
> - <listitem><para>not used?</para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_TYPE_CRTC_C</term>
> - <listitem><para>not used?</para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>
> - DRM_MODE_TYPE_PREFERRED - The preferred mode for the connector
> - </term>
> - <listitem>
> - <para>not used?</para>
> - </listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_TYPE_DEFAULT</term>
> - <listitem><para>not used?</para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_TYPE_USERDEF</term>
> - <listitem><para>not used?</para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_TYPE_DRIVER</term>
> - <listitem>
> - <para>
> - The mode has been created by the driver (as opposed to
> - to user-created modes).
> - </para>
> - </listitem>
> - </varlistentry>
> - </variablelist>
> - Drivers must set the DRM_MODE_TYPE_DRIVER bit for all modes they
> - create, and set the DRM_MODE_TYPE_PREFERRED bit for the preferred
> - mode.
> - </para>
> - </listitem>
> - <listitem>
> - <synopsis>__u32 clock;</synopsis>
> - <para>Pixel clock frequency in kHz unit</para>
> - </listitem>
> - <listitem>
> - <synopsis>__u16 hdisplay, hsync_start, hsync_end, htotal;
> - __u16 vdisplay, vsync_start, vsync_end, vtotal;</synopsis>
> - <para>Horizontal and vertical timing information</para>
> - <screen><![CDATA[
> - Active Front Sync Back
> - Region Porch Porch
> - <-----------------------><----------------><-------------><-------------->
> -
> - //////////////////////|
> - ////////////////////// |
> - ////////////////////// |.................. ................
> - _______________
> -
> - <----- [hv]display ----->
> - <------------- [hv]sync_start ------------>
> - <--------------------- [hv]sync_end --------------------->
> - <-------------------------------- [hv]total ----------------------------->
> -]]></screen>
> - </listitem>
> - <listitem>
> - <synopsis>__u16 hskew;
> - __u16 vscan;</synopsis>
> - <para>Unknown</para>
> - </listitem>
> - <listitem>
> - <synopsis>__u32 flags;</synopsis>
> - <para>
> - Mode flags, a combination of
> - <variablelist>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_PHSYNC</term>
> - <listitem><para>
> - Horizontal sync is active high
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_NHSYNC</term>
> - <listitem><para>
> - Horizontal sync is active low
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_PVSYNC</term>
> - <listitem><para>
> - Vertical sync is active high
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_NVSYNC</term>
> - <listitem><para>
> - Vertical sync is active low
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_INTERLACE</term>
> - <listitem><para>
> - Mode is interlaced
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_DBLSCAN</term>
> - <listitem><para>
> - Mode uses doublescan
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_CSYNC</term>
> - <listitem><para>
> - Mode uses composite sync
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_PCSYNC</term>
> - <listitem><para>
> - Composite sync is active high
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_NCSYNC</term>
> - <listitem><para>
> - Composite sync is active low
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_HSKEW</term>
> - <listitem><para>
> - hskew provided (not used?)
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_BCAST</term>
> - <listitem><para>
> - not used?
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_PIXMUX</term>
> - <listitem><para>
> - not used?
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_DBLCLK</term>
> - <listitem><para>
> - not used?
> - </para></listitem>
> - </varlistentry>
> - <varlistentry>
> - <term>DRM_MODE_FLAG_CLKDIV2</term>
> - <listitem><para>
> - ?
> - </para></listitem>
> - </varlistentry>
> - </variablelist>
> - </para>
> - <para>
> - Note that modes marked with the INTERLACE or DBLSCAN flags will be
> - filtered out by
> - <function>drm_helper_probe_single_connector_modes</function> if
> - the connector's <structfield>interlace_allowed</structfield> or
> - <structfield>doublescan_allowed</structfield> field is set to 0.
> - </para>
> - </listitem>
> - <listitem>
> - <synopsis>char name[DRM_DISPLAY_MODE_LEN];</synopsis>
> - <para>
> - Mode name. The driver must call
> - <function>drm_mode_set_name</function> to fill the mode name from
> - <structfield>hdisplay</structfield>,
> - <structfield>vdisplay</structfield> and interlace flag after
> - filling the corresponding fields.
> - </para>
> - </listitem>
> - </itemizedlist>
> - </para>
> - <para>
> The <structfield>vrefresh</structfield> value is computed by
> <function>drm_helper_probe_single_connector_modes</function>.
> </para>
> diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
> index 5f79b9334a38..041138f5acc9 100644
> --- a/drivers/gpu/drm/drm_modes.c
> +++ b/drivers/gpu/drm/drm_modes.c
> @@ -708,7 +708,8 @@ void drm_mode_set_name(struct drm_display_mode *mode)
> }
> EXPORT_SYMBOL(drm_mode_set_name);
>
> -/** drm_mode_hsync - get the hsync of a mode
> +/**
> + * drm_mode_hsync - get the hsync of a mode
> * @mode: mode
> *
> * Returns:
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
> index f9115aee43f4..cd3c42256ab8 100644
> --- a/include/drm/drm_modes.h
> +++ b/include/drm/drm_modes.h
> @@ -35,46 +35,91 @@
> * structures).
> */
>
> +/**
> + * enum drm_mode_status - hardware support status of a mode
> + * @MODE_OK: Mode OK
> + * @MODE_HSYNC: hsync out of range
> + * @MODE_VSYNC: vsync out of range
> + * @MODE_H_ILLEGAL: mode has illegal horizontal timings
> + * @MODE_V_ILLEGAL: mode has illegal horizontal timings
> + * @MODE_BAD_WIDTH: requires an unsupported linepitch
> + * @MODE_NOMODE: no mode with a matching name
> + * @MODE_NO_INTERLACE: interlaced mode not supported
> + * @MODE_NO_DBLESCAN: doublescan mode not supported
> + * @MODE_NO_VSCAN: multiscan mode not supported
> + * @MODE_MEM: insufficient video memory
> + * @MODE_VIRTUAL_X: mode width too large for specified virtual size
> + * @MODE_VIRTUAL_Y: mode height too large for specified virtual size
> + * @MODE_MEM_VIRT: insufficient video memory given virtual size
> + * @MODE_NOCLOCK: no fixed clock available
> + * @MODE_CLOCK_HIGH: clock required is too high
> + * @MODE_CLOCK_LOW: clock required is too low
> + * @MODE_CLOCK_RANGE: clock/mode isn't in a ClockRange
> + * @MODE_BAD_HVALUE: horizontal timing was out of range
> + * @MODE_BAD_VVALUE: vertical timing was out of range
> + * @MODE_BAD_VSCAN: VScan value out of range
> + * @MODE_HSYNC_NARROW: horizontal sync too narrow
> + * @MODE_HSYNC_WIDE: horizontal sync too wide
> + * @MODE_HBLANK_NARROW: horizontal blanking too narrow
> + * @MODE_HBLANK_WIDE: horizontal blanking too wide
> + * @MODE_VSYNC_NARROW: vertical sync too narrow
> + * @MODE_VSYNC_WIDE: vertical sync too wide
> + * @MODE_VBLANK_NARROW: vertical blanking too narrow
> + * @MODE_VBLANK_WIDE: vertical blanking too wide
> + * @MODE_PANEL: exceeds panel dimensions
> + * @MODE_INTERLACE_WIDTH: width too large for interlaced mode
> + * @MODE_ONE_WIDTH: only one width is supported
> + * @MODE_ONE_HEIGHT: only one height is supported
> + * @MODE_ONE_SIZE: only one resolution is supported
> + * @MODE_NO_REDUCED: monitor doesn't accept reduced blanking
> + * @MODE_NO_STEREO: stereo modes not supported
> + * @MODE_UNVERIFIED: mode needs to reverified
> + * @MODE_BAD: unspecified reason
> + * @MODE_ERROR: error condition
> + *
> + * This enum is used to filter out modes not supported by the driver/hardware
> + * combination.
> + */
> enum drm_mode_status {
> - MODE_OK = 0, /* Mode OK */
> - MODE_HSYNC, /* hsync out of range */
> - MODE_VSYNC, /* vsync out of range */
> - MODE_H_ILLEGAL, /* mode has illegal horizontal timings */
> - MODE_V_ILLEGAL, /* mode has illegal horizontal timings */
> - MODE_BAD_WIDTH, /* requires an unsupported linepitch */
> - MODE_NOMODE, /* no mode with a matching name */
> - MODE_NO_INTERLACE, /* interlaced mode not supported */
> - MODE_NO_DBLESCAN, /* doublescan mode not supported */
> - MODE_NO_VSCAN, /* multiscan mode not supported */
> - MODE_MEM, /* insufficient video memory */
> - MODE_VIRTUAL_X, /* mode width too large for specified virtual size */
> - MODE_VIRTUAL_Y, /* mode height too large for specified virtual size */
> - MODE_MEM_VIRT, /* insufficient video memory given virtual size */
> - MODE_NOCLOCK, /* no fixed clock available */
> - MODE_CLOCK_HIGH, /* clock required is too high */
> - MODE_CLOCK_LOW, /* clock required is too low */
> - MODE_CLOCK_RANGE, /* clock/mode isn't in a ClockRange */
> - MODE_BAD_HVALUE, /* horizontal timing was out of range */
> - MODE_BAD_VVALUE, /* vertical timing was out of range */
> - MODE_BAD_VSCAN, /* VScan value out of range */
> - MODE_HSYNC_NARROW, /* horizontal sync too narrow */
> - MODE_HSYNC_WIDE, /* horizontal sync too wide */
> - MODE_HBLANK_NARROW, /* horizontal blanking too narrow */
> - MODE_HBLANK_WIDE, /* horizontal blanking too wide */
> - MODE_VSYNC_NARROW, /* vertical sync too narrow */
> - MODE_VSYNC_WIDE, /* vertical sync too wide */
> - MODE_VBLANK_NARROW, /* vertical blanking too narrow */
> - MODE_VBLANK_WIDE, /* vertical blanking too wide */
> - MODE_PANEL, /* exceeds panel dimensions */
> - MODE_INTERLACE_WIDTH, /* width too large for interlaced mode */
> - MODE_ONE_WIDTH, /* only one width is supported */
> - MODE_ONE_HEIGHT, /* only one height is supported */
> - MODE_ONE_SIZE, /* only one resolution is supported */
> - MODE_NO_REDUCED, /* monitor doesn't accept reduced blanking */
> - MODE_NO_STEREO, /* stereo modes not supported */
> - MODE_UNVERIFIED = -3, /* mode needs to reverified */
> - MODE_BAD = -2, /* unspecified reason */
> - MODE_ERROR = -1 /* error condition */
> + MODE_OK = 0,
^
Stray tab.
> + MODE_HSYNC,
> + MODE_VSYNC,
> + MODE_H_ILLEGAL,
> + MODE_V_ILLEGAL,
> + MODE_BAD_WIDTH,
> + MODE_NOMODE,
> + MODE_NO_INTERLACE,
> + MODE_NO_DBLESCAN,
> + MODE_NO_VSCAN,
> + MODE_MEM,
> + MODE_VIRTUAL_X,
> + MODE_VIRTUAL_Y,
> + MODE_MEM_VIRT,
> + MODE_NOCLOCK,
> + MODE_CLOCK_HIGH,
> + MODE_CLOCK_LOW,
> + MODE_CLOCK_RANGE,
> + MODE_BAD_HVALUE,
> + MODE_BAD_VVALUE,
> + MODE_BAD_VSCAN,
> + MODE_HSYNC_NARROW,
> + MODE_HSYNC_WIDE,
> + MODE_HBLANK_NARROW,
> + MODE_HBLANK_WIDE,
> + MODE_VSYNC_NARROW,
> + MODE_VSYNC_WIDE,
> + MODE_VBLANK_NARROW,
> + MODE_VBLANK_WIDE,
> + MODE_PANEL,
> + MODE_INTERLACE_WIDTH,
> + MODE_ONE_WIDTH,
> + MODE_ONE_HEIGHT,
> + MODE_ONE_SIZE,
> + MODE_NO_REDUCED,
> + MODE_NO_STEREO,
> + MODE_UNVERIFIED = -3,
> + MODE_BAD = -2,
> + MODE_ERROR = -1
^
and here too
> };
>
> #define DRM_MODE_TYPE_CLOCK_CRTC_C (DRM_MODE_TYPE_CLOCK_C | \
> @@ -96,17 +141,124 @@ enum drm_mode_status {
>
> #define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
>
> +/**
> + * struct drm_display_mode - DRM kernel-internal display mode structure
> + * @hdisplay: horizontal display size
> + * @hsync_start: horizontal sync start
> + * @hsync_end: horizontal sync end
> + * @htotal: horizontal total size
> + * @hskew: horizontal skew?!
> + * @vdisplay: vertical display size
> + * @vsync_start: vertical sync start
> + * @vsync_end: vertical sync end
> + * @vtotal: vertical total size
> + * @vscan: vertical scan?!
> + * @crtc_hdisplay: hardware modehorizontal display size
> + * @crtc_hsync_start: hardware modehorizontal sync start
> + * @crtc_hsync_end: hardware modehorizontal sync end
> + * @crtc_htotal: hardware modehorizontal total size
> + * @crtc_hskew: hardware modehorizontal skew?!
> + * @crtc_vdisplay: hardware modevertical display size
> + * @crtc_vsync_start: hardware modevertical sync start
> + * @crtc_vsync_end: hardware modevertical sync end
> + * @crtc_vtotal: hardware modevertical total size
> + * @crtc_vscan: hardware modevertical scan?!
> + *
> + * The horizontal an vertical timings are defined per the following diagram:
> + *
> + *
> + * Active Front Sync Back
> + * Region Porch Porch
> + * <-----------------------><----------------><-------------><-------------->
> + *
> + * //////////////////////|
> + * ////////////////////// |
> + * ////////////////////// |.................. ................
> + * _______________
> + *
> + * <----- [hv]display ----->
> + * <------------- [hv]sync_start ------------>
> + * <--------------------- [hv]sync_end --------------------->
> + * <-------------------------------- [hv]total ----------------------------->*
> + *
> + * This structure contains two copies of timings. First are the plain timings,
> + * which specify the logical mode, as it would be for a progressive 1:1 scanout
> + * at the refresh rate userspace can observe through vblank timestamps. Then
> + * there's the hardware timings, which are corrected for interlacing,
> + * double-clocking and similar things. They are provided as a convience, and can
> + * be appropriately computed using drm_mode_set_crtcinfo().
> + */
> struct drm_display_mode {
> - /* Header */
> + /**
> + * @head:
> + *
> + * struct list_head for mode lists.
> + */
> struct list_head head;
> +
> + /**
> + * @base:
> + *
> + * A display mode is a normal modeset object, possibly including public
> + * userspace id.
> + *
> + * FIXME:
> + *
> + * This can probably be removed since the entire concept of userspace
> + * managing modes explicitly hasn't ever landed in upstream kernel mode
> + * setting support.
> + */
> struct drm_mode_object base;
>
> + /**
> + * @name:
> + *
> + * Human-readable name of the mode, filled out with drm_mode_set_name().
> + */
> char name[DRM_DISPLAY_MODE_LEN];
>
> + /**
> + * @status:
> + *
> + * Status of the mode, used to filter out modes not supported by the
> + * hardware. See enum &drm_mode_status.
> + */
> enum drm_mode_status status;
> +
> + /**
> + * @type:
> + *
> + * A bitmask of flags, mostly about the source of a mode. Possible flags
> + * are:
> + *
> + * - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, effectively
> + * unused.
> + * - DRM_MODE_TYPE_PREFERRED: Preferred mode, usually the native
> + * resolution of an LCD panel. There should only be one preferred
> + * mode per connector at any given time.
> + * - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
> + * them really. Drivers must set this bit for all modes they create
> + * and expose to userspace.
> + *
> + * Plus a big list of flags which shouldn't be used at all, but are
> + * still around since these flags are also used in the userspace ABI:
> + *
> + * - DRM_MODE_TYPE_DEFAULT: Again a leftover, use
> + * DRM_MODE_TYPE_PREFERRED instead.
> + * - DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
> + * which are stuck around for hysterical raisins only. No one has an
> + * idea what they where meant for. Don't use.
> + * - DRM_MODE_TYPE_USERDEF: Mode defined by userspace, again a vestige
> + * from older kms designs where userspace had to first add a custom
> + * mode to the kernel's mode list before it could use it. Don't use.
> + */
> unsigned int type;
>
> - /* Proposed mode values */
> + /**
> + * @clock:
> + *
> + * Pixel clock in kHz.
> + */
> int clock; /* in kHz */
> int hdisplay;
> int hsync_start;
> @@ -118,14 +270,74 @@ struct drm_display_mode {
> int vsync_end;
> int vtotal;
> int vscan;
> + /**
> + * @flags:
> + *
> + * Sync and timing flags:
> + *
> + * - DRM_MODE_FLAG_PHSYNC: horizontal sync is active high.
> + * - DRM_MODE_FLAG_NHSYNC: horizontal sync is active low.
> + * - DRM_MODE_FLAG_PVSYNC: vertical sync is active high.
> + * - DRM_MODE_FLAG_NVSYNC: vertical sync is active low.
> + * - DRM_MODE_FLAG_INTERLACE: mode is interlaced.
> + * - DRM_MODE_FLAG_DBLSCAN: mode uses doublescan.
> + * - DRM_MODE_FLAG_CSYNC: mode uses composite sync.
> + * - DRM_MODE_FLAG_PCSYNC: composite sync is active high.
> + * - DRM_MODE_FLAG_NCSYNC: composite sync is active low.
> + * - DRM_MODE_FLAG_HSKEW: hskew provided (not used?).
> + * - DRM_MODE_FLAG_BCAST: not used?
> + * - DRM_MODE_FLAG_PIXMUX: not used?
> + * - DRM_MODE_FLAG_DBLCLK: double-clocked mode.
> + * - DRM_MODE_FLAG_CLKDIV2: half-clocked mode.
Random rant: How I wish we didn't have have bunch of these flags.
No real reason why userspace should have to know how the pixels
get clocked out etc. But can't change that now.
> + *
> + * Additionally there's flags to specify how 3D modes are packed:
> + *
> + * - DRM_MODE_FLAG_3D_NONE: normal, non-3D mode.
> + * - DRM_MODE_FLAG_3D_FRAME_PACKING: 2 full frames for left and right.
> + * - DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE: interleaved like fields.
> + * - DRM_MODE_FLAG_3D_LINE_ALTERNATIVE: interleaved lines.
> + * - DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL: side-by-side full frames.
> + * - DRM_MODE_FLAG_3D_L_DEPTH: ?
> + * - DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH: ?
> + * - DRM_MODE_FLAG_3D_TOP_AND_BOTTOM: frame split into top and bottom
> + * parts.
> + * - DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF: frame split into left and
> + * right parts.
I think these either need a proper explanation (ie. some diagrams probably),
or we just add a spec reference here. Can be done later once we figure
out which way we want to go.
Anyway, patch looks mostly OK, so
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
> + */
> unsigned int flags;
>
> - /* Addressable image size (may be 0 for projectors, etc.) */
> + /**
> + * @width_mm:
> + *
> + * Addressable size of the output in mm, projectors should set this to
> + * 0.
> + */
> int width_mm;
> +
> + /**
> + * @height_mm:
> + *
> + * Addressable size of the output in mm, projectors should set this to
> + * 0.
> + */
> int height_mm;
>
> - /* Actual mode we give to hw */
> - int crtc_clock; /* in KHz */
> + /**
> + * @crtc_clock:
> + *
> + * Actual pixel or dot clock in the hardware. This differs from the
> + * logical @clock when e.g. using interlacing, double-clocking, stereo
> + * modes or other fancy stuff that changes the timings and signals
> + * actually sent over the wire.
> + *
> + * This is again in kHz.
> + *
> + * Note that with digital outputs like HDMI or DP there's usually a
> + * massive confusion between the dot clock and the signal clock at the
> + * bit encoding level. Especially when a 8b/10b encoding is used and the
> + * differences is exactly a factor of 10.
> + */
> + int crtc_clock;
> int crtc_hdisplay;
> int crtc_hblank_start;
> int crtc_hblank_end;
> @@ -140,12 +352,48 @@ struct drm_display_mode {
> int crtc_vsync_end;
> int crtc_vtotal;
>
> - /* Driver private mode info */
> + /**
> + * @private:
> + *
> + * Pointer for driver private data. This can only be used for mode
> + * objects passed to drivers in modeset operations. It shouldn't be used
> + * by atomic drivers since they can store any additional data by
> + * subclassing state structures.
> + */
> int *private;
> +
> + /**
> + * @private_flags:
> + *
> + * Similar to @private, but just an integer.
> + */
> int private_flags;
>
> - int vrefresh; /* in Hz */
> - int hsync; /* in kHz */
> + /**
> + * @vrefresh:
> + *
> + * Vertical refresh rate, for debug output in human readable form. Not
> + * used in a functional way.
> + *
> + * This value is in Hz.
> + */
> + int vrefresh;
> +
> + /**
> + * @hsync:
> + *
> + * Horizontal refresh rate, for debug output in human readable form. Not
> + * used in a functional way.
> + *
> + * This value is in kHz.
> + */
> + int hsync;
> +
> + /**
> + * @picture_aspect_ratio:
> + *
> + * Filed for setting the HDMI picture aspect ratio of a mode.
> + */
> enum hdmi_picture_aspect picture_aspect_ratio;
> };
>
> --
> 2.5.1
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 26/28] drm: Move drm_display_mode an related docs into kerneldoc
2015-12-04 8:46 ` [PATCH 26/28] drm: Move drm_display_mode an related docs into kerneldoc Daniel Vetter
2015-12-07 13:39 ` Ville Syrjälä
@ 2015-12-07 15:02 ` Thierry Reding
2015-12-07 15:33 ` Daniel Vetter
1 sibling, 1 reply; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 15:02 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Daniel Vetter, Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 8095 bytes --]
On Fri, Dec 04, 2015 at 09:46:07AM +0100, Daniel Vetter wrote:
[...]
> diff --git a/include/drm/drm_modes.h b/include/drm/drm_modes.h
[...]
> @@ -96,17 +141,124 @@ enum drm_mode_status {
>
> #define DRM_MODE_FLAG_3D_MAX DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF
>
> +/**
> + * struct drm_display_mode - DRM kernel-internal display mode structure
[...]
> + * @crtc_hdisplay: hardware modehorizontal display size
> + * @crtc_hsync_start: hardware modehorizontal sync start
> + * @crtc_hsync_end: hardware modehorizontal sync end
> + * @crtc_htotal: hardware modehorizontal total size
> + * @crtc_hskew: hardware modehorizontal skew?!
> + * @crtc_vdisplay: hardware modevertical display size
> + * @crtc_vsync_start: hardware modevertical sync start
> + * @crtc_vsync_end: hardware modevertical sync end
> + * @crtc_vtotal: hardware modevertical total size
> + * @crtc_vscan: hardware modevertical scan?!
These are missing a space between "mode" and the description.
> + *
> + * The horizontal an vertical timings are defined per the following diagram:
> + *
> + *
> + * Active Front Sync Back
> + * Region Porch Porch
> + * <-----------------------><----------------><-------------><-------------->
> + *
> + * //////////////////////|
> + * ////////////////////// |
> + * ////////////////////// |.................. ................
> + * _______________
> + *
> + * <----- [hv]display ----->
> + * <------------- [hv]sync_start ------------>
> + * <--------------------- [hv]sync_end --------------------->
> + * <-------------------------------- [hv]total ----------------------------->*
> + *
> + * This structure contains two copies of timings. First are the plain timings,
> + * which specify the logical mode, as it would be for a progressive 1:1 scanout
> + * at the refresh rate userspace can observe through vblank timestamps. Then
> + * there's the hardware timings, which are corrected for interlacing,
> + * double-clocking and similar things. They are provided as a convience, and can
"convenience"
> + * be appropriately computed using drm_mode_set_crtcinfo().
> + */
> struct drm_display_mode {
> - /* Header */
> + /**
> + * @head:
> + *
> + * struct list_head for mode lists.
> + */
> struct list_head head;
> +
> + /**
> + * @base:
> + *
> + * A display mode is a normal modeset object, possibly including public
> + * userspace id.
> + *
> + * FIXME:
> + *
> + * This can probably be removed since the entire concept of userspace
> + * managing modes explicitly hasn't ever landed in upstream kernel mode
"has never"
> + * setting support.
> + */
> struct drm_mode_object base;
>
> + /**
> + * @name:
> + *
> + * Human-readable name of the mode, filled out with drm_mode_set_name().
> + */
> char name[DRM_DISPLAY_MODE_LEN];
>
> + /**
> + * @status:
> + *
> + * Status of the mode, used to filter out modes not supported by the
> + * hardware. See enum &drm_mode_status.
> + */
> enum drm_mode_status status;
> +
> + /**
> + * @type:
> + *
> + * A bitmask of flags, mostly about the source of a mode. Possible flags
> + * are:
> + *
> + * - DRM_MODE_TYPE_BUILTIN: Meant for hard-coded modes, effectively
> + * unused.
> + * - DRM_MODE_TYPE_PREFERRED: Preferred mode, usually the native
> + * resolution of an LCD panel. There should only be one preferred
> + * mode per connector at any given time.
> + * - DRM_MODE_TYPE_DRIVER: Mode created by the driver, which is all of
> + * them really. Drivers must set this bit for all modes they create
> + * and expose to userspace.
> + *
> + * Plus a big list of flags which shouldn't be used at all, but are
> + * still around since these flags are also used in the userspace ABI:
> + *
> + * - DRM_MODE_TYPE_DEFAULT: Again a leftover, use
> + * DRM_MODE_TYPE_PREFERRED instead.
> + * - DRM_MODE_TYPE_CLOCK_C and DRM_MODE_TYPE_CRTC_C: Define leftovers
> + * which are stuck around for hysterical raisins only. No one has an
> + * idea what they where meant for. Don't use.
"were"
> + * - DRM_MODE_TYPE_USERDEF: Mode defined by userspace, again a vestige
> + * from older kms designs where userspace had to first add a custom
> + * mode to the kernel's mode list before it could use it. Don't use.
> + */
> unsigned int type;
>
> - /* Proposed mode values */
> + /**
> + * @clock:
> + *
> + * Pixel clock in kHz.
> + */
> int clock; /* in kHz */
> int hdisplay;
> int hsync_start;
> @@ -118,14 +270,74 @@ struct drm_display_mode {
> int vsync_end;
> int vtotal;
> int vscan;
I'm thinking that these could all use "unsigned", but that's definitely
something for a separate patch.
> + /**
> + * @flags:
> + *
> + * Sync and timing flags:
> + *
> + * - DRM_MODE_FLAG_PHSYNC: horizontal sync is active high.
> + * - DRM_MODE_FLAG_NHSYNC: horizontal sync is active low.
> + * - DRM_MODE_FLAG_PVSYNC: vertical sync is active high.
> + * - DRM_MODE_FLAG_NVSYNC: vertical sync is active low.
> + * - DRM_MODE_FLAG_INTERLACE: mode is interlaced.
> + * - DRM_MODE_FLAG_DBLSCAN: mode uses doublescan.
> + * - DRM_MODE_FLAG_CSYNC: mode uses composite sync.
> + * - DRM_MODE_FLAG_PCSYNC: composite sync is active high.
> + * - DRM_MODE_FLAG_NCSYNC: composite sync is active low.
> + * - DRM_MODE_FLAG_HSKEW: hskew provided (not used?).
> + * - DRM_MODE_FLAG_BCAST: not used?
> + * - DRM_MODE_FLAG_PIXMUX: not used?
> + * - DRM_MODE_FLAG_DBLCLK: double-clocked mode.
> + * - DRM_MODE_FLAG_CLKDIV2: half-clocked mode.
> + *
> + * Additionally there's flags to specify how 3D modes are packed:
> + *
> + * - DRM_MODE_FLAG_3D_NONE: normal, non-3D mode.
> + * - DRM_MODE_FLAG_3D_FRAME_PACKING: 2 full frames for left and right.
> + * - DRM_MODE_FLAG_3D_FIELD_ALTERNATIVE: interleaved like fields.
> + * - DRM_MODE_FLAG_3D_LINE_ALTERNATIVE: interleaved lines.
> + * - DRM_MODE_FLAG_3D_SIDE_BY_SIDE_FULL: side-by-side full frames.
> + * - DRM_MODE_FLAG_3D_L_DEPTH: ?
^
Stray tab.
> + * Note that with digital outputs like HDMI or DP there's usually a
> + * massive confusion between the dot clock and the signal clock at the
> + * bit encoding level. Especially when a 8b/10b encoding is used and the
> + * differences is exactly a factor of 10.
"difference"
> + */
> + int crtc_clock;
> int crtc_hdisplay;
> int crtc_hblank_start;
> int crtc_hblank_end;
> @@ -140,12 +352,48 @@ struct drm_display_mode {
> int crtc_vsync_end;
> int crtc_vtotal;
>
> - /* Driver private mode info */
> + /**
> + * @private:
> + *
> + * Pointer for driver private data. This can only be used for mode
> + * objects passed to drivers in modeset operations. It shouldn't be used
> + * by atomic drivers since they can store any additional data by
> + * subclassing state structures.
> + */
> int *private;
Off-topic: Any reasons why this is int * and not void *?
> +
> + /**
> + * @private_flags:
> + *
> + * Similar to @private, but just an integer.
> + */
> int private_flags;
>
> - int vrefresh; /* in Hz */
> - int hsync; /* in kHz */
> + /**
> + * @vrefresh:
> + *
> + * Vertical refresh rate, for debug output in human readable form. Not
> + * used in a functional way.
> + *
> + * This value is in Hz.
> + */
> + int vrefresh;
> +
> + /**
> + * @hsync:
> + *
> + * Horizontal refresh rate, for debug output in human readable form. Not
> + * used in a functional way.
> + *
> + * This value is in kHz.
> + */
> + int hsync;
> +
> + /**
> + * @picture_aspect_ratio:
> + *
> + * Filed for setting the HDMI picture aspect ratio of a mode.
"Field".
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 26/28] drm: Move drm_display_mode an related docs into kerneldoc
2015-12-07 15:02 ` Thierry Reding
@ 2015-12-07 15:33 ` Daniel Vetter
0 siblings, 0 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-07 15:33 UTC (permalink / raw)
To: Thierry Reding
Cc: Daniel Vetter, Intel Graphics Development, DRI Development,
Daniel Vetter
On Mon, Dec 07, 2015 at 04:02:38PM +0100, Thierry Reding wrote:
> On Fri, Dec 04, 2015 at 09:46:07AM +0100, Daniel Vetter wrote:
> > @@ -140,12 +352,48 @@ struct drm_display_mode {
> > int crtc_vsync_end;
> > int crtc_vtotal;
> >
> > - /* Driver private mode info */
> > + /**
> > + * @private:
> > + *
> > + * Pointer for driver private data. This can only be used for mode
> > + * objects passed to drivers in modeset operations. It shouldn't be used
> > + * by atomic drivers since they can store any additional data by
> > + * subclassing state structures.
> > + */
> > int *private;
>
> Off-topic: Any reasons why this is int * and not void *?
Was added like that years ago. Iirc no one ever used this at all, so maybe
we should just nuke it. With atomic state structures we have a much better
solution now.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 27/28] drm: Document drm_encoder/crtc_helper_funcs
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (25 preceding siblings ...)
2015-12-04 8:46 ` [PATCH 26/28] drm: Move drm_display_mode an related docs into kerneldoc Daniel Vetter
@ 2015-12-04 8:46 ` Daniel Vetter
2015-12-07 15:21 ` Thierry Reding
2015-12-04 8:46 ` [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe Daniel Vetter
27 siblings, 1 reply; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:46 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development
Mostly this is about all the callbacks used to modesets by both legacy
CRTC helpers and atomic helpers and I figured it doesn't make all that
much sense to split this up.
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
include/drm/drm_modeset_helper_vtables.h | 447 +++++++++++++++++++++++++++----
1 file changed, 400 insertions(+), 47 deletions(-)
diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
index 22cc51b278fb..d776ef6dd00e 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -46,58 +46,236 @@ enum mode_set_atomic;
/**
* struct drm_crtc_helper_funcs - helper operations for CRTCs
- * @dpms: set power state
- * @prepare: prepare the CRTC, called before @mode_set
- * @commit: commit changes to CRTC, called after @mode_set
- * @mode_fixup: try to fixup proposed mode for this CRTC
- * @mode_set: set this mode
- * @mode_set_nofb: set mode only (no scanout buffer attached)
- * @mode_set_base: update the scanout buffer
- * @mode_set_base_atomic: non-blocking mode set (used for kgdb support)
- * @load_lut: load color palette
- * @disable: disable CRTC when no longer in use
- * @enable: enable CRTC
*
- * The helper operations are called by the mid-layer CRTC helper.
- *
- * Note that with atomic helpers @dpms, @prepare and @commit hooks are
- * deprecated. Used @enable and @disable instead exclusively.
- *
- * With legacy crtc helpers there's a big semantic difference between @disable
- * and the other hooks: @disable also needs to release any resources acquired in
- * @mode_set (like shared PLLs).
+ * These hooks are used by the legacy CRTC helpers, the transitional plane
+ * helpers and the new atomic modesetting helpers.
*/
struct drm_crtc_helper_funcs {
- /*
- * Control power levels on the CRTC. If the mode passed in is
- * unsupported, the provider must use the next lowest power level.
+ /**
+ * @dpms:
+ *
+ * Callback to control power levels on the CRTC. If the mode passed in
+ * is unsupported, the provider must use the next lowest power level.
+ * This is used by the legacy CRTC helpers to implement DPMS
+ * functionality in drm_helper_connector_dpms().
+ *
+ * This callback is also used to disable a CRTC by calling it with
+ * DRM_MODE_DPMS_OFF if the @disable hook isn't used.
+ *
+ * This callback is used by the legacy CRTC helpers. Atomic helpers
+ * also support using this hook for enabling and disabling a CRTC to
+ * facilitate transitions to atomic, but it is deprecated. Instead
+ * @enable and @disable should be used.
*/
void (*dpms)(struct drm_crtc *crtc, int mode);
+
+ /**
+ * @prepare:
+ *
+ * This callback should prepare the CRTC for a subsequent modeset, which
+ * in practice means the driver should disable the CRTC if it is
+ * running. Most drivers ended up implementing this by calling their
+ * @dpms hook with DRM_MODE_DPMS_OFF.
+ *
+ * This callback is used by the legacy CRTC helpers. Atomic helpers
+ * also support using this hook for disabling a CRTC to facilitate
+ * transitions to atomic, but it is deprecated. Instead @disable should
+ * be used.
+ */
void (*prepare)(struct drm_crtc *crtc);
+
+ /**
+ * @commit:
+ *
+ * This callback should commit the new mode on the CRTC after a modeset,
+ * which in practice means the driver should enable the CRTC. Most
+ * drivers ended up implementing this by calling their @dpms hook with
+ * DRM_MODE_DPMS_ON.
+ *
+ * This callback is used by the legacy CRTC helpers. Atomic helpers
+ * also support using this hook for enabling a CRTC to facilitate
+ * transitions to atomic, but it is deprecated. Instead @enable should
+ * be used.
+ */
void (*commit)(struct drm_crtc *crtc);
- /* Provider can fixup or change mode timings before modeset occurs */
+ /**
+ * @mode_fixup:
+ *
+ * This callback is used to validate a mode. The paramater mode is the
+ * display mode that userspace requested, adjusted_mode is the mode the
+ * encoders need to be fed with. Note that this is the inverse semantics
+ * of the meaning for the &drm_encoder and &drm_bridge
+ * ->mode_fixup() functions. If the CRTC cannot support the requested
+ * conversion from mode to adjusted_mode it should reject the modeset.
+ *
+ * This function is used by both legacy CRTC helpers and atomic helpers.
+ * With atomic helpers it is optional.
+ *
+ * NOTE:
+ *
+ * This function is called in the check phase of atomic modesets, which
+ * can be aborted for any reason (including on userspace's request to
+ * just check whether a configuration would be possible). Atomic drivers
+ * MUST NOT touch any persistent state (hardware or software) or data
+ * structures except the passed in adjusted_mode parameter.
+ *
+ * This is in contrast to the legacy CRTC helpers where this was
+ * allowed.
+ *
+ * Atomic drivers which need to inspect and adjust more state should
+ * instead use the @atomic_check callback.
+ *
+ * RETURNS:
+ *
+ * True if an acceptable configuration is possible, false if the modeset
+ * operation should be rejected.
+ */
bool (*mode_fixup)(struct drm_crtc *crtc,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
- /* Actually set the mode */
+
+ /**
+ * @mode_set:
+ *
+ * This callback is used by the legacy CRTC helpers to set a new mode,
+ * position and framebuffer. Since it ties the primary plane to every
+ * mode change it is incompatible with universal plane support. And
+ * since it can't update other planes it's incompatible with atomic
+ * modeset support.
+ *
+ * This callback is only used by CRTC helpers and deprecated.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*mode_set)(struct drm_crtc *crtc, struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode, int x, int y,
struct drm_framebuffer *old_fb);
- /* Actually set the mode for atomic helpers, optional */
+
+ /**
+ * @mode_set_nofb:
+ *
+ * This callback is used to update the display mode of a CRTC without
+ * changing anything of the primary plane configuration. This fits the
+ * requirement of atomic and hence is used by the atomic helpers. It is
+ * also used by the transitional plane helpers to implement a
+ * @mode_set hook in drm_helper_crtc_mode_set().
+ *
+ * Note that the display pipe is completely off when this function is
+ * called. Atomic drivers which need hardware to be running before they
+ * program the new display mode (e.g. because they implement runtime PM)
+ * should not use this hook. This is because the helper library calls
+ * this hook only once per mode change and not every time the display
+ * pipeline is suspended using either DPMS or the new "ACTIVE" property.
+ * Which means register values set in this callback might get reset when
+ * the CRTC is suspended, but not restored. Such drivers should instead
+ * move all their CRTC setup into the @enable callback.
+ *
+ * This callback is optional.
+ */
void (*mode_set_nofb)(struct drm_crtc *crtc);
- /* Move the crtc on the current fb to the given position *optional* */
+ /**
+ * @mode_set_base:
+ *
+ * This callback is used by the legacy CRTC helpers to set a new
+ * framebuffer and scanout position. It is optional and used as an
+ * optimized fast-path instead of a full mode set operation with all the
+ * resulting flickering. Since it can't update other planes it's
+ * incompatible with atomic modeset support.
+ *
+ * This callback is only used by the CRTC helpers and deprecated.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*mode_set_base)(struct drm_crtc *crtc, int x, int y,
struct drm_framebuffer *old_fb);
+
+ /**
+ * @mode_set_base_atomic:
+ *
+ * This callback is used by the fbdev helpers to set a new framebuffer
+ * and scanout without sleeping, i.e. from an atomic calling context. It
+ * is only used to implement kgdb support.
+ *
+ * This callback is optional and only needed for kgdb support in the fbdev
+ * helpers.
+ *
+ * RETURNS:
+ *
+ * 0 on success or a negative error code on failure.
+ */
int (*mode_set_base_atomic)(struct drm_crtc *crtc,
struct drm_framebuffer *fb, int x, int y,
enum mode_set_atomic);
- /* reload the current crtc LUT */
+ /**
+ * @load_lut:
+ *
+ * Load a LUT prepared with the @gamma_set functions from
+ * &drm_fb_helper_funcs.
+ *
+ * This callback is optional and is only used by the fbdev emulation
+ * helpers.
+ *
+ * FIXME:
+ *
+ * This callback is functionally redundant with the core gamma table
+ * support and simply exists because the fbdev hasn't yet been
+ * refactored to use the core gamma table interfaces.
+ */
void (*load_lut)(struct drm_crtc *crtc);
+ /**
+ * @disable:
+ *
+ * This callback should be used to disable the CRTC. With the atomic
+ * drivers it is called after all encoders connected to this CRTC have
+ * been shut off already using their own ->disable hook. If that
+ * sequence is too simple drivers can just add their own hooks and call
+ * it from this CRTC callback here by looping over all encoders
+ * connected to it using for_each_encoder_on_crtc().
+ *
+ * This hook is used both by legacy CRTC helpers and atomic helpers.
+ * Atomic drivers don't need to implement it if there's no need to
+ * disable anything at the CRTC level. To ensure that runtime PM
+ * handling (using either DPMS or the new "ACTIVE" property) works
+ * @disable must be the inversve of @enable for atomic drivers.
+ *
+ * NOTE:
+ *
+ * With legacy CRTC helpers there's a big semantic difference between
+ * @disable other hooks (like @prepare or @dpms) used to shut down a
+ * CRTC: @disable is only called when also logically disabling the
+ * display pipeline and needs to release any resources acquired in
+ * @mode_set (like shared PLLs, or again release pinned framebuffers).
+ *
+ * Therefore @disable must be the inverse of @mode_set plus @commit for
+ * drivers still using legacy CRTC helpers, which is different from the
+ * rules under atomic.
+ */
void (*disable)(struct drm_crtc *crtc);
+
+ /**
+ * @enable:
+ *
+ * This callback should be used to enable the CRTC. With the atomic
+ * drivers it is called before all encoders connected to this CRTC are
+ * enabled through the encoder's own ->enable hook. If that sequence is
+ * too simple drivers can just add their own hooks and call it from this
+ * CRTC callback here by looping over all encoders connected to it using
+ * for_each_encoder_on_crtc().
+ *
+ * This hook is used only by atomic helpers, for symmetry with @disable.
+ * Atomic drivers don't need to implement it if there's no need to
+ * enable anything at the CRTC level. To ensure that runtime PM handling
+ * (using either DPMS or the new "ACTIVE" property) works
+ * @enable must be the inversve of @disable for atomic drivers.
+ */
void (*enable)(struct drm_crtc *crtc);
/**
@@ -206,46 +384,221 @@ static inline void drm_crtc_helper_add(struct drm_crtc *crtc,
/**
* struct drm_encoder_helper_funcs - helper operations for encoders
- * @dpms: set power state
- * @mode_fixup: try to fixup proposed mode for this connector
- * @prepare: part of the disable sequence, called before the CRTC modeset
- * @commit: called after the CRTC modeset
- * @mode_set: set this mode, optional for atomic helpers
- * @get_crtc: return CRTC that the encoder is currently attached to
- * @detect: connection status detection
- * @disable: disable encoder when not in use (overrides DPMS off)
- * @enable: enable encoder
- * @atomic_check: check for validity of an atomic update
- *
- * The helper operations are called by the mid-layer CRTC helper.
*
- * Note that with atomic helpers @dpms, @prepare and @commit hooks are
- * deprecated. Used @enable and @disable instead exclusively.
- *
- * With legacy crtc helpers there's a big semantic difference between @disable
- * and the other hooks: @disable also needs to release any resources acquired in
- * @mode_set (like shared PLLs).
+ * These hooks are used by the legacy CRTC helpers, the transitional plane
+ * helpers and the new atomic modesetting helpers.
*/
struct drm_encoder_helper_funcs {
+ /**
+ * @dpms:
+ *
+ * Callback to control power levels on the encoder. If the mode passed in
+ * is unsupported, the provider must use the next lowest power level.
+ * This is used by the legacy encoder helpers to implement DPMS
+ * functionality in drm_helper_connector_dpms().
+ *
+ * This callback is also used to disable a encoder by calling it with
+ * DRM_MODE_DPMS_OFF if the @disable hook isn't used.
+ *
+ * This callback is used by the legacy CRTC helpers. Atomic helpers
+ * also support using this hook for enabling and disabling a encoder to
+ * facilitate transitions to atomic, but it is deprecated. Instead
+ * @enable and @disable should be used.
+ */
void (*dpms)(struct drm_encoder *encoder, int mode);
+ /**
+ * @mode_fixup:
+ *
+ * This callback is used to validate and adjust a mode. The paramater
+ * mode is the display mode that should be fed to the next element in
+ * the display chain, either the final &drm_connector or a &drm_bridge.
+ * The parameter adjusted_mode is the input mode the encoder requires. It
+ * can be modified by this callback and does not need to match mode.
+ *
+ * This function is used by both legacy CRTC helpers and atomic helpers.
+ * With atomic helpers it is optional.
+ *
+ * NOTE:
+ *
+ * This function is called in the check phase of atomic modesets, which
+ * can be aborted for any reason (including on userspace's request to
+ * just check whether a configuration would be possible). Atomic drivers
+ * MUST NOT touch any persistent state (hardware or software) or data
+ * structures except the passed in adjusted_mode parameter.
+ *
+ * This is in contrast to the legacy CRTC helpers where this was
+ * allowed.
+ *
+ * Atomic drivers which need to inspect and adjust more state should
+ * instead use the @atomic_check callback.
+ *
+ * RETURNS:
+ *
+ * True if an acceptable configuration is possible, false if the modeset
+ * operation should be rejected.
+ */
bool (*mode_fixup)(struct drm_encoder *encoder,
const struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+
+ /**
+ * @prepare:
+ *
+ * This callback should prepare the encoder for a subsequent modeset,
+ * which in practice means the driver should disable the encoder if it
+ * is running. Most drivers ended up implementing this by calling their
+ * @dpms hook with DRM_MODE_DPMS_OFF.
+ *
+ * This callback is used by the legacy CRTC helpers. Atomic helpers
+ * also support using this hook for disabling a encoder to facilitate
+ * transitions to atomic, but it is deprecated. Instead @disable should
+ * be used.
+ */
void (*prepare)(struct drm_encoder *encoder);
+
+ /**
+ * @commit:
+ *
+ * This callback should commit the new mode on the encoder after a modeset,
+ * which in practice means the driver should enable the encoder. Most
+ * drivers ended up implementing this by calling their @dpms hook with
+ * DRM_MODE_DPMS_ON.
+ *
+ * This callback is used by the legacy CRTC helpers. Atomic helpers
+ * also support using this hook for enabling a encoder to facilitate
+ * transitions to atomic, but it is deprecated. Instead @enable should
+ * be used.
+ */
void (*commit)(struct drm_encoder *encoder);
+
+ /**
+ * @mode_set:
+ *
+ * This callback is used to update the display mode of an encoder.
+ *
+ * Note that the display pipe is completely off when this function is
+ * called. Drivers which need hardware to be running before they program
+ * the new display mode (because they implement runtime PM) should not
+ * use this hook, because the helper library calls it only once and not
+ * every time the display pipeline is suspend using either DPMS or the
+ * new "ACTIVE" property. Such drivers should instead move all their
+ * encoder setup into the ->enable() callback.
+ *
+ * This callback is used both by the legacy CRTC helpers and the atomic
+ * modeset helpers. It is optional in the atomic helpers.
+ */
void (*mode_set)(struct drm_encoder *encoder,
struct drm_display_mode *mode,
struct drm_display_mode *adjusted_mode);
+
+ /**
+ * @get_crtc:
+ *
+ * This callback is used by the legacy CRTC helpers to work around
+ * deficiencies in its own book-keeping.
+ *
+ * Do not use, use atomic helpers instead, which get the book keeping
+ * right.
+ *
+ * FIXME:
+ *
+ * Currently only nouveau is using this, and as soon as nouveau is
+ * atomic we can ditch this hook.
+ */
struct drm_crtc *(*get_crtc)(struct drm_encoder *encoder);
- /* detect for DAC style encoders */
+
+ /**
+ * @detect:
+ *
+ * This callback can be used by drivers who want to do detection on the
+ * encoder object instead of in connector functions.
+ *
+ * It is not used by any helper and therefore has purely driver-specific
+ * semantics. New drivers shouldn't use this and instead just implement
+ * their own private callbacks.
+ *
+ * FIXME:
+ *
+ * This should just be converted into a pile of driver vfuncs.
+ * Currently radeon, amdgpu and nouveau are using it.
+ */
enum drm_connector_status (*detect)(struct drm_encoder *encoder,
struct drm_connector *connector);
+
+ /**
+ * @disable:
+ *
+ * This callback should be used to disable the encoder. With the atomic
+ * drivers it is called before this encoder's CRTC has been shut off
+ * using the CRTC's own ->disable hook. If that sequence is too simple
+ * drivers can just add their own driver private encoder hooks and call
+ * them from CRTC's callback by looping over all encoders connected to
+ * it using for_each_encoder_on_crtc().
+ *
+ * This hook is used both by legacy CRTC helpers and atomic helpers.
+ * Atomic drivers don't need to implement it if there's no need to
+ * disable anything at the encoder level. To ensure that runtime PM
+ * handling (using either DPMS or the new "ACTIVE" property) works
+ * @disable must be the inversve of @enable for atomic drivers.
+ *
+ * NOTE:
+ *
+ * With legacy CRTC helpers there's a big semantic difference between
+ * @disable other hooks (like @prepare or @dpms) used to shut down a
+ * encoder: @disable is only called when also logically disabling the
+ * display pipeline and needs to release any resources acquired in
+ * @mode_set (like shared PLLs, or again release pinned framebuffers).
+ *
+ * Therefore @disable must be the inverse of @mode_set plus @commit for
+ * drivers still using legacy CRTC helpers, which is different from the
+ * rules under atomic.
+ */
void (*disable)(struct drm_encoder *encoder);
+ /**
+ * @enable:
+ *
+ * This callback should be used to enable the encoder. With the atomic
+ * drivers it is called after this encoder's CRTC has been enabled using
+ * the CRTC's own ->enable hook. If that sequence is too simple drivers
+ * can just add their own driver private encoder hooks and call them
+ * from CRTC's callback by looping over all encoders connected to it
+ * using for_each_encoder_on_crtc().
+ *
+ * This hook is used only by atomic helpers, for symmetry with @disable.
+ * Atomic drivers don't need to implement it if there's no need to
+ * enable anything at the encoder level. To ensure that runtime PM handling
+ * (using either DPMS or the new "ACTIVE" property) works
+ * @enable must be the inversve of @disable for atomic drivers.
+ */
void (*enable)(struct drm_encoder *encoder);
- /* atomic helpers */
+ /**
+ * @atomic_check:
+ *
+ * This callback is used to validate encoder state for atomic drivers.
+ * Since the encoder is the object connecting the CRTC and connector it
+ * gets passed both states, to be able to validate interactions and
+ * update the CRTC to match what the encoder needs for the requested
+ * connector.
+ *
+ * This function is used by the atomic helpers, but it is optional.
+ *
+ * NOTE:
+ *
+ * This function is called in the check phase of an atomic update. The
+ * driver is not allowed to change anything outside of the free-standing
+ * state objects passed-in or assembled in the overall &drm_atomic_state
+ * update tracking structure.
+ *
+ * RETURNS:
+ *
+ * 0 on success, -EINVAL if the state or the transition can't be
+ * support, -ENOMEM on memory allocation failure and -EDEADLK if an
+ * attempt to obtain another state object ran into a &drm_modeset_lock
+ * deadlock.
+ */
int (*atomic_check)(struct drm_encoder *encoder,
struct drm_crtc_state *crtc_state,
struct drm_connector_state *conn_state);
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 27/28] drm: Document drm_encoder/crtc_helper_funcs
2015-12-04 8:46 ` [PATCH 27/28] drm: Document drm_encoder/crtc_helper_funcs Daniel Vetter
@ 2015-12-07 15:21 ` Thierry Reding
0 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 15:21 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 9850 bytes --]
On Fri, Dec 04, 2015 at 09:46:08AM +0100, Daniel Vetter wrote:
> Mostly this is about all the callbacks used to modesets by both legacy
"used for modesets"?
> CRTC helpers and atomic helpers and I figured it doesn't make all that
> much sense to split this up.
>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> include/drm/drm_modeset_helper_vtables.h | 447 +++++++++++++++++++++++++++----
> 1 file changed, 400 insertions(+), 47 deletions(-)
>
> diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h
> index 22cc51b278fb..d776ef6dd00e 100644
> --- a/include/drm/drm_modeset_helper_vtables.h
> +++ b/include/drm/drm_modeset_helper_vtables.h
> @@ -46,58 +46,236 @@ enum mode_set_atomic;
>
> /**
> * struct drm_crtc_helper_funcs - helper operations for CRTCs
> - * @dpms: set power state
> - * @prepare: prepare the CRTC, called before @mode_set
> - * @commit: commit changes to CRTC, called after @mode_set
> - * @mode_fixup: try to fixup proposed mode for this CRTC
> - * @mode_set: set this mode
> - * @mode_set_nofb: set mode only (no scanout buffer attached)
> - * @mode_set_base: update the scanout buffer
> - * @mode_set_base_atomic: non-blocking mode set (used for kgdb support)
> - * @load_lut: load color palette
> - * @disable: disable CRTC when no longer in use
> - * @enable: enable CRTC
> *
> - * The helper operations are called by the mid-layer CRTC helper.
> - *
> - * Note that with atomic helpers @dpms, @prepare and @commit hooks are
> - * deprecated. Used @enable and @disable instead exclusively.
> - *
> - * With legacy crtc helpers there's a big semantic difference between @disable
> - * and the other hooks: @disable also needs to release any resources acquired in
> - * @mode_set (like shared PLLs).
> + * These hooks are used by the legacy CRTC helpers, the transitional plane
> + * helpers and the new atomic modesetting helpers.
> */
> struct drm_crtc_helper_funcs {
> - /*
> - * Control power levels on the CRTC. If the mode passed in is
> - * unsupported, the provider must use the next lowest power level.
> + /**
> + * @dpms:
> + *
> + * Callback to control power levels on the CRTC. If the mode passed in
> + * is unsupported, the provider must use the next lowest power level.
> + * This is used by the legacy CRTC helpers to implement DPMS
> + * functionality in drm_helper_connector_dpms().
> + *
> + * This callback is also used to disable a CRTC by calling it with
> + * DRM_MODE_DPMS_OFF if the @disable hook isn't used.
> + *
> + * This callback is used by the legacy CRTC helpers. Atomic helpers
> + * also support using this hook for enabling and disabling a CRTC to
> + * facilitate transitions to atomic, but it is deprecated. Instead
> + * @enable and @disable should be used.
> */
> void (*dpms)(struct drm_crtc *crtc, int mode);
> +
> + /**
> + * @prepare:
> + *
> + * This callback should prepare the CRTC for a subsequent modeset, which
> + * in practice means the driver should disable the CRTC if it is
> + * running. Most drivers ended up implementing this by calling their
> + * @dpms hook with DRM_MODE_DPMS_OFF.
> + *
> + * This callback is used by the legacy CRTC helpers. Atomic helpers
> + * also support using this hook for disabling a CRTC to facilitate
> + * transitions to atomic, but it is deprecated. Instead @disable should
> + * be used.
> + */
> void (*prepare)(struct drm_crtc *crtc);
> +
> + /**
> + * @commit:
> + *
> + * This callback should commit the new mode on the CRTC after a modeset,
> + * which in practice means the driver should enable the CRTC. Most
> + * drivers ended up implementing this by calling their @dpms hook with
> + * DRM_MODE_DPMS_ON.
> + *
> + * This callback is used by the legacy CRTC helpers. Atomic helpers
> + * also support using this hook for enabling a CRTC to facilitate
> + * transitions to atomic, but it is deprecated. Instead @enable should
> + * be used.
> + */
> void (*commit)(struct drm_crtc *crtc);
>
> - /* Provider can fixup or change mode timings before modeset occurs */
> + /**
> + * @mode_fixup:
> + *
> + * This callback is used to validate a mode. The paramater mode is the
"parameter"
[...]
> + /**
> + * @disable:
> + *
> + * This callback should be used to disable the CRTC. With the atomic
> + * drivers it is called after all encoders connected to this CRTC have
> + * been shut off already using their own ->disable hook. If that
> + * sequence is too simple drivers can just add their own hooks and call
> + * it from this CRTC callback here by looping over all encoders
> + * connected to it using for_each_encoder_on_crtc().
> + *
> + * This hook is used both by legacy CRTC helpers and atomic helpers.
> + * Atomic drivers don't need to implement it if there's no need to
> + * disable anything at the CRTC level. To ensure that runtime PM
> + * handling (using either DPMS or the new "ACTIVE" property) works
> + * @disable must be the inversve of @enable for atomic drivers.
"inverse"
> + *
> + * NOTE:
> + *
> + * With legacy CRTC helpers there's a big semantic difference between
> + * @disable other hooks (like @prepare or @dpms) used to shut down a
"and other hooks"
> + * CRTC: @disable is only called when also logically disabling the
> + * display pipeline and needs to release any resources acquired in
> + * @mode_set (like shared PLLs, or again release pinned framebuffers).
> + *
> + * Therefore @disable must be the inverse of @mode_set plus @commit for
> + * drivers still using legacy CRTC helpers, which is different from the
> + * rules under atomic.
> + */
> void (*disable)(struct drm_crtc *crtc);
[...]
> struct drm_encoder_helper_funcs {
> + /**
> + * @dpms:
> + *
> + * Callback to control power levels on the encoder. If the mode passed in
> + * is unsupported, the provider must use the next lowest power level.
> + * This is used by the legacy encoder helpers to implement DPMS
> + * functionality in drm_helper_connector_dpms().
> + *
> + * This callback is also used to disable a encoder by calling it with
"disable an encoder"
> + * DRM_MODE_DPMS_OFF if the @disable hook isn't used.
> + *
> + * This callback is used by the legacy CRTC helpers. Atomic helpers
> + * also support using this hook for enabling and disabling a encoder to
> + * facilitate transitions to atomic, but it is deprecated. Instead
> + * @enable and @disable should be used.
> + */
> void (*dpms)(struct drm_encoder *encoder, int mode);
>
> + /**
> + * @mode_fixup:
> + *
> + * This callback is used to validate and adjust a mode. The paramater
"parameter"
> + /**
> + * @disable:
> + *
> + * This callback should be used to disable the encoder. With the atomic
> + * drivers it is called before this encoder's CRTC has been shut off
> + * using the CRTC's own ->disable hook. If that sequence is too simple
> + * drivers can just add their own driver private encoder hooks and call
> + * them from CRTC's callback by looping over all encoders connected to
> + * it using for_each_encoder_on_crtc().
> + *
> + * This hook is used both by legacy CRTC helpers and atomic helpers.
> + * Atomic drivers don't need to implement it if there's no need to
> + * disable anything at the encoder level. To ensure that runtime PM
> + * handling (using either DPMS or the new "ACTIVE" property) works
> + * @disable must be the inversve of @enable for atomic drivers.
"inverse"
> + *
> + * NOTE:
> + *
> + * With legacy CRTC helpers there's a big semantic difference between
> + * @disable other hooks (like @prepare or @dpms) used to shut down a
"and other hooks", "an encoder"
> + /**
> + * @enable:
> + *
> + * This callback should be used to enable the encoder. With the atomic
> + * drivers it is called after this encoder's CRTC has been enabled using
> + * the CRTC's own ->enable hook. If that sequence is too simple drivers
> + * can just add their own driver private encoder hooks and call them
> + * from CRTC's callback by looping over all encoders connected to it
> + * using for_each_encoder_on_crtc().
> + *
> + * This hook is used only by atomic helpers, for symmetry with @disable.
> + * Atomic drivers don't need to implement it if there's no need to
> + * enable anything at the encoder level. To ensure that runtime PM handling
> + * (using either DPMS or the new "ACTIVE" property) works
> + * @enable must be the inversve of @disable for atomic drivers.
"inverse"
> + */
> void (*enable)(struct drm_encoder *encoder);
>
> - /* atomic helpers */
> + /**
> + * @atomic_check:
> + *
> + * This callback is used to validate encoder state for atomic drivers.
> + * Since the encoder is the object connecting the CRTC and connector it
> + * gets passed both states, to be able to validate interactions and
> + * update the CRTC to match what the encoder needs for the requested
> + * connector.
> + *
> + * This function is used by the atomic helpers, but it is optional.
> + *
> + * NOTE:
> + *
> + * This function is called in the check phase of an atomic update. The
> + * driver is not allowed to change anything outside of the free-standing
> + * state objects passed-in or assembled in the overall &drm_atomic_state
> + * update tracking structure.
> + *
> + * RETURNS:
> + *
> + * 0 on success, -EINVAL if the state or the transition can't be
> + * support, -ENOMEM on memory allocation failure and -EDEADLK if an
"supported"
Thanks for writing this up, it's great documentation.
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread
* [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe
2015-12-04 8:45 [PATCH 00/28] kerneldoc for display vtables Daniel Vetter
` (26 preceding siblings ...)
2015-12-04 8:46 ` [PATCH 27/28] drm: Document drm_encoder/crtc_helper_funcs Daniel Vetter
@ 2015-12-04 8:46 ` Daniel Vetter
2015-12-07 13:42 ` Ville Syrjälä
` (2 more replies)
27 siblings, 3 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-04 8:46 UTC (permalink / raw)
To: DRI Development; +Cc: Daniel Vetter, Intel Graphics Development, Daniel Stone
We want this for consistency with existing page_flip semantics.
Since this spurred quite a discussion on IRC also document why we
reject even generation when the pipe is off: It's not that it's hard
to implement, but userspace has a track recording proofing that it's
way too easy to accidentally abuse and cause havoc. We want to make
sure userspace doesn't get away with that.
Cc: Daniel Stone <daniels@collabora.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
---
drivers/gpu/drm/drm_atomic.c | 9 +++++++++
drivers/gpu/drm/drm_atomic_helper.c | 8 ++++++++
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 7426d40017a0..06cdb52907da 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1265,6 +1265,15 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
if (config->funcs->atomic_check)
ret = config->funcs->atomic_check(state->dev, state);
+ /*
+ * Reject event generation for when a CRTC is off and stays off. It
+ * wouldn't be hard to implement this, but userspace has a track record
+ * of happily burning through 100% cpu (or worse, crash) when the
+ * display pipe is suspended. To avoid all that fun just reject updates
+ * that ask for events since likely that indicates a bug in the
+ * compositors drawing loop. This is consistent with the vblank ioctl
+ * which also rejects service on a disabled pipe.
+ */
if (!state->allow_modeset) {
for_each_crtc_in_state(state, crtc, crtc_state, i) {
if (drm_atomic_crtc_needs_modeset(crtc_state)) {
diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
index 110f3db8dd05..8e281a96c35f 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2283,6 +2283,14 @@ retry:
goto fail;
drm_atomic_set_fb_for_plane(plane_state, fb);
+ state->allow_modeset = false;
+ if (!crtc_state->active) {
+ DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
+ crtc->base.id);
+ ret = -EINVAL;
+ goto fail;
+ }
+
ret = drm_atomic_async_commit(state);
if (ret != 0)
goto fail;
--
2.5.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related [flat|nested] 81+ messages in thread* Re: [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe
2015-12-04 8:46 ` [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe Daniel Vetter
@ 2015-12-07 13:42 ` Ville Syrjälä
2015-12-07 15:25 ` Thierry Reding
2015-12-07 15:33 ` Daniel Stone
2 siblings, 0 replies; 81+ messages in thread
From: Ville Syrjälä @ 2015-12-07 13:42 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, Daniel Stone, DRI Development
On Fri, Dec 04, 2015 at 09:46:09AM +0100, Daniel Vetter wrote:
> We want this for consistency with existing page_flip semantics.
>
> Since this spurred quite a discussion on IRC also document why we
> reject even generation when the pipe is off: It's not that it's hard
> to implement, but userspace has a track recording proofing that it's
> way too easy to accidentally abuse and cause havoc. We want to make
> sure userspace doesn't get away with that.
>
> Cc: Daniel Stone <daniels@collabora.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/drm_atomic.c | 9 +++++++++
> drivers/gpu/drm/drm_atomic_helper.c | 8 ++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7426d40017a0..06cdb52907da 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1265,6 +1265,15 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> if (config->funcs->atomic_check)
> ret = config->funcs->atomic_check(state->dev, state);
>
> + /*
> + * Reject event generation for when a CRTC is off and stays off. It
> + * wouldn't be hard to implement this, but userspace has a track record
> + * of happily burning through 100% cpu (or worse, crash) when the
> + * display pipe is suspended. To avoid all that fun just reject updates
> + * that ask for events since likely that indicates a bug in the
> + * compositors drawing loop. This is consistent with the vblank ioctl
> + * which also rejects service on a disabled pipe.
> + */
> if (!state->allow_modeset) {
> for_each_crtc_in_state(state, crtc, crtc_state, i) {
> if (drm_atomic_crtc_needs_modeset(crtc_state)) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 110f3db8dd05..8e281a96c35f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2283,6 +2283,14 @@ retry:
Argh! Once again that stupid 'put goto labes at col 0' rule making
it impossible to review a patch. Could we *please* change that to
put the labels at col 1 instead?
> goto fail;
> drm_atomic_set_fb_for_plane(plane_state, fb);
>
> + state->allow_modeset = false;
> + if (!crtc_state->active) {
> + DRM_DEBUG_ATOMIC("[CRTC:%d] disabled, rejecting legacy flip\n",
> + crtc->base.id);
> + ret = -EINVAL;
> + goto fail;
> + }
> +
> ret = drm_atomic_async_commit(state);
> if (ret != 0)
> goto fail;
> --
> 2.5.1
--
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe
2015-12-04 8:46 ` [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe Daniel Vetter
2015-12-07 13:42 ` Ville Syrjälä
@ 2015-12-07 15:25 ` Thierry Reding
2015-12-07 15:33 ` Daniel Stone
2 siblings, 0 replies; 81+ messages in thread
From: Thierry Reding @ 2015-12-07 15:25 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, Daniel Stone, DRI Development
[-- Attachment #1.1: Type: text/plain, Size: 2270 bytes --]
On Fri, Dec 04, 2015 at 09:46:09AM +0100, Daniel Vetter wrote:
> We want this for consistency with existing page_flip semantics.
>
> Since this spurred quite a discussion on IRC also document why we
> reject even generation when the pipe is off: It's not that it's hard
> to implement, but userspace has a track recording proofing that it's
> way too easy to accidentally abuse and cause havoc. We want to make
> sure userspace doesn't get away with that.
>
> Cc: Daniel Stone <daniels@collabora.com>
> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
> ---
> drivers/gpu/drm/drm_atomic.c | 9 +++++++++
> drivers/gpu/drm/drm_atomic_helper.c | 8 ++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7426d40017a0..06cdb52907da 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1265,6 +1265,15 @@ int drm_atomic_check_only(struct drm_atomic_state *state)
> if (config->funcs->atomic_check)
> ret = config->funcs->atomic_check(state->dev, state);
>
> + /*
> + * Reject event generation for when a CRTC is off and stays off. It
> + * wouldn't be hard to implement this, but userspace has a track record
> + * of happily burning through 100% cpu (or worse, crash) when the
> + * display pipe is suspended. To avoid all that fun just reject updates
> + * that ask for events since likely that indicates a bug in the
> + * compositors drawing loop. This is consistent with the vblank ioctl
"compositor's".
> + * which also rejects service on a disabled pipe.
> + */
> if (!state->allow_modeset) {
> for_each_crtc_in_state(state, crtc, crtc_state, i) {
> if (drm_atomic_crtc_needs_modeset(crtc_state)) {
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c
> index 110f3db8dd05..8e281a96c35f 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2283,6 +2283,14 @@ retry:
> goto fail;
> drm_atomic_set_fb_for_plane(plane_state, fb);
>
> + state->allow_modeset = false;
Perhaps explain the reason for setting this?
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe
2015-12-04 8:46 ` [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe Daniel Vetter
2015-12-07 13:42 ` Ville Syrjälä
2015-12-07 15:25 ` Thierry Reding
@ 2015-12-07 15:33 ` Daniel Stone
2015-12-08 8:23 ` Daniel Vetter
2 siblings, 1 reply; 81+ messages in thread
From: Daniel Stone @ 2015-12-07 15:33 UTC (permalink / raw)
To: Daniel Vetter; +Cc: Intel Graphics Development, Daniel Stone, DRI Development
Hi,
On 4 December 2015 at 08:46, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> + /*
> + * Reject event generation for when a CRTC is off and stays off. It
> + * wouldn't be hard to implement this, but userspace has a track record
> + * of happily burning through 100% cpu (or worse, crash) when the
> + * display pipe is suspended. To avoid all that fun just reject updates
> + * that ask for events since likely that indicates a bug in the
> + * compositors drawing loop. This is consistent with the vblank ioctl
> + * which also rejects service on a disabled pipe.
> + */
Sorry to keep whingeing, but this isn't actually related to event
generation. To the best of my knowledge, this change does a few
things. Firstly, comments the check above (enforcing that (flags &
ALLOW_MODESET) == {crtcs}->allow_modeset), which is good. But the
comment is incorrect, because whether or not an event is requested is
wholly unrelated. Secondly, it disables allow_modeset on pageflip,
which shouldn't be changing DPMS stage (good!). Thirdly, it enforces
something like the above statement on pageflips, except again it has
no regard to events: it just enforces the no-DPMS-on-flip rule, for
which event generation is a subset.
If you fix the above comment to more accurately note that this just
enforces that you need the ALLOW_MODESET flag to change active, mode
or connector routing, and (as Thierry asked), add a comment below to
note that we enforce existing no-DPMS-on-flip semantics in the helper,
then you're welcome to my R-b. But please don't mention events in the
new comment. :)
Cheers,
Daniel
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread* Re: [PATCH 28/28] drm/atomic-helper: Reject legacy flips on a disabled pipe
2015-12-07 15:33 ` Daniel Stone
@ 2015-12-08 8:23 ` Daniel Vetter
0 siblings, 0 replies; 81+ messages in thread
From: Daniel Vetter @ 2015-12-08 8:23 UTC (permalink / raw)
To: Daniel Stone
Cc: Daniel Vetter, Intel Graphics Development, Daniel Stone, DRI Development
On Mon, Dec 07, 2015 at 03:33:00PM +0000, Daniel Stone wrote:
> Hi,
>
> On 4 December 2015 at 08:46, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> > + /*
> > + * Reject event generation for when a CRTC is off and stays off. It
> > + * wouldn't be hard to implement this, but userspace has a track record
> > + * of happily burning through 100% cpu (or worse, crash) when the
> > + * display pipe is suspended. To avoid all that fun just reject updates
> > + * that ask for events since likely that indicates a bug in the
> > + * compositors drawing loop. This is consistent with the vblank ioctl
> > + * which also rejects service on a disabled pipe.
> > + */
>
> Sorry to keep whingeing, but this isn't actually related to event
> generation. To the best of my knowledge, this change does a few
> things. Firstly, comments the check above (enforcing that (flags &
> ALLOW_MODESET) == {crtcs}->allow_modeset), which is good. But the
> comment is incorrect, because whether or not an event is requested is
> wholly unrelated. Secondly, it disables allow_modeset on pageflip,
> which shouldn't be changing DPMS stage (good!). Thirdly, it enforces
> something like the above statement on pageflips, except again it has
> no regard to events: it just enforces the no-DPMS-on-flip rule, for
> which event generation is a subset.
Well the comment is completely misplace, I wanted to put it next to the
check for event generation, not here.
> If you fix the above comment to more accurately note that this just
> enforces that you need the ALLOW_MODESET flag to change active, mode
> or connector routing, and (as Thierry asked), add a comment below to
> note that we enforce existing no-DPMS-on-flip semantics in the helper,
> then you're welcome to my R-b. But please don't mention events in the
> new comment. :)
Hm, I didn't really want to type a comment for ALLOW_MODESET - imo it's
pretty clear what it does and why it's useful. I'll try again at making
something coheren here ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 81+ messages in thread