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 sca
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 at
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 a
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&m=159415024816722&w=2
>>
>> ?
>>
>> It seems to address the same issue, I've added George and Dan to Cc:.
>
> George Kenned
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
+++ l
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
+++ linux-next-20200
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
---
dr
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
+++ linux-next-
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 shrink
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
+++ li
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
> > --- a/drivers/gpu/drm/bri
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 regis
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(-)
--- linux-next-20200714.orig/include/drm/drm_mode_c
On 2020/07/14 16:22, Bartlomiej Zolnierkiewicz wrote:
> How does this patch relate to:
>
> https://marc.info/?l=linux-fbdev&m=159415024816722&w=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
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 (https://github.com
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 fb_var
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
Tested-by
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
+++ linux-nex
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. So
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
index
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: Jonas
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.
>
> Since
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(-)
--- linux-next-20200714.orig/include/uapi/drm/i915_drm
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 02:05:33
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 thi
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
dri
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 memor
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 tre
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() f
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
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 the
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 l
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
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 no
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 n
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
---
drivers/dm
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 signale
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 fe
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 alw
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 a/drive
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 --
driver
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 spec
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 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 used
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
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 Xian
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. We
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 w
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 fenc
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 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
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 follo
to fetch 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, Anu
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 out
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 s
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
> > >
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):
> > drm/probe_helpe
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 decouple
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 list_emp
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 cons
The mgag200 driver maps registers into the address space. Move the
code into a separate helper function. No functional changes.
One small difference is in the handling of SDRAM/SGRAM. MGA devices
can come with either SDRAM or SGRAM. So far, the driver checked for
SDRAM, which is the common case. T
MGA cards can run in traditional VGA mode or an enhanced MGA mode; with
the latter being required for KMS. So far, MGA mode was enabled during
modesetting. As it's fundamental for device operation, the patch moves
it next to the device register setup.
Signed-off-by: Thomas Zimmermann
---
drivers
The modesetting code initialized the memory-related register CRTCEXT4.
Move this code to MM initialization.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mm.c | 2 ++
drivers/gpu/drm/mgag200/mgag200_mode.c | 6 +-
2 files changed, 3 insertions(+), 5 deletions(-)
dif
The modesetting code initialized several memory-related flags in the
MISC register. Move this code to MM initialization.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_mm.c | 6 ++
drivers/gpu/drm/mgag200/mgag200_mode.c | 4 +---
2 files changed, 7 insertions(+), 3 de
The unique revision id is only useful for G200SE devices. Store the
value in model-specific data within struct mga_device. While at it,
the patch also adds an init helper for the value.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 19 +--
drivers/
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. No
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 BI
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 mappi
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;
> >>> regio
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 is
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 7:2
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 t
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 07:39:42
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 ar
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
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #63 from Duncan (1i5t5.dun...@cox.net) ---
(In reply to Duncan from comment #62)
> I've applied the three 320-and-followups revert-patches to
> v5.8-rc5-8-g0dc589da8 and just did the rebuild with them applied.
> Now to reboot to it and
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 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 is
https://bugzilla.kernel.org/show_bug.cgi?id=207383
--- Comment #64 from Anthony Ruhier (anthony.ruh...@gmail.com) ---
(In reply to Duncan from comment #63)
> (In reply to Duncan from comment #62)
> > I've applied the three 320-and-followups revert-patches to
> > v5.8-rc5-8-g0dc589da8 and just did
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 dm
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,
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 ++
>
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 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
> ---
> arch/arm64/boot/dts/qcom/s
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 -EINV
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
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, Ani
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
https://bugzilla.kernel.org/show_bug.cgi?id=208573
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
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&action=edit
xorg.log just after connecting second display
--
You are receivi
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&action=edit
dmesg just after plugging in second display
--
You are receiving
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 -EINV
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) 9.3.
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 cards
1 - 100 of 113 matches
Mail list logo
