> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 21 March 2023 02:04
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 3/6] drm/i915/vrr: Make delayed vblank
> operational in VRR mode on adl/dg2
>
> From: Ville Syrjälä
>
> On adl/dg2 a chic
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 21 March 2023 02:04
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 4/6] drm/i915/vrr: Tell
> intel_crtc_update_active_timings() about VRR explicitly
>
> From: Ville Syrjälä
>
> In order to
Add an interface to obtain hwmon energy values. The function returns
per-gt energy if gt level energy is available else returns the package
level energy if there is a single gt.
This is used by selftests to verify power consumption
v2 : use i915_hwmon prefix (Anshuman)
v3 : re-use is_visible funct
Rename librapl files to libpower and replace librapl
with libpower prefix. No functional changes
v2: update commit message (Anshuman)
v3: fix license year
Signed-off-by: Riana Tauro
Reviewed-by: Anshuman Gupta
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/Makefile |
From: Tilak Tangudu
hwmon provides an interface to read energy values for discrete graphics.
add hwmon support to the existing libpower library so that it can verify
power consumption values in different selftests.
Changed prototype of libpower_get_energy_uJ
v2: add per-gt hwmon support (Ashuto
Hwmon reads the energy/power consumed by discrete soc,
i.e. energy/power includes the power drawn from non-gfx discrete
components
This test uses the power consumed by GT to validate RC6
power consumption.
Skip comparison of power for discrete graphics
TODO : measure power of GT in discrete graph
Rename librapl library to libpower. Add hwmon support in libpower for
dgfx.
Use libpower in selftests.
Rev2 : Update commit message
Rev3 : Remove redundant code
Rev4 : Add hwmon per-gt support
Rev5 : No functional changes.
Change author for last patch
Rev6 : re-order libpower library patch
Type-C PHYs are taking longer than expected for Aux IO Power Enabling.
Workaround: Increase the timeout.
WA_14017248603: adlp
Bspec: 55480
---v2
-change style on how we mention WA [Ankit]
-fix bat error
Signed-off-by: Suraj Kandpal
---
.../i915/display/intel_display_power_well.c | 30 +++
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 21 March 2023 02:04
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 6/6] drm/i915/vrr: Allow VRR to be toggled during
> fastsets
>
> From: Ville Syrjälä
>
> Now that VRR enable/disable are
== Series Details ==
Series: fbmem: Reject FB_ACTIVATE_KD_TEXT from userspace
URL : https://patchwork.freedesktop.org/series/116107/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12966_full -> Patchwork_116107v1_full
Summar
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 21 March 2023 02:04
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/6] drm/i915: Generalize planes_{enabling,
> disabling}()
>
> From: Ville Syrjälä
>
> I want to use the same logic that
On 04/04/2023 19:04, Yang, Fei wrote:
Subject: Re: [Intel-gfx] [PATCH 7/7] drm/i915: Allow user to set cache at BO
creation
On 01/04/2023 09:38, fei.y...@intel.com wrote:
From: Fei Yang
To comply with the design that buffer objects shall have immutable
cache setting through out its life cycl
Hi
Am 04.04.23 um 22:18 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu and never shipped with anything discrete, so there should
not be any difference.
v2: Unfortunately the framebuffer sits outside of the pci bars for
gma500, and so only
> From: Alex Williamson
> Sent: Wednesday, April 5, 2023 4:19 AM
>
> On Sat, 1 Apr 2023 07:44:22 -0700
> Yi Liu wrote:
>
> > as an alternative method for ownership check when iommufd is used. In
> > this case all opened devices in the affected dev_set are verified to
> > be bound to a same val
On Wed, Apr 05, 2023 at 12:53:29AM +0300, Dmitry Baryshkov wrote:
> On 04/04/2023 22:16, Daniel Vetter wrote:
> > On Tue, Apr 04, 2023 at 08:22:05PM +0300, Dmitry Baryshkov wrote:
> > > On 08/03/2023 17:53, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > For an atomic commit updating a s
> From: Liu, Yi L
> Sent: Wednesday, April 5, 2023 3:55 PM
> >
> > Therefore, I think as written, the singleton dev_set hot-reset is
> > enabled for iommufd and (unintentionally?) for the group path, while
> > also negating a requirement for a group fd or that a provided group fd
> > actually ma
On 4/4/23 22:18, Alex Williamson wrote:
> On Sat, 1 Apr 2023 07:44:22 -0700
> Yi Liu wrote:
>
>> as an alternative method for ownership check when iommufd is used. In
>> this case all opened devices in the affected dev_set are verified to
>> be bound to a same valid iommufd value to allow rese
On Wed, Apr 5, 2023 at 9:49 AM Thomas Zimmermann wrote:
>
> Hi
>
> Am 04.04.23 um 22:18 schrieb Daniel Vetter:
> > This one nukes all framebuffers, which is a bit much. In reality
> > gma500 is igpu and never shipped with anything discrete, so there should
> > not be any difference.
> >
> > v2: Un
Hi
Am 05.04.23 um 09:49 schrieb Thomas Zimmermann:
Hi
Am 04.04.23 um 22:18 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu and never shipped with anything discrete, so there should
not be any difference.
v2: Unfortunately the framebuffer
Hi Yi,
On 4/1/23 16:44, Yi Liu wrote:
> This extends both vfio_file_is_valid() and vfio_file_has_dev() to accept
> device file from the vfio PCI hot reset.
typo in the title s/Accpet/Accept
>
> Reviewed-by: Kevin Tian
> Reviewed-by: Jason Gunthorpe
> Tested-by: Yanting Jiang
> Signed-off-by: Yi
Hi Eric,
> From: Eric Auger
> Sent: Wednesday, April 5, 2023 4:02 PM
>
> On 4/4/23 22:18, Alex Williamson wrote:
> > On Sat, 1 Apr 2023 07:44:22 -0700
> > Yi Liu wrote:
> >
> >> as an alternative method for ownership check when iommufd is used. In
> >> this case all opened devices in the affe
> From: Eric Auger
> Sent: Wednesday, April 5, 2023 4:08 PM
>
> Hi Yi,
>
> On 4/1/23 16:44, Yi Liu wrote:
> > This extends both vfio_file_is_valid() and vfio_file_has_dev() to accept
> > device file from the vfio PCI hot reset.
> typo in the title s/Accpet/Accept
thanks. would correct it.
> >
Hi Patrik
Am 05.04.23 um 10:05 schrieb Patrik Jakobsson:
On Wed, Apr 5, 2023 at 9:49 AM Thomas Zimmermann wrote:
Hi
Am 04.04.23 um 22:18 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu and never shipped with anything discrete, so there
If the crtc is being switched on or off then the semantics of
computing the timestampe of the next vblank is somewhat ill-defined.
And indeed, the code splats with a warning in the timestamp
computation code. Specifically it hits the check to make sure that
atomic drivers have full set up the timin
Hi
Am 04.04.23 um 22:18 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu and never shipped with anything discrete, so there should
not be any difference.
I do own an Intel DN2800MT board with gma500 hardware. [1] It has a PCIe
x1 slot. I n
Hi Yi,
On 4/1/23 16:44, Yi Liu wrote:
> This prepares vfio core to accept vfio device file from the vfio PCI
> hot reset path. vfio_file_is_group() is still kept for KVM usage.
>
> Reviewed-by: Kevin Tian
> Reviewed-by: Jason Gunthorpe
> Tested-by: Yanting Jiang
> Signed-off-by: Yi Liu
> ---
>
== Series Details ==
Series: series starting with [1/3] drm/fb-helper: set x/yres_virtual in
drm_fb_helper_check_var
URL : https://patchwork.freedesktop.org/series/116109/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12966_full -> Patchwork_116109v1_full
On 05/04/2023 07:56, Upadhyay, Tejas wrote:
-int igt_live_test_end(struct igt_live_test *t)
+int igt_live_test_end(struct igt_live_test *t, struct intel_gt *gt)
{
- struct drm_i915_private *i915 = t->i915;
+ struct drm_i915_private *i915 = gt->i915;
struct intel_engine_cs
On Tue, Apr 04, 2023 at 01:59:33PM -0700, Aaron Plattner wrote:
> On 4/4/23 1:18 PM, Daniel Vetter wrote:
> > Instead of calling aperture_remove_conflicting_devices() to remove the
> > conflicting devices, just call to aperture_detach_devices() to detach
> > the device that matches the same PCI BAR
Hi Mika,
On Mon, Mar 27, 2023 at 03:34:26PM +0300, Mika Kahola wrote:
> Phy programming support for C10 PICA chips. This is the first part of
> the series that adds support for PICA chips. Later the support for
> C20 chips are added.
>
> Signed-off-by: Mika Kahola
>
> Clint Taylor (1):
> drm/
On Wed, Apr 05, 2023 at 10:07:54AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.04.23 um 09:49 schrieb Thomas Zimmermann:
> > Hi
> >
> > Am 04.04.23 um 22:18 schrieb Daniel Vetter:
> > > This one nukes all framebuffers, which is a bit much. In reality
> > > gma500 is igpu and never shipped with
Hi Dave & Daniel -
drm-intel-fixes-2023-04-05:
drm/i915 fixes for v6.3-rc6:
- Fix DP MST DSC M/N calculation to use compressed bpp
- Fix racy use-after-free in perf ioctl
- Fix context runtime accounting
- Fix handling of GT reset during HuC loading
- Fix use of unsigned vm_fault_t for error val
On Wed, Apr 05, 2023 at 10:19:55AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 04.04.23 um 22:18 schrieb Daniel Vetter:
> > This one nukes all framebuffers, which is a bit much. In reality
> > gma500 is igpu and never shipped with anything discrete, so there should
> > not be any difference.
>
>
> From: Eric Auger
> Sent: Wednesday, April 5, 2023 4:28 PM
>
> Hi Yi,
> On 4/1/23 16:44, Yi Liu wrote:
> > This prepares vfio core to accept vfio device file from the vfio PCI
> > hot reset path. vfio_file_is_group() is still kept for KVM usage.
> >
> > Reviewed-by: Kevin Tian
> > Reviewed-by:
== Series Details ==
Series: drm/ttm: Small fixes / cleanups in prep for shrinking (rev3)
URL : https://patchwork.freedesktop.org/series/114774/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12966_full -> Patchwork_114774v3_full
On Tue, Apr 04, 2023 at 10:18:37PM +0200, Daniel Vetter wrote:
> Only really pci devices have a business setting this - it's for
> figuring out whether the legacy vga stuff should be nuked too. And
> with the preceeding two patches those are all using the pci version of
> this.
>
> Which means for
Hi
Am 05.04.23 um 10:59 schrieb Daniel Vetter:
On Wed, Apr 05, 2023 at 10:07:54AM +0200, Thomas Zimmermann wrote:
Hi
Am 05.04.23 um 09:49 schrieb Thomas Zimmermann:
Hi
Am 04.04.23 um 22:18 schrieb Daniel Vetter:
This one nukes all framebuffers, which is a bit much. In reality
gma500 is igpu
> From: Alex Williamson
> Sent: Wednesday, April 5, 2023 5:01 AM
>
> On Sat, 1 Apr 2023 07:44:28 -0700
> Yi Liu wrote:
>
> > as there are IOMMUFD users that want to know check if an ID generated
> > by IOMMUFD is valid or not. e.g. vfio-pci optionaly returns invalid
> > dev_id to user in the V
On 4/1/23 16:44, Yi Liu wrote:
> No functional change is intended.
>
> Reviewed-by: Kevin Tian
> Reviewed-by: Jason Gunthorpe
> Tested-by: Yanting Jiang
> Signed-off-by: Yi Liu
Reviewed-by: Eric Auger
Eric
> ---
> drivers/vfio/pci/vfio_pci_core.c | 52
> 1
On 4/1/23 16:44, Yi Liu wrote:
> Now user can also provide an array of device fds as a 3rd method to verify
> the reset ownership. It's not useful at this point when the device fds are
> acquired via group fds. But it's necessary when moving to device cdev which
> allows the user to directly acq
On Wed, Apr 05, 2023 at 11:26:51AM +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.04.23 um 10:59 schrieb Daniel Vetter:
> > On Wed, Apr 05, 2023 at 10:07:54AM +0200, Thomas Zimmermann wrote:
> > > Hi
> > >
> > > Am 05.04.23 um 09:49 schrieb Thomas Zimmermann:
> > > > Hi
> > > >
> > > > Am 04.04.
On Wed, Apr 05, 2023 at 12:04:04PM +0300, Jani Nikula wrote:
>
> Hi Dave & Daniel -
>
> drm-intel-fixes-2023-04-05:
> drm/i915 fixes for v6.3-rc6:
> - Fix DP MST DSC M/N calculation to use compressed bpp
> - Fix racy use-after-free in perf ioctl
> - Fix context runtime accounting
> - Fix handling
== Series Details ==
Series: series starting with [1/8] drm/gma500: Use
drm_aperture_remove_conflicting_pci_framebuffers
URL : https://patchwork.freedesktop.org/series/116115/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12966_full -> Patchwork_116115v1_full
Daniel Vetter writes:
> Drivers are supposed to fix this up if needed if they don't outright
> reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
> sizes in fb_set_var()").
>
Should have a Fixes: tag ? I understand what was uncovered by that commit
but it help distros to figure o
Daniel Vetter writes:
> The fb_check_var hook is supposed to validate all this stuff. Any
> errors from fb_set_par are considered driver/hw issues and resulting
> in dmesg warnings.
>
> Luckily we do fix up the pixclock already, so this is all fine.
>
> Signed-off-by: Daniel Vetter
> Cc: Maarten
There's not much point in a static work function having a kernel-doc
comment. Just clean it up and make it a regular comment.
This fixes the kernel-doc warnings:
drivers/gpu/drm/i915/display/intel_tc.c:1370: warning: Function
parameter or member 'work' not described in
'intel_tc_port_disconnect_p
Fix the warning:
drivers/gpu/drm/i915/intel_wakeref.h:118: warning: expecting prototype
for intel_wakeref_get_if_in_use(). Prototype was for
intel_wakeref_get_if_active() instead
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/intel_wakeref.h | 2 +-
1 file changed, 1 insertion(+), 1 deleti
On 4/4/2023 5:30 PM, Andrzej Hajda wrote:
On 04.04.2023 16:30, Nirmoy Das wrote:
Add a mechanism to keep existing data when creating
a ttm object with I915_BO_ALLOC_USER flag.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-
On Tue, 04 Apr 2023, Rodrigo Vivi wrote:
> On Tue, Apr 04, 2023 at 03:26:24PM +0300, Jani Nikula wrote:
>> On Tue, 04 Apr 2023, kernel test robot wrote:
>> > Hi Jani,
>> >
>> > kernel test robot noticed the following build warnings:
>>
>> Yeah, that's kind of the point of adding more checks. ;)
Daniel Vetter writes:
> Apparently drivers need to check all this stuff themselves, which for
> most things makes sense I guess. And for everything else we luck out,
> because modern distros stopped supporting any other fbdev drivers than
> drm ones and I really don't want to argue anymore about
On 4/4/2023 6:23 PM, Andi Shyti wrote:
Hi Nirmoy,
On Tue, Apr 04, 2023 at 04:30:56PM +0200, Nirmoy Das wrote:
Add a mechanism to keep existing data when creating
a ttm object with I915_BO_ALLOC_USER flag.
why do we need this mechanism? What was the logic behind? These
are all questions peopl
Hi
Am 05.04.23 um 11:38 schrieb Daniel Vetter:
On Wed, Apr 05, 2023 at 11:26:51AM +0200, Thomas Zimmermann wrote:
Hi
Am 05.04.23 um 10:59 schrieb Daniel Vetter:
On Wed, Apr 05, 2023 at 10:07:54AM +0200, Thomas Zimmermann wrote:
Hi
Am 05.04.23 um 09:49 schrieb Thomas Zimmermann:
Hi
Am 04.0
Thomas Zimmermann writes:
[...]
>
> Your comment says that it calls a PCI function to clean up to vgacon.
> That comment explains what is happening, not why. And how the PCI and
> vgacon code work together is non-obvious.
>
> Again, here's my proposal for gma500:
>
> // call this from psb_pci_
Daniel Vetter writes:
> Since vgaarb has been promoted to be a core piece of the pci subsystem
> we don't have to open code random guesses anymore, we actually know
> this in a platform agnostic way, and there's no need for an x86
> specific hack. See also 1d38fe6ee6a8 ("PCI/VGA: Move vgaarb to
>
Daniel Vetter writes:
> Only really pci devices have a business setting this - it's for
> figuring out whether the legacy vga stuff should be nuked too. And
> with the preceeding two patches those are all using the pci version of
> this.
>
> Which means for all other callers primary == false and
On Wed, 2023-04-05 at 13:41 +0300, Jani Nikula wrote:
> There's not much point in a static work function having a kernel-doc
> comment. Just clean it up and make it a regular comment.
>
> This fixes the kernel-doc warnings:
>
> drivers/gpu/drm/i915/display/intel_tc.c:1370: warning: Function
> par
Daniel Vetter writes:
> Otherwise it's bit silly, and we might throw out the driver for the
> screen the user is actually looking at. I haven't found a bug report
> for this case yet, but we did get bug reports for the analog case
> where we're throwing out the efifb driver.
>
> v2: Flip the chec
On Wed, 2023-04-05 at 13:41 +0300, Jani Nikula wrote:
> Fix the warning:
>
> drivers/gpu/drm/i915/intel_wakeref.h:118: warning: expecting prototype
> for intel_wakeref_get_if_in_use(). Prototype was for
> intel_wakeref_get_if_active() instead
>
> Signed-off-by: Jani Nikula
> ---
Thanks
Reviewe
Daniel Vetter writes:
> A few reasons for this:
>
> - It's really the only one where this matters. I tried looking around,
> and I didn't find any non-pci vga-compatible controllers for x86
> (since that's the only platform where we had this until a few
> patches ago), where a driver partic
Daniel Vetter writes:
> With the preceeding patches it's become defunct. Also I'm about to add
> a different boolean argument, so it's better to keep the confusion
> down to the absolute minimum.
>
> v2: Since the hypervfb patch got droppped (it's only a pci device for
> gen1 vm, not for gen2) th
Daniel Vetter writes:
> Instead of calling aperture_remove_conflicting_devices() to remove the
> conflicting devices, just call to aperture_detach_devices() to detach
> the device that matches the same PCI BAR / aperture range. Since the
> former is just a wrapper of the latter plus a sysfb_disab
Daniel Vetter writes:
> vga_default_device really is supposed to cover all corners, at least
> for x86. Additionally checking for rom shadowing should be redundant,
> because the bios/fw only does that for the boot vga device.
>
> If this turns out to be wrong, then most likely that's a special c
On Tue, Apr 04, 2023 at 05:59:01PM +0200, Eric Auger wrote:
> > but the hot reset shall fail as the group is not owned by the user.
>
> sure it shall but I fail to understand if the reset fails or the device
> plug is somehow delayed until the reset completes.
It is just racy today - vfio_pci_de
Hi Yi
On 4/1/23 16:44, Yi Liu wrote:
> as there are IOMMUFD users that want to know check if an ID generated
s/want to know check/ need to check
which type of ID?
> by IOMMUFD is valid or not. e.g. vfio-pci optionaly returns invalid
optionally
> dev_id to user in the VFIO_DEVICE_GET_PCI_HOT_RESET_
On 4/1/23 16:44, Yi Liu wrote:
> There are users that need to check if vfio_device is opened as cdev.
> e.g. vfio-pci. This adds a flag in vfio_device, it will be set in the
> cdev path when device is opened. This is not used at this moment, but
> a preparation for vfio device cdev support.
bet
Hi Nirmoy,
> > > Add a mechanism to keep existing data when creating
> > > a ttm object with I915_BO_ALLOC_USER flag.
> > why do we need this mechanism? What was the logic behind? These
> > are all questions people might have when checking this commit.
> > Please be a bit more explicative.
>
>
>
On Tue, Apr 04, 2023 at 04:45:12PM -0600, Alex Williamson wrote:
> On Sat, 1 Apr 2023 08:18:24 -0700
> Yi Liu wrote:
>
> > From: Nicolin Chen
> >
> > Previously, the detach routine is only done by the destroy(). And it was
> > called by vfio_iommufd_emulated_unbind() when the device runs close
Hi Yi,
On 4/1/23 16:44, Yi Liu wrote:
> for the users that accept device fds passed from management stacks to be
> able to figure out the host reset affected devices among the devices
> opened by the user. This is needed as such users do not have BDF (bus,
> devfn) knowledge about the devices it
Hi Yi,
On 4/1/23 17:18, Yi Liu wrote:
> since no user of vfio_file_is_group() now.
>
> Reviewed-by: Kevin Tian
> Reviewed-by: Jason Gunthorpe
> Tested-by: Terrence Xu
> Tested-by: Nicolin Chen
> Tested-by: Yanting Jiang
> Signed-off-by: Yi Liu
Reviewed-by: Eric Auger
Eric
> ---
> drivers
On Wed, Apr 05, 2023 at 10:16:50AM +0200, Daniel Vetter wrote:
> If the crtc is being switched on or off then the semantics of
> computing the timestampe of the next vblank is somewhat ill-defined.
> And indeed, the code splats with a warning in the timestamp
> computation code. Specifically it hit
Am 04.04.23 um 22:06 schrieb Thomas Hellström:
I collected the, from my POW, uncontroversial patches from V1 of the TTM
shrinker series, some corrected after the initial patch submission, one
patch added from the Xe RFC ("drm/ttm: Don't print error message if
eviction was interrupted"). It would
Hi Andi,
On 4/5/2023 1:53 PM, Andi Shyti wrote:
Hi Nirmoy,
Add a mechanism to keep existing data when creating
a ttm object with I915_BO_ALLOC_USER flag.
why do we need this mechanism? What was the logic behind? These
are all questions people might have when checking this commit.
Please be a
On 4/5/23 14:32, Christian König wrote:
Am 04.04.23 um 22:06 schrieb Thomas Hellström:
I collected the, from my POW, uncontroversial patches from V1 of the TTM
shrinker series, some corrected after the initial patch submission, one
patch added from the Xe RFC ("drm/ttm: Don't print error messa
== Series Details ==
Series: fdinfo: Enable some support for GuC based client busyness
URL : https://patchwork.freedesktop.org/series/116120/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12967_full -> Patchwork_116120v1_full
===
On Tue, Apr 4, 2023 at 10:18 PM Daniel Vetter wrote:
>
> Only really pci devices have a business setting this - it's for
> figuring out whether the legacy vga stuff should be nuked too. And
> with the preceeding two patches those are all using the pci version of
I think it's spelled "preceding"
[
The default value of i915.enable_psr2_sel_fetch is true while the
description given in i915_params.c is 0. Changing to correct the
description.
Signed-off-by: Qiyu Yan
---
drivers/gpu/drm/i915/i915_params.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/
On Wed, Apr 05, 2023 at 01:16:27PM +0200, Javier Martinez Canillas wrote:
> Thomas Zimmermann writes:
>
> [...]
>
> >
> > Your comment says that it calls a PCI function to clean up to vgacon.
> > That comment explains what is happening, not why. And how the PCI and
> > vgacon code work togethe
On Wed, Apr 05, 2023 at 12:52:12PM +0200, Javier Martinez Canillas wrote:
> Daniel Vetter writes:
>
> > Apparently drivers need to check all this stuff themselves, which for
> > most things makes sense I guess. And for everything else we luck out,
> > because modern distros stopped supporting any
On Wed, Apr 05, 2023 at 12:21:11PM +0200, Javier Martinez Canillas wrote:
> Daniel Vetter writes:
>
> > Drivers are supposed to fix this up if needed if they don't outright
> > reject it. Uncovered by 6c11df58fd1a ("fbmem: Check virtual screen
> > sizes in fb_set_var()").
> >
>
> Should have a F
On Wed, Apr 05, 2023 at 03:25:15PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 05, 2023 at 10:16:50AM +0200, Daniel Vetter wrote:
> > If the crtc is being switched on or off then the semantics of
> > computing the timestampe of the next vblank is somewhat ill-defined.
> > And indeed, the code splats
If the crtc is being switched on or off then the semantics of
computing the timestampe of the next vblank is somewhat ill-defined.
And indeed, the code splats with a warning in the timestamp
computation code. Specifically it hits the check to make sure that
atomic drivers have full set up the timin
== Series Details ==
Series: Update DSC Bigjoiner BW check (rev3)
URL : https://patchwork.freedesktop.org/series/115773/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12967_full -> Patchwork_115773v3_full
Summary
---
On Wed, Apr 05, 2023 at 03:31:05PM +0200, Daniel Vetter wrote:
> If the crtc is being switched on or off then the semantics of
> computing the timestampe of the next vblank is somewhat ill-defined.
> And indeed, the code splats with a warning in the timestamp
> computation code. Specifically it hit
On Tue, 04 Apr 2023, Jani Nikula wrote:
> On Mon, 03 Apr 2023, Lee Jones wrote:
> > On Mon, 03 Apr 2023, Jani Nikula wrote:
> >
> >> On Fri, 31 Mar 2023, Lee Jones wrote:
> >> > Fixes the following W=1 kernel build warning(s):
> >> >
> >> > drivers/gpu/drm/i915/i915_scatterlist.c:62: warning: F
Hi Yi,
On 4/1/23 17:18, Yi Liu wrote:
> This gives notes for userspace applications on device cdev usage.
>
> Reviewed-by: Kevin Tian
> Signed-off-by: Yi Liu
> ---
> Documentation/driver-api/vfio.rst | 132 ++
> 1 file changed, 132 insertions(+)
>
> diff --git a/Docu
On Wed, Apr 5, 2023 at 6:31 AM Daniel Vetter wrote:
>
> If the crtc is being switched on or off then the semantics of
> computing the timestampe of the next vblank is somewhat ill-defined.
> And indeed, the code splats with a warning in the timestamp
> computation code. Specifically it hits the ch
> Add a mechanism to preserve existing data when creating a TTM
> object with the I915_BO_ALLOC_USER flag. This will be used in the subsequent
> patch where the I915_BO_ALLOC_USER flag will be applied to the framebuffer
> object. For a pre-allocated framebuffer without the I915_BO_PREALLOC flag,
>
On Fri, Mar 31, 2023 at 08:11:29PM -0700, Dixit, Ashutosh wrote:
> On Fri, 31 Mar 2023 19:00:49 -0700, Vinay Belgaumkar wrote:
> >
>
> Hi Vinay,
>
> > @@ -478,20 +507,15 @@ int intel_guc_slpc_set_min_freq(struct intel_guc_slpc
> > *slpc, u32 val)
> > val > slpc->max_freq_softlimit)
> >
Hi Eric,
> From: Eric Auger
> Sent: Wednesday, April 5, 2023 9:46 PM
>
> Hi Yi,
>
> On 4/1/23 17:18, Yi Liu wrote:
> > This gives notes for userspace applications on device cdev usage.
> >
> > Reviewed-by: Kevin Tian
> > Signed-off-by: Yi Liu
> > ---
> > Documentation/driver-api/vfio.rst | 1
Hi Eric,
> From: Eric Auger
> Sent: Wednesday, April 5, 2023 8:20 PM
>
> Hi Yi,
> On 4/1/23 16:44, Yi Liu wrote:
> > for the users that accept device fds passed from management stacks to be
> > able to figure out the host reset affected devices among the devices
> > opened by the user. This is n
> From: Jason Gunthorpe
> Sent: Wednesday, April 5, 2023 7:56 PM
>
> On Tue, Apr 04, 2023 at 04:45:12PM -0600, Alex Williamson wrote:
> > On Sat, 1 Apr 2023 08:18:24 -0700
> > Yi Liu wrote:
> >
> > > From: Nicolin Chen
> > >
> > > Previously, the detach routine is only done by the destroy(). A
On 04.04.2023 16:30, Nirmoy Das wrote:
Framebuffer is exposed to userspace so make sure we set
proper flags for it. Set I915_BO_PREALLOC for prealloced
fb so that ttm won't clear existing data.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Andrzej Hajda
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre D
On 04.04.2023 16:30, Nirmoy Das wrote:
Add a helper function to retrieve struct intel_fbdev from
struct drm_fb_helper.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Nirmoy Das
Reviewed-by: Jani Nikula
Reviewed-by: Andi Shyti
Reviewed-by
On 05.04.2023 16:13, Andrzej Hajda wrote:
On 04.04.2023 16:30, Nirmoy Das wrote:
Add a helper function to retrieve struct intel_fbdev from
struct drm_fb_helper.
Cc: Matthew Auld
Cc: Andi Shyti
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Imre Deak
Signed-off-by: Nirmoy Das
Reviewed-by: Jani
On 31.03.2023 16:16, Andrzej Hajda wrote:
From: Chris Wilson
There may be a disconnect between the GT used by the engine and the GT
used for the VM, requiring us to hold a wakeref on both while the GPU is
active with this request.
v2: added explanation to __queue_and_release_pm
Signed-off-by:
On Wed, Apr 05, 2023 at 02:10:19PM +, Liu, Yi L wrote:
> > From: Jason Gunthorpe
> > Sent: Wednesday, April 5, 2023 7:56 PM
> >
> > On Tue, Apr 04, 2023 at 04:45:12PM -0600, Alex Williamson wrote:
> > > On Sat, 1 Apr 2023 08:18:24 -0700
> > > Yi Liu wrote:
> > >
> > > > From: Nicolin Chen
Hi
Am 05.04.23 um 15:18 schrieb Daniel Vetter:
On Wed, Apr 05, 2023 at 01:16:27PM +0200, Javier Martinez Canillas wrote:
Thomas Zimmermann writes:
[...]
Your comment says that it calls a PCI function to clean up to vgacon.
That comment explains what is happening, not why. And how the PCI a
> From: Jason Gunthorpe
> Sent: Wednesday, April 5, 2023 10:29 PM
> > > >
> > > > Does this need to go in via iommufd first? There seems to be quite a
> > > > bit of churn in iommufd/device.c vs the vfio_mdev_ops branch (ie. it
> > > > doesn't apply). Thanks,
> > >
> > > I think it is best to sta
On Tue, Apr 04, 2023 at 03:29:15PM -0300, Gustavo Sousa wrote:
> Quoting Haridhar Kalvala (2023-04-04 14:32:20)
> > Wa_14017856879 implementation for mtl.
> >
> > Bspec: 46046
> >
> > Signed-off-by: Haridhar Kalvala
>
> Reviewed-by: Gustavo Sousa
Applied to drm-intel-gt-next. Thanks for the
On Wed, 5 Apr 2023 09:31:39 +
"Liu, Yi L" wrote:
> > From: Alex Williamson
> > Sent: Wednesday, April 5, 2023 5:01 AM
> >
> > On Sat, 1 Apr 2023 07:44:28 -0700
> > Yi Liu wrote:
> >
> > > as there are IOMMUFD users that want to know check if an ID generated
> > > by IOMMUFD is valid or
1 - 100 of 166 matches
Mail list logo
