so
there's some risk I think. Otoh I also don't see anything that would
unbreak the lifelook, so feels minimally.
With that impact to pushbuf ioctl documented in the commit message somehow
this is Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.
On Tue, Jul 21, 2020 at 09:32:37AM +0200, Christian König wrote:
> Just use the use_io_reserve_lru flag. It doesn't make much
> sense to have two flags.
>
> Signed-off-by: Christian König
Yeah looks entirely redundant.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/d
On Tue, Jul 21, 2020 at 09:32:38AM +0200, Christian König wrote:
> Only functional change is to always keep io_reserved_count up to date
> for debugging even when it is not used otherwise.
Functional change in a cleanup patch. Tsk. It looks correct though ...
Reviewed-by: Daniel
ent & TTM_PL_MASK_CACHING) == 0)) {
> - ret = ttm_mem_io_lock(old_man, true);
> - if (unlikely(ret != 0))
> - goto out_err;
> - ttm_bo_unmap_virtual_locked(bo);
> - ttm_mem_io_unlock(old_man);
> - }
Fast
}
> - if (!rdev->ddev->agp->cant_use_aperture)
> - man->flags = TTM_MEMTYPE_FLAG_MAPPABLE;
There is a bunch of agp drivers (alpha, ppc, that kind of stuff) with this
flag set. And radeon.ko did at least once work on these. And your
On Tue, Jul 21, 2020 at 09:32:41AM +0200, Christian König wrote:
> The driver doesn't expose any not-mapable memory resources.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 9 ++---
> 1 file chan
struct drm_mm_node *mm_node = mem->mm_node;
>
> @@ -805,8 +803,7 @@ static int amdgpu_ttm_io_mem_reserve(struct ttm_bo_device
> *bdev, struct ttm_mem_
> mem->bus.size = mem->num_pages << PAGE_SHIFT;
> mem->bus.base = 0;
> mem->bus.i
On Tue, Jul 21, 2020 at 09:32:43AM +0200, Christian König wrote:
> The driver doesn't expose any not-mapable memory resources.
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/nouveau/nouveau_bo.c | 13 +
> 1 file chan
On Tue, Jul 21, 2020 at 09:32:44AM +0200, Christian König wrote:
> The driver doesn't expose any not-mapable memory resources.
>
> v2: remove unused man variable as well
>
> Signed-off-by: Christian König
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/qxl/qx
checks whether a buffer can
be mappable directly, instead of going through the indirection of using
this flag.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Also watching the steps of vkms_crtc_atomic_flush, when the very first
> drm_crtc_vblank_get returned an error, the subtest crashed. On the other
> hand, when vblank_get succeeded, the subtest completed. Finally, checking
> the flush steps: it increases counter to hold a vblank reference
rmm_add_action_or_reset is indeed the way to go, except we probably want
some helpers to wrap the allocation, drm_foo_init and adding the reset
action all into one thing (plus you can stuff the reset action into the
allocation instead of the kfree action only, even nicer that way).
But that'
ch means drm_mode_config_cleanup won't even see it. But
if the driver has some additional code in ->cleanup that won't ever run,
so probably still a bug.
I also think that the drmm_foo_ wrappers should also do the allocation
(and upcasting) kinda like drmm_dev_alloc(). Otherwise we'
e rollout")
> Signed-off-by: Li Heng
Queued up, should make it into 5.9 merge window, thanks for your patch.
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/dr
goto out_no_sys;
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> index 1d78187eaba6..00cef1a3a178 100644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
>
ject *bo,
> if (ret)
> return ret;
>
> - if (to->flags & TTM_MEMTYPE_FLAG_FIXED) {
> + if (!to->use_tt) {
> ttm_tt_destroy(bo->ttm);
> bo->ttm = NULL;
>
(struct ttm_buffer_object *bo,
> > >* bo to be unbound and destroyed.
> > >*/
> > > - if (!(to->flags & TTM_MEMTYPE_FLAG_FIXED))
> > > + if (to->use_tt)
> > >
r-y (having a per-type cast in a callback is a very clear
signal something with the layering is all busted). So removing this sounds
like a good idea, but not really following why just for radeon? Or simply
wip?
-Daniel
> ---
> drivers/gpu/drm/radeon/radeon_ttm.c | 70 ++--
or radeon? Or simply
> wip?
nvm, I've seen the next series :-) And Alex already r-b'ed it.
-Daniel
>
>
>
> > ---
> > drivers/gpu/drm/radeon/radeon_ttm.c | 70 ++---
> > 1 file changed, 35 insertions(+), 35 deletions(-)
h I kinda want to wait until we cross that bridge ... this entire vendor
heaps thing still sounds very much like vendor trees hacking around
instead of having upstream drivers using upstream infrastructure.
-Daniel
>
> Cc: Sumit Semwal
> Cc: Andrew F. Davis
> Cc: Benjamin Gaignard
The patch also replaces a reference to drm_crtc_state.allow_modeset with
> the correct call to drm_atomic_crtc_needs_modeset().
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
>
"store random stuff
in private structures" (they're not even atomic state structures, it's the
driver private thing even!) is very non-atomic. And I see zero reasons why
you have to do this, the cursor stays around.
-Daniel
>
> Signed-off-by: Thomas Zimmermann
> F
sible drivers that
are forced to hack around the helper midlayer in their callbacks like the
below very much looks like.
-Daniel
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Sam Ravnborg
> Cc: Emil Velikov
> Cc: "Y.C. Chen&q
gt; Care to send a v3?
Don't worry, I'm pushing this to drm-misc-fixes now, should still make it
to 5.8. Plus cc: stable. I didn't bother with Fixes: since I think the bug
is rather old. Also, worst case you leak 32bit of some kernel
>
> > > Care to send a v3?
> >
> > Don't worry, I'm pushing this to drm-misc-fixes now, should still make
> > it
> > to 5.8. Plus cc: stable. I didn't bother with Fixes: since I think the
> > bug
> > is rather old. Also, worst case y
On Mon, Jul 27, 2020 at 10:49:48PM -0400, Kazlauskas, Nicholas wrote:
> On 2020-07-27 5:32 p.m., Daniel Vetter wrote:
> > On Mon, Jul 27, 2020 at 11:11 PM Mazin Rezk wrote:
> > >
> > > On Monday, July 27, 2020 4:29 PM, Daniel Vetter wrote:
> > >
>
this looks a bit like ttm_bo_swapout_all shouldn't even be exported
really, it's part of the internal shrinker stuff.
-Daniel
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 2 +-
> include/drm/ttm
y this would be nice I think.
Maybe as a follow-up refactor?
-Daniel
> ---
> drivers/gpu/drm/ast/ast_dp501.c | 23 ++-
> drivers/gpu/drm/ast/ast_drv.h | 1 -
> drivers/gpu/drm/ast/ast_main.c | 3 ---
> 3 files changed, 14 insertions(+), 13 deletions(-)
>
mware after the device is gone, so
I think this is one of the very rare exceptions where devm_kzalloc is the
right thing to do! Totally minor nit though, since either way it gets
cleaned up. But I think conceptually cleaner.
-Daniel
> ---
> drivers/gpu/drm/ast/ast_main.c | 7 +++
> 1 f
e connector is already gone. At the end of the series it's
fine again though.
I've done a very cursory reading of your series to look for high-level
issues, I think overall reasonable. On the series:
Acked-by: Daniel Vetter
But maybe you want to polish a bit more, up to you.
-Dani
On Mon, Jul 27, 2020 at 03:51:06PM -0500, Daniel Dadap wrote:
> Changes to allow vga-switcheroo to switch the mux while modesetting
> clients remain active. There is existing support for switching the
> mux without checking can_switch; however, this support also does not
> reprobe a
nted devres functions in todo.rst makes sense.
For devres it depends which subsystem you're dealing with I guess, and how
much they want to see before it lands.
-Daniel
>
> Best regards
> Thomas
>
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/a
On Tue, Jul 28, 2020 at 04:16:34PM +, Sidong Yang wrote:
> On Sun, Jul 26, 2020 at 12:26:08PM +0200, Daniel Vetter wrote:
> > On Sat, Jul 25, 2020 at 9:29 PM Melissa Wen wrote:
> > >
> > > On Sat, Jul 25, 2020 at 4:19 PM Melissa Wen wrote:
> > > >
/context swap idea should make the use-after-free behave how it
> > > did in 5.6. Since the bug doesn't cause an issue in 5.6, it's less of a
> > > "less disturbance" workaround and more of a "no disturbance" workaround.
> >
> > Sorry f
s fine, you can add my:
> Reviewed-by: Sam Ravnborg
>
> I assume you will apply the patches.
> Maybe wait for Daniel to take a look, he had some feedback on where
> to add checks. I assume this is covered by the second patch.
Yeah changelog for new versions would be great, but aside
Hi Hyun Kwon,
Are you all sorted with drm-misc commit rights so you can push the 3
(maybe there's more) xlnx fixup patches to drm-misc-next-fixes?
Cheers, Daniel
On Sat, Jul 25, 2020 at 06:34:29AM +, Wei Yongjun wrote:
> Fix typo in parameter description.
>
> Fixes: d762
On Wed, Jul 29, 2020 at 03:41:44PM +0200, Thomas Zimmermann wrote:
> Removes trailing whitespaces in several places.
>
> Signed-off-by: Thomas Zimmermann
checkpatch patch for fbdev, I'm blown :-)
Acked-by: Daniel Vetter
> ---
> drivers/video/fbdev/core/fbmem.c | 10 +
ble), cfb vs sys here. This
entire fbmem.c stuff is pretty bad midlayer, trying to avoid code
duplication here doesn't seem worth it imo.
Thoughts?
-Daniel
> ---
> drivers/video/fbdev/core/fbmem.c | 53 ++--
> include/linux/fb.h | 5 +++
void vaddr;
};
};
And then having a wrapper for memcpy_from_dma_buf_addr and
memcpy_to_dma_buf_addr, which switches between memcpy and memcpy_from/toio
depending upon the is_iomem flag.
But it's a lot more invasive unfortunately :-/
-Daniel
> ---
> drive
On Thu, Jul 30, 2020 at 07:09:25AM -0300, Melissa Wen wrote:
> On 07/29, Daniel Vetter wrote:
> > On Wed, Jul 29, 2020 at 9:09 PM Melissa Wen wrote:
> > >
> > > Melissa Wen
> > >
> > > On Sat, Jul 25, 2020 at 3:12 PM Daniel Vetter wrote:
> >
; >
> > > > Cheers,
> > > > -Paul
> > > >
> > > > Paul Cercueil (2):
> > > > drm/ingenic: Handle errors of drm_atomic_get_plane_state
> > > > drm/ingenic: Validate mode in a .mode_valid callback
> > >
&
x27;s going on. Or are we
covered already by a different lock (but then maybe the check here should
be moved, and a comment added about which spinlock protects this).
The other question: How did you even end up in here? I think the better
fix would be to make sure the mode we're settin
ct
> + * will not go away until the handle is deleted.
Applied, thanks.
-Daniel
> */
> int
> drm_gem_open_ioctl(struct drm_device *dev, void *data,
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> a Linux Foundation Collaborative Pro
On Wed, Jul 29, 2020 at 06:36:03PM +0200, Sam Ravnborg wrote:
> Hi Daniel.
>
> On Wed, Jul 29, 2020 at 03:53:28PM +0200, dan...@ffwll.ch wrote:
> > On Wed, Jul 29, 2020 at 03:41:45PM +0200, Thomas Zimmermann wrote:
> > > DRM fb helpers require read and write functions for
/* next line */
> src = /* next line */
> }
>
> drm_gem_vunmap(gbo);
>
> The whole mess about I/O access would be self-contained.
Copying the irc discussion over: We've had that idea floating around years
ago, i915-gem even implemented in the form of pwrite/
sn't very friendly for newbies, apologies.
-Daniel
>
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_panel_orientation_quirks.c
> b/drivers/gpu/drm/drm_panel_orientation_quirks.c
&
map_clear(vaddr_out + src_offset, 24, 8);
Yeah that's a pretty good "oops" oversight on review, nice catch!
Cheers, Daniel
> crc = crc32_le(crc, vaddr_out + src_offset,
> sizeof(u32));
>
into ttm_resource and
> ttm_mem_type_manager into ttm_resource_manager.
+1 on names I can understand, I alwas get confused about what exactly ttm
means with mem_reg and mem_type_manager.
-Daniel
>
> Neither amdgpu's OA/GWS resources nor the IDs in VMGFX are really memory.
>
> In th
&& man->func->debug)
> (*man->func->debug)(man, p);
> }
Bit a bikeshed, but what about exporting this function (maybe with the man
as argument, not the bdev, mem_type pair) and using it in the first 2
patches? Avoids surprises with optional func->
>
> Signed-off-by: Dave Airlie
Maybe I'm missing something, but doesn't this boild down to:
tmm_mm_used(type) = (bool) ttm_manager_type(type)
now that all resource managers are explicitly registered? I think there's
nothing else left, your ttm_set_driver_manager essen
ice shrinker. And then global kinda completely disappears (minus
maybe a drm-global limit on how much crap you can permanently pin in
system memory for scanout, but that's a different thing I think).
-Daniel
> struct ttm_mem_type_manager *man_drv[TTM_NUM_MEM_TYPES]
d I started introducing
> errors, so I left it alone, and it's not necessary until the patch
> that changes it's definition anyways.
I like this ordering a lot better, it gives a clear separation between the
different steps. Some code gets touched mu
On Sat, Aug 01, 2020 at 08:17:13AM +0200, Christoph Hellwig wrote:
> This symbols isn't used anywhere outside of vgaarb.c.
>
> Signed-off-by: Christoph Hellwig
Nice catch, patch queued up for 5.9.
Thanks, Daniel
> ---
> drivers/gpu/vga/vgaarb.c | 3 +--
> inclu
On Sat, Aug 01, 2020 at 05:39:50PM +0300, Lionel Landwerlin wrote:
> On 01/08/2020 12:26, Daniel Vetter wrote:
> > Userspace can provoke this, we generally don't allow userspace to spam
> > dmesg. Tune it down to debug. Unfortunately we don't have easy access
> > to
> old_{rows,row_size} values which were saved before calling resize_screen().
>
> Daniel Vetter explained that resize_screen() should not recurse into
> fbcon_update_vcs() path due to FBINFO_MISC_USEREVENT being still set
> when calling resize_screen().
>
> Instead of mas
On Mon, Aug 03, 2020 at 08:46:34AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 02.08.20 um 22:01 schrieb Sam Ravnborg:
> > On Fri, Jul 31, 2020 at 11:20:33AM +0200, dan...@ffwll.ch wrote:
> >> On Wed, Jul 29, 2020 at 06:36:03PM +0200, Sam Ravnborg wrote:
> >>>
treats the warning. I believe that
> in the body of the commit message, it would be nice to have the warning
> that this patch addresses, and when it appears by running an IGT test.
> Also, say why it should be done this way in vkms.
> This info could help future debugging.
Yeah I t
On Sat, Aug 01, 2020 at 03:34:46PM +0300, Marius Iacob wrote:
> Signed-off-by: Marius Iacob
Queued up for the 5.9 merge window. I also added cc: stable.
-Daniel
> ---
> drivers/gpu/drm/drm_panel_orientation_quirks.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff -
cquires a vblank ref when setup CRC source
> and releases ref when disabling crc capture, ensuring vblanks happen to
> compute CRC.
>
> Cc: Rodrigo Siqueira
> Cc: Haneen Mohammed
> Co-developed-by: Sidong Yang
> Signed-off-by: Sidong Yang
> Co-developed-by: Daniel Ve
with
> less ifdef's and thus more readable code.
>
> The set/get methods hides some of the confusing power states, limiting
> the power state to either ON or OFF for the drivers.
>
> Signed-off-by: Sam Ravnborg
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo
eeds backlight patches queued up outside of drm there's two
options:
- merge the backlight stuff through drm-misc (imo simplest, we have all
the fbdev stuff in there too by now)
- shared topic branch merged in drm-misc and optionally backlight tree
Otherwise this is going to be a pain to me
e actually need the direct
bl->props.brightness value.
I think an even cleaner way to solve this would be to change the
get_brightness code in actual_brightness_show to handle negative error
codes from ->get_brightness and use that to fall back to
bd->props.brightness, then we coul
like a helper for standard mipi dsi panel backlight would
be great, it's pretty much all the same code.
-Daniel
>
> return brightness & 0xff;
> }
> @@ -495,7 +495,7 @@ static int rad_bl_update_status(struct backlight_device
> *bl)
>
> dsi->mode_f
drm_connector and the underlying backlight device have different
lifetimes that would mean we need to refcount somewhere, or protect
drm_connector->backlight with some lock. The lock might not work because
the drm connector property paths come from the other direction than the
backlight driver
gister that framebuffer driver. I think the only case where gma500 loads
but psbdrmfb isn't set up is if it doesn't detect any outputs. I'd test
these monitors with some other linux system first (they might be simply
too broken), if that doesn't work you can quirk your system wi
reg Kroah-Hartman
If this helps to get the next gpu related entertainment at least cc'ed to
dri-devel, maybe even using an upstream driver, I'm all for it.
Acked-by: Daniel Vetter
> ---
> include/linux/module.h | 1 +
> kernel/module.c| 12
> 2
On Tue, Aug 04, 2020 at 09:56:00PM +0200, Sam Ravnborg wrote:
> Hi Daniel et al.
> On Tue, Aug 04, 2020 at 06:43:30PM +0200, dan...@ffwll.ch wrote:
> > On Sun, Aug 02, 2020 at 01:06:17PM +0200, Sam Ravnborg wrote:
> > > Add get and set operations to incapsualte access to
the offset is 0). And then this patch here removing that
again. Or cc: stable this patch here, since we seem to have a gap in
validating addfb.
-Daniel
> ---
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 14 +-
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
s with their
own ddx in their CI rig only.
This also avoids a bunch of layering and locking unprettiness, since
display code doesn't need to dig around in gem_bo side of things. On that,
there's another amdgpu_bo_get_tiling_flags in amdgpu_dm_commit_planes
which probably shoul
.interruptible = false,
> + .no_wait_gpu = false
> + };
> + struct ttm_buffer_object *bo;
> + int ret;
> +
> + ret = ttm_bo_create(&dev_priv->bdev, bo_size,
> + ttm_bo_type_device,
> + &
ulate(struct vmw_private
> *dev_priv,
>
> ret = ttm_bo_reserve(bo, false, true, NULL);
> BUG_ON(ret != 0);
> - ret = vmw_bo_driver.ttm_tt_populate(bo->ttm, &ctx);
> - if (likely(ret == 0))
> - ret = vmw_bo_map_dma(bo
man->default_caching = TTM_PL_FLAG_CACHED;
> +
> + ret = ttm_range_man_init(&dev_priv->bdev, man,
> + dev_priv->vram_size >> PAGE_SHIFT);
> +#endif
The ifdeffery here looks a bit funny, but not really less convoluted than
the old one I think.
Reviewed-by: Dani
gman->max_gmr_pages = dev_priv->max_gmr_pages;
> @@ -122,6 +128,8 @@ static int vmw_gmrid_man_init(struct ttm_mem_type_manager
> *man,
> BUG();
> }
> man->priv = (void *) gman;
> +
> + ttm_mem_type_manager_se
once we
have full sub-classing, since it's for vmwgfx internally only. Maybe add a
todo to the kernel-doc.
-Daniel
> ---
> drivers/gpu/drm/nouveau/nouveau_ttm.c | 1 -
> drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 14 +++---
t;priv = NULL;
> - return 0;
> - }
> + drm_mm_clean(mm);
> + drm_mm_takedown(mm);
> spin_unlock(&rman->lock);
> - return -EBUSY;
> + kfree(rman);
> + man->priv = NULL;
> + ttm_mem_type_manager_cleanup(man);
>
(struct vmwgfx_gmrid_man *)man->priv;
>
> + ttm_mem_type_manager_disable(man);
> +
> + ttm_mem_type_manager_force_list_clean(&dev_priv->bdev, man);
> +
> if (gman) {
I don't think this can ever be non-NULL if init worked, not after t
On Tue, Aug 04, 2020 at 12:56:15PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 23 +++
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 +
On Tue, Aug 04, 2020 at 12:56:21PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 32 +++--
> 1 file changed, 21 insertions(+), 11 deletions(-)
id_man_init(struct vmw_private *dev_priv,
> int type)
> void vmw_gmrid_man_fini(struct vmw_private *dev_priv, int type)
> {
> struct ttm_mem_type_manager *man = ttm_manager_type(&dev_priv->bdev,
> type);
> - struct vmwgfx_gmrid_man *gman =
> - (struct vmwgfx
On Wed, Aug 05, 2020 at 06:03:15PM +0800, Huang Jiachai wrote:
> Hi Daniel
>
> 在 2020/8/5 17:36, Daniel Vetter 写道:
> > On Wed, Aug 5, 2020 at 10:37 AM Sandy Huang wrote:
> > > add this node to get the current true mode.
> > >
> > > Signed-off-by: Sandy
upporter:DRM DRIVER
FOR VMWARE VIRTUAL GPU)
Roland Scheidegger (supporter:DRM DRIVER FOR VMWARE
VIRTUAL GPU)
David Airlie (maintainer:DRM DRIVERS)
Daniel Vetter (maintainer:DRM DRIVERS)
dri-devel@lists.freedesktop.org (open list:DRM DRIVER FOR VMWARE VIRTUAL GPU)
linux-ker...@vger.kernel.org (op
07-17' of
> git://people.freedesktop.org/~agd5f/linux into drm-next")
>
> the spelling error has been introduced on one side of the merge and
> introduced and corrected on the other. This would have produced a
> conflict which David presumably resolved in haste b
s not shut it off, it's just the lowest setting.
But I've not been involved in the details of these discussions.
-Daniel
> +
> /*
>* As we use interpolation lets remove current
>* brightness lev
lane or not.
I've also dropped some comments on Bas' series for adding modifiers which
might be relevant for shuffling all this. But yeah stuff this into plane
state sounds like a good idea.
-Daniel
>
> [How]
> This change should mostly be a refactor. Only commit check is
o subclass
drm_atomic_state.
Another thing I wondered is whether we should rename drm_atomic_state to
drm_atomic_state_update, so it's clear it's the container with the updated
states, not a real state object thing itself.
-Daniel
>
> [1] https://bugzilla.kernel.org/show_bug.cg
27;
series are even more relevant now. I think long term would be best to bake
these flags in at addfb time when modifiers aren't set. And otherwise
always use the modifiers flag, and completely ignore the legacy flags
here.
-Daniel
>
> [How]
> We unfortunately can't drop this fun
uch synchronization in your
locking (e.g. modern compositors do like to change tiling and stuff,
especially once you have modifiers enabled, so this shouldn't cause a sync
across crtc except when absolutely needed).
-Daniel
>
> Optimization can come later so we don't reset DC planes
ing else.
The idea is that essentially you treat individual stream objects as
read-locks on that part of the overall global state, and only when you
need to do a write do you grab all the "read locks" to do the update.
But might not actually help for your hw. Just highlighting this as a
pa
each plane's atomic_update() function.
>
> v2:
> * move the logic into the commit-tail function
>
> Signed-off-by: Thomas Zimmermann
> Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Dave Airl
we could look into moving the actual DC states into drm private states
perhaps (if that helps with the code structure and overall flow).
Maybe as next steps.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri
On Wed, Aug 05, 2020 at 01:42:27PM +0100, Colin King wrote:
> From: Colin Ian King
>
> There a handful of spelling mistakes. fix them.
>
> Signed-off-by: Colin Ian King
Queued up for 5.10, should show up in linux-next right after the merge
window closes.
-Daniel
> ---
xt TEST_ONLY atomic_check
might duplicate the atomic state object in an incosistent state, and fail.
Worse, this looks like if you race like that then you might duplicate an
object with old reservations still in place, and then we've essentially
leaked those resources and need to reboot. Yes m
Hi
> As I suspected, on your system all the performance levels are the same:
(...)
> [8.961704]power level 0sclk: 45000 mclk: 5 vddc:
> 950
> [8.961706]power level 1sclk: 45000 mclk: 5 vddc:
> 950
> [8.961708]power level
t series, since he's typed
the igts for that which us dma_buf poll.
-Daniel
>
> Thanks,
> Christian.
>
> Am 09.07.21 um 14:07 schrieb Christian König:
> > Daniel pointed me towards this function and there are multiple obvious
> > problems
> > in the implementati
On Thu, Jul 15, 2021 at 03:16:08PM -0700, John Harrison wrote:
> On 6/16/2021 03:25, Daniel Vetter wrote:
> > On Thu, Jun 10, 2021 at 10:46 PM wrote:
> > > From: John Harrison
> > >
> > > Various UMDs need to know the L3 bank count. So add a query API for
> > > > the
> > > > simpledrm driver could be used on aarch64 EFI systems as well.
> > > >
> > > > The patches have already been acked by x86 and DRM folks.
> > >
> > > Time to get this merged, I'd say. People are asking for t
On Wed, Jul 14, 2021 at 11:51:34AM -0600, Jim Cromie wrote:
> s/prink/printk/ - no functional changes
>
> Signed-off-by: Jim Cromie
Applied to drm-misc-next, thanks for your patch.
-Daniel
> ---
> include/drm/drm_print.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(
+ The drm debug category facility does a lot of unlikely bit-field
> + tests at runtime; while cheap individually, the cost accumulates.
> + This option uses dynamic debug facility (if configured and
> + using jump_label) to avoid those runtime checks, patching
&
nside is probably that the implementation of
> drm_with_modeset_lock_ctx() is a bit harder to read than a hand
> rolled version on account of being split across three functions,
> but the actual code using it ends up being much simpler.
>
> Cc: Sean Paul
> Cc: Daniel Vetter
>
d everything
> you do here makes totally sense.
>
> Whole series is Acked-by: Christian König
Care to also push this into drm-misc-next since you looked already?
-Daniel
>
> Regards,
> Christian.
>
> > ---
> > include/linux/vgaarb.h | 6 --
> > 1 file
1 - 100 of 26103 matches
Mail list logo
