On Thu, Sep 08, 2022 at 09:34:04PM +0200, Das, Nirmoy wrote:
>
> On 9/8/2022 5:11 PM, Ville Syrjälä wrote:
> > On Thu, Sep 08, 2022 at 04:32:56PM +0200, Das, Nirmoy wrote:
> >> Hi Ville,
> >>
> >>
> >> I fixed a similar issue in DII but I couldn't reproduce it in drm
> >>
> >> http://intel-gfx-pw.
There are several trivial warnings there, due to trivial things:
- lack of function name at the kerneldoc markup;
- renamed functions;
- wrong parameter syntax.
Fix such warnings:
drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or
member 'active'
Two documented functions don't match the kernel-doc comments,
as reported by kernel-doc:
drivers/gpu/drm/i915/intel_wakeref.h:117: warning: expecting prototype
for intel_wakeref_get_if_in_use(). Prototype was for
intel_wakeref_get_if_active() instead
drivers/gpu/drm/i915/intel_wa
The documentation for the flags field is missing there. It sounds
that some last-time change converted some bools into flags, but
the kernel-doc change didn't follow it.
Fix those warnings:
drivers/gpu/drm/i915/gem/i915_gem_ttm_pm.c:135: warning: Function
parameter or member 'flags' not
There are several kernel-doc markups along the i915 driver that aren't part
of the i915.rst file, nor are included on any other file under Documentation.
Maybe due to that, there are several kernel-doc markups that report problems
when checked with scripts/kernel-doc. More than that, some of them a
Some functions seem to have been renamed without updating the kernel-doc
markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
properly documented, but has a kerneld-doc markup.
Fix those warnings:
drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting
prototype for i
There are several documented kAPI at the display side that
aren't currently part of the docs. Add them, as this allows
identifying issues with badly-formatted tags.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing
There are several documented GT kAPI that aren't currently part
of the docs. Add them, as this allows identifying issues with
badly-formatted tags.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3
Building docs currently produces this warning:
Documentation/foo/i915:159:
./drivers/gpu/drm/i915/i915_scatterlist.h:73: WARNING: Inline strong
start-string without end-string.
That's because @foo evaluates into **foo**, and placing anything
after it without spaces cause Sphinx to warn
Both intel_runtime_pm.h and intel_pm.c contains kAPI for
runtime PM. So, add them to the documentation.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https
Two new fields were added to __i915_gem_ttm_object_init() without
their corresponding documentation.
Document them.
Fixes: 9b78b5dade2d ("drm/i915: add i915_gem_object_create_region_at()")
Reviewed-by: Nirmoy Das
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number o
The return code table is not properly marked, causing warnings
and being badly parsed by Sphinx:
Documentation/gpu/i915:130:
./drivers/gpu/drm/i915/display/intel_dp_link_training.c:183: WARNING: Block
quote ends without a blank line; unexpected unindent.
Documentation/gpu/i915:130:
./dr
The return codes for i915_gem_wait_ioctl() have identation issues,
and will be displayed on a very confusing way. Use lists to improve
its output.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on
There are some occurrences of "/**" that aren't actually part of
a kernel-doc markup. Replace them by "/*", in order to make easier
to identify what i915 files contain kernel-doc markups.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number o
We can't use %foo[] as this produces a bad markup.
Use instead, the emphasis markup directly.
Fix this issue:
Documentation/gpu/i915:136:
./drivers/gpu/drm/i915/display/intel_fb.c:280: WARNING: Inline strong
start-string without end-string.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Maur
There are several documented GVT kAPI that aren't currently part
of the docs. Add them, as this allows identifying issues with
badly-formatted tags.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
This file is licensed with MIT license. Change its license text
to use SPDX.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cove
This file is licensed with MIT license. Change its license text
to use SPDX.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.kernel.org/all/cove
This is a large struct used to describe gem objects. It is
currently partially documented. Finish its documentation, filling
the gaps from git logs.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
The DOC: tag waits for a one-line short title for the doc
section. Using multiple lines will produce a weird output.
So, add a shorter description for the title, while keeping
the current content below it.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing o
There are a couple of issues at i915 display kernel-doc markups:
drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning:
Function parameter or member 'intel_connector' not described in
'intel_connector_debugfs_add'
drivers/gpu/drm/i915/display/intel_display_debugfs.c:
Prevent this Sphinx warning:
Documentation/foo/i915:728: ./drivers/gpu/drm/i915/i915_gem.c:447:
WARNING: Inline emphasis start-string without end-string.
By using @data to identify the data field, as expected by kernel-doc.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
Preserving ascii artwork on kernel-docs is tricky, as it needs
to respect both the Sphinx rules and be properly parsed by
kernel-doc script.
The Sphinx syntax require code-blocks, which is:
::
followed by a blank line and indented lines.
But kernel-doc only works fine if the first and t
commit d1b48c1e7184 ("drm/i915: Replace execbuf vma ht with an idr")
added a rbtree list to allow searching for obj/ctx.
Document it.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
Building docs currently produces two warnings:
Documentation/foo/i915:71: ./drivers/gpu/drm/i915/i915_vma_resource.c:286:
WARNING: Inline strong start-string without end-string.
Documentation/foo/i915:71: ./drivers/gpu/drm/i915/i915_vma_resource.c:370:
WARNING: Inline strong start-string
The way it is, it produces this warning:
Documentation/gpu/i915:150:
./drivers/gpu/drm/i915/display/skl_scaler.c:213: WARNING: Block quote ends
without a blank line; unexpected unindent.
Use list markups to suppress the warning.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho
Fix those kernel-doc warnings:
drivers/gpu/drm/i915/intel_region_ttm.c:199: warning: Function
parameter or member 'offset' not described in 'intel_region_ttm_resource_alloc'
drivers/gpu/drm/i915/i915_vma_resource.h:123: warning: Function
parameter or member 'wakeref' not described
There are other files with kernel-doc markups:
$ git grep -l "/\*\*" $(git ls-files|grep drivers/gpu/drm/i915/)
>kernel-doc-files
$ for i in $(cat kernel-doc-files); do if [ "$(git grep $i
Documentation/)" == "" ]; then echo "$i"; fi; done >aaa
Add them to i915.rst as well.
Sig
There are several trivial warnings there, due to trivial things:
- lack of function name at the kerneldoc markup;
- undocumented structs with kernel-doc markups;
- wrong parameter syntax.
Fix such warnings:
drivers/gpu/drm/i915/gt/intel_context.h:107: warning:
There are several trivial issueson kernel-doc markups at gem:
drivers/gpu/drm/i915/gem/i915_gem_create.c:146: warning: This comment
starts with '/**', but isn't a kernel-doc comment. Refer
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/i915/gem/i915_gem_create.c:217: warn
The kernel-doc markup for i915_gem_apply_to_region_ops() has some
issues:
1. The field should be marked as @process_obj;
2. The callback parameters aren't document properly, as sphinx
will consider them to be placed at the wrong place.
Fix (1) and change the way the parameters are described, u
There are several documented GEM/TTM kAPI that aren't currently part
of the docs. Add them, as this allows identifying issues with
badly-formatted tags.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C
Kernel-doc dump_flags parameter is missing at i915_capture_error_state().
Document it.
Fixes: a6f0f9cf330a ("drm/i915/guc: Plumb GuC-capture into gpu_coredump")
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing list
Currently, 91% of kernel-doc function declarations don't have
parenthesis on it. Let's be consistent inside the driver by
removing the parenthesis from the other ones.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the c
The intel_gt_pm.h file contains some convenient macros to be used
in GT code in order to get/put runtime PM references and for
checking them.
Add descriptions based on the ones at intel_wakeref.h and
intel_runtime_pm.c.
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large nu
There are some parameters missing at the kernel-doc markups on
some gem files. Some of those are trivial enough to be added.
Document them.
Reviewed-by: Nirmoy Das
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cov
Currently, functions inside GuC aren't presented as part of the
GuC documentation.
Add them.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v3 00/37] at:
https://lore.ke
The doc markup should not end with ":", as it would generate a
warning on Sphinx while generating the cross-reference tag.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
on the cover.
See [PATCH v
There are several documented GuC kAPI that aren't currently part
of the docs. Add them, as this allows identifying issues with
badly-formatted tags.
Reviewed-by: Rodrigo Vivi
Signed-off-by: Mauro Carvalho Chehab
---
To avoid mailbombing on a large number of people, only mailing lists were C/C
== Series Details ==
Series: i915: CAGF and RC6 changes for MTL (rev3)
URL : https://patchwork.freedesktop.org/series/108156/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12102_full -> Patchwork_108156v3_full
Summary
-
Hi, Kevin,
在 2022/9/9 18:22, Kevin Tian 写道:
The idea is to let vfio core manage the vfio_device life cycle instead
of duplicating the logic cross drivers. This is also a preparatory
step for adding struct device into vfio_device.
New pair of helpers together with a kref in vfio_device:
- vfi
On Thu, 08 Sep 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No reaon to have this humongous if ladder in intel_read_wm_latency().
*reason
> Just split it into nicer per-platforms functions.
>
> Also do the s/dev_priv/i915/ while touching all of this code.
>
> Signed-off-by: Ville Syrjäl
> From: Ethan Zhao
> Sent: Friday, September 9, 2022 4:24 PM
>
> Hi, Kevin,
>
> 在 2022/9/9 18:22, Kevin Tian 写道:
> > The idea is to let vfio core manage the vfio_device life cycle instead
> > of duplicating the logic cross drivers. This is also a preparatory
> > step for adding struct device int
Hello Dave, Daniel,
Another pull request for drm-misc-next, enjoy!
~Maarten
drm-misc-next-2022-09-09:
drm-misc-next for v6.1-rc1:
UAPI Changes:
- Hide unregistered connectors from GETCONNECTOR ioctl.
- drm/virtio no longer advertises LINEAR modifier, as it doesn't work.
-
Cross-subsystem Chan
On Thu, 08 Sep 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Replace the hand rolled stuff with REG_FIELD_GET() for reading
> out the skl+ watermark latencies.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/skl_watermark.c | 22 +++--
On 08/09/2022 21:07, Nirmoy Das wrote:
i915_gem_drain_freed_objects() might not be enough to
free all the objects and RCU delayed work might get
scheduled after the i915 device struct gets freed.
Call i915_gem_drain_workqueue() to catch all RCU delayed work.
Suggested-by: Chris Wilson
Signed
On 08/09/2022 21:07, Nirmoy Das wrote:
i915_gem_drain_workqueue() call i915_gem_drain_freed_objects()
so no need to call that again.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/i915_gem.c | 2 --
drivers/gpu/drm/i915/selftests/mock_gem_device.c | 1 -
2 files chang
> From: Suraj Kandpal
>
> Adding WD Types, WD transcoder to enum list and WD Transcoder offsets.
> Adding i915 register definitions related to WD transcoder
>
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 6 +
> .../drm/i915/display/intel_display_type
> From: Suraj Kandpal
>
> Changing intel_connector iterators as with writeback introduction not all
> drm_connector will be embedded within intel_connector.
>
> Signed-off-by: Suraj Kandpal
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 7 ++---
> .../drm/i915/display/intel_display_t
On Fri, 09 Sep 2022, "Murthy, Arun R" wrote:
>> From: Suraj Kandpal
>>
>> Adding WD Types, WD transcoder to enum list and WD Transcoder offsets.
>> Adding i915 register definitions related to WD transcoder
>>
>> Signed-off-by: Suraj Kandpal
>> ---
>> drivers/gpu/drm/i915/display/intel_display
> On Fri, 09 Sep 2022, "Murthy, Arun R" wrote:
> >> From: Suraj Kandpal
> >>
> >> Adding WD Types, WD transcoder to enum list and WD Transcoder
> offsets.
> >> Adding i915 register definitions related to WD transcoder
> >>
> >> Signed-off-by: Suraj Kandpal
> >> ---
> >> drivers/gpu/drm/i915/dis
On Fri, Sep 09, 2022 at 09:34:34AM +0200, Mauro Carvalho Chehab wrote:
> There are several documented GT kAPI that aren't currently part
> of the docs. Add them, as this allows identifying issues with
> badly-formatted tags.
>
In i915's commits we usually add a version history here
to indicate wha
On Fri, Sep 09, 2022 at 11:27:07AM +0300, Jani Nikula wrote:
> On Thu, 08 Sep 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > No reaon to have this humongous if ladder in intel_read_wm_latency().
>
> *reason
>
> > Just split it into nicer per-platforms functions.
> >
> > Also do the
On Fri, Sep 09, 2022 at 09:34:39AM +0200, Mauro Carvalho Chehab wrote:
> There are other files with kernel-doc markups:
>
> $ git grep -l "/\*\*" $(git ls-files|grep drivers/gpu/drm/i915/)
> >kernel-doc-files
> $ for i in $(cat kernel-doc-files); do if [ "$(git grep $i
> Documentatio
On Fri, Sep 09, 2022 at 09:34:42AM +0200, Mauro Carvalho Chehab wrote:
> The intel_gt_pm.h file contains some convenient macros to be used
> in GT code in order to get/put runtime PM references and for
> checking them.
>
> Add descriptions based on the ones at intel_wakeref.h and
> intel_runtime_p
On Fri, Sep 09, 2022 at 09:34:44AM +0200, Mauro Carvalho Chehab wrote:
> Currently, 91% of kernel-doc function declarations don't have
> parenthesis on it. Let's be consistent inside the driver by
> removing the parenthesis from the other ones.
>
> Signed-off-by: Mauro Carvalho Chehab
Reviewed-b
> >
> > > -Original Message-
> > > From: Greg Kroah-Hartman
> > > Sent: Friday, September 09, 2022 09:16
> > > To: Ceraolo Spurio, Daniele
> > > Cc: intel-gfx@lists.freedesktop.org;
> > > dri-de...@lists.freedesktop.org; Winkler, Tomas
> > > ; Lubart, Vitaly ;
> > > Teres Alexis, Alan Pre
On Wed, Sep 07, 2022 at 09:52:09PM +0200, Mateusz Kwiatkowski wrote:
> W dniu 7.09.2022 o 14:10, Maxime Ripard pisze:
> > Hi,
> >
> > On Fri, Sep 02, 2022 at 12:00:33AM +0200, Mateusz Kwiatkowski wrote:
> >> W dniu 29.08.2022 o 15:11, Maxime Ripard pisze:
> >>> The TV mode property has been around
On Fri, Sep 09, 2022 at 11:35:28AM +0200, Aurélien wrote:
>Hi,
>I hope this mailing-mist is the right place for this question.
+ dri-devel mailing list that looks more appropriated.
+ Hans and Lyude who were recently working to standardize some of the
backlight stuff.
>I would like to
On Wed, Sep 07, 2022 at 10:22:49PM -0700, Ashutosh Dixit wrote:
> From: Tilak Tangudu
>
> Add perf_limit_reasons in debugfs. The upper 16 perf_limit_reasons RW "log"
> bits are identical to the lower 16 RO "status" bits except that the "log"
> bits remain set until cleared, thereby ensuring the t
On Wed, Sep 07, 2022 at 10:23:38PM -0700, Ashutosh Dixit wrote:
> PERF_LIMIT_REASONS register for MTL media gt is different now.
>
> v2: Avoid static inline for intel_gt_perf_limit_reasons_reg() (Jani)
>
> Cc: Jani Nikula
> Cc: Badal Nilawar
> Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrig
On Wed, Sep 07, 2022 at 10:23:57PM -0700, Ashutosh Dixit wrote:
> For MTL, when reading from HW, RP0, RP1 (actuall RPe) and RPn freq use an
> entirely different set of registers with different fields, bitwidths and
> units.
>
> v2: Move MTL check into a separate function (Jani)
>
> Cc: Jani Nikul
On Fri, Sep 09, 2022 at 09:21:30AM +, Winkler, Tomas wrote:
> > >
> > > > -Original Message-
> > > > From: Greg Kroah-Hartman
> > > > Sent: Friday, September 09, 2022 09:16
> > > > To: Ceraolo Spurio, Daniele
> > > > Cc: intel-gfx@lists.freedesktop.org;
> > > > dri-de...@lists.freedes
Dave, do you have a preference how to deal with the mishap here, shall I do a
force-push to drm-intel-gt-next to correctly record the Acked-by or revert and
re-push? Or just leave it as is?
Quoting Greg Kroah-Hartman (2022-09-01 18:09:09)
> On Sat, Aug 06, 2022 at 03:26:21PM +0300, Tomas Winkler w
== Series Details ==
Series: drm/i915: fix kernel-doc issues (rev3)
URL : https://patchwork.freedesktop.org/series/106224/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On 8/26/22 1:47 AM, Kees Cook wrote:
On Wed, Aug 24, 2022 at 05:45:07PM +0900, Gwan-gyeong Mun wrote:
It moves overflows_type utility macro into overflow header from i915_utils
header. The overflows_type can be used to catch the truncaion (overflow)
between different data types. And it adds c
On 8/26/22 10:44 PM, Andrzej Hajda wrote:
On 25.08.2022 18:47, Kees Cook wrote:
On Wed, Aug 24, 2022 at 05:45:07PM +0900, Gwan-gyeong Mun wrote:
It moves overflows_type utility macro into overflow header from
i915_utils
header. The overflows_type can be used to catch the truncaion (overflow
== Series Details ==
Series: drm/i915: fix kernel-doc issues (rev3)
URL : https://patchwork.freedesktop.org/series/106224/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12104 -> Patchwork_106224v3
Summary
---
**FAILU
On 8/26/22 2:19 AM, Kees Cook wrote:
On Wed, Aug 24, 2022 at 05:45:08PM +0900, Gwan-gyeong Mun wrote:
It adds exact_type and exactly_pgoff_t macro to catch type mis-match while
compiling. The existing typecheck() macro outputs build warnings, but the
newly added exact_type() macro uses the BU
This patch series fixes integer overflow or integer truncation issues in
page lookups, ttm place configuration and scatterlist creation, etc.
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain integer
instead o
From: Chris Wilson
We need to check that we avoid integer overflows when looking up a page,
and so fix all the instances where we have mistakenly used a plain
integer instead of a more suitable long. Be pedantic and add integer
typechecking to the lookup so that we can be sure that we are safe.
A
It moves overflows_type utility macro into overflow header from i915_utils
header. The overflows_type can be used to catch the truncaion (overflow)
between different data types. And it adds check_assign() macro which
performs an assigning source value into destination pointer along with an
overflow
From: Kees Cook
When the check_[op]_overflow() helpers were introduced, all arguments were
required to be the same type to make the fallback macros simpler. However,
now that the fallback macros have been removed[1], it is fine to allow
mixed types, which makes using the helpers much more useful,
It adds assert_type and assert_typable macros to catch type mis-match while
compiling. The existing typecheck() macro outputs build warnings, but the
newly added assert_type() macro uses the _Static_assert() keyword (which is
introduced in C11) to generate a build break when the types are different
From: Chris Wilson
There is an impedance mismatch between the scatterlist API using unsigned
int and our memory/page accounting in unsigned long. That is we may try
to create a scatterlist for a large object that overflows returning a
small table into which we try to fit very many pages. As the o
The __shmem_file_setup() function returns -EINVAL if size is greater than
MAX_LFS_FILESIZE. To handle the same error as other code that returns
-E2BIG when the size is too large, it add a code that returns -E2BIG when
the size is larger than the size that can be handled.
v4: If BITS_PER_LONG is 32
From: Chris Wilson
Having addressed the issues surrounding incorrect types for local
variables and potential integer truncation in using the scatterlist API,
we have closed all the loop holes we had previously identified with
dangerously large object creation. As such, we can eliminate the warnin
There is an impedance mismatch between the first/last valid page
frame number of ttm place in unsigned and our memory/page accounting in
unsigned long.
As the object size is under the control of userspace, we have to be prudent
and catch the conversion errors.
To catch the implicit truncation as we
The ttm_bo_init_reserved() functions returns -ENOSPC if the size is too big
to add vma. The direct function that returns -ENOSPC is
drm_mm_insert_node_in_range().
To handle the same error as other code returning -E2BIG when the size is
too large, it converts return value to -E2BIG.
Signed-off-by:
Hi Dave & Daniel,
Here goes second drm-intel-gt-next PR towards 6.1.
As the top item we're now aligning the GuC/HuC firmware versioning
to meet the expectations recorded under firmware-usage-guidelines.rst.
A revert of a previous (incorrect) userspace register removal for DG2
and addition of new
== Series Details ==
Series: Fixes integer overflow or integer truncation issues in page lookups,
ttm place configuration and scatterlist creation
URL : https://patchwork.freedesktop.org/series/108358/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
CALL
As per PCIe Spec Section 5.3.1.4.1
When pcie function is in d3hot state,
Configuration and Message requests are the only TLPs accepted by a
Function in the D3hot state. All other received Requests must be
handled as Unsupported Requests, and all received Completions
may optionally be handled as
Release all mmap mapping for all lmem objects which are associated
with userfault such that, while pcie function in D3hot, any access
to memory mappings will raise a userfault.
Runtime resume the dgpu(when gem object lies in lmem).
This will transition the dgpu graphics function to D0
state if it
Refactor userfault_wakeref to re-use for discrete lmem mmap mapping
as well, as on discrete GTT mmap are not supported. Moving
userfault_wakeref from ggtt to gt structure.
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_pm.
The debugfs should be where the implementation details are.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_debugfs.c | 160 +
drivers/gpu/drm/i915/display/intel_hotplug.c | 166 ++
drivers/gpu/drm/i915/display/intel_hotplug.h | 1 +
3 files
Rename intel_hpd_init_work() to the more generic intel_hpd_init_early(),
and move the hotplug storm initialization there. This lets us move the
HPD_STORM_DEFAULT_THRESHOLD macro to intel_hotplug.c too.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hotplug.c | 22 +
Hi,
On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote:
> W dniu 7.09.2022 o 16:34, Maxime Ripard pisze:
> > On Mon, Sep 05, 2022 at 06:44:42PM +0200, Mateusz Kwiatkowski wrote:
> >> Hi Maxime,
> >>
> >> W dniu 5.09.2022 o 15:37, Maxime Ripard pisze:
> > + vfp = vfp_min + (
On Wed, Sep 07, 2022 at 11:31:21PM +0200, Mateusz Kwiatkowski wrote:
> The "canonical" modelines (at least for vc4's VEC, see the notes below):
>
> - (vfp==4, vsync==6, vbp==39) for 576i
> - (vfp==7, vsync==6, vbp==32) for 480i
> - (vfp==5, vsync==6, vbp==28) for 486i (full frame NTSC as originall
Current implementation of async flip w/a relies on assumption that
previous atomic commit contains valid information if async_flip is still
enabled on the plane. It is incorrect. If previous commit did not modify
the plane its state->uapi.async_flip can be false. As a result DMAR/PIPE
errors can be
On 9/9/2022 3:24 AM, Joonas Lahtinen wrote:
Dave, do you have a preference how to deal with the mishap here, shall I do a
force-push to drm-intel-gt-next to correctly record the Acked-by or revert and
re-push? Or just leave it as is?
Quoting Greg Kroah-Hartman (2022-09-01 18:09:09)
On Sat, A
On Fri, 09 Sep 2022, Rodrigo Vivi wrote:
> On Fri, Sep 09, 2022 at 11:35:28AM +0200, Aurélien wrote:
>>Hi,
>>I hope this mailing-mist is the right place for this question.
>
> + dri-devel mailing list that looks more appropriated.
> + Hans and Lyude who were recently working to standardize
On 09/09/2022 12:24, Anshuman Gupta wrote:
Release all mmap mapping for all lmem objects which are associated
with userfault such that, while pcie function in D3hot, any access
to memory mappings will raise a userfault.
Runtime resume the dgpu(when gem object lies in lmem).
This will transition
On Fri, 09 Sep 2022 03:13:05 -0700, Rodrigo Vivi wrote:
>
> On Wed, Sep 07, 2022 at 10:22:49PM -0700, Ashutosh Dixit wrote:
> > From: Tilak Tangudu
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 24009786f88b..9492f8f43b25 100644
> > --- a/drivers/
Hi,
> + dri-devel mailing list that looks more appropriated.
> + Hans and Lyude who were recently working to standardize some of the
> backlight stuff.
Thank you for these contacts. I'll try there if I need.
> I don't believe you want to use the i915 API, but move the common functions
> to the
Hi Anshuman,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Anshuman-Gupta/DGFX-mmap-with-rpm/20220909-192609
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386
Hi Anshuman,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
url:
https://github.com/intel-lab-lkp/linux/commits/Anshuman-Gupta/DGFX-mmap-with-rpm/20220909-192609
base: git://anongit.freedesktop.org/drm/drm-tip drm-tip
config: i386
On Fri, 2022-09-09 at 08:17 -0700, Ceraolo Spurio, Daniele wrote:
>
>
> On 9/9/2022 3:24 AM, Joonas Lahtinen wrote:
> > Dave, do you have a preference how to deal with the mishap here,
> > shall I do a
> > force-push to drm-intel-gt-next to correctly record the Acked-by or
> > revert and
> > re-p
On Fri, 2022-09-09 at 08:38 -0700, Dixit, Ashutosh wrote:
On Fri, 09 Sep 2022 03:13:05 -0700, Rodrigo Vivi wrote:
On Wed, Sep 07, 2022 at 10:22:49PM -0700, Ashutosh Dixit wrote:
From: Tilak Tangudu mailto:tilak.tang...@intel.com>>
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915
== Series Details ==
Series: DGFX mmap with rpm (rev3)
URL : https://patchwork.freedesktop.org/series/107400/
State : warning
== Summary ==
Error: dim checkpatch failed
fecdb3883843 drm/i915: Refactor userfault_wakeref to re-use
0152e06bf81b drm/i915/dgfx: Release mmap on rpm suspend
-:38: WAR
== Series Details ==
Series: DGFX mmap with rpm (rev3)
URL : https://patchwork.freedesktop.org/series/107400/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12109 -> Patchwork_107400v3
Summary
---
**SUCCESS**
No re
1 - 100 of 149 matches
Mail list logo
