Let’s establish a merge plan for Xe, by writing down clear pre-merge goals, in
order to avoid unnecessary delays.
This initial document starts with a TODO list containing items with clear and
measurable key results. Xe’s initial pull request should only be sent to
dri-devel after all the items
>>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> index 1803a633ed64..98e682b7df07 100644
>>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>>> @@ -415,12 +415,6 @@ static int
Hi,
On 2023/4/17 15:29, Thomas Zimmermann wrote:
Hi
Am 14.04.23 um 12:58 schrieb Sui Jingfeng:
Hi,
On 2023/4/14 03:16, Thomas Zimmermann wrote:
Hi,
thanks for the patch. This is effectively a revert of commit
8fbc9af55de0 ("drm/fbdev-generic: Set screen size to size of GEM
buffer").
On Tue, Apr 18, 2023 at 03:57:57PM -0700, Patrick McLean wrote:
> Currently the ASPEED PCI vendor ID is defined in
> drivers/gpu/drm/ast/ast_drv.c, move that to include/linux/pci_ids.h
> with all the rest of the PCI vendor ID definitions. Rename the definition
> to follow the format that the other
On Wed, Apr 19, 2023 at 09:00:15AM +0200, Thomas Zimmermann wrote:
> Am 19.04.23 um 00:57 schrieb Patrick McLean:
> > Currently the ASPEED PCI vendor ID is defined in
> > drivers/gpu/drm/ast/ast_drv.c, move that to include/linux/pci_ids.h
> > with all the rest of the PCI vendor ID definitions.
Hi,
On 2023/4/19 23:46, Thomas Zimmermann wrote:
Hi
Am 19.04.23 um 17:09 schrieb Daniel Vetter:
On Tue, 18 Apr 2023 at 20:16, Sui Jingfeng <15330273...@189.cn> wrote:
Hi,
On 2023/4/19 01:52, Sui Jingfeng wrote:
Hi,
On 2023/4/18 16:32, Daniel Vetter wrote:
On Mon, Apr 17, 2023 at
From: Fei Yang
The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time because GPU is no longer automatically snooping CPU
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out its life cycle, {set, get}_caching ioctl's
are no longer supported from MTL onward. With that change caching
policy can only be set at object creation time. The current code
applies a
From: Fei Yang
Currently the KMD is using enum i915_cache_level to set caching policy for
buffer objects. This is flaky because the PAT index which really controls
the caching behavior in PTE has far more levels than what's defined in the
enum. In addition, the PAT index is platform dependent,
From: Fei Yang
The series includes patches needed to enable MTL.
Also add new extension for GEM_CREATE uAPI to let
user space set cache policy for buffer objects.
v2: addressing review comments and checkpatch warnings
Fei Yang (7):
drm/i915/mtl: Set has_llc=0
drm/i915/mtl: Add PTE encode
From: Fei Yang
This patch is a preparation for replacing enum i915_cache_level with PAT
index. Caching policy for buffer objects is set through the PAT index in
PTE, the old i915_cache_level is not sufficient to represent all caching
modes supported by the hardware.
Preparing the transition by
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE encode.
Signed-off-by: Fei Yang
---
From: Fei Yang
On MTL, LLC is not shared between GT and CPU, set has_llc=0.
Signed-off-by: Fei Yang
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index d64e074d7457..272a8ba37b64 100644
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by Media tile update the whole
cache line even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
to different locations within a single cache line.
From: Madhumitha Tolakanahalli Pradeep
On MTL, GT can no longer allocate on LLC - only the CPU can.
This, along with addition of support for L4 cache calls for
a MOCS/PAT table update.
Also the PAT index registers are multicasted for primary GT,
and there is an address jump from index 7 to 8.
On 4/19/2023 10:33, Ceraolo Spurio, Daniele wrote:
On 4/19/2023 10:12 AM, John Harrison wrote:
On 4/19/2023 10:02, John Harrison wrote:
On 4/18/2023 16:24, Ceraolo Spurio, Daniele wrote:
Typo doplicate in patch title
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
Hi,
On 2023/4/20 00:31, Daniel Vetter wrote:
On Thu, Apr 20, 2023 at 12:00:41AM +0800, Sui Jingfeng wrote:
Hi,
Sorry about reply to you so late,
our downstream (product kernel side) userspace GPU/DC driver
has been tested out a few bugs, I'm asking to fulfill my duty to that part
all days.
Replace the use of ttm_execbuf_util helpers with the drm_exec helpers.
Signed-off-by: Francois Dugast
Signed-off-by: Matthew Brost
---
drivers/gpu/drm/xe/Kconfig | 1 +
drivers/gpu/drm/xe/tests/xe_bo.c | 17 +-
drivers/gpu/drm/xe/xe_bo.c | 29 +--
From: Christian König
This adds the infrastructure for an execution context for GEM buffers
which is similar to the existinc TTMs execbuf util and intended to replace
it in the long term.
The basic functionality is that we abstracts the necessary loop to lock
many different GEM buffers with
From: Danilo Krummrich
Signed-off-by: Danilo Krummrich
---
drivers/gpu/drm/drm_exec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_exec.c b/drivers/gpu/drm/drm_exec.c
index df546cc5a227..f645d22a0863 100644
--- a/drivers/gpu/drm/drm_exec.c
+++
This makes Xe use the new drm_exec helpers provided by this series,
which is not merged yet:
https://patchwork.freedesktop.org/series/114464/
with this fix:
https://patchwork.freedesktop.org/patch/530670/?series=112994=4
v3 includes code shared by Matthew Brost.
v2: add a first patch with
On 4/19/2023 10:12 AM, John Harrison wrote:
On 4/19/2023 10:02, John Harrison wrote:
On 4/18/2023 16:24, Ceraolo Spurio, Daniele wrote:
Typo doplicate in patch title
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
It was noticed that duplicte entries in the
Hi Thomas,
Am 17.04.23 um 16:12 schrieb Arnd Bergmann:>> On Mon, Apr 17, 2023, at 14:56,
Thomas Zimmermann wrote:
Various architectures provide with helpers for fbdev
framebuffer devices. Share the contained code where possible. There
is already , which implements generic (as in
'empty')
On 4/19/2023 10:02, John Harrison wrote:
On 4/18/2023 16:24, Ceraolo Spurio, Daniele wrote:
Typo doplicate in patch title
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
It was noticed that duplicte entries in the firmware table could cause
typo duplicte
an
On 4/18/2023 16:24, Ceraolo Spurio, Daniele wrote:
Typo doplicate in patch title
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
It was noticed that duplicte entries in the firmware table could cause
typo duplicte
an infinite loop in the firmware loading code
> On 17.04.2023 08:25, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> The design is to keep Buffer Object's caching policy immutable through
>> out its life cycle. This patch ends the support for set caching ioctl
>> from MTL onward. While doing that we also set BO's to be 1-way
>> coherent at
On Tue, Apr 18, 2023 at 08:42:46PM +0200, Geert Uytterhoeven wrote:
> Fbtest contains some very simple validation of the fbdev userspace API
> contract. When used with shmob-drm, it reports the following warnings
> and errors:
>
> height changed from 68 to 0
> height was rounded down
>
>> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> index 1803a633ed64..98e682b7df07 100644
>> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
>> @@ -415,12 +415,6 @@ static int
On 4/18/23 23:35, Heiner Kallweit wrote:
On 19.04.2023 02:10, Justin Chen wrote:
Add support for the Broadcom ASP 2.0 Ethernet controller which is first
introduced with 72165. This controller features two distinct Ethernet
ports that can be independently operated.
This patch supports:
[snip]
On Wed, Apr 19, 2023 at 09:30:11AM -0700, Nathan Chancellor wrote:
> On Wed, Apr 19, 2023 at 06:24:37PM +0200, Daniel Vetter wrote:
> > On Tue, Apr 18, 2023 at 07:34:44PM +0100, Mark Brown wrote:
> > > On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote:
> > >
> > > > Note there was a
On Thu, Apr 20, 2023 at 12:00:41AM +0800, Sui Jingfeng wrote:
> Hi,
>
> Sorry about reply to you so late,
>
> our downstream (product kernel side) userspace GPU/DC driver
>
> has been tested out a few bugs, I'm asking to fulfill my duty to that part
> all days.
>
> I may slow to reply, but I
On Wed, Apr 19, 2023 at 06:24:37PM +0200, Daniel Vetter wrote:
> On Tue, Apr 18, 2023 at 07:34:44PM +0100, Mark Brown wrote:
> > On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote:
> >
> > > Note there was a ppc compile fail, which is why we pushed the ttm revert.
> > > That /should/
On 2023-04-19 06:07, Lucas Stach wrote:
> Am Mittwoch, dem 19.04.2023 um 10:53 +0100 schrieb Steven Price:
>> On 19/04/2023 10:44, Lucas Stach wrote:
>>> Hi Steven,
>>>
>>> Am Mittwoch, dem 19.04.2023 um 10:39 +0100 schrieb Steven Price:
On 18/04/2023 11:04, Danilo Krummrich wrote:
> It
On Tue, Apr 18, 2023 at 07:34:44PM +0100, Mark Brown wrote:
> On Sun, Apr 16, 2023 at 09:58:50AM +0200, Daniel Vetter wrote:
>
> > Note there was a ppc compile fail, which is why we pushed the ttm revert.
> > That /should/ be fixed now, but would be good if you can confirm?
>
> According to
On 4/18/2023 15:46, Ceraolo Spurio, Daniele wrote:
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
When reduced version firmware files were added (matching major
component being the only strict requirement), the minor version was
still tracked and a notification
>> On MTL, GT can no longer allocate on LLC - only the CPU can.
>> This, along with addition of support for L4 cache calls a
> s/calls a/calls for a
Will update
>> MOCS/PAT table update.
>> Alos the PAT index registers are multicasted for primary GT,
> s/Alos/Also
>> and there is an address jump
On 4/19/2023 2:28 AM, Marijn Suijten wrote:
On 2023-04-18 09:06:34, Abhinav Kumar wrote:
On 4/17/2023 4:14 PM, Marijn Suijten wrote:
The WB debug log mask ended up never being assigned, leading to writes
to this block to never be logged even if the mask is enabled in
dpu_hw_util_log_mask
>> void setup_private_pat(struct intel_gt *gt)
>>
>> GEM_BUG_ON(GRAPHICS_VER(i915) < 8);
>>
>> -if (GRAPHICS_VER_FULL(i915) >= IP_VER(12, 50))
>> -xehp_setup_private_ppat(gt);
>> -else if (GRAPHICS_VER(i915) >= 12)
>> -tgl_setup_private_ppat(uncore);
>> -
Hi,
Sorry about reply to you so late,
our downstream (product kernel side) userspace GPU/DC driver
has been tested out a few bugs, I'm asking to fulfill my duty to that
part all days.
I may slow to reply, but I really love to reply.
On 2023/4/19 23:09, Daniel Vetter wrote:
On Tue, 18
> Hi Fei,
>
> On Sun, Apr 16, 2023 at 11:24:57PM -0700, fei.y...@intel.com wrote:
>> From: Madhumitha Tolakanahalli Pradeep
>>
>>
>> On MTL, GT can no longer allocate on LLC - only the CPU can.
>> This, along with addition of support for L4 cache calls a MOCS/PAT
>> table update.
>> Alos the PAT
Hi
Am 19.04.23 um 17:09 schrieb Daniel Vetter:
On Tue, 18 Apr 2023 at 20:16, Sui Jingfeng <15330273...@189.cn> wrote:
Hi,
On 2023/4/19 01:52, Sui Jingfeng wrote:
Hi,
On 2023/4/18 16:32, Daniel Vetter wrote:
On Mon, Apr 17, 2023 at 07:32:19PM +0800, Sui Jingfeng wrote:
The fbdev test of
On 4/18/2023 16:14, Ceraolo Spurio, Daniele wrote:
On 4/14/2023 5:57 PM, john.c.harri...@intel.com wrote:
From: John Harrison
The validation of the firmware table was being done inside the code
for scanning the table for the next available firmware blob. Which is
unnecessary. Potentially, it
From: Sean Paul
Now that all of the HDCP 1.x logic has been migrated to the central HDCP
helpers, use it in the i915 driver.
The majority of the driver code for HDCP 1.x will live in intel_hdcp.c,
however there are a few helper hooks which are connector-specific and
need to be partially or
From: Sean Paul
Add HDCP 1.x support to msm DP bridges using the new HDCP
helpers.
Cc: Stephen Boyd
Reviewed-by: Stephen Boyd
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v2:
-Squash [1] into this patch with the following changes (Stephen)
-Update the sc7180 dtsi
From: Sean Paul
Add the bindings for the MSM DisplayPort HDCP registers
which are required to write the HDCP key into the display controller as
well as the registers to enable HDCP authentication/key
exchange/encryption.
Cc: Rob Herring
Cc: Stephen Boyd
Reviewed-by: Rob Herring
Reviewed-by:
From: Sean Paul
Add the register ranges required for HDCP key injection and
HDCP TrustZone interaction as described in the dt-bindings for the
sc7180 dp controller.
Reviewed-by: Douglas Anderson
Signed-off-by: Sean Paul
Signed-off-by: Mark Yacoub
---
Changes in v3:
-Split off into a new
From: Sean Paul
The shim functions return error codes, but they are discarded in
intel_hdcp.c. This patch plumbs the return codes through so they are
properly handled.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Reviewed-by: Suraj Kandpal
Signed-off-by: Sean Paul
Signed-off-by: Mark
From: Sean Paul
Stick all of the setup for HDCP into a dedicated function. No functional
change, but this will facilitate moving HDCP logic into helpers.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean Paul
---
Changes in v2:
-None
Changes in v3:
-None
Changes in v4:
From: Sean Paul
Update the connector's property value in 2 cases which were
previously missed:
1- Content type changes. The value should revert back to DESIRED from
ENABLED in case the driver must re-authenticate the link due to the
new content type.
2- Userspace sets value to DESIRED
From: Sean Paul
Expand upon the HDCP helper library to manage HDCP enable, disable, and check.
Previous to this patch, the majority of the state management and sink
interaction is tucked inside the Intel driver with the understanding
that once a new platform supported HDCP we could make good
From: Sean Paul
Instead of forcing a modeset in the hdcp atomic check, rename to
drm_hdcp_has_changed and return true if the content protection value
is changing and let the driver decide whether a modeset is required or not.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Signed-off-by: Sean
From: Sean Paul
Move the hdcp atomic check from i915 to drm_hdcp so other
drivers can use it. No functional changes, just cleaned up some of the
code when moving it over.
Acked-by: Jani Nikula
Reviewed-by: Rodrigo Vivi
Reviewed-by: Dmitry Baryshkov
Signed-off-by: Sean Paul
Signed-off-by:
Hi all,
This is v10 of the HDCP patches. The patches are authored by Sean Paul.
I rebased and addressed the review comments in v6-v10.
Main change in v10 is handling the kernel test bot warnings.
Patches 1-4 focus on moving the common HDCP helpers to common DRM.
This introduces a slight change
On 17.04.2023 08:24, fei.y...@intel.com wrote:
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by Media tile update the whole
cache line even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
to
On 4/17/2023 8:24 AM, fei.y...@intel.com wrote:
From: Fei Yang
This patch implements Wa_22016122933.
In MTL, memory writes initiated by Media tile update the whole
cache line even for partial writes. This creates a coherency
problem for cacheable memory if both CPU and GPU are writing data
On 4/11/23 20:09, Rodrigo Siqueira wrote:
> This commit adds missing luminance control registers to enable a more
> standard way (VESA) to deal with eDP luminance control.
>
> Cc: Anthony Koo
> Cc: Iswara Negulendran
> Cc: Felipe Clark
> Cc: Harry Wentland
> Signed-off-by: Rodrigo Siqueira
On 4/17/2023 8:24 AM, fei.y...@intel.com wrote:
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE
On Tue, 18 Apr 2023 at 20:16, Sui Jingfeng <15330273...@189.cn> wrote:
>
> Hi,
>
> On 2023/4/19 01:52, Sui Jingfeng wrote:
> > Hi,
> >
> > On 2023/4/18 16:32, Daniel Vetter wrote:
> >> On Mon, Apr 17, 2023 at 07:32:19PM +0800, Sui Jingfeng wrote:
> >>> The fbdev test of IGT may write after EOF,
On Wed, Apr 19, 2023 at 6:36 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 15:56, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 1:53 AM Tvrtko Ursulin
> > wrote:
> >>
> >>
> >> On 17/04/2023 21:12, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>> Normally this would be the same information that
On Wed, Apr 19, 2023 at 7:06 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 17:08, Rob Clark wrote:
> > On Tue, Apr 18, 2023 at 7:58 AM Tvrtko Ursulin
> > wrote:
> >> On 18/04/2023 15:39, Rob Clark wrote:
> >>> On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> >>> wrote:
>
> From: Tvrtko
On 4/17/2023 8:24 AM, fei.y...@intel.com wrote:
From: Madhumitha Tolakanahalli Pradeep
On MTL, GT can no longer allocate on LLC - only the CPU can.
This, along with addition of support for L4 cache calls a
s/calls a/calls for a
MOCS/PAT table update.
Alos the PAT index registers are
On Wed, Apr 19, 2023 at 6:16 AM Tvrtko Ursulin
wrote:
>
>
> On 18/04/2023 18:18, Rob Clark wrote:
> > On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
> > wrote:
> >>
> >> From: Tvrtko Ursulin
> >>
> >> For drivers who only wish to show one memory region called 'system,
> >> and only account the
On 4/17/2023 8:24 AM, fei.y...@intel.com wrote:
From: Fei Yang
On MTL, GT is no longer allocated on LLC, set has_llc=0.
This statement is bit unclear to me. I would say "On MTL, LLC is not
shared between GT and CPU"
Otherwise
Reviewed-by: Nirmoy Das
Signed-off-by: Fei Yang
---
On 18/04/2023 17:08, Rob Clark wrote:
On Tue, Apr 18, 2023 at 7:58 AM Tvrtko Ursulin
wrote:
On 18/04/2023 15:39, Rob Clark wrote:
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
Show how more driver specific set of memory stats could be shown,
more
On 17.04.2023 08:24, fei.y...@intel.com wrote:
From: Madhumitha Tolakanahalli Pradeep
On MTL, GT can no longer allocate on LLC - only the CPU can.
This, along with addition of support for L4 cache calls a
MOCS/PAT table update.
Alos the PAT index registers are multicasted for primary GT,
and
Applied. Thanks!
Alex
On Wed, Apr 19, 2023 at 8:24 AM Christian König
wrote:
>
> Am 19.04.23 um 14:20 schrieb hackyzh002:
> > The type of size is unsigned, if size is 0x4000, there will be an
> > integer overflow, size will be zero after size *= sizeof(uint32_t),
> > will cause
On 18/04/2023 15:56, Rob Clark wrote:
On Tue, Apr 18, 2023 at 1:53 AM Tvrtko Ursulin
wrote:
On 17/04/2023 21:12, Rob Clark wrote:
From: Rob Clark
Normally this would be the same information that can be obtained in
other ways. But in some cases the process opening the drm fd is merely
a
On 10/04/2023 23:35, Ashutosh Dixit wrote:
Instead of erroring out when GuC reset is in progress, block waiting for
GuC reset to complete which is a more reasonable uapi behavior.
v2: Avoid race between wake_up_all and waiting for wakeup (Rodrigo)
Signed-off-by: Ashutosh Dixit
---
On Wed, 19 Apr 2023, Jeff Layton wrote:
> I've been experiencing some intermittent crashes down in the display
> driver code. The symptoms are ususally a line like this in dmesg:
>
> amdgpu :30:00.0: [drm] Failed to create MST payload for port
> 6d3a3885: -5
>
> ...followed by an
On 18/04/2023 18:18, Rob Clark wrote:
On Mon, Apr 17, 2023 at 8:56 AM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
For drivers who only wish to show one memory region called 'system,
and only account the GEM buffer object handles under it.
Signed-off-by: Tvrtko Ursulin
---
Am 19.04.23 um 15:13 schrieb Mikhail Gavrilov:
On Wed, Apr 19, 2023 at 1:12 PM Christian König
wrote:
I'm already looking into this, but can't figure out why we run into
problems here.
What happens is that a CS is aborted without sending the job to the
scheduler and in this case the cleanup
On Wed, Apr 19, 2023 at 1:12 PM Christian König
wrote:
>
> I'm already looking into this, but can't figure out why we run into
> problems here.
>
> What happens is that a CS is aborted without sending the job to the
> scheduler and in this case the cleanup function doesn't seem to work.
>
>
On 17.04.2023 08:25, fei.y...@intel.com wrote:
From: Fei Yang
The design is to keep Buffer Object's caching policy immutable through
out its life cycle. This patch ends the support for set caching ioctl
from MTL onward. While doing that we also set BO's to be 1-way coherent
at creation time
On 17.04.2023 08:24, fei.y...@intel.com wrote:
From: Fei Yang
PTE encode functions are platform dependent. This patch implements
PTE functions for MTL, and ensures the correct PTE encode function
is used by calling pte_encode function pointer instead of the
hardcoded gen8 version of PTE
On 17.04.2023 08:24, fei.y...@intel.com wrote:
From: Fei Yang
On MTL, GT is no longer allocated on LLC, set has_llc=0.
Signed-off-by: Fei Yang
Reviewed-by: Andrzej Hajda
Regards
Andrzej
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git
Hi Fei,
On Wed, Apr 19, 2023 at 12:59:09PM +0200, Andi Shyti wrote:
> Hi Fei,
>
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> > @@ -743,6 +743,13 @@ struct i915_vma *intel_guc_allocate_vma(struct
> > intel_guc *guc, u32 size)
> > if
On Sun, Apr 16, 2023 at 11:25:03PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> To comply with the design that buffer objects shall have immutable
> cache setting through out its life cycle, {set, get}_caching ioctl's
/its/their/
> are no longer supported from MTL onward. With that
Am 19.04.23 um 14:20 schrieb hackyzh002:
The type of size is unsigned, if size is 0x4000, there will be an
integer overflow, size will be zero after size *= sizeof(uint32_t),
will cause uninitialized memory to be referenced later
Signed-off-by: hackyzh002
Reviewed-by: Christian König
On Tue, 18 Apr 2023 17:10:13 -0700, Justin Chen wrote:
> From: Florian Fainelli
>
> Add a binding document for the Broadcom ASP 2.0 Ethernet
> controller.
>
> Signed-off-by: Florian Fainelli
> Signed-off-by: Justin Chen
> ---
> .../devicetree/bindings/net/brcm,asp-v2.0.yaml | 146
>
Hi Fei,
On Sun, Apr 16, 2023 at 11:25:02PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> Currently the KMD is using enum i915_cache_level to set caching policy for
> buffer objects. This is flaky because the PAT index which really controls
> the caching behavior in PTE has far more
I've been experiencing some intermittent crashes down in the display
driver code. The symptoms are ususally a line like this in dmesg:
amdgpu :30:00.0: [drm] Failed to create MST payload for port
6d3a3885: -5
...followed by an Oops due to a NULL pointer dereference.
Switch to
Hi Fei,
[...]
> @@ -180,6 +182,14 @@ struct drm_i915_private *mock_gem_device(void)
> I915_GTT_PAGE_SIZE_2M;
>
> RUNTIME_INFO(i915)->memory_regions = REGION_SMEM;
> +
> +
double space here, otherwise:
Reviewed-by: Andi Shyti
Andi
> + /* simply use legacy cache
Hi Fei,
On Sun, Apr 16, 2023 at 11:25:00PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> The design is to keep Buffer Object's caching policy immutable through
> out its life cycle. This patch ends the support for set caching ioctl
> from MTL onward. While doing that we also set BO's to
Hi Fei,
On Sun, Apr 16, 2023 at 11:24:58PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> PTE encode functions are platform dependent. This patch implements
> PTE functions for MTL, and ensures the correct PTE encode function
> is used by calling pte_encode function pointer instead of
Hi Fei,
On Sun, Apr 16, 2023 at 11:24:57PM -0700, fei.y...@intel.com wrote:
> From: Madhumitha Tolakanahalli Pradeep
>
>
> On MTL, GT can no longer allocate on LLC - only the CPU can.
> This, along with addition of support for L4 cache calls a
> MOCS/PAT table update.
> Alos the PAT index
Hi Fei,
On Sun, Apr 16, 2023 at 11:24:56PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> On MTL, GT is no longer allocated on LLC, set has_llc=0.
>
> Signed-off-by: Fei Yang
Reviewed-by: Andi Shyti
Andi
Hi Fei,
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
> @@ -743,6 +743,13 @@ struct i915_vma *intel_guc_allocate_vma(struct intel_guc
> *guc, u32 size)
> if (IS_ERR(obj))
> return ERR_CAST(obj);
>
> + /*
> + *
On Mon, Apr 17, 2023 at 6:55 AM Adam Ford wrote:
>
> On Mon, Apr 17, 2023 at 3:43 AM Lucas Stach wrote:
> >
> > Hi Adam,
> >
> > Am Samstag, dem 15.04.2023 um 05:40 -0500 schrieb Adam Ford:
> > > If there is more than one lane, the HFP, HBP, and HSA is calculated in
> > > bytes/pixel, then they
to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/hackyzh002/drm-amdgpu-Fix-integer-overflow-in-amdgpu_cs_pass1/20230419-125344
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
patch
On Tue, Apr 18, 2023 at 3:47 AM Lucas Stach wrote:
>
> Am Dienstag, dem 18.04.2023 um 10:30 +0200 schrieb Marek Vasut:
> > On 4/18/23 04:29, Adam Ford wrote:
> > > On Sun, Apr 16, 2023 at 5:08 PM Marek Vasut wrote:
> > > >
> > > > On 4/15/23 12:41, Adam Ford wrote:
> > > > > Fetch the clock rate
Am Mittwoch, dem 19.04.2023 um 10:53 +0100 schrieb Steven Price:
> On 19/04/2023 10:44, Lucas Stach wrote:
> > Hi Steven,
> >
> > Am Mittwoch, dem 19.04.2023 um 10:39 +0100 schrieb Steven Price:
> > > On 18/04/2023 11:04, Danilo Krummrich wrote:
> > > > It already happend a few times that patches
From: Petr Tesarik
Do not walk the list of dynamically allocated bounce buffers if the
list is empty. This avoids taking dma_io_tlb_dyn_lock for devices
which do not use any dynamically allocated bounce buffers.
When unmapping the last dynamically allocated bounce buffer, the
flag is set to
From: Petr Tesarik
These mappings are never done from atomic context. If a dynamically
allocated bounce buffer is used for the mapping, this change allows
to allocate from CMA.
Signed-off-by: Petr Tesarik
---
drivers/gpu/drm/drm_gem_shmem_helper.c | 2 +-
drivers/gpu/drm/drm_prime.c
From: Petr Tesarik
The main goal of allocating bounce buffers dynamically is to allow
allocating a minimal fixed swiotlb at boot time but avoid hard
limits on the amount of I/O that can be handled later.
Compared to fixed IO TLB slots, dynamic allocation of bounce buffers
typically increases
From: Petr Tesarik
The software IO TLB was designed with the assumption that it is not
used much, especially on 64-bit systems, so a small fixed memory
area (currently 64 MiB) is sufficient to handle the few cases which
still require a bounce buffer. However, these cases are not so rare
in some
From: Petr Tesarik
Introduce a DMA attribute to tell the DMA-mapping subsystem that
the operation is allowed to sleep.
This patch merely adds the flag, but it does not do anything at
the moment.
Signed-off-by: Petr Tesarik
---
Documentation/core-api/dma-attributes.rst | 10 ++
On 19/04/2023 10:53, Steven Price wrote:
> On 19/04/2023 10:44, Lucas Stach wrote:
>> Hi Steven,
>>
>> Am Mittwoch, dem 19.04.2023 um 10:39 +0100 schrieb Steven Price:
>>> On 18/04/2023 11:04, Danilo Krummrich wrote:
It already happend a few times that patches slipped through which
From: Petr Tesarik
Move swiotlb initialization code to swiotlb.h. This change also
allows to provide a stub implementation if swiotlb is not
configured, getting rid of an #ifdef in driver core.
Signed-off-by: Petr Tesarik
---
drivers/base/core.c | 4 +---
include/linux/swiotlb.h | 12
From: Petr Tesarik
To prepare for the introduction of dynamically allocated bounce
buffers, separate out common code and code which handles non-dynamic
(aka fixed) bounce buffers.
No functional change, but this commit should make the addition of
dynamic allocations easier to review.
From: Petr Tesarik
The goal of my work is to provide more flexibility in the sizing of
SWIOTLB.
The software IO TLB was designed with these assumptions:
1. It would not be used much, especially on 64-bit systems.
2. A small fixed memory area (64 MiB by default) is sufficient to
handle the
101 - 200 of 224 matches
Mail list logo
