[git pull] drm for v4.15 (fixes/cleanups/one small feature)

[Dave Airlie]

Hi Linus,

This is just some bits and pieces for the second half of the merge window,

1. Remove the MSM dt-bindings file Rob managed to push in the previous pull.
2. Add a property/edid quirk to denote HMD devices, I had these
hanging around for a few weeks and Keith had done some work on them,
they are fairly self contained and small, and only affect people using
HTC Vive VR headsets so far.
3. amdgpu, tegra, tilcdc, fsl fixes
4. some imx-drm cleanups I missed, these seemed pretty small, and no
reason to hold off.

I have one TTM regression fix (fixes bochs-vga in qemu) sitting
locally awaiting review I'll probably send that in a separate pull
request tomorrow.

Dave.

The following changes since commit f150891fd9878ef0d9197c4e8451ce67c3bdd014:

  Merge tag 'exynos-drm-next-for-v4.15' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-next (2017-11-14 14:12:43 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-for-v4.15-part2

for you to fetch changes up to 98ecf1a308977505381b5c360b039a84cf67513c:

  dt-bindings: remove file that was added accidentally (2017-11-23
14:10:39 +1000)


fixes/cleanups for rc1, non-desktop flags for VR


Alex Deucher (2):
  Revert "drm/radeon: dont switch vt on suspend"
  drm/amdgpu: don't skip attributes when powerplay is enabled

Christian König (2):
  drm/amdgpu: make AMDGPU_VA_RESERVED_SIZE 64bit
  drm/amdgpu: set f_mapping on exported DMA-bufs

Cihangir Akturk (1):
  drm/imx: switch to drm_*_get(), drm_*_put() helpers

Colin Ian King (1):
  drm/amd/powerplay: fix copy-n-paste error on vddci_buf index

Dave Airlie (9):
  Merge branch 'drm-next-4.15' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'drm-fsl-dcu-fixes-for-v4.15' of
http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next
  Merge tag 'drm/tegra/for-4.15-rc1-fixes' of
git://anongit.freedesktop.org/tegra/linux into drm-next
  Merge tag 'imx-drm-next-2017-10-18' of
git://git.pengutronix.de/git/pza/linux into drm-next
  Merge branch 'drm-next-4.15' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'tilcdc-4.15-fixes' of https://github.com/jsarha/linux
into drm-next
  drm: add connector info/property for non-desktop displays [v2]
  drm/fb: add support for not enabling fbcon on non-desktop displays [v2]
  drm/edid: quirk HTC vive headset as non-desktop. [v2]

Emily Deng (1):
  drm/amdgpu: Fix null pointer issue in amdgpu_cs_wait_any_fence

Eric Huang (1):
  drm/amd/powerplay: fix unfreeze level smc message for smu7

Fabio Estevam (1):
  gpu: ipu-v3: ipu-dc: Remove unused 'di' variable

Jyri Sarha (1):
  drm/tilcdc: Remove obsolete "ti,tilcdc,slave" dts binding support

Ken Wang (2):
  drm/amdgpu: Remove check which is not valid for certain VBIOS
  drm/amdgpu: Add common golden settings for GFX9

Laurent Pinchart (1):
  drm/fsl-dcu: Don't set connector DPMS property

Lucas Stach (1):
  drm/imx: parallel-display: use correct connector enum

Marco Franchi (1):
  dt-bindings: fsl-imx-drm: Remove incorrect "@di0" usage

Monk Liu (2):
  drm/amdgpu:fix memleak in takedown
  drm/amdgpu:fix memleak

Nicolai Hähnle (1):
  drm/amdgpu/gfx9: implement wave VGPR reading

Rex Zhu (2):
  drm/amd/pp: fix dpm randomly failed on Vega10
  drm/amd/pp: fix typecast error in powerplay.

Rob Clark (1):
  dt-bindings: remove file that was added accidentally

Roger He (2):
  drm/amd/amdgpu: if visible VRAM allocation fail, fall back to
invisible try again
  drm/amd/amdgpu: fix over-bound accessing in amdgpu_cs_wait_any_fence

Stefan Agner (2):
  drm/fsl-dcu: avoid disabling pixel clock twice on suspend
  drm/fsl-dcu: enable IRQ before drm_atomic_helper_resume()

Thierry Reding (1):
  drm/tegra: sor: Reimplement pad clock

Tom St Denis (1):
  drm/amd/amdgpu: Fix wave mask in amdgpu_debugfs_wave_read() (v2)

Wang Hongcheng (1):
  drm/amdgpu: fix rmmod KCQ disable failed error

Xiangliang.Yu (1):
  drm/amdgpu: fix kernel hang when starting VNC server

ozeng (1):
  drm/amdgpu: Properly allocate VM invalidate eng v2

 .../bindings/display/imx/fsl-imx-drm.txt   |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c   |   6 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  43 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|  15 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c|   6 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |   4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c  |   3 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|   2 -
 

[git pull] drm for v4.15 (fixes/cleanups/one small feature)

[Dave Airlie]

Hi Linus,

This is just some bits and pieces for the second half of the merge window,

1. Remove the MSM dt-bindings file Rob managed to push in the previous pull.
2. Add a property/edid quirk to denote HMD devices, I had these
hanging around for a few weeks and Keith had done some work on them,
they are fairly self contained and small, and only affect people using
HTC Vive VR headsets so far.
3. amdgpu, tegra, tilcdc, fsl fixes
4. some imx-drm cleanups I missed, these seemed pretty small, and no
reason to hold off.

I have one TTM regression fix (fixes bochs-vga in qemu) sitting
locally awaiting review I'll probably send that in a separate pull
request tomorrow.

Dave.

The following changes since commit f150891fd9878ef0d9197c4e8451ce67c3bdd014:

  Merge tag 'exynos-drm-next-for-v4.15' of
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into
drm-next (2017-11-14 14:12:43 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-for-v4.15-part2

for you to fetch changes up to 98ecf1a308977505381b5c360b039a84cf67513c:

  dt-bindings: remove file that was added accidentally (2017-11-23
14:10:39 +1000)


fixes/cleanups for rc1, non-desktop flags for VR


Alex Deucher (2):
  Revert "drm/radeon: dont switch vt on suspend"
  drm/amdgpu: don't skip attributes when powerplay is enabled

Christian König (2):
  drm/amdgpu: make AMDGPU_VA_RESERVED_SIZE 64bit
  drm/amdgpu: set f_mapping on exported DMA-bufs

Cihangir Akturk (1):
  drm/imx: switch to drm_*_get(), drm_*_put() helpers

Colin Ian King (1):
  drm/amd/powerplay: fix copy-n-paste error on vddci_buf index

Dave Airlie (9):
  Merge branch 'drm-next-4.15' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'drm-fsl-dcu-fixes-for-v4.15' of
http://git.agner.ch/git/linux-drm-fsl-dcu into drm-next
  Merge tag 'drm/tegra/for-4.15-rc1-fixes' of
git://anongit.freedesktop.org/tegra/linux into drm-next
  Merge tag 'imx-drm-next-2017-10-18' of
git://git.pengutronix.de/git/pza/linux into drm-next
  Merge branch 'drm-next-4.15' of
git://people.freedesktop.org/~agd5f/linux into drm-next
  Merge tag 'tilcdc-4.15-fixes' of https://github.com/jsarha/linux
into drm-next
  drm: add connector info/property for non-desktop displays [v2]
  drm/fb: add support for not enabling fbcon on non-desktop displays [v2]
  drm/edid: quirk HTC vive headset as non-desktop. [v2]

Emily Deng (1):
  drm/amdgpu: Fix null pointer issue in amdgpu_cs_wait_any_fence

Eric Huang (1):
  drm/amd/powerplay: fix unfreeze level smc message for smu7

Fabio Estevam (1):
  gpu: ipu-v3: ipu-dc: Remove unused 'di' variable

Jyri Sarha (1):
  drm/tilcdc: Remove obsolete "ti,tilcdc,slave" dts binding support

Ken Wang (2):
  drm/amdgpu: Remove check which is not valid for certain VBIOS
  drm/amdgpu: Add common golden settings for GFX9

Laurent Pinchart (1):
  drm/fsl-dcu: Don't set connector DPMS property

Lucas Stach (1):
  drm/imx: parallel-display: use correct connector enum

Marco Franchi (1):
  dt-bindings: fsl-imx-drm: Remove incorrect "@di0" usage

Monk Liu (2):
  drm/amdgpu:fix memleak in takedown
  drm/amdgpu:fix memleak

Nicolai Hähnle (1):
  drm/amdgpu/gfx9: implement wave VGPR reading

Rex Zhu (2):
  drm/amd/pp: fix dpm randomly failed on Vega10
  drm/amd/pp: fix typecast error in powerplay.

Rob Clark (1):
  dt-bindings: remove file that was added accidentally

Roger He (2):
  drm/amd/amdgpu: if visible VRAM allocation fail, fall back to
invisible try again
  drm/amd/amdgpu: fix over-bound accessing in amdgpu_cs_wait_any_fence

Stefan Agner (2):
  drm/fsl-dcu: avoid disabling pixel clock twice on suspend
  drm/fsl-dcu: enable IRQ before drm_atomic_helper_resume()

Thierry Reding (1):
  drm/tegra: sor: Reimplement pad clock

Tom St Denis (1):
  drm/amd/amdgpu: Fix wave mask in amdgpu_debugfs_wave_read() (v2)

Wang Hongcheng (1):
  drm/amdgpu: fix rmmod KCQ disable failed error

Xiangliang.Yu (1):
  drm/amdgpu: fix kernel hang when starting VNC server

ozeng (1):
  drm/amdgpu: Properly allocate VM invalidate eng v2

 .../bindings/display/imx/fsl-imx-drm.txt   |   2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_bios.c   |   6 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c |   7 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  43 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|  15 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c|   6 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |   4 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_powerplay.c  |   3 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_prime.c  |   6 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c|   2 -
 

Re: [git pull] drm for v4.15

[Nicolai Hähnle]

On 17.11.2017 20:18, Christian König wrote:
The obvious alternative which we are working on for a few years now is 
to improve the input data we get from the hardware people.


In other words instead of getting a flat list of registers we want the 
information about where and how many times a hardware block was 
instantiated.


But getting that proved much more difficult than we thought and yes we 
are working on that for multiple years now.


Well, the good news is that at least for the gfx registers, I actually 
have a proof-of-concept script that extracts the required information 
from the hardware sources. Generating e.g. a CB_COLOR_INFO(x) macro 
instead of CB_COLORx_INFO defines from that is not that hard :)


The real challenge is getting this integrated into the right processes 
so we don't have as much of a maintenance burden.


Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.

Re: [git pull] drm for v4.15

[Nicolai Hähnle]

On 17.11.2017 20:18, Christian König wrote:
The obvious alternative which we are working on for a few years now is 
to improve the input data we get from the hardware people.


In other words instead of getting a flat list of registers we want the 
information about where and how many times a hardware block was 
instantiated.


But getting that proved much more difficult than we thought and yes we 
are working on that for multiple years now.


Well, the good news is that at least for the gfx registers, I actually 
have a proof-of-concept script that extracts the required information 
from the hardware sources. Generating e.g. a CB_COLOR_INFO(x) macro 
instead of CB_COLORx_INFO defines from that is not that hard :)


The real challenge is getting this integrated into the right processes 
so we don't have as much of a maintenance burden.


Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.

Re: [git pull] drm for v4.15

[Christian König]

Am 17.11.2017 um 19:55 schrieb Linus Torvalds:

On Fri, Nov 17, 2017 at 10:14 AM, Christian König
 wrote:

Taking an example from the AMD headers why this automation is more tricky
than it sounds in the first place: Look at the
mmVM_CONTEXT*_PAGE_TABLE_BASE_ADDR registers for example.

Register 0-7 are consecutive and so could be perfectly addressable with an
index, but register 8-15 aren't and so we always end with logic like if(i<8)
... else 

The rational from the hardware guys is obvious that they initially had only
8 and on a later hardware generation extended that to 16 registers.

Heh. I don't disagree, but at the same time, that case is actually a
wonderful example.

Let's take the gmc_6_0 case, because it shows your irregularity, but
it also shows another horrid example of nasty nasty automation:

   mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR 0x054F
   mmVM_CONTEXT10_PAGE_TABLE_BASE_ADDR 0x0510
   mmVM_CONTEXT11_PAGE_TABLE_BASE_ADDR 0x0511
   mmVM_CONTEXT12_PAGE_TABLE_BASE_ADDR 0x0512
   mmVM_CONTEXT13_PAGE_TABLE_BASE_ADDR 0x0513
   mmVM_CONTEXT14_PAGE_TABLE_BASE_ADDR 0x0514
   mmVM_CONTEXT15_PAGE_TABLE_BASE_ADDR 0x0515
   mmVM_CONTEXT1_PAGE_TABLE_BASE_ADDR 0x0550
   mmVM_CONTEXT2_PAGE_TABLE_BASE_ADDR 0x0551
   mmVM_CONTEXT3_PAGE_TABLE_BASE_ADDR 0x0552
   mmVM_CONTEXT4_PAGE_TABLE_BASE_ADDR 0x0553
   mmVM_CONTEXT5_PAGE_TABLE_BASE_ADDR 0x0554
   mmVM_CONTEXT6_PAGE_TABLE_BASE_ADDR 0x0555
   mmVM_CONTEXT7_PAGE_TABLE_BASE_ADDR 0x0556
   mmVM_CONTEXT8_PAGE_TABLE_BASE_ADDR 0x050E
   mmVM_CONTEXT9_PAGE_TABLE_BASE_ADDR 0x050F

Oops. Those were clearly sorted automatically, and in entirely the wrong way.

So automation has _really_ done something inexcusably stupid, and made
the end result completely illegible in the process.


Yeah, but that is already the input we get from the hardware teams. E.g. 
in this case a list of registers sorted by their name or address (or 
even sometimes some hardware internal magic).


There isn't much we could do about that except for manual or semi 
manually cleaning up the mess.



And yes, you'd be right that it's discontiguous at 8, but it's still
arithmetic, ie you could easily have

  #define  mmVM_PAGE_TABLE_BASE_ADDR(ctx) \
 ((ctx)+0x054f-((ctx) & 8)*9-((ctx)&8)/8)

and if "ctx" is a constant, then the end result is trivially a
constant and can be used as such. And if it isn't, it's still a much
cheaper operation than an "if" or "switch ()" statement (it's just a
bitmask and two shifts).


Interesting approach, but it is not so performance critical. So I would 
still go with the "if" or "?" operator just for the improved readability.



Now, seeing those patterns is likely not something that automation
should do (although it's definitely possible - superoptimizers do that
all the time), but automation could still *verify* the patterns once a
human has made them up.


Well, this was just a rather simple example, the real problem is that 
some blocks have a dozen instances and >10k registers each.


Manual intervention is just completely out of question when applied to 
the general problem.


What we need is some automation, but as you wrote as well that is 
possible but far from easy.



And it's quite possible that it would be a good idea to encode that
pattern even in the original source code. In fact, it may *be* there
somewhere (not as that arithmetic expression, but as the reverse
decode logic, obviously).


The obvious alternative which we are working on for a few years now is 
to improve the input data we get from the hardware people.


In other words instead of getting a flat list of registers we want the 
information about where and how many times a hardware block was 
instantiated.


But getting that proved much more difficult than we thought and yes we 
are working on that for multiple years now.


Regards,
Christian.

Re: [git pull] drm for v4.15

[Christian König]

Am 17.11.2017 um 19:55 schrieb Linus Torvalds:

On Fri, Nov 17, 2017 at 10:14 AM, Christian König
 wrote:

Taking an example from the AMD headers why this automation is more tricky
than it sounds in the first place: Look at the
mmVM_CONTEXT*_PAGE_TABLE_BASE_ADDR registers for example.

Register 0-7 are consecutive and so could be perfectly addressable with an
index, but register 8-15 aren't and so we always end with logic like if(i<8)
... else 

The rational from the hardware guys is obvious that they initially had only
8 and on a later hardware generation extended that to 16 registers.

Heh. I don't disagree, but at the same time, that case is actually a
wonderful example.

Let's take the gmc_6_0 case, because it shows your irregularity, but
it also shows another horrid example of nasty nasty automation:

   mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR 0x054F
   mmVM_CONTEXT10_PAGE_TABLE_BASE_ADDR 0x0510
   mmVM_CONTEXT11_PAGE_TABLE_BASE_ADDR 0x0511
   mmVM_CONTEXT12_PAGE_TABLE_BASE_ADDR 0x0512
   mmVM_CONTEXT13_PAGE_TABLE_BASE_ADDR 0x0513
   mmVM_CONTEXT14_PAGE_TABLE_BASE_ADDR 0x0514
   mmVM_CONTEXT15_PAGE_TABLE_BASE_ADDR 0x0515
   mmVM_CONTEXT1_PAGE_TABLE_BASE_ADDR 0x0550
   mmVM_CONTEXT2_PAGE_TABLE_BASE_ADDR 0x0551
   mmVM_CONTEXT3_PAGE_TABLE_BASE_ADDR 0x0552
   mmVM_CONTEXT4_PAGE_TABLE_BASE_ADDR 0x0553
   mmVM_CONTEXT5_PAGE_TABLE_BASE_ADDR 0x0554
   mmVM_CONTEXT6_PAGE_TABLE_BASE_ADDR 0x0555
   mmVM_CONTEXT7_PAGE_TABLE_BASE_ADDR 0x0556
   mmVM_CONTEXT8_PAGE_TABLE_BASE_ADDR 0x050E
   mmVM_CONTEXT9_PAGE_TABLE_BASE_ADDR 0x050F

Oops. Those were clearly sorted automatically, and in entirely the wrong way.

So automation has _really_ done something inexcusably stupid, and made
the end result completely illegible in the process.


Yeah, but that is already the input we get from the hardware teams. E.g. 
in this case a list of registers sorted by their name or address (or 
even sometimes some hardware internal magic).


There isn't much we could do about that except for manual or semi 
manually cleaning up the mess.



And yes, you'd be right that it's discontiguous at 8, but it's still
arithmetic, ie you could easily have

  #define  mmVM_PAGE_TABLE_BASE_ADDR(ctx) \
 ((ctx)+0x054f-((ctx) & 8)*9-((ctx)&8)/8)

and if "ctx" is a constant, then the end result is trivially a
constant and can be used as such. And if it isn't, it's still a much
cheaper operation than an "if" or "switch ()" statement (it's just a
bitmask and two shifts).


Interesting approach, but it is not so performance critical. So I would 
still go with the "if" or "?" operator just for the improved readability.



Now, seeing those patterns is likely not something that automation
should do (although it's definitely possible - superoptimizers do that
all the time), but automation could still *verify* the patterns once a
human has made them up.


Well, this was just a rather simple example, the real problem is that 
some blocks have a dozen instances and >10k registers each.


Manual intervention is just completely out of question when applied to 
the general problem.


What we need is some automation, but as you wrote as well that is 
possible but far from easy.



And it's quite possible that it would be a good idea to encode that
pattern even in the original source code. In fact, it may *be* there
somewhere (not as that arithmetic expression, but as the reverse
decode logic, obviously).


The obvious alternative which we are working on for a few years now is 
to improve the input data we get from the hardware people.


In other words instead of getting a flat list of registers we want the 
information about where and how many times a hardware block was 
instantiated.


But getting that proved much more difficult than we thought and yes we 
are working on that for multiple years now.


Regards,
Christian.

Re: [git pull] drm for v4.15

[Linus Torvalds]

On Fri, Nov 17, 2017 at 10:14 AM, Christian König
 wrote:
>
> Taking an example from the AMD headers why this automation is more tricky
> than it sounds in the first place: Look at the
> mmVM_CONTEXT*_PAGE_TABLE_BASE_ADDR registers for example.
>
> Register 0-7 are consecutive and so could be perfectly addressable with an
> index, but register 8-15 aren't and so we always end with logic like if(i<8)
> ... else 
>
> The rational from the hardware guys is obvious that they initially had only
> 8 and on a later hardware generation extended that to 16 registers.

Heh. I don't disagree, but at the same time, that case is actually a
wonderful example.

Let's take the gmc_6_0 case, because it shows your irregularity, but
it also shows another horrid example of nasty nasty automation:

  mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR 0x054F
  mmVM_CONTEXT10_PAGE_TABLE_BASE_ADDR 0x0510
  mmVM_CONTEXT11_PAGE_TABLE_BASE_ADDR 0x0511
  mmVM_CONTEXT12_PAGE_TABLE_BASE_ADDR 0x0512
  mmVM_CONTEXT13_PAGE_TABLE_BASE_ADDR 0x0513
  mmVM_CONTEXT14_PAGE_TABLE_BASE_ADDR 0x0514
  mmVM_CONTEXT15_PAGE_TABLE_BASE_ADDR 0x0515
  mmVM_CONTEXT1_PAGE_TABLE_BASE_ADDR 0x0550
  mmVM_CONTEXT2_PAGE_TABLE_BASE_ADDR 0x0551
  mmVM_CONTEXT3_PAGE_TABLE_BASE_ADDR 0x0552
  mmVM_CONTEXT4_PAGE_TABLE_BASE_ADDR 0x0553
  mmVM_CONTEXT5_PAGE_TABLE_BASE_ADDR 0x0554
  mmVM_CONTEXT6_PAGE_TABLE_BASE_ADDR 0x0555
  mmVM_CONTEXT7_PAGE_TABLE_BASE_ADDR 0x0556
  mmVM_CONTEXT8_PAGE_TABLE_BASE_ADDR 0x050E
  mmVM_CONTEXT9_PAGE_TABLE_BASE_ADDR 0x050F

Oops. Those were clearly sorted automatically, and in entirely the wrong way.

So automation has _really_ done something inexcusably stupid, and made
the end result completely illegible in the process.

And yes, you'd be right that it's discontiguous at 8, but it's still
arithmetic, ie you could easily have

 #define  mmVM_PAGE_TABLE_BASE_ADDR(ctx) \
((ctx)+0x054f-((ctx) & 8)*9-((ctx)&8)/8)

and if "ctx" is a constant, then the end result is trivially a
constant and can be used as such. And if it isn't, it's still a much
cheaper operation than an "if" or "switch ()" statement (it's just a
bitmask and two shifts).

Now, seeing those patterns is likely not something that automation
should do (although it's definitely possible - superoptimizers do that
all the time), but automation could still *verify* the patterns once a
human has made them up.

And it's quite possible that it would be a good idea to encode that
pattern even in the original source code. In fact, it may *be* there
somewhere (not as that arithmetic expression, but as the reverse
decode logic, obviously).

Linus

Re: [git pull] drm for v4.15

[Linus Torvalds]

On Fri, Nov 17, 2017 at 10:14 AM, Christian König
 wrote:
>
> Taking an example from the AMD headers why this automation is more tricky
> than it sounds in the first place: Look at the
> mmVM_CONTEXT*_PAGE_TABLE_BASE_ADDR registers for example.
>
> Register 0-7 are consecutive and so could be perfectly addressable with an
> index, but register 8-15 aren't and so we always end with logic like if(i<8)
> ... else 
>
> The rational from the hardware guys is obvious that they initially had only
> 8 and on a later hardware generation extended that to 16 registers.

Heh. I don't disagree, but at the same time, that case is actually a
wonderful example.

Let's take the gmc_6_0 case, because it shows your irregularity, but
it also shows another horrid example of nasty nasty automation:

  mmVM_CONTEXT0_PAGE_TABLE_BASE_ADDR 0x054F
  mmVM_CONTEXT10_PAGE_TABLE_BASE_ADDR 0x0510
  mmVM_CONTEXT11_PAGE_TABLE_BASE_ADDR 0x0511
  mmVM_CONTEXT12_PAGE_TABLE_BASE_ADDR 0x0512
  mmVM_CONTEXT13_PAGE_TABLE_BASE_ADDR 0x0513
  mmVM_CONTEXT14_PAGE_TABLE_BASE_ADDR 0x0514
  mmVM_CONTEXT15_PAGE_TABLE_BASE_ADDR 0x0515
  mmVM_CONTEXT1_PAGE_TABLE_BASE_ADDR 0x0550
  mmVM_CONTEXT2_PAGE_TABLE_BASE_ADDR 0x0551
  mmVM_CONTEXT3_PAGE_TABLE_BASE_ADDR 0x0552
  mmVM_CONTEXT4_PAGE_TABLE_BASE_ADDR 0x0553
  mmVM_CONTEXT5_PAGE_TABLE_BASE_ADDR 0x0554
  mmVM_CONTEXT6_PAGE_TABLE_BASE_ADDR 0x0555
  mmVM_CONTEXT7_PAGE_TABLE_BASE_ADDR 0x0556
  mmVM_CONTEXT8_PAGE_TABLE_BASE_ADDR 0x050E
  mmVM_CONTEXT9_PAGE_TABLE_BASE_ADDR 0x050F

Oops. Those were clearly sorted automatically, and in entirely the wrong way.

So automation has _really_ done something inexcusably stupid, and made
the end result completely illegible in the process.

And yes, you'd be right that it's discontiguous at 8, but it's still
arithmetic, ie you could easily have

 #define  mmVM_PAGE_TABLE_BASE_ADDR(ctx) \
((ctx)+0x054f-((ctx) & 8)*9-((ctx)&8)/8)

and if "ctx" is a constant, then the end result is trivially a
constant and can be used as such. And if it isn't, it's still a much
cheaper operation than an "if" or "switch ()" statement (it's just a
bitmask and two shifts).

Now, seeing those patterns is likely not something that automation
should do (although it's definitely possible - superoptimizers do that
all the time), but automation could still *verify* the patterns once a
human has made them up.

And it's quite possible that it would be a good idea to encode that
pattern even in the original source code. In fact, it may *be* there
somewhere (not as that arithmetic expression, but as the reverse
decode logic, obviously).

Linus

Re: [git pull] drm for v4.15

[Christian König]

First of all I can certainly agree with everything said so far, so just 
skipping to the technical problem.


Am 17.11.2017 um 17:57 schrieb Linus Torvalds:


People say "it's a ton of work to do it by hand". They'd be right. I'm
not saying you should do it by hand. But "automation" does not always
need to mean "completely mindlessly stupid" either.


Taking an example from the AMD headers why this automation is more 
tricky than it sounds in the first place: Look at the 
mmVM_CONTEXT*_PAGE_TABLE_BASE_ADDR registers for example.


Register 0-7 are consecutive and so could be perfectly addressable with 
an index, but register 8-15 aren't and so we always end with logic like 
if(i<8) ... else 


The rational from the hardware guys is obvious that they initially had 
only 8 and on a later hardware generation extended that to 16 registers.


Patterns like that repeat all over the place and are not limited to AMD 
at all.



We could write up hand written rules to sanitize all of that, but then 
we are back to "automatically" creating the headers by hand.


When you have to maintain 10+ years of hardware generations where 
sometimes registers headers even need to be regenerated from the 
database then that is something which won't fly either.



Certainly not saying that this is a bad idea, but we simply need better 
tools for that which also have 100% reproducible results.


Ideas welcome,
Christian.

Re: [git pull] drm for v4.15

[Christian König]

First of all I can certainly agree with everything said so far, so just 
skipping to the technical problem.


Am 17.11.2017 um 17:57 schrieb Linus Torvalds:


People say "it's a ton of work to do it by hand". They'd be right. I'm
not saying you should do it by hand. But "automation" does not always
need to mean "completely mindlessly stupid" either.


Taking an example from the AMD headers why this automation is more 
tricky than it sounds in the first place: Look at the 
mmVM_CONTEXT*_PAGE_TABLE_BASE_ADDR registers for example.


Register 0-7 are consecutive and so could be perfectly addressable with 
an index, but register 8-15 aren't and so we always end with logic like 
if(i<8) ... else 


The rational from the hardware guys is obvious that they initially had 
only 8 and on a later hardware generation extended that to 16 registers.


Patterns like that repeat all over the place and are not limited to AMD 
at all.



We could write up hand written rules to sanitize all of that, but then 
we are back to "automatically" creating the headers by hand.


When you have to maintain 10+ years of hardware generations where 
sometimes registers headers even need to be regenerated from the 
database then that is something which won't fly either.



Certainly not saying that this is a bad idea, but we simply need better 
tools for that which also have 100% reproducible results.


Ideas welcome,
Christian.

Re: [git pull] drm for v4.15

[Linus Torvalds]

On Fri, Nov 17, 2017 at 9:19 AM, Lukas Wunner  wrote:
>> and tell me that there isn't any room for making these things smarter.
>
> ... or deduplicate them. :-)

You could even - wait for it - have _automation_ that does it.

Yeah, it's easier to write a stupid sed-script or whatever to generate
those files. Taking patterns into account and making the output
smarter is harder, but still doesn't have to be manual. But wouldn't
it be good?

I bet it would be good for all those other OS's that want the header file too.

Linus

Re: [git pull] drm for v4.15

[Linus Torvalds]

On Fri, Nov 17, 2017 at 9:19 AM, Lukas Wunner  wrote:
>> and tell me that there isn't any room for making these things smarter.
>
> ... or deduplicate them. :-)

You could even - wait for it - have _automation_ that does it.

Yeah, it's easier to write a stupid sed-script or whatever to generate
those files. Taking patterns into account and making the output
smarter is harder, but still doesn't have to be manual. But wouldn't
it be good?

I bet it would be good for all those other OS's that want the header file too.

Linus

Re: [git pull] drm for v4.15

[Lukas Wunner]

On Fri, Nov 17, 2017 at 08:57:53AM -0800, Linus Torvalds wrote:
> On Fri, Nov 17, 2017 at 4:51 AM, Nicolai Hähnle  wrote:
> To see the effects of this, I picked something at random from one of
> those huge AMD header files.
> 
> I swear. It was entirely at random, and the first thing I picked. Do this:
> 
> git grep PCIE_UNCORR_ERR_MASK

Oh that looks familiar, it's the Uncorrectable Error Mask Register
(PCIe Base Spec r2.1 page 558).  We already have those definitions
in the tree in include/uapi/linux/pci_regs.h:

  git grep PCI_ERR_UNC_


> and tell me that there isn't any room for making these things smarter.

... or deduplicate them. :-)

Lukas

Re: [git pull] drm for v4.15

[Lukas Wunner]

On Fri, Nov 17, 2017 at 08:57:53AM -0800, Linus Torvalds wrote:
> On Fri, Nov 17, 2017 at 4:51 AM, Nicolai Hähnle  wrote:
> To see the effects of this, I picked something at random from one of
> those huge AMD header files.
> 
> I swear. It was entirely at random, and the first thing I picked. Do this:
> 
> git grep PCIE_UNCORR_ERR_MASK

Oh that looks familiar, it's the Uncorrectable Error Mask Register
(PCIe Base Spec r2.1 page 558).  We already have those definitions
in the tree in include/uapi/linux/pci_regs.h:

  git grep PCI_ERR_UNC_


> and tell me that there isn't any room for making these things smarter.

... or deduplicate them. :-)

Lukas

Re: [git pull] drm for v4.15

[Linus Torvalds]

On Fri, Nov 17, 2017 at 4:51 AM, Nicolai Hähnle  wrote:
>
> This raises the question of how people feel about putting the source
> database into the kernel (most likely as XML in our case) and
> auto-generating the headers from there instead.

I suspect that at  least in some cases, the "source" database may be a
bit too sensitive. It may have various comments about errata, and may
even be part of the whole hardware build system (ie it might be munged
from verilog/vhdl)

> I've been pondering doing this in Mesa for radeonsi for quite some time now.

What personally annoys me most about a lot of generated header files
(not all, but a _lot_) is that exactly because they are generated,
they are often inexcusably stupid.

So say that you have a block of status registers, all of which have a
certain base pattern. Every single auto-generated header file I have
ever seen takes the brute-force approach of just enumerating them all
separately as independent things.

Which makes the header file a huge mess of repeated almost-identical
register defines.

But it's not even the _size_ of the header file that then annoys me,
it's that it's not just big, but inflexible. Often, on a source level,
you may actually be in the situation where you get an index to the
thing, and then you do

switch (index) {
case X:
access_using(REGISTERX_DEFINITION);
case Y:
access_using(REGISTERY_DEFINITION);
   ...

or similar. When a _smarter_ auto-generated file would actually take
advantage of the language features (whether preprocessor or dynamic),
and actually allow for

access_using(REGISTER_DEFINITION(index))

instead.

Or - a variation of the above - it's not that the register definitions
for _one_ core have that kind of regularity, but you have it for a
while family of products, and because you autogenerate, you
auto-generate the stupid "repat the exact same thing with different
names" model, and then you have (instead of the index thing) you have
the "chip family" thing that you switch on.

To see the effects of this, I picked something at random from one of
those huge AMD header files.

I swear. It was entirely at random, and the first thing I picked. Do this:

git grep PCIE_UNCORR_ERR_MASK

and tell me that there isn't any room for making these things smarter.

Btw, not a single of those defines are actually _used_.  Again, that
pattern was entirely randomly picked from the largest header file we
have.

People say "it's a ton of work to do it by hand". They'd be right. I'm
not saying you should do it by hand. But "automation" does not always
need to mean "completely mindlessly stupid" either.

 Linus

Re: [git pull] drm for v4.15

[Linus Torvalds]

On Fri, Nov 17, 2017 at 4:51 AM, Nicolai Hähnle  wrote:
>
> This raises the question of how people feel about putting the source
> database into the kernel (most likely as XML in our case) and
> auto-generating the headers from there instead.

I suspect that at  least in some cases, the "source" database may be a
bit too sensitive. It may have various comments about errata, and may
even be part of the whole hardware build system (ie it might be munged
from verilog/vhdl)

> I've been pondering doing this in Mesa for radeonsi for quite some time now.

What personally annoys me most about a lot of generated header files
(not all, but a _lot_) is that exactly because they are generated,
they are often inexcusably stupid.

So say that you have a block of status registers, all of which have a
certain base pattern. Every single auto-generated header file I have
ever seen takes the brute-force approach of just enumerating them all
separately as independent things.

Which makes the header file a huge mess of repeated almost-identical
register defines.

But it's not even the _size_ of the header file that then annoys me,
it's that it's not just big, but inflexible. Often, on a source level,
you may actually be in the situation where you get an index to the
thing, and then you do

switch (index) {
case X:
access_using(REGISTERX_DEFINITION);
case Y:
access_using(REGISTERY_DEFINITION);
   ...

or similar. When a _smarter_ auto-generated file would actually take
advantage of the language features (whether preprocessor or dynamic),
and actually allow for

access_using(REGISTER_DEFINITION(index))

instead.

Or - a variation of the above - it's not that the register definitions
for _one_ core have that kind of regularity, but you have it for a
while family of products, and because you autogenerate, you
auto-generate the stupid "repat the exact same thing with different
names" model, and then you have (instead of the index thing) you have
the "chip family" thing that you switch on.

To see the effects of this, I picked something at random from one of
those huge AMD header files.

I swear. It was entirely at random, and the first thing I picked. Do this:

git grep PCIE_UNCORR_ERR_MASK

and tell me that there isn't any room for making these things smarter.

Btw, not a single of those defines are actually _used_.  Again, that
pattern was entirely randomly picked from the largest header file we
have.

People say "it's a ton of work to do it by hand". They'd be right. I'm
not saying you should do it by hand. But "automation" does not always
need to mean "completely mindlessly stupid" either.

 Linus

Re: [git pull] drm for v4.15

[Nicolai Hähnle]

On 16.11.2017 21:57, Dave Airlie wrote:

On 16 November 2017 at 14:59, Linus Torvalds
 wrote:

On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie  wrote:


There is some code touched on sound/soc, but I think the sound tree
should have the same commits from the same base,so this may luck different
if you pulled it as I generated my pull request a couple of days ago. Otherwise
the highlights are below.


I'm more curious about (and disgusted by) this one:

   include/dt-bindings/msm/msm-bus-ids.h

wtf? It's full of defines that aren't actually used anywhere.  Which
is just as well, since it doesn't seem to be included from anything
either.

There's something odd about drm people. You guys like these completely
insane generated header files, and you seem to be populating the whole
tree with this odd and diseased notion of "generated header files are
cool".

Is somebody getting paid by line of code?


It would still cost less than transcribing each register and all it's fields by
hand from pdfs generated from the same place.


This raises the question of how people feel about putting the source 
database into the kernel (most likely as XML in our case) and 
auto-generating the headers from there instead.


I've been pondering doing this in Mesa for radeonsi for quite some time 
now. Given that the Mesa header style is different from the kernel 
header style, this could help reduce our IP review load going forward, 
and would have some other neat benefits as well.


Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.

Re: [git pull] drm for v4.15

[Nicolai Hähnle]

On 16.11.2017 21:57, Dave Airlie wrote:

On 16 November 2017 at 14:59, Linus Torvalds
 wrote:

On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie  wrote:


There is some code touched on sound/soc, but I think the sound tree
should have the same commits from the same base,so this may luck different
if you pulled it as I generated my pull request a couple of days ago. Otherwise
the highlights are below.


I'm more curious about (and disgusted by) this one:

   include/dt-bindings/msm/msm-bus-ids.h

wtf? It's full of defines that aren't actually used anywhere.  Which
is just as well, since it doesn't seem to be included from anything
either.

There's something odd about drm people. You guys like these completely
insane generated header files, and you seem to be populating the whole
tree with this odd and diseased notion of "generated header files are
cool".

Is somebody getting paid by line of code?


It would still cost less than transcribing each register and all it's fields by
hand from pdfs generated from the same place.


This raises the question of how people feel about putting the source 
database into the kernel (most likely as XML in our case) and 
auto-generating the headers from there instead.


I've been pondering doing this in Mesa for radeonsi for quite some time 
now. Given that the Mesa header style is different from the kernel 
header style, this could help reduce our IP review load going forward, 
and would have some other neat benefits as well.


Cheers,
Nicolai
--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.

Re: [git pull] drm for v4.15

[Linus Torvalds]

On Thu, Nov 16, 2017 at 12:57 PM, Dave Airlie  wrote:
>
> This sounds more like a Monty Python sketch than a serious question.

It's a serious question when the files start appearing in random
places where they don't belong.

There's a place for automatically generated files.

But that "there is a place" very much also implies that they shouldn't
be all over the tree.

  Linus

Re: [git pull] drm for v4.15

[Linus Torvalds]

On Thu, Nov 16, 2017 at 12:57 PM, Dave Airlie  wrote:
>
> This sounds more like a Monty Python sketch than a serious question.

It's a serious question when the files start appearing in random
places where they don't belong.

There's a place for automatically generated files.

But that "there is a place" very much also implies that they shouldn't
be all over the tree.

  Linus

Re: [git pull] drm for v4.15

[Dave Airlie]

On 16 November 2017 at 14:59, Linus Torvalds
 wrote:
> On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie  wrote:
>>
>> There is some code touched on sound/soc, but I think the sound tree
>> should have the same commits from the same base,so this may luck different
>> if you pulled it as I generated my pull request a couple of days ago. 
>> Otherwise
>> the highlights are below.
>
> I'm more curious about (and disgusted by) this one:
>
>   include/dt-bindings/msm/msm-bus-ids.h
>
> wtf? It's full of defines that aren't actually used anywhere.  Which
> is just as well, since it doesn't seem to be included from anything
> either.
>
> There's something odd about drm people. You guys like these completely
> insane generated header files, and you seem to be populating the whole
> tree with this odd and diseased notion of "generated header files are
> cool".
>
> Is somebody getting paid by line of code?

It would still cost less than transcribing each register and all it's fields by
hand from pdfs generated from the same place.

This sounds more like a Monty Python sketch than a serious question. (In
my day we hard transcribed 1000s of register by hand before breakfast, and
then we ate the pdf printouts for breakfast).

The sheer size of those headers should be proof enough that they shouldn't
be handcrafted.

Next thing you'll be telling people to get off your lawn!

But this seems like Rob dropped the ball, he's no longer allowed run
git add without
passing every filename by hand, and I probably should have noticed
when I pulled it
but an 887 line register header file is quite small in a
+65,000,-56000 pull req.

Dave.

Re: [git pull] drm for v4.15

[Dave Airlie]

On 16 November 2017 at 14:59, Linus Torvalds
 wrote:
> On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie  wrote:
>>
>> There is some code touched on sound/soc, but I think the sound tree
>> should have the same commits from the same base,so this may luck different
>> if you pulled it as I generated my pull request a couple of days ago. 
>> Otherwise
>> the highlights are below.
>
> I'm more curious about (and disgusted by) this one:
>
>   include/dt-bindings/msm/msm-bus-ids.h
>
> wtf? It's full of defines that aren't actually used anywhere.  Which
> is just as well, since it doesn't seem to be included from anything
> either.
>
> There's something odd about drm people. You guys like these completely
> insane generated header files, and you seem to be populating the whole
> tree with this odd and diseased notion of "generated header files are
> cool".
>
> Is somebody getting paid by line of code?

It would still cost less than transcribing each register and all it's fields by
hand from pdfs generated from the same place.

This sounds more like a Monty Python sketch than a serious question. (In
my day we hard transcribed 1000s of register by hand before breakfast, and
then we ate the pdf printouts for breakfast).

The sheer size of those headers should be proof enough that they shouldn't
be handcrafted.

Next thing you'll be telling people to get off your lawn!

But this seems like Rob dropped the ball, he's no longer allowed run
git add without
passing every filename by hand, and I probably should have noticed
when I pulled it
but an 887 line register header file is quite small in a
+65,000,-56000 pull req.

Dave.

Re: [git pull] drm for v4.15

[Michel Dänzer]

On 16/11/17 05:59 AM, Linus Torvalds wrote:
> 
> There's something odd about drm people. You guys like these completely
> insane generated header files, and you seem to be populating the whole
> tree with this odd and diseased notion of "generated header files are
> cool".
> 
> Is somebody getting paid by line of code?

At least in the case of amdgpu, it's more like nobody's getting paid to
write/maintain register header files by hand full-time. I hope you can
agree nobody should have to do that.

The headers are generated from the same database used for other OSes,
which minimizes the potential for error. We used hand-written headers in
the radeon driver, and there was a fair number of bugs due to subtle
errors in them.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [git pull] drm for v4.15

[Michel Dänzer]

On 16/11/17 05:59 AM, Linus Torvalds wrote:
> 
> There's something odd about drm people. You guys like these completely
> insane generated header files, and you seem to be populating the whole
> tree with this odd and diseased notion of "generated header files are
> cool".
> 
> Is somebody getting paid by line of code?

At least in the case of amdgpu, it's more like nobody's getting paid to
write/maintain register header files by hand full-time. I hope you can
agree nobody should have to do that.

The headers are generated from the same database used for other OSes,
which minimizes the potential for error. We used hand-written headers in
the radeon driver, and there was a fair number of bugs due to subtle
errors in them.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer

Re: [git pull] drm for v4.15

[Rob Clark]

On Wed, Nov 15, 2017 at 11:59 PM, Linus Torvalds
 wrote:
> On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie  wrote:
>>
>> There is some code touched on sound/soc, but I think the sound tree
>> should have the same commits from the same base,so this may luck different
>> if you pulled it as I generated my pull request a couple of days ago. 
>> Otherwise
>> the highlights are below.
>
> I'm more curious about (and disgusted by) this one:
>
>   include/dt-bindings/msm/msm-bus-ids.h
>
> wtf? It's full of defines that aren't actually used anywhere.  Which
> is just as well, since it doesn't seem to be included from anything
> either.

Yeah, that shouldn't be there and should be removed.. I think it is my
bad.  The patch that introduced it didn't cherry pick cleanly when I
was pulling things into msm-next, so patch -p1 + git-add (which pulled
it in by mistake).  I'll send a patch to remove it.

BR,
-R

> There's something odd about drm people. You guys like these completely
> insane generated header files, and you seem to be populating the whole
> tree with this odd and diseased notion of "generated header files are
> cool".
>
> Is somebody getting paid by line of code?
>
> Yeah, yeah, we have those nasty dt-bindings heades from before too,
> but this one is one of the bigger ones, and it really comes with no
> explanation, and a commit message that doesn't really mention
> device-tree at all.
>
> Honestly, it seems like it got committed by mistake.
>
> I've pulled it, but Christ on a stick!
>
>   Linus

Re: [git pull] drm for v4.15

[Rob Clark]

On Wed, Nov 15, 2017 at 11:59 PM, Linus Torvalds
 wrote:
> On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie  wrote:
>>
>> There is some code touched on sound/soc, but I think the sound tree
>> should have the same commits from the same base,so this may luck different
>> if you pulled it as I generated my pull request a couple of days ago. 
>> Otherwise
>> the highlights are below.
>
> I'm more curious about (and disgusted by) this one:
>
>   include/dt-bindings/msm/msm-bus-ids.h
>
> wtf? It's full of defines that aren't actually used anywhere.  Which
> is just as well, since it doesn't seem to be included from anything
> either.

Yeah, that shouldn't be there and should be removed.. I think it is my
bad.  The patch that introduced it didn't cherry pick cleanly when I
was pulling things into msm-next, so patch -p1 + git-add (which pulled
it in by mistake).  I'll send a patch to remove it.

BR,
-R

> There's something odd about drm people. You guys like these completely
> insane generated header files, and you seem to be populating the whole
> tree with this odd and diseased notion of "generated header files are
> cool".
>
> Is somebody getting paid by line of code?
>
> Yeah, yeah, we have those nasty dt-bindings heades from before too,
> but this one is one of the bigger ones, and it really comes with no
> explanation, and a commit message that doesn't really mention
> device-tree at all.
>
> Honestly, it seems like it got committed by mistake.
>
> I've pulled it, but Christ on a stick!
>
>   Linus

Re: [git pull] drm for v4.15

[Linus Torvalds]

On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie  wrote:
>
> There is some code touched on sound/soc, but I think the sound tree
> should have the same commits from the same base,so this may luck different
> if you pulled it as I generated my pull request a couple of days ago. 
> Otherwise
> the highlights are below.

I'm more curious about (and disgusted by) this one:

  include/dt-bindings/msm/msm-bus-ids.h

wtf? It's full of defines that aren't actually used anywhere.  Which
is just as well, since it doesn't seem to be included from anything
either.

There's something odd about drm people. You guys like these completely
insane generated header files, and you seem to be populating the whole
tree with this odd and diseased notion of "generated header files are
cool".

Is somebody getting paid by line of code?

Yeah, yeah, we have those nasty dt-bindings heades from before too,
but this one is one of the bigger ones, and it really comes with no
explanation, and a commit message that doesn't really mention
device-tree at all.

Honestly, it seems like it got committed by mistake.

I've pulled it, but Christ on a stick!

  Linus

Re: [git pull] drm for v4.15

[Linus Torvalds]

On Wed, Nov 15, 2017 at 6:34 PM, Dave Airlie  wrote:
>
> There is some code touched on sound/soc, but I think the sound tree
> should have the same commits from the same base,so this may luck different
> if you pulled it as I generated my pull request a couple of days ago. 
> Otherwise
> the highlights are below.

I'm more curious about (and disgusted by) this one:

  include/dt-bindings/msm/msm-bus-ids.h

wtf? It's full of defines that aren't actually used anywhere.  Which
is just as well, since it doesn't seem to be included from anything
either.

There's something odd about drm people. You guys like these completely
insane generated header files, and you seem to be populating the whole
tree with this odd and diseased notion of "generated header files are
cool".

Is somebody getting paid by line of code?

Yeah, yeah, we have those nasty dt-bindings heades from before too,
but this one is one of the bigger ones, and it really comes with no
explanation, and a commit message that doesn't really mention
device-tree at all.

Honestly, it seems like it got committed by mistake.

I've pulled it, but Christ on a stick!

  Linus