https://bugs.freedesktop.org/show_bug.cgi?id=110604
Jason changed:
What|Removed |Added
Summary|AMX WX4150 hangs in |AMD WX4150 hangs in
https://bugs.freedesktop.org/show_bug.cgi?id=110604
Bug ID: 110604
Summary: AMX WX4150 hangs in aux_read call for REG_RC_CAP
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
https://bugs.freedesktop.org/show_bug.cgi?id=109524
--- Comment #2 from da...@linuxid10t.com ---
I have had the same problem in Mesa 19.0.0 with the Nouveau driver. It seems
that any card without hardware shaders is failing. This was tested with NV05
and NV11.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=108893
--- Comment #13 from supercoolem...@seznam.cz ---
You are lucky. I have this:
https://imgur.com/a/YTDyAXv
Notice, that this is with vastly limited object rendering distance, which makes
fights rather difficult - I can't even see who is shooting
> On Thu, May 02, 2019 at 11:45:43AM -0700, Brendan Higgins wrote:
> > On Thu, May 2, 2019 at 11:15 AM wrote:
> > >
> > >
> > >
> > > > -Original Message-
> > > > From: Greg KH
> > > >
> > > > On Wed, May 01, 2019 at 04:01:25PM -0700, Brendan Higgins wrote:
> > > > > From: Iurii Zaikin
>
On Thu, Apr 25, 2019 at 12:45:33PM +0200, Maarten Lankhorst wrote:
> Op 26-02-2019 om 17:17 schreef Matt Roper:
> > On Tue, Feb 26, 2019 at 08:26:36AM +0100, Maarten Lankhorst wrote:
> >> Hey,
> >>
> >> Op 21-02-2019 om 01:28 schreef Matt Roper:
> >>> Some display controllers can be programmed to
> On 5/2/19 10:36 PM, Brendan Higgins wrote:
> > On Thu, May 2, 2019 at 6:45 PM Frank Rowand wrote:
> >>
> >> On 5/2/19 4:45 PM, Brendan Higgins wrote:
> >>> On Thu, May 2, 2019 at 2:16 PM Frank Rowand
> >>> wrote:
>
> On 5/2/19 11:07 AM, Brendan Higgins wrote:
> > On Thu, May 2,
https://bugs.freedesktop.org/show_bug.cgi?id=108893
--- Comment #12 from andrew.m.mcma...@gmail.com ---
(In reply to Michel Dänzer from comment #8)
> The video shows very low frame-rate and GPU load in the menu, but high CPU
> load. Maybe there's a CPU bottleneck which affects the reporter even
https://bugs.freedesktop.org/show_bug.cgi?id=110575
Danylo changed:
What|Removed |Added
CC||danylo.pilia...@gmail.com
--- Comment #2 from
On 5/2/2019 3:48 PM, Kenny Ho wrote:
> On 5/2/2019 1:34 AM, Leon Romanovsky wrote:
>> Count us (Mellanox) too, our RDMA devices are exposing special and
>> limited in size device memory to the users and we would like to provide
>> an option to use cgroup to control its exposure.
Hi Leon, great
On Fri, May 3, 2019 at 10:31 AM Robin Murphy wrote:
>
> Hi,
>
> These are a few trivial fixes and cleanups from playing with the
> panfrost kernel driver on an Arm Juno board. Not that anyone has ever
> cared much about the built-in GPU on Juno, but it's at least a somewhat
> interesting platform
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #43 from Talha Khan ---
I updated my Fedora KDE spin system from Fedora 29 to Fedora 30 and had the
same experience as Jay's.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=110443
--- Comment #13 from Julien Isorce ---
Thx!
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://bugs.freedesktop.org/show_bug.cgi?id=110443
--- Comment #12 from Viktor Jägersküpper ---
I tested the commit in the merge request together with the r600-related change
which has already been committed to the master branch, VLC doesn't crash any
more.
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=108750
--- Comment #2 from Henri Verbeet ---
(In reply to Timothy Arceri from comment #1)
> wined3d DX11 support is known to be very buggy. Just use dxvk.
With DXVK effectively being a Valve project I can understand your personal
preference, but I
Hi Tomi,
On Fri, May 03, 2019 at 04:17:41PM +0300, Tomi Valkeinen wrote:
> On 03/05/2019 15:48, Laurent Pinchart wrote:
> > On Fri, May 03, 2019 at 02:43:51PM +0300, Tomi Valkeinen wrote:
> >> On 23/04/2019 17:56, Laurent Pinchart wrote:
> >>
> During initial driver development I had one eDP
https://bugs.freedesktop.org/show_bug.cgi?id=108893
--- Comment #11 from supercoolem...@seznam.cz ---
Ok, so I started the game and attached perf to it by PID, waited a minute and
stopped perf with CTRL+C. Here it is:
perf report --stdio
45.80% Gothic2.exe wined3d.dll.so [.]
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #53 from Marco (rodomar...@protonmail.com) ---
For the first time it has triggered while I was using the system after some
time; and as imagined the system disappear from the network, so no dmesg
available. I'll try without DC enabled
On Fri, May 3, 2019 at 9:38 AM Robert Foss wrote:
>
> virtio_gpu_fence_emit() always returns 0, since it
> has no error paths.
>
> Consequently no calls for virtio_gpu_fence_emit()
> use the return value, and it can be removed.
>
> Signed-off-by: Robert Foss
> Suggested-by: Emil Velikov
virtio_gpu_fence_emit() always returns 0, since it
has no error paths.
Consequently no calls for virtio_gpu_fence_emit()
use the return value, and it can be removed.
Signed-off-by: Robert Foss
Suggested-by: Emil Velikov
---
This patch was suggested in this email thread:
[PATCH] drm/virtio:
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #28 from Christian Zigotzky ---
Hi All,
Allan successfully tested the second test kernel today. He wrote:
Christian
DRM2 BINGO, boots to Firepro!
ace
--
This step has been marked as good.
git bisect good
Output:
https://bugs.freedesktop.org/show_bug.cgi?id=108893
--- Comment #10 from Michel Dänzer ---
(In reply to supercoolemail from comment #9)
> Output of perf (if you want anything more, e.g. full perf.data or something,
> I'll deliver):
AFAIK perf.data generally won't be useful outside of your
The pull request you sent on Fri, 3 May 2019 11:01:07 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-fixes-2019-05-03
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a4ccb5f9dc6c4fb4d4c0a9d73a911986f20ec88a
Thank you!
--
Deet-doot-dot, I am a bot.
https://bugs.freedesktop.org/show_bug.cgi?id=108893
--- Comment #9 from supercoolem...@seznam.cz ---
I am on 19.0.3.
The game used to run quite well from what I remeber and I could navigate the
menu. Now it's horrible and when I want to change something in menu, I need
LIBGL_ALWAYS_SOFTWARE=1,
Hi Matt,
and many thanks for the patch.
Tested successfully by Yannick on STM32MP1 boards :-)
Tested-by: Yannick Fertré
Reviewed-by: Philippe Cornu
Thank you,
Philippe :-)
On 4/30/19 10:17 AM, Matt Redfearn wrote:
> The Synopsys MIPI DSI IP contains a video test pattern generator which
> is
Re-reading the feature registers for the sake of displaying the raw
values seems pointless, and in fact showing the copies that we've
already read and stored is arguably more useful in terms of giving
exposure to any potential bugs in that part of the process.
Signed-off-by: Robin Murphy
---
Probe deferral is far from "fatal".
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index
Since we now have bindings for Mali Midgard GPUs, let's use them to
describe Juno's GPU subsystem, if only because we can. Juno sports a
Mali-T624 integrated behind an MMU-400 (as a gesture towards
virtualisation), in their own dedicated power domain with DVFS
controlled by the SCP.
Make sure to disable runtime PM again if probe fails after we've enabled
it. Otherwise, any subsequent attempt to re-probe starts triggering
"Unbalanced pm_runtime_enable!" assertions from the driver core.
Signed-off-by: Robin Murphy
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 1 +
1 file
The DMA masks need to be set correctly before any DMA API activity kicks
off, and the current point in panfrost_probe() is way too late in that
regard. since panfrost_mmu_init() has already set up a live address
space and DMA-mapped MMU pagetables. We can't set masks until we've
queried the
Hi,
These are a few trivial fixes and cleanups from playing with the
panfrost kernel driver on an Arm Juno board. Not that anyone has ever
cared much about the built-in GPU on Juno, but it's at least a somewhat
interesting platform from the kernel driver perspective for having
I/O coherency, RAM
https://bugs.freedesktop.org/show_bug.cgi?id=109835
--- Comment #3 from rtent...@yandex.ru ---
I've lied, i have 865GV. With this motherboard:
https://www.asrock.com/mb/Intel/P4i65GV/index.asp
Also, LIBGL_ALWAYS_SOFTWARE is a workaround for the problem. But it works very
slow.
--
You are
Hi Chia-I,
On Mon, 29 Apr 2019 at 23:08, Chia-I Wu wrote:
>
> This is motivated by having meaningful ftrace events, but it also
> fixes use cases where dma_fence_is_later is called, such as in
> sync_file_merge.
>
> In other drivers, fence creation and cmdbuf submission normally
> happen
On 03.05.19 16:31, Emil Velikov wrote:
On Mon, 29 Apr 2019 at 23:10, Chia-I Wu wrote:
It was changed to GFP_ATOMIC in commit ec2f0577c (add & use
virtio_gpu_queue_fenced_ctrl_buffer) because the allocation happened
with a spinlock held. That was no longer true after commit
9fdd90c0f (add
On Fri, May 03, 2019 at 03:25:25PM +0300, Dan Carpenter wrote:
> We need to check whether drm_atomic_get_crtc_state() returns an error
> pointer before dereferencing "crtc_st".
>
> Fixes: 7d31b9e7a550 ("drm/komeda: Add komeda_plane/plane_helper_funcs")
> Signed-off-by: Dan Carpenter
Acked-by:
On 5/1/19 5:01 PM, Brendan Higgins wrote:
Add myself as maintainer of KUnit, the Linux kernel's unit testing
framework.
Signed-off-by: Brendan Higgins
---
MAINTAINERS | 10 ++
1 file changed, 10 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 5c38f21aee787..c78ae95c56b80
On Mon, 29 Apr 2019 at 23:10, Chia-I Wu wrote:
>
> It was changed to GFP_ATOMIC in commit ec2f0577c (add & use
> virtio_gpu_queue_fenced_ctrl_buffer) because the allocation happened
> with a spinlock held. That was no longer true after commit
> 9fdd90c0f (add virtio_gpu_alloc_fence()).
>
>
On 5/1/19 5:01 PM, Brendan Higgins wrote:
From: Avinash Kondareddy
Tests how tests interact with test managed resources in their lifetime.
Signed-off-by: Avinash Kondareddy
Signed-off-by: Brendan Higgins
---
I think this change log could use more details. It is vague on what it
does.
On Fri, May 3, 2019 at 2:34 PM Sean Paul wrote:
>
> On Fri, May 03, 2019 at 09:51:30AM +0200, Daniel Vetter wrote:
> > On Thu, May 02, 2019 at 03:49:43PM -0400, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > This patch adds atomic_enable and atomic_disable callbacks to the
> > > encoder
On Fri, May 3, 2019 at 2:47 PM Sean Paul wrote:
> On Fri, May 03, 2019 at 10:18:51AM +0200, Daniel Vetter wrote:
> > On Thu, May 02, 2019 at 03:49:44PM -0400, Sean Paul wrote:
> > > From: Sean Paul
> > >
> > > This patch adds a helper to tease out the currently connected crtc for
> > > an
On Thu, May 02, 2019 at 02:01:45PM +0200, Lucas Stach wrote:
> Hi Daniel,
>
> Am Donnerstag, den 02.05.2019, 11:33 +0100 schrieb Daniel Thompson:
> > On 29/04/2019 16:29, Lucas Stach wrote:
> > > This way the backlight can be referenced through its device node and
> > > enabling/disabling can be
Am 03.05.19 um 14:27 schrieb Thomas Zimmermann:
> cc: nor...@tronnes.org
Actually cc him
> Am 03.05.19 um 14:07 schrieb Koenig, Christian:
>> Am 03.05.19 um 14:01 schrieb Daniel Vetter:
>>> [CAUTION: External Email]
>>>
>>> On Fri, May 3, 2019 at 12:15 PM Thomas Zimmermann
>>> wrote:
Hi
On 03/05/2019 15:48, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Fri, May 03, 2019 at 02:43:51PM +0300, Tomi Valkeinen wrote:
>> On 23/04/2019 17:56, Laurent Pinchart wrote:
>>
During initial driver development I had one eDP display that reports 0 in
Bit 0
(ANSI 8B/10B) of DPCD reg
On 03/05/2019 15:55, Laurent Pinchart wrote:
- if (state) {
- ret = tc_set_video_mode(tc, tc->mode);
- if (ret)
- goto err;
+ ret = tc_set_video_mode(tc, tc->mode);
+ if (ret)
+ goto err;
>>>
>>> Let's return
Hi Tomi,
On Fri, May 03, 2019 at 11:10:54AM +0300, Tomi Valkeinen wrote:
> On 21/04/2019 01:14, Laurent Pinchart wrote:
> > On Tue, Mar 26, 2019 at 12:31:40PM +0200, Tomi Valkeinen wrote:
> >> tc_main_link_enable() checks if videomode has been set, and fails if
> >> there's no videomode. As
Hi Tomi,
On Fri, May 03, 2019 at 12:20:49PM +0300, Tomi Valkeinen wrote:
> On 21/04/2019 00:29, Laurent Pinchart wrote:
> > On Tue, Mar 26, 2019 at 12:31:32PM +0200, Tomi Valkeinen wrote:
> >> It is nicer to have enable/disable functions instead of set(bool enable)
> >> style function.
> >
> >
Hi Tomi,
On Fri, May 03, 2019 at 02:43:51PM +0300, Tomi Valkeinen wrote:
> On 23/04/2019 17:56, Laurent Pinchart wrote:
>
> >> During initial driver development I had one eDP display that reports 0 in
> >> Bit 0
> >> (ANSI 8B/10B) of DPCD reg 0x0006 (MAIN_LINK_CHANNEL_CODING).
> >> Also it does
https://bugs.freedesktop.org/show_bug.cgi?id=110600
Bug ID: 110600
Summary: [IGT runner] be more consistent with checks on
display/outputs
Product: DRI
Version: DRI git
Hardware: Other
OS: All
On Fri, May 03, 2019 at 10:18:51AM +0200, Daniel Vetter wrote:
> On Thu, May 02, 2019 at 03:49:44PM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch adds a helper to tease out the currently connected crtc for
> > an encoder, along with its state. This follows the same pattern as
https://bugs.freedesktop.org/show_bug.cgi?id=110599
Bug ID: 110599
Summary: [IGT runner] Per-test external watchdog
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Add DT property for defining the pin used for HPD.
Signed-off-by: Tomi Valkeinen
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Reviewed-by: Rob Herring
---
.../devicetree/bindings/display/bridge/toshiba,tc358767.txt | 1 +
1 file changed, 1 insertion(+)
diff --git
In tc_bridge_mode_set callback, we store the pointer to the given
drm_display_mode, and use the mode later. Storing a pointer in such a
way looks very suspicious to me, and I have observed odd issues where
the timings were apparently (at least mostly) zero.
Do a copy of the drm_display_mode
On Fri, May 03, 2019 at 09:51:30AM +0200, Daniel Vetter wrote:
> On Thu, May 02, 2019 at 03:49:43PM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > This patch adds atomic_enable and atomic_disable callbacks to the
> > encoder helpers. This will allow encoders to make informed decisions in
>
For some reason the driver has a msleep(100) after writing to
DP_PHY_CTRL. Toshiba's documentation doesn't suggest any delay is
needed, and I have not seen any issues with the sleep removed.
Drop it, as msleep(100) is a rather big one.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
We have tc_connector_mode_valid() to filter out videomdoes that the
tc358767 cannot support. As it is a bridge limitation, change the code
to use drm_bridge_funcs's mode_valid instead.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
Add GPIO and interrupt related registers for HPD work. Mark INTSTS_G and
GPIOI as volatile.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
The current link training code does unnecessary retry-loops, and does
extra writes to the registers. It is easier to follow the flow and
ensure it's similar to Toshiba's documentation if we deal with LT inside
tc_main_link_enable() function.
This patch adds tc_wait_link_training() which handles
Am 30.04.19 um 16:16 schrieb Daniel Vetter:
[SNIP]
/**
- * amdgpu_gem_map_attach - _buf_ops.attach implementation
- * @dma_buf: Shared DMA buffer
+ * amdgpu_gem_pin_dma_buf - _buf_ops.pin_dma_buf implementation
+ *
+ * @dma_buf: DMA-buf to pin in memory
+ *
+ * Pin the BO which is backing the
Add support for interrupt and hotplug handling. Both are optional.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358767.c | 166 ++
1 file changed, 148 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
At the end of the link training, two steps have to be taken: 1)
tc358767's LT mode is disabled by a write to DP0_SRCCTRL, and 2) Remove
LT flag in DPCD 0x102.
Toshiba's documentation tells to first write the DPCD, then modify
DP0_SRCCTRL. In my testing this often causes issues, and the link
https://bugs.freedesktop.org/show_bug.cgi?id=110214
--- Comment #87 from komqin...@zoho.eu ---
I have the same bug with xterm and shift+paging.
Another similar bug.
xfce4-terminal leaves a large black area at the bottom when it renders 'dmesg'
or 'cat /etc/passwd'.
AMD Ryzen 3 2200G.
Arch
It is nicer to have enable/disable functions instead of set(bool enable)
style function.
Split tc_main_link_stream into tc_stream_enable and tc_stream_disable.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358767.c | 81 +--
1 file changed, 45
Currently the code writes 0 to DP0CTL in tc_stream_disable(), which
disables the whole DP link instead of just the video stream. We always
disable the link and the stream together from tc_bridge_disable(), so
this doesn't cause any issues.
Nevertheless, fix this by only clearing VID_EN in
Currently we have tc_main_link_setup(), which configures and enabled the
link, but we have no counter-part for disabling the link.
Add tc_main_link_disable, and rename tc_main_link_setup to
tc_main_link_enable.
Signed-off-by: Tomi Valkeinen
---
drivers/gpu/drm/bridge/tc358767.c | 27
tc_main_link_enable() checks if videomode has been set, and fails if
there's no videomode. As tc_main_link_enable() no longer depends on the
videomode, we can drop the check.
Also, while tc_stream_enable() does depend on the videomode, we can
expect that a mode has been set before
drm_connector_helper_funcs.best_encoder is only needed when the
connector can have more than one encoder, and that is never the case
here.
So remove tc_connector_best_encoder.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
Link training will sometimes fail if the DP link is enabled when
tc_main_link_enable() is called. The driver makes sure the DP link is
disabled when the DP output is disabled, and we never enable the DP
without first disabling it, so this should never happen.
However, as the HW behavior seems to
We set up the PXL PLL inside tc_main_link_setup. This is unnecessary,
and makes tc_main_link_setup depend on the video-mode, which should not
be the case. As PXL PLL is used only for the video stream (and only when
using the HW test pattern), let's move the PXL PLL setup into
tc_stream_enable.
The driver has a loop after ending link training, where it reads the
DPCD link status and prints an error if that status is not ok.
The loop is unnecessary, as far as I can understand from DP specs, so
let's remove it. We can also print the more specific errors to help
debugging.
Signed-off-by:
Minor cleanups:
- Use bool for boolean fields
- Use DP_MAX_DOWNSPREAD_0_5 instead of BIT(0)
- debug print down-spread and scrambler status
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/tc358767.c | 13 -
1 file
The driver currently sets the video stream registers in
tc_main_link_setup. One should be able to establish the DP link without
any video stream, so a more logical place is to configure the stream in
the tc_main_link_stream. So move them there.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej
The driver sets up AUX link at probe time, but, for some reason, also
sets the main link's number of lanes using tc->link.base.num_lanes. This
is not needed nor correct, as the number of lanes has not been decided
yet. The number of lanes will be set later during main link setup.
Modify
tc_aux_get_status() does not report AUX_TIMEOUT correctly, as it only
checks the AUX_TIMEOUT if aux is still busy. Fix this by always checking
for AUX_TIMEOUT.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 11 +++
1 file changed, 7
We need to reset DPCD voltage-swing & pre-emphasis before starting the
link training, as otherwise tc358767 will use the previous values as
minimums.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
---
drivers/gpu/drm/bridge/tc358767.c | 7 +++
1 file changed, 7 insertions(+)
Hi,
tc358767 bridge was originally implemented for eDP use with an embedded
panel. I've been working to add DP and HPD support, and this series is
the result. I did have a lot of issues with link training, but with
these, it's been working reliably with my devices.
Changes in v2
* Drop
DP always uses ANSI 8B10B encoding. Some monitors (old?) may not have
the ANSI 8B10B bit set in DPCD, even if it should always be set.
The tc358767 driver currently respects that flag, and turns the encoding
off if the monitor does not have the bit set, which then results in the
monitor not
swing and preemp fields are not used. Remove them.
Signed-off-by: Tomi Valkeinen
Reviewed-by: Andrzej Hajda
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/bridge/tc358767.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/bridge/tc358767.c
https://bugs.freedesktop.org/show_bug.cgi?id=109124
Sylvain BERTRAND changed:
What|Removed |Added
Resolution|NOTABUG |NOTOURBUG
--- Comment #5 from
cc: nor...@tronnes.org
Am 03.05.19 um 14:07 schrieb Koenig, Christian:
> Am 03.05.19 um 14:01 schrieb Daniel Vetter:
>> [CAUTION: External Email]
>>
>> On Fri, May 3, 2019 at 12:15 PM Thomas Zimmermann
>> wrote:
>>> Hi Christian,
>>>
>>> would you review the whole patch set? Daniel mentioned
We need to check whether drm_atomic_get_crtc_state() returns an error
pointer before dereferencing "crtc_st".
Fixes: 7d31b9e7a550 ("drm/komeda: Add komeda_plane/plane_helper_funcs")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/arm/display/komeda/komeda_plane.c | 2 +-
1 file changed, 1
On Fri, May 03, 2019 at 10:29:48AM +0100, Liviu Dudau wrote:
> On Fri, May 03, 2019 at 11:15:23AM +0200, Daniel Vetter wrote:
> > On Fri, May 3, 2019 at 11:11 AM Liviu Dudau wrote:
> > >
> > > On Fri, May 03, 2019 at 09:54:35AM +1000, Dave Airlie wrote:
> > > > On Thu, 2 May 2019 at 20:45, Liviu
Am 03.05.19 um 14:09 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Fri, May 03, 2019 at 02:05:47PM +0200, Christian König wrote:
>> Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin:
>>> On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
Add a structure for
On Fri, May 03, 2019 at 02:05:47PM +0200, Christian König wrote:
> Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin:
> > On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
> > > Add a structure for the parameters of dma_buf_attach, this makes it much
> > > easier
> > > to
Am 03.05.19 um 14:01 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Fri, May 3, 2019 at 12:15 PM Thomas Zimmermann wrote:
>> Hi Christian,
>>
>> would you review the whole patch set? Daniel mentioned that he'd prefer
>> to leave the review to memory-mgmt developers.
> I think Noralf
Am 30.04.19 um 19:31 schrieb Russell King - ARM Linux admin:
On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
Add a structure for the parameters of dma_buf_attach, this makes it much easier
to add new parameters later on.
I don't understand this reasoning. What are the "new
On Fri, May 3, 2019 at 12:15 PM Thomas Zimmermann wrote:
>
> Hi Christian,
>
> would you review the whole patch set? Daniel mentioned that he'd prefer
> to leave the review to memory-mgmt developers.
I think Noralf Tronnes or Gerd Hoffmann would also make good reviewers
for this, fairly close to
On Sat, Apr 13, 2019 at 10:24 PM megous via linux-sunxi
wrote:
>
> From: Ondrej Jirman
>
> Orange Pi 3 has two regulators that power the Realtek RTL8211E. According
> to the phy datasheet, both regulators need to be enabled at the same time,
> but we can only specify a single phy-supply in the
On Monday, 2019-04-29 18:10:52 +0900, Seung-Woo Kim wrote:
> In drmModeGetPropertyPtr(), from upper error path, it calls free
> but with just next error path, it does not call. Fix the possible
> memory leak.
>
> Signed-off-by: Seung-Woo Kim
Reviewed-by: Eric Engestrom
and pushed, thanks!
>
On 23/04/2019 17:56, Laurent Pinchart wrote:
>> During initial driver development I had one eDP display that reports 0 in
>> Bit 0
>> (ANSI 8B/10B) of DPCD reg 0x0006 (MAIN_LINK_CHANNEL_CODING).
>> Also it does not react on setting Bit 0 (SET_ANSI 8B10B) in 0x0108
>>
https://bugs.freedesktop.org/show_bug.cgi?id=110598
Bug ID: 110598
Summary: [IGT runner] allow tests to attach test-specific
results
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status:
https://bugs.freedesktop.org/show_bug.cgi?id=110597
Bug ID: 110597
Summary: [IGT runner] allow attachments to results.json
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity:
https://bugs.freedesktop.org/show_bug.cgi?id=110598
Martin Peres changed:
What|Removed |Added
Depends on||110597
Referenced Bugs:
https://bugs.freedesktop.org/show_bug.cgi?id=110597
Martin Peres changed:
What|Removed |Added
Blocks||110598
Referenced Bugs:
Hi Lucas,
On Wed, Apr 17, 2019 at 03:50:15PM +0200, Lucas Stach wrote:
>
> Hi all,
>
> v1 cover letter:
>
> the following patches finally implement one of the longstanding TODO
> items in the etnaviv driver: per-process address spaces. They are only
> enabled for MMUv2, as switching the MMU
On 21/04/2019 00:44, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Mar 26, 2019 at 12:31:37PM +0200, Tomi Valkeinen wrote:
>> At the end of the link training, two steps have to be taken: 1)
>> tc358767's LT mode is disabled by a write to DP0_SRCCTRL, and 2) Remove
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #27 from Christian Zigotzky ---
Hi All,
Allan tested the first test kernel today. He wrote:
Hi Christian
The kernel boots but to SI card.
Cheers
ace
--
That means, this step has been marked as bad.
git bisect bad
Output:
On 21/04/2019 01:06, Laurent Pinchart wrote:
> Hi Tomi,
>
> Thank you for the patch.
>
> On Tue, Mar 26, 2019 at 12:31:38PM +0200, Tomi Valkeinen wrote:
>> The driver has a loop after ending link training, where it reads the
>> DPCD link status and prints an error if that status is not ok.
>>
>>
On Thu, 2 May 2019 at 23:19, Rob Clark wrote:
>
> On Thu, May 2, 2019 at 2:57 PM Dan Willemsen wrote:
> >
> > On Thu, May 2, 2019 at 1:52 PM John Stultz wrote:
> > >
> > > We need solutions for the xgettext and the python-mako usage.
> >
> > Android doesn't support translations at this level,
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #52 from Marco (rodomar...@protonmail.com) ---
(In reply to Marco from comment #51)
> (In reply to Alex Deucher from comment #49)
> > Can you still log in remotely via ssh and get an updated dmesg? If it's a
> > blank screen, can you
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #51 from Marco (rodomar...@protonmail.com) ---
(In reply to Alex Deucher from comment #49)
> Can you still log in remotely via ssh and get an updated dmesg? If it's a
> blank screen, can you try another display connector on the
1 - 100 of 153 matches
Mail list logo
