On Mon, 16 Sep 2019, Marek Olšák wrote:
> The purpose is to get rid of all PCI ID tables for all drivers in
> userspace. (or at least stop updating them)
>
> Mesa common code and modesetting will use this.
I'd think this would warrant a high level description of what you want
to achieve in the
https://bugs.freedesktop.org/show_bug.cgi?id=111236
--- Comment #15 from Julien Isorce ---
https://gitlab.freedesktop.org/mesa/mesa/merge_requests/2005
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
https://bugzilla.kernel.org/show_bug.cgi?id=204885
--- Comment #3 from no2stable (pro...@outlook.com) ---
Created attachment 285023
--> https://bugzilla.kernel.org/attachment.cgi?id=285023=edit
anathor picture of the graphic glitch
--
You are receiving this mail because:
You are watching
https://bugzilla.kernel.org/show_bug.cgi?id=204885
--- Comment #2 from no2stable (pro...@outlook.com) ---
Created attachment 285021
--> https://bugzilla.kernel.org/attachment.cgi?id=285021=edit
a picture of the graphic glitch
--
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=204885
--- Comment #1 from no2stable (pro...@outlook.com) ---
Created attachment 285019
--> https://bugzilla.kernel.org/attachment.cgi?id=285019=edit
5.3.0 kernel config
--
You are receiving this mail because:
You are watching the assignee of
https://bugzilla.kernel.org/show_bug.cgi?id=204885
Bug ID: 204885
Summary: ryzen 2500U cause graphics glitch in all browsers with
kernel version 5.2.x+
Product: Drivers
Version: 2.5
Kernel Version: 5.3.0
Hardware: All
Hey Dave,
A couple of fixes from Thierry fixing issues as a result of the
reservation object rework in this cycle, as well as a fix from Lyude
to allow the driver to load on Thinkpad P71.
Thanks,
Ben.
The following changes since commit 9a60b2990d6c2b7ab935fe0a5cc274de67d98bed:
Merge branch
Hi Gareth,
> From: Gareth Williams, Sent: Monday, September 16, 2019 10:56 PM
>
> 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
On Tue, 17 Sep 2019 at 01:04, Thierry Reding wrote:
>
> 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.
>
>
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote:
>
> From: Thierry Reding
>
> The engine field in the FIFO fault information registers is actually 9
> bits wide.
Looks like this is true for fault buffer parsing too.
>
> Signed-off-by: Thierry Reding
> ---
>
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote:
>
> 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.
Should this be parsed for fault buffer entries too?
>
On Tue, 17 Sep 2019 at 01:18, Thierry Reding wrote:
>
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=93652
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=100638
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #2 from Timothy
https://bugs.freedesktop.org/show_bug.cgi?id=103743
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Mon, Sep 16, 2019 at 1:30 PM Vasily Khoruzhick wrote:
>
> On Sun, Sep 15, 2019 at 2:18 PM Mark Brown wrote:
> >
> > Hi all,
>
> Hi Mark,
>
> > Today's linux-next merge of the drm tree got a conflict in:
> >
> > drivers/gpu/drm/lima/lima_gem.c
> >
> > between commit:
> >
> >
https://bugs.freedesktop.org/show_bug.cgi?id=100239
--- Comment #27 from Timothy Arceri ---
(In reply to Bruno Jacquet (Xaapyks) from comment #26)
> (In reply to Michel Dänzer from comment #25)
> > (In reply to Bruno Jacquet (Xaapyks) from comment #23)
> > > So I'd say the issue is still there.
https://bugs.freedesktop.org/show_bug.cgi?id=111669
--- Comment #6 from Doug Ty ---
Unfortunately I'm still getting the hang with the kernel patch +
AMD_DEBUG=nongg, both ingame as well as replaying the apitraces. Same messages
in journalctl
Not sure how useful it'll be but I've made another
On Thu, Sep 12, 2019 at 10:55:47AM +0100, Linus Walleij wrote:
> On Wed, Sep 11, 2019 at 8:52 AM Dmitry Torokhov
> wrote:
>
> > If we agree in principle, I would like to have the very first 3 patches
> > in an immutable branch off maybe -rc8 so that it can be pulled into
> > individual
The purpose is to get rid of all PCI ID tables for all drivers in
userspace. (or at least stop updating them)
Mesa common code and modesetting will use this.
Marek
On Sat, Sep 7, 2019 at 3:48 PM Daniel Vetter wrote:
> On Sat, Sep 7, 2019 at 3:18 AM Rob Clark wrote:
> >
> > On Fri, Sep 6,
DRM Fb driver expects multiple CRTCs if it sees connector->has_tile
is set, but we need to handle tile support and look for multiple CRTCs
only for the modes that match the tile size. The other modes should
be able to be displayed without tile support or uisng single CRTC.
This patch adds the
On Fri, Sep 13, 2019 at 12:25 PM Alyssa Rosenzweig
wrote:
>
> I'm conflicted on this series.
>
> On the one hand, userspace should obviously not be able to crash the
> kernel. So the crash should be fixed in one way or another.
>
> On the other hand, userspace really has to supply all the BOs it
On Fri, Sep 13, 2019 at 12:43 PM Alyssa Rosenzweig
wrote:
>
> Patch 1 is:
>
> Acked-by: Alyssa Rosenzweig
>
> Patch 2 is:
>
> Reviewed-by: Alyssa Rosenzweig
In the future, please reply to each patch with your tag. The reason
being is patchwork will automatically add them
On Tue, Sep 17, 2019 at 02:46:48AM +0900, Masahiro Yamada wrote:
> On Mon, Sep 16, 2019 at 1:46 PM Austin Kim wrote:
> > gcc throws compile error with below message:
> GNU Make throws ...
Xinpeng Liu via Nick Desaulniers sent a description of the problem and a
patch so I think I'll be able to
Thanks for the patch and reviews, pushed to drm-misc
Regards
Manasi
On Mon, Sep 16, 2019 at 02:12:14PM -0700, Souza, Jose wrote:
> On Mon, 2019-09-16 at 12:39 -0700, Manasi Navare wrote:
> > On Mon, Sep 16, 2019 at 07:34:32PM +, Souza, Jose wrote:
> > > Someone with drm-misc commit access
On Fri, Sep 13, 2019 at 8:44 AM 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
On Fri, Sep 13, 2019 at 6:17 AM 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.
Any data on performance differences?
> The NO_IMPLICIT_FENCE might be useful when the user knows
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #9 from Michael Haworth ---
I updated to the 5.3 release but has not fixed the issue
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On Mon, Sep 16, 2019 at 02:06:46PM -0700, Nick Desaulniers wrote:
> On Sun, Sep 15, 2019 at 2:47 PM Mark Brown wrote:
> > 0f0727d971f6fdf ("drm/amd/display: readd -msse2 to prevent Clang from
> > emitting libcalls to undefined SW FP routines")
> ^ this patch is now broken due to the SHA
On Fri, Sep 13, 2019 at 7:29 AM Gerd Hoffmann wrote:
>
Version? Pretty sure this is not v1.
> DEFINE_DRM_GEM_SHMEM_FOPS is identical
> to DEFINE_DRM_GEM_FOPS now, drop it.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/drm/drm_gem_shmem_helper.h | 26 -
>
> From: Dexuan Cui
> Sent: Monday, September 16, 2019 2:46 PM
> To: Michael Kelley ; Wei Hu ;
> b.zolnier...@samsung.com; linux-hyp...@vger.kernel.org;
> dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org;
> linux-ker...@vger.kernel.org; Stephen Hemminger
> ; sas...@kernel.org; Haiyang
Thanks,
-- Dexuan
> -Original Message-
> From: linux-hyperv-ow...@vger.kernel.org
> On Behalf Of Dexuan Cui
> Sent: Thursday, September 12, 2019 11:38 PM
> To: Wei Hu ; Michael Kelley ;
> rdun...@infradead.org; shc_w...@mail.ru; gre...@linuxfoundation.org;
> lee.jo...@linaro.org;
> From: linux-hyperv-ow...@vger.kernel.org
> On Behalf Of Dexuan Cui
> Sent: Thursday, September 12, 2019 11:39 PM
> To: Michael Kelley ; Wei Hu ;
> b.zolnier...@samsung.com; linux-hyp...@vger.kernel.org;
> dri-devel@lists.freedesktop.org; linux-fb...@vger.kernel.org;
>
On Mon, 2019-09-16 at 12:39 -0700, Manasi Navare wrote:
> On Mon, Sep 16, 2019 at 07:34:32PM +, Souza, Jose wrote:
> > Someone with drm-misc commit access could push this?
> >
>
> Sure will push this series.
Thanks Manasi
>
> Manasi
>
> > Thanks
> >
> > On Sun, 2019-09-15 at 11:36
On Sun, Sep 15, 2019 at 2:47 PM Mark Brown wrote:
>
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/amd/display/dc/dml/Makefile
>
> between commit:
>
> 54b8ae66ae1a345 ("kbuild: change *FLAGS_.o to take the path
> relative to $(obj)")
>
> from
On Mon, Sep 16, 2019 at 1:12 PM Drew Davenport wrote:
>
> The arguments related to IOMMU port name have been unused since
> commit 944fc36c31ed ("drm/msm: use upstream iommu") and can be removed.
>
> Signed-off-by: Drew Davenport
> ---
> Rob, in the original commit the port name stuff was left
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #8 from Michael Haworth ---
Thanks for the explanation. I only recently bought the graphics card and the
bug occurred the first time I used it on linux
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #7 from Felix Schwarz ---
>> If this is a regression, can you bisect?
> do not know how to answer your question, this is my first bug report.
Regression: Was the bug always present (as far as you know) or did it work in
the past?
The arguments related to IOMMU port name have been unused since
commit 944fc36c31ed ("drm/msm: use upstream iommu") and can be removed.
Signed-off-by: Drew Davenport
---
Rob, in the original commit the port name stuff was left intentionally.
Would it be alright to remove it now?
Patches 13, 14 and this 15 look ok to me. Those num/den combos in 13 I
cannot bet my head on but the plumbing look all ok.
Also if on 1..8 some patch wasn't pushed yet, those are all
Reviewed-by: Juha-Pekka Heikkila
Ville Syrjala kirjoitti 8.7.2019 klo 15.53:
From: Ville Syrjälä
Now that
>-Original Message-
>From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
>Of Chris Wilson
>Sent: Sunday, September 15, 2019 2:46 PM
>To: dri-devel@lists.freedesktop.org
>Cc: intel-...@lists.freedesktop.org
>Subject: [PATCH 2/2] drm/mm: Pack allocated/scanned boolean
On Mon, Sep 16, 2019 at 07:34:32PM +, Souza, Jose wrote:
> Someone with drm-misc commit access could push this?
>
Sure will push this series.
Manasi
> Thanks
>
> On Sun, 2019-09-15 at 11:36 +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: series starting with [CI,1/2]
Someone with drm-misc commit access could push this?
Thanks
On Sun, 2019-09-15 at 11:36 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,1/2] drm/connector: Share with non-
> atomic drivers the function to get the single encoder
> URL :
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #6 from Michael Haworth ---
I have attached the logs but do not know how to answer your question, this is
my first bug report.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #5 from Michael Haworth ---
Created attachment 145383
--> https://bugs.freedesktop.org/attachment.cgi?id=145383=edit
Xorg log after booting with HW cursor enabled
--
You are receiving this mail because:
You are the assignee for
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #4 from Michael Haworth ---
Created attachment 145382
--> https://bugs.freedesktop.org/attachment.cgi?id=145382=edit
dmesg output after booting with HW cursor enabled
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=111691
--- Comment #3 from Alex Deucher ---
Please attach your xorg log (if using X) and your dmesg output. If this is a
regression, can you bisect?
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111682
--- Comment #2 from Pierre-Eric Pelloux-Prayer
---
(In reply to Andrey Grodzovsky from comment #1)
> 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
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
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
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
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
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
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
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
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
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
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
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.
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 +
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
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
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
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
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
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
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=edit
kernel 5.2.14-200 dmesg output
--
You are receiving this mail because:
You are the assignee for the
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
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
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
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
---
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
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
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
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
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
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
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
---
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.
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
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
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
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
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
---
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
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 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.
>
>
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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=109628
Rohan Lean changed:
What|Removed |Added
CC||ro...@rohanlean.de
--- Comment #18 from
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
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
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
>> >>
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
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
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
> ---
>
1 - 100 of 149 matches
Mail list logo
