From: Christian König
Add bulk move pos to store the pointer of first and last buffer object.
The list in between will be bulk moved on lru list.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
---
include/drm/ttm/ttm_bo_driver.h | 28
1 file changed, 28 i
From: Christian König
When move a BO to the end of LRU, it need remember the BO positions.
Make sure all moved bo in between "first" and "last". And they will be bulk
moving together.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 8 -
This function allow us to bulk move a group of BOs to the tail of their LRU.
The positions of group of BOs are stored on the (first, last) bulk_move_pos
structure.
Signed-off-by: Christian König
Signed-off-by: Huang Rui
---
drivers/gpu/drm/ttm/ttm_bo.c | 52 +
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact performance seriousl
The new bulk moving functionality is ready, the overhead of moving PD/PT bos to
LRU is fixed. So move them on LRU again.
Signed-off-by: Huang Rui
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
On Thu, 2018-08-09 at 14:13 +0300, Gwan-gyeong Mun wrote:
> The hotplug detection routine of i915 uses
> drm_helper_hpd_irq_event(). This
> helper can detect changing of status of connector, but it can not
> detect
> changing of edid.
>
> Following scenario requires detection of changing of edid.
Am 09.08.2018 um 19:39 schrieb Andrey Grodzovsky:
[SNIP]
SIGKILL isn't processed as long as any thread of the application is
still inside the kernel. That's why we have wait_event_killable().
Can you tell me where is this happening ? What i see is in the code is
that
do_group_exit calls zap_o
From: Stanislav Lisovskiy
Introduced new XYUV scan-in format for framebuffer and
added support for it to i915 driver.
Stanislav Lisovskiy (2):
drm: Introduce new DRM_FORMAT_XYUV
drm/i915: Adding YUV444 packed format(DRM_FORMAT_XYUV) support.
drivers/gpu/drm/drm_fourcc.c | 1 +
driv
From: Stanislav Lisovskiy
v5: This is YUV444 packed format same as AYUV, but without alpha,
as supported by i915.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/
It seems that line 352 should have one more tab at the beginning of the
line.
julia
-- Forwarded message --
Date: Fri, 10 Aug 2018 21:01:50 +0800
From: kbuild test robot
To: kbu...@01.org
Cc: Julia Lawall
Subject: [radeon-alex:drm-next-4.19 52/60]
drivers/gpu/drm/amd/amdgpu/
From: Stanislav Lisovskiy
PLANE_CTL_FORMAT_AYUV is already supported, according to hardware
specification.
v2: Edited commit message, removed redundant whitespaces.
v3: Fixed fallthrough logic for the format switch cases.
v4: Yet again fixed fallthrough logic, to reuse code from other case
Crap, yeah indeed that needs to be protected by some lock.
Going to prepare a patch for that,
Christian.
Am 09.08.2018 um 21:49 schrieb Andrey Grodzovsky:
Reviewed-by: Andrey Grodzovsky
But I still have questions about entity->last_user (didn't notice
this before) -
Looks to me there is
Dear all,
This patchset is a result of further improving Exynos DRM IPP drivers.
Graphics and codec hardware modules found in Samsung Exynos5250/542x/5433
SoCs supports 16x16 tiled formats. This patchset adds support for it.
Best regards
Marek Szyprowski
Samsung R&D Institute Poland
Patch summa
From: Andrzej Pietrasiewicz
Add support for 16x16 tiled formats: NV12/NV21, YUYV and YUV420.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_scaler.c | 133 -
1 file changed, 75 insertions(+), 58 deletions(-)
diff
From: Andrzej Pietrasiewicz
Add modifier for tiled formats used by graphics modules found in Samsung
Exynos5250/542x/5433 SoCs. This is a simple tiled layout using tiles
of 16x16 pixels in a row-major layout.
Signed-off-by: Andrzej Pietrasiewicz
Signed-off-by: Marek Szyprowski
---
include/uap
Add support for 16x16 tiled NV12 and NV21 formats.
Signed-off-by: Marek Szyprowski
---
drivers/gpu/drm/exynos/exynos_drm_gsc.c | 46 ++---
1 file changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
b/drivers/gpu/drm/exynos/exynos_
I can take care of this.
Andrey
On 08/10/2018 09:27 AM, Christian König wrote:
Crap, yeah indeed that needs to be protected by some lock.
Going to prepare a patch for that,
Christian.
Am 09.08.2018 um 21:49 schrieb Andrey Grodzovsky:
Reviewed-by: Andrey Grodzovsky
But I still have ques
Am 10.08.2018 um 13:55 schrieb Huang Rui:
I continue to work for bulk moving that based on the proposal by Christian.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end
Am 10.08.2018 um 11:21 schrieb Daniel Vetter:
[SNIP]
Then don't track _any_ of the amdgpu internal fences in the reservation object:
- 1 reservation object that you hand to ttm, for use internally within amdgpu
- 1 reservation object that you attach to the dma-buf (or get from the
imported dma-bu
https://bugs.freedesktop.org/show_bug.cgi?id=107518
--- Comment #7 from Alex Deucher ---
amdgpu_pmops_freeze() calls amdgpu_device_suspend() which calls
amdgpu_asic_reset() at the end. amdgpu_asic_reset() is a macro which calls an
asic specific callback to reset the GPU. vi_asic_reset() in vi.
This RFC adds the remaining fourcc codes which are needed to cover all
currently supported formats in Mali IPs.
There was quite a lengthy discussion on IRC about it - please treat this
as RFC and read the commentary below!
This patch is on-top of
https://lists.freedesktop.org/archives/dri-devel/2
On Thursday, August 02, 2018 01:28:38 PM Hans de Goede wrote:
> Hi Bartlomiej,
>
> After backporting the deferred fbcon takeover patches to the 4.18
> kernel for the upcoming Fedora 29 release, Fedora QA found a serious
> bug caused by the fbcon takeover support.
>
> When using classic (non EFI)
On Tuesday, August 07, 2018 09:27:52 AM Randy Dunlap wrote:
> From: Randy Dunlap
>
> Fix grammar, spacing, indentation, and Kconfig menu locations
> in fbcon.txt.
>
> Signed-off-by: Randy Dunlap
Patch queued for 4.19, thanks.
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R&D Institute Po
On Friday, August 10, 2018 01:27:57 PM Hans de Goede wrote:
> Taking over the console involves allocating mem with GFP_KERNEL, talking
> to drm drivers, etc. So this should not be done from an atomic context.
>
> But the console-output trigger deferred console takeover may happen from an
> atomic
On Fri, Aug 10, 2018 at 10:22:58AM +0530, spa...@codeaurora.org wrote:
> Hi Sean,
>
> Thanks for your patch.
> I also made this similar change as part of my PSR support changes (yet to be
> posted for review). But since this patch is posted now, i will pick this for
> my PSR changes.
Hi Sandeep,
This was hand-rolled in the first version, and will surely be useful as
we expand the driver to support more varied use cases.
Changes in v2:
- Change subject prefix s/panel/bridge/
- Downgrade warning in poll function to error message
- Fix DP_EDP_CONFIGURATION_SET write value (Sandeep)
- Mask up
On Wed, Aug 08, 2018 at 11:15:47PM +0100, Russell King - ARM Linux wrote:
> On Wed, Aug 08, 2018 at 03:09:30PM -0400, Sean Paul wrote:
> > > -static const struct drm_encoder_helper_funcs
> > > tda998x_encoder_helper_funcs = {
> > > - .dpms = tda998x_encoder_dpms,
> > > - .prepare = tda998x_encoder
On Fri, Aug 10, 2018 at 05:50:37PM +0100, Russell King - ARM Linux wrote:
> On Fri, Aug 10, 2018 at 12:11:05PM -0400, Sean Paul wrote:
> > On Wed, Aug 08, 2018 at 11:15:47PM +0100, Russell King - ARM Linux wrote:
> > > In any case, bridges are buggy with unbinding/rebinding as I've pointed
> > > ou
DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear
to me, so try to clarify that with a bit of ascii graphics.
Signed-off-by: Alexandru Gheorghe
---
include/uapi/drm/drm_mode.h | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/include/uapi/drm/drm
Hi Stanislav,
FYI, we are trying to add same format under a slightly different name.
See https://lists.freedesktop.org/archives/dri-devel/2018-July/184598.html
On Fri, Aug 10, 2018 at 04:19:03PM +0300, StanLis wrote:
> From: Stanislav Lisovskiy
>
> v5: This is YUV444 packed format same as AYUV,
prepare() is the old-timey way to say pre_enable(). It should be called
before modeset. This fixes an issue where the panel on cheza must have
the regulator always-on/boot-on for it to work.
Cc: Sandeep Panda
Cc: Stephen Boyd
Signed-off-by: Sean Paul
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c |
The panel datasheet specifies a 500ms delay after power-down before
re-enabling.
Cc: Sandeep Panda
Cc: Stephen Boyd
Signed-off-by: Sean Paul
---
drivers/gpu/drm/panel/panel-simple.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/p
On Fri, Aug 10, 2018 at 06:50:31PM +0100, Alexandru Gheorghe wrote:
> DRM_MODE_REFLECT_X and DRM_MODE_REFLECT_Y meaning seems a bit unclear
> to me, so try to clarify that with a bit of ascii graphics.
>
> Signed-off-by: Alexandru Gheorghe
Reviewed-by: Sean Paul
> ---
> include/uapi/drm/drm_m
Quoting Jordan Crouse (2018-08-08 15:47:01)
> diff --git a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> index cdaabeb3c995..9fb90bb4ea1f 100644
> --- a/arch/arm64/boot/dts/qcom/sdm845.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sdm845.dtsi
> @@ -323,5 +323,126 @@
>
Reviewed-by: Karol Herbst
On Tue, Aug 7, 2018 at 10:39 PM, Lyude Paul wrote:
> It's not necessary to call these before we call nouveau_do_suspend().
> Ideally; we shouldn't have to call this at all here, but getting that to
> work will take a bit more effort. So for the time being, just move thi
Reviewed-by: Karol Herbst
On Tue, Aug 7, 2018 at 10:39 PM, Lyude Paul wrote:
> Currently, it appears that nouveau_do_suspend() forgets to roll back
> suspending fbcon and suspending the device LEDs. We also currently skip
> the entire rollback process if nouveau_display_suspend() fails. So, fix
Reviewed-by: Karol Herbst
On Tue, Aug 7, 2018 at 10:39 PM, Lyude Paul wrote:
> Otherwise, how will we roll everything back?
>
> Signed-off-by: Lyude Paul
> Cc: sta...@vger.kernel.org
> Cc: Lukas Wunner
> Cc: Karol Herbst
> ---
> drivers/gpu/drm/nouveau/nouveau_drm.c | 3 +++
> 1 file changed
Reviewed-by: Karol Herbst
On Tue, Aug 7, 2018 at 10:39 PM, Lyude Paul wrote:
> It's true we can't resume the device from poll workers in
> nouveau_connector_detect(). We can however, prevent the autosuspend
> timer from elapsing immediately if it hasn't already without risking any
> sort of dead
Tanmay Shah writes:
> msm_drm.h file derived from drm-next kernel uapi header.
>
> Remove freedreno/msm/msm_drm.h to maintain only
> one copy of msm_drm.h and change freedreno Makefile
> accordingly.
>
> Signed-off-by: Tanmay Shah
Looks like this is missing the meson.build update, and leaves a
https://bugs.freedesktop.org/show_bug.cgi?id=107545
Bug ID: 107545
Summary: radeon - ring 0 stalled - GPU lockup - SI
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: normal
Hi Dave,
A couple small fixes for v4.19.
I have a 2nd optional follow-up PR that I'll send on top of this which
adds a6xx support. See the following PR for details.
The following changes since commit a7663a79343658f9362dc0655f1a06723c7014e3:
dt-bindings: msm/disp: Add bindings for Snapdragon
Hi Dave,
An optional follow-on PR for 4.19, on top of previous -fixes PR, which
brings in a6xx support.
These patches have been on list since earlier in the year (mostly
waiting for userspace). They have been in linux-next since earlier in
the week, now that we have freedreno userspace working o
On Fri, Aug 10, 2018 at 10:18:24PM +0800, Koenig, Christian wrote:
> Am 10.08.2018 um 13:55 schrieb Huang Rui:
> > I continue to work for bulk moving that based on the proposal by Christian.
> >
> > Background:
> > amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move
> > all o
On Thu, Aug 09, 2018 at 01:37:09PM +0200, Christian König wrote:
> Add a helper to access the shared fences in an reservation object.
>
> Signed-off-by: Christian König
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 7 ++-
> drivers/gpu/drm/amd/amdgpu/a
On 10/08/2018 08:35, Maxime Jourdan wrote:
> 2018-08-10 0:41 GMT+02:00 Rob Herring :
>> Hi, this is an automated email from Rob's (experimental) review bot. I
>> found a couple of common problems with your patch. Please see below.
>>
>> On Wed, 1 Aug 2018 20:51:28 +0200, Maxime Jourdan wrote:
>>>
Quoting Christian König (2018-08-09 15:54:31)
> Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
> > On Thu, Aug 9, 2018 at 3:58 PM, Christian König
> > wrote:
> >> Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
> >>> On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
> >>> [SNIP]
> >> S
https://bugs.freedesktop.org/show_bug.cgi?id=107539
Bug ID: 107539
Summary: Inverted colours after screen blank/unblank
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
S
Am 10.08.2018 um 09:51 schrieb Chris Wilson:
Quoting Christian König (2018-08-09 15:54:31)
Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
On Thu, Aug 9, 2018 at 3:58 PM, Christian König
wrote:
Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian Kö
On Fri, 2018-08-10 at 11:39 +1000, Dave Airlie wrote:
> >
> > I've resent the pull requests with the missing [GIT PULL] tag added,
> > sorry for the noise.
>
> Since we are at -rc8 and this is late, I've just dropped these fixes
> into drm-next, once they land in Linus,
> you might want to nomina
On Thu, Aug 9, 2018 at 4:54 PM, Christian König
wrote:
> Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
>>
>> On Thu, Aug 9, 2018 at 3:58 PM, Christian König
>> wrote:
>>>
>>> Am 09.08.2018 um 15:38 schrieb Daniel Vetter:
On Thu, Aug 09, 2018 at 01:37:07PM +0200, Christian König wrote:
>
On Fri, Aug 10, 2018 at 10:24 AM, Christian König
wrote:
> Am 10.08.2018 um 09:51 schrieb Chris Wilson:
>>
>> Quoting Christian König (2018-08-09 15:54:31)
>>>
>>> Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
On Thu, Aug 9, 2018 at 3:58 PM, Christian König
wrote:
>
> Am 09
Hi,
On 09-08-18 15:29, Daniel Vetter wrote:
On Thu, Aug 9, 2018 at 1:42 PM, Hans de Goede wrote:
Taking over the console involves allocating mem with GFP_KERNEL, talking
to drm drivers, etc. So this should not be done from an atomic context.
But the console-output trigger deferred console tak
On Thu, Aug 9, 2018 at 12:53 PM Thierry Reding wrote:
[Me]
> > I suspect this is indeed a panel driver and not a panel with integrated
> > driver. I think the best is to define two compatible strings like
> > we do for ILI9322:
> > "truly,nt35597", "qcom,reference-design-name-display";
>
> I don'
On Fri, Aug 10, 2018 at 10:42 AM, Hans de Goede wrote:
> Hi,
>
>
> On 09-08-18 15:29, Daniel Vetter wrote:
>>
>> On Thu, Aug 9, 2018 at 1:42 PM, Hans de Goede wrote:
>>>
>>> Taking over the console involves allocating mem with GFP_KERNEL, talking
>>> to drm drivers, etc. So this should not be don
Am 10.08.2018 um 10:32 schrieb Daniel Vetter:
On Fri, Aug 10, 2018 at 10:24 AM, Christian König
wrote:
Am 10.08.2018 um 09:51 schrieb Chris Wilson:
Quoting Christian König (2018-08-09 15:54:31)
Am 09.08.2018 um 16:22 schrieb Daniel Vetter:
On Thu, Aug 9, 2018 at 3:58 PM, Christian König
wro
On Thu, Aug 09, 2018 at 08:27:10PM +0800, Koenig, Christian wrote:
> Am 09.08.2018 um 14:25 schrieb Huang Rui:
> > On Thu, Aug 09, 2018 at 03:18:55PM +0800, Koenig, Christian wrote:
> >> Am 09.08.2018 um 08:18 schrieb Huang Rui:
> >>> On Wed, Aug 08, 2018 at 06:47:49PM +0800, Christian König wrote:
Am 10.08.2018 um 10:29 schrieb Daniel Vetter:
[SNIP]
I'm only interested in the case of shared buffers. And for those you
_do_ pessimistically assume that all access must be implicitly synced.
Iirc amdgpu doesn't support EGL_ANDROID_native_fence_sync, so this
makes sense that you don't bother wit
On Fri, Aug 10, 2018 at 11:14 AM, Christian König
wrote:
> Am 10.08.2018 um 10:29 schrieb Daniel Vetter:
>>
>> [SNIP]
>> I'm only interested in the case of shared buffers. And for those you
>> _do_ pessimistically assume that all access must be implicitly synced.
>> Iirc amdgpu doesn't support EGL
On Fri, Aug 10, 2018 at 10:51 AM, Christian König
wrote:
> Am 10.08.2018 um 10:32 schrieb Daniel Vetter:
>>
>> On Fri, Aug 10, 2018 at 10:24 AM, Christian König
>> wrote:
>>>
>>> Am 10.08.2018 um 09:51 schrieb Chris Wilson:
Quoting Christian König (2018-08-09 15:54:31)
>
> Am 09
On Fri, Aug 10, 2018 at 11:14 AM, Christian König
wrote:
> Am 10.08.2018 um 10:29 schrieb Daniel Vetter:
>>
>> [SNIP]
>> I'm only interested in the case of shared buffers. And for those you
>> _do_ pessimistically assume that all access must be implicitly synced.
>> Iirc amdgpu doesn't support EGL
HI,
On 10-08-18 10:50, Daniel Vetter wrote:
On Fri, Aug 10, 2018 at 10:42 AM, Hans de Goede wrote:
Hi,
On 09-08-18 15:29, Daniel Vetter wrote:
On Thu, Aug 9, 2018 at 1:42 PM, Hans de Goede wrote:
Taking over the console involves allocating mem with GFP_KERNEL, talking
to drm drivers, et
Taking over the console involves allocating mem with GFP_KERNEL, talking
to drm drivers, etc. So this should not be done from an atomic context.
But the console-output trigger deferred console takeover may happen from an
atomic context, which leads to "BUG: sleeping function called from invalid
co
The idea and proposal is originally from Christian, and I continue to work to
deliver it.
Background:
amdgpu driver will move all PD/PT and PerVM BOs into idle list. Then move all of
them on the end of LRU list one by one. Thus, that cause so many BOs moved to
the end of the LRU, and impact perfor
63 matches
Mail list logo
