Re: [Intel-gfx] [PATCH 1/2] drm/i915/mtl: Added restriction for plane downscaling

On Mon, 2022-08-29 at 02:48 +, Murthy, Arun R wrote: > > -Original Message- > > From: Intel-gfx On Behalf > > Of > > Animesh Manna > > Sent: Friday, August 26, 2022 5:48 PM > > To: intel-gfx@lists.freedesktop.org > > Subject: [Intel-gfx] [PATCH 1/2] drm/i915/mtl: Added restriction > >

Re: [Intel-gfx] [PATCH 03/11] drm/edid: s/monitor_rage/vrr_range/

On Sat, 27 Aug 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Rename info->monitor_range to info->vrr_range to actually > reflect its usage. > > Cc: Manasi Navare > Cc: Nicholas Kazlauskas > Cc: Harry Wentland > Cc: Leo Li > Cc: Rodrigo Siqueira > Cc: amd-...@lists.freedesktop.org > Si

Re: [Intel-gfx] [PATCH 04/11] drm/edid: Define more flags

On Sat, 27 Aug 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Replace a bunch of hex constants with proper definitions. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/drm_edid.c | 18 +- > include/drm/drm_edid.h | 14 +-

Re: [Intel-gfx] [PATCH 06/11] drm/edid: Extract drm_gtf2_mode()

On Sat, 27 Aug 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Extract the GTF vs. GTF2 logic into a separate function. > We'll have a second user soon. > > Signed-off-by: Ville Syrjälä Reviewed-by: Jani Nikula > --- > drivers/gpu/drm/drm_edid.c | 47

Re: [Intel-gfx] [PATCH 11/11] drm/i915: Infer vrefresh range for eDP if the EDID omits it

On Sat, 27 Aug 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > A bunch of machines seem to have eDP panels where the EDID > indicates continuous frequency support but fails to actually > include the range descirptor. This violates the EDID 1.4 > spec, but looks like the Windows driver just h

Re: [Intel-gfx] [PATCH 05/11] drm/edid: Only parse VRR range for continuous frequency displays

On Sat, 27 Aug 2022, Ville Syrjala wrote: > From: Ville Syrjälä > > Since we only use the parsed vrefresh range to determine > if VRR should be supported we should only accept continuous > frequency displays here. > > Cc: Manasi Navare > Cc: Nicholas Kazlauskas > Cc: Harry Wentland > Cc: Leo L

[Intel-gfx] [PATCH 0/4] Add DP MST DSC support to i915

Currently we have only DSC support for DP SST. Stanislav Lisovskiy (4): drm: Add missing DP DSC extended capability definitions. drm/i915: Fix intel_dp_mst_compute_link_config drm/i915: Add DSC support to MST path drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate functi

[Intel-gfx] [PATCH 1/4] drm: Add missing DP DSC extended capability definitions.

Adding DP DSC register definitions, we might need for further DSC implementation, supporting MST and DP branch pass-through mode. v2: - Fixed checkpatch comment warning v3: - Removed function which is not yet used(Jani Nikula) Reviewed-by: Vinod Govindapillai Signed-off-by: Stanislav Lisovskiy

[Intel-gfx] [PATCH 3/4] drm/i915: Add DSC support to MST path

Whenever we are not able to get enough timeslots for required PBN, let's try to allocate those using DSC, just same way as we do for SST. v2: Removed intel_dp_mst_dsc_compute_config and refactored intel_dp_dsc_compute_config to support timeslots as a parameter(Ville Syrjälä) v3: - Rebased

[Intel-gfx] [PATCH 2/4] drm/i915: Fix intel_dp_mst_compute_link_config

We currently always exit that bpp loop because drm_dp_atomic_find_vcpi_slots doesn't care if we actually can fit those or not. I think that wasn't the initial intention here, especially when we keep trying with lower bpps, we are supposed to keep trying until we actually find some _working_ configu

[Intel-gfx] [PATCH 4/4] drm/i915: Extract drm_dp_atomic_find_vcpi_slots cycle to separate function

We are using almost same code to loop through bpps while calling drm_dp_atomic_find_vcpi_slots - lets remove this duplication by introducing a new function intel_dp_mst_find_vcpi_slots_for_bpp Signed-off-by: Stanislav Lisovskiy --- drivers/gpu/drm/i915/display/intel_dp_mst.c | 88 +++

Re: [Intel-gfx] [PATCH 1/1] drm/i915/dgfx: Release mmap on rpm suspend

> -Original Message- > From: Auld, Matthew Thanks Matt for reviewing this. > Sent: Friday, August 26, 2022 11:09 PM > To: Gupta, Anshuman ; intel- > g...@lists.freedesktop.org > Cc: joonas.lahti...@linux.intel.com; Vivi, Rodrigo ; > Nilawar, Badal ; ch...@chris-wilson.co.uk > Subject: Re

Re: [Intel-gfx] [PATCH v5 17/31] ACPI: video: Add Nvidia WMI EC brightness control detection (v3)

Hi, On 8/26/22 00:21, Daniel Dadap wrote: > On 8/25/22 9:37 AM, Hans de Goede wrote: >> On some new laptop designs a new Nvidia specific WMI interface is present >> which gives info about panel brightness control and may allow controlling >> the brightness through this interface when the embedded

[Intel-gfx] [PATCH v2 11/11] drm/i915: Infer vrefresh range for eDP if the EDID omits it

From: Ville Syrjälä A bunch of machines seem to have eDP panels where the EDID indicates continuous frequency support but fails to actually include the range descirptor. This violates the EDID 1.4 spec, but looks like the Windows driver just hacks around this by just assuming that the panel suppo

[Intel-gfx] [PATCH] drm/i915/ttm: Abort suspend on i915_ttm_backup failure

On system suspend when system memory is low then i915_gem_obj_copy_ttm() could fail trying to backup a lmem obj. GEM_WARN_ON() is not enough, suspend shouldn't continue if i915_ttm_backup() throws an error. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6529 Suggested-by: Chris P Wilson

Re: ✓ Fi.CI.BAT: success for drm/i915/guc: Remove log size module parameters (rev2)

Quoting Patchwork (2022-08-26 13:54:30) > Patch Details > > Series: drm/i915/guc: Remove log size module parameters (rev2) > URL: https://patchwork.freedesktop.org/series/107780/ > State: success > Details: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107780v2/index.html > > CI Bu

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 20:45, Christian König wrote: > Am 24.08.22 um 17:49 schrieb Dmitry Osipenko: >> On 8/24/22 18:24, Christian König wrote: >>> Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: Move dma-buf attachment API functions to the dynamic locking specification. The strict locking conven

[Intel-gfx] SPENDE

Beste begunstigde, Je hebt een liefdadigheidsdonatie van ($ 10.000.000,00) van Mr. Mike Weirsky, een winnaar van een powerball-jackpotloterij van $ 273 miljoen. Ik doneer aan 5 willekeurige personen als je deze e-mail ontvangt, dan is je e-mail geselecteerd na een spin-ball. Ik heb vrijwillig be

[Intel-gfx] [PATCH] i915/gvt: fix repeated words in comments

Delete the redundant word 'the'. Signed-off-by: wangjianli --- drivers/gpu/drm/i915/gvt/gtt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gvt/gtt.c b/drivers/gpu/drm/i915/gvt/gtt.c index b4f69364f9a1..62e5f27adca9 100644 --- a/drivers/gpu/drm/i915/gv

Re: [Intel-gfx] [PATCH v1] drm/i915: fix null pointer dereference

Hi all, Apologies in advance if you see this twice. I did not see the original make it to either lore.kernel.org or the freedesktop.org archives so I figured it might have been sent into the void. On Tue, Feb 01, 2022 at 04:33:54PM +0100, Lukasz Bartosik wrote: > From: Łukasz Bartosik > > Asus

Re: [Intel-gfx] [PATCH v1] drm/i915: fix null pointer dereference

Hi all, On Tue, Feb 01, 2022 at 04:33:54PM +0100, Lukasz Bartosik wrote: > From: Łukasz Bartosik > > Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel. > The root cause is null pointer defeference of bi_next > in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c. > > BUG:

[Intel-gfx] [PATCH v3 2/9] dma-buf: Add locked variant of dma_buf_vmap/vunmap()

Add locked variant of dma_buf_vmap/vunmap() that will be utilized by DRM drivers once vmap/unmap functions will be moved to the new locking convention. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 42 +++ include/linux/dma-buf.h | 2 ++ 2

[Intel-gfx] [PATCH v3 5/9] dma-buf: Move dma_buf_mmap_unlocked() to dynamic locking specification

Move dma_buf_mmap_unlocked() function to the dynamic locking specification by taking the reservation lock. Neither of the today's drivers take the reservation lock within the mmap() callback, hence it's safe to enforce the locking. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 8

[Intel-gfx] SPENDE

Beste begunstigde, Je hebt een liefdadigheidsdonatie van ($ 10.000.000,00) van Mr. Mike Weirsky, een winnaar van een powerball-jackpotloterij van $ 273 miljoen. Ik doneer aan 5 willekeurige personen als je deze e-mail ontvangt, dan is je e-mail geselecteerd na een spin-ball. Ik heb vrijwillig be

[Intel-gfx] [PATCH v3 9/9] dma-buf: Remove internal lock

The internal dma-buf lock isn't needed anymore because the updated locking specification claims that dma-buf reservation must be locked by importers, and thus, the internal data is already protected by the reservation lock. Remove the obsoleted internal lock. Signed-off-by: Dmitry Osipenko --- d

[Intel-gfx] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

Move dma-buf attachment API functions to the dynamic locking specification. The strict locking convention prevents deadlock situations for dma-buf importers and exporters. Previously, the "unlocked" versions of the attachment API functions weren't taking the reservation lock and this patch makes t

Re: [Intel-gfx] [PATCH] gpu: move from strlcpy with unused retval to strscpy

Dne četrtek, 18. avgust 2022 ob 23:00:07 CEST je Wolfram Sang napisal(a): > Follow the advice of the below link and prefer 'strscpy' in this > subsystem. Conversion is 1:1 because the return value is not used. > Generated by a coccinelle script. > > Link: > https://lore.kernel.org/r/CAHk-=wgfRnXz0

[Intel-gfx] [PATCH v3 0/9] Move all drivers to a common dma-buf locking convention

Hello, This series moves all drivers to a dynamic dma-buf locking specification. >From now on all dma-buf importers are made responsible for holding dma-buf's reservation lock around all operations performed over dma-bufs in accordance to the locking specification. This allows us to utilize reserv

[Intel-gfx] [PATCH] drm/i915: fix repeated words in comments

Delete the redundant word 'for'. Delete the redundant word 'the'. Delete the redundant word 'into'. Signed-off-by: Jilin Yuan --- drivers/gpu/drm/i915/i915_reg.h | 2 +- drivers/gpu/drm/i915/i915_request.c | 2 +- drivers/gpu/drm/i915/intel_device_info.h | 2 +- 3 files changed,

[Intel-gfx] [PATCH v3 4/9] dma-buf: Move dma_buf_vmap/vunmap_unlocked() to dynamic locking specification

Move dma_buf_vmap/vunmap_unlocked() functions to the dynamic locking specification by taking the reservation lock. All the affected drivers were prepared to this change by a previous drm/gem patch. Signed-off-by: Dmitry Osipenko --- drivers/dma-buf/dma-buf.c | 8 drivers/gpu/drm/drm_p

Re: [Intel-gfx] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 17:08, Christian König wrote: > Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: >> Move dma-buf attachment API functions to the dynamic locking >> specification. >> The strict locking convention prevents deadlock situations for dma-buf >> importers and exporters. >> >> Previously, the "unl

Re: [Intel-gfx] [PATCH v1] drm/i915: fix null pointer dereference

On Thu, Aug 25, 2022 at 10:37:14AM +0300, Jani Nikula wrote: > On Tue, 23 Aug 2022, Łukasz Bartosik wrote: > >> > >> Hi all, > >> > >> Apologies in advance if you see this twice. I did not see the original > >> make it to either lore.kernel.org or the freedesktop.org archives so I > >> figured it

Re: [Intel-gfx] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 18:14, Christian König wrote: > Am 24.08.22 um 17:03 schrieb Dmitry Osipenko: >> On 8/24/22 17:08, Christian König wrote: >>> Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: Move dma-buf attachment API functions to the dynamic locking specification. The strict locking conven

[Intel-gfx] [PATCH] drm/i915: fix repeated words in comments

Delete the redundant word 'other'. Delete the redundant word 'the'. Delete the redundant word 'will'. Signed-off-by: Jilin Yuan --- drivers/gpu/drm/i915/i915_gem_evict.c | 2 +- drivers/gpu/drm/i915/i915_irq.c | 4 ++-- drivers/gpu/drm/i915/i915_memcpy.h| 2 +- 3 files changed, 4 in

[Intel-gfx] SPENDE

Beste begunstigde, Je hebt een liefdadigheidsdonatie van ($ 10.000.000,00) van Mr. Mike Weirsky, een winnaar van een powerball-jackpotloterij van $ 273 miljoen. Ik doneer aan 5 willekeurige personen als je deze e-mail ontvangt, dan is je e-mail geselecteerd na een spin-ball. Ik heb vrijwillig be

[Intel-gfx] SPENDE

Beste begunstigde, Je hebt een liefdadigheidsdonatie van ($ 10.000.000,00) van Mr. Mike Weirsky, een winnaar van een powerball-jackpotloterij van $ 273 miljoen. Ik doneer aan 5 willekeurige personen als je deze e-mail ontvangt, dan is je e-mail geselecteerd na een spin-ball. Ik heb vrijwillig be

[Intel-gfx] [PATCH v3 8/9] media: videobuf2: Stop using internal dma-buf lock

All drivers that use dma-bufs have been moved to the updated locking specification and now dma-buf reservation is guaranteed to be locked by importers during the mapping operations. There is no need to take the internal dma-buf lock anymore. Remove locking from the videobuf2 memory allocators. Ack

[Intel-gfx] [PATCH] i915/display: fix repeated words in comments

Delete the redundant word 'the'. Signed-off-by: wangjianli --- drivers/gpu/drm/i915/display/intel_crt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_crt.c b/drivers/gpu/drm/i915/display/intel_crt.c index 6a3893c8ff22..fead011c87b5 10064

[Intel-gfx] SPENDE

Beste begunstigde, Je hebt een liefdadigheidsdonatie van ($ 10.000.000,00) van Mr. Mike Weirsky, een winnaar van een powerball-jackpotloterij van $ 273 miljoen. Ik doneer aan 5 willekeurige personen als je deze e-mail ontvangt, dan is je e-mail geselecteerd na een spin-ball. Ik heb vrijwillig be

[Intel-gfx] [PATCH] drm/i915: fix repeated words in comments

Delete the redundant word 'the'. Signed-off-by: wangjianli --- drivers/gpu/drm/i915/i915_irq.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 73cebc6aa650..783a6ca41a61 100644 --- a/drivers/gpu/drm/i915

[Intel-gfx] [PATCH v3 3/9] drm/gem: Take reservation lock for vmap/vunmap operations

The new common dma-buf locking convention will require buffer importers to hold the reservation lock around mapping operations. Make DRM GEM core to take the lock around the vmapping operations and update DRM drivers to use the locked functions for the case where DRM core now holds the lock. This p

[Intel-gfx] [PATCH v3 7/9] dma-buf: Document dynamic locking convention

Add documentation for the dynamic locking convention. The documentation tells dma-buf API users when they should take the reservation lock and when not. Signed-off-by: Dmitry Osipenko --- Documentation/driver-api/dma-buf.rst | 6 +++ drivers/dma-buf/dma-buf.c| 63 +++

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH v3 6/9] dma-buf: Move dma-buf attachment to dynamic locking specification

On 8/24/22 18:24, Christian König wrote: > Am 24.08.22 um 12:22 schrieb Dmitry Osipenko: >> Move dma-buf attachment API functions to the dynamic locking >> specification. >> The strict locking convention prevents deadlock situations for dma-buf >> importers and exporters. >> >> Previously, the "unl

[Intel-gfx] [PATCH v3 1/9] dma-buf: Add _unlocked postfix to function names

Add _unlocked postfix to the dma-buf API function names in a preparation to move all non-dynamic dma-buf users over to the dynamic locking specification. This patch only renames API functions, preparing drivers to the common locking convention. Later on, we will make the "unlocked" functions to tak

[Intel-gfx] [PATCH v3 00/18] drm/i915: add display sub-struct to drm_i915_private

v3 of https://patchwork.freedesktop.org/series/107170/ Dropped already merged patches, rebased the rest. Jani Nikula (18): drm/i915: move and group hdcp under display.hdcp drm/i915: move and group max_bw and bw_obj under display.bw drm/i915: move opregion to display.opregion drm/i915: mov

[Intel-gfx] [PATCH v3 02/18] drm/i915: move and group max_bw and bw_obj under display.bw

Move display bandwidth related members under drm_i915_private display sub-struct. v2: Rebase Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_bw.c | 42 +-- .../gpu/drm/i915/display/intel_display_core.h | 21 ++ .../dr

[Intel-gfx] [PATCH v3 01/18] drm/i915: move and group hdcp under display.hdcp

Move display hdcp related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi Reviewed-by: Arun R Murthy --- .../gpu/drm/i915/display/intel_display_core.h | 9 ++ drivers/gpu/drm/i915/display/intel_hdcp.c | 134 +- dr

[Intel-gfx] [PATCH v3 04/18] drm/i915: move and group cdclk under display.cdclk

Move display cdclk related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/hsw_ips.c| 2 +- drivers/gpu/drm/i915/display/intel_audio.c| 6 +- .../gpu/drm/i915/display/intel_backlight.c

[Intel-gfx] [PATCH v3 03/18] drm/i915: move opregion to display.opregion

Move display opregion related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_bios.c | 4 +- .../gpu/drm/i915/display/intel_display_core.h | 2 + .../drm/i915/display/intel_display_debugfs.c

[Intel-gfx] [PATCH v3 05/18] drm/i915: move backlight to display.backlight

Move display backlight related members under drm_i915_private display sub-struct. Prefer adding anonymous sub-structs even for single members that aren't our own structs. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- .../gpu/drm/i915/display/intel_backlight.c| 28 +---

[Intel-gfx] [PATCH v3 06/18] drm/i915: move mipi_mmio_base to display.dsi

Move display DSI related members under drm_i915_private display sub-struct. Prefer adding anonymous sub-structs even for single members that aren't our own structs. Abstract mmio base member access in register definitions in a macro. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi ---

[Intel-gfx] [PATCH v3 07/18] drm/i915: move vbt to display.vbt

Move display VBT related members under drm_i915_private display sub-struct. v2: Rebase Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_bios.c | 212 +- drivers/gpu/drm/i915/display/intel_crt.c | 4 +- drivers/gpu/drm/i91

[Intel-gfx] [PATCH v3 08/18] drm/i915: move fbc to display.fbc

Move display FBC related members under drm_i915_private display sub-struct. Pointers and arrays of pointers to structs that we defined are fine without a sub-struct wrapping. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/i9xx_plane.c | 2 +-

[Intel-gfx] [PATCH v3 09/18] drm/i915: move and group power related members under display.power

Move display power related members under drm_i915_private display sub-struct. Arguably chv_phy_control and chv_phy_assert could be placed in a phy substruct, but they are only used in the power code. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- .../gpu/drm/i915/display/intel_dis

[Intel-gfx] [PATCH v3 11/18] drm/i915: move fb_tracking under display sub-struct

Move display frontbuffer tracking related members under drm_i915_private display sub-struct. Rename struct i915_frontbuffer_tracking to intel_frontbuffer_tracking while at it. FIXME: fb_tracking.lock mutex init should be moved away from i915_gem_init_early(). Signed-off-by: Jani Nikula Reviewed

[Intel-gfx] [PATCH v3 12/18] drm/i915: move dbuf under display sub-struct

Move display dbuf related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_display_core.h | 7 +++ drivers/gpu/drm/i915/display/intel_display_power.c | 6 +++--- .../drm/i915/display/intel_di

[Intel-gfx] [PATCH v3 14/18] drm/i915/quirks: abstract checking for display quirks

Add intel_has_quirk() for checking if a display quirk is present. Avoid accessing i915->quirks all over the place. v2: Rebase Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_backlight.c | 9 + drivers/gpu/drm/i915/display/intel_ddi.c

[Intel-gfx] [PATCH v3 10/18] drm/i915: move and group fdi members under display.fdi

Move display fdi related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_crt.c | 4 ++-- drivers/gpu/drm/i915/display/intel_display_core.h | 5 + drivers/gpu/drm/i915/display/intel_f

[Intel-gfx] [PATCH v3 13/18] drm/i915: move and group modeset_wq and flip_wq under display.wq

Move display workqueue related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_display.c | 20 +-- .../gpu/drm/i915/display/intel_display_core.h | 8 drivers/gpu/drm/i915

[Intel-gfx] [PATCH v3 15/18] drm/i915/quirks: abstract quirks further by making quirk ids an enum

Turn the quirk ids to enums instead of bits, and hide the masking inside intel_quirks.c. Define the enums in intel_quirks.h to declutter i915_drv.h while at it. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_quirks.c | 21 + dr

[Intel-gfx] [PATCH v3 16/18] drm/i915: move quirks under display sub-struct

Move display quirk related members under drm_i915_private display sub-struct. Prefer adding anonymous sub-structs even for single members that aren't our own structs. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_display_core.h | 4 drivers

[Intel-gfx] [PATCH v3 17/18] drm/i915: move atomic_helper under display sub-struct

Move display atomic helper related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_display.c | 14 +++--- drivers/gpu/drm/i915/display/intel_display_core.h | 6 ++ drivers/gpu/drm

[Intel-gfx] [PATCH v3 18/18] drm/i915: move and group properties under display.properties

Move display property related members under drm_i915_private display sub-struct. Signed-off-by: Jani Nikula Reviewed-by: Lucas De Marchi --- drivers/gpu/drm/i915/display/intel_atomic.c | 8 drivers/gpu/drm/i915/display/intel_connector.c| 8 drivers/gpu/drm/i915/displ

[Intel-gfx] [PATCH v2 00/41] drm: Analog TV Improvements

Hi, Here's a series aiming at improving the command line named modes support, and more importantly how we deal with all the analog TV variants. The named modes support were initially introduced to allow to specify the analog TV mode to be used. However, this was causing multiple issues: * The

[Intel-gfx] [PATCH v2 01/41] drm/tests: Order Kunit tests in Makefile

Since we've recently added a ton of tests, the list starts to be a bit of a mess and creates unneeded conflicts. Let's order it alphabetically. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/tests/Makefile b/drivers/gpu/drm/tests/Makefile index 91b70f7d2769..2d9f49b62ecb 100644 --- a

[Intel-gfx] [PATCH v2 14/41] drm/modes: Move named modes parsing to a separate function

The current construction of the named mode parsing doesn't allow to extend it easily. Let's move it to a separate function so we can add more parameters and modes. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 99a21e5cd00d..0636cb707544

[Intel-gfx] [PATCH v2 09/41] drm/connector: Add TV standard property

The TV mode property has been around for a while now to select and get the current TV mode output on an analog TV connector. Despite that property name being generic, its content isn't and has been driver-specific which makes it hard to build any generic behaviour on top of it, both in kernel and

[Intel-gfx] [PATCH v2 13/41] drm/client: Add some tests for drm_connector_pick_cmdline_mode()

drm_connector_pick_cmdline_mode() is in charge of finding a proper drm_display_mode from the definition we got in the video= command line argument. Let's add some unit tests to make sure we're not getting any regressions there. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/drm_clien

[Intel-gfx] [PATCH v2 12/41] drm/modes: parse_cmdline: Add support for named modes containing dashes

From: Geert Uytterhoeven It is fairly common for named video modes to contain dashes (e.g. "tt-mid" on Atari, "dblntsc-ff" on Amiga). Currently such mode names are not recognized, as the dash is considered to be a separator between mode name and bpp. Fix this by skipping any dashes that are not

[Intel-gfx] [PATCH v2 03/41] drm/atomic-helper: Rename drm_atomic_helper_connector_tv_reset to avoid ambiguity

We currently have two sets of TV properties. The first one is there to deal with analog TV properties, creating properties such as the TV mode, subconnectors, saturation, hue and so on. It's created by calling the drm_mode_create_tv_properties() function. The second one is there to deal with prop

[Intel-gfx] [PATCH v2 08/41] drm/connector: Rename drm_mode_create_tv_properties

drm_mode_create_tv_properties(), among other things, will create the "mode" property that stores the analog TV mode that connector is supposed to output. However, that property is getting deprecated, so let's rename that function to mention it's deprecated. We'll introduce a new variant of that fu

[Intel-gfx] [PATCH v2 06/41] drm/connector: Rename legacy TV property

The current tv_mode has driver-specific values that don't allow to easily share code using it, either at the userspace or kernel level. Since we're going to introduce a new, generic, property that fit the same purpose, let's rename this one to legacy_tv_mode to make it obvious we should move away

[Intel-gfx] [PATCH v2 04/41] drm/connector: Rename subconnector state variable

There is two TV subconnector related properties registered by drm_mode_create_tv_properties(): subconnector and select subconnector. While the select subconnector property is stored in the kernel by the drm_tv_connector_state structure, the subconnector property isn't stored anywhere. Worse, the

[Intel-gfx] [PATCH v2 11/41] drm/modes: Only consider bpp and refresh before options

Some video= options might have a value that contains a dash. However, the command line parsing mode considers all dashes as the separator between the mode and the bpp count. Let's rework the parsing code a bit to only consider a dash as the bpp separator if it before a comma, the options separator

[Intel-gfx] [PATCH v2 02/41] drm/tests: Add Kunit Helpers

As the number of kunit tests in KMS grows further, we start to have multiple test suites that, for example, need to register a mock DRM driver to interact with the KMS function they are supposed to test. Let's add a file meant to provide those kind of helpers to avoid duplication. Signed-off-by:

[Intel-gfx] [PATCH v2 07/41] drm/connector: Only register TV mode property if present

The drm_create_tv_properties() will create the TV mode property unconditionally. However, since we'll gradually phase it out, let's register it only if we have a list passed as an argument. This will make the transition easier. Signed-off-by: Maxime Ripard Acked-by: Noralf Trønnes diff --git a

[Intel-gfx] [PATCH v2 10/41] drm/modes: Add a function to generate analog display modes

Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and 625-lines modes in their drivers. Since those modes are fairly standard, and that we'll need to use them in more places in the future, it makes sense to move their definition into the core framework. However, analog display usual

[Intel-gfx] [PATCH v2 05/41] drm/atomic: Add TV subconnector property to get/set_property

The subconnector property was created by drm_mode_create_tv_properties(), but wasn't exposed to the userspace through the generic atomic_get/set_property implementation, and wasn't stored in any generic state structure. Let's solve this. Signed-off-by: Maxime Ripard Reviewed-by: Noralf Trønnes

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

Hi Dave & Daniel - drm-intel-next-2022-08-29: drm/i915 feature pull for v6.1: Features and functionality: - Early Meteorlake (MTL) enabling (José, Radhakrishna, Clint, Imre, Vandita, Ville, Jani) - Support more HDMI pixel clock frequencies on DG2 (Clint) - Sanity check PCI BARs (Piotr Piórkows

[Intel-gfx] [PATCH v2 21/41] drm/modes: Introduce more named modes

Now that we can easily extend the named modes list, let's add a few more analog TV modes that were used in the wild, and some unit tests to make sure it works as intended. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 065dbfbd815e..7d76

[Intel-gfx] [PATCH v2 31/41] drm/vc4: vec: Use TV Reset implementation

The analog TV properties created by the drm_mode_create_tv_properties() are not properly initialised at reset. Let's switch our implementation to call drm_atomic_helper_connector_tv_reset(). Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c i

[Intel-gfx] [PATCH v2 17/41] drm/connector: Add pixel clock to cmdline mode

We'll need to get the pixel clock to generate proper display modes for all the current named modes. Let's add it to struct drm_cmdline_mode and fill it when parsing the named mode. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index 5e898699b

[Intel-gfx] [PATCH v2 32/41] drm/vc4: vec: Convert to the new TV mode property

Now that the core can deal fine with analog TV modes, let's convert the vc4 VEC driver to leverage those new features. We've added some backward compatibility to support the old TV mode property and translate it into the new TV norm property. Signed-off-by: Maxime Ripard diff --git a/drivers/gp

[Intel-gfx] [PATCH v2 40/41] drm/sun4i: tv: Add missing reset assertion

The reset line is deasserted at bind, and asserted if we ever encounter an error there. However, it's never asserted in unbind which will lead to a resource unbalance. Signed-off-by: Maxime Ripard Reviewed-by: Jernej Skrabec diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/

[Intel-gfx] [PATCH v2 33/41] drm/vc4: vec: Add support for more analog TV standards

From: Mateusz Kwiatkowski Add support for the following composite output modes (all of them are somewhat more obscure than the previously defined ones): - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to 4.43361875 MHz (the PAL subcarrier frequency). Never used for broadcas

[Intel-gfx] [PATCH v2 30/41] drm/vc4: vec: Fix definition of PAL-M mode

From: Mateusz Kwiatkowski PAL-M is a Brazilian analog TV standard that uses a PAL-style chroma subcarrier at 3.575611[888111] MHz on top of 525-line (480i60) timings. This commit makes the driver actually use the proper VEC preset for this mode instead of just changing PAL subcarrier frequency.

[Intel-gfx] [PATCH v2 22/41] drm/atomic-helper: Add a TV properties reset helper

The drm_tv_create_properties() function will create a bunch of properties, but it's up to each and every driver using that function to properly reset the state of these properties leading to inconsistent behaviours. Let's create a helper that will take care of it. Signed-off-by: Maxime Ripard d

[Intel-gfx] [PATCH v2 15/41] drm/modes: Switch to named mode descriptors

The current named mode parsing relies only the mode name, and doesn't allow to specify any other parameter. Let's convert that string list to an array of a custom structure that will hold the name and some additional parameters in the future. Signed-off-by: Maxime Ripard diff --git a/drivers/gp

[Intel-gfx] [PATCH v2 25/41] drm/vc4: vec: Convert to atomic helpers

The VC4 VEC driver still uses legacy enable and disable hook implementation. Let's convert to the atomic variants. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c index d521ffd8d75c..72eee0cbb615 100644 --- a/drivers/gpu/drm/vc4/vc4_vec.c +

[Intel-gfx] [PATCH v2 16/41] drm/modes: Fill drm_cmdline mode from named modes

The current code to deal with named modes will only set the mode name, and then it's up to drivers to try to match that name to whatever mode or configuration they see fit. The plan is to remove that need and move the named mode handling out of drivers and into the core, and only rely on modes and

[Intel-gfx] [PATCH v2 29/41] drm/vc4: vec: Switch for common modes

Now that the core has a definition for the 525 and 625 lines analog TV modes, let's switch to it for vc4. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c index d1d40b69279e..63e4e617e321 100644 --- a/drivers/gpu/drm/vc4/vc4_vec.c +++ b/driv

[Intel-gfx] [PATCH v2 28/41] drm/vc4: vec: Fix timings for VEC modes

From: Mateusz Kwiatkowski This commit fixes vertical timings of the VEC (composite output) modes to accurately represent the 525-line ("NTSC") and 625-line ("PAL") ITU-R standards. Previous timings were actually defined as 502 and 601 lines, resulting in non-standard 62.69 Hz and 52 Hz signals b

[Intel-gfx] [PATCH v2 35/41] drm/sun4i: tv: Convert to atomic hooks

The sun4i TV driver still uses legacy enable and disable hook implementation. Let's convert to the atomic variants. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c index 53152d77c392..f7aad995ab5b 100644 --- a/drivers/gpu/drm/sun4i/su

[Intel-gfx] [PATCH v2 27/41] drm/vc4: vec: Remove redundant atomic_mode_set

From: Mateusz Kwiatkowski Let's remove the superfluous tv_mode field, which was redundant with the mode field in struct drm_tv_connector_state. Signed-off-by: Mateusz Kwiatkowski Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c index 9a37

[Intel-gfx] [PATCH v2 41/41] drm/sun4i: tv: Convert to the new TV mode property

Now that the core can deal fine with analog TV modes, let's convert the sun4i TV driver to leverage those new features. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c index 74ff5ad6a8b9..10c0d727d700 100644 --- a/drivers/gpu/drm/sun4

[Intel-gfx] [PATCH v2 37/41] drm/sun4i: tv: Remove useless function

The drm_connector_to_sun4i_tv() function isn't used anywhere in the driver, so let's remove it. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c index 3944da9a3c34..52bbba8f19dc 100644 --- a/drivers/gpu/drm/sun4i/sun4i_tv.c +++ b/drive

[Intel-gfx] [PATCH v2 39/41] drm/sun4i: tv: Rename error label

The other error labels in sun4i_tv_bind() are named after the task they perform (err_disable_clk to call clk_disable_unprepare for example). However, the err_cleanup_connector is named after the calling site (drm_connector_init failing) and will actually cleanup the encoder. Let's rename it to err

[Intel-gfx] [PATCH v2 24/41] drm/vc4: vec: Remove empty mode_fixup

The mode_fixup hooks are deprecated, and the behaviour we implement is the default one anyway. Let's remove it. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/vc4/vc4_vec.c b/drivers/gpu/drm/vc4/vc4_vec.c index d5140fe0be4f..d521ffd8d75c 100644 --- a/drivers/gpu/drm/vc4/vc4_vec.c +++

[Intel-gfx] [PATCH v2 36/41] drm/sun4i: tv: Merge mode_set into atomic_enable

Our mode_set implementation can be merged into our atomic_enable implementation to simplify things, so let's do this. Signed-off-by: Maxime Ripard diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c index f7aad995ab5b..3944da9a3c34 100644 --- a/drivers/gpu/drm/sun4i/

[Intel-gfx] [PATCH v2 19/41] drm/modes: Introduce the tv_mode property as a command-line option

Our new tv mode option allows to specify the TV mode from a property. However, it can still be useful, for example to avoid any boot time artifact, to set that property directly from the kernel command line. Let's add some code to allow it, and some unit tests to exercise that code. Signed-off-by

  1   2   >