> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Friday, November 20, 2015 4:03 AM
>
> > >
> > > The proposal is therefore that GPU vendors can expose vGPUs to
> > > userspace, and thus to QEMU, using the VFIO API. For instance, vfio
> > > supports modular bus drivers and IOMMU
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin patch in order to pin buffers
to a certain VA.
Cave
These tests exercise the userptr ioctl to create shared buffers
between CPU and GPU. They contain error and normal usage scenarios.
They also contain a couple of stress tests which copy buffers between
CPU and GPU. These tests rely on the softpin patch in order to pin buffers
to a certain VA.
Cave
> From: Gerd Hoffmann [mailto:kra...@redhat.com]
> Sent: Thursday, November 19, 2015 4:41 PM
>
> Hi,
>
> > > Another area of extension is how to expose a framebuffer to QEMU for
> > > seamless integration into a SPICE/VNC channel. For this I believe we
> > > could use a new region, much like w
> From: Song, Jike
> Sent: Friday, November 20, 2015 1:52 PM
>
> On 11/20/2015 12:22 PM, Alex Williamson wrote:
> > On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> >> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> >>> On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> On T
Hmm, please help me understand more about it.
As per bspec this is a RW register.
Also, restoring the register values, isn't it part of the firmware's job?
Do we have any communication from HW team on this?
Regards,
Sonika
-Original Message-
From: Rodrigo Vivi [mailto:rodrigo.v...@gmail.c
On 11/20/2015 12:22 PM, Alex Williamson wrote:
On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In addition
On Fri, 2015-11-20 at 10:58 +0800, Jike Song wrote:
> On 11/19/2015 11:52 PM, Alex Williamson wrote:
> > On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
> >> On Thu, 19 Nov 2015, Jike Song wrote:
> >>> Hi Alex, thanks for the discussion.
> >>>
> >>> In addition to Kevin's replies, I ha
On Thu, Nov 05, 2015 at 02:55:20PM +0200, Jani Nikula wrote:
> On Thu, 05 Nov 2015, Matt Roper wrote:
> > On Wed, Nov 04, 2015 at 04:12:33PM +0200, Jani Nikula wrote:
> >> On Tue, 03 Nov 2015, Matt Roper wrote:
> >> > Although we can do a good job of reading out hardware state, the
> >> > graphic
On 11/19/2015 11:52 PM, Alex Williamson wrote:
On Thu, 2015-11-19 at 15:32 +, Stefano Stabellini wrote:
On Thu, 19 Nov 2015, Jike Song wrote:
Hi Alex, thanks for the discussion.
In addition to Kevin's replies, I have a high-level question: can VFIO
be used by QEMU for both KVM and Xen?
N
On 11/19/2015 07:09 PM, Paolo Bonzini wrote:
On 19/11/2015 09:40, Gerd Hoffmann wrote:
But this code should be
minor to be maintained in libvirt.
As far I know libvirt only needs to discover those devices. If they
look like sr/iov devices in sysfs this might work without any changes to
libvirt
From: "Lu, Han"
For SKL we added a commit 632f3ab95fe2 ("drm/i915/audio: add codec wakeup
override enabled/disable callback"), in order to enable codec wakeup
override signal, to allow re-enumeration of the controller on SKL after
resume from low power state.
In SKL, HDMI/DP codec and PCH HD Audi
On 11/20/2015 12:01 AM, Jani Nikula wrote:
On Thu, 19 Nov 2015, Daniel Vetter wrote:
On Thu, Nov 19, 2015 at 10:44:48PM +0800, han...@intel.com wrote:
From: "Lu, Han"
For SKL we added a commit 632f3ab95fe2 ("drm/i915/audio: add codec wakeup
override enabled/disable callback"), in order to en
From: Alex Dai
Can't immediately free LRC (neither unpin it) even all its
referenced requests are completed, because HW still need a short
period of time to save data to LRC status page. It is safe to free
LRC when HW completes a request from a different LRC.
Introduce a new function intel_lr_co
On Thu, Nov 19, 2015 at 03:10:14PM -0800, Ben Widawsky wrote:
> On Wed, Oct 21, 2015 at 06:40:31PM +0300, Imre Deak wrote:
> > The data in this struct is provided both by getting the
> > slice/subslice/eu features available on a given platform and the actual
> > runtime state of these same features
From: Alex Dai
When GuC Work Queue is full, driver will wait GuC for avaliable
space by calling wait_for_atomic. If irq is disabled, lockup will
happen because jiffies won't be updated.
Issue is found in igt/gem_close_race.
Signed-off-by: Alex Dai
---
drivers/gpu/drm/i915/i915_guc_submission.
From: Alex Dai
There is a memory leak warning message from i915_gem_context_clean
when GuC submission is enabled. The reason is that when LRC is
released, its ppgtt could be still referenced. The assumption that
all VMAs are unbound during release of LRC is not true.
v1: Move the code inside i91
On Wed, Oct 21, 2015 at 06:40:37PM +0300, Imre Deak wrote:
> Currently when checking for fused off EUs we may ignore the EU count in
> an enabled slice if there is any disabled slice preceding the enabled
> one (with a lower slice ID). Perhaps this can't happen in reality, but
> there is no reason
On Wed, Oct 21, 2015 at 06:40:35PM +0300, Imre Deak wrote:
> In an upcoming patch we'll need the actual mask of subslices in addition
> to their count, so convert the subslice_per_slice field to a mask.
> Also we can easily calculate subslice_total from the other fields, so
> instead of storing a c
On Wed, Oct 21, 2015 at 06:40:34PM +0300, Imre Deak wrote:
> In an upcoming patch we'll need the actual mask of slices in addition to
> their count, so replace the count field with a mask.
>
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 14 +++---
> drivers/gpu
On Wed, Oct 21, 2015 at 06:40:33PM +0300, Imre Deak wrote:
> Signed-off-by: Imre Deak
Reviewed-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 55
> +++--
> 1 file changed, 29 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/
On Wed, Oct 21, 2015 at 06:40:32PM +0300, Imre Deak wrote:
> Move all slice/subslice/eu related properties to the sseu_dev_info
> struct.
>
> No functional change.
>
> Signed-off-by: Imre Deak
Reviewed-by: Ben Widawsky
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 25
On Wed, Oct 21, 2015 at 06:40:31PM +0300, Imre Deak wrote:
> The data in this struct is provided both by getting the
> slice/subslice/eu features available on a given platform and the actual
> runtime state of these same features which depends on the HW's current
> power saving state.
>
> Atm memb
Hi Chris,
On Thu, Nov 19, 2015 at 09:46:34PM +, Chris Wilson wrote:
> On Thu, Nov 19, 2015 at 04:58:44PM +0100, Daniel Vetter wrote:
> > On Wed, Nov 18, 2015 at 04:29:51PM +0100, Lukas Wunner wrote:
> > > @@ -727,7 +730,8 @@ void intel_fbdev_fini(struct drm_device *dev)
> > >
> > > flush_w
On Thu, 2015-11-19 at 23:50 +0200, Imre Deak wrote:
> On Thu, 2015-11-19 at 21:38 +, Chris Wilson wrote:
> > On Thu, Nov 19, 2015 at 11:01:49PM +0200, Imre Deak wrote:
> > > On Thu, 2015-11-19 at 20:51 +, Chris Wilson wrote:
> > > > On Thu, Nov 19, 2015 at 08:55:00PM +0200, Imre Deak wrote:
On Thu, 2015-11-19 at 21:38 +, Chris Wilson wrote:
> On Thu, Nov 19, 2015 at 11:01:49PM +0200, Imre Deak wrote:
> > On Thu, 2015-11-19 at 20:51 +, Chris Wilson wrote:
> > > On Thu, Nov 19, 2015 at 08:55:00PM +0200, Imre Deak wrote:
> > > > Suggested by Ville.
> > >
> > > Do you mind explai
On Thu, Nov 19, 2015 at 04:58:44PM +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 04:29:51PM +0100, Lukas Wunner wrote:
> > @@ -727,7 +730,8 @@ void intel_fbdev_fini(struct drm_device *dev)
> >
> > flush_work(&dev_priv->fbdev_suspend_work);
> >
> > - async_synchronize_full();
> > +
On Thu, Nov 19, 2015 at 11:01:49PM +0200, Imre Deak wrote:
> On Thu, 2015-11-19 at 20:51 +, Chris Wilson wrote:
> > On Thu, Nov 19, 2015 at 08:55:00PM +0200, Imre Deak wrote:
> > > Suggested by Ville.
> >
> > Do you mind explaining why this is done at the hdmi level and not the
> > gmbus level
On 2015-11-10 21:15, Jesse Barnes wrote:
On 08/17/2015 08:46 AM, ville.syrj...@linux.intel.com wrote:
From: Ville Syrjälä
Set up the DDI->PLL mapping on SKL also for MST links. Might help make
MST operational on SKL.
Cc: Maarten Lankhorst
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i
On Thu, Nov 19, 2015 at 10:06:01PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 19, 2015 at 05:44:51PM -0200, Paulo Zanoni wrote:
> > 2014-05-26 11:26 GMT-03:00 :
> > > From: Ville Syrjälä
> > >
> > > Now that the vblank races are plugged, we can opt out of using
> > > the vblank disable timer and j
On Thu, Nov 19, 2015 at 10:53:30PM +0200, Ville Syrjälä wrote:
> On Thu, Nov 19, 2015 at 06:35:04PM -0200, Paulo Zanoni wrote:
> > 2015-11-19 18:06 GMT-02:00 Ville Syrjälä :
> > > On Thu, Nov 19, 2015 at 05:44:51PM -0200, Paulo Zanoni wrote:
> > >> 2014-05-26 11:26 GMT-03:00 :
> > >> > From: Ville
On Thu, Nov 19, 2015 at 05:46:50PM +0100, Daniel Vetter wrote:
> To avoid even more code duplication punt this all to the probe worker,
> which needs some slight adjustment to also generate a uevent when the
> status has changed to due connector->force.
>
> v2: Instead of running the output_poll_w
On Thu, Nov 19, 2015 at 05:24:03PM +, Tvrtko Ursulin wrote:
> >>+ while (i % 4)
> >>+ batch[i++] = MI_NOOP;
>
> Is this ok? I arrived at it by experimentation, kernel was
> complaining that relocations are not 4-byte aligned without it.
batch is u32, so all is good
On Thu, 2015-11-19 at 20:51 +, Chris Wilson wrote:
> On Thu, Nov 19, 2015 at 08:55:00PM +0200, Imre Deak wrote:
> > Suggested by Ville.
>
> Do you mind explaining why this is done at the hdmi level and not the
> gmbus level?
To reduce the on/off toggling, since we don't have delayed power-off
On Thu, Nov 19, 2015 at 06:35:04PM -0200, Paulo Zanoni wrote:
> 2015-11-19 18:06 GMT-02:00 Ville Syrjälä :
> > On Thu, Nov 19, 2015 at 05:44:51PM -0200, Paulo Zanoni wrote:
> >> 2014-05-26 11:26 GMT-03:00 :
> >> > From: Ville Syrjälä
> >> >
> >> > Now that the vblank races are plugged, we can opt
On Thu, Nov 19, 2015 at 08:55:00PM +0200, Imre Deak wrote:
> Suggested by Ville.
Do you mind explaining why this is done at the hdmi level and not the
gmbus level?
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
I
2015-11-19 18:06 GMT-02:00 Ville Syrjälä :
> On Thu, Nov 19, 2015 at 05:44:51PM -0200, Paulo Zanoni wrote:
>> 2014-05-26 11:26 GMT-03:00 :
>> > From: Ville Syrjälä
>> >
>> > Now that the vblank races are plugged, we can opt out of using
>> > the vblank disable timer and just let vblank interrupts
Hi again,
On Thu, Nov 19, 2015 at 05:02:04PM +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 01:43:20PM +0100, Lukas Wunner wrote:
> > --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> > @@ -408,7 +408,10 @@ static void intel_connector_add_to_fbdev(str
One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disable FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame a
On Thu, Nov 19, 2015 at 05:44:51PM -0200, Paulo Zanoni wrote:
> 2014-05-26 11:26 GMT-03:00 :
> > From: Ville Syrjälä
> >
> > Now that the vblank races are plugged, we can opt out of using
> > the vblank disable timer and just let vblank interrupts get
> > disabled immediately when the last refere
Hi Kevin,
On Thu, 2015-11-19 at 04:06 +, Tian, Kevin wrote:
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Thursday, November 19, 2015 2:12 AM
> >
> > [cc +qemu-devel, +paolo, +gerd]
> >
> > On Tue, 2015-10-27 at 17:25 +0800, Jike Song wrote:
> > > Hi all,
> > >
> >
2014-05-26 11:26 GMT-03:00 :
> From: Ville Syrjälä
>
> Now that the vblank races are plugged, we can opt out of using
> the vblank disable timer and just let vblank interrupts get
> disabled immediately when the last reference is dropped.
>
> Gen2 is the exception since it has no hardware frame c
On Thu, Nov 19, 2015 at 09:13:04PM +0200, Imre Deak wrote:
> On Thu, 2015-11-19 at 21:08 +0200, Ville Syrjälä wrote:
> > On Thu, Nov 19, 2015 at 08:55:01PM +0200, Imre Deak wrote:
> > > There are platforms that don't need the full GMBUS power domain
> > > (PCH, BXT) while others do (VLV/CHV). For o
On Thu, 2015-11-19 at 21:08 +0200, Ville Syrjälä wrote:
> On Thu, Nov 19, 2015 at 08:55:01PM +0200, Imre Deak wrote:
> > There are platforms that don't need the full GMBUS power domain
> > (PCH, BXT) while others do (VLV/CHV). For optimizing this we
> > would need to add a new power domain, but it'
On Thu, Nov 19, 2015 at 08:55:01PM +0200, Imre Deak wrote:
> There are platforms that don't need the full GMBUS power domain
> (PCH, BXT) while others do (VLV/CHV). For optimizing this we
> would need to add a new power domain, but it's not clear how much we
> would benefit given the short time we
There are platforms that don't need the full GMBUS power domain
(PCH, BXT) while others do (VLV/CHV). For optimizing this we
would need to add a new power domain, but it's not clear how much we
would benefit given the short time we hold the reference. So for now
let's keep things simple.
Signed-of
Suggested by Ville.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/intel_hdmi.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index fd86cef..17ced03 100644
--- a/drivers/gpu/drm/i915/intel_hdmi
On Thu, 2015-11-19 at 08:44 +, Daniel Stone wrote:
> Hi Rodrigo,
>
> On 19 November 2015 at 00:39, Rodrigo Vivi
> wrote:
> > @@ -441,15 +438,14 @@ void intel_psr_enable(struct intel_dp
> > *intel_dp)
> > /*
> > * FIXME: Activation should happen immediately since this
> > f
On Thu, Nov 19, 2015 at 06:26:23PM +, Daniel Stone wrote:
> Hey,
>
> On 19 November 2015 at 18:24, Ville Syrjälä
> wrote:
> > On Thu, Nov 19, 2015 at 05:59:10PM +, Daniel Stone wrote:
> >> +static inline const char *
> >> +intel_display_power_domain_str(enum intel_display_power_domain dom
On Wed, Nov 18, 2015 at 11:45 PM, Jindal, Sonika
wrote:
> Hi Rodrigo,
>
> Which platform have you observed this issue on?
Skylake and Kabylake
> This looks really strange.
It is expected actually.
On DC5/6 states all read-only registers are reset and cannot be
restored. including this counter.
Hey,
On 19 November 2015 at 18:24, Ville Syrjälä
wrote:
> On Thu, Nov 19, 2015 at 05:59:10PM +, Daniel Stone wrote:
>> +static inline const char *
>> +intel_display_power_domain_str(enum intel_display_power_domain domain)
>
> It's still const. And I assume now we end up duplicating these stri
On Thu, Nov 19, 2015 at 05:59:10PM +, Daniel Stone wrote:
> Let us print human-parseable values from the power domain code; upcoming
> display code also wants to use it.
>
> Signed-off-by: Daniel Stone
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 67
> +
On to, 2015-11-19 at 19:00 +0100, Patrik Jakobsson wrote:
> On Thu, Nov 19, 2015 at 04:06:47PM +0200, Imre Deak wrote:
> > On to, 2015-11-19 at 14:34 +0100, Patrik Jakobsson wrote:
> > > On Wed, Nov 18, 2015 at 06:44:43PM +0200, Imre Deak wrote:
> > > > On ke, 2015-11-18 at 17:33 +0100, Daniel Vett
On Wed, Nov 18, 2015 at 07:53:50PM +0200, Imre Deak wrote:
> Now that the known DMC/DC issues are fixed, let's try again and
> re-enable the power well support.
>
> Signed-off-by: Imre Deak
Together with the PC9/10 fix this is:
Reviewed-by: Patrik Jakobsson
> ---
> drivers/gpu/drm/i915/intel
On Thu, Nov 19, 2015 at 04:06:47PM +0200, Imre Deak wrote:
> On to, 2015-11-19 at 14:34 +0100, Patrik Jakobsson wrote:
> > On Wed, Nov 18, 2015 at 06:44:43PM +0200, Imre Deak wrote:
> > > On ke, 2015-11-18 at 17:33 +0100, Daniel Vetter wrote:
> > > > On Wed, Nov 18, 2015 at 05:32:30PM +0200, Imre D
Let us print human-parseable values from the power domain code; upcoming
display code also wants to use it.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/i915/i915_debugfs.c | 67 +
drivers/gpu/drm/i915/i915_drv.h | 66 +++
If we experience a refcounting failure in a power domain/well (unref'ing at
least one too many times), log the name of the offending domain or well.
Signed-off-by: Daniel Stone
---
drivers/gpu/drm/i915/intel_runtime_pm.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a
Add the Kabylake GT4 PCI IDs as defined in this kernel patch.
commit 8b10c0cf21ec84618d4bf02c73c0543500ece68d
Author: Deepak S
Date: Wed Oct 28 12:21:12 2015 -0700
drm/i915/kbl: Add Kabylake GT4 PCI ID
Cc: Rodrigo Vivi
Signed-off-by: Wayne Boyer
---
lib/intel_chipset.h |
Remove the KBL check from IS_SKYLAKE() following the kernel definition.
Then, add the KBL check to IS_GEN9().
The idea is to avoid confusion. On the kernel side, the mix of SKY
and KBL was nacked so the platforms are split.
Cc: Rodrigo Vivi
Signed-off-by: Wayne Boyer
---
lib/intel_chipset.h |
Hi,
On 19/11/15 16:58, Chris Wilson wrote:
On Thu, Nov 19, 2015 at 03:06:05PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Test designed to trigger the
WARN_ON(!list_empty(&ppgtt->base.active_list))
in i915_gem_context_clean.
Signed-off-by: Tvrtko Ursulin
Cc: Chris Wilson
Cc: Daniel
From: Clint Taylor
Add SKL and KBL cdclk changes during modeset. Taking into account new
linkrates available using 8640 VCO.
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/intel_display.c | 68 ++
1 file changed, 68 insertions(+)
diff --git a/drivers/gp
On Thu, Nov 19, 2015 at 04:50:11PM +, Daniel Stone wrote:
> Hi,
>
> On 19 November 2015 at 16:46, Daniel Vetter wrote:
> > @@ -367,7 +364,6 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev,
> > void *data,
> > args->size = exynos_gem->size;
> >
> > drm_gem_object_unrefe
On Thu, Nov 19, 2015 at 03:06:05PM +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Test designed to trigger the
> WARN_ON(!list_empty(&ppgtt->base.active_list))
> in i915_gem_context_clean.
>
> Signed-off-by: Tvrtko Ursulin
> Cc: Chris Wilson
> Cc: Daniel Vetter
Wouldn't this be a be
We need to drop the gem bo reference if it's an imported one.
Cc: Russell King
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_gem.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
in
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 still cares).
v2: Finally get rid of the copypasta from another c
This only grabs the mutex when really needed, but still has a
might-acquire lockdep check to make sure that's always possible.
With this patch tegra is officially struct_mutex free, yay!
v2: refernce_unlocked doesn't exist as kbuild spotted.
Cc: Thierry Reding
Acked-by: Thierry Reding
Signed-of
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 still cares).
v2: Split out the leak fix in dump_map_offset into
On Thu, Nov 19, 2015 at 11:10:16AM -0500, Tejun Heo wrote:
> Hello, Lukas.
>
> On Thu, Nov 19, 2015 at 04:31:11PM +0100, Lukas Wunner wrote:
> > Hi Tejun,
> >
> > when you introduced current_is_async() with 84b233adcca3, was it a
> > deliberate decision not to export it? All other non-static func
On Thu, Nov 19, 2015 at 04:47:44PM +, Arun Siluvery wrote:
> This reverts commit 2e5356da370e36ba7aab39d2800c7a2412630ae7.
>
> It is now redundant as it is already covered in below commit which introduced
> the changes to reuse initialization of resources in resume/reset path.
>
> commit e84f
Hi,
On 19 November 2015 at 16:46, Daniel Vetter wrote:
> @@ -367,7 +364,6 @@ int exynos_drm_gem_get_ioctl(struct drm_device *dev, void
> *data,
> args->size = exynos_gem->size;
>
> drm_gem_object_unreference(obj);
> - mutex_unlock(&dev->struct_mutex);
drm_gem_object_unrefe
This reverts commit 2e5356da370e36ba7aab39d2800c7a2412630ae7.
It is now redundant as it is already covered in below commit which introduced
the changes to reuse initialization of resources in resume/reset path.
commit e84fe80337dc85cca07d0417ea97edbec4789d8b
Author: Nick Hoath
Date: Fri Sep 11
It's racy, creating mmap offsets is a slowpath, so better to remove it
to avoid drivers doing broken things.
The only user is i915, and it's ok there because everything (well
almost) is protected by dev->struct_mutex in i915-gem.
While at it add a note in the create_mmap_offset kerneldoc that
dri
Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.
Aside: DRM_ERROR for userspace controlled input isn't great, but
that's for another patch.
Signed-
This is called without dev->struct_mutex held, we need to use the
_unlocked variant.
Never caught in the wild since you'd need an evil userspace which
races a gem_close ioctl call with the in-progress open.
Cc: Patrik Jakobsson
Acked-by: Patrik Jakobsson
Signed-off-by: Daniel Vetter
---
drive
It's either init code or already protected by other means. Note
that psb_gtt_pin/unpin has it's own lock, and that's really the
only piece of driver private state - all the modeset state is
protected with modeset locks already.
The only important bit is to switch all gem_obj_unref calls to the
_un
Doesn't protect anything at all.
With this patch nouveau is completely dev->struct_mutex free!
Cc: Ben Skeggs
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/nouveau/nouveau_fbcon.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_fbcon.c
b/drivers/gpu/
The offset manager already checks for existing offsets internally,
while holding suitable locks. We can drop this check.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vgem/vgem_drv.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/
Doesn't protect anything at all, and probably just here because a long
time ago dev->struct_mutex was required to allocate gem objects.
With this patch exynos is completely struct_mutex free!
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 22 --
With the previous two changes it doesn't protect anything any more.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vgem/vgem_drv.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index 1a60934
The sg table isn't refcounted, there's no corresponding locking for
unmapping and drm_map_sg is ok with being called concurrently.
So drop the locking since it doesn't protect anything.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 4
1 file changed, 4 deletion
Simply forgotten about this when I was doing my general cleansing of
simple gem mmap offset functions. There's nothing but core functions
called here, and they all have their own protection already.
Cc: Patrik Jakobsson
Acked-by: Patrik Jakobsson
Signed-off-by: Daniel Vetter
---
drivers/gpu/dr
To avoid even more code duplication punt this all to the probe worker,
which needs some slight adjustment to also generate a uevent when the
status has changed to due connector->force.
v2: Instead of running the output_poll_work (which is kinda the wrong
thing and a layering violation since it's a
There's currently two places where the gma500 fault handler relies
upon dev->struct_mutex:
- To protect r->mappping
- To make sure vm_insert_pfn isn't called concurrently (in which case
the 2nd thread would get an error code).
Everything else (specifically psb_gtt_pin) is already protected by
so
The kms state itself is already protected by the modeset locks
acquired by the drm core. The only thing left is gem bo state, and
since the cursor code expects small objects which are statically
mapped at create time and then invariant over the lifetime of the gem
bo there's nothing to protect.
Se
This is init/teardown code, locking is just to appease locking checks.
And since gem create/free doesn't need this any more there's really no
reason for grabbing dev->struct_mutex.
Again important to switch obj_unref to _unlocked variants.
Cc: Patrik Jakobsson
Acked-by: Patrik Jakobsson
Signed-
The only things this protects is reading ->flags and ->size, both of
which are invariant over the lifetime of an exynos gem bo. So no
locking needed at all (besides that, nothing protects the writers
anyway).
Aside: exynos_gem_obj->size is redundant with
exynos_gem_obj->base.size and probably shou
vgem doesn't have a shrinker or anything like that and drops backing
storage only at object_free time. There's no use in trying to be
clever and allocating backing storage delayed, it only causes trouble
by requiring locking.
Instead grab pages when we allocate the object right away.
Signed-off-b
Reusing the Big DRM Lock just leaks, and the few things left that
dev->struct_mutex protected are very well contained - it's just the
linear drm_mm manager.
With this armada is completely struct_mutex free!
Cc: Russell King
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_debugfs
Hi all,
Here's my resend of the dev->struct_mutex locking removal patches. I'd like to
get them all into 4.5, so please pick them either up into your tree or ack them.
I'll send a pull request for the remaining in a few weeks.
Thanks, Daniel
Daniel Vetter (20):
drm/armada: Plug leak in dumb_ma
On 11/19/2015 01:35 AM, Chris Wilson wrote:
> On Thu, Nov 19, 2015 at 10:14:08AM +0100, Daniel Vetter wrote:
>> On Wed, Nov 18, 2015 at 03:08:47PM -0800, Jesse Barnes wrote:
>>> On 11/17/2015 08:37 AM, Daniel Vetter wrote:
On Fri, Oct 30, 2015 at 04:58:41PM +, Chris Wilson wrote:
> On
On 11/18/2015 02:56 AM, Chris Wilson wrote:
This should filter out all explicit wait requests from userspace and
only apply busywaiting to circumstances where we are forced to drain the
GPU of old requests. With the 2 microsecond timeout from before, this
still seems to preserve the speed up in s
On Fri, Oct 02, 2015 at 01:08:40PM +0100, Emil Velikov wrote:
> On 2 October 2015 at 12:01, Daniel Vetter wrote:
> > We chase pointers/lists without taking the locks protecting them,
> > which isn't that good.
> >
> > Fix it.
> >
> > v2: Actually unlock properly, spotted by Julia.
> >
> > v3: Put
Hi,
On Thu, Nov 19, 2015 at 05:02:04PM +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 01:43:20PM +0100, Lukas Wunner wrote:
> > intelfb_create() is called once on driver initialization. If it fails,
> > ifbdev->helper.fbdev, ifbdev->fb or ifbdev->fb->obj may be NULL.
> >
> > Further up in
Hello, Lukas.
On Thu, Nov 19, 2015 at 04:31:11PM +0100, Lukas Wunner wrote:
> Hi Tejun,
>
> when you introduced current_is_async() with 84b233adcca3, was it a
> deliberate decision not to export it? All other non-static functions
> in async.c are exported as well.
>
> I'm asking because I would
Hi,
On Thu, Nov 19, 2015 at 04:58:44PM +0100, Daniel Vetter wrote:
> On Wed, Nov 18, 2015 at 04:29:51PM +0100, Lukas Wunner wrote:
> > Currently if intelfb_create() errors out, it unrefs the bo even though
> > the fb now owns that reference. (Spotted by Ville Syrjälä.) We should
> > unref the fb i
On Thu, 19 Nov 2015 16:51:05 +0100,
Daniel Vetter wrote:
>
> On Thu, Nov 19, 2015 at 12:09:56PM +0100, Takashi Iwai wrote:
> > Currently a DDI port may register the DP hotplug handler even though
> > it's used with HDMI, and the DP HPD handler overrides the encoder
> > type forcibly to DP. This c
On Thu, 19 Nov 2015, Daniel Vetter wrote:
> On Thu, Nov 19, 2015 at 10:44:48PM +0800, han...@intel.com wrote:
>> From: "Lu, Han"
>>
>> For SKL we added a commit 632f3ab95fe2 ("drm/i915/audio: add codec wakeup
>> override enabled/disable callback"), in order to enable codec wakeup
>> override sig
On Wed, Nov 18, 2015 at 01:43:20PM +0100, Lukas Wunner wrote:
> intelfb_create() is called once on driver initialization. If it fails,
> ifbdev->helper.fbdev, ifbdev->fb or ifbdev->fb->obj may be NULL.
>
> Further up in the call stack, intel_fbdev_initial_config() calls
> intel_fbdev_fini() to tea
Hi Dave -
Here are some drm core fixes for v4.4 that I've picked up. Atomic fixes
from Maarten, and atomic helper fixes from Ville and Daniel.
Admittedly the topmost commit didn't sit in our tree for very long, but
does come with reviews and testing from trustworthy people.
BR,
Jani.
The follo
On Wed, Nov 18, 2015 at 04:29:51PM +0100, Lukas Wunner wrote:
> Currently if intelfb_create() errors out, it unrefs the bo even though
> the fb now owns that reference. (Spotted by Ville Syrjälä.) We should
> unref the fb instead of the bo.
>
> However the fb was not necessarily allocated by intel
1 - 100 of 198 matches
Mail list logo
