What about
"Enable recursive locking at swapout time to make it possible to swap
out BOs that share the same reservation object."
Is "per VM BOs" an AMD specific name? In that case, I'd avoid using it
in the TTM code since most people have no idea what they are and why the
need specific tre
Quoting Dave Airlie (2017-12-21 02:42:56)
> > @@ -494,12 +473,11 @@ static int drm_syncobj_fd_to_handle(struct drm_file
> > *file_private,
> > spin_unlock(&file_private->syncobj_table_lock);
> > idr_preload_end();
> >
> > - if (ret < 0) {
> > - fput(syncobj->fil
On 12/20/2017 11:35 AM, Roger He wrote:
extract this function since eviction and swapout share same logic
But it's only used in eviction?
Change-Id: I80a475a93fceed8d66d74a1832c815a0756341ac
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 29 +++--
1 fi
Roger,
5 out of 7 patches in this series are completely lacking a commit log
message, and thats not OK. Really.
https://www.kernel.org/doc/html/v4.12/process/submitting-patches.html#describe-your-changes
I'll review these, but IIRC the no_wait in the memory accounting code is
different in th
https://bugzilla.kernel.org/show_bug.cgi?id=198221
--- Comment #3 from Petr Vandrovec (p...@vandrovec.name) ---
Created attachment 261285
--> https://bugzilla.kernel.org/attachment.cgi?id=261285&action=edit
Bandaid to prevent processing of works not fully set up
I've attached bandaid that seems
Patch bd36d3bab2e3d08f80766c86487090dbceed4651 fixed a deadlock in the
failure path of drm_lease_create. This made the partially initialized
lease object visible for a short window of time.
To avoid having the lessee state appear transiently, I've rearranged
the code so that the lessor fields are
On Wed, 20 Dec 2017, Dhinakaran Pandiyan wrote:
> Occasionally there are LINK_ADDRESS sideband messages timing out with the
> Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
> failures lead to the display not coming up on boot. Power cycling the port
> corresponding to t
Occasionally there are LINK_ADDRESS sideband messages timing out with the
Lenovo MST dock + Dell MST monitor(w/ in-built branch) setup I have. These
failures lead to the display not coming up on boot. Power cycling the port
corresponding to the MST monitor's branch device and resending the message
These ioctls replace drmWaitVBlank and add ns time resolution and
64-bit sequence numbers to comply with the Vulkan API specifications.
The tests were derived from the existing kms_vblank tests with the
'wait' variant elided as the new API doesn't provide a mechanism for
blocking in the kernel.
v
Both of these APIs are now in the kernel; it would be nice to have the
tests integrated into the test suite.
This includes an updated version of the kms_lease patch (v3) which
adapts to the final kernel API changes.
___
dri-devel mailing list
dri-devel@
Validate that the leasing API creates leases that allow access to a
subset of the available resources and that lease revocation works.
v2: from Dave Airlie
* Update ioctl numbers to latest proposed values.
* Fix commit message
* Add tests for get_lease and list_lessees
v3: adapt to final ker
With the addition of "private_objs" in drm_atomic_state, we no longer
need to subclass drm_atomic_state to store state of share resources
that don't perfectly fit within planes/crtc/connector state information.
We can now save this state within drm_atomic_state itself using
the private objects.
Re
Global shared resources (hwpipes, hwmixers and SMP) for MDP5 are
implemented as a part of atomic state by subclassing drm_atomic_state.
The preferred approach is to use the drm_private_obj infrastructure
available in the atomic core.
mdp5_global_state is introduced as a drm atomic private object.
It's been recommended that we use drm_private_objs embedded in
drm_atomic_state to hold shared resources instead of subclassing
drm_atomic_state.
This will also help us in getting one step closer to using the
atomic commit helpers instead of the msm_atomic_commit() funcs
in msm_atomic.c
I've take
This replaces the usage of the subclassed atomic state (mdp5_state)
with a private_obj state embedded within drm_atomic_state. The latter
method is the preferred approach, since it's simpler to implement
and less prone to errors.
The new API replaces the older and equivalent mdp5_state usage in th
-Original Message-
From: Christian König [mailto:ckoenig.leichtzumer...@gmail.com]
Sent: Wednesday, December 20, 2017 9:36 PM
To: He, Roger ; amd-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org
Subject: Re: [PATCH 3/7] drm/ttm: use an operation ctx for
ttm_mem_global_alloc_p
Hi all,
Commits
bb5cdf8d1c76 ("drm: omapdrm: Remove filename from header and fix copyright
tag")
d66c36a3ee79 ("drm: omapdrm: Simplify platform registration")
are missing a Signed-off-by from their committer.
--
Cheers,
Stephen Rothwell
___
dri-
https://bugzilla.kernel.org/show_bug.cgi?id=198221
Petr Vandrovec (p...@vandrovec.name) changed:
What|Removed |Added
Regression|No |Yes
--- Comment #2
> @@ -494,12 +473,11 @@ static int drm_syncobj_fd_to_handle(struct drm_file
> *file_private,
> spin_unlock(&file_private->syncobj_table_lock);
> idr_preload_end();
>
> - if (ret < 0) {
> - fput(syncobj->file);
> - return ret;
> - }
> -
https://bugzilla.kernel.org/show_bug.cgi?id=198221
Ilia Mirkin (imir...@alum.mit.edu) changed:
What|Removed |Added
CC||imir...@alum.mit.edu
On Wed, Dec 20, 2017 at 6:22 PM, Kristian Kristensen
wrote:
> On Wed, Dec 20, 2017 at 12:41 PM, Miguel Angel Vico
> wrote:
>> On Wed, 20 Dec 2017 11:54:10 -0800
>> Kristian Høgsberg wrote:
>> > I'd like to see concrete examples of actual display controllers
>> > supporting more format layouts th
https://bugzilla.kernel.org/show_bug.cgi?id=198221
Bug ID: 198221
Summary: nouveau DRM driver scheduling invalid work
Product: Drivers
Version: 2.5
Kernel Version: 4.15.0-rc3
Hardware: All
OS: Linux
Tree: Main
On Tue, 2017-12-19 at 10:15 -0800, Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_RO where possible.
>
> Done with perl script:
>
> $ git grep -w --name-only DEVICE_ATTR | \
> xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IRUGO\s*|\s*0444
On Tue, 2017-12-19 at 10:15 -0800, Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
>
> Done with perl script:
>
> $ git grep -w --name-only DEVICE_ATTR | \
> xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(\s*S_IRUGO\s*\|\s*S_IWU
https://bugs.freedesktop.org/show_bug.cgi?id=104248
--- Comment #3 from Harry Wentland ---
I'm working on fixing DVI on DC with timings requiring dual link, like I assume
your 120+ Hz timings require. That work is tracked under
https://bugs.freedesktop.org/show_bug.cgi?id=103953.
--
You are rec
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #17 from Andrew ---
Harry,
On rc2 i had this message , but i also saw terminals(init3)
On rc3 i didnt see this message, but i didnt see terminals either.
The new kernel version was the only change on the system.
On Dec 20, 2017 1
The discussion sounds similar as well - related to load_lut() not being called.
Perhaps after the drm-next-4.14 merge, whatever call stack used to cause
load_lut to always get called is now gone. Even if FB_VISUAL_TRUECOLOR doesn't
support a clut, some hardware may still need a default gamma lut
https://bugs.freedesktop.org/show_bug.cgi?id=104206
--- Comment #16 from Harry Wentland ---
Do I understand it correctly that the issue is resolved other than the error
message on cold boot?
That error message is logged erroneously. The fix for the wrong error log is in
the pipeline and should l
On Fri, Dec 1, 2017 at 5:16 PM, Linus Walleij wrote:
> This adds support for the Ilitek ILI9322 QVGA (320x240)
> TFT panel driver.
>
> This panel driver supports serial or parallel RGB or
> YUV input and also ITU-T BT.656 input streams.
>
> The controller is combined with a physical panel and
> c
https://bugs.freedesktop.org/show_bug.cgi?id=94973
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=104205
--- Comment #6 from Bret Towe ---
maybe it wasn't clear but I tested rc3 with those options and it still has the
issue
--
You are receiving this mail because:
You are the assignee for the bug.___
dri
https://bugs.freedesktop.org/show_bug.cgi?id=104205
--- Comment #5 from Harry Wentland ---
Do you have a chance to try enabling the two config options Michel mentioned
and see if this changes things? We have a new display driver in 4.15 (AMD_DC)
that could very well make a difference here.
--
Y
This looks similar to this bug that I spotted while finally going through my
large dri-devel backlog: https://bugzilla.kernel.org/show_bug.cgi?id=198123
The discussion continues here
https://lists.freedesktop.org/archives/dri-devel/2017-December/160667.html
Not sure if this is related but the s
On Thu, Dec 21, 2017 at 12:05:40AM +0300, Dmitry Osipenko wrote:
> On 20.12.2017 23:16, Thierry Reding wrote:
> > On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote:
> >> On 20.12.2017 21:01, Thierry Reding wrote:
> >>> On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
>
https://bugs.freedesktop.org/show_bug.cgi?id=94973
--- Comment #3 from Jay Cornwall ---
I think it got fixed a while ago. I'm running upstream with no changes/module
parameters.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=104345
--- Comment #5 from bernhardu ---
Created attachment 136336
--> https://bugs.freedesktop.org/attachment.cgi?id=136336&action=edit
vdpauinfo
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=104345
--- Comment #4 from bernhardu ---
Created attachment 136335
--> https://bugs.freedesktop.org/attachment.cgi?id=136335&action=edit
glxinfo
Sorry for the delay.
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Dave,
More stuff for 4.16:
- Further radeon cleanup after dropping kfd support
- Fix S3 on raven
- Further GPU reset clean ups and fixes
- Move the amd gpu scheduler into common code so it can be shared
with other drivers, notably etnaviv
- Various ttm fixes
- Support for 2+1 level GPU page t
https://bugs.freedesktop.org/show_bug.cgi?id=97896
--- Comment #5 from Stefan Müller-Klieser ---
I have probably the same issue on 4.14.5. My setup works fine with Redmond OS.
This thread helped me to find the workaround under Linux with radeon.audio=0.
One additional information about the issue:
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #21 from Alex Deucher ---
Can you post a video of the flickering? The one linked above no longer works.
Is it like tearing or does the display go blank or unstable image?
--
You are receiving this mail because:
You are the assigne
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #20 from Harry Wentland ---
Looks like some guys more familiar with the power profiles should take a peek
at this. Not really familiar with that myself.
--
You are receiving this mail because:
You are the assignee for the bug._
On Wed, Dec 20, 2017 at 06:46:12PM +0300, Dmitry Osipenko wrote:
> Older Tegra's do not support RGBA format for the cursor, but instead
> overlay plane could be used for it. Since there is no much use for the
> overlays on a regular desktop and HW-accelerated cursor is much nicer
> than the jerky S
On Wed, Dec 20, 2017 at 06:46:14PM +0300, Dmitry Osipenko wrote:
> host1x_syncpt_wait() takes timeout value in jiffies, but DRM passes it in
> milliseconds.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/drm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Applied,
On Wed, Dec 20, 2017 at 06:46:13PM +0300, Dmitry Osipenko wrote:
> iommu_map_sg() doesn't return a error value, but a size of the requested
> IOMMU mapping or zero in case of error.
>
> Signed-off-by: Dmitry Osipenko
> ---
> drivers/gpu/drm/tegra/gem.c | 15 +++
> 1 file changed, 7 i
On Wed, Dec 20, 2017 at 06:46:10PM +0300, Dmitry Osipenko wrote:
> HW reset isn't actually broken on Tegra20, but there is a dependency on
> first display controller to be taken out of reset for the second to be
> enabled successfully.
>
> Signed-off-by: Dmitry Osipenko
> ---
>
> Change log:
>
On Wed, Dec 20, 2017 at 11:01:49PM +0300, Dmitry Osipenko wrote:
> On 20.12.2017 21:01, Thierry Reding wrote:
> > On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
> >> Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats") broke
> >> DRM's MODE_ADDFB IOCTL on Tegra20/30, b
Am 20.12.2017 um 20:43 schrieb Daniel Vetter:
On Wed, Dec 20, 2017 at 6:20 PM, Li, Samuel wrote:
Ping... can someone please review this patch?
Might be simpler to implement your own dma-buf backend instead of
going through the drm_prime midlayer. That was mostly written to give
nvidia a set of
On Wed, Dec 20, 2017 at 11:51 AM, Daniel Vetter wrote:
> Since this also involves the kernel let's add dri-devel ...
>
> On Wed, Dec 20, 2017 at 5:51 PM, Miguel Angel Vico
> wrote:
>> Hi all,
>>
>> As many of you already know, I've been working with James Jones on the
>> Generic Device Allocator
Since this also involves the kernel let's add dri-devel ...
On Wed, Dec 20, 2017 at 5:51 PM, Miguel Angel Vico wrote:
> Hi all,
>
> As many of you already know, I've been working with James Jones on the
> Generic Device Allocator project lately. He started a discussion thread
> some weeks ago see
On Wed, Dec 20, 2017 at 6:20 PM, Li, Samuel wrote:
> Ping... can someone please review this patch?
Might be simpler to implement your own dma-buf backend instead of
going through the drm_prime midlayer. That was mostly written to give
nvidia a set of non-EXPORT_GPL symbols to support dma-buf. Or
https://bugs.freedesktop.org/show_bug.cgi?id=104347
--- Comment #5 from network...@rkmail.ru ---
(In reply to Michel Dänzer from comment #2)
> can you bisect?
I think it started happening around 2-3 months ago on my RX480, so it's quite a
lot to bisect. I'd bisect myself, but I don't have polaris
https://bugs.freedesktop.org/show_bug.cgi?id=104306
--- Comment #4 from eric vz ---
Created attachment 136333
--> https://bugs.freedesktop.org/attachment.cgi?id=136333&action=edit
Bisect log
Bisect log attached. I also had to revert c4ed39f85b (which I did via
cherrypick applying b6f41e393e)t
https://bugs.freedesktop.org/show_bug.cgi?id=104306
--- Comment #3 from eric vz ---
A cycle of git bisect building leads me here:
255573996cc997cb61be9adad3e8fcaa78db5d1f is the first bad commit
commit 255573996cc997cb61be9adad3e8fcaa78db5d1f
Author: Marek Olšák
Date: Mon Oct 9 18:56:22 2017
On Tuesday, December 19, 2017 7:15:08 PM CET Joe Perches wrote:
> Convert DEVICE_ATTR uses to DEVICE_ATTR_RO where possible.
>
> Done with perl script:
>
> $ git grep -w --name-only DEVICE_ATTR | \
> xargs perl -i -e 'local $/; while (<>) {
> s/\bDEVICE_ATTR\s*\(\s*(\w+)\s*,\s*\(?(?:\s*S_IRUGO
On Mon, Dec 18, 2017 at 02:44:46PM +0100, Arnd Bergmann wrote:
> The new debugfs registration fails to build when CONFIG_DEBUGFS is
> disabled, because the drm_crtc structure is lacking a member in that
> configuration:
>
> drivers/gpu/drm/tegra/dc.c: In function 'tegra_dc_late_register':
> driver
https://bugs.freedesktop.org/show_bug.cgi?id=102130
Gašper Sedej changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=104347
--- Comment #4 from Arthur Borsboom ---
Created attachment 136330
--> https://bugs.freedesktop.org/attachment.cgi?id=136330&action=edit
glxinfo
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=94908
Alex Deucher changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=104347
--- Comment #3 from Arthur Borsboom ---
> Did this not happen with an older version of Mesa / LLVM?
I do not know, since I have recently bought this AMD videocard to get rid of
the out of kernel proprietary trouble with my previous Nvidia video
On Wed, Dec 20, 2017 at 11:32:23AM +, Guillaume Tucker wrote:
> When neither HDMI nor DP is supported such as on the tegra124, the
> sor->clk_out is not initialised and remains NULL. In this case, the
> parent clock can't be assigned to it so revert to the previous
> behaviour of assigning it
https://bugs.freedesktop.org/show_bug.cgi?id=102130
--- Comment #5 from Alex Deucher ---
Is this still an issue?
--
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=97471
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=94973
--- Comment #2 from Alex Deucher ---
Is this still an issue?
--
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=97993
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Dec 20, 2017 at 06:46:11PM +0300, Dmitry Osipenko wrote:
> Commit 7772fdaef939 ("drm/tegra: Support ARGB and ABGR formats") broke
> DRM's MODE_ADDFB IOCTL on Tegra20/30, because IOCTL uses XRGB format if
> requested FB depth is 24bpp. As a result, Xorg doesn't work anymore with
> both modes
https://bugs.freedesktop.org/show_bug.cgi?id=96866
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=104347
--- Comment #2 from Michel Dänzer ---
Please attach the corresponding glxinfo output.
Did this not happen with an older version of Mesa / LLVM? If so, can you
bisect?
--
You are receiving this mail because:
You are the assignee for the bug.__
Ping... can someone please review this patch?
Samuel Li
> -Original Message-
> From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf
> Of Samuel Li
> Sent: Friday, December 15, 2017 11:28 AM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
> Cc: Koen
https://bugs.freedesktop.org/show_bug.cgi?id=104347
--- Comment #1 from network...@rkmail.ru ---
I had the same issue with my RX480, but it does not happen on hd7950 with
amdgpu.
--
You are receiving this mail because:
You are the assignee for the bug.
On 12/20/2017 04:35 PM, Ray Strode wrote:
> Hi,
>
>> Actually, I don't want that :)
>>
>> This was a design decision that I've made to keep the code small and simple
>> to audit.
>> As it is, the simple bootsplash code will make 99% of people happy.
> You think only 1% of linux users have more th
On 12/20/2017 04:21 PM, Ray Strode wrote:
> If we've reached the scenario you're discussing above, the real
> failure is that the KMS
> driver took too long to load. DRM is the platform graphics api. If
> it's not loading
> timely enough to show graphics then that's the problem! It sounds
> like
On 12/20/2017 04:19 PM, Daniel Vetter wrote:
> On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter wrote:
>> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote:
>>> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
btw since I'm probably sounding a bit too grumpy here: I'd very much
support this.
On 12/20/2017 04:11 PM, Daniel Vetter wrote:
> So fundamentally I don't think an in-kernel bootsplash is a bad idea.
> But most likely you want this on a highly embedded system, which
> probably is compiled for your exact hw, with pretty much everything
> built in. Also, no fbcon, maybe even no vt
Hi,
> Actually, I don't want that :)
>
> This was a design decision that I've made to keep the code small and simple
> to audit.
> As it is, the simple bootsplash code will make 99% of people happy.
You think only 1% of linux users have more than one monitor or a 4k screen?
> I've made this deci
On Wed, Dec 20, 2017 at 4:19 PM, Daniel Vetter wrote:
> On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter wrote:
>> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote:
>>> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
btw since I'm probably sounding a bit too grumpy here: I'd very much
supp
Hi,
> The problem that I am stumbling upon is different:
> - the system starts with an FB driver
> - after the ShowDelay time, Plymouth opens /dev/fb0
> - the system finally loads the DRM driver, which tries to kick the previous
> FB driver
> - loading the DRM driver fails because Plymouth st
On Wed, Dec 20, 2017 at 4:11 PM, Daniel Vetter wrote:
> On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote:
>> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
>>> btw since I'm probably sounding a bit too grumpy here: I'd very much
>>> support this. I think bootsplash in kernel has a bunch of uses, a
On Wed, Dec 20, 2017 at 3:55 PM, Max Staudt wrote:
> On 12/20/2017 11:14 AM, Daniel Vetter wrote:
>> btw since I'm probably sounding a bit too grumpy here: I'd very much
>> support this. I think bootsplash in kernel has a bunch of uses, and it
>> shouldn't be hard to get non-suse people to cheer f
On 12/20/2017 11:14 AM, Daniel Vetter wrote:
> btw since I'm probably sounding a bit too grumpy here: I'd very much
> support this. I think bootsplash in kernel has a bunch of uses, and it
> shouldn't be hard to get non-suse people to cheer for it (makes merging
> easier if it's not just a one-off
https://bugs.freedesktop.org/show_bug.cgi?id=104275
--- Comment #9 from Harry Wentland ---
Created attachment 136321
--> https://bugs.freedesktop.org/attachment.cgi?id=136321&action=edit
DC scatter gather patch
You'll need this DC patch.
--
You are receiving this mail because:
You are the as
Am 20.12.2017 um 11:34 schrieb Roger He:
Change-Id: I803ea52d11e5c06add0dffab836c3aecc00b56dd
Signed-off-by: Roger He
Commit message! And please double check the coding style of
ast_ttm_tt_populate.
With that fixed that patch is Reviewed-by: Christian König
.
Regards,
Christian.
---
On 12/20/2017 11:06 AM, Neil Armstrong wrote:
> My 2cents about this patchset:
> You did a good job about all the animation and splash logic, but for me all
> this fbcon
> stuff is a huge hack, please use a standard and modern display subsystem en
> leave fbcon
> die alone
Thanks for the com
On 12/20/2017 10:43 AM, Daniel Vetter wrote:
> On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
>> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
>>> So essentially you're telling me that on a current general purpose
>>> distro the gfx driver loading is a dumpster fire, and we're fixing
>>
On Wed, Dec 20, 2017 at 11:50:17AM +0100, Hans de Goede wrote:
> At least on the Chuwi Vi8 (non pro/plus) the LCD panel will show an image
> shifted aprox. 20% to the left (with wraparound) and sometimes also wrong
> colors, showing that the panel controller is starting with sampling the
> datastre
Den 15.12.2017 18.51, skrev Noralf Trønnes:
Hi,
This is a new attempt at simplifying fbdev setup/teardown in drivers.
Only doc changes in this version based on feedback from Daniel.
Noralf.
Changes since version 1:
- Document a case where drm_fb_helper_fbdev_setup() can't be used:
connect
Commit message!
Am 20.12.2017 um 11:34 schrieb Roger He:
Change-Id: I4104a12e09a374b6477a0dd5a8fce26dce27a746
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_memory.c | 15 ---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 6 +-
drivers/gpu/drm/ttm/ttm_page_alloc_d
Commit message needed! Something like:
Forward the operation context to ttm_mem_global_alloc as well.
Am 20.12.2017 um 11:34 schrieb Roger He:
Change-Id: I5279b5cd3560c4082b00f822219575a5f9c3808a
Signed-off-by: Roger He
With the commit message fixed, patch is Reviewed-by: Christian König
.
Am 20.12.2017 um 11:34 schrieb Roger He:
then remove superfluous functions
We need a better commit message. Something like:
Remove the extra indirection, cause we have only one implementation anyway.
Change-Id: Iea020f0e30a239e0265e7a1500168c7d7f819bd9
Signed-off-by: Roger He
With the co
On Wed, 20 Dec 2017, Joe Perches wrote:
> On Wed, 2017-12-20 at 10:59 +0100, Greg Kroah-Hartman wrote:
> > > > Why you didn't send that patch to the sysfs maintainer is a bit odd...
> > > > :)
> > >
> > > So here's an opportunity for you:
> > >
> > > The sysfs maintainer hasn't added include/l
On 12/19/2017 10:01 PM, Ray Strode wrote:
> Hi,
>
> On Tue, Dec 19, 2017 at 10:41 AM, Max Staudt wrote:
>> I'm hooking into the in-kernel terminal emulator, because the bootsplash is a
>> functional extension of that. It just happens that fbcon sits on top of FB,
>> so I
>> work with what I get.
On 12/19/2017 09:30 PM, Ray Strode wrote:
> Hi,
>
>> For example, having a userspace splash that starts as early as it can
>> (thus on vesafb/efifb on a PC) will cause the KMS driver to fail
>> reserving the entirety of video RAM, and thus fail loading. This cannot be
>> fixed.
> well the fix the
Hi Dave, seasons greetings, just a few small fixes.
BR,
Jani.
The following changes since commit 2cf654db8d7eafb973d28eb3cddf043d353e1345:
drm/i915/fence: Use rcu to defer freeing of irq_work (2017-12-14 10:58:59
+0200)
are available in the git repository at:
git://anongit.freedesktop.or
Hi Daniel,
On Tue, Dec 19, 2017 at 11:05:04AM +0100, Daniel Vetter wrote:
> On Mon, Dec 18, 2017 at 08:50:46AM +0100, Maxime Ripard wrote:
> > Hi,
> >
> > On Fri, Dec 15, 2017 at 06:06:32PM +0100, Daniel Vetter wrote:
> > > On Fri, Dec 15, 2017 at 05:46:19PM +0100, Hans Verkuil wrote:
> > > > Whe
This patch was initially sent along with another one to fix a
first hang in the nouveau drm driver[1]. I'm now sending it
again as a separate patch as it's to fix a second hang which is
not strictly related. It is hidden by the first hang though, as
this happens later on during the driver initial
When neither HDMI nor DP is supported such as on the tegra124, the
sor->clk_out is not initialised and remains NULL. In this case, the
parent clock can't be assigned to it so revert to the previous
behaviour of assigning it to the main sor->clk instead.
This fixes a kernel hang on tegra124 and sh
https://bugs.freedesktop.org/show_bug.cgi?id=104347
Bug ID: 104347
Summary: AMD RX 580: Hide/Show window sometimes corrupts screen
(see screenshot)
Product: Mesa
Version: 17.3
Hardware: x86-64 (AMD64)
OS: Li
On 19.12.2017 12:42, Marc Zyngier wrote:
> On 19/12/17 07:55, Andrzej Hajda wrote:
>> On 18.12.2017 12:28, Marc Zyngier wrote:
>>> Stopping the X display manager on a kevin platform results in the
>>> following crash:
>>>
>>> [ 674.833536] Synchronous External Abort: synchronous external abort
>>
Hi Johannes,
On 20 December 2017 at 11:08, Johannes Thumshirn wrote:
> On Tue, Dec 19, 2017 at 05:16:30PM +0100, Daniel Vetter wrote:
>> Ok I've realized that my assumptions about why you need this aren't
>> So from reading these patches it sounded like you want an in-kernel boot
>> splash becaus
https://bugzilla.kernel.org/show_bug.cgi?id=196197
--- Comment #17 from Andreas Brogle (an...@ok.de) ---
What do you suggest ?
Who is the maintainer for fixing this bug ?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
On Wed, 2017-12-20 at 10:59 +0100, Greg Kroah-Hartman wrote:
> > > Why you didn't send that patch to the sysfs maintainer is a bit odd... :)
> >
> > So here's an opportunity for you:
> >
> > The sysfs maintainer hasn't added include/linux/sysfs.h to
> > the list of maintained files...
> >
> > D
1 - 100 of 141 matches
Mail list logo
