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 a/d
https://bugs.freedesktop.org/show_bug.cgi?id=110717
Gert Wollny changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110701
Gert Wollny changed:
What|Removed |Added
CC||gw.foss...@gmail.com
--- Comment #19 from
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. the
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 bug._
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 actual
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 11:2
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 a
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 unnecessa
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 ne
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
---
drivers/g
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 idr-ge
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: Thomas
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:
F
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")
Sig
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
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 t
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 thro
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 sig
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 requi
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 rev
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
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
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 add
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
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 con
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 app
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: J
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 a/include/drm/drm_mode_object
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 komeda_coeffs_table/manage
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
- ga
- 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 lay
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 bandwidt
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 inspectin
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 / differen
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 al
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
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 execu
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 b
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
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: b/drivers/vi
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: b/drivers/video/fbdev/K
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: b/drivers/video/fbde
^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 v1
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: b/drivers/video/fbdev/K
Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> Create a new wrapper function for this, feels like there's some
> refactoring room here between the two modes.
>
> Signed-off-by: Daniel Vetter
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Cc: Bartlomiej Zolnierkiewicz
> Cc: Daniel Ve
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
>> n
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 operatio
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 +++
drivers/gpu/drm/ast/ast_mode
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 as
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
b/drivers/gpu/drm/drm_gem_vram_helpe
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: P
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 Tuesday, May 21, 2019 11:48 AM, 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 concern
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
>> n
Hi,
On Tue, May 21, 2019 at 01:50:08AM +0200, meg...@megous.com wrote:
> From: Ondrej Jirman
>
> Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
> for the DDC bus to be usable.
>
> Add support for hdmi-connector node's optional ddc-en-gpios property to
> support this use c
Add COMPILE_TEST support to gbefb driver for better compile
testing coverage.
While at it convert bogus udelay() calls to mdelay() (needed to
build driver on ARM) and remove dead x86 specific code.
Signed-off-by: Bartlomiej Zolnierkiewicz
---
v2:
- add missing HAS_IOMEM dependency
- fix build on
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 ord
Hi Maxime,
On Tue, May 21, 2019 at 01:46:11PM +0200, Maxime Ripard wrote:
> Hi,
>
> On Tue, May 21, 2019 at 01:50:08AM +0200, meg...@megous.com wrote:
> > From: Ondrej Jirman
> >
> > Orange Pi 3 board requires enabling a voltage shifting circuit via GPIO
> > for the DDC bus to be usable.
> >
> >
On Tue, May 21, 2019 at 8:47 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.
> >
This patch checks a support of YCBCR420 outputs on an encoder level.
If the input mode is YCBCR420-only mode then it prepares DP as an YCBCR420
output, else it continues with RGB output mode.
It set output_format to INTEL_OUTPUT_FORMAT_YCBCR420 in order to using
a pipe scaler as RGB to YCbCr 4:4:4.
Function intel_pixel_encoding_setup_vsc handles vsc header and data block
setup for pixel encoding / colorimetry format.
Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
for pixel encoding / colorimetry format as per dp 1.4a spec,
section 2.2.5.7.1, table 2-119: VSC SDP H
On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
to MSA and VSC SDP.
And Link M/N values are calculated and applied based on the Full Clock
forYCbCr4
When YCBCR 4:2:0 outputs is used for DP, we should program YCBCR 4:2:0 to
MSA and VSC SDP.
As per DP 1.4a spec section 2.2.4.3 [MSA Field for Indication of Color
Encoding Format and Content Color Gamut] while sending YCBCR 420 signals
we should program MSA MISC1 fields which indicate VSC SDP for t
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 has different reserved data blocks and
Video_Stream_Conf
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 1.5.
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 fi
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 nam
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 but with a slightly different prototype. However, the
> documentation wasn
On Tue, May 21, 2019 at 12:56:30PM +0200, Maarten Lankhorst wrote:
> Op 20-05-2019 om 10:22 schreef Daniel Vetter:
> > Create a new wrapper function for this, feels like there's some
> > refactoring room here between the two modes.
> >
> > Signed-off-by: Daniel Vetter
> > Cc: Lee Jones
> > Cc: Da
Am 21.05.19 um 14:16 schrieb Erico Nunes:
> [CAUTION: External Email]
>
> On Tue, May 21, 2019 at 8:47 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 dele
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):
>
>
On Tue, May 21, 2019 at 8:17 PM Erico Nunes wrote:
>
> On Tue, May 21, 2019 at 8:47 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 w
We also have an incoming patch where the Fixes: line has a comment in
it. Does your tooling account for this when checking the Fixes: line?
Regards, Joonas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/l
Thanks David,
Initially I thought we could run into wait issues with a dma_fence_chain
with a value = 0, but you're right, it works fine.
We could just avoid to create a dma_fence_chain object, but maybe we
don't care.
-Lionel
On 21/05/2019 09:51, zhoucm1 wrote:
Sorry for late response.
On 5/21/19 3:59 AM, Christian König wrote:
> BTW: Is there actually good documentation how to correctly do the variable
> length array at end of structure thing in the kernel?
>
> I do know that I've seen a lot of different variants like array[] array[0] or
> array[1] and I have also seen a b
This is a PCI driver and FB_CYBER2000 depends on PCI in Kconfig so
there is no need to check for PCI inside the driver code.
Cc: Russell King
Signed-off-by: Bartlomiej Zolnierkiewicz
---
drivers/video/fbdev/cyber2000fb.c |5 -
1 file changed, 5 deletions(-)
Index: b/drivers/video/fbdev
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] amdgpu
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
===
--- a/drivers
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.___
dri-deve
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
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.
> >
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 del
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 f
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 lock/unl
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, unused
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 fun
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 wrot
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/of
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 non_block_sta
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 al
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 n
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 c
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 but
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 some
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 fc3
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
> (wi
1 - 100 of 144 matches
Mail list logo
