Am 13.07.2018 um 04:37 schrieb Sinclair Yeh:
On Mon, Jul 09, 2018 at 10:24:47AM -0500, Gustavo A. R. Silva wrote:
Make use of the swap macro and remove unnecessary variable *tmp_mem*.
This makes the code easier to read and maintain. Also, reduces the
stack usage.
This code was detected with the
https://bugs.freedesktop.org/show_bug.cgi?id=107082
--- Comment #4 from mikhail.v.gavri...@gmail.com ---
(In reply to Harry Wentland from comment #3)
> Created attachment 140594 [details] [review]
> [PATCH] drm/amd/display: Convert 10kHz clks from PPLib into kHz for Vega
>
> Don't think the other
On Mon, Jul 09, 2018 at 10:24:47AM -0500, Gustavo A. R. Silva wrote:
> Make use of the swap macro and remove unnecessary variable *tmp_mem*.
> This makes the code easier to read and maintain. Also, reduces the
> stack usage.
>
> This code was detected with the help of Coccinelle.
>
> Signed-off-b
Hi all,
[Dave cc'd because this will probably turn up in the drm tree soon.]
After merging the drm-intel tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/i915/gvt/kvmgt.c: In function 'gvt_dma_map_page':
drivers/gpu/drm/i915/gvt/kvmgt.c:188:17: error: 'pfn'
https://bugs.freedesktop.org/show_bug.cgi?id=107213
Bug ID: 107213
Summary: [amdgpu/DisplayPort] KDE Wayland session is
segfaulting right after login
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #44 from Thomas Martitz ---
Disabling runtime pm probably result in poor battery life, right? This is a
laptop with hybrid graphics afterall and the radeon should be disabled most of
the time.
Is there anything I can try? Like check
https://bugs.freedesktop.org/show_bug.cgi?id=107153
--- Comment #8 from Leo Li ---
Thanks for filing the ticket Patrik, can you please give the attached two
patches a shot? I cp'ed them over 4.18-rc3 and they seem to fix it for me.
--
You are receiving this mail because:
You are the assignee fo
https://bugs.freedesktop.org/show_bug.cgi?id=107153
--- Comment #7 from Leo Li ---
Created attachment 140614
--> https://bugs.freedesktop.org/attachment.cgi?id=140614&action=edit
Patch 2/2
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=107153
--- Comment #6 from Leo Li ---
Created attachment 140613
--> https://bugs.freedesktop.org/attachment.cgi?id=140613&action=edit
Patch 1/2
--
You are receiving this mail because:
You are the assignee for the bug.___
DPU is short for the Display Processing Unit. It is the display
controller on Qualcomm SDM845 chips.
While the dts is pretty sparse for sdm845 atm, the only piece
we're missing is the iommu. It's commented out for now, and should be
uncommented once support is provided.
Changes in v2:
- Beefed u
From: Jeykumar Sankaran
Adds bindings for Snapdragon 845 display processing unit
Changes in v2:
- Use SoC specific compatibles for mdss and dpu
- Use assigned-clocks to set initial clock frequency
Signed-off-by: Jeykumar Sankaran
Signed-off-by: Rajesh Yadav
Signed-off-by: Sean Paul
---
..
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #43 from Alex Deucher ---
It's fine to have one of the patches to stop the segfault applied. that's just
a symptom of the root cause:
[ 54.734549] amdgpu :01:00.0: Refused to change power state, currently in
D3
[ 54.810069]
On Thu, Jul 12, 2018 at 01:24:19PM -0400, Lyude Paul wrote:
> This is something we've needed for a very long time now, as it makes
> debugging issues with faulty MST hubs along with debugging issues
> regarding us interfacing with hubs correctly vastly easier to debug.
> Currently this can actually
On Thu, Jul 12, 2018 at 12:59:27PM -0600, Jordan Crouse wrote:
> Convert the format of the 'show' debugfs file and the crash
> dump to a format resembling YAML. This should be easier to
> parse and be more flexible for future changes and expansions.
>
> Signed-off-by: Jordan Crouse
> ---
> Docu
On Thu, Jul 12, 2018 at 12:59:20PM -0600, Jordan Crouse wrote:
> Add drm_puts() for a much faster path to print constant strings
> into a drm_printer object with memcpy and friends. This can
> shave seconds off of really large outputs such as GPU dumps.
>
> If the drm_printer object supports a cus
Quoting Jordan Crouse (2018-07-12 19:59:25)
> Do a bit of cleanup to prepare for upcoming changes to pass the
> hanging task comm and cmdline to the crash dump function.
>
> Signed-off-by: Jordan Crouse
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 18 ++
> 1 file changed, 10 insertion
On Thu, Jul 12, 2018 at 12:59:21PM -0600, Jordan Crouse wrote:
> Add a puts() function to use seq_puts() to help speed up
> up print time for constant strings.
>
> Signed-off-by: Jordan Crouse
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_print.c | 6 ++
> include/drm/drm_print.h
Quoting Jordan Crouse (2018-07-12 19:59:24)
> Convert the existing GPU show function to use the GPU state to
> dump the information rather than reading it directly from the hardware.
> This will require an additional step to capture the state before
> dumping it for the existing nodes but it will g
On Thu, Jul 12, 2018 at 12:59:19PM -0600, Jordan Crouse wrote:
> Add a drm printer suitable for use with the read callback for
> devcoredump or other suitable buffer based output format that
> isn't otherwise covered by seq_file.
>
> Signed-off-by: Jordan Crouse
Hm, why not add seq_file support t
Quoting Jordan Crouse (2018-07-12 19:59:22)
> Add a put function for the coredump printer to bypass printf()
> for constant strings for a speed boost.
>
> v2: Add EXPORT_SYMBOL for _drm_puts_coredump
> Signed-off-by: Jordan Crouse
> ---
> drivers/gpu/drm/drm_print.c | 43
Quoting Jordan Crouse (2018-07-12 19:59:19)
> Add a drm printer suitable for use with the read callback for
> devcoredump or other suitable buffer based output format that
> isn't otherwise covered by seq_file.
>
> Signed-off-by: Jordan Crouse
> ---
> drivers/gpu/drm/drm_print.c | 74 +++
https://bugs.freedesktop.org/show_bug.cgi?id=105760
Thomas Martitz changed:
What|Removed |Added
Attachment #140592|0 |1
is obsolete|
Quoting Jordan Crouse (2018-07-12 19:59:18)
> The i915 DRM driver very cleverly used ascii85 encoding for their
> GPU state file. Move the encode functions to a general header file to
> support other drivers that might be interested in the same
> functionality.
>
> v3: Fix error_puts -> err_puts p
For hangs, dump copy out the contents of the buffer objects attached to the
guilty submission and print them in the crash dump report.
v2: Use %zd to print the size of the buffer correctly
Signed-off-by: Jordan Crouse
---
Documentation/gpu/drm-msm-crash-dump.txt | 7 +++
drivers/gpu/drm/msm/ad
Capture the GPU state on a GPU hang and store it for later playback
via the devcoredump facility. Only one crash state is stored at a
time on the assumption that the first hang is usually the most
interesting. The existing crash state can be cleared after capturing
it and then a new one will be cap
Convert the format of the 'show' debugfs file and the crash
dump to a format resembling YAML. This should be easier to
parse and be more flexible for future changes and expansions.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/drm-msm-crash-dump.txt | 46
drivers/g
Do a bit of cleanup to prepare for upcoming changes to pass the
hanging task comm and cmdline to the crash dump function.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm
Convert the existing GPU show function to use the GPU state to
dump the information rather than reading it directly from the hardware.
This will require an additional step to capture the state before
dumping it for the existing nodes but it will greatly facilitate reusing
the same code for dumping
HLSQ, SP and TP registers are only accessible from a special
aperture and to make matters worse the aperture is blocked from
the CPU on targets that can support secure rendering. Luckily the
GPU hardware has its own purpose built register dumper that can
access the registers from the aperture. Add
Add the contents of each ringbuffer to the GPU state and dump the
data in the crash file encoded with ascii85. To save space only
the used portions of the ringbuffer are dumped.
Signed-off-by: Jordan Crouse
---
Documentation/gpu/drm-msm-crash-dump.txt | 5 +++
drivers/gpu/drm/msm/adreno/adreno_
Add a put function for the coredump printer to bypass printf()
for constant strings for a speed boost.
v2: Add EXPORT_SYMBOL for _drm_puts_coredump
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 43 +
include/drm/drm_print.h | 2 ++
2 file
Add a drm printer suitable for use with the read callback for
devcoredump or other suitable buffer based output format that
isn't otherwise covered by seq_file.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 74 +
include/drm/drm_print.h |
The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.
v3: Fix error_puts -> err_puts pointed out by the 01.org bot
v2: Update API to be cleane
This is revision t implementing a GPU crash state for drm/msm
(https://patchwork.freedesktop.org/series/36097/). This patchset fixes a
few things that the build bot found.
The object of this code is to store and provide enough information to debug
software and hardware issues on the Adreno hardwar
Add drm_puts() for a much faster path to print constant strings
into a drm_printer object with memcpy and friends. This can
shave seconds off of really large outputs such as GPU dumps.
If the drm_printer object supports a custom puts function then
use that otherwise fall back to the slower legacy
Add a puts() function to use seq_puts() to help speed up
up print time for constant strings.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/drm_print.c | 6 ++
include/drm/drm_print.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/drm_print.c b/drivers/gpu/drm/d
Add the infrastructure to capture the current state of the GPU and
store it in memory so that it can be dumped later.
For now grab the same basic ringbuffer information and registers
that are provided by the debugfs 'gpu' node but obviously this should
be extended to capture a much larger set of G
Nayan Deshmukh writes:
> diff --git a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> index 3dc1a4f07e3f..b2dbd1c1ba69 100644
> --- a/drivers/gpu/drm/scheduler/gpu_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/gpu_scheduler.c
> @@ -162,26 +162,32 @@ drm_s
Nayan Deshmukh writes:
> Signed-off-by: Nayan Deshmukh
> ---
Acked-by: Eric Anholt
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=107183
--- Comment #5 from Paul Menzel ---
Michel, Chris, I just noticed, that the delay is only there when starting the
X.Org X server for the first time. Could you please make sure, that your
systems are rebooted when trying this?
(During my tests I
This is something we've needed for a very long time now, as it makes
debugging issues with faulty MST hubs along with debugging issues
regarding us interfacing with hubs correctly vastly easier to debug.
Currently this can actually be done if you trace the i2c devices for DP
using ftrace but that's
On Thu, Jul 12, 2018 at 01:10:45PM -0400, Lyude Paul wrote:
> This hooks up the DRM helpers for dumping information on the current
> status of each MST topology from nouveau's perspective to debugfs files,
> similar to what i915 does (albeit, i915 labels their debugfs node for
> this as i915_dp_mst
On Thu, Jul 12, 2018 at 01:02:54PM -0400, Lyude Paul wrote:
> This both uses the legacy modesetting structures in a racy manner, and
> additionally also doesn't even check the right variable (enabled != the
> CRTC is actually turned on for atomic).
>
> This fixes issues on my P50 regarding the ded
This makes debugging with DP tracing a lot harder to interpret, so name
each i2c based off the name of the encoder that it's for
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
drivers/gpu/drm/nouveau/nouveau
On 07/09/2018 10:20 AM, Arnd Bergmann wrote:
This tinydrm driver fails to link without the backlight support:
drivers/gpu/drm/tinydrm/ili9341.o: In function `ili9341_probe':
ili9341.c:(.text+0x578): undefined reference to `devm_of_find_backlight'
Fixes: 3fa0e8f6f960 ("drm/tinydrm: new driver fo
This is very useful for checking what nouveau thinks the current state
of each MST topology looks like.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/nouveau_debugfs.c | 47 ++-
1 file changed, 45 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nou
We're about to need this so that we can hook up dp_mst_info into debugfs
so we can walk the encoder list and find each mst mgr.
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 34
drivers/gpu/drm/nouveau/dispnv50/disp.h | 35 ++
This hooks up the DRM helpers for dumping information on the current
status of each MST topology from nouveau's perspective to debugfs files,
similar to what i915 does (albeit, i915 labels their debugfs node for
this as i915_dp_mst_info).
Lyude Paul (2):
drm/nouveau: Expose nv50 MST structures i
On Fri, Jul 06, 2018 at 06:47:32PM +0200, Jernej Skrabec wrote:
> Initial implementation of DE2 planes only supported fixed zpos.
>
> Expand implementation with configurable zpos property.
>
> Implementation background:
> Channel in DE2 driver represents one DRM plane, whereas pipe is just
> mapp
This both uses the legacy modesetting structures in a racy manner, and
additionally also doesn't even check the right variable (enabled != the
CRTC is actually turned on for atomic).
This fixes issues on my P50 regarding the dedicated GPU not entering
runtime suspend.
Signed-off-by: Lyude Paul
C
A CRTC being enabled doesn't mean it's on! It doesn't even necessarily
mean it's being used. This fixes runtime PM leaks on the P50 I've got
next to me.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 2 +-
1 file changed, 1 insertion(+), 1 dele
Noticed this as I was skimming through, if we fail to allocate memory
for cli we'll end up returning without dropping the runtime PM ref we
got. Additionally, we'll even return the wrong return code! (ret most
likely will == 0 here, we want -ENOMEM).
Signed-off-by: Lyude Paul
Reviewed-by: Lukas W
This is the latest version of
https://patchwork.freedesktop.org/series/45862/ . One new patch has been
added that also addresses some additional issues I found with
pmops_runtime_idle that would stop nouveau from suspending the GPU when
running under X.
Additionally,
"drm/nouveau: Fix runtime PM l
On Thu, Jul 12, 2018 at 10:35:08AM +0200, Daniel Vetter wrote:
> On Thu, Jul 12, 2018 at 10:08:18AM +0200, Maxime Ripard wrote:
> > When commit af11942ee44e ("drm/sun4i: tcon-top: Cleanup clock handling")
> > was merged, the error handling path of the of_property_match_string was
> > changed to tak
https://bugs.freedesktop.org/show_bug.cgi?id=107209
Bug ID: 107209
Summary: DM_PPLIB causes a warning on Raven
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
P
Hi Uma,
On Tue, Jun 12, 2018 at 04:01:31AM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
> >Alexandru-Cosmin Gheorghe
> >Sent: Monday, June 11, 2018 3:47 PM
> >To: Shankar, Uma
> >Cc: dcasta...@chrom
We're returning -errno instead of ERR_PTR(-errno).
Fixes: af11942ee44e ("drm/sun4i: tcon-top: Cleanup clock handling")
Cc: Chen-Yu Tsai
Cc: Jernej Skrabec
Cc: Maxime Ripard
Cc: dri-devel@lists.freedesktop.org
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: Sean Paul
---
drivers/gpu/dr
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #35 from Andrea Vettorello ---
Sorry for the spam, I thought the two attachments would be inserted in the same
comment.
I think I'm afflicted by the same bug on different HW (Asrock AB350 ixt, Ryzen
5 2400G), Debian Stretch running
On Thu, 2018-07-12 at 07:54 -0600, Jens Axboe wrote:
>
> Thanks for your invaluable and useful feedback, sharing your vast
> experience in patchsets with dependencies.
I've probably more experience sending patchsets
with dependencies across subsystems than anyone.
There is no single style that w
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #34 from Andrea Vettorello ---
Created attachment 140597
--> https://bugs.freedesktop.org/attachment.cgi?id=140597&action=edit
relevant kernel 4.17.5 source of the oops
--
You are receiving this mail because:
You are the assignee
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann
Acked-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drv.c | 8
1 file change
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #33 from Andrea Vettorello ---
Created attachment 140596
--> https://bugs.freedesktop.org/attachment.cgi?id=140596&action=edit
relevant kernel 4.17.5 log of the oops
--
You are receiving this mail because:
You are the assignee fo
This fixes a static checker warning:
drivers/gpu/drm/drm_client.c:289 drm_client_buffer_create()
error: double free of 'buffer'
Extend drm_client_buffer_delete() to handle the case when there's no
dumb buffer attached and drop the extra kfree.
Fixes: c76f0f7cb546 ("drm: Begin an
On Tuesday 10 July 2018 02:18 AM, Sean Paul wrote:
On Wed, Jun 27, 2018 at 02:10:02PM +0530, Ramalingam C wrote:
Implements a sequence of enabling and disabling the HDCP2.2
(auth and encryption).
This is really hard to review, since all I see are stubs. I'd much rather have
each patch do some
On Tuesday 10 July 2018 02:01 AM, Sean Paul wrote:
On Wed, Jun 27, 2018 at 02:09:55PM +0530, Ramalingam C wrote:
For upcoming implementation of HDCP2.2 in I915, important variable
required for HDCP2.2 are defined.
Please just introduce them when you use them. I can't provide useful review on
On Tuesday 10 July 2018 02:14 AM, Sean Paul wrote:
On Wed, Jun 27, 2018 at 02:10:01PM +0530, Ramalingam C wrote:
When HDCP2.2 enabling fails and HDCP1.4 is supported, HDCP1.4 is
enabled.
Just squash this into patch 11, no need for a separate patch.
Doing it in the next version of the series
On Tuesday 10 July 2018 02:14 AM, Sean Paul wrote:
On Wed, Jun 27, 2018 at 02:10:00PM +0530, Ramalingam C wrote:
Considering that HDCP2.2 is more secure than HDCP1.4, When a setup
supports HDCP2.2 and HDCP1.4, HDCP2.2 will be enabled.
v2:
Included few optimization suggestions [Chris Wilson
On Thu, Jul 12, 2018 at 10:41:02AM -0300, Rodrigo Siqueira wrote:
> This patch appends the minimum helpers related to framebuffer and plane
> to make vkms minimally usable.
>
> Changes since V1:
> - None
> Changes since V2:
> - Squash "Add plane helper struct" and "Add helper for framebuffer
> c
https://bugs.freedesktop.org/show_bug.cgi?id=104611
--- Comment #9 from Vedran Miletić ---
Created attachment 140595
--> https://bugs.freedesktop.org/attachment.cgi?id=140595&action=edit
dmesg with fiji amdgpu.dc_log=1
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=104611
--- Comment #8 from Vedran Miletić ---
This still occurs on 4.17, despite bug 106194 suggesting otherwise:
[ 7670.095885] BUG: unable to handle kernel NULL pointer dereference at
0208
[ 7670.095899] PGD 8003fcee8067 P4D 8003
On Thu, Jul 12, 2018 at 03:55:26PM +0200, Dominique Martinet wrote:
> Ville Syrjälä wrote on Thu, Jul 12, 2018:
> > On Wed, Jul 11, 2018 at 09:46:15AM +0200, Dominique Martinet wrote:
> > > This is effectively no-op as the next line writes a nul at the final
> >
> > What is "This". Please write se
On Mon, Jul 09, 2018 at 10:40:05AM +0200, Daniel Vetter wrote:
> - switch everything over to inline comments
> - add notes about locking, links to functions and other related stuff
> - also include a note about Ville's soon-to-be-merged
> drm_connector_for_each_possible_encoder().
>
> Also check
https://bugs.freedesktop.org/show_bug.cgi?id=107082
--- Comment #3 from Harry Wentland ---
Created attachment 140594
--> https://bugs.freedesktop.org/attachment.cgi?id=140594&action=edit
[PATCH] drm/amd/display: Convert 10kHz clks from PPLib into kHz for Vega
Don't think the other patch would
On Mon, Jul 09, 2018 at 10:40:04AM +0200, Daniel Vetter wrote:
> For consistency. Also spelled out the docs for ->best_encoder a bit
> more while at it.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Sean Paul
> ---
> include/drm/drm_connector.h | 14 ++
> 1 file changed, 10 insert
Am Donnerstag, den 12.07.2018, 16:37 +0300 schrieb Leonard Crestez:
> The imx6sl soc has gpu_2d and gpu_vg, no 3d support:
>
> etnaviv-gpu 220.gpu: model: GC320, revision: 5007
> etnaviv-gpu 2204000.gpu: model: GC355, revision: 1215
>
> The IP blocks are close enough to supported hardware tha
On Mon, Jul 09, 2018 at 10:40:03AM +0200, Daniel Vetter wrote:
> Only needed minimal changes in drm_internal.h (for the drm_ioctl_t
> type and a few forward declarations), plus a few missing includes in
> drm_connector.c.
>
> Yay, the last stage of the drm header cleanup can finally commence!
>
>
On Mon, Jul 09, 2018 at 10:40:02AM +0200, Daniel Vetter wrote:
> Last bit the prevented us from starting to delete the drmP.h monster
> includes from source files!
>
> Also add kernel-doc while moving them.
>
> A nice consistent drm_dev_ prefix would be cute for these, but since
> they're used ev
On Mon, Jul 09, 2018 at 10:40:16AM +0200, Daniel Vetter wrote:
> This is starting to become easy!
>
> Note: This needs the patch to move for_each_if from drmP.h to kernel.h
> or it won't compile.
>
> Signed-off-by: Daniel Vetter
Once for_each_if gets sorted out (however it goes).
Reviewed-by:
On 12.07.2018 15:03, Leonard Crestez wrote:
> On Thu, 2018-07-12 at 11:21 +0200, Stefan Agner wrote:
>> On 10.07.2018 11:11, Marek Vasut wrote:
>> > On 07/10/2018 11:06 AM, Stefan Agner wrote:
>> > > This is one of the situation where states quo is kinda the worst
>> > > situation.
>> > >
>> > > Cu
Hi Leonard,
On Thu, Jul 12, 2018 at 10:37 AM, Leonard Crestez
wrote:
> diff --git a/arch/arm/boot/dts/imx6sl.dtsi b/arch/arm/boot/dts/imx6sl.dtsi
> index a6bc21433839..49a56b4fd393 100644
> --- a/arch/arm/boot/dts/imx6sl.dtsi
> +++ b/arch/arm/boot/dts/imx6sl.dtsi
> @@ -130,10 +130,30 @@
>
This commit adds regular vblank events simulated through hrtimers, which
is a feature required by VKMS to mimic real hardware. Additionally, all
the vblank event send after pageflip is kept in the atomic_flush
function.
Changes since V1:
- Compute the vblank timer interval per interruption
Ville
VKMS currently does not handle dumb data, and as a consequence, it does
not provide mechanisms for handling gem. This commit adds the necessary
support for gem object/handler and the dumb functions.
Changes since V1:
Daniel Vetter:
- Add dumb buffer support to the same patchset
Changes since V2:
This patch appends the minimum helpers related to framebuffer and plane
to make vkms minimally usable.
Changes since V1:
- None
Changes since V2:
- Squash "Add plane helper struct" and "Add helper for framebuffer
create"
Changes since V3:
Daniel Vetter:
- Remove atomic_check from plane helper
This patch adds the struct drm_connector_helper_funcs with some
necessary hooks. Additionally, it also adds some missing hooks at
drm_connector_funcs.
Changes since V1:
- None
Changes since V2:
Daniel Vetter:
- Remove vkms_conn_mode_valid
Changes since V3:
- None
Signed-off-by: Rodrigo Siqueira
Currently, we are working to make VKMS pass in the kms_flip test (IGT).
As a result, we made a series of changes in the module with the goal to
meet some of the necessary steps required by kms_flip. This patchset
comprises all the modifications needed to make kms_flip partially pass.
Finally, this
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #41 from Alex Deucher ---
(In reply to Thomas Martitz from comment #40)
> Further investigations show that toc->num_entires and toc->structure_version
> are set to -1 after the first call to smu7_request_smu_load_fw(). Does that
> ma
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #40 from Thomas Martitz ---
Further investigations show that toc->num_entires and toc->structure_version
are set to -1 after the first call to smu7_request_smu_load_fw(). Does that
makes sense?
Since you say the GPU does not properl
On Thu, 12 Jul 2018 09:29:38 -0400
Steven Rostedt wrote:
> From: Steven Rostedt (VMware)
>
> There's been discussion on the fb list about the addition of
> WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when
> the fb module is loaded with lockless_register_fb the console lock
From: Steven Rostedt (VMware)
There's been discussion on the fb list about the addition of
WARN_CONSOLE_UNLOCKED() inside the fb code. The complaint is that when
the fb module is loaded with lockless_register_fb the console lock is
not taken for debugging reasons. With the addition of
WARN_CONSO
https://bugs.freedesktop.org/show_bug.cgi?id=105760
Alex Deucher changed:
What|Removed |Added
Attachment #140584|0 |1
is obsolete|
On Thu, Jul 12, 2018 at 11:18:40AM +0200, Noralf Trønnes wrote:
> This fixes a static checker warning:
>
> drivers/gpu/drm/drm_client.c:289 drm_client_buffer_create()
> error: double free of 'buffer'
>
> drm_client_buffer_delete() frees the buffer so remove the extra free.
>
> Fixes:
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #38 from Alex Deucher ---
(In reply to Thomas Martitz from comment #36)
> Created attachment 140591 [details] [review]
> workaround without memcpy
>
> I made the following patch as an alternative workaround. The printks I added
> in
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #37 from Thomas Martitz ---
Created attachment 140592
--> https://bugs.freedesktop.org/attachment.cgi?id=140592&action=edit
dmesg with 0001-workaround-v2.patch
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105760
--- Comment #35 from Alex Deucher ---
Created attachment 140590
--> https://bugs.freedesktop.org/attachment.cgi?id=140590&action=edit
use gtt for firmware buffers
I still don't understand what's corrupting the cpu pointer. Ultimately, it
loo
https://bugs.freedesktop.org/show_bug.cgi?id=105760
Thomas Martitz changed:
What|Removed |Added
Attachment #140560|0 |1
is obsolete|
On Thu, Jul 12, 2018 at 01:54:07PM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Thu, Jul 12, 2018 at 03:37:36PM +0300, Ville Syrjälä wrote:
> > On Thu, Jul 12, 2018 at 09:48:56AM +0100, Alexandru Gheorghe wrote:
> > > Set possible_clones field to report that the writeback connector and
> > > the on
On Thu, Jul 12, 2018 at 10:20:35AM +0100, Alexandru-Cosmin Gheorghe wrote:
> On Thu, Jul 12, 2018 at 10:55:47AM +0200, Daniel Vetter wrote:
> > On Thu, Jul 12, 2018 at 09:48:02AM +0100, Alexandru Gheorghe wrote:
> > > Writeback connector is reported as disconnected, currently this causes
> > > the
On 12/07/18 14:42, Neil Armstrong wrote:
> Hi Lee,
>
> On 12/07/2018 14:26, Lee Jones wrote:
>> On Wed, 04 Jul 2018, Neil Armstrong wrote:
>>
>>> Hi All,
>>>
>>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
>>> through it's Embedded Controller, to enable the Linux CEC C
On Thu, Jul 12, 2018 at 03:37:36PM +0300, Ville Syrjälä wrote:
> On Thu, Jul 12, 2018 at 09:48:56AM +0100, Alexandru Gheorghe wrote:
> > Set possible_clones field to report that the writeback connector and
> > the one driving the display could be enabled at the same time.
> >
> > Signed-off-by: Al
https://bugs.freedesktop.org/show_bug.cgi?id=107204
Bug ID: 107204
Summary: GPU hang (ring gfx timeout) in OpenGL game
Product: Mesa
Version: git
Hardware: All
OS: All
Status: NEW
Severity: normal
1 - 100 of 158 matches
Mail list logo
