Re: [git pull] drm for v4.11 - main pull request

2017-02-24 Thread Daniel Vetter 
Hi Linus,

Yeah this went wrong. My experience with anything Kconfig (whether new
drivers or anything else) is that it takes 0day a few days to 1-2 weeks to
crunch through all the combos. I guess we could block new drivers pulls
like we already do with regular feature pulls in drm (e.g. drm-intel.git
cuts out around -rc5/6-ish, drm-misc.git works similar), but delaying
new drivers isn't that great.

On Thu, Feb 23, 2017 at 05:44:04PM -0800, Linus Torvalds wrote:
> [snip]

Don't shit on (new) contributors like this. Noralf has done good work (go
look), Kconfig is an impossible combinatorial maze, and I'd be rather
annoyed if you managed to drive away Noralf (and other contributors) with
your mail.

I know that you need to rage every once in a while, but at least only send
those mails to Dave (and me) in private. On dri-devel here, this isn't
accepted.

We'll discuss late driver pull requests and what to with them in drm in
the future more after -rc1, after the heat has dissipated.

Yours, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [git pull] drm for v4.11 - main pull request

2017-02-24 Thread Daniel Vetter 
Hi Linus,

Yeah this went wrong. My experience with anything Kconfig (whether new
drivers or anything else) is that it takes 0day a few days to 1-2 weeks to
crunch through all the combos. I guess we could block new drivers pulls
like we already do with regular feature pulls in drm (e.g. drm-intel.git
cuts out around -rc5/6-ish, drm-misc.git works similar), but delaying
new drivers isn't that great.

On Thu, Feb 23, 2017 at 05:44:04PM -0800, Linus Torvalds wrote:
> [snip]

Don't shit on (new) contributors like this. Noralf has done good work (go
look), Kconfig is an impossible combinatorial maze, and I'd be rather
annoyed if you managed to drive away Noralf (and other contributors) with
your mail.

I know that you need to rage every once in a while, but at least only send
those mails to Dave (and me) in private. On dri-devel here, this isn't
accepted.

We'll discuss late driver pull requests and what to with them in drm in
the future more after -rc1, after the heat has dissipated.

Yours, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [git pull] drm for v4.11 - main pull request

2017-02-23 Thread Linus Torvalds 
On Thu, Feb 23, 2017 at 5:44 PM, Linus Torvalds
 wrote:
>
> AND WHY THE HELL WAS THIS UTTER SHITE SENT TO ME IF IT WAS COMMITTED 
> YESTERDAY?

.. and a slightly less annoying piece of crap in this pull request:
that "PRIME_NUMBERS" config thing is utter garbage too.

Why would you ask a user about it? The only valid use is for a kernel
module that needs it to "select" it, so there's no point in asking the
user if they want it.

We don't want to make the kernel config phase any worse than it
already is (and it's bad). Asking people idiotic and pointless
questions is simply not ok.

Christ. I dislike this pull request intensely, and I haven't even
gotten to the point where I can even _test_ it yet.

I'm very close to just saying "this is complete bullshit" and not pull
any DRM crap this merge window.

Honestly, if I find anything else, that's what I'll do. I might do it
even without finding anything elze.

And _reghardless_ of what happens this merge window, I will instate a
hard rule that the DRM code needs to be in linux-next *before* the
merge window opens.  No last-minute crap. No shit that hasn't even
been build-tested.

Because I am _never_ going to accept this kind of crap in the future.

If I find broken stuff like this from just a cursory examination and
build test, things are seriously wrong.

I think I'm also going to require the DRM pull requests to be split
up, because as it is now, I'm in the situation that I have to accept
all or nothing. Which is not good, when the "all" stuff is of this
dubious quality.

And if the DRM "maintenance" is about sending me random half-arsed
crap in one big pull, I'm just not willing to deal with it. This is
like the crazy ARM tree used to be.

Guys, this needs to be fixed.

   Linus

Re: [git pull] drm for v4.11 - main pull request

2017-02-23 Thread Linus Torvalds 
On Thu, Feb 23, 2017 at 5:44 PM, Linus Torvalds
 wrote:
>
> AND WHY THE HELL WAS THIS UTTER SHITE SENT TO ME IF IT WAS COMMITTED 
> YESTERDAY?

.. and a slightly less annoying piece of crap in this pull request:
that "PRIME_NUMBERS" config thing is utter garbage too.

Why would you ask a user about it? The only valid use is for a kernel
module that needs it to "select" it, so there's no point in asking the
user if they want it.

We don't want to make the kernel config phase any worse than it
already is (and it's bad). Asking people idiotic and pointless
questions is simply not ok.

Christ. I dislike this pull request intensely, and I haven't even
gotten to the point where I can even _test_ it yet.

I'm very close to just saying "this is complete bullshit" and not pull
any DRM crap this merge window.

Honestly, if I find anything else, that's what I'll do. I might do it
even without finding anything elze.

And _reghardless_ of what happens this merge window, I will instate a
hard rule that the DRM code needs to be in linux-next *before* the
merge window opens.  No last-minute crap. No shit that hasn't even
been build-tested.

Because I am _never_ going to accept this kind of crap in the future.

If I find broken stuff like this from just a cursory examination and
build test, things are seriously wrong.

I think I'm also going to require the DRM pull requests to be split
up, because as it is now, I'm in the situation that I have to accept
all or nothing. Which is not good, when the "all" stuff is of this
dubious quality.

And if the DRM "maintenance" is about sending me random half-arsed
crap in one big pull, I'm just not willing to deal with it. This is
like the crazy ARM tree used to be.

Guys, this needs to be fixed.

   Linus

Re: [git pull] drm for v4.11 - main pull request

2017-02-23 Thread Linus Torvalds 
On Thu, Feb 23, 2017 at 4:01 PM, Dave Airlie  wrote:
>
> This is the main drm pull request for v4.11.
>
> Nothing too major, the tinydrm and mmu-less support should make writing
> smaller drivers easier for some of the simpler platforms, and there are
> a bunch of documentation updates.

The tinydrm code seems like absolute pure shit that has never seen a compiler.

I'm upset, because I expect better quality control. In fact, I expect
*some* qualitty control, and this piece-of-shit driver has clearly
seen none at all.

And those patches were apparently committed yesterday.

WHAT THE ACTUAL FUCK?

I get tons and tons of lines of warnings:

  drivers/gpu/drm/tinydrm/mipi-dbi.c: In function ‘mipi_dbi_typec1_command’:
  drivers/gpu/drm/tinydrm/mipi-dbi.c:65:20: warning: field width
specifier ‘*’ expects argument of type ‘int’, but argument 5 has type
‘size_t {aka long unsigned int}’ [-Wformat=]
 DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, len, data); \

with nasty chains of nested defines, but then I also get actual compile failures

  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c:198:26: error:
redefinition of ‘tinydrm_of_find_backlight’
   struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
^
  In file included from drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c:11:0:
  ./include/drm/tinydrm/tinydrm-helpers.h:53:1: note: previous
definition of ‘tinydrm_of_find_backlight’ was here
   tinydrm_of_find_backlight(struct device *dev)
   ^

(with similar stuff for tinydrm_disable_backlight()).

It looks like it might compile if CONFIG_BACKLIGHT_CLASS_DEVICE was
enabled rather than being a module.

Doing this:

  -#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
  +#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

in tinydrm-helpers.h gets rid of the complete build failure, and only
leaves the tens of lines of warnings.

How the hell did this get to the point where crap like this is even
sent to me? Nobody tested *anything*?

AND WHY THE HELL WAS THIS UTTER SHITE SENT TO ME IF IT WAS COMMITTED YESTERDAY?

 Linus

Re: [git pull] drm for v4.11 - main pull request

2017-02-23 Thread Linus Torvalds 
On Thu, Feb 23, 2017 at 4:01 PM, Dave Airlie  wrote:
>
> This is the main drm pull request for v4.11.
>
> Nothing too major, the tinydrm and mmu-less support should make writing
> smaller drivers easier for some of the simpler platforms, and there are
> a bunch of documentation updates.

The tinydrm code seems like absolute pure shit that has never seen a compiler.

I'm upset, because I expect better quality control. In fact, I expect
*some* qualitty control, and this piece-of-shit driver has clearly
seen none at all.

And those patches were apparently committed yesterday.

WHAT THE ACTUAL FUCK?

I get tons and tons of lines of warnings:

  drivers/gpu/drm/tinydrm/mipi-dbi.c: In function ‘mipi_dbi_typec1_command’:
  drivers/gpu/drm/tinydrm/mipi-dbi.c:65:20: warning: field width
specifier ‘*’ expects argument of type ‘int’, but argument 5 has type
‘size_t {aka long unsigned int}’ [-Wformat=]
 DRM_DEBUG_DRIVER("cmd=%02x, par=%*ph\n", cmd, len, data); \

with nasty chains of nested defines, but then I also get actual compile failures

  drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c:198:26: error:
redefinition of ‘tinydrm_of_find_backlight’
   struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
^
  In file included from drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c:11:0:
  ./include/drm/tinydrm/tinydrm-helpers.h:53:1: note: previous
definition of ‘tinydrm_of_find_backlight’ was here
   tinydrm_of_find_backlight(struct device *dev)
   ^

(with similar stuff for tinydrm_disable_backlight()).

It looks like it might compile if CONFIG_BACKLIGHT_CLASS_DEVICE was
enabled rather than being a module.

Doing this:

  -#ifdef CONFIG_BACKLIGHT_CLASS_DEVICE
  +#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)

in tinydrm-helpers.h gets rid of the complete build failure, and only
leaves the tens of lines of warnings.

How the hell did this get to the point where crap like this is even
sent to me? Nobody tested *anything*?

AND WHY THE HELL WAS THIS UTTER SHITE SENT TO ME IF IT WAS COMMITTED YESTERDAY?

 Linus

[git pull] drm for v4.11 - main pull request

2017-02-23 Thread Dave Airlie 
Hi Linus,

This is the main drm pull request for v4.11.

Nothing too major, the tinydrm and mmu-less support should make writing
smaller drivers easier for some of the simpler platforms, and there are
a bunch of documentation updates.

Intel grew displayport MST audio support which is hopefully useful to
people, and FBC is on by default for GEN9+ (so people know where to
look for regressions). AMDGPU has a lot of fixes that would like new
firmware files installed for some GPUs.

Other than that it's pretty scattered all over.

I may have a follow up pull request as I know BenH has a bunch
of AST rework and fixes and I'd like to get those in once they've
been tested by AST, and I've got at least one pull request I'm just
trying to get the author to fix up.

Core:
drm_mm reworked
Connector list locking and iterators
Documentation updates
Format handling rework
MMU-less support for fbdev helpers
drm_crtc_from_index helper
Core CRC API
Remove drm_framebuffer_unregister_private
Debugfs cleanup
EDID/Infoframe fixes
Release callback.
Tinydrm support (smaller drivers for simple hw)

panel:
Add support for some new simple panels

i915:
FBC by default for gen9+
Shared dpll cleanups and docs
GEN8 powerdomain cleanup
DMC support on GLK
DP MST audio support
HuC loading support
GVT init ordering fixes
GVT IOMMU workaround fix

amdgpu/radeon:
Power/clockgating improvements
Preliminary SR-IOV support
TTM buffer priority and eviction fixes
SI DPM quirks removed due to firmware fixes
Powerplay improvements
VCE/UVD powergating fixes
Cleanup SI GFX code to match CI/VI
Support for > 2 displays on 3/5 crtc asics
SI headless fixes

nouveau:
Rework securre boot code in prep for GP10x secure boot
Channel recovery improvements
Initial power budget code
MMU rework preperation

vmwgfx:
Bunch of fixes and cleanups

exynos:
Runtime PM support for MIC driver
Cleanups to use atomic helpers.
UHD Support for TM2/TM2E boards
Trigger mode fix for Rinato board

etnaviv:
Shader performance fix
Command stream validator fixes
Command buffer suballocator.

rockchip:
CDN DisplayPort support.
IOMMU support for arm64 platform.

imx-drm:
Fix i.MX5 TV encoder probing
Remove lower fb size limits

msm:
Support for HW cursor on MDP5 devices
DSI encoder cleanup
GPU DT bindings cleanup

sti:
stih410 cleanups
Create fbdev at binding
HQVDP fixes
Remove stih416 chip functionality
DVI/HDMI mode selection fixes
FPS statistic reporting

omapdrm:
IRQ code cleanup

dwi-hdmi bridge:
Cleanups and fixes

adv-bridge:
Updates for nexus

sii8520 bridge:
Add interlace mode support
Rework HDMI and lots of fixes

qxl:
probing/teardown cleanups

ZTE drm:
HDMI audio via SPDIF interface
Video Layer overlay plane support
Add TV encoder output device

atmel-hlcdc:
Rework fbdev creation logic.

tegra:
OF node fix.

fsl-dcu:
Minor fixes

mali-dp:
Assorted fixes

sunxi:
Minor fix.

The following changes since commit 7089db84e356562f8ba737c29e472cc42d530dbc:

  Linux 4.10-rc8 (2017-02-12 13:03:20 -0800)

are available in the git repository at:

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

for you to fetch changes up to 1e8ad3d8da4763b238d09244d4d1177aa640c0d3:

  Merge branch 'drm-next-4.11' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2017-02-24
08:35:23 +1000)


main drm pull request for v4.11


A.Sunil Kamath (1):
  drm/i915: Use num_scalers instead of SKL_NUM_SCALERS in debugfs

Alan Harrison (1):
  drm/amdgpu: Add to initialization of mmVCE_VCPU_CNTL register

Alex Deucher (10):
  drm/amdgpu: use the num_rings variable for checking vce rings
  drm/amdgpu: drop pitcairn dpm quirks
  drm/radeon: drop pitcairn dpm quirks
  drm/amdgpu: remove unused header si_reg.h
  drm/amdgpu: move misc si headers into amdgpu
  drm/radeon: handle vfct with multiple vbios images
  drm/amdgpu: handle vfct with multiple vbios images
  drm/amdgpu: add support for new smc firmware on polaris
  drm/amdgpu: add more cases to DCE11 possible crtc mask setup
  drm/amdgpu/pm: check for headless before calling compute_clocks

Alexandre Courbot (32):
  drm/nouveau/core: constify nv*_printk macros
  drm/nouveau/mc: add nvkm_mc_enabled() function
  drm/nouveau/core: add falcon library functions
  drm/nouveau/pmu: add nvkm_pmu_ctor() function
  drm/nouveau/pmu: instanciate the falcon in PMU device
  drm/nouveau/pmu/gk20a: use nvkm_pmu_ctor()
  drm/nouveau/pmu/gk20a: simplify code a bit
  drm/nouveau/pmu/gk20a: use falcon library functions
  drm/nouveau/gm20b: add dummy PMU device

[git pull] drm for v4.11 - main pull request

2017-02-23 Thread Dave Airlie 
Hi Linus,

This is the main drm pull request for v4.11.

Nothing too major, the tinydrm and mmu-less support should make writing
smaller drivers easier for some of the simpler platforms, and there are
a bunch of documentation updates.

Intel grew displayport MST audio support which is hopefully useful to
people, and FBC is on by default for GEN9+ (so people know where to
look for regressions). AMDGPU has a lot of fixes that would like new
firmware files installed for some GPUs.

Other than that it's pretty scattered all over.

I may have a follow up pull request as I know BenH has a bunch
of AST rework and fixes and I'd like to get those in once they've
been tested by AST, and I've got at least one pull request I'm just
trying to get the author to fix up.

Core:
drm_mm reworked
Connector list locking and iterators
Documentation updates
Format handling rework
MMU-less support for fbdev helpers
drm_crtc_from_index helper
Core CRC API
Remove drm_framebuffer_unregister_private
Debugfs cleanup
EDID/Infoframe fixes
Release callback.
Tinydrm support (smaller drivers for simple hw)

panel:
Add support for some new simple panels

i915:
FBC by default for gen9+
Shared dpll cleanups and docs
GEN8 powerdomain cleanup
DMC support on GLK
DP MST audio support
HuC loading support
GVT init ordering fixes
GVT IOMMU workaround fix

amdgpu/radeon:
Power/clockgating improvements
Preliminary SR-IOV support
TTM buffer priority and eviction fixes
SI DPM quirks removed due to firmware fixes
Powerplay improvements
VCE/UVD powergating fixes
Cleanup SI GFX code to match CI/VI
Support for > 2 displays on 3/5 crtc asics
SI headless fixes

nouveau:
Rework securre boot code in prep for GP10x secure boot
Channel recovery improvements
Initial power budget code
MMU rework preperation

vmwgfx:
Bunch of fixes and cleanups

exynos:
Runtime PM support for MIC driver
Cleanups to use atomic helpers.
UHD Support for TM2/TM2E boards
Trigger mode fix for Rinato board

etnaviv:
Shader performance fix
Command stream validator fixes
Command buffer suballocator.

rockchip:
CDN DisplayPort support.
IOMMU support for arm64 platform.

imx-drm:
Fix i.MX5 TV encoder probing
Remove lower fb size limits

msm:
Support for HW cursor on MDP5 devices
DSI encoder cleanup
GPU DT bindings cleanup

sti:
stih410 cleanups
Create fbdev at binding
HQVDP fixes
Remove stih416 chip functionality
DVI/HDMI mode selection fixes
FPS statistic reporting

omapdrm:
IRQ code cleanup

dwi-hdmi bridge:
Cleanups and fixes

adv-bridge:
Updates for nexus

sii8520 bridge:
Add interlace mode support
Rework HDMI and lots of fixes

qxl:
probing/teardown cleanups

ZTE drm:
HDMI audio via SPDIF interface
Video Layer overlay plane support
Add TV encoder output device

atmel-hlcdc:
Rework fbdev creation logic.

tegra:
OF node fix.

fsl-dcu:
Minor fixes

mali-dp:
Assorted fixes

sunxi:
Minor fix.

The following changes since commit 7089db84e356562f8ba737c29e472cc42d530dbc:

  Linux 4.10-rc8 (2017-02-12 13:03:20 -0800)

are available in the git repository at:

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

for you to fetch changes up to 1e8ad3d8da4763b238d09244d4d1177aa640c0d3:

  Merge branch 'drm-next-4.11' of
git://people.freedesktop.org/~agd5f/linux into drm-next (2017-02-24
08:35:23 +1000)


main drm pull request for v4.11


A.Sunil Kamath (1):
  drm/i915: Use num_scalers instead of SKL_NUM_SCALERS in debugfs

Alan Harrison (1):
  drm/amdgpu: Add to initialization of mmVCE_VCPU_CNTL register

Alex Deucher (10):
  drm/amdgpu: use the num_rings variable for checking vce rings
  drm/amdgpu: drop pitcairn dpm quirks
  drm/radeon: drop pitcairn dpm quirks
  drm/amdgpu: remove unused header si_reg.h
  drm/amdgpu: move misc si headers into amdgpu
  drm/radeon: handle vfct with multiple vbios images
  drm/amdgpu: handle vfct with multiple vbios images
  drm/amdgpu: add support for new smc firmware on polaris
  drm/amdgpu: add more cases to DCE11 possible crtc mask setup
  drm/amdgpu/pm: check for headless before calling compute_clocks

Alexandre Courbot (32):
  drm/nouveau/core: constify nv*_printk macros
  drm/nouveau/mc: add nvkm_mc_enabled() function
  drm/nouveau/core: add falcon library functions
  drm/nouveau/pmu: add nvkm_pmu_ctor() function
  drm/nouveau/pmu: instanciate the falcon in PMU device
  drm/nouveau/pmu/gk20a: use nvkm_pmu_ctor()
  drm/nouveau/pmu/gk20a: simplify code a bit
  drm/nouveau/pmu/gk20a: use falcon library functions
  drm/nouveau/gm20b: add dummy PMU device