https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #4 from Alexander Mezin ---
(In reply to Alex Deucher from comment #3)
> More likely a bug in the mesa OpenCL code. If you want functional OpenCL,
> you should use the ROCm OpenCL packages.
I thought that buggy userspace shouldn't
https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #3 from Alex Deucher ---
More likely a bug in the mesa OpenCL code. If you want functional OpenCL, you
should use the ROCm OpenCL packages.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=110637
Alex Deucher changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Gallium/radeonsi
Prod
https://bugs.freedesktop.org/show_bug.cgi?id=110641
--- Comment #6 from Bong Cosca ---
So does it make sense to expose VDDGFX and VDDNB at all? Or should this be
fixed in lm_sensors?
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #2 from Alexander Mezin ---
Other examples: Luxmark, Geekbench (`./geekbench4 --compute`)
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing li
https://bugs.freedesktop.org/show_bug.cgi?id=110637
Alexander Mezin changed:
What|Removed |Added
Summary|Enabling OpenCL in |Any OpenCL application
https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #1 from Alexander Mezin ---
And the same thing with 4.19.40. And with manually built drm-next.
Also, not only libreoffice, but literally any application that uses OpenCL
triggers the same problem. It seems that I just can't use Open
Dave,
On Wed, May 8, 2019 at 8:28 PM Dave Airlie wrote:
>
> This is the main drm pull request for 5.2.
Thanks. I've merged it, but I got a couple of conflicts with fixes
(reverts) to mainline in the meantime.
The one to the i915 driver you seem to have applied again (after the
function was move
The pull request you sent on Thu, 9 May 2019 13:28:07 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2019-05-09
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a2d635decbfa9c1e4ae15cb05b68b2559f7f827c
Thank you!
--
Deet-doot-dot, I am a bot.
https://kor
https://bugs.freedesktop.org/show_bug.cgi?id=110641
--- Comment #5 from Alex Deucher ---
(In reply to Bong Cosca from comment #4)
> AMD A6-7400K Radeon R5
No hwmon support for voltage on that family.
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=110641
--- Comment #4 from Bong Cosca ---
AMD A6-7400K Radeon R5
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://l
On Wed, May 08, 2019 at 07:13:59PM -0700, Frank Rowand wrote:
> > If you want to use vice grips as a hammer, screwdriver, monkey wrench,
> > etc. there's nothing stopping you from doing that. But it's not fair
> > to object to other people who might want to use better tools.
> >
> > The reality
https://bugs.freedesktop.org/show_bug.cgi?id=110472
--- Comment #4 from gpiza...@javaman.net ---
(In reply to Timothy Arceri from comment #3)
> It would be helpful if you were able to get an apitrace [1] of the problem.
>
> [1] https://github.com/apitrace/apitrace
Thank you for replying!
My api
https://bugs.freedesktop.org/show_bug.cgi?id=110472
--- Comment #3 from Timothy Arceri ---
It would be helpful if you were able to get an apitrace [1] of the problem.
[1] https://github.com/apitrace/apitrace
--
You are receiving this mail because:
You are the assignee for the bug._
On Wed, May 8, 2019 at 7:16 PM Brian Masney wrote:
>
> On Mon, May 06, 2019 at 11:39:02PM -0700, Bjorn Andersson wrote:
> > On Sun 05 May 06:04 PDT 2019, Brian Masney wrote:
> > > diff --git a/arch/arm/boot/dts/qcom-msm8974.dtsi
> > > b/arch/arm/boot/dts/qcom-msm8974.dtsi
> > [..]
> > > +
https://bugs.freedesktop.org/show_bug.cgi?id=110635
--- Comment #1 from Timothy Arceri ---
Looks like it might be the same as bug #110575.
Do either of these go away when you run steam with the following:
R600_DEBUG=zerovram steam
Or setting the launch options for the game in steam to:
R600_D
https://bugs.freedesktop.org/show_bug.cgi?id=110641
--- Comment #3 from Alex Deucher ---
What chip do you have? Voltage hwmon is not implemented on all APUs.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel maili
On Wed, May 08, 2019 at 05:43:35PM -0700, Frank Rowand wrote:
> kselftest provides a mechanism for in-kernel tests via modules. For
> example, see:
>
> tools/testing/selftests/vm/run_vmtests invokes:
> tools/testing/selftests/vm/test_vmalloc.sh
> loads module:
> test_vmalloc
>
On Wed, May 08, 2019 at 05:58:49PM -0700, Frank Rowand wrote:
>
> If KUnit is added to the kernel, and a subsystem that I am submitting
> code for has chosen to use KUnit instead of kselftest, then yes, I do
> *have* to use KUnit if my submission needs to contain a test for the
> code unless I wan
https://bugs.freedesktop.org/show_bug.cgi?id=110641
--- Comment #2 from Bong Cosca ---
It wasn't the case before when VDDGFX and VDDNB were not exposed. Are these
(and the missing in0_input/in1_input probes) present on APUs?
--
You are receiving this mail because:
You are the assignee for the b
Hi allen.
Thanks for this fine patch.
A few comments follows.
Consider to use DRM_DEV_ERROR and friends.
Then you get the devicename included in logging
and this makes it much easier to find relevant entries.
On Wed, May 08, 2019 at 03:48:41PM +0800, allen wrote:
> From: Allen Chen
>
> This ad
Hi Da.*,
So last week when I said we were ready for merge window... I lied. Lots of stuff
to sneak in this week including 6 patches that came from -misc-next. Fortunately
they _just_ missed the feature freeze so I was able to tag and merge them here.
Most of what is here is panfrost fixes, which i
From: Jayant Shekhar
Since the upstream interconnect bus framework has landed
upstream, the existing references of custom bus scaling
needs to be cleaned up.
Changes in v2:
- Fixed build error due to partial clean up
Changes in v3:
- Condense multiple lines into a single line (S
From: Jayant Shekhar
The interconnect framework is designed to provide a
standard kernel interface to control the settings of
the interconnects on a SoC.
The interconnect API uses a consumer/provider-based model,
where the providers are the interconnect buses and the
consumers could be various d
From: Georgi Djakov
Signed-off-by: Georgi Djakov
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 14 ++
1 file changed, 14 insertions(+)
diff --git a/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c
index 97179bec8902..54
From: Abhinav Kumar
dpu_mdss_destroy() can get called not just from
msm_drm_uninit() but also from msm_drm_bind() in case
of any failures.
dpu_mdss_destroy() removes the icc voting by calling
icc_put. This could accidentally remove the voting
done by pm_runtime_enable.
To make the voting balanc
From: Jayant Shekhar
Add interconnect properties such as interconnect provider specifier
, the edge source and destination ports which are required by the
interconnect API to configure interconnect path for MDSS.
Changes in v2:
- None
Changes in v3:
- Remove common property defi
From: Rob Clark
Most of this is a resend of things that have already been posted to
list. I've rebased the DPU patches, which was somewhat conflicty due to
other changes and refactoring in the DPU code.
Probably wouldn't hurt for someone to look over my rebases of the first
two patches in parti
Quoting Daniel Vetter (2019-05-08 13:53:30)
> On Wed, May 8, 2019 at 2:06 PM Chris Wilson wrote:
> >
> > Currently there is an underlying assumption that i915_request_unsubmit()
> > is synchronous wrt the GPU -- that is the request is no longer in flight
> > as we remove it. In the near future tha
On Wed, May 08, 2019 at 06:06:52AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Depending on platform firmware, a zap shader may not be required to take
> the GPU out of secure mode on boot, in which case we can just write
> RBBM_SECVID_TRUST_CNTL directly. Which we *mostly* handled, but missed
https://bugs.freedesktop.org/show_bug.cgi?id=110630
--- Comment #7 from Axel Davy ---
amdgpu.dc=0 makes things worse.
http://dev.ipol.im/~adavy/green_lines2.mp4
As you can see, instead of a few green lines, there are instead a few full bad
frames.
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=110443
--- Comment #14 from Julien Isorce ---
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/796
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/797
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/842
--
You are receiving thi
> On Tue, May 07, 2019 at 10:01:19AM +0200, Greg KH wrote:
> > > My understanding is that the intent of KUnit is to avoid booting a kernel
> > > on
> > > real hardware or in a virtual machine. That seems to be a matter of
> > > semantics
> > > to me because isn't invoking a UML Linux just runnin
Attach HDR metadata property to connector object.
v2: Rebase
v3: Updated the property name as per updated name
while creating hdr metadata property
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git
From: Ville Syrjälä
ADD HLG EOTF to the list of EOTF transfer functions supported.
Hybrid Log-Gamma (HLG) is a high dynamic range (HDR) standard.
HLG defines a nonlinear transfer function in which the lower
half of the signal values use a gamma curve and the upper half
of the signal values use a
This patch series enables HDR support in drm. It basically defines
HDR metadata structures, property to pass content (after blending)
metadata from user space compositors to driver.
Dynamic Range and Mastering infoframe creation and sending.
ToDo:
1. We need to get the color framework in place fo
BYT/CHT doesn't support DRM Infoframe. This caused
a WARN_ON due to a missing CASE while executing
intel_hdmi_infoframes_enabled function. This patch
fixes the same.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_hdmi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu
Added state readout for DRM infoframe and enabled
state validation for DRM infoframe.
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_ddi.c | 4
drivers/gpu/drm/i915/intel_display.c | 1 +
drivers/gpu/drm/i915/intel_hdmi.c| 4
3 files changed, 9 insertions(+)
diff --
On Wed, May 08, 2019 at 06:31:24PM +0200, Daniel Vetter wrote:
> On Wed, May 08, 2019 at 12:09:06PM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch adds atomic_enable and atomic_disable callbacks to the
> > encoder helpers. This will allow encoders to make informed decisions in
> >
From: Jonas Karlman
This adds reference count for HDR metadata blob,
handled as part of duplicate and destroy connector
state functions.
Signed-off-by: Jonas Karlman
Signed-off-by: Uma Shankar
---
drivers/gpu/drm/drm_atomic_state_helper.c | 6 ++
1 file changed, 6 insertions(+)
diff --gi
This patch enables modeset whenever HDR metadata
needs to be updated to sink.
v2: Addressed Shashank's review comments.
v3: Added Shashank's RB.
v4: Addressed Ville's review comments.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i9
From: Ville Syrjälä
This patch enables infoframes on GLK+ to be
used to send HDR metadata to HDMI sink.
v2: Addressed Shashank's review comment.
v3: Addressed Shashank's review comment.
v4: Added Shashank's RB.
Signed-off-by: Ville Syrjälä
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sh
HDR metadata requires a infoframe to be set. Due to fastset,
full modeset is not performed hence adding it to update_pipe
to handle that.
Signed-off-by: Uma Shankar
Reviewed-by: Shashank Sharma
---
drivers/gpu/drm/i915/intel_ddi.c | 13 +
drivers/gpu/drm/i915/intel_hdmi.c | 7
Added unpack function for DRM infoframe for dynamic
range and mastering infoframe readout.
Suggested-by: Ville Syrjälä
Signed-off-by: Uma Shankar
---
drivers/video/hdmi.c | 54
include/linux/hdmi.h | 1 +
2 files changed, 55 insertions(+)
d
Enable writing of HDR metadata infoframe to panel.
The data will be provid by usersapace compositors, based
on blending policies and passsed to driver through a blob
property.
v2: Rebase
v3: Fixed a warning message
v4: Addressed Shashank's review comments
v5: Rebase. Added infoframe calculation
Enable Dynamic Range and Mastering Infoframe for HDR
content, which is defined in CEA 861.3 spec.
The metadata will be computed based on blending
policy in userspace compositors and passed as a connector
property blob to driver. The same will be sent as infoframe
to panel which support HDR.
Added
HDR metadata block is introduced in CEA-861.3 spec.
Parsing the same to get the panel's HDR metadata.
v2: Rebase and added Ville's POC changes to the patch.
v3: No Change
v4: Addressed Shashank's review comments
v5: Addressed Shashank's comment and added his RB.
v6: Addressed Jonas Karlman rev
This patch adds a blob property to get HDR metadata
information from userspace. This will be send as part
of AVI Infoframe to panel.
It also implements get() and set() functions for HDR output
metadata property.The blob data is received from userspace and
saved in connector state, the same is retu
On Wed, May 08, 2019 at 11:17:56AM +0300, Gwan-gyeong Mun wrote:
> Data M/N calculations were assumed a bpp as RGB format. But when we are
> using YCbCr 4:2:0 output format on DP, we should change bpp calculations
> as YCbCr 4:2:0 format. The pipe_bpp value was assumed RGB format,
> therefore, it w
On Wed, May 08, 2019 at 11:17:54AM +0300, Gwan-gyeong Mun wrote:
> Function intel_pixel_encoding_setup_vsc handles vsc header and data block
> setup for pixel encoding / colorimetry format.
>
> Setup VSC header and data block in function intel_pixel_encoding_setup_vsc
> for pixel encoding / colori
On Sat, Apr 27, 2019 at 01:49:27PM +, Deucher, Alexander wrote:
NACK. 4.19 did not contain support for picasso. Please drop this patch for
4.19.
Dropped, thank you!
--
Thanks,
Sasha
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
htt
On Wed, May 08, 2019 at 11:17:53AM +0300, Gwan-gyeong Mun wrote:
> SDP VSC Header and Data Block follow DP 1.4a spec, section 2.2.5.7.5,
> chapter "VSC SDP Payload for Pixel Encoding/Colorimetry Format".
>
> Signed-off-by: Gwan-gyeong Mun
> Reviewed-by: Maarten Lankhorst
> ---
> include/drm/drm
https://bugs.freedesktop.org/show_bug.cgi?id=109526
--- Comment #6 from Johannes Hirte ---
ping? still an issue with kernel 5.1
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedes
Hi,
On Thu, Mar 07, 2019 at 11:30:51AM +0100, Guido Günther wrote:
> This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
> SoCs.
>
> It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
> i.MX8QXP. I added the necessary hooks to support other imx
On Wed, May 08, 2019 at 12:09:10PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds a new drm helper library to help drivers implement
> self refresh. Drivers choosing to use it will register crtcs and
> will receive callbacks when it's time to enter or exit self refresh
> mode.
>
>
On Wed, May 08, 2019 at 12:09:07PM -0400, Sean Paul wrote:
> From: Laurent Pinchart
>
> Add functions to the atomic core to retrieve the old and new connectors
> associated with an encoder in a drm_atomic_state. This is useful for
> encoders and bridges that need to access the connector, for inst
On Wed, May 08, 2019 at 12:09:06PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds atomic_enable and atomic_disable callbacks to the
> encoder helpers. This will allow encoders to make informed decisions in
> their start-up/shutdown based on the committed state.
>
> Aside from the
From: Sean Paul
This patch adds a new drm helper library to help drivers implement
self refresh. Drivers choosing to use it will register crtcs and
will receive callbacks when it's time to enter or exit self refresh
mode.
In its current form, it has a timer which will trigger after a
driver-spec
From: Sean Paul
Instead of flushing all vops every time we get a dirtyfb call, use the
damage helper to kick off an atomic commit. Even though we don't use
damage clips, the helper commit will force us through the normal
psr_inhibit_get/put sequence.
Changes in v3:
- Added to the set
Changes in
From: Sean Paul
Instead of fully disabling and re-enabling the vop on self refresh
transitions, only disable the active windows. This will speed up
self refresh exits substantially and is still a power-savings win.
This patch integrates portions of Zain's patch from here:
https://patchwork.kerne
From: Sean Paul
Now that we use the drm psr helpers, we no longer need to hand-roll our
atomic_commit_tail implementation. So use the helper
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- None
Link to v1:
https://patchwork.freedesktop.org/patch/msgid/20190228210939.83386-6-s...@p
From: Sean Paul
Once we start shutting off the link during PSR, we're going to want fast
training to work. If the display doesn't support fast training, don't
enable psr.
Changes in v2:
- None
Changes in v3:
- None
Changes in v4:
- None
Link to v1:
https://patchwork.freedesktop.org/patch/msgid
From: Sean Paul
Everyone who implements connector_helper_funcs->atomic_check reaches
into the connector state to get the atomic state. Instead of continuing
this pattern, change the callback signature to just give atomic state
and let the driver determine what it does and does not need from it.
From: Sean Paul
Change the argument to vop_win_disable to vop_win to accomodate future
changes to the function.
Changes in v4:
- Added to the patchset
Signed-off-by: Sean Paul
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions
From: Sean Paul
Instead of rolling our own implementation for tracking when PSR should
be [in]active, use the new self refresh helpers to do the heavy lifting.
Changes in v2:
- updated to reflect changes made in the helpers
Changes in v3:
- use the new atomic hooks to inspect crtc state instead
From: Sean Paul
This patch adds atomic variants for all of
pre_enable/enable/disable/post_disable bridge functions. These will be
called from the appropriate atomic helper functions. If the bridge
driver doesn't implement the atomic version of the function, we will
fall back to the vanilla implem
From: Laurent Pinchart
Add functions to the atomic core to retrieve the old and new connectors
associated with an encoder in a drm_atomic_state. This is useful for
encoders and bridges that need to access the connector, for instance for
the drm_display_info.
The CRTC associated with the encoder
From: Sean Paul
Another version of the SR helpers for your consumption.
Pretty minor differences between v4 and v3:
- lots of documentation changes
- Use connector to get at crtc state in encoders
- Use the damage helpers in rockchip to fix fbdev
Note that the rockchip patches require
e9abc611a
From: Sean Paul
This patch adds atomic_enable and atomic_disable callbacks to the
encoder helpers. This will allow encoders to make informed decisions in
their start-up/shutdown based on the committed state.
Aside from the new hooks, this patch also introduces the new signature
for .atomic_* fun
https://bugs.freedesktop.org/show_bug.cgi?id=110472
--- Comment #2 from gpiza...@javaman.net ---
I really hope someone sees this. Bump x2?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lis
https://bugs.freedesktop.org/show_bug.cgi?id=110641
--- Comment #1 from Alex Deucher ---
That commit just exposes the temperature via an ioctl interface. It doesn't
affect the hwmon sysfs API. How did you determine that that was the
problematic one?
--
You are receiving this mail because:
You
On Wed, May 08, 2019 at 06:06:52AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Depending on platform firmware, a zap shader may not be required to take
> the GPU out of secure mode on boot, in which case we can just write
> RBBM_SECVID_TRUST_CNTL directly. Which we *mostly* handled, but missed
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote:
>
> Due to the lack of
> controversy about the candidates [...]
Such a statement, when talking about election results, very much sounds
like "the election committees favourite candidates won anyway, so..."
p.
Luc Verhaegen.
__
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote:
>
> In the interest of transparency I should mention that one person
> accidentally signed up twice and voted twice. Luckily this doesn't
> change the results of the election since there is more than a 6-point
> gap between 4th and
On Wed, May 08, 2019 at 02:06:37PM +, Harry Wentland wrote:
>
> It should also be noted that even though our election process as
> outlined at https://www.x.org/wiki/BoardOfDirectors/Elections/ allows
> denying candidates any points our website didn't take this into account
> and forced vot
On Wed, May 8, 2019 at 10:06 AM Harry Wentland wrote:
>Trevor Woerner 4 14 10 10 8 19 199
>
I'd like to truly thank the other 3 people who chose me as their 1st pick,
and the 14 (:-O !!) who chose me as their first 2nd-place pick!
Considering I'm not an active contributor
On Wed, May 08, 2019 at 06:06:52AM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Depending on platform firmware, a zap shader may not be required to take
> the GPU out of secure mode on boot, in which case we can just write
> RBBM_SECVID_TRUST_CNTL directly. Which we *mostly* handled, but missed
https://bugzilla.kernel.org/show_bug.cgi?id=203525
--- Comment #7 from Erik (erikjohans...@flashbox.5july.org) ---
Is there anything more i can do to find out what's going on?
--
You are receiving this mail because:
You are watching the assignee of the bug.
__
Den 08.05.2019 08.33, skrev Oleksandr Andrushchenko:
> On 5/7/19 7:04 PM, Noralf Trønnes wrote:
>> Hi,
>>
>> Could someone please have a look at this one?
>>
>> Noralf.
>>
>> Den 26.04.2019 14.47, skrev Noralf Trønnes:
>>> The logic for freeing an imported buffer with a virtual address is
>>> bro
Total membership 84; total votes 65; which makes for a 77.4% voter
turnout. Here are the results:
Board Members:
Name 1 2 3 4 5 6 Score
Daniel Vetter 27 10 14 6 2 6 296
Samuel Iglesias Gonsálvez 11 10 13 15 10 6 239
Lyude
https://bugs.freedesktop.org/show_bug.cgi?id=110645
Michel Dänzer changed:
What|Removed |Added
QA Contact|mesa-dev@lists.freedesktop. |dri-devel@lists.freedesktop
On Wed, May 08, 2019 at 04:11:28PM +0300, Andy Shevchenko wrote:
> On Wed, May 08, 2019 at 02:28:29PM +0300, Alexandru Ardelean wrote:
> > This change re-introduces `match_string()` as a macro that uses
> > ARRAY_SIZE() to compute the size of the array.
> > The macro is added in all the places that
From: Rob Clark
Depending on platform firmware, a zap shader may not be required to take
the GPU out of secure mode on boot, in which case we can just write
RBBM_SECVID_TRUST_CNTL directly. Which we *mostly* handled, but missed
clearing 'ret' resulting that hw_init() returned an error on these
d
On Wed, May 8, 2019 at 2:06 PM Chris Wilson wrote:
>
> Currently there is an underlying assumption that i915_request_unsubmit()
> is synchronous wrt the GPU -- that is the request is no longer in flight
> as we remove it. In the near future that may change, and this may upset
> our signaling as we
On Wed, May 8, 2019 at 2:23 PM Koenig, Christian
wrote:
>
> Am 08.05.19 um 14:15 schrieb Daniel Vetter:
> > [CAUTION: External Email]
> >
> > On Wed, May 8, 2019 at 2:00 PM Christian König
> > wrote:
> >> Am 08.05.19 um 12:11 schrieb Daniel Vetter:
> >>> On Wed, May 08, 2019 at 11:15:33AM +0200,
On Wed, May 8, 2019 at 2:05 PM Chris Wilson wrote:
>
> Move the duplicated code within dma-fence.c into the header for wider
> reuse. In the process apply a small micro-optimisation to only prune the
> fence->cb_list once rather than use list_del on every entry.
>
> Signed-off-by: Chris Wilson
>
Am 08.05.19 um 14:15 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Wed, May 8, 2019 at 2:00 PM Christian König
> wrote:
>> Am 08.05.19 um 12:11 schrieb Daniel Vetter:
>>> On Wed, May 08, 2019 at 11:15:33AM +0200, Daniel Vetter wrote:
On Tue, May 07, 2019 at 10:13:30AM +0200, Chris
On Wed, May 08, 2019 at 02:28:35PM +0300, Alexandru Ardelean wrote:
> -static const char * const phy_types[] = {
> - "emmc 5.0 phy",
> - "emmc 5.1 phy"
> -};
> -
> enum xenon_phy_type_enum {
> EMMC_5_0_PHY,
> EMMC_5_1_PHY,
> NR_PHY_TYPES
There is no need for NR_PHY_TYPES
On 08/05/2019 13:05, Chris Wilson wrote:
Move the duplicated code within dma-fence.c into the header for wider
reuse. In the process apply a small micro-optimisation to only prune the
fence->cb_list once rather than use list_del on every entry.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko U
On Wed, May 8, 2019 at 2:00 PM Christian König
wrote:
> Am 08.05.19 um 12:11 schrieb Daniel Vetter:
> > On Wed, May 08, 2019 at 11:15:33AM +0200, Daniel Vetter wrote:
> >> On Tue, May 07, 2019 at 10:13:30AM +0200, Christian König wrote:
> >>> To allow a smooth transition from pinning buffer object
Quoting Chris Wilson (2019-05-08 13:05:42)
> Move the duplicated code within dma-fence.c into the header for wider
> reuse. In the process apply a small micro-optimisation to only prune the
> fence->cb_list once rather than use list_del on every entry.
>
> Signed-off-by: Chris Wilson
> Reviewed-b
In order to fix a bug in i915, I would like to opencode the dma fence
signal processing (to close a race condition with preemption and signal
enabling). Tvrtko quite rightly objected to the opencoding and suggested
that dma-fence should provide the helpers, so here's my suggestion wrt
the interface
Currently there is an underlying assumption that i915_request_unsubmit()
is synchronous wrt the GPU -- that is the request is no longer in flight
as we remove it. In the near future that may change, and this may upset
our signaling as we can process an interrupt for that request while it
is no long
Move the duplicated code within dma-fence.c into the header for wider
reuse. In the process apply a small micro-optimisation to only prune the
fence->cb_list once rather than use list_del on every entry.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/dma-buf/Makefile
Am 08.05.19 um 12:11 schrieb Daniel Vetter:
On Wed, May 08, 2019 at 11:15:33AM +0200, Daniel Vetter wrote:
On Tue, May 07, 2019 at 10:13:30AM +0200, Christian König wrote:
To allow a smooth transition from pinning buffer objects to dynamic
invalidation we first start to cache the sg_table for a
Am 08.05.19 um 11:15 schrieb Daniel Vetter:
On Tue, May 07, 2019 at 10:13:30AM +0200, Christian König wrote:
To allow a smooth transition from pinning buffer objects to dynamic
invalidation we first start to cache the sg_table for an attachment.
Signed-off-by: Christian König
---
drivers/dma
Am 08.05.19 um 11:57 schrieb Daniel Vetter:
On Tue, May 07, 2019 at 10:13:32AM +0200, Christian König wrote:
That is now done by the DMA-buf helpers instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_prime.c | 76 -
1 file changed, 16 inserti
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #37 from Christian Zigotzky ---
Hi All,
Allan has tested the ninth test kernel.
He wrote:
Christian
DRM9 boots to SI card.
ace
--
This step has been marked as bad because the ninth test kernel doesn't boot to
the FirePro.
https://bugzilla.kernel.org/show_bug.cgi?id=203525
--- Comment #6 from Erik (erikjohans...@flashbox.5july.org) ---
The bisect was working i only didn't trust it.
What causes the change in behavior wasn't caused by resent fixes, well it was
but it wasn't.
What makes it work is bumping SUBLEVEL abov
https://bugzilla.kernel.org/show_bug.cgi?id=202873
--- Comment #7 from Haxk20 (haxk...@gmail.com) ---
Ah sorry this is the old bug where clocks cause flickering. But still try 5.1.
Maybe it will help.
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
1 - 100 of 163 matches
Mail list logo
