https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #24 from Richard Thier ---
Sorry! I have to add that the above printf only prints as such if I use my
hacky patch on latest git! I will try what it says with the "proposed fix"
patch of Marek as the body of radeon_get_heap_index seem
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #23 from Richard Thier ---
I have added this before the assert:
fprintf(stderr, "radeon_get_heap_index(%u, %u): %d", domain, flags, heap);
And I see this logged out before the assertion fail:
radeon_get_heap_index(6, 1): -1
Will
https://bugs.freedesktop.org/show_bug.cgi?id=110822
--- Comment #4 from Alex Deucher ---
(In reply to Gobinda Joy from comment #3)
> I was curious so checked out the commit log on amd-staging-drm-next branch.
> And I see some reverts of powerplay related commits.
>
> Link: https://cgit.freedeskt
https://bugzilla.kernel.org/show_bug.cgi?id=203779
--- Comment #3 from Gobinda Joy (gobinda@gmail.com) ---
(In reply to Alex Deucher from comment #2)
> Can you bisect?
I thought helping as more in line with if you need more logs/debug logs. Not
sure I can bisect this bug though. Sorry for get
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #22 from Richard Thier ---
I also get the same error if I apply my simple hack of use_reusable_pool=true;
Applying the changes to the revision where things went wrong in the past seem
to be working though (but I did not test them fo
https://bugs.freedesktop.org/show_bug.cgi?id=110822
--- Comment #3 from Gobinda Joy ---
Thanks for the reply.
By today's standard my whole system spec is slow to be honest.
But slow ram speed shouldn't cause this problems with powerplay. As I can run
the card fine with load or idle with kernel
On Wed, May 29, 2019 at 01:22:30PM +0300, Jani Nikula wrote:
> On Wed, 29 May 2019, Ilpo Järvinen wrote:
> > On Tue, 28 May 2019, Jani Nikula wrote:
> >
> >> On Mon, 27 May 2019, Ashutosh Dixit wrote:
> >> > On Sun, 26 May 2019 12:50:51 -0700, Ilpo Järvinen wrote:
> >> >>
> >> >> Hi all,
> >> >>
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #21 from Richard Thier ---
Hi!
I have applied this "possible fix" patch to the (nearly) latest 19.x from git
and I get an assertion error there.
glxinfo: ../src/gallium/winsys/radeon/drm/radeon_drm_bo.c:1023:
radeon_winsys_bo_creat
https://bugzilla.kernel.org/show_bug.cgi?id=203779
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #20 from Marek Olšák ---
GEM_CREATE just creates a buffer, you should always see them, but a lot less.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-dev
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #36 from sehell...@gmail.com ---
Created attachment 144438
--> https://bugs.freedesktop.org/attachment.cgi?id=144438&action=edit
dmesg.log vega20 crash after idle
--
You are receiving this mail because:
You are the assignee for th
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #35 from sehell...@gmail.com ---
Vega20 affected to these or similar bugs, too. On are kernels 5.0.x the primary
monitor falls. Starting with version 5.1.x, hangs and resets gpu already after
login to x-session or after workiing dpms.
https://bugs.freedesktop.org/show_bug.cgi?id=108973
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Timothy A
https://bugs.freedesktop.org/show_bug.cgi?id=108628
Timothy Arceri changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
On Mon, Jun 3, 2019 at 4:09 PM Daniel Vetter wrote:
>
> On Mon, Jun 03, 2019 at 09:45:49AM +0200, Hans Verkuil wrote:
> > On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > > From: Hans Verkuil
> > >
> > > Add support for HDMI hotplug and EDID notifiers, which is used to convey
> > > information from
Hi, Hsin-Yi:
On Thu, 2019-05-30 at 17:18 +0800, Hsin-Yi Wang wrote:
> mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which
> needs
> ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is called,
> ovl irq will be disabled. If drm_crtc_wait_one_vblank() is cal
On Mon, Jun 3, 2019 at 3:46 PM Hans Verkuil wrote:
>
> On 6/3/19 6:32 AM, Cheng-Yi Chiang wrote:
> > From: Hans Verkuil
> >
> > Add support for HDMI hotplug and EDID notifiers, which is used to convey
> > information from HDMI drivers to their CEC and audio counterparts.
> >
> > Based on an earli
Hi, Hsin-Yi:
On Wed, 2019-05-29 at 18:25 +0800, Hsin-Yi Wang wrote:
> There are some errors when unbinding and rebinding mediatek drm, dsi,
> and disp-* drivers. This series is to fix those errors and warnings.
>
> Hsin-Yi Wang (4):
> drm: mediatek: fix unbind functions
> drm: mediatek: unbin
https://bugs.freedesktop.org/show_bug.cgi?id=110422
--- Comment #2 from Dieter Nützel ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #1)
> Should be fixed on master by
> https://gitlab.freedesktop.org/mesa/mesa/commit/
> 4583f09caa5aef719a1eec282f24a86c789cbba6.
>
> Can you test and co
On Sat, Jun 1, 2019 at 5:26 PM Jitao Shi wrote:
>
> Change the method of frame rate calc which can get more accurate
> frame rate.
>
> data rate = pixel_clock * bit_per_pixel / lanes
> Adjust hfp_wc to adapt the additional phy_data
>
> if MIPI_DSI_MODE_VIDEO_BURST
> hfp_wc = hfp * bpp - da
https://bugs.freedesktop.org/show_bug.cgi?id=110822
--- Comment #2 from Matt Coffin ---
I'm experiencing the same problem, but with an XFX RX 590 FATBOY.
Strangely enough, I am also running crappy, kinda slow DDR3 RAM at 1600 mhz.
I've read so much on this issue today that I don't know where I
Booting up with DMA_API_DEBUG_SG=y generates a warning due to the driver
forgot to set dma_parms appropriately. Set it just after vmw_dma_masks()
in vmw_driver_load().
DMA-API: vmwgfx :00:0f.0: mapping sg segment longer than device
claims to support [len=2097152] [max=65536]
WARNING: CPU: 2 PI
Laurent,
On Thu, May 16, 2019 at 2:40 PM Douglas Anderson wrote:
>
> On Rockchip rk3288-based Chromebooks when you do a suspend/resume
> cycle:
>
> 1. You lose the ability to detect an HDMI device being plugged in.
>
> 2. If you're using the i2c bus built in to dw_hdmi then it stops
> working.
>
On Sun, Jun 2, 2019 at 8:40 PM Ilia Mirkin wrote:
>
> This series improves the pattern generation logic to support additional
> formats, as well as a new "gradient" pattern (see patch comments on why
> I found it useful).
>
> Furthermore, these formats are piped through to modetest, including the
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #19 from Richard Thier ---
Hmmm... I have tried the possible fix and Extreme Tux Racer became fast again
however I still see a lot of "DRM_IOCTL_RADEON_GEM_CREATE" if I do an
strace -T -e ioctl glxgears 2>&1 | vim -
So things are f
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #18 from Richard Thier ---
Will try that supposed patch as soon as possible. It seems reasonable to me as
far as I understand it. So you basically set the flag for r300. I was searching
a lot to see where to add these, but I was too
On 6/3/19 1:56 PM, Helen Koike wrote:
> Async update callbacks are expected to set the old_fb in the new_state
> so prepare/cleanup framebuffers are balanced.
>
> Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
> fb and put the old fb) is not required, as it's taken care
On 6/3/19 1:56 PM, Helen Koike wrote:
> In the case of async update, modifications are done in place, i.e. in the
> current plane state, so the new_state is prepared and the new_state is
> cleaned up (instead of the old_state, unlike what happens in a
> normal sync update).
> To cleanup the old_f
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #26 from Matt Coffin ---
For reproducability, here's what I've been using. (I can reproduce this crash
on both the RADV and AMDVLK Vulkan implementations, and can reproduce it both
on top of sway 1.1 (wayland), and xfce4 (X11)).
* 5
https://bugs.freedesktop.org/show_bug.cgi?id=102322
--- Comment #82 from Matt Coffin ---
I am also experiencing this issue.
* Kernel: 5.1.3-arch2-1-ARCH
* LLVM 8.0.0
* AMDVLK (dev branch pulled 20190602)
* Mesa 19.0.4
* Card: XFX Radeon RX 590
I've seen this error, bug 105733, bug 105152, bug 1
On Fri, 2019-05-31 at 14:37 +0200, Neil Armstrong wrote:
> Devfreq runtime usage was made mandatory, thus making panfrost fail to probe
> on Amlogic S912 SoCs missin the "operating-points-v2" property.
> Make it optional again, leaving PM_DEVFREQ is selected by default.
>
> Fixes: f3617b449d ("drm
https://bugs.freedesktop.org/show_bug.cgi?id=107536
--- Comment #6 from Matt Coffin ---
I also tried to reproduce with amdgpu.vm_update_mode=3, but I can't get Xorg to
launch with that setting (KERNEL (not gpu) fails on a page request with that
setting on, but that might be due to a lower amt of
https://bugs.freedesktop.org/show_bug.cgi?id=107536
--- Comment #5 from Matt Coffin ---
I can reproduce this in a very very specific way (discovered while reproducing
bug 102322).
With the amdgpu driver, and RADV vulkan implementation, with DXVK 1.2.1,
running "House Flipper" from Steam (wine-st
On Mon, 2019-06-03 at 15:25 -0400, Lyude Paul wrote:
> On Thu, 2019-05-30 at 18:20 +, Li, Sun peng (Leo) wrote:
> > Hey, sorry for my late response!
> >
> > On 2019-05-16 5:40 p.m., Lyude Paul wrote:
> >
> > > >if (old_pdt != port->pdt && !port->input) {
> > > > @@ -1220,6 +1268,8 @@
On Thu, 2019-05-30 at 18:20 +, Li, Sun peng (Leo) wrote:
> Hey, sorry for my late response!
>
> On 2019-05-16 5:40 p.m., Lyude Paul wrote:
>
> > >if (old_pdt != port->pdt && !port->input) {
> > > @@ -1220,6 +1268,8 @@ static void drm_dp_add_port(struct
> > > drm_dp_mst_branch
> > > *m
https://bugs.freedesktop.org/show_bug.cgi?id=110777
--- Comment #4 from Anton Herzfeld ---
Is there anything else I can provide to support getting this fixed?
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel maili
https://bugs.freedesktop.org/show_bug.cgi?id=110422
--- Comment #1 from Pierre-Eric Pelloux-Prayer
---
Should be fixed on master by
https://gitlab.freedesktop.org/mesa/mesa/commit/4583f09caa5aef719a1eec282f24a86c789cbba6.
Can you test and confirm?
--
You are receiving this mail because:
You a
https://bugs.freedesktop.org/show_bug.cgi?id=110777
--- Comment #3 from ant...@gmx.de ---
reverting the following two patches fixes the boost in memory clocks but it
seems once mem clock has ramped up it's not going down again.
1.
Revert "drm/amd/powerplay: update soc boot and max level on vega10
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #17 from Marek Olšák ---
Created attachment 144431
--> https://bugs.freedesktop.org/attachment.cgi?id=144431&action=edit
possible fix
Hey fellas, can you test this patch? Thanks.
--
You are receiving this mail because:
You are t
https://bugs.freedesktop.org/show_bug.cgi?id=110777
--- Comment #2 from ant...@gmx.de ---
The issue is fully fixed on kernel master (currently I am using commit
460b48a0fefce25beb0fc0139e721c5691d65d7f) when reverting
drivers/gpu/drm/amd/powerplay/hwmgr/vega10_hwmgr.c back to the state it was
arou
https://bugs.freedesktop.org/show_bug.cgi?id=110831
Sylvain BERTRAND changed:
What|Removed |Added
Summary|[AMD TAHITI |[AMD TAHITI
|XT][a
https://bugs.freedesktop.org/show_bug.cgi?id=110831
--- Comment #3 from Sylvain BERTRAND ---
Created attachment 144430
--> https://bugs.freedesktop.org/attachment.cgi?id=144430&action=edit
xorg
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=110831
--- Comment #2 from Sylvain BERTRAND ---
Created attachment 144429
--> https://bugs.freedesktop.org/attachment.cgi?id=144429&action=edit
dmesg
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=110831
--- Comment #1 from Sylvain BERTRAND ---
The guilty commit is following. I reverted this commit on top of the current
amd-staging-drm-next (40cc64619a2580b26f924bcabdefd555e7831a14), my system is
then booting ok. It seems to do some specific pro
On Fri, May 31, 2019 at 02:52:46PM +0200, Ondřej Jirman wrote:
> Hello,
>
> On Mon, May 27, 2019 at 06:22:31PM +0200, megous via linux-sunxi wrote:
> > From: Ondrej Jirman
> >
> > This series implements support for Xunlong Orange Pi 3 board.
> >
> > Unfortunately, this board needs some small drive
On Sun, May 19, 2019 at 05:25:36PM +0800, Jitao Shi wrote:
> Change the method of frame rate calc which can get more accurate
> frame rate.
>
> data rate = pixel_clock * bit_per_pixel / lanes
> Adjust hfp_wc to adapt the additional phy_data
>
> if MIPI_DSI_MODE_VIDEO_BURST
> hfp_wc = hfp *
Hi Maxime, Joerg,
On Wed, 22 May 2019 at 21:27, Rob Herring wrote:
>
> On Tue, May 21, 2019 at 11:11 AM Clément Péron wrote:
> >
> > Hi,
> >
> > The Allwinner H6 has a Mali-T720 MP2 which should be supported by
> > the new panfrost driver. This series fix two issues and introduce the
> > dt-bind
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Cc: # v4.14+
Fixes: 224a4c970987 ("drm/msm: update cursors asynchronously through atomic")
Suggested-by: Boris Brezillon
Signed-off-by: Helen Koike
Acked-by: Rob Clark
---
Hell
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_a
Async update callbacks are expected to set the old_fb in the new_state
so prepare/cleanup framebuffers are balanced.
Calling drm_atomic_set_fb_for_plane() (which gets a reference of the new
fb and put the old fb) is not required, as it's taken care by
drm_mode_cursor_universal() when calling drm_a
In the case of a normal sync update, the preparation of framebuffers (be
it calling drm_atomic_helper_prepare_planes() or doing setups with
drm_framebuffer_get()) are performed in the new_state and the respective
cleanups are performed in the old_state.
In the case of async updates, the preparatio
In the case of async update, modifications are done in place, i.e. in the
current plane state, so the new_state is prepared and the new_state is
cleaned up (instead of the old_state, unlike what happens in a
normal sync update).
To cleanup the old_fb properly, it needs to be placed in the new_state
Hello,
I'm re-sending this series with the acked by in the msm patch and
updating the docs in the last patch, the rest is the same.
v3 link: https://patchwork.kernel.org/project/dri-devel/list/?series=91353
Thanks!
Helen
Changes in v4:
- add acked by tag
- update docs in atomic_async_update cal
On 5/7/19 5:18 PM, Sean Paul wrote:
> On Wed, Mar 13, 2019 at 09:20:26PM -0300, Helen Koike wrote:
>> In the case of a normal sync update, the preparation of framebuffers (be
>> it calling drm_atomic_helper_prepare_planes() or doing setups with
>> drm_framebuffer_get()) are performed in the new_s
https://bugs.freedesktop.org/show_bug.cgi?id=110831
Bug ID: 110831
Summary: [AMD TAHITI XT][amd-staging-drm-next] broken since
5.2-rc1 rebase
Product: DRI
Version: DRI git
Hardware: x86-64 (AMD64)
OS: Linux
On 03/06/2019 17:21, Colin King wrote:
> From: Colin Ian King
>
> The less than check for the variable num_lanes is always going to be
> false because the variable is a u32. Fix this by making num_lanes an
> int and also make loop index i an int too.
>
> Addresses-Coverity: ("Unsigned compared
On Mon, Jun 3, 2019 at 5:43 PM Eric Anholt wrote:
>
> Daniel Vetter writes:
>
> > On Fri, May 31, 2019 at 08:46:58AM -0700, Eric Anholt wrote:
> >> Boris Brezillon writes:
> >>
> >> > Right now, the BO is mapped as a cached region when ->vmap() is called
> >> > and the underlying object is not a
Daniel Vetter writes:
> On Fri, May 31, 2019 at 08:46:58AM -0700, Eric Anholt wrote:
>> Boris Brezillon writes:
>>
>> > Right now, the BO is mapped as a cached region when ->vmap() is called
>> > and the underlying object is not a dmabuf.
>> > Doing that makes cache management a bit more compli
On Thu, May 30, 2019 at 12:09 AM Alex Deucher wrote:
>
> Hi Dave, Daniel,
>
> New stuff for 5.3:
> - Add new thermal sensors for vega asics
> - Various RAS fixes
> - Add sysfs interface for memory interface utilization
> - Use HMM rather than mmu notifier for user pages
> - Expose xgmi topology vi
The GPM940B0 is a 3.0" 320x240 24-bit TFT LCD panel.
Signed-off-by: Paul Cercueil
Reviewed-by: Rob Herring
---
Notes:
v2: New patch
v3: Add Rob's ack
v4: No change
.../bindings/display/panel/giantplus,gpm940b0.txt| 12
1 file changed, 12 insertions(+)
c
The GiantPlus GPM940B0 is a 24-bit TFT panel where the RGB components
are transferred sequentially on a 8-bit bus.
Signed-off-by: Paul Cercueil
---
Notes:
v2: New patch
v3: No change
v4: Add only MEDIA_BUS_FMT_RGB888_3X8, as we don't have to care about
endianness
The GiantPlus GPM940B0 is a simple 3.0" 320x240 24-bit TFT panel.
Signed-off-by: Paul Cercueil
Tested-by: Artur Rojek
---
Notes:
v2: Change bus format to MEDIA_BUS_FMT_RGB888_3X8_BE
v3: No change
v4: Change bus format to MEDIA_BUS_FMT_RGB888_3X8
drivers/gpu/drm/panel/pan
The LS020B1DD01D is a 2.0" 240x160 16-bit TFT LCD panel.
Signed-off-by: Paul Cercueil
Reviewed-by: Rob Herring
---
Notes:
v2: New patch
v3: Add Rob's Reviewed-by
v4: Rebase on drm-misc-next (b232d4ed92ea)
.../bindings/display/panel/sharp,ls020b1dd01d.txt| 12
The Sharp LS020B1DD01D is a simple 2.0" 240x160 16-bit TFT panel.
Signed-off-by: Paul Cercueil
Tested-by: Artur Rojek
---
Notes:
v2: No change
v3: Add DRM_BUS_FLAG_SHARP_SIGNALS to the bus flags
v4: Rebase on drm-misc-next (b232d4ed92ea)
drivers/gpu/drm/panel/panel-simpl
Add the DRM_BUS_FLAG_SHARP_SIGNALS to the drm_bus_flags enum.
This flags can be used when the display must be driven with the
Sharp-specific signals SPL, CLS, REV, PS.
Signed-off-by: Paul Cercueil
---
Notes:
v3: New patch
v4: Rebase on drm-misc-next (b232d4ed92ea)
include/drm/drm
Add support for display panels built around the Novatek NT39016 display
controller, as found on e.g. the King Display KD035G6-54NT 24-bit
320x240 3.5" LCD panel which equips the GCW Zero open-source handheld
gaming console.
Signed-off-by: Paul Cercueil
Signed-off-by: Maarten ter Huurne
---
Note
The KD035G6-54NT is a 3.5" 320x240 24-bit TFT LCD panel.
Signed-off-by: Paul Cercueil
---
Notes:
v2: - Add an address to the panel node
- Add information about SPI properties
- Add information about the 'port' sub-node
.../panel/kingdisplay,kd035g6-54nt.txt| 42
Add a KMS driver for the Ingenic JZ47xx family of SoCs.
This driver is meant to replace the aging jz4740-fb driver.
This driver does not make use of the simple pipe helper, for the reason
that it will soon be updated to support more advanced features like
multiple planes, IPU integration for color
Add documentation for the devicetree bindings of the LCD controller present in
the JZ47xx family of SoCs from Ingenic.
Signed-off-by: Paul Cercueil
Tested-by: Artur Rojek
---
Notes:
v2: Remove ingenic,panel property.
v3: - Rename compatible strings from ingenic,jz47XX-drm to
ingen
On Mon, 2019-06-03 at 17:08 +0200, Daniel Vetter wrote:
> On Mon, Jun 03, 2019 at 11:50:53AM +0200, Michel Dänzer wrote:
> > On 2019-05-21 9:52 a.m., Daniel Vetter wrote:
> > > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen
> > > wrote:
> > > > On Mon, 20 May 2019 18:11:07 +0200
> > > > Daniel Ve
On Mon, Jun 03, 2019 at 05:34:11PM +0300, Pekka Paalanen wrote:
> On Mon, 3 Jun 2019 16:28:48 +0200
> Daniel Vetter wrote:
>
> > drm_atomic_set_fence_for_plane() contains the main discussion from a
> > driver pov, link to that from more places.
> >
> > Cc: Pekka Paalanen
> > Signed-off-by: Dan
On Mon, Jun 03, 2019 at 11:50:53AM +0200, Michel Dänzer wrote:
> On 2019-05-21 9:52 a.m., Daniel Vetter wrote:
> > On Tue, May 21, 2019 at 8:55 AM Pekka Paalanen wrote:
> >> On Mon, 20 May 2019 18:11:07 +0200
> >> Daniel Vetter wrote:
> >>
> >>> There's also a fairly easy fix for that -modesettin
https://bugs.freedesktop.org/show_bug.cgi?id=110674
--- Comment #34 from ant...@gmx.de ---
I think this is not just affecting Vega 20 but also Vega 10 is now stuck on
memclock pstate 0 (167MHz) since kernel 5.1.
I assume this is related to fclk and defclk
--
You are receiving this mail because:
On Fri, May 31, 2019 at 4:09 PM Jordan Crouse wrote:
>
> Before loading the zap shader we should ensure that the reserved memory
> region is big enough to hold the loaded file.
>
> Signed-off-by: Jordan Crouse
Reviewed-by: Jeffrey Hugo
> ---
>
> drivers/gpu/drm/msm/adreno/adreno_gpu.c | 8 +++
On Fri, May 31, 2019 at 3:46 AM Brian Masney wrote:
>
> The mdp5 drm/kms driver currently does not work on command-mode DSI
> panels due to 'vblank wait timed out' errors. This causes a latency
> of seconds, or tens of seconds in some cases, before content is shown
> on the panel. This hardware do
> It shouldn't be a problem to hook something else up to the IOMMU
> subsystem. Hopefully it's something that people are going to standardize
> on.
>
> > 3) The automatic attach of DMA domain is also causing a different
> >problem for us on the GPU side, preventing us from supporting per-
> >
Hi Daniel,
On Mon, 3 Jun 2019 19:50:18 +1000 Stephen Rothwell
wrote:
>
> On Mon, 3 Jun 2019 09:31:03 +0200 Daniel Vetter wrote:
> >
> > drm.git too I guess?
>
> No, I fetch that from git://git.freedesktop.org/ which seems to answer.
>
> > But yeah fd.o anongit keeled over over the w/e :-( A
On Mon, Jun 03, 2019 at 07:20:14AM -0700, Rob Clark wrote:
> On Mon, Jun 3, 2019 at 6:54 AM Thierry Reding
> wrote:
> >
> > On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote:
> > > On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote:
> > > >
> > > > On 03/06/2019 11:47, Rob Clark wrote:
>
On 6/3/19 3:24 AM, Daniel Vetter wrote:
> On Thu, May 30, 2019 at 05:04:20PM +0200, Christian König wrote:
>> Am 29.05.19 um 21:36 schrieb Daniel Vetter:
>>> On Wed, May 29, 2019 at 04:43:45PM +, Grodzovsky, Andrey wrote:
I don't, sorry.
>>> Should we fix that? Seems like you do plenty of
On Mon, 3 Jun 2019 16:28:48 +0200
Daniel Vetter wrote:
> drm_atomic_set_fence_for_plane() contains the main discussion from a
> driver pov, link to that from more places.
>
> Cc: Pekka Paalanen
> Signed-off-by: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc:
drm_atomic_set_fence_for_plane() contains the main discussion from a
driver pov, link to that from more places.
Cc: Pekka Paalanen
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_gem_framebuffer_h
https://bugs.freedesktop.org/show_bug.cgi?id=109835
rtent...@yandex.ru changed:
What|Removed |Added
Version|unspecified |19.1
--- Comment #4 from rtent...@y
From: Colin Ian King
The less than check for the variable num_lanes is always going to be
false because the variable is a u32. Fix this by making num_lanes an
int and also make loop index i an int too.
Addresses-Coverity: ("Unsigned compared against 0")
Fixes: ff5781634c41 ("drm/bridge: sii902x
On Mon, Jun 3, 2019 at 6:54 AM Thierry Reding wrote:
>
> On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote:
> > On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote:
> > >
> > > On 03/06/2019 11:47, Rob Clark wrote:
> > > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
> > > >>
> > > >
On Mon, Jun 03, 2019 at 06:20:57AM -0700, Rob Clark wrote:
> On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote:
> >
> > On 03/06/2019 11:47, Rob Clark wrote:
> > > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
> > >>
> > >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> > >>>
> > >>> So,
On Mon, May 20, 2019 at 02:33:16PM +0530, Jagan Teki wrote:
> Allwinner MIPI DSI controllers are supplied with SoC
> DSI power rails via VCC-DSI pin.
>
> Add support for this supply pin by adding voltage
> regulator handling code to MIPI DSI driver.
>
> Tested-by: Merlijn Wajer
> Signed-off-by: Ja
On Mon, Jun 3, 2019 at 2:25 PM Pierre Yves MORDRET
wrote:
>
> Hi all,
>
> Many thanks for your valuable support and answers.
>
> Since Dumb mmap is for buffer created using dumb_create ioctl we won't use it
> anymore. In place a mmap/ummap is called with DMA Buf FD.
> After some tests it seems wor
On Mon, Jun 03, 2019 at 12:14:27PM +0100, Robin Murphy wrote:
> On 03/06/2019 11:47, Rob Clark wrote:
> > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
> > >
> > > On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> > > >
> > > > On Fri, May 10, 2019 at 7:35 AM Rob Clark wrote:
> > > > >
>
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #16 from Richard Thier ---
Created attachment 144427
--> https://bugs.freedesktop.org/attachment.cgi?id=144427&action=edit
Simple diff/patch to test the issue
See attached diff/patch for what I am trying as a quickfix and testing
https://bugs.freedesktop.org/show_bug.cgi?id=110823
--- Comment #3 from Chris Wilson ---
(In reply to Martin Peres from comment #0)
> Hi, it looks like amdgpu's userptrs are now broken:
>
> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6179/fi-kbl-8809g/
> igt@amdgpu_amd_ba...@userptr.html
>
https://bugs.freedesktop.org/show_bug.cgi?id=110823
Chris Wilson changed:
What|Removed |Added
Component|DRM/AMDgpu |IGT
--- Comment #2 from Chris Wilson --
Hi Dave & Daniel,
Missed last week's window of opportunity due to trouble getting
CI results for Icelake. So this is against -rc2 still to avoid
re-doing the GVT pull third time.
Just a single Icelake W/A for i915. For GVT a fix for recently
seen arbitrary DMA map fault and more enforcement fixes
On Mon, Jun 3, 2019 at 3:32 AM Daniel Vetter wrote:
>
> On Sun, Jun 02, 2019 at 08:40:08PM -0400, Ilia Mirkin wrote:
> > This series improves the pattern generation logic to support additional
> > formats, as well as a new "gradient" pattern (see patch comments on why
> > I found it useful).
> >
>
On Mon, Jun 3, 2019 at 4:14 AM Robin Murphy wrote:
>
> On 03/06/2019 11:47, Rob Clark wrote:
> > On Sun, Jun 2, 2019 at 11:25 PM Tomasz Figa wrote:
> >>
> >> On Mon, Jun 3, 2019 at 4:40 AM Rob Clark wrote:
> >>>
> >>> So, another case I've come across, on the display side.. I'm working
> >>> on
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #15 from Richard Thier ---
It seems similar issues not only affect me then...
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #14 from Richard Thier ---
Now seeing that the commit diff is actually small, I can put some printf logs
in place to see what is going on and where the code ends up.
--
You are receiving this mail because:
You are the assignee for
Dropped static functions from kernel documentation.
v2: Dropped the comments altogether for static functions,
as the definitions seems self explanatory.
Suggested-by: Daniel Vetter
Signed-off-by: Uma Shankar
---
drivers/video/hdmi.c | 30 --
1 file changed, 30 delet
Fixes the following warnings:
./include/drm/drm_mode_config.h:841: warning: Incorrect use of
kernel-doc format: * hdr_output_metadata_property: Connector
property containing hdr
./include/drm/drm_mode_config.h:918: warning: Function parameter or member
'hdr_output_metadata_property' not d
This series adds DRM UAPI header structure documentation to kernel
docs. Fixes issues with existing structure documentation in drm
uapi header.
This also fixes warnings in HDR doc and addresses suggestions from
Daniel Vetter.
v2: 2 patches from v1 are merged. This series version adds remaining
on
Add a new section for UAPI structure and helper definitions
in kernel docbook.
Suggested-by: Daniel Vetter
Signed-off-by: Uma Shankar
---
Documentation/gpu/drm-uapi.rst | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
i
1 - 100 of 158 matches
Mail list logo
