On Wed, Apr 25, 2018 at 8:42 AM, Thomas Hellstrom wrote:
> Hi,
>
> On 12/07/2017 03:49 PM, Daniel Vetter wrote:
>>
>> We're spotting this very rarely in CI, but have no idea. Let's add
>> more debug info about what's going on here.
>>
>> References: https://bugs.freedesktop.org/show_bug.cgi?id=102
Hi!
On 12/07/2017 03:49 PM, Daniel Vetter wrote:
We're spotting this very rarely in CI, but have no idea. Let's add
more debug info about what's going on here.
References:https://bugs.freedesktop.org/show_bug.cgi?id=102707
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_config.c | 3
On Wed, Apr 25, 2018 at 08:23:15AM +0200, Daniel Vetter wrote:
> For more fun:
>
> https://www.spinics.net/lists/dri-devel/msg173630.html
>
> Yeah, sometimes we want to disable the iommu because the on-gpu
> pagetables are faster ...
I am not on this list, but remote NAK from here. This needs a
Hi,
On 12/07/2017 03:49 PM, Daniel Vetter wrote:
We're spotting this very rarely in CI, but have no idea. Let's add
more debug info about what's going on here.
References: https://bugs.freedesktop.org/show_bug.cgi?id=102707
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_config.c |
On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote:
> > It has a non-coherent transaction mode (which the chipset can opt to
> > not implement and still flush), to make sure the AGP horror show
> > doesn't happen again and GPU folks are happy with PCIe. That's at
> > least my understandin
On Wed, Apr 25, 2018 at 09:07:07AM +0300, Oleksandr Andrushchenko wrote:
> On 04/24/2018 11:35 PM, Dongwon Kim wrote:
> > Had a meeting with Daniel and talked about bringing out generic
> > part of hyper-dmabuf to the userspace, which means we most likely
> > reuse IOCTLs defined in xen-zcopy for o
https://bugs.freedesktop.org/show_bug.cgi?id=106194
--- Comment #1 from ebigge...@gmail.com ---
This happened to me too: the same BUG() with the same stacktrace, on 4.17-rc2.
It was when I was away, so maybe it happened when the screen turned off due to
inactivity. Graphics card is an Radeon RX
On Tue, Apr 24, 2018 at 9:15 AM, Luc Van Oostenryck
wrote:
> The method struct vga_switcheroo_handler::get_client_id() is defined
> as returning an 'enum vga_switcheroo_client_id' but the implementation
> in this driver, amdgpu_atpx_get_client_id(), returns an 'int'.
>
> Fix this by returning 'enu
On 23/04/18 23:09, Mauro Carvalho Chehab wrote:
>> I don't think it's worth it renaming the common symbols. They will change
>> over
>> time as omapdrm is under heavy rework, and it's painful enough without
>> having
>> to handle cross-tree changes.
>
> It could just rename the namespace-conf
On Wed, Apr 25, 2018 at 2:13 AM, Daniel Vetter wrote:
> On Wed, Apr 25, 2018 at 7:48 AM, Christoph Hellwig wrote:
>> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
>>> Out of curiosity, how much virtual flushing stuff is there still out
>>> there? At least in drm we've pretty much
On Wed, Apr 25, 2018 at 8:13 AM, Daniel Vetter wrote:
> On Wed, Apr 25, 2018 at 7:48 AM, Christoph Hellwig wrote:
>> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
>>> Out of curiosity, how much virtual flushing stuff is there still out
>>> there? At least in drm we've pretty much
On Wed, Apr 25, 2018 at 7:48 AM, Christoph Hellwig wrote:
> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
>> Out of curiosity, how much virtual flushing stuff is there still out
>> there? At least in drm we've pretty much ignore this, and seem to be
>> getting away without a huge
On Wed, Apr 25, 2018 at 1:48 AM, Christoph Hellwig wrote:
> On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
>> Out of curiosity, how much virtual flushing stuff is there still out
>> there? At least in drm we've pretty much ignore this, and seem to be
>> getting away without a huge
On 04/24/2018 11:35 PM, Dongwon Kim wrote:
Had a meeting with Daniel and talked about bringing out generic
part of hyper-dmabuf to the userspace, which means we most likely
reuse IOCTLs defined in xen-zcopy for our use-case if we follow
his suggestion.
I will still have kernel side API, so backe
Hi, Vasyl:
Sorry for the late reply.
I've applied this to my branch mediatek-drm-next-4.18
Regards,
CK
On Thu, 2017-11-23 at 17:31 +0800, Philipp Zabel wrote:
> On Tue, 2017-11-21 at 23:31 +0100, Vasyl Gomonovych wrote:
> > Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)).
> >
> >
On Tue, Apr 24, 2018 at 09:32:20PM +0200, Daniel Vetter wrote:
> Out of curiosity, how much virtual flushing stuff is there still out
> there? At least in drm we've pretty much ignore this, and seem to be
> getting away without a huge uproar (at least from driver developers
> and users, core folks
https://bugs.freedesktop.org/show_bug.cgi?id=106229
--- Comment #3 from Luke-Jr ---
It did work with the "radeon" driver on x86, and *mostly* works with "radeon"
on POWER9 as well (except that it limits itself to 32-bit DMA for some reason,
and eventually crashes when I bump up against the alloca
https://bugs.freedesktop.org/show_bug.cgi?id=106229
--- Comment #2 from Luke-Jr ---
Never tried amdgpu on x86.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://
https://bugs.freedesktop.org/show_bug.cgi?id=106229
--- Comment #1 from Alex Deucher ---
Does it work on x86?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://l
Fixes: 61986dd6bef0 ("drm/amdkfd: Copy in KFD-related files")
Signed-off-by: Fengguang Wu
---
amdgpu_amdkfd_fence.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_fence.c
index cf
https://bugs.freedesktop.org/show_bug.cgi?id=106229
Bug ID: 106229
Summary: EEH problem at boot with Radeon HD 7950, in
amdgpu_mm_rreg
Product: DRI
Version: XOrg git
Hardware: PowerPC
OS: Linux (All)
Hi,
On Tue, Apr 24, 2018 at 7:31 AM, Ezequiel Garcia
wrote:
> Hi Doug, Sean:
>
> I would like to move this forward.
>
> On 26 February 2018 at 15:23, Doug Anderson wrote:
>> Hi,
>>
>> On Thu, Feb 8, 2018 at 9:48 AM, Sean Paul wrote:
>>> This patch adds an override mode for kevin devices. The mo
https://bugs.freedesktop.org/show_bug.cgi?id=106228
Bug ID: 106228
Summary: amdgpu reads back brightness 0 (which is not true) if
checked before a brightness has been explicitly set
Product: DRI
Version: unspecified
Hardwar
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.15
head: 9556f93f18f7923978fb90f860c107fed9ca7f57
commit: 54df8c4830456ee6d9f9cb16c281e8bef8780dce [1429/1759] drm/amd/dkms: add
amdkfd module
config: x86_64-federa-25 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-16
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.15
head: 9556f93f18f7923978fb90f860c107fed9ca7f57
commit: 02349fbb559640a1f948df9c84e8f65bd2565d57 [1098/1759] drm/amdkcl: [4.11]
fix debugfs func
coccinelle warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/amd/am
https://bugs.freedesktop.org/show_bug.cgi?id=106191
--- Comment #13 from François Jacques ---
Created attachment 139083
--> https://bugs.freedesktop.org/attachment.cgi?id=139083&action=edit
REAL dmesg output (with debug messages)
Last attachment for tonight. This one its not /var/log/messages
https://bugs.freedesktop.org/show_bug.cgi?id=106191
--- Comment #12 from François Jacques ---
Created attachment 139082
--> https://bugs.freedesktop.org/attachment.cgi?id=139082&action=edit
dmesg (Linux 4.16.3, drm.debug=0x06, audio enabled)
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=106191
--- Comment #11 from François Jacques ---
The bug is caused by having both the audio signal and image simultaneously, it
seems.
After I added "radeon.audio=0" to the kernel argument list and rebooted, the
video interface and the monitor concl
Hi Kieran,
I love your patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.17-rc2 next-20180424]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.15
head: 9556f93f18f7923978fb90f860c107fed9ca7f57
commit: 61986dd6bef0b17e85a9846bb4d1ca610f9d6ce0 [1409/1759] drm/amdkfd: Copy
in KFD-related files
config: i386-randconfig-a1-04241604 (attached as .config)
compiler: gcc-4
Hi Julia,
Thank you for the patch.
On Tuesday, 10 April 2018 08:49:40 EEST Julia Lawall wrote:
> From: Fengguang Wu
>
> PTR_ERR should normally access the value just tested by IS_ERR
>
> Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci
>
> Fixes: 742243a44a73 ("drm: xlnx: pl_disp: Us
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #10 from Mike Bendel ---
I have the same issue. For me amdgpu.dc=0 does not really fix it either. I have
a 3840x1600 monitor running at 75 Hz. This is the different behavior I noticed
when toggling the DC setting:
amdgpu.dc=0
Movin
On Tue, Apr 24, 2018 at 7:31 AM, Ezequiel Garcia
wrote:
> Hi Doug, Sean:
>
> I would like to move this forward.
>
> On 26 February 2018 at 15:23, Doug Anderson wrote:
>> Hi,
>>
>> On Thu, Feb 8, 2018 at 9:48 AM, Sean Paul wrote:
>>> This patch adds an override mode for kevin devices. The mode in
https://bugs.freedesktop.org/show_bug.cgi?id=106225
Bug ID: 106225
Summary: Kernel panic after modesetting (not on every boot) on
ryzen 5 2400g
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS:
On Wed, 2018-04-11 at 18:54 -0400, Lyude Paul wrote:
> While having the modeset_retry_work in intel_connector makes sense with
> SST, this paradigm doesn't make a whole ton of sense when it comes to
> MST since we have to deal with multiple connectors. In most cases, it's
> more useful to just u
Allow userland to specify a syncobj that is waited on before a render job
starts processing.
v2: Use 0 as invalid syncobj to drop flag (Eric)
Drop extra newline (Eric)
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_drv.h | 1 +
drivers/gpu/drm/vc4/vc4_gem.c | 30 +
Allow specifying a syncobj on render job submission where we store the
fence for the job. This gives userland flexible access to the fence.
v2: Use 0 as invalid syncobj to drop flag (Eric)
Don't reintroduce the padding (Eric)
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_gem.c |
v2 drops the extra syncobj parameter and gets rid of the submit flags
since 0 is never a valid syncobj handle.
This series allows userspace to submit syncobj handles for importing
a fence to wait on or exporting the job fence as part of submission.
The primary use of this is to enable native fenc
This doesn't require any additional functionality from the driver but
is a prerequisite to userland calling the syncobj ioctls.
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/dri
On Tue, Apr 24, 2018 at 4:28 PM, Harry Wentland wrote:
>
>
> On 2018-04-24 08:09 AM, Daniel Vetter wrote:
>> On Mon, Apr 23, 2018 at 02:19:44PM -0700, Manasi Navare wrote:
>>> On Mon, Apr 23, 2018 at 10:40:06AM -0400, Harry Wentland wrote:
On 2018-04-20 04:32 PM, Manasi Navare wrote:
> On
On Tue, Apr 24, 2018 at 05:02:40PM -0400, Andrey Grodzovsky wrote:
>
>
> On 04/24/2018 03:44 PM, Daniel Vetter wrote:
> > On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
> > > Adding the dri-devel list, since this is driver independent code.
> > >
> > >
> > > On 2018-04-24 05:30
https://bugs.freedesktop.org/show_bug.cgi?id=103277
--- Comment #23 from dwagner ---
(I should mention that a very long time ago, I also posted a bug report
specifically regarding the EDID-loading feature:
https://bugs.freedesktop.org/show_bug.cgi?id=102202)
--
You are receiving this mail becau
On 04/24/2018 05:21 PM, Eric W. Biederman wrote:
Andrey Grodzovsky writes:
On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
Adding the dri-devel list, since this is driver independent code.
On 2018-04-24 05:30 PM, Andrey Grodzovs
https://bugs.freedesktop.org/show_bug.cgi?id=106159
--- Comment #7 from dwagner ---
I cannot comment on how useful above patches are for the topic of this bug
report, but they are helpful for bug report
https://bugs.freedesktop.org/show_bug.cgi?id=103277
--
You are receiving this mail because:
https://bugs.freedesktop.org/show_bug.cgi?id=103277
dwagner changed:
What|Removed |Added
Status|NEEDINFO|REOPENED
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=106224
Bug ID: 106224
Summary: "Medieval 2 Total War" will sometimes crash system on
a R9 270 card
Product: Mesa
Version: 18.0
Hardware: x86-64 (AMD64)
OS: Linux
https://bugs.freedesktop.org/show_bug.cgi?id=103277
--- Comment #22 from dwagner ---
Two patches posted by Harry Wentland in bug report
https://bugs.freedesktop.org/show_bug.cgi?id=106159
today may hold the key to get finally rid of this long-standing bug:
When I apply
https://bugs.freedesktop.
On Tue, Apr 24, 2018 at 08:29:36PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 24, 2018 at 04:22:42PM +0200, Daniel Vetter wrote:
> > Only used within drm.ko, no need to tempt drivers.
> >
> > Cc: Keith Packard
> > Cc: Ville Syrjala
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Ville Syrjälä
On Fri, Apr 13, 2018 at 6:01 AM Daniel Vetter
wrote:
> This tries to align with the X.org communities's long-standing
> tradition of trying to be an inclusive community and handing out
> commit rights fairly freely.
> We also tend to not revoke commit rights for people no longer
> regularly acti
On 04/24/2018 03:44 PM, Daniel Vetter wrote:
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
Adding the dri-devel list, since this is driver independent code.
On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
Avoid calling wait_event_killable when you are possibly being called
https://bugs.freedesktop.org/show_bug.cgi?id=106006
--- Comment #14 from Joel Sass ---
Sorry, I completely forgot that I was using a custom kernel. I downloaded it
from here:
https://github.com/M-Bab/linux-kernel-amdgpu-binaries
and installed the .deb files directly.
Here's the source: https:/
Had a meeting with Daniel and talked about bringing out generic
part of hyper-dmabuf to the userspace, which means we most likely
reuse IOCTLs defined in xen-zcopy for our use-case if we follow
his suggestion.
So assuming we use these IOCTLs as they are,
Several things I would like you to double-c
https://bugs.freedesktop.org/show_bug.cgi?id=106159
--- Comment #6 from Joel Sass ---
Will do! Sorry, I haven't had much time for testing recently.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri
https://bugs.freedesktop.org/show_bug.cgi?id=106193
--- Comment #4 from Joel Sass ---
Hey Harry,
Thanks for your help.
Should I be using my current kernel, or just download the newest source to
apply these patches against?
Some of the other patches didn't really have the context useful to patc
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #49 from MirceaKitsune ---
Sorry about that: I posted my last message before reading your last one, and
didn't notice your mention about /var/log/messages being obsolete. Just
mentioning so you don't think I ignored what you said.
I
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #48 from MirceaKitsune ---
Created attachment 139071
--> https://bugs.freedesktop.org/attachment.cgi?id=139071&action=edit
/var/log/messages
I managed to trigger the GPU freeze while running Xonotic through apitrace.
Upon restarti
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #47 from i...@yahoo.com ---
(In reply to MirceaKitsune from comment #46)
> I found out what's causing the apitrace crash: It no longer happens when I
> use fresh settings, therefore something in my config was breaking it. Upon
> furth
On Tue, Apr 24, 2018 at 12:42:39PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> Based on kernel commit '672e314b21dc ("drm/i915/kbl: Add KBL GT2 sku")'
>
> v2: name change M -> ULX, add enumeration in KBL ULX
> v3: add entry to IS_KABYLAKE
reviewed and pushed. Thanks for the
From: Matt Atwood
Based on kernel commit '672e314b21dc ("drm/i915/kbl: Add KBL GT2 sku")'
v2: name change M -> ULX, add enumeration in KBL ULX
v3: add entry to IS_KABYLAKE
Signed-off-by: Matt Atwood
---
intel/intel_chipset.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --
On Wed, 2018-04-11 at 19:42 -0400, Lyude Paul wrote:
> Does what it says on the label, it's a little confusing debugging atomic
> check failures otherwise.
>
> Cc: Manasi Navare
> Cc: Ville Syrjälä
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_atomic.c | 5 -
> 1 file changed,
On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote:
>
> Adding the dri-devel list, since this is driver independent code.
>
>
> On 2018-04-24 05:30 PM, Andrey Grodzovsky wrote:
> > Avoid calling wait_event_killable when you are possibly being called
> > from get_signal routine since i
On Tue, Apr 24, 2018 at 06:51:07PM +0300, Jyri Sarha wrote:
> Remove all drm_panel_detach() calls from all panel drives update the
> kernel doc for drm_panel_detach().
>
> Setting the connector and drm to NULL when the drm panel device is
> going away hardly serves any purpose. Usually the the who
On Tue, Apr 24, 2018 at 05:26:30PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 24, 2018 at 04:18:37PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 24, 2018 at 04:02:50PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > We're currently failing to reset everything in display_info.hdmi
On Tue, Apr 24, 2018 at 8:48 PM, Christoph Hellwig wrote:
> On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote:
>> > At the very lowest level they will need to be handled differently for
>> > many architectures, the questions is at what point we'll do the
>> > branching out.
>>
>> Havin
https://bugs.freedesktop.org/show_bug.cgi?id=106159
--- Comment #5 from Harry Wentland ---
Created attachment 139070
--> https://bugs.freedesktop.org/attachment.cgi?id=139070&action=edit
[PATCH 2/2] drm/amd/display: Check dc_sink every time in MST hotplug
Can you try patches 1 and 2?
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=106159
--- Comment #4 from Harry Wentland ---
Created attachment 139069
--> https://bugs.freedesktop.org/attachment.cgi?id=139069&action=edit
[PATCH 1/2] drm/amd/display: Update MST edid property every time
--
You are receiving this mail because:
Y
https://bugzilla.kernel.org/show_bug.cgi?id=199101
Kevin McCormack (harlemsquir...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugzilla.kernel.org/show_bug.cgi?id=199101
--- Comment #25 from Thomas Crider (tcride...@gmail.com) ---
I can also confirm the flicker is gone with 4.17rc2
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dr
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #46 from MirceaKitsune ---
I found out what's causing the apitrace crash: It no longer happens when I use
fresh settings, therefore something in my config was breaking it. Upon further
inspection it seems to be one of the visual effe
Den 24.04.2018 21.16, skrev Daniel Vetter:
On Tue, Apr 24, 2018 at 6:52 PM, Noralf Trønnes wrote:
Den 23.04.2018 18.16, skrev Tom Callaway:
The PiTFT (ili9340) has a hardware reset circuit that resets only
on power-on and not on each reboot through a gpio like the
rpi-display does. As a resul
From: Matt Atwood
Based on kernel commit '672e314b21dc ("drm/i915/kbl: Add KBL GT2 sku")'
v2: name change M -> ULX, add enumeration in KBL ULX
Signed-off-by: Matt Atwood
---
intel/intel_chipset.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/intel/intel_chipset.h b/int
On Tue, Apr 24, 2018 at 6:52 PM, Noralf Trønnes wrote:
>
> Den 23.04.2018 18.16, skrev Tom Callaway:
>>
>> The PiTFT (ili9340) has a hardware reset circuit that resets only
>> on power-on and not on each reboot through a gpio like the
>> rpi-display does. As a result, we need to always apply the
>
On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov wrote:
> On 13 April 2018 at 11:00, Daniel Vetter wrote:
>> This tries to align with the X.org communities's long-standing
>> tradition of trying to be an inclusive community and handing out
>> commit rights fairly freely.
>>
>> We also tend to not re
On 2018-04-24 09:14 AM, Luc Van Oostenryck wrote:
> The method (*hqd_destroy) is defined as using an 'uint32_t'
> as 3rd argument but the the actual implementation of this
> method and all its calls actually uses an 'enum kfd_preempt_type'
> for this argument.
>
> Fix this by using 'enum kfd_preem
Hi Tomi,
On Thursday, 5 April 2018 13:21:30 EEST Tomi Valkeinen wrote:
> On 04/04/18 17:23, Laurent Pinchart wrote:
> +WARN(out_width > dispc.feat->ovl_width_max,
> + "Requested OVL width (%d) is larger than can be supported
> (%d).\n",
> + out_w
https://bugs.freedesktop.org/show_bug.cgi?id=101900
Harry Wentland changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=199101
--- Comment #24 from Harry Wentland (harry.wentl...@amd.com) ---
Kevin, can you mark this as resolved?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel ma
https://bugs.freedesktop.org/show_bug.cgi?id=102820
Harry Wentland changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
Reviewed-by: Felix Kuehling
We could probably add a sanity check for n_devices to avoid user mode
causing excessive memory allocations in the kernel. There is no good
reason for this to be bigger than the number of GPUs in the system. The
maximum number of GPUs supported due to device minor limit
https://bugs.freedesktop.org/show_bug.cgi?id=103987
Harry Wentland changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=104319
Harry Wentland changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #18 from David Henningsson ---
(In reply to Michel Dänzer from comment #10)
> (In reply to David Henningsson from comment #8)
> > The regression is between 4.15rc2 and 4.15rc3
>
> Any chance you can bisect between these two?
So I d
https://bugs.freedesktop.org/show_bug.cgi?id=104281
Harry Wentland changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=105284
Harry Wentland changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Fri, Apr 20, 2018 at 05:21:11PM +0200, Daniel Vetter wrote:
> > At the very lowest level they will need to be handled differently for
> > many architectures, the questions is at what point we'll do the
> > branching out.
>
> Having at least struct page also in that list with (dma_addr_t, lenght
https://bugs.freedesktop.org/show_bug.cgi?id=106006
--- Comment #13 from Harry Wentland ---
Not sure exactly how that kernel is assembled but it contains the problematic
code in drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c. You should be
able to simply delete the block for if (__is_lut
On Tue, Apr 24, 2018 at 3:34 AM, Stefan Schake wrote:
> On Tue, Apr 24, 2018 at 10:09 AM, Alexandru-Cosmin Gheorghe
> wrote:
>> On Mon, Apr 23, 2018 at 05:06:44PM -0700, John Stultz wrote:
>>> @@ -695,6 +704,15 @@ HWC2::Error
>>> DrmHwcTwo::HwcDisplay::ValidateDisplay(uint32_t *num_types,
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #45 from MirceaKitsune ---
(In reply to iive from comment #44)
I'm doing my best to debug this as well as possible, but there are a lot of
points and it's hard to pay attention to everything. I thought the crashing to
the desktop in
Hi Maxime and all,
I resend the e-mail since it was refused by some address(my phone
composed it in HTML). Sorry.
Il 24/04/2018 10:41, Maxime Ripard ha scritto:
Hi,
On Mon, Apr 23, 2018 at 04:37:33PM +0200, Giulio Benetti wrote:
Il 22/03/2018 19:05, Maxime Ripard ha scritto:
On Wed, Mar 21,
On 24/04/18 20:06, Russell King - ARM Linux wrote:
> On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote:
>> On 24/04/18 13:14, Peter Rosin wrote:
>>> On 2018-04-24 10:08, Russell King - ARM Linux wrote:
On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote:
> On 2018-04-23 18
On Tue, Apr 24, 2018 at 10:55:05AM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
please add the message:
Based on kernel commit '672e314b21dc ("drm/i915/kbl: Add KBL GT2 sku")'
>
> v2: name change M -> ULX, add enumeration in KBL ULX
>
> Signed-off-by: Matt Atwood
> ---
> int
malidp_pm_suspend_late checks if the runtime status is not suspended
and if so, invokes malidp_runtime_pm_suspend which disables the
display engine/core interrupts and the clocks. It sets the runtime status
as suspended.
The difference between suspend() and suspend_late() is as follows:-
1. suspen
One needs to store the value of the OUTPUT_DEPTH that one has parsed from
device tree, so that it can be restored on system resume. This value is
set in the modeset function as this gets reset when the system suspends.
Signed-off-by: Ayan Kumar Halder
---
Changes in v3:-
- Rebased the patch on t
Malidp uses two interrupts ie 1. se_irq - used for memory writeback.
and 2. de_irq - used for display output.
Extract the hardware initialization part from malidp interrupt registration
ie (malidp_de_irq_init()/ malidp_se_irq_init()) into a separate function
(ie malidp_de_irq_hw_init()/malidp_se
Malidp uses two interrupts ie 1. se_irq - used for memory writeback.
and 2. de_irq - used for display output.
'struct drm_device' is being replaced with 'struct malidp_hw_device'
as the function argument. The reason being the dependency of
malidp_de_irq_fini on 'struct drm_device' needs to be rem
Display and scaling engine interrupts need to be disabled when the
runtime pm invokes malidp_runtime_pm_suspend(). Conversely, they
need to be enabled in malidp_runtime_pm_resume().
This patch depends on:
https://lkml.org/lkml/2017/5/15/695
Signed-off-by: Ayan Kumar Halder
Signed-off-by: Alexand
This patch series enhances and fixes certain issues relevant to system and
runtime power management on malidp.
---
Changes in v3:
- Squashed some commits.
- Fixed an issue related to writeback.
Reported-by: Alexandru-Cosmin Gheorghe
Changes in v2:
- Removed the change ids and modified some co
From: Matt Atwood
v2: name change M -> ULX, add enumeration in KBL ULX
Signed-off-by: Matt Atwood
---
intel/intel_chipset.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/intel/intel_chipset.h b/intel/intel_chipset.h
index 01d250e..f479bc4 100644
--- a/intel/intel_chipse
On Tue, Apr 24, 2018 at 10:42:26AM -0700, Rodrigo Vivi wrote:
> On Mon, Apr 23, 2018 at 03:08:31PM -0700, matthew.s.atw...@intel.com wrote:
> > From: Matt Atwood
>
> Based on kernel commit '672e314b21dc ("drm/i915/kbl: Add KBL GT2 sku")'
>
> (I'm adding this and pushing. Thanks for the patch)
>
On Mon, Apr 09, 2018 at 11:14:17AM +0200, Daniel Vetter wrote:
> On Fri, Apr 06, 2018 at 04:56:48PM -0700, Keith Packard wrote:
> > (This is an RFC on whether this pair of ioctls seems reasonable. The
> > code compiles, but I haven't tested it as I'm away from home this
> > weekend.)
> >
> > I'm r
1 - 100 of 284 matches
Mail list logo