On Thu, Mar 15, 2018 at 02:08:51PM -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> DP_TRAINING_AUX_RD_INTERVAL with DP 1.3 spec changed bit scheeme from 8
> bits to 7 in DPCD 0x000e. The 8th bit is used to identify extended
> receiver capabilities. For panels that use this new fe
https://bugs.freedesktop.org/show_bug.cgi?id=105515
--- Comment #9 from Edward Kigwana ---
Created attachment 138164
--> https://bugs.freedesktop.org/attachment.cgi?id=138164&action=edit
dmesg
This is with options amdgpu dpm=0 dc=1 dc_log=1
[drm:amdgpu_device_ip_set_powergating_state [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=105515
--- Comment #8 from Edward Kigwana ---
(In reply to Alex Deucher from comment #7)
> Does disabling the Intel gfx chip or booting with the AMD card as the
> primary help? Can you also try booting with amdgpu.dc=1?
options amdgpu dpm=0 dc=1 dc_l
eDP 1.4a specification defines PSR version 3, it PSR2 with the
addition of Y-coordinate support when doing selective update.
Signed-off-by: José Roberto de Souza
---
include/drm/drm_dp_helper.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_h
https://bugs.freedesktop.org/show_bug.cgi?id=105569
Bug ID: 105569
Summary: sw_init of IP block failed -2
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: n
Xilinx ZynqMP has a hardened display pipeline. The pipeline can
be logically partitioned into 2 parts: display controller and
DisplayPort encoder / transmitter. This driver handles the display
controller part of the pipeline that handles buffer management and
blending.
Signed-off-by: Hyun Kwon
Ac
This is a wrapper around the ZynqMP Display and DisplayPort drivers.
Signed-off-by: Hyun Kwon
Acked-by: Daniel Vetter
---
v6
- Accomodate the migration of logical master from platform device to device
- Remove the duplicate license paragraphs
- Do complete forward declaration in the header
v5
-
This add a dt binding for ZynqMP DP subsystem.
Signed-off-by: Hyun Kwon
Reviewed-by: Rob Herring
---
v6
- Add more descriptions and references
- Remove the description for child node
v4
- Specify phy related descriptions
- Specify dma related descriptions
- Remove ports
- Remove child nodes for
This driver creates DRM encoder and connector for ZynqMP DisplayPort.
Signed-off-by: Hyun Kwon
Acked-by: Daniel Vetter
---
v6
- Constify all function pointers
- Clean up the duplicated license paragraphs
- Do complete forward declaration in the header
v2
- Change the SPDX identifier format
- Spl
Xilinx has various platforms for display, where users can create
using multiple IPs in the programmable FPGA fabric, or where
some hardened pipeline is available on the chip. Furthermore,
hardened pipeline can also interact with soft logics in FPGA.
The Xilinx DRM KMS module is to integrate multip
Commit 39bf4de89ff7 ("drm/i915: Add -Wall -Wextra to our build, set
warnings to full") enabled extra warnings for i915 to spot possible
bugs in new code, and then disabled a subset of these warnings to keep
the current code building without warnings (with gcc). Enabling the
extra warnings also enab
Update i915_context_status to include priority information.
v2:
- Clarify that the offset is based on cgroup (Chris)
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i
Usually display-boosted contexts get treated as
I915_CONTEXT_MAX_USER_PRIORITY+1, which prioritizes them above regular
GPU contexts. Now that we allow a much larger range of effective
priority values via per-cgroup priority offsets, a system administrator
may want more detailed control over how mu
Wraps task_dfl_cgroup() to also take a reference to the cgroup.
v2:
- Eliminate cgroup_mutex and make lighter-weight (Tejun)
Cc: Tejun Heo
Cc: cgro...@vger.kernel.org
Signed-off-by: Matt Roper
---
include/linux/cgroup.h | 29 +
1 file changed, 29 insertions(+)
dif
There are cases where a system integrator may wish to raise/lower the
priority of GPU workloads being submitted by specific OS process(es),
independently of how the software self-classifies its own priority.
Exposing "priority offset" as an i915-specific cgroup parameter will
enable such system-lev
Getting cgroup private data for the current process' cgroup is such a
common pattern that we should add a convenience wrapper for it.
Signed-off-by: Matt Roper
---
include/linux/cgroup.h | 1 +
kernel/cgroup/cgroup.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/
In preparation for adding cgroup-based priority adjustments, let's
define the driver's priority values a little more clearly.
Cc: Chris Wilson
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/i915_gem_context.c | 4 ++--
drivers/gpu/drm/i915/i9
Introduce a new DRM_IOCTL_I915_CGROUP_SETPARAM ioctl that will allow
userspace to set i915-specific parameters for individual cgroups. i915
cgroup data will be registered and later looked up via the new
cgroup_priv infrastructure.
v2:
- Large rebase/rewrite for new cgroup_priv interface
v3:
- A
There are cases where other parts of the kernel may wish to store data
associated with individual cgroups without building a full cgroup
controller. Let's add interfaces to allow them to register and lookup
this private data for individual cgroups.
A kernel system (e.g., a driver) that wishes to
This is the fourth iteration of the work previously posted here:
(v1) https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html
(v2)
https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html
(v3) https://lists.freedesktop.org/archives/intel-gfx/2018-March/15
Meghana Madhyastha writes:
> Split spi messages into chunks of <65535 in the spi subsystem and remove the
> message
> length warning in bcm2835_spi_can_dma. This is so that the messages can be
> transferred
> via dma and that the tinydrm drivers need not split it. The current chunk
> size is 6
Hi Matt,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180316]
[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/matthew
"Gustavo A. R. Silva" writes:
> In preparation to enabling -Wvla, remove VLA. In this particular
> case use macro ARRAY_SIZE so the length of array _bo_ can be
> computed at preprocessing time.
>
> The use of stack Variable Length Arrays needs to be avoided, as they
> can be a vector for stack ex
Hi Dave,
The following changes since commit 7928b2cbe55b2a410a0f5c1f154610059c57b1b2:
Linux 4.16-rc1 (2018-02-11 15:04:29 -0800)
are available in the Git repository at:
git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.16-rc7
for you to fetch changes up to 48519232bea9230d1c5d
Ville Syrjälä writes:
> On Thu, Mar 15, 2018 at 08:03:44PM +0200, Ville Syrjälä wrote:
>> On Thu, Mar 15, 2018 at 07:48:02PM +0200, Ville Syrjälä wrote:
>> > On Thu, Mar 15, 2018 at 10:42:17AM -0700, Eric Anholt wrote:
>> > > Ville Syrjala writes:
>> > >
>> > > > From: Ville Syrjälä
>> > > >
>
Daniel Stone writes:
> Hey Eric,
>
> On 3 March 2018 at 01:34, Eric Anholt wrote:
>> Ccing a couple of folks who are likely to have opinions about
>> drm_fourcc.h additions (Do we have enough docs? Are the macros OK?),
>> and Bootlin who are likely reviewers.
>>
>> The plan is to use these modi
For parameterized modifiers (Broadcom's SAND and UIF), we need to
allow the parameter fields to be filled in, while exposing only the
variant of the modifier with the parameter unfilled in the internal
arrays and the format blob.
Signed-off-by: Eric Anholt
Cc: Ville Syrjälä
---
drivers/gpu/drm/
Daniel's format_mod_supported() patch predated Dave's for NV21/61, and
I didn't catch that when rebasing. This is a problem since the
formats are now getting validated before being passed to the driver's
atomic hooks.
Signed-off-by: Eric Anholt
Cc: Daniel Stone
Cc: Dave Stevenson
Fixes: 423ad7
From: Dave Stevenson
This is the format generated by VC4's H.264 engine, and preferred by
the ISP as well. By displaying SAND buffers directly, we can avoid
needing to use the ISP to rewrite the SAND H.264 output to linear
before display.
This is a joint effort by Dave Stevenson (who wrote the
This series adds support for the gamma and CTM properties to VC4.
Patches 2 and 3 need the register definitions from here:
https://patchwork.freedesktop.org/patch/207863/
The CTM support is somewhat limited in that we can only enable it for one
CRTC at a time and coefficients are S0.9 in hardware
We are an atomic driver so the gamma LUT should also be exposed as a
CRTC property through the DRM atomic color management. This will also
take care of the legacy path for us.
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_crtc.c | 24 +---
1 file changed, 13 insert
The hardware supports a CTM with S0.9 values. We therefore only allow
a value of 1.0 or fractional only and reject all others with integer
parts. This restriction is mostly inconsequential in practice since
commonly used transformation matrices have all scalars <= 1.0.
Signed-off-by: Stefan Schake
We only have one hardware block to do the CTM and need to reject
attempts to enable it for multiple CRTCs simultaneously.
Signed-off-by: Stefan Schake
---
drivers/gpu/drm/vc4/vc4_crtc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/
Rework the platformdrmgeneric buffer importer to use the libdrm
generic gralloc handle definition.
This is just to get the drm_hwcomposer project building in AOSP
along with the libdrm freedesktop/master branch. Similar changes
may also be needed to gbm_gralloc and other projects not used
in AOSP.
In trying to integrate the new gralloc_handle.h with the
drm_hwcomposer, I started seeing the following compilation
errors:
In file included from external/drm_hwcomposer/platformdrmgeneric.cpp:28:
external/libdrm/android/gralloc_handle.h:108:9: error: cannot initialize return
object of type 'nati
Hi Dave,
Updates for 4.17. Highlights:
- Continued cleanup and restructuring of powerplay
- Fetch VRAM type from vbios rather than hardcoding for SOC15 asics
- Allow ttm to drop its backing store when drivers don't need it
- DC bandwidth calc updates
- Enable DC backlight control pre-DCE11 asics
Quoting Eric Engestrom (2018-03-16 10:12:27)
> Signed-off-by: Eric Engestrom
> ---
> meson.build | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/meson.build b/meson.build
> index 0fe04a1411963c70cf80..74a541e8d835ae27c7f4 100644
> --- a/meson.build
> +++ b/meson.bui
On 2018-03-16 12:45, Sean Paul wrote:
Instead, shuffle things around so we kickoff crtc after enabling
encoder
during modesets. Also moves the vblank wait to after the frame.
Changes in v2:
- Remove the encoder.commit hack, it's not required (Jeykumar)
Cc: Jeykumar Sankaran
Signed-off-by: Sea
These macros are similar to the DRM_ with the addition
of a struct device * to the arguments.
Convert the single drm_dev_printk function into 2 separate functions.
drm_dev_printk with a KERN_ * for generic use and drm_dev_dbg
for conditional masked use.
Remove the __func__ argument and use __buil
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #7 from philipmor...@gmail.com ---
There are 3 physical motherboard sockets: HDMI, DVI DL, and D-SUB.
xrandr reports the D-SUB as DisplayPort-0.
In kernel versions before 4.10 I used to have to hack the i915 code as follows
(in inte
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #6 from Ville Syrjala ---
(In reply to Alex Deucher from comment #5)
> (In reply to Christian König from comment #3)
> > What you can use is either an active DP to dual DVI converter (probably
> > rather expensive if such a thing eve
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #5 from Alex Deucher ---
(In reply to Christian König from comment #3)
> What you can use is either an active DP to dual DVI converter (probably
> rather expensive if such a thing even exists) or native DP/HDMI (if the
> monitor has
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
>Daniel Vetter
>Sent: Friday, March 16, 2018 1:43 AM
>To: Xiong, James
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
>Subject: Re: [PATCH libdrm 0/5] improve reuse
Instead, shuffle things around so we kickoff crtc after enabling encoder
during modesets. Also moves the vblank wait to after the frame.
Changes in v2:
- Remove the encoder.commit hack, it's not required (Jeykumar)
Cc: Jeykumar Sankaran
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu
On Fri, Mar 16, 2018 at 3:59 AM, Daniel Vetter wrote:
> We have quite a few driver docs now, which is great, but having them
> all in the top-level gpu documentation chapter makes it harder to spot
> the core/shared bits.
>
> Stuff them into a separate chapter and ecourage people to add even
> mor
https://bugzilla.kernel.org/show_bug.cgi?id=198123
--- Comment #41 from Alex Deucher (alexdeuc...@gmail.com) ---
Maybe something will jump out if we look at the register differences? You can
use radeonreg (https://cgit.freedesktop.org/~airlied/radeontool/) to dump the
display registers. e.g., rad
From: Ville Syrjälä
drm_property_add_enum() can calculate the index itself just fine,
so no point in having the caller pass it in.
Cc: Patrik Jakobsson
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_connector.c | 6 +++---
dri
https://bugs.freedesktop.org/show_bug.cgi?id=105515
--- Comment #7 from Alex Deucher ---
Does disabling the Intel gfx chip or booting with the AMD card as the primary
help? Can you also try booting with amdgpu.dc=1?
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=105515
--- Comment #6 from Alex Deucher ---
(In reply to Edward Kigwana from comment #5)
> options msi=1 exp_hw_support=0 ppfeaturemask=0
The msi and exp_hw_support shouldn't have any effect in your case and
ppfeaturemask is pretty much irrelevant if
Document the device tree bindings for the Adreno GMU device
available on Adreno a6xx targets.
Signed-off-by: Jordan Crouse
---
.../devicetree/bindings/display/msm/gmu.txt| 54 ++
.../devicetree/bindings/display/msm/gpu.txt| 10 +++-
2 files changed, 62 inserti
(resend because I forgot to CC everybody on the patches)
Add DT nodes for the sdm845 GPU/GMU (graphics management unit) and the companion
arm-smmu-v2 compatible SMMU.
This builds on the following dependencies -
https://patchwork.kernel.org/patch/10286369/ - bindings for qcom,level
https://patchwo
Add the nodes to describe the Adreno GPU and GMU devices.
Signed-off-by: Jordan Crouse
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 119 +++
1 file changed, 119 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
the system]
url:
https://github.com/0day-ci/linux/commits/Nautiyal-Ankit-K/Aspect-ratio-support-in-DRM-layer/20180316-204825
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__
sparse warnings: (new ones prefixed by
Add DT nodes for the sdm845 GPU/GMU (graphics management unit) and the companion
arm-smmu-v2 compatible SMMU.
This builds on the following dependencies -
https://patchwork.kernel.org/patch/10286369/ - bindings for qcom,level
https://patchwork.kernel.org/patch/10281599/ - qcom,smmu-v2 bindings
Ple
Add the nodes to describe the Adreno GPU and GMU devices.
Signed-off-by: Jordan Crouse
---
arch/arm64/boot/dts/qcom/sdm845.dtsi | 119 +++
1 file changed, 119 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
b/arch/arm64/boot/dts/qcom/sdm845.dtsi
Document the device tree bindings for the Adreno GMU device
available on Adreno a6xx targets.
Signed-off-by: Jordan Crouse
---
.../devicetree/bindings/display/msm/gmu.txt| 54 ++
.../devicetree/bindings/display/msm/gpu.txt| 10 +++-
2 files changed, 62 inserti
On Mon, Mar 05, 2018 at 01:38:59PM -0600, Rob Herring wrote:
> On Fri, Mar 2, 2018 at 3:56 PM, Jordan Crouse wrote:
> > Document the device tree bindings for the Adreno GMU device
> > available on Adreno a6xx targets.
> >
> > Change-Id: I3cfd5fb35ab0045e39905ff12393006e60f1a124
>
> Gerrit!
>
> >
On March 16, 2018 5:25:12 PM UTC, Emil Velikov wrote:
> On 16 March 2018 at 17:12, Eric Engestrom
> wrote:
> > Signed-off-by: Eric Engestrom
> > ---
> > configure.ac | 2 ++
> > meson.build | 2 +-
> > xf86drm.c| 8
> > 3 files changed, 7 insertions(+), 5 deletions(-)
> >
> > di
From: Sharat Masetty
Add initial register headers for A6XX targets.
Signed-off-by: Sharat Masetty
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 1600 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 382 +++
2 files changed, 1982 in
Add support for the A6XX family of Adreno GPUs. The biggest addition
is the GMU (Graphics Management Unit) which takes over most of the
power management of the GPU itself but in a ironic twist of fate
needs a goodly amount of management itself. Add support for the
A6XX core code, the GMU and the H
This is an RFC for the initial version of a6xx support for the Adreno a6xx GPU
family as found on the sdm845 SoC. This code is ahead of most of the rest of
the sdm845 code that would be needed to actually bring up a device and it is
definitely far in advance of any user side support for the a6xx G
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip
head: 61deb7d0941d1e3ffee0d799396ac93b0e90
commit: 34e40f6338c730572874bc3d6fe330c7f2b63013 [83/87] drm/amd/pp: Rename
file name cz_* to smu8_*
reproduce:
# apt-get install sparse
git checkout 34e40f6338c
On 16 March 2018 at 17:12, Eric Engestrom wrote:
> Signed-off-by: Eric Engestrom
> ---
> configure.ac | 2 ++
> meson.build | 2 +-
> xf86drm.c| 8
> 3 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/configure.ac b/configure.ac
> index 14baa1c87f9078f336fa..619af497
Signed-off-by: Eric Engestrom
---
configure.ac| 2 ++
libdrm_macros.h | 2 +-
meson.build | 7 +++
3 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5751a8113635ce6a1c48..14baa1c87f9078f336fa 100644
--- a/configure.ac
+++ b/configure.ac
@
Signed-off-by: Eric Engestrom
---
configure.ac | 2 ++
meson.build | 2 +-
xf86drm.c| 8
3 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/configure.ac b/configure.ac
index 14baa1c87f9078f336fa..619af49726d198c5d685 100644
--- a/configure.ac
+++ b/configure.ac
@@ -347,6
Signed-off-by: Eric Engestrom
---
meson.build | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/meson.build b/meson.build
index 0fe04a1411963c70cf80..74a541e8d835ae27c7f4 100644
--- a/meson.build
+++ b/meson.build
@@ -187,9 +187,8 @@ else
endif
dep_m = cc.find_library('m'
Signed-off-by: Eric Engestrom
---
configure.ac| 4 +++-
intel/test_decode.c | 4 ++--
meson.build | 4 +---
3 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/configure.ac b/configure.ac
index 5d3a20ffd3e7b38db5f1..5751a8113635ce6a1c48 100644
--- a/configure.ac
+++ b/c
On 16 March 2018 at 08:43, Daniel Vetter wrote:
> On Thu, Mar 15, 2018 at 06:20:09PM -0700, James Xiong wrote:
>> From: "Xiong, James"
>>
>> With gem_reuse enabled, when a buffer size is different than
>> the sizes of buckets, it is aligned to the next bucket's size,
>> which means about 25% more
On Thu, Mar 15, 2018 at 07:56:57PM -0700, Alexandru M Stan wrote:
> I noticed that the backlight on the ASUS Chromebook Flip C101 (bob) is
> flickering.
>
> We're sending it a high frequency pwm signal, but the EDP panel decided to
> "parse" the signal, read the duty cycle, then make its own signa
On Wed, Mar 14, 2018 at 02:56:28PM +0100, Daniel Vetter wrote:
> On Tue, Mar 13, 2018 at 05:07:58PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Do the refresh rate calculation with a single division. This gives
> > us slightly more accurate results, especially for interlaced since
On 16 March 2018 at 14:35, Rob Herring wrote:
> On Wed, Mar 14, 2018 at 12:21 PM, Emil Velikov
> wrote:
>> On 14 March 2018 at 16:47, John Stultz wrote:
>>> When building AOSP after updating libdrm project to the
>>> freedesktop/master branch, I've seen the following build errors:
>>>
>>> exter
Quoting Andy Shevchenko (2018-03-16 14:12:13)
> ...instead of open coding file operations followed by custom ->open()
> callbacks per each attribute.
>
> Reviewed-by: Chris Wilson
> Signed-off-by: Andy Shevchenko
And pushed, thanks very much for the patch.
-Chris
___
On 14 March 2018 at 17:30, John Stultz wrote:
> On Wed, Mar 14, 2018 at 10:21 AM, Emil Velikov
> wrote:
>> On 14 March 2018 at 16:47, John Stultz wrote:
>>> When building AOSP after updating libdrm project to the
>>> freedesktop/master branch, I've seen the following build errors:
>>>
>>> exter
Hi Dave,
I have accumulated some patches as we went through some internal testing
for mali-dp and I was waiting for the YUV2RGB patches to land in your
tree, so I would like to get them into drm-next at your earliest
convenient time.
Please note that after you pull Dan Carpenter's patch f2f2c85c6
The same field name appears on two differnt lines, with different values.
julia
-- Forwarded message --
Date: Fri, 16 Mar 2018 22:35:29 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: [radeon-alex:drm-next-4.17-wip 72/87]
drivers/gpu/drm/amd/powerpl
On Thu, 2018-03-15 at 10:11 +0100, Lucas Stach wrote:
> Right now the vblank event completion is racing with the atomic update,
> which is especially bad when the PRE is in use, as one of the hardware
> issue workaround might extend the atomic commit for quite some time.
>
> If the vblank IRQ happ
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #60 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
(In reply to Ricardo Ribalda from comment #59)
> Hi Andrey
>
> Testing with llvm7 setup:
>
>
> R600_DEBUG=notiling,norbplus xinit
>
> does not avoid the hang :(
>
> [ 31
On Wed, Mar 14, 2018 at 12:21 PM, Emil Velikov wrote:
> On 14 March 2018 at 16:47, John Stultz wrote:
>> When building AOSP after updating libdrm project to the
>> freedesktop/master branch, I've seen the following build errors:
>>
>> external/libdrm/intel/Android.mk: error: libdrm_intel
>> (SHAR
Am 16.03.2018 um 14:51 schrieb Chris Wilson:
Quoting Christian König (2018-03-16 13:20:45)
@@ -326,6 +338,29 @@ struct dma_buf_attachment {
struct device *dev;
struct list_head node;
void *priv;
+
+ /**
+* @invalidate_mappings:
+*
+* Optio
https://bugs.freedesktop.org/show_bug.cgi?id=101739
--- Comment #8 from tom34 ---
I see that Bohemia mentioned about this bug here:
https://community.bistudio.com/wiki/Arma_3_Experimental_Ports#Known_Issues
"AMD Mesa drivers can cause graphical glitches, such as white blinking
vegetation LODs."
On Tue, Mar 06, 2018 at 08:54:21AM +0100, Daniel Vetter wrote:
> On Fri, Feb 23, 2018 at 09:25:04PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Provide a small helper to convert the blob length in bytes
> > to the number of LUT entries.
> >
> > Signed-off-by: Ville Syrjälä
> > -
https://bugs.freedesktop.org/show_bug.cgi?id=101739
--- Comment #7 from tom34 ---
I using mesa3d (17.3.6) from stable padoka repo and i see white bushes in game,
here is the example:
(Headphone warning, mic volume too high)
https://www.twitch.tv/videos/239136303?t=01m10s
--
You are receiving t
Quoting Christian König (2018-03-16 13:20:45)
> @@ -326,6 +338,29 @@ struct dma_buf_attachment {
> struct device *dev;
> struct list_head node;
> void *priv;
> +
> + /**
> +* @invalidate_mappings:
> +*
> +* Optional callback provided by the impo
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #4 from philipmor...@gmail.com ---
Thanks for replies. My monitor is DVI DL only.
My old Haswell i5 4670 with HD4600 graphics was also single link DVI only
(https://communities.intel.com/thread/44135), and it worked at 60Hz. Could
so
Instead of relying on the DRM functions just implement our own import
functions. This adds support for taking care of unpinned DMA-buf.
v2: enable for all exporters, not just amdgpu, fix invalidation
handling, lock reservation object while setting callback
Signed-off-by: Christian König
---
Instead of relying on the DRM functions just implement our own export
functions. This adds support for taking care of unpinned DMA-buf.
v2: fix unintended recursion, remove debugging leftovers
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 -
drivers/gpu/drm
Make sure the transfered BO is never destroy before the transfer BO.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 50 +++
1 file changed, 30 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu
Pipeline removal of the BOs backing store when the placement is given
during validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 98e06f8bf23
Each importer can now provide an invalidate_mappings callback.
This allows the exporter to provide the mappings without the need to pin
the backing store.
v2: don't try to invalidate mappings when the callback is NULL,
lock the reservation obj while using the attachments,
add helper to se
Hi everybody,
since I've got positive feedback from Daniel I continued working on this
approach.
A few issues are still open:
1. Daniel suggested that I make the invalidate_mappings callback a parameter of
dma_buf_attach().
This approach unfortunately won't work because when the attachment is
Am 16.03.2018 um 08:46 schrieb Gerd Hoffmann:
A driver to let userspace turn iovecs into dma-bufs.
Use case: Allows qemu create dmabufs for the vga framebuffer or
virtio-gpu ressources. Then they can be passed around to display
those guest things on the host. To spice client for classic full
On Fri, 2018-03-16 at 08:41 +0100, Daniel Vetter wrote:
> On Tue, Mar 13, 2018 at 03:02:15PM -0700, Joe Perches wrote:
> > drm_printk is used for both DRM_ERROR and DRM_DEBUG with unnecessary
> > arguments that can be removed by creating separate functins.
> >
> > Create specific functions for the
Hi Matt,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on v4.16-rc4]
[also build test WARNING on next-20180316]
[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
https://bugzilla.kernel.org/show_bug.cgi?id=198883
--- Comment #59 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Hi Andrey
Testing with llvm7 setup:
R600_DEBUG=notiling,norbplus xinit
does not avoid the hang :(
[ 31.200134] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout,
Hi, Daniel!
Sorry, if I strip the patch too much below.
On 03/16/2018 10:23 AM, Daniel Vetter wrote:
S-o-b line went missing here :-)
will restore it back ;)
I've read through it, 2 actual review comments (around hot-unplug and
around the error recovery for failed flips), a few bikesheds, bu
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #3 from Christian König ---
(In reply to philipmorant from comment #2)
> Will this work with an HDMI to DVI-D cable then ?
No, DVI only supports up to 1920×1200 @ 60Hz with a single link.
It doesn't matter if the output is HDMI or
https://bugs.freedesktop.org/show_bug.cgi?id=105534
--- Comment #2 from philipmor...@gmail.com ---
Will this work with an HDMI to DVI-D cable then ?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri
https://bugs.freedesktop.org/show_bug.cgi?id=105530
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com
Assign
Hi Niklas,
thanks for review,
On Fri, Mar 16, 2018 at 01:00:04AM +0100, Niklas Söderlund wrote:
> Hi Jacopo,
>
> Thanks for your patch.
>
> This one must depend on '[PATCH v2 0/5] arm64: dts: renesas: r8a77970:
> enable HDMI output' or something similar not yet in renesas-drivers
> repository c
https://bugzilla.kernel.org/show_bug.cgi?id=198123
Michel Dänzer (mic...@daenzer.net) changed:
What|Removed |Added
CC||harry.wentl...@amd.co
1 - 100 of 124 matches
Mail list logo
