Re: [PATCH v2 1/3] drm: Add support for panic message output
Hi,
[[ CCing John for the trylock parts ]]
On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
>
> Den 11.03.2019 20.23, skrev Daniel Vetter:
> > On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> >> This adds support for outputting kernel messages on panic().
> >> A kernel message dumper is used to dump the log. The dumper iterates
> >> over each DRM device and it's crtc's to find suitable framebuffers.
> >>
> >> All the other dumpers are run before this one except mtdoops.
> >> Only atomic drivers are supported.
> >>
> >> Signed-off-by: Noralf Trønnes
> >
> > Bunch of comments/ideas for you or Darwish below, whoever picks this up.
>
> Actually it would ne nice if Darwish could pick it up since he will do
> it on i915 which will be useful to a much broader audience.
> If not I'll respin when I'm done with the drm_fb_helper refactoring.
>
Yup, I'll be more than happy to do this.. while preserving all of
Noralf's authorship and copyright notices of course.
I guess it can be:
- Handle the comments posted by Daniel and others (I'll post
some questions too)
- Add the necessary i915 specific bits
- Test, post v3/v4/../vn. Rinse and repeat. Keep it local at
dri-devel until getting the necessary S-o-Bs.
- Post to wider audience (some feedback from distribution folks
would also be nice, before posting to lkml)
More comments below..
[...]
> >> +
> >> +static void drm_panic_kmsg_dump(struct kmsg_dumper *dumper,
> >> + enum kmsg_dump_reason reason)
> >> +{
> >> + class_for_each_device(drm_class, NULL, dumper, drm_panic_dev_iter);
> >
> > class_for_each_device uses klist, which only uses an irqsave spinlock. I
> > think that's good enough. Comment to that effect would be good e.g.
> >
> > /* based on klist, which uses only a spin_lock_irqsave, which we
> > * assume still works */
> >
> > If we aim for perfect this should be a trylock still, maybe using our own
> > device list.
> >
I definitely agree here.
The lock may already be locked either by a stopped CPU, or by the
very same CPU we execute panic() on (e.g. NMI panic() on the
printing CPU).
This is why it's very common for example in serial consoles, which
are usually careful about re-entrance and panic contexts, to do:
xx_console_write(...) {
if (oops_in_progress)
locked = spin_trylock_irqsave(>lock, flags);
else
spin_lock_irqsave(>lock, flags);
}
I'm quite positive we should do the same for panic drm drivers.
John?
> >> +}
> >> +
> >> +static struct kmsg_dumper drm_panic_kmsg_dumper = {
> >> + .dump = drm_panic_kmsg_dump,
> >> + .max_reason = KMSG_DUMP_PANIC,
> >> +};
> >> +
> >> +static ssize_t drm_panic_file_panic_write(struct file *file,
> >> +const char __user *user_buf,
> >> +size_t count, loff_t *ppos)
> >> +{
> >> + unsigned long long val;
> >> + char buf[24];
> >> + size_t size;
> >> + ssize_t ret;
> >> +
> >> + size = min(sizeof(buf) - 1, count);
> >> + if (copy_from_user(buf, user_buf, size))
> >> + return -EFAULT;
> >> +
> >> + buf[size] = '\0';
> >> + ret = kstrtoull(buf, 0, );
> >> + if (ret)
> >> + return ret;
> >> +
> >> + drm_panic_kmsg_dumper.max_reason = KMSG_DUMP_OOPS;
> >> + wmb();
> >> +
> >> + /* Do a real test with: echo c > /proc/sysrq-trigger */
> >> +
> >> + if (val == 0) {
> >> + pr_info("Test panic screen using kmsg_dump(OOPS)\n");
> >> + kmsg_dump(KMSG_DUMP_OOPS);
> >> + } else if (val == 1) {
> >> + char *null_pointer = NULL;
> >> +
> >> + pr_info("Test panic screen using NULL pointer dereference\n");
> >> + *null_pointer = 1;
> >> + } else {
> >> + return -EINVAL;
> >> + }
> >
> > This isn't quite what I had in mind, since it still kills the kernel (like
> > sysrq-trigger).
>
> If val == 0, it doesn't kill the kernel, it only dumps the kernel log.
> And it doesn't taint the kernel either.
>
> > Instead what I had in mind is to recreate the worst
> > possible panic context as much as feasible (disabling interrupts should be
> > a good start, maybe we can even do an nmi callback), and then call our
> > panic implementation. That way we can test the panic handler in a
> > non-destructive way (i.e. aside from last dmesg lines printed to the
> > screen nothing bad happens to the kernel: No real panic, no oops, no
> > tainting).
>
> The interrupt case I can do, nmi I have no idea.
>
I agree too. Disabling interrupts + CONFIG_DEBUG_ATOMIC_SLEEP
would be a nice non-destructive test-case emulation.
thanks!
--
darwi
http://darwish.chasingpointers.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add support for panic message output
Hi,
On Tue, Mar 12, 2019 at 11:58:10AM +0100, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 11.03.2019 20.23, skrev Daniel Vetter:
> > > On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
[...]
> > >> +}
> > >> +
> > >> +static struct kmsg_dumper drm_panic_kmsg_dumper = {
> > >> +.dump = drm_panic_kmsg_dump,
> > >> +.max_reason = KMSG_DUMP_PANIC,
> > >> +};
> > >> +
> > >> +static ssize_t drm_panic_file_panic_write(struct file *file,
> > >> + const char __user *user_buf,
> > >> + size_t count, loff_t *ppos)
> > >> +{
> > >> +unsigned long long val;
> > >> +char buf[24];
> > >> +size_t size;
> > >> +ssize_t ret;
> > >> +
> > >> +size = min(sizeof(buf) - 1, count);
> > >> +if (copy_from_user(buf, user_buf, size))
> > >> +return -EFAULT;
> > >> +
> > >> +buf[size] = '\0';
> > >> +ret = kstrtoull(buf, 0, );
> > >> +if (ret)
> > >> +return ret;
> > >> +
> > >> +drm_panic_kmsg_dumper.max_reason = KMSG_DUMP_OOPS;
> > >> +wmb();
> > >> +
> > >> +/* Do a real test with: echo c > /proc/sysrq-trigger */
> > >> +
> > >> +if (val == 0) {
> > >> +pr_info("Test panic screen using kmsg_dump(OOPS)\n");
> > >> +kmsg_dump(KMSG_DUMP_OOPS);
> > >> +} else if (val == 1) {
> > >> +char *null_pointer = NULL;
> > >> +
> > >> +pr_info("Test panic screen using NULL pointer
> > >> dereference\n");
> > >> +*null_pointer = 1;
> > >> +} else {
> > >> +return -EINVAL;
> > >> +}
>> > >
> > > This isn't quite what I had in mind, since it still kills the kernel (like
> > > sysrq-trigger).
> >
> > If val == 0, it doesn't kill the kernel, it only dumps the kernel log.
> > And it doesn't taint the kernel either.
>
> Ah I didn't realize that. Sounds like a good option to keep.
>
> > > Instead what I had in mind is to recreate the worst
> > > possible panic context as much as feasible (disabling interrupts should be
> > > a good start, maybe we can even do an nmi callback), and then call our
> > > panic implementation. That way we can test the panic handler in a
> > > non-destructive way (i.e. aside from last dmesg lines printed to the
> > > screen nothing bad happens to the kernel: No real panic, no oops, no
> > > tainting).
> >
> > The interrupt case I can do, nmi I have no idea.
>
> I just read the printk nmi code again and it looks like there's now even
> more special handling for issues happening in nmi context, so we should
> never see an oops from nmi context. So local_irq_disable() wrapping should
> be good enough for testing.
> -Daniel
>
Hmmm, John is on a mission to change that soon:
-
https://lore.kernel.org/lkml/20190212143003.48446-1-john.ogn...@linutronix.de
- https://lwn.net/Articles/780556
A v2 is on the way, and there's a lot of interest from different
groups, including RT, to get that in.
So I guess it would be nice to cover NMI contexts from the start,
not necessarily from a non-destructive CI testing perspective, but
at least while doing normal tests and code reviews.
(Is it possible to do non-destructive NMI tests? I don't know..)
thanks!
--
darwi
http://darwish.chasingpointers.com
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] drm/rockchip: fix fb references in async update
On Wed, Mar 13, 2019 at 12:52 AM Boris Brezillon
wrote:
>
> On Tue, 12 Mar 2019 12:34:45 -0300
> Helen Koike wrote:
>
> > On 3/12/19 3:34 AM, Boris Brezillon wrote:
> > > On Mon, 11 Mar 2019 23:21:59 -0300
> > > Helen Koike wrote:
> > >
> > >> In the case of async update, modifications are done in place, i.e. in the
> > >> current plane state, so the new_state is prepared and the new_state is
> > >> cleanup up (instead of the old_state, diferrently on what happen in a
> > >
> > > ^ cleaned up ^ differently (but maybe
> > > "unlike what happens" is more appropriate here).
> > >
> > >> normal sync update).
> > >> To cleanup the old_fb properly, it needs to be placed in the new_state
> > >> in the end of async_update, so cleanup call will unreference the old_fb
> > >> correctly.
> > >>
> > >> Also, the previous code had a:
> > >>
> > >>plane_state = plane->funcs->atomic_duplicate_state(plane);
> > >>...
> > >>swap(plane_state, plane->state);
> > >>
> > >>if (plane->state->fb && plane->state->fb != new_state->fb) {
> > >>...
> > >>}
> > >>
> > >> Which was wrong, as the fb were just assigned to be equal, so this if
> > >> statement nevers evaluates to true.
> > >>
> > >> Another details is that the function drm_crtc_vblank_get() can only be
> > >> called when vop->is_enabled is true, otherwise it has no effect and
> > >> trows a WARN_ON().
> > >>
> > >> Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
> > >> fb and pus the old fb) is not required, as it is taken care by
> > >> drm_mode_cursor_universal() when calling
> > >> drm_atomic_helper_update_plane().
> > >>
> > >> Signed-off-by: Helen Koike
> > >>
> > >> ---
> > >> Hello,
> > >>
> > >> I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
> > >> kms_cursor_legacy and I didn't see any regressions.
> > >>
> > >> Changes in v2: None
> > >>
> > >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 -
> > >> 1 file changed, 24 insertions(+), 18 deletions(-)
> > >>
> > >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > >> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > >> index c7d4c6073ea5..a1ee8c156a7b 100644
> > >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > >> @@ -912,30 +912,31 @@ static void vop_plane_atomic_async_update(struct
> > >> drm_plane *plane,
> > >> struct drm_plane_state *new_state)
> > >> {
> > >>struct vop *vop = to_vop(plane->state->crtc);
> > >> - struct drm_plane_state *plane_state;
> > >> + struct drm_framebuffer *old_fb = plane->state->fb;
> > >>
> > >> - plane_state = plane->funcs->atomic_duplicate_state(plane);
> > >> - plane_state->crtc_x = new_state->crtc_x;
> > >> - plane_state->crtc_y = new_state->crtc_y;
> > >> - plane_state->crtc_h = new_state->crtc_h;
> > >> - plane_state->crtc_w = new_state->crtc_w;
> > >> - plane_state->src_x = new_state->src_x;
> > >> - plane_state->src_y = new_state->src_y;
> > >> - plane_state->src_h = new_state->src_h;
> > >> - plane_state->src_w = new_state->src_w;
> > >> -
> > >> - if (plane_state->fb != new_state->fb)
> > >> - drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
> > >> -
> > >> - swap(plane_state, plane->state);
> > >> -
> > >> - if (plane->state->fb && plane->state->fb != new_state->fb) {
> > >> + /*
> > >> + * A scanout can still be occurring, so we can't drop the reference to
> > >> + * the old framebuffer. To solve this we get a reference to old_fb and
> > >> + * set a worker to release it later.
> > >
> > > Hm, doesn't look like an async update to me if we have to wait for the
> > > next VBLANK to happen to get the new content on the screen. Maybe we
> > > should reject async updates when old_fb != new_fb in the rk
> > > ->async_check() hook.
> >
> > Unless I am misunderstanding this, we don't wait here, we just grab a
> > reference to the fb in case it is being still used by the hw, so it
> > doesn't get released prematurely.
>
> I was just reacting to the comment that says the new FB should stay
> around until the next VBLANK event happens. If the FB must stay around
> that probably means the HW is still using, which made me wonder if this
> HW actually supports async update (where async means "update now and
> don't care about about tearing"). Or maybe it takes some time to switch
> to the new FB and waiting for the next VBLANK to release the old FB was
> an easy solution to not wait for the flip to actually happen in
> ->async_update() (which is kind of a combination of async+non-blocking).
The hardware switches framebuffers on vblank, so whatever framebuffer
is currently being scanned out from needs to stay there until the
hardware switches to the new one in shadow registers. If that doesn't
happen, you get IOMMU faults and the display controller stops working
since we don't have any fault handling
[PATCH] drm/dp: Set the connector's TILE property even for DP SST connectors
Current driver sets the tile property only for DP MST connectors.
However there are some tiled displays where each SST connector
carries a single tile. So we need to attach this property object
for every connector and set it for every connector (DP SST and MST).
Plus since the tile information is obtained as a result of EDID
parsing, the best place to update tile property is where we update
edid property.
Also now we dont need to explicitly set this now for MST connectors.
This has been tested with xrandr --props and modetest and verified
that TILE property is exposed correctly.
Cc: Dave Airlie
Cc: Jani Nikula
Cc: Daniel Vetter
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/drm_connector.c | 13 -
drivers/gpu/drm/drm_dp_mst_topology.c | 1 -
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 07d65a16c623..2355124849db 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -245,6 +245,7 @@ int drm_connector_init(struct drm_device *dev,
INIT_LIST_HEAD(>modes);
mutex_init(>mutex);
connector->edid_blob_ptr = NULL;
+ connector->tile_blob_ptr = NULL;
connector->status = connector_status_unknown;
connector->display_info.panel_orientation =
DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
@@ -272,6 +273,9 @@ int drm_connector_init(struct drm_device *dev,
drm_object_attach_property(>base,
config->non_desktop_property,
0);
+ drm_object_attach_property(>base,
+ config->tile_property,
+ 0);
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base,
config->prop_crtc_id, 0);
@@ -1712,6 +1716,8 @@ EXPORT_SYMBOL(drm_connector_set_path_property);
* This looks up the tile information for a connector, and creates a
* property for userspace to parse if it exists. The property is of
* the form of 8 integers using ':' as a separator.
+ * This is used for dual port tiled displays with DisplayPort SST
+ * or DisplayPort MST connectors.
*
* Returns:
* Zero on success, errno on failure.
@@ -1755,6 +1761,9 @@ EXPORT_SYMBOL(drm_connector_set_tile_property);
*
* This function creates a new blob modeset object and assigns its id to the
* connector's edid property.
+ * Since we also parse tile information from EDID's displayID block, we also
+ * set the connector's tile property here. See
drm_connector_set_tile_property()
+ * for more details.
*
* Returns:
* Zero on success, negative errno on failure.
@@ -1796,7 +1805,9 @@ int drm_connector_update_edid_property(struct
drm_connector *connector,
edid,
>base,
dev->mode_config.edid_property);
- return ret;
+ if (ret)
+ return ret;
+ return drm_connector_set_tile_property(connector);
}
EXPORT_SYMBOL(drm_connector_update_edid_property);
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index dc7ac0c60547..c630ed157994 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -3022,7 +3022,6 @@ struct edid *drm_dp_mst_get_edid(struct drm_connector
*connector, struct drm_dp_
edid = drm_edid_duplicate(port->cached_edid);
else {
edid = drm_get_edid(connector, >aux.ddc);
- drm_connector_set_tile_property(connector);
}
port->has_audio = drm_detect_monitor_audio(edid);
drm_dp_mst_topology_put_port(port);
--
2.19.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109924] WARNING: CPU: 3 PID: 4373 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:788 dm_suspend+0x53/0x60
https://bugs.freedesktop.org/show_bug.cgi?id=109924 Javier Fernandez changed: What|Removed |Added Hardware|Other |x86-64 (AMD64) OS|All |Linux (All) -- 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 v5 07/19] media: vsp1: dl: Support one-shot entries in the display list
Hi Liviu, On Fri, Mar 08, 2019 at 03:02:39PM +, Liviu Dudau wrote: > On Fri, Mar 08, 2019 at 02:46:08PM +0200, Laurent Pinchart wrote: > > On Thu, Mar 07, 2019 at 04:31:40PM +, Liviu Dudau wrote: > >> On Thu, Mar 07, 2019 at 03:48:23PM +0200, Laurent Pinchart wrote: > >>> On Thu, Mar 07, 2019 at 11:52:18AM +, Liviu Dudau wrote: > On Wed, Mar 06, 2019 at 08:01:53PM +0200, Laurent Pinchart wrote: > > On Wed, Mar 06, 2019 at 02:20:51PM +, Liviu Dudau wrote: > >> On Wed, Mar 06, 2019 at 01:14:40AM +0200, Laurent Pinchart wrote: > > > > [snip] > > > >>> We thus have three states for an atomic commit: > >>> > >>> - active, where the corresponding registers list address has been > >>> written to the hardware, and processed > >>> > >>> - queued, where the corresponding registers list address has been > >>> written to the hardware but not processed yet > >>> > >>> - pending, where the corresponding registers list address hasn't been > >>> written to the hardware yet > >>> > >>> The status bit mentioned above allows us to tell if a list exists in > >>> the > >>> queued state. > >>> > >>> At frame end time, if the status bit is set, we have potentially lost > >>> the race between writing the new registers list and the frame end > >>> interrupt, so we wait for one more vblank. Otherwise, if a list was > >>> queued, we move it to the active state, and retire the active list. > >>> If a > >>> list was pending, we write its address to the hardware, and move it to > >>> the queued state. > > It looks to me like the moving of the pending state into queued state is > your > opportunity to also in-place modify the writeback registers if the state > does > not have its own writeback request. > >>> > >>> Moving from pending to queued means the pointer has been given to the > >>> hardware, but not processed yet. I need to wait until the commit that > >>> enables writeback is fully processed before modifying it in-place to > >>> disable writeback, and that's at the frame start following the move from > >>> the queued state to the active state. > >> > >> I'm not attempting to (re)write your driver, only to explain my thinking > >> process in > >> a way that is easiest for me: > > > > I wouldn't mind if you attempted to rewrite the driver if it ended up in > > a better state :-) > > > >> 1. driver prepares a new commit that might have a writeback and sets the > >> pointer register to the new address. It then marks the commit as queued. > >> > >> (optional) 2. driver receives a new commit that is marked as pending > >> > >> 3. end-of-frame interrupt arrives > >> a. HW reads the new address and programs a DMA transfer to update > >> registers. > >> b. driver reads the status bit and waits until status == 0. > > > > Step b is not needed as the status bit is set to 0 as soon as the > > hardware starts the DMA. > > OK, however because I'm not sure when the driver's interrupt handler > is called, I was trying to be safe and make sure the driver can > proceed. > > >> c. driver marks queued commit as active and looks if it has any > >> pending commits > >> - if yes, it looks at the pending commit if it has a writeback > >> request > >>- if no, it updates the pending commit to write the register(s) > >> that disable writeback > >>- moves pending commit to queued > >> - if no, then it copies active commit and disables writeback. (*) > > > > Pending commits are very rare. Userspace will usually queue the next > > commit when it receives notification of completion of the previous > > commit, so the next commit will arrive after vblank, with a single > > commit per frame interval. At that point there will be an active commit, > > and no queued commit, and the new commit will become the queued commit. > > The "no" case will thus be hit in the vast majority of cases, preventing > > the next userspace commit to be queued for the same frame, delaying it > > by one frame, and thus halving the frame rate :-( > > I'll guess you're referring to the (*) case of "no", but I'm not sure how the > next > userspace commit will be delayed . wait a bit a light bulb turned on > somewhere in the darkness of my mind see below. > > >> d. driver signals vblank and any previous writebacks that might have > >> been programmed > >> by the previously active commit > >> > >> 4. > >> 5. profit! > >> > >> > >> (*) depending on how the HW behaves, it might be enough to create a stub > >> commit that only disables the writeback, with no other update. > > > > A stub is enough, there's no need to reprogram everything. > > Right, in that case, can you not look at the queued commit when the next > userspace > commit comes in and if it is the stub commit overwrite it with your new > commit as > if
[PATCH v8] drm: Add library for shmem backed GEM objects
From: Noralf Trønnes
This adds a library for shmem backed GEM objects.
v8:
- export drm_gem_shmem_create_with_handle
- call mapping_set_gfp_mask to set default zone to GFP_HIGHUSER
- Add helper drm_gem_shmem_get_pages_sgt()
v7:
- Use write-combine for mmap instead. This is the more common
case. (robher)
v6:
- Fix uninitialized variable issue in an error path (anholt).
- Add a drm_gem_shmem_vm_open() to the fops to get proper refcounting
of the pages (anholt).
v5:
- Drop drm_gem_shmem_prime_mmap() (Daniel Vetter)
- drm_gem_shmem_mmap(): Subtract drm_vma_node_start() to get the real
vma->vm_pgoff
- drm_gem_shmem_fault(): Use vmf->pgoff now that vma->vm_pgoff is correct
v4:
- Drop cache modes (Thomas Hellstrom)
- Add a GEM attached vtable
v3:
- Grammar (Sam Ravnborg)
- s/drm_gem_shmem_put_pages_unlocked/drm_gem_shmem_put_pages_locked/
(Sam Ravnborg)
- Add debug output in error path (Sam Ravnborg)
Signed-off-by: Noralf Trønnes
Signed-off-by: Eric Anholt
Signed-off-by: Rob Herring
---
Documentation/gpu/drm-kms-helpers.rst | 12 +
drivers/gpu/drm/Kconfig| 6 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_gem_shmem_helper.c | 625 +
include/drm/drm_gem_shmem_helper.h | 159 +++
5 files changed, 803 insertions(+)
create mode 100644 drivers/gpu/drm/drm_gem_shmem_helper.c
create mode 100644 include/drm/drm_gem_shmem_helper.h
diff --git a/Documentation/gpu/drm-kms-helpers.rst
b/Documentation/gpu/drm-kms-helpers.rst
index 17ca7f8bf3d3..58b375e47615 100644
--- a/Documentation/gpu/drm-kms-helpers.rst
+++ b/Documentation/gpu/drm-kms-helpers.rst
@@ -369,3 +369,15 @@ Legacy CRTC/Modeset Helper Functions Reference
.. kernel-doc:: drivers/gpu/drm/drm_crtc_helper.c
:export:
+
+SHMEM GEM Helper Reference
+==
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
+ :doc: overview
+
+.. kernel-doc:: include/drm/drm_gem_shmem_helper.h
+ :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gem_shmem_helper.c
+ :export:
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index bd943a71756c..febdc102b75c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -173,6 +173,12 @@ config DRM_KMS_CMA_HELPER
help
Choose this if you need the KMS CMA helper functions
+config DRM_GEM_SHMEM_HELPER
+ bool
+ depends on DRM
+ help
+ Choose this if you need the GEM shmem helper functions
+
config DRM_VM
bool
depends on DRM && MMU
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 1ac55c65eac0..7476ed945e30 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -25,6 +25,7 @@ drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
+drm-$(CONFIG_DRM_GEM_SHMEM_HELPER) += drm_gem_shmem_helper.o
drm-$(CONFIG_PCI) += ati_pcigart.o
drm-$(CONFIG_DRM_PANEL) += drm_panel.o
drm-$(CONFIG_OF) += drm_of.o
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c
b/drivers/gpu/drm/drm_gem_shmem_helper.c
new file mode 100644
index ..3750a982aaf6
--- /dev/null
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -0,0 +1,625 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright 2018 Noralf Trønnes
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+/**
+ * DOC: overview
+ *
+ * This library provides helpers for GEM objects backed by shmem buffers
+ * allocated using anonymous pageable memory.
+ */
+
+static const struct drm_gem_object_funcs drm_gem_shmem_funcs = {
+ .free = drm_gem_shmem_free_object,
+ .print_info = drm_gem_shmem_print_info,
+ .pin = drm_gem_shmem_pin,
+ .unpin = drm_gem_shmem_unpin,
+ .get_sg_table = drm_gem_shmem_get_sg_table,
+ .vmap = drm_gem_shmem_vmap,
+ .vunmap = drm_gem_shmem_vunmap,
+ .vm_ops = _gem_shmem_vm_ops,
+};
+
+/**
+ * drm_gem_shmem_create - Allocate an object with the given size
+ * @dev: DRM device
+ * @size: Size of the object to allocate
+ *
+ * This function creates a shmem GEM object.
+ *
+ * Returns:
+ * A struct drm_gem_shmem_object * on success or an ERR_PTR()-encoded negative
+ * error code on failure.
+ */
+struct drm_gem_shmem_object *drm_gem_shmem_create(struct drm_device *dev,
size_t size)
+{
+ struct drm_gem_shmem_object *shmem;
+ struct drm_gem_object *obj;
+ int ret;
+
+ size = PAGE_ALIGN(size);
+
+ if (dev->driver->gem_create_object)
+ obj = dev->driver->gem_create_object(dev, size);
+ else
+ obj = kzalloc(sizeof(*shmem), GFP_KERNEL);
+ if (!obj)
+ return ERR_PTR(-ENOMEM);
+
+ if (!obj->funcs)
+ obj->funcs = _gem_shmem_funcs;
+
+ ret = drm_gem_object_init(dev, obj, size);
+ if (ret)
+
[PATCH v6 2/3] drm/i915: Refactor icl_is_hdr_plane
Change the api in order to enable callers that can't supply a valid
intel_plane pointer, as would be the case prior to calling
drm_universal_plane_init.
v4:
- Rename variables and move a declaration (Ville)
v6:
- Rebase and fix merge conflict
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kevin Strasser
Reviewed-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Reviewed-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_atomic.c | 3 ++-
drivers/gpu/drm/i915/intel_display.c | 7 +--
drivers/gpu/drm/i915/intel_drv.h | 7 ---
drivers/gpu/drm/i915/intel_sprite.c | 6 +++---
4 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index da419e1..b844e88 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -235,10 +235,11 @@ static void intel_atomic_setup_scaler(struct
intel_crtc_scaler_state *scaler_sta
if (plane_state && plane_state->base.fb &&
plane_state->base.fb->format->is_yuv &&
plane_state->base.fb->format->num_planes > 1) {
+ struct intel_plane *plane =
to_intel_plane(plane_state->base.plane);
if (IS_GEN(dev_priv, 9) &&
!IS_GEMINILAKE(dev_priv)) {
mode = SKL_PS_SCALER_MODE_NV12;
- } else if
(icl_is_hdr_plane(to_intel_plane(plane_state->base.plane))) {
+ } else if (icl_is_hdr_plane(dev_priv, plane->id)) {
/*
* On gen11+'s HDR planes we only use the scaler for
* scaling. They have a dedicated chroma upsampler, so
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index d11cec1..60fbe3a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3781,6 +3781,8 @@ u32 glk_plane_color_ctl_crtc(const struct
intel_crtc_state *crtc_state)
u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state)
{
+ struct drm_i915_private *dev_priv =
+ to_i915(plane_state->base.plane->dev);
const struct drm_framebuffer *fb = plane_state->base.fb;
struct intel_plane *plane = to_intel_plane(plane_state->base.plane);
u32 plane_color_ctl = 0;
@@ -3788,7 +3790,7 @@ u32 glk_plane_color_ctl(const struct intel_crtc_state
*crtc_state,
plane_color_ctl |= PLANE_COLOR_PLANE_GAMMA_DISABLE;
plane_color_ctl |= glk_plane_color_ctl_alpha(plane_state);
- if (fb->format->is_yuv && !icl_is_hdr_plane(plane)) {
+ if (fb->format->is_yuv && !icl_is_hdr_plane(dev_priv, plane->id)) {
if (plane_state->base.color_encoding == DRM_COLOR_YCBCR_BT709)
plane_color_ctl |=
PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709;
else
@@ -5101,13 +5103,14 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
{
struct intel_plane *intel_plane =
to_intel_plane(plane_state->base.plane);
+ struct drm_i915_private *dev_priv = to_i915(intel_plane->base.dev);
struct drm_framebuffer *fb = plane_state->base.fb;
int ret;
bool force_detach = !fb || !plane_state->base.visible;
bool need_scaler = false;
/* Pre-gen11 and SDR planes always need a scaler for planar formats. */
- if (!icl_is_hdr_plane(intel_plane) &&
+ if (!icl_is_hdr_plane(dev_priv, intel_plane->id) &&
fb && is_planar_yuv_format(fb->format->format))
need_scaler = true;
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 40ebc94..a26c2cb 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -2436,12 +2436,13 @@ static inline bool icl_is_nv12_y_plane(enum plane_id id)
return false;
}
-static inline bool icl_is_hdr_plane(struct intel_plane *plane)
+static inline bool icl_is_hdr_plane(struct drm_i915_private *dev_priv,
+ enum plane_id plane_id)
{
- if (INTEL_GEN(to_i915(plane->base.dev)) < 11)
+ if (INTEL_GEN(dev_priv) < 11)
return false;
- return plane->id < PLANE_SPRITE2;
+ return plane_id < PLANE_SPRITE2;
}
/* intel_tv.c */
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 89d7bf7..622669f 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -349,7 +349,7 @@ skl_program_scaler(struct intel_plane *plane,
/* TODO: handle sub-pixel coordinates */
if (is_planar_yuv_format(plane_state->base.fb->format->format) &&
- !icl_is_hdr_plane(plane)) {
+ !icl_is_hdr_plane(dev_priv, plane->id)) {
y_hphase =
[PATCH v6 3/3] drm/i915/icl: Implement half float formats
64 bpp half float formats are supported on hdr planes only and are subject
to the following restrictions:
* 90/270 rotation not supported
* Yf Tiling not supported
* Frame Buffer Compression not supported
* Color Keying not supported
v2:
- Drop handling pixel normalize register
- Don't use icl_is_hdr_plane too early
v3:
- Use refactored icl_is_hdr_plane (Ville)
- Use u32 instead of uint32_t (Ville)
v6:
- Rebase and fix merge conflicts
- Reorganize switch statements to keep RGB grouped separately from YUV
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kevin Strasser
Reviewed-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Reviewed-by: Adam Jackson
---
drivers/gpu/drm/i915/intel_display.c | 22 +++
drivers/gpu/drm/i915/intel_sprite.c | 72 ++--
2 files changed, 91 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 60fbe3a..eaedf91 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2680,6 +2680,18 @@ int skl_format_to_fourcc(int format, bool rgb_order,
bool alpha)
return DRM_FORMAT_XBGR2101010;
else
return DRM_FORMAT_XRGB2101010;
+ case PLANE_CTL_FORMAT_XRGB_16161616F:
+ if (rgb_order) {
+ if (alpha)
+ return DRM_FORMAT_ABGR16161616F;
+ else
+ return DRM_FORMAT_XBGR16161616F;
+ } else {
+ if (alpha)
+ return DRM_FORMAT_ARGB16161616F;
+ else
+ return DRM_FORMAT_XRGB16161616F;
+ }
}
}
@@ -3575,6 +3587,12 @@ static u32 skl_plane_ctl_format(u32 pixel_format)
return PLANE_CTL_FORMAT_XRGB_2101010;
case DRM_FORMAT_XBGR2101010:
return PLANE_CTL_ORDER_RGBX | PLANE_CTL_FORMAT_XRGB_2101010;
+ case DRM_FORMAT_XBGR16161616F:
+ case DRM_FORMAT_ABGR16161616F:
+ return PLANE_CTL_FORMAT_XRGB_16161616F | PLANE_CTL_ORDER_RGBX;
+ case DRM_FORMAT_XRGB16161616F:
+ case DRM_FORMAT_ARGB16161616F:
+ return PLANE_CTL_FORMAT_XRGB_16161616F;
case DRM_FORMAT_YUYV:
return PLANE_CTL_FORMAT_YUV422 | PLANE_CTL_YUV422_YUYV;
case DRM_FORMAT_YVYU:
@@ -5143,6 +5161,10 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
case DRM_FORMAT_ARGB:
case DRM_FORMAT_XRGB2101010:
case DRM_FORMAT_XBGR2101010:
+ case DRM_FORMAT_XBGR16161616F:
+ case DRM_FORMAT_ABGR16161616F:
+ case DRM_FORMAT_XRGB16161616F:
+ case DRM_FORMAT_ARGB16161616F:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_YVYU:
case DRM_FORMAT_UYVY:
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index 622669f..e00559d 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1508,8 +1508,6 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
/*
* 90/270 is not allowed with RGB64 16:16:16:16 and
* Indexed 8-bit. RGB 16-bit 5:6:5 is allowed gen11 onwards.
-* TBD: Add RGB64 case once its added in supported format
-* list.
*/
switch (fb->format->format) {
case DRM_FORMAT_RGB565:
@@ -1517,6 +1515,10 @@ static int skl_plane_check_fb(const struct
intel_crtc_state *crtc_state,
break;
/* fall through */
case DRM_FORMAT_C8:
+ case DRM_FORMAT_XRGB16161616F:
+ case DRM_FORMAT_XBGR16161616F:
+ case DRM_FORMAT_ARGB16161616F:
+ case DRM_FORMAT_ABGR16161616F:
DRM_DEBUG_KMS("Unsupported pixel format %s for
90/270!\n",
drm_get_format_name(fb->format->format,
_name));
@@ -1837,6 +1839,31 @@ static const uint32_t icl_plane_formats[] = {
DRM_FORMAT_Y416,
};
+static const uint32_t icl_hdr_plane_formats[] = {
+ DRM_FORMAT_C8,
+ DRM_FORMAT_RGB565,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_XBGR,
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_ABGR,
+ DRM_FORMAT_XRGB2101010,
+ DRM_FORMAT_XBGR2101010,
+ DRM_FORMAT_XRGB16161616F,
+ DRM_FORMAT_XBGR16161616F,
+ DRM_FORMAT_ARGB16161616F,
+ DRM_FORMAT_ABGR16161616F,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_YVYU,
+ DRM_FORMAT_UYVY,
+ DRM_FORMAT_VYUY,
+ DRM_FORMAT_Y210,
+ DRM_FORMAT_Y212,
+ DRM_FORMAT_Y216,
[PATCH v6 0/3] Support 64 bpp half float formats
This series defines new formats and adds implementation to the i915 driver. Since posting v1 I have removed the pixel normalize property, as it's not needed for basic functionality. Also, I have been working on adding support to userspace, but we can't land any patches until drm_fourcc.h has been updated here. Mesa series: https://patchwork.freedesktop.org/series/54759/ IGT series: https://patchwork.freedesktop.org/series/57473/ My libdrm branch with fp16 coverage added to modetest: https://gitlab.freedesktop.org/strassek/drm/commits/fp16 My kmscube branch: https://gitlab.freedesktop.org/strassek/kmscube/commits/fp16 Kevin Strasser (3): drm/fourcc: Add 64 bpp half float formats drm/i915: Refactor icl_is_hdr_plane drm/i915/icl: Implement half float formats drivers/gpu/drm/drm_fourcc.c | 4 ++ drivers/gpu/drm/i915/intel_atomic.c | 3 +- drivers/gpu/drm/i915/intel_display.c | 29 +- drivers/gpu/drm/i915/intel_drv.h | 7 ++-- drivers/gpu/drm/i915/intel_sprite.c | 78 +--- include/uapi/drm/drm_fourcc.h| 11 + 6 files changed, 120 insertions(+), 12 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/3] drm/fourcc: Add 64 bpp half float formats
Add 64 bpp 16:16:16:16 half float pixel formats. Each 16 bit component is
formatted in IEEE-754 half-precision float (binary16) 1:5:10
MSb-sign:exponent:fraction form.
This patch attempts to address the feedback provided when 2 of these
formats were previosly proposed:
https://patchwork.kernel.org/patch/10072545/
v2:
- Fixed cpp (Ville)
- Added detail pixel formatting (Ville)
- Ordered formats in header (Ville)
v5:
- .depth should be 0 for new formats (Maarten)
Cc: Tina Zhang
Cc: Uma Shankar
Cc: Shashank Sharma
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Kevin Strasser
Reviewed-by: Ville Syrjälä
Reviewed-by: Maarten Lankhorst
Reviewed-by: Adam Jackson
---
drivers/gpu/drm/drm_fourcc.c | 4
include/uapi/drm/drm_fourcc.h | 11 +++
2 files changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index 3684c49..b914b16 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -198,6 +198,10 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_ABGR,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_RGBA,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_BGRA,.depth = 32,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_XRGB16161616F, .depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_XBGR16161616F, .depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1 },
+ { .format = DRM_FORMAT_ARGB16161616F, .depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
+ { .format = DRM_FORMAT_ABGR16161616F, .depth = 0,
.num_planes = 1, .cpp = { 8, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_RGB888_A8, .depth = 32,
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_BGR888_A8, .depth = 32,
.num_planes = 2, .cpp = { 3, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
{ .format = DRM_FORMAT_XRGB_A8, .depth = 32,
.num_planes = 2, .cpp = { 4, 1, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index dc99e7f..5010b47 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -144,6 +144,17 @@ extern "C" {
#define DRM_FORMAT_RGBA1010102 fourcc_code('R', 'A', '3', '0') /* [31:0]
R:G:B:A 10:10:10:2 little endian */
#define DRM_FORMAT_BGRA1010102 fourcc_code('B', 'A', '3', '0') /* [31:0]
B:G:R:A 10:10:10:2 little endian */
+/*
+ * Floating point 64bpp RGB
+ * IEEE 754-2008 binary16 half-precision float
+ * [15:0] sign:exponent:mantissa 1:5:10
+ */
+#define DRM_FORMAT_XRGB16161616F fourcc_code('X', 'R', '4', 'H') /* [63:0]
x:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_XBGR16161616F fourcc_code('X', 'B', '4', 'H') /* [63:0]
x:B:G:R 16:16:16:16 little endian */
+
+#define DRM_FORMAT_ARGB16161616F fourcc_code('A', 'R', '4', 'H') /* [63:0]
A:R:G:B 16:16:16:16 little endian */
+#define DRM_FORMAT_ABGR16161616F fourcc_code('A', 'B', '4', 'H') /* [63:0]
A:B:G:R 16:16:16:16 little endian */
+
/* packed YCbCr */
#define DRM_FORMAT_YUYVfourcc_code('Y', 'U', 'Y', 'V') /*
[31:0] Cr0:Y1:Cb0:Y0 8:8:8:8 little endian */
#define DRM_FORMAT_YVYUfourcc_code('Y', 'V', 'Y', 'U') /*
[31:0] Cb0:Y1:Cr0:Y0 8:8:8:8 little endian */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 18/18] drm: rcar-du: Add writeback support for R-Car Gen3
Implement writeback support for R-Car Gen3 by exposing writeback
connectors. Behind the scene the calls are forwarded to the VSP
backend.
Using writeback connectors will allow implemented writeback support for
R-Car Gen2 with a consistent API if desired.
Signed-off-by: Laurent Pinchart
---
Changes since v5:
- Skip writeback connector when configuring output routing
- Implement writeback connector atomic state operations
---
drivers/gpu/drm/rcar-du/Kconfig | 4 +
drivers/gpu/drm/rcar-du/Makefile| 3 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +-
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 7 +-
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 12 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 5 +
drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 243
drivers/gpu/drm/rcar-du/rcar_du_writeback.h | 39
8 files changed, 317 insertions(+), 3 deletions(-)
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.c
create mode 100644 drivers/gpu/drm/rcar-du/rcar_du_writeback.h
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 7c36e2777a15..1529849e217e 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -36,3 +36,7 @@ config DRM_RCAR_VSP
depends on VIDEO_RENESAS_VSP1=y || (VIDEO_RENESAS_VSP1 && DRM_RCAR_DU=m)
help
Enable support to expose the R-Car VSP Compositor as KMS planes.
+
+config DRM_RCAR_WRITEBACK
+ bool
+ default y if ARM64
diff --git a/drivers/gpu/drm/rcar-du/Makefile b/drivers/gpu/drm/rcar-du/Makefile
index 2a3b8d7972b5..6c2ed9c46467 100644
--- a/drivers/gpu/drm/rcar-du/Makefile
+++ b/drivers/gpu/drm/rcar-du/Makefile
@@ -4,7 +4,7 @@ rcar-du-drm-y := rcar_du_crtc.o \
rcar_du_encoder.o \
rcar_du_group.o \
rcar_du_kms.o \
-rcar_du_plane.o
+rcar_du_plane.o \
rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS)+= rcar_du_of.o \
rcar_du_of_lvds_r8a7790.dtb.o \
@@ -13,6 +13,7 @@ rcar-du-drm-$(CONFIG_DRM_RCAR_LVDS) += rcar_du_of.o \
rcar_du_of_lvds_r8a7795.dtb.o \
rcar_du_of_lvds_r8a7796.dtb.o
rcar-du-drm-$(CONFIG_DRM_RCAR_VSP) += rcar_du_vsp.o
+rcar-du-drm-$(CONFIG_DRM_RCAR_WRITEBACK) += rcar_du_writeback.o
obj-$(CONFIG_DRM_RCAR_DU) += rcar-du-drm.o
obj-$(CONFIG_DRM_RCAR_DW_HDMI) += rcar_dw_hdmi.o
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index 96175d48a902..a95cf6bab4e0 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -645,8 +645,13 @@ static int rcar_du_crtc_atomic_check(struct drm_crtc *crtc,
rstate->outputs = 0;
drm_for_each_encoder_mask(encoder, crtc->dev, state->encoder_mask) {
- struct rcar_du_encoder *renc = to_rcar_encoder(encoder);
+ struct rcar_du_encoder *renc;
+ /* Skip the writeback encoder. */
+ if (encoder->encoder_type == DRM_MODE_ENCODER_VIRTUAL)
+ continue;
+
+ renc = to_rcar_encoder(encoder);
rstate->outputs |= BIT(renc->output);
}
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index c478953be092..92f7d5f3ff80 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -15,6 +15,7 @@
#include
#include
+#include
#include
@@ -39,6 +40,7 @@ struct rcar_du_vsp;
* @group: CRTC group this CRTC belongs to
* @vsp: VSP feeding video to this CRTC
* @vsp_pipe: index of the VSP pipeline feeding video to this CRTC
+ * @writeback: the writeback connector
*/
struct rcar_du_crtc {
struct drm_crtc crtc;
@@ -65,9 +67,12 @@ struct rcar_du_crtc {
const char *const *sources;
unsigned int sources_count;
+
+ struct drm_writeback_connector writeback;
};
-#define to_rcar_crtc(c)container_of(c, struct rcar_du_crtc, crtc)
+#define to_rcar_crtc(c)container_of(c, struct rcar_du_crtc,
crtc)
+#define wb_to_rcar_crtc(c) container_of(c, struct rcar_du_crtc, writeback)
/**
* struct rcar_du_crtc_state - Driver-specific CRTC state
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index 999440c7b258..c729f048626e 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -24,6 +24,7 @@
#include "rcar_du_kms.h"
#include "rcar_du_regs.h"
#include "rcar_du_vsp.h"
+#include "rcar_du_writeback.h"
/*
-
* Format helpers
@@ -662,6 +663,17 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu)
encoder->possible_clones = (1 <<
[PATCH v6 16/18] drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structure
The mapping between DRM and V4L2 fourcc's is stored in two separate
tables in rcar_du_vsp.c. In order to make it reusable to implement
writeback support, move it to the rcar_du_format_info structure.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 25 +++
drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 +
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 44 ---
3 files changed, 32 insertions(+), 38 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
index b0c80dffd8b8..999440c7b258 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
@@ -32,60 +32,70 @@
static const struct rcar_du_format_info rcar_du_format_infos[] = {
{
.fourcc = DRM_FORMAT_RGB565,
+ .v4l2 = V4L2_PIX_FMT_RGB565,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_ARGB1555,
+ .v4l2 = V4L2_PIX_FMT_ARGB555,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_XRGB1555,
+ .v4l2 = V4L2_PIX_FMT_XRGB555,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_ALP | PnMR_DDDF_ARGB,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_XRGB,
+ .v4l2 = V4L2_PIX_FMT_XBGR32,
.bpp = 32,
.planes = 1,
.pnmr = PnMR_SPIM_TP | PnMR_DDDF_16BPP,
.edf = PnDDCR4_EDF_RGB888,
}, {
.fourcc = DRM_FORMAT_ARGB,
+ .v4l2 = V4L2_PIX_FMT_ABGR32,
.bpp = 32,
.planes = 1,
.pnmr = PnMR_SPIM_ALP | PnMR_DDDF_16BPP,
.edf = PnDDCR4_EDF_ARGB,
}, {
.fourcc = DRM_FORMAT_UYVY,
+ .v4l2 = V4L2_PIX_FMT_UYVY,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_YUYV,
+ .v4l2 = V4L2_PIX_FMT_YUYV,
.bpp = 16,
.planes = 1,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_NV12,
+ .v4l2 = V4L2_PIX_FMT_NV12M,
.bpp = 12,
.planes = 2,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_NV21,
+ .v4l2 = V4L2_PIX_FMT_NV21M,
.bpp = 12,
.planes = 2,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
.edf = PnDDCR4_EDF_NONE,
}, {
.fourcc = DRM_FORMAT_NV16,
+ .v4l2 = V4L2_PIX_FMT_NV16M,
.bpp = 16,
.planes = 2,
.pnmr = PnMR_SPIM_TP_OFF | PnMR_DDDF_YC,
@@ -97,62 +107,77 @@ static const struct rcar_du_format_info
rcar_du_format_infos[] = {
*/
{
.fourcc = DRM_FORMAT_RGB332,
+ .v4l2 = V4L2_PIX_FMT_RGB332,
.bpp = 8,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_ARGB,
+ .v4l2 = V4L2_PIX_FMT_ARGB444,
.bpp = 16,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_XRGB,
+ .v4l2 = V4L2_PIX_FMT_XRGB444,
.bpp = 16,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_BGR888,
+ .v4l2 = V4L2_PIX_FMT_RGB24,
.bpp = 24,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_RGB888,
+ .v4l2 = V4L2_PIX_FMT_BGR24,
.bpp = 24,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_BGRA,
+ .v4l2 = V4L2_PIX_FMT_ARGB32,
.bpp = 32,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_BGRX,
+ .v4l2 = V4L2_PIX_FMT_XRGB32,
.bpp = 32,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_YVYU,
+ .v4l2 = V4L2_PIX_FMT_YVYU,
.bpp = 16,
.planes = 1,
}, {
.fourcc = DRM_FORMAT_NV61,
+ .v4l2 = V4L2_PIX_FMT_NV61M,
.bpp = 16,
.planes = 2,
}, {
.fourcc = DRM_FORMAT_YUV420,
+ .v4l2 = V4L2_PIX_FMT_YUV420M,
.bpp = 12,
[PATCH v6 14/18] drm: writeback: Add job prepare and cleanup operations
As writeback jobs contain a framebuffer, drivers may need to prepare and
cleanup them the same way they can prepare and cleanup framebuffers for
planes. Add two new optional connector helper operations,
.prepare_writeback_job() and .cleanup_writeback_job() to support this.
The job prepare operation is called from
drm_atomic_helper_prepare_planes() to avoid a new atomic commit helper
that would need to be called by all drivers not using
drm_atomic_helper_commit(). The job cleanup operation is called from the
existing drm_writeback_cleanup_job() function, invoked both when
destroying the job as part of a aborted commit, or when the job
completes.
The drm_writeback_job structure is extended with a priv field to let
drivers store per-job data, such as mappings related to the writeback
framebuffer.
For internal plumbing reasons the drm_writeback_job structure needs to
store a back-pointer to the drm_writeback_connector. To avoid pushing
too much writeback-specific knowledge to drm_atomic_uapi.c, create a
drm_writeback_set_fb() function, move the writeback job setup code
there, and set the connector backpointer. The prepare_signaling()
function doesn't need to allocate writeback jobs and can ignore
connectors without a job, as it is called after the writeback jobs are
allocated to store framebuffers, and a writeback fence with a
framebuffer is an invalid configuration that gets rejected by the commit
check.
Signed-off-by: Laurent Pinchart
---
Changes since v5:
- Export drm_writeback_prepare_job()
- Check for .prepare_writeback_job() in drm_writeback_prepare_job()
---
drivers/gpu/drm/drm_atomic_helper.c | 11 ++
drivers/gpu/drm/drm_atomic_uapi.c| 31 +
drivers/gpu/drm/drm_writeback.c | 44
include/drm/drm_modeset_helper_vtables.h | 7
include/drm/drm_writeback.h | 28 ++-
5 files changed, 97 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 6fe2303fccd9..70a4886c6e65 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2245,10 +2245,21 @@ EXPORT_SYMBOL(drm_atomic_helper_commit_cleanup_done);
int drm_atomic_helper_prepare_planes(struct drm_device *dev,
struct drm_atomic_state *state)
{
+ struct drm_connector *connector;
+ struct drm_connector_state *new_conn_state;
struct drm_plane *plane;
struct drm_plane_state *new_plane_state;
int ret, i, j;
+ for_each_new_connector_in_state(state, connector, new_conn_state, i) {
+ if (!new_conn_state->writeback_job)
+ continue;
+
+ ret = drm_writeback_prepare_job(new_conn_state->writeback_job);
+ if (ret < 0)
+ return ret;
+ }
+
for_each_new_plane_in_state(state, plane, new_plane_state, i) {
const struct drm_plane_helper_funcs *funcs;
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index c40889888a16..e802152a01ad 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -647,28 +647,15 @@ drm_atomic_plane_get_property(struct drm_plane *plane,
return 0;
}
-static struct drm_writeback_job *
-drm_atomic_get_writeback_job(struct drm_connector_state *conn_state)
-{
- WARN_ON(conn_state->connector->connector_type !=
DRM_MODE_CONNECTOR_WRITEBACK);
-
- if (!conn_state->writeback_job)
- conn_state->writeback_job =
- kzalloc(sizeof(*conn_state->writeback_job), GFP_KERNEL);
-
- return conn_state->writeback_job;
-}
-
static int drm_atomic_set_writeback_fb_for_connector(
struct drm_connector_state *conn_state,
struct drm_framebuffer *fb)
{
- struct drm_writeback_job *job =
- drm_atomic_get_writeback_job(conn_state);
- if (!job)
- return -ENOMEM;
+ int ret;
- drm_framebuffer_assign(>fb, fb);
+ ret = drm_writeback_set_fb(conn_state, fb);
+ if (ret < 0)
+ return ret;
if (fb)
DRM_DEBUG_ATOMIC("Set [FB:%d] for connector state %p\n",
@@ -1158,19 +1145,17 @@ static int prepare_signaling(struct drm_device *dev,
for_each_new_connector_in_state(state, conn, conn_state, i) {
struct drm_writeback_connector *wb_conn;
- struct drm_writeback_job *job;
struct drm_out_fence_state *f;
struct dma_fence *fence;
s32 __user *fence_ptr;
+ if (!conn_state->writeback_job)
+ continue;
+
fence_ptr = get_out_fence_for_connector(state, conn);
if (!fence_ptr)
continue;
- job = drm_atomic_get_writeback_job(conn_state);
- if
[PATCH v6 17/18] drm: rcar-du: vsp: Extract framebuffer (un)mapping to separate functions
The rcar_du_vsp_plane_prepare_fb() and rcar_du_vsp_plane_cleanup_fb()
functions implement the DRM plane .prepare_fb() and .cleanup_fb()
operations. They map and unmap the framebuffer to/from the VSP
internally, which will be useful to implement writeback support. Split
the mapping and unmapping out to separate functions.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 68 ---
drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 17 +++
2 files changed, 58 insertions(+), 27 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 29a08f7b0761..0806a69c4679 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -173,26 +173,16 @@ static void rcar_du_vsp_plane_setup(struct
rcar_du_vsp_plane *plane)
plane->index, );
}
-static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
- struct drm_plane_state *state)
+int rcar_du_vsp_map_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
+ struct sg_table sg_tables[3])
{
- struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
- struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
struct rcar_du_device *rcdu = vsp->dev;
unsigned int i;
int ret;
- /*
-* There's no need to prepare (and unprepare) the framebuffer when the
-* plane is not visible, as it will not be displayed.
-*/
- if (!state->visible)
- return 0;
-
- for (i = 0; i < rstate->format->planes; ++i) {
- struct drm_gem_cma_object *gem =
- drm_fb_cma_get_gem_obj(state->fb, i);
- struct sg_table *sgt = >sg_tables[i];
+ for (i = 0; i < fb->format->num_planes; ++i) {
+ struct drm_gem_cma_object *gem = drm_fb_cma_get_gem_obj(fb, i);
+ struct sg_table *sgt = _tables[i];
ret = dma_get_sgtable(rcdu->dev, sgt, gem->vaddr, gem->paddr,
gem->base.size);
@@ -207,15 +197,11 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane
*plane,
}
}
- ret = drm_gem_fb_prepare_fb(plane, state);
- if (ret)
- goto fail;
-
return 0;
fail:
while (i--) {
- struct sg_table *sgt = >sg_tables[i];
+ struct sg_table *sgt = _tables[i];
vsp1_du_unmap_sg(vsp->vsp, sgt);
sg_free_table(sgt);
@@ -224,22 +210,50 @@ static int rcar_du_vsp_plane_prepare_fb(struct drm_plane
*plane,
return ret;
}
+static int rcar_du_vsp_plane_prepare_fb(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+ struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
+ struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
+ int ret;
+
+ /*
+* There's no need to prepare (and unprepare) the framebuffer when the
+* plane is not visible, as it will not be displayed.
+*/
+ if (!state->visible)
+ return 0;
+
+ ret = rcar_du_vsp_map_fb(vsp, state->fb, rstate->sg_tables);
+ if (ret < 0)
+ return ret;
+
+ return drm_gem_fb_prepare_fb(plane, state);
+}
+
+void rcar_du_vsp_unmap_fb(struct rcar_du_vsp *vsp, struct drm_framebuffer *fb,
+ struct sg_table sg_tables[3])
+{
+ unsigned int i;
+
+ for (i = 0; i < fb->format->num_planes; ++i) {
+ struct sg_table *sgt = _tables[i];
+
+ vsp1_du_unmap_sg(vsp->vsp, sgt);
+ sg_free_table(sgt);
+ }
+}
+
static void rcar_du_vsp_plane_cleanup_fb(struct drm_plane *plane,
struct drm_plane_state *state)
{
struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
struct rcar_du_vsp *vsp = to_rcar_vsp_plane(plane)->vsp;
- unsigned int i;
if (!state->visible)
return;
- for (i = 0; i < rstate->format->planes; ++i) {
- struct sg_table *sgt = >sg_tables[i];
-
- vsp1_du_unmap_sg(vsp->vsp, sgt);
- sg_free_table(sgt);
- }
+ rcar_du_vsp_unmap_fb(vsp, state->fb, rstate->sg_tables);
}
static int rcar_du_vsp_plane_atomic_check(struct drm_plane *plane,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
index db232037f24a..9b4724159378 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.h
@@ -12,8 +12,10 @@
#include
+struct drm_framebuffer;
struct rcar_du_format_info;
struct rcar_du_vsp;
+struct sg_table;
struct rcar_du_vsp_plane {
struct drm_plane plane;
@@ -60,6 +62,10 @@ void rcar_du_vsp_enable(struct
[PATCH v6 15/18] drm: rcar-du: Fix rcar_du_crtc structure documentation
The rcar_du_crtc structure index field contains the CRTC hardware index,
not the hardware and software index. Update the documentation
accordingly.
Fixes: 5361cc7f8e91 ("drm: rcar-du: Split CRTC handling to support hardware
indexing")
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
index bcb35b0b7612..c478953be092 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
@@ -27,7 +27,7 @@ struct rcar_du_vsp;
* @clock: the CRTC functional clock
* @extclock: external pixel dot clock (optional)
* @mmio_offset: offset of the CRTC registers in the DU MMIO block
- * @index: CRTC software and hardware index
+ * @index: CRTC hardware index
* @initialized: whether the CRTC has been initialized and clocks enabled
* @dsysr: cached value of the DSYSR register
* @vblank_enable: whether vblank events are enabled on this CRTC
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 09/18] media: vsp1: drm: Split RPF format setting to separate function
The code that initializes the RPF format-related fields for display
pipelines will also be useful for the WPF to implement writeback
support. Split it from vsp1_du_atomic_update() to a new
vsp1_du_pipeline_set_rwpf_format() function.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_drm.c | 55 --
1 file changed, 35 insertions(+), 20 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 4f1bc51d1ef4..5601a787688b 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -566,6 +566,36 @@ static void vsp1_du_pipeline_configure(struct
vsp1_pipeline *pipe)
vsp1_dl_list_commit(dl, dl_flags);
}
+static int vsp1_du_pipeline_set_rwpf_format(struct vsp1_device *vsp1,
+ struct vsp1_rwpf *rwpf,
+ u32 pixelformat, unsigned int pitch)
+{
+ const struct vsp1_format_info *fmtinfo;
+ unsigned int chroma_hsub;
+
+ fmtinfo = vsp1_get_format_info(vsp1, pixelformat);
+ if (!fmtinfo) {
+ dev_dbg(vsp1->dev, "Unsupported pixel format %08x for RPF\n",
+ pixelformat);
+ return -EINVAL;
+ }
+
+ /*
+* Only formats with three planes can affect the chroma planes pitch.
+* All formats with two planes have a horizontal subsampling value of 2,
+* but combine U and V in a single chroma plane, which thus results in
+* the luma plane and chroma plane having the same pitch.
+*/
+ chroma_hsub = (fmtinfo->planes == 3) ? fmtinfo->hsub : 1;
+
+ rwpf->fmtinfo = fmtinfo;
+ rwpf->format.num_planes = fmtinfo->planes;
+ rwpf->format.plane_fmt[0].bytesperline = pitch;
+ rwpf->format.plane_fmt[1].bytesperline = pitch / chroma_hsub;
+
+ return 0;
+}
+
/*
-
* DU Driver API
*/
@@ -773,9 +803,8 @@ int vsp1_du_atomic_update(struct device *dev, unsigned int
pipe_index,
{
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_drm_pipeline *drm_pipe = >drm->pipe[pipe_index];
- const struct vsp1_format_info *fmtinfo;
- unsigned int chroma_hsub;
struct vsp1_rwpf *rpf;
+ int ret;
if (rpf_index >= vsp1->info->rpf_count)
return -EINVAL;
@@ -808,25 +837,11 @@ int vsp1_du_atomic_update(struct device *dev, unsigned
int pipe_index,
* Store the format, stride, memory buffer address, crop and compose
* rectangles and Z-order position and for the input.
*/
- fmtinfo = vsp1_get_format_info(vsp1, cfg->pixelformat);
- if (!fmtinfo) {
- dev_dbg(vsp1->dev, "Unsupported pixel format %08x for RPF\n",
- cfg->pixelformat);
- return -EINVAL;
- }
+ ret = vsp1_du_pipeline_set_rwpf_format(vsp1, rpf, cfg->pixelformat,
+ cfg->pitch);
+ if (ret < 0)
+ return ret;
- /*
-* Only formats with three planes can affect the chroma planes pitch.
-* All formats with two planes have a horizontal subsampling value of 2,
-* but combine U and V in a single chroma plane, which thus results in
-* the luma plane and chroma plane having the same pitch.
-*/
- chroma_hsub = (fmtinfo->planes == 3) ? fmtinfo->hsub : 1;
-
- rpf->fmtinfo = fmtinfo;
- rpf->format.num_planes = fmtinfo->planes;
- rpf->format.plane_fmt[0].bytesperline = cfg->pitch;
- rpf->format.plane_fmt[1].bytesperline = cfg->pitch / chroma_hsub;
rpf->alpha = cfg->alpha;
rpf->mem.addr[0] = cfg->mem[0];
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 03/18] media: vsp1: Replace leftover occurrence of fragment with body
Display list fragments have been renamed to bodies. Replace one last occurrence of the word fragment in the documentation. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_dl.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_dl.c b/drivers/media/platform/vsp1/vsp1_dl.c index 26289adaf658..64af449791b0 100644 --- a/drivers/media/platform/vsp1/vsp1_dl.c +++ b/drivers/media/platform/vsp1/vsp1_dl.c @@ -699,8 +699,8 @@ struct vsp1_dl_body *vsp1_dl_list_get_body0(struct vsp1_dl_list *dl) * which bodies are added. * * Adding a body to a display list passes ownership of the body to the list. The - * caller retains its reference to the fragment when adding it to the display - * list, but is not allowed to add new entries to the body. + * caller retains its reference to the body when adding it to the display list, + * but is not allowed to add new entries to the body. * * The reference must be explicitly released by a call to vsp1_dl_body_put() * when the body isn't needed anymore. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 08/18] media: vsp1: wpf: Add writeback support
Add support for the writeback feature of the WPF, to enable capturing
frames at the WPF output for display pipelines. To enable writeback the
vsp1_rwpf structure mem field must be set to the address of the
writeback buffer and the writeback field set to true before the WPF
.configure_stream() and .configure_partition() are called. The WPF will
enable writeback in the display list for a single frame, and writeback
will then be automatically disabled.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_rwpf.h | 2 +
drivers/media/platform/vsp1/vsp1_wpf.c | 73 ++---
2 files changed, 66 insertions(+), 9 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_rwpf.h
b/drivers/media/platform/vsp1/vsp1_rwpf.h
index 70742ecf766f..910990b27617 100644
--- a/drivers/media/platform/vsp1/vsp1_rwpf.h
+++ b/drivers/media/platform/vsp1/vsp1_rwpf.h
@@ -35,6 +35,7 @@ struct vsp1_rwpf {
struct v4l2_ctrl_handler ctrls;
struct vsp1_video *video;
+ bool has_writeback;
unsigned int max_width;
unsigned int max_height;
@@ -61,6 +62,7 @@ struct vsp1_rwpf {
} flip;
struct vsp1_rwpf_memory mem;
+ bool writeback;
struct vsp1_dl_manager *dlm;
};
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c
b/drivers/media/platform/vsp1/vsp1_wpf.c
index fc5c1b0f6633..390ac478336d 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -232,6 +232,27 @@ static void vsp1_wpf_destroy(struct vsp1_entity *entity)
vsp1_dlm_destroy(wpf->dlm);
}
+static int wpf_configure_writeback_chain(struct vsp1_rwpf *wpf,
+struct vsp1_dl_list *dl)
+{
+ unsigned int index = wpf->entity.index;
+ struct vsp1_dl_list *dl_next;
+ struct vsp1_dl_body *dlb;
+
+ dl_next = vsp1_dl_list_get(wpf->dlm);
+ if (!dl_next) {
+ dev_err(wpf->entity.vsp1->dev,
+ "Failed to obtain a dl list, disabling writeback\n");
+ return -ENOMEM;
+ }
+
+ dlb = vsp1_dl_list_get_body0(dl_next);
+ vsp1_dl_body_write(dlb, VI6_WPF_WRBCK_CTRL(index), 0);
+ vsp1_dl_list_add_chain(dl, dl_next);
+
+ return 0;
+}
+
static void wpf_configure_stream(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
struct vsp1_dl_list *dl,
@@ -241,9 +262,11 @@ static void wpf_configure_stream(struct vsp1_entity
*entity,
struct vsp1_device *vsp1 = wpf->entity.vsp1;
const struct v4l2_mbus_framefmt *source_format;
const struct v4l2_mbus_framefmt *sink_format;
+ unsigned int index = wpf->entity.index;
unsigned int i;
u32 outfmt = 0;
u32 srcrpf = 0;
+ int ret;
sink_format = vsp1_entity_get_pad_format(>entity,
wpf->entity.config,
@@ -251,8 +274,9 @@ static void wpf_configure_stream(struct vsp1_entity *entity,
source_format = vsp1_entity_get_pad_format(>entity,
wpf->entity.config,
RWPF_PAD_SOURCE);
+
/* Format */
- if (!pipe->lif) {
+ if (!pipe->lif || wpf->writeback) {
const struct v4l2_pix_format_mplane *format = >format;
const struct vsp1_format_info *fmtinfo = wpf->fmtinfo;
@@ -277,8 +301,7 @@ static void wpf_configure_stream(struct vsp1_entity *entity,
vsp1_wpf_write(wpf, dlb, VI6_WPF_DSWAP, fmtinfo->swap);
- if (vsp1_feature(vsp1, VSP1_HAS_WPF_HFLIP) &&
- wpf->entity.index == 0)
+ if (vsp1_feature(vsp1, VSP1_HAS_WPF_HFLIP) && index == 0)
vsp1_wpf_write(wpf, dlb, VI6_WPF_ROT_CTRL,
VI6_WPF_ROT_CTRL_LN16 |
(256 << VI6_WPF_ROT_CTRL_LMEM_WD_SHIFT));
@@ -289,11 +312,9 @@ static void wpf_configure_stream(struct vsp1_entity
*entity,
wpf->outfmt = outfmt;
- vsp1_dl_body_write(dlb, VI6_DPR_WPF_FPORCH(wpf->entity.index),
+ vsp1_dl_body_write(dlb, VI6_DPR_WPF_FPORCH(index),
VI6_DPR_WPF_FPORCH_FP_WPFN);
- vsp1_dl_body_write(dlb, VI6_WPF_WRBCK_CTRL(wpf->entity.index), 0);
-
/*
* Sources. If the pipeline has a single input and BRx is not used,
* configure it as the master layer. Otherwise configure all
@@ -319,9 +340,26 @@ static void wpf_configure_stream(struct vsp1_entity
*entity,
vsp1_wpf_write(wpf, dlb, VI6_WPF_SRCRPF, srcrpf);
/* Enable interrupts. */
- vsp1_dl_body_write(dlb, VI6_WPF_IRQ_STA(wpf->entity.index), 0);
- vsp1_dl_body_write(dlb, VI6_WPF_IRQ_ENB(wpf->entity.index),
+ vsp1_dl_body_write(dlb, VI6_WPF_IRQ_STA(index), 0);
+ vsp1_dl_body_write(dlb,
[PATCH v6 06/18] media: vsp1: Add vsp1_dl_list argument to .configure_stream() operation
The WPF needs access to the current display list to configure writeback.
Add a display list pointer to the VSP1 entity .configure_stream()
operation.
Only display pipelines can make use of the display list there as
mem-to-mem pipelines don't have access to a display list at stream
configuration time. This is not an issue as writeback is only used for
display pipelines.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_brx.c| 1 +
drivers/media/platform/vsp1/vsp1_clu.c| 1 +
drivers/media/platform/vsp1/vsp1_drm.c| 2 +-
drivers/media/platform/vsp1/vsp1_entity.c | 3 ++-
drivers/media/platform/vsp1/vsp1_entity.h | 7 +--
drivers/media/platform/vsp1/vsp1_hgo.c| 1 +
drivers/media/platform/vsp1/vsp1_hgt.c| 1 +
drivers/media/platform/vsp1/vsp1_hsit.c | 1 +
drivers/media/platform/vsp1/vsp1_lif.c| 1 +
drivers/media/platform/vsp1/vsp1_lut.c| 1 +
drivers/media/platform/vsp1/vsp1_rpf.c| 1 +
drivers/media/platform/vsp1/vsp1_sru.c| 1 +
drivers/media/platform/vsp1/vsp1_uds.c| 1 +
drivers/media/platform/vsp1/vsp1_uif.c| 1 +
drivers/media/platform/vsp1/vsp1_video.c | 3 ++-
drivers/media/platform/vsp1/vsp1_wpf.c| 1 +
16 files changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_brx.c
b/drivers/media/platform/vsp1/vsp1_brx.c
index 5e50178b057d..43468bc8fb56 100644
--- a/drivers/media/platform/vsp1/vsp1_brx.c
+++ b/drivers/media/platform/vsp1/vsp1_brx.c
@@ -283,6 +283,7 @@ static const struct v4l2_subdev_ops brx_ops = {
static void brx_configure_stream(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
+struct vsp1_dl_list *dl,
struct vsp1_dl_body *dlb)
{
struct vsp1_brx *brx = to_brx(>subdev);
diff --git a/drivers/media/platform/vsp1/vsp1_clu.c
b/drivers/media/platform/vsp1/vsp1_clu.c
index 942fc14c19d1..a47b23bf5abf 100644
--- a/drivers/media/platform/vsp1/vsp1_clu.c
+++ b/drivers/media/platform/vsp1/vsp1_clu.c
@@ -171,6 +171,7 @@ static const struct v4l2_subdev_ops clu_ops = {
static void clu_configure_stream(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
+struct vsp1_dl_list *dl,
struct vsp1_dl_body *dlb)
{
struct vsp1_clu *clu = to_clu(>subdev);
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 89773d3a916c..4f1bc51d1ef4 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -558,7 +558,7 @@ static void vsp1_du_pipeline_configure(struct vsp1_pipeline
*pipe)
}
vsp1_entity_route_setup(entity, pipe, dlb);
- vsp1_entity_configure_stream(entity, pipe, dlb);
+ vsp1_entity_configure_stream(entity, pipe, dl, dlb);
vsp1_entity_configure_frame(entity, pipe, dl, dlb);
vsp1_entity_configure_partition(entity, pipe, dl, dlb);
}
diff --git a/drivers/media/platform/vsp1/vsp1_entity.c
b/drivers/media/platform/vsp1/vsp1_entity.c
index a54ab528b060..aa9d2286056e 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.c
+++ b/drivers/media/platform/vsp1/vsp1_entity.c
@@ -71,10 +71,11 @@ void vsp1_entity_route_setup(struct vsp1_entity *entity,
void vsp1_entity_configure_stream(struct vsp1_entity *entity,
struct vsp1_pipeline *pipe,
+ struct vsp1_dl_list *dl,
struct vsp1_dl_body *dlb)
{
if (entity->ops->configure_stream)
- entity->ops->configure_stream(entity, pipe, dlb);
+ entity->ops->configure_stream(entity, pipe, dl, dlb);
}
void vsp1_entity_configure_frame(struct vsp1_entity *entity,
diff --git a/drivers/media/platform/vsp1/vsp1_entity.h
b/drivers/media/platform/vsp1/vsp1_entity.h
index 97acb7795cf1..a1ceb37bb837 100644
--- a/drivers/media/platform/vsp1/vsp1_entity.h
+++ b/drivers/media/platform/vsp1/vsp1_entity.h
@@ -67,7 +67,9 @@ struct vsp1_route {
* struct vsp1_entity_operations - Entity operations
* @destroy: Destroy the entity.
* @configure_stream: Setup the hardware parameters for the stream which do
- * not vary between frames (pipeline, formats).
+ * not vary between frames (pipeline, formats). Note that
+ * the vsp1_dl_list argument is only valid for display
+ * pipeline and will be NULL for mem-to-mem pipelines.
* @configure_frame: Configure the runtime parameters for each frame.
* @configure_partition: Configure partition specific parameters.
* @max_width: Return the max supported width of data that the entity can
@@ -78,7 +80,7 @@ struct vsp1_route {
struct vsp1_entity_operations {
void (*destroy)(struct vsp1_entity *);
[PATCH v6 05/18] media: vsp1: Replace the display list internal flag with a flags field
To prepare for addition of more flags to the display list, replace the
'internal' flag field by a bitmask 'flags' field.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
Changes since v4:
- Fix check for the completed flag in vsp1_du_pipeline_frame_end()
---
drivers/media/platform/vsp1/vsp1_dl.c| 31 +---
drivers/media/platform/vsp1/vsp1_dl.h| 2 +-
drivers/media/platform/vsp1/vsp1_drm.c | 8 --
drivers/media/platform/vsp1/vsp1_video.c | 2 +-
4 files changed, 25 insertions(+), 18 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 64af449791b0..886b3a69d329 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -178,7 +178,7 @@ struct vsp1_dl_cmd_pool {
* @post_cmd: post command to be issued through extended dl header
* @has_chain: if true, indicates that there's a partition chain
* @chain: entry in the display list partition chain
- * @internal: whether the display list is used for internal purpose
+ * @flags: display list flags, a combination of VSP1_DL_FRAME_END_*
*/
struct vsp1_dl_list {
struct list_head list;
@@ -197,7 +197,7 @@ struct vsp1_dl_list {
bool has_chain;
struct list_head chain;
- bool internal;
+ unsigned int flags;
};
/**
@@ -861,13 +861,15 @@ static void vsp1_dl_list_commit_continuous(struct
vsp1_dl_list *dl)
*
* If a display list is already pending we simply drop it as the new
* display list is assumed to contain a more recent configuration. It is
-* an error if the already pending list has the internal flag set, as
-* there is then a process waiting for that list to complete. This
-* shouldn't happen as the waiting process should perform proper
-* locking, but warn just in case.
+* an error if the already pending list has the
+* VSP1_DL_FRAME_END_INTERNAL flag set, as there is then a process
+* waiting for that list to complete. This shouldn't happen as the
+* waiting process should perform proper locking, but warn just in
+* case.
*/
if (vsp1_dl_list_hw_update_pending(dlm)) {
- WARN_ON(dlm->pending && dlm->pending->internal);
+ WARN_ON(dlm->pending &&
+ (dlm->pending->flags & VSP1_DL_FRAME_END_INTERNAL));
__vsp1_dl_list_put(dlm->pending);
dlm->pending = dl;
return;
@@ -897,7 +899,7 @@ static void vsp1_dl_list_commit_singleshot(struct
vsp1_dl_list *dl)
dlm->active = dl;
}
-void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool internal)
+void vsp1_dl_list_commit(struct vsp1_dl_list *dl, unsigned int dl_flags)
{
struct vsp1_dl_manager *dlm = dl->dlm;
struct vsp1_dl_list *dl_next;
@@ -912,7 +914,7 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool
internal)
vsp1_dl_list_fill_header(dl_next, last);
}
- dl->internal = internal;
+ dl->flags = dl_flags & ~VSP1_DL_FRAME_END_COMPLETED;
spin_lock_irqsave(>lock, flags);
@@ -941,9 +943,10 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, bool
internal)
* set in single-shot mode as display list processing is then not continuous
and
* races never occur.
*
- * The VSP1_DL_FRAME_END_INTERNAL flag indicates that the previous display list
- * has completed and had been queued with the internal notification flag.
- * Internal notification is only supported for continuous mode.
+ * The following flags are only supported for continuous mode.
+ *
+ * The VSP1_DL_FRAME_END_INTERNAL flag indicates that the display list that
just
+ * became active had been queued with the internal notification flag.
*/
unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
{
@@ -986,9 +989,9 @@ unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager
*dlm)
* frame end interrupt. The display list thus becomes active.
*/
if (dlm->queued) {
- if (dlm->queued->internal)
+ if (dlm->queued->flags & VSP1_DL_FRAME_END_INTERNAL)
flags |= VSP1_DL_FRAME_END_INTERNAL;
- dlm->queued->internal = false;
+ dlm->queued->flags &= ~VSP1_DL_FRAME_END_INTERNAL;
__vsp1_dl_list_put(dlm->active);
dlm->active = dlm->queued;
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h
b/drivers/media/platform/vsp1/vsp1_dl.h
index 125750dc8b5c..e0fdb145e6ed 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -61,7 +61,7 @@ struct vsp1_dl_list *vsp1_dl_list_get(struct vsp1_dl_manager
*dlm);
void vsp1_dl_list_put(struct vsp1_dl_list *dl);
struct vsp1_dl_body *vsp1_dl_list_get_body0(struct vsp1_dl_list *dl);
struct vsp1_dl_ext_cmd *vsp1_dl_get_pre_cmd(struct vsp1_dl_list *dl);
-void
[PATCH v6 10/18] media: vsp1: drm: Extend frame completion API to the DU driver
The VSP1 driver will need to pass extra flags to the DU through the
frame completion API. Replace the completed bool flag by a bitmask to
support this.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 4 ++--
drivers/media/platform/vsp1/vsp1_drm.c | 4 ++--
drivers/media/platform/vsp1/vsp1_drm.h | 2 +-
include/media/vsp1.h | 4 +++-
4 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 76a39eee7c9c..28bfeb8c24fb 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -26,14 +26,14 @@
#include "rcar_du_kms.h"
#include "rcar_du_vsp.h"
-static void rcar_du_vsp_complete(void *private, bool completed, u32 crc)
+static void rcar_du_vsp_complete(void *private, unsigned int status, u32 crc)
{
struct rcar_du_crtc *crtc = private;
if (crtc->vblank_enable)
drm_crtc_handle_vblank(>crtc);
- if (completed)
+ if (status & VSP1_DU_STATUS_COMPLETE)
rcar_du_crtc_finish_page_flip(crtc);
drm_crtc_add_crc_entry(>crtc, false, 0, );
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 5601a787688b..0367f88135bf 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -34,14 +34,14 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline
*pipe,
unsigned int completion)
{
struct vsp1_drm_pipeline *drm_pipe = to_vsp1_drm_pipeline(pipe);
- bool complete = completion & VSP1_DL_FRAME_END_COMPLETED;
if (drm_pipe->du_complete) {
struct vsp1_entity *uif = drm_pipe->uif;
+ unsigned int status = completion & VSP1_DU_STATUS_COMPLETE;
u32 crc;
crc = uif ? vsp1_uif_get_crc(to_uif(>subdev)) : 0;
- drm_pipe->du_complete(drm_pipe->du_private, complete, crc);
+ drm_pipe->du_complete(drm_pipe->du_private, status, crc);
}
if (completion & VSP1_DL_FRAME_END_INTERNAL) {
diff --git a/drivers/media/platform/vsp1/vsp1_drm.h
b/drivers/media/platform/vsp1/vsp1_drm.h
index 8dfd274a59e2..e85ad4366fbb 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.h
+++ b/drivers/media/platform/vsp1/vsp1_drm.h
@@ -42,7 +42,7 @@ struct vsp1_drm_pipeline {
struct vsp1_du_crc_config crc;
/* Frame synchronisation */
- void (*du_complete)(void *data, bool completed, u32 crc);
+ void (*du_complete)(void *data, unsigned int status, u32 crc);
void *du_private;
};
diff --git a/include/media/vsp1.h b/include/media/vsp1.h
index 1cf868360701..877496936487 100644
--- a/include/media/vsp1.h
+++ b/include/media/vsp1.h
@@ -17,6 +17,8 @@ struct device;
int vsp1_du_init(struct device *dev);
+#define VSP1_DU_STATUS_COMPLETEBIT(0)
+
/**
* struct vsp1_du_lif_config - VSP LIF configuration
* @width: output frame width
@@ -32,7 +34,7 @@ struct vsp1_du_lif_config {
unsigned int height;
bool interlaced;
- void (*callback)(void *data, bool completed, u32 crc);
+ void (*callback)(void *data, unsigned int status, u32 crc);
void *callback_data;
};
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 00/18] R-Car DU display writeback support
Hello everybody, This patch series implements display writeback support for the R-Car Gen3 platforms in the VSP1 and DU drivers. Patches 01/18 to 11/18 prepare the VSP1 driver for writeback support with all the necessary plumbing, including extensions of the API between the VSP1 and DU drivers. Compared to v5 the major change is the usage of chained display lists in the VSP to disable writeback after one frame, instead of patching the active display list in memory. This should solve the potential DMA to released buffer issue that could occur when the frame start interrupt was delayed after frame end. Patch 06/18 and 07/18 are new in this version to support usage of chained display pipelines. Compared to v4 the major change is the move from V4L2 to DRM writeback connectors for the userspace API. This has caused a few issues with writeback support to be uncovered, and they are addressed by patches 12/18 to 14/18. Patches 15/18 to 17/18 then perform refactoring of the DU driver, to finally add writeback support in patch 18/18. The writeback pixel format is restricted to RGB, due to the VSP1 outputting RGB to the display and lacking a separate colour space conversion unit for writeback. The writeback framebuffer size must match the active mode, writeback scaling is not supported by the hardware. Writeback requests being part of atomic commits, they're queued to the hardware when they are received, become active at the next vblank, and complete on the following vblank. The display list chaining mechanism ensures that writeback will be enabled for a single frame only, unless the next atomic commit contains a separate writeback request. The code is based on a merge of the media master branch, the drm-next branch and the R-Car DT next branch. For convenience patches can be found at git://linuxtv.org/pinchartl/media.git v4l2/vsp1/writeback Kieran Bingham (1): Revert "[media] v4l: vsp1: Supply frames to the DU continuously" Laurent Pinchart (17): media: vsp1: wpf: Fix partition configuration for display pipelines media: vsp1: Replace leftover occurrence of fragment with body media: vsp1: Fix addresses of display-related registers for VSP-DL media: vsp1: Replace the display list internal flag with a flags field media: vsp1: Add vsp1_dl_list argument to .configure_stream() operation media: vsp1: dl: Allow chained display lists for display pipelines media: vsp1: wpf: Add writeback support media: vsp1: drm: Split RPF format setting to separate function media: vsp1: drm: Extend frame completion API to the DU driver media: vsp1: drm: Implement writeback support drm: writeback: Cleanup job ownership handling when queuing job drm: writeback: Fix leak of writeback job drm: writeback: Add job prepare and cleanup operations drm: rcar-du: Fix rcar_du_crtc structure documentation drm: rcar-du: Store V4L2 fourcc in rcar_du_format_info structure drm: rcar-du: vsp: Extract framebuffer (un)mapping to separate functions drm: rcar-du: Add writeback support for R-Car Gen3 drivers/gpu/drm/arm/malidp_mw.c | 3 +- drivers/gpu/drm/drm_atomic_helper.c | 11 + drivers/gpu/drm/drm_atomic_state_helper.c | 4 + drivers/gpu/drm/drm_atomic_uapi.c | 31 +-- drivers/gpu/drm/drm_writeback.c | 73 +- drivers/gpu/drm/rcar-du/Kconfig | 4 + drivers/gpu/drm/rcar-du/Makefile| 3 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 7 +- drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 9 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 37 +++ drivers/gpu/drm/rcar-du/rcar_du_kms.h | 1 + drivers/gpu/drm/rcar-du/rcar_du_vsp.c | 121 +- drivers/gpu/drm/rcar-du/rcar_du_vsp.h | 17 ++ drivers/gpu/drm/rcar-du/rcar_du_writeback.c | 243 drivers/gpu/drm/rcar-du/rcar_du_writeback.h | 39 drivers/gpu/drm/vc4/vc4_txp.c | 2 +- drivers/media/platform/vsp1/vsp1_brx.c | 1 + drivers/media/platform/vsp1/vsp1_clu.c | 1 + drivers/media/platform/vsp1/vsp1_dl.c | 84 --- drivers/media/platform/vsp1/vsp1_dl.h | 5 +- drivers/media/platform/vsp1/vsp1_drm.c | 94 +--- drivers/media/platform/vsp1/vsp1_drm.h | 2 +- drivers/media/platform/vsp1/vsp1_entity.c | 3 +- drivers/media/platform/vsp1/vsp1_entity.h | 7 +- drivers/media/platform/vsp1/vsp1_hgo.c | 1 + drivers/media/platform/vsp1/vsp1_hgt.c | 1 + drivers/media/platform/vsp1/vsp1_hsit.c | 1 + drivers/media/platform/vsp1/vsp1_lif.c | 1 + drivers/media/platform/vsp1/vsp1_lut.c | 1 + drivers/media/platform/vsp1/vsp1_regs.h | 6 +- drivers/media/platform/vsp1/vsp1_rpf.c | 1 + drivers/media/platform/vsp1/vsp1_rwpf.h | 2 + drivers/media/platform/vsp1/vsp1_sru.c | 1 + drivers/media/platform/vsp1/vsp1_uds.c | 1 + drivers/media/platform/vsp1/vsp1_uif.c | 1 +
[PATCH v6 04/18] media: vsp1: Fix addresses of display-related registers for VSP-DL
The VSP-DL instances have two LIFs, and thus two copies of the VI6_DISP_IRQ_ENB, VI6_DISP_IRQ_STA and VI6_WPF_WRBCK_CTRL registers. Fix the corresponding macros accordingly. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_drm.c | 4 ++-- drivers/media/platform/vsp1/vsp1_regs.h | 6 +++--- drivers/media/platform/vsp1/vsp1_wpf.c | 2 +- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/media/platform/vsp1/vsp1_drm.c b/drivers/media/platform/vsp1/vsp1_drm.c index 8d86f618ec77..048190fd3a2d 100644 --- a/drivers/media/platform/vsp1/vsp1_drm.c +++ b/drivers/media/platform/vsp1/vsp1_drm.c @@ -700,8 +700,8 @@ int vsp1_du_setup_lif(struct device *dev, unsigned int pipe_index, drm_pipe->du_private = cfg->callback_data; /* Disable the display interrupts. */ - vsp1_write(vsp1, VI6_DISP_IRQ_STA, 0); - vsp1_write(vsp1, VI6_DISP_IRQ_ENB, 0); + vsp1_write(vsp1, VI6_DISP_IRQ_STA(pipe_index), 0); + vsp1_write(vsp1, VI6_DISP_IRQ_ENB(pipe_index), 0); /* Configure all entities in the pipeline. */ vsp1_du_pipeline_configure(pipe); diff --git a/drivers/media/platform/vsp1/vsp1_regs.h b/drivers/media/platform/vsp1/vsp1_regs.h index f6e4157095cc..1bb1d39c60d9 100644 --- a/drivers/media/platform/vsp1/vsp1_regs.h +++ b/drivers/media/platform/vsp1/vsp1_regs.h @@ -39,12 +39,12 @@ #define VI6_WFP_IRQ_STA_DFE(1 << 1) #define VI6_WFP_IRQ_STA_FRE(1 << 0) -#define VI6_DISP_IRQ_ENB 0x0078 +#define VI6_DISP_IRQ_ENB(n)(0x0078 + (n) * 60) #define VI6_DISP_IRQ_ENB_DSTE (1 << 8) #define VI6_DISP_IRQ_ENB_MAEE (1 << 5) #define VI6_DISP_IRQ_ENB_LNEE(n) (1 << (n)) -#define VI6_DISP_IRQ_STA 0x007c +#define VI6_DISP_IRQ_STA(n)(0x007c + (n) * 60) #define VI6_DISP_IRQ_STA_DST (1 << 8) #define VI6_DISP_IRQ_STA_MAE (1 << 5) #define VI6_DISP_IRQ_STA_LNE(n)(1 << (n)) @@ -307,7 +307,7 @@ #define VI6_WPF_DSTM_ADDR_C0 0x1028 #define VI6_WPF_DSTM_ADDR_C1 0x102c -#define VI6_WPF_WRBCK_CTRL 0x1034 +#define VI6_WPF_WRBCK_CTRL(n) (0x1034 + (n) * 0x100) #define VI6_WPF_WRBCK_CTRL_WBMD(1 << 0) /* - diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c b/drivers/media/platform/vsp1/vsp1_wpf.c index a07c5944b598..18c49e3a7875 100644 --- a/drivers/media/platform/vsp1/vsp1_wpf.c +++ b/drivers/media/platform/vsp1/vsp1_wpf.c @@ -291,7 +291,7 @@ static void wpf_configure_stream(struct vsp1_entity *entity, vsp1_dl_body_write(dlb, VI6_DPR_WPF_FPORCH(wpf->entity.index), VI6_DPR_WPF_FPORCH_FP_WPFN); - vsp1_dl_body_write(dlb, VI6_WPF_WRBCK_CTRL, 0); + vsp1_dl_body_write(dlb, VI6_WPF_WRBCK_CTRL(wpf->entity.index), 0); /* * Sources. If the pipeline has a single input and BRx is not used, -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 12/18] drm: writeback: Cleanup job ownership handling when queuing job
The drm_writeback_queue_job() function takes ownership of the passed job
and requires the caller to manually set the connector state
writeback_job pointer to NULL. To simplify drivers and avoid errors
(such as the missing NULL set in the vc4 driver), pass the connector
state pointer to the function instead of the job pointer, and set the
writeback_job pointer to NULL internally.
Signed-off-by: Laurent Pinchart
Reviewed-by: Brian Starkey
Acked-by: Eric Anholt
Acked-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_mw.c | 3 +--
drivers/gpu/drm/drm_writeback.c | 15 ++-
drivers/gpu/drm/vc4/vc4_txp.c | 2 +-
include/drm/drm_writeback.h | 2 +-
4 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 041a64dc7167..87627219ce3b 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -252,8 +252,7 @@ void malidp_mw_atomic_commit(struct drm_device *drm,
_state->addrs[0],
mw_state->format);
- drm_writeback_queue_job(mw_conn, conn_state->writeback_job);
- conn_state->writeback_job = NULL;
+ drm_writeback_queue_job(mw_conn, conn_state);
hwdev->hw->enable_memwrite(hwdev, mw_state->addrs,
mw_state->pitches,
mw_state->n_planes,
fb->width, fb->height,
mw_state->format,
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index c20e6fe00cb3..338b993d7c9f 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -242,11 +242,12 @@ EXPORT_SYMBOL(drm_writeback_connector_init);
/**
* drm_writeback_queue_job - Queue a writeback job for later signalling
* @wb_connector: The writeback connector to queue a job on
- * @job: The job to queue
+ * @conn_state: The connector state containing the job to queue
*
- * This function adds a job to the job_queue for a writeback connector. It
- * should be considered to take ownership of the writeback job, and so any
other
- * references to the job must be cleared after calling this function.
+ * This function adds the job contained in @conn_state to the job_queue for a
+ * writeback connector. It takes ownership of the writeback job and sets the
+ * @conn_state->writeback_job to NULL, and so no access to the job may be
+ * performed by the caller after this function returns.
*
* Drivers must ensure that for a given writeback connector, jobs are queued in
* exactly the same order as they will be completed by the hardware (and
@@ -258,10 +259,14 @@ EXPORT_SYMBOL(drm_writeback_connector_init);
* See also: drm_writeback_signal_completion()
*/
void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
-struct drm_writeback_job *job)
+struct drm_connector_state *conn_state)
{
+ struct drm_writeback_job *job;
unsigned long flags;
+ job = conn_state->writeback_job;
+ conn_state->writeback_job = NULL;
+
spin_lock_irqsave(_connector->job_lock, flags);
list_add_tail(>list_entry, _connector->job_queue);
spin_unlock_irqrestore(_connector->job_lock, flags);
diff --git a/drivers/gpu/drm/vc4/vc4_txp.c b/drivers/gpu/drm/vc4/vc4_txp.c
index aa279b5b0de7..5dabd91f2d7e 100644
--- a/drivers/gpu/drm/vc4/vc4_txp.c
+++ b/drivers/gpu/drm/vc4/vc4_txp.c
@@ -327,7 +327,7 @@ static void vc4_txp_connector_atomic_commit(struct
drm_connector *conn,
TXP_WRITE(TXP_DST_CTRL, ctrl);
- drm_writeback_queue_job(>connector, conn_state->writeback_job);
+ drm_writeback_queue_job(>connector, conn_state);
}
static const struct drm_connector_helper_funcs vc4_txp_connector_helper_funcs
= {
diff --git a/include/drm/drm_writeback.h b/include/drm/drm_writeback.h
index 23df9d463003..47662c362743 100644
--- a/include/drm/drm_writeback.h
+++ b/include/drm/drm_writeback.h
@@ -123,7 +123,7 @@ int drm_writeback_connector_init(struct drm_device *dev,
const u32 *formats, int n_formats);
void drm_writeback_queue_job(struct drm_writeback_connector *wb_connector,
-struct drm_writeback_job *job);
+struct drm_connector_state *conn_state);
void drm_writeback_cleanup_job(struct drm_writeback_job *job);
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 01/18] Revert "[media] v4l: vsp1: Supply frames to the DU continuously"
From: Kieran Bingham
This reverts commit 3299ba5c0b21 ("[media] v4l: vsp1: Supply frames to
the DU continuously")
The DU output mode does not rely on frames being supplied on the WPF as
its pipeline is supplied from DRM. For the upcoming WPF writeback
functionality, we will choose to enable writeback mode if there is an
output buffer, or disable it (leaving the existing display pipeline
unharmed) otherwise.
Signed-off-by: Kieran Bingham
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_video.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_video.c
b/drivers/media/platform/vsp1/vsp1_video.c
index 7ceaf3222145..328d686189be 100644
--- a/drivers/media/platform/vsp1/vsp1_video.c
+++ b/drivers/media/platform/vsp1/vsp1_video.c
@@ -307,11 +307,6 @@ static int vsp1_video_pipeline_setup_partitions(struct
vsp1_pipeline *pipe)
* This function completes the current buffer by filling its sequence number,
* time stamp and payload size, and hands it back to the videobuf core.
*
- * When operating in DU output mode (deep pipeline to the DU through the LIF),
- * the VSP1 needs to constantly supply frames to the display. In that case, if
- * no other buffer is queued, reuse the one that has just been processed
instead
- * of handing it back to the videobuf core.
- *
* Return the next queued buffer or NULL if the queue is empty.
*/
static struct vsp1_vb2_buffer *
@@ -333,12 +328,6 @@ vsp1_video_complete_buffer(struct vsp1_video *video)
done = list_first_entry(>irqqueue,
struct vsp1_vb2_buffer, queue);
- /* In DU output mode reuse the buffer if the list is singular. */
- if (pipe->lif && list_is_singular(>irqqueue)) {
- spin_unlock_irqrestore(>irqlock, flags);
- return done;
- }
-
list_del(>queue);
if (!list_empty(>irqqueue))
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 11/18] media: vsp1: drm: Implement writeback support
Extend the vsp1_du_atomic_flush() API with writeback support by adding
format, pitch and memory addresses of the writeback framebuffer.
Writeback completion is reported through the existing frame completion
callback with a new VSP1_DU_STATUS_WRITEBACK status flag.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_dl.c | 14 ++
drivers/media/platform/vsp1/vsp1_dl.h | 3 ++-
drivers/media/platform/vsp1/vsp1_drm.c | 25 -
include/media/vsp1.h | 15 +++
4 files changed, 55 insertions(+), 2 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index ed7cda4130f2..104b6f514536 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -958,6 +958,9 @@ void vsp1_dl_list_commit(struct vsp1_dl_list *dl, unsigned
int dl_flags)
*
* The VSP1_DL_FRAME_END_INTERNAL flag indicates that the display list that
just
* became active had been queued with the internal notification flag.
+ *
+ * The VSP1_DL_FRAME_END_WRITEBACK flag indicates that the previously active
+ * display list had been queued with the writeback flag.
*/
unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager *dlm)
{
@@ -995,6 +998,17 @@ unsigned int vsp1_dlm_irq_frame_end(struct vsp1_dl_manager
*dlm)
if (status & VI6_STATUS_FLD_STD(dlm->index))
goto done;
+ /*
+* If the active display list has the writeback flag set, the frame
+* completion marks the end of the writeback capture. Return the
+* VSP1_DL_FRAME_END_WRITEBACK flag and reset the display list's
+* writeback flag.
+*/
+ if (dlm->active && (dlm->active->flags & VSP1_DL_FRAME_END_WRITEBACK)) {
+ flags |= VSP1_DL_FRAME_END_WRITEBACK;
+ dlm->active->flags &= ~VSP1_DL_FRAME_END_WRITEBACK;
+ }
+
/*
* The device starts processing the queued display list right after the
* frame end interrupt. The display list thus becomes active.
diff --git a/drivers/media/platform/vsp1/vsp1_dl.h
b/drivers/media/platform/vsp1/vsp1_dl.h
index e0fdb145e6ed..4d7bcfdc9bd9 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.h
+++ b/drivers/media/platform/vsp1/vsp1_dl.h
@@ -18,7 +18,8 @@ struct vsp1_dl_list;
struct vsp1_dl_manager;
#define VSP1_DL_FRAME_END_COMPLETEDBIT(0)
-#define VSP1_DL_FRAME_END_INTERNAL BIT(1)
+#define VSP1_DL_FRAME_END_WRITEBACKBIT(1)
+#define VSP1_DL_FRAME_END_INTERNAL BIT(2)
/**
* struct vsp1_dl_ext_cmd - Extended Display command
diff --git a/drivers/media/platform/vsp1/vsp1_drm.c
b/drivers/media/platform/vsp1/vsp1_drm.c
index 0367f88135bf..16826bf184c7 100644
--- a/drivers/media/platform/vsp1/vsp1_drm.c
+++ b/drivers/media/platform/vsp1/vsp1_drm.c
@@ -37,7 +37,9 @@ static void vsp1_du_pipeline_frame_end(struct vsp1_pipeline
*pipe,
if (drm_pipe->du_complete) {
struct vsp1_entity *uif = drm_pipe->uif;
- unsigned int status = completion & VSP1_DU_STATUS_COMPLETE;
+ unsigned int status = completion
+ & (VSP1_DU_STATUS_COMPLETE |
+ VSP1_DU_STATUS_WRITEBACK);
u32 crc;
crc = uif ? vsp1_uif_get_crc(to_uif(>subdev)) : 0;
@@ -541,6 +543,8 @@ static void vsp1_du_pipeline_configure(struct vsp1_pipeline
*pipe)
if (drm_pipe->force_brx_release)
dl_flags |= VSP1_DL_FRAME_END_INTERNAL;
+ if (pipe->output->writeback)
+ dl_flags |= VSP1_DL_FRAME_END_WRITEBACK;
dl = vsp1_dl_list_get(pipe->output->dlm);
dlb = vsp1_dl_list_get_body0(dl);
@@ -870,12 +874,31 @@ void vsp1_du_atomic_flush(struct device *dev, unsigned
int pipe_index,
struct vsp1_device *vsp1 = dev_get_drvdata(dev);
struct vsp1_drm_pipeline *drm_pipe = >drm->pipe[pipe_index];
struct vsp1_pipeline *pipe = _pipe->pipe;
+ int ret;
drm_pipe->crc = cfg->crc;
mutex_lock(>drm->lock);
+
+ if (pipe->output->has_writeback && cfg->writeback.pixelformat) {
+ const struct vsp1_du_writeback_config *wb_cfg = >writeback;
+
+ ret = vsp1_du_pipeline_set_rwpf_format(vsp1, pipe->output,
+ wb_cfg->pixelformat,
+ wb_cfg->pitch);
+ if (WARN_ON(ret < 0))
+ goto done;
+
+ pipe->output->mem.addr[0] = wb_cfg->mem[0];
+ pipe->output->mem.addr[1] = wb_cfg->mem[1];
+ pipe->output->mem.addr[2] = wb_cfg->mem[2];
+ pipe->output->writeback = true;
+ }
+
vsp1_du_pipeline_setup_inputs(vsp1, pipe);
vsp1_du_pipeline_configure(pipe);
+
+done:
mutex_unlock(>drm->lock);
}
[PATCH v6 07/18] media: vsp1: dl: Allow chained display lists for display pipelines
Refactor the display list header setup to allow chained display lists
with display pipelines. Chain the display lists as for mem-to-mem
pipelines, but enable the frame end interrupt for every list as display
pipelines have a single list per frame.
This feature will be used to disable writeback exactly one frame after
enabling it by chaining a writeback disable display list.
Signed-off-by: Laurent Pinchart
---
drivers/media/platform/vsp1/vsp1_dl.c | 35 ++-
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_dl.c
b/drivers/media/platform/vsp1/vsp1_dl.c
index 886b3a69d329..ed7cda4130f2 100644
--- a/drivers/media/platform/vsp1/vsp1_dl.c
+++ b/drivers/media/platform/vsp1/vsp1_dl.c
@@ -770,17 +770,35 @@ static void vsp1_dl_list_fill_header(struct vsp1_dl_list
*dl, bool is_last)
}
dl->header->num_lists = num_lists;
+ dl->header->flags = 0;
- if (!list_empty(>chain) && !is_last) {
+ /*
+* Enable the interrupt for the end of each frame. In continuous mode
+* chained lists are used with one list per frame, so enable the
+* interrupt for each list. In singleshot mode chained lists are used
+* to partition a single frame, so enable the interrupt for the last
+* list only.
+*/
+ if (!dlm->singleshot || is_last)
+ dl->header->flags |= VSP1_DLH_INT_ENABLE;
+
+ /*
+* In continuous mode enable auto-start for all lists, as the VSP must
+* loop on the same list until a new one is queued. In singleshot mode
+* enable auto-start for all lists but the last to chain processing of
+* partitions without software intervention.
+*/
+ if (!dlm->singleshot || !is_last)
+ dl->header->flags |= VSP1_DLH_AUTO_START;
+
+ if (!is_last) {
/*
-* If this display list's chain is not empty, we are on a list,
-* and the next item is the display list that we must queue for
-* automatic processing by the hardware.
+* If this is not the last display list in the chain, queue the
+* next item for automatic processing by the hardware.
*/
struct vsp1_dl_list *next = list_next_entry(dl, chain);
dl->header->next_header = next->dma;
- dl->header->flags = VSP1_DLH_AUTO_START;
} else if (!dlm->singleshot) {
/*
* if the display list manager works in continuous mode, the VSP
@@ -788,13 +806,6 @@ static void vsp1_dl_list_fill_header(struct vsp1_dl_list
*dl, bool is_last)
* instructed to do otherwise.
*/
dl->header->next_header = dl->dma;
- dl->header->flags = VSP1_DLH_INT_ENABLE | VSP1_DLH_AUTO_START;
- } else {
- /*
-* Otherwise, in mem-to-mem mode, we work in single-shot mode
-* and the next display list must not be started automatically.
-*/
- dl->header->flags = VSP1_DLH_INT_ENABLE;
}
if (!dl->extension)
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 02/18] media: vsp1: wpf: Fix partition configuration for display pipelines
When configuring partitions for memory-to-memory pipelines, the WPF
accesses data of the current partition through pipe->partition.
Writeback support will require full configuration of the WPF while not
providing a valid pipe->partition. Rework the configuration code to fall
back to the full image width in that case, as is already done for the
part of the configuration currently relevant for display pipelines.
Signed-off-by: Laurent Pinchart
Reviewed-by: Kieran Bingham
---
drivers/media/platform/vsp1/vsp1_wpf.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/media/platform/vsp1/vsp1_wpf.c
b/drivers/media/platform/vsp1/vsp1_wpf.c
index 32bb207b2007..a07c5944b598 100644
--- a/drivers/media/platform/vsp1/vsp1_wpf.c
+++ b/drivers/media/platform/vsp1/vsp1_wpf.c
@@ -362,6 +362,7 @@ static void wpf_configure_partition(struct vsp1_entity
*entity,
const struct vsp1_format_info *fmtinfo = wpf->fmtinfo;
unsigned int width;
unsigned int height;
+ unsigned int left;
unsigned int offset;
unsigned int flip;
unsigned int i;
@@ -371,13 +372,16 @@ static void wpf_configure_partition(struct vsp1_entity
*entity,
RWPF_PAD_SINK);
width = sink_format->width;
height = sink_format->height;
+ left = 0;
/*
* Cropping. The partition algorithm can split the image into
* multiple slices.
*/
- if (pipe->partitions > 1)
+ if (pipe->partitions > 1) {
width = pipe->partition->wpf.width;
+ left = pipe->partition->wpf.left;
+ }
vsp1_wpf_write(wpf, dlb, VI6_WPF_HSZCLIP, VI6_WPF_SZCLIP_EN |
(0 << VI6_WPF_SZCLIP_OFST_SHIFT) |
@@ -408,13 +412,11 @@ static void wpf_configure_partition(struct vsp1_entity
*entity,
flip = wpf->flip.active;
if (flip & BIT(WPF_CTRL_HFLIP) && !wpf->flip.rotate)
- offset = format->width - pipe->partition->wpf.left
- - pipe->partition->wpf.width;
+ offset = format->width - left - width;
else if (flip & BIT(WPF_CTRL_VFLIP) && wpf->flip.rotate)
- offset = format->height - pipe->partition->wpf.left
- - pipe->partition->wpf.width;
+ offset = format->height - left - width;
else
- offset = pipe->partition->wpf.left;
+ offset = left;
for (i = 0; i < format->num_planes; ++i) {
unsigned int hsub = i > 0 ? fmtinfo->hsub : 1;
@@ -436,7 +438,7 @@ static void wpf_configure_partition(struct vsp1_entity
*entity,
* image height.
*/
if (wpf->flip.rotate)
- height = pipe->partition->wpf.width;
+ height = width;
else
height = format->height;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 13/18] drm: writeback: Fix leak of writeback job
Writeback jobs are allocated when the WRITEBACK_FB_ID is set, and
deleted when the jobs complete. This results in both a memory leak of
the job and a leak of the framebuffer if the atomic commit returns
before the job is queued for processing, for instance if the atomic
check fails or if the commit runs in test-only mode.
Fix this by implementing the drm_writeback_cleanup_job() function and
calling it from __drm_atomic_helper_connector_destroy_state(). As
writeback jobs are removed from the state when they're queued for
processing, any job left in the state when the state gets destroyed
needs to be cleaned up.
The existing declaration of the drm_writeback_cleanup_job() function
without an implementation hints that this problem was considered, but
never addressed.
Signed-off-by: Laurent Pinchart
Reviewed-by: Brian Starkey
Acked-by: Liviu Dudau
---
Changes since v5:
- Export drm_writeback_cleanup_job()
---
drivers/gpu/drm/drm_atomic_state_helper.c | 4
drivers/gpu/drm/drm_writeback.c | 14 +++---
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index 4985384e51f6..59ffb6b9c745 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -412,6 +413,9 @@ __drm_atomic_helper_connector_destroy_state(struct
drm_connector_state *state)
if (state->commit)
drm_crtc_commit_put(state->commit);
+
+ if (state->writeback_job)
+ drm_writeback_cleanup_job(state->writeback_job);
}
EXPORT_SYMBOL(__drm_atomic_helper_connector_destroy_state);
diff --git a/drivers/gpu/drm/drm_writeback.c b/drivers/gpu/drm/drm_writeback.c
index 338b993d7c9f..1b497d3530b5 100644
--- a/drivers/gpu/drm/drm_writeback.c
+++ b/drivers/gpu/drm/drm_writeback.c
@@ -273,6 +273,15 @@ void drm_writeback_queue_job(struct
drm_writeback_connector *wb_connector,
}
EXPORT_SYMBOL(drm_writeback_queue_job);
+void drm_writeback_cleanup_job(struct drm_writeback_job *job)
+{
+ if (job->fb)
+ drm_framebuffer_put(job->fb);
+
+ kfree(job);
+}
+EXPORT_SYMBOL(drm_writeback_cleanup_job);
+
/*
* @cleanup_work: deferred cleanup of a writeback job
*
@@ -285,10 +294,9 @@ static void cleanup_work(struct work_struct *work)
struct drm_writeback_job *job = container_of(work,
struct drm_writeback_job,
cleanup_work);
- drm_framebuffer_put(job->fb);
- kfree(job);
-}
+ drm_writeback_cleanup_job(job);
+}
/**
* drm_writeback_signal_completion - Signal the completion of a writeback job
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 15/19] drm/msm: Remove prototypes for non-existing functions
On Thu, Feb 21, 2019 at 12:39:24PM +0200, Laurent Pinchart wrote: > Forgot to CC Rob, sorry about that. Rob, could you take this in your tree ? > On Thu, Feb 21, 2019 at 12:32:08PM +0200, Laurent Pinchart wrote: > > The msm_atomic_state_clear() and msm_atomic_state_free() functions are > > declared but never defined. Remove their prototypes. > > > > Signed-off-by: Laurent Pinchart > > --- > > drivers/gpu/drm/msm/msm_drv.h | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/msm/msm_drv.h b/drivers/gpu/drm/msm/msm_drv.h > > index 4e0c6c2f9a86..8f0287e75efb 100644 > > --- a/drivers/gpu/drm/msm/msm_drv.h > > +++ b/drivers/gpu/drm/msm/msm_drv.h > > @@ -240,8 +240,6 @@ int msm_atomic_prepare_fb(struct drm_plane *plane, > > struct drm_plane_state *new_state); > > void msm_atomic_commit_tail(struct drm_atomic_state *state); > > struct drm_atomic_state *msm_atomic_state_alloc(struct drm_device *dev); > > -void msm_atomic_state_clear(struct drm_atomic_state *state); > > -void msm_atomic_state_free(struct drm_atomic_state *state); > > > > int msm_gem_init_vma(struct msm_gem_address_space *aspace, > > struct msm_gem_vma *vma, int npages); -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PULL] drm-intel-next-fixes
Hi Dave and Daniel, Here goes drm-intel-next-fixes-2019-03-12: - HDCP state handling in ddi_update_pipe - Protect i915_active iterators from the shrinker - Reacquire priolist cache after dropping the engine lock - (Selftest) Always free spinner on __sseu_prepare error - Acquire breadcrumb ref before canceling - Fix atomic state leak on HDMI link reset - Relax mmap VMA check Thanks, Rodrigo. The following changes since commit 8d451a4b6e9f4b52ae3d4cafe17486d8d0c6afb0: Merge tag 'drm-misc-next-2019-02-11' of git://anongit.freedesktop.org/drm/drm-misc into drm-next (2019-02-14 14:07:18 +0100) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-03-12 for you to fetch changes up to ca22f32a6296cbfa29de56328c8505560a18cfa8: drm/i915: Relax mmap VMA check (2019-03-08 09:52:55 -0800) - HDCP state handling in ddi_update_pipe - Protect i915_active iterators from the shrinker - Reacquire priolist cache after dropping the engine lock - (Selftest) Always free spinner on __sseu_prepare error - Acquire breadcrumb ref before canceling - Fix atomic state leak on HDMI link reset - Relax mmap VMA check Chris Wilson (4): drm/i915: Protect i915_active iterators from the shrinker drm/i915: Reacquire priolist cache after dropping the engine lock drm/i915/selftests: Always free spinner on __sseu_prepare error drm/i915: Acquire breadcrumb ref before cancelling José Roberto de Souza (1): drm/i915: Fix atomic state leak when resetting HDMI link Ramalingam C (1): drm/i915: HDCP state handling in ddi_update_pipe Tvrtko Ursulin (1): drm/i915: Relax mmap VMA check drivers/gpu/drm/i915/i915_active.c| 36 drivers/gpu/drm/i915/i915_gem.c | 3 +- drivers/gpu/drm/i915/i915_scheduler.c | 27 + drivers/gpu/drm/i915/intel_breadcrumbs.c | 18 +++--- drivers/gpu/drm/i915/intel_ddi.c | 14 +++-- drivers/gpu/drm/i915/selftests/i915_gem_context.c | 69 +++ 6 files changed, 94 insertions(+), 73 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 16/19] drm: rcar-du: Fix rcar_du_crtc structure documentation
Hi Laurent,
On 12/03/2019 15:24, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Mon, Mar 11, 2019 at 10:57:15PM +, Kieran Bingham wrote:
>> On 21/02/2019 10:32, Laurent Pinchart wrote:
>>> The rcar_du_crtc structure index field contains the CRTC hardware index,
>>> not the hardware and software index. Update the documentation
>>> accordingly.
>>
>> Should this have a fixes tag? It's only trivial - but if so:
>>
>> Fixes: 5361cc7f8e91 ("drm: rcar-du: Split CRTC handling to support
>> hardware indexing")
>
> I'll add it for correctness, I just hope it won't be automatically
> backported to stable.
I would expect that it should only be backported if the patch it fixes
(5361cc7f8e91) has also been backported?
>
>> Either way,
>>
>> Reviewed-by: Kieran Bingham
>>
>>> Signed-off-by: Laurent Pinchart
>>> ---
>>> drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>>> b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>>> index bcb35b0b7612..c478953be092 100644
>>> --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
>>> @@ -27,7 +27,7 @@ struct rcar_du_vsp;
>>> * @clock: the CRTC functional clock
>>> * @extclock: external pixel dot clock (optional)
>>> * @mmio_offset: offset of the CRTC registers in the DU MMIO block
>>> - * @index: CRTC software and hardware index
>>> + * @index: CRTC hardware index
>>> * @initialized: whether the CRTC has been initialized and clocks enabled
>>> * @dsysr: cached value of the DSYSR register
>>> * @vblank_enable: whether vblank events are enabled on this CRTC
>
--
Regards
--
Kieran
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: Add helpers for locking an array of BO reservations.
On Tue, Mar 12, 2019 at 12:37 PM Eric Anholt wrote: > > Rob Herring writes: > > > On Fri, Mar 8, 2019 at 10:17 AM Eric Anholt wrote: > >> > >> Now that we have the reservation object in the GEM object, it's easy > >> to provide a helper for this common case. Noticed while reviewing > >> panfrost and lima drivers. This particular version came out of v3d, > >> which in turn was a copy from vc4. > >> > >> Signed-off-by: Eric Anholt > >> --- > >> drivers/gpu/drm/drm_gem.c | 76 +++ > >> include/drm/drm_gem.h | 4 +++ > >> 2 files changed, 80 insertions(+) > > > > Sweet! I was about to go write this same patch. You are changing the > > license from GPL to MIT copying the v3d version, but I guess you have > > rights to do that. > > > > FWIW, > > > > Acked-by: Rob Herring > > Was this just for this one patch, or the series? I don't think I can > merge without a consumer. Sure, it can be for patches 1-3. Patch 4 is dependent on me sending out the shmem helpers again. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/7] dt-bindings: mfd: add bindings for SAM9X60 HLCD controller
On Tue, 5 Mar 2019 10:07:47 +, wrote: > From: Claudiu Beznea > > Add new compatible string for the HLCD controller on SAM9X60 SoC. > > Signed-off-by: Claudiu Beznea > --- > Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt | 1 + > 1 file changed, 1 insertion(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] dt-bindings: display: armada: Document bus-width property
On Mon, 4 Mar 2019 21:20:06 +0100, Lubomir Rintel wrote: > This makes it possible to choose a different pixel format for the > endpoint. Modelled after what other LCD controllers use, including > marvell,pxa2xx-lcdc and atmel,hlcdc-display-controller and perhaps more. > > Signed-off-by: Lubomir Rintel > --- > .../devicetree/bindings/display/marvell,armada-lcdc.txt | 6 ++ > 1 file changed, 6 insertions(+) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] dt-bindings: display: armada: Add more compatible strings
On Mon, Mar 04, 2019 at 09:20:05PM +0100, Lubomir Rintel wrote: > There's a generic compatible string and the driver will work on a MMP2 as > well, using the same binding. > > Signed-off-by: Lubomir Rintel > > --- > Changes since v1: > - Added marvell,armada-lcdc compatible string. > > .../devicetree/bindings/display/marvell,armada-lcdc.txt | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt > b/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt > index 2606a8efc956..4ef66bc2845c 100644 > --- a/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt > +++ b/Documentation/devicetree/bindings/display/marvell,armada-lcdc.txt > @@ -3,7 +3,9 @@ Marvell Armada LCD controller > > Required properties: > > - - compatible: value should be "marvell,dove-lcd". > + - compatible: value should be "marvell,armada-lcdc" along with > + "marvell,dove-lcd" or "marvell,mmp2-lcd", depending on the > + exact SoC model. It is not exactly clear what the order is here. The preferred form is: compatible: must be one of: a b c followed by 'fallback' So "marvell,armada-lcdc" is the fallback, but you can't start requiring the existing "marvell,dove-lcd" to have a fallback. At least you can't depend on that. > - reg: base address and size of the LCD controller > - interrupts: single interrupt number for the LCD controller > > -- > 2.20.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 3/5] dt-bindings: display: armada: Improve the LCDC documentation
On Mon, 4 Mar 2019 21:20:04 +0100, Lubomir Rintel wrote: > The port is a child, not a property. And should be accompanied by an > example. Plus a pair of cosmetic changes that don't seem to deserve a > separate commit. > > Signed-off-by: Lubomir Rintel > > --- > Changes since v1: > - Minor adjustments to the commit message wording. > > .../bindings/display/marvell,armada-lcdc.txt | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] dt-bindings: reserved-memory: Add binding for Armada framebuffer
On Mon, 4 Mar 2019 21:20:02 +0100, Lubomir Rintel wrote: > This is the binding for memory that is set aside for allocation of Marvell > Armada framebuffer objects. > > Signed-off-by: Lubomir Rintel > > --- > Changes since v1: > - Moved from bindings/display/armada/ > - Removed the marvell,dove-framebuffer string > - Added to the MAINTAINERS entry > > .../marvell,armada-framebuffer.txt| 22 +++ > MAINTAINERS | 1 + > 2 files changed, 23 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/reserved-memory/marvell,armada-framebuffer.txt > Reviewed-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 10/10] drm/arm/malidp: Added support for AFBC modifiers for all layers except DE_SMART
From: Ayan Kumar Halder
The list of modifiers to be supported for each plane has been dynamically
generated
from 'malidp_format_modifiers[]' and 'malidp_hw_regmap->features'.
Changes from v1:-
1. Replaced DRM_ERROR() with DRM_DEBUG_KMS() in malidp_format_mod_supported()
to report unsupported modifiers.
Changes from v2:-
1. Removed malidp_format_mod_supported() from the current patch. This has been
added
in "PATCH 7/12"
2. Dynamically generate the list of modifiers (to be supported for each plane)
from
'malidp_format_modifiers' and features.
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_drv.c| 1 +
drivers/gpu/drm/arm/malidp_planes.c | 31 ---
2 files changed, 29 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index 4106f5d..21725c9 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -391,6 +391,7 @@ static int malidp_init(struct drm_device *drm)
drm->mode_config.max_height = hwdev->max_line_size;
drm->mode_config.funcs = _mode_config_funcs;
drm->mode_config.helper_private = _mode_config_helpers;
+ drm->mode_config.allow_fb_modifiers = true;
ret = malidp_crtc_init(drm);
if (ret)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 044bf7f..d42e0ea 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -939,7 +939,26 @@ int malidp_de_planes_init(struct drm_device *drm)
BIT(DRM_MODE_BLEND_PREMULTI) |
BIT(DRM_MODE_BLEND_COVERAGE);
u32 *formats;
- int ret, i, j, n;
+ int ret, i = 0, j = 0, n;
+ u64 supported_modifiers[MODIFIERS_COUNT_MAX];
+ const u64 *modifiers;
+
+ modifiers = malidp_format_modifiers;
+
+ if (!(map->features & MALIDP_DEVICE_AFBC_SUPPORT_SPLIT)) {
+ /*
+* Since our hardware does not support SPLIT, so build the list
+* of supported modifiers excluding SPLIT ones.
+*/
+ while (*modifiers != DRM_FORMAT_MOD_INVALID) {
+ if (!(*modifiers & AFBC_SPLIT))
+ supported_modifiers[j++] = *modifiers;
+
+ modifiers++;
+ }
+ supported_modifiers[j++] = DRM_FORMAT_MOD_INVALID;
+ modifiers = supported_modifiers;
+ }
formats = kcalloc(map->n_pixel_formats, sizeof(*formats), GFP_KERNEL);
if (!formats) {
@@ -964,9 +983,15 @@ int malidp_de_planes_init(struct drm_device *drm)
plane_type = (i == 0) ? DRM_PLANE_TYPE_PRIMARY :
DRM_PLANE_TYPE_OVERLAY;
+
+ /*
+* All the layers except smart layer supports AFBC modifiers.
+*/
ret = drm_universal_plane_init(drm, >base, crtcs,
- _de_plane_funcs, formats,
- n, NULL, plane_type, NULL);
+ _de_plane_funcs, formats, n,
+ (id == DE_SMART) ? NULL : modifiers, plane_type,
+ NULL);
+
if (ret < 0)
goto cleanup;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 08/10] drm/arm/malidp:- Use the newly introduced malidp_format_get_bpp() instead of relying on cpp for calculating framebuffer size
From: Ayan Kumar Halder
Formats like DRM_FORMAT_VUY101010, DRM_FORMAT_YUV420_8BIT and
DRM_FORMAT_YUV420_10BIT are expressed in bits per pixel as they have a non
integer value of cpp (thus denoted as '0' in drm_format_info[]). Therefore,
the calculation of AFBC framebuffer size needs to use malidp_format_get_bpp().
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_drv.c | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index c697664..4106f5d 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -298,6 +298,7 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
struct drm_gem_object *objs = NULL;
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
+ int bpp = 0;
switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
case AFBC_SIZE_16X16:
@@ -314,15 +315,19 @@ malidp_verify_afbc_framebuffer_size(struct drm_device
*dev,
n_superblocks = (mode_cmd->width / afbc_superblock_width) *
(mode_cmd->height / afbc_superblock_height);
- afbc_superblock_size = info->cpp[0] * afbc_superblock_width *
- afbc_superblock_height;
+ bpp = malidp_format_get_bpp(info->format);
+
+ afbc_superblock_size = (bpp * afbc_superblock_width *
afbc_superblock_height)
+ / BITS_PER_BYTE;
afbc_size = ALIGN(n_superblocks * AFBC_HEADER_SIZE,
AFBC_SUPERBLK_ALIGNMENT);
afbc_size += n_superblocks * ALIGN(afbc_superblock_size,
AFBC_SUPERBLK_ALIGNMENT);
- if (mode_cmd->width * info->cpp[0] != mode_cmd->pitches[0]) {
- DRM_DEBUG_KMS("Invalid value of pitch (=%u) should be same as
width (=%u) * cpp (=%u)\n",
- mode_cmd->pitches[0], mode_cmd->width,
info->cpp[0]);
+ if ((mode_cmd->width * bpp) != (mode_cmd->pitches[0] * BITS_PER_BYTE)) {
+ DRM_DEBUG_KMS("Invalid value of (pitch * BITS_PER_BYTE) (=%u) "
+ "should be same as width (=%u) * bpp (=%u)\n",
+ (mode_cmd->pitches[0] * BITS_PER_BYTE),
+ mode_cmd->width, bpp);
return false;
}
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 09/10] drm/arm/malidp:- Disregard the pitch alignment constraint for AFBC framebuffer.
From: Ayan Kumar Halder
Considering the fact that some of the AFBC specific pixel formats are expressed
in bits per pixel (ie bpp which is not byte aligned), the pitch (ie width * bpp)
is not guaranteed to be aligned to burst size (ie 8 or 16 bytes).
For example, DRM_FORMAT_VUY101010 is 30 bits per pixel. For a framebuffer of
width 32 pixels, the pitch will be 120 bytes which is not aligned to burst size
(ie 16 bytes) for DP650.
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Acked-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_planes.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_planes.c
b/drivers/gpu/drm/arm/malidp_planes.c
index 3dc8a6f..044bf7f 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -531,8 +531,8 @@ static int malidp_de_plane_check(struct drm_plane *plane,
for (i = 0; i < ms->n_planes; i++) {
u8 alignment = malidp_hw_get_pitch_align(mp->hwdev, rotated);
- if ((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
- & (alignment - 1)) {
+ if (((fb->pitches[i] * drm_format_info_block_height(fb->format,
i))
+ & (alignment - 1)) && !(fb->modifier)) {
DRM_DEBUG_KMS("Invalid pitch %u for plane %d\n",
fb->pitches[i], i);
return -EINVAL;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 03/10] drm/arm/malidp: Set the AFBC register bits if the framebuffer has AFBC modifier
From: Ayan Kumar Halder
Added the AFBC decoder registers for DP500 , DP550 and DP650.
These registers control the processing of AFBC buffers. It controls various
features like AFBC decoder enable, lossless transformation and block split
as well as setting of the left, right, top and bottom cropping of AFBC
buffers (in number of pixels).
All the layers (except DE_SMART) support framebuffers with AFBC modifiers.
One needs to set the pixel values of the top, left, bottom and right
cropping for the AFBC framebuffer.
Cropping an AFBC framebuffer is controlled by the AFBC crop registers.
In that case, the layer input size registers should be configured with
framebuffer's dimensions and not with drm_plane_state source width/height
values (which is used for non AFBC framebuffer to denote cropping).
Changes from v1:
- Removed the "if (fb->modifier)" check from malidp_de_plane_update()
and added it in malidp_de_set_plane_afbc(). This will consolidate all the
AFBC specific register configurations in a single function ie
malidp_de_set_plane_afbc().
Changes from v2:
- For AFBC framebuffer, layer input size register should be set to
framebuffer's width and height.
Changes from v3:
- Rebased on top of latest drm-misc-next
- Some cleanups/sanity changes based on Liviu's comments
Changes from v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_hw.c | 30 ++
drivers/gpu/drm/arm/malidp_hw.h | 2 +
drivers/gpu/drm/arm/malidp_planes.c | 107
drivers/gpu/drm/arm/malidp_regs.h | 20 +++
4 files changed, 136 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index b9bed11..64c2ca3 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -94,11 +94,14 @@ static const struct malidp_layer malidp500_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP500_DE_LV_BASE, MALIDP500_DE_LV_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP500_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP500_DE_LV_AD_CTRL },
{ DE_GRAPHICS1, MALIDP500_DE_LG1_BASE, MALIDP500_DE_LG1_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP500_DE_LG1_AD_CTRL },
{ DE_GRAPHICS2, MALIDP500_DE_LG2_BASE, MALIDP500_DE_LG2_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP500_DE_LG2_AD_CTRL },
};
static const struct malidp_layer malidp550_layers[] = {
@@ -106,13 +109,16 @@ static const struct malidp_layer malidp550_layers[] = {
* yuv2rgb matrix offset, mmu control register offset,
rotation_features
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
- MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY },
+ MALIDP_DE_LG_STRIDE, 0, 0, ROTATE_ANY,
+ MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
- MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY },
+ MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB, 0, ROTATE_ANY,
+ MALIDP550_DE_LV2_AD_CTRL },
{ DE_SMART, MALIDP550_DE_LS_BASE, MALIDP550_DE_LS_PTR_BASE,
- MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE },
+ MALIDP550_DE_LS_R1_STRIDE, 0, 0, ROTATE_NONE, 0 },
};
static const struct malidp_layer malidp650_layers[] = {
@@ -122,16 +128,18 @@ static const struct malidp_layer malidp650_layers[] = {
*/
{ DE_VIDEO1, MALIDP550_DE_LV1_BASE, MALIDP550_DE_LV1_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY,
+ MALIDP550_DE_LV1_AD_CTRL },
{ DE_GRAPHICS1, MALIDP550_DE_LG_BASE, MALIDP550_DE_LG_PTR_BASE,
MALIDP_DE_LG_STRIDE, 0, MALIDP650_DE_LG_MMU_CTRL,
- ROTATE_COMPRESSED },
+ ROTATE_COMPRESSED, MALIDP550_DE_LG_AD_CTRL },
{ DE_VIDEO2, MALIDP550_DE_LV2_BASE, MALIDP550_DE_LV2_PTR_BASE,
MALIDP_DE_LV_STRIDE0, MALIDP550_LV_YUV2RGB,
- MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY },
+ MALIDP650_DE_LV_MMU_CTRL, ROTATE_ANY,
+ MALIDP550_DE_LV2_AD_CTRL },
[PATCH v4 05/10] drm/arm/malidp:- Define a common list of AFBC format modifiers supported for DP500, DP550 and DP650
From: Ayan Kumar Halder
We need to define a common list of format modifiers supported by each of
the Mali display processors.
The following are the constraints with AFBC:-
1. AFBC is not supported for the formats defined in
malidp_hw_format_is_linear_only()
2. Some of the formats are supported only with AFBC modifiers. Thus we have
introduced a new function 'malidp_hw_format_is_afbc_only()' which verifies
the same.
3. AFBC_FORMAT_MOD_YTR needs to be provided for any RGB format.
4. Formats <= 16bpp cannot support AFBC_FORMAT_MOD_SPLIT.
5. CBR should not be set for non-subsampled formats.
6. SMART layer does not support framebuffer with AFBC modifiers.
Return -EINVAL for such a scenario.
7. AFBC_FORMAT_MOD_YTR is not supported for any YUV formats.
8. Formats which are subsampled cannot support AFBC_FORMAT_MOD_SPLIT.
However in DP550, YUV_420_10BIT is supported with AFBC_FORMAT_MOD_SPLIT.
This feature has been identified with
MALIDP_DEVICE_AFBC_YUV_420_10_SUPPORT_SPLIT.
9. In DP550 and DP650, for YUYV, the hardware supports different
format-ids to be used with and without AFBC modifier. We have used the
feature 'MALIDP_DEVICE_AFBC_YUYV_USE_422_P2' to identify this
characteristic.
10. DP500 does not support split mode (ie AFBC_FORMAT_MOD_SPLIT). We have
used the feature 'MALIDP_DEVICE_AFBC_SUPPORT_SPLIT' to identify the DPs
which support SPLIT mode.
11. DP550 supports YUV420 with split mode. We have defined the feature
'AFBC_SUPPORT_SPLIT_WITH_YUV_420_10' to identify this characteristic.
Changes since v1:-
- Merged https://patchwork.freedesktop.org/patch/265215/ into this patch
- As Liviu pointed out in the last patch, we can pull the checks outside
of the 'while (*modifiers != DRM_FORMAT_MOD_INVALID)' loop
- Rebased
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_drv.c| 32 ++---
drivers/gpu/drm/arm/malidp_drv.h| 6 ++
drivers/gpu/drm/arm/malidp_hw.c | 96 +--
drivers/gpu/drm/arm/malidp_hw.h | 24 +--
drivers/gpu/drm/arm/malidp_mw.c | 2 +-
drivers/gpu/drm/arm/malidp_planes.c | 126 +++-
6 files changed, 246 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
index ab50ad0..c697664 100644
--- a/drivers/gpu/drm/arm/malidp_drv.c
+++ b/drivers/gpu/drm/arm/malidp_drv.c
@@ -264,37 +264,17 @@ static bool
malidp_verify_afbc_framebuffer_caps(struct drm_device *dev,
const struct drm_mode_fb_cmd2 *mode_cmd)
{
- const struct drm_format_info *info;
-
- if ((mode_cmd->modifier[0] >> 56) != DRM_FORMAT_MOD_VENDOR_ARM) {
- DRM_DEBUG_KMS("Unknown modifier (not Arm)\n");
+ if (malidp_format_mod_supported(dev, mode_cmd->pixel_format,
+ mode_cmd->modifier[0]) == false)
return false;
- }
-
- if (mode_cmd->modifier[0] &
- ~DRM_FORMAT_MOD_ARM_AFBC(AFBC_MOD_VALID_BITS)) {
- DRM_DEBUG_KMS("Unsupported modifiers\n");
- return false;
- }
-
- info = drm_get_format_info(dev, mode_cmd);
- if (!info) {
- DRM_DEBUG_KMS("Unable to get the format information\n");
- return false;
- }
-
- if (info->num_planes != 1) {
- DRM_DEBUG_KMS("AFBC buffers expect one plane\n");
- return false;
- }
if (mode_cmd->offsets[0] != 0) {
DRM_DEBUG_KMS("AFBC buffers' plane offset should be 0\n");
return false;
}
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
if ((mode_cmd->width % 16) || (mode_cmd->height % 16)) {
DRM_DEBUG_KMS("AFBC buffers must be aligned to 16
pixels\n");
return false;
@@ -319,8 +299,8 @@ malidp_verify_afbc_framebuffer_size(struct drm_device *dev,
u32 afbc_superblock_size = 0, afbc_superblock_height = 0;
u32 afbc_superblock_width = 0, afbc_size = 0;
- switch (mode_cmd->modifier[0] & AFBC_FORMAT_MOD_BLOCK_SIZE_MASK) {
- case AFBC_FORMAT_MOD_BLOCK_SIZE_16x16:
+ switch (mode_cmd->modifier[0] & AFBC_SIZE_MASK) {
+ case AFBC_SIZE_16X16:
afbc_superblock_height = 16;
afbc_superblock_width = 16;
break;
diff --git a/drivers/gpu/drm/arm/malidp_drv.h b/drivers/gpu/drm/arm/malidp_drv.h
index b76c86f..019a682 100644
--- a/drivers/gpu/drm/arm/malidp_drv.h
+++ b/drivers/gpu/drm/arm/malidp_drv.h
@@ -90,6 +90,12 @@ struct malidp_crtc_state {
int malidp_de_planes_init(struct drm_device *drm);
int
[PATCH v4 06/10] drm/arm/malidp: Specified the rotation memory requirements for AFBC YUV formats
From: Ayan Kumar Halder
The newly supported AFBC YUV formats have the following rotation memory
constraints (in DP550/DP650).
1. DRM_FORMAT_VUY888/DRM_FORMAT_VUY101010 :- It can rotate upto 8
horizontal lines in the AFBC output buffer.
2. DRM_FORMAT_YUV420_8BIT :- It can rotate upto 16 horizontal lines
in the AFBC output buffer.
Also some of the pixel formats are specified in bits per pixel (rather
than bytes per pixel), so the calculation needs to take note of this.
Besides there are some difference between DP550 and DP650 and these are
as follows:-
1. DRM_FORMAT_X0L2 (in uncompressed format) does not support rotation in
DP550. For DP650, it can rotate upto 16 horizontal lines in the AFBC
output buffer, whereas in DP550 (with AFBC), it can rotate upto 8
horizontal lines.
2. DRM_FORMAT_YUV420_10BIT :- It can rotate upto 8 horizontal lines in
dp550 and 16 horizontal lines in DP650.
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_hw.c | 101
drivers/gpu/drm/arm/malidp_hw.h | 5 +-
drivers/gpu/drm/arm/malidp_planes.c | 3 +-
3 files changed, 98 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 0ac2762..8df12e9 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -380,14 +380,39 @@ static void malidp500_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+int malidp_format_get_bpp(u32 fmt)
+{
+ int bpp = drm_format_plane_cpp(fmt, 0) * 8;
+
+ if (bpp == 0) {
+ switch (fmt) {
+ case DRM_FORMAT_VUY101010:
+ bpp = 30;
+ case DRM_FORMAT_YUV420_10BIT:
+ bpp = 15;
+ break;
+ case DRM_FORMAT_YUV420_8BIT:
+ bpp = 12;
+ break;
+ default:
+ bpp = 0;
+ }
+ }
+
+ return bpp;
+}
+
+static int malidp500_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
{
/*
* Each layer needs enough rotation memory to fit 8 lines
* worth of pixel data. Required size is then:
*size = rotated_width * (bpp / 8) * 8;
*/
- return w * drm_format_plane_cpp(fmt, 0) * 8;
+ int bpp = malidp_format_get_bpp(fmt);
+
+ return w * bpp;
}
static void malidp500_se_write_pp_coefftab(struct malidp_hw_device *hwdev,
@@ -665,9 +690,9 @@ static void malidp550_modeset(struct malidp_hw_device
*hwdev, struct videomode *
malidp_hw_clearbits(hwdev, MALIDP_DISP_FUNC_ILACED,
MALIDP_DE_DISPLAY_FUNC);
}
-static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
u16 h, u32 fmt)
+static int malidpx50_get_bytes_per_column(u32 fmt)
{
- u32 bytes_per_col;
+ u32 bytes_per_column;
switch (fmt) {
/* 8 lines at 4 bytes per pixel */
@@ -693,19 +718,77 @@ static int malidp550_rotmem_required(struct
malidp_hw_device *hwdev, u16 w, u16
case DRM_FORMAT_UYVY:
case DRM_FORMAT_YUYV:
case DRM_FORMAT_X0L0:
- case DRM_FORMAT_X0L2:
- bytes_per_col = 32;
+ bytes_per_column = 32;
break;
/* 16 lines at 1.5 bytes per pixel */
case DRM_FORMAT_NV12:
case DRM_FORMAT_YUV420:
- bytes_per_col = 24;
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_VUY888:
+ /* 16 lines at 12 bits per pixel */
+ case DRM_FORMAT_YUV420_8BIT:
+ /* 8 lines at 3 bytes per pixel */
+ case DRM_FORMAT_P010:
+ bytes_per_column = 24;
+ break;
+ /* 8 lines at 30 bits per pixel */
+ case DRM_FORMAT_VUY101010:
+ /* 16 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 30;
break;
default:
return -EINVAL;
}
- return w * bytes_per_col;
+ return bytes_per_column;
+}
+
+static int malidp550_rotmem_required(struct malidp_hw_device *hwdev, u16 w,
+u16 h, u32 fmt, bool has_modifier)
+{
+ int bytes_per_column = 0;
+
+ switch (fmt) {
+ /* 8 lines at 15 bits per pixel */
+ case DRM_FORMAT_YUV420_10BIT:
+ bytes_per_column = 15;
+ break;
+ /* Uncompressed YUV 420 10 bit single plane cannot be rotated */
+ case DRM_FORMAT_X0L2:
+ if (has_modifier)
+
[PATCH v4 07/10] drm/arm/malidp:- Writeback framebuffer does not support any modifiers
From: Ayan Kumar Halder
In malidp, the writeback pipeline does not support writing crtc output
to a framebuffer with modifiers ie the memory writeback content is
devoid of any compression or tiling, etc.
So we have added a commit check in memory writeback encoder helper function
to validate if the framebuffer has any modifier and if so, return EINVAL.
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Acked-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_mw.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/arm/malidp_mw.c b/drivers/gpu/drm/arm/malidp_mw.c
index 28cd351..2865f7a 100644
--- a/drivers/gpu/drm/arm/malidp_mw.c
+++ b/drivers/gpu/drm/arm/malidp_mw.c
@@ -141,6 +141,11 @@ malidp_mw_encoder_atomic_check(struct drm_encoder *encoder,
return -EINVAL;
}
+ if (fb->modifier) {
+ DRM_DEBUG_KMS("Writeback framebuffer does not support
modifiers\n");
+ return -EINVAL;
+ }
+
mw_state->format =
malidp_hw_get_format_id(>dev->hw->map, SE_MEMWRITE,
fb->format->format, !!fb->modifier);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 04/10] drm/arm/malidp:- Added support for new YUV formats for DP500, DP550 and DP650
From: Ayan Kumar Halder
We have added support for some AFBC only pixel formats like :-
DRM_FORMAT_YUV420_8BIT (single plane YUV 420 8 bit format)
DRM_FORMAT_VUY888 (single plane YUV 444 8 bit format)
DRM_FORMAT_VUY101010 (single plane YUV 444 10 bit format)
DRM_FORMAT_YUV420_10BIT (single plane YUV 420 10 bit format)
Generally, these formats are supported by our hardware using the same
hw-ids as the equivalent multi plane pixel formats.
Also we have added support for XYUV 444 8 and 10 bit formats
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar Halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/arm/malidp_hw.c | 22 +-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/arm/malidp_hw.c b/drivers/gpu/drm/arm/malidp_hw.c
index 64c2ca3..b4a0e11 100644
--- a/drivers/gpu/drm/arm/malidp_hw.c
+++ b/drivers/gpu/drm/arm/malidp_hw.c
@@ -49,6 +49,12 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_YUYV, DE_VIDEO1, 13 },
{ DRM_FORMAT_NV12, DE_VIDEO1 | SE_MEMWRITE, 14 },
{ DRM_FORMAT_YUV420, DE_VIDEO1, 15 },
+ { DRM_FORMAT_XYUV, DE_VIDEO1, 16 },
+ /* These are supported with AFBC only */
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1, 14 },
+ { DRM_FORMAT_VUY888, DE_VIDEO1, 16 },
+ { DRM_FORMAT_VUY101010, DE_VIDEO1, 17 },
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1, 18 }
};
#define MALIDP_ID(__group, __format) \
@@ -74,11 +80,25 @@ static const struct malidp_format_id malidp500_de_formats[]
= {
{ DRM_FORMAT_ABGR1555, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2,
MALIDP_ID(4, 1) }, \
{ DRM_FORMAT_RGB565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
2) }, \
{ DRM_FORMAT_BGR565, DE_VIDEO1 | DE_GRAPHICS1 | DE_VIDEO2, MALIDP_ID(4,
3) }, \
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XYUV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) },\
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY888, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 0) }, \
{ DRM_FORMAT_YUYV, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 2) },\
+ /* This is only supported with linear modifier */ \
{ DRM_FORMAT_UYVY, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 3) },\
{ DRM_FORMAT_NV12, DE_VIDEO1 | DE_VIDEO2 | SE_MEMWRITE, MALIDP_ID(5, 6)
}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_8BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 6) }, \
{ DRM_FORMAT_YUV420, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(5, 7) }, \
- { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}
+ /* This is only supported with linear modifier */ \
+ { DRM_FORMAT_XVYU2101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_VUY101010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 0)}, \
+ { DRM_FORMAT_X0L2, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 6)}, \
+ /* This is only supported with AFBC modifier */ \
+ { DRM_FORMAT_YUV420_10BIT, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}, \
+ { DRM_FORMAT_P010, DE_VIDEO1 | DE_VIDEO2, MALIDP_ID(6, 7)}
static const struct malidp_format_id malidp550_de_formats[] = {
MALIDP_COMMON_FORMATS,
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 01/10] drm/fourcc: Add AFBC yuv fourccs for Mali
From: Brian Starkey As we look to enable AFBC using DRM format modifiers, we run into problems which we've historically handled via vendor-private details (i.e. gralloc, on Android). AFBC (as an encoding) is fully flexible, and for example YUV data can be encoded into 1, 2 or 3 encoded "planes", much like the linear equivalents. Component order is also meaningful, as AFBC doesn't necessarily care about what each "channel" of the data it encodes contains. Therefore ABGR and RGBA can be encoded in AFBC with different representations. Similarly, 'X' components may be encoded into AFBC streams in cases where a decoder expects to decode a 4th component. In addition, AFBC is a licensable IP, meaning that to support the ecosystem we need to ensure that _all_ AFBC users are able to describe the encodings that they need. This is much better achieved by preserving meaning in the fourcc codes when they are combined with an AFBC modifier. In essence, we want to use the modifier to describe the parameters of the AFBC encode/decode, and use the fourcc code to describe the data being encoded/decoded. To do anything different would be to introduce redundancy - we would need to duplicate in the modifier information which is _already_ conveyed clearly and non-ambigiously by a fourcc code. I hope that for RGB this is non-controversial. (BGRA + MODIFIER_AFBC) is a different format from (RGBA + MODIFIER_AFBC). Possibly more controversial is that (XBGR + MODIFIER_AFBC) is different from (BGR888 + MODIFIER_AFBC). I understand that in some schemes it is not the case - but in AFBC it is so. Where we run into problems is where there are not already fourcc codes which represent the data which the AFBC encoder/decoder is processing. To that end, we want to introduce new fourcc codes to describe the data being encoded/decoded, in the places where none of the existing fourcc codes are applicable. Where we don't support an equivalent non-compressed layout, or where no "obvious" linear layout exists, we are proposing adding fourcc codes which have no associated linear layout - because any layout we proposed would be completely arbitrary. Some formats are following the naming conventions from [2]. The summary of the new formats is: DRM_FORMAT_VUY888 - Packed 8-bit YUV 444. Y followed by U then V. DRM_FORMAT_VUY101010 - Packed 10-bit YUV 444. Y followed by U then V. No defined linear encoding. DRM_FORMAT_Y210 - Packed 10-bit YUV 422. Y followed by U (then Y) then V. 10-bit samples in 16-bit words. DRM_FORMAT_Y410 - Packed 10-bit YUV 444, with 2-bit alpha. DRM_FORMAT_P210 - Semi-planar 10-bit YUV 422. Y plane, followed by interleaved U-then-V plane. 10-bit samples in 16-bit words. DRM_FORMAT_YUV420_8BIT - Packed 8-bit YUV 420. Y followed by U then V. No defined linear encoding DRM_FORMAT_YUV420_10BIT - Packed 10-bit YUV 420. Y followed by U then V. No defined linear encoding Please also note that in the absence of AFBC, we would still need to add Y410, Y210 and P210. Full rationale follows: YUV 444 8-bit, 1-plane -- The currently defined AYUV format encodes a 4th alpha component, which makes it unsuitable for representing a 3-component YUV 444 AFBC stream. The proposed[1] XYUV format which is supported by Mali-DP in linear layout is also unsuitable, because the component order is the opposite of the AFBC version, and it encodes a 4th 'X' component. DRM_FORMAT_VUY888 is the "obvious" format for a 3-component, packed, YUV 444 8-bit format, with the component order which our HW expects to encode/decode. It conforms to the same naming convention as the existing packed YUV 444 format. The naming here is meant to be consistent with DRM_FORMAT_AYUV and DRM_FORMAT_XYUV[1] YUV 444 10-bit, 1-plane --- There is no currently-defined YUV 444 10-bit format in drm_fourcc.h, irrespective of number of planes. The proposed[1] XVYU2101010 format which is supported by Mali-DP in linear layout uses the wrong component order, and also encodes a 4th 'X' component, which doesn't match the AFBC version of YUV 444 10-bit which we support. DRM_FORMAT_Y410 is the same layout as XVYU2101010, but with 2 bits of alpha. This format is supported with linear layout by Mali GPUs. The naming follows[2]. There is no "obvious" linear encoding for a 3-component 10:10:10 packed format, and so DRM_FORMAT_VUY101010 defines a component order, but not a bit encoding. Again, the naming is meant to be consistent with DRM_FORMAT_AYUV. YUV 422 8-bit, 1-plane -- The existing DRM_FORMAT_YUYV (and the other component orders) are single-planar YUV 422 8-bit formats. Following the convention of the component orders of the RGB formats, YUYV has the correct component order for our AFBC encoding (Y followed by U followed by
[PATCH v4 02/10] drm: Added a new format DRM_FORMAT_XVYU2101010
From: Ayan Kumar Halder
This new format is supported by DP550 and DP650
Changes since v3 (series):
- Added the ack
- Rebased on the latest drm-misc-next
Signed-off-by: Ayan Kumar halder
Reviewed-by: Liviu Dudau
Acked-by: Alyssa Rosenzweig
---
drivers/gpu/drm/drm_fourcc.c | 1 +
include/uapi/drm/drm_fourcc.h | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
index a9df743..3684c49 100644
--- a/drivers/gpu/drm/drm_fourcc.c
+++ b/drivers/gpu/drm/drm_fourcc.c
@@ -229,6 +229,7 @@ const struct drm_format_info *__drm_format_info(u32 format)
{ .format = DRM_FORMAT_VUY888, .depth = 0,
.num_planes = 1, .cpp = { 3, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y410,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
{ .format = DRM_FORMAT_AYUV,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .has_alpha = true,
.is_yuv = true },
+ { .format = DRM_FORMAT_XVYU2101010, .depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 1, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y210,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y212,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
{ .format = DRM_FORMAT_Y216,.depth = 0,
.num_planes = 1, .cpp = { 4, 0, 0 }, .hsub = 2, .vsub = 1, .is_yuv = true },
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index b992a38..dc99e7f 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -153,6 +153,7 @@ extern "C" {
#define DRM_FORMAT_AYUVfourcc_code('A', 'Y', 'U', 'V') /*
[31:0] A:Y:Cb:Cr 8:8:8:8 little endian */
#define DRM_FORMAT_XYUVfourcc_code('X', 'Y', 'U', 'V') /*
[31:0] X:Y:Cb:Cr 8:8:8:8 little endian */
+#define DRM_FORMAT_XVYU2101010 fourcc_code('X', 'V', '3', '0') /* [31:0]
X:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY888 fourcc_code('V', 'U', '2', '4') /* [23:0]
Cr:Cb:Y 8:8:8 little endian */
#define DRM_FORMAT_Y410fourcc_code('Y', '4', '1', '0') /*
[31:0] A:Cr:Y:Cb 2:10:10:10 little endian */
#define DRM_FORMAT_VUY101010 fourcc_code('V', 'U', '3', '0') /* Y followed
by U then V, 10:10:10. Non-linear modifier only */
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 0/4] drm/msm/a6xx: Add support for zap shader
This patch series adds support for loading the zap shader on a6xx and using it to get the GPU out of secure mode. The Adreno a5xx and a6xx GPUs boot in "secure" mode which restricts the memory the GPU is allowed to use. To get the GPU out of secure mode we need to write to a register. However some bootloaders block access to this register and require that the GPU instead perform a sequence to pull the GPU out of secure mode. This sequence requires a special "zap" shader that will execute in secure mode, clear out all the internal GPU settings and then transition to in-secure mode. This series adds support for loading and using the zap shader on a6xx assuming that the shader exists and that the bootloader supports the secure mode. If any part of the sequence fails then fall back to writing the register. If we get it wrong, then writing to the register will trigger a protection mode error and the system will go down. The actual zap shader works almost identically to the one on 5xx outside of a minor workaround for system resume. The first patch moves the a5xx specific support to the generic adreno driver. The second patch add support for the zap shader and the final two patches add the DT bindings and DT settings for setting up the reserved memory that the shader requires. Jordan Crouse (4): drm/msm/gpu: Move zap shader loading to adreno drm/msm/a6xx: Add zap shader load dt-bindings: drm/msm/gpu: Document a5xx / a6xx zap shader region arm64: dts: sdm845: Add zap shader region for GPU .../devicetree/bindings/display/msm/gpu.txt| 7 ++ arch/arm64/boot/dts/qcom/sdm845.dtsi | 11 ++ drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 109 +--- drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 38 ++- drivers/gpu/drm/msm/adreno/adreno_device.c | 1 + drivers/gpu/drm/msm/adreno/adreno_gpu.c| 113 + drivers/gpu/drm/msm/adreno/adreno_gpu.h| 6 ++ 7 files changed, 176 insertions(+), 109 deletions(-) -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 1/4] drm/msm/gpu: Move zap shader loading to adreno
a5xx and a6xx both share (mostly) the same code to load the zap shader and
bring the GPU out of secure mode. Move the formerly 5xx specific code to
adreno to make it available for a6xx too.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 109 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 113
drivers/gpu/drm/msm/adreno/adreno_gpu.h | 6 ++
3 files changed, 120 insertions(+), 108 deletions(-)
diff --git a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
index d5f5e56..e5fcefa 100644
--- a/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a5xx_gpu.c
@@ -15,9 +15,6 @@
#include
#include
#include
-#include
-#include
-#include
#include
#include
#include
@@ -30,94 +27,6 @@ static void a5xx_dump(struct msm_gpu *gpu);
#define GPU_PAS_ID 13
-static int zap_shader_load_mdt(struct msm_gpu *gpu, const char *fwname)
-{
- struct device *dev = >pdev->dev;
- const struct firmware *fw;
- struct device_node *np;
- struct resource r;
- phys_addr_t mem_phys;
- ssize_t mem_size;
- void *mem_region = NULL;
- int ret;
-
- if (!IS_ENABLED(CONFIG_ARCH_QCOM))
- return -EINVAL;
-
- np = of_get_child_by_name(dev->of_node, "zap-shader");
- if (!np)
- return -ENODEV;
-
- np = of_parse_phandle(np, "memory-region", 0);
- if (!np)
- return -EINVAL;
-
- ret = of_address_to_resource(np, 0, );
- if (ret)
- return ret;
-
- mem_phys = r.start;
- mem_size = resource_size();
-
- /* Request the MDT file for the firmware */
- fw = adreno_request_fw(to_adreno_gpu(gpu), fwname);
- if (IS_ERR(fw)) {
- DRM_DEV_ERROR(dev, "Unable to load %s\n", fwname);
- return PTR_ERR(fw);
- }
-
- /* Figure out how much memory we need */
- mem_size = qcom_mdt_get_size(fw);
- if (mem_size < 0) {
- ret = mem_size;
- goto out;
- }
-
- /* Allocate memory for the firmware image */
- mem_region = memremap(mem_phys, mem_size, MEMREMAP_WC);
- if (!mem_region) {
- ret = -ENOMEM;
- goto out;
- }
-
- /*
-* Load the rest of the MDT
-*
-* Note that we could be dealing with two different paths, since
-* with upstream linux-firmware it would be in a qcom/ subdir..
-* adreno_request_fw() handles this, but qcom_mdt_load() does
-* not. But since we've already gotten thru adreno_request_fw()
-* we know which of the two cases it is:
-*/
- if (to_adreno_gpu(gpu)->fwloc == FW_LOCATION_LEGACY) {
- ret = qcom_mdt_load(dev, fw, fwname, GPU_PAS_ID,
- mem_region, mem_phys, mem_size, NULL);
- } else {
- char *newname;
-
- newname = kasprintf(GFP_KERNEL, "qcom/%s", fwname);
-
- ret = qcom_mdt_load(dev, fw, newname, GPU_PAS_ID,
- mem_region, mem_phys, mem_size, NULL);
- kfree(newname);
- }
- if (ret)
- goto out;
-
- /* Send the image to the secure world */
- ret = qcom_scm_pas_auth_and_reset(GPU_PAS_ID);
- if (ret)
- DRM_DEV_ERROR(dev, "Unable to authorize the image\n");
-
-out:
- if (mem_region)
- memunmap(mem_region);
-
- release_firmware(fw);
-
- return ret;
-}
-
static void a5xx_flush(struct msm_gpu *gpu, struct msm_ringbuffer *ring)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -563,8 +472,6 @@ static int a5xx_zap_shader_resume(struct msm_gpu *gpu)
static int a5xx_zap_shader_init(struct msm_gpu *gpu)
{
static bool loaded;
- struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
- struct platform_device *pdev = gpu->pdev;
int ret;
/*
@@ -574,23 +481,9 @@ static int a5xx_zap_shader_init(struct msm_gpu *gpu)
if (loaded)
return a5xx_zap_shader_resume(gpu);
- /* We need SCM to be able to load the firmware */
- if (!qcom_scm_is_available()) {
- DRM_DEV_ERROR(>dev, "SCM is not available\n");
- return -EPROBE_DEFER;
- }
-
- /* Each GPU has a target specific zap shader firmware name to use */
- if (!adreno_gpu->info->zapfw) {
- DRM_DEV_ERROR(>dev,
- "Zap shader firmware file not specified for this
target\n");
- return -ENODEV;
- }
-
- ret = zap_shader_load_mdt(gpu, adreno_gpu->info->zapfw);
+ ret = adreno_zap_shader_load(gpu, GPU_PAS_ID);
loaded = !ret;
-
return ret;
}
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/adreno/adreno_gpu.c
index 2789847..a9eb58c 100644
---
[PATCH v1 2/4] drm/msm/a6xx: Add zap shader load
The a6xx GPU powers on in secure mode which restricts what memory it can
write to. To get out of secure mode the GPU driver can write to
REG_A6XX_RBBM_SECVID_TRUST_CNTL but on targets that are "secure" that
register region is blocked and writes will cause the system to go down.
For those targets we need to execute a special sequence that involves
loadinga special shader that clears the GPU registers and use a PM4
sequence to pull the GPU out of secure. Add support for loading the zap
shader and executing the secure sequence. For targets that do not support
SCM or the specific SCM sequence this should fail and we would fall back
to writing the register.
Signed-off-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 38 +-
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
2 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index fefe773..5983e47 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
@@ -10,6 +10,8 @@
#include
+#define GPU_PAS_ID 13
+
static inline bool _a6xx_check_idle(struct msm_gpu *gpu)
{
struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
@@ -343,6 +345,20 @@ static int a6xx_ucode_init(struct msm_gpu *gpu)
return 0;
}
+static int a6xx_zap_shader_init(struct msm_gpu *gpu)
+{
+ static bool loaded;
+ int ret;
+
+ if (loaded)
+ return 0;
+
+ ret = adreno_zap_shader_load(gpu, GPU_PAS_ID);
+
+ loaded = !ret;
+ return ret;
+}
+
#define A6XX_INT_MASK (A6XX_RBBM_INT_0_MASK_CP_AHB_ERROR | \
A6XX_RBBM_INT_0_MASK_RBBM_ATB_ASYNCFIFO_OVERFLOW | \
A6XX_RBBM_INT_0_MASK_CP_HW_ERROR | \
@@ -491,7 +507,27 @@ static int a6xx_hw_init(struct msm_gpu *gpu)
if (ret)
goto out;
- gpu_write(gpu, REG_A6XX_RBBM_SECVID_TRUST_CNTL, 0x0);
+ /*
+* Try to load a zap shader into the secure world. If successful
+* we can use the CP to switch out of secure mode. If not then we
+* have no resource but to try to switch ourselves out manually. If we
+* guessed wrong then access to the RBBM_SECVID_TRUST_CNTL register will
+* be blocked and a permissions violation will soon follow.
+*/
+ ret = a6xx_zap_shader_init(gpu);
+ if (!ret) {
+ OUT_PKT7(gpu->rb[0], CP_SET_SECURE_MODE, 1);
+ OUT_RING(gpu->rb[0], 0x);
+
+ a6xx_flush(gpu, gpu->rb[0]);
+ if (!a6xx_idle(gpu, gpu->rb[0]))
+ return -EINVAL;
+ } else {
+ /* Print a warning so if we die, we know why */
+ dev_warn_once(gpu->dev->dev,
+ "Zap shader not enabled - using SECVID_TRUST_CNTL
instead\n");
+ gpu_write(gpu, REG_A6XX_RBBM_SECVID_TRUST_CNTL, 0x0);
+ }
out:
/*
diff --git a/drivers/gpu/drm/msm/adreno/adreno_device.c
b/drivers/gpu/drm/msm/adreno/adreno_device.c
index 714ed65..ead5f6a 100644
--- a/drivers/gpu/drm/msm/adreno/adreno_device.c
+++ b/drivers/gpu/drm/msm/adreno/adreno_device.c
@@ -155,6 +155,7 @@ static const struct adreno_info gpulist[] = {
.gmem = SZ_1M,
.inactive_period = DRM_MSM_INACTIVE_PERIOD,
.init = a6xx_gpu_init,
+ .zapfw = "a630_zap.mdt",
},
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v1 3/4] dt-bindings: drm/msm/gpu: Document a5xx / a6xx zap shader region
Describe the zap-shader node that defines a reserved memory region
to store the zap shader.
Signed-off-by: Jordan Crouse
---
Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/msm/gpu.txt
b/Documentation/devicetree/bindings/display/msm/gpu.txt
index aad1aef..1e6d870 100644
--- a/Documentation/devicetree/bindings/display/msm/gpu.txt
+++ b/Documentation/devicetree/bindings/display/msm/gpu.txt
@@ -25,6 +25,9 @@ Required properties:
- qcom,gmu: For GMU attached devices a phandle to the GMU device that will
control the power for the GPU. Applicable targets:
- qcom,adreno-630.2
+- zap-shader: For a5xx and a6xx devices this node contains a memory-region that
+ points to reserved memory to store the zap shader that can be used to help
+ bring the GPU out of secure mode.
Example 3xx/4xx/a5xx:
@@ -71,5 +74,9 @@ Example a6xx (with GMU):
operating-points-v2 = <_opp_table>;
qcom,gmu = <>;
+
+ zap-shader {
+ memory-region = <_shader_region>;
+ };
};
};
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
On Tue, Mar 12, 2019 at 06:37:57PM +0100, Noralf Trønnes wrote:
>
>
> Den 12.03.2019 18.25, skrev Ville Syrjälä:
> > On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
> >>
> >>
> >> Den 12.03.2019 17.17, skrev Ville Syrjälä:
> >>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> > This adds support for outputting kernel messages on panic().
> > A kernel message dumper is used to dump the log. The dumper iterates
> > over each DRM device and it's crtc's to find suitable framebuffers.
> >
> > All the other dumpers are run before this one except mtdoops.
> > Only atomic drivers are supported.
> >
> > Signed-off-by: Noralf Trønnes
> > ---
> > [...]
> >
> > diff --git a/include/drm/drm_framebuffer.h
> > b/include/drm/drm_framebuffer.h
> > index f0b34c977ec5..f3274798ecfe 100644
> > --- a/include/drm/drm_framebuffer.h
> > +++ b/include/drm/drm_framebuffer.h
> > @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
> > struct drm_file *file_priv, unsigned flags,
> > unsigned color, struct drm_clip_rect *clips,
> > unsigned num_clips);
> > +
> > + /**
> > +* @panic_vmap:
> > +*
> > +* Optional callback for panic handling.
> > +*
> > +* For vmapping the selected framebuffer in a panic context.
> > Must
> > +* be super careful about locking (only trylocking allowed).
> > +*
> > +* RETURNS:
> > +*
> > +* NULL if it didn't work out, otherwise an opaque cookie which
> > is
> > +* passed to @panic_draw_xy. It can be anything: vmap area,
> > structure
> > +* with more details, just a few flags, ...
> > +*/
> > + void *(*panic_vmap)(struct drm_framebuffer *fb);
>
> FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
> drivers:
>
> Framebuffers are normally tiled, writing to them with the CPU results in
> garbled output.
>
> >>
> >> In which case the driver needs to support the ->panic_draw_xy callback,
> >> or maybe it's possible to make a generic helper for tiled buffers.
> >>
> With a discrete GPU having a large amount of VRAM, the framebuffer may
> not be directly CPU accessible at all.
>
> >>
> >> I would have been nice to know how Windows works around this.
> >>
>
> There would need to be a mechanism for switching scanout to a linear,
> CPU accessible framebuffer.
> >>>
> >>> I suppose panic_vmap() could just provide a linear temp buffer
> >>> to the panic handler, and panic_unmap() could copy the contents
> >>> over to the real fb.
> >>>
> >>> That said, this approach of scribbling over the primary plane's
> >>> framebuffer has some clear limitations:
> >>> * something may overwrite the oops message before the user
> >>> can even read it
> >>
> >> When the dumper drm_panic_kmsg_dump() runs, the other CPU's should have
> >> been stopped. See panic().
> >
> > GPUs etc. may still be executing away.
> >
>
> Would it be safe to stop it in a panic situation? It would ofc be bad to
> crash the box even harder.
Some drivers/devices may have working (and hopefully even reliable)
gpu reset, some may not.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d: Fix calling drm_sched_resubmit_jobs for same sched.
They are not the same, but the guilty job belongs to only one {entity,
scheduler} pair and so we mark as guilty only for that particular entity in the
context of that scheduler only once.
Andrey
From: Eric Anholt
Sent: 12 March 2019 13:33:16
To: Grodzovsky, Andrey; dri-devel@lists.freedesktop.org;
amd-...@lists.freedesktop.org; to...@tomeuvizoso.net
Cc: Grodzovsky, Andrey
Subject: Re: [PATCH] drm/v3d: Fix calling drm_sched_resubmit_jobs for same
sched.
Andrey Grodzovsky writes:
> Also stop calling drm_sched_increase_karma multiple times.
Each v3d->queue[q].sched was initialized with a separate
drm_sched_init(). I wouldn't have thought they were all the "same
sched".
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
Den 12.03.2019 18.37, skrev Noralf Trønnes:
>
>
> Den 12.03.2019 18.25, skrev Ville Syrjälä:
>> On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
>>>
>>>
>>> Den 12.03.2019 17.17, skrev Ville Syrjälä:
On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
>> This adds support for outputting kernel messages on panic().
>> A kernel message dumper is used to dump the log. The dumper iterates
>> over each DRM device and it's crtc's to find suitable framebuffers.
>>
>> All the other dumpers are run before this one except mtdoops.
>> Only atomic drivers are supported.
>>
>> Signed-off-by: Noralf Trønnes
>> ---
>> [...]
>>
>> diff --git a/include/drm/drm_framebuffer.h
>> b/include/drm/drm_framebuffer.h
>> index f0b34c977ec5..f3274798ecfe 100644
>> --- a/include/drm/drm_framebuffer.h
>> +++ b/include/drm/drm_framebuffer.h
>> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
>> struct drm_file *file_priv, unsigned flags,
>> unsigned color, struct drm_clip_rect *clips,
>> unsigned num_clips);
>> +
>> +/**
>> + * @panic_vmap:
>> + *
>> + * Optional callback for panic handling.
>> + *
>> + * For vmapping the selected framebuffer in a panic context.
>> Must
>> + * be super careful about locking (only trylocking allowed).
>> + *
>> + * RETURNS:
>> + *
>> + * NULL if it didn't work out, otherwise an opaque cookie which
>> is
>> + * passed to @panic_draw_xy. It can be anything: vmap area,
>> structure
>> + * with more details, just a few flags, ...
>> + */
>> +void *(*panic_vmap)(struct drm_framebuffer *fb);
>
> FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
> drivers:
>
> Framebuffers are normally tiled, writing to them with the CPU results in
> garbled output.
>
>>>
>>> In which case the driver needs to support the ->panic_draw_xy callback,
>>> or maybe it's possible to make a generic helper for tiled buffers.
>>>
> With a discrete GPU having a large amount of VRAM, the framebuffer may
> not be directly CPU accessible at all.
>
>>>
>>> I would have been nice to know how Windows works around this.
>>>
>
> There would need to be a mechanism for switching scanout to a linear,
> CPU accessible framebuffer.
I suppose panic_vmap() could just provide a linear temp buffer
to the panic handler, and panic_unmap() could copy the contents
over to the real fb.
That said, this approach of scribbling over the primary plane's
framebuffer has some clear limitations:
* something may overwrite the oops message before the user
can even read it
>>>
>>> When the dumper drm_panic_kmsg_dump() runs, the other CPU's should have
>>> been stopped. See panic().
>>
>> GPUs etc. may still be executing away.
>>
>
> Would it be safe to stop it in a panic situation? It would ofc be bad to
> crash the box even harder.
>
>>>
* there may be other planes obscuring part or all of the
primary plane
>>>
>>> Yeah, this is a problem, again I wonder how Windows deals with this.
>>
>> Probably just disables all other planes. Not that it uses planes
>> all that heavily.
>>
>>>
Also scribbling over the user's framebuffer seems rather rude
to me, so I'm thinking this approach should be limited to kernel
panics only.
>>>
>>> Yes this will only happen on kernel panics:
>>>
>>> panic() -> kmsg_dump() -> drm_panic_kmsg_dump()
>>>
>>> (Unless invoking through debugfs ofc)
>>
>> I thought you set the max_level or whatever to OOPS. Doesn't that mean
>> it gets involved for non-panics as well?
>>
>
> I do that in the debugfs code, but I can't remember why I lower level,
Now I remember, it is so I can catch the null pointer debugfs test, but
that's not necessary since this is designed for panics, so I should
remove that test.
Noralf.
> I
> think can just change the level when invoking the dumper:
> drm_panic_file_panic_write(...)
> - kmsg_dump(KMSG_DUMP_OOPS);
> + kmsg_dump(KMSG_DUMP_PANIC);
>
>
> This is the dumper config:
>
> static struct kmsg_dumper drm_panic_kmsg_dumper = {
> .dump = drm_panic_kmsg_dump,
> .max_reason = KMSG_DUMP_PANIC,
> };
>
> ___
> 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: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
Den 12.03.2019 18.25, skrev Ville Syrjälä:
> On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 12.03.2019 17.17, skrev Ville Syrjälä:
>>> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> This adds support for outputting kernel messages on panic().
> A kernel message dumper is used to dump the log. The dumper iterates
> over each DRM device and it's crtc's to find suitable framebuffers.
>
> All the other dumpers are run before this one except mtdoops.
> Only atomic drivers are supported.
>
> Signed-off-by: Noralf Trønnes
> ---
> [...]
>
> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
> index f0b34c977ec5..f3274798ecfe 100644
> --- a/include/drm/drm_framebuffer.h
> +++ b/include/drm/drm_framebuffer.h
> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
>struct drm_file *file_priv, unsigned flags,
>unsigned color, struct drm_clip_rect *clips,
>unsigned num_clips);
> +
> + /**
> + * @panic_vmap:
> + *
> + * Optional callback for panic handling.
> + *
> + * For vmapping the selected framebuffer in a panic context. Must
> + * be super careful about locking (only trylocking allowed).
> + *
> + * RETURNS:
> + *
> + * NULL if it didn't work out, otherwise an opaque cookie which is
> + * passed to @panic_draw_xy. It can be anything: vmap area, structure
> + * with more details, just a few flags, ...
> + */
> + void *(*panic_vmap)(struct drm_framebuffer *fb);
FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
drivers:
Framebuffers are normally tiled, writing to them with the CPU results in
garbled output.
>>
>> In which case the driver needs to support the ->panic_draw_xy callback,
>> or maybe it's possible to make a generic helper for tiled buffers.
>>
With a discrete GPU having a large amount of VRAM, the framebuffer may
not be directly CPU accessible at all.
>>
>> I would have been nice to know how Windows works around this.
>>
There would need to be a mechanism for switching scanout to a linear,
CPU accessible framebuffer.
>>>
>>> I suppose panic_vmap() could just provide a linear temp buffer
>>> to the panic handler, and panic_unmap() could copy the contents
>>> over to the real fb.
>>>
>>> That said, this approach of scribbling over the primary plane's
>>> framebuffer has some clear limitations:
>>> * something may overwrite the oops message before the user
>>> can even read it
>>
>> When the dumper drm_panic_kmsg_dump() runs, the other CPU's should have
>> been stopped. See panic().
>
> GPUs etc. may still be executing away.
>
Would it be safe to stop it in a panic situation? It would ofc be bad to
crash the box even harder.
>>
>>> * there may be other planes obscuring part or all of the
>>> primary plane
>>>
>>
>> Yeah, this is a problem, again I wonder how Windows deals with this.
>
> Probably just disables all other planes. Not that it uses planes
> all that heavily.
>
>>
>>> Also scribbling over the user's framebuffer seems rather rude
>>> to me, so I'm thinking this approach should be limited to kernel
>>> panics only.
>>>
>>
>> Yes this will only happen on kernel panics:
>>
>> panic() -> kmsg_dump() -> drm_panic_kmsg_dump()
>>
>> (Unless invoking through debugfs ofc)
>
> I thought you set the max_level or whatever to OOPS. Doesn't that mean
> it gets involved for non-panics as well?
>
I do that in the debugfs code, but I can't remember why I lower level, I
think can just change the level when invoking the dumper:
drm_panic_file_panic_write(...)
- kmsg_dump(KMSG_DUMP_OOPS);
+ kmsg_dump(KMSG_DUMP_PANIC);
This is the dumper config:
static struct kmsg_dumper drm_panic_kmsg_dumper = {
.dump = drm_panic_kmsg_dump,
.max_reason = KMSG_DUMP_PANIC,
};
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: Add helpers for locking an array of BO reservations.
Rob Herring writes: > On Fri, Mar 8, 2019 at 10:17 AM Eric Anholt wrote: >> >> Now that we have the reservation object in the GEM object, it's easy >> to provide a helper for this common case. Noticed while reviewing >> panfrost and lima drivers. This particular version came out of v3d, >> which in turn was a copy from vc4. >> >> Signed-off-by: Eric Anholt >> --- >> drivers/gpu/drm/drm_gem.c | 76 +++ >> include/drm/drm_gem.h | 4 +++ >> 2 files changed, 80 insertions(+) > > Sweet! I was about to go write this same patch. You are changing the > license from GPL to MIT copying the v3d version, but I guess you have > rights to do that. > > FWIW, > > Acked-by: Rob Herring Was this just for this one patch, or the series? I don't think I can merge without a consumer. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d: Fix calling drm_sched_resubmit_jobs for same sched.
Andrey Grodzovsky writes: > Also stop calling drm_sched_increase_karma multiple times. Each v3d->queue[q].sched was initialized with a separate drm_sched_init(). I wouldn't have thought they were all the "same sched". signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
On Tue, Mar 12, 2019 at 06:15:24PM +0100, Noralf Trønnes wrote:
>
>
> Den 12.03.2019 17.17, skrev Ville Syrjälä:
> > On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> >> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> >>> This adds support for outputting kernel messages on panic().
> >>> A kernel message dumper is used to dump the log. The dumper iterates
> >>> over each DRM device and it's crtc's to find suitable framebuffers.
> >>>
> >>> All the other dumpers are run before this one except mtdoops.
> >>> Only atomic drivers are supported.
> >>>
> >>> Signed-off-by: Noralf Trønnes
> >>> ---
> >>> [...]
> >>>
> >>> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
> >>> index f0b34c977ec5..f3274798ecfe 100644
> >>> --- a/include/drm/drm_framebuffer.h
> >>> +++ b/include/drm/drm_framebuffer.h
> >>> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
> >>>struct drm_file *file_priv, unsigned flags,
> >>>unsigned color, struct drm_clip_rect *clips,
> >>>unsigned num_clips);
> >>> +
> >>> + /**
> >>> + * @panic_vmap:
> >>> + *
> >>> + * Optional callback for panic handling.
> >>> + *
> >>> + * For vmapping the selected framebuffer in a panic context. Must
> >>> + * be super careful about locking (only trylocking allowed).
> >>> + *
> >>> + * RETURNS:
> >>> + *
> >>> + * NULL if it didn't work out, otherwise an opaque cookie which is
> >>> + * passed to @panic_draw_xy. It can be anything: vmap area, structure
> >>> + * with more details, just a few flags, ...
> >>> + */
> >>> + void *(*panic_vmap)(struct drm_framebuffer *fb);
> >>
> >> FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
> >> drivers:
> >>
> >> Framebuffers are normally tiled, writing to them with the CPU results in
> >> garbled output.
> >>
>
> In which case the driver needs to support the ->panic_draw_xy callback,
> or maybe it's possible to make a generic helper for tiled buffers.
>
> >> With a discrete GPU having a large amount of VRAM, the framebuffer may
> >> not be directly CPU accessible at all.
> >>
>
> I would have been nice to know how Windows works around this.
>
> >>
> >> There would need to be a mechanism for switching scanout to a linear,
> >> CPU accessible framebuffer.
> >
> > I suppose panic_vmap() could just provide a linear temp buffer
> > to the panic handler, and panic_unmap() could copy the contents
> > over to the real fb.
> >
> > That said, this approach of scribbling over the primary plane's
> > framebuffer has some clear limitations:
> > * something may overwrite the oops message before the user
> > can even read it
>
> When the dumper drm_panic_kmsg_dump() runs, the other CPU's should have
> been stopped. See panic().
GPUs etc. may still be executing away.
>
> > * there may be other planes obscuring part or all of the
> > primary plane
> >
>
> Yeah, this is a problem, again I wonder how Windows deals with this.
Probably just disables all other planes. Not that it uses planes
all that heavily.
>
> > Also scribbling over the user's framebuffer seems rather rude
> > to me, so I'm thinking this approach should be limited to kernel
> > panics only.
> >
>
> Yes this will only happen on kernel panics:
>
> panic() -> kmsg_dump() -> drm_panic_kmsg_dump()
>
> (Unless invoking through debugfs ofc)
I thought you set the max_level or whatever to OOPS. Doesn't that mean
it gets involved for non-panics as well?
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.9 91/96] drm: disable uncached DMA optimization for ARM and arm64
4.9-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ] The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel Reviewed-by: Christian König Reviewed-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- include/drm/drm_cache.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h index cebecff536a3..c5fb6f871930 100644 --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -41,6 +41,24 @@ static inline bool drm_arch_can_wc_memory(void) return false; #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3) return false; +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) + /* +* The DRM driver stack is designed to work with cache coherent devices +* only, but permits an optimization to be enabled in some cases, where +* for some buffers, both the CPU and the GPU use uncached mappings, +* removing the need for DMA snooping and allocation in the CPU caches. +* +* The use of uncached GPU mappings relies on the correct implementation +* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU +* will use cached mappings nonetheless. On x86 platforms, this does not +* seem to matter, as uncached CPU mappings will snoop the caches in any +* case. However, on ARM and arm64, enabling this optimization on a +* platform where NoSnoop is ignored results in loss of coherency, which +* breaks correct operation of the device. Since we have no way of +* detecting whether NoSnoop works or not, just disable this +* optimization entirely for ARM and arm64. +*/ + return false; #else return true; #endif -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.14 127/135] drm: disable uncached DMA optimization for ARM and arm64
4.14-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ] The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel Reviewed-by: Christian König Reviewed-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- include/drm/drm_cache.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h index beab0f0d0cfb..250e2d13c61b 100644 --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -45,6 +45,24 @@ static inline bool drm_arch_can_wc_memory(void) return false; #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3) return false; +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) + /* +* The DRM driver stack is designed to work with cache coherent devices +* only, but permits an optimization to be enabled in some cases, where +* for some buffers, both the CPU and the GPU use uncached mappings, +* removing the need for DMA snooping and allocation in the CPU caches. +* +* The use of uncached GPU mappings relies on the correct implementation +* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU +* will use cached mappings nonetheless. On x86 platforms, this does not +* seem to matter, as uncached CPU mappings will snoop the caches in any +* case. However, on ARM and arm64, enabling this optimization on a +* platform where NoSnoop is ignored results in loss of coherency, which +* breaks correct operation of the device. Since we have no way of +* detecting whether NoSnoop works or not, just disable this +* optimization entirely for ARM and arm64. +*/ + return false; #else return true; #endif -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.19 134/149] drm: disable uncached DMA optimization for ARM and arm64
4.19-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ] The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel Reviewed-by: Christian König Reviewed-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- include/drm/drm_cache.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h index bfe1639df02d..97fc498dc767 100644 --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -47,6 +47,24 @@ static inline bool drm_arch_can_wc_memory(void) return false; #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3) return false; +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) + /* +* The DRM driver stack is designed to work with cache coherent devices +* only, but permits an optimization to be enabled in some cases, where +* for some buffers, both the CPU and the GPU use uncached mappings, +* removing the need for DMA snooping and allocation in the CPU caches. +* +* The use of uncached GPU mappings relies on the correct implementation +* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU +* will use cached mappings nonetheless. On x86 platforms, this does not +* seem to matter, as uncached CPU mappings will snoop the caches in any +* case. However, on ARM and arm64, enabling this optimization on a +* platform where NoSnoop is ignored results in loss of coherency, which +* breaks correct operation of the device. Since we have no way of +* detecting whether NoSnoop works or not, just disable this +* optimization entirely for ARM and arm64. +*/ + return false; #else return true; #endif -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
Den 12.03.2019 17.17, skrev Ville Syrjälä:
> On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
>> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
>>> This adds support for outputting kernel messages on panic().
>>> A kernel message dumper is used to dump the log. The dumper iterates
>>> over each DRM device and it's crtc's to find suitable framebuffers.
>>>
>>> All the other dumpers are run before this one except mtdoops.
>>> Only atomic drivers are supported.
>>>
>>> Signed-off-by: Noralf Trønnes
>>> ---
>>> [...]
>>>
>>> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
>>> index f0b34c977ec5..f3274798ecfe 100644
>>> --- a/include/drm/drm_framebuffer.h
>>> +++ b/include/drm/drm_framebuffer.h
>>> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
>>> struct drm_file *file_priv, unsigned flags,
>>> unsigned color, struct drm_clip_rect *clips,
>>> unsigned num_clips);
>>> +
>>> + /**
>>> +* @panic_vmap:
>>> +*
>>> +* Optional callback for panic handling.
>>> +*
>>> +* For vmapping the selected framebuffer in a panic context. Must
>>> +* be super careful about locking (only trylocking allowed).
>>> +*
>>> +* RETURNS:
>>> +*
>>> +* NULL if it didn't work out, otherwise an opaque cookie which is
>>> +* passed to @panic_draw_xy. It can be anything: vmap area, structure
>>> +* with more details, just a few flags, ...
>>> +*/
>>> + void *(*panic_vmap)(struct drm_framebuffer *fb);
>>
>> FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
>> drivers:
>>
>> Framebuffers are normally tiled, writing to them with the CPU results in
>> garbled output.
>>
In which case the driver needs to support the ->panic_draw_xy callback,
or maybe it's possible to make a generic helper for tiled buffers.
>> With a discrete GPU having a large amount of VRAM, the framebuffer may
>> not be directly CPU accessible at all.
>>
I would have been nice to know how Windows works around this.
>>
>> There would need to be a mechanism for switching scanout to a linear,
>> CPU accessible framebuffer.
>
> I suppose panic_vmap() could just provide a linear temp buffer
> to the panic handler, and panic_unmap() could copy the contents
> over to the real fb.
>
> That said, this approach of scribbling over the primary plane's
> framebuffer has some clear limitations:
> * something may overwrite the oops message before the user
> can even read it
When the dumper drm_panic_kmsg_dump() runs, the other CPU's should have
been stopped. See panic().
> * there may be other planes obscuring part or all of the
> primary plane
>
Yeah, this is a problem, again I wonder how Windows deals with this.
> Also scribbling over the user's framebuffer seems rather rude
> to me, so I'm thinking this approach should be limited to kernel
> panics only.
>
Yes this will only happen on kernel panics:
panic() -> kmsg_dump() -> drm_panic_kmsg_dump()
(Unless invoking through debugfs ofc)
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4.20 160/171] drm: disable uncached DMA optimization for ARM and arm64
4.20-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ] The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel Reviewed-by: Christian König Reviewed-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- include/drm/drm_cache.h | 18 ++ 1 file changed, 18 insertions(+) diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h index bfe1639df02d..97fc498dc767 100644 --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -47,6 +47,24 @@ static inline bool drm_arch_can_wc_memory(void) return false; #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3) return false; +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) + /* +* The DRM driver stack is designed to work with cache coherent devices +* only, but permits an optimization to be enabled in some cases, where +* for some buffers, both the CPU and the GPU use uncached mappings, +* removing the need for DMA snooping and allocation in the CPU caches. +* +* The use of uncached GPU mappings relies on the correct implementation +* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU +* will use cached mappings nonetheless. On x86 platforms, this does not +* seem to matter, as uncached CPU mappings will snoop the caches in any +* case. However, on ARM and arm64, enabling this optimization on a +* platform where NoSnoop is ignored results in loss of coherency, which +* breaks correct operation of the device. Since we have no way of +* detecting whether NoSnoop works or not, just disable this +* optimization entirely for ARM and arm64. +*/ + return false; #else return true; #endif -- 2.19.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5.0 13/25] drm: disable uncached DMA optimization for ARM and arm64
5.0-stable review patch. If anyone has any objections, please let me know. -- [ Upstream commit e02f5c1bb2283cfcee68f2f0feddcc06150f13aa ] The DRM driver stack is designed to work with cache coherent devices only, but permits an optimization to be enabled in some cases, where for some buffers, both the CPU and the GPU use uncached mappings, removing the need for DMA snooping and allocation in the CPU caches. The use of uncached GPU mappings relies on the correct implementation of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU will use cached mappings nonetheless. On x86 platforms, this does not seem to matter, as uncached CPU mappings will snoop the caches in any case. However, on ARM and arm64, enabling this optimization on a platform where NoSnoop is ignored results in loss of coherency, which breaks correct operation of the device. Since we have no way of detecting whether NoSnoop works or not, just disable this optimization entirely for ARM and arm64. Cc: Christian Koenig Cc: Alex Deucher Cc: David Zhou Cc: Huang Rui Cc: Junwei Zhang Cc: Michel Daenzer Cc: David Airlie Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Sean Paul Cc: Michael Ellerman Cc: Benjamin Herrenschmidt Cc: Will Deacon Cc: Christoph Hellwig Cc: Robin Murphy Cc: amd-gfx list Cc: dri-devel Reported-by: Carsten Haitzler Signed-off-by: Ard Biesheuvel Reviewed-by: Christian König Reviewed-by: Alex Deucher Link: https://patchwork.kernel.org/patch/10778815/ Signed-off-by: Christian König Signed-off-by: Sasha Levin --- include/drm/drm_cache.h | 18 ++ 1 file changed, 18 insertions(+) --- a/include/drm/drm_cache.h +++ b/include/drm/drm_cache.h @@ -47,6 +47,24 @@ static inline bool drm_arch_can_wc_memor return false; #elif defined(CONFIG_MIPS) && defined(CONFIG_CPU_LOONGSON3) return false; +#elif defined(CONFIG_ARM) || defined(CONFIG_ARM64) + /* +* The DRM driver stack is designed to work with cache coherent devices +* only, but permits an optimization to be enabled in some cases, where +* for some buffers, both the CPU and the GPU use uncached mappings, +* removing the need for DMA snooping and allocation in the CPU caches. +* +* The use of uncached GPU mappings relies on the correct implementation +* of the PCIe NoSnoop TLP attribute by the platform, otherwise the GPU +* will use cached mappings nonetheless. On x86 platforms, this does not +* seem to matter, as uncached CPU mappings will snoop the caches in any +* case. However, on ARM and arm64, enabling this optimization on a +* platform where NoSnoop is ignored results in loss of coherency, which +* breaks correct operation of the device. Since we have no way of +* detecting whether NoSnoop works or not, just disable this +* optimization entirely for ARM and arm64. +*/ + return false; #else return true; #endif ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/v3d: Fix calling drm_sched_resubmit_jobs for same sched.
Also stop calling drm_sched_increase_karma multiple times.
Signed-off-by: Andrey Grodzovsky
---
drivers/gpu/drm/v3d/v3d_sched.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_sched.c b/drivers/gpu/drm/v3d/v3d_sched.c
index 4704b2d..ce7c737b 100644
--- a/drivers/gpu/drm/v3d/v3d_sched.c
+++ b/drivers/gpu/drm/v3d/v3d_sched.c
@@ -231,20 +231,17 @@ v3d_gpu_reset_for_timeout(struct v3d_dev *v3d, struct
drm_sched_job *sched_job)
mutex_lock(>reset_lock);
/* block scheduler */
- for (q = 0; q < V3D_MAX_QUEUES; q++) {
- struct drm_gpu_scheduler *sched = >queue[q].sched;
-
- drm_sched_stop(sched);
+ for (q = 0; q < V3D_MAX_QUEUES; q++)
+ drm_sched_stop(>queue[q].sched);
- if(sched_job)
- drm_sched_increase_karma(sched_job);
- }
+ if(sched_job)
+ drm_sched_increase_karma(sched_job);
/* get the GPU back into the init state */
v3d_reset(v3d);
for (q = 0; q < V3D_MAX_QUEUES; q++)
- drm_sched_resubmit_jobs(sched_job->sched);
+ drm_sched_resubmit_jobs(>queue[q].sched);
/* Unblock schedulers and restart their jobs. */
for (q = 0; q < V3D_MAX_QUEUES; q++) {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v2 1/3] drm: Add support for panic message output
On Tue, Mar 12, 2019 at 11:47:04AM +0100, Michel Dänzer wrote:
> On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> > This adds support for outputting kernel messages on panic().
> > A kernel message dumper is used to dump the log. The dumper iterates
> > over each DRM device and it's crtc's to find suitable framebuffers.
> >
> > All the other dumpers are run before this one except mtdoops.
> > Only atomic drivers are supported.
> >
> > Signed-off-by: Noralf Trønnes
> > ---
> > [...]
> >
> > diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
> > index f0b34c977ec5..f3274798ecfe 100644
> > --- a/include/drm/drm_framebuffer.h
> > +++ b/include/drm/drm_framebuffer.h
> > @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
> > struct drm_file *file_priv, unsigned flags,
> > unsigned color, struct drm_clip_rect *clips,
> > unsigned num_clips);
> > +
> > + /**
> > +* @panic_vmap:
> > +*
> > +* Optional callback for panic handling.
> > +*
> > +* For vmapping the selected framebuffer in a panic context. Must
> > +* be super careful about locking (only trylocking allowed).
> > +*
> > +* RETURNS:
> > +*
> > +* NULL if it didn't work out, otherwise an opaque cookie which is
> > +* passed to @panic_draw_xy. It can be anything: vmap area, structure
> > +* with more details, just a few flags, ...
> > +*/
> > + void *(*panic_vmap)(struct drm_framebuffer *fb);
>
> FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
> drivers:
>
> Framebuffers are normally tiled, writing to them with the CPU results in
> garbled output.
>
> With a discrete GPU having a large amount of VRAM, the framebuffer may
> not be directly CPU accessible at all.
>
>
> There would need to be a mechanism for switching scanout to a linear,
> CPU accessible framebuffer.
I suppose panic_vmap() could just provide a linear temp buffer
to the panic handler, and panic_unmap() could copy the contents
over to the real fb.
That said, this approach of scribbling over the primary plane's
framebuffer has some clear limitations:
* something may overwrite the oops message before the user
can even read it
* there may be other planes obscuring part or all of the
primary plane
Also scribbling over the user's framebuffer seems rather rude
to me, so I'm thinking this approach should be limited to kernel
panics only.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 5/5] drm/bridge: sii902x: Implement HDMI audio support
On Wed, Feb 27, 2019 at 11:54:23PM +0200, Jyri Sarha wrote:
> Implement HDMI audio support by using ASoC HDMI codec. The commit
> implements the necessary callbacks and configuration for the HDMI
> codec and registers a virtual platform device for the codec to attach.
>
> Signed-off-by: Jyri Sarha
> ---
> .../bindings/display/bridge/sii902x.txt | 36 +-
> drivers/gpu/drm/bridge/sii902x.c | 453 +-
> include/dt-bindings/sound/sii902x-audio.h | 11 +
Please split bindings (doc and header) to a separate patch.
> 3 files changed, 493 insertions(+), 7 deletions(-)
> create mode 100644 include/dt-bindings/sound/sii902x-audio.h
>
> diff --git a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> index 72d2dc6c3e6b..647b2fd84db9 100644
> --- a/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> +++ b/Documentation/devicetree/bindings/display/bridge/sii902x.txt
> @@ -5,9 +5,32 @@ Required properties:
> - reg: i2c address of the bridge
>
> Optional properties:
> - - interrupts: describe the interrupt line used to inform the host
> + - interrupts: describe the interrupt line used to inform the host
Unrelated change.
> about hotplug events.
> - reset-gpios: OF device-tree gpio specification for RST_N pin.
> + - i2s-fifo-routing: Array of exactly 4 integers indicating i2s
Needs a vendor prefix.
> + pins for audio fifo routing. First integer defines routing to
> + fifo 0 and second to fifo 1, etc. Integers can be filled with
> + definitions from: include/dt-bindings/sound/sii902x-audio.h
> + The available definitions are:
> + - ENABLE_BIT: enable this audio fifo
> + - CONNECT_SD#: route audio input from SD0, SD1, SD2, or SD3 i2s
> + data input pin
> + - LEFT_RIGHT_SWAP_BIT: swap i2s input channels for this fifo
> + I2S HDMI audio is configured only if this property is found.
> + - clocks: phandle mclk
> + - clock-names: "mclk"
> + Describes SII902x MCLK input. MCLK is used to produce
> + HDMI audio CTS values. This property is required if
> + "i2s-fifo-routing"-property is present. This property follows
> + Documentation/devicetree/bindings/clock/clock-bindings.txt
> + consumer binding.
> + - #sound-dai-cells = <0>: ASoC codec dai available for simple-card
> + If audio properties are present sii902x provides an ASoC
> + codec component driver that can be used by other ASoC
> + components like simple-card. See binding document fo> +
> details:
> + Documentation/devicetree/bindings/sound/simple-card.txt
>
> Optional subnodes:
> - video input: this subnode can contain a video input port node
> @@ -21,6 +44,17 @@ Example:
> compatible = "sil,sii9022";
> reg = <0x39>;
> reset-gpios = < 1 0>;
> +
> + #sound-dai-cells = <0>;
> + i2s-fifo-routing = <
> + (ENABLE_BIT|CONNECT_SD0)
> + 0
> + 0
> + 0
> + >;
> + clocks = <>;
> + clock-names = "mclk";
> +
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
[...]
> diff --git a/include/dt-bindings/sound/sii902x-audio.h
> b/include/dt-bindings/sound/sii902x-audio.h
> new file mode 100644
> index ..32e50a926b6f
> --- /dev/null
> +++ b/include/dt-bindings/sound/sii902x-audio.h
> @@ -0,0 +1,11 @@
License?
> +#ifndef __DT_SII9022_AUDIO_H
> +#define __DT_SII9022_AUDIO_H
> +
> +#define ENABLE_BIT 0x80
> +#define CONNECT_SD0 0x00
> +#define CONNECT_SD1 0x10
> +#define CONNECT_SD2 0x20
> +#define CONNECT_SD3 0x30
> +#define LEFT_RIGHT_SWAP_BIT 0x04
> +
> +#endif /* __DT_SII9022_AUDIO_H */
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu: drm: atomic_helper: Fix spelling errors
Hi Ville, On 12/03/2019 15:14, Ville Syrjälä wrote: > On Tue, Mar 12, 2019 at 12:33:07AM +, Kieran Bingham wrote: >> Trivial fixes identified while working on the DRM code. >> >> s/artifically/artificially/ >> s/achive/achieve/ >> >> Signed-off-by: Kieran Bingham >> --- >> >> v2: - Actually spell achieve correctly! > > drm convention is to put this above the --- so that it gets included in > the commit msg. Oh - in linux-media these are just dropped. I'll try to remember this for my future work in DRM. I don't have commit access anyway, so can I presume whomever will pick this up will adjust if necessary? Or should I repost? (which might be a bit redundant just to move a patch version comment which would then increase again :D ) > With that > Reviewed-by: Ville Syrjälä Thanks, -- Regards Kieran > >> >> drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_atomic_helper.c >> b/drivers/gpu/drm/drm_atomic_helper.c >> index 540a77a2ade9..2453678d1186 100644 >> --- a/drivers/gpu/drm/drm_atomic_helper.c >> +++ b/drivers/gpu/drm/drm_atomic_helper.c >> @@ -1752,7 +1752,7 @@ int drm_atomic_helper_commit(struct drm_device *dev, >> * >> * NOTE: Commit work has multiple phases, first hardware commit, then >> * cleanup. We want them to overlap, hence need system_unbound_wq to >> - * make sure work items don't artifically stall on each another. >> + * make sure work items don't artificially stall on each another. >> */ >> >> drm_atomic_state_get(state); >> @@ -1786,7 +1786,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit); >> * >> * Asynchronous workers need to have sufficient parallelism to be able to >> run >> * different atomic commits on different CRTCs in parallel. The simplest >> way to >> - * achive this is by running them on the _unbound_wq work queue. Note >> + * achieve this is by running them on the _unbound_wq work queue. >> Note >> * that drivers are not required to split up atomic commits and run an >> * individual commit in parallel - userspace is supposed to do that if it >> cares. >> * But it might be beneficial to do that for modesets, since those >> necessarily >> -- >> 2.19.1 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/5] drm/rockchip: fix fb references in async update
On Tue, 12 Mar 2019 12:34:45 -0300
Helen Koike wrote:
> On 3/12/19 3:34 AM, Boris Brezillon wrote:
> > On Mon, 11 Mar 2019 23:21:59 -0300
> > Helen Koike wrote:
> >
> >> In the case of async update, modifications are done in place, i.e. in the
> >> current plane state, so the new_state is prepared and the new_state is
> >> cleanup up (instead of the old_state, diferrently on what happen in a
> >
> > ^ cleaned up ^ differently (but maybe
> > "unlike what happens" is more appropriate here).
> >
> >> normal sync update).
> >> To cleanup the old_fb properly, it needs to be placed in the new_state
> >> in the end of async_update, so cleanup call will unreference the old_fb
> >> correctly.
> >>
> >> Also, the previous code had a:
> >>
> >>plane_state = plane->funcs->atomic_duplicate_state(plane);
> >>...
> >>swap(plane_state, plane->state);
> >>
> >>if (plane->state->fb && plane->state->fb != new_state->fb) {
> >>...
> >>}
> >>
> >> Which was wrong, as the fb were just assigned to be equal, so this if
> >> statement nevers evaluates to true.
> >>
> >> Another details is that the function drm_crtc_vblank_get() can only be
> >> called when vop->is_enabled is true, otherwise it has no effect and
> >> trows a WARN_ON().
> >>
> >> Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
> >> fb and pus the old fb) is not required, as it is taken care by
> >> drm_mode_cursor_universal() when calling
> >> drm_atomic_helper_update_plane().
> >>
> >> Signed-off-by: Helen Koike
> >>
> >> ---
> >> Hello,
> >>
> >> I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
> >> kms_cursor_legacy and I didn't see any regressions.
> >>
> >> Changes in v2: None
> >>
> >> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 -
> >> 1 file changed, 24 insertions(+), 18 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >> index c7d4c6073ea5..a1ee8c156a7b 100644
> >> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> >> @@ -912,30 +912,31 @@ static void vop_plane_atomic_async_update(struct
> >> drm_plane *plane,
> >> struct drm_plane_state *new_state)
> >> {
> >>struct vop *vop = to_vop(plane->state->crtc);
> >> - struct drm_plane_state *plane_state;
> >> + struct drm_framebuffer *old_fb = plane->state->fb;
> >>
> >> - plane_state = plane->funcs->atomic_duplicate_state(plane);
> >> - plane_state->crtc_x = new_state->crtc_x;
> >> - plane_state->crtc_y = new_state->crtc_y;
> >> - plane_state->crtc_h = new_state->crtc_h;
> >> - plane_state->crtc_w = new_state->crtc_w;
> >> - plane_state->src_x = new_state->src_x;
> >> - plane_state->src_y = new_state->src_y;
> >> - plane_state->src_h = new_state->src_h;
> >> - plane_state->src_w = new_state->src_w;
> >> -
> >> - if (plane_state->fb != new_state->fb)
> >> - drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
> >> -
> >> - swap(plane_state, plane->state);
> >> -
> >> - if (plane->state->fb && plane->state->fb != new_state->fb) {
> >> + /*
> >> + * A scanout can still be occurring, so we can't drop the reference to
> >> + * the old framebuffer. To solve this we get a reference to old_fb and
> >> + * set a worker to release it later.
> >
> > Hm, doesn't look like an async update to me if we have to wait for the
> > next VBLANK to happen to get the new content on the screen. Maybe we
> > should reject async updates when old_fb != new_fb in the rk
> > ->async_check() hook.
>
> Unless I am misunderstanding this, we don't wait here, we just grab a
> reference to the fb in case it is being still used by the hw, so it
> doesn't get released prematurely.
I was just reacting to the comment that says the new FB should stay
around until the next VBLANK event happens. If the FB must stay around
that probably means the HW is still using, which made me wonder if this
HW actually supports async update (where async means "update now and
don't care about about tearing"). Or maybe it takes some time to switch
to the new FB and waiting for the next VBLANK to release the old FB was
an easy solution to not wait for the flip to actually happen in
->async_update() (which is kind of a combination of async+non-blocking).
Anyway, let's keep it like that.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/fourcc: add ARM GPU tile format
On Mon, Mar 11, 2019 at 09:39:28AM -0700, Alyssa Rosenzweig wrote: > > You might want to re-use the exisiting modifier > > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16. > > > > I would suggest you to have a look at the exisiting AFBC modifiers > > (denoted by AFBC_FORMAT_MOD_XXX ) and let us know if there is > > something you cannot reuse. > > So, the "tiled" format in question (that Qiang needs to import/export > BOs in) is *uncompressed* but tiled with an Arm-internal format (for the > GPUs). Here's a software implementation for encoding this format: > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/panfrost/pan_swizzle.c > ok I understood now. In this case, please ignore my suggestion. > For Midgard/Bifrost, we use this tiling internally for uploading bitmap > textures, but we only render to AFBC (or linear). So for Panfrost, we'll > always be importing/exporting AFBC buffers, never uncompressed tiled. I am not a gpu guy so can't comment at the moment. > But Utgard does not seem to support AFBC (?), so Qiang needs the > uncompressed tiled for the same purpose Panfrost uses AFBC. > > Is it possible that this is the same tiling used internally by > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16, only without any compression? AFBC is > blackbox for us, so this isn't something we can figure out ourselves, > but that influences whether it's appropriate to reuse the modifier. If > this is the same tiling scheme, perhaps that's the answer. If it's not > (I don't know how AFBC tiling works), we probably do need a separate > modifier to avoid confusion. > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 denotes the superblock size to be used only in case of AFBC buffers. For non compressed tiled format, none of the AFBC_FORMAT_MOD_XXX should be used. However, I would like you to review my patch series (https://patchwork.freedesktop.org/series/53395/) to see if we have the same understanding. > Thanks, > > Alyssa > ___ > 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 v2 1/5] drm/rockchip: fix fb references in async update
On 3/12/19 3:34 AM, Boris Brezillon wrote:
> On Mon, 11 Mar 2019 23:21:59 -0300
> Helen Koike wrote:
>
>> In the case of async update, modifications are done in place, i.e. in the
>> current plane state, so the new_state is prepared and the new_state is
>> cleanup up (instead of the old_state, diferrently on what happen in a
>
> ^ cleaned up^ differently (but maybe
> "unlike what happens" is more appropriate here).
>
>> normal sync update).
>> To cleanup the old_fb properly, it needs to be placed in the new_state
>> in the end of async_update, so cleanup call will unreference the old_fb
>> correctly.
>>
>> Also, the previous code had a:
>>
>> plane_state = plane->funcs->atomic_duplicate_state(plane);
>> ...
>> swap(plane_state, plane->state);
>>
>> if (plane->state->fb && plane->state->fb != new_state->fb) {
>> ...
>> }
>>
>> Which was wrong, as the fb were just assigned to be equal, so this if
>> statement nevers evaluates to true.
>>
>> Another details is that the function drm_crtc_vblank_get() can only be
>> called when vop->is_enabled is true, otherwise it has no effect and
>> trows a WARN_ON().
>>
>> Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
>> fb and pus the old fb) is not required, as it is taken care by
>> drm_mode_cursor_universal() when calling
>> drm_atomic_helper_update_plane().
>>
>> Signed-off-by: Helen Koike
>>
>> ---
>> Hello,
>>
>> I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
>> kms_cursor_legacy and I didn't see any regressions.
>>
>> Changes in v2: None
>>
>> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 -
>> 1 file changed, 24 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> index c7d4c6073ea5..a1ee8c156a7b 100644
>> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
>> @@ -912,30 +912,31 @@ static void vop_plane_atomic_async_update(struct
>> drm_plane *plane,
>>struct drm_plane_state *new_state)
>> {
>> struct vop *vop = to_vop(plane->state->crtc);
>> -struct drm_plane_state *plane_state;
>> +struct drm_framebuffer *old_fb = plane->state->fb;
>>
>> -plane_state = plane->funcs->atomic_duplicate_state(plane);
>> -plane_state->crtc_x = new_state->crtc_x;
>> -plane_state->crtc_y = new_state->crtc_y;
>> -plane_state->crtc_h = new_state->crtc_h;
>> -plane_state->crtc_w = new_state->crtc_w;
>> -plane_state->src_x = new_state->src_x;
>> -plane_state->src_y = new_state->src_y;
>> -plane_state->src_h = new_state->src_h;
>> -plane_state->src_w = new_state->src_w;
>> -
>> -if (plane_state->fb != new_state->fb)
>> -drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
>> -
>> -swap(plane_state, plane->state);
>> -
>> -if (plane->state->fb && plane->state->fb != new_state->fb) {
>> +/*
>> + * A scanout can still be occurring, so we can't drop the reference to
>> + * the old framebuffer. To solve this we get a reference to old_fb and
>> + * set a worker to release it later.
>
> Hm, doesn't look like an async update to me if we have to wait for the
> next VBLANK to happen to get the new content on the screen. Maybe we
> should reject async updates when old_fb != new_fb in the rk
> ->async_check() hook.
Unless I am misunderstanding this, we don't wait here, we just grab a
reference to the fb in case it is being still used by the hw, so it
doesn't get released prematurely.
>
>> + */
>> +if (vop->is_enabled &&
>> +plane->state->fb && plane->state->fb != new_state->fb) {
>> drm_framebuffer_get(plane->state->fb);
>> WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
>> drm_flip_work_queue(>fb_unref_work, plane->state->fb);
>> set_bit(VOP_PENDING_FB_UNREF, >pending);
>> }
>
> In any case, I think this should be called after
> vop_plane_atomic_update() to prevent the situation where the VBLANK
> event happens between this point and the following
> vop_plane_atomic_update() call.
ack, I'll update it in the next version.
>
>>
>> +plane->state->crtc_x = new_state->crtc_x;
>> +plane->state->crtc_y = new_state->crtc_y;
>> +plane->state->crtc_h = new_state->crtc_h;
>> +plane->state->crtc_w = new_state->crtc_w;
>> +plane->state->src_x = new_state->src_x;
>> +plane->state->src_y = new_state->src_y;
>> +plane->state->src_h = new_state->src_h;
>> +plane->state->src_w = new_state->src_w;
>> +plane->state->fb = new_state->fb;
>
> Any reason not to use swap() here and reference plane->state->fb
> instead of new_state->fb after this point?
I had the impression I had to do this in one of my tests, but re-testing
now and re-looking at the code this doesn't seem to be
Re: [PATCH v5 16/19] drm: rcar-du: Fix rcar_du_crtc structure documentation
Hi Kieran,
On Mon, Mar 11, 2019 at 10:57:15PM +, Kieran Bingham wrote:
> On 21/02/2019 10:32, Laurent Pinchart wrote:
> > The rcar_du_crtc structure index field contains the CRTC hardware index,
> > not the hardware and software index. Update the documentation
> > accordingly.
>
> Should this have a fixes tag? It's only trivial - but if so:
>
> Fixes: 5361cc7f8e91 ("drm: rcar-du: Split CRTC handling to support
> hardware indexing")
I'll add it for correctness, I just hope it won't be automatically
backported to stable.
> Either way,
>
> Reviewed-by: Kieran Bingham
>
> > Signed-off-by: Laurent Pinchart
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > index bcb35b0b7612..c478953be092 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.h
> > @@ -27,7 +27,7 @@ struct rcar_du_vsp;
> > * @clock: the CRTC functional clock
> > * @extclock: external pixel dot clock (optional)
> > * @mmio_offset: offset of the CRTC registers in the DU MMIO block
> > - * @index: CRTC software and hardware index
> > + * @index: CRTC hardware index
> > * @initialized: whether the CRTC has been initialized and clocks enabled
> > * @dsysr: cached value of the DSYSR register
> > * @vblank_enable: whether vblank events are enabled on this CRTC
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 --- Comment #27 from JerryD --- I am following 7 serious bug reports on kernel, redhat, freedesktop bugzillas. This one is by far the most critical when one can not boot the machine. I am happy to try to test things. I am not set up to compile a kernel, but I can try release candidates. If anyone sees something that might work, please let me know. model name : AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx Command line: BOOT_IMAGE=/vmlinuz-4.19.15-300.fc29.x86_64 root=/dev/mapper/fedora-root ro resume=/dev/mapper/fedora-swap rd.lvm.lv=fedora/root rd.lvm.lv=fedora/swap rhgb quiet LANG=en_US.UTF-8 idle=nomwait iommu=pt processor.max_cstate=1 DMI: HP HP ENVY x360 Convertible 15-bq1xx/83C6, BIOS F.20 12/25/2018 -- 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 5/9] drm/bridge: tc358767: Simplify polling in tc_link_training()
Hi Andrey,
On Mon, Mar 11, 2019 at 11:26:20AM -0700, Andrey Smirnov wrote:
> On Mon, Mar 4, 2019 at 4:30 AM Laurent Pinchart wrote:
> > On Tue, Feb 26, 2019 at 11:36:05AM -0800, Andrey Smirnov wrote:
> >> Replace explicit polling in tc_link_training() with equivalent call to
> >> regmap_read_poll_timeout() for simplicity. No functional change
> >> intended (not including slightly altered debug output).
> >>
> >> Signed-off-by: Andrey Smirnov
> >> Cc: Archit Taneja
> >> Cc: Andrzej Hajda
> >> Cc: Laurent Pinchart
> >> Cc: Chris Healy
> >> Cc: Lucas Stach
> >> Cc: dri-devel@lists.freedesktop.org
> >> Cc: linux-ker...@vger.kernel.org
> >> ---
> >> drivers/gpu/drm/bridge/tc358767.c | 14 +-
> >> 1 file changed, 5 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> >> b/drivers/gpu/drm/bridge/tc358767.c
> >> index 6455e6484722..ea30cec4a0c3 100644
> >> --- a/drivers/gpu/drm/bridge/tc358767.c
> >> +++ b/drivers/gpu/drm/bridge/tc358767.c
> >> @@ -735,7 +735,6 @@ static int tc_link_training(struct tc_data *tc, int
> >> pattern)
> >> const char * const *errors;
> >> u32 srcctrl = tc_srcctrl(tc) | DP0_SRCCTRL_SCRMBLDIS |
> >> DP0_SRCCTRL_AUTOCORRECT;
> >> - int timeout;
> >> int retry;
> >> u32 value;
> >> int ret;
> >> @@ -765,20 +764,17 @@ static int tc_link_training(struct tc_data *tc, int
> >> pattern)
> >> tc_write(DP0CTL, DP_EN);
> >>
> >> /* wait */
> >> - timeout = 1000;
> >> - do {
> >> - tc_read(DP0_LTSTAT, );
> >> - udelay(1);
> >> - } while ((!(value & LT_LOOPDONE)) && (--timeout));
> >> - if (timeout == 0) {
> >> + ret = regmap_read_poll_timeout(tc->regmap, DP0_LTSTAT, value,
> >> +value & LT_LOOPDONE, 1, 1000);
> >> + if (ret) {
> >> dev_err(tc->dev, "Link training timeout!\n");
> >> } else {
> >> int pattern = (value >> 11) & 0x3;
> >> int error = (value >> 8) & 0x7;
> >>
> >> dev_dbg(tc->dev,
> >> - "Link training phase %d done after %d uS:
> >> %s\n",
> >> - pattern, 1000 - timeout, errors[error]);
> >> + "Link training phase %d done: %s\n",
> >> + pattern, errors[error]);
> >
> > It's probably not a big deal in this specific case, but in general it
> > can be useful to know how long the poll took.
>
> I don't disagree, but bear in mind that the way time is measured in
> original loop assumes that tc_read, an I2C transaction over 100KHz
> bus, takes insignificant amount of time compared to 1 uS delay. I
> think original debug statement does a bit of a false advertising when
> it presents a number of polling loop iterations as if it is time it
> took to establish a link in microseconds.
>
> > Any hope to enhance regmap_read_poll_timeout() to return either the elapsed
> > time or the
> > remaining timeout instead of 0 on success ?
>
> I'd rather not go there. That'll take convincing Mark Brown to accept
> that semantics change, then fixing all of the callers across the tree
> via a separate patch series.
>
> What if instead we just add an extra debug statement before link
> training starts, so that duration of the process can be discerned from
> logging timestamps? This does require user doing a bit of math by
> hand, but it's actually more accurate timing info compared to original
> and it doesn't require any API modification.
That works for me.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] gpu: drm: atomic_helper: Fix spelling errors
On Tue, Mar 12, 2019 at 12:33:07AM +, Kieran Bingham wrote: > Trivial fixes identified while working on the DRM code. > > s/artifically/artificially/ > s/achive/achieve/ > > Signed-off-by: Kieran Bingham > --- > > v2: - Actually spell achieve correctly! drm convention is to put this above the --- so that it gets included in the commit msg. With that Reviewed-by: Ville Syrjälä > > drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 540a77a2ade9..2453678d1186 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -1752,7 +1752,7 @@ int drm_atomic_helper_commit(struct drm_device *dev, >* >* NOTE: Commit work has multiple phases, first hardware commit, then >* cleanup. We want them to overlap, hence need system_unbound_wq to > - * make sure work items don't artifically stall on each another. > + * make sure work items don't artificially stall on each another. >*/ > > drm_atomic_state_get(state); > @@ -1786,7 +1786,7 @@ EXPORT_SYMBOL(drm_atomic_helper_commit); > * > * Asynchronous workers need to have sufficient parallelism to be able to run > * different atomic commits on different CRTCs in parallel. The simplest way > to > - * achive this is by running them on the _unbound_wq work queue. Note > + * achieve this is by running them on the _unbound_wq work queue. Note > * that drivers are not required to split up atomic commits and run an > * individual commit in parallel - userspace is supposed to do that if it > cares. > * But it might be beneficial to do that for modesets, since those > necessarily > -- > 2.19.1 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v6 1/2] drm/sched: Refactor ring mirror list handling.
On 3/12/19 3:43 AM, Tomeu Vizoso wrote:
> On Thu, 27 Dec 2018 at 20:28, Andrey Grodzovsky
> wrote:
>> Decauple sched threads stop and start and ring mirror
>> list handling from the policy of what to do about the
>> guilty jobs.
>> When stoppping the sched thread and detaching sched fences
>> from non signaled HW fenes wait for all signaled HW fences
>> to complete before rerunning the jobs.
>>
>> v2: Fix resubmission of guilty job into HW after refactoring.
>>
>> v4:
>> Full restart for all the jobs, not only from guilty ring.
>> Extract karma increase into standalone function.
>>
>> v5:
>> Rework waiting for signaled jobs without relying on the job
>> struct itself as those might already be freed for non 'guilty'
>> job's schedulers.
>> Expose karma increase to drivers.
>>
>> v6:
>> Use list_for_each_entry_safe_continue and drm_sched_process_job
>> in case fence already signaled.
>> Call drm_sched_increase_karma only once for amdgpu and add documentation.
>>
>> Suggested-by: Christian Koenig
>> Signed-off-by: Andrey Grodzovsky
>> ---
>> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 20 ++-
>> drivers/gpu/drm/etnaviv/etnaviv_sched.c| 11 +-
>> drivers/gpu/drm/scheduler/sched_main.c | 195
>> +++--
>> drivers/gpu/drm/v3d/v3d_sched.c| 12 +-
>> include/drm/gpu_scheduler.h| 8 +-
>> 5 files changed, 157 insertions(+), 89 deletions(-)
>>
> [snip]
>> diff --git a/drivers/gpu/drm/v3d/v3d_sched.c
>> b/drivers/gpu/drm/v3d/v3d_sched.c
>> index 445b2ef..f76d9ed 100644
>> --- a/drivers/gpu/drm/v3d/v3d_sched.c
>> +++ b/drivers/gpu/drm/v3d/v3d_sched.c
>> @@ -178,18 +178,22 @@ v3d_job_timedout(struct drm_sched_job *sched_job)
>> for (q = 0; q < V3D_MAX_QUEUES; q++) {
>> struct drm_gpu_scheduler *sched = >queue[q].sched;
>>
>> - kthread_park(sched->thread);
>> - drm_sched_hw_job_reset(sched, (sched_job->sched == sched ?
>> + drm_sched_stop(sched, (sched_job->sched == sched ?
>> sched_job : NULL));
>> +
>> + if(sched_job)
>> + drm_sched_increase_karma(sched_job);
>> }
>>
>> /* get the GPU back into the init state */
>> v3d_reset(v3d);
>>
>> + for (q = 0; q < V3D_MAX_QUEUES; q++)
>> + drm_sched_resubmit_jobs(sched_job->sched);
> Hi Andrey,
>
> I'm not sure of what was the original intent, but I guess it wasn't to
> repeatedly call resubmit_jobs on that specific job's queue?
>
> Regards,
>
> Tomeu
My bad, there is also another mistake here with increasing karma for
the guilty job's entity multiple times. I will fix that. Thanks for
pointing out.
Andrey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109978] Unprivileged user mode program can cause GPU reset
https://bugs.freedesktop.org/show_bug.cgi?id=109978
Bug ID: 109978
Summary: Unprivileged user mode program can cause GPU reset
Product: DRI
Version: XOrg git
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: major
Priority: medium
Component: DRM/amdkfd
Assignee: dri-devel@lists.freedesktop.org
Reporter: sudols...@gmail.com
https://github.com/RadeonOpenCompute/ROCK-Kernel-Driver/issues/72
Sample program which causes this (needs ROCm):
> #include
> int main()
> {
> parallel_for_each(hc::extent<1>(1), [=]() [[hc]]
> {
> asm("s_trap 2");
> });
> return 0;
> }
> hcc -hc main.cpp
> ./a.out
Process never ends and CTRL-C causes GPU reset which breaks all other processes
actually using rocm on that GPU. Seems trap handler expects queue handle in
s[0:1] which is set when using __builtin_trap() so without it trap handler
causes another exceptions.
System logs:
[ 247.428727] qcm fence wait loop timeout expired
[ 247.428730] The cp might be in an unrecoverable state due to an unsuccessful
queues preemption
[ 247.428736] amdgpu :0b:00.0: GPU reset begin!
[ 247.619440] amdgpu :0b:00.0: GPU reset
[ 248.152762] [drm] psp mode1 reset succeed
[ 248.279461] amdgpu :0b:00.0: GPU reset succeeded, trying to resume
[ 248.279584] [drm] PCIE GART of 512M enabled (table at 0x00F40090).
[ 248.279639] [drm:amdgpu_device_gpu_recover [amdgpu]] *ERROR* VRAM is lost!
[ 248.279769] [drm] PSP is resuming...
[ 248.428305] [drm] reserve 0x40 from 0xf400d0 for PSP TMR SIZE
[ 248.472774] WARNING: CPU: 23 PID: 21634 at
/build/linux-uQJ2um/linux-4.15.0/kernel/kthread.c:498 kthread_park+0x67/0x80
[ 248.472775] Modules linked in: ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs
msr nls_utf8 cifs ccm fscache cmac bnep binfmt_misc nls_iso8859_1 edac_mce_amd
arc4 snd_hda_codec_realtek snd_hda_codec_generic kvm_amd snd_hda_codec_hdmi kvm
snd_seq_midi irqbypass snd_hda_intel snd_seq_midi_event snd_hda_codec btusb
snd_hda_core btrtl wmi_bmof snd_rawmidi iwlmvm snd_hwdep btbcm btintel snd_pcm
snd_seq bluetooth mac80211 snd_seq_device ecdh_generic snd_timer iwlwifi ccp
snd cfg80211 soundcore k10temp shpchp mac_hid sch_fq_codel ib_iser rdma_cm
iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi
nct6775 hwmon_vid parport_pc ppdev lp parport ip_tables x_tables autofs4 btrfs
zstd_compress raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor
async_tx xor raid6_pq libcrc32c raid1
[ 248.472823] multipath linear raid0 amdgpu(OE) amdchash(OE) amdttm(OE)
amd_sched(OE) mxm_wmi crct10dif_pclmul crc32_pclmul ghash_clmulni_intel pcbc
aesni_intel aes_x86_64 amdkcl(OE) crypto_simd glue_helper amd_iommu_v2 cryptd
drm_kms_helper syscopyarea sysfillrect sysimgblt igb fb_sys_fops drm dca nvme
i2c_algo_bit i2c_piix4 nvme_core ptp ahci atlantic libahci pps_core gpio_amdpt
wmi gpio_generic
[ 248.472846] CPU: 23 PID: 21634 Comm: a.out Tainted: G OE
4.15.0-45-generic #48-Ubuntu
[ 248.472847] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./X399 Professional Gaming, BIOS P3.30 08/14/2018
[ 248.472849] RIP: 0010:kthread_park+0x67/0x80
[ 248.472850] RSP: 0018:b44fc7e27ad0 EFLAGS: 00010202
[ 248.472852] RAX: 0004 RBX: 9ec63f49e480 RCX:
[ 248.472853] RDX: 9ec63c717198 RSI: 9ec63ea0c0c0 RDI:
9ec63dd38000
[ 248.472854] RBP: b44fc7e27ae0 R08: 0051 R09:
[ 248.472855] R10: R11: 0056 R12:
9ec63ea0c0c0
[ 248.472855] R13: 9ec64f4f4200 R14: 9ec63c71 R15:
[ 248.472857] FS: 7fd52a286c00() GS:9ec65cdc()
knlGS:
[ 248.472858] CS: 0010 DS: ES: CR0: 80050033
[ 248.472859] CR2: 7f0c07687a98 CR3: 00081b5b6000 CR4:
003406e0
[ 248.472860] Call Trace:
[ 248.472865] amddrm_sched_entity_fini+0x44/0x1b0 [amd_sched]
[ 248.472868] amddrm_sched_entity_destroy+0x1f/0x30 [amd_sched]
[ 248.472907] amdgpu_vm_fini+0xbb/0x4f0 [amdgpu]
[ 248.472942] amdgpu_driver_postclose_kms+0x15b/0x2b0 [amdgpu]
[ 248.472952] drm_release+0x26b/0x390 [drm]
[ 248.472955] __fput+0xea/0x220
[ 248.472957] fput+0xe/0x10
[ 248.472959] task_work_run+0x9d/0xc0
[ 248.472961] do_exit+0x2ec/0xb40
[ 248.472963] do_group_exit+0x43/0xb0
[ 248.472965] get_signal+0x27b/0x590
[ 248.472968] do_signal+0x37/0x730
[ 248.472971] ? __switch_to_asm+0x34/0x70
[ 248.472973] ? __switch_to_asm+0x40/0x70
[ 248.472976] ? do_vfs_ioctl+0xa8/0x630
[ 248.472978] ? __schedule+0x299/0x8a0
[ 248.472980] exit_to_usermode_loop+0x73/0xd0
[ 248.472982] do_syscall_64+0x115/0x130
[ 248.472984] entry_SYSCALL_64_after_hwframe+0x3d/0xa2
[ 248.472986] RIP: 0033:0x7fd528bdd5d7
[ 248.472987] RSP: 002b:7ffe830d4778 EFLAGS:
Re: [PATCH v2 1/3] drm: Add support for panic message output
Den 12.03.2019 11.58, skrev Daniel Vetter:
> On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
>>
>>
>> Den 11.03.2019 20.23, skrev Daniel Vetter:
>>> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
This adds support for outputting kernel messages on panic().
A kernel message dumper is used to dump the log. The dumper iterates
over each DRM device and it's crtc's to find suitable framebuffers.
All the other dumpers are run before this one except mtdoops.
Only atomic drivers are supported.
Signed-off-by: Noralf Trønnes
>>>
+static void drm_panic_kmsg_render_screen(struct drm_plane *plane,
+ struct kmsg_dumper *dumper)
+{
+ struct drm_framebuffer *fb = plane->state->fb;
+ bool first_iteration = true;
+ struct drm_panic_ctx ctx;
+ static char text[1024];
+ size_t len;
+
+ ctx.vmap = fb->funcs->panic_vmap(fb);
+
+ /* Print some info when testing */
+ if (dumper->max_reason == KMSG_DUMP_OOPS) {
+ struct drm_format_name_buf format_name;
+
+ pr_info("%s: [FB:%d] %ux%u format=%s vmap=%p\n",
+ __func__, fb->base.id, fb->width, fb->height,
+ drm_get_format_name(fb->format->format, _name),
+ ctx.vmap);
+ }
+
+ if (!ctx.vmap)
+ return;
>>>
>>> For some framebuffers it might be useful to not require vmap, but instead
>>> have some page-by-page kind of access helper. Since preemptively setting
>>> up a vmap for all the non-continous buffers is a bit much, and we really
>>> can't set up the vmap in the panic handler.
>>>
>>> Maybe we should call this panic_prepare/panic_finish and
>>> s/vmap/cookie/, to make it entirely opaque?
>>>
>>> But a bit overengineering perhaps :-)
>>>
>>
>> I guess i915 wants something else than vmap, but I have no idea how a
>> page-by-page solution is to be implemented.
>
> i915 should be mostly fine, since we have a GTT for remapping and can make
> it look continuous. It might not be in the part of the GTT accessible by
> the cpu though.
>
> Wrt implementation: My idea would be to extract the pixel writing function
> and export it to drivers. The driver would then implement a
> ->panic_draw_xy function which looks up the right page, computes it
> address, computes the x/y offset within (taking into account tiling and
> stuff like that), and then uses the helper function to draw the right
> pixel value for the format at the given address.
>
> That's why I suggested that drivers need to either implement
> ->panic_prepare or ->panic_draw_xy. Since for this approach you might not
> need a ->panic_prepare/cleanup implementation, since it's all done in
> ->panic_draw_xy on a pixel-by-pixel basis.
>
>> When we get bootsplash, we will at least have a kernel address during
>> that phase for all drivers supporting it.
>
> Hm, not following what you mean here. Why is bootsplash special?
>
Special in the sense that it's framebuffer will be linear and already
have a virtual address for its backing buffer since that's a
prerequisite for it to render the splash image.
Noralf.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 201957] amdgpu: ring gfx timeout
https://bugzilla.kernel.org/show_bug.cgi?id=201957 Cameron (ker...@cameron.bz) changed: What|Removed |Added CC||ker...@cameron.bz --- Comment #5 from Cameron (ker...@cameron.bz) --- I'm having a very similar issue, running Linux Mint 19.1. The issue has persisted from at least 4.15, I'm currently running 5.0.1 and the issue remains. Here is the latest syslog of the error: [37258.615599] gmc_v9_0_process_interrupt: 10 callbacks suppressed [37258.615608] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317) [37258.615615] amdgpu :06:00.0: in page starting at address 0x800107805000 from 27 [37258.615619] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x00301031 [37258.615629] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317) [37258.615633] amdgpu :06:00.0: in page starting at address 0x800107807000 from 27 [37258.615636] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x [37258.615645] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317) [37258.615648] amdgpu :06:00.0: in page starting at address 0x800107801000 from 27 [37258.615651] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x [37258.615660] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317) [37258.615663] amdgpu :06:00.0: in page starting at address 0x800107803000 from 27 [37258.615666] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x [37258.615675] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317) [37258.615678] amdgpu :06:00.0: in page starting at address 0x800107809000 from 27 [37258.615681] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x [37258.615689] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317) [37258.615692] amdgpu :06:00.0: in page starting at address 0x80010780b000 from 27 [37258.615695] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x [37258.615704] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317) [37258.615707] amdgpu :06:00.0: in page starting at address 0x800107805000 from 27 [37258.615710] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x [37258.615740] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317) [37258.615743] amdgpu :06:00.0: in page starting at address 0x800107807000 from 27 [37258.615746] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x [37258.615756] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317) [37258.615759] amdgpu :06:00.0: in page starting at address 0x800107801000 from 27 [37258.615762] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x [37258.615771] amdgpu :06:00.0: [gfxhub] VMC page fault (src_id:0 ring:24 vmid:3 pasid:32768, for process Xorg pid 1287 thread Xorg:cs0 pid 1317) [37258.615774] amdgpu :06:00.0: in page starting at address 0x800107803000 from 27 [37258.615777] amdgpu :06:00.0: VM_L2_PROTECTION_FAULT_STATUS:0x [37268.712339] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=602475, emitted seq=602478 [37268.712387] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 1287 thread Xorg:cs0 pid 1317 [37268.712389] [drm] GPU recovery disabled. [37278.952537] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=602475, emitted seq=602478 [37278.952624] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 1287 thread Xorg:cs0 pid 1317 [37278.952628] [drm] GPU recovery disabled. [37289.192390] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=602475, emitted seq=602478 [37289.192478] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 1287 thread Xorg:cs0 pid 1317 [37289.192481] [drm] GPU recovery disabled. [37299.432447] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx timeout, signaled seq=602475, emitted seq=602478 [37299.432534] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process Xorg pid 1287 thread Xorg:cs0 pid 1317 [37299.432538] [drm] GPU recovery disabled. [37309.676431] [drm:amdgpu_job_timedout [amdgpu]]
[Bug 109977] Segmentation fault in drmParsePlatformDeviceInfo
https://bugs.freedesktop.org/show_bug.cgi?id=109977
Eric Engestrom changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--- |FIXED
CC||emil.l.veli...@gmail.com
--- Comment #1 from Eric Engestrom ---
Thanks!
Your fix is correct, although partial: the same bug appears again in the free()
a couple lines below.
I've added it as part of your patch and pushed it:
commit 4735ca71af9f741e2438104d543dc3c5a8107f35
Author: Andreas Baierl
Date: Mon Mar 11 16:04:08 2019 +0100
xf86drm: Fix segmentation fault while parsing device info
This fixes a bug, which was introduced with commit ee798b98
"xf85drm: de-duplicate drmParse{Platform.Host1x}{Bus,Device}Info".
where accessing *compatible[i] with i>0 results in a segfault.
Signed-off-by: Andreas Baierl
Fixes: ee798b98479709acdd8d "xf85drm: de-duplicate
drmParse{Platform.Host1x}{Bus,Device}Info"
Reviewed-by: Eric Engestrom
[Eric: add the same fix to the free() below]
Signed-off-by: Eric Engestrom
--
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 5/5] drm: don't block fb changes for async plane updates
On 3/12/19 2:44 AM, Boris Brezillon wrote:
> On Mon, 11 Mar 2019 23:22:03 -0300
> Helen Koike wrote:
>
>> In the case of a normal sync update, the preparation of framebuffers (be
>> it calling drm_atomic_helper_prepare_planes() or doing setups with
>> drm_framebuffer_get()) are performed in the new_state and the respective
>> cleanups are performed in the old_state.
>>
>> In the case of async updates, the preparation is also done in the
>> new_state but the cleanups are done in the new_state (because updates
>> are performed in place, i.e. in the current state).
>>
>> The current code blocks async udpates when the fb is changed, turning
>> async updates into sync updates, slowing down cursor updates and
>> introducing regressions in igt tests with errors of type:
>>
>> "CRITICAL: completed 97 cursor updated in a period of 30 flips, we
>> expect to complete approximately 15360 updates, with the threshold set
>> at 7680"
>>
>> Fb changes in async updates were prevented to avoid the following scenario:
>>
>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, cleanup fb1
>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb2
>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
>> (wrong)
>> Where we have a single call to prepare fb2 but double cleanup call to fb2.
>>
>> To solve the above problems, instead of blocking async fb changes, we
>> place the old framebuffer in the new_state object, so when the code
>> performs cleanups in the new_state it will cleanup the old_fb and we
>> will have the following scenario instead:
>>
>> - Async update, oldfb = NULL, newfb = fb1, prepare fb1, no cleanup
>> - Async update, oldfb = fb1, newfb = fb2, prepare fb2, cleanup fb1
>> - Non-async commit, oldfb = fb2, newfb = fb1, prepare fb1, cleanup fb2
>>
>> Where calls to prepare/cleanup are balanced.
>>
>> Cc: # v4.14+
>> Fixes: 25dc194b34dd ("drm: Block fb changes for async plane updates")
>> Suggested-by: Boris Brezillon
>> Signed-off-by: Helen Koike
>
> Reviewed-by: Boris Brezillon
Reviewed-by: Nicholas Kazlauskas
I was thinking that the comment could go in async_commit or async_check,
but I guess it works there too. Maybe it needs a FIXME or a TODO for a
full state swap, but these are just nitpicks.
Nicholas Kazlauskas
>
>>
>> ---
>> Hello,
>>
>> As mentioned in the cover letter, I tested in almost all platforms with
>> igt plane_cursor_legacy and kms_cursor_legacy and I didn't see any
>> regressions. But I couldn't test on MSM and AMD because I don't have
>> the hardware I would appreciate if anyone could help me testing those.
>>
>> Thanks!
>> Helen
>>
>> Changes in v2:
>> - Change the order of the patch in the series, add this as the last one.
>> - Add documentation
>> - s/ballanced/balanced
>>
>> drivers/gpu/drm/drm_atomic_helper.c | 20 ++--
>> include/drm/drm_modeset_helper_vtables.h | 5 +
>> 2 files changed, 15 insertions(+), 10 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 540a77a2ade9..e7eb96f1efc2 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -1608,15 +1608,6 @@ int drm_atomic_helper_async_check(struct drm_device
>> *dev,
>> old_plane_state->crtc != new_plane_state->crtc)
>> return -EINVAL;
>>
>> -/*
>> - * FIXME: Since prepare_fb and cleanup_fb are always called on
>> - * the new_plane_state for async updates we need to block framebuffer
>> - * changes. This prevents use of a fb that's been cleaned up and
>> - * double cleanups from occuring.
>> - */
>> -if (old_plane_state->fb != new_plane_state->fb)
>> -return -EINVAL;
>> -
>> funcs = plane->helper_private;
>> if (!funcs->atomic_async_update)
>> return -EINVAL;
>> @@ -1657,6 +1648,9 @@ void drm_atomic_helper_async_commit(struct drm_device
>> *dev,
>> int i;
>>
>> for_each_new_plane_in_state(state, plane, plane_state, i) {
>> +struct drm_framebuffer *new_fb = plane_state->fb;
>> +struct drm_framebuffer *old_fb = plane->state->fb;
>> +
>> funcs = plane->helper_private;
>> funcs->atomic_async_update(plane, plane_state);
>>
>> @@ -1665,11 +1659,17 @@ void drm_atomic_helper_async_commit(struct
>> drm_device *dev,
>> * plane->state in-place, make sure at least common
>> * properties have been properly updated.
>> */
>> -WARN_ON_ONCE(plane->state->fb != plane_state->fb);
>> +WARN_ON_ONCE(plane->state->fb != new_fb);
>> WARN_ON_ONCE(plane->state->crtc_x != plane_state->crtc_x);
>> WARN_ON_ONCE(plane->state->crtc_y != plane_state->crtc_y);
>> WARN_ON_ONCE(plane->state->src_x != plane_state->src_x);
>> WARN_ON_ONCE(plane->state->src_y != plane_state->src_y);
>> +
>> +/*
Re: [PATCH] drm/atomic-helper: Validate pointer before dereference
Hi,
First of all, thanks for the feedback.
I will fix all the problems pointed out in the review.
I just have two inline questions.
On 03/12, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 06:01:20PM -0300, Rodrigo Siqueira wrote:
> > The function disable_outputs() and
> > drm_atomic_helper_commit_modeset_enables() tries to retrieve
> > helper_private from the target CRTC, for dereferencing some operations.
> > However, the current implementation does not check whether
> > helper_private is null and, if not, if it has a valid pointer to a dpms
> > and commit functions. This commit adds pointer validations before
> > trying to dereference the dpms and commit function.
> >
> > Signed-off-by: Rodrigo Siqueira
>
> Please also adjust the kerneldoc for these functions. And I think the
> patch subject can be improved, e.g. "Make ->atomic_enable/disable crtc
> callbacks optional". Describe what you're trying to achieve in the
> summary, not how you achieve it.
Do I need to add information which says that both functions are
optional? I'm asking because the description related to the affected
functions and struct looks good for me [1,2,3].
1. Documentation for drm_crtc_helper_funcs:
https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html?highlight=drm_crtc_helper_funcs#c.drm_crtc_helper_funcs
2. Documentation for drm_atomic_helper_commit_modeset_enables():
https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html?highlight=drm_atomic_helper_commit_modeset_enables#c.drm_atomic_helper_commit_modeset_enables
3. Documentation for drm_atomic_helper_commit_modeset_disables():
https://dri.freedesktop.org/docs/drm/gpu/drm-kms-helpers.html?highlight=drm_atomic_helper_commit_modeset_disables#c.drm_atomic_helper_commit_modeset_disables
> > ---
> > drivers/gpu/drm/drm_atomic_helper.c | 30 -
> > 1 file changed, 17 insertions(+), 13 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > b/drivers/gpu/drm/drm_atomic_helper.c
> > index 540a77a2ade9..fbeef7c461fc 100644
> > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > @@ -1028,14 +1028,16 @@ disable_outputs(struct drm_device *dev, struct
> > drm_atomic_state *old_state)
> >
> >
> > /* Right function depends upon target state. */
> > - if (new_crtc_state->enable && funcs->prepare)
> > - funcs->prepare(crtc);
> > - else if (funcs->atomic_disable)
> > - funcs->atomic_disable(crtc, old_crtc_state);
> > - else if (funcs->disable)
> > - funcs->disable(crtc);
> > - else
> > - funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> > + if (funcs) {
>
> I don't think making funcs optional is a good idea. If you have a crtc
> with no functions implemented, it's not terribly useful.
>
> Also making functions optional just here is not going to help if we still
> require it everywhere else.
Should I remove the other occurrence of "if (funcs)" inside
disable_outputs() and drm_atomic_helper_commit_modeset_enables()? Both
functions, already had this before.
Best Regards
> -Daniel
>
> > + if (new_crtc_state->enable && funcs->prepare)
> > + funcs->prepare(crtc);
> > + else if (funcs->atomic_disable)
> > + funcs->atomic_disable(crtc, old_crtc_state);
> > + else if (funcs->disable)
> > + funcs->disable(crtc);
> > + else if (funcs->dpms)
> > + funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> > + }
> >
> > if (!(dev->irq_enabled && dev->num_crtcs))
> > continue;
> > @@ -1277,11 +1279,13 @@ void
> > drm_atomic_helper_commit_modeset_enables(struct drm_device *dev,
> > if (new_crtc_state->enable) {
> > DRM_DEBUG_ATOMIC("enabling [CRTC:%d:%s]\n",
> > crtc->base.id, crtc->name);
> > -
> > - if (funcs->atomic_enable)
> > - funcs->atomic_enable(crtc, old_crtc_state);
> > - else
> > - funcs->commit(crtc);
> > + if (funcs) {
> > + if (funcs->atomic_enable)
> > + funcs->atomic_enable(crtc,
> > +old_crtc_state);
> > + else if (funcs->atomic_enable)
> > + funcs->commit(crtc);
> > + }
> > }
> > }
> >
> > --
> > 2.21.0
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Rodrigo Siqueira
https://siqueira.tech
Graduate Student
Department of Computer Science
University of São Paulo
___
dri-devel mailing
[Bug 109977] Segmentation fault in drmParsePlatformDeviceInfo
https://bugs.freedesktop.org/show_bug.cgi?id=109977
Bug ID: 109977
Summary: Segmentation fault in drmParsePlatformDeviceInfo
Product: DRI
Version: XOrg git
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: medium
Component: libdrm
Assignee: dri-devel@lists.freedesktop.org
Reporter: ich...@imkreisrum.de
Created attachment 143633
--> https://bugs.freedesktop.org/attachment.cgi?id=143633=edit
[PATCH libdrm] xf86drm: Fix segmentation fault while parsing device info
Since commit ee798b98479709acdd8d1492689dc93c1a62f239 (xf85drm: de-duplicate
drmParse{Platform.Host1x}{Bus,Device}Info)
I encounter a segfault at line 3632:
*compatible[i] = tmp_name;
Libdrm segfaults as soon as i>0.
This was encountered on armhf platform (Allwinner A10) with kernel 5.0
including drm-misc-next and the lima driver
(https://gitlab.freedesktop.org/lima/linux/commits/lima-drm-misc-next-20190309)
and the lima mesa branch (https://gitlab.freedesktop.org/lima/mesa) while
running glmark2-es2-drm and kmscube.
You can see the original issue including backtrace and strace reported here:
https://gitlab.freedesktop.org/lima/mesa/issues/80#note_129271
The attached patch fixes it.
--
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 1/5] drm/rockchip: fix fb references in async update
On Tue, Mar 12, 2019 at 07:34:38AM +0100, Boris Brezillon wrote:
> On Mon, 11 Mar 2019 23:21:59 -0300
> Helen Koike wrote:
>
> > In the case of async update, modifications are done in place, i.e. in the
> > current plane state, so the new_state is prepared and the new_state is
> > cleanup up (instead of the old_state, diferrently on what happen in a
>
> ^ cleaned up^ differently (but maybe
> "unlike what happens" is more appropriate here).
>
> > normal sync update).
> > To cleanup the old_fb properly, it needs to be placed in the new_state
> > in the end of async_update, so cleanup call will unreference the old_fb
> > correctly.
> >
> > Also, the previous code had a:
> >
> > plane_state = plane->funcs->atomic_duplicate_state(plane);
> > ...
> > swap(plane_state, plane->state);
> >
> > if (plane->state->fb && plane->state->fb != new_state->fb) {
> > ...
> > }
> >
> > Which was wrong, as the fb were just assigned to be equal, so this if
> > statement nevers evaluates to true.
> >
> > Another details is that the function drm_crtc_vblank_get() can only be
> > called when vop->is_enabled is true, otherwise it has no effect and
> > trows a WARN_ON().
> >
> > Calling drm_atomic_set_fb_for_plane() (which get a referent of the new
> > fb and pus the old fb) is not required, as it is taken care by
> > drm_mode_cursor_universal() when calling
> > drm_atomic_helper_update_plane().
> >
> > Signed-off-by: Helen Koike
> >
> > ---
> > Hello,
> >
> > I tested on the rockchip ficus v1.1 using igt plane_cursor_legacy and
> > kms_cursor_legacy and I didn't see any regressions.
> >
> > Changes in v2: None
> >
> > drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 42 -
> > 1 file changed, 24 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > index c7d4c6073ea5..a1ee8c156a7b 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> > @@ -912,30 +912,31 @@ static void vop_plane_atomic_async_update(struct
> > drm_plane *plane,
> > struct drm_plane_state *new_state)
> > {
> > struct vop *vop = to_vop(plane->state->crtc);
> > - struct drm_plane_state *plane_state;
> > + struct drm_framebuffer *old_fb = plane->state->fb;
> >
> > - plane_state = plane->funcs->atomic_duplicate_state(plane);
> > - plane_state->crtc_x = new_state->crtc_x;
> > - plane_state->crtc_y = new_state->crtc_y;
> > - plane_state->crtc_h = new_state->crtc_h;
> > - plane_state->crtc_w = new_state->crtc_w;
> > - plane_state->src_x = new_state->src_x;
> > - plane_state->src_y = new_state->src_y;
> > - plane_state->src_h = new_state->src_h;
> > - plane_state->src_w = new_state->src_w;
> > -
> > - if (plane_state->fb != new_state->fb)
> > - drm_atomic_set_fb_for_plane(plane_state, new_state->fb);
> > -
> > - swap(plane_state, plane->state);
> > -
> > - if (plane->state->fb && plane->state->fb != new_state->fb) {
> > + /*
> > +* A scanout can still be occurring, so we can't drop the reference to
> > +* the old framebuffer. To solve this we get a reference to old_fb and
> > +* set a worker to release it later.
>
> Hm, doesn't look like an async update to me if we have to wait for the
> next VBLANK to happen to get the new content on the screen. Maybe we
> should reject async updates when old_fb != new_fb in the rk
> ->async_check() hook.
Scanning out garbage because the old buffer is unpinned too quickly is one
of the long-term "features" of async updates. At least for features.
It's another one of these things we need to fix. Which might become easier
if we switch to usual state switching, since then we can punt the
cleanup_plane phase to a worker.
Note that depending upon the gpu this might not just result in garbage but
hangs, usually when there's an iommu and the chip dies if it accesses an
unmapped page.
Probably something to fix later on in async framework.
-Daniel
>
> > +*/
> > + if (vop->is_enabled &&
> > + plane->state->fb && plane->state->fb != new_state->fb) {
> > drm_framebuffer_get(plane->state->fb);
> > WARN_ON(drm_crtc_vblank_get(plane->state->crtc) != 0);
> > drm_flip_work_queue(>fb_unref_work, plane->state->fb);
> > set_bit(VOP_PENDING_FB_UNREF, >pending);
> > }
>
> In any case, I think this should be called after
> vop_plane_atomic_update() to prevent the situation where the VBLANK
> event happens between this point and the following
> vop_plane_atomic_update() call.
>
> >
> > + plane->state->crtc_x = new_state->crtc_x;
> > + plane->state->crtc_y = new_state->crtc_y;
> > + plane->state->crtc_h = new_state->crtc_h;
> > + plane->state->crtc_w = new_state->crtc_w;
> > + plane->state->src_x = new_state->src_x;
> > +
Re: [PATCH] drm/atomic-helper: Validate pointer before dereference
On Mon, Mar 11, 2019 at 06:01:20PM -0300, Rodrigo Siqueira wrote:
> The function disable_outputs() and
> drm_atomic_helper_commit_modeset_enables() tries to retrieve
> helper_private from the target CRTC, for dereferencing some operations.
> However, the current implementation does not check whether
> helper_private is null and, if not, if it has a valid pointer to a dpms
> and commit functions. This commit adds pointer validations before
> trying to dereference the dpms and commit function.
>
> Signed-off-by: Rodrigo Siqueira
Please also adjust the kerneldoc for these functions. And I think the
patch subject can be improved, e.g. "Make ->atomic_enable/disable crtc
callbacks optional". Describe what you're trying to achieve in the
summary, not how you achieve it.
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 30 -
> 1 file changed, 17 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 540a77a2ade9..fbeef7c461fc 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1028,14 +1028,16 @@ disable_outputs(struct drm_device *dev, struct
> drm_atomic_state *old_state)
>
>
> /* Right function depends upon target state. */
> - if (new_crtc_state->enable && funcs->prepare)
> - funcs->prepare(crtc);
> - else if (funcs->atomic_disable)
> - funcs->atomic_disable(crtc, old_crtc_state);
> - else if (funcs->disable)
> - funcs->disable(crtc);
> - else
> - funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> + if (funcs) {
I don't think making funcs optional is a good idea. If you have a crtc
with no functions implemented, it's not terribly useful.
Also making functions optional just here is not going to help if we still
require it everywhere else.
-Daniel
> + if (new_crtc_state->enable && funcs->prepare)
> + funcs->prepare(crtc);
> + else if (funcs->atomic_disable)
> + funcs->atomic_disable(crtc, old_crtc_state);
> + else if (funcs->disable)
> + funcs->disable(crtc);
> + else if (funcs->dpms)
> + funcs->dpms(crtc, DRM_MODE_DPMS_OFF);
> + }
>
> if (!(dev->irq_enabled && dev->num_crtcs))
> continue;
> @@ -1277,11 +1279,13 @@ void drm_atomic_helper_commit_modeset_enables(struct
> drm_device *dev,
> if (new_crtc_state->enable) {
> DRM_DEBUG_ATOMIC("enabling [CRTC:%d:%s]\n",
>crtc->base.id, crtc->name);
> -
> - if (funcs->atomic_enable)
> - funcs->atomic_enable(crtc, old_crtc_state);
> - else
> - funcs->commit(crtc);
> + if (funcs) {
> + if (funcs->atomic_enable)
> + funcs->atomic_enable(crtc,
> + old_crtc_state);
> + else if (funcs->atomic_enable)
> + funcs->commit(crtc);
> + }
> }
> }
>
> --
> 2.21.0
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add support for panic message output
On Mon, Mar 11, 2019 at 11:33:15PM +0100, Noralf Trønnes wrote:
>
>
> Den 11.03.2019 20.23, skrev Daniel Vetter:
> > On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> >> This adds support for outputting kernel messages on panic().
> >> A kernel message dumper is used to dump the log. The dumper iterates
> >> over each DRM device and it's crtc's to find suitable framebuffers.
> >>
> >> All the other dumpers are run before this one except mtdoops.
> >> Only atomic drivers are supported.
> >>
> >> Signed-off-by: Noralf Trønnes
> >
> > Bunch of comments/ideas for you or Darwish below, whoever picks this up.
>
> Actually it would ne nice if Darwish could pick it up since he will do
> it on i915 which will be useful to a much broader audience.
> If not I'll respin when I'm done with the drm_fb_helper refactoring.
>
>
>
> >> diff --git a/drivers/gpu/drm/drm_panic.c b/drivers/gpu/drm/drm_panic.c
> >> new file mode 100644
> >> index ..4bca7f0bc369
> >> --- /dev/null
> >> +++ b/drivers/gpu/drm/drm_panic.c
> >> @@ -0,0 +1,363 @@
> >> +// SPDX-License-Identifier: GPL-2.0
> >> +// Copyright 2018 Noralf Trønnes
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#include "drm_internal.h"
> >> +
> >> +/*
> >> + * The log lines in an ARM stack dump are 92 characters long
> >> + * and 120 is a nice multiple for HD and 4K.
> >> + */
> >> +#define DRM_PANIC_COLUMN_WIDTH120
> >
> > I think we should compute this dynamically from the actual fb width and
> > font witdth.
>
> The font is picked based on whether it can fit 50 lines of text.
>
> The next rule is to decide when to add another column. I decided to use
> a number that gets most log lines in one line on the screen. If most
> lines get broken into two lines, there's not much use in an extra column.
>
> Do you have another idea on how to do this?
>
> (There's even a 16x32 font now that wasn't available when I did this.)
Oh I had no idea that this is for multi-column oops printing. That's
indeed neat for 4k screens.
>
> >
> >> +
> >> +struct drm_panic_ctx {
> >> + struct drm_framebuffer *fb;
> >> + unsigned int width;
> >> + unsigned int height;
> >> + void *vmap;
> >> +
> >> + const struct font_desc *font;
> >> + unsigned int col_width;
> >> + unsigned int bottom_y;
> >> + size_t max_line_length;
> >> +
> >> + unsigned int x;
> >> + unsigned int y;
> >> +};
> >> +
> >> +static const struct font_desc *drm_panic_font8x8, *drm_panic_font8x16;
> >> +
> >> +static void drm_panic_draw_xy(struct drm_framebuffer *fb, void *vmap,
> >> +int x, int y, bool fg)
> >> +{
> >> + if (fb->funcs->panic_draw_xy)
> >> + fb->funcs->panic_draw_xy(fb, vmap, x, y, fg);
> >> + else
> >> + drm_framebuffer_panic_draw_xy(fb, vmap, x, y, fg);
> >> +}
> >> +
> >> +static void drm_panic_render_char(struct drm_panic_ctx *ctx,
> >> +unsigned int offset, char c)
> >> +{
> >> + unsigned int h, w, x, y;
> >> + u8 fontline;
> >> +
> >> + for (h = 0; h < ctx->font->height; h++) {
> >> + fontline = *(u8 *)(ctx->font->data + c * ctx->font->height + h);
> >> +
> >> + for (w = 0; w < ctx->font->width; w++) {
> >> + x = ctx->x + (offset * ctx->font->width) + w;
> >> + y = ctx->y + h;
> >> + drm_panic_draw_xy(ctx->fb, ctx->vmap, x, y,
> >> +fontline & BIT(7 - w));
> >> + }
> >> + }
> >> +}
> >> +
> >> +static void drm_panic_render_line(struct drm_panic_ctx *ctx,
> >> +const char *line, size_t len)
> >> +{
> >> + unsigned int i;
> >> +
> >> + for (i = 0; i < len; i++)
> >> + drm_panic_render_char(ctx, i, line[i]);
> >> +
> >> + /* Clear out the rest of the line */
> >> + for (i = len; i < ctx->max_line_length; i++)
> >> + drm_panic_render_char(ctx, i, ' ');
> >> +}
> >> +
> >> +static bool drm_panic_newline(struct drm_panic_ctx *ctx)
> >> +{
> >> + if (ctx->x == 0 && ctx->y == 0)
> >> + return false;
> >> + if (ctx->y == 0) {
> >> + ctx->x -= ctx->col_width;
> >> + ctx->y = ctx->bottom_y;
> >> + } else {
> >> + ctx->y -= ctx->font->height;
> >> + }
> >> +
> >> + return true;
> >> +}
> >> +
> >> +/* Render from bottom right most column */
> >> +static bool drm_panic_render_lines(struct drm_panic_ctx *ctx,
> >> + const char *str, size_t len)
> >> +{
> >> + size_t l, line_length;
> >> + const char *pos;
> >> + int i;
> >> +
> >> + while (len) {
> >> + pos = str + len - 1;
> >> +
> >> + if (*pos == '\n') {
> >> + len--;
> >> + if (!drm_panic_newline(ctx))
> >> +
Re: 2019 X.Org Foundation Election Candidates
On Tue, Mar 12, 2019 at 12:24:00AM +, Wentland, Harry wrote: > To all X.Org Foundation Members: > > The election for the X.Org Foundation Board of Directors will begin on > 14 March 2019. We have 6 candidates who are running for 4 seats. They > are (in alphabetical order): > Attached below are the Personal Statements each candidate submitted > for your consideration along with their Statements of Contribution > that they submitted with the membership application. Please review > each of the candidates' statements to help you decide whom to vote for > during the upcoming election. > > If you have questions of the candidates, you should feel free to ask them > here on the mailing list. > > The election committee will provide detailed instructions on how the voting > system will work when the voting period begins. > > Harry, on behalf of the X.Org elections committee Are these candidates the only thing we will be voting on? Luc Verhaegen. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/3] drm: Add support for panic message output
On 2019-03-11 6:42 p.m., Noralf Trønnes wrote:
> This adds support for outputting kernel messages on panic().
> A kernel message dumper is used to dump the log. The dumper iterates
> over each DRM device and it's crtc's to find suitable framebuffers.
>
> All the other dumpers are run before this one except mtdoops.
> Only atomic drivers are supported.
>
> Signed-off-by: Noralf Trønnes
> ---
> [...]
>
> diff --git a/include/drm/drm_framebuffer.h b/include/drm/drm_framebuffer.h
> index f0b34c977ec5..f3274798ecfe 100644
> --- a/include/drm/drm_framebuffer.h
> +++ b/include/drm/drm_framebuffer.h
> @@ -94,6 +94,44 @@ struct drm_framebuffer_funcs {
>struct drm_file *file_priv, unsigned flags,
>unsigned color, struct drm_clip_rect *clips,
>unsigned num_clips);
> +
> + /**
> + * @panic_vmap:
> + *
> + * Optional callback for panic handling.
> + *
> + * For vmapping the selected framebuffer in a panic context. Must
> + * be super careful about locking (only trylocking allowed).
> + *
> + * RETURNS:
> + *
> + * NULL if it didn't work out, otherwise an opaque cookie which is
> + * passed to @panic_draw_xy. It can be anything: vmap area, structure
> + * with more details, just a few flags, ...
> + */
> + void *(*panic_vmap)(struct drm_framebuffer *fb);
FWIW, the panic_vmap hook cannot work in general with the amdgpu/radeon
drivers:
Framebuffers are normally tiled, writing to them with the CPU results in
garbled output.
With a discrete GPU having a large amount of VRAM, the framebuffer may
not be directly CPU accessible at all.
There would need to be a mechanism for switching scanout to a linear,
CPU accessible framebuffer.
--
Earthling Michel Dänzer | https://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104602] [apitrace] Graphical artifacts in Civilization VI on RX Vega
https://bugs.freedesktop.org/show_bug.cgi?id=104602 oliver.trie...@haspa.de changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #19 from oliver.trie...@haspa.de --- I also confirm success on Ryzen 2200g system. Steam launch property `R600_DEBUG=nir %command%` fixed texture flickering/artifacts in CIV6 (that appeared on strategic map). olly@ryzen-pc1:~$ uname -a Linux ryzen-pc1 5.0.0-05-generic #201903032031 SMP Mon Mar 4 01:33:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux olly@ryzen-pc1:~$ glxinfo | grep "OpenGL version" OpenGL version string: 4.5 (Compatibility Profile) Mesa 18.3.3 olly@ryzen-pc1:~$ lspci -nnk | grep -i VGA -A2 38:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Raven Ridge [Radeon Vega Series / Radeon Vega Mobile Series] [1002:15dd] (rev c8) Subsystem: Micro-Star International Co., Ltd. [MSI] Vega [Radeon Vega 8 Mobile] [1462:7a39] Kernel driver in use: amdgpu olly@ryzen-pc1:~$ lsb_release -a No LSB modules are available. Description: Ubuntu 18.04.2 LTS -- 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 109975] personal banking button is not working
https://bugs.freedesktop.org/show_bug.cgi?id=109975 ramana changed: What|Removed |Added URL||http://192.168.1.97/ebank2/ ||home.aspx -- 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 109975] personal banking button is not working
https://bugs.freedesktop.org/show_bug.cgi?id=109975 Bug ID: 109975 Summary: personal banking button is not working Product: DRI Version: DRI git Hardware: x86-64 (AMD64) OS: Windows (All) Status: NEW Severity: major Priority: medium Component: DRM/AMDgpu-pro Assignee: dri-devel@lists.freedesktop.org Reporter: ramanavaizurs3...@gmail.com Created attachment 143632 --> https://bugs.freedesktop.org/attachment.cgi?id=143632=edit personal banking button is not working enter valid URL click on go In visitor flow personal banking button is not displayed -- 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: DRM-based Oops viewer
On Mon, 11 Mar 2019, "Ahmed S. Darwish" wrote: > Hello Jani, > > On Mon, Mar 11, 2019 at 11:04:19AM +0200, Jani Nikula wrote: >> On Sun, 10 Mar 2019, "Ahmed S. Darwish" wrote: >> Please first better define what you want to achieve. >> > > Oh I thought this was clear.. > > What I want to achieve is: > > - for normal day-to-day x86 laptops users > - properly inform the user when a kernel panic happens during > a running graphical session (e.g. wayland/gnome/kde/...). Thanks for the detailed reply. It always helps to start with the problem you want to solve or end goal you want to reach. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109974] libgl will not load radeonsi on X running using DRM lease
https://bugs.freedesktop.org/show_bug.cgi?id=109974 Michel Dänzer changed: What|Removed |Added Resolution|--- |NOTOURBUG Status|NEW |RESOLVED --- Comment #1 from Michel Dänzer --- AFAICT this is due to the Xorg modesetting driver / glamor still relying on drmGet/AuthMagic even for DRI3 clients. Please file an issue at https://gitlab.freedesktop.org/xorg/xserver/issues/new?issue . Meanwhile, you can try xf86-video-amdgpu, which uses DRM render nodes for DRI3 clients if available. -- 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 109974] libgl will not load radeonsi on X running using DRM lease
https://bugs.freedesktop.org/show_bug.cgi?id=109974 Michel Dänzer changed: What|Removed |Added Attachment #143631|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109974] libgl will not load radeonsi on X running using DRM lease
https://bugs.freedesktop.org/show_bug.cgi?id=109974 Bug ID: 109974 Summary: libgl will not load radeonsi on X running using DRM lease Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: p...@polepetko.eu QA Contact: dri-devel@lists.freedesktop.org Created attachment 143631 --> https://bugs.freedesktop.org/attachment.cgi?id=143631=edit Xorg log Running any OpenGL application on X running using DRM lease will result in fallback to swrast. But the modesseting driver is able to use radeonsi for glamor. LIBGL_DEBUG=verbose glxinfo | grep OpenGL libGL: screen 0 does not appear to be DRI3 capable libGL error: failed to authenticate magic 10 libGL error: failed to load driver: radeonsi libGL: MESA-LOADER: dlopen(/usr/lib64/dri/swrast_dri.so) libGL: Can't open configuration file /etc/drirc: No such file or directory. libGL: Can't open configuration file /etc/drirc: No such file or directory. OpenGL vendor string: VMware, Inc. OpenGL renderer string: llvmpipe (LLVM 7.0, 128 bits) OpenGL core profile version string: 3.3 (Core Profile) Mesa 19.1.0-devel (git-9ab1b1d022) OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.1 Mesa 19.1.0-devel (git-9ab1b1d022) OpenGL shading language version string: 1.40 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.0 Mesa 19.1.0-devel (git-9ab1b1d022) OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.00 OpenGL ES profile extensions: Xorg 1.20.4 libdrm 2.4.97 Mesa 19.1.0-devel (git-9ab1b1d022) kernel 5.0.0-gentoo -- 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 1/3] drm: Add support for panic message output
On Tue, Mar 12, 2019 at 10:53:20AM +0100, Daniel Vetter wrote:
> On Mon, Mar 11, 2019 at 11:40:36PM +0100, Noralf Trønnes wrote:
> >
> >
> > Den 11.03.2019 20.29, skrev Daniel Vetter:
> > > On Mon, Mar 11, 2019 at 08:23:38PM +0100, Daniel Vetter wrote:
> > >> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> > >>> This adds support for outputting kernel messages on panic().
> > >>> A kernel message dumper is used to dump the log. The dumper iterates
> > >>> over each DRM device and it's crtc's to find suitable framebuffers.
> > >>>
> > >>> All the other dumpers are run before this one except mtdoops.
> > >>> Only atomic drivers are supported.
> > >>>
> > >>> Signed-off-by: Noralf Trønnes
> >
> >
> >
> > >>> +static void drm_panic_try_dev(struct drm_device *dev, struct
> > >>> kmsg_dumper *dumper)
> > >>> +{
> > >>> + struct drm_framebuffer *fb;
> > >>> + struct drm_plane *plane;
> > >>> + struct drm_crtc *crtc;
> > >>> +
> > >>> + if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> > >>> + return;
> > >>> +
> > >>> + if (dumper->max_reason == KMSG_DUMP_OOPS)
> > >>> + pr_info("%s: %s on minor %d\n", __func__,
> > >>> dev->driver->name,
> > >>> + dev->primary->index);
> > >>> +
> > >>> + drm_for_each_crtc(crtc, dev) {
> > >>> + if (!ww_mutex_trylock(>mutex.mutex))
> > >>> + continue;
> > >>> +
> > >>> + if (!crtc->enabled || !crtc->primary)
> > >>> + goto crtc_unlock;
> > >>> +
> > >>> + if (!crtc->state || !crtc->state->active)
> > >>> + goto crtc_unlock;
> > >>> +
> > >>> + plane = crtc->primary;
> > >>> + if (!ww_mutex_trylock(>mutex.mutex))
> > >>> + goto crtc_unlock;
> > >>> +
> > >>> + /*
> > >>> +* TODO: Should we check plane_state->visible?
> > >>> +* It is not set on vc4
> > >>
> > >> I think we should. We should also check whether that primary is connected
> > >> to the crtc (some hw you can reassign planes freely between crtc, and the
> > >> crtc->primary pointer is only used for compat with legacy ioctl).
> > >>
> > >>> + if (!plane->state || !plane->state->visible)
> > >>> +*/
> > >>> + if (!plane->state)
> > >>> + goto plane_unlock;
> > >>> +
> > >>> + fb = plane->state->fb;
> > >>> + if (!fb || !fb->funcs->panic_vmap)
> > >>
> > >> Docs says this is optional, doesn't seem to be all that optional. I'd
> > >> check for this or a driver-specific ->panic_draw_xy instead.
> > >>> + goto plane_unlock;
> > >>> +
> > >>> + /*
> > >>> +* fbcon puts out panic messages so stay away to avoid
> > >>> jumbled
> > >>> +* output. If vc->vc_mode != KD_TEXT fbcon won't put out
> > >>> +* messages (see vt_console_print).
> > >>> +*/
> > >>> + if (dev->fb_helper && dev->fb_helper->fb == fb)
> > >
> > > This is a bit a layering violation. Could we instead tell fbcon that it
> > > shouldn't do panic handling for drm drivers? I think that would resolve
> > > this overlap here in a much cleaner way. drm fbdev helpers already have
> > > lots of oops_in_progress checks all over to make sure fbcon doesn't do
> > > anything bad. That only leaves the actual rendering, which I think we can
> > > stop too with a simple flag.
> > >
> > > Ofc only for atomic drivers which have this panic handling mode here
> > > implemented.
> >
> > There used to be a fbdev flag FBINFO_CAN_FORCE_OUTPUT that controlled
> > vc->vc_panic_force_write, but it's gone now I see.
>
> I killed that :-)
>
> Looking at those patches again, it's not what we wanted. It was used to
> force panic display even when not in KD_TEXT mode.
>
> What we want instead here is a flag to tell fbcon/vt to _never_ write
> dmesg to our console, not even when the console is in KD_TEXT mode.
> Because we have a separate panic handler to display it. Heck maybe that QR
> code thing could be resurrected eventually again.
>
> Totally untested snippet below is what I'm thinking of:
>
>
> diff --git a/drivers/video/fbdev/core/fbcon.c
> b/drivers/video/fbdev/core/fbcon.c
> index 7f4c22a65f63..b08c63286ed0 100644
> --- a/drivers/video/fbdev/core/fbcon.c
> +++ b/drivers/video/fbdev/core/fbcon.c
> @@ -282,6 +282,9 @@ static inline int fbcon_is_inactive(struct vc_data *vc,
> struct fb_info *info)
> {
> struct fbcon_ops *ops = info->fbcon_par;
>
> + if (oops_in_progress && info->flags & NO_OOPS_OUTPUT)
> + return false;
> +
> return (info->state != FBINFO_STATE_RUNNING ||
> vc->vc_mode != KD_TEXT || ops->graphics);
> }
>
>
> Plus then unconditionally rendering the oops output on the drm side, even
> if the
Re: [PATCH v2 1/3] drm: Add support for panic message output
On Mon, Mar 11, 2019 at 11:40:36PM +0100, Noralf Trønnes wrote:
>
>
> Den 11.03.2019 20.29, skrev Daniel Vetter:
> > On Mon, Mar 11, 2019 at 08:23:38PM +0100, Daniel Vetter wrote:
> >> On Mon, Mar 11, 2019 at 06:42:16PM +0100, Noralf Trønnes wrote:
> >>> This adds support for outputting kernel messages on panic().
> >>> A kernel message dumper is used to dump the log. The dumper iterates
> >>> over each DRM device and it's crtc's to find suitable framebuffers.
> >>>
> >>> All the other dumpers are run before this one except mtdoops.
> >>> Only atomic drivers are supported.
> >>>
> >>> Signed-off-by: Noralf Trønnes
>
>
>
> >>> +static void drm_panic_try_dev(struct drm_device *dev, struct kmsg_dumper
> >>> *dumper)
> >>> +{
> >>> + struct drm_framebuffer *fb;
> >>> + struct drm_plane *plane;
> >>> + struct drm_crtc *crtc;
> >>> +
> >>> + if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> >>> + return;
> >>> +
> >>> + if (dumper->max_reason == KMSG_DUMP_OOPS)
> >>> + pr_info("%s: %s on minor %d\n", __func__, dev->driver->name,
> >>> + dev->primary->index);
> >>> +
> >>> + drm_for_each_crtc(crtc, dev) {
> >>> + if (!ww_mutex_trylock(>mutex.mutex))
> >>> + continue;
> >>> +
> >>> + if (!crtc->enabled || !crtc->primary)
> >>> + goto crtc_unlock;
> >>> +
> >>> + if (!crtc->state || !crtc->state->active)
> >>> + goto crtc_unlock;
> >>> +
> >>> + plane = crtc->primary;
> >>> + if (!ww_mutex_trylock(>mutex.mutex))
> >>> + goto crtc_unlock;
> >>> +
> >>> + /*
> >>> + * TODO: Should we check plane_state->visible?
> >>> + * It is not set on vc4
> >>
> >> I think we should. We should also check whether that primary is connected
> >> to the crtc (some hw you can reassign planes freely between crtc, and the
> >> crtc->primary pointer is only used for compat with legacy ioctl).
> >>
> >>> + if (!plane->state || !plane->state->visible)
> >>> + */
> >>> + if (!plane->state)
> >>> + goto plane_unlock;
> >>> +
> >>> + fb = plane->state->fb;
> >>> + if (!fb || !fb->funcs->panic_vmap)
> >>
> >> Docs says this is optional, doesn't seem to be all that optional. I'd
> >> check for this or a driver-specific ->panic_draw_xy instead.
> >>> + goto plane_unlock;
> >>> +
> >>> + /*
> >>> + * fbcon puts out panic messages so stay away to avoid jumbled
> >>> + * output. If vc->vc_mode != KD_TEXT fbcon won't put out
> >>> + * messages (see vt_console_print).
> >>> + */
> >>> + if (dev->fb_helper && dev->fb_helper->fb == fb)
> >
> > This is a bit a layering violation. Could we instead tell fbcon that it
> > shouldn't do panic handling for drm drivers? I think that would resolve
> > this overlap here in a much cleaner way. drm fbdev helpers already have
> > lots of oops_in_progress checks all over to make sure fbcon doesn't do
> > anything bad. That only leaves the actual rendering, which I think we can
> > stop too with a simple flag.
> >
> > Ofc only for atomic drivers which have this panic handling mode here
> > implemented.
>
> There used to be a fbdev flag FBINFO_CAN_FORCE_OUTPUT that controlled
> vc->vc_panic_force_write, but it's gone now I see.
I killed that :-)
Looking at those patches again, it's not what we wanted. It was used to
force panic display even when not in KD_TEXT mode.
What we want instead here is a flag to tell fbcon/vt to _never_ write
dmesg to our console, not even when the console is in KD_TEXT mode.
Because we have a separate panic handler to display it. Heck maybe that QR
code thing could be resurrected eventually again.
Totally untested snippet below is what I'm thinking of:
diff --git a/drivers/video/fbdev/core/fbcon.c b/drivers/video/fbdev/core/fbcon.c
index 7f4c22a65f63..b08c63286ed0 100644
--- a/drivers/video/fbdev/core/fbcon.c
+++ b/drivers/video/fbdev/core/fbcon.c
@@ -282,6 +282,9 @@ static inline int fbcon_is_inactive(struct vc_data *vc,
struct fb_info *info)
{
struct fbcon_ops *ops = info->fbcon_par;
+ if (oops_in_progress && info->flags & NO_OOPS_OUTPUT)
+ return false;
+
return (info->state != FBINFO_STATE_RUNNING ||
vc->vc_mode != KD_TEXT || ops->graphics);
}
Plus then unconditionally rendering the oops output on the drm side, even
if the current fb is the fbcon one.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109973] System hangs/freeze/hiccups
https://bugs.freedesktop.org/show_bug.cgi?id=109973 Bug ID: 109973 Summary: System hangs/freeze/hiccups Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: FreeBSD Status: NEW Severity: critical Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: walterkrup...@gmail.com Hi all, My system is: CPU: AMD Ryzen2 2700x MB: Asus x470-F Memory: Corsair 32GB PC3200mhz GPU: Asus Rog Strix Vega 64 Monitor: Asus MG279Q ( 2560x1440, 144hz ) (connected at display port 0) + (FreeSync is ON from Monitor Settings) (also tried OFF) Disk: Corsair Nvme 1920gb OS: Freebsd 12 p3 Problem Description: Sudden FPS dropouts and sometimes full system freeze/lock (requires hard reset), + and time to time 15/30ms freezes (doesnt require hard reboot but happens exactly the same time with sudden fps dropouts) can be problem caused by dynamic power management of gpu/amdgpu ? ( i did amdgpu.dpm=0 at /boot/loader.conf but doesnt seem to effect.. ) Note: all the hardware above has been tested at another pc, they work flawlessly at arch linux (no freezes no hiccups no sudden fps dropouts) (so hardware are fine) clinfo reports; Number of platforms 0 .. so I'm confused about what works and not or partially works in my system.. (opengl,opencl,vulkan,rocm?,etc..) (+which packages/ports are missing and need to be installed..) Attached files are: (due attachment limit per post were 5 files max, i posted the rest of the files with my other posts in this topic) 1> uname -a 2> kldstat 3> xrandr 4> /boot/loader.conf 5> /etc/rc.conf 6> dmesg 7> /var/log/messages 8> xorg.conf 9> /var/log/xorg.log.0 10> /var/log/Xorg.log.0 (when full system freeze occurs)=> "[mi] EQ overflowing." + "[mi] This may be caused by a misbehaving driver monopolizing the server's resources." 11> pkg info (installed packages) (comparison with arch wiki amdgpu + xorg amdgpu + https://wiki.freebsd.org/Graphics) 12/13/14/15> glxinfo + glxgears + vulkaninfo + vdpauinfo 16> pciconf -lvbce 17> devinfo -vr 18> sysctl hw.model ---> total 18 files. Since I cant attach all the files above to this bug report, i submit the link/url that I have attached them to.. https://forums.freebsd.org/threads/freebsd-12-amdgpu-freeze-hiccups.69980/ I really would appriciate any help. Thanks 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
