On Wed, Oct 31, 2018 at 08:43:03AM +, Chris Wilson wrote:
> Quoting Jonathan Gray (2018-10-31 00:56:12)
> > Chris Wilson said Intel is willing to change the license of these files
> > to MIT.
> >
> > Signed-off-by: Jonathan Gray
> Reviewed-by: Chris Wilson
> -Chris
Still looking to get this
On Thu, 15 Nov 2018, Fernando Ramos wrote:
> The coccinelle script was used to rename some (deprecated) functions
> which no longer exist now.
>
> Signed-off-by: Fernando Ramos
Acked-by: Julia Lawall
> ---
> scripts/coccinelle/api/drm-get-put.cocci | 78
> 1 file c
I find the reservation object will be created when: dma_buf_export
if no reservation object created when buffer object creation.
And the implicit fence can be synced before display in: drm_gem_fb_prepare_fb
but seems most display driver doesn't call this function.
Regards,
Qiang
On Sun, Nov 18, 2
add ".prepare_fb = drm_gem_fb_prepare_fb," in "drm_plane_helper_funcs"
solve my flicker problem on Allwinner A64.
Thanks,
Qiang
On Sun, Nov 18, 2018 at 8:14 PM Qiang Yu wrote:
>
> I find the reservation object will be created when: dma_buf_export
> if no reservation object created when buffer ob
On 11/12, Maarten Lankhorst wrote:
> We already have __drm_atomic_helper_connector_reset() and
> __drm_atomic_helper_plane_reset(), extend this to crtc as well.
>
> Most drivers already have a gpu reset hook, correct it.
> Nouveau already implemented its own __drm_atomic_helper_crtc_reset(),
> con
https://bugs.freedesktop.org/show_bug.cgi?id=108037
--- Comment #10 from Öyvind Saether ---
I turned off freesync on one monitor and have been using
Section "Extensions"
Option "DPMS" "Disable"
EndSection
in /etc/X11/xorg.conf.d/20-amdgpu.conf which appears to prevent this from
happeni
https://bugs.freedesktop.org/show_bug.cgi?id=108778
--- Comment #1 from erhar...@mailbox.org ---
Created attachment 142506
--> https://bugs.freedesktop.org/attachment.cgi?id=142506&action=edit
dmesg (4.19.2, non-working)
Same here on kernel 4.19.2 with a R9 390. The other 2 cards in my system (
https://bugs.freedesktop.org/show_bug.cgi?id=108778
--- Comment #2 from erhar...@mailbox.org ---
Created attachment 142507
--> https://bugs.freedesktop.org/attachment.cgi?id=142507&action=edit
dmesg (4.18.19, working)
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #41 from afm ---
RX 570
1002:67df [AMD/ATI] Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev
ef)
Kernel: 4.19.2-300.fc29.x86_64
1920x1080 59.93*+
Lots of strange flickering and black lines with dc=1. Strange ghosting and
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #42 from afm ---
Just to add. I noticed the corruption during the plymouth boot screen too.
After just waking the monitors from DPMS i got corruption until I echo'd 0
again.
--
You are receiving this mail because:
You are the assig
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #43 from afm ---
OK really sorry for the noise on this ticket. It seems I did this to myself
with featuremask 0xfff . All is working without it. (i had been using
watman gtk)
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #44 from tempel.jul...@gmail.com ---
I have this issue also without amdgpu.ppfeaturemask=0x.
amdgpu.dc 0 or 1 doesn't make a difference for me.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=105113
--- Comment #7 from Jan Vesely ---
(In reply to Maciej S. Szmigiero from comment #6)
> There are really two issues at play here:
> 1) If the LLVM-generated code cannot be run properly then it should be simply
> rejected by whatever is actually i
The TPO (Toppoly) TPG110 is a pretty generic display driver
similar in vein to the Ilitek 93xx devices. It is not a panel
per se but a driver used with several low-cost noname panels.
This is used on the Nomadik NHK15 combined with a OSD
OSD057VA01CT display for WVGA 800x480.
The driver is pretty
After adding the hs_rate and lp_rate fields to the DSI device
we need to populate these accordingly so display drivers can
respect them.
This figure for HS rate comes from the ILI9881C manual, the
calculation is explained in the comment.
Cc: Daniel Vetter
Cc: Andrzej Hajda
Acked-by: Maxime Ripa
On Wed, Nov 14, 2018 at 3:31 PM Heiko Stübner wrote:
> Am Mittwoch, 14. November 2018, 12:42:54 CET schrieb Linus Walleij:
> > After adding the hs_rate and lp_rate fields to the DSI device
> > we need to populate these accordingly so display drivers can
> > respect them.
> >
> > Cc: Andrzej Hajda
After adding the hs_rate and lp_rate fields to the DSI device
we need to populate these accordingly so display drivers can
respect them.
Cc: Andrzej Hajda
Cc: Chris Zhong
Cc: Lin Huang
Cc: Heiko Stuebner
Tested-by: Heiko Stuebner
Signed-off-by: Linus Walleij
---
ChangeLog v1->v2:
- Collect H
https://bugs.freedesktop.org/show_bug.cgi?id=108493
--- Comment #16 from Timur Kristóf ---
Hi,
After some more experimentation it seems that increasing the highest mclk
voltage above 900 mV and setting all other voltages in pp_od_clk_voltage in
such a way that they remain below 1000 mV, is a vi
On Sun, Nov 18, 2018 at 08:30:39PM +0100, Linus Walleij wrote:
> The TPO (Toppoly) TPG110 is a pretty generic display driver
> similar in vein to the Ilitek 93xx devices. It is not a panel
> per se but a driver used with several low-cost noname panels.
>
> This is used on the Nomadik NHK15 combine
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #45 from bmil...@gmail.com ---
A temporary way to at least lock mclck forever would be great until this is
fixed. There is no sane way to do it permanently (some events switch it back to
auto, IE resolution changes and sleep/wake)
--
https://bugs.freedesktop.org/show_bug.cgi?id=108709
--- Comment #2 from mikhail.v.gavri...@gmail.com ---
Yes, your patch fix this issue, thanks.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-dev
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #46 from tempel.jul...@gmail.com ---
As a workaround, a timer job/script writing every few seconds might do the
trick.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=108709
--- Comment #3 from mikhail.v.gavri...@gmail.com ---
Created attachment 142508
--> https://bugs.freedesktop.org/attachment.cgi?id=142508&action=edit
dmesg 4.20.0-0.rc2.git2.1 before Chris patch
--
You are receiving this mail because:
You are
https://bugs.freedesktop.org/show_bug.cgi?id=108709
--- Comment #4 from mikhail.v.gavri...@gmail.com ---
Created attachment 142509
--> https://bugs.freedesktop.org/attachment.cgi?id=142509&action=edit
dmesg 4.20.0-0.rc2.git2.1 after Chris patch
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=108709
--- Comment #5 from mikhail.v.gavri...@gmail.com ---
Chris, I am appreciate your work.
Hope to see this patch as soon as possible in mainline.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #42 from Brandon Wright ---
This is pretty serious. Just moving the mouse cursor around while something
slightly GPU-heavy is running at 60hz can produce frame-skipping.
I switched the display core off with amdgpu.dc=0 and everythin
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #43 from bmil...@gmail.com ---
(In reply to Brandon Wright from comment #42)
> This is pretty serious. Just moving the mouse cursor around while something
> slightly GPU-heavy is running at 60hz can produce frame-skipping.
>
> I swit
On Fri, 2 Nov 2018 at 20:21, Jani Nikula wrote:
>
>
> Hi Dave -
>
> I just tagged this minutes ago, but I'm sending this now because I'll be
> out for about a week. I don't expect you to pull this until some time
> after -rc1 anyway. I'm asking Joonas and Rodrigo to tell you if this
> one's a go o
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #44 from Brandon Wright ---
You're too late, I already tried it. But as you say, there's no improvement.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-d
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #45 from rro...@gmail.com ---
(In reply to bmilreu from comment #43)
> If devs want an easy test case, use these links for reproducing it in
> chromium:
>
> https://www.vsynctester.com/
> https://www.testufo.com/photo
> https://www.s
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #45 from Kent Ross ---
This happens to me as well. I first noticed it occurring when I had a
double-GPU setup, but since then I have completely reinstalled with only the
AMD gpu (a Vega 64) and it still happens. The failures are simi
https://bugs.freedesktop.org/show_bug.cgi?id=105733
--- Comment #46 from Kent Ross ---
Created attachment 142511
--> https://bugs.freedesktop.org/attachment.cgi?id=142511&action=edit
dmesg logs for failure
Other items of potential relevance:
I have two screens, one at 3840x2160 and one at 256
Hi, Matthias:
On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> It can happen that the mmsys clock drivers aren't probed before the
> platform driver gets invoked. The platform driver used to print a warning
> that the driver failed to get the clocks.
Hi, Matthias:
On Fri, 2018-11-16 at 13:54 +0100, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> The MMSYS subsystem includes clocks and drm components.
> This patch adds an initailization path through a platform device
> for the clock part, so that both drivers get probed from the s
On 18.11.2018 22:31, Linus Walleij wrote:
> After adding the hs_rate and lp_rate fields to the DSI device
> we need to populate these accordingly so display drivers can
> respect them.
>
> This figure for HS rate comes from the ILI9881C manual, the
> calculation is explained in the comment.
>
> Cc:
On 18.11.2018 22:36, Linus Walleij wrote:
> After adding the hs_rate and lp_rate fields to the DSI device
> we need to populate these accordingly so display drivers can
> respect them.
>
> Cc: Andrzej Hajda
> Cc: Chris Zhong
> Cc: Lin Huang
> Cc: Heiko Stuebner
> Tested-by: Heiko Stuebner
> Si
https://bugs.freedesktop.org/show_bug.cgi?id=105982
jian-h...@endlessm.com changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Hi,
At FOSDEM on saturday the 3rd of february 2018, there will be another
graphics DevRoom. URL: https://fosdem.org/2018/
The focus of this DevRoom is of course the same as the previous
editions, namely:
* Graphics drivers: from display to media to 3d drivers, both in kernel
or userspace. Be
On 29.10.2018 12:46, Tomi Valkeinen wrote:
> Initially DP0_SRCCTRL is set to a static value which includes
> DP0_SRCCTRL_LANES_2 and DP0_SRCCTRL_BW27, even when only 1 lane of
> 1.62Gbps speed is used. DP1_SRCCTRL is configured to a magic number.
>
> This patch changes the configuration as follows:
On Mon, Nov 19, 2018 at 08:17:32AM +0100, Luc Verhaegen wrote:
> Hi,
>
> At FOSDEM on saturday the 3rd of february 2018, there will be another
> graphics DevRoom. URL: https://fosdem.org/2018/
That should of course read:
At FOSDEM on saturday the 2nd of february 2019, there will be another
graph
On 29.10.2018 12:47, Tomi Valkeinen wrote:
> tc358767 driver sets the connector type always to eDP.
>
> This patch sets the type to DP if there is no panel defined, which
> implies that there's a DP connector on the board.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/tc358767.
On 29.10.2018 12:47, Tomi Valkeinen wrote:
> The H and V syncs of the DP output are always set to active high. This
> patch fixes the syncs by configuring them according to the videomode.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/bridge/tc358767.c | 4 +++-
> 1 file changed, 3 ins
On 29.10.2018 12:46, Tomi Valkeinen wrote:
> PHY_2LANE bit is always set in DP_PHY_CTRL, breaking 1 lane use.
>
> Set PHY_2LANE only when 2 lanes are used.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
___
dri-devel
On 29.10.2018 12:46, Tomi Valkeinen wrote:
> The current driver accepts any videomode with pclk < 154MHz. This is not
> correct, as with 1 lane and/or 1.62Mbps speed not all videomodes can be
> supported.
>
> Add code to reject modes that require more bandwidth that is available.
>
> Signed-off-by:
On 29.10.2018 12:46, Tomi Valkeinen wrote:
> DP1_SRCCTRL register and PHY_2LANE field did not have matching defines.
> Add these.
>
> Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
--
Regards
Andrzej
___
dri-devel mailing list
dri-devel@list
On 29.10.2018 12:46, Tomi Valkeinen wrote:
> tc358767 driver does not set DRM bus_flags, even if it does configures
> the polarity settings into its registers. This means that the DPI source
> can't configure the polarities correctly.
>
> Add sync flags accordingly.
>
> Signed-off-by: Tomi Valkeine
46 matches
Mail list logo
