https://bugs.freedesktop.org/show_bug.cgi?id=109234
Michel Dänzer changed:
What|Removed |Added
Resolution|--- |NOTOURBUG
Status|NEW
https://bugzilla.kernel.org/show_bug.cgi?id=202263
--- Comment #5 from Emre Işık (e.isi...@gmail.com) ---
I found this line in my dmesg logs:
> [drm:atom_op_jump [amdgpu]] *ERROR* atombios stuck in loop for more than
> 5secs aborting
So I searched and found some threads about TLP and AMDGPU prob
On Fri, Jan 11, 2019 at 04:06:38PM +0100, Maxime Ripard wrote:
> From: Neil Armstrong
>
> commit 4be9bd10e22dfc7fc101c5cf5969ef2d3a042d8a upstream.
>
> Since "drm/fb: Stop leaking physical address", the default behaviour of
> the DRM fbdev emulation is to set the smem_base to 0 and pass the new
Hi Ayan,
On Mon, Jan 14, 2019 at 05:02:00PM +, Ayan Halder wrote:
> From: Matteo Franchin
>
> This commit adds definitions of format modifiers for version 1.3 of the
> Arm Framebuffer Compression (AFBC).
>
> Signed-off-by: Matteo Franchin
We should have your Signed-off-by on any patches t
https://bugs.freedesktop.org/show_bug.cgi?id=105113
--- Comment #12 from Pander ---
Super for the tested patch. What is the status regarding Mesa on this?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing l
https://bugs.freedesktop.org/show_bug.cgi?id=102909
--- Comment #3 from Pander ---
Christopher, are you still experiencing this bug?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.fr
https://bugs.freedesktop.org/show_bug.cgi?id=109239
--- Comment #6 from Samuel Pitoiset ---
FWIW, I have the same issue on both Polaris/Vega. Disabling DC on Polaris
appears to fix the problem on my side. Also, those periodic random black
screens seem to only happen with my 4K screen, I don't hav
On Tue, Jan 15, 2019 at 10:46:19AM +1100, Stephen Rothwell wrote:
> Hi Liviu,
Hi Stephen,
>
> After merging the mali-dp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/gpu/drm/arm/display/komeda/komeda_private_obj.c: In function
> 'komeda_pipeline_obj_add':
On Sat, Jan 12, 2019 at 09:50:51PM +0100, Borislav Petkov wrote:
> Hi guys,
>
> my odyssey with the GPU continues. This time it didn't reset itself
> but started spewing a single line about the hardware locking up.
>
> The machine was responsive to sysrq so I was able to write out
> /var/log/mess
Although given the lack of progress since 2010, maybe time to ditch it
from staging outright?
Signed-off-by: Daniel Vetter
Cc: Arnaud Patard
Cc: Daniel Vetter
---
drivers/staging/xgifb/TODO | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/staging/xgifb/TODO b/drivers/staging/xgif
It's a debug hack flag useful to work around driver bugs. That's not a
good idea for a new driver. Especially for a new drm driver.
Aside: the fbdev support should probably be converted over to the new
generic fbdev support.
Signed-off-by: Daniel Vetter
Cc: Greg Kroah-Hartman
Cc: Hans de Goede
On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote:
> It's a debug hack flag useful to work around driver bugs. That's not a
> good idea for a new driver. Especially for a new drm driver.
>
> Aside: the fbdev support should probably be converted over to the new
> generic fbdev support.
The initial series is only introducing the basic components and not
implementing IRQ handling. Remove the left over code that touches
IRQs until the proper implementation is introduced in a later series.
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/display/komeda/komeda_dev.c | 5 -
dr
Hi Liviu,
On Tue, 15 Jan 2019 10:12:19 + Liviu Dudau wrote:
>
> That looks like the right fix, thank you for that!
Thanks for your verification.
> I will roll your patch into my tree.
You can only do that when your tree is merged with the drm tree (and
it should be part of the merge resolu
On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> Hi Liviu,
>
> On Tue, 15 Jan 2019 10:12:19 + Liviu Dudau wrote:
> >
> > That looks like the right fix, thank you for that!
>
> Thanks for your verification.
>
> > I will roll your patch into my tree.
>
> You can only do th
On Tue, 08 Jan 2019, Nathan Chancellor wrote:
> Hi all,
>
> Commit e845f099f1c6 ("drm/i915/dsc: Add Per connector debugfs node for
> DSC support/enable") causes a Clang warning:
>
> drivers/gpu/drm/i915/i915_debugfs.c:4961:17: warning: address of array
> 'intel_dp->dsc_dpcd' will always evaluate
On Tue, 15 Jan 2019, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
> drivers. And
On Mon, Jan 14, 2019 at 03:13:29PM -0600, Gustavo A. R. Silva wrote:
>
>
> On 1/14/19 2:27 PM, Mathieu Malaterre wrote:
> > There is a plan to build the kernel with -Wimplicit-fallthrough and
> > these places in the code produced warnings (W=1). Fix them up.
> >
> > This commit remove the follow
On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> One needs to translate the Gralloc buffer flags for AFBC (eg
> MALI_GRALLOC_INTFMT_AFBC_BASIC) to the corresponding linux kernel drm
> modifiers.
> This gets passed to libdrm via drmModeAddFB2WithModifiers.
>
> Signed-off-by: Ayan Kum
On Mon, Jan 14, 2019 at 04:31:18PM +0100, Neil Armstrong wrote:
> Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
> example) the display gets blurry, looking like an invalid framebuffer width.
>
> This commit fixed atomic crtc modesetting in a totally wrong way and
> introd
On Tue, Jan 15, 2019 at 10:51:02AM +, Liviu Dudau wrote:
> On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> > Hi Liviu,
> >
> > On Tue, 15 Jan 2019 10:12:19 + Liviu Dudau wrote:
> > >
> > > That looks like the right fix, thank you for that!
> >
> > Thanks for your veri
On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote:
> > It's a debug hack flag useful to work around driver bugs. That's not a
> > good idea for a new driver. Especially for a new drm driver.
> >
> > Aside: the fbdev
On 15/01/2019 13:06, Daniel Vetter wrote:
> On Mon, Jan 14, 2019 at 04:31:18PM +0100, Neil Armstrong wrote:
>> Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
>> example) the display gets blurry, looking like an invalid framebuffer width.
>>
>> This commit fixed atomic crtc
https://bugs.freedesktop.org/show_bug.cgi?id=104362
--- Comment #18 from nmr ---
Created attachment 143124
--> https://bugs.freedesktop.org/attachment.cgi?id=143124&action=edit
dmesg during reboot/recovery
On the basis that it may be shader induced I repro'd a similar hang with dxvk
(v0.95-5-g
https://bugs.freedesktop.org/show_bug.cgi?id=104362
--- Comment #19 from nmr ---
Created attachment 143125
--> https://bugs.freedesktop.org/attachment.cgi?id=143125&action=edit
UMR dump for similar dxvk hang
I see that there is only one wave noted in the dump, and the shader appears to
be of r
On Tue, Jan 15, 2019 at 01:08:36PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 10:51:02AM +, Liviu Dudau wrote:
> > On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> > > Hi Liviu,
> > >
> > > On Tue, 15 Jan 2019 10:12:19 + Liviu Dudau
> > > wrote:
> > > >
> >
On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> > One needs to translate the Gralloc buffer flags for AFBC (eg
> > MALI_GRALLOC_INTFMT_AFBC_BASIC) to the corresponding linux kernel drm
> > modifiers.
> > This gets pass
On 15/01/2019 11:41, Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actually achieved the goal here I went through all
> drivers. And
Add support for TMDS Clock > 3.4GHz for HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
b/drivers/gpu/drm/meson/meson
Now the DW-HDMI Controller supports the HDMI2.0 modes, enable support
for these modes in the connector if the platform supports them.
We limit these modes to DW-HDMI IP version >= 0x200a which
are designed to support HDMI2.0 display modes.
Signed-off-by: Neil Armstrong
Tested-by: Heiko Stuebner
This patchset aims to add support for the following HDMI2.0 4k60 modes:
- 594Mhz TMDS frequency needing TMDS Scramling and 1/40 rate for RGB/YUV4:4:4
- 297MHz TMDS frequency with YUV4:2:0 encoding
The first mode uses the SCDC helpers introduced by intel to :
- discover where the monitor support SC
With the YUV420 handling, we can dynamically setup the HDMI output
pixel format depending on the mode and connector info.
So now, we can output in YUV444, which is the native video pipeline
format, directly to the HDMI Sink if it's supported without
necessarily involving the HDMI Controller CSC.
S
Now we support the TMDS Clock > 3.4GHz and support the SCDC Control
operation in the DW-HDMI Controller, we can enable support for the
HDMI2.0 3840x2160@60/50 RGB444 display modes.
Signed-off-by: Neil Armstrong
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/meson/meson_venc.c | 2 ++
1 file cha
Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
Scrambling when supported or mandatory.
This patch also adds an helper to setup the control bit to support
the high TMDS Bit Period/TMDS Clock-Period Ratio as required with
TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.
Th
In order to support the HDMI2.0 YUV420 display modes, this patch
adds support for the YUV420 TMDS Clock divided by 2 and the controller
passthrough mode.
YUV420 Synopsys PHY support will need some specific configuration table
to support theses modes.
This patch is based on work from Zheng Yang i
From: Zheng Yang
To get input/output bus_format/enc_format dynamically, this patch
introduce following functions in plat_data:
- get_input_bus_format
- get_output_bus_format
- get_enc_in_encoding
- get_enc_out_encoding
Signed-off-by: Zheng Yang
Signed-off-by: Nei
This patch adds support for the YUV420 output from the Amlogic Meson SoCs
Video Processing Unit to the HDMI Controller.
The YUV420 is obtained by generating a YUV444 pixel stream like
the classic HDMI display modes, but then the Video Encoder output
can be configured to down-sample the YUV444 pixe
On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
>
> On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> > > One needs to translate the Gralloc buffer flags for AFBC (eg
> > > MALI_GRALLOC_INTFMT_AFBC_BASIC) to the cor
https://bugs.freedesktop.org/show_bug.cgi?id=109239
--- Comment #7 from Harry Wentland ---
If you didn't say you tried swapping monitors and cables I'd say it was a cable
issue.
Are those high refresh rate displays (120Hz+)? If so you might want to give
what's suggested in this comment a try:
ht
https://bugs.freedesktop.org/show_bug.cgi?id=104345
--- Comment #13 from bernhardu ---
Happened again.
A way to avoid that crash may be to not stay int first cold boot.
I am not sure but I think I never saw this when system was
running from a rebooted state (warm boot).
[0.00] Linux ver
On Mon, Jan 14, 2019 at 05:29:31PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that
On Tue, Jan 15, 2019 at 01:38:19PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
> >
> > On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > > On Mon, Jan 14, 2019 at 03:28:27PM +, Ayan Halder wrote:
> > > > One needs to translate the Gralloc b
On Tue, Jan 15, 2019 at 2:27 PM Liviu Dudau wrote:
>
> On Tue, Jan 15, 2019 at 01:38:19PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
> > >
> > > On Tue, Jan 15, 2019 at 01:05:47PM +0100, Daniel Vetter wrote:
> > > > On Mon, Jan 14, 2019 at 03:28:27PM +,
On Tue, Jan 15, 2019 at 1:23 PM Liviu Dudau wrote:
>
> On Tue, Jan 15, 2019 at 01:08:36PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 10:51:02AM +, Liviu Dudau wrote:
> > > On Tue, Jan 15, 2019 at 09:47:25PM +1100, Stephen Rothwell wrote:
> > > > Hi Liviu,
> > > >
> > > > On Tue, 1
On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote:
> > > It's a debug hack flag useful to work around driver bugs. That's not a
> > > good idea for a
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #96 from tempel.jul...@gmail.com ---
Yep, that's my observation as well (no compositor vsync enbled at the same
time).
I also noticed that sometimes switching between Vulkan fullscreen windows
(radv) and desktop can break TearFree, i
From: Oleksandr Andrushchenko
When GEM backing storage is allocated with drm_gem_get_pages
the backing pages may be cached, thus making it possible that
the backend sees only partial content of the buffer which may
lead to screen artifacts. Make sure that the frontend's
memory is coherent and the
Hi, Christoph,
On Mon, 2019-01-14 at 10:48 +0100, Christoph Hellwig wrote:
> On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
> > > Changes since the RFC:
> > > - Rework vmwgfx too [CH]
> > > - Use a distinct type for the DMA page iterator [CH]
> > > - Do not have a #ifdef [CH]
> >
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #54 from OliverHB ---
Did anyone ever try switching to a text console (CTRL-ALT-F[1-6]) and back
(usually CTRl-ALT-F7)to graphical screen? That does the trick for me! However,
I wouldn't mind if there is a solution which makes that o
Am 15.01.19 um 15:17 schrieb Thomas Hellstrom:
Hi, Christoph,
On Mon, 2019-01-14 at 10:48 +0100, Christoph Hellwig wrote:
On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote:
Changes since the RFC:
- Rework vmwgfx too [CH]
- Use a distinct type for the DMA page iterator [CH]
- Do n
https://bugs.freedesktop.org/show_bug.cgi?id=109359
--- Comment #2 from Timur Kristóf ---
Created attachment 143126
--> https://bugs.freedesktop.org/attachment.cgi?id=143126&action=edit
dmesg log
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=109359
--- Comment #3 from Timur Kristóf ---
Created attachment 143127
--> https://bugs.freedesktop.org/attachment.cgi?id=143127&action=edit
xorg log
--
You are receiving this mail because:
You are the assignee for the bug._
Hi Daniel,
Thank you for the patch.
On Tuesday, 15 January 2019 12:41:37 EET Daniel Vetter wrote:
> Having the probe helper stuff (which pretty much everyone needs) in
> the drm_crtc_helper.h file (which atomic drivers should never need) is
> confusing. Split them out.
>
> To make sure I actuall
Hi all,
I would like to have some Acked-by's from you, the distro media
folks Cc'd here, to document your intent to start using Intel's
new media driver[1]. So if you recognize yourself (or are otherwise
interested), please read on.
TL;DR Distro folks, please give your Acked-by on patch [5/6]
I
On Tue, Jan 15, 2019 at 02:29:19PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 2:27 PM Liviu Dudau wrote:
> >
> > On Tue, Jan 15, 2019 at 01:38:19PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 15, 2019 at 1:24 PM Liviu Dudau wrote:
> > > >
> > > > On Tue, Jan 15, 2019 at 01:05:47PM +0
On Sat, Dec 01, 2018 at 12:31:45PM +0100, Hans de Goede wrote:
> There are 3 problems with the dsi code's pipe_bpp handling for 6 bpc
> pixel-formats which this commit addresses:
>
> 1) It assumes that the pipe_bpp is the same as the bpp going over the dsi
> lanes. This assumption is not valid for
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #97 from Michel Dänzer ---
(In reply to tempel.julian from comment #96)
> I also noticed that sometimes switching between Vulkan fullscreen windows
> (radv) and desktop can break TearFree, it needs to be reactivated then. I
> however
On Sat, Dec 01, 2018 at 12:31:46PM +0100, Hans de Goede wrote:
> The display engine has 2 dithering enable bits which both need to be set
> for dithering to happen, 1 in the PIPECONF register which is taken care of
> by i9xx_set_pipeconf() and a second bit at the encoder level.
>
> The dsi code wa
On 1/15/19 2:26 PM, Neil Armstrong wrote:
On 15/01/2019 11:41, Daniel Vetter wrote:
Having the probe helper stuff (which pretty much everyone needs) in
the drm_crtc_helper.h file (which atomic drivers should never need) is
confusing. Split them out.
To make sure I actually achieved the goal her
On Sat, Dec 01, 2018 at 12:31:47PM +0100, Hans de Goede wrote:
> On devices with a burst_mode_ratio which is not 100 (1:1), the pclk
> will have a different value then drm_display_mode.clock .
>
> On a Prowise PT301 tablet where vbt.lfp_lvds_vbt_mode.clock is 66100 and
> burst_mode_ratio is 130 th
On Tue, Jan 15, 2019 at 10:17:09AM +0530, Nishad Kamdar wrote:
> This switches the fbtft driver to use GPIO descriptors
> rather than numerical gpios:
>
> Utilize the GPIO library's intrinsic handling of OF GPIOs
> and polarity. If the line is flagged active low, gpiolib
> will deal with this.
>
https://bugzilla.kernel.org/show_bug.cgi?id=202217
--- Comment #7 from Haxk20 (haxk...@gmail.com) ---
I did some further testing. The bug seems to be that even when i run just TTY
session without GNOME even launched and i suspend the laptop to turn off the
screen then the screen doesnt come back u
Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
types, which differs from the BSDs' headers. Thus we should include
stdint.h to ensure we have all the required integer types.
Signed-off-by: James Clarke
---
include/uapi/drm/drm.h | 1 +
1 file changed, 1 insertion(+)
diff
On Tue, Jan 15, 2019 at 02:45:53PM +0100, Greg Kroah-Hartman wrote:
> On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote:
> > On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote:
> > > On Tue, Jan 15, 2019 at 11:27:54AM +0100, Daniel Vetter wrote:
> > > > It's a debug hack
On Tue, Jan 15, 2019 at 03:04:18PM +, James Clarke wrote:
> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
> types, which differs from the BSDs' headers. Thus we should include
> stdint.h to ensure we have all the required integer types.
>
> Signed-off-by: James Clarke
On Tue, Jan 15, 2019 at 03:24:55PM +0100, Christian König wrote:
> Yeah, indeed. Bounce buffers are an absolute no-go for GPUs.
>
> If the DMA API finds that a piece of memory is not directly accessible by
> the GPU we need to return an error and not try to use bounce buffers behind
> the surface
On Tue, Jan 15, 2019 at 04:15:49PM +0100, Daniel Vetter wrote:
> On Tue, Jan 15, 2019 at 02:45:53PM +0100, Greg Kroah-Hartman wrote:
> > On Tue, Jan 15, 2019 at 01:12:28PM +0100, Daniel Vetter wrote:
> > > On Tue, Jan 15, 2019 at 11:38:29AM +0100, Greg Kroah-Hartman wrote:
> > > > On Tue, Jan 15, 2
https://bugs.freedesktop.org/show_bug.cgi?id=109366
Bug ID: 109366
Summary: NULL pointer at pcie_capability_read_dword with Radeon
SI vfio passthrough
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #42 from Jerry Zuo ---
We are currently looking at the startup issue now.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lis
Hi,
(Sending those kind of bug reports to linux-sunxi doesn't really work,
you should Cc at least the ML involved in the development of the
driver at fault).
On Mon, Jan 14, 2019 at 01:29:34PM +, Priit Laes wrote:
> I have a somewhat curious case with one HDMI/DVI screen that fails
> to initi
Hi Daniel, Dave,
Here is the drm-misc-next PR for this week.
Thanks!
Maxime
drm-misc-next-2019-01-15:
drm-misc-next for 5.1:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Reorganisation of drm_device and drm_framebuffer headers
- Cleanup of the drmP inclusion
- Fix leaks in the fb
On 1/14/19 8:32 PM, Laura Abbott wrote:
> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>> The "unmapped" heap is very similar to the carveout heap except
>> the backing memory is presumed to be unmappable by the host, in
>> my specific case due to firewalls. This memory can still be
>> allocated fro
https://bugs.freedesktop.org/show_bug.cgi?id=109366
--- Comment #1 from Alex Williamson ---
Use a Q35 VM configuration with the assigned GPU downstream of an emulated PCIe
root port as a workaround. The driver assumes this configuration, presumably
it's the only one that exists on bare metal, an
https://bugs.freedesktop.org/show_bug.cgi?id=109366
Alex Deucher changed:
What|Removed |Added
Component|DRM/AMDgpu |DRM/Radeon
--
You are receiving this ma
https://bugzilla.kernel.org/show_bug.cgi?id=202263
--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 280505
--> https://bugzilla.kernel.org/attachment.cgi?id=280505&action=edit
possible fix
Does this patch fix the issue?
--
You are receiving this mail because:
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=109366
--- Comment #2 from Alex Deucher ---
Created attachment 143133
--> https://bugs.freedesktop.org/attachment.cgi?id=143133&action=edit
possible fix
Does this patch fix it? dGPUs are always add in cards, so they always plug
into an upstream por
On 1/14/19 10:36 PM, Noralf Trønnes wrote:
This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty
handler. All flushing will now happen in the pipe functions.
Also enable the damage plane property for all except repaper which can
only do full updates.
ili9225:
This change made il
On 1/14/19 8:39 PM, Laura Abbott wrote:
> On 1/11/19 10:05 AM, Andrew F. Davis wrote:
>> Hello all,
>>
>> This is a set of (hopefully) non-controversial cleanups for the ION
>> framework and current set of heaps. These were found as I start to
>> familiarize myself with the framework to help in wha
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #98 from Michel Dänzer ---
(In reply to Brandon Wright from comment #95)
> For me, at least, it hiccups regularly every second and introduces
> noticeable latency. With dc=1 it's smooth
Thanks, I was able to reproduce the hiccups wi
On Tue, 2019-01-15 at 16:20 +0100, h...@lst.de wrote:
> On Tue, Jan 15, 2019 at 03:24:55PM +0100, Christian König wrote:
> > Yeah, indeed. Bounce buffers are an absolute no-go for GPUs.
> >
> > If the DMA API finds that a piece of memory is not directly
> > accessible by
> > the GPU we need to re
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #99 from tempel.jul...@gmail.com ---
Does the trick for me too, TearFree with amdgpu.dc=0 seems to be completely
smooth now. Delay / input latency seems to be the same between amdgpu.dc=1 and
0, I suppose this is as low as it can be w
On Tue, Jan 15, 2019 at 06:03:39PM +, Thomas Hellstrom wrote:
> In the graphics case, it's probably because it doesn't fit the graphics
> use-cases:
>
> 1) Memory typically needs to be mappable by another device. (the "dma-
> buf" interface)
And there is nothing preventing dma-buf sharing of
On 1/15/19 11:45 AM, Liam Mark wrote:
> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>
>> On 1/14/19 11:13 AM, Liam Mark wrote:
>>> On Fri, 11 Jan 2019, Andrew F. Davis wrote:
>>>
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses from the CPU to a cached heap
On 1/15/19 12:38 PM, Andrew F. Davis wrote:
> On 1/15/19 11:45 AM, Liam Mark wrote:
>> On Tue, 15 Jan 2019, Andrew F. Davis wrote:
>>
>>> On 1/14/19 11:13 AM, Liam Mark wrote:
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
> Buffers may not be mapped from the CPU so skip cache maintenanc
Daniel Vetter writes:
> On Tue, Jan 15, 2019 at 03:04:18PM +, James Clarke wrote:
>> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
>> types, which differs from the BSDs' headers. Thus we should include
>> stdint.h to ensure we have all the required integer types.
>>
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, in
my specific case due to firewalls. This
On 1/15/19 9:47 AM, Andrew F. Davis wrote:
On 1/14/19 8:39 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
Hello all,
This is a set of (hopefully) non-controversial cleanups for the ION
framework and current set of heaps. These were found as I start to
familiarize myself wi
https://bugzilla.kernel.org/show_bug.cgi?id=202217
Haxk20 (haxk...@gmail.com) changed:
What|Removed |Added
Severity|normal |high
--
You are receiving t
On 1/15/19 10:38 AM, Andrew F. Davis wrote:
On 1/15/19 11:45 AM, Liam Mark wrote:
On Tue, 15 Jan 2019, Andrew F. Davis wrote:
On 1/14/19 11:13 AM, Liam Mark wrote:
On Fri, 11 Jan 2019, Andrew F. Davis wrote:
Buffers may not be mapped from the CPU so skip cache maintenance here.
Accesses fro
On 1/15/19 10:43 AM, Laura Abbott wrote:
On 1/15/19 7:58 AM, Andrew F. Davis wrote:
On 1/14/19 8:32 PM, Laura Abbott wrote:
On 1/11/19 10:05 AM, Andrew F. Davis wrote:
The "unmapped" heap is very similar to the carveout heap except
the backing memory is presumed to be unmappable by the host, i
https://bugs.freedesktop.org/show_bug.cgi?id=109370
Bug ID: 109370
Summary: [Runelite GPU plugin] Enabling GPU plugin produces
incorrect rendering
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linu
Am 15.01.19 um 19:31 schrieb h...@lst.de:
> On Tue, Jan 15, 2019 at 06:03:39PM +, Thomas Hellstrom wrote:
>> In the graphics case, it's probably because it doesn't fit the graphics
>> use-cases:
>>
>> 1) Memory typically needs to be mappable by another device. (the "dma-
>> buf" interface)
> An
https://bugs.freedesktop.org/show_bug.cgi?id=109370
MIka R changed:
What|Removed |Added
Severity|normal |minor
Priority|medium
On Fri, 11 Jan 2019 15:18:55 +, Peter Rosin wrote:
> DS90C185 has a shutdown pin which does not fit in the lvds-transmitter
> binding, which is meant to be generic.
>
> The sister chip DS90C187 is similar to DS90C185, describe it here as well.
>
> Signed-off-by: Peter Rosin
> ---
> .../bind
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #100 from Brandon Wright ---
(In reply to tempel.julian from comment #99)
> Does the trick for me too, TearFree with amdgpu.dc=0 seems to be completely
> smooth now. Delay / input latency seems to be the same between amdgpu.dc=1
> an
Something that I completely missed when implementing the new MST VCPI
atomic helpers is that with those helpers, there's technically a chance
of us having to grab additional modeset locks in ->compute_config() and
furthermore, that means we have the potential to hit a normal modeset
deadlock. Howev
On Tue, Jan 15, 2019 at 03:08:00PM -0500, Lyude Paul wrote:
> Something that I completely missed when implementing the new MST VCPI
> atomic helpers is that with those helpers, there's technically a chance
> of us having to grab additional modeset locks in ->compute_config() and
> furthermore, that
https://bugs.freedesktop.org/show_bug.cgi?id=109239
--- Comment #8 from Raman Gupta ---
Created attachment 143137
--> https://bugs.freedesktop.org/attachment.cgi?id=143137&action=edit
Xorg.0.log with modeset ddx instead of amdgpu ddx
(In reply to Michel Dänzer from comment #4)
> Does it also h
On Tue, Jan 15, 2019 at 07:13:11PM +, Koenig, Christian wrote:
> Thomas is correct that the interface you propose here doesn't work at
> all for GPUs.
>
> The kernel driver is not informed of flush/sync, but rather just setups
> coherent mappings between system memory and devices.
>
> In ot
https://bugs.freedesktop.org/show_bug.cgi?id=102909
--- Comment #4 from Christopher Clapp ---
(In reply to Pander from comment #3)
> Christopher, are you still experiencing this bug?
Pander, the Radeon graphics card in my computer died, so I replaced it with an
Nvidia card. I didn't experience
1 - 100 of 127 matches
Mail list logo
