https://bugs.freedesktop.org/show_bug.cgi?id=102962
--- Comment #3 from Matt ---
This bug has been going on for me since wine-staging 2.17 and continues in 2.19
released today.
Some particulars of my setup.
Fiji (Fury) card
running patched kernel 4.12 with Display Core patches
mesa-git - 17.3.0
https://bugs.freedesktop.org/show_bug.cgi?id=102646
--- Comment #16 from Justin Mitzel ---
I tested under other Desktop Environments, and it does appear that the problem
is still there, just not as noticeable as under plasma. I do want to know
though, is there any work I can do that would help so
Hi Sean,
On 10/21/2017 12:52 AM, Sean Paul wrote:
On Thu, Oct 19, 2017 at 11:48:05AM +0800, Jeffy Chen wrote:
This patch has somehow lost it's original author. I assume this is not
intentional.
oops, sorry, guess i used some wrongly command during the rebasing...
will fix that.
___
Hi Sean,
On 10/21/2017 01:25 AM, Sean Paul wrote:
I didn't catch this before applying, just right after (of course).
Fixes:
../drivers/gpu/drm/rockchip/analogix_dp-rockchip.c: In function
‘rockchip_dp_of_probe’:
../drivers/gpu/drm/rockchip/analogix_dp-rockchip.c:276:6: warning:
unused variable
https://bugzilla.kernel.org/show_bug.cgi?id=196615
Florian Schmitt (kommer...@galois.de) changed:
What|Removed |Added
CC||kommer...@galois.d
https://bugzilla.kernel.org/show_bug.cgi?id=196615
--- Comment #29 from klavkala...@gmail.com ---
I did a quick test on my Arch linux install. With Linux 4.14-rc5 and this
latest patch applied, it seems to work like it should! I suspended and resumed
twice and there were no errors reported and the
https://bugzilla.kernel.org/show_bug.cgi?id=194761
--- Comment #89 from yousifjka...@yahoo.com ---
@Michel Dänzer
Many thanks for your kind & rapid reply !
No ! No ! Since I was on Fedora 24 that I used for 11 months & then I upgraded
from Fedora 24 to Fedora 26, till now my Radeon VGA do not wo
https://bugs.freedesktop.org/show_bug.cgi?id=103317
--- Comment #5 from Torsten Kessler ---
Created attachment 134943
--> https://bugs.freedesktop.org/attachment.cgi?id=134943&action=edit
Second Xorg log with EnablePageFlip turned off
You're right. I was mixing things up. I meant loading the r
I didn't catch this before applying, just right after (of course).
Fixes:
../drivers/gpu/drm/rockchip/analogix_dp-rockchip.c: In function
‘rockchip_dp_of_probe’:
../drivers/gpu/drm/rockchip/analogix_dp-rockchip.c:276:6: warning:
unused variable ‘ret’ [-Wunused-variable]
int ret;
^~~
Fix
https://bugs.freedesktop.org/show_bug.cgi?id=92836
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Wed, Oct 18, 2017 at 1:11 PM, Meghana Madhyastha
wrote:
> On Mon, Oct 16, 2017 at 02:26:00PM -0400, Sean Paul wrote:
>> On Fri, Oct 13, 2017 at 6:42 PM, Noralf Trønnes wrote:
>> >
>> > Den 13.10.2017 22.25, skrev Sean Paul:
>> >>
>> >> On Fri, Oct 13, 2017 at 04:11:43PM +0530, Meghana Madhyast
On Tue, Oct 17, 2017 at 10:21:19PM -0600, Haneen Mohammed wrote:
> This patchset move debug macros from drmP.h to drm_print.h and move
> printing related functions used by the debug macros from drm_drv.[hc]
> to drm_print.[hc].
> In addition, it fixes old comment style.
>
> Changes in v4:
> - Move
https://bugs.freedesktop.org/show_bug.cgi?id=103365
Chris Wilson changed:
What|Removed |Added
Component|DRM/Intel |IGT
QA Contact|intel-gfx-bugs@li
Den 20.10.2017 18.00, skrev Ville Syrjälä:
On Fri, Oct 20, 2017 at 05:44:15PM +0200, Noralf Trønnes wrote:
Den 20.10.2017 15.52, skrev Ville Syrjälä:
On Fri, Oct 20, 2017 at 01:02:00AM +0200, Noralf Trønnes wrote:
drm_fb_helper is *the* way of doing fbdev emulation so add a pointer to
struct
Implement preemption for A5XX targets - this allows multiple
ringbuffers for different priorities with automatic preemption
of a lower priority ringbuffer if a higher one is ready.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/Makefile | 1 +
drivers/gpu/drm/msm/adreno/a5xx
Add a shadow pointer to track the current command being written into
the ring. Don't commit it as 'cur' until the command is submitted.
Because 'cur' is used to construct the software copy of the wptr this
ensures that somebody peeking in on the ring doesn't assume that a
command is inflight while
When we move to multiple ringbuffers we're going to store the data
in the memptrs on a per-ring basis. In order to prepare for that
move the current memptrs from the adreno namespace into msm_gpu.
This is way cleaner and immediately lets us kill off some sub
functions so there is much less cost lat
Recent changes to locking have rendered struct_mutex_task
unused.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_drv.h| 6 --
drivers/gpu/drm/msm/msm_gem_submit.c | 2 --
2 files changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_d
On Thu, Oct 19, 2017 at 11:48:02AM +0800, Jeffy Chen wrote:
>
> Make edp display works on chromebook kevin(at least for boot animation).
>
> Also solve some issues i meet during the bringup.
>
> Changes in v6:
> Don't change order of rockchip_drm_psr_register().
>
> Changes in v5:
> Call the de
Add the infrastructure to support the idea of multiple ringbuffers.
Assign each ringbuffer an id and use that as an index for the various
ring specific operations.
The biggest delta is to support legacy fences. Each fence gets its own
sequence number but the legacy functions expect to use a unique
In order to manage ringbuffer priority to its fullest userspace
should know how many ringbuffers it has to work with. Add a
parameter to return the number of active rings.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 3 +++
include/uapi/drm/msm_drm.h |
We use a global ringbuffer size and block size for all targets and
at least for 5XX preemption we need to know the value the RB_CNTL
in several locations so it makes sense to calculate it once and use
it everywhere.
The only monkey wrench is that we need to disable the RPTR shadow
for A430 targets
Currently the rd dump avoids any buffers marked as WRITE under
the assumption that the contents are not interesting. While it
is true that the contents are uninteresting we should still print
the iova and size for all buffers so that any listening replay
tools can correctly construct the submissio
Currently the behavior of a command stream is provided by the user
application during submission and the application is expected to internally
maintain the settings for each 'context' or 'rendering queue' and specify
the correct ones.
This works okay for simple cases but as applications become mor
(Resending for more visibility)
Here are the refreshed submitqueue/ringbuffer/preemption changes for 4.15.
These are the original changes with bug fixes, improvements and suggestions
squashed in:
- Moved SUBMITQUEUE_CLOSE param to a u32 instead of reusing the struct
- Changed to use per-ring f
On Fri, Oct 20, 2017 at 09:48:35AM +0800, Mark yao wrote:
> On 2017年10月19日 11:48, Jeffy Chen wrote:
> > Remove unnecessary init code, since we would do it in the power_on()
> > callback.
> >
> > Also move of parse code to probe().
> >
> > Fixes: 9e32e16e9e98 ("drm: rockchip: dp: add rockchip plat
On Thu, Oct 19, 2017 at 11:48:05AM +0800, Jeffy Chen wrote:
This patch has somehow lost it's original author. I assume this is not
intentional.
Sean
> The driver that instantiates the bridge should own the drvdata, as all
> driver model callbacks (probe, remove, shutdown, PM ops, etc.) are also
On Fri, Oct 20, 2017 at 05:44:15PM +0200, Noralf Trønnes wrote:
>
> Den 20.10.2017 15.52, skrev Ville Syrjälä:
> > On Fri, Oct 20, 2017 at 01:02:00AM +0200, Noralf Trønnes wrote:
> >> drm_fb_helper is *the* way of doing fbdev emulation so add a pointer to
> >> struct drm_device. This makes it poss
https://bugs.freedesktop.org/show_bug.cgi?id=103370
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #8 from
The feature implementation isn't stable yet. Reject any attempt to use
the IOCTLs for now. This keeps most of the code in place, so we can stabilize
it in-tree, but keeps userspace from using the feature for now.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 6 ++
1
The performance monitoring feature isn't stable enough yet, so don't advertise
it to userspace yet.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/et
Den 20.10.2017 15.52, skrev Ville Syrjälä:
On Fri, Oct 20, 2017 at 01:02:00AM +0200, Noralf Trønnes wrote:
drm_fb_helper is *the* way of doing fbdev emulation so add a pointer to
struct drm_device. This makes it possible to add callback helpers for
.last_close and .output_poll_changed further r
Generated using make headers_install from:
airlied/drm-next 282dc83 Merge tag 'drm-intel-next-2017-10-12' ...
Signed-off-by: Andres Rodriguez
---
include/drm/amdgpu_drm.h | 31 ++-
1 file changed, 30 insertions(+), 1 deletion(-)
diff --git a/include/drm/amdgpu_drm.h
Add a new context creation function that allows specifying the context
priority.
A high priority context has the potential of starving lower priority
contexts. The current kernel driver implementation allows only apps
that hold CAP_SYS_NICE or DRM_MASTER to acquire a priority above
AMDGPU_CTX_PRIO
https://bugzilla.kernel.org/show_bug.cgi?id=197327
--- Comment #2 from Alex (mad_...@bk.ru) ---
(In reply to Michel Dänzer from comment #1)
> (In reply to Alex from comment #0)
> > I have error message radeon :01:00.0: failed VCE resume (-110) in boot
> > time,
>
> That looks harmless.
I thi
https://bugzilla.kernel.org/show_bug.cgi?id=194761
--- Comment #88 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to yousifjkadom from comment #87)
Everything you say applies to the amdgpu kernel driver, but in the meantime,
your card should work with the radeon kernel driver. Doesn't it?
https://bugzilla.kernel.org/show_bug.cgi?id=194761
yousifjka...@yahoo.com changed:
What|Removed |Added
CC||yousifjka...@yahoo.com
--- Comme
https://bugs.freedesktop.org/show_bug.cgi?id=103370
Michel Dänzer changed:
What|Removed |Added
Attachment #134936|text/x-log |text/plain
mime type|
https://bugzilla.kernel.org/show_bug.cgi?id=196615
--- Comment #28 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 260307
--> https://bugzilla.kernel.org/attachment.cgi?id=260307&action=edit
possible fix
Does the attached patch fix the issue?
--
You are receiving this mail be
On Fri, Oct 20, 2017 at 01:02:00AM +0200, Noralf Trønnes wrote:
> drm_fb_helper is *the* way of doing fbdev emulation so add a pointer to
> struct drm_device. This makes it possible to add callback helpers for
> .last_close and .output_poll_changed further reducing fbdev emulation
> footprint in dr
Hi Dave,
drm-misc-next-2017-10-20:
Final drm-misc feature pull for 4.15:
UAPI Changes:
- new madvise ioctl for vc4 (Boris)
Core Changes:
- plane commit tracking fixes (Maarten)
- vgaarb improvements for fancy new platforms (aka ppc64 and arm64) by
Bjorn Helgaas
Driver Changes:
- pile of new p
On Fri, Oct 20, 2017 at 04:12:58PM +0300, Peter Ujfalusi wrote:
> If we have memory bandwidth limit configured, reject the modes which would
> require more bandwidth than the limit if it is used with one full
> resolution plane (most common use case).
>
> This filtering is not providing full prote
On Fri, Oct 20, 2017 at 01:02:00AM +0200, Noralf Trønnes wrote:
> drm_fb_helper is *the* way of doing fbdev emulation so add a pointer to
> struct drm_device. This makes it possible to add callback helpers for
> .last_close and .output_poll_changed further reducing fbdev emulation
> footprint in dr
On 10/20/2017 01:30 AM, Rob Clark wrote:
Since we enabled runtime PM, we cannot count on cursor registers to
retain their values. This can result in situations where we think the
cursor is enabled when we enable the CRTC but it is trying to scan out
null (and the rest of cursor position/size i
If we have memory bandwidth limit configured, reject the modes which would
require more bandwidth than the limit if it is used with one full
resolution plane (most common use case).
This filtering is not providing full protection as it is possible that
application would pick smaller crtc resolutio
The get_memory_bandwidth_limit() in dispc_ops can be used to query the
memory bandwidth limit of dispc by upper layers.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 13 +
drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 ++
2 files changed, 15 insertions(+)
di
max-memory-bandwidth can be used to specify the maximum bandwidth dispc
can use when reading display data from main memory.
In some SoC (am437x for example) we have memory bandwidth limitation
which causes underflow in the display subsystem.
Signed-off-by: Peter Ujfalusi
---
Documentation/devic
Hi,
This series will add simple memory bandwidth limit support to reject modes
which, if used with one plane in full size would fail the limit.
Regards,
Peter
---
Peter Ujfalusi (3):
dt-bindings: display/ti: Add optional property to set memory bandwidth
limit
drm/omap: dss: Add support fo
On 10/20/2017 05:47 PM, Rob Clark wrote:
It's only likely to paper over bugs. Unlike the gpu, where we want to
keep things alive a bit longer in expectation of the next frame's
submit, when the display is shut down we can power off immediately.
Acked-by: Archit Taneja
Signed-off-by: Rob
This extends the dumb VGA DAC bridge to handle the THS8134A
and THS8134B VGA DACs in addition to those already handled.
The THS8134A, THS8134B and as it turns out also THS8135 need to
have data clocked out at the negative edge of the clock pulse,
since they clock it into the DAC at the positive ed
Hi Dave,
The following changes since commit 9e66317d3c92ddaab330c125dfe9d06eee268aff:
Linux 4.14-rc3 (2017-10-01 14:54:54 -0700)
are available in the git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.15-rc1
for you to fetch changes up to fb83be8873909ba7c089
It's only likely to paper over bugs. Unlike the gpu, where we want to
keep things alive a bit longer in expectation of the next frame's
submit, when the display is shut down we can power off immediately.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/mdp/mdp5/mdp5_cmd_encoder.c | 2 +-
drive
https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #7 from Shih-Yuan Lee ---
Created attachment 134936
--> https://bugs.freedesktop.org/attachment.cgi?id=134936&action=edit
dmesg by drm.debug=0xe
The messages just before the system halt.
--
You are receiving this mail because:
Y
Hi Linus,
Thank you for the patch.
On Friday, 20 October 2017 09:59:41 EEST Linus Walleij wrote:
> This extends the dumb VGA DAC bridge to handle the THS8134A
> and THS8134B VGA DACs in addition to those already handled.
>
> The THS8134A, THS8134B and as it turns out also THS8135 need to
> have
https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #6 from Michel Dänzer ---
(In reply to Shih-Yuan Lee from comment #5)
> There is no problem under the battery mode, and because the system halts
> that makes unable to collect any dmesg.
Please attach dmesg captured in battery mode
https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #5 from Shih-Yuan Lee ---
There is no problem under the battery mode, and because the system halts that
makes unable to collect any dmesg.
$ DRI_PRIME=1 glxgears -info
Running sync
https://bugs.freedesktop.org/show_bug.cgi?id=103371
Bug ID: 103371
Summary: glxinfo -l shows GL_INVALID_ENUM
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: minor
https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #4 from Shih-Yuan Lee ---
Sorry. I pasted wrong logs.
GL_VERSION should be "3.0 Mesa 17.0.7" instead.
(In reply to Shih-Yuan Lee from comment #3)
> Using DRI_PRIME=0 is just to switch between Intel and AMD Graphics.
> Of course, we
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head: 2b14e1f4fded74b9efeb990869076cebb06d27ee
commit: c5a743365208938dae80f1cca8df9c370ba54292 [1811/2206] drm/amdkfd: fix in
tree build
reproduce:
# apt-get install sparse
git checkout c5a743365208938da
https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #3 from Shih-Yuan Lee ---
Using DRI_PRIME=0 is just to switch between Intel and AMD Graphics.
Of course, we can omit it completely.
The system halt issue happens when executing `DRI_PRIME=1 glxgears -info`.
u@u:~$ DRI_PRIME=1 glxge
https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #2 from Shih-Yuan Lee ---
If I executed the command under battery mode, it won't halt the system.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel ma
https://bugs.freedesktop.org/show_bug.cgi?id=103370
--- Comment #1 from Michel Dänzer ---
Please attach the corresponding dmesg output.
(In reply to Shih-Yuan Lee from comment #0)
> While I am doing the tests with AC plugged in by `DRI_PRIME=1 glxgears
> -info` and `DRI_PRIME=0 glxgears -info`,
Hi, Matthias:
On Thu, 2017-10-19 at 13:26 +0200, Matthias Brugger wrote:
> DRM subysystem and clock driver shared the same compatible mmsys.
> This stopped does not work, as only the first driver for a compatible
> gets probed. We change the comaptible to the new DRM identifier to fix
> this.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=103370
Bug ID: 103370
Summary: `DRI_PRIME=1 glxgears -info` halts the system with
Intel Graphics [8086:5917] + AMD Graphics [1002:6665].
Product: DRI
Version: XOrg git
Hardware:
https://bugzilla.kernel.org/show_bug.cgi?id=197327
--- Comment #1 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Alex from comment #0)
> I have error message radeon :01:00.0: failed VCE resume (-110) in boot
> time,
That looks harmless.
> and i think my discrette card Radeon HD 875
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head: 2b14e1f4fded74b9efeb990869076cebb06d27ee
commit: b7f99b04c37bbf0a5690d87d460792633fa2a9fb [1335/2206] radeon_kfd.c copied
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 201609
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-4.13
head: e16e1739c334c1e3a180402c7e30391f6de8ddf2
commit: e0b811b5fa55f01f4b647b676e6ab9ff4ea033fd [995/1265] drm/amd/display:
remove DCN1 guard as DCN1 is already open sourced.
config: arm-allmodconfig (attached as .config)
com
Document the bindings used for the Cadence DSI bridge.
Signed-off-by: Boris Brezillon
---
Hi Rob,
I dropped your A-b because two important things changed in this
version:
* the clk names have changed (they are now prefixed with dsi_)
* compatible no longer contains the IP version
Feel free to a
Add a driver for Cadence DPI -> DSI bridge.
This driver only support a subset of Cadence DSI bridge capabilities.
Here is a non-exhaustive list of missing features:
* burst mode
* dynamic configuration of the DPHY based on the
* support for additional input interfaces (SDI input)
Signed-off-b
On 10/19/2017 03:06 PM, Philipp Zabel wrote:
> On Thu, 2017-10-19 at 15:53 +0300, Laurent Pinchart wrote:
>> Hi Matthias,
>>
>> Thank you for the patch.
>>
>> On Thursday, 19 October 2017 14:26:07 EEST Matthias Brugger wrote:
>>> DRM subysystem and clock driver shared the same compatible mmsys.
>
HI Thierry,
> On Fri, Sep 08, 2017 at 11:43:02AM +0200, Lukasz Majewski wrote:
> > This commit adds support for Mitsubishi aa070mc01 TFT panel working
> > with 8 bit ISP mode (pin 19 "mode" HIGH for 20 pin TFT connector).
> >
> > Signed-off-by: Lukasz Majewski
> > ---
> > drivers/gpu/drm/panel/
Hi Tomi,
Looks like omapdrm won't show anything with current Linux next based
on my test with 900:
modprobe twl4030_keypad
modprobe tsc2005
modprobe omapdss
modprobe panel_sony_acx565akm
modprobe omapdrm
echo 255 > /sys/class/backlight/acx565akm/brightness
echo 0 > /sys/class/graphics/fb0/blank
On Tue, Oct 17, 2017 at 6:36 PM, wrote:
> static int overlay_notify(struct overlay_changeset *ovcs,
> enum of_overlay_notify_action action)
> {
> @@ -86,8 +109,14 @@ static int overlay_notify(struct overlay_changeset *ovcs,
>
> ret = blocking_notifier_call_chain
On 10/19/2017 02:19 PM, Ryder Lee wrote:
> Hi Matthias,
>
> Should I base on your changes and resend this patch series
> https://patchwork.kernel.org/patch/9980061/ ?
>
> I add a similar node - display_components, but your approach is better
> than mine.
>
You series should have the same issu
On 10/19/17 12:04, Alan Tull wrote:
> On Tue, Oct 17, 2017 at 6:36 PM, wrote:
>
>> static int overlay_notify(struct overlay_changeset *ovcs,
>> enum of_overlay_notify_action action)
>> {
>> @@ -86,8 +109,14 @@ static int overlay_notify(struct overlay_changeset *ovcs,
>>
>>
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-dkms-4.13
head: 2b14e1f4fded74b9efeb990869076cebb06d27ee
commit: 521a9dac01416576acda468261e9e6902e59bac5 [1333/2206] port in all files
config: i386-allmodconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
This extends the dumb VGA DAC bridge to handle the THS8134A
and THS8134B VGA DACs in addition to those already handled.
The THS8134A, THS8134B and as it turns out also THS8135 need to
have data clocked out at the negative edge of the clock pulse,
since they clock it into the DAC at the positive ed
77 matches
Mail list logo
