[PATCH] kernel/cpu: Distinct name for cpu_hotplug.dep_map

freedesktop.org Cc: triv...@kernel.org Acked-by: Gautham R. Shenoy <e...@linux.vnet.ibm.com> Signed-off-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com> --- This time CC'ing triv...@kernel.org too in the hopes of finally getting this in. --- kernel/cpu.c | 2 +- 1 file chang

Re: [PATCH v3 2/2] iommu: Remove cpu-local spinlock

ut of memory. Here, we can instead schedule a task to run > on the other CPU to do the flush before trying again. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Joerg Roedel <j...@8bytes.org>

Re: [PATCH v3 1/2] iommu: Disable preemption around use of this_cpu_ptr()

var = this_cpu_ptr() to var = get_cpu_ptr() > v3: Actually use get_cpu_ptr (not get_cpu_var). Drop the spinlock > removal, concentrate on the immediate bug fix. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96293 > Signed-off-by: Chris Wilson <ch...@chris-wil

[PATCH] kernel/cpu: Distinctive name for cpu_hotplug.dep_map

elopment <intel-...@lists.freedesktop.org> Signed-off-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com> --- kernel/cpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/kernel/cpu.c b/kernel/cpu.c index 5b9d396..6a13f24 100644 --- a/kernel/cpu.c +++ b/kernel/cp

Re: [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

On ti, 2016-02-16 at 12:07 +0100, Peter Zijlstra wrote: > On Tue, Feb 16, 2016 at 12:51:03PM +0200, Joonas Lahtinen wrote: > > Quoting my original patch; > > > > "See the Bugzilla link for more details. > > If its not in the Changelog it doesn't exist. Pa

Re: [Intel-gfx] [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

have been caught by cpuhp_lock_* lockdep tracking. So I'll move the discussion to linux-pm list to change the CPUfreq code. Thanks for the comments. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

Hi, On ma, 2016-02-15 at 18:06 +0100, Peter Zijlstra wrote: > On Mon, Feb 15, 2016 at 03:17:55PM +0100, Peter Zijlstra wrote: > > On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote: > > > Instead of implementing a custom locked reference counting, use lockref. &g

Re: [PATCH] kernel/cpu: Distinctive name for cpu_hotplug.dep_map

Hi, According to scripts/get_maintainer.pl Ingo or Peter would be more appropriate to merge. Added them as To: On ke, 2016-02-03 at 22:42 +0530, Gautham R Shenoy wrote: > Hello Joonas, > > On Wed, Feb 03, 2016 at 04:24:28PM +0200, Joonas Lahtinen wrote: > > Use d

[PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

gt; Cc: Paul E. McKenney <paul...@linux.vnet.ibm.com> Cc: Gautham R. Shenoy <e...@linux.vnet.ibm.com> Cc: Chris Wilson <ch...@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com> --- kernel/cpu.c | 87 +---

Re: [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

Hi, On ma, 2016-02-15 at 18:06 +0100, Peter Zijlstra wrote: > On Mon, Feb 15, 2016 at 03:17:55PM +0100, Peter Zijlstra wrote: > > On Mon, Feb 15, 2016 at 02:36:43PM +0200, Joonas Lahtinen wrote: > > > Instead of implementing a custom locked reference counting, use lockref. &g

Re: [PATCH] [RFC] kernel/cpu: Use lockref for online CPU reference counting

On ti, 2016-02-16 at 10:14 +0100, Peter Zijlstra wrote: > On Tue, Feb 16, 2016 at 10:49:36AM +0200, Joonas Lahtinen wrote: > > I originally thought of implementing this more similar to what you > > specify, but then I came across a discussion in the mailing list where > > it

Re: [PATCH] intel-pstate: Update frequencies of policy->cpus only from ->set_policy()

rite(>rwsem); > > pm_suspend(...) > ...disable_nonboot_cpus() > _cpu_down() > cpu_hotplug_begin(); // Locks cpu_hotplug.lock > __cpu_notify(CPU_DOWN_PREPARE, ...); > ...cpufreq_offlin

Re: [PATCH v2 3/3] drm/i915/shrinker: Hook up vmap allocation failure notifier

gor...@techsingularity.net> > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> A comment below. But regardless; Reviewed-by: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Tvrtko Ursulin <tvrtk

Re: [PATCH v2 2/3] mm/vmap: Add a notifier for when we run out of vmap address space

lt;a...@linux-foundation.org> > Cc: David Rientjes <rient...@google.com> > Cc: Roman Peniaev <r.peni...@gmail.com> > Cc: Mel Gorman <mgor...@techsingularity.net> > Cc: linux...@kvack.org > Cc: linux-kernel@vger.kernel.org > Acked-by: Andrew Morton <a...@l

Re: [PATCH] kernfs: Move faulting copy_user operations outside of the mutex

he > > kernfs file mutex: > ... > > > > Reported-by: Ville Syrjälä <ville.syrj...@linux.intel.com> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94350 > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > > Reviewed-by: Joonas L

Re: [PATCH] kernfs: Move faulting copy_user operations outside of the mutex

On to, 2016-03-31 at 13:15 -0700, Greg Kroah-Hartman wrote: > On Thu, Mar 31, 2016 at 08:30:05PM +0300, Joonas Lahtinen wrote: > > > > On to, 2016-03-31 at 12:49 -0400, Tejun Heo wrote: > > > > > > On Thu, Mar 31, 2016 at 11:45:06AM +0100, Chris Wilson wrote:

Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

ce > v4.8 I've had it in all (four, actually) boots. > > What am I expected to do about this WARNING? > Bisecting the offending commit between v4.8 and v4.8.1 would be a good start. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH 1/3] drm/i915: allocate mock file pointer dynamically

> >   struct drm_file *file; > >   int err; >   filp = kzalloc(sizeof(*filp), GFP_KERNEL); if (unlikely(!filp)) { err = -ENOMEM; goto err; } And appropriate onion teardown in case drm_open fails, so that we don't leak memory. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [Intel-gfx] [PATCH 1/5] i915: avoid kernel hang caused by synchronize rcu struct_mutex deadlock

  return freed; >  } >   > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

the > synchronize_rcu_expedited from the _count methods where it was useless > (in addition to unsafe). -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

On ti, 2017-05-09 at 20:04 -0700, Hugh Dickins wrote: > On Mon, 8 May 2017, Joonas Lahtinen wrote: > > On pe, 2017-05-05 at 14:57 -0700, Hugh Dickins wrote: > > > On Fri, 5 May 2017, Joonas Lahtinen wrote: > > > > On ma, 2017-05-01 at 11:05 +0900, J. R. Okajima wrote:

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

freedesktop.org/patch/156990/ For quick testing on older kernels, just remove all lines with "_rcu" in drivers/gpu/drm/i915/i915_gem_shrinker.c . Regards, Joonas PS: It'll help to subscribe to and track our mailing list at intel-...@lists.freedesktop.org for future convenience. -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

On ti, 2017-05-30 at 13:00 -0700, Hugh Dickins wrote: > On Mon, 22 May 2017, Joonas Lahtinen wrote: > > On la, 2017-05-20 at 10:56 +0900, J. R. Okajima wrote: > > > "J. R. Okajima": > > > >  > > > > I don't know whether the fix is good to me or

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

On pe, 2017-05-05 at 14:57 -0700, Hugh Dickins wrote: > On Fri, 5 May 2017, Joonas Lahtinen wrote: > > On ma, 2017-05-01 at 11:05 +0900, J. R. Okajima wrote: > > > Thanx for the reply. > > >  > > > Andrea Arcangeli: > > > >  > > > &g

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

ug. I've anyway gone and prepared a patch to drop the RCU sync completely from shrinker phase, as discussed originally with Chris. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

choose depending on how often your function gets called, and how critical the execution time is. Hopefully this clarified things. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

ver be possible in practise and if really that big I think something > is already insane indeed. It's good idea to document these assumptions as WARN_ON's. In i915, if the value is completely internal to kernel, we're using GEM_BUG_ON for these so that our CI will notice breakage. If it's not a driver internal value only, a WARN_ON is the appropriate action. Otherwise the information is lost and the next person reading the code will have the same question in mind. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH v15 6/7] drm/i915: Introduce GEM proxy

; i915_gem_set_caching_ioctl > i915_gem_set_domain_ioctl > i915_gem_sw_finish_ioctl > i915_gem_set_tiling_ioctl > i915_gem_madvise_ioctl > > Signed-off-by: Tina Zhang <tina.zh...@intel.com> > Cc: Daniel Vetter <daniel.vet...@ffwll.ch> > Cc: Chris Wilson <ch...

Re: [Intel-gfx] [PATCH v15 6/7] drm/i915: Introduce GEM proxy

On Tue, 2017-10-10 at 13:58 +0300, Joonas Lahtinen wrote: > On Tue, 2017-10-10 at 17:50 +0800, Tina Zhang wrote: > > GEM proxy is a kind of GEM, whose backing physical memory is pinned > > and produced by guest VM and is used by host as read only. With GEM > > proxy, host is

Re: [PATCH] drm/i915: remove redundant check on has_aliasing_ppgtt

n.k...@canonical.com> Thanks, I took it a few steps further and removed the variable altogether. I Cc'd you on the patch. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH] drm/i915: Convert timers to use timer_setup()

l.vet...@intel.com> > Cc: Jani Nikula <jani.nik...@linux.intel.com> > Cc: David Airlie <airl...@linux.ie> > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Tvrtko Ursulin <tvrtko.ursu...@i

Re: [PATCH] drm/i915: Convert timers to use timer_setup()

l.vet...@intel.com> > Cc: Jani Nikula <jani.nik...@linux.intel.com> > Cc: David Airlie <airl...@linux.ie> > Cc: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > Cc: Tvrtko Ursulin <tvrtko.ursu...@i

Re: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

ably the way to go :) Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

On Tue, 2017-12-12 at 19:07 -0500, Sinan Kaya wrote: > On 12/12/2017 9:04 AM, Joonas Lahtinen wrote: > > Hi, > > > > I sent this individual i915 patch to our CI, and it is passing on > > all platforms: > > > > https://patchwork.freedesktop.org/ser

Re: [PATCH] drm/i915: Mark expected switch fall-throughs

? Like: #define FALLTHROUGH __attribute__((fallthrough)); With the appropriate version checks, of course. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH] drm/i915: Increase max texture to 16k for gen9+

else { > - dev->mode_config.max_width = 8192; > - dev->mode_config.max_height = 8192; > + dev->mode_config.max_width = 16384; > + dev->mode_config.max_height = 16384; > } > > if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) { -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH 1/8] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

ough the drm-tip tree as previously discussed. Regards, Joonas On Mon, 2017-12-11 at 12:14 +, Matthew Auld wrote: > From: Joonas Lahtinen <joonas.lahti...@linux.intel.com> > > To give upcoming SKU BIOSes more flexibility in placing the Intel > graphics stolen memory, make

Re: [Intel-gfx] [PATCH] drm/i915: Use copy_from_user() in fence copying

rm/i915: Add support for drm syncobjs") There's been request to reduce the amount of Fixes: tags that are not actually fixing bugs. This seems more like an optimization. References: has been suggested for these cases instead. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel-fixes tree

+ GVT folks. On Fri, 2017-12-08 at 09:15 +1100, Stephen Rothwell wrote: > Hi all, > > Commit > > 365ad5df9caa ("drm/i915/gvt: Export > intel_gvt_render_mmio_to_ring_id()") > > is missing a Signed-off-by from its committer. > -- Joonas Lahtine

Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

; > - dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0)); > > + int domain = pci_domain_nr(dev_priv->drm.pdev->bus); > > + > > + dev_priv->bridge_dev = > > + pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0)); > > if (!dev_priv->bridge_dev) { > > DRM_ERROR("bridge device not found\n"); > > return -1; > > > > -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

Quoting Jani Nikula (2018-04-27 12:20:55) > On Wed, 25 Apr 2018, Ian W MORRISON wrote: > > Can I ask if this is on anyone's radar as I'm concerned this patch will > > stall otherwise? > > Pushed to drm-intel-next-queued, thanks for the patch. > > I opted to drop the Cc:

Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

Quoting Jani Nikula (2018-02-19 11:34:34) > On Fri, 16 Feb 2018, Bjorn Helgaas wrote: > > On Mon, Nov 27, 2017 at 11:57:46AM -0500, Sinan Kaya wrote: > >> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > >> where a PCI device is present. This restricts

Re: [PATCH] drm/i915: drop various VLAs in i915_debugfs.c

Quoting Salvatore Mesoraca (2018-03-13 21:51:28) > Avoid 3 VLAs[1] by using real constant expressions instead of variables. > The compiler should be able to optimize the original code and avoid using > any actual VLAs. Anyway this change is useful because it will avoid a false > positives with

RE: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

Quoting Jani Nikula (2018-04-17 12:02:52) > On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: > >>-Original Message- > >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >>Sent: Wednesday, April 11, 2018 5:27 AM > >>To: Ian W MORRISON

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

Quoting Stephen Rothwell (2018-03-23 02:50:18) > Hi all, > > On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell > wrote: > > > > Today's linux-next merge of the drm-intel tree got a conflict in: > > > > drivers/gpu/drm/i915/gvt/scheduler.c > > > > between commit: > >

Re: [PATCH] drm/i915: avoid rebuilding i915_gpu_error.o on version string updates

Quoting Hans Holmberg (2018-11-21 13:35:19) > On Wed, Nov 21, 2018 at 11:10 AM Joonas Lahtinen > wrote: > > > > Quoting Hans Holmberg (2018-11-21 11:54:23) > > > From: Hans Holmberg > > > > > > There is no need to rebuild i915_gpu_error.o when th

Re: [PATCH] drm/i915: drop various VLAs in i915_debugfs.c

Quoting Salvatore Mesoraca (2018-03-13 21:51:28) > Avoid 3 VLAs[1] by using real constant expressions instead of variables. > The compiler should be able to optimize the original code and avoid using > any actual VLAs. Anyway this change is useful because it will avoid a false > positives with

Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree

Quoting Stephen Rothwell (2018-03-23 02:50:18) > Hi all, > > On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell > wrote: > > > > Today's linux-next merge of the drm-intel tree got a conflict in: > > > > drivers/gpu/drm/i915/gvt/scheduler.c > > > > between commit: > > > > fa3dd623e559

Re: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

Quoting Jani Nikula (2018-04-27 12:20:55) > On Wed, 25 Apr 2018, Ian W MORRISON wrote: > > Can I ask if this is on anyone's radar as I'm concerned this patch will > > stall otherwise? > > Pushed to drm-intel-next-queued, thanks for the patch. > > I opted to drop the Cc: stable for now. This

Re: [PATCH] drm/i915: Convert timers to use timer_setup()

Jani Nikula > Cc: David Airlie > Cc: Chris Wilson > Cc: Joonas Lahtinen > Cc: Tvrtko Ursulin > Cc: Oscar Mateo > Cc: intel-...@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Kees Cook > Reviewed-by: Joonas Lahtinen # for > mock

Re: [PATCH] drm/i915: Convert timers to use timer_setup()

Jani Nikula > Cc: David Airlie > Cc: Chris Wilson > Cc: Joonas Lahtinen > Cc: Tvrtko Ursulin > Cc: Oscar Mateo > Cc: intel-...@lists.freedesktop.org > Cc: dri-de...@lists.freedesktop.org > Cc: Thomas Gleixner > Signed-off-by: Kees Cook > @@ -32,9 +32,9 @@

Re: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

> void *dst = NULL; > > > > int ret = 0; > > > > > > > > > > Applied this, thanks! > > > > Is it possible for bb_size to be both >= 2g and valid? > > Never be possible in practise and if really that big I think somethin

Re: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

choose depending on how often your function gets called, and how critical the execution time is. Hopefully this clarified things. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

RE: [RESEND PATCH 1/1] drm/i915/glk: Add MODULE_FIRMWARE for Geminilake

Quoting Jani Nikula (2018-04-17 12:02:52) > On Mon, 16 Apr 2018, "Srivatsa, Anusha" wrote: > >>-Original Message- > >>From: Jani Nikula [mailto:jani.nik...@linux.intel.com] > >>Sent: Wednesday, April 11, 2018 5:27 AM > >>To: Ian W MORRISON > >>Cc: Vivi, Rodrigo ; Srivatsa, Anusha > >>;

Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

Quoting Jani Nikula (2018-02-19 11:34:34) > On Fri, 16 Feb 2018, Bjorn Helgaas wrote: > > On Mon, Nov 27, 2017 at 11:57:46AM -0500, Sinan Kaya wrote: > >> pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as > >> where a PCI device is present. This restricts the device drivers

Re: [PATCH] drm/i915: Increase max texture to 16k for gen9+

->mode_config.max_width = 8192; > - dev->mode_config.max_height = 8192; > + dev->mode_config.max_width = 16384; > + dev->mode_config.max_height = 16384; > } > > if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) { -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH] drm/i915: Mark expected switch fall-throughs

? Like: #define FALLTHROUGH __attribute__((fallthrough)); With the appropriate version checks, of course. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [Intel-gfx] [PATCH] drm/i915: Use copy_from_user() in fence copying

rm/i915: Add support for drm syncobjs") There's been request to reduce the amount of Fixes: tags that are not actually fixing bugs. This seems more like an optimization. References: has been suggested for these cases instead. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [Intel-gfx] linux-next: Signed-off-by missing for commit in the drm-intel-fixes tree

+ GVT folks. On Fri, 2017-12-08 at 09:15 +1100, Stephen Rothwell wrote: > Hi all, > > Commit > > 365ad5df9caa ("drm/i915/gvt: Export > intel_gvt_render_mmio_to_ring_id()") > > is missing a Signed-off-by from its committer. > -- Joonas Lahtine

Re: [PATCH 1/8] x86/early-quirks: Extend Intel graphics stolen memory placement to 64bit

ough the drm-tip tree as previously discussed. Regards, Joonas On Mon, 2017-12-11 at 12:14 +, Matthew Auld wrote: > From: Joonas Lahtinen > > To give upcoming SKU BIOSes more flexibility in placing the Intel > graphics stolen memory, make all variables storing the placement or s

Re: [PATCH v15 6/7] drm/i915: Introduce GEM proxy

; i915_gem_set_caching_ioctl > i915_gem_set_domain_ioctl > i915_gem_sw_finish_ioctl > i915_gem_set_tiling_ioctl > i915_gem_madvise_ioctl > > Signed-off-by: Tina Zhang > Cc: Daniel Vetter > Cc: Chris Wilson > Cc: Joonas Lahtinen > +++ b/drivers/gpu/drm/i915/i91

Re: [Intel-gfx] [PATCH v15 6/7] drm/i915: Introduce GEM proxy

On Tue, 2017-10-10 at 13:58 +0300, Joonas Lahtinen wrote: > On Tue, 2017-10-10 at 17:50 +0800, Tina Zhang wrote: > > GEM proxy is a kind of GEM, whose backing physical memory is pinned > > and produced by guest VM and is used by host as read only. With GEM > > proxy, host is

Re: [PATCH] drm/i915: remove redundant check on has_aliasing_ppgtt

and removed the variable altogether. I Cc'd you on the patch. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

CI_DEVFN(0, 0)); > > + int domain = pci_domain_nr(dev_priv->drm.pdev->bus); > > + > > + dev_priv->bridge_dev = > > + pci_get_domain_bus_and_slot(domain, 0, PCI_DEVFN(0, 0)); > > if (!dev_priv->bridge_dev) { > > DRM_ERROR("bridge device not found\n"); > > return -1; > > > > -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [PATCH V3 09/29] drm/i915: deprecate pci_get_bus_and_slot()

On Tue, 2017-12-12 at 19:07 -0500, Sinan Kaya wrote: > On 12/12/2017 9:04 AM, Joonas Lahtinen wrote: > > Hi, > > > > I sent this individual i915 patch to our CI, and it is passing on > > all platforms: > > > > https://patchwork.freedesktop.org/ser

Re: linux-next: manual merge of the akpm tree with the drm-intel tree

Quoting Daniel Vetter (2020-10-01 18:13:26) > On Thu, Oct 1, 2020 at 5:08 PM Jani Nikula > wrote: > > > > On Thu, 01 Oct 2020, Daniel Vetter wrote: > > > On Thu, Oct 1, 2020 at 3:53 PM Christoph Hellwig wrote: > > >> > > >> On Thu, Oct 01, 2020 at 08:39:17PM +1000, Stephen Rothwell wrote: > >

Re: REGRESSION: in intel video driver following introduction of mm_struct.has_pinned

(+ intel-gfx for being i915 related) (+ Chris who has looked into the issue) Hi, Thanks for reporting! Could you open a bug report according to following instructions: https://gitlab.freedesktop.org/drm/intel/-/wikis/How-to-file-i915-bugs A full dmesg of a bad boot and git bisect logs will be

Re: remove alloc_vm_area v2

Quoting Christoph Hellwig (2020-09-28 15:37:41) > On Mon, Sep 28, 2020 at 01:13:38PM +0300, Joonas Lahtinen wrote: > > I think we have a gap that after splitting the drm-intel-next pull requests > > into > > two the drm-intel/for-linux-next branch is now missing material f

Re: [PATCH tip/core/rcu 11/15] drm/i915: Cleanup PREEMPT_COUNT leftovers

Quoting paul...@kernel.org (2020-09-29 02:30:58) > From: Thomas Gleixner > > CONFIG_PREEMPT_COUNT is now unconditionally enabled and will be > removed. Cleanup the leftovers before doing so. Change looks fine: Reviewed-by: Joonas Lahtinen Are you looking for us to merge or m

Re: [PATCH v6 44/80] docs: gpu: i915.rst: Fix several C duplication warnings

+ Lionel Can you please take a look at best resolving the below problem. Maybe we should eliminate the duplicate declarations? Updating such a list manually seems error prone to me. Regards, Joonas Quoting Mauro Carvalho Chehab (2020-10-13 14:53:59) > As reported by Sphinx: > >

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count

+ Tvrtko and Chris for comments Code seems to be added in: commit 0cd4684d6ea9a4ffec33fc19de4dd667bb90d0a5 Author: Tvrtko Ursulin Date: Tue Nov 21 18:18:50 2017 + drm/i915/pmu: Add interrupt count metric I think later in the thread there was a suggestion to replace this with simple

Re: [PATCH] x86/gpu: add JSL stolen memory support

Would that work? Regards, Joonas > > > -Original Message- > > > From: Bjorn Helgaas > > > Sent: 30 November 2020 22:21 > > > To: Surendrakumar Upadhyay, TejaskumarX > > > > > > Cc: Jesse Barnes ; Daniel Vetter ; > > > Joonas Laht

Re: [PATCH] x86/gpu: add JSL stolen memory support

Quoting Bjorn Helgaas (2020-11-04 19:35:56) > [+cc Jani, Joonas, Rodrigo, David, Daniel] > > On Wed, Nov 04, 2020 at 05:35:06PM +0530, Tejas Upadhyay wrote: > > JSL re-uses the same stolen memory as ICL and EHL. > > > > Cc: Lucas De Marchi > > Cc: Matt Roper > > Signed-off-by: Tejas Upadhyay

Re: remove alloc_vm_area v2

+ Dave and Daniel + Stephen Quoting Christoph Hellwig (2020-09-26 09:29:59) > On Fri, Sep 25, 2020 at 07:43:49PM -0700, Andrew Morton wrote: > > On Thu, 24 Sep 2020 15:58:42 +0200 Christoph Hellwig wrote: > > > > > this series removes alloc_vm_area, which was left over from the big > > >

Re: [PATCH v4 0/7] Convert the intel iommu driver to the dma-iommu api

Quoting Tvrtko Ursulin (2020-11-03 11:14:32) > > > On 03/11/2020 02:53, Lu Baolu wrote: > > On 11/2/20 7:52 PM, Tvrtko Ursulin wrote: > >> > >> On 02/11/2020 02:00, Lu Baolu wrote: > >>> Hi Tvrtko, > >>> On 10/12/20 4:44 PM, Tvrtko Ursulin wrote: > > On 29/09/2020 01:11, Lu Baolu

Re: [PATCH][drm-next] drm/i915/gvt: ensure -ve return value is handled correctly

ably the way to go :) Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: linux-next: Fixes tag needs some work in the drm-intel tree

Quoting Stephen Rothwell (2019-05-20 15:15:38) > Hi all, > > In commit > > 0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the > signaler") > > Fixes tag > > Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni > > has these problem(s): > >

Re: [PATCH 06/34] drm/i915: convert put_page() to put_user_page*()

Quoting john.hubb...@gmail.com (2019-08-02 05:19:37) > From: John Hubbard > > For pages that were retained via get_user_pages*(), release those pages > via the new put_user_page*() routines, instead of via put_page() or > release_pages(). > > This is part a tree-wide conversion, as described in

Re: linux-next: build failure after merge of the drm-intel-fixes tree

Quoting Stephen Rothwell (2020-06-16 02:39:12) > Hi all, > > After merging the drm-intel-fixes tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > > In file included from drivers/gpu/drm/i915/gt/intel_lrc.c:5972: > drivers/gpu/drm/i915/gt/selftest_lrc.c: In function >

Re: [PATCH] drm/i915: avoid rebuilding i915_gpu_error.o on version string updates

Quoting Hans Holmberg (2018-11-21 13:35:19) > On Wed, Nov 21, 2018 at 11:10 AM Joonas Lahtinen > wrote: > > > > Quoting Hans Holmberg (2018-11-21 11:54:23) > > > From: Hans Holmberg > > > > > > There is no need to rebuild i915_gpu_error.o when th

Re: 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?

Quoting Pavel Machek (2018-12-12 20:29:02) > Hi! > > > > > > > > > There's one similar for nouveau in Bugzilla, but it seems like > > > > > > > > a genuine > > > > > > > > memory corruption (1 bit flipped): > > > > > > > > > > > > > > > > https://bugs.freedesktop.org/show_bug.cgi?id=84880 > > >

Re: [PULL] topic/mei-hdcp

Quoting Daniel Vetter (2019-02-19 09:55:27) > Hi all, > > topic/mei-hdcp-2019-02-19: > Prep patches + headers for the mei-hdcp/i915 component interfaces > > Also contains the prep work in the component helpers plus adjustements > for the snd-hda/i915 component interface. > > Plus one small

Re: [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx

Quoting Joerg Roedel (2019-01-22 13:01:09) > Hi Daniel, > > On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote: > > Note that the string of platforms which have various issues with iommu > > and igfx is very long, thus far we only disabled it where there's no > > workaround to stop it

Re: [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx

Quoting Joerg Roedel (2019-01-22 18:51:35) > On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote: > > According to our IOMMU folks there exists some desire to be able to assign > > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off > > due to

Re: [PATCH v4 8/9] gpu/drm/i915: optimize out the case when a range is updated to read only

Hi Jerome, This patch seems to have plenty of Cc:s, but none of the right ones :) For further iterations, I guess you could use git option --cc to make sure everyone gets the whole series, and still keep the Cc:s in the patches themselves relevant to subsystems. This doesn't seem to be on top

Re: [PATCH 07/16] tools headers uapi: Update i915_drm.h

' differs > from latest version at 'include/uapi/drm/i915_drm.h' > diff -u tools/include/uapi/drm/i915_drm.h include/uapi/drm/i915_drm.h > > Cc: Adrian Hunter > Cc: Chris Wilson > Cc: Jiri Olsa > Cc: Joonas Lahtinen > Cc: Lionel Landwerlin > Cc: Namhyung Kim &

Re: [regression from v4.19] Re: 4.20.0-rc6-next-20181210, v4.20-rc1: list_del corruption on thinkpad x220, graphics related?

Quoting Pavel Machek (2018-12-27 10:34:39) > Hi! > > > > > > If you think it is useful, I can try to update my machine to > > > > > linux-next. > > > > > > > > linux-next is closer to drm-tip, so it's better. Do you have some > > > > specific reason for not wanting to run drm-tip (but linux-next

Re: iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip

Quoting Eric Wong (2018-12-27 13:49:48) > I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57 > chipset) and hit some kernel panics while trying to view > image/animation-intensive stuff in Firefox (X11) unless I use > "iommu_intel=igfx_off". > > With Debian stable backport kernels,

Re: iommu_intel or i915 regression in 4.18, 4.19.12 and drm-tip

Quoting Eric Wong (2019-01-04 03:06:26) > Joonas Lahtinen wrote: > > Quoting Eric Wong (2018-12-27 13:49:48) > > > I just got a used Thinkpad X201 (Core i5 M 520, Intel QM57 > > > chipset) and hit some kernel panics while trying to view > > > image/anima

Re: v4.20-rc1: list_del corruption on thinkpad x220, graphics related?

it, and backport that. On the other hand, if it's still reproducible, we know we're not spending time on something we already fixed, and the priority gets a bump. > If you think it is useful, I can try to update my machine to > linux-next. linux-next is closer to drm-tip, so it's better. Do you have some specific reason for not wanting to run drm-tip (but linux-next is still ok)? Regards, Joonas > > Best regards, > Pavel > -- Joonas Lahtinen Open Source Graphics Center Intel Corporation

Re: v4.20-rc5+ on x220: Resetting chip for hang on rcs0

t; [31850.668487] Hardware name: LENOVO 42872WU/42872WU, BIOS 8DET74WW > (1.44 ) 03/13/2018 > > Dmesg and /sys/class/drm/card0/error are attached. > > Best regards, > Pavel -- Joonas Lahtinen Open Source Graphics Center Intel Corporation

Re: [PATCH 1/3] drm/i915: allocate mock file pointer dynamically

struct drm_file *file; > >   int err; >   filp = kzalloc(sizeof(*filp), GFP_KERNEL); if (unlikely(!filp)) { err = -ENOMEM; goto err; } And appropriate onion teardown in case drm_open fails, so that we don't leak memory. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

On ti, 2017-05-30 at 13:00 -0700, Hugh Dickins wrote: > On Mon, 22 May 2017, Joonas Lahtinen wrote: > > On la, 2017-05-20 at 10:56 +0900, J. R. Okajima wrote: > > > "J. R. Okajima": > > > >  > > > > I don't know whether the fix is good to me or

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

ug. I've anyway gone and prepared a patch to drop the RCU sync completely from shrinker phase, as discussed originally with Chris. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

On pe, 2017-05-05 at 14:57 -0700, Hugh Dickins wrote: > On Fri, 5 May 2017, Joonas Lahtinen wrote: > > On ma, 2017-05-01 at 11:05 +0900, J. R. Okajima wrote: > > > Thanx for the reply. > > >  > > > Andrea Arcangeli: > > > >  > > > &g

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

freedesktop.org/patch/156990/ For quick testing on older kernels, just remove all lines with "_rcu" in drivers/gpu/drm/i915/i915_gem_shrinker.c . Regards, Joonas PS: It'll help to subscribe to and track our mailing list at intel-...@lists.freedesktop.org for future convenience. -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

On ti, 2017-05-09 at 20:04 -0700, Hugh Dickins wrote: > On Mon, 8 May 2017, Joonas Lahtinen wrote: > > On pe, 2017-05-05 at 14:57 -0700, Hugh Dickins wrote: > > > On Fri, 5 May 2017, Joonas Lahtinen wrote: > > > > On ma, 2017-05-01 at 11:05 +0900, J. R. Okajima wrote:

Re: Q. drm/i915 shrinker, synchronize_rcu_expedited() from handlers

e_rcu_expedited from the _count methods where it was useless > (in addition to unsafe). -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

ce > v4.8 I've had it in all (four, actually) boots. > > What am I expected to do about this WARNING? > Bisecting the offending commit between v4.8 and v4.8.1 would be a good start. Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation

Re: [Intel-gfx] [PATCH 1/5] i915: avoid kernel hang caused by synchronize rcu struct_mutex deadlock

  return freed; >  } >   > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Joonas Lahtinen Open Source Technology Center Intel Corporation

  1   2   >