On Wed, Jun 30, 2021 at 08:56:51AM -0700, Nathan Chancellor wrote:
> On Wed, Jun 30, 2021 at 12:43:48PM +0100, Will Deacon wrote:
> > On Wed, Jun 30, 2021 at 05:17:27PM +0800, Claire Chang wrote:
> > > `BUG: unable to handle page fault for address: 003a8290` and
> > > the fact it crashed at
On Wed, 30 Jun 2021 11:42:10 +0200
Werner Sembach wrote:
> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
> > On Tue, 29 Jun 2021 13:02:05 +0200
> > Werner Sembach wrote:
> >
> >> Am 28.06.21 um 19:03 schrieb Werner Sembach:
> >>> Am 18.06.21 um 11:11 schrieb Werner Sembach:
> Add a new
On Wed, 30 Jun 2021 11:20:18 +0200
Werner Sembach wrote:
> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
>
> > On Tue, 29 Jun 2021 13:39:18 +0200
> > Werner Sembach wrote:
> >
> >> Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> >>> On Tue, 29 Jun 2021 08:12:54 +
> >>> Simon Ser wrote:
>
On Wed, 30 Jun 2021 11:58:25 -0700
John Harrison wrote:
> On 6/30/2021 01:22, Martin Peres wrote:
> > On 24/06/2021 10:05, Matthew Brost wrote:
> >> From: Daniele Ceraolo Spurio
> >>
> >> Unblock GuC submission on Gen11+ platforms.
> >>
> >> Signed-off-by: Michal Wajdeczko
> >> Signed-off-by:
On Thu, 24 Jun 2021, Jiri Kosina wrote:
> From: Jiri Kosina
>
> This reverts commit 4192f7b5768912ceda82be2f83c87ea7181f9980.
>
> It is not true (as stated in the reverted commit changelog) that we never
> unmap the BAR on failure; it actually does happen properly on
> amdgpu_driver_load_kms(
On Thu, 24 Jun 2021, Jiri Kosina wrote:
> From: Jiri Kosina
>
> In case when psp_init_asd_microcode() fails to load ASD microcode file,
> psp_v12_0_init_microcode() tries to print the firmware filename that
> failed to load before bailing out.
>
> This is wrong because:
>
> - the firmware fi
On Wed, 30 Jun 2021, Rodrigo Vivi wrote:
> On Wed, Jun 30, 2021 at 01:05:35PM +0300, Jani Nikula wrote:
>> On Tue, 29 Jun 2021, Rodrigo Vivi wrote:
>> > Hi Dave and Daniel,
>> >
>> > Here goes drm-intel-next-fixes-2021-06-29:
>> >
>> > The biggest fix is the restoration of mmap ioctl for gen12 in
The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.
Change all calls to synchronize_hardirq() to intel_synchronize_irq(),
which uses the correct interrupt. _hardirq() func
Fix a bug in the usage of IRQs and cleanup references to the DRM
IRQ midlayer.
Preferably this patchset would be merged through drm-misc-next.
v4:
* switch IRQ code to intel_synchronize_irq() (Daniel)
v3:
* also use intel_synchronize_hardirq() from other callsite
v2:
* spl
Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
functions directly.
v2:
* also remove an outdated comment
* move IRQ fix into separate patch
* update Fixes tag (Daniel)
Signed-off-by: Thomas Zimmermann
Fixes: b318b82455bd ("drm/i915: Nuke drm_drive
Hi Dave and Daniel,
this week's PR for drm-misc-next-fixes contains a number of BO-related
fixes in amdgpu, gma500 and radeon, and a documentation fix for dma-buf.
Best regards
Thomas
drm-misc-next-fixes-2021-07-01:
Short summary of fixes pull:
* amdgpu: TTM fixes
* dma-buf: Doc fixes
* gma5
So we can re-use it from elsewhere.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 52 ++---
1 file changed, 29 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gpu/drm/panfrost/panfrost_drv.c
index
Hello,
This is an attempt at providing a new submit ioctl that's more
Vulkan-friendly than the existing one. This ioctl
1/ allows passing several out syncobjs so we can easily update
several fence/semaphore in a single ioctl() call
2/ allows passing several jobs so we don't have to have one io
So we don't have to change the prototype if we extend the function.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_job.c | 22 --
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_job.c
b/drivers/gpu/drm/pa
Needed to keep VkQueues isolated from each other.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/Makefile | 3 +-
drivers/gpu/drm/panfrost/panfrost_device.h| 2 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 69 --
drivers/gpu/drm/panfrost/panfrost_j
This should help limit the number of ioctls when submitting multiple
jobs. The new ioctl also supports syncobj timelines and BO access flags.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 305
drivers/gpu/drm/panfrost/panfrost_job.c | 3 +
Jobs reading from the same BO should not be serialized. Add access
flags so we can relax the implicit dependencies in that case. We force
exclusive access for now to keep the behavior unchanged, but a new
SUBMIT ioctl taking explicit access flags will be introduced.
Signed-off-by: Boris Brezillon
Now that we have a new SUBMIT ioctl dealing with timelined syncojbs we
can advertise the feature.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/panfrost/panfrost_drv.c
b/drivers/gp
We now have a new ioctl that allows submitting multiple jobs at once
(among other things) and we support timelined syncobjs. Bump the
minor version number to reflect those changes.
Signed-off-by: Boris Brezillon
---
drivers/gpu/drm/panfrost/panfrost_drv.c | 4 +++-
1 file changed, 3 insertions(+
On 29/06/2021 04:04, Chunyou Tang wrote:
> Hi Steve,
> thinks for your reply.
> I set the pte in arm_lpae_prot_to_pte(),
> ***
> /*
>* Also Mali has its own notions of shareability wherein its
> Inner
>
Am 01.07.21 um 09:42 schrieb Pekka Paalanen:
> On Wed, 30 Jun 2021 11:42:10 +0200
> Werner Sembach wrote:
>
>> Am 30.06.21 um 10:21 schrieb Pekka Paalanen:
>>> On Tue, 29 Jun 2021 13:02:05 +0200
>>> Werner Sembach wrote:
>>>
Am 28.06.21 um 19:03 schrieb Werner Sembach:
> Am 18.06.2
Inline mgag200_device_init() into mgag200_device_create(), which is the
only caller.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 41 +--
1 file changed, 13 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
The flags argument is only relevant for UMS drivers. Pass 0.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.c
b/drivers/gpu/drm/mgag200/mgag200_drv.c
index 36d1bfb
Cleanup several nits in the driver's init code. Also move constant
data into the RO data segment. No functional changes.
Tested on mgag200 HW.
Thomas Zimmermann (4):
drm/mgag200: Don't pass flags to drm_dev_register()
drm/mgag200: Inline mgag200_device_init()
drm/mgag200: Extract device typ
Declare constant LUT for bpp programming as static const. Removes mutable
data from device structure.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.h | 2 --
drivers/gpu/drm/mgag200/mgag200_mode.c | 16 ++--
2 files changed, 6 insertions(+), 12 deletions(
The type and flags values are stored in the PCI ID list. Extract them
in the probe function. Makes the device initialization more readable.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/mgag200/mgag200_drv.c | 21 +
drivers/gpu/drm/mgag200/mgag200_drv.h | 12 --
Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
> On Wed, 30 Jun 2021 11:20:18 +0200
> Werner Sembach wrote:
>
>> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
>>
>>> On Tue, 29 Jun 2021 13:39:18 +0200
>>> Werner Sembach wrote:
>>>
Am 29.06.21 um 13:17 schrieb Pekka Paalanen:
> On Tue,
On Thu, 1 Jul 2021 14:50:13 +0200
Werner Sembach wrote:
> Am 01.07.21 um 10:07 schrieb Pekka Paalanen:
>
> > On Wed, 30 Jun 2021 11:20:18 +0200
> > Werner Sembach wrote:
> >
> >> Am 30.06.21 um 10:41 schrieb Pekka Paalanen:
> >>
> >>> On Tue, 29 Jun 2021 13:39:18 +0200
> >>> Werner Sembach
On Wed, 23 Jun 2021 10:43:08 -0600, Rob Herring wrote:
> Fix the renesas,du binding 'ports' schema which is referencing the 'port'
> schema instead of the 'ports' schema.
>
> Fixes: 99d66127fad2 ("dt-bindings: display: renesas,du: Convert binding to
> YAML")
> Cc: Laurent Pinchart
> Cc: Kieran B
On Wed, 23 Jun 2021 10:43:44 -0600, Rob Herring wrote:
> In testing out under development json-schema 2020-12 support, there's a
> few issues with 'unevaluatedProperties' and the graph schema. If
> 'graph.yaml#/properties/port' is used, then neither the port nor the
> endpoint(s) can have additiona
Applied. Thanks!
Alex
On Thu, Jul 1, 2021 at 4:32 AM Jiri Kosina wrote:
>
> On Thu, 24 Jun 2021, Jiri Kosina wrote:
>
> > From: Jiri Kosina
> >
> > This reverts commit 4192f7b5768912ceda82be2f83c87ea7181f9980.
> >
> > It is not true (as stated in the reverted commit changelog) that we never
>
Applied. Thanks!
Alex
On Thu, Jul 1, 2021 at 4:33 AM Jiri Kosina wrote:
>
> On Thu, 24 Jun 2021, Jiri Kosina wrote:
>
> > From: Jiri Kosina
> >
> > In case when psp_init_asd_microcode() fails to load ASD microcode file,
> > psp_v12_0_init_microcode() tries to print the firmware filename that
>
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin() c
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to rec
For discrete, users of pin_map() needs to obey the same rules at the TTM
backend, where we map system only objects as WB, and everything else as
WC. The simplest for now is to just force the correct mapping type as
per the new rules for discrete.
Suggested-by: Thomas Hellström
Signed-off-by: Matt
It's a noop on DG1, and in the future when need to support other devices
which let us control the coherency, then it should be an immutable
creation time property for the BO.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Maarten Lankhorst
Cc: Kenneth Graunke
The CPU domain should be static for discrete, and on DG1 we don't need
any flushing since everything is already coherent, so really all this
does is an object wait, for which we have an ioctl. Longer term the
desired caching should be an immutable creation time property for the
BO.
One other user
For discrete, users of pin_map() needs to obey the same rules at the TTM
backend, where we map system only objects as WB, and everything else as
WC. The simplest for now is to just force the correct mapping type as
per the new rules for discrete.
Suggested-by: Thomas Hellström
Signed-off-by: Matt
It's a noop on DG1, and in the future when need to support other devices
which let us control the coherency, then it should be an immutable
creation time property for the BO. This will likely be controlled
through a new gem_create_ext extension.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew
The CPU domain should be static for discrete, and on DG1 we don't need
any flushing since everything is already coherent, so really all this
does is an object wait, for which we have an ioctl. Longer term the
desired caching should be an immutable creation time property for the
BO, which can be set
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin() c
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to rec
In commit b839a869dfc9 ("drm/i915/guc: Add support for data
reporting in GuC responses") we missed the hypothetical case
that GuC might return positive non-zero value as success data.
While that would be lucky treated as error case, and at the
end will result in reporting valid -EIO, in the meanti
Instead of plain error value (%d) print more user friendly error
name (%pe).
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915
Instead of plain error value (%d) print more user friendly error
name (%pe).
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
b/drivers/gpu/drm/i915/gt/
If we timeout waiting for a CT reply we print very simple error
message. Improve that and by moving error reporting to the caller
we can use CT_ERROR instead of DRM_ERROR and report just fence
as error code will be reported later anyway.
Signed-off-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/g
There was a gap in handling MMIO result from CTB (de)registration
and while fixing it improve some other error reports.
Signed-off-by: Michal Wajdeczko
Michal Wajdeczko (4):
drm/i915/guc: Verify result from CTB (de)register action
drm/i915/guc: Print error name on CTB (de)registration failur
This is a reminder that the call for proposals for hosting XDC 2022
period finishes in two months.
Be sure to prepare your submission before you leave on holiday!
Sam
On Thu, 2021-05-20 at 12:15 +0200, Samuel Iglesias Gonsálvez wrote:
> Hello everyone!
>
> The X.org board is soliciting proposal
On 2021-06-30 17:00, Dmitry Baryshkov wrote:
None of supported devies uses "gdsc" regulator for DSI. GDSC support is
now implemented as a power domain. Drop old code and config handling
gdsc regulator requesting and enabling.
Signed-off-by: Dmitry Baryshkov
Reviewed-by: Abhinav Kumar
---
dr
Make CTB Header explicit and separate from CTB Message.
Signed-off-by: Michal Wajdeczko
Cc: Matthew Brost
---
.../gt/uc/abi/guc_communication_ctb_abi.h | 51 +++
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 -
2 files changed, 43 insertions(+), 32 deletions(-)
This patch series addresses potential use-after-free errors when dereferencing
pointers to struct drm_master. These were identified after one such bug was
caught by Syzbot in drm_getunique():
https://syzkaller.appspot.com/bug?id=148d2f1dfac64af52ffd27b661981a540724f803
The series is broken up in
In preparation for a future patch to take a lock on
drm_device.master_mutex inside drm_is_current_master(), we first move
the call to drm_is_current_master() in drm_mode_getconnector out from the
section locked by &dev->mode_config.mutex. This avoids creating a
circular lock dependency.
Failing to
In a future patch, _drm_lease_held will dereference drm_file->master
only after making a call to drm_file_get_master. This will increment
the reference count of drm_file->master while holding onto a new
drm_file.master_lock.
In preparation for this, the call to _drm_lease_held should be moved
out
While checking the master status of the DRM file in
drm_is_current_master(), the device's master mutex should be
held. Without the mutex, the pointer fpriv->master may be freed
concurrently by another process calling drm_setmaster_ioctl(). This
could lead to use-after-free errors when the pointer i
Currently, drm_file.master pointers should be protected by
drm_device.master_mutex when being dereferenced. This is because
drm_file.master is not invariant for the lifetime of drm_file. If
drm_file is not the creator of master, then drm_file.is_master is
false, and a call to drm_setmaster_ioctl wi
drm_file->master pointers should be protected by
drm_device.master_mutex or drm_file.master_lock when being
dereferenced.
However, in drm_lease.c, there are multiple instances where
drm_file->master is accessed and dereferenced while neither lock is
held. This makes drm_lease.c vulnerable to use-a
In upcoming patch we will allow more CTB requests to be sent in
parallel to the GuC for processing, so we shouldn't assume any more
that GuC will always reply without 10ms.
Use bigger value hardcoded value of 1s instead.
v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option
v3:
(Daniel Vetter)
As part of enabling GuC submission discussed in [1], [2], and [3] we
need optimize and update the CT code as this is now in the critical
path of submission. This series includes the patches to do that which is
the first 7 patches from [3]. The patches should have addressed all the
feedback in [3] a
Implement a stall timer which fails H2G CTBs once a period of time
with no forward progress is reached to prevent deadlock.
v2:
(Michal)
- Improve error message in ct_deadlock()
- Set broken when ct_deadlock() returns true
- Return -EPIPE on ct_deadlock()
v3:
(Michal)
- Add ms to stall t
Improve the error message when a unsolicited CT response is received by
printing fence that couldn't be found, the last fence, and all requests
with a response outstanding.
Signed-off-by: Matthew Brost
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 10 +++---
From: John Harrison
Add several module failure load inject points in the CT buffer creation
code path.
Signed-off-by: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 8
1 file changed, 8 insertions(+)
diff --g
CTB writes are now in the path of command submission and should be
optimized for performance. Rather than reading CTB descriptor values
(e.g. head, tail) which could result in accesses across the PCIe bus,
store shadow local copies and only read/write the descriptor values when
absolutely necessary
Add non blocking CTB send function, intel_guc_send_nb. GuC submission
will send CTBs in the critical path and does not need to wait for these
CTBs to complete before moving on, hence the need for this new function.
The non-blocking CTB now must have a flow control mechanism to ensure
the buffer is
With the introduction of non-blocking CTBs more than one CTB can be in
flight at a time. Increasing the size of the CTBs should reduce how
often software hits the case where no space is available in the CTB
buffer.
Cc: John Harrison
Signed-off-by: Matthew Brost
Reviewed-by: Michal Wajdeczko
---
Arm Fixed Rate Compression (AFRC) is a proprietary fixed rate image
compression protocol and format.
It is designed to provide guaranteed bandwidth and memory footprint
reductions in graphics and media use-cases.
This patch aims to add modifier definitions for describing
AFRC.
Signed-off-by: Norm
There'a limit to how big a kmalloc buffer can be, and as memory gets
fragmented it becomes more difficult to get big buffers. The downside of
smaller buffers is that the driver has to split the transfer up which
hampers performance. Compression might also take a hit because of the
splitting.
Solve
Free transfer and compression buffers on device removal instead of at
DRM device removal time. This ensures that the usual 2x8MB buffers are
released when the device is unplugged and not kept around should
userspace keep the DRM device fd open.
At least Ubuntu 20.04 doesn't release the DRM device
The code in xcs_resume() probably didn't work as intended. It uses
struct drm_device.irq, which is allocated to 0, but never initialized
by i915 to the device's interrupt number.
Change all calls to synchronize_hardirq() to intel_synchronize_irq(),
which uses the correct interrupt. _hardirq() func
Fix a bug in the usage of IRQs and cleanup references to the DRM
IRQ midlayer.
Preferably this patchset would be merged through drm-misc-next.
v5:
* go back to _hardirq() after CI tests reported atomic
context in PCI probe; add rsp comment
v4:
* switch IRQ code to intel_
Remove all references to DRM's IRQ midlayer. i915 uses Linux' interrupt
functions directly.
v2:
* also remove an outdated comment
* move IRQ fix into separate patch
* update Fixes tag (Daniel)
Signed-off-by: Thomas Zimmermann
Fixes: b318b82455bd ("drm/i915: Nuke drm_drive
Hi Thomas,
On Thu, Jul 01, 2021 at 02:43:12PM +0200, Thomas Zimmermann wrote:
> Cleanup several nits in the driver's init code. Also move constant
> data into the RO data segment. No functional changes.
>
> Tested on mgag200 HW.
>
> Thomas Zimmermann (4):
> drm/mgag200: Don't pass flags to drm
On 30/06/2021 21:00, Matthew Brost wrote:
On Wed, Jun 30, 2021 at 11:22:38AM +0300, Martin Peres wrote:
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Signed-off-by: Daniele Ceraolo Spurio
On 01/07/2021 11:14, Pekka Paalanen wrote:
On Wed, 30 Jun 2021 11:58:25 -0700
John Harrison wrote:
On 6/30/2021 01:22, Martin Peres wrote:
On 24/06/2021 10:05, Matthew Brost wrote:
From: Daniele Ceraolo Spurio
Unblock GuC submission on Gen11+ platforms.
Signed-off-by: Michal Wajdeczko
Si
On Thu, Jul 1, 2021 at 8:27 PM Martin Peres wrote:
>
> On 01/07/2021 11:14, Pekka Paalanen wrote:
> > On Wed, 30 Jun 2021 11:58:25 -0700
> > John Harrison wrote:
> >
> >> On 6/30/2021 01:22, Martin Peres wrote:
> >>> On 24/06/2021 10:05, Matthew Brost wrote:
> From: Daniele Ceraolo Spurio
>
On Thu, Jul 01, 2021 at 11:57:53AM +0300, Jani Nikula wrote:
> On Wed, 30 Jun 2021, Rodrigo Vivi wrote:
> > On Wed, Jun 30, 2021 at 01:05:35PM +0300, Jani Nikula wrote:
> >> On Tue, 29 Jun 2021, Rodrigo Vivi wrote:
> >> > Hi Dave and Daniel,
> >> >
> >> > Here goes drm-intel-next-fixes-2021-06-29
On Wed, Jun 30, 2021 at 9:34 PM Dave Airlie wrote:
>
> Hi Linus,
>
> This is the main drm pull request for 5.14-rc1.
>
> I've done a test pull into your current tree, and hit two conflicts
> (one in vc4, one in amdgpu), both seem pretty trivial, the amdgpu one
> is recent and sfr sent out a resolu
From: Thomas Hellström
If our exported dma-bufs are imported by another instance of our driver,
that instance will typically have the imported dma-bufs locked during
dma_buf_map_attachment(). But the exporter also locks the same reservation
object in the map_dma_buf() callback, which leads to rec
From: Thomas Hellström
Until we support p2p dma or as a complement to that, migrate data
to system memory at dma-buf attach time if possible.
v2:
- Rebase on dynamic exporter. Update the igt_dmabuf_import_same_driver
selftest to migrate if we are LMEM capable.
v3:
- Migrate also in the pin() c
The pull request you sent on Thu, 1 Jul 2021 14:34:15 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2021-07-01
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e058a84bfddc42ba356a2316f2cf1141974625c9
Thank you!
--
Deet-doot-dot, I am a bot.
https://kor
This series provides some of the initial enablement patches for two
upcoming discrete GPUs:
* XeHP SDV: Xe_HP (version 12.50) graphics IP, no display IP
* DG2: Xe_HPG (version 12.55) graphics IP, Xe_LPD (version 13) display IP
Both platforms will need additional enablement patches beyond what'
Since we can't steer multicast register reads during ring-based
workaround verification, we need to define the multicast ranges where
failure to steer could potentially cause us to read back from a
fused-off register instance.
As with gen12, we can ignore the multicast ranges that the bspec
descri
Implement Xe_HP forcewake handling. While we're at it, let's reorder to
the forcewake assignment if/else ladder to match our usual driver
conventions.
Co-authored-by: Daniele Ceraolo Spurio
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
Signed-off-by: Matt Roper
---
.../
From: John Harrison
Xe_HP can have a lot of extra media engines. This patch adds the
interrupt handler support for them.
Cc: Tvrtko Ursulin
Cc: Daniele Ceraolo Spurio
Signed-off-by: John Harrison
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_gt_irq.c | 13 -
driver
From: Lucas De Marchi
Our _FEATURES macro went back to GEN7, extending each other, making it
difficult to grasp what was really enabled/disabled. Take the
opportunity of the GEN -> XE_HP name break and also break with the
feature inheritance.
For XE_HP this basically goes from GEN12 back to GEN7
From: Venkata Sandeep Dhanalakota
In Gen12 there are various fuse combinations and in each configuration
vdbox engine may be connected to SFC depending on which engines are
available, so we need to set the SFC capability based on fuse value from
the hardware. Even numbered phyical instance always
From: Lucas De Marchi
Besides the arch version returned by GRAPHICS_VER(), new platforms
contain a "release id" to make clear the difference from one platform to
another. Although for the first ones we may use them as if they were a
major/minor version, that is not true for all platforms: we may
DG2 has Xe_LPD display (version 13) and Xe_HPG (version 12.55) graphics.
There are two variants (treated as subplatforms in the code): DG2-G10
and DG2-G11 that require independent programming in some areas (e.g.,
workarounds).
Bspec: 44472, 44474, 46197, 48028, 48077
Cc: Anusha Srivatsa
Signed-o
DG2's replicated register ranges are almost the same at XeHP SDV with
the exception of one LNCF sub-range that switches to gslice steering.
We can re-use the XeHP SDV mslice steering table and just provide a
DG2-specific LNCF steering table.
Bspec: 66534
Cc: Daniele Ceraolo Spurio
Signed-off-by:
From: John Harrison
Xe_HP can have a lot of extra media engines. This patch adds the reset
support for them.
Signed-off-by: John Harrison
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_reset.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 8
2 files changed, 14 ins
From: Stuart Summers
Starting in XeHP, the concept of slice has been removed in favor of
DSS (Dual-Subslice) masks for various workload types. These workloads have
been divided into those enabled for geometry and those enabled for compute.
i915 currently maintains a single set of S/SS/EU masks f
From: Lucas De Marchi
XeHP SDV is a Intel® dGPU without display. This is just the definition
of some basic platform macros, by large a copy of current state of
Tigerlake which does not reflect the end state of this platform.
Bspec: 44467, 48077
Cc: Rodrigo Vivi
Signed-off-by: Lucas De Marchi
S
DG2 supports compute DSS and has the same maximum number of DSS and EU
as XeHP SDV.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_sseu.c
b/drivers/gpu/drm/i915/gt/intel_sseu.c
Although DG2_G10 platforms will always have all SQIDI's present and
don't need steering for registers in a SQIDI MMIO range, this isn't true
for DG2_G11 platforms; only SQIDI's 2 and 3 can be used on those.
We handle SQIDI ranges a bit differently from other types of explicit
steering. The SQIDI
From: Animesh Manna
In verify_mpllb_state() encoder is retrieved from best_encoder
of connector_state. As there will be only one connector_state
for bigjoiner and checking encoder may not be needed for
bigjoiner-slave. This code path related to mpll is done on dg2
and need this fix to avoid null
From: Prathap Kumar Valsan
The layout of some engine contexts has changed on Xe_HP. Define the new
offsets.
Bspec: 45585, 46256
Signed-off-by: Prathap Kumar Valsan
Signed-off-by: Ramalingam C
Signed-off-by: Venkata Ramana Nayana
Signed-off-by: Akeem G Abodunrin
Signed-off-by: Matt Roper
--
DG2's SNPS PHYs incorporate a dedicated port PLL called MPLLB which
takes the place of the shared DPLLs we've used on past platforms. Let's
add the MPLLB programming sequences; they'll be plugged into the rest of
the code in future patches.
Bspec: 54032
Bspec: 53881
Cc: Lucas De Marchi
Signed-of
From: Matthew Auld
Xe_HP no longer has "slices" in the same way that old platforms did.
There are new concepts (gslices, cslices, mslices) that apply in various
contexts, but for the purposes of fusing slices no longer exist and we
just have one large pool of dual-subslices (DSS) to work with.
Fu
We no longer have traditional slices on Xe_HP platforms, but the
INSTDONE registers are replicated according to gslice representation
which is similar. We can mostly re-use the existing instdone code with
just a few modifications:
* Create an alternate instdone loop macro that will iterate over
From: Paulo Zanoni
The current interrupt handler is getting increasingly complicated and
Xe_HP changes will bring even more complexity. Let's split off a new
interrupt handler starting with DG1 (i.e., when the master tile
interrupt register was added to the design) and use that as the basis
for
Note that DG2 only has a single possible refclk frequency (38.4 MHz).
Bspec: 54034
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 24 --
1 file changed, 22 insertions(+), 2 deletions(-)
diff --g
1 - 100 of 152 matches
Mail list logo
