On Wed, Feb 08, 2017 at 10:38:07PM -0800, Dhinakaran Pandiyan wrote:
> +#define for_each_private_obj(__state, obj_funcs, obj, obj_state, __i,
> __funcs) \
> + for ((__i) = 0; \
> + (__i) < (__state)->num_private_objs &&
On Wed, Feb 08, 2017 at 10:49:57AM -0500, Sean Paul wrote:
> On Tue, Feb 07, 2017 at 05:16:12PM +0800, Shawn Guo wrote:
> > From: Shawn Guo
> >
> > The vblank is mostly CRTC specific and implemented as part of CRTC
> > driver. The first patch adds 3 vblank core<->driver hooks into struct
> > drm
Hi Dave,
drm-misc-next-fixes-2017-02-09:
Just 3 bugfixes for 4.11 merge window:
- fbdev module unload oops fix from Chris
- patch from Dan that look really dangers, better safe than sorry
Cheers, Daniel
The following changes since commit 4eaa39c63caf535dc1a8cc43b9a8677a100c09e1:
Merge branc
Hi Dave -
Hopefully final fixes for v4.10, about half of them stable material.
BR,
Jani.
The following changes since commit d5adbfcd5f7bcc6fa58a41c5c5ada0e5c826ce2c:
Linux 4.10-rc7 (2017-02-05 15:10:58 -0800)
are available in the git repository at:
git://anongit.freedesktop.org/git/drm-i
Hi Chris, Dave,
Recently, I started seeing ca. 2 minute delays during boot-up on Renesas
R-Car Gen2 boards.
It turned out the DRM range manager selftests started taking quite some time.
With debug output, I get:
[2.310472] drm_mm: Testing DRM range manger (struct drm_mm), with
random_seed=0x
On Thu, Feb 09, 2017 at 10:58:38AM +0100, Geert Uytterhoeven wrote:
> Hi Chris, Dave,
>
> Recently, I started seeing ca. 2 minute delays during boot-up on Renesas
> R-Car Gen2 boards.
>
> It turned out the DRM range manager selftests started taking quite some time.
> With debug output, I get:
>
https://bugs.freedesktop.org/show_bug.cgi?id=98924
--- Comment #2 from Stefano Cipriani ---
Created attachment 129431
--> https://bugs.freedesktop.org/attachment.cgi?id=129431&action=edit
dmesg when glxgears runs once
Small update, on drm-next-4.11-wip sometimes glxgears starts correctly the
f
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #22 from Gregor Münch ---
(In reply to siyia from comment #21)
>
> If you have the blood dlc,can you reproduce the bug Gregor Münch?
I dont have the game at all. I assume you have to have this DLC to actually see
this checkbox.
The
https://bugs.freedesktop.org/show_bug.cgi?id=99484
--- Comment #3 from Timothy Arceri ---
The game requests a compatibility profile but its using OpenGL features from
3.1+. Overriding the version doesn't fix the issue, so may be related, may not.
--
You are receiving this mail because:
You are
On Wed, 2017-02-08 at 10:47 -0200, Fabio Estevam wrote:
> Commit deb65870b5d9d ("drm/imx: imx-tve: check the value returned by
> regulator_set_voltage()") exposes the following probe issue:
>
> 63ff.tve supply dac not found, using dummy regulator
> imx-drm display-subsystem: failed to bind 63f
Op 26-01-17 om 19:29 schreef Ville Syrjälä:
> On Mon, Jan 09, 2017 at 06:06:56PM +0100, Maarten Lankhorst wrote:
>> This will allow i915 to perform a wait on pending modeset using the
>> same code.
> I don't like commit messages that refer to the subject like this. I
> can't even see the subject wh
https://bugs.freedesktop.org/show_bug.cgi?id=98869
cosiek...@o2.pl changed:
What|Removed |Added
Severity|normal |major
--
You are receiving this mail b
Op 26-01-17 om 19:31 schreef Ville Syrjälä:
> On Mon, Jan 09, 2017 at 06:06:57PM +0100, Maarten Lankhorst wrote:
>> We're protected by the connection_mutex lock against blocking modesets,
>> but nonblocking modesets are performed without any locking. This is
>> causing WARN in drm_wait_for_vblank a
https://bugzilla.kernel.org/show_bug.cgi?id=193981
fin4...@hotmail.com changed:
What|Removed |Added
CC||fin4...@hotmail.com
--- Comment #1
On Thu, 09 Feb 2017, sourab gupta wrote:
> On Tue, 2016-12-20 at 01:44 -0800, Jani Nikula wrote:
>> On Tue, 20 Dec 2016, Laurent Pinchart
>> wrote:
>> > Hi Swati,
>> >
>> > On Monday 19 Dec 2016 16:12:22 swati.dhin...@intel.com wrote:
>> >> From: Swati Dhingra
>> >>
>> >> Currently, we don't ha
On Thu, 09 Feb 2017, Lyude wrote:
> This adds a file in i915's debugfs directory that allows userspace to
> manually control HPD storm detection. This is mainly for hotplugging
> tests, where we might want to test HPD storm functionality or disable
> storm detection to speed up hotplugging tests w
https://bugzilla.kernel.org/show_bug.cgi?id=193981
--- Comment #2 from Fabian ---
Is there some kind of live-image? I just can not switch to another distro,
since I need to work with this computer.
> Are you sure it is the gpu fan?
Yep. I can just write "0" to /sys/class/hwmon/hwmon2/pwm1 and i
On 02/09/2017 03:57 PM, Andrzej Hajda wrote:
On 09.02.2017 02:26, Hoegeun Kwon wrote:
The dsi + panel is a parental relationship, so OF grpah is not needed.
Therefore, the current dsi_parse_dt function will throw an error,
because there is no linked OF graph for case such as fimd + dsi +
panel
https://bugzilla.kernel.org/show_bug.cgi?id=193981
--- Comment #3 from Fabian ---
Linux 4.4.47 is quiet. So it has to be somewhere in between 4.5 - 4.8. Wasnt
there a fan/hwmon related work in 4.6? or .7?
4.10RC7 has no fix for this. Mesa/Xorg seems also not related here.
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=193981
--- Comment #4 from Fabian ---
Also maybe not related, but according to sapphire, on OS start, the fan will
rotate for a short time (short like 0.5s) at a higher speed, to remove some
dust.
Maybe the linux-hwmon taked this dust-removal speed as
Op 26-01-17 om 19:39 schreef Sinclair Yeh:
> On Thu, Jan 26, 2017 at 10:55:51AM +0100, Maarten Lankhorst wrote:
>> Op 25-01-17 om 19:05 schreef Sinclair Yeh:
>>> On Wed, Jan 25, 2017 at 09:36:36AM +0100, Maarten Lankhorst wrote:
Op 25-01-17 om 09:09 schreef Thomas Hellstrom:
> On 01/25/201
On Thu, Feb 09, 2017 at 12:27:12PM +0100, Maarten Lankhorst wrote:
> Op 26-01-17 om 19:31 schreef Ville Syrjälä:
> > On Mon, Jan 09, 2017 at 06:06:57PM +0100, Maarten Lankhorst wrote:
> >> We're protected by the connection_mutex lock against blocking modesets,
> >> but nonblocking modesets are perf
Op 09-02-17 om 13:34 schreef Ville Syrjälä:
> On Thu, Feb 09, 2017 at 12:27:12PM +0100, Maarten Lankhorst wrote:
>> Op 26-01-17 om 19:31 schreef Ville Syrjälä:
>>> On Mon, Jan 09, 2017 at 06:06:57PM +0100, Maarten Lankhorst wrote:
We're protected by the connection_mutex lock against blocking m
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #73 from Clemens Eisserer ---
just to be curious, does it actually map the buffer with the READ flag?
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #23 from siyia ---
yes i do lol sorry for not checking that
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.
The Sitronix ST7789V is an LCD panel controller, controlled over SPI, that
can drive 18-bits 240x320 LCD displays.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/display/panel/sitronix,st7789v.txt | 37
+
1 file changed, 37 insertions(+),
The Sitronix ST7789v controller is used to drive 240x320 LCD panels through
various interfaces, including SPI and RGB/Parallel.
The current driver is configuring it for the latter. Support for tinyDRM
can always be added later.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/panel/Kconfig
Hi,
Here is an attempt at supporting the ST7789V LCD controller from Sitronix.
It is controlled through an SPI bus, with a twist, since each byte sent
must be prefixed by a bit, which needs an 9-bits-per-word SPI controller,
which is quite rare. Else, you would need to bitbang it.
Let me know wh
https://bugs.freedesktop.org/show_bug.cgi?id=99542
--- Comment #6 from John ---
Same here on a 280x with mpv 0.23 and mesa-git & llvm-svn from yesterday (it's
been like this for maybe 2 weeks or 3).
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugzilla.kernel.org/show_bug.cgi?id=193981
--- Comment #5 from fin4...@hotmail.com ---
(In reply to Fabian from comment #2)
> Is there some kind of live-image? I just can not switch to another distro,
> since I need to work with this computer.
No live images and for example today adg5f 4.
https://bugs.freedesktop.org/show_bug.cgi?id=99718
--- Comment #1 from Alex Deucher ---
Does the firmware here help?
https://people.freedesktop.org/~agd5f/radeon_ucode/polaris/
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=99476
Alex Deucher changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugs.freedesktop.org/show_bug.cgi?id=99718
Alex Deucher changed:
What|Removed |Added
See Also||https://bugs.freedesktop.or
https://bugzilla.kernel.org/show_bug.cgi?id=193981
Alex Deucher changed:
What|Removed |Added
CC||alexdeuc...@gmail.com
--- Comment #6 from
On Wed, 08 Feb 2017, Thierry Reding wrote:
> This series introduces DRM reference counting APIs that are consistent
> with other reference counting APIs in the kernel. They are also much
> shorter. Compatibility aliases are added to keep existing code working
> and will stay in place until all use
https://bugzilla.kernel.org/show_bug.cgi?id=193981
--- Comment #7 from fin4...@hotmail.com ---
(In reply to fin4478 from comment #5)
>
> Burn Debian netinstaller to a cdrw or usb memory:
> http://cdimage.debian.org/cdimage/stretch_di_alpha7/amd64/iso-cd/
Link above is old, should be:
https://ww
On Wed, 04 Jan 2017, Daniel Vetter wrote:
> On Wed, Dec 21, 2016 at 12:08:45PM +0100, Maarten Lankhorst wrote:
>> Op 21-12-16 om 11:36 schreef Chris Wilson:
>> > On Wed, Dec 21, 2016 at 11:23:30AM +0100, Daniel Vetter wrote:
>> >> When writing the generic nonblocking commit code I assumed that
>>
I've verified that it doesn't break our existing code, but I'm in the process
of rebasing my atomic enabling patch series onto drm-next along with this. I
should be able to get this done by tomorrow morning.
From: Maarten Lankhorst
Sent: Thursday, Februa
Hi,
I was working on a few patches adding fields to struct malidp_crtc_state and
found myself writing memcpy multiple times in the ->atomic_duplicate_state
hook because I wanted to avoid copying the drm_crtc_state twice
(__drm_atomic_helper_crtc_duplicate_state copies it already). I figured this
a
https://bugs.freedesktop.org/show_bug.cgi?id=99718
--- Comment #2 from Mathieu Belanger ---
Yes, Seam to be fine with these. Errors are still in dmesg but MCLK go up to
2000 by hitself.
--
You are receiving this mail because:
You are the assignee for the bug.
Device frequency scaling is implemented through devfreq in the kernel,
which requires CONFIG_PM_OPP.
Let's select it.
Signed-off-by: Maxime Ripard
---
arch/arm/mach-sunxi/Kconfig | 1 +
1 file changed, 1 insertion(+), 0 deletions(-)
diff --git a/arch/arm/mach-sunxi/Kconfig b/arch/arm/mach-sunx
The reserved memory bindings allow us to specify which memory areas our
buffers can be allocated from.
Let's use it.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4
1 file changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/d
Hi,
This serie is building on the recently merged bindings for the ARM Mali
Utgard GPU.
The two features that are supported with this serie are DVFS and the fbdev
support. The first one uses devfreq and is pretty standard, the only
addition being the generic OPP mechanism we have, plus some DT an
The memory buffers might need to be allocated and shared from both the
scanout and the GPU.
Create a memory region reserved for their own usage so that each can
allocate from it, and get the informations on the region that is going to
be used (size and offset).
Signed-off-by: Maxime Ripard
---
The Mali clock rate was improperly assumed to be 408MHz, while it was
really 384Mhz, 408MHz being the "extreme" frequency, and definitely not
stable.
Switch for the stable, correct frequency for the GPU.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a23-a33.dtsi | 2 +-
1 file change
The Mali GPU in the A33 has various operating frequencies used in the
Allwinner BSP.
Add them to our DT.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun8i-a33.dtsi | 17 +
1 file changed, 17 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/sun8i-a33.dtsi b/ar
The operating-points-v2 binding gives a way to provide the OPP of the GPU.
Let's use it.
Signed-off-by: Maxime Ripard
---
Documentation/devicetree/bindings/gpu/arm,mali-utgard.txt | 4
1 file changed, 4 insertions(+), 0 deletions(-)
diff --git a/Documentation/devicetree/bindings/gpu/arm,ma
Allow to provide an optional memory region to allocate from for our DRM
driver.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_drv.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_drv.c
b/drivers/gpu/drm/sun4i/s
Modules might want to check their CMA pool size and address for debugging
and / or have additional checks.
The obvious way to do this would be through dev_get_cma_area and
cma_get_base and cma_get_size, that are currently not exported, which
results in a build failure.
Export them to prevent such
On Thu, Feb 09, 2017 at 03:41:41PM +, Mihail Atanassov wrote:
> Hi,
>
> I was working on a few patches adding fields to struct malidp_crtc_state and
> found myself writing memcpy multiple times in the ->atomic_duplicate_state
> hook because I wanted to avoid copying the drm_crtc_state twice
>
On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
> From: Stefan Christ
>
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer emulation driver. Legacy framebuffer users like non kms/drm
> based OpenGL(ES)/EGL implementations may require the ioctl to
>
On Thu, Feb 02, 2017 at 11:31:56AM +0100, Maxime Ripard wrote:
> From: Xinliang Liu
>
> This patch add a config to support to create multi buffer for cma fbdev.
> Such as double buffer and triple buffer.
>
> Cma fbdev is convient to add a legency fbdev. And still many Android
> devices use fbdev
On Wed, Feb 08, 2017 at 02:28:14PM -0500, Sean Paul wrote:
> On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > For consistency with other reference counting APIs in the kernel, add
> > drm_mode_object_get() and drm_mode_object_put() to reference coun
On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
> On Wed, 08 Feb 2017, Thierry Reding wrote:
> > This series introduces DRM reference counting APIs that are consistent
> > with other reference counting APIs in the kernel. They are also much
> > shorter. Compatibility aliases are added
https://bugs.freedesktop.org/show_bug.cgi?id=99476
--- Comment #1 from Alex Deucher ---
Does the firmware here help?
https://people.freedesktop.org/~agd5f/radeon_ucode/polaris/
--
You are receiving this mail because:
You are the assignee for the bug._
On Wed, Feb 08, 2017 at 12:47:01PM -0800, Eric Anholt wrote:
> Unlike the other encoders in the driver, I've also dropped the debug
> dump function. There's only really one register to this device, and
> we have the debugfs reg entry still.
>
> Signed-off-by: Eric Anholt
Yeah, dmesg spew by def
Assuming a derived struct of the form:
struct foo_bar_state
{
struct drm_bar_state bar_state;
struct foo_private priv;
struct foo_private2 *priv2;
};
memcpy priv and priv2 to the new instance of foo_bar_state. The
intention is to use this macro in ->atomic_duplicate_state
On Thu, Feb 09, 2017 at 05:57:04PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2017 at 03:41:41PM +, Mihail Atanassov wrote:
> > Hi,
> >
> > I was working on a few patches adding fields to struct malidp_crtc_state and
> > found myself writing memcpy multiple times in the ->atomic_duplicate_s
On Thu, Feb 09, 2017 at 04:39:29PM +0200, Jani Nikula wrote:
> On Wed, 04 Jan 2017, Daniel Vetter wrote:
> > On Wed, Dec 21, 2016 at 12:08:45PM +0100, Maarten Lankhorst wrote:
> >> Op 21-12-16 om 11:36 schreef Chris Wilson:
> >> > On Wed, Dec 21, 2016 at 11:23:30AM +0100, Daniel Vetter wrote:
> >>
On Thu, Feb 09, 2017 at 03:41:42PM +, Mihail Atanassov wrote:
> Assuming a derived struct of the form:
>
> struct foo_bar_state
> {
> struct drm_bar_state bar_state;
> struct foo_private priv;
> struct foo_private2 *priv2;
> };
>
> memcpy priv and priv2 to the new instance o
Hi,
On 9 February 2017 at 17:01, Daniel Vetter wrote:
> On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
>> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned
>> long arg)
>> +{
>> + struct drm_fb_helper *fb_helper = info->par;
>> + struct drm_device
On Thu, Feb 09, 2017 at 03:41:42PM +, Mihail Atanassov wrote:
> Assuming a derived struct of the form:
>
> struct foo_bar_state
> {
> struct drm_bar_state bar_state;
> struct foo_private priv;
> struct foo_private2 *priv2;
> };
>
> memcpy priv and priv2 to the new instance o
On Thu, 09 Feb 2017, Daniel Vetter wrote:
> On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
>> On Wed, 08 Feb 2017, Thierry Reding wrote:
>> > This series introduces DRM reference counting APIs that are consistent
>> > with other reference counting APIs in the kernel. They are also m
If a CMA allocation failed, the partially constructed BO would be
unreferenced through the normal path, and we might choose to put it in
the BO cache. If we then reused it before it expired from the cache,
the kernel would OOPS.
Signed-off-by: Eric Anholt
Fixes: c826a6e10644 ("drm/vc4: Add a BO
On Thu, Feb 09, 2017 at 05:38:26PM +, Daniel Stone wrote:
> Hi,
>
> On 9 February 2017 at 17:01, Daniel Vetter wrote:
> > On Thu, Feb 02, 2017 at 11:31:57AM +0100, Maxime Ripard wrote:
> >> +int drm_fb_helper_ioctl(struct fb_info *info, unsigned int cmd, unsigned
> >> long arg)
> >> +{
> >>
On Thu, Feb 09, 2017 at 07:39:33PM +0200, Jani Nikula wrote:
> On Thu, 09 Feb 2017, Daniel Vetter wrote:
> > On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
> >> On Wed, 08 Feb 2017, Thierry Reding wrote:
> >> > This series introduces DRM reference counting APIs that are consistent
>
Hi Dave,
Some additional fixes for 4.11. Delayed a bit due to Chinese New Year.
Highlights:
- Powerplay fixes
- VCE and UVD powergating fixes
- Clean up amdgpu SI gfx code to match CI and VI
- Misc bug fixes
The following changes since commit 18566acac18f5784347bc5fe636a26897d1c963b:
Merge b
On Thu, Feb 09, 2017 at 08:07:41PM +0100, Daniel Vetter wrote:
> On Thu, Feb 09, 2017 at 07:39:33PM +0200, Jani Nikula wrote:
> > On Thu, 09 Feb 2017, Daniel Vetter wrote:
> > > On Thu, Feb 09, 2017 at 04:10:12PM +0200, Jani Nikula wrote:
> > >> On Wed, 08 Feb 2017, Thierry Reding wrote:
> > >> >
On Thu, Feb 09, 2017 at 06:08:10PM +0100, Daniel Vetter wrote:
> On Wed, Feb 08, 2017 at 02:28:14PM -0500, Sean Paul wrote:
> > On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > For consistency with other reference counting APIs in the kernel,
https://bugzilla.kernel.org/show_bug.cgi?id=194533
Bug ID: 194533
Summary: Invalid PCI ROM header signature: expecting 0xaa55,
got 0x9125
Product: Drivers
Version: 2.5
Kernel Version: 4.9.8
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=194533
nuc...@hotmail.com changed:
What|Removed |Added
CC||nuc...@hotmail.com
Hardwar
https://bugzilla.kernel.org/show_bug.cgi?id=194533
--- Comment #1 from nuc...@hotmail.com ---
Created attachment 254693
--> https://bugzilla.kernel.org/attachment.cgi?id=254693&action=edit
lspci -vv
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #24 from Samuel Pitoiset ---
I do have the blood dlc now. Unfortunately, after trying few minutes I can't
reproduce the issue with latest mesa/LLVM. Maybe it's on my side but I don't
really have much time to investigate into that issu
https://bugs.freedesktop.org/show_bug.cgi?id=99450
--- Comment #5 from Samuel Pitoiset ---
Okay, you hit a second issue that should be definitely fixed in mesa 17. I
confirm the visual glitches with 13.0.4, but not with latest mesa/llvm.
Fwiw, the commit previously mentionned should prevent VM f
On 9 February 2017 at 20:41, Thierry Reding wrote:
> On Thu, Feb 09, 2017 at 06:08:10PM +0100, Daniel Vetter wrote:
>> On Wed, Feb 08, 2017 at 02:28:14PM -0500, Sean Paul wrote:
>> > On Wed, Feb 08, 2017 at 07:24:04PM +0100, Thierry Reding wrote:
>> > > From: Thierry Reding
>> > >
>> > > For cons
https://bugs.freedesktop.org/show_bug.cgi?id=98869
Grazvydas Ignotas changed:
What|Removed |Added
CC||nota...@gmail.com
--- Comment #19 fr
https://bugs.freedesktop.org/show_bug.cgi?id=99747
APoliTech changed:
What|Removed |Added
Component|Other |Drivers/Gallium/radeonsi
QA Contact|
https://bugs.freedesktop.org/show_bug.cgi?id=99747
--- Comment #1 from APoliTech ---
The links to the launchpad.net reports
https://bugs.launchpad.net/ubuntu-mate/+bug/1663379
https://bugs.launchpad.net/ubuntu-mate/+bug/1663391
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #74 from i...@posteo.net ---
Do you need more testing?
Has anyone yet reported that to psyonix?
--
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=97879
--- Comment #75 from Michel Dänzer ---
(In reply to Clemens Eisserer from comment #73)
> just to be curious, does it actually map the buffer with the READ flag?
According to Timothee and the apitrace it does, so
https://patchwork.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=95306
--- Comment #56 from Jaime Rodrigo ---
I tried 4.10 RC7, and I could successfully login with this kernel. But after 5
mins of using it, I had a blackout again :/ . Guess I'll stick to RC5 for a
while
--
You are receiving this mail because:
You
https://bugs.freedesktop.org/show_bug.cgi?id=99748
Bug ID: 99748
Summary: [radeonsi] Civ6 Assert in LLVM SIMachineScheduler.cpp
with R600_DEBUG=sisched
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS:
https://bugs.freedesktop.org/show_bug.cgi?id=99747
--- Comment #2 from Michel Dänzer ---
What does
apt-cache policy libllvm3.9
say?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.
Hi Linus,
This should be the final set of drm fixes for 4.10, one vmwgfx boot
fix, one vc4 fix, and a few i915 fixes.
Hopefully haven't missed anything.
Dave.
The following changes since commit d5adbfcd5f7bcc6fa58a41c5c5ada0e5c826ce2c:
Linux 4.10-rc7 (2017-02-05 15:10:58 -0800)
are availabl
https://bugs.freedesktop.org/show_bug.cgi?id=99744
Michel Dänzer changed:
What|Removed |Added
Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop
The total vcpi time slots is always 63 and does not depend on the link BW,
remove total_slots from MST topology manager struct. The next change is to
remove total_pbn which is hardcoded to 2560. The total PBN that the
topology manager allocates from depends on the link rate and is not a
constant. S
On Tue, 2016-12-20 at 01:44 -0800, Jani Nikula wrote:
> On Tue, 20 Dec 2016, Laurent Pinchart
> wrote:
> > Hi Swati,
> >
> > On Monday 19 Dec 2016 16:12:22 swati.dhin...@intel.com wrote:
> >> From: Swati Dhingra
> >>
> >> Currently, we don't have a stable ABI which can be used for the purpose of
drm_dp_mst_allocate_vcpi() apart from setting up the vcpi structure,
also finds if there are enough slots available. This check is a duplicate
of that implemented in drm_dp_mst_find_vcpi_slots(). Let's move this check
out and reuse the existing drm_dp_mst_find_vcpi_slots() function to check
if ther
On Thu, 2017-02-09 at 08:08 +, Chris Wilson wrote:
> On Wed, Feb 08, 2017 at 10:38:07PM -0800, Dhinakaran Pandiyan wrote:
> > +#define for_each_private_obj(__state, obj_funcs, obj, obj_state, __i,
> > __funcs) \
> > + for ((__i) = 0; \
> >
The OF graph API leaves too much of the graph walking to clients when
in many cases the driver doesn't care about accessing the port or
endpoint nodes. The drivers typically just want the device connected via
a particular graph connection. of_graph_get_remote_node provides this
functionality.
Sign
The OF graph is not needed because the panel is a child of dsi. So
Remove the ports node and move burst and esc clock frequency
properties to the parent (DSI node).
Signed-off-by: Hoegeun Kwon
---
arch/arm/boot/dts/exynos3250-rinato.dts | 23 ++-
1 file changed, 2 insertions(
Daniel Vetter wrote:
Latest report just says that the revert isn't helping either. I suspect
the report is a giantic conflagration of everything ever that kills
various reporters boxes. I still believe that the patch here fixes the
original bug, but there might be a lot more hiding.
I
Use the added helpers to track MST link bandwidth for atomic modesets.
Link bw is acquired in the ->atomic_check() phase when CRTCs are being
enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots().
Similarly, link bw is released during ->atomic_check() with the connector
helper
Link bandwidth is a shared resource between multiple displays in DP MST
configurations. For atomic modesetting drivers, checking if there is
sufficient link bandwidth for a mode needs to be done during the
atomic_check phase to avoid failed modesets when multiple CRTC's and
connectors are involved.
Convert drivers to use the new of_graph_get_remote_node() helper
instead of parsing the endpoint node and then getting the remote device
node. Now drivers can just specify the device node and which
port/endpoint and get back the connected remote device node. The details
of the graph binding are nic
I've been unhappy with the OF graph API for some time and decided to
do something about it. The problem is drivers have to do too much of the
graph parsing and walking themselves. This has led to the same pattern
duplicated over and over. This series adds 2 new helpers and adapts DRM
drivers to use
On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> > Having a ->atomic_release callback is useful to release shared
> > resources
> > that get allocated in compute_config(). This function is expected to
> > be
> > called i
Similar to the previous commit, convert drivers open coding OF graph
parsing to use drm_of_find_panel_or_bridge instead.
This changes some error messages to debug messages (in the graph core).
Graph connections are often "no connects" depending on the particular
board, so we want to avoid spurious
The avail_slots member in the MST topology manager is never updated to
reflect the available vcpi slots. The check is effectively against
total slots, 63. So, let's make that check obvious and remove
avail_slots. While at it, make debug messages more descriptive.
Signed-off-by: Dhinakaran Pandiyan
Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-0800]:
> Having a ->atomic_release callback is useful to release shared
> resources
> that get allocated in compute_config(). This function is expected to
> be
> called in the atomic_check() phase before new resources are acquired.
>
> v2: Mo
1 - 100 of 145 matches
Mail list logo
