[Intel-gfx] [PATCH 2/8] drm/i915: Make the intel_device_info structure kept in dev_priv writable

Daniel Vetter daniel at ffwll.ch
Mon Feb 10 10:09:11 CET 2014


On Fri, Feb 07, 2014 at 07:12:48PM +0000, Damien Lespiau wrote:
> Turns out it'd be nice to change some device information at run-time or simply
> have some code to fill in the info struct instead of having to declare the
> values in 30+ structures.
> 
> What prompted this change is handling fused out display/pipe and tweaking
> num_pipes at run-time, but I'm quite sure we'll find other flags/limits to
> stick into dev_priv->info.
> 
> Most of the changes were done with a sed:
> sed -i -e 's/dev_priv->info->/dev_priv->info./g' drivers/gpu/drm/i915/*[ch]
> 
> with a few tweaks to make it all work:
> - Change the field definition in struct drm_i915_private
> - adjust i915_dump_device_info()
> - adjust i915_driver_load()
> - adjust the INTEL_INFO() macro
> 
> v2: cast the info pointer returned by INTEL_INFO() to be const to catch
>     uses that would modify the structure post-initialization.
>     (Ville Syrjälä)
> 
> v3: Redo the patch onto latest drm-nightly,
>     Keep the info field const to catch post initialization writes
>     instead of the v2 solution,
>     Use a direct structure copy for the initial info initialization to
>     use the compiler type safety (Ville Syrjälä)
> 
> Reviewed-by: Mika Kuoppala <mika.kuoppala at intel.com> (for v2)
> Reviewed-by: Ville Syrjälä <ville.syrjala at linux.intel.com> (for v2)
> Signed-off-by: Damien Lespiau <damien.lespiau at intel.com>

[snip]

> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 728b9c3..f66699f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1390,7 +1390,7 @@ typedef struct drm_i915_private {
>  	struct drm_device *dev;
>  	struct kmem_cache *slab;
>  
> -	const struct intel_device_info *info;
> +	const struct intel_device_info info;

Since every access should now go through the macro I think it'd be good to
give this a __ prefix to make it clear that users better think twice
before using it. Maybe as a patch on top of all this?
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch



More information about the Intel-gfx mailing list