On 27/04/18 21:12, Aaro Koskinen wrote:
>> You should be targeting omapdrm driver instead, fbdev subsystem is closed
>> for the new hardware support.
>
> AFAIK, based on N950 display support discussion, it's impossible to get
> anything new into omapdrm for a long time. And based on Tomi's commen
https://bugs.freedesktop.org/show_bug.cgi?id=106013
Martin Peres changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #5 from Martin Peres
Quoting Jani Nikula (2018-04-27 12:20:55)
> On Wed, 25 Apr 2018, Ian W MORRISON wrote:
> > Can I ask if this is on anyone's radar as I'm concerned this patch will
> > stall otherwise?
>
> Pushed to drm-intel-next-queued, thanks for the patch.
>
> I opted to drop the Cc: stable for now. This does
Hey Emil,
On 27.04.2018 15:48, Emil Velikov wrote:
On 27 April 2018 at 12:31, Robert Foss wrote:
drmHandleMatch is intended to allow for userspace to filter out
devices that it does not want to open.
Opening specific devices using paths alone is not a reliable due to
probing order. This funct
Hi Laurent,
Sorry for late reply.
> -Original Message-
> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com]
> Sent: Montag, 23. April 2018 23:47
> To: Ucan, Emre (ADITG/ESB)
> Cc: dri-devel@lists.freedesktop.org
> Subject: Re: [PATCH v2] drm: rcar-du: track dma-buf fences
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #13 from Michel Dänzer ---
(In reply to Francisco Pina Martins from comment #12)
> francisco@ZenBox [18:12:53] [/usr/lib/modules/4.16.5-1-kasan/build]
> -> $ scripts/faddr2line ../kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
> firmwa
https://bugs.freedesktop.org/show_bug.cgi?id=106317
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com
--- Comment #1 f
On Tue, 31 Oct 2017 12:32:57 -0700
Eric Anholt wrote:
> It seems that trying to go from unlatched to unlatched will time out
> waiting for STOP, and we can just skip that.
>
> Signed-off-by: Eric Anholt
Reviewed-by: Boris Brezillon
> ---
> drivers/gpu/drm/vc4/vc4_dsi.c | 5 +
> 1 file c
https://bugzilla.kernel.org/show_bug.cgi?id=199567
--- Comment #2 from Michel Dänzer (mic...@daenzer.net) ---
Can you bisect?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.f
On Tue, 31 Oct 2017 12:32:58 -0700
Eric Anholt wrote:
> It turns out that I had just mistaken what type of write the register
> writes were supposed to be, using DCS instead of generic long writes.
>
> Switching to transactions instead of using the atmel as a bridge also
> seems to resolve the s
Den 24.04.2018 18.52, skrev Noralf Trønnes:
Den 23.04.2018 18.16, skrev Tom Callaway:
The PiTFT (ili9340) has a hardware reset circuit that resets only
on power-on and not on each reboot through a gpio like the
rpi-display does. As a result, we need to always apply the
rotation value regardles
https://bugs.freedesktop.org/show_bug.cgi?id=106297
--- Comment #9 from Michel Dänzer ---
Does
https://patchwork.freedesktop.org/patch/218931/
help?
--
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=106263
Michel Dänzer changed:
What|Removed |Added
Attachment #139194|text/x-log |text/plain
mime type|
On Tue, Oct 31, 2017 at 12:32:58PM -0700, Eric Anholt wrote:
> It turns out that I had just mistaken what type of write the register
> writes were supposed to be, using DCS instead of generic long writes.
>
> Switching to transactions instead of using the atmel as a bridge also
> seems to resolve
https://bugs.freedesktop.org/show_bug.cgi?id=106263
Michel Dänzer changed:
What|Removed |Added
CC||charlene@amd.com
--- Comment #6 fro
https://bugs.freedesktop.org/show_bug.cgi?id=106289
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Gallium/r300
Version
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #14 from Francisco Pina Martins ---
francisco@ZenBox [10:31:49] [~]
-> $ file
/usr/lib/modules/4.16.5-1-kasan/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko
/usr/lib/modules/4.16.5-1-kasan/kernel/drivers/gpu/drm/amd/amdgpu/amdgpu.ko:
E
Greg, Thomas,
On Wed, 25 Apr 2018, Daniel Vetter wrote:
> Leaking driver internal tracking into the already massively confusing
> backlight power tracking is really confusing.
>
> Luckily we have already a drvdata structure, so fixing this is really
> easy.
>
> Cc: Lee Jones
> Cc: Daniel Thomps
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #15 from Francisco Pina Martins ---
Here you go:
francisco@ZenBox [11:13:37] [/tmp/build/linux-kasan/src/linux-4.16]
-> $ scripts/faddr2line drivers/gpu/drm/amd/amdgpu/amdgpu.ko
firmware_parser_create+0xa70/0xd90
firmware_parser_cr
On Fri, 27 Apr 2018, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> The MMSYS subsystem includes clocks and drm components.
> This patch adds a MFD device to probe both drivers from the same
> device tree compatible.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/mfd/Kconfig
On Wed, 25 Apr 2018, Daniel Vetter wrote:
> The backlight power state handling is supremely confusing. We have:
> - props.power, using FB_BLANK_* defines
> - props.fb_blank, using the same, but deprecated int favour of
> props.state
> - props.state, using the BL_CORE_* defines
> - and finally a
On Wed, 25 Apr 2018, Daniel Vetter wrote:
> Nothing in the entire tree ever sets this, which means this is dead
> code. Remove it.
>
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
> Acked-by: Daniel Thompson
> Signed-off-by: Daniel Vetter
Reviewed-by: Jani Nikula
> ---
> drivers/v
On Wed, 25 Apr 2018, Daniel Vetter wrote:
> Leaking driver internal tracking into the already massively confusing
> backlight power tracking is really confusing.
>
> Luckily we have already a drvdata structure, so fixing this is really
> easy.
>
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo
On Wed, 25 Apr 2018, Daniel Vetter wrote:
> Leaking driver internal tracking into the already massively confusing
> backlight power tracking is really confusing.
>
> Stop that by allocating a tiny driver private data structure instead.
>
> Cc: Lee Jones
> Cc: Daniel Thompson
> Cc: Jingoo Han
>
On Wed, 25 Apr 2018, Daniel Vetter wrote:
> Now that the 3 drivers using this are cleaned up we can also remove
> this final bit of confusion of leaking driver internals into the
> backlight power interface.
>
> The backlight power interface itself is still a massive mess.
>
> Cc: Lee Jones
> Cc:
On Fri, 27 Apr 2018, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> Add binding description for the mmsys mfd for some Mediatek
> devices. mmsys has some registers to control clock gates (which is
> used in the clk driver) and some registers to set the routing and enable
> the diffe
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #16 from Michel Dänzer ---
That does look helpful, thanks! I'll leave it to the DC folks to take it from
here.
Francisco, just one more thing: Can you double-check that KASAN still reports
firmware_parser_create+0xa70/0xd90 with the
On Sat, Apr 28, 2018 at 08:21:58AM +0530, Nipun Gupta wrote:
[...]
> diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
> index 88a3558..a9ec99d 100644
> --- a/drivers/gpu/host1x/bus.c
> +++ b/drivers/gpu/host1x/bus.c
> @@ -314,6 +314,13 @@ static int host1x_device_match(struct device
Hi, Matthias:
On Fri, 2018-04-27 at 11:23 +0200, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> With the mtk-mmsys MFD device in place, we switch the probing for
> mt2701 from device-tree to mfd.
>
> Signed-off-by: Matthias Brugger
Reviewed-by: CK Hu
Regards,
CK
> ---
> driv
Hi, Matthias:
On Fri, 2018-04-27 at 11:24 +0200, matthias@kernel.org wrote:
> From: Matthias Brugger
>
> When probe through the MFD, it can happen that the
> clock drivers wasn't probed before the ddp driver gets
> invoked. The driver used to omit a warning that the driver
> failed to get th
On Mon, Apr 30, 2018 at 10:54:15AM +0100, Lee Jones wrote:
> Greg, Thomas,
>
> On Wed, 25 Apr 2018, Daniel Vetter wrote:
> > Leaking driver internal tracking into the already massively confusing
> > backlight power tracking is really confusing.
> >
> > Luckily we have already a drvdata structure,
On Thu, Apr 26, 2018 at 02:11:36PM +0200, Thierry Reding wrote:
> On Wed, Apr 25, 2018 at 08:19:34AM -0700, Christoph Hellwig wrote:
> > On Wed, Apr 25, 2018 at 12:10:48PM +0200, Thierry Reding wrote:
> > > From: Thierry Reding
> > >
> > > The dma_iommu_detach_device() API can be used by drivers
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #17 from Francisco Pina Martins ---
I don't think I'll be able to test that, since The kernel with debug enabled
weights in at 590Mb, which is larger than my 512Mb /boot partition.
Will it work if I just replace the amdgpu.ko file wi
On 30/04/18 12:02, Thierry Reding wrote:
On Thu, Apr 26, 2018 at 02:11:36PM +0200, Thierry Reding wrote:
On Wed, Apr 25, 2018 at 08:19:34AM -0700, Christoph Hellwig wrote:
On Wed, Apr 25, 2018 at 12:10:48PM +0200, Thierry Reding wrote:
From: Thierry Reding
The dma_iommu_detach_device() API c
On 27/04/18 18:39, Thomas Hellstrom wrote:
On 04/27/2018 06:56 PM, Robin Murphy wrote:
Hi Thomas,
On 25/04/18 14:21, Thomas Hellstrom wrote:
Hi, Robin,
Thanks for the patch. It was some time since I put together that
code, but I remember hitting something similar to
https://urldefense.proo
Hi Emre,
On Monday, 30 April 2018 11:40:51 EEST Ucan, Emre (ADITG/ESB) wrote:
> Hi Laurent,
>
> Sorry for late reply.
No worries.
> On Montag, 23. April 2018 23:47 Laurent Pinchart wrote:
> > On Wednesday, 4 April 2018 14:03:57 EEST Emre Ucan wrote:
> >> We have to check dma-buf reservation obj
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #58 from MirceaKitsune ---
(In reply to iive from comment #57)
I believe I've already tried with nodma under Xonotic, as I previously
attempted playing with the following options and still got the crash:
export
R600_DEBUG=checkir,p
On Wed, Apr 18, 2018 at 12:40 PM, Stefan Schake wrote:
> Using drm_atomic_get_private_obj_state after state has been swapped
> will return old state.
>
> Fixes: 0281c4149021 ("drm/tegra: hub: Use private object for global state")
> Signed-off-by: Stefan Schake
> ---
> drivers/gpu/drm/tegra/hub.c
We have to check dma-buf reservation objects of our framebuffers before
we use them. Otherwise, another driver might be writing on the same
buffer which we are using. This would cause visible tearing effects
on display.
We can use existing atomic helper functions to solve this problem.
v2 changes
https://bugs.freedesktop.org/show_bug.cgi?id=105425
--- Comment #59 from MirceaKitsune ---
I'm not sure if this helps, but here is the darkplaces engine file responsible
for drawing shadows. Remember that when disabling shadows, the frequency of the
freeze is reduced from 0 - 30 minutes to 60 - 2
On Mon, Apr 30, 2018 at 12:41:52PM +0100, Robin Murphy wrote:
> On 30/04/18 12:02, Thierry Reding wrote:
> > On Thu, Apr 26, 2018 at 02:11:36PM +0200, Thierry Reding wrote:
> > > On Wed, Apr 25, 2018 at 08:19:34AM -0700, Christoph Hellwig wrote:
> > > > On Wed, Apr 25, 2018 at 12:10:48PM +0200, Thi
On Mon, 30 Apr 2018, Jani Nikula wrote:
> On Wed, 25 Apr 2018, Daniel Vetter wrote:
> > Now that the 3 drivers using this are cleaned up we can also remove
> > this final bit of confusion of leaking driver internals into the
> > backlight power interface.
> >
> > The backlight power interface its
Hi Laurent,
(snip)
> > I will send a new patch with these changes after I tested it. Is it possible
> > that improved patch lands on 4.17 and 4.14 stable versions? What is the
> > process to propose a patch to a stable release ?
>
> The process is pretty simple, it's documented in
> Documentatio
On Wed, 25 Apr 2018, Daniel Vetter wrote:
> The backlight power state handling is supremely confusing. We have:
> - props.power, using FB_BLANK_* defines
> - props.fb_blank, using the same, but deprecated int favour of
> props.state
> - props.state, using the BL_CORE_* defines
> - and finally a
On 11/04/18 19:55, Jordan Crouse wrote:
I've been struggling with a problem for a while and I haven't been able to come
up with a clean solution. Rob convinced me to stop complaining and do
_something_ and hopefully this can spur a good discussion.
The scenario is basically this: The MSM GPU wan
https://bugs.freedesktop.org/show_bug.cgi?id=106199
--- Comment #8 from Maximilian Böhm ---
I can confirm, works again on Linux 4.17 RC3.
But label this bug RESOLVED WORKSFORME is the wrong attitude. It needs to get
fixed in 4.16 too.
--
You are receiving this mail because:
You are the assignee
On 30/04/18 13:12, Thierry Reding wrote:
On Mon, Apr 30, 2018 at 12:41:52PM +0100, Robin Murphy wrote:
On 30/04/18 12:02, Thierry Reding wrote:
On Thu, Apr 26, 2018 at 02:11:36PM +0200, Thierry Reding wrote:
On Wed, Apr 25, 2018 at 08:19:34AM -0700, Christoph Hellwig wrote:
On Wed, Apr 25, 20
https://bugs.freedesktop.org/show_bug.cgi?id=106175
--- Comment #11 from tempel.jul...@gmail.com ---
I noticed that this issue also exists apart from Xorg compositors.
When I run Serious Sam: Fusion (both OpenGL and Vulkan) in fullscreen (no Xorg
compositor enabled in the background), the mouse cu
On Thu, Apr 26, 2018 at 04:54:23PM +0200, Lukas Wunner wrote:
> On Thu, Apr 26, 2018 at 04:25:57PM +0200, Daniel Vetter wrote:
> > This is the exact same text as proposed&merged for igt:
> >
> > https://patchwork.kernel.org/patch/10339739/
> >
> > With one minor change: Both regular contributions
On 27/04/18 20:42, Sinan Kaya wrote:
On 4/27/2018 11:54 AM, Robin Murphy wrote:
ubuntu@ubuntu:~/amdgpu$_./vectoradd_hip.exe
[ 834.002206] create_process:620
[ 837.413021] Unable to handle kernel NULL pointer dereference at virtual
address 0018
£5 says that's sg_dma_len(NULL), which im
https://bugs.freedesktop.org/show_bug.cgi?id=106225
--- Comment #18 from Michel Dänzer ---
(In reply to Francisco Pina Martins from comment #17)
> Will it work if I just replace the amdgpu.ko file with the debug-enabled
> version?
Yeah, that could work. If it doesn't, then it's not a big deal, i
Commit b9f19259b84d ("drm/vc4: Add the DRM_IOCTL_VC4_GEM_MADVISE ioctl")
introduced a mechanism to mark some BOs as purgeable to allow the driver
to drop them under memory pressure. In order to implement this feature
we had to add a mechanism to mark BOs as currently used by a piece of
hardware whi
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/Kconfig | 1 +
drivers/gpu/drm/selftests/Makefile| 2 +-
.../gpu/drm/selftests/drm_helper_selftests.h | 9 +
drivers/gpu/drm/selftests/test-drm-helper.c | 247 ++
4 files changed, 258 i
No matter how you perform the clip adjustments, a small
error may push the scaling factor to the other side of
0x1. Solve this with a macro that will fixup the
scale to 0x1 if we accidentally wrap to the other side.
Changes since v1:
- Adjust dst immediately, else drm_rect_width/height on
We want to add more DRM selftests, and there's not much point in
having a Kconfig option for every single one of them, so make
a generic one.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/Kconfig| 8
drivers/gpu/drm/Makefile | 2 +-
drivers/gpu/drm/selftests
When calculating limits we want to be as pessimistic as possible,
so we have to explicitly say whether we want to round up or down
to accurately calculate whether we are below min_scale or above
max_scale.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/drm_rect.c | 17 -
1
There were some small rounding errors in when clamping with
1.0001 and 0. scaling, solve these and add a testcase for drm
helpers, which can be used to prevent more of these errors in the
future.
The testcases helped me find an error in v1, which wouldn't have
been found in another way.
Maart
With the previous patch drm_atomic_helper_check_plane_state correctly
calculates clipping and the xf86-video-intel ddx is fixed to fall back
to GPU correctly when SetPlane fails, we can remove the hack where
we try to pan/zoom when out of min/max scaling range. This was already
poor behavior where
The amdgpu driver doesn't appear to directly use the scatterlist mapped
by amdgpu_ttm_tt_pin_userptr(), it merely hands it off to
drm_prime_sg_to_page_addr_arrays() to generate the dma_address array
which it actually cares about. Now that the latter can cope with
dma_map_sg() coalescing dma-contigu
Much like amdgpu, the radeon driver doesn't appear to directly use the
scatterlist mapped by radeon_ttm_tt_pin_userptr(), it merely hands it
off to drm_prime_sg_to_page_addr_arrays() to generate the dma_address
array which it actually cares about. Now that the latter can cope with
dma_map_sg() coal
For dma_map_sg(), DMA API implementations are free to merge consecutive
segments into a single DMA mapping if conditions are suitable, thus the
resulting DMA addresses which drm_prime_sg_to_page_addr_arrays()
iterates over may be packed into fewer entries than sgt->nents implies.
The current imple
https://bugs.freedesktop.org/show_bug.cgi?id=105018
--- Comment #31 from Öyvind Saether ---
Kernel 4.17.0-rc3-linus.git-keumjo4.17.0-rc3-linus.git-keumjo on a 2400G with a
RX 560 GPU:
> login to xfce desktop
> type "xset dpms force standby" in a terminal
screens go blank and there is no more res
https://bugs.freedesktop.org/show_bug.cgi?id=106317
--- Comment #2 from Öyvind Saether ---
This could be duplicate of
https://bugs.freedesktop.org/show_bug.cgi?id=105018#c31
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=105911
--- Comment #11 from lucbo...@gmail.com ---
I can confirm the bug ( in my case I have a DVI-I to VGA adapter)
https://bugs.launchpad.net/bugs/1762259
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=106317
--- Comment #3 from Kertesz Laszlo ---
(In reply to Öyvind Saether from comment #2)
> This could be duplicate of
> https://bugs.freedesktop.org/show_bug.cgi?id=105018#c31
Not sure, when this happens to me the box is dead (no ssh etc).
Later i w
https://bugs.freedesktop.org/show_bug.cgi?id=106199
--- Comment #9 from Maximilian Böhm ---
BTW, 4.17 RC3 does not bring back my DP monitor after I have turned it off, so
this situation is by far not hunky-dory.
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=106285
--- Comment #1 from ojab ---
```
#!/bin/sh
set -ex
while true; do
set -x
X&
sleep 1
XPID=$!
kill -9 ${XPID}
sleep 0.1
done
```
reliably triggers this error in a minute or so.
--
You are receiving this mail because:
You
The DRM panel framework now exposes a way to know whether a panel is
connected or disconnected.
Use this panel detection logic to implement the connector->detect_ctx()
method and allow one to report when a panel is connected or disconnected
which is particularly useful to support panels connected
Implement a way to determine when the panel is connected. This is done
by reading REG_ID through I2C. We consider the panel as disconnect
until we retrieve a valid ID.
Signed-off-by: Boris Brezillon
---
.../gpu/drm/panel/panel-raspberrypi-touchscreen.c | 62 ++
1 file change
Some panels are connected through extension boards an provide an easy
way for the main board to detect when they are present (like checking
for a working I2C communication with a device and making sure a
specific reg in this device has a consistent value).
When this is the case, we might want to s
Some panels might be connected through extension boards and might not
be available when the system boots. Extend the panel interface to
support panel detection.
An optional ->detect() hook is added and, if implemented, will be called
every time the panel user wants to know if the panel is connecte
https://bugs.freedesktop.org/show_bug.cgi?id=106199
--- Comment #10 from Harry Wentland ---
A fix should land in 4.16 stable soon:
https://www.spinics.net/lists/stable-commits/msg86375.html
--
You are receiving this mail because:
You are the assignee for the bug.
On Sat, Apr 28, 2018 at 12:07:04AM +0300, Laurent Pinchart wrote:
> Hi Daniel,
>
> (Removing the linux-media mailing list from CC as it is out of scope)
>
> You enquired on IRC whether this patch series passes the igt CRC tests.
>
> # ./kms_pipe_crc_basic --run-subtest read-crc-pipe-A
> IGT-Vers
On 27/04/18 19:51, Linus Walleij wrote:
On Fri, Apr 27, 2018 at 5:02 PM, Robin Murphy wrote:
I dug a little bit and it seems pl111_modeset_init() is deferring because it
can't find endpoint 0. And given that that's apparently pointing at some
non-existent panel rather than the DVI encoder as I
https://bugs.freedesktop.org/show_bug.cgi?id=105018
--- Comment #32 from L.S.S. ---
So it seems there definitely is a regression on 4.17 on this issue (the patches
are not required as the lines were already there in 4.17). This time it isn't a
kernel panic, but an "invalid opcode" error caused by
On Mon, Apr 30, 2018 at 04:55:24PM +0200, Daniel Vetter wrote:
> On Sat, Apr 28, 2018 at 12:07:04AM +0300, Laurent Pinchart wrote:
> > Hi Daniel,
> >
> > (Removing the linux-media mailing list from CC as it is out of scope)
> >
> > You enquired on IRC whether this patch series passes the igt CRC
https://bugs.freedesktop.org/show_bug.cgi?id=100891
--- Comment #5 from MichaelLong ---
Update:
>From time to time I'm testing this card with newer kernels along with the most
recent set of firmware files. The only difference I was able to observe is that
the amount of debug messages is less and
https://bugs.freedesktop.org/show_bug.cgi?id=100891
--- Comment #6 from MichaelLong ---
Created attachment 139229
--> https://bugs.freedesktop.org/attachment.cgi?id=139229&action=edit
dmesg output of kernel 4.17-rc3
--
You are receiving this mail because:
You are the assignee for the bug.
On Fri, Apr 27, 2018 at 10:40:00PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 23, 2018 at 10:34:41AM +0300, StanLis wrote:
> > From: Stanislav Lisovskiy
> >
> > Added content_type property to drm_connector_state
> > in order to properly handle external HDMI TV content-type setting.
> >
> > v2:
>
https://bugs.freedesktop.org/show_bug.cgi?id=100891
--- Comment #7 from MichaelLong ---
Created attachment 139230
--> https://bugs.freedesktop.org/attachment.cgi?id=139230&action=edit
recent lspci output
--
You are receiving this mail because:
You are the assignee for the bug.
On Thu, Apr 26, 2018 at 05:16:31PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> An overeager sed has corrupted the drm_rect_rotation_inv()
> documentation. Fix it up.
>
> Looks like it wasn't entirely correct before the sed fail
> either. We were missing _rect_ from the function names,
On Fri, Apr 27, 2018 at 01:40:21AM +0300, Laurent Pinchart wrote:
> Hi Peter,
>
> Thank you for the patches.
>
> On Friday, 27 April 2018 01:31:15 EEST Peter Rosin wrote:
> > Hi!
> >
> > It was noted by Russel King [1] that bridges (not using components)
> > might disappear unexpectedly if the o
On 27/04/18 20:54, Linus Walleij wrote:
The Versatile Express was submitted with the actual display
bridges unconnected (but defined in the device tree) and
mock "panels" encoded in the device tree node of the PL111
controller.
This doesn't even remotely describe the actual Versatile
Express har
On Fri, Apr 27, 2018 at 12:31:38AM +0200, Peter Rosin wrote:
> The .owner will be handy to have around.
>
> Signed-off-by: Peter Rosin
> ---
> drivers/gpu/drm/drm_bridge.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> i
On Fri, Apr 27, 2018 at 12:31:39AM +0200, Peter Rosin wrote:
> If the bridge supplier is unbound, this will bring the bridge consumer
> down along with the bridge. Thus, there will no longer linger any
> dangling pointers from the bridge consumer (the drm_device) to some
> non-existent bridge suppl
On Friday, April 27, 2018 09:25:37 PM Aaro Koskinen wrote:
> Hi,
>
> On Fri, Apr 27, 2018 at 05:09:14PM +0200, Bartlomiej Zolnierkiewicz wrote:
> > omapfb equivalent of drm's commit aa61321d4c08 ("drm/omap: remove rfbi"):
> >
> > The RFBI driver has not worked nor compiled for many years. There a
On Sun, Apr 29, 2018 at 09:11:31AM +0200, Christian König wrote:
> Am 27.04.2018 um 08:17 schrieb Daniel Vetter:
> > When this was introduced in
> >
> > commit a519435a96597d8cd96123246fea4ae5a6c90b02
> > Author: Christian König
> > Date: Tue Oct 20 16:34:16 2015 +0200
> >
> > dma-buf/fen
On Sun, Apr 29, 2018 at 09:08:31AM +0200, Christian König wrote:
> NAK, there is a subtitle but major difference:
>
> > - if (rdev->needs_reset) {
> > - t = -EDEADLK;
> > - break;
> > - }
>
> Without that the whole radeon GPU reset code brea
Replied on the ticket.
If this is about non-functioning LVDS or VGA I'm aware of it and trying to find
time to find a good solution.
Harry
On 2018-04-30 11:14 AM, Joseph Salisbury wrote:
> Hi Harry,
>
> A kernel bug report was opened against Ubuntu [0]. After a kernel
> bisect, it was found th
On Mon, Apr 30, 2018 at 02:02:04PM +0200, Emre Ucan wrote:
> We have to check dma-buf reservation objects of our framebuffers before
> we use them. Otherwise, another driver might be writing on the same
> buffer which we are using. This would cause visible tearing effects
> on display.
>
> We can
On Mon, Apr 30, 2018 at 04:43:21PM +0200, Boris Brezillon wrote:
> Some panels might be connected through extension boards and might not
> be available when the system boots. Extend the panel interface to
> support panel detection.
>
> An optional ->detect() hook is added and, if implemented, will
On 2018-04-29 09:02 AM, Christian König wrote:
> Am 29.04.2018 um 01:02 schrieb Michel Dänzer:
>> On 2018-04-28 06:30 PM, Ilia Mirkin wrote:
>>> On Fri, Apr 27, 2018 at 9:08 AM, Michel Dänzer
>>> wrote:
From: Michel Dänzer
Previously, TTM would always (with CONFIG_TRANSPARENT_HUGEP
Hi Daniel,
On Mon, 30 Apr 2018 18:08:47 +0200
Daniel Vetter wrote:
> On Mon, Apr 30, 2018 at 04:43:21PM +0200, Boris Brezillon wrote:
> > Some panels might be connected through extension boards and might not
> > be available when the system boots. Extend the panel interface to
> > support panel
Boris Brezillon writes:
> Some panels are connected through extension boards an provide an easy
> way for the main board to detect when they are present (like checking
> for a working I2C communication with a device and making sure a
> specific reg in this device has a consistent value).
>
> When
The driver for S6E63M0 AMOLED LCD panel is not used. It does not
support DeviceTree and respective possible users (S5Pv210 Aquila and
Goni boards) are DeviceTree-only.
Suggested-by: Marek Szyprowski
Cc: Marek Szyprowski
Cc: Inki Dae
Signed-off-by: Krzysztof Kozlowski
---
drivers/video/backli
The driver for LD9040 AMOLED LCD panel was superseded with DRM driver
panel-samsung-ld9040.c. It does not support DeviceTree and respective
possible user (Exynos4210 Universal C210) is DeviceTree-only and uses
DRM version of driver..
Suggested-by: Marek Szyprowski
Cc: Marek Szyprowski
Cc: Inki
On Mon, 30 Apr 2018 10:22:19 -0700
Eric Anholt wrote:
> Boris Brezillon writes:
>
> > Some panels are connected through extension boards an provide an easy
> > way for the main board to detect when they are present (like checking
> > for a working I2C communication with a device and making sure
Daniel Vetter writes:
> + /**
> + * @fill_driver_data:
> + *
> + * Callback to fill in free-form debug info Returns amount of bytes
> + * filled, or negative error on failure.
Maybe this "Returns" should be on a new line? Or at least a '.' in
between.
Other than that,
R
Daniel Vetter writes:
> Noticed while I was typing docs. Entirely unused.
>
> Signed-off-by: Daniel Vetter
> ---
> include/linux/dma-fence.h | 10 --
> 1 file changed, 10 deletions(-)
>
> diff --git a/include/linux/dma-fence.h b/include/linux/dma-fence.h
> index 9d6f39bf2111..f9a6848f85
Daniel Vetter writes:
> dma_fence_default_wait is the default now, same for the trivial
> enable_signaling implementation.
>
> Signed-off-by: Daniel Vetter
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
___
dri-devel mailing list
1 - 100 of 170 matches
Mail list logo
