search for: drm_fb_helpers

Hi Boris, Thank you for the patch. On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote: > Adapt drm_pick_crtcs() and update_connector_routing() to fallback to > drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so > that DRM drivers can leave this hook unassigned if they know they want > to use drm_atomic_helper_best_encoder(). Could you please update

Hi Boris, Thank you for the patch. On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote: > Adapt drm_pick_crtcs() and update_connector_routing() to fallback to > drm_atomic_helper_best_encoder() if funcs->best_encoder() is NULL so > that DRM drivers can leave this hook unassigned if they know they want > to use drm_atomic_helper_best_encoder(). Could you please update

On Mon, Jul 30, 2018 at 08:39:48PM -0400, Lyude Paul wrote: > I'm sure I don't need to tell you that fb_helper's locking is a mess. > That being said; fb_helper's locking mess can seriously complicate the > runtime suspend/resume operations of drivers because it can invoke > atomic commits and connector probing from anywhere that calls >

I'm sure I don't need to tell you that fb_helper's locking is a mess. That being said; fb_helper's locking mess can seriously complicate the runtime suspend/resume operations of drivers because it can invoke atomic commits and connector probing from anywhere that calls drm_fb_helper_hotplug_event(). Since most drivers use drm_fb_helper_output_poll_changed() as their

KMS drivers really should all be able to restore their display state on resume without fbcon helping out. So make this the default. Since I'm not entirely foolish, make it only a default, which drivers can still override. That way when the inevitable regression report happens I can fix things up with a one-liner plus FIXME comment that someone should fix up the suspend/resume code in that

Hi Am 03.07.19 um 21:27 schrieb Noralf Tr?nnes: > > > Den 03.07.2019 10.32, skrev Thomas Zimmermann: >> DRM client buffers are permanently mapped throughout their lifetime. This >> prevents us from using generic framebuffer emulation for devices with >> small dedicated video memory, such as ast or mgag200. With fb buffers >> permanently mapped, such devices

Hi Am 03.07.19 um 21:27 schrieb Noralf Tr?nnes: > > > Den 03.07.2019 10.32, skrev Thomas Zimmermann: >> DRM client buffers are permanently mapped throughout their lifetime. This >> prevents us from using generic framebuffer emulation for devices with >> small dedicated video memory, such as ast or mgag200. With fb buffers >> permanently mapped, such devices

Den 05.07.2019 11.26, skrev Thomas Zimmermann: > Generic framebuffer emulation uses a shadow buffer for framebuffers with > dirty() function. If drivers want to use the shadow FB without such a > function, they can now set prefer_shadow or prefer_shadow_fbdev in their > mode_config structures. The former flag is exported to userspace, the latter > flag is fbdev-only. > >

Den 05.07.2019 11.26, skrev Thomas Zimmermann: > Generic framebuffer emulation uses a shadow buffer for framebuffers with > dirty() function. If drivers want to use the shadow FB without such a > function, they can now set prefer_shadow or prefer_shadow_fbdev in their > mode_config structures. The former flag is exported to userspace, the latter > flag is fbdev-only. > >

This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get totally obsolete. I think the gamma_store can end up invalid on error. But the way I read it, that can happen in drm_mode_gamma_set_ioctl as well, so why should this pesky legacy fbdev stuff be any better? drm_fb_helper_save_lut_atomic justs saves the gamma lut for later. However, it saves it to the gamma_store which should

On Mon, 2018-08-06 at 10:43 +0200, Daniel Vetter wrote: > On Mon, Jul 30, 2018 at 08:39:48PM -0400, Lyude Paul wrote: > > I'm sure I don't need to tell you that fb_helper's locking is a mess. > > That being said; fb_helper's locking mess can seriously complicate the > > runtime suspend/resume operations of drivers because it can invoke > > atomic commits

Den 04.07.2019 09.43, skrev Thomas Zimmermann: > Hi > > Am 03.07.19 um 21:27 schrieb Noralf Tr?nnes: >> >> >> Den 03.07.2019 10.32, skrev Thomas Zimmermann: >>> DRM client buffers are permanently mapped throughout their lifetime. This >>> prevents us from using generic framebuffer emulation for devices with >>> small dedicated video memory,

On Thu, 2 Jun 2016 23:57:02 +0200 Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart > <laurent.pinchart at ideasonboard.com> wrote: > > Hi Boris, > > > > Thank you for the patch. > > > > On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote: > >> Adapt drm_pick_crtcs() and

On Thu, 2 Jun 2016 23:57:02 +0200 Daniel Vetter <daniel at ffwll.ch> wrote: > On Thu, Jun 2, 2016 at 11:05 PM, Laurent Pinchart > <laurent.pinchart at ideasonboard.com> wrote: > > Hi Boris, > > > > Thank you for the patch. > > > > On Thursday 02 Jun 2016 16:31:28 Boris Brezillon wrote: > >> Adapt drm_pick_crtcs() and

Hi Thomas. On Thu, Oct 15, 2020 at 02:38:06PM +0200, Thomas Zimmermann wrote: > At least sparc64 requires I/O-specific access to framebuffers. This > patch updates the fbdev console accordingly. > > For drivers with direct access to the framebuffer memory, the callback > functions in struct fb_ops test for the type of memory and call the rsp > fb_sys_ of fb_cfb_ functions. >

KMS drivers really should all be able to restore their display state on resume without fbcon helping out. So make this the default. Since I'm not entirely foolish, make it only a default, which drivers can still override. That way when the inevitable regression report happens I can fix things up with a one-liner plus FIXME comment that someone should fix up the suspend/resume code in that

This is the next version of https://patchwork.freedesktop.org/series/46815/ With a lot more thought put into it so as to avoid the potential deadlock scenarios I missed. This also required fixing some bogus DRM helper usage. Try and deadlock me now, nouveau. I dare you!!! Lyude Paul (8): drm/nouveau: Fix bogus drm_kms_helper_poll_enable() placement drm/nouveau: Enable polling even if we

This makes the redundant fb helpers .load_lut, .gamma_set and .gamma_get totally obsolete. Signed-off-by: Peter Rosin <peda at axentia.se> --- drivers/gpu/drm/drm_fb_helper.c | 154 ++++++++++++++++------------------------ 1 file changed, 63 insertions(+), 91 deletions(-) diff --git a/drivers/gpu/drm/drm_fb_helper.c b/drivers/gpu/drm/drm_fb_helper.c index 7ade384..58eb045 100644 ---

On Tue, Oct 20, 2020 at 02:20:44PM +0200, Thomas Zimmermann wrote: > Kernel DRM clients now store their framebuffer address in an instance > of struct dma_buf_map. Depending on the buffer's location, the address > refers to system or I/O memory. > > Callers of drm_client_buffer_vmap() receive a copy of the value in > the call's supplied arguments. It can be accessed and

This check is useful for drivers that do not have DRIVER_ATOMIC set but have atomic modesetting internally implemented. Wrap the check into a function since this is used in many places and as a bonus, the function name helps to document what the check is for. v2: Change return type to bool (Ville) Move the function drm_atomic.h (Daniel) Fixed comment marker for documentation v3: Included drmP.h