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
> > > >
>
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
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,
--
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
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
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
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
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
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,
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,
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=108585
--- Comment #14 from Alex Deucher ---
Created attachment 142303
--> https://bugs.freedesktop.org/attachment.cgi?id=142303=edit
possible fix
(In reply to Benjamin Herrenschmidt from comment #12)
> We have no control on what firmware is loaded
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
> > ---
> >
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).
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
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
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
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 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
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 +
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
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
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 +--
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 |
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
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
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
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
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
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
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
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 |
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,
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" >
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.
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
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 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
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
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
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:
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.
> >
> >
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
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=108608
--- Comment #3 from abortretryf...@gmail.com ---
Created attachment 142312
--> https://bugs.freedesktop.org/attachment.cgi?id=142312=edit
Full dmesg output after crash
--
You are receiving this mail because:
You are the assignee for the
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 #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:
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
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
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=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)
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 ++--
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
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?
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
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"
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
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
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
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
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
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.
>
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
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
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
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=104602
--- Comment #16 from Timothy Arceri ---
Created attachment 142314
--> https://bugs.freedesktop.org/attachment.cgi?id=142314=edit
Renderdoc capture
Also attaching a renderdoc capture of the issue.
--
You are receiving this mail because:
You
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
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
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
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
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
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=edit
Hack around issue
I've found the source of the problem. It seems that the tgsi indirect indexing
optimisation is
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=edit
possible fix
Does this patch fix the issue?
--
You are receiving this mail because:
You are the assignee for the
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
https://bugs.freedesktop.org/show_bug.cgi?id=108194
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #2 from Timothy
https://bugs.freedesktop.org/show_bug.cgi?id=108096
Dieter Nützel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
>
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=108585
--- Comment #15 from Alex Deucher ---
Created attachment 142316
--> https://bugs.freedesktop.org/attachment.cgi?id=142316=edit
more involved fix
These patches attempt to reset the GPU on init if the GPU was already running
from a previous
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
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.
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
https://bugs.freedesktop.org/show_bug.cgi?id=108486
Petri Latvala changed:
What|Removed |Added
Status|VERIFIED|CLOSED
--
You are receiving this mail
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
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #15 from Timur Kristóf ---
(In reply to Alex Deucher from comment #14)
> I suspect the display may require additional voltage in your case which is
> why you see the issue at 4k. The display requirements are not handled as
> finely
On Mon, Oct 08, 2018 at 06:06:19PM +, Leonard Crestez wrote:
> The DISPLAY power domain on imx6sx has 7 clocks.
>
> Signed-off-by: Leonard Crestez
Applied, thanks.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
There is no good reason to not define ARCH_HAS_SG_CHAIN. To fix
your immediate problem just select it from riscv, as riscv uses
the generic dma-direct code which is chained S/G safe by definition.
And if you want to get extra points do a quick audit of the remaning
iommu drivers on architectures
On Mon, Oct 08, 2018 at 06:06:23PM +, Leonard Crestez wrote:
> This was implemented in the driver but not actually defined and
> referenced in dts. This makes it always on.
>
> From reference manual in section "10.4.1.4.1 Power Distribution":
>
> "Display domain - The DISPLAY domain contains
Hi,
On 2018-10-26 12:40, Andrzej Hajda wrote:
> DSI device can be attached after DRM device is registered. In such
> case newly created connector must be registered by exynos_dsi.
> The patch fixes exynos_drm on rinato and trats boards.
>
> Fixes: 6afb7721e2a0 ("drm/exynos: move connector
https://bugs.freedesktop.org/show_bug.cgi?id=108607
Christian König changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
>
> Acked-by: Sean Paul
>
Reviewed-by: Haneen Mohammed
> > ---
> >
From: "Y.C. Chen"
v1: over-sample data to increase the stability with some specific monitors
v2: refine to avoid infinite loop
Signed-off-by: Y.C. Chen
---
drivers/gpu/drm/ast/ast_mode.c | 34 --
1 file changed, 28 insertions(+), 6 deletions(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=108585
Christian König changed:
What|Removed |Added
CC||joel.s...@gmail.com
--- Comment #10
https://bugs.freedesktop.org/show_bug.cgi?id=108607
Christian König changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--
You are receiving this
https://bugs.freedesktop.org/show_bug.cgi?id=108585
--- Comment #11 from Dan Horák ---
Thanks for the info, I've documented that in the Talos wiki under
https://wiki.raptorcs.com/wiki/Troubleshooting/GPU#AMDGPU_driver_crashes_after_firmware_update
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=108609
Bug ID: 108609
Summary: vegam_smumgr.c: accessing mvdd_voltage_table.entries[]
array out of bounds in function
vegam_populate_smc_mvdd_table
Product: DRI
1 - 100 of 121 matches
Mail list logo
