On Fri, 2019-09-13 at 22:13 +0300, Ville Syrjälä wrote:
> On Thu, Sep 12, 2019 at 02:33:34PM +0300, Gwan-gyeong Mun wrote:
> > Because between HDMI and DP have different colorspaces, it renames
> > drm_mode_create_colorspace_property() function to
> > drm_mode_create_hdmi_colorspace_property() func
If the initialization of the job fails we need to kfree() it
before returning.
Signed-off-by: Iago Toral Quiroga
---
drivers/gpu/drm/v3d/v3d_gem.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
index d46d91346d09..ed68731404a7 10
Support for HDR10 video was introduced in DisplayPort 1.4.
On GLK+ platform, in order to use DisplayPort HDR10, we need to support
BT.2020 colorimetry and HDR Static metadata.
It implements the CTA-861-G standard for transport of static HDR metadata.
It enables writing of HDR metadata infoframe SDP
It attaches the colorspace connector property to a DisplayPort connector.
Based on colorspace change, modeset will be triggered to switch to a new
colorspace.
Based on colorspace property value create a VSC SDP packet with appropriate
colorspace. This would help to enable wider color gamut like BT
Because between HDMI and DP have different colorspaces, it renames
drm_mode_create_colorspace_property() function to
drm_mode_create_hdmi_colorspace_property() function for HDMI connector.
And it adds drm_mode_create_dp_colorspace_property() function for creating
of DP colorspace property.
In order
According to Bspec, GEN11 and prior GEN11 have different register size for
HDR Metadata Infoframe SDP packet. It adds new VIDEO_DIP_GMP_DATA_SIZE for
GEN11. And it makes handle different register size for
HDMI_PACKET_TYPE_GAMUT_METADATA on hsw_dip_data_size() for each GEN
platforms. It addresses Um
It refactors and renames a function which handled vsc sdp header and data
block setup for supporting colorimetry format.
Function intel_dp_setup_vsc_sdp handles vsc sdp header and data block
setup for pixel encoding / colorimetry format.
In order to use colorspace information of a connector, it add
When BT.2020 Colorimetry output is used for DP, we should program BT.2020
Colorimetry to MSA and VSC SDP. It adds output_colorspace to
intel_crtc_state struct as a place holder of pipe's output colorspace.
In order to distinguish needed colorimetry for VSC SDP, it adds
intel_dp_needs_vsc_sdp functi
It attaches HDR metadata property to DP connector on GLK+.
It enables HDR metadata infoframe sdp on GLK+ to be used to send
HDR metadata to DP sink.
v2: Minor style fix
Signed-off-by: Gwan-gyeong Mun
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/display/intel_dp.c | 5 +
1 file changed
Function intel_dp_setup_hdr_metadata_infoframe_sdp handles Infoframe SDP
header and data block setup for HDR Static Metadata. It enables writing of
HDR metadata infoframe SDP to panel. Support for HDR video was introduced
in DisplayPort 1.4. It implements the CTA-861-G standard for transport of
sta
On Fri, 13 Sep 2019 11:32:09 +0200
>
> err = ttm_mem_io_lock(man, true);
> - if (unlikely(err != 0)) {
> - ret = VM_FAULT_NOPAGE;
> - goto out_unlock;
> - }
> + if (unlikely(err != 0))
> + return VM_FAULT_NOPAGE;
> err = ttm_mem_io_reser
On Fri, 13 Sep 2019 11:32:06 +0200
>
> The mm patch page walk interface has been reworked to be similar to the
> reworked page-walk code (mm/pagewalk.c). There have been two other solutions
> to consider:
> 1) Using the page-walk code. That is currently not possible since it requires
> the mmap-s
On Fri, Sep 13, 2019 at 12:09 AM Thomas Hellström (VMware)
wrote:
>
> From: Thomas Hellstrom
>
> Commit 4daa4fba3a38 ("gpu: drm: ttm: Adding new return type vm_fault_t")
> broke TTM prefaulting. Since vmf_insert_mixed() typically always returns
> VM_FAULT_NOPAGE, prefaulting stops after the secon
gcc throws compile error with below message:
HDRINST usr/include/drm/i915_drm.h
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/Makefile:70: *** missing 'endif'.
Stop.
scripts/Makefile.modbuiltin:55: recipe for target 'drivers/gpu/drm/amd/amdgpu'
failed
make[3]: *** [drivers/gpu/drm/amd/amdgpu] Er
Thank you, after adjust TV image settings, screen display normally.
发件人: Adam Jackson
发送时间: Saturday, September 14, 2019 12:47:39 AM
收件人: zhangn1...@outlook.com ;
dri-devel@lists.freedesktop.org
主题: Re: image size is wrong in EDID, how to use EDID quirks
https://bugs.freedesktop.org/show_bug.cgi?id=109819
--- Comment #10 from Pierre-Eric Pelloux-Prayer
---
I could replay the trace 3 times without getting a gpu hang using a recent
kernel and mesa master.
Can you still reproduce the problem?
--
You are receiving this mail because:
You are the a
Hi Steven,
the problem seems to be than panfrost is trying to sleep while freeing a
job. E.g. it tries to take a mutex.
That is not allowed any more since we need to free the jobs from atomic
and even interrupt context.
Your suggestion wouldn't work because this way jobs are not freed when
th
Hi Brian,
On 15.08.2019 02:48, Brian Masney wrote:
> This patch series begins to add support for the external display over
> HDMI that is supported on msm8974 SoCs. I'm testing this series on the
> Nexus 5, and I'm able to communicate with the HDMI bridge via the
> analogix-anx78xx driver, however
On Fri, 13 Sep 2019, Eric Engestrom wrote:
> On Friday, 2019-09-13 14:51:39 +0300, Jani Nikula wrote:
>> Add helper to check if a drm debug category is enabled. Convert drm core
>> to use it. No functional changes.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_atomic_uapi.c
Hi Andrzej,
On Mon, Sep 16, 2019 at 10:13:58AM +0200, Andrzej Hajda wrote:
> Hi Brian,
>
> On 15.08.2019 02:48, Brian Masney wrote:
> > This patch series begins to add support for the external display over
> > HDMI that is supported on msm8974 SoCs. I'm testing this series on the
> > Nexus 5, and
Hi Thomas,
On Mon, Sep 09, 2019 at 04:12:37PM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 04.09.19 um 08:27 schrieb Feng Tang:
> > Hi Thomas,
> >
> > On Wed, Aug 28, 2019 at 12:51:40PM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 28.08.19 um 11:37 schrieb Rong Chen:
> >>> Hi Thomas,
> >>
> On Tue, 10 Sep 2019 11:20:16 +
> Simon Ser wrote:
>
> > On Tuesday, September 10, 2019 1:38 PM, Pekka Paalanen
> > wrote:
> >
> > > On Tue, 10 Sep 2019 10:09:55 +
> > > Simon Ser cont...@emersion.fr wrote:
> > >
> > > > Currently the property docs don't specify whether it's okay for tw
On Tue, Sep 10, 2019 at 12:38 PM Pekka Paalanen wrote:
>
> On Tue, 10 Sep 2019 10:09:55 +
> Simon Ser wrote:
>
> > Currently the property docs don't specify whether it's okay for two planes
> > to
> > have the same zpos value and what user-space should expect in this case.
> >
> > The rule m
https://bugs.freedesktop.org/show_bug.cgi?id=109819
--- Comment #11 from Dominic ---
I'm travelling right now, but can check once home again.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel
On 15.08.2019 02:48, Brian Masney wrote:
> When attempting to configure this driver on a Nexus 5 phone (msm8974),
> setting up the dummy i2c bus for TX_P0 would fail due to an -EBUSY
> error. The downstream MSM kernel sources [1] shows that the proper value
> for TX_P0 is 0x78, not 0x70, so correct
https://bugs.freedesktop.org/show_bug.cgi?id=111691
Bug ID: 111691
Summary: hardware cursor corruption w/ AMD 5700 XT
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Seve
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #1 from Michael Haworth ---
I forgot to mention that I have been using oibaf's PPA in addition to the other
software. I was under the impression that I had to do this for the display to
function.
--
You are receiving this mail beca
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #2 from Michael Haworth ---
A workaround is to enable SWCursor in Xorg
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.
DRM_IOCTL_BO_SET_LABEL lets you label GEM objects, making it
easier to debug issues in userspace applications.
Signed-off-by: Rohan Garg
---
drivers/gpu/drm/drm_gem.c | 51 ++
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 1 +
incl
On Mon, Sep 16, 2019 at 12:36:19PM +0200, Enric Balletbo i Serra wrote:
> Hi Andrzej and Brian
>
> On 16/9/19 12:02, Andrzej Hajda wrote:
> > On 15.08.2019 02:48, Brian Masney wrote:
> >> When attempting to configure this driver on a Nexus 5 phone (msm8974),
> >> setting up the dummy i2c bus for T
Hi Brian,
On Mon, Sep 16, 2019 at 06:36:14AM -0400, Brian Masney wrote:
> On Mon, Sep 16, 2019 at 12:02:09PM +0200, Andrzej Hajda wrote:
> > On 15.08.2019 02:48, Brian Masney wrote:
> > > When attempting to configure this driver on a Nexus 5 phone (msm8974),
> > > setting up the dummy i2c bus for
https://bugs.freedesktop.org/show_bug.cgi?id=111694
Bug ID: 111694
Summary: [CI][DRMTIP] igt@kms_hdmi_inject@inject-audio - fail -
Failed assertion: glob("/proc/asound/card*/"
ELD_PREFIX "*", GLOB_NOSORT, NULL, &glob_buf) == 0,
https://bugs.freedesktop.org/show_bug.cgi?id=111694
Lakshmi changed:
What|Removed |Added
QA Contact||intel-gfx-bugs@lists.freede
Hi,
On 16/9/19 12:49, Laurent Pinchart wrote:
> Hi Brian,
>
> On Mon, Sep 16, 2019 at 06:36:14AM -0400, Brian Masney wrote:
>> On Mon, Sep 16, 2019 at 12:02:09PM +0200, Andrzej Hajda wrote:
>>> On 15.08.2019 02:48, Brian Masney wrote:
When attempting to configure this driver on a Nexus 5 pho
On Monday, 2019-09-16 11:53:24 +0300, Jani Nikula wrote:
> On Fri, 13 Sep 2019, Eric Engestrom wrote:
> > On Friday, 2019-09-13 14:51:39 +0300, Jani Nikula wrote:
> >> Add helper to check if a drm debug category is enabled. Convert drm core
> >> to use it. No functional changes.
> >>
> >> Signed-
https://bugs.freedesktop.org/show_bug.cgi?id=76
--- Comment #1 from asavah ---
Created attachment 145374
--> https://bugs.freedesktop.org/attachment.cgi?id=145374&action=edit
backtrace 5.3.0
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=76
--- Comment #2 from asavah ---
Still not fixed in 5.3.0, attached new backtrace above.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@li
On 16.09.2019 11:01, Brian Masney wrote:
> Hi Andrzej,
>
> On Mon, Sep 16, 2019 at 10:13:58AM +0200, Andrzej Hajda wrote:
>> Hi Brian,
>>
>> On 15.08.2019 02:48, Brian Masney wrote:
>>> This patch series begins to add support for the external display over
>>> HDMI that is supported on msm8974 SoCs.
On Mon, Sep 16, 2019 at 01:32:58PM +0200, Enric Balletbo i Serra wrote:
> Hi,
>
> On 16/9/19 12:49, Laurent Pinchart wrote:
> > Hi Brian,
> >
> > On Mon, Sep 16, 2019 at 06:36:14AM -0400, Brian Masney wrote:
> >> On Mon, Sep 16, 2019 at 12:02:09PM +0200, Andrzej Hajda wrote:
> >>> On 15.08.2019 0
On Monday, 2019-09-16 12:35:41 +0200, Rohan Garg wrote:
> DRM_IOCTL_BO_SET_LABEL lets you label GEM objects, making it
> easier to debug issues in userspace applications.
>
> Signed-off-by: Rohan Garg
> ---
> drivers/gpu/drm/drm_gem.c | 51 ++
> drivers/gpu/d
Ping? Any further comment on this or can't we merge at least the locking
change?
Christian.
Am 11.09.19 um 12:53 schrieb Christian König:
Am 03.09.19 um 10:05 schrieb Daniel Vetter:
On Thu, Aug 29, 2019 at 04:29:14PM +0200, Christian König wrote:
This patch is a stripped down version of the
On 16.09.2019 14:02, Brian Masney wrote:
> On Mon, Sep 16, 2019 at 01:32:58PM +0200, Enric Balletbo i Serra wrote:
>> Hi,
>>
>> On 16/9/19 12:49, Laurent Pinchart wrote:
>>> Hi Brian,
>>>
>>> On Mon, Sep 16, 2019 at 06:36:14AM -0400, Brian Masney wrote:
On Mon, Sep 16, 2019 at 12:02:09PM +0200
On 9/16/19 12:35 PM, Rohan Garg wrote:
DRM_IOCTL_BO_SET_LABEL lets you label GEM objects, making it
easier to debug issues in userspace applications.
Signed-off-by: Rohan Garg
---
drivers/gpu/drm/drm_gem.c | 51 ++
drivers/gpu/drm/drm_internal.h | 2 ++
https://bugs.freedesktop.org/show_bug.cgi?id=111669
--- Comment #5 from Pierre-Eric Pelloux-Prayer
---
Another env variable to test is: AMD_DEBUG=nongg
Using AMD_DEBUG=nongg and a kernel with the patch from
https://bugs.freedesktop.org/show_bug.cgi?id=111481#c33 I could replay both
traces multi
On Fri, 13 Sep 2019 14:46:46 +0100
Steven Price wrote:
> On 13/09/2019 12:17, Boris Brezillon wrote:
> > So we can choose to wait for all BO users, or just for writers.
> >
> > Signed-off-by: Boris Brezillon
>
> Looks good to me:
>
> Reviewed-by: Steven Price
>
> Although I don't know if
On Fri, 13 Sep 2019 14:44:14 +0100
Steven Price wrote:
> On 13/09/2019 12:17, Boris Brezillon wrote:
> > The READ/WRITE flags are particularly useful if we want to avoid
> > serialization of jobs that read from the same BO but never write to it.
> > The NO_IMPLICIT_FENCE might be useful when the
Le mer. 11 sept. 2019 à 15:41, Harry Wentland a écrit :
>
> On 2019-09-11 4:47 a.m., Benjamin Gaignard wrote:
> > Remove always false comparisons due to limited range of nfl_bpg_offset
> > and scale_increment_interval fields.
> > Warnings detected when compiling with W=1.
> >
> > Signed-off-by: Be
Le jeu. 12 sept. 2019 à 10:57, Yannick Fertré a écrit :
>
> In order to better support video non-burst modes,
> the +20% on pll out is added only in burst mode.
>
> Signed-off-by: Philippe Cornu
> Reviewed-by: Yannick FERTRE
Applied on drm-misc-next,
Thanks,
Benjamin
> ---
> drivers/gpu/drm/s
Le lun. 9 sept. 2019 à 12:29, Benjamin Gaignard
a écrit :
>
> Fix warnings when W=1.
> No code changes, only clean up in sti internal structures and functions
> descriptions.
>
> Signed-off-by: Benjamin Gaignard
For my own reference, applied on drm-misc-next
> ---
> drivers/gpu/drm/sti/sti_cur
Le lun. 9 sept. 2019 à 16:41, Benjamin Gaignard
a écrit :
>
> Fix warnings with W=1.
> Few for_each macro set variables that are never used later.
> Prevent warning by marking these variables as __maybe_unused.
>
A little up on this one because it may exist others ways to fix these warnings.
Get
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #34 from jaapbuur...@gmail.com ---
How big is the improvement? Is the issue completely gone, or is it still there?
The KSP example also reliably triggers the flickering for me, and I am using
the exact same monitor.
These LFC patches
On Mon, 16 Sep 2019, Eric Engestrom wrote:
> On Monday, 2019-09-16 11:53:24 +0300, Jani Nikula wrote:
>> On Fri, 13 Sep 2019, Eric Engestrom wrote:
>> > On Friday, 2019-09-13 14:51:39 +0300, Jani Nikula wrote:
>> >> Add helper to check if a drm debug category is enabled. Convert drm core
>> >> to
Hi Laurent/Kieran,
I need to upstream a driver for a display controller that within its registers
memory region contains registers related to a PWM device. The PWM device is for
controlling the backlight of the display.
Ideally, I would like to create a separated driver for the PWM, so that I ca
On Sun, Sep 15, 2019 at 12:13:23AM -0700, Dmitry Torokhov wrote:
> We do not really need to use API that fetches GPIO data from an
> arbitrary device tree node, as we are dealing with device tree node
> assigned to the device structure. We can easily switch to
> devm_gpiod_get_optional() plus gpiod
https://bugs.freedesktop.org/show_bug.cgi?id=109628
Rohan Lean changed:
What|Removed |Added
CC||ro...@rohanlean.de
--- Comment #18 from Ro
From: Thierry Reding
Commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before TTM
object") introduced a subtle change in how the buffer allocation size is
handled. Prior to that change, the size would get aligned to at least a
page, whereas after that change a non-page-aligned size would g
From: Thierry Reding
Prior to commit 019cbd4a4feb ("drm/nouveau: Initialize GEM object before
TTM object"), the reservation object was locked across all of the buffer
object creation.
After splitting nouveau_bo_new() into separate nouveau_bo_alloc() and
nouveau_bo_init() functions, the reservati
From: Thierry Reding
Writing the 0x1704 (BUS_BAR1_BLOCK) register causes the GPU to probe the
memory region at the programmed address. The result is an address decode
error in the external memory controller because address 0, which is what
is written to the register, is not designated as accessib
From: Thierry Reding
When the last reference to a TTM BO is dropped, ttm_bo_release() will
acquire the DMA reservation object's wound/wait mutex while trying to
clean up (ttm_bo_cleanup_refs_or_queue() via ttm_bo_release()). It is
therefore essential that drm_gem_object_release() be called after
From: Thierry Reding
Hi Ben,
these are fixes for a couple of issues that I've been running into when
testing on various Tegra boards. The first two patches fix up issues in
the fix that I had sent out earlier to fix the regression introduced in
drm-misc-next. The first one is critical because it
On Mon, Sep 16, 2019 at 10:11 AM Koenig, Christian
wrote:
>
> Hi Steven,
>
> the problem seems to be than panfrost is trying to sleep while freeing a
> job. E.g. it tries to take a mutex.
>
> That is not allowed any more since we need to free the jobs from atomic
> and even interrupt context.
>
>
On Mi, 2019-09-11 at 19:40 -0700, Guido Günther wrote:
> Add #cooling-cells for when the gpu acts as a cooling device.
>
> Signed-off-by: Guido Günther
Reviewed-by: Lucas Stach
> ---
> .../devicetree/bindings/display/etnaviv/etnaviv-drm.txt | 1 +
> 1 file changed, 1 insertion(+)
>
On Mi, 2019-09-11 at 19:40 -0700, Guido Günther wrote:
> Temperature and hysteresis were picked after the CPU.
>
> Signed-off-by: Guido Günther
Reviewed-by: Lucas Stach
> ---
> arch/arm64/boot/dts/freescale/imx8mq.dtsi | 15 +++
> 1 file changed, 15 insertions(+)
>
> diff --git a
From: Thierry Reding
Hi Ben,
I messed up the ordering of patches in my tree a bit, so these two fixes
got separated from the others. I don't consider these particularily
urgent because the crash that the first one fixes only happens on gp10b
which we don't enable by default yet and the second pa
From: Thierry Reding
Fill in BAR2 callbacks for instance memory. There's no BAR2 on Tegra
GPUs, but buffers are all in system memory anyway, so just return the
plain address.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/subdev/instmem/gk20a.c | 30 +++
1 file change
From: Thierry Reding
When Nouveau is instantiated on top of a platform device, the dev->pdev
field will be NULL and calling pci_disable_device() will crash. Move the
PCI disabling code to the PCI specific driver removal code.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nouveau_dr
Am 16.09.19 um 16:24 schrieb Daniel Vetter:
> On Mon, Sep 16, 2019 at 10:11 AM Koenig, Christian
> wrote:
>> Hi Steven,
>>
>> the problem seems to be than panfrost is trying to sleep while freeing a
>> job. E.g. it tries to take a mutex.
>>
>> That is not allowed any more since we need to free the
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #35 from Clément Guérin (li...@protonmail.com) ---
If you haven't updated to linux 5.2 yet, you should because it fixed constant
flickering when in LFC mode.
This additional patch helps when freesync goes in and out of LFC mode. It's
https://bugzilla.kernel.org/show_bug.cgi?id=202445
--- Comment #36 from Clément Guérin (li...@protonmail.com) ---
If you haven't updated to linux 5.2 yet, you should because it fixed constant
flickering when in LFC mode.
This additional patch helps when the monitor goes in and out of LFC mode. It
From: Thierry Reding
The GPUs found on Tegra SoCs have registers that can be used to read the
WPR configuration. Use these registers instead of reaching into the
memory controller's register space to read the same information.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/subdev/secbo
From: Thierry Reding
Hi,
the GPU on Jetson TX2 (GP10B) does not work properly on all devices. Why
exactly is not clear, but there are slight differences between the SKUs
that were tested. It turns out that the biggest issue is that on some
devices (e.g. the one that I have), pulsing the GPU rese
From: Thierry Reding
If the GPU clock has not had a rate set, initialize it to the maximum
clock rate to make sure it does run.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm
From: Thierry Reding
When the GPU powergate is controlled by a generic power domain provider,
the reset will automatically be asserted and deasserted as part of the
power-ungating procedure.
On some Jetson TX2 boards, doing an additional assert and deassert of
the GPU outside of the power-ungate
From: Thierry Reding
The GPU integrated in NVIDIA Tegra SoCs is connected to system memory
via two paths: one direct path to the memory controller and another path
that goes through a system MMU first. It's not typically necessary to go
through the system MMU because the GPU's MMU can already map
From: Thierry Reding
There are extra registers that need to be programmed to make the level 2
cache work on GP10B, such as the stream ID register that is used when an
SMMU is used to translate memory addresses.
Signed-off-by: Thierry Reding
---
.../gpu/drm/nouveau/include/nvkm/subdev/ltc.h |
From: Thierry Reding
Detect if the DMA API is backed by an IOMMU and set the IOMMU bit if so.
This is needed to make sure IOMMU addresses are properly translated even
the explicit IOMMU API is not used.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/subdev/instmem/gk20a.c | 35 ++
From: Thierry Reding
If the GPU is already attached to an IOMMU, don't detach it and setup an
explicit IOMMU domain. Since Nouveau can now properly handle the case of
the DMA API being backed by an IOMMU, just continue using the DMA API.
Signed-off-by: Thierry Reding
---
.../drm/nouveau/nvkm/e
From: Thierry Reding
The GPU can usually address more than 32-bit, even without being
attached to an IOMMU. However, if the GPU is not attached to an IOMMU,
it's likely that there is no IOMMU in the system, in which case any
buffers allocated by Nouveau will likely end up in a region of memory
th
From: Thierry Reding
gp10b uses the new engine enumeration mechanism introduced in the Pascal
architecture. As a result, the copy engine, which used to be at index 2
for prior Tegra GPU instantiations, has now moved to index 0. Fix up the
index and also use the gp100 variant of the copy engine cl
From: Thierry Reding
The GPU has a connection to the ARM SMMU found on Tegra186, which can be
used to support large pages. Make sure the GPU is attached to the SMMU
to take advantage of its capabilities.
Signed-off-by: Thierry Reding
---
arch/arm64/boot/dts/nvidia/tegra186.dtsi | 1 +
1 file c
From: Alexandre Courbot
Enable the GPU node for the Jetson TX2 board.
Signed-off-by: Alexandre Courbot
Signed-off-by: Thierry Reding
---
arch/arm64/boot/dts/nvidia/tegra186-p2771-.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/nvidia/tegra186-p2771-.dt
https://bugs.freedesktop.org/show_bug.cgi?id=109628
--- Comment #19 from peter m ---
Created attachment 145377
--> https://bugs.freedesktop.org/attachment.cgi?id=145377&action=edit
kernel 5.2.14-200 dmesg output
--
You are receiving this mail because:
You are the assignee for the bug.
From: Thierry Reding
These implementations are now all unused. Remove them.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 2 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgf100.c | 14 --
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgk104.c |
From: Thierry Reding
Some registers and instance block entries need the aperture to be
programmed correctly. This is important on recent Tegra GPUs where
the GPU actually checks the value of this field and faults if an
invalid aperture is programmed.
For example GV11B no longer supports VRAM and
From: Thierry Reding
The engine field in the FIFO fault information registers is actually 9
bits wide.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/nvkm/subdev/fault/gv100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fau
From: Thierry Reding
The fault information register contains data about the aperture that
caused the failure. This can be useful in debugging aperture related
programming bugs.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/nouveau/include/nvkm/subdev/fault.h | 1 +
drivers/gpu/drm/nouveau/
From: Thierry Reding
The aperture of a buffer is always specific to where its memory was
allocated from. Furthermore, the encoding of the aperture is always
the same, regardless of GPU generation.
Implement the memory target to aperture conversion in one central
place and make the aperture indep
From: Thierry Reding
Hi Ben,
these are a couple of patches that are in preparation for adding GV11B
support. The fundamental issue that these are trying to solve is that
the GV11B is the first Tegra incarnation of the GPU where the aperture
really matters. All prior generations would accept any
From: Thierry Reding
The gk20a (as well as all subsequent Tegra instantiations of the GPU) do
in fact use the same apertures as regular GPUs. Prior to gv11b there are
no checks in hardware for the aperture, so we get away with setting VRAM
as the aperture for buffers that are actually in system m
Hi Thierry,
On 16/09/2019 16:04, Thierry Reding wrote:
From: Thierry Reding
If the GPU is already attached to an IOMMU, don't detach it and setup an
explicit IOMMU domain. Since Nouveau can now properly handle the case of
the DMA API being backed by an IOMMU, just continue using the DMA API.
Hi Jitao.
> Changes since v4:
You are hit by some of the progress made in the kernel.
New dispaly bindings are preferred to be in meta-schma formal (.yaml
files).
This allows more formals checks and this is the format that we
hope all display bindigns will migrate over to use once
someone steps u
On Mon, Sep 16, 2019 at 04:35:30PM +0100, Ben Dooks wrote:
> On 16/09/2019 16:04, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > There are extra registers that need to be programmed to make the level 2
> > cache work on GP10B, such as the stream ID register that is used when an
> > SMMU i
On Mon, Sep 16, 2019 at 05:49:46PM +0200, Thierry Reding wrote:
> On Mon, Sep 16, 2019 at 04:35:30PM +0100, Ben Dooks wrote:
> > On 16/09/2019 16:04, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > There are extra registers that need to be programmed to make the level 2
> > > cache w
On Mon, Sep 16, 2019 at 04:29:18PM +0100, Robin Murphy wrote:
> Hi Thierry,
>
> On 16/09/2019 16:04, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > If the GPU is already attached to an IOMMU, don't detach it and setup an
> > explicit IOMMU domain. Since Nouveau can now properly handle th
On 16/09/2019 16:57, Thierry Reding wrote:
On Mon, Sep 16, 2019 at 04:29:18PM +0100, Robin Murphy wrote:
Hi Thierry,
On 16/09/2019 16:04, Thierry Reding wrote:
From: Thierry Reding
If the GPU is already attached to an IOMMU, don't detach it and setup an
explicit IOMMU domain. Since Nouveau c
On Mon, Sep 16, 2019 at 03:59:04PM +0200, Thierry Reding wrote:
> On Sun, Sep 15, 2019 at 12:13:23AM -0700, Dmitry Torokhov wrote:
> > We do not really need to use API that fetches GPIO data from an
> > arbitrary device tree node, as we are dealing with device tree node
> > assigned to the device s
https://bugs.freedesktop.org/show_bug.cgi?id=111682
--- Comment #1 from Andrey Grodzovsky ---
Which kernel branch are you using ? I couldn't find
amdgpu_vm_update_directories in latest code in amd-staging-drm-next and turns
out it was renamed to amdgpu_vm_update_pdes in
78b20c2ee6788ba0df8b36b13
On Tue, Sep 17, 2019 at 02:46:48AM +0900, Masahiro Yamada wrote:
> (+CC Stephen Rothwell, Mark Brown)
>
> On Mon, Sep 16, 2019 at 1:46 PM Austin Kim wrote:
> >
> > gcc throws compile error with below message:
>
> GNU Make throws ...
>
>
I don't have the original patch so I don't know what the
https://bugs.freedesktop.org/show_bug.cgi?id=111232
--- Comment #9 from Andrey Grodzovsky ---
I noticed IOMMU page fault in the log - is disabling iommu helps ? (from grub
cmdline add iommu=off)
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=111481
--- Comment #47 from Mathieu Belanger ---
Naa, Random crash still occur with FileZilla, so there not totally gone for me.
I put nodma back because I use that system for work.
--
You are receiving this mail because:
You are the assignee for the
1 - 100 of 150 matches
Mail list logo
