On Wed, 2022-02-16 at 10:50 +0200, Ville Syrjälä wrote:
> On Tue, Feb 15, 2022 at 11:21:54AM +0530, Ramalingam C wrote:
> > From: Jouni Högander
> >
> > Currently ICL_PHY_MISC macro is returning offset 0x64C10 for PHY_E
> > port. Correct offset is 0x64C14.
>
> Why is it PHY_E and not PHY_F?
On Wed, 2022-02-16 at 12:07 +0200, Ville Syrjälä wrote:
> On Wed, Feb 16, 2022 at 09:36:02AM +0000, Hogander, Jouni wrote:
> > On Wed, 2022-02-16 at 10:50 +0200, Ville Syrjälä wrote:
> > > On Tue, Feb 15, 2022 at 11:21:54AM +0530, Ramalingam C wrote:
> >
Hello Paul,
On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> As we've unfortunately started to come to expect from PSR on Intel
> platforms, PSR2 selective fetch is not at all ready to be enabled on
> Tigerlake as it results in severe flickering issues - at least on
> this
> ThinkPad X1
On Tue, 2023-09-05 at 13:05 +0530, Animesh Manna wrote:
> Modify existing PSR implementation to enable panel replay feature of
> DP 2.0
> which is similar to PSR feature of EDP panel. There is different DPCD
> address to check panel capability compare to PSR and vsc sdp header
> is different.
>
>
On Tue, 2023-10-31 at 23:21 +, Paz Zcharya wrote:
> Currently, i915 fails fastset if both the sink and the source support
> any version of PSR and regardless of the configuration setting of the
> driver (i.e., i915.enable_psr kernel argument). However, the
> implementation of PSR1 enable
On Wed, 2023-11-01 at 09:11 +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 25.10.23 um 10:36 schrieb Hogander, Jouni:
> > Hi Thomas, One minor comment inline below.
>
> Thank you so much for taking the time to review these patches.
>
> >
> > On Wed, 2023-09-
On Wed, 2023-10-11 at 16:39 +0530, Animesh Manna wrote:
> Add debugfs support which will print source and sink status
> per connector basis.
Sorry for late review. Noticed only by now that you have added this
patch into you set.
Can you please describe in commit message how you see the output of
On Fri, 2023-11-03 at 06:10 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Thursday, November 2, 2023 1:08 PM
> > To: Manna, Animesh ; intel-
> > g...@lists.freedesktop.org
> > Cc: dri-devel@lists.fr
On Tue, 2023-11-07 at 05:01 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Monday, November 6, 2023 1:33 PM
> > To: dri-devel@lists.freedesktop.org; Manna, Animesh
> > ; intel-...@lists.freedesktop.org
&
On Wed, 2023-09-27 at 12:26 +0200, Thomas Zimmermann wrote:
> Unregister all in-kernel clients before unloading the i915 driver.
> For
> other drivers, drm_dev_unregister() does this automatically. As i915
> does not use this helper, it has to perform the call by itself.
>
> Note that there are
On Wed, 2023-09-27 at 12:26 +0200, Thomas Zimmermann wrote:
> Move functions within intel_fbdev.c to simplify later updates. Minor
> style fixes to make checkpatch happy, but no functional changes.
>
> v5:
> * style fixes (checkpatch)
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by:
Hello Animesh,
Thank you for the changes. Now the patch is much shorter, cleaner and
easier to review. See my inline comments below.
On Sat, 2023-11-04 at 02:30 +0530, Animesh Manna wrote:
> Add debugfs support which will print source and sink status
> per connector basis. Existing
Hi Thomas, One minor comment inline below.
On Wed, 2023-09-27 at 12:26 +0200, Thomas Zimmermann wrote:
> Initialize i915's fbdev client by giving an instance of struct
> drm_client_funcs to drm_client_init(). Also clean up with
> drm_client_release().
>
> Doing this in i915 prevents fbdev
Hi Thomas, couple of inline commments/suggestions below.
On Wed, 2023-09-27 at 12:26 +0200, Thomas Zimmermann wrote:
> Move code from ad-hoc fbdev callbacks into DRM client functions
> and remove the old callbacks. The functions instruct the client
> to poll for changed output or restore the
Hi Thomas, couple of minor comments and a question below.
On Wed, 2023-09-27 at 12:26 +0200, Thomas Zimmermann wrote:
> Replace all code that initializes or releases fbdev emulation
> throughout the driver. Instead initialize the fbdev client by a
> single call to i915_fbdev_setup() after i915
On Fri, 2022-04-29 at 19:34 -0400, Lyude Paul wrote:
> Cool! Tested this on three different laptops, and it seems to work
> great on
> all of them. so, this series is:
>
> Tested-by: Lyude Paul
Thank you all for review/testing support. I will come back with updated
patch set later.
>
> Would
On Fri, 2022-08-19 at 09:09 -0300, Maíra Canal wrote:
> Hi Jouni,
>
> On 7/15/22 10:49, Jouni Högander wrote:
> > drm_plane_state->src might be modified by the driver. This is done
> > e.g. in i915 driver when there is bigger framebuffer than the plane
> > and there is some offset within
On Thu, 2022-08-11 at 18:23 +0200, Daniel Vetter wrote:
> On Fri, Jul 15, 2022 at 04:49:56PM +0300, Jouni Högander wrote:
> > drm_plane_state->src might be modified by the driver. This is done
> > e.g. in i915 driver when there is bigger framebuffer than the plane
> > and there is some offset
On Tue, 2022-09-13 at 12:04 +0300, Ville Syrjälä wrote:
> On Tue, Aug 23, 2022 at 02:29:16PM +0300, Jouni Högander wrote:
> > Currently damage clips handling is broken for planes when using big
> > framebuffer + offset in case kms driver adjusts drm_plane_state.src
> > coords. This is because
On Wed, 2022-12-21 at 13:05 +0100, Thomas Zimmermann wrote:
> Hi
>
> Am 21.12.22 um 12:19 schrieb Jouni Högander:
> > Checking if damage clip is valid is common to all fb helpers.
> > Makes more sense to check it in higher level than adding into
> > all helpers.
>
> It was a deliberate decision
On Mon, 2023-03-06 at 22:58 +0200, Ville Syrjälä wrote:
> On Mon, Mar 06, 2023 at 09:23:50PM +0100, Maarten Lankhorst wrote:
> > Hey,
> >
> > On 2023-03-06 16:23, Souza, Jose wrote:
> > > On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote:
> > > > As a fallback if we decide not to merge
On Fri, 2023-02-17 at 09:18 -0800, John Harrison wrote:
> On 2/17/2023 00:39, Hogander, Jouni wrote:
> > On Wed, 2023-02-15 at 17:10 -0800, john.c.harri...@intel.com wrote:
> > > From: John Harrison
> > >
> > > Instruction from hardware arch is that
On Thu, 2023-02-23 at 20:02 +0100, Werner Sembach wrote:
>
> Am 23.02.23 um 19:56 schrieb Werner Sembach:
> >
> > Am 23.02.23 um 19:26 schrieb Hogander, Jouni:
> > > On Wed, 2023-02-22 at 15:17 +0100, Werner Sembach wrote:
> > > > On these Barebones PSR 2
On Wed, 2023-02-22 at 15:13 -0500, Rodrigo Vivi wrote:
> On Wed, Feb 22, 2023 at 03:17:55PM +0100, Werner Sembach wrote:
> > On these Barebones PSR 2 is recognized as supported but is very
> > buggy:
> > - Upper third of screen does sometimes not updated, resulting in
> > disappearing cursors or
On Wed, 2023-02-22 at 15:17 +0100, Werner Sembach wrote:
> On these Barebones PSR 2 is recognized as supported but is very
> buggy:
> - Upper third of screen does sometimes not updated, resulting in
> disappearing cursors or ghosts of already closed Windows saying
> behind.
> - Approximately 40 px
On Wed, 2023-02-15 at 17:10 -0800, john.c.harri...@intel.com wrote:
> From: John Harrison
>
> Instruction from hardware arch is that stolen memory and BAR mappings
> are unsafe for use as ring buffers. There can be issues with cache
> aliasing due to the CPU access going to memory via the BAR.
On Thu, 2023-03-09 at 14:34 +0200, Ville Syrjälä wrote:
> On Thu, Mar 09, 2023 at 12:09:55PM +0100, Maarten Lankhorst wrote:
> >
> > On 2023-03-09 12:04, Hogander, Jouni wrote:
> > > On Mon, 2023-03-06 at 22:58 +0200, Ville Syrjälä wrote:
> > > > On Mon, Mar 0
On Tue, 2023-04-04 at 23:26 +0200, Das, Nirmoy wrote:
>
> On 4/4/2023 8:27 PM, Ville Syrjälä wrote:
> > On Tue, Apr 04, 2023 at 08:13:42PM +0200, Nirmoy Das wrote:
> > > Stolen memory is not usable for MTL A0 stepping beyond
> > > certain access size and we have no control over userspace
> > >
Hello All,
I accidentally pushed this patch into drm-intel/drm-intel-next.
Hopefully this doesn't cause problems. I'm very sorry for
inconvenience.
Best Regards,
Jouni Högander
On Wed, 2024-01-03 at 10:46 +, Kahola, Mika wrote:
> > -Original Message-
> > From: Intel-gfx On Behalf
On Thu, 2024-01-04 at 12:59 +0200, Dmitry Baryshkov wrote:
> On Thu, 4 Jan 2024 at 12:49, Jouni Högander
> wrote:
> >
> > Add definitions for panel replay selective update
> >
> > Cc: dri-devel@lists.freedesktop.org
> >
>
> 1) This CC should not be necessary. It is already a part of
>
On Mon, 2023-12-04 at 14:49 +0100, Maarten Lankhorst wrote:
> Works better for xe like that. obj is no longer const.
>
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Jouni Högander
> ---
> drivers/gpu/drm/i915/display/intel_cursor.c | 6 --
> 1 file changed, 4 insertions(+), 2
On Tue, 2024-01-23 at 12:28 +0200, Imre Deak wrote:
> Add support for Display Port DP tunneling. For now this includes the
> support for Bandwidth Allocation Mode, leaving adding Panel Replay
> support for later.
>
> BWA allows using displays that share the same (Thunderbolt) link with
> their
On Tue, 2024-01-23 at 12:28 +0200, Imre Deak wrote:
> On shared (Thunderbolt) links with DP tunnels, the modeset may need
> to
> be retried on all connectors on the link due to a link BW limitation
> arising only after the atomic check phase. To support this add a
> helper
> function queuing a
On Wed, 2023-11-08 at 12:53 +0530, Animesh Manna wrote:
> Add debugfs support which will print source and sink status
> per connector basis. Existing i915_psr_status and
> i915_psr_sink_status will be used to get the source and
> sink status of panel replay.
>
> v1: Initial version. [rb-ed by
On Fri, 2024-04-05 at 10:59 +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 05.04.24 um 10:34 schrieb Hogander, Jouni:
> [...]
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > > b/drivers/gpu/drm/i915/i915_driver.c
> > > index e0f13c6
On Fri, 2024-03-01 at 14:42 +0100, Thomas Zimmermann wrote:
> Replace all code that initializes or releases fbdev emulation
> throughout the driver. Instead initialize the fbdev client by a
> single call to intel_fbdev_setup() after i915 has registered its
> DRM device. Just like similar code in
On Fri, 2024-03-01 at 14:42 +0100, Thomas Zimmermann wrote:
> Move code from ad-hoc fbdev callbacks into DRM client functions
> and remove the old callbacks. The functions instruct the client
> to poll for changed output or restore the display.
>
> The DRM core calls both, the old callbacks and
On Fri, 2024-03-01 at 14:42 +0100, Thomas Zimmermann wrote:
> Initialize i915's fbdev client by giving an instance of struct
> drm_client_funcs to drm_client_init(). Also clean up with
> drm_client_release().
>
> Doing this in i915 prevents fbdev helpers from initializing and
> releasing the
On Tue, 2024-04-09 at 10:04 +0200, Thomas Zimmermann wrote:
> Replace all code that initializes or releases fbdev emulation
> throughout the driver. Instead initialize the fbdev client by a
> single call to intel_fbdev_setup() after i915 has registered its
> DRM device. Just like similar code in
On Tue, 2024-04-09 at 10:04 +0200, Thomas Zimmermann wrote:
> Export drm_client_dev_unregister() for use by the i915 driver. The
> driver does not use drm_dev_unregister(), so it has to clean up the
> in-kernel DRM clients by itself.
>
> Signed-off-by: Thomas Zimmermann
Reviewed-by: Jouni
On Tue, 2024-04-09 at 10:04 +0200, Thomas Zimmermann wrote:
> Unregister all in-kernel clients before unloading the i915 driver.
> For
> other drivers, drm_dev_unregister() does this automatically. As i915
> and
> xe do not use this helper, they have to perform the call by
> themselves.
>
> Note
On Tue, 2024-04-16 at 08:15 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Monday, April 15, 2024 3:36 PM
> > To: Manna, Animesh ; intel-
> > g...@lists.freedesktop.org
> > Cc: dri-devel@lists.fr
On Tue, 2024-04-16 at 08:20 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Monday, April 15, 2024 3:39 PM
> > To: Manna, Animesh ; intel-
> > g...@lists.freedesktop.org
> > Cc: dri-devel@lists.fr
On Fri, 2024-04-12 at 21:22 +0530, Animesh Manna wrote:
> Set the Link Off Between Frames Enable bit in ALPM_CTL register.
>
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_alpm.c | 5 +
> drivers/gpu/drm/i915/display/intel_display_types.h | 1 +
> 2 files
On Fri, 2024-04-12 at 21:22 +0530, Animesh Manna wrote:
> For validation purpose add debugfs for LOBF.
>
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_alpm.c | 47
> +++
> drivers/gpu/drm/i915/display/intel_alpm.h | 2 +
>
On Fri, 2024-04-12 at 21:22 +0530, Animesh Manna wrote:
> Link Off Between Active Frames, is a new feature for eDP
> that allows the panel to go to lower power state after
> transmission of data. This is a feature on top of ALPM, AS SDP.
> Add compute config during atomic-check phase.
>
> v1: RFC
On Tue, 2024-04-23 at 13:13 +0200, Thomas Zimmermann wrote:
> Hi
>
> Am 22.04.24 um 16:11 schrieb Hogander, Jouni:
> > On Tue, 2024-04-09 at 10:04 +0200, Thomas Zimmermann wrote:
> > > Replace all code that initializes or releases fbdev emulation
> > > througho
On Fri, 2024-05-10 at 12:38 +0300, Jouni Högander wrote:
> This patch set is implementing panel replay selective update support
> for Intel hardware.
These are now merged into drm-intel-next including "drm/panelreplay:
dpcd register definition for panelreplay SU".
Thank you Animesh and Maarten
On Fri, 2024-05-03 at 08:19 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Friday, May 3, 2024 1:18 PM
> > To: Manna, Animesh ; intel-
> > g...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesk
On Thu, 2024-04-25 at 00:08 +0530, Animesh Manna wrote:
> Link Off Between Active Frames, is a new feature for eDP
> that allows the panel to go to lower power state after
> transmission of data. This is a feature on top of ALPM, AS SDP.
> Add compute config during atomic-check phase.
>
> v1: RFC
On Thu, 2024-04-25 at 00:08 +0530, Animesh Manna wrote:
> For validation purpose add debugfs for LOBF.
>
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_alpm.c | 48
> +++
> drivers/gpu/drm/i915/display/intel_alpm.h | 2 +
>
On Thu, 2024-04-25 at 00:08 +0530, Animesh Manna wrote:
> Set the Link Off Between Frames Enable bit in ALPM_CTL register.
>
> Note: Lobf need to be enabled adaptive sync fixed refresh mode
> where vmin = vmax = flipline, which will arise after cmmr feature
> enablement. Will add enabling
On Fri, 2024-05-03 at 08:30 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Friday, May 3, 2024 1:02 PM
> > To: Manna, Animesh ; intel-
> > g...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesk
On Fri, 2024-05-03 at 08:42 +, Manna, Animesh wrote:
>
>
> > -Original Message-
> > From: Hogander, Jouni
> > Sent: Friday, May 3, 2024 12:49 PM
> > To: Manna, Animesh ; intel-
> > g...@lists.freedesktop.org
> > Cc: dri-devel@lists.freedesk
On Thu, 2024-04-25 at 00:08 +0530, Animesh Manna wrote:
> Link Off Between Active Frames (LOBF) allows an eDP link to be turned
> Off and On
> durning long VBLANK durations without enabling any of the PSR/PSR2/PR
> modes of operation.
You could describe a bit more about what this patch set is
Hello Maintainers,
Could you please ack this patch? I'm planning to merge it via drm-intel
tree.
BR,
Jouni Högander
On Fri, 2024-05-10 at 13:26 +0300, Jouni Högander wrote:
> Add definitions for panel replay selective update
>
> v2: Remove unnecessary Cc from commit message
>
>
On Thu, 2024-05-09 at 11:01 +0530, Animesh Manna wrote:
> Link Off Between Active Frames, is a new feature for eDP
> that allows the panel to go to lower power state after
> transmission of data. This is a feature on top of ALPM, AS SDP.
> Add compute config during atomic-check phase.
>
> v1: RFC
On Mon, 2024-05-27 at 13:56 +0530, Animesh Manna wrote:
> Link Off Between Active Frames (LOBF) allows an eDP link to be turned
> Off and On
> durning long VBLANK durations without enabling any of the PSR/PSR2/PR
> modes of operation.
>
> Bspec: 71477
>
> Note: Lobf need to be enabled adaptive
On Thu, 2024-05-16 at 11:53 +0300, Jouni Högander wrote:
> Add PANEL_REPLAY_CONFIGURATION_2 register and some missing Panel
> Replay
> bits.
Hello drm-core maintainers,
Could you please consider providing your ack on this patch? I'm
planning to merge it via drm-intel tree. I have already r-b
59 matches
Mail list logo
