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
+++
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
+++
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
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
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 ++
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
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
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
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
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 +
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
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 +
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 +
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
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
---
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 +-
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 --
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
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*
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
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
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
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
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
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
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
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
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
---
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
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
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
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
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 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,
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
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
> 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 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,
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
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=edit
Kernel log with debug of 4.19.20+ after patch, including screen reset that does
nothing
--
You are receiving this
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,
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
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.
>
>
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
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
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
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
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
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
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
> > >>
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.
> >
> >
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
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
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
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
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
---
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
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
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
> ---
>
https://bugzilla.kernel.org/show_bug.cgi?id=203325
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC|
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 ;
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
> -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 ;
>
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
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 +-
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
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
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
Since we'll be using the binner bo allocation helper in other parts
of the driver, reformat it with a vc4_v3d prefix and pass the vc4 dev
directly to match other functions.
Make the function visible to the whole driver too.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/vc4/vc4_drv.h |
Check that we have a V3D device registered before attempting to
allocate a binner buffer object.
Signed-off-by: Paul Kocialkowski
---
drivers/gpu/drm/vc4/vc4_v3d.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index
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 --git a/drivers/gpu/drm/vc4/vc4_irq.c
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 with a mutex to
avoid race conditions.
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 +0530, Ramalingam C wrote:
> > > > Functions to create and remove the
Changes since v4:
* Used a kref on the binner bo instead of firstopen/lastclose;
* Added a mutex to prevent race conditions;
* Took care of enabling the OOM interrupt when we have a binner BO allocated.
Changes since v3:
* Split changes into more commits when possible;
* Reworked binner bo alloc
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 after rotation.
>
> Investigation showed that reason was that
On Mon, Apr 15, 2019 at 09:47:19AM +0900, Inki Dae wrote:
> 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(-)
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=110313
Arek Hiler changed:
What|Removed |Added
QA Contact|intel-gfx-bugs@lists.freede |
|sktop.org
On 15.04.2019 13:19, Tomi Valkeinen wrote:
> On 15/04/2019 13:09, Andrzej Hajda wrote:
>> On 26.03.2019 11:31, Tomi Valkeinen wrote:
>>> In tc_bridge_mode_set callback, we store the pointer to the given
>>> drm_display_mode, and use the mode later. Storing a pointer in such a
>>> way looks very
https://bugs.freedesktop.org/show_bug.cgi?id=110416
--- Comment #7 from Hic Sunt Dracones ---
@Alex Deucher, I will try and post results here later
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=110416
--- Comment #6 from Hic Sunt Dracones ---
Created attachment 143976
--> https://bugs.freedesktop.org/attachment.cgi?id=143976=edit
Detailed system configuration after amdgpu-install
--
You are receiving this mail because:
You are the
https://bugs.freedesktop.org/show_bug.cgi?id=110416
--- Comment #5 from Hic Sunt Dracones ---
Created attachment 143975
--> https://bugs.freedesktop.org/attachment.cgi?id=143975=edit
Basic system configuration after amggpu-install
--
You are receiving this mail because:
You are the assignee
On 15/04/2019 11:36, Andrzej Hajda wrote:
>> +static int tc_main_link_disable(struct tc_data *tc)
>> +{
>> +int ret;
>> +
>> +dev_dbg(tc->dev, "link disable\n");
>> +
>> +tc_write(DP0_SRCCTRL, 0);
>> +tc_write(DP0CTL, 0);
>
>
> The same register is set in stream_disable, is it
1 - 100 of 219 matches
Mail list logo
