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 consume
This commit removes a check where we would skip writing the ctrl register
and then setting the update bit in case the ctrl register already contains
the correct values.
In a perfect world skipping the update should be fine in these cases, but
on Cherry Trail devices the AML code in the GFX0 device
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 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
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
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
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
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
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
Hi All,
Unfortunately while testing some unrelated things I found another issue with
this series related to the CHT ACPI GFX0._PS3 code poking the PWM controller
in unexpected ways.
This new version contains a new patch: "[PATCH v8 07/17] pwm: lpss: Always
update state and set update bit" fixing
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 inden
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
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
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
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
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 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
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
== 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/81176/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
48148eeaab72 ACPI / LPSS: Resume Cherry Trail PWM controller in
== 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/81176/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8941 -> Patchwork_18422
===
== 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/81176/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8941_full -> Patchwork_18422_full
=
From: Brian Starkey
Add a test which makes commits using the writeback connector, and
checks the output buffer hash to make sure it is/isn't written as
appropriate.
Changes since V8 (Arkadiusz Hiler):
* Add short description
Changes since V7 (Maxime Ripard):
* Make fb_fill cross-platform
Chang
Hi,
A couple of months ago I updated and re-submitted a patchset made by
Brian Starkey and Liviu Dudau for adding a writeback connectors test to
IGT. It is important to highlight that DRM already have writeback
connectors support, which is a way to expose in DRM the hardware
functionality from dis
From: Brian Starkey
To use writeback buffers as a CRC source, we need to be able to hash
them. Implement a simple FVA-1a hashing routine for this purpose.
Doing a bytewise hash on the framebuffer directly can be very slow if
the memory is noncached. By making a copy of each line in the FB first
From: Brian Starkey
Add tests for the WRITEBACK_PIXEL_FORMATS, WRITEBACK_OUT_FENCE_PTR and
WRITEBACK_FB_ID properties on writeback connectors, ensuring their
behaviour is correct.
Changes since V8:
* Remove unnecessary fence cleanup on prepare commit.
Changes since V7 (Maxime Ripard and Petri L
From: Brian Starkey
Add support in igt_kms for writeback connectors, with the ability
to attach framebuffers.
v8: Remove unnecessary fence cleanup on prepare commit.
v5: Rebase and add DRM_CLIENT_CAP_WRITEBACK_CONNECTORS before
drmModeGetResources()
Signed-off-by: Brian Starkey
[rebased and u
26 matches
Mail list logo
