Hi Sinclair,
Is it ok if I merge this patch through drm-misc-next ?
Thank you,
Alex Gheorghe
On Mon, Aug 06, 2018 at 09:57:53AM -0700, Sinclair Yeh wrote:
> Acked-by: Sinclair Yeh
>
> On Sat, Aug 04, 2018 at 05:15:30PM +0100, Alexandru Gheorghe wrote:
> > A new helper function(__drm_atomic_hel
2018년 07월 26일 00:46에 Andrzej Hajda 이(가) 쓴 글:
> From: Maciej Purski
>
> The current implementation assumes that the only possible peripheral
> device for DSIM is a panel. Using an output bridge child device
> should also be possible.
>
> If an output bridge is available, don't create a new conn
Hi, CK:
On Tue, 2018-08-07 at 11:33 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Mon, 2018-08-06 at 19:58 +0800, Stu Hsieh wrote:
> > This patch add YUYV/UYVY color format support for RDMA
> > and transform matrix for YUYV/UYVY.
> >
> > Signed-off-by: Stu Hsieh
> > ---
> > drivers/gpu/drm/mediatek/mt
Hi, CK:
On Tue, 2018-08-07 at 11:01 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Mon, 2018-08-06 at 19:58 +0800, Stu Hsieh wrote:
> > This patch add RGB color format support for RDMA,
> > including RGB565, RGB888, RGBA and ARGB.
> >
> > Signed-off-by: Stu Hsieh
> > ---
> > drivers/gpu/drm/med
Hi,CK:
On Tue, 2018-08-07 at 12:32 +0800, CK Hu wrote:
> Hi, Stu:
>
> On Mon, 2018-08-06 at 19:58 +0800, Stu Hsieh wrote:
> > This patch use layer_nr function to get layer number to init plane
> >
> > When plane init in crtc create,
> > it use the number of OVL layer to init plane.
> > That's OV
Thanks for that!
Reviewed-by: Kent Russell
-Original Message-
From: amd-gfx On Behalf Of Huang Rui
Sent: Tuesday, August 07, 2018 1:28 AM
To: Gustavo A. R. Silva ; Kuehling, Felix
Cc: Oded Gabbay ; Zhou, David(ChunMing)
; David Airlie ;
linux-ker...@vger.kernel.org; amd-...@lists.fre
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 s
On Mon, 2018-08-06 at 22:31 +0300, 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
On Tue, Aug 07, 2018 at 11:45:00AM +0100, Chris Wilson wrote:
> 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 aft
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 Emil,
>> >
>> > On 03/08/18 14:35, Emil Velikov wrote:
>> >>
>> >> Hi Martin,
>> >>
>> >> On 1 August 2018 at 15:24, Martin Fu
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 s
Quoting Huang Rui (2018-08-07 11:56:24)
> On Tue, Aug 07, 2018 at 11:45:00AM +0100, Chris Wilson wrote:
> > 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 h
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 s
Am 07.08.2018 um 13:05 schrieb Chris Wilson:
amdgpu only uses shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_excl.
Well I would rather suggest a solution where we stop doing this.
The problem here is that i915 assumes that
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 Emil,
> >> >
> >> > On 03/08/18 14:35, Emil Velikov wr
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 shared-fences internally, but dmabuf importers rely on
> > implicit write hazard tracking via the reservation_object.fence_excl.
>
> Well I would rather suggest a so
On Tue, Aug 07, 2018 at 02:43:22PM +0200, Daniel Vetter wrote:
> 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 shared-fences internally, but dmabuf importers rely on
> > > implicit write hazard tracking via t
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 shared-fences internally, but dmabuf importers rely on
implicit write hazard tracking via the reservation_object.fence_exc
Make sure we access last_scheduled only after checking that there are no
more jobs on the entity.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/gpu_scheduler.c | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/gpu
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 shared-fences internally, but dmabuf impo
On Mon 09 Jul 03:22 PDT 2018, Kiran Gunda wrote:
> WLED4 peripheral is present on some PMICs like pmi8998 and
> pm660l. It has a different register map and configurations
> are also different. Add support for it.
>
> Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
Regards,
Bjorn
> --
Add support to async updates of cursors by using the new atomic
interface for that.
Signed-off-by: Enric Balletbo i Serra
---
Hi,
This first version is slightly different from the RFC, note that I did
not maintain the Sean reviewed tag for that reason. With this version I
don't touch the atomic_
On Mon, Aug 06, 2018 at 12:15:48PM +0300, Dan Carpenter wrote:
> Hi Sam,
>
> I love your patch! Perhaps something to improve:
>
> url:
> https://github.com/0day-ci/linux/commits/Sam-Ravnborg/dt-bindings-add-parallel-data-bus-pardata/20180803-090135
>
> smatch warnings:
> drivers/gpu/drm/tiny
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 mxsfb_pipe_enable/disable.
Signed-off-by: Leonard Crestez
---
drivers/g
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
[..]
> @@ -189,6 +206,15 @@ static int wled4_set_brightness(struct wled *wled, u16
> brightness)
> return 0;
> }
>
> +static void wled_ovp_work(stru
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 drm_atomic_helper_commit_tail_rpm
and having the drm core e
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
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 21 +
1 file changed, 21 insertions(+)
diff --git
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 update for the same plane is
not queued.
It uses the already in place infrastructure fo
Hi Daniel,
On 30/07/18 13:12, Daniel Thompson wrote:
> On Fri, Jul 27, 2018 at 05:11:21PM +0200, Enric Balletbo i Serra wrote:
>> The "atomic" API allows us to configure PWM period and duty_cycle and
>> enable it in one call.
>>
>> The patch also moves the pwm_init_state just before any use of the
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
activating the CRTC.
Signed-off-by: Leonard Crestez
---
On Mon 09 Jul 03:22 PDT 2018, Kiran Gunda wrote:
> diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
> b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.txt
[..]
> - qcom,num-strings
> Usage:optional
> Value type:
> Definition: #
On Thu, Aug 02, 2018 at 10:34:21AM +0100, Russell King wrote:
> Hi David,
>
> The following changes since commit 4da1d4c751c9b1b713c13043bad7c4d27cd1418c:
>
> Merge commit 'refs/for-upstream/mali-dp' of git://linux-arm.org/linux-ld
> into drm-next (2018-07-06 10:02:13 +1000)
>
> are available
On 06/08/18 21:05, Rob Herring wrote:
On Fri, Aug 3, 2018 at 1:50 PM Sean Paul wrote:
Fwiw, I'd lean towards allowing DUMB allocation from the render nodes. I
understand it limits use cases that are undesirable, but it is also limiting
usecases that are desirable. So, given that people are goin
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 patch.
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 resume.
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 to
On Mon 09 Jul 03:22 PDT 2018, Kiran Gunda wrote:
> Rename the PM8941* references as WLED3 to make the
> driver generic and have WLED support for other PMICs.
>
> Signed-off-by: Kiran Gunda
I agree with Daniel, regarding the mentioning of the variable rename.
Apart from that:
Reviewed-by: Bjor
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 definiti
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 shared-fe
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
Signed-of-by:
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:
>> >> > H
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:
> > Acked
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 bridge
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 König
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
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: amdgpu
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=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 bug.__
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 #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 fo
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://gitlab.freedesktop.org/wayland/wayland
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 0
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 me
https://bugs.freedesktop.org/show_bug.cgi?id=107516
Mike changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 wr
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 do
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 a
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:
(drv_mis
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
>
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.
Noral
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 s
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 suppor
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 update
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 kno
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 c
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 ++
drivers/
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 Wilson
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 map_
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 p
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 fin
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 t
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
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
> ac
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
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 s
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 mxsfb_pipe_enable/
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 func
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
> ---
> drivers/gpu/drm/mxs
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 fin
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 drm_a
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
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
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
C
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 con
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 s
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&action=edit
dmesg for 4.18.0-rc8+
--
You are receiving this mail because:
You are the assignee for the bug.__
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
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 deletions(-)
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 p
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 GP
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 wi
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 fun
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
drm_kms_helper_poll_en
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: Kar
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 drm_kms_helper_poll_en
1 - 100 of 135 matches
Mail list logo
