+ Ville to comment if the removed code loses some meaningful comments
or not. I already went through the code doing consolidations, about a
year ago, so I may be blind to it.
On Wed, 2017-11-22 at 21:19 +, Matthew Auld wrote:
> We duplicate the stolen discovery code in early-quirks and in i915
https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #41 from Robert Liu ---
So far, setting max_sclk to 6 and max_mclk to 8, the system passed a
24hours burn-in test (vblank_mode=0 DRI_PRIME=1 glmark2 --run-forever).
Another issue found is when removing the adapter, the syste
On Thu, Nov 23, 2017 at 10:09:25PM +0100, Rainer Fiebig wrote:
> Rainer Fiebig wrote:
> > Maarten Lankhorst wrote:
> >> Op 20-11-17 om 09:51 schreef Rainer Fiebig:
> >>> Jani Nikula wrote:
> On Sun, 19 Nov 2017, Greg KH wrote:
> > On Sun, Nov 19, 2017 at 01:44:06PM +0100, Rainer Fiebig wr
Hi Linus,
This is an incremental pull on top of yesterdays, it contains all of that,
Summary from first pull:
This is just some bits and pieces for the second half of the merge window,
1. Remove the MSM dt-bindings file Rob managed to push in the previous pull.
2. Add a property/edid quirk to de
https://bugs.freedesktop.org/show_bug.cgi?id=103874
Bug ID: 103874
Summary: The Witcher 3: flickering regression with radeonsi
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on next-20171122]
[cannot apply to v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.
Hi all,
FIXME: Add owner of second tree to To:
Add author(s)/SOB of conflicting commits.
Today's linux-next merge of the drm tree got a conflict in:
drivers/gpu/drm/tilcdc/tilcdc_slave_compat.c
between commits:
0290c4ca2536 ("of: overlay: rename identifiers to more reflect what they
On Thu, Nov 23, 2017 at 2:49 PM, Nicolas Dechesne
wrote:
> * some a5xx files were missing
> * fixup for an existing typo
>
> Signed-off-by: Nicolas Dechesne
Thanks
Reviewed-by: Rob Clark
> ---
> drivers/gpu/drm/msm/adreno/adreno_device.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 dele
Hi Roger,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20171122]
[cannot apply to v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0d
Hi Jordan,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robclark/msm-next]
[also build test ERROR on next-20171122]
[cannot apply to v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.
Hi Roger,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm/drm-next]
[also build test WARNING on next-20171122]
[cannot apply to v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://githu
On Thu, Nov 23, 2017 at 2:09 PM, Ville Syrjälä
wrote:
> On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote:
>> We need to shift the values up, otherwise we'd end up with a negative
>> shift. This works for up-to 16-bit components, which is fine for now.
>
> Shouldn't we actually replicate
Hi Tobias,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on next-20171122]
[cannot apply to drm-exynos/exynos-drm/for-next v4.14 v4.14-rc8 v4.14-rc7 v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
htt
Hi Roger,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm/drm-next]
[also build test ERROR on next-20171122]
[cannot apply to v4.14]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0d
https://bugs.freedesktop.org/show_bug.cgi?id=103850
--- Comment #5 from yunt...@gmail.com ---
(In reply to Michel Dänzer from comment #2)
> Looks like there might be memory corruption, can you run one of these games
> in valgrind and attach the output from valgrind?
Valgrind output attached. Look
* some a5xx files were missing
* fixup for an existing typo
Signed-off-by: Nicolas Dechesne
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_dev
https://bugs.freedesktop.org/show_bug.cgi?id=103850
--- Comment #3 from yunt...@gmail.com ---
Created attachment 135687
--> https://bugs.freedesktop.org/attachment.cgi?id=135687&action=edit
Quern - valgrind output
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=103850
--- Comment #4 from yunt...@gmail.com ---
Created attachment 135688
--> https://bugs.freedesktop.org/attachment.cgi?id=135688&action=edit
Unturned - valgrind output
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Dave,
drm-misc-next-fixes-2017-11-23:
Fix crtc_id in page_flip event.
One tiny uapi fix, cc: stable, for a small oversight. Shouldn't matter
much since we added this for atomic, but yay for OCD and making igt happy
:-)
Cheers, Daniel
The following changes since commit f150891fd9878ef0d9197c4
https://bugs.freedesktop.org/show_bug.cgi?id=103863
Benjamin Bellec changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|NEW
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.13
head: 59aa856b7672d465443305a3fd7a6956f9567ea6
commit: b3be11d6288525da016bec7d50a11476d6ff1089 [2023/2065] drm/amdgpu: Fix
for amd_pm_funcs moved to struct amd_powerplay
config: i386-allyesconfig (attached as .config)
On Thu, Nov 23, 2017 at 01:59:28PM -0500, Ilia Mirkin wrote:
> We need to shift the values up, otherwise we'd end up with a negative
> shift. This works for up-to 16-bit components, which is fine for now.
Shouldn't we actually replicate the high bits in the low bits?
>
> Signed-off-by: Ilia Mirk
From: Ville Syrjälä
Move the plane clip rectangle handling into
drm_atomic_helper_check_plane_state(). Drivers no longer
have to worry about such mundane details.
Cc: Laurent Pinchart
Cc: Daniel Vetter
Suggested-by: Daniel Vetter
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/arm/hdlcd_cr
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.
Once everyone agrees on this we can move the clip handling into
drm_atom
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also p
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also p
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also p
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also p
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.
Once everyone agrees on this we can move the clip handling into
drm_atom
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.
Once everyone agrees on this we can move the clip handling into
drm_atom
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes as the code already uses crtc_state->mode
to populate the clip, which is also what drm_mode_get_hv_timing()
uses.
Once everyone agrees on this we can move the clip handling into
drm_atom
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
No functional changes since pipe_src_w/h are already filled via
drm_mode_get_hv_timing().
Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().
Cc: Laurent Pin
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also p
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also p
From: Ville Syrjälä
This series first unifies all users of drm_atomic_helper_check_plane_state()
to populate the clip rectangle with drm_mode_get_hv_timing(), and once
everything is unified the clip rectangle handling is sucked into
drm_atomic_helper_check_plane_state() away from driver code.
En
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also p
From: Ville Syrjälä
Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.
Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also p
From: Ville Syrjälä
In order to guarantee that pipe_src_w/h matches the user mode h/vdisplay
we must not adjust pipe_src_w to accommodate double wide/dual link.
Instead just reject the mode outright.
This will allows us to rely on crtc_state->mode for plane clipping.
Cc: Laurent Pinchart
Signe
We need to shift the values up, otherwise we'd end up with a negative
shift. This works for up-to 16-bit components, which is fine for now.
Signed-off-by: Ilia Mirkin
---
tests/util/pattern.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/tests/util/pattern.c
tree: git://people.freedesktop.org/~agd5f/linux.git amd-mainline-dkms-4.13
head: 59aa856b7672d465443305a3fd7a6956f9567ea6
commit: 9c2014d08693830897cad6bbd359d905825d8a18 [2016/2065] drm/amd/powerplay:
add CI asics support to smumgr
config: i386-allyesconfig (attached as .config)
compiler: gcc
https://bugs.freedesktop.org/show_bug.cgi?id=103863
--- Comment #3 from Jordan L ---
Hi Benjamin,
Do you have a full dmesg log?
Also, would you be able to try with a different cable? It looks like a link
training failure.
Thanks
--
You are receiving this mail because:
You are the assignee fo
On Thu, Nov 23, 2017 at 10:09 AM, Nicolas Dechesne
wrote:
> On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark wrote:
>> On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne
>> wrote:
>>> The preferred location for Adreno firmware files is now in qcom/ subfolder,
>>> especially now that we are adding some
On Thu, Nov 23, 2017 at 12:09 PM, Ben Hutchings wrote:
> On Thu, 2017-11-23 at 16:09 +0100, Nicolas Dechesne wrote:
>> On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark wrote:
>> > On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne
>> > wrote:
>> > > The preferred location for Adreno firmware files is n
On Thu, 2017-11-23 at 16:09 +0100, Nicolas Dechesne wrote:
> On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark wrote:
> > On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne
> > wrote:
> > > The preferred location for Adreno firmware files is now in qcom/
> > > subfolder,
> > > especially now that we are
Hi,
On 23-11-17 17:14, Christian König wrote:
I missed this driver because it is in the staging area.
Signed-off-by: Christian König
Thank you, looks good to me.
Can you please re-send this with Greh KH (the staging maintainer)
added in the To: list and my:
Reviewed-by: Hans de Goede
Add
I missed this driver because it is in the staging area.
Signed-off-by: Christian König
---
drivers/staging/vboxvideo/vbox_ttm.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_ttm.c
b/drivers/staging/vboxvideo/vbox_ttm.c
inde
On Thu, Nov 23, 2017 at 04:56:56PM +0800, Tina Zhang wrote:
> The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in
> windows. The float format in each component is 1:5:10 MSb-sign:exponent:
> fraction.
>
> This patch is to introduce the format to drm, so that the windows guest's
On Thu, Nov 23, 2017 at 3:54 PM, Rob Clark wrote:
> On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne
> wrote:
>> The preferred location for Adreno firmware files is now in qcom/ subfolder,
>> especially now that we are adding some of them in linux-firmware.
>>
>> Reported-by: Ben Hutchings
>> S
Hi Jan,
On Thu, Nov 23, 2017 at 10:55 AM, Jan Tuerk wrote:
> The Emerging Display Technology ETM0700G0BDH6 is exactly
> the same display as the ETM0700G0DH6, exept the pixelclock
> polarity. Therefore re-use the ETM0700G0DH6 modes. It is
> used by default on emtrion Avari based development kits.
On Thu, Nov 23, 2017 at 5:32 AM, Nicolas Dechesne
wrote:
> The preferred location for Adreno firmware files is now in qcom/ subfolder,
> especially now that we are adding some of them in linux-firmware.
>
> Reported-by: Ben Hutchings
> Signed-off-by: Nicolas Dechesne
Thanks, I was wondering if
If an interlaced video mode is selected, a IOMMU pagefault is
triggered by vp_video_buffer().
Fix the most apparent bugs:
- pitch value for chroma plane
- divide by two of height and vpos
This is more like a band-aid at this point. The VP plane is
still corrupted, but at least there are no more p
Please disregard this one, need to rebase. v2 in a minute...
- Tobias
Tobias Jakobi wrote:
> If an interlaced video mode is selected, a IOMMU pagefault is
> triggered by vp_video_buffer().
>
> Fix the most apparent bugs:
> - pitch value for chroma plane
> - divide by two of height and vpos
>
>
If an interlaced video mode is selected, a IOMMU pagefault is
triggered by vp_video_buffer().
Fix the most apparent bugs:
- pitch value for chroma plane
- divide by two of height and vpos
This is more like a band-aid at this point. The VP plane is
still corrupted, but at least there are no more p
This was implemented correctly only on the atomic ioctl before, but
it should really be working on all 3 ioctl's involved, so ensure we
always set crtc_id correctly with a testcase.
Signed-off-by: Maarten Lankhorst
---
tests/kms_vblank.c | 60 ++---
Inki Dae wrote:
>
>
> 2017년 11월 22일 22:14에 Marek Szyprowski 이(가) 쓴 글:
>> When no IOMMU is available, all GEM buffers allocated by Exynos DRM driver
>> are contiguous, because of the underlying dma_alloc_attrs() function
>> provides only such buffers. In such case it makes no sense to keep
>> BO_N
I'm juggling too many things, and drm-misc maintenance is one that I
keep dropping on the floor. Admit reality and remove myself as
maintainer. This still leaves us with a nice team of three who are
actually doing the drm-misc work, while I focus on drm-intel.
Cc: Daniel Vetter
Cc: Gustavo Padova
On 11/21/17 16:27, Ville Syrjälä wrote:
> On Mon, Nov 20, 2017 at 04:02:14PM +0100, Hans Verkuil wrote:
>> On 11/20/2017 03:51 PM, Ville Syrjälä wrote:
>>> On Mon, Nov 20, 2017 at 02:41:28PM +0100, Hans Verkuil wrote:
From: Hans Verkuil
Some devices (Windows Intel driver!) send a Ve
From: Colin Ian King
The assignment of height to itself is redundant and can be removed.
Detected with Coccinelle.
Signed-off-by: Colin Ian King
---
drivers/video/fbdev/vga16fb.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/fbdev/vga16fb.c b/drivers/video/fbdev/vga16fb.c
in
Hello Vasyl,
On 22 November 2017 at 20:52, Vasyl Gomonovych wrote:
> NULL check before some freeing functions is not needed.
> drivers/dma-buf/dma-buf.c:1183:2-26: WARNING: NULL check before freeing
> debugfs_remove_recursive
> Generated by: scripts/coccinelle/free/ifnullfree.cocci
Thank you fo
We added crtc_id to the atomic ioctl, but forgot to add it for vblank
and page flip events. Commit bd386e518056 ("drm: Reorganize
drm_pending_event to support future event types [v2]") added it to
the vblank event, but page flip event was still missing.
Correct this and add a test for making sure
The preferred location for Adreno firmware files is now in qcom/ subfolder,
especially now that we are adding some of them in linux-firmware.
Reported-by: Ben Hutchings
Signed-off-by: Nicolas Dechesne
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 16
1 file changed, 8 insert
Hi Ville,
On Monday, 20 November 2017 21:36:46 EET Ville Syrjälä wrote:
> On Mon, Nov 20, 2017 at 09:32:56AM -0800, Sinclair Yeh wrote:
> > On Mon, Nov 20, 2017 at 08:34:50AM +0100, Daniel Vetter wrote:
> >> On Fri, Nov 10, 2017 at 11:42:59PM +0200, Ville Syrjälä wrote:
> >>> On Fri, Nov 10, 2017
Hi Ville,
Thank you for the patch.
On Wednesday, 1 November 2017 20:29:17 EET Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Atomic drivers have no reason to use drm_plane_helper_check_update()
> instead of drm_plane_helper_check_state(). So let's switch over.
>
> Cc: VMware Graphics
> Cc: Si
Hi Ville,
Thank you for the patch.
On Wednesday, 1 November 2017 20:29:16 EET Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Throw away the bugs crtc coords vs. fb size check. Crtc coords don't
> define the viewport inside the fb, that's a job for the src coords,
> which have been checked by th
Hi Ville,
Thank you for the patch.
On Wednesday, 1 November 2017 20:29:20 EET Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_plane_helper_check_update() isn't a transitional helper, so let's
> rename it to drm_atomic_helper_check_plane_state() and move it into
> drm_atomic_helper.c.
>
> Cc
Hi Ville,
Thank you for the patch.
On Wednesday, 1 November 2017 20:29:19 EET Ville Syrjala wrote:
> From: Ville Syrjälä
>
> drm_plane_helper_check_state() is supposed to do things the atomic way,
> so it should not be inspecting crtc->enabled. Rather we should be
> looking at crtc_state->enabl
Hi Ville,
On Monday, 6 November 2017 20:04:38 EET Ville Syrjälä wrote:
> On Thu, Nov 02, 2017 at 03:19:30PM +0200, Ville Syrjälä wrote:
> > On Thu, Nov 02, 2017 at 11:12:09AM +0100, Daniel Vetter wrote:
> >> On Wed, Nov 01, 2017 at 08:29:18PM +0200, Ville Syrjala wrote:
> >>> From: Ville Syrjälä
https://bugs.freedesktop.org/show_bug.cgi?id=103863
Michel Dänzer changed:
What|Removed |Added
Component|Driver/AMDgpu |DRM/AMDgpu
QA Contact|xorg-t...
Hi Dave, some early fixes for v4.15 and stable.
BR,
Jani.
The following changes since commit e8c49fa96838101435b9e4884d49b30da7a4e0c6:
drm/i915: Reorder context-close to avoid calling i915_vma_close() under RCU
(2017-11-09 16:18:37 +0200)
are available in the git repository at:
git://ano
On Tue, 2017-11-21 at 23:31 +0100, Vasyl Gomonovych wrote:
> Use ERR_CAST inlined function instead of ERR_PTR(PTR_ERR(...)).
>
> drivers/gpu/drm/mediatek/mtk_drm_gem.c:223:9-16: WARNING: ERR_CAST can be
> used with mtk_gem
> Generated by: scripts/coccinelle/api/err_cast.cocci
>
> Signed-off-by:
On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> Use the MFD device for SoC mt8173. Probing via devicetree
> is no longer needed for any SoC, so delete it.
>
> Signed-off-by: Matthias Brugger
Apart from the mmsys_private issue noted in previous patches,
Reviewed-by: Philipp Zabel
On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> Add devices for the mt8173 SoC.
>
> Signed-off-by: Matthias Brugger
Reviewed-by: Philipp Zabel
regards
Philipp
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freed
On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> With the mtk-mmsys MFD device in place, we switch the probing for
> mt2701 from device-tree to mfd.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 32 +---
> 1 file chan
Hi Matthias,
On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> The MMSYS subsystem includes clocks and drm components.
> This patch adds a MFD device to probe both drivers from the same
> device tree compatible.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/mfd/Kconfig |
Hi, Matthias:
On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> The MMSYS subsystem includes clocks and drm components.
> This patch adds a MFD device to probe both drivers from the same
> device tree compatible.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/mfd/Kconfig |
The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in
windows. The float format in each component is 1:5:10 MSb-sign:exponent:
fraction.
This patch is to introduce the format to drm, so that the windows guest's
framebuffer in this kind of format can be recognized and used by linu
https://bugs.freedesktop.org/show_bug.cgi?id=103850
--- Comment #2 from Michel Dänzer ---
Looks like there might be memory corruption, can you run one of these games in
valgrind and attach the output from valgrind?
--
You are receiving this mail because:
You are the assignee for the bug.___
This patch is from "[PATCH v19 0/6] drm/i915/gvt: Dma-buf support for GVT-g":
https://lists.freedesktop.org/archives/intel-gvt-dev/2017-November/002508.html
The RGB 64-bit 16:16:16:16 float pixel format is needed by some Apps in
windows. The float format in each component is 1:5:10 MSb-sign:expone
https://bugs.freedesktop.org/show_bug.cgi?id=100745
--- Comment #9 from Michel Dänzer ---
(In reply to Benjamin Bellec from comment #8)
> I hit the same problem today after enabling amdgpu.dc=1
> The screen doesn't light up at all if I boot the kernel with amdgpu.dc=1
AFAICT this report is about
Hi Matthias,
On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> The mmsys memory space is shared between the drm and the
> clk driver. Use regmap to access it.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 ++--
> drivers/gpu/drm/mediatek/mtk
https://bugs.freedesktop.org/show_bug.cgi?id=100745
Michel Dänzer changed:
What|Removed |Added
Attachment #130957|text/x-log |text/plain
mime type|
Hi, Matthias:
On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> Use the MFD device for SoC mt8173. Probing via devicetree
> is no longer needed for any SoC, so delete it.
>
> Signed-off-by: Matthias Brugger
Acked-by: CK Hu
> ---
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 28 ++
Hi, Matthias:
On Thu, 2017-11-23 at 09:30 +0100, Matthias Brugger wrote:
>
> On 11/23/2017 06:48 AM, CK Hu wrote:
> > Hi, Matthias:
> >
> > On Tue, 2017-11-14 at 22:41 +0100, Matthias Brugger wrote:
> >> With the mtk-mmsys MFD device in place, we switch the probing for
> >> mt2701 from device-tr
On 11/22/2017 5:49 PM, Sinan Kaya wrote:
> static int i915_get_bridge_dev(struct drm_i915_private *dev_priv)
> {
> - dev_priv->bridge_dev = pci_get_bus_and_slot(0, PCI_DEVFN(0, 0));
> + u32 domain = pci_domain_nr(dev_priv->drm.pdev->bus);
I'll convert domain type to int on the next versi
NULL check before some freeing functions is not needed.
drivers/dma-buf/dma-buf.c:1183:2-26: WARNING: NULL check before freeing
debugfs_remove_recursive
Generated by: scripts/coccinelle/free/ifnullfree.cocci
Signed-off-by: Vasyl Gomonovych
---
drivers/dma-buf/dma-buf.c | 3 +--
1 file changed,
Hi Boris,
> Boris Brezillon hat am 22. November 2017
> um 18:51 geschrieben:
>
>
> Hi Stefan,
>
> On Wed, 22 Nov 2017 17:43:35 +0100 (CET)
> Stefan Wahren wrote:
> ...
>
> Looks like I didn't test this code with CONFIG_REFCOUNT_FULL enabled :-/.
>
> Anyway, can you try to apply the followi
On 11/22/2017 05:09 AM, Christian König wrote:
> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:
>> On 11/21/2017 08:34 AM, Christian König wrote:
>>> Hi Boris,
>>>
>>> attached are two patches.
>>>
>>> The first one is a trivial fix for the infinite loop issue, it now
>>> correctly aborts the fixu
Hi Boris,
if i boot Raspberry Pi 3 (ARM64, defconfig, linux-next-20171122) with
sufficient CMA memory (32 MB), i'll get this warning during boot:
[7.623510] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
[7.632453] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Extract the domain numb
pci_get_bus_and_slot() is restrictive such that it assumes domain=0 as
where a PCI device is present. This restricts the device drivers to be
reused for other domain numbers.
Getting ready to remove pci_get_bus_and_slot() function in favor of
pci_get_domain_bus_and_slot().
Replace pci_get_bus_and
On 11/22/2017 11:54 AM, Christian König wrote:
> Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
>> On 11/22/2017 05:09 AM, Christian König wrote:
>>> Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:
On 11/21/2017 08:34 AM, Christian König wrote:
> Hi Boris,
>
> attached are two pat
Fixes the following enum conversion warning:
drivers/gpu/drm/i915/intel_ddi.c:1481:30: error: implicit conversion
from enumeration type 'enum port' to different enumeration type 'enum
intel_dpll_id' [-Werror,-Wenum-conversion]
enum intel_dpll_id pll_id = port;
~~
On Tue, Nov 21, 2017 at 05:55:29PM +, Emil Velikov wrote:
>On 21 November 2017 at 15:07, wrote:
>> On Mon, Nov 20, 2017 at 11:21:52AM +, Emil Velikov wrote:
>>> - Document the autoselect process
>>>Information about about What, Why, and [ideally] How - analogous to
>>>the normal stable no
The 4.15 vmwgfx driver shows a warning during boot (32 bit x86)
It is caused by a mismatch between the result of vmw_enable_vblank() and
what the drm_atomic_helper expects:
/...
ret = drm_crtc_vblank_get(crtc);
WARN_ONCE(ret != -EINVAL, "driver forgot to call
drm_crtc_vblank_off()\n");
* Joonas Lahtinen wrote:
> + Dave as a heads-up
>
> On Thu, 2017-11-23 at 07:17 +0100, Ingo Molnar wrote:
> > * Matthew Auld wrote:
> >
> > > We duplicate the stolen discovery code in early-quirks and in i915,
> > > however if we just export the region as a resource from early-quirks we
> > >
Use vma_pages function on vma object instead of explicit computation.
./drivers/gpu/drm/rockchip/rockchip_drm_gem.c:223:34-40: WARNING: Consider
using vma_pages helper on vma
Generated by: scripts/coccinelle/api/vma_pages.cocci
Signed-off-by: Vasyl Gomonovych
---
drivers/gpu/drm/rockchip/rockch
* Matthew Auld wrote:
> We duplicate the stolen discovery code in early-quirks and in i915,
> however if we just export the region as a resource from early-quirks we
> can nuke the duplication.
>
> Suggested-by: Joonas Lahtinen
> Suggested-by: Chris Wilson
> Signed-off-by: Matthew Auld
> Cc:
On Wed, 22 Nov 2017 16:13:31 -0800
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > On Wed, 22 Nov 2017 13:16:08 -0800
> > Eric Anholt wrote:
> >
> >> Boris Brezillon writes:
> >>
> >> > With CONFIG_REFCOUNT_FULL enabled, refcount_inc() complains when it's
> >> > passed a refcount obje
Am 23.11.2017 um 03:41 schrieb Dave Airlie:
From: Dave Airlie
The commit below introduced thp support for ttm allocations, however it didn't
take into account the case where dma32 was requested. Some drivers always
request
dma32, and the bochs driver is one of those.
This fixes an oops:
[
Am 22.11.2017 um 18:27 schrieb Boris Ostrovsky:
On 11/22/2017 11:54 AM, Christian König wrote:
Am 22.11.2017 um 17:24 schrieb Boris Ostrovsky:
On 11/22/2017 05:09 AM, Christian König wrote:
Am 21.11.2017 um 23:26 schrieb Boris Ostrovsky:
On 11/21/2017 08:34 AM, Christian König wrote:
Hi Bori
1 - 100 of 101 matches
Mail list logo
