Re: [Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic

On Tue, 06 Apr 2021, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some rounding involved. > > pwm_get_state() traditionally returned the setting that was requested most > recently by the consumer (

[Intel-gfx] [PATCH] drm/i915/hdcp: Fix uninitialized symbol 'msg_end'

Fix static analysis tool uninitialized symbol error. Reported-by: kernel test robot Reported-by: Dan Carpenter Signed-off-by: Anshuman Gupta --- drivers/gpu/drm/i915/display/intel_dp_hdcp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_d

Re: [Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic

On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some rounding involved. > > pwm_get_state() traditionally returned the setting that was requested most > recen

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Do not report 100% RC6 if not supported

Hi Tvrtko, > We use GT parked status to estimate RC6 while not in use, however if RC6 > is not supported to start with that does not work very well and produces a > false 100% RC6 readout. > > Fix by not advancing the estimated RC6 counter when feature is not > supported. > > Signed-off-by: Tvrt

[Intel-gfx] ✗ Fi.CI.DOCS: warning for drm/i915/hdcp: Fix uninitialized symbol 'msg_end'

== Series Details == Series: drm/i915/hdcp: Fix uninitialized symbol 'msg_end' URL : https://patchwork.freedesktop.org/series/88756/ 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 me

Re: [Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic

On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some rounding involved. Acked-by: Mark Brown signature.asc Description: PGP signature _

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/hdcp: Fix uninitialized symbol 'msg_end'

== Series Details == Series: drm/i915/hdcp: Fix uninitialized symbol 'msg_end' URL : https://patchwork.freedesktop.org/series/88756/ State : success == Summary == CI Bug Log - changes from CI_DRM_9928 -> Patchwork_19894 Summary --- *

Re: [Intel-gfx] [PATCH 00/11] treewide: address gcc-11 -Wstringop-overread warnings

On Mon, 22 Mar 2021 17:02:38 +0100, Arnd Bergmann wrote: > The coming gcc release introduces a new warning for string operations > reading beyond the end of a fixed-length object. After testing > randconfig kernels for a while, think I have patches for any such > warnings that came up on x86, arm

[Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic

Given that lowlevel drivers usually cannot implement exactly what a consumer requests with pwm_apply_state() there is some rounding involved. pwm_get_state() traditionally returned the setting that was requested most recently by the consumer (opposed to what was actually implemented in hardware in

Re: [Intel-gfx] [PATCH] drm/i915/sysfs: convert snprintf to sysfs_emit

On Sun, 04 Apr 2021, Carlis wrote: > From: Xuezhi Zhang > > Fix the following coccicheck warning: > drivers/gpu/drm/i915//i915_sysfs.c:266:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/i915//i915_sysfs.c:285:8-16: > WARNING: use scnprintf or sprintf > drivers/gpu/drm/i915//i915_sy

[Intel-gfx] ✗ Fi.CI.DOCS: warning for pwm: Rename pwm_get_state() to better reflect its semantic

== Series Details == Series: pwm: Rename pwm_get_state() to better reflect its semantic URL : https://patchwork.freedesktop.org/series/88759/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning: Function paramet

[Intel-gfx] ✓ Fi.CI.BAT: success for pwm: Rename pwm_get_state() to better reflect its semantic

== Series Details == Series: pwm: Rename pwm_get_state() to better reflect its semantic URL : https://patchwork.freedesktop.org/series/88759/ State : success == Summary == CI Bug Log - changes from CI_DRM_9928 -> Patchwork_19895 Summary ---

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/hdcp: Fix uninitialized symbol 'msg_end'

== Series Details == Series: drm/i915/hdcp: Fix uninitialized symbol 'msg_end' URL : https://patchwork.freedesktop.org/series/88756/ State : success == Summary == CI Bug Log - changes from CI_DRM_9928_full -> Patchwork_19894_full Summary --

[Intel-gfx] [PULL] drm-intel-gt-next

Hi Dave & Daniel, Bit late PR due to Easter break. Prep work for local memory support as requested. Hard hang fix for Sandybridge. Sanitize dma-buf size on import and avoid GPU reset if heartbeat callback runs before timeout. The rest is mostly small fixes and code/checkpatch cleanups. Regards

Re: [Intel-gfx] [PATCH 1/2] drm/i915/display/vlv_dsi: Do not skip panel_pwr_cycle_delay when disabling the panel

Hi, On 3/25/21 12:48 PM, Hans de Goede wrote: > After the recently added commit fe0f1e3bfdfe ("drm/i915: Shut down > displays gracefully on reboot"), the DSI panel on a Cherry Trail based > Predia Basic tablet would no longer properly light up after reboot. > > I've managed to reproduce this with

[Intel-gfx] ✓ Fi.CI.IGT: success for pwm: Rename pwm_get_state() to better reflect its semantic

== Series Details == Series: pwm: Rename pwm_get_state() to better reflect its semantic URL : https://patchwork.freedesktop.org/series/88759/ State : success == Summary == CI Bug Log - changes from CI_DRM_9928_full -> Patchwork_19895_full S

Re: [Intel-gfx] [PATCH] drm/i915/dpcd_bl: Don't try vesa interface unless specified by VBT

On Tue, 23 Mar 2021, Lyude Paul wrote: > On Tue, 2021-03-23 at 16:06 +0200, Jani Nikula wrote: >> On Thu, 18 Mar 2021, Lyude Paul wrote: >> > Actually-NAK this. I just realized I've been misreading the bug and that >> > this >> > doesn't actually seem to be fixed. Will resend once I figure out wh

Re: [Intel-gfx] [PATCH v5] vfio/pci: Add support for opregion v2.1+

On Fri, 26 Mar 2021 01:09:53 +0800 Fred Gao wrote: > Before opregion version 2.0 VBT data is stored in opregion mailbox #4, > but when VBT data exceeds 6KB size and cannot be within mailbox #4 > then from opregion v2.0+, Extended VBT region, next to opregion is > used to hold the VBT data, so the

Re: [Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic

Hello Thierry, On Tue, Apr 06, 2021 at 01:16:31PM +0200, Thierry Reding wrote: > On Tue, Apr 06, 2021 at 09:30:36AM +0200, Uwe Kleine-König wrote: > > Given that lowlevel drivers usually cannot implement exactly what a > > consumer requests with pwm_apply_state() there is some rounding involved. >

Re: [Intel-gfx] [PATCH 18/18] vfio/mdev: Correct the function signatures for the mdev_type_attributes

On Tue, Mar 23, 2021 at 08:31:03PM +0100, Christoph Hellwig wrote: > > - type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(kobj)); > > + type = intel_gvt_find_vgpu_type(gvt, mtype_get_type_group_id(mtype)); > > Somewhere in this series you should probably switch > intel_gvt_find_vg

[Intel-gfx] [PATCH v2 00/18] Make vfio_mdev type safe

vfio_mdev has a number of different objects: mdev_parent, mdev_type and mdev_device. Unfortunately the types of these have been erased in various places throughout the API, and this makes it very hard to understand this code or maintain it by the time it reaches all of the drivers. This series pu

[Intel-gfx] [PATCH v2 16/18] vfio/gvt: Use mdev_get_type_group_id()

intel_gvt_init_vgpu_type_groups() makes gvt->types 1:1 with the supported_type_groups array, so the type_group_id is also the index into gvt->types. Use it directly and remove the string matching. Reviewed-by: Kevin Tian Reviewed-by: Christoph Hellwig Signed-off-by: Jason Gunthorpe --- drivers

[Intel-gfx] [PATCH v2 18/18] vfio/mdev: Correct the function signatures for the mdev_type_attributes

The driver core standard is to pass in the properly typed object, the properly typed attribute and the buffer data. It stems from the root kobject method: ssize_t (*show)(struct kobject *kobj, struct kobj_attribute *attr,..) Each subclass of kobject should provide their own function with the sa

[Intel-gfx] [PATCH v2 15/18] vfio/gvt: Make DRM_I915_GVT depend on VFIO_MDEV

At some point there may have been some reason for this weird split in this driver, but today only the VFIO side is actually implemented. However, it got messed up at some point and mdev code was put in gvt.c and is pretending to be "generic" by masquerading as some generic attribute list: stat

Re: [Intel-gfx] [PATCH] pwm: Rename pwm_get_state() to better reflect its semantic

On Tue, 06 Apr 2021, Uwe Kleine-König wrote: > Given that lowlevel drivers usually cannot implement exactly what a > consumer requests with pwm_apply_state() there is some > rounding involved. > > pwm_get_state() traditionally returned the setting that was requested > most recently by the consu

[Intel-gfx] [PATCH 1/2] ACPI: utils: Add acpi_reduced_hardware() helper

Add a getter for the acpi_gbl_reduced_hardware variable so that modules can check if they are running on an ACPI reduced-hw platform or not. Signed-off-by: Hans de Goede --- drivers/acpi/utils.c| 11 +++ include/acpi/acpi_bus.h | 1 + include/linux/acpi.h| 5 + 3 files chan

[Intel-gfx] [PATCH 2/2] ACPI: video: Check LCD flag on ACPI-reduced-hardware devices

Starting with Windows 8, Windows no longer uses the ACPI-video interface for backlight control by default. Instead backlight control is left up to the GPU drivers and these are typically directly accessing the GPU for this instead of going through ACPI. This means that the ACPI video interface is

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper

== Series Details == Series: series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper URL : https://patchwork.freedesktop.org/series/88779/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked se

[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper

== Series Details == Series: series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper URL : https://patchwork.freedesktop.org/series/88779/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/gem/i915_gem_shrinker.c:102: warning:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper

== Series Details == Series: series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper URL : https://patchwork.freedesktop.org/series/88779/ State : success == Summary == CI Bug Log - changes from CI_DRM_9930 -> Patchwork_19896

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper

== Series Details == Series: series starting with [1/2] ACPI: utils: Add acpi_reduced_hardware() helper URL : https://patchwork.freedesktop.org/series/88779/ State : failure == Summary == CI Bug Log - changes from CI_DRM_9930_full -> Patchwork_19896_full ==

Re: [Intel-gfx] [PATCH] drm/i915: Add Wa_14010733141

On 4/1/2021 9:28 AM, Aditya Swarup wrote: The WA requires the following procedure for VDBox SFC reset: If (MFX-SFC usage is 1) { 1.Issue a MFX-SFC forced lock 2.Wait for MFX-SFC forced lock ack 3.Check the MFX-SFC usage bit If (MFX-SFC usage bit is 1)