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
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
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
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
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
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.
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
dri-devel@lists.freedesktop.org
-
Daniel Vetter -
Dave Airlie -
Sean Paul -
Tomi Valkeinen