The clk_ops structure is only stored in the ops field of a
clk_init_data structure. This field is const, so the clk_ops
structure can be const as well.
Identified and transformed using Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/imx/imx-tve.c |2 +-
1 file changed, 1 inser
The clk_ops structure is only stored in the ops field of a
clk_init_data structure. This field is const, so the clk_ops
structure can be const as well.
Identified and transformed using Coccinelle.
Signed-off-by: Julia Lawall
---
drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c |2 +-
1 file chang
Declare as const clk_ops structures that are only stored in const fields or
passed to functions with const parameters.
Identified and transformed using Coccinelle.
Signed-off-by: Julia Lawall
---
arch/arm/mach-vexpress/spc.c |2 +-
drivers/clk/clk-max77686.c |
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #12 from Timur Kristóf ---
By the way the voltage issue has already been reported against ROCm and is
supposed to be already fixed. The details are here:
https://github.com/RadeonOpenCompute/ROCm/issues/348
--
You are receiving thi
Hi Lyude,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on v4.19 next-20181019]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #11 from Timur Kristóf ---
Created attachment 142228
--> https://bugs.freedesktop.org/attachment.cgi?id=142228&action=edit
Content of /sys/class/drm/card0/device/pp_table
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #10 from Timur Kristóf ---
Created attachment 142227
--> https://bugs.freedesktop.org/attachment.cgi?id=142227&action=edit
Content of /sys/kernel/debug/dri/0/amdgpu_vbios
--
You are receiving this mail because:
You are the assign
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #9 from Timur Kristóf ---
I think I discovered a possible reason for this issue. If you look at the
DDEBUG dumps, it says in several places: "This slot was corrupted in GPU
memory". So I began to suspect something was wrong with the
https://bugs.freedesktop.org/show_bug.cgi?id=107518
--- Comment #13 from Timothy Pearson ---
The patch originally at
https://cgit.freedesktop.org/~agd5f/linux/commit/?h=amd-staging-drm-next&id=8242308cc3c4419832126ab78ca409ce7110ab33
is no longer available:
> Bad commit reference: 8242308cc3c441
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: af1ad4786a34698ea5bc7a3e6fb833646b22c71d
commit: 97a7445714f44d2a978237281af297b299770f16 [709/711] drm/amdgpu: fix
reporting of failed msg sent to SMU
config: i386-allmodconfig (attached as .config)
compiler: gcc-7
https://bugzilla.kernel.org/show_bug.cgi?id=201439
fin4...@hotmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=108573
Bug ID: 108573
Summary: Cannot set pstate values with under-voltage values for
Vega M
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux
https://bugs.freedesktop.org/show_bug.cgi?id=108096
--- Comment #17 from Dieter Nützel ---
(In reply to Andrey Grodzovsky from comment #16)
> Question is do you have " winsys/amdgpu: pass the BO list via the CS ioctl
> on DRM >= 3.27.0" commit in your MESA tree ? I am not clear on that.
461a8643
IMPORTANT -
As a note: I have not had the customer who this second patch is for test
this yet, I'm sending this ahead of time to make sure this is something
that isn't too crazy for upstream to accept. I'm not planning on pushing
this after review until I've verified this actually fixes th
Turns out that if you trigger an HPD storm on a system that has an MST
topology connected to it, you'll end up causing the kernel to eventually
hit a NULL deref:
[ 332.339041] BUG: unable to handle kernel NULL pointer dereference at
00ec
[ 332.340906] PGD 0 P4D 0
[ 332.342750] Oops
Unfortunately, it seems that the HPD IRQ storm problem from the early
days of Intel GPUs was never entirely solved, only mostly. Within the
last couple of days, I got a bug report from one of our customers who
had been having issues with their machine suddenly booting up very
slowly after having up
This hasn't caused any issues yet that I'm aware of, but as Ville
Syrjälä pointed out - we need to make sure that
intel_connector->mst_port is set before initializing MST connectors,
since in theory we could potentially check intel_connector->mst_port in
i915_hpd_poll_init_work() after registering
Den 17.10.2018 15.04, skrev Noralf Trønnes:
This move makes tinydrm useful for more drivers. tinydrm doesn't need
continuous memory, but at the time it was convenient to use the CMA
library. The spi core can do dma on is_vmalloc() addresses making this
possible.
Cc: David Lechner
Signed-off-by
Den 26.10.2018 21.16, skrev Noralf Trønnes:
Den 26.10.2018 04.30, skrev Eric Anholt:
Noralf Trønnes writes:
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
On Fri, Oct 26, 2018 at 08:06:11PM +, Kazlauskas, Nicholas wrote:
> On 10/26/18 3:13 PM, Manasi Navare wrote:
> > On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote:
> >> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
> >>> On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nic
https://bugzilla.kernel.org/show_bug.cgi?id=201285
--- Comment #7 from vl...@aresgate.net ---
Created attachment 279173
--> https://bugzilla.kernel.org/attachment.cgi?id=279173&action=edit
debug_logs_new
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=201285
--- Comment #6 from vl...@aresgate.net ---
Created attachment 279171
--> https://bugzilla.kernel.org/attachment.cgi?id=279171&action=edit
debug logs
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=201285
oyvi...@everdot.org changed:
What|Removed |Added
CC||oyvi...@everdot.org
--- Comment #5
There has been a TODO waiting for quite a long time in
drm_dp_mst_topology.c:
/* We cannot rely on port->vcpi.num_slots to update
* topology_state->avail_slots as the port may not exist if the parent
* branch device was unplugged. This should be fixed by tracking
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
---
include/drm/drm_dp_mst_helper.h | 77 +
1 file changed, 77 insertions(+)
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 59f005b419cf..3faceb66f5cb 100644
--- a/include/drm/drm_d
Currently, nouveau uses the yolo method of setting up MST displays: it
uses the old VCPI helpers (drm_dp_find_vcpi_slots()) for computing the
display configuration. These helpers don't take care to make sure they
take a reference to the mstb port that they're checking, and
additionally don't actual
It occurred to me that we never actually check this! So let's start
doing that.
Signed-off-by: Lyude Paul
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_dp_mst_topology.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/d
This patchset does some cleaning up of the atomic VCPI helpers for MST,
and converts nouveau over to using them. I would have included amdgpu in
this patch as well, but at the moment moving them over to the atomic
helpers is nontrivial.
Cc: Daniel Vetter
Lyude Paul (4):
drm/dp_mst: Add some at
https://bugs.freedesktop.org/show_bug.cgi?id=108096
--- Comment #16 from Andrey Grodzovsky ---
Question is do you have " winsys/amdgpu: pass the BO list via the CS ioctl on
DRM >= 3.27.0" commit in your MESA tree ? I am not clear on that.
--
You are receiving this mail because:
You are the assi
On Fri, 2018-03-09 at 17:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the messy framebuffer format/modifier validation code
> with a single call to drm_any_plane_has_format(). The code was
> extremely annoying to maintain as you had to have a lot of platform
> checks for diffe
On 10/26/18 3:13 PM, Manasi Navare wrote:
> On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote:
>> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
>>> On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote:
On 10/26/18 7:37 AM, Pekka Paalanen wrote:
> On Thu, 11
On Fri, 2018-03-09 at 17:14 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a function to check whether there is at least one plane that
> supports a specific format and modifier combination. Drivers can
> use this to reject unsupported formats/modifiers in .fb_create().
>
> v2: Accept
Use 'unsigned int' with bitfield instead of 'bool' to avoid alignment
issues and remove checkpatch.pl check:
CHECK: Avoid using bool structure members because of possible alignment
issues
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/qxl/qxl_drv.h | 10 +-
1 file changed, 5 i
Add space to remove checkpath.pl error:
ERROR: space required before the open parenthesis '('
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/q
Use 'usigned int' instead of 'usigned' to remove the checkpath.pl warning:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/qxl/qxl_cmd.c | 2 +-
drivers/gpu/drm/qxl/qxl_debugfs.c | 4 ++--
drivers/gpu/drm/qxl/qxl_display.c
Remove extra whiteline to clean the checkpatch.pl check:
CHECK: Please don't use multiple blank lines
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/qxl/qxl_cmd.c | 1 -
drivers/gpu/drm/qxl/qxl_debugfs.c | 1 -
drivers/gpu/drm/qxl/qxl_dev.h | 1 -
drivers/gpu/drm/qxl/qxl_displ
Add whiteline after variable declarations to remove the checkpath.pl
warning:
WARNING: Missing a blank line after declarations
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/qxl/qxl_cmd.c | 4
drivers/gpu/drm/qxl/qxl_display.c | 2 ++
drivers/gpu/drm/qxl/qxl_draw.c| 2 ++
Remove extra tab and space to clean the checkpath.pl error.
ERROR: trailing whitespace
Signed-off-by: Shayenne da Luz Moura
---
drivers/gpu/drm/qxl/qxl_dumb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c
inde
This series cleans the following checkpatch.pl issues:
ERROR: trailing whitespace
WARNING: Missing a blank line after declarations
CHECK: Please don't use multiple blank lines
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
ERROR: space required before the open parenthesis '('
CHECK: Avoi
Den 26.10.2018 04.30, skrev Eric Anholt:
Noralf Trønnes writes:
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 n
On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote:
> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
> > On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote:
> >> On 10/26/18 7:37 AM, Pekka Paalanen wrote:
> >>> On Thu, 11 Oct 2018 12:39:41 -0400
> >>> Nicholas Kazlau
https://bugzilla.kernel.org/show_bug.cgi?id=201285
--- Comment #4 from vl...@aresgate.net ---
Forgot to mention system locks up as well at random after new 4.19.0 kernel
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=201285
vl...@aresgate.net changed:
What|Removed |Added
CC||vl...@aresgate.net
--- Comment #3 fr
Am 26.10.18 um 16:43 schrieb Andrey Grodzovsky:
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/v3d/v3d_sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 27
From: Colin Ian King
Trivial fix to a spelling mistake of the error access name EACCESS,
rename to EACCES
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/drm_lease.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
On Fri, Oct 26, 2018 at 05:34:15PM +, Kazlauskas, Nicholas wrote:
> On 10/26/18 10:53 AM, Ville Syrjälä wrote:
> > On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote:
> >> On 10/26/18 7:37 AM, Pekka Paalanen wrote:
> >>> On Thu, 11 Oct 2018 12:39:41 -0400
> >>> Nicholas Kazlau
On Fri, 2018-10-26 at 20:52 +0300, Ville Syrjälä wrote:
> On Thu, Oct 25, 2018 at 06:26:57PM -0400, Lyude Paul wrote:
> > Unfortunately, it seems that the HPD IRQ storm problem from the early
> > days of Intel GPUs was never entirely solved, only mostly. Within the
> > last couple of days, I got a
On Thu, Oct 25, 2018 at 06:26:57PM -0400, Lyude Paul wrote:
> Unfortunately, it seems that the HPD IRQ storm problem from the early
> days of Intel GPUs was never entirely solved, only mostly. Within the
> last couple of days, I got a bug report from one of our customers who
> had been having issue
On Thu, Oct 25, 2018 at 06:26:56PM -0400, Lyude Paul wrote:
> Turns out that if you trigger an HPD storm on a system that has an MST
> topology connected to it, you'll end up causing the kernel to eventually
> hit a NULL deref:
>
> [ 332.339041] BUG: unable to handle kernel NULL pointer dereferen
On 10/26/18 10:53 AM, Ville Syrjälä wrote:
> On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote:
>> On 10/26/18 7:37 AM, Pekka Paalanen wrote:
>>> On Thu, 11 Oct 2018 12:39:41 -0400
>>> Nicholas Kazlauskas wrote:
>>>
These include the drm_connector 'vrr_capable' and the drm_
https://bugs.freedesktop.org/show_bug.cgi?id=108570
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=108521
--- Comment #27 from Robert Strube ---
Thanks for the response.
I think it was just a coincidence that the eGPU started working with acpi=off.
Taking a closer look at the issue it really does appear to be a BIOS problem
that prevents the prope
https://bugs.freedesktop.org/show_bug.cgi?id=108562
--- Comment #4 from Slava ---
this is xorg log after normal shutdown, not after gpu hung. I will try paste
some logs after gpu hung bit later
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108570
--- Comment #3 from testmod...@protonmail.com ---
Not seeing any DC success or error messages - though not clear how these would
look.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108562
--- Comment #3 from Slava ---
Created attachment 14
--> https://bugs.freedesktop.org/attachment.cgi?id=14&action=edit
xorg log
this is xorg log after normal shutdown, not after gpu hung
--
You are receiving this mail because:
You ar
https://bugs.freedesktop.org/show_bug.cgi?id=108570
--- Comment #2 from testmod...@protonmail.com ---
Created attachment 142223
--> https://bugs.freedesktop.org/attachment.cgi?id=142223&action=edit
dmesg-amd
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=108562
--- Comment #2 from Slava ---
Created attachment 142221
--> https://bugs.freedesktop.org/attachment.cgi?id=142221&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108570
--- Comment #1 from John Bridgman ---
I don't believe there is any connection between "atomic" modesetting and atomic
operations in PCIE 3.0.
Do you see other DC-related messages ? Might be helpful to post your full dmesg
output.
--
You are r
https://bugs.freedesktop.org/show_bug.cgi?id=108570
testmod...@protonmail.com changed:
What|Removed |Added
Summary|AMDGPU DC Not workin on PCI |AMDGPU DC not working on
https://bugs.freedesktop.org/show_bug.cgi?id=108570
Bug ID: 108570
Summary: AMDGPU DC Not workin on PCI Express 2.0?
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
-ci/linux/commits/Emil-Velikov/drm-vgem-create-a-render-node-for-vgem/20181026-233734
base: https://github.com/fuweitax/linux master
config: i386-randconfig-x077-201842 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 4cab470e01108ad0a7a74c6a30d83e7e8e60aa9e
commit: 4cab470e01108ad0a7a74c6a30d83e7e8e60aa9e [3/3] drm/amdgpu/amdkfd: clean
up mmhub and gfxhub includes
config: x86_64-allmodconfig (attached as .config)
compiler: gcc-7
On Fri, Oct 19, 2018 at 4:51 AM Daniel Vetter wrote:
>
> Hi all,
>
> This is just to collect feedback on this idea, and see whether the
> overall dri-devel community stands on all this. I think the past few
> cross-vendor uapi extensions all came with igts attached, and
> personally I think there'
On Fri, Oct 26, 2018 at 04:52:33PM +0200, Boris Brezillon wrote:
> On Fri, 26 Oct 2018 16:26:03 +0200
> Daniel Vetter wrote:
>
> > On Fri, Oct 26, 2018 at 3:57 PM Boris Brezillon
> > wrote:
> > >
> > > On Fri, 26 Oct 2018 15:30:26 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Thu, Oct 25,
Sean,
On Fri, Oct 26, 2018 at 7:47 AM Sean Paul wrote:
> > I didn't see your v2 when I replied to the v1 patch, so for the record,
> >
> > Reviewed-by: Sean Paul
> >
> > Also note to whoever applies this to -misc, v1 also had
> >
> > Reviewed-by: Abhinav Kumar
>
> And I just realized that patch
https://bugzilla.kernel.org/show_bug.cgi?id=199139
--- Comment #19 from Eduard (wirch.edu...@gmail.com) ---
I figured out it is not true. After a longer period of turned off screen
(lightDM automatically turns it off if you lock the station), the hangs
appeared again. So I'm back again on 4.14. :(
On Fri, Oct 26, 2018 at 02:49:31PM +, Kazlauskas, Nicholas wrote:
> On 10/26/18 7:37 AM, Pekka Paalanen wrote:
> > On Thu, 11 Oct 2018 12:39:41 -0400
> > Nicholas Kazlauskas wrote:
> >
> >> These include the drm_connector 'vrr_capable' and the drm_crtc
> >> 'vrr_enabled' properties.
> >>
> >>
On Fri, Oct 26, 2018 at 10:43 AM Andrey Grodzovsky
wrote:
>
> Signed-off-by: Andrey Grodzovsky
Reviewed-by: Alex Deucher
> ---
> drivers/gpu/drm/v3d/v3d_sched.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sc
On Fri, 26 Oct 2018 16:26:03 +0200
Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 3:57 PM Boris Brezillon
> wrote:
> >
> > On Fri, 26 Oct 2018 15:30:26 +0200
> > Daniel Vetter wrote:
> >
> > > On Thu, Oct 25, 2018 at 11:41:14AM +0200, Boris Brezillon wrote:
> > > > On Thu, 25 Oct 2018 11:33
On 10/26/18 7:37 AM, Pekka Paalanen wrote:
> On Thu, 11 Oct 2018 12:39:41 -0400
> Nicholas Kazlauskas wrote:
>
>> These include the drm_connector 'vrr_capable' and the drm_crtc
>> 'vrr_enabled' properties.
>>
>> Signed-off-by: Nicholas Kazlauskas
>> ---
>> Documentation/gpu/drm-kms.rst | 7
On Fri, Oct 26, 2018 at 10:43:56AM -0400, Sean Paul wrote:
> On Thu, Oct 25, 2018 at 03:21:33PM -0700, Douglas Anderson wrote:
> > As far as I can tell the bindings that were added in commit
> > 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
> > bindings") weren't actually f
On Thu, Oct 25, 2018 at 03:21:34PM -0700, Douglas Anderson wrote:
> As far as I can tell the panel that was added in commit da50bd4258db
> ("drm/panel: simple: Add Innolux TV123WAM panel driver support")
> wasn't actually an Innolux TV123WAM but was actually an Innolux
> P120ZDG-BF1.
>
> As far as
On Thu, Oct 25, 2018 at 03:21:33PM -0700, Douglas Anderson wrote:
> As far as I can tell the bindings that were added in commit
> 9c04400f7ea6 ("dt-bindings: drm/panel: Document Innolux TV123WAM panel
> bindings") weren't actually for Innolux TV123WAM but were actually for
> Innolux P120ZDG-BF1.
>
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/v3d/v3d_sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 273d0fb..80b641f 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 4cab470e01108ad0a7a74c6a30d83e7e8e60aa9e
commit: 852c20fdce7c6702c4d073f2c238c0859344bcb9 [696/705] drm/ttm: initialize
globals during device init
config: i386-allmodconfig (attached as .config)
compiler: gcc-7 (Deb
On Thu, Oct 25, 2018 at 03:21:31PM -0700, Douglas Anderson wrote:
> If the HPD signal isn't hooked up to this panel we need a 200 ms
> delay. In the datasheet this is shown as the maximum time that HPD
> will take to be asserted after power is given to the panel.
>
> Signed-off-by: Douglas Anders
On Fri, Oct 26, 2018 at 4:32 AM Daniel Vetter wrote:
>
> On Fri, Oct 26, 2018 at 5:50 AM Zhou, David(ChunMing)
> wrote:
> >
> > Make igt for cross-driver, I think you should rename it first, not an intel
> > specific. NO company wants their employee working on other company stuff.
> > You can re
On Thu, Oct 25, 2018 at 03:21:30PM -0700, Douglas Anderson wrote:
> Some eDP panels that are designed to be always connected to a board
> use their HPD signal to signal that they've finished powering on and
> they're ready to be talked to.
>
> However, for various reasons it's possible that the HP
Quoting Daniel Vetter (2018-10-26 14:40:36)
> On Fri, Oct 26, 2018 at 01:06:47PM +0100, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > VGEM doesn't do anything modeset specific, so in a way exposing a
> > primary node is 'wrong'. At the same time, we extensively use if for
> > creating dumb b
On Thu, Oct 25, 2018 at 03:24:58PM -0700, Doug Anderson wrote:
> Hi,
>
> On Thu, Oct 25, 2018 at 11:13 AM Sean Paul wrote:
> >
> > On Mon, Oct 22, 2018 at 01:46:38PM -0700, Douglas Anderson wrote:
> > > As far as I can tell the panel that was added in commit da50bd4258db
> > > ("drm/panel: simple
https://bugs.freedesktop.org/show_bug.cgi?id=108562
--- Comment #1 from Alex Deucher ---
Please attach your xorg log and dmesg output.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.
On Mon, 15 Oct 2018 12:06:52 +0200
Michel Dänzer wrote:
> On 2018-10-15 11:47 a.m., Christian König wrote:
> > Am 15.10.2018 um 11:40 schrieb Michel Dänzer:
> >> On 2018-10-13 7:38 p.m., Christian König wrote:
> >>> Am 12.10.2018 um 18:44 schrieb Nicholas Kazlauskas:
> This patch intro
On Fri, Oct 26, 2018 at 3:57 PM Boris Brezillon
wrote:
>
> On Fri, 26 Oct 2018 15:30:26 +0200
> Daniel Vetter wrote:
>
> > On Thu, Oct 25, 2018 at 11:41:14AM +0200, Boris Brezillon wrote:
> > > On Thu, 25 Oct 2018 11:33:14 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Thu, Oct 25, 2018 at 10
On Fri, Oct 26, 2018 at 4:13 PM Boris Brezillon
wrote:
>
> On Fri, 26 Oct 2018 15:36:15 +0200
> Daniel Vetter wrote:
>
> > On Fri, Oct 26, 2018 at 02:36:56PM +0200, Boris Brezillon wrote:
> > > Hi Daniel,
> > >
> > > On Fri, 26 Oct 2018 12:33:37 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On
On Fri, 26 Oct 2018 15:36:15 +0200
Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 02:36:56PM +0200, Boris Brezillon wrote:
> > Hi Daniel,
> >
> > On Fri, 26 Oct 2018 12:33:37 +0200
> > Daniel Vetter wrote:
> >
> > > On Thu, Oct 25, 2018 at 02:45:44PM +0200, Boris Brezillon wrote:
> > > > D
BACKLIGHT_CLASS_DEVICE is already tristate, but a dependency
FB_BACKLIGHT prevents it from being built as a module. There
doesn't seem to be any particularly good reason for this, so
switch FB_BACKLIGHT over to tristate.
Signed-off-by: Rob Clark
Tested-by: Arnd Bergmann
---
v2: remove IS_ENABLE
On Fri, 26 Oct 2018 15:30:26 +0200
Daniel Vetter wrote:
> On Thu, Oct 25, 2018 at 11:41:14AM +0200, Boris Brezillon wrote:
> > On Thu, 25 Oct 2018 11:33:14 +0200
> > Daniel Vetter wrote:
> >
> > > On Thu, Oct 25, 2018 at 10:09:31AM +0200, Boris Brezillon wrote:
> > > > On Tue, 23 Oct 2018 1
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.21-wip
head: 0f117df308faec4f1eecc9a36b3a836181063483
commit: 0544d53c4e7baac87a8fc81a9aae001be0e034ae [83/87] drm/sched: Add boolean
to mark if sched is ready to work v4
config: xtensa-allyesconfig (attached as .config)
compiler:
On Fri, Oct 26, 2018 at 01:06:47PM +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> VGEM doesn't do anything modeset specific, so in a way exposing a
> primary node is 'wrong'. At the same time, we extensively use if for
> creating dumb buffers, fences, prime fd <> handle imports/exports.
>
>
Added Rob to this thread.
On 10/17/2018 8:05 PM, Jordan Crouse wrote:
On Wed, Oct 17, 2018 at 06:34:01PM +0530, Sharat Masetty wrote:
This patch attempts to make use of the hardware counters for GPU busy %
estimation when possible and skip using the software counters as it also
accounts for sof
On Fri, Oct 26, 2018 at 02:36:56PM +0200, Boris Brezillon wrote:
> Hi Daniel,
>
> On Fri, 26 Oct 2018 12:33:37 +0200
> Daniel Vetter wrote:
>
> > On Thu, Oct 25, 2018 at 02:45:44PM +0200, Boris Brezillon wrote:
> > > Display controllers usually provide a lot features like overlay planes,
> > > h
https://bugs.freedesktop.org/show_bug.cgi?id=108563
--- Comment #1 from fin4...@hotmail.com ---
It is just a debug trace that you can delete:
[ 18.371385] WARNING: CPU: 1 PID: 289 at drivers/gpu/drm/drm_plane.c:182
WARN_ON(drm_drv_uses_atomic_modeset(dev) &&
(!funcs->atomic_des
On Thu, Oct 25, 2018 at 11:41:14AM +0200, Boris Brezillon wrote:
> On Thu, 25 Oct 2018 11:33:14 +0200
> Daniel Vetter wrote:
>
> > On Thu, Oct 25, 2018 at 10:09:31AM +0200, Boris Brezillon wrote:
> > > On Tue, 23 Oct 2018 15:44:43 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Tue, Oct 23,
Hi Daniel,
On Fri, 26 Oct 2018 12:33:37 +0200
Daniel Vetter wrote:
> On Thu, Oct 25, 2018 at 02:45:44PM +0200, Boris Brezillon wrote:
> > Display controllers usually provide a lot features like overlay planes,
> > hardware scalers, hardware rotations, ...
> > Most of the time those features work
Am 26.10.18 um 10:28 schrieb zhoucm1:
> Thanks, Could you help to submit to drm-misc again?
Done.
Christian.
>
> -David
>
>
> On 2018年10月26日 15:43, Christian König wrote:
>> Am 26.10.18 um 08:20 schrieb Chunming Zhou:
>>> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
>>> drm_syncobj_f
From: Emil Velikov
VGEM doesn't do anything modeset specific, so in a way exposing a
primary node is 'wrong'. At the same time, we extensively use if for
creating dumb buffers, fences, prime fd <> handle imports/exports.
To the point that we explicitly annotate the vgem fence ioctls as
DRM_RENDE
https://bugs.freedesktop.org/show_bug.cgi?id=108096
--- Comment #15 from Dieter Nützel ---
(In reply to Michel Dänzer from comment #14)
> Which Git commit of Mesa are you using? Any local patches on top?
Every, since ever, as always (even, since _before_ Aug 22, 2018) ...;-)
But kidding aside,
https://bugs.freedesktop.org/show_bug.cgi?id=108563
Bug ID: 108563
Summary: Kernel hangs up when no amdgpu.dc=0 (if DC not
disabled) kernel parameter supplied and when GCN 1.1
and GCN 1.2/1.4 (very likely) device will be handled
Op 26-10-18 om 08:20 schreef Chunming Zhou:
> drivers/gpu/drm/drm_syncobj.c:202:4-14: ERROR: function
> drm_syncobj_find_signal_pt_for_point called on line 390 inside lock on line
> 389 but uses GFP_KERNEL
>
> Find functions that refer to GFP_KERNEL but are called with locks held.
>
> Generated
On Thu, 11 Oct 2018 12:39:41 -0400
Nicholas Kazlauskas wrote:
> These include the drm_connector 'vrr_capable' and the drm_crtc
> 'vrr_enabled' properties.
>
> Signed-off-by: Nicholas Kazlauskas
> ---
> Documentation/gpu/drm-kms.rst | 7 +++
> drivers/gpu/drm/drm_connector.c | 22 +++
1 - 100 of 162 matches
Mail list logo
