[Bug 106671] Frequent lock ups for AMD RX 550 graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #17 from Alan W. Irwin --- I terminated the last test immediately because it turns out a new kernel (Linux merlin 4.18.0-1-amd64 #1 SMP Debian 4.18.6-1 (2018-09-06) x86_64 GNU/Linux) has propagated from Debian Unstable to Debian Testing = Buster so I will use that kernel for my new test. On boot with this new kernel the usual blast of random color on the Linux console displayed by the RX 550 that I am used to for all previous kernel versions is now gone. So that is a positive step in the right direction, and I hope that means the Debian Buster graphics stack is finally completely stable for the RX 550, but I will test that hypothesis with this latest test. The latest Debian Buster graphics stack versions for this direct graphics kernel stability test for the RX 550 are as follows: linux-image-4.18.0-1-amd644.18.6-1 amd64-microcode 3.20180524.1 firmware-amd-graphics 20180825+dfsg-1 libdrm-amdgpu1:amd64 2.4.94-1 libglapi-mesa:amd64 18.1.7-1 xserver-xorg-video-amdgpu 18.0.1-1+b1 Here are my kernel parameters which includes the suggested idle=nomwait: irwin@merlin> cat /proc/cmdline BOOT_IMAGE=/boot/vmlinuz-4.18.0-1-amd64 root=UUID=1e45a1ee-a5d6-4327-9a7b-2663ffc0b157 ro rootwait quiet idle=nomwait -- 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 106671] Frequent lock ups for AMD RX 550 graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #16 from Alan W. Irwin --- I was beginning to have some hope that the latest direct access experiment would prove to be stable. However, just now it locked up again after almost 7 days. So the stability is substantially improved compared to before, and my guess is that improvement is due to installation of the amd64-microcode package from Debian Buster for this latest experiment. However, this is still disappointing stability because typically for truly stable systems I achieve up times of 30 days or longer with the only limit on uptime being how often I have to reboot due to kernel upgrades. I have attached a crash report tarball containing dmesg output as well as various log files that captured all log activity before the lockup and the boot afterward. I don't see anything concerning the crash in those log files, but I may be missing something since I am no expert so I would appreciate it if you took a look. I have restarted exactly the same direct graphics access test again (with same versions of graphics stack packages and your recommended idle=nomwait kernel parameter in hopes that the kernel will last longer this time before the lockup and/or I catch more details of the lockup when it occurs. If you would prefer me to try a different variant of this test, please let me know. -- 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 libdrm] CONTRIBUTING: clarify how to request a Developer role
While requesting a Developer role I was pointed to this url and check
those with "owner" role. So add it to our documentation.
Signed-off-by: Lucas De Marchi
---
CONTRIBUTING | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/CONTRIBUTING b/CONTRIBUTING
index 96f1e4fb..487a5c36 100644
--- a/CONTRIBUTING
+++ b/CONTRIBUTING
@@ -78,9 +78,10 @@ below criteria:
- Agrees to use their commit rights in accordance with the documented merge
criteria, tools, and processes.
-To apply for commit rights ("Developer" role in gitlab) send a mail to
-dri-devel@lists.freedesktop.org and please ping the maintainers if your request
-is stuck.
+To apply for commit rights ("Developer" role in gitlab), check project
+members who have the "owner" role at
+https://gitlab.freedesktop.org/mesa/drm/project_members?sort=access_level_desc.
+Any of them can add new developers.
Committers are encouraged to request their commit rights get removed when they
no longer contribute to the project. Commit rights will be reinstated when they
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Request for commit rights on libdrm
On Fri, Sep 14, 2018 at 08:27:34PM +0200, Daniel Vetter wrote: > On Fri, Sep 14, 2018 at 8:24 PM, Lucas De Marchi > wrote: > > Hey, > > > > I'm contributing to libdrm and plan to continue doing so. Reading the > > CONTRIBUTING file I understand I can already request commit rights due > > to my past contributions to libdrm, kernel and i-g-t. I also have a > > pending patch series waiting for more reviews/acks I'd be able to merge > > by myself. > > https://gitlab.freedesktop.org/mesa/drm/project_members?sort=access_level_desc > > ^^ Anyone who's an Owner can add you. Probably simplest if you just > ask one of the Intel folks listed. I had the impression the CONTRIBUTING file stated to send an email to dri-devel due to needing a review of some kind. Lucas De Marchi > > Cheers, Daniel > > > Thanks > > Lucas De Marchi > > > > -- > 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
[Bug 106671] Frequent lock ups for AMD RX 550 graphics card
https://bugs.freedesktop.org/show_bug.cgi?id=106671 --- Comment #15 from Alan W. Irwin --- Created attachment 141567 --> https://bugs.freedesktop.org/attachment.cgi?id=141567=edit log files from latest logup -- 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: rcar-du: Revert "drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying the logic"
Hi Laurent,
I've looked through a bit further to try to understand this issue and I
think I have identified a possible/probable cause.
Before commit 161ad653d6c9, we *always* set the plane->state->alpha as
DRM_BLEND_ALPHA_OPAQUE. (0x)
After this commit, the __drm_atomic_helper_plane_reset() call will only
set state->alpha to 0x if the alpha_property is set:
if (plane->alpha_property)
state->alpha = plane->alpha_property->values[1];
Then the state->alpha value is always referenced in
rcar_du_vsp_plane_setup() and passed to the VSP for that layer.
We can see in rcar_du_planes_init(), that all OVERLAY planes are
configured to have this propery with a call to
drm_plane_create_alpha_property(>plane); however - the PRIMARY
plane is skipped over before setting this.
I believe I recall seeing that the kms-test-planeposition.py
successfully showed other planes which were not the back one (I'm now
going from hazy memory of this afternoon - but I am fairly sure I saw this)
This implies that the primary planes are being incorrectly configured -
but the overlay planes are still functioning as expected.
So I believe we could move the call to create the alpha property:
drm_plane_create_alpha_property(>plane);
to occur before the if (type == DRM_PLANE_TYPE_PRIMARY) continue; statement.
It may or may not make sense to have alpha blending support on the
PRIMARY plane. At the risk of sounding silly - can we have anything else
behind the PRIMARY plane ? (I doubt this, I don't think we have any
extra layers hiding anywhere)
Otherwise, I think we would need to intercept the configuration of the
alpha blending and make sure that all PRIMARY planes are configured to
be fully opaque in our layers. I think this is happening in
rcar_du_vsp_plane_setup().
But rather than put in a conditional in there, I think I'd rather just
initialise the plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE in our
rcar_du_vsp_plane_reset() call and be done with it.
Anyway - just some musings and thoughts at this stage, we can
investigate in more detail next week.
--
Regards
Kieran
On 14/09/18 21:09, Kieran Bingham wrote:
> Commit: 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
> instead of copying the logic") causes a regression in the R-Car DU
> display driver, and prevents any output from being displayed.
>
> The display appears to function correctly but only a black screen is
> ever visible.
>
> Revert the commit.
>
> Signed-off-by: Kieran Bingham
>
> ---
>
> Looking through the code, the reason for this issue isn't particularly
> obvious - and will need some further exploration, which I can't look at
> until Tuesday. So I'm posting this revert patch to
>
> A) Report the issue
> B) Provide a temporary fix
>
> I suspect either the initial alpha value is not set correctly or setting
>
> state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
>
> causes some side effect perhaps. There's not much else that could be
> different between the helper, and the original code.
>
> drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 --
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
> 2 files changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> index 9e07758a755c..5c2462afe408 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> @@ -686,12 +686,14 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
> if (state == NULL)
> return;
>
> - __drm_atomic_helper_plane_reset(plane, >state);
> -
> state->hwindex = -1;
> state->source = RCAR_DU_PLANE_MEMORY;
> state->colorkey = RCAR_DU_COLORKEY_NONE;
> state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> +
> + plane->state = >state;
> + plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
> + plane->state->plane = plane;
> }
>
> static int rcar_du_plane_atomic_set_property(struct drm_plane *plane,
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> index 4576119e..3170b126cfba 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -341,8 +341,11 @@ static void rcar_du_vsp_plane_reset(struct drm_plane
> *plane)
> if (state == NULL)
> return;
>
> - __drm_atomic_helper_plane_reset(plane, >state);
> + state->state.alpha = DRM_BLEND_ALPHA_OPAQUE;
> state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
> +
> + plane->state = >state;
> + plane->state->plane = plane;
> }
>
> static const struct drm_plane_funcs rcar_du_vsp_plane_funcs = {
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau: Grab runtime PM ref in nv50_mstc_detect()
While we currently grab a runtime PM ref in nouveau's normal connector
detection code, we apparently don't do this for MST. This means if we're
in a scenario where the GPU is suspended and userspace attempts to do a
connector probe on an MSTC connector, the probe will fail entirely due
to the DP aux channel and GPU not being woken up:
[ 316.633489] nouveau :01:00.0: i2c: aux 000a: begin idle timeout
[ 316.635713] nouveau :01:00.0: i2c: aux 000a: begin idle timeout
[ 316.637785] nouveau :01:00.0: i2c: aux 000a: begin idle timeout
...
So, grab a runtime PM ref here.
Signed-off-by: Lyude Paul
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers/gpu/drm/nouveau/dispnv50/disp.c
index c94b7f42d62d..9da0bdfe1e1c 100644
--- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
+++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
@@ -938,9 +938,22 @@ static enum drm_connector_status
nv50_mstc_detect(struct drm_connector *connector, bool force)
{
struct nv50_mstc *mstc = nv50_mstc(connector);
+ enum drm_connector_status conn_status;
+ int ret;
+
if (!mstc->port)
return connector_status_disconnected;
- return drm_dp_mst_detect_port(connector, mstc->port->mgr, mstc->port);
+
+ ret = pm_runtime_get_sync(connector->dev->dev);
+ if (ret < 0 && ret != -EACCES)
+ return connector_status_disconnected;
+
+ conn_status = drm_dp_mst_detect_port(connector, mstc->port->mgr,
+mstc->port);
+
+ pm_runtime_mark_last_busy(connector->dev->dev);
+ pm_runtime_put_autosuspend(connector->dev->dev);
+ return conn_status;
}
static void
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed, Sep 12, 2018 at 05:08:52PM +0200, Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
> ---
...
> drivers/platform/x86/wmi.c | 2 +-
...
> static void link_event_work(struct work_struct *work)
> diff --git a/drivers/platform/x86/wmi.c b/drivers/platform/x86/wmi.c
> index 04791ea5d97b..e4d0697e07d6 100644
> --- a/drivers/platform/x86/wmi.c
> +++ b/drivers/platform/x86/wmi.c
> @@ -886,7 +886,7 @@ static const struct file_operations wmi_fops = {
> .read = wmi_char_read,
> .open = wmi_char_open,
> .unlocked_ioctl = wmi_ioctl,
> - .compat_ioctl = wmi_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
For platform/drivers/x86:
Acked-by: Darren Hart (VMware)
As for a longer term solution, would it be possible to init fops in such
a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg
so we don't have to duplicate this boilerplate for every ioctl fops
structure?
--
Darren Hart
VMware Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/2] drm: Add shmem GEM library
Hi
On 09/14/2018 08:09 PM, Noralf Trønnes wrote:
Den 14.09.2018 19.11, skrev Thomas Hellstrom:
On 09/14/2018 06:51 PM, Noralf Trønnes wrote:
Den 14.09.2018 18.13, skrev Daniel Vetter:
On Fri, Sep 14, 2018 at 5:48 PM, Thomas Hellstrom
wrote:
Hi, Noralf,
On 09/11/2018 02:43 PM, Noralf Trønnes wrote:
This patchset adds a library for shmem backed GEM objects and
makes use
of it in tinydrm.
When I made tinydrm I used the CMA helper because it was very
easy to
use. July last year I learned that this limits which drivers to
PRIME
import from, since CMA requires continuous memory. tinydrm
drivers don't
require that. So I set out to change that looking first at shmem,
but
that wasn't working since shmem didn't work with fbdev deferred I/O.
Then I did a vmalloc buffer attempt which worked with deferred
I/O, but
maybe wouldn't be of so much use as a library for other drivers
to use.
As my work to split out stuff from the CMA helper for shared use
came to
an end, I had a generic fbdev emulation that uses a shadow buffer
for
deferred I/O.
This means that I can now use shmem buffers after all.
I have looked at the other drivers that use drm_gem_get_pages() and
several supports different cache modes so I've done that even though
tinydrm only uses the cached one.
Out if interest, how can you use writecombine and uncached with
shared
memory?
as typically the linear kernel map of the affected pages also needs
changing?
I think on x86 at least the core code takes care of that. On arm, I'm
not sure this just works, since you can't change the mode of the
linear map. Instead you need specially allocated memory which is _not_
in the linear map. I guess arm boxes with pcie slots aren't that
common yet :-)
I was hoping to get some feedback on these cache mode flags.
These drivers use them:
udl/udl_gem.c
omapdrm/omap_gem.c
msm/msm_gem.c
etnaviv/etnaviv_gem.c
I don't know if they make sense or not, so any help is appreciated.
It's possible, as Daniel says, that the X86 PAT system now
automatically tracks all pte inserts and changes the linear kernel
map accordingly. It certainly didn't use to do that, so for example
TTM does that explicitly. And it's a very slow operation since it
involves a global cache- and TLB flush across all cores. So if PAT is
doing that on a per-page basis, it's probably bound to be very slow.
The concern with shmem (last time I looked which was a couple of
years ago, i admit) was that shmem needs the linear kernel map to
copy data in and out when swapping and on hibernate. If the above
drivers that you mention don't use shmem, that's all fine, but the
combination of shmem and special memory that is NOT mapped in the
kernel memory does look a bit odd to me.
When I started writing this helper I first looked at udl which has
different cache modes, but only uses shmem. It does hardcode cache mode
to cached though. Based on what you say I'm starting to think that maybe
the udl GEM code was just copied from some other driver and not cleaned
up properly afterwards.
In addition to shmem, msm and etnaviv use vram and omap uses
dma_alloc_wc(). So the cache modes are for distinguishing the memory
types I suppose.
They all have this type of code in their *_mmap_obj() function (with the
same comment):
if (msm_obj->flags & MSM_BO_WC) {
vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
} else if (msm_obj->flags & MSM_BO_UNCACHED) {
vma->vm_page_prot =
pgprot_noncached(vm_get_page_prot(vma->vm_flags));
} else {
/*
* Shunt off cached objs to shmem file so they have their own
* address_space (so unmap_mapping_range does what we want,
* in particular in the case of mmap'd dmabufs)
*/
fput(vma->vm_file);
get_file(obj->filp);
vma->vm_pgoff = 0;
vma->vm_file = obj->filp;
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
}
So now it's starting to make more sense to me. It seems that shmem is the
cached mode and that WC and uncached is used for the other memory types.
If I've understood this correctly, it means that I can just drop the
cache modes.
Yes, I think that might be a good idea, at least until there is a clear
understanding how and if the linear kernel map is handled, and it's
probably different on each architecture. Best would of course be if we
were allowed to set up different mappings to a page with conflicting
cache modes...
/Thomas
Thanks,
Noralf.
/Thomas
Noralf.
-Daniel
Thanks,
Thomas
___
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
[PATCH] drm: rcar-du: Revert "drm: rcar-du: Use __drm_atomic_helper_plane_reset instead of copying the logic"
Commit: 161ad653d6c9 ("drm: rcar-du: Use __drm_atomic_helper_plane_reset
instead of copying the logic") causes a regression in the R-Car DU
display driver, and prevents any output from being displayed.
The display appears to function correctly but only a black screen is
ever visible.
Revert the commit.
Signed-off-by: Kieran Bingham
---
Looking through the code, the reason for this issue isn't particularly
obvious - and will need some further exploration, which I can't look at
until Tuesday. So I'm posting this revert patch to
A) Report the issue
B) Provide a temporary fix
I suspect either the initial alpha value is not set correctly or setting
state->pixel_blend_mode = DRM_MODE_BLEND_PREMULTI;
causes some side effect perhaps. There's not much else that could be
different between the helper, and the original code.
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 6 --
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 -
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 9e07758a755c..5c2462afe408 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -686,12 +686,14 @@ static void rcar_du_plane_reset(struct drm_plane *plane)
if (state == NULL)
return;
- __drm_atomic_helper_plane_reset(plane, >state);
-
state->hwindex = -1;
state->source = RCAR_DU_PLANE_MEMORY;
state->colorkey = RCAR_DU_COLORKEY_NONE;
state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
+
+ plane->state = >state;
+ plane->state->alpha = DRM_BLEND_ALPHA_OPAQUE;
+ plane->state->plane = plane;
}
static int rcar_du_plane_atomic_set_property(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 4576119e..3170b126cfba 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -341,8 +341,11 @@ static void rcar_du_vsp_plane_reset(struct drm_plane
*plane)
if (state == NULL)
return;
- __drm_atomic_helper_plane_reset(plane, >state);
+ state->state.alpha = DRM_BLEND_ALPHA_OPAQUE;
state->state.zpos = plane->type == DRM_PLANE_TYPE_PRIMARY ? 0 : 1;
+
+ plane->state = >state;
+ plane->state->plane = plane;
}
static const struct drm_plane_funcs rcar_du_vsp_plane_funcs = {
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: Return -ENOTSUPP in drm_setclientcap() when driver do not support KMS
On Fri, Sep 14, 2018 at 10:02 PM, Daniel Vetter wrote:
> On Fri, Sep 14, 2018 at 7:04 PM, Chris Wilson
> wrote:
>> Quoting Souza, Jose (2018-09-14 17:30:59)
>>> On Fri, 2018-09-14 at 09:15 +0100, Chris Wilson wrote:
>>> > Quoting José Roberto de Souza (2018-09-13 23:13:41)
>>> > > @@ -306,6 +306,9 @@ drm_setclientcap(struct drm_device *dev, void
>>> > > *data, struct drm_file *file_priv)
>>> > > {
>>> > > struct drm_set_client_cap *req = data;
>>> > >
>>> > > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
>>> > > + return -ENOTSUPP;
>>> >
>>> > The wider question though is client cap restricted to modesetting
>>> > capabilities? Or should each case include a check like
>>> > DRM_CLIENT_CAP_ATOMIC.
>>>
>>> Well all of those:
>>>
>>> DRM_CLIENT_CAP_STEREO_3D
>>> DRM_CLIENT_CAP_UNIVERSAL_PLANES
>>> DRM_CLIENT_CAP_ATOMIC
>>> DRM_CLIENT_CAP_ASPECT_RATIO
>>> DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
>>>
>>> are just usefull with KMS.
>>
>> It more about the semantics. If it's the first guard in the function, it
>> gives the impression that the setclientcap ioctl is KMS only. If they
>> are repeated for each case, then it's clear that the ioctl is more
>> general and it just those caps that are KMS only.
>>
>> Imo, the drm_client is wider than the kms interface, but I may be wrong.
Oops, slipped :-)
In getcap we have 2 blocks, with DRIVER_MODESET check in between. I
think a comment along the lines of
/* No render-only settable capabilities for now */
/* Below caps only work with KMS drivers */
if (!drm_core_check_feature(DRIVER_MODESET))
return -ENOTSUPP;
I think with that it's clear that it's _not_ the top-level check, and
if someone needs to add a gem cap, they know where to put it. Not that
we needed that anytime in the past 10 years, but who knows.
Cheers, Daniel
--
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] drm: Return -ENOTSUPP in drm_setclientcap() when driver do not support KMS
On Fri, Sep 14, 2018 at 7:04 PM, Chris Wilson wrote:
> Quoting Souza, Jose (2018-09-14 17:30:59)
>> On Fri, 2018-09-14 at 09:15 +0100, Chris Wilson wrote:
>> > Quoting José Roberto de Souza (2018-09-13 23:13:41)
>> > > @@ -306,6 +306,9 @@ drm_setclientcap(struct drm_device *dev, void
>> > > *data, struct drm_file *file_priv)
>> > > {
>> > > struct drm_set_client_cap *req = data;
>> > >
>> > > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
>> > > + return -ENOTSUPP;
>> >
>> > The wider question though is client cap restricted to modesetting
>> > capabilities? Or should each case include a check like
>> > DRM_CLIENT_CAP_ATOMIC.
>>
>> Well all of those:
>>
>> DRM_CLIENT_CAP_STEREO_3D
>> DRM_CLIENT_CAP_UNIVERSAL_PLANES
>> DRM_CLIENT_CAP_ATOMIC
>> DRM_CLIENT_CAP_ASPECT_RATIO
>> DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
>>
>> are just usefull with KMS.
>
> It more about the semantics. If it's the first guard in the function, it
> gives the impression that the setclientcap ioctl is KMS only. If they
> are repeated for each case, then it's clear that the ioctl is more
> general and it just those caps that are KMS only.
>
> Imo, the drm_client is wider than the kms interface, but I may be wrong.
In getcap we have 2 blocks, with DRIVER_MODESET check in between. I
think a comment along the lines of
> -Chris
> ___
> 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] [RFC]drm: add syncobj timeline support v5
Am 14.09.2018 um 20:24 schrieb Daniel Vetter: On Fri, Sep 14, 2018 at 6:43 PM, Christian König wrote: Am 14.09.2018 um 18:10 schrieb Daniel Vetter: On Fri, Sep 14, 2018 at 12:49:45PM +0200, Christian König wrote: Am 14.09.2018 um 12:37 schrieb Chunming Zhou: This patch is for VK_KHR_timeline_semaphore extension, semaphore is called syncobj in kernel side: This extension introduces a new type of syncobj that has an integer payload identifying a point in a timeline. Such timeline syncobjs support the following operations: * CPU query - A host operation that allows querying the payload of the timeline syncobj. * CPU wait - A host operation that allows a blocking wait for a timeline syncobj to reach a specified value. * Device wait - A device operation that allows waiting for a timeline syncobj to reach a specified value. * Device signal - A device operation that allows advancing the timeline syncobj to a specified value. Since it's a timeline, that means the front time point(PT) always is signaled before the late PT. a. signal PT design: Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when PT[N] fence is signaled, the timeline will increase to value of PT[N]. b. wait PT design: Wait PT fence is signaled by reaching timeline point value, when timeline is increasing, will compare wait PTs value with new timeline value, if PT value is lower than timeline value, then wait PT will be signaled, otherwise keep in list. syncobj wait operation can wait on any point of timeline, so need a RB tree to order them. And wait PT could ahead of signal PT, we need a sumission fence to perform that. v2: 1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian) 2. move unexposed denitions to .c file. (Daniel Vetter) 3. split up the change to drm_syncobj_find_fence() in a separate patch. (Christian) 4. split up the change to drm_syncobj_replace_fence() in a separate patch. 5. drop the submission_fence implementation and instead use wait_event() for that. (Christian) 6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter) v3: 1. replace normal syncobj with timeline implemenation. (Vetter and Christian) a. normal syncobj signal op will create a signal PT to tail of signal pt list. b. normal syncobj wait op will create a wait pt with last signal point, and this wait PT is only signaled by related signal point PT. 2. many bug fix and clean up 3. stub fence moving is moved to other patch. v4： 1. fix RB tree loop with while(node=rb_first(...)). (Christian) 2. fix syncobj lifecycle. (Christian) 3. only enable_signaling when there is wait_pt. (Christian) 4. fix timeline path issues. 5. write a timeline test in libdrm v5: (Christian) 1. semaphore is called syncobj in kernel side. 2. don't need 'timeline' characters in some function name. 3. keep syncobj cb normal syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore* timeline syncobj is tested by ./amdgpu_test -s 9 Signed-off-by: Chunming Zhou Cc: Christian Konig Cc: Dave Airlie Cc: Daniel Rakos Cc: Daniel Vetter At least on first glance that looks like it should work, going to do a detailed review on Monday. Just for my understanding, it's all condensed down to 1 patch now? I kinda didn't follow the detailed discussion last few days at all :-/ I've already committed all the cleanup/fix prerequisites to drm-misc-next. The driver specific implementation needs to come on top and maybe a new CPU wait IOCTL. But essentially this patch is just the core of the kernel implementation. Ah cool, missed that. Also, is there a testcase, igt highly preferred (because then we'll run it in our intel-gfx CI, and a bunch of people outside of intel have already discovered that and are using it). libdrm patches and I think amdgpu based test cases where already published as well. Not sure about igt testcases. I guess we can write them when the intel implementation shows up. Just kinda still hoping that we'd have a more unfified test suite. And not really well-kept secret: We do have an amdgpu in our CI, in the form of kbl-g :-) But unfortunately it's not running the full test set for patches (only for drm-tip). But we could perhaps run more of the amdgpu tests somehow, if there's serious interest. Well I wouldn't mind if we sooner or later get rid of the amdgpu unit tests in libdrm. They are more or less just a really bloody mess. Christian. Cheers, Daniel Christian. Thanks, Daniel Christian. --- drivers/gpu/drm/drm_syncobj.c | 294 ++--- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +- include/drm/drm_syncobj.h | 62 +++-- include/uapi/drm/drm.h | 1 + 4 files changed, 292 insertions(+), 69 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index e9ce623d049e..e78d076f2703 100644 --- a/drivers/gpu/drm/drm_syncobj.c +++
Re: Request for commit rights on libdrm
On Fri, Sep 14, 2018 at 8:24 PM, Lucas De Marchi wrote: > Hey, > > I'm contributing to libdrm and plan to continue doing so. Reading the > CONTRIBUTING file I understand I can already request commit rights due > to my past contributions to libdrm, kernel and i-g-t. I also have a > pending patch series waiting for more reviews/acks I'd be able to merge > by myself. https://gitlab.freedesktop.org/mesa/drm/project_members?sort=access_level_desc ^^ Anyone who's an Owner can add you. Probably simplest if you just ask one of the Intel folks listed. Cheers, Daniel > Thanks > Lucas De Marchi -- 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
Request for commit rights on libdrm
Hey, I'm contributing to libdrm and plan to continue doing so. Reading the CONTRIBUTING file I understand I can already request commit rights due to my past contributions to libdrm, kernel and i-g-t. I also have a pending patch series waiting for more reviews/acks I'd be able to merge by myself. Thanks Lucas De Marchi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC]drm: add syncobj timeline support v5
On Fri, Sep 14, 2018 at 6:43 PM, Christian König wrote: > Am 14.09.2018 um 18:10 schrieb Daniel Vetter: >> >> On Fri, Sep 14, 2018 at 12:49:45PM +0200, Christian König wrote: >>> >>> Am 14.09.2018 um 12:37 schrieb Chunming Zhou: This patch is for VK_KHR_timeline_semaphore extension, semaphore is called syncobj in kernel side: This extension introduces a new type of syncobj that has an integer payload identifying a point in a timeline. Such timeline syncobjs support the following operations: * CPU query - A host operation that allows querying the payload of the timeline syncobj. * CPU wait - A host operation that allows a blocking wait for a timeline syncobj to reach a specified value. * Device wait - A device operation that allows waiting for a timeline syncobj to reach a specified value. * Device signal - A device operation that allows advancing the timeline syncobj to a specified value. Since it's a timeline, that means the front time point(PT) always is signaled before the late PT. a. signal PT design: Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when PT[N] fence is signaled, the timeline will increase to value of PT[N]. b. wait PT design: Wait PT fence is signaled by reaching timeline point value, when timeline is increasing, will compare wait PTs value with new timeline value, if PT value is lower than timeline value, then wait PT will be signaled, otherwise keep in list. syncobj wait operation can wait on any point of timeline, so need a RB tree to order them. And wait PT could ahead of signal PT, we need a sumission fence to perform that. v2: 1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian) 2. move unexposed denitions to .c file. (Daniel Vetter) 3. split up the change to drm_syncobj_find_fence() in a separate patch. (Christian) 4. split up the change to drm_syncobj_replace_fence() in a separate patch. 5. drop the submission_fence implementation and instead use wait_event() for that. (Christian) 6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter) v3: 1. replace normal syncobj with timeline implemenation. (Vetter and Christian) a. normal syncobj signal op will create a signal PT to tail of signal pt list. b. normal syncobj wait op will create a wait pt with last signal point, and this wait PT is only signaled by related signal point PT. 2. many bug fix and clean up 3. stub fence moving is moved to other patch. v4： 1. fix RB tree loop with while(node=rb_first(...)). (Christian) 2. fix syncobj lifecycle. (Christian) 3. only enable_signaling when there is wait_pt. (Christian) 4. fix timeline path issues. 5. write a timeline test in libdrm v5: (Christian) 1. semaphore is called syncobj in kernel side. 2. don't need 'timeline' characters in some function name. 3. keep syncobj cb normal syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore* timeline syncobj is tested by ./amdgpu_test -s 9 Signed-off-by: Chunming Zhou Cc: Christian Konig Cc: Dave Airlie Cc: Daniel Rakos Cc: Daniel Vetter >>> >>> At least on first glance that looks like it should work, going to do a >>> detailed review on Monday. >> >> Just for my understanding, it's all condensed down to 1 patch now? I kinda >> didn't follow the detailed discussion last few days at all :-/ > > > I've already committed all the cleanup/fix prerequisites to drm-misc-next. > > The driver specific implementation needs to come on top and maybe a new CPU > wait IOCTL. > > But essentially this patch is just the core of the kernel implementation. Ah cool, missed that. >> Also, is there a testcase, igt highly preferred (because then we'll run it >> in our intel-gfx CI, and a bunch of people outside of intel have already >> discovered that and are using it). > > > libdrm patches and I think amdgpu based test cases where already published > as well. > > Not sure about igt testcases. I guess we can write them when the intel implementation shows up. Just kinda still hoping that we'd have a more unfified test suite. And not really well-kept secret: We do have an amdgpu in our CI, in the form of kbl-g :-) But unfortunately it's not running the full test set for patches (only for drm-tip). But we could perhaps run more of the amdgpu tests somehow, if there's serious interest. Cheers, Daniel > Christian. > > >> >> Thanks, Daniel >> >>> Christian. >>> --- drivers/gpu/drm/drm_syncobj.c | 294 ++--- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +- include/drm/drm_syncobj.h | 62 +++--
Re: [PATCH v3 0/2] drm: Add shmem GEM library
Den 14.09.2018 19.11, skrev Thomas Hellstrom:
On 09/14/2018 06:51 PM, Noralf Trønnes wrote:
Den 14.09.2018 18.13, skrev Daniel Vetter:
On Fri, Sep 14, 2018 at 5:48 PM, Thomas Hellstrom
wrote:
Hi, Noralf,
On 09/11/2018 02:43 PM, Noralf Trønnes wrote:
This patchset adds a library for shmem backed GEM objects and
makes use
of it in tinydrm.
When I made tinydrm I used the CMA helper because it was very easy to
use. July last year I learned that this limits which drivers to PRIME
import from, since CMA requires continuous memory. tinydrm drivers
don't
require that. So I set out to change that looking first at shmem, but
that wasn't working since shmem didn't work with fbdev deferred I/O.
Then I did a vmalloc buffer attempt which worked with deferred
I/O, but
maybe wouldn't be of so much use as a library for other drivers to
use.
As my work to split out stuff from the CMA helper for shared use
came to
an end, I had a generic fbdev emulation that uses a shadow buffer for
deferred I/O.
This means that I can now use shmem buffers after all.
I have looked at the other drivers that use drm_gem_get_pages() and
several supports different cache modes so I've done that even though
tinydrm only uses the cached one.
Out if interest, how can you use writecombine and uncached with shared
memory?
as typically the linear kernel map of the affected pages also needs
changing?
I think on x86 at least the core code takes care of that. On arm, I'm
not sure this just works, since you can't change the mode of the
linear map. Instead you need specially allocated memory which is _not_
in the linear map. I guess arm boxes with pcie slots aren't that
common yet :-)
I was hoping to get some feedback on these cache mode flags.
These drivers use them:
udl/udl_gem.c
omapdrm/omap_gem.c
msm/msm_gem.c
etnaviv/etnaviv_gem.c
I don't know if they make sense or not, so any help is appreciated.
It's possible, as Daniel says, that the X86 PAT system now
automatically tracks all pte inserts and changes the linear kernel map
accordingly. It certainly didn't use to do that, so for example TTM
does that explicitly. And it's a very slow operation since it involves
a global cache- and TLB flush across all cores. So if PAT is doing
that on a per-page basis, it's probably bound to be very slow.
The concern with shmem (last time I looked which was a couple of years
ago, i admit) was that shmem needs the linear kernel map to copy data
in and out when swapping and on hibernate. If the above drivers that
you mention don't use shmem, that's all fine, but the combination of
shmem and special memory that is NOT mapped in the kernel memory does
look a bit odd to me.
When I started writing this helper I first looked at udl which has
different cache modes, but only uses shmem. It does hardcode cache mode
to cached though. Based on what you say I'm starting to think that maybe
the udl GEM code was just copied from some other driver and not cleaned
up properly afterwards.
In addition to shmem, msm and etnaviv use vram and omap uses
dma_alloc_wc(). So the cache modes are for distinguishing the memory
types I suppose.
They all have this type of code in their *_mmap_obj() function (with the
same comment):
if (msm_obj->flags & MSM_BO_WC) {
vma->vm_page_prot =
pgprot_writecombine(vm_get_page_prot(vma->vm_flags));
} else if (msm_obj->flags & MSM_BO_UNCACHED) {
vma->vm_page_prot =
pgprot_noncached(vm_get_page_prot(vma->vm_flags));
} else {
/*
* Shunt off cached objs to shmem file so they have their own
* address_space (so unmap_mapping_range does what we want,
* in particular in the case of mmap'd dmabufs)
*/
fput(vma->vm_file);
get_file(obj->filp);
vma->vm_pgoff = 0;
vma->vm_file = obj->filp;
vma->vm_page_prot = vm_get_page_prot(vma->vm_flags);
}
So now it's starting to make more sense to me. It seems that shmem is the
cached mode and that WC and uncached is used for the other memory types.
If I've understood this correctly, it means that I can just drop the
cache modes.
Thanks,
Noralf.
/Thomas
Noralf.
-Daniel
Thanks,
Thomas
___
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 107940] libdrm 2.4.94-1 causes blender to crash on opencl
https://bugs.freedesktop.org/show_bug.cgi?id=107940 --- Comment #1 from Mowley --- can provide more info if required but was unsure as to what specifically I should attach in order to help. -- 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 107940] libdrm 2.4.94-1 causes blender to crash on opencl
https://bugs.freedesktop.org/show_bug.cgi?id=107940 Bug ID: 107940 Summary: libdrm 2.4.94-1 causes blender to crash on opencl Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: libdrm Assignee: dri-devel@lists.freedesktop.org Reporter: yachts...@hotmail.com Running Arch Linux on AMD FX-8350 with Radeon Pro WX-5100 GPU version 2.4.94-1 of libdrm caused blender to crash with the following error amdgpu_device_initialize: amdgpu_query_info(ACCEL_WORKING) failed (-9) downgraded to 2.4.93-1 as a temporary fix. -- 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/msm/A5xx: Skip hardware preemption init if no preemption
On Fri, Sep 14, 2018 at 02:08:55PM +0530, Sharat Masetty wrote:
> In the case where preemption is not enabled, this patch simply skips
> preemption related initialization in hardware init sequence.
Reviewed-by: Jordan Crouse
> Signed-off-by: Sharat Masetty
> ---
> drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> index 970c796..6a3c560 100644
> --- a/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> +++ b/drivers/gpu/drm/msm/adreno/a5xx_preempt.c
> @@ -208,6 +208,13 @@ void a5xx_preempt_hw_init(struct msm_gpu *gpu)
> struct a5xx_gpu *a5xx_gpu = to_a5xx_gpu(adreno_gpu);
> int i;
>
> + /* Always come up on rb 0 */
> + a5xx_gpu->cur_ring = gpu->rb[0];
> +
> + /* No preemption if we only have one ring */
> + if (gpu->nr_rings == 1)
> + return;
> +
> for (i = 0; i < gpu->nr_rings; i++) {
> a5xx_gpu->preempt[i]->wptr = 0;
> a5xx_gpu->preempt[i]->rptr = 0;
> @@ -220,9 +227,6 @@ void a5xx_preempt_hw_init(struct msm_gpu *gpu)
>
> /* Reset the preemption state */
> set_preempt_state(a5xx_gpu, PREEMPT_NONE);
> -
> - /* Always come up on rb 0 */
> - a5xx_gpu->cur_ring = gpu->rb[0];
> }
>
> static int preempt_init_ring(struct a5xx_gpu *a5xx_gpu,
> --
> 1.9.1
>
--
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 v3 0/2] drm: Add shmem GEM library
On 09/14/2018 06:51 PM, Noralf Trønnes wrote: Den 14.09.2018 18.13, skrev Daniel Vetter: On Fri, Sep 14, 2018 at 5:48 PM, Thomas Hellstrom wrote: Hi, Noralf, On 09/11/2018 02:43 PM, Noralf Trønnes wrote: This patchset adds a library for shmem backed GEM objects and makes use of it in tinydrm. When I made tinydrm I used the CMA helper because it was very easy to use. July last year I learned that this limits which drivers to PRIME import from, since CMA requires continuous memory. tinydrm drivers don't require that. So I set out to change that looking first at shmem, but that wasn't working since shmem didn't work with fbdev deferred I/O. Then I did a vmalloc buffer attempt which worked with deferred I/O, but maybe wouldn't be of so much use as a library for other drivers to use. As my work to split out stuff from the CMA helper for shared use came to an end, I had a generic fbdev emulation that uses a shadow buffer for deferred I/O. This means that I can now use shmem buffers after all. I have looked at the other drivers that use drm_gem_get_pages() and several supports different cache modes so I've done that even though tinydrm only uses the cached one. Out if interest, how can you use writecombine and uncached with shared memory? as typically the linear kernel map of the affected pages also needs changing? I think on x86 at least the core code takes care of that. On arm, I'm not sure this just works, since you can't change the mode of the linear map. Instead you need specially allocated memory which is _not_ in the linear map. I guess arm boxes with pcie slots aren't that common yet :-) I was hoping to get some feedback on these cache mode flags. These drivers use them: udl/udl_gem.c omapdrm/omap_gem.c msm/msm_gem.c etnaviv/etnaviv_gem.c I don't know if they make sense or not, so any help is appreciated. It's possible, as Daniel says, that the X86 PAT system now automatically tracks all pte inserts and changes the linear kernel map accordingly. It certainly didn't use to do that, so for example TTM does that explicitly. And it's a very slow operation since it involves a global cache- and TLB flush across all cores. So if PAT is doing that on a per-page basis, it's probably bound to be very slow. The concern with shmem (last time I looked which was a couple of years ago, i admit) was that shmem needs the linear kernel map to copy data in and out when swapping and on hibernate. If the above drivers that you mention don't use shmem, that's all fine, but the combination of shmem and special memory that is NOT mapped in the kernel memory does look a bit odd to me. /Thomas Noralf. -Daniel Thanks, Thomas ___ 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
Re: [PATCH] drm: Return -ENOTSUPP in drm_setclientcap() when driver do not support KMS
Quoting Souza, Jose (2018-09-14 17:30:59)
> On Fri, 2018-09-14 at 09:15 +0100, Chris Wilson wrote:
> > Quoting José Roberto de Souza (2018-09-13 23:13:41)
> > > @@ -306,6 +306,9 @@ drm_setclientcap(struct drm_device *dev, void
> > > *data, struct drm_file *file_priv)
> > > {
> > > struct drm_set_client_cap *req = data;
> > >
> > > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > > + return -ENOTSUPP;
> >
> > The wider question though is client cap restricted to modesetting
> > capabilities? Or should each case include a check like
> > DRM_CLIENT_CAP_ATOMIC.
>
> Well all of those:
>
> DRM_CLIENT_CAP_STEREO_3D
> DRM_CLIENT_CAP_UNIVERSAL_PLANES
> DRM_CLIENT_CAP_ATOMIC
> DRM_CLIENT_CAP_ASPECT_RATIO
> DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
>
> are just usefull with KMS.
It more about the semantics. If it's the first guard in the function, it
gives the impression that the setclientcap ioctl is KMS only. If they
are repeated for each case, then it's clear that the ioctl is more
general and it just those caps that are KMS only.
Imo, the drm_client is wider than the kms interface, but I may be wrong.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/imx: ipuv3-plane: add IDMAC timeout warning
From: Philipp Zabel
ipu_plane_disable should never be called while the plane IDMAC channel
is active. The busy wait is just a safety net that should never time
out.
Signed-off-by: Philipp Zabel
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/imx/ipuv3-plane.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index c95a2fc51741..23fba068e964 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -236,9 +236,15 @@ static void ipu_plane_enable(struct ipu_plane *ipu_plane)
void ipu_plane_disable(struct ipu_plane *ipu_plane, bool disable_dp_channel)
{
+ int ret;
+
DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
- ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
+ ret = ipu_idmac_wait_busy(ipu_plane->ipu_ch, 50);
+ if (ret == -ETIMEDOUT) {
+ DRM_ERROR("[PLANE:%d] IDMAC timeout\n",
+ ipu_plane->base.base.id);
+ }
if (ipu_plane->dp && disable_dp_channel)
ipu_dp_disable_channel(ipu_plane->dp, false);
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/4] gpu: ipu-v3: pre: add double buffer status readback
This allows the upper layers to check if a double buffer update has
been applied by the PRE or is still pending.
Signed-off-by: Lucas Stach
---
drivers/gpu/ipu-v3/ipu-pre.c | 6 ++
drivers/gpu/ipu-v3/ipu-prv.h | 1 +
2 files changed, 7 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-pre.c b/drivers/gpu/ipu-v3/ipu-pre.c
index 2f8db9d62551..7389ad157fd6 100644
--- a/drivers/gpu/ipu-v3/ipu-pre.c
+++ b/drivers/gpu/ipu-v3/ipu-pre.c
@@ -259,6 +259,12 @@ void ipu_pre_update(struct ipu_pre *pre, unsigned int
bufaddr)
writel(IPU_PRE_CTRL_SDW_UPDATE, pre->regs + IPU_PRE_CTRL_SET);
}
+bool ipu_pre_update_done(struct ipu_pre *pre)
+{
+ return !(readl_relaxed(pre->regs + IPU_PRE_CTRL) &
+IPU_PRE_CTRL_SDW_UPDATE);
+}
+
u32 ipu_pre_get_baddr(struct ipu_pre *pre)
{
return (u32)pre->buffer_paddr;
diff --git a/drivers/gpu/ipu-v3/ipu-prv.h b/drivers/gpu/ipu-v3/ipu-prv.h
index d6beee99b6b8..215d342d8441 100644
--- a/drivers/gpu/ipu-v3/ipu-prv.h
+++ b/drivers/gpu/ipu-v3/ipu-prv.h
@@ -272,6 +272,7 @@ void ipu_pre_configure(struct ipu_pre *pre, unsigned int
width,
unsigned int height, unsigned int stride, u32 format,
uint64_t modifier, unsigned int bufaddr);
void ipu_pre_update(struct ipu_pre *pre, unsigned int bufaddr);
+bool ipu_pre_update_done(struct ipu_pre *pre);
struct ipu_prg *ipu_prg_lookup_by_phandle(struct device *dev, const char *name,
int ipu_id);
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/4] gpu: ipu-v3: prg: add function to get channel configure status
This allows channels using the PRG to check if a requested configuration
update has been applied or is still pending.
Signed-off-by: Lucas Stach
---
drivers/gpu/ipu-v3/ipu-prg.c | 16
include/video/imx-ipu-v3.h | 1 +
2 files changed, 17 insertions(+)
diff --git a/drivers/gpu/ipu-v3/ipu-prg.c b/drivers/gpu/ipu-v3/ipu-prg.c
index 38a3a9764e49..f78463cf1c15 100644
--- a/drivers/gpu/ipu-v3/ipu-prg.c
+++ b/drivers/gpu/ipu-v3/ipu-prg.c
@@ -347,6 +347,22 @@ int ipu_prg_channel_configure(struct ipuv3_channel
*ipu_chan,
}
EXPORT_SYMBOL_GPL(ipu_prg_channel_configure);
+int ipu_prg_channel_configure_done(struct ipuv3_channel *ipu_chan)
+{
+ int prg_chan = ipu_prg_ipu_to_prg_chan(ipu_chan->num);
+ struct ipu_prg *prg = ipu_chan->ipu->prg_priv;
+ struct ipu_prg_channel *chan;
+
+ if (prg_chan < 0)
+ return -EINVAL;
+
+ chan = >chan[prg_chan];
+ WARN_ON(!chan->enabled);
+
+ return ipu_pre_update_done(prg->pres[chan->used_pre]);
+}
+EXPORT_SYMBOL_GPL(ipu_prg_channel_configure_done);
+
static int ipu_prg_probe(struct platform_device *pdev)
{
struct device *dev = >dev;
diff --git a/include/video/imx-ipu-v3.h b/include/video/imx-ipu-v3.h
index abbad94e14a1..45802eab1084 100644
--- a/include/video/imx-ipu-v3.h
+++ b/include/video/imx-ipu-v3.h
@@ -345,6 +345,7 @@ int ipu_prg_channel_configure(struct ipuv3_channel
*ipu_chan,
unsigned int axi_id, unsigned int width,
unsigned int height, unsigned int stride,
u32 format, uint64_t modifier, unsigned long
*eba);
+int ipu_prg_channel_configure_done(struct ipuv3_channel *ipu_chan);
/*
* IPU CMOS Sensor Interface (csi) functions
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/4] drm/imx: only send commit done event when all state has been applied
Currently there is a small race window where we could manage to arm the
vblank event from atomic flush, but programming the hardware was too close
to the frame end, so the hardware will only apply the current state on the
next vblank. In this case we will send out the commit done event too early
causing userspace to reuse framebuffes that are still in use.
Instead of using the event arming mechnism, just remember the pending event
and send it from the vblank IRQ handler, once we are sure that all state
has been applied sucessfully.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/imx/ipuv3-crtc.c | 32
1 file changed, 28 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/imx/ipuv3-crtc.c b/drivers/gpu/drm/imx/ipuv3-crtc.c
index 7d4b710b837a..b0c95565a28d 100644
--- a/drivers/gpu/drm/imx/ipuv3-crtc.c
+++ b/drivers/gpu/drm/imx/ipuv3-crtc.c
@@ -42,6 +42,7 @@ struct ipu_crtc {
struct ipu_dc *dc;
struct ipu_di *di;
int irq;
+ struct drm_pending_vblank_event *event;
};
static inline struct ipu_crtc *to_ipu_crtc(struct drm_crtc *crtc)
@@ -181,8 +182,31 @@ static const struct drm_crtc_funcs ipu_crtc_funcs = {
static irqreturn_t ipu_irq_handler(int irq, void *dev_id)
{
struct ipu_crtc *ipu_crtc = dev_id;
+ struct drm_crtc *crtc = _crtc->base;
+ unsigned long flags;
+ int i;
+
+ drm_crtc_handle_vblank(crtc);
+
+ if (ipu_crtc->event) {
+ for (i = 0; i < ARRAY_SIZE(ipu_crtc->plane); i++) {
+ struct ipu_plane *plane = ipu_crtc->plane[i];
+
+ if (!plane)
+ continue;
+
+ if (!ipu_plane_atomic_update_done(>base))
+ break;
+ }
- drm_crtc_handle_vblank(_crtc->base);
+ if (i == ARRAY_SIZE(ipu_crtc->plane)) {
+ spin_lock_irqsave(>dev->event_lock, flags);
+ drm_crtc_send_vblank_event(crtc, ipu_crtc->event);
+ ipu_crtc->event = NULL;
+ drm_crtc_vblank_put(crtc);
+ spin_unlock_irqrestore(>dev->event_lock, flags);
+ }
+ }
return IRQ_HANDLED;
}
@@ -229,13 +253,13 @@ static void ipu_crtc_atomic_begin(struct drm_crtc *crtc,
static void ipu_crtc_atomic_flush(struct drm_crtc *crtc,
struct drm_crtc_state *old_crtc_state)
{
- spin_lock_irq(>dev->event_lock);
+ struct ipu_crtc *ipu_crtc = to_ipu_crtc(crtc);
+
if (crtc->state->event) {
WARN_ON(drm_crtc_vblank_get(crtc));
- drm_crtc_arm_vblank_event(crtc, crtc->state->event);
+ ipu_crtc->event = crtc->state->event;
crtc->state->event = NULL;
}
- spin_unlock_irq(>dev->event_lock);
}
static void ipu_crtc_mode_set_nofb(struct drm_crtc *crtc)
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/4] drm/imx: ipuv3-plane: add function to query atomic update status
This function allows upper layer to check if a requested atomic update
to the plane has been applied or is still pending.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/imx/ipuv3-plane.c | 20
drivers/gpu/drm/imx/ipuv3-plane.h | 2 ++
2 files changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.c
b/drivers/gpu/drm/imx/ipuv3-plane.c
index 203f247d4854..c95a2fc51741 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.c
+++ b/drivers/gpu/drm/imx/ipuv3-plane.c
@@ -587,6 +587,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
active = ipu_idmac_get_current_buffer(ipu_plane->ipu_ch);
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, !active, eba);
ipu_idmac_select_buffer(ipu_plane->ipu_ch, !active);
+ ipu_plane->next_buf = !active;
if (ipu_plane_separate_alpha(ipu_plane)) {
active =
ipu_idmac_get_current_buffer(ipu_plane->alpha_ch);
ipu_cpmem_set_buffer(ipu_plane->alpha_ch, !active,
@@ -713,6 +714,7 @@ static void ipu_plane_atomic_update(struct drm_plane *plane,
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 0, eba);
ipu_cpmem_set_buffer(ipu_plane->ipu_ch, 1, eba);
ipu_idmac_lock_enable(ipu_plane->ipu_ch, num_bursts);
+ ipu_plane->next_buf = -1;
ipu_plane_enable(ipu_plane);
}
@@ -723,6 +725,24 @@ static const struct drm_plane_helper_funcs
ipu_plane_helper_funcs = {
.atomic_update = ipu_plane_atomic_update,
};
+bool ipu_plane_atomic_update_done(struct drm_plane *plane)
+{
+ struct ipu_plane *ipu_plane = to_ipu_plane(plane);
+ struct drm_plane_state *state = plane->state;
+ struct ipu_plane_state *ipu_state = to_ipu_plane_state(state);
+
+ /* disabled crtcs must not block the update */
+ if (!state->crtc)
+ return true;
+
+ if (ipu_state->use_pre)
+ return ipu_prg_channel_configure_done(ipu_plane->ipu_ch);
+ else if (ipu_plane->next_buf >= 0)
+ return ipu_idmac_get_current_buffer(ipu_plane->ipu_ch) ==
+ ipu_plane->next_buf;
+
+ return true;
+}
int ipu_planes_assign_pre(struct drm_device *dev,
struct drm_atomic_state *state)
{
diff --git a/drivers/gpu/drm/imx/ipuv3-plane.h
b/drivers/gpu/drm/imx/ipuv3-plane.h
index e563ea17a827..60eb6776a34e 100644
--- a/drivers/gpu/drm/imx/ipuv3-plane.h
+++ b/drivers/gpu/drm/imx/ipuv3-plane.h
@@ -27,6 +27,7 @@ struct ipu_plane {
int dp_flow;
booldisabling;
+ int next_buf;
};
struct ipu_plane *ipu_plane_init(struct drm_device *dev, struct ipu_soc *ipu,
@@ -48,5 +49,6 @@ int ipu_plane_irq(struct ipu_plane *plane);
void ipu_plane_disable(struct ipu_plane *ipu_plane, bool disable_dp_channel);
void ipu_plane_disable_deferred(struct drm_plane *plane);
+bool ipu_plane_atomic_update_done(struct drm_plane *plane);
#endif
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] drm: Differentiate the lack of an interface from invalid parameter
Quoting Chris Wilson (2018-09-13 20:20:50) > If the ioctl is not supported on a particular piece of HW/driver > combination, report ENOTSUP (aka EOPNOTSUPP) so that it can be easily > distinguished from both the lack of the ioctl and from a regular invalid > parameter. > > v2: Across all the kms ioctls we had a mixture of reporting EINVAL, > ENODEV and a few ENOTSUPP (most where EINVAL) for a failed > drm_core_check_feature(). Update everybody to report ENOTSUPP. > > v3: ENOTSUPP is an internal errno! It's value (524) does not correspond > to a POSIX errno, the one we want is ENOTSUP. However, > uapi/asm-generic/errno.h doesn't include ENOTSUP but man errno says > > "ENOTSUP and EOPNOTSUPP have the same value on Linux, > but according to POSIX.1 these error values should be > distinct." > > so use EOPNOTSUPP as its equivalent. > > Signed-off-by: Chris Wilson > Cc: Daniel Vetter > Cc: Ville Syrjälä > Reviewed-by: Daniel Vetter #v2 And pushed to drm-misc-next, so hopefully the ENOTSUP/EOPNOTSUPP is all fine. Thanks for the review, -Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/2] drm: Add shmem GEM library
Den 14.09.2018 18.13, skrev Daniel Vetter: On Fri, Sep 14, 2018 at 5:48 PM, Thomas Hellstrom wrote: Hi, Noralf, On 09/11/2018 02:43 PM, Noralf Trønnes wrote: This patchset adds a library for shmem backed GEM objects and makes use of it in tinydrm. When I made tinydrm I used the CMA helper because it was very easy to use. July last year I learned that this limits which drivers to PRIME import from, since CMA requires continuous memory. tinydrm drivers don't require that. So I set out to change that looking first at shmem, but that wasn't working since shmem didn't work with fbdev deferred I/O. Then I did a vmalloc buffer attempt which worked with deferred I/O, but maybe wouldn't be of so much use as a library for other drivers to use. As my work to split out stuff from the CMA helper for shared use came to an end, I had a generic fbdev emulation that uses a shadow buffer for deferred I/O. This means that I can now use shmem buffers after all. I have looked at the other drivers that use drm_gem_get_pages() and several supports different cache modes so I've done that even though tinydrm only uses the cached one. Out if interest, how can you use writecombine and uncached with shared memory? as typically the linear kernel map of the affected pages also needs changing? I think on x86 at least the core code takes care of that. On arm, I'm not sure this just works, since you can't change the mode of the linear map. Instead you need specially allocated memory which is _not_ in the linear map. I guess arm boxes with pcie slots aren't that common yet :-) I was hoping to get some feedback on these cache mode flags. These drivers use them: udl/udl_gem.c omapdrm/omap_gem.c msm/msm_gem.c etnaviv/etnaviv_gem.c I don't know if they make sense or not, so any help is appreciated. Noralf. -Daniel Thanks, Thomas ___ 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
Re: [PATCH] [RFC]drm: add syncobj timeline support v5
Am 14.09.2018 um 18:10 schrieb Daniel Vetter:
On Fri, Sep 14, 2018 at 12:49:45PM +0200, Christian König wrote:
Am 14.09.2018 um 12:37 schrieb Chunming Zhou:
This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
syncobj in kernel side:
This extension introduces a new type of syncobj that has an integer payload
identifying a point in a timeline. Such timeline syncobjs support the
following operations:
* CPU query - A host operation that allows querying the payload of the
timeline syncobj.
* CPU wait - A host operation that allows a blocking wait for a
timeline syncobj to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline syncobj to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline syncobj to a specified value.
Since it's a timeline, that means the front time point(PT) always is signaled
before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when timeline is
increasing, will compare
wait PTs value with new timeline value, if PT value is lower than timeline
value, then wait PT will be
signaled, otherwise keep in list. syncobj wait operation can wait on any point
of timeline,
so need a RB tree to order them. And wait PT could ahead of signal PT, we need
a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate patch.
(Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate patch.
5. drop the submission_fence implementation and instead use wait_event() for
that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
v3:
1. replace normal syncobj with timeline implemenation. (Vetter and Christian)
a. normal syncobj signal op will create a signal PT to tail of signal pt
list.
b. normal syncobj wait op will create a wait pt with last signal point,
and this wait PT is only signaled by related signal point PT.
2. many bug fix and clean up
3. stub fence moving is moved to other patch.
v4：
1. fix RB tree loop with while(node=rb_first(...)). (Christian)
2. fix syncobj lifecycle. (Christian)
3. only enable_signaling when there is wait_pt. (Christian)
4. fix timeline path issues.
5. write a timeline test in libdrm
v5: (Christian)
1. semaphore is called syncobj in kernel side.
2. don't need 'timeline' characters in some function name.
3. keep syncobj cb
normal syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore*
timeline syncobj is tested by ./amdgpu_test -s 9
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
At least on first glance that looks like it should work, going to do a
detailed review on Monday.
Just for my understanding, it's all condensed down to 1 patch now? I kinda
didn't follow the detailed discussion last few days at all :-/
I've already committed all the cleanup/fix prerequisites to drm-misc-next.
The driver specific implementation needs to come on top and maybe a new
CPU wait IOCTL.
But essentially this patch is just the core of the kernel implementation.
Also, is there a testcase, igt highly preferred (because then we'll run it
in our intel-gfx CI, and a bunch of people outside of intel have already
discovered that and are using it).
libdrm patches and I think amdgpu based test cases where already
published as well.
Not sure about igt testcases.
Christian.
Thanks, Daniel
Christian.
---
drivers/gpu/drm/drm_syncobj.c | 294 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
include/drm/drm_syncobj.h | 62 +++--
include/uapi/drm/drm.h | 1 +
4 files changed, 292 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e9ce623d049e..e78d076f2703 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,9 @@either
#include "drm_internal.h"
#include
+/* merge normal syncobj to timeline syncobj, the point interval is 1 */
+#define DRM_SYNCOBJ_NORMAL_POINT 1
+
struct drm_syncobj_stub_fence {
struct dma_fence base;
spinlock_t lock;
@@ -82,6 +85,11 @@ static const struct dma_fence_ops drm_syncobj_stub_fence_ops
= {
.release = drm_syncobj_stub_fence_release,
};
+struct drm_syncobj_signal_pt {
+ struct dma_fence_array *base;
+ u64value;
+ struct list_head list;
+};
/**
* drm_syncobj_find - lookup and reference a sync object.
@@ -124,7 +132,7 @@ static int
Re: [PATCH v3 1/2] drm: Add library for shmem backed GEM objects
Den 14.09.2018 12.10, skrev Eric Engestrom:
On Wednesday, 2018-09-12 20:33:32 -0500, David Lechner wrote:
On 09/11/2018 07:43 AM, Noralf Trønnes wrote:
This adds a library for shmem backed GEM objects with the necessary
drm_driver callbacks.
Signed-off-by: Noralf Trønnes
---
...
+static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem)
+{
+ struct drm_gem_object *obj = >base;
+ int ret;
+
+ if (shmem->vmap_use_count++ > 0)
+ return 0;
+
+ ret = drm_gem_shmem_get_pages(shmem);
+ if (ret)
+ goto err_zero_use;
+
+ if (obj->import_attach) {
+ shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
+ } else {
+ pgprot_t prot;
+
+ switch (shmem->cache_mode) {
+ case DRM_GEM_SHMEM_BO_UNKNOWN:
+ DRM_DEBUG_KMS("Can't vmap cache mode is unknown\n");
+ ret = -EINVAL;
+ goto err_put_pages;
+
+ case DRM_GEM_SHMEM_BO_WRITECOMBINED:
+ prot = pgprot_writecombine(PAGE_KERNEL);
+ break;
+
+ case DRM_GEM_SHMEM_BO_UNCACHED:
+ prot = pgprot_noncached(PAGE_KERNEL);
+ break;
+
+ case DRM_GEM_SHMEM_BO_CACHED:
+ prot = PAGE_KERNEL;
+ break;
+ }
+
+ shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
VM_MAP, prot);
I get a gcc warning here:
/home/david/work/ev3dev2/ev3dev-kernel/drivers/gpu/drm/drm_gem_shmem_helper.c:220:18:
warning: ‘prot’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT, VM_MAP, prot);
^
/home/david/work/ev3dev2/ev3dev-kernel/drivers/gpu/drm/drm_gem_shmem_helper.c:199:12:
note: ‘prot’ was declared here
pgprot_t prot;
^~~~
This warning is saying that the vmap could be reached without hitting
any cases in the switch, which is technically true if one sets the
cache_mode to some garbage, but not if only existing enums from `enum
drm_gem_shmem_cache_mode` are used.
I think we should just add a `default:` next to the
DRM_GEM_SHMEM_BO_UNKNOWN case.
---
And since I am making a comment anyway, it is not clear to me
what BO means in the enum names. I didn't see any hints in the
doc comments either.
Buffer Object, but yeah I guess it's not necessary in the enum names.
Yeah, the helper was called drm_shem_bo_helper in an earlier version,
forgot to remove the BO from the enum.
Noralf.
+ }
+
+ if (!shmem->vaddr) {
+ DRM_DEBUG_KMS("Failed to vmap pages\n");
+ ret = -ENOMEM;
+ goto err_put_pages;
+ }
+
+ return 0;
+
+err_put_pages:
+ drm_gem_shmem_put_pages(shmem);
+err_zero_use:
+ shmem->vmap_use_count = 0;
+
+ return ret;
+}
___
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
Re: [PATCH 05/20] drm/meson: Use drm_fbdev_generic_setup()
Den 14.09.2018 10.23, skrev Neil Armstrong: Hi Daniel, On 13/09/2018 16:55, Daniel Vetter wrote: On Thu, Sep 13, 2018 at 04:26:53PM +0200, Neil Armstrong wrote: Hi Daniel, On 13/09/2018 15:21, Daniel Vetter wrote: On Wed, Sep 12, 2018 at 01:06:07PM +0200, Noralf Trønnes wrote: Den 12.09.2018 12.57, skrev Noralf Trønnes: (Cc: Daniel Vetter) Somehow that CC was dropped somewhere after leaving email client. Trying once more. Yeah I just made myself unpopular. If you want SMEM_START, then you need to carry a local patch now. virt_to_pfn on the vmap should work. It's about 2 lines, including the change to drop HIDE_SMEM_START. Would it be totally unacceptable to add such 2 line : - enabled by a specific config depending on EXPERT and narrowed to specific platforms - printing a big fat pr_warning_once when used - with a big fat comment specifying when this code will be dropped and why we should not activate it module_param_debug auto-taints your kernel, I'd just go with that. Plus CONFIG_EXPERT (or CONFIG_BROKEN). OK, I think you mean module_param_unsafe, but I see the point. But yes, I think that's something I'll happily ack. Must be acked by Dave (and perhaps a few others too), since defacto this means we now suddenly care about closed source blobs. I'd say get someone from amd and a few of the driver maintainers on board with this (nouveau, Eric, Rob, Lucas, ...), to make sure it really represents community consensus. I'll drop something, but I'm afraid a kernel won't have this hack, shouldn't this serie be delayed for a release ? It's not this series that drops smem_start support. It happened in commit 894a677f4b3e: drm/cma-helper: Use the generic fbdev emulation This series only deals with the fb_helper callbacks. @Noaralf, do you have a branch somewhere I can base a work on ? I haven't got a git repo, but you can apply the patches from patchwork: [01/20] drm/fb-helper: Improve error reporting in setup curl https://patchwork.freedesktop.org/patch/247860/mbox/ | git am [05/20] drm/meson: Use drm_fbdev_generic_setup() curl https://patchwork.freedesktop.org/patch/247868/mbox/ | git am Noralf. Neil Cheers, Daniel Neil And if consensus is that hiding SMEM_START is not a nice idea, then I'm sure we can reintroduce it through some slightly unpretty backdoor, even with Noralf's generic code. So not really a good reason to reject the cleanup I think. -Daniel Den 12.09.2018 11.56, skrev Maxime Ripard: On Wed, Sep 12, 2018 at 11:48:34AM +0200, Neil Armstrong wrote: Hi Noralf, On 08/09/2018 15:46, Noralf Trønnes wrote: The CMA helper is already using the drm_fb_helper_generic_probe part of the generic fbdev emulation. This patch makes full use of the generic fbdev emulation by using its drm_client callbacks. This means that drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are now handled by the emulation code. Additionally fbdev unregister happens automatically on drm_dev_unregister(). The drm_fbdev_generic_setup() call is put after drm_dev_register() in the driver. This is done to highlight the fact that fbdev emulation is an internal client that makes use of the driver, it is not part of the driver as such. If fbdev setup fails, an error is printed, but the driver succeeds probing. I can't really ack/nack this move, on one side it's great to have a generic fbdev emulation instead of the old fbdev code, but on the other side the Amlogic platform (like allwinner, samsung, rockchip, ...) still relies on an Fbdev variant of the libMali that uses smem_start... I know it's dirty and fbdev based code should be legacy now, but I consider it like an user-space breakage... I'll be happy if ARM provided it's Mali vendors a Fbdev libMali that could use FBINFO_HIDE_SMEM_START and allocate BO's from the DRM driver, it won't be the case and it will never be the case until the Lima projects finalizes. So for me it's a no-go until Lima lands upstream in Linux *and* Mesa. My feelings exactly. If the choice is between reducing the DRM driver by a couple of dozens of lines or keeping the mali working, I'll pick the latter, every single day. I don't know the reasoning for blocking smem_start other than what Daniel wrote in these commit messages: da6c7707caf3736c1cf968606bd97c07e79625d4 fbdev: Add FBINFO_HIDE_SMEM_START flag DRM drivers really, really, really don't want random userspace to share buffer behind it's back, bypassing the dma-buf buffer sharing machanism. For that reason we've ruthlessly rejected any IOCTL exposing the physical address of any graphics buffer. Unfortunately fbdev comes with that built-in. We could just set smem_start to 0, but that means we'd have to hand-roll our own fb_mmap implementation. For good reasons many drivers do that, but smem_start/length is still super convenient. Hence instead just stop the leak in the ioctl, to keep fb mmap working as-is. A second patch will set this flag for all drm
[Bug 105733] Amdgpu randomly hangs and only ssh works. Mouse cursor moves sometimes but does nothing. Keyboard stops working.
https://bugs.freedesktop.org/show_bug.cgi?id=105733 --- Comment #38 from Jan Jurzitza --- So the "manual" freq hack for me fixes games and graphics intensive applications (or at least delays it by more than 15 hours). There are still actual crashes (don't know if it's because of GPU or CPU) that occasionally occur with my setup which happen after simply browsing a lot, especially with lots of SVGs and images, but they used to happen before the manual hack as well and don't seem to be related to this issue. -- 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: Return -ENOTSUPP in drm_setclientcap() when driver do not support KMS
On Fri, 2018-09-14 at 09:15 +0100, Chris Wilson wrote:
> Quoting José Roberto de Souza (2018-09-13 23:13:41)
> > All DRM_CLIENT capabilities are tied to KMS support, so returning
> > -ENOTSUPP when KMS is not supported.
>
> The posix errno is ENOTSUP (ENOTSUPP is internal). Now since we have
> no
> ENOTSUP in the uapi, I've switched to using EOPNOTSUP as that is
> documented to have the same value as ENOTSUP under Linux. (At least
> until somebody decided to make ENOTSUP unique.)
Oh thanks, I have copied it from drm_getcap() and did not notice.
>
> > Cc: Chris Wilson
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/drm_ioctl.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_ioctl.c
> > b/drivers/gpu/drm/drm_ioctl.c
> > index 6b4a633b4240..842423fe9762 100644
> > --- a/drivers/gpu/drm/drm_ioctl.c
> > +++ b/drivers/gpu/drm/drm_ioctl.c
> > @@ -306,6 +306,9 @@ drm_setclientcap(struct drm_device *dev, void
> > *data, struct drm_file *file_priv)
> > {
> > struct drm_set_client_cap *req = data;
> >
> > + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> > + return -ENOTSUPP;
>
> The wider question though is client cap restricted to modesetting
> capabilities? Or should each case include a check like
> DRM_CLIENT_CAP_ATOMIC.
Well all of those:
DRM_CLIENT_CAP_STEREO_3D
DRM_CLIENT_CAP_UNIVERSAL_PLANES
DRM_CLIENT_CAP_ATOMIC
DRM_CLIENT_CAP_ASPECT_RATIO
DRM_CLIENT_CAP_WRITEBACK_CONNECTORS
are just usefull with KMS.
> -Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm v2 12/13] meson: make symbols hidden by default
Quoting Lucas De Marchi (2018-09-13 16:57:23)
> Now that symbols that should be exported are annotated accordingly, make
> all the rest hidden by default.
>
> Signed-off-by: Lucas De Marchi
> ---
> amdgpu/meson.build | 2 +-
> etnaviv/meson.build | 2 +-
> exynos/meson.build | 2 +-
> freedreno/meson.build | 2 +-
> intel/meson.build | 4 ++--
> libkms/meson.build | 2 +-
> meson.build | 5 -
> nouveau/meson.build | 2 +-
> omap/meson.build| 2 +-
> radeon/meson.build | 2 +-
> tegra/meson.build | 2 +-
> tests/exynos/meson.build| 6 +++---
> tests/kms/meson.build | 2 +-
> tests/kmstest/meson.build | 2 +-
> tests/meson.build | 8
> tests/modeprint/meson.build | 2 +-
> tests/modetest/meson.build | 2 +-
> tests/nouveau/meson.build | 2 +-
> tests/proptest/meson.build | 2 +-
> tests/radeon/meson.build| 2 +-
> tests/tegra/meson.build | 2 +-
> tests/vbltest/meson.build | 2 +-
> 22 files changed, 31 insertions(+), 28 deletions(-)
>
> diff --git a/amdgpu/meson.build b/amdgpu/meson.build
> index d9d7de2d..7c8ccc7e 100644
> --- a/amdgpu/meson.build
> +++ b/amdgpu/meson.build
> @@ -31,7 +31,7 @@ libdrm_amdgpu = shared_library(
> config_file,
>],
>c_args : [
> -warn_c_args,
> +libdrm_c_args,
> '-DAMDGPU_ASIC_ID_TABLE="@0@"'.format(join_paths(datadir_amdgpu,
> 'amdgpu.ids')),
>],
>include_directories : [inc_root, inc_drm],
> diff --git a/etnaviv/meson.build b/etnaviv/meson.build
> index ca2aa544..515a4ed0 100644
> --- a/etnaviv/meson.build
> +++ b/etnaviv/meson.build
> @@ -30,7 +30,7 @@ libdrm_etnaviv = shared_library(
>],
>include_directories : [inc_root, inc_drm],
>link_with : libdrm,
> - c_args : warn_c_args,
> + c_args : libdrm_c_args,
>dependencies : [dep_pthread_stubs, dep_rt, dep_atomic_ops],
>version : '1.0.0',
>install : true,
> diff --git a/exynos/meson.build b/exynos/meson.build
> index 30d36405..bdfc3fc6 100644
> --- a/exynos/meson.build
> +++ b/exynos/meson.build
> @@ -21,7 +21,7 @@
> libdrm_exynos = shared_library(
>'drm_exynos',
>[files('exynos_drm.c', 'exynos_fimg2d.c'), config_file],
> - c_args : warn_c_args,
> + c_args : libdrm_c_args,
>include_directories : [inc_root, inc_drm],
>link_with : libdrm,
>dependencies : [dep_pthread_stubs],
> diff --git a/freedreno/meson.build b/freedreno/meson.build
> index 015b7fb1..c9aba060 100644
> --- a/freedreno/meson.build
> +++ b/freedreno/meson.build
> @@ -42,7 +42,7 @@ endif
> libdrm_freedreno = shared_library(
>'drm_freedreno',
>[files_freedreno, config_file],
> - c_args : warn_c_args,
> + c_args : libdrm_c_args,
>include_directories : [inc_root, inc_drm],
>dependencies : [dep_valgrind, dep_pthread_stubs, dep_rt, dep_atomic_ops],
>link_with : libdrm,
> diff --git a/intel/meson.build b/intel/meson.build
> index ff40ab91..3d6bbac6 100644
> --- a/intel/meson.build
> +++ b/intel/meson.build
> @@ -30,7 +30,7 @@ libdrm_intel = shared_library(
>include_directories : [inc_root, inc_drm],
>link_with : libdrm,
>dependencies : [dep_pciaccess, dep_pthread_stubs, dep_rt, dep_valgrind,
> dep_atomic_ops],
> - c_args : warn_c_args,
> + c_args : libdrm_c_args,
>version : '1.0.0',
>install : true,
> )
> @@ -59,7 +59,7 @@ test_decode = executable(
>files('test_decode.c'),
>include_directories : [inc_root, inc_drm],
>link_with : [libdrm, libdrm_intel],
> - c_args : warn_c_args,
> + c_args : libdrm_c_args,
> )
>
> test(
> diff --git a/libkms/meson.build b/libkms/meson.build
> index 86d1a4ee..dc931608 100644
> --- a/libkms/meson.build
> +++ b/libkms/meson.build
> @@ -44,7 +44,7 @@ endif
> libkms = shared_library(
>'kms',
>[files_libkms, config_file],
> - c_args : warn_c_args,
> + c_args : libdrm_c_args,
>include_directories : libkms_include,
>link_with : libdrm,
>version : '1.0.0',
> diff --git a/meson.build b/meson.build
> index 75c7bdff..80d50188 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -211,6 +211,9 @@ foreach a : ['unused-parameter', 'attributes',
> 'long-long',
>endif
> endforeach
>
> +# all c args:
> +libdrm_c_args = warn_c_args + ['-fvisibility=hidden']
> +
>
> dep_pciaccess = dependency('pciaccess', version : '>= 0.10', required :
> with_intel)
> dep_cunit = dependency('cunit', version : '>= 2.1', required : false)
> @@ -286,7 +289,7 @@ libdrm = shared_library(
> ),
> config_file,
>],
> - c_args : warn_c_args,
> + c_args : libdrm_c_args,
>dependencies : [dep_valgrind, dep_rt, dep_m],
>include_directories : inc_drm,
>version : '2.4.0',
> diff --git a/nouveau/meson.build b/nouveau/meson.build
> index 51c9a712..0c1498d7 100644
> --- a/nouveau/meson.build
> +++ b/nouveau/meson.build
> @@ -22,7 +22,7 @@
> libdrm_nouveau = shared_library(
>'drm_nouveau',
>[files( 'nouveau.c', 'pushbuf.c',
Re: [PATCH] msm/gpu/a6xx: Force of_dma_configure to setup DMA for GMU
Tested-by: Sibi Sankar
On 2018-09-14 20:33, Jordan Crouse wrote:
The point of the 'force_dma' parameter for of_dma_configure
is to force the device to be set up even if DMA capability is
not described by the firmware which is exactly the use case
we have for GMU - we need SMMU to get set up but we have no
other dma capabilities since memory is managed by the GPU
driver. Currently we pass false so of_dma_configure() fails
and subsequently GMU and GPU probe does as well.
Fixes: 4b565ca5a2c ("drm/msm: Add A6XX device support")
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index bbb8126ec5c5..cbaca366fc20 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1140,7 +1140,7 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu,
struct device_node *node)
gmu->dev = >dev;
- of_dma_configure(gmu->dev, node, false);
+ of_dma_configure(gmu->dev, node, true);
/* Fow now, don't do anything fancy until we get our feet under us */
gmu->idle_level = GMU_IDLE_STATE_ACTIVE;
--
-- Sibi Sankar --
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 v3 0/2] drm: Add shmem GEM library
On Fri, Sep 14, 2018 at 5:48 PM, Thomas Hellstrom wrote: > Hi, Noralf, > > On 09/11/2018 02:43 PM, Noralf Trønnes wrote: >> >> This patchset adds a library for shmem backed GEM objects and makes use >> of it in tinydrm. >> >> When I made tinydrm I used the CMA helper because it was very easy to >> use. July last year I learned that this limits which drivers to PRIME >> import from, since CMA requires continuous memory. tinydrm drivers don't >> require that. So I set out to change that looking first at shmem, but >> that wasn't working since shmem didn't work with fbdev deferred I/O. >> Then I did a vmalloc buffer attempt which worked with deferred I/O, but >> maybe wouldn't be of so much use as a library for other drivers to use. >> As my work to split out stuff from the CMA helper for shared use came to >> an end, I had a generic fbdev emulation that uses a shadow buffer for >> deferred I/O. >> This means that I can now use shmem buffers after all. >> >> I have looked at the other drivers that use drm_gem_get_pages() and >> several supports different cache modes so I've done that even though >> tinydrm only uses the cached one. > > Out if interest, how can you use writecombine and uncached with shared > memory? > as typically the linear kernel map of the affected pages also needs > changing? I think on x86 at least the core code takes care of that. On arm, I'm not sure this just works, since you can't change the mode of the linear map. Instead you need specially allocated memory which is _not_ in the linear map. I guess arm boxes with pcie slots aren't that common yet :-) -Daniel > > Thanks, > Thomas > > > ___ > 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 02/10] phy: Add configuration interface
Hi Maxime, On Wednesday 12 September 2018 02:12 PM, Maxime Ripard wrote: > Hi! > > On Wed, Sep 12, 2018 at 01:12:31PM +0530, Kishon Vijay Abraham I wrote: >> On Thursday 06 September 2018 08:26 PM, Maxime Ripard wrote: >>> Hi Kishon, >>> >>> On Thu, Sep 06, 2018 at 02:57:58PM +0530, Kishon Vijay Abraham I wrote: On Wednesday 05 September 2018 02:46 PM, Maxime Ripard wrote: > The phy framework is only allowing to configure the power state of the PHY > using the init and power_on hooks, and their power_off and exit > counterparts. > > While it works for most, simple, PHYs supported so far, some more advanced > PHYs need some configuration depending on runtime parameters. These PHYs > have been supported by a number of means already, often by using ad-hoc > drivers in their consumer drivers. > > That doesn't work too well however, when a consumer device needs to deal > multiple PHYs, or when multiple consumers need to deal with the same PHY > (a > DSI driver and a CSI driver for example). > > So we'll add a new interface, through two funtions, phy_validate and > phy_configure. The first one will allow to check that a current > configuration, for a given mode, is applicable. It will also allow the PHY > driver to tune the settings given as parameters as it sees fit. > > phy_configure will actually apply that configuration in the phy itself. > > Signed-off-by: Maxime Ripard > --- > drivers/phy/phy-core.c | 62 ++- > include/linux/phy/phy.h | 42 - > 2 files changed, 104 insertions(+) > > diff --git a/drivers/phy/phy-core.c b/drivers/phy/phy-core.c > index 35fd38c5a4a1..6eaf655e370f 100644 > --- a/drivers/phy/phy-core.c > +++ b/drivers/phy/phy-core.c > @@ -408,6 +408,68 @@ int phy_calibrate(struct phy *phy) > EXPORT_SYMBOL_GPL(phy_calibrate); > > /** > + * phy_configure() - Changes the phy parameters > + * @phy: the phy returned by phy_get() > + * @mode: phy_mode the configuration is applicable to. mode should be used if the same PHY can be configured in multiple modes. But with phy_set_mode() and phy_calibrate() we could achieve the same. >>> >>> So you would change the prototype to have a configuration applying >>> only to the current mode set previously through set_mode? >> >> yeah. >> With phy_configure, if the PHY is not in @mode, it should return an error? Or >> will it set the PHY to @mode and apply the configuration in @opts? > > I wanted to have it return an error either if it was configured in > another mode or if the mode was unsupported yes. > >>> Can we have PHY that operate in multiple modes at the same time? >> >> Not at the same time. But the same PHY can operate in multiple modes (For >> example we have PHYs that can be used either with PCIe or USB3) > > Ok, that makes sense. I guess we could rely on phy_set_mode then if > you prefer. > > + * @opts: New configuration to apply Should these configuration come from the consumer driver? >>> >>> Yes >> >> How does the consumer driver get these configurations? Is it from user space >> or >> dt associated with consumer device. > > It really depends on multiple factors (and I guess on what mode the > PHY is actually supposed to support), but in the case covered by this > serie, the info mostly come from multiple places: > - The resolutions supported by the panel > - The resolutions supported by the phy consumer (and its > integration, for things like the clock rates it can output) > - The resolutions and timings supported by the phy itself (once > again, the integration is mostly involved here since it really > only depends on which clock rates can be achieved) > - The timings boundaries that the specification has > - The resolution selected by the user > > So we'd have that information coming from multiple places: the > userspace would select the resolution, drivers would be able to filter > out unsupported resolutions, and the DT will provide the integration > details to help them do so. > > But I guess from an API standpoint, it really is expected to be > assembled by the phy consumer driver. > > +/** > + * phy_validate() - Checks the phy parameters > + * @phy: the phy returned by phy_get() > + * @mode: phy_mode the configuration is applicable to. > + * @opts: Configuration to check > + * > + * Used to check that the current set of parameters can be handled by > + * the phy. Implementations are free to tune the parameters passed as > + * arguments if needed by some implementation detail or > + * constraints. It will not change any actual configuration of the > + * PHY, so calling it as many times as deemed fit will have no side > + * effect. > + * > + * Returns: 0 if successful, an negative error
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed, Sep 12, 2018 at 05:08:52PM +0200, Arnd Bergmann wrote: > The .ioctl and .compat_ioctl file operations have the same prototype so > they can both point to the same function, which works great almost all > the time when all the commands are compatible. > > One exception is the s390 architecture, where a compat pointer is only > 31 bit wide, and converting it into a 64-bit pointer requires calling > compat_ptr(). Most drivers here will ever run in s390, but since we now > have a generic helper for it, it's easy enough to use it consistently. > > I double-checked all these drivers to ensure that all ioctl arguments > are used as pointers or are ignored, but are not interpreted as integer > values. > > Signed-off-by: Arnd Bergmann > --- > fs/btrfs/super.c| 2 +- Acked-by: David Sterba ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC]drm: add syncobj timeline support v5
On Fri, Sep 14, 2018 at 12:49:45PM +0200, Christian König wrote:
> Am 14.09.2018 um 12:37 schrieb Chunming Zhou:
> > This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
> > syncobj in kernel side:
> > This extension introduces a new type of syncobj that has an integer payload
> > identifying a point in a timeline. Such timeline syncobjs support the
> > following operations:
> > * CPU query - A host operation that allows querying the payload of the
> > timeline syncobj.
> > * CPU wait - A host operation that allows a blocking wait for a
> > timeline syncobj to reach a specified value.
> > * Device wait - A device operation that allows waiting for a
> > timeline syncobj to reach a specified value.
> > * Device signal - A device operation that allows advancing the
> > timeline syncobj to a specified value.
> >
> > Since it's a timeline, that means the front time point(PT) always is
> > signaled before the late PT.
> > a. signal PT design:
> > Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
> > PT[N] fence is signaled,
> > the timeline will increase to value of PT[N].
> > b. wait PT design:
> > Wait PT fence is signaled by reaching timeline point value, when timeline
> > is increasing, will compare
> > wait PTs value with new timeline value, if PT value is lower than timeline
> > value, then wait PT will be
> > signaled, otherwise keep in list. syncobj wait operation can wait on any
> > point of timeline,
> > so need a RB tree to order them. And wait PT could ahead of signal PT, we
> > need a sumission fence to
> > perform that.
> >
> > v2:
> > 1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
> > 2. move unexposed denitions to .c file. (Daniel Vetter)
> > 3. split up the change to drm_syncobj_find_fence() in a separate patch.
> > (Christian)
> > 4. split up the change to drm_syncobj_replace_fence() in a separate patch.
> > 5. drop the submission_fence implementation and instead use wait_event()
> > for that. (Christian)
> > 6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
> >
> > v3:
> > 1. replace normal syncobj with timeline implemenation. (Vetter and
> > Christian)
> > a. normal syncobj signal op will create a signal PT to tail of signal
> > pt list.
> > b. normal syncobj wait op will create a wait pt with last signal
> > point, and this wait PT is only signaled by related signal point PT.
> > 2. many bug fix and clean up
> > 3. stub fence moving is moved to other patch.
> >
> > v4：
> > 1. fix RB tree loop with while(node=rb_first(...)). (Christian)
> > 2. fix syncobj lifecycle. (Christian)
> > 3. only enable_signaling when there is wait_pt. (Christian)
> > 4. fix timeline path issues.
> > 5. write a timeline test in libdrm
> >
> > v5: (Christian)
> > 1. semaphore is called syncobj in kernel side.
> > 2. don't need 'timeline' characters in some function name.
> > 3. keep syncobj cb
> >
> > normal syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore*
> > timeline syncobj is tested by ./amdgpu_test -s 9
> >
> > Signed-off-by: Chunming Zhou
> > Cc: Christian Konig
> > Cc: Dave Airlie
> > Cc: Daniel Rakos
> > Cc: Daniel Vetter
>
> At least on first glance that looks like it should work, going to do a
> detailed review on Monday.
Just for my understanding, it's all condensed down to 1 patch now? I kinda
didn't follow the detailed discussion last few days at all :-/
Also, is there a testcase, igt highly preferred (because then we'll run it
in our intel-gfx CI, and a bunch of people outside of intel have already
discovered that and are using it).
Thanks, Daniel
>
> Christian.
>
> > ---
> > drivers/gpu/drm/drm_syncobj.c | 294 ++---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
> > include/drm/drm_syncobj.h | 62 +++--
> > include/uapi/drm/drm.h | 1 +
> > 4 files changed, 292 insertions(+), 69 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
> > index e9ce623d049e..e78d076f2703 100644
> > --- a/drivers/gpu/drm/drm_syncobj.c
> > +++ b/drivers/gpu/drm/drm_syncobj.c
> > @@ -56,6 +56,9 @@either
> > #include "drm_internal.h"
> > #include
> > +/* merge normal syncobj to timeline syncobj, the point interval is 1 */
> > +#define DRM_SYNCOBJ_NORMAL_POINT 1
> > +
> > struct drm_syncobj_stub_fence {
> > struct dma_fence base;
> > spinlock_t lock;
> > @@ -82,6 +85,11 @@ static const struct dma_fence_ops
> > drm_syncobj_stub_fence_ops = {
> > .release = drm_syncobj_stub_fence_release,
> > };
> > +struct drm_syncobj_signal_pt {
> > + struct dma_fence_array *base;
> > + u64value;
> > + struct list_head list;
> > +};
> > /**
> >* drm_syncobj_find - lookup and reference a sync object.
> > @@ -124,7 +132,7 @@ static int drm_syncobj_fence_get_or_add_callback(struct
> > drm_syncobj *syncobj,
> > {
> >
Re: [PATCH -fixes] drm/vmwgfx: Fix buffer object eviction
On 09/14/2018 09:45 AM, Christian König wrote:
Am 14.09.2018 um 09:35 schrieb Thomas Hellstrom:
Commit 19be55701071 ("drm/ttm: add operation ctx to ttm_bo_validate v2")
introduced a regression where the vmwgfx driver refused to evict a
buffer that was still busy instead of waiting for it to become idle.
Fix this.
Cc: Christian König
Signed-off-by: Thomas Hellstrom
Ups, sorry for that. Patch is Reviewed-by: Christian König
Thanks!
/Thomas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 0/2] drm: Add shmem GEM library
Hi, Noralf, On 09/11/2018 02:43 PM, Noralf Trønnes wrote: This patchset adds a library for shmem backed GEM objects and makes use of it in tinydrm. When I made tinydrm I used the CMA helper because it was very easy to use. July last year I learned that this limits which drivers to PRIME import from, since CMA requires continuous memory. tinydrm drivers don't require that. So I set out to change that looking first at shmem, but that wasn't working since shmem didn't work with fbdev deferred I/O. Then I did a vmalloc buffer attempt which worked with deferred I/O, but maybe wouldn't be of so much use as a library for other drivers to use. As my work to split out stuff from the CMA helper for shared use came to an end, I had a generic fbdev emulation that uses a shadow buffer for deferred I/O. This means that I can now use shmem buffers after all. I have looked at the other drivers that use drm_gem_get_pages() and several supports different cache modes so I've done that even though tinydrm only uses the cached one. Out if interest, how can you use writecombine and uncached with shared memory? as typically the linear kernel map of the affected pages also needs changing? Thanks, Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] amdgpu/kfd, radeon, ttm, scheduler drm-next-4.20
Hi Dave, First pull for 4.20 for amdgpu/kfd, radeon, ttm, and the GPU scheduler. amdgpu/kfd: - Picasso (new APU) support - Raven2 (new APU) support - Vega20 enablement - ACP powergating improvements - Add ABGR/XBGR display support - VCN JPEG engine support - Initial xGMI support - Use load balancing for engine scheduling - Lots of new documentation - Rework and clean up i2c and aux handling in DC - Add DP YCbCr 4:2:0 support in DC - Add DMCU firmware loading for Raven (used for ABM and PSR) - New debugfs features in DC - LVDS support in DC - Implement wave kill for gfx/compute (light weight reset for shaders) - Use AGP aperture to avoid gart mappings when possible - GPUVM performance improvements - Bulk moves for more efficient GPUVM LRU handling - Merge amdgpu and amdkfd into one module - Enable gfxoff and stutter mode on Raven - Misc cleanups Scheduler: - Load balancing support - Bug fixes ttm: - Bulk move functionality - Bug fixes radeon: - Misc cleanups The following changes since commit 5b394b2ddf0347bef56e50c69a58773c94343ff3: Linux 4.19-rc1 (2018-08-26 14:11:59 -0700) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.20 for you to fetch changes up to 0957dc7097a3f462f6cedb45cf9b9785cc29e5bb: drm/amdgpu: revert "stop using gart_start as offset for the GTT domain" (2018-09-14 10:05:42 -0500) Alex Deucher (22): drm/amdgpu/pp: endian fixes for process_pptables_v1_0.c drm/amdgpu/pp: endian fixes for processpptables.c drm/amdgpu/powerplay: check vrefresh when when changing displays drm/amdgpu: add AVFS control to PP_FEATURE_MASK drm/amdgpu/powerplay/smu7: enable AVFS control via ppfeaturemask drm/amdgpu/powerplay/vega10: enable AVFS control via ppfeaturemask Revert "drm/amdgpu: Add nbio support for vega20 (v2)" drm/amdgpu: remove experimental flag for vega20 drm/amdgpu/display: add support for LVDS (v5) drm/amdgpu: add missing CHIP_HAINAN in amdgpu_ucode_get_load_type drm/amdgpu/gmc9: rework stolen vga memory handling drm/amdgpu/gmc9: don't keep stolen memory on Raven drm/amdgpu/gmc9: don't keep stolen memory on vega12 drm/amdgpu/gmc9: don't keep stolen memory on vega20 drm/amdgpu/gmc: add initial xgmi structure to amdgpu_gmc structure drm/amdgpu/gmc9: add a new gfxhub 1.1 helper for xgmi drm/amdgpu/gmc9: Adjust GART and AGP location with xgmi offset (v2) drm/amdgpu: use IP presence to free uvd and vce handles drm/amdgpu: set external rev id for raven2 drm/amdgpu/soc15: clean up picasso support drm/amdgpu: simplify Raven, Raven2, and Picasso handling drm/amdgpu/display: return proper error codes in dm Alvin lee (2): drm/amd/display: Enable Stereo in Dal3 drm/amd/display: Program vsc_infopacket in commit_planes_for_stream Amber Lin (4): drm/amdgpu: Merge amdkfd into amdgpu drm/amdgpu: Remove CONFIG_HSA_AMD_MODULE drm/amdgpu: Move KFD parameters to amdgpu (v3) drm/amdgpu: Relocate some definitions v2 Andrey Grodzovsky (8): drm/amdgpu: Fix page fault and kasan warning on pci device remove. drm/scheduler: Add job dependency trace. drm/amdgpu: Add job pipe sync dependecy trace drm/scheduler: Add stopped flag to drm_sched_entity drm/amdgpu: Refine gmc9 VM fault print. drm/amdgpu: Use drm_dev_unplug in PCI .remove drm/amdgpu: Fix SDMA TO after GPU reset v3 drm/amd/display: Fix pflip IRQ status after gpu reset. Anthony Koo (10): drm/amd/display: Refactor FreeSync module drm/amd/display: add method to check for supported range drm/amd/display: Fix bug where refresh rate becomes fixed drm/amd/display: Fix bug that causes black screen drm/amd/display: Add back code to allow for rounding error drm/amd/display: fix LFC tearing at top of screen drm/amd/display: refactor vupdate interrupt registration drm/amd/display: Correct rounding calcs in mod_freesync_is_valid_range drm/amd/display: add config for sending VSIF drm/amd/display: move edp fast boot optimization flag to stream Bhawanpreet Lakha (3): drm/amd/display: Build stream update and plane updates in dm drm/amd/display: Add Raven2 definitions in dc drm/amd/display: Add DC config flag for Raven2 (v2) Boyuan Zhang (6): drm/amdgpu: add emit reg write reg wait for vcn jpeg drm/amdgpu: add system interrupt register offset header drm/amdgpu: add system interrupt mask for jrbc drm/amdgpu: enable system interrupt for jrbc drm/amdgpu: add emit trap for vcn jpeg drm/amdgpu: fix emit frame size and comments for jpeg Charlene Liu (2): drm/amd/display: pass compat_level to hubp drm/amd/display: add retimer log for HWQ tuning use. Chiawen Huang (2): drm/amd/display: add aux transition event log.
[Bug 107939] Commit 888b7fc causes performance regression
https://bugs.freedesktop.org/show_bug.cgi?id=107939 Michel Dänzer changed: What|Removed |Added Component|Drivers/Gallium/radeonsi|Drivers/Vulkan/radeon Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- 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 107939] Commit 888b7fc causes performance regression
https://bugs.freedesktop.org/show_bug.cgi?id=107939 Bug ID: 107939 Summary: Commit 888b7fc causes performance regression Product: Mesa Version: 18.1 Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: da...@lunarg.com QA Contact: dri-devel@lists.freedesktop.org Our Vulkan regression test suite includes a Vulkan trace of the Sasha Willems shadowmapping demo. We found that the fps when playing back that trace file had decreased by about 20%. I narrowed down the performance drop to commit 888b7fc. I duplicated the performance drop with the demo itself. Without commit 888b7fc, the demo runs at an average of 3125 fps. With commit 888b7fc, it runs at 2675 fps. This is a performance regression of about 14%. I ran this on a system with an Intel i5-6600K CPU @ 3.50GHz and an AMD Radeon RX470 graphics card. -- 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 6/6] drm/msm/a6xx: Add a6xx gpu state
Add support for gathering and dumping the a6xx GPU state including
registers, GMU registers, indexed registers, shader blocks,
context clusters and debugbus.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/Makefile|1 +
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 25 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h |3 +
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 39 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.h |6 +
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 1159 +++
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 430 +++
7 files changed, 1625 insertions(+), 38 deletions(-)
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
diff --git a/drivers/gpu/drm/msm/Makefile b/drivers/gpu/drm/msm/Makefile
index 19ab521d4c3a..33645c6539ee 100644
--- a/drivers/gpu/drm/msm/Makefile
+++ b/drivers/gpu/drm/msm/Makefile
@@ -14,6 +14,7 @@ msm-y := \
adreno/a6xx_gpu.o \
adreno/a6xx_gmu.o \
adreno/a6xx_hfi.o \
+ adreno/a6xx_gpu_state.o \
hdmi/hdmi.o \
hdmi/hdmi_audio.o \
hdmi/hdmi_bridge.o \
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index d04b63ea8cd9..ad2a887ce700 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -55,10 +55,31 @@ static irqreturn_t a6xx_hfi_irq(int irq, void *data)
return IRQ_HANDLED;
}
+bool a6xx_gmu_sptprac_is_on(struct a6xx_gmu *gmu)
+{
+ u32 val;
+
+ /* This can be called from gpu state code so make sure GMU is valid */
+ if (IS_ERR_OR_NULL(gmu->mmio))
+ return false;
+
+ val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
+
+ return !(val &
+ (A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SPTPRAC_GDSC_POWER_OFF |
+ A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_SP_CLOCK_OFF));
+}
+
/* Check to see if the GX rail is still powered */
-static bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
+bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu)
{
- u32 val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
+ u32 val;
+
+ /* This can be called from gpu state code so make sure GMU is valid */
+ if (IS_ERR_OR_NULL(gmu->mmio))
+ return false;
+
+ val = gmu_read(gmu, REG_A6XX_GMU_SPTPRAC_PWR_CLK_STATUS);
return !(val &
(A6XX_GMU_SPTPRAC_PWR_CLK_STATUS_GX_HM_GDSC_POWER_OFF |
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
index 09d97e4ed293..9683e65b0783 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.h
@@ -153,4 +153,7 @@ void a6xx_hfi_stop(struct a6xx_gmu *gmu);
void a6xx_hfi_task(unsigned long data);
+bool a6xx_gmu_gx_is_on(struct a6xx_gmu *gmu);
+bool a6xx_gmu_sptprac_is_on(struct a6xx_gmu *gmu);
+
#endif
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 9a14cb3d5027..69700806ee9f 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -645,33 +645,6 @@ static const u32
a6xx_register_offsets[REG_ADRENO_REGISTER_MAX] = {
REG_ADRENO_DEFINE(REG_ADRENO_CP_RB_CNTL, REG_A6XX_CP_RB_CNTL),
};
-static const u32 a6xx_registers[] = {
- 0x, 0x0002, 0x0010, 0x0010, 0x0012, 0x0012, 0x0018, 0x001b,
- 0x001e, 0x0032, 0x0038, 0x003c, 0x0042, 0x0042, 0x0044, 0x0044,
- 0x0047, 0x0047, 0x0056, 0x0056, 0x00ad, 0x00ae, 0x00b0, 0x00fb,
- 0x0100, 0x011d, 0x0200, 0x020d, 0x0210, 0x0213, 0x0218, 0x023d,
- 0x0400, 0x04f9, 0x0500, 0x0500, 0x0505, 0x050b, 0x050e, 0x0511,
- 0x0533, 0x0533, 0x0540, 0x0555, 0x0800, 0x0808, 0x0810, 0x0813,
- 0x0820, 0x0821, 0x0823, 0x0827, 0x0830, 0x0833, 0x0840, 0x0843,
- 0x084f, 0x086f, 0x0880, 0x088a, 0x08a0, 0x08ab, 0x08c0, 0x08c4,
- 0x08d0, 0x08dd, 0x08f0, 0x08f3, 0x0900, 0x0903, 0x0908, 0x0911,
- 0x0928, 0x093e, 0x0942, 0x094d, 0x0980, 0x0984, 0x098d, 0x0996,
- 0x0998, 0x099e, 0x09a0, 0x09a6, 0x09a8, 0x09ae, 0x09b0, 0x09b1,
- 0x09c2, 0x09c8, 0x0a00, 0x0a03, 0x0c00, 0x0c04, 0x0c06, 0x0c06,
- 0x0c10, 0x0cd9, 0x0e00, 0x0e0e, 0x0e10, 0x0e13, 0x0e17, 0x0e19,
- 0x0e1c, 0x0e2b, 0x0e30, 0x0e32, 0x0e38, 0x0e39, 0x8600, 0x8601,
- 0x8610, 0x861b, 0x8620, 0x8620, 0x8628, 0x862b, 0x8630, 0x8637,
- 0x8e01, 0x8e01, 0x8e04, 0x8e05, 0x8e07, 0x8e08, 0x8e0c, 0x8e0c,
- 0x8e10, 0x8e1c, 0x8e20, 0x8e25, 0x8e28, 0x8e28, 0x8e2c, 0x8e2f,
- 0x8e3b, 0x8e3e, 0x8e40, 0x8e43, 0x8e50, 0x8e5e, 0x8e70, 0x8e77,
- 0x9600, 0x9604, 0x9624, 0x9637, 0x9e00, 0x9e01, 0x9e03, 0x9e0e,
- 0x9e11, 0x9e16, 0x9e19, 0x9e19, 0x9e1c, 0x9e1c, 0x9e20, 0x9e23,
- 0x9e30, 0x9e31, 0x9e34, 0x9e34, 0x9e70, 0x9e72, 0x9e78, 0x9e79,
- 0x9e80, 0x9fff, 0xa600, 0xa601, 0xa603, 0xa603, 0xa60a, 0xa60a,
- 0xa610, 0xa617,
[PATCH 4/6] drm/msm/gpu: Move gpu_poll_timeout() to adreno_gpu.h
The gpu_poll_timeout() function can be useful to multiple targets so
mvoe it into adreno_gpu.h from the a5xx code.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 5 -
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 6 ++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index ab1d9308c311..937f470da609 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -20,7 +20,6 @@
#include
#include
#include
-#include
#include
#include "msm_gem.h"
#include "msm_mmu.h"
@@ -1211,10 +1210,6 @@ struct a5xx_gpu_state {
u32 *hlsqregs;
};
-#define gpu_poll_timeout(gpu, addr, val, cond, interval, timeout) \
- readl_poll_timeout((gpu)->mmio + ((addr) << 2), val, cond, \
- interval, timeout)
-
static int a5xx_crashdumper_init(struct msm_gpu *gpu,
struct a5xx_crashdumper *dumper)
{
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
index de6e6ee42fba..7e5f1120ce7a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
@@ -21,6 +21,7 @@
#define __ADRENO_GPU_H__
#include
+#include
#include "msm_gpu.h"
@@ -375,4 +376,9 @@ static inline uint32_t get_wptr(struct msm_ringbuffer *ring)
((1 << 29) \
((ilog2((_len)) & 0x1F) << 24) | (((_reg) << 2) & 0xF))
+
+#define gpu_poll_timeout(gpu, addr, val, cond, interval, timeout) \
+ readl_poll_timeout((gpu)->mmio + ((addr) << 2), val, cond, \
+ interval, timeout)
+
#endif /* __ADRENO_GPU_H__ */
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/6] drm/msm/a6xx: Fix PDC register overlap
The current design greedily takes a big chunk of the PDC
register space instead of just the GPU specific sections
which conflicts with other drivers and generally makes
a mess of things.
Furthermore we only need to map the GPU PDC sections
just once during init so map the memory inside the function
that uses it.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 87 ---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 6 --
2 files changed, 51 insertions(+), 42 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index cbaca366fc20..d04b63ea8cd9 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -348,8 +348,23 @@ static void a6xx_rpmh_stop(struct a6xx_gmu *gmu)
gmu_write(gmu, REG_A6XX_GMU_RSCC_CONTROL_REQ, 0);
}
+static inline void pdc_write(void __iomem *ptr, u32 offset, u32 value)
+{
+ return msm_writel(value, ptr + (offset << 2));
+}
+
+static void __iomem *a6xx_gmu_get_mmio(struct platform_device *pdev,
+ const char *name);
+
static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
{
+ struct platform_device *pdev = to_platform_device(gmu->dev);
+ void __iomem *pdcptr = a6xx_gmu_get_mmio(pdev, "gmu_pdc");
+ void __iomem *seqptr = a6xx_gmu_get_mmio(pdev, "gmu_pdc_seq");
+
+ if (!pdcptr || !seqptr)
+ goto err;
+
/* Disable SDE clock gating */
gmu_write(gmu, REG_A6XX_GPU_RSCC_RSC_STATUS0_DRV0, BIT(24));
@@ -374,44 +389,48 @@ static void a6xx_gmu_rpmh_init(struct a6xx_gmu *gmu)
gmu_write(gmu, REG_A6XX_RSCC_SEQ_MEM_0_DRV0 + 4, 0x0020e8a8);
/* Load PDC sequencer uCode for power up and power down sequence */
- pdc_write(gmu, REG_A6XX_PDC_GPU_SEQ_MEM_0, 0xfebea1e1);
- pdc_write(gmu, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 1, 0xa5a4a3a2);
- pdc_write(gmu, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 2, 0x8382a6e0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 3, 0xbce3e284);
- pdc_write(gmu, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 4, 0x002081fc);
+ pdc_write(seqptr, REG_A6XX_PDC_GPU_SEQ_MEM_0, 0xfebea1e1);
+ pdc_write(seqptr, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 1, 0xa5a4a3a2);
+ pdc_write(seqptr, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 2, 0x8382a6e0);
+ pdc_write(seqptr, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 3, 0xbce3e284);
+ pdc_write(seqptr, REG_A6XX_PDC_GPU_SEQ_MEM_0 + 4, 0x002081fc);
/* Set TCS commands used by PDC sequence for low power modes */
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD_ENABLE_BANK, 7);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD_WAIT_FOR_CMPL_BANK, 0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CONTROL, 0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR, 0x30010);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA, 1);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID + 4, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR + 4, 0x3);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA + 4, 0x0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID + 8, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR + 8, 0x30080);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA + 8, 0x0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD_ENABLE_BANK, 7);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD_WAIT_FOR_CMPL_BANK, 0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CONTROL, 0);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR, 0x30010);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA, 2);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID + 4, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR + 4, 0x3);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA + 4, 0x3);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_MSGID + 8, 0x10108);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_ADDR + 8, 0x30080);
- pdc_write(gmu, REG_A6XX_PDC_GPU_TCS3_CMD0_DATA + 8, 0x3);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD_ENABLE_BANK, 7);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD_WAIT_FOR_CMPL_BANK, 0);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CONTROL, 0);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID, 0x10108);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR, 0x30010);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA, 1);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID + 4, 0x10108);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR + 4, 0x3);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA + 4, 0x0);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_MSGID + 8, 0x10108);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_ADDR + 8, 0x30080);
+ pdc_write(pdcptr, REG_A6XX_PDC_GPU_TCS1_CMD0_DATA + 8, 0x0);
+
[PATCH 1/6] drm/msm/a6xx: rnndb updates for a6xx
Update the register definitions for a6xx from the rnndb database.
Changes include new enums for upcoming devcoredump support, moving
the PDC and GCC_GX register definitions to their own domain and
various other register updates and additions.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx.xml.h | 642 ++
drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 26 +-
2 files changed, 416 insertions(+), 252 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
index 87eab51f7000..7acc57b2c1be 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx.xml.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx.xml.h
@@ -8,17 +8,17 @@ This file was generated by the rules-ng-ng headergen tool in
this git repository
git clone https://github.com/freedreno/envytools.git
The rules-ng-ng source files this header was generated from are:
-- /home/robclark/src/envytools/rnndb/adreno.xml (501 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/freedreno_copyright.xml ( 1572 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a2xx.xml ( 36805 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_common.xml ( 13634 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/adreno_pm4.xml( 42393 bytes,
from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a3xx.xml ( 83840 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a4xx.xml ( 112086 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/a5xx.xml ( 147240 bytes,
from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx.xml ( 101627 bytes,
from 2018-08-06 18:45:45)
-- /home/robclark/src/envytools/rnndb/adreno/a6xx_gmu.xml ( 10431 bytes,
from 2018-07-03 19:37:13)
-- /home/robclark/src/envytools/rnndb/adreno/ocmem.xml ( 1773 bytes,
from 2018-07-03 19:37:13)
+- ./adreno.xml (501 bytes, from 2018-05-23 16:51:57)
+- ./freedreno_copyright.xml ( 1572 bytes, from 2016-10-24 21:12:27)
+- ./adreno/a2xx.xml ( 36805 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_common.xml ( 13634 bytes, from 2018-05-23 16:51:57)
+- ./adreno/adreno_pm4.xml( 42393 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a3xx.xml ( 83840 bytes, from 2017-12-05 18:20:27)
+- ./adreno/a4xx.xml ( 112086 bytes, from 2018-05-23 16:51:57)
+- ./adreno/a5xx.xml ( 147240 bytes, from 2018-08-16 16:56:14)
+- ./adreno/a6xx.xml ( 107521 bytes, from 2018-08-16 17:44:50)
+- ./adreno/a6xx_gmu.xml ( 10431 bytes, from 2018-08-16 17:44:26)
+- ./adreno/ocmem.xml ( 1773 bytes, from 2016-10-24 21:12:27)
Copyright (C) 2013-2018 by the following authors:
- Rob Clark (robclark)
@@ -272,6 +272,98 @@ enum a6xx_cp_perfcounter_select {
PERF_CP_ALWAYS_COUNT = 0,
};
+enum a6xx_shader_id {
+ A6XX_TP0_TMO_DATA = 9,
+ A6XX_TP0_SMO_DATA = 10,
+ A6XX_TP0_MIPMAP_BASE_DATA = 11,
+ A6XX_TP1_TMO_DATA = 25,
+ A6XX_TP1_SMO_DATA = 26,
+ A6XX_TP1_MIPMAP_BASE_DATA = 27,
+ A6XX_SP_INST_DATA = 41,
+ A6XX_SP_LB_0_DATA = 42,
+ A6XX_SP_LB_1_DATA = 43,
+ A6XX_SP_LB_2_DATA = 44,
+ A6XX_SP_LB_3_DATA = 45,
+ A6XX_SP_LB_4_DATA = 46,
+ A6XX_SP_LB_5_DATA = 47,
+ A6XX_SP_CB_BINDLESS_DATA = 48,
+ A6XX_SP_CB_LEGACY_DATA = 49,
+ A6XX_SP_UAV_DATA = 50,
+ A6XX_SP_INST_TAG = 51,
+ A6XX_SP_CB_BINDLESS_TAG = 52,
+ A6XX_SP_TMO_UMO_TAG = 53,
+ A6XX_SP_SMO_TAG = 54,
+ A6XX_SP_STATE_DATA = 55,
+ A6XX_HLSQ_CHUNK_CVS_RAM = 73,
+ A6XX_HLSQ_CHUNK_CPS_RAM = 74,
+ A6XX_HLSQ_CHUNK_CVS_RAM_TAG = 75,
+ A6XX_HLSQ_CHUNK_CPS_RAM_TAG = 76,
+ A6XX_HLSQ_ICB_CVS_CB_BASE_TAG = 77,
+ A6XX_HLSQ_ICB_CPS_CB_BASE_TAG = 78,
+ A6XX_HLSQ_CVS_MISC_RAM = 80,
+ A6XX_HLSQ_CPS_MISC_RAM = 81,
+ A6XX_HLSQ_INST_RAM = 82,
+ A6XX_HLSQ_GFX_CVS_CONST_RAM = 83,
+ A6XX_HLSQ_GFX_CPS_CONST_RAM = 84,
+ A6XX_HLSQ_CVS_MISC_RAM_TAG = 85,
+ A6XX_HLSQ_CPS_MISC_RAM_TAG = 86,
+ A6XX_HLSQ_INST_RAM_TAG = 87,
+ A6XX_HLSQ_GFX_CVS_CONST_RAM_TAG = 88,
+ A6XX_HLSQ_GFX_CPS_CONST_RAM_TAG = 89,
+ A6XX_HLSQ_PWR_REST_RAM = 90,
+ A6XX_HLSQ_PWR_REST_TAG = 91,
+ A6XX_HLSQ_DATAPATH_META = 96,
+ A6XX_HLSQ_FRONTEND_META = 97,
+ A6XX_HLSQ_INDIRECT_META = 98,
+ A6XX_HLSQ_BACKEND_META = 99,
+};
+
+enum a6xx_debugbus_id {
+ A6XX_DBGBUS_CP = 1,
+ A6XX_DBGBUS_RBBM = 2,
+ A6XX_DBGBUS_VBIF = 3,
+ A6XX_DBGBUS_HLSQ = 4,
+ A6XX_DBGBUS_UCHE = 5,
+ A6XX_DBGBUS_DPM = 6,
+ A6XX_DBGBUS_TESS = 7,
+ A6XX_DBGBUS_PC = 8,
+ A6XX_DBGBUS_VFDP = 9,
+ A6XX_DBGBUS_VPC = 10,
+ A6XX_DBGBUS_TSE = 11,
+
[PATCH 3/6] drm/msm/a6xx: Rename gmu phandle to qcom,gmu
From the review for the DT bindings for the GPU/GMU it was suggested that the phandle for the GMU be 'qcom,gmu' instead of just 'gmu' but that never actually got changed in the code. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c index c629f742a1d1..9a14cb3d5027 100644 --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c @@ -799,7 +799,7 @@ struct msm_gpu *a6xx_gpu_init(struct drm_device *dev) } /* Check if there is a GMU phandle and set it up */ - node = of_parse_phandle(pdev->dev.of_node, "gmu", 0); + node = of_parse_phandle(pdev->dev.of_node, "qcom,gmu", 0); /* FIXME: How do we gracefully handle this? */ BUG_ON(!node); -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/6] Add a6xx GPU state capture
This stack adds support for capturing the A6xx GPU state. The A6xx GPU state is comprehensive including registers for the GPU and the GMU, shader caches, context clusters and debugbus state. It isn't as straightforward to capture the state as with previous targets. Some of the state is located behind apertures and other registers have special access rules so the complete state is defined by a hodgepodge of lists and structs which makes the code appear way more complex than it is. Jordan Crouse (6): drm/msm/a6xx: rnndb updates for a6xx drm/msm/a6xx: Fix PDC register overlap drm/msm/a6xx: Rename gmu phandle to qcom,gmu drm/msm/gpu: Move gpu_poll_timeout() to adreno_gpu.h drm/msm/adreno: Don't capture registers if target doesn't need them drm/msm/a6xx: Add a6xx gpu state drivers/gpu/drm/msm/Makefile|1 + drivers/gpu/drm/msm/adreno/a5xx_gpu.c |5 - drivers/gpu/drm/msm/adreno/a6xx.xml.h | 642 ++ drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 112 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.h |9 +- drivers/gpu/drm/msm/adreno/a6xx_gmu.xml.h | 26 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 41 +- drivers/gpu/drm/msm/adreno/a6xx_gpu.h |6 + drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 1159 +++ drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 430 +++ drivers/gpu/drm/msm/adreno/adreno_gpu.c | 19 +- drivers/gpu/drm/msm/adreno/adreno_gpu.h |6 + 12 files changed, 2113 insertions(+), 343 deletions(-) create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c create mode 100644 drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h -- 2.18.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/6] drm/msm/adreno: Don't capture registers if target doesn't need them
If the GPU target doesn't define a list of registers then gracefully skip
capturing and/or printing them. This is used by more complex targets like
6xx that have other means of capturing register values.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index da1363a0c54d..bb8cd21b46d0 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
@@ -414,6 +414,10 @@ int adreno_gpu_state_get(struct msm_gpu *gpu, struct
msm_gpu_state *state)
}
}
+ /* Some targets prefer to collect their own registers */
+ if (!adreno_gpu->registers)
+ return 0;
+
/* Count the number of registers */
for (i = 0; adreno_gpu->registers[i] != ~0; i += 2)
count += adreno_gpu->registers[i + 1] -
@@ -551,12 +555,14 @@ void adreno_show(struct msm_gpu *gpu, struct
msm_gpu_state *state,
}
}
- drm_puts(p, "registers:\n");
+ if (state->nr_registers) {
+ drm_puts(p, "registers:\n");
- for (i = 0; i < state->nr_registers; i++) {
- drm_printf(p, " - { offset: 0x%04x, value: 0x%08x }\n",
- state->registers[i * 2] << 2,
- state->registers[(i * 2) + 1]);
+ for (i = 0; i < state->nr_registers; i++) {
+ drm_printf(p, " - { offset: 0x%04x, value: 0x%08x }\n",
+ state->registers[i * 2] << 2,
+ state->registers[(i * 2) + 1]);
+ }
}
}
#endif
@@ -595,6 +601,9 @@ void adreno_dump(struct msm_gpu *gpu)
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
int i;
+ if (!adreno_gpu->registers)
+ return;
+
/* dump these out in a form that can be parsed by demsm: */
printk("IO:region %s 0002\n", gpu->name);
for (i = 0; adreno_gpu->registers[i] != ~0; i += 2) {
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107213] [amdgpu/DisplayPort] KDE Wayland session is segfaulting right after login
https://bugs.freedesktop.org/show_bug.cgi?id=107213 --- Comment #18 from Shmerl --- Corresponding wayland-client bug: https://gitlab.freedesktop.org/wayland/wayland/issues/56 -- 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 1/2] drm/nouveau: Disable atomic support on a per-device basis
On Thu, Sep 13, 2018 at 05:02:05PM -0400, Lyude Paul wrote: > Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends on > the driver supporting atomic, maybe it would be good to make it so that we set > DRIVER_ATOMIC in the driver_stub structure, then disable it per-device > depending > on the nouveau_atomic setting + hw support. That way we can always have the > state debugfs file while maintaining nouveau's current behavior with exposing > atomic ioctls. Assuming that wouldn't have any unintended side-effects of > course I'm not sure why there are three driver structs in nouveau. Maybe someone can just nuke two of them? > > On Thu, 2018-09-13 at 19:31 +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We now have per-device driver_features, so let's use that > > to disable atomic only for pre-nv50. > > > > Cc: Ben Skeggs > > Cc: Lyude Paul > > Cc: nouv...@lists.freedesktop.org > > Cc: Daniel Vetter > > Reviewed-by: Daniel Vetter > > Suggested-by: Daniel Vetter > > Signed-off-by: Ville Syrjälä > > --- > > drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c > > b/drivers/gpu/drm/nouveau/dispnv04/disp.c > > index 70dce544984e..670535a68d3b 100644 > > --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c > > +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c > > @@ -56,7 +56,7 @@ nv04_display_create(struct drm_device *dev) > > nouveau_display(dev)->fini = nv04_display_fini; > > > > /* Pre-nv50 doesn't support atomic, so don't expose the ioctls */ > > - dev->driver->driver_features &= ~DRIVER_ATOMIC; > > + dev->driver_features &= ~DRIVER_ATOMIC; > > > > nouveau_hw_save_vga_fonts(dev, 1); > > -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] msm/gpu/a6xx: Force of_dma_configure to setup DMA for GMU
The point of the 'force_dma' parameter for of_dma_configure
is to force the device to be set up even if DMA capability is
not described by the firmware which is exactly the use case
we have for GMU - we need SMMU to get set up but we have no
other dma capabilities since memory is managed by the GPU
driver. Currently we pass false so of_dma_configure() fails
and subsequently GMU and GPU probe does as well.
Fixes: 4b565ca5a2c ("drm/msm: Add A6XX device support")
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
index bbb8126ec5c5..cbaca366fc20 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
@@ -1140,7 +1140,7 @@ int a6xx_gmu_probe(struct a6xx_gpu *a6xx_gpu, struct
device_node *node)
gmu->dev = >dev;
- of_dma_configure(gmu->dev, node, false);
+ of_dma_configure(gmu->dev, node, true);
/* Fow now, don't do anything fancy until we get our feet under us */
gmu->idle_level = GMU_IDLE_STATE_ACTIVE;
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support
On Fri, Sep 14, 2018 at 02:49:09PM +, Lisovskiy, Stanislav wrote: > On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote: > > Hi, > > > > > -Original Message- > > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On > > > Behalf > > > Of Lisovskiy, Stanislav > > > Sent: perjantai 14. syyskuuta 2018 17.31 > > > To: ville.syrj...@linux.intel.com > > > Cc: intel-...@lists.freedesktop.org; Syrjala, Ville > > intel.com>; > > > Heikkila, Juha-pekka ; dri- > > > de...@lists.freedesktop.org; Peres, Martin > > > Subject: Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support > > > > > > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote: > > > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav > > > > wrote: > > > > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote: > > > > > > Introduced new XYUV scan-in format for framebuffer and added > > > > > > support for it to i915(SkyLake+). > > > > > > > > > > > > Stanislav Lisovskiy (2): > > > > > > drm: Introduce new DRM_FORMAT_XYUV > > > > > > drm/i915: Adding YUV444 packed format support for skl+ > > > > > > > > > > > > drivers/gpu/drm/drm_fourcc.c | 1 + > > > > > > drivers/gpu/drm/i915/i915_reg.h | 2 +- > > > > > > drivers/gpu/drm/i915/intel_display.c | 15 +++ > > > > > > drivers/gpu/drm/i915/intel_sprite.c | 2 ++ > > > > > > include/uapi/drm/drm_fourcc.h| 1 + > > > > > > 5 files changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > > > > > > > Ping. There is an IGT patch which got Reviewed-by Ville. > > > > > This one left in order to get XYUV support. > > > > > > > > Did we figure out userspace for this? > > > > > > > > Was the conflict solved with the other guy (forgot who it is) > > > > trying > > > > to add the same format with a different name? > > > > > > Currently for userspace we have VLC(checked with Juha-Pekka) and > > > also IGT > > > test case. > > > > > > I think those guys were from ARM and they were adding also support > > > for > > > XYUV. The only difference was that they called XYUV, like XYUV > > > something. > > > Our patches were otherwise identical regarding drm_fourcc.c part, I > > > don't > > > see their stuff merged, but I guess it really shouldn't matter, who > > > does this > > > first. i915 specific part doesn't conflict with their stuff. To be > > > honest, I forgot > > > the guy's name neither could find his email in my mailbox. > > > So hopefully somebody shows up here. > > > > Stan: > > Alexandru-Cosmin Gheorghe ? > > > > Exactly, found now. Thanks for the hint! Yes, that's me. Not a real conflict here, as long as your patches are ready to be merged feel free to do it and I will just rebase my series on top of that. > > > > > > > > > > > > > > -- > > > Best Regards, > > > > > > Lisovskiy Stanislav > > > ___ > > > Intel-gfx mailing list > > > intel-...@lists.freedesktop.org > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > -- > Best Regards, > > Lisovskiy Stanislav > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Cheers, Alex G ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107929] High memory clock speed issue on R9 380
https://bugs.freedesktop.org/show_bug.cgi?id=107929 --- Comment #2 from Alex Deucher --- On windows it's only supported if both monitors have the same timing and the vblank periods line up. I'm not sure what's missing to enable this on Linux. Harry? Leo? -- 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 107929] High memory clock speed issue on R9 380
https://bugs.freedesktop.org/show_bug.cgi?id=107929 Alex Deucher changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Alex Deucher --- We don't currently support mclk switching with multiple monitors in Linux. -- 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 v10 0/2] Add XYUV format support
On Fri, 2018-09-14 at 15:34 +0100, Saarinen, Jani wrote: > Hi, > > > -Original Message- > > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On > > Behalf > > Of Lisovskiy, Stanislav > > Sent: perjantai 14. syyskuuta 2018 17.31 > > To: ville.syrj...@linux.intel.com > > Cc: intel-...@lists.freedesktop.org; Syrjala, Ville > intel.com>; > > Heikkila, Juha-pekka ; dri- > > de...@lists.freedesktop.org; Peres, Martin > > Subject: Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support > > > > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote: > > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav > > > wrote: > > > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote: > > > > > Introduced new XYUV scan-in format for framebuffer and added > > > > > support for it to i915(SkyLake+). > > > > > > > > > > Stanislav Lisovskiy (2): > > > > > drm: Introduce new DRM_FORMAT_XYUV > > > > > drm/i915: Adding YUV444 packed format support for skl+ > > > > > > > > > > drivers/gpu/drm/drm_fourcc.c | 1 + > > > > > drivers/gpu/drm/i915/i915_reg.h | 2 +- > > > > > drivers/gpu/drm/i915/intel_display.c | 15 +++ > > > > > drivers/gpu/drm/i915/intel_sprite.c | 2 ++ > > > > > include/uapi/drm/drm_fourcc.h| 1 + > > > > > 5 files changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > > > > Ping. There is an IGT patch which got Reviewed-by Ville. > > > > This one left in order to get XYUV support. > > > > > > Did we figure out userspace for this? > > > > > > Was the conflict solved with the other guy (forgot who it is) > > > trying > > > to add the same format with a different name? > > > > Currently for userspace we have VLC(checked with Juha-Pekka) and > > also IGT > > test case. > > > > I think those guys were from ARM and they were adding also support > > for > > XYUV. The only difference was that they called XYUV, like XYUV > > something. > > Our patches were otherwise identical regarding drm_fourcc.c part, I > > don't > > see their stuff merged, but I guess it really shouldn't matter, who > > does this > > first. i915 specific part doesn't conflict with their stuff. To be > > honest, I forgot > > the guy's name neither could find his email in my mailbox. > > So hopefully somebody shows up here. > > Stan: > Alexandru-Cosmin Gheorghe ? > Exactly, found now. Thanks for the hint! > > > > > > > > > -- > > Best Regards, > > > > Lisovskiy Stanislav > > ___ > > Intel-gfx mailing list > > intel-...@lists.freedesktop.org > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Best Regards, Lisovskiy Stanislav ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: add DMA configuration for etnaviv platform device
Hi Lucas,
On Fri, 2018-09-14 at 11:24 +0200, Lucas Stach wrote:
> The etnaviv device is a virtual device backing the DRM device, which may
> drive multiple hardware GPU core devies. As most of the dma-mapping handling
> is done through the virtual device, we need to make sure that a proper DMA
> setup is in place. The easiest way to get a reasonable configuration is
> to let the virtual device share the DMA configuration with one of the GPU
> devices, so call of_dma_configure() with the right parameters manually.
>
> This assumes that all etnaviv driven GPU devices in the system share the
> same DMA configuration. If we ever encounter a SoC where the GPUs are on
> busses with different offsets or behind different IOMMUs that will require
> much deeper changes to the driver, as we would need to implement etnaviv
> specific versions of most of the DRM helper functions.
>
> For now we should be fine with this solution.
This works fine on HSDK, thanks!
Tested-By: Eugeniy Paltsev
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 27 +--
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index 9b2720b41571..83c1f46670bf 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -592,8 +592,6 @@ static int etnaviv_pdev_probe(struct platform_device
> *pdev)
> struct device *dev = >dev;
> struct component_match *match = NULL;
>
> - dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
> -
> if (!dev->platform_data) {
> struct device_node *core_node;
>
> @@ -655,13 +653,30 @@ static int __init etnaviv_init(void)
> for_each_compatible_node(np, NULL, "vivante,gc") {
> if (!of_device_is_available(np))
> continue;
> - pdev = platform_device_register_simple("etnaviv", -1,
> -NULL, 0);
> - if (IS_ERR(pdev)) {
> - ret = PTR_ERR(pdev);
> +
> + pdev = platform_device_alloc("etnaviv", -1);
> + if (!pdev) {
> + ret = -ENOMEM;
> + of_node_put(np);
> + goto unregister_platform_driver;
> + }
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(40);
> + pdev->dev.dma_mask = >dev.coherent_dma_mask;
> +
> + /*
> + * Apply the same DMA configuration to the virtual etnaviv
> + * device as the GPU we found. This assumes that all Vivante
> + * GPUs in the system share the same DMA constraints.
> + */
> + of_dma_configure(>dev, np, true);
> +
> + ret = platform_device_add(pdev);
> + if (ret) {
> + platform_device_put(pdev);
> of_node_put(np);
> goto unregister_platform_driver;
> }
> +
> etnaviv_drm = pdev;
> of_node_put(np);
> break;
--
Eugeniy Paltsev
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107213] [amdgpu/DisplayPort] KDE Wayland session is segfaulting right after login
https://bugs.freedesktop.org/show_bug.cgi?id=107213 --- Comment #17 from Shmerl --- Thanks. I already reported it for KWin (linked above): https://bugs.kde.org/show_bug.cgi?id=396066 I'll open libwayland bug too. -- 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 v10 0/2] Add XYUV format support
Hi, > -Original Message- > From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Lisovskiy, Stanislav > Sent: perjantai 14. syyskuuta 2018 17.31 > To: ville.syrj...@linux.intel.com > Cc: intel-...@lists.freedesktop.org; Syrjala, Ville ; > Heikkila, Juha-pekka ; dri- > de...@lists.freedesktop.org; Peres, Martin > Subject: Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support > > On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote: > > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav wrote: > > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote: > > > > Introduced new XYUV scan-in format for framebuffer and added > > > > support for it to i915(SkyLake+). > > > > > > > > Stanislav Lisovskiy (2): > > > > drm: Introduce new DRM_FORMAT_XYUV > > > > drm/i915: Adding YUV444 packed format support for skl+ > > > > > > > > drivers/gpu/drm/drm_fourcc.c | 1 + > > > > drivers/gpu/drm/i915/i915_reg.h | 2 +- > > > > drivers/gpu/drm/i915/intel_display.c | 15 +++ > > > > drivers/gpu/drm/i915/intel_sprite.c | 2 ++ > > > > include/uapi/drm/drm_fourcc.h| 1 + > > > > 5 files changed, 20 insertions(+), 1 deletion(-) > > > > > > > > > > Ping. There is an IGT patch which got Reviewed-by Ville. > > > This one left in order to get XYUV support. > > > > Did we figure out userspace for this? > > > > Was the conflict solved with the other guy (forgot who it is) trying > > to add the same format with a different name? > > Currently for userspace we have VLC(checked with Juha-Pekka) and also IGT > test case. > > I think those guys were from ARM and they were adding also support for > XYUV. The only difference was that they called XYUV, like XYUV > something. > Our patches were otherwise identical regarding drm_fourcc.c part, I don't > see their stuff merged, but I guess it really shouldn't matter, who does this > first. i915 specific part doesn't conflict with their stuff. To be honest, I > forgot > the guy's name neither could find his email in my mailbox. > So hopefully somebody shows up here. Stan: Alexandru-Cosmin Gheorghe ? > > > > -- > Best Regards, > > Lisovskiy Stanislav > ___ > Intel-gfx mailing list > intel-...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support
On Fri, 2018-09-14 at 16:47 +0300, Ville Syrjälä wrote: > On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav wrote: > > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote: > > > Introduced new XYUV scan-in format for framebuffer and > > > added support for it to i915(SkyLake+). > > > > > > Stanislav Lisovskiy (2): > > > drm: Introduce new DRM_FORMAT_XYUV > > > drm/i915: Adding YUV444 packed format support for skl+ > > > > > > drivers/gpu/drm/drm_fourcc.c | 1 + > > > drivers/gpu/drm/i915/i915_reg.h | 2 +- > > > drivers/gpu/drm/i915/intel_display.c | 15 +++ > > > drivers/gpu/drm/i915/intel_sprite.c | 2 ++ > > > include/uapi/drm/drm_fourcc.h| 1 + > > > 5 files changed, 20 insertions(+), 1 deletion(-) > > > > > > > Ping. There is an IGT patch which got Reviewed-by Ville. > > This one left in order to get XYUV support. > > Did we figure out userspace for this? > > Was the conflict solved with the other guy (forgot who it is) > trying to add the same format with a different name? Currently for userspace we have VLC(checked with Juha-Pekka) and also IGT test case. I think those guys were from ARM and they were adding also support for XYUV. The only difference was that they called XYUV, like XYUV something. Our patches were otherwise identical regarding drm_fourcc.c part, I don't see their stuff merged, but I guess it really shouldn't matter, who does this first. i915 specific part doesn't conflict with their stuff. To be honest, I forgot the guy's name neither could find his email in my mailbox. So hopefully somebody shows up here. > -- Best Regards, Lisovskiy Stanislav ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107213] [amdgpu/DisplayPort] KDE Wayland session is segfaulting right after login
https://bugs.freedesktop.org/show_bug.cgi?id=107213 --- Comment #16 from Michel Dänzer --- kwin crashes in libwayland code. You should probably report this to libwayland (uses Gitlab issues now) and/or kwin. -- 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: [v7] Add udmabuf misc device
On 09/14/2018 03:00 PM, Gerd Hoffmann wrote: On Fri, Sep 14, 2018 at 02:00:30PM +0200, Tomeu Vizoso wrote: On 09/14/2018 08:37 AM, Gerd Hoffmann wrote: Hi, Well, no. This is *not* about 3D, it's about software rendering, for example cairo doing its work for gtk apps. So the workflow would be along these lines: (1) guest app allocates dumb drm buffer from virtio-gpu, renders to it. Why not let clients keep allocating memory for buffers with memfd? The guest proxy would then create a virtio-gpu resource to wrap the shm pool memory. Should be workable too, with udmabuf in the guest. Allocate with memfd, turn into dmabuf using udmabuf, let the virtio-gpu guest driver import the thing so you have a virtio-gpu resource handle for it. I don't see why this is better than using virtio-gpu dumb buffers directly though. Because wl_shm clients are allocating memory with memfd already, so they would need to be modified so they allocate dumb buffers instead. In practice, that means only modifying gtk, qt and sdl. Cheers, Tomeu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Remove packed VYUY support
Hi Kieran,
On Friday, 14 September 2018 16:55:38 EEST Kieran Bingham wrote:
> On 14/09/18 14:51, Laurent Pinchart wrote:
> > On Friday, 14 September 2018 16:21:49 EEST Kieran Bingham wrote:
> >> The Gen3 VSP used by the DU for display does not support packed the VYUY
> >> pixel format. Gen2 VSP hardware is able to process this format, but it
> >> is not officially supported there either and thus it's output can not be
> >> guaranteed.
> >
> > I think we could guarantee proper operation on Gen2, but as DU + VSP
> > operation isn't enabled in the drivers by default, and as the VYUY format
> > isn't a strategic target, I think we can ignore that.
> >
> > How about updating the commit message as follows ?
> >
> > "The Gen3 VSP used by the DU for display does not support packed the VYUY
>
> s/packed the/the packed/
>
> Which was a fault in my original text :)
>
> > pixel format. Gen2 VSP hardware is able to process this format, but DU +
> > VSP operation isn't enabled on Gen2, and VYUY isn't a strategic format,
> > so it can be ignored."
>
> That sounds fine to me, though I don't think we would even need to state
> that 'VYUY isn't a strategic format' once it's simply not available on
> the only platform that is enabled to use the VSP. But I don't object to
> stating it otherwise.
It could be enabled in the drivers (I have out-of-tree patches for testing
purpose), so the fact that we don't need the format is still important I
think.
> >> Remove the format from the capabilities of the DU driver.
> >>
> >> Signed-off-by: Kieran Bingham
> >
> > Reviewed-by: Laurent Pinchart
> >
> >> ---
> >>
> >> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 --
> >> 1 file changed, 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 4480243813ec..4576119e
> >> 100644
> >> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> >> @@ -126,7 +126,6 @@ static const u32 formats_kms[] = {
> >>DRM_FORMAT_ARGB,
> >>DRM_FORMAT_XRGB,
> >>DRM_FORMAT_UYVY,
> >> - DRM_FORMAT_VYUY,
> >>DRM_FORMAT_YUYV,
> >>DRM_FORMAT_YVYU,
> >>DRM_FORMAT_NV12,
> >> @@ -155,7 +154,6 @@ static const u32 formats_v4l2[] = {
> >>V4L2_PIX_FMT_ABGR32,
> >>V4L2_PIX_FMT_XBGR32,
> >>V4L2_PIX_FMT_UYVY,
> >> - V4L2_PIX_FMT_VYUY,
> >>V4L2_PIX_FMT_YUYV,
> >>V4L2_PIX_FMT_YVYU,
> >>V4L2_PIX_FMT_NV12M,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/4] drm: rcar-du: Update to SoC manual revision 1.00
Hi Laurent, On Thu, Aug 23, 2018 at 05:12:10PM +0200, Jacopo Mondi wrote: > Hello Laurent, >Revision 1.00 has brought several updates on how to handle some registers > in the DU. In particular > > - ESCR cannot be written for channels with a DPLL > - OTAR cannot be written for channels without a digital output pad > - routing superimposition processor output to pincontrollers through DORCR2 > register cannot be performed for channels of group 1 > - The plane super-imposition register PnMR can be written to groups with more > than 1 channel. > > Patches applied on top of your latest drm/du/next branch. Could you please consider including this series in your tree? Thanks j > > Tested on Salvator-X M3-W with VGA and HDMI output. > Tested on Salvator-XS M3-N with VGA and HDMI output. > No visible regression, but if you have ideas on how to better verify this > please let me know. > > Thanks >j > > Jacopo Mondi (4): > drm: rcar-du: Do not write ESCR for DPLL channels > drm: rcar-du: Write OTAR for DPAD channels only > drm: rcar-du: Fix handling of DORCR for group 1 > drm: rcar-du: Fix handling of PnMR register > > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 18 +++--- > drivers/gpu/drm/rcar-du/rcar_du_group.c | 19 --- > drivers/gpu/drm/rcar-du/rcar_du_plane.c | 13 +++-- > 3 files changed, 38 insertions(+), 12 deletions(-) > > -- > 2.7.4 > signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: rcar-du: Rework clock configuration based on hardware limits
Hi Laurent,
On Mon, Jul 30, 2018 at 07:20:12PM +0200, Jacopo Mondi wrote:
> From: Laurent Pinchart
>
> The DU channels that have a display PLL (DPLL) can only use external
> clock sources, and don't have an internal clock divider (with the
> exception of H3 ES1.x where the post-divider is present and needs to be
> used as a workaround for a DPLL silicon issue).
>
> Rework the clock configuration to take this into account, avoiding
> selection of non-existing clock sources or usage of a missing
> post-divider.
>
I have based my work on non-DPLL channel selection on this patch, but
always forgot to add my:
Reviewed-by: Jacopo Mondi
Thanks
j
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 122
> ++---
> 1 file changed, 67 insertions(+), 55 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> index b52b3e8..6d55cec 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> @@ -208,78 +208,90 @@ static void rcar_du_crtc_set_display_timing(struct
> rcar_du_crtc *rcrtc)
> const struct drm_display_mode *mode = >crtc.state->adjusted_mode;
> struct rcar_du_device *rcdu = rcrtc->group->dev;
> unsigned long mode_clock = mode->clock * 1000;
> - unsigned long clk;
> u32 value;
> u32 escr;
> - u32 div;
>
> - /*
> - * Compute the clock divisor and select the internal or external dot
> - * clock based on the requested frequency.
> - */
> - clk = clk_get_rate(rcrtc->clock);
> - div = DIV_ROUND_CLOSEST(clk, mode_clock);
> - div = clamp(div, 1U, 64U) - 1;
> - escr = div | ESCR_DCLKSEL_CLKS;
> -
> - if (rcrtc->extclock) {
> + if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
> + unsigned long target = mode_clock;
> struct dpll_info dpll = { 0 };
> unsigned long extclk;
> - unsigned long extrate;
> - unsigned long rate;
> - u32 extdiv;
> + u32 dpllcr;
> + u32 div = 0;
>
> - extclk = clk_get_rate(rcrtc->extclock);
> - if (rcdu->info->dpll_ch & (1 << rcrtc->index)) {
> - unsigned long target = mode_clock;
> + /*
> + * DU channels that have a display PLL can't use the internal
> + * system clock, and have no internal clock divider.
> + */
>
> - /*
> - * The H3 ES1.x exhibits dot clock duty cycle stability
> - * issues. We can work around them by configuring the
> - * DPLL to twice the desired frequency, coupled with a
> - * /2 post-divider. This isn't needed on other SoCs and
> - * breaks HDMI output on M3-W for a currently unknown
> - * reason, so restrict the workaround to H3 ES1.x.
> - */
> - if (soc_device_match(rcar_du_r8a7795_es1))
> - target *= 2;
> + if (WARN_ON(!rcrtc->extclock))
> + return;
>
> - rcar_du_dpll_divider(rcrtc, , extclk, target);
> - extclk = dpll.output;
> + /*
> + * The H3 ES1.x exhibits dot clock duty cycle stability issues.
> + * We can work around them by configuring the DPLL to twice the
> + * desired frequency, coupled with a /2 post-divider. Restrict
> + * the workaround to H3 ES1.x as ES2.0 and all other SoCs have
> + * no post-divider when a display PLL is present (as shown by
> + * the workaround breaking HDMI output on M3-W during testing).
> + */
> + if (soc_device_match(rcar_du_r8a7795_es1)) {
> + target *= 2;
> + div = 1;
> }
>
> - extdiv = DIV_ROUND_CLOSEST(extclk, mode_clock);
> - extdiv = clamp(extdiv, 1U, 64U) - 1;
> + extclk = clk_get_rate(rcrtc->extclock);
> + rcar_du_dpll_divider(rcrtc, , extclk, target);
>
> - rate = clk / (div + 1);
> - extrate = extclk / (extdiv + 1);
> + dpllcr = DPLLCR_CODE | DPLLCR_CLKE
> +| DPLLCR_FDPLL(dpll.fdpll)
> +| DPLLCR_N(dpll.n) | DPLLCR_M(dpll.m)
> +| DPLLCR_STBY;
>
> - if (abs((long)extrate - (long)mode_clock) <
> - abs((long)rate - (long)mode_clock)) {
> + if (rcrtc->index == 1)
> + dpllcr |= DPLLCR_PLCS1
> +| DPLLCR_INCS_DOTCLKIN1;
> + else
> + dpllcr |= DPLLCR_PLCS0
> +| DPLLCR_INCS_DOTCLKIN0;
>
> - if (rcdu->info->dpll_ch & (1 << rcrtc->index))
Re: [PATCH] drm: rcar-du: Remove packed VYUY support
Hi Laurent,
On 14/09/18 14:51, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Friday, 14 September 2018 16:21:49 EEST Kieran Bingham wrote:
>> The Gen3 VSP used by the DU for display does not support packed the VYUY
>> pixel format. Gen2 VSP hardware is able to process this format, but it
>> is not officially supported there either and thus it's output can not be
>> guaranteed.
>
> I think we could guarantee proper operation on Gen2, but as DU + VSP
> operation
> isn't enabled in the drivers by default, and as the VYUY format isn't a
> strategic target, I think we can ignore that.
>
> How about updating the commit message as follows ?
>
> "The Gen3 VSP used by the DU for display does not support packed the VYUY
s/packed the/the packed/
Which was a fault in my original text :)
> pixel format. Gen2 VSP hardware is able to process this format, but DU + VSP
> operation isn't enabled on Gen2, and VYUY isn't a strategic format, so it can
> be ignored."
That sounds fine to me, though I don't think we would even need to state
that 'VYUY isn't a strategic format' once it's simply not available on
the only platform that is enabled to use the VSP. But I don't object to
stating it otherwise.
--
Kieran
>
>> Remove the format from the capabilities of the DU driver.
>>
>> Signed-off-by: Kieran Bingham
>
> Reviewed-by: Laurent Pinchart
>
>> ---
>> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 --
>> 1 file changed, 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 4480243813ec..4576119e
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
>> @@ -126,7 +126,6 @@ static const u32 formats_kms[] = {
>> DRM_FORMAT_ARGB,
>> DRM_FORMAT_XRGB,
>> DRM_FORMAT_UYVY,
>> -DRM_FORMAT_VYUY,
>> DRM_FORMAT_YUYV,
>> DRM_FORMAT_YVYU,
>> DRM_FORMAT_NV12,
>> @@ -155,7 +154,6 @@ static const u32 formats_v4l2[] = {
>> V4L2_PIX_FMT_ABGR32,
>> V4L2_PIX_FMT_XBGR32,
>> V4L2_PIX_FMT_UYVY,
>> -V4L2_PIX_FMT_VYUY,
>> V4L2_PIX_FMT_YUYV,
>> V4L2_PIX_FMT_YVYU,
>> V4L2_PIX_FMT_NV12M,
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: rcar-du: Remove packed VYUY support
Hi Kieran,
Thank you for the patch.
On Friday, 14 September 2018 16:21:49 EEST Kieran Bingham wrote:
> The Gen3 VSP used by the DU for display does not support packed the VYUY
> pixel format. Gen2 VSP hardware is able to process this format, but it
> is not officially supported there either and thus it's output can not be
> guaranteed.
I think we could guarantee proper operation on Gen2, but as DU + VSP operation
isn't enabled in the drivers by default, and as the VYUY format isn't a
strategic target, I think we can ignore that.
How about updating the commit message as follows ?
"The Gen3 VSP used by the DU for display does not support packed the VYUY
pixel format. Gen2 VSP hardware is able to process this format, but DU + VSP
operation isn't enabled on Gen2, and VYUY isn't a strategic format, so it can
be ignored."
> Remove the format from the capabilities of the DU driver.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
> ---
> drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c index 4480243813ec..4576119e
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
> @@ -126,7 +126,6 @@ static const u32 formats_kms[] = {
> DRM_FORMAT_ARGB,
> DRM_FORMAT_XRGB,
> DRM_FORMAT_UYVY,
> - DRM_FORMAT_VYUY,
> DRM_FORMAT_YUYV,
> DRM_FORMAT_YVYU,
> DRM_FORMAT_NV12,
> @@ -155,7 +154,6 @@ static const u32 formats_v4l2[] = {
> V4L2_PIX_FMT_ABGR32,
> V4L2_PIX_FMT_XBGR32,
> V4L2_PIX_FMT_UYVY,
> - V4L2_PIX_FMT_VYUY,
> V4L2_PIX_FMT_YUYV,
> V4L2_PIX_FMT_YVYU,
> V4L2_PIX_FMT_NV12M,
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v10 0/2] Add XYUV format support
On Fri, Sep 14, 2018 at 01:36:32PM +, Lisovskiy, Stanislav wrote: > On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote: > > Introduced new XYUV scan-in format for framebuffer and > > added support for it to i915(SkyLake+). > > > > Stanislav Lisovskiy (2): > > drm: Introduce new DRM_FORMAT_XYUV > > drm/i915: Adding YUV444 packed format support for skl+ > > > > drivers/gpu/drm/drm_fourcc.c | 1 + > > drivers/gpu/drm/i915/i915_reg.h | 2 +- > > drivers/gpu/drm/i915/intel_display.c | 15 +++ > > drivers/gpu/drm/i915/intel_sprite.c | 2 ++ > > include/uapi/drm/drm_fourcc.h| 1 + > > 5 files changed, 20 insertions(+), 1 deletion(-) > > > > Ping. There is an IGT patch which got Reviewed-by Ville. > This one left in order to get XYUV support. Did we figure out userspace for this? Was the conflict solved with the other guy (forgot who it is) trying to add the same format with a different name? -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 0/2] Add XYUV format support
On Fri, 2018-09-07 at 11:45 +0300, Stanislav Lisovskiy wrote: > Introduced new XYUV scan-in format for framebuffer and > added support for it to i915(SkyLake+). > > Stanislav Lisovskiy (2): > drm: Introduce new DRM_FORMAT_XYUV > drm/i915: Adding YUV444 packed format support for skl+ > > drivers/gpu/drm/drm_fourcc.c | 1 + > drivers/gpu/drm/i915/i915_reg.h | 2 +- > drivers/gpu/drm/i915/intel_display.c | 15 +++ > drivers/gpu/drm/i915/intel_sprite.c | 2 ++ > include/uapi/drm/drm_fourcc.h| 1 + > 5 files changed, 20 insertions(+), 1 deletion(-) > Ping. There is an IGT patch which got Reviewed-by Ville. This one left in order to get XYUV support. -- Best Regards, Lisovskiy Stanislav ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: rcar-du: Remove packed VYUY support
The Gen3 VSP used by the DU for display does not support packed the VYUY
pixel format. Gen2 VSP hardware is able to process this format, but it
is not officially supported there either and thus it's output can not be
guaranteed.
Remove the format from the capabilities of the DU driver.
Signed-off-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 4480243813ec..4576119e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -126,7 +126,6 @@ static const u32 formats_kms[] = {
DRM_FORMAT_ARGB,
DRM_FORMAT_XRGB,
DRM_FORMAT_UYVY,
- DRM_FORMAT_VYUY,
DRM_FORMAT_YUYV,
DRM_FORMAT_YVYU,
DRM_FORMAT_NV12,
@@ -155,7 +154,6 @@ static const u32 formats_v4l2[] = {
V4L2_PIX_FMT_ABGR32,
V4L2_PIX_FMT_XBGR32,
V4L2_PIX_FMT_UYVY,
- V4L2_PIX_FMT_VYUY,
V4L2_PIX_FMT_YUYV,
V4L2_PIX_FMT_YVYU,
V4L2_PIX_FMT_NV12M,
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: rcar-du: Add pixel format support
Hi Laurent,
On 14/09/18 12:17, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Friday, 31 August 2018 21:12:58 EEST Kieran Bingham wrote:
>> From: Koji Matsuoka
>>
>> This patch supports pixel format of RGB332, ARGB, XRGB,
>> BGR888, RGB888, BGRA, BGRX and YVYU.
>> VYUY pixel format is not supported by H/W specification.
>
> Should VYUY be removed from rcar_du_vsp.c ? This can be done in a separate
> patch.
On further consideration - yes, I believe it should.
Removal patch generated, and doesn't negatively affect the current
kms-tests, so expect it in your inbox imminently.
--
Regards
Kieran
>
>> Signed-off-by: Koji Matsuoka
>> Signed-off-by: Kieran Bingham
>>
>> ---
>>
>> This patch does not remove existing support for multiplanar YVUY, even
>> though the hardware does not explicitly provide it, because we support
>> it through software by swapping the plane buffers.
>>
>> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 32 +++
>> 1 file changed, 32 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 7c7aff8cdf77..d1bd174ec893
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> @@ -124,6 +124,38 @@ static const struct rcar_du_format_info
>> rcar_du_format_infos[] = { .fourcc = DRM_FORMAT_YVU444,
>> .bpp = 24,
>> .planes = 3,
>> +}, {
>> +.fourcc = DRM_FORMAT_RGB332,
>> +.bpp = 8,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_ARGB,
>> +.bpp = 16,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_XRGB,
>> +.bpp = 16,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_BGR888,
>> +.bpp = 24,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_RGB888,
>> +.bpp = 24,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_BGRA,
>> +.bpp = 32,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_BGRX,
>> +.bpp = 32,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_YVYU,
>> +.bpp = 16,
>> +.planes = 1,
>> },
>> };
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107213] [amdgpu/DisplayPort] KDE Wayland session is segfaulting right after login
https://bugs.freedesktop.org/show_bug.cgi?id=107213 --- Comment #15 from Shmerl --- I managed to make it produce a core. It's from kwin_wayland. After installing needed debug symbol packages, here is a backtrace: Core was generated by `/usr/bin/kwin_wayland --xwayland --libinput --exit-with-session=/usr/lib/x86_64'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x7eff59760f30 in wl_closure_init (message=message@entry=0x7, size=size@entry=52, num_arrays=num_arrays@entry=0x7eff5140858c, args=args@entry=0x0) at ../src/connection.c:562 562 ../src/connection.c: No such file or directory. [Current thread is 1 (Thread 0x7eff51409700 (LWP 7249))] (gdb) bt #0 0x7eff59760f30 in wl_closure_init (message=message@entry=0x7, size=size@entry=52, num_arrays=num_arrays@entry=0x7eff5140858c, args=args@entry=0x0) at ../src/connection.c:562 #1 0x7eff59761aa0 in wl_connection_demarshal (connection=0x7eff440053e0, size=size@entry=52, objects=objects@entry=0x7eff440052e8, message=0x7) at ../src/connection.c:698 #2 0x7eff5975fae8 in queue_event (len=52, display=0x7eff44005270) at ../src/wayland-client.c:1364 #3 read_events (display=0x7eff44005270) at ../src/wayland-client.c:1466 #4 wl_display_read_events (display=display@entry=0x7eff44005270) at ../src/wayland-client.c:1549 #5 0x7eff59760169 in wl_display_dispatch_queue (display=0x7eff44005270, queue=0x7eff44005338) at ../src/wayland-client.c:1788 #6 0x7eff5d123933 in KWayland::Client::ConnectionThread::Privateoperator() (__closure=0x7eff44009550) at ./src/client/connection_thread.cpp:129 #7 QtPrivate::FunctorCall, QtPrivate::List<>, void, KWayland::Client::ConnectionThread::Private::setupSocketNotifier():: >::call (arg=, f=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:128 #8 QtPrivate::Functor, 0>::call, void> (arg=, f=...) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:238 #9 QtPrivate::QFunctorSlotObject, 0, QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase *, QObject *, void **, bool *) (which=, this_=0x7eff44009540, r=, a=, ret=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:421 #10 0x7eff5e606910 in QtPrivate::QSlotObjectBase::call (a=0x7eff514087d0, r=0x564a80be84f0, this=0x7eff44009540) at ../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:376 #11 QMetaObject::activate(QObject*, int, int, void**) () at kernel/qobject.cpp:3754 #12 0x7eff5e606dd7 in QMetaObject::activate (sender=sender@entry=0x7eff44009440, m=m@entry=0x7eff5e863c60 , local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7eff514087d0) at kernel/qobject.cpp:3633 #13 0x7eff5e611ff9 in QSocketNotifier::activated (this=this@entry=0x7eff44009440, _t1=, _t2=...) at .moc/moc_qsocketnotifier.cpp:136 #14 0x7eff5e612341 in QSocketNotifier::event (this=0x7eff44009440, e=0x7eff51408a30) at kernel/qsocketnotifier.cpp:266 #15 0x7eff5e9cb4a1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #16 0x7eff5e9d2ae0 in QApplication::notify(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #17 0x7eff5e5dd579 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at ../../include/QtCore/5.11.1/QtCore/private/../../../../../src/corelib/thread/qthread_p.h:307 #18 0x7eff5e62fe4a in QCoreApplication::sendEvent (event=0x7eff51408a30, receiver=) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:234 #19 socketNotifierSourceDispatch(_GSource*, int (*)(void*), void*) () at kernel/qeventdispatcher_glib.cpp:106 #20 0x7eff5a647287 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #21 0x7eff5a6474c0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #22 0x7eff5a64754c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x7eff5e62f223 in QEventDispatcherGlib::processEvents (this=0x7eff44000b20, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #24 0x7eff5e5dc24b in QEventLoop::exec(QFlags) () at ../../include/QtCore/../../src/corelib/global/qflags.h:140 #25 0x7eff5e42b176 in QThread::exec() () at ../../include/QtCore/../../src/corelib/global/qflags.h:120 #26 0x7eff5e434d47 in QThreadPrivate::start(void*) () at thread/qthread_unix.cpp:367 #27 0x7eff5efb5f2a in start_thread (arg=0x7eff51409700) at pthread_create.c:463 #28 0x7eff5e0fdedf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 -- 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 201067] [bisected] [4.19-rc2 regression] Display corruption with Vega 64 in 4.19-rc2
https://bugzilla.kernel.org/show_bug.cgi?id=201067 --- Comment #6 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- I think you're referencing this patch: https://patchwork.freedesktop.org/patch/238065/ Which should be fixed in 4.18. Please post a new ticket with a full dmesg log, Xorg log and your distro/desktop environment if you can still reproduce the problem. -- 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
[Bug 199139] System freezes (kernel, amdgpu NULL pointer dereference) when video enters powersafe state
https://bugzilla.kernel.org/show_bug.cgi?id=199139 Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) changed: What|Removed |Added CC||nicholas.kazlaus...@amd.com --- Comment #10 from Nicholas Kazlauskas (nicholas.kazlaus...@amd.com) --- Please post a full dmesg log and Xorg log from your 4.18 kernel. If your setup differs from the original poster then it would likely help if you noted your distro/desktop environment as well. -- 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: [PATCH 2/3] drm: rcar-du: Add pixel format support
Hi Laurent,
On 14/09/18 12:11, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> How about renaming the subject line to "Add support for missing pixel
> formats"
> ?
>
Ack.
> On Friday, 31 August 2018 21:12:58 EEST Kieran Bingham wrote:
>> From: Koji Matsuoka
>>
>> This patch supports pixel format of RGB332, ARGB, XRGB,
>> BGR888, RGB888, BGRA, BGRX and YVYU.
>> VYUY pixel format is not supported by H/W specification.
>>
>> Signed-off-by: Koji Matsuoka
>> Signed-off-by: Kieran Bingham
>>
>> ---
>>
>> This patch does not remove existing support for multiplanar YVUY, even
>> though the hardware does not explicitly provide it, because we support
>> it through software by swapping the plane buffers.
>>
>> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 32 +++
>> 1 file changed, 32 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 7c7aff8cdf77..d1bd174ec893
>> 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
>> @@ -124,6 +124,38 @@ static const struct rcar_du_format_info
>> rcar_du_format_infos[] = { .fourcc = DRM_FORMAT_YVU444,
>> .bpp = 24,
>> .planes = 3,
>> +}, {
>> +.fourcc = DRM_FORMAT_RGB332,
>> +.bpp = 8,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_ARGB,
>> +.bpp = 16,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_XRGB,
>> +.bpp = 16,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_BGR888,
>> +.bpp = 24,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_RGB888,
>> +.bpp = 24,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_BGRA,
>> +.bpp = 32,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_BGRX,
>> +.bpp = 32,
>> +.planes = 1,
>> +}, {
>> +.fourcc = DRM_FORMAT_YVYU,
>> +.bpp = 16,
>> +.planes = 1,
>> },
>> };
>
> I would list the RGB formats first, followed by the packed YUV format, and
> then the multiplanar YUV formats. With this changed,
>
Ack.
> Reviewed-by: Laurent Pinchart
>
> If you're fine with the changes there's no need to resubmit.
That's fine by me.
Thanks
--
Kieran
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107095] Artifacts in X sessions, GPU fault 147
https://bugs.freedesktop.org/show_bug.cgi?id=107095 --- Comment #5 from Andrew Dorney --- This is still occurring as of today using: linux 4.18.6.arch1-1 mesa 18.2.0-1 xf86-video-amdgpu 18.0.1-2 xorg-server 1.20.1-1 Same error messages in 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: [v7] Add udmabuf misc device
On Fri, Sep 14, 2018 at 02:00:30PM +0200, Tomeu Vizoso wrote: > On 09/14/2018 08:37 AM, Gerd Hoffmann wrote: > >Hi, > > > > > > Well, no. This is *not* about 3D, it's about software rendering, for > > > > example cairo doing its work for gtk apps. So the workflow would be > > > > along these lines: > > > > > > > > (1) guest app allocates dumb drm buffer from virtio-gpu, renders to it. > > Why not let clients keep allocating memory for buffers with memfd? > > The guest proxy would then create a virtio-gpu resource to wrap the shm pool > memory. Should be workable too, with udmabuf in the guest. Allocate with memfd, turn into dmabuf using udmabuf, let the virtio-gpu guest driver import the thing so you have a virtio-gpu resource handle for it. I don't see why this is better than using virtio-gpu dumb buffers directly though. cheers, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/etnaviv: add DMA configuration for etnaviv platform device
Hi,
On Fri, Sep 14, 2018 at 11:24:38AM +0200, Lucas Stach wrote:
> The etnaviv device is a virtual device backing the DRM device, which may
> drive multiple hardware GPU core devies. As most of the dma-mapping handling
> is done through the virtual device, we need to make sure that a proper DMA
> setup is in place. The easiest way to get a reasonable configuration is
> to let the virtual device share the DMA configuration with one of the GPU
> devices, so call of_dma_configure() with the right parameters manually.
>
> This assumes that all etnaviv driven GPU devices in the system share the
> same DMA configuration. If we ever encounter a SoC where the GPUs are on
> busses with different offsets or behind different IOMMUs that will require
> much deeper changes to the driver, as we would need to implement etnaviv
> specific versions of most of the DRM helper functions.
>
> For now we should be fine with this solution.
This works on GC7000, thanks!
Tested-By: Guido Günther
>
> Signed-off-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 27 +--
> 1 file changed, 21 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index 9b2720b41571..83c1f46670bf 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -592,8 +592,6 @@ static int etnaviv_pdev_probe(struct platform_device
> *pdev)
> struct device *dev = >dev;
> struct component_match *match = NULL;
>
> - dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
> -
> if (!dev->platform_data) {
> struct device_node *core_node;
>
> @@ -655,13 +653,30 @@ static int __init etnaviv_init(void)
> for_each_compatible_node(np, NULL, "vivante,gc") {
> if (!of_device_is_available(np))
> continue;
> - pdev = platform_device_register_simple("etnaviv", -1,
> -NULL, 0);
> - if (IS_ERR(pdev)) {
> - ret = PTR_ERR(pdev);
> +
> + pdev = platform_device_alloc("etnaviv", -1);
> + if (!pdev) {
> + ret = -ENOMEM;
> + of_node_put(np);
> + goto unregister_platform_driver;
> + }
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(40);
> + pdev->dev.dma_mask = >dev.coherent_dma_mask;
> +
> + /*
> + * Apply the same DMA configuration to the virtual etnaviv
> + * device as the GPU we found. This assumes that all Vivante
> + * GPUs in the system share the same DMA constraints.
> + */
> + of_dma_configure(>dev, np, true);
> +
> + ret = platform_device_add(pdev);
> + if (ret) {
> + platform_device_put(pdev);
> of_node_put(np);
> goto unregister_platform_driver;
> }
> +
> etnaviv_drm = pdev;
> of_node_put(np);
> break;
> --
> 2.19.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] tests: Test mapping different caching types on etnaviv
This makes it simple to test if all cache types are mappable.
Signed-off-by: Guido Günther
---
Prompted by
https://lists.freedesktop.org/archives/etnaviv/2018-September/001946.html
tests/etnaviv/etnaviv_bo_cache_test.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/tests/etnaviv/etnaviv_bo_cache_test.c
b/tests/etnaviv/etnaviv_bo_cache_test.c
index 7fb06293..0ad37e19 100644
--- a/tests/etnaviv/etnaviv_bo_cache_test.c
+++ b/tests/etnaviv/etnaviv_bo_cache_test.c
@@ -28,6 +28,7 @@
#include
#include
+#include
#include
#include
#include
@@ -78,6 +79,28 @@ static void test_size_rounding(struct etna_device *dev)
printf("ok\n");
}
+
+static void test_write(struct etna_device *dev, uint32_t flags)
+{
+ struct etna_bo *bo;
+ uint32_t *buf;
+
+ /* allocate, map, write to, and free of a bo */
+ printf("testing bo map with flags 0x%"PRIx32"... ", flags);
+ fflush(stdout);
+
+ bo = etna_bo_new(dev, 0x100, flags);
+ assert(bo);
+ buf = etna_bo_map(bo);
+ assert(buf);
+ assert(!etna_bo_cpu_prep(bo, DRM_ETNA_PREP_WRITE));
+ memset(buf, 0, 0x100);
+ etna_bo_cpu_fini(bo);
+ etna_bo_del(bo);
+
+ printf("ok\n");
+}
+
int main(int argc, char *argv[])
{
struct etna_device *dev;
@@ -107,6 +130,9 @@ int main(int argc, char *argv[])
test_cache(dev);
test_size_rounding(dev);
+ test_write(dev, ETNA_BO_CACHED);
+ test_write(dev, ETNA_BO_WC);
+ test_write(dev, ETNA_BO_UNCACHED);
etna_device_del(dev);
--
2.18.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [v7] Add udmabuf misc device
On 09/14/2018 08:37 AM, Gerd Hoffmann wrote: Hi, Well, no. This is *not* about 3D, it's about software rendering, for example cairo doing its work for gtk apps. So the workflow would be along these lines: (1) guest app allocates dumb drm buffer from virtio-gpu, renders to it. Why not let clients keep allocating memory for buffers with memfd? The guest proxy would then create a virtio-gpu resource to wrap the shm pool memory. The VMM would receive a number of physical addresses that can be used to create a dmabuf. The would place the new FD in the wayland protocol stream. (2) guest app passes the buffer to wayland guest proxy (which looks like a wayland server/compositor to the app, but it doesn't actually composite anything). (3) wayland guest proxy passes buffer handle to wayland host proxy. (4) qemu can then use the buffer handle to lookup the virtio-gpu buffer, then use udmabuf to create a host dma-buf for it. (5) host dma-buf can be passed to host wayland server for display, so guest app window shows up seamlessly on the host. Details of the wayland protocol proxying are not hashed out yet. Thanks for the clarification. With dumb buffers, I guess the host can use DRM_FORMAT_MOD_LINEAR when sending the udmabuf-created buffer to the display. Note there are certain cases where tiled buffers are map-able (Intel), and with some variation of virtio_gpu_resource_create_coherent, we could expose that to the guest. The coherent mapping (host-allocated resources into guest address space) is another thing which needs to be sorted out. That's the direction we're interested in going, though it looks like udmabuf is orthogonal to that. Yes, udmabuf is the other way around, guest allocates resources and we make them available as host dmabufs. What details on wayland protocol proxying still need to be worked out? That's one component of the ChromiumOS solution (virtio_wl) that hasn't been up-streamed yet. That method maps guest fds to host fds. Tomeu Vizoso (Cc'ed) was looking into using virtio-serial as wayland protocol transport between host and guest. With udmabuf we can use virtio-gpu drm objects to pass pixel buffers from guest to host, which is one important building block for that. The approach that was agreed by everybody was to add ioctls to virtio-gpu to send and receive protocol messages. The guest proxy would use those ioctls and the VMM would play as the host proxy and would use similar virtio commands. There's code for that already and someone else from Collabora is to retake the upstreaming effort at some point soon. Regards, Tomeu ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [PATCH] drm/nouveau: Don't disable polling in fallback mode
On 14/09/2018 10:28, Ben Skeggs wrote:
> On Wed, 12 Sep 2018 at 20:59, Takashi Iwai wrote:
>>
>> When a fan is controlled via linear fallback without cstate, we
>> shouldn't stop polling. Otherwise it won't be adjusted again and
>> keeps running at an initial crazy pace.
> Martin,
>
> Any thoughts on this?
>
> Ben.
Wow, blast from the past!
Anyway, the analysis is pretty spot on here. When using the cstate-based
fan speed (change the speed of the fan based on what frequency is used),
then polling is unnecessary and this function should only be called when
changing the pstate.
However, in the absence of ANY information, we fallback to a
temperature-based management which requires constant polling, so the
patch is accurate and poll = false should only be set if we have a cstate.
So, the patch is Reviewed-by: Martin Peres
>
>>
>> Fixes: 800efb4c2857 ("drm/nouveau/drm/therm/fan: add a fallback if no fan
>> control is specified in the vbios")
>> Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1103356
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107447
I see that Thomas has been having issues with the noise level anyway. I
suggest he should bump the value of temp1_auto_point1_temp (see
https://www.kernel.org/doc/Documentation/thermal/nouveau_thermal).
The default value is set to 90°C which is quite safe on these old GPUs
(NVIDIA G71 / nv49). I would say that it is safe to go up to 110°C.
Which should reduce the noise level.
Another technique may be to reduce the minimum fan speed to something
lower than 30°C. It should increase the slope but reduce the noise level
at a given temperature.
One reason why these GPUs run so hot on nouveau is the lack of power and
clock gating. I am sorry that I never finished to reverse engineer these...
Anyway, thanks a lot for the patch!
>> Reported-by: Thomas Blume
>> Signed-off-by: Takashi Iwai
>>
>> ---
>> drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c | 7 ---
>> 1 file changed, 4 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
>> b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
>> index 3695cde669f8..07914e36939e 100644
>> --- a/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
>> +++ b/drivers/gpu/drm/nouveau/nvkm/subdev/therm/base.c
>> @@ -132,11 +132,12 @@ nvkm_therm_update(struct nvkm_therm *therm, int mode)
>> duty = nvkm_therm_update_linear(therm);
>> break;
>> case NVBIOS_THERM_FAN_OTHER:
>> - if (therm->cstate)
>> + if (therm->cstate) {
>> duty = therm->cstate;
>> - else
>> + poll = false;
>> + } else {
>> duty =
>> nvkm_therm_update_linear_fallback(therm);
>> - poll = false;
>> + }
>> break;
>> }
>> immd = false;
>> --
>> 2.18.0
>>
>> ___
>> Nouveau mailing list
>> nouv...@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 11/20] drm/imx: Use drm_fbdev_generic_setup()
Hi Noralf, On Sat, 2018-09-08 at 15:46 +0200, Noralf Trønnes wrote: > The CMA helper is already using the drm_fb_helper_generic_probe part of > the generic fbdev emulation. This patch makes full use of the generic > fbdev emulation by using its drm_client callbacks. This means that > drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are > now handled by the emulation code. Additionally fbdev unregister happens > automatically on drm_dev_unregister(). > > The drm_fbdev_generic_setup() call is put after drm_dev_register() in the > driver. This is done to highlight the fact that fbdev emulation is an > internal client that makes use of the driver, it is not part of the > driver as such. If fbdev setup fails, an error is printed, but the driver > succeeds probing. > > CONFIG_DRM_FBDEV_EMULATION wasn't honoured by the CMA helper, but it is by > drm_fb_helper. > > Cc: Philipp Zabel > Signed-off-by: Noralf Trønnes Tested-by: Philipp Zabel Acked-by: Philipp Zabel regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: rcar-du: Add pixel format support
Hi Kieran,
On Friday, 31 August 2018 21:12:58 EEST Kieran Bingham wrote:
> From: Koji Matsuoka
>
> This patch supports pixel format of RGB332, ARGB, XRGB,
> BGR888, RGB888, BGRA, BGRX and YVYU.
> VYUY pixel format is not supported by H/W specification.
Should VYUY be removed from rcar_du_vsp.c ? This can be done in a separate
patch.
> Signed-off-by: Koji Matsuoka
> Signed-off-by: Kieran Bingham
>
> ---
>
> This patch does not remove existing support for multiplanar YVUY, even
> though the hardware does not explicitly provide it, because we support
> it through software by swapping the plane buffers.
>
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 32 +++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 7c7aff8cdf77..d1bd174ec893
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -124,6 +124,38 @@ static const struct rcar_du_format_info
> rcar_du_format_infos[] = { .fourcc = DRM_FORMAT_YVU444,
> .bpp = 24,
> .planes = 3,
> + }, {
> + .fourcc = DRM_FORMAT_RGB332,
> + .bpp = 8,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_ARGB,
> + .bpp = 16,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_XRGB,
> + .bpp = 16,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_BGR888,
> + .bpp = 24,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_RGB888,
> + .bpp = 24,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_BGRA,
> + .bpp = 32,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_BGRX,
> + .bpp = 32,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_YVYU,
> + .bpp = 16,
> + .planes = 1,
> },
> };
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: rcar-du: Add pixel format support
Hi Kieran,
Thank you for the patch.
How about renaming the subject line to "Add support for missing pixel formats"
?
On Friday, 31 August 2018 21:12:58 EEST Kieran Bingham wrote:
> From: Koji Matsuoka
>
> This patch supports pixel format of RGB332, ARGB, XRGB,
> BGR888, RGB888, BGRA, BGRX and YVYU.
> VYUY pixel format is not supported by H/W specification.
>
> Signed-off-by: Koji Matsuoka
> Signed-off-by: Kieran Bingham
>
> ---
>
> This patch does not remove existing support for multiplanar YVUY, even
> though the hardware does not explicitly provide it, because we support
> it through software by swapping the plane buffers.
>
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 32 +++
> 1 file changed, 32 insertions(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 7c7aff8cdf77..d1bd174ec893
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -124,6 +124,38 @@ static const struct rcar_du_format_info
> rcar_du_format_infos[] = { .fourcc = DRM_FORMAT_YVU444,
> .bpp = 24,
> .planes = 3,
> + }, {
> + .fourcc = DRM_FORMAT_RGB332,
> + .bpp = 8,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_ARGB,
> + .bpp = 16,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_XRGB,
> + .bpp = 16,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_BGR888,
> + .bpp = 24,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_RGB888,
> + .bpp = 24,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_BGRA,
> + .bpp = 32,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_BGRX,
> + .bpp = 32,
> + .planes = 1,
> + }, {
> + .fourcc = DRM_FORMAT_YVYU,
> + .bpp = 16,
> + .planes = 1,
> },
> };
I would list the RGB formats first, followed by the packed YUV format, and
then the multiplanar YUV formats. With this changed,
Reviewed-by: Laurent Pinchart
If you're fine with the changes there's no need to resubmit.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: rcar-du: Update Gen3 output limitations
Hi Kieran,
Thank you for the patch.
On Friday, 31 August 2018 21:12:57 EEST Kieran Bingham wrote:
> The R-Car Gen3 DU utilises the VSP1 hardware for memory access. The
> limits on the RPF and WPF in this pipeline are 8190x8190.
>
> Update the supported maximum sizes accordingly.
>
> Signed-off-by: Kieran Bingham
Reviewed-by: Laurent Pinchart
and applied to my tree.
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 14 --
> 1 file changed, 12 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index ed7fa3204892..7c7aff8cdf77
> 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -512,12 +512,22 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
>
> dev->mode_config.min_width = 0;
> dev->mode_config.min_height = 0;
> - dev->mode_config.max_width = 4095;
> - dev->mode_config.max_height = 2047;
> dev->mode_config.normalize_zpos = true;
> dev->mode_config.funcs = _du_mode_config_funcs;
> dev->mode_config.helper_private = _du_mode_config_helper;
>
> + if (rcdu->info->gen < 3) {
> + dev->mode_config.max_width = 4095;
> + dev->mode_config.max_height = 2047;
> + } else {
> + /*
> + * The Gen3 DU uses the VSP1 for memory access, and is limited
> + * to frame sizes of 8190x8190.
> + */
> + dev->mode_config.max_width = 8190;
> + dev->mode_config.max_height = 8190;
> + }
> +
> rcdu->num_crtcs = hweight8(rcdu->info->channels_mask);
>
> ret = rcar_du_properties_init(rcdu);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> On Icelake, a separate power well PG2 is created for
> VDSC engine used for eDP/MIPI DSI. This patch adds a new
> display power domain for Power well 2.
>
> Cc: Rodrigo Vivi
> Cc: Imre Deak
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/intel_display.h| 1 +
> drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> 2 files changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.h
> b/drivers/gpu/drm/i915/intel_display.h
> index 3fe52788b4cf..bef71d27cdfe 100644
> --- a/drivers/gpu/drm/i915/intel_display.h
> +++ b/drivers/gpu/drm/i915/intel_display.h
> @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> POWER_DOMAIN_MODESET,
> POWER_DOMAIN_GT_IRQ,
> POWER_DOMAIN_INIT,
> + POWER_DOMAIN_VDSC_EDP_MIPI,
This is better named VDSC_PIPE_A. The other pipes have also VDSC
functionality which could be on separate power wells in the future.
>
> POWER_DOMAIN_NUM,
> };
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_pm.c
> index 480dadb1047b..146e2d6cf954 100644
> --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> @@ -146,6 +146,8 @@ intel_display_power_domain_str(enum
> intel_display_power_domain domain)
> return "MODESET";
> case POWER_DOMAIN_GT_IRQ:
> return "GT_IRQ";
> + case POWER_DOMAIN_VDSC_EDP_MIPI:
> + return "VDSC_EDP_MIPI";
> default:
> MISSING_CASE(domain);
> return "?";
> @@ -1966,18 +1968,16 @@ void intel_display_power_put(struct drm_i915_private
> *dev_priv,
> BIT_ULL(POWER_DOMAIN_AUDIO) | \
> BIT_ULL(POWER_DOMAIN_INIT))
> /*
> - * - transcoder WD
> - * - KVMR (HW control)
> + * - eDP/MIPI DSI VDSC
We're not changing anything in the PW3 domains list, so why changing
the above?
>*/
> #define ICL_PW_2_POWER_DOMAINS ( \
> - ICL_PW_3_POWER_DOMAINS |\
> - BIT_ULL(POWER_DOMAIN_INIT))
The above is bogus, both the PW3 domains and the INIT domain should
stay included in the list of PW2 domains.
> + BIT_ULL(POWER_DOMAIN_VDSC_EDP_MIPI))
> /*
> - * - eDP/DSI VDSC
> + * - transcoder WD
Why adding here the transcoder WD?
>* - KVMR (HW control)
>*/
> #define ICL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> - ICL_PW_2_POWER_DOMAINS |\
> + ICL_PW_3_POWER_DOMAINS |\
The PW2 domain list should stay included in the DC_OFF domain list (and
so no need to add the PW3 domain list either).
> BIT_ULL(POWER_DOMAIN_MODESET) | \
> BIT_ULL(POWER_DOMAIN_AUX_A) | \
> BIT_ULL(POWER_DOMAIN_INIT))
> --
> 2.18.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC]drm: add syncobj timeline support v5
Am 14.09.2018 um 12:37 schrieb Chunming Zhou:
This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
syncobj in kernel side:
This extension introduces a new type of syncobj that has an integer payload
identifying a point in a timeline. Such timeline syncobjs support the
following operations:
* CPU query - A host operation that allows querying the payload of the
timeline syncobj.
* CPU wait - A host operation that allows a blocking wait for a
timeline syncobj to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline syncobj to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline syncobj to a specified value.
Since it's a timeline, that means the front time point(PT) always is signaled
before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when timeline is
increasing, will compare
wait PTs value with new timeline value, if PT value is lower than timeline
value, then wait PT will be
signaled, otherwise keep in list. syncobj wait operation can wait on any point
of timeline,
so need a RB tree to order them. And wait PT could ahead of signal PT, we need
a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate patch.
(Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate patch.
5. drop the submission_fence implementation and instead use wait_event() for
that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
v3:
1. replace normal syncobj with timeline implemenation. (Vetter and Christian)
a. normal syncobj signal op will create a signal PT to tail of signal pt
list.
b. normal syncobj wait op will create a wait pt with last signal point,
and this wait PT is only signaled by related signal point PT.
2. many bug fix and clean up
3. stub fence moving is moved to other patch.
v4：
1. fix RB tree loop with while(node=rb_first(...)). (Christian)
2. fix syncobj lifecycle. (Christian)
3. only enable_signaling when there is wait_pt. (Christian)
4. fix timeline path issues.
5. write a timeline test in libdrm
v5: (Christian)
1. semaphore is called syncobj in kernel side.
2. don't need 'timeline' characters in some function name.
3. keep syncobj cb
normal syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore*
timeline syncobj is tested by ./amdgpu_test -s 9
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
At least on first glance that looks like it should work, going to do a
detailed review on Monday.
Christian.
---
drivers/gpu/drm/drm_syncobj.c | 294 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
include/drm/drm_syncobj.h | 62 +++--
include/uapi/drm/drm.h | 1 +
4 files changed, 292 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e9ce623d049e..e78d076f2703 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,9 @@either
#include "drm_internal.h"
#include
+/* merge normal syncobj to timeline syncobj, the point interval is 1 */
+#define DRM_SYNCOBJ_NORMAL_POINT 1
+
struct drm_syncobj_stub_fence {
struct dma_fence base;
spinlock_t lock;
@@ -82,6 +85,11 @@ static const struct dma_fence_ops drm_syncobj_stub_fence_ops
= {
.release = drm_syncobj_stub_fence_release,
};
+struct drm_syncobj_signal_pt {
+ struct dma_fence_array *base;
+ u64value;
+ struct list_head list;
+};
/**
* drm_syncobj_find - lookup and reference a sync object.
@@ -124,7 +132,7 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
{
int ret;
- *fence = drm_syncobj_fence_get(syncobj);
+ ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
if (*fence)
return 1;
@@ -133,10 +141,10 @@ static int drm_syncobj_fence_get_or_add_callback(struct drm_syncobj *syncobj,
* have the lock, try one more time just to be sure we don't add a
* callback when a fence has already been set.
*/
- if (syncobj->fence) {
- *fence = dma_fence_get(rcu_dereference_protected(syncobj->fence,
-
lockdep_is_held(>lock)));
- ret = 1;
+ if (fence) {
+ drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ if (*fence)
+ ret = 1;
}
[PATCH] [RFC]drm: add syncobj timeline support v5
This patch is for VK_KHR_timeline_semaphore extension, semaphore is called
syncobj in kernel side:
This extension introduces a new type of syncobj that has an integer payload
identifying a point in a timeline. Such timeline syncobjs support the
following operations:
* CPU query - A host operation that allows querying the payload of the
timeline syncobj.
* CPU wait - A host operation that allows a blocking wait for a
timeline syncobj to reach a specified value.
* Device wait - A device operation that allows waiting for a
timeline syncobj to reach a specified value.
* Device signal - A device operation that allows advancing the
timeline syncobj to a specified value.
Since it's a timeline, that means the front time point(PT) always is signaled
before the late PT.
a. signal PT design:
Signal PT fence N depends on PT[N-1] fence and signal opertion fence, when
PT[N] fence is signaled,
the timeline will increase to value of PT[N].
b. wait PT design:
Wait PT fence is signaled by reaching timeline point value, when timeline is
increasing, will compare
wait PTs value with new timeline value, if PT value is lower than timeline
value, then wait PT will be
signaled, otherwise keep in list. syncobj wait operation can wait on any point
of timeline,
so need a RB tree to order them. And wait PT could ahead of signal PT, we need
a sumission fence to
perform that.
v2:
1. remove unused DRM_SYNCOBJ_CREATE_TYPE_NORMAL. (Christian)
2. move unexposed denitions to .c file. (Daniel Vetter)
3. split up the change to drm_syncobj_find_fence() in a separate patch.
(Christian)
4. split up the change to drm_syncobj_replace_fence() in a separate patch.
5. drop the submission_fence implementation and instead use wait_event() for
that. (Christian)
6. WARN_ON(point != 0) for NORMAL type syncobj case. (Daniel Vetter)
v3:
1. replace normal syncobj with timeline implemenation. (Vetter and Christian)
a. normal syncobj signal op will create a signal PT to tail of signal pt
list.
b. normal syncobj wait op will create a wait pt with last signal point, and
this wait PT is only signaled by related signal point PT.
2. many bug fix and clean up
3. stub fence moving is moved to other patch.
v4：
1. fix RB tree loop with while(node=rb_first(...)). (Christian)
2. fix syncobj lifecycle. (Christian)
3. only enable_signaling when there is wait_pt. (Christian)
4. fix timeline path issues.
5. write a timeline test in libdrm
v5: (Christian)
1. semaphore is called syncobj in kernel side.
2. don't need 'timeline' characters in some function name.
3. keep syncobj cb
normal syncobj is tested by ./deqp-vk -n dEQP-VK*semaphore*
timeline syncobj is tested by ./amdgpu_test -s 9
Signed-off-by: Chunming Zhou
Cc: Christian Konig
Cc: Dave Airlie
Cc: Daniel Rakos
Cc: Daniel Vetter
---
drivers/gpu/drm/drm_syncobj.c | 294 ++---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 4 +-
include/drm/drm_syncobj.h | 62 +++--
include/uapi/drm/drm.h | 1 +
4 files changed, 292 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e9ce623d049e..e78d076f2703 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -56,6 +56,9 @@
#include "drm_internal.h"
#include
+/* merge normal syncobj to timeline syncobj, the point interval is 1 */
+#define DRM_SYNCOBJ_NORMAL_POINT 1
+
struct drm_syncobj_stub_fence {
struct dma_fence base;
spinlock_t lock;
@@ -82,6 +85,11 @@ static const struct dma_fence_ops drm_syncobj_stub_fence_ops
= {
.release = drm_syncobj_stub_fence_release,
};
+struct drm_syncobj_signal_pt {
+ struct dma_fence_array *base;
+ u64value;
+ struct list_head list;
+};
/**
* drm_syncobj_find - lookup and reference a sync object.
@@ -124,7 +132,7 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
{
int ret;
- *fence = drm_syncobj_fence_get(syncobj);
+ ret = drm_syncobj_search_fence(syncobj, 0, 0, fence);
if (*fence)
return 1;
@@ -133,10 +141,10 @@ static int drm_syncobj_fence_get_or_add_callback(struct
drm_syncobj *syncobj,
* have the lock, try one more time just to be sure we don't add a
* callback when a fence has already been set.
*/
- if (syncobj->fence) {
- *fence = dma_fence_get(rcu_dereference_protected(syncobj->fence,
-
lockdep_is_held(>lock)));
- ret = 1;
+ if (fence) {
+ drm_syncobj_search_fence(syncobj, 0, 0, fence);
+ if (*fence)
+ ret = 1;
} else {
*fence = NULL;
drm_syncobj_add_callback_locked(syncobj, cb, func);
@@ -164,6 +172,151 @@ void drm_syncobj_remove_callback(struct drm_syncobj
*syncobj,
[Bug 106111] [GPU Passthrough]GPU (Polaris) not reinitialized with Linux VM (Reset bug)
https://bugs.freedesktop.org/show_bug.cgi?id=106111 --- Comment #7 from Andrew Sheldon --- Another workaround that has worked for me with a Vega 56 is to suspend-to-ram the host system before trying to start the guest again. -- 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 107929] High memory clock speed issue on R9 380
https://bugs.freedesktop.org/show_bug.cgi?id=107929 Michel Dänzer changed: What|Removed |Added CC||harry.wentl...@amd.com, ||sunpeng...@amd.com Product|xorg|DRI Component|Driver/AMDgpu |DRM/AMDgpu Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org QA Contact|xorg-t...@lists.x.org | -- 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 1/4] MAINTAINERS: rcar-du: Add co-maintainer
Hi Jacopo, On Thursday, 13 September 2018 12:37:00 EEST jacopo mondi wrote: > Hi Kieran, Laurent > > On Mon, Aug 06, 2018 at 03:39:01PM +0100, Kieran Bingham wrote: > > From: Kieran Bingham > > > > Add myself as a co-maintainer for the Renesas DRM drivers. > > > > Signed-off-by: Kieran Bingham > > --- > > Cc: Laurent Pinchart > > Cc: dri-devel@lists.freedesktop.org > > Cc: linux-renesas-...@vger.kernel.org > > > > MAINTAINERS | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index 7cebd5bba8a8..c7cecb9201b3 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -4764,6 +4764,7 @@ > > F: Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x. > > txt > > DRM DRIVERS FOR RENESAS > > M: Laurent Pinchart > > +M: Kieran Bingham > > L: dri-devel@lists.freedesktop.org > > L: linux-renesas-...@vger.kernel.org > > T: git git://linuxtv.org/pinchartl/fbdev > > Am I wrong or this git repository isn't actual anymore for DU? You're right, the fix will be in my pull request for v4.20. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] MAINTAINERS: rcar-du: Add co-maintainer
Hi Kieran, Thank you for the patch. On Monday, 6 August 2018 17:39:01 EEST Kieran Bingham wrote: > From: Kieran Bingham > > Add myself as a co-maintainer for the Renesas DRM drivers. > > Signed-off-by: Kieran Bingham Acked-by: Laurent Pinchart and applied to my tree. Thank you for your help with the R-Car DU driver ! > --- > Cc: Laurent Pinchart > Cc: dri-devel@lists.freedesktop.org > Cc: linux-renesas-...@vger.kernel.org > > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7cebd5bba8a8..c7cecb9201b3 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4764,6 +4764,7 @@ > F:Documentation/devicetree/bindings/display/tegra/nvidia,tegra20- host1x.tx > t > > DRM DRIVERS FOR RENESAS > M: Laurent Pinchart > +M: Kieran Bingham > L: dri-devel@lists.freedesktop.org > L: linux-renesas-...@vger.kernel.org > T: git git://linuxtv.org/pinchartl/fbdev -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 1/2] drm: Add library for shmem backed GEM objects
On Wednesday, 2018-09-12 20:33:32 -0500, David Lechner wrote:
> On 09/11/2018 07:43 AM, Noralf Trønnes wrote:
> > This adds a library for shmem backed GEM objects with the necessary
> > drm_driver callbacks.
> >
> > Signed-off-by: Noralf Trønnes
> > ---
> >
>
> ...
>
> > +static int drm_gem_shmem_vmap_locked(struct drm_gem_shmem_object *shmem)
> > +{
> > + struct drm_gem_object *obj = >base;
> > + int ret;
> > +
> > + if (shmem->vmap_use_count++ > 0)
> > + return 0;
> > +
> > + ret = drm_gem_shmem_get_pages(shmem);
> > + if (ret)
> > + goto err_zero_use;
> > +
> > + if (obj->import_attach) {
> > + shmem->vaddr = dma_buf_vmap(obj->import_attach->dmabuf);
> > + } else {
> > + pgprot_t prot;
> > +
> > + switch (shmem->cache_mode) {
> > + case DRM_GEM_SHMEM_BO_UNKNOWN:
> > + DRM_DEBUG_KMS("Can't vmap cache mode is unknown\n");
> > + ret = -EINVAL;
> > + goto err_put_pages;
> > +
> > + case DRM_GEM_SHMEM_BO_WRITECOMBINED:
> > + prot = pgprot_writecombine(PAGE_KERNEL);
> > + break;
> > +
> > + case DRM_GEM_SHMEM_BO_UNCACHED:
> > + prot = pgprot_noncached(PAGE_KERNEL);
> > + break;
> > +
> > + case DRM_GEM_SHMEM_BO_CACHED:
> > + prot = PAGE_KERNEL;
> > + break;
> > + }
> > +
> > + shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT,
> > VM_MAP, prot);
>
> I get a gcc warning here:
>
> /home/david/work/ev3dev2/ev3dev-kernel/drivers/gpu/drm/drm_gem_shmem_helper.c:220:18:
> warning: ‘prot’ may be used uninitialized in this function
> [-Wmaybe-uninitialized]
>shmem->vaddr = vmap(shmem->pages, obj->size >> PAGE_SHIFT, VM_MAP, prot);
> ^
> /home/david/work/ev3dev2/ev3dev-kernel/drivers/gpu/drm/drm_gem_shmem_helper.c:199:12:
> note: ‘prot’ was declared here
>pgprot_t prot;
> ^~~~
This warning is saying that the vmap could be reached without hitting
any cases in the switch, which is technically true if one sets the
cache_mode to some garbage, but not if only existing enums from `enum
drm_gem_shmem_cache_mode` are used.
I think we should just add a `default:` next to the
DRM_GEM_SHMEM_BO_UNKNOWN case.
>
> ---
>
> And since I am making a comment anyway, it is not clear to me
> what BO means in the enum names. I didn't see any hints in the
> doc comments either.
Buffer Object, but yeah I guess it's not necessary in the enum names.
>
>
> > + }
> > +
> > + if (!shmem->vaddr) {
> > + DRM_DEBUG_KMS("Failed to vmap pages\n");
> > + ret = -ENOMEM;
> > + goto err_put_pages;
> > + }
> > +
> > + return 0;
> > +
> > +err_put_pages:
> > + drm_gem_shmem_put_pages(shmem);
> > +err_zero_use:
> > + shmem->vmap_use_count = 0;
> > +
> > + return ret;
> > +}
> ___
> 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
[PATCH] libdrm: Add Arm Framebuffer Compression (AFBC) modifiers
drm_fourcc.h file Generated using make headers_install.
Generated from
tree - git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
branch - master
commit - ce6058039bca7f1f11f1723549eec1bc069dcb28
Removed the 'SAND modifiers' part to commit only the AFBC specific
code in drm_fourcc.h ie the changes introduced by the following commits
were removed by git add -i :-
e065a8dd30af703b4794dc740c0825ee12b92efd
14d9deeb273c2bf4ec256589adabd8df65395d36
Change-Id: If050c17779ba16f8f47adcd825e3e2300676c247
Signed-off-by: Ayan Kumar halder
---
include/drm/drm_fourcc.h | 83
1 file changed, 83 insertions(+)
diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
index e04613d..af7e9ab 100644
--- a/include/drm/drm_fourcc.h
+++ b/include/drm/drm_fourcc.h
@@ -183,6 +183,7 @@ extern "C" {
#define DRM_FORMAT_MOD_VENDOR_QCOM0x05
#define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
#define DRM_FORMAT_MOD_VENDOR_BROADCOM 0x07
+#define DRM_FORMAT_MOD_VENDOR_ARM 0x08
/* add more to the end as needed */
#define DRM_FORMAT_RESERVED ((1ULL << 56) - 1)
@@ -405,6 +406,88 @@ extern "C" {
*/
#define DRM_FORMAT_MOD_BROADCOM_VC4_T_TILED fourcc_mod_code(BROADCOM, 1)
+/*
+ * Arm Framebuffer Compression (AFBC) modifiers
+ *
+ * AFBC is a proprietary lossless image compression protocol and format.
+ * It provides fine-grained random access and minimizes the amount of data
+ * transferred between IP blocks.
+ *
+ * AFBC has several features which may be supported and/or used, which are
+ * represented using bits in the modifier. Not all combinations are valid,
+ * and different devices or use-cases may support different combinations.
+ */
+#define DRM_FORMAT_MOD_ARM_AFBC(__afbc_mode) fourcc_mod_code(ARM,
__afbc_mode)
+
+/*
+ * AFBC superblock size
+ *
+ * Indicates the superblock size(s) used for the AFBC buffer. The buffer
+ * size (in pixels) must be aligned to a multiple of the superblock size.
+ * Four lowest significant bits(LSBs) are reserved for block size.
+ */
+#define AFBC_FORMAT_MOD_BLOCK_SIZE_MASK 0xf
+#define AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 (1ULL)
+#define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 (2ULL)
+
+/*
+ * AFBC lossless colorspace transform
+ *
+ * Indicates that the buffer makes use of the AFBC lossless colorspace
+ * transform.
+ */
+#define AFBC_FORMAT_MOD_YTR (1ULL << 4)
+
+/*
+ * AFBC block-split
+ *
+ * Indicates that the payload of each superblock is split. The second
+ * half of the payload is positioned at a predefined offset from the start
+ * of the superblock payload.
+ */
+#define AFBC_FORMAT_MOD_SPLIT (1ULL << 5)
+
+/*
+ * AFBC sparse layout
+ *
+ * This flag indicates that the payload of each superblock must be stored at a
+ * predefined position relative to the other superblocks in the same AFBC
+ * buffer. This order is the same order used by the header buffer. In this mode
+ * each superblock is given the same amount of space as an uncompressed
+ * superblock of the particular format would require, rounding up to the next
+ * multiple of 128 bytes in size.
+ */
+#define AFBC_FORMAT_MOD_SPARSE (1ULL << 6)
+
+/*
+ * AFBC copy-block restrict
+ *
+ * Buffers with this flag must obey the copy-block restriction. The restriction
+ * is such that there are no copy-blocks referring across the border of 8x8
+ * blocks. For the subsampled data the 8x8 limitation is also subsampled.
+ */
+#define AFBC_FORMAT_MOD_CBR (1ULL << 7)
+
+/*
+ * AFBC tiled layout
+ *
+ * The tiled layout groups superblocks in 8x8 or 4x4 tiles, where all
+ * superblocks inside a tile are stored together in memory. 8x8 tiles are used
+ * for pixel formats up to and including 32 bpp while 4x4 tiles are used for
+ * larger bpp formats. The order between the tiles is scan line.
+ * When the tiled layout is used, the buffer size (in pixels) must be aligned
+ * to the tile size.
+ */
+#define AFBC_FORMAT_MOD_TILED (1ULL << 8)
+
+/*
+ * AFBC solid color blocks
+ *
+ * Indicates that the buffer makes use of solid-color blocks, whereby bandwidth
+ * can be reduced if a whole superblock is a single color.
+ */
+#define AFBC_FORMAT_MOD_SC (1ULL << 9)
+
#if defined(__cplusplus)
}
#endif
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107928] Screen regularly turns black, reboot needed
https://bugs.freedesktop.org/show_bug.cgi?id=107928 --- Comment #2 from Vik-T --- Created attachment 141560 --> https://bugs.freedesktop.org/attachment.cgi?id=141560=edit Dmesg Output -- 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 v2 6/8] drm/imx: support handling bridge timings bus flags
Hi Stefan, Thank you for the patch. On Wednesday, 12 September 2018 21:32:20 EEST Stefan Agner wrote: > A bridge might require specific settings for the pixel data on > the bus. Copy the bus flags from the bridge timings if a bridge > is in use. > > Signed-off-by: Stefan Agner > --- > drivers/gpu/drm/imx/parallel-display.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/gpu/drm/imx/parallel-display.c > b/drivers/gpu/drm/imx/parallel-display.c index aefd04e18f93..7798a0621df7 > 100644 > --- a/drivers/gpu/drm/imx/parallel-display.c > +++ b/drivers/gpu/drm/imx/parallel-display.c > @@ -239,6 +239,9 @@ static int imx_pd_bind(struct device *dev, struct device > *master, void *data) if (ret && ret != -ENODEV) > return ret; > > + if (imxpd->bridge && imxpd->bridge->timings) > + imxpd->bus_flags = imxpd->bridge->timings->input_bus_flags; As explained in different replies in this mail thread (and in v1), we need something more complex than this. How about creating a helper function that would take a sampling edge, setup and hold times, clock frequency and internal delay on the driving side, and return which edge to drive the data on ? I agree with you that the logic is complex, so we shouldn't duplicate it in multiple drivers. If you submit such a patch I'll implement support for configuring the clock edge in the R-Car DU driver and test it with the ADV7123. > imxpd->dev = dev; > > ret = imx_pd_register(drm, imxpd); -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] drm/bridge: use bus flags in bridge timings
On Friday, 14 September 2018 12:49:40 EEST Laurent Pinchart wrote: > Hi Stefan, > > On Thursday, 6 September 2018 23:25:56 EEST Stefan Agner wrote: > > On 06.09.2018 04:07, Linus Walleij wrote: > > > On Wed, Sep 5, 2018 at 8:32 PM Stefan Agner wrote: > > >> On 05.09.2018 00:44, Laurent Pinchart wrote: > > >> > > >> Good point! I actually really don't like that we use the same flags > > >> here > > >> but from a different perspective. Especially since the flags defines > > >> document things differently: > > >> > > >> /* drive data on pos. edge */ > > >> #define DRM_BUS_FLAG_PIXDATA_POSEDGE(1<<2) > > >> /* drive data on neg. edge */ > > >> #define DRM_BUS_FLAG_PIXDATA_NEGEDGE(1<<3) > > > > > > Maybe a stupid comment from my side, but can't we just change the > > > documentation to match the usecases? > > > > > > /* Trigger pixel data latch on positive edge */ > > > #define DRM_BUS_FLAG_PIXDATA_POSEDGE(1<<2) > > > > > >> Using the opposite perspective would also need translation in crtc > > >> drivers... So far no driver uses sampling_edge. > > >> > > >> I would prefer if we always use the meaning as documented by the flags. > > >> > > >> I guess we would need to convert DRM_BUS_FLAG_PIXDATA_POSEDGE -> > > >> DRM_BUS_FLAG_PIXDATA_NEGEDGE. > > >> > > >> Linus Walleij, you added sampling edge, any thoughts? > > > > > > I just thought it was generally useful to have triggering edge encoded > > > into the bridge as it makes it clear that this edge is something > > > that is a delayed version of the driving edge which is subject to > > > clock skew caused by the speed of electrons in silicon and > > > copper and slew rate caused by parasitic capacitance. > > > > Ok, I read a bit up on the history of bridge timing, especially: > > https://www.spinics.net/lists/dri-devel/msg155618.html > > > > IMHO, this got overengineered. For displays we do not need all that > > setup/sample delay timing information, and much longer cables are in > > use. So why is all that needed for bridges? > > > > For Linus case, the THS8134(A/B) data sheet I found (revised March 2010) > > clearly states: > > Clock input. A rising edge on CLK latches RPr0-7, GY0-7, BPb0-7. > > > > So we need to drive on negative edge, hence DRM_BUS_FLAG_PIXDATA_NEGEDGE > > should be used, which makes the pl111 driver setting TIM2_IPC: > > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0121d/index > > .h tml > > > > > DRM_BUS_FLAG_PIXDATA_POSEDGE is the right value for my use cases, but it > > > doesn't match how the ADV7123 operates. Using > > > DRM_BUS_FLAG_PIXDATA_NEGEDGE > > > would match the hardware, but would break display for some modes, > > > depending on the display clock frequency as the internal 8.5ns output > > > delay applied to a falling clock edge would fall right into the 1.7ns > > > setup + hold time window of the ADV7123 around the rising edge. I can't > > > test this right now as I don't have local access to boards using the > > > ADV7123, but from a quick calculation that ignores the PCB transmission > > > delay modes with frequencies between 57MHz and 71MHz could break if the > > > data was output on the falling edge of the clock. > > > > If clocks vs. data signal are really that much off on R-Car DU, then > > parallel displays must have the very same issue... > > > > Are you sure that only the clock signal has an output delay? And that > > this output delay is a fixed value, clock independent? > > > > Typically, delays apply to all signals equally, and often are clock > > frequency dependent... > > > > Without really looking at the signals, I would not jump to conclusions > > here! I am pretty sure that driving on negative edge works just as well. > > I've tested Linus' original patch and it broke display on R-Car, so, no, it > doesn't work :-) > > The R-Car display engine delays the clock internally (in some cases that > delay is even configurable, and that's not uncommon in display > controllers). We really need all this information, and I believe we need it > for panels too, not just for bridges. The fact that we managed to get away > without adding it to panels is likely due to the large number of panels out > there, which makes it less likely that the same panel gets used by > different systems in mainline with different clock delays. I expect that > some panel drivers report the wrong clock edge to make things work on the > board they were tested with, and I expect we'll eventually need to add the > same information for panels too. > > So please don't remove this useful API, otherwise you'll break my board, and > I won't be happy. Or, to be precise, the board won't break now, but as soon as I need to implement support for configuring the output clock edge, it will break as the ADV7123 driver won't give me the right information to make the right choice. -- Regards, Laurent Pinchart ___ dri-devel mailing list
