>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Ville Syrjälä
>Sent: Tuesday, January 29, 2019 10:09 PM
>To: Shankar, Uma
>Cc: Syrjala, Ville ; intel-...@lists.freedesktop.org;
>emil.l.veli...@gmail.com; dri-devel@lists.freedesktop.org;
https://bugs.freedesktop.org/show_bug.cgi?id=108889
--- Comment #5 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- HSW SKL ICL: igt@sw_sync@sync_busy_fork* - incomplete - __igt_fork_helper:
Assertion `!proc->running' failed. -}
{+ HSW SKL KBL ICL: igt@sw_sync@
On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
>
>
> Den 24.01.2019 18.57, skrev Daniel Vetter:
> > On Thu, Jan 24, 2019 at 6:46 PM Greg KH wrote:
> >>
> >> On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> >>> On Wed, Jan 23, 2019 at 11:54:07AM +0100, Noralf Trøn
https://bugs.freedesktop.org/show_bug.cgi?id=109498
Bug ID: 109498
Summary: Game enabling VBO Core but disabling VAO Core causing
reproducible, predictable, spontaneous powerdown
Product: DRI
Version: XOrg git
Hardware: x86
On Tue, Jan 29, 2019 at 03:18:00PM +0100, Sam Ravnborg wrote:
> Hi Daniel.
>
> >
> > Sam, want drm-misc commit rights to start merging your own stuff? Assuming
> > you plan to stick around ofc ... I'll also ask the drm-misc maintainers
> > whether that's ok.
>
> The plan is to re-submit the Atme
https://bugs.freedesktop.org/show_bug.cgi?id=109498
--- Comment #1 from Alex Deucher ---
Please attach your dmesg output and xorg log (if using X).
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri
From: Ville Syrjälä
drm_color_lut_check() doens't modify the passed in blob so
let's make it const.
Also s/uint32_y/u32/ while at it.
Cc: Matt Roper
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_color_mgmt.c | 6 +++---
include/drm/drm_color_mgmt.h | 4 ++--
2 files changed, 5 ins
https://bugs.freedesktop.org/show_bug.cgi?id=109498
--- Comment #2 from Adam Wenocur ---
Created attachment 143249
--> https://bugs.freedesktop.org/attachment.cgi?id=143249&action=edit
dmesg output
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=109498
--- Comment #3 from Adam Wenocur ---
Created attachment 143250
--> https://bugs.freedesktop.org/attachment.cgi?id=143250&action=edit
XOrg log
--
You are receiving this mail because:
You are the assignee for the bug.__
On Tue, Jan 29, 2019 at 11:45:10AM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Changes in v2:
> - Add drm_display_mode.vrefresh removal (Ville)
> - Add Sam's R-b and bonus points
hsync has the same problem, maybe add that too. With that:
Reviewed-by: Daniel Vetter
> Cc: Ville Syrjälä
> Su
Den 29.01.2019 17.50, skrev Daniel Vetter:
> On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 24.01.2019 18.57, skrev Daniel Vetter:
>>> On Thu, Jan 24, 2019 at 6:46 PM Greg KH wrote:
On Thu, Jan 24, 2019 at 11:43:12AM +0100, Daniel Vetter wrote:
> On We
On Tue, Jan 29, 2019 at 8:43 PM Maxime Ripard wrote:
>
> On Mon, Jan 28, 2019 at 03:06:10PM +0530, Jagan Teki wrote:
> > On Sat, Jan 26, 2019 at 2:54 AM Maxime Ripard
> > wrote:
> > >
> > > On Fri, Jan 25, 2019 at 01:28:49AM +0530, Jagan Teki wrote:
> > > > Minimum PLL used for MIPI is 500MHz, a
On Tue, Jan 29, 2019 at 05:50:05PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 24.01.2019 18.57, skrev Daniel Vetter:
> > > On Thu, Jan 24, 2019 at 6:46 PM Greg KH
> > > wrote:
> > >>
> > >> On Thu, Jan 24, 2019 at 11:43:12AM +01
From: Jérôme Glisse
This patchset add support for peer to peer between device in two manner.
First for device memory use through HMM in process regular address space
(ie inside a regular vma that is not an mmap of device file or special
file). Second for special vma ie mmap of a device file, in t
From: Jérôme Glisse
device_test_p2p() return true if two devices can peer to peer to
each other. We add a generic function as different inter-connect
can support peer to peer and we want to genericaly test this no
matter what the inter-connect might be. However this version only
support PCIE for
From: Jérôme Glisse
device_test_p2p() return true if two devices can peer to peer to
each other. We add a generic function as different inter-connect
can support peer to peer and we want to genericaly test this no
matter what the inter-connect might be. However this version only
support PCIE for
From: Jérôme Glisse
Special device vma (mmap of a device file) can correspond to device
driver object that some device driver might want to share with other
device (giving access to). This add support for HMM to map those
special device vma if the owning device (exporter) allows it.
Signed-off-b
From: Jérôme Glisse
Signed-off-by: Jérôme Glisse
Cc: Logan Gunthorpe
Cc: Greg Kroah-Hartman
Cc: Rafael J. Wysocki
Cc: Bjorn Helgaas
Cc: Christian Koenig
Cc: Felix Kuehling
Cc: Jason Gunthorpe
Cc: linux-...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: Christoph Hellwig
Cc: Mare
From: Jérôme Glisse
Allow mmap of device file to export device memory to peer to peer
devices. This will allow for instance a network device to access a
GPU memory or to access a storage device queue directly.
The common case will be a vma created by userspace device driver
that is then share to
Hi Ville.
On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_color_lut_check() doens't modify the passed in blob so
> let's make it const.
>
> Also s/uint32_y/u32/ while at it.
>
> Cc: Matt Roper
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/dr
https://bugs.freedesktop.org/show_bug.cgi?id=109499
Bug ID: 109499
Summary: amdgpu 4k modes not working
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: norm
https://bugs.freedesktop.org/show_bug.cgi?id=109499
--- Comment #1 from Nadal Gonzalo García Zavala
---
Created attachment 143251
--> https://bugs.freedesktop.org/attachment.cgi?id=143251&action=edit
EDID firmware
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=109499
--- Comment #2 from Nadal Gonzalo García Zavala
---
Created attachment 143252
--> https://bugs.freedesktop.org/attachment.cgi?id=143252&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug._
On Tue, Jan 29, 2019 at 06:52:51PM +0100, Sam Ravnborg wrote:
> Hi Ville.
>
> On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > drm_color_lut_check() doens't modify the passed in blob so
> > let's make it const.
> >
> > Also s/uint32_y/u32/ while at
https://bugs.freedesktop.org/show_bug.cgi?id=109499
--- Comment #3 from Nadal Gonzalo García Zavala
---
Created attachment 143253
--> https://bugs.freedesktop.org/attachment.cgi?id=143253&action=edit
parse-edid
--
You are receiving this mail because:
You are the assignee for the bug.
On Tue, Jan 29, 2019 at 6:36 PM Greg KH wrote:
>
> On Tue, Jan 29, 2019 at 05:50:05PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
> > >
> > >
> > > Den 24.01.2019 18.57, skrev Daniel Vetter:
> > > > On Thu, Jan 24, 2019 at 6:46 PM Greg KH
> > >
On Tuesday, 2019-01-29 14:21:53 +0100, Daniel Vetter wrote:
> I'm kinda fed up explaining why the have a confusing name :-)
>
> Cc: Noralf Trønnes
> Cc: Laurent Pinchart
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 10 ++
> 1 file changed, 10 insertions(+)
>
> d
This patch series creates a new connector property to program
colorspace to sink devices. Modern sink devices support more
than 1 type of colorspace like 601, 709, BT2020 etc. This helps
to switch based on content type which is to be displayed. The
decision lies with compositors as to in which scen
This patch adds a DP colorspace property, enabling
userspace to switch to various supported colorspaces.
This will help enable BT2020 along with other colorspaces.
v2: Addressed Maarten and Ville's review comments. Enhanced
the colorspace enum to incorporate both HDMI and DP supported
colo
This patch attaches the colorspace connector property to the
hdmi connector. Based on colorspace change, modeset will be
triggered to switch to new colorspace.
Based on colorspace property value create an infoframe
with appropriate colorspace. This can be used to send an
infoframe packet with prop
Create a new connector property to program colorspace to sink
devices. Modern sink devices support more than 1 type of
colorspace like 601, 709, BT2020 etc. This helps to switch
based on content type which is to be displayed. The decision
lies with compositors as to in which scenarios, a particular
Since
commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
connectors harder")
We've been failing atomic checks if they try to enable new displays on
unregistered connectors. This is fine except for the one situation that
breaks atomic assumptions: suspend/resume. If a connector
Since there's a chance MST topologies can be removed while the system is
in suspend, there's also a chance that the connectors in the atomic
state which we try to restore on system resume will have been
unregistered if they were part of an MST topology that was removed
mid-suspend. In such situatio
In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call
drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we
never successfully allocated VCPI to it. This is contrary to what we do
in drm_dp_mst_allocate_vcpi(), where we only call
drm_dp_mst_get_port_malloc() on the p
This fixes the extra issues I discovered upstream after the introduction
of my rework of the atomic VCPI helpers that occur during
suspend/resume.
Lyude Paul (3):
drm/dp_mst: Fix unbalanced malloc ref in drm_dp_mst_deallocate_vcpi()
drm/atomic: Add drm_atomic_state->suspend_or_resume
drm/i91
On 2019-01-29 1:56 p.m., Guenter Roeck wrote:
> On Tue, Jan 29, 2019 at 10:30:31AM -0500, Alex Deucher wrote:
>> On Fri, Jan 25, 2019 at 10:29 AM Wentland, Harry
>> wrote:
>>>
>>> On 2019-01-24 7:52 p.m., ndesaulni...@google.com wrote:
arch/x86/Makefile disables SSE and SSE2 for the whole ke
On Tue, Jan 29, 2019 at 07:58:56PM +0200, Ville Syrjälä wrote:
> On Tue, Jan 29, 2019 at 06:52:51PM +0100, Sam Ravnborg wrote:
> > Hi Ville.
> >
> > On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > drm_color_lut_check() doens't modify the passe
This hotplug also isn't needed: drm_dp_mst_topology_mgr_set_mst()
already sends a hotplug on its own from drm_dp_destroy_connector_work()
after destroying connectors in the MST topology.
Signed-off-by: Lyude Paul
Cc: Imre Deak
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/intel_dp.c | 6 ++
1
While trying to fix a problem with suspend/resume that I introduced in
the atomic VCPI helpers for MST, I also ran into some issues with i915
varying from "not that bad" to "oh wow that's very bad". Here are the
fixes for those issues.
This series was originally just one patch,
"drm/i915: Don't se
We have a bad habit of calling drm_fb_helper_hotplug_event() far more
then we actually need to. MST appears to be one of these cases, where we
call drm_fb_helper_hotplug_event() if we fail to resume a connected MST
topology in intel_dp_mst_resume(). We don't actually need to do this at
all though s
When resuming, we check whether or not any previously connected
MST topologies are still present and if so, attempt to resume them. If
this fails, we disable said MST topologies and fire off a hotplug event
so that userspace knows to reprobe.
However, sending a hotplug event involves calling
drm_f
On Tue, Jan 29, 2019 at 11:36:29AM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
>
> > + /*
> > +* Optional for device driver that want to allow peer to peer (p2p)
> > +* mapping of their vma (which can be back by some device memory) to
> > +
Quoting Lyude Paul (2019-01-29 19:09:59)
> When resuming, we check whether or not any previously connected
> MST topologies are still present and if so, attempt to resume them. If
> this fails, we disable said MST topologies and fire off a hotplug event
> so that userspace knows to reprobe.
>
> Ho
On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_color_lut_check() doens't modify the passed in blob so
s/doens't/doesn't/
Otherwise, LGTM.
Reviewed-by:
> let's make it const.
>
> Also s/uint32_y/u32/ while at it.
>
> Cc: Matt Roper
> Signed-off
From: Sean Paul
Drivers shouldn't be using these values, add a TODO so someone removes
them.
Changes in v2:
- Add drm_display_mode.vrefresh removal (Ville)
- Add Sam's R-b and bonus points
Changes in v3:
- Add hsync removal todo item (Daniel)
- Change vrefresh wording to make removal less option
On Tue, Jan 29, 2019 at 07:10:55PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2019 at 6:36 PM Greg KH wrote:
> >
> > On Tue, Jan 29, 2019 at 05:50:05PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf Trønnes wrote:
> > > >
> > > >
> > > > Den 24.01.2019 18.57,
On Tue, Jan 29, 2019 at 11:24:09AM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> > +bool pci_test_p2p(struct device *devA, struct device *devB)
> > +{
> > + struct pci_dev *pciA, *pciB;
> > + bool ret;
> > + int tmp;
> > +
> > + /*
> > +* Fo
On Tue, Jan 29, 2019 at 12:24:04PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 12:11 p.m., Jerome Glisse wrote:
> > On Tue, Jan 29, 2019 at 11:36:29AM -0700, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> >>
> >>> + /*
> >>> + * Optional for dev
On Tue, Jan 29, 2019 at 12:47:25PM -0500, jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
> device_test_p2p() return true if two devices can peer to peer to
> each other. We add a generic function as different inter-connect
> can support peer to peer and we want to genericaly test this no
> mat
On Tue, Jan 29, 2019 at 07:32:57PM +, Jason Gunthorpe wrote:
> On Tue, Jan 29, 2019 at 02:11:23PM -0500, Jerome Glisse wrote:
> > On Tue, Jan 29, 2019 at 11:36:29AM -0700, Logan Gunthorpe wrote:
> > >
> > >
> > > On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> > >
> > > > + /*
>
On Tue, Jan 29, 2019 at 08:44:26PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 29, 2019 at 11:24:09AM -0700, Logan Gunthorpe wrote:
> >
> >
> > On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> > > +bool pci_test_p2p(struct device *devA, struct device *devB)
> > > +{
> > > + struct pci_dev
On Tue, Jan 29, 2019 at 11:26:01AM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> > From: Jérôme Glisse
> >
> > device_test_p2p() return true if two devices can peer to peer to
> > each other. We add a generic function as different inter-connect
> > ca
On Tue, Jan 29, 2019 at 12:47 PM wrote:
>
> From: Jérôme Glisse
>
> device_test_p2p() return true if two devices can peer to peer to
> each other. We add a generic function as different inter-connect
> can support peer to peer and we want to genericaly test this no
> matter what the inter-connect
On Tue, Jan 29, 2019 at 08:46:05PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 29, 2019 at 12:47:25PM -0500, jgli...@redhat.com wrote:
> > From: Jérôme Glisse
> >
> > device_test_p2p() return true if two devices can peer to peer to
> > each other. We add a generic function as different inter-c
On Tue, Jan 29, 2019 at 02:56:38PM -0500, Alex Deucher wrote:
> On Tue, Jan 29, 2019 at 12:47 PM wrote:
> >
> > From: Jérôme Glisse
> >
> > device_test_p2p() return true if two devices can peer to peer to
> > each other. We add a generic function as different inter-connect
> > can support peer to
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.1-wip
head: 5daa9c4d3d3cf0da1520ad5a814c7f970160194a
commit: 3cec41769d2182e629692a3262cc8b24ec972b04 [174/192] drm/amd/display: Fix
use of uninitialized union
config: i386-randconfig-h1-01290401 (attached as .config)
compiler: gcc
On Tue, Jan 29, 2019 at 01:39:26PM -0500, Lyude Paul wrote:
> Since
>
> commit 39b50c603878 ("drm/atomic_helper: Stop modesets on unregistered
> connectors harder")
>
> We've been failing atomic checks if they try to enable new displays on
> unregistered connectors. This is fine except for the on
On Tue, Jan 29, 2019 at 01:39:27PM -0500, Lyude Paul wrote:
> Since there's a chance MST topologies can be removed while the system is
> in suspend, there's also a chance that the connectors in the atomic
> state which we try to restore on system resume will have been
> unregistered if they were pa
On Tue, Jan 29, 2019 at 01:39:25PM -0500, Lyude Paul wrote:
> In drm_dp_mst_deallocate_vcpi(), we currently unconditionally call
> drm_dp_mst_put_port_malloc() on the port that's passed to us, even if we
> never successfully allocated VCPI to it. This is contrary to what we do
> in drm_dp_mst_alloc
On Tue, Jan 29, 2019 at 08:24:36PM +, Jason Gunthorpe wrote:
> On Tue, Jan 29, 2019 at 02:50:55PM -0500, Jerome Glisse wrote:
>
> > GPU driver do want more control :) GPU driver are moving things around
> > all the time and they have more memory than bar space (on newer platform
> > AMD GPU do
On Tue, Jan 29, 2019 at 01:39:49PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 12:32 p.m., Jason Gunthorpe wrote:
> > Jerome, I think it would be nice to have a helper scheme - I think the
> > simple case would be simple remapping of PCI BAR memory, so if we
> > could have, say something li
On Tue, Jan 29, 2019 at 01:44:09PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 12:44 p.m., Greg Kroah-Hartman wrote:
> > On Tue, Jan 29, 2019 at 11:24:09AM -0700, Logan Gunthorpe wrote:
> >>
> >>
> >> On 2019-01-29 10:47 a.m., jgli...@redhat.com wrote:
> >>> +bool pci_test_p2p(struct device
On Tue, Jan 29, 2019 at 3:25 PM Logan Gunthorpe wrote:
>
>
>
> On 2019-01-29 12:56 p.m., Alex Deucher wrote:
> > On Tue, Jan 29, 2019 at 12:47 PM wrote:
> >>
> >> From: Jérôme Glisse
> >>
> >> device_test_p2p() return true if two devices can peer to peer to
> >> each other. We add a generic func
On Tue, Jan 29, 2019 at 08:04:18PM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2019 at 07:58:56PM +0200, Ville Syrjälä wrote:
> > On Tue, Jan 29, 2019 at 06:52:51PM +0100, Sam Ravnborg wrote:
> > > Hi Ville.
> > >
> > > On Tue, Jan 29, 2019 at 07:06:09PM +0200, Ville Syrjala wrote:
> > > > From:
On Tue, Jan 29, 2019 at 02:30:49PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 1:57 p.m., Jerome Glisse wrote:
> > GPU driver must be in control and must be call to. Here there is 2 cases
> > in this patchset and i should have instead posted 2 separate patchset as
> > it seems that it is co
https://bugs.freedesktop.org/show_bug.cgi?id=109403
--- Comment #2 from Chris ---
I wonder if this is related to your motherboard. I have an ASUS Zenith with a
1950X, 128GB RAM and a Vega 64 LC that have been on Kernel 4.20 through
5.0-rc4. The latter of which I'm currently on. I have no kernel p
Hi all,
After merging the drm-intel-fixes tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/intel_display.c: In function 'has_bogus_dpll_config':
drivers/gpu/drm/i915/intel_display.c:15432:27: error: macro "IS_GEN" requires 3
arguments, but only 2 given
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: f479c0ba4a17 drm/nouveau/kms/nv50: initial support for DP 1.2
multi-stream.
The bot has tested the following trees: v4.20.5, v4.19.18, v4.14.96.
v4.20.5: Build OK!
v4.19.18: Build
On Tue, Jan 29, 2019 at 8:27 PM Greg KH wrote:
>
> On Tue, Jan 29, 2019 at 07:10:55PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 29, 2019 at 6:36 PM Greg KH wrote:
> > >
> > > On Tue, Jan 29, 2019 at 05:50:05PM +0100, Daniel Vetter wrote:
> > > > On Tue, Jan 29, 2019 at 03:34:46PM +0100, Noralf
On Tue, Jan 29, 2019 at 03:58:45PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 2:50 p.m., Jerome Glisse wrote:
> > No this is the non HMM case i am talking about here. Fully ignore HMM
> > in this frame. A GPU driver that do not support or use HMM in anyway
> > has all the properties and re
On Tue, Jan 29, 2019 at 11:02:25PM +, Jason Gunthorpe wrote:
> On Tue, Jan 29, 2019 at 03:44:00PM -0500, Jerome Glisse wrote:
>
> > > But this API doesn't seem to offer any control - I thought that
> > > control was all coming from the mm/hmm notifiers triggering p2p_unmaps?
> >
> > The contr
Some blocks in amdgpu can have 0 rqs.
Job creation already fails with -ENOENT when entity->rq is NULL,
so jobs cannot be pushed. Without a rq there is no scheduler to
pop jobs, and rq selection already does the right thing with a
list of length 0.
So the operations we need to fix are:
- Creatio
Otherwise we interpret the file private data as drm & amdgpu data
while it might not be, possibly allowing one to get memory corruption.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 ++
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 16
driver
Given a master fd we can then override the priority of the context
in another fd.
Using these overrides was recommended by Christian instead of trying
to submit from a master fd, and I am adding a way to override a
single context instead of the entire process so we can only upgrade
a single Vulkan
I don't see another way to figure out if a ring is initialized if
the hardware block might not be initialized.
Entities have been fixed up to handle num_rqs = 0.
Signed-off-by: Bas Nieuwenhuizen
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ctx.c | 11 ---
1 file changed, 8 insertions(+), 3 del
On Tue, Jan 29, 2019 at 06:17:43PM -0700, Logan Gunthorpe wrote:
>
>
> On 2019-01-29 4:47 p.m., Jerome Glisse wrote:
> > The whole point is to allow to use device memory for range of virtual
> > address of a process when it does make sense to use device memory for
> > that range. So they are mult
Got it, thanks.
On Wed, 30 Jan 2019 at 06:55, Gustavo A. R. Silva
wrote:
>
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
>
> This patch fixes the following warning:
>
> drivers/gpu/drm/nouveau/nouveau_bo.c:1434:53: warning: this s
On Wed, Jan 23, 2019 at 11:54 PM Maxime Ripard
wrote:
>
> The current calculation for the video start delay in the current DSI driver
> is that it is the total vertical size, minus the backporch and sync length,
> plus 1.
>
> However, the Allwinner code has it as the active vertical size, plus the
On 28/01/2019 19:22, Daniel Vetter wrote:
> Compared to the RFC[1] no changes to the patch itself, but igt moved
> forward a lot:
>
> - gitlab CI builds with: reduced configs/libraries, arm cross build
> and a sysroot build (should address all the build/cross platform
> concerns raised in the
On Wed, Jan 30, 2019 at 12:14:46AM +0100, Daniel Vetter wrote:
> On Tue, Jan 29, 2019 at 8:27 PM Greg KH wrote:
> > On Tue, Jan 29, 2019 at 07:10:55PM +0100, Daniel Vetter wrote:
> > > The problem is when drivers use devm_ not to allocate hw resources and
> > > related things, but structures for o
Hello Ville,
On 1/29/2019 9:33 PM, Ville Syrjälä wrote:
On Tue, Jan 29, 2019 at 03:57:29PM +, Shankar, Uma wrote:
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Ville Syrjälä
Sent: Tuesday, January 29, 2019 9:14 PM
To: Shankar, U
101 - 181 of 181 matches
Mail list logo
