On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> According to the docs - prevents firstopen/lastclose races. Yet never
> used in practise.
>
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
Reviewed-by: Thomas
On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Core DRM is safe when the callback is NULL.
>
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> Cc: Daniel Vetter
> Signed-off-by: Emil Velikov
Reviewed-by: Thomas Hellstrom
> ---
>
From: Icenowy Zheng
Some code can be shared within different DP bridges by Analogix.
Extract them to a new module.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Signed-off-by: Torsten Duwe
---
drivers/gpu/drm/bridge/analogix/Kconfig| 4 +
From: Icenowy Zheng
The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
for portable devices. This driver adds initial support for RGB to eDP
mode, without HPD and interrupts.
This is a configuration usually seen in eDP applications.
Signed-off-by: Icenowy Zheng
From: Icenowy Zheng
The anx6345 is an ultra-low power DisplayPort/eDP transmitter designed
for portable devices.
Add a binding document for it.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Reviewed-by: Rob Herring
Signed-off-by: Torsten Duwe
---
From: Icenowy Zheng
Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
the I2C controlling signals are connected to I2C0 bus. eDP output goes
to an Innolux N116BGE panel.
Enable it in the device tree.
Signed-off-by: Icenowy Zheng
Signed-off-by: Torsten Duwe
---
On Thu, May 23, 2019 at 2:54 PM Torsten Duwe wrote:
>
> From: Icenowy Zheng
>
> Some code can be shared within different DP bridges by Analogix.
>
> Extract them to a new module.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Vasily Khoruzhick
> Signed-off-by: Torsten Duwe
> ---
>
Hi Torsten,
Thank you for the patch.
On Thu, May 23, 2019 at 08:53:52AM +0200, Torsten Duwe wrote:
> From: Icenowy Zheng
>
> Some code can be shared within different DP bridges by Analogix.
>
> Extract them to a new module.
>
> Signed-off-by: Icenowy Zheng
> Signed-off-by: Vasily Khoruzhick
Hi, Sean:
On Wed, 2019-05-22 at 16:21 -0400, Sean Paul wrote:
> From: Sean Paul
>
> Fixes the following build warning:
> drivers/gpu/drm/mediatek/mtk_hdmi.c:327:2: warning: enumeration value
> ‘HDMI_INFOFRAME_TYPE_DRM’ not handled in switch [-Wswitch]
>
> Introduced with the addition of
Hi, Emil,
On Wed, 2019-05-22 at 17:41 +0100, Emil Velikov wrote:
> From: Emil Velikov
>
> Drop the custom ioctl io encoding check - core drm does it for us.
I fail to see where the core does this, or do I miss something?
Thanks,
Thomas
>
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
>
From: Icenowy Zheng
As ANA78xx chips are designed and produced by Analogix Semiconductor,
Inc, move their driver codes into analogix subdirectory.
Signed-off-by: Icenowy Zheng
Signed-off-by: Vasily Khoruzhick
Reviewed-by: Laurent Pinchart
Signed-off-by: Torsten Duwe
---
From: Icenowy Zheng
Some definitions currently in analogix-anx78xx.h are not restricted to
the ANX78xx series, but also applicable to other DisplayPort
transmitters by Analogix.
Split out them to dedicated headers, and make analogix-anx78xx.h include
them.
Signed-off-by: Icenowy Zheng
On Tue, 21 May 2019, Gwan-gyeong Mun wrote:
> On Gen 11 platform, to enable resolutions like 5K@120 (or higher) we need
> to use DSC (DP 1.4) or YCbCr4:2:0 (DP 1.3 or 1.4) on DP.
> In order to support YCbCr4:2:0 on DP we need to program YCBCR 4:2:0
> to MSA and VSC SDP.
> And Link M/N values are
Hi, Christian
Thanks for you patch .Those patches can fix amdgpu bo pinned failed issue
during perform dm_plane_helper_prepare_fb
and Abaqus performance seems improved.
But there some error message can be observer. Do we need drop
amdgpu_vm_validate_pt_bos() error message
and other warning
Hi Torsten,
Thank you for the patch.
On Thu, May 23, 2019 at 08:54:00AM +0200, Torsten Duwe wrote:
> From: Icenowy Zheng
>
> The anx6345 is an ultra-low power DisplayPort/eDP transmitter designed
> for portable devices.
>
> Add a binding document for it.
>
> Signed-off-by: Icenowy Zheng
>
Hi Torsten,
Thank you for the patch.
On Thu, May 23, 2019 at 08:53:56AM +0200, Torsten Duwe wrote:
> From: Icenowy Zheng
>
> The ANX6345 is an ultra-low power DisplayPower/eDP transmitter designed
> for portable devices. This driver adds initial support for RGB to eDP
> mode, without HPD and
On Thu, May 23, 2019 at 03:40:25PM +0800, Chen-Yu Tsai wrote:
> On Thu, May 23, 2019 at 2:54 PM Torsten Duwe wrote:
> >
> > From: Icenowy Zheng
> >
> > Some code can be shared within different DP bridges by Analogix.
> >
> > Extract them to a new module.
> >
> > Signed-off-by: Icenowy Zheng
> >
On Wed, 22 May 2019, Ville Syrjälä wrote:
> Pushed the core/etc. bits to drm-misc-next so that other drivers
> can base their work on that. We'll need a backmerge to get the
> i915 stuff in via dinq.
To avoid any confusion, drm-misc-next needs to get merged to drm-next,
which then needs to be
Hi Stephen,
On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> Documentation/devicetree/bindings/vendor-prefixes.txt
>
> between commit:
>
> 8122de54602e ("dt-bindings: Convert vendor prefixes to
1. Add scaler to writeback pipeline to enable the writeback scaling support
2. Display HW can not do upscaling for writeback, check it when validate.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../drm/arm/display/komeda/komeda_pipeline.h | 2 ++
For downscaling there is a restriction, the downscaling needed engine
clock can not acceed the real engine clock, and the clock requirement
mostly depend on the specific HW, to solve this problem:
1. Add a pipeline func - downscaling_clk_check for CORE to query the real
HW if downscaling can be
This patch series added scaling and image enhancement support for komeda
driver.
Enabled two different scaling usage:
- layer scaling: scaling a input image before composite it with others
- write-back scaling: scaling the composition result and write it to memory
This patchset depends on:
-
This patch add the initial and necessary logic for CORE to support scaler:
- Complete the struct komeda_scaler and komeda_scaler_state for adding
the scaler specific features and capablities.
- Implement komeda_scaler_validate to check the scaler with the data flow
configurations.
- Enable
According to the komeda pipeline configuration, attach scaler to drm as
private object.
v2: Rebase
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/komeda_private_obj.c | 49 +++
1 file changed, 49 insertions(+)
diff --git
Besides scaling, Arm display scaler also can support image enhancement.
For support it, Add a new property "img_enhancement" to plane, then user
can turn on/off it by this property, and kernel follow user's requirement
to maitain the state and enable/disable the real HW image enhancement.
v2:
1. Add scaler component and initialize it according to D71 HW.
2. Implement d71_scaler_update/disable/dump
v2:
- Correct a typo
- Constify component_funcs: d71_scaler_funcs
Signed-off-by: James Qian Wang (Arm Technology China)
---
.../arm/display/komeda/d71/d71_component.c| 131
On Thu, May 23, 2019 at 10:50:35AM +0300, Laurent Pinchart wrote:
> On Thu, May 23, 2019 at 03:40:25PM +0800, Chen-Yu Tsai wrote:
> >
> > If this was simple code movement, then the original copyright still applies.
> > A different copyright notice should not be used. I suppose the same applies
>
On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> Documentation/devicetree/bindings/vendor-prefixes.txt
>
> between commit:
>
> 8122de54602e ("dt-bindings: Convert vendor prefixes to
https://bugs.freedesktop.org/show_bug.cgi?id=110736
Bug ID: 110736
Summary: Spotify rendering issues
Product: Mesa
Version: git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Priority:
Sure
-Lionel
On 23/05/2019 13:11, Zhou, David(ChunMing) wrote:
can you make the parameter optional? Otherwise looks good to me.
-David
Original Message
Subject: [PATCH 1/2] drm/syncobj: add an output syncobj parameter to
find_fence
From: Lionel Landwerlin
To:
>-Original Message-
>From: Sean Paul [mailto:s...@poorly.run]
>Sent: Thursday, May 23, 2019 7:25 PM
>To: dri-devel@lists.freedesktop.org
>Cc: Sean Paul ; Shankar, Uma ;
>Sharma, Shashank ; Ville Syrjälä
>; Maarten Lankhorst
>; Maxime Ripard
>; Sean Paul ; David Airlie
>; Daniel Vetter ;
This is a note to let you know that I've just added the patch titled
PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary
to the 5.0-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
We would like to get both the fence & the syncobj in i915 rather than
doing 2 calls to drm_syncobj_find() & drm_syncobj_find_fence().
Signed-off-by: Lionel Landwerlin
Cc: Christian Koenig
Cc: David(ChunMing) Zhou
Cc: Eric Anholt
CC: DRI-Devel
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 4
Ease entry for anyone wanting to pick up the bootsplash work by providing
a couple of pointers.
Signed-off-by: Noralf Trønnes
---
Documentation/gpu/todo.rst | 14 ++
1 file changed, 14 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index
On Tue, May 21, 2019 at 02:15:19PM +0200, Ondřej Jirman wrote:
> Hi Maxime,
>
> On Tue, May 21, 2019 at 01:46:11PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > On Tue, May 21, 2019 at 01:50:08AM +0200, meg...@megous.com wrote:
> > > From: Ondrej Jirman
> > >
> > > Orange Pi 3 board requires
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #11 from Utku Helvacı (tuxutku) ---
I have bisected the bug, also i have reported it:
https://bugzilla.kernel.org/show_bug.cgi?id=201077
its been a month since reporting it to linux kernel amd team, they acknowledged
the problem.
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #13 from Andre Klapper ---
> its actually been more then two months since reporting it, its not fixed yet
You (or anyone else) needs to volunteer to investigate and provide a patch.
--
You are receiving this mail because:
You are
On Wed, May 22, 2019 at 11:54 PM Torsten Duwe wrote:
>
> From: Icenowy Zheng
>
> Teres-I has an anx6345 bridge connected to the RGB666 LCD output, and
> the I2C controlling signals are connected to I2C0 bus. eDP output goes
> to an Innolux N116BGE panel.
>
> Enable it in the device tree.
>
>
On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
>
> +# define roundup_64(x, y) (\
> +{ \
> + typeof(y) __y = y; \
> + typeof(x) __x = (x) + (__y - 1);\
>
>From Daniel Kwon
The system was crashed due to invalid memory access while trying to access
auxiliary device.
crash> bt
PID: 9863 TASK: 89d1bdf11040 CPU: 1 COMMAND: "ipmitool"
#0 [89cedd7f3868] machine_kexec at b0663674
#1 [89cedd7f38c8] __crash_kexec at
On Thu, May 23, 2019 at 11:05:40AM +0200, Maxime Ripard wrote:
> > +Optional properties:
> > +
> > + - Video ports for RGB input and eDP output using the DT bindings
> > + defined in [1]
>
> The output node can be optional, but the input one is probably going
> to be needed all the time, since
No functional changes, just moving code as-is and fixing includes.
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client_modeset.c | 707 ++-
drivers/gpu/drm/drm_fb_helper.c | 692
Am 22.05.19 um 20:30 schrieb Daniel Vetter:
> [SNIP]
>> Well, it seems you are making incorrect assumptions about the cache
>> maintenance of DMA-buf here.
>>
>> At least for all DRM devices I'm aware of mapping/unmapping an
>> attachment does *NOT* have any cache maintenance implications.
>>
>>
On Thu, May 23, 2019 at 1:30 PM Daniel Vetter wrote:
>
> On Thu, May 23, 2019 at 1:21 PM Koenig, Christian
> wrote:
> >
> > Am 22.05.19 um 20:30 schrieb Daniel Vetter:
> > > [SNIP]
> > >> Well, it seems you are making incorrect assumptions about the cache
> > >> maintenance of DMA-buf here.
> >
This moves the modesetting code from drm_fb_helper to drm_client so it
can be shared by all internal clients.
Changes this time:
- Improve commit messages
All patches have been reviewed now, thanks alot for reviewing!
Noralf.
Noralf Trønnes (8):
drm/atomic: Move
struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so
use that directly instead and attach it as a modeset array onto
drm_client_dev. drm_fb_helper will use this array to store its modesets
which means it will always initialize a drm_client, but it will not
register the client
All drivers add all their connectors so there's no need to keep around an
array of available connectors. Instead we just put the useable (not
writeback) connectors in a temporary array using
drm_client_for_each_connector_iter() everytime we probe the outputs.
Other places where it's necessary to
This prepares the modeset code so it can be moved out as-is in the next
patch.
v3: Remove stray newline
Signed-off-by: Noralf Trønnes
Reviewed-by: Maxime Ripard
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_fb_helper.c | 62 +++--
include/drm/drm_fb_helper.h
Move the modeset commit code to drm_client_modeset.
No changes except exporting API.
v2: Move to drm_client_modeset.c instead of drm_client.c
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_client_modeset.c | 287 +++
Prepare for moving drm_fb_helper modesetting code to drm_client.
drm_client will be linked to drm.ko, so move
__drm_atomic_helper_disable_plane() and __drm_atomic_helper_set_config()
out of drm_kms_helper.ko.
While at it, fix two checkpatch complaints:
- WARNING: Block comments use a trailing */
An example to showcase the client API.
TODO:
- A bootsplash client needs a way to tell drm_fb_helper to stay away,
otherwise it will chime in on setup and hotplug.
Most DRM drivers register fbdev before calling drm_dev_register() (the
generic emulation is an exception). This have to be
This makes the necessary changes so the commit code can be moved out to
drm_client as-is in the next patch. It's split up to ease review.
Signed-off-by: Noralf Trønnes
Reviewed-by: Sam Ravnborg
---
drivers/gpu/drm/drm_fb_helper.c | 122 +---
1 file changed, 81
On Thu, 23 May 2019 08:10:44 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 7:00 AM Steven Rostedt wrote:
> >
> > +# define roundup_64(x, y) (\
> > +{ \
> > + typeof(y) __y = y;
Am 22.05.19 um 13:29 schrieb Daniel Vetter:
> [SNIP]
> Forgot to add: Iirc it was buffer sharing between i915 and amdgpu that
> hits this. Can't say for sure since intel-gfx isn't cc'ed on this
> version, so our CI hasn't picked this up.
I've changed this so that when exporter/importer disagree
This is a note to let you know that I've just added the patch titled
PCI: Reset Lenovo ThinkPad P50 nvgpu at boot if necessary
to the 5.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
On Thu, May 23, 2019 at 1:21 PM Koenig, Christian
wrote:
>
> Am 22.05.19 um 20:30 schrieb Daniel Vetter:
> > [SNIP]
> >> Well, it seems you are making incorrect assumptions about the cache
> >> maintenance of DMA-buf here.
> >>
> >> At least for all DRM devices I'm aware of mapping/unmapping an
>
在 2019/5/23 19:03, Christian König 写道:
> [CAUTION: External Email]
>
> Am 23.05.19 um 12:24 schrieb zhoucm1:
>>
>>
>> On 2019年05月22日 20:59, Christian König wrote:
>>> [CAUTION: External Email]
>>>
>>> BOs on the LRU might be blocked during command submission
>>> and cause OOM situations.
>>>
>>>
From: Steven Rostedt (VMware)
In discussing a build failure on x86_32 due to the use of roundup() on
a 64 bit number, I realized that there's no generic equivalent
roundup_64(). It is implemented in two separate places in the kernel,
but there really should be just one that all can use.
Hi,
On Thu, 2019-05-23 at 16:26 +0200, Noralf Trønnes wrote:
> Ease entry for anyone wanting to pick up the bootsplash work by providing
> a couple of pointers.
>
> Signed-off-by: Noralf Trønnes
I think a native DRM bootsplash would be a great thing to have!
Reviewed-by: Paul Kocialkowski
On Thu, May 23, 2019 at 10:50:41AM +0300, Laurent Pinchart wrote:
> Hi Torsten,
>
> Thank you for the patch.
Thank you for the thorough review!
> On Thu, May 23, 2019 at 08:53:56AM +0200, Torsten Duwe wrote:
> > +{
> > + struct anx6345 *anx6345 = connector_to_anx6345(connector);
> > + int
Hi Maxime,
On Thu, 23 May 2019 13:53:55 +0200 Maxime Ripard
wrote:
>
> On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> >
> > between
https://bugs.freedesktop.org/show_bug.cgi?id=109073
--- Comment #12 from Utku Helvacı (tuxutku) ---
its actually been more then two months since reporting it, its not fixed yet
--
You are receiving this mail because:
You are the assignee for the
Am 23.05.19 um 13:50 schrieb Zhou, David(ChunMing):
> 在 2019/5/23 19:03, Christian König 写道:
>> [CAUTION: External Email]
>>
>> Am 23.05.19 um 12:24 schrieb zhoucm1:
>>>
>>> On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
BOs on the LRU might be blocked during
Am 23.05.19 um 12:24 schrieb zhoucm1:
On 2019年05月22日 20:59, Christian König wrote:
[CAUTION: External Email]
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
can you make the parameter optional? Otherwise looks good to me.
-David
Original Message
Subject: [PATCH 1/2] drm/syncobj: add an output syncobj parameter to find_fence
From: Lionel Landwerlin
To: intel-...@lists.freedesktop.org
CC: Lionel Landwerlin ,"Koenig, Christian"
I should mentioned that this is going to make the find_fence() function
a fair bit more complex :)
On 23/05/2019 14:35, Lionel Landwerlin wrote:
Sure
-Lionel
On 23/05/2019 13:11, Zhou, David(ChunMing) wrote:
can you make the parameter optional? Otherwise looks good to me.
-David
From: Sean Paul
Fixes the following warnings:
../drivers/gpu/drm/drm_edid.c:4925: warning: Function parameter or member
'conn_state' not described in 'drm_hdmi_infoframe_set_hdr_metadata'
../drivers/gpu/drm/drm_edid.c:4925: warning: Excess function parameter
'hdr_metadata' description in
Hi Daniel,
On Thu, 23 May 2019 15:11:15 +0200 Daniel Vetter wrote:
>
> That commit is on top of drm-misc, and somehow the .txt version has
> been resurrect in drm-misc-next (so needs to be re-deleted too).
My mistake, the conflict went away (due to the back merge) so my
scripts assumed the file
On Thu, May 23, 2019 at 3:04 PM Stephen Rothwell wrote:
>
> Hi Maxime,
>
> On Thu, 23 May 2019 13:53:55 +0200 Maxime Ripard
> wrote:
> >
> > On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > >
> > > Today's linux-next merge of the drm-misc tree got a conflict in:
> > >
> > >
On Thu, May 23, 2019 at 03:44:49PM +0100, Catalin Marinas wrote:
> There is also the obvious requirement which I didn't mention: new user
> space continues to run on new/subsequent kernel versions. That's one of
> the points of contention for this series (ignoring MTE) with the
> maintainers
On Thu, May 23, 2019 at 02:13:20PM +0800, CK Hu wrote:
> Hi, Sean:
>
> On Wed, 2019-05-22 at 16:21 -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > Fixes the following build warning:
> > drivers/gpu/drm/mediatek/mtk_hdmi.c:327:2: warning: enumeration value
> > ‘HDMI_INFOFRAME_TYPE_DRM’ not
On Thu, 23 May 2019 09:51:29 -0700
Linus Torvalds wrote:
> On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
> >
> > I haven't yet tested this, but what about something like the following:
>
> So that at least handles the constant case that the normal "roundup()"
> case also handles.
>
https://bugs.freedesktop.org/show_bug.cgi?id=110217
--- Comment #4 from numz...@yandex.ru ---
Just downgraded xf86-video-amdgpu back to 19.0.0-1. The flicker disappeared.
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=110736
--- Comment #1 from Mathieu Belanger ---
I have the same bug
It started yesterday after a reboot.
Between the reboot and the previous reboot I did emerge -e the whole things so
I'm not totally sure it's mesa related
I have the bug in:
*
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #13 from Mathieu Belanger ---
That bug was affecting Discord, Brave and Chromium.
Fixed by reverting : 811fa9a79cf
--
You are receiving this mail because:
You are the assignee for the
Hi Linus, Gerd.
> This moves the modesetting code from drm_fb_helper to drm_client so it
> can be shared by all internal clients.
Could one of you take a look at this series.
Daniel already ack'ed the series on irc, but an extra pair of eyes
is never bad.
For my part I have been through them
On Thu, May 23, 2019 at 02:38:37PM +, Shankar, Uma wrote:
>
>
> >-Original Message-
> >From: Sean Paul [mailto:s...@poorly.run]
> >Sent: Thursday, May 23, 2019 7:25 PM
> >To: dri-devel@lists.freedesktop.org
> >Cc: Sean Paul ; Shankar, Uma ;
> >Sharma, Shashank ; Ville Syrjälä
> >;
https://bugs.freedesktop.org/show_bug.cgi?id=110736
--- Comment #2 from Mathieu Belanger ---
Created attachment 144332
--> https://bugs.freedesktop.org/attachment.cgi?id=144332=edit
Brave browser
Here a screenshot of a Brave browser tab
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110736
--- Comment #3 from Mathieu Belanger ---
I would also add that the previous git version I did compile did not have the
problem (Fri May 10 17:39:53 2019)
--
You are receiving this mail because:
You are the assignee for the
Den 23.05.2019 15.44, skrev Noralf Trønnes:
> struct drm_fb_helper_crtc is now just a wrapper around drm_mode_set so
> use that directly instead and attach it as a modeset array onto
> drm_client_dev. drm_fb_helper will use this array to store its modesets
> which means it will always initialize
https://bugs.freedesktop.org/show_bug.cgi?id=110736
Mathieu Belanger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thu, May 23, 2019 at 8:27 AM Steven Rostedt wrote:
>
> I haven't yet tested this, but what about something like the following:
So that at least handles the constant case that the normal "roundup()"
case also handles.
At the same time, in the case you are talking about, I really do
suspect
From: Sean Paul
This rename makes it more clear that everything initialized in the _init
function must be cleaned up in a6xx_gmu_remove. This will hopefully
dissuade people from using device managed resources (for reasons laid
out in the previous patch).
Changes in v2:
- None
Cc: Jordan Crouse
From: Sean Paul
a6xx_gmu_stop() already calls this function via shutdown or force_stop,
so it's not necessary to call it twice. Previously this would have
knocked the irq refcount out of sync, but now with the irqs_enabled flag
it's just housekeeping.
Changes in v2:
- None
Cc: Jordan Crouse
From: Sean Paul
The gmu driver is initialized and cleaned up with calls from the gpu driver. As
such, the platform device stays valid after a6xx_gmu_remove is called and the
device managed resources are not freed. In the case of gpu probe failures or
unbind, these resources will remain managed.
From: Sean Paul
of_find_device_by_node() grabs a dev reference, so make sure we clear it
on error and remove.
Changes in v2:
- Added to the set (Jordan)
Cc: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 14 +++---
1 file changed, 11
From: Sean Paul
pdcptr and seqptr aren't necessarily valid, check them before trying to
unmap them.
Changes in v2:
- None
Cc: Jordan Crouse
Signed-off-by: Sean Paul
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
From: Lyude Paul
commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream.
On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M
variant, the BIOS does not always reset the secondary Nvidia GPU during
reboot if the laptop is configured in Hybrid Graphics mode. The reason is
On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote:
> Hi Daniel and Dave,
>
> We keep adding support for panels at a high rate, is it still worth listing
> them individually under cross subsystem changes?
>
> First pull req for v5.3 here, enjoy!
> As I was writing this mail, I
On Thu, May 23, 2019 at 5:53 PM Sean Paul wrote:
>
> On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote:
> > Hi Daniel and Dave,
> >
> > We keep adding support for panels at a high rate, is it still worth listing
> > them individually under cross subsystem changes?
> >
> > First
On Thu, May 23, 2019 at 5:55 PM Daniel Vetter wrote:
>
> On Thu, May 23, 2019 at 5:53 PM Sean Paul wrote:
> >
> > On Thu, May 23, 2019 at 05:47:04PM +0200, Maarten Lankhorst wrote:
> > > Hi Daniel and Dave,
> > >
> > > We keep adding support for panels at a high rate, is it still worth
> > >
With Sphinx 2.0 (or prior versions with the deprecation warnings fixed) the
docs build fails with:
Documentation/gpu/i915.rst:403: WARNING: Title level inconsistent:
Global GTT Fence Handling
~
reST markup error:
Documentation/gpu/i915.rst:403: (SEVERE/4) Title
From: Sean Paul
The driver checks for gmu->mmio as a sign that the device has been
initialized, however there are failures in probe below the mmio init.
If one of those is hit, mmio will be non-null but freed.
In that case, a6xx_gmu_probe will return an error to a6xx_gpu_init which
will in turn
https://bugs.freedesktop.org/show_bug.cgi?id=110217
--- Comment #5 from numz...@yandex.ru ---
The flicker seems to be due to
https://bugs.freedesktop.org/show_bug.cgi?id=102646, despite the fact Arch wiki
tells that affects 120+ Hz only (my monitor runs at 75 Hz). At least fixing
clocks fixes the
https://bugs.freedesktop.org/show_bug.cgi?id=110721
--- Comment #15 from alvarex ---
>
> Using master + this commit reverted: no more corruption in chromium.
I reverted the commit on 19.1.0 rc3 and it works as well.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110217
--- Comment #3 from numz...@yandex.ru ---
New information:
1. Screen turns black at module insertion, be it during bootup or later. But
resuming from hibernation works.
2. On the system, the converter I use is problematic itself. When I
https://bugs.freedesktop.org/show_bug.cgi?id=110721
Mathieu Belanger changed:
What|Removed |Added
CC||0xe2.0x9a.0...@gmail.com
---
Hi Daniel and Dave,
We keep adding support for panels at a high rate, is it still worth listing
them individually under cross subsystem changes?
First pull req for v5.3 here, enjoy!
As I was writing this mail, I missed a fix in mtk_hdmi_hw_send_info_frame for
the unhandled
HDR case in switch,
On Thu, May 23, 2019 at 6:54 AM Maxime Ripard wrote:
>
> On Tue, May 21, 2019 at 10:51:51AM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > Today's linux-next merge of the drm-misc tree got a conflict in:
> >
> > Documentation/devicetree/bindings/vendor-prefixes.txt
> >
> > between commit:
>
From: Lyude Paul
commit e0547c81bfcfad01cbbfa93a5e66bb98ab932f80 upstream.
On ThinkPad P50 SKUs with an Nvidia Quadro M1000M instead of the M2000M
variant, the BIOS does not always reset the secondary Nvidia GPU during
reboot if the laptop is configured in Hybrid Graphics mode. The reason is
1 - 100 of 155 matches
Mail list logo
