||.org
Version|unspecified |11.2
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160
receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/415966ff/attachment.html>
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/b368845c/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/bc0d55f2/attachment.html>
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/3db212c5/attachment.html>
On 19 July 2016 at 19:30, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix the reset_control_deassert() fail and clk_prepare_enable() fail
> error handling of ade_power_up().
>
> Signed-off-by: Wei Yongjun
Applied, thanks.
-xinliang
> ---
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c | 10
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/a26b42da/attachment.html>
assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/46714014/attachment-0001.html>
is mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/14b58424/attachment.html>
ut if that would be sufficient?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/16658934/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/4bfb3d60/attachment.html>
e bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/d8c7307f/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/d8db64cf/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/9eab7019/attachment.html>
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/cf5babd6/attachment-0001.html>
vel/attachments/20160726/c963136d/attachment.html>
..
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/9e344725/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/6f250302/attachment.html>
issue goes away
:)
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/70bd59f7/attachment.html>
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/64bcfcbb/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/6f764d51/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=141741
--- Comment #10 from Michael Schenaerts ---
I'll be glad to help but I don't know where to start.
Do you have some documentation ?
Thanks
Michaël
--
You are receiving this mail because:
You are watching the assignee of the bug.
art --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/30b4b46d/attachment.html>
What is share plane:
Plane hardware only be used when the display scanout run into plane active
scanout, that means we can reuse the plane hardware resources on plane
non-active scanout.
--
| scanout |
Change-Id: Iac8fde019020d8f1a671d52c1a4d91ad2d050d43
Signed-off-by: Mark Yao
---
drivers/gpu/drm/rockchip/rockchip_vop_reg.c | 52 -
1 file changed, 44 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/rockchip_vop_reg.c
b/drivers/gpu/drm/rockchip/r
The series vop of VOP_FULL framework support area plane, such as
RK3288 and RK3399, one group of area planes share same hardware,
reuse the hardware on different scanout time, this design is
useful to support mulit planes with low hardware consume.
Signed-off-by: Mark Yao
---
drivers/gpu/drm/roc
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/71d48b88/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/9e0ace1b/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/36349de0/attachment.html>
On Tue, Jul 26, 2016 at 03:46:32PM +0800, Mark Yao wrote:
> What is share plane:
> Plane hardware only be used when the display scanout run into plane active
> scanout, that means we can reuse the plane hardware resources on plane
> non-active scanout.
>
>
s is a bit off topic, I'm sure that your customers'
customers would be very happy to get all the security and bug fixes that
would automatically be delivered with the frequent kernel updates that
bring in support for new panels.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/b075159b/attachment-0001.sig>
Hi Joonas,
On Mon, Jul 25, 2016 at 10:00:25AM +0300, Joonas Lahtinen wrote:
> Only property creation uses the rotation as an index, so convert the
> #define to the more used BIT(DRM_ROTATE_?) form and use __builtin_ffs
> to figure the index when needed.
>
> Cc: intel-gfx at lists.freedesktop.org
On 2016å¹´07æ26æ¥ 16:26, Daniel Vetter wrote:
> On Tue, Jul 26, 2016 at 03:46:32PM +0800, Mark Yao wrote:
>> >What is share plane:
>> >Plane hardware only be used when the display scanout run into plane active
>> >scanout, that means we can reuse the plane hardware resources on plane
>> >non-act
Hi Steve,
Am Dienstag, den 19.07.2016, 18:10 -0700 schrieb Steve Longerbeam:
> These updates to IPUv3 are needed for media staging drivers
> for i.MX5/6 video capture and mem2mem.
>
> Steve Longerbeam (13):
> gpu: ipu-cpmem: Add ipu_cpmem_set_uv_offset()
> gpu: ipu-cpmem: Add ipu_cpmem_get_bu
Am Dienstag, den 19.07.2016, 18:10 -0700 schrieb Steve Longerbeam:
> Adds the Video Deinterlacer (VDIC) unit.
>
> Signed-off-by: Steve Longerbeam
[...]
> +++ b/drivers/gpu/ipu-v3/ipu-vdi.c
[...]
> +static void __ipu_vdi_set_top_field_man(struct ipu_vdi *vdi, bool
> top_field_0)
> +{
> + u32
Am Dienstag, den 19.07.2016, 18:11 -0700 schrieb Steve Longerbeam:
> Adds functions to link and unlink IDMAC source channels to sink
> channels.
>
> So far the following links are supported:
>
> IPUV3_CHANNEL_IC_PRP_ENC_MEM -> IPUV3_CHANNEL_MEM_ROT_ENC
> PUV3_CHANNEL_IC_PRP_VF_MEM -> IPUV3_CHAN
Am Dienstag, den 19.07.2016, 18:11 -0700 schrieb Steve Longerbeam:
> This patch implements complete image conversion support to ipu-ic,
> with tiling to support scaling to and from images up to 4096x4096.
> Image rotation is also supported.
>
> The internal API is subsystem agnostic (no V4L2 depen
This patch adds the remaining missing IDMAC channel names: VDIC channels
for combining, the separate alpha channels for the MEM->IC and MEM->DC
ASYNC channels, and the DC read, command, and output mask channels.
Signed-off-by: Philipp Zabel
---
include/video/imx-ipu-v3.h | 12
1 fil
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/0f1aa17c/attachment.html>
se:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/680317b8/attachment.html>
is mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/2112feea/attachment.html>
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/f1d20693/attachment.html>
On ti, 2016-07-26 at 10:05 +0100, Liviu Dudau wrote:
> > --- a/drivers/gpu/drm/arm/malidp_planes.c
> > +++ b/drivers/gpu/drm/arm/malidp_planes.c
> > @@ -108,7 +108,7 @@ static int malidp_de_plane_check(struct drm_plane
> > *plane,
> > Â return -EINVAL;
> > Â
> > Â /* packed RGB888 / B
On Mon, Jul 25, 2016 at 10:00:25AM +0300, Joonas Lahtinen wrote:
> Only property creation uses the rotation as an index, so convert the
> #define to the more used BIT(DRM_ROTATE_?) form and use __builtin_ffs
> to figure the index when needed.
>
> Cc: intel-gfx at lists.freedesktop.org
> Cc: linux-
Op 21-07-16 om 21:23 schreef Lyude:
> From: Matt Roper
>
> When we write watermark values to the hardware, those values are stored
> in dev_priv->wm.skl_hw. However with recent watermark changes, the
> results structure we're copying from only contains valid watermark and
> DDB values for the pip
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/cac89d96/attachment.html>
On Mon, Jul 25, 2016 at 6:40 AM, Lee Jones wrote:
> On Mon, 25 Jul 2016, Peter Griffin wrote:
>> On Mon, 25 Jul 2016, Lee Jones wrote:
>>
>> > Since 0b52297f228 ("reset: Add support for shared reset controls") the
>> > new Reset API now demands consumers choose either an *_exclusive or a
>> > *_sh
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/682e5862/attachment.html>
On Mon, Jul 25, 2016 at 3:00 AM, Joonas Lahtinen
wrote:
> Only property creation uses the rotation as an index, so convert the
> #define to the more used BIT(DRM_ROTATE_?) form and use __builtin_ffs
> to figure the index when needed.
>
> Cc: intel-gfx at lists.freedesktop.org
> Cc: linux-arm-msm a
So unfortunately, this patch series fixes most of the underruns on Skylake, but
not all of them. Even with this patchset we're still apt to potentially hitting
underruns since we don't update the ddb allocations atomically as well yet. I'm
planning to do this eventually when I get the chance, but f
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
o
Manual pipe flushes are only necessary in order to make sure that we prevent
pipes with changed ddb allocations from overlapping from one another at
any point in time. Additionally, forcing us to wait for the next vblank
every time we have to update the watermark values because the cursor was
movin
Similar to how a vehicle will travel faster if you paint flames on it,
cleaning up this extra whitespace is guaranteed to provide additional
stability while updating watermark values.
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_pm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/driv
Unfortunately right now we don't really update watermarks on Skylake
properly, since ideally we'd be updating both the ddb allocations, plane
properties, and watermarks all in a single go. Until this is fixed
however, we can improve things somewhat by adding a vblank wait after
the third iteration
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"ar
Op 26-07-16 om 16:50 schreef Lyude:
> Since the watermark calculations for Skylake are still broken, we're apt
> to hitting underruns very easily under multi-monitor configurations.
> While it would be lovely if this was fixed, it's not. Another problem
> that's been coming from this however, is th
On Tue, Jul 26, 2016 at 04:58:58PM +0200, Maarten Lankhorst wrote:
> Op 26-07-16 om 16:50 schreef Lyude:
> > Since the watermark calculations for Skylake are still broken, we're apt
> > to hitting underruns very easily under multi-monitor configurations.
> > While it would be lovely if this was fix
was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/e25d58d2/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=141741
Vedran MiletiÄ changed:
What|Removed |Added
CC||vedran at miletic.net
--- Comment #11
From: Ville Syrjälä
Replace the use of drm_plane_helper_check_update() with
drm_plane_helper_check_state() since we have a plane state.
Rockchip looks to handling plane clipping rather well already
(unlikje most arm drm drivers) so there are no function changes
here.
Cc: Yao
Cc: linux-rockch
From: Ville Syrjälä
Replace the use of drm_plane_helper_check_update() with
drm_plane_helper_check_state() since we have a plane state.
This also eliminates the double clipping the driver was doing
in both check and commit phases). And it should fix src coordinate
addr adjustement. Previously
From: Ville Syrjälä
Pretty much all driver will have need for the clipped plane
coordinates, so let's stuff then into drm_plane_state.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_crtc.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/drm/drm_crtc.h b/include
From: Ville Syrjälä
Add a version of drm_plane_helper_check_update() which takes a plane
state instead of having the caller pass in everything.
And to reduce code duplication, let's reimplement
drm_plane_helper_check_update() in terms of the new function, by
having a tempororary plane state on
From: Ville Syrjälä
Replace the private drm_rects in vop_plane_state with
the ones now living in drm_plane_state.
Cc: Yao
Cc: linux-rockchip at lists.infradead.org
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 10 --
1 file changed, 4 insertions(+)
From: Ville Syrjälä
Passing negative width/hight to scale factor calculations is not
legal. Let's WARN if that happens.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_rect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/d
From: Ville Syrjälä
Moving the clipped plane coordinates into drm_plane_state has been
discussed a few times, but as no patches seems to have materialized,
I decoded to do it myself. I also added a new helper function
like drm_plane_helper_check_update() that takes a plane state instead.
I con
From: Ville Syrjälä
Replace the use of drm_plane_helper_check_update() with
drm_plane_helper_check_state() since we have a plane state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 14 --
drivers/gpu/drm/i915/intel_display.c | 26 +--
From: Ville Syrjälä
Replace the private drm_rects/flags in intel_plane_state
with the ones now living in drm_plane_state.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 20 ++---
drivers/gpu/drm/i915/intel_display.c | 132 +++---
From: Ville Syrjälä
Replace the use of drm_plane_helper_check_update() with
drm_plane_helper_check_state() since we have a plane state.
I don't see any actual users of drm_simple_kms_helper yet, so
no actual plane clipping bugs to fix.
Cc: Noralf Trønnes
Signed-off-by: Ville Syrjälä
---
The CRTC's port pointer was being set to the endpoint node instead of
the port. Fix that, and hold a reference on the port node.
Signed-off-by: Brian Starkey
Acked-by: Liviu Dudau
---
drivers/gpu/drm/arm/malidp_drv.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff -
On Tue, Jul 26, 2016 at 07:06:59PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Replace the private drm_rects/flags in intel_plane_state
> with the ones now living in drm_plane_state.
>
> Signed-off-by: Ville Syrjälä
Didn't spot any mistakes creeping in, and as
On Tue, Jul 26, 2016 at 07:06:56PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Passing negative width/hight to scale factor calculations is not
> legal. Let's WARN if that happens.
Does this get called with user controllable inputs? A quick grep leads
me to drm_pr
On Thu, Jul 21, 2016 at 10:52:00AM +0200, Benjamin Gaignard wrote:
> From: Marek Szyprowski
>
> version 6:
> - add zpos in gpu documentation file
> - merge Ville patch about zpos initial value and API improvement.
> I have split Ville patch between zpos core and drivers
>
> version 5:
> - remo
On Tue, Jul 26, 2016 at 07:06:58PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Add a version of drm_plane_helper_check_update() which takes a plane
> state instead of having the caller pass in everything.
>
> And to reduce code duplication, let's reimplement
> drm
On Tue, Jul 26, 2016 at 05:24:42PM +0100, Chris Wilson wrote:
> On Tue, Jul 26, 2016 at 07:06:56PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > Passing negative width/hight to scale factor calculations is not
> > legal. Let's WARN if that happens.
>
> Does
On Tue, Jul 26, 2016 at 05:33:29PM +0100, Chris Wilson wrote:
> On Tue, Jul 26, 2016 at 07:06:58PM +0300, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > Add a version of drm_plane_helper_check_update() which takes a plane
> > state instead of having the caller pass i
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/2afd0b8d/attachment-0001.html>
Latest version of https://lkml.org/lkml/2016/7/26/290 . Resending the whole
thing to keep it in one place.
Lyude (5):
drm/i915/skl: Add support for the SAGV, fix underrun hangs
drm/i915/skl: Only flush pipes when we change the ddb allocation
drm/i915/skl: Fix extra whitespace in skl_flush_wm
Since the watermark calculations for Skylake are still broken, we're apt
to hitting underruns very easily under multi-monitor configurations.
While it would be lovely if this was fixed, it's not. Another problem
that's been coming from this however, is the mysterious issue of
underruns causing full
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
o
Similar to how a vehicle will travel faster if you paint flames on it,
cleaning up this extra whitespace is guaranteed to provide additional
stability while updating watermark values.
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/intel_pm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/driv
Manual pipe flushes are only necessary in order to make sure that we prevent
pipes with changed ddb allocations from overlapping from one another at
any point in time. Additionally, forcing us to wait for the next vblank
every time we have to update the watermark values because the cursor was
movin
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"ar
Unfortunately right now we don't really update watermarks on Skylake
properly, since ideally we'd be updating both the ddb allocations, plane
properties, and watermarks all in a single go. Until this is fixed
however, we can improve things somewhat by adding a vblank wait after
the third iteration
From: Ville Syrjälä
Add a version of drm_plane_helper_check_update() which takes a plane
state instead of having the caller pass in everything.
And to reduce code duplication, let's reimplement
drm_plane_helper_check_update() in terms of the new function, by
having a tempororary plane state on
|REOPENED
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/8347851d/attachment.html>
On Tue, Jul 26, 2016 at 12:15 PM, Brian Starkey
wrote:
> The CRTC's port pointer was being set to the endpoint node instead of
> the port. Fix that, and hold a reference on the port node.
>
> Signed-off-by: Brian Starkey
> Acked-by: Liviu Dudau
Applied to drm-misc
> ---
> drivers/gpu/drm/arm
directly after a DP disconnect, but just at
some random point.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/b94af2d4/attachment.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160726/c49c600b/attachment-0001.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160726/bcdfadc6/attachment.html>
nts/20160726/ba6caa0f/attachment.html>
is, the game is invoking undefined behaviour,
hence this is not our bug.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments
Here are a bunch of miscellaneous fixes for 3D I've come up with while
doing a bunch of piglit runs. One has a new IGT test sent out, and
I've got a test almost ready for large CLs.
Eric Anholt (6):
drm/vc4: Use drm_free_large() on handles to match its allocation.
drm/vc4: Use drm_malloc_ab t
If the device was already up, a 1 is returned instead of 0. We were
erroring out, leading the 3D driver to sometimes fail at screen
initialization (generally with ENOENT returned to it).
Signed-off-by: Eric Anholt
Fixes: af713795c59f ("drm/vc4: Add a getparam ioctl for getting the V3D
identity
The BO cache will complain if BOs are still allocated when we try to
destroy it (since freeing those BOs would try to hit the cache). You
could hit this if you were to unload the module after a GPU hang.
Signed-off-by: Eric Anholt
Fixes: 214613656b51 ("drm/vc4: Add an interface for capturing the
If you managed to exceed the limit to switch to vmalloc, we'd use the
wrong free.
Signed-off-by: Eric Anholt
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
We'd end up NULL pointer dereferencing because we didn't take the
error path out in the parent. Fixes igt vc4_lookup_fail test.
Signed-off-by: Eric Anholt
Fixes: d5b1a78a772f ("drm/vc4: Add support for drawing 3D frames.")
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/vc4/vc4_gem.c | 2 +-
Overflow memory handling is tricky: While it's still referenced by the
BPO registers, we want to keep it from being freed. When we are
putting a new set of overflow memory in the registers, we need to
assign the old one to the last rendering job using it.
We were looking at "what's currently runn
If you exceeded the size that kmalloc would return, you'd get a dmesg
warning and an error from the job submit. We can handle much larger
allocations with vmalloc, and drm_malloc_ab makes that decision.
Fixes failure in piglit's scissor-many.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/
1 - 100 of 109 matches
Mail list logo
