On 12/05/2017 06:49 AM, Brian Norris wrote:
Hi Archit,
I'm a relative n00b here, but I'm trying to follow along and I have some
questions:
On Fri, Dec 01, 2017 at 06:29:04PM +0530, Archit Taneja wrote:
On 11/30/2017 11:02 PM, Nickey Yang wrote:
I try to follow as you suggested,use
mipi_dsi
This patch adds HDCP support for HDMI connectors by implementing
the intel_hdcp_shim.
Nothing too special, just a bunch of DDC reads/writes.
Changes in v2:
- Rebased on drm-intel-next
Changes in v3:
- Initialize new worker
Signed-off-by: Sean Paul
---
drivers/gpu/drm/i915/i915_reg.h | 1 +
This patch adds a new optional connector property to allow userspace to enable
protection over the content it is displaying. This will typically be implemented
by the driver using HDCP.
The property is a tri-state with the following values:
- OFF: Self explanatory, no content protection
- DESIRED:
This patch adds HDCP support for DisplayPort connectors by implementing
the intel_hdcp_shim.
Most of this is straightforward read/write from/to DPCD registers. One
thing worth pointing out is the Aksv output bit. It wasn't easily
separable like it's HDMI counterpart, so it's crammed in with the re
In preparation for implementing HDCP in i915, add some HDCP related
register offsets and defines. The dpcd register offsets will go in
drm_dp_helper.h whereas the ddc offsets along with generic HDCP stuff
will get stuffed in drm_hdcp.h, which is new.
Changes in v2:
- drm_hdcp.h gets MIT license (D
This patch adds the framework required to add HDCP support to intel
connectors. It implements Aksv loading from fuse, and parts 1/2/3
of the HDCP authentication scheme.
Note that without shim implementations, this does not actually implement
HDCP. That will come in subsequent patches.
Changes in
This patch enables the indexed write feature of the GMBUS to concatenate
2 consecutive messages into one. The criteria for an indexed write is
that both messages are writes, the first is length == 1, and the second
is length > 0. The first message is sent out by the GMBUS as the slave
command, and
Once the Aksv is available in the PCH, we need to get it on the wire to
the receiver via DDC. The hardware doesn't allow us to read the value
directly, so we need to tell GMBUS to source the Aksv internally and
send it to the right offset on the receiver.
The way we do this is to initiate an index
Oh, hello there. Here's v3 of the HDCP patchset.
Highlights of v3 are:
- Add atomic_check/commit helpers to intel_hdcp to handle state transitions and
call enable/disable at the right time.
- intel_hdcp_check_link() gets moved again to avoid being called with locks held
- Split out setting the p
I'm adding some stuff below it and it's killing my editor's vibe.
Changes in v2:
- Added to the series
Changes in v3:
- None
Cc: Manasi Navare
Acked-by: Daniel Vetter
Signed-off-by: Sean Paul
---
drivers/gpu/drm/drm_connector.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
d
This patch adds a little more control to a couple wait_for routines such
that we can avoid open-coding read/wait/timeout patterns which:
- need the value of the register after the wait_for
- run arbitrary operation for the read portion
This patch also chooses the correct sleep function (based on
Hi all,
Commits
36a46da90212 ("drm: rcar-du: Add R8A7743 support")
cdd907001572 ("drm: rcar-du: Add R8A7745 support")
7912dee7775e ("drm: rcar-du: Implement system suspend/resume support")
cf05f74ef40e ("drm: rcar-du: Remove unused CRTC suspend/resume functions")
are missing a Signed-off
Hold on, only Patch 1 is Reviewed-by: Roger He .
For Patch 2:
+ list_for_each_entry(p, &plist, lru) {
+ /* Swap the pages if we detect consecutive order */
+ if (count > first && pages[count - 1] == p - 1) {
+
Series is:
Reviewed-by: Roger He
Thanks
Roger(Hongbo.He)
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Monday, December 04, 2017 8:46 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; He, Roger
Subject: [PATCH 2/2] drm/ttm
Hi Archit,
I'm a relative n00b here, but I'm trying to follow along and I have some
questions:
On Fri, Dec 01, 2017 at 06:29:04PM +0530, Archit Taneja wrote:
> On 11/30/2017 11:02 PM, Nickey Yang wrote:
> >I try to follow as you suggested,use
> >
> >mipi_dsi: mipi@ff96 {
> > ...
> > .
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: da94f258bbf0786f7578d4804a77ce75cf58777f
commit: b41c97d7270b82207c5edc7c2d67337b15918462 [8/11] Merge remote-tracking
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: i386-randconfig-x007-12041112 (attached as .config)
tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip
head: da94f258bbf0786f7578d4804a77ce75cf58777f
commit: b41c97d7270b82207c5edc7c2d67337b15918462 [8/11] Merge remote-tracking
branch 'drm-intel/drm-intel-next-queued' into drm-tip
config: x86_64-randconfig-x009-201749 (attached as .config)
https://bugs.freedesktop.org/show_bug.cgi?id=104090
--- Comment #10 from Hein-Pieter van Braam ---
Created attachment 135955
--> https://bugs.freedesktop.org/attachment.cgi?id=135955&action=edit
DC: dmesg -T
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=104090
--- Comment #9 from Hein-Pieter van Braam ---
Created attachment 135954
--> https://bugs.freedesktop.org/attachment.cgi?id=135954&action=edit
DC: Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=104090
--- Comment #8 from Hein-Pieter van Braam ---
Created attachment 135953
--> https://bugs.freedesktop.org/attachment.cgi?id=135953&action=edit
DC: xrandr --prop output
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=104090
--- Comment #7 from Hein-Pieter van Braam ---
Created attachment 135952
--> https://bugs.freedesktop.org/attachment.cgi?id=135952&action=edit
Without DC: dmesg -T
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=104090
--- Comment #5 from Hein-Pieter van Braam ---
Created attachment 135950
--> https://bugs.freedesktop.org/attachment.cgi?id=135950&action=edit
Without DC: xrandr --prop output
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=104090
--- Comment #6 from Hein-Pieter van Braam ---
Created attachment 135951
--> https://bugs.freedesktop.org/attachment.cgi?id=135951&action=edit
Without DC: Xorg.log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=104090
--- Comment #4 from Hein-Pieter van Braam ---
Created attachment 135949
--> https://bugs.freedesktop.org/attachment.cgi?id=135949&action=edit
Without DC: Gnome shell shutdown dialog
--
You are receiving this mail because:
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=104090
--- Comment #3 from Hein-Pieter van Braam ---
Created attachment 135948
--> https://bugs.freedesktop.org/attachment.cgi?id=135948&action=edit
DC: Gnome shell shutdown dialog
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=104090
--- Comment #2 from Hein-Pieter van Braam ---
Created attachment 135947
--> https://bugs.freedesktop.org/attachment.cgi?id=135947&action=edit
DC: Gnome shell overview
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=104090
--- Comment #1 from Hein-Pieter van Braam ---
Created attachment 135946
--> https://bugs.freedesktop.org/attachment.cgi?id=135946&action=edit
Without DC: Gnome shell overview
--
You are receiving this mail because:
You are the assignee for t
https://bugs.freedesktop.org/show_bug.cgi?id=104090
Bug ID: 104090
Summary: Reduced colors on RX580 through eDP on Asus GL702ZC
laptop
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Add a comment to the DRM_PANEL_ORIENTATION_QUIRKS documenting that the
reason for a separate Kconfig for this is because
drm_panel_orientation_quirks.c code is shared with fbdev.
Suggested-by: Bartlomiej Zolnierkiewicz
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/Kconfig | 1 +
1 file chang
Hi,
On 01-12-17 19:02, Bartlomiej Zolnierkiewicz wrote:
On Saturday, November 25, 2017 08:35:46 PM Hans de Goede wrote:
Here is v7 of my series to add a "panel orientation" property to
the drm-connector for the LCD panel to let userspace know about LCD
panels which are not mounted upright, as w
Hi,
Am Montag, 4. Dezember 2017, 08:08:31 CET schrieb Doug Anderson:
> On Sun, Dec 3, 2017 at 11:46 PM, Heiko Stübner wrote:
> > Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
> >> On 2017年12月02日 05:58, Heiko Stuebner wrote:
> >> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrie
On Fri, Dec 1, 2017 at 10:55 AM, Christian König
wrote:
> Am 01.12.2017 um 16:28 schrieb Lucas Stach:
>>
>> Hi all,
>>
>> so this is the first step to make the marvelous AMDGPU scheduler useable
>> for other drivers. I have a (mostly) working prototype of Etnaviv using
>> the scheduler, but those
In
commit 613051dac40da1751ab269572766d3348d45a197
Author: Daniel Vetter
Date: Wed Dec 14 00:08:06 2016 +0100
drm: locking&new iterators for connector_list
we've went to extreme lengths to make sure connector iterations works
in any context, without introducing any additional locking cont
On 2017-12-04 08:08 AM, Arnd Bergmann wrote:
> Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
> and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions
> that do a comparison of floating-point variables:
>
> drivers/gpu/drm/amd/display/dc/calcs/dc
Hi Nick,
On Monday, 4 December 2017 21:30:01 EET Nick Bowler wrote:
> On 2017-12-04 21:06 +0200, Laurent Pinchart wrote:
> > As you reported that the PLL lock failure message is not printed, the
> > failure can only come from either the extra delay introduced by the
> > above loop, or from reading
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 762f01cfcaa042752cbcec9e9e5a67100ee7be11
commit: 0bd599b1f523598c05f13a4a562884e82a378c2c [151/500] ASoC: AMD: enable
ACP3x drivers build
config: sh-allmodconfig (attached as .config)
compiler: sh4-linux-gnu-gcc (De
https://bugs.freedesktop.org/show_bug.cgi?id=103791
--- Comment #14 from denisgolo...@yandex.ru ---
Created attachment 135938
--> https://bugs.freedesktop.org/attachment.cgi?id=135938&action=edit
dmesg with vblank debug
--
You are receiving this mail because:
You are the assignee for the bug._
Hi Nick,
On Friday, 1 December 2017 02:11:46 EET Nick Bowler wrote:
> On 2017-11-27 22:30 -0500, Nick Bowler wrote:
> > A note about the test setup: I had to remove the test equipment so I
> > no longer have any information about the video mode from the sink side
> > (like in the photos). Thus, w
https://bugs.freedesktop.org/show_bug.cgi?id=104082
Bug ID: 104082
Summary: amdgpu :07:00.0: swiotlb buffer is full (sz:
2097152 bytes)
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
On Mon, Dec 4, 2017 at 4:20 PM, Gustavo A. R. Silva
wrote:
> Hi Joonas,
>
> Quoting Joonas Lahtinen :
>
>> On Mon, 2017-11-27 at 16:17 -0600, Gustavo A. R. Silva wrote:
>>>
>>> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
>>> where we are expecting to fall through.
>>
>>
>>
On 4 December 2017 at 14:02, Jose Abreu wrote:
> On 04-12-2017 13:16, Alexey Brodkin wrote:
>> Option "kmsdev" "/dev/dri/card1"
>
> Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and
> if you don't specify the busID it will fallback for the first
> card that matches
On 04-12-2017 16:00, Alexey Brodkin wrote:
> [30.763] (II) armada(0): etnaviv: Xv: using YUY2 format intermediate YUV
> target
>
I'm wondering if this means that target format for UDL is YUV ...
But anyway, I revisited your first email and noticed that you
said kmscube runs fine. Is this usi
From: Colin Ian King
The ring_id maximum boundary is being compared using the > operator
instead of >=, leading to an off-by-one error and an out of bounds
write into array vgpu->hws_pga[]. Fix this by simply using the
correct comparison operator. Also re-work another comparison that
uses the co
On Mon, Dec 4, 2017 at 5:36 PM, Laurent Pinchart
wrote:
> Hi Arnd,
>
> Thank you for the patch.
>
> On Monday, 4 December 2017 16:44:23 EET Arnd Bergmann wrote:
>> gcc-8 -fsanitize-coverage=trace-pc produces a false-positive warning:
>>
>> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function
>>
On Fri, Dec 01, 2017 at 12:33:51PM +0100, Andrzej Hajda wrote:
> sii8620 supports 1MHz clock, it allows faster transmissions and according
> to extensive tests allows to mitigate some obscure bugs in I2C client
> logic of the chip.
>
> Signed-off-by: Andrzej Hajda
> ---
> arch/arm64/boot/dts/exy
From: Colin Ian King
The switch statement is missing breaks for the cases of
GVT_FAILSAFE_INSUFFICIENT_RESOURCE and GVT_FAILSAFE_GUEST_ERR. Add them
in.
Detected by CoverityScan, CID#1462416 ("Missing break in switch")
Fixes: e011c6ce2b4f ("drm/i915/gvt: Add VM healthy check for workload_thread
Hi Dave,
The following changes since commit ca797d29cd63e7b71b4eea29aff3b1cefd1ecb59:
Merge tag 'drm-intel-next-2017-11-17-1' of git://anongit.freedesktop.org/
drm/drm-intel into drm-next (2017-12-04 10:56:53 +1000)
are available in the git repository at:
git://linuxtv.org/pinchartl/media.g
Hi Heiko,
On Monday, 4 December 2017 15:46:32 EET Heiko Stuebner wrote:
> Am Montag, 4. Dezember 2017, 15:22:07 CET schrieb Laurent Pinchart:
> > On Wednesday, 29 November 2017 20:47:55 EET Brian Norris wrote:
> > > From: Nickey Yang
> > >
> > > We might include additional ports in derivative de
Hi Arnd,
Thank you for the patch.
On Monday, 4 December 2017 16:44:23 EET Arnd Bergmann wrote:
> gcc-8 -fsanitize-coverage=trace-pc produces a false-positive warning:
>
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function
> 'mdp5_plane_mode_set.isra.8':
> drivers/gpu/drm/msm/mdp/mdp5/mdp5_pl
On 2017-12-04 01:46 PM, Christian König wrote:
> When we detect consecutive allocation of pages swap them to avoid
> accidentally freeing them as huge page.
>
> v2: use swap
> v3: check if it's really the first allocated page
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_pa
Hi,
On Sun, Dec 3, 2017 at 11:46 PM, Heiko Stübner wrote:
> Hi Chris,
>
> Am Montag, 4. Dezember 2017, 10:47:08 CET schrieb Chris Zhong:
>> On 2017年12月02日 05:58, Heiko Stuebner wrote:
>> > Am Freitag, 1. Dezember 2017, 13:42:46 CET schrieb Doug Anderson:
>> >> Hi,
>> >>
>> >> On Wed, Nov 29, 2017
On 04-12-2017 14:53, Alexey Brodkin wrote:
> Full log you may find below.
Sorry but I meant /var/log/Xorg.0.log file.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
This enables userspace to discover the engines available on the GPU.
Here is the layout on a Skylake GT4:
/sys/devices/pci:00/:00:02.0/drm/card0/gt/
└── engines
├── bcs
│ └── 0
│ ├── capabilities
│ ├── class
│ ├── id
│ └── instance
├──
With the introduction of asymetric slices in CNL, we cannot rely on
the previous SUBSLICE_MASK getparam. Here we introduce a more detailed
way of querying the Gen's GPU topology that doesn't aggregate numbers.
This is essential for monitoring parts of the GPU with the OA unit,
because signals need
Now that we have that information in topology fields, let's just reused it.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_debugfs.c | 26 ++
1 file changed, 10 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu
Up to now, subslice mask was assumed to be uniform across slices. But
starting with Cannonlake, slices can be asymetric (for example slice0
has different number of subslices as slice1+). This change stores all
subslices masks for all slices rather than having a single mask that
applies to all slice
In i915 we would like to expose information about the GPU topology
which would be useful mostly to applications making use of the device
computational capability (not so much the display part). At the moment
we already store information like frequency, etc... into the card
directory (/sys/class/drm
Hi,
After discussion with Chris, Joonas & Tvrtko, this series adds an
additional commit to link the render node back to the card through a
symlink. Making it obvious from an application using a render node to
know where to get the information it needs.
Cheers,
Lionel Landwerlin (5):
drm: add c
gcc-8 reports
drivers/gpu/drm/nouveau/nvkm/engine/pm/base.c: In function 'nvkm_perfmon_mthd':
include/linux/string.h:265:9: error: '__builtin_strncpy' specified bound 64
equals destination size [-Werror=stringop-truncation]
We need one less byte or call strlcpy() to make it a
nul-terminated stri
gcc-8 reports that we access an array with a negative index
in an error case:
drivers/gpu/ipu-v3/ipu-prg.c: In function 'ipu_prg_channel_disable':
drivers/gpu/ipu-v3/ipu-prg.c:252:43: error: array subscript -22 is below array
bounds of 'struct ipu_prg_channel[3]' [-Werror=array-bounds]
This move
https://bugs.freedesktop.org/show_bug.cgi?id=103829
Chris Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
gcc-8 -fsanitize-coverage=trace-pc produces a false-positive warning:
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c: In function
'mdp5_plane_mode_set.isra.8':
drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c:1053:3: error: 'crtc_x_r' may be used
uninitialized in this function [-Werror=maybe-uninitialized]
Hi Laurent,
Thankyou for the patch.
On 26/11/17 11:30, Laurent Pinchart wrote:
> Unlike the KMS API, the hardware doesn't support planes exceeding the
> screen boundaries or planes being located fully off-screen. We need to
> clip plane coordinates to support the use case.
>
> Fortunately the DR
On 04-12-2017 13:16, Alexey Brodkin wrote:
> Option "kmsdev" "/dev/dri/card1"
Which drm driver uses /dev/dri/card0? I'm seing drmOpen code and
if you don't specify the busID it will fallback for the first
card that matches "armada-drm" or "imx-drm" or "udl".
> But if I swap "imx-
Hi,
On Thu, 30 Nov 2017 14:14:40 +0800 Lin Huang wrote:
> Support Innolux P097PFG 9.7" 1536x2048 TFT LCD panel,
> it refactor Innolux P079ZCA panel driver, let it support
> multi panel, and add support P097PFG panel in this driver.
>
> Signed-off-by: Lin Huang
>
> ---
> drivers/gpu/drm/panel/p
Hi Laurent,
Am Montag, 4. Dezember 2017, 15:22:07 CET schrieb Laurent Pinchart:
> On Wednesday, 29 November 2017 20:47:55 EET Brian Norris wrote:
> > From: Nickey Yang
> >
> > We might include additional ports in derivative device trees, so the
> > 'port' node should have an address, and the par
This patch fixes a possible memory leak in get_pages()
Prakash Kamliya (1):
drm/msm: fix leak in failed get_pages
drivers/gpu/drm/msm/msm_gem.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
--
1.9.1
___
dri-devel mailing lis
From: Prakash Kamliya
get_pages doesn't keep a reference of the pages allocated
when it fails later in the code path. This can lead to
a memory leak. Keep reference of the allocated pages so
that it can be freed when msm_gem_free_object gets called
later during cleanup.
Signed-off-by: Prakash Ka
The omap4 CEC hardware cannot tell a Nack from a Low Drive from an
Arbitration Lost error, so just report a Nack, which is almost
certainly the reason for the error anyway.
This also simplifies the implementation. The only three interrupts
that need to be enabled are:
Transmit Buffer Full/Empty C
Hi Nickey,
Thank you for the patch.
On Wednesday, 29 November 2017 20:47:55 EET Brian Norris wrote:
> From: Nickey Yang
>
> We might include additional ports in derivative device trees, so the
> 'port' node should have an address, and the parent 'ports' node needs
> /#{addres,size}-cells.
>
>
Building the DCN 1.0 Raven display driver with CONFIG_KCOV_INSTRUMENT_ALL=y
and CONFIG_KCOV_ENABLE_COMPARISONS=y results in warnings about many functions
that do a comparison of floating-point variables:
drivers/gpu/drm/amd/display/dc/calcs/dcn_calcs.o: In function
`dcn_bw_calc_rq_dlg_ttu':
dcn_c
From: Prakash Kamliya
get_pages doesn't keep a reference of the pages allocated
when it fails later in the code path. This can lead to
a memory leak. Keep reference of the allocated pages so
that it can be freed when msm_gem_free_object gets called
later during cleanup.
Signed-off-by: Prakash Ka
This patch fixes a possible memory leak in get_pages()
Prakash Kamliya (1):
drm/msm: fix leak in failed get_pages
drivers/gpu/drm/msm/msm_gem.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
--
1.9.1
___
dri-devel mailing lis
When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.
v2: use swap
v3: check if it's really the first allocated page
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deleti
When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.
v2: use swap
v3: check if it's really the first allocated page
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deleti
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Monday, December 04, 2017 8:13 PM
To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org; He, Roger
; ckoenig.leichtzumer...@gmail.com
Subject: [PATCH 1/2] drm/ttm: swap consecutive alloca
Am 04.12.2017 um 12:51 schrieb Michel Dänzer:
On 2017-12-04 12:42 PM, Christian König wrote:
When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 8
1 file
When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.
v2: use swap
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/
When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.
v2: use swap
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_al
Quoting Dmitry Vyukov (2017-11-29 19:00:59)
> On Wed, Nov 29, 2017 at 6:21 AM, Fengguang Wu wrote:
> > Greetings,
> >
> > 0day kernel testing robot got the below dmesg and the first bad commit is
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> >
> > commit d17a1
On 2017-12-04 12:42 PM, Christian König wrote:
> When we detect consecutive allocation of pages swap them to avoid
> accidentally freeing them as huge page.
>
> Signed-off-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_page_alloc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff -
Hi Alexey,
On 04-12-2017 11:32, Alexey Brodkin wrote:
> My first [probably incorrect] assumption is Xserver requires fbdev (/dev/fbX)
> and it cannot use DRI video card natively. Is that correct?
>
>
Xserver can use DRI directly, you need to enable modesetting
driver in Xorg config or use the des
On Thu, Nov 30, 2017 at 07:23:02PM -0500, Lyude Paul wrote:
> I haven't gone to see where it started, but as of late a good number of
> pretty nasty deadlock issues have appeared with the kernel. Easy
> reproduction recipe on a laptop with i915/amdgpu prime with lockdep enabled:
>
> DRI_PRIME=1 gl
https://bugs.freedesktop.org/show_bug.cgi?id=103788
--- Comment #8 from Michel Dänzer ---
(In reply to oschowa from comment #7)
> I have a similar issue which is still present in 4.15-rc2. Though, in my
> case the system completly hangs after the screen wakes up from sleep and I
> can't even ssh
When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/tt
When we detect consecutive allocation of pages swap them to avoid
accidentally freeing them as huge page.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/
https://bugs.freedesktop.org/show_bug.cgi?id=103791
--- Comment #13 from Michel Dänzer ---
Created attachment 135923
--> https://bugs.freedesktop.org/attachment.cgi?id=135923&action=edit
drm_vblank_get debugging output
Please do the same with this patch, to see why drm_vblank_get returns -EINV
Hi Sergei,
On Monday, 4 December 2017 11:31:49 EET Sergei Shtylyov wrote:
> On 12/3/2017 1:57 PM, Laurent Pinchart wrote:
> > The structure is used in the API that the VSP1 driver exposes to the DU
> > driver. Documenting it is thus important.
> >
> > Signed-off-by: Laurent Pinchart
> >
> > ---
https://bugs.freedesktop.org/show_bug.cgi?id=104064
--- Comment #1 from taij...@posteo.de ---
Created attachment 135922
--> https://bugs.freedesktop.org/attachment.cgi?id=135922&action=edit
relevant output of #lspci -vv
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=104064
Bug ID: 104064
Summary: (DC 4.15-rc2) WARNING: CPU: 4 PID: 75 at
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu
_dm.c:601 dm_suspend+0x4e/0x60 [amdgpu]
Product: DRI
https://bugs.freedesktop.org/show_bug.cgi?id=104063
--- Comment #1 from taij...@posteo.de ---
Created attachment 135920
--> https://bugs.freedesktop.org/attachment.cgi?id=135920&action=edit
relevant output of #lspci -vv
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=104063
Bug ID: 104063
Summary: (DC 4.15-rc2) [drm:dm_logger_write [amdgpu]] *ERROR*
hwss_edp_wait_for_hpd_ready: wait timed out!
Product: DRI
Version: DRI git
Hardware: x86-64 (A
https://bugs.freedesktop.org/show_bug.cgi?id=103962
taij...@posteo.de changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=103962
--- Comment #2 from taij...@posteo.de ---
OK, 4.15-rc2 seems to have fixed this bug, not getting it anymore.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mail
https://bugs.freedesktop.org/show_bug.cgi?id=103788
--- Comment #7 from osch...@web.de ---
I have a similar issue which is still present in 4.15-rc2. Though, in my case
the system completly hangs after the screen wakes up from sleep and I can't
even ssh in and there is nothing in the logs after a
On Mon, 2017-11-27 at 16:17 -0600, Gustavo A. R. Silva wrote:
> In preparation to enabling -Wimplicit-fallthrough, mark switch cases
> where we are expecting to fall through.
I have to say I'm totally not sold on regexps matching comment
contents. Was something more explicit ever considered? Like:
https://bugs.freedesktop.org/show_bug.cgi?id=103829
--- Comment #2 from Jani Saarinen ---
Reference: https://patchwork.freedesktop.org/series/34818/
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dr
Am Mittwoch, 29. November 2017, 10:47:55 CET schrieb Brian Norris:
> From: Nickey Yang
>
> We might include additional ports in derivative device trees, so the
> 'port' node should have an address, and the parent 'ports' node needs
> /#{addres,size}-cells.
>
> v4:
> * keep #{address,size}-cells
On 03-12-2017 05:20, Nick Bowler wrote:
>
> Your patch changes things. With this applied on top of 4.15-rc1
> it is failing 100% of the time instead of only half of the time.
Ok, it was a long shot anyway.
>
> I brought the original test equipment back to the setup so I can
> see the video and p
Hi,
Am Samstag, den 02.12.2017, 12:14 + schrieb Liu, Monk:
> I'm wondering if GPU reset still work after this home move ...
Why wouldn't it continue to work? After all this is just a code move
that doesn't change anything about the inner workings of the scheduler.
Regards,
Lucas
>
> -O
1 - 100 of 121 matches
Mail list logo