https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #18 from Robin ---
Same problem for me.
Using 2 identical DELL U2415 and a Radeon RX 580.
On Arch with 4.18.x Daisychainig both monitors worked like a charm.
After upgrading to 4.19 the monitors only work when I`m disableing DP1.2. B
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #19 from Shmerl ---
This seem to commonly affect Dell monitors. Do they not follow DisplayPort 1.2
spec, or amdgpu is doing something incorrectly after all?
--
You are receiving this mail because:
You are the assignee for the bug._
dadb36b7ec42 ("drm/msm: Add a common function to free kernel buffer objects")
missed freeing the crashdumper state for a6xx.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/gpu/dr
Add a buffer object name for the a6xx crashdumper so it can be
seen with the changes introduced by 7799a98edd
("drm/msm: Add a name field for gem objects").
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
dif
The GMU code currently has some misguided code to try to work around
a hardware quirk that requires the power domains on the GPU be
collapsed in a certain order. Future changes will do this the
right way so get rid of the unused and unwanted regulator
code.
Signed-off-by: Jordan Crouse
---
drive
On 2018-11-26 13:53, Sean Paul wrote:
On Mon, Nov 19, 2018 at 12:03:53PM -0800, Jeykumar Sankaran wrote:
On 2018-11-16 13:14, Sean Paul wrote:
> On Fri, Nov 16, 2018 at 12:05:09PM -0800, Jeykumar Sankaran wrote:
> > On 2018-11-16 10:42, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > It's fo
On 2018-11-16 10:42, Sean Paul wrote:
From: Sean Paul
power_events are only used for pm_runtime, and that's all handled in
dpu_kms. So just call vbif_init_memtypes at the correct times.
Changes in v2:
- Removed obsolete comment (Jeykumar)
Cc: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
On 2018-11-16 10:42, Sean Paul wrote:
From: Sean Paul
Add a bool to dpu_encoder_virt to track whether the encoder is enabled
or not. Repurpose the enc_lock mutex to ensure that it is consistent
with the hw state.
Changes in v2:
- None
Cc: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
Revi
On 2018-11-16 10:42, Sean Paul wrote:
From: Sean Paul
The crtc runtime resume doesn't actually operate on the crtc, but
rather
its encoders. The problem with this is that we need to inspect the crtc
state to get the currently connected encoders. Since runtime resume
isn't guaranteed to be cal
On 2018-11-30 14:00, Sean Paul wrote:
From: Sean Paul
This patch wraps dpu_core_perf_crtc_release_bw() with modeset locks
since it digs into the state objects.
Changes in v2:
- None
Changes in v3:
- Use those nifty new DRM_MODESET_LOCK_ALL_* helpers (Daniel)
Cc: Daniel Vetter
Cc: Jeykumar Sa
From: Sean Paul
Since dpu_crtc subclasses crtc_state, we need a custom .reset hook in
order to allocate the right amount of memory to accommodate the
additional struct members in dpu_crtc_state. So bring it [partially]
back.
Relevant KASAN splat:
[ 10.82]
=
https://bugs.freedesktop.org/show_bug.cgi?id=108934
Bug ID: 108934
Summary: [Dualscreen] "No signal" issues when booting with DVI
and HDMI screens both plugged in
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
On Fri, 2018-11-30 at 15:35 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > i915 yet don't support PSR in Apple panels, so lets keep it
> > disabled
> > while we work on that.
> >
> > v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to
>
With DEBUG_SLAB (poisoning on free) enabled, I could quickly produce
an oops when tracing V3D.
Signed-off-by: Eric Anholt
---
I think this patch is correct (though maybe a bigger refactor could
avoid the extra get/put?), but I've still got this with "vblank_mode=0
perf record -a -e v3d:.\* -e gp
From: Jérôme Glisse
To avoid having to change many callback definition everytime we want
to add a parameter use a structure to group all parameters for the
mmu_notifier invalidate_range_start/end callback. No functional changes
with this patch.
Signed-off-by: Jérôme Glisse
Cc: Andrew Morton
Cc
From: Jérôme Glisse
CPU page table update can happens for many reasons, not only as a result
of a syscall (munmap(), mprotect(), mremap(), madvise(), ...) but also
as a result of kernel activities (memory compression, reclaim, migration,
...).
Users of mmu notifier API track changes to the CPU p
From: Jérôme Glisse
To avoid having to change many call sites everytime we want to add a
parameter use a structure to group all parameters for the mmu_notifier
invalidate_range_start/end cakks. No functional changes with this
patch.
Signed-off-by: Jérôme Glisse
Cc: Andrew Morton
Cc: Matthew Wi
From: Jérôme Glisse
This patchset add contextual information, why an invalidation is
happening, to mmu notifier callback. This is necessary for user
of mmu notifier that wish to maintains their own data structure
without having to add new fields to struct vm_area_struct (vma).
For instance devic
On Fri, 2018-11-30 at 15:54 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > As we have a else block for the 'if (dev_priv->psr.psr2_enabled) {'
> > and this bit is only set for PSR1 move it to that block to make it
> > more easy to read.
> >
On 2018-12-03 06:21, Sean Paul wrote:
On Fri, Nov 30, 2018 at 04:21:15PM -0800, Jeykumar Sankaran wrote:
On 2018-11-30 12:07, Sean Paul wrote:
> On Fri, Nov 30, 2018 at 11:45:55AM -0800, Jeykumar Sankaran wrote:
> > On 2018-11-29 14:15, Sean Paul wrote:
> > > On Tue, Nov 20, 2018 at 02:04:14PM -
Dave Emett writes:
> On Mon, 3 Dec 2018 at 17:22, Dave Emett wrote:
>>
>> > + * The caches (L1T, slice, and L2T) will be flushed before the job
>> > + * executes. The TLB writes are guaranteed to have been flushed by
>>
>> I would say before *each* job executes, as the caches are flushed
>> bef
On Fri, 2018-11-30 at 15:35 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > i915 yet don't support PSR in Apple panels, so lets keep it
> > disabled
> > while we work on that.
> >
> > v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to
>
On Fri, 2018-11-30 at 16:37 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > Selective updates have a default granularity requirements as stated
> > by eDP spec
> Needs reference to the location in the spec.
Done
>
> > , so check if HW can m
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #5 from tempel.jul...@gmail.com ---
Thanks for the explanation, I misunderstood you.
So I've tested night colors in a KDE Plasma Wayland session: And indeed, it
shows the same behavior as RedShift on Xorg (stutter with amdgpu.dc=1, n
On 2018-11-28 4:14 a.m., Joonas Lahtinen wrote:
> Quoting Ho, Kenny (2018-11-27 17:41:17)
>> On Tue, Nov 27, 2018 at 4:46 AM Joonas Lahtinen
>> wrote:
>>> I think a more abstract property "% of GPU (processing power)" might
>>> be a more universal approach. One can then implement that through
>>
On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> According to eDP spec, sink can required specific selective update
> granularity that source must comply.
> Here caching the value if required and checking if source supports
> it.
>
> Cc: Rodrigo Vivi
> Cc: Dhinakaran Pandiyan
>
On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote:
> On 21.11.2018 19:19, Laurent Pinchart wrote:
> > Hi Ville,
> >
> > Thank you for the patch.
> >
> > On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote:
> >> From: Ville Syrjälä
> >>
> >> Make life easier for drivers by sim
On Fri, Nov 30, 2018 at 05:00:02PM -0500, Sean Paul wrote:
> From: Sean Paul
>
> This patch wraps dpu_core_perf_crtc_release_bw() with modeset locks
> since it digs into the state objects.
>
> Changes in v2:
> - None
> Changes in v3:
> - Use those nifty new DRM_MODESET_LOCK_ALL_* helpers (Daniel
On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
> Quite late, hopefully not too late.
>
>
> On 21.11.2018 12:51, Ville Syrjälä wrote:
> > On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> >>
> >>> return;
> >>> diff --git a/drivers/gpu/drm/bridge/sil-sii8620.
Now that I've specified how the end-of-pipeline flushing should work,
we're never going to use this function.
Signed-off-by: Eric Anholt
Reviewed-by: Dave Emett
---
drivers/gpu/drm/v3d/v3d_drv.h | 1 -
drivers/gpu/drm/v3d/v3d_gem.c | 21 -
2 files changed, 22 deletions(-)
This cache was replaced with the slice accessing the L2T in the newer
generations. Noted by Dave during review.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_gem.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gp
This is the write combiner for TMU writes. You're supposed to flush
that at job end if you had dirtied any cachelines. Flushing it at job
start then doesn't make any sense.
Signed-off-by: Eric Anholt
Fixes: 57692c94dcbe ("drm/v3d: Introduce a new DRM driver for Broadcom V3D
V3.x+")
Reviewed-by
This would be a fairly obscure race, but let's make sure we don't ever
lose it.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/v3d/v3d_gem.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index 8a4be951517
Right now, userspace doesn't do any L2T writes, but we should lay out
our expectations for how it works.
v2: Explicitly mention the VCD cache flushing requirements and that
we'll flush the other caches before each of the CLs.
Signed-off-by: Eric Anholt
---
include/uapi/drm/v3d_drm.h | 8 +++
According to Dave, once you've started an L2T flush, all L2T accesses
will be blocked until the flush completes. This fixes a consistent
3-4ms stall between the ioctl and running the job, and 3DMMES Taiji
goes from 27fps to 110fps.
v2: Leave a note about why we don't need to wait for completion.
DPU is short for the Display Processing Unit. It is the display
controller on Qualcomm SDM845 chips.
This change adds MDSS and DSI nodes to enable display on the
target device.
Changes in v2:
- Beefed up commit message
- Use SoC specific compatibles for mdss and dpu (Rob H)
https://bugs.freedesktop.org/show_bug.cgi?id=108577
--- Comment #35 from Duncan Roe ---
Tried to add a comment just now but got server failure
--- Comment #36 from Duncan Roe ---
Tried to add a comment just now but got server failure
--- Comment #37 from Duncan Roe ---
Control key straight aw
On Mon, 2018-12-03 at 12:59 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > According to eDP spec, sink can required specific selective update
> > granularity that source must comply.
> > Here caching the value if required and checking if sour
On Mon, 2018-12-03 at 12:14 -0800, Souza, Jose wrote:
> On Fri, 2018-11-30 at 15:35 -0800, Dhinakaran Pandiyan wrote:
> > On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > > i915 yet don't support PSR in Apple panels, so lets keep it
> > > disabled
> > > while we work on that.
> >
dpu_crtc_get_mixer_height() is only used once and the value it
returns can be easily derived from the calling function.
v3: No changes
Reviewed-by: Sean Paul
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c | 3 +--
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.h | 13 --
dpu_irq.c does some unneeded checks and passes control
to dpu_core_irq.c The simple functions can be defined
in the same file where we use them and the files and
their associated hangers on can be deleted.
Additionally the postinstall hook isn't used even
in dpu_core_irq.c so zap that entire path
Outside of superfluous parameter checks the dpu_hw_blk_init()
doesn't have any failure paths. Switch it over to be a void
function and we can remove error handling paths in all the functions
that call it. While we're in those functions remove unneeded
initialization for a static variable.
v3: No c
Remove some unused container_of() helper functions.
v3: No changes
v2: Retained still used helper functions in the name of readability
Reviewed-by: Sean Paul
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h | 10 --
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_p
Allow the KMS operation 'irq_postinstall' to be optional
so that the target display drivers don't need to define
a dummy function if they don't need one.
v3: No changes
Reviewed-by: Sean Paul
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.c | 6 +-
1 file changed, 5 insertion
Remove more static inline functions that are lightly used and/or
very simple and easy to build into the calling functions.
v3: Fix a nit from Sean Paul
v2: Removed another unused function from dpu_hw_lm.c and add back
dpu_crtc_get_client_type() since there was a question regarding
its usefulness.
Do some debugfs cleanups from across the DPU driver. The DRM
destroy functions will do a recursive delete on the entire
debugfs node so there is no need to store dentry pointers for
the debugfs files that are persistent for the life of the
driver. This also means that the destroy functions can go
a
This is a rebase of
https://patchwork.freedesktop.org/series/51214/
On top of
https://gitlab.freedesktop.org/seanpaul/dpu-staging/tags/for_jcrouse
Which should be up to date for the latest and greatest of the DPU. This should
be mostly unchanged since the last revision with the exception that
The functions in dpu_dbg.c aren't used. The two main dump functions
fail after a lookup from dpu_dbg_base.reg_base_list which turns out
to never be populated and once those are removed the rest of the
file doesn't make any sense.
v3: No changes
v2: Moved some unrelated changes to another patch
Re
Do some cleanup in the static inline functions defined in
dpu_media_info.h by cleaning up gotos and unneeded local
variables.
v3: Added spaces between operators per Seal Paul and Sam Ravnborg
Reviewed-by: Sean Paul
Signed-off-by: Jordan Crouse
---
.../gpu/drm/msm/disp/dpu1/msm_media_info.h
The static inline function dpu_crtc_enabled() is only called once
and the function that calls it in turn is only called once and
the return value can be easily checked in the calling functions
so collapse everything down.
v3: No changes
Reviewed-by: Sean Paul
Signed-off-by: Jordan Crouse
---
d
https://bugs.freedesktop.org/show_bug.cgi?id=108912
Samantha McVey changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, 2018-12-03 at 14:45 -0800, Dhinakaran Pandiyan wrote:
> On Mon, 2018-12-03 at 12:14 -0800, Souza, Jose wrote:
> > On Fri, 2018-11-30 at 15:35 -0800, Dhinakaran Pandiyan wrote:
> > > On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > > > i915 yet don't support PSR in Apple p
https://bugs.freedesktop.org/show_bug.cgi?id=108919
--- Comment #3 from Markus ---
Similar issue with black flickering reported here on an RX480 with Mesa 18.2.2
and ambient occlusion turned on:
https://old.reddit.com/r/ThemeParkitect/comments/a1mt60/graphics_issue_black_flickering_all_over_the_p
On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> - Reusing the EDP_PSR2_FRAME_BEFORE_SU_SHIFT in
> EDP_PSR2_FRAME_BEFORE_SU
> - Removing unused EDP_PSR2_FRAME_BEFORE_SU_MASK
> - Adding EDP_PSR2_FRAME_BEFORE_SU_MAX
> - Adding EDP_PSR2_IDLE_FRAME()
> - Adding EDP_PSR2_IDLE_FRAME_MAX
On Mon, Dec 03, 2018 at 03:03:52PM -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > - Reusing the EDP_PSR2_FRAME_BEFORE_SU_SHIFT in
> > EDP_PSR2_FRAME_BEFORE_SU
> > - Removing unused EDP_PSR2_FRAME_BEFORE_SU_MASK
> > - Adding EDP_PSR2_FRAME_BEF
On Mon, 2018-12-03 at 14:45 -0800, Souza, Jose wrote:
> On Mon, 2018-12-03 at 12:59 -0800, Dhinakaran Pandiyan wrote:
> > On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > > According to eDP spec, sink can required specific selective
> > > update
> > > granularity that source must
On Mon, 2018-12-03 at 15:12 -0800, Pandiyan, Dhinakaran wrote:
> On Mon, 2018-12-03 at 14:45 -0800, Souza, Jose wrote:
> > On Mon, 2018-12-03 at 12:59 -0800, Dhinakaran Pandiyan wrote:
> > > On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > > > According to eDP spec, sink can requ
https://bugs.freedesktop.org/show_bug.cgi?id=107823
--- Comment #23 from Drexler ---
Hi Jan,
thanks for the video.
just like to ask, were you also able to try on using another DP cable? short
and or thicker DP cable?
Also, would just like to ask if you observe the issue on Ubuntu 18.10? I tested
On Wed, Nov 21, 2018 at 05:20:55PM -0800, Andrew Morton wrote:
> On Tue, 20 Nov 2018 15:12:49 -0800 Dan Williams
> wrote:
[...]
> > I am also concerned that HMM was designed in a way to minimize further
> > engagement with the core-MM. That, with these hooks in place,
> > device-drivers are fre
On Mon, Dec 03, 2018 at 03:26:26PM -0800, Brendan Higgins wrote:
> On Thu, Nov 29, 2018 at 7:40 PM Luis Chamberlain wrote:
> >
> > On Wed, Nov 28, 2018 at 11:36:24AM -0800, Brendan Higgins wrote:
> > > Add a test for string stream along with a simpler example.
> > >
> > > Signed-off-by: Brendan Hi
On Mon, Dec 03, 2018 at 03:34:57PM -0800, Brendan Higgins wrote:
> On Thu, Nov 29, 2018 at 7:34 PM Luis Chamberlain wrote:
> >
> > On Wed, Nov 28, 2018 at 11:36:25AM -0800, Brendan Higgins wrote:
> > > diff --git a/arch/um/kernel/trap.c b/arch/um/kernel/trap.c
> > > index cced829460427..bf90e678b3
On Mon, Dec 03, 2018 at 03:18:16PM -0500, jgli...@redhat.com wrote:
> diff --git a/mm/migrate.c b/mm/migrate.c
> index f7e4bfdc13b7..4896dd9d8b28 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -2303,8 +2303,13 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
> */
> static void migrate_v
https://bugzilla.kernel.org/show_bug.cgi?id=201867
Bug ID: 201867
Summary: Nouveau + discrete GPU (GP104M = GTX 1070 M) Driver
Crashes, System freezes, dual screen not working
Product: Drivers
Version: 2.5
Kernel Version: 4.19.4-
Hi,
On Mon, Dec 3, 2018 at 2:27 PM Jeykumar Sankaran wrote:
> + dsi0: dsi@ae94000 {
> + compatible = "qcom,mdss-dsi-ctrl";
> + reg = <0xae94000 0x400>;
> + reg-names = "dsi_ctrl";
> +
>
+People in community.
Rodrigo,
Thanks for the kind info.
What's the answer to below question?
I find i915 binds one pipeline per display. It means even with DP1.2 MST, i915
driver still restricts the display number to the display pipeline
number. Am I right?
In addition, I might mislead you a
On 2018-12-03 16:57, Doug Anderson wrote:
Hi,
On Mon, Dec 3, 2018 at 2:27 PM Jeykumar Sankaran
wrote:
+ dsi0: dsi@ae94000 {
+ compatible = "qcom,mdss-dsi-ctrl";
+ reg = <0xae94000 0x400>;
+
> -Original Message-
> From: Christian König
> Sent: Monday, December 03, 2018 9:56 PM
> To: Zhou, David(ChunMing) ; Koenig, Christian
> ; dri-devel@lists.freedesktop.org; amd-
> g...@lists.freedesktop.org
> Subject: Re: [PATCH 02/11] dma-buf: add new dma_fence_chain container
> v2
>
>
On 2018-12-03 06:47, Sean Paul wrote:
On Tue, Nov 27, 2018 at 02:28:30PM -0800, Jeykumar Sankaran wrote:
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
This change is based on the SDM845 Display port
driver changes[1].
changes in v
+intel-gfx.
> -Original Message-
> From: Zhang, Yanmin
> Sent: Tuesday, December 04, 2018 10:31 AM
> To: Vivi, Rodrigo ; Deak, Imre
> Cc: Syrjala, Ville ; dri-devel@lists.freedesktop.org
> Subject: RE: DP1.2 MST HUB
>
> +People in community.
>
> Rodrigo,
>
> Thanks for the kind info.
>
On 2018年12月04日 14:39, Wei Yongjun wrote:
Fix the return value check which testing the wrong variable
in amdgpu_allocate_static_csa().
Fixes: 7946340fa389 ("drm/amdgpu: Move csa related code to separate file")
Signed-off-by: Wei Yongjun
---
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c | 2 +-
1
https://bugs.freedesktop.org/show_bug.cgi?id=108487
--- Comment #7 from Duane Voth ---
lspci on my laptop lists:
Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express
Integrated Graphics Controller (rev 03)
I get the same errors when trying to start weston:
...
[] failed
https://bugs.freedesktop.org/show_bug.cgi?id=108487
--- Comment #8 from Duane Voth ---
ugh. typo. $ weston --use-pixman
(can't edit comments?)
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-
On 03.12.2018 22:48, Ville Syrjälä wrote:
> On Thu, Nov 29, 2018 at 09:46:16AM +0100, Andrzej Hajda wrote:
>> Quite late, hopefully not too late.
>>
>>
>> On 21.11.2018 12:51, Ville Syrjälä wrote:
>>> On Wed, Nov 21, 2018 at 01:40:43PM +0200, Jani Nikula wrote:
> return;
> diff --
Am 03.12.18 um 21:14 schrieb Eric Anholt:
> With DEBUG_SLAB (poisoning on free) enabled, I could quickly produce
> an oops when tracing V3D.
Good catch, but the solution is a clear NAK.
drm_sched_entity_add_dependency_cb() can result in setting
entity->dependency to NULL. That in turn can lead t
Am 03.12.18 um 21:18 schrieb jgli...@redhat.com:
> From: Jérôme Glisse
>
> This patchset add contextual information, why an invalidation is
> happening, to mmu notifier callback. This is necessary for user
> of mmu notifier that wish to maintains their own data structure
> without having to add ne
Hi Yongjun,
This issue has been fixed.
Thanks.
Best Regards
Rex
commit 51f1f6f51712aade68cabb145ed8bab4a6c3997e
Author: Rex Zhu
Date: Fri Nov 23 18:52:21 2018 +0800
drm/amdgpu: Fix static checker warning
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c:49 amdgpu_allocate_static_csa()
On 03.12.2018 22:38, Ville Syrjälä wrote:
> On Thu, Nov 29, 2018 at 10:08:07AM +0100, Andrzej Hajda wrote:
>> On 21.11.2018 19:19, Laurent Pinchart wrote:
>>> Hi Ville,
>>>
>>> Thank you for the patch.
>>>
>>> On Tuesday, 20 November 2018 18:13:42 EET Ville Syrjala wrote:
From: Ville Syrjälä
101 - 177 of 177 matches
Mail list logo
