== Series Details ==
Series: series starting with [1/3] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern
2 and 3
URL : https://patchwork.freedesktop.org/series/81316/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8962 -> Patchwork_18441
== Series Details ==
Series: series starting with [1/3] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern
2 and 3
URL : https://patchwork.freedesktop.org/series/81316/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be
== Series Details ==
Series: series starting with [1/3] drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern
2 and 3
URL : https://patchwork.freedesktop.org/series/81316/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
476360697e13 drm/dp: Add PHY_TEST_PATTERN CP2520 Pattern 2 and 3
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
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 --
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
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
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
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 --
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
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 --
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
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
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
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
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
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 --
== 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
---
== 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: 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
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 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 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
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
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
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 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
> -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,
== 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
---
== 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...
(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
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
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
== 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
== 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
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
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
>
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
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 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
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
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
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
== 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
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
== 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
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
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 =
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
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
== 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.
-
== 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
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
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
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
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
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
== 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
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
== 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
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/81284/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1697ae1e044d ACPI / LPSS: Resume Cherry Trail PWM controller in
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 =
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 /*
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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 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
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
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
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
1 - 100 of 108 matches
Mail list logo
