virglrenderer has logic to validate both stride and layer_stride,
but both are always zero. The fallback for that case is:
stride = width * bytes_per_pixel
layer_stride = stride * num_layers
However, this assumption causes trouble in the following cases:
1) When allocating host-compatible
This doesn't really break userspace, since it always passes down
0 for stride/layer_stride currently. We could:
(1) modify UAPI now and add a VIRTGPU_PARAM_STRIDE_FIX feature
(2) modify the UAPI now, and not expose a corresponding feature
(i.e, VIRTGPU_PARAM_STRIDE_FIX). This would fold
https://bugs.freedesktop.org/show_bug.cgi?id=111846
--- Comment #3 from Yuxuan Shui ---
Created attachment 145611
--> https://bugs.freedesktop.org/attachment.cgi?id=145611=edit
Xorg.0.log (has a couple of suspension/hibernation)
--
You are receiving this mail because:
You are the assignee
https://bugs.freedesktop.org/show_bug.cgi?id=111846
--- Comment #2 from Yuxuan Shui ---
Created attachment 145610
--> https://bugs.freedesktop.org/attachment.cgi?id=145610=edit
dmesg (from suspend entry to exit)
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111879
--- Comment #4 from Yuxuan Shui ---
(In reply to Alex Deucher from comment #3)
> Created attachment 145608 [details] [review]
> possible fix
>
> Does this patch fix the issue?
I hiberate/resumed with this patch a couple of times, the problem
https://bugzilla.kernel.org/show_bug.cgi?id=204611
--- Comment #4 from tones...@hotmail.com ---
I've been able to narrow the problem down a bit.
The first commit where I get the scrolling amdgpu errors is
4f8b49092c37cf0c87c43bb2698d43c71cf0e4e5
Unfortunately that's a merge commit.
One of the
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #153 from ReddestDream ---
Just FYI, it appears that kernel 5.3.2 does not have the Vega 20 fix commits
that Alex Deucher mentioned.
--
You are receiving this mail because:
You are the assignee for the
With the removal of the panel-dpi from the omap drivers, the
LCD no longer works. This patch points the device tree to
a newly created panel named "logicpd,type28"
Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
Signed-off-by: Adam Ford
Acked-by: Sam Ravnborg
---
V4: No Change
V3:
With the removal of the panel-dpi from the omap drivers, the
LCD no longer works. This patch points the device tree to
a newly created panel named "logicpd,type28"
Fixes: 8bf4b1621178 ("drm/omap: Remove panel-dpi driver")
Signed-off-by: Adam Ford
Acked-by: Sam Ravnborg
---
V4: No Change
V3:
Previously, there was an omap panel-dpi driver that would
read generic timings from the device tree and set the display
timing accordingly. This driver was removed so the screen
no longer functions. This patch modifies the panel-simple
file to setup the timings to the same values previously
This patch adds documentation of device tree bindings for the WVGA panel
Logic PD Type 28 display.
Signed-off-by: Adam Ford
---
V4: Update per Rob H's suggestions and copy other panel yaml example from
5.4-rc1
V3: Correct build errors from 'make dt_binding_check'
V2: Use YAML instead of TXT
Previously, there was an omap panel-dpi driver that would
read generic timings from the device tree and set the display
timing accordingly. This driver was removed so the screen
no longer functions. This patch modifies the panel-simple
file to setup the timings to the same values previously
This patch adds documentation of device tree bindings for the WVGA panel
Logic PD Type 28 display.
Signed-off-by: Adam Ford
---
V4: Update per Rob H's suggestions and copy other panel yaml example from
5.4-rc1
V3: Correct build errors from 'make dt_binding_check'
V2: Use YAML instead of TXT
pwm_backlight_probe() re-assigns pb->levels for every brightness
level. This is not needed and was likely not intended, since
neither side of the assignment changes during the loop. Assign
the field only once.
Signed-off-by: Matthias Kaehlcke
---
drivers/video/backlight/pwm_bl.c | 4 ++--
1
On 2019-10-01 5:57 p.m., Gustavo A. R. Silva wrote:
>
> On 10/1/19 16:46, Liu, Leo wrote:
>
> + ring->sched.ready = true;
This is redundant. all the sched->ready is initialized as true, please
refer to drm_sched_init()
>>> I see... so in the following commit
On 10/1/19 16:46, Liu, Leo wrote:
+ ring->sched.ready = true;
>>> This is redundant. all the sched->ready is initialized as true, please
>>> refer to drm_sched_init()
>>>
>> I see... so in the following commit 1b61de45dfaf ("drm/amdgpu: add initial
>> VCN2.0 support (v2)")
>>
On Fri, 20 Sep 2019 09:54:10 +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Add vendor prefix for Logic Technologies Limited [1] which is a Chinese
> display manufacturer e.g. distributed by German Endrich Bauelemente
> Vertriebs GmbH [2].
>
> [1] https://logictechno.com/contact-us/
Hi,
On 10/1/19 16:29, Liu, Leo wrote:
>
> On 2019-10-01 1:16 p.m., Gustavo A. R. Silva wrote:
>> Notice that there is a *continue* statement in the middle of the
>> for loop and that prevents the code below from ever being reached:
>>
>> r = amdgpu_ring_test_ring(ring);
>> if (r) {
>>
On Fri, Sep 20, 2019 at 09:54:11AM +0200, Marcel Ziswiler wrote:
> From: Marcel Ziswiler
>
> Add display timings for the following 3 display panels manufactured by
> Logic Technologies Limited:
>
> - LT161010-2NHC e.g. as found in the Toradex Capacitive Touch Display
> 7" Parallel [1]
> -
https://bugs.freedesktop.org/show_bug.cgi?id=111879
--- Comment #3 from Alex Deucher ---
Created attachment 145608
--> https://bugs.freedesktop.org/attachment.cgi?id=145608=edit
possible fix
Does this patch fix the issue?
--
You are receiving this mail because:
You are the assignee for the
On 2019-10-01 5:43 p.m., Gustavo A. R. Silva wrote:
> Hi,
>
> On 10/1/19 16:29, Liu, Leo wrote:
>> On 2019-10-01 1:16 p.m., Gustavo A. R. Silva wrote:
>>> Notice that there is a *continue* statement in the middle of the
>>> for loop and that prevents the code below from ever being reached:
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=111879
--- Comment #2 from Alex Deucher ---
What chip is this? Please attach your full dmesg output.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
On 2019-10-01 1:16 p.m., Gustavo A. R. Silva wrote:
> Notice that there is a *continue* statement in the middle of the
> for loop and that prevents the code below from ever being reached:
>
> r = amdgpu_ring_test_ring(ring);
> if (r) {
> ring->sched.ready = false;
>
On 2019-09-30 03:39, Ville Syrjälä wrote:
On Fri, Sep 27, 2019 at 06:28:51PM -0700, Jeykumar Sankaran wrote:
The mode_config max width/height values determine the maximum
resolution the pixel reader can handle.
Not according to the docs I "fixed" a while ago.
But the same values are
used to
https://bugzilla.kernel.org/show_bug.cgi?id=205069
--- Comment #5 from freddyrei...@comcast.net ---
I've seen another report on a similar issue, where the suggestion (solution?)
was to be using a newer mesa and llvm. I am on llvm 9 and mesa 19.2.0
* media-libs/mesa
Latest version
https://bugzilla.kernel.org/show_bug.cgi?id=205069
--- Comment #4 from freddyrei...@comcast.net ---
Created attachment 285293
--> https://bugzilla.kernel.org/attachment.cgi?id=285293=edit
Xorg log from amdgpu freeze startx
--
You are receiving this mail because:
You are watching the assignee
https://bugzilla.kernel.org/show_bug.cgi?id=205069
--- Comment #3 from freddyrei...@comcast.net ---
Created attachment 285291
--> https://bugzilla.kernel.org/attachment.cgi?id=285291=edit
lspci -vv
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=205069
--- Comment #2 from freddyrei...@comcast.net ---
Created attachment 285289
--> https://bugzilla.kernel.org/attachment.cgi?id=285289=edit
lsmod
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=205069
--- Comment #1 from freddyrei...@comcast.net ---
Created attachment 285287
--> https://bugzilla.kernel.org/attachment.cgi?id=285287=edit
dmesg
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=205069
Bug ID: 205069
Summary: Black screen when starting graphical environment
Product: Drivers
Version: 2.5
Kernel Version: 5.3.1, 5.4.0-rc1, latest
Hardware: x86-64
OS: Linux
On Mon, Sep 30, 2019 at 12:43 AM Hillf Danton wrote:
>
>
> On Fri, 6 Sep 2019 18:47:09 + John Stultz wrote:
> >
> > +static int system_heap_allocate(struct dma_heap *heap,
> > + unsigned long len,
> > + unsigned long fd_flags,
> > +
Hi Tomi,
On Mon, Sep 30, 2019 at 02:15:20PM +0300, Tomi Valkeinen wrote:
> On 07/07/2019 21:18, Laurent Pinchart wrote:
> > Display connectors are modelled in DT as a device node, but have so far
> > been handled manually in several bridge drivers. This resulted in
> > duplicate code in several
Hi Tomi,
On Tue, Oct 01, 2019 at 10:04:11AM +0300, Tomi Valkeinen wrote:
> On 20/08/2019 04:16, Laurent Pinchart wrote:
>
> > @@ -,7 +1113,7 @@ int dw_mipi_dsi_bind(struct dw_mipi_dsi *dsi, struct
> > drm_encoder *encoder)
> > {
> > int ret;
> >
> > - ret =
On Tue, Oct 01, 2019 at 06:21:28PM +0200, Karol Herbst wrote:
> On Tue, Oct 1, 2019 at 3:27 PM Bjorn Helgaas wrote:
> > On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote:
> > > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg
> > > wrote:
> > > >
> > > > On Mon, Sep 30, 2019 at
Hi Ezequiel,
On Mon, Sep 30, 2019 at 05:53:00PM -0300, Ezequiel Garcia wrote:
> +Doug, Heiko:
>
> On Fri, 2019-09-06 at 15:54 +0200, Jacopo Mondi wrote:
> > Update CMM settings at in the atomic commit tail helper method.
> > The CMM is updated with new gamma values provided to the driver
> > in
https://bugs.freedesktop.org/show_bug.cgi?id=111879
--- Comment #1 from Yuxuan Shui ---
Looks like a GPU reset was triggered during hibernation and that's what's
causing the "Failed to initialize parser" error.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111879
Yuxuan Shui changed:
What|Removed |Added
Summary|Failed to initialize parser |GPU reset during
https://bugs.freedesktop.org/show_bug.cgi?id=111879
Bug ID: 111879
Summary: Failed to initialize parser after resuming from disk
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status:
On Fri, Sep 20, 2019 at 05:26:34PM +, Michael Kelley wrote:
From: Michael Kelley Sent: Wednesday, September 18,
2019 2:48 PM
>
> Without deferred IO support, hyperv_fb driver informs the host to refresh
> the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
> is
On Fri, Sep 13, 2019 at 06:02:55AM +, Wei Hu wrote:
Without deferred IO support, hyperv_fb driver informs the host to refresh
the entire guest frame buffer at fixed rate, e.g. at 20Hz, no matter there
is screen update or not. This patch supports deferred IO for screens in
graphics mode and
On Wed, Sep 11, 2019 at 11:34:10PM +, Dexuan Cui wrote:
This patch depends on the vmbus side change of the definition of
struct hv_driver.
Signed-off-by: Dexuan Cui
Queued up for hyperv-next, thanks!
--
Thanks,
Sasha
From: Peter Griffin
Some SoCs like HiKey have 2 reset lines, so update
to use the devm_reset_control_array_* variant of the
API so that multiple resets can be specified in DT.
Cc: Qiang Yu
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Cc: l...@lists.freedesktop.org
Notice that there is a *continue* statement in the middle of the
for loop and that prevents the code below from ever being reached:
r = amdgpu_ring_test_ring(ring);
if (r) {
ring->sched.ready = false;
goto done;
}
Fix this by removing the
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15
From: Hans de Goede
[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ]
Bail from the pci_driver probe function instead of from the drm_driver
load function.
This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15
From: Felix Kuehling
[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by:
From: Hans de Goede
[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ]
Bail from the pci_driver probe function instead of from the drm_driver
load function.
This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15
From: Felix Kuehling
[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by:
From: Hans de Goede
[ Upstream commit 9dbc88d013b79c62bd845cb9e7c0256e660967c5 ]
Bail from the pci_driver probe function instead of from the drm_driver
load function.
This avoid /dev/dri/card0 temporarily getting registered and then
unregistered again, sending unwanted add / remove udev events
From: Trek
[ Upstream commit 73d8e6c7b841d9bf298c8928f228fb433676635c ]
Do not try to allocate any amount of memory requested by the user.
Instead limit it to 128 registers. Actually the longest series of
consecutive allowed registers are 48, mmGB_TILE_MODE0-31 and
mmGB_MACROTILE_MODE0-15
From: Felix Kuehling
[ Upstream commit dcafbd50f2e4d5cc964aae409fb5691b743fba23 ]
Hawaii needs to flush caches explicitly, submitting an IB in a user
VMID from kernel mode. There is no s_fence in this case.
Fixes: eb3961a57424 ("drm/amdgpu: remove fence context from the job")
Signed-off-by:
On Tue, Oct 01, 2019 at 10:09:46AM -0600, Mat King wrote:
> Resending in plain text mode
>
> I have been looking into adding Linux support for electronic privacy
> screens which is a feature on some new laptops which is built into the
> display and allows users to turn it on instead of needing to
On Tue, Oct 1, 2019 at 3:27 PM Bjorn Helgaas wrote:
>
> On Mon, Sep 30, 2019 at 06:36:12PM +0200, Karol Herbst wrote:
> > On Mon, Sep 30, 2019 at 6:30 PM Mika Westerberg
> > wrote:
> > >
> > > On Mon, Sep 30, 2019 at 06:05:14PM +0200, Karol Herbst wrote:
> > > > still happens with your patch
From: David Francis
If there is limited link bandwidth on a MST network,
it must be divided fairly between the streams on that network
Implement an algorithm to determine the correct DSC config
for each stream
The algorithm:
This
[ ] ( )
represents the range of
From: David Francis
Rework the dm_helpers_write_dsc_enable callback to
handle the MST case.
Use the cached dsc_aux field.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
---
.../amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 19 ++-
1 file changed, 18 insertions(+), 1
From: David Francis
Add drm_dp_mst_dsc_aux_for_port. To enable DSC, the DSC_ENABLED
register might have to be written on the leaf port's DPCD,
its parent's DPCD, or the MST manager's DPCD. This function
finds the correct aux for the job.
As part of this, add drm_dp_mst_is_virtual_dpcd. Virtual
From: Mikita Lipski
Since for DSC MST connector's PBN is claculated differently
due to compression, we have to recalculate both PBN and
VCPI slots for that connector.
This patch proposes to use similair logic as in
dm_encoder_helper_atomic_chek, but since we do not know which
connectors will
From: David Francis
Whenever a connector on an MST network is attached, detached, or
undergoes a modeset, the DSC configs for each stream on that
topology will be recalculated. This can change their required
bandwidth, requiring a full reprogramming, as though a modeset
was performed, even if
From: David Francis
With DSC, bpp can be fractional in multiples of 1/16.
Change drm_dp_calc_pbn_mode to reflect this, adding a new
parameter bool dsc. When this parameter is true, treat the
bpp parameter as having units not of bits per pixel, but
1/16 of a bit per pixel
v2: Don't add separate
From: David Francis
We were using drm helpers to convert a timing into its
bandwidth, its bandwidth into pbn, and its pbn into timeslots
These helpers
-Did not take DSC timings into account
-Used the link rate and lane count of the link's aux device,
which are not the same as the link's current
From: David Francis
For DSC MST, sometimes monitors would break out
in full-screen static. The issue traced back to the
PPS generation code, where these variables were being used
uninitialized and were picking up garbage.
memset to 0 to avoid this
Reviewed-by: Nicholas Kazlauskas
From: Mikita Lipski
This set of patches is a continuation of DSC enablement
patches for AMDGPU. This set enables DSC on MST. It also
contains implementation of both encoder and connector
atomic check routines.
First 12 patches have been introduced in multiple
iterations to the mailing list
From: David Francis
During MST mode enumeration, if a new dc_sink is created,
populate it with dsc caps as appropriate.
Use drm_dp_mst_dsc_aux_for_port to get the raw caps,
then parse them onto dc_sink with dc_dsc_parse_dsc_dpcd.
Reviewed-by: Wenjing Liu
Signed-off-by: David Francis
---
From: David Francis
As of DP1.4, ENUM_PATH_RESOURCES returns a bit indicating
if FEC can be supported up to that point in the MST network.
The bit is the first byte of the ENUM_PATH_RESOURCES ack reply,
bottom-most bit (refer to section 2.11.9.4 of DP standard,
v1.4)
That value is needed for
From: Mikita Lipski
- Adding encoder atomic check to find vcpi slots for a connector
- Using DRM helper functions to calculate PBN
- Adding connector atomic check to release vcpi slots if connector
loses CRTC
- Calculate PBN and VCPI slots only once during atomic
check and store them on amdgpu
From: David Francis
This field on drm_dp_mst_branch was never filled
It is initialized to zero when the port is kzallocced.
When a port is added to the list, increment num_ports,
and when a port is removed from the list, decrement num_ports.
v2: remember to decrement on port removal
v3: don't
From: Mikita Lipski
Synaptics DP1.4 hubs (BRANCH_ID 0x90CC24) do not
support virtual DPCD registers, but do support DSC.
The DSC caps can be read from the physical aux,
like in SST DSC. These hubs have many different
DEVICE_IDs. Add a new quirk to detect this case.
Reviewed-by: Wenjing Liu
From: David Francis
Instead of having drm_dp_dpcd_read/write and
drm_dp_mst_dpcd_read/write as entry points into the
aux code, have drm_dp_dpcd_read/write handle both.
This means that DRM drivers can make MST DPCD read/writes.
v2: Fix spacing
v3: Dump dpcd access on MST read/writes
Resending in plain text mode
I have been looking into adding Linux support for electronic privacy
screens which is a feature on some new laptops which is built into the
display and allows users to turn it on instead of needing to use a
physical privacy filter. In discussions with my colleagues
Hi,
On 22/9/19 19:59, Brian Masney wrote:
> According to the downstream Android sources, the anx7808 variants use
> address 0x78 for TX_P0 and the anx781x variants use address 0x70. Since
> the datasheets aren't available for these devices, and we only have the
> downstream kernel sources to look
https://bugs.freedesktop.org/show_bug.cgi?id=111877
--- Comment #3 from Dimitar Atanasov ---
yes this helps. clinfo is working now without crash and also darktable will
find all gpu-s
--
You are receiving this mail because:
You are the assignee for the
On Mon, Sep 30, 2019 at 8:57 AM Ayan Halder wrote:
>
> On Mon, Sep 30, 2019 at 09:51:35AM +, Brian Starkey wrote:
> > Hi,
> >
> > On Tue, Sep 17, 2019 at 07:36:45PM +0200, Daniel Vetter wrote:
> > > On Tue, Sep 17, 2019 at 6:15 PM Neil Armstrong
> > > wrote:
> > > >
> > > > Hi,
> > > >
> >
On Tue, Oct 01, 2019 at 09:00:03AM -0500, Rob Herring wrote:
> On Wed, Sep 18, 2019 at 07:31:35PM +0200, Krzysztof Kozlowski wrote:
> > Convert generic mmio-sram bindings to DT schema format using
> > json-schema.
>
> I've been slow getting to this because I started on the same thing...
>
> >
>
https://bugs.freedesktop.org/show_bug.cgi?id=111860
--- Comment #7 from Dimitar Atanasov ---
Created attachment 145605
--> https://bugs.freedesktop.org/attachment.cgi?id=145605=edit
dmesg_resume
--
You are receiving this mail because:
You are the assignee for the
Kiran
On 9/30/19 1:39 AM, Kiran Gunda wrote:
Restructure the driver to add the support for new WLED
peripherals.
Signed-off-by: Kiran Gunda
Acked-by: Daniel Thompson
---
drivers/video/backlight/qcom-wled.c | 395 ++--
1 file changed, 245 insertions(+), 150
Kiran
On 9/30/19 1:39 AM, Kiran Gunda wrote:
Update the bindings with the new properties used for
PMI8998.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
Reviewed-by: Rob Herring
Acked-by: Daniel Thompson
---
.../bindings/leds/backlight/qcom-wled.txt | 76
https://bugs.freedesktop.org/show_bug.cgi?id=111860
--- Comment #6 from Dimitar Atanasov ---
It was working with 5.1.x but since 5.2.x it is not
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=111877
--- Comment #2 from Alex Deucher ---
Does appending amdgpu.runpm=0 to the kernel command line in grub help?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=111860
--- Comment #5 from Dimitar Atanasov ---
Created attachment 145604
--> https://bugs.freedesktop.org/attachment.cgi?id=145604=edit
dmesg_full
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111877
--- Comment #1 from Dimitar Atanasov ---
CPU 8706G Precision 5530 2-in-1 Ubuntu 18.04.3 kernel 5.3.1
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
https://bugs.freedesktop.org/show_bug.cgi?id=111877
Bug ID: 111877
Summary: AMDKFD crash with VegaM
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: not set
Priority:
Kiran
On 9/30/19 1:39 AM, Kiran Gunda wrote:
Restructure the qcom-wled bindings for the better readability.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
Reviewed-by: Rob Herring
Acked-by: Daniel Thompson
Acked-by: Pavel Machek
---
.../bindings/leds/backlight/qcom-wled.txt
On Tuesday, 2019-10-01 17:06:14 +0300, Jani Nikula wrote:
> Add helper to check if a drm debug category is enabled. Convert drm core
> to use it. No functional changes.
>
> v2: Move unlikely() to drm_debug_enabled() (Eric)
>
> v3: Keep unlikely() when combined with other conditions (Eric)
>
>
Kiran
On 9/30/19 1:39 AM, Kiran Gunda wrote:
pm8941-wled.c driver is supporting the WLED peripheral
on pm8941. Rename it to qcom-wled.c so that it can support
WLED on multiple PMICs.
Signed-off-by: Kiran Gunda
Reviewed-by: Bjorn Andersson
Acked-by: Rob Herring
Acked-by: Daniel Thompson
https://bugs.freedesktop.org/show_bug.cgi?id=111860
--- Comment #4 from Alex Deucher ---
Is this a regression? Did it work on a previous kernel? Please attach your
full dmesg output from boot.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111860
--- Comment #3 from Dimitar Atanasov ---
No it will not work at all. DRI_PRIME is not functioning also
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
On Mon, Sep 30, 2019 at 07:28:02PM -0300, Ezequiel Garcia wrote:
> Some platforms are not able to maintain the color transformation
> state after a system suspend/resume cycle.
>
> Set the colog_mgmt_changed flag so that CMM on the CRTCs in
> the suspend state are reapplied after system resume.
>
On Tue, Oct 01, 2019 at 12:26:52PM +0300, Jani Nikula wrote:
> On Mon, 30 Sep 2019, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add a helper to translate a rectangle to an absolute position.
> >
> > Signed-off-by: Ville Syrjälä
>
> The series is
>
> Reviewed-by: Jani Nikula
>
Hi Ezequiel,
On Mon, Sep 30, 2019 at 07:28:02PM -0300, Ezequiel Garcia wrote:
> Some platforms are not able to maintain the color transformation
> state after a system suspend/resume cycle.
>
> Set the colog_mgmt_changed flag so that CMM on the CRTCs in
CMM is the name of the Renesas unit for
https://bugs.freedesktop.org/show_bug.cgi?id=111846
--- Comment #1 from Alex Deucher ---
Please attach your xorg log (if using X) and your dmesg output.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
On Tue, Oct 01, 2019 at 02:21:40PM +, Mihail Atanassov wrote:
> When initially turning a crtc on, drm_reset_vblank_timestamp will
> set the vblank timestamp to 0 for any driver that doesn't provide
> a ->get_vblank_timestamp() hook.
>
> Unfortunately, the FLIP_COMPLETE event depends on that
https://bugs.freedesktop.org/show_bug.cgi?id=111860
--- Comment #2 from Alex Deucher ---
That's just a warning. Does the driver still work properly?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=111876
--- Comment #4 from Christopher Jordan ---
I forgot to mention - when using DP, after that EDID error, my screen displays
a 640x480 tty. I can start X with it, but xrandr shows no other resolutions to
use (probably because the KMS has no EDID
On Tue, Oct 01, 2019 at 02:58:31PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> We no longer use any symbols from of_gpio.h. Remove this include.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/gpio_backlight.c | 1 -
When initially turning a crtc on, drm_reset_vblank_timestamp will
set the vblank timestamp to 0 for any driver that doesn't provide
a ->get_vblank_timestamp() hook.
Unfortunately, the FLIP_COMPLETE event depends on that timestamp,
and the only way to regenerate a valid one is to have vblank
https://bugs.freedesktop.org/show_bug.cgi?id=111876
--- Comment #3 from Christopher Jordan ---
Created attachment 145601
--> https://bugs.freedesktop.org/attachment.cgi?id=145601=edit
pacman -Q output
--
You are receiving this mail because:
You are the assignee for the
1 - 100 of 162 matches
Mail list logo
