[Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types

Jani Nikula jani.nikula at intel.com
Fri Jun 15 09:08:23 UTC 2018


On Thu, 14 Jun 2018, Rodrigo Vivi <rodrigo.vivi at intel.com> wrote:
> On Wed, Jun 13, 2018 at 09:55:38AM +0300, Jani Nikula wrote:
>> On Tue, 12 Jun 2018, Lucas De Marchi <lucas.de.marchi at gmail.com> wrote:
>> > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula <jani.nikula at intel.com> wrote:
>> >>
>> >> On Tue, 12 Jun 2018, Tvrtko Ursulin <tvrtko.ursulin at linux.intel.com> wrote:
>> >> > On 12/06/2018 10:19, Jani Nikula wrote:
>> >> >> Semi-RFC. Do we want to do this? Here's a batch of conversions that shouldn't
>> >> >> conflict much with in-flight patches.
>> >> >>
>> >> >> The trouble with mixed use is that it's inconsistent, and any remaining C99
>> >> >> types will encourage their use. We could at least do the low hanging fruit?
>> >> >
>> >> > Ack from me. Doesn't seem so big to cause much pain.
>> >> >
>> >> > When you say low-hanging fruit, that implies you only dealt with a
>> >> > particular class of occurrences?
>> >>
>> >> I meant the files which don't have massive amounts of C99 types and
>> >> aren't under active development right now. I just wanted to avoid
>> >> trouble for starters. ;)
>> >
>> > If using kernel types is where we want to go (which I agree with),
>> > maybe it would be better to have a single conversion rather than
>> > several small ones as we are doing with dev_priv -> i915? This allows
>> > in-flight-but-not-yet-sent patches to easily keep up with the changes
>> > rather than conflicting every other rebase.
>> 
>> I'm thinking we can do a lot of changes without conflicting anything or
>> very little. At least for starters before the sudden ripping off the
>> band-aid.
>
> I'm with Lucas. I'd prefer one single massive move than many small ones.
> Easier for the internal maintenance. We fix it only once and not one per
> day for months and months like dev_priv/i915 case.

For everything else, I believe smaller patches are easier. For example,
who is going to review the massive change? Halt everything until it's
reviewed and merged? For merge conflicts I think git can do a better job
of managing the rerere with piecemeal changes. Internal is not the only
consideration.

BR,
Jani.

>
>> 
>> BR,
>> Jani.
>> 
>> >
>> > Lucas De Marchi
>> >
>> >>
>> >> > Also going forward we have to make sure we will be able to stop them
>> >> > creeping back in. Is checkpatch perhaps covering this? Or we could put
>> >> > something in dim?
>> >>
>> >> We can stop ignoring PREFER_KERNEL_TYPES in checkpatch (the ignores are
>> >> in dim). We don't even have to change everything for that, we just need
>> >> to change enough to make the S/N better. People tend to use the types
>> >> near the places they change.
>> >>
>> >> BR,
>> >> Jani.
>> >>
>> >>
>> >> >
>> >> > Regards,
>> >> >
>> >> > Tvrtko
>> >> >
>> >> >> $ git grep "uint\(8\|16\|32\|64\)_t" -- drivers/gpu/drm/i915/ | sed 's/:.*//' | sort | uniq -c | sort -n
>> >> >>
>> >> >> BR,
>> >> >> Jani.
>> >> >>
>> >> >>
>> >> >> Jani Nikula (7):
>> >> >>    drm/i915/vbt: switch to kernel unsigned int types
>> >> >>    drm/i915/hdmi: switch to kernel unsigned int types
>> >> >>    drm/i915/uncore: switch to kernel unsigned int types
>> >> >>    drm/i915/dvo: switch to kernel unsigned int types
>> >> >>    drm/i915/backlight: switch to kernel unsigned int types
>> >> >>    drm/i915/audio: switch to kernel unsigned int types
>> >> >>    drm/i915/lspcon: switch to kernel unsigned int types
>> >> >>
>> >> >>   drivers/gpu/drm/i915/dvo_ch7017.c             | 20 ++++++------
>> >> >>   drivers/gpu/drm/i915/dvo_ch7xxx.c             | 22 +++++++-------
>> >> >>   drivers/gpu/drm/i915/dvo_ivch.c               | 26 ++++++++--------
>> >> >>   drivers/gpu/drm/i915/dvo_ns2501.c             | 44 +++++++++++++--------------
>> >> >>   drivers/gpu/drm/i915/dvo_sil164.c             | 10 +++---
>> >> >>   drivers/gpu/drm/i915/dvo_tfp410.c             | 16 +++++-----
>> >> >>   drivers/gpu/drm/i915/intel_audio.c            | 36 +++++++++++-----------
>> >> >>   drivers/gpu/drm/i915/intel_bios.c             |  4 +--
>> >> >>   drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 12 ++++----
>> >> >>   drivers/gpu/drm/i915/intel_dvo.c              |  2 +-
>> >> >>   drivers/gpu/drm/i915/intel_hdmi.c             | 14 ++++-----
>> >> >>   drivers/gpu/drm/i915/intel_lspcon.c           |  2 +-
>> >> >>   drivers/gpu/drm/i915/intel_panel.c            |  8 ++---
>> >> >>   drivers/gpu/drm/i915/intel_uncore.h           | 22 +++++++-------
>> >> >>   drivers/gpu/drm/i915/intel_vbt_defs.h         |  2 +-
>> >> >>   15 files changed, 120 insertions(+), 120 deletions(-)
>> >> >>
>> >>
>> >> --
>> >> Jani Nikula, Intel Open Source Graphics Center
>> >> _______________________________________________
>> >> Intel-gfx mailing list
>> >> Intel-gfx at lists.freedesktop.org
>> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> 
>> -- 
>> Jani Nikula, Intel Open Source Graphics Center
>> _______________________________________________
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Jani Nikula, Intel Open Source Graphics Center


More information about the Intel-gfx mailing list