Zhenyu Wang 于2022年12月21日周三 11:01写道：
>
> On 2022.12.20 17:40:14 +0800, Zheng Wang wrote:
> > If intel_gvt_dma_map_guest_page failed, it will call
> > ppgtt_invalidate_spt, which will finally free the spt. But the
> > caller function ppgtt_populate_spt_by_guest_entry does not notice
> > that, it
The busy timeout logic checks for the AUX BUSY, then waits for the
timeout period and then after timeout reads the register for BUSY or
Success.
Instead replace interrupt with polling so as to read the AUX CTL
register often before the timeout period. Looks like there might be some
issue with
On 2022.12.20 17:40:14 +0800, Zheng Wang wrote:
> If intel_gvt_dma_map_guest_page failed, it will call
> ppgtt_invalidate_spt, which will finally free the spt. But the
> caller function ppgtt_populate_spt_by_guest_entry does not notice
> that, it will free spt again in its error path.
indent
Ignore this, use rev2 instead, apologies for the mistake.
On Tue, 2022-12-20 at 14:03 -0800, Teres Alexis, Alan Previn wrote:
> If PXP arb-session is being attempted on older hardware SKUs or
> on hardware with older, unsupported, firmware versions, then don't
> report the failure with a
If PXP arb-session is being attempted on older hardware SKUs or
on hardware with older, unsupported, firmware versions, then don't
report the failure with a drm_error. Instead, look specifically for
the API-version error reply and drm_dbg that reply. In this case, the
user-space will eventually
If PXP arb-session is being attempted on older hardware SKUs or
on hardware with older, unsupported, firmware versions, then don't
report the failure with a drm_error. Instead, look specifically for
the API-version error reply and drm_dbg that reply. In this case, the
user-space will eventually
On 20.12.2022 18.29, Stanislav Lisovskiy wrote:
We have some Tile4 tests now skipping, which were
supposed to be working. So lets make them work, by
adding display_ver 14 as supported.
v2: - Remove "14" for Tile 4 CCS formats, as they
seem to be not supported by DG2(Juha-Pekka Heikkila)
On Tue, Dec 20, 2022 at 02:07:24PM +0200, Luca Coelho wrote:
> From: Animesh Manna
>
> As part of die area reduction max input source modified to 4096
> for MTL so modified range check logic of scaler.
>
> Signed-off-by: Jos? Roberto de Souza
> Signed-off-by: Animesh Manna
> Signed-off-by:
On Tue, Dec 20, 2022 at 02:07:23PM +0200, Luca Coelho wrote:
> In newer hardware versions (i.e. display version >= 14), the second
> scaler doesn't support vertical scaling.
>
> The current implementation of the scaling limits is simplified and
> only occurs when the planes are created, so we
On Tue, 20 Dec 2022, "Murthy, Arun R" wrote:
>> -Original Message-
>> From: Nikula, Jani
>> Sent: Tuesday, December 20, 2022 9:33 PM
>> To: Murthy, Arun R ; intel-
>> g...@lists.freedesktop.org; ville.syrj...@linux.intel.com; Deak, Imre
>>
>> Subject: RE: [PATCHv6] drm/i915/dp: change
As we do not require specific versions anymore, change the convention
for blob filenames to stop using version numbers. This simplifies code
maintenance, since we do not need to keep updating blob paths for new
DMC releases, and also makes DMC loading compatible with systems that do
not have the
Currently there is no DMC version requirement with respect to how i915
interacts with it and new versions of the firmware serve as drop-in
replacements of older ones. As such, do not require specific versions.
References: https://lore.kernel.org/r/y3081s7c5ksut...@intel.com
Signed-off-by: Gustavo
This patch series changes DMC loading to be backwards-compatible by removing
version checking and loading blobs from unversioned filenames.
Should this be accepted, the next step would be to update linux-firmware to
start using the unversioned filenames. That said, this change still allows to
use
On Tue 2022-12-20 13:45:19, Steven Rostedt wrote:
> [
> Linus,
>
> I ran the script against your latest master branch:
> commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
>
> As the timer_shutdown*() code is now in your tree, I figured
> we can start doing the conversions. At
On Tue, Dec 20, 2022 at 02:40:47PM +0200, Jani Nikula wrote:
> On Tue, 20 Dec 2022, Maarten Lankhorst
> wrote:
> > We enable the DP aux channel during probe, but may free the connector
> > soon afterwards. Ensure the DP aux display power put is completed before
> > everything is freed, to
[
Linus,
I ran the script against your latest master branch:
commit b6bb9676f2165d518b35ba3bea5f1fcfc0d969bf
As the timer_shutdown*() code is now in your tree, I figured
we can start doing the conversions. At least add the trivial ones
now as Thomas suggested that this gets
On Tue, Dec 20, 2022 at 07:53:06PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 29, 2022 at 02:43:02PM +0200, Jouni Högander wrote:
> > After splitting generic drm_fb_helper into it's own file it's left to
> > helper implementation to have fb_dirty function. Currently intel
> > fb doesn't have it.
On Tue, Nov 29, 2022 at 02:43:02PM +0200, Jouni Högander wrote:
> After splitting generic drm_fb_helper into it's own file it's left to
> helper implementation to have fb_dirty function. Currently intel
> fb doesn't have it. This is causing problems when PSR is enabled.
>
> Implement simple
> -Original Message-
> From: Nikula, Jani
> Sent: Tuesday, December 20, 2022 9:33 PM
> To: Murthy, Arun R ; intel-
> g...@lists.freedesktop.org; ville.syrj...@linux.intel.com; Deak, Imre
>
> Subject: RE: [PATCHv6] drm/i915/dp: change aux_ctl reg read to polling read
>
> On Mon, 19 Dec
We have some Tile4 tests now skipping, which were
supposed to be working. So lets make them work, by
adding display_ver 14 as supported.
v2: - Remove "14" for Tile 4 CCS formats, as they
seem to be not supported by DG2(Juha-Pekka Heikkila)
- For generic Tile 4, the opposite - lets use
On Mon, 19 Dec 2022, "Murthy, Arun R" wrote:
> Any comments?
>From #intel-gfx:
bashing the hw for 500 usec seems a bit harsh
Which is true. The default for intel_de_wait_for_register() is 2
us. Should probably stick to that.
BR,
Jani.
>
> Thanks and Regards,
> Arun R Murthy
>
Hi,
On 20/12/2022 15:22, srinivas pandruvada wrote:
+Added DRM mailing list and maintainers
On Tue, 2022-12-20 at 15:33 +0100, Mirsad Todorovac wrote:
Hi all,
I have been unsuccessful to find any particular Intel i915 maintainer
emails, so my best bet is to post here, as you will must
On Tue, Dec 20, 2022 at 11:32 AM Ville Syrjälä
wrote:
>
> On Mon, Dec 19, 2022 at 06:29:27PM +0100, Sasa Dragic wrote:
> > RC6p on Sandy Bridge got re-enabled over time, causing visual glitches
> > and GPU hangs.
> >
> > Disabled originally in commit 1c8ecf80fdee ("drm/i915: do not enable
> >
+Added DRM mailing list and maintainers
On Tue, 2022-12-20 at 15:33 +0100, Mirsad Todorovac wrote:
> Hi all,
>
> I have been unsuccessful to find any particular Intel i915 maintainer
> emails, so my best bet is to post here, as you will must assuredly
> already know them.
>
> The problem is a
On Tue, Dec 20, 2022 at 04:01:05PM +0200, Jani Nikula wrote:
> Due to copy-paste fail, MIPI_BKLT_EN_1 would always use PPS index 1,
> never 0. Fix the sloppiest commit in recent memory.
>
> Fixes: f087cfe6fcff ("drm/i915/dsi: add support for ICL+ native MIPI GPIO
> sequence")
> Reported-by:
Due to copy-paste fail, MIPI_BKLT_EN_1 would always use PPS index 1,
never 0. Fix the sloppiest commit in recent memory.
Fixes: f087cfe6fcff ("drm/i915/dsi: add support for ICL+ native MIPI GPIO
sequence")
Reported-by: Ville Syrjälä
Signed-off-by: Jani Nikula
---
On Tue, 20 Dec 2022, Ville Syrjälä wrote:
> On Tue, Dec 20, 2022 at 02:52:01PM +0200, Jani Nikula wrote:
>> On Tue, 20 Dec 2022, Ville Syrjälä wrote:
>> > On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
>> >> By moving update_display_info() out of _drm_edid_connector_update() we
>>
On Tue, Dec 20, 2022 at 02:52:01PM +0200, Jani Nikula wrote:
> On Tue, 20 Dec 2022, Ville Syrjälä wrote:
> > On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
> >> By moving update_display_info() out of _drm_edid_connector_update() we
> >> make the function purely about adding modes.
>
On Tue, 20 Dec 2022, Ville Syrjälä wrote:
> On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
>> By moving update_display_info() out of _drm_edid_connector_update() we
>> make the function purely about adding modes.
>
> I don't think that's quite true. The 4:2:0 stuff still updates
>
On Tue, 20 Dec 2022, Maarten Lankhorst
wrote:
> We enable the DP aux channel during probe, but may free the connector
> soon afterwards. Ensure the DP aux display power put is completed before
> everything is freed, to prevent a use-after-free in icl_aux_pw_to_phy(),
> called from
On Fri, Dec 16, 2022 at 06:00:20PM +0200, Jani Nikula wrote:
> By moving update_display_info() out of _drm_edid_connector_update() we
> make the function purely about adding modes.
I don't think that's quite true. The 4:2:0 stuff still updates
various display_info things from the mode parsing
From: Animesh Manna
As part of die area reduction max input source modified to 4096
for MTL so modified range check logic of scaler.
Signed-off-by: Jos� Roberto de Souza
Signed-off-by: Animesh Manna
Signed-off-by: Luca Coelho
---
drivers/gpu/drm/i915/display/skl_scaler.c | 31
In newer hardware versions (i.e. display version >= 14), the second
scaler doesn't support vertical scaling.
The current implementation of the scaling limits is simplified and
only occurs when the planes are created, so we don't know which scaler
is being used.
In order to handle separate
Hi,
I stupidly sent an old version of the patches in my v5... Resending
the correct ones (which were sent as v4).
The versioning history is in the patches themselves.
Please review.
Cheers,
Luca.
Animesh Manna (1):
drm/i915/mtl: Limit scaler input to 4k in plane scaling
Luca Coelho (1):
The helper makes the code more compact and readable.
Signed-off-by: Andrzej Hajda
---
drivers/gpu/drm/i915/display/g4x_dp.c | 12 ++--
drivers/gpu/drm/i915/display/g4x_hdmi.c | 8 +--
.../gpu/drm/i915/display/intel_backlight.c| 59 +++
The helper makes the code more compact and readable.
Signed-off-by: Andrzej Hajda
---
Hi all,
This is the last patchset converting different flavours
of register updates to intel_de_rmw. There are probably
still some remnants, which would require functional changes
to allow conversion. They
On Tue, 2022-12-20 at 13:09 +0200, Ville Syrjälä wrote:
> On Tue, Dec 20, 2022 at 10:11:16AM +0200, Luca Coelho wrote:
> > In newer hardware versions (i.e. display version >= 14), the second
> > scaler doesn't support vertical scaling.
> >
> > The current implementation of the scaling limits is
This was mostly needed to differentiate between mappable and
non-mappable lmem, such that ttm would understand non-mappable ->
mappable moves (or vice versa), and not just turn them into noops. We
have since gained proper .intersects() and .compatible() hooks for the
resource manager, which takes
On Mon, Dec 19, 2022 at 09:29:19AM +0200, Stanislav Lisovskiy wrote:
> There was a specific SW workaround requested, which should prevent
> some watermark issues happening, which requires copying highest
> enabled wm level to those disabled wm levels(bit 31 is of course
> still needs to be
On 12/20/2022 3:41 AM, john.c.harri...@intel.com wrote:
From: John Harrison
In the case where a firmware file is too large (e.g. someone
downloaded a web page ASCII dump from github...), the firmware object
is released but the pointer is not zerod. If no other firmware file
was found then
On 12/20/2022 2:31 PM, Jani Nikula wrote:
On Tue, 20 Dec 2022, Ankit Nautiyal wrote:
There are cases, where devices have an HDMI1.4 retimer, and TMDS clock rate
is capped to 340MHz via VBT. In such cases scrambling might be supported
by the platform and an HDMI2.0 sink for lower TMDS rates,
On Tue, Dec 20, 2022 at 12:39:17PM +0200, Ville Syrjälä wrote:
> On Thu, Dec 15, 2022 at 03:51:50PM +, Simon Ser wrote:
> > In intel_dp_mst_atomic_master_trans_check(), we pull connectors
> > sharing the same DP-MST stream into the atomic state. However,
> > if the connector is unregistered,
On Tue, Dec 20, 2022 at 10:11:16AM +0200, Luca Coelho wrote:
> In newer hardware versions (i.e. display version >= 14), the second
> scaler doesn't support vertical scaling.
>
> The current implementation of the scaling limits is simplified and
> only occurs when the planes are created, so we
We should still be able to GTT evict objects during execbuf (old
bindings can linger around), even if there is object lock contention. In
the worst case the execbuf should just wait on the contented locks.
Returning -ENOSPC smells like a regression from past behaviour, and
seems to break
On Mon, Dec 19, 2022 at 12:59:55PM +0200, Jani Nikula wrote:
> Starting from ICL, the default for MIPI GPIO sequences seems to be using
> native GPIOs i.e. GPIOs available in the GPU. These native GPIOs reuse
> many pins that quite frankly seem scary to poke based on the VBT
> sequences. We pretty
On Thu, Dec 15, 2022 at 03:51:50PM +, Simon Ser wrote:
> In intel_dp_mst_atomic_master_trans_check(), we pull connectors
> sharing the same DP-MST stream into the atomic state. However,
> if the connector is unregistered, this later fails with:
>
> [ 559.425658] i915 :00:02.0:
On 12/19/2022 8:04 PM, Andrzej Hajda wrote:
On 19.12.2022 12:29, Nirmoy Das wrote:
Use i915_coherent_map_type() function to find out
map_type of the shmem obj.
v2: handle non-llc platform(Matt)
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/shmem_utils.c | 7 +--
1 file
On Mon, Dec 19, 2022 at 06:29:27PM +0100, Sasa Dragic wrote:
> RC6p on Sandy Bridge got re-enabled over time, causing visual glitches
> and GPU hangs.
>
> Disabled originally in commit 1c8ecf80fdee ("drm/i915: do not enable
> RC6p on Sandy Bridge").
re cover letter:
> It was originally disabled
On Mon, Dec 19, 2022 at 08:27:30PM +0200, Juha-Pekka Heikkila wrote:
> Hi Stan,
>
> On 19.12.2022 15.50, Stanislav Lisovskiy wrote:
> > We have some Tile4 tests now skipping, which were
> > supposed to be working. So lets make them work, by
> > adding display_ver 14 as supported.
> >
> >
We enable the DP aux channel during probe, but may free the connector
soon afterwards. Ensure the DP aux display power put is completed before
everything is freed, to prevent a use-after-free in icl_aux_pw_to_phy(),
called from icl_combo_phy_aux_power_well_disable.
Signed-off-by: Maarten
On 12/19/22 17:05, Thomas Zimmermann wrote:
> There are no users left of struct fb_info.apertures and the flag
> FBINFO_MISC_FIRMWARE. Remove both and the aperture-ownership code
> in the fbdev core. All code for aperture ownership is now located
> in the fbdev drivers.
>
> Signed-off-by: Thomas
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Acquire ownership of the firmware scanout buffer by calling Linux'
> aperture helpers. Remove the use of struct fb_info.apertures and do
> not set FBINFO_MISC_FIRMWARE; both of which previously configured
> buffer ownership.
>
> Signed-off-by: Thomas
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Acquire ownership of the firmware scanout buffer by calling Linux'
> aperture helpers. Remove the use of struct fb_info.apertures and do
> not set FBINFO_MISC_FIRMWARE; both of which previously configured
> buffer ownership.
>
> Signed-off-by: Thomas
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Acquire ownership of the firmware scanout buffer by calling Linux'
> aperture helpers. Remove the use of struct fb_info.apertures and do
> not set FBINFO_MISC_FIRMWARE; both of which previously configured
> buffer ownership.
>
> Signed-off-by: Thomas
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Acquire ownership of the firmware scanout buffer by calling Linux'
> aperture helpers. Remove the use of struct fb_info.apertures and do
> not set FBINFO_MISC_FIRMWARE; both of which previously configured
> buffer ownership.
>
> Signed-off-by: Thomas
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Move the palette array into struct offb_par and allocate both via
> framebuffer_alloc(), as intended by fbdev. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Acquire ownership of the firmware scanout buffer by calling Linux'
> aperture helpers. Remove the use of struct fb_info.apertures and do
> not set FBINFO_MISC_FIRMWARE; both of which previously configured
> buffer ownership.
>
> Signed-off-by: Thomas
On 12/19/22 17:05, Thomas Zimmermann wrote:
> The efifb_par structure holds the palette for efifb. It will also
> be useful for storing the device's aperture range.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
[adding Kirti Wankhede and k...@vger.kernel.org to Cc list]
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in mdpy-fb.
>
> Signed-off-by:
On Mon, 19 Dec 2022, Andrzej Hajda wrote:
> The helper makes the code more compact and readable.
>
> Signed-off-by: Andrzej Hajda
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/icl_dsi.c | 256 -
> 1 file changed, 82 insertions(+), 174 deletions(-)
>
>
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in hyperv-fb.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in clps711x-fb.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez
On 12/19/22 17:05, Thomas Zimmermann wrote:
> The apertures field in struct fb_info is not used by DRM drivers. Do
> not allocate it.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in radeon.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in i915.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
On 12/19/22 17:05, Thomas Zimmermann wrote:
> Generic fbdev drivers use the apertures field in struct fb_info to
> control ownership of the framebuffer memory and graphics device. Do
> not set the values in gma500.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
On 12/19/22 17:05, Thomas Zimmermann wrote:
> This reverts commit ae1287865f5361fa138d4d3b1b6277908b54eac9.
>
> Always free the console font when deinitializing the framebuffer
> console. Subsequent framebuffer consoles will then use the default
> font. Rely on userspace to load any
On 12/19/22 17:04, Thomas Zimmermann wrote:
> Fix coding style. No functional changes.
>
> Signed-off-by: Thomas Zimmermann
> ---
Reviewed-by: Javier Martinez Canillas
--
Best regards,
Javier Martinez Canillas
Core Platforms
Red Hat
Zhenyu Wang 于2022年12月20日周二 16:25写道：
>
> On 2022.12.19 20:52:04 +0800, Zheng Wang wrote:
> > If intel_gvt_dma_map_guest_page failed, it will call
> > ppgtt_invalidate_spt, which will finally free the spt. But the caller does
> > not notice that, it will free spt again in error path.
> >
>
> It's
On Tue, 20 Dec 2022, Ankit Nautiyal wrote:
> There are cases, where devices have an HDMI1.4 retimer, and TMDS clock rate
> is capped to 340MHz via VBT. In such cases scrambling might be supported
> by the platform and an HDMI2.0 sink for lower TMDS rates, but not
> supported by the retimer,
On Wed, 14 Dec 2022, Suraj Kandpal wrote:
> From: Anshuman Gupta
>
> Change the include/drm/i915_mei_hdcp_interface.h to
> include/drm/i915_cp_fw_hdcp_interface.h
This is now stale.
>
> Cc: Tomas Winkler
> Cc: Rodrigo Vivi
> Cc: Uma Shankar
> Cc: Ankit Nautiyal
> Signed-off-by: Anshuman
On 2022.12.20 16:41:15 +1300, Paulo Miguel Almeida wrote:
> One-element arrays are deprecated, and we are replacing them with
> flexible array members instead. So, replace one-element array with
> flexible-array member in struct gvt_firmware_header and refactor the
> rest of the code accordingly.
From: Animesh Manna
As part of die area reduction max input source modified to 4096
for MTL so modified range check logic of scaler.
Signed-off-by: José Roberto de Souza
Signed-off-by: Animesh Manna
Signed-off-by: Luca Coelho
---
drivers/gpu/drm/i915/display/skl_scaler.c | 31
On 2022.12.19 20:52:04 +0800, Zheng Wang wrote:
> If intel_gvt_dma_map_guest_page failed, it will call
> ppgtt_invalidate_spt, which will finally free the spt. But the caller does
> not notice that, it will free spt again in error path.
>
It's not clear from this description which caller is
From: Animesh Manna
As part of die area reduction max input source modified to 4096
for MTL so modified range check logic of scaler.
Signed-off-by: Jose Roberto de Souza
Signed-off-by: Animesh Manna
Signed-off-by: Luca Coelho
---
In v2:
* No changes;
In v3:
* Removed stray
In newer hardware versions (i.e. display version >= 14), the second
scaler doesn't support vertical scaling.
The current implementation of the scaling limits is simplified and
only occurs when the planes are created, so we don't know which scaler
is being used.
In order to handle separate
Hi,
I'm resending this series with a cover letter, because the patches
didn't seem to arrive in patchwork as they should.
The versioning history is in the patches themselves.
Please review.
Cheers,
Luca.
Animesh Manna (1):
drm/i915/mtl: Limit scaler input to 4k in plane scaling
Luca
78 matches
Mail list logo
