io mapped memory should not be directly dereferenced to ensure
portability. io memory should be read/written/copied using helper
functions.
i915_memcpy_from_wc() function was used to copy the data from io memory to
a temporary buffer and pointer to the temporary buffer was passed to CRC
calculation
memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
by the implementation in drm_cache.c.
Updated to use the functions provided by drm_cache.c.
v2: check if the source and destination memory address is from local
memory or system memory and initialize the iosys_map according
memcpy_from_wc functions in i915_memcpy.c will be removed and replaced
by the implementation in drm_cache.c.
Updated to use the functions provided by drm_cache.c.
v2: Pass newly added src offset argument to the modified
drm_memcpy_from_wc_vaddr() function.
Signed-off-by: Balasubramani Vivekananda
Pointer passed to zlib_deflate() for compression could point to io
mapped memory and might end up in direct derefencing.
io mapped memory is copied to a temporary buffer, which is then shared
to zlib_deflate(), only for the case where platform supports fast copy
using non-temporal instructions. If
Hello Jose,
Thanks much for the patch. I tested it on chrome system and the patch works.
Adding my Tested-by.
Tested-by: Vidya Srinivas
Regards
Vidya
> -Original Message-
> From: Souza, Jose
> Sent: Friday, April 22, 2022 12:52 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.
On 4/26/22 3:53 PM, Jason Gunthorpe wrote:
> On Tue, Apr 26, 2022 at 07:58:59AM +, Wang, Zhi A wrote:
>> Hi folks:
>>
>> Here is the pull of gvt-next which fixs the compilation error when i915 debug
>> is open after the GVT-g refactor patches.
>>
>> Thanks so much for the efforts.
>>
>> Thanks,
On Tue, Apr 26, 2022 at 12:17:24AM +, Patchwork wrote:
> == Series Details ==
>
> Series: i915: Upstream initial DG2 PCI IDs
> URL : https://patchwork.freedesktop.org/series/103098/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103098v1_fu
== Series Details ==
Series: drm/i915/rc6: Access RC6 CTRL regs with forcewake
URL : https://patchwork.freedesktop.org/series/103156/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103156v1
Summary
---
== Series Details ==
Series: drm/i915: Use the memcpy_from_wc function from drm (rev4)
URL : https://patchwork.freedesktop.org/series/100581/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_100581v4
Summary
On Thu, Apr 21, 2022 at 12:22:03PM -0700, José Roberto de Souza wrote:
> Intel hardware supports change between modes with different refresh
> rates without any glitches or visual artifacts, that feature is called
> seamless DRRS.
>
> So far i915 driver was automatically changing between preferred
On Mon, 2022-04-25 at 14:55 +0300, Jani Nikula wrote:
> On Thu, 21 Apr 2022, José Roberto de Souza wrote:
> > Will be adding some additional control options to DRRS that will
> > require to have the DRRS downclock mode stored in the crtc_state.
> >
> > So to optimize memory usage a bit here using
On Tue, Apr 26, 2022 at 05:34:07PM +0530, Arun R Murthy wrote:
> Starting from Gen12 Async Flip is supported on linear buffers.
It's supported earlier than that. But IIRC there was some kind of
GTT alignment vs. async flip vs. FBC restriction that we weren't
handling.
> This patch enables support
On Tue, 2022-04-26 at 21:08 +0300, Ville Syrjälä wrote:
> On Thu, Apr 21, 2022 at 12:22:03PM -0700, José Roberto de Souza wrote:
> > Intel hardware supports change between modes with different refresh
> > rates without any glitches or visual artifacts, that feature is called
> > seamless DRRS.
> >
Hello!
The 2022 X.Org Developers Conference is being held in conjunction with
the 2022 Wine Developers Conference. This is a meeting to bring
together developers working on all things open graphics (Linux kernel,
Mesa, DRM, Wayland, X11, etc.) as well as developers for the Wine
Project, a key con
Hello everyone!
The X.org board is soliciting proposals to host XDC in 2023. Since
XDC 2022 is being held in North America this year, XDC 2023 is expected
to be in Europe. However, the board is open to other locations,
especially if there's an interesting co-location with another
conference.
If y
From: Ville Syrjälä
Start reordering when we do the clock/dpll calculations
during the atomic check. The eventual goals are:
- back feed the actually calculated clock into the crtc state
so that stuff that depends on it (eg. watermarks) will be
calculated based on the actual hardware state we
From: Ville Syrjälä
Split the DPLL state computation into a separate function
from the current .get_dplls() which currently serves a dual duty
by also reserving the shared DPLLs.
v2: s/false/-EINVAL/ (Jani)
Cc: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_d
From: Ville Syrjälä
Currently we calculate a lot of things (pixel rate, watermarks,
cdclk) trusting that the DPLL can generate the exact frequency
we ask it. In practice that is not true and there can be
certain amount of rounding involved.
To allow us to eventually get accurate numbers for all
From: Ville Syrjälä
Only reassign the pipe's DPLL if it's going through a full
.compute_config() cycle. If OTOH it's just getting modeset
eg. in order to change cdclk there doesn't seem much point in
picking a new DPLL for it.
This should also prevent .get_dplls() from seeing a funky port_clock
From: Ville Syrjälä
The debugs in lower level DPLL code don't really provide any
useful extra information AFAICS. Better just streamline the
code and just put the necessary debugs (to identify at which
step the modeset failed) into the higher level code. In
addition we'll get the full state dump
On Tue, Apr 26, 2022 at 06:32:01PM +, Souza, Jose wrote:
> On Tue, 2022-04-26 at 21:08 +0300, Ville Syrjälä wrote:
> > On Thu, Apr 21, 2022 at 12:22:03PM -0700, José Roberto de Souza wrote:
> > > Intel hardware supports change between modes with different refresh
> > > rates without any glitche
On Thu, Apr 14, 2022 at 06:06:44PM +0300, Jani Nikula wrote:
> If a NULL edid gets passed to drm_add_edid_modes(), we should probably
> also reset the display info.
One concern I had with this is resetting of eg. {width,height}_mm
which might have been populated by intel_panel_add_fixed_mode().
Bu
On Thu, Apr 14, 2022 at 06:06:45PM +0300, Jani Nikula wrote:
> From: Lee Shawn C
>
> Find HF-SCDB information in CEA extensions block. And retrieve
> Max_TMDS_Character_Rate that support by sink device.
>
> v2: HF-SCDB and HF-VSDBS carry the same SCDS data. Reuse
> drm_parse_hdmi_forum_vsdb(
On Thu, Apr 14, 2022 at 06:06:49PM +0300, Jani Nikula wrote:
> Abstract helpers for matching vendor data blocks and extended tags, and
> use them to simplify all the cea_db_is_*() functions.
>
> Take void pointer as parameter to allow transitional use for both u8 *
> and struct cea_db *.
>
> v2:
== Series Details ==
Series: drm/i915/rc6: Access RC6 CTRL regs with forcewake
URL : https://patchwork.freedesktop.org/series/103156/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103156v1_full
Summa
On 26/04/2022 17:58, Wang, Zhi A wrote:
On 4/26/22 3:53 PM, Jason Gunthorpe wrote:
On Tue, Apr 26, 2022 at 07:58:59AM +, Wang, Zhi A wrote:
Hi folks:
Here is the pull of gvt-next which fixs the compilation error when i915 debug
is open after the GVT-g refactor patches.
Thanks so much f
From: Ville Syrjälä
Several changes to our BDB block handling:
1)
The current way of trusting the version checks to avoid out of
bounds accesses to the BDB blocks is fragile. We might just get
the version check wrong, or the VBT may be corrupted/malicious.
So instead of doing blind accesses into
From: Ville Syrjälä
Reorder things so that we can parse the entier LFP data block
in one go. For now we just stick to parsing the DTD from it.
Also fix the misleading comment about block 42 being deprecated.
Only the DTD part is deprecated, the rest is still very much needed.
v2: Move the versi
From: Ville Syrjälä
Modern VBTs no longer contain the LFP data table pointers
block (41). We are expecting to have one in order to be able
to parse the LFP data block (42), so let's make one up.
Since the fp_timing table has variable size we must somehow
determine its size. Rather than just hard
From: Ville Syrjälä
We need to start parsing stuff from the tail end of the LFP data block.
This is made awkward by the fact that the fp_timing table has variable
size. So we must use a bit more finesse to get the tail end, and to
make sure we allocate enough memory for it to make sure our struct
From: Ville Syrjälä
Document the fact that struct lvds_lfp_data_entry can't be used
directly and instead must be accessed via the data table pointers.
Also remove the bogus comment implying that there might be a
variable number of panel entries in the table. There are always
exactly 16.
Signed-
From: Ville Syrjälä
Just assume panel_type==0 always if the VBT gives us bogus data.
We actually already do this everywhere else except in
parse_panel_options() since we just leave i915->vbt.panel_type
zeroed. This also seems to be what Windows does.
Reviewed-by: Jani Nikula
Signed-off-by: Vill
From: Ville Syrjälä
We use the "driver features" block for two different kinds
of data: global data, and per panel data. Split the function
into two parts along that line so that we can start doing the
parsing in two different locations.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
--
From: Ville Syrjälä
Parsing the panel specific data (anything that depends on panel_type)
from VBT is currently happening too early. Split the whole thing
into global vs. panel specific parts so that we can start doing
the panel specific parsing at a later time.
v2: Clarify that this is about pa
From: Ville Syrjälä
Make sure we don't cause memory leaks/etc. by parsing panel_type
specific parts multiple times. The real solution would be to stop
stuffing panel specific stuff into i915->vbt, but in the meantime
let's just make sure we don't leak too badly.
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Split the PPS init to something we do at the start of the eDP
probe and a second part we do at the end.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 2 ++
drivers/gpu/drm/i915/display/intel_pps.c | 30
drivers/gpu/drm
From: Ville Syrjälä
During the eDP probe we may not yet know the panel_type used
to index the VBT panel tables. So the initial eDP probe will have
to be done without that, and thus we won't yet have the PPS delays
from the VBT. Once the VBT has been fully parse we should reinit
the PPS delays to
From: Ville Syrjälä
Pull the code to determine the panel type into its own set of
sane functions.
v2: rebase
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 58 +++
1 file changed, 39 insertions(+), 19 deletions(-)
di
From: Ville Syrjälä
Move the panel specific VBT parsing to happen during the
output probing stage. Needs to be done because the VBT
parsing will need to look at the EDID to determine
the correct panel_type on some machines.
v2: Do intel_bios_init_panel() a bit earlier for vlv_dsi
Signed-off-by:
From: Ville Syrjälä
Apparently when the VBT panel_type==0xff we should trawl through
the PNPID table and check for a match against the EDID. If a
match is found the index gives us the panel_type.
Tried to match the Windows behaviour here with first looking
for an exact match, and if one isn't fo
From: Ville Syrjälä
Make the panel type code a bit more abstract along the
lines of the source of the panel type. For the moment
we have three classes: OpRegion, VBT, fallback.
Well introduce another one shortly.
We can now also print out all the different panel types,
and indicate which one we
From: Ville Syrjälä
Make sure our choice of downclock mode respects the VBT
seameless DRRS min refresh rate limit.
v2: s/vrefesh/vrefresh/ (Jani)
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_panel.c | 10 +++---
1 file changed, 7 insertions
From: Ville Syrjälä
Make the PNPID decoding available for other users.
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
include/drm/drm_edid.h | 21 +
1 file changed, 17 insertions(+), 4 deletions(-)
diff --git a/include/drm/dr
From: Ville Syrjälä
Dump the panel PNPID and name from the VBT.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 24 +++
1 file changed, 24 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers
From: Ville Syrjälä
Extract the seamless DRRS min refresh rate from the VBT.
v2: Do a version check
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 9 -
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 9 insertion
On Tue, 26 Apr 2022 00:55:26 -0700, Jani Nikula wrote:
>
> On Tue, 19 Apr 2022, Ashutosh Dixit wrote:
> > Each gt contains an independent instance of pcode. Extend pcode functions
> > to interface with pcode on different gt's. Previous (GT0) pcode read/write
> > interfaces are preserved.
>
> Reply
== Series Details ==
Series: drm/i915: Start reordering modeset clock calculations (rev6)
URL : https://patchwork.freedesktop.org/series/101789/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/101789/revisions/6/mbox/ not
applied
Applying: drm/i915
== Series Details ==
Series: drm/i915: Use the memcpy_from_wc function from drm (rev4)
URL : https://patchwork.freedesktop.org/series/100581/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_100581v4_full
===
On Sun, 24 Apr 2022 15:30:59 -0700, Andi Shyti wrote:
>
> Hi Ashutosh,
>
Hi Andi,
> [...]
>
> > -static struct kobj_type kobj_gt_type = {
> > - .release = kobj_gt_release,
> > +static struct kobj_type kobj_gtn_type = {
>
> what does it mean GTN? Or is it GTn? Please use just GT, gtn is
> confus
== Series Details ==
Series: drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching
(rev7)
URL : https://patchwork.freedesktop.org/series/102213/
State : warning
== Summary ==
Error: dim checkpatch failed
491bd4fb1142 drm/i915/bios: Reorder panel DTD parsing
3e5577a49b4e drm/
== Series Details ==
Series: drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching
(rev7)
URL : https://patchwork.freedesktop.org/series/102213/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separat
== Series Details ==
Series: drm/i915/bios: Rework BDB block handling and PNPID->panel_type matching
(rev7)
URL : https://patchwork.freedesktop.org/series/102213/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_102213v7
===
The following changes since commit ac21ab5d1de0de34201c90d32eee436f873d1e5b:
Mellanox: Add lc_ini_bundle for xx.2010.1006 (2022-04-25 07:36:16 -0400)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-firmware guc_v70.1.2_dg2
for you to fetch changes up to 89ae5eb
On Mon, Apr 25, 2022 at 12:16:11PM +0530, Bhanuprakash Modem wrote:
> Modern display hardware is capable of supporting variable refresh rates.
> This patch introduces helpers to attach and set "vrr_enabled" property
> on the crtc to allow userspace to query VRR enabled status on that crtc.
>
> Ato
Hi Arun,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on drm-tip/drm-tip v5.18-rc4 next-20220426]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use
On newer platforms (starting DG2 G10 B-step and G11 A-step), ownership of
HuC loading and authentication has been moved from the GuC to the GSC, with
both actions being performed via a single PXP command.
Given that the mei code has not fully landed yet (see [1]), we can't
implement the new load me
The huc_is_authenticated function return is based on our SW tracking of
the HuC auth status. However, around suspend/resume and reset this can
go out of sync with the actual HW state, which is why we use
huc_check_state() to look at the actual HW state. Instead of having this
duality, just make huc
HuC loading via GSC is performed via a PXP command sent through the mei
modules, so we need both MEI_GSC and MEI_PXP to be available. Given that
the GSC will do both the transfer and the authentication, the legacy HuC
loading paths can be safely skipped.
Also note that the GSC-loaded HuC survives G
The previous patch introduced new failure cases in the HuC init flow
that can be hit by simply changing the config, so we want to avoid
failing the probe in those scenarios. HuC load failure is already
considered a non-fatal error and we have a way to report to userspace
if the HuC is not available
On newer platforms (starting DG2 G10 B-step and G11 A-step), ownership of
HuC loading has been moved from the GuC to the GSC. As part of the
change, the header format of the HuC binary has been updated and does not
match the GuC anymore. The GSC will perform all the required checks on
the binary si
Use intel_uncore_read64_2x32 to read upper and lower fields of the GPM
timestamp.
v2: Fix compile error
Signed-off-by: Umesh Nerlige Ramappa
---
.../gpu/drm/i915/gt/uc/intel_guc_submission.c | 17 ++---
1 file changed, 2 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm
Bspec has added some steps that check forDMC MMIO range before
programming them
v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)
BSpec: 49193
Cc:
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
== Series Details ==
Series: drm/i915: Prepare for GSC-loaded HuC
URL : https://patchwork.freedesktop.org/series/103186/
State : warning
== Summary ==
Error: dim checkpatch failed
8916eb4e3081 drm/i915/huc: check HW directly for HuC auth status
0cbbd92e569f drm/i915/huc: Add fetch support for
== Series Details ==
Series: drm/i915: Prepare for GSC-loaded HuC
URL : https://patchwork.freedesktop.org/series/103186/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: Prepare for GSC-loaded HuC
URL : https://patchwork.freedesktop.org/series/103186/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103186v1
Summary
---
**FAILURE
== Series Details ==
Series: drm/i915/pmu: Use existing uncore helper to read gpm_timestamp
URL : https://patchwork.freedesktop.org/series/103189/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103189v1
Su
== Series Details ==
Series: drm/i915/dmc: Add MMIO range restrictions (rev3)
URL : https://patchwork.freedesktop.org/series/102168/
State : warning
== Summary ==
Error: dim checkpatch failed
f6bceb457fc4 drm/i915/dmc: Add MMIO range restrictions
-:58: WARNING:LONG_LINE: line length of 111 exc
== Series Details ==
Series: drm/i915/dmc: Add MMIO range restrictions (rev3)
URL : https://patchwork.freedesktop.org/series/102168/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_102168v3
Summary
---
== Series Details ==
Series: drm/i915/pmu: Use existing uncore helper to read gpm_timestamp
URL : https://patchwork.freedesktop.org/series/103189/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103189v1_full
==
> On Tue, Apr 26, 2022 at 05:34:07PM +0530, Arun R Murthy wrote:
> > Starting from Gen12 Async Flip is supported on linear buffers.
>
> It's supported earlier than that. But IIRC there was some kind of GTT
> alignment vs. async flip vs. FBC restriction that we weren't handling.
>
Should I enable
Hi Arun,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip v5.18-rc4 next-20220426]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest
Hi Anusha,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on drm-tip/drm-tip next-20220426]
[cannot apply to v5.18-rc4]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
== Series Details ==
Series: i915: Upstream initial DG2 PCI IDs
URL : https://patchwork.freedesktop.org/series/103098/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103098v1_full
Summary
---
*
== Series Details ==
Series: i915: Upstream initial DG2 PCI IDs
URL : https://patchwork.freedesktop.org/series/103098/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103098v1_full
Summary
---
*
Yes, I have filed a new issue and re-reported.
https://gitlab.freedesktop.org/drm/intel/-/issues/5846
igt@kms_vblank@pipe-d-wait-idle-hang - incomplete - general protection fault,
probably for non-canonical address 0x380015ffd0003c, RIP:
0010:acpi_ns_search_one_scope
Thanks,
Lakshmi
-Origina
Both are known failures, so I have re-reported.
Thanks,
Lakshmi.
From: Zhang, Dingchen (David)
Sent: Tuesday, April 26, 2022 10:48 AM
To: Vudum, Lakshminarayana ;
intel-gfx@lists.freedesktop.org; Latvala, Petri
Cc: Siqueira, Rodrigo ; Pillai, Aurabindo
Subject: Re: False-positive of CI issue
On Tue, Apr 26, 2022 at 05:35:09PM -0700, Anusha Srivatsa wrote:
Bspec has added some steps that check forDMC MMIO range before
programming them
v2: Fix for CI
v3: move register defines to .h (Anusha)
- Check MMIO restrictions per pipe
- Add MMIO restricton for v1 dmc header as well (Lucas)
BSp
drm-misc-fixes-2022-04-27:
drm-misc-fixes for v5.18-rc5:
- Single fix removing applying PHYS_OFFSET twice in sunxi.
The following changes since commit 94f4c4965e5513ba624488f4b601d6b385635aec:
drm/amdgpu: partial revert "remove ctx->lock" v2 (2022-04-21 11:26:20 +0200)
are available in the Git
Hi Matt,
The proposal looks good to me.
Looking forward to try it on drm-tip.
-Lionel
On 20/04/2022 20:13, Matthew Auld wrote:
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interac
One question though, how do we detect that this flag
(I915_GEM_CREATE_EXT_FLAG_NEEDS_CPU_ACCESS) is accepted on a given kernel?
I assume older kernels are going to reject object creation if we use
this flag?
I didn't plan to use __drm_i915_query_vma_info, but isn't it
inconsistent to select th
== Series Details ==
Series: drm/i915: remove superfluous string helper include (rev2)
URL : https://patchwork.freedesktop.org/series/103086/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103086v2
Summary
On 25/04/2022 19:40, Yang, Fei wrote:
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -1175,6 +1175,7 @@ void intel_gt_invalidate_tlbs(struct intel_gt *gt)
[VIDEO_DECODE_CLASS]= GEN12_VD_TLB_INV_CR,
[VIDEO_ENHANCEM
On Tue, 26 Apr 2022, Stephen Rothwell wrote:
> Hi all,
>
> After merging the drm-intel tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: modpost: "intel_runtime_pm_put" [drivers/gpu/drm/i915/kvmgt.ko]
> undefined!
>
> Possibly caused by commit
>
> 8b750bf74418
On Wed, 20 Apr 2022, "Vivi, Rodrigo" wrote:
> On Tue, 2022-04-19 at 22:54 -0700, Dixit, Ashutosh wrote:
>> On Fri, 15 Apr 2022 03:21:26 -0700, Rodrigo Vivi wrote:
>> > On Thu, Apr 14, 2022 at 03:31:07PM -0700, Dixit, Ashutosh wrote:
>> > > On Thu, 14 Apr 2022 06:28:57 -0700, Jani Nikula wrote:
>>
On Tue, 19 Apr 2022, Ashutosh Dixit wrote:
> Each gt contains an independent instance of pcode. Extend pcode functions
> to interface with pcode on different gt's. Previous (GT0) pcode read/write
> interfaces are preserved.
Replying here as well. I'd prefer it if a dependency on gt wasn't
introdu
Hi folks:
Here is the pull of gvt-next which fixs the compilation error when i915 debug
is open after the GVT-g refactor patches.
Thanks so much for the efforts.
Thanks,
Zhi.
The following changes since commit 2917f53113be3b7a0f374e02cebe6d6b749366b5:
vfio/mdev: Remove mdev drvdata (2022-04-
On Tue, 26 Apr 2022, "Wang, Zhi A" wrote:
> Hi folks:
>
> Here is the pull of gvt-next which fixs the compilation error when i915 debug
> is open after the GVT-g refactor patches.
>
> Thanks so much for the efforts.
Pulled, thanks.
BR,
Jani.
>
> Thanks,
> Zhi.
>
> The following changes since co
Hi folks:
I updated the branch again. Please use this pull. Here is the pull of
gvt-next which fixes the compilation error when i915 debug is open after
the GVT-g refactor patches.
Thanks so much for the efforts.
Thanks,
Zhi.
The following changes since commit 2917f53113be3b7a0f374e02cebe6d6b74
On 4/26/22 8:37 AM, Jani Nikula wrote:
> On Tue, 26 Apr 2022, "Wang, Zhi A" wrote:
>> Hi folks:
>>
>> Here is the pull of gvt-next which fixs the compilation error when i915 debug
>> is open after the GVT-g refactor patches.
>>
>> Thanks so much for the efforts.
>
> Pulled, thanks.
>
> BR,
> Jan
On 4/26/22 8:37 AM, Jani Nikula wrote:
> On Tue, 26 Apr 2022, "Wang, Zhi A" wrote:
>> Hi folks:
>>
>> Here is the pull of gvt-next which fixs the compilation error when i915 debug
>> is open after the GVT-g refactor patches.
>>
>> Thanks so much for the efforts.
>
> Pulled, thanks.
>
> BR,
> Jan
No action can be taken, and the pipeline issue can be ignored.
https://patchwork.freedesktop.org/series/102992/ is looking for review / acks
for this issue btw...
Petri
From: Vudum, Lakshminarayana
Sent: Tuesday, 26 April 2022 0.25
To: Zhang, Dingchen (David) ;
intel-gfx@lists.freedesktop.or
Fix the below drm/edid kernel-doc warnings:
drivers/gpu/drm/drm_edid.c:1589: warning: Function parameter or member '_edid'
not described in 'drm_edid_header_is_valid'
drivers/gpu/drm/drm_edid.c:1589: warning: Excess function parameter 'raw_edid'
description in 'drm_edid_header_is_valid'
drivers/
Drop the kernel-doc for static functions, it's excessive, but retain the
info in plain comments.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_edid.c | 57 --
1 file changed, 17 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/dri
== Series Details ==
Series: series starting with [1/2] drm/edid: fix kernel-doc parameter name
mismatches
URL : https://patchwork.freedesktop.org/series/103131/
State : warning
== Summary ==
Error: dim checkpatch failed
a94bb9f72a7c drm/edid: fix kernel-doc parameter name mismatches
-:18: WA
On Thu, Apr 14, 2022 at 01:49:54PM +0300, Jani Nikula wrote:
> On Sat, 09 Apr 2022, Imre Deak wrote:
> > Some ADLP DP link configuration at least with multiple LTTPRs expects
> > the first DPCD access during the LTTPR/DPCD detection after hotplug to
> > be a read from the LTTPR range starting with
== Series Details ==
Series: series starting with [1/2] drm/edid: fix kernel-doc parameter name
mismatches
URL : https://patchwork.freedesktop.org/series/103131/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103131v1
== Series Details ==
Series: series starting with [1/2] drm/edid: fix kernel-doc parameter name
mismatches
URL : https://patchwork.freedesktop.org/series/103131/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103131v1_full
==
On Tue, 26 Apr 2022, Imre Deak wrote:
> On Thu, Apr 14, 2022 at 01:49:54PM +0300, Jani Nikula wrote:
>> On Sat, 09 Apr 2022, Imre Deak wrote:
>> > Some ADLP DP link configuration at least with multiple LTTPRs expects
>> > the first DPCD access during the LTTPR/DPCD detection after hotplug to
>> >
On Tue, Apr 26, 2022 at 02:31:07PM +0300, Jani Nikula wrote:
> On Tue, 26 Apr 2022, Imre Deak wrote:
> > On Thu, Apr 14, 2022 at 01:49:54PM +0300, Jani Nikula wrote:
> >> On Sat, 09 Apr 2022, Imre Deak wrote:
> >> > Some ADLP DP link configuration at least with multiple LTTPRs expects
> >> > the
Starting from Gen12 Async Flip is supported on linear buffers.
This patch enables support for async on linear buffer.
Signed-off-by: Arun R Murthy
---
drivers/gpu/drm/i915/display/intel_display.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_displa
1 - 100 of 113 matches
Mail list logo
