On 21/02/17 07:00 PM, Stefan Lengfeld wrote:
>
> 2/ Wait for a single vsync event on all active crtcs as Ville Syrjälä
>described here [2] in the optimal implementation.
FWIW, this seems like a bad idea, since with multiple active CRTCs it
would make it essentially random at which intervals
On 02/22/2017 05:31 AM, Pandiyan, Dhinakaran wrote:
On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
Hi,
On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
It is necessary to
https://bugzilla.kernel.org/show_bug.cgi?id=194645
--- Comment #10 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Mateusz Lenik from comment #6)
> Can incremental builds (that means without clean/distclean, just building
> whatever files have changed) have some effect on bisect outcome?
Hi Sean
On 02/21/2017 11:39 PM, Sean Paul wrote:
On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote:
Hi all
[Resend this v7 version series, since there are 5 mails have gone missing, last
week]
This version does not change the existing v6 patches, just to add the
"bandwidth fix" patc
Hi all,
This patchset is resent patchset.
Because I have a missing TO, CC, I sent it again.
Sorry, I will send it in the correct format next time.
Best Regards,
Hoegeun
On 02/22/2017 10:09 AM, Hoegeun Kwon wrote:
Dear Thierry,
I understand that your opinion is:
It is better to handle th
https://bugs.freedesktop.org/show_bug.cgi?id=95306
--- Comment #61 from Jaime Rodrigo ---
(In reply to Jaime Rodrigo from comment #60)
> Tried every RC8 and it blackouts too. Official 4.10 release boots into low
> graphics mode by default, and theres no kernel driver in use (nor radeon or
> amdgp
On Fri, 17 Feb 2017, Manasi Navare wrote:
> Display stream compression is supported on DP 1.4 DP devices. This
> patch adds the corersponding DPCD register definitions for DSC.
>
> v2:
> * Rebased on drm-tip
>
> Signed-off-by: Manasi Navare
> Cc: Jani Nikula
> Cc: Paulo Zanoni
> Cc: dri-devel
From: Hyungwon Hwang
This patch add the panel device tree node for S6E3HA2 display
controller to TM2 dts.
Signed-off-by: Hyungwon Hwang
Signed-off-by: Andrzej Hajda
Signed-off-by: Chanwoo Choi
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
---
arch/arm64/boot/dts/exynos/exynos5433-tm
The Samsung s6e3ha2 is a 5.7" 1440x2560 AMOLED panel connected
using MIPI-DSI interfaces.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Reviewed-by: Andrzej Hajda
Acked-by: Rob Herring
---
.../bindings/display/panel/samsung,s6e3ha2.txt | 28
++
This patch add support for MIPI-DSI based S6E3HA2 AMOLED panel
driver. This panel has 1440x2560 resolution in 5.7-inch physical
panel in the TM2 device.
Signed-off-by: Donghwa Lee
Signed-off-by: Hyungwon Hwang
Signed-off-by: Hoegeun Kwon
Tested-by: Chanwoo Choi
Reviewed-by: Andrzej Hajda
---
Dear Thierry,
I understand that your opinion is:
It is better to handle the error every time it is input to the
register, rather than error handling at once in the struct using
error. This not only makes the code easier to maintain, but also
reduces unnecessary computation.
So I modified the pan
https://bugs.freedesktop.org/show_bug.cgi?id=95306
--- Comment #60 from Jaime Rodrigo ---
Tried every RC8 and it blackouts too. Official 4.10 release boots into low
graphics mode by default, and theres no kernel driver in use (nor radeon or
amdgpu). Installed AMDGPUPRO and I get stuck in the logg
Hi Dave
Some fixes, looks good to me.
Best regards.
The following changes since commit 9ca70356a9260403c1bda40d942935e55d00c11c:
Revert "drm: Resurrect atomic rmfb code, v3" (2017-02-17 12:39:04 +1000)
are available in the git repository at:
https://github.com/markyzq/kernel-drm-rockchip
On Tue, Feb 21, 2017 at 1:24 AM, Inki Dae wrote:
>>> Ideally you are right. DT changes should be no any dependency of driver
>>> changes but now Exynos DT is broken.
>>
>> I didn't receive any bug reports that Exynos DT is broken so I am
>> quite surprised hearing that. What do you mean by that?
On Tue, 2017-02-21 at 18:26 +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2017, Andy Shevchenko m> wrote:
> > The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element
> > support") enables GPIO support for Broxton based platforms.
> >
> > While using that API we might get into troubles in th
The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element
support") enables GPIO support for Broxton based platforms.
While using that API we might get into troubles in the future, because
we can't rely on label "panel" in the driver since vendor firmware might
provide any GPIO pin there, e
On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote:
>
> On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote:
> > On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote:
> >> Hi,
> >>
> >> On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote:
> >>> It is necessary to track states for objects other
00644
> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> @@ -41,9 +41,9 @@
> #include
> #include "vmwgfx_fence.h"
>
> -#define VMWGFX_DRIVER_DATE "20160210"
> +#define VMWGFX_DRIVER_DATE "20170221"
>
https://bugs.freedesktop.org/show_bug.cgi?id=99488
--- Comment #8 from Jan Vesely ---
Created attachment 129815
--> https://bugs.freedesktop.org/attachment.cgi?id=129815&action=edit
Fix-ALU-clause-markers-use-detection
This patch fixes gromacs build for me. I tested blur and it now results in
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #18 from intermedi...@hotmail.com ---
umm thans for the info.
i have an idea... but need to check oldest kernel version.
i see last release of kernel made radeon load only as a module. dont made
radeon as a y .
on embenbed ppc mach
On Fri, Feb 17, 2017 at 11:13:30AM +0800, Chen-Yu Tsai wrote:
> sun4i_crtc_init can fail for a number of reasons. Instead of returning
> a NULL pointer when it fails, pass back the encountered error using
> ERR_PTR.
>
> Signed-off-by: Chen-Yu Tsai
Applied, thanks!
Maxime
--
Maxime Ripard, Free
On Fri, Feb 17, 2017 at 11:13:29AM +0800, Chen-Yu Tsai wrote:
> sun4i_layers_init allocates an array to store pointers to newly created
> layers returned by sun4i_layer_init_one(), but fails to actually store
> them. But it actually returns the empty array to unsuspecting users.
>
> Save the point
On Fri, Feb 17, 2017 at 11:13:28AM +0800, Chen-Yu Tsai wrote:
> The assignment found in the main loop in sun4i_layers_init:
>
> struct sun4i_layer *layer = layers[i];
>
> is useless as it gets overwritten by the next line:
>
> layer = sun4i_layer_init_one(drm, plane);
>
> Drop the a
On Fri, Feb 17, 2017 at 11:13:27AM +0800, Chen-Yu Tsai wrote:
> In sun4i_layers_init we are allocating an array of pointers to struct
> sun4i_layer:
>
> layers = devm_kcalloc(drm->dev, ARRAY_SIZE(sun4i_backend_planes),
> sizeof(**layers), GFP_KERNEL);
>
> The ele
On Fri, Feb 17, 2017 at 11:13:26AM +0800, Chen-Yu Tsai wrote:
> drm_vblank_init can fail due to insufficient memory. Ignoring the error
> and proceeding may cause the kernel to dereference an invalid pointer
> when vblank is enabled.
>
> Signed-off-by: Chen-Yu Tsai
Applied, thanks!
Maxime
--
M
A cleanup patch just introduced this function, but no user, leading
to a compile-time warning:
drivers/gpu/drm/sti/sti_drv.c:120:13: error: 'sti_drm_dbg_cleanup' defined but
not used [-Werror=unused-function]
It would be logical that we should actually call this function, but
I couldn't see from
One variable was left behind after its user got removed and we should now
delete the declaration as well:
drivers/gpu/drm/sti/sti_vtg.c: In function 'vtg_probe':
drivers/gpu/drm/sti/sti_vtg.c:392:22: error: unused variable 'np'
[-Werror=unused-variable]
Fixes: 0c7ff84f7f9d ("drm/sti: remove depr
https://bugs.freedesktop.org/show_bug.cgi?id=99851
--- Comment #17 from Alex Deucher ---
(In reply to intermedi...@hotmail.com from comment #16)
> why im sure it is an xorg issue or one of xorg component issue
> (cafedead),because on Lubuntu 14.04.5 i had kernel 4.9 and no issue but xorg
> was 1
https://bugs.freedesktop.org/show_bug.cgi?id=99387
--- Comment #18 from Marco ---
Works fine here too (but only on 4.10) with the two ptches applied.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
d
On Mon, Feb 20, 2017 at 8:49 AM, Shawn Guo wrote:
> From: Shawn Guo
>
> Commit 4e986d3705df ("drm: zte: add overlay plane support") introduces
> the following static checker warning:
>
> drivers/gpu/drm/zte/zx_plane.c:170 zx_vl_rsz_setup()
> warn: always true condition '(fmt >= 0) => (0-u32max
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #21 from Matthew Fox ---
Created attachment 129814
--> https://bugs.freedesktop.org/attachment.cgi?id=129814&action=edit
dmesg after xrandr
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #20 from Matthew Fox ---
Created attachment 129813
--> https://bugs.freedesktop.org/attachment.cgi?id=129813&action=edit
dmesg before xrandr
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #19 from Matthew Fox ---
Created attachment 129812
--> https://bugs.freedesktop.org/attachment.cgi?id=129812&action=edit
vgaswitcheroo switch after xrandr
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #18 from Matthew Fox ---
Created attachment 129811
--> https://bugs.freedesktop.org/attachment.cgi?id=129811&action=edit
vgaswitcheroo switch before xrandr
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #17 from Matthew Fox ---
Created attachment 129810
--> https://bugs.freedesktop.org/attachment.cgi?id=129810&action=edit
Xorg log after xrandr
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=98869
Marek Olšák changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #16 from Matthew Fox ---
Created attachment 129809
--> https://bugs.freedesktop.org/attachment.cgi?id=129809&action=edit
Xorg log before xrandr
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #15 from Matthew Fox ---
Created attachment 129808
--> https://bugs.freedesktop.org/attachment.cgi?id=129808&action=edit
xrandr.log
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=99881
--- Comment #14 from Matthew Fox ---
Hi,
It's rare that the PC doesn't lock up with runpm enabled so I've only been able
to test this a couple of times.
In the first try, the PC had stabilized (stopped freezing) after a while. I
then ran xrandr
On Fri, Feb 17, 2017 at 11:13:25AM +0800, Chen-Yu Tsai wrote:
> The master bind function calls numerous drm functions which initialize
> underlying structures. It also tries to bind the various components
> of the display pipeline, some of which may add additional drm objects.
>
> This patch adds
On Fri, Feb 17, 2017 at 11:13:24AM +0800, Chen-Yu Tsai wrote:
> drm_mode_config_cleanup is the complement of drm_mode_config_init, which
> is called in the bind function of sun4i_drv. drm_mode_config_cleanup
> should be put in the unbind function to match.
>
> Signed-off-by: Chen-Yu Tsai
Applied
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #31 from siyia ---
ok not 10 but around 3GB
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://list
https://bugs.freedesktop.org/show_bug.cgi?id=99136
--- Comment #30 from siyia ---
lol thatgs 10 GB!!!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.fre
https://bugzilla.kernel.org/show_bug.cgi?id=194645
--- Comment #9 from Mateusz Lenik (m...@mlen.pl) ---
I retried it with x11 drivers build for 4.9.11, it still crashes
[ 64.460823] suspend debug: Waiting for 5 second(s).
[ 69.490160] sd 2:0:0:0: [sda] Starting disk
[ 69.490214] sd 4:0:0:0:
https://bugzilla.kernel.org/show_bug.cgi?id=194649
--- Comment #3 from Roberth Sjonøy (roberth.sjo...@gmail.com) ---
The example shown in the image is easily reproducible for me by just right
clicking over and over and it will appear.
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=194649
Roberth Sjonøy (roberth.sjo...@gmail.com) changed:
What|Removed |Added
Attachment #254861|xorg log. |xorg log
https://bugzilla.kernel.org/show_bug.cgi?id=194649
--- Comment #2 from Roberth Sjonøy (roberth.sjo...@gmail.com) ---
Created attachment 254861
--> https://bugzilla.kernel.org/attachment.cgi?id=254861&action=edit
xorg log.
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=194649
--- Comment #1 from Roberth Sjonøy (roberth.sjo...@gmail.com) ---
Created attachment 254859
--> https://bugzilla.kernel.org/attachment.cgi?id=254859&action=edit
dmesg output
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=194649
Bug ID: 194649
Summary: Graphical garbage r9 380
Product: Drivers
Version: 2.5
Kernel Version: 4.9
Hardware: All
OS: Linux
Tree: Mainline
Status:
https://bugzilla.kernel.org/show_bug.cgi?id=194645
--- Comment #8 from Mateusz Lenik (m...@mlen.pl) ---
(In reply to Christian König from comment #7)
> Please don't rebuild the x11 drivers! If it's a kernel bug you only need to
> build and check the kernel. X11 shouldn't be involved here.
>
> Or
https://bugzilla.kernel.org/show_bug.cgi?id=194645
--- Comment #7 from Christian König (deathsim...@vodafone.de) ---
(In reply to Mateusz Lenik from comment #6)
> I did check that it was using the freshly built kernel manually before every
> suspend test and I rebuilt x11 drivers every time the re
https://bugzilla.kernel.org/show_bug.cgi?id=194645
--- Comment #6 from Mateusz Lenik (m...@mlen.pl) ---
I did check that it was using the freshly built kernel manually before every
suspend test and I rebuilt x11 drivers every time the revision was changed.
Can incremental builds (that means witho
On Tue, 21 Feb 2017, Andy Shevchenko wrote:
> The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element
> support") enables GPIO support for Broxton based platforms.
>
> While using that API we might get into troubles in the future, because
> we can't rely on label "panel" in the driver sin
https://bugzilla.kernel.org/show_bug.cgi?id=194645
Christian König (deathsim...@vodafone.de) changed:
What|Removed |Added
CC||deathsim...@vo
On Tue, Feb 07, 2017 at 05:16:27PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
>
> Signed-off-by:
On Tue, Feb 07, 2017 at 05:16:25PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
>
> Signed-off-by:
On Thu, Feb 16, 2017 at 11:23:39AM +0800, Xinliang Liu wrote:
> On 7 February 2017 at 17:16, Shawn Guo wrote:
> > From: Shawn Guo
> >
> > The vblank hooks in struct drm_driver are deprecated and only meant for
> > legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks
> > in stru
https://bugzilla.kernel.org/show_bug.cgi?id=194645
--- Comment #4 from Mateusz Lenik (m...@mlen.pl) ---
I did try to bisect, but wasn't very successful. It reported totally unrelated
commit as the first “bad” commit.
I'm sure that resume for amdgpu works correctly on v4.9 and is broken on
4.10-rc
https://bugs.freedesktop.org/show_bug.cgi?id=99889
Ilia Mirkin changed:
What|Removed |Added
Product|DRI |xorg
QA Contact|
https://bugs.freedesktop.org/show_bug.cgi?id=99889
Bug ID: 99889
Summary: nouveau preventing shutdown after suspend-resume
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
On Mon, Feb 20, 2017 at 04:02:22PM +0800, Chris Zhong wrote:
> Set the lanes bps to 1 / 0.9 times of pclk, the margin is not enough
> for some panel, it will cause the screen display is not normal, so
> increases the badnwidth to 1 / 0.8.
>
> Signed-off-by: Chris Zhong
Reviewed-by: Sean Paul
>
On Mon, Feb 20, 2017 at 04:02:16PM +0800, Chris Zhong wrote:
> Hi all
>
> [Resend this v7 version series, since there are 5 mails have gone missing,
> last
> week]
>
> This version does not change the existing v6 patches, just to add the
> "bandwidth fix" patch back, since we really need it.
>
Am 21.02.2017 um 15:55 schrieb Marek Szyprowski:
Dear All,
On 2017-02-21 15:37, Marek Szyprowski wrote:
Hi Christian,
On 2017-02-21 14:59, Christian König wrote:
Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:
Add compat ioctl support to dma-buf. This lets one to use
DMA_BUF_IOCTL_SYNC
ioct
Dear All,
On 2017-02-21 15:37, Marek Szyprowski wrote:
Hi Christian,
On 2017-02-21 14:59, Christian König wrote:
Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:
Add compat ioctl support to dma-buf. This lets one to use
DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data str
Hi Christian,
On 2017-02-21 14:59, Christian König wrote:
Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:
Add compat ioctl support to dma-buf. This lets one to use
DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for
both 32
and 64bit modes are same, so there
On Fri, 17 Feb 2017, Ville Syrjälä wrote:
> On Fri, Feb 17, 2017 at 05:20:50PM +0200, Jani Nikula wrote:
>> v2 of cover.1487241304.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1487241304.git.jani.nikula@intel.com
>
> lgtm. For the series
> Reviewed-by: Ville Syrjälä
Thanks for th
On Mon, Feb 20, 2017 at 5:01 AM, Yannick FERTRE wrote:
>
>
> On 02/16/2017 03:34 AM, Rob Herring wrote:
>> On Fri, Feb 10, 2017 at 03:54:44PM +0100, Yannick Fertre wrote:
>>> Signed-off-by: Yannick Fertre
>>> ---
>>> .../bindings/display/panel/ampire,am-480272h3tmqw-t01h.txt | 7
>>> +++
On Mon, Feb 20, 2017 at 10:08 AM, Yannick Fertre wrote:
> Signed-off-by: Yannick Fertre
> ---
> .../devicetree/bindings/display/st,stm32-ltdc.txt | 36
> ++
> 1 file changed, 36 insertions(+)
> create mode 100644
> Documentation/devicetree/bindings/display/st,stm32-ltdc.t
Am 21.02.2017 um 14:21 schrieb Marek Szyprowski:
Add compat ioctl support to dma-buf. This lets one to use DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for both 32
and 64bit modes are same, so there is no need for additional translation
layer.
Well I might be
Instead of trying to do everything in 1 go, just do a basic safe
conversion first. We've been bitten by too many regressions in the
past.
This patch only converts drm_framebuffer_remove to atomic. The
regression sensitive part is split out to a separate patch.
v2:
- Remove plane->fb assignment, d
It seems that nouveau requires this, so best to do this in the helper.
This allows nouveau to use the atomic suspend helper.
Cc: nouv...@lists.freedesktop.org
Acked-by: Ben Skeggs #irc
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 51 ++
drivers/g
This fixes a connector leak first when disabling the device,
and then converts rmfb to atomic. The behavior change is done as
a separate patch, so it can be reverted if it breaks, again..
Maarten Lankhorst (3):
drm/atomic: Make disable_all helper fully disable the crtc.
drm: Convert drm_frameb
This introduces a slight behavioral change to rmfb. Instead of
disabling a crtc when the primary plane is disabled, we try to
preserve it.
Apart from old versions of the vmwgfx xorg driver, there is
nothing depending on rmfb disabling a crtc. Since vmwgfx is
a legacy driver we can safely only disa
Add compat ioctl support to dma-buf. This lets one to use DMA_BUF_IOCTL_SYNC
ioctl from 32bit application on 64bit kernel. Data structures for both 32
and 64bit modes are same, so there is no need for additional translation
layer.
Signed-off-by: Marek Szyprowski
---
drivers/dma-buf/dma-buf.c | 3
https://bugzilla.kernel.org/show_bug.cgi?id=194579
--- Comment #12 from PaX Team (pagee...@freemail.hu) ---
(In reply to Christian König from comment #11)
> The issue is that the offset handling should actually be transparent to TTM.
> So mem.start can have any value here which might as well overf
On ti, 2017-02-21 at 09:30 +, Chris Wilson wrote:
> In a similar fashion to reservation_object_lock() and
> reservation_object_unlock(), ww_mutex_trylock is also useful and so is
> worth wrapping for consistency.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Joonas Lahtinen
> Cc:
https://bugs.freedesktop.org/show_bug.cgi?id=91202
--- Comment #27 from Thomas R. ---
With amd-staging-4.9, commit a364784ea02674736abd9d345fd74bf6787f95a1
("drm/amdgpu: expose GPU sensor related information"), it works now, but only
if DC is enabled (I guess it's DAL reborn?)
Either I didn't co
ers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -41,9 +41,9 @@
#include
#include "vmwgfx_fence.h"
-#define VMWGFX_DRIVER_DATE "20160210"
+#define VMWGFX_DRIVER_DATE "20170221"
#define VMWGFX_DRIVER_MAJOR 2
-#define VMWGFX_DRIVER_MINOR 11
On 02/20/2017 11:22 PM, Daniel Vetter wrote:
> On Sun, Feb 19, 2017 at 4:21 PM, Thomas Hellstrom wrote:
>> So I think we need a quick revert of this commit or a quick stable
>> follow-up to unbreak things on our side.
> I'd much prefer we just register control nodes for vmwgfx only, with a
> commi
On Tue, Feb 21, 2017 at 11:00:59AM +0100, Stefan Lengfeld wrote:
> Hi Maxime,
>
> On Wed, Feb 15, 2017 at 05:19:09PM +0100, Maxime Ripard wrote:
> > From: Stefan Christ
> >
>
> Maybe change the author here. Only the boilerplate code looks my original
> patch. The real code is your work ;-)
>
>
On 02/21/2017 06:34 AM, David Airlie wrote:
>> No.
>>
>> IMO Not fixing this immediately through stable is out of the question.
>> The deal is that we don't break userspace.
>> Having said that, I'm not against a long term vmwgfx-only solution. But
>> let's fix this now.
>>
>> Admittedly we missed
Hi Maxime,
On Wed, Feb 15, 2017 at 05:19:09PM +0100, Maxime Ripard wrote:
> From: Stefan Christ
>
Maybe change the author here. Only the boilerplate code looks my original
patch. The real code is your work ;-)
> Implement legacy framebuffer ioctl FBIO_WAITFORVSYNC in the generic
> framebuffer
https://bugzilla.kernel.org/show_bug.cgi?id=194579
--- Comment #11 from Christian König (deathsim...@vodafone.de) ---
(In reply to PaX Team from comment #9)
> would the following workaround do the job of not triggering the overflow and
> not causing any other logic bugs for our purposes:
Not real
On Fri, 17 Feb 2017, Manasi Navare wrote:
> Display stream compression is supported on DP 1.4 DP
> devices. This patch adds the corersponding DPCD
> register definitions for DSC.
>
> v2:
> * Rebased on drm-tip
>
> Signed-off-by: Manasi Navare
> Cc: Jani Nikula
> Cc: Paulo Zanoni
> Cc: dri-devel
In a similar fashion to reservation_object_lock() and
reservation_object_unlock(), ww_mutex_trylock is also useful and so is
worth wrapping for consistency.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Joonas Lahtinen
Cc: Daniel Vetter
---
include/linux/reservation.h | 20
https://bugzilla.kernel.org/show_bug.cgi?id=194579
--- Comment #10 from Nicolai Hähnle (nhaeh...@gmail.com) ---
1. That shouldn't compile (use LONG_MAX).
2. The cur_placement still needs to be updated even in that case.
Guarding only the assignment to bo->offset in this way is a reasonable
workar
On Tue, 2017-02-21 at 11:02 +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2017, Joe Perches wrote:
> > On Tue, 2017-02-21 at 10:26 +0200, Jani Nikula wrote:
> > > You know how this stuff works, please split it up to get the stuff
> > > merged.
> >
> > Quite well actually.
> >
> > Fix it as you thin
https://bugzilla.kernel.org/show_bug.cgi?id=194645
--- Comment #3 from Mateusz Lenik (m...@mlen.pl) ---
I'll try to do it later today.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-deve
On Tue, 21 Feb 2017, Joe Perches wrote:
> On Tue, 2017-02-21 at 10:26 +0200, Jani Nikula wrote:
>> You know how this stuff works, please split it up to get the stuff
>> merged.
>
> Quite well actually.
>
> Fix it as you think appropriate.
> But in any case, fix it.
Yes, I'm sure someone will even
On ma, 2017-02-20 at 13:12 +0100, Maarten Lankhorst wrote:
> Op 20-02-17 om 13:03 schreef Chris Wilson:
> >
> > On Mon, Feb 20, 2017 at 01:32:42PM +0200, Joonas Lahtinen wrote:
> > >
> > > Smells like a helper function? While that helper is finding the way
> > > upstream;
> > Blurgh.
> >
> > enu
https://bugzilla.kernel.org/show_bug.cgi?id=194645
--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
Can you bisect?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.f
On Mon, 20 Feb 2017, Marek Vasut wrote:
> On 02/20/2017 10:05 AM, Dave Airlie wrote:
>> On 20 Feb. 2017 18:29, "Marek Vasut" wrote:
>>
>> On 02/20/2017 03:56 AM, Dave Airlie wrote:
>>> On 19 February 2017 at 08:25, Marek Vasut wrote:
On 02/17/2017 09:34 PM, Dave Airlie wrote:
> On 17 F
On Tue, 2017-02-21 at 10:26 +0200, Jani Nikula wrote:
> You know how this stuff works, please split it up to get the stuff
> merged.
Quite well actually.
Fix it as you think appropriate.
But in any case, fix it.
___
dri-devel mailing list
dri-devel@list
https://bugzilla.kernel.org/show_bug.cgi?id=194645
--- Comment #1 from Mateusz Lenik (m...@mlen.pl) ---
Created attachment 254851
--> https://bugzilla.kernel.org/attachment.cgi?id=254851&action=edit
full dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
https://bugzilla.kernel.org/show_bug.cgi?id=194645
Bug ID: 194645
Summary: amdgpu: amdgpu_resume failed
Product: Drivers
Version: 2.5
Kernel Version: 4.10
Hardware: x86-64
OS: Linux
Tree: Mainline
On Mon, 20 Feb 2017, Joe Perches wrote:
> On Mon, 2017-02-20 at 12:17 +, Eric Engestrom wrote:
>> On Wednesday, 2017-02-15 15:33:18 -0800, Joe Perches wrote:
>> > drm_printf does not currently use the compiler to verify
>> > format and arguments. Make it do so.
>> >
>> > Miscellanea:
>> >
>
Thanks for the review Maarten.
My comments inline.
Regards
Shashank
On 2/20/2017 5:48 PM, Maarten Lankhorst wrote:
Op 10-02-17 om 17:29 schreef Shashank Sharma:
Geminilake platform sports a native HDMI 2.0 controller, and is
capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec
mendat
97 matches
Mail list logo
