Am 06.03.24 um 19:19 schrieb Sunil Khatri:
Add page fault information to the devcoredump.
Output of devcoredump:
AMDGPU Device Coredump
version: 1
kernel: 6.7.0-amd-staging-drm-next
module: amdgpu
time: 29.725011811
process_name: soft_recovery_p PID: 1720
Ring timed out details
IP Typ
Hi Dave & Sima,
Here goes the final drm-intel-fixes for v6.8.
This PR will appear to contain more patches than it does. It's 4 patches on top
of
drm-fixes after Sima pulled the previous PR as you can observe from git log.
Fixes for kernel crash on UHD 730, boot delay regression on PSR, DP DSC
W
Quoting Stephen Rothwell (2024-03-07 04:10:27)
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/display/intel_dp.c
>
> between commit:
>
> 984318aaf7b6 ("drm/i915/panelreplay: Move out psr_init_dpcd() from
> init_connector()")
>
> from the
On Wed, 6 Mar 2024 17:42:09 +0100
Sebastian Wick wrote:
> On Wed, Mar 06, 2024 at 10:27:21AM +0200, Pekka Paalanen wrote:
> > On Tue, 5 Mar 2024 14:51:49 +0100
> > Sebastian Wick wrote:
> >
> > > The initial idea of the Colorspace prop was that this maps 1:1 to
> > > InfoFrames/SDP but KMS d
On Thu, 29 Feb 2024 09:52:26 +, Matthew Auld wrote:
> This will report a build warning once we have: 806cb2270237 ("kunit:
> Annotate _MSG assertion variants with gnu printf specifiers").
>
>
Applied to drm/drm-misc (drm-misc-fixes).
Thanks!
Maxime
Forward declare struct drm_printer and include .
v2: Include (kernel test robot)
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc_internal.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index a514d5207e4
Many a times images are blurred or upscaled content is also not as
crisp as original rendered image. Traditional sharpening techniques often
apply a uniform level of enhancement across entire image, which sometimes
result in over-sharpening of some areas and potential loss of natural detail
This allows the user to set the intensity
so as to get the sharpness effect.
It is useful in scenario when the output is blurry
and user want to sharpen the pixels.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_crtc.c| 17 +++
Including the file twice can lead to errors.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_crtc_internal.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index c0c5d79ed4c9..0c693229a1c9 100644
--- a/driver
Scaler coefficient values are based on experiments
and vary for different tap value/win size. These values
are normalized by taking the sum of all values and then
dividing each value with a sum.
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm
The strength value should be greater than zero to
set to the scaler flag true and if the second scaler
is free then it can be used for sharpening purpose.
v2: Modify the condition for checking pipe scaler
availability
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_displa
Add new registers and related bits. Compute the strength
value and tap value based on display mode.
Signed-off-by: Nemesa Garg
---
.../drm/i915/display/intel_display_types.h| 1 +
.../drm/i915/display/intel_sharpen_filter.c | 81 +++
.../drm/i915/display/intel_sharpen_filt
Load the lut values during pipe enable.
v2: Add the display version check
Signed-off-by: Nemesa Garg
---
drivers/gpu/drm/i915/display/intel_crtc.c| 3 +++
drivers/gpu/drm/i915/display/intel_display.c | 14 +-
drivers/gpu/drm/i915/display/skl_scaler.c| 13 -
3 f
On 3/7/2024 1:47 PM, Christian König wrote:
Am 06.03.24 um 19:19 schrieb Sunil Khatri:
Add page fault information to the devcoredump.
Output of devcoredump:
AMDGPU Device Coredump
version: 1
kernel: 6.7.0-amd-staging-drm-next
module: amdgpu
time: 29.725011811
process_name: soft_reco
On Wed, 6 Mar 2024 18:29:53 +0100
Louis Chauvet wrote:
> [...]
>
> > > > > > > +++ b/drivers/gpu/drm/vkms/vkms_formats.c
> > > > > > > @@ -9,6 +9,17 @@
> > > > > > >
> > > > > > > #include "vkms_formats.h"
> > > > > > >
> > > > > > > +/**
> > > > > > > + * packed_pixels_offset() - Get the o
m.com/docs/git-format-patch#_base_tree_information]
>
> url:
> https://github.com/intel-lab-lkp/linux/commits/Jani-Nikula/drm-crtc-make-drm_crtc_internal-h-self-contained/20240307-023603
> base: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
> patch link:
> https://l
Hi,
Here's this week drm-misc-fixes PR
Maxime
drm-misc-fixes-2024-03-07:
A connector status polling fix, a timings fix for the Himax83102-j02
panel, a deadlock fix for nouveau, A controversial format fix for udl
that got reverted to allow further discussion, and a build fix for the
drm/buddy kun
On 07/03/2024 08:30, Maxime Ripard wrote:
On Thu, 29 Feb 2024 09:52:26 +, Matthew Auld wrote:
This will report a build warning once we have: 806cb2270237 ("kunit:
Annotate _MSG assertion variants with gnu printf specifiers").
Applied to drm/drm-misc (drm-misc-fixes).
Thanks.
Thanks!
Hi
Am 06.03.24 um 19:31 schrieb Jani Nikula:
First, fix a bunch of issues in drm headers, uncovered with the last
patch. A few kernel-doc warnings are just brushed under the carpet for
now, with a FIXME comment. Otherwise, pretty straightforward stuff.
Nice, thanks a lot. For the FIXME comment
If there are no further comments, I'm going to merge this patchset in
time for today's PR of drm-misc-next-fixes.
Am 06.03.24 um 13:28 schrieb Thomas Zimmermann:
After cleaning up in commit 11b4eedfc87d ("fbdev: Do
not include in header"), building with
CONFIG_PMAC_BACKLIGHT=y returns errors
On Thu, 07 Mar 2024, Thomas Zimmermann wrote:
> Hi
>
> Am 06.03.24 um 19:31 schrieb Jani Nikula:
>> First, fix a bunch of issues in drm headers, uncovered with the last
>> patch. A few kernel-doc warnings are just brushed under the carpet for
>> now, with a FIXME comment. Otherwise, pretty straigh
Hi,
We are using the stm32mp1 together with the sn65dsi83 bridge.
The ti,sn65dsi83 driver is (hard) enabling MIPI_DSI_MODE_VIDEO_BURST, then the
st,stm32-dsi driver is adding +20% to the clock speed.
That means our LVDS is +20% higher than expected.
Any proposals for a fix? Could we add a devic
This introduces a new drm panic handler, which displays a message when a panic
occurs.
So when fbcon is disabled, you can still see a kernel panic.
This is one of the missing feature, when disabling VT/fbcon in the kernel:
https://www.reddit.com/r/linux/comments/10eccv9/config_vtn_in_2023/
Fbco
From: Daniel Vetter
Rough sketch for the locking of drm panic printing code. The upshot of
this approach is that we can pretty much entirely rely on the atomic
commit flow, with the pair of raw_spin_lock/unlock providing any
barriers we need, without having to create really big critical
sections
This is needed for drm_panic, to draw the font, and fill
the background color, in multiple color format.
v5:
* Change the drawing API, use drm_fb_blit_from_r1() to draw the font.
* Also add drm_fb_fill() to fill area with background color.
v6:
* fix __le32 conversion warning found by the kernel
Add a debugfs file, so you can test drm_panic without freezing
your machine. This is unsafe, and should be enabled only for
developer or tester.
To display the drm_panic screen on the device 0:
echo 1 > /sys/kernel/debug/dri/0/drm_panic_plane_0
v9:
* Create a debugfs file for each plane in the d
This was initialy done for imx6, but should work on most drivers
using drm_fb_dma_helper.
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
(Thomas Zimmermann)
v9:
* go back to get_scanout_buffer()
* move get_scanout_buffer() to plane helper functions
Signed-off-by: Joce
This module displays a user friendly message when a kernel panic
occurs. It currently doesn't contain any debug information,
but that can be added later.
v2
* Use get_scanout_buffer() instead of the drm client API.
(Thomas Zimmermann)
* Add the panic reason to the panic message (Nerdopolis)
*
Add support for the drm_panic module, which displays a user-friendly
message to the screen when a kernel panic occurs.
v8:
* Replace get_scanout_buffer() with drm_panic_set_buffer()
(Thomas Zimmermann)
v9:
* Revert to using get_scanout_buffer() (Sima)
* move get_scanout_buffer() to plane he
Add support for the drm_panic module, which displays a user-friendly
message to the screen when a kernel panic occurs.
v7:
* use drm_panic_gem_get_scanout_buffer() helper
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
v9:
* Revert to using get_scanout_buffer() (Sima)
*
Add support for the drm_panic module, which displays a message to
the screen when a kernel panic occurs.
v5:
* Also check that the plane is visible and primary. (Thomas Zimmermann)
v7:
* use drm_for_each_primary_visible_plane()
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffe
Add support for the drm_panic module, which displays a message to
the screen when a kernel panic occurs.
v7
* Use drm_for_each_primary_visible_plane()
v8:
* Replace get_scanout_buffer() logic with drm_panic_set_buffer()
(Thomas Zimmermann)
v9:
* Revert to using get_scanout_buffer() (Sima)
When just including :
include/asm-generic/pgtable-nop4d.h:9:18: error: unknown type name ‘pgd_t’
9 | typedef struct { pgd_t pgd; } p4d_t;
| ^
Make self-contained by including .
Reported-by: Jani Nikula
Closes: https://lore.kernel.org/r/878r2uxwha@
Hi Jani,
On Thu, Mar 7, 2024 at 9:44 AM Jani Nikula wrote:
> On Thu, 07 Mar 2024, kernel test robot wrote:
> > kernel test robot noticed the following build errors:
>
> So I'm trying to make include/drm/ttm/ttm_caching.h self-contained by
> including with [1], but it fails like below.
>
> Cc: T
The variable out is being initialized and incremented but it is never
actually referenced in any other way. The variable is redundant and can
be removed.
Cleans up clang scan build warning:
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.c:843:6: warning: variable
'out' set but not used [-Wunused-but-se
Add support for the following 2 panels:
1. BOE NT116WHM-N44
2. CMN N116BCA-EA1
Signed-off-by: Xuxin Xiong
---
drivers/gpu/drm/panel/panel-edp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-edp.c
b/drivers/gpu/drm/panel/panel-edp.c
index a0b6f69b916f..e21b4bb
On Thu, 07 Mar 2024, Geert Uytterhoeven wrote:
> When just including :
>
> include/asm-generic/pgtable-nop4d.h:9:18: error: unknown type name ‘pgd_t’
> 9 | typedef struct { pgd_t pgd; } p4d_t;
> | ^
>
> Make self-contained by including .
>
> Reported-by: Jan
Hi Dave, Sima,
please pull the following etnaviv changes for the next merge window.
This time mostly code cleanups in preparation for PCI device support,
but also some changes required to get NPU support working with the
teflon userspace implementation. Christian also fixed the exposed chip
ID, w
On 2024-03-07, Jocelyn Falempe wrote:
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 39ef0a6addeb..c0bb91312fb2 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -38,6 +38,7 @@
> #include
> #i
Il 06/03/24 21:37, Justin Green ha scritto:
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
of 0 bytes. Currently, no such check exists and the kernel will panic if
a userspace application attempts to allocate a 0x0 GBM buffer.
Tested by attempting to allocate a 0x0 GBM bu
Thomas Zimmermann writes:
> Replace with a forward declaration in to
> resolve an unnecessary dependency. Remove pmac_backlight_curve_lookup()
> and struct fb_info from source and header files. The function and the
> framebuffer struct are unused. No functional changes.
>
> v3:
> * Add Fix
The variable num_relocs is being initialized and incremented but it is
never actually referenced in any other way. The variable is redundant
and can be removed.
Cleans up clang scan build warning:
drivers/gpu/drm/qxl/qxl_ioctl.c:148:14: warning: variable 'num_relocs'
set but not used [-Wunused-but
Hi Dave, Sima
A single error path fix for 6.8 final (-rc8).
Thanks,
Thomas
drm-xe-fixes-2024-03-07:
Driver Changes:
- An error path fix.
The following changes since commit 90d35da658da8cff0d4ecbb5113f5fac9d00eb72:
Linux 6.8-rc7 (2024-03-03 13:02:52 -0800)
are available in the Git repository
https://bugzilla.kernel.org/show_bug.cgi?id=218569
Bug ID: 218569
Summary: Early KMS Resolution Issue on MST dock connected 4K
Monitor
Product: Drivers
Version: 2.5
Hardware: All
OS: Linux
Status
On 06/03/24 21:03, Louis Chauvet wrote:
> Le 06/03/24 - 17:03, Arthur Grillo a écrit :
>> Signed-off-by: Arthur Grillo
>> ---
>> drivers/gpu/drm/vkms/tests/vkms_format_test.c | 2 +-
>> drivers/gpu/drm/vkms/vkms_drv.h | 4
>> 2 files changed, 5 insertions(+), 1 deletion(-)
>
Hi Geert,
On Tue, 2024-02-27 at 12:04 +0100, Geert Uytterhoeven wrote:
> Hi Matt,
>
> On Tue, Feb 27, 2024 at 10:31 AM Matt Coster wrote:
> > Hi Adam,
> >
> > Thanks for these patches! I'll just reply to this one patch, but my
> > comments apply to them all.
> >
> > On 27/02/2024 03:45, Adam F
On 2024/3/7 6:10, Mina Almasry wrote:
...
> +static int netdev_restart_rx_queue(struct net_device *dev, int rxq_idx)
> +{
> + void *new_mem;
> + void *old_mem;
> + int err;
> +
> + if (!dev || !dev->netdev_ops)
> + return -EINVAL;
>
Hi Matthew,
On 3/6/2024 11:19 PM, Matthew Auld wrote:
On 04/03/2024 16:32, Arunpravin Paneer Selvam wrote:
- Add tracking clear page feature.
- Driver should enable the DRM_BUDDY_CLEARED flag if it
successfully clears the blocks in the free path. On the otherhand,
DRM buddy marks each bl
On Tue, 2024-02-27 at 05:50 -0600, Adam Ford wrote:
> On Tue, Feb 27, 2024 at 3:31 AM Matt Coster wrote:
> > Hi Adam,
> >
> > Thanks for these patches! I'll just reply to this one patch, but my
> > comments apply to them all.
> >
> > On 27/02/2024 03:45, Adam Ford wrote:
> > > The GPU on the RZ/
On Thu, 2024-03-07 at 12:26 +, Frank Binns wrote:
> On Tue, 2024-02-27 at 05:50 -0600, Adam Ford wrote:
> > On Tue, Feb 27, 2024 at 3:31 AM Matt Coster wrote:
> > > Hi Adam,
> > >
> > > Thanks for these patches! I'll just reply to this one patch, but my
> > > comments apply to them all.
> > >
Am 07.03.24 um 09:37 schrieb Khatri, Sunil:
On 3/7/2024 1:47 PM, Christian König wrote:
Am 06.03.24 um 19:19 schrieb Sunil Khatri:
Add page fault information to the devcoredump.
Output of devcoredump:
AMDGPU Device Coredump
version: 1
kernel: 6.7.0-amd-staging-drm-next
module: amdgp
Hi Adam,
On Mon, 2024-02-26 at 21:45 -0600, Adam Ford wrote:
> Update the binding to add support for various Renesas SoC's with PowerVR
> Rogue GX6250 and GX6650 GPUs. These devices only need one clock, so update
> the table to indicate such like what was done for the ti,am62-gpu.
>
> Signed-off
On 3/7/2024 6:10 PM, Christian König wrote:
Am 07.03.24 um 09:37 schrieb Khatri, Sunil:
On 3/7/2024 1:47 PM, Christian König wrote:
Am 06.03.24 um 19:19 schrieb Sunil Khatri:
Add page fault information to the devcoredump.
Output of devcoredump:
AMDGPU Device Coredump
version: 1
k
On Wed, 06 Mar 2024, Doug Anderson wrote:
> Hi,
>
> On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
>>
>> @@ -2764,58 +2764,71 @@ static u32 edid_extract_panel_id(const struct edid
>> *edid)
>> }
>>
>> /**
>> - * drm_edid_get_panel_id - Get a panel's ID through DDC
>> - * @adapter: I2C ada
On Wed, 06 Mar 2024, Doug Anderson wrote:
> Hi,
>
> On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
>>
>> drm_edid_get_panel_id() now just directly call edid_extract_panel_id().
>>
>> Merge them into one function.
>>
>> Signed-off-by: Hsin-Yi Wang
>> ---
>> v4->v5: new
>> ---
>> drivers/gpu
On Wed, 06 Mar 2024, Doug Anderson wrote:
> Hi,
>
> On Wed, Mar 6, 2024 at 4:20 PM Hsin-Yi Wang wrote:
>>
>> On Wed, Mar 6, 2024 at 3:30 PM Doug Anderson wrote:
>> >
>> > Hi,
>> >
>> > On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
>> > >
>> > > +static void
>> > > +match_identity(const st
On 06/03/2024 23:18, Vignesh Raman wrote:
Volteer devices in the collabora lab are categorized under the
asus-cx9400-volteer device type. The majority of these units
has an Intel Core i5-1130G7 CPU, while some of them have a
Intel Core i7-1160G7 CPU instead. So due to this difference,
new devi
On Wed, 06 Mar 2024, Doug Anderson wrote:
> Hi,
>
> On Wed, Mar 6, 2024 at 12:04 PM Hsin-Yi Wang wrote:
>>
>> @@ -1009,6 +1009,19 @@ static const struct panel_desc auo_b101ean01 = {
>> },
>> };
>>
>> +static const struct drm_display_mode auo_b116xa3_mode = {
>> + .clock = 70589,
>>
On Thu, Mar 7, 2024 at 6:37 AM Frank Binns wrote:
>
> On Thu, 2024-03-07 at 12:26 +, Frank Binns wrote:
> > On Tue, 2024-02-27 at 05:50 -0600, Adam Ford wrote:
> > > On Tue, Feb 27, 2024 at 3:31 AM Matt Coster
> > > wrote:
> > > > Hi Adam,
> > > >
> > > > Thanks for these patches! I'll just
On 06/03/2024 00:06, Vignesh Raman wrote:
zlib.net is not allowing tarball download anymore and results
in below error in kernel+rootfs_arm32 container build,
urllib.error.HTTPError: HTTP Error 403: Forbidden
urllib.error.HTTPError: HTTP Error 415: Unsupported Media Type
Uprev mesa which incl
On 06/03/2024 00:06, Vignesh Raman wrote:
Uprev IGT and add amd, v3d, vc4 and vgem specific
tests to testlist. Have testlist.txt per driver
and include a base testlist so that the driver
specific tests will run only on those hardware.
Also add testlists to the MAINTAINERS file.
Signed-off-by:
Hi,
Here's a series that creates some extra infrastructure specifically
targeted at HDMI controllers.
The idea behind this series came from a recent discussion on IRC during
which we discussed infoframes generation of i915 vs everything else.
Infoframes generation code still requires some decent
A lot of the various HDMI drivers duplicate some logic that depends on
the HDMI spec itself and not really a particular hardware
implementation.
Output BPC or format selection, infoframe generation are good examples
of such areas.
This creates a lot of boilerplate, with a lot of variations, which
We just introduced a new initialization function for our connectors, so
let's build a kunit test suite for it as well.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 123 +
1 file changed, 123 insertions(+)
We'll add automatic selection of the output BPC in a following patch,
but let's add it to the HDMI connector state already.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 5 +
drivers/gpu/drm/drm_atomic_state_helper.c | 20 +++
The next features we will need to share across drivers will need to
store some parameters for drivers to use, such as the selected output
format.
Let's create a new connector sub-state dedicated to HDMI controllers,
that will eventually store everything we need.
Reviewed-by: Dave Stevenson
Signe
Now that we're tracking the output bpc count in the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/Makefile | 1 +
.../gpu/drm/tests/drm_atomic_state_helper_test.c
Just like BPC, we'll add support for automatic selection of the output
format for HDMI connectors.
Let's add the needed defaults and fields for now.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c | 2 ++
drivers/gpu/drm/drm_atom
Now that we track the HDMI output format as part of the connector state,
let's add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 32 +++
drivers/gpu/drm/tests/drm_connector_tes
A lot of HDMI drivers have some variation of the formula to calculate
the TMDS character rate from a mode, but few of them actually take all
parameters into account.
Let's create a helper to provide that rate taking all parameters into
account.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime R
The previous patch added an helper to compute the TMDS character rate on
an HDMI connector. Let's add a few tests to make sure it works as
expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 323 +
1 fil
Most HDMI drivers have some code to calculate the TMDS character rate,
usually to adjust an internal clock to match what the mode requires.
Since the TMDS character rates mostly depends on the resolution, whether
we need to repeat pixels or not, the bpc count and the format, we can
now derive it f
The previous patch stores in the connector state the expected TMDS
character rate matching the configuration of the HDMI connector. Let's
add a few tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_tes
Most of the HDMI controllers have an upper TMDS character rate limit
they can't exceed. On "embedded"-grade display controllers, it will
typically be lower than what high-grade monitors can provide these days,
so drivers will filter the TMDS character rate based on the controller
capabilities.
To
The previous patch adds a new hook for HDMI connectors to filter out
configurations based on the TMDS character rate. Let's add some tests to
make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 65
Now that we have all the infrastructure needed, we can add some code
that will, for a given connector state and mode, compute the best output
format and bpc.
The algorithm is equivalent to the one already found in i915 and vc4.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic_state_h
The previous patch added the bpc and format an HDMI connector needs to
be set up with for a given connector state.
Let's add a few tests to make sure it works as expected.
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atomic_state_helper_test.c | 504 +
drivers/gp
The i915 driver has a property to force the RGB range of an HDMI output.
The vc4 driver then implemented the same property with the same
semantics. KWin has support for it, and a PR for mutter is also there to
support it.
Both drivers implementing the same property with the same semantics,
plus th
This had a bunch of kunit tests to make sure our code to handle the
Broadcast RGB property behaves properly.
This requires bringing a bit of infrastructure to create mock HDMI
connectors, with custom EDIDs.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests/drm_atom
HDMI controller drivers will need to figure out the RGB range they need
to configure based on a mode and property values. Let's expose that in
the HDMI connector state so drivers can just use that value.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_atomic.c
The previous commit added the infrastructure to the connector state to
track what RGB Quantization should be used in a given state for an HDMI
connector.
Let's add some kunit tests to make sure it works as expected.
Reviewed-by: Dave Stevenson
Signed-off-by: Maxime Ripard
---
.../gpu/drm/tests
Infoframes in KMS is usually handled by a bunch of low-level helpers
that require quite some boilerplate for drivers. This leads to
discrepancies with how drivers generate them, and which are actually
sent.
Now that we have everything needed to generate them in the HDMI
connector state, we can gen
The previous patch added the generation of the infoframes matching an
HDMI connector state. Let's add a few tests to make sure it works as
expected.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/drm_connector_test.c | 219 +
1 file changed, 219 insertions(+)
There has been some discussions recently about the infoframes sent by
drivers and if they were properly generated.
In parallel, there's been some interest in creating an infoframe-decode
tool similar to edid-decode.
Both would be much easier if we were to expose the infoframes programmed
in the h
The new HDMI connector infrastructure allows us to remove a lot of
boilerplate, so let's switch to it.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_hdmi.c | 638 +
drivers/gpu/drm/vc4/vc4_hdmi.h | 44 +--
drivers/gpu/drm/vc4/vc4_hdmi_phy.c
The vc4_dummy_plane structure was introduced as a mean to add
mock-specific fields.
However, we never really used it and it's still strictly equivalent to
vc4_plane (which is in the same situation vs drm_plane), so we can
simply remove the vc4_dummy_plane structure and make the mock code
cleaner.
Now that we have a plane create helper for kunit mocked drivers, let's
convert to it in vc4.
Reviewed-by: Maíra Canal
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/tests/vc4_mock_plane.c | 34 +++---
1 file changed, 8 insertions(+), 26 deletions(-)
diff --git a/d
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Heiko Stuebner
Acked-by: Heiko Stuebner
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/rockchip/inno_hdmi.c | 143 +--
The new HDMI connector infrastructure allows to remove some boilerplate,
especially to generate infoframes. Let's switch to it.
Reviewed-by: Jernej Skrabec
Acked-by: Sui Jingfeng
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 80 ++
1
Hi Dave, Sima,
this is the weekly PR for drm-misc-next-fixes.
Best regards
Thomas
drm-misc-next-fixes-2024-03-07:
Short summary of fixes pull:
- i915: Fix applying placement flags
- fbdev: Fix build on PowerMacs after header cleanup
The following changes since commit c6d6a82d8a9f8f9326b760accaa
On Wed, 06 Mar 2024, Maxime Ripard wrote:
> This URL gets redirected to the Intel landing page now. Let's switch the
> webpage to freedesktop.
>
> Signed-off-by: Maxime Ripard
> ---
> MAINTAINERS | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
>
On 06/03/2024 00:06, Vignesh Raman wrote:
For mediatek mt8173 and mt8183, the display driver is mediatek.
Currently, in drm-ci for mediatek, only the display driver is
tested. Refactor the existing mediatek jobs so that gpu driver
testing jobs can be added later and update xfails accordingly.
On 06/03/2024 00:06, Vignesh Raman wrote:
For Amlogic Meson SOC the display driver is meson. Currently,
in drm-ci for meson, only the display driver is tested.
Refactor the existing meson jobs so that gpu driver testing
jobs can be added later and update xfails accordingly.
Signed-off-by: Vig
On 06/03/2024 00:06, Vignesh Raman wrote:
For rockchip rk3288 and rk3399, the display driver is rockchip.
Currently, in drm-ci for rockchip, only the display driver is
tested. Refactor the existing rockchip jobs so that gpu driver
testing jobs can be added later and update xfails accordingly.
On 06/03/2024 00:06, Vignesh Raman wrote:
Some ARM SOCs have a separate display controller and GPU, each with
different drivers. For mediatek mt8173, the GPU driver is powervr,
and the display driver is mediatek. In the case of mediatek mt8183,
the GPU driver is panfrost, and the display drive
On Thu, Mar 7, 2024 at 6:41 AM Frank Binns wrote:
>
> Hi Adam,
>
> On Mon, 2024-02-26 at 21:45 -0600, Adam Ford wrote:
> > Update the binding to add support for various Renesas SoC's with PowerVR
> > Rogue GX6250 and GX6650 GPUs. These devices only need one clock, so update
> > the table to indic
On 3/7/24 9:09 AM, Sean Nyekjaer wrote:
Hi,
Hi,
We are using the stm32mp1 together with the sn65dsi83 bridge.
The ti,sn65dsi83 driver is (hard) enabling MIPI_DSI_MODE_VIDEO_BURST, then the
st,stm32-dsi driver is adding +20% to the clock speed.
That means our LVDS is +20% higher than expecte
On 07/03/2024 10:21, Helen Koike wrote:
On 06/03/2024 23:18, Vignesh Raman wrote:
Volteer devices in the collabora lab are categorized under the
asus-cx9400-volteer device type. The majority of these units
has an Intel Core i5-1130G7 CPU, while some of them have a
Intel Core i7-1160G7 CPU i
On 3/6/24 21:59, Mina Almasry wrote:
On Wed, Mar 6, 2024 at 11:14 AM Pavel Begunkov wrote:
On 3/6/24 17:04, Mina Almasry wrote:
On Wed, Mar 6, 2024 at 6:30 AM Pavel Begunkov wrote:
On 3/5/24 22:36, Mina Almasry wrote:
...
To be honest, I think it makes sense for the TCP stack to be
respons
On 07.03.24 09:09, Sean Nyekjaer wrote:
> Hi,
>
> We are using the stm32mp1 together with the sn65dsi83 bridge.
> The ti,sn65dsi83 driver is (hard) enabling MIPI_DSI_MODE_VIDEO_BURST, then
> the st,stm32-dsi driver is adding +20% to the clock speed.
>
> That means our LVDS is +20% higher than ex
1 - 100 of 215 matches
Mail list logo
