https://bugs.freedesktop.org/show_bug.cgi?id=107731
--- Comment #12 from L.S.S. ---
Sorry, but should have commented on this much sooner.
After my last comment I eventually replaced the ATEN CS1924 KVM with a new
generic 4-port KVM that is 4K@60Hz-capable. This one does not exhibit the
issue,
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #1 from rro...@gmail.com ---
I get similar corruption in Chromium and Visual Studio Code with Mesa
19.1.0-rc3. There was no problem with 19.1.0-rc2.
This is on Archlinux, kernel 5.1.3, the card is an RX480. I tried compiling
Mesa
The saturation bit was being set at bit 9 in the second 32-bit word
of the TPMEM CSC. This isn't correct, the saturation bit is bit 42,
which is bit 10 of the second word.
Fixes: 1aa8ea0d2bd5d ("gpu: ipu-v3: Add Image Converter unit")
Signed-off-by: Steve Longerbeam
Reviewed-by: Philipp Zabel
Only providing the input and output RGB/YUV space to the IC task init
functions is not sufficient. To fully characterize a colorspace
conversion, the Y'CbCr encoding standard, and quantization also
need to be specified.
Define a 'struct ipu_ic_colorspace' that includes all the above.
This allows
Add support for encodings to or from limited range quantization.
Signed-off-by: Steve Longerbeam
---
Changes in v7:
- hard-code the coefficients instead of deriving the limited range
coefficients from the full2full coefficients on the fly with
fixed-point math.
- add support for RGB
Add support for Rec.709 encoding and inverse encoding.
Reported-by: Tim Harvey
Signed-off-by: Steve Longerbeam
---
Changes in v7:
- moved CSC tables to new module ipu-ic-csc.c.
- express negative coefficients as true signed int's, for better
readability.
Changes in v5:
- moved API changes to
This commit was reverted later. I guess the revert was probably not picked up
properly.
Regards,
Yong
From: syzbot
Sent: Tuesday, May 21, 2019 11:16 PM
To: Zhao, Yong; airl...@linux.ie; Deucher, Alexander;
amd-...@lists.freedesktop.org; a...@kernel.org;
https://bugs.freedesktop.org/show_bug.cgi?id=110701
--- Comment #24 from Yury Zhuravlev ---
(In reply to Marek Olšák from comment #23)
> Fixed by d6053bf2a170a0fec6d232fda097d2f35f0e9eae. Closing.
The original issue was about Vega and on Vega we saw a different problem. I
suppose before close
On 5/20/19 8:30 AM, Daniel Thompson wrote:
> On Mon, May 20, 2019 at 08:14:03AM -0500, Rob Herring wrote:
>> On Mon, May 20, 2019 at 3:59 AM Brian Masney wrote:
>>>
>>> The '#address-cells' and '#size-cells' properties were not defined in
>>> the lm3630a bindings and would cause the following
On Tue, May 21, 2019 at 07:29:33PM +0100, Catalin Marinas wrote:
> On Mon, May 20, 2019 at 04:53:07PM -0700, Evgenii Stepanov wrote:
> > On Fri, May 17, 2019 at 7:49 AM Catalin Marinas
> > wrote:
> > > IMO (RFC for now), I see two ways forward:
> > > [...]
> > > 2. Similar shim to the above libc
https://bugs.freedesktop.org/show_bug.cgi?id=107731
--- Comment #13 from Fermulator ---
Sorry I no longer have access to the system originally reported this issue
from.
--
You are receiving this mail because:
You are the assignee for the bug.___
On 03.05.2019 14:29, Tomi Valkeinen wrote:
> In tc_bridge_mode_set callback, we store the pointer to the given
> drm_display_mode, and use the mode later. Storing a pointer in such a
> way looks very suspicious to me, and I have observed odd issues where
> the timings were apparently (at least
Quoting Dongli Zhang (2019-05-21 05:40:39)
> This patch removes IO_TLB_SEGPAGES which is no longer used since
> commit 5584f1b1d73e ("drm/i915: fix i915 running as dom0 under Xen").
>
> As the define of both IO_TLB_SEGSIZE and IO_TLB_SHIFT are from swiotlb,
> IO_TLB_SEGPAGES should be defined on
On 20-03-19, 15:19, Rajendra Nayak wrote:
> This is a v2 of the RFC posted earlier by Stephen Boyd [1]
>
> As part of v2 I still follow the same approach of dev_pm_opp_set_rate()
> API using clk framework to round the frequency passed and making it
> accept 0 as a valid frequency indicating the
On 03.05.2019 14:29, Tomi Valkeinen wrote:
> Add support for interrupt and hotplug handling. Both are optional.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/tc358767.c | 166 ++
> 1 file changed, 148 insertions(+), 18 deletions(-)
>
> diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=110701
Gert Wollny changed:
What|Removed |Added
CC||gw.foss...@gmail.com
--- Comment #19
https://bugs.freedesktop.org/show_bug.cgi?id=110717
Gert Wollny changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, May 21, 2019 at 4:33 AM Alex Deucher wrote:
>
> On Mon, May 20, 2019 at 7:19 PM Pan, Xinhui wrote:
> >
> > Daniel, what you are talking about is totally wrong.
> > 1) AFAIK, only one zero-size array can be in the end of a struct.
> > 2) two struct_size will add up struct itself twice.
On Mon, 20 May 2019 18:11:07 +0200
Daniel Vetter wrote:
> On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> > On Thu, 16 May 2019 14:24:55 +0200
> > Daniel Vetter wrote:
> >
> > > On Thu, May 16, 2019 at 11:22:11AM +0300, Pekka Paalanen wrote:
> > > > On Wed, 15 May 2019
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #29 from Chris Hodapp ---
Tom B, as far as I can tell, that commit didn't get merged in until relatively
recently and is not in 5.1.
--
You are receiving this mail because:
You are the assignee for the
On Mon, 20 May 2019, Gwan-gyeong Mun wrote:
> VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
> Packet). In order to generalize SDP packet structure name, it renames
> struct edp_vsc_psr to struct dp_sdp. And each SDP data blocks have
> different usages, each SDP type
User-space handles equal to zero are interpreted as uninitialized or
illegal by some drm systems (most notably kms). This means that a
dumb buffer or surface with a zero user-space handle can never be
used as a kms frame-buffer.
Cc:
Fixes: c7eae62666ad ("drm/vmwgfx: Make the object handles
This may confuse user-space clients like plymouth that opens a drm
file descriptor as a result of a hotplug event and then generates a
new event...
Cc:
Fixes: 5ea1734827bb ("drm/vmwgfx: Send a hotplug event at master_set")
Signed-off-by: Thomas Hellstrom
Reviewed-by: Deepak Rawat
---
With Eric's patch
commit ba6e798ecf320716780bb6a6088a8d17dcba1d49
Author: Eric Anholt
Date: Wed Apr 24 11:56:17 2019 -0700
drm/doc: Document expectation that userspace review looks at kernel uAPI.
there's been concerns raised that we expect userspace people to do
in-depth kernel patch
Looks good for me, patch is:
Reviewed-by: Qiang Yu
I'll apply it to drm-misc-next.
Regards,
Qiang
On Tue, May 21, 2019 at 6:46 AM Erico Nunes wrote:
>
> After "5918045c4ed4 drm/scheduler: rework job destruction", lima started
> to leak memory due to buffers not being destroyed after job
Ping?
On 16/05/2019 15:49, Lionel Landwerlin wrote:
Hi all,
While picking up the IGT tests for timeline syncobj,
I noticed that although we deal with multi wait across both timeline
(with point value > 0) and binary (point value = 0) syncobjs,
we don't seem to have a similar behavior with
Sorry for late response.
Although we don't expect that, drm_syncobj_timeline_signal_ioctl already
handle this case I think. Which can handle both (point value > 0) and
(point value = 0).
-David
On 2019年05月21日 16:44, Lionel Landwerlin wrote:
[CAUTION: External Email]
Ping?
On 16/05/2019
Am 21.05.19 um 09:23 schrieb Daniel Vetter:
On Tue, May 21, 2019 at 4:33 AM Alex Deucher wrote:
On Mon, May 20, 2019 at 7:19 PM Pan, Xinhui wrote:
Daniel, what you are talking about is totally wrong.
1) AFAIK, only one zero-size array can be in the end of a struct.
2) two struct_size will
On 08.05.2019 18:09, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds atomic variants for all of
> pre_enable/enable/disable/post_disable bridge functions. These will be
> called from the appropriate atomic helper functions. If the bridge
> driver doesn't implement the atomic version of the
On Tue, 21 May 2019 10:48:49 +0200
Daniel Vetter wrote:
> With Eric's patch
>
> commit ba6e798ecf320716780bb6a6088a8d17dcba1d49
> Author: Eric Anholt
> Date: Wed Apr 24 11:56:17 2019 -0700
>
> drm/doc: Document expectation that userspace review looks at kernel uAPI.
>
> there's been
komeda display HWs have kinds of coefficient tables for various purposes
like gamma/degamma. ususally these tables are shared by multiple HW
component and have limited number.
Introduce komeda_coeffs_table/manager for describing and managing these
tables, like table reuse, racing.
Signed-off-by:
^Typo in subject.
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> For some reasons the pm_vt_switch_unregister call was missing from the
> direct unregister_framebuffer path. Fix this.
>
> v2: fbinfo->dev is used to decided whether unlink_framebuffer has been
> called already. I botched that in
Add COMPILE_TEST support to da8xx-fb driver for better compile
testing coverage.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2: add missing HAVE_CLK && HAS IOMEM dependencies
drivers/video/fbdev/Kconfig |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
Add COMPILE_TEST support to atmel_lcdfb driver for better compile
testing coverage.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2: add missing HAVE_CLK && HAS IOMEM dependencies
drivers/video/fbdev/Kconfig |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen wrote:
>
> On Mon, 20 May 2019 18:11:07 +0200
> Daniel Vetter wrote:
>
> > On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> > > On Thu, 16 May 2019 14:24:55 +0200
> > > Daniel Vetter wrote:
> > >
> > > > On Thu, May 16, 2019 at
This patch series enabled layer/plane color management for komeda driver
This patch series depends on:
- https://patchwork.freedesktop.org/series/30876/
- https://patchwork.freedesktop.org/series/60856/
James Qian Wang (Arm Technology China) (4):
drm/komeda: Introduce
Many komeda component support color management like layer and IPS, so
komeda_color_manager/state are introduced to manager gamma, csc and degamma
together for easily share it to multiple componpent.
And for komeda_color_manager which:
- convert drm 3d gamma lut to komeda specific gamma coeffs
-
- D71 has 3 global layer gamma table which can be used for all layers as
gamma lookup table, no matter inverse or forward.
- Add komeda_color_manager/state to layer/layer_state for describe the
color caps for the specific layer which will be initialized in
d71_layer_init, and for D71 only
DRM_OBJECT_MAX_PROPERTY number 24 is not enough for komeda usage, increase
it to 32 to fit komeda's requirement.
Signed-off-by: James Qian Wang (Arm Technology China)
---
include/drm/drm_mode_object.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
https://bugs.freedesktop.org/show_bug.cgi?id=110701
--- Comment #20 from Eero Tamminen ---
There were several days when I didn't see this problem, but now I got it
triggered once again. I.e. it seems to happen very rarely, so far only twice
in 30 runs of Valley (done on different days /
Hello Jani,
On Tue, May 21, 2019 at 09:44:04AM +0300, Jani Nikula wrote:
> On Mon, 20 May 2019, Gwan-gyeong Mun wrote:
> > VSC SDP Payload for PSR is one of data block type of SDP (Secondaray Data
> > Packet). In order to generalize SDP packet structure name, it renames
> > struct edp_vsc_psr to
Hi,
> I think would be good to have a lockdep_assert_held here for the ww_mutex.
>
> Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations
> we call the structure tracking the fences+lock the "reservation", but the
> naming scheme used is _lock/_unlock.
>
> I think would
On Wed, 24 Apr 2019 21:36:36 +0200
Daniel Vetter wrote:
> On Wed, Apr 24, 2019 at 11:56:17AM -0700, Eric Anholt wrote:
> > The point of this review process is that userspace using the new uAPI
> > can actually live with the uAPI being provided, and it's hard to know
> > that without having
Hi,
The bug is in the driver, so ...
> Bisecting the issue for commits to drivers/gpu/drm/bochs/ points to:
> 6579c39594ae ("drm/bochs: atomic: switch planes to atomic, wire up helpers.")
> ... but the issue also seems to be due to a change in the generic drm code
... this one is the culprit
Use struct sg_dma_page_iter in favour struct of sg_page_iter, which fairly
recently was declared useless for obtaining dma addresses.
With a struct sg_dma_page_iter we can't call sg_page_iter_page() so
when the page is needed, use the same page lookup mechanism as for the
non-sg dma modes instead
In compat mode, we allowed host-backed user-space with guest-backed
kernel / device. In this mode, set shader commands was broken since
no relocations were emitted. Fix this.
Cc:
Fixes: e8c66efbfe3a ("drm/vmwgfx: Make user resource lookups reference-free
during validation")
Signed-off-by:
From: Murray McAllister
If SVGA_3D_CMD_DX_SET_SHADER is called with a shader ID
of SVGA3D_INVALID_ID, and a shader type of
SVGA3D_SHADERTYPE_INVALID, the calculated binding.shader_slot
will be 4294967295, leading to an out-of-bounds read in vmw_binding_loc()
when the offset is calculated.
Cc:
From: Murray McAllister
If SVGA_3D_CMD_DX_DEFINE_RENDERTARGET_VIEW is called with a surface
ID of SVGA3D_INVALID_ID, the srf struct will remain NULL after
vmw_cmd_res_check(), leading to a null pointer dereference in
vmw_view_add().
Cc:
Fixes: d80efd5cb3de ("drm/vmwgfx: Initial DX support")
Hello!
On 21.05.2019 2:50, meg...@megous.com wrote:
From: Icenowy Zheng
The PHY selection bit also exists on SoCs without an internal PHY; if it's
set to 1 (internal PHY, default value) then the MAC will not make use of
any PHY such SoCs.
^ "on" or "with" missing?
This problem
Add COMPILE_TEST support to pxa168fb driver for better compile
testing coverage.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2: add missing HAVE_CLK && HAS IOMEM dependencies
drivers/video/fbdev/Kconfig |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #30 from Chris Hodapp ---
Some interesting findings:
First, I think I may have identified the problematic commit (or at least the
most-problematic one): d1a3e239a6016f2bb42a91696056e223982e8538
(drm/amd/powerplay: drop the
On Thu, May 16, 2019 at 09:57:49PM +0800, Ayan Halder wrote:
> On Thu, Apr 04, 2019 at 12:06:14PM +0100, james qian wang (Arm Technology
> China) wrote:
> > For supporting AFBC:
> > 1. Check if the user requested modifier can be supported by display HW.
> > 2. Check the obj->size with AFBC's
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #31 from Tom B ---
That's interesting because a single one of your 120hz 4k displays would require
the same bandwidth as both of my 60hz 4k displays together. That means the
issue is either related only to resolution and not
On Tue, May 21, 2019 at 12:01:29PM +0300, Pekka Paalanen wrote:
> Hi Daniel,
>
> what says the assumption of the only monitor being driven by CRTC 0
> was a bad one? :-p
>
> It's probably not obvious that userspace needs to explicitly try to
> avoid invalid configuration combinations by
Hello Sergei,
On Tue, May 21, 2019 at 12:27:24PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 21.05.2019 2:50, meg...@megous.com wrote:
>
> > From: Icenowy Zheng
> >
> > The PHY selection bit also exists on SoCs without an internal PHY; if it's
> > set to 1 (internal PHY, default value) then
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not
Hi Ayan:
Sorry for late.
On Thu, May 16, 2019 at 08:33:45PM +0800, Ayan Halder wrote:
> On Thu, May 16, 2019 at 09:13:27AM +0100, james qian wang (Arm Technology
> China) wrote:
> > Komeda driver uses a individual component to describe the HW's writeback
> > caps, but drivers doesn't define a
On Tue, May 21, 2019 at 10:47:34AM +0300, Pekka Paalanen wrote:
> On Wed, 24 Apr 2019 21:36:36 +0200
> Daniel Vetter wrote:
>
> > On Wed, Apr 24, 2019 at 11:56:17AM -0700, Eric Anholt wrote:
> > > The point of this review process is that userspace using the new uAPI
> > > can actually live with
https://bugs.freedesktop.org/show_bug.cgi?id=108824
--- Comment #10 from Pierre-Eric Pelloux-Prayer ---
(In reply to Baldur Karlsson from comment #7)
> To repro with RenderDoc:
>
> * Download or build RenderDoc 1.4
> * Build gears3d from https://github.com/gears3d/gears3d
> * Launch gears3d
On Tue, 21 May 2019 09:52:50 +0200
Daniel Vetter wrote:
> On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen wrote:
> >
> > On Mon, 20 May 2019 18:11:07 +0200
> > Daniel Vetter wrote:
> >
> > > On Fri, May 17, 2019 at 01:08:24PM +0300, Pekka Paalanen wrote:
> > > > On Thu, 16 May 2019 14:24:55
Add COMPILE_TEST support to imxfb driver for better compile
testing coverage.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2: add missing HAVE_CLK && HAS IOMEM dependencies (noted by Uwe)
drivers/video/fbdev/Kconfig |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Index:
On Tue 21-05-19 12:06:11, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
>
> This will be used
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #67 from udo ---
I get multiple of these:
392.377183] amdgpu :09:00.0: [gfxhub] VMC page fault (src_id:0 ring:24
vmid:5 pasid:32772, for process firefox pid 4467 thread firefox:cs0 pid 4565
)
[ 392.377194]
Hi
Am 21.05.19 um 14:40 schrieb Daniel Vetter:
> On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
>> Replacing drm_gem_vram_push_to_system() moves policy from drivers back
>> to the memory manager. Now, unused BOs are only evicted when the space
>> is required.
>>
>> The
On Tue, May 21, 2019 at 10:58:06AM +0200, Andrzej Hajda wrote:
> On 08.05.2019 18:09, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch adds atomic variants for all of
> > pre_enable/enable/disable/post_disable bridge functions. These will be
> > called from the appropriate atomic helper
On Tue, May 21, 2019 at 12:46:38PM +0200, Michal Hocko wrote:
> On Tue 21-05-19 12:06:11, Daniel Vetter wrote:
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a
GPD has done it again, make a nice device (good), use way too generic
DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
Because of the too generic DMI strings this entry is also doing bios-date
matching, so the gpd_pocket2 data struct may very well need to be updated
with
On Mon, May 20, 2019 at 4:23 AM Steven Price wrote:
>
You forgot to update the subject. I can fixup when applying, but I'd
like an ack from Chris on patch 1.
> panfrost_ioctl_mmap_bo() contains a reimplementation of
> drm_gem_map_offset() but with a bug - it allows mapping imported objects
>
No need for them.
Cc: Geert Uytterhoeven
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/atafb.c | 21 -
1 file changed, 21 deletions(-)
Index: b/drivers/video/fbdev/atafb.c
===
---
https://bugs.freedesktop.org/show_bug.cgi?id=105251
--- Comment #68 from udo ---
I started getting these after/around commit
076159b40b96096ba01413abc011a26c9acf7176
--
You are receiving this mail because:
You are the assignee for the bug.___
On 21.05.2019 13:34, Tomi Valkeinen wrote:
> On 21/05/2019 10:07, Andrzej Hajda wrote:
>
>>> @@ -1214,19 +1234,43 @@ static int tc_connector_get_modes(struct
>>> drm_connector *connector)
>>> return count;
>>> }
>>>
>>> -static void tc_connector_set_polling(struct tc_data *tc,
>>> -
This is unused code since
commit 6104c37094e729f3d4ce65797002112735d49cd1
Author: Daniel Vetter
Date: Tue Aug 1 17:32:07 2017 +0200
fbcon: Make fbcon a built-time depency for fbdev
when fbcon was made a compile-time static dependency of fbdev. We
can't exit fbcon anymore without exiting
On Tue, May 21, 2019 at 08:24:53PM +0900, Tetsuo Handa wrote:
> On 2019/05/21 20:11, Michal Hocko wrote:
> > On Tue 21-05-19 20:04:34, Tetsuo Handa wrote:
> >> On 2019/05/21 19:51, Michal Hocko wrote:
> >>> On Tue 21-05-19 19:44:01, Tetsuo Handa wrote:
> On 2019/05/21 19:06, Daniel Vetter
On Tue, 21 May 2019, Daniel Vetter wrote:
> In some special cases we must not block, but there's not a
> spinlock, preempt-off, irqs-off or similar critical section already
> that arms the might_sleep() debug checks. Add a non_block_start/end()
> pair to annotate these.
Just putting preempt
On Tue 21-05-19 14:43:38, Cristopher Lameter wrote:
> On Tue, 21 May 2019, Daniel Vetter wrote:
>
> > In some special cases we must not block, but there's not a
> > spinlock, preempt-off, irqs-off or similar critical section already
> > that arms the might_sleep() debug checks. Add a
In some special cases we must not block, but there's not a
spinlock, preempt-off, irqs-off or similar critical section already
that arms the might_sleep() debug checks. Add a non_block_start/end()
pair to annotate these.
This will be used in the oom paths of mmu-notifiers, where blocking is
not
On Mon, May 20, 2019 at 10:37:53AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 20.05.19 um 10:33 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 20.05.19 um 10:21 schrieb Daniel Vetter:
> > ...
> >> diff --git a/drivers/video/fbdev/core/fbmem.c
> >> b/drivers/video/fbdev/core/fbmem.c
> >> index
On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> Just a bit of paranoia, since if we start pushing this deep into
> callchains it's hard to spot all places where an mmu notifier
> implementation might fail when it's not allowed to.
>
> Inspired by some confusion we had discussing
On Tue, May 21, 2019 at 2:48 AM Koenig, Christian
wrote:
>
> Am 21.05.19 um 01:16 schrieb Erico Nunes:
> > [CAUTION: External Email]
> >
> > After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
> > only deleted when the timeout handler is able to be cancelled
> > successfully.
> >
On Tue, May 21, 2019 at 4:02 PM Bartlomiej Zolnierkiewicz
wrote:
> No need for them.
>
> Cc: Geert Uytterhoeven
> Signed-off-by: Bartlomiej Zolnierkiewicz
Reviewed-by: Geert Uytterhoeven
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond
Am 21.05.19 um 16:13 schrieb Alex Deucher:
> [CAUTION: External Email]
>
> On Tue, May 21, 2019 at 2:48 AM Koenig, Christian
> wrote:
>> Am 21.05.19 um 01:16 schrieb Erico Nunes:
>>> [CAUTION: External Email]
>>>
>>> After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
>>> only
On Tue, May 21, 2019 at 4:26 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 21.05.19 um 14:40 schrieb Daniel Vetter:
> > On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
> >> Replacing drm_gem_vram_push_to_system() moves policy from drivers back
> >> to the memory manager. Now,
Reviewed-by: Deepak Rawat
On Tue, 2019-05-21 at 00:35 +0200, Daniel Vetter wrote:
> That's purely for the uapi layer to implement the ALLOW_MODESET flag.
>
> Drivers should instead look at the state, e.g. through
> drm_atomic_crtc_needs_modeset(), which vmwgfx already does. Also
> remove
> the
On Tue, May 21, 2019 at 02:41:30PM +0200, Daniel Vetter wrote:
> On Tue, May 21, 2019 at 01:09:06PM +0200, Maxime Ripard wrote:
> > We introduced new functions in the commit bf39607c1614 ("drm/fourcc: Pass
> > the format_info pointer to drm_format_plane_width/height") based on
> > previous ones
On Mon, May 20, 2019 at 11:39:44PM +0200, Daniel Vetter wrote:
> We need to make sure implementations don't cheat and don't have a
> possible schedule/blocking point deeply burried where review can't
> catch it.
>
> I'm not sure whether this is the best way to make sure all the
> might_sleep()
On Mon, May 20, 2019 at 11:39:45PM +0200, Daniel Vetter wrote:
> This is a similar idea to the fs_reclaim fake lockdep lock. It's
> fairly easy to provoke a specific notifier to be run on a specific
> range: Just prep it, and then munmap() it.
>
> A bit harder, but still doable, is to provoke the
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> It's not pretty.
>
> Signed-off-by: Daniel Vetter
> Cc: Daniel Vetter
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Hans de Goede
> Cc: Yisheng Xie
> ---
> drivers/video/fbdev/core/fbcon.c | 19 +++
> 1 file changed, 19 insertions(+)
>
On 21/05/2019 10:07, Andrzej Hajda wrote:
@@ -1214,19 +1234,43 @@ static int tc_connector_get_modes(struct drm_connector
*connector)
return count;
}
-static void tc_connector_set_polling(struct tc_data *tc,
-struct drm_connector *connector)
-{
Hi
Am 21.05.19 um 12:35 schrieb Gerd Hoffmann:
> Hi,
>
>> I think would be good to have a lockdep_assert_held here for the ww_mutex.
>>
>> Also general thing: _reserved is kinda ttm lingo, for dma-buf reservations
>> we call the structure tracking the fences+lock the "reservation", but the
>>
On Tue, 2019-05-21 at 13:14 +0300, Laurent Pinchart wrote:
> Hello Jani,
>
> On Tue, May 21, 2019 at 09:44:04AM +0300, Jani Nikula wrote:
> > On Mon, 20 May 2019, Gwan-gyeong Mun
> > wrote:
> > > VSC SDP Payload for PSR is one of data block type of SDP
> > > (Secondaray Data
> > > Packet). In
On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
> Replacing drm_gem_vram_push_to_system() moves policy from drivers back
> to the memory manager. Now, unused BOs are only evicted when the space
> is required.
>
> The lock/unlock-renaming patch aligns the interface with other
Quoting Stephen Rothwell (2019-05-20 15:15:38)
> Hi all,
>
> In commit
>
> 0d90ccb70211 ("drm/i915: Delay semaphore submission until the start of the
> signaler")
>
> Fixes tag
>
> Fixes: e88619646971 ("drm/i915: Use HW semaphores for inter-engine synchroni
>
> has these problem(s):
>
>
To align with the rest of DRM terminology, the GEM VRAM helpers now use
lock and unlock in places where reserve and unreserve where used before.
All callers have been adapted.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/ast/ast_fb.c | 11 +++
Replacing drm_gem_vram_push_to_system() moves policy from drivers back
to the memory manager. Now, unused BOs are only evicted when the space
is required.
The lock/unlock-renaming patch aligns the interface with other names
in DRM. No functional changes are done.
Finally, there's now a lockdep
We may not call drm_gem_vram_{pin,unpin}_locked() with an unlocked
BO. Now test for this.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
The push-to-system function forces a buffer out of video RAM. This decision
should rather be made by the memory manager. By replacing the function with
calls to the kunmap and unpin functions, the buffer's memory becomes available,
but the buffer remains in VRAM until it's evicted by a pin
We introduced new functions in the commit bf39607c1614 ("drm/fourcc: Pass
the format_info pointer to drm_format_plane_width/height") based on
previous ones but with a slightly different prototype. However, the
documentation wasn't changed to reflect that change.
Fixes: bf39607c1614 ("drm/fourcc:
Data M/N calculations were assumed a bpp as RGB format. But when we are
using YCbCr 4:2:0 output format on DP, we should change bpp calculations
as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
therefore, it was multiplied with 3. But YCbCr 4:2:0 requires a multiplier
value to
Bspec describes that GEN10 only supports capability of YUV 4:2:0 output to
HDMI port and GEN11 supports capability of YUV 4:2:0 output to both DP and
HDMI ports.
v2: Minor style fix.
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp.c | 3 +++
1
Am 21.05.19 um 01:16 schrieb Erico Nunes:
> [CAUTION: External Email]
>
> After "5918045c4ed4 drm/scheduler: rework job destruction", jobs are
> only deleted when the timeout handler is able to be cancelled
> successfully.
>
> In case no timeout handler is running (timeout ==
1 - 100 of 149 matches
Mail list logo
