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
datastream somewhere mid-line. This happens after the first blanking and
re-ini
On 19/12/17 08:53, Andrzej Hajda wrote:
> On 18.12.2017 12:39, Marc Zyngier wrote:
>> The analogix DP bridge is entierely driven via MMIO accesses, and
>> does not do any DMA that requires coherency with the CPU. Yet, the
>> driver uses the non-relaxed accessors, forcing strong barriers to
>> be em
Am Dienstag, den 19.12.2017, 14:57 +0100 schrieb Daniel Vetter:
> > Would you like me to extend the FB API or not?
>
> Yes. Well for real I'd like you to do kms, so maybe you need to explain
> why exactly you absolutely have to use fbdev (aka which driver isn't
> supported by drm that you want to
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
>> (0x9610) at 0x0c970640
>> [ 674.84
On 12/19/2017 6:59 PM, Daniel Vetter wrote:
On Mon, Dec 18, 2017 at 09:42:13AM -0800, Linus Torvalds wrote:
On Sun, Dec 17, 2017 at 11:11 PM, Daniel Vetter wrote:
This didn't seem to have made it into -rc4. Anything needed to get it
going?
Do you actually see the problem in -rc4?
Because w
* Tomi Valkeinen [171219 10:51]:
> On 11/12/17 17:22, Tony Lindgren wrote:
> > * H. Nikolaus Schaller [171201 07:44]:
> > > Official vendor string is now "tpo" and not "toppoly".
> > >
> > > Requires patch "omapdrm: panel: fix compatible vendor string for
> > > td028ttec1"
> > > so that the dri
Em Sun, 17 Dec 2017 16:28:44 -0800
Joe Perches escreveu:
> Some functions definitions have either the initial open brace and/or
> the closing brace outside of column 1.
>
> Move those braces to column 1.
>
> This allows various function analyzers like gnu complexity to work
> properly for these
On 2017-12-18 12:37, Michel Dänzer wrote:
>
> Following up by e-mail, since I can't find Peter Rosin in the kernel
> bugzilla.
>
>
> On 2017-12-16 02:41 AM, bugzilla-dae...@bugzilla.kernel.org wrote:
>> https://bugzilla.kernel.org/show_bug.cgi?id=198123
>>
>> --- Comment #8 from Deposite Pirate
On 20/12/17 00:27, Dongwon Kim wrote:
> I forgot to include this brief information about this patch series.
>
> This patch series contains the implementation of a new device driver,
> hyper_dmabuf, which provides a method for DMA-BUF sharing across
> different OSes running on the same virtual OS p
On 12/19/2017 12:15 PM, Joe Perches wrote:
drivers/char/ipmi/ipmi_msghandler.c| 17 +++---
For ipmi:
Acked-by: Corey Minyard
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/
On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote:
> On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote:
> > Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
[]
> > diff --git a/sound/soc/omap/mcbsp.c b/sound/soc/omap/mcbsp.c
[]
> > @@ -854,7 +854,7 @@ static ssize_t dma_op
On Wed, Dec 20, 2017 at 01:24:44AM -0800, Joe Perches wrote:
> On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote:
> > On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote:
> > > Convert DEVICE_ATTR uses to DEVICE_ATTR_RW where possible.
> []
> > > diff --git a/sound/soc/omap/mcbsp.c b/
https://bugzilla.kernel.org/show_bug.cgi?id=197925
--- Comment #11 from Charles (ylang-yl...@libertysurf.fr) ---
Hi team,
Just to say... same error :
[drm:hwss_wait_for_blank_complete [amdgpu]] *ERROR* DC: failed to blank crtc!
with 4.15-rc4
(on the same noteboook)
--
You are receiving this
lock_all_ctx in setplane_internal may return -EINTR, and
__setplane_internal could return -EDEADLK. Making more
special cases for fb would make the code even harder to
read, so the easiest solution is not taking over the fb
refcount, and making callers responsible for dropping
the ref.
Bugzilla: h
From: Ville Syrjälä
We don't need any active planes during load detection, so just disable
them all. This saves us from having to come up with a suitable
framebuffer. And we also avoid leaving sprite/cursor planes on and
potentially presenting them at a peculiar location during the load
detection
This is is very useful to finding sources of leaked framebufers.
The fbcon fb is annotated with [fbcon], to give it a better name
than kworker.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_fb_helper.c | 1 +
drivers/gpu/drm/drm_framebuffer.c | 2 ++
include/drm/drm_framebuffer.h
There's a small leak excerbated by interruptible waiting in setplane_internal,
which was triggered by kms_atomic. Another leak is in load detection, and easily
plugged by just removing the fb handling.
Maarten Lankhorst (2):
drm/plane: Make framebuffer refcounting the responsibility of
setpl
On Tue, Dec 19, 2017 at 07:40:12PM +0100, Max Staudt wrote:
> On 12/19/2017 06:26 PM, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote:
> >> Well, those could enable fbcon if they want the bootsplash. Shouldn't make
> >> a difference anyway if they're powerful enough to
On Tue, Dec 19, 2017 at 05:23:52PM +0100, Max Staudt wrote:
> On 12/19/2017 05:02 PM, Daniel Vetter wrote:
> > On Tue, Dec 19, 2017 at 4:41 PM, Max Staudt wrote:
> >> On 12/19/2017 02:57 PM, Daniel Vetter wrote:
> >>> The problem is that defio is totally not how a real driver works.
> >>
> >> But
On Wed, 2017-12-20 at 10:32 +0100, Greg Kroah-Hartman wrote:
> On Wed, Dec 20, 2017 at 01:24:44AM -0800, Joe Perches wrote:
> > On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote:
> > > On Tue, Dec 19, 2017 at 10:15:07AM -0800, Joe Perches wrote:
> > > > Convert DEVICE_ATTR uses to DEVICE_ATTR_
https://bugs.freedesktop.org/show_bug.cgi?id=104275
--- Comment #8 from Michel Dänzer ---
(In reply to Alex_Zhang1 from comment #7)
Without the patch referenced in comment 3, a buffer must be pinned to VRAM
before it can be scanned out (displayed). The problem described in this report
happens be
On Wed, Dec 20, 2017 at 01:54:41AM -0800, Joe Perches wrote:
> On Wed, 2017-12-20 at 10:32 +0100, Greg Kroah-Hartman wrote:
> > On Wed, Dec 20, 2017 at 01:24:44AM -0800, Joe Perches wrote:
> > > On Wed, 2017-12-20 at 10:34 +0200, Jarkko Nikula wrote:
> > > > On Tue, Dec 19, 2017 at 10:15:07AM -0800
On Tue, Dec 19, 2017 at 03:27:31PM -0800, Dongwon Kim wrote:
> I forgot to include this brief information about this patch series.
>
> This patch series contains the implementation of a new device driver,
> hyper_dmabuf, which provides a method for DMA-BUF sharing across
> different OSes running o
https://bugs.freedesktop.org/show_bug.cgi?id=104331
--- Comment #5 from Michel Dänzer ---
(In reply to MWATTT from comment #2)
> However, the demo does not render properly(I don't know if I should make
> another report for that).
Please do.
--
You are receiving this mail because:
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=104345
Bug ID: 104345
Summary: Playing video hangs X-Server with showing scrambled
picture, sound still playing.
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On 20/12/2017 10:43, 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:
>>> On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote:
Well, those could enable fbcon if they want the bootsplash. Shouldn't make
a dif
https://bugs.freedesktop.org/show_bug.cgi?id=104345
Michel Dänzer changed:
What|Removed |Added
QA Contact||dri-devel@lists.freedesktop
On Wed, Dec 20, 2017 at 11:06:34AM +0100, Neil Armstrong wrote:
> On 20/12/2017 10:43, 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:
> >>> On Tue, Dec 19, 2017 at 6:04 PM, Max Staudt wrote:
> Well, those
On Wed, Dec 20, 2017 at 10:35:43AM +0100, Maarten Lankhorst wrote:
> lock_all_ctx in setplane_internal may return -EINTR, and
> __setplane_internal could return -EDEADLK. Making more
> special cases for fb would make the code even harder to
> read, so the easiest solution is not taking over the fb
On Wed, Dec 20, 2017 at 10:35:44AM +0100, Maarten Lankhorst wrote:
> This is is very useful to finding sources of leaked framebufers.
> The fbcon fb is annotated with [fbcon], to give it a better name
> than kworker.
>
> Signed-off-by: Maarten Lankhorst
I think we can polish this more later on,
On Wed, Dec 20, 2017 at 10:35:45AM +0100, Maarten Lankhorst wrote:
> From: Ville Syrjälä
>
> We don't need any active planes during load detection, so just disable
> them all. This saves us from having to come up with a suitable
> framebuffer. And we also avoid leaving sprite/cursor planes on and
then remove superfluous functions
Change-Id: Iea020f0e30a239e0265e7a1500168c7d7f819bd9
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 21 +++-
drivers/gpu/drm/ttm/ttm_memory.c | 12 ++-
include/drm/ttm/ttm_bo_api.h | 1 +
include/drm/ttm/ttm_bo_driver.h | 1 -
https://bugs.freedesktop.org/show_bug.cgi?id=104345
--- Comment #2 from bernhardu ---
(In reply to Michel Dänzer from comment #1)
> It's more likely a Mesa or maybe LLVM issue. Did this start happening after
> you upgraded Mesa and/or LLVM, or maybe another component such as the kernel?
I get su
Change-Id: I5279b5cd3560c4082b00f822219575a5f9c3808a
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
drivers/gpu/drm/ttm/ttm_memory.c| 15 +--
drivers/gpu/drm/ttm/ttm_object.c| 13 ++---
drivers/gpu/drm/vmwgf
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_dma.c | 8 ++--
include/drm/ttm/ttm_memory.h |
Change-Id: I42a7df8c50e1ce3b527ee9cb78809f8e58136f07
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c| 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c| 2 +-
drivers/gpu/drm/ttm/ttm_
Change-Id: I803ea52d11e5c06add0dffab836c3aecc00b56dd
Signed-off-by: Roger He
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ---
drivers/gpu/drm/ast/ast_ttm.c| 5 +++--
drivers/gpu/drm/cirrus/cirrus_ttm.c | 5 +++--
drivers/gpu/drm/nouveau/nouveau_bo.c | 8
Change-Id: I1e87954564f38ad298bf6e4ff88c9f26f291a62d
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 15 +++
drivers/gpu/drm/ttm/ttm_memory.c | 12
include/drm/ttm/ttm_bo_api.h | 3 ++-
3 files changed, 21 insertions(+), 9 deletions(-)
diff --git a/dr
extract this function since eviction and swapout share same logic
Change-Id: I80a475a93fceed8d66d74a1832c815a0756341ac
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_bo.c | 29 +++--
1 file changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/ttm/
https://bugs.freedesktop.org/show_bug.cgi?id=104345
--- Comment #3 from Michel Dänzer ---
Please attach the output of glxinfo and vdpauinfo.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@
https://bugzilla.kernel.org/show_bug.cgi?id=196197
--- Comment #16 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Andreas Brogle from comment #14)
> 60e8d3e11645a1b9c4197d9786df3894332c1685 (BAD)
> 190c3ee06a0f0660839785b7ad8a830e832d9481 (GOOD)
There are only PCI subsystem changes betw
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
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.
___
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
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
>>
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
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
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
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
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
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
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 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
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
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
.
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
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
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
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 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
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.
---
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
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
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 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
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: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,
> 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 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
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: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: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
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.
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 #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.__
https://bugs.freedesktop.org/show_bug.cgi?id=96866
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=97993
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=97471
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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:
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=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
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 #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=102130
Gašper Sedej changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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
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
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=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
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
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 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
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: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
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 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: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
1 - 100 of 141 matches
Mail list logo
