On Friday, 10 December 2021 3:54:31 AM AEDT Sierra Guiza, Alejandro (Alex)
wrote:
>
> On 12/9/2021 10:29 AM, Felix Kuehling wrote:
> > Am 2021-12-09 um 5:53 a.m. schrieb Alistair Popple:
> >> On Thursday, 9 December 2021 5:55:26 AM AEDT Sierra Guiza, Alejandro
> >> (Alex) wrote:
> >>> On 12/8/20
Hi Matt,
> > GGTT is currently available both through i915->ggtt and gt->ggtt, and we
> > eventually want to get rid of the i915->ggtt one.
> > Use to_gt() for all i915->ggtt accesses to help with the future
> > refactoring.
>
> I think we can also convert the two references in i915_drm_suspend()
Hi Linus,
Regular fixes, pretty small overall, couple of core fixes, two i915
and two amdgpu, hopefully it stays this quiet.
Regards,
Dave.
drm-fixes-2021-12-10:
drm fixes for 5.16-rc5
ttm:
- fix ttm_bo_swapout
syncobj:
- fix fence find bug with signalled fences
i915:
- fix error pointer dere
From: John Harrison
It is possible for platforms to require GuC but not HuC firmware.
Also, the firmware versions for GuC and HuC advance independently. So
split the macros up to allow the lists to be maintained separately.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
Reviewed-by:
From: John Harrison
Add support for telling the debugfs interface the size of the GuC log
dump in advance. Without that, the underlying framework keeps calling
the 'show' function with larger and larger buffer allocations until it
fits. That means reading the log from graphics memory many times -
From: John Harrison
Lots of testing is done with the DEBUG_GEM config option enabled but
not the DEBUG_GUC option. That means we only get teeny-tiny GuC logs
which are not hugely useful. Enabling full DEBUG_GUC also spews lots
of other detailed output that is not generally desired. However,
bigge
From: John Harrison
Fix a potential null pointer dereference, improve debug crash reports,
improve code separation, improve GuC log read speed.
Signed-off-by: John Harrison
John Harrison (4):
drm/i915/uc: Allow platforms to have GuC but not HuC
drm/i915/guc: Speed up GuC log dumps
drm/
From: John Harrison
If the GuC has failed to load for any reason and then the user pokes
the debugfs GuC log interface, a BUG and/or null pointer deref can
occur. Don't let that happen.
Signed-off-by: John Harrison
Reviewed-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_log_debu
Am 09.12.21 um 19:28 schrieb Felix Kuehling:
Am 2021-12-09 um 10:30 a.m. schrieb Christian König:
That still won't work.
But I think we could do this change for the amdgpu mmap callback only.
If graphics user mode has problems with it, we could even make this
specific to KFD BOs in the amdgpu_
Hi,
> > The drivers are asic and platform specific. E.g., the driver for
> > vangogh is different from renoir is different from skylake, etc. The
> > display programming interfaces are asic specific.
>
> Cool, that makes sense! But if you (or anybody here) know some of these
> GOP drivers, e.
On Thu, Dec 09, 2021 at 09:15:24PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> Tile4 in bspec format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Moved Tile4 associating struct for modifier/dis
On Thu, Dec 09, 2021 at 09:15:24PM +0530, Ramalingam C wrote:
> From: Stanislav Lisovskiy
>
> Tile4 in bspec format is 4K tile organized into
> 64B subtiles with same basic shape as for legacy TileY
> which will be supported by Display13.
>
> v2: - Moved Tile4 associating struct for modifier/dis
201 - 212 of 212 matches
Mail list logo
