https://bugs.freedesktop.org/show_bug.cgi?id=102370
Jani Saarinen changed:
What|Removed |Added
Assignee|dri-devel@lists.freedesktop |intel-gfx-bugs@lists.freede
Hi,
On 10/05/2019 22:42, Adam Ford wrote:
Currently the source code is compiled using hard-coded values
from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
clock divider value to be moved to the device tree and be changed
without having to recompile the kernel.
Signed-off-by: Adam Fo
https://bugs.freedesktop.org/show_bug.cgi?id=94043
--- Comment #15 from Richard Thier ---
I have seen really similar scrambled graphics when trying to play Rome: Total
War (rtw 1). In my case however the glitch seems to have more simmetry: it
looks like the screen is tiled into tiles all of which
Op 22-05-2019 om 22:45 schreef Ville Syrjälä:
> On Thu, May 16, 2019 at 07:40:05PM +0530, Uma Shankar wrote:
>> This patch series enables HDR support in drm. It basically defines
>> HDR metadata structures, property to pass content (after blending)
>> metadata from user space compositors to driver.
>-Original Message-
>From: Maarten Lankhorst [mailto:maarten.lankho...@linux.intel.com]
>Sent: Tuesday, May 28, 2019 5:06 PM
>To: Ville Syrjälä ; Shankar, Uma
>
>Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Sharma,
>Shashank ; emil.l.veli...@gmail.com;
>brian.star
https://bugs.freedesktop.org/show_bug.cgi?id=110781
Bug ID: 110781
Summary: Radeon: heavy r300 performance drop regression between
11.x and 19.x
Product: Mesa
Version: git
Hardware: x86 (IA32)
OS: Linux (All
https://bugs.freedesktop.org/show_bug.cgi?id=94043
--- Comment #16 from Mike Lothian ---
Unless you're running an old r300 card I recommend you open your own bug
Make sure you state what versions of Mesa you're using and which versions (if
any) worked and take a look at https://www.mesa3d.org/bu
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #1 from Richard Thier ---
PS.: As you can see I already have the mesa sources and can build and test my
own in case there is any kind of idea what I should search for...
--
You are receiving this mail because:
You are the assignee
On 28.05.2019 10:27, Tomi Valkeinen wrote:
> We need to know the link bandwidth to filter out modes we cannot
> support, so we need to have read the display props before doing the
> filtering.
>
> To ensure we have up to date display props, call tc_get_display_props()
> in the beginning of tc_conne
Hi Jacopo,
On Tue, May 28, 2019 at 11:28:47AM +0200, Jacopo Mondi wrote:
> On Sun, May 12, 2019 at 12:06:56AM +0300, Laurent Pinchart wrote:
> > Add a new optional renesas,companion property to point to the companion
> > LVDS encoder. This is used to support dual-link operation where the main
> >
https://bugs.freedesktop.org/show_bug.cgi?id=110725
Lakshmi changed:
What|Removed |Added
Component|DRM/Intel |IGT
Assignee|intel-gfx-bugs@lists.f
Hi Jacopo,
On Tue, May 28, 2019 at 11:35:50AM +0200, Jacopo Mondi wrote:
> Hi Laurent,
> a small note.
>
> On Sun, May 12, 2019 at 12:06:58AM +0300, Laurent Pinchart wrote:
> > In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and
> > sends odd-numbered pixels to the LVDS1 enco
On Sun, 26 May 2019, Sam Ravnborg wrote:
> Do not require users of include/drm/drm_auth.h to include
> other files just to let it build.
>
> Signed-off-by: Sam Ravnborg
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> ---
> include/drm/drm
Hi Jani.
On Tue, May 28, 2019 at 03:54:48PM +0300, Jani Nikula wrote:
> On Sun, 26 May 2019, Sam Ravnborg wrote:
> > Do not require users of include/drm/drm_auth.h to include
> > other files just to let it build.
> >
> > Signed-off-by: Sam Ravnborg
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripar
https://bugs.freedesktop.org/show_bug.cgi?id=110783
Bug ID: 110783
Summary: Mesa 19.1 rc crashing MPV with VAAPI
Product: Mesa
Version: 19.1
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: n
https://bugs.freedesktop.org/show_bug.cgi?id=110783
--- Comment #1 from AngryPenguin ---
Created attachment 144363
--> https://bugs.freedesktop.org/attachment.cgi?id=144363&action=edit
inxi
--
You are receiving this mail because:
You are the assignee for the bug.__
On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
> Here is a patch series that adds initial display support for the LG
> Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> of these patches are RFC until we can get it fully working.
>
> The phones boots into terminal mode, h
Hi Steve,
On Thu, 16 May 2019 17:21:39 +0100
Steven Price wrote:
> >> +static void panfrost_perfcnt_setup(struct panfrost_device *pfdev)
> >> +{
> >> + u32 cfg;
> >> +
> >> + /*
> >> +* Always use address space 0 for now.
> >> +* FIXME: this needs to be updated when
On Tue, 28 May 2019 15:53:48 +0200
Boris Brezillon wrote:
> Hi Steve,
>
> On Thu, 16 May 2019 17:21:39 +0100
> Steven Price wrote:
>
>
> > >> +static void panfrost_perfcnt_setup(struct panfrost_device *pfdev)
> > >> +{
> > >> + u32 cfg;
> > >> +
> > >> + /*
> > >> +* Alway
From: Ville Syrjälä
CH7511 doesn't update SINK_COUNT properly so in order to detect
the device as connected we have to ignore SINK_COUNT.
In order to have access to the quirk list early enough we
must move the drm_dp_read_desc() call to happen earlier.
We can also skip re-reading this on eDP sin
From: Ville Syrjälä
CH7511 eDP->LVDS bridge doesn't seem to set SINK_COUNT properly
causing i915 to detect it as disconnected. Add a quirk to ignore
SINK_COUNT on these devices.
Cc: David S.
Cc: Peteris Rudzusiks
Tested-by: Peteris Rudzusiks
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi
Hello everybody,
This patch series implements support for LVDS dual-link mode in the
R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd1024
LVDS decoder driver.
LVDS dual-link is a mode of operation where two individual LVDS links
are operated together to carry even- and odd-num
Extend the drm_bridge_timings structure with a new dual_link field to
indicate that the bridge's input bus carries data on two separate
physical links. The first use case is LVDS dual-link mode where even-
and odd-numbered pixels are transferred on separate LVDS links.
Signed-off-by: Laurent Pinch
The THC63LVD1024 LVDS decoder can operate in two modes, single-link or
dual-link. In dual-link mode both input ports are used to carry even-
and odd-numbered pixels separately. Document this in the DT bindings,
along with the related rules governing port and usage.
Signed-off-by: Laurent Pinchart
The DRM core and DU driver guarantee that the LVDS bridge will not be
double-enabled or double-disabled. Remove the corresponding unnecessary
checks.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mondi
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 19 -
Add the new renesas,companion property to the LVDS0 node to point to the
companion LVDS encoder LVDS1.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mondi
---
arch/arm64/boot/dts/renesas/r8a77990.dtsi | 2 ++
arch/arm64/boot/dts/renesas/r8a77995.dtsi | 2 ++
2 fil
In dual-link mode the LVDS0 encoder transmits even-numbered pixels, and
sends odd-numbered pixels to the LVDS1 encoder for transmission on a
separate link.
To implement support for this mode of operation, determine if the LVDS
connection operates in dual-link mode by querying the next device in th
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
Tested-by: Jacopo Mondi
---
.../arm64/boot/dts/renesas/r
In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
can't be used in that case, don't create an encoder and connector for
it.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mond
Add a new optional renesas,companion property to point to the companion
LVDS encoder. This is used to support dual-link operation where the main
LVDS encoder splits even-numbered and odd-numbered pixels between the
two LVDS encoders.
The new property doesn't control the mode of operation, it only
Set a drm_bridge_timings in the drm_bridge, and use it to report the
input bus mode (single-link or dual-link). The other fields of the
timings structure are kept to 0 as they do not apply to LVDS buses.
Signed-off-by: Laurent Pinchart
Reviewed-by: Jacopo Mondi
Tested-by: Jacopo Mondi
---
Chang
Enable and connect the second LVDS encoder to the second LVDS input of
the THC63LVD1024 for dual-link LVDS operation. This requires changing
the default settings of SW45 and SW47 to OFF and ON respectively.
Signed-off-by: Laurent Pinchart
Tested-by: Jacopo Mondi
---
.../arm64/boot/dts/renesas/r
On 5/28/19 2:31 AM, Thomas Hellstrom wrote:
> Hi, Tom,
>
> Could you shed some light on this?
I don't have a lot of GPU knowledge, so let me start with an overview of
how everything should work and see if that answers the questions being
asked.
First, SME:
The encryption bit is bit-47 of a physi
Am 28.05.19 um 16:48 schrieb Lendacky, Thomas:
On 5/28/19 2:31 AM, Thomas Hellstrom wrote:
Hi, Tom,
Could you shed some light on this?
I don't have a lot of GPU knowledge, so let me start with an overview of
how everything should work and see if that answers the questions being
asked.
First,
On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen wrote:
>
> Hi,
>
> On 10/05/2019 22:42, Adam Ford wrote:
> > Currently the source code is compiled using hard-coded values
> > from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
> > clock divider value to be moved to the device tree and be
Hi, Tom,
Thanks for the reply. The question is not graphics specific, but lies in
your answer further below:
On 5/28/19 4:48 PM, Lendacky, Thomas wrote:
On 5/28/19 2:31 AM, Thomas Hellstrom wrote:
Hi, Tom,
Could you shed some light on this?
I don't have a lot of GPU knowledge, so let me st
From: Sean Paul
Instead of reaching into dev->primary for debugfs_root, use the minor
passed into debugfs_init.
This avoids creating a debug directory under /sys/kernel/debug/debug
and instead uses /sys/kernel/debug/dri//
Since we're now putting everything under */dri/, there's no
need to creat
Hi Thomas,
Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
> Hi, Tom,
>
> Thanks for the reply. The question is not graphics specific, but lies
> in your answer further below:
>
> On 5/28/19 4:48 PM, Lendacky, Thomas wrote:
>> On 5/28/19 2:31 AM, Thomas Hellstrom wrote:
>> [SNIP]
>> As for kernel
> Am 28.05.2019 um 17:09 schrieb Adam Ford :
>
> On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen wrote:
>>
>> Hi,
>>
>> On 10/05/2019 22:42, Adam Ford wrote:
>>> Currently the source code is compiled using hard-coded values
>>> from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
>>>
Hi James,
On Mon, May 27, 2019 at 07:51:18AM +0100, james qian wang (Arm Technology
China) wrote:
> Hi Brian & Ville:
>
> komed has a format+modifier check before the fb size check.
> and for komeda_fb_create, the first step is do the format+modifier
> check, the size check is the furthur check
On Tue, May 28, 2019 at 8:13 AM Sean Paul wrote:
>
> From: Sean Paul
>
> Instead of reaching into dev->primary for debugfs_root, use the minor
> passed into debugfs_init.
>
> This avoids creating a debug directory under /sys/kernel/debug/debug
> and instead uses /sys/kernel/debug/dri//
>
> Since
On Tue, May 28, 2019 at 11:13:39AM -0400, Sean Paul wrote:
> From: Sean Paul
>
> Instead of reaching into dev->primary for debugfs_root, use the minor
> passed into debugfs_init.
>
> This avoids creating a debug directory under /sys/kernel/debug/debug
> and instead uses /sys/kernel/debug/dri//
>
On 2019/05/28, Tomi Valkeinen wrote:
> On 22/05/2019 18:02, Emil Velikov wrote:
> > From: Emil Velikov
> >
> > Cc: Tomi Valkeinen
> > Signed-off-by: Emil Velikov
> > ---
> > drivers/gpu/drm/omapdrm/omap_drv.c | 16 +---
> > 1 file changed, 1 insertion(+), 15 deletions(-)
> >
> >
On 5/28/19 10:17 AM, Koenig, Christian wrote:
> Hi Thomas,
>
> Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
>> Hi, Tom,
>>
>> Thanks for the reply. The question is not graphics specific, but lies
>> in your answer further below:
>>
>> On 5/28/19 4:48 PM, Lendacky, Thomas wrote:
>>> On 5/28/19 2
Hi,
On 28/05/2019 18:09, Adam Ford wrote:
On Tue, May 28, 2019 at 4:11 AM Tomi Valkeinen wrote:
Hi,
On 10/05/2019 22:42, Adam Ford wrote:
Currently the source code is compiled using hard-coded values
from CONFIG_OMAP2_DSS_MIN_FCK_PER_PCK. This patch allows this
clock divider value to be mo
On 2019/05/28, Daniel Vetter wrote:
> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> wrote:
> >
> > Am 28.05.19 um 09:38 schrieb Daniel Vetter:
> > > [SNIP]
> > >> Might be a good idea looking into reverting it partially, so that at
> > >> least command submission and buffer allocation is st
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #2 from Richard Thier ---
The "gallium/winsys/radeon/drm/radeon_drm_bo.c" is indeed used by r300 because
I have put a log in it.
--
You are receiving this mail because:
You are the assignee for the bug._
Am 28.05.19 um 18:10 schrieb Emil Velikov:
> On 2019/05/28, Daniel Vetter wrote:
>> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
>> wrote:
>>> Am 28.05.19 um 09:38 schrieb Daniel Vetter:
[SNIP]
> Might be a good idea looking into reverting it partially, so that at
> least comman
When a signal arrives we should return immediately for
handling it and not try other placements first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm
We are already doing this for DMA-buf imports and also for
amdgpu VM BOs for quite a while now.
If this doesn't run into any problems we are probably going
to stop removing BOs from the LRU altogether.
v2: drop BUG_ON from ttm_bo_add_to_lru
Signed-off-by: Christian König
---
.../gpu/drm/amd/am
We tried this once before, but that turned out to be more
complicated than thought. With all the right prerequisites
it looks like we can do this now.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 127 ++-
1 file changed, 66 insertions(+), 61 d
If drivers don't prefer a system memory placement
they should not but it into the placement list first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gp
Move BOs which are currently in a lower domain to the new
LRU before allocating backing space while validating.
This makes sure that we always have enough entries on the
LRU to allow for other processes to wait for an operation
to complete.
v2: generalize the test
Signed-off-by: Christian König
This avoids OOM situations when we have lots of threads
submitting at the same time.
v3: apply this to the whole driver, not just CS
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c| 2 +-
drivers/gpu/drm/amd/amdgp
BOs on the LRU might be blocked during command submission
and cause OOM situations.
Avoid this by blocking for the first busy BO not locked by
the same ticket as the BO we are searching space for.
v10: completely start over with the patch since we didn't
handled a whole bunch of corner cases
From: Chunming Zhou
add ticket for display bo, so that it can preempt busy bo.
v2: fix stupid rebase error
Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 ++-
The messages about amdgpu_cs_list_validate are duplicated because the
caller will complain into the logs as well and we can also get
interrupted by a signal here.
Also fix the the caller to not report -EAGAIN from validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_
And only move them in on validation. This allows for better control
when multiple processes are fighting over those resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/am
On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
> On 5/28/19 10:17 AM, Koenig, Christian wrote:
> > Hi Thomas,
> >
> > Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
> > > Hi, Tom,
> > >
> > > Thanks for the reply. The question is not graphics specific, but
> > > lies
> > > in your an
Am 28.05.19 um 18:27 schrieb Thomas Hellstrom:
> On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
>> On 5/28/19 10:17 AM, Koenig, Christian wrote:
>>> Hi Thomas,
>>>
>>> Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
Hi, Tom,
Thanks for the reply. The question is not graphi
Hi Laurent.
Reading through this nice series.
On Tue, May 28, 2019 at 05:12:28PM +0300, Laurent Pinchart wrote:
> Add a new optional renesas,companion property to point to the companion
> LVDS encoder. This is used to support dual-link operation where the main
> LVDS encoder splits even-numbered
Hi Laurent.
On Tue, May 28, 2019 at 05:12:31PM +0300, Laurent Pinchart wrote:
> In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
> LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
> can't be used in that case, don't create an encoder and connector for
>
Hi Laurent.
Nice series with small and well described patches.
> On Tue, May 28, 2019 at 05:12:24PM +0300, Laurent Pinchart wrote:
>> Hello everybody,
>>
>> This patch series implements support for LVDS dual-link mode in the
>> R-Car DU and R-Car LVDS encoder drivers, and well as in the thc63lvd
On 2019/05/28, Koenig, Christian wrote:
> Am 28.05.19 um 18:10 schrieb Emil Velikov:
> > On 2019/05/28, Daniel Vetter wrote:
> >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> >> wrote:
> >>> Am 28.05.19 um 09:38 schrieb Daniel Vetter:
> [SNIP]
> > Might be a good idea looking into
On 28/05/2019 18:41, Emil Velikov wrote:
On 2019/05/28, Tomi Valkeinen wrote:
On 22/05/2019 18:02, Emil Velikov wrote:
From: Emil Velikov
Cc: Tomi Valkeinen
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/omapdrm/omap_drv.c | 16 +---
1 file changed, 1 insertion(+), 15 dele
Hi Sam,
On Tue, May 28, 2019 at 06:37:30PM +0200, Sam Ravnborg wrote:
> On Tue, May 28, 2019 at 05:12:28PM +0300, Laurent Pinchart wrote:
> > Add a new optional renesas,companion property to point to the companion
> > LVDS encoder. This is used to support dual-link operation where the main
> > LVD
Hi Sam,
On Tue, May 28, 2019 at 06:42:13PM +0200, Sam Ravnborg wrote:
> On Tue, May 28, 2019 at 05:12:31PM +0300, Laurent Pinchart wrote:
> > In dual-link LVDS mode, the LVDS1 encoder is used as a companion for
> > LVDS0, and both encoders transmit data from DU0. The LVDS1 output of DU1
> > can't
Hi Laurent.
> > >
> > > +Optional properties:
> > > +
> > > +- renesas,companion : phandle to the companion LVDS encoder. This
> > > property is
> > > + mandatory for the first LVDS encoder on D3 and E3 SoCs, and shall
> > > point to
> > > + the second encoder to be used as a companion in du
On 5/28/19 11:32 AM, Koenig, Christian wrote:
> Am 28.05.19 um 18:27 schrieb Thomas Hellstrom:
>> On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
>>> On 5/28/19 10:17 AM, Koenig, Christian wrote:
Hi Thomas,
Am 28.05.19 um 17:11 schrieb Thomas Hellstrom:
> Hi, Tom,
Hi Laurent.
On Tue, May 28, 2019 at 07:50:52PM +0300, Laurent Pinchart wrote:
> Hi Sam,
>
> On Tue, May 28, 2019 at 06:42:13PM +0200, Sam Ravnborg wrote:
> > On Tue, May 28, 2019 at 05:12:31PM +0300, Laurent Pinchart wrote:
> > > In dual-link LVDS mode, the LVDS1 encoder is used as a companion fo
Hi!
Dne nedelja, 26. maj 2019 ob 23:18:46 CEST je Jonas Karlman napisal(a):
> Add support for HDR metadata using the hdr_output_metadata connector
> property, configure Dynamic Range and Mastering InfoFrame accordingly.
>
> A drm_infoframe flag is added to dw_hdmi_plat_data that platform drivers
On 5/28/19 7:00 PM, Lendacky, Thomas wrote:
On 5/28/19 11:32 AM, Koenig, Christian wrote:
Am 28.05.19 um 18:27 schrieb Thomas Hellstrom:
On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
On 5/28/19 10:17 AM, Koenig, Christian wrote:
Hi Thomas,
Am 28.05.19 um 17:11 schrieb Thomas Hel
Hi Christian.
On Tue, May 28, 2019 at 06:25:54PM +0200, Christian König wrote:
> From: Chunming Zhou
>
> add ticket for display bo, so that it can preempt busy bo.
>
> v2: fix stupid rebase error
>
> Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
What is this?
I do not recall seeing this
On Tue, May 21, 2019 at 12:27 AM Souptick Joarder wrote:
>
> Convert to use hmm_range_fault().
Any comment on this patch ?
>
> Signed-off-by: Souptick Joarder
> ---
> drivers/gpu/drm/nouveau/nouveau_svm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/
On Mon, 27 May 2019 18:56:20 +0800 Christian Koenig wrote:
> Thanks for the comments, but you are looking at a completely outdated
> patchset.
>
> If you are interested in the newest one please ping me and I'm going to CC you
> when I send out the next version.
>
Ping...
Thanks
Hillf
The A540 is a derivative of the A530, and is found in the MSM8998 SoC.
Signed-off-by: Jeffrey Hugo
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22 +++
drivers/gpu/drm/msm/adreno/a5xx_power.c| 76 +-
drivers/gpu/drm/msm/adreno/adreno_device.c | 18 +
drivers/g
On Tue, May 28, 2019 at 1:05 PM Sam Ravnborg wrote:
>
> Hi Christian.
>
> On Tue, May 28, 2019 at 06:25:54PM +0200, Christian König wrote:
> > From: Chunming Zhou
> >
> > add ticket for display bo, so that it can preempt busy bo.
> >
> > v2: fix stupid rebase error
> >
> > Change-Id: I9f031cdcc82
On 5/28/19 12:05 PM, Thomas Hellstrom wrote:
> On 5/28/19 7:00 PM, Lendacky, Thomas wrote:
>> On 5/28/19 11:32 AM, Koenig, Christian wrote:
>>> Am 28.05.19 um 18:27 schrieb Thomas Hellstrom:
On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
> On 5/28/19 10:17 AM, Koenig, Christian
From: Sean Paul
There's a comment in _dpu_kms_hw_destroy() that reads "safe to call
these more than once during shutdown", referring to
_dpu_kms_mmu_destroy(). Unfortunately that's not the case, mmu_destroy
will fail hard if it's called twice. So fix that function to ensure it
can be called multi
From: Sean Paul
This comment doesn't make any sense, remove it.
Suggested-by: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.
https://bugs.freedesktop.org/show_bug.cgi?id=106302
--- Comment #4 from s...@vestigecounty.com ---
Thank you for being exactly on point, it turns out I was using a frivolous
interpretation of "change" rather than the one specified in OpenGL ES. The bug
can safely be closed as invalid, as fence is
[Why]
For userspace to send static HDR metadata to the display we need to
attach the property on the connector and send it to DC.
[How]
The property is attached to HDMI and DP connectors. Since the metadata
isn't actually available when creating the connector this isn't a
property we can dynamical
This patch series enables HDR output metadata support in amdgpu using the
DRM HDR interface merged in drm-misc-next. Enabled for DCE and DCN ASICs
over DP and HDMI.
It's limited to static HDR metadata support for now since that's all the
DRM interface supports. It requires a modeset for entering a
[Why]
We can issue HDR static metadata as part of stream updates for
non-modesets as long as we force a modeset when entering or exiting HDR.
This avoids unnecessary blanking for simple metadata updates.
[How]
When changing scaling and abm for the stream also check if HDR has
changed and send the
https://bugs.freedesktop.org/show_bug.cgi?id=110786
dron1...@gmail.com changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving t
https://bugs.freedesktop.org/show_bug.cgi?id=110786
Bug ID: 110786
Summary: Adaptive sync (vrr, freesync): Cinnamon DE isn't
blacklisted properly
Product: Mesa
Version: unspecified
Hardware: x86-64 (AMD64)
O
On Wed, 29 May 2019 at 02:47, Emil Velikov wrote:
>
> On 2019/05/28, Koenig, Christian wrote:
> > Am 28.05.19 um 18:10 schrieb Emil Velikov:
> > > On 2019/05/28, Daniel Vetter wrote:
> > >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> > >> wrote:
> > >>> Am 28.05.19 um 09:38 schrieb Danie
On Tue, May 28, 2019 at 02:26:45PM -0400, Sean Paul wrote:
> From: Sean Paul
>
> This comment doesn't make any sense, remove it.
>
> Suggested-by: Jordan Crouse
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 1 -
> 1 file changed, 1 deletion(-)
Reviewed-by: Jord
Sigh ... looks like this doesn't actually do what we want. See the
last couple comments in:
https://bugs.freedesktop.org/show_bug.cgi?id=110660
It seems to work as expected with "mode" instead of "adjusted_mode".
Does that make sense? It kinda does based on the later code, which
copies mode into
On Tue, May 28, 2019 at 10:06:12AM -0700, Jeffrey Hugo wrote:
> The A540 is a derivative of the A530, and is found in the MSM8998 SoC.
>
> Signed-off-by: Jeffrey Hugo
> ---
> drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22 +++
> drivers/gpu/drm/msm/adreno/a5xx_power.c| 76 ++
On Tue, May 28, 2019 at 2:45 PM Jordan Crouse wrote:
>
> On Tue, May 28, 2019 at 10:06:12AM -0700, Jeffrey Hugo wrote:
> > The A540 is a derivative of the A530, and is found in the MSM8998 SoC.
> >
> > Signed-off-by: Jeffrey Hugo
> > ---
> > drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 22 ++
https://bugs.freedesktop.org/show_bug.cgi?id=110787
Bug ID: 110787
Summary: Glitches in console of the Julia language plugin for
Atom (Juno)
Product: Mesa
Version: 19.0
Hardware: x86-64 (AMD64)
OS: Linux (Al
https://bugs.freedesktop.org/show_bug.cgi?id=110787
--- Comment #1 from Manuel Vögele ---
Created attachment 144367
--> https://bugs.freedesktop.org/attachment.cgi?id=144367&action=edit
Output of glxinfo
--
You are receiving this mail because:
You are the assignee for the bug.
On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
>
> > Here is a patch series that adds initial display support for the LG
> > Nexus 5 (hammerhead) phone. It's not fully working so that's why some
> > of these patches are RFC unti
On Tue, May 28, 2019 at 7:17 PM Brian Masney wrote:
>
> On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
> >
> > > Here is a patch series that adds initial display support for the LG
> > > Nexus 5 (hammerhead) phone. It's not fu
Hi, Hsin-yi:
On Mon, 2019-05-27 at 12:50 +0800, Hsin-Yi Wang wrote:
> move mipi_dsi_host_unregister() to .remove since mipi_dsi_host_register()
> is called in .probe.
In the latest kernel [1], mipi_dsi_host_register() is called in
mtk_dsi_bind(), I think we don't need this part.
[1]
https://git.
On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
> On Tue, May 28, 2019 at 7:17 PM Brian Masney wrote:
> >
> > On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > > On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
> > >
> > > > Here is a patch series that adds initia
On Tue, May 28, 2019 at 7:37 PM Brian Masney wrote:
>
> On Tue, May 28, 2019 at 07:32:14PM -0600, Jeffrey Hugo wrote:
> > On Tue, May 28, 2019 at 7:17 PM Brian Masney wrote:
> > >
> > > On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > > > On Thu, May 9, 2019 at 4:04 AM Brian Mas
The variable edid returned by psb_intel_sdvo_get_edid()
was never freed.
Signed-off-by: Young Xiao <92siuy...@gmail.com>
---
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/gma500/psb_intel_sdvo.c
b/drivers/gpu/drm/gma500/psb_intel_sdvo
On Tue, May 28, 2019 at 6:17 PM Brian Masney wrote:
>
> On Tue, May 28, 2019 at 03:46:14PM +0200, Linus Walleij wrote:
> > On Thu, May 9, 2019 at 4:04 AM Brian Masney wrote:
> >
> > > Here is a patch series that adds initial display support for the LG
> > > Nexus 5 (hammerhead) phone. It's not fu
101 - 200 of 211 matches
Mail list logo
