On Mon, 10 Feb 2014, Daniel Vetter <daniel@xxxxxxxx> wrote:
> 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@xxxxxxxxx> (for v2)
>> Reviewed-by: Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> (for v2)
>> Signed-off-by: Damien Lespiau <damien.lespiau@xxxxxxxxx>
>
> [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?
Begs the question whether every access also in i915_reg.h should be
through the macro. If that was changed before this patch, this one
wouldn't have to touch i915_reg.h at all AFAICT.
BR,
Jani.
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
