Hi, Nancy:
On Thu, 2021-07-22 at 09:32 +0800, Nancy.Lin wrote:
> Hi Chun-Kuang,
>
> On Mon, 2021-07-19 at 07:56 +0800, Chun-Kuang Hu wrote:
> > Hi, Nancy:
> >
> > Nancy.Lin 於 2021年7月17日 週六 下午5:04寫道：
> > >
> > > Add ETHDR module files:
> > > ETHDR is designed for HDR video and graphics
On Wed, Jul 21, 2021 at 3:51 PM Matt Roper wrote:
>
> On Tue, Jul 20, 2021 at 04:20:13PM -0700, Lucas De Marchi wrote:
> > We kept adding new engines and for that increasing hw_id unnecessarily:
> > it's not used since GRAPHICS_VER == 8. Prepend "gen6" to the field and
> > try to pack it in the
On Fri, Jul 16, 2021 at 01:17:06PM -0700, Matthew Brost wrote:
> From: John Harrison
>
> The driver must provide GuC with a list of mmio registers
> that should be saved/restored during a GuC-based engine reset.
> Unfortunately, the list must be dynamically allocated as its size is
> variable.
The Generic System Framebuffers support is built when the COMPILE_TEST
option is enabled. But this wrongly assumes that all the architectures
declare a struct screen_info.
This is true for most architectures, but at least the following do not:
arc, m68k, microblaze, openrisc, parisc and s390.
By
Update the DSI controller header XML file to add registers
and bitfields to support rectangular checkered pattern
generator.
Signed-off-by: Abhinav Kumar
---
drivers/gpu/drm/msm/dsi/dsi.xml.h | 94 +++
1 file changed, 75 insertions(+), 19 deletions(-)
diff
During board bringups its useful to have a DSI test pattern
generator to isolate a DPU vs a DSI issue and focus on the relevant
hardware block.
To facilitate this, add an API which triggers the DSI controller
test pattern. The expected output is a rectangular checkered pattern.
This has been
Some bootloaders set the widebus enable bit in the INTF_CONFIG register,
but configuration of widebus isn't yet supported ensure that the
register has a known value, with widebus disabled.
Fixes: c943b4948b58 ("drm/msm/dp: add displayPort driver support")
Signed-off-by: Bjorn Andersson
---
Not all platforms has P0 at an offset of 0x1000 from the base address,
so add support for specifying each sub-region in DT. The code falls back
to the predefined offsets in the case that only a single reg is
specified, in order to support existing DT.
Signed-off-by: Bjorn Andersson
---
Not all platforms has DP_P0 at offset 0x1000 from the beginning of the
DP block. So dss_io_data into representing each of the sub-regions, to
make it possible in the next patch to specify each of the sub-regions
individually.
Signed-off-by: Bjorn Andersson
---
The non-devres version of ioremap is used, which requires manual
cleanup. But the code paths leading here is mixed with other devres
users, so rely on this for ioremap as well to simplify the code.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/dp/dp_parser.c | 29
reg was defined as one region covering the entire DP block, but the
memory map is actually split in 4 regions and obviously the size of
these regions differs between platforms.
Switch the reg to require that all four regions are specified instead.
It is expected that the implementation will
In order to deal with multiple memory ranges in the following commit
change the ioremap wrapper to not poke directly into the dss_io_data
struct.
Signed-off-by: Bjorn Andersson
---
drivers/gpu/drm/msm/dp/dp_parser.c | 28 ++--
drivers/gpu/drm/msm/dp/dp_parser.h | 2 +-
It turns out that sc8180x (among others) doesn't have the same internal layout
of the 4 subblocks. This series therefor modifies the binding to require all
four regions to be described individually and then extends the driver to read
these four regions. The driver will fall back to read the old
Hi Vinay,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm/drm-next v5.14-rc2 next-20210721]
[If your patch is applied to the wrong git tree
On Wed, Jul 21, 2021 at 04:03:40PM +0200, Maxime Ripard wrote:
> The binding mentions that all the drivers using that driver must use a
> vendor-specific compatible but never enforces it, nor documents the
> vendor-specific compatibles.
>
> Let's make we document all of them, and that the binding
On Wed, 21 Jul 2021 16:03:40 +0200, Maxime Ripard wrote:
> The binding mentions that all the drivers using that driver must use a
> vendor-specific compatible but never enforces it, nor documents the
> vendor-specific compatibles.
>
> Let's make we document all of them, and that the binding will
Hi Noralf
Thanks for your time to review my patch.
On Thu, 22 Jul 2021 at 01:42, Noralf Trønnes wrote:
>
>
>
> Den 21.07.2021 09.41, skrev dillon.min...@gmail.com:
> > From: Dillon Min
> >
> > This driver combine tiny/ili9341.c mipi_dbi_interface driver
> > with mipi_dpi_interface driver, can
The cursor plane should use the current plane state in atomic_async_update
because it would not be the new plane state in the global atomic state
since _swap_state happened when those hook are run.
Fix cursor plane issue by below modification:
1. Remove plane_helper_funcs->atomic_update(plane,
Hi Vinay,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm/drm-next v5.14-rc2 next-20210721]
[If your patch is applied to the wrong git tree
On 7/21/2021 10:24 AM, Michal Wajdeczko wrote:
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
Add macros to check for SLPC support. This feature is currently supported
for Gen12+ and enabled whenever GuC submission is enabled/selected.
Include templates for SLPC init/fini and enable.
v2:
Hi, Frank:
Frank Wunderlich 於 2021年7月12日 週一 下午4:08寫道：
>
> From: Frank Wunderlich
>
> bridge->driver_private is not set (NULL) so use bridge_to_dpi(bridge)
> like it's done in bridge_atomic_get_output_bus_fmts
Applied to mediatek-drm-fixes [1], thanks.
[1]
On 7/20/2021 6:51 PM, John Harrison wrote:
On 7/20/2021 15:39, Matthew Brost wrote:
Implement GuC context operations which includes GuC specific operations
alloc, pin, unpin, and destroy.
v2:
(Daniel Vetter)
- Use msleep_interruptible rather than cond_resched in busy loop
(Michal)
On 7/19/2021 9:04 PM, Matthew Brost wrote:
On Mon, Jul 19, 2021 at 05:51:46PM -0700, Daniele Ceraolo Spurio wrote:
On 7/16/2021 1:16 PM, Matthew Brost wrote:
Implement GuC context operations which includes GuC specific operations
alloc, pin, unpin, and destroy.
v2:
(Daniel Vetter)
Hi Vinay,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm-exynos/exynos-drm-next
tegra-drm/drm/tegra/for-next drm/drm-next v5.14-rc2 next-20210721]
[If your patch is applied to the wrong git tree
Hi Sam,
Thanks for your time on my code review.
On Thu, 22 Jul 2021 at 00:56, Sam Ravnborg wrote:
>
> Hi Dillon,
>
> On Wed, Jul 21, 2021 at 03:41:28PM +0800, dillon.min...@gmail.com wrote:
> > From: Dillon Min
> >
> > This driver combine tiny/ili9341.c mipi_dbi_interface driver
> > with
From: Maitreyee Rao
Add trace points across the MSM DP driver to help debug
interop issues.
Changes in v4:
- Changed goto statement and used if else-if
Signed-off-by: Maitreyee Rao
---
drivers/gpu/drm/msm/dp/dp_catalog.c | 8 ++--
drivers/gpu/drm/msm/dp/dp_ctrl.c| 5 -
On Wed, Jul 21, 2021 at 03:47:22PM -0700, Matt Roper wrote:
On Tue, Jul 20, 2021 at 04:20:12PM -0700, Lucas De Marchi wrote:
The engine hw_id is only used by RING_FAULT_REG(), which is not used
since GRAPHICS_VER == 8. We tend to keep adding new defines just to be
consistent, but let's try to
Hi Jagan
Thanks for your time to review my code.
On Wed, 21 Jul 2021 at 23:48, Jagan Teki wrote:
>
> On Wed, Jul 21, 2021 at 1:11 PM wrote:
> >
> > From: Dillon Min
> >
> > This driver combine tiny/ili9341.c mipi_dbi_interface driver
> > with mipi_dpi_interface driver, can support ili9341
On Tue, Jul 20, 2021 at 04:20:14PM -0700, Lucas De Marchi wrote:
> This is only used by GRAPHICS_VER == 6 and GRAPHICS_VER == 7. All other
> recent platforms do not depend on this field, so it doesn't make much
> sense to keep it generic like that. Instead, just do a mapping from
> engine class to
On Tue, Jul 20, 2021 at 04:20:13PM -0700, Lucas De Marchi wrote:
> We kept adding new engines and for that increasing hw_id unnecessarily:
> it's not used since GRAPHICS_VER == 8. Prepend "gen6" to the field and
> try to pack it in the structs to give a hint this field is actually not
> used in
On Tue, Jul 20, 2021 at 04:20:12PM -0700, Lucas De Marchi wrote:
> The engine hw_id is only used by RING_FAULT_REG(), which is not used
> since GRAPHICS_VER == 8. We tend to keep adding new defines just to be
> consistent, but let's try to remove them and let them defined to 0 when
> not used.
Quoting Rajeev Nandan (2021-06-22 05:42:28)
> Add support for v2.5.0 DSI block in the SC7280 SoC.
>
> Signed-off-by: Rajeev Nandan
> Reviewed-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Rajeev Nandan (2021-06-22 05:42:27)
> The SC7280 SoC uses the 7nm (V4.1) DSI PHY driver with
> different enable|disable regulator loads.
>
> Signed-off-by: Rajeev Nandan
> Reviewed-by: Dmitry Baryshkov
> ---
Reviewed-by: Stephen Boyd
Quoting Rajeev Nandan (2021-06-22 05:42:26)
> The SC7280 SoC uses the 7nm (V4.1) DSI PHY driver.
>
> Signed-off-by: Rajeev Nandan
> ---
Reviewed-by: Stephen Boyd
On Tue, Jul 20, 2021 at 04:20:11PM -0700, Lucas De Marchi wrote:
> gen8_clear_engine_error_register() is actually not used by
> GRAPHICS_VER >= 8, since for those we are using another register that is
> not engine-dependent. Fix the platform prefix, to make clear we are not
> using any
From: Colin Ian King
A couple of statements are indented with spaces, clean this up
by replacing spaces with tabs.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c
Hello Stephen,
Thanks again for the review comments
On 2021-07-20 22:31, Stephen Boyd wrote:
Quoting maitreye (2021-07-20 15:39:30)
diff --git a/drivers/gpu/drm/msm/dp/dp_link.c
b/drivers/gpu/drm/msm/dp/dp_link.c
index be986da..316e8e6 100644
--- a/drivers/gpu/drm/msm/dp/dp_link.c
+++
Hi Dave, Daniel,
Updates for 5.14. Mostly fixes for new asics added in 5.14.
The following changes since commit 876d98e5511d8cfd12fc617a6717e7a8ea07be17:
Merge tag 'drm-intel-fixes-2021-07-15' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2021-07-16 10:53:02
+1000)
are
Add intel_context tracing. These trace points are particular helpful
when debugging the GuC firmware and can be enabled via
CONFIG_DRM_I915_LOW_LEVEL_TRACEPOINTS kernel config option.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
When running the GuC the GPU can't be considered idle if the GuC still
has contexts pinned. As such, a call has been added in
intel_gt_wait_for_idle to idle the UC and in turn the GuC by waiting for
the number of unpinned contexts to go to zero.
v2: rtimeout -> remaining_timeout
v3: Drop
Update GuC debugfs to support the new GuC structures.
v2:
(John Harrison)
- Remove intel_lrc_reg.h include from i915_debugfs.c
(Michal)
- Rename GuC debugfs functions
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
Disable preempt busywait when using GuC scheduling. This isn't needed as
the GuC controls preemption when scheduling.
v2:
(John H):
- Fix commit message
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 6 --
1
Add bypass tasklet submission path to GuC. The tasklet is only used if H2G
channel has backpresure.
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 37 +++
1 file changed, 29 insertions(+), 8 deletions(-)
diff --git
Semaphores are an optimization and not required for basic GuC submission
to work properly. Disable until we have time to do the implementation to
enable semaphores and tune them for performance. Also long direction is
just to delete semaphores from the i915 so another reason to not enable
these
Ensure G2H response has space in the buffer before sending H2G CTB as
the GuC can't handle any backpressure on the G2H interface.
v2:
(Matthew)
- s/INTEL_GUC_SEND/INTEL_GUC_CT_SEND
v3:
(Matthew)
- Add G2H credit accounting to blocking path, add g2h_release_space
helper
(John H)
-
Extend the deregistration context fence to fence whne a GuC context has
scheduling disable pending.
v2:
(John H)
- Update comment why we check the pin count within spin lock
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
Add trace point for GuC submit. Extended existing request trace points
to include submit fence value,, guc_id, and ring tail value.
v2: Fix white space alignment in i915_request_add trace point
v3: Delete dep_from , dep_to (Tvrtko)
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by:
Sometimes during context pinning a context with the same guc_id is
registered with the GuC. In this a case deregister must be done before
the context can be registered. A fence is inserted on all requests while
the deregister is in flight. Once the G2H is received indicating the
deregistration is
Add LRC descriptor context lookup array which can resolve the
intel_context from the LRC descriptor index. In addition to lookup, it
can determine if the LRC descriptor context is currently registered with
the GuC by checking if an entry for a descriptor index is present.
Future patches in the
Implement GuC context operations which includes GuC specific operations
alloc, pin, unpin, and destroy.
v2:
(Daniel Vetter)
- Use msleep_interruptible rather than cond_resched in busy loop
(Michal)
- Remove C++ style comment
v3:
(Matthew Brost)
- Drop GUC_ID_START
(John Harrison)
-
With GuC scheduling, it isn't safe to unpin a context while scheduling
is enabled for that context as the GuC may touch some of the pinned
state (e.g. LRC). To ensure scheduling isn't enabled when an unpin is
done, a call back is added to intel_context_unpin when pin count == 1
to disable
Disable engine barriers for unpinning with GuC. This feature isn't
needed with the GuC as it disables context scheduling before unpinning
which guarantees the HW will not reference the context. Hence it is
not necessary to defer unpinning until a kernel context request
completes on each engine in
If two requests are on the same ring, they are explicitly ordered by the
HW. So, a submission fence is sufficient to ensure ordering when using
the new GuC submission interface. Conversely, if two requests share a
timeline and are on the same physical engine but different context this
doesn't
Implement GuC submission tasklet for new interface. The new GuC
interface uses H2G to submit contexts to the GuC. Since H2G use a single
channel, a single tasklet is used for the submission path.
Also the per engine interrupt handler has been updated to disable the
rescheduling of the physical
Add new GuC interface defines and structures while maintaining old ones
in parallel.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
.../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 14 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 42 +++
The first 18 patches [1] are basically ready to merge.
v2: Address NITs, add missing RBs, fix checkpatch warnings
Signed-off-by: Matthew Brost
[1] https://patchwork.freedesktop.org/series/91840/
Matthew Brost (18):
drm/i915/guc: Add new GuC interface defines and structures
drm/i915/guc:
Remove old GuC stage descriptor, add LRC descriptor which will be used
by the new GuC interface implemented in this patch series.
v2:
(John Harrison)
- s/lrc/LRC/g
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: John Harrison
---
drivers/gpu/drm/i915/gt/uc/intel_guc.h|
On 7/20/2021 3:39 PM, Matthew Brost wrote:
If two requests are on the same ring, they are explicitly ordered by the
HW. So, a submission fence is sufficient to ensure ordering when using
the new GuC submission interface. Conversely, if two requests share a
timeline and are on the same
On 7/21/2021 11:59 AM, Rodrigo Vivi wrote:
On Thu, Jul 15, 2021 at 09:10:28PM -0700, Daniele Ceraolo Spurio wrote:
From: "Huang, Sean Z"
The HW will generate a teardown interrupt when session termination is
required, which requires i915 to submit a terminating batch. Once the HW
is done
Am Mittwoch, dem 21.07.2021 um 13:55 -0400 schrieb Sean Paul:
> From: Sean Paul
>
> Since the logs protected by these checks specifically target syslog,
> use the new drm_debug_syslog_enabled() call to avoid triggering
> these prints when only trace is enabled.
>
> Signed-off-by: Sean Paul
On Wed, Jul 21, 2021 at 10:11 PM Jason Ekstrand wrote:
>
> On Mon, Jul 19, 2021 at 8:35 AM Matthew Auld
> wrote:
> >
> > On Fri, 16 Jul 2021 at 20:49, Jason Ekstrand wrote:
> > >
> > > On Fri, Jul 16, 2021 at 1:45 PM Matthew Auld
> > > wrote:
> > > >
> > > > On Fri, 16 Jul 2021 at 18:39, Jason
On Thu, Jul 15, 2021 at 5:16 AM Matthew Auld wrote:
>
> From: Chris Wilson
>
> Jason Ekstrand requested a more efficient method than userptr+set-domain
> to determine if the userptr object was backed by a complete set of pages
> upon creation. To be more efficient than simply populating the
On Wed, Jul 21, 2021 at 10:17 PM Jason Ekstrand wrote:
>
> On Wed, Jul 21, 2021 at 1:32 PM Daniel Vetter wrote:
> >
> > This essentially reverts
> >
> > commit 84a1074920523430f9dc30ff907f4801b4820072
> > Author: Chris Wilson
> > Date: Wed Jan 24 11:36:08 2018 +
> >
> > drm/i915:
On Wed, Jul 21, 2021 at 1:32 PM Daniel Vetter wrote:
>
> This essentially reverts
>
> commit 84a1074920523430f9dc30ff907f4801b4820072
> Author: Chris Wilson
> Date: Wed Jan 24 11:36:08 2018 +
>
> drm/i915: Shrink the GEM kmem_caches upon idling
>
> mm/vmscan.c:do_shrink_slab() is a
On Wed, Jul 21, 2021 at 1:56 PM Daniel Vetter wrote:
>
> On Wed, Jul 21, 2021 at 05:25:41PM +0100, Matthew Auld wrote:
> > On 21/07/2021 16:23, Jason Ekstrand wrote:
> > > There's no reason that I can tell why this should be per-i915_buddy_mm
> > > and doing so causes KMEM_CACHE to throw dmesg
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin()
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to
Whenever we had a user object (n_placements > 0), we were ignoring
obj->mm.region and always putting obj->placements[0] as the requested
region. For LMEM+SMEM objects, this was causing them to get shoved into
LMEM on every i915_ttm_get_pages() even when SMEM was requested by, say,
Instead of hand-rolling the same three calls in each function, pull them
into an i915_gem_object_create_user helper. Apart from re-ordering of
the placements array ENOMEM check, there should be no functional change.
v2 (Matthew Auld):
- Add the call to i915_gem_flush_free_objects() from
This doesn't really fix anything serious since the chances of a client
creating and destroying a mass of dumb BOs is pretty low. However, it
is called by the other two create IOCTLs to garbage collect old objects.
Call it here too for consistency.
Signed-off-by: Jason Ekstrand
Reviewed-by:
Since we don't allow changing the set of regions after creation, we can
make ext_set_placements() build up the region set directly in the
create_ext and assign it to the object later. This is similar to what
we did for contexts with the proto-context only simpler because there's
no funny object
We don't roll them together entirely because there are still a couple
cases where we want a separate can_migrate check. For instance, the
display code checks that you can migrate a buffer to LMEM before it
accepts it in fb_create. The dma-buf import code also uses it to do an
early check and
This patch series fixes an issue with discrete graphics on Intel where we
allowed dma-buf import while leaving the object in local memory. This
breaks down pretty badly if the import happened on a different physical
device.
v7:
- Drop "drm/i915/gem/ttm: Place new BOs in the requested region"
-
On Mon, Jul 19, 2021 at 8:35 AM Matthew Auld
wrote:
>
> On Fri, 16 Jul 2021 at 20:49, Jason Ekstrand wrote:
> >
> > On Fri, Jul 16, 2021 at 1:45 PM Matthew Auld
> > wrote:
> > >
> > > On Fri, 16 Jul 2021 at 18:39, Jason Ekstrand wrote:
> > > >
> > > > On Fri, Jul 16, 2021 at 11:00 AM Matthew
On 7/21/21 9:01 PM, Marek Vasut wrote:
[...]
@@ -486,18 +500,6 @@ static int pwm_backlight_probe(struct
platform_device *pdev)
goto err_alloc;
}
- /*
- * If the GPIO is not known to be already configured as output,
that
- * is, if gpiod_get_direction returns
Thanks! Series is:
Acked-by: Kenneth Graunke
https://gitlab.freedesktop.org/kwg/mesa/-/commits/iris-userptr-probe
is an untested Mesa branch that makes use of the new probe uAPI.
On Thursday, July 15, 2021 3:15:35 AM PDT Matthew Auld wrote:
> From: Chris Wilson
>
> Jason Ekstrand requested
Thanks for this! Series is:
Acked-by: Kenneth Graunke
https://gitlab.freedesktop.org/kwg/mesa/-/commits/iris-userptr-probe
is an untested branch that uses the new probe API in Mesa.
On Thursday, July 15, 2021 3:15:35 AM PDT Matthew Auld wrote:
> From: Chris Wilson
>
> Jason Ekstrand
On Wed, Jul 21, 2021 at 09:34:43AM -0700, Rob Clark wrote:
> On Wed, Jul 21, 2021 at 12:59 AM Daniel Vetter wrote:
> >
> > On Wed, Jul 21, 2021 at 12:32 AM Rob Clark wrote:
> > >
> > > On Tue, Jul 20, 2021 at 1:55 PM Daniel Vetter wrote:
> > > >
> > > > On Tue, Jul 20, 2021 at 8:26 PM Rob Clark
On 7/21/21 6:43 PM, Daniel Thompson wrote:
On Wed, Jul 21, 2021 at 05:09:57PM +0200, Marek Vasut wrote:
On 7/21/21 12:49 PM, Daniel Thompson wrote:
However, on the basis of making things less fragile, I think the
underlying problem here is the assumption that it is safe to modify
enable_gpio
On Thu, Jul 15, 2021 at 09:10:28PM -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z"
>
> The HW will generate a teardown interrupt when session termination is
> required, which requires i915 to submit a terminating batch. Once the HW
> is done with the termination it will generate
On Wed, Jul 21, 2021 at 05:25:41PM +0100, Matthew Auld wrote:
> On 21/07/2021 16:23, Jason Ekstrand wrote:
> > There's no reason that I can tell why this should be per-i915_buddy_mm
> > and doing so causes KMEM_CACHE to throw dmesg warnings because it tries
> > to create a debugfs entry with the
On Thu, Jul 15, 2021 at 09:10:22PM -0700, Daniele Ceraolo Spurio wrote:
> Ahead of the PXP implementation, define the relevant define flag and
> kconfig option.
>
> v2: flip kconfig default to N. Some machines have IFWIs that do not
> support PXP, so we need it to be an opt-in until we add
On Thu, Jul 15, 2021 at 09:10:26PM -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z"
>
> Create the arbitrary session, with the fixed session id 0xf, after
> system boot, for the case that application allocates the protected
> buffer without establishing any protection session.
On Thu, Jul 15, 2021 at 09:10:24PM -0700, Daniele Ceraolo Spurio wrote:
> From: "Huang, Sean Z"
>
> Implement the funcs to create the TEE channel, so kernel can
> send the TEE commands directly to TEE for creating the arbitrary
> (default) session.
>
> v2: fix locking, don't pollute dev_priv
On 7/21/21 6:12 PM, Daniel Thompson wrote:
On Wed, Jul 21, 2021 at 05:09:57PM +0200, Marek Vasut wrote:
On 7/21/21 12:49 PM, Daniel Thompson wrote:
I'm not sure that's correct, we can simply say that any new uses of the
pwm-backlight should specify the initial GPIO configuration, and for the
On Wed, Jul 21, 2021 at 10:25:59AM +0100, Tvrtko Ursulin wrote:
On 21/07/2021 00:20, Lucas De Marchi wrote:
This is only used by GRAPHICS_VER == 6 and GRAPHICS_VER == 7. All other
recent platforms do not depend on this field, so it doesn't make much
sense to keep it generic like that. Instead,
This essentially reverts
commit 84a1074920523430f9dc30ff907f4801b4820072
Author: Chris Wilson
Date: Wed Jan 24 11:36:08 2018 +
drm/i915: Shrink the GEM kmem_caches upon idling
mm/vmscan.c:do_shrink_slab() is a thing, if there's an issue with it
then we need to fix that there, not
On Wed, Jul 21, 2021 at 3:32 AM Matthew Auld
wrote:
>
> On Tue, 20 Jul 2021 at 23:07, Jason Ekstrand wrote:
> >
> > On Mon, Jul 19, 2021 at 3:18 AM Matthew Auld
> > wrote:
> > >
> > > On Fri, 16 Jul 2021 at 15:14, Jason Ekstrand wrote:
> > > >
> > > > Since we don't allow changing the set of
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
> This feature hands over the control of HW RC6 to the GuC.
> GuC decides when to put HW into RC6 based on it's internal
> busyness algorithms.
>
> GUCRC needs GuC submission to be enabled, and only
> supported on Gen12+ for now.
>
> When GUCRC is
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
> Update the get/set min/max freq hooks to work for
> SLPC case as well. Consolidate helpers for requested/min/max
> frequency get/set to intel_rps where the proper action can
> be taken depending on whether slpc is enabled.
s/slpc/SLPC
>
> v2:
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
> Cache rp0, rp1 and rpn platform limits into SLPC structure
> for range checking while setting min/max frequencies.
>
> Also add "soft" limits which keep track of frequency changes
> made from userland. These are initially set to platform min
> and
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
> This prints out relevant SLPC info from the SLPC shared structure.
>
> We will send a h2g message which forces SLPC to update the
> shared data structure with latest information before reading it.
>
> v2: Address review comments (Michal W)
>
>
On 21.07.2021 18:11, Vinay Belgaumkar wrote:
> Add helpers to read the min/max frequency being used
> by SLPC. This is done by send a H2G command which forces
> SLPC to update the shared data struct which can then be
> read.
add note that functions will be used later
>
> v2: Address review
From: Sean Paul
This patch adds a new module parameter called drm.trace which accepts
the same mask as drm.debug. When a debug category is enabled, log
messages will be put in a new tracefs instance called drm for
consumption.
Using the new tracefs instance will allow distros to enable drm
From: Sean Paul
The atomic state is printed if the DRM_UT_STATE is active, but it's
printed at INFO level. This patch converts it to use the debug
category printer so:
a- it's consistent with other DRM_UT_STATE logging
b- it's properly routed through drm_trace when introduced
Signed-off-by:
From: Sean Paul
The welcome printer is meant to be gated on DRM_UT_DRIVER, so use the
debug category printer to avoid dumping the message in the wrong
place.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-13-s...@poorly.run
#v5
Changes in
From: Sean Paul
The printers in dp_mst are meant to be gated on DRM_UT_DP, so use the
debug category printer to avoid dumping mst transactions to the wrong
place.
Signed-off-by: Sean Paul
Link:
https://patchwork.freedesktop.org/patch/msgid/20200608210505.48519-12-s...@poorly.run
#v5
Changes
From: Sean Paul
This patch adds a new printer which will select the appropriate output
for a given debug category. Currently there is only one output target,
which is syslog. However in the future we'll have tracefs and it will be
useful to print to syslog, tracefs, or both. Drivers just need to
From: Sean Paul
Since the logs protected by these checks specifically target syslog,
use the new drm_debug_syslog_enabled() call to avoid triggering
these prints when only trace is enabled.
Signed-off-by: Sean Paul
Link:
From: Sean Paul
Since the logs protected by these checks specifically target syslog,
use the new drm_debug_syslog_enabled() call to avoid triggering
these prints when only trace is enabled.
Signed-off-by: Sean Paul
Link:
1 - 100 of 246 matches
Mail list logo
