On Tue, Apr 20, 2021 at 3:18 AM Daniel Stone wrote:
>
> Hi,
>
> On Mon, 19 Apr 2021 at 13:06, Simon Ser wrote:
>>
>> I'm working on a Wayland extension [1] that, among other things, allows
>> compositors to advertise the preferred device to be used by Wayland
>> clients.
>>
>> In general, composi
On Mon, Mar 29, 2021 at 7:47 AM Will Deacon wrote:
>
> On Fri, Mar 26, 2021 at 04:13:02PM -0700, Eric Anholt wrote:
> > db820c wants to use the qcom smmu path to get HUPCF set (which keeps
> > the GPU from wedging and then sometimes wedging the kernel after a
> > page fau
This enables the adreno-specific SMMU path that sets HUPCF so
(user-managed) page faults don't wedge the GPU.
Signed-off-by: Eric Anholt
---
We've been seeing a flaky test per day or so in Mesa CI where the
kernel gets wedged after an iommu fault turns into CP errors. With
this pat
db820c wants to use the qcom smmu path to get HUPCF set (which keeps
the GPU from wedging and then sometimes wedging the kernel after a
page fault), but it doesn't have separate pagetables support yet in
drm/msm so we can't go all the way to the TTBR1 path.
Signed-off-by: Eric Anholt
Clean up GMU OOB set/clear handling")
> > Signed-off-by: Jonathan Marek
>
> Thanks. I feel silly that I missed that.
>
> Reviewed-by: Jordan Crouse
Yeah, oops.
Reviewed-by: Eric Anholt
___
dri-devel mailing list
dri-devel@l
On Thu, Feb 4, 2021 at 10:09 AM Chema Casanova wrote:
>
> On 3/9/20 18:48, Yukimasa Sugizaki wrote:
> > From: Yukimasa Sugizaki
> >
> > The default timeout is 500 ms which is too short for some workloads
> > including Piglit. Adding this parameter will help users to run heavier
> > tasks.
> >
>
Now that the bug is fixed in the minimal way for stable, go make the
code table-driven.
Signed-off-by: Eric Anholt
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 124 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 55
2 files changed
.
Signed-off-by: Eric Anholt
Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 25 ++---
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 8
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 ++-
patch, the message seems to
have completely gone away.
Signed-off-by: Eric Anholt
Fixes: 4b565ca5a2cb ("drm/msm: Add A6XX device support")
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/msm/
Updated commit messages over v2, no code changes.
Eric Anholt (3):
drm/msm: Fix race of GPU init vs timestamp power management.
drm/msm: Fix races managing the OOB state for timestamp vs timestamps.
drm/msm: Clean up GMU OOB set/clear handling.
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 105
On Thu, Jan 28, 2021 at 10:52 AM Jordan Crouse wrote:
>
> On Wed, Jan 27, 2021 at 03:39:44PM -0800, Eric Anholt wrote:
> > We were using the same force-poweron bit in the two codepaths, so they
> > could race to have one of them lose GPU power early.
> >
> > Sign
Now that the bug is fixed in the minimal way for stable, go make the
code table-driven.
Signed-off-by: Eric Anholt
---
Previous version hadn't been rebased off of a bit of debug code I had,
so it wouldn't cleanly apply.
drivers/gpu/drm/msm/adreno/a6xx_g
Now that the bug is fixed in the minimal way for stable, go make the
code table-driven.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 124 +-
drivers/gpu/drm/msm/adreno/a6xx_gmu.h | 55
2 files changed, 77 insertions(+), 102
given that we start many tests in parallel, and waiting for NFS
to page in code probably means that lots of tests hit the same point
of screen init at the same time).
Signed-off-by: Eric Anholt
Cc: sta...@vger.kernel.org # v5.9
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4
1 file changed, 4
We were using the same force-poweron bit in the two codepaths, so they
could race to have one of them lose GPU power early.
Signed-off-by: Eric Anholt
Cc: sta...@vger.kernel.org # v5.9
---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 25 ++---
drivers/gpu/drm/msm/adreno
R to set the ID lookup from base 1. This avoids all lookups that
> otherwise starts from 0 since 0 is always unused / available.
>
> References: commit 6ce711f27500 ("idr: Make 1-based IDRs more efficient")
>
> Signed-off-by: Deepak R Varma
> ---
> Changes since v1:
&
On Thu, Nov 5, 2020 at 10:25 AM Deepak R Varma wrote:
>
> idr_init() uses base 0 which is an invalid identifier for this driver.
> The idr_alloc for this driver uses VC4_PERFMONID_MIN as start value for
> ID range and it is #defined to 1. The new function idr_init_base allows
> IDR to set the ID l
Reviewed-by: Eric Anholt
I'd be fine with retiring from being maintainer, too. I'm definitely
not active.
On Fri, Oct 9, 2020 at 12:50 AM Maxime Ripard wrote:
>
> Eric isn't working on vc4 anymore and I've been working on it, as well as
> merging patches for
On Wed, Sep 23, 2020 at 6:13 AM Dave Stevenson
wrote:
>
> Hi
>
> On Wed, 23 Sep 2020 at 08:53, Li Heng wrote:
> >
> > This addresses the following gcc warning with "make W=1":
> >
> > drivers/gpu/drm/v3d/v3d_drv.c:73:32: warning:
> > ‘v3d_v3d_pm_ops’ defined but not used [-Wunused-const-variable=
roga
> Signed-off-by: Eric Anholt
> Link:
> https://patchwork.freedesktop.org/patch/msgid/20190916071125.5255-1-ito...@igalia.com
> Fixes: a783a09ee76d ("drm/v3d: Refactor job management.")
> Reviewed-by: Eric Anholt
> Signed-off-by: Sasha Levin
You'
irq1 = platform_get_irq_optional(v3d_to_pdev(v3d), 1);
> if (irq1 == -EPROBE_DEFER)
> return irq1;
> if (irq1 > 0) {
> --
Reviewed-by: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, Jul 7, 2020 at 3:26 AM Maxime Ripard wrote:
>
> If the DSI driver is the last to probe, component_add will try to run all
> the bind callbacks straight away and return the error code.
>
> However, since we depend on a power domain, we're pretty much guaranteed to
> be in that case on the B
On Tue, Jun 30, 2020 at 1:25 AM Maxime Ripard wrote:
>
> Hi Eric,
>
> On Thu, Jun 11, 2020 at 03:36:45PM +0200, Maxime Ripard wrote:
> > Hi,
> >
> > This is another part of the rpi4 HDMI series that got promoted to a
> > series of its own to try to reduce the main one.
> >
> > This rework is neede
On Fri, Jul 3, 2020 at 6:57 AM Maxime Ripard wrote:
>
> The VC4_SET_FIELD and VC4_GET_FIELD are reimplementing most of the logic
> already defined in FIELD_SET and FIELD_GET. Let's convert the vc4 macros to
> use the FIELD_* macros.
>
> Signed-off-by: Maxime Ripard
&
We don't expect to find vbif_nrt or regdma on cheza, but were clogging
up dmesg with errors about it.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 4 ++--
drivers/gpu/drm/msm/msm_drv.c | 22 ++
drivers/gpu/drm/msm/msm_
Nothing was using the lengths of these ioremaps.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 21 -
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.h | 1 -
drivers/gpu/drm/msm/disp/dpu1/dpu_mdss.c | 9 -
3 files changed, 31 deletions(-)
diff
random.*
Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.c
b/drivers/gpu/drm/msm/
We don't want it under CONFIG_DRM_MSM_GPU_STATE, we need it all the
time (like the other GPUs do).
Fixes: ccac7ce373c1 ("drm/msm: Refactor address space initialization")
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion
On Wed, Jun 17, 2020 at 1:16 PM Eric Anholt wrote:
>
> On Thu, Apr 9, 2020 at 4:34 PM Jordan Crouse wrote:
> >
> > Refactor how address space initialization works. Instead of having the
> > address space function create the MMU object (and thus require separate but
> &
On Thu, Apr 9, 2020 at 4:34 PM Jordan Crouse wrote:
>
> Refactor how address space initialization works. Instead of having the
> address space function create the MMU object (and thus require separate but
> equal functions for gpummu and iommu) use a single function and pass the
> MMU struct in. M
On Tue, Jun 9, 2020 at 1:17 PM Linus Walleij wrote:
>
> On Tue, Jun 9, 2020 at 10:11 PM Eric Anholt wrote:
>
> > FWIW, series is Reviewed-by: Eric Anholt
>
> Thanks Eric, do I remember correct that you were using this
> driver for something like a clock display? Are
h scaling: this has been
> implemented.
>
> Cc: Russell King
> Signed-off-by: Linus Walleij
FWIW, series is Reviewed-by: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Wed, May 27, 2020 at 8:49 AM Maxime Ripard wrote:
>
> The HDMI block has a block that controls clocks and reset signals to the
> HDMI0 and HDMI1 controllers.
>
> Let's expose that through a clock driver implementing a clock and reset
> provider.
>
> Cc: Michael Turquette
> Cc: Stephen Boyd
>
On Tue, Jun 2, 2020 at 8:02 AM Dave Stevenson
wrote:
>
> Hi Maxime and Eric
>
> On Tue, 2 Jun 2020 at 15:12, Maxime Ripard wrote:
> >
> > Hi Eric
> >
> > On Wed, May 27, 2020 at 09:54:44AM -0700, Eric Anholt wrote:
> > > On Wed, May 27, 2020 at 8:50
On Tue, Jun 2, 2020 at 5:52 AM Maxime Ripard wrote:
>
> Hi Eric,
>
> On Wed, May 27, 2020 at 09:33:44AM -0700, Eric Anholt wrote:
> > On Wed, May 27, 2020 at 8:49 AM Maxime Ripard wrote:
> > >
> > > In order to prevent timeouts and stalls in the pipeline, th
On Fri, May 29, 2020 at 6:44 AM Rohan Garg wrote:
>
> Hey Eric!
>
> On jueves, 28 de mayo de 2020 20:45:24 (CEST) Eric Anholt wrote:
> > On Thu, May 28, 2020 at 10:06 AM Rohan Garg
> wrote:
> > > DRM_IOCTL_HANDLE_SET_LABEL lets you label buffers associated
> &g
On Thu, May 28, 2020 at 10:06 AM Rohan Garg wrote:
>
> DRM_IOCTL_HANDLE_SET_LABEL lets you label buffers associated
> with a handle, making it easier to debug issues in userspace
> applications.
>
> DRM_IOCTL_HANDLE_GET_LABEL lets you read the label associated
> with a buffer.
>
> Changes in v2:
>
On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote:
>
> At boot time, if we detect that a pixelvalve has been enabled, we need to
> be able to retrieve the HVS channel it has been assigned to so that we can
> disable that channel too. Let's create that function that returns the FIFO
> or an error
On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote:
>
> The BCM2711 has 5 pixelvalves, so now that our driver is ready, let's add
> support for them.
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 84 ++-
> drivers/gpu/drm/vc4/vc4_regs.
On Wed, May 27, 2020 at 8:51 AM Maxime Ripard wrote:
>
> the vc4_hdmi driver has some custom structures to hold the data it needs to
> associate with the drm_encoder and drm_connector structures.
>
> However, it allocates them separately from the vc4_hdmi structure which
> makes it more complicate
On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote:
>
> Signed-off-by: Maxime Ripard
> ---
> drivers/gpu/drm/vc4/vc4_crtc.c | 272 +---
> drivers/gpu/drm/vc4/vc4_drv.h | 5 +-
> drivers/gpu/drm/vc4/vc4_hvs.c | 298 ++-
> 3 files ch
On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote:
>
> The driver resets the pixelvalve FIFO in a number of occurences without
> always using the same sequence.
>
> Since this will be critical for BCM2711, let's move that sequence to a
> function so that we are consistent.
>
> Signed-off-by: Max
On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote:
>
> The HVS found in the BCM2711 has 6 outputs and 3 FIFOs, with each output
> being connected to a pixelvalve, and some muxing between the FIFOs and
> outputs.
>
> Any output cannot feed from any FIFO though, and they all have a bunch of
> cons
On Wed, May 27, 2020 at 8:50 AM Maxime Ripard wrote:
>
> The VIDEN bit in the pixelvalve currently being used to enable or disable
> the pixelvalve seems to not be enough in some situations, which whill end
> up with the pixelvalve stalling.
>
> In such a case, even re-enabling VIDEN doesn't bring
On Wed, May 27, 2020 at 8:49 AM Maxime Ripard wrote:
>
> Now that we have everything in place, we can now register all the overlay
> planes that can be assigned to all the CRTCs.
>
> This has two side effects:
>
> - The number of overlay planes is reduced from 24 to 8. This is temporary
> an
On Wed, May 27, 2020 at 8:49 AM Maxime Ripard wrote:
>
> From: Dave Stevenson
>
> LBM allocations were always taking the worst case sizing of
> max(src_width, dst_width) * 16. This is significantly over
> the required sizing, and stops us rendering multiple 4k images
> to the screen.
>
> Add some
On Wed, May 27, 2020 at 8:49 AM Maxime Ripard wrote:
>
> In order to prevent timeouts and stalls in the pipeline, the core clock
> needs to be maxed at 500MHz during a modeset on the BCM2711.
Like, the whole system's core clock? How is it reasonable for some
device driver to crank the system's c
device
> *pdev)
> }
>
> static const struct of_device_id vc4_of_match[] = {
> + { .compatible = "brcm,bcm2711-vc5", },
> { .compatible = "brcm,bcm2835-vc4", },
> { .compatible = "brcm,cygnus-vc4", },
> {},
Patch 6
always, hides references to the
> nents and orig_nents entries, making the code robust, easier to follow
> and copy/paste safe.
>
> Signed-off-by: Marek Szyprowski
Reviewed-by: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
ck for the suspend state and blindly call into the devfreq
> callbacks that end up triggering hardware reads in the GPU driver.
>
> Call pm_runtime_get_if_in_use() in the gpu_busy() and gpu_set_freq()
> callbacks to skip the hardware access if it isn't active.
>
>
On Fri, May 1, 2020 at 11:26 AM Jordan Crouse wrote:
>
> Writing to the devfreq sysfs nodes while the GPU is powered down can
> result in a system crash (on a5xx) or a nasty GMU error (on a6xx):
>
> $ /sys/class/devfreq/500.gpu# echo 5 > min_freq
> [ 104.841625] platform 506a000.gm
On Thu, Apr 30, 2020 at 3:44 AM Daniel Vetter wrote:
>
> On Tue, Apr 28, 2020 at 2:46 PM Peter Collingbourne wrote:
> >
> > Render nodes are not just useful for devices supporting GPU hardware
> > acceleration. Even on devices that only support dumb frame buffers,
> > they are useful in situation
On Mon, Apr 27, 2020 at 1:05 PM Peter Collingbourne wrote:
>
> Render nodes are not just useful for devices supporting GPU hardware
> acceleration. Even on devices that only support dumb frame buffers,
> they are useful in situations where composition (using software
> rasterization) and KMS are d
On Mon, Apr 27, 2020 at 7:45 AM Emil Velikov wrote:
>
> On Fri, 24 Apr 2020 at 19:54, Peter Collingbourne wrote:
> >
> > On Fri, Apr 24, 2020 at 4:11 AM Emil Velikov
> > wrote:
> > >
> > > On Thu, 23 Apr 2020 at 23:51, Peter Collingbourne wrote:
> > > >
> > > > The render node is required by A
On Thu, Apr 23, 2020 at 3:35 PM Peter Collingbourne wrote:
>
> The render node is required by Android which does not support the legacy
> drmAuth authentication process.
There's no rendering engine on pl111, so only the control node makes
sense for this HW since all this driver does is display.
"Noralf Trønnes"
> Cc: Sam Ravnborg
Acked-by: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Fri, Apr 3, 2020 at 6:58 AM Daniel Vetter wrote:
>
> And switch the helper over to container_of, which is a bunch faster
> than chasing a pointer. Plus allows gcc to see through this maze.
>
> Signed-off-by: Daniel Vetter
Acked-
On Fri, Apr 3, 2020 at 6:58 AM Daniel Vetter wrote:
>
> Also allows us to simplify the unroll code since the drm_dev_put
> disappears.
>
> Signed-off-by: Daniel Vetter
Acked-by: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.
On Fri, Apr 3, 2020 at 6:59 AM Daniel Vetter wrote:
>
> Already using devm_drm_dev_init, so very simple replacment.
>
> Signed-off-by: Daniel Vetter
Acked-by: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.freedeskt
bikeshed, so feel free to ignore.
>
> Signed-off-by: Daniel Vetter
> Cc: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
gt; different objects if there's multiple
> - compilers have an easier time too
>
> But also a bit a bikeshed, so feel free to ignore.
>
> Signed-off-by: Daniel Vetter
> Cc: Eric Anholt
a-b.
___
dri-devel mailing list
dri-devel@li
On Thu, Mar 5, 2020 at 8:00 AM Thomas Zimmermann wrote:
>
> The vc4 driver uses empty implementations for its encoders. Replace
> the code with the generic simple encoder.
Acked-by: Eric Anholt
___
dri-devel mailing list
On Wed, Dec 18, 2019 at 6:39 AM Nicolas Saenz Julienne
wrote:
>
> Hi Peter,
>
> On Wed, 2019-12-18 at 08:43 +, Peter Robinson wrote:
> > On arm64 the config ARCH_BCM doesn't exist so to be able to
> > build for platforms such as the Raspberry Pi 4 we need to add
> > ARCH_BCM2835 similar to wha
On Thu, Feb 20, 2020 at 1:44 AM James Hughes
wrote:
>
> On Wed, 19 Feb 2020 at 22:51, Eric Anholt wrote:
> >
> > On Mon, Feb 17, 2020 at 7:41 AM James Hughes
> > wrote:
> > >
> > > The wait_for macro's for Broadcom VC4 and V3D drivers used
On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote:
>
> On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote:
> >
> > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote:
> > > b) we probably need to take a large step back here.
> > >
> > > Look at this from a sponsor POV, why would I give X.org/fd.o
>
On Mon, Feb 17, 2020 at 7:41 AM James Hughes
wrote:
>
> The wait_for macro's for Broadcom VC4 and V3D drivers used msleep
> which is inappropriate due to its inaccuracy at low values (minimum
> wait time is about 30ms on the Raspberry Pi).
>
> This patch replaces the macro with the one from the In
On Tue, Feb 18, 2020 at 9:28 AM Wambui Karuga wrote:
>
> As drm_debugfs_create_files should return void, remove its use as the
> return value of v3d_debugfs_init and have the function return 0
> directly.
If we're going this route, then this function should be returning void, too.
>
> Signed-off
r the setup to fix this issue.
>
> After a bit more prep in drivers and drm core v3d should be able to
> switch over to devm_drm_dev_init, which should clean this up further.
>
> Signed-off-by: Daniel Vetter
> Cc: Eric Anholt
Acked-by: Eric Anholt
_
ch the default table entries but not
> conflict with any possible real bin values. Also fix a small memory leak
> and free the buffer allocated by nvmem_cell_read().
>
> Signed-off-by: Jordan Crouse
This does fix my warn at boot on db820c.
Reviewed-by: Eric Anholt
_
.. */
> > - ret =
> > ww_mutex_lock_slow_interruptible(&msm_obj->base.resv->lock,
> > - &submit->ticket);
> > + ret = dma_resv_lock_slow_interruptible(msm_obj->base.resv,
> > +&submit->ticket);
> > if (!ret) {
> > submit->bos[contended].flags |= BO_LOCKED;
> > slow_locked = contended;
> > --
> > 2.24.0
> >
Reviewed-by: Eric Anholt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
> if (contended_lock != -1 && contended_lock >= i) {
> > bo = &exec->bo[contended_lock]->base;
> >
> > - ww_mutex_unlock(&bo->resv->lock);
> > + dma_resv_unlock(bo->resv);
> > }
> >
> > if (ret == -EDEADLK) {
> > --
> > 2.24.0
> >
Assuming they're supposed to be exactly equivalent currently,
Acked-by: Eric Anholt
but we should really just be using drm_gem_lock_reservations()
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reviewed-by: Rob Clark
Seems like a reasonable workaround to me, and permissible by our fourcc
modifier rules ("you just have to have one way to address the pixels
given a fourcc and a modifier").
Reviewed-by: Eric Anholt
signature.asc
Description: PGP signature
_
hader images, scratch, etc) which sometimes
> also lead to GPU resets during Piglit and CTS workloads.
>
> v2: if v3d_job_init() fails we need to kfree() the job instead of
> v3d_job_put() it (Eric Anholt).
>
> v3 (Eric Anholt):
> - Drop _FLAG suffix from the new flag name.
&
ndroid O cannot be expressed in
> Andorid.mk files.
>
> Patch originally by Dan Willemsen with fixes folded in by:
> Jerry Zhang, Eliott Hughes and myself.
>
> With this change, the only patches carried by Android for libdrm
> would be the gerrit OWNERS meta-data file.
Acked-by: E
Iago Toral Quiroga writes:
> If the initialization of the job fails we need to kfree() it
> before returning.
>
> Signed-off-by: Iago Toral Quiroga
Applied to drm-misc-next with a fixes tag for the commit that introduced
the bug. Thanks!
signature.asc
Description: PGP signature
_
hader images, scratch, etc) which sometimes
> also lead to GPU resets during Piglit and CTS workloads.
>
> v2: if v3d_job_init() fails we need to kfree() the job instead of
> v3d_job_put() it (Eric Anholt).
>
> Signed-off-by: Iago Toral Quiroga
> Reviewed-
Iago Toral writes:
> On Thu, 2019-09-12 at 10:25 -0700, Eric Anholt wrote:
>> Iago Toral Quiroga writes:
>>
>> > Extends the user space ioctl for CL submissions so it can include a
>> > request
>> > to flush the cache once the CL execution has complet
Rohan Garg writes:
> [ Unknown signature status ]
> Hi
> I'm investigating a way to label BO's in panfrost, similar to how VC4 does it
> and realised that this could be something that's might be useful to all
> drivers.
>
> With that in mind, would anyone be opposed to add a DRM_IOCTL_BO_SET_LA
+ ret = v3d_job_init(v3d, file_priv, clean_job, v3d_job_free, 0);
> + if (ret)
> + goto fail;
Only issue I see: If v3d_job_init() fails, we need to not v3d_job_put()
it. I'm fine with either kfree() it and NULL the ptr before jumping to
fa
er to using the PM driver
> instead of firmware.")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Stefan Wahren
Acked-by: Eric Anholt
I wish someone with firmware source had the time to look into why using
open source drivers to drive this hardware was failing, but I don&#x
Hans Verkuil writes:
> From: Dariusz Marcinkiewicz
>
> Fill in the connector info, allowing userspace to associate
> the CEC device with the drm connector.
Acked-by: Eric Anholt
signature.asc
Description: PGP signature
___
dri-devel
ges if the pages array is populated.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Eric Anholt
> Reviewed-by: Steven Price
> Acked-by: Alyssa Rosenzweig
> Signed-off-by: Rob Herring
Patch 1, 2:
R
Boris Brezillon writes:
> Now that we have an official way to request custom encoder/bridge
> enable/disable sequences we can get rid of the extra ->bridge field
> and use the encoder one.
Patch 2, 3 are:
Reviewed-by: Eric Anholt
signature.asc
Description: P
/notro/linux/tree/move_mipi_dbi
Congratulations on making it to this stage. This looks like a fine
conclusion to tinydrm.
Acked-by: Eric Anholt
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Rob Clark writes:
> From: Rob Clark
>
> Since there is no real device associated with VGEM, it is impossible to
> end up with appropriate dev->dma_ops, meaning that we have no way to
> invalidate the shmem pages allocated by VGEM. So, at least on platforms
> without drm_cflush_pages(), we end u
Rob Clark writes:
> From: Rob Clark
>
> The driver should be in control of this.
>
> Signed-off-by: Rob Clark
> ---
> It is possible that this was masking bugs (ie. not setting appropriate
> pgprot) in drivers. I don't have a particularly good idea for tracking
> those down (since I don't have
Sam Ravnborg writes:
> This patch set removes a far share of the remaining uses of drmP.h.
> Common for all patches are that the respective files are maintained
> in drm-misc.
> All patches are independent.
For v3d, vc4, pl111:
Reviewed-by: Eric Anholt
signature.asc
Desc
Nishka Dasgupta writes:
> Each iteration of for_each_available_child_of_node puts the previous
> node, but in the case of a break from the middle of the loop there is
> no put, thus causing a memory leak. Hence add an of_node_put before the
> break.
> Issue found with Coccinelle.
Pushed. Thanks
Rob Clark writes:
> From: Rob Clark
>
> The goal here is to support inheriting a display setup by bootloader,
> although there may also be some non-display related use-cases.
>
> Rough idea is to add a flag for clks and power domains that might
> already be enabled when kernel starts, and which
uffers. Which means
> we don't need to check to check the dma-buf in the prepare_fb helper,
> but can generalize them so they're also useful for display+render
> drivers which use gem_bo.resv to track their own rendering for their
> own scanout buffers.
1-3 are:
Reviewed-by: Eri
Maxime Ripard writes:
> Now that the TV margins are properly parsed and filled into
> drm_cmdline_mode, we just need to initialise the first state at reset to
> get those values and start using them.
>
> Reviewed-by: Noralf Trønnes
> Signed-off-by: Maxime Ripard
Ack
Greg Kroah-Hartman writes:
> When calling debugfs functions, there is no need to ever check the
> return value. The function can work or not, but the code logic should
> never do something different based on this.
Applied to drm-misc-next. Thanks!
signature.asc
Description: PGP signature
___
great cleanup. I took a look at a lot of it.
Patch 1-2, 4-10, 41-47, 49-50, and all the gem_prime_import/export drop
patches are:
Reviewed-by: Eric Anholt
I don't currently have a plan for reading the shuffle in patch 3.
signature.asc
Description: PGP signature
__
Daniel Vetter writes:
> On Fri, May 31, 2019 at 08:46:58AM -0700, Eric Anholt wrote:
>> Boris Brezillon writes:
>>
>> > Right now, the BO is mapped as a cached region when ->vmap() is called
>> > and the underlying object is not a dmabuf.
>> >
in memory and the CPU reads them back in
> kernel-space. This patch seems to solve the unpredictable behavior I
> had.
>
> I can also go for the other option (call dma_map/unmap/_sg() when
> needed) if you think that's more appropriate.
writecombined was the intent, and this makes
Daniel Vetter writes:
> On Wed, Apr 24, 2019 at 03:06:38PM -0700, Eric Anholt wrote:
>> I was trying to figure out if it was permissible to merge the Mesa
>> side of V3D's CSD support yet while it's in drm-misc-next but not
>> drm-next, and developers on #dri-deve
Eric Anholt writes:
> [ Unknown signature status ]
> James Clarke writes:
>
>> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
>> types, which differs from the BSDs' headers. Thus we should include
>> stdint.h to ensure we have all the
Paul Kocialkowski writes:
> Changes sinve v8:
> * Added collected Reviewed-by;
> * Fixed up another problematic case as discussed on v8.
I think this is ready to go. Thanks!
signature.asc
Description: PGP signature
ck wants to be:
if (vc4->bin_bo)
kref_get(&vc4->bin_bo_kref);
else
ret = bin_bo_alloc(vc4);
if (ret == 0 && used)
*used = true;
(so we don't flag used if bin_bo_alloc fails)
If you agree, then the s
James Clarke writes:
> Like GNU/Linux, GNU/kFreeBSD's sys/types.h does not define the uintX_t
> types, which differs from the BSDs' headers. Thus we should include
> stdint.h to ensure we have all the required integer types.
>
> Signed-off-by: James Clarke
1 - 100 of 1429 matches
Mail list logo
