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
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
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 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
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 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
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
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
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
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
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
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 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
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
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
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
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 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 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 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 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: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 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: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
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 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
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 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 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 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 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 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 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 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 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,
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: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
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 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
> > +
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
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
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
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
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
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
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
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
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
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
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 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
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
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
> > >
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 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 #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._
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
Bug ID: 109499
Summary: amdgpu 4k modes not working
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: norm
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
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
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
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
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
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
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
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 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
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.__
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.__
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 #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
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
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: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=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@
>-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;
On Tue, Jan 29, 2019 at 02:37:23PM +0100, Heiko Stübner wrote:
> Hi Thierry,
>
> Am Dienstag, 13. November 2018, 13:42:05 CET schrieb Heiko Stuebner:
> > From: Heiko Stuebner
> >
> > This is a panel handled through the generic lvds-panel binding,
> > so only needs its additional compatible speci
From: Sean Paul
Changes in v2:
- Add drm_display_mode.vrefresh removal (Ville)
- Add Sam's R-b and bonus points
Cc: Ville Syrjälä
Suggested-by: Daniel Vetter
Reviewed-by: Sam Ravnborg
Bonus-points-awarded-by: Sam Ravnborg
Signed-off-by: Sean Paul
---
Documentation/gpu/todo.rst | 18 +++
On Tue, Jan 29, 2019 at 10:55:47AM -0500, Sean Paul wrote:
> On Mon, Jan 28, 2019 at 02:58:53PM -0800, Chandan Uddaraju wrote:
> > This change adds definitions needed for DP audio compliance testing.
> > It also adds missing definition for DP video compliance.
> >
> > Changes in V2:
> > -- Delete
On Tue, Jan 29, 2019 at 04:20:39PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> >Sent: Tuesday, January 29, 2019 9:34 PM
> >To: Shankar, Uma
> >Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala,
On Tue, Jan 29, 2019 at 11:15:51AM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Sean Paul
> ---
> Documentation/gpu/todo.rst | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/t
https://bugs.freedesktop.org/show_bug.cgi?id=109487
--- Comment #6 from asavah ---
Yes, indeed reverting
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-next-5.1-wip&id=10117450735c7a7c0858095fb46a860e7037cb9a
seems to fix the issue.
--
You are receiving this mail because:
You are the a
On Tue, Jan 29, 2019 at 11:15:51AM -0500, Sean Paul wrote:
> From: Sean Paul
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Sean Paul
Reviewed-by: Sam Ravnborg
> ---
> Documentation/gpu/todo.rst | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a/Documentation/gpu/to
>-Original Message-
>From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
>Sent: Tuesday, January 29, 2019 9:34 PM
>To: Shankar, Uma
>Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-devel@lists.freedesktop.org
>Subject: Re:
On Tue, Jan 29, 2019 at 04:20:00PM +0200, Joonas Lahtinen wrote:
> Quoting Jerome Glisse (2019-01-24 17:30:32)
> > On Thu, Jan 24, 2019 at 02:09:12PM +0200, Joonas Lahtinen wrote:
> > > Hi Jerome,
> > >
> > > This patch seems to have plenty of Cc:s, but none of the right ones :)
> >
> > So sorry,
https://bugs.freedesktop.org/show_bug.cgi?id=108889
--- Comment #4 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- SKL ICL: igt@sw_sync@sync_busy_fork* - incomplete - __igt_fork_helper:
Assertion `!proc->running' failed. -}
{+ HSW SKL ICL: igt@sw_sync@sync_bus
From: Sean Paul
Suggested-by: Daniel Vetter
Signed-off-by: Sean Paul
---
Documentation/gpu/todo.rst | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 38360ede12215..7fc30380eaf6c 100644
--- a/Documentation/gpu/tod
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, Uma
> >Cc: emil.l.veli...@gmail.com; intel-
>-Original Message-
>From: Daniel Stone [mailto:dan...@fooishbar.org]
>Sent: Tuesday, January 29, 2019 9:24 PM
>To: Brian Starkey
>Cc: Shankar, Uma ; Syrjala, Ville
>; intel-...@lists.freedesktop.org; dri-
>de...@lists.freedesktop.org; nd ; Lankhorst, Maarten
>
>Subject: Re: [Intel-gfx]
Hi,
On Wed, 2019-01-23 at 16:54 +0100, 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, plu
>-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, Uma
>Cc: emil.l.veli...@gmail.com; intel-...@lists.freedesktop.org; Syrjala, Ville
>; Lankhorst, Maarten ;
>dri-devel@l
On Mon, Jan 28, 2019 at 02:58:53PM -0800, Chandan Uddaraju wrote:
> This change adds definitions needed for DP audio compliance testing.
> It also adds missing definition for DP video compliance.
>
> Changes in V2:
> -- Delete cover letter for this patch.
> -- Move the description from cover lette
Hi,
On Tue, 29 Jan 2019 at 15:24, Brian Starkey wrote:
> On Tue, Jan 29, 2019 at 01:30:43PM +, Shankar, Uma wrote:
> > >> +#define DP_COLORIMETRY_SCRGB 15
> > >> +#define DP_COLORIMETRY_DCI_P3 16
> > >> +#define DP_COLORIMETRY_CUSTOM_COLOR_PROFILE 17
>
> Sorry,
On Tue, Jan 29, 2019 at 09:59:40AM +0100, Daniel Vetter wrote:
> On Mon, Jan 28, 2019 at 03:42:48PM -0500, Sean Paul wrote:
> > From: Sean Paul
> >
> > Use the drm_mode_vrefresh helper where we need refresh rate in case
> > vrefresh is empty.
> >
> > Signed-off-by: Sean Paul
>
> I think adding
Hi,
On Wed, 2019-01-23 at 16:54 +0100, Maxime Ripard wrote:
> The current code allows the TCON clock divider to have a range between 4
> and 127 when feeding the DSI controller.
>
> The only display supported so far had a display clock rate that ended up
> using a divider of 4, but testing with o
1 - 100 of 181 matches
Mail list logo
