19. 3. 8. 오전 9:12에 Marian Mihailescu 이(가) 쓴 글:
> Tested on my Exynos5422 Odroid XU4, vsync seems to not happen at all,> screen
> remains black since kernel loads.
I faced with same issue.
Andrzej,
Did you test this patch and worked correctly?
I had tested this patch on mainline kernel -
Hi,
On Mon, Mar 18, 2019 at 10:58 AM Robert Foss wrote:
>
> Hey Mauro,
>
> On 3/18/19 9:38 AM, Mauro Rossi wrote:
> > Hi Robert,
> >
> > On Mon, Mar 18, 2019 at 9:21 AM Robert Foss
> > wrote:
> >>
> >> On a second note, this does not apply on libdrm/master due
> >> to:
> >>
> >>
https://bugs.freedesktop.org/show_bug.cgi?id=110140
--- Comment #9 from leoxs...@gmail.com ---
It makes more sense now, we'll take a look. But the thing is we don't got Raven
system with a camera, so it's probably hard to reproduce.
--
You are receiving this mail because:
You are the assignee
On Thu, Mar 14, 2019 at 04:09:13PM +, Måns Rullgård wrote:
> Maxime Ripard writes:
>
> > On Mon, Mar 11, 2019 at 04:11:06PM +, Måns Rullgård wrote:
> >> Maxime Ripard writes:
> >>
> >> > Hi!
> >> >
> >> > On Mon, Mar 11, 2019 at 01:47:13PM +, Mans Rullgard wrote:
> >> >> Sometimes it
Hi Paul,
On Fri, Mar 15, 2019 at 6:58 PM Paul Kocialkowski
wrote:
>
> Hi Jakan,
>
> On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote:
> > Export drm_bridge_detach from drm bridge core so-that it
> > can use on respective interface or bridge driver while
> > detaching the bridge.
>
> I don't
On 3/18/19 3:25 PM, Robert Foss wrote:
Hey,
On 3/18/19 2:11 PM, Mauro Rossi wrote:
Hi,
On Mon, Mar 18, 2019 at 10:58 AM Robert Foss
wrote:
Hey Mauro,
On 3/18/19 9:38 AM, Mauro Rossi wrote:
Hi Robert,
On Mon, Mar 18, 2019 at 9:21 AM Robert Foss
wrote:
On a second note, this does
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #9 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- fi-kbl-7560u fi-icl-u2, fi-icl-u3: random tests - incomplete -}
{+ fi-kbl-7560u fi-icl-u2, fi-icl-u3: random tests - incomplete +}
New failures
Em Mon, 18 Mar 2019 16:31:03 +0200
Laurent Pinchart escreveu:
> Hello everybody,
>
> This is the latest and greatest version of the patch series that
> implements display writeback support for the R-Car Gen3 platforms in the
> VSP1 and DU drivers. All patches have been reviewed, all comments
>
On 15/03/2019 12:09, Chunming Zhou wrote:
points array is one-to-one match with syncobjs array.
v2:
add seperate ioctl for timeline point wait, otherwise break uapi.
v3:
userspace can specify two kinds waits::
a. Wait for time point to be completed.
b. and wait for time point to become available
Hi Thomas,
Thanks for doing this and somehow I missed the last patch, sorry about
that. Have some questions below otherwise the patch looks good to me.
Reviewed-by: Deepak Rawat
I will include your changes in vmwgfx-next and run tests.
On Mon, 2019-03-18 at 15:47 +0100, Thomas Zimmermann
Hi Laurent,
Sorry for the delay, I was travelling last week and didn't find a
chance to digest your diagrams (thanks for all the detail!)
On Fri, Mar 08, 2019 at 02:24:40PM +0200, Laurent Pinchart wrote:
> Hi Brian,
>
> On Thu, Mar 07, 2019 at 12:28:08PM +, Brian Starkey wrote:
> > On Wed,
https://bugs.freedesktop.org/show_bug.cgi?id=110182
chanchal changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from chanchal ---
https://bugs.freedesktop.org/show_bug.cgi?id=110182
chanchal changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |singhals...@gmail.com
https://bugs.freedesktop.org/show_bug.cgi?id=110137
--- Comment #1 from Nicholas Kazlauskas ---
AFAIK, the matching should just be done based on the executable name.
See: src/util/u_process.c
The process name likely differs for the content processes for the browser. You
might need both
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #27 from Clément Guérin (li...@protonmail.com) ---
I'm sorry, I assumed this particular commit had been backported to Linux 5.0,
and it's apparently not the case. I will try with both when I find some time
tonight.
--
You are
Hi
This series implements properly working vblank and pageflip completion
timestamping for amdgpu in VRR / FreeSync mode.
Now pageflip timestamps for pageflip events always carry the
vblank timestamp of the vblank in which the flip completed,
and the vblank timestamp is as accurate as in fixed
During VRR mode we can not allow vblank irq dis-/enable
transitions, as an enable after a disable can happen at
an arbitrary time during the video refresh cycle, e.g.,
with a high likelyhood inside vblank front-porch. An
enable during front-porch would cause vblank timestamp
updates/calculations
For throttling to work correctly, we always need a baseline vblank
count last_flip_vblank that increments at start of front-porch.
This is the case for drm_crtc_vblank_count() in non-VRR mode, where
the vblank irq fires at start of front-porch and triggers DRM core
vblank handling, but it is no
In VRR mode, proper vblank/pageflip timestamps can only be computed
after the display scanout position has left front-porch. Therefore
delay calls to drm_crtc_handle_vblank(), and thereby calls to
drm_update_vblank_count() and pageflip event delivery, to after the
end of front-porch when in VRR
https://bugs.freedesktop.org/show_bug.cgi?id=110031
--- Comment #4 from Tom Hughes ---
Doesn't the drm.debug=6 that I used before already include 4 as it's a bitmask?
--
You are receiving this mail because:
You are the assignee for the bug.___
Hi Dave,
The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
Linux 5.1-rc1 (2019-03-17 14:22:26 -0700)
are available in the Git repository at:
git://linuxtv.org/pinchartl/media.git tags/du-next-20190318
for you to fetch changes up
We want vblank counts and timestamps of flip completion as sent
in pageflip completion events to be consistent with the vblank
count and timestamp of the vblank of flip completion, like in non
VRR mode.
In VRR mode, drm_update_vblank_count() - and thereby vblank
count and timestamp updates - must
Am 18.03.19 um 17:59 schrieb Lionel Landwerlin:
> On 15/03/2019 12:09, Chunming Zhou wrote:
>> points array is one-to-one match with syncobjs array.
>> v2:
>> add seperate ioctl for timeline point wait, otherwise break uapi.
>> v3:
>> userspace can specify two kinds waits::
>> a. Wait for time
https://bugs.freedesktop.org/show_bug.cgi?id=110031
--- Comment #5 from Nicholas Kazlauskas ---
Ah, those were both dmesg logs. Those are sufficient then, thanks!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
Hi Geert,
On Mon, Mar 18, 2019 at 11:21:15AM +0100, Geert Uytterhoeven wrote:
> On Thu, Mar 7, 2019 at 12:24 AM Laurent Pinchart wrote:
> > Add a new optional renesas,companion property to point to the companion
> > LVDS encoder. This is used to support dual-link operation where the main
> > LVDS
Hi,
On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote:
> Hey..
>
> There's a conflict with this patch and the merge of topic/hdr-formats,
> resulting in double definitions for Y210, Y410 and P010.
>
> Worse still is that one has set has_alpha to true for Y41x and other to
Hey,
On 3/18/19 2:11 PM, Mauro Rossi wrote:
Hi,
On Mon, Mar 18, 2019 at 10:58 AM Robert Foss wrote:
Hey Mauro,
On 3/18/19 9:38 AM, Mauro Rossi wrote:
Hi Robert,
On Mon, Mar 18, 2019 at 9:21 AM Robert Foss wrote:
On a second note, this does not apply on libdrm/master due
to:
When configuring partitions for memory-to-memory pipelines, the WPF
accesses data of the current partition through pipe->partition.
Writeback support will require full configuration of the WPF while not
providing a valid pipe->partition. Rework the configuration code to fall
back to the full image
Implement writeback support for R-Car Gen3 by exposing writeback
connectors. Behind the scene the calls are forwarded to the VSP
backend.
Using writeback connectors will allow implemented writeback support for
R-Car Gen2 with a consistent API if desired.
Signed-off-by: Laurent Pinchart
Extend the vsp1_du_atomic_flush() API with writeback support by adding
format, pitch and memory addresses of the writeback framebuffer.
Writeback completion is reported through the existing frame completion
callback with a new VSP1_DU_STATUS_WRITEBACK status flag.
Signed-off-by: Laurent Pinchart
The WPF needs access to the current display list to configure writeback.
Add a display list pointer to the VSP1 entity .configure_stream()
operation.
Only display pipelines can make use of the display list there as
mem-to-mem pipelines don't have access to a display list at stream
configuration
Writeback jobs are allocated when the WRITEBACK_FB_ID is set, and
deleted when the jobs complete. This results in both a memory leak of
the job and a leak of the framebuffer if the atomic commit returns
before the job is queued for processing, for instance if the atomic
check fails or if the
Refactor the display list header setup to allow chained display lists
with display pipelines. Chain the display lists as for mem-to-mem
pipelines, but enable the frame end interrupt for every list as display
pipelines have a single list per frame.
This feature will be used to disable writeback
Add support for the writeback feature of the WPF, to enable capturing
frames at the WPF output for display pipelines. To enable writeback the
vsp1_rwpf structure mem field must be set to the address of the
writeback buffer and the writeback field set to true before the WPF
.configure_stream() and
The rcar_du_vsp_plane_prepare_fb() and rcar_du_vsp_plane_cleanup_fb()
functions implement the DRM plane .prepare_fb() and .cleanup_fb()
operations. They map and unmap the framebuffer to/from the VSP
internally, which will be useful to implement writeback support. Split
the mapping and unmapping
Display list fragments have been renamed to bodies. Replace one last
occurrence of the word fragment in the documentation.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_dl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
The VSP1 driver will need to pass extra flags to the DU through the
frame completion API. Replace the completed bool flag by a bitmask to
support this.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v6:
- Add a comment to keep VSP1_DU_STATUS_* and
Hello everybody,
This is the latest and greatest version of the patch series that
implements display writeback support for the R-Car Gen3 platforms in the
VSP1 and DU drivers. All patches have been reviewed, all comments
incorporated, and the result rebased on top ov v5.1-rc1.
Patches 01/18 to
The VSP-DL instances have two LIFs, and thus two copies of the
VI6_DISP_IRQ_ENB, VI6_DISP_IRQ_STA and VI6_WPF_WRBCK_CTRL registers. Fix
the corresponding macros accordingly.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_drm.c | 4 ++--
To prepare for addition of more flags to the display list, replace the
'internal' flag field by a bitmask 'flags' field.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v4:
- Fix check for the completed flag in vsp1_du_pipeline_frame_end()
---
From: Kieran Bingham
This reverts commit 3299ba5c0b21 ("[media] v4l: vsp1: Supply frames to
the DU continuously")
The DU output mode does not rely on frames being supplied on the WPF as
its pipeline is supplied from DRM. For the upcoming WPF writeback
functionality, we will choose to enable
Hi Daniel,
On Fri, 15 Mar 2019 at 16:36, Daniel Vetter wrote:
>
> On Thu, Mar 14, 2019 at 6:49 PM Sumit Semwal wrote:
> >
> > Hello Chenbo,Thank you for your RFC series.
> >
> > On Wed, 27 Feb 2019 at 09:24, Chenbo Feng wrote:
> > >
> > > Currently, all dma-bufs share the same anonymous inode.
On Mon, Mar 18, 2019 at 10:27 PM Paul Kocialkowski
wrote:
>
> Hi,
>
> Le lundi 18 mars 2019 à 22:18 +0530, Jagan Teki a écrit :
> > Hi Paul,
> >
> > On Fri, Mar 15, 2019 at 6:58 PM Paul Kocialkowski
> > wrote:
> > > Hi Jakan,
> > >
> > > On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote:
> > >
https://bugzilla.kernel.org/show_bug.cgi?id=201795
--- Comment #22 from thomas.lassdiesonner...@gmx.de ---
I investigated further and the culprit seems to be that kernel =4.14 ignores
what xrandr *wrongly* detects and sets the connected TV correctly to its native
3840x2160@60hz without black
When calling vmw_fb_set_par(), the mode stored in par->set_mode gets free'd
twice. The first free is in vmw_fb_kms_detach(), the second is near the
end of vmw_fb_set_par() under the name of 'old_mode'. The mode-setting code
only works correctly if the mode doesn't actually change. Removing
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #26 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) ---
Was "drm/amd/display: Use vrr friendly pageflip throttling in DC." also in the
tree you built?
--
You are receiving this mail because:
You are watching the assignee of
Quoting Maarten Lankhorst (2019-03-13 13:21:46)
> Hey Sean and Joonas,
>
> One more pull request for the hdr-formats topic branch. FP16 support
> is now also implemented.
>
> Can this be pulled to drm-misc-next and dinq?
Pulled to drm-intel-next-queued.
Regards, Joonas
>
> ~Maarten
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=110138
--- Comment #3 from Nicholas Kazlauskas ---
Created attachment 143724
--> https://bugs.freedesktop.org/attachment.cgi?id=143724=edit
0001-drm-amd-display-Only-allow-VRR-when-vrefresh-is-with.patch
I think this patch should fix your issue. We
https://bugs.freedesktop.org/show_bug.cgi?id=110031
--- Comment #3 from Nicholas Kazlauskas ---
Please post a dmesg log after booting (preferably after the commit failure
occurs) with drm.debug=4 as part of your kernel boot parameters.
--
You are receiving this mail because:
You are the
The mapping between DRM and V4L2 fourcc's is stored in two separate
tables in rcar_du_vsp.c. In order to make it reusable to implement
writeback support, move it to the rcar_du_format_info structure.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
The drm_writeback_queue_job() function takes ownership of the passed job
and requires the caller to manually set the connector state
writeback_job pointer to NULL. To simplify drivers and avoid errors
(such as the missing NULL set in the vc4 driver), pass the connector
state pointer to the
As writeback jobs contain a framebuffer, drivers may need to prepare and
cleanup them the same way they can prepare and cleanup framebuffers for
planes. Add two new optional connector helper operations,
.prepare_writeback_job() and .cleanup_writeback_job() to support this.
The job prepare
The rcar_du_crtc structure index field contains the CRTC hardware index,
not the hardware and software index. Update the documentation
accordingly.
Fixes: 5361cc7f8e91 ("drm: rcar-du: Split CRTC handling to support hardware
indexing")
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
The code that initializes the RPF format-related fields for display
pipelines will also be useful for the WPF to implement writeback
support. Split it from vsp1_du_atomic_update() to a new
vsp1_du_pipeline_set_rwpf_format() function.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
Hi,
Le lundi 18 mars 2019 à 22:18 +0530, Jagan Teki a écrit :
> Hi Paul,
>
> On Fri, Mar 15, 2019 at 6:58 PM Paul Kocialkowski
> wrote:
> > Hi Jakan,
> >
> > On Fri, 2019-03-15 at 18:38 +0530, Jagan Teki wrote:
> > > Export drm_bridge_detach from drm bridge core so-that it
> > > can use on
On Fri, Mar 15, 2019 at 7:04 PM Maxime Ripard wrote:
>
> On Fri, Mar 15, 2019 at 06:38:23PM +0530, Jagan Teki wrote:
> > ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
> > It has a flexible configuration of MIPI DSI signal input
> > and produce RGB565, RGB666, RGB888 output format.
> >
>
https://bugs.freedesktop.org/show_bug.cgi?id=110182
Bug ID: 110182
Summary: igt/gem_sync
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority: medium
On Fri, Mar 15, 2019 at 7:03 PM Maxime Ripard wrote:
>
> On Fri, Mar 15, 2019 at 06:38:24PM +0530, Jagan Teki wrote:
> > ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
> > It has a flexible configuration of MIPI DSI signal input
> > and produce RGB565, RGB666, RGB888 output format.
> >
>
On 3/18/19 1:19 PM, Mario Kleiner wrote:
> For throttling to work correctly, we always need a baseline vblank
> count last_flip_vblank that increments at start of front-porch.
>
> This is the case for drm_crtc_vblank_count() in non-VRR mode, where
> the vblank irq fires at start of front-porch
On 18/03/2019 17:20, Koenig, Christian wrote:
- if (dma_fence_is_signaled(entries[i].fence)) {
+ if (fence)
+ entries[i].fence = fence;
+ else
+ entries[i].fence = dma_fence_get_stub();
+
+ if ((flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_AVAILABLE)
On Mon, Mar 18, 2019 at 07:00:57PM +, Brian Starkey wrote:
> On Mon, Mar 18, 2019 at 07:12:24PM +0100, Maarten Lankhorst wrote:
> > Op 18-03-2019 om 16:40 schreef Brian Starkey:
> > > Hi,
> > >
> > > On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote:
> > >
> > >
> > >
> > >>
Hi,
On Wed, Jan 16, 2019 at 10:46 AM Douglas Anderson wrote:
>
> The patch ("OPP: Add support for parsing the 'opp-level' property")
> adds an API enabling a cleaner way to read the opp-level. Let's use
> the new API.
>
> Signed-off-by: Douglas Anderson
> Reviewed-by: Jordan Crouse
> ---
>
Op 18-03-2019 om 16:40 schreef Brian Starkey:
> Hi,
>
> On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote:
>
>
>
>> Hey..
>>
>> There's a conflict with this patch and the merge of topic/hdr-formats,
>> resulting in double definitions for Y210, Y410 and P010.
>>
>> Worse still is
On Mon, Mar 11, 2019 at 9:36 PM Jagan Teki wrote:
>
> On Mon, Mar 11, 2019 at 9:08 PM Maxime Ripard
> wrote:
> >
> > On Mon, Mar 11, 2019 at 07:06:24PM +0530, Jagan Teki wrote:
> > > pll-video => pll-mipi => tcon0 => tcon0-pixel-clock is the typical
> > > MIPI clock topology in Allwinner DSI
Alex already applied an equivalent patch by Colin King (attached for
reference).
Regards,
Felix
On 3/18/2019 2:05 PM, Gustavo A. R. Silva wrote:
> Assign return value of function amdgpu_bo_sync_wait() to variable ret
> for its further check.
>
> Addresses-Coverity-ID: 1443914 ("Logically
On Mon, Mar 18, 2019 at 07:06:39PM +, Brian Starkey wrote:
> > [1]
> > https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/commit/0ac7d1187b234e86157ad74937c249a3c016807c
>
> Eh. I'm not familiar enough with the gitlab UI. Looks like this didn't
> merge in GStreamer so far.
Gah! Still
Hi,
On Sun, Mar 3, 2019 at 11:06 PM Jagan Teki wrote:
>
> Unfortunately due to various reasons[3] the previous fixes[1] and burst[2]
> changes are failed to apply.
>
> So, this series is filtered version of previous [1] and [2] changes on top
> of drm-misc.
>
> patch-1: Fix for burst mode
https://bugs.freedesktop.org/show_bug.cgi?id=107731
--- Comment #6 from Harry Wentland ---
Thanks. This is definitely a link training failure.
Can you see if your monitor is set to auto-select the input and force it to
select the DP input? Some monitors don't respond well to link training when
Quoting Peter Griffin (2019-03-18 12:38:51)
> As now we also need to probe in the reset driver as well.
>
> Signed-off-by: Peter Griffin
> ---
> drivers/clk/hisilicon/clk-hi6220.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Doesn't this need to be squashed with the reset driver
Am Freitag, 1. März 2019, 13:56:23 CET schrieb Maarten Lankhorst:
> Convert rockchip to using __drm_atomic_helper_crtc_reset(), instead of
> writing its own version. Instead of open coding
> destroy_state(), call it directly for freeing the old state.
>
> Signed-off-by: Maarten Lankhorst
> Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=110183
Bug ID: 110183
Summary: check out
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: critical
Priority: medium
Assign return value of function amdgpu_bo_sync_wait() to variable ret
for its further check.
Addresses-Coverity-ID: 1443914 ("Logically dead code")
Fixes: c60cd590cb7d ("drm/amdgpu: Replace ttm_bo_wait with amdgpu_bo_sync_wait")
Signed-off-by: Gustavo A. R. Silva
---
On Mon, Mar 18, 2019 at 07:12:24PM +0100, Maarten Lankhorst wrote:
> Op 18-03-2019 om 16:40 schreef Brian Starkey:
> > Hi,
> >
> > On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote:
> >
> >
> >
> >> Hey..
> >>
> >> There's a conflict with this patch and the merge of
Dear Harry,
On 18.03.19 21:55, Wentland, Harry wrote:
On 2019-03-08 4:11 a.m., Michel Dänzer wrote:
On 2019-03-06 5:35 p.m., Paul Menzel wrote:
On 03/06/19 15:55, Michel Dänzer wrote:
On 2019-03-06 1:41 p.m., Paul Menzel wrote:
On 03/05/19 20:07, Alex Deucher wrote:
On Tue, Mar 5, 2019
Hi Jonas,
Am Mittwoch, 20. Februar 2019, 23:40:06 CET schrieb Jonas Karlman:
> NV12 framebuffers produced by the VPU shows distorted on RK3288
> after win has been disabled when scaling is active.
>
> This issue can be reproduced using a 1080p modeset by:
> - Scale a 1280x720 NV12 framebuffer to
On 3/18/19 1:25 PM, Kuehling, Felix wrote:
> Alex already applied an equivalent patch by Colin King (attached for
> reference).
>
Oh, that's great. Good to know.
Thanks, Felix.
--
Gustavo
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #28 from Clément Guérin (li...@protonmail.com) ---
Nevermind. This commit was merged right before 5.0 was released. So yes, it was
in the tree.
What I suspect is happening is that a couple or more frames are scheduled by
the BTR
https://bugs.freedesktop.org/show_bug.cgi?id=109763
Kristoffer changed:
What|Removed |Added
CC||bri...@outlook.com
--- Comment #13 from
https://bugs.freedesktop.org/show_bug.cgi?id=109763
--- Comment #14 from Shmerl ---
(In reply to Kristoffer from comment #13)
> I believe Chill might be encumbered by patents so I'm not sure an open
> source implementation is legally possible.
>
>
On 3/18/19 1:19 PM, Mario Kleiner wrote:
> During VRR mode we can not allow vblank irq dis-/enable
> transitions, as an enable after a disable can happen at
> an arbitrary time during the video refresh cycle, e.g.,
> with a high likelyhood inside vblank front-porch. An
> enable during front-porch
Hello Qiang,
Sorry for weighing in late on this, I've quite a backlog to work
through.
Since your first patch set, I did raise this internally. The request
has been making it's way through:
- GPU engineering, to determine what exactly this format is, and
what other variants there might be
On 03/15, Ville Syrjälä wrote:
> On Fri, Mar 15, 2019 at 08:51:57AM -0300, Rodrigo Siqueira wrote:
> > On 03/11, Ville Syrjälä wrote:
> > > On Sun, Mar 10, 2019 at 05:35:05PM -0300, Rodrigo Siqueira wrote:
> > > > On 03/01, Ville Syrjälä wrote:
> > > > > On Fri, Mar 01, 2019 at 03:35:35PM -0300,
On 2019-03-08 4:11 a.m., Michel Dänzer wrote:
> On 2019-03-06 5:35 p.m., Paul Menzel wrote:
>> On 03/06/19 15:55, Michel Dänzer wrote:
>>> On 2019-03-06 1:41 p.m., Paul Menzel wrote:
On 03/05/19 20:07, Alex Deucher wrote:
> On Tue, Mar 5, 2019 at 1:16 PM Paul Menzel wrote:
>>
https://bugs.freedesktop.org/show_bug.cgi?id=103430
lonelywoolf changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
On Tue, Mar 19, 2019 at 12:58 AM Jagan Teki wrote:
>
> On Fri, Mar 15, 2019 at 7:04 PM Maxime Ripard
> wrote:
> >
> > On Fri, Mar 15, 2019 at 06:38:23PM +0530, Jagan Teki wrote:
> > > ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
> > > It has a flexible configuration of MIPI DSI signal
https://bugs.freedesktop.org/show_bug.cgi?id=106571
lonelywoolf changed:
What|Removed |Added
Component|DRM/AMDgpu |DRM/amdkfd
Severity|normal
https://bugs.freedesktop.org/show_bug.cgi?id=107296
--- Comment #10 from jzahra...@gmail.com ---
Testing Linux 5.1-rc1, error still present.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=110142
--- Comment #6 from Peter Easton ---
Whoops, hit return too quickly.
(In reply to Michel Dänzer from comment #3)
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/
> ?id=c713a461459202504050305242cd854bad57837c seems
https://bugs.freedesktop.org/show_bug.cgi?id=110184
Bug ID: 110184
Summary: kernel BUG at drivers/dma-buf/reservation.c:172
(kernel 5.0.2)
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=103430
Andre Klapper changed:
What|Removed |Added
Group||spam
Component|DRM/amdkfd
Hi, Frank:
My platform's fbcon works correctly, so I've applied this series to [1].
If you have another patch, I'd treat it as a bug-fix.
[1]
https://github.com/ckhu-mediatek/linux.git-tags/commits/mediatek-drm-fixes-5.1
Regards,
CK
On Sun, 2019-01-20 at 14:36 +0100, Frank Wunderlich wrote:
>
https://bugs.freedesktop.org/show_bug.cgi?id=110142
--- Comment #5 from Peter Easton ---
I'm going to try to see if I can narrow things down a bit by finding the last
commit that worked before the bug happened and then bisect the kernel there.
I'm going to try to compile the kernels, install
https://bugs.freedesktop.org/show_bug.cgi?id=106571
--- Comment #2 from lonelywoolf ---
suspend works ok. Only hibernate hanging.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=109370
--- Comment #5 from Tom Seewald ---
Have the LLVM developers been notified of this, and if so, can you provide a
link to the report?
--
You are receiving this mail because:
You are the assignee for the
19. 3. 15. 오후 10:08에 Jagan Teki 이(가) 쓴 글:
> drm_bridge_detach now available to use while detaching
> bridge, use this core wrapper instead of explicitly
> pointing the bridge funcs.
>
> Cc: Dae
> Cc: Joonyoung Shim
> Cc: Seung-Woo Kim
> Cc: Kyungmin Park
> Signed-off-by: Jagan Teki
Hi all,
Today's linux-next merge of the drm-misc tree got a conflict in:
drivers/gpu/drm/i915/intel_hdmi.c
between commit:
fbf08556ed43 ("drm/i915: Precompute HDMI infoframes")
from the drm-intel tree and commit:
2f146b78d5a9 ("drm/i915: Attach colorspace property and enable modeset")
On Mon, Mar 18, 2019 at 07:12:24PM +0100, Maarten Lankhorst wrote:
> Op 18-03-2019 om 16:40 schreef Brian Starkey:
> > Hi,
> >
> > On Mon, Mar 18, 2019 at 11:17:55AM +0100, Maarten Lankhorst wrote:
> >
> >
> >
> >> Hey..
> >>
> >> There's a conflict with this patch and the merge of
On Tue, Mar 19, 2019 at 1:59 AM Jagan Teki wrote:
>
> On Fri, Mar 15, 2019 at 7:03 PM Maxime Ripard
> wrote:
> >
> > On Fri, Mar 15, 2019 at 06:38:24PM +0530, Jagan Teki wrote:
> > > ICN6211 is MIPI-DSI/RGB converter bridge from chipone.
> > > It has a flexible configuration of MIPI DSI signal
On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with
sm712fb framebuffer driver would cause a white screen of death on
the next POST, presumably the proper timings for the LCD panel was
not reprogrammed properly by the BIOS.
Experiments showed a few CRTC Scratch Registers, including
mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which needs
ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called after last
irq, it will timeout with this message: "vblank wait timed out
1 - 100 of 141 matches
Mail list logo
