On Mon, Apr 26, 2021 at 04:13:55PM +0200, Christoph Hellwig wrote:
> > diff --git a/drivers/vfio/mdev/Makefile b/drivers/vfio/mdev/Makefile
> > index ff9ecd80212503..7c236ba1b90eb1 100644
> > +++ b/drivers/vfio/mdev/Makefile
> > @@ -1,5 +1,5 @@
> > # SPDX-License-Identifier: GPL-2.0-only
> >
>
On Mon, Apr 26, 2021 at 06:43:14PM +0200, Christian Borntraeger wrote:
> On 24.04.21 01:02, Jason Gunthorpe wrote:
> > Prologue
> >
> >
> > This is series #3 in part of a larger work that arose from the minor
> > remark that the mdev_parent_ops indirection shim is useless and
> >
On Mon, Apr 26, 2021 at 04:19:11PM +0200, Christoph Hellwig wrote:
> > +The mediated bus driver's probe function should create a vfio_device on
> > top of
> > +the mdev_device and connect it to an appropriate implementation of
> > vfio_device_ops.
>
> Overly long line.
>
> > +This will provide
On 26-04-2021 15:19, Jani Nikula wrote:
On Mon, 26 Apr 2021, Rajeev Nandan wrote:
Add backlight driver for the panels supporting backlight control
using DPCD registers on the DisplayPort aux channel.
No, please don't do this.
I wrote you last week in reply to v1 why I thought merging this
The last useful member in this struct is the supported_type_groups, move
it to the mdev_driver and delete mdev_parent_ops.
Replace it with mdev_driver as an argument to mdev_register_device()
Reviewed-by: Christoph Hellwig
Signed-off-by: Jason Gunthorpe
---
On 26.04.21 19:42, Jason Gunthorpe wrote:
On Mon, Apr 26, 2021 at 06:43:14PM +0200, Christian Borntraeger wrote:
On 24.04.21 01:02, Jason Gunthorpe wrote:
Prologue
This is series #3 in part of a larger work that arose from the minor
remark that the mdev_parent_ops indirection shim
On 24.04.21 01:02, Jason Gunthorpe wrote:
Prologue
This is series #3 in part of a larger work that arose from the minor
remark that the mdev_parent_ops indirection shim is useless and
complicates things.
It applies on top of Alex's current tree and requires the prior two
series.
The mdev bus's core part for managing the lifecycle of devices is mostly
as one would expect for a driver core bus subsystem.
However instead of having a normal 'struct device_driver' and binding the
actual mdev drivers through the standard driver core mechanisms it open
codes this with the
On Fri, Apr 23, 2021 at 05:31:12PM -0500, Jason Ekstrand wrote:
> The idea behind this param is to support OpenCL drivers with relocations
> because OpenCL reserves 0x0 for NULL and, if we placed memory there, it
> would confuse CL kernels. It was originally sent out as part of a patch
> series
On Fri, Apr 23, 2021 at 05:31:11PM -0500, Jason Ekstrand wrote:
> This reverts commit 88be76cdafc7 ("drm/i915: Allow userspace to specify
> ringsize on construction"). This API was originally added for OpenCL
> but the compute-runtime PR has sat open for a year without action so we
> can still
Reviewed-by: Simon Ser
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/dg1: Fix mapping type for
default state object
URL : https://patchwork.freedesktop.org/series/89529/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't
== Series Details ==
Series: series starting with [v2,1/7] drm/i915/dg1: Fix mapping type for
default state object
URL : https://patchwork.freedesktop.org/series/89529/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
c40331cdc349 drm/i915/dg1: Fix mapping type for default state
It's very confusing for userspace to have to deal with inconsistencies
here, and some drivers screwed this up a bit. Most just ommitted the
format list when they meant to say that only linear modifier is
allowed, but some also meant that only implied modifiers are
acceptable (because actually none
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
Setting the cap without the modifier list is very confusing to
userspace. Fix that by listing the ones we support explicitly.
Stable backport so that userspace can rely on this working in a
reasonable way, i.e. that the cap set implies IN_FORMATS is available.
Cc: sta...@vger.kernel.org
Cc:
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
Even when all we support is linear, make that explicit. Otherwise the
uapi is rather confusing.
Cc: sta...@vger.kernel.org
Cc: Pekka Paalanen
Cc: Liviu Dudau
Cc: Brian Starkey
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/malidp_planes.c | 9 +++--
1 file changed, 7 insertions(+),
Since
commit 890880ddfdbe256083170866e49c87618b706ac7
Author: Paul Kocialkowski
Date: Fri Jan 4 09:56:10 2019 +0100
drm: Auto-set allow_fb_modifiers when given modifiers at plane init
this is done automatically as part of plane init, if drivers set the
modifier list correctly. Which is
On Mon, Apr 26, 2021 at 08:18:39PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 26, 2021 at 06:08:59PM +0200, Daniel Vetter wrote:
> > On Thu, Apr 22, 2021 at 04:11:22PM +0300, Ville Syrjälä wrote:
> > > On Thu, Apr 22, 2021 at 11:49:43AM +0200, Daniel Vetter wrote:
> > > > On Wed, Apr 21, 2021 at
From: Mohammed Khajapasha
Use local memory io BAR address for fbdev's fb_mmap() operation on
discrete, fbdev uses the physical address of our framebuffer for its
fb_mmap() fn.
Signed-off-by: Mohammed Khajapasha
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
From: Mohammed Khajapasha
Return EREMOTE value when frame buffer object is not backed by LMEM
for discrete. If Local memory is supported by hardware the framebuffer
backing gem objects should be from local memory.
Signed-off-by: Mohammed Khajapasha
Signed-off-by: Matthew Auld
Reviewed-by:
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
has_aperture check since it should always be present on such platforms.
(Chris)
Cc:
It's a requirement that for dgfx we place all the paging structures in
device local-memory.
v2: use i915_coherent_map_type()
v3: improve the shared dma-resv object comment
Signed-off-by: Matthew Auld
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 5 -
We need to generalise our accessor for the page directories and tables from
using the simple kmap_atomic to support local memory, and this setup
must be done on acquisition of the backing storage prior to entering
fence execution contexts. Here we replace the kmap with the object
mapping code that
From: Venkata Sandeep Dhanalakota
Determine the possible coherent map type based on object location,
and if target has llc or if user requires an always coherent
mapping.
Cc: Matthew Auld
Cc: CQ Tang
Suggested-by: Michal Wajdeczko
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by:
From: Venkata Ramana Nayana
Use I915_MAP_WC when default state object is allocated in LMEM.
Signed-off-by: Venkata Ramana Nayana
Reviewed-by: Matthew Auld
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff
Hi Dave & Daniel -
Some fixes to the drm-next feature pull.
drm-intel-next-fixes-2021-04-27:
drm/i915 fixes for v5.13-rc1:
- Several fixes to GLK handling in recent display refactoring (Ville)
- Rare watchdog timer race fix (Tvrtko)
- Cppcheck redundant condition fix (José)
- Overlay error code
Am Mon, 26 Apr 2021 19:05:40 +0300
schrieb Ville Syrjälä :
> On Mon, Apr 26, 2021 at 04:11:24PM +0200, Simon Rettberg wrote:
> > When resetting CACHE_MODE registers, don't enable HiZ Raw Stall
> > Optimization on Ivybridge GT1 and Baytrail, as it causes severe
> > glitches when rendering any kind
On 26/04/2021 17:18, Matthew Auld wrote:
On 26/04/2021 16:20, Tvrtko Ursulin wrote:
On 26/04/2021 11:18, Matthew Auld wrote:
We need to general our accessor for the page directories and tables from
Generalise?
using the simple kmap_atomic to support local memory, and this setup
must be
On Mon, 26 Apr 2021, Randy Dunlap wrote:
> When CONFIG_DRM_I915=y, CONFIG_ACPI is not set, and
> CONFIG_BACKLIGHT_CLASS_DEVICE=m, not due to I915 config,
> there are build errors trying to reference backlight_device_{un}register().
>
> Changing the use of IS_ENABLED() to IS_REACHABLE() in
On Tue, 27 Apr 2021, Ville Syrjälä wrote:
> On Tue, Apr 27, 2021 at 12:07:21AM +, Souza, Jose wrote:
>> On Mon, 2021-04-26 at 21:56 +0300, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > The pipe crc code slipped theough the net when we tried to
>> > eliminate all crtc->index==pipe
== Series Details ==
Series: Implement PSF GV point support (rev2)
URL : https://patchwork.freedesktop.org/series/89491/
State : failure
== Summary ==
Applying: Implement PSF GV point support
error: sha1 information is lacking or useless
(drivers/gpu/drm/i915/display/intel_bw.c).
error:
PSF GV points are an additional factor that can limit the
bandwidth available to display, separate from the traditional
QGV points. Whereas traditional QGV points represent possible
memory clock frequencies, PSF GV points reflect possible
frequencies of the memory fabric.
Switching between PSF
101 - 136 of 136 matches
Mail list logo
