https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #13 from Michel Dänzer ---
(In reply to lei.pero from comment #7)
> Sure, i will, it's like performace loss, I'm not sure if video would do the
> justice,
Indeed, I'm afraid I can't see much difference, though the DRI2 videos do seem
https://bugs.freedesktop.org/show_bug.cgi?id=99456
--- Comment #2 from Michel Dänzer ---
Any chance you can bisect Mesa with LLVM 3.9?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.
https://bugs.freedesktop.org/show_bug.cgi?id=99456
--- Comment #3 from Michel Dänzer ---
Created attachment 129042
--> https://bugs.freedesktop.org/attachment.cgi?id=129042&action=edit
Backtrace with debugging symbols
--
You are receiving this mail because:
You are the assignee for the bug.__
After warning that the connector list is not empty on device
unregistration (i.e. module unload) also print out which connectors are
still hanging around to aide finding the leak.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_mode_config.c | 7 ++-
1 file changed, 6 insertions(+), 1 de
https://bugs.freedesktop.org/show_bug.cgi?id=96600
Nicolai Hähnle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
On Wed, 18 Jan 2017, Martin Peres wrote:
> On 16/12/16 15:48, Daniel Vetter wrote:
>> On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
>>> The two remaining patches from [1], rebased.
>>>
>>> BR,
>>> Jani.
>>>
>>>
>>> [1]
>>> http://mid.mail-archive.com/1480984058-552-1-git-send-email
On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote:
> Add support for Amlogic Meson DRM driver merged for Linux 4.10.
>
> Signed-off-by: Neil Armstrong
> ---
> tests/util/kms.c | 1 +
> 1 file changed, 1 insertion(+)
Applied, thanks.
Thierry
signature.asc
Description: PGP signatu
https://bugs.freedesktop.org/show_bug.cgi?id=98784
--- Comment #13 from Germano Massullo ---
I have just wrote an e-mail to Croteam support, attaching the URL of this
bugreport. I will let you know about any their reply.
--
You are receiving this mail because:
You are the assignee for the bug._
On Wed, 18 Jan 2017, "Vivi, Rodrigo" wrote:
> On Wed, 2017-01-18 at 10:12 +0200, Jani Nikula wrote:
>> On Tue, 17 Jan 2017, Rodrigo Vivi wrote:
>> > On Mon, Jan 16, 2017 at 2:04 AM, Jani Nikula
>> > wrote:
>> >> On Fri, 13 Jan 2017, Rodrigo Vivi wrote:
>> >>> This and all the remaining patches
https://bugs.freedesktop.org/show_bug.cgi?id=99451
Nicolai Hähnle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Mon, Jan 16, 2017 at 02:53:52PM +, Emil Velikov wrote:
> On 13 January 2017 at 21:11, Nicholas Miell wrote:
> > On 01/13/2017 09:57 AM, Emil Velikov wrote:
> >>
> >> On 13 January 2017 at 11:34, Jan Vesely wrote:
> >>>
> >>> On Thu, 2017-01-12 at 18:16 -0800, Nicholas Miell wrote:
>
>
This patch replaces specific atomic commit function
with atomic helper commit one.
For this, it removes existing atomic commit function
and relevant code specific to Exynos DRM and makes
atomic helper commit to be used instead.
Below are changes for the use of atomic helper commit:
- add atomic_c
Adding back dri-devel@lists.freedesktop.org
On Wed, Jan 18, 2017 at 12:21:23PM +0100, walter harms wrote:
>
>
> Am 18.01.2017 10:02, schrieb Thierry Reding:
> > Allow DRM/KMS devices hosted on USB to be detected by the drmDevice
> > infrastructure.
> >
> > v3:
> > - guard Linux-specific sysfs p
Adding back dri-devel@lists.freedesktop.org
On Wed, Jan 18, 2017 at 04:00:20PM +0100, walter harms wrote:
> Am 18.01.2017 10:02, schrieb Thierry Reding:
[...]
> > diff --git a/xf86drm.c b/xf86drm.c
[...]
> > @@ -3187,11 +3199,55 @@ static int drmParsePciDeviceInfo(int maj, int min,
> > #endif
> >
On Wed, Jan 18, 2017 at 07:38:53AM +1100, Eric Anholt wrote:
> Mark Brown writes:
> > You don't appear to have sent this to any of the DRM maintainers - it
> > does need review from them.
> It was sent to dri-devel. That's us. And the patch already has a r-b
> From DRM on it.
I see. For most
Hi Neil,
ST may use this hardware IP also in other SoC, even that is not true
now, I hope that "st" is a more futur proof name.
Best regards
Yannick Fertré
On 01/16/2017 05:02 PM, Neil Armstrong wrote:
> On 01/16/2017 02:28 PM, Yannick Fertre wrote:
>> The purpose of this set of patches is to
On Thu, Jan 12, 2017 at 12:13:51PM +0100, Arnd Bergmann wrote:
> The tegra DRM driver is almost ok without an MMU, but there
> is one small warning that I get:
>
> drivers/gpu/drm/tegra/gem.c: In function 'tegra_drm_mmap':
> drivers/gpu/drm/tegra/gem.c:508:12: unused variable 'prot'
>
> This mark
On Thu, Jan 19, 2017 at 11:49:56AM +0100, Arnaud Pouliquen wrote:
> I limited diffusion to ASoC, as Daniel Vetter and Takashi Iwai
> discussed the topic here:
> http://www.spinics.net/lists/alsa-devel/msg58114.html
> Seems that is was not a good strategy as it leads to discussions..
> Sorry for th
On Wed, Dec 14, 2016 at 12:04:38AM +0200, Laurent Pinchart wrote:
> Hi Chris,
>
> Thank you for the patch.
>
> On Thursday 08 Dec 2016 08:18:40 Chris Wilson wrote:
> > Some state is coupled into the device lifetime outside of the
> > load/unload timeframe and requires teardown during final unrefe
On Wed, Jan 18, 2017 at 11:05:18PM +0200, Martin Peres wrote:
> On 16/12/16 15:48, Daniel Vetter wrote:
> > On Fri, Dec 16, 2016 at 12:29:05PM +0200, Jani Nikula wrote:
> >> The two remaining patches from [1], rebased.
> >>
> >> BR,
> >> Jani.
> >>
> >>
> >> [1]
> >> http://mid.mail-archive.com/14
Hi Inki,
2017-01-19 Inki Dae :
> This patch replaces specific atomic commit function
> with atomic helper commit one.
>
> For this, it removes existing atomic commit function
> and relevant code specific to Exynos DRM and makes
> atomic helper commit to be used instead.
>
> Below are changes fo
What about Laurent's comment stating that drm_atomic_helper_commit() is
broken at the moment? Shouldn't there be some kind of warning in the
commit message that this patch is only safe to apply once the fixes for
drm_atomic_helper_commit() have landed? I'm already seeing this getting
merged by acci
https://bugs.freedesktop.org/show_bug.cgi?id=99459
Bug ID: 99459
Summary: Performace drop on AMD TONGA(380x) on kernels 4.9 and
4.10RC3
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (A
Hello Joonyoung,
Joonyoung Shim wrote:
> Hi Tobias,
>
> On 01/17/2017 11:24 PM, Tobias Jakobi wrote:
>> Joonyoung Shim wrote:
>>> The size of cmdlist is integer type, so it can be overflowed by cmd and
>>> cmd_buf that has too big size. This patch will fix overflow issue as
>>> checking maximum s
On Wed, 18 Jan 2017, Manasi Navare wrote:
> v2:
> * Add all the other DP Complianec TEST register defs (Jani Nikula)
> Cc: dri-devel@lists.freedesktop.org
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Ville Syrjala
> Signed-off-by: Manasi Navare
> ---
> include/drm/drm_dp_helper.h | 58
> +
On to, 2017-01-19 at 09:05 +, Chris Wilson wrote:
> After warning that the connector list is not empty on device
> unregistration (i.e. module unload) also print out which connectors are
> still hanging around to aide finding the leak.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Joonas Laht
This avoids using the deprecated drm_put_dev() and unload() hook
interfaces in the qxl driver.
Signed-off-by: Gabriel Krisman Bertazi
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Gustavo Padovan
---
drivers/gpu/drm/qxl/qxl_drv.c | 11 +--
drivers/gpu/drm/qxl/qxl_drv.h | 2 --
drivers/gpu/dr
This avoids using the deprecated drm_get_pci_dev() and load() hook
interfaces in the qxl driver.
The only tricky part is to ensure TTM debugfs initialization happens
after the debugfs root node is created, which is done by moving that
code into the debufs_init() hook.
Tested on qemu with igt and
> Please group this declaration together with the other qxl debugfs
> declarations.
Thanks for the review. Just submitted a v3 that adds this
modification. Please, take a look when you have the time.
--
Gabriel Krisman Bertazi
___
dri-devel mailing l
Op 19-01-17 om 10:05 schreef Chris Wilson:
> After warning that the connector list is not empty on device
> unregistration (i.e. module unload) also print out which connectors are
> still hanging around to aide finding the leak.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/drm_mode_con
https://bugs.freedesktop.org/show_bug.cgi?id=99051
Darek Deoniziak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Thursday, January 19, 2017 12:00:58 PM CET Thierry Reding wrote:
> On Thu, Jan 12, 2017 at 12:13:51PM +0100, Arnd Bergmann wrote:
> > The tegra DRM driver is almost ok without an MMU, but there
> > is one small warning that I get:
> >
> > drivers/gpu/drm/tegra/gem.c: In function 'tegra_drm_mmap
On Wed, Jan 18, 2017 at 10:34 AM, Jeff Smith wrote:
> Hello all,
>
> This code is very raw at this point, but wanted to get this out there
> for feedback.
>
> This uses codepaths very close to those used for HDMI audio support.
> The driver currently has this disabled, so I needed to re-enable it.
Hi Dave -
Apparently you haven't pulled my fixes from last week [1], so this one
supersedes and includes that one.
More GVT-g stuff than I'd like at this stage, but then again that's
pretty new and isolated so I'm not too worried.
BR,
Jani.
[1] 877f605pim.fsf@intel.com">http://mid.mail-archive
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #14 from lei.p...@gmail.com ---
(In reply to Michel Dänzer from comment #13)
> (In reply to lei.pero from comment #7)
> > Sure, i will, it's like performace loss, I'm not sure if video would do the
> > justice,
>
> Indeed, I'm afraid
On 01/19/17 16:21, Jose Abreu wrote:
Hi Laurent,
On 18-01-2017 20:49, Laurent Pinchart wrote:
Ideally the bridge mode set operation should be extended to take format and
colorspace information (or another bridge operation should be created for that
purpose, I'm still undecided). As that's qui
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #15 from lei.p...@gmail.com ---
Created attachment 129048
--> https://bugs.freedesktop.org/attachment.cgi?id=129048&action=edit
DRI2_EV1
DRI2 Chromium with EV
--
You are receiving this mail because:
You are the assignee for the bu
On Mon, Jan 16, 2017 at 06:08:21PM +0800, Chris Zhong wrote:
> The dw-mipi-dsi of rk3399 is almost the same as rk3288, the rk3399 has
> additional phy config clock.
>
> Signed-off-by: Chris Zhong
> ---
>
> .../devicetree/bindings/display/rockchip/dw_mipi_dsi_rockchip.txt | 4
> +++-
> 1 fi
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #16 from lei.p...@gmail.com ---
Created attachment 129049
--> https://bugs.freedesktop.org/attachment.cgi?id=129049&action=edit
DRI3_EV1
DRI3 Chromium with EV
--
You are receiving this mail because:
You are the assignee for the bu
On Wed, 18 Jan 2017, Manasi Navare wrote:
> This patch adds support to handle automated DP compliance
> link training test requests. This patch has been tested with
> Unigraf DPR-120 DP Compliance device for testing Link
> Training Compliance.
> After we get a short pulse Compliance test request,
Hi Dave,
A little bigger than usual since it's two weeks worth. Highlights:
- Add support for new smc firmware on some new hainan variants
- add support for SI chips that require special mc firmware
- remove workarounds for issues fixed by new mc firmware
- fix a regression in cursor handling
- v
On 01/16/2017 09:30 PM, Laurent Pinchart wrote:
> Hi Yannick,
>
> Thank you for the patch.
>
> On Monday 16 Jan 2017 14:28:58 Yannick Fertre wrote:
>> Signed-off-by: Yannick Fertre
>> ---
>> .../devicetree/bindings/display/st,ltdc.txt| 57 ++
>> 1 file changed, 57 insertio
From: Shawn Guo
The clock control module (CRM) cannot always provide desired frequency
for all VOU output devices. That's why VOU integrates a few dividers
to further divide the clocks from CRM. Let's add an interface for
configuring these dividers.
Signed-off-by: Shawn Guo
---
drivers/gpu/d
From: Shawn Guo
Although data in struct vou_inf is defined per output device, it doesn't
belong to the device itself but VOU control module. All these data can
just be defined in VOU driver, and output device driver only needs to
invoke VOU driver function with device ID to enable/disable specif
From: Shawn Guo
It adds interlace mode support in VOU TIMING_CTRL and channel control
block, so that VOU driver gets ready to support output device in
interlace mode like TV Encoder.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/zte/zx_vou.c | 53 +--
dr
From: Shawn Guo
The series updates zx_vou driver a bit as the preparation of adding
TVENC output device, and then adds the device driver.
Shawn Guo (5):
drm: zte: add interlace mode support
drm: zte: move struct vou_inf into zx_vou driver
drm: zte: add function to configure vou_ctrl divide
From: Shawn Guo
It adds the TV Encoder driver to support video output in PAL and NTSC
format. The driver uses syscon/regmap interface to configure register
bit sitting in SYSCTRL module for DAC power control.
Signed-off-by: Shawn Guo
---
drivers/gpu/drm/zte/Makefile| 1 +
drivers/gp
From: Shawn Guo
It adds bindings doc for ZTE VOU TV Encoder device.
Signed-off-by: Shawn Guo
---
Documentation/devicetree/bindings/display/zte,vou.txt | 15 +++
1 file changed, 15 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/zte,vou.txt
b/Documentation/dev
On Mon, Jan 16, 2017 at 02:28:58PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre
Changelog?
> ---
> .../devicetree/bindings/display/st,ltdc.txt| 57
> ++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/displa
On Thu, Jan 19, 2017 at 04:16:01PM +, Yannick FERTRE wrote:
> On 01/16/2017 09:30 PM, Laurent Pinchart wrote:
> > Hi Yannick,
> >
> > Thank you for the patch.
> >
> > On Monday 16 Jan 2017 14:28:58 Yannick Fertre wrote:
> >> Signed-off-by: Yannick Fertre
> >> ---
> >> .../devicetree/bindings/
On Mon, Jan 16, 2017 at 02:29:00PM +0100, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre
> ---
> .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7
> +++
> 1 file changed, 7 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/panel/amp
Hi Hans and Jose,
On Thursday 19 Jan 2017 16:30:57 Hans Verkuil wrote:
> On 01/19/17 16:21, Jose Abreu wrote:
> > On 18-01-2017 20:49, Laurent Pinchart wrote:
> >> Ideally the bridge mode set operation should be extended to take format
> >> and colorspace information (or another bridge operation s
Hi Laurent,
On 18-01-2017 20:49, Laurent Pinchart wrote:
>
> Ideally the bridge mode set operation should be extended to take format and
> colorspace information (or another bridge operation should be created for
> that
> purpose, I'm still undecided). As that's quite a big change, I'm fine if
Hi Peter,
On Thursday 19 Jan 2017 10:25:32 Peter Senna Tschudin wrote:
> On Thu, Jan 19, 2017 at 10:17:45AM +0200, Laurent Pinchart wrote:
> > On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote:
> >> On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> >>> On Monday 16 Jan
On Thu, Jan 19, 2017 at 10:17:45AM +0200, Laurent Pinchart wrote:
> Hi Peter,
>
> On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote:
> > On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> > > On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> > >> On Tue, Jan 1
On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> Hi Peter,
>
> On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> > On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> > > On Saturday 07 Jan 2017 01:29:52 Peter Senna Tschudin wrote:
> > >> On 04 January
Hi Neil,
On 18-01-2017 11:20, Neil Armstrong wrote:
>
> It's the idea we discussed with Laurent.
> Keeping the Synopsys PHY code inside the dw-hdmi driver would be simpler.
>
> But don't you think adding a proper "ops" structure apart from the plat_data
> should be necessary ?
>
> Neil
>
An "ops
On 01/19/2017 11:29 AM, Mark Brown wrote:
> On Wed, Jan 18, 2017 at 07:38:53AM +1100, Eric Anholt wrote:
>> Mark Brown writes:
>
>>> You don't appear to have sent this to any of the DRM
>>> maintainers - it does need review from them.
>
>> It was sent to dri-devel. That's us. And the patch a
Hi Peter,
On Thursday 19 Jan 2017 09:12:14 Peter Senna Tschudin wrote:
> On Wed, Jan 18, 2017 at 11:10:58PM +0200, Laurent Pinchart wrote:
> > On Monday 16 Jan 2017 09:37:11 Peter Senna Tschudin wrote:
> >> On Tue, Jan 10, 2017 at 11:04:58PM +0200, Laurent Pinchart wrote:
> >>> On Saturday 07 Jan
Am Freitag, den 20.01.2017, 00:24 +0800 schrieb Shawn Guo:
> From: Shawn Guo
>
> It adds bindings doc for ZTE VOU TV Encoder device.
>
> Signed-off-by: Shawn Guo
> ---
> Documentation/devicetree/bindings/display/zte,vou.txt | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --g
https://bugs.freedesktop.org/show_bug.cgi?id=98975
Samuel Pitoiset changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99450
Samuel Pitoiset changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=99450
--- Comment #2 from hugo.pos...@protonmail.com ---
(In reply to Samuel Pitoiset from comment #1)
> Should be fixed by e490b7812cae778c61004971d86dc8299b6cd240.
Thank's for this patch. Can't test it but I hope so ;)
--
You are receiving this mai
Hi Gabriel,
2017-01-19 Gabriel Krisman Bertazi :
> This avoids using the deprecated drm_put_dev() and unload() hook
> interfaces in the qxl driver.
>
> Signed-off-by: Gabriel Krisman Bertazi
> Cc: Dave Airlie
> Cc: Daniel Vetter
> Cc: Gustavo Padovan
> ---
> drivers/gpu/drm/qxl/qxl_drv.c |
https://bugs.freedesktop.org/show_bug.cgi?id=99456
--- Comment #4 from Clément Guérin ---
I did some bisecting yesterday, didn't have to finish but I'm really close.
I'll update later today.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=99456
--- Comment #5 from Clément Guérin ---
bf75ef3f9201e11bb08a4d03dab20d5ff86f1ebc is the first bad commit
commit bf75ef3f9201e11bb08a4d03dab20d5ff86f1ebc
Author: Marek Olšák
Date: Tue Nov 15 21:15:55 2016 +0100
radeonsi: remove all varyings
Hi folks,
there seems to be an issue on 32 bit kernels which makes graphics
output look all messed up under X when using the amdgpu drm kernel
driver.
In fact, the same issue was present at some time in 2015 using the
radeon driver too, but it has been fixed a long time ago, as can be
seen here:
On 01/07, Archit Taneja wrote:
> +
> +static struct clk *pll_14nm_postdiv_register(struct dsi_pll_14nm *pll_14nm,
> + const char *name,
> + const char *parent_name,
> + unsigne
Hi Chris,
On Thursday 19 Jan 2017 11:20:37 Chris Wilson wrote:
> On Wed, Dec 14, 2016 at 12:04:38AM +0200, Laurent Pinchart wrote:
> > On Thursday 08 Dec 2016 08:18:40 Chris Wilson wrote:
> >> Some state is coupled into the device lifetime outside of the
> >> load/unload timeframe and requires tea
Just a friendly reminder that now would be a good time to update the
wiki page for GSoC/EVoC ideas:
https://www.x.org/wiki/SummerOfCodeIdeas/
There are currently still some stale ideas there (and probably plenty
of missing good ideas).
Also, I've added a "Potential Mentors" section. Please ad
2017년 01월 19일 20:53에 Gustavo Padovan 이(가) 쓴 글:
> Hi Inki,
>
> 2017-01-19 Inki Dae :
>
>> This patch replaces specific atomic commit function
>> with atomic helper commit one.
>>
>> For this, it removes existing atomic commit function
>> and relevant code specific to Exynos DRM and makes
>> atom
https://bugs.freedesktop.org/show_bug.cgi?id=99456
--- Comment #6 from Marek Olšák ---
Does this commit fix it?
https://cgit.freedesktop.org/mesa/mesa/commit/?id=35cd7551a443477147293e562d8c1adfbe00dea9
--
You are receiving this mail because:
You are the assignee for the bug.___
Hi Tobias,
On 01/19/2017 10:16 PM, Tobias Jakobi wrote:
> Hello Joonyoung,
>
> Joonyoung Shim wrote:
>> Hi Tobias,
>>
>> On 01/17/2017 11:24 PM, Tobias Jakobi wrote:
>>> Joonyoung Shim wrote:
The size of cmdlist is integer type, so it can be overflowed by cmd and
cmd_buf that has too bi
https://bugs.freedesktop.org/show_bug.cgi?id=99456
--- Comment #7 from Clément Guérin ---
Hi Marek,
No, the mesa build I was using when hitting the bug already included this
commit.
I also tried with e0674e740bf8 (current master~1) and I get a crash too.
--
You are receiving this mail because
https://bugs.freedesktop.org/show_bug.cgi?id=99459
--- Comment #1 from Michel Dänzer ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
https://bugzilla.kernel.org/show_bug.cgi?id=192921
stevengrusp...@gmail.com changed:
What|Removed |Added
Regression|No |Yes
--
You are receiving this
https://bugzilla.kernel.org/show_bug.cgi?id=192921
Bug ID: 192921
Summary: Low frame rates and unrecognized monitor after kernel
upgrade
Product: Drivers
Version: 2.5
Kernel Version: 4.10.0
Hardware: x86-64
On 20/01/17 04:35 AM, Nils Holland wrote:
> Hi folks,
>
> there seems to be an issue on 32 bit kernels which makes graphics
> output look all messed up under X when using the amdgpu drm kernel
> driver.
>
> In fact, the same issue was present at some time in 2015 using the
> radeon driver too, bu
https://bugzilla.kernel.org/show_bug.cgi?id=192921
--- Comment #1 from Michel Dänzer ---
Please attach the dmesg output.
Can you bisect?
What does xrandr say about the mode, and what framerate does e.g. glxgears
report?
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=192921
--- Comment #2 from Michel Dänzer ---
Please attach the Xorg log file and output of glxinfo as well.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mai
https://bugzilla.kernel.org/show_bug.cgi?id=192921
--- Comment #3 from stevengrusp...@gmail.com ---
Created attachment 252491
--> https://bugzilla.kernel.org/attachment.cgi?id=252491&action=edit
Dmesg Output
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=192921
--- Comment #4 from stevengrusp...@gmail.com ---
xrandr
[CODE]
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 2560 x 1440, current 2560 x 1440, maximum 2560 x 1440
default connected primary 2560x1440+0+0 0mm x 0mm
2560
https://bugzilla.kernel.org/show_bug.cgi?id=192921
--- Comment #5 from stevengrusp...@gmail.com ---
Created attachment 252501
--> https://bugzilla.kernel.org/attachment.cgi?id=252501&action=edit
Glxinfo
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugzilla.kernel.org/show_bug.cgi?id=192921
--- Comment #6 from Michel Dänzer ---
dmesg shows that the amdgpu driver fails to initialize due to missing
microcode:
amdgpu :01:00.0: Direct firmware load for amdgpu/tonga_k_smc.bin failed
with error -2
--
You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=99418
--- Comment #17 from Michel Dänzer ---
(In reply to lei.pero from comment #14)
> It does happen on modesetting driver regardless of DRI version, strange.
The modesetting driver doesn't allow disabling DRI3 on the server side. You can
always disa
Hi Tobias,
2017년 01월 19일 21:49에 Tobias Jakobi 이(가) 쓴 글:
> What about Laurent's comment stating that drm_atomic_helper_commit() is
> broken at the moment? Shouldn't there be some kind of warning in the
> commit message that this patch is only safe to apply once the fixes for
> drm_atomic_helper_com
The intel_dp_autotest_video_pattern() function gets invoked through the
compliance test handler on a HPD short pulse if the test type is
set to DP_TEST_VIDEO_PATTERN. This performs the DPCD registers
reads to read the requested test pattern, video pattern resolution,
frame rate and bits per color v
This patch adds support to handle automated DP compliance
link training test requests. This patch has been tested with
Unigraf DPR-120 DP Compliance device for testing Link
Training Compliance.
After we get a short pulse Compliance test request, test
request values are read and hotplug uevent is se
This series addresses review comments from the previous series:
https://patchwork.freedesktop.org/series/18150/
Apart from addressing review comments, it also adds a fix for
CRC mismatch errors in Compliance tests 4.4.1.1 - 4.4.1.3
DP 1.2 compliance testing can be acheived using DPR-120's CTS sui
This patch addresses a few issues from the original patch for
DP Compliance EDID test support submitted by
Todd Previte
Video Mode requested in the EDID test handler for the EDID Read
test (CTS 4.2.2.3) should be set to PREFERRED as per the CTS spec.
v2:
* Added read debugfs data from test_data.e
v3:
* Fix the conventions in bit definitions (Jani Nikula)
v2:
* Add all the other DP Complianec TEST register defs (Jani Nikula)
Cc: dri-devel@lists.freedesktop.org
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjala
Signed-off-by: Manasi Navare
---
include/drm/drm_dp_helper.h | 64 ++
In case of interlace mode irq is generated for odd and even fields, but
vblank should be signaled only for the last emitted field.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 7 +++
include/video/exynos5433_decon.h | 1 +
2 files changed, 8 i
297MHz is used by Ultra HD modes.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/gpu/drm/exynos/exynos_hdmi.c
index 5ed8b1e..bef8965 100644
--- a/drivers/gpu/drm/ex
VSI infoframe registers address space is non-contiguous, so infoframe write
should be split into two chunks.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers
Current settings for 27MHz and 27.027MHz do not work. Use the settings from
vendor code instead.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
b/drivers/
In some platforms there is attached another device to the end of HDMI.
The patch adds support for it.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 56 +---
1 file changed, 46 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/e
Ultra HD modes requires clock ticking at increased rate.
Signed-off-by: Andrzej Hajda
---
arch/arm64/boot/dts/exynos/exynos5433.dtsi | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/boot/dts/exynos/exynos5433.dtsi
b/arch/arm64/boot/dts/exynos/exynos5433.dtsi
index f120d99..314d
Some registers should be programmed differently in interlace mode.
Additionally IP does not signal stop state properly in interlaced
mode, so warning has been removed.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 45 +++
include/video/e
Hi Inki,
This patchset adds support for UltraHD and intrelace modes on DECON and HDMI
drivers of Exynos5433 chipset. To fully support it on TM2(e) platforms MHL
patches are alse required which will be posted in separate patchset.
Krzysztof, DTS patch do not depend on the previous patches, so ther
https://bugs.freedesktop.org/show_bug.cgi?id=98619
--- Comment #5 from Brandon Egbert ---
Changing shadows from 'All shadows' to 'Directional Only' seems to correct the
issue in XCOM2 at least. Be nice to be able to have shadows working though.
--
You are receiving this mail because:
You are t
1 - 100 of 127 matches
Mail list logo
