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 - linux
This is probably a good idea!
Reviewed-by: Robert Foss
On 3/17/19 9:54 PM, Mauro Rossi wrote:
Hi,
I used the option --subject-prefix="PATCH libdrm"
but it did not go as expected.
Anyway, the patch is for Android build of mesa/drm
Mauro
On Sun, Mar 17, 2019 at 9:50 PM Mauro Rossi wrote:
F
Hi Sam,
Le sam. 16 mars 2019 à 21:59, Sam Ravnborg a écrit
:
Hi Paul.
On Fri, Mar 15, 2019 at 06:06:59PM +0100, Paul Cercueil wrote:
Add documentation for the devicetree bindings of the DRM driver for
the
JZ47xx family of SoCs from Ingenic.
Signed-off-by: Paul Cercueil
Tested-by: Artu
In order to support the 1024x600 panel on Yeeloong Loongson MIPS
laptop, the original 1024x768-16 table was modified to 1024x600-16,
without leaving the original. It causes problem on x86 laptop as
the 1024x768-16 support was still claimed but not working.
Fix it by introducing the 1024x768-16 mod
On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), the amount of Video
RAM is not detected correctly by the xf86-video-siliconmotion driver.
This is because sm712fb overwrites the GPR71 Scratch Pad Register, which
is set by BIOS on x86 and used to indicate amount of VRAM.
Other Scratch Pad Registe
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 C
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
Hi Sam,
Le sam. 16 mars 2019 à 22:59, Sam Ravnborg a écrit
:
Hi Paul.
Thanks for the v2 submission.
Did you analyze the possibility to utilize
drm_simple_display_pipe_init()
and the related infrastructure?
If this fits it should simplify the driver.
If it does not fit please let us know wh
On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), rebooting with
sm712fb framebuffer driver would cause the role of brightness up/down
button to swap.
Experiments showed the FPR30 register caused this behavior. Moreover,
even if this register don't have side-effect on other systems, over-
writing
Loongson MIPS netbooks use 1024x600 LCD panels, which is the original
target platform of this driver, but nearly all old x86 laptops have
1024x768. Lighting 768 panels using 600's timings would partially
garble the display. Since it's not possible to distinguish them reliably,
we change the default
Hi all,
This patchset contains a series of important fixes to various problems,
including lockups, crashes, screen gliches, and missing video modes.
These patches are crucial to the correct operation to the hardware,
especially Lynx3DM+ (SM720). I have tested and verified them on x86.
Please revi
When the machine is booted in VGA mode, loading sm712fb would cause
a glitch of random pixels shown on the screen. To prevent it from
happening, we first clear the entire framebuffer, and we also need
to stop calling smtcfb_setmode() during initialization, the fbdev
layer will call it for us later
On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), blanking the display
or starting the X server will crash and freeze the system, or garble the
display.
Experiments showed this problem can mostly be solved by adjusting the
order of register writes. Also, sm712fb failed to consider the difference
On a Thinkpad s30 (Pentium III / i440MX, Lynx3DM), running fbtest or X
will crash the machine instantly, because the VRAM/framebuffer is not
mapped correctly.
On SM712, the framebuffer starts at the beginning of address space, but
SM720's framebuffer starts at the 1 MiB offset from the beginning.
On a second note, this does not apply on libdrm/master due
to:
LOCAL_SHARED_LIBRARIES := \
libcutils
My thinking is that libcutils probably can be replaced with liblog,
but I'm not 100% sure.
Rob.
On 3/18/19 9:09 AM, Robert Foss wrote:
This is probably a good idea!
Reviewed-by: Rob
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:
>
> LOCAL_SHARED_LIBRARIES := \
> libcutils
Sorry, we have an additional Google patch, not present in libdrm/master
that adds libdrm_platform module, but it
https://bugs.freedesktop.org/show_bug.cgi?id=110153
Bug ID: 110153
Summary: login error
Product: DRI
Version: DRI git
Hardware: Other
OS: Windows (All)
Status: NEW
Severity: major
Priority: mediu
https://bugs.freedesktop.org/show_bug.cgi?id=110152
Bug ID: 110152
Summary: login error
Product: DRI
Version: XOrg git
Hardware: PowerPC
OS: Windows (All)
Status: NEW
Severity: minor
Priority: me
https://bugs.freedesktop.org/show_bug.cgi?id=110154
Bug ID: 110154
Summary: login error
Product: DRI
Version: XOrg git
Hardware: PowerPC
OS: Windows (All)
Status: NEW
Severity: minor
Priority: me
https://bugs.freedesktop.org/show_bug.cgi?id=110155
Bug ID: 110155
Summary: login error
Product: DRI
Version: DRI git
Hardware: PowerPC
OS: Windows (All)
Status: NEW
Severity: major
Priority: med
https://bugs.freedesktop.org/show_bug.cgi?id=110157
Bug ID: 110157
Summary: login error
Product: DRI
Version: DRI git
Hardware: SPARC
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=110143
--- Comment #2 from andrew.m.mcma...@gmail.com ---
Just out of interest RBDoom3-BFG works perfectly.
Consider compiling the latest master rather than running Doom 3 through
Wine/Proton. Your RX580 shouldn't have any issue - my R9 285 can handle i
https://bugs.freedesktop.org/show_bug.cgi?id=110160
Bug ID: 110160
Summary: login errer
Product: DRI
Version: unspecified
Hardware: Other
OS: Windows (All)
Status: NEW
Severity: major
Priority: m
https://bugs.freedesktop.org/show_bug.cgi?id=110161
Bug ID: 110161
Summary: login error
Product: DRI
Version: DRI git
Hardware: SPARC
OS: Linux (All)
Status: NEW
Severity: minor
Priority: medium
https://bugs.freedesktop.org/show_bug.cgi?id=110169
Bug ID: 110169
Summary: login error
Product: DRI
Version: XOrg git
Hardware: SGI
OS: Windows (All)
Status: NEW
Severity: normal
Priority: mediu
Hi Dave,
Please pull omapdrm changes for 5.2. There's the DRM_BUS_FLAG change in the
series which
might cause conflicts with other pull requests, so I'm sending this very early.
Tomi
The following changes since commit 9e98c678c2d6ae3a17cb2de55d17f69dddaa231b:
Linux 5.1-rc1 (2019-03-17 14:22
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:
LOCAL_SHARED_LIBRARIES := \
libcutils
Sorry, we have an additional Google patch, not present in libdrm/ma
https://bugs.freedesktop.org/show_bug.cgi?id=110142
--- Comment #3 from Michel Dänzer ---
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c713a461459202504050305242cd854bad57837c
seems the most likely candidate, it's the only significant change to
gmc_v9_0_late_init
https://bugs.freedesktop.org/show_bug.cgi?id=110142
Christian König changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from Christia
https://bugs.freedesktop.org/show_bug.cgi?id=110138
Michel Dänzer changed:
What|Removed |Added
Product|xorg|DRI
Component|Driver/AMDgpu
https://bugs.freedesktop.org/show_bug.cgi?id=110138
--- Comment #2 from Michel Dänzer ---
Please attach the corresponding Xorg log file and output of dmesg.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
Op 12-03-2019 om 19:16 schreef Ayan Halder:
> From: Brian Starkey
>
> As we look to enable AFBC using DRM format modifiers, we run into
> problems which we've historically handled via vendor-private details
> (i.e. gralloc, on Android).
>
> AFBC (as an encoding) is fully flexible, and for example
Hi Laurent,
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 encoder splits even-numbered and odd-numbered pixels between the
> two LV
On 25/02/2019 at 22:25, Alexandre Belloni wrote:
> Make the driver OF only as since AVR32 has been removed from the kernel,
> there are only OF enabled platform using it.
>
> Signed-off-by: Alexandre Belloni
In case it's needed:
Acked-by: Nicolas Ferre
> ---
> drivers/video/fbdev/Kconfig
Create virtio_gpu_object_params, use that to pass object parameters to
virtio_gpu_object_create. This is just the first step, followup patches
will add more parameters to the struct. The plan is to use the struct
for all object parameters.
Drop unused "kernel" parameter for virtio_gpu_alloc_obje
Add 3d resource parameters to virtio_gpu_object_params struct. With
that in place we can use it for virtio_gpu_cmd_resource_create_3d()
calls.
Signed-off-by: Gerd Hoffmann
Acked-by: Noralf Trønnes
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 10 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.
changes in v3:
- We can't drop fencing for the create ioctl (Gurchetan Singh).
Patch #5 is largely rewritten because of that.
changes in v2:
- some cleanup patches are reviewed and merged already, dropped them.
- more verbose commit messages.
Gerd Hoffmann (5):
drm/virtio: move virtio_gpu
This patch moves the virtio_gpu_cmd_create_resource() call (which
notifies the host about the new resource created) into the
virtio_gpu_object_create() function. That way we can call
virtio_gpu_cmd_create_resource() before ttm_bo_init(), so the host
already knows about the object when ttm initiali
Add format, width and height fields to the virtio_gpu_object_params
struct. With that in place we can use the parameter struct for
virtio_gpu_cmd_create_resource() calls too.
Signed-off-by: Gerd Hoffmann
Acked-by: Noralf Trønnes
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 7 ---
drivers/
Drop the dummy ttm backend implementation, add a real one for
TTM_PL_FLAG_TT objects. The bin/unbind callbacks will call
virtio_gpu_object_{attach,detach}, to update the object state
on the host side, instead of invoking those calls from the
move_notify() callback.
With that in place the move and
Hi,
> virtio_gpu_execbuffer_ioctl
> virtio_gpu_resource_create_ioctl with fence resource
> virtio_gpu_wait_ioctl with that fence resource --> associated with a
> GL wait on the host side
After a long break (sidetracked with other stuff) I've finally sent v3
which should address this.
cheers,
It seems like there is no usage of __android_log_vprint in upstream
libdrm. Perhaps this was against libdrm with some android specific
changes on top?
On 3/17/19 10:50 PM, Mauro Rossi wrote:
Fixes the following building error:
FAILED:
$(OUT)/obj/SHARED_LIBRARIES/libdrm_platform_intermediates
Hi,
On Thu, Mar 14, 2019 at 10:54:26AM -0700, Vasily Khoruzhick wrote:
> On Thu, Mar 14, 2019 at 8:42 AM Maxime Ripard
> wrote:
> >
> > Hi Vasily,
> >
> > On Wed, Mar 13, 2019 at 07:58:38PM -0700, Vasily Khoruzhick wrote:
> > > Add support for gamma corretion to sun4i TCON driver. Its LUT has 25
[Tomasz wants to comment, adding him to CC]
On 2/5/18 9:19 AM, Tomeu Vizoso wrote:
On 1 February 2018 at 17:36, Gerd Hoffmann wrote:
Hi,
Sorry for joining the party late. Had a broken finger and was
offline for a bunch of weeks (and a buif backlog afterwards ...).
Hi, no problem, hope it's
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 qutebrow
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&action=edit
0001-drm-amd-display-Only-allow-VRR-when-vrefresh-is-with.patch
I think this patch should fix your iss
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 th
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 fo
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:
> >>
> >> LOCAL_SHARED_LI
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:
LOCAL_SHAR
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 no
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 assigne
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.___
dri-dev
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 m
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 bars.
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
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
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 11
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 ++--
drivers
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()
---
drivers/media/platfo
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 writ
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
Reviewed-
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 ti
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 commit
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 exa
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 out
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 VSP1_DL_FRAME_EN
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 operatio
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 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
---
drivers/gpu/drm/rcar-du/rcar_du
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 function
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
--
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
> i
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 'old_mod
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
>
> topic
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 receivi
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 to
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 fal
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 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.
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 se
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 resp
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.
> >
> >
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 wrote
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, M
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
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://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
https://bugs.freedesktop.org/show_bug.cgi?id=110182
chanchal changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #1 from chanchal ---
i
https://bugs.freedesktop.org/show_bug.cgi?id=110182
chanchal changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |singhals...@gmail.com
|.or
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 re
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 wh
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 lo
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 mod
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 poin
1 - 100 of 142 matches
Mail list logo
