[PATCH v2] drm/rockchip: cdn-dp-core: Fix cdn_dp_resume unused warning

2021-09-10 Thread Palmer Dabbelt
From: Palmer Dabbelt cdn_dp_resume is only used under PM_SLEEP, and now that it's static an unused function warning is triggered undner !PM_SLEEP. This marks the function as possibly unused, to avoid triggering compiler warnings. Fixes: 7c49abb4c2f8 ("drm/rockchip: cdn-dp-core: Make

Intel UHD resolutions

2021-09-10 Thread Randy Dunlap
Hi, I would like to use QHD resolution (2560x1440) with my shiny new computer and display. That resolution works if I boot Windows 10 (cough). What do I need to do to use that resolution in Linux? I first tried openSUSE 15.3 (kernel 5.3.18-59.19-default) then I build a v5.14 kernel and tried

[PATCH] drm/i915: fix odd_ptr_err.cocci warnings

2021-09-10 Thread kernel test robot
that is wrong. Generated by: scripts/coccinelle/tests/odd_ptr_err.cocci CC: Maarten Lankhorst Reported-by: kernel test robot Signed-off-by: kernel test robot --- url: https://github.com/0day-ci/linux/commits/Maarten-Lankhorst/drm-i915-Add-ww-context-to-intel_dpt_pin/20210910-162231 base: git

Re: [Intel-gfx] [PATCH 3/4] drm/i915: rename debugfs_gt_pm files

2021-09-10 Thread Yokoyama, Caz
On Fri, 2021-09-10 at 14:52 -0700, Lucas De Marchi wrote: > On Fri, Sep 10, 2021 at 09:14:37PM +, Yokoyama, Caz wrote: > > On Fri, 2021-09-10 at 10:52 -0700, Lucas De Marchi wrote: > > > On Wed, Sep 08, 2021 at 05:49:40PM -0700, Lucas De Marchi wrote: > > > > We shouldn't be using debugfs_

Re: [Intel-gfx] [PATCH v9 15/17] drm/i915/pxp: add pxp debugfs

2021-09-10 Thread Teres Alexis, Alan Previn
Reviewed-by: Alan Previn ..alan On Fri, 2021-09-10 at 08:36 -0700, Daniele Ceraolo Spurio wrote: > 2 debugfs files, one to query the current status of the pxp session and one > to trigger an invalidation for testing. > > v2: rename debugfs, fix date (Alan) > > Signed-off-by: Daniele Ceraolo

Re: [PATCH] drm/rockchip: Update crtc fixup to account for fractional clk change

2021-09-10 Thread Chris Morgan
On Wed, Sep 08, 2021 at 09:05:52PM +0300, Andy Shevchenko wrote: > On Wed, Sep 08, 2021 at 08:53:56AM -0500, Chris Morgan wrote: > > From: Chris Morgan > > > > After commit 928f9e268611 ("clk: fractional-divider: Hide > > clk_fractional_divider_ops from wide audience") was merged it appears > >

Re: [Intel-gfx] [PATCH 3/4] drm/i915: rename debugfs_gt_pm files

2021-09-10 Thread Lucas De Marchi
On Fri, Sep 10, 2021 at 09:14:37PM +, Yokoyama, Caz wrote: On Fri, 2021-09-10 at 10:52 -0700, Lucas De Marchi wrote: On Wed, Sep 08, 2021 at 05:49:40PM -0700, Lucas De Marchi wrote: > We shouldn't be using debugfs_ namespace for this functionality. > Rename > debugfs_gt_pm.[ch] to

Re: [PATCH 2/2] drm/msm/dpu: Fix timeout issues on command mode panels

2021-09-10 Thread Marijn Suijten
Hi Angelo! On 2021-09-01 19:43:47, AngeloGioacchino Del Regno wrote: > In function dpu_encoder_phys_cmd_wait_for_commit_done we are always > checking if the relative CTL is started by waiting for an interrupt > to fire: it is fine to do that, but then sometimes we call this > function while the

Re: [Intel-gfx] [PATCH 3/4] drm/i915: rename debugfs_gt_pm files

2021-09-10 Thread Yokoyama, Caz
On Fri, 2021-09-10 at 10:52 -0700, Lucas De Marchi wrote: > On Wed, Sep 08, 2021 at 05:49:40PM -0700, Lucas De Marchi wrote: > > We shouldn't be using debugfs_ namespace for this functionality. > > Rename > > debugfs_gt_pm.[ch] to intel_gt_pm_debugfs.[ch] and then make > > functions, defines and

Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc

2021-09-10 Thread Matthew Brost
On Fri, Sep 10, 2021 at 12:25:43PM +0100, Tvrtko Ursulin wrote: > > On 20/08/2021 23:44, Matthew Brost wrote: > > For some users of multi-lrc, e.g. split frame, it isn't safe to preempt > > mid BB. To safely enable preemption at the BB boundary, a handshake > > between to parent and child is

Re: [Intel-gfx] [PATCH 05/27] drm/i915: Add GT PM unpark worker

2021-09-10 Thread Matthew Brost
On Fri, Sep 10, 2021 at 09:36:17AM +0100, Tvrtko Ursulin wrote: > > On 20/08/2021 23:44, Matthew Brost wrote: > > Sometimes it is desirable to queue work up for later if the GT PM isn't > > held and run that work on next GT PM unpark. > > Sounds maybe plausible, but it depends how much work can

[PATCH v2 3/6] drm/i915/uncore: Replace gen8 write functions with general fwtable

2021-09-10 Thread Matt Roper
Now that we have both a standard forcewake table (albeit a single-entry table) and the shadow table stored in the uncore, we can drop the gen8-specific write handlers in favor of the general fwtable version. Signed-off-by: Matt Roper --- drivers/gpu/drm/i915/intel_uncore.c | 13 + 1

[PATCH v2 6/6] drm/i915/dg2: Add DG2-specific shadow register table

2021-09-10 Thread Matt Roper
We thought the DG2 table of shadowed registers would be the same as the gen12/xehp table, but it turns out that there are a few minor differences that require us to define a new DG2-specific table: * One register is removed (0xC4D4) * One register is added (0xC4E0) Signed-off-by: Matt Roper

[PATCH v2 5/6] drm/i915/uncore: Drop gen11 mmio read handlers

2021-09-10 Thread Matt Roper
Consolidate down to just a single 'fwtable' implementation. For reads we don't need to worry about shadow tables. Also, the NEEDS_FORCE_WAKE() check we previously had in the fwtable implementation can be dropped --- if a register is outside that range on one of the old platforms, then it won't

[PATCH v2 2/6] drm/i915/uncore: Associate shadow table with uncore

2021-09-10 Thread Matt Roper
Store a reference to a platform's shadow table inside the uncore, the same as we do with the forcewake table. This will allow us to use a single set of functions that operate on the shadow table reference rather than generating lots of nearly-identical functions via macros that differ only in

[PATCH v2 4/6] drm/i915/uncore: Drop gen11/gen12 mmio write handlers

2021-09-10 Thread Matt Roper
Now that the reference to the shadow table is stored within the uncore, we don't need to generate separate fwtable, gen11_fwtable, and gen12_fwtable variants of the register write functions; a single 'fwtable' implementation will work for all of those platforms now. While consolidating the

[PATCH v2 1/6] drm/i915/uncore: Convert gen6/gen7 read operations to fwtable

2021-09-10 Thread Matt Roper
On gen6-gen8 (except vlv/chv) we don't use a forcewake lookup table; we simply check whether the register offset is < 0x4, and return FORCEWAKE_RENDER if it is. To prepare for upcoming refactoring, let's define a single-entry forcewake table from [0x0, 0x3] and switch these platforms over

[PATCH v2 0/6] i915: Simplify mmio handling & add new DG2 shadow table

2021-09-10 Thread Matt Roper
Our uncore MMIO functions for reading/writing registers have become very complicated over time. There's significant macro magic used to generate several nearly-identical functions that only really differ in terms of which platform-specific shadow register table they should check on write

Re: [Intel-gfx] [PATCH 08/27] drm/i915: Add logical engine mapping

2021-09-10 Thread Matthew Brost
On Fri, Sep 10, 2021 at 12:12:42PM +0100, Tvrtko Ursulin wrote: > > On 20/08/2021 23:44, Matthew Brost wrote: > > Add logical engine mapping. This is required for split-frame, as > > workloads need to be placed on engines in a logically contiguous manner. > > > > v2: > > (Daniel Vetter) > >

[PATCH 1/1] drm/amdkfd: Add sysfs bitfields and enums to uAPI

2021-09-10 Thread Felix Kuehling
These bits are de-facto part of the uAPI, so declare them in a uAPI header. Signed-off-by: Felix Kuehling --- MAINTAINERS | 1 + drivers/gpu/drm/amd/amdkfd/kfd_topology.h | 46 + include/uapi/linux/kfd_sysfs.h| 108 ++ 3

Re: [virtio-dev] [PATCH v1 09/12] drm/virtio: implement context init: allocate an array of fence contexts

2021-09-10 Thread Chia-I Wu
On Wed, Sep 8, 2021 at 6:37 PM Gurchetan Singh wrote: > > We don't want fences from different 3D contexts (virgl, gfxstream, > venus) to be on the same timeline. With explicit context creation, > we can specify the number of ring each context wants. > > Execbuffer can specify which ring to use.

Re: [git pull] drm fixes for 5.15-rc1

2021-09-10 Thread pr-tracker-bot
The pull request you sent on Fri, 10 Sep 2021 16:35:59 +1000: > git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-09-10 has been merged into torvalds/linux.git: https://git.kernel.org/torvalds/c/a668acb8f01fc0d1e3877cddecbe319ef2ef651c Thank you! -- Deet-doot-dot, I am a bot.

Re: [Intel-gfx] [PATCH v9 05/17] drm/i915/pxp: Implement funcs to create the TEE channel

2021-09-10 Thread Rodrigo Vivi
On Fri, Sep 10, 2021 at 08:36:15AM -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

Re: [PATCH v9 10/17] drm/i915/pxp: interfaces for using protected objects

2021-09-10 Thread Rodrigo Vivi
On Fri, Sep 10, 2021 at 08:36:20AM -0700, Daniele Ceraolo Spurio wrote: > This api allow user mode to create protected buffers and to mark > contexts as making use of such objects. Only when using contexts > marked in such a way is the execution guaranteed to work as expected. > > Contexts can

Re: [Intel-gfx] [PATCH v9 16/17] drm/i915/pxp: add PXP documentation

2021-09-10 Thread Rodrigo Vivi
On Fri, Sep 10, 2021 at 08:36:26AM -0700, Daniele Ceraolo Spurio wrote: > Now that all the pieces are in place we can add a description of how the > feature works. Also modify the comments in struct intel_pxp into > kerneldoc. > > v2: improve doc (Rodrigo) > > Signed-off-by: Daniele Ceraolo

Re: [PATCH] drm/ttm: add a WARN_ON in ttm_set_driver_manager when array bounds (v2)

2021-09-10 Thread Robin Murphy
On 2021-09-10 11:09, Guchun Chen wrote: Vendor will define their own memory types on top of TTM_PL_PRIV, but call ttm_set_driver_manager directly without checking mem_type value when setting up memory manager. So add such check to aware the case when array bounds. v2: lower check level to

Re: [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

2021-09-10 Thread Mark Brown
On Thu, Sep 09, 2021 at 11:32:18AM +0200, Maarten Lankhorst wrote: > This is also useful in regulator_lock_nested, which may avoid dropping > regulator_nesting_mutex in the uncontended path, so use it there. Acked-by: Mark Brown signature.asc Description: PGP signature

Re: [Intel-gfx] [PATCH 3/4] drm/i915: rename debugfs_gt_pm files

2021-09-10 Thread Lucas De Marchi
On Wed, Sep 08, 2021 at 05:49:40PM -0700, Lucas De Marchi wrote: We shouldn't be using debugfs_ namespace for this functionality. Rename debugfs_gt_pm.[ch] to intel_gt_pm_debugfs.[ch] and then make functions, defines and structs follow suit. Signed-off-by: Lucas De Marchi ---

Re: [PATCH] drm/msm: Disable frequency clamping on a630

2021-09-10 Thread Caleb Connolly
On 10/09/2021 18:18, Rob Clark wrote: On Tue, Sep 7, 2021 at 7:20 PM Bjorn Andersson wrote: On Mon 09 Aug 10:26 PDT 2021, Akhil P Oommen wrote: On 8/9/2021 9:48 PM, Caleb Connolly wrote: On 09/08/2021 17:12, Rob Clark wrote: On Mon, Aug 9, 2021 at 7:52 AM Akhil P Oommen wrote: [..]

Re: [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

2021-09-10 Thread Peter Zijlstra
On Fri, Sep 10, 2021 at 05:02:54PM +0200, Peter Zijlstra wrote: > That doesn't look right, how's this for you? Full patch for the robots here: https://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git/commit/?h=locking/core=826e7b8826f0af185bb93249600533c33fd69a95

Re: [PATCH] drm/msm: Disable frequency clamping on a630

2021-09-10 Thread Rob Clark
On Thu, Sep 9, 2021 at 1:54 PM Rob Clark wrote: > > On Thu, Sep 9, 2021 at 12:50 PM Akhil P Oommen wrote: > > > > On 9/9/2021 9:42 PM, Amit Pundir wrote: > > > On Thu, 9 Sept 2021 at 17:47, Amit Pundir wrote: > > >> > > >> On Wed, 8 Sept 2021 at 07:50, Bjorn Andersson > > >> wrote: > > >>> > >

Re: [PATCH] drm/msm: Disable frequency clamping on a630

2021-09-10 Thread Rob Clark
On Tue, Sep 7, 2021 at 7:20 PM Bjorn Andersson wrote: > > On Mon 09 Aug 10:26 PDT 2021, Akhil P Oommen wrote: > > > On 8/9/2021 9:48 PM, Caleb Connolly wrote: > > > > > > > > > On 09/08/2021 17:12, Rob Clark wrote: > > > > On Mon, Aug 9, 2021 at 7:52 AM Akhil P Oommen > > > > wrote: > [..] > > >

Re: [PATCH] dt-bindings: More use 'enum' instead of 'oneOf' plus 'const' entries

2021-09-10 Thread Guenter Roeck
On 9/10/21 9:51 AM, Rob Herring wrote: 'enum' is equivalent to 'oneOf' with a list of 'const' entries, but 'enum' is more concise and yields better error messages. Fix a couple more cases which have appeared. Cc: Rob Clark Cc: Sean Paul Cc: Mark Brown Cc: Wim Van Sebroeck Cc: Guenter Roeck

Re: [RFC PATCH] drm/ttm: Add a private member to the struct ttm_resource

2021-09-10 Thread Christian König
Am 10.09.21 um 17:30 schrieb Thomas Hellström: On Fri, 2021-09-10 at 16:40 +0200, Christian König wrote: Am 10.09.21 um 15:15 schrieb Thomas Hellström: Both the provider (resource manager) and the consumer (the TTM driver) want to subclass struct ttm_resource. Since this is left for the

[PATCH] video: fbdev: atyfb: Remove assigned but never used variable statements

2021-09-10 Thread Colin King
From: Colin Ian King There are a couple of statements where local variables are being assigned values that are never read because the function returns immediately after the assignment. Clean up the code by removing them. Addresses-Coverity: ("Unused value") Signed-off-by: Colin Ian King ---

Re: [PATCH] dt-bindings: More use 'enum' instead of 'oneOf' plus 'const' entries

2021-09-10 Thread Mark Brown
On Fri, Sep 10, 2021 at 11:51:53AM -0500, Rob Herring wrote: > 'enum' is equivalent to 'oneOf' with a list of 'const' entries, but 'enum' > is more concise and yields better error messages. Acked-by: Mark Brown signature.asc Description: PGP signature

[PATCH] dt-bindings: More use 'enum' instead of 'oneOf' plus 'const' entries

2021-09-10 Thread Rob Herring
'enum' is equivalent to 'oneOf' with a list of 'const' entries, but 'enum' is more concise and yields better error messages. Fix a couple more cases which have appeared. Cc: Rob Clark Cc: Sean Paul Cc: Mark Brown Cc: Wim Van Sebroeck Cc: Guenter Roeck Cc: Jonathan Marek Cc: Aswath

Re: [RFC PATCH 0/4] Allow to use DRM fbdev emulation layer with CONFIG_FB disabled

2021-09-10 Thread Sam Ravnborg
Hi Noralf, On Thu, Sep 09, 2021 at 06:27:02PM +0200, Noralf Trønnes wrote: > > > > Hi Daniel, > > > > > > > > > > > I think for a substantial improvement here in robustness what you > really > > > > want is > > > > - kmscon in userspace > > > > - disable FB layer > > > > - ideally also disable

Re: Habanalabs Open-Source TPC LLVM compiler and SynapseAI Core library

2021-09-10 Thread Daniel Vetter
Forgot to add dri-devel. On Fri, Sep 10, 2021 at 6:09 PM Daniel Vetter wrote: > > On Fri, Sep 10, 2021 at 9:58 AM Greg Kroah-Hartman > wrote: > > On Fri, Sep 10, 2021 at 10:26:56AM +0300, Oded Gabbay wrote: > > > Hi Greg, > > > > > > Following our conversations a couple of months ago, I'm happy

Re: [PATCH v2 5/9] vfio/mdev: Consolidate all the device_api sysfs into the core code

2021-09-10 Thread Alex Williamson
On Fri, 10 Sep 2021 10:38:50 -0300 Jason Gunthorpe wrote: > On Fri, Sep 10, 2021 at 01:10:46PM +0100, Christoph Hellwig wrote: > > On Thu, Sep 09, 2021 at 04:38:45PM -0300, Jason Gunthorpe wrote: > > > Every driver just emits a static string, simply feed it through the ops > > > and provide a

[PATCH v9 15/17] drm/i915/pxp: add pxp debugfs

2021-09-10 Thread Daniele Ceraolo Spurio
2 debugfs files, one to query the current status of the pxp session and one to trigger an invalidation for testing. v2: rename debugfs, fix date (Alan) Signed-off-by: Daniele Ceraolo Spurio Reviewed-by : Alan Previn --- drivers/gpu/drm/i915/Makefile| 1 +

[PATCH v9 16/17] drm/i915/pxp: add PXP documentation

2021-09-10 Thread Daniele Ceraolo Spurio
Now that all the pieces are in place we can add a description of how the feature works. Also modify the comments in struct intel_pxp into kerneldoc. v2: improve doc (Rodrigo) Signed-off-by: Daniele Ceraolo Spurio Cc: Daniel Vetter Cc: Rodrigo Vivi --- Documentation/gpu/i915.rst

[PATCH v9 12/17] drm/i915/pxp: Enable PXP power management

2021-09-10 Thread Daniele Ceraolo Spurio
From: "Huang, Sean Z" During the power event S3+ sleep/resume, hardware will lose all the encryption keys for every hardware session, even though the session state might still be marked as alive after resume. Therefore, we should consider the session as dead on suspend and invalidate all the

[PATCH v9 13/17] drm/i915/pxp: Add plane decryption support

2021-09-10 Thread Daniele Ceraolo Spurio
From: Anshuman Gupta Add support to enable/disable PLANE_SURF Decryption Request bit. It requires only to enable plane decryption support when following condition met. 1. PXP session is enabled. 2. Buffer object is protected. v2: - Used gen fb obj user_flags instead gem_object_metadata.

[PATCH v9 09/17] drm/i915/pxp: Implement PXP irq handler

2021-09-10 Thread Daniele Ceraolo Spurio
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 another interrupt, at which point it is safe to re-create the session. Since the

[PATCH v9 11/17] drm/i915/pxp: start the arb session on demand

2021-09-10 Thread Daniele Ceraolo Spurio
Now that we can handle destruction and re-creation of the arb session, we can postpone the start of the session to the first submission that requires it, to avoid keeping it running with no user. Signed-off-by: Daniele Ceraolo Spurio Reviewed-by: Rodrigo Vivi ---

[PATCH v9 17/17] drm/i915/pxp: enable PXP for integrated Gen12

2021-09-10 Thread Daniele Ceraolo Spurio
Note that discrete cards can support PXP as well, but we haven't tested on those yet so keeping it disabled for now. Signed-off-by: Daniele Ceraolo Spurio Reviewed-by: Rodrigo Vivi --- drivers/gpu/drm/i915/i915_pci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

[PATCH v9 14/17] drm/i915/pxp: black pixels on pxp disabled

2021-09-10 Thread Daniele Ceraolo Spurio
From: Anshuman Gupta When protected sufaces has flipped and pxp session is disabled, display black pixels by using plane color CTM correction. v2: - Display black pixels in async flip too. v3: - Removed the black pixels logic for async flip. [Ville] - Used plane state to force black pixels.

[PATCH v9 10/17] drm/i915/pxp: interfaces for using protected objects

2021-09-10 Thread Daniele Ceraolo Spurio
This api allow user mode to create protected buffers and to mark contexts as making use of such objects. Only when using contexts marked in such a way is the execution guaranteed to work as expected. Contexts can only be marked as using protected content at creation time (i.e. the parameter is

[PATCH v9 08/17] drm/i915/pxp: Implement arb session teardown

2021-09-10 Thread Daniele Ceraolo Spurio
From: "Huang, Sean Z" Teardown is triggered when the display topology changes and no long meets the secure playback requirement, and hardware trashes all the encryption keys for display. Additionally, we want to emit a teardown operation to make sure we're clean on boot and resume v2: emit in

[PATCH v9 06/17] drm/i915/pxp: set KCR reg init

2021-09-10 Thread Daniele Ceraolo Spurio
The setting is required by hardware to allow us doing further protection operation such as sending commands to GPU or TEE. The register needs to be re-programmed on resume, so for simplicitly we bundle the programming with the component binding, which is automatically called on resume. Further HW

[PATCH v9 07/17] drm/i915/pxp: Create the arbitrary session after boot

2021-09-10 Thread Daniele Ceraolo Spurio
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. Because the hardware requires at least one alive session for protected buffer creation.

[PATCH v9 05/17] drm/i915/pxp: Implement funcs to create the TEE channel

2021-09-10 Thread Daniele Ceraolo Spurio
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 (Chris) v3: wait for mei PXP component to be bound. v4: drop the wait, as the

[PATCH v9 04/17] drm/i915/pxp: allocate a vcs context for pxp usage

2021-09-10 Thread Daniele Ceraolo Spurio
The context is required to send the session termination commands to the VCS, which will be implemented in a follow-up patch. We can also use the presence of the context as a check of pxp initialization completion. v2: use perma-pinned context (Chris) v3: rename pinned_context functions (Chris)

[PATCH v9 03/17] drm/i915/pxp: define PXP device flag and kconfig

2021-09-10 Thread Daniele Ceraolo Spurio
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 support to query the caps from the mei device. Signed-off-by: Daniele Ceraolo Spurio

[PATCH v9 02/17] mei: pxp: export pavp client to me client bus

2021-09-10 Thread Daniele Ceraolo Spurio
From: Vitaly Lubart Export PAVP client to work with i915 driver, for binding it uses kernel component framework. v2:drop debug prints, refactor match code to match mei_hdcp (Tomas) Signed-off-by: Vitaly Lubart Signed-off-by: Tomas Winkler Signed-off-by: Daniele Ceraolo Spurio Reviewed-by:

[PATCH v9 01/17] drm/i915/pxp: Define PXP component interface

2021-09-10 Thread Daniele Ceraolo Spurio
This will be used for communication between the i915 driver and the mei one. Defining it in a stand-alone patch to avoid circualr dependedencies between the patches modifying the 2 drivers. Split out from an original patch from Huang, Sean Z v2: rename the component struct (Rodrigo)

[PATCH v9 00/17] drm/i915: Introduce Intel PXP

2021-09-10 Thread Daniele Ceraolo Spurio
PXP (Protected Xe Path) is an i915 component, available on GEN12i and newer platforms, that helps to establish the hardware protected session and manage the status of the alive software session, as well as its life cycle. changes from v8: - comments/docs improvements - remove rpm put race

Re: [RFC PATCH] drm/ttm: Add a private member to the struct ttm_resource

2021-09-10 Thread Thomas Hellström
On Fri, 2021-09-10 at 16:40 +0200, Christian König wrote: > > > Am 10.09.21 um 15:15 schrieb Thomas Hellström: > > Both the provider (resource manager) and the consumer (the TTM > > driver) > > want to subclass struct ttm_resource. Since this is left for the > > resource > > manager, we need to

Re: [PATCH v2 1/3] video: fbdev: asiliantfb: Error out if 'pixclock' equals zero

2021-09-10 Thread Geert Uytterhoeven
Hi Zheyu, On Mon, Jul 26, 2021 at 12:04 PM Zheyu Ma wrote: > The userspace program could pass any values to the driver through > ioctl() interface. If the driver doesn't check the value of 'pixclock', > it may cause divide error. > > Fix this by checking whether 'pixclock' is zero first. > > The

Re: [Intel-gfx] [PATCH 0/6] i915: Simplify mmio handling & add new DG2 shadow table

2021-09-10 Thread Matt Roper
On Fri, Sep 10, 2021 at 04:03:50PM +0100, Tvrtko Ursulin wrote: > > On 10/09/2021 15:24, Matt Roper wrote: > > On Fri, Sep 10, 2021 at 02:03:44PM +0100, Tvrtko Ursulin wrote: > > > > > > On 10/09/2021 06:33, Matt Roper wrote: > > > > Our uncore MMIO functions for reading/writing registers have

Re: [PATCH v2] kernel/locking: Add context to ww_mutex_trylock.

2021-09-10 Thread Peter Zijlstra
On Thu, Sep 09, 2021 at 11:32:18AM +0200, Maarten Lankhorst wrote: > diff --git a/kernel/locking/mutex.c b/kernel/locking/mutex.c > index d456579d0952..791c28005eef 100644 > --- a/kernel/locking/mutex.c > +++ b/kernel/locking/mutex.c > @@ -736,6 +736,44 @@ __ww_mutex_lock(struct mutex *lock,

Re: [Intel-gfx] [PATCH 0/6] i915: Simplify mmio handling & add new DG2 shadow table

2021-09-10 Thread Tvrtko Ursulin
On 10/09/2021 15:24, Matt Roper wrote: On Fri, Sep 10, 2021 at 02:03:44PM +0100, Tvrtko Ursulin wrote: On 10/09/2021 06:33, Matt Roper wrote: Our uncore MMIO functions for reading/writing registers have become very complicated over time. There's significant macro magic used to generate

[PATCH 0/1] lib, stackdepot: Add helper to print stack entries into buffer.

2021-09-10 Thread Imran Khan
This change is in response to discussion at [1]. The patch has been created on top of my earlier changes [2] and [3]. If needed I can resend all of these patches together, though my earlier patches have been Acked. [1] https://lore.kernel.org/lkml/e6f6fb85-1d83-425b-9e36-b5784cc9e...@suse.cz/ [2]

[PATCH 1/1] lib, stackdepot: Add helper to print stack entries into buffer.

2021-09-10 Thread Imran Khan
To print stack entries into a buffer, users of stackdepot, first get a list of stack entries using stack_depot_fetch and then print this list into a buffer using stack_trace_snprint. Provide a helper in stackdepot for this purpose. Also change above mentioned users to use this helper.

Re: [PATCH v3 2/8] mm: Introduce a function to check for confidential computing features

2021-09-10 Thread Borislav Petkov
On Wed, Sep 08, 2021 at 05:58:33PM -0500, Tom Lendacky wrote: > In prep for other confidential computing technologies, introduce a generic preparation > helper function, cc_platform_has(), that can be used to check for specific > active confidential computing attributes, like memory encryption.

[PATCH v5 1/3] dt-bindings: Add YAML bindings for NVDEC

2021-09-10 Thread Mikko Perttunen
Add YAML device tree bindings for NVDEC, now in a more appropriate place compared to the old textual Host1x bindings. Signed-off-by: Mikko Perttunen --- v5: * Changed from nvidia,instance to nvidia,host1x-class optional property. * Added dma-coherent v4: * Fix incorrect compatibility string in

[PATCH v5 2/3] arm64: tegra: Add NVDEC to Tegra186/194 device trees

2021-09-10 Thread Mikko Perttunen
Add a device tree node for NVDEC on Tegra186, and device tree nodes for NVDEC and NVDEC1 on Tegra194. Signed-off-by: Mikko Perttunen --- v5: * Change from nvidia,instance to nvidia,host1x-class v4: * Add dma-coherent markers v3: * Change read2 to read-1 v2: * Add NVDECSRD1 memory client * Add

[PATCH v5 3/3] drm/tegra: Add NVDEC driver

2021-09-10 Thread Mikko Perttunen
Add support for booting and using NVDEC on Tegra210, Tegra186 and Tegra194 to the Host1x and TegraDRM drivers. Booting in secure mode is not currently supported. Signed-off-by: Mikko Perttunen --- v5: * Remove num_instances * Change from nvidia,instance to nvidia,host1x-class v3: * Change

[PATCH v5 0/3] NVIDIA Tegra NVDEC support

2021-09-10 Thread Mikko Perttunen
Here's the v5 of the NVDEC support series, containing the following changes: * Changed from nvidia,instance property to nvidia,host1x-class property. * Set additionalProperties to false in DT bindings. * Added dma-coherent property to DT bindings. NVDEC hardware documentation can be found at

Re: [RFC PATCH] drm/ttm: Add a private member to the struct ttm_resource

2021-09-10 Thread Christian König
Am 10.09.21 um 15:15 schrieb Thomas Hellström: Both the provider (resource manager) and the consumer (the TTM driver) want to subclass struct ttm_resource. Since this is left for the resource manager, we need to provide a private pointer for the TTM driver. Provide a struct

Re: [Intel-gfx] [PATCH 0/6] i915: Simplify mmio handling & add new DG2 shadow table

2021-09-10 Thread Matt Roper
On Fri, Sep 10, 2021 at 02:03:44PM +0100, Tvrtko Ursulin wrote: > > On 10/09/2021 06:33, Matt Roper wrote: > > Our uncore MMIO functions for reading/writing registers have become very > > complicated over time. There's significant macro magic used to generate > > several nearly-identical

Re: [PATCH] drm/vc4: hdmi: Remove unused struct

2021-09-10 Thread Dave Stevenson
On Thu, 19 Aug 2021 at 15:08, Maxime Ripard wrote: > > Commitc7d30623540b ("drm/vc4: hdmi: Remove unused struct") removed the > references to the vc4_hdmi_audio_widgets and vc4_hdmi_audio_routes > structures, but not the structures themselves resulting in two warnings. > Remove it. > > Fixes:

Re: [PATCH v3 1/6] drm/vc4: select PM

2021-09-10 Thread Dave Stevenson
On Thu, 19 Aug 2021 at 14:59, Maxime Ripard wrote: > > We already depend on runtime PM to get the power domains and clocks for > most of the devices supported by the vc4 driver, so let's just select it > to make sure it's there, and remove the ifdef. > > Signed-off-by: Maxime Ripard

Re: [PATCH v2 5/9] vfio/mdev: Consolidate all the device_api sysfs into the core code

2021-09-10 Thread Jason Gunthorpe
On Fri, Sep 10, 2021 at 01:10:46PM +0100, Christoph Hellwig wrote: > On Thu, Sep 09, 2021 at 04:38:45PM -0300, Jason Gunthorpe wrote: > > Every driver just emits a static string, simply feed it through the ops > > and provide a standard sysfs show function. > > Looks sensible. But can you make

Re: [Intel-gfx] [PATCH v5] drm/i915: Use Transparent Hugepages when IOMMU is enabled

2021-09-10 Thread Tvrtko Ursulin
On 09/09/2021 17:17, Rodrigo Vivi wrote: On Thu, Sep 09, 2021 at 12:44:48PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Usage of Transparent Hugepages was disabled in 9987da4b5dcf ("drm/i915: Disable THP until we have a GPU read BW W/A"), but since it appears majority of performance

[Bug 213391] AMDGPU retries page fault with some specific processes amdgpu and sometimes followed [gfxhub0] retry page fault until *ERROR* ring gfx timeout, but soft recovered

2021-09-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213391 --- Comment #37 from Michel Dänzer (mic...@daenzer.net) --- (In reply to Lahfa Samy from comment #36) > Did anyone test whether this has been fixed in newer firmware updates, or > should we still stay on version 20210315.3568f96-3 ? It's fixed

Re: [PATCH v2 3/6] drm/i915 Implement LMEM backup and restore for suspend / resume

2021-09-10 Thread Thomas Hellström
On 9/6/21 6:55 PM, Thomas Hellström wrote: Just evict unpinned objects to system. For pinned LMEM objects, make a backup system object and blit the contents to that. Backup is performed in three steps, 1: Opportunistically evict evictable objects using the gpu blitter. 2: After gt idle, evict

[RFC PATCH] drm/ttm: Add a private member to the struct ttm_resource

2021-09-10 Thread Thomas Hellström
Both the provider (resource manager) and the consumer (the TTM driver) want to subclass struct ttm_resource. Since this is left for the resource manager, we need to provide a private pointer for the TTM driver. Provide a struct ttm_resource_private for the driver to subclass for data with the

[PATCH 3/3] drm/vc4: dsi: Switch to devm_drm_of_get_bridge

2021-09-10 Thread Maxime Ripard
The new devm_drm_of_get_bridge removes most of the boilerplate we have to deal with. Let's switch to it. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_drv.c | 2 ++ drivers/gpu/drm/vc4/vc4_dsi.c | 28 2 files changed, 6 insertions(+), 24 deletions(-)

[PATCH 2/3] drm/vc4: dpi: Switch to devm_drm_of_get_bridge

2021-09-10 Thread Maxime Ripard
The new devm_drm_of_get_bridge removes most of the boilerplate we have to deal with. Let's switch to it. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/vc4/vc4_dpi.c | 15 --- 1 file changed, 4 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/vc4/vc4_dpi.c

[PATCH 1/3] drm/bridge: Add a function to abstract away panels

2021-09-10 Thread Maxime Ripard
Display drivers so far need to have a lot of boilerplate to first retrieve either the panel or bridge that they are connected to using drm_of_find_panel_or_bridge(), and then either deal with each with ad-hoc functions or create a drm panel bridge through drm_panel_bridge_add. In order to reduce

[PATCH 0/3] drm/bridge: Create a function to abstract panels away

2021-09-10 Thread Maxime Ripard
Hi, This series used to be part of the DSI probe order series, but got removed since it wasn't useful there anymore. However, I still believe there is value in moving towards merging bridges and panels by only making encoder (or upstream bridges) manipulate bridges. The first patch creates a

Re: [PATCH v5 1/3] dt-bindings: Add YAML bindings for NVDEC

2021-09-10 Thread Rob Herring
On Fri, 10 Sep 2021 13:42:45 +0300, Mikko Perttunen wrote: > Add YAML device tree bindings for NVDEC, now in a more appropriate > place compared to the old textual Host1x bindings. > > Signed-off-by: Mikko Perttunen > --- > v5: > * Changed from nvidia,instance to nvidia,host1x-class optional >

Re: [Intel-gfx] [PATCH 0/6] i915: Simplify mmio handling & add new DG2 shadow table

2021-09-10 Thread Tvrtko Ursulin
On 10/09/2021 06:33, Matt Roper wrote: Our uncore MMIO functions for reading/writing registers have become very complicated over time. There's significant macro magic used to generate several nearly-identical functions that only really differ in terms of which platform-specific shadow

Re: [Intel-gfx] [PATCH 1/6] drm/i915/uncore: Convert gen6/gen7 read operations to fwtable

2021-09-10 Thread Tvrtko Ursulin
On 10/09/2021 06:33, Matt Roper wrote: On gen6-gen8 (except vlv/chv) we don't use a forcewake lookup table; we simply check whether the register offset is < 0x4, and return FORCEWAKE_RENDER if it is. To prepare for upcoming refactoring, let's define a single-entry forcewake table from

Re: [Intel-gfx] [PATCH 5/6] drm/i915/uncore: Drop gen11 mmio read handlers

2021-09-10 Thread Tvrtko Ursulin
On 10/09/2021 06:33, Matt Roper wrote: Consolidate down to just a single 'fwtable' implementation. For reads we don't need to worry about shadow tables. Also, the NEEDS_FORCE_WAKE() check we previously had in the fwtable implementation can be dropped --- if a register is outside that range

[Bug 213391] AMDGPU retries page fault with some specific processes amdgpu and sometimes followed [gfxhub0] retry page fault until *ERROR* ring gfx timeout, but soft recovered

2021-09-10 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=213391 --- Comment #36 from Lahfa Samy (s...@lahfa.xyz) --- Did anyone test whether this has been fixed in newer firmware updates, or should we still stay on version 20210315.3568f96-3 ? -- You may reply to this email to add a comment. You are

Re: [PATCH RESEND] drm/i915: Mark GPU wedging on driver unregister unrecoverable

2021-09-10 Thread Michał Winiarski
On 03.09.2021 16:28, Janusz Krzysztofik wrote: GPU wedged flag now set on driver unregister to prevent from further using the GPU can be then cleared unintentionally when calling __intel_gt_unset_wedged() still before the flag is finally marked unrecoverable. We need to have it marked

Re: [Intel-gfx] [PATCH 23/27] drm/i915/guc: Implement no mid batch preemption for multi-lrc

2021-09-10 Thread Tvrtko Ursulin
On 20/08/2021 23:44, Matthew Brost wrote: For some users of multi-lrc, e.g. split frame, it isn't safe to preempt mid BB. To safely enable preemption at the BB boundary, a handshake between to parent and child is needed. This is implemented via custom emit_bb_start & emit_fini_breadcrumb

Re: [Intel-gfx] [PATCH 08/27] drm/i915: Add logical engine mapping

2021-09-10 Thread Tvrtko Ursulin
On 20/08/2021 23:44, Matthew Brost wrote: Add logical engine mapping. This is required for split-frame, as workloads need to be placed on engines in a logically contiguous manner. v2: (Daniel Vetter) - Add kernel doc for new fields Signed-off-by: Matthew Brost ---

[PATCH v4 24/24] drm/exynos: dsi: Adjust probe order

2021-09-10 Thread Maxime Ripard
Without proper care and an agreement between how DSI hosts and devices drivers register their MIPI-DSI entities and potential components, we can end up in a situation where the drivers can never probe. Most drivers were taking evasive maneuvers to try to workaround this, but not all of them were

[PATCH v4 23/24] drm/kirin: dsi: Adjust probe order

2021-09-10 Thread Maxime Ripard
Without proper care and an agreement between how DSI hosts and devices drivers register their MIPI-DSI entities and potential components, we can end up in a situation where the drivers can never probe. Most drivers were taking evasive maneuvers to try to workaround this, but not all of them were

[PATCH v4 22/24] drm/bridge: tc358775: Register and attach our DSI device at probe

2021-09-10 Thread Maxime Ripard
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/tc358775.c | 37 +-- 1 file

[PATCH v4 21/24] drm/bridge: tc358775: Switch to devm MIPI-DSI helpers

2021-09-10 Thread Maxime Ripard
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/tc358775.c | 13 - 1 file changed, 4 insertions(+), 9 deletions(-) diff

[PATCH v4 20/24] drm/bridge: sn65dsi86: Register and attach our DSI device at probe

2021-09-10 Thread Maxime Ripard
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 74 ++- 1 file

[PATCH v4 19/24] drm/bridge: sn65dsi86: Switch to devm MIPI-DSI helpers

2021-09-10 Thread Maxime Ripard
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/ti-sn65dsi86.c | 22 +++--- 1 file changed, 7 insertions(+), 15

[PATCH v4 18/24] drm/bridge: sn65dsi83: Register and attach our DSI device at probe

2021-09-10 Thread Maxime Ripard
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 80 +++ 1 file

[PATCH v4 17/24] drm/bridge: sn65dsi83: Switch to devm MIPI-DSI helpers

2021-09-10 Thread Maxime Ripard
Let's switch to the new devm MIPI-DSI function to register and attach our secondary device. This also avoids leaking the device when we detach the bridge but don't remove its driver. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/ti-sn65dsi83.c | 12 +++- 1 file changed, 3

[PATCH v4 16/24] drm/bridge: ps8640: Register and attach our DSI device at probe

2021-09-10 Thread Maxime Ripard
In order to avoid any probe ordering issue, the best practice is to move the secondary MIPI-DSI device registration and attachment to the MIPI-DSI host at probe time. Let's do this. Signed-off-by: Maxime Ripard --- drivers/gpu/drm/bridge/parade-ps8640.c | 97 +++--- 1 file

  1   2   >