https://bugs.freedesktop.org/show_bug.cgi?id=108194
--- Comment #3 from Timothy Arceri ---
It's also possible this is another example of bug #104602
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dr
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #17 from Timothy Arceri ---
After talking this over with Marek here is a summary of the problem.
LLVM's VGPR indexing code on gfx9+ is broken for immediate arrays. Usually this
is not a problem as GLSL IR in mesa will lower these to
On Wed, 31 Oct 2018, Shayenne Moura wrote:
> On 10/31, Julia Lawall wrote:
> >
> >
> > On Wed, 31 Oct 2018, Shayenne Moura wrote:
> >
> > > On 10/31, Julia Lawall wrote:
> > > >
> > > >
> > > > On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote:
> > > >
> > > > > Rename 'drm_mode_config.crtc_idr'
https://bugs.freedesktop.org/show_bug.cgi?id=108086
--- Comment #6 from jeckfer...@gmail.com ---
Created attachment 142317
--> https://bugs.freedesktop.org/attachment.cgi?id=142317&action=edit
It occurred again with 18.2.3
--
You are receiving this mail because:
You are the assignee for the bu
https://bugs.freedesktop.org/show_bug.cgi?id=108585
--- Comment #15 from Alex Deucher ---
Created attachment 142316
--> https://bugs.freedesktop.org/attachment.cgi?id=142316&action=edit
more involved fix
These patches attempt to reset the GPU on init if the GPU was already running
from a previ
https://bugs.freedesktop.org/show_bug.cgi?id=108606
--- Comment #12 from Alex Deucher ---
(In reply to Samantha McVey from comment #11)
> I am testing with amdgpu.ppfeaturemask=0xfffdbfff right now. I still have
> that commit reverted, is this test still valid? What I mean is I have
> amdgpu.ppfe
This patch is needed to help implement half-float texturing and
rendering for the vc4 driver in mesa. This small patch introduces the
cpp value for the RGBA64 texture. A future patch will include updates to
vc4_render_cl.c to handle HDR color stores.
---
drivers/gpu/drm/vc4/vc4_validate.c | 4 +++-
https://bugs.freedesktop.org/show_bug.cgi?id=108272
--- Comment #11 from jamespharve...@gmail.com ---
When I originally filed this, I assumed it was 1 bug since I tried 2 things
with OpenCL, and both failed with opencl-mesa but worked with opencl-amd.
Jan Vesely was correct that there were two se
https://bugs.freedesktop.org/show_bug.cgi?id=108606
--- Comment #11 from Samantha McVey ---
I am testing with amdgpu.ppfeaturemask=0xfffdbfff right now. I still have that
commit reverted, is this test still valid? What I mean is I have
amdgpu.ppfeaturemask=0xfffdbfff in my cmdline at the same tim
https://bugs.freedesktop.org/show_bug.cgi?id=108608
--- Comment #4 from Alex Deucher ---
I think this patch should fix at least some of the issues:
https://patchwork.freedesktop.org/patch/259364/
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=108606
--- Comment #10 from Alex Deucher ---
Can you determine whether it's stutter or gfxoff that causes the problem?
Please try booting with amdgpu.ppfeaturemask=0xfffdbfff or
amdgpu.ppfeaturemask=0x3fff on the kernel command line in grub and se
https://bugs.freedesktop.org/show_bug.cgi?id=108606
--- Comment #9 from Alex Deucher ---
Created attachment 142315
--> https://bugs.freedesktop.org/attachment.cgi?id=142315&action=edit
possible fix
Does this patch fix the issue?
--
You are receiving this mail because:
You are the assignee fo
https://bugs.freedesktop.org/show_bug.cgi?id=108609
--- Comment #3 from Alex Deucher ---
Ideally against one of these branches:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next
https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-4.21-wip
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=108096
Dieter Nützel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Oct 31, 2018 at 4:05 PM Grodzovsky, Andrey
wrote:
>
>
>
> On 10/31/2018 03:49 PM, Alex Deucher wrote:
> > On Wed, Oct 31, 2018 at 2:33 PM Andrey Grodzovsky
> > wrote:
> >> Illegal access will cause CP hang followed by job timeout and
> >> recovery kicking in.
> >> Also, disable the suite
https://bugs.freedesktop.org/show_bug.cgi?id=108096
--- Comment #24 from Dieter Nützel ---
(In reply to Andrey Grodzovsky from comment #22)
> (In reply to Andrey Grodzovsky from comment #21)
> > Please load the driver in debug mode so I can see the error code value in
> > dmesg -
> > when loadin
https://bugs.freedesktop.org/show_bug.cgi?id=108096
--- Comment #23 from Dieter Nützel ---
(In reply to Samuel Pitoiset from comment #20)
> Make sure to load the right version of libdrm (ie. 2.4.93 or more recent). I
> had this problem today because I was loading and old version of libdrm.
> Some
https://bugs.freedesktop.org/show_bug.cgi?id=108194
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #2 from Timothy A
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #16 from Timothy Arceri ---
Created attachment 142314
--> https://bugs.freedesktop.org/attachment.cgi?id=142314&action=edit
Renderdoc capture
Also attaching a renderdoc capture of the issue.
--
You are receiving this mail becaus
https://bugs.freedesktop.org/show_bug.cgi?id=104602
--- Comment #15 from Timothy Arceri ---
Created attachment 142313
--> https://bugs.freedesktop.org/attachment.cgi?id=142313&action=edit
Hack around issue
I've found the source of the problem. It seems that the tgsi indirect indexing
optimisat
msm maintains a separate structure to define vblank
work definitions and a list to track events submitted
to the display worker thread. We can avoid these
redundant list and its protection mechanism, if we
subclass the work object to encapsulate vblank
event parameters.
Signed-off-by: Jeykumar San
DPU was using one thread per display to dispatch async
commits and vblank requests. Since clean up already happened
in msm to use the common thread for all the display commits,
display threads are only used to cater vblank requests. Single
thread is sufficient to do the job without any performance
Den 17.10.2018 15.04, skrev Noralf Trønnes:
This adds an optional function table on GEM objects.
The main benefit is for drivers that support more than one type of
memory (shmem,vram,cma) for their buffers depending on the hardware it
runs on. With the callbacks attached to the GEM object itself
Pushed first 7 patches of this series, thanks for the reviews.
Manasi
On Wed, Oct 24, 2018 at 03:28:12PM -0700, Manasi Navare wrote:
> VESA has developed an industry standard Display Stream Compression(DSC)
> for interoperable, visually lossless compression over display links to
> address the nee
Hi Shayenne,
Welcome to DRM.
As far as I can see you're a newcomer to kernel development, so I'd
recommend watch a recent talk from Marc [1]
He provides a very good introduction, both for newbies and for people
willing the know the deeper reasons behind.
That said, here's some suggestions:
On W
On 10/31, Julia Lawall wrote:
>
>
> On Wed, 31 Oct 2018, Shayenne Moura wrote:
>
> > On 10/31, Julia Lawall wrote:
> > >
> > >
> > > On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote:
> > >
> > > > Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr',
> > > > as proposed in the task
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #30 from bmil...@gmail.com ---
https://github.com/yshui/compton/issues/25 - related to this issue
Some tests me and others did in compton shows there is some relation with vsync
issues and the HW cursor. When I turn swcursor on in xo
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #38 from bmil...@gmail.com ---
(In reply to Alex Deucher from comment #36)
> *** Bug 105300 has been marked as a duplicate of this bug. ***
https://bugs.freedesktop.org/show_bug.cgi?id=108322 - Also related.
When I tested 4.18 kern
https://bugs.freedesktop.org/show_bug.cgi?id=108609
--- Comment #2 from Robert Strube ---
What repo and branch do you want the patch made against? Does AMD have it's
own repo for the linux kernel, or should I go against:
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master branch?
https://bugs.freedesktop.org/show_bug.cgi?id=108608
--- Comment #3 from abortretryf...@gmail.com ---
Created attachment 142312
--> https://bugs.freedesktop.org/attachment.cgi?id=142312&action=edit
Full dmesg output after crash
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #37 from bmil...@gmail.com ---
(In reply to Alex Deucher from comment #35)
> (In reply to bmilreu from comment #34)
> > The flickering issues I have with 75hz are gone after forcing profile to
> > high.
>
> The disables mclk switchin
https://bugs.freedesktop.org/show_bug.cgi?id=108608
--- Comment #2 from abortretryf...@gmail.com ---
Sure. I'll see if I can turn off all this 'audit' nonsense that's filling dmesg
with the names of files and users on my PC that I don't want all over the
internet.
Haven't built a kernel from sour
On Wed, 31 Oct 2018, Shayenne Moura wrote:
> On 10/31, Julia Lawall wrote:
> >
> >
> > On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote:
> >
> > > Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr',
> > > as proposed in the task description in TODO list for KMS cleanups.
> >
> > I
On 10/31, Julia Lawall wrote:
>
>
> On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote:
>
> > Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr',
> > as proposed in the task description in TODO list for KMS cleanups.
>
> Is object_idr a field that already exists? If so, "Rename" i
On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote:
> Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr',
> as proposed in the task description in TODO list for KMS cleanups.
Is object_idr a field that already exists? If so, "Rename" is not the
best choice of words. It should be
Rename 'drm_mode_config.crtc_idr' as 'drm_mode_config.object_idr',
as proposed in the task description in TODO list for KMS cleanups.
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/drm_lease.c | 6 +++---
drivers/gpu/drm/drm_mode_config.c | 4 ++--
drivers/gpu/drm/drm_mode_object
Hi Dave,
A few patches to round out the merge window. 6/7 are from one series fixing up
things around bridge/panel.
drm-misc-next-fixes-2018-10-31:
- Properly label Innolux TV123WAM as P120ZDG-BF1 (Doug)
- Add optional delay for panels without hpd hooked up (which solves the
mystery delay for
https://bugs.freedesktop.org/show_bug.cgi?id=108323
--- Comment #4 from bmil...@gmail.com ---
Bug also triggers using the new sysfs API's fan1_target+fan1_enable on latest
drm-next-4.21-wip
--
You are receiving this mail because:
You are the assignee for the bug._
On 10/31/2018 03:49 PM, Alex Deucher wrote:
> On Wed, Oct 31, 2018 at 2:33 PM Andrey Grodzovsky
> wrote:
>> Illegal access will cause CP hang followed by job timeout and
>> recovery kicking in.
>> Also, disable the suite for all APU ASICs until GPU
>> reset issues for them will be resolved and G
On 10/31/2018 03:49 PM, Alex Deucher wrote:
> On Wed, Oct 31, 2018 at 2:33 PM Andrey Grodzovsky
> wrote:
>> Illegal access will cause CP hang followed by job timeout and
>> recovery kicking in.
>> Also, disable the suite for all APU ASICs until GPU
>> reset issues for them will be resolved and G
https://bugs.freedesktop.org/show_bug.cgi?id=108613
Bug ID: 108613
Summary: amdgpu.dc=1 + xf86-video-amdgpu: changing to a GPU
upscaling resolution resets pp_dpm_mclk
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=108606
--- Comment #8 from Samantha McVey ---
On the newest firmware, the issue is present, yes.
Output of /sys/kernel/debug/dri/0/amdgpu_firmware_info
VCE feature version: 0, firmware version: 0x
UVD feature version: 0, firmware version: 0x0
https://bugs.freedesktop.org/show_bug.cgi?id=108606
--- Comment #7 from Alex Deucher ---
(In reply to Samantha McVey from comment #6)
> Yeah I have the latest linux-firmware installed. I also have raven_dmcu.bin
> which just was added so I'm certain I have the latest, since I installed the
> git
On Wed, Oct 31, 2018 at 2:33 PM Andrey Grodzovsky
wrote:
>
> Illegal access will cause CP hang followed by job timeout and
> recovery kicking in.
> Also, disable the suite for all APU ASICs until GPU
> reset issues for them will be resolved and GPU reset recovery
> will be enabled by default.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=108606
--- Comment #6 from Samantha McVey ---
Yeah I have the latest linux-firmware installed. I also have raven_dmcu.bin
which just was added so I'm certain I have the latest, since I installed the
git version 3 days ago (when I read that Raven Ridge
https://bugs.freedesktop.org/show_bug.cgi?id=105300
Alex Deucher changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=102646
Alex Deucher changed:
What|Removed |Added
CC||tempel.jul...@gmail.com
--- Comment #36
https://bugs.freedesktop.org/show_bug.cgi?id=108606
--- Comment #5 from Alex Deucher ---
Does the latest firmware from
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
fix the issue as well?
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108272
--- Comment #10 from Juan A. Suarez ---
Mesa 18.2.4 has been released. Could you check if that version fixes this bug?
If so, please, close it.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=105300
--- Comment #15 from tempel.jul...@gmail.com ---
Issue still exists with current 4.21-wip kernel.
As a workaround, it's enough to force the highest VRAM clock state (Forcing
higher clocks on the GPU itself is not necessary.):
echo "manual" > /s
On 2018-10-21 9:27 p.m., Rodrigo Siqueira wrote:
> Add maintainers and reviewers for VKMS driver
>
> Signed-off-by: Rodrigo Siqueira
Acked-by: Harry Wentland
Harry
> ---
> Changes in v2:
> - Insert the section in alphabetical order
>
> MAINTAINERS | 10 ++
> 1 file changed, 10 ins
On Wed, Oct 31, 2018 at 7:31 AM Bartlomiej Zolnierkiewicz
wrote:
>
> Please pull fbdev changes for v4.20. No major changes to the subsystem
> itself, mainly fb drivers fixes & cleanups (atyfb & udlfb updates stand
> out from the rest) + removal of no longer needed old clps711xfb driver.
Pulled,
Den 29.10.2018 10.07, skrev Daniel Vetter:
On Sun, Oct 28, 2018 at 09:46:43PM +0100, Noralf Trønnes wrote:
Den 28.10.2018 21.21, skrev David Lechner:
On 10/26/2018 05:38 PM, Noralf Trønnes wrote:
Den 17.10.2018 15.04, skrev Noralf Trønnes:
This move makes tinydrm useful for more drivers. tin
Illegal access will cause CP hang followed by job timeout and
recovery kicking in.
Also, disable the suite for all APU ASICs until GPU
reset issues for them will be resolved and GPU reset recovery
will be enabled by default.
Signed-off-by: Andrey Grodzovsky
---
tests/amdgpu/deadlock_tests.c | 11
On 10/31/18 12:20 PM, Michel Dänzer wrote:
> On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote:
>> On 10/31/18 10:12 AM, Michel Dänzer wrote:
>>> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote:
On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote:
>
> I understand the issue you're d
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.21-wip
head: 6830ffcb15a5bae3f031734b75b11a5f489a52bf
commit: 6459eb8ee95150ffbdfcd0c9325945be80f98cf8 [113/125] drm/amd/display:
Expand dc to use 16.16 bit backlight
smatch warnings:
drivers/gpu/drm/amd/amdgpu/../display/dc/dce/d
Break line after NULL to decrease the line size.
Signed-off-by: Shayenne da Luz Moura
---
Changes in v2:
- Remove aditional variable added in v1 and add a line break
drivers/gpu/drm/drm_mode_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mo
On 10/31, Daniel Vetter wrote:
> On Wed, Oct 31, 2018 at 4:13 PM Jani Nikula
> wrote:
> >
> > On Wed, 31 Oct 2018, Shayenne da Luz Moura
> > wrote:
> > > Add a new variable to make the drm_mode_object comparison before
> > > idr_alloc and decrease line size.
> > >
> > > Signed-off-by: Shayenne
Split the operation of msm_gem_get_iova into two operations:
1) allocate an iova and 2) map (pin) the backing memory int the
iommu. This is the first step toward allowing memory pinning
to occur independently of the iova management.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.h
Add a new function to get and pin the iova memory in one
step (basically renaming the old msm_gem_get_iova function)
and switch msm_gem_get_iova() to only allocate an iova but
not map it in the IOMMU. This is only currently used by
msm_ioctl_gem_info() since all other users of of the iova
expect th
Add a reference count to track how many times a particular
chunk of iova memory is pinned (mapped) in the iomu and
add msm_gem_unpin_iova to give up references.
It is important to note that msm_gem_unpin_iova replaces
msm_gem_put_iova because the new implicit behavior
that an assigned iova in a gi
Add headers for the 'gem' debugfs file to make it easier to remember
what all the values mean and move the list of virtual address regions
to the next line and add the name and map status to make it clearer
what we are looking at.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gem.c |
Buffer objects allocated with msm_gem_kernel_new() are mostly
freed the same way so we can save a few lines of code with a
common function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 13 ++---
drivers/gpu/drm/msm/adreno/a5xx_power.c | 13 +
The scatter gather table doesn't need to be passed in for the
MMU unmap function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.h | 2 +-
drivers/gpu/drm/msm/msm_gem.c | 2 +-
drivers/gpu/drm/msm/msm_gem_vma.c | 4 ++--
drivers/gpu/drm/msm/msm_iommu.c | 3 +--
drivers/gp
Currently in the msm driver iova addresses are mapped in the IOMMU at
allocation time and stay there for the life of the buffer. This may not
be desirable for long lived user space buffers that could be temporarily
swapped or moved.
This first set of patches breaks up the allocation and mapping in
Den 25.10.2018 18.29, skrev Eric Anholt:
Eric Anholt writes:
I was going to start working on making the vc4 driver work with
tinydrm panels, but it turned out tinydrm didn't have the panel I had
previously bought. So, last night I ported the fbtft staging
driver over to DRM.
It seems to wor
Hi Laurent,
Tomi is busy with other things so I have taken over applying these
comments. The rest is more or less clear, or commented by Tomi, but this
is something have not addressed:
On 30/07/18 17:12, Laurent Pinchart wrote:
>> +static void tidss_crtc_atomic_flush(struct drm_crtc *crtc,
>> +
On 2018-10-31 3:41 p.m., Kazlauskas, Nicholas wrote:
> On 10/31/18 10:12 AM, Michel Dänzer wrote:
>> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote:
>>> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote:
I understand the issue you're describing now. The timestamp is supposed
to s
On Wed, Oct 31, 2018 at 09:05:05AM -0700, Manasi Navare wrote:
> On Wed, Oct 31, 2018 at 03:10:15PM +0200, Ville Syrjälä wrote:
> > On Tue, Oct 30, 2018 at 04:53:49PM -0700, Manasi Navare wrote:
> > > On Wed, Oct 24, 2018 at 03:28:24PM -0700, Manasi Navare wrote:
> > > > Basic DSC parameters and DS
Hi Fabrizio,
thanks for your patch!
On Wed, Oct 31, 2018 at 1:58 PM Fabrizio Castro
wrote:
> While adding SiI9022A support to the iwg23s board it came up
> that when the HDMI transmitter is in pass through mode the
> device is not compliant with the I2C specification anymore,
> as it requires a
On Wed, Oct 31, 2018 at 03:10:15PM +0200, Ville Syrjälä wrote:
> On Tue, Oct 30, 2018 at 04:53:49PM -0700, Manasi Navare wrote:
> > On Wed, Oct 24, 2018 at 03:28:24PM -0700, Manasi Navare wrote:
> > > Basic DSC parameters and DSC configuration data needs to be computed
> > > for each of the request
https://bugs.freedesktop.org/show_bug.cgi?id=108608
--- Comment #1 from Alex Deucher ---
Please attach your full dmesg output. Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-dev
https://bugs.freedesktop.org/show_bug.cgi?id=99923
--- Comment #42 from Martin Pilarski ---
With the fix commited in LLVM trunk/master (and obviously working), I guess
this bug can be closed?
I'd like to know if it can be backported, too. LLVM 8 is quite some time away
and, depending on the dist
On Wed, Oct 31, 2018 at 4:13 PM Jani Nikula wrote:
>
> On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote:
> > Add a new variable to make the drm_mode_object comparison before
> > idr_alloc and decrease line size.
> >
> > Signed-off-by: Shayenne da Luz Moura
> > ---
> > drivers/gpu/drm/drm_mode_o
https://bugs.freedesktop.org/show_bug.cgi?id=108585
--- Comment #14 from Alex Deucher ---
Created attachment 142303
--> https://bugs.freedesktop.org/attachment.cgi?id=142303&action=edit
possible fix
(In reply to Benjamin Herrenschmidt from comment #12)
> We have no control on what firmware is
On Wed, 31 Oct 2018, Shayenne da Luz Moura wrote:
> Add a new variable to make the drm_mode_object comparison before
> idr_alloc and decrease line size.
>
> Signed-off-by: Shayenne da Luz Moura
> ---
> drivers/gpu/drm/drm_mode_object.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
https://bugs.freedesktop.org/show_bug.cgi?id=107947
--- Comment #7 from Alex Smith ---
This is occurring for me on a Vega 64. When it occurs the machine boots to a
black screen. It has started happening since upgrading to Fedora 27's 4.18.16,
previously I was on 4.18.7 (does not happen there). I'
Add a new variable to make the drm_mode_object comparison before
idr_alloc and decrease line size.
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/drm_mode_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_mode_object.c
b/drivers/gpu/drm
On 10/31/18 10:12 AM, Michel Dänzer wrote:
> On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote:
>> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote:
>>> On 10/30/18 5:29 AM, Michel Dänzer wrote:
On 2018-10-29 7:03 p.m., Ville Syrjälä wrote:
> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Mic
Hi Linus,
Please pull fbdev changes for v4.20. No major changes to the subsystem
itself, mainly fb drivers fixes & cleanups (atyfb & udlfb updates stand
out from the rest) + removal of no longer needed old clps711xfb driver.
Please see the signed tag description for details.
Best regards,
--
Bar
On 2018-10-31 2:38 p.m., Kazlauskas, Nicholas wrote:
> On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote:
>> On 10/30/18 5:29 AM, Michel Dänzer wrote:
>>> On 2018-10-29 7:03 p.m., Ville Syrjälä wrote:
On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
> On 2018-10-26 7:59 p.m.,
On 10/30/18 11:34 AM, Kazlauskas, Nicholas wrote:
> On 10/30/18 5:29 AM, Michel Dänzer wrote:
>> On 2018-10-29 7:03 p.m., Ville Syrjälä wrote:
>>> On Mon, Oct 29, 2018 at 05:37:49PM +0100, Michel Dänzer wrote:
On 2018-10-26 7:59 p.m., Ville Syrjälä wrote:
> On Fri, Oct 26, 2018 at 05:34:15
On Tue, Oct 30, 2018 at 04:53:49PM -0700, Manasi Navare wrote:
> On Wed, Oct 24, 2018 at 03:28:24PM -0700, Manasi Navare wrote:
> > Basic DSC parameters and DSC configuration data needs to be computed
> > for each of the requested mode during atomic check. This is
> > required since for certain mod
On Tue, Oct 30, 2018 at 04:45:35PM -0700, Manasi Navare wrote:
> On Thu, Oct 25, 2018 at 05:09:42PM +0300, Ville Syrjälä wrote:
> > On Wed, Oct 24, 2018 at 03:28:34PM -0700, Manasi Navare wrote:
> > > DSC PPS secondary data packet infoframes are filled with
> > > DSC picure parameter set metadata a
Hi Tony,
On Saturday, 20 October 2018 03:38:12 EET Tony Lindgren wrote:
> * Sebastian Reichel [181019 15:58]:
> > I uploaded my current status here. It's not based on the newest
> > -next, but contains the interesting patches from Laurent. Also
> > the last few patches are not yet cleaned up, sor
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #39 from Allan ---
I can't clone the git repo using command :
"git clone git://people.freedesktop.org/~agd5f/linux"
Firstly it was checksum errors, found that the processor had a bug, replaced it
through warranty process, and now I
drivers/gpu/drm/drm_syncobj.c:181:6: warning: no previous prototype for
‘drm_syncobj_add_callback’ [-Wmissing-prototypes]
drivers/gpu/drm/drm_syncobj.c:190:6: warning: no previous prototype for
‘drm_syncobj_remove_callback’ [-Wmissing-prototypes]
Fixing that leads to
drivers/gpu/drm/drm_syncobj
https://bugs.freedesktop.org/show_bug.cgi?id=108486
Petri Latvala changed:
What|Removed |Added
Status|VERIFIED|CLOSED
--
You are receiving this mail
This patch adds a 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
colorspaces. Als
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 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 10/31, Daniel Vetter wrote:
> On Wed, Oct 31, 2018 at 02:12:27AM +0300, Haneen Mohammed wrote:
> > On Mon, Oct 22, 2018 at 08:31:42AM -0400, Sean Paul wrote:
> > > On Sun, Oct 21, 2018 at 10:27:01PM -0300, Rodrigo Siqueira wrote:
> > > > Add maintainers and reviewers for VKMS driver
> > > >
> >
https://bugs.freedesktop.org/show_bug.cgi?id=108585
--- Comment #13 from Christian König ---
(In reply to Benjamin Herrenschmidt from comment #12)
> We'll probably need to add something to the amdgpu shutdown() path to force
> an adapter reset.
If that would be possible we would have already don
https://bugs.freedesktop.org/show_bug.cgi?id=108542
--- Comment #8 from davide26...@gmail.com ---
(In reply to Nicholas Kazlauskas from comment #7)
> Created attachment 142278 [details] [review]
> 0001-Fix-unsigned-short-unsigned-long-mixup-for-usSymCloc.patch
>
> Does applying this patch help?
>
On Wed, Oct 31, 2018 at 02:12:27AM +0300, Haneen Mohammed wrote:
> On Mon, Oct 22, 2018 at 08:31:42AM -0400, Sean Paul wrote:
> > On Sun, Oct 21, 2018 at 10:27:01PM -0300, Rodrigo Siqueira wrote:
> > > Add maintainers and reviewers for VKMS driver
> > >
> > > Signed-off-by: Rodrigo Siqueira
> >
Hi Rob,
On Thu, 25 Oct 2018 at 19:37, Robert Foss wrote:
>
> This series implements fence support for drm/virtio and
> has been tested using qemu, kmscube and the below branches.
>
> Rob Herring solved a reference counting issue and
> suggested a context check for the execbuf ioctl, his
> changes
On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote:
>
> From: Gustavo Padovan
>
> To reflect the (backward compatible) changes in the uabi we are bumping
> the driver's version.
>
> Signed-off-by: Gustavo Padovan
> Signed-off-by: Robert Foss
Not strictly required, but doesn't hurt either.
Reviewe
Hi Rob,
On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote:
>
> From: Gustavo Padovan
>
> On the out-fence side we get fence returned by the submitted draw call
> and attach it to a sync_file and send the sync_file fd to userspace. On
> error -1 is returned to userspace.
>
Can we have both an IN an
Hi Rob,
On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote:
>
> Add a new field called fence_fd that will be used by userspace to send
> in-fences to the kernel and receive out-fences created by the kernel.
>
> This uapi enables virtio to take advantage of explicit synchronization of
> dma-bufs.
>
>
Hi Rob,
On Thu, 25 Oct 2018 at 19:38, Robert Foss wrote:
>
> From: Gustavo Padovan
>
> Refactor fence creation to remove the potential allocation failure from
> the cmd_submit and atomic_commit paths. Now the fence should be allocated
> first and just after we should proceed with the rest of the
1 - 100 of 121 matches
Mail list logo