On Mon, 2024-02-19 at 13:25 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Tooling appears very strict so lets pacify it by adding some comments,
> even if fields are completely self-explanatory.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Tvrtko Ursulin
> Fixes:
On Fri, 2024-02-09 at 09:06 +, Tvrtko Ursulin wrote:
> On 08/02/2024 17:55, Souza, Jose wrote:
> > On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
> > > On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> > > > On 08/02/2024 14:30, Souza
On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
> On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> > On 08/02/2024 14:30, Souza, Jose wrote:
> > > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
&g
On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
> On 08/02/2024 14:30, Souza, Jose wrote:
> > On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Add a new query to the GuC submission interface versi
On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Add a new query to the GuC submission interface version.
>
> Mesa intends to use this information to check for old firmware versions
> with a known bug where using the render and compute command streamers
>
On Wed, 2024-02-07 at 11:52 -0800, John Harrison wrote:
> On 2/7/2024 11:43, Souza, Jose wrote:
> > On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
> > > On 2/7/2024 10:49, Tvrtko Ursulin wrote:
> > > > On 07/02/2024 18:12, John Harrison wrote:
> > >
On Wed, 2024-02-07 at 11:34 -0800, John Harrison wrote:
> On 2/7/2024 10:49, Tvrtko Ursulin wrote:
> > On 07/02/2024 18:12, John Harrison wrote:
> > > On 2/7/2024 03:56, Tvrtko Ursulin wrote:
> > > > From: Tvrtko Ursulin
> > > >
> > > > Add a new query to the GuC submission interface version.
>
On Wed, 2023-05-10 at 16:19 +0200, Thomas Hellström wrote:
> Each VM has two rebind lists, one protected by the VM resv, the other
> one protected essentially by the VM notifier.list_lock. This series
> intends to fix two points of illegal access.
>
> Patch 1 fixes an access of VM rebind_lists'
On Mon, 2023-03-06 at 15:16 +0100, Maarten Lankhorst wrote:
> As a fallback if we decide not to merge the frontbuffer tracking, allow
> i915 to keep its own implementation, and do the right thing in Xe.
>
> The frontbuffer tracking for Xe is still done per-fb, while i915 can
> keep doing the
On Mon, 2022-05-16 at 15:19 +0800, Hangyu Hua wrote:
> If drm_connector_init fails, intel_connector_free will be called to take
> care of proper free. So it is necessary to drop the refcount of port
> before intel_connector_free.
Reviewed-by: José Roberto de Souza
>
> Fixes: 091a4f91942a
On Mon, 2022-06-13 at 09:53 -0700, Matt Roper wrote:
> As with past platforms, the bspec's performance tuning guide provides
> recommended MMIO settings. Although not technically "workarounds" we
> apply these through the workaround framework to ensure that they're
> re-applied at the proper
On Thu, 2022-06-02 at 16:30 -0700, Matt Roper wrote:
> We missed this setting in the initial device info patch's definition of
> XE_HPC_FEATURES.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> 1 file changed, 1 insertion(+)
>
On Wed, 2022-06-01 at 14:06 -0700, Matt Roper wrote:
> From: Stuart Summers
>
> Our internal teams have identified a few additional engine registers
> that are worth inspecting in error state dumps during development &
> debug. Let's capture and print them as part of our error dump.
>
> For
On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Add drm_debug_once* macros to allow printing out one time debug
> messages which can be still controlled via drm.debug parameter.
Reviewed-by: José Roberto de Souza
>
> Cc: José Roberto de Souza
> Cc: Mika Kahola
> Cc: Mark Pearson
On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Current update area calculation is not handling situation where
> e.g. cursor plane is fully or partially outside pipe area.
>
> Fix this by checking damage area against pipe_src area using
> drm_rect_intersect.
>
> v2: Set x1 and x2 in
On Tue, 2022-05-10 at 21:33 +0300, Jouni Högander wrote:
> Currently we have some corner cases where area calculation fails. For
> these sel fetch area calculation ends up having update area as y1 = 0,
> y2 = 4. Instead of these values safer option is full update.
>
> One of such for example is
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> From: Lucas De Marchi
>
> The new Link Copy engines in PVC may be fused off according to the
> mslice_mask. Each bit of the MEML3_EN_MASK we read from the
> GEN10_MIRROR_FUSE3 register disables a pair of link copy engines.
Reviewed-by: José
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> From: John Harrison
>
> PVC adds extra blitter engines (in the following patch). The reset
> selftest has a local array on the stack which is sized by the number
> of engines. The increase pushes the size of this array to the point
> where
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> This patch adds the basic definitions needed to support
> new copy engines. Also updating the cmd_info to accommodate
> new engines, as the engine id's of legacy engines have been
> changed.
Reviewed-by: José Roberto de Souza
>
>
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> This patch adds the reset support for new copy engines
> in PVC.
Reviewed-by: José Roberto de Souza
>
> Bspec: 52549
> Original-author: CQ Tang
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 8 +
>
On Mon, 2022-05-02 at 09:34 -0700, Matt Roper wrote:
> From: Lucas De Marchi
>
> As we have more copy engines now, mask all of them from aux table
> invalidate.
Reviewed-by: José Roberto de Souza
>
> Cc: Prathap Kumar Valsan
> Signed-off-by: Lucas De Marchi
> Signed-off-by: Matt Roper
>
On Tue, 2022-04-26 at 21:08 +0300, Ville Syrjälä wrote:
> On Thu, Apr 21, 2022 at 12:22:03PM -0700, José Roberto de Souza wrote:
> > Intel hardware supports change between modes with different refresh
> > rates without any glitches or visual artifacts, that feature is called
> > seamless DRRS.
> >
On Mon, 2022-04-25 at 14:55 +0300, Jani Nikula wrote:
> On Thu, 21 Apr 2022, José Roberto de Souza wrote:
> > Will be adding some additional control options to DRRS that will
> > require to have the DRRS downclock mode stored in the crtc_state.
> >
> > So to optimize memory usage a bit here
On Wed, 2022-03-16 at 16:45 -0700, Lucas De Marchi wrote:
> From: Matthew Brost
>
> Add logical mapping for VDBOXs. This mapping is required for
> split-frame workloads, which otherwise fail with
>
> -F8C53528: [GUC] 0441-INVALID_ENGINE_SUBMIT_MASK
>
> ... if the application is
On Wed, 2022-03-16 at 16:45 -0700, Lucas De Marchi wrote:
> Earlier versions of commit a5b7ef27da60 ("drm/i915: Add struct to hold
> IP version") named "ver" as "arch" and then when it was renamed it
> missed the rename on MEDIA_VER_FULL() since it it's currently not used.
Reviewed-by: José
On Mon, 2022-03-14 at 16:42 -0700, Matt Roper wrote:
> Add a new 'steering' node in each gt's debugfs directory that tells
> whether we're using explicit steering for various types of MCR ranges
> and, if so, what MMIO ranges it applies to.
>
> We're going to be transitioning away from implicit
On Mon, 2022-03-14 at 19:08 -0700, Matt Roper wrote:
> From: John Harrison
>
> sseu_dev_info is already a pretty large structure which will likely
> continue to grow when future platforms increase potential DSS and EU
> counts. Let's switch the stack placement of this structure in debugfs
>
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 Carbon 9th
On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Following what was done in drm_cache.c, when the stub for
> remap_io_mapping() was added in commit 67c430bbaae1 ("drm/i915: Skip
> remap_io_mapping() for non-x86 platforms"), it included a log message
> with pr_err(). However just the
On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Only x86 and in some cases PPC have support added in drm_cache.c for the
> clflush class of functions. However warning once is sufficient to taint
> the log instead of spamming it with "Architecture has no drm_cache.c
> support" every few
On Mon, 2022-01-31 at 08:59 -0800, Lucas De Marchi wrote:
> Architectures others than x86 have a stub implementation calling
> WARN_ON_ONCE(). The appropriate headers need to be included, otherwise
> the header-test target will fail with:
>
> HDRTEST drivers/gpu/drm/i915/i915_mm.h
> In file
On Tue, 2022-01-04 at 21:21 +0530, Manna, Animesh wrote:
> Hi,
>
> > -Original Message-
> > From: Souza, Jose
> > Sent: Wednesday, November 24, 2021 1:19 AM
> > To: dri-devel@lists.freedesktop.org; Manna, Animesh
> > ; intel-...@lists.freedesktop.o
On Wed, 2021-12-01 at 16:30 -0800, Lucas De Marchi wrote:
> PAT can be disabled on boot with "nopat" in the command line. Replace
> one x86-ism with another, which is slightly more correct to prepare for
> supporting other architectures.
Reviewed-by: José Roberto de Souza
>
> Cc: Matt Roper
>
On Sun, 2021-10-10 at 17:40 +0530, Animesh Manna wrote:
> As panel replay feature similar to PSR feature of EDP panel, so currently
> utilized existing psr framework for panel replay.
>
> v1: RFC version.
> v2: optimized code, pr_enabled and pr_dpcd variable removed. [Jose]
> v3:
> - code
On Sun, 2021-10-10 at 17:40 +0530, Animesh Manna wrote:
> DPCD register definition added to check and enable panel replay
> capability of the sink.
>
> Signed-off-by: Animesh Manna
> ---
> include/drm/drm_dp_helper.h | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git
On Tue, 2021-11-16 at 09:48 -0800, Matt Roper wrote:
> From: Matt Atwood
>
> Extend existing workaround 1409120013 to DG2.
>
> Cc: José Roberto de Souza
> Signed-off-by: Matt Atwood
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/intel_pm.c | 4 ++--
> 1 file changed, 2
On Thu, 2021-09-30 at 15:46 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one
On Thu, 2021-09-23 at 18:49 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one
On Mon, 2021-09-20 at 16:11 +0200, Lukasz Majczak wrote:
> With patch "drm/i915/vbt: Fix backlight parsing for VBT 234+"
> the size of bdb_lfp_backlight_data structure has been increased,
> causing if-statement in the parse_lfp_backlight function
> that comapres this structure size to the one
On Wed, 2021-08-18 at 11:54 +0200, Daniel Vetter wrote:
> On Tue, Aug 17, 2021 at 04:26:04PM -0700, José Roberto de Souza wrote:
> > Cursors don't have a framebuffer so the fb comparisson was always
> > failing and atomic state was being committed without any plane state.
> >
> > So here checking
On Wed, 2021-07-21 at 15:30 +0200, Daniel Vetter wrote:
> It's not used. Drivers should instead use the helpers anyway.
>
> Currently both vbox and i915 hand-roll this and it's not the greatest.
> vbox looks buggy, and i915 does a bit much that helpers would take
> care of I think.
>
> Also
On Wed, 2021-07-21 at 15:30 +0200, Daniel Vetter wrote:
> We're trying to have a fairly strict split between core functionality
> that defines the uapi, including the docs, and the helper functions to
> implement it.
>
> Move drm_plane_enable_fb_damage_clips and associated kerneldoc into
>
On Wed, 2021-07-21 at 15:30 +0200, Daniel Vetter wrote:
> There's two stages of manual upload/invalidate displays:
> - just handling dirtyfb and uploading the entire fb all the time
> - looking at damage clips
>
> In the latter case we support it through fbdev emulation (with
> fb_defio), atomic
On Wed, 2021-06-16 at 11:55 +0800, Wayne Lin wrote:
> [Why]
> After unplug/hotplug hub from the system, userspace might start to
> clear stale payloads gradually. If we call drm_dp_mst_deallocate_vcpi()
> to release stale VCPI of those ports which are not relating to current
> topology, we have
On Fri, 2021-04-23 at 12:25 +0200, Maarten Lankhorst wrote:
> Op 22-04-2021 om 13:00 schreef Mun, Gwan-gyeong:
> > The changed name looks more accurate to the edp 1.4b spec.
> > Looks good to me.
> >
> > Reviewed-by: Gwan-gyeong Mun
> >
> > On Wed, 2021-04-21 at 15:02 -0700, José Roberto de
On Mon, 2021-04-12 at 10:05 +0100, Matthew Auld wrote:
> From: José Roberto de Souza
>
> Commit c457d9cf256e ("drm/i915: Make sure we have enough memory
> bandwidth on ICL") assumes that we always have a non-zero
> dram_info->channels and uses it as a divisor. We need num memory
> channels to be
On Tue, 2020-12-15 at 16:44 +0200, Ville Syrjälä wrote:
> On Mon, Dec 14, 2020 at 09:49:08AM -0800, José Roberto de Souza wrote:
> > Much more clear to read one function call than four lines doing this
> > conversion.
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Gwan-gyeong Mun
> >
On Tue, 2020-12-15 at 12:52 +, Mun, Gwan-gyeong wrote:
> On Mon, 2020-12-14 at 09:49 -0800, José Roberto de Souza wrote:
> > Much more clear to read one function call than four lines doing this
> > conversion.
> >
> > Cc: dri-devel@lists.freedesktop.org
> > Cc: Gwan-gyeong Mun
> >
On Sun, 2020-12-13 at 17:22 +, Simon Ser wrote:
> Can you add some drm_dbg_atomic logs when the damage is invalid, to make it
> easier for user-space to understand why an atomic commit failed?
sure, this is enough? will wait for a couple of more days before send another
version.
diff --git
s own list and for changes in drm
subsystem that affects all other drm based drivers.
On Wed, 2020-10-14 at 20:29 +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP.
>
> BSpec: 21257
>
> Cc: Souza Jose
> Signed-off-by: Tejas Upadhyay
> ---
> drivers/gpu
On Tue, 2020-10-06 at 10:55 -0700, Vivi, Rodrigo wrote:
>
> > On Oct 6, 2020, at 10:48 AM, Chris Wilson wrote:
> >
> > Quoting Souza, Jose (2020-10-06 18:46:45)
> > > +Rodrigo and Jani
> > >
> > > On Tue, 2020-10-06 at 14:56 +, Kamati Sriniva
+Rodrigo and Jani
On Tue, 2020-10-06 at 14:56 +, Kamati Srinivas wrote:
> Removing force probe protection from EHL platform. Did
> not observe warnings, errors, flickering or any visual
> defects while doing ordinary tasks like browsing and
> editing documents in a two monitor setup.
One of
On Tue, 2020-09-29 at 23:30 +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 08:20:22PM +0000, Souza, Jose wrote:
> > On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 29, 2020 at 07:33:45PM +, Souza, Jose wrote:
> > > > On Tue, 20
On Tue, 2020-09-29 at 23:02 +0300, Ville Syrjälä wrote:
> On Tue, Sep 29, 2020 at 07:33:45PM +0000, Souza, Jose wrote:
> > On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> > > JSL has update in vswing table for eDP
> >
> > Would be nice to mention in
On Tue, 2020-09-29 at 17:41 +0530, Tejas Upadhyay wrote:
> JSL has update in vswing table for eDP
Would be nice to mention in the commit description why PCH is being used, that
would avoid Ville's question.
>
> BSpec: 21257
>
> Changes since V1 :
> - IS_ELKHARTLAKE and IS_JASPERLAKE is
Just merged the first patch that fixed this issue, thanks anyways.
2034c2129bc4a91d471815d4dc7a2a69eaa5338d - drm/i915/display: Ensure that ret is
always initialized in icl_combo_phy_verify_state
On Tue, 2020-08-25 at 16:20 -0700, t...@redhat.com wrote:
> From: Tom Rix <
> t...@redhat.com
> >
On Thu, 2020-08-20 at 10:46 +0200, Adam Miszczak wrote:
> Add DG1 and clean-up VLV PCI IDs.
>
> Align with kernel commits:
> f2bde2546b81 ("drm/i915: Remove dubious Valleyview PCI IDs")
> fd38cdb81105 ("drm/i915/dg1: Add DG1 PCI IDs")
>
Reviewed-by: José Roberto de Souza
But the current
On Thu, 2020-07-02 at 17:40 +0300, Ville Syrjälä wrote:
> On Tue, Jun 30, 2020 at 11:42:36PM +0000, Souza, Jose wrote:
> > On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Apparently EDIDs with multiple Disp
On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Drop some pointless curly braces, and add some across the
> else when the if has them too.
Reviewed-by: José Roberto de Souza
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_edid.c | 9 -
On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Apparently there are EDIDs in the wild with multiple DispID extension
> blocks. Iterate through them all.
>
> In one particular case the tile information is specicied in the
> second DispID ext block, and since
On Wed, 2020-05-27 at 16:03 +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Apparently EDIDs with multiple DispID ext blocks is a thing, so prepare
> for iterating through multiple ext blocks of the same type by
> passing the starting ext block index to drm_find_edid_extension(). Well
>
On Thu, 2020-06-04 at 00:10 +0300, Imre Deak wrote:
> Make the locking look symmetric with the unlocking.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Thu, 2020-06-04 at 00:10 +0300, Imre Deak wrote:
> Currently MST on a port can get enabled/disabled from the hotplug work
> and get disabled from the short pulse work in a racy way. Fix this by
> relying on the MST state checking in the hotplug work and just schedule
> a hotplug work from the
Hi Hans
Just commenting in the "[3.309061] [drm:intel_dump_pipe_config
[i915]] MST master transcoder: " message, it is the expected
behaviour for anything older than Tigerlake, from TGL+ this will be set
in MST mode.
On Wed, 2020-02-26 at 18:52 +0100, Hans de Goede wrote:
> Hi,
>
> On
On Thu, 2020-01-30 at 19:16 +0200, Ville Syrjälä wrote:
> On Thu, Jan 16, 2020 at 05:58:36PM -0800, José Roberto de Souza
> wrote:
> > This is a eDP function and it will always returns true for non-eDP
> > ports.
> >
> > Signed-off-by: José Roberto de Souza
> > ---
> >
On Thu, 2020-01-30 at 10:49 +, Lisovskiy, Stanislav wrote:
> On Wed, 2020-01-29 at 15:24 -0800, José Roberto de Souza wrote:
> > According to DP specification, DP_SINK_EVENT_NOTIFY is also a
> > broadcast message but as this function only handles
> > DP_CONNECTION_STATUS_NOTIFY I will only
On Thu, 2020-01-30 at 19:25 +0200, Ville Syrjälä wrote:
> On Thu, Jan 16, 2020 at 05:58:37PM -0800, José Roberto de Souza
> wrote:
> > TGL timeouts when disabling MST transcoder and fifo underruns over
> > MST
> > transcoders are fixed when setting TRANS_DDI_MODE_SELECT to 0(HDMI
> > mode) during
On Wed, 2020-01-22 at 18:49 +0530, Anshuman Gupta wrote:
> On 2020-01-21 at 12:13:14 -0800, José Roberto de Souza wrote:
> > A recent change in BSpec allow us to change EXTLINE while
> > transcoder
> > is enabled so this allow us to change it even when doing the first
> > fastset after taking over
On Sun, 2019-12-29 at 16:22 +, Eric Engestrom wrote:
> On Monday, 2019-12-16 16:51:28 +0000, Souza, Jose wrote:
> > Hello
> >
> > I have being contributing to i915 for the past 2 years and part of
> > my
> > work is update the PCI ids of Intel devices in
On Thu, 2019-12-12 at 09:17 -0800, Matt Roper wrote:
> On Tue, Dec 10, 2019 at 12:06:11PM -0800, José Roberto de Souza
> wrote:
> > It is missing the new EHL/JSL PCI ids added in commit
> > 651cc835d5f6 ("drm/i915: Add new EHL/JSL PCI ids")
> >
> > Cc: James Ausmus
> > Cc: Matt Roper
> >
Hello
I have being contributing to i915 for the past 2 years and part of my
work is update the PCI ids of Intel devices in libdrm.
Being able to push my reviewed patches would be really helpful, please
consider this request.
Thanks
___
dri-devel
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> For the sake of symmetry with the crtc stuff let's add
> a helper to reset the plane state to sane default values.
> For the moment this only gets caller from the plane init.
>
Reviewed-by: José Roberto de Souza
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We have a few places where we want to reset a crtc state to its
> default values. Let's add a helper for that. We'll need the new
> __drm_atomic_helper_crtc_state_reset() helper for this to allow
> us to just reset
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Let's get rid of the redundant intel_ prefix on our variables.
>
Reviewed-by: José Roberto de Souza
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 32 ++--
>
On Thu, 2019-11-07 at 16:24 +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We already have alloc/free helpers for planes, add the same for
> crtcs. The main benefit is we get to move all the annoying state
> initialization out of the main crtc_init() flow.
>
Reviewed-by: José Roberto de
On Tue, 2019-11-19 at 13:58 +0100, Benjamin Gaignard wrote:
> Include drm_crtc_helper_internal.h to provide
> drm_connector_get_single_encoder
> prototype.
>
> Fixes: a92462d6bf493 ("drm/connector: Share with non-atomic drivers
> the function to get the single encoder")
On Mon, 2019-09-16 at 12:39 -0700, Manasi Navare wrote:
> On Mon, Sep 16, 2019 at 07:34:32PM +0000, Souza, Jose wrote:
> > Someone with drm-misc commit access could push this?
> >
>
> Sure will push this series.
Thanks Manasi
>
> Manasi
>
> > Thanks
Someone with drm-misc commit access could push this?
Thanks
On Sun, 2019-09-15 at 11:36 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [CI,1/2] drm/connector: Share with non-
> atomic drivers the function to get the single encoder
> URL :
On Wed, 2019-09-11 at 21:10 +0300, Ville Syrjälä wrote:
> On Wed, Sep 11, 2019 at 10:56:02AM -0700, José Roberto de Souza
> wrote:
> > This 3 non-atomic drivers all have the same function getting the
> > only encoder available in the connector, also atomic drivers have
> > this fallback. So moving
On Fri, 2019-09-06 at 14:27 +0300, Ville Syrjälä wrote:
> On Thu, Sep 05, 2019 at 02:09:27PM -0700, José Roberto de Souza
> wrote:
> > From: Dhinakaran Pandiyan
> >
> > Currently we restrict the number of encoders that can be linked to
> > a connector to 3, increase it to match the maximum
On Fri, 2019-08-30 at 13:32 -0700, Anusha Srivatsa wrote:
> Add the new CML PCI IDS.
>
> Align with kernel commit:
> bfc4c359b2822 ("drm/i915/cml: Add Missing PCI IDs")
>
> This is in sync with kernel header as of:
> 0747590267e7 ("drm-tip: 2019y-08m-30d-18h-03m-18s UTC integration
> manifest")
On Wed, 2019-09-04 at 16:39 +0200, Daniel Vetter wrote:
> - it's what we recommend in our docs:
>
> https://dri.freedesktop.org/docs/drm/gpu/drm-uapi.html#recommended-ioctl-return-values
>
> - it's the overwhelmingly used error code for "operation not
> supported", at least in drm core
On Sat, 2019-06-29 at 17:39 +0200, Daniel Vetter wrote:
> On Fri, Jun 28, 2019 at 7:24 PM Sean Paul wrote:
> > On Fri, Jun 14, 2019 at 08:17:23AM +0200, Daniel Vetter wrote:
> > > Only dynamic mode objects, i.e. those which are refcounted and
> > > have a free
> > > callback, can be added while
On Fri, 2019-08-16 at 21:29 +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/connector: Allow max possible encoders to attach to a
> connector (rev2)
> URL : https://patchwork.freedesktop.org/series/62743/
> State : warning
>
> == Summary ==
>
> $ dim sparse origin/drm-tip
>
Series is Reviewed-by: José Roberto de Souza
On Mon, 2019-07-15 at 11:53 -0700, Lucas De Marchi wrote:
> From: Rodrigo Vivi
>
> Add the PCI ID import for EHL.
>
> Cc: Rodrigo Vivi
> Signed-off-by: James Ausmus
> Signed-off-by: Lucas De Marchi
> ---
> intel/intel_chipset.c | 1 +
> 1 file
On Fri, 2019-03-22 at 13:35 -0700, Anusha wrote:
> Straight copy from the kernel file.
>
> Add PCI IDs for CML, add additional PCI ID
> for ICL.
>
> Align with kernel commits:
>
> a7b4deeb02b97 ("drm/i915/cml: Add CML PCI IDS")
> 9a751b999d17a ("drm/i915: Add new ICL PCI ID")
>
> v2: Do a copy
On Thu, 2019-02-28 at 16:09 -0500, Sean Paul wrote:
> From: Sean Paul
>
> This patch adds a new drm helper library to help drivers implement
> PSR. Drivers choosing to use it will register connectors with
> PSR-capable displays connected and will receive callbacks when it's
> time
> to enter or
On Wed, 2018-12-05 at 12:30 -0800, Dhinakaran Pandiyan wrote:
> On Wed, 2018-12-05 at 10:48 -0800, José Roberto de Souza wrote:
> > The DP_DPCD_QUIRK_NO_PSR comment is missing colon causing this
> > warning when generating kernel documentation.
> >
> > ./include/drm/drm_dp_helper.h:1374: warning:
On Mon, 2018-12-03 at 15:12 -0800, Pandiyan, Dhinakaran wrote:
> On Mon, 2018-12-03 at 14:45 -0800, Souza, Jose wrote:
> > On Mon, 2018-12-03 at 12:59 -0800, Dhinakaran Pandiyan wrote:
> > > On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > > > A
On Mon, 2018-12-03 at 14:45 -0800, Dhinakaran Pandiyan wrote:
> On Mon, 2018-12-03 at 12:14 -0800, Souza, Jose wrote:
> > On Fri, 2018-11-30 at 15:35 -0800, Dhinakaran Pandiyan wrote:
> > > On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > > > i915
On Mon, 2018-12-03 at 12:59 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > According to eDP spec, sink can required specific selective update
> > granularity that source must comply.
> > Here caching the value if required and checking if
On Fri, 2018-11-30 at 16:37 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > Selective updates have a default granularity requirements as stated
> > by eDP spec
> Needs reference to the location in the spec.
Done
>
> > , so check if HW can
On Fri, 2018-11-30 at 15:54 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > As we have a else block for the 'if (dev_priv->psr.psr2_enabled) {'
> > and this bit is only set for PSR1 move it to that block to make it
> > more easy to read.
> >
On Fri, 2018-11-30 at 15:35 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 18:25 -0800, José Roberto de Souza wrote:
> > i915 yet don't support PSR in Apple panels, so lets keep it
> > disabled
> > while we work on that.
> >
> > v2: Renamed DP_DPCD_QUIRK_PSR_NOT_CURRENTLY_SUPPORTED to
On Thu, 2018-11-29 at 15:10 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:09PM -0800, José Roberto de Souza
> wrote:
> > EDP_PSR2_IDLE_FRAMES_TO_DEEP_SLEEP() was being set with the number
> > of
> > frames that it should wait to enter PSR, what is wrong.
> > Here it is setting this
On Thu, 2018-11-29 at 15:25 -0800, Dhinakaran Pandiyan wrote:
> On Thu, 2018-11-29 at 15:07 -0800, Rodrigo Vivi wrote:
> > On Mon, Nov 26, 2018 at 04:37:08PM -0800, José Roberto de Souza
> > wrote:
> > > The first 8 bits of PSR2_CTL have 2 fields to set frames count,
> > > the
> > > first one is
On Thu, 2018-11-29 at 15:03 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:07PM -0800, José Roberto de Souza
> wrote:
> > According to eDP spec, sink can required specific selective update
> > granularity that source must comply.
> > Here caching the value if required and checking
On Thu, 2018-11-29 at 14:15 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:05PM -0800, José Roberto de Souza
> wrote:
> > For ICL the bit 12 of CHICKEN_TRANS is reserved so we should not
> > touch it and as by default VSC_DATA_SEL_SOFTWARE_CONTROL is already
> > unset in gen10 + GLK we
On Wed, 2018-11-28 at 11:02 -0800, Rodrigo Vivi wrote:
> On Mon, Nov 26, 2018 at 04:37:03PM -0800, José Roberto de Souza
> wrote:
> > For PSR2 there is no register to tell HW to keep main link enabled
> > while PSR2 is active, so don't configure sink DPCD with a
> > misleading value.
> >
> > Cc:
On Tue, 2018-11-27 at 15:38 +0200, Ville Syrjälä wrote:
> On Mon, Nov 26, 2018 at 04:37:02PM -0800, José Roberto de Souza
> wrote:
> > i915 yet don't support PSR in Apple panels, so lets keep it
> > disabled
> > while we work on that.
> >
> > Fixes: 598c6cfe0690 (drm/i915/psr: Enable PSR1 on
1 - 100 of 110 matches
Mail list logo
