Re: [Intel-gfx] [PATCH v2 02/21] drm/armada: Introduce GEM object functions

On Tue, Sep 15, 2020 at 04:59:39PM +0200, Thomas Zimmermann wrote: > GEM object functions deprecate several similar callback interfaces in > struct drm_driver. This patch replaces the per-driver callbacks with > per-instance callbacks in armada. > > Signed-off-by: Thomas Zimmermann Acked-by:

Re: [Intel-gfx] [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to user_full_access_begin/end()

On Tue, Apr 21, 2020 at 03:49:19AM +0100, Al Viro wrote: > The only source I'd been able to find speeks of >= 60 cycles > (and possibly much more) for non-pipelined coprocessor instructions; > the list of such does contain loads and stores to a bunch of registers. > However, the register in

Re: [Intel-gfx] [PATCH 18/51] drm/: Use drmm_add_final_kfree

On Fri, Feb 21, 2020 at 10:02:46PM +0100, Daniel Vetter wrote: > These are the leftover drivers that didn't have a ->release hook that > needed to be updated. > > Signed-off-by: Daniel Vetter > Cc: "James (Qian) Wang" > Cc: Liviu Dudau > Cc: Mihail Atanassov > Cc: Russell King > Cc: Hans de

Re: [Intel-gfx] [PATCH 05/15] drm/armada: Delete dma_buf->k(un)map implemenation

On Mon, Nov 25, 2019 at 10:44:43PM +0100, Daniel Vetter wrote: > On Mon, Nov 18, 2019 at 11:35:26AM +0100, Daniel Vetter wrote: > > It's a dummy anyway. > > > > Signed-off-by: Daniel Vetter > > Cc: Russell King > > I merged the entire series except this one and the final patch, sill > waiting

Re: [Intel-gfx] [PATCH] dma-buf: add struct dma_buf_attach_info v2

On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote: > Add a structure for the parameters of dma_buf_attach, this makes it much > easier > to add new parameters later on. I don't understand this reasoning. What are the "new parameters" that are being proposed, and why do we need to

Re: [Intel-gfx] [PATCH 2/4] components: multiple components for a device

On Fri, Feb 08, 2019 at 12:27:57AM +0100, Daniel Vetter wrote: > Component framework is extended to support multiple components for > a struct device. These will be matched with different masters based on > its sub component value. > > We are introducing this, as I915 needs two different

Re: [Intel-gfx] [PATCH 1/4] drm/edid: Pass connector to AVI inforframe functions

On Tue, Nov 20, 2018 at 06:13:42PM +0200, Ville Syrjala wrote: > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c > b/drivers/gpu/drm/i2c/tda998x_drv.c > index a7c39f39793f..38c66fbc8276 100644 > --- a/drivers/gpu/drm/i2c/tda998x_drv.c > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c > @@ -849,7 +849,8 @@

Re: [Intel-gfx] [RFC 1/6] drm/armada: Simplify drm_dev_init error log

On Wed, Jan 24, 2018 at 04:18:16PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > dev_err will log the device in question and since there is a single caller > to drm_dev_init inside this driver, the drm prefix and the function name > can both also be safely

Re: [Intel-gfx] [PATCH v2 05/15] drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()

On Mon, Oct 30, 2017 at 04:39:41PM +0100, Noralf Trønnes wrote: > -static void armada_output_poll_changed(struct drm_device *dev) > -{ > - struct armada_private *priv = dev->dev_private; > - struct drm_fb_helper *fbh = priv->fbdev; > - > - if (fbh) > -

Re: [Intel-gfx] [PATCH 05/15] drm/armada: Use drm_fb_helper_lastclose() and _poll_changed()

On Fri, Oct 20, 2017 at 01:02:03AM +0200, Noralf Trønnes wrote: > This driver can use drm_fb_helper_lastclose() as its .lastclose callback. > It can also use drm_fb_helper_output_poll_changed() as its > .output_poll_changed callback. > > Cc: Russell King Acked-by: Russell

Re: [Intel-gfx] [PATCH 02/19] drm: Add acquire ctx parameter to ->update_plane

On Wed, Mar 22, 2017 at 10:50:41PM +0100, Daniel Vetter wrote: > diff --git a/drivers/gpu/drm/armada/armada_overlay.c > b/drivers/gpu/drm/armada/armada_overlay.c > index 34cb73d0db77..b54fd8cbd3a6 100644 > --- a/drivers/gpu/drm/armada/armada_overlay.c > +++

Re: [Intel-gfx] [PATCH 16/35] drm/etnaviv: Use lockless gem BO free callback

On Tue, Apr 26, 2016 at 07:29:49PM +0200, Daniel Vetter wrote: > No dev->struct_mutex anywhere to be seen. > > Cc: Christian Gmeiner > Cc: Russell King Acked-by: Russell King Thanks Daniel. -- RMK's

Re: [Intel-gfx] [PATCH 11/35] drm/armada: Use lockless gem BO free callback

On Tue, Apr 26, 2016 at 07:29:44PM +0200, Daniel Vetter wrote: > No dev->struct_mutex anywhere to be seen. > > Cc: Russell King Acked-by: Russell King Thanks Daniel. -- RMK's Patch system:

Re: [Intel-gfx] [PATCH 03/10] drm/armada: Drop fb gamma_set/get functions

On Wed, Mar 30, 2016 at 01:19:21PM +0200, Daniel Vetter wrote: > On Wed, Mar 30, 2016 at 1:09 PM, Russell King - ARM Linux > <li...@arm.linux.org.uk> wrote: > > On Wed, Mar 30, 2016 at 11:51:18AM +0200, Daniel Vetter wrote: > >> The fb helper private gamma_set/get funct

Re: [Intel-gfx] [PATCH 03/10] drm/armada: Drop fb gamma_set/get functions

On Wed, Mar 30, 2016 at 11:51:18AM +0200, Daniel Vetter wrote: > The fb helper private gamma_set/get functions are only required when > the driver supports paletted 8bit mode with fbdev. Armada uses 32bpp > unconditionally, so this is just dead code. It also doesn't do > anything really. Let's

Re: [Intel-gfx] [REGRESSION] component: add support for releasing match data

On Tue, Jan 26, 2016 at 02:42:16PM +0100, Maarten Lankhorst wrote: > Commit ce657b1cddf1f88c56 ("component: add support for releasing match > data") causes a general protection fault when unloading snd-hda-intel > with the i915 module loaded on a recent skylake machine. I'm no good at

Re: [Intel-gfx] [REGRESSION] component: add support for releasing match data

On Tue, Jan 26, 2016 at 03:28:34PM +0100, Maarten Lankhorst wrote: > Something similar to a segfault. It's trying to call 0x6b6b6b6b6b which > is POISON_FREE. > > mc appears to be freed already, so calling mc->release would jump to > invalid data. It seems that my devm foo wasn't quite up to

Re: [Intel-gfx] [PATCH 07/22] drm/armada: Remove NULL open/pre/postclose hooks

On Mon, Jan 11, 2016 at 10:41:01PM +0100, Daniel Vetter wrote: > The compiler will do this, but the void hits when grepping all the > hooks for a subsystem wide audit are slightly annoying. So remove them > for next time around. I'll try to remember to queue this after -rc1, though a reminder

Re: [Intel-gfx] [PATCH 5/5] drm/tda998x: Remove dummy save/restore funcs

On Tue, Dec 08, 2015 at 11:11:01AM +0100, Daniel Vetter wrote: > On Tue, Dec 08, 2015 at 09:30:48AM +, Emil Velikov wrote: > > On 8 December 2015 at 08:49, Daniel Vetter wrote: > > > In my quest to remove all the drm_encoder_helper_funcs->save/restore > > > hooks I

Re: [Intel-gfx] [PATCH 12/29] drm/armada: Drop struct_mutex from cursor paths

On Mon, Nov 23, 2015 at 10:32:45AM +0100, Daniel Vetter wrote: > @@ -957,11 +955,9 @@ static int armada_drm_crtc_cursor_move(struct drm_crtc > *crtc, int x, int y) > if (!dcrtc->variant->has_spu_adv_reg) > return -EFAULT; > > - mutex_lock(>struct_mutex); >

Re: [Intel-gfx] [PATCH 13/29] drm/armada: Use a private mutex to protect priv->linear

On Mon, Nov 23, 2015 at 10:32:46AM +0100, Daniel Vetter wrote: > diff --git a/drivers/gpu/drm/armada/armada_gem.c > b/drivers/gpu/drm/armada/armada_gem.c > index e3a86b96af2a..a43690ab18b9 100644 > --- a/drivers/gpu/drm/armada/armada_gem.c > +++ b/drivers/gpu/drm/armada/armada_gem.c > @@ -46,7

[Intel-gfx] i915 render node discovery buggy?

In passing, while reading the Intel DDX driver code, I've noticed that the Intel driver contains code which assumes that the master and render devices are related by minor device number, eg: /* Are we a render-node ourselves? */ if (is_render_node(fd, )) return

Re: [Intel-gfx] [PATCH 11/18] drm/armada: Don't grab dev-struct_mutex for in mmap offset ioctl

On Thu, Jul 09, 2015 at 11:32:43PM +0200, Daniel Vetter wrote: Since David Herrmann's mmap vma manager rework we don't need to grab dev-struct_mutex any more to prevent races when looking up the mmap offset. Drop it and instead don't forget to use the unref_unlocked variant (since the drm core

Re: [Intel-gfx] [PATCH] drm/mm: Support 4 GiB and larger ranges

On Tue, Jan 27, 2015 at 09:31:26AM +0100, Thomas Hellstrom wrote: On 01/27/2015 09:15 AM, Thierry Reding wrote: Are you referring to the 4 GiB - 1 comment? The point I was trying to make is not that the granularity of the IOVA space needs to be 1 byte but rather that using an unsigned long

Re: [Intel-gfx] [PATCH RFC 0/4] drm/core: restore suspend/resume calbacks in KMS drm drivers

On Fri, Oct 03, 2014 at 01:39:21PM +0200, Daniel Vetter wrote: On Fri, Oct 3, 2014 at 11:42 AM, Andrzej Hajda a.ha...@samsung.com wrote: But this is an issue closely connected with component framework. Component framework separates master component probe and drm device initialization. As a

Re: [Intel-gfx] [PATCH v3 2/4] drm: Constify struct drm_fb_helper_funcs

On Fri, Jun 27, 2014 at 05:19:23PM +0200, Thierry Reding wrote: From: Thierry Reding tred...@nvidia.com There's no need for this to be modifiable. Make it const so that it can be put into the .rodata section. Reviewed-by: Daniel Vetter daniel.vet...@ffwll.ch Signed-off-by: Thierry Reding

Re: [Intel-gfx] [PATCH 1/2] drm: provide a helper for the encoder possible_crtcs mask

On Mon, Jan 13, 2014 at 02:50:46PM +0100, David Herrmann wrote: Hi Russel On Mon, Jan 13, 2014 at 1:47 PM, Russell King - ARM Linux li...@arm.linux.org.uk wrote: On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote: Does that -1 ever make sense? We don't support mode-object

Re: [Intel-gfx] [PATCH 1/2] drm: provide a helper for the encoder possible_crtcs mask

On Mon, Jan 13, 2014 at 12:58:54PM +0100, David Herrmann wrote: Does that -1 ever make sense? We don't support mode-object-hotplugging so all drm_crtc objects are known at initialization time. I'd rather put a BUG() here than a silent -1. This also makes drm_crtc_mask() redundant. I disagree

Re: [Intel-gfx] [PATCH 1/2] drm: share drm_add_fake_info_node

On Wed, Jan 15, 2014 at 12:25:10AM +0100, Daniel Vetter wrote: On Tue, Jan 14, 2014 at 06:14:06AM -0800, Ben Widawsky wrote: Both i915 and Armada had the exact same implementation. For an upcoming patch, I'd like to call this function from two different source files in i915, and having it