Hi Noralf,
see comment bellow.
po 29. 7. 2019 v 21:55 odesílatel Noralf Trønnes napsal:
>
> Embed mipi_dbi in struct ili9341.
> Rebase on moved mipi-dbi, rename variable name.
> Add backlight_device to panel struct.
> mipi_dbi_hw_reset() already has a NULL check on the reset gpio.
> Prepare for m
Hi Noralf,
the patch series looks good, see comments in the patch emails.
One question: is there a general mechanism to tell a driver not to use
parallel RGB even though
the display supports it and "port" is specified in the device-tree?
Josef
po 29. 7. 2019 v 21:55 odesílatel Noralf Trønnes na
Hi Jyri.
On Tue, Jul 30, 2019 at 09:03:11AM +0300, Jyri Sarha wrote:
> On 16/07/2019 09:42, Sam Ravnborg wrote:
> > Dropped drmP.h and all other header files not used by tilcdc_drv.h.
> > Added the minimal includes and forwards to make the header file
> > self-contained.
> >
> > Then dropped the
On 17/07/2019 08:09, Keerthy wrote:
Fix the below build warning/Error
drivers/gpu/drm/tilcdc/tilcdc_crtc.c: In function ‘tilcdc_crtc_set_mode’:
drivers/gpu/drm/tilcdc/tilcdc_crtc.c:384:8: error: this statement may fall
through [-Werror=implicit-fallthrough=]
reg |= LCDC_V2_TFT_24BPP_UNPACK;
We can already use DMA_ATTR_WRITE_COMBINE or the _wc prefixed version,
so remove the third way of doing things.
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 11 +--
include/linux/dma-mapping.h | 9 -
2 files changed, 5 insertions(+), 15 dele
On 16/07/2019 09:42, Sam Ravnborg wrote:
> Dropped drmP.h and all other header files not used by tilcdc_drv.h.
> Added the minimal includes and forwards to make the header file
> self-contained.
>
> Then dropped the remaining uses of drmP.h and fixed all fall-out.
>
> Signed-off-by: Sam Ravnborg
https://bugzilla.kernel.org/show_bug.cgi?id=204145
Michael Ellerman (mich...@ellerman.id.au) changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Co
Reviewed-by: Yan Zhao
> -Original Message-
> From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On
> Behalf Of Zhenyu Wang
> Sent: Wednesday, June 12, 2019 11:23 AM
> To: Hariprasad Kelam
> Cc: David Airlie ; intel-...@lists.freedesktop.org; Joonas
> Lahtinen ; linu
Signed-off-by: Pei-Hsuan Hung
Acked-by: Liviu Dudau
Cc: triv...@kernel.org
---
Hi Liviu, thanks for your reply.
This patch is generated by a script so at first I didn't notice there is
also a typo in the word coefficient. I've fixed the typo in this
version.
arch/powerpc/kernel/eeh.c
https://bugs.freedesktop.org/show_bug.cgi?id=111234
--- Comment #3 from Michael J Evans ---
After looking at the linked bug and your description of my environment (dual
screen and yes KDE / Plasma as a compositor potentially exposing whatever
corner case this is in the kernel driver):
I agree th
https://bugs.freedesktop.org/show_bug.cgi?id=111243
--- Comment #2 from jacque8...@gmail.com ---
That fixed the problem. Thank you so much.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@l
Hi Yue,
Thank you for the patch.
On Mon, Jul 29, 2019 at 05:05:20PM +0800, YueHaibing wrote:
> If CONFIG_DRM_TOSHIBA_TC358764=y but CONFIG_DRM_KMS_HELPER=m,
> building fails:
>
> drivers/gpu/drm/bridge/tc358764.o:(.rodata+0x228): undefined reference to
> `drm_atomic_helper_connector_reset'
> dr
https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #11 from Alex Deucher ---
(In reply to Alexander Mezin from comment #10)
> (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 p
Move basic members of ttm_mem_type_manager into a new DRM memory region
structure. The idea is for this base structure to be nested inside
the TTM structure and later in Intel's proposed intel_memory_region.
As comments in the code suggest, the following future work can extend
the usefulness of t
Introduce DRM memory region types to be common for both drivers using
TTM and for i915. For now, TTM continues to define it's own set but
uses the DRM base definitions.
Signed-off-by: Brian Welty
---
include/drm/drm_mm.h| 8
include/drm/ttm/ttm_placement.h | 8
2 f
Some fields are deleted from intel_memory_region in favor of instead
using the new nested drm_mem_region structure.
Note, this is based upon unmerged i915 series [1] in order to show how
i915 might begin to integrate the proposed drm_mem_region.
[1] https://lists.freedesktop.org/archives/intel-gf
[ By request, resending to include amd-gfx + intel-gfx. Since resending,
I fixed the nit with ordering of header includes that Sam noted. ]
This RFC series is first implementation of some ideas expressed
earlier on dri-devel [1].
Some of the goals (open for much debate) are:
- Create common
On Mon, Jul 29, 2019 at 04:52:30PM -0700, Jose Souza wrote:
Series is Reviewed-by: José Roberto de Souza
Thanks, applied.
Lucas De Marchi
On Mon, 2019-07-15 at 11:53 -0700, Lucas De Marchi wrote:
From: Rodrigo Vivi
Add the PCI ID import for EHL.
Cc: Rodrigo Vivi
Signed-off-by: James A
On Mon, Jul 29, 2019 at 8:23 AM Torsten Duwe wrote:
>
> On Fri, Jul 26, 2019 at 06:36:01PM +0200, Maxime Ripard wrote:
> > > +
> > > + dvdd12-supply:
> > > +maxItems: 1
> > > +description: Regulator for 1.2V digital core power.
> > > +$ref: /schemas/types.yaml#/definitions/phandle
> >
Series is Reviewed-by: José Roberto de Souza
On Mon, 2019-07-15 at 11:53 -0700, Lucas De Marchi wrote:
> From: Rodrigo Vivi
>
> Add the PCI ID import for EHL.
>
> Cc: Rodrigo Vivi
> Signed-off-by: James Ausmus
> Signed-off-by: Lucas De Marchi
> ---
> intel/intel_chipset.c | 1 +
> 1 file c
On Mon, Jul 29, 2019 at 04:42:01PM -0700, Ralph Campbell wrote:
>
> On 7/29/19 7:28 AM, Christoph Hellwig wrote:
> > The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> > where it can be replaced with a simple boolean local variable.
> >
> > Signed-off-by: Christoph Hellwig
On Mon, Jul 29, 2019 at 05:28:35PM +0300, Christoph Hellwig wrote:
> There isn't any good reason to pass callbacks to migrate_vma. Instead
> we can just export the three steps done by this function to drivers and
> let them sequence the operation without callbacks. This removes a lot
> of boilerp
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
where it can be replaced with a simple boolean local variable.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
include/linux/migrate.h | 1 -
mm/migrate.
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
No one ever checks this flag, and we could easily get that information
from the page if needed.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 3 +--
include/linux/migrate.h
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
We don't use this flag anymore, so remove it.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
include/linux/migrate.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/include/linux/migrate.h b/include/linux/migrate.h
index
On Mon, Jul 29, 2019 at 05:28:43PM +0300, Christoph Hellwig wrote:
> The MIGRATE_PFN_WRITE is only used locally in migrate_vma_collect_pmd,
> where it can be replaced with a simple boolean local variable.
>
> Signed-off-by: Christoph Hellwig
NAK that flag is useful, for instance a anonymous vma
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor the main copy page to vram routine out into a helper that acts
on a single page and which doesn't require the nouveau_dmem_migrate
structure for argument passing. As an added benefit the new version
only allocates the dma address array once an
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor the main copy page to ram routine out into a helper that acts on
a single page and which doesn't require the nouveau_dmem_fault
structure for argument passing. Also remove the loop over multiple
pages as we only handle one at the moment, altho
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor out the end of fencing logic from the two migration routines.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 33 --
1 file changed, 15 insertions(+), 1
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
Factor out the repeated device memory address calculation into
a helper.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 42 +++---
1 file changed, 17 insertions(+
On Fri, Jul 26, 2019 at 08:47:21AM -0300, Mauro Carvalho Chehab wrote:
> Some files got renamed but probably due to some merge conflicts,
> a few references still point to the old locations.
>
> Signed-off-by: Mauro Carvalho Chehab
> Acked-by: Wolfram Sang # I2C part
> Reviewed-by: Jerry Hoemann
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
When we start a new batch of dma_map operations we need to reset dma_nr,
as we start filling a newly allocated array.
Signed-off-by: Christoph Hellwig
Reviewed-by: Ralph Campbell
---
drivers/gpu/drm/nouveau/nouveau_dmem.c | 1 +
1 file chang
https://bugs.freedesktop.org/show_bug.cgi?id=111232
--- Comment #2 from bibitocarlos ---
(In reply to Alex Deucher from comment #1)
> Can you bisect?
I'm gonna try ^^, never did it before and leave to holydays Friday.
I'm gonna start with RC, then whith commits.
You think it's a proper way ?
--
On 7/29/19 7:28 AM, Christoph Hellwig wrote:
There isn't any good reason to pass callbacks to migrate_vma. Instead
we can just export the three steps done by this function to drivers and
let them sequence the operation without callbacks. This removes a lot
of boilerplate code as-is, and will a
Mark switch cases where we are expecting to fall through.
This patch fixes the following warning (Building: arm):
drivers/gpu/drm/sti/sti_hdmi.c: In function ‘hdmi_audio_configure’:
drivers/gpu/drm/sti/sti_hdmi.c:851:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
audio
https://bugs.freedesktop.org/show_bug.cgi?id=110637
--- Comment #10 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.
Do you mean "Mesa OpenCL is not supporte
On Mon, Jul 29, 2019 at 12:58 PM Oleksandr Suvorov
wrote:
>
> On Thu, Jul 25, 2019 at 5:41 PM maxime.rip...@free-electrons.com
> wrote:
> >
> > On Thu, Jul 25, 2019 at 11:05:23AM +, Oleksandr Suvorov wrote:
> > >
> > > Even in source code of this driver there is an author's description:
> > >
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #54 from ReddestDream ---
(In reply to Peter Hercek from comment #52)
> I'm getting hangs-up with kernels 5.2.3 (often) and 5.1.15 (less often).
> Radeon VII with 3 monitors. Each monitor connected through DP.
I hear that 5.0.0.13 i
https://bugs.freedesktop.org/show_bug.cgi?id=110963
Jeremy Newton changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
--- Comment #3 from Jeremy New
https://bugs.freedesktop.org/show_bug.cgi?id=110961
--- Comment #3 from Jeremy Newton ---
I believe libdrm is open source with minor patches.
MIT does not require distributing source code, although with that said, I am
looking into doing this none the less.
--
You are receiving this mail becau
https://bugs.freedesktop.org/show_bug.cgi?id=110962
--- Comment #3 from Jeremy Newton ---
This configuration is not supported. PRO unconditionally requires dkms.
I will try to update the documentation.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=110956
--- Comment #8 from Jeremy Newton ---
A few notes:
- Installing on 32bit is unsupported, but you could in theory still do it as I
don't thing we block this. This configuration is not advised.
- I am looking into a better way of providing source
https://bugs.freedesktop.org/show_bug.cgi?id=110956
--- Comment #7 from Alex Deucher ---
(In reply to Eric Engestrom from comment #6)
> (In reply to Ilia Mirkin from comment #5)
> > I think it's the right bugracker. Note that DRM/AMDgpu-pro component. It's
> > meant for the AMD developers who ver
https://bugs.freedesktop.org/show_bug.cgi?id=110967
Jeremy Newton changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110956
Bug 110956 depends on bug 110967, which changed state.
Bug 110967 Summary: Naming packages with pro suffix depending if open or close
source
https://bugs.freedesktop.org/show_bug.cgi?id=110967
What|Removed |Ad
https://bugs.freedesktop.org/show_bug.cgi?id=110957
Jeremy Newton changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110956
Bug 110956 depends on bug 110957, which changed state.
Bug 110957 Summary: wsa-amdgpu package has empty copyright file
https://bugs.freedesktop.org/show_bug.cgi?id=110957
What|Removed |Added
---
https://bugs.freedesktop.org/show_bug.cgi?id=110960
Jeremy Newton changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110956
Bug 110956 depends on bug 110960, which changed state.
Bug 110960 Summary: Non-existent alternative dependencies in some deb packages
https://bugs.freedesktop.org/show_bug.cgi?id=110960
What|Removed |Added
https://bugs.freedesktop.org/show_bug.cgi?id=111243
--- Comment #1 from Jeremy Newton ---
It looks like you didn't do a clean install. For the time being, we recommend a
full uninstall and reinstall after every driver update.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=03
Jeremy Newton changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110898
Jeremy Newton changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
= mipi_dbi_debugfs_init,
+ .name = "drm_mipi_dbi",
+ .desc = "DRM MIPI DBI",
+ .date = "20190729",
+ .major = 1,
+ .minor = 0,
+};
+
+/**
+ * drm
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/panel/panel-ilitek-ili9341.c | 179 ++-
1 file changed, 170 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
b/drivers/gpu/drm/panel/panel-ilitek-ili9341.c
index a755f3e60111..dd333a642159 1
Inspired by the thread[1] following the submission of a new ili9341
panel driver[2], I set out to see if I could support panel drivers in
drm_mipi_dbi.
I have included the original driver, done some prep work on it, added
panel support to drm_mipi_dbi and converted mi0283qt to this new panel
drive
Embed mipi_dbi in struct ili9341.
Rebase on moved mipi-dbi, rename variable name.
Add backlight_device to panel struct.
mipi_dbi_hw_reset() already has a NULL check on the reset gpio.
Prepare for more panels by reworking ili9341_config.
Signed-off-by: Noralf Trønnes
---
drivers/gpu/drm/panel/pan
From: Josef Lusticky
Add driver for Ilitek ILI9341 panels in parallel RGB mode
Signed-off-by: Josef Lusticky
---
MAINTAINERS | 6 +
drivers/gpu/drm/panel/Kconfig| 9 +
drivers/gpu/drm/panel/Makefile | 1 +
drivers/gpu/drm/pan
https://bugs.freedesktop.org/show_bug.cgi?id=110405
--- Comment #1 from Jeremy Newton ---
Can you try a newer driver? 18.30 is pretty old and likely doesn't support
18.04.2.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=109834
Jeremy Newton changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
From: Jérôme Glisse
commit 5e383a9798990c69fc759a4930de224bb497e62c upstream.
The debugfs take reference on fence without dropping them.
Signed-off-by: Jérôme Glisse
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: linux-me...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #53 from Anthony Rabbito ---
Interesting, on 5.2.x with 2 monitors hooked up via HDMI and DP it behaves 75%
of the time with most issues coming from xinit or sleep. Hopefully 5.3 will
contain fixes
--
You are receiving this mail be
https://bugs.freedesktop.org/show_bug.cgi?id=111231
--- Comment #14 from deltasquared ---
The apitrace no longer causes issues on my system either if I use
AMD_DEBUG=nodpbb . I also decided to try this on minetest and *so far* (bearing
in mind the issue was indetermistic in the first place, so a
https://bugs.freedesktop.org/show_bug.cgi?id=111244
--- Comment #6 from csp...@verizon.net ---
I see your point, and you are correct. It seems the issue is not 100%
reproducible. I will redo the bisect and test more thoroughly. Thank you.
--
You are receiving this mail because:
You are the assig
- Ursprüngliche Mail -
>> Was this series tested with the Ben Nanonote device?
>> I have one of these and from time to time I upgrade the kernel on it.
>
> Yes! Artur (Cc'd) tested it.
>
> You can test it yourself, after merging this patchset with:
> https://git.kernel.org/pub/scm/linux/k
Hi Brian.
Small nit below - did not try to understand your patch.
Sam
> diff --git a/include/drm/drm_mm.h b/include/drm/drm_mm.h
> index 2c3bbb43c7d1..3d123eb10d62 100644
> --- a/include/drm/drm_mm.h
> +++ b/include/drm/drm_mm.h
> @@ -43,6 +43,8 @@
> #include
> #include
> #include
Hi Fabio.
On Mon, Jul 29, 2019 at 12:51:08PM -0300, Fabio Estevam wrote:
> Hi Sam,
>
> On Mon, Jul 29, 2019 at 11:37 AM Sam Ravnborg wrote:
>
> > Could we throw a COMPILE_TEST in the mix so we get better build
> > coverage too?
>
> There is no architecture dependency to build this driver, so w
Hi Christian.
On Mon, Jul 29, 2019 at 03:28:15PM +, Koenig, Christian wrote:
> Am 29.07.19 um 16:35 schrieb Sam Ravnborg:
> Even then it so useless (which drm driver is this message for???) that I
> want to remove them all :(
> >>> Yeah, agree. I mean it is nice if the core drm funct
Hi Richard,
Le lun. 29 juil. 2019 à 7:23, Richard Weinberger
a écrit :
On Fri, Jul 26, 2019 at 12:02 AM Paul Cercueil
wrote:
Hi,
This patchset converts the Qi LB60 MIPS board to devicetree and
makes it
use all the shiny new drivers that have been developed or updated
recently.
All
Introduce DRM memory region types to be common for both drivers using
TTM and for i915. For now, TTM continues to define it's own set but
uses the DRM base definitions.
Signed-off-by: Brian Welty
---
include/drm/drm_mm.h| 8
include/drm/ttm/ttm_placement.h | 8
2 f
Some fields are deleted from intel_memory_region in favor of instead
using the new nested drm_mem_region structure.
Note, this is based upon unmerged i915 series [1] in order to show how
i915 might begin to integrate the proposed drm_mem_region.
[1] https://lists.freedesktop.org/archives/intel-gf
This RFC series is first implementation of some ideas expressed
earlier on dri-devel [1].
Some of the goals (open for much debate) are:
- Create common base structure (subclass) for memory regions (patch #1)
- Create common memory region types (patch #2)
- Create common set of memory_region
Move basic members of ttm_mem_type_manager into a new DRM memory region
structure. The idea is for this base structure to be nested inside
the TTM structure and later in Intel's proposed intel_memory_region.
As comments in the code suggest, the following future work can extend
the usefulness of t
https://bugs.freedesktop.org/show_bug.cgi?id=108882
--- Comment #1 from Jeremy Newton ---
It sounds like fglrx was not cleaned up properly.
Unfortunately I'm not sure there's much we can do here.
--
You are receiving this mail because:
You are the assignee for the bug._
On 2019-07-29 at 17:20:40 +0300, Pekka Paalanen wrote:
> On Sun, 14 Jul 2019 16:30:08 +0530
> Ramalingam C wrote:
>
> > This patch adds a DRM ENUM property to the selected connectors.
> > This property is used for mentioning the protected content's type
> > from userspace to kernel HDCP authentic
https://bugzilla.kernel.org/show_bug.cgi?id=204363
Adam Jackson (a...@redhat.com) changed:
What|Removed |Added
CC||a...@redhat.com
--- Comm
https://bugs.freedesktop.org/show_bug.cgi?id=110381
--- Comment #9 from John Francis ---
I am still seeing this error on kernel 5.2.2. I think it happens when I switch
away the monitors to another host on the KVM switch.
Switching back later, I get only 1 display, problematic as some windows are
https://bugs.freedesktop.org/show_bug.cgi?id=108883
Jeremy Newton changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=107826
Jeremy Newton changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=108994
Jeremy Newton changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
On Tue, Jun 18, 2019 at 09:10:49AM +0100, james qian wang (Arm Technology
China) wrote:
> Komeda HW can support dual-link which splits display frame to two halves
> (left/link0, right/link1) and output them by two output links.
> Due to the halved pixel rate of each link, the pxlclk of dual-link c
https://bugs.freedesktop.org/show_bug.cgi?id=110968
--- Comment #3 from Jeremy Newton ---
This is not a Ubuntu issue, we do this purposely.
Let me discuss internally and I can try to get a better solution.
--
You are receiving this mail because:
You are the assignee for the bug.___
On Tue, Jun 18, 2019 at 09:10:40AM +0100, james qian wang (Arm Technology
China) wrote:
> struct drm_display_mode contains two copies of timings.
> - plain timings.
> - hardware timings, the ones with "crtc_" prefix.
> According to the definition, update komeda to use the hardware timing.
>
> Sig
https://bugs.freedesktop.org/show_bug.cgi?id=111232
--- Comment #1 from Alex Deucher ---
Can you bisect?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.
https://bugs.freedesktop.org/show_bug.cgi?id=111231
--- Comment #13 from Pierre-Eric Pelloux-Prayer
---
Using AMD_DEBUG=nodpbb "fixes" the problem.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dr
Hi Sam,
On Mon, Jul 29, 2019 at 11:37 AM Sam Ravnborg wrote:
> Could we throw a COMPILE_TEST in the mix so we get better build
> coverage too?
There is no architecture dependency to build this driver, so we
already have build coverage for it.
Regards,
Fabio Estevam
___
On Fri, 2019-07-05 at 19:17 +0200, Lucas Stach wrote:
> In preparation to having a context per process, etnaviv_gem_mapping_get
> should not use the current GPU context, but needs to be told which
> context to use.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem.c
On Fri, 2019-07-05 at 19:17 +0200, Lucas Stach wrote:
> Move buffer setup and starting of the FE loop in the kernel ringbuffer
> into a separate function. This is a preparation to start the FE later
> in the submit process.
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_g
On Fri, 2019-07-05 at 19:17 +0200, Lucas Stach wrote:
> This reworks the MMU handling to make it possible to have multiple MMU
> contexts.
> A context is basically one instance of GPU page tables. Currently we have one
> set of page tables per GPU, which isn't all that clever, as it has the
> foll
Am 29.07.19 um 16:35 schrieb Sam Ravnborg:
Even then it so useless (which drm driver is this message for???) that I
want to remove them all :(
>>> Yeah, agree. I mean it is nice if the core drm functions use a prefix
>>> for debug output.
>>>
>>> But I actually don't see the point for ind
From: Liviu Dudau
Add the names of the kernel modules for the Arm display drivers
so that tests inside libDRM can auto-detect their presence.
Signed-off-by: Liviu Dudau
---
tests/util/kms.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/tests/util/kms.c b/tests/util/kms.c
index dd1bbee
Hi Sébastien,
On Mon, Jul 29, 2019 at 11:27:37AM -0300, Fabio Estevam wrote:
> Hi Sébastien,
>
> On Mon, Jul 29, 2019 at 11:14 AM Sébastien Szymanski
> wrote:
>
> > config DRM_MXSFB
> > - tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller"
> > + tristate "i.MX23/i.MX28/i.MX6SX/i.M
> >>
> >> Even then it so useless (which drm driver is this message for???) that I
> >> want to remove them all :(
> >
> > Yeah, agree. I mean it is nice if the core drm functions use a prefix
> > for debug output.
> >
> > But I actually don't see the point for individual drivers.
>
> We should a
Hi Sébastien,
On Mon, Jul 29, 2019 at 11:14 AM Sébastien Szymanski
wrote:
> config DRM_MXSFB
> - tristate "i.MX23/i.MX28/i.MX6SX MXSFB LCD controller"
> + tristate "i.MX23/i.MX28/i.MX6SX/i.MX6UL MXSFB LCD controller"
This IP is also found on i.MX6SL, i.MX7D, i.MX7S, i.MX8M, i.MX8QX
On Fri, Jul 26, 2019 at 06:36:01PM +0200, Maxime Ripard wrote:
> > +
> > + dvdd12-supply:
> > +maxItems: 1
> > +description: Regulator for 1.2V digital core power.
> > +$ref: /schemas/types.yaml#/definitions/phandle
> > +
> > + dvdd25-supply:
> > +maxItems: 1
> > +description:
https://bugzilla.kernel.org/show_bug.cgi?id=204365
Bug ID: 204365
Summary: amdgpu crashes when using parameter
"drm.edid_firmware"
Product: Drivers
Version: 2.5
Kernel Version: 5.2.4
Hardware: All
OS: Li
On Sun, 14 Jul 2019 16:30:08 +0530
Ramalingam C wrote:
> This patch adds a DRM ENUM property to the selected connectors.
> This property is used for mentioning the protected content's type
> from userspace to kernel HDCP authentication.
>
> Type of the stream is decided by the protected content
On 2019-07-26 11:06 p.m., Sam Ravnborg wrote:
> DRM_WAIT_ON() is from the deprecated drm_os_linux header and
> the modern replacement is the wait_event_*.
>
> The return values differ, so a conversion is needed to
> keep the original interface towards userspace.
> Introduced a switch/case to make
https://bugs.freedesktop.org/show_bug.cgi?id=109456
libgra...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=109456
--- Comment #8 from libgra...@gmail.com ---
Got back to this again recently and can confirm it's fixed in Qemu git (for
4.1) now.
Many thanks :)
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=111231
--- Comment #12 from Pierre-Eric Pelloux-Prayer
---
Thanks for the bug report.
I could reproduce the bug using the provided apitrace, both on a Ryzen platform
and on a Vega Mobile laptop (can't reproduce on Navi).
Using MESA_DEBUG=flush or AM
1 - 100 of 154 matches
Mail list logo
