Am 16.04.19 um 02:35 schrieb Karol Herbst:
Kobjects are supposed to be dynamically allocated, but with recent changes
this rule was violated. Reverting those commits fixes crashes when a drm
driver using TTM gets loaded again.
The object in question is "ttm_mem_glob" declared inside
"include/drm
Hi Bartlomiej,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.1-rc5 next-20190415]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci
Changes since v1:
- separate frame size and reg commit control independent patches.
- fix some return values in probe
- remove DSI_CMDW0 in "CMDQ reg address of mt8173 is different with mt2701"
Jitao Shi (5):
drm/mediatek: move mipi_dsi_host_register to probe
drm/mediatek: CMDQ reg address
Add mt8183 dsi driver data. Enable size control and
reg commit control.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index 458a700ce74c..f0b36ec
New DSI IP has shadow register and working reg. The register
values are writen to shadow register. And then trigger with
commit reg, the register values will be moved working register.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 10 ++
1 file changed, 10 insertions(
Config the different CMDQ reg address in driver data.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 39 +++---
1 file changed, 30 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index
Our new DSI chip has frame size control.
So add the driver data to control for different chips.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dsi.c
b/drivers/gpu/drm/mediatek/mtk_dsi.c
index
DSI panel driver need attach function which is inculde in
mipi_dsi_host_ops.
If mipi_dsi_host_register is not in probe, dsi panel will
probe fail or more delay.
So move the mipi_dsi_host_register to probe from bind.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 50 +
On 16.04.2019 01:24, Life is hard, and then you die wrote:
> Hi Andrzej,
>
> On Mon, Apr 15, 2019 at 10:58:09AM +0200, Andrzej Hajda wrote:
>> On 15.04.2019 10:12, Ronald Tschalär wrote:
>>> commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency
>>> of RC_CORE) changed the driver
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 22e68a100e7b..66405159141a 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/g
Changes since v2:
- update dt-bindings document for mt8183 dpi.
- separate dual edge modfication as independent patch.
*** BLURB HERE ***
Jitao Shi (3):
dt-bindings: display: mediatek: update dpi supported chips
drm/mediatek: dpi dual edge support
drm/mediatek: add mt8183 dpi support
.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/mtk_dpi.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 66405159141a..fbb087218775 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/
Add decriptions about supported chips, including MT2701 & MT8173 &
mt8183
Signed-off-by: Jitao Shi
---
.../devicetree/bindings/display/mediatek/mediatek,dpi.txt| 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.txt
b/Docu
https://bugs.freedesktop.org/show_bug.cgi?id=109607
--- Comment #11 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- fi-kbl-7560u fi-icl-u2, fi-icl-u3: random tests - incomplete -}
{+ fi-kbl-7560u, fi-cfl-8109u, fi-icl-u2, fi-icl-u3: random tests - incomplete
+
This patch add mt8183 mipi_tx driver.
And also support other chips that use the same binding and driver.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/Makefile | 1 +
drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 2 +
drivers/gpu/drm/mediatek/mtk_mipi_tx.h| 1
Changes since v1:
- update dt-bindings document for mt8183 mipitx.
- remove mtk_mipitx_clk_get_ops and assign clk_ops in probe.
- fix the lincence
- remove txdiv1 from mtk_mipi_tx_pll_prepare
*** BLURB HERE ***
Jitao Shi (3):
dt-bindings: display: mediatek: update dsi supported chips
drm/
Different IC has different mipi_tx setting of dsi.
This patch separates the mipi_tx hardware relate part for mt8173.
Signed-off-by: Jitao Shi
---
drivers/gpu/drm/mediatek/Makefile | 1 +
drivers/gpu/drm/mediatek/mtk_mipi_tx.c| 340 ++
drivers/gpu/drm/mediate
Update device tree binding documentation for the dsi for
Mediatek MT8183 SoCs.
Signed-off-by: Jitao Shi
---
.../devicetree/bindings/display/mediatek/mediatek,dsi.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/Documentation/devicetree/bindings/display/mediatek/medi
https://bugs.freedesktop.org/show_bug.cgi?id=110443
Bug ID: 110443
Summary: vaapi/vpp: wrong output for non 64-bytes align width
(ex: 1200)
Product: Mesa
Version: unspecified
Hardware: Other
OS: All
This series convert lots of files to be properly parsed by Sphinx
as ReST files.
As it touches on lot of stuff, the series is based on linux-next.
I have a separate patch series with do the actual rename and
adjustment of references. I opted to submit this first, as it
sounds easier to merge this
https://bugs.freedesktop.org/show_bug.cgi?id=110360
--- Comment #10 from Daniel Drake ---
Thanks Alex. We will have to return this unit to the vendor at some point, but
we will try to hold onto it for another month so that we can run any tests you
request.
Alternatively, we may be able to get an
This reverts commit 56b3d20413587fab6a790cfc8bc075ca94bc8ed9.
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/ttm/ttm_bo.c| 14 +-
include/drm/ttm/ttm_bo_driver.h | 1 +
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm
Kobjects are supposed to be dynamically allocated, but with recent changes
this rule was violated. Reverting those commits fixes crashes when a drm
driver using TTM gets loaded again.
The object in question is "ttm_mem_glob" declared inside
"include/drm/ttm/ttm_memory.h" and instatiated inside
"dr
This reverts commit 27eb1fa9130a98edd2b321d4dbce5c8b244ee7af.
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 44 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 +
drivers/gpu/drm/ast/ast_drv.h | 1 +
drivers/gpu/drm/ast/as
This reverts commit 62b53b37e4b1500d4eb4624a44ad861cf8d3cd18.
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/ttm/ttm_bo.c| 31 ---
include/drm/ttm/ttm_bo_driver.h | 15 +++
2 files changed, 15 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/d
This reverts commit 30f33126feca0fe16df9e9302ffc28a953e2eb37.
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/ttm/ttm_bo.c | 1 +
drivers/gpu/drm/ttm/ttm_memory.c | 9 +
2 files changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index
This reverts commit 2bb42410b1bd324912389c6ac748df1c1befd69f.
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/Makefile| 2 +-
drivers/gpu/drm/drm_drv.c | 2 +
drivers/gpu/drm/drm_global.c| 137
include/drm/drmP.h | 1 +
includ
This reverts commit a64f784bb14a56bfdfad2dc397dd67e4564e3a29.
Signed-off-by: Karol Herbst
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 59 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h | 1 +
drivers/gpu/drm/ast/ast_drv.h | 1 +
drivers/gpu/drm/ast/as
Print out debug messages with correct device name.
As for this, this patch adds device pointer to exynos_drm_ipp structure,
and in case of exynos_drm_ipp_task structure, replace drm_device pointer
with device one. This will make each ipp driver to print out debug
messages with correct device name.
Add device pointer to vidi_context and remove platform_device pointer.
It doesn't need for vidi_context to contain platform_device object.
Instead, this patch makes this driver more simply by replacing platform_device
pointer with device one.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/e
This patch just cleans up the use of error log macro, which changes
the log macro to DRM_DEV_ERROR.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 14 +---
drivers/gpu/drm/exynos/exynos_dp.c| 9 +
Use DRM_DEV_DEBUG* instead of DRM_DEBUG macro to print out
debug messages.
This patch just cleans up the use of debug log macro, which changes
the log macro to DRM_DEV_DEBUG*.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 +-
drivers/gpu/drm/exynos/exynos7_drm_d
This patch removes unnecessary messages from fimd_clear_channels
and decon_clear_channels functions which print out just function
name.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 2 --
drivers/gpu/drm/exynos/exynos7_drm_decon.c| 2 --
drivers/gpu/drm/exynos/e
This patch makes error messages to be printed out using DRM_ERROR
instead of DRM_INFO.
Signed-off-by: Inki Dae
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos
Just clean up logs of Exynos DRM driver.
What this patch series does is to replace the use of existing DRM_DEBUG/ERROR
macros with DRM_DEV_DEBUG*/ERROR* macros including relevant code cleanup.
Chnagelog v3:
. correct subject prefix.
. drop one patch merged already from v2.
Changelog v2:
. Clean
Hi Sam,
19. 4. 15. 오후 6:13에 Sam Ravnborg 이(가) 쓴 글:
> Hi Inki
>
>
>> Inki Dae (6):
>> drm/fimd: use DRM_ERROR instead of DRM_INFO in error case
>> drm/exynos: remove unnecessary messages
>> drm/exynos: use DRM_DEV_ERROR to print out error message
>> drm/exynos: use DRM_DEV_DEBUG* instead
Neil Armstrong writes:
> On 13/03/2019 15:10, Neil Armstrong wrote:
>> This patchset adds the G12A specific bindings for the Display VPU
>> and VPU Power Control.
>>
>> The Amlogic Meson G12A Display module is based on the Meson GXM SoC
>> with an updated Plane Blender, thus VPU architecture and
Andrey Grodzovsky writes:
> 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 should solve a deadlock reported
Paul Kocialkowski writes:
> The binner bo is not required until the V3D is in use, so avoid
> allocating it at probe and do it on the first non-dumb BO allocation.
> Keep track of which clients are using the V3D and liberate the buffer
> when there is none left (through a kref) and protect it wit
Paul Kocialkowski writes:
> Since the OOM interrupt directly deals with the binner bo, it doesn't
> make sense to try and handle it without a binner buffer registered.
>
> Signed-off-by: Paul Kocialkowski
> ---
> drivers/gpu/drm/vc4/vc4_irq.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff
On Tue, 16 Apr 2019 at 06:05, Lionel Landwerlin
wrote:
>
> On 15/04/2019 20:52, Dave Airlie wrote:
> > On Tue, 16 Apr 2019 at 05:48, Lionel Landwerlin
> > wrote:
> >> Unfortunately userspace users of this API cannot be publicly disclosed
> >> yet so disable this stuff by default until all is reve
On 15/04/2019 20:52, Dave Airlie wrote:
On Tue, 16 Apr 2019 at 05:48, Lionel Landwerlin
wrote:
Unfortunately userspace users of this API cannot be publicly disclosed
yet so disable this stuff by default until all is revealed.
This begs the question how userspace is meant to know we support the
On 4/15/19 3:43 PM, Andrey Grodzovsky wrote:
> Signed-off-by: Andrey Grodzovsky
> Reviewed-by: Nicholas Kazlauskas
Nitpicks:
Put the current commit message (with the spelling mistake in
accidentally fixed) in the body of the commit and give the commit title
something a little more descriptive
On Tue, 16 Apr 2019 at 05:48, Lionel Landwerlin
wrote:
>
> Unfortunately userspace users of this API cannot be publicly disclosed
> yet so disable this stuff by default until all is revealed.
This begs the question how userspace is meant to know we support these?
Is there a CAP for it? if not wh
Unfortunately userspace users of this API cannot be publicly disclosed
yet so disable this stuff by default until all is revealed.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/Kconfig | 10 ++
drivers/gpu/drm/drm_syncobj.c | 12
2 files changed, 22 insertions(+
On 15/04/2019 13:56, Christian König wrote:
Instead of checking the upper values of the sequence number use an explicit
field in the dma_fence_ops structure to note if a sequence should be 32bit
or 64bit.
Signed-off-by: Christian König
That works for me :)
Reviewed-by: Lionel Landwerlin
From: Christian König
Don't block others while waiting for the fences to finish, concurrent
submission is perfectly valid in this case and holding the lock can
prevent killed applications from terminating.
Signed-off-by: Christian König
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd
For later driver's reference to see if the fence is signaled.
v2: Move parent fence put to resubmit jobs.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/dri
Also reject TDRs if another one already running.
v2:
Stop all schedulers across device and entire XGMI hive before
force signaling HW fences.
Avoid passing job_signaled to helper fnctions to keep all the decision
making about skipping HW reset in one place.
v3:
Fix SW sched. hang after non HW res
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 should solve a deadlock reported by a user.
v2: Remove unused variable
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/a
On Mon, Apr 15, 2019 at 4:14 PM Lankhorst, Maarten
wrote:
>
> mån 2019-04-15 klockan 19:26 +0530 skrev Sharma, Shashank:
> > > -Original Message-
> > > From: Lankhorst, Maarten
> > > Sent: Monday, April 15, 2019 4:28 PM
> > > To: Shankar, Uma ; intel-gfx@lists.freedeskt
> > > op.org; dri-
On Mon, Apr 15, 2019 at 6:21 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 15.04.19 um 17:54 schrieb Daniel Vetter:
> > On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote:
> >> Hi
> >>
> >> Am 09.04.19 um 09:12 schrieb kra...@redhat.com:
> >>> Hi,
> >>>
> If not for TTM, what wou
On Mon, Apr 15, 2019 at 8:01 PM Greg Kroah-Hartman
wrote:
> On Mon, Apr 15, 2019 at 10:44:12PM +0530, Ramalingam C wrote:
> > On 2019-04-15 at 16:47:16 +0200, Greg Kroah-Hartman wrote:
> > > On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote:
> > > > On 2019-04-05 at 14:32:00 +0200, Greg
On Mon, Apr 15, 2019 at 8:56 PM Koenig, Christian
wrote:
>
> Am 15.04.19 um 20:54 schrieb Dave Airlie:
> >> Well, I've got commit rights as well.
> >>
> >> Going to remove the warning, add your rb and push everything if nobody
> >> objects in the next hour or so.
> > So this got committed and is i
Am 15.04.19 um 20:54 schrieb Dave Airlie:
>> Well, I've got commit rights as well.
>>
>> Going to remove the warning, add your rb and push everything if nobody
>> objects in the next hour or so.
> So this got committed and is in my -next tree, but where is the
> userspace and igt tests?
I was wait
> Well, I've got commit rights as well.
>
> Going to remove the warning, add your rb and push everything if nobody
> objects in the next hour or so.
So this got committed and is in my -next tree, but where is the
userspace and igt tests?
There needs to be a functional mesa userspace and a set of
On 2019-04-12 1:30 p.m., Ville Syrjälä wrote:
> On Fri, Apr 12, 2019 at 12:05:29PM -0400, sunpeng...@amd.com wrote:
>> From: Leo Li
>>
>> Hi all,
>>
>> This is a follup to this change made by Ville to add MST aux nodes:
>> https://github.com/vsyrjala/linux/commit/cac63f799ee2f5fbbe4f0a375383f13
On Thu, 2019-04-04 at 09:17 -0500, Bjorn Helgaas wrote:
> [+cc Hans, author of 0b2fe6594fa2 ("drm/nouveau: Queue hpd_work on (runtime)
> resume")]
>
> On Fri, Mar 22, 2019 at 06:30:15AM -0500, Bjorn Helgaas wrote:
> > On Thu, Mar 21, 2019 at 05:48:19PM -0500, Bjorn Helgaas wrote:
> > > On Wed, Mar
On Mon, Apr 15, 2019 at 10:44:12PM +0530, Ramalingam C wrote:
> On 2019-04-15 at 16:47:16 +0200, Greg Kroah-Hartman wrote:
> > On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote:
> > > On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Apr 05, 2019 at 04:06:22PM +0
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #11 from Thomas R. ---
Created attachment 143978
--> https://bugs.freedesktop.org/attachment.cgi?id=143978&action=edit
Kernel log with debug of 4.19.20+ after patch, including screen reset that does
nothing
--
You are receiving t
https://bugs.freedesktop.org/show_bug.cgi?id=105433
Thomas R. changed:
What|Removed |Added
Attachment #137980|0 |1
is obsolete|
Plane property "FB_DAMAGE_CLIPS" can only be used by atomic aware
user-space, so no point exposing it otherwise.
Signed-off-by: Deepak Rawat
Fixes: d3b21767821e ("drm: Add a new plane property to send damage during plane
update")
---
drivers/gpu/drm/drm_mode_config.c | 5 +++--
1 file changed,
On 2019-04-15 at 16:47:16 +0200, Greg Kroah-Hartman wrote:
> On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote:
> > On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote:
> > > > On 2019-04-05 at 11:23:00 +0200, Greg
https://bugs.freedesktop.org/show_bug.cgi?id=105433
--- Comment #9 from Thomas R. ---
I'm unsure if I should file a new bug at this point, but here is an update for
the LTS kernel:
4.19.20 breaks functionality again, now the second screen is reliably dead at
1080p (native resolution). I could bi
Am 15.04.19 um 17:11 schrieb Andrey Grodzovsky:
For later driver's reference to see if the fence is signaled.
v2: Move parent fence put to resubmit jobs.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +--
1 file ch
On Thu, Apr 11, 2019 at 03:22:42PM +0200, Maxime Ripard wrote:
> Properly configuring the overscan properties might be needed for the
> initial setup of the framebuffer for display that still have overscan.
> Let's allow for more properties on the kernel command line to setup each
> margin.
>
> Si
On Thu, Apr 11, 2019 at 03:22:41PM +0200, Maxime Ripard wrote:
> Rotations and reflections setup are needed in some scenarios to initialise
> properly the initial framebuffer. Some drivers already had a bunch of
> quirks to deal with this, such as either a private kernel command line
> parameter (o
On Thu, Apr 11, 2019 at 05:36:30PM +0300, Gwan-gyeong Mun wrote:
> This patch series fix missed detection of changing of edid on between
> suspend and resume.
> First patch fixes drm_helper_hdp_irq_event() in order to fix a below use
> case.
>
> Following scenario requires detection of changing o
Hi
Am 15.04.19 um 17:54 schrieb Daniel Vetter:
> On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote:
>> Hi
>>
>> Am 09.04.19 um 09:12 schrieb kra...@redhat.com:
>>> Hi,
>>>
If not for TTM, what would be the alternative? One VMA manager per
memory region per device?
>>>
>
Our driver makes a typical use of CMA, with GEM object allocated as
GEM CMA objects. Use DRM_GEM_CMA_VMAP_DRIVER_OPS to describe the ops
instead of duplicating them.
Because DRM_GEM_CMA_VMAP_DRIVER_OPS implements a gem_create_object op
which sets per-object funcs (drm_cma_gem_default_funcs), we ca
On Mon, Apr 15, 2019 at 12:41:33PM +, Lisovskiy, Stanislav wrote:
> On Mon, 2019-04-15 at 15:36 +0300, Ville Syrjälä wrote:
> > On Mon, Apr 15, 2019 at 10:58:47AM +0300, Stanislav Lisovskiy wrote:
> > > There was an issue reported from end users, confirmed
> > > also locally that when user exec
Hi Marco
On Mon, Apr 15, 2019 at 05:46:48PM +0200, Marco Felsch wrote:
> Hi Thierry,
>
> gentle ping.
>
> On 19-01-14 11:28, Marco Felsch wrote:
> > Hi Sam,
> >
> > On 19-01-04 17:40, Sam Ravnborg wrote:
> > > Hi Marco.
> > >
> > > In $subject pannel => panel
> >
> > Thanks for covering that,
On Sat, Mar 16, 2019 at 10:59:44PM +0100, Sam Ravnborg wrote:
> > + ret = drm_fbdev_generic_setup(drm, 16);
> > + if (ret) {
> > + dev_err(dev, "Failed to init fbdev\n");
> > + goto err_devclk_disable;
> > + }
> fbdev is usually considered an optionl feature that do not pr
On Sun, Apr 14, 2019 at 10:08:24PM +0200, Paul Cercueil wrote:
> Add a KMS driver for the Ingenic JZ47xx family of SoCs.
> This driver is meant to replace the aging jz4740-fb driver.
>
> Signed-off-by: Paul Cercueil
> Tested-by: Artur Rojek
Please put somewhere in your commit message why you're
On Wed, Apr 10, 2019 at 09:49:33PM -0400, Rob Clark wrote:
> On Tue, Apr 9, 2019 at 8:27 AM Eric Engestrom
> wrote:
> >
> > On Tuesday, 2019-04-09 12:59:13 +0100, Eric Engestrom wrote:
> > > On Tuesday, 2019-04-09 11:35:14 +, Ayan Halder wrote:
> > > > Generated using make headers_install fro
On Mon, Apr 15, 2019 at 05:54:30PM +0200, Daniel Vetter wrote:
> On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote:
> > Hi
> >
> > Am 09.04.19 um 09:12 schrieb kra...@redhat.com:
> > > Hi,
> > >
> > >> If not for TTM, what would be the alternative? One VMA manager per
> > >> mem
On Tue, Apr 09, 2019 at 09:50:40AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 09.04.19 um 09:12 schrieb kra...@redhat.com:
> > Hi,
> >
> >> If not for TTM, what would be the alternative? One VMA manager per
> >> memory region per device?
> >
> > Depends pretty much on the device.
> >
> > The
On Mon, Apr 15, 2019 at 06:41:48PM +0800, Joel Stanley wrote:
> On Mon., 15 Apr. 2019, 17:32 Daniel Vetter, wrote:
>
> > On Fri, Apr 05, 2019 at 06:41:17PM +1030, Joel Stanley wrote:
> > > The GFX IP is inside of the ASPEED BMC SoC so there is little use
> > > enabling it on a kernel that does no
On 4/15/19 2:46 AM, Koenig, Christian wrote:
I agree this would be good in case of amdgpu_device_pre_asic_reset
because we can totally skip this function if guilty job already
signaled, but for amdgpu_device_post_asic_reset it crates complications
because drm_sched_start is right in the middle th
was accidentaly removed during one of DALs code merges.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_
For later driver's reference to see if the fence is signaled.
v2: Move parent fence put to resubmit jobs.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_m
From: Christian König
Don't block others while waiting for the fences to finish, concurrent
submission is perfectly valid in this case and holding the lock can
prevent killed applications from terminating.
Signed-off-by: Christian König
Reviewed-by: Nicholas Kazlauskas
---
drivers/gpu/drm/amd
Also reject TDRs if another one already running.
v2:
Stop all schedulers across device and entire XGMI hive before
force signaling HW fences.
Avoid passing job_signaled to helper fnctions to keep all the decision
making about skipping HW reset in one place.
Signed-off-by: Andrey Grodzovsky
---
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 should solve a deadlock reported by a user.
v2: Remove unused variable
On Mon, Apr 15, 2019 at 06:11:13PM +0530, Ramalingam C wrote:
> On 2019-04-05 at 14:32:00 +0200, Greg Kroah-Hartman wrote:
> > On Fri, Apr 05, 2019 at 04:06:22PM +0530, Ramalingam C wrote:
> > > On 2019-04-05 at 11:23:00 +0200, Greg Kroah-Hartman wrote:
> > > > On Fri, Apr 05, 2019 at 02:12:54PM +0
On 4/15/2019 7:42 PM, Lankhorst, Maarten wrote:
mån 2019-04-15 klockan 19:26 +0530 skrev Sharma, Shashank:
-Original Message-
From: Lankhorst, Maarten
Sent: Monday, April 15, 2019 4:28 PM
To: Shankar, Uma ; intel-gfx@lists.freedeskt
op.org; dri-
de...@lists.freedesktop.org
Cc: Syrjala,
Am Mo., 15. Apr. 2019 um 15:12 Uhr schrieb Lucas Stach :
>
> Setting the GFP flags does not need a new code block if moved to
> the right location, which makes this function a bit easier to read.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etna
https://bugzilla.kernel.org/show_bug.cgi?id=203325
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
mån 2019-04-15 klockan 19:26 +0530 skrev Sharma, Shashank:
> > -Original Message-
> > From: Lankhorst, Maarten
> > Sent: Monday, April 15, 2019 4:28 PM
> > To: Shankar, Uma ; intel-gfx@lists.freedeskt
> > op.org; dri-
> > de...@lists.freedesktop.org
> > Cc: Syrjala, Ville ; emil.l.velikov@g
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #36 from Talha Khan ---
(In reply to JerryD from comment #35)
> Well, I just ran Fedora updates which brought kernel to 5.0.7-200.fc29 and
> there was also an update to mesa-dri-drivers.x86_64 18.3.6-1.fc29. My laptop
> failed to boo
> -Original Message-
> From: Lankhorst, Maarten
> Sent: Monday, April 15, 2019 4:28 PM
> To: Shankar, Uma ; intel-...@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org
> Cc: Syrjala, Ville ; emil.l.veli...@gmail.com;
> s...@ravnborg.org; Roper, Matthew D ;
> seanp...@chromium.o
On Mon, 2019-04-15 at 15:12 +0200, Lucas Stach wrote:
> Setting the GFP flags does not need a new code block if moved to
> the right location, which makes this function a bit easier to read.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
regards
Philipp
_
https://bugs.freedesktop.org/show_bug.cgi?id=108514
Werner Lueckel changed:
What|Removed |Added
Keywords||bisected, patch
--
You are receiving
Setting the GFP flags does not need a new code block if moved to
the right location, which makes this function a bit easier to read.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/
https://bugs.freedesktop.org/show_bug.cgi?id=108514
--- Comment #33 from Werner Lueckel ---
Thanks to Paul Dufresne a patch in "radeon_display.c" seems to fix the bug.
So the radeon maintainers should work on an upstream fix.
--
You are receiving this mail because:
You are the assignee for the
Instead of checking the upper values of the sequence number use an explicit
field in the dma_fence_ops structure to note if a sequence should be 32bit
or 64bit.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-fence-chain.c | 3 ++-
drivers/dma-buf/sw_sync.c | 2 +-
drivers/dma-b
https://bugs.freedesktop.org/show_bug.cgi?id=109955
--- Comment #14 from Mauro Gaspari ---
Quick update.
OS: OpenSUSE tumbleweed x86_64 updated (2019 04 15)
Kernel: 5.0.7-1-default
Desktop Environment: KDE Plasma (x11)
OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.0.1
GPU: AMD Rade
On Mon, Apr 15, 2019 at 10:57:52AM +, Lankhorst, Maarten wrote:
> fre 2019-04-12 klockan 15:51 +0530 skrev Uma Shankar:
> > Introduced a client cap for advance cap mode
> > capability. Userspace should set this to get
> > to be able to use the new gamma_mode property.
> >
> > If this is not se
On Mon, 2019-04-15 at 15:36 +0300, Ville Syrjälä wrote:
> On Mon, Apr 15, 2019 at 10:58:47AM +0300, Stanislav Lisovskiy wrote:
> > There was an issue reported from end users, confirmed
> > also locally that when user executes xrandr --output
> > --rotate left/right, the other eDP screen gets blank
1 - 100 of 230 matches
Mail list logo
