== Series Details ==
Series: drm/i915: dbuf cleanups
URL : https://patchwork.freedesktop.org/series/89171/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9978_full -> Patchwork_19944_full
Summary
---
**SUCCESS**
Daniel Vetter writes:
> On Fri, Apr 16, 2021 at 12:25 AM Ian Romanick wrote:
>> Since we just had a big discussion about this on mesa-dev w.r.t. Mesa
>> code and documentation... does the kernel have a policy about which
>> flavor (pun intended) of English should be used?
>
> I'm not finding it
Reviewed-by: Jason Ekstrand
On April 16, 2021 05:37:55 Matthew Auld wrote:
Add a note about the two-step process.
v2(Tvrtko):
- Also document the other method of just passing in a buffer which is
large enough, which avoids two ioctl calls. Can make sense for
smaller query items.
On April 16, 2021 05:37:52 Matthew Auld wrote:
Add some example usage for the extension chaining also, which is quite
nifty.
v2: (Daniel)
- clarify that the name is just some integer, also document that the
name space is not global
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
== Series Details ==
Series: drm/i915: dbuf cleanups
URL : https://patchwork.freedesktop.org/series/89171/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9978 -> Patchwork_19944
Summary
---
**SUCCESS**
No
On 4/16/2021 10:02 AM, Daniel Vetter wrote:
On Fri, Apr 16, 2021 at 6:38 PM Jason Ekstrand wrote:
On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote:
Add an entry for the new uAPI needed for DG1.
v2(Daniel):
- include the overall upstreaming plan
- add a note for mmap, there are
== Series Details ==
Series: drm/i915: dbuf cleanups
URL : https://patchwork.freedesktop.org/series/89171/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function parameter
or member 'ww' not described
== Series Details ==
Series: drm/i915: dbuf cleanups
URL : https://patchwork.freedesktop.org/series/89171/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
== Series Details ==
Series: drm/i915: dbuf cleanups
URL : https://patchwork.freedesktop.org/series/89171/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c4e158b6022a drm/i915: Collect dbuf device info into a sub-struct
3bcf75a562a4 drm/i915: Handle dbuf bypass path allocation
From: Ville Syrjälä
Use intel_dbuf_slice_size() instead of hand rolling it.
Also clean up some of the types.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
From: Ville Syrjälä
'enable ? "enable" : "disable"' is a fairly common pattern in
out debug prints. Let's introduce a helper for it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 4 ++--
drivers/gpu/drm/i915/display/intel_display_power.c| 2 +-
From: Ville Syrjälä
Use intel_de_rmw() instead of hand rolling it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display_power.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
From: Ville Syrjälä
We always reserve the same 4 dbuf blocks for the bypass path
allocation, so might as well do that when declaring the dbuf
size.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_pci.c | 8
drivers/gpu/drm/i915/intel_pm.c | 9 +
2 files changed, 5
From: Ville Syrjälä
A bunch of drive-by-cleanup While I was reading through
the dbuf code.
Ville Syrjälä (8):
drm/i915: Collect dbuf device info into a sub-struct
drm/i915: Handle dbuf bypass path allocation earlier
drm/i915: Store dbuf slice mask in device info
drm/i915: Use
From: Ville Syrjälä
Collect the related dbuf information into a struct.
Signed-off-by: Ville Syrjälä
---
.../gpu/drm/i915/display/intel_display_power.c | 4 ++--
drivers/gpu/drm/i915/i915_pci.c | 16
drivers/gpu/drm/i915/intel_device_info.h | 6
From: Ville Syrjälä
Use simpler sentences. Just say "enable foo" instead
of "set foo to enabled" etc.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dp.c | 12 ++--
drivers/gpu/drm/i915/display/intel_tc.c | 4 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
From: Ville Syrjälä
Now that we have the dbuf slice mask stored in the device info
let's use it for for_each_dbuf_slice_in_mask*().
With this we cal also rip out intel_dbuf_size() and
intel_dbuf_num_slices().
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bw.c | 11
From: Ville Syrjälä
Let's just store the dbuf slice information as a bitmask
in the device info. Makes life a little easier later.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display_power.c | 4 ++--
drivers/gpu/drm/i915/i915_pci.c| 6 +++---
On Fri, Apr 16, 2021 at 6:38 PM Jason Ekstrand wrote:
>
> On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote:
> >
> > Add an entry for the new uAPI needed for DG1.
> >
> > v2(Daniel):
> > - include the overall upstreaming plan
> > - add a note for mmap, there are differences here for TTM vs
On Thu, Apr 15, 2021 at 11:04 AM Matthew Auld wrote:
>
> Add an entry for the new uAPI needed for DG1.
>
> v2(Daniel):
> - include the overall upstreaming plan
> - add a note for mmap, there are differences here for TTM vs i915
> - bunch of other suggestions from Daniel
> v3:
> (Daniel)
>
On 14/04/2021 16:01, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Add "REGION_STOLEN" device info to dg1, create stolen memory
region from upper portion of local device memory, starting
from DSMBASE.
v2:
- s/drm_info/drm_dbg; userspace likely doesn't
On Fri, Apr 16, 2021 at 10:23 PM Jani Nikula
wrote:
>
> On Thu, 15 Apr 2021, Hsin-Yi Wang wrote:
> > pm_resume and pm_suspend might be conflict with the ones defined in
> > include/linux/suspend.h. Rename pm_resume{suspend} to
> > i915_pm_resume{suspend} since they are only used here.
>
> I
On 14/04/2021 16:33, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: Anusha Srivatsa
In the scenario where local memory is available, we have
rely on CPU access via lmem directly instead of aperture.
v2:
gmch is only relevant for much older hw, therefore we can drop the
On Thu, 15 Apr 2021, Hsin-Yi Wang wrote:
> pm_resume and pm_suspend might be conflict with the ones defined in
> include/linux/suspend.h. Rename pm_resume{suspend} to
> i915_pm_resume{suspend} since they are only used here.
I agree with the rationale here.
Do you need this to be part of your
On Fri, Apr 16, 2021 at 12:37 PM Matthew Auld wrote:
>
> Add section for drm/i915 uAPI and pull in i915_drm.h.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Dave
On 14/04/2021 16:09, Tvrtko Ursulin wrote:
On 12/04/2021 10:05, Matthew Auld wrote:
From: CQ Tang
Stolen memory is always allocated as physically contiguous pages, mark
the object flags as such.
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
== Series Details ==
Series: series starting with [1/4] drm/i915/uapi: fix kernel doc warnings
URL : https://patchwork.freedesktop.org/series/89155/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9976_full -> Patchwork_19943_full
== Series Details ==
Series: series starting with [1/4] drm/i915/uapi: fix kernel doc warnings
URL : https://patchwork.freedesktop.org/series/89155/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_9976 -> Patchwork_19943
== Series Details ==
Series: series starting with [1/4] drm/i915/uapi: fix kernel doc warnings
URL : https://patchwork.freedesktop.org/series/89155/
State : warning
== Summary ==
$ make htmldocs 2>&1 > /dev/null | grep i915
./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function
== Series Details ==
Series: series starting with [1/4] drm/i915/uapi: fix kernel doc warnings
URL : https://patchwork.freedesktop.org/series/89155/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e98fe0216171 drm/i915/uapi: fix kernel doc warnings
92879b3dd962 drm/doc: add
Add a note about the two-step process.
v2(Tvrtko):
- Also document the other method of just passing in a buffer which is
large enough, which avoids two ioctl calls. Can make sense for
smaller query items.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Add some example usage for the extension chaining also, which is quite
nifty.
v2: (Daniel)
- clarify that the name is just some integer, also document that the
name space is not global
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc:
Add section for drm/i915 uAPI and pull in i915_drm.h.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc:
Fix the cases where it is almost already valid kernel doc, for the
others just nerf the warnings for now.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Cc:
On Thu, Apr 15, 2021 at 04:59:58PM +0100, Matthew Auld wrote:
> Add an entry for the new uAPI needed for DG1.
>
> v2(Daniel):
> - include the overall upstreaming plan
> - add a note for mmap, there are differences here for TTM vs i915
> - bunch of other suggestions from Daniel
> v3:
>
On Fri, Apr 16, 2021 at 12:25 AM Ian Romanick wrote:
> On 4/15/21 8:59 AM, Matthew Auld wrote:
> > Add a note about the two-step process.
> >
> > Suggested-by: Daniel Vetter
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: Jordan Justen
> > Cc: Daniel Vetter
> > Cc: Kenneth
On Fri, Apr 16, 2021 at 10:44:28AM +0200, Daniel Vetter wrote:
> On Thu, Apr 15, 2021 at 04:59:55PM +0100, Matthew Auld wrote:
> > It's not properly formatted kernel doc, just nerf the warnings for now.
> >
> > Signed-off-by: Matthew Auld
> > Cc: Joonas Lahtinen
> > Cc: Jordan Justen
> > Cc:
On Thu, Apr 15, 2021 at 04:59:57PM +0100, Matthew Auld wrote:
> Add a note about the two-step process.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Dave Airlie
>
On Thu, Apr 15, 2021 at 04:59:56PM +0100, Matthew Auld wrote:
> Add some example usage for the extension chaining also, which is quite
> nifty.
>
> Suggested-by: Daniel Vetter
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
>
On Thu, Apr 15, 2021 at 04:59:55PM +0100, Matthew Auld wrote:
> It's not properly formatted kernel doc, just nerf the warnings for now.
>
> Signed-off-by: Matthew Auld
> Cc: Joonas Lahtinen
> Cc: Jordan Justen
> Cc: Daniel Vetter
> Cc: Kenneth Graunke
> Cc: Jason Ekstrand
> Cc: Dave Airlie
On 15/04/2021 16:59, Matthew Auld wrote:
Add a note about the two-step process.
Suggested-by: Daniel Vetter
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Jordan Justen
Cc: Daniel Vetter
Cc: Kenneth Graunke
Cc: Jason Ekstrand
Cc: Dave Airlie
Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Simon Ser
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
42 matches
Mail list logo
