* [PULL] drm-misc-next
@ 2019-10-17 19:26 Sean Paul
2019-10-18 13:45 ` Tomi Valkeinen
0 siblings, 1 reply; 9+ messages in thread
From: Sean Paul @ 2019-10-17 19:26 UTC (permalink / raw)
To: Dave Airlie, Daniel Vetter
Cc: dri-devel, Gerd Hoffmann, Sam Ravnborg, dim-tools,
Ezequiel Garcia, Rodrigo Siqueira, Steven Price, Tomi Valkeinen,
Robert Chiras, Jean-Jacques Hiblot, Lowry Li, Jonas Karlman,
intel-gfx, Maxime Ripard, Wen He, Simon Ser, Oleg Vasilev,
Qiang Yu, Thomas Zimmermann
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
--
Sean Paul, Software Engineer, Google / Chromium OS
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] drm-misc-next
2019-10-17 19:26 [PULL] drm-misc-next Sean Paul
@ 2019-10-18 13:45 ` Tomi Valkeinen
2019-10-18 20:11 ` Sean Paul
0 siblings, 1 reply; 9+ messages in thread
From: Tomi Valkeinen @ 2019-10-18 13:45 UTC (permalink / raw)
To: Sean Paul, Dave Airlie, Daniel Vetter
Cc: dri-devel, Gerd Hoffmann, Sam Ravnborg, dim-tools,
Rodrigo Siqueira, Steven Price, Robert Chiras,
Jean-Jacques Hiblot, Lowry Li, Jonas Karlman, intel-gfx,
Maxime Ripard, Ezequiel Garcia, Wen He, Simon Ser, Oleg Vasilev,
Qiang Yu, Thomas Zimmermann
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
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] drm-misc-next
2019-10-18 13:45 ` Tomi Valkeinen
@ 2019-10-18 20:11 ` Sean Paul
2019-10-21 8:09 ` Tomi Valkeinen
0 siblings, 1 reply; 9+ messages in thread
From: Sean Paul @ 2019-10-18 20:11 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Daniel Vetter, dri-devel, Gerd Hoffmann, Sam Ravnborg,
DRM maintainer tools announcements, discussion, and development,
Rodrigo Siqueira, Steven Price, Robert Chiras,
Jean-Jacques Hiblot, Lowry Li, Jonas Karlman,
Intel Graphics Development, Rodrigo Vivi, Ezequiel Garcia,
Wen He, Oleg Vasilev, Qiang Yu, Thomas Zimmermann,
Laurent Pinchart
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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] drm-misc-next
2019-10-18 20:11 ` Sean Paul
@ 2019-10-21 8:09 ` Tomi Valkeinen
2019-10-21 15:48 ` Sean Paul
0 siblings, 1 reply; 9+ messages in thread
From: Tomi Valkeinen @ 2019-10-21 8:09 UTC (permalink / raw)
To: Sean Paul
Cc: Daniel Vetter, dri-devel, Gerd Hoffmann, Sam Ravnborg,
DRM maintainer tools announcements, discussion, and development,
Rodrigo Siqueira, Steven Price, Robert Chiras,
Jean-Jacques Hiblot, Lowry Li, Jonas Karlman,
Intel Graphics Development, Maxime Ripard, Ezequiel Garcia,
Wen He, Simon Ser, Oleg Vasilev, Qiang Yu, Thomas Zimmermann,
Laurent Pinchart
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
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PULL] drm-misc-next
2019-10-21 8:09 ` Tomi Valkeinen
@ 2019-10-21 15:48 ` Sean Paul
2019-10-22 2:17 ` [Intel-gfx] " Dave Airlie
0 siblings, 1 reply; 9+ messages in thread
From: Sean Paul @ 2019-10-21 15:48 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Wen He, DRM maintainer tools announcements, discussion,
and development, Jonas Karlman, Ezequiel Garcia, Daniel Vetter,
Intel Graphics Development, Rodrigo Siqueira, Laurent Pinchart,
dri-devel, Steven Price, Oleg Vasilev, Gerd Hoffmann,
Thomas Zimmermann, Robert Chiras, Jean-Jacques Hiblot, Lowry Li,
Sam Ravnborg, Qiang Yu
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
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] [PULL] drm-misc-next
2019-10-21 15:48 ` Sean Paul
@ 2019-10-22 2:17 ` Dave Airlie
2019-10-22 7:01 ` Daniel Vetter
0 siblings, 1 reply; 9+ messages in thread
From: Dave Airlie @ 2019-10-22 2:17 UTC (permalink / raw)
To: Sean Paul
Cc: Wen He, Qiang Yu, DRM maintainer tools announcements, discussion,
and development, Sam Ravnborg, Jonas Karlman, Daniel Vetter,
Intel Graphics Development, Rodrigo Siqueira, dri-devel,
Steven Price, Oleg Vasilev, Tomi Valkeinen, Laurent Pinchart,
Thomas Zimmermann, Robert Chiras, Jean-Jacques Hiblot, Lowry Li,
Ezequiel Garcia, Gerd Hoffmann
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.
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] [PULL] drm-misc-next
2019-10-22 2:17 ` [Intel-gfx] " Dave Airlie
@ 2019-10-22 7:01 ` Daniel Vetter
0 siblings, 0 replies; 9+ messages in thread
From: Daniel Vetter @ 2019-10-22 7:01 UTC (permalink / raw)
To: Dave Airlie
Cc: Wen He, Qiang Yu, DRM maintainer tools announcements, discussion,
and development, Sam Ravnborg, Jonas Karlman, Sean Paul,
Intel Graphics Development, Rodrigo Siqueira, dri-devel,
Steven Price, Oleg Vasilev, Tomi Valkeinen, Laurent Pinchart,
Thomas Zimmermann, Robert Chiras, Jean-Jacques Hiblot, Lowry Li,
Ezequiel Garcia, Gerd Hoffmann
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
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] [PULL] drm-misc-next
2021-10-14 13:24 ` [Intel-gfx] " Hans de Goede
@ 2021-10-14 14:30 ` Hans de Goede
0 siblings, 0 replies; 9+ messages in thread
From: Hans de Goede @ 2021-10-14 14:30 UTC (permalink / raw)
To: Maxime Ripard, Dave Airlie, Daniel Vetter
Cc: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Sean Paul,
Maarten Lankhorst, Maxime Ripard, dri-devel, intel-gfx,
dim-tools
Hi,
On 10/14/21 3:24 PM, Hans de Goede wrote:
> Hi,
>
> On 10/14/21 2:04 PM, Maxime Ripard wrote:
>> Hi Dave, Daniel,
>>
>> Here's this week drm-misc-next PR
>>
>> Maxime
>>
>> drm-misc-next-2021-10-14:
>> drm-misc-next for 5.16:
>
> Ugh, this just missed the drm-privacy-screen work which I just pushed
> out to drm-misc-next (I was waiting for the last i915 integration patch
> to get reviewed).
>
> It would be nice if we can still get the drm-privacy-screen work
> included into 5.16. But if it is too late I understand.
Thinking more about this, delaying this till 5.17 is fine, that
will nicely align its release with GNOME42 which will be the
first userspace to support this; and it will give it a nice long
time to find any issues in -next (not that I expect any).
Regards,
Hans
>> UAPI Changes:
>>
>> Cross-subsystem Changes:
>>
>> Core Changes:
>> - fbdev: Fix double-free, Remove unused scrolling acceleration
>> - locking: improve logging for contented locks without backoff
>> - dma-buf: Add dma_resv_for_each_fence iterator, and conversion of
>> users
>>
>> Driver Changes:
>> - nouveau: Various code style improvements
>> - bridge: HPD improvements for lt9611uxc, eDP aux-bus support for
>> ps8640, lvds-codec data-mapping selection support
>> - panels: Vivax TPC-9150, Innolux G070Y2-T02, LOGIC Technologies
>> LTTD800480070-L2RT, Sharp LS060T1SX01,
>> The following changes since commit 9962601ca5719050906915c3c33a63744ac7b15c:
>>
>> drm/bridge: dw-hdmi-cec: Make use of the helper function devm_add_action_or_reset() (2021-10-06 11:21:46 +0200)
>>
>> are available in the Git repository at:
>>
>> git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-10-14
>>
>> for you to fetch changes up to b3ec8cdf457e5e63d396fe1346cc788cf7c1b578:
>>
>> fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list) (2021-10-13 15:29:23 +0200)
>>
>> ----------------------------------------------------------------
>> drm-misc-next for 5.16:
>>
>> UAPI Changes:
>>
>> Cross-subsystem Changes:
>>
>> Core Changes:
>> - fbdev: Fix double-free, Remove unused scrolling acceleration
>> - locking: improve logging for contented locks without backoff
>> - dma-buf: Add dma_resv_for_each_fence iterator, and conversion of
>> users
>>
>> Driver Changes:
>> - nouveau: Various code style improvements
>> - bridge: HPD improvements for lt9611uxc, eDP aux-bus support for
>> ps8640, lvds-codec data-mapping selection support
>> - panels: Vivax TPC-9150, Innolux G070Y2-T02, LOGIC Technologies
>> LTTD800480070-L2RT, Sharp LS060T1SX01,
>>
>> ----------------------------------------------------------------
>> Alex Xu (Hello71) (1):
>> drm/plane-helper: fix uninitialized variable reference
>>
>> Amos Kong (1):
>> drm/ttm_bo_api: update the description for @placement and @sg
>>
>> Christian König (7):
>> dma-buf: add dma_resv_for_each_fence v3
>> dma-buf: use the new iterator in dma_buf_debug_show
>> dma-buf: use the new iterator in dma_resv_poll
>> drm/ttm: use the new iterator in ttm_bo_flush_all_fences
>> drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2
>> drm/i915: use the new iterator in i915_request_await_object v2
>> drm: use new iterator in drm_gem_fence_array_add_implicit v3
>>
>> Claudio Suarez (1):
>> fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)
>>
>> Dan Carpenter (1):
>> drm/v3d: fix copy_from_user() error codes
>>
>> David Heidelberg (1):
>> dt-bindings: display: simple: hardware can use ddc-i2c-bus
>>
>> Dmitry Baryshkov (5):
>> drm/bridge/lontium-lt9611uxc: fix provided connector suport
>> dt-bindings: add bindings for the Sharp LS060T1SX01 panel
>> drm/panel: Add support for Sharp LS060T1SX01 panel
>> dt-bindings: add bindings for the Sharp LS060T1SX01 panel
>> drm/panel: Add support for Sharp LS060T1SX01 panel
>>
>> Guido Günther (5):
>> drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts
>> drm/panel: mantix: Add media bus format
>> drm/panel: st7703: Add media bus format
>> drm: mxsfb: Print failed bus format in hex
>> drm: mxsfb: Set fallback bus format when the bridge doesn't provide one
>>
>> Jani Nikula (1):
>> drm/locking: add backtrace for locking contended locks without backoff
>>
>> Jing Xiangfeng (1):
>> drm/virtio: fix the missed drm_gem_object_put() in virtio_gpu_user_framebuffer_create()
>>
>> Karol Herbst (1):
>> drm/nouveau/mmu/gp100: remove unused variable
>>
>> Lee Jones (1):
>> drm/nouveau/nouveau_bo: Remove unused variables 'dev'
>>
>> Luo penghao (2):
>> drm/nouveau/mmu: drop unneeded assignment in the nvkm_uvmm_mthd_page()
>> drm/nouveau/mmu/gp100-: drop unneeded assignment in the if condition.
>>
>> Marek Vasut (3):
>> drm/bridge: ti-sn65dsi83: Implement .detach callback
>> dt-bindings: display: bridge: lvds-codec: Document LVDS data mapping select
>> drm/bridge: lvds-codec: Add support for LVDS data mapping select
>>
>> Nikola Pavlica (2):
>> dt-bindings: add vendor prefix for Vivax
>> dt-bindings: display: simple: Add Vivax TPC-9150 panel
>>
>> Oleksij Rempel (1):
>> dt-bindings: display: simple: add Innolux G070Y2-T02 panel
>>
>> Philip Chen (1):
>> dt-bindings: drm/bridge: ps8640: Add aux-bus child
>>
>> Randy Dunlap (1):
>> drm/connector: fix all kernel-doc warnings
>>
>> Sam Ravnborg (2):
>> Revert "drm/panel: Add support for Sharp LS060T1SX01 panel"
>> Revert "dt-bindings: add bindings for the Sharp LS060T1SX01 panel"
>>
>> Simon Ser (1):
>> drm/connector: refer to CTA-861-G in the "content type" prop docs
>>
>> Søren Andersen (1):
>> drm/panel: panel-simple: add LOGIC Technologies LTTD800480070-L2RT panel
>>
>> Tvrtko Ursulin (1):
>> dma-resv: Fix dma_resv_get_fences and dma_resv_copy_fences after conversion
>>
>> Uwe Kleine-König (1):
>> drm/panel: s6e63m0: Make s6e63m0_remove() return void
>>
>> Yang Yingliang (1):
>> drm/nouveau/gem: remove redundant semi-colon
>>
>> Zheyu Ma (1):
>> fbdev: fbmem: Fix double free of 'fb_info->pixmap.addr'
>>
>> yong yiran (1):
>> drm/nouveau/nvenc: remove duplicate include in base.c
>>
>> .../bindings/display/bridge/lvds-codec.yaml | 33 +-
>> .../devicetree/bindings/display/bridge/ps8640.yaml | 19 +-
>> .../bindings/display/panel/panel-simple.yaml | 5 +
>> .../bindings/display/panel/sharp,ls060t1sx01.yaml | 56 +++
>> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
>> Documentation/gpu/todo.rst | 13 +-
>> drivers/dma-buf/dma-buf.c | 60 +--
>> drivers/dma-buf/dma-resv.c | 69 ++-
>> drivers/gpu/drm/Kconfig | 15 +
>> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 9 +-
>> drivers/gpu/drm/bridge/lvds-codec.c | 76 ++-
>> drivers/gpu/drm/bridge/nwl-dsi.c | 35 ++
>> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 17 +-
>> drivers/gpu/drm/drm_connector.c | 32 +-
>> drivers/gpu/drm/drm_gem.c | 26 +-
>> drivers/gpu/drm/drm_modeset_lock.c | 49 +-
>> drivers/gpu/drm/drm_plane_helper.c | 1 -
>> drivers/gpu/drm/i915/i915_request.c | 34 +-
>> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 +-
>> drivers/gpu/drm/nouveau/nouveau_bo.c | 4 -
>> drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
>> drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c | 1 -
>> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c | 2 +-
>> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 4 +-
>> drivers/gpu/drm/panel/Kconfig | 10 +
>> drivers/gpu/drm/panel/Makefile | 1 +
>> drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
>> drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c | 3 +-
>> drivers/gpu/drm/panel/panel-samsung-s6e63m0-spi.c | 3 +-
>> drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 4 +-
>> drivers/gpu/drm/panel/panel-samsung-s6e63m0.h | 2 +-
>> drivers/gpu/drm/panel/panel-sharp-ls060t1sx01.c | 333 ++++++++++++++
>> drivers/gpu/drm/panel/panel-simple.c | 35 ++
>> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8 +
>> drivers/gpu/drm/scheduler/sched_main.c | 26 +-
>> drivers/gpu/drm/ttm/ttm_bo.c | 16 +-
>> drivers/gpu/drm/v3d/v3d_gem.c | 13 +-
>> drivers/gpu/drm/virtio/virtgpu_display.c | 4 +-
>> drivers/video/fbdev/core/bitblit.c | 16 -
>> drivers/video/fbdev/core/fbcon.c | 509 +--------------------
>> drivers/video/fbdev/core/fbcon.h | 59 ---
>> drivers/video/fbdev/core/fbcon_ccw.c | 28 +-
>> drivers/video/fbdev/core/fbcon_cw.c | 28 +-
>> drivers/video/fbdev/core/fbcon_rotate.h | 9 -
>> drivers/video/fbdev/core/fbcon_ud.c | 37 +-
>> drivers/video/fbdev/core/fbmem.c | 5 +-
>> drivers/video/fbdev/core/tileblit.c | 16 -
>> drivers/video/fbdev/skeletonfb.c | 12 +-
>> include/drm/drm_modeset_lock.h | 8 +
>> include/drm/ttm/ttm_bo_api.h | 6 +-
>> include/linux/dma-resv.h | 25 +-
>> include/linux/fb.h | 2 +-
>> 52 files changed, 939 insertions(+), 860 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml
>> create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls060t1sx01.c
>>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Intel-gfx] [PULL] drm-misc-next
2021-10-14 12:04 Maxime Ripard
@ 2021-10-14 13:24 ` Hans de Goede
2021-10-14 14:30 ` Hans de Goede
0 siblings, 1 reply; 9+ messages in thread
From: Hans de Goede @ 2021-10-14 13:24 UTC (permalink / raw)
To: Maxime Ripard, Dave Airlie, Daniel Vetter
Cc: Jani Nikula, Joonas Lahtinen, Rodrigo Vivi, Sean Paul,
Maarten Lankhorst, Maxime Ripard, dri-devel, intel-gfx,
dim-tools
Hi,
On 10/14/21 2:04 PM, Maxime Ripard wrote:
> Hi Dave, Daniel,
>
> Here's this week drm-misc-next PR
>
> Maxime
>
> drm-misc-next-2021-10-14:
> drm-misc-next for 5.16:
Ugh, this just missed the drm-privacy-screen work which I just pushed
out to drm-misc-next (I was waiting for the last i915 integration patch
to get reviewed).
It would be nice if we can still get the drm-privacy-screen work
included into 5.16. But if it is too late I understand.
Regards,
Hans
>
> UAPI Changes:
>
> Cross-subsystem Changes:
>
> Core Changes:
> - fbdev: Fix double-free, Remove unused scrolling acceleration
> - locking: improve logging for contented locks without backoff
> - dma-buf: Add dma_resv_for_each_fence iterator, and conversion of
> users
>
> Driver Changes:
> - nouveau: Various code style improvements
> - bridge: HPD improvements for lt9611uxc, eDP aux-bus support for
> ps8640, lvds-codec data-mapping selection support
> - panels: Vivax TPC-9150, Innolux G070Y2-T02, LOGIC Technologies
> LTTD800480070-L2RT, Sharp LS060T1SX01,
> The following changes since commit 9962601ca5719050906915c3c33a63744ac7b15c:
>
> drm/bridge: dw-hdmi-cec: Make use of the helper function devm_add_action_or_reset() (2021-10-06 11:21:46 +0200)
>
> are available in the Git repository at:
>
> git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2021-10-14
>
> for you to fetch changes up to b3ec8cdf457e5e63d396fe1346cc788cf7c1b578:
>
> fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list) (2021-10-13 15:29:23 +0200)
>
> ----------------------------------------------------------------
> drm-misc-next for 5.16:
>
> UAPI Changes:
>
> Cross-subsystem Changes:
>
> Core Changes:
> - fbdev: Fix double-free, Remove unused scrolling acceleration
> - locking: improve logging for contented locks without backoff
> - dma-buf: Add dma_resv_for_each_fence iterator, and conversion of
> users
>
> Driver Changes:
> - nouveau: Various code style improvements
> - bridge: HPD improvements for lt9611uxc, eDP aux-bus support for
> ps8640, lvds-codec data-mapping selection support
> - panels: Vivax TPC-9150, Innolux G070Y2-T02, LOGIC Technologies
> LTTD800480070-L2RT, Sharp LS060T1SX01,
>
> ----------------------------------------------------------------
> Alex Xu (Hello71) (1):
> drm/plane-helper: fix uninitialized variable reference
>
> Amos Kong (1):
> drm/ttm_bo_api: update the description for @placement and @sg
>
> Christian König (7):
> dma-buf: add dma_resv_for_each_fence v3
> dma-buf: use the new iterator in dma_buf_debug_show
> dma-buf: use the new iterator in dma_resv_poll
> drm/ttm: use the new iterator in ttm_bo_flush_all_fences
> drm/scheduler: use new iterator in drm_sched_job_add_implicit_dependencies v2
> drm/i915: use the new iterator in i915_request_await_object v2
> drm: use new iterator in drm_gem_fence_array_add_implicit v3
>
> Claudio Suarez (1):
> fbdev: Garbage collect fbdev scrolling acceleration, part 1 (from TODO list)
>
> Dan Carpenter (1):
> drm/v3d: fix copy_from_user() error codes
>
> David Heidelberg (1):
> dt-bindings: display: simple: hardware can use ddc-i2c-bus
>
> Dmitry Baryshkov (5):
> drm/bridge/lontium-lt9611uxc: fix provided connector suport
> dt-bindings: add bindings for the Sharp LS060T1SX01 panel
> drm/panel: Add support for Sharp LS060T1SX01 panel
> dt-bindings: add bindings for the Sharp LS060T1SX01 panel
> drm/panel: Add support for Sharp LS060T1SX01 panel
>
> Guido Günther (5):
> drm/bridge: nwl-dsi: Add atomic_get_input_bus_fmts
> drm/panel: mantix: Add media bus format
> drm/panel: st7703: Add media bus format
> drm: mxsfb: Print failed bus format in hex
> drm: mxsfb: Set fallback bus format when the bridge doesn't provide one
>
> Jani Nikula (1):
> drm/locking: add backtrace for locking contended locks without backoff
>
> Jing Xiangfeng (1):
> drm/virtio: fix the missed drm_gem_object_put() in virtio_gpu_user_framebuffer_create()
>
> Karol Herbst (1):
> drm/nouveau/mmu/gp100: remove unused variable
>
> Lee Jones (1):
> drm/nouveau/nouveau_bo: Remove unused variables 'dev'
>
> Luo penghao (2):
> drm/nouveau/mmu: drop unneeded assignment in the nvkm_uvmm_mthd_page()
> drm/nouveau/mmu/gp100-: drop unneeded assignment in the if condition.
>
> Marek Vasut (3):
> drm/bridge: ti-sn65dsi83: Implement .detach callback
> dt-bindings: display: bridge: lvds-codec: Document LVDS data mapping select
> drm/bridge: lvds-codec: Add support for LVDS data mapping select
>
> Nikola Pavlica (2):
> dt-bindings: add vendor prefix for Vivax
> dt-bindings: display: simple: Add Vivax TPC-9150 panel
>
> Oleksij Rempel (1):
> dt-bindings: display: simple: add Innolux G070Y2-T02 panel
>
> Philip Chen (1):
> dt-bindings: drm/bridge: ps8640: Add aux-bus child
>
> Randy Dunlap (1):
> drm/connector: fix all kernel-doc warnings
>
> Sam Ravnborg (2):
> Revert "drm/panel: Add support for Sharp LS060T1SX01 panel"
> Revert "dt-bindings: add bindings for the Sharp LS060T1SX01 panel"
>
> Simon Ser (1):
> drm/connector: refer to CTA-861-G in the "content type" prop docs
>
> Søren Andersen (1):
> drm/panel: panel-simple: add LOGIC Technologies LTTD800480070-L2RT panel
>
> Tvrtko Ursulin (1):
> dma-resv: Fix dma_resv_get_fences and dma_resv_copy_fences after conversion
>
> Uwe Kleine-König (1):
> drm/panel: s6e63m0: Make s6e63m0_remove() return void
>
> Yang Yingliang (1):
> drm/nouveau/gem: remove redundant semi-colon
>
> Zheyu Ma (1):
> fbdev: fbmem: Fix double free of 'fb_info->pixmap.addr'
>
> yong yiran (1):
> drm/nouveau/nvenc: remove duplicate include in base.c
>
> .../bindings/display/bridge/lvds-codec.yaml | 33 +-
> .../devicetree/bindings/display/bridge/ps8640.yaml | 19 +-
> .../bindings/display/panel/panel-simple.yaml | 5 +
> .../bindings/display/panel/sharp,ls060t1sx01.yaml | 56 +++
> .../devicetree/bindings/vendor-prefixes.yaml | 2 +
> Documentation/gpu/todo.rst | 13 +-
> drivers/dma-buf/dma-buf.c | 60 +--
> drivers/dma-buf/dma-resv.c | 69 ++-
> drivers/gpu/drm/Kconfig | 15 +
> drivers/gpu/drm/bridge/lontium-lt9611uxc.c | 9 +-
> drivers/gpu/drm/bridge/lvds-codec.c | 76 ++-
> drivers/gpu/drm/bridge/nwl-dsi.c | 35 ++
> drivers/gpu/drm/bridge/ti-sn65dsi83.c | 17 +-
> drivers/gpu/drm/drm_connector.c | 32 +-
> drivers/gpu/drm/drm_gem.c | 26 +-
> drivers/gpu/drm/drm_modeset_lock.c | 49 +-
> drivers/gpu/drm/drm_plane_helper.c | 1 -
> drivers/gpu/drm/i915/i915_request.c | 34 +-
> drivers/gpu/drm/mxsfb/mxsfb_kms.c | 8 +-
> drivers/gpu/drm/nouveau/nouveau_bo.c | 4 -
> drivers/gpu/drm/nouveau/nouveau_gem.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/engine/nvenc/base.c | 1 -
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/uvmm.c | 2 +-
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 4 +-
> drivers/gpu/drm/panel/Kconfig | 10 +
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-mantix-mlaf057we51.c | 9 +
> drivers/gpu/drm/panel/panel-samsung-s6e63m0-dsi.c | 3 +-
> drivers/gpu/drm/panel/panel-samsung-s6e63m0-spi.c | 3 +-
> drivers/gpu/drm/panel/panel-samsung-s6e63m0.c | 4 +-
> drivers/gpu/drm/panel/panel-samsung-s6e63m0.h | 2 +-
> drivers/gpu/drm/panel/panel-sharp-ls060t1sx01.c | 333 ++++++++++++++
> drivers/gpu/drm/panel/panel-simple.c | 35 ++
> drivers/gpu/drm/panel/panel-sitronix-st7703.c | 8 +
> drivers/gpu/drm/scheduler/sched_main.c | 26 +-
> drivers/gpu/drm/ttm/ttm_bo.c | 16 +-
> drivers/gpu/drm/v3d/v3d_gem.c | 13 +-
> drivers/gpu/drm/virtio/virtgpu_display.c | 4 +-
> drivers/video/fbdev/core/bitblit.c | 16 -
> drivers/video/fbdev/core/fbcon.c | 509 +--------------------
> drivers/video/fbdev/core/fbcon.h | 59 ---
> drivers/video/fbdev/core/fbcon_ccw.c | 28 +-
> drivers/video/fbdev/core/fbcon_cw.c | 28 +-
> drivers/video/fbdev/core/fbcon_rotate.h | 9 -
> drivers/video/fbdev/core/fbcon_ud.c | 37 +-
> drivers/video/fbdev/core/fbmem.c | 5 +-
> drivers/video/fbdev/core/tileblit.c | 16 -
> drivers/video/fbdev/skeletonfb.c | 12 +-
> include/drm/drm_modeset_lock.h | 8 +
> include/drm/ttm/ttm_bo_api.h | 6 +-
> include/linux/dma-resv.h | 25 +-
> include/linux/fb.h | 2 +-
> 52 files changed, 939 insertions(+), 860 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/display/panel/sharp,ls060t1sx01.yaml
> create mode 100644 drivers/gpu/drm/panel/panel-sharp-ls060t1sx01.c
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2021-10-14 14:30 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-17 19:26 [PULL] drm-misc-next Sean Paul
2019-10-18 13:45 ` Tomi Valkeinen
2019-10-18 20:11 ` Sean Paul
2019-10-21 8:09 ` Tomi Valkeinen
2019-10-21 15:48 ` Sean Paul
2019-10-22 2:17 ` [Intel-gfx] " Dave Airlie
2019-10-22 7:01 ` Daniel Vetter
2021-10-14 12:04 Maxime Ripard
2021-10-14 13:24 ` [Intel-gfx] " Hans de Goede
2021-10-14 14:30 ` Hans de Goede
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).