On Tue, Jul 14, 2020 at 4:54 PM Bjorn Andersson
wrote:
>
> On Tue 14 Jul 15:13 PDT 2020, Rob Herring wrote:
>
> > On Tue, Jul 14, 2020 at 10:33 AM Jeffrey Hugo
> > wrote:
> > >
> > > On Mon, Jul 13, 2020 at 5:50 PM Doug Anderson
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Mon, Jul 13,
From: Rob Clark
If there is no interconnect-names, but there is an interconnects
property, then of_icc_get(dev, "gfx-mem"); would return an error
rather than NULL.
Also, if there is no interconnect-names property, there will never
be a ocmem path. But of_icc_get(dev, "ocmem") would return
From: Rob Clark
If there is no interconnect-names, but there is an interconnects
property, then of_icc_get(dev, "gfx-mem"); would return an error
rather than NULL.
Also, if there is no interconnect-names property, there will never
be a ocmem path. But of_icc_get(dev, "ocmem") would return
On Wed, Jul 15, 2020 at 9:56 PM Dave Airlie wrote:
>
> On Thu, 16 Jul 2020 at 00:59, Thomas Zimmermann wrote:
> >
> > This patchset puts device initialization in the correct order and
> > adds support for G200 Desktop chips (PCI ids 0x520 and 0x521).
>
> why? :-)
>
> I'm pretty sure I NAKed the
Hi Dave and Daniel,
here is the PR for the current drm-misc-fixes. The aspeed fix is only
about dmesg noise. The dmabuf locking appears to be a real bug.
Best regards
Thomas
drm-misc-fixes-2020-07-15:
* aspeed: setup fbdev console after registering device; avoids warning
and stacktrace in
On Sat, 13 Jun 2020 19:36:46 +0530, Kamlesh Gurudasani wrote:
> Add vendor prefix for display manufacturer company EastRising
> Technology Co.,Ltd
>
> [1]https://eastrising.en.ec21.com/
>
> Signed-off-by: Kamlesh Gurudasani
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml | 2 ++
https://bugzilla.kernel.org/show_bug.cgi?id=208573
Bug ID: 208573
Summary: Black screen on boot if two displays plugged in with
NAVI 10
Product: Drivers
Version: 2.5
Kernel Version: 5.7.8-6-MANJARO
Hardware: x86-64
From: Rob Clark
If split-lm is used (for ex, on sdm845), we can have multiple ping-
pongs, but only a single phys encoder. We need to configure dithering
on each of them.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 22 ++-
Hi Sam and Daniel,
Thank you very much for reviewing the code. I will squish all the commits and
send version 3, so it will be easier for you to review.
Anitha
> -Original Message-
> From: Sam Ravnborg
> Sent: Wednesday, July 15, 2020 10:07 AM
> To: Daniel Vetter
> Cc: Chrisanthus,
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next
head: d7373aaf738393f38f40b0570bfa1403584eb982
commit: 1f61a43fcec1dceac2ec537a63aba6846dd0e80a [140/193] drm/amd/sriov
porting sriov cap to vcn3.0
config: parisc-allyesconfig (attached as .config)
compiler: hppa-linux-gcc (GCC)
On Mon, Jul 13, 2020 at 5:42 AM Akhil P Oommen wrote:
>
> From: Sharat Masetty
>
> This patch adds the interconnects property to the GPU node. This enables
> the GPU->DDR path bandwidth voting.
>
> Signed-off-by: Sharat Masetty
> Signed-off-by: Akhil P Oommen
> ---
>
https://bugzilla.kernel.org/show_bug.cgi?id=208413
ghutzr...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=208573
--- Comment #3 from Thomas Langkamp (thomas.langk...@medicalschool-hamburg.de)
---
Created attachment 290307
--> https://bugzilla.kernel.org/attachment.cgi?id=290307=edit
xorg.log just after connecting second display
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=208573
--- Comment #2 from Thomas Langkamp (thomas.langk...@medicalschool-hamburg.de)
---
Created attachment 290305
--> https://bugzilla.kernel.org/attachment.cgi?id=290305=edit
dmesg just after plugging in second display
--
You are receiving this
On Thu, 16 Jul 2020 at 00:59, Thomas Zimmermann wrote:
>
> This patchset puts device initialization in the correct order and
> adds support for G200 Desktop chips (PCI ids 0x520 and 0x521).
why? :-)
I'm pretty sure I NAKed the previous version because the userspace
experience for these old
On Tue, 30 Jun 2020 00:33:12 +0200, Sebastian Reichel wrote:
> Convert panel-dsi-cm bindings to YAML and add
> missing properties while at it.
>
> Signed-off-by: Sebastian Reichel
> ---
> .../bindings/display/panel/panel-dsi-cm.txt | 29 -
> .../bindings/display/panel/panel-dsi-cm.yaml
On Sat, 13 Jun 2020 19:37:03 +0530, Kamlesh Gurudasani wrote:
> This adds binding for ilitek,ili9488 based display panels
>
> Signed-off-by: Kamlesh Gurudasani
> ---
> .../bindings/display/ilitek,ili9488.yaml | 71
> ++
> 1 file changed, 71 insertions(+)
> create
On Wed, Jul 15, 2020 at 11:37 AM Jonathan Marek wrote:
>
> On 7/15/20 2:29 PM, Rob Clark wrote:
> > From: Rob Clark
> >
> > If there is no interconnect-names, but there is an interconnects
> > property, then of_icc_get(dev, "gfx-mem"); would return an error
> > rather than NULL.
> >
> > Also, if
On Wed, Jul 15, 2020 at 12:07:30PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> If there is no interconnect-names, but there is an interconnects
> property, then of_icc_get(dev, "gfx-mem"); would return an error
> rather than NULL.
>
> Also, if there is no interconnect-names property, there
On Fri, 03 Jul 2020 13:47:17 +0200, Ondrej Jirman wrote:
> The display has one port. Allow it in the binding.
>
> Signed-off-by: Ondrej Jirman
> ---
> .../devicetree/bindings/display/panel/rocktech,jh057n00900.yaml | 1 +
> 1 file changed, 1 insertion(+)
>
Reviewed-by: Rob Herring
On Fri, 03 Jul 2020 13:47:16 +0200, Ondrej Jirman wrote:
> The example is now validated against rocktech,jh057n00900 schema
> that was ported to yaml, and didn't validate with:
>
> - '#address-cells', '#size-cells', 'port@0' do not match any of
> the regexes: 'pinctrl-[0-9]+'
> - 'vcc-supply'
https://bugzilla.kernel.org/show_bug.cgi?id=208573
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
Will try to look over this tomorrow, jfyi
On Wed, 2020-07-15 at 16:58 +0200, Thomas Zimmermann wrote:
> This patchset puts device initialization in the correct order and
> adds support for G200 Desktop chips (PCI ids 0x520 and 0x521).
>
> The first 7 patches prepare the driver. Desktop chips
Hi Dave, Daniel,
Fixes for 5.8.
The following changes since commit 38794a5465b752118098e36cf95c59083f9f1f88:
Merge tag 'amd-drm-fixes-5.8-2020-07-09' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2020-07-10 07:02:02
+1000)
are available in the Git repository at:
Drop doubled word "the" in a comment.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
include/drm/drm_rect.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200714.orig/include/drm/drm_rect.h
+++
Use kthread_create_worker to simplify the code and optimise
the manager struct: msm_drm_thread. With this change, we
could remove struct element (struct task_struct *thread &
struct kthread_worker worker), instead, use one point (struct
kthread_worker *worker).
Signed-off-by: Bernard Zhao
---
Drop doubled word "than" in a comment.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
include/drm/drm_atomic.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200714.orig/include/drm/drm_atomic.h
+++
syzbot is reporting general protection fault in bitfill_aligned() [1]
caused by integer underflow in bit_clear_margins(). The cause of this
problem is when and how do_vc_resize() updates vc->vc_{cols,rows}.
If vc_do_resize() fails (e.g. kzalloc() fails) when var.xres or var.yres
is going to
Drop the doubled word "to" in comments.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
include/uapi/drm/msm_drm.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20200714.orig/include/uapi/drm/msm_drm.h
+++
On Thu, Jul 02, 2020 at 04:22:34PM +0200, Andrzej Hajda wrote:
> On 14.05.2020 13:30, Vincent Whitchurch wrote:
> > diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> > b/drivers/gpu/drm/bridge/adv7511/adv7511_cec.c
> > index a20a45c0b353..ee0ed4fb67c1 100644
> > ---
On 2020-07-13 22:50, Rob Clark wrote:
On Mon, Jul 13, 2020 at 8:59 AM wrote:
On 2020-07-10 22:38, Rob Clark wrote:
> On Thu, Jun 18, 2020 at 7:09 AM Kalyan Thota
> wrote:
>>
>> This change adds support to scale src clk and bandwidth as
>> per composition requirements.
>>
>> Interconnect
Drop doubled word "is" in several comments.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
include/drm/drm_mode_config.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
---
On 2020-07-14 06:42, Matthias Kaehlcke wrote:
On Thu, Jun 18, 2020 at 07:38:41PM +0530, Kalyan Thota wrote:
This change adds support to scale src clk and bandwidth as
per composition requirements.
Interconnect registration for bw has been moved to mdp
device node from mdss to facilitate the
On Mon, Jul 13, 2020 at 5:50 PM Doug Anderson wrote:
>
> Hi,
>
> On Mon, Jul 13, 2020 at 1:25 PM Rob Herring wrote:
> >
> > On Mon, Jul 13, 2020 at 9:08 AM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Jul 13, 2020 at 7:11 AM Rob Herring wrote:
> > > >
> > > > On Fri, Jul 10, 2020
The wrappers in include/linux/pci-dma-compat.h should go away.
The patch has been generated with the coccinelle script below and has been
hand modified to replace GFP_ with a correct flag.
It has been compile tested.
When memory is allocated in 'ksz_alloc_desc()', GFP_KERNEL can be used
because
On 2020/07/14 16:22, Bartlomiej Zolnierkiewicz wrote:
> How does this patch relate to:
>
> https://marc.info/?l=linux-fbdev=159415024816722=2
>
> ?
>
> It seems to address the same issue, I've added George and Dan to Cc:.
George Kennedy's patch does not help for my case.
You can try
On 2020/07/14 19:27, Tetsuo Handa wrote:
> On 2020/07/14 16:22, Bartlomiej Zolnierkiewicz wrote:
>> How does this patch relate to:
>>
>> https://marc.info/?l=linux-fbdev=159415024816722=2
>>
>> ?
>>
>> It seems to address the same issue, I've added George and Dan to Cc:.
>
> George Kennedy's
Drop the doubled words "the" and "by" in comments.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
include/drm/drm_gem.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- linux-next-20200714.orig/include/drm/drm_gem.h
+++
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 2c6fefb23a0e94add694b04a82bf020aed1898a0
commit: 8e37efbf94c9516cbec8ac650ecae7c8647d4d7f [1019/1033] drm/amd/display:
reduce sr_xxx_time by 3 us when ppt disable
config: i386-allyesconfig (attached as .config)
Hello Tetsuo,
Can you try the a.out built from the original Syzkaller modified repro C
program? It walks 0-7 through xres and yres of the fb_var_screeninfo struct.
// https://syzkaller.appspot.com/bug?id=a565882df74fa76f10d3a6fec4be31098dbb37c6
// autogenerated by syzkaller
On 2020/07/15 2:15, George Kennedy wrote:
> Can you try the a.out built from the original Syzkaller modified repro C
> program? It walks 0-7 through xres and yres of the fb_var_screeninfo struct.
I'm not familiar with exploit code. What do you want to explain via this
program?
> struct
On Tue 14 Jul 15:13 PDT 2020, Rob Herring wrote:
> On Tue, Jul 14, 2020 at 10:33 AM Jeffrey Hugo
> wrote:
> >
> > On Mon, Jul 13, 2020 at 5:50 PM Doug Anderson wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Jul 13, 2020 at 1:25 PM Rob Herring wrote:
> > > >
> > > > On Mon, Jul 13, 2020 at 9:08 AM
Chen-Yu Tsai writes:
> From: Chen-Yu Tsai
>
> When the extra HPD polling in sun4i_hdmi was removed, the result of
> HPD was accidentally inverted.
>
> Fix this by inverting the check.
>
> Fixes: bda8eaa6dee7 ("drm: sun4i: hdmi: Remove extra HPD polling")
> Signed-off-by: Chen-Yu Tsai
Drop doubled word "should" in a comment.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
include/drm/drm_bridge.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- linux-next-20200714.orig/include/drm/drm_bridge.h
+++
hi
I've encountered [BUG: unable to handle kernel NULL pointer dereference at]
which has call stack like your pattern2.
And before this happended, I got a lot of memory allocation failure warnings.
And my kernel is 3.10.0-327.62.1.el7.x86_64.
Since, you mentioned it may be a bug of drm/tmm.
It is not used since commit 058179e72e09 ("drm/i915/gt: Replace
hangcheck by heartbeats")
Signed-off-by: YueHaibing
---
drivers/gpu/drm/i915/i915_utils.h | 13 -
1 file changed, 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
Hi Jonas,
Am 07.07.20 um 00:30 schrieb Jonas Karlman:
Add support for displaying 10-bit 4:2:0 and 4:2:2 formats produced by the
Rockchip Video Decoder on RK322X, RK3288, RK3328, RK3368 and RK3399.
Also add support for 10-bit 4:4:4 format while at it.
V2: Added NV30 support
Signed-off-by:
On 2020/07/14 18:13, Gu Jinxiang wrote:
> I've encountered [BUG: unable to handle kernel NULL pointer dereference at]
> which has call stack like your pattern2.
> And before this happended, I got a lot of memory allocation failure warnings.
> And my kernel is 3.10.0-327.62.1.el7.x86_64.
>
>
Drop doubled words "the" and "be" in comments.
Signed-off-by: Randy Dunlap
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
---
include/uapi/drm/i915_drm.h |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
---
Am 14.07.20 um 16:31 schrieb Daniel Vetter:
On Tue, Jul 14, 2020 at 01:40:11PM +0200, Christian König wrote:
Am 14.07.20 um 12:49 schrieb Daniel Vetter:
On Tue, Jul 07, 2020 at 10:12:23PM +0200, Daniel Vetter wrote:
My dma-fence lockdep annotations caught an inversion because we
allocate
Still Reviewed-by: Bas Nieuwenhuizen
On Tue, Jul 14, 2020 at 11:24 PM Chris Wilson wrote:
>
> Since we decouple the sync_pt from the timeline tree upon release, in
> order to allow releasing the sync_pt from a signal callback we need to
> separate the sync_pt signaling lock from the timeline
Quoting YueHaibing (2020-07-15 04:21:04)
> It is not used since commit 058179e72e09 ("drm/i915/gt: Replace
> hangcheck by heartbeats")
>
> Signed-off-by: YueHaibing
Indeed, it is no more.
Reviewed-by: Chris Wilson
-Chris
___
dri-devel mailing list
On Wed, Jul 15, 2020 at 10:51:02AM +0900, Tetsuo Handa wrote:
> syzbot is reporting general protection fault in bitfill_aligned() [1]
> caused by integer underflow in bit_clear_margins(). The cause of this
> problem is when and how do_vc_resize() updates vc->vc_{cols,rows}.
>
> If vc_do_resize()
On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen wrote:
>
> On 07/14, Daniel Vetter wrote:
> > On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > > On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen wrote:
> > > >
> > > > On 07/13, Daniel Vetter wrote:
> > > > > On Fri, Jul 10, 2020 at
Am 14.07.20 um 22:06 schrieb Chris Wilson:
From: Bas Nieuwenhuizen
Calltree:
timeline_fence_release
drm_sched_entity_wakeup
dma_fence_signal_locked
sync_timeline_signal
sw_sync_ioctl
Releasing the reference to the fence in the fence signal callback
seems reasonable to me, so
While sw_sync is purely a debug facility for userspace to create fences
and timelines it can control, nevertheless it has some tricky locking
semantics of its own. In particular, Bas Nieuwenhuizen reported that we
had reintroduced a deadlock if a signal callback attempted to destroy
the fence. So
If a signal callback releases the sw_sync fence, that will trigger a
deadlock as the timeline_fence_release recurses onto the fence->lock
(used both for signaling and the the timeline tree).
If we always hold a reference for an unsignaled fence held by the
timeline, we no longer need to detach
dma_fence_release() objects to a fence being freed before it is
signaled, so instead of playing fancy tricks to avoid handling dying
requests, let's keep the syncpt alive until signaled. This neatly
removes the issue with having to decouple the syncpt from the timeline
upon fence release.
-Chris
etch changes up to e57bd05ec0d2d82d63725dedf9f5a063f879de25:
drm/i915: Update DRIVER_DATE to 20200715 (2020-07-15 14:18:02 +0300)
drm/i915 features for v5.9, batch #2
Highlights:
- Very early DG1 enabling (Abdiel, Lucas, Anusha)
On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson wrote:
> Quoting Chris Wilson (2020-07-15 13:21:43)
> > Quoting Daniel Vetter (2020-07-15 13:10:22)
> > > On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > > > When waiting with a callback on the stack, we must remove the callback
> > >
Hi Dave & Daniel -
drm-intel-fixes-2020-07-15:
drm/i915 fixes for v5.8-rc6:
- FBC w/a stride fix
- Fix use-after-free fix on module reload
- Ignore irq enabling on the virtual engines to fix device sleep
- Use GTT when saving/restoring engine GPR
- Fix selftest sort function
BR,
Jani.
The
Argh, failed to mention:
On Wed, 15 Jul 2020, Jani Nikula wrote:
> Lee Shawn C (1):
> drm/i915/mst: filter out the display mode exceed sink's capability
The above depends on:
> Lyude Paul (1):
> drm/probe_helper: Add drm_connector_helper_funcs.mode_valid_ctx
Which has changes
On Wed, Jul 15, 2020 at 2:53 PM Liviu Dudau wrote:
>
> On Tue, Jul 07, 2020 at 10:12:12PM +0200, Daniel Vetter wrote:
> > Again needs to be put right after the call to
> > drm_atomic_helper_commit_hw_done(), since that's the last thing which
> > can hold up a subsequent atomic commit.
> >
> > No
Hi Chris,
My concern with going in this direction was that we potentially allow
an application to allocate a lot of kernel memory but not a lot of fds
by creating lots of fences and then closing the fds but never
signaling them. Is that not an issue?
- Bas
On Wed, Jul 15, 2020 at 12:04 PM Chris
Rearrange the code to pull the operations beore the fence->lock critical
section, and remove a small amount of redundancy:
Function old new delta
dma_fence_add_callback 156 145 -11
Signed-off-by: Chris Wilson
---
When waiting with a callback on the stack, we must remove the callback
upon wait completion. Since this will be notified by the fence signal
callback, the removal often contends with the fence->lock being held by
the signaler. We can look at the list entry to see if the callback was
already
Reviewed-by: Bas Nieuwenhuizen
On Wed, Jul 15, 2020 at 12:04 PM Chris Wilson wrote:
>
> If a signal callback releases the sw_sync fence, that will trigger a
> deadlock as the timeline_fence_release recurses onto the fence->lock
> (used both for signaling and the the timeline tree).
>
> If we
On Wed, Jul 15, 2020 at 10:17:56AM +0200, Daniel Vetter wrote:
> On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen wrote:
> >
> > On 07/14, Daniel Vetter wrote:
> > > On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > > > On Tue, Jul 14, 2020 at 7:20 AM Melissa Wen
> > > > wrote:
> > >
On Wed, Jul 15, 2020 at 3:34 PM Jani Nikula wrote:
>
>
> Argh, failed to mention:
>
> On Wed, 15 Jul 2020, Jani Nikula wrote:
> > Lee Shawn C (1):
> > drm/i915/mst: filter out the display mode exceed sink's capability
>
> The above depends on:
>
> > Lyude Paul (1):
> >
On Mon, Jul 13, 2020 at 5:41 AM Akhil P Oommen wrote:
>
> This series adds support for GPU DDR bandwidth scaling and is based on the
> bindings from Georgi [1]. This is mostly a rebase of Sharat's patches [2] on
> the
> tip of msm-next branch.
>
> Changes from v4:
> - Squashed a patch to another
On 07/15, Sidong Yang wrote:
> On Wed, Jul 15, 2020 at 10:17:56AM +0200, Daniel Vetter wrote:
> > On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen wrote:
> > >
> > > On 07/14, Daniel Vetter wrote:
> > > > On Tue, Jul 14, 2020 at 07:39:42AM -0300, Melissa Wen wrote:
> > > > > On Tue, Jul 14, 2020 at
https://bugzilla.kernel.org/show_bug.cgi?id=206987
Cyrax (ev...@hotmail.com) changed:
What|Removed |Added
Kernel Version|5.7.0 |5.7.6
--
You are receiving
On Wed, Jul 15, 2020 at 5:57 PM Melissa Wen wrote:
>
> On 07/15, Sidong Yang wrote:
> > On Wed, Jul 15, 2020 at 10:17:56AM +0200, Daniel Vetter wrote:
> > > On Tue, Jul 14, 2020 at 9:01 PM Melissa Wen wrote:
> > > >
> > > > On 07/14, Daniel Vetter wrote:
> > > > > On Tue, Jul 14, 2020 at
https://bugzilla.kernel.org/show_bug.cgi?id=206987
--- Comment #30 from Cyrax (ev...@hotmail.com) ---
The patch in https://bugzilla.kernel.org/show_bug.cgi?id=207979 works
beatifully.
19 days heavy usage without system crash on patched 5.7.6 kernel.
--
You are receiving this mail because:
You
Dave, Daniel,
vmwgfx-fixes pull for 5.8.
Just one fix for now, but it's a really important one, causing black
screens in VMs (sometimes on boot), hence marking it for stable.
The following changes since commit 1f054fd26e29784d373c3d29c348ee48f1c41fb2:
drm/vmwgfx: fix update of display surface
Quoting Bas Nieuwenhuizen (2020-07-15 11:23:35)
> Hi Chris,
>
> My concern with going in this direction was that we potentially allow
> an application to allocate a lot of kernel memory but not a lot of fds
> by creating lots of fences and then closing the fds but never
> signaling them. Is that
Implementing those is completely unecessary.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 5 -
drivers/gpu/drm/drm_gem_vram_helper.c | 5 -
drivers/gpu/drm/qxl/qxl_ttm.c | 6 --
drivers/gpu/drm/radeon/radeon_ttm.c| 5
Only functional change is to always keep io_reserved_count up to date
for debugging even when it is not used otherwise.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 97 +++
1 file changed, 48 insertions(+), 49 deletions(-)
diff --git
Just use the use_io_reserve_lru flag. It doesn't make much
sense to have two flags.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
drivers/gpu/drm/ttm/ttm_bo.c | 1 -
drivers/gpu/drm/ttm/ttm_bo_util.c| 8
include/drm/ttm/ttm_bo_driver.h
Nouveau is the only user of this functionality and evicting io space
on -EAGAIN is really a misuse of the return code.
Instead switch to using -ENOSPC here which makes much more sense and
simplifies the code.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 --
On Tue, Jul 14, 2020 at 10:23:43PM -0700, Randy Dunlap wrote:
> Drop doubled word "than" in a comment.
>
> Signed-off-by: Randy Dunlap
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: dri-devel@lists.freedesktop.org
Entire series pushed to drm-misc-next, thanks for your patches. Should
still make
Hi,
On Wed, 15 Jul 2020 at 11:23, Bas Nieuwenhuizen
wrote:
> My concern with going in this direction was that we potentially allow
> an application to allocate a lot of kernel memory but not a lot of fds
> by creating lots of fences and then closing the fds but never
> signaling them. Is that
Hi,
On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen
wrote:
> On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson
> wrote:
> > Maybe now is the time to ask: are you using sw_sync outside of
> > validation?
>
> Yes, this is used as part of the Android stack on Chrome OS (need to
> see if ChromeOS
On Wed, Jul 15, 2020 at 1:47 PM Daniel Stone wrote:
>
> Hi,
>
> On Wed, 15 Jul 2020 at 12:05, Bas Nieuwenhuizen
> wrote:
> > On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson
> > wrote:
> > > Maybe now is the time to ask: are you using sw_sync outside of
> > > validation?
> >
> > Yes, this is
Quoting Daniel Vetter (2020-07-15 13:10:22)
> On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > When waiting with a callback on the stack, we must remove the callback
> > upon wait completion. Since this will be notified by the fence signal
> > callback, the removal often contends
On Wed, Jul 15, 2020 at 12:34 PM Chris Wilson wrote:
>
> Quoting Bas Nieuwenhuizen (2020-07-15 11:23:35)
> > Hi Chris,
> >
> > My concern with going in this direction was that we potentially allow
> > an application to allocate a lot of kernel memory but not a lot of fds
> > by creating lots of
On Wed, Jul 15, 2020 at 11:17 AM Christian König
wrote:
>
> Am 14.07.20 um 16:31 schrieb Daniel Vetter:
> > On Tue, Jul 14, 2020 at 01:40:11PM +0200, Christian König wrote:
> >> Am 14.07.20 um 12:49 schrieb Daniel Vetter:
> >>> On Tue, Jul 07, 2020 at 10:12:23PM +0200, Daniel Vetter wrote:
>
On Wed, Jul 15, 2020 at 03:05:59PM +0800, Jing Xiangfeng wrote:
> The variable ret has been assigned the value '-EINVAL'. The assignment
> in the if() is redundant. We can remove it.
Nope, that's not correct. Before this assignement ret is guaranteed to be
0.
-Daniel
>
> Signed-off-by: Jing
On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> When waiting with a callback on the stack, we must remove the callback
> upon wait completion. Since this will be notified by the fence signal
> callback, the removal often contends with the fence->lock being held by
> the signaler.
Quoting Chris Wilson (2020-07-15 13:21:43)
> Quoting Daniel Vetter (2020-07-15 13:10:22)
> > On Wed, Jul 15, 2020 at 11:49:05AM +0100, Chris Wilson wrote:
> > > When waiting with a callback on the stack, we must remove the callback
> > > upon wait completion. Since this will be notified by the
On Tue, Jul 07, 2020 at 10:12:12PM +0200, Daniel Vetter wrote:
> Again needs to be put right after the call to
> drm_atomic_helper_commit_hw_done(), since that's the last thing which
> can hold up a subsequent atomic commit.
>
> No surprises here.
I was (still am) hoping to do a testing for this
Quoting Daniel Vetter (2020-07-15 15:03:34)
> On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson wrote:
> > There's a further problem in that we call INIT_LIST_HEAD on the
> > dma_fence_cb before the signal callback. So even if list_empty_careful()
> > confirms the dma_fence_cb to be completely
This patch adds support for G200 desktop cards. We can reuse the whole
memory and modesetting code. A few PCI and DAC register values have to
be updated accordingly.
The most significant change is in the PLL setup. The get the clock limits
and reference clocks, parses the device's BIOS. With no
This patchset puts device initialization in the correct order and
adds support for G200 Desktop chips (PCI ids 0x520 and 0x521).
The first 7 patches prepare the driver. Desktop chips would probably
work without them, but since we're at it we can also do it right.
Patch 1 enables cached page
So far, PCI option registers were initialized as part of modesetting,
which is late in the process. As these registers control fundamental
operation, they should be set early.
The patch moves the PCI option handling into device register setup,
before even the device MMIO memory is being mapped.
Hi Anitha
On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> This is a new DRM driver for Intel's KeemBay SOC.
> The SoC couples an ARM Cortex A53 CPU with an Intel
> Movidius VPU.
>
> This driver is tested with the KMB EVM board which is the refernce baord
> for Keem Bay SOC.
On Wed, Jul 15, 2020 at 11:02:58PM +0900, Tetsuo Handa wrote:
> On 2020/07/15 20:17, Tetsuo Handa wrote:
> > On 2020/07/15 18:48, Dan Carpenter wrote:
> >>> @@ -216,7 +216,7 @@ static void bit_clear_margins(struct vc_data *vc,
> >>> struct fb_info *info,
> >>> region.color = color;
> >>>
On Wed, Jul 15, 2020 at 05:05:49PM +0200, Daniel Vetter wrote:
> Hi Anitha
>
> On Tue, Jul 14, 2020 at 01:56:46PM -0700, Anitha Chrisanthus wrote:
> > This is a new DRM driver for Intel's KeemBay SOC.
> > The SoC couples an ARM Cortex A53 CPU with an Intel
> > Movidius VPU.
> >
> > This driver
On Wed, Jul 15, 2020 at 4:37 PM Chris Wilson wrote:
>
> Quoting Daniel Vetter (2020-07-15 15:03:34)
> > On Wed, Jul 15, 2020 at 2:40 PM Chris Wilson
> > wrote:
> > > There's a further problem in that we call INIT_LIST_HEAD on the
> > > dma_fence_cb before the signal callback. So even if
SHMEM pages use write-combine caching by default, but can also use the
platform's default page caching. Doing so may improve the performance
of I/O on the framebuffer.
Mgag200's hardware does not access framebuffer pages directly (i.e.,
via DMA), so enabling caching does not have an effect on
1 - 100 of 113 matches
Mail list logo