Am 23.09.21 um 02:58 schrieb Dave Airlie:
On Sat, 18 Sept 2021 at 07:57, Alexandre Bailon wrote:
Some Mediatek SoC provides hardware accelerator for AI / ML.
This driver provides the infrastructure to manage memory
shared between host CPU and the accelerator, and to submit
jobs to the accelerat
[AMD Public Use]
Hi Christian,
> And where is the patch to switch i915 and remove the Intel copy of this?
Creating a patch for the switch.
> In general I think that every public function here needs a kerneldoc
> description what it is all about.
Making a kernel doc description for each public f
Hi Paul,
thanks for another update.
We have been delayed to rework the CI20 HDMI code on top of your series
but it basically works in some situations. There is for example a problem
if the EDID reports DRM_COLOR_FORMAT_YCRCB422 but it appears to be outside
of your series.
The only issue we have i
[AMD Public Use]
Hi Alex,
I will fix the name and send a document in my next version.
Thanks,
Arun
-Original Message-
From: Alex Deucher
Sent: Tuesday, September 21, 2021 12:54 AM
To: Paneer Selvam, Arunpravin
Cc: Maling list - DRI developers ; Intel
Graphics Development ; amd-gfx lis
[AMD Public Use]
Hi Christian,
Thanks for the review, I will the send the next version fixing all issues.
Regards,
Arun
-Original Message-
From: Christian König
Sent: Wednesday, September 22, 2021 12:18 PM
To: Paneer Selvam, Arunpravin ; Koenig,
Christian ; dri-devel@lists.freedesktop.
On Tue, Sep 21, 2021 at 04:06:00PM +0300, Ville Syrjälä wrote:
On Mon, Sep 20, 2021 at 10:47:08PM -0700, Lucas De Marchi wrote:
On Wed, Sep 15, 2021 at 12:29:12PM -0700, John Harrison wrote:
>On 9/15/2021 12:24, Belgaumkar, Vinay wrote:
>>On 9/14/2021 12:51 PM, Lucas De Marchi wrote:
>>>The clfl
On Fri 17 Sep 07:59 CDT 2021, Alexandre Bailon wrote:
> Some Mediatek SoC provides hardware accelerator for AI / ML.
> This driver use the DRM driver to manage the shared memory,
> and use rpmsg to execute jobs on the APU.
>
> Signed-off-by: Alexandre Bailon
> ---
> drivers/rpmsg/Kconfig |
On Sat, Sep 18, 2021 at 12:55 AM Bjorn Helgaas wrote:
>
> On Fri, Sep 17, 2021 at 11:49:45AM +0800, Kai-Heng Feng wrote:
> > On Fri, Sep 17, 2021 at 12:38 AM Bjorn Helgaas wrote:
> > >
> > > [+cc Huacai, linux-pci]
> > >
> > > On Wed, May 19, 2021 at 09:57:23PM +0800, Kai-Heng Feng wrote:
> > > >
On Wed, Sep 22, 2021 at 01:15:46PM -0700, John Harrison wrote:
> On 9/22/2021 09:25, Matthew Brost wrote:
> > On Mon, Sep 20, 2021 at 02:48:52PM -0700, John Harrison wrote:
> > > On 8/20/2021 15:44, Matthew Brost wrote:
> > > > Implement multi-lrc submission via a single workqueue entry and single
On Sat, 18 Sept 2021 at 07:57, Alexandre Bailon wrote:
>
> Some Mediatek SoC provides hardware accelerator for AI / ML.
> This driver provides the infrastructure to manage memory
> shared between host CPU and the accelerator, and to submit
> jobs to the accelerator.
> The APU itself is managed by
Hi Rob,
Thank you for the patch.
On Mon, Sep 20, 2021 at 03:58:00PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> Slightly awkward to fish out the display_info when we aren't creating
> own connector. But I don't see an obvious better way.
>
> v2: Remove error return with NO_CONNECTOR flag
>
Hi Rob and Doug,
On Mon, Sep 20, 2021 at 11:32:02AM -0700, Rob Clark wrote:
> On Thu, Aug 12, 2021 at 1:08 PM Doug Anderson wrote:
> > On Thu, Aug 12, 2021 at 12:26 PM Laurent Pinchart wrote:
> > > On Wed, Aug 11, 2021 at 04:52:50PM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > >
On 23/09/2021 00:59, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Thu, Sep 23, 2021 at 12:47:26AM +0100, Kieran Bingham wrote:
>> From: Kieran Bingham
>>
>> Extend the rcar_du_device_info structure and rcar_du_output enum to
>> support DSI outputs and utilise these
Hi Rob,
Thank you for the patch.
On Mon, Sep 20, 2021 at 03:57:59PM -0700, Rob Clark wrote:
> From: Rob Clark
>
> For the brave new world of bridges not creating their own connectors, we
> need to implement the max clock limitation via bridge->mode_valid()
> instead of connector->mode_valid().
With the recent refactor of the uncore mmio handling, all
forcewake-based platforms (i.e., graphics version 6 and beyond) now use
the 'fwtable' read handlers. Let's pull the assignment out of the
per-platform if/else ladder to make this more obvious.
Suggested-by: Tvrtko Ursulin
Suggested-by: Lu
Hi Maxime,
Thank you for the patch.
I know this has already been merged, but I have a question.
On Fri, Sep 10, 2021 at 03:09:39PM +0200, Maxime Ripard wrote:
> Display drivers so far need to have a lot of boilerplate to first
> retrieve either the panel or bridge that they are connected to usin
Hi Kieran,
Thank you for the patch.
On Thu, Sep 23, 2021 at 12:47:26AM +0100, Kieran Bingham wrote:
> From: Kieran Bingham
>
> Extend the rcar_du_device_info structure and rcar_du_output enum to
> support DSI outputs and utilise these additions to provide support for
> the R8A779A0 V3U platform
The R-Car DU as found on the D3, E3, and V3U do not have support
for an external synchronisation method.
In these cases, the dsysr cached register should not be initialised
in DSYSR_TVM_TVSYNC, but instead should be left clear to configure as
DSYSR_TVM_MASTER by default.
Reviewed-by: Laurent Pinc
The DIDSR fields named LDCS were incorrectly defined as LCDS.
Both the Gen2 and Gen3 documentation refer to the fields as the "LVDS
Dot Clock Select".
Correct the definitions.
Reviewed-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
v2:
- New patch
v3:
- Collect tag
drivers/gpu/drm
From: Kieran Bingham
Extend the rcar_du_device_info structure and rcar_du_output enum to
support DSI outputs and utilise these additions to provide support for
the R8A779A0 V3U platform.
While the DIDSR register field is now named "DSI/CSI-2-TX-IF0 Dot Clock
Select" the existing define LVDS0 is
Not all platforms require both per-crtc IRQ and per-crtc clock
management. In preparation for suppporting such platforms, split the
feature macro to be able to specify both features independently.
The other features are incremented accordingly, to keep the two crtc
features adjacent.
Reviewed-by:
From: Kieran Bingham
Sort the DU outputs alphabetically, with the exception of the final
entry which is there as a sentinal.
Reviewed-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
v2:
- Collect tag
drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 4 ++--
1 file changed, 2 insertions(+), 2
From: Kieran Bingham
Extend the Renesas DU display bindings to support the r8a779a0 V3U.
Reviewed-by: Laurent Pinchart
Signed-off-by: Kieran Bingham
---
v2:
- Collected Laurent's tag
- Remove clock-names requirement
- Specify only a single clock
v3:
- Use clocknames: 'du.0' instead of 'd
Hi Cai,
Thank you for the patch.
On Wed, Sep 22, 2021 at 08:59:08PM +0800, Cai Huoqing wrote:
> The helper function devm_add_action_or_reset() will internally
> call devm_add_action(), and if devm_add_action() fails then it will
> execute the action mentioned and return the error code. So
> use d
Hi Cai,
Thank you for the patch.
On Tue, Aug 31, 2021 at 03:54:42PM +0800, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Reviewed-by: Laurent Pinchart
>
Hi Cai,
Thank you for the patch.
On Tue, Aug 31, 2021 at 09:57:30PM +0800, Cai Huoqing wrote:
> Use the devm_platform_ioremap_resource() helper instead of
> calling platform_get_resource() and devm_ioremap_resource()
> separately
>
> Signed-off-by: Cai Huoqing
Reviewed-by: Laurent Pinchart
>
Hi Andrzej,
On Wed, Sep 22, 2021 at 04:29:39AM +0300, Laurent Pinchart wrote:
> On Tue, Sep 21, 2021 at 09:42:11PM +0200, Andrzej Hajda wrote:
> > W dniu 23.06.2021 o 15:56, Laurent Pinchart pisze:
> > > From: LUU HOAI
> > >
> > > The driver supports the MIPI DSI/CSI-2 TX encoder found in the R-C
From: Rob Clark
In the case of iova fault triggered devcore dumps, include additional
debug information based on what we think is the current page tables,
including the TTBR0 value (which should match what we have in
adreno_smmu_fault_info unless things have gone horribly wrong), and
the pagetabl
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/adreno_gpu.c | 25 +
drivers/gpu/drm/msm/msm_gpu.h | 2 +-
3 files changed, 19 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm
On R-Car Gen3, the DU uses a separate IP core named VSP to perform DMA
from memory and composition of planes. The DU hardware then only handles
the video timings and the interface with the encoders. This differs from
Gen2, where the DU included a composer with DMA engines.
When sourcing from the V
From: Rob Clark
Add an io-pgtable method to retrieve the raw PTEs that would be
traversed for a given iova access.
Signed-off-by: Rob Clark
---
drivers/iommu/io-pgtable-arm.c | 40 +++---
include/linux/io-pgtable.h | 9
2 files changed, 41 insertions(+
From: Rob Clark
This series extends io-pgtable-arm with a method to retrieve the page
table entries traversed in the process of address translation, and then
beefs up drm/msm gpu devcore dump to include this (and additional info)
in the devcore dump.
The motivation is tracking down an obscure io
On Fri, Sep 03, 2021 at 04:23:20PM +0200, Janusz Krzysztofik wrote:
> In preparation for clean driver release, attempts to drain work queues
> and release freed objects are taken at driver remove time. However, GT
> buffer pools are now not flushed before the driver release phase.
> Since unused o
Hi Kieran,
On Wed, Sep 22, 2021 at 10:37:29PM +0100, Kieran Bingham wrote:
> On 30/07/2021 03:05, Laurent Pinchart wrote:
> > On R-Car Gen3, the DU uses a separate IP core named VSP to perform DMA
> > from memory and composition of planes. The DU hardware then only handles
> > the video timings an
https://bugzilla.kernel.org/show_bug.cgi?id=214029
Erhard F. (erhar...@mailbox.org) changed:
What|Removed |Added
Summary|[bisected] [NAVI] Several |[bisected] [amdgpu] Sev
https://bugzilla.kernel.org/show_bug.cgi?id=214029
--- Comment #14 from Erhard F. (erhar...@mailbox.org) ---
Created attachment 298927
--> https://bugzilla.kernel.org/attachment.cgi?id=298927&action=edit
kernel dmesg (kernel 5.14.6, AMD Opteron 6386 SE)
Does not seem to be Navi specific after a
On Mon, Sep 20, 2021 at 08:04:32AM +, Gupta, Anshuman wrote:
-Original Message-
From: Nikula, Jani
Sent: Monday, September 20, 2021 1:12 PM
To: De Marchi, Lucas
Cc: Auld, Matthew ; intel-...@lists.freedesktop.org;
dri-devel@lists.freedesktop.org; Gupta, Anshuman
Subject: Re: [In
Hello everybody,
On Tue, Sep 07, 2021 at 09:17:31PM +0200, Geert Uytterhoeven wrote:
> On Tue, Sep 7, 2021 at 8:45 PM Rob Herring wrote:
> > On Mon, Sep 06, 2021 at 10:13:07AM +0200, Geert Uytterhoeven wrote:
> > > On Thu, Sep 2, 2021 at 1:39 AM Kieran Bingham wrote:
> > > > From: Kieran Bingham
Hi Kieran,
Thank you for the patch.
On Thu, Sep 02, 2021 at 12:49:07AM +0100, Kieran Bingham wrote:
> From: Kieran Bingham
>
> Extend the rcar_du_device_info structure and rcar_du_output enum to
> support DSI outputs and utilise these additions to provide support for
> the R8A779A0 V3U platform
On 30/07/2021 03:05, Laurent Pinchart wrote:
> On R-Car Gen3, the DU uses a separate IP core named VSP to perform DMA
> from memory and composition of planes. The DU hardware then only handles
> the video timings and the interface with the encoders. This differs from
> Gen2, where the DU included a
On Tue, Sep 21, 2021 at 06:40:41PM -0700, Matthew Brost wrote:
On Tue, Sep 21, 2021 at 04:29:31PM -0700, Lucas De Marchi wrote:
On Tue, Sep 21, 2021 at 03:55:15PM -0700, Matthew Brost wrote:
> On Tue, Sep 21, 2021 at 11:46:37AM -0700, Lucas De Marchi wrote:
> > On Tue, Sep 21, 2021 at 10:43:32AM
On Wed, Sep 22, 2021 at 09:52:07PM +0200, Borislav Petkov wrote:
> On Wed, Sep 22, 2021 at 05:30:15PM +0300, Kirill A. Shutemov wrote:
> > Not fine, but waiting to blowup with random build environment change.
>
> Why is it not fine?
>
> Are you suspecting that the compiler might generate somethin
Attach a top-level bridge to each encoder, which will be used for
negociating the bus format and flags.
All the bridges are now attached with DRM_BRIDGE_ATTACH_NO_CONNECTOR.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-drm-drv.c | 92 +--
1 file changed,
When using C8 color mode, make sure that the palette is always uploaded
before a frame; otherwise the very first frame will have wrong colors.
Do that by changing the link order of the DMA descriptors.
v3: Fix ingenic_drm_get_new_priv_state() called instead of
ingenic_drm_get_priv_state()
Si
Setting the DMA descriptor chain register in the probe function has been
fine until now, because we only ever had one descriptor per foreground.
As the driver will soon have real descriptor chains, and the DMA
descriptor chain register updates itself to point to the current
descriptor being proces
The IPU scaling information is computed in the plane's ".atomic_check"
callback, and used in the ".atomic_update" callback. As such, it is
state-specific, and should be moved to a private state structure.
Signed-off-by: Paul Cercueil
---
drivers/gpu/drm/ingenic/ingenic-ipu.c | 73 +++
Until now, the ingenic-drm as well as the ingenic-ipu drivers used to
put state-specific information in their respective private structure.
Add boilerplate code to support private objects in the two drivers, so
that state-specific information can be put in the state-specific private
structure.
Si
Instead of having one 'hwdesc' variable for the plane #0, one for the
plane #1 and one for the palette, use a 'hwdesc[3]' array, where the
DMA hardware descriptors are indexed by the plane's number.
v2: dma_hwdesc_addr() extended to support palette hwdesc. The palette
hwdesc is now hwdesc[3] t
Hi,
A V3 of my patchset for the ingenic-drm driver.
The patches "drm/ingenic: Remove dead code" and
"drm/ingenic: Use standard drm_atomic_helper_commit_tail"
that were present in V1 have been merged in drm-misc-next,
so they are not in this V3.
Changelog since V2:
[PATCH 5/6]:
Fix ingenic_d
On Wed, Sep 22, 2021 at 1:19 PM Sudip Mukherjee
wrote:
>
> I added some debugs to print the addresses, and I am getting:
> [ 38.813809] sudip crtc
>
> This is from struct drm_crtc *crtc = connector->state->crtc;
Yeah, that was my personal suspicion, because while the line numbe
On Wed, Sep 22, 2021 at 7:23 PM Linus Torvalds
wrote:
>
> On Wed, Sep 22, 2021 at 10:02 AM Sudip Mukherjee
> wrote:
> >
> >
> > Attached is a complete dmesg and also the decoded trace.
> > This is done on 4357f03d6611 ("Merge tag 'pm-5.15-rc2' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/
As reported at [1] Coverity complains about an used value.
Let's make drm_connector a pointer in struct rockchip_rgb and "remove
redundant assignment of pointer connector".
[1] https://lkml.org/lkml/2021/9/22/432
Fixes: 2e87bf389e13 ("drm/rockchip: add DRM_BRIDGE_ATTACH_NO_CONNECTOR flag to
drm
On 9/22/2021 09:25, Matthew Brost wrote:
On Mon, Sep 20, 2021 at 02:48:52PM -0700, John Harrison wrote:
On 8/20/2021 15:44, Matthew Brost wrote:
Implement multi-lrc submission via a single workqueue entry and single
H2G. The workqueue entry contains an updated tail value for each
request, of al
On Wed, Sep 22, 2021 at 05:30:15PM +0300, Kirill A. Shutemov wrote:
> Not fine, but waiting to blowup with random build environment change.
Why is it not fine?
Are you suspecting that the compiler might generate something else and
not a rip-relative access?
--
Regards/Gruss,
Boris.
https:/
Set number of engines before attempting to create contexts so the
function free_engines can clean up properly. Also check return of
alloc_engines for NULL.
v2:
(Tvrtko)
- Send as stand alone patch
(John Harrison)
- Check for alloc_engines returning NULL
Cc: Jason Ekstrand
Fixes: d4433c7600
Hi all,
Am 22.09.21 um 19:31 schrieb Alex Bee:
Hi Heiko,
Am 22.09.21 um 18:45 schrieb Heiko Stübner:
Hi Alex,
Am Mittwoch, 22. September 2021, 18:35:38 CEST schrieb Alex Bee:
Hi Colin,
Am 22.09.21 um 13:24 schrieb Colin King:
From: Colin Ian King
The pointer connector is being assigned a
On Wed, Sep 22, 2021 at 10:02 AM Sudip Mukherjee
wrote:
>
>
> Attached is a complete dmesg and also the decoded trace.
> This is done on 4357f03d6611 ("Merge tag 'pm-5.15-rc2' of
> git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm")
drivers/gpu/drm/vc4/vc4_hdmi.c:1214 is
tmp
Hi Laurent,
On Wed, Sep 22, 2021 at 10:08 AM Laurent Pinchart
wrote:
> On Wed, Sep 22, 2021 at 08:43:57AM +0200, Geert Uytterhoeven wrote:
> > On Wed, Sep 22, 2021 at 3:27 AM Laurent Pinchart wrote:
> > > On Tue, Sep 21, 2021 at 05:53:52PM +0200, Geert Uytterhoeven wrote:
> > > > On Wed, Jul 28,
Hi Kieran,
Thank you for the patch.
On Thu, Sep 02, 2021 at 12:49:06AM +0100, Kieran Bingham wrote:
> Not all platforms require both per-crtc IRQ and per-crtc clock
> management. In preparation for suppporting such platforms, split the
> feature macro to be able to specify both features independe
[Why]
For some reason we're defining DP 2.0 definitions inside our
driver. Now that patches to introduce relevant definitions
are slated to be merged into drm-next this is causing conflicts.
In file included from drivers/gpu/drm/amd/amdgpu/amdgpu_bo_list.c:33:
In file included from ./drivers/gpu/d
Hi Heiko,
Am 22.09.21 um 18:45 schrieb Heiko Stübner:
Hi Alex,
Am Mittwoch, 22. September 2021, 18:35:38 CEST schrieb Alex Bee:
Hi Colin,
Am 22.09.21 um 13:24 schrieb Colin King:
From: Colin Ian King
The pointer connector is being assigned a value that is never
read, it is being updated imm
Hi Kieran,
Thank you for the patch.
On Thu, Sep 02, 2021 at 12:49:05AM +0100, Kieran Bingham wrote:
> The DIDSR fields named LDCS were incorrectly defined as LCDS.
> Both the Gen2 and Gen3 documentation refer to the fields as the "LVDS
> Dot Clock Select".
>
> Correct the definitions.
>
> Signe
On Wed, Sep 22, 2021 at 12:28 PM Maxime Ripard wrote:
>
> On Wed, Sep 22, 2021 at 11:10:34AM +0100, Sudip Mukherjee wrote:
> > On Wed, Sep 22, 2021 at 10:57 AM Maxime Ripard wrote:
> > >
>
> Still works fine (and it required some mangling of the kernel command line).
>
> If we summarize:
>
>
On Wed, Sep 22, 2021 at 4:25 PM Linus Torvalds
wrote:
>
> On Wed, Sep 22, 2021 at 3:11 AM Sudip Mukherjee
> wrote:
> >
> > That test script is triggering the openqa job, but its running only
> > after lava is able to login. The trace is appearing before the login
> > prompt even, so test_mainline
Hi Alex,
Am Mittwoch, 22. September 2021, 18:35:38 CEST schrieb Alex Bee:
> Hi Colin,
> Am 22.09.21 um 13:24 schrieb Colin King:
> > From: Colin Ian King
> >
> > The pointer connector is being assigned a value that is never
> > read, it is being updated immediately afterwards. The assignment
> >
On Mon, Sep 20, 2021 at 05:09:28PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Introduce 'set parallel submit' extension to connect UAPI to GuC
> > multi-lrc interface. Kernel doc in new uAPI should explain it all.
> >
> > IGT: https://patchwork.freedesktop.org/patch
Hi Colin,
Am 22.09.21 um 13:24 schrieb Colin King:
From: Colin Ian King
The pointer connector is being assigned a value that is never
read, it is being updated immediately afterwards. The assignment
is redundant and can be removed.
The pointer to the connector is used in rockchip_rgb_fini for
On Mon, Sep 20, 2021 at 02:48:52PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
> > Implement multi-lrc submission via a single workqueue entry and single
> > H2G. The workqueue entry contains an updated tail value for each
> > request, of all the contexts in the multi-lrc
On Mon, Sep 20, 2021 at 03:44:18PM -0700, John Harrison wrote:
> On 8/20/2021 15:44, Matthew Brost wrote:
>
> Update context and full GPU reset to work with multi-lrc. The idea is
> parent context tracks all the active requests inflight for itself and
> its' children. The parent contex
Hi, Guillaume:
Rob Herring 於 2021年9月7日 週二 下午10:51寫道：
>
> On Tue, 07 Sep 2021 10:37:21 +0200, Guillaume Ranquet wrote:
> > Add Mediatek HDMI and HDMI-DDC bindings for MT8195 SoC.
Move this patch before the driver patch which refer to this patch.
> >
> > Signed-off-by: Guillaume Ranquet
> > ---
Hi, Guillaume:
Guillaume Ranquet 於 2021年9月7日 週二 下午4:39寫道：
>
> Add bindings to describe Mediatek MT8195 HDMI PHY
Move this patch before the driver patch which reference this patch.
>
> Signed-off-by: Guillaume Ranquet
> ---
> .../phy/mediatek,mtk8195-hdmi-phy.yaml| 71 +
Rather than stealing bits from i915_sw_fence function pointer use
seperate fields for function pointer and flags. If using two different
fields, the 4 byte alignment for the i915_sw_fence function pointer can
also be dropped.
v2:
(CI)
- Set new function field rather than flags in __i915_sw_fenc
From: Tvrtko Ursulin
Make GEM contexts keep a reference to i915_drm_client for the whole of
of their lifetime which will come handy in following patches.
v2: Don't bother supporting selftests contexts from debugfs. (Chris)
v3 (Lucas): Finish constructing ctx before adding it to the list
v4 (Ram)
From: Tvrtko Ursulin
As contexts are abandoned we want to remember how much GPU time they used
(per class) so later we can used it for smarter purposes.
As GEM contexts are closed we want to have the DRM client remember how
much GPU time they used (per class) so later we can used it for smarter
From: Tvrtko Ursulin
Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.
Example of the output:
pos:0
flags: 012
mnt_id: 21
drm-driver:
From: Tvrtko Ursulin
Track context active (on hardware) status together with the start
timestamp.
This will be used to provide better granularity of context
runtime reporting in conjunction with already tracked pphwsp accumulated
runtime.
The latter is only updated on context save so does not g
From: Tvrtko Ursulin
Proposal to standardise the fdinfo text format as optionally output by DRM
drivers.
Idea is that a simple but, well defined, spec will enable generic
userspace tools to be written while at the same time avoiding a more heavy
handed approach of adding a mid-layer to DRM.
i91
From: Tvrtko Ursulin
Tracking DRM clients more explicitly will allow later patches to
accumulate past and current GPU usage in a centralised place and also
consolidate access to owning task pid/name.
Unique client id is also assigned for the purpose of distinguishing/
consolidating between multi
From: Tvrtko Ursulin
We soon want to start answering questions like how much GPU time is the
context belonging to a client which exited still using.
To enable this we start tracking all context belonging to a client on a
separate list.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamse
From: Tvrtko Ursulin
Same old work but now rebased and series ending with some DRM docs proposing
the common specification which should enable nice common userspace tools to be
written.
For the moment I only have intel_gpu_top converted to use this and that seems to
work okay.
v2:
* Added prot
On Wed, Sep 22, 2021 at 10:41:56AM +0200, Maxime Ripard wrote:
> Hi Randy,
>
> On Sun, Sep 19, 2021 at 09:40:44AM -0700, Randy Dunlap wrote:
> > On 8/19/21 6:59 AM, Maxime Ripard wrote:
> > > We already depend on runtime PM to get the power domains and clocks for
> > > most of the devices supporte
On Wed, Sep 22, 2021 at 04:25:04PM +0100, Tvrtko Ursulin wrote:
>
> On 22/09/2021 16:21, Tvrtko Ursulin wrote:
> >
> > On 22/09/2021 15:57, Matthew Brost wrote:
> > > Rather than stealing bits from i915_sw_fence function pointer use
> > > seperate fields for function pointer and flags. If using t
Maybe try creating multiple physical seats with logind, and start each
compositor on its own seat? A physical seat is a collection of devices like
DRM nodes and evdev device files.
Also udev creates files in /dev/dri/by-path/, these should be stable across
reboots. `udevadm settle` before a compos
On 2021-09-22 04:31, Pekka Paalanen wrote:
> On Tue, 21 Sep 2021 14:05:05 -0400
> Harry Wentland wrote:
>
>> On 2021-09-21 09:31, Pekka Paalanen wrote:
>>> On Mon, 20 Sep 2021 20:14:50 -0400
>>> Harry Wentland wrote:
>>>
...
>
>> Did anybody start any CM doc patches in Weston or Wayland
On Wed, Sep 22, 2021 at 3:11 AM Sudip Mukherjee
wrote:
>
> That test script is triggering the openqa job, but its running only
> after lava is able to login. The trace is appearing before the login
> prompt even, so test_mainline.sh should not matter here.
Side note: the traces might be more legi
On 22/09/2021 16:21, Tvrtko Ursulin wrote:
On 22/09/2021 15:57, Matthew Brost wrote:
Rather than stealing bits from i915_sw_fence function pointer use
seperate fields for function pointer and flags. If using two different
fields, the 4 byte alignment for the i915_sw_fence function pointer can
On 22/09/2021 15:57, Matthew Brost wrote:
Rather than stealing bits from i915_sw_fence function pointer use
seperate fields for function pointer and flags. If using two different
fields, the 4 byte alignment for the i915_sw_fence function pointer can
also be dropped.
v2:
(CI)
- Set new fu
Currently autoloading for SPI devices does not use the DT ID table, it uses
SPI modalises. Supporting OF modalises is going to be difficult if not
impractical, an attempt was made but has been reverted, so ensure that
module autoloading works for this driver by adding a SPI device ID table.
Fixes:
On 22/09/2021 15:50, Christian König wrote:
Am 22.09.21 um 16:36 schrieb Tvrtko Ursulin:
+
+/**
+ * dma_resv_iter_first_unlocked - first fence in an unlocked
dma_resv obj.
+ * @cursor: the cursor with the current position
+ *
+ * Returns the first fence from an unlocked dma_resv obj.
+ */
+s
On 2021-09-20 20:14, Harry Wentland wrote:
> On 2021-09-15 10:01, Pekka Paalanen wrote:> On Fri, 30 Jul 2021 16:41:29 -0400
>> Harry Wentland wrote:
>>
>>> +If a display's maximum HDR white level is correctly reported it is trivial
>>> +to convert between all of the above representations of
Rather than stealing bits from i915_sw_fence function pointer use
seperate fields for function pointer and flags. If using two different
fields, the 4 byte alignment for the i915_sw_fence function pointer can
also be dropped.
v2:
(CI)
- Set new function field rather than flags in __i915_sw_fenc
On Wed, Sep 22, 2021 at 7:31 AM Andrey Grodzovsky
wrote:
>
>
> On 2021-09-21 11:32 p.m., Rob Clark wrote:
> > On Tue, Sep 21, 2021 at 7:18 PM Andrey Grodzovsky
> > wrote:
> >>
> >> On 2021-09-21 4:47 p.m., Rob Clark wrote:
> >>> On Tue, Sep 21, 2021 at 1:09 PM Andrey Grodzovsky
> >>> wrote:
> >>
Am 22.09.21 um 16:36 schrieb Tvrtko Ursulin:
+
+/**
+ * dma_resv_iter_first_unlocked - first fence in an unlocked
dma_resv obj.
+ * @cursor: the cursor with the current position
+ *
+ * Returns the first fence from an unlocked dma_resv obj.
+ */
+struct dma_fence *dma_resv_iter_first_unlocked(s
On Tue, 14 Sep 2021, Paul Kocialkowski wrote:
> The LogiCVC multi-function device has a display part which is now
> described in its binding. Add a patternProperties match for it.
>
> Signed-off-by: Paul Kocialkowski
> ---
> Documentation/devicetree/bindings/mfd/xylon,logicvc.yaml | 3 +++
> 1
On 22/09/2021 15:31, Christian König wrote:
Am 22.09.21 um 12:21 schrieb Tvrtko Ursulin:
On 22/09/2021 10:10, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i
On 22/09/2021 10:10, Christian König wrote:
Abstract the complexity of iterating over all the fences
in a dma_resv object.
The new loop handles the whole RCU and retry dance and
returns only fences where we can be sure we grabbed the
right one.
v2: fix accessing the shared fences while they m
On Wed, Sep 22, 2021 at 08:40:43AM -0500, Tom Lendacky wrote:
> On 9/21/21 4:58 PM, Kirill A. Shutemov wrote:
> > On Tue, Sep 21, 2021 at 04:43:59PM -0500, Tom Lendacky wrote:
> > > On 9/21/21 4:34 PM, Kirill A. Shutemov wrote:
> > > > On Tue, Sep 21, 2021 at 11:27:17PM +0200, Borislav Petkov wrote
On 2021-09-21 11:32 p.m., Rob Clark wrote:
On Tue, Sep 21, 2021 at 7:18 PM Andrey Grodzovsky
wrote:
On 2021-09-21 4:47 p.m., Rob Clark wrote:
On Tue, Sep 21, 2021 at 1:09 PM Andrey Grodzovsky
wrote:
On 2021-09-03 2:47 p.m., Rob Clark wrote:
From: Rob Clark
As the finished fence is the
Am 22.09.21 um 12:21 schrieb Tvrtko Ursulin:
On 22/09/2021 10:10, Christian König wrote:
This makes the function much simpler since the complex
retry logic is now handled else where.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_busy.c | 35 ++--
On Mon, Sep 20, 2021 at 4:10 PM Thomas Zimmermann wrote:
>
> Switch gma500 to managed cleanup and remove the manual cleanup
> code from the driver's PCI callbacks.
>
> Managed cleanup involves embedding the DRM device structure in the
> driver's structure. In preparation, patch 1 replaces referenc
1 - 100 of 182 matches
Mail list logo
