Re: [maintainer-tools PATCH RFC 3/3] dim: fix rr_cache_dir discovery
On Tue, Dec 18, 2018 at 8:15 AM Andrzej Hajda wrote:
>
> On 17.12.2018 15:46, Daniel Vetter wrote:
> > On Mon, Dec 17, 2018 at 10:54:48AM +0100, Andrzej Hajda wrote:
> >> Hi Daniel,
> >>
> >> Thanks for reviewing other two patches.
> >>
> >>
> >> On 14.12.2018 17:29, Daniel Vetter wrote:
> >>> On Fri, Dec 14, 2018 at 02:38:52PM +0100, Andrzej Hajda wrote:
> rr_cache_dir function cannot assume REPO/.git is a directory. On the
> other
> side it should be backward compatible - if rr-cache directory/link
> already
> exists it should be returned.
>
> Signed-off-by: Andrzej Hajda
> ---
> Hi,
>
> I am not sure of the purpose of rr-cache symbolic link, dim does not use
> it (except its creation/removal). So this patch should be verified by
> someone who knows better what is going on here.
>
> Regards
> Andrzej
> ---
> dim | 20 +++-
> 1 file changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/dim b/dim
> index 3afa8b6..b72ebfd 100755
> --- a/dim
> +++ b/dim
> @@ -554,15 +554,6 @@ function check_conflicts # tree
> true
> }
>
> -function rr_cache_dir
> -{
> - if [ -d $DIM_PREFIX/drm-tip/.git/ ] ; then
> - echo $DIM_PREFIX/drm-tip/.git/rr-cache
> - else
> - echo $DIM_PREFIX/$DIM_REPO/.git/rr-cache
> - fi
> -}
> >>> I think this breaks it, rr-cache is shared among all worktrees (which is a
> >>> big reason for having them).
> >>
> >> If drm-tip and $DIM_REPO are worktrees (more exactly "linked working
> >> tree" - ie .git is a file), then rr_cache_dir will return invalid path.
> >>
> >> As a result update_rerere_cache will fail create symlink, with this kind
> >> of error:
> >>
> >> ln: failed to create symbolic link '/lab/dim/drm-misc-next/.git':
> >> File exists
> > Ah, now I get it, your $DIM_REPO is also a worktree. Yes that's not
> > supported with the current code.
> >
> > But your code doesn't fix it. We do _not_ want $(git_dir)/rr-cache here,
> > but really the .git/rr-cache of the master repo. The worktrees do not have
> > their own private rr-cache, but use the one of the master repo.
> >
> >>> And yes dim only sets up the symlink, dim rebuild-tip uses the rr-cache
> >>> stuff automatically through git merge.
> >>
> >> I still do not see who and when is using (ie. reading) this link.
> >> rebuild_tip seems to use only $DIM_PREFIX/drm_rerere/rr-cache. Is there
> >> some magic inside git itself, or I am just blind?
> > git merge --rerere-autoupdate uses it internally. We want that drm-tip
> > uses the rr-cache we store in drm-rerere/rr-cache.
> >
> > Maybe $(git_dir drm-tip)/../../rr-cache works? Again, the important part
> > is that we edit the .git/rr-cache in your master repo, not in any of the
> > worktrees (rr-cache doesn't exist there).
>
>
> I think the proper way of finding rr-cache would be:
>
>
> function rr_cache_dir
> {
> echo $(git rev-parse --git-common-dir)/rr-cache
> }
Indeed. Also just noticed that rev-parse also has a --git-dir option.
Care to also change git_dir() to use that?
> If you are OK with it I can prepare patch. In fact since the function is
> used only in update_rerere_cache, it could be squashed there:
>
> function update_rerere_cache
> {
> echo -n "Updating rerere cache... "
> pull_rerere_cache
>
> local rr_cache_dir=$(git rev-parse --git-common-dir)/rr-cache
>
> ...
>
> }
Yeah makes sense.
-Daniel
>
>
> Is this approach OK?
>
>
> Regards
>
> Andrzej
>
>
>
> > -Daniel
> >
> >>
> >> Regards
> >>
> >> Andrzej
> >>
> >>
> >>
> >>> -Daniel
> >>>
> -
> function git_dir
> {
> local dir=${1:-$PWD}
> @@ -574,6 +565,17 @@ function git_dir
> fi
> }
>
> +function rr_cache_dir
> +{
> + local dir=$(git_dir $DIM_PREFIX/$DIM_REPO)/rr-cache
> +
> + if [ -d $dir ]; then
> + echo $dir
> + else
> + echo $(git_dir $DIM_PREFIX/drm-tip)/rr-cache
> + fi
> +}
> +
> function pull_rerere_cache
> {
> cd $DIM_PREFIX/drm-rerere/
> --
> 2.17.1
>
> ___
> dim-tools mailing list
> dim-to...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dim-tools
> >>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH/RFC 0/2] R-Car DU: Support importing non-contiguous dma-buf with VSP
Hi Kieran, On Monday, 13 November 2017 15:48:19 EET Kieran Bingham wrote: > On 13/11/17 10:32, Laurent Pinchart wrote: > > Hello everybody, > > > > This patch series fixes two issues related to dma-buf import for the > > Renesas R-Car DU when the imported buffer is either not physically > > contiguous or located in high memory. > > > > Both cases require the use of an IOMMU to remap the buffers contiguously > > and in 32-bit DMA space. On Gen2 platforms this is transparent and works > > already, but on Gen3 platforms the situation is more complex. > > > > The Gen3 DU doesn't perform DMA access directly but instead goes through a > > VSP IP core that acts as an external composer. When importing a dma-buf > > buffer the GEM PRIME helper drm_gem_prime_import() maps the buffer to the > > DU device, and the DU driver later remaps it to the VSP device. The > > driver unfortunately can't use the drm_gem_prime_import_dev() helper to > > map th buffer to the VSP device directly, as at import time we don't know > > yet to which VSP device the buffer will need to be mapped (there is one > > VSP composer per CRTC). Mapping the buffer to the VSP can thus only be > > done when pinning the framebuffer, as we know at that time which plane > > and CRTC it will be used with. > > > > This works currently (with the caveat that an unneeded mapping to the DU > > is created), but fails when the imported buffer is not physically > > contiguous or is located in high memory. In the first case the GEM CMA > > helper drm_gem_cma_prime_import_sg_table() will reject the buffer as it > > hasn't been mapped contiguously in the DU DMA address space (because the > > DU has no IOMMU), and in the second case the DMA mapping API will try to > > allocate a bounce buffer and fail due to bounce buffer memory exhaustion. > > > > The first patch in this series fixes the second issue by setting the DMA > > coherent mask of the DU device to the full 40 bits address space. All > > memory will thus be accepted without trying to allocate a bounce buffer. > > > > The second patch in this series fixes the first issue by using an internal > > copy of the drm_gem_cma_prime_import_sg_table() function that doesn't > > ensure that the buffer is contiguous in memory. This is what caused me to > > post this series as an RFC, as I'm not very happy with duplication of > > helper code in the driver that could lead to breakages when the GEM CMA > > helpers are modified. If this approach is accepted, I would prefer > > implementing the code in the GEM CMA helpers. > > > > Another point that bothers me is that buffers can now be imported > > unconditionally on Gen3 platforms, but atomic commits will fail if the > > buffer can't be remapped through the VSP (for instance if no IOMMU is > > available). Given the hardware architecture and the DRM/KMS API I don't > > really see a way around this. > > > > Testing this series isn't easy as it requires getting hold of exported > > dma-bufs located in high memory or not physically contiguous. I have used > > the V4L2 vivid driver as an exporter for that purpose, with a few hacks > > that can be found at > > > > git://linuxtv.org/pinchartl/media.git drm/du/devel/iommu > > Ok - testing from this branch with "drm: rcar-du: Allow importing > non-contiguous dma-buf with VSP" applied on top (it appeared to be missing) > > > On the userspace side I have used the v4l2-drm-example test application > > available at > > > > git://git.infradead.org/users/kmpark/public-apps > > > > and run with > > > > dmabuf-sharing -M rcar-du -i /dev/video0 -S 640,480 -f YUYV -F YUYV \ > > > > -s 640,480@0,0 -t 640,480@0,0 -o 70:68:640x480 -b 4 -e v4l2 > > > > (the -o argument needs to be modified based on the connector and CRTC ID). > > I've build dmabuf-sharing from kmpark/public-apps/v4l2-drm-example, but it > doesn't appear to have a "-e v4l2" option (not listed in the -h, and > complains with "ERROR(dmabuf-sharing.c:560) : failed to parse arguments") > > Have you also modified this application to run your tests? Oops, yes, I have. Sorry for not mentioning that. The modified version can be found at git://git.ideasonboard.org/samsung-utils.git > If it's easier, I can look at the screen while you run the test under your > control as well. > > > Up to patch "[DEBUG] v4l: videobuf2-dma-contig: Print allocated buffer > > address" buffer sharing should work. Patch "[HACK] vivid: Allocate buffers > > from high memory" then breaks buffer import, and the issue is fixed by > > patch "drm: rcar-du: Set the DMA coherent mask for the DU device". Patch > > "[HACK] vivid: Use vmalloc allocator" breaks buffer import again, and is > > fixed by "drm: rcar-du: Allow importing non-contiguous dma-buf with VSP". > > > > Kieran, I have tested this remotely on your Salvator-X H3 ES1.1 and > > haven't noticed any problem, but couldn't check the output on the screen. > > Would you be able to rerun the test locally for me ? Please
[PATCH] drm/bochs: add edid present check
Check first two header bytes before trying to read the edid blob, to avoid the log being spammed in case qemu has no edid support (old qemu or edid turned off). Fixes: 01f23459cf drm/bochs: add edid support. Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/bochs/bochs_hw.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/bochs/bochs_hw.c b/drivers/gpu/drm/bochs/bochs_hw.c index c90a0d492f..f91e049625 100644 --- a/drivers/gpu/drm/bochs/bochs_hw.c +++ b/drivers/gpu/drm/bochs/bochs_hw.c @@ -89,6 +89,10 @@ int bochs_hw_load_edid(struct bochs_device *bochs) if (!bochs->mmio) return -1; + if (readb(bochs->mmio + 0) != 0x00 || + readb(bochs->mmio + 1) != 0xff) + return -1; + kfree(bochs->edid); bochs->edid = drm_do_get_edid(>connector, bochs_get_edid_block, bochs); -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [maintainer-tools PATCH RFC 3/3] dim: fix rr_cache_dir discovery
On 17.12.2018 15:46, Daniel Vetter wrote:
> On Mon, Dec 17, 2018 at 10:54:48AM +0100, Andrzej Hajda wrote:
>> Hi Daniel,
>>
>> Thanks for reviewing other two patches.
>>
>>
>> On 14.12.2018 17:29, Daniel Vetter wrote:
>>> On Fri, Dec 14, 2018 at 02:38:52PM +0100, Andrzej Hajda wrote:
rr_cache_dir function cannot assume REPO/.git is a directory. On the other
side it should be backward compatible - if rr-cache directory/link already
exists it should be returned.
Signed-off-by: Andrzej Hajda
---
Hi,
I am not sure of the purpose of rr-cache symbolic link, dim does not use
it (except its creation/removal). So this patch should be verified by
someone who knows better what is going on here.
Regards
Andrzej
---
dim | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/dim b/dim
index 3afa8b6..b72ebfd 100755
--- a/dim
+++ b/dim
@@ -554,15 +554,6 @@ function check_conflicts # tree
true
}
-function rr_cache_dir
-{
- if [ -d $DIM_PREFIX/drm-tip/.git/ ] ; then
- echo $DIM_PREFIX/drm-tip/.git/rr-cache
- else
- echo $DIM_PREFIX/$DIM_REPO/.git/rr-cache
- fi
-}
>>> I think this breaks it, rr-cache is shared among all worktrees (which is a
>>> big reason for having them).
>>
>> If drm-tip and $DIM_REPO are worktrees (more exactly "linked working
>> tree" - ie .git is a file), then rr_cache_dir will return invalid path.
>>
>> As a result update_rerere_cache will fail create symlink, with this kind
>> of error:
>>
>> ln: failed to create symbolic link '/lab/dim/drm-misc-next/.git':
>> File exists
> Ah, now I get it, your $DIM_REPO is also a worktree. Yes that's not
> supported with the current code.
>
> But your code doesn't fix it. We do _not_ want $(git_dir)/rr-cache here,
> but really the .git/rr-cache of the master repo. The worktrees do not have
> their own private rr-cache, but use the one of the master repo.
>
>>> And yes dim only sets up the symlink, dim rebuild-tip uses the rr-cache
>>> stuff automatically through git merge.
>>
>> I still do not see who and when is using (ie. reading) this link.
>> rebuild_tip seems to use only $DIM_PREFIX/drm_rerere/rr-cache. Is there
>> some magic inside git itself, or I am just blind?
> git merge --rerere-autoupdate uses it internally. We want that drm-tip
> uses the rr-cache we store in drm-rerere/rr-cache.
>
> Maybe $(git_dir drm-tip)/../../rr-cache works? Again, the important part
> is that we edit the .git/rr-cache in your master repo, not in any of the
> worktrees (rr-cache doesn't exist there).
I think the proper way of finding rr-cache would be:
function rr_cache_dir
{
echo $(git rev-parse --git-common-dir)/rr-cache
}
If you are OK with it I can prepare patch. In fact since the function is
used only in update_rerere_cache, it could be squashed there:
function update_rerere_cache
{
echo -n "Updating rerere cache... "
pull_rerere_cache
local rr_cache_dir=$(git rev-parse --git-common-dir)/rr-cache
...
}
Is this approach OK?
Regards
Andrzej
> -Daniel
>
>>
>> Regards
>>
>> Andrzej
>>
>>
>>
>>> -Daniel
>>>
-
function git_dir
{
local dir=${1:-$PWD}
@@ -574,6 +565,17 @@ function git_dir
fi
}
+function rr_cache_dir
+{
+ local dir=$(git_dir $DIM_PREFIX/$DIM_REPO)/rr-cache
+
+ if [ -d $dir ]; then
+ echo $dir
+ else
+ echo $(git_dir $DIM_PREFIX/drm-tip)/rr-cache
+ fi
+}
+
function pull_rerere_cache
{
cd $DIM_PREFIX/drm-rerere/
--
2.17.1
___
dim-tools mailing list
dim-to...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dim-tools
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH][resend] drm: dw-hdmi-i2s: convert to SPDX identifiers
Hi Morimoto-san, Thank you for the patch. On Tuesday, 18 December 2018 08:00:24 EET Kuninori Morimoto wrote: > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. > > Signed-off-by: Kuninori Morimoto Reviewed-by: Laurent Pinchart > --- > few weeks passed, nothing happen. I re-post this patch again. > I added Andrew on Cc The driver seems to be lacking a maintainer :-S > drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c index > 8f9c8a6..2228689 100644 > --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi-i2s-audio.c > @@ -1,12 +1,9 @@ > +// SPDX-License-Identifier: GPL-2.0 > /* > * dw-hdmi-i2s-audio.c > * > * Copyright (c) 2017 Renesas Solutions Corp. > * Kuninori Morimoto > - * > - * This program is free software; you can redistribute it and/or modify > - * it under the terms of the GNU General Public License version 2 as > - * published by the Free Software Foundation. > */ > #include -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm: Make drmNodeIsDRM() public.
On 18 December 2018 5:03:22 am AEDT, Emil Velikov wrote: >Hi Christopher, > >On Tue, 20 Nov 2018 at 04:30, Christopher James Halse Rogers > wrote: >> >> I have wanted this code in Mir, so it's plausibly useful elsewhere, >> particularly if the DRM device major number is going to become >> dynamic. >> >Can you elaborate/link to the code that uses the major/minor? >Fiddling with those manually is rather error prone most often than not. We have an internal API that mirrors that of logind - taking a (major,minor) pair and returning a usable fd. For input devices, that just means opened O_NONBLOCK; for DRM devices it means calling SetMaster. Here's the relevant (non-logind) implementation: https://github.com/MirServer/mir/blob/master/src/server/console/linux_virtual_terminal.cpp#L634 Since we by necessity end up pulling out the devnode I guess we could match on a /dev/dri prefix instead. I just noticed this function while doing the drmIsMaster patch and thought it would be convenient for us! ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] libkms: remove ilo from list of intel_drivers
Signed-off-by: Tapani Pälli --- (Driver was removed from Mesa long time ago.) libkms/Android.mk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libkms/Android.mk b/libkms/Android.mk index 0be72054..bf4781a3 100644 --- a/libkms/Android.mk +++ b/libkms/Android.mk @@ -1,6 +1,6 @@ DRM_GPU_DRIVERS := $(strip $(filter-out swrast, $(BOARD_GPU_DRIVERS))) -intel_drivers := i915 i965 i915g ilo +intel_drivers := i915 i965 i915g radeon_drivers := r300g r600g radeonsi nouveau_drivers := nouveau virgl_drivers := virgl -- 2.17.2 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm: Add drmIsMaster()
On 18 December 2018 4:35:37 am AEDT, Emil Velikov wrote: >Hi Christopher, > >On Tue, 20 Nov 2018 at 03:37, Christopher James Halse Rogers > wrote: >> >> We can't use drmSetMaster to query whether or not a drm fd is master >> because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd. >> >Can you please mention the exact use case here? You mentioned it over >IRC although it'll be nice to have it here for posterity. Certainly! The particular use-case I was hitting was testing my display server in a container, where container-root is not real-root but the implicit-master FD you get by opening the DRM node when there is no current master would be sufficient. Just assuming the FD we get is master and failing later breaks the platform probing; for example, when run under X11 if we don't check master we'll load the KMS platform and then fail, rather than noticing that KMS won't work and using our X11 backend. > >> Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is >> DRM_MASTER but not DRM_ROOT_ONLY as the probe by which we can detect >> whether or not the fd is master. >> >I'm wondering if we cannot extent DRM_IOCTL_GET_CLIENT or another >IOCTL. >What do you think? May I interest you in writing an RFC for the >kernel-side? I think if I was going to do kernel-side changes if probably just make it so that IOCTL_SET_MASTER just unconditionally succeeded on an fd that was already master? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #64 from CheatCodesOfLife --- It'll be a different bug, this only affects Vega10 cards. Polaris is fine with Cemu and the other guy's Vega test app. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #34 from Shmerl --- I tested the patch. I don't see the error message now, but the startup monitor sleep regression is still present. Is it a separate issue? I can open another bug if needed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109022] ring gfx timeout during particular shader generation on yuzu emulator
https://bugs.freedesktop.org/show_bug.cgi?id=109022 --- Comment #3 from e88z4 --- I did a little more troubleshooting on my API trace. Call #36840880 is the culprit of the VMC Page Fault error. The GPU didn't crash right away but continuing 100-200 calls after 36840880 might randomly trigger the ring gfx timeout error. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105251] [Vega10] GPU lockup on boot: VMC page fault
https://bugs.freedesktop.org/show_bug.cgi?id=105251 --- Comment #63 from e88z4 --- Hi I came across this bug report that might be related to my bug report #109022 https://bugs.freedesktop.org/show_bug.cgi?id=109022 I got the VMC Page Fault error as well while playing Yuzu with RX580. The bug can be reproduced easily at the same spot each time. GPU crashed but can be accessed through SSH. If you think my bug is very similar with this bug, maybe I can help debugging. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #33 from Sibren Vasse --- Just tried the patch, so far no reg_wait warnings. Looking good! -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 2/4] drm/i915: Use drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI as well
On Thu, 2018-12-13 at 15:09 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-12-13 at 07:18 +0200, Ville Syrjälä wrote:
> > On Wed, Dec 12, 2018 at 04:32:02PM -0800, Dhinakaran Pandiyan
> > wrote:
> > > On Tue, 2018-11-20 at 18:13 +0200, Ville Syrjala wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > Fill out the AVI infoframe quantization range bits using
> > > > drm_hdmi_avi_infoframe_quant_range() for SDVO HDMI encoder as
> > > > well.
> > > >
> > > > Signed-off-by: Ville Syrjälä
> > > > ---
> > > > drivers/gpu/drm/i915/intel_sdvo.c | 19 ++-
> > > > 1 file changed, 10 insertions(+), 9 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
> > > > b/drivers/gpu/drm/i915/intel_sdvo.c
> > > > index 1277d31adb54..9c16e273fb8d 100644
> > > > --- a/drivers/gpu/drm/i915/intel_sdvo.c
> > > > +++ b/drivers/gpu/drm/i915/intel_sdvo.c
> > > > @@ -984,6 +984,8 @@ static bool
> > > > intel_sdvo_set_avi_infoframe(struct
> > > > intel_sdvo *intel_sdvo,
> > > > const struct
> > > > intel_crtc_state
> > > > *pipe_config,
> > > > const struct
> > > > drm_connector_state *conn_state)
> > > > {
> > > > + const struct drm_display_mode *adjusted_mode =
> > > > + _config->base.adjusted_mode;
> > > > uint8_t sdvo_data[HDMI_INFOFRAME_SIZE(AVI)];
> > > > union hdmi_infoframe frame;
> > > > int ret;
> > > > @@ -991,20 +993,19 @@ static bool
> > > > intel_sdvo_set_avi_infoframe(struct
> > > > intel_sdvo *intel_sdvo,
> > > >
> > > > ret =
> > > > drm_hdmi_avi_infoframe_from_display_mode(,
> > > >conn_sta
> > > > te-
> > > > > connector,
> > > >
> > > > - _co
> > > > nfig-
> > > > > base.adjusted_mode);
> > > >
> > > > + adjusted
> > > > _mode);
> > > > if (ret < 0) {
> > > > DRM_ERROR("couldn't fill AVI infoframe\n");
> > > > return false;
> > > > }
> > > >
> > > > - if (intel_sdvo->rgb_quant_range_selectable) {
> > > > - if (pipe_config->limited_color_range)
> > > > - frame.avi.quantization_range =
> > > > - HDMI_QUANTIZATION_RANGE_LIMITED
> > > > ;
> > > > - else
> > > > - frame.avi.quantization_range =
> > > > - HDMI_QUANTIZATION_RANGE_FULL;
> > > > - }
> > > > + drm_hdmi_avi_infoframe_quant_range(,
> > > > + conn_state-
> > > > >connector,
> > > > + adjusted_mode,
> > > > + pipe_config-
> > > > > limited_color_range ?
> > > >
> > > > + rgb_quant_range_sele
> > > > ctableTE
> > > > D :
> > > > + HDMI_QUANTIZATION_RA
> > > > NGE_FULL
> > > > ,
> > > > + intel_sdvo-
> > > > > rgb_quant_range_selectable);
> > >
> > > Seems like avi.quantization_range can now get set to _LIMITED or
> > > _FULL
> > > even when ->rgb_quant_range_selectable == false, i.e., it is not
> > > _DEFAULT anymore. Is that change in behavior intended?
> >
> > ->quant_range_selectable will be passed to
> > drm_hdmi_avi_infoframe_quant_range() which will do the right thing
> > with
> > it.
> >
> > That said, there is a slight behavioural change in that it will set
>
> Okay, I was indeed referring to this case.
>
> > the Q bit even with QS==1 iff the quantization range matches the
> > default quantization range for the mode. I noted this in the radeon
> > patch but forgot to mention it here.
>
> I'll let someone else with knowledge of HDMI to review this
> behavioral
> change. I'm trying to get hold of the HDMI spec now and will review
> if
> this hasn't been looked at by then.
>
Looks alright now that I went through the specs. With commit message
updated to make note of the Q value changes
Reviewed-by: Dhinakaran Pandiyan
>
> >
> > >
> > >
> > > >
> > > > len = hdmi_infoframe_pack(, sdvo_data,
> > > > sizeof(sdvo_data));
> > > > if (len < 0)
> >
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 2/2] arm64: dts: sdm845: Add gpu and gmu device nodes
Hi,
On Sun, Dec 16, 2018 at 11:06 PM Viresh Kumar wrote:
>
> +Rob +Stephen,
>
> On 14-12-18, 09:04, Doug Anderson wrote:
> > Hi,
> >
> > On Thu, Dec 13, 2018 at 8:41 PM Viresh Kumar
> > wrote:
> > >
> > > On 12-12-18, 14:18, Jordan Crouse wrote:
> > > > + gpu_opp_table: opp-table {
> > > > + compatible =
> > > > "operating-points-v2-qcom-level";
> > >
> > > I think you need to mention "operating-points-v2" as well here.
> >
> > Are you saying the above should be:
> > compatible = "operating-points-v2-qcom-level", "operating-points-v2";
> >
> > If so I'm not sure I agree.
>
> Well I have my doubts as well on this. This is where the ordering was
> discussed
> earlier:
>
> https://lore.kernel.org/lkml/152328979897.180276.15963925877442657...@swboyd.mtv.corp.google.com/
>
> @Rob/Stephen: Should the opp-table node above also have "operating-points-v2"
> string in the compatible property ?
>
> > It's _not_ really compatible with the
> > "operating-points-v2" binding. If you had a driver that had never
> > heard of "operating-points-v2-qcom-level" and had only heard of
> > "operating-points-v2" and it took a look at this node it would have no
> > idea what to do with it.
>
> Well it will parse everything apart from the qcom,level thing, so it can
> actually parse stuff here.
>
> > I'll also note that other instances posted to the list don't list both:
> >
> > https://patchwork.kernel.org/patch/10725801/ - RPM / RPMH PD bindings
> > https://patchwork.kernel.org/patch/10725793/ - RPMH PD device tree for
> > sdm845
> >
> > The bindings patch also makes no mention of needing
> > "operating-points-v2". I think the common case when a fallback is
> > required it is explicitly called out in the bindings:
> >
> > https://patchwork.kernel.org/patch/10725803/ - qcom-opp bindings
>
> Sure, maybe I am wrong but its better to get some clarity on it from
> Rob/Stephen.
In case it helps:
https://lkml.kernel.org/r/20181217210849.GA15490@bogus
...shows Rob giving a Reviewed-by with just
compatible = "operating-points-v2-qcom-level";
...and not:
compatible = "operating-points-v2-qcom-level", "operating-points-v2";
-Doug
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers/base: use a worker for sysfs unbind
On Mon, Dec 17, 2018 at 8:48 PM Daniel Vetter wrote: > > On Thu, Dec 13, 2018 at 07:09:15PM +0100, Rafael J. Wysocki wrote: > > On Thu, Dec 13, 2018 at 5:25 PM Daniel Vetter > > wrote: > > > > > > On Thu, Dec 13, 2018 at 5:18 PM Rafael J. Wysocki > > > wrote: > > > > > > > > On Thu, Dec 13, 2018 at 1:36 PM Daniel Vetter > > > > wrote: > > > > [cut] > > > > > > > I can do the old code exactly, but afaict the non-NULL parent just > > > > > takes care of the parent bus locking for us, instead of hand-rolling > > > > > it in the caller. But if I missed something, I can easily undo that > > > > > part. > > > > > > > > It is different if device links are present, but I'm not worried about > > > > that case honestly. :-) > > > > > > What would change with device links? We have some cleanup plans to > > > remove our usage for early/late s/r hooks with a device link, to make > > > sure i915 resumes before snd_hda_intel. Digging more into the code I > > > only see the temporary dropping of the parent's device_lock, but I > > > have no idea what that even implies ... > > > > That's just it (which is why I said I was not worried). > > > > Running device_links_unbind_consumers() with the parent lock held may > > deadlock if another child of the same parent also is a consumer of the > > current device (which really is a corner case), but the current code > > has this problem - it goes away with your change. > > > > But dev->bus->need_parent_lock checks are missing in there AFAICS, let > > me cut a patch to fix that. > > With your patch before this one, are you ok with mine? Or want me to > respin with a different flavour? Having reconsidered this a bit I'm leaning towards annotating the locks - if that works. After all, what is problematic is the lockdep false-positive and addressing it that way would be most natural IMO. Thanks, Rafael ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/2] gitignore: add _build
On Mon, Dec 17, 2018 at 05:43:59PM +, Emil Velikov wrote: > On Fri, 19 Oct 2018 at 18:20, Lucas De Marchi > wrote: > > > > > /_build* > > /build* > > > These two sound perfectly reasonable IMHO. They will catch vast > majority of use-cases. > > With that the series is: > Acked-by: Emil Velikov Pushed, thanks Lucas De Marchi > > -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/msm/dpu: Change definition of RGB565 and BGR565
Correct definition of both formats by swapping red
and blue channels
v3: update commit message
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index d53abc8ce670..f59fe1a9f4b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -263,13 +263,13 @@ static const struct dpu_format dpu_format_map[] = {
INTERLEAVED_RGB_FMT(RGB565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
- C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
+ C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),
INTERLEAVED_RGB_FMT(BGR565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
- C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
+ C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109073] AMDGPU Radeon RX540 system freezes and/or crashes; poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 tiredandn...@gmail.com changed: What|Removed |Added Summary|AMDGPU Radeon RX540 system |AMDGPU Radeon RX540 system |freezes poor performance|freezes and/or crashes; |with ac adapter plugged in |poor performance with ac ||adapter plugged in -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 102322] System crashes after "[drm] IP block:gmc_v8_0 is hung!" / [drm] IP block:sdma_v3_0 is hung!
https://bugs.freedesktop.org/show_bug.cgi?id=102322 --- Comment #72 from dwagner --- Just for the record, since another month has passed: I can still reproduce the crash with today's git head of amd-staging-drm-next within minutes. (Also using the very latest firmware files from https://people.freedesktop.org/~agd5f/radeon_ucode/ ) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109073] AMDGPU Radeon RX540 system freezes poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 tiredandn...@gmail.com changed: What|Removed |Added Priority|medium |high -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109073] AMDGPU Radeon RX540 system freezes poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #4 from tiredandn...@gmail.com --- Created attachment 142843 --> https://bugs.freedesktop.org/attachment.cgi?id=142843=edit dmesg with 4.20.0-042000rc7-generic without ac adapter -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109073] AMDGPU Radeon RX540 system freezes poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #3 from tiredandn...@gmail.com --- Created attachment 142842 --> https://bugs.freedesktop.org/attachment.cgi?id=142842=edit Kern.log of failed boot (black screen) with 4.20.0-042000rc7-generic -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109073] AMDGPU Radeon RX540 system freezes poor performance with ac adapter plugged in
https://bugs.freedesktop.org/show_bug.cgi?id=109073 --- Comment #2 from tiredandn...@gmail.com --- With 4.20.0-042000rc7-generic it is actually worse. The system hangs with a black screen while booting with power adapter connected. Without power adapter it does boot. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/2] drm: Add color management LUT validation helper (v4)
Some hardware may place additional restrictions on the gamma/degamma
curves described by our LUT properties. E.g., that a gamma curve never
decreases or that the red/green/blue channels of a LUT's entries must be
equal. Let's add a helper function that drivers can use to test that a
userspace-provided LUT is valid and doesn't violate hardware
requirements.
v2:
- Combine into a single helper that just takes a bitmask of the tests
to apply. (Brian Starkey)
- Add additional check (always performed) that LUT property blob size
is always a multiple of the LUT entry size. (stolen from ARM driver)
v3:
- Drop the LUT size check again since
drm_atomic_replace_property_blob_from_id() already covers this for
us. (Alexandru Gheorghe)
v4:
- Use an enum to describe possible test values rather than #define's;
this is cleaner to provide kerneldoc for. (Daniel Vetter)
- s/DRM_COLOR_LUT_INCREASING/DRM_COLOR_LUT_NON_DECREASING/. (Ville)
Cc: Uma Shankar
Cc: Swati Sharma
Cc: Brian Starkey
Cc: Daniel Vetter
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by(v1): Brian Starkey
Reviewed-by: Alexandru Gheorghe
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/drm_color_mgmt.c | 44
include/drm/drm_color_mgmt.h | 29 ++
2 files changed, 73 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 07dcf47daafe..968ca7c91ad8 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -462,3 +462,47 @@ int drm_plane_create_color_properties(struct drm_plane
*plane,
return 0;
}
EXPORT_SYMBOL(drm_plane_create_color_properties);
+
+/**
+ * drm_color_lut_check - check validity of lookup table
+ * @lut: property blob containing LUT to check
+ * @tests: bitmask of tests to run
+ *
+ * Helper to check whether a userspace-provided lookup table is valid and
+ * satisfies hardware requirements. Drivers pass a bitmask indicating which of
+ * the tests in _color_lut_tests should be performed.
+ *
+ * Returns 0 on success, -EINVAL on failure.
+ */
+int drm_color_lut_check(struct drm_property_blob *lut,
+ uint32_t tests)
+{
+ struct drm_color_lut *entry;
+ int i;
+
+ if (!lut || !tests)
+ return 0;
+
+ entry = lut->data;
+ for (i = 0; i < drm_color_lut_size(lut); i++) {
+ if (tests & DRM_COLOR_LUT_EQUAL_CHANNELS) {
+ if (entry[i].red != entry[i].blue ||
+ entry[i].red != entry[i].green) {
+ DRM_DEBUG_KMS("All LUT entries must have equal
r/g/b\n");
+ return -EINVAL;
+ }
+ }
+
+ if (i > 0 && tests & DRM_COLOR_LUT_NON_DECREASING) {
+ if (entry[i].red < entry[i - 1].red ||
+ entry[i].green < entry[i - 1].green ||
+ entry[i].blue < entry[i - 1].blue) {
+ DRM_DEBUG_KMS("LUT entries must never
decrease.\n");
+ return -EINVAL;
+ }
+ }
+ }
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_color_lut_check);
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index 90ef9996d9a4..6affbda6d9cb 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -69,4 +69,33 @@ int drm_plane_create_color_properties(struct drm_plane
*plane,
u32 supported_ranges,
enum drm_color_encoding default_encoding,
enum drm_color_range default_range);
+
+/**
+ * enum drm_color_lut_tests - hw-specific LUT tests to perform
+ *
+ * The drm_color_lut_check() function takes a bitmask of the values here to
+ * determine which tests to apply to a userspace-provided LUT.
+ */
+enum drm_color_lut_tests {
+ /**
+* @DRM_COLOR_LUT_EQUAL_CHANNELS:
+*
+* Checks whether the entries of a LUT all have equal values for the
+* red, green, and blue channels. Intended for hardware that only
+* accepts a single value per LUT entry and assumes that value applies
+* to all three color components.
+*/
+ DRM_COLOR_LUT_EQUAL_CHANNELS = BIT(0),
+
+ /**
+* @DRM_COLOR_LUT_NON_DECREASING:
+*
+* Checks whether the entries of a LUT are always flat or increasing
+* (never decreasing).
+*/
+ DRM_COLOR_LUT_NON_DECREASING = BIT(1),
+};
+
+int drm_color_lut_check(struct drm_property_blob *lut,
+ uint32_t tests);
#endif
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/i915: Validate userspace-provided color management LUT's (v3)
We currently program userspace-provided gamma and degamma LUT's into our
hardware without really checking to see whether they satisfy our
hardware's rules. We should try to catch tables that are invalid for
our hardware early and reject the atomic transaction.
All of our platforms that accept a degamma LUT expect that the entries
in the LUT are always flat or increasing, never decreasing. Also, our
GLK and ICL platforms only accept degamma tables with r=g=b entries; so
we should also add the relevant checks for that in anticipation of
degamma support landing for those platforms.
v2:
- Use new API (single check function with bitmask of tests to apply)
- Call helper for our gamma table as well (with no additional tests
specified) so that the table size will be validated.
v3:
- Don't call on the gamma table since the LUT size is already tested at
property blob upload and we don't have any additional hardware
constraints for that LUT.
Cc: Uma Shankar
Cc: Swati Sharma
Signed-off-by: Matt Roper
Reviewed-by: Uma Shankar
---
drivers/gpu/drm/i915/intel_color.c | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/intel_color.c
index 37fd9ddf762e..bdbe474ad9b2 100644
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@ -609,10 +609,26 @@ int intel_color_check(struct intel_crtc_state *crtc_state)
{
struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
size_t gamma_length, degamma_length;
+ uint32_t tests = DRM_COLOR_LUT_NON_DECREASING;
degamma_length = INTEL_INFO(dev_priv)->color.degamma_lut_size;
gamma_length = INTEL_INFO(dev_priv)->color.gamma_lut_size;
+ /*
+* All of our platforms mandate that the degamma curve be
+* non-decreasing. Additionally, GLK and gen11 only accept a single
+* value for red, green, and blue in the degamma table. Make sure
+* userspace didn't try to pass us something we can't handle.
+*
+* We don't have any extra hardware constraints on the gamma table,
+* so no need to explicitly check it.
+*/
+ if (IS_GEMINILAKE(dev_priv) || INTEL_GEN(dev_priv) >= 11)
+ tests |= DRM_COLOR_LUT_EQUAL_CHANNELS;
+
+ if (drm_color_lut_check(crtc_state->base.degamma_lut, tests) != 0)
+ return -EINVAL;
+
/*
* We allow both degamma & gamma luts at the right size or
* NULL.
--
2.14.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] drm/msm/dpu: fix documentation for intf_type
Fix intf_type description in msm_disp_info to show that
it represents drm encoder mode of the display.
changes in v3:
- introduced in the series
changes in v4:
- none
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/msm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h
index 9cd6a96..4725d52 100644
--- a/drivers/gpu/drm/msm/msm_drv.h
+++ b/drivers/gpu/drm/msm/msm_drv.h
@@ -126,7 +126,7 @@ struct msm_display_topology {
/**
* struct msm_display_info - defines display properties
- * @intf_type: DRM_MODE_CONNECTOR_ display type
+ * @intf_type: DRM_MODE_ENCODER_ type
* @capabilities: Bitmask of display flags
* @num_of_h_tiles: Number of horizontal tiles in case of split interface
* @h_tile_instance:Controller instance used per tile. Number of elements
is
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 3/3] drm/msm/dpu: add display port support in DPU
Add display port support in DPU by creating hooks
for DP encoder enumeration and encoder mode
initialization.
This change is based on the SDM845 Display port
driver changes[1].
changes in v2:
- rebase on [2] (Sean Paul)
- remove unwanted error checks and
switch cases (Jordan Crouse)
changes in v3:
- add dp support after fixing
the current code base for error logging (Sean Paul)
changes in v4:
- avoid duplicate returns (Jordan Crouse)
- get rid of duplicate error logs (Jordan Crouse)
[1] https://lwn.net/Articles/768265/
[2] https://lkml.org/lkml/2018/11/17/87
Signed-off-by: Jeykumar Sankaran
Reviewed-by: Jordan Crouse
Reviewed-by: Sean Paul
---
drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 8 ++--
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 58 +
2 files changed, 54 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
index 0dda4a6..371d17d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
@@ -2031,7 +2031,7 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
{
int ret = 0;
int i = 0;
- enum dpu_intf_type intf_type;
+ enum dpu_intf_type intf_type = INTF_NONE;
struct dpu_enc_phys_init_params phys_params;
if (!dpu_enc || !dpu_kms) {
@@ -2054,9 +2054,9 @@ static int dpu_encoder_setup_display(struct
dpu_encoder_virt *dpu_enc,
case DRM_MODE_ENCODER_DSI:
intf_type = INTF_DSI;
break;
- default:
- DPU_ERROR_ENC(dpu_enc, "unsupported display interface type\n");
- return -EINVAL;
+ case DRM_MODE_ENCODER_TMDS:
+ intf_type = INTF_DP;
+ break;
}
WARN_ON(disp_info->num_of_h_tiles < 1);
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 885bf88..62b400c 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -439,6 +439,31 @@ static int _dpu_kms_initialize_dsi(struct drm_device *dev,
return rc;
}
+static int _dpu_kms_initialize_displayport(struct drm_device *dev,
+ struct msm_drm_private *priv,
+ struct dpu_kms *dpu_kms)
+{
+ struct drm_encoder *encoder = NULL;
+ int rc;
+
+ if (!priv->dp)
+ return 0;
+
+ encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_TMDS);
+ if (IS_ERR(encoder)) {
+ DPU_ERROR("encoder init failed for dsi display\n");
+ return PTR_ERR(encoder);
+ }
+
+ rc = msm_dp_modeset_init(priv->dp, dev, encoder);
+ if (rc) {
+ DPU_ERROR("modeset_init failed for DP, rc = %d\n", rc);
+ drm_encoder_cleanup(encoder);
+ }
+
+ return rc;
+}
+
/**
* _dpu_kms_setup_displays - create encoders, bridges and connectors
* for underlying displays
@@ -451,12 +476,22 @@ static int _dpu_kms_setup_displays(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
+ int rc;
+
+ rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ if (rc)
+ goto fail;
+
+ rc = _dpu_kms_initialize_displayport(dev, priv, dpu_kms);
+ if (rc)
+ goto fail;
+
/**
* Extend this function to initialize other
* types of displays
*/
-
- return _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+fail:
+ return rc;
}
static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
@@ -669,13 +704,20 @@ static void _dpu_kms_set_encoder_mode(struct msm_kms *kms,
info.capabilities = cmd_mode ? MSM_DISPLAY_CAP_CMD_MODE :
MSM_DISPLAY_CAP_VID_MODE;
- /* TODO: No support for DSI swap */
- for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
- if (priv->dsi[i]) {
- info.h_tile_instance[info.num_of_h_tiles] = i;
- info.num_of_h_tiles++;
+ switch (info.intf_type) {
+ case DRM_MODE_ENCODER_DSI:
+ /* TODO: No support for DSI swap */
+ for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
+ if (priv->dsi[i]) {
+ info.h_tile_instance[info.num_of_h_tiles] = i;
+ info.num_of_h_tiles++;
+ }
}
- }
+ break;
+ case DRM_MODE_ENCODER_TMDS:
+ info.num_of_h_tiles = 1;
+ break;
+ };
rc = dpu_encoder_setup(encoder->dev, encoder, );
if (rc)
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux
[PATCH v4 2/3] drm/msm/dpu: handle failures while initializing displays
Bail out KMS hw init on display initialization failures with
proper error logging.
changes in v3:
- introduced in the series
changes in v4:
- avoid duplicate return on errors (Sean Paul)
- avoid spamming errors on failures (Jordon Crouse)
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index d39b745..885bf88 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -405,35 +405,38 @@ static void dpu_kms_wait_for_commit_done(struct msm_kms
*kms,
}
}
-static void _dpu_kms_initialize_dsi(struct drm_device *dev,
+static int _dpu_kms_initialize_dsi(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
struct drm_encoder *encoder = NULL;
- int i, rc;
+ int i, rc = 0;
+
+ if (!(priv->dsi[0] || priv->dsi[1]))
+ return rc;
/*TODO: Support two independent DSI connectors */
encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_DSI);
- if (IS_ERR_OR_NULL(encoder)) {
+ if (IS_ERR(encoder)) {
DPU_ERROR("encoder init failed for dsi display\n");
- return;
+ return PTR_ERR(encoder);
}
priv->encoders[priv->num_encoders++] = encoder;
for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
- if (!priv->dsi[i]) {
- DPU_DEBUG("invalid msm_dsi for ctrl %d\n", i);
- return;
- }
+ if (!priv->dsi[i])
+ continue;
rc = msm_dsi_modeset_init(priv->dsi[i], dev, encoder);
if (rc) {
DPU_ERROR("modeset_init failed for dsi[%d], rc = %d\n",
i, rc);
- continue;
+ break;
}
}
+
+ return rc;
}
/**
@@ -444,16 +447,16 @@ static void _dpu_kms_initialize_dsi(struct drm_device
*dev,
* @dpu_kms:Pointer to dpu kms structure
* Returns: Zero on success
*/
-static void _dpu_kms_setup_displays(struct drm_device *dev,
+static int _dpu_kms_setup_displays(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
- _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
-
/**
* Extend this function to initialize other
* types of displays
*/
+
+ return _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
}
static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
@@ -516,7 +519,9 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms *dpu_kms)
* Create encoder and query display drivers to create
* bridges and connectors
*/
- _dpu_kms_setup_displays(dev, priv, dpu_kms);
+ ret = _dpu_kms_setup_displays(dev, priv, dpu_kms);
+ if (ret)
+ goto fail;
max_crtc_count = min(catalog->mixer_count, priv->num_encoders);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 3/3] dt-bindings: msm/disp: Introduce interconnect bindings for MDSS on SDM845
On Thu, 22 Nov 2018 14:36:53 +0530, Sravanthi Kollukuduru wrote: > Add interconnect properties such as interconnect provider specifier > , the edge source and destination ports which are required by the > interconnect API to configure interconnect path for MDSS. > > Changes in v2: > - none > > Changes in v3: > - Remove common property definitions (Rob Herring) > > Signed-off-by: Sravanthi Kollukuduru > --- > Documentation/devicetree/bindings/display/msm/dpu.txt | 9 + > 1 file changed, 9 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/2] dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings
On Mon, Dec 17, 2018 at 03:20:10PM -0600, Rob Herring wrote:
> On Wed, Dec 12, 2018 at 02:18:47PM -0700, Jordan Crouse wrote:
> > Update the GPU bindings and document the new bindings for the GMU
> > device found with Adreno a6xx targets.
> >
> > Signed-off-by: Jordan Crouse
> > ---
> > .../devicetree/bindings/display/msm/gmu.txt | 56 +++
> > .../devicetree/bindings/display/msm/gpu.txt | 41 +-
> > 2 files changed, 94 insertions(+), 3 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt
> >
> > diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
> > b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > new file mode 100644
> > index ..6152cb551d29
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> > @@ -0,0 +1,56 @@
> > +Qualcomm adreno/snapdragon GMU (Graphics management unit)
> > +
> > +The GMU is a programmable power controller for the GPU. the CPU controls
> > the
> > +GMU which in turn handles power controls for the GPU.
> > +
> > +Required properties:
> > +- compatible:
> > + * "qcom,adreno-gmu"
>
> I probably asked before, but this needs a specific compatible unless you
> have reliable version/capability registers. If you do, please state that
> here.
Most of our decisions are made based on the type of GPU attached but it wouldn't
hurt to make this future proof. I'll do it.
> > +- reg: Physical base address and length of the GMU registers.
> > +- reg-names: Matching names for the register regions
> > + * "gmu"
> > + * "gmu_pdc"
> > + * "gmu_pdc_seg"
> > +- interrupts: The interrupt signals from the GMU.
> > +- interrupt-names: Matching names for the interrupts
> > + * "hfi"
> > + * "gmu"
> > +- clocks: phandles to the device clocks
> > +- clock-names: Matching names for the clocks
> > + * "gmu"
> > + * "cxo"
> > + * "axi"
> > + * "mnoc"
> > +- power-domains: should be <_gpucc GPU_CX_GDSC>
> > +- iommus: phandle to the adreno iommu
> > +- operating-points-v2: phandle to the OPP operating points
> > +
> > +Example:
> > +
> > +/ {
> > + ...
> > +
> > + gmu: gmu@506a000 {
> > + compatible="qcom,adreno-gmu";
> > +
> > + reg = <0x506a000 0x3>,
> > + <0xb28 0x1>,
> > + <0xb48 0x1>;
> > + reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
> > +
> > + interrupts = ,
> > +;
> > + interrupt-names = "hfi", "gmu";
> > +
> > + clocks = < GPU_CC_CX_GMU_CLK>,
> > + < GPU_CC_CXO_CLK>,
> > + < GCC_DDRSS_GPU_AXI_CLK>,
> > + < GCC_GPU_MEMNOC_GFX_CLK>;
> > + clock-names = "gmu", "cxo", "axi", "memnoc";
> > +
> > + power-domains = < GPU_CX_GDSC>;
> > + iommus = <_smmu 5>;
> > +
> > + operating-points-v2 = <_opp_table>;
> > + };
> > +};
> > diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt
> > b/Documentation/devicetree/bindings/display/msm/gpu.txt
> > index 43fac0fe09bb..8d9415180c22 100644
> > --- a/Documentation/devicetree/bindings/display/msm/gpu.txt
> > +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
> > @@ -8,14 +8,21 @@ Required properties:
> >with the chip-id.
> > - reg: Physical base address and length of the controller's registers.
> > - interrupts: The interrupt signal from the gpu.
> > -- clocks: device clocks
> > +- interrupt-names: List of names for the interrupt signals. The following
> > can be
> > + provided:
> > + * "kgsl_3d0_irq"
>
> I'm pretty sure 'kgsl' is not a hardware thing. You don't need *-names
> when there is only one of something.
This has mainly existed just for compatibility issues. We do only have the one
interrupt so lets zap the downstream name and never look back.
> > +- clocks: device clocks (if applicable)
>
> What does this mean? They are now optional? If so, move to an "Optional"
> section. Likewise for the others.
They are indeed optional now.
> Really, you should add a new compatible so we can validate when clocks
> not being present is valid vs. an error in the DT.
We could use the GPU revision for that, but our approach has been to make all
clocks optional for all targets. Eventually when we go to power up if the GPU
core ends up needing a clock and it isn't defined we fail probe at that point.
I'm not sure if that is resilient enough for DT purposes though.
Jordan
--
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH -next] drm/shmob: Fix return value check in shmob_drm_probe
Hi Yue,
Thank you for the patch.
On Monday, 17 December 2018 11:18:30 EET YueHaibing wrote:
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
>
> Fixes: 8f1597c8f1a5 ("drm: shmobile: Perform initialization/cleanup at
> probe/remove time")
> Signed-off-by: YueHaibing
Reviewed-by: Laurent Pinchart
and applied to my tree.
> ---
> drivers/gpu/drm/shmobile/shmob_drm_drv.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> b/drivers/gpu/drm/shmobile/shmob_drm_drv.c index 8554102..f2cfd16 100644
> --- a/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> +++ b/drivers/gpu/drm/shmobile/shmob_drm_drv.c
> @@ -229,8 +229,8 @@ static int shmob_drm_probe(struct platform_device *pdev)
>
> res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> sdev->mmio = devm_ioremap_resource(>dev, res);
> - if (sdev->mmio == NULL)
> - return -ENOMEM;
> + if (IS_ERR(sdev->mmio))
> + return PTR_ERR(sdev->mmio);
>
> ret = shmob_drm_setup_clocks(sdev, pdata->clk_source);
> if (ret < 0)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 1/2] dt-bindings: panel: Add Sitronix ST7701 panel documentation
On Tue, 11 Dec 2018 21:13:57 +0530, Jagan Teki wrote: > Techstar TS8550B MIPI DSI panel is 480x854, 2-lane MIPI DSI LCD panel > with inbuilt ST7701 chip. > > The default regulator names in ST7701 chip is renamed in Techstar TS8550B > so, add specific binding names for them. > > Signed-off-by: Jagan Teki > --- > Changes for v5: > - found the chip from vendor, so added new chip binding > - here is v4: https://patchwork.kernel.org/patch/10680333/ > > .../display/panel/sitronix,st7701.txt | 30 +++ > 1 file changed, 30 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/sitronix,st7701.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/2] dt-bindings: drm/msm/a6xx: Document GMU and update GPU bindings
On Wed, Dec 12, 2018 at 02:18:47PM -0700, Jordan Crouse wrote:
> Update the GPU bindings and document the new bindings for the GMU
> device found with Adreno a6xx targets.
>
> Signed-off-by: Jordan Crouse
> ---
> .../devicetree/bindings/display/msm/gmu.txt | 56 +++
> .../devicetree/bindings/display/msm/gpu.txt | 41 +-
> 2 files changed, 94 insertions(+), 3 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/display/msm/gmu.txt
>
> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.txt
> b/Documentation/devicetree/bindings/display/msm/gmu.txt
> new file mode 100644
> index ..6152cb551d29
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/msm/gmu.txt
> @@ -0,0 +1,56 @@
> +Qualcomm adreno/snapdragon GMU (Graphics management unit)
> +
> +The GMU is a programmable power controller for the GPU. the CPU controls the
> +GMU which in turn handles power controls for the GPU.
> +
> +Required properties:
> +- compatible:
> + * "qcom,adreno-gmu"
I probably asked before, but this needs a specific compatible unless you
have reliable version/capability registers. If you do, please state that
here.
> +- reg: Physical base address and length of the GMU registers.
> +- reg-names: Matching names for the register regions
> + * "gmu"
> + * "gmu_pdc"
> + * "gmu_pdc_seg"
> +- interrupts: The interrupt signals from the GMU.
> +- interrupt-names: Matching names for the interrupts
> + * "hfi"
> + * "gmu"
> +- clocks: phandles to the device clocks
> +- clock-names: Matching names for the clocks
> + * "gmu"
> + * "cxo"
> + * "axi"
> + * "mnoc"
> +- power-domains: should be <_gpucc GPU_CX_GDSC>
> +- iommus: phandle to the adreno iommu
> +- operating-points-v2: phandle to the OPP operating points
> +
> +Example:
> +
> +/ {
> + ...
> +
> + gmu: gmu@506a000 {
> + compatible="qcom,adreno-gmu";
> +
> + reg = <0x506a000 0x3>,
> + <0xb28 0x1>,
> + <0xb48 0x1>;
> + reg-names = "gmu", "gmu_pdc", "gmu_pdc_seq";
> +
> + interrupts = ,
> + ;
> + interrupt-names = "hfi", "gmu";
> +
> + clocks = < GPU_CC_CX_GMU_CLK>,
> + < GPU_CC_CXO_CLK>,
> + < GCC_DDRSS_GPU_AXI_CLK>,
> + < GCC_GPU_MEMNOC_GFX_CLK>;
> + clock-names = "gmu", "cxo", "axi", "memnoc";
> +
> + power-domains = < GPU_CX_GDSC>;
> + iommus = <_smmu 5>;
> +
> + operating-points-v2 = <_opp_table>;
> + };
> +};
> diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt
> b/Documentation/devicetree/bindings/display/msm/gpu.txt
> index 43fac0fe09bb..8d9415180c22 100644
> --- a/Documentation/devicetree/bindings/display/msm/gpu.txt
> +++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
> @@ -8,14 +8,21 @@ Required properties:
>with the chip-id.
> - reg: Physical base address and length of the controller's registers.
> - interrupts: The interrupt signal from the gpu.
> -- clocks: device clocks
> +- interrupt-names: List of names for the interrupt signals. The following
> can be
> + provided:
> + * "kgsl_3d0_irq"
I'm pretty sure 'kgsl' is not a hardware thing. You don't need *-names
when there is only one of something.
> +- clocks: device clocks (if applicable)
What does this mean? They are now optional? If so, move to an "Optional"
section. Likewise for the others.
Really, you should add a new compatible so we can validate when clocks
not being present is valid vs. an error in the DT.
>See ../clocks/clock-bindings.txt for details.
> -- clock-names: the following clocks are required:
> +- clock-names: the following clocks can be provided:
>* "core"
>* "iface"
>* "mem_iface"
> +- iommus: optional phandle to an adreno iommu instance
> +- operating-points-v2: optional phandle to the OPP operating points
> +- qcom,gmu: For a6xx and newer targets a phandle to the GMU device that will
> + control the power for the GPU
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109080] Broken video playback colors on AMD Ryzen 5 (PRO) Mobile 2500U in 18.1 and 18.2
https://bugs.freedesktop.org/show_bug.cgi?id=109080 Bug ID: 109080 Summary: Broken video playback colors on AMD Ryzen 5 (PRO) Mobile 2500U in 18.1 and 18.2 Product: Mesa Version: 18.2 Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: zaj...@gmail.com QA Contact: dri-devel@lists.freedesktop.org Created attachment 142840 --> https://bugs.freedesktop.org/attachment.cgi?id=142840=edit Screenshot for Chromium with corrupted video When playing video on YouTube using Chromium I see broken colors. Info from the YouTube player: Codecs vp09.00.51.08.01.01.01.01 (247) / opus (251) Color bt709 / bt709 I experience this problem on two machines: 1) HP EliteBook 745 G5 with Ryzen 5 PRO 2500U It runs 1.03.01 BIOS with 0x0810100b CPU microcode. 2) MateBook D with Ryzen 5 2500U It runs 1.12 BIOS with 0x08101007 CPU microcode. I've bisected the *fix* down to the: commit 55e7de7b193535133d4324e9f601ae44a0cdd9a7 Author: Boyuan Zhang Date: Wed Oct 17 15:03:30 2018 -0400 radeonsi: enable vcn jpeg decode for raven Enable vcn jpeg decode for raven. Signed-off-by: Boyuan Zhang Reviewed-by: Leo Liu Is that possible to either: 1) cherry-pick those vcn/va fixes to the 18.1 and 18.2 branches 2) disable unsupported formats support in the 18.2 and 18.2 branches please? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v3 2/3] drm/msm/dpu: handle failures while initializing displays
On 2018-12-14 07:22, Sean Paul wrote:
On Thu, Dec 13, 2018 at 10:51:03AM -0800, Jeykumar Sankaran wrote:
Bail out KMS hw init on display initialization failures with
proper error logging.
changes in v3:
- introduced in the series
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 39
+++--
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 685686e..39c8549 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -405,33 +405,36 @@ static void dpu_kms_wait_for_commit_done(struct
msm_kms *kms,
}
}
-static void _dpu_kms_initialize_dsi(struct drm_device *dev,
+static int _dpu_kms_initialize_dsi(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
struct drm_encoder *encoder = NULL;
- int i, rc;
+ int i, rc = 0;
+
+ if (!(priv->dsi[0] || priv->dsi[1]))
It'd be nice to not have to support both blocks if only one is hooked
up.
Perhaps move the TODO below above this check.
+ return rc;
/*TODO: Support two independent DSI connectors */
encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_DSI);
- if (IS_ERR_OR_NULL(encoder)) {
+ if (IS_ERR(encoder)) {
DPU_ERROR("encoder init failed for dsi display\n");
- return;
+ return PTR_ERR(encoder);
}
for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
- if (!priv->dsi[i]) {
- DPU_DEBUG("invalid msm_dsi for ctrl %d\n", i);
- return;
- }
+ if (!priv->dsi[i])
I don't think this is possible given the check at the beginning of the
function
The check at the beginning returns only if BOTH the dsi blocks are NULL.
In case of full hd panel, only one of the dsi block will be active. The
above check is needed to return on the inactive dsi.
Thanks,
Jeykumar S.
+ continue;
rc = msm_dsi_modeset_init(priv->dsi[i], dev, encoder);
if (rc) {
DPU_ERROR("modeset_init failed for dsi[%d], rc =
%d\n",
i, rc);
- continue;
+ return rc;
}
}
+
+ return rc;
nit: You can keep rc uninitialized above and just return 0 here.
}
/**
@@ -442,16 +445,24 @@ static void _dpu_kms_initialize_dsi(struct
drm_device *dev,
* @dpu_kms:Pointer to dpu kms structure
* Returns: Zero on success
*/
-static void _dpu_kms_setup_displays(struct drm_device *dev,
+static int _dpu_kms_setup_displays(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
- _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ int rc = 0;
nit: No need to initialize to 0
+
+ rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ if (rc) {
+ DPU_ERROR("failed to initialize dsi, rc = %d\n", rc);
+ return rc;
+ }
/**
* Extend this function to initialize other
* types of displays
*/
+
+ return rc;
}
static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
@@ -517,7 +528,11 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms
*dpu_kms)
* Create encoder and query display drivers to create
* bridges and connectors
*/
- _dpu_kms_setup_displays(dev, priv, dpu_kms);
+ ret = _dpu_kms_setup_displays(dev, priv, dpu_kms);
+ if (ret) {
+ DPU_ERROR("failed to setup display, rc = %d\n", ret);
+ goto fail;
+ }
max_crtc_count = min(catalog->mixer_count,
(u32)dev->mode_config.num_encoder);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [WIP PATCH 02/15] drm/dp_mst: Refactor drm_dp_update_payload_part1()
On 2018-12-14 3:47 a.m., Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 08:25:31PM -0500, Lyude Paul wrote:
>> There should be no functional changes here
>
> Would be good to explain what you did refactor here, instead of me trying
> to reconstruct it from the patch. Especially pre-coffee that helps :-)
I concur. Something like "use local variables to improve readability".
With that fixed this is
Reviewed-by: Harry Wentland
Harry
>>
>> Signed-off-by: Lyude Paul
>> Cc: Juston Li
>> ---
>> drivers/gpu/drm/drm_dp_mst_topology.c | 71 ---
>> 1 file changed, 42 insertions(+), 29 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index 9b1b5c9b1fa0..2ab16c9e6243 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -1879,39 +1879,48 @@ int drm_dp_update_payload_part1(struct
>> drm_dp_mst_topology_mgr *mgr)
>>
>> mutex_lock(>payload_lock);
>> for (i = 0; i < mgr->max_payloads; i++) {
>> +struct drm_dp_vcpi *vcpi = mgr->proposed_vcpis[i];
>> +struct drm_dp_payload *payload = >payloads[i];
>> +
>> /* solve the current payloads - compare to the hw ones
>> - update the hw view */
>> req_payload.start_slot = cur_slots;
>> -if (mgr->proposed_vcpis[i]) {
>> -port = container_of(mgr->proposed_vcpis[i], struct
>> drm_dp_mst_port, vcpi);
>> +if (vcpi) {
>> +port = container_of(vcpi, struct drm_dp_mst_port,
>> +vcpi);
>> port = drm_dp_get_validated_port_ref(mgr, port);
>> if (!port) {
>> mutex_unlock(>payload_lock);
>> return -EINVAL;
>> }
>> -req_payload.num_slots =
>> mgr->proposed_vcpis[i]->num_slots;
>> -req_payload.vcpi = mgr->proposed_vcpis[i]->vcpi;
>> +req_payload.num_slots = vcpi->num_slots;
>> +req_payload.vcpi = vcpi->vcpi;
>> } else {
>> port = NULL;
>> req_payload.num_slots = 0;
>> }
>>
>> -mgr->payloads[i].start_slot = req_payload.start_slot;
>> +payload->start_slot = req_payload.start_slot;
>> /* work out what is required to happen with this payload */
>> -if (mgr->payloads[i].num_slots != req_payload.num_slots) {
>> +if (payload->num_slots != req_payload.num_slots) {
>>
>> /* need to push an update for this payload */
>> if (req_payload.num_slots) {
>> -drm_dp_create_payload_step1(mgr,
>> mgr->proposed_vcpis[i]->vcpi, _payload);
>> -mgr->payloads[i].num_slots =
>> req_payload.num_slots;
>> -mgr->payloads[i].vcpi = req_payload.vcpi;
>> -} else if (mgr->payloads[i].num_slots) {
>> -mgr->payloads[i].num_slots = 0;
>> -drm_dp_destroy_payload_step1(mgr, port,
>> mgr->payloads[i].vcpi, >payloads[i]);
>> -req_payload.payload_state =
>> mgr->payloads[i].payload_state;
>> -mgr->payloads[i].start_slot = 0;
>> +drm_dp_create_payload_step1(mgr, vcpi->vcpi,
>> +_payload);
>> +payload->num_slots = req_payload.num_slots;
>> +payload->vcpi = req_payload.vcpi;
>> +
>> +} else if (payload->num_slots) {
>> +payload->num_slots = 0;
>> +drm_dp_destroy_payload_step1(mgr, port,
>> + payload->vcpi,
>> + payload);
>> +req_payload.payload_state =
>> +payload->payload_state;
>> +payload->start_slot = 0;
>> }
>> -mgr->payloads[i].payload_state =
>> req_payload.payload_state;
>> +payload->payload_state = req_payload.payload_state;
>> }
>> cur_slots += req_payload.num_slots;
>>
>> @@ -1920,22 +1929,26 @@ int drm_dp_update_payload_part1(struct
>> drm_dp_mst_topology_mgr *mgr)
>> }
>>
>> for (i = 0; i < mgr->max_payloads; i++) {
>> -if (mgr->payloads[i].payload_state == DP_PAYLOAD_DELETE_LOCAL) {
>> -DRM_DEBUG_KMS("removing payload %d\n", i);
>> -for (j = i; j < mgr->max_payloads - 1; j++) {
>> -memcpy(>payloads[j], >payloads[j +
Re: [PATCH v3 03/10] phy: Add MIPI D-PHY configuration options
Hi Maxime, On Mon, Dec 17, 2018 at 04:49:21PM +0100, Maxime Ripard wrote: > Hi Sakari, > > Thanks for your feedback. > > On Thu, Dec 13, 2018 at 10:49:28PM +0200, sakari.ai...@iki.fi wrote: > > > + /** > > > + * @lanes: > > > + * > > > + * Number of active data lanes used for the transmissions. > > > > Could you add that these are the first "lanes" number of lanes from what > > are available? > > I'm not quite sure I understood this part though, what did you mean? A number of lanes are routed between the two devices on hardware, and this field is specifying how many of them are in use. In order for the bus to function, both ends need to be in agreement on which of these lanes are actually being used. The current practice I've seen without exceptions is that these are the first n lanes. -- Regards, Sakari Ailus ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [WIP PATCH 01/15] drm/dp_mst: Remove bogus conditional in drm_dp_update_payload_part1()
On 2018-12-14 3:42 a.m., Daniel Vetter wrote:
> On Thu, Dec 13, 2018 at 08:25:30PM -0500, Lyude Paul wrote:
>> There's no reason we need this, it's just confusing looking.
>>
>> Signed-off-by: Lyude Paul
>> Cc: Juston Li
>> ---
>> drivers/gpu/drm/drm_dp_mst_topology.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
>> b/drivers/gpu/drm/drm_dp_mst_topology.c
>> index ad0fb6d003be..9b1b5c9b1fa0 100644
>> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
>> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
>> @@ -1896,9 +1896,7 @@ int drm_dp_update_payload_part1(struct
>> drm_dp_mst_topology_mgr *mgr)
>> req_payload.num_slots = 0;
>> }
>>
>> -if (mgr->payloads[i].start_slot != req_payload.start_slot) {
>> -mgr->payloads[i].start_slot = req_payload.start_slot;
>> -}
>> +mgr->payloads[i].start_slot = req_payload.start_slot;
>
> Entertaining!
>
> Reviewed-by: Daniel Vetter
>
Reviewed-by: Harry Wentland
Harry
>> /* work out what is required to happen with this payload */
>> if (mgr->payloads[i].num_slots != req_payload.num_slots) {
>>
>> --
>> 2.19.2
>>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm: Make drmNodeIsDRM() public.
Emil Velikov writes: > Hi Christopher, > > On Tue, 20 Nov 2018 at 04:30, Christopher James Halse Rogers > wrote: >> >> I have wanted this code in Mir, so it's plausibly useful elsewhere, >> particularly if the DRM device major number is going to become >> dynamic. >> > Can you elaborate/link to the code that uses the major/minor? > Fiddling with those manually is rather error prone most often than not. Yeah, I think this shouldn't be part of the API. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/2] drm/sched: Rework HW fence processing.
Expedite job deletion from ring mirror list to the HW fence signal
callback instead from finish_work, together with waiting for all
such fences to signal in drm_sched_stop we garantee that
already signaled job will not be processed twice.
Remove the sched finish fence callback and just submit finish_work
directly from the HW fence callback.
v2: Fix comments.
v3: Attach hw fence cb to sched_job
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/scheduler/sched_main.c | 55 +-
include/drm/gpu_scheduler.h| 6 ++--
2 files changed, 29 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 1cf9541..40df9b9 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -284,8 +284,6 @@ static void drm_sched_job_finish(struct work_struct *work)
cancel_delayed_work_sync(>work_tdr);
spin_lock_irqsave(>job_list_lock, flags);
- /* remove job from ring_mirror_list */
- list_del_init(_job->node);
/* queue TDR for next job */
drm_sched_start_timeout(sched);
spin_unlock_irqrestore(>job_list_lock, flags);
@@ -293,22 +291,11 @@ static void drm_sched_job_finish(struct work_struct *work)
sched->ops->free_job(s_job);
}
-static void drm_sched_job_finish_cb(struct dma_fence *f,
- struct dma_fence_cb *cb)
-{
- struct drm_sched_job *job = container_of(cb, struct drm_sched_job,
-finish_cb);
- schedule_work(>finish_work);
-}
-
static void drm_sched_job_begin(struct drm_sched_job *s_job)
{
struct drm_gpu_scheduler *sched = s_job->sched;
unsigned long flags;
- dma_fence_add_callback(_job->s_fence->finished, _job->finish_cb,
- drm_sched_job_finish_cb);
-
spin_lock_irqsave(>job_list_lock, flags);
list_add_tail(_job->node, >ring_mirror_list);
drm_sched_start_timeout(sched);
@@ -389,7 +376,7 @@ void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
drm_sched_job *bad)
list_for_each_entry_reverse(s_job, >ring_mirror_list, node) {
if (s_job->s_fence->parent &&
dma_fence_remove_callback(s_job->s_fence->parent,
- _job->s_fence->cb)) {
+ _job->cb)) {
dma_fence_put(s_job->s_fence->parent);
s_job->s_fence->parent = NULL;
atomic_dec(>hw_rq_count);
@@ -425,31 +412,34 @@ EXPORT_SYMBOL(drm_sched_stop);
void drm_sched_start(struct drm_gpu_scheduler *sched, bool full_recovery)
{
struct drm_sched_job *s_job, *tmp;
- unsigned long flags;
int r;
if (!full_recovery)
goto unpark;
- spin_lock_irqsave(>job_list_lock, flags);
+ /*
+* Locking the list is not required here as the sched thread is parked
+* so no new jobs are being pushed in to HW and in drm_sched_stop we
+* flushed all the jobs who were still in mirror list but who already
+* signaled and removed them self from the list. Also concurrent
+* GPU recovers can't run in parallel.
+*/
list_for_each_entry_safe(s_job, tmp, >ring_mirror_list, node) {
- struct drm_sched_fence *s_fence = s_job->s_fence;
struct dma_fence *fence = s_job->s_fence->parent;
if (fence) {
- r = dma_fence_add_callback(fence, _fence->cb,
+ r = dma_fence_add_callback(fence, _job->cb,
drm_sched_process_job);
if (r == -ENOENT)
- drm_sched_process_job(fence, _fence->cb);
+ drm_sched_process_job(fence, _job->cb);
else if (r)
DRM_ERROR("fence add callback failed (%d)\n",
r);
} else
- drm_sched_process_job(NULL, _fence->cb);
+ drm_sched_process_job(NULL, _job->cb);
}
drm_sched_start_timeout(sched);
- spin_unlock_irqrestore(>job_list_lock, flags);
unpark:
kthread_unpark(sched->thread);
@@ -598,18 +588,27 @@ drm_sched_select_entity(struct drm_gpu_scheduler *sched)
*/
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb *cb)
{
- struct drm_sched_fence *s_fence =
- container_of(cb, struct drm_sched_fence, cb);
+ struct drm_sched_job *s_job = container_of(cb, struct drm_sched_job,
cb);
+ struct drm_sched_fence *s_fence = s_job->s_fence;
struct drm_gpu_scheduler *sched = s_fence->sched;
+ unsigned long
[PATCH v4 1/2] drm/sched: Refactor ring mirror list handling.
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 HW fences
to complete before rerunning the jobs.
v2: Fix resubmission of guilty job into HW after refactoring.
v4:
Full restart for all the jobs, not only from guilty ring.
Extract karma increase into standalone function.
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +--
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 8 +-
drivers/gpu/drm/scheduler/sched_main.c | 164 +
drivers/gpu/drm/v3d/v3d_sched.c| 9 +-
include/drm/gpu_scheduler.h| 9 +-
5 files changed, 118 insertions(+), 89 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 8a078f4..8ac4f43 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3298,12 +3298,7 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
- kthread_park(ring->sched.thread);
-
- if (job && job->base.sched != >sched)
- continue;
-
- drm_sched_hw_job_reset(>sched, job ? >base : NULL);
+ drm_sched_stop(>sched, job ? >base : NULL);
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
@@ -3454,14 +3449,10 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev,
if (!ring || !ring->sched.thread)
continue;
- /* only need recovery sched of the given job's ring
-* or all rings (in the case @job is NULL)
-* after above amdgpu_reset accomplished
-*/
- if ((!job || job->base.sched == >sched) &&
!adev->asic_reset_res)
- drm_sched_job_recovery(>sched);
+ if (!adev->asic_reset_res)
+ drm_sched_resubmit_jobs(>sched);
- kthread_unpark(ring->sched.thread);
+ drm_sched_start(>sched, !adev->asic_reset_res);
}
if (!amdgpu_device_has_dc_support(adev)) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 49a6763..d7075cd 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,16 +109,16 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
}
/* block scheduler */
- kthread_park(gpu->sched.thread);
- drm_sched_hw_job_reset(>sched, sched_job);
+ drm_sched_stop(>sched, sched_job);
/* get the GPU back into the init state */
etnaviv_core_dump(gpu);
etnaviv_gpu_recover_hang(gpu);
+ drm_sched_resubmit_jobs(>sched);
+
/* restart scheduler after GPU is usable again */
- drm_sched_job_recovery(>sched);
- kthread_unpark(gpu->sched.thread);
+ drm_sched_start(>sched, true);
}
static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index dbb6906..1cf9541 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -60,8 +60,6 @@
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb
*cb);
-static void drm_sched_expel_job_unlocked(struct drm_sched_job *s_job);
-
/**
* drm_sched_rq_init - initialize a given run queue struct
*
@@ -335,6 +333,41 @@ static void drm_sched_job_timedout(struct work_struct
*work)
spin_unlock_irqrestore(>job_list_lock, flags);
}
+static void drm_sched_increase_karma(struct drm_sched_job *bad)
+{
+ int i;
+ struct drm_sched_entity *tmp;
+ struct drm_sched_entity *entity;
+ struct drm_gpu_scheduler *sched = bad->sched;
+
+ /* don't increase @bad's karma if it's from KERNEL RQ,
+* because sometimes GPU hang would cause kernel jobs (like VM updating
jobs)
+* corrupt but keep in mind that kernel jobs always considered good.
+*/
+ if (bad->s_priority != DRM_SCHED_PRIORITY_KERNEL) {
+ atomic_inc(>karma);
+ for (i = DRM_SCHED_PRIORITY_MIN; i < DRM_SCHED_PRIORITY_KERNEL;
+i++) {
+ struct drm_sched_rq *rq = >sched_rq[i];
+
+ spin_lock(>lock);
+ list_for_each_entry_safe(entity, tmp, >entities,
list) {
+ if (bad->s_fence->scheduled.context ==
+
Re: VC4 DRM
Sergey Suloev writes: > Eric, thanks for answer, > > I am in doubt the type of my panel. It is Himax HX8379A-based panel. > Is there a deterministic way to find out which type of panel I have, > video or command ? You have to find your panel's documentation, existing drivers, etc. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drivers/base: use a worker for sysfs unbind
On Thu, Dec 13, 2018 at 07:09:15PM +0100, Rafael J. Wysocki wrote: > On Thu, Dec 13, 2018 at 5:25 PM Daniel Vetter wrote: > > > > On Thu, Dec 13, 2018 at 5:18 PM Rafael J. Wysocki wrote: > > > > > > On Thu, Dec 13, 2018 at 1:36 PM Daniel Vetter > > > wrote: > > [cut] > > > > > I can do the old code exactly, but afaict the non-NULL parent just > > > > takes care of the parent bus locking for us, instead of hand-rolling > > > > it in the caller. But if I missed something, I can easily undo that > > > > part. > > > > > > It is different if device links are present, but I'm not worried about > > > that case honestly. :-) > > > > What would change with device links? We have some cleanup plans to > > remove our usage for early/late s/r hooks with a device link, to make > > sure i915 resumes before snd_hda_intel. Digging more into the code I > > only see the temporary dropping of the parent's device_lock, but I > > have no idea what that even implies ... > > That's just it (which is why I said I was not worried). > > Running device_links_unbind_consumers() with the parent lock held may > deadlock if another child of the same parent also is a consumer of the > current device (which really is a corner case), but the current code > has this problem - it goes away with your change. > > But dev->bus->need_parent_lock checks are missing in there AFAICS, let > me cut a patch to fix that. With your patch before this one, are you ok with mine? Or want me to respin with a different flavour? btw threading somehow broke apart, Chris Wilson r-b stamped this one on intel-gfx: https://patchwork.freedesktop.org/patch/267220/ Reviewed-by: Chris Wilson Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm: Unexport drm_crtc_force_disable
It's a legacy kms only thing, good to hide it better now that all
those old drivers use the legacy crtc helpers directly.
Reviewed-by: Alex Deucher
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
---
drivers/gpu/drm/drm_crtc.c | 10 --
drivers/gpu/drm/drm_crtc_internal.h | 1 +
include/drm/drm_crtc.h | 1 -
3 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 1593dd6cdfb7..f660819d406e 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -93,15 +93,6 @@ struct drm_crtc *drm_crtc_from_index(struct drm_device *dev,
int idx)
}
EXPORT_SYMBOL(drm_crtc_from_index);
-/**
- * drm_crtc_force_disable - Forcibly turn off a CRTC
- * @crtc: CRTC to turn off
- *
- * Note: This should only be used by non-atomic legacy drivers.
- *
- * Returns:
- * Zero on success, error code on failure.
- */
int drm_crtc_force_disable(struct drm_crtc *crtc)
{
struct drm_mode_set set = {
@@ -112,7 +103,6 @@ int drm_crtc_force_disable(struct drm_crtc *crtc)
return drm_mode_set_config_internal();
}
-EXPORT_SYMBOL(drm_crtc_force_disable);
/**
* drm_crtc_force_disable_all - Forcibly turn off all enabled CRTCs
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 86893448f486..216f2a9ee3d4 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -50,6 +50,7 @@ int drm_crtc_check_viewport(const struct drm_crtc *crtc,
const struct drm_framebuffer *fb);
int drm_crtc_register_all(struct drm_device *dev);
void drm_crtc_unregister_all(struct drm_device *dev);
+int drm_crtc_force_disable(struct drm_crtc *crtc);
struct dma_fence *drm_crtc_create_fence(struct drm_crtc *crtc);
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 39c3900aab3c..b45bec0b7a9c 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1149,7 +1149,6 @@ static inline uint32_t drm_crtc_mask(const struct
drm_crtc *crtc)
return 1 << drm_crtc_index(crtc);
}
-int drm_crtc_force_disable(struct drm_crtc *crtc);
int drm_crtc_force_disable_all(struct drm_device *dev);
int drm_mode_set_config_internal(struct drm_mode_set *set);
--
2.20.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm/nouveau: Stop using drm_crtc_force_disable
The correct way for legacy drivers to update properties that need to do a full modeset, is to do a full modeset. Note that we don't need to call the drm_mode_config_internal helper because we're not changing any of the refcounted paramters. v2: Fixup error handling (Ville). Since the old code didn't bother I decided to just delete it instead of adding even more code for just error handling. Cc: Ville Syrjälä Reviewed-by: Alex Deucher (v1) Cc: Sean Paul Signed-off-by: Daniel Vetter --- drivers/gpu/drm/nouveau/dispnv04/tvnv17.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c index 6a4ca139cf5d..8fd8124d72ba 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c +++ b/drivers/gpu/drm/nouveau/dispnv04/tvnv17.c @@ -750,7 +750,9 @@ static int nv17_tv_set_property(struct drm_encoder *encoder, /* Disable the crtc to ensure a full modeset is * performed whenever it's turned on again. */ if (crtc) - drm_crtc_force_disable(crtc); + drm_crtc_helper_set_mode(crtc, >mode, +crtc->x, crtc->y, +crtc->primary->fb); } return 0; -- 2.20.0.rc1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/7] drm: Move the legacy kms disable_all helper to crtc helpers
It's not a core function, and the matching atomic functions are also
not in the core. Plus the suspend/resume helper is also already there.
Needs a tiny bit of open-coding, but less midlayer beats that I think.
v2: Rebase onto ast (which gained a new user).
Cc: Sam Bobroff
Reviewed-by: Alex Deucher
Reviewed-by: Sean Paul
Signed-off-by: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Ben Skeggs
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: Rex Zhu
Cc: Andrey Grodzovsky
Cc: Huang Rui
Cc: Shaoyun Liu
Cc: Monk Liu
Cc: nouv...@lists.freedesktop.org
Cc: amd-...@lists.freedesktop.org
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
drivers/gpu/drm/ast/ast_fb.c | 2 +-
drivers/gpu/drm/drm_crtc.c | 31 ---
drivers/gpu/drm/drm_crtc_helper.c | 35 ++
drivers/gpu/drm/nouveau/nouveau_display.c | 2 +-
drivers/gpu/drm/radeon/radeon_display.c| 2 +-
include/drm/drm_crtc.h | 2 --
include/drm/drm_crtc_helper.h | 1 +
8 files changed, 40 insertions(+), 37 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index b60afeade50a..00c86c33f9a2 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2708,7 +2708,7 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
amdgpu_irq_disable_all(adev);
if (adev->mode_info.mode_config_initialized){
if (!amdgpu_device_has_dc_support(adev))
- drm_crtc_force_disable_all(adev->ddev);
+ drm_helper_force_disable_all(adev->ddev);
else
drm_atomic_helper_shutdown(adev->ddev);
}
diff --git a/drivers/gpu/drm/ast/ast_fb.c b/drivers/gpu/drm/ast/ast_fb.c
index c2e41369adcf..75f867d00031 100644
--- a/drivers/gpu/drm/ast/ast_fb.c
+++ b/drivers/gpu/drm/ast/ast_fb.c
@@ -261,7 +261,7 @@ static void ast_fbdev_destroy(struct drm_device *dev,
{
struct ast_framebuffer *afb = >afb;
- drm_crtc_force_disable_all(dev);
+ drm_helper_force_disable_all(dev);
drm_fb_helper_unregister_fbi(>helper);
if (afb->obj) {
diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index f660819d406e..7dabbaf033a1 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -104,37 +104,6 @@ int drm_crtc_force_disable(struct drm_crtc *crtc)
return drm_mode_set_config_internal();
}
-/**
- * drm_crtc_force_disable_all - Forcibly turn off all enabled CRTCs
- * @dev: DRM device whose CRTCs to turn off
- *
- * Drivers may want to call this on unload to ensure that all displays are
- * unlit and the GPU is in a consistent, low power state. Takes modeset locks.
- *
- * Note: This should only be used by non-atomic legacy drivers. For an atomic
- * version look at drm_atomic_helper_shutdown().
- *
- * Returns:
- * Zero on success, error code on failure.
- */
-int drm_crtc_force_disable_all(struct drm_device *dev)
-{
- struct drm_crtc *crtc;
- int ret = 0;
-
- drm_modeset_lock_all(dev);
- drm_for_each_crtc(crtc, dev)
- if (crtc->enabled) {
- ret = drm_crtc_force_disable(crtc);
- if (ret)
- goto out;
- }
-out:
- drm_modeset_unlock_all(dev);
- return ret;
-}
-EXPORT_SYMBOL(drm_crtc_force_disable_all);
-
static unsigned int drm_num_crtcs(struct drm_device *dev)
{
unsigned int num = 0;
diff --git a/drivers/gpu/drm/drm_crtc_helper.c
b/drivers/gpu/drm/drm_crtc_helper.c
index a3c81850e755..23159eb494f1 100644
--- a/drivers/gpu/drm/drm_crtc_helper.c
+++ b/drivers/gpu/drm/drm_crtc_helper.c
@@ -984,3 +984,38 @@ void drm_helper_resume_force_mode(struct drm_device *dev)
drm_modeset_unlock_all(dev);
}
EXPORT_SYMBOL(drm_helper_resume_force_mode);
+
+/**
+ * drm_helper_force_disable_all - Forcibly turn off all enabled CRTCs
+ * @dev: DRM device whose CRTCs to turn off
+ *
+ * Drivers may want to call this on unload to ensure that all displays are
+ * unlit and the GPU is in a consistent, low power state. Takes modeset locks.
+ *
+ * Note: This should only be used by non-atomic legacy drivers. For an atomic
+ * version look at drm_atomic_helper_shutdown().
+ *
+ * Returns:
+ * Zero on success, error code on failure.
+ */
+int drm_helper_force_disable_all(struct drm_device *dev)
+{
+ struct drm_crtc *crtc;
+ int ret = 0;
+
+ drm_modeset_lock_all(dev);
+ drm_for_each_crtc(crtc, dev)
+ if (crtc->enabled) {
+ struct drm_mode_set set = {
+ .crtc = crtc,
+ };
+
+ ret = drm_mode_set_config_internal();
+ if (ret)
+
[PATCH 6/7] drm/tda998x: Don't set dpms hook
Doesn't do anything for atomic drivers.
Signed-off-by: Daniel Vetter
Cc: Russell King
---
drivers/gpu/drm/i2c/tda998x_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
b/drivers/gpu/drm/i2c/tda998x_drv.c
index a7c39f39793f..f8a1d70a31c7 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -1122,7 +1122,6 @@ static void tda998x_connector_destroy(struct
drm_connector *connector)
}
static const struct drm_connector_funcs tda998x_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
.reset = drm_atomic_helper_connector_reset,
.fill_modes = drm_helper_probe_single_connector_modes,
.detect = tda998x_connector_detect,
--
2.20.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] drm/arc: Don't set the dpms hook
Doesn't do anything for atomic.
Signed-off-by: Daniel Vetter
Cc: Alexey Brodkin
---
drivers/gpu/drm/arc/arcpgu_sim.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_sim.c b/drivers/gpu/drm/arc/arcpgu_sim.c
index 68629e614990..6530d88f7293 100644
--- a/drivers/gpu/drm/arc/arcpgu_sim.c
+++ b/drivers/gpu/drm/arc/arcpgu_sim.c
@@ -51,7 +51,6 @@ arcpgu_drm_connector_helper_funcs = {
};
static const struct drm_connector_funcs arcpgu_drm_connector_funcs = {
- .dpms = drm_helper_connector_dpms,
.reset = drm_atomic_helper_connector_reset,
.fill_modes = drm_helper_probe_single_connector_modes,
.destroy = arcpgu_drm_connector_destroy,
--
2.20.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/7] drm/ch7006: Stop using drm_crtc_force_disable
The correct way for legacy drivers to update properties that need to
do a full modeset, is to do a full modeset.
Note that we don't need to call the drm_mode_config_internal helper
because we're not changing any of the refcounted paramters.
v2: Fixup error handling (Ville). Since the old code didn't bother
I decided to just delete it instead of adding even more code for just
error handling.
Cc: Ville Syrjälä
Reviewed-by: Alex Deucher (v1)
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i2c/ch7006_drv.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i2c/ch7006_drv.c b/drivers/gpu/drm/i2c/ch7006_drv.c
index 544a8a2d3562..b91e48d2190d 100644
--- a/drivers/gpu/drm/i2c/ch7006_drv.c
+++ b/drivers/gpu/drm/i2c/ch7006_drv.c
@@ -359,10 +359,10 @@ static int ch7006_encoder_set_property(struct drm_encoder
*encoder,
if (modes_changed) {
drm_helper_probe_single_connector_modes(connector, 0, 0);
- /* Disable the crtc to ensure a full modeset is
-* performed whenever it's turned on again. */
if (crtc)
- drm_crtc_force_disable(crtc);
+ drm_crtc_helper_set_mode(crtc, >mode,
+crtc->x, crtc->y,
+crtc->primary->fb);
}
return 0;
--
2.20.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [PATCH v3 2/3] drm/msm/dpu: handle failures while initializing displays
On 2018-12-14 07:22, Sean Paul wrote:
On Thu, Dec 13, 2018 at 10:51:03AM -0800, Jeykumar Sankaran wrote:
Bail out KMS hw init on display initialization failures with
proper error logging.
changes in v3:
- introduced in the series
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 39
+++--
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
index 685686e..39c8549 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c
@@ -405,33 +405,36 @@ static void dpu_kms_wait_for_commit_done(struct
msm_kms *kms,
}
}
-static void _dpu_kms_initialize_dsi(struct drm_device *dev,
+static int _dpu_kms_initialize_dsi(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
struct drm_encoder *encoder = NULL;
- int i, rc;
+ int i, rc = 0;
+
+ if (!(priv->dsi[0] || priv->dsi[1]))
It'd be nice to not have to support both blocks if only one is hooked
up.
Perhaps move the TODO below above this check.
For dual DSI panels (e.g: MTP panels), both of these blocks will be
populated.
TODO comment below is to convey that the support for two independent
single DSI
panels is not yet available in DPU.
Thanks and Regards,
Jeykumar S.
+ return rc;
/*TODO: Support two independent DSI connectors */
encoder = dpu_encoder_init(dev, DRM_MODE_ENCODER_DSI);
- if (IS_ERR_OR_NULL(encoder)) {
+ if (IS_ERR(encoder)) {
DPU_ERROR("encoder init failed for dsi display\n");
- return;
+ return PTR_ERR(encoder);
}
for (i = 0; i < ARRAY_SIZE(priv->dsi); i++) {
- if (!priv->dsi[i]) {
- DPU_DEBUG("invalid msm_dsi for ctrl %d\n", i);
- return;
- }
+ if (!priv->dsi[i])
I don't think this is possible given the check at the beginning of the
function
+ continue;
rc = msm_dsi_modeset_init(priv->dsi[i], dev, encoder);
if (rc) {
DPU_ERROR("modeset_init failed for dsi[%d], rc =
%d\n",
i, rc);
- continue;
+ return rc;
}
}
+
+ return rc;
nit: You can keep rc uninitialized above and just return 0 here.
}
/**
@@ -442,16 +445,24 @@ static void _dpu_kms_initialize_dsi(struct
drm_device *dev,
* @dpu_kms:Pointer to dpu kms structure
* Returns: Zero on success
*/
-static void _dpu_kms_setup_displays(struct drm_device *dev,
+static int _dpu_kms_setup_displays(struct drm_device *dev,
struct msm_drm_private *priv,
struct dpu_kms *dpu_kms)
{
- _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ int rc = 0;
nit: No need to initialize to 0
+
+ rc = _dpu_kms_initialize_dsi(dev, priv, dpu_kms);
+ if (rc) {
+ DPU_ERROR("failed to initialize dsi, rc = %d\n", rc);
+ return rc;
+ }
/**
* Extend this function to initialize other
* types of displays
*/
+
+ return rc;
}
static void _dpu_kms_drm_obj_destroy(struct dpu_kms *dpu_kms)
@@ -517,7 +528,11 @@ static int _dpu_kms_drm_obj_init(struct dpu_kms
*dpu_kms)
* Create encoder and query display drivers to create
* bridges and connectors
*/
- _dpu_kms_setup_displays(dev, priv, dpu_kms);
+ ret = _dpu_kms_setup_displays(dev, priv, dpu_kms);
+ if (ret) {
+ DPU_ERROR("failed to setup display, rc = %d\n", ret);
+ goto fail;
+ }
max_crtc_count = min(catalog->mixer_count,
(u32)dev->mode_config.num_encoder);
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora
Forum,
a Linux Foundation Collaborative Project
___
Freedreno mailing list
freedr...@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/freedreno
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [DPU PATCH v2] drm/msm/dpu: Change RGB565 and BGR565 format map.
On 2018-12-14 11:46, Tanmay Shah wrote:
Red and Blue colors will be interchanged on display with
current format maps for RGB565 and BGR565.
Change both format maps to display correct colors.
You can drop "DPU PATCH" prefix in the patches.
Can you also provide history on what has changed since v1.
Thanks,
Jeykumar S.
Signed-off-by: Tanmay Shah
---
drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
index d53abc8ce670..f59fe1a9f4b9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.c
@@ -263,13 +263,13 @@ static const struct dpu_format dpu_format_map[] =
{
INTERLEAVED_RGB_FMT(RGB565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
- C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
+ C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),
INTERLEAVED_RGB_FMT(BGR565,
0, COLOR_5BIT, COLOR_6BIT, COLOR_5BIT,
- C2_R_Cr, C0_G_Y, C1_B_Cb, 0, 3,
+ C1_B_Cb, C0_G_Y, C2_R_Cr, 0, 3,
false, 2, 0,
DPU_FETCH_LINEAR, 1),
--
Jeykumar S
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/1] drm/i915: Enable fastset by default, except on initial modeset
On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote: > Hi All, > > As discussed a while ago, I would like to see us enable fastboot by > default, starting with Skylake / GEN9 and newer hardware, so that we can > avoid an unnecessary modeset at boot and move to a truely flickerfree boot. > > During our previous discussion about this Maarten mentioned that a first > step would be to get this patch from him upstream. So I'm hereby > resubmitting it, with a small fix. Hopefully the CI will like it better > this time (if not we will need to investigate) and once this passes CI > I hope this can be reviewed quickly and we can get this upstream. I honestly believe the first step is to make sure FBC, PSR, DRRS features gets enabled somehow with fastboot. Maybe DSC as well?! Right now as I can remember FBC, PSR, and DRRS will get disabled if fastboot is used because we just enable those when enabling the pipe. > > I will also be sending out a follow-up patch which actually makes fastboot > the default on GEN9 and newer, I will mark that as RFC for now since based > on our previous discussion this patch should be landed first. > > Regards, > > Hans > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/2] libdrm: Use DRM_IOCTL_GET_PCIINFO on DragonFly
On Wed, 12 Dec 2018 at 19:49, François Tigeot wrote: > > It is a cleaner and less fragile way to get PCI IDs than the one > currently used by local DPorts patches. > Thanks for these François. Props to Ilia for pushing these. JFYI, once DragonFly gets PCI dynamic power management, the team may want to reconsider the ioctl approach. Powering off/on the GPU (to issue the ioctl) may take some time, In the odd case the GPU may lock-up :-( -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm/sched: Refactor ring mirror list handling.
Am 17.12.18 um 17:57 schrieb Grodzovsky, Andrey:
>
> On 12/17/2018 10:27 AM, Christian König wrote:
>> Am 10.12.18 um 22:43 schrieb Andrey Grodzovsky:
>>> 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 HW fences
>>> to complete before rerunning the jobs.
>>>
>>> v2: Fix resubmission of guilty job into HW after refactoring.
>>>
>>> Suggested-by: Christian Koenig
>>> Signed-off-by: Andrey Grodzovsky
>>> ---
>>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++--
>>> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 8 +--
>>> drivers/gpu/drm/scheduler/sched_main.c | 110
>>> ++---
>>> drivers/gpu/drm/v3d/v3d_sched.c | 11 +--
>>> include/drm/gpu_scheduler.h | 10 ++-
>>> 5 files changed, 95 insertions(+), 61 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> index ef36cc5..42111d5 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>>> @@ -3292,17 +3292,16 @@ static int
>>> amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
>>> /* block all schedulers and reset given job's ring */
>>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>>> struct amdgpu_ring *ring = adev->rings[i];
>>> + bool park_only = job && job->base.sched != >sched;
>>> if (!ring || !ring->sched.thread)
>>> continue;
>>> - kthread_park(ring->sched.thread);
>>> + drm_sched_stop(>sched, job ? >base : NULL,
>>> park_only);
>>> - if (job && job->base.sched != >sched)
>>> + if (park_only)
>>> continue;
>>> - drm_sched_hw_job_reset(>sched, job ? >base :
>>> NULL);
>>> -
>>> /* after all hw jobs are reset, hw fence is meaningless, so
>>> force_completion */
>>> amdgpu_fence_driver_force_completion(ring);
>>> }
>>> @@ -3445,6 +3444,7 @@ static void
>>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
>>> struct amdgpu_job *job)
>>> {
>>> int i;
>>> + bool unpark_only;
>>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>>> struct amdgpu_ring *ring = adev->rings[i];
>>> @@ -3456,10 +3456,13 @@ static void
>>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
>>> * or all rings (in the case @job is NULL)
>>> * after above amdgpu_reset accomplished
>>> */
>>> - if ((!job || job->base.sched == >sched) &&
>>> !adev->asic_reset_res)
>>> - drm_sched_job_recovery(>sched);
>>> + unpark_only = (job && job->base.sched != >sched) ||
>>> + adev->asic_reset_res;
>>> +
>>> + if (!unpark_only)
>>> + drm_sched_resubmit_jobs(>sched);
>>> - kthread_unpark(ring->sched.thread);
>>> + drm_sched_start(>sched, unpark_only);
>>> }
>>> if (!amdgpu_device_has_dc_support(adev)) {
>>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>>> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>>> index 49a6763..fab3b51 100644
>>> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>>> @@ -109,16 +109,16 @@ static void etnaviv_sched_timedout_job(struct
>>> drm_sched_job *sched_job)
>>> }
>>> /* block scheduler */
>>> - kthread_park(gpu->sched.thread);
>>> - drm_sched_hw_job_reset(>sched, sched_job);
>>> + drm_sched_stop(>sched, sched_job, false);
>>> /* get the GPU back into the init state */
>>> etnaviv_core_dump(gpu);
>>> etnaviv_gpu_recover_hang(gpu);
>>> + drm_sched_resubmit_jobs(>sched);
>>> +
>>> /* restart scheduler after GPU is usable again */
>>> - drm_sched_job_recovery(>sched);
>>> - kthread_unpark(gpu->sched.thread);
>>> + drm_sched_start(>sched);
>>> }
>>> static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
>>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>>> b/drivers/gpu/drm/scheduler/sched_main.c
>>> index dbb6906..cdf95e2 100644
>>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>>> @@ -60,8 +60,6 @@
>>> static void drm_sched_process_job(struct dma_fence *f, struct
>>> dma_fence_cb *cb);
>>> -static void drm_sched_expel_job_unlocked(struct drm_sched_job
>>> *s_job);
>>> -
>>> /**
>>> * drm_sched_rq_init - initialize a given run queue struct
>>> *
>>> @@ -342,13 +340,21 @@ static void drm_sched_job_timedout(struct
>>> work_struct *work)
>>> * @bad: bad scheduler job
>>> *
>>> */
>>> -void drm_sched_hw_job_reset(struct drm_gpu_scheduler *sched, struct
>>> drm_sched_job *bad)
>>> +void drm_sched_stop(struct
Re: [PATCH libdrm] libdrm: Fix drmNodeIsDRM() on DragonFly
On Tue, 11 Dec 2018 at 22:15, François Tigeot wrote: > > * There is no way to check if a device name is really a drm device > by looking it up in a virtual filesystem like on Linux > > * The major device number is also dynamically allocated from a pool, > comparing it to a constant makes no sense > > * In the absence of better ideas, just assume the device name really > points to a drm device and always return true > I guess one could use the sysfs path, although that may require a few extra lines to the linux emulation layer. What's the reason behind the dynamic allocation of the major? FWIW some userspace requires a fixed DRM_MAJOR - they will need patching to run :-( Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: VC4 DRM
Sergey Suloev writes: > Eric, Noralf, > > could either of you answer a question about Vc4 DRM, please ? > > I am trying to connect MIPI DSI display to VC4 but it isn't showing > anything. I have noticed > that the DSI host transfer() method vc4_dsi_host_transfer gets called > for the commands that > I am sending from my panel driver, but not for pixel data. > > My question: are pixel data normally transferred the same method within > vc4_dsi driver > or any "behind the scene" way ? The transfer function isn't used for pixel data in video mode. The vc4 panel has never been used for command mode panels, so if you have one of those it will probably be extra work. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm: Make drmNodeIsDRM() public.
Hi Christopher, On Tue, 20 Nov 2018 at 04:30, Christopher James Halse Rogers wrote: > > I have wanted this code in Mir, so it's plausibly useful elsewhere, > particularly if the DRM device major number is going to become > dynamic. > Can you elaborate/link to the code that uses the major/minor? Fiddling with those manually is rather error prone most often than not. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Update crtc scaler settings when update_pipe is set
Op 17-12-2018 om 15:19 schreef Hans de Goede:
> When the pipe_config's update_pipe flag is set we may need to update the
> panel fitting settings. On GEN9+ this means we need to update the crtc's
> scaler settings.
>
> This fixes the following WARN_ON, during i915 loading on an Asrock
> B150M Pro4S/D3 board with an i5-6500 CPU / graphics:
>
> [drm:pipe_config_err [i915]] *ERROR* mismatch in pch_pfit.enabled
> (expected no, found yes)
> pipe state doesn't match!
> WARNING: CPU: 3 PID: 305 at drivers/gpu/drm/i915/intel_display.c:12084
>
> With line 12084 being the I915_STATE_WARN call inside the
> "if (!intel_pipe_config_compare())" block in verify_crtc_state().
>
> On this board with 2 1920x1080 monitors connected over HDMI the GOP
> initializes both monitors at 1920x1080 and despite no scaling being
> necessary configures a scaler for one of them.
>
> When booting with fastboot=1 on the initial modeset needs_modeset will
> be false while update_pipe is true. Since we were not calling
> skl_update_scaler_crtc() in this case we would leave the scaler enabled
> causing this error.
>
> Signed-off-by: Hans de Goede
> ---
> drivers/gpu/drm/i915/intel_display.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 62df34d30b1f..df32626e0810 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10919,7 +10919,7 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *crtc,
> }
>
> if (INTEL_GEN(dev_priv) >= 9) {
> - if (mode_changed)
> + if (mode_changed || pipe_config->update_pipe)
> ret = skl_update_scaler_crtc(pipe_config);
>
> if (!ret)
Ah, the missing bit..
https://patchwork.freedesktop.org/series/54127/
Reviewed-by: Maarten Lankhorst
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drmHash: remove unused loop variable
On Wed, 7 Nov 2018 at 14:44, Eric Engestrom wrote: > > Reported-by: Jan Vesely > Signed-off-by: Eric Engestrom Reviewed-by: Emil Velikov -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] README: reflow the project description to improve readability
On Wed, 7 Nov 2018 at 18:02, Eric Engestrom wrote: > > Also, move the sentence about "who would use libdrm" into its own paragraph, > as it is something people discovering libdrm will want to know. > > Signed-off-by: Eric Engestrom Reviewed-by: Emil Velikov -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm: Add drmIsMaster()
On Mon, Dec 17, 2018 at 6:38 PM Emil Velikov wrote: > > Hi Christopher, > > On Tue, 20 Nov 2018 at 03:37, Christopher James Halse Rogers > wrote: > > > > We can't use drmSetMaster to query whether or not a drm fd is master > > because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd. > > > Can you please mention the exact use case here? You mentioned it over > IRC although it'll be nice to have it here for posterity. > > > Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is > > DRM_MASTER but not DRM_ROOT_ONLY as the probe by which we can detect > > whether or not the fd is master. > > > I'm wondering if we cannot extent DRM_IOCTL_GET_CLIENT or another IOCTL. > What do you think? May I interest you in writing an RFC for the kernel-side? > > IMHO checking with the kernel devs for a cleaner solution is a worthy > goal. If they're unhappy we can use this workaround. I think an invalid request through authmagic would be cleaner. That should give you EINVAL (you're master) or EACCESS (you're not master). It's also directly related to the master status, so less of a mindbinder. Note that we allocate magic numbers through the idr starting at 1, 0 is considered an invalid magic number and rejected. -Daniel > > Thanks > Emil > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/2] xf86atomic: #undef internal define
On Wed, 7 Nov 2018 at 18:01, Eric Engestrom wrote: > > Thanks to the #error just above, any file including this header can only > see one state for this macro: defined, with the value `1`. > Let's just #undef it once we're done using it in here so that other > files don't misconstrue any meaning to it. > > Signed-off-by: Eric Engestrom For the series: Reviewed-by: Emil Velikov -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/5] [libdrm] new syncobj extension
Hi Chunming Zhou, On Fri, 2 Nov 2018 at 08:27, Chunming Zhou wrote: > > Signed-off-by: Chunming Zhou > --- > include/drm/drm.h | 38 ++ Please read through include/drm/README about how include/drm/ should be updated. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 1/2] symbol-check: ignore platform symbols
On Wed, 24 Oct 2018 at 17:59, Eric Engestrom wrote: > > On Wednesday, 2018-10-24 17:53:51 +0100, Eric Engestrom wrote: > > Fixes the tests on ARM, but more importantly this makes it much easier > > to maintain. > > BTW I have a wip to replace all of those with a python script that will > be more thorough in its checks, but until that lands this is already > a good step. > (Just mentioning it so that someone else doesn't see this as an > opportunity to start the same project again.) > You already had a series (in POSIX shell) that tweaks those. I guess one can trivially rebase that and apply. AFAICT nothing* really relies on python so the change seems quite strange. -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm 2/2] gitignore: add _build
On Fri, 19 Oct 2018 at 18:20, Lucas De Marchi wrote: > > /_build* > /build* > These two sound perfectly reasonable IMHO. They will catch vast majority of use-cases. With that the series is: Acked-by: Emil Velikov -Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108272] [polaris10] opencl-mesa: Anything using OpenCL segfaults, XFX Radeon RX 580
https://bugs.freedesktop.org/show_bug.cgi?id=108272 --- Comment #12 from Jan Vesely --- Hi, sorry for the delay. somehow I missed the notifications. (In reply to jamespharvey20 from comment #11) > When I originally filed this, I assumed it was 1 bug since I tried 2 things > with OpenCL, and both failed with opencl-mesa but worked with opencl-amd. > > Jan Vesely was correct that there were two separate problems. > > I'm hoping Jan Vesely can give guidance on whether to leave this bug open > for any of the reasons below, or if I should close it and potentially open > up 1-2 new bugs. > > The original luxmark bug (segfault) is solved, but that exposes 2 new > opencl-mesa bugs when running luxmark. > > The original IndigoBenchmark bug (segfault) isn't solved, but as explained > below, I understand if we have to consider that unsolvable for now. > > I don't think this affects any of these bugs, but I'll mention a few weeks > ago, I switched back to my Asus Radeon R9 390. The same behaviors discussed > in this entire bug report occur. (i.e. 18.2.3 and before crash luxmark.) > If someone really wants me to do so, I can switch back to the RX 580 to test > 18.2.4, but I'm betting since it works properly with the R9 390 that the > problem is fixed. > > ORIGINAL LUXMARK BUG #1 > - > > Using mesa 18.2.4, the luxmark segfault is solved. As this was the first bug. I'd close this one and open new bugs for both indigo and incorrect rendering in luxmark. > > NEW - LUXMARK BUG #2 > > > Jan Vesely's comment on 2018-10-09 mentions: "bumping MAX_GLOBAL_BUFFERS to > 32 allows luxmark to run, albeit still with many incorrect pixels -- libclc > rounding conversions are incorrect." > > That's what I'm seeing out of 18.2.4. Using LuxBall HDR (Simple Benchmark): > > MESA 18.2.4: 40626 (Image validation OK (65739 different pixels, 10.27%) > > AMDGPU-PRO: 15739 (Image validation OK (5736 different pixels, 0.90%) > > There's no typos there. opencl-mesa scores almost unbelievably higher than > opencl-amd, but the different pixels percentage increases by a factor of > 11.4. > > As Jan's other comment on 2018-10-09 mentions, the image looks garbled and > the results are incorrect. > > Not sure if this bug should be left open for this issue, or if I should > create a new bug. (Or, if there is a bug already open for it.) Or, if mesa > will say it's purely libclc's problem, and to go to them about it. I'd say this is probably a purely libclc problem, but feel free to open the bug against clover on freedesktop. 10% is rather good I usually saw ~30% wrong pixels on my machines. > > NEW - LUXMARK BUG #3 > > > Although luxmark can now benchmark, when doing so, all input becomes > unusably awful. It reminds me of when Windows has too many things open, > suddenly decided it can't cope, and you're waiting to see if it's going to > recover or crash. Keystrokes take too long to be printed, and the mouse > becomes slow and jumpy. Top shows cpu and memory usage are fine, which was > my first thought. BTW, running xf86-video-amdgpu 18.1.0, and when I > upgraded mesa, it was both mesa and opencl-mesa. > > In comparison, if I use opencl-amd, input is not affected. I wouldn't even > know the GPU is being slammed. > > Using the program radeontop, I can see when using mesa, "Graphics pipe", > "Texture Addresser", and "Shader Interpolator" are between 95-100%, usually > 98-100%. > > When using opencl-amd, radeontop shows the same. (Granted, Vertex Grouper + > Tesselator / Shader Export/Scan Converter/Depth Block/Color Block bounce > between 5-20% vs on opencl-mesa, they bounce between 1-5%.) This sounds like GPU priority/scheduling problem. I haven't looked into whether it can be solved via opening lower priority pipe for compute, or we need to enable advanced features like CWSR. Please open a separate bug. Hogging a large portion of the GPU might explain some of that high score. > > INDIGO BUG > -- > > I edited 18.2.4's si_get.c to be very short: > > snprintf(sscreen->renderer_string, sizeof(sscreen->renderer_string), >"%s", >chip_name); > > And compiled/installed it, but it didn't affect the crash. > > IndigoBenchmark said they're statically linking with LLVM 3.4, which is > quite old. But, it runs fine with opencl-amd, and only crashes on > opencl-mesa. I just posted a followup "where do we go from here"-ish > comment there which has to be moderator approved so isn't showing yet. > https://www.indigorenderer.com/forum/viewtopic.php?f=37=14986 > > Part of me thinks it needs to be given up on, being a closed-source > precompiled binary statically linked against LLVM 3.4. > > Part of me thinks since it only crashes with opencl-mesa, and runs perfectly > fine with opencl-amd, there's probably (but not definitely) a bug in > opencl-mesa. > > But, I understand
[Bug 109068] Raven Ridge: backlight is off after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=109068 --- Comment #3 from Samantha McVey --- Created attachment 142838 --> https://bugs.freedesktop.org/attachment.cgi?id=142838=edit 4.20-rc5 dmesg In addition, this is what happens to the levels of "brightness" and "actual_brightness" before and after sleep on amd-staging-drm-next: Before sleep: actual_brightness: 12141 brightness: 102 After sleep: actual_brightness: 0 brightness: 102 On 4.20-rc5 or 4.19 actual_brightness is not at 0 after resume from suspend. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] xf86drm: Add drmIsMaster()
Hi Christopher, On Tue, 20 Nov 2018 at 03:37, Christopher James Halse Rogers wrote: > > We can't use drmSetMaster to query whether or not a drm fd is master > because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd. > Can you please mention the exact use case here? You mentioned it over IRC although it'll be nice to have it here for posterity. > Pick DRM_IOCTL_MODE_ATTACHMODE as a long-deprecated ioctl that is > DRM_MASTER but not DRM_ROOT_ONLY as the probe by which we can detect > whether or not the fd is master. > I'm wondering if we cannot extent DRM_IOCTL_GET_CLIENT or another IOCTL. What do you think? May I interest you in writing an RFC for the kernel-side? IMHO checking with the kernel devs for a cleaner solution is a worthy goal. If they're unhappy we can use this workaround. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109068] Raven Ridge: backlight is off after suspend
https://bugs.freedesktop.org/show_bug.cgi?id=109068 --- Comment #2 from Samantha McVey --- Created attachment 142837 --> https://bugs.freedesktop.org/attachment.cgi?id=142837=edit amd-staging-drm-next dmesg -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm/sched: Refactor ring mirror list handling.
On 12/17/2018 10:27 AM, Christian König wrote:
> Am 10.12.18 um 22:43 schrieb Andrey Grodzovsky:
>> 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 HW fences
>> to complete before rerunning the jobs.
>>
>> v2: Fix resubmission of guilty job into HW after refactoring.
>>
>> Suggested-by: Christian Koenig
>> Signed-off-by: Andrey Grodzovsky
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++--
>> drivers/gpu/drm/etnaviv/etnaviv_sched.c | 8 +--
>> drivers/gpu/drm/scheduler/sched_main.c | 110
>> ++---
>> drivers/gpu/drm/v3d/v3d_sched.c | 11 +--
>> include/drm/gpu_scheduler.h | 10 ++-
>> 5 files changed, 95 insertions(+), 61 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> index ef36cc5..42111d5 100644
>> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
>> @@ -3292,17 +3292,16 @@ static int
>> amdgpu_device_pre_asic_reset(struct amdgpu_device *adev,
>> /* block all schedulers and reset given job's ring */
>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>> struct amdgpu_ring *ring = adev->rings[i];
>> + bool park_only = job && job->base.sched != >sched;
>> if (!ring || !ring->sched.thread)
>> continue;
>> - kthread_park(ring->sched.thread);
>> + drm_sched_stop(>sched, job ? >base : NULL,
>> park_only);
>> - if (job && job->base.sched != >sched)
>> + if (park_only)
>> continue;
>> - drm_sched_hw_job_reset(>sched, job ? >base :
>> NULL);
>> -
>> /* after all hw jobs are reset, hw fence is meaningless, so
>> force_completion */
>> amdgpu_fence_driver_force_completion(ring);
>> }
>> @@ -3445,6 +3444,7 @@ static void
>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
>> struct amdgpu_job *job)
>> {
>> int i;
>> + bool unpark_only;
>> for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
>> struct amdgpu_ring *ring = adev->rings[i];
>> @@ -3456,10 +3456,13 @@ static void
>> amdgpu_device_post_asic_reset(struct amdgpu_device *adev,
>> * or all rings (in the case @job is NULL)
>> * after above amdgpu_reset accomplished
>> */
>> - if ((!job || job->base.sched == >sched) &&
>> !adev->asic_reset_res)
>> - drm_sched_job_recovery(>sched);
>> + unpark_only = (job && job->base.sched != >sched) ||
>> + adev->asic_reset_res;
>> +
>> + if (!unpark_only)
>> + drm_sched_resubmit_jobs(>sched);
>> - kthread_unpark(ring->sched.thread);
>> + drm_sched_start(>sched, unpark_only);
>> }
>> if (!amdgpu_device_has_dc_support(adev)) {
>> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> index 49a6763..fab3b51 100644
>> --- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> +++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
>> @@ -109,16 +109,16 @@ static void etnaviv_sched_timedout_job(struct
>> drm_sched_job *sched_job)
>> }
>> /* block scheduler */
>> - kthread_park(gpu->sched.thread);
>> - drm_sched_hw_job_reset(>sched, sched_job);
>> + drm_sched_stop(>sched, sched_job, false);
>> /* get the GPU back into the init state */
>> etnaviv_core_dump(gpu);
>> etnaviv_gpu_recover_hang(gpu);
>> + drm_sched_resubmit_jobs(>sched);
>> +
>> /* restart scheduler after GPU is usable again */
>> - drm_sched_job_recovery(>sched);
>> - kthread_unpark(gpu->sched.thread);
>> + drm_sched_start(>sched);
>> }
>> static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
>> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
>> b/drivers/gpu/drm/scheduler/sched_main.c
>> index dbb6906..cdf95e2 100644
>> --- a/drivers/gpu/drm/scheduler/sched_main.c
>> +++ b/drivers/gpu/drm/scheduler/sched_main.c
>> @@ -60,8 +60,6 @@
>> static void drm_sched_process_job(struct dma_fence *f, struct
>> dma_fence_cb *cb);
>> -static void drm_sched_expel_job_unlocked(struct drm_sched_job
>> *s_job);
>> -
>> /**
>> * drm_sched_rq_init - initialize a given run queue struct
>> *
>> @@ -342,13 +340,21 @@ static void drm_sched_job_timedout(struct
>> work_struct *work)
>> * @bad: bad scheduler job
>> *
>> */
>> -void drm_sched_hw_job_reset(struct drm_gpu_scheduler *sched, struct
>> drm_sched_job *bad)
>> +void drm_sched_stop(struct drm_gpu_scheduler *sched, struct
>> drm_sched_job *bad,
>> + bool park_only)
>> {
>> struct drm_sched_job *s_job;
>> struct drm_sched_entity *entity, *tmp;
>> unsigned long
[Bug 103949] REG_WAIT timeout - dce110_stream_encoder_dp_blank line:930 - 4.15-rc1
https://bugs.freedesktop.org/show_bug.cgi?id=103949 --- Comment #4 from Patrik Jakobsson --- Hi, I'm getting the same error on upstream 4.18, 4.19 and drm-fixes-4.20 whenever I hotplug a DP monitor. Can you point me to the patch that is supposed to fix this? I took a quick look at the mailing list and found "[PATCH] drm/amdgpu:Improves robustness of SOC15_WAIT_ON_RREG". Unfortunately this doesn't work for me. I also tried something similar as that patch but in generic_reg_wait(). Still no luck. Thanks Patrik -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 Alex Deucher changed: What|Removed |Added Attachment #142834|0 |1 is obsolete|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 Alex Deucher changed: What|Removed |Added Attachment #142835|0 |1 is patch|| Attachment #142835|application/mbox|text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] etnaviv-next for 4.21
On Mon, Dec 17, 2018 at 04:37:21PM +0100, Lucas Stach wrote: > Hi Christian, > > Am Montag, den 17.12.2018, 11:09 +0100 schrieb Christian Gmeiner: > > Am Fr., 14. Dez. 2018 um 11:44 Uhr schrieb Lucas Stach > tronix.de>: > > > > > > Hi Dave, > > > > > > nothing major this time, mostly some cleanups that were found on > > > the > > > way of reworking the code in preparation for new feature additions. > > > > > > Regards, > > > Lucas > > > > > > The following changes since commit > > > 6fce3a406108ee6c8a61e2a33e52e9198a626ea0: > > > > > > drm/etnaviv: fix bogus fence complete check in timeout handler > > > (2018-11-05 18:14:48 +0100) > > > > > > are available in the Git repository at: > > > > > > https://git.pengutronix.de/git/lst/linux etnaviv/next > > > > > > for you to fetch changes up to > > > dea492e0cfcbe8ca592406fefc7ceeaf53f63380: > > > > > > drm/etnaviv: remove lastctx member from gpu struct (2018-12-11 > > > 12:35:07 +0100) > > > > > > > > > Lucas Stach (5): > > > > .. > > > drm/etnaviv: remove unnecessary local irq disable > > > drm/etnaviv: replace header include with forward declaration > > > drm/etnaviv: remove lastctx member from gpu struct > > > > > > > I did not found these three patches via google or in my in-box. Where > > they ever send to any ml? > > I'm pretty sure I did hit send on those, but also can't find a trace of > them anywhere, so seems they have been eaten by whatever likes little > patches before hitting the MLs. Unfortunately silence in response to > etnaviv kernel patches isn't something totally unusual, so I didn't > realize this in time. :-/ > > I've just re-sent those patches. Since they all have r-b tags now I'll assume you're going to send me a new pull with those added? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109066] Launching Libretro Nestopia Core in Retroarch Triggers AMDGPU Kernel Bug
https://bugs.freedesktop.org/show_bug.cgi?id=109066 --- Comment #2 from Benjamin Hodgetts --- Created attachment 142836 --> https://bugs.freedesktop.org/attachment.cgi?id=142836=edit Pulseaudio HDMI Sink Errors I'll try amd-staging-drm-next but I've been getting almost non-stop errors on that version of the kernel (anything using audio errors out often) so I've reverted back to the stock kernel. It happens on the stock kernel too, but less often. I've attached an example of those errors in case it's useful. Regarding your other question, I'm using Xorg 1.20.3 with xf86-video-amdgpu 18.1. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #32 from Jerry Zuo --- Created attachment 142835 --> https://bugs.freedesktop.org/attachment.cgi?id=142835=edit Patch for dp_blank timeout -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/etnaviv: remove lastctx member from gpu struct
Am Mo., 17. Dez. 2018 um 16:36 Uhr schrieb Lucas Stach :
>
> It only written and we don't infer any useful information from
> it anymore. Remove it.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 2 --
> drivers/gpu/drm/etnaviv/etnaviv_drv.c| 8 +---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 2 --
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 1 -
> 4 files changed, 1 insertion(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> index 7fea74861a87..160ce3c060a5 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
> @@ -439,6 +439,4 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
> exec_state,
>
> if (drm_debug & DRM_UT_DRIVER)
> etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
> -
> - gpu->lastctx = cmdbuf->ctx;
> }
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index 1bb1d09e5fb0..96efc84396bf 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -72,14 +72,8 @@ static void etnaviv_postclose(struct drm_device *dev,
> struct drm_file *file)
> for (i = 0; i < ETNA_MAX_PIPES; i++) {
> struct etnaviv_gpu *gpu = priv->gpu[i];
>
> - if (gpu) {
> - mutex_lock(>lock);
> - if (gpu->lastctx == ctx)
> - gpu->lastctx = NULL;
> - mutex_unlock(>lock);
> -
> + if (gpu)
> drm_sched_entity_destroy(>sched_entity[i]);
> - }
> }
>
> kfree(ctx);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index aefb17e39ad0..6904535475de 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -997,7 +997,6 @@ void etnaviv_gpu_recover_hang(struct etnaviv_gpu *gpu)
> spin_unlock(>event_spinlock);
>
> etnaviv_gpu_hw_init(gpu);
> - gpu->lastctx = NULL;
> gpu->exec_state = -1;
>
> mutex_unlock(>lock);
> @@ -1546,7 +1545,6 @@ static int etnaviv_gpu_hw_resume(struct etnaviv_gpu
> *gpu)
> etnaviv_gpu_update_clock(gpu);
> etnaviv_gpu_hw_init(gpu);
>
> - gpu->lastctx = NULL;
> gpu->exec_state = -1;
>
> mutex_unlock(>lock);
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index 56b6a8ee7ec0..9bcf151f706b 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -97,7 +97,6 @@ struct etnaviv_gpu {
> struct mutex lock;
> struct etnaviv_chip_identity identity;
> enum etnaviv_sec_mode sec_mode;
> - struct etnaviv_file_private *lastctx;
> struct workqueue_struct *wq;
> struct drm_gpu_scheduler sched;
>
> --
> 2.19.1
>
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm/etnaviv: replace header include with forward declaration
Am Mo., 17. Dez. 2018 um 16:36 Uhr schrieb Lucas Stach :
>
> The etnaviv_gpu header only needs to know about the pointer types, so
> replace by a forward declaration and only include the headers where needed.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
> drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 5 ++---
> 2 files changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 293e248e1b29..aefb17e39ad0 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -3,10 +3,12 @@
> * Copyright (C) 2015-2018 Etnaviv Project
> */
>
> +#include
> #include
> #include
> #include
> #include
> +#include
> #include
>
> #include "etnaviv_cmdbuf.h"
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> index 74758f21e5d3..56b6a8ee7ec0 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
> @@ -6,9 +6,6 @@
> #ifndef __ETNAVIV_GPU_H__
> #define __ETNAVIV_GPU_H__
>
> -#include
> -#include
> -
> #include "etnaviv_cmdbuf.h"
> #include "etnaviv_drv.h"
>
> @@ -88,6 +85,8 @@ struct etnaviv_event {
>
> struct etnaviv_cmdbuf_suballoc;
> struct etnaviv_cmdbuf;
> +struct regulator;
> +struct clk;
>
> #define ETNA_NR_EVENTS 30
>
> --
> 2.19.1
>
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm/etnaviv: remove unnecessary local irq disable
Am Mo., 17. Dez. 2018 um 16:36 Uhr schrieb Lucas Stach :
>
> The only event function that is called from IRQ context is event_free,
> which is already using atomic bitmap operations, so we can avoid taking
> the event spinlock in this function completely. As other the other
> functions still using the event spinlock are all called from normal
> process context, we can avoid disabling IRQs while holding the spinlock.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 18 +-
> 1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> index 8fbe77cae810..293e248e1b29 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
> @@ -976,7 +976,6 @@ int etnaviv_gpu_debugfs(struct etnaviv_gpu *gpu, struct
> seq_file *m)
>
> void etnaviv_gpu_recover_hang(struct etnaviv_gpu *gpu)
> {
> - unsigned long flags;
> unsigned int i = 0;
>
> dev_err(gpu->dev, "recover hung GPU!\n");
> @@ -989,11 +988,11 @@ void etnaviv_gpu_recover_hang(struct etnaviv_gpu *gpu)
> etnaviv_hw_reset(gpu);
>
> /* complete all events, the GPU won't do it after the reset */
> - spin_lock_irqsave(>event_spinlock, flags);
> + spin_lock(>event_spinlock);
> for_each_set_bit_from(i, gpu->event_bitmap, ETNA_NR_EVENTS)
> complete(>event_free);
> bitmap_zero(gpu->event_bitmap, ETNA_NR_EVENTS);
> - spin_unlock_irqrestore(>event_spinlock, flags);
> + spin_unlock(>event_spinlock);
>
> etnaviv_gpu_hw_init(gpu);
> gpu->lastctx = NULL;
> @@ -1083,7 +1082,7 @@ static inline bool fence_after(u32 a, u32 b)
> static int event_alloc(struct etnaviv_gpu *gpu, unsigned nr_events,
> unsigned int *events)
> {
> - unsigned long flags, timeout = msecs_to_jiffies(10 * 1);
> + unsigned long timeout = msecs_to_jiffies(10 * 1);
> unsigned i, acquired = 0;
>
> for (i = 0; i < nr_events; i++) {
> @@ -1100,7 +1099,7 @@ static int event_alloc(struct etnaviv_gpu *gpu,
> unsigned nr_events,
> timeout = ret;
> }
>
> - spin_lock_irqsave(>event_spinlock, flags);
> + spin_lock(>event_spinlock);
>
> for (i = 0; i < nr_events; i++) {
> int event = find_first_zero_bit(gpu->event_bitmap,
> ETNA_NR_EVENTS);
> @@ -1110,7 +1109,7 @@ static int event_alloc(struct etnaviv_gpu *gpu,
> unsigned nr_events,
> set_bit(event, gpu->event_bitmap);
> }
>
> - spin_unlock_irqrestore(>event_spinlock, flags);
> + spin_unlock(>event_spinlock);
>
> return 0;
>
> @@ -1123,18 +1122,11 @@ static int event_alloc(struct etnaviv_gpu *gpu,
> unsigned nr_events,
>
> static void event_free(struct etnaviv_gpu *gpu, unsigned int event)
> {
> - unsigned long flags;
> -
> - spin_lock_irqsave(>event_spinlock, flags);
> -
> if (!test_bit(event, gpu->event_bitmap)) {
> dev_warn(gpu->dev, "event %u is already marked as free",
> event);
> - spin_unlock_irqrestore(>event_spinlock, flags);
> } else {
> clear_bit(event, gpu->event_bitmap);
> - spin_unlock_irqrestore(>event_spinlock, flags);
> -
> complete(>event_free);
> }
> }
> --
> 2.19.1
>
--
greets
--
Christian Gmeiner, MSc
https://christian-gmeiner.info
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #31 from Alex Deucher --- (In reply to Jerry Zuo from comment #30) > Please try the patch, and see if you can see reg_wait timeout > dce110_stream_encoder_dp_blank() Can you attach a non-zipped version? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 03/10] phy: Add MIPI D-PHY configuration options
Hi Sakari, Thanks for your feedback. On Thu, Dec 13, 2018 at 10:49:28PM +0200, sakari.ai...@iki.fi wrote: > > + /** > > +* @lanes: > > +* > > +* Number of active data lanes used for the transmissions. > > Could you add that these are the first "lanes" number of lanes from what > are available? I'm not quite sure I understood this part though, what did you mean? Thanks! Maxime -- Maxime Ripard, Bootlin Embedded Linux and Kernel engineering https://bootlin.com signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #30 from Jerry Zuo --- Please try the patch, and see if you can see reg_wait timeout dce110_stream_encoder_dp_blank() -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107978] [amdgpu] Switching to tty fails with DisplayPort 1.2 monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 --- Comment #29 from Jerry Zuo --- Created attachment 142834 --> https://bugs.freedesktop.org/attachment.cgi?id=142834=edit parch for reg_wait timeout for dce -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] etnaviv-next for 4.21
Hi Christian, Am Montag, den 17.12.2018, 11:09 +0100 schrieb Christian Gmeiner: > Am Fr., 14. Dez. 2018 um 11:44 Uhr schrieb Lucas Stach tronix.de>: > > > > Hi Dave, > > > > nothing major this time, mostly some cleanups that were found on > > the > > way of reworking the code in preparation for new feature additions. > > > > Regards, > > Lucas > > > > The following changes since commit > > 6fce3a406108ee6c8a61e2a33e52e9198a626ea0: > > > > drm/etnaviv: fix bogus fence complete check in timeout handler > > (2018-11-05 18:14:48 +0100) > > > > are available in the Git repository at: > > > > https://git.pengutronix.de/git/lst/linux etnaviv/next > > > > for you to fetch changes up to > > dea492e0cfcbe8ca592406fefc7ceeaf53f63380: > > > > drm/etnaviv: remove lastctx member from gpu struct (2018-12-11 > > 12:35:07 +0100) > > > > > > Lucas Stach (5): > > .. > > drm/etnaviv: remove unnecessary local irq disable > > drm/etnaviv: replace header include with forward declaration > > drm/etnaviv: remove lastctx member from gpu struct > > > > I did not found these three patches via google or in my in-box. Where > they ever send to any ml? I'm pretty sure I did hit send on those, but also can't find a trace of them anywhere, so seems they have been eaten by whatever likes little patches before hitting the MLs. Unfortunately silence in response to etnaviv kernel patches isn't something totally unusual, so I didn't realize this in time. :-/ I've just re-sent those patches. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] drm/etnaviv: remove lastctx member from gpu struct
It only written and we don't infer any useful information from
it anymore. Remove it.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 2 --
drivers/gpu/drm/etnaviv/etnaviv_drv.c| 8 +---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 2 --
drivers/gpu/drm/etnaviv/etnaviv_gpu.h| 1 -
4 files changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
index 7fea74861a87..160ce3c060a5 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_buffer.c
@@ -439,6 +439,4 @@ void etnaviv_buffer_queue(struct etnaviv_gpu *gpu, u32
exec_state,
if (drm_debug & DRM_UT_DRIVER)
etnaviv_buffer_dump(gpu, buffer, 0, 0x50);
-
- gpu->lastctx = cmdbuf->ctx;
}
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 1bb1d09e5fb0..96efc84396bf 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -72,14 +72,8 @@ static void etnaviv_postclose(struct drm_device *dev, struct
drm_file *file)
for (i = 0; i < ETNA_MAX_PIPES; i++) {
struct etnaviv_gpu *gpu = priv->gpu[i];
- if (gpu) {
- mutex_lock(>lock);
- if (gpu->lastctx == ctx)
- gpu->lastctx = NULL;
- mutex_unlock(>lock);
-
+ if (gpu)
drm_sched_entity_destroy(>sched_entity[i]);
- }
}
kfree(ctx);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index aefb17e39ad0..6904535475de 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -997,7 +997,6 @@ void etnaviv_gpu_recover_hang(struct etnaviv_gpu *gpu)
spin_unlock(>event_spinlock);
etnaviv_gpu_hw_init(gpu);
- gpu->lastctx = NULL;
gpu->exec_state = -1;
mutex_unlock(>lock);
@@ -1546,7 +1545,6 @@ static int etnaviv_gpu_hw_resume(struct etnaviv_gpu *gpu)
etnaviv_gpu_update_clock(gpu);
etnaviv_gpu_hw_init(gpu);
- gpu->lastctx = NULL;
gpu->exec_state = -1;
mutex_unlock(>lock);
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 56b6a8ee7ec0..9bcf151f706b 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -97,7 +97,6 @@ struct etnaviv_gpu {
struct mutex lock;
struct etnaviv_chip_identity identity;
enum etnaviv_sec_mode sec_mode;
- struct etnaviv_file_private *lastctx;
struct workqueue_struct *wq;
struct drm_gpu_scheduler sched;
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] drm/etnaviv: replace header include with forward declaration
The etnaviv_gpu header only needs to know about the pointer types, so
replace by a forward declaration and only include the headers where needed.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 5 ++---
2 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 293e248e1b29..aefb17e39ad0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -3,10 +3,12 @@
* Copyright (C) 2015-2018 Etnaviv Project
*/
+#include
#include
#include
#include
#include
+#include
#include
#include "etnaviv_cmdbuf.h"
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
index 74758f21e5d3..56b6a8ee7ec0 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.h
@@ -6,9 +6,6 @@
#ifndef __ETNAVIV_GPU_H__
#define __ETNAVIV_GPU_H__
-#include
-#include
-
#include "etnaviv_cmdbuf.h"
#include "etnaviv_drv.h"
@@ -88,6 +85,8 @@ struct etnaviv_event {
struct etnaviv_cmdbuf_suballoc;
struct etnaviv_cmdbuf;
+struct regulator;
+struct clk;
#define ETNA_NR_EVENTS 30
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/etnaviv: remove unnecessary local irq disable
The only event function that is called from IRQ context is event_free,
which is already using atomic bitmap operations, so we can avoid taking
the event spinlock in this function completely. As other the other
functions still using the event spinlock are all called from normal
process context, we can avoid disabling IRQs while holding the spinlock.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 18 +-
1 file changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
index 8fbe77cae810..293e248e1b29 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_gpu.c
@@ -976,7 +976,6 @@ int etnaviv_gpu_debugfs(struct etnaviv_gpu *gpu, struct
seq_file *m)
void etnaviv_gpu_recover_hang(struct etnaviv_gpu *gpu)
{
- unsigned long flags;
unsigned int i = 0;
dev_err(gpu->dev, "recover hung GPU!\n");
@@ -989,11 +988,11 @@ void etnaviv_gpu_recover_hang(struct etnaviv_gpu *gpu)
etnaviv_hw_reset(gpu);
/* complete all events, the GPU won't do it after the reset */
- spin_lock_irqsave(>event_spinlock, flags);
+ spin_lock(>event_spinlock);
for_each_set_bit_from(i, gpu->event_bitmap, ETNA_NR_EVENTS)
complete(>event_free);
bitmap_zero(gpu->event_bitmap, ETNA_NR_EVENTS);
- spin_unlock_irqrestore(>event_spinlock, flags);
+ spin_unlock(>event_spinlock);
etnaviv_gpu_hw_init(gpu);
gpu->lastctx = NULL;
@@ -1083,7 +1082,7 @@ static inline bool fence_after(u32 a, u32 b)
static int event_alloc(struct etnaviv_gpu *gpu, unsigned nr_events,
unsigned int *events)
{
- unsigned long flags, timeout = msecs_to_jiffies(10 * 1);
+ unsigned long timeout = msecs_to_jiffies(10 * 1);
unsigned i, acquired = 0;
for (i = 0; i < nr_events; i++) {
@@ -1100,7 +1099,7 @@ static int event_alloc(struct etnaviv_gpu *gpu, unsigned
nr_events,
timeout = ret;
}
- spin_lock_irqsave(>event_spinlock, flags);
+ spin_lock(>event_spinlock);
for (i = 0; i < nr_events; i++) {
int event = find_first_zero_bit(gpu->event_bitmap,
ETNA_NR_EVENTS);
@@ -1110,7 +1109,7 @@ static int event_alloc(struct etnaviv_gpu *gpu, unsigned
nr_events,
set_bit(event, gpu->event_bitmap);
}
- spin_unlock_irqrestore(>event_spinlock, flags);
+ spin_unlock(>event_spinlock);
return 0;
@@ -1123,18 +1122,11 @@ static int event_alloc(struct etnaviv_gpu *gpu,
unsigned nr_events,
static void event_free(struct etnaviv_gpu *gpu, unsigned int event)
{
- unsigned long flags;
-
- spin_lock_irqsave(>event_spinlock, flags);
-
if (!test_bit(event, gpu->event_bitmap)) {
dev_warn(gpu->dev, "event %u is already marked as free",
event);
- spin_unlock_irqrestore(>event_spinlock, flags);
} else {
clear_bit(event, gpu->event_bitmap);
- spin_unlock_irqrestore(>event_spinlock, flags);
-
complete(>event_free);
}
}
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm/sched: Refactor ring mirror list handling.
Am 10.12.18 um 22:43 schrieb Andrey Grodzovsky:
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 HW fences
to complete before rerunning the jobs.
v2: Fix resubmission of guilty job into HW after refactoring.
Suggested-by: Christian Koenig
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17 +++--
drivers/gpu/drm/etnaviv/etnaviv_sched.c| 8 +--
drivers/gpu/drm/scheduler/sched_main.c | 110 ++---
drivers/gpu/drm/v3d/v3d_sched.c| 11 +--
include/drm/gpu_scheduler.h| 10 ++-
5 files changed, 95 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index ef36cc5..42111d5 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3292,17 +3292,16 @@ static int amdgpu_device_pre_asic_reset(struct
amdgpu_device *adev,
/* block all schedulers and reset given job's ring */
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
+ bool park_only = job && job->base.sched != >sched;
if (!ring || !ring->sched.thread)
continue;
- kthread_park(ring->sched.thread);
+ drm_sched_stop(>sched, job ? >base : NULL,
park_only);
- if (job && job->base.sched != >sched)
+ if (park_only)
continue;
- drm_sched_hw_job_reset(>sched, job ? >base : NULL);
-
/* after all hw jobs are reset, hw fence is meaningless, so
force_completion */
amdgpu_fence_driver_force_completion(ring);
}
@@ -3445,6 +3444,7 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev,
struct amdgpu_job *job)
{
int i;
+ bool unpark_only;
for (i = 0; i < AMDGPU_MAX_RINGS; ++i) {
struct amdgpu_ring *ring = adev->rings[i];
@@ -3456,10 +3456,13 @@ static void amdgpu_device_post_asic_reset(struct
amdgpu_device *adev,
* or all rings (in the case @job is NULL)
* after above amdgpu_reset accomplished
*/
- if ((!job || job->base.sched == >sched) &&
!adev->asic_reset_res)
- drm_sched_job_recovery(>sched);
+ unpark_only = (job && job->base.sched != >sched) ||
+ adev->asic_reset_res;
+
+ if (!unpark_only)
+ drm_sched_resubmit_jobs(>sched);
- kthread_unpark(ring->sched.thread);
+ drm_sched_start(>sched, unpark_only);
}
if (!amdgpu_device_has_dc_support(adev)) {
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
index 49a6763..fab3b51 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_sched.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_sched.c
@@ -109,16 +109,16 @@ static void etnaviv_sched_timedout_job(struct
drm_sched_job *sched_job)
}
/* block scheduler */
- kthread_park(gpu->sched.thread);
- drm_sched_hw_job_reset(>sched, sched_job);
+ drm_sched_stop(>sched, sched_job, false);
/* get the GPU back into the init state */
etnaviv_core_dump(gpu);
etnaviv_gpu_recover_hang(gpu);
+ drm_sched_resubmit_jobs(>sched);
+
/* restart scheduler after GPU is usable again */
- drm_sched_job_recovery(>sched);
- kthread_unpark(gpu->sched.thread);
+ drm_sched_start(>sched);
}
static void etnaviv_sched_free_job(struct drm_sched_job *sched_job)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index dbb6906..cdf95e2 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -60,8 +60,6 @@
static void drm_sched_process_job(struct dma_fence *f, struct dma_fence_cb *cb);
-static void drm_sched_expel_job_unlocked(struct drm_sched_job *s_job);
-
/**
* drm_sched_rq_init - initialize a given run queue struct
*
@@ -342,13 +340,21 @@ static void drm_sched_job_timedout(struct work_struct
*work)
* @bad: bad scheduler job
*
*/
-void drm_sched_hw_job_reset(struct drm_gpu_scheduler *sched, struct
drm_sched_job *bad)
+void drm_sched_stop(struct drm_gpu_scheduler *sched, struct drm_sched_job *bad,
+ bool park_only)
{
struct drm_sched_job *s_job;
struct drm_sched_entity *entity, *tmp;
unsigned long flags;
+ struct list_head wait_list;
int i;
+ kthread_park(sched->thread);
+ if (park_only)
+ return;
Removing the callback needs to be done for all engines, not just the one
where
[Bug 109049] [CI][BAT] igt@amdgpu/amd_prime@amd-to-i915 - fail - Failed assertion: r == 0, Last errno: 28, No space left on device
https://bugs.freedesktop.org/show_bug.cgi?id=109049 Chris Wilson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Chris Wilson --- Stopped being so stringent about allocating so many contexts, and just focus on testing fence import: commit 270da20849db4d170db09673c6b67712c90ec9fe (HEAD, upstream/master) Author: Chris Wilson Date: Thu Dec 13 11:54:36 2018 + igt/amdgpu_amd_prime: Bail if we fail to create more contexts amdgpu has started to report out of space after creating a few contexts. This is not the scope of this test as here we are just verifying that fences created in amd can be imported and used for synchronisation by i915 and for that we just need at least one context created! References: https://bugs.freedesktop.org/show_bug.cgi?id=109049 Signed-off-by: Chris Wilson Reviewed-by: Antonio Argenziano Acked-by: Alex Deucher -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Xen-devel] [PATCH v2 2/3] drm/xen-front: Use Xen common shared buffer implementation
On 12/17/18 4:52 PM, Boris Ostrovsky wrote: On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote: Hello, Juergen, Boris! As this DRM part of the series is the only one which needs ack/nack (and it might take quite some time to complete) could we please merge the patches 1 and 3 now that already have ack/r-b? TBH I am not sure it makes sense to do this without the second patch. Refactoring (and IIUIC this series is purely refactoring --- is it not?) is done to reduce amount of code, and with only first and third patch we end up with quite a significant increase in the number of LoC. (I am going purely by diffstat) Of course, the other reason for refactoring is to eliminate code duplication, but without second patch that will not happen. Agree, but this is the basis for the new pv camera frontend I am working on now [1], so even if we do not remove the code from DRM then we at least do not add it to the camera driver -boris Thank you, Oleksandr [1] https://github.com/andr2000/linux/blob/camera_front_v1/drivers/media/xen/Kconfig#L6 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 0/1] drm/i915: Enable fastset by default, except on initial modeset
Hi, On 17-12-18 15:38, Ville Syrjälä wrote: On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote: Hi All, As discussed a while ago, I would like to see us enable fastboot by default, starting with Skylake / GEN9 and newer hardware, so that we can avoid an unnecessary modeset at boot and move to a truely flickerfree boot. During our previous discussion about this Maarten mentioned that a first step would be to get this patch from him upstream. So I'm hereby resubmitting it, with a small fix. Hopefully the CI will like it better this time (if not we will need to investigate) and once this passes CI I hope this can be reviewed quickly and we can get this upstream. I will also be sending out a follow-up patch which actually makes fastboot the default on GEN9 and newer, I will mark that as RFC for now since based on our previous discussion this patch should be landed first. The infoframe precompute/check stuff didn't land yet. I think we want those in before we enable this thing. Hmm, what is the status of those changes? Unless those are almost ready to go I'm not convinced that delaying this patch for those is a good idea, I have the feeling there will always be one more thing to wait for if we go that route. Do you have a link to the latest version in patchwork? Anything I can do to help these move along ? Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201273] Fatal error during GPU init amdgpu RX560
https://bugzilla.kernel.org/show_bug.cgi?id=201273 --- Comment #25 from quirin.blae...@freenet.de --- Bug is still alive. amd-staging-drm-next 75061f375e7f627acbc3aa5466bc1ee552f3f22c plymouth low res -> clear -> crash (4da295299bda146326b44f22d8eeaa797d6acb38 too) -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [maintainer-tools PATCH RFC 3/3] dim: fix rr_cache_dir discovery
On Mon, Dec 17, 2018 at 10:54:48AM +0100, Andrzej Hajda wrote:
> Hi Daniel,
>
> Thanks for reviewing other two patches.
>
>
> On 14.12.2018 17:29, Daniel Vetter wrote:
> > On Fri, Dec 14, 2018 at 02:38:52PM +0100, Andrzej Hajda wrote:
> >> rr_cache_dir function cannot assume REPO/.git is a directory. On the other
> >> side it should be backward compatible - if rr-cache directory/link already
> >> exists it should be returned.
> >>
> >> Signed-off-by: Andrzej Hajda
> >> ---
> >> Hi,
> >>
> >> I am not sure of the purpose of rr-cache symbolic link, dim does not use
> >> it (except its creation/removal). So this patch should be verified by
> >> someone who knows better what is going on here.
> >>
> >> Regards
> >> Andrzej
> >> ---
> >> dim | 20 +++-
> >> 1 file changed, 11 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/dim b/dim
> >> index 3afa8b6..b72ebfd 100755
> >> --- a/dim
> >> +++ b/dim
> >> @@ -554,15 +554,6 @@ function check_conflicts # tree
> >>true
> >> }
> >>
> >> -function rr_cache_dir
> >> -{
> >> - if [ -d $DIM_PREFIX/drm-tip/.git/ ] ; then
> >> - echo $DIM_PREFIX/drm-tip/.git/rr-cache
> >> - else
> >> - echo $DIM_PREFIX/$DIM_REPO/.git/rr-cache
> >> - fi
> >> -}
> > I think this breaks it, rr-cache is shared among all worktrees (which is a
> > big reason for having them).
>
>
> If drm-tip and $DIM_REPO are worktrees (more exactly "linked working
> tree" - ie .git is a file), then rr_cache_dir will return invalid path.
>
> As a result update_rerere_cache will fail create symlink, with this kind
> of error:
>
> ln: failed to create symbolic link '/lab/dim/drm-misc-next/.git':
> File exists
Ah, now I get it, your $DIM_REPO is also a worktree. Yes that's not
supported with the current code.
But your code doesn't fix it. We do _not_ want $(git_dir)/rr-cache here,
but really the .git/rr-cache of the master repo. The worktrees do not have
their own private rr-cache, but use the one of the master repo.
> > And yes dim only sets up the symlink, dim rebuild-tip uses the rr-cache
> > stuff automatically through git merge.
>
>
> I still do not see who and when is using (ie. reading) this link.
> rebuild_tip seems to use only $DIM_PREFIX/drm_rerere/rr-cache. Is there
> some magic inside git itself, or I am just blind?
git merge --rerere-autoupdate uses it internally. We want that drm-tip
uses the rr-cache we store in drm-rerere/rr-cache.
Maybe $(git_dir drm-tip)/../../rr-cache works? Again, the important part
is that we edit the .git/rr-cache in your master repo, not in any of the
worktrees (rr-cache doesn't exist there).
-Daniel
>
>
> Regards
>
> Andrzej
>
>
>
> > -Daniel
> >
> >> -
> >> function git_dir
> >> {
> >>local dir=${1:-$PWD}
> >> @@ -574,6 +565,17 @@ function git_dir
> >>fi
> >> }
> >>
> >> +function rr_cache_dir
> >> +{
> >> + local dir=$(git_dir $DIM_PREFIX/$DIM_REPO)/rr-cache
> >> +
> >> + if [ -d $dir ]; then
> >> + echo $dir
> >> + else
> >> + echo $(git_dir $DIM_PREFIX/drm-tip)/rr-cache
> >> + fi
> >> +}
> >> +
> >> function pull_rerere_cache
> >> {
> >>cd $DIM_PREFIX/drm-rerere/
> >> --
> >> 2.17.1
> >>
> >> ___
> >> dim-tools mailing list
> >> dim-to...@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dim-tools
>
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109066] Launching Libretro Nestopia Core in Retroarch Triggers AMDGPU Kernel Bug
https://bugs.freedesktop.org/show_bug.cgi?id=109066 --- Comment #1 from Nicholas Kazlauskas --- Do you see this occur on the amd-staging-drm-next branch from: https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next ? If yes, then it would also help to know more about your userspace environment: - Are you using X or Wayland? - If you're using X, are you using xf86-video-amdgpu? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 0/1] drm/i915: Enable fastset by default, except on initial modeset
On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote: > Hi All, > > As discussed a while ago, I would like to see us enable fastboot by > default, starting with Skylake / GEN9 and newer hardware, so that we can > avoid an unnecessary modeset at boot and move to a truely flickerfree boot. > > During our previous discussion about this Maarten mentioned that a first > step would be to get this patch from him upstream. So I'm hereby > resubmitting it, with a small fix. Hopefully the CI will like it better > this time (if not we will need to investigate) and once this passes CI > I hope this can be reviewed quickly and we can get this upstream. > > I will also be sending out a follow-up patch which actually makes fastboot > the default on GEN9 and newer, I will mark that as RFC for now since based > on our previous discussion this patch should be landed first. The infoframe precompute/check stuff didn't land yet. I think we want those in before we enable this thing. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Enable fastset by default, except on initial modeset
Hi,
On 17-12-18 15:29, Daniel Vetter wrote:
On Mon, Dec 17, 2018 at 3:23 PM Hans de Goede wrote:
From: Maarten Lankhorst
We may not be perfect at reading out the initial mode, but when the mode
is sanitized by our first modeset we know for sure the state is compatible,
so we can compare with intel_pipe_config_compare.
Changes in v2 (Hans de Goede):
-When checking if we need to reset the mode (initial modeset), check
I915_MODE_FLAG_INHERITED is set in private_flags instead of
private_flags != 0
Signed-off-by: Maarten Lankhorst
Signed-off-by: Hans de Goede
Do we have igts which exercise this functionality?
I'm not sure, but last time Maarten submitted this patch it caused
a bunch of new dmesg warnings CI failures, which seems to indicate that
at least some tests are hitting the new code path where we do a fastset
independent of the fastboot=x parameter.
Having that is
kinda the point of enabling this first only for non-bootup modesets,
so that we can weed out the bugs. I think most (maybe even all) igts
we have do their modesets by explicitly shutting things down, and so
will never hit this. But we have lots of igts, so might have missed
some.
Anyway, patch imo should have a clear indication which igts we need to
watch out for this one here.
Hmm, Maarten, can you provide a list of relevant igts to add to the
commit message ?
Regards,
Hans
---
drivers/gpu/drm/i915/intel_display.c | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index c2980643a1a5..071954d255c6 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12501,6 +12501,22 @@ static int calc_watermark_data(struct drm_atomic_state
*state)
return 0;
}
+static bool can_fastset(struct drm_i915_private *dev_priv,
+ struct intel_crtc_state *old_crtc_state,
+ struct intel_crtc_state *new_crtc_state)
+{
+ bool reset_mode =
+ (old_crtc_state->base.mode.private_flags & I915_MODE_FLAG_INHERITED)
&&
+ !(new_crtc_state->base.mode.private_flags &
I915_MODE_FLAG_INHERITED);
+
+ /* Without fastboot, we always want to modeset the initial mode. */
+ if (reset_mode && !i915_modparams.fastboot)
+ return false;
+
+ return intel_pipe_config_compare(dev_priv, old_crtc_state,
+new_crtc_state, true);
+}
+
/**
* intel_atomic_check - validate state object
* @dev: drm device
@@ -12531,6 +12547,8 @@ static int intel_atomic_check(struct drm_device *dev,
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, crtc_state,
i) {
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
+ struct intel_crtc_state *old_intel_crtc_state =
+ to_intel_crtc_state(old_crtc_state);
if (!needs_modeset(crtc_state))
continue;
@@ -12547,10 +12565,7 @@ static int intel_atomic_check(struct drm_device *dev,
return ret;
}
- if (i915_modparams.fastboot &&
- intel_pipe_config_compare(dev_priv,
- to_intel_crtc_state(old_crtc_state),
- pipe_config, true)) {
+ if (can_fastset(dev_priv, old_intel_crtc_state, pipe_config)) {
crtc_state->mode_changed = false;
pipe_config->update_pipe = true;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108917] gamma adjustments cause stuttering with amdgpu.dc=1, especially problematic with RedShift etc.
https://bugs.freedesktop.org/show_bug.cgi?id=108917 --- Comment #6 from Nicholas Kazlauskas --- I suspect that Alex is right about this being similar to the cursor update issue - a large volume of color management changes through the full atomic commit codepath would likely be quite slow. The dc=1 to dc=0 comparison is good evidence supporting it as well. Expanding the cursor path into a generalized plane update fast path would likely resolve the issue, but may be tricky to do right. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915: Enable fastset by default, except on initial modeset
On Mon, Dec 17, 2018 at 3:23 PM Hans de Goede wrote:
>
> From: Maarten Lankhorst
>
> We may not be perfect at reading out the initial mode, but when the mode
> is sanitized by our first modeset we know for sure the state is compatible,
> so we can compare with intel_pipe_config_compare.
>
> Changes in v2 (Hans de Goede):
> -When checking if we need to reset the mode (initial modeset), check
> I915_MODE_FLAG_INHERITED is set in private_flags instead of
> private_flags != 0
>
> Signed-off-by: Maarten Lankhorst
> Signed-off-by: Hans de Goede
Do we have igts which exercise this functionality? Having that is
kinda the point of enabling this first only for non-bootup modesets,
so that we can weed out the bugs. I think most (maybe even all) igts
we have do their modesets by explicitly shutting things down, and so
will never hit this. But we have lots of igts, so might have missed
some.
Anyway, patch imo should have a clear indication which igts we need to
watch out for this one here.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_display.c | 23 +++
> 1 file changed, 19 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index c2980643a1a5..071954d255c6 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12501,6 +12501,22 @@ static int calc_watermark_data(struct
> drm_atomic_state *state)
> return 0;
> }
>
> +static bool can_fastset(struct drm_i915_private *dev_priv,
> + struct intel_crtc_state *old_crtc_state,
> + struct intel_crtc_state *new_crtc_state)
> +{
> + bool reset_mode =
> + (old_crtc_state->base.mode.private_flags &
> I915_MODE_FLAG_INHERITED) &&
> + !(new_crtc_state->base.mode.private_flags &
> I915_MODE_FLAG_INHERITED);
> +
> + /* Without fastboot, we always want to modeset the initial mode. */
> + if (reset_mode && !i915_modparams.fastboot)
> + return false;
> +
> + return intel_pipe_config_compare(dev_priv, old_crtc_state,
> +new_crtc_state, true);
> +}
> +
> /**
> * intel_atomic_check - validate state object
> * @dev: drm device
> @@ -12531,6 +12547,8 @@ static int intel_atomic_check(struct drm_device *dev,
> for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
> crtc_state, i) {
> struct intel_crtc_state *pipe_config =
> to_intel_crtc_state(crtc_state);
> + struct intel_crtc_state *old_intel_crtc_state =
> + to_intel_crtc_state(old_crtc_state);
>
> if (!needs_modeset(crtc_state))
> continue;
> @@ -12547,10 +12565,7 @@ static int intel_atomic_check(struct drm_device *dev,
> return ret;
> }
>
> - if (i915_modparams.fastboot &&
> - intel_pipe_config_compare(dev_priv,
> - to_intel_crtc_state(old_crtc_state),
> - pipe_config, true)) {
> + if (can_fastset(dev_priv, old_intel_crtc_state, pipe_config))
> {
> crtc_state->mode_changed = false;
> pipe_config->update_pipe = true;
> }
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] drm/i915: Enable fastboot by default on Skylake and newer
We really want to have fastboot enabled by default to avoid an ugly
modeset during boot.
Rather then enabling it everywhere, lets start with enabling it on
Skylake and newer.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/i915_params.c | 6 --
drivers/gpu/drm/i915/i915_params.h | 2 +-
drivers/gpu/drm/i915/intel_display.c | 11 ++-
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 295e981e4a39..ff5f32a3aaf0 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -101,8 +101,10 @@ i915_param_named_unsafe(disable_power_well, int, 0400,
i915_param_named_unsafe(enable_ips, int, 0600, "Enable IPS (default: true)");
-i915_param_named(fastboot, bool, 0600,
- "Try to skip unnecessary mode sets at boot time (default: false)");
+i915_param_named(fastboot, int, 0600,
+ "Try to skip unnecessary mode sets at boot time "
+ "(0=disabled, 1=enabled) "
+ "Default: -1 (use per-chip default)");
i915_param_named_unsafe(prefault_disable, bool, 0600,
"Disable page prefaulting for pread/pwrite/reloc (default:false). "
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/drivers/gpu/drm/i915/i915_params.h
index 6c4d4a21474b..7e11aa4d1d97 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -55,10 +55,10 @@ struct drm_printer;
param(int, edp_vswing, 0) \
param(int, reset, 2) \
param(unsigned int, inject_load_failure, 0) \
+ param(int, fastboot, -1) \
/* leave bools at the end to not create holes */ \
param(bool, alpha_support, IS_ENABLED(CONFIG_DRM_I915_ALPHA_SUPPORT)) \
param(bool, enable_hangcheck, true) \
- param(bool, fastboot, false) \
param(bool, prefault_disable, false) \
param(bool, load_detect_test, false) \
param(bool, force_reset_modeset_test, false) \
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 071954d255c6..62df34d30b1f 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12501,6 +12501,15 @@ static int calc_watermark_data(struct drm_atomic_state
*state)
return 0;
}
+static bool fastboot_enabled(struct drm_i915_private *dev_priv)
+{
+ if (i915_modparams.fastboot != -1)
+ return i915_modparams.fastboot;
+
+ /* Enable fastboot by default on Skylake and newer */
+ return INTEL_GEN(dev_priv) >= 9;
+}
+
static bool can_fastset(struct drm_i915_private *dev_priv,
struct intel_crtc_state *old_crtc_state,
struct intel_crtc_state *new_crtc_state)
@@ -12510,7 +12519,7 @@ static bool can_fastset(struct drm_i915_private
*dev_priv,
!(new_crtc_state->base.mode.private_flags &
I915_MODE_FLAG_INHERITED);
/* Without fastboot, we always want to modeset the initial mode. */
- if (reset_mode && !i915_modparams.fastboot)
+ if (reset_mode && !fastboot_enabled(dev_priv))
return false;
return intel_pipe_config_compare(dev_priv, old_crtc_state,
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
