Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
On Fri, Jun 15, 2018 at 2:08 AM Jani Nikula wrote: > > On Thu, 14 Jun 2018, Rodrigo Vivi wrote: > > On Wed, Jun 13, 2018 at 09:55:38AM +0300, Jani Nikula wrote: > >> On Tue, 12 Jun 2018, Lucas De Marchi wrote: > >> > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula > >> > wrote: > >> >> > >> >> On Tue, 12 Jun 2018, Tvrtko Ursulin > >> >> 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,
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
On Mon, 18 Jun 2018, Joonas Lahtinen wrote: > Quoting Jani Nikula (2018-06-15 12:08:23) >> On Thu, 14 Jun 2018, Rodrigo Vivi wrote: >> > On Wed, Jun 13, 2018 at 09:55:38AM +0300, Jani Nikula wrote: >> >> On Tue, 12 Jun 2018, Lucas De Marchi wrote: >> >> > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula >> >> > wrote: >> >> >> >> >> >> On Tue, 12 Jun 2018, Tvrtko Ursulin >> >> >> 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. > > I'm somewhere in the middle, but I have to agree changing everything with > one patch would be bit too overwhelming for review. Okay, we can continue to debate, but I've pushed this series in the mean time because it has review and by my judgement should not conflict much. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
Quoting Jani Nikula (2018-06-15 12:08:23) > On Thu, 14 Jun 2018, Rodrigo Vivi wrote: > > On Wed, Jun 13, 2018 at 09:55:38AM +0300, Jani Nikula wrote: > >> On Tue, 12 Jun 2018, Lucas De Marchi wrote: > >> > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula > >> > wrote: > >> >> > >> >> On Tue, 12 Jun 2018, Tvrtko Ursulin > >> >> 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. I'm somewhere in the middle, but I have to agree changing everything with one patch would be bit too overwhelming for review. Regards, Joonas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
On Thu, 14 Jun 2018, Rodrigo Vivi wrote: > On Wed, Jun 13, 2018 at 09:55:38AM +0300, Jani Nikula wrote: >> On Tue, 12 Jun 2018, Lucas De Marchi wrote: >> > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula wrote: >> >> >> >> On Tue, 12 Jun 2018, Tvrtko Ursulin >> >> 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@lists.freedesktop.org >> >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx >> >> -- >> Jani Nikula, Intel Open Source Graphics Center >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >>
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
On Wed, Jun 13, 2018 at 09:55:38AM +0300, Jani Nikula wrote: > On Tue, 12 Jun 2018, Lucas De Marchi wrote: > > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula wrote: > >> > >> On Tue, 12 Jun 2018, Tvrtko Ursulin 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. > > 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@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Jani Nikula, Intel Open Source Graphics Center > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
On Tue, 12 Jun 2018, Lucas De Marchi wrote: > On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula wrote: >> >> On Tue, 12 Jun 2018, Tvrtko Ursulin 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. 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@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
On Tue, Jun 12, 2018 at 3:15 AM Jani Nikula wrote: > > On Tue, 12 Jun 2018, Tvrtko Ursulin 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. 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@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
On Tue, Jun 12, 2018 at 12:19:28PM +0300, 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? > > $ 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 Did a quick once over and didn't spot anything wrong, so Reviewed-by: Ville Syrjälä > > 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(-) > > -- > 2.11.0 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
On Tue, 12 Jun 2018, Tvrtko Ursulin 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. ;) > 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@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
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? 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? 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(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/7] drm/i915: move towards kernel types
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? $ 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(-) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
