[PULL] drm-misc-next
mbox series

Message ID 20191017192601.GA215957@art_vandelay
State New
Headers show
Series
  • [PULL] drm-misc-next
Related show

Pull-request

git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-10-17

Message

Sean Paul Oct. 17, 2019, 7:26 p.m. UTC
Hi Dave/Daniel,
Apologies for this being a day late, I wanted to get the dt-bindings for the
malidp QoS change before sending this.

Most of the volume is incremental this week, there's some new HW features
enabled which I've called out below.

As for the uapi changes, well it's interesting timing with your RFC the other
day :) I think the error code changes are well-scrutinized so I don't have much
concern for those. The omap OMAP_BO_MEM_* changes though I don't think have
really reached non-TI eyes. There's no link in the commit message to a UAPI
implementation and the only reference I could find is libkmsxx which can set
them through the python bindings. Since this is TI-specific gunk in TI-specific
headers I'm inclined to let it pass, but I would have liked to have this
conversation upfront. I figured I'd call this out so you have final say.

drm-misc-next-2019-10-17:
drm-misc-next for 5.5:

UAPI Changes:
-omap:
    -Add OMAP_BO_MEM_* flags to specify how to allocate BO (Tomi)
    -Reorder OMAP_BO_* #defines, no functional change (Tomi)
-Change unsupported error code from EINVAL to EOPNOTSUPP for: (Rodrigo)
    -drm_wait_vblank_ioctl
    -drm_crtc_get_sequence_ioctl
    -drm_crtc_queue_sequence_ioctl

Cross-subsystem Changes:
-None

Core Changes:
-Delete drmP.h \o/ (Sam)
-kerneldoc clarifications on zpos collisions and plane rects (Simon & Maarten)
-dp_helpers: Add link training repeater definitions added in DP 1.4 (Rodrigo)
-TODO: Add item to convert fbdev drivers to drm (Thomas)
-prime: Add mmap to drm_gem_object_funcs giving more control than vm_ops (Gerd)
-shmem/ttm/vram: Use new mmap gem_object callback (Gerd)

Driver Changes:
-malidp: Add display QoS configuration via devicetree (Wen)
-vkms: Add prime import support (Oleg)
-panfrost: Properly handle job timeouts when cancelling them (Steven)
-rockchip/meson/sun4i(via dw-hdmi): Add Dynamic Range and Mastering infoframe
                                    support (Jonas)
-mxsfb: Add bridge support to accommodate dsi outputs (Robert)
-vboxvideo: Drop hand-rolled implementations and use fbdev emulation,
	    dirtyfb and drm_framebuffer struct from core/core helpers (Thomas)
-komeda: Add D71-specific line sizes and respect connector color fmt (Lowry)
-lima: Use shmem and reservation lock helpers from gem (Qiang)
-rockchip: Add gamma LUT support on vop crtcs (Ezequiel)
-omap:
  -Use refcount_t instead of rolling custom refcounting (Jean-Jacques)

Cc: Wen He <wen.he_1@nxp.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: Oleg Vasilev <omrigann@gmail.com>
Cc: Steven Price <steven.price@arm.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Simon Ser <contact@emersion.fr>
Cc: Robert Chiras <robert.chiras@nxp.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Lowry Li <Lowry.Li@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Qiang Yu <yuq825@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ezequiel Garcia <ezequiel@collabora.com>
Cc: Jean-Jacques Hiblot <jjhiblot@ti.com>

Cheers, Sean


The following changes since commit 354c2d310082d1c384213ba76c3757dd3cd8755d:

  drm: damage_helper: Fix race checking plane->state->fb (2019-10-08 09:41:06 -0400)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2019-10-17

for you to fetch changes up to e30b38b71294849c018322d85e90ec056438fe43:

  drm/lima: add __GFP_NOWARN flag to all dma_alloc_wc (2019-10-17 23:42:02 +0800)

----------------------------------------------------------------
drm-misc-next for 5.5:

UAPI Changes:
-omap:
    -Add OMAP_BO_MEM_* flags to specify how to allocate BO (Tomi)
    -Reorder OMAP_BO_* #defines, no functional change (Tomi)
-Change unsupported error code from EINVAL to EOPNOTSUPP for: (Rodrigo)
    -drm_wait_vblank_ioctl
    -drm_crtc_get_sequence_ioctl
    -drm_crtc_queue_sequence_ioctl

Cross-subsystem Changes:
-None

Core Changes:
-Delete drmP.h \o/ (Sam)
-kerneldoc clarifications on zpos collisions and plane rects (Simon & Maarten)
-dp_helpers: Add link training repeater definitions added in DP 1.4 (Rodrigo)
-TODO: Add item to convert fbdev drivers to drm (Thomas)
-prime: Add mmap to drm_gem_object_funcs giving more control than vm_ops (Gerd)
-shmem/ttm/vram: Use new mmap gem_object callback (Gerd)

Driver Changes:
-malidp: Add display QoS configuration via devicetree (Wen)
-vkms: Add prime import support (Oleg)
-panfrost: Properly handle job timeouts when cancelling them (Steven)
trockchip/meson/sun4i(via dw-hdmi): Add Dynamic Range and Mastering infoframe					    support (Jonas)
-mxsfb: Add bridge support to accommodate dsi outputs (Robert)
-vboxvideo: Drop hand-rolled implementations and use fbdev emulation,
	    dirtyfb and drm_framebuffer struct from core/core helpers (Thomas)
-komeda: Add D71-specific line sizes and respect connector color fmt (Lowry)
-lima: Use shmem and reservation lock helpers from gem (Qiang)
-rockchip: Add gamma LUT support on vop crtcs (Ezequiel)
-omap:
  -Use refcount_t instead of rolling custom refcounting (Jean-Jacques)

Cc: Wen He <wen.he_1@nxp.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
Cc: Rodrigo Siqueira <Rodrigo.Siqueira@amd.com>
Cc: Oleg Vasilev <omrigann@gmail.com>
Cc: Steven Price <steven.price@arm.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Simon Ser <contact@emersion.fr>
Cc: Robert Chiras <robert.chiras@nxp.com>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: Lowry Li <Lowry.Li@arm.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Qiang Yu <yuq825@gmail.com>
Cc: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Ezequiel Garcia <ezequiel@collabora.com>
Cc: Jean-Jacques Hiblot <jjhiblot@ti.com>

----------------------------------------------------------------
Ben Dooks (3):
      drm/scheduler: make unexported items static
      drm/rockchip: include rockchip_drm_drv.h
      drm/rockchip: make rockchip_gem_alloc_object static

Brian Masney (1):
      drm/bridge: analogix-anx78xx: add support for 7808 addresses

Colin Ian King (1):
      drm/komeda: remove redundant assignment to pointer disable_done

Daniel Kurtz (1):
      drm/bridge: dw-hdmi: Restore audio when setting a mode

Daniel Vetter (1):
      drm/dp-mst: Drop connection_mutex check

Douglas Anderson (1):
      drm/rockchip: Round up _before_ giving to the clock framework

Ezequiel Garcia (2):
      dt-bindings: display: rockchip: document VOP gamma LUT address
      drm/rockchip: Add optional support for CRTC gamma LUT

Gerd Hoffmann (11):
      drm: add mmap() to drm_gem_object_funcs
      drm/shmem: switch shmem helper to &drm_gem_object_funcs.mmap
      drm/shmem: drop VM_DONTDUMP
      drm/shmem: drop VM_IO
      drm/shmem: drop DEFINE_DRM_GEM_SHMEM_FOPS
      drm/ttm: factor out ttm_bo_mmap_vma_setup
      drm/ttm: rename ttm_fbdev_mmap
      drm/ttm: add drm_gem_ttm_mmap()
      drm/vram: switch vram helper to &drm_gem_object_funcs.mmap()
      drm/vram: drop verify_access
      drm/vram: drop DRM_VRAM_MM_FILE_OPERATIONS

Guido Günther (1):
      drm/mxsfb: Read bus flags from bridge if present

Jean-Jacques Hiblot (1):
      drm/omap: use refcount API to track the number of users of dma_addr

Jonas Karlman (4):
      drm/bridge: dw-hdmi: Add Dynamic Range and Mastering InfoFrame support
      drm/rockchip: Enable DRM InfoFrame support on RK3328 and RK3399
      drm/meson: Enable DRM InfoFrame support on GXL, GXM and G12A
      drm/sun4i: Enable DRM InfoFrame support on H6

Lee Shawn C (1):
      drm/edid: Select DMT timing if EDID's display feature not support GTF

Lowry Li (Arm Technology China) (4):
      drm/komeda: Add line size support
      drm/komeda: Adds layer horizontal input size limitation check for D71
      drm/komeda: Set output color depth for output
      drm/komeda: Adds output-color format support

Lucas De Marchi (1):
      drm/dp-mst: fix warning on unused var

Maarten Lankhorst (1):
      drm/plane: Clarify our expectations for src/dst rectangles

Markus Elfring (1):
      drm/rockchip: rk3066_hdmi: Use devm_platform_ioremap_resource() in rk3066_hdmi_bind()

Nickey Yang (1):
      drm/rockchip: vop: add the definition of dclk_pol

Oleg Vasilev (1):
      drm/vkms: prime import support

Qiang Yu (3):
      drm/lima: use drm_gem_shmem_helpers
      drm/lima: use drm_gem_(un)lock_reservations
      drm/lima: add __GFP_NOWARN flag to all dma_alloc_wc

Robert Chiras (1):
      drm/mxsfb: Update mxsfb to support a bridge

Rodrigo Siqueira (3):
      drm: Add link training repeaters addresses
      drm/drm_vblank: Change EINVAL by the correct errno
      drm: Add LT-tunable PHY repeater mode operations

Ronald Tschalär (1):
      drm/bridge: sil_sii8620: make remote control optional.

Sam Ravnborg (2):
      drm_dp_cec: drop use of drmP.h
      drm: delete drmP.h + drm_os_linux.h

Sean Paul (1):
      Documentation: Fix warning in drm-kms-helpers.rst

Sebastian Andrzej Siewior (1):
      drm/i810: Refer to `PREEMPTION' in comment

Simon Ser (1):
      drm: two planes with the same zpos have undefined ordering

Steven Price (3):
      drm/panfrost: Remove NULL check for regulator
      drm/panfrost: Handle resetting on timeout better
      drm/panfrost: Remove commented out call to panfrost_core_dump

Thomas Zimmermann (5):
      drm/vboxvideo: Switch to generic fbdev emulation
      drm/vboxvideo: Switch to drm_atomic_helper_dirty_fb()
      drm/vboxvideo: Replace struct vram_framebuffer with generic implemenation
      drm: Add TODO item for fbdev driver conversion
      drm/cirrus: Remove obsolete header file

Tomi Valkeinen (7):
      drm/omap: add omap_gem_unpin_locked()
      drm/omap: accept NULL for dma_addr in omap_gem_pin
      drm/omap: cleanup OMAP_BO flags
      drm/omap: remove OMAP_BO_TILED define
      drm/omap: cleanup OMAP_BO_SCANOUT use
      drm/omap: add omap_gem_validate_flags()
      drm/omap: add OMAP_BO flags to affect buffer allocation

Ville Syrjälä (1):
      drm/atmel-hlcdc: Use swap() where appropriate

Wen He (2):
      drm/arm/mali-dp: Add display QoS interface configuration for Mali DP500
      dt/bindings: display: Add optional property node define for Mali DP500

Wolfram Sang (1):
      gpu: drm: bridge: sii9234: convert to devm_i2c_new_dummy_device

YueHaibing (2):
      drm/vkms: Remove duplicated include from vkms_drv.c
      drm/qxl: Fix randbuild error

zhengbin (4):
      drm/omap: Remove set but not used variable 'plane'
      drm/omap: Remove set but not used variable 'tclk_trail'
      drm/omap: Remove set but not used variable 'err' in hdmi5_audio_config
      drm/omap: Remove set but not used variable 'err' in hdmi4_audio_config

zhong jiang (1):
      drm/vkms: Fix an undefined reference error in vkms_composer_worker

 .../devicetree/bindings/display/arm,malidp.txt     |   3 +
 .../bindings/display/rockchip/rockchip-vop.txt     |   6 +-
 Documentation/gpu/drm-kms-helpers.rst              |   3 -
 Documentation/gpu/todo.rst                         |  39 +++-
 drivers/gpu/drm/Kconfig                            |   3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c         |   5 +-
 .../gpu/drm/arm/display/komeda/d71/d71_component.c | 121 +++++++++-
 drivers/gpu/drm/arm/display/komeda/d71/d71_regs.h  |   9 +-
 drivers/gpu/drm/arm/display/komeda/komeda_crtc.c   |  29 ++-
 drivers/gpu/drm/arm/display/komeda/komeda_kms.h    |   2 +
 .../gpu/drm/arm/display/komeda/komeda_pipeline.h   |   3 +
 .../drm/arm/display/komeda/komeda_pipeline_state.c |  46 ++++
 .../drm/arm/display/komeda/komeda_wb_connector.c   |   5 +
 drivers/gpu/drm/arm/malidp_drv.c                   |   6 +
 drivers/gpu/drm/arm/malidp_hw.c                    |   9 +
 drivers/gpu/drm/arm/malidp_hw.h                    |   3 +
 drivers/gpu/drm/arm/malidp_regs.h                  |  10 +
 drivers/gpu/drm/ast/ast_drv.c                      |   5 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c    |   5 +-
 drivers/gpu/drm/bochs/bochs_drv.c                  |   5 +-
 drivers/gpu/drm/bridge/Kconfig                     |   3 +-
 drivers/gpu/drm/bridge/analogix-anx78xx.c          |  36 +--
 drivers/gpu/drm/bridge/analogix-anx78xx.h          |  17 +-
 drivers/gpu/drm/bridge/sii9234.c                   |  36 +--
 drivers/gpu/drm/bridge/sil-sii8620.c               |  10 +-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c          |  83 ++++++-
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.h          |  37 +++
 drivers/gpu/drm/cirrus/cirrus.c                    |   2 +-
 drivers/gpu/drm/cirrus/cirrus_drv.h                | 247 ---------------------
 drivers/gpu/drm/drm_blend.c                        |   8 +-
 drivers/gpu/drm/drm_dp_cec.c                       |   6 +-
 drivers/gpu/drm/drm_dp_mst_topology.c              |   3 -
 drivers/gpu/drm/drm_edid.c                         |   3 +-
 drivers/gpu/drm/drm_gem.c                          |  27 ++-
 drivers/gpu/drm/drm_gem_shmem_helper.c             |  28 +--
 drivers/gpu/drm/drm_gem_ttm_helper.c               |  17 ++
 drivers/gpu/drm/drm_gem_vram_helper.c              |  56 +----
 drivers/gpu/drm/drm_prime.c                        |   9 +
 drivers/gpu/drm/drm_vblank.c                       |   6 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c    |   5 +-
 drivers/gpu/drm/lima/Kconfig                       |   1 +
 drivers/gpu/drm/lima/Makefile                      |   4 +-
 drivers/gpu/drm/lima/lima_device.c                 |   2 +-
 drivers/gpu/drm/lima/lima_drv.c                    |  22 +-
 drivers/gpu/drm/lima/lima_gem.c                    | 195 ++++++----------
 drivers/gpu/drm/lima/lima_gem.h                    |  32 ++-
 drivers/gpu/drm/lima/lima_gem_prime.c              |  46 ----
 drivers/gpu/drm/lima/lima_gem_prime.h              |  13 --
 drivers/gpu/drm/lima/lima_mmu.c                    |   1 -
 drivers/gpu/drm/lima/lima_object.c                 | 119 ----------
 drivers/gpu/drm/lima/lima_object.h                 |  35 ---
 drivers/gpu/drm/lima/lima_sched.c                  |   6 +-
 drivers/gpu/drm/lima/lima_vm.c                     |  87 ++++----
 drivers/gpu/drm/meson/meson_dw_hdmi.c              |   5 +
 drivers/gpu/drm/mgag200/mgag200_drv.c              |   5 +-
 drivers/gpu/drm/mxsfb/mxsfb_crtc.c                 |  20 +-
 drivers/gpu/drm/mxsfb/mxsfb_drv.c                  |  46 +++-
 drivers/gpu/drm/mxsfb/mxsfb_drv.h                  |   4 +-
 drivers/gpu/drm/mxsfb/mxsfb_out.c                  |  26 ++-
 drivers/gpu/drm/omapdrm/dss/dsi.c                  |   3 +-
 drivers/gpu/drm/omapdrm/dss/hdmi4_core.c           |   4 +-
 drivers/gpu/drm/omapdrm/dss/hdmi5_core.c           |   4 +-
 drivers/gpu/drm/omapdrm/omap_dmm_tiler.h           |   2 +-
 drivers/gpu/drm/omapdrm/omap_fb.c                  |   9 +-
 drivers/gpu/drm/omapdrm/omap_gem.c                 | 191 +++++++++++-----
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c          |   2 +-
 drivers/gpu/drm/panfrost/TODO                      |   2 +
 drivers/gpu/drm/panfrost/panfrost_devfreq.c        |   6 +-
 drivers/gpu/drm/panfrost/panfrost_drv.c            |   2 +-
 drivers/gpu/drm/panfrost/panfrost_gem.c            |   2 +-
 drivers/gpu/drm/panfrost/panfrost_job.c            |  18 +-
 drivers/gpu/drm/qxl/Kconfig                        |   1 +
 drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c        |   2 +
 drivers/gpu/drm/rockchip/rk3066_hdmi.c             |   8 +-
 drivers/gpu/drm/rockchip/rockchip_drm_gem.c        |   2 +-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c        | 169 +++++++++++++-
 drivers/gpu/drm/rockchip/rockchip_drm_vop.h        |  10 +-
 drivers/gpu/drm/rockchip/rockchip_vop_reg.c        |  48 ++--
 drivers/gpu/drm/scheduler/sched_fence.c            |   4 +-
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c              |   2 +
 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h              |   1 +
 drivers/gpu/drm/tiny/gm12u320.c                    |   2 +-
 drivers/gpu/drm/ttm/ttm_bo_vm.c                    |  54 +++--
 drivers/gpu/drm/v3d/v3d_bo.c                       |   2 +-
 drivers/gpu/drm/v3d/v3d_drv.c                      |   2 +-
 drivers/gpu/drm/vboxvideo/Makefile                 |   2 +-
 drivers/gpu/drm/vboxvideo/vbox_drv.c               |  19 +-
 drivers/gpu/drm/vboxvideo/vbox_drv.h               |  25 ---
 drivers/gpu/drm/vboxvideo/vbox_fb.c                | 149 -------------
 drivers/gpu/drm/vboxvideo/vbox_main.c              | 119 +---------
 drivers/gpu/drm/vboxvideo/vbox_mode.c              |  85 +++----
 drivers/gpu/drm/virtio/virtgpu_drv.c               |   2 +-
 drivers/gpu/drm/virtio/virtgpu_object.c            |   2 +-
 drivers/gpu/drm/vkms/vkms_drv.c                    |  13 +-
 drivers/gpu/drm/vkms/vkms_drv.h                    |   6 +
 drivers/gpu/drm/vkms/vkms_gem.c                    |  27 +++
 include/drm/bridge/dw_hdmi.h                       |   1 +
 include/drm/drmP.h                                 | 103 ---------
 include/drm/drm_dp_helper.h                        |  30 +++
 include/drm/drm_gem.h                              |  14 ++
 include/drm/drm_gem_shmem_helper.h                 |  30 +--
 include/drm/drm_gem_ttm_helper.h                   |   2 +
 include/drm/drm_gem_vram_helper.h                  |  25 ---
 include/drm/drm_os_linux.h                         |  55 -----
 include/drm/drm_plane.h                            |  31 ++-
 include/drm/ttm/ttm_bo_api.h                       |  10 +-
 include/uapi/drm/omap_drm.h                        |  27 ++-
 107 files changed, 1336 insertions(+), 1618 deletions(-)
 delete mode 100644 drivers/gpu/drm/cirrus/cirrus_drv.h
 delete mode 100644 drivers/gpu/drm/lima/lima_gem_prime.c
 delete mode 100644 drivers/gpu/drm/lima/lima_gem_prime.h
 delete mode 100644 drivers/gpu/drm/lima/lima_object.c
 delete mode 100644 drivers/gpu/drm/lima/lima_object.h
 delete mode 100644 drivers/gpu/drm/vboxvideo/vbox_fb.c
 delete mode 100644 include/drm/drmP.h
 delete mode 100644 include/drm/drm_os_linux.h

Comments

Tomi Valkeinen Oct. 18, 2019, 1:45 p.m. UTC | #1
Hi Sean,

On 17/10/2019 22:26, Sean Paul wrote:

> concern for those. The omap OMAP_BO_MEM_* changes though I don't think have
> really reached non-TI eyes. There's no link in the commit message to a UAPI
> implementation and the only reference I could find is libkmsxx which can set
> them through the python bindings. Since this is TI-specific gunk in TI-specific
> headers I'm inclined to let it pass, but I would have liked to have this
> conversation upfront. I figured I'd call this out so you have final say.

There was some discussion about that a few years back when I initially 
sent the patches, but now that I look, the discussion died before really 
even starting.

This is what I said about userspace implementation:

> Yes, unfortunately that is not going to happen. I don't see how this
> could be used in a generic system like Weston or X. It's meant for very
> specific use cases, where you know exactly the requirements of your
> application and the capabilities of the whole system, and optimize based
> on that.
I know this feature is used by customers, but I don't have access to 
their applications.

  Tomi
Sean Paul Oct. 18, 2019, 8:11 p.m. UTC | #2
On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
> Hi Sean,
>
> On 17/10/2019 22:26, Sean Paul wrote:
>
> > concern for those. The omap OMAP_BO_MEM_* changes though I don't think have
> > really reached non-TI eyes. There's no link in the commit message to a UAPI
> > implementation and the only reference I could find is libkmsxx which can set
> > them through the python bindings. Since this is TI-specific gunk in TI-specific
> > headers I'm inclined to let it pass, but I would have liked to have this
> > conversation upfront. I figured I'd call this out so you have final say.
>
> There was some discussion about that a few years back when I initially
> sent the patches, but now that I look, the discussion died before really
> even starting.
>
> This is what I said about userspace implementation:
>
> > Yes, unfortunately that is not going to happen. I don't see how this
> > could be used in a generic system like Weston or X. It's meant for very
> > specific use cases, where you know exactly the requirements of your
> > application and the capabilities of the whole system, and optimize based
> > on that.

Thanks for the context, Tomi.

Indeed it looks like the discussion died, but Laurent still brought up
the u/s requirement and the patch was effectively dead until Daniel or
Dave weighed in. I'd expect at least some outreach before pushing the
patch directly 2+ years later. Has anything changed since then?


> I know this feature is used by customers, but I don't have access to
> their applications.

Unfortunately, and as you know, that is insufficient/irrelevant for
introducing new UAPI. So the question is if the libkmsxx bindings
constitute opensource userspace, it's really thin IMO.

Sean


>
>   Tomi
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
Tomi Valkeinen Oct. 21, 2019, 8:09 a.m. UTC | #3
Hi,

On 18/10/2019 23:11, Sean Paul wrote:
> On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>
>> Hi Sean,
>>
>> On 17/10/2019 22:26, Sean Paul wrote:
>>
>>> concern for those. The omap OMAP_BO_MEM_* changes though I don't think have
>>> really reached non-TI eyes. There's no link in the commit message to a UAPI
>>> implementation and the only reference I could find is libkmsxx which can set
>>> them through the python bindings. Since this is TI-specific gunk in TI-specific
>>> headers I'm inclined to let it pass, but I would have liked to have this
>>> conversation upfront. I figured I'd call this out so you have final say.
>>
>> There was some discussion about that a few years back when I initially
>> sent the patches, but now that I look, the discussion died before really
>> even starting.
>>
>> This is what I said about userspace implementation:
>>
>>> Yes, unfortunately that is not going to happen. I don't see how this
>>> could be used in a generic system like Weston or X. It's meant for very
>>> specific use cases, where you know exactly the requirements of your
>>> application and the capabilities of the whole system, and optimize based
>>> on that.
> 
> Thanks for the context, Tomi.
> 
> Indeed it looks like the discussion died, but Laurent still brought up
> the u/s requirement and the patch was effectively dead until Daniel or
> Dave weighed in. I'd expect at least some outreach before pushing the
> patch directly 2+ years later. Has anything changed since then?

There were new review rounds for the series this summer & autumn, but 
no, nothing else. I haven't specifically pinged anyone about the UAPI 
changes.

This series introduces three new flags to an already existing UAPI, and, 
for whatever reason, this didn't register to me as a new UAPI, even if 
Laurent asked about it some years back.

So, my mistake.

The flags are added in a single patch, so I can easily push a revert for 
that if this patch is not acceptable. The rest of the series is cleanup.

>> I know this feature is used by customers, but I don't have access to
>> their applications.
> 
> Unfortunately, and as you know, that is insufficient/irrelevant for
> introducing new UAPI. So the question is if the libkmsxx bindings
> constitute opensource userspace, it's really thin IMO.

Ok. Well, I know and understand the general rule here. But perhaps I 
haven't taken it as strictly as needed.

I have to say I don't quite understand why this rule would be always 
strictly held, though.

These flags, for example, what should we do with them?
- They provide a proven, real use-case benefit.
- They are specific to SoCs with OMAP DSS and DMM IPs.
- They are relatively simple.
- All the details, including the details about the HW, are public.
- Using them makes sense only in cases where you are tuning your system 
to your application, and you must know the resource needs of all the 
apps in your system. So they cannot really be used in any generic setup, 
or at least I have no idea how.

Does the history and experience say that such specific case as above 
cases don't really exist, and we can always have a generic UAPI (or, in 
worst case, a device specific UAPI) which can be used from X/Weston/or-such?

Or do things like above exist, but they need to carried in vendors' kernels?

  Tomi
Sean Paul Oct. 21, 2019, 3:48 p.m. UTC | #4
On Mon, Oct 21, 2019 at 4:11 AM Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>
> Hi,
>
> On 18/10/2019 23:11, Sean Paul wrote:
> > On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >>
> >> Hi Sean,
> >>
> >> On 17/10/2019 22:26, Sean Paul wrote:
> >>
> >>> concern for those. The omap OMAP_BO_MEM_* changes though I don't think have
> >>> really reached non-TI eyes. There's no link in the commit message to a UAPI
> >>> implementation and the only reference I could find is libkmsxx which can set
> >>> them through the python bindings. Since this is TI-specific gunk in TI-specific
> >>> headers I'm inclined to let it pass, but I would have liked to have this
> >>> conversation upfront. I figured I'd call this out so you have final say.
> >>
> >> There was some discussion about that a few years back when I initially
> >> sent the patches, but now that I look, the discussion died before really
> >> even starting.
> >>
> >> This is what I said about userspace implementation:
> >>
> >>> Yes, unfortunately that is not going to happen. I don't see how this
> >>> could be used in a generic system like Weston or X. It's meant for very
> >>> specific use cases, where you know exactly the requirements of your
> >>> application and the capabilities of the whole system, and optimize based
> >>> on that.
> >
> > Thanks for the context, Tomi.
> >
> > Indeed it looks like the discussion died, but Laurent still brought up
> > the u/s requirement and the patch was effectively dead until Daniel or
> > Dave weighed in. I'd expect at least some outreach before pushing the
> > patch directly 2+ years later. Has anything changed since then?
>
> There were new review rounds for the series this summer & autumn, but
> no, nothing else. I haven't specifically pinged anyone about the UAPI
> changes.
>
> This series introduces three new flags to an already existing UAPI, and,
> for whatever reason, this didn't register to me as a new UAPI, even if
> Laurent asked about it some years back.
>
> So, my mistake.
>
> The flags are added in a single patch, so I can easily push a revert for
> that if this patch is not acceptable. The rest of the series is cleanup.
>

I'll wait for Dave or Daniel to weigh in on whether they want to take
this, otherwise I'll revert before sending the next pull and we can
have this conversation on the review.

> >> I know this feature is used by customers, but I don't have access to
> >> their applications.
> >
> > Unfortunately, and as you know, that is insufficient/irrelevant for
> > introducing new UAPI. So the question is if the libkmsxx bindings
> > constitute opensource userspace, it's really thin IMO.
>
> Ok. Well, I know and understand the general rule here. But perhaps I
> haven't taken it as strictly as needed.
>
> I have to say I don't quite understand why this rule would be always
> strictly held, though.
>

It's strictly held because once you start accepting the
harmless/isolated features every driver has, you end up with
untestable bloat sprinkled everywhere.

> These flags, for example, what should we do with them?
> - They provide a proven, real use-case benefit.
> - They are specific to SoCs with OMAP DSS and DMM IPs.
> - They are relatively simple.
> - All the details, including the details about the HW, are public.
> - Using them makes sense only in cases where you are tuning your system
> to your application, and you must know the resource needs of all the
> apps in your system. So they cannot really be used in any generic setup,
> or at least I have no idea how.
>
> Does the history and experience say that such specific case as above
> cases don't really exist, and we can always have a generic UAPI (or, in
> worst case, a device specific UAPI) which can be used from X/Weston/or-such?
>

We don't need generic userspace to be able to make use of it, but at
least some oss project should find it useful. Otherwise why are we
maintaining code that no one in the open source community cares about?
How do we test it when the closed source implementations have been
abandoned?

> Or do things like above exist, but they need to carried in vendors' kernels?

That's really the problem. _Everybody_ has features they would
describe as above, so where do we draw the line?

Sean

>
>   Tomi
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
Dave Airlie Oct. 22, 2019, 2:17 a.m. UTC | #5
On Tue, 22 Oct 2019 at 01:49, Sean Paul <sean@poorly.run> wrote:
>
> On Mon, Oct 21, 2019 at 4:11 AM Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> >
> > Hi,
> >
> > On 18/10/2019 23:11, Sean Paul wrote:
> > > On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > >>
> > >> Hi Sean,
> > >>
> > >> On 17/10/2019 22:26, Sean Paul wrote:
> > >>
> > >>> concern for those. The omap OMAP_BO_MEM_* changes though I don't think have
> > >>> really reached non-TI eyes. There's no link in the commit message to a UAPI
> > >>> implementation and the only reference I could find is libkmsxx which can set
> > >>> them through the python bindings. Since this is TI-specific gunk in TI-specific
> > >>> headers I'm inclined to let it pass, but I would have liked to have this
> > >>> conversation upfront. I figured I'd call this out so you have final say.
> > >>
> > >> There was some discussion about that a few years back when I initially
> > >> sent the patches, but now that I look, the discussion died before really
> > >> even starting.
> > >>
> > >> This is what I said about userspace implementation:
> > >>
> > >>> Yes, unfortunately that is not going to happen. I don't see how this
> > >>> could be used in a generic system like Weston or X. It's meant for very
> > >>> specific use cases, where you know exactly the requirements of your
> > >>> application and the capabilities of the whole system, and optimize based
> > >>> on that.
> > >
> > > Thanks for the context, Tomi.
> > >
> > > Indeed it looks like the discussion died, but Laurent still brought up
> > > the u/s requirement and the patch was effectively dead until Daniel or
> > > Dave weighed in. I'd expect at least some outreach before pushing the
> > > patch directly 2+ years later. Has anything changed since then?
> >
> > There were new review rounds for the series this summer & autumn, but
> > no, nothing else. I haven't specifically pinged anyone about the UAPI
> > changes.
> >
> > This series introduces three new flags to an already existing UAPI, and,
> > for whatever reason, this didn't register to me as a new UAPI, even if
> > Laurent asked about it some years back.
> >
> > So, my mistake.
> >
> > The flags are added in a single patch, so I can easily push a revert for
> > that if this patch is not acceptable. The rest of the series is cleanup.
> >
>
> I'll wait for Dave or Daniel to weigh in on whether they want to take
> this, otherwise I'll revert before sending the next pull and we can
> have this conversation on the review.

I'd rather we revert it, just to stick to some semblance of the rules,
otherwise if we make execptions other people will drive trucks through
them.

Dave.
Daniel Vetter Oct. 22, 2019, 7:01 a.m. UTC | #6
On Tue, Oct 22, 2019 at 4:17 AM Dave Airlie <airlied@gmail.com> wrote:
>
> On Tue, 22 Oct 2019 at 01:49, Sean Paul <sean@poorly.run> wrote:
> >
> > On Mon, Oct 21, 2019 at 4:11 AM Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > >
> > > Hi,
> > >
> > > On 18/10/2019 23:11, Sean Paul wrote:
> > > > On Fri, Oct 18, 2019 at 9:46 AM Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> > > >>
> > > >> Hi Sean,
> > > >>
> > > >> On 17/10/2019 22:26, Sean Paul wrote:
> > > >>
> > > >>> concern for those. The omap OMAP_BO_MEM_* changes though I don't think have
> > > >>> really reached non-TI eyes. There's no link in the commit message to a UAPI
> > > >>> implementation and the only reference I could find is libkmsxx which can set
> > > >>> them through the python bindings. Since this is TI-specific gunk in TI-specific
> > > >>> headers I'm inclined to let it pass, but I would have liked to have this
> > > >>> conversation upfront. I figured I'd call this out so you have final say.
> > > >>
> > > >> There was some discussion about that a few years back when I initially
> > > >> sent the patches, but now that I look, the discussion died before really
> > > >> even starting.
> > > >>
> > > >> This is what I said about userspace implementation:
> > > >>
> > > >>> Yes, unfortunately that is not going to happen. I don't see how this
> > > >>> could be used in a generic system like Weston or X. It's meant for very
> > > >>> specific use cases, where you know exactly the requirements of your
> > > >>> application and the capabilities of the whole system, and optimize based
> > > >>> on that.
> > > >
> > > > Thanks for the context, Tomi.
> > > >
> > > > Indeed it looks like the discussion died, but Laurent still brought up
> > > > the u/s requirement and the patch was effectively dead until Daniel or
> > > > Dave weighed in. I'd expect at least some outreach before pushing the
> > > > patch directly 2+ years later. Has anything changed since then?
> > >
> > > There were new review rounds for the series this summer & autumn, but
> > > no, nothing else. I haven't specifically pinged anyone about the UAPI
> > > changes.
> > >
> > > This series introduces three new flags to an already existing UAPI, and,
> > > for whatever reason, this didn't register to me as a new UAPI, even if
> > > Laurent asked about it some years back.
> > >
> > > So, my mistake.
> > >
> > > The flags are added in a single patch, so I can easily push a revert for
> > > that if this patch is not acceptable. The rest of the series is cleanup.
> > >
> >
> > I'll wait for Dave or Daniel to weigh in on whether they want to take
> > this, otherwise I'll revert before sending the next pull and we can
> > have this conversation on the review.
>
> I'd rather we revert it, just to stick to some semblance of the rules,
> otherwise if we make execptions other people will drive trucks through
> them.

Imo we have driven a truck through the "it's not really new uapi, only
a new flag/field/type added to existing uapi" + "it's obvious this is
the right thing", it's how we got a metric ton of questionable kms
properties.

Also for this case specifically, I'm not seeing why we can't follow
the usual rules:
- lots of gem drivers have buffer allocation/placement hints (it's
kinda the thing ttm is for ...), and they all found some userspace for
it
- _PIN looks suspicious, imo the proper approach is something like
amdgpu's per-ctx persistent working set, which gives you the "look no
pin" fastpath while still being able to manage buffers for real. That
one also yells at you with ENOMEM if the memory doesn't exist, at
alloc time.

tldr; I concur

Cheers, Daniel