On 2020-08-24 at 10:43:45 -0700, José Roberto de Souza wrote:
> Supported and enabled are different things so printing both.
>
> Cc: Anshuman Gupta
> Cc: Srinivas K
> Cc: Hariom Pandey
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_display_debugfs.c | 12
Use semicolons and braces.
Signed-off-by: Joe Perches
---
drivers/gpu/drm/i915/gt/gen8_ppgtt.c | 8 +---
drivers/gpu/drm/i915/gt/intel_gt_requests.c| 6 --
drivers/gpu/drm/i915/gt/selftest_workarounds.c | 6 --
drivers/gpu/drm/i915/intel_runtime_pm.c| 6 --
There are many comma separated statements in the kernel.
See:https://lore.kernel.org/lkml/alpine.DEB.2.22.394.2008201856110.2524@hadrien/
Convert the comma separated statements that are in if/do/while blocks
to use braces and semicolons.
Many comma separated statements still exist but those are
Hi Chris,
On 2020/8/23 0:02, Chris Wilson wrote:
Beware that the address size for x86-32 may exceed unsigned long.
[0.368971] UBSAN: shift-out-of-bounds in drivers/iommu/intel/iommu.c:128:14
[0.369055] shift exponent 36 is too large for 32-bit type 'long unsigned
int'
If we don't
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/display: Compute has_drrs after
compute has_psr
URL : https://patchwork.freedesktop.org/series/80953/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8921_full -> Patchwork_18395_full
On Mon, 2020-08-24 at 16:57 -0700, Matt Roper wrote:
> On Mon, Aug 24, 2020 at 04:45:31PM -0700, Souza, Jose wrote:
> > On Mon, 2020-08-24 at 16:22 -0700, Matt Roper wrote:
> > > On Wed, Aug 19, 2020 at 11:51:44AM -0700, José Roberto de Souza wrote:
> > > > Reusing icl_get_combo_buf_trans() for
On Mon, Aug 24, 2020 at 04:45:31PM -0700, Souza, Jose wrote:
> On Mon, 2020-08-24 at 16:22 -0700, Matt Roper wrote:
> > On Wed, Aug 19, 2020 at 11:51:44AM -0700, José Roberto de Souza wrote:
> > > Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
> > > being used when the eDP
On Wed, Aug 19, 2020 at 11:51:46AM -0700, José Roberto de Souza wrote:
> Update with latest tunning in the table.
>
> BSpec: 21257
> Signed-off-by: José Roberto de Souza
It looks like we now have separate tables for EHL and JSL; we probably
need to handle them with separate tables now.
> ---
>
On Mon, 2020-08-24 at 16:22 -0700, Matt Roper wrote:
> On Wed, Aug 19, 2020 at 11:51:44AM -0700, José Roberto de Souza wrote:
> > Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
> > being used when the eDP port don't support low power voltage swing table.
> >
> > Cc: Lee
On Wed, Aug 19, 2020 at 11:51:44AM -0700, José Roberto de Souza wrote:
> Reusing icl_get_combo_buf_trans() for eDP was causing the wrong table
> being used when the eDP port don't support low power voltage swing table.
>
> Cc: Lee Shawn C
> Cc: Khaled Almahallawy
> Signed-off-by: José Roberto
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
On Mon, Aug 03, 2020 at 04:33:45PM -0700, Jose Souza wrote:
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
From: Anshuman Gupta <
anshuman.gu...@intel.com
>
DC6 is not supported on DG1, so change the allowed DC mask for DG1.
Cc: Uma Shankar <
uma.shan...@intel.com
>
Signed-off-by:
On Fri, Aug 21, 2020 at 11:48:37PM -0700, Khaled Almahallawy wrote:
> Source needs to write DPCD 103-106 after receiving a PHY request to change
> swing/pre-emphasis after reading DPCD 206-207. This is especially needed if
> there is a retimer between source and sink and the retimer implements
On Mon, Aug 24, 2020 at 07:46:30PM +, Shankar, Uma wrote:
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Monday, August 24, 2020 11:46 PM
> > To: Shankar, Uma
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Add an extra
On Mon, Aug 24, 2020 at 09:15:52AM +0530, Nischal Varide wrote:
> There is a possble Null Pointer dereference in intel_atomic.c and this
> patch fixes the same by introducting a check to old_state, new_state
> old_conn_state and new_conn_state variables.
Not possible. In fact none of the supposed
> -Original Message-
> From: Ville Syrjälä
> Sent: Monday, August 24, 2020 11:46 PM
> To: Shankar, Uma
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/display: Add an extra vblank wait
> before fbc activation
>
> On Mon, Aug 17, 2020 at 01:14:18PM
On Mon, 2020-08-24 at 12:24 -0700, Lucas De Marchi wrote:
> On Mon, Aug 03, 2020 at 04:24:17PM -0700, Jose Souza wrote:
> > On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
> > > From: Matt Roper <
> > > matthew.d.ro...@intel.com
> > >
> > >
> > > DG1 does some additional pcode/uncore
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/display: Compute has_drrs after
compute has_psr
URL : https://patchwork.freedesktop.org/series/80953/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8921 -> Patchwork_18395
On Mon, Aug 03, 2020 at 04:24:17PM -0700, Jose Souza wrote:
On Fri, 2020-07-24 at 14:39 -0700, Lucas De Marchi wrote:
From: Matt Roper <
matthew.d.ro...@intel.com
>
DG1 does some additional pcode/uncore handshaking at
boot time; this handshaking must complete before various other pcode
I remember some strangeness about the blnclegdisbl. I'll see if I can dig up
some more.
-Original Message-
From: Ville Syrjälä
Sent: Monday, August 24, 2020 11:05 AM
To: Kai-Heng Feng
Cc: Runyan, Arthur J ; Vivi, Rodrigo
; intel-gfx
Subject: Re: [Regression] "drm/i915: Implement
On Mon, Aug 17, 2020 at 01:14:18PM +0530, Uma Shankar wrote:
> Add an extra vblank before fbc is activated.
> WA: 1409689360
> Corruption with FBC around plane 1A enabling. In the Frame Buffer
> Compression programming sequence "Display Plane Enabling with FBC"
> add a wait for vblank between
== Series Details ==
Series: drm/i915/gt: Show engine properties in the pretty printer
URL : https://patchwork.freedesktop.org/series/80947/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8918_full -> Patchwork_18394_full
On Mon, Aug 17, 2020 at 02:17:49PM +0800, Kai-Heng Feng wrote:
>
>
> > On Aug 17, 2020, at 00:22, Runyan, Arthur J
> > wrote:
> >
> > You'll need to read out the DDI_BUF_TRANS_* and DISPIO_CR_TX_BMU_CR0
> > registers at boot before i915 programs them and compare with what driver
> >
Supported and enabled are different things so printing both.
Cc: Anshuman Gupta
Cc: Srinivas K
Cc: Hariom Pandey
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git
DRRS and PSR can't be enable together, so giving preference to PSR
as it allows more power-savings by complete shutting down display,
so to guarantee this, it should compute DRRS state after compute PSR.
Cc: Srinivas K
Cc: Hariom Pandey
Reviewed-by: Anshuman Gupta
Signed-off-by: José Roberto
Changes in the configuration could cause PSR to be compatible and
enabled so driver must also be able to disable DRRS when doing
fastsets.
v2: Fixed name of DRRS compute function (Anshuman)
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/209
Closes:
On Mon, 2020-08-24 at 14:21 +0530, Anshuman Gupta wrote:
> On 2020-08-20 at 22:53:53 +0530, José Roberto de Souza wrote:
> > Changes in the configuration could cause PSR to be compatible and
> > enabled so driver must also be able to disable DRRS when doing
> > fastsets.
> >
> > Closes:
> >
On Mon, 2020-08-24 at 16:24 +0530, Anshuman Gupta wrote:
> On 2020-08-20 at 10:23:52 -0700, José Roberto de Souza wrote:
> > DRRS and PSR can't be enable together, so giving preference to PSR
> > as it allows more power-savings by complete shutting down display,
> > so to guarantee this, it should
== 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/80943/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8918_full -> Patchwork_18393_full
On Fri, Aug 21, 2020 at 01:43:39PM -0400, Lyude Paul wrote:
> [...]
> > The wording is a bit unclear, but as I understand the Standard only
> > calls for the above:
> >
> > """
> > A DP upstream device shall read the capability from DPCD Addresses 00080h
> > through 00083h. A DP Branch device
Reduce the preemption timeout to 150ms (from infinity for tgl! tsk,
tsk) so that the preemption hang tests run quicker.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 37 --
1 file changed, 26 insertions(+), 11 deletions(-)
diff --git
== Series Details ==
Series: drm/i915/gt: Show engine properties in the pretty printer
URL : https://patchwork.freedesktop.org/series/80947/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8918 -> Patchwork_18394
Summary
== Series Details ==
Series: drm/i915/gt: Show engine properties in the pretty printer
URL : https://patchwork.freedesktop.org/series/80947/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
6ef144300979 drm/i915/gt: Show engine properties in the pretty printer
-:48:
== Series Details ==
Series: series starting with [1/5] Fixing Possible Null Pointer Dereference
URL : https://patchwork.freedesktop.org/series/80939/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8918_full -> Patchwork_18392_full
When debugging the engine state, include the user properties that may,
or may not, have been adjusted by the user/test.
For example,
vecs0
...
Properties:
heartbeat_interval_ms: 2500 [default 2500]
max_busywait_duration_ns: 8000 [default 8000]
Hi Logan/All,
I have added a check for the sg_dma_len == 0 :
"""
} __sgt_iter(struct scatterlist *sgl, bool dma) {
struct sgt_iter s = { .sgp = sgl };
+ if (sgl && sg_dma_len(sgl) == 0)
+ s.sgp = NULL;
if (s.sgp) {
.
"""
at location [1].
but it
> On Aug 19, 2020, at 12:48 PM, Matthew Wilcox (Oracle)
> wrote:
>
> This patch seris started out as part of the THP patch set, but it has
> some nice effects along the way and it seems worth splitting it out and
> submitting separately.
>
> Currently find_get_entry() and find_lock_entry()
== 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/80943/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8918 -> Patchwork_18393
== 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/80943/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
23eeb608a11a ACPI / LPSS: Resume Cherry Trail PWM controller in
Before this commit a suspend + resume of the LPSS PWM controller
would result in the controller being reset to its defaults of
output-freq = clock/256, duty-cycle=100%, until someone changes
to the output-freq and/or duty-cycle are made.
This problem has been masked so far because the main
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
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
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
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
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 /*
Implement the pwm_ops.get_state() method to complete the support for the
new atomic PWM API.
Reviewed-by: Andy Shevchenko
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
Changes in v5:
- Fix an
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
Replace the enable, disable and config pwm_ops with an apply op,
to support the new atomic PWM API.
Reviewed-by: Andy Shevchenko
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_cycle
are now u64
Changes
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
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
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
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
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
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
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 =
Hi All,
Here is v6 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an external PWM controller to
use the atomic PWM API. See below for the changelog.
This version of the series has been rebased on 5.9-rc1 and has
a Reviewed-by or Acked-by for all
== Series Details ==
Series: series starting with [1/5] Fixing Possible Null Pointer Dereference
URL : https://patchwork.freedesktop.org/series/80939/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8918 -> Patchwork_18392
On 2020-08-20 at 10:23:52 -0700, José Roberto de Souza wrote:
> DRRS and PSR can't be enable together, so giving preference to PSR
> as it allows more power-savings by complete shutting down display,
> so to guarantee this, it should compute DRRS state after compute PSR.
>
> Cc: Srinivas K
> Cc:
Chris Wilson writes:
> As the error capture will compress user buffers as directed to by the
> user, it can take an arbitrary amount of time and space. Break up the
> compression loops with a call to cond_resched(), that will allow other
> processes to schedule (avoiding the soft lockups) and
== Series Details ==
Series: series starting with [1/5] Fixing Possible Null Pointer Dereference
URL : https://patchwork.freedesktop.org/series/80939/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
e2dc6f705c6e Fixing Possible Null Pointer Dereference
3b7087647897 Fixing
Fixing a Possible Null Pointer Dereference in intel_crt.c.
Introduced a Null Check for dev_priv pointer before dereferencing.
Signed-off-by: Nischal Varide
---
drivers/gpu/drm/i915/display/intel_crt.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
There is a possble Null Pointer dereference in intel_atomic.c and this
patch fixes the same by introducting a check to old_state, new_state
old_conn_state and new_conn_state variables.
Signed-off-by: Nischal Varide
---
drivers/gpu/drm/i915/display/intel_atomic.c | 5 +
1 file changed, 5
A possible Null Pointer dereference of new_state,old_state, new_crtc_state
pointers from intel_tv.c is handled in this patch.
Signed-off-by: Nischal Varide
---
drivers/gpu/drm/i915/display/intel_tv.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git
A Possible Null Pointer Dereference of a Pointer obj is handled in
intel_displa.c .This patch introduced a check on pointer obj before
dereferencing
Signed-off-by: Nischal Varide
---
drivers/gpu/drm/i915/display/intel_display.c | 22 +++-
1 file changed, 12 insertions(+), 10
This Patch addresses a Possible Null Pointer Dereference of variables
new_stae, new_conn_state and old_state, old_conn_state in intel_sdvo.c
Signed-off-by: Nischal Varide
---
drivers/gpu/drm/i915/display/intel_sdvo.c | 3 +++
1 file changed, 3 insertions(+)
diff --git
Hi Petri,
On Mon, 2020-08-24 at 12:26 +0300, Petri Latvala wrote:
> On Mon, Aug 24, 2020 at 10:42:10AM +0200, Janusz Krzysztofik wrote:
> > On Fri, 2020-08-21 at 17:40 +, Patchwork wrote:
> > > Patch Details
> > > Series: tests/core_hotunplug: Fixes and enhancements (rev4)
> > > URL:
On Mon, Aug 24, 2020 at 10:42:10AM +0200, Janusz Krzysztofik wrote:
> On Fri, 2020-08-21 at 17:40 +, Patchwork wrote:
> > Patch Details
> > Series: tests/core_hotunplug: Fixes and enhancements (rev4)
> > URL:https://patchwork.freedesktop.org/series/79671/
> > State: failure
>
On 2020-08-20 at 22:53:53 +0530, José Roberto de Souza wrote:
> Changes in the configuration could cause PSR to be compatible and
> enabled so driver must also be able to disable DRRS when doing
> fastsets.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/209
> Closes:
On Fri, 2020-08-21 at 17:40 +, Patchwork wrote:
> Patch Details
> Series: tests/core_hotunplug: Fixes and enhancements (rev4)
> URL: https://patchwork.freedesktop.org/series/79671/
> State:failure
> Details: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_4901/index.html
>
On 2020-08-19 at 10:04:08 +0530, Nischal Varide wrote:
> This patch fixes the Critical Klock work Error and in this case a
> Possible Null Pointer Dereference has been addressed with a Null check
> before dereferencing
>
> Signed-off-by: Nischal Varide
> ---
>
On 2020-08-19 at 10:04:09 +0530, Nischal Varide wrote:
> This Patch fixes the Critical KlockWork Errors and here a Possible Null
> Pointer Dereferencing is addressed with a Null Pointer check before
> Dereferencing
>
> Signed-off-by: Nischal Varide
> ---
>
71 matches
Mail list logo
