The pull request you sent on Fri, 14 Oct 2022 10:29:19 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2022-10-14
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/9c9155a3509a2ebdb06d77c7a621e9685c802eac
Thank you!
--
Deet-doot-dot, I am a bot.
On Thu, Oct 13, 2022 at 5:29 PM Dave Airlie wrote:
>
> Round of fixes for the merge window stuff, bunch of amdgpu and i915
> changes, this should have the gcc11 warning fix, amongst other
> changes.
Some of those amd changes aren't "fixes". They are some major code changes.
We're still in the
Hi
-Original Message-
From: Rob Herring
Sent: Friday, October 14, 2022 3:20 AM
To: Laurent Pinchart ; Allen Chen (陳柏宇)
Cc: Pin-yen Lin ; Jau-Chih Tseng (曾昭智)
; Kenneth Hung (洪家倫) ;
Hermes Wu (吳佳宏) ; Andrzej Hajda
; Neil Armstrong ; Robert
Foss ; Jonas Karlman ; Jernej Skrabec
;
After commit 64ff18911878, struct csc_coef_rgb2yuv is not used any more
and can be removed as well.
Fixes: 64ff18911878 ("drm/omap: Enable COLOR_ENCODING and COLOR_RANGE
properties for planes")
Signed-off-by: Yuan Can
---
changes in v2:
- adjust commit msg
---
On Thu, Oct 13, 2022 at 11:07:14PM +0200, Fabio M. De Francesco wrote:
> The use of kmap() is being deprecated in favor of kmap_local_page().
>
> There are two main problems with kmap(): (1) It comes with an overhead as
> the mapping space is restricted and protected by a global lock for
>
https://bugzilla.kernel.org/show_bug.cgi?id=216583
Paulo Marcos de Souza Arruda do Nascimento (contato-mygh...@protonmail.com)
changed:
What|Removed |Added
Hardware|All
https://bugzilla.kernel.org/show_bug.cgi?id=216583
Bug ID: 216583
Summary: [AMDGPU] Black screen after resume + Failed to pin
framebuffer -19
Product: Drivers
Version: 2.5
Kernel Version: 6.0.1
Hardware: All
Hi Linus,
Round of fixes for the merge window stuff, bunch of amdgpu and i915
changes, this should have the gcc11 warning fix, amongst other
changes.
Dave.
drm-next-2022-10-14:
drm fixes for 6.1-rc1
amdgpu:
- DC mutex fix
- DC SubVP fixes
- DCN 3.2.x fixes
- DCN 3.1.x fixes
- SDMA 6.x fixes
-
On 10/13/2022 3:28 PM, Dixit, Ashutosh wrote:
On Thu, 13 Oct 2022 08:55:24 -0700, Vinay Belgaumkar wrote:
Hi Vinay,
GuC will set the min/max frequencies to theoretical max on
ATS-M. This will break kernel ABI, so limit min/max frequency
to RP0(platform max) instead.
Isn't what we are
On Thu, Oct 13, 2022 at 3:55 PM Rob Clark wrote:
>
> From: Rob Clark
>
> First patch fixes a recently introduced memory corruption, the remaining
> two are cleanups.
Series is
Reviewed-by: Chia-I Wu
> Rob Clark (3):
> drm/msm/a6xx: Fix kvzalloc vs state_kcalloc usage
> drm/msm/a6xx: Skip
Hi Liviu,
On 10/12/22 17:07, Liviu Dudau wrote:
Hi Danilo,
Appologies again for the delay in reviewing this as I was at XDC last week.
No worries, thanks for following up.
Looking at the documentation for drm_dev_unplug, you can get a hint about what
is going on:
/*
* [] There is
From: Rob Clark
adreno_show_object() is a trap! It will re-allocate the pointer it is
passed on first call, when the data is ascii85 encoded, using kvmalloc/
kvfree(). Which means the data *passed* to it must be kvmalloc'd, ie.
we cannot use the state_kcalloc() helper.
This partially reverts
From: Rob Clark
Technically it worked as it was before, only because it was using the
_safe version of the iterator. But it is sloppy practice to leave
dangling pointers.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 4 +++-
1 file changed, 3 insertions(+), 1
From: Rob Clark
Some buffers are unused on certain sub-generations of a6xx. So just
skip them.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c
From: Rob Clark
First patch fixes a recently introduced memory corruption, the remaining
two are cleanups.
Rob Clark (3):
drm/msm/a6xx: Fix kvzalloc vs state_kcalloc usage
drm/msm/a6xx: Skip snapshotting unused GMU buffers
drm/msm/a6xx: Remove state objects from list before freeing
On Thu, 13 Oct 2022 08:55:24 -0700, Vinay Belgaumkar wrote:
>
Hi Vinay,
> GuC will set the min/max frequencies to theoretical max on
> ATS-M. This will break kernel ABI, so limit min/max frequency
> to RP0(platform max) instead.
Isn't what we are calling "theoretical max" or "RPmax" really just
There is a spelling mistake in a DRM_DEBUG_KMS message. Fix it.
Also clean checkpatch warning on the overly long line and remove
braces as the if statement is just one statement.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/gma500/cdv_intel_dp.c | 6 +++---
1 file changed, 3 insertions(+),
Github deprecated the git:// links about a year ago, so let's move to
the https:// URLs instead.
Reported-by: Conor Dooley
Link: https://github.blog/2021-09-01-improving-git-protocol-security-github/
Signed-off-by: Palmer Dabbelt
---
I've split these up by github username so folks can take them
The use of kmap() is being deprecated in favor of kmap_local_page().
There are two main problems with kmap(): (1) It comes with an overhead as
the mapping space is restricted and protected by a global lock for
synchronization and (2) it also requires global TLB invalidation when the
kmap’s pool
When booting with CONFIG_CFI_CLANG, there are numerous violations when
accessing the files under
/sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:
$ cd /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0
$ grep . *
id:0
punit_req_freq_mhz:350
rc6_enable:1
https://bugzilla.kernel.org/show_bug.cgi?id=216119
--- Comment #41 from Alex Deucher (alexdeuc...@gmail.com) ---
Does setting amdgpu.dc=0 make any difference?
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
We're observing sporadic HuC delayed load timeouts in CI, due to mei_pxp
binding completing later than we expected. HuC is still loaded when the
bind occurs, but in the meantime i915 has started allowing submission to
the VCS engines even if HuC is not there.
In most of the cases I've observed,
Jonas has reported that this breaks Mutter. Sasha, can we remove this
from the stable queue?
Tested on MT8195 and confirmed both correct video output and improved DRAM
bandwidth performance.
v4:
* Move modifier validation to format_mod_supported function.
* Add modifiers to drm_universal_plane_init() call.
* Make comparisons to DRM_FORMAT_MOD_LINEAR explicit rather than relying on
https://bugzilla.kernel.org/show_bug.cgi?id=216119
--- Comment #40 from Harald Judt (h.j...@gmx.at) ---
Any updates on this? Hibernate/resume is still borked after a few cycles
(rather sooner than later) and it gets harder and harder to revert these fb
patches on newer kernels. The prefer_shadow
On Thu, Oct 13, 2022 at 09:41:21PM +0300, Ville Syrjälä wrote:
> On Tue, Oct 11, 2022 at 04:49:35PM +0300, Jani Nikula wrote:
> > For normal connector detect, there's really no point in trying dual mode
> > detect if the connector is disconnected. We can simplify the detect
> > sequence by
On Thu, Oct 13, 2022 at 02:05:45PM +0300, Laurent Pinchart wrote:
> Hi Allen,
>
> Thank you for the patch.
>
> On Thu, Oct 13, 2022 at 06:51:13PM +0800, allen wrote:
> > From: allen chen
> >
> > Add properties to restrict dp output data-lanes and clock.
> >
> > Signed-off-by: Pin-Yen Lin
> >
On Tue, Oct 11, 2022 at 04:49:35PM +0300, Jani Nikula wrote:
> For normal connector detect, there's really no point in trying dual mode
> detect if the connector is disconnected. We can simplify the detect
> sequence by skipping it. Since intel_hdmi_dp_dual_mode_detect() is only
> called when EDID
Building 32-bit images may fail with the following error.
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:
In function ‘dml32_UseMinimumDCFCLK’:
drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn32/display_mode_vba_util_32.c:3142:1:
error: the frame
Hi Maxime,
Dne četrtek, 13. oktober 2022 ob 15:19:06 CEST je Maxime Ripard napisal(a):
> Now that the core can deal fine with analog TV modes, let's convert the
> sun4i TV driver to leverage those new features.
>
> Acked-by: Noralf Trønnes
> Signed-off-by: Maxime Ripard
>
> ---
> Changes in
On 10/13/2022 9:25 PM, Vinay Belgaumkar wrote:
GuC will set the min/max frequencies to theoretical max on
ATS-M. This will break kernel ABI, so limit min/max frequency
to RP0(platform max) instead.
Also modify the SLPC selftest to update the min frequency
when we have a server part so that
On 10/12/2022 7:05 PM, Christian König wrote:
That essentially looks like the right approach, but I would go a few
steps further.
I think we should add a drm_sched_fence_set_parent() function to
sched_fence.c and move a good part of the handling into that C file.
Just a simple signal
> > > So no tests that actually verify that the kernel properly rejects
> > > stuff stuff like modesets, gamma LUT updates, plane movement,
> > > etc.?
> >
> > Pondering this a bit more, it just occurred to me the current driver
> > level checks might easily lead to confusing behaviour. Eg. is
> >
On 10/13/2022 2:36 AM, Marijn Suijten wrote:
On 2022-10-12 16:03:06, Abhinav Kumar wrote:
On 10/9/2022 11:50 AM, Marijn Suijten wrote:
As per the FIXME this code is entirely duplicate with what is already
provided inside drm_dsc_compute_rc_parameters(), and it is yet unknown
why this
On 10/13/2022 8:14 AM, Das, Nirmoy wrote:
On 10/12/2022 8:26 PM, Vinay Belgaumkar wrote:
GuC will set the min/max frequencies to theoretical max on
ATS-M. This will break kernel ABI, so limit min/max frequency
to RP0(platform max) instead.
Also modify the SLPC selftest to update the min
GuC will set the min/max frequencies to theoretical max on
ATS-M. This will break kernel ABI, so limit min/max frequency
to RP0(platform max) instead.
Also modify the SLPC selftest to update the min frequency
when we have a server part so that we can iterate between
platform min and max.
v2:
On Thu, 13 Oct 2022 18:51:13 +0800, allen wrote:
> From: allen chen
>
> Add properties to restrict dp output data-lanes and clock.
>
> Signed-off-by: Pin-Yen Lin
> Signed-off-by: Allen Chen
> ---
> .../bindings/display/bridge/ite,it6505.yaml | 43 +++
> 1 file changed, 43
On Mon, 03 Oct 2022 14:32:36 -0700, Andi Shyti wrote:
>
Hi Andi,
> > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > index f9d6d3b08bba..19b9fe3ef237 100644
> > ---
On Mon, 03 Oct 2022 14:13:10 -0700, Andi Shyti wrote:
>
Hi Andi,
> [...]
>
> > > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > > b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon
> > > index 16e697b1db3d..7525db243d74 100644
> > > ---
On Fri, 30 Sep 2022 09:52:28 -0700, Rodrigo Vivi wrote:
>
Hi Rodrigo,
> On Tue, Sep 27, 2022 at 11:20:17AM +0530, Badal Nilawar wrote:
> > From: Dale B Stimson
> >
> > Use i915 HWMON to display device level energy input.
> >
> > v2: Updated the date and kernel version in feature description
> >
On Mon, 03 Oct 2022 14:05:14 -0700, Andi Shyti wrote:
>
> Hi Badal,
>
> [...]
>
> > hwm_get_preregistration_info(struct drm_i915_private *i915)
> > {
> > struct i915_hwmon *hwmon = i915->hwmon;
> > + struct intel_uncore *uncore = >uncore;
> > + intel_wakeref_t wakeref;
> > + u32
On Wed, 21 Sep 2022 05:02:48 -0700, Gupta, Anshuman wrote:
>
> > diff --git a/drivers/gpu/drm/i915/intel_mchbar_regs.h
> > b/drivers/gpu/drm/i915/intel_mchbar_regs.h
> > index b74df11977c6..1014d0b7cc16 100644
> > --- a/drivers/gpu/drm/i915/intel_mchbar_regs.h
> > +++
On Mon, 03 Oct 2022 13:56:05 -0700, Andi Shyti wrote:
Hi Andi,
Badal is out for a bit so I am posting this version of the patches.
>
> Hi Badal,
>
> [...]
>
> > static void
> > hwm_get_preregistration_info(struct drm_i915_private *i915)
> > {
> > + struct i915_hwmon *hwmon = i915->hwmon;
>
This series adds the HWMON support for DGFX
Test-with: 20221013151400.2086268-1-ashutosh.di...@intel.com
v2:
- Reorganized series. Created first patch as infrastructure patch
followed by feature patches. (Ashutosh)
- Fixed review comments (Jani)
- Fixed review comments (Ashutosh)
v3:
From: Dale B Stimson
The i915 HWMON module will be used to expose voltage, power and energy
values for dGfx. Here we set up i915 hwmon infrastructure including i915
hwmon registration, basic data structures and functions.
v2:
- Create HWMON infra patch (Ashutosh)
- Fixed review comments
From: Dale B Stimson
Use i915 HWMON to display device level energy input.
v2: Updated the date and kernel version in feature description
v3:
- Cleaned up hwm_energy function and removed unused function
i915_hwmon_energy_status_get (Ashutosh)
v4: KernelVersion: 6.2, Date: February 2023 in
From: Riana Tauro
Use i915 HWMON subsystem to display current input voltage.
v2:
- Updated date and kernel version in feature description
- Fixed review comments (Ashutosh)
v3: Use macro HWMON_CHANNEL_INFO to define hwmon channel (Guenter)
v4:
- Fixed review comments (Ashutosh)
- Use
Expose power1_max_interval, that is the tau corresponding to PL1, as a
custom hwmon attribute. Some bit manipulation is needed because of the
format of PKG_PWR_LIM_1_TIME in
GT0_PACKAGE_RAPL_LIMIT register (1.x * power(2,y)).
v2: Update date and kernel version in Documentation (Badal)
v3: Cleaned
Expose the card reactive critical (I1) power. I1 is exposed as
power1_crit in microwatts (typically for client products) or as
curr1_crit in milliamperes (typically for server).
v2: Add curr1_crit functionality (Ashutosh)
v3: Use HWMON_CHANNEL_INFO to define power1_crit, curr1_crit (Badal)
v4:
From: Dale B Stimson
Extend hwmon power/energy for XEHPSDV especially per gt level energy
usage.
v2: Update to latest HWMON spec (Ashutosh)
v3: Fix review comments (Ashutosh)
v4: Fix review comments (Anshuman)
v5: s/hwmon_device_register_with_info/
devm_hwmon_device_register_with_info/
From: Dale B Stimson
Use i915 HWMON to display/modify dGfx power PL1 limit and TDP setting.
v2:
- Fix review comments (Ashutosh)
- Do not restore power1_max upon module unload/load sequence
because on production systems modules are always loaded
and not unloaded/reloaded (Ashutosh)
On 10/13/2022 4:34 AM, Tauro, Riana wrote:
On 10/12/2022 11:56 PM, Vinay Belgaumkar wrote:
GuC will set the min/max frequencies to theoretical max on
ATS-M. This will break kernel ABI, so limit min/max frequency
to RP0(platform max) instead.
Also modify the SLPC selftest to update the min
On 10/12/2022 8:26 PM, Vinay Belgaumkar wrote:
GuC will set the min/max frequencies to theoretical max on
ATS-M. This will break kernel ABI, so limit min/max frequency
to RP0(platform max) instead.
Also modify the SLPC selftest to update the min frequency
when we have a server part so that we
Thanks for the comments everyone! I'll upload a new CL sometime today.
I did want to ask though, I realize I should be using u32/u64 for
kernel code in general, but the rest of this file seems to be written
using unsigned int/unsigned long long. In this circumstance, does
keeping with the style
Am 13.10.22 um 15:28 schrieb Jocelyn Falempe:
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);
Tested on G200_SE_A rev 42
This line of code was
Hi!
I bisected an issue of the 6.0 kernel which started happening after
6.0-rc7 on all my machines.
Backtrace of this issue looks like as:
[ 2807.339439] [ cut here ]
[ 2807.339445] WARNING: CPU: 11 PID: 2061 at
drivers/gpu/drm/drm_modeset_lock.c:276
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |= 0x80" which was changed to
m |= ((pixpllcn & BIT(8)) >> 1);
Tested on G200_SE_A rev 42
This line of code was moved to another file with
commit 85397f6bc4ff
Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
Changes in v5:
- Removed the count variable in get_modes
- Removed spurious vc4 change
---
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. We're also making use of
the new analog TV
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
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().
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_vec.c | 8 +++-
From: Mateusz Kwiatkowski
The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.
Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.
Acked-by: Noralf Trønnes
Signed-off-by:
The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created some boilerplate that can be be shared
across drivers too.
Let's create an atomic_check helper for those use cases.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
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
---
Changes in v5:
- Switched to KUNIT_ASSERT_NOT_NULL
---
drivers/gpu/drm/drm_modes.c
The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().
The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.
In the case of the named modes though,
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.
Reviewed-by: Noralf Trønnes
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.
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
---
drivers/gpu/drm/drm_modes.c | 9 ++---
include/drm/drm_connector.h | 7
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
As part of the command line parsing rework coming in the next patches,
we'll need to lookup drm_connector_tv_mode values by their name, already
defined in drm_tv_mode_enum_list.
In order to avoid any code duplication, let's do a function that will
perform a lookup of a TV mode name and return its
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
---
Changes in v5:
- Removed useless
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.
In order for the tests to still pass, some extra checks are needed, so
it's not a 1:1 move.
Signed-off-by: Maxime Ripard
---
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
---
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
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
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.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
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
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:
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
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:
*
On 13/10/2022 12:36, Ville Syrjälä wrote:
On Thu, Oct 13, 2022 at 11:05:19AM +0200, Thomas Zimmermann wrote:
Hi
Am 13.10.22 um 10:29 schrieb Jocelyn Falempe:
For G200_SE_A, PLL M setting is wrong, which leads to blank screen,
or "signal out of range" on VGA display.
previous code had "m |=
Hello Max, Marek, Dave et al.
On Tue, Jun 28, 2022 at 08:18:36PM +0200, Max Krummenacher wrote:
> From: Max Krummenacher
>
> The property is used to set the enum bus_format and infer the bpc
> for a panel defined by 'panel-dpi'.
> This specifies how the panel is connected to the display
Hi Dave, Daniel,
Not sure if there is time for one more pull during the merge window, but
in case there is here it is. Only one which affects platforms outside
force_probe and that is the fix for DPT PTE corruption after resume. The
rest are all DG2 specific.
Regards,
Tvrtko
On Wed, Oct 12, 2022 at 01:34:38PM -0700, Dmitry Torokhov wrote:
> On Mon, Oct 10, 2022 at 10:36:00PM +0200, Linus Walleij wrote:
> > On Thu, Oct 6, 2022 at 12:05 PM Daniel Thompson
> > wrote:
> > > On Thu, Oct 06, 2022 at 11:03:15AM +0200, Linus Walleij wrote:
> > > > On Tue, Oct 4, 2022 at
Hi Dave and Daniel,
this is the weekly PR for drm-misc-fixes.
Best regards
Thomas
drm-misc-fixes-2022-10-13:
Short summary of fixes pull:
* vc4: HDMI fixes
The following changes since commit cc62d98bd56d45de4531844ca23913a15136c05b:
Revert "drm: bridge: analogix/dp: add panel
On Thu, 29 Sep 2022 11:21:18 +0200, Maxime Ripard wrote:
> If our HSM clock has not been properly initialized, any register access
> will silently lock up the system.
>
> Let's check that this can't happen by adding a check for the rate before
> any register access, and error out otherwise.
>
>
On Fri, 2 Sep 2022 16:41:11 +0200, Maxime Ripard wrote:
> The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In
> order to set it up properly, in vc4_hdmi_audio_init(), our HDMI driver
> will register a device matching the HDMI codec driver, and then register
> an ASoC card using
On Thu, 29 Sep 2022 11:21:17 +0200, Maxime Ripard wrote:
> This is a revert of commit fd5894fa2413 ("drm/vc4: hdmi: Remove clock
> rate initialization"), with the code slightly moved around.
>
> It turns out that we can't downright remove that code from the driver,
> since the Pi0-3 and Pi4 are
Hi Javier,
Thanks for reviewing this
On Thu, Oct 13, 2022 at 11:27:15AM +0200, Javier Martinez Canillas wrote:
> On 9/2/22 16:41, Maxime Ripard wrote:
> > The VC4 HDMI controller driver relies on the HDMI codec ASoC driver. In
> > order to set it up properly, in vc4_hdmi_audio_init(), our HDMI
On 10/12/2022 11:56 PM, Vinay Belgaumkar wrote:
GuC will set the min/max frequencies to theoretical max on
ATS-M. This will break kernel ABI, so limit min/max frequency
to RP0(platform max) instead.
Also modify the SLPC selftest to update the min frequency
when we have a server part so that
Replace GEM VRAM helpers with GEM SHMEM helpers in ast. Avoids OOM
errors when allocating video memory. Also adds support for dma-buf
functionality.
Aspeed display hardware supports display resolutions of FullHD and
higher at 32-bit pixel depth. But the amount of video memory is in
the range of 8
Rename the plane structure struct ast_cursor_plane to struct
ast_plane as it will be used for the primary plane as well. No
functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_drv.h | 15 +--
Update the cursor image via damage handling in-place. The cursor's
double buffering has no visible effect on the output, so remove it.
Done in preparation of switching ast to GEM SHMEM helpers. Removing
double buffering will allow us to use the same data structure for
primary and cursor plane.
Rename some of the variables in the plane code to better reflect the
old and new state during checks and updates. Change some indention as
well. No functional changes.
Signed-off-by: Thomas Zimmermann
Reviewed-by: Jocelyn Falempe
Tested-by: Jocelyn Falempe
---
drivers/gpu/drm/ast/ast_mode.c |
Some AST-based BMCs stop display output for up to 5 seconds after
reprogramming the scanout address. As the address is fixed, avoid
re-setting the address' value.
v2:
* only update offset if it changed (Jocelyn)
Reported-by: Jocelyn Falempe
Signed-off-by: Thomas Zimmermann
Reviewed-by:
There's no need to add planes to the atomic state. Remove the call
to drm_atomic_add_affected_planes() from ast.
On full modesets, the DRM helpers already add a CRTC's planes to the
atomic state; see drm_atomic_helper_check_modeset(). There's no reason
to call drm_atomic_add_affected_planes()
This patchset converts ast to GEM SHMEM helpers. Fixes problems with
memory allocation and BMC scanout updates.
Patches 1 to 3 are fixes for various minor problems in the ast driver.
We should merge them even without SHMEM support.
Patches 4 to 6 prepare the driver for the conversion. The cursor
Always call drm_atomic_helper_check_plane_state() in each plane's
atomic_check function. At the minimum, it needs to set or clear the
plane state's 'visible' field. Otherwise the plane-state handling
is bogus and would keep updating planes that have been disabled.
While at it, also warn if the
Hold I/O-register lock in atomic_commit_tail to protect all pipeline
updates at once. Protects modesetting against concurrent EDID reads.
Complex modesetting operations involve mode changes and plane updates.
These steps used to be protected individually against concurrent I/O.
Make all this
Hi Allen,
Thank you for the patch.
On Thu, Oct 13, 2022 at 06:51:13PM +0800, allen wrote:
> From: allen chen
>
> Add properties to restrict dp output data-lanes and clock.
>
> Signed-off-by: Pin-Yen Lin
> Signed-off-by: Allen Chen
> ---
> .../bindings/display/bridge/ite,it6505.yaml | 43
1 - 100 of 147 matches
Mail list logo
