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

Tue Jun 19 06:55:08 UTC 2018

On Fri, Jun 15, 2018 at 2:08 AM Jani Nikula <jani.nikula at intel.com> wrote:
>
> 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.

A change like this would be a matter of having a sed/cocci/whatever
script that can be reproduced later.
The end result can be split in logical chunks for review/merge, I
never said it ought to be in one patch.

Lucas De Marchi

>
> 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

-- 
Lucas De Marchi