On Wed, 10 Nov 2021 at 20:50, Sultan Alsawaf wrote:
>
> On Wed, Nov 10, 2021 at 10:00:35AM +0100, Vincent Guittot wrote:
> > Is it the same SCHED_WARN_ON(rq->tmp_alone_branch !=
> > >leaf_cfs_rq_list); that generates the deadlock on v5.15 too ?
> >
> > one remaining tmp_alone_branch warning has
On Wed, 10 Nov 2021, Rob Herring wrote:
> On Wed, 10 Nov 2021 16:01:41 +0100, patrice.chot...@foss.st.com wrote:
> > From: Patrice Chotard
> >
> > Benjamin has left the company, remove his name from maintainers.
> >
> > Signed-off-by: Patrice Chotard
> > ---
> >
It's possible that i915 might get wedged between a boost
and un-boost. Validate the i915-GuC connection before trying
to send a H2G to change the min frequency.
Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/4464
Cc: Ashutosh Dixit
Signed-off-by: Vinay Belgaumkar
---
On Fri, Nov 12, 2021 at 5:40 AM Tim Harvey wrote:
>
> On Thu, Nov 11, 2021 at 2:15 AM Jagan Teki wrote:
> >
> > This series support MIPI DSI on i.MX8MM.
> >
> > The DSIM bridge still need to work to make it compatible for
> > exynos drm dsi hardware block.
> >
> > This series work directly on to
Replace atomic version of the enable/disable operations to
continue the transition to the atomic API.
Also added default drm atomic operations for duplicate, destroy
and reset state API's in order to have smooth transition on
atomic API's.
Tested on Engicam i.Core STM32MP1 SoM.
Signed-off-by:
From: Ye Guojin
This was found by coccicheck:
./drivers/gpu/drm/amd/display/dc/core/dc_resource.c, 2516, 7-9, WARNING
possible condition with no effect (if == else)
hdmi_info.bits.YQ0_YQ1 is always YYC_QUANTIZATION_LIMITED_RANGE.
Reported-by: Zeal Robot
Signed-off-by: Ye Guojin
---
https://bugzilla.kernel.org/show_bug.cgi?id=205089
--- Comment #23 from Joey Espinosa (jlouis.espin...@gmail.com) ---
... and I guess some of this info:
Mesa: 21.2.5
DE: Gnome 41.1
Vulkan: 1.2.189
Xorg: 1.20.11
--
You may reply to this email to add a comment.
You are receiving this mail
https://bugzilla.kernel.org/show_bug.cgi?id=214991
Bug ID: 214991
Summary: VC4 DRM waiting for flip down makes UI freeze a while
with kernel 5.15
Product: Drivers
Version: 2.5
Kernel Version: 5.15
Hardware: ARM
Hi Linus,
I missed a drm-misc-next pull for the main pull last week. It wasn't
that major and isn't the bulk of this at all. This has a bunch of
fixes all over, a lot for amdgpu and i915.
This contains a backmerge of 5.15 as we had a bunch of fixes queued up
in the past couple of days that were
From: chiminghao
Fix the following coccicheck REVIEW:
./drivers/gpu/drm/tegra/dpaux.c:282:13-16 REVIEW Unneeded variable
Reported-by: Zeal Robot
Signed-off-by: chiminghao
---
drivers/gpu/drm/tegra/dpaux.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git
Irrespective of the backend for request submissions, busyness for an
engine with an active context is calculated using:
busyness = total + (current_time - context_switch_in_time)
In execlists mode of operation, the context switch events are handled
by the CPU. Context switch in/out time and
From: chiminghao
Fix the following coccicheck REVIEW:
./fs/btrfs/extent_map.c:299:5-8 REVIEW Unneeded variable
Reported-by: Zeal Robot
Signed-off-by: chiminghao
---
fs/btrfs/extent_map.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/fs/btrfs/extent_map.c
[AMD Official Use Only]
Hi Harry.
> -Original Message-
> From: Wentland, Harry
> Sent: Wednesday, November 10, 2021 11:32 PM
> To: Yuan, Perry ; Jani Nikula
> ; Maarten Lankhorst
> ; Maxime Ripard ;
> Thomas Zimmermann ; David Airlie ;
> Daniel Vetter
> Cc: Huang, Shimmer ; Huang, Ray
Hi Markus,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on robh/for-next]
[also build test ERROR on pza/reset/next linus/master v5.15 next-2021]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On 11/11/21 11:18 PM, Tvrtko Ursulin wrote:
On 10/11/2021 14:37, Robin Murphy wrote:
On 2021-11-10 14:11, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 11/11/21 11:06 PM, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi Tvrtko,
On 2021/11/9 20:17, Tvrtko Ursulin
On Thu, Nov 11, 2021 at 2:15 AM Jagan Teki wrote:
>
> Add eLCDIF controller node for i.MX8MM.
>
Jagan,
It doesn't look like you sent this to the Device Tree mainling list so
I added that to cc.
> Signed-off-by: Jagan Teki
> ---
> arch/arm64/boot/dts/freescale/imx8mm.dtsi | 19
On Thu, Nov 11, 2021 at 2:15 AM Jagan Teki wrote:
>
> Add MIPI DSI pipeline for i.MX8MM.
>
> Video pipeline start from eLCDIF to MIPI DSI and respective
> Panel or Bridge on the backend side.
>
> Add support for it.
Jagan,
Thanks for your continued work on IMX8MM DSI support!
It doesn't look
This string- and electrical configuration depend on the board and panel,
and should hence not be defined generically for every user of pm660l.
SoMainline will pick this configuration again when enabling WLED on the
Sony Nile platform.
Fixes: 7b56a804e58b ("arm64: dts: qcom: pm660l: Add WLED
The property is named "qcom,external-pfet", as found by
dt_binding_check:
'qcom,eternal-pfet' does not match any of the regexes
Fixes: 37aa540cbd30 ("arm64: dts: qcom: pmi8994: Add WLED node")
Signed-off-by: Marijn Suijten
Reviewed-By: AngeloGioacchino Del Regno
---
The hardware is capable of controlling any non-contiguous sequence of
LEDs specified in the DT using qcom,enabled-strings as u32
array, and this also follows from the DT-bindings documentation. The
numbers specified in this array represent indices of the LED strings
that are to be enabled and
Only WLED 3 sets a sensible default that allows operating this driver
with just qcom,num-strings in the DT; WLED 4 and 5 require
qcom,enabled-strings to be provided otherwise enabled_strings remains
zero-initialized, resuling in every string-specific register write
(currently only the setup and
The number of WLED strings used by a certain platform depend on the
panel connected to that board and may not be the same for every user of
pmi8994.
Signed-off-by: Marijn Suijten
Reviewed-By: AngeloGioacchino Del Regno
---
arch/arm64/boot/dts/qcom/msm8996-sony-xperia-tone.dtsi | 1 +
The driver now sets an appropriate default for WLED4 (and WLED5) just
like WLED3 making this linear array from 0-3 redundant. In addition the
driver is now able to parse arrays of variable length solving the "all
four strings *have to* be defined" comment.
Besides the driver will now warn when
Remove redundant spaces inside for loop conditions. No other double
spaces were found that are not part of indentation with `[^\s] `.
Signed-off-by: Marijn Suijten
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/qcom-wled.c | 4 ++--
1 file
The length of qcom,enabled-strings as property array is enough to
determine the number of strings to be enabled, without needing to set
qcom,num-strings to override the default number of strings when less
than the default (which is also the maxium) is provided in DT.
Fixes: 775d2ffb4af6
This patchset fixes WLED's handling of enabled-strings: besides some
cleanup it is now actually possible to specify a non-contiguous array of
enabled strings (not necessarily starting at zero) and the values from
DT are now validated to prevent possible unexpected out-of-bounds
register and array
The previous commit improves num_strings parsing to not go over the
maximum of 3 strings for WLED3 anymore. Likewise this default index for
a hypothetical 4th string is invalid and could access registers that are
not mapped to the desired purpose.
Removing this value gets rid of undesired
The kernel already provides appropriate primitives to perform endianness
conversion which should be used in favour of manual bit-wrangling.
Signed-off-by: Marijn Suijten
Reviewed-by: AngeloGioacchino Del Regno
Reviewed-by: Daniel Thompson
---
drivers/video/backlight/qcom-wled.c | 25
of_property_read_u32_array takes the number of elements to read as last
argument. This does not always need to be 4 (sizeof(u32)) but should
instead be the size of the array in DT as read just above with
of_property_count_elems_of_size.
To not make such an error go unnoticed again the driver now
When not specifying num-strings in the DT the default is used, but +1 is
added to it which turns WLED3 into 4 and WLED4/5 into 5 strings instead
of 3 and 4 respectively, causing out-of-bounds reads and register
read/writes. This +1 exists for a deficiency in the DT parsing code,
and is simply
The strings passed in DT may possibly cause out-of-bounds register
accesses and should be validated before use.
Fixes: 775d2ffb4af6 ("backlight: qcom-wled: Restructure the driver for WLED3")
Signed-off-by: Marijn Suijten
Reviewed-by: AngeloGioacchino Del Regno
---
On Thu, Nov 11, 2021 at 2:15 AM Jagan Teki wrote:
>
> This series support MIPI DSI on i.MX8MM.
>
> The DSIM bridge still need to work to make it compatible for
> exynos drm dsi hardware block.
>
> This series work directly on to of linux-next with recent
> dispmix-blk-ctrl changes.
>
Jagan,
Hi, Nancy:
Nancy.Lin 於 2021年10月29日 週五 下午3:52寫道：
>
> Add driver data of mt8195 vdosys1 to mediatek-drm and the sub driver.
>
> Signed-off-by: Nancy.Lin
> ---
> drivers/gpu/drm/mediatek/mtk_disp_merge.c | 4 ++
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 13 ++---
>
From: Rob Clark
Mesa attempts to allocate a cached-coherent buffer in order to determine
if cached-coherent is supported. Resulting in seeing this error message
once per process with newer mesa. But no reason for this to be more
than a debug msg.
Signed-off-by: Rob Clark
---
From: Rob Clark
Reported-by: kernel test robot
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
index 8a2af3a27e33..dcde5eff931d
add sysfs knobs to enable modules' pr_debug()s ---> tracefs
Signed-off-by: Jim Cromie
---
drivers/gpu/drm/amd/display/dc/core/dc_debug.c | 8
drivers/gpu/drm/drm_print.c| 13 ++---
drivers/gpu/drm/i915/intel_gvt.c | 15 ---
3 files
With the recent addition of pr_debug to tracefs via +T flag, we now
want to add drm.trace; like its model: drm.debug, it maps bits to
pr_debug categories, but this one enables/disables writing to tracefs
(iff CONFIG_TRACING).
Do this by:
1. add flags to dyndbg_bitmap_param, holds "p" or "T" to
Duplicate drm_debug_enabled() code into both "basic" and "dyndbg"
ifdef branches. Then add a pr_debug("todo: ...") into the "dyndbg"
branch.
Then convert the "dyndbg" branch's code to a macro, so that the
pr_debug() get its callsite info from the invoking function, instead
of from
Sean Paul proposed, in:
https://patchwork.freedesktop.org/series/78133/
drm/trace: Mirror DRM debug logs to tracefs
His patchset's objective is to be able to independently steer some of
the drm.debug stream to an alternate tracing destination, by splitting
drm_debug_enabled() into syslog & trace
drm's debug system writes 10 distinct categories of messages to syslog
using a small API[1]: drm_dbg*(10 names), DRM_DEV_DEBUG*(3 names),
DRM_DEBUG*(8 names). There are thousands of these callsites, each
categorized in this systematized way.
These callsites can be enabled at runtime by their
The gvt component of this driver has ~120 pr_debugs with formats using
one of 9 fixed string prefixes, which are quite similar to those
enumerated in DRM debug categories. Following the interface model of
drm.debug, add a parameter to map bits to these format prefixes.
static struct
Taking embedded spaces out of existing prefixes makes them more easily
searchable; simplifying the extra quoting needed otherwise:
$> echo format "^gvt: core:" +p >control
Dropping the internal spaces means any trailing space in a query will
more clearly terminate the prefix being searched
logger_types.h defines many DC_LOG_*() categorized debug wrappers.
Most of these already use DRM debug API, so are controllable using
drm.debug, but others use a bare pr_debug("$prefix: .."), with 1 of 13
different class-prefixes matching [:uppercase:]
Use DEFINE_DYNAMIC_DEBUG_BITGRPS to create a
allocates and initializes ...
Signed-off-by: Jim Cromie
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 0cd95953cdf5..4b29261c4537 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@
DEFINE_DYNAMIC_DEBUG_BITGRPS(fsname, var, bitmap_desc, bitmap)
allows users to create a drm.debug style (bitmap) sysfs interface,
mapping each bit to a group of pr_debugs, matching on their formats.
This works well when the formats systematically include a prefix
string such as ERR|WARN|INFO,
Hi Jason, Greg, DRM-everyone, everyone,
resend to add more people, after rebasing on master to pick up
306589856399 drm/print: Add deprecation notes to DRM_...() functions
This patchset has 3 separate but related parts:
1. DEFINE_DYNAMIC_DEBUG_BITGRPS macro [patch 1/10]
Declares DRM.debug
> -Original Message-
> From: Harry Wentland
> Sent: Friday, November 12, 2021 2:41 AM
> To: Shankar, Uma ; Ville Syrjälä
>
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
> ppaala...@gmail.com; brian.star...@arm.com; sebast...@sebastianwick.net;
>
Coarse power gating for render should not be enabled on some DG2
steppings.
Bspec: 52698
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
From: Ramalingam C
Invalidate IC cache through pipe control command as part of the ctx
restore flow through indirect ctx pointer
Cc: Chris Wilson
Signed-off-by: Ramalingam C
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 5 +
1 file changed, 5 insertions(+)
diff
From: Matt Atwood
Extend existing workaround 1409120013 to DG2.
Cc: José Roberto de Souza
Signed-off-by: Matt Atwood
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
We have a few more DG2 workarounds that weren't included in the initial
batch.
Matt Atwood (1):
drm/i915/dg2: extend Wa_1409120013 to DG2
Matt Roper (2):
drm/i915/dg2: Add Wa_14010547955
drm/i915/dg2: Add Wa_16011777198
Ramalingam C (1):
drm/i915/dg2: Add Wa_16013000631
This workaround is documented a bit strangely in the bspec; it's listed
as an A0 workaround, but the description clarifies that the workaround
is implicitly handled by the hardware and what the driver really needs
to do is program a chicken bit to reenable some internal behavior.
Signed-off-by:
A weak implementation of parallel submission (multi-bb execbuf IOCTL) for
execlists. Doing as little as possible to support this interface for
execlists - basically just passing submit fences between each request
generated and virtual engines are not allowed. This is on par with what
is there for
On Thu, Nov 11, 2021 at 2:19 AM Jagan Teki wrote:
>
> On Wed, Nov 10, 2021 at 11:58 PM Jagan Teki
> wrote:
> >
> > On Wed, Nov 10, 2021 at 2:24 AM Tim Harvey wrote:
> > >
> > > On Tue, Nov 9, 2021 at 12:39 PM Marek Vasut wrote:
> > > >
> > > > On 11/9/21 8:35 PM, Adam Ford wrote:
> > > >
> >
On 2021-11-11 15:42, Shankar, Uma wrote:
>
>
>> -Original Message-
>> From: Ville Syrjälä
>> Sent: Thursday, November 11, 2021 10:13 PM
>> To: Harry Wentland
>> Cc: Shankar, Uma ; intel-...@lists.freedesktop.org;
>> dri-
>> de...@lists.freedesktop.org; ppaala...@gmail.com;
Hi Linus,
On Thu, Nov 11, 2021 at 2:03 PM Sudip Mukherjee
wrote:
>
> Hi Linus,
>
> My testing has been failing for the last few days. Last good test was
> with 6f2b76a4a384 and I started seeing the failure with ce840177930f5
> where boot timeout.
>
> Last good test -
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, November 11, 2021 10:13 PM
> To: Harry Wentland
> Cc: Shankar, Uma ; intel-...@lists.freedesktop.org;
> dri-
> de...@lists.freedesktop.org; ppaala...@gmail.com; brian.star...@arm.com;
> sebast...@sebastianwick.net;
Hey Matt, apologies for the delay, went thru all the code, LGTM.
Reviewed-by: Alan Previn
P.S. - As a side note, would be interesting to replay the original reason
behind the overloading of the
func ptr bits to begin with... to see what the initial intention was.
...alan
On Wed, 2021-09-22
On Thu, 2021-11-11 at 14:42 +0200, Ville Syrjälä wrote:
> On Wed, Nov 10, 2021 at 05:24:22PM -0500, Rodrigo Vivi wrote:
> > On Wed, Nov 10, 2021 at 01:46:46PM +0200, Ville Syrjälä wrote:
> > > On Wed, Nov 10, 2021 at 10:59:26AM +0530, Tilak Tangudu wrote:
> > > > Enable runtime pm autosuspend by
From: Rob Clark
When converting to use an idr to map userspace fence seqno values back
to a dma_fence, we lost the error return when userspace passes seqno
that is larger than the last submitted fence. Restore this check.
Reported-by: Akhil P Oommen
Fixes: a61acbbe9cf8 ("drm/msm: Track
From: Rob Clark
We weren't dropping the submitqueue reference in all paths. In
particular, when the fence has already been signalled. Split out
a helper to simplify handling this in the various different return
paths.
Fixes: a61acbbe9cf8 ("drm/msm: Track "seqno" fences by idr")
Signed-off-by:
From: Rob Clark
A couple of wait_fence related fixes.
Rob Clark (2):
drm/msm: Fix wait_fence submitqueue leak
drm/msm: Restore error return on invalid fence
drivers/gpu/drm/msm/msm_drv.c| 49 ++--
drivers/gpu/drm/msm/msm_gem_submit.c | 1 +
On 11/10, Colin Ian King wrote:
> There are a couple of calls that are passing null pointers as
> integer zeros rather than NULL. Fix this by using NULL instead.
>
> Fixes: 07c2a41658c4 ("drm/v3d: alloc and init job in one shot")
> Signed-off-by: Colin Ian King
> ---
>
Reviewed-by: Clint Taylor
-Clint
On 11/2/21 3:25 PM, Matt Roper wrote:
The bspec's performance guide suggests programming specific values into
a few registers for optimal performance. Although these aren't
workarounds, it's easiest to handle them inside the GT workaround
functions (which
On Thu, Nov 11, 2021 at 7:54 AM Akhil P Oommen wrote:
>
> On 11/10/2021 10:25 PM, Rob Clark wrote:
> > On Wed, Nov 10, 2021 at 7:28 AM Akhil P Oommen
> > wrote:
> >>
> >> On 7/28/2021 6:36 AM, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>> Previously the (non-fd) fence returned from submit
On 11/9/2021 11:41 PM, Rob Clark wrote:
From: Rob Clark
Add a debugfs interface to ignore hw error irqs, in order to force
fallback to sw hangcheck mechanism. Because the hw error detection is
pretty good on newer gens, we need this for igt tests to test the sw
hang detection.
Signed-off-by:
On 11/9/2021 11:41 PM, Rob Clark wrote:
From: Rob Clark
Add some helpers for fence comparision, which handle rollover properly,
and stop open coding fence seqno comparisions.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_fence.h | 12
drivers/gpu/drm/msm/msm_gpu.c |
On Mon, Nov 01, 2021 at 10:35:09AM +, Tvrtko Ursulin wrote:
>
> On 27/10/2021 21:10, Matthew Brost wrote:
> > On Wed, Oct 27, 2021 at 01:04:49PM -0700, John Harrison wrote:
> > > On 10/27/2021 12:17, Matthew Brost wrote:
> > > > On Tue, Oct 26, 2021 at 02:58:00PM -0700, John Harrison wrote:
>
On 11/9/2021 11:41 PM, Rob Clark wrote:
From: Rob Clark
cur_ctx_seqno already does the same thing, but handles the edge cases
where a refcnt'd context can live after lastclose. So let's not have
two ways to do the same thing.
Signed-off-by: Rob Clark
---
On Wed, 2021-11-10 at 09:50 -0500, Zack Rusin wrote:
> TTM takes full control over TTM_PL_SYSTEM placed buffers. This makes
> driver internal usage of TTM_PL_SYSTEM prone to errors because it
> requires the drivers to manually handle all interactions between TTM
> which can swap out those buffers
On Thu, Nov 11, 2021 at 10:17:17AM -0500, Harry Wentland wrote:
>
>
> On 2021-09-06 17:38, Uma Shankar wrote:
> > Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> > planes have different capabilities, implemented respective
> > structure for the HDR planes.
> >
> >
On Thu, Nov 11, 2021 at 3:51 PM Marek Vasut wrote:
>
> On 11/11/21 11:14 AM, Jagan Teki wrote:
>
> [...]
>
> > + dsi: dsi@32e1 {
> > + compatible = "fsl,imx8mm-mipi-dsim";
> > + reg = <0x32e1 0x400>;
> > +
Hi,
On Thu, Oct 28, 2021 at 12:39 PM Doug Anderson wrote:
>
> Hi,
>
> On Thu, Oct 28, 2021 at 11:02 AM Philip Chen wrote:
> >
> > Add "Sam Ravnborg " to cc list for vis.
> > Remove "Andrzej Hajda " from cc list as the
> > address can't be found.
>
> Looking at
>
https://bugzilla.kernel.org/show_bug.cgi?id=205089
--- Comment #22 from Joey Espinosa (jlouis.espin...@gmail.com) ---
Kernel version would help too probably :-/
5.14.16-301.fc35.x86_64
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the
https://bugzilla.kernel.org/show_bug.cgi?id=205089
Joey Espinosa (jlouis.espin...@gmail.com) changed:
What|Removed |Added
CC|
On 2021-11-10 8:24 a.m., Daniel Vetter wrote:
On Wed, Nov 10, 2021 at 11:09:50AM +0100, Christian König wrote:
Am 10.11.21 um 10:50 schrieb Daniel Vetter:
On Tue, Nov 09, 2021 at 08:17:01AM -0800, Rob Clark wrote:
On Tue, Nov 9, 2021 at 1:07 AM Daniel Vetter wrote:
On Mon, Nov 08, 2021 at
On 11/10/2021 10:25 PM, Rob Clark wrote:
On Wed, Nov 10, 2021 at 7:28 AM Akhil P Oommen wrote:
On 7/28/2021 6:36 AM, Rob Clark wrote:
From: Rob Clark
Previously the (non-fd) fence returned from submit ioctl was a raw
seqno, which is scoped to the ring. But from UABI standpoint, the
ioctls
On 10/11/2021 14:37, Robin Murphy wrote:
On 2021-11-10 14:11, Tvrtko Ursulin wrote:
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi
On 2021-09-06 17:38, Uma Shankar wrote:
> Define the structure with XE_LPD degamma lut ranges. HDR and SDR
> planes have different capabilities, implemented respective
> structure for the HDR planes.
>
> Signed-off-by: Uma Shankar
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 52
On 10/11/2021 12:35, Lu Baolu wrote:
On 2021/11/10 20:08, Tvrtko Ursulin wrote:
On 10/11/2021 12:04, Lu Baolu wrote:
On 2021/11/10 17:30, Tvrtko Ursulin wrote:
On 10/11/2021 07:12, Lu Baolu wrote:
Hi Tvrtko,
On 2021/11/9 20:17, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
On igfx + dgfx
On Wed, 10 Nov 2021 20:43:28 +0100, H. Nikolaus Schaller wrote:
> From: Sam Ravnborg
>
> Add DT bindings for the hdmi driver for the Ingenic JZ4780 SoC.
> Based on .txt binding from Zubair Lutfullah Kakakhel
>
> We also add add generic ddc-i2c-bus to synopsys,dw-hdmi.yaml
>
> Signed-off-by:
On Thu, 11 Nov 2021 11:07:21 -0300
Igor Torrente wrote:
> Hi Pekka,
>
> On Thu, Nov 11, 2021 at 6:33 AM Pekka Paalanen wrote:
> >
> > On Wed, 10 Nov 2021 13:56:54 -0300
> > Igor Torrente wrote:
> >
> > > On Tue, Nov 9, 2021 at 8:40 AM Pekka Paalanen
> > > wrote:
> > > >
> > > > Hi Igor,
Hi Pekka,
On Thu, Nov 11, 2021 at 6:33 AM Pekka Paalanen wrote:
>
> On Wed, 10 Nov 2021 13:56:54 -0300
> Igor Torrente wrote:
>
> > On Tue, Nov 9, 2021 at 8:40 AM Pekka Paalanen wrote:
> > >
> > > Hi Igor,
> > >
> > > again, that is a really nice speed-up. Unfortunately, I find the code
> > >
On Wed, Nov 10, 2021 at 09:34:52PM -0300, André Almeida wrote:
> Hi,
>
> This RFC is a preview of the progress we made in the KUnit hackathon[0].
> This patch, made by Maíra and Arthur, converts the damage helper test
> from the original DRM selftest framework to use the KUnit framework.
>
> [0]
From: Tvrtko Ursulin
Trying to capture uninitialised engines when we wedged on init ends in
tears. Skip that together with uC capture, since failure to initialise the
latter can actually be one of the reasons for wedging on init.
v2:
* Use i915_disable_error_state when wedging on init/fini.
Update the copy function i915_gem_obj_copy_ttm() to be asynchronous for
future users and update the only current user to sync the objects
as needed after this function.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 40 ++--
Don't wait sync while migrating, but rather make the GPU blit await the
dependencies and add a moving fence to the object.
This also enables asynchronous VRAM management in that on eviction,
rather than waiting for the moving fence to expire before freeing VRAM,
it is freed immediately and the
On Thu, Nov 11, 2021 at 10:10:54AM +, Simon Ser wrote:
> User-space shouldn't look up the modifier array when the modifier
> flag is missing, but at the moment no docs make this clear (working
> on it). Right now the modifier array is pre-filled with zeroes, aka.
> LINEAR. Instead, pre-fill
There is an interesting refcounting loop:
struct intel_memory_region has a struct ttm_resource_manager,
ttm_resource_manager->move may hold a reference to i915_request,
i915_request may hold a reference to intel_context,
intel_context may hold a reference to drm_i915_gem_object,
Move the i915_gem_obj_copy_ttm() function to i915_gem_ttm_move.h.
This will help keep a number of functions static when introducing
async moves.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 47 ---
drivers/gpu/drm/i915/gem/i915_gem_ttm.h |
From: Maarten Lankhorst
For now, we will only allow async migration when TTM is used,
so the paths we care about are related to TTM.
The mmap path is handled by having the fence in ttm_bo->moving,
when pinning, the binding only becomes available after the moving
fence is signaled, and pinning a
From: Maarten Lankhorst
We want to get rid of i915_vma tracking to simplify the code and
lifetimes. Add a way to set/put the moving fence, in preparation for
removing the tracking.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_object.c | 37 ++
This patch series deals with async migration and async vram management.
It still leaves an important part out, which is async unbinding which
will reduce latency further, at least when trying to migrate already active
objects.
Patches 1/6 and 2/6 deal with accessing and waiting for the TTM moving
On Wed, Nov 10, 2021 at 05:24:22PM -0500, Rodrigo Vivi wrote:
> On Wed, Nov 10, 2021 at 01:46:46PM +0200, Ville Syrjälä wrote:
> > On Wed, Nov 10, 2021 at 10:59:26AM +0530, Tilak Tangudu wrote:
> > > Enable runtime pm autosuspend by default for gen12 and
> > > later versions.
> > >
> > >
On Thu, Nov 11, 2021 at 12:57:57PM +0100, Javier Martinez Canillas wrote:
> The efifb and simplefb drivers just render to a pre-allocated frame buffer
> and rely on the display hardware being initialized before the kernel boots.
>
> But if another driver already probed correctly and registered a
The efifb and simplefb drivers just render to a pre-allocated frame buffer
and rely on the display hardware being initialized before the kernel boots.
But if another driver already probed correctly and registered a fbdev, the
generic drivers shouldn't be probed since an actual driver for the
On Tue, 9 Nov 2021 at 08:56, Simon Ser wrote:
> There are a few details specific to the GETFB2 IOCTL.
>
> It's not immediately clear how user-space should check for the
> number of planes. Suggest using the pitches field.
In fairness it is perfectly clear, it's just that I never considered
On Thu, 11 Nov 2021 at 10:11, Simon Ser wrote:
> User-space shouldn't look up the modifier array when the modifier
> flag is missing, but at the moment no docs make this clear (working
> on it). Right now the modifier array is pre-filled with zeroes, aka.
> LINEAR. Instead, pre-fill with INVALID
On Thu, Nov 11, 2021 at 12:11:20PM +0100, Javier Martinez Canillas wrote:
> The efifb and simplefb drivers just render to a pre-allocated frame buffer
> and rely on the display hardware being initialized before the kernel boots.
>
> But if another driver already probed correctly and registered a
1 - 100 of 129 matches
Mail list logo
