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.
Hi Dave, Daniel,
Fixes for 6.3.
The following changes since commit 6a8f57ae2eb07ab39a6f0ccad60c760743051026:
Linux 6.3-rc7 (2023-04-16 15:23:53 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.3-2023-04-19
for you to
The fbdev test of IGT may write after EOF, which lead to out-of-bound
access for drm drivers hire fbdev-generic. For example, run fbdev test
on a x86+ast2400 platform, with 1680x1050 resolution, will cause the
linux kernel hang with the following call trace:
Oops: [#1] PREEMPT SMP PTI
On Mon, Apr 17, 2023 at 6:23 PM Marek Vasut wrote:
>
> On 4/18/23 00:24, Adam Ford wrote:
> > On Mon, Apr 17, 2023 at 3:08 PM Marek Vasut wrote:
> >>
> >> On 4/17/23 13:57, Adam Ford wrote:
> >>> On Sun, Apr 16, 2023 at 5:13 PM Marek Vasut wrote:
>
> On 4/15/23 12:41, Adam Ford wrote:
gcc reports
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_hwseq.c:
In function ‘dcn21_set_backlight_level’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn21/dcn21_hwseq.c:229:18:
error: unused variable ‘otg_inst’ [-Werror=unused-variable]
229 | uint32_t otg_inst =
On 20.04.2023 03:28, Abhinav Kumar wrote:
>
>
> On 4/19/2023 6:26 PM, Konrad Dybcio wrote:
>>
>>
>> On 20.04.2023 03:25, Dmitry Baryshkov wrote:
>>> On 20/04/2023 04:14, Konrad Dybcio wrote:
Almost all SoCs from SDM845 to SM8550 inclusive feature a GC1.8
dspp sub-block in addition
On 4/19/2023 6:26 PM, Konrad Dybcio wrote:
On 20.04.2023 03:25, Dmitry Baryshkov wrote:
On 20/04/2023 04:14, Konrad Dybcio wrote:
Almost all SoCs from SDM845 to SM8550 inclusive feature a GC1.8
dspp sub-block in addition to PCCv4. The other block differ a bit
more, but none of them are
On 20.04.2023 03:25, Dmitry Baryshkov wrote:
> On 20/04/2023 04:14, Konrad Dybcio wrote:
>> Almost all SoCs from SDM845 to SM8550 inclusive feature a GC1.8
>> dspp sub-block in addition to PCCv4. The other block differ a bit
>> more, but none of them are supported upstream.
>>
>> This series
On 20/04/2023 04:14, Konrad Dybcio wrote:
Almost all SoCs from SDM845 to SM8550 inclusive feature a GC1.8
dspp sub-block in addition to PCCv4. The other block differ a bit
more, but none of them are supported upstream.
This series adds configures the GCv1.8 on all the relevant SoCs.
Does this
SDM845 was the first SoC to include both PCC v4 and GC v1.8.
We don't currently support any other blocks but the common config
for these two can be reused for a large amount of SoCs.
Rename it to indicate the origin of that combo.
Signed-off-by: Konrad Dybcio
---
There's a plethora of S(D)M-era SoCs that have a GC v1.8 but never
declared, let alone enabled it. Do so!
Signed-off-by: Konrad Dybcio
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h | 8
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h | 8
Almost all SoCs from SDM845 to SM8550 inclusive feature a GC1.8
dspp sub-block in addition to PCCv4. The other block differ a bit
more, but none of them are supported upstream.
This series adds configures the GCv1.8 on all the relevant SoCs.
Signed-off-by: Konrad Dybcio
---
Konrad Dybcio (2):
On 17/04/2023 23:21, Marijn Suijten wrote:
Since DPU 5.0.0 the TEARCHECK registers and interrupts moved out of the
PINGPONG block and into the INTF. Implement the necessary callbacks in
the INTF block, and use these callbacks together with the INTF_TEAR
interrupts.
Signed-off-by: Marijn
On 17/04/2023 23:21, Marijn Suijten wrote:
These functions are always called consecutively and are best bundled
together for simplicity, especially when the same structure of callbacks
will be replicated later on the interface block for INTF TE support.
The enable_tearcheck(false) case is now
On 17/04/2023 23:21, Marijn Suijten wrote:
All SoCs since DPU 5.0.0 have the tear interrupt registers moved out of
the PINGPONG block and into the INTF block. Wire up these interrupts
and IRQ masks on all supported hardware.
Signed-off-by: Marijn Suijten
---
I have a number of comments but most are personal preferences and so i labelled
them nits.
I did catch a few minor coding styling issues and am assuming those need to be
enforced as per i915/kernel rules?
That said, since they are so minor (or maybe they are not strict), I'm
providing a
On 20/04/2023 04:01, Konrad Dybcio wrote:
On 20.04.2023 03:00, Dmitry Baryshkov wrote:
On 17/04/2023 23:21, Marijn Suijten wrote:
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block, including vsync source selection
that was previously part
On 17/04/2023 23:21, Marijn Suijten wrote:
As the INTF block is going to attain more interrupts that don't share
the same MDP_SSPP_TOP0_INTR register, factor out the _reg argument for
the caller to construct the right interrupt index (register and bit
index) to not make the interrupt bit
On 20.04.2023 03:00, Dmitry Baryshkov wrote:
> On 17/04/2023 23:21, Marijn Suijten wrote:
>> Since hardware revision 5.0.0 the TE configuration moved out of the
>> PINGPONG block into the INTF block, including vsync source selection
>> that was previously part of MDP top. Writing to the
On 17/04/2023 23:21, Marijn Suijten wrote:
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block, including vsync source selection
that was previously part of MDP top. Writing to the MDP_VSYNC_SEL
register has no effect anymore and is omitted
On 17/04/2023 23:21, Marijn Suijten wrote:
Since hardware revision 5.0.0 the TE configuration moved out of the
PINGPONG block into the INTF block. Writing these registers has no
effect, and is omitted downstream via the DPU/SDE_PINGPONG_TE feature
flag. This flag is only added to PINGPONG
On 17/04/2023 23:21, Marijn Suijten wrote:
This autorefresh disable logic in the physical command-mode encoder
consumes three callbacks to the pingpong block, and will explode in
unnecessary complexity when the same callbacks need to be called on the
interface block instead to accommodate INTF
On 17/04/2023 23:21, Marijn Suijten wrote:
This callback was migrated from downstream when DPU1 was first
introduced to mainline, but never used by any component. Drop it to
save some lines and unnecessary confusion.
Suggested-by: Dmitry Baryshkov
Signed-off-by: Marijn Suijten
---
On 17/04/2023 23:21, Marijn Suijten wrote:
A bunch of registers were appended at the end in e.g. 91143873a05d
("drm/msm/dpu: Add MISR register support for interface") rather than
being inserted in a place that maintains numerical sorting. Restore
that.
Assuming that = "sort order":
On 17/04/2023 23:21, Marijn Suijten wrote:
A bunch of registers are indented with two extra spaces, looking as if
these are values corresponding to the previous register which is not the
case, rather these are simply also register offsets and should only have
a single space separating them and
On 17/04/2023 23:21, Marijn Suijten wrote:
The INTF_FRAME_LINE_COUNT_EN, INTF_FRAME_COUNT and INTF_LINE_COUNT
registers are already defined higher up, in the right place when sorted
numerically.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
Signed-off-by: Marijn Suijten
---
On 17/04/2023 23:21, Marijn Suijten wrote:
SM8550 only comes with a DITHER subblock inside the PINGPONG block,
hence the name and a block length of zero. However, the PP_BLK macro
name was typo'd to DIPHER rather than DITHER.
Fixes: efcd0107727c ("drm/msm/dpu: add support for SM8550")
On 17/04/2023 23:21, Marijn Suijten wrote:
These offsets do not fall under the MDP TOP block and do not fit the
comment right above. Move them to dpu_hw_interrupts.c next to the
repsective MDP_INTF_x_OFF interrupt block offsets.
Fixes: 25fdd5933e4c ("drm/msm: Add SDM845 DPU support")
On 17/04/2023 23:21, Marijn Suijten wrote:
No hardware beyond kona (sm8250) defines the TE2 PINGPONG sub-block
offset downstream. Even though neither downstream nor upstream utilizes
these registers in any way, remove the erroneous specification for
SC8280XP, SM8350 and SM8450 to prevent
On 17/04/2023 23:21, Marijn Suijten wrote:
Neither of these SoCs has INTF0, they only have a DSI interface on index
1. Stop enabling an interrupt that can't fire.
Fixes: 3581b7062cec ("drm/msm/disp/dpu1: add support for display on SM6115")
Fixes: 5334087ee743 ("drm/msm: add support for QCM2290
On 20/04/2023 00:26, Konrad Dybcio wrote:
On 19.04.2023 22:11, Jeykumar Sankaran wrote:
On 4/19/2023 12:48 PM, Konrad Dybcio wrote:
On 19.04.2023 21:06, Jeykumar Sankaran wrote:
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR),
On 18/04/2023 15:10, Konrad Dybcio wrote:
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
Nit: msm_mdss.c is not DPU1.
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation
On 18/04/2023 15:10, Konrad Dybcio wrote:
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation for supporting the
On 20/04/2023 03:27, Abhinav Kumar wrote:
On 4/19/2023 5:21 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:17, Abhinav Kumar wrote:
On 4/19/2023 5:11 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:10, Abhinav Kumar wrote:
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10,
On 17/04/2023 18:30, Konrad Dybcio wrote:
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation for supporting the
On 4/19/2023 5:21 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:17, Abhinav Kumar wrote:
On 4/19/2023 5:11 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:10, Abhinav Kumar wrote:
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and
On 17/04/2023 18:30, Konrad Dybcio wrote:
The DPU1 driver needs to handle all MDPn<->DDR paths, as well as
CPU<->SLAVE_DISPLAY_CFG. The former ones share how their values are
calculated, but the latter one has static predefines spanning all SoCs.
In preparation for supporting the
On 19/04/2023 23:05, Jeykumar Sankaran wrote:
Resending the question as the previous one was sent only to the
freedreno list. Apologies for spamming!
On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another path that needs to be
On 20/04/2023 03:17, Abhinav Kumar wrote:
On 4/19/2023 5:11 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:10, Abhinav Kumar wrote:
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and bitfields were determined from the downstream
On 18/04/2023 21:10, Arnaud Vrac wrote:
Some Qualcomm SoCs that support HDMI also support CEC, including MSM8996
and MSM8998. The hardware block can handle a single CEC logical address
and broadcast messages.
Port the CEC driver from downstream msm-4.4 kernel. It has been tested
on MSM8998 and
On 4/19/2023 5:11 PM, Dmitry Baryshkov wrote:
On 20/04/2023 03:10, Abhinav Kumar wrote:
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and bitfields were determined from the downstream
msm-4.4 driver.
Signed-off-by: Arnaud Vrac
On 20/04/2023 03:10, Abhinav Kumar wrote:
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and bitfields were determined from the downstream
msm-4.4 driver.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 62
On 4/19/2023 4:53 PM, Dmitry Baryshkov wrote:
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and bitfields were determined from the downstream
msm-4.4 driver.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 62
-
1
On 18/04/2023 21:10, Arnaud Vrac wrote:
When edid has been read after hpd, pass it to the cec adapter so that it
can extract the physical address of the device on the cec bus.
Invalidate the physical address when hpd is low.
If there is another bridge in a chain (e.g. display-connector) which
On 18/04/2023 21:10, Arnaud Vrac wrote:
The register names and bitfields were determined from the downstream
msm-4.4 driver.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/hdmi/hdmi.xml.h | 62 -
1 file changed, 61 insertions(+), 1 deletion(-)
I
On Wed, Apr 19, 2023 at 07:56:47PM +0200, Francois Dugast wrote:
> 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
On Wed, Apr 19, 2023 at 07:56:50PM +0200, Francois Dugast wrote:
> 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
On 13/04/2023 20:25, Kandpal, Suraj wrote:
Hi,
Include RC parameters for YCbCr 4:2:2 and 4:2:0 configurations.
Looks Good to me
Reviewed-by: Suraj Kandpal
And gentle reminder for patches 9-12. We would kindly ask to get this
patches reviewed and ready to be merged into drm-intel after
On 19/04/2023 17:41, Arnaud Vrac wrote:
This avoids using lm blocks that support DSPP when not needed, to
keep those resources available.
This will break some of the platforms. Consider qcm2290 which has a
single LM with DSPP. So, _dpu_rm_check_lm_and_get_connected_blks should
be performed
On 19/04/2023 17:41, Arnaud Vrac wrote:
Change lm blocks pairs so that lm blocks with the same features are
paired together:
LM_0 and LM_1 with PP and DSPP
LM_2 and LM_5 with PP
LM_3 and LM_4
This matches the sdm845 configuration and allows using pp or dspp when 2
lm blocks are needed in the
On 19/04/2023 17:41, Arnaud Vrac wrote:
This matches the value for both fbdev and sde implementations in the
downstream msm-4.4 repository.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
On 19/04/2023 17:41, Arnaud Vrac wrote:
Now that cursor sspp blocks can be used for cursor planes, enable them
on msm8998. The dma sspp blocks that were assigned to cursor planes can
now be used for overlay planes instead.
While the change is correct, there is more about it. Composers, using
> Hi Fei,
>
>> +#define MTL_PPGTT_PTE_PAT3 BIT_ULL(62)
>> #define GEN12_PPGTT_PTE_LM BIT_ULL(11)
>> +#define GEN12_PPGTT_PTE_PAT2BIT_ULL(7)
>> +#define GEN12_PPGTT_PTE_NC BIT_ULL(5)
>> +#define GEN12_PPGTT_PTE_PAT1BIT_ULL(4)
>> +#define GEN12_PPGTT_PTE_PAT0BIT_ULL(3)
>>
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
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
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: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out their 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
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
Reviewed-by: Andrzej
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
On MTL, LLC is not shared between GT and CPU, set has_llc=0.
Signed-off-by: Fei Yang
Reviewed-by: Andi Shyti
Reviewed-by: Andrzej Hajda
Reviewed-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 insertion(+)
diff --git
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.
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
v3: make mtl_ggtt_pte_encode static
Fei Yang (7):
drm/i915/mtl: Set
On 19/04/2023 17:41, Arnaud Vrac wrote:
Override the default max cursor size reported to userspace of 64x64.
MSM8998 hw cursor planes support 512x512 size, and other chips use DMA
SSPPs.
Signed-off-by: Arnaud Vrac
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 3 +++
1 file changed, 3
On 19/04/2023 17:41, Arnaud Vrac wrote:
Cursor SSPP must be assigned to the last mixer stage, so we assign an
immutable zpos property with a value higher than primary/overlay planes,
to ensure it will always be on top.
The commit does more than is described in the commit message. Let's do
it
On 19/04/2023 17:41, Arnaud Vrac wrote:
The max_mixer_blendstages hw catalog property represents the number of
planes that can be blended by the lm mixer, excluding the base stage, so
adjust the check for the number of currently assigned planes accordingly.
Signed-off-by: Arnaud Vrac
---
On 19/04/2023 17:41, Arnaud Vrac wrote:
The dpu backend already handles applying alpha to the base stage, so we
can use it to render the bottom plane in all cases. This allows mixing
one additional plane with the hardware mixer.
Signed-off-by: Arnaud Vrac
This might require additional
On 19/04/2023 17:41, Arnaud Vrac wrote:
Do not override the hsync/vsync polarity passed by the encoder when
setting up intf timings. The same logic was used in both the encoder and
intf code to set the DP and DSI polarities, so those interfaces are not
impacted. However for HDMI, the polarities
On 19/04/2023 17:41, Arnaud Vrac wrote:
This avoids using two LMs instead of one when the display width is lower
than the maximum supported value. For example on MSM8996/MSM8998, the
actual maxwidth is 2560, so we would use two LMs for 1280x720 or
1920x1080 resolutions, while one is enough.
On Wed, 19 Apr 2023 12:40:44 -0700, Rodrigo Vivi wrote:
>
Hi Rodrigo,
> On Tue, Apr 18, 2023 at 10:23:50AM -0700, Dixit, Ashutosh wrote:
> > On Mon, 17 Apr 2023 22:35:58 -0700, Rodrigo Vivi wrote:
> > >
> >
> > Hi Rodrigo,
> >
> > > On Mon, Apr 10, 2023 at 03:35:09PM -0700, Ashutosh Dixit wrote:
On Wed, 19 Apr 2023 06:21:27 -0700, Tvrtko Ursulin wrote:
>
Hi Tvrtko,
> 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
Hi Fei,
On Wed, Apr 19, 2023 at 02:12:19PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> To comply with the design that buffer objects shall have immutable
> cache setting through out their life cycle, {set, get}_caching ioctl's
> are no longer supported from MTL onward. With that
Hi Fei,
On Wed, Apr 19, 2023 at 02:12:17PM -0700, fei.y...@intel.com wrote:
> 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
Hi Fei,
On Wed, Apr 19, 2023 at 10:10:24PM +, Yang, Fei wrote:
> > Hi Fei,
> >
> > On Wed, Apr 19, 2023 at 02:12:12PM -0700, fei.y...@intel.com wrote:
> >> From: Fei Yang
> >>
> >> On MTL, LLC is not shared between GT and CPU, set has_llc=0.
> >>
> >> Signed-off-by: Fei Yang
> >
> > just an
On 19/04/2023 17:41, Arnaud Vrac wrote:
Match the values found in the downstream msm-4.4 kernel sde driver.
Signed-off-by: Arnaud Vrac
Fixes: 94391a14fc27 ("drm/msm/dpu1: Add MSM8998 to hw catalog")
Reviewed-by: Dmitry Baryshkov
---
> Hi Fei,
>
> On Wed, Apr 19, 2023 at 02:12:12PM -0700, fei.y...@intel.com wrote:
>> From: Fei Yang
>>
>> On MTL, LLC is not shared between GT and CPU, set has_llc=0.
>>
>> Signed-off-by: Fei Yang
>
> just an unanswered questino from Nirmoy:
>
> This statement is bit unclear to me. I would say
Hi Fei,
> 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,
Hi Fei,
On Wed, Apr 19, 2023 at 02:12:16PM -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 Wed, Apr 19, 2023 at 02:12:15PM -0700, 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
Hi Fei,
> 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
I think nothing
Hi Fei,
On Wed, Apr 19, 2023 at 02:12:13PM -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 for
> a MOCS/PAT table update.
> Also the PAT index
Hi Fei,
On Wed, Apr 19, 2023 at 02:12:12PM -0700, fei.y...@intel.com wrote:
> From: Fei Yang
>
> On MTL, LLC is not shared between GT and CPU, set has_llc=0.
>
> Signed-off-by: Fei Yang
just an unanswered questino from Nirmoy:
This statement is bit unclear to me. I would say "On MTL, LLC
Hi Fei,
> +#define MTL_PPGTT_PTE_PAT3 BIT_ULL(62)
> #define GEN12_PPGTT_PTE_LM BIT_ULL(11)
> +#define GEN12_PPGTT_PTE_PAT2 BIT_ULL(7)
> +#define GEN12_PPGTT_PTE_NC BIT_ULL(5)
> +#define GEN12_PPGTT_PTE_PAT1 BIT_ULL(4)
> +#define GEN12_PPGTT_PTE_PAT0 BIT_ULL(3)
>
> -#define
On 19.04.2023 22:11, Jeykumar Sankaran wrote:
>
>
> On 4/19/2023 12:48 PM, Konrad Dybcio wrote:
>>
>>
>> On 19.04.2023 21:06, Jeykumar Sankaran wrote:
>>>
>>>
>>> On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
another
Hello Gurchetan,
On 4/18/23 02:17, Gurchetan Singh wrote:
> On Sun, Apr 16, 2023 at 4:53 AM Dmitry Osipenko <
> dmitry.osipe...@collabora.com> wrote:
>
>> We have multiple Vulkan context types that are awaiting for the addition
>> of the sync object DRM UAPI support to the VirtIO-GPU kernel
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: 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
To comply with the design that buffer objects shall have immutable
cache setting through out their 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
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 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
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
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
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
v3: make mtl_ggtt_pte_encode static
Fei Yang (7):
drm/i915/mtl: Set
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.
Reviewed-by: Lyude Paul
Thanks!
On Wed, 2023-04-19 at 07:24 -0400, 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
Hi Fei,
On Wed, Apr 19, 2023 at 11:09:34AM -0700, fei.y...@intel.com wrote:
> 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
Thomas Zimmermann wrote:
> Am 19.04.23 um 06:48 schrieb Pierre Asselin:
>>
>> v2 fixes the warnings from a max3() macro with arguments of different
>> types; split the bits_per_pixel assignment to avoid uglyfing the code
>> with too many typecasts.
>
> What exactly was that warning?
A friendly
The fbdev test of IGT may write after EOF, which lead to out-of-bound
access for the drm drivers hire fbdev-generic. However, run fbdev test
on x86 +ast2400 platform, with 1680x1050 resolution, will cause the
linux kernel hang with the following call trace:
Oops: [#1] PREEMPT SMP PTI
Javier Martinez Canillas writes:
> Pierre Asselin writes:
>> Fixes: f35cd3fa7729 [firmware/sysfb: Fix EFI/VESA format selection]
>
> The convention is f35cd3fa7729 ("firmware/sysfb: Fix EFI/VESA format
> selection")
>> +bits_per_pixel= max(bits_per_pixel, (u32)si->lfb_depth);
>
>
On 19.04.2023 21:06, Jeykumar Sankaran wrote:
>
>
> On 4/17/2023 8:30 AM, Konrad Dybcio wrote:
>> Apart from the already handled data bus (MAS_MDP_Pn<->DDR), there's
>> another path that needs to be handled to ensure MDSS functions properly,
>> namely the "reg bus", a.k.a the CPU-MDSS
On Tue, Apr 18, 2023 at 10:23:50AM -0700, Dixit, Ashutosh wrote:
> On Mon, 17 Apr 2023 22:35:58 -0700, Rodrigo Vivi wrote:
> >
>
> Hi Rodrigo,
>
> > On Mon, Apr 10, 2023 at 03:35:09PM -0700, Ashutosh Dixit wrote:
> > > Instead of erroring out when GuC reset is in progress, block waiting for
> >
1 - 100 of 224 matches
Mail list logo
