Hi all,
On Wed, 26 Aug 2020 10:18:53 +1000 Stephen Rothwell
wrote:
>
> Hi all,
>
> Today's linux-next merge of the drm-misc tree got conflicts in:
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.h
> drive
Hi Dave & Daniel -
drm-intel-fixes-2020-09-03:
drm/i915 fixes for v5.9-rc4:
- Clang build warning fix
- HDCP fixes
BR,
Jani.
The following changes since commit f75aef392f869018f78cfedf3c320a6b3fcfda6b:
Linux 5.9-rc3 (2020-08-30 16:01:54 -0700)
are available in the Git repository at:
git
On 9/2/20 4:02 PM, Thomas Hellström (Intel) wrote:
Hi, Chris,
On 8/26/20 3:28 PM, Chris Wilson wrote:
Use the wait_queue_entry.flags to denote the special fence behaviour
(flattening continuations along fence chains, and for propagating
errors) rather than trying to detect ordinary waiters by
Hi Roman,
Sorry that I am a software guy and can only speak for software. In general
there are various approaches to support graphics virtualization. GVT-g as a
pure software approach, does not rely on any hardware I/O virtualization
features, meanwhile, hypervisors need specific implementation
Hi Jason,
We ever supported both XenGT and KVMGT for data center usages. Right now KVMGT
is still used in client side for GPU sharing. That's why we are supporting
KVMGT. Thanks!
Regards,
-Zhiyuan
-Original Message-
From: Jason Long
Date: Wednesday, September 2, 2020 at 9:38 PM
To: M
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 = PSA
Hi All,
So the bug-fix which prompted v8, lead to some discussion about the pwm-lpss
suspend/resume code. So as discussed this version drops the following 2
patches:
[PATCH v8 06/17] pwm: lpss: Use pwm_lpss_restore() when restoring state on
resume
[PATCH v8 07/17] pwm: lpss: Always update state
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter ove
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input cl
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
The BACKLIGHT_EN register at address 0x51 really controls a separate
output-only GPIO which is earmarked to be used as output connected to the
backlight-enable
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.
Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the m
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set i
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which grea
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested f
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
---
Changes in v6:
- Rebase on 5.9-rc1
- Use do_div when calculating level because pwm_state.period and .duty_cy
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastse
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Acked-by: Jani Nikula
Signed-off-by: Hans de
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a clo
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
---
Changes in v6:
- Rebase on 5.9-rc1
- Use DIV_ROUND_UP_ULL because pwm_state.period and .duty_cycle are now u64
Cha
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enable
Before this commit pwm_lpss_apply() was making 2 assuming
2 pre-conditions were met by the existing hardware state:
1. That the base-unit and on-time-div read back from the
control register are those actually in use, so that it
can skip setting the update bit if the read-back value
matches the des
PWM controller drivers should not restore the PWM state on resume. The
convention is that PWM consumers do this by calling pwm_apply_state(),
so that it can be done at the exact moment when the consumer needs
the state to be stored, avoiding e.g. backlight flickering.
The only in kernel consumers
On Thu, Sep 03, 2020 at 12:51:03PM +0200, Hans de Goede wrote:
> Before this commit pwm_lpss_apply() was making 2 assuming
> 2 pre-conditions were met by the existing hardware state:
I think that "making 2" is too much.
>
> 1. That the base-unit and on-time-div read back from the
> control regis
On Thu, Sep 03, 2020 at 12:51:04PM +0200, Hans de Goede wrote:
> PWM controller drivers should not restore the PWM state on resume. The
> convention is that PWM consumers do this by calling pwm_apply_state(),
> so that it can be done at the exact moment when the consumer needs
> the state to be sto
Hi,
On 9/3/20 12:59 PM, Thierry Reding wrote:
On Thu, Sep 03, 2020 at 12:51:03PM +0200, Hans de Goede wrote:
Before this commit pwm_lpss_apply() was making 2 assuming
2 pre-conditions were met by the existing hardware state:
I think that "making 2" is too much.
You're right at first the sen
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI
Hi All,
Here is hopefully the last version of this series, as everything seems
to be ready for merging this now.
The only difference from v9 is correcting some mistakes in the commit-msg of:
[PATCH v10 06/17] pwm: lpss: Make pwm_lpss_apply() not rely on hardware state
I plan is to push the entir
In the not-enabled -> enabled path pwm_lpss_apply() needs to get a
runtime-pm reference; and then on any errors it needs to release it
again.
This leads to somewhat hard to read code. This commit introduces a new
pwm_lpss_prepare_enable() helper and moves all the steps necessary for
the not-enable
Before this commit pwm_lpss_apply() was assuming 2 pre-conditions
were met by the existing hardware state:
1. That the base-unit and on-time-div read back from the
control register are those actually in use, so that it
can skip setting the update bit if the read-back value
matches the desired valu
The DSDTs on most Cherry Trail devices have an ugly clutch where the PWM
controller gets poked from the _PS0 method of the graphics-card device:
Local0 = PSAT /* \_SB_.PCI0.GFX0.PSAT */
If (((Local0 & 0x03) == 0x03))
{
PSAT &= 0xFFFC
Local1 = PSA
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
The BACKLIGHT_EN register at address 0x51 really controls a separate
output-only GPIO which is earmarked to be used as output connected to the
backlight-enable
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
---
Changes in v6:
- Rebase on 5.9-rc1
- Use DIV_ROUND_UP_ULL because pwm_state.period and .duty_cycle are now u64
Cha
PWM controller drivers should not restore the PWM state on resume. The
convention is that PWM consumers do this by calling pwm_apply_state(),
so that it can be done at the exact moment when the consumer needs
the state to be stored, avoiding e.g. backlight flickering.
The only in kernel consumers
The CRC PWM controller has a clock-divider which divides the clock with
a value between 1-128. But as can seen from the PWM_DIV_CLK_xxx
defines, this range maps to a register value of 0-127.
So after calculating the clock-divider we must subtract 1 to get the
register value, unless the requested f
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the minimum allowed
PWM level to 0. But several of these devices specify a non 0 minimum
setting in their VBT.
Change pwm_setup_backlight() to use get_backlight_min_vbt() to get
the m
So far for devices using an external PWM controller (devices using
pwm_setup_backlight()), we have been hardcoding the period-time passed to
pwm_config() to 21333 ns.
I suspect this was done because many VBTs set the PWM frequency to 200
which corresponds to a period-time of 500 ns, which grea
While looking into adding atomic-pwm support to the pwm-crc driver I
noticed something odd, there is a PWM_BASE_CLK define of 6 MHz and
there is a clock-divider which divides this with a value between 1-128,
and there are 256 duty-cycle steps.
The pwm-crc code before this commit assumed that a clo
When the user requests a high enough period ns value, then the
calculations in pwm_lpss_prepare() might result in a base_unit value of 0.
But according to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter ove
According to the data-sheet the way the PWM controller works is that
each input clock-cycle the base_unit gets added to a N bit counter and
that counter overflowing determines the PWM output frequency.
So assuming e.g. a 16 bit counter this means that if base_unit is set to 1,
after 65535 input cl
Factor the code which checks and drm_dbg_kms-s the VBT PWM frequency
out of get_backlight_max_vbt().
This is a preparation patch for honering the VBT PWM frequency for
devices which use an external PWM controller (devices using
pwm_setup_backlight()).
Acked-by: Jani Nikula
Signed-off-by: Hans de
Now that the PWM drivers which we use have been converted to the atomic
PWM API, we can move the i915 panel code over to using the atomic PWM API.
The removes a long standing FIXME and this removes a flicker where
the backlight brightness would jump to 100% when i915 loads even if
using the fastse
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Reviewed-by: Andy Shevchenko
Acked-by: Thierry Reding
Signed-off-by: Hans de Goede
---
Changes in v6:
- Rebase on 5.9-rc1
- Use do_div when calculating level because pwm_state.period and .duty_cy
The pwm-crc code is using 2 different enable bits:
1. bit 7 of the PWM0_CLK_DIV (PWM_OUTPUT_ENABLE)
2. bit 0 of the BACKLIGHT_EN register
So far we've kept the PWM_OUTPUT_ENABLE bit set when disabling the PWM,
this commit makes crc_pwm_disable() clear it on disable and makes
crc_pwm_enable() set i
== Series Details ==
Series: acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the
atomic PWM API
URL : https://patchwork.freedesktop.org/series/81284/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1697ae1e044d ACPI / LPSS: Resume Cherry Trail PWM controller in
Quoting Thomas Hellström (Intel) (2020-09-03 10:50:45)
>
> On 9/2/20 4:02 PM, Thomas Hellström (Intel) wrote:
> > Hi, Chris,
> >
> > On 8/26/20 3:28 PM, Chris Wilson wrote:
> >> Use the wait_queue_entry.flags to denote the special fence behaviour
> >> (flattening continuations along fence chains,
== Series Details ==
Series: acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the
atomic PWM API
URL : https://patchwork.freedesktop.org/series/81284/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8957 -> Patchwork_18436
===
== Series Details ==
Series: acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the
atomic PWM API
URL : https://patchwork.freedesktop.org/series/81287/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1168abd5ce8d ACPI / LPSS: Resume Cherry Trail PWM controller in
On 9/3/20 1:32 PM, Chris Wilson wrote:
Quoting Thomas Hellström (Intel) (2020-09-03 10:50:45)
On 9/2/20 4:02 PM, Thomas Hellström (Intel) wrote:
Hi, Chris,
On 8/26/20 3:28 PM, Chris Wilson wrote:
Use the wait_queue_entry.flags to denote the special fence behaviour
(flattening continuations a
== Series Details ==
Series: acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the
atomic PWM API
URL : https://patchwork.freedesktop.org/series/81287/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8957 -> Patchwork_18437
===
Enable HDCP 1.4 over DP MST for Gen12.
This also enable the stream encryption support for
older generations.
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 ++
drivers/gpu/drm/i915/display/intel_hdcp.c | 36 +
2 file
DP MST stream encryption status requires time of a link frame
in order to change its status, but as there were some HDCP
encryption timeout observed earlier, it is safer to use
ENCRYPT_STATUS_CHANGE_TIMEOUT_MS timeout for stream status too,
it requires to move the macro to a header.
It will be used
This is the version after addressing the review comment from
sean over RFC patch https://patchwork.freedesktop.org/series/81222/
Addressed Below Comments:
Typo fixes.
Cosmetic Fixes.
Used single hook for stream select and stream status validation.
Anshuman Gupta (4):
drm/i915/hdcp: DP MST tra
Both HDCP_{1.x,2.x} requires to select/deselect Multistream HDCP bit
in TRANS_DDI_FUNC_CTL in order to enable/disable stream HDCP
encryption over DP MST Transport Link.
HDCP 1.4 stream encryption requires to validate the stream encryption
status in HDCP_STATUS_{TRANSCODER,PORT} register driving th
Gen12 has H/W delta with respect to HDCP{1.x,2.x} display engine
instances lies in Transcoder instead of DDI as in Gen11.
This requires hdcp driver to use mst_master_transcoder for link
authentication and stream transcoder for stream encryption
separately.
This will be used for both HDCP 1.4 and
== Series Details ==
Series: Gen12 HDCP 1.4 support on DP MST
URL : https://patchwork.freedesktop.org/series/81289/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
f00dd9da6f69 drm/i915/hdcp: DP MST transcoder for link and stream
6bfdaa67e988 drm/i915/hdcp: Move HDCP enc status t
== Series Details ==
Series: Gen12 HDCP 1.4 support on DP MST
URL : https://patchwork.freedesktop.org/series/81289/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i915/gt/intel_
On Thu, Sep 03, 2020 at 01:23:26PM +0200, Hans de Goede wrote:
> Before this commit pwm_lpss_apply() was assuming 2 pre-conditions
> were met by the existing hardware state:
>
> 1. That the base-unit and on-time-div read back from the
> control register are those actually in use, so that it
> can
On Thu, Sep 03, 2020 at 01:23:27PM +0200, Hans de Goede wrote:
> PWM controller drivers should not restore the PWM state on resume. The
> convention is that PWM consumers do this by calling pwm_apply_state(),
> so that it can be done at the exact moment when the consumer needs
> the state to be sto
On Thu, Sep 03, 2020 at 03:48:16PM +0300, Andy Shevchenko wrote:
> On Thu, Sep 03, 2020 at 01:23:27PM +0200, Hans de Goede wrote:
> the question is do we need to have similar in acpi_lpss.c?
> For example,
> static const struct lpss_device_desc byt_pwm_dev_desc = {
> .flags = L
Hi,
On 9/3/20 2:56 PM, Andy Shevchenko wrote:
On Thu, Sep 03, 2020 at 03:48:16PM +0300, Andy Shevchenko wrote:
On Thu, Sep 03, 2020 at 01:23:27PM +0200, Hans de Goede wrote:
the question is do we need to have similar in acpi_lpss.c?
For example,
static const struct lpss_device_desc b
== Series Details ==
Series: Gen12 HDCP 1.4 support on DP MST
URL : https://patchwork.freedesktop.org/series/81289/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8958 -> Patchwork_18438
Summary
---
**SUCCESS**
No
From: Thomas Hellström
The hwsp_gtt object is used for sub-allocation and could therefore
be shared by many contexts causing unnecessary contention during
concurrent context pinning.
However since we're currently locking it only for pinning, it remains
resident until we unpin it, and therefore it
== Series Details ==
Series: drm/managed: Cleanup of unused functions and polishing docs
URL : https://patchwork.freedesktop.org/series/81253/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8953_full -> Patchwork_18431_full
On Tue, Sep 01, 2020 at 06:10:36PM +0300, Kai Vehmanen wrote:
> In commit 4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking
> to separate function") the order of force_min_cdclk_changed check and
> intel_modeset_checks(), was reversed. This broke the mechanism to
> immediately force a ne
Quoting Mika Kuoppala (2020-09-03 14:31:44)
> From: Thomas Hellström
>
> The hwsp_gtt object is used for sub-allocation and could therefore
> be shared by many contexts causing unnecessary contention during
> concurrent context pinning.
> However since we're currently locking it only for pinning,
On 9/3/20 4:01 PM, Chris Wilson wrote:
Quoting Mika Kuoppala (2020-09-03 14:31:44)
From: Thomas Hellström
The hwsp_gtt object is used for sub-allocation and could therefore
be shared by many contexts causing unnecessary contention during
concurrent context pinning.
However since we're current
On Wed, Sep 2, 2020 at 5:48 AM Lv, Zhiyuan wrote:
>
> Hi,
>
> It is mainly due to the business priority change. XenGT project was
> originally created for data center usages with XEON E3 servers which have
> integrated processor graphics. After SkyLake E3, there are no new servers
> capable of
Hi,
since kernel v5.7-rc1 my graphical output hangs on boot or if the i915
module is blacklisted on modprobe.
I've already found and extended a bugzilla
https://bugzilla.kernel.org/show_bug.cgi?id=208737
But sadly there has been little reaction so I would appreciate any
help in further debugging
On 10/08/2020 10:51, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2020-08-06 10:21:38)
On 05/08/2020 17:22, Thomas Hellström (Intel) wrote:
Hi, Chris,
On 8/5/20 2:21 PM, Chris Wilson wrote:
Long story short, we need to manage evictions using dma_resv & dma_fence
tracking. The backing storag
On Wed, Sep 02, 2020 at 09:26:27AM +0200, Daniel Vetter wrote:
> Following functions are only used internally, not by drivers:
> - devm_drm_dev_init
>
> Also, now that we have a very slick and polished way to allocate a
> drm_device with devm_drm_dev_alloc, update all the docs to reflect the
> new
Hey,
On Thu, 3 Sep 2020, Ville Syrjälä wrote:
> On Tue, Sep 01, 2020 at 06:10:36PM +0300, Kai Vehmanen wrote:
>> In commit 4f0b4352bd26 ("drm/i915: Extract cdclk requirements checking
>> to separate function") the order of force_min_cdclk_changed check and
>> intel_modeset_checks(), was reversed.
== Series Details ==
Series: drm/i915: Unlock the shared hwsp_gtt object after pinning
URL : https://patchwork.freedesktop.org/series/81290/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8959 -> Patchwork_18439
Summary
== Series Details ==
Series: drm/kms: Add separate hotplug event call for drm connector (rev2)
URL : https://patchwork.freedesktop.org/series/81257/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8954_full -> Patchwork_18433_full
From: Thomas Hellström
The hwsp_gtt object is used for sub-allocation and could therefore
be shared by many contexts causing unnecessary contention during
concurrent context pinning.
However since we're currently locking it only for pinning, it remains
resident until we unpin it, and therefore it
Hi Dave, Daniel,
Here's this week PR for drm-misc-next
Thanks!
Maxime
drm-misc-next-2020-09-03:
drm-misc-next for 5.10:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- doc: update the doc to encourage drivers to use devm_drm_dev_alloc
- ttm: More reworks / cleanups
Driver Changes:
(Including a bunch more emails in the To: that got missed the first time)
Hello everyone!
The X.org board is soliciting proposals to host XDC in 2021. Since
XDC2020 is being held virtually this year, we've decided to host in
either North America or Europe. However, the board is open to other
loca
== Series Details ==
Series: drm/i915: Unlock the shared hwsp_gtt object after pinning (rev2)
URL : https://patchwork.freedesktop.org/series/81290/
State : failure
== Summary ==
Applying: drm/i915: Unlock the shared hwsp_gtt object after pinning
Using index info to reconstruct a base tree...
M
== Series Details ==
Series: drm/i915: modeset probe cleanup
URL : https://patchwork.freedesktop.org/series/81267/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8955_full -> Patchwork_18435_full
Summary
---
**SUCCESS
> -Original Message-
> From: Vivi, Rodrigo
> Sent: Wednesday, September 2, 2020 2:32 PM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE register
> lookup
>
>
>
> > On Sep 2, 2020, at 12:30 PM, Srivats
On Wed, Jul 15, 2020 at 03:42:13PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst
>
> The members in hw.mode can be used from adjusted_mode as well,
> use that when available.
>
> Some places that use hw.mode can be converted to use adjusted_mode
> as well.
>
> v2:
> * Manual rebase (Man
On Wed, Jul 15, 2020 at 03:42:14PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst
>
> v4:
> * Manual rebase (Manasi)
> v3:
> * Change state to crtc_state, fix rebase err (Manasi)
> v2:
> * Manual Rebase (Manasi)
>
> Signed-off-by: Maarten Lankhorst
> Signed-off-by: Manasi Navare
> ---
On Thu, Sep 03, 2020 at 08:49:44PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 15, 2020 at 03:42:13PM -0700, Manasi Navare wrote:
> > From: Maarten Lankhorst
> >
> > The members in hw.mode can be used from adjusted_mode as well,
> > use that when available.
> >
> > Some places that use hw.mode can
On Wed, Jul 15, 2020 at 03:42:16PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst
>
> When the clock is higher than the dotclock, try with 2 pipes enabled.
> If we can enable 2, then we will go into big joiner mode, and steal
> the adjacent crtc.
>
> This only links the crtc's in soft
On Thu, Sep 03, 2020 at 11:04:33AM -0700, Navare, Manasi wrote:
> On Thu, Sep 03, 2020 at 08:49:44PM +0300, Ville Syrjälä wrote:
> > On Wed, Jul 15, 2020 at 03:42:13PM -0700, Manasi Navare wrote:
> > > From: Maarten Lankhorst
> > >
> > > The members in hw.mode can be used from adjusted_mode as we
On Wed, Jul 15, 2020 at 03:42:19PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst
>
> Make sure that when a plane is set in a bigjoiner mode, we will add
> their counterpart to the atomic state as well. This will allow us to
> make sure all state is available when planes are checked.
>
On Wed, Jul 15, 2020 at 03:42:21PM -0700, Manasi Navare wrote:
> From: Maarten Lankhorst
>
> Enabling is done in a special sequence and so should plane updates
> be. Ideally the end user never notices the second pipe is used,
> so use the vblank evasion to cover both pipes.
>
> This way ideally
== Series Details ==
Series: acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the
atomic PWM API
URL : https://patchwork.freedesktop.org/series/81284/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8957_full -> Patchwork_18436_full
=
== Series Details ==
Series: acpi/pwm/i915: Convert pwm-crc and i915 driver's PWM code to use the
atomic PWM API
URL : https://patchwork.freedesktop.org/series/81287/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8957_full -> Patchwork_18437_full
=
== Series Details ==
Series: Gen12 HDCP 1.4 support on DP MST
URL : https://patchwork.freedesktop.org/series/81289/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8958_full -> Patchwork_18438_full
Summary
---
**FAILUR
From: Khaled Almahallawy
Add the missing CP2520 pattern 2 and 3 phy compliance patterns
v2: cosemtic changes
Reviewed-by: Manasi Navare (v1)
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
include/drm/drm_dp_helper.h | 4 +++-
2 files changed, 4 insertions(+
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.
v2: Rebased patch on top of Khaled
From: Khaled Almahallawy
Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
v2: uniform bit names TP4a/b/c (Manasi)
Signed-off-by: Khaled Almahallawy
Reviewed-by: Manasi Navare
Tested-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 --
d
v2: Rebased patch on top of:
https://patchwork.freedesktop.org/series/79779/
Fixed phy patterns for JSL/EHL
Add TPS4 support for JSL/EHL
Signed-off-by: Khaled Almahallawy
Signed-off-by: Vidya Srinivas
---
drivers/gpu/drm/i915/display/intel_dp.c | 81 +
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.
v2: Rebased patch on top of Khaled
From: Khaled Almahallawy
Add the missing CP2520 pattern 2 and 3 phy compliance patterns
v2: cosemtic changes
Reviewed-by: Manasi Navare (v1)
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
include/drm/drm_dp_helper.h | 4 +++-
2 files changed, 4 insertions(+
From: Khaled Almahallawy
Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
v2: uniform bit names TP4a/b/c (Manasi)
Signed-off-by: Khaled Almahallawy
Reviewed-by: Manasi Navare
Tested-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 --
d
Please Note: Comment from Ville could not be addressed
as his comments are with respect to base implementation
(design) which are already merged. We need JSL changes
for compliance. Hence pushing the required changes
on top of existing design. Apoligies for that.
v2: Rebased patch on top of Khaled
From: Khaled Almahallawy
Adding support for TPS4 (CP2520 Pattern 3) PHY pattern source tests.
v2: uniform bit names TP4a/b/c (Manasi)
Signed-off-by: Khaled Almahallawy
Reviewed-by: Manasi Navare
Tested-by: Khaled Almahallawy
---
drivers/gpu/drm/i915/display/intel_dp.c | 14 --
d
From: Khaled Almahallawy
Add the missing CP2520 pattern 2 and 3 phy compliance patterns
v2: cosemtic changes
Reviewed-by: Manasi Navare (v1)
Signed-off-by: Khaled Almahallawy
---
drivers/gpu/drm/drm_dp_helper.c | 2 +-
include/drm/drm_dp_helper.h | 4 +++-
2 files changed, 4 insertions(+
1 - 100 of 109 matches
Mail list logo
