https://bugzilla.kernel.org/show_bug.cgi?id=201139
--- Comment #7 from Aleksandr Mezin (mezin.alexan...@gmail.com) ---
Created attachment 279403
--> https://bugzilla.kernel.org/attachment.cgi?id=279403=edit
Kernel log
Encountered the same issue (monitor turned on, but shows black screen only)
https://bugzilla.kernel.org/show_bug.cgi?id=201015
Aleksandr Mezin (mezin.alexan...@gmail.com) changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=108330
--- Comment #5 from aceman ---
Good idea:)
I did that, but it seems to not help in any way.
How do I check if the option is picked up?
Why is drirc now called 00-mesa-defaults.conf ? Where should it be put in /etc
?
--
You are receiving this
Eric Anholt writes:
> [ Unknown signature status ]
> zhoucm1 writes:
>
>> On 2018年11月09日 00:52, Christian König wrote:
>>> Am 08.11.18 um 17:07 schrieb Koenig, Christian:
Am 08.11.18 um 17:04 schrieb Eric Anholt:
> Daniel suggested I submit this, since we're still seeing regressions
zhoucm1 writes:
> On 2018年11月09日 00:52, Christian König wrote:
>> Am 08.11.18 um 17:07 schrieb Koenig, Christian:
>>> Am 08.11.18 um 17:04 schrieb Eric Anholt:
Daniel suggested I submit this, since we're still seeing regressions
from it. This is a revert to before 48197bc564c7 ("drm:
https://bugs.freedesktop.org/show_bug.cgi?id=108625
--- Comment #14 from Alex Deucher ---
(In reply to Alex Deucher from comment #13)
> Does returning false in drm_arch_can_wc_memory() for ARM fix the issue?
This has enabled a working driver for others on ARM.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=108625
--- Comment #13 from Alex Deucher ---
Does returning false in drm_arch_can_wc_memory() for ARM fix the issue?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=108330
--- Comment #4 from Alex Deucher ---
(In reply to aceman from comment #3)
> Could we get a patch like
> https://lists.freedesktop.org/archives/mesa-dev/2018-November/208785.html so
> that I can try to turn off the L3 cache thread pinning for
On Fri, Nov 09, 2018 at 07:35:33PM +0530, Mamta Shukla wrote:
> On Wed, Nov 7, 2018 at 12:25 AM Sean Paul wrote:
> >
> > On Sat, Oct 20, 2018 at 11:33:54PM +0530, Mamta Shukla wrote:
> > > Use DRM_DEV_ERROR/DEBUG instead of DPU_ERROR/DEBUG to generate
> > > drm-formatted specific log messages in
Error message was invalid too, negative values aren't the number of
devices, they're errno error codes.
Signed-off-by: Eric Engestrom
---
This fixes the Gitlab CI; goes from:
https://gitlab.freedesktop.org/mesa/drm/-/jobs/42061
to:
https://gitlab.freedesktop.org/eric/libdrm/-/jobs/42099
---
https://bugs.freedesktop.org/show_bug.cgi?id=108330
--- Comment #3 from aceman ---
Could we get a patch like
https://lists.freedesktop.org/archives/mesa-dev/2018-November/208785.html so
that I can try to turn off the L3 cache thread pinning for this game?
--
You are receiving this mail
Pushed with small changes to drm-misc-fixes: Renamed patch and added stable Cc
Thanks!
On Fri, 2018-11-09 at 11:00 +0200, Stanislav Lisovskiy wrote:
> Unfortunately drm_dp_get_mst_branch_device which is called from both
> drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely
> on
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #11 from quirin.blae...@freenet.de ---
Created attachment 279393
--> https://bugzilla.kernel.org/attachment.cgi?id=279393=edit
config+dmesg for patched 4.19.1
Bug is still alive.
A more precise description:
System boots and shows
Christian König writes:
> Also use the irq work for dma_fence_array_enable_signaling to make sure
> that the spinlock for the dma-fence-array is always unrelated to all
> other spinlocks.
>
> This fixes a lockdep warning if a dma-fence-array is embedded into
> another dma-fence-array.
>
>
Hey Gerd,
On 2018-11-09 11:13, Gerd Hoffmann wrote:
On Mon, Nov 05, 2018 at 05:25:05PM +, Emil Velikov wrote:
On Mon, 5 Nov 2018 at 11:42, Robert Foss wrote:
When the execbuf call receives an in-fence it will get the dma_fence
related to that fence fd and wait on it before submitting
https://bugs.freedesktop.org/show_bug.cgi?id=105664
--- Comment #2 from Alex Deucher ---
A number of boards had stability issues at the default clocks. Please attach
your dmesg output.
--
You are receiving this mail because:
You are the assignee for the
Hans de Goede writes:
> Hi,
>
> On 18-10-18 21:31, Gabriel Krisman Bertazi wrote:
>> I just got a new GDP Win2 device with an updated firmware, which still
>> requires this quirk to get the rotation right, so add the new firmware
>> date to the quirk matching table.
>>
>> This should go to
On Fri, 9 Nov 2018 11:26:32 +0100
Boris Brezillon wrote:
> For the YUV conversion to work properly, ->x_scaling[1] should never
> be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return
> VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the
> horizontal subsampling
https://bugs.freedesktop.org/show_bug.cgi?id=105664
--- Comment #1 from Yassine Oudjana ---
Created attachment 142420
--> https://bugs.freedesktop.org/attachment.cgi?id=142420=edit
root/drivers/gpu/drm/radeon/si_dpm.c with 1 line modified
blob: 8fb60b3af015804d6d5ee3ef5d6f24ba74e2b1d9
+Eric Anholt to aware this.
在 2018/11/9 22:21, Chunming Zhou 写道:
> Tested-And-Reviewed-by: Chunming Zhou
>
>
> 在 2018/11/9 20:20, Christian König 写道:
>> Also use the irq work for dma_fence_array_enable_signaling to make sure
>> that the spinlock for the dma-fence-array is always unrelated to
Tested-And-Reviewed-by: Chunming Zhou
在 2018/11/9 20:20, Christian König 写道:
> Also use the irq work for dma_fence_array_enable_signaling to make sure
> that the spinlock for the dma-fence-array is always unrelated to all
> other spinlocks.
>
> This fixes a lockdep warning if a dma-fence-array
Also use the irq work for dma_fence_array_enable_signaling to make sure
that the spinlock for the dma-fence-array is always unrelated to all
other spinlocks.
This fixes a lockdep warning if a dma-fence-array is embedded into
another dma-fence-array.
Signed-off-by: Christian König
---
https://bugs.freedesktop.org/show_bug.cgi?id=108680
--- Comment #3 from Martin Peres ---
Another example of this issue. The watchdog just randomly killed the platform
before it was done:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5110/fi-skl-6700k2/igt@drv_selftest@live_execlists.html
--
https://bugs.freedesktop.org/show_bug.cgi?id=108680
--- Comment #2 from Petri Latvala ---
Turns out, fi-skl-6700k2's network interface is just prone to completely
disappearing on suspend. Work is ongoing to make IGT instead check for working
network connectivity after suspending to mitigate
On Fri, Nov 09, 2018 at 10:37:19AM +, Ayan Halder wrote:
> Rotation memory for layers is shared with AFBC decoder block. Thus one needs
> to
> calculate rotation memory requirement in case of AFBC framebuffer. This is
> used later to verify if it can be sufficed by the hardware rotation
Rotation memory for layers is shared with AFBC decoder block. Thus one needs to
calculate rotation memory requirement in case of AFBC framebuffer. This is
used later to verify if it can be sufficed by the hardware rotation memory
availibility.
Fixes: 66da13a ("drm/arm/malidp: Validate rotations
For the YUV conversion to work properly, ->x_scaling[1] should never
be set to VC4_SCALING_NONE, but vc4_get_scaling_mode() might return
VC4_SCALING_NONE if the horizontal scaling ratio exactly matches the
horizontal subsampling factor. Add a test to turn VC4_SCALING_NONE
into VC4_SCALING_PPF when
The HVS spec recommends using PPF when the downscaling ratio is
between 2/3 and 1. Let's modify vc4_get_scaling_mode() to follow this
recommendation.
Signed-off-by: Boris Brezillon
Reviewed-by: Eric Anholt
---
Changes in v2:
- Add Eric's R-b
---
drivers/gpu/drm/vc4/vc4_plane.c | 8
1
On Mon, Nov 05, 2018 at 05:25:05PM +, Emil Velikov wrote:
> On Mon, 5 Nov 2018 at 11:42, Robert Foss wrote:
> >
> > When the execbuf call receives an in-fence it will get the dma_fence
> > related to that fence fd and wait on it before submitting the draw call.
> >
> > On the out-fence side
Commit e6bcca0890b9 ("backlight: pwm_bl: Switch to using "atomic" PWM API")
removed the driver internal enabled tracking in favor of simply checking
the pwm state.
This can lead to issues as all of gpio-, regulator- and pwm-state are used
to determine the initial state and the bootloader or
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
specification.
v2: Edited commit message, removed redundant whitespaces.
v3: Fixed fallthrough logic for the format switch cases.
v4: Yet again fixed fallthrough logic, to reuse code from other case
labels.
v5: Started to
v5: This is YUV444 packed format same as AYUV, but without alpha,
as supported by i915.
v6: Removed unneeded initializer for new XYUV format.
v7: Added is_yuv field initialization according to latest
drm_fourcc format structure initialization changes.
v8: Edited commit message to be
Introduced new XYUV scan-in format for framebuffer and
added support for it to i915(SkyLake+).
Stanislav Lisovskiy (2):
drm: Introduce new DRM_FORMAT_XYUV
drm/i915: Adding YUV444 packed format support for skl+
drivers/gpu/drm/drm_fourcc.c | 1 +
drivers/gpu/drm/i915/i915_reg.h
Unfortunately drm_dp_get_mst_branch_device which is called from both
drm_dp_mst_handle_down_rep and drm_dp_mst_handle_up_rep seem to rely
on that mgr->mst_primary is not NULL, which seem to be wrong as it can be
cleared with simultaneous mode set, if probing fails or in other case.
mgr->lock mutex
On Wed, Nov 07, 2018 at 07:18:35PM +0100, Paul Kocialkowski wrote:
> The series adds support for the BL035-RGB-002 LCD panel and the required
> device-tree bindings for using it on the BananaPi M1.
>
> Only the changes related to the DRM driver and the panel are submitted
> for merge, which does
https://bugs.freedesktop.org/show_bug.cgi?id=108680
--- Comment #1 from Jani Saarinen ---
>From Petri:
"The story for it is that the test suspends a couple of times and then reports
success, and chamelium's atexit handlers attempt to reset the chamelium to a
good default state for other tests,
On 2018-11-06 12:52, Fabrizio Castro wrote:
> While adding SiI9022A support to the iwg23s board, it came
> up that when the HDMI transmitter is in pass through mode the
> device is not compliant with the I2C specification anymore,
> as it requires a far bigger tbuf, due to a delay the HDMI
>
On 11/6/18 5:17 PM, Brendan Higgins wrote:
> On Fri, Nov 2, 2018 at 11:23 AM Shuah Khan wrote:
>>
>> Hi Brendan,
>
>> Framework looks good. I think it would be helpful to include a real test
>
> Great to hear!
>
>> in the patch series to get a feel for how effective it is.
>
> Alright, will
From: Andrzej Hajda
Sent: Wednesday, November 7, 2018 12:40
To: Damian Kos ; David Airlie ; Rob Herring
; Mark Rutland ; Archit Taneja
; Laurent Pinchart ;
Gustavo Padovan ; Maarten Lankhorst
; Sean Paul ; Sandy Huang
; Heiko Stübner ; Quentin Schulz
; Piotr Sroka ;
Commit '88ba95bedb79 ("backlight: pwm_bl: Compute brightness of LED
linearly to human eye")' allows the possibility to compute a default
brightness table when there isn't the brightness-levels property in the
DT. Unfortunately the changes made broke the pwm backlight for the
non-DT boards.
On Tue, Nov 6, 2018 at 10:40 AM Neil Armstrong wrote:
>
> The Amlogic Meson GX SoCs support an Overlay plane behind the primary
> plane for video rendering.
>
> This Overlay plane support various YUV layouts :
> - YUYV
> - NV12 / NV21
> - YUV444 / 422 / 420 / 411 / 410
>
> The scaler supports a
From: Yue Haibing
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/radeon/radeon_object.c: In function 'radeon_bo_unref':
drivers/gpu/drm/radeon/radeon_object.c:317:24: warning:
variable 'rdev' set but not used [-Wunused-but-set-variable]
It not used any more after commit
Fixes gcc '-Wunused-but-set-variable' warning:
drivers/gpu/drm/ttm/ttm_execbuf_util.c: In function
'ttm_eu_fence_buffer_objects':
drivers/gpu/drm/ttm/ttm_execbuf_util.c:190:24: warning:
variable 'driver' set but not used [-Wunused-but-set-variable]
It not used any more after
commit
Support for newer ArcticSand LED drivers is added. The
i2c device id is used to modify some limits and set
some device specific register addresses
Signed-off-by: Brian Dodge
---
drivers/video/backlight/arcxcnn_bl.c | 261 +--
1 file changed, 190 insertions(+), 71
The vendor-prefixes.txt file properly refers to ArcticSand
as arctic but the driver bindings improperly abbreviated the
prefix to arc. This was a mistake in the original patch
Signed-off-by: Brian Dodge
---
.../bindings/leds/backlight/arcxcnn_bl.txt | 20 ++--
1 file
Am 07.11.18 um 21:48 schrieb Sean Paul:
On Wed, Nov 07, 2018 at 09:31:51PM +0100, Daniel Vetter wrote:
On Wed, Nov 7, 2018 at 9:29 PM Sean Paul wrote:
On Wed, Nov 07, 2018 at 09:18:16PM +0100, Daniel Vetter wrote:
On Wed, Nov 07, 2018 at 12:58:56PM +0100, Maarten Lankhorst wrote:
Hey Dave,
From: Przemyslaw Gaj
This patch enables DSC (Digital Stream Compression) on Cadence DisplayPort
controller.
I think that a little bit of an explanation is needed here from our side
before we go into the patch contents.
One might ask, why not just put everything together for mhdp8546 IP and send
Benjamin Herrenschmidt wrote:
> There's a whole pile of power management stuff for ancient laptops that
> never quite made it from radeonfb to the radeon DRM driver... sadly it
> also prevents sleep on old PowerBooks but I haven't had many complaints
> so...
Thanks for the confirmation that
On Thu, 1 Nov 2018 16:27:07 +0100, Jean Delvare wrote:
> Hi David,
>
> The following commit:
>
> commit 7cf321d118a825c1541b43ca45294126fd474efa
> Author: Dave Airlie
> Date: Mon Oct 24 15:37:48 2016 +1000
>
> drm/drivers: add support for using the arch wc mapping API.
>
> is causing a
On Thu, Nov 08, 2018 at 05:52:08PM -0500, Harry Wentland wrote:
> The leadership of freedesktop.org (fd.o) has recently expressed interest
> in having an elected governing body. Given the tight connection between
> fd.o and X.Org and the fact that X.Org has such a governing body it
> seemed
Blitting an image with "negative" offsets is not working since there
is no clipping. It hopefully just crashes. For the bootup logo, there
is protection so that blitting does not happen as the image is drawn
further and further to the right (ROTATE_UR) or further and further
down (ROTATE_CW).
The vendor-prefixes.txt file properly refers to ArcticSand
as arctic but the driver improperly abbreviated the prefix
to arc. This was a mistake in the original patch
Signed-off-by: Brian Dodge
---
drivers/video/backlight/arcxcnn_bl.c | 22 +++---
1 file changed, 11
The vendor-prefix.txt file correctly uses the prefix arctic for ArcticSand.
The ArcticSand driver and the device tree bindings for it incorreclty use
just arc. This mismatch was an error in the original patchset for the
driver and is fixed in the first two patches here.
ArcticSand has been
* Laurent Pinchart [181107 05:30]:
> Hi Tony,
>
> Thank you for the patch.
>
> On Tuesday, 6 November 2018 17:28:02 EET Tony Lindgren wrote:
> > We're missing a call to of_platform_depopulate() on errors for dsi.
> > Looks like dss is already doing this.
> >
> > Signed-off-by: Tony Lindgren
>
Hi Jagan,
On Wed, Nov 7, 2018 at 5:13 AM Jagan Teki wrote:
>
> On Wed, Oct 31, 2018 at 2:46 PM Julian Calaby wrote:
> >
> > Hi Jagan,
> >
> > On Wed, Oct 31, 2018 at 7:58 PM Chen-Yu Tsai wrote:
> > >
> > > On Wed, Oct 31, 2018 at 4:53 PM Andrzej Hajda wrote:
> > > >
> > > > On 26.10.2018
55 matches
Mail list logo
