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 assume that it's related to the
> vblank events not working properly?
They are only waiting for 50 ms before timing out, I raised it
to 100ms in the -next kernel. I'm still
On Tue, 28 May 2019 16:01:15 +0200
Boris Brezillon wrote:
> On Tue, 28 May 2019 15:53:48 +0200
> Boris Brezillon wrote:
>
> > Hi Steve,
> >
> > On Thu, 16 May 2019 17:21:39 +0100
> > Steven Price wrote:
> >
> >
> > > >> +static void panfrost_perfcnt_setup(struct panfrost_device *pfdev)
>
On Wed, May 29, 2019 at 08:51:21AM +0200, Boris Brezillon wrote:
> 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 complicated (you'd need
> to call dma_map/unmap_sg() on the ->sgt
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]
>
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
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, mtk_drm_crtc_destroy() will be triggered, and the clocks will
> > be disabled and
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 complicated (you'd need
to call dma_map/unmap_sg() on the ->sgt field everytime the BO is about
to be passed to the GPU/CPU), so let's map
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,
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #2 from Rolf ---
Also, the install scrip fails without rolling back anything and leaving the
system in a half-baked state. The supplied uninstall fails because amdgpu-core
isn't installed yet. Since only 18.04 is supported, the
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-5.3-wip
head: 66ca5577c50a68d89e0e9ad7a2eba697911622c9
commit: ceb7ee86fbedcf20e978b7e41dfce5b144f71dfa [207/222] drm/scheduler:
rework job destruction
config: sparc64-allmodconfig (attached as .config)
compiler: sparc64-linux-gcc
Hi, Hsin-Yi:
On Wed, 2019-05-29 at 18:25 +0800, Hsin-Yi Wang wrote:
> 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.
[ Upstream commit bc29d3a69d4c1bd1a103e8b3c1ed81b807c1870b ]
The call to of_find_matching_node_and_match returns a node pointer with
refcount incremented thus it must be explicitly decremented after the
last usage.
Detected by coccinelle with the following warnings:
Hi, Hsin-Yi:
On Wed, 2019-05-29 at 18:25 +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
[ Upstream commit 6cd5235c3135ea84b32469ea51b2aae384eda8af ]
The call to of_get_child_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
* Tony Lindgren [190529 08:11]:
> * 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
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #3 from Rolf ---
If anyone else finds themselves in this fix by installing this driver, the only
way to get apt-get working again is to forcefully remove all of the files
using:
sudo dpkg --force-all -P [package name]
Here is the
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #4 from Alex Deucher ---
The packaged drivers only support the Linux distros listed.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
[ Upstream commit bc29d3a69d4c1bd1a103e8b3c1ed81b807c1870b ]
The call to of_find_matching_node_and_match returns a node pointer with
refcount incremented thus it must be explicitly decremented after the
last usage.
Detected by coccinelle with the following warnings:
https://bugs.freedesktop.org/show_bug.cgi?id=110795
--- Comment #5 from Rolf ---
Yet it half-way installs on 19.04 without a check, and your download page does
not include any warning of what it will do to your system if it's not 18.04. In
fact, the sub heading lists 18.04.2, so is that the only
Hi, Hsin-Yi:
On Wed, 2019-05-29 at 18:25 +0800, Hsin-Yi Wang wrote:
> shutdown all CRTC when unbinding drm driver.
>
Reviewed-by: CK Hu
> Fixes: 119f5173628a ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
> Signed-off-by: Hsin-Yi Wang
> ---
>
On Tue, May 28, 2019 at 4:53 PM CK Hu wrote:
> I think we've already discussed in [1]. I need a reason to understand
> this is hardware behavior or software bug. If this is a software bug, we
> need to fix the bug and code could be symmetric.
>
> [1]
>
[ Upstream commit 6cd5235c3135ea84b32469ea51b2aae384eda8af ]
The call to of_get_child_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
[ Upstream commit bc29d3a69d4c1bd1a103e8b3c1ed81b807c1870b ]
The call to of_find_matching_node_and_match returns a node pointer with
refcount incremented thus it must be explicitly decremented after the
last usage.
Detected by coccinelle with the following warnings:
[ Upstream commit 6cd5235c3135ea84b32469ea51b2aae384eda8af ]
The call to of_get_child_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
Hi, Hsin-Yi:
On Wed, 2019-05-29 at 18:25 +0800, Hsin-Yi Wang wrote:
> detatch panel in mtk_dsi_destroy_conn_enc(), since .bind will try to
> attach it again.
>
Reviewed-by: CK Hu
> Fixes: 2e54c14e310f ("drm/mediatek: Add DSI sub driver")
> Signed-off-by: Hsin-Yi Wang
> ---
> change log
[ Upstream commit 6cd5235c3135ea84b32469ea51b2aae384eda8af ]
The call to of_get_child_by_name returns a node pointer with refcount
incremented thus it must be explicitly decremented after the last
usage.
Detected by coccinelle with the following warnings:
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=110790
Andre Klapper changed:
What|Removed |Added
Group||spam
Version|DRI git
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
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
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.
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
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 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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=110790
Andre Klapper changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
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
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
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
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
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
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.
---
* 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?
>
>
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
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
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
---
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=106302
Pierre-Eric Pelloux-Prayer changed:
What|Removed |Added
Status|NEW |RESOLVED
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
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
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]
> >
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
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
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=110781
Richard Thier changed:
What|Removed |Added
Severity|normal |major
--
You are receiving this mail
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,
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:
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
---
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
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
---
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
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:
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
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
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
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>
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
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
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
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
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:
On Wed, 29 May 2019 at 15:00, Robin Murphy wrote:
>
> 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
On Wed, May 29, 2019 at 10:29 AM Andrey Grodzovsky
wrote:
>
> Signed-off-by: Andrey Grodzovsky
Reviewed-by: Alex Deucher
I'll push it to drm-misc in a minute unless you have commit rights.
Alex
> ---
> drivers/gpu/drm/scheduler/sched_main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
>
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
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
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
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
On 2019/05/29, Koenig, Christian wrote:
> 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
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
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:
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
---
rnndb/adreno/a5xx.xml | 1 +
1 file changed, 1 insertion(+)
diff --git a/rnndb/adreno/a5xx.xml b/rnndb/adreno/a5xx.xml
index ae654eeb..16203512 100644
--- a/rnndb/adreno/a5xx.xml
+++ b/rnndb/adreno/a5xx.xml
@@ -1523,6 +1523,7 @@ xsi:schemaLocation="http://nouveau.freedesktop.org/
Adreno driver support for the A540 found in the MSM8998 SoC
v2:
-Removed extra RBBM write
-Corrected added RBBM writes to allow for hwcg disable
-Patch to add REG_A5XX_HLSQ_DBG_ECO_CNTL to envytools
-Regenerated a5xx header file with updated envytools
-Used REG_A5XX_HLSQ_DBG_ECO_CNTL in code
https://bugs.freedesktop.org/show_bug.cgi?id=110781
--- Comment #5 from Richard Thier ---
Still fast with mesa 17.2.8 and X.Org X Server 1.19.5
The problem is somewhere between 17.x and 19.x mesa versions (and corresponding
xorg).
Also I have made an strace when it is good in one older system
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:
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:
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:
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:
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
1 - 100 of 203 matches
Mail list logo
