On 28/05/2019 13:18, Tony Lindgren wrote:
My board is x15 rev A3, attached to AM5 EVM. I've also attached my kernel
config.
Strange that this is not affecting other x15? I think timer12 would
be blocked on HS devices though?
Seems that the kernel config affects. omap2plus_defconfig boots ok.
On Wed, May 29, 2019 at 9:35 AM CK Hu wrote:
>
> I think mtk_dsi_destroy_conn_enc() has much thing to do and I would like
> you to do more. You could refer to [2] for complete implementation.
>
> [2]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/exynos/
Hi, Hsin-Yi:
On Wed, 2019-05-29 at 14:08 +0800, Hsin-Yi Wang wrote:
> On Wed, May 29, 2019 at 1:58 PM CK Hu wrote:
> >
> > Hi, Hsin-Yi:
> >
> > On Mon, 2019-05-27 at 12:50 +0800, Hsin-Yi Wang wrote:
> > > There is no clk_prepare() called in mtk_drm_crtc_reset(), when unbinding
> > > drm device, m
Am 28.05.19 um 19:23 schrieb Lendacky, Thomas:
On 5/28/19 12:05 PM, Thomas Hellstrom wrote:
On 5/28/19 7:00 PM, Lendacky, Thomas wrote:
On 5/28/19 11:32 AM, Koenig, Christian wrote:
Am 28.05.19 um 18:27 schrieb Thomas Hellstrom:
On Tue, 2019-05-28 at 15:50 +, Lendacky, Thomas wrote:
On 5
https://bugs.freedesktop.org/show_bug.cgi?id=110787
--- Comment #2 from Pierre-Eric Pelloux-Prayer
---
Thanks for your bug report.
It seems to be the same bug than
https://bugs.freedesktop.org/show_bug.cgi?id=110721
Should be fixed on master - can you try it?
--
You are receiving this mail
https://bugs.freedesktop.org/show_bug.cgi?id=106302
Pierre-Eric Pelloux-Prayer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolutio
Hi, Hsin-Yi:
On Wed, 2019-05-29 at 15:06 +0800, Hsin-Yi Wang wrote:
> On Wed, May 29, 2019 at 9:35 AM CK Hu wrote:
>
> >
> > I think mtk_dsi_destroy_conn_enc() has much thing to do and I would like
> > you to do more. You could refer to [2] for complete implementation.
> >
> > [2]
> > https://gi
mmu_ops->unmap() will fail when called on a BO that has not been
previously mapped, and the error path in panfrost_ioctl_create_bo()
can call drm_gem_object_put_unlocked() (which in turn calls
panfrost_mmu_unmap()) on a BO that has not been mapped yet.
Keep track of the mapped/unmapped state to av
On Wed, 2019-05-29 at 09:50 +0200, Christian König wrote:
> Am 28.05.19 um 19:23 schrieb Lendacky, Thomas:
> > On 5/28/19 12:05 PM, Thomas Hellstrom wrote:
> > > On 5/28/19 7:00 PM, Lendacky, Thomas wrote:
> > > > On 5/28/19 11:32 AM, Koenig, Christian wrote:
> > > > > Am 28.05.19 um 18:27 schrieb
This completes Emil's series of removing DRM_UNLOCKED from modern
drivers. It's entirely cargo-culted since we ignore it on
non-DRIVER_LEGACY drivers since:
commit ea487835e8876abf7ad909636e308c801a2bcda6
Author: Daniel Vetter
Date: Mon Sep 28 21:42:40 2015 +0200
drm: Enforce unlocked ioct
On 28/05/2019 13.32, Tomi Valkeinen wrote:
> On 28/05/2019 13:18, Tony Lindgren wrote:
>> Strange that this is not affecting other x15? I think timer12 would
>> be blocked on HS devices though?
>
> I don't know... I can't believe my x15 would be unique =). Can it be
> something in the kernel con
On Wed, May 29, 2019 at 08:23:17AM +0200, Linus Walleij wrote:
> On Wed, May 29, 2019 at 3:17 AM Brian Masney wrote:
>
> > It's in low speed mode but its usable.
>
> How low speed is that?
I don't have a number but my test with 4.17 is to run
'cat /etc/passwd > /dev/tty1' over a serial cable. T
When building the docs with make htmldocs:
./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_pr
Hi, Hsin-Yi:
On Mon, 2019-05-27 at 12:50 +0800, Hsin-Yi Wang wrote:
> Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will
> trigger master(mtk_drm)'s .unbind(), and currently mtk_drm's unbind
> won't actually unbind components. During the next bind,
> mtk_drm_kms_init() is called,
Expose performance counters through 2 driver specific ioctls: one to
enable/disable the perfcnt block, and one to dump the counter values.
There are discussions to expose global performance monitors (those
counters that can't be retrieved on a per-job basis) in a consistent
way, but this is likely
We plan to expose performance counters through 2 driver specific
ioctls until there's a solution to expose them in a generic way.
In order to be able to deprecate those ioctls when this new
infrastructure is in place we add an unsafe module parameter that
will keep those ioctls hidden unless it's s
Hello,
This a new version of the panfrost perfcnt series, this time exposing
this functionality through 2 ioctls instead of the debugfs approach
used in v2.
I also went for Emil's suggestion to expose those ioctls only when
the unstable_iocts unsafe param is set to true. This way, I hope we'll
be
So they can be used from other files.
Signed-off-by: Boris Brezillon
---
Changes in v3:
- None
Changes in v2:
- None
---
drivers/gpu/drm/panfrost/panfrost_gpu.c | 3 ---
drivers/gpu/drm/panfrost/panfrost_regs.h | 3 +++
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu
All models with an ID >= 0x1000 are Bifrost GPUs for now (might change
with new gens).
Suggested-by: Alyssa Rosenzweig
Signed-off-by: Boris Brezillon
---
Changes in v3:
* New patch
---
drivers/gpu/drm/panfrost/panfrost_device.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gp
On Thu, Apr 18, 2019 at 5:00 PM Andrey Grodzovsky
wrote:
>
> From: Christian König
>
> We now destroy finished jobs from the worker thread to make sure that
> we never destroy a job currently in timeout processing.
> By this we avoid holding lock around ring mirror list in drm_sched_stop
> which
On Thu, Dec 27, 2018 at 8:28 PM Andrey Grodzovsky
wrote:
>
> Decauple sched threads stop and start and ring mirror
> list handling from the policy of what to do about the
> guilty jobs.
> When stoppping the sched thread and detaching sched fences
> from non signaled HW fenes wait for all signaled
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #3 from Richard Thier ---
When doing an strace this is what I am getting:
...
ioctl(6, DRM_IOCTL_RADEON_GEM_CREATE, 0xbfafd880) = 0 <0.68>
> [vdso]() [0x891]
ioctl(6, DRM_IOCTL_RADEON_CS, 0xafe2404c) = 0 <0.000102>
>
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,
>> >>
>> >> I've a workstation which has internal VGA that is detected as AST 2400
https://bugs.freedesktop.org/show_bug.cgi?id=110787
--- Comment #3 from Manuel Vögele ---
Can confirm this is fixed on master.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesk
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: unbind components in mtk_drm_unbind()
drm: mediatek: call drm_atomic_helper_shutdown
num_pipes is used for mutex created in mtk_drm_crtc_create(). If we
don't clear num_pipes count, when rebinding driver, the count will
be accumulated. From mtk_disp_mutex_get(), there can only be at most
10 mutex id. Clear this number so it starts from 0 in every rebind.
Fixes: 119f5173628a ("drm/
Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will
trigger master(mtk_drm)'s .unbind(), and currently mtk_drm's unbind
won't actually unbind components. During the next bind,
mtk_drm_kms_init() is called, and the components are added back.
.unbind() should call mtk_drm_kms_deinit
shutdown all CRTC when unbinding drm driver.
Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
Signed-off-by: Hsin-Yi Wang
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
b/drivers/
https://bugs.freedesktop.org/show_bug.cgi?id=110790
Andre Klapper changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #4 from Richard Thier ---
Btw what is a "slab buffer" or "slab"? It bugs me and I see this everywhere in
the code too...
--
You are receiving this mail because:
You are the assignee for the bug._
https://bugs.freedesktop.org/show_bug.cgi?id=110790
Andre Klapper changed:
What|Removed |Added
Group||spam
Version|DRI git
https://bugs.freedesktop.org/show_bug.cgi?id=110781
Richard Thier changed:
What|Removed |Added
Severity|normal |major
--
You are receiving this mail b
The dma_required_mask might overestimate the memory size, or might not match
up with the CMA area placement for other reasons. Get the information about
CMA area placement directly from CMA where it is available, but keep the
dma_required_mask as an approximate fallback for architectures where CMA
Make them usable in modules. Some drivers want to know where their
device CMA area is located to make better decisions about the DMA
programming.
Signed-off-by: Lucas Stach
---
mm/cma.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/cma.c b/mm/cma.c
index 3340ef34c154..191c89bf038d 100
On Fri, 2019-03-22 at 13:05 +0800, Hsin-Yi Wang wrote:
> On Fri, Mar 22, 2019 at 9:21 AM CK Hu wrote:
> >
> > Hi, Hsin-yi:
> >
> > On Thu, 2019-03-21 at 22:09 +0800, Hsin-Yi Wang wrote:
> > > On Thu, Mar 21, 2019 at 9:46 AM CK Hu wrote:
> > > >
> > > > Hi, Hsin-yi:
> > > >
> > > > On Thu, 2019-03
The MIPI DSI controller in Allwinner A64 is similar to A33.
But unlike A33, A64 doesn't have DSI_SCLK gating so it is valid
to with separate compatible for A64 on the same driver.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
Tested-by: Merlijn Wajer
---
Documentation/devicetree/bindings
The MIPI DSI PHY controller on Allwinner A64 is similar
on the one on A31.
Add A64 compatible and append A31 compatible as fallback.
Signed-off-by: Jagan Teki
Reviewed-by: Rob Herring
---
Documentation/devicetree/bindings/display/sunxi/sun6i-dsi.txt | 1 +
1 file changed, 1 insertion(+)
diff
This is v9 version for Allwinner A64 MIPI-DSI support
and here is the previous version set[1].
This depends on dsi host controller fixes which were
supported in this series[2].
All these changes are tested in Allwinner A64 with
2, 4 lanes devices and whose pixel clocks are 27.5 MHz,
30MHz, 55MHz
Amarula A64-Relic board by default bound with Techstar TS8550B
MIPI-DSI panel, add support for it.
DSI panel connected via board DSI port with,
- DLDO1 as VCC-DSI supply
- DLDO2 as VCC supply
- DLDO2 as IOVCC supply
- PD24 gpio for reset pin
- PD23 gpio for backlight enable pin
Signed-off-by: Jag
As per the user manual, look like mod clock is not mandatory
for all Allwinner MIPI DSI controllers, it is connected to
CLK_DSI_SCLK for A31 and not available in A64.
So add has_mod_clk quirk and process the clk accordingly.
Tested-by: Merlijn Wajer
Signed-off-by: Jagan Teki
---
drivers/gpu/dr
Feiyang FY07024DI26A30-D MIPI_DSI panel is desiged to attach with
DSI connector on pine64 boards, enable the same for pine64 LTS.
DSI panel connected via board DSI port with,
- DLDO1 as VCC-DSI supply
- DC1SW as AVDD supply
- DLDO2 as DVDD supply
- PD24 gpio for reset pin
- PH10 gpio for backlight
The MIPI DSI controller in Allwinner A64 is similar to A33.
But unlike A33, A64 doesn't have DSI_SCLK gating so add compatible
for Allwinner A64 with uninitialized has_mod_clk driver.
Signed-off-by: Jagan Teki
Tested-by: Merlijn Wajer
---
drivers/gpu/drm/sun4i/sun6i_mipi_dsi.c | 7 +++
1 f
Add MIPI DSI pipeline for Allwinner A64.
- dsi node, with A64 compatible since it doesn't support
DSI_SCLK gating unlike A33
- dphy node, with A64 compatible with A33 fallback since
DPHY on A64 and A33 is similar
- finally, attach the dsi_in to tcon0 for complete MIPI DSI
Signed-off-by: Jagan
This patch add support for Bananapi S070WV20-CT16 DSI panel to
BPI-M64 board.
DSI panel connected via board DSI port with,
- DLDO1 as VCC-DSI supply
- DCDC1 as VDD supply
- PD7 gpio for lcd enable pin
- PD6 gpio for lcd reset pin
- PD5 gpio for backlight enable pin
Signed-off-by: Jagan Teki
---
Microtech MTF050FHDI-03 is 1080x1920, 4-lane MIPI DSI LCD panel which
has inbuilt NT35596 IC chip.
DSI panel connected to board via 39-pin FPC port with,
- DLDO1 as VCC-DSI supply
- DLDO2 as DVDD supply
- DC1SW as AVDD supply
- DC1SW as AVEE supply
- PD24 gpio for reset pin
- PH10 gpio for backlig
From: Ville Syrjälä
Give the "DFP 1.x" bit a proper name, and clean up the rest
of the bits defines as well.
Cc: Mario Kleiner
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_edid.c | 2 +-
include/drm/drm_edid.h | 32 +---
2 files changed, 18 insertions(
From: Ville Syrjälä
From VESA EDID implementation guide v1.0:
"For EDID version 1 revision 2 or earlier data structures when offset 14h
bit 7 is set to one, the value of bits 6-0 are undefined, and therefore
cannot be interpreted to mean anything."
And since EDID 1.4 redefines that bit let's c
We should check "request[n]" instead of just "request".
Fixes: 78e41ddd2198 ("drm/i915: Apply an execution_mask to the virtual_engine")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/i915/gt/selftest_lrc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/
Hello Linus Walleij,
The patch 5fc537bfd000: "drm/mcde: Add new driver for ST-Ericsson
MCDE" from May 24, 2019, leads to the following static checker
warning:
drivers/gpu/drm/mcde/mcde_dsi.c:917 mcde_dsi_bind()
warn: 'bridge' isn't an ERR_PTR
drivers/gpu/drm/mcde/mcde_dsi.c
88
Quoting Dan Carpenter (2019-05-29 12:03:55)
> We should check "request[n]" instead of just "request".
>
> Fixes: 78e41ddd2198 ("drm/i915: Apply an execution_mask to the
> virtual_engine")
> Signed-off-by: Dan Carpenter
Oops.
Reviewd-by: Chris Wilson
-Chris
_
Hi Dave, Daniel,
please consider merging these fixes for v5.2.
regards
Philipp
The following changes since commit cd6c84d8f0cdc911df435bb075ba22ce3c605b07:
Linux 5.2-rc2 (2019-05-26 16:49:19 -0700)
are available in the Git repository at:
git://git.pengutronix.de/git/pza/linux tags/imx-drm
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,
> >>
> >> I've a workstation which has internal VGA that is detected as AST 2400 and
> >> with it EDID has been always quite flaky (e
detatch panel in mtk_dsi_destroy_conn_enc(), since .bind will try to
attach it again.
Fixes: 2e54c14e310f ("drm/mediatek: Add DSI sub driver")
Signed-off-by: Hsin-Yi Wang
---
change log v1->v2:
* mipi_dsi_host_unregister() should be fixed in another patch on the list.
---
drivers/gpu/drm/mediate
* Tomi Valkeinen [190529 07:06]:
> On 28/05/2019 13:18, Tony Lindgren wrote:
>
> > > My board is x15 rev A3, attached to AM5 EVM. I've also attached my kernel
> > > config.
> >
> > Strange that this is not affecting other x15? I think timer12 would
> > be blocked on HS devices though?
>
> Seems
Make sure the clock level enforced is within the allowed
ranges in case PP_SCLK and PP_MCLK.
Signed-off-by: Young Xiao <92siuy...@gmail.com>
---
drivers/gpu/drm/amd/powerplay/hwmgr/vega12_hwmgr.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr
The ETM0700G0DH6 is currently documented as using edt,etm070080dh6
compatible string, however the Linux kernel driver as well as a
couple of DTs use edt,etm0700g0dh6 compatible string. Add it into
the documentation.
Signed-off-by: Marek Vasut
Cc: Rob Herring
Cc: Jan Tuerk
Cc: Thierry Reding
Cc
Hello Linus Walleij,
The patch 5fc537bfd000: "drm/mcde: Add new driver for ST-Ericsson
MCDE" from May 24, 2019, leads to the following static checker
warning:
drivers/gpu/drm/mcde/mcde_drv.c:488 mcde_probe()
error: uninitialized symbol 'match'.
drivers/gpu/drm/mcde/mcde_drv.c
Hello Linus Walleij,
This is a semi-automatic email about new static checker warnings.
The patch 5fc537bfd000: "drm/mcde: Add new driver for ST-Ericsson
MCDE" from May 24, 2019, leads to the following Smatch complaint:
drivers/gpu/drm/mcde/mcde_dsi.c:908 mcde_dsi_bind()
error: we previo
We never set "vblank" to "false".
Current versions of GCC will initialize it to zero automatically at
certain optimization levels so that's probably why this didn't show up
in testing.
Fixes: 5fc537bfd000 ("drm/mcde: Add new driver for ST-Ericsson MCDE")
Signed-off-by: Dan Carpenter
---
drivers
https://bugs.freedesktop.org/show_bug.cgi?id=110793
vijay...@kosoft.co changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://bugs.freedesktop.org/show_bug.cgi?id=110793
Andre Klapper changed:
What|Removed |Added
Group||spam
Component|DRM/other
When a signal arrives we should return immediately for
handling it and not try other placements first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm
We are already doing this for DMA-buf imports and also for
amdgpu VM BOs for quite a while now.
If this doesn't run into any problems we are probably going
to stop removing BOs from the LRU altogether.
v2: drop BUG_ON from ttm_bo_add_to_lru
Signed-off-by: Christian König
---
.../gpu/drm/amd/am
Move BOs which are currently in a lower domain to the new
LRU before allocating backing space while validating.
This makes sure that we always have enough entries on the
LRU to allow for other processes to wait for an operation
to complete.
v2: generalize the test
v3: fix rebase error
Signed-off
We tried this once before, but that turned out to be more
complicated than thought. With all the right prerequisites
it looks like we can do this now.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 127 ++-
1 file changed, 66 insertions(+), 61 d
The messages about amdgpu_cs_list_validate are duplicated because the
caller will complain into the logs as well and we can also get
interrupted by a signal here.
Also fix the the caller to not report -EAGAIN from validation.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_
And only move them in on validation. This allows for better control
when multiple processes are fighting over those resources.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/am
This avoids OOM situations when we have lots of threads
submitting at the same time.
v3: apply this to the whole driver, not just CS
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_csa.c| 2 +-
drivers/gpu/drm/amd/amdgp
From: Chunming Zhou
add ticket for display bo, so that it can preempt busy bo.
v2: fix stupid rebase error
Change-Id: I9f031cdcc8267de00e819ae303baa0a52df8ebb9
Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 21 ++-
If drivers don't prefer a system memory placement
they should not but it into the placement list first.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gp
BOs on the LRU might be blocked during command submission
and cause OOM situations.
Avoid this by blocking for the first busy BO not locked by
the same ticket as the BO we are searching space for.
v10: completely start over with the patch since we didn't
handled a whole bunch of corner cases
Quoting Chris Wilson (2019-05-29 12:06:57)
> Quoting Dan Carpenter (2019-05-29 12:03:55)
> > We should check "request[n]" instead of just "request".
> >
> > Fixes: 78e41ddd2198 ("drm/i915: Apply an execution_mask to the
> > virtual_engine")
> > Signed-off-by: Dan Carpenter
>
> Oops.
> Reviewd-b
Hi Tomeu, Rob,
On 28/05/2019 08:03, Tomeu Vizoso wrote:
Robin, Steven,
would you or someone else at Arm be able to run the IGT tests [0] on
5.2-rc2 with this patch on top?
I don't have any hw with Bifrost and am not planning to work on the
userspace any time soon, but I think it would be good
On 5/13/19 17:47, Sean Paul wrote:
> On Wed, May 08, 2019 at 01:42:12PM -0700, Rob Clark wrote:
>> From: Jayant Shekhar
>>
>> The interconnect framework is designed to provide a
>> standard kernel interface to control the settings of
>> the interconnects on a SoC.
>>
>> The interconnect API uses a
On 2019/05/29, Dave Airlie wrote:
> On Wed, 29 May 2019 at 02:47, Emil Velikov wrote:
> >
> > On 2019/05/28, Koenig, Christian wrote:
> > > Am 28.05.19 um 18:10 schrieb Emil Velikov:
> > > > On 2019/05/28, Daniel Vetter wrote:
> > > >> On Tue, May 28, 2019 at 10:03 AM Koenig, Christian
> > > >> w
Patch #1,#5,#6,#8,#9,#10 are Reviewed-by: Chunming Zhou
Patch #2,#3,#4 are Acked-by: Chunming Zhou
-David
> -Original Message-
> From: dri-devel On Behalf Of
> Christian K?nig
> Sent: Wednesday, May 29, 2019 8:27 PM
> To: dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
>
Am 29.05.19 um 15:03 schrieb Emil Velikov:
> On 2019/05/29, Dave Airlie wrote:
>> On Wed, 29 May 2019 at 02:47, Emil Velikov wrote:
>>> On 2019/05/28, Koenig, Christian wrote:
Am 28.05.19 um 18:10 schrieb Emil Velikov:
> On 2019/05/28, Daniel Vetter wrote:
>> On Tue, May 28, 2019 at 1
https://bugs.freedesktop.org/show_bug.cgi?id=110787
Alex Deucher changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=110721
Alex Deucher changed:
What|Removed |Added
CC||deve...@manuel-voegele.de
--- Comment #1
https://bugs.freedesktop.org/show_bug.cgi?id=105684
--- Comment #46 from Jörn Frenzel ---
Hi Michel,
sorry for the long delay.
What is the reason for your opinion? It really seems like the same issue for
me, but may be i'm wrong.
Same thing with manjaro linux and kernel 4.19.x - oops.
We buil
Hi Christian,
The series is:
Tested-by: Pierre-Eric Pelloux-Prayer
Pierre-Eric
On 29/05/2019 14:27, Christian König wrote:
> This avoids OOM situations when we have lots of threads
> submitting at the same time.
>
> v3: apply this to the whole driver, not just CS
>
> Signed-off-by: Christ
On Tue, May 21, 2019 at 01:08:28PM +0200, Thomas Zimmermann wrote:
> Replacing drm_gem_vram_push_to_system() moves policy from drivers back
> to the memory manager. Now, unused BOs are only evicted when the space
> is required.
>
> The lock/unlock-renaming patch aligns the interface with other nam
On Wed, May 29, 2019 at 7:02 AM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> From VESA EDID implementation guide v1.0:
> "For EDID version 1 revision 2 or earlier data structures when offset 14h
> bit 7 is set to one, the value of bits 6-0 are undefined, and therefore
> cannot be interprete
>-Original Message-
>From: Daniel Vetter [mailto:dan...@ffwll.ch]
>Sent: Wednesday, May 29, 2019 3:13 PM
>To: Shankar, Uma
>Cc: intel-gfx ; dri-devel de...@lists.freedesktop.org>; Daniele Castagna ;
>jo...@kwiboo.se; Sean Paul ; Sharma, Shashank
>; Syrjala, Ville
>Subject: Re: [Intel-gf
On Wed, May 29, 2019 at 1:32 PM Dan Carpenter wrote:
> drivers/gpu/drm/mcde/mcde_drv.c:488 mcde_probe()
> error: uninitialized symbol 'match'.
(...)
>480 while ((d = bus_find_device(&platform_bus_type, p,
> drv,
>481
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
From: Colin Ian King
Currently mask is not initialized and so data is being bit-wise or'd into
a garbage value. Fix this by inintializing mask to zero.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: 1ac159e23c2c ("drm/i915: Expand subslice mask")
Signed-off-by: Colin Ian King
---
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 49e7d07..c1058ee 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drive
On Wed, May 29, 2019 at 08:13:50PM +0530, Uma Shankar wrote:
> 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: warn
On Wed, May 29, 2019 at 4:28 AM Brian Masney wrote:
>
> On Tue, May 28, 2019 at 08:53:49PM -0600, Jeffrey Hugo wrote:
> > On Tue, May 28, 2019 at 8:46 PM Brian Masney wrote:
> > >
> > > On Tue, May 28, 2019 at 07:42:19PM -0600, Jeffrey Hugo wrote:
> > > > > > Do you know if the nexus 5 has a vide
From: Colin Ian King
Currently subslice_mask is not initialized and so data is being
bit-wise or'd into a garbage value. Fix this by inintializing
subslice_mask to zero.
Addresses-Coverity: ("Uninitialized scalar variable")
Fixes: 1ac159e23c2c ("drm/i915: Expand subslice mask")
Signed-off-by: Co
On Fri, May 24, 2019 at 03:48:51PM +0530, Jagan Teki wrote:
> On Fri, May 24, 2019 at 2:04 AM Maxime Ripard
> wrote:
> >
> > On Mon, May 20, 2019 at 02:33:08PM +0530, Jagan Teki wrote:
> > > According to "DRM kernel-internal display mode structure" in
> > > include/drm/drm_modes.h the current dri
On Wed, 29 May 2019, Colin King wrote:
> From: Colin Ian King
>
> Currently mask is not initialized and so data is being bit-wise or'd into
> a garbage value. Fix this by inintializing mask to zero.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: 1ac159e23c2c ("drm/i915: Expand
On Wed, May 29, 2019 at 4:16 PM Uma Shankar wrote:
>
> 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: Fu
On Wed, 29 May 2019, Colin King wrote:
> From: Colin Ian King
>
> Currently subslice_mask is not initialized and so data is being
> bit-wise or'd into a garbage value. Fix this by inintializing
> subslice_mask to zero.
>
> Addresses-Coverity: ("Uninitialized scalar variable")
> Fixes: 1ac159e23c2
On Wed, May 29, 2019 at 3:59 PM Shankar, Uma wrote:
>
>
>
> >-Original Message-
> >From: Daniel Vetter [mailto:dan...@ffwll.ch]
> >Sent: Wednesday, May 29, 2019 3:13 PM
> >To: Shankar, Uma
> >Cc: intel-gfx ; dri-devel >de...@lists.freedesktop.org>; Daniele Castagna ;
> >jo...@kwiboo.se;
On 29/05/2019 16:04, Jani Nikula wrote:
> On Wed, 29 May 2019, Colin King wrote:
>> From: Colin Ian King
>>
>> Currently subslice_mask is not initialized and so data is being
>> bit-wise or'd into a garbage value. Fix this by inintializing
>> subslice_mask to zero.
>>
>> Addresses-Coverity: ("Uni
From: Colin Ian King
The pointer dev is set to null yet it is being dereferenced when
checking dev->dqm->sched_policy. Fix this by performing the check
on dev->dqm->sched_policy after dev has been assigned and null
checked. Also remove the redundant null assignment to dev.
Addresses-Coverity:
On Tue, 21 May 2019 at 18:11, Clément Péron wrote:
>
[snip]
> [ 345.204813] panfrost 180.gpu: mmu irq status=1
> [ 345.209617] panfrost 180.gpu: Unhandled Page fault in AS0 at VA
> 0x02400400
>From what I can see here, 0x02400400 points to the first byte
of the first sub
https://bugs.freedesktop.org/show_bug.cgi?id=110658
--- Comment #5 from Alexander Mezin ---
(In reply to Timothy Arceri from comment #3)
> Are you able to test with llvm 9?
I won't have time for that until weekend
(In reply to Timothy Arceri from comment #4)
> I've run it on llvm 8 and mesa 19
1 - 100 of 199 matches
Mail list logo
