On 20/10/2021 08:50, patrice.chot...@foss.st.com wrote:
> From: Patrice Chotard
>
> Not all @st.com email address are concerned, only people who have
> a specific @foss.st.com email will see their entry updated.
> For some people, who left the company, remove their email.
>
Please split simple
Well please keep in mind that each patch on its own should not break
anything.
Especially patches #1, #2, #3 and #10 look like they need to be squashed
together to cleanly move the i915 code into a common place.
Christian.
Am 20.10.21 um 00:53 schrieb Arunpravin:
This series of patches impl
From: ran jianping
'drm/ttm/ttm_placement.h' included in
'drivers/gpu/drm/i915/selftests/mock_region.c' is duplicated.
It is also included on the 9 line.
Reported-by: Zeal Robot
Signed-off-by: ran jianping
---
drivers/gpu/drm/i915/selftests/mock_region.c | 2 --
1 file changed, 2 deletion(-)
On 20/10/2021 09:04, Ran Jianping wrote:
From: ran jianping
'drm/ttm/ttm_placement.h' included in
'drivers/gpu/drm/i915/selftests/mock_region.c' is duplicated.
It is also included on the 9 line.
Reported-by: Zeal Robot
Signed-off-by: ran jianping
Pushed to drm-intel-gt-next. Thanks.
---
Hi
Am 20.10.21 um 00:53 schrieb Arunpravin:
- Include drm buddy to DRM root Makefile
- Add drm buddy init and exit function calls
to drm core
Is there a hard requirement to have this code in the core?
IMHO there's already too much code in the DRM core that should rather go
into helpers. T
On Tue, 19 Oct 2021 18:10:57 -0300
Igor Matheus Andrade Torrente wrote:
> Hi Pekka,
>
> On 10/19/21 5:05 AM, Pekka Paalanen wrote:
> > On Mon, 18 Oct 2021 16:26:06 -0300
> > Igor Matheus Andrade Torrente wrote:
> >
> >> Hi Pekka,
> >>
> >> On 10/18/21 5:30 AM, Pekka Paalanen wrote:
> >>> O
On Tue, 19 Oct 2021, Bhawanpreet Lakha wrote:
> 8b/10b encoding format requires to reserve the first slot for
> recording metadata. Real data transmission starts from the second slot,
> with a total of available 63 slots available.
>
> In 128b/132b encoding format, metadata is transmitted separate
On Wed, 20 Oct 2021, Arunpravin wrote:
> - Move i915_buddy.c to drm root folder
> - Rename "i915" string with "drm" string wherever applicable
> - Rename "I915" string with "DRM" string wherever applicable
> - Fix header file dependencies
> - Fix alignment issues
>
> Signed-off-by: Arunpravin
> -
PAGE_KERNEL_IO is only defined for x86 and is the same as PAGE_KERNEL.
Use the latter since that is also available on other archs, which should
help us getting i915 there.
This is the same that was done done in commit 80c33624e472 ("io-mapping:
Fixup for different names of writecombine"). Later th
On 14-10-21, 17:06, Dmitry Baryshkov wrote:
> On 07/10/2021 10:08, Vinod Koul wrote:
> > Later gens of hardware have DSC bits moved to hw_ctl, so configure these
> > bits so that DSC would work there as well
> >
> > Signed-off-by: Vinod Koul
> > ---
> > Changes since
> > v1:
> > - Move this pat
Maxime Ripard 于2021年9月28日周二 下午5:28写道：
>
> On Sun, Sep 26, 2021 at 10:31:53PM +0800, Kevin Tang wrote:
> > Maxime Ripard 于2021年9月17日周五 下午11:40写道：
> > > > +static void sprd_dsi_encoder_mode_set(struct drm_encoder *encoder,
> > > > + struct drm_display_mode *mode,
> > >
On Wed, 20 Oct 2021 08:45:02 +0100,
Krzysztof Kozlowski wrote:
>
> On 20/10/2021 08:50, patrice.chot...@foss.st.com wrote:
> > From: Patrice Chotard
> >
> > Not all @st.com email address are concerned, only people who have
> > a specific @foss.st.com email will see their entry updated.
> > For
On 15-10-21, 02:18, Dmitry Baryshkov wrote:
> On 07/10/2021 10:08, Vinod Koul wrote:
> > When DSC is enabled, we need to configure DSI registers accordingly and
> > configure the respective stream compression registers.
> >
> > Add support to calculate the register setting based on DSC params and
This serie finnally reworks the drm/meson driver by extracting the encoders
in their own file and moves to bridge-only callbacks.
This permits passing the ATTACH_NO_CONNECTOR bridge attach flag and finally
use the CVBS & HDMI display-connector driver.
This will ease Martin Blumenstingl writing th
This implements the necessary change to no more use the embedded
connector in dw-hdmi and use the dedicated bridge connector driver
by passing DRM_BRIDGE_ATTACH_NO_CONNECTOR to the bridge attach call.
The necessary connector properties are added to handle the same
functionalities as the embedded d
Since this bridge is tied to the connector, it acts like a passthrough,
so concerning the output & input bus formats, either pass the bus formats from
the
previous bridge or return fallback data like done in the bridge function:
drm_atomic_bridge_chain_select_bus_fmts() & select_bus_fmt_recursive.
The initial design was recursive to cover all port/endpoints, but only the
first layer
of endpoints should be covered by the components list.
This also breaks the MIPI-DSI init/bridge attach sequence, thus only parse the
first endpoints instead of recursing.
Signed-off-by: Neil Armstrong
Acked-b
Drop the local connector and move all callback to bridge funcs in order
to leverage the generic CVBS diplay connector.
This will also permit adding custom cvbs connectors for ADC based HPD
detection on some Amlogic SoC based boards.
Signed-off-by: Neil Armstrong
Acked-by: Sam Ravnborg
Acked-by:
This moves all the non-DW-HDMI code where it should be:
an encoder in the drm/meson core driver.
The bridge functions are copied as-is, except:
- the encoder init uses the simple kms helper
- the mode_set has been moved to atomic_enable()
- debug prints are converted to dev_debg()
For now the bri
Rename the cvbs encoder to match the newly introduced meson_encoder_hdmi.
Signed-off-by: Neil Armstrong
Acked-by: Sam Ravnborg
Acked-by: Martin Blumenstingl
---
drivers/gpu/drm/meson/Makefile| 2 +-
drivers/gpu/drm/meson/meson_drv.c | 4 +-
...meson_venc_cvbs.c =>
All code in drm_irq.o is for legacy UMs drivers. Only build and link
the file if CONFIG_DRM_LEGACY has been enabled.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Makefile | 6 +++---
drivers/gpu/drm/drm_irq.c | 2 --
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers
DRM core uses the GEM base object to access GEM functionality. It does
not depend on individual implementations. Move the code into modules.
Also move the CMA framebuffer helpers into the CMA's module, as they're
not usable without CMA.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Kconf
Several core DRM functions are not used by the DRM core. Link the
object files into the KMS helper library.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/Makefile | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Make
Move a number of files into modules and behind config options.
So far, early boot graphics was provided by fbdev. With simpledrm, and
possibly other generic DRM drivers, it's now possible to have general
early-boot output with DRM. This requires the DRM core to be linked into
the kernel binary ima
On Wed, 20 Oct 2021 at 15:14, Sankeerth Billakanti
wrote:
>
> From: Sankeerth Billakanti
>
> The eDP controller on SC7280 is similar to the eDP/DP controllers
> supported by the current driver implementation.
>
> SC7280 supports one EDP and one DP controller which can operate
> concurrently.
>
>
Hi
Am 19.10.21 um 16:02 schrieb Alex Bee:
Am 24.06.21 um 11:55 schrieb Thomas Zimmermann:
Moving the driver-specific mmap code into a GEM object function allows
for using DRM helpers for various mmap callbacks.
The respective rockchip functions are being removed. The file_operations
structure
On Wed, Oct 20, 2021 at 08:34:33AM +0200, Thomas Hellström wrote:
> Follow up question: If we resurrect this in the proper way (and in that case
> only for x86_64) is there something we need to pay particular attention to
> WRT the ZONE_DEVICE refcounting fixing you mention above?
Similar to PTE
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission sta
[Why]
Add DP2 MST and debugfs support
[How]
Update the slot info based on the link encoding format
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ++
.../
This code path is used during commit, and we dont expect things to fail
during the commit stage, so remove this.
Signed-off-by: Bhawanpreet Lakha
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology
From: Fangzhi Zuo
Signed-off-by: Fangzhi Zuo
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 19 ++
drivers/gpu/drm/amd/display/dc/dc_link.h | 7 +
drivers/
On Mon, 2021-10-18 at 10:10 +0100, Matthew Auld wrote:
> We currently just evict lmem objects to system memory when under
> memory
> pressure. For this case we might lack the usual object mm.pages,
> which
> effectively hides the pages from the i915-gem shrinker, until we
> actually "attach" the TT
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> These are userspace objects, so mark them as such. In a later patch
> it's
> useful to determine how paranoid we need to be when managing cache
> flushes. In theory no functional changes.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellstr
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> These are userspace objects, so mark them as such. In a later patch
> it's
> useful to determine how paranoid we need to be when managing cache
> flushes. In theory no functional changes.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellstr
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> It looks like we will need this in some more places, so extract as a
> helper.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 26
> ++
> drivers/gpu/drm/i915
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> As pointed out by Thomas, we likely need to flush the pages here if
> the
> GPU can read the page contents directly from main memory. Underneath
> we
> don't know what the sg_table is pointing to, so just add a
> wbinvd_on_all_cpus() here, fo
https://bugzilla.kernel.org/show_bug.cgi?id=211425
Andreas (icedragon...@web.de) changed:
What|Removed |Added
Kernel Version|5.14.6 |5.14.13
--- Comment #22 f
On 10/18/21 19:45, Matthew Auld wrote:
Even though userptr objects are always coherent with the GPU, with no
way for userspace to change this with the set_caching ioctl, even on
non-LLC platforms, there is still the 'Bypass LCC' mocs setting, which
might permit reading the contents of main memo
On 10/18/21 19:45, Matthew Auld wrote:
On non-LLC platforms, force the flush-on-acquire if this is ever
swapped-in. Our async flush path is not trust worthy enough yet(and
happens in the wrong order), and with some tricks it's conceivable for
userspace to change the cache-level to I915_CACHE_NO
On 10/18/21 19:45, Matthew Auld wrote:
Add some details around non-LLC platforms and cflushing, when dealing
with the flush-on-acquire, which is potentially security sensitive.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Daniel Vetter
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> Just like we do for internal objects. Also just use
> i915_gem_object_set_cache_coherency() here. No need for over-flushing
> on
> LLC platforms.
>
> Signed-off-by: Matthew Auld
> Cc: Thomas Hellström
> ---
> drivers/gpu/drm/i915/gem/self
On Mon, 2021-10-18 at 18:45 +0100, Matthew Auld wrote:
> While the pages can't be swapped out, they can be discarded by the
> shrinker.
> Normally such objects are marked with __I915_MADV_PURGED, which can't
> be
> unset, and therefore requires a new object. For kernel internal
> objects
> this is
https://bugzilla.kernel.org/show_bug.cgi?id=213983
--- Comment #2 from Erhard F. (erhar...@mailbox.org) ---
*** Bug 214621 has been marked as a duplicate of this bug. ***
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the b
https://bugzilla.kernel.org/show_bug.cgi?id=214621
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Status|NEW |RESOLVED
Resol
On Fri, Mar 26, 2021 at 06:55:03AM +0100, Christoph Hellwig wrote:
Add a helper that calls remap_pfn_range for an struct io_mapping, relying
on the pgprot pre-validation done when creating the mapping instead of
doing it at runtime.
Signed-off-by: Christoph Hellwig
---
include/linux/io-mapping.
The properties below refer to items in panel-common.yaml, which means
that needs to be referenced in the schema.
Signed-off-by: John Keeping
---
.../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git
a/Documentation/devicetree/binding
The panel orientation needs to parsed from a device-tree and assigned to
the panel's connector in order to make orientation property available to
userspace. That's what this patch does for ILI9881C based panels.
Signed-off-by: John Keeping
---
drivers/gpu/drm/panel/panel-ilitek-ili9881c.c | 11 +
Support the "rotation" DT property for ILI9881C based panels.
The first patch is a fix for the binding, then the usual binding update
followed by the corresponding driver update.
John Keeping (3):
dt-bindings: ili9881c: add missing panel-common inheritance
dt-bindings: ili9881c: add rotation
Allow the standard rotation property from panel-common for ILI9881C
based panels.
Signed-off-by: John Keeping
---
.../devicetree/bindings/display/panel/ilitek,ili9881c.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
a/Documentation/devicetree/bindings/display/panel/ilitek,ili9881c.
Hello Daniel,
On 10/13/21 14:27, Daniel Vetter wrote:
>>>
>>> info->par = fb_helper;
>>> - snprintf(info->fix.id, sizeof(info->fix.id), "%s",
>
> Please add a comment here that drmfb is uapi because pm-utils matches
> against it ...
>
Sure, I'll do that and send a v2.
Best regards,
--
This reverts commit b3484d2b03e4c940a9598aa841a52d69729c582a.
That change attempted to improve the DRM drivers fbdev emulation device
names to avoid having confusing names like "simpledrmdrmfb" in /proc/fb.
But unfortunately, there are user-space programs such as pm-utils that
match against the f
On Wed, Oct 20, 2021 at 10:09 AM Joao Martins wrote:
>
> On 10/19/21 20:21, Dan Williams wrote:
> > On Tue, Oct 19, 2021 at 9:02 AM Jason Gunthorpe wrote:
> >>
> >> On Tue, Oct 19, 2021 at 04:13:34PM +0100, Joao Martins wrote:
> >>> On 10/19/21 00:06, Jason Gunthorpe wrote:
> On Mon, Oct 18,
On Tue, Oct 19, 2021 at 5:59 PM Brian Norris wrote:
>
> https://drm.pages.freedesktop.org/maintainer-tools/drm-misc.html gives
> HTTP 404, and https://drm.pages.freedesktop.org/maintainer-tools/
> redirects to freedesktop.org now.
With a dash of irony, I actually listed the wrong URLs in the
desc
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/drm-misc.html
gives HTTP 404, and
https://01.org/linuxgraphics/gfx-docs/maintainer-tools/ redirects to
freedesktop.org now.
Let's save people the pain of figuring that out.
Signed-off-by: Brian Norris
Reviewed-by: Sean Paul
---
Changes in
We need to cleanup the fences for ghost objects as well.
Signed-off-by: Christian König
CC:
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index 82af095f6b81..f37a8c53b35f 100644
--
Hi,
On Wed, Oct 20, 2021 at 5:14 AM Sankeerth Billakanti
wrote:
>
> From: Sankeerth Billakanti
>
> The Qualcomm SC7280 platform supports an eDP controller, add
> compatible string for it to dp-controller.
>
> Signed-off-by: Sankeerth Billakanti
> ---
> Documentation/devicetree/bindings/display
On Wed, Oct 20, 2021 at 1:32 PM Christian König
wrote:
>
> We need to cleanup the fences for ghost objects as well.
>
> Signed-off-by: Christian König
> CC:
Does this fix this bug?
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Alex
> ---
> drivers/gpu/drm/ttm/ttm_bo_util.c | 1 +
> 1 fi
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #19 from Christian König (christian.koe...@amd.com) ---
Created attachment 299277
--> https://bugzilla.kernel.org/attachment.cgi?id=299277&action=edit
Potential fix
--
You may reply to this email to add a comment.
You are receivin
Am 20.10.21 um 19:43 schrieb Alex Deucher:
On Wed, Oct 20, 2021 at 1:32 PM Christian König
wrote:
We need to cleanup the fences for ghost objects as well.
Signed-off-by: Christian König
CC:
Does this fix this bug?
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Yeah, I was already addi
On 18/10/2021 23:13, Andrzej Hajda wrote:
> Beside updating email, the patch updates maintainers
> of Samsung drivers.
>
> Signed-off-by: Andrzej Hajda
> ---
> .mailmap| 1 +
> MAINTAINERS | 13 -
> 2 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/.mailmap b/.m
Move initialization of sblk in _sspp_subblk_offset() after NULL check to
avoid potential NULL pointer dereference.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Dan Carpenter
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_hw_sspp.c | 8 +---
1 file
Over time we have accumulated some deprecated functions etc. in drm_bridge.
This patch-set starts to move over to the atomic variants and deletes what
is not used anymore.
There was only one user of the non-atomic drm_bridge_chain functions in
parade-ps8640 - migrate it to the atomic variants and
The atomic variants of enable/disable in drm_bridge_funcs are the
preferred operations - introduce these.
The ps8640 driver used the non-atomic variants of the
drm_bridge_chain_pre_enable/
drm_bridge_chain_post_disable - convert these to the atomic variants.
v2:
- Added a few more people to cc
The drm_bridge_chain_{pre_enable,enable,disable,post_disable} has no
users left and we have atomic variants that should be used.
Drop them so they do not gain new users.
Adjust a few comments to avoid references to the dropped functions.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc
The mode_valid implementation had a call to
drm_bridge_chain_mode_fixup() which would be wrong as the mode_valid is
not allowed to change anything - only to validate the mode.
As the next bridge is often/always a connector the call had no effect
anyway. So drop it.
>From the git history I could s
The atomic variants of enable/disable in drm_bridge_funcs are the
preferred operations - introduce these.
Use of mode_set is deprecated - merge the functionality with
atomic_enable()
v2:
- Added check if crtc_state is NULL (Maxime)
- Updated to use drm_atomic_get_new_crtc_for_bridge()
Signed
- deprecated callbacks in drm_bridge_funcs
- move connector creation to display drivers
v2:
- Updated descriptions in todo.rst
Signed-off-by: Sam Ravnborg
Acked-by: Maxime Ripard
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Danie
drm_atomic_get_new_crtc_for_bridge() will be used by bridge
drivers to provide easy access to the mode from the
drm_bridge_funcs operations.
The helper will be useful in the conversion to the atomic
operations of struct drm_bridge_funcs.
v2:
- Renamed to drm_atomic_get_new_crtc_for_bridge (Maxi
There are no users left of drm_bridge_chain_mode_fixup() and we
do not want to have this function available, so drop it.
Signed-off-by: Sam Ravnborg
Reviewed-by: Maxime Ripard
Cc: Laurent Pinchart
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Thomas Zimmermann
Cc: David Airlie
Cc: Daniel Vett
Following kernel crash noticed on linux next 20211020 tag.
while booting on arm64 architecture dragonboard 410c device.
I see the following config is enabled in 20211020 tag builds.
CONFIG_STACKDEPOT=y
Crash log,
[ 18.583097] Unable to handle kernel paging request at virtual
address
Change byte_clk_rate, pixel_clk_rate, esc_clk_rate, and src_clk_rate
from u32 to unsigned long, since clk_get_rate() returns an unsigned long.
Fixes: a6bcddbc2ee1 ("drm/msm: dsi: Handle dual-channel for 6G as well")
Reported-by: Dan Carpenter
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm
Add NULL checks in KMS CRTC funcs to avoid potential NULL
dereference.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Reported-by: Dan Carpenter
Signed-off-by: Jessica Zhang
---
drivers/gpu/drm/msm/disp/dpu1/dpu_core_irq.c | 8
drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
Hi Chun-Kuang,
On Fri, Oct 15, 2021 at 12:04:10AM +0800, Chun-Kuang Hu wrote:
> Hi, Markus:
>
> Markus Schneider-Pargmann 於 2021年10月1日 週五 下午5:44寫道：
> >
> > dpintf is the displayport interface hardware unit. This unit is similar
> > to dpi and can reuse most of the code.
> >
> > This patch adds s
Use __release_guc_id (lock held) rather than release_guc_id (acquires
lock), add lockdep annotations.
213.280129] i915: Running i915_perf_live_selftests/live_noa_gpr
[ 213.283459]
[ 213.283462] WARNING: possible recursive locking detected
{{[ 213.283466
Hi Rob,
On Mon, Oct 11, 2021 at 06:44:53PM -0500, Rob Herring wrote:
> On Mon, 11 Oct 2021 11:46:18 +0200, Markus Schneider-Pargmann wrote:
> > DP_INTF is a similar functional block to mediatek,dpi but is different
> > in that it serves the DisplayPort controller on mediatek SoCs and uses
> > diff
Reviewed-by: Lyude Paul
On Wed, 2021-10-20 at 10:16 -0400, Bhawanpreet Lakha wrote:
> This code path is used during commit, and we dont expect things to fail
> during the commit stage, so remove this.
>
> Signed-off-by: Bhawanpreet Lakha
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
Awesome! So this all looks fine to me, just some formatting changes:
On Wed, 2021-10-20 at 10:16 -0400, Bhawanpreet Lakha wrote:
> 8b/10b encoding format requires to reserve the first slot for
> recording metadata. Real data transmission starts from the second slot,
> with a total of available 63
Use __release_guc_id (lock held) rather than release_guc_id (acquires
lock), add lockdep annotations.
213.280129] i915: Running i915_perf_live_selftests/live_noa_gpr
[ 213.283459]
[ 213.283462] WARNING: possible recursive locking detected
{{[ 213.283466
On 2021-10-04 4:14 a.m., Christian König wrote:
The problem is a bit different.
The callback is on the dependent fence, while we need to signal the
scheduler fence.
Daniel is right that this needs an irq_work struct to handle this
properly.
Christian.
So we had some discussions with Ch
Hi Rob,
On Mon, Oct 18, 2021 at 02:38:33PM -0500, Rob Herring wrote:
> On Mon, Oct 18, 2021 at 9:19 AM Markus Schneider-Pargmann
> wrote:
> >
> > Hi Rob,
> >
> > On Mon, Oct 11, 2021 at 07:43:16PM -0500, Rob Herring wrote:
> > > On Mon, Oct 11, 2021 at 11:46:19AM +0200, Markus Schneider-Pargmann
On Wed, Oct 20, 2021 at 08:41:24AM +0200, Christian König wrote:
> > I think the patch subject needs updating to reflect that we're disabling
> > PUD/PMDs completely.
> > With that fixed,
Everyone is OK with this?
drm/ttm: remove ttm_bo_vm_insert_huge()
The huge page functionality in TTM does n
On Wed, Oct 20, 2021 at 08:40:05AM -0700, Lucas De Marchi wrote:
> On Fri, Mar 26, 2021 at 06:55:03AM +0100, Christoph Hellwig wrote:
> > Add a helper that calls remap_pfn_range for an struct io_mapping, relying
> > on the pgprot pre-validation done when creating the mapping instead of
> > doing it
This code path is used during commit, and we dont expect things to fail
during the commit stage, so remove this.
Signed-off-by: Bhawanpreet Lakha
Reviewed-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/gp
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission sta
From: Fangzhi Zuo
Signed-off-by: Fangzhi Zuo
---
drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
.../gpu/drm/amd/display/dc/core/dc_link_dp.c | 19 ++
drivers/gpu/drm/amd/display/dc/dc_link.h | 7 +
drivers/
[Why]
Add DP2 MST and debugfs support
[How]
Update the slot info based on the link encoding format
Signed-off-by: Bhawanpreet Lakha
Signed-off-by: Fangzhi Zuo
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 29 +++
.../amd/display/amdgpu_dm/amdgpu_dm_debugfs.c | 3 ++
.../
Waitboost is a legacy feature implemented in the Host Turbo algorithm. This
patch set implements it for the SLPC path. A "boost" happens when user
calls gem_wait ioctl on a submission that has not landed on HW yet. GT
frequency gets temporarily bumped to RP0 to allow the previous request
to finish
Boost frequency is initialized at RP0. Also define num_waiters
which can track the pending boost requests. This is set to 0 when
we enable SLPC.
Signed-off-by: Vinay Belgaumkar
---
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c | 10 ++
drivers/gpu/drm/i915/gt/uc/intel_guc_slpc_types.
Add helpers in RPS code for handling SLPC and non-SLPC cases.
When a boost is requested in the SLPC case, we can ask GuC to ramp
up the frequency by setting the minimum frequency to RP0. Reset the
frequency back to the min softlimit when there are no more waiters.
Signed-off-by: Vinay Belgaumkar
Add a helper to sort through the SLPC/RPS cases of get/set methods.
Boost frequency will be modified as long as it is within the constraints
of RP0 and if it is different from the existing one. We will set min
freq to boost only if there is an active waiter.
Signed-off-by: Vinay Belgaumkar
---
d
8b/10b encoding format requires to reserve the first slot for
recording metadata. Real data transmission starts from the second slot,
with a total of available 63 slots available.
In 128b/132b encoding format, metadata is transmitted separately
in LLCP packet before MTP. Real data transmission sta
On Wed, Oct 20, 2021 at 3:50 PM Bhawanpreet Lakha
wrote:
>
> From: Fangzhi Zuo
Please include a patch description.
Alex
>
> Signed-off-by: Fangzhi Zuo
> ---
> drivers/gpu/drm/amd/display/dc/core/dc.c | 14 +
> drivers/gpu/drm/amd/display/dc/core/dc_link.c | 280 ++
> ..
From: Fangzhi Zuo
[Why]
configure/call DC interface for DP2 mst support. This is needed to make DP2
mst work.
[How]
- add encoding type, logging, mst update/reduce payload functions
Use the link encoding to determine the DP type (1.4 or 2.0) and add a
flag to dc_stream_update to determine wheth
https://bugzilla.kernel.org/show_bug.cgi?id=214197
--- Comment #6 from Alex Deucher (alexdeuc...@gmail.com) ---
Does this patch help?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=60b78ed088ebe1a872ee1320b6c5ad6ee2c4bd9a
--
You may reply to this email to add a com
FWIW, I'm using this IOCTL in a wlroots patchset [1].
To detect support for this IOCTL, is there anything better than creating a
DMA-BUF and checking for ENOTTY? I'd like to disable explicit sync at init-time
if this is missing.
[1]: https://github.com/swaywm/wlroots/pull/3282
On 10/11/2021 10:57, Matthew Brost wrote:
perf_parallel_engines is micro benchmark to test i915 request
scheduling. The test creates a thread per physical engine and submits
NOP requests and waits the requests to complete in a loop. In execlists
mode this works perfectly fine as powerful CPU has
The fallback was introduced in commit 80c33624e472 ("io-mapping: Fixup
for different names of writecombine") to fix the build on microblaze.
5 years later, it seems all archs now provide a pgprot_writecombine(),
so just remove the other possible fallbacks. For microblaze,
pgprot_writecombine() is
Set all engine props values for GuC virtual engines as a request can
point to a virtual engine with GuC submission and these props are used
all over the driver. This differs from execlists where a request can
only point to a virtual engine.
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/i915/g
On Tue, 2021-10-19 at 21:09 +0300, Ville Syrjälä wrote:
> On Tue, Oct 05, 2021 at 10:40:14PM -0400, Lyude Paul wrote:
> > This simply adds proper support for panel backlights that can be
> > controlled
> > via VESA's backlight control protocol, but which also require that we
> > enable and disable
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 t
1 - 100 of 128 matches
Mail list logo
