Am 06.08.2018 02:13, schrieb Dieter Nützel:
Am 04.08.2018 06:18, schrieb Dieter Nützel:
Am 04.08.2018 06:12, schrieb Dieter Nützel:
Am 04.08.2018 05:27, schrieb Dieter Nützel:
Am 03.08.2018 13:09, schrieb Christian König:
Am 03.08.2018 um 03:08 schrieb Dieter Nützel:
Hello Christian, AMD
Hi all,
The main goal is to have the SLES12 SP3 kernel version 4.4.140-94.42.1 the fix
it needed for Kabylake graphics issue and also enable the dp aux character
device CONFIG_DRM_DP_AUX_CHARDEV=y.
I like to inquiry if there's a way or how to proceed with this correctly.
My question is I have a
https://bugs.freedesktop.org/show_bug.cgi?id=107518
--- Comment #4 from Shawn Anastasio ---
(In reply to Alex Deucher from comment #3)
> (In reply to Shawn Anastasio from comment #2)
> > Upon further testing, the issue seems to go away when the firmware is
> > removed from petitboot, preventing
Switch to state based resource management. This patch
overhauls the resource manager and HW allocation methods by
maintaining the global resource pool and allocated hw
blocks in respective drm component states.
Global resource manager(RM) is tracked in private object.
Allocation strategy is
Encoder H_TILE values are not used for allocating the hw blocks.
no. of hw_intf blocks provides the info.
changes in v2:
- none
changes in v3:
- none
Change-Id: I1c1c13e9b9f608fbaa8c5897f9f1892029107ac5
Signed-off-by: Jeykumar Sankaran
---
Subclass drm private state for DPU for handling driver
specific data. Adds atomic private object and private object
lock to dpu kms. Provides helper function to retrieve DPU
private data from current atomic state.
changes in v2:
- none
changes in v3:
- rebase on [1]
[1]
Strip down the support for topology enums. It
can be replaced with simple hw count checks.
changes in v2:
- none
changes in v3:
- none
Change-Id: If9b2a4db5bbdf8545b99b6d90825e256d014382d
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
Instead of iterating for hw ctrl per physical encoder, this
patch moves the iterations and assignment to the virtual encoder.
changes in v2:
- none
changes in v3:
- none
Change-Id: I896a8c36d6353986582e9d0fe3da9b2293579d4b
Signed-off-by: Jeykumar Sankaran
---
hw intf blocks are needed only during encoder enable to program
timing engines(for video panels). encoder->enable is triggered
only after atomic_modeset at which point we assign the
resources for the display pipeline. This patch defers the
hw_intf look-up until encoder enable.
changes in v2:
Prep change for state based resource management.
Rename hw_ctl to lm_ctl to mean the ctl associated
with the hw layer mixer block.
changes in v2:
- none
changes in v3:
- none
Change-Id: If6e6249e089b89225cdfafe9158f7509e97b
Signed-off-by: Jeykumar Sankaran
---
Prep changes for state based resource management.
Moves all the hw block tracking for the crtc to the state
object.
changes in v2:
- none
changes in v3:
- none
Change-Id: I2816e9e28b27f1126b477d62eb3858a30a652747
Signed-off-by: Jeykumar Sankaran
---
Identify slave-master encoders and program them explicitly.
changes in v2:
- none
changes in v3:
- none
Change-Id: I0ebfada05bd7f8437f842ad860490a678aa8f4cd
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 39 ++---
1
Avoid querying RM for hw mdp block. Use the one
stored in KMS during initialization.
changes in v2:
- none
changes in v3:
- none
Change-Id: I52129b96bd561a5547507d7f567bcaa3dbe554aa
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c | 12
resource pool manager utility was introduced to manage
rotator sessions. Removing the support as the rotator
feature doesn't exist.
changes in v2:
- none
changes in v3:
- rebase on [1]
[1] https://gitlab.freedesktop.org/seanpaul/dpu-staging/commits/for-next
Change-Id:
cleans up left out scalar config definitions from headers
changes in v2:
- none
changes in v3:
- none
Change-Id: Id824dd5075c666f97b964573c97215bb786eac75
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h| 2 --
This patchset series introduces drm private object in KMS to manage HW resource
management. It modifies the resource manager by introducing API's to do per DRM
object resource allocation/cleanups.
Patches 00/13 to 11/13 are clean up patches to prepare DPU for the above
migration.
major changes
removes left out variables of previous ping pong
split topology cleanup.
changes in v2:
- none
changes in v3:
- none
Change-Id: I1bf9d242039ce7cfd271233fa27840e83184fb95
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 3 ---
1 file changed, 3
This change validates the physical encoder before it
is dereferenced.
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
On Tue, Aug 07, 2018 at 06:40:39PM +0200, Daniel Vetter wrote:
> On Mon, Aug 06, 2018 at 06:01:02PM +0200, Enric Balletbo i Serra wrote:
> > From: Gustavo Padovan
> >
> > This flag tells core to jump ahead the queued update if the conditions
> > in drm_atomic_async_check() are met. That means we
https://bugzilla.kernel.org/show_bug.cgi?id=200645
Duncan (1i5t5.dun...@cox.net) changed:
What|Removed |Added
Attachment #277491|0 |1
is obsolete|
On evergreen depth-stencil textures are allocated as two objects, and
when using the eg_surface_init_1d_miptrees code path the size evaluation
uses the generalized surf_minify function. Here when allocating the
depth texture the alignment takes the depth bpe value into account, and
uses bpe=1 for
Currently, there's nothing in nouveau that actually cancels this work
struct. So, cancel it on suspend/unload. Otherwise, if we're unlucky
enough hpd_work might try to keep running up until the system is
suspended.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
https://bugs.freedesktop.org/show_bug.cgi?id=107518
--- Comment #3 from Alex Deucher ---
(In reply to Shawn Anastasio from comment #2)
> Upon further testing, the issue seems to go away when the firmware is
> removed from petitboot, preventing it from initializing the card before the
> host OS.
I'm sure I don't need to tell you that fb_helper's locking is a mess.
That being said; fb_helper's locking mess can seriously complicate the
runtime suspend/resume operations of drivers because it can invoke
atomic commits and connector probing from anywhere that calls
We can't and don't need to try resuming the device from our hotplug
handlers, but hotplug events are generally something we'd like to keep
the device awake for whenever possible. So, grab a PM ref safely in our
hotplug handlers using pm_runtime_get_noresume() and mark the device as
busy once we're
Otherwise, how will we roll everything back?
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc: Karol Herbst
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c
When we disable hotplugging on the GPU, we need to be able to
synchronize with each connector's hotplug interrupt handler before the
interrupt is finally disabled. This can be a problem however, since
nouveau_connector_detect() currently grabs a runtime power reference
when handling connector
There isn't actually any reason we need to call drm_hpd_irq_event() from
our hotplug handler, as we already know which connector the hotplug
event was fired for. We're also going to need to avoid probing all
connectors needlessly from hotplug handlers anyway so that we can track
when
Again, this doesn't do anything. drm_kms_helper_poll_enable() will have
already been called in nouveau_display_init()
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Karol Herbst
[omitting stable Cc, this probably doesn't fix any real bugs]
---
drivers/gpu/drm/nouveau/nouveau_drm.c | 4 +---
1
It's true we can't resume the device from poll workers in
nouveau_connector_detect(). We can however, prevent the autosuspend
timer from elapsing immediately if it hasn't already without risking any
sort of deadlock with the runtime suspend/resume operations. So do that
instead of entirely
This won't do anything but potentially make us miss hotplugs. We already
call drm_kms_helper_poll_disable() in
nouveau_pmops_suspend()->nouveau_display_suspend()->nouveau_display_fini()
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Karol Herbst
[omitting stable Cc, this likely doesn't fix
It's not necessary to call these before we call nouveau_do_suspend().
Ideally; we shouldn't have to call this at all here, but getting that to
work will take a bit more effort. So for the time being, just move this
call after nouveau_do_suspend() to allow us to easily be able to abort
the runtime
This doesn't do anything, drm_kms_helper_poll_enable() gets called in
nouveau_pmops_resume()->nouveau_display_resume()->nouveau_display_init()
already.
Signed-off-by: Lyude Paul
Cc: Lukas Wunner
Cc: Karol Herbst
[omitting stable Cc, this likely doesn't fix any real bugs]
---
Since actual hotplug notifications don't get disabled until
nouveau_display_fini() is called, all this will do is cause any hotplugs
that happen between this drm_kms_helper_poll_disable() call and the
actual hotplug disablement to potentially be dropped if ACPI isn't
around to help us.
This is the latest version of https://patchwork.freedesktop.org/series/46815/
I moved everything out of fb_helper and back into nouveau, because it
seems that other drivers actually do have this handled already as far as
I can tell.
Lyude Paul (13):
drm/nouveau: Fix bogus
Turns out this part is my fault for not noticing when reviewing
9a2eba337cace ("drm/nouveau: Fix drm poll_helper handling"). Currently
we call drm_kms_helper_poll_enable() from nouveau_display_hpd_work().
This makes basically no sense however, because that means we're calling
Currently, it appears that nouveau_do_suspend() forgets to roll back
suspending fbcon and suspending the device LEDs. We also currently skip
the entire rollback process if nouveau_display_suspend() fails. So, fix
that.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
Cc: Lukas Wunner
Cc:
It seems I did a wrong indication in the subject,
Am Montag, den 06.08.2018, 10:13 +0200 schrieb Gert Wollny:
> On evergreen depth-stencil textures are allocated as two objects, and
> when using the eg_surface_init_1d_miptrees code path the size
> evaluation
> uses the generalized surf_minify
https://bugs.freedesktop.org/show_bug.cgi?id=107518
--- Comment #2 from Shawn Anastasio ---
Upon further testing, the issue seems to go away when the firmware is removed
from petitboot, preventing it from initializing the card before the host OS.
This indicates that it may have something to do
Hi,
Le mardi 07 août 2018 à 22:18 +0200, Daniel Vetter a écrit :
> On Tue, Aug 07, 2018 at 09:39:19PM +0200, Paul Kocialkowski wrote:
> > Initializing and registering fbdev requires at least one DRM connector
> > and will fail otherwise. In order to support headless setups (for
> > instance for
On Tue, Aug 07, 2018 at 09:39:19PM +0200, Paul Kocialkowski wrote:
> Initializing and registering fbdev requires at least one DRM connector
> and will fail otherwise. In order to support headless setups (for
> instance for GPU rendering with the GBM backend, where a DRI card node
> is required to
As a driver write it is not entirely obvious that a reference to
the event e mentioned in the doc can be obtained via
drm_crtc_vblank_get(). Clarify how to obtain the reference.
Signed-off-by: Stefan Agner
---
drivers/gpu/drm/drm_vblank.c | 4 ++--
1 file changed, 2 insertions(+), 2
On 3 August 2018 at 02:55, Jyri Sarha wrote:
> Hi Dave,
> Please pull the tilcdc fixes for Linux v4.19. This fix has been pending
> for some while, because I was planning for a bigger clean up that would
> remove the need for this fix. But as it is the time for it - at least
> for v4.19 - is gone
https://bugs.freedesktop.org/show_bug.cgi?id=107518
--- Comment #1 from Shawn Anastasio ---
Created attachment 141003
--> https://bugs.freedesktop.org/attachment.cgi?id=141003=edit
dmesg for 4.18.0-rc8+
--
You are receiving this mail because:
You are the assignee for the
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
Initializing and registering fbdev requires at least one DRM connector
and will fail otherwise. In order to support headless setups (for
instance for GPU rendering with the GBM backend, where a DRI card node
is required to provide GEM memory reservation), add a check on the
number of registered
The HW only executes a load once the tile coordinates packet happens,
and only tracks one at a time, so by emitting our two MSAA loads back
to back we would end up with an undefined color or Z buffer.
Fixes dEQP-EGL.functional.render.multi_context.gles2.rgb888_window
Signed-off-by: Eric Anholt
https://bugs.freedesktop.org/show_bug.cgi?id=107518
Bug ID: 107518
Summary: polaris powerplay init fails: There must be 1 or more
PCIE levels defined in PPTable
Product: DRI
Version: unspecified
Hardware: PowerPC
On Tue, Aug 07, 2018 at 07:36:47PM +0100, Chris Wilson wrote:
> Since commit 9ea0dfbf972 ("dma-buf: make map_atomic and map function
> pointers optional"), the core provides the no-op functions when map and
> map_atomic are not provided, so we no longer need assert that are
> supplied by a dma-buf
On 06.08.2018 21:31, Leonard Crestez wrote:
> The lcdif block is only powered on when display is active so plane
> updates when not enabled are not valid. Writing to an unpowered IP block
> is mostly ignored but can trigger bus errors on some chips.
>
> Prevent this situation by switching to
Am 07.08.2018 um 20:32 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has
On 06.08.2018 21:31, Leonard Crestez wrote:
> Since power to the lcdif block can be lost on suspend implement
> PM_SLEEP_OPS using drm_mode_config_helper_suspend/resume to save/restore
> the current mode.
>
> Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
> ---
>
Since commit 9ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), the core provides the no-op functions when map and
map_atomic are not provided, so we no longer need assert that are
supplied by a dma-buf exporter.
Fixes: 09ea0dfbf972 ("dma-buf: make map_atomic and map
On 06.08.2018 21:31, Leonard Crestez wrote:
> Adding lcdif nodes to a power domain currently results in
> black/corrupted screens or hangs because power is not correctly enabled
> when required.
>
> Ensure power is on when display is active by adding
> pm_runtime_get/put_sync to
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
Quoting Christian König (2018-08-07 19:18:55)
> Am 07.08.2018 um 20:14 schrieb Chris Wilson:
> > Quoting Christian König (2018-08-07 18:57:16)
> >> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> >>> amdgpu only uses shared-fences internally, but dmabuf importers rely on
> >>> implicit write hazard
On 06.08.2018 21:31, Leonard Crestez wrote:
> LCDIF will repeatedly display data from CUR_BUF and set CUR_BUF to
> NEXT_BUF when done. Since we are only ever writing to NEXT_BUF the
> display will show an initial corrupt frame.
>
> Fix by writing the FB paddr to both CUR_BUF and NEXT_BUF when
>
Am 07.08.2018 um 20:14 schrieb Chris Wilson:
Quoting Christian König (2018-08-07 18:57:16)
Am 07.08.2018 um 18:08 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the
Quoting Christian König (2018-08-07 18:57:16)
> Am 07.08.2018 um 18:08 schrieb Chris Wilson:
> > amdgpu only uses shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
> > For example, the importer use the write hazard for
Am 07.08.2018 um 18:08 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has
Am 07.08.2018 um 19:47 schrieb Chris Wilson:
Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), we no longer need to provide stub no-op functions
as the core now provides them directly.
References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function
On Tue, Aug 07, 2018 at 06:47:48PM +0100, Chris Wilson wrote:
> Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
> pointers optional"), we no longer need to provide stub no-op functions
> as the core now provides them directly.
>
> References: 09ea0dfbf972 ("dma-buf: make
Since commit 09ea0dfbf972 ("dma-buf: make map_atomic and map function
pointers optional"), we no longer need to provide stub no-op functions
as the core now provides them directly.
References: 09ea0dfbf972 ("dma-buf: make map_atomic and map function pointers
optional")
Signed-off-by: Chris
Den 02.08.2018 21.45, skrev Sam Ravnborg:
Add driver for the winstar wg160160 display.
The driver utilises pardata-dbi that
again utilise the pardata subsystem.
Signed-off-by: Sam Ravnborg
---
MAINTAINERS| 5 +
drivers/gpu/drm/tinydrm/Kconfig| 10 ++
On Tue, Jul 24, 2018 at 02:27:33PM +0200, Mads Lønsethagen wrote:
> > Hey
> >
> > On request of Noralf, I picked up the patches and prepared v5. Works
> > fine with
> > Xorg, if configured according to:
> > https://lists.freedesktop.org/archives/dri-devel/2014-January/052777.html
> > If anyone
On Mon, Aug 06, 2018 at 06:58:29AM +0300, Haneen Mohammed wrote:
> This patch compute CRC for output frame with cursor and primary plane.
> Blend cursor with primary plane and compute CRC on the resulted frame.
>
> Signed-off-by: Haneen Mohammed
Nice!
I assume with this you're passing all the
On Mon, Aug 06, 2018 at 06:01:02PM +0200, Enric Balletbo i Serra wrote:
> From: Gustavo Padovan
>
> This flag tells core to jump ahead the queued update if the conditions
> in drm_atomic_async_check() are met. That means we are only able to do an
> async update if no modeset is pending and
Hi Sam,
Den 02.08.2018 21.45, skrev Sam Ravnborg:
The pardata supports implement a simple bus for devices
that are connected using a parallel bus driven by GPIOs.
The is often used in combination with simple displays
that is often seen in older embedded designs.
There is a demand for this
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
For example, the importer use the write hazard for timing a page flip to
only occur after the exporter has finished flushing its write into the
surface. As
Den 13.07.2018 15.46, skrev Thomas Zimmermann:
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann
---
Thanks, applied to drm-misc.
On 7 August 2018 at 14:39, Benjamin Gaignard
wrote:
> 2018-07-20 13:32 GMT+02:00 Benjamin Gaignard :
>> Signed-off-by: Benjamin Gaignard
>> ---
>> tests/util/kms.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/tests/util/kms.c b/tests/util/kms.c
>> index 8b3e7878..a2d1d7ba 100644
https://bugs.freedesktop.org/show_bug.cgi?id=103199
--- Comment #3 from Martin Peres ---
https://intel-gfx-ci.01.org/tree/drm-tip/drmtip_93/fi-icl-u/igt@drv_missed_irq.html
(drv_missed_irq:1510) CRITICAL: Test assertion failure function __real_main96,
file ../tests/drv_missed_irq.c:159:
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #5 from Mike ---
PS. security.sandbox.content.read_path_whitelist works.
Need to add /sys/ (with trailing slash, as
https://wiki.mozilla.org/Security/Sandbox says), and restart Firefox.
--
You are receiving this mail because:
You
On 7 August 2018 at 14:53, Daniel Stone wrote:
> Hi Emil,
> This is off-topic for the list, but ...
>
> On Tue, 7 Aug 2018 at 14:46, Emil Velikov wrote:
>> Aside: libdrm following X/Wayland in that it lacks contributor/push access
>> docs.
>> Might be worth, copying the Mesa ones and adding a
On Tue, Aug 7, 2018 at 3:54 PM, Christian König
wrote:
> Am 07.08.2018 um 15:37 schrieb Daniel Vetter:
>>
>> On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
>>>
>>> Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König
https://bugs.freedesktop.org/show_bug.cgi?id=107516
Mike changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #4 from Mike ---
(In reply to Emil Velikov from comment #3)
> https://bugzilla.mozilla.org/show_bug.cgi?id=1480755#c1
Indeed, this is Firefox's problem.
Аlthough security.sandbox.content.read_path_whitelist trick didn't work for
Am 07.08.2018 um 15:37 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at
Hi Emil,
This is off-topic for the list, but ...
On Tue, 7 Aug 2018 at 14:46, Emil Velikov wrote:
> Aside: libdrm following X/Wayland in that it lacks contributor/push access
> docs.
> Might be worth, copying the Mesa ones and adding a doc in-tree.
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #3 from Emil Velikov ---
The FF sandboxing is fairly, ahem, strange. The following Mozilla bug addresses
that.
https://bugzilla.mozilla.org/show_bug.cgi?id=1480755#c1
--
You are receiving this mail because:
You are the assignee
On 25 July 2018 at 15:00, Benjamin Gaignard
wrote:
> If "-a" option is set this make modetest use atomic API instead
> of legacy API.
>
> Test the frame rate ("-v") it does a loop and swap between two
> framebuffer for each active planes.
>
> Signed-off-by: Benjamin Gaignard
> ---
>
> version 3:
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #2 from Mike ---
One more thing. This bug might be firefox-specific, because other OpenGL apps,
say, glxgears, use correct driver and get HW accel.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=107516
Mike changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
|
https://bugs.freedesktop.org/show_bug.cgi?id=98629
Mike changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
|
https://bugs.freedesktop.org/show_bug.cgi?id=107384
Mike changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
|
https://bugs.freedesktop.org/show_bug.cgi?id=107516
--- Comment #1 from Mike ---
Possibly related to bugs 107384 and/or 98629.
If firefox start with LIBGL_DEBUG=verbose parameter, it shows:
libGL error: MESA-LOADER: failed to retrieve device information
libGL error: unable to load driver:
https://bugs.freedesktop.org/show_bug.cgi?id=107516
Mike changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
|
2018-07-20 13:32 GMT+02:00 Benjamin Gaignard :
> Signed-off-by: Benjamin Gaignard
> ---
> tests/util/kms.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/tests/util/kms.c b/tests/util/kms.c
> index 8b3e7878..a2d1d7ba 100644
> --- a/tests/util/kms.c
> +++ b/tests/util/kms.c
> @@ -144,6
https://bugs.freedesktop.org/show_bug.cgi?id=107516
Bug ID: 107516
Summary: Firefox for WebGL fallbacks to swrast_dri.so, not
using radeon_si.so
Product: DRI
Version: DRI git
Hardware: Other
OS: All
On Tue, Aug 07, 2018 at 03:17:06PM +0200, Christian König wrote:
> Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
> > On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
> > > Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
> > > > On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian
2018-08-06 8:19 GMT+02:00 Peter Rosin :
> Removing the drm_bridge_remove call should avoid a NULL dereference
> during list processing in drm_bridge_remove if the error path is ever
> taken.
>
> The more natural approach would perhaps be to add a drm_bridge_add,
> but there are several other
On Tue, Aug 07, 2018 at 09:03:27AM +0100, Alexandru-Cosmin Gheorghe wrote:
> Hi Sinclair,
>
> Is it ok if I merge this patch through drm-misc-next ?
Sure. Thanks for handling this.
Sinclair
> Thank you,
> Alex Gheorghe
>
> On Mon, Aug 06, 2018 at 09:57:53AM -0700, Sinclair Yeh wrote:
> >
On 7 August 2018 at 13:28, Daniel Vetter wrote:
> On Tue, Aug 07, 2018 at 12:01:50PM +0100, Emil Velikov wrote:
>> On 3 August 2018 at 20:50, Sean Paul wrote:
>> > On Fri, Aug 03, 2018 at 06:03:50PM +0100, Emil Velikov wrote:
>> >> On 3 August 2018 at 16:06, Martin Fuzzey
>> >> wrote:
>> >> >
Hi Mike,
it is not the right mailing list, but thanks for the info.
I'm going to push that patch ASAP.
Christian.
Am 07.08.2018 um 14:38 schrieb Mike Lothian:
Hi
I'm not sure if this is the right mailing list or not but the
following patch gets things building with meson again
Am 07.08.2018 um 14:59 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 02:51:50PM +0200, Christian König wrote:
Am 07.08.2018 um 14:43 schrieb Daniel Vetter:
On Tue, Aug 07, 2018 at 01:23:19PM +0200, Christian König wrote:
Am 07.08.2018 um 13:05 schrieb Chris Wilson:
amdgpu only uses
Hi,
On 01/08/18 10:36, Chanwoo Choi wrote:
> Hi Enric,
>
> On 2018년 07월 30일 17:11, Enric Balletbo i Serra wrote:
>> Some rk3399 GRF (Generic Register Files) definitions can be used for
>> different drivers. Move these definitions to a common include so we
>> don't need to duplicate these
On 2018-08-03 13:15, Daniel Thompson wrote:
On Fri, Aug 03, 2018 at 12:49:34PM +0530, kgu...@codeaurora.org wrote:
Hi Bjorn,
Can you please help review this patch series ?
Pavel, Rob, Daniel reviewed the series except the "auto string
detection"
patch.
I did take a glance at the last
convert drm_atomic_helper_suspend/resume() to use
drm_mode_config_helper_suspend/resume().
Fixed one sparse warning by making hibmc_drm_interrupt
static.
Signed-off-by: Ajit Negi
Signed-off-by: Souptick Joarder
Reviewed-by: Xinliang Liu
---
v2: remove ret variable from both suspend and
On Mon 09 Jul 03:22 PDT 2018, Kiran Gunda wrote:
> diff --git a/drivers/video/backlight/qcom-wled.c
> b/drivers/video/backlight/qcom-wled.c
[..]
> @@ -365,6 +434,15 @@ static int wled_configure(struct wled *wled, struct
> device *dev)
>
> cfg->num_strings = cfg->num_strings + 1;
>
> +
Adding lcdif nodes to a power domain currently does work, it results in
black/corrupted screens or hangs. While the driver does enable runtime
pm it does not deal correctly with the block being unpowered.
Changes since v2:
* Split into multiple commits.
* Use #ifdef CONFIG_PM_SLEEP.
* Switch
1 - 100 of 134 matches
Mail list logo
