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)
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
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
== 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
---
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
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
> 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
== 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
== 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/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
== 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
== 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
---
== 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 : 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
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
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
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
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 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
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
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
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 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.
>
>
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
== 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
== 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
== 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
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
>
== 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
== 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:
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.
>
>
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
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
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
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
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ä
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
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
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(-)
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ä
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
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ä
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
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ä
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:
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.
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
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
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
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
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
== 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
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:
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
>
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().
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
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
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ä
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ä
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ä
---
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
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
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
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.
> >
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
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
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
== 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
== 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
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 ->
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.
>>
>>
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;
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
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
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
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
Pointer to the GuC log may be pointing to system memory or device memory
based on if the GuC log is backed by system memory or GPU local memory.
If the GuC log is on the local memory, we need to use memcpy_[from/to]io
APIs to access the logs to support i915 on non-x86 architectures.
iosys_map
There is no need for the destination address to be aligned to 16 byte
boundary to be able to use the non-temporal instructions while copying.
Non-temporal instructions are used only for loading from the source
address which has alignment constraints.
We only need to take care of using the right
Fast copy using non-temporal instructions for x86 currently exists at two
locations. One is implemented in i915 driver at i915/i915_memcpy.c and
another copy at drm_cache.c. The plan is to remove the duplicate
implementation in i915 driver and use the functions from drm_cache.c.
A variant of
drm_memcpy_from_wc() performs fast copy from WC memory type using
non-temporal instructions. Now there are two similar implementations of
this function. One exists in drm_cache.c as drm_memcpy_from_wc() and
another implementation in i915/i915_memcpy.c as i915_memcpy_from_wc().
drm_memcpy_from_wc()
Use forcewake to access RC6 CTRL regs
Signed-off-by: Badal Nilawar
---
drivers/gpu/drm/i915/gt/intel_rc6.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
index b4770690e794..acc26b7d2562 100644
== Series Details ==
Series: gvt-next (rev2)
URL : https://patchwork.freedesktop.org/series/102952/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/102952/revisions/2/mbox/ not
applied
Applying: gvt-next
error: sha1 information is lacking or
Hi
I'm having issues with this patch on my PRIME system and vulkan workloads
https://gitlab.freedesktop.org/drm/amd/-/issues/1992
Is there any chance you could take a look?
Cheers
Mike
I have re-opened https://gitlab.freedesktop.org/drm/intel/-/issues/5302
igt@i915_module_load@reload-with-fault-injection - dmesg-warn - WARNING: .* at
drivers/gpu/drm/i915/i915_vma.c:\d+ i915_ggtt_pin
Other sounds is not totally new, I have seen similar signature few months ago
on a different
== Series Details ==
Series: drm/i915: Support Async Flip on Linear buffers
URL : https://patchwork.freedesktop.org/series/103137/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550_full -> Patchwork_103137v1_full
Summary
On Tue, 26 Apr 2022, Imre Deak wrote:
> 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
On Mon, 25 Apr 2022 20:13:09 -0700, Patchwork wrote:
>
> Possible new issues
>
> Here are the unknown changes that may have been introduced in
> Patchwork_103110v1_full:
>
> IGT changes
>
> Possible regressions
>
> * {igt@i915_pm_disag_freq@media-freq@gt0} (NEW):
>
> * shard-iclb: NOTRUN -> SKIP
== Series Details ==
Series: drm/i915: Support Async Flip on Linear buffers
URL : https://patchwork.freedesktop.org/series/103137/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11550 -> Patchwork_103137v1
Summary
---
== Series Details ==
Series: drm/i915: Support Async Flip on Linear buffers
URL : https://patchwork.freedesktop.org/series/103137/
State : warning
== Summary ==
Error: dim checkpatch failed
4d312fea73b4 drm/i915: Support Async Flip on Linear buffers
-:22: CHECK:PARENTHESIS_ALIGNMENT:
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
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
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
>>
== 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
== 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
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
== 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:
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
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'
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) ;
1 - 100 of 111 matches
Mail list logo
