m next-20220620 for today.
--
Cheers,
Stephen Rothwell
pgpONB8A38WPS.pgp
Description: OpenPGP digital signature
== Series Details ==
Series: drm/i915: ttm for stolen (rev3)
URL : https://patchwork.freedesktop.org/series/101396/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11786 -> Patchwork_101396v3
Summary
---
**FAILURE**
== Series Details ==
Series: drm/i915: ttm for stolen (rev3)
URL : https://patchwork.freedesktop.org/series/101396/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: Add HWMON support (rev2)
URL : https://patchwork.freedesktop.org/series/104278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11786 -> Patchwork_104278v2
Summary
---
== Series Details ==
Series: drm/i915: Add HWMON support (rev2)
URL : https://patchwork.freedesktop.org/series/104278/
State : warning
== Summary ==
Error: dim checkpatch failed
b435e8c95f2c drm/i915/hwmon: Add HWMON infrastructure patch
Traceback (most recent call last):
File
== Series Details ==
Series: series starting with [1/2] drm/i915/fbc: Move flip_pending assignmnt
URL : https://patchwork.freedesktop.org/series/105383/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11786 -> Patchwork_105383v1
== Series Details ==
Series: drm/i915: move display feature check macros out of i915_drv.h
URL : https://patchwork.freedesktop.org/series/105381/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11786 -> Patchwork_105381v1
== Series Details ==
Series: drm/i915: move display feature check macros out of i915_drv.h
URL : https://patchwork.freedesktop.org/series/105381/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: move display feature check macros out of i915_drv.h
URL : https://patchwork.freedesktop.org/series/105381/
State : warning
== Summary ==
Error: dim checkpatch failed
15d736930b6b drm/i915/display: spread out HAS_*() feature macros
-:47:
== Series Details ==
Series: drm/i915: Make fastset not suck and allow seamless M/N changes (rev6)
URL : https://patchwork.freedesktop.org/series/103491/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11785 -> Patchwork_103491v6
== Series Details ==
Series: drm/i915: Make fastset not suck and allow seamless M/N changes (rev6)
URL : https://patchwork.freedesktop.org/series/103491/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915: Make fastset not suck and allow seamless M/N changes (rev6)
URL : https://patchwork.freedesktop.org/series/103491/
State : warning
== Summary ==
Error: dim checkpatch failed
0cf5770ce11c drm/i915: Relocate intel_crtc_dotclock()
8e214039c42f drm/i915:
== Series Details ==
Series: drm/i915: Fix vm use-after-free in vma destruction (rev2)
URL : https://patchwork.freedesktop.org/series/103922/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11780_full -> Patchwork_103922v2_full
refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/display/intel_fbc.c | 78 ++--
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 -
During testing make can_mmap consider whether the region is private.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
add callbacks for alloc and free.
this allows region creators to allocate any extra storage they may
require.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_memory_region.c | 16 +---
drivers/gpu/drm/i915/intel_memory_region.h | 2 ++
2 files changed, 15
By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.
ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.
The desired behaviour is to clear user allocated buffers and any kernel
buffers that
For situations where allocations need to fail on alloc instead of
delayed get_pages, add a new alloc flag to pin the ttm bo.
This makes sure that the resource has been allocated during buffer
creation, allowing it to fail with an error if the placement is
exhausted.
This allows existing fallback
prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.
Signed-off-by: Robert Beckett
Reviewed-by: Thomas Hellström
---
drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 ++--
drivers/gpu/drm/i915/intel_region_ttm.c | 31
Stolen regions are not page backed or considered iomem.
Prevent flags indicating such.
This correctly prevents stolen buffers from attempting to directly map
them.
See i915_gem_object_has_struct_page() and i915_gem_object_has_iomem()
usage for where it would break otherwise.
Signed-off-by:
i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.
Signed-off-by: Robert Beckett
---
drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.
TTM movement code came along and decided that it could make that
decision at that time, which is usually well
This series refactors i915's stolen memory region to use ttm.
v2: handle disabled stolen similar to legacy version.
relying on ttm to fail allocs works fine, but is dmesg noisy and causes
testing
dmesg warning regressions.
v3: rebase to latest drm-tip.
fix v2
On 6/20/22 13:46, Badal Nilawar wrote:
From: Riana Tauro
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display current voltage
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
Cc: Anshuman Gupta
On 6/20/22 13:46, Badal Nilawar wrote:
From: Dale B Stimson
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display energy utilization
v2:
- Updated the date and kernel version in feature description
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh
== Series Details ==
Series: drm/i915/dsi: add payload receiving code (rev5)
URL : https://patchwork.freedesktop.org/series/105096/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11780_full -> Patchwork_105096v5_full
On 6/20/22 13:46, Badal Nilawar wrote:
From: Dale B Stimson
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on
From: Dale B Stimson
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display energy utilization
v2:
- Updated the date and kernel version in feature description
Signed-off-by: Dale B Stimson
Signed-off-by: Ashutosh Dixit
Signed-off-by: Riana Tauro
From: Dale B Stimson
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display power utilization.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
From: Riana Tauro
As part of the System Managemenent Interface (SMI), use the HWMON
subsystem to display current voltage
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
Cc: Anshuman Gupta
Signed-off-by: Riana Tauro
Signed-off-by: Badal
From: Dale B Stimson
As part of the System Managemenent Interface (SMI), HWMON
subsystem can be used to get the raw sensor data.
This patch sets up HWMON infrastructure
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments (Jani)
- Remove "select HWMON" from i915/Kconfig
v2:
- Reorganized series. Created first patch as infrastructure patch
followed by feature patches. (Ashutosh)
- Fixed review comments (Jani)
- Fixed review comments (Ashutosh)
Dale B Stimson (3):
drm/i915/hwmon: Add HWMON infrastructure patch
drm/i915/hwmon: Add HWMON power sensor
From: Ville Syrjälä
Replace the mutex_is_locked() stuff with lockdep_assert_held() since
that's what it's there for.
Asoo sprinkle these around so that we have more or less
mirrored coverate for the enable vs. disable instead of the
current situation where the asserts seem to be more or less
From: Ville Syrjälä
Move the flip_pending assignment into __intel_fbc_post_update()
from intel_fbc_post_update(). Now mirrors the pre_update() side.
The only reason the assignment was in the higher level function
is that we used to call __intel_fbc_post_update() from elsewhere
as well. That got
On Mon, 20 Jun 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have a couple of places that want to make distinction between
> double buffered M/N registers vs. the split M1/N1+M2/N2 registers.
> Add a helper for that.
>
> v2: Turn into a HAS_ macro (Jani)
>
> Reviewed-by: Jani Nikula
Group widely used display feature check macros together in one place.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_features.h | 37 +++
.../i915/display/intel_display_power_map.c| 5 +--
.../drm/i915/display/intel_display_types.h| 1 +
Expand single-use display feature macros around device info flags
in-place, and remove the macros.
Move display feature macros used in one file only into that file.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_bios.c| 2 ++
drivers/gpu/drm/i915/display/intel_cdclk.c
Started pondering about this based on [1]. Spread out single-use and
single-file-use HAS_*() macros, and move display macros to
display/intel_display_features.h.
Food for thought at least. Doesn't look too bad tbh.
BR,
Jani.
[1] https://lore.kernel.org/r/yrcoxugseuzl+...@intel.com
Jani Nikula
From: Ville Syrjälä
Extract the state->freq computation for VLV/BXT DSI PLL
into small helpers. We want to use these during the state
computation as well.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/vlv_dsi_pll.c | 121 -
1 file changed, 68 insertions(+),
From: Ville Syrjälä
Do the DPLL computation before fastset checks. This should
allow us to get rid of all that horrible fuzzy clock handling
for fastsets. Who knows how many bugs there are caused by our
state not actually matching what the hardware will generate.
Reviewed-by: Jani Nikula
From: Ville Syrjälä
Fill port_clock and hw.adjusted_mode.crtc_clock with the actual
frequency we're going to be getting from the hardware. This will
let us accurately compute all derived state that depends on those.
v2: Reintroduce iCLKIP WARN
v3: Try to deal with VLV/BXT DSI PLL as well
From: Ville Syrjälä
Use round-to-nearest behavour when calculating the TMDS clock.
Matches what we do for most other clock related things.
Acked-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 3 ++-
drivers/gpu/drm/i915/display/intel_hdmi.c
From: Ville Syrjälä
Windows/BIOS always uses fixed N values. Let's match that
behaviour.
Allows us to also get rid of that constant_n quirk stuff.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 36 +---
From: Ville Syrjälä
On BDW+ M/N are double buffered and so we can easily reprogram them
during a fastset. So for eDP panels that support seamless DRRS we
can just change these without a full modeset.
For earlier platforms we'd need to play tricks with M1/N1 vs.
M2/N2 during the fastset to make
From: Ville Syrjälä
Add a function to get the fixed_mode with the highest clock.
The plan is to use this for the link bw calculation on seamless
DRRS panels so that we alwasy end up with the same link params
regardless of the requested refresh rate. This will allow fastset
to do seamless refresh
From: Ville Syrjälä
No sense in calling intel_modeset_pipe_config_late() for a disabled
pipe.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git
From: Ville Syrjälä
Now that we no longer do the fuzzy clock and M/N checks we can
get rid of the fastset state copy hacks.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 28 +++-
1 file changed, 3 insertions(+), 25
From: Ville Syrjälä
To make the fastboot checks at least somewhat sensible let's mark
the expected DPLL as the active one right after we finished the
state computation. Otherwise intel_pipe_config_compare() will
always be comparing things against NULL/0.
TODO: This is still not really right. If
From: Ville Syrjälä
Now that we backfeed the actual DPLL frequency into the
compute crtc state all our clocks should come out exact.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 19 ---
1 file changed, 4
From: Ville Syrjälä
Now that we no longer fuzz M/N during fastset these should
match exctly.
In order to get a match with what the BIOS does we need to round
M/N down. And we do the opposite rounding when doing the readback.
That gets us pretty much the same thing back.
There can still be
From: Ville Syrjälä
Only reassign the pipe's DPLL if it's going through a full
.compute_config() cycle. If OTOH it's just getting modeset
eg. in order to change cdclk there doesn't seem much point in
picking a new DPLL for it.
This should also prevent .get_dplls() from seeing a funky port_clock
From: Ville Syrjälä
Currently we calculate a lot of things (pixel rate, watermarks,
cdclk) trusting that the DPLL can generate the exact frequency
we ask it. In practice that is not true and there can be
certain amount of rounding involved.
To allow us to eventually get accurate numbers for all
From: Ville Syrjälä
And with fastset made to not suck we can consider allowing
seameless M/N changes on eDP panels that support such things.
I've given that a quick test here on a TGL and it seemed to work
OK.
The rough parts:
- The DPLL stuff is kinda messy still, a lot of which is due to
From: Ville Syrjälä
We have a couple of places that want to make distinction between
double buffered M/N registers vs. the split M1/N1+M2/N2 registers.
Add a helper for that.
v2: Turn into a HAS_ macro (Jani)
Reviewed-by: Jani Nikula #v1
Signed-off-by: Ville Syrjälä
---
From: Ville Syrjälä
Shuffle some PLL functions around a bit to avoid ugle
forward declarations later on. No functional changes.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 176 +-
1 file changed, 88 insertions(+),
From: Ville Syrjälä
intel_crtc_dotclock() is a bit misplaced. In lieu of a better
place let's just move it next to its friends in intel_display.c.
Reviewed-by: Jani Nikula
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_ddi.c | 22
On Mon, 20 Jun 2022 at 17:28, Christian König wrote:
>
> Hi Thomas,
>
> Am 20.06.22 um 16:31 schrieb Thomas Voegtle:
> > On Mon, 20 Jun 2022, Christian König wrote:
> >
> >> Am 20.06.22 um 13:40 schrieb Thomas Voegtle:
> >>> On Mon, 20 Jun 2022, Christian König wrote:
> >>>
> Hi Thomas,
>
On Mon, 20 Jun 2022, Jani Nikula wrote:
> On Mon, 20 Jun 2022, Animesh Manna wrote:
>> Each LFP may have different panel type which is stored in LFP data
>> data block. Based on the child device index respective panel-type/
>> panel-type2 field will be used.
>>
>> v1: Initial rfc verion.
>> v2:
On Mon, Jun 20, 2022 at 12:05:42PM +0300, Jani Nikula wrote:
> On Fri, 17 Jun 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We have a couple of places that want to make distinction between
> > double buffered M/N registers vs. the split M1/N1+M2/N2 registers.
> > Add a helper for
On Fri, 17 Jun 2022, Jani Nikula wrote:
> Split out the modeset hardware state readout and sanitize, or state
> setup, to a separate file.
>
> Do some drive-by checkpatch fixes while at it.
>
> v2: Rebase
>
> Signed-off-by: Jani Nikula
> Reviewed-by: Ville Syrjälä # v1
Both patches pushed to
On Mon, Jun 20, 2022 at 11:43:10AM +0100, Tvrtko Ursulin wrote:
Hi,
On 17/06/2022 06:14, Niranjana Vishwanathapura wrote:
VM_BIND design document with description of intended use cases.
v2: Reduce the scope to simple Mesa use case.
since I expressed interest please add me to cc when
On Mon, 20 Jun 2022, "Jason A. Donenfeld" wrote:
> Hi Jani,
>
> On Mon, Jun 20, 2022 at 07:10:30PM +0300, Jani Nikula wrote:
>> On Mon, 20 Jun 2022, "Jason A. Donenfeld" wrote:
>> > Hi Jani,
>> >
>> > Do you plan to merge this revert?
>>
>> Yes, I've done that now, thanks for the bisection and
Hi Jani,
On Mon, Jun 20, 2022 at 07:10:30PM +0300, Jani Nikula wrote:
> On Mon, 20 Jun 2022, "Jason A. Donenfeld" wrote:
> > Hi Jani,
> >
> > Do you plan to merge this revert?
>
> Yes, I've done that now, thanks for the bisection and the patch.
Thanks!
I see that this went into
On Mon, 20 Jun 2022, "Jason A. Donenfeld" wrote:
> Hi Jani,
>
> Do you plan to merge this revert?
Yes, I've done that now, thanks for the bisection and the patch.
Ankit, Imre, we need to figure out what to do with [1] now.
BR,
Jani.
[1] https://gitlab.freedesktop.org/drm/intel/-/issues/5272
On 20.06.2022 14:36, Thomas Hellström wrote:
In vma destruction, the following race may occur:
Thread 1: Thread 2:
i915_vma_destroy();
...
list_del_init(vma->vm_link);
...
mutex_unlock(vma->vm->mutex);
__i915_vm_release();
On Mon, Jun 20, 2022 at 07:42:25AM -0700, Zeng, Oak wrote:
Thanks,
Oak
-Original Message-
From: Vishwanathapura, Niranjana
Sent: June 17, 2022 1:15 AM
To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Vetter,
Daniel
Cc: Hellstrom, Thomas ; Wilson, Chris P
;
== Series Details ==
Series: drm/i915: Fix vm use-after-free in vma destruction (rev2)
URL : https://patchwork.freedesktop.org/series/103922/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11780 -> Patchwork_103922v2
()
On Thu, May 26, 2022 at 4:55 PM Dmitry Osipenko
wrote:
>
> Introduce a common DRM SHMEM shrinker framework that allows to reduce
> code duplication among DRM drivers by replacing theirs custom shrinker
> implementations with the generic shrinker.
>
> In order to start using DRM SHMEM shrinker
On Mon, Jun 20, 2022 at 7:09 AM Dmitry Osipenko
wrote:
>
> On 6/19/22 20:53, Rob Clark wrote:
> ...
> >> +static unsigned long
> >> +drm_gem_shmem_shrinker_count_objects(struct shrinker *shrinker,
> >> +struct shrink_control *sc)
> >> +{
> >> + struct
== Series Details ==
Series: drm/i915/dsi: add payload receiving code (rev5)
URL : https://patchwork.freedesktop.org/series/105096/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11780 -> Patchwork_105096v5
Summary
---
== Series Details ==
Series: drm/i915: stop modifying "const" device info
URL : https://patchwork.freedesktop.org/series/105358/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11780 -> Patchwork_105358v1
Summary
---
Thanks,
Oak
> -Original Message-
> From: Vishwanathapura, Niranjana
> Sent: June 17, 2022 1:15 AM
> To: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Vetter,
> Daniel
> Cc: Hellstrom, Thomas ; Wilson, Chris P
> ; ja...@jlekstrand.net;
> christian.koe...@amd.com;
== Series Details ==
Series: drm/i915: stop modifying "const" device info
URL : https://patchwork.freedesktop.org/series/105358/
State : warning
== Summary ==
Error: dim checkpatch failed
0c57ec003486 drm/i915: use GRAPHICS_VER() instead of accessing match_info
directly
596a710de9af
Acked-by: Nirmoy Das
On 6/20/2022 2:36 PM, Thomas Hellström wrote:
In vma destruction, the following race may occur:
Thread 1: Thread 2:
i915_vma_destroy();
...
list_del_init(vma->vm_link);
...
mutex_unlock(vma->vm->mutex);
In vma destruction, the following race may occur:
Thread 1: Thread 2:
i915_vma_destroy();
...
list_del_init(vma->vm_link);
...
mutex_unlock(vma->vm->mutex);
__i915_vm_release();
release_references();
And in release_reference() we
Hi, Andi
On 5/19/22 23:46, Andi Shyti wrote:
Hi Thomas,
On Thu, May 12, 2022 at 11:40:45AM +0200, Thomas Hellström wrote:
In vma destruction, the following race may occur:
Thread 1: Thread 2:
i915_vma_destroy();
...
list_del_init(vma->vm_link);
...
Hi Jani,
Do you plan to merge this revert?
Thanks,
Jason
Hi,
On 17/06/2022 06:14, Niranjana Vishwanathapura wrote:
VM_BIND design document with description of intended use cases.
v2: Reduce the scope to simple Mesa use case.
since I expressed interest please add me to cc when sending out.
How come the direction changed to simplify all of a
== Series Details ==
Series: drm/i915/dsi: add payload receiving code (rev4)
URL : https://patchwork.freedesktop.org/series/105096/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11778_full -> Patchwork_105096v4_full
On 20/06/2022 11:02, zys.zlj...@gmail.com wrote:
From: katrinzhou
The variable ret is reassigned and the value EINVAL is never used.
Thus, remove the unused assignments.
Addresses-Coverity: ("Unused value")
Fixes: d4433c7600f7 ("drm/i915/gem: Use the proto-context to handle create
On Mon, 20 Jun 2022, zys.zlj...@gmail.com wrote:
> From: katrinzhou
>
> The variable ret is reassigned and the value EINVAL is never used.
> Thus, remove the unused assignments.
It's obviously a bug, but it's not obvious just throwing the code away
is the fix. Maybe there's a missing "else"
On 10.6.2022 20.43, Matthew Auld wrote:
On Fri, 10 Jun 2022 at 15:53, Matthew Auld
wrote:
On Fri, 10 Jun 2022 at 13:12, Juha-Pekka Heikkila
wrote:
From: CQ Tang
Display might allocate a smem object and call
i915_vma_pin_iomap(), the existing code will fail.
This fix was suggested by
== Series Details ==
Series: drm/i915/bios: calculate panel type as per child device index in VBT
(rev3)
URL : https://patchwork.freedesktop.org/series/104943/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11778_full -> Patchwork_104943v3_full
On Fri, 17 Jun 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have a couple of places that want to make distinction between
> double buffered M/N registers vs. the split M1/N1+M2/N2 registers.
> Add a helper for that.
>
> Signed-off-by: Ville Syrjälä
Mhh. So why a function in
On Fri, 17 Jun 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Shuffle some PLL functions around a bit to avoid ugle
> forward declarations later on. No functional changes.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c |
On Fri, 17 Jun 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> intel_crtc_dotclock() is a bit misplaced. In lieu of a better
> place let's just move it next to its friends in intel_display.c.
With hopes we'll find a better place than intel_display.c for this and
its friends in the future,
To support Host to read data from Peripheral after
a DCS read command is sent over DSI.
v1: initial version.
v2:
- adding error message when failing to place BTA.
- returning byte number instead of 0 for the read
function dsi_read_pkt_payld().
v3: fixing coding style warning.
v4:
- correcting the
On Mon, 20 Jun 2022, Jani Nikula wrote:
> Move any device info that gets modified runtime into runtime info,
> making device info a const pointer. Finally throw mkwrite_device_info()
> into the curb.
Had some SMTP issues sending this series, sorry if you got multiple
copies of some patches.
BR,
On Mon, 20 Jun 2022, Animesh Manna wrote:
> Each LFP may have different panel type which is stored in LFP data
> data block. Based on the child device index respective panel-type/
> panel-type2 field will be used.
>
> v1: Initial rfc verion.
> v2: Based on review comments from Jani,
> - Used
Now that the device info is no longer modified runtime, we don't need to
make a copy of it, and we can convert i915->__info into a pointer to
static const data. Also remove mkwrite_device_info().
This does increase the text size slightly.
Signed-off-by: Jani Nikula
---
An alternative is to
This is the last blocker in making device info a pointer to const
data. Hopefully resetting pipe_mask to 0 and thus ensuring HAS_DISPLAY()
is false is enough, and we don't go ahead and do something with the
display info regardless. Fingers crossed.
Signed-off-by: Jani Nikula
---
If it's modified runtime, it's runtime info.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_vdsc.c | 2 +-
drivers/gpu/drm/i915/i915_pci.c | 4 ++--
drivers/gpu/drm/i915/intel_device_info.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h | 2 +-
4 files changed,
If it's modified runtime, it's runtime info.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_pci.c | 6 +++---
drivers/gpu/drm/i915/intel_device_info.c | 3 ++-
drivers/gpu/drm/i915/intel_device_info.h | 2 +-
4 files changed, 7
If it's modified runtime, it's runtime info.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_hdcp.c | 4 ++--
drivers/gpu/drm/i915/i915_pci.c | 6 +++---
drivers/gpu/drm/i915/intel_device_info.c | 4 +++-
drivers/gpu/drm/i915/intel_device_info.h | 3 ++-
4 files
If it's modified runtime, it's runtime info.
mock_gem_device() is the only one that modifies them. If that could be
fixed, we wouldn't have to do this.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
drivers/gpu/drm/i915/i915_pci.c
If it's modified runtime, it's runtime info.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.h | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 6 +-
drivers/gpu/drm/i915/i915_pci.c | 66 ++--
If it's modified runtime, it's runtime info.
mock_gem_device() is the only one that modifies it. If that could be
fixed, we wouldn't have to do this.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/i915_pci.c | 56
If it's modified runtime, it's runtime info.
mock_gem_device() is the only one that modifies it. If that could be
fixed, we wouldn't have to do this.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_pci.c | 4
If it's modified runtime, it's runtime info.
Curiously, the flag was never initialized statically.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_sseu.c | 5 ++---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_device_info.c | 2 ++
1 - 100 of 120 matches
Mail list logo
