https://bugs.freedesktop.org/show_bug.cgi?id=101733
Clément Guérin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=101731
--- Comment #10 from Shmerl ---
Created attachment 132626
--> https://bugs.freedesktop.org/attachment.cgi?id=132626&action=edit
The Witcher 3 crash save (GOG/GOTY version).
With latest Mesa built from source, it now consistently crashes for m
RK3399's GPU uses the quad-core Mali-T860, which is the new generation of
high-end graphics processors from ARM.
This patch added "rockchip,rk3399-mali" for dt-bindings, in order to
support IPA of gpu thermal in later.
Signed-off-by: Caesar Wang
---
Documentation/devicetree/bindings/gpu/arm,ma
This series patches supported the mail in devicetree and used the
thermal IPA by default.
Verified with rk3399 kevin board on my github
https://github.com/Caesar-github/rockchip/commits/gru/next-stable-chromeos
The kernel is based on Linus's master branch and Heiko's
v4.14-armsoc-tmp/dts64 branch.
DRM_IOCTL_VERSION is supposed to update the name_len/date_len/desc_len
fields to user.
Fixes: 012c6741c6aa("switch compat_drm_version() to drm_ioctl_kernel()")
Signed-off-by: Jeffy Chen
---
drivers/gpu/drm/drm_ioc32.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/drm_i
https://bugs.freedesktop.org/show_bug.cgi?id=101731
--- Comment #9 from Shmerl ---
I noticed, when I set graphics settings to minimum, this freeze doesn't happen
(or at least didn't happen to me so far).
--
You are receiving this mail because:
You are the assignee for the bug.__
This commit will take the topmost commit and add all cc's from
get_maintainer.pl, it is useful for adding cc's to an entire patch
series touching multiple drivers, to add the right cc to each one.
Signed-off-by: Maarten Lankhorst
---
dim | 41 +
dim.rs
On 07/03/2017 02:11 PM, Philippe CORNU wrote:
Add a Synopsys Designware MIPI DSI host DRM bridge driver, based on the
Rockchip version from rockchip/dw-mipi-dsi.c with phy & bridge APIs.
The patch looks good now. One thing that needs to be updated is to make
drm_bridge_add() not return anyth
From: Christian König
Pinning them in other devices VRAM would obviously not work.
v2: Add checks to DC code paths
Signed-off-by: Christian König
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 6 ++
drivers/gpu/drm/amd/amdgpu/dce_v10_0.c
From: Christian König
This allows us to have multiple GEM objects for one BO.
Signed-off-by: Christian König
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 12 +++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 41 +++---
drivers/gpu/d
https://bugs.freedesktop.org/show_bug.cgi?id=101731
--- Comment #8 from Shmerl ---
(In reply to Philipp Überbacher from comment #5)
> I've used this to get a apitrace quickly and I have one with just 1.1 GB.
> However, replaying it does not produce the freeze. Maybe the actual freeze
> trigger d
https://bugs.freedesktop.org/show_bug.cgi?id=101731
--- Comment #7 from Shmerl ---
I have the freeze with hairworks disabled all the same.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@li
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 57f5c7f15032e48265fb4302cf8eb62ec7ce3246
commit: 24ede71be1fefa780f3e8c3ad7e9b65a5d4fd4c2 [625/639] drm/amd/display:
Create dm_plane_state.
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (G
Vop Full framework now has following vops:
IP versionchipname
3.1 rk3288
3.2 rk3368
3.4 rk3366
3.5 rk3399 big
3.6 rk3399 lit
3.7 rk3228
3.8 rk3328
The above IP version is from H/W define, some of vop support ge
Changes in v2:
- rename rk322x to rk3228(Heiko Stübner)
Signed-off-by: Mark Yao
---
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt
b/Documentation/de
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 66 +
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 18 ++--
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 20 ++---
3 files changed, 77 insertions(+), 27 deletions(-)
diff --git a/drive
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
drivers/gpu/drm/rockchip/rockchip_drm_vop.h | 4 ++--
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 8
3 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.
Register init table use un-document define, it is unreadable,
And sometimes we only want to update tiny bits, init table
method is not friendly, it's diffcult to reuse for difference
chips.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 6 ++--
drivers/gpu/drm/rockchi
These patches try to make all current rockchip full framework vop works
on drm, The newer vop design always have some different to the old one,
So we add a register verify mechanism to distinguish those register, then
the registers table can be reused.
And people can easy to know the different for
https://bugs.freedesktop.org/show_bug.cgi?id=101294
--- Comment #15 from Michel Dänzer ---
(In reply to MirceaKitsune from comment #14)
> I assume I'm experiencing the same bug described here [...]
You're most definitely not. Many different causes can result in similar
symptoms. If the symptoms
On 2017年07月11日 20:45, Heiko Stübner wrote:
Hi Mark,
Am Dienstag, 11. Juli 2017, 20:42:38 CEST schrieb Mark Yao:
Signed-off-by: Mark Yao
---
Documentation/devicetree/bindings/display/rockchip/rockchip-vop.txt | 4
1 file changed, 4 insertions(+)
diff --git
a/Documentation/devicetree/bind
On Mon, Jul 10, 2017 at 11:25:31AM +0200, Simon Horman wrote:
> On Mon, Jun 26, 2017 at 10:56:42AM -0500, Rob Herring wrote:
> > On Wed, Jun 21, 2017 at 12:31:27PM +0300, Laurent Pinchart wrote:
> > > The M3-W HDMI TX controller seems to be compatible for the H3. No
> > > extension to the DT bindin
Greetings,
I met $subject in master-rt post drm merge, but taking the config
(attached) to virgin v4.12-10624-g9967468c0a10, it's reproducible.
KERNEL: vmlinux-4.12.0.g9967468-preempt.gz
DUMPFILE: vmcore
CPUS: 8
DATE: Tue Jul 11 18:55:28 2017
UPTIME: 00:02:03
LOAD
On Tue, 2017-07-11 at 14:22 -0400, Ilia Mirkin wrote:
>
> OK, thanks. So in other words, a fairly standard desktop with a PCIe
> board plugged in. No funny business. (Laptops can create a ton of
> additional weirdness, which I assumed you had since you were talking
> about STR.)
Yup, garden varie
On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote:
> Some details that may be useful in analysis of the bug:
>
> 1. lspci -nn -d 10de:
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce GTX
980] [10de:13c0] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GM20
On (07/11/17 11:31), Sergey Senozhatsky wrote:
[..]
> (replying to both Petr and Daniel)
>
> interesting direction, gents.
>
> and this is what I thought about over the weekend; it's very sketchy and
> I didn't spend too much time on it. (I'm on a sick leave now, sorry).
>
> it's quite close to
On 2017-07-11 10:13, Daniel Vetter wrote:
> On Thu, Jul 06, 2017 at 02:20:48PM +0200, Peter Rosin wrote:
>> Drivers no longer have any need for these callbacks, and there are no
>> users. Zap. Zap-zap-zzzap-p-pp-p.
>>
>> Signed-off-by: Peter Rosin
>
> On patches 4-14: Acked-by: Daniel Vetter
>
On 2017-07-11 10:01, Daniel Vetter wrote:
> On Thu, Jul 06, 2017 at 02:20:35PM +0200, Peter Rosin wrote:
>> While at it, add some words in the kernel-doc about the 'replaced' arg and
>> remove a faulty kernel-doc comment on the return value.
>>
>> Also remove a redundant return statement.
>>
>> Sig
On 2017-07-11 10:10, Daniel Vetter wrote:
> On Thu, Jul 06, 2017 at 02:20:37PM +0200, Peter Rosin wrote:
>> The legacy path implements setcmap in terms of crtc .gamma_set.
>>
>> The atomic path implements setcmap by directly updating the crtc gamma_lut
>> property.
>>
>> This has a couple of benefi
On (07/11/17 09:50), Daniel Vetter wrote:
[..]
> > ok, obviously stupid.
> >
> > I meant to hold con->lock between console_disable() and console_enable().
> > so no other CPU can unregister it, etc. printk->console_unlock(), thus,
> > can either have a racy con->flags check (no con->lock taken) or
Hello,
On (07/10/17 20:07), Daniel Vetter wrote:
[..]
> > Would it be acceptable to remove "console=tty0" parameter and push
> > the messages only to the serial console?
> >
> > Also there is the patchset from Peter Zijlstra that allows to
> > use early console all the time, see
> > https://lkml.k
On 2017-07-11 10:02, Daniel Vetter wrote:
> On Thu, Jul 06, 2017 at 02:20:36PM +0200, Peter Rosin wrote:
>> Do not waste cycles looking up the property id when we have the
>> actual property already.
>>
>> Signed-off-by: Peter Rosin
>
> With the names adjusted per my comments on patch 1 this lgtm
Hi Benjamin,
[auto build test ERROR on linus/master]
[also build test ERROR on v4.12 next-20170711]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Benjamin-Gaignard/fbdev-make
https://bugs.freedesktop.org/show_bug.cgi?id=100400
--- Comment #13 from CraZy bisCuiT ---
Thanks for fixing! With the current mesa-git and llvm-svn it seems to work
flawlessly!
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=99349
--- Comment #16 from higu...@gmx.net ---
So if the patch works, will it be merged? or is already merged, and if yes, in
what version?
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=100742
--- Comment #3 from Alex Deucher ---
I think we probably need to add a new op to the context ioctl to allow the
application to request a floor for a specific clock (sclk, mclk, dclk, eclk,
etc.) so that the application can override the natural d
From: Kieran Bingham
The driver recently switched from handling page flip completion in the
DU vertical blanking handler to the VSP frame end handler to fix a race
condition. This unfortunately resulted in incorrect timestamps in the
vertical blanking events sent to userspace as vertical blanking
The DU can compose the output of a VSP with other planes on Gen2
hardware, and of two VSPs on Gen3 hardware. Neither of these features
are supported by the driver, and the current implementation always
assigns planes to CRTCs the same way.
Simplify the implementation by configuring plane assignmen
Hello,
The recent changes to the rcar-du driver to fix a page flip handling race
condition changed the order of which vblanks and page flips are handled,
resulting in incorrect timestamps being reported in the vblan events.
Correct this by handling vblank events in the same completion handler as
When implementing support for interlaced modes, the driver switched from
reporting vblank events on the vertical blanking (VBK) interrupt to the
frame end interrupt (FRM). This incorrectly divided the reported refresh
rate by two. Fix it by moving back to the VBK interrupt.
Fixes: 906eff7fcada ("d
https://bugs.freedesktop.org/show_bug.cgi?id=101294
--- Comment #14 from MirceaKitsune ---
Greetings. I'm also getting a GPU crash / system lockup, when running Minecraft
as well as other game engines. It doesn't happen during the splash screen, but
probabilistically while the game is running. Th
https://bugs.freedesktop.org/show_bug.cgi?id=101672
--- Comment #8 from MirceaKitsune ---
Created attachment 132621
--> https://bugs.freedesktop.org/attachment.cgi?id=132621&action=edit
mesa_err_2.log
The freeze persists in Mesa 17.1.4. This comes as a surprise since a GPU lockup
was fixed in
https://bugs.freedesktop.org/show_bug.cgi?id=100742
--- Comment #2 from higu...@gmx.net ---
maybe my bug is a dupe from this
https://bugs.freedesktop.org/show_bug.cgi?id=101749
i notice that we all have a RX480... does other AMDGPU cards also have this or
is the problem only related with this har
On 11/07/17 22:39, Maxime Ripard wrote:
> On Tue, Jul 11, 2017 at 08:30:33AM +0200, Hans Verkuil wrote:
>> From: Hans Verkuil
>>
>> This patch series adds CEC support for the sun4i HDMI controller.
>>
>> The CEC hardware support for the A10 is very low-level as it just
>> controls the CEC pin. Sin
When implementing support for interlaced modes, the driver switched from
reporting vblank events on the vertical blanking (VBK) interrupt to the
frame end interrupt (FRM). This incorrectly divided the reported refresh
rate by two. Fix it by moving back to the VBK interrupt.
Fixes: 906eff7fcada ("d
On Tue, Jul 11, 2017 at 08:30:33AM +0200, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This patch series adds CEC support for the sun4i HDMI controller.
>
> The CEC hardware support for the A10 is very low-level as it just
> controls the CEC pin. Since I also wanted to support GPIO-based CEC
> h
On Tue, Jul 11, 2017 at 9:53 PM, Rob Clark wrote:
> On Tue, Jul 11, 2017 at 10:42 AM, Daniel Vetter wrote:
>> On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark wrote:
>>> On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote:
On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote:
> +static unsign
On Tue, Jul 11, 2017 at 8:10 PM, Takashi Iwai wrote:
> On Tue, 11 Jul 2017 19:35:36 +0200,
> Daniel Vetter wrote:
>>
>> On Mon, Jul 10, 2017 at 4:56 PM, Daniel Vetter wrote:
>> > On Mon, Jul 10, 2017 at 11:37 AM, Takashi Iwai wrote:
>> >>> DPMS should be an error anyway, we want that to be able
On 11/07/17 08:30, Hans Verkuil wrote:
> From: Hans Verkuil
>
> This patch series adds CEC support for the sun4i HDMI controller.
>
> The CEC hardware support for the A10 is very low-level as it just
> controls the CEC pin. Since I also wanted to support GPIO-based CEC
> hardware most of this pa
This is just future proofing code, not something that can be triggered
in real life. We're testing to make sure we don't shift wrap when we
do "1ull << i" so "i" has to be in the 0-63 range. If it's 64 then we
have gone too far.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/amd/amd
On Tue, Jul 11, 2017 at 10:42 AM, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark wrote:
>> On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote:
>>> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote:
+static unsigned long hijack_firmware_fb(struct drm_device *dev)
+
On Tue, Jul 11, 2017 at 12:22 AM, Daniel Vetter wrote:
> On Mon, Jul 10, 2017 at 02:09:42PM -0700, Jason Ekstrand wrote:
> > On Mon, Jul 10, 2017 at 9:15 AM, Christian König <
> deathsim...@vodafone.de>
> > wrote:
> >
> > > Am 10.07.2017 um 17:52 schrieb Jason Ekstrand:
> > >
> > > On Mon, Jul 10
On Mon, Jul 10, 2017 at 11:48:00PM +0800, Chen-Yu Tsai wrote:
> On Sun, Jun 18, 2017 at 10:05 PM, Rob Herring wrote:
> > On Wed, Jun 14, 2017 at 02:30:16PM +0800, Chen-Yu Tsai wrote:
> >> The explanation for the endpoint ID numbering scheme is convoluted
> >> and hard to understand.
> >>
> >> This
On Mon, Jul 10, 2017 at 04:55:04PM +1000, Jonathan Liu wrote:
> The drm_driver lastclose callback is called when the last userspace
> DRM client has closed. Call drm_fbdev_cma_restore_mode to restore
> the fbdev console otherwise the fbdev console will stop working.
>
> Fixes: 9026e0d122ac ("drm:
On Tue, Jul 11, 2017 at 2:35 PM, Geert Uytterhoeven
wrote:
> Hi Rob,
>
> On Tue, Jul 11, 2017 at 8:20 PM, Rob Clark wrote:
>> So now that this is working (at least on a single device), I figured
>> it was a good time to send out an RFC to start discussion about how
>> to do this properly, in part
Hi Rob,
On Tue, Jul 11, 2017 at 8:20 PM, Rob Clark wrote:
> So now that this is working (at least on a single device), I figured
> it was a good time to send out an RFC to start discussion about how
> to do this properly, in particular the CCF/powerdomain parts.
>
> The first patch adds flags so
On Tue, Jul 11, 2017 at 2:08 PM, Mike Galbraith wrote:
> On Tue, 2017-07-11 at 13:51 -0400, Ilia Mirkin wrote:
>> Some details that may be useful in analysis of the bug:
>>
>> 1. lspci -nn -d 10de:
>
> 01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM204 [GeForce
> GTX 980] [10de:13
It is quite common for bootloader to enable display on tablets/phones.
But until now for upstream kernel we've been ignoring that since it
highly confuses drm/msm, and recommending to disable the bootloader
display. (Otherwise we end up trying to set rates on already enabled
clks and all sorts of
The goal here is to support inheriting a display setup by bootloader,
although there may also be some non-display related use-cases.
Rough idea is to add a flag for clks and power domains that might
already be enabled when kernel starts, and make corresponding fixups
to clk enable/prepare_count an
We need to do some things a bit differently if the bridge chip is
already powered up when the driver loads (ie. bootloader has already
enabled display). In particular we don't want to do anything that
would kill the display.
---
drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 57 ++
So now that this is working (at least on a single device), I figured
it was a good time to send out an RFC to start discussion about how
to do this properly, in particular the CCF/powerdomain parts.
The first patch adds flags so we can mark power domains and leaf
node clocks which might (or might
On Tue, 11 Jul 2017 19:35:36 +0200,
Daniel Vetter wrote:
>
> On Mon, Jul 10, 2017 at 4:56 PM, Daniel Vetter wrote:
> > On Mon, Jul 10, 2017 at 11:37 AM, Takashi Iwai wrote:
> >>> DPMS should be an error anyway, we want that to be able to properly
> >>> thread the acquire_ctx EDEADLK backoff stuf
Some details that may be useful in analysis of the bug:
1. lspci -nn -d 10de:
2. What displays, if any, you have plugged into the NVIDIA board when
this happens?
3. Any boot parameters, esp relating to ACPI, PM, or related?
Cheers,
-ilia
On Tue, Jul 11, 2017 at 1:32 PM, Mike Galbraith wrote:
On Tue, Jul 11, 2017 at 3:07 PM, kbuild test robot wrote:
> make ARCH=i386
Yeah, either this code shouldn't have been built on 32-bit arch at
all, or be portable.
>arch/x86/pci/fixup.c: In function 'pci_amd_enable_64bit_bar':
>>> arch/x86/pci/fixup.c:674:15: warning: large integer i
On Tue, Jul 11, 2017 at 11:20 AM, Dave Airlie wrote:
> On 11 July 2017 at 18:36, Christian König wrote:
>> Am 11.07.2017 um 08:49 schrieb Dave Airlie:
>>>
>>> On 7 July 2017 at 19:07, Christian König wrote:
Hi Dave,
on first glance that looks rather good to me, but there is o
On Mon, Jul 10, 2017 at 4:56 PM, Daniel Vetter wrote:
> On Mon, Jul 10, 2017 at 11:37 AM, Takashi Iwai wrote:
>>> DPMS should be an error anyway, we want that to be able to properly
>>> thread the acquire_ctx EDEADLK backoff stuff through that we need for
>>> atomic. That would be the best long-t
Quoting Chris Wilson (2017-02-14 12:40:01)
> [ 236.821534] WARNING: kmemcheck: Caught 64-bit read from uninitialized
> memory (8802538683d0)
> [ 236.828642]
> 42001e7f0008
> [ 236.839543] i i i i u u u u i i i i i i i i u u u u u u u u u
On Tue, Jul 11, 2017 at 5:44 PM, John Stultz wrote:
> On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote:
>> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote:
> > be even better if you could calculate whether the mode is valid, but I
> > didn't
> > spend enough time to figure ou
https://bugs.freedesktop.org/show_bug.cgi?id=92715
--- Comment #31 from Armando Antonio ---
The following test fail on BSW with latest configuration
Test list
gt@gem_reset_stats@reset-count-
https://bugs.freedesktop.org/show_bug.cgi?id=92715
Armando Antonio changed:
What|Removed |Added
Summary|[IGT] |[IGT]
|[BYT-M/KBL/BX
https://bugs.freedesktop.org/show_bug.cgi?id=92715
--- Comment #29 from Armando Antonio ---
Sorry this is the test list
igt@gem_reset_stats@ban-default
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing lis
https://bugs.freedesktop.org/show_bug.cgi?id=101749
--- Comment #1 from Christoph Haag ---
Possibly the same as bug 100742 which is very visible with SteamVR.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel maili
https://bugs.freedesktop.org/show_bug.cgi?id=92715
Armando Antonio changed:
What|Removed |Added
Summary|[IGT] |[IGT]
|[BYT-M/KBL/BS
On Tue, Jul 11, 2017 at 8:12 AM, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote:
> be even better if you could calculate whether the mode is valid, but I
> didn't
> spend enough time to figure out if this is possible.
Theoretically that might b
On Tue, Jul 11, 2017 at 12:17 AM, Christian König
wrote:
> Am 11.07.2017 um 04:36 schrieb Michel Dänzer:
>
>> On 11/07/17 06:09 AM, Jason Ekstrand wrote:
>>
>>> On Mon, Jul 10, 2017 at 9:15 AM, Christian König
>>> mailto:deathsim...@vodafone.de>> wrote:
>>>
>>> Am 10.07.2017 um 17:52 schrieb
https://bugs.freedesktop.org/show_bug.cgi?id=101712
--- Comment #6 from guiscara...@gmail.com ---
Created attachment 132618
--> https://bugs.freedesktop.org/attachment.cgi?id=132618&action=edit
Dmesg after boot
(In reply to Julien Isorce from comment #5)
> Thx for the apitrace. I could not repr
On Tue, Jul 11, 2017 at 5:05 PM, John Stultz wrote:
>>> > be even better if you could calculate whether the mode is valid, but I
>>> > didn't
>>> > spend enough time to figure out if this is possible.
>>>
>>> Theoretically that might be possible, checking if the requested freq
>>> matches the cal
https://bugs.freedesktop.org/show_bug.cgi?id=100189
--- Comment #15 from Indie ---
I actually need this.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
On Tue, Jul 11, 2017 at 12:56 AM, Daniel Vetter wrote:
> On Mon, Jul 10, 2017 at 03:47:54PM -0700, John Stultz wrote:
>> On Mon, Jul 10, 2017 at 2:18 PM, Sean Paul wrote:
>> > On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote:
>> >> Currently the hikey dsi logic cannot generate accurate
https://bugs.freedesktop.org/show_bug.cgi?id=101712
Vedran Miletić changed:
What|Removed |Added
Summary|CPU lockup after ring 0 |[Turks PRO/Radeon HD
Instead check info->ops->owner, which amounts to the same.
Spotted because I want to remove the pile of broken and cargo-culted
fb_info->flags assignments in drm drivers.
v2: Fixup matrox (reported by kbuild). Also nuke FBINFO_FLAG_* defines
that I've failed to spot.
v3: Don't nuke FBINFO_FLAG_D
On Tue, Jul 11, 2017 at 4:31 PM, Rob Clark wrote:
> On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote:
>> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote:
>>> +static unsigned long hijack_firmware_fb(struct drm_device *dev)
>>> +{
>>> + struct msm_drm_private *priv = dev->dev_private;
On Tue, Jul 11, 2017 at 10:17 AM, Chris Wilson wrote:
> Quoting Rob Clark (2017-07-11 14:38:22)
>> +static unsigned long hijack_firmware_fb(struct drm_device *dev)
>> +{
>> + struct msm_drm_private *priv = dev->dev_private;
>> + unsigned long size;
>> + int i;
>> +
>> + /*
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Signed-off-by: Maarten Lankhorst
Cc: CK Hu
Cc: Philipp Zabel
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-media...@lists.infradead.org
--
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
VC4 has its own nonblocking modeset tracking through the vc4->async_modeset
semaphore, so it doesn't need to stall in swap_state. Pass stall = fal
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Signed-off-by: Maarten Lankhorst
Cc: Jyri Sarha
Cc: Tomi Valkeinen
---
drivers/gpu/drm/tilcdc/tilcdc_drv.c | 6 +-
1 file changed, 5 inser
Now that all drivers check the return value, convert swap_state to
__must_check. This is done separately to force build warnings if we
missed a driver.
Signed-off-by: Maarten Lankhorst
---
include/drm/drm_atomic_helper.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/inclu
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_atomic_helper.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index bfb98fbd0e0e..05a22aeffbb0 100644
--- a/drivers/gpu/drm/drm
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Signed-off-by: Maarten Lankhorst
Cc: Thierry Reding
Cc: Jonathan Hunter
Cc: linux-te...@vger.kernel.org
---
drivers/gpu/drm/tegra/drm.c | 7 ++
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
MSM has its own busy tracking, which means the swap_state call can be
done with stall = false, in which case it should never return an error.
Hand
drm_atomic_helper_swap_state could previously never fail, in order to still
continue it would set a limit of 10s on waiting for previous updates to
complete,
then it moved forward. This can be very bad when ignoring previous updates,
because the hw state and sw state may get out of sync when for e
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Atmel tracks pending commits through dc->commit.pending, so it can
ignore the changes by setting stall = false. We never return failure in
this ca
Make it more clear that post commit return ret is really return 0,
and add a missing drm_atomic_helper_cleanup_planes when
drm_atomic_helper_wait_for_fences fails.
Fixes: 839ca903f12e ("drm/nouveau/kms/nv50: transition to atomic interfaces
internally")
Cc: Ben Skeggs
Cc: dri-devel@lists.freedes
drm_atomic_helper_swap_state() will be changed to interruptible waiting
in the next few commits, so all drivers have to be changed to handling
failure.
Signed-off-by: Maarten Lankhorst
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
---
drivers/gpu/drm/nouveau/nv50_display.c | 5 -
1 file
We want to change swap_state to wait indefinitely, but to do this
swap_state should wait interruptibly. This requires propagating
the error to each driver.
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Maarten Lankhorst
---
On Tue, Jul 11, 2017 at 10:03 AM, Daniel Vetter wrote:
> On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote:
>> +static unsigned long hijack_firmware_fb(struct drm_device *dev)
>> +{
>> + struct msm_drm_private *priv = dev->dev_private;
>> + unsigned long size;
>> + int i;
>> +
>>
Quoting Rob Clark (2017-07-11 14:38:22)
> +static unsigned long hijack_firmware_fb(struct drm_device *dev)
> +{
> + struct msm_drm_private *priv = dev->dev_private;
> + unsigned long size;
> + int i;
> +
> + /* if we have simplefb/efifb, find it's aperture and hijack
> +
On Tue, Jul 11, 2017 at 3:38 PM, Rob Clark wrote:
> +static unsigned long hijack_firmware_fb(struct drm_device *dev)
> +{
> + struct msm_drm_private *priv = dev->dev_private;
> + unsigned long size;
> + int i;
> +
> + /* if we have simplefb/efifb, find it's aperture and hij
Needed for following patch.
Signed-off-by: Rob Clark
---
drivers/video/fbdev/core/fbmem.c | 6 --
include/linux/fb.h | 2 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/core/fbmem.c b/drivers/video/fbdev/core/fbmem.c
index 5324358f110f..db
1 - 100 of 144 matches
Mail list logo
