On Monday, May 07, 2018 03:15:22 PM Tomi Valkeinen wrote:
> omapfb is not maintained by me anymore, so drop my name from the
> maintainers, and mark omapfb as orphan.
>
> At some point in the future we should mark omapfb as obsolete, but there
> are still some features supported by omapfb which
https://bugs.freedesktop.org/show_bug.cgi?id=105880
--- Comment #22 from Przemek ---
Just to supplement the list above.
Netbook Lenovo g50-45, a6-6310 R4 Beema/Mullins.
Has HDMI and VGA output.
HDMI is working without a hitch, while VGA output is dead.(eDP plus only one
extra monitor
On Sat, Jun 2, 2018 at 12:57 AM, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Ref->
2018-06-07 9:07 GMT+02:00 Christian König :
> Am 06.06.2018 um 17:44 schrieb Gabriel C:
>>
>> 2018-06-06 17:03 GMT+02:00 Michel Dänzer :
>>>
>>> On 2018-06-06 04:44 PM, Christian König wrote:
Am 06.06.2018 um 16:12 schrieb Michel Dänzer:
[SNIP]
At least in theory it should work
Hi Lucas,
Here you can find the test I used (actually pretty the same as your) :
https://github.com/julbouln/test_omap5_drm/blob/master/test_viv2d.c#L472
And my fix that make it works :
https://github.com/julbouln/etnaviv_x15/blob/master/etnaviv_cmd_parser.c#L182
(sorry it is kernel 4.9)
As a
On 06/07/2018 04:44 AM, Oleksandr Andrushchenko wrote:
> On 06/07/2018 12:48 AM, Boris Ostrovsky wrote:
>> On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote:
>>> On 06/05/2018 01:07 AM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr Andrushchenko wrote:
>>
+
+static
Dne četrtek, 07. junij 2018 ob 00:30:24 CEST je Jernej Škrabec napisal(a):
> Dne ponedeljek, 04. junij 2018 ob 18:23:57 CEST je Maxime Ripard napisal(a):
> > On Mon, Jun 04, 2018 at 05:09:56PM +0200, Jernej Škrabec wrote:
> > > Dne ponedeljek, 04. junij 2018 ob 13:50:34 CEST je Maxime Ripard
>
>
This adds support for the Rocktech Display Ltd. RK070ER9427
800(RGB)x480 TFT LCD panel, which can be supported by the
simple panel driver.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
---
Changes for v2:
- collect Rob r-w-b tag
.../display/panel/rocktech,rk070er9427.txt | 25
>> Well that is very interesting, you are the first one who reports that SME +
>> GFX works in some way. So far we only got negative reports for that.
>>
>>> There is a 4.16.13 boot dmesg which has no such issue:
>>>
>>>
>>>
Hi, CK:
On Mon, 2018-05-28 at 15:53 +0800, CK Hu wrote:
> Hi, Stu:
>
> Two inline comment.
>
> On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> > This patch add support for the Mediatek MT2712 DISP subsystem.
> > There are two OVL engine and three disp output in MT2712.
> >
> >
[ + linux-fbdev ML ]
On Thursday, May 31, 2018 03:02:52 PM r...@google.com wrote:
> From: Christoffer Dall
>
> User space Android code identifies pixclock == 0 as a sign for emulation
> and will set the frame rate to 60 fps when reading this value, which is
> the desired outcome.
>
>
[ + linux-fbdev ML ]
Hi,
On Thursday, May 31, 2018 03:02:51 PM r...@google.com wrote:
> From: Yu Ning
>
> Follow the same way in which ACPI was enabled for goldfish battery. See
> commit d3be10e for details.
No commit d3be10e in upstream and -next kernels?
> Note that this patch also
The video timings are stored in the CRTC structure by the
omap_crtc_dss_set_timings() function, called by dss_mgr_set_timings()
from the .enable() operation of the internal encoders. This instead
belongs to the .set_timings() code paths. Move the
omap_crtc_dss_set_timings() calls accordingly.
Instead of call the dispc timings check function dispc_mgr_timings_ok()
from the internal encoders .check_timings() operation, expose it through
the dispc ops (after renaming it to check_timings) and call it directly
from omapdrm. This allows removal of now empty omap_dss_device
.check_timings()
The bus flags stored in omap_dss_device instances are used to fixup the
video mode before setting it, to honour constraints that can't be
expressed through drm_display_mode. The fixup occurs in the CRTC mode
set operation and the resulting video mode is stored internally in the
CRTC. It is then
Timings for the TV output are currently reported by the analog TV
connector. This has the disadvantage of having to handle timing-related
operations in a connector omap_dss_device that has, at the hardware
level, no knowledge of any timing information.
Implement the .get_timings() operation in
Panels drivers store their timings in a device data structure field that
is initialized at probe time, either from hardcoded values or from
firmware-supplied values. Those timings are then reported through the
.get_timings() operation to construct the panel display mode.
The panel timings are
The SDI encoder modifies the pixel clock of the requested video mode to
take the limitations of the PLL into account in the .enable() operation.
This should be performed in the .check_timings() operation instead. Move
the fixup.
Signed-off-by: Laurent Pinchart
---
The video mode is aleady fixed up by the .check_timings() operation,
there's no need to repeat that when enabling the DPI output.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/dpi.c | 12 +---
1 file changed, 1 insertion(+), 11 deletions(-)
diff --git
The VENC encoder modifies the requested video mode to match the NTSC or
PAL timings (or reject the video mode completely) in the .set_timings()
operation. This should be performed in the .check_timings() operation
instead. Move the fixup.
Signed-off-by: Laurent Pinchart
---
The encoder enable operation currently performs mode fixup and mode
setting for all omap_dss_device instances in the display pipeline. There
are dedicated encoder operations for those operations (respectively
.atomic_check() and .mode_set()), but they are not used for this
purpose.
Move the mode
Constify many pointers to struct videomode, as well as pointers to
container structures, to ensure the video mode isn't modified after
the .check_timings() operation.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/dss/hdmi.h | 8
drivers/gpu/drm/omapdrm/dss/hdmi4.c
The DSI encoder modifies the passed videomode to take the requirements
of the internal DISPC-DSI bus into account in the .enable_video_output()
operation. This should be performed in the .check_timings() operation
instead. There is however no .check_timings() operation as the DSI
encoder uses a
https://bugzilla.kernel.org/show_bug.cgi?id=199619
--- Comment #5 from Elmar Stellnberger (estel...@elstel.org) ---
The issue persists with kernel 4.17.0+.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel
On Monday, May 28, 2018 05:46:19 PM Arnd Bergmann wrote:
> I got a bunch of warnings in a randconfig build:
>
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/video/fbdev/omap/lcd_ams_delta.o
> WARNING: modpost: missing MODULE_LICENSE() in
> drivers/video/fbdev/omap/lcd_inn1510.o
>
The .check_timings() operation is called recursively from the display
device back to the output device. Most components just forward the
operation to the previous component in the chain, resulting in lots of
duplicated pass-through functions. To avoid that, iterate over the
components manually.
The analog TV, DVI and HDMI connectors all report timing information
through the .get_timings() information.
For analog TV outputs the information is queried from the encoder, so
the operation is unused. Remove it.
For HDMI outputs the display pipeline provides EDID capability, so the
operation
Hello,
This patch series reworks all the timing-related operations (.get_timings(),
.set_timings() and .check_timings()) as a step toward moving from
omap_dss_device to drm_bridge.
All timing-related operations are called by the omapdrm driver on the
omap_dss_device at the end of display
The .set_timings() operations of the omap_dss_device instances don't
need to modify the passed timings. Make the pointer const.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/connector-analog-tv.c | 2 +-
drivers/gpu/drm/omapdrm/displays/connector-dvi.c| 2
The two functions implement the .set_timings() and .check_timings()
operations. Rename them to hdmi_disply_set_timings() and
hdmi_display_check_timings() respectively to match the operations names
and make searching the source code easier.
Signed-off-by: Laurent Pinchart
---
The .check_timings() operation is present in all panels and connectors.
The fallback that uses .get_timings() in the absence of .check_timings()
is thus unneeded.
While it could be argued that the fallback implements a useful check
that should be extended to cover all fixed-resolution panels, the
Instead of determining the connector type from the type of the display's
omap_dss_device and passing it to the omap_connector_init() function,
move the type determination code to omap_connector.c and remove the type
argument to the connector init function. This moves code to a more
natural
The omap_dss_device .set_timings() operation for external encoders
stores the video mode in the device data structure. That mode is then
never used again. Drop it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/displays/encoder-opa362.c| 5 -
Source components in the display pipeline need to configure their output
signals polarities and clock driving edge based on the requirements of
the sink component.
Those requirements are currently shared across the whole pipeline in the
flags of a videomode structure, instead of being local to
The drm_connector implementation requires access to the omap_dss_device
corresponding to the display, which is passed to its initialization
function and stored internally. Refactoring of the timings operations
will require access to the output omap_dss_device. To prepare for that,
pass it to the
The drm_display_info structure contains bus flags that specify on which
pixel clock edge the data are driven and sampled. Add a set of flags to
specify the pixel clock edge for sync signals, as they can be driven and
sampled on the opposite clock edge of the data signals.
Signed-off-by: Laurent
The omap_dss_device .set_timings() operations are called directly from
omap_encoder_update(), and indirectly from the omap_dss_device .enable()
operation. The latter is called from omap_encoder_enable(), right after
calling omap_encoder_update(). The .set_timings() operation it thus
called twice
On Wednesday, May 30, 2018 11:49:22 PM Arnd Bergmann wrote:
> Building the omap sub-drivers when CONFIG_GPIOLIB is disabled causes
> lots of build failures, either from using gpiolib interfaces, or from
> including the wrong headers:
>
> drivers/video/fbdev/omap2/omapfb/displays/encoder-opa362.c:
Instead of calling the .set_timings() operation recursively from the
display device backwards, iterate over the devices manually in the DRM
encoder code. This moves the complexity to a single central location and
simplifies the logic in omap_dss_device drivers.
Signed-off-by: Laurent Pinchart
Lucas Stach writes:
> Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt:
>> This isn't the first time I've had to argue to myself why the '++' was
>> safe.
>
> And now you need to do the same thing with me...
>
>> Signed-off-by: Eric Anholt
>> ---
>> drivers/gpu/drm/v3d/v3d_fence.c
On Fri, Jun 1, 2018 at 11:11 AM, Souptick Joarder wrote:
> On Tue, May 22, 2018 at 11:43 PM, Souptick Joarder
> wrote:
>> Use new return type vm_fault_t for fault handler. For
>> now, this is just documenting that the function returns
>> a VM_FAULT value rather than an errno. Once all instances
On 06/07/2018 03:17 AM, Oleksandr Andrushchenko wrote:
> On 06/07/2018 12:32 AM, Boris Ostrovsky wrote:
>> On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote:
>>> On 06/04/2018 11:49 PM, Boris Ostrovsky wrote:
> diff --git a/drivers/xen/gntdev.c b/drivers/xen/gntdev.c
> index
(Stefano, question for you at the end)
On 06/07/2018 02:39 AM, Oleksandr Andrushchenko wrote:
> On 06/07/2018 12:19 AM, Boris Ostrovsky wrote:
>> On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote:
>>> On 06/04/2018 11:12 PM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr
https://bugzilla.kernel.org/show_bug.cgi?id=199979
Bug ID: 199979
Summary: amdgpu: changing pwm1_enable from 1 to 2 does not
resume automatic fan control
Product: Drivers
Version: 2.5
Kernel Version: 4.17.0
Hardware:
https://bugzilla.kernel.org/show_bug.cgi?id=73931
Mateusz Lenik (m...@mlen.pl) changed:
What|Removed |Added
CC||m...@mlen.pl
--- Comment
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #8 from Christian König (christian.koe...@amd.com) ---
Mhm, I've tried the same ASIC (Polaris 10 8gb) in an AMD Threadripper and here
it is working quite fine with suspend/resume.
So the only explanation I have is that this is some
Hi,
On 22/05/18 21:13, Souptick Joarder wrote:
> Use new return type vm_fault_t for fault handler. For
> now, this is just documenting that the function returns
> a VM_FAULT value rather than an errno. Once all instances
> are converted, vm_fault_t will become a distinct type.
>
> Ref-> commit
Hi Christoph,
Am 08.06.2018 um 08:01 schrieb Christoph Hellwig:
On Thu, Jun 07, 2018 at 07:20:37PM +0200, Christian König wrote:
Hi Christopher,
I don't see a Christopher on the Cc list..
Sorry, auto-uncorrection. I indeed meant you :)
Christian.
https://bugs.freedesktop.org/show_bug.cgi?id=106856
jorg...@cirsa.com changed:
What|Removed |Added
Resolution|WONTFIX |FIXED
--- Comment #2 from
Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt:
> This isn't the first time I've had to argue to myself why the '++' was
> safe.
And now you need to do the same thing with me...
> Signed-off-by: Eric Anholt
> ---
> drivers/gpu/drm/v3d/v3d_fence.c | 3 +++
> 1 file changed, 3
On 06/08/2018 01:30 AM, Boris Ostrovsky wrote:
On 06/07/2018 04:44 AM, Oleksandr Andrushchenko wrote:
On 06/07/2018 12:48 AM, Boris Ostrovsky wrote:
On 06/06/2018 08:10 AM, Oleksandr Andrushchenko wrote:
On 06/05/2018 01:07 AM, Boris Ostrovsky wrote:
On 06/01/2018 07:41 AM, Oleksandr
On 08.06.2018 00:50, Heiko Stuebner wrote:
> Am Donnerstag, 7. Juni 2018, 23:10:20 CEST schrieb Brian Norris:
>> Hi,
>>
>> I only have a little bit to add, but Heiko did solicit my opinion.
> yep ... and I realized that I am/was way to attached to my (working)
> endpoint-based thingy to really
https://bugs.freedesktop.org/show_bug.cgi?id=106856
Christian König changed:
What|Removed |Added
Resolution|--- |WONTFIX
Status|NEW
On 06/08/2018 12:46 AM, Boris Ostrovsky wrote:
(Stefano, question for you at the end)
On 06/07/2018 02:39 AM, Oleksandr Andrushchenko wrote:
On 06/07/2018 12:19 AM, Boris Ostrovsky wrote:
On 06/06/2018 04:14 AM, Oleksandr Andrushchenko wrote:
On 06/04/2018 11:12 PM, Boris Ostrovsky wrote:
There is no need to flip reset pin twice. Also delays can be changed to
values present in vendor's code.
Signed-off-by: Andrzej Hajda
---
Hi,
This is v2 of forgotten patch, awaiting reviewers, any volunteers.
Also "drm/bridge/sii8620: fix loops in EDID fetch logic" waits for reviewers.
In this
Am 08.06.2018 um 08:02 schrieb Christoph Hellwig:
On Thu, Jun 07, 2018 at 02:32:46PM +0200, Gabriel C wrote:
Ok done.. bisect points to:
What is the failure mode you are seeing? Can't find anything in the
mail unfortunately.
As far as I analyzed it we now get an -ENOMEM from
This series re-factors the devfreq code a bit in preparation for the upcoming
A6x related devfreq changes. The code applies cleanly on 4.17 and has been
verified on DB820C.
V2: Addressed code review comments from Jordan Crouse.
V3: Added a new patch for devfreq cleanup.
V4: removed "drm/msm: move
Devfreq turns on and starts recommending power level as soon as it is
initialized. The GPU is still not powered on by the time the devfreq
init happens and this leads to problems on GPU's where register access
is needed to get/set power levels. So we start suspended and only restart
devfreq when
Call the devfreq_remove_device() API to remove the GPU devfreq instance
during GPU driver cleanup.
Signed-off-by: Sharat Masetty
---
drivers/gpu/drm/msm/msm_gpu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c b/drivers/gpu/drm/msm/msm_gpu.c
index
Am 08.06.2018 um 06:36 schrieb Souptick Joarder:
On Sat, Jun 2, 2018 at 12:57 AM, Souptick Joarder wrote:
Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted,
Hi Andrzej,
On 2018-06-08 08:04, Andrzej Hajda wrote:
> There is no need to flip reset pin twice. Also delays can be changed to
> values present in vendor's code.
>
> Signed-off-by: Andrzej Hajda
Tested-by: Marek Szyprowski
> ---
> Hi,
>
> This is v2 of forgotten patch, awaiting reviewers,
Hi Andrzej,
On 2018-01-15 18:33, Andrzej Hajda wrote:
> Function should constantly check if cable is connected and finish
> in finite time.
>
> Signed-off-by: Andrzej Hajda
Tested-by: Marek Szyprowski
> ---
> drivers/gpu/drm/bridge/sil-sii8620.c | 31 ---
> 1
On 08/06/18 10:17, Neil Armstrong wrote:
> Hi Hans,
>
> On 08/06/2018 09:53, Hans Verkuil wrote:
>> On 06/01/2018 10:19 AM, Neil Armstrong wrote:
>>> Hi All,
>>>
>>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
>>> through it's Embedded Controller, to enable the Linux
https://bugs.freedesktop.org/show_bug.cgi?id=106856
Bug ID: 106856
Summary: amdgpu kernel warning playing vdpau videos
Product: Mesa
Version: git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #6 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Created attachment 276391
--> https://bugzilla.kernel.org/attachment.cgi?id=276391=edit
lspci -t -v -nn
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #7 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Created attachment 276393
--> https://bugzilla.kernel.org/attachment.cgi?id=276393=edit
/proc/iomem
--
You are receiving this mail because:
You are watching the assignee of
On 06/08/2018 01:26 AM, Boris Ostrovsky wrote:
On 06/07/2018 03:17 AM, Oleksandr Andrushchenko wrote:
On 06/07/2018 12:32 AM, Boris Ostrovsky wrote:
On 06/06/2018 05:06 AM, Oleksandr Andrushchenko wrote:
On 06/04/2018 11:49 PM, Boris Ostrovsky wrote:
diff --git a/drivers/xen/gntdev.c
Hi Dave, these missed the main drm-next pull request.
drm-intel-next-fixes-2018-06-08-2:
First batch of i915 fixes for v4.18:
- gvt fixes that missed v4.17, potentially need to be backported
- eDP resolution regression revert
- remove broken nv12 special casing
- remove stale asserts from find
devfreq framework requires the drivers to provide busy time estimations.
The GPU driver relies on the hardware performance counters for the busy time
estimations, but different hardware revisions have counters which can be
sourced from different clocks. So the busy time estimation will be target
Hi Hans,
On 08/06/2018 09:53, Hans Verkuil wrote:
> On 06/01/2018 10:19 AM, Neil Armstrong wrote:
>> Hi All,
>>
>> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
>> through it's Embedded Controller, to enable the Linux CEC Core to communicate
>> with it and get the CEC
https://bugs.freedesktop.org/show_bug.cgi?id=105532
--- Comment #2 from Nicolas Cannasse ---
Hi,
I'm Northgard technical director.
We are creating buffers to draw various 2D shapes into textures for map
generation. Then we download the textures from GPU to CPU for additional
processing. These
On 06/01/2018 10:19 AM, Neil Armstrong wrote:
> Hi All,
>
> The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support
> through it's Embedded Controller, to enable the Linux CEC Core to communicate
> with it and get the CEC Physical Address from the correct HDMI Connector, the
>
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #5 from Christian König (christian.koe...@amd.com) ---
Ok, well that is interesting.
Please provide the output of "sudo cat /proc/iomem" and "lspci -t -v -nn".
In the meantime I will try to reproduce the issue here.
--
You are
On Mon, 2018-05-28 at 15:47 +0800, CK Hu wrote:
> Hi, Stu:
>
> One inline comment.
>
> On Mon, 2018-05-28 at 14:38 +0800, Stu Hsieh wrote:
> > This patch create third crtc by third ddp path
> >
> > Signed-off-by: Stu Hsieh
> > ---
> > drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 3 +++
> >
Am Dienstag, den 05.06.2018, 12:03 -0700 schrieb Eric Anholt:
> Since our seqno value comes from a counter associated with the GPU
> ring, not the entity (aka client), they'll be completed out of order.
> There's actually no need for this code at all, since we don't have
> enable_signaling() and
On Fri, 8 Jun 2018, Oleksandr Andrushchenko wrote:
> On 06/08/2018 12:46 AM, Boris Ostrovsky wrote:
> > (Stefano, question for you at the end)
> >
> > On 06/07/2018 02:39 AM, Oleksandr Andrushchenko wrote:
> > > On 06/07/2018 12:19 AM, Boris Ostrovsky wrote:
> > > > On 06/06/2018 04:14 AM,
https://bugzilla.kernel.org/show_bug.cgi?id=199619
--- Comment #6 from Elmar Stellnberger (estel...@elstel.org) ---
This applies to the nouveau driver.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #9 from Alexander Mezin (mezin.alexan...@gmail.com) ---
It seems that only GPU is hung, I can even SSH to the machine.
But things like restarting gdm/Xorg/unplugging the monitor didn't "fix" it.
"shutdown -h now" didn't work.
--
You
https://bugs.freedesktop.org/show_bug.cgi?id=106446
--- Comment #6 from Justin Mitzel ---
Have you tried using the amdgpu.dpm=1 kernel command? It's worked for me with
my 390X.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=105083
--- Comment #20 from Öyvind Saether ---
Since this bug remains open for some reason I'll report the following: redshift
appears to work just fine with both RX 560 & RX 470 and:
- kernel 4.17.0-1 (rx 580) / 4.18.0-0.rc0.git2 (rx 470)
- X.Org
tree: git://anongit.freedesktop.org/drm-intel topic/core-for-CI
head: e2ea2db1734a0e38b89e4d706b5f9ad9f73b1543
commit: 72041f9847abb05b9d4d7dea17631b579191ca99 [7/8] RFC: debugobjects:
capture stack traces at _init() time
config: m68k-allyesconfig (attached as .config)
compiler:
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #10 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Actually, sometimes mouse pointer moves, and only freezes after I press a few
keys/click a few times.
Also, sometimes it's just colored pattern instead of the lock screen on the
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #11 from Alexander Mezin (mezin.alexan...@gmail.com) ---
I literally have no idea what I'm doing, but adding
'amdgpu_device_resize_fb_bar(adev);' line to all 'gmc_v?_?_resume()' (because I
don't know which version is used for my card)
https://bugzilla.kernel.org/show_bug.cgi?id=199959
--- Comment #12 from Alexander Mezin (mezin.alexan...@gmail.com) ---
Created attachment 276415
--> https://bugzilla.kernel.org/attachment.cgi?id=276415=edit
dmesg: resume with device_resize_fb_bar() in gmc_v?_?_resume()
--
You are receiving
84 matches
Mail list logo
