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
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>
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
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
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
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
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
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
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 +---
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
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
rite(>rwsem);
>
> pm_suspend(...)
> ...disable_nonboot_cpus()
> _cpu_down()
> cpu_hotplug_begin(); // Locks cpu_hotplug.lock
> __cpu_notify(CPU_DOWN_PREPARE, ...);
> ...cpufreq_offlin
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
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
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
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:
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
> > 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
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
the
> synchronize_rcu_expedited from the _count methods where it was useless
> (in addition to unsafe).
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
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:
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
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
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
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
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
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
; 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...
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
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
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
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
ably the way to go :)
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
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
? Like:
#define FALLTHROUGH __attribute__((fallthrough));
With the appropriate version checks, of course.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
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
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
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
+ 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
; > - 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
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:
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
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
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
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:
> >
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
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
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
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
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
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 @@
> 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
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
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
> >>;
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
->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
? Like:
#define FALLTHROUGH __attribute__((fallthrough));
With the appropriate version checks, of course.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
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
+ 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
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
; 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
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
and removed the variable
altogether. I Cc'd you on the patch.
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
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
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
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:
> >
(+ 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
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
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
+ 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:
>
>
+ 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
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
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
+ 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
> > >
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
ably the way to go :)
Regards, Joonas
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
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):
>
>
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
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
>
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
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
> > >
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
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
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
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
' 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
&
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
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,
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
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
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
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
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
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
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
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
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:
e_rcu_expedited from the _count methods where it was useless
> (in addition to unsafe).
--
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
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
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 - 100 of 116 matches
Mail list logo