From: Oleg Vasilev
Since DP-specific information is stored in driver's structures, every
driver needs to implement subconnector property by itself.
v2: rebase
v3: renamed a function call
Cc: Ben Skeggs
Cc: nouv...@lists.freedesktop.org
Signed-off-by: Jeevan B
Signed-off-by: Oleg Vasilev
Rev
On Tue, 25 Aug 2020, Lyude Paul wrote:
> Just a tiny drive-by cleanup, we can consolidate i915's code for
> checking for MST support into a helper to be shared across drivers.
>
> Signed-off-by: Lyude Paul
> Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 18 ++-
This patch add gvt suspend/resume wrapper into i915: i915_drm_suspend()
and i915_drm_resume(). GVT relies on i915 so suspend gvt ahead of other
i915 sub-routine and resume gvt at last.
V2:
- Direct call into gvt suspend/resume wrapper in intel_gvt.h/intel_gvt.c.
The wrapper and implementation will
The Documentation/DMA-API-HOWTO.txt states that the dma_map_sg() function
returns the number of the created entries in the DMA address space.
However the subsequent calls to the dma_sync_sg_for_{device,cpu}() and
dma_unmap_sg must be called with the original number of the entries
passed to the dma_
This patch save/restore necessary GVT info during i915 suspend/resume so
that GVT enabled QEMU VM can continue running.
Only GGTT and fence regs are saved/restored now. GVT will save GGTT
entries into GVT in suspend routine, and restore the saved entries
and re-init fence regs in resume routine.
This patchset enables GVT suspend/resume so that GVT enabled VM can
continue running after host resuming from suspend state.
V2:
- Change kzalloc/kfree to vzalloc/vfree since the space allocated
from kmalloc may not enough for all saved GGTT entries.
- Keep gvt suspend/resume wrapper in intel_gvt.
== Series Details ==
Series: drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
URL : https://patchwork.freedesktop.org/series/81004/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8925 -> Patchwork_18405
Summary
---
*
== Series Details ==
Series: drm/i915/gt: Implement WA_1406941453 (rev4)
URL : https://patchwork.freedesktop.org/series/78243/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8925_full -> Patchwork_18404_full
Summary
---
== Series Details ==
Series: drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
URL : https://patchwork.freedesktop.org/series/81004/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a73a2592d427 drm/i915/lspcon: Limits to 8 bpc for RGB/YCbCr444
-:22: CHECK:BRACES: Unbalanced brace
LSPCON only supports 8 bpc for RGB/YCbCr444.
Set the correct bpp otherwise it renders blank screen.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2195
Signed-off-by: Kai-Heng Feng
---
drivers/gpu/drm/i915/display/intel_lspcon.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Hi,
> On Aug 25, 2020, at 02:46, Runyan, Arthur J wrote:
>
> I remember some strangeness about the blnclegdisbl. I'll see if I can dig up
> some more.
The register read can be found at [1] and [2].
[1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1871721/comments/119
[2] https://bug
On Tue, Aug 25, 2020 at 07:57:24PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Enable HW Default flip for small PL.
>
> bspec: 52890
> bspec: 53508
> bspec: 53273
>
> v2: rebase to drm-tip
> v3: move from ctx to gt workarounds. Remove whitelist.
> v4: move to rcs WA init
>
== Series Details ==
Series: drm/i915/gt: Implement WA_1406941453 (rev4)
URL : https://patchwork.freedesktop.org/series/78243/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8925 -> Patchwork_18404
Summary
---
**SUCCE
From: Clint Taylor
Enable HW Default flip for small PL.
bspec: 52890
bspec: 53508
bspec: 53273
v2: rebase to drm-tip
v3: move from ctx to gt workarounds. Remove whitelist.
v4: move to rcs WA init
Cc: Matt Atwood
Cc: Matt Roper
Cc: José Roberto de Souza
Signed-off-by: Clint Taylor
---
driv
== Series Details ==
Series: linux-next: build failure after merge of the drm-misc tree
URL : https://patchwork.freedesktop.org/series/81001/
State : failure
== Summary ==
Applying: linux-next: build failure after merge of the drm-misc tree
Using index info to reconstruct a base tree...
M
Hi,
Any update on this? It now conflicts in a few places so it needs a rebase.
Lucas De Marchi
On Wed, Apr 15, 2020 at 3:11 AM Tvrtko Ursulin
wrote:
>
> From: Tvrtko Ursulin
>
> Expose a list of clients with open file handles in sysfs.
>
> This will be a basis for a top-like utility showing pe
Hi all,
After merging the drm-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/gpu/drm/qxl/qxl_display.c: In function
'qxl_display_read_client_monitors_config':
include/drm/drm_modeset_lock.h:167:7: error: implicit declaration of function
'drm_drv_uses_atomic_
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
drivers/gpu/drm/amd/amdgpu/amdgpu_vram_mgr.c
between commits:
cacbbe7c0065 ("drm/amdgpu:
Hi all,
Today's linux-next merge of the drm-misc tree got conflicts in:
drivers/video/fbdev/arcfb.c
drivers/video/fbdev/atmel_lcdfb.c
drivers/video/fbdev/savage/savagefb_driver.c
between commit:
df561f6688fe ("treewide: Use fallthrough pseudo-keyword")
from Linus' tree and commit:
a
== Series Details ==
Series: drm/i915/display: fix uninitialized variable
URL : https://patchwork.freedesktop.org/series/80998/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18402
Summary
---
**FAIL
From: Tom Rix
clang static analysis flags this error
intel_combo_phy.c:268:7: warning: The left expression of the
compound assignment is an uninitialized value.
The computed value will also be garbage
ret &= check_phy_reg(...
~~~ ^
ret has no initial values,
On Tue, Aug 25, 2020 at 11:43:42AM -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.
>
> v2: Only use icl_combo_phy_ddi_translations_edp_hbr3 if low_vswing is
> set
On Tue, Aug 25, 2020 at 11:43:41AM -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
> Cc: Matt Roper
> Signed-off-b
On Tue, Aug 25, 2020 at 11:43:43AM -0700, José Roberto de Souza wrote:
> Update with latest tunning in the table.
>
> BSpec: 21257
> Cc: Matt Roper
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 del
CI failed with lost value on reset
<3> [300.632894] [drm:wa_verify [i915]] *ERROR* GT_REF workaround lost on
before reset! (e18c=3020/0, expected 80008000)
<3> [300.665974] i915/intel_workarounds_live_selftests:
live_gpu_reset_workarounds failed with error -3
I will move the W/A to the RCS engi
== Series Details ==
Series: drm/i915/gt: Implement WA_1406941453 (rev3)
URL : https://patchwork.freedesktop.org/series/78243/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18401
Summary
---
**FAILU
On Tue, Aug 25, 2020 at 02:54:34PM -0700, clinton.a.tay...@intel.com wrote:
> From: Clint Taylor
>
> Enable HW Default flip for small PL.
>
> bspec: 52890
> bspec: 53508
> bspec: 53273
>
> v2: rebase to drm-tip
> v3: move from ctx to gt workarounds. Remove whitelist.
I think we actually want t
From: Clint Taylor
Enable HW Default flip for small PL.
bspec: 52890
bspec: 53508
bspec: 53273
v2: rebase to drm-tip
v3: move from ctx to gt workarounds. Remove whitelist.
Cc: Matt Atwood
Cc: Matt Roper
Cc: José Roberto de Souza
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/i915/gt/inte
Linus Torvalds [25.08.2020 20:19]:
>> Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
>> freeezes. I can still ssh into the machine
>>
>> The three reverts (763fedd6a216, 7ac2d2536dfa and 9e0f9464e2ab) fixes
>> the bug for me.
> Do you get any oops or other indication of wha
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev6)
URL : https://patchwork.freedesktop.org/series/80542/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18400
===
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support
URL : https://patchwork.freedesktop.org/series/80990/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8924_full -> Patchwork_18399_full
===
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev6)
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be check
== Series Details ==
Series: drm/dp, i915, nouveau: Cleanup nouveau HPD and add DP features from
i915 (rev6)
URL : https://patchwork.freedesktop.org/series/80542/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
eb602825d26c drm/nouveau/kms: Fix some indenting in nouveau_dp_detec
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 16 +++-
1 file changed, 3 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 032afc73e2a33..201c0b4335563 100644
Currently in nouveau_connector_ddc_detect() and
nouveau_connector_detect_lvds(), we start the connector probing process
by releasing the previous EDID and informing DRM of the change. However,
since commit 5186421cbfe2 ("drm: Introduce epoch counter to
drm_connector") drm_connector_update_edid_prop
And of course, we'll also need to read the sink count from other drivers
as well if we're checking whether or not it's supported. So, let's
extract the code for this into another helper.
v2:
* Fix drm_dp_dpcd_readb() ret check
* Add back comment and move back sink_count assignment in intel_dp_get_
Since DP 1.3, it's been possible for DP receivers to specify an
additional set of DPCD capabilities, which can take precedence over the
capabilities reported at DP_DPCD_REV.
Basically any device supporting DP is going to need to read these in an
identical manner, in particular nouveau, so let's go
Now that we've extracted i915's code for reading both the normal DPCD
caps and extended DPCD caps into a shared helper, let's start using this
in nouveau to enable us to start checking extended DPCD caps for free.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nou
For whatever reason we currently unset the EDID for DP CEC support when
responding to the connector being unplugged, instead of just doing it in
nouveau_connector_detect() where we set the CEC EDID. This isn't really
needed and could even potentially cause us to forget to unset the EDID
if the conn
Just use drm_dp_dpcd_(readb|writeb)() so we get automatic DPCD logging
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/dispnv50/disp.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/dispnv50/disp.c
b/drivers
Just a tiny drive-by cleanup, we can consolidate i915's code for
checking for MST support into a helper to be shared across drivers.
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_dp.c | 18 ++
include/drm/drm_dp_mst_helper.h | 22
Since other drivers are also going to need to be aware of the sink count
in order to do proper dongle detection, we might as well steal i915's
DP_SINK_COUNT helpers and move them into DRM helpers so that other
dirvers can use them as well.
Note that this also starts using intel_dp_has_sink_count()
Currently we perform both short IRQ handling for DP, and connector
reprobing in the HPD IRQ handler. However since we need to grab
connection_mutex in order to reprobe a connector, in theory we could
accidentally block ourselves from handling any short IRQs until after a
modeset completes if a conn
We're going to be doing the same probing process in nouveau for
determining downstream DP port capabilities, so let's deduplicate the
work by moving i915's code for handling this into a shared helper:
drm_dp_downstream_read_info().
Note that when we do this, we also do make some functional changes
First some backstory here: Currently, we keep track of whether or not
we've enabled MST or not by trying to piggy-back off the MST helpers.
This means that in order to check whether MST is enabled or not, we
actually need to grab drm_dp_mst_topology_mgr.lock.
Back when I originally wrote this, I d
While the way we find the associated connector for an encoder is just
fine for legacy modesetting, it's not correct for nv50+ since that uses
atomic modesetting. For reference, see the drm_encoder kdocs.
Fix this by removing nouveau_encoder_connector_get(), and replacing it
with nv04_encoder_get_c
This adds support for querying the maximum clock rate of a downstream
port on a DisplayPort connection. Generally, downstream ports refer to
active dongles which can have their own pixel clock limits.
Note as well, we also start marking the connector as disconnected if we
can't read the DPCD, sinc
This is another bit that we never implemented for nouveau: dongle
detection. When a "dongle", e.g. an active display adaptor, is hooked up
to the system and causes an HPD to be fired, we don't actually know
whether or not there's anything plugged into the dongle without checking
the sink count. As
Since fa3cdf8d0b09 ("drm/nouveau: Reset MST branching unit before
enabling") we've been clearing DP_MST_CTRL before we start enabling MST.
Since then clearing DP_MST_CTRL in nv50_mstm_new() has been unnecessary
and redundant, so let's remove it.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
No functional changes.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8db9216d52c69..4030806
Noticed this while going through our DP code - we use an open-coded
version of drm_dp_read_desc() instead of just using the helper, so
change that. This will also let us use quirks in the future if we end up
needing them.
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nou
Since this actually logs accesses, we should probably always be using
this imho…
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/dr
Most of the reason I'm asking for an RFC here is because this
code pulls a lot of code out of i915 and into shared DP helpers.
Anyway-nouveau's HPD related code has been collecting dust for a while.
Other then the occasional runtime PM related and MST related fixes,
we're missing a lot of nice thi
Signed-off-by: Lyude Paul
Reviewed-by: Ben Skeggs
---
drivers/gpu/drm/nouveau/nouveau_dp.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_dp.c
b/drivers/gpu/drm/nouveau/nouveau_dp.c
index 8a0f7994e1aeb..ee778ddc95fae 100644
--- a/driv
On Wed, 2020-08-19 at 13:33 -0700, José Roberto de Souza wrote:
> TGL made stepping a litte mess, workarounds refer to the stepping of
> the IP(GT or Display) not of the GPU stepping so it would already
> require the same solution as used in commit 96c5a15f9f39
> ("drm/i915/kbl: Fix revision ID che
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support
URL : https://patchwork.freedesktop.org/series/80990/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18399
=
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display: Compute has_drrs after
compute has_psr
URL : https://patchwork.freedesktop.org/series/80989/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8924_full -> Patchwork_18398_full
==
== Series Details ==
Series: series starting with [v2,1/3] drm/i915/display/tgl: Use TGL DP tables
for eDP ports without low power support
URL : https://patchwork.freedesktop.org/series/80990/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5b6227b45a69 drm/i915/display/tgl: Use
Update with latest tunning in the table.
BSpec: 21257
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i91
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
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_ddi.c | 52
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.
v2: Only use icl_combo_phy_ddi_translations_edp_hbr3 if low_vswing is
set as EHL combo phy supports HBR3 (Matt R)
Cc: Lee Shawn C
Cc: Khaled Almahallawy
On Tue, Aug 25, 2020 at 9:32 AM Harald Arnesen wrote:
>
> > For posterity, I'm told the fix is [1].
> >
> > [1]
> > https://lore.kernel.org/intel-gfx/20200821123746.16904-1-j...@8bytes.org/
>
> Doesn't fix it for me. As soon as I start XFCE, the mouse and keyboard
> freeezes. I can still ssh into
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/display: Compute has_drrs after
compute has_psr
URL : https://patchwork.freedesktop.org/series/80989/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18398
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 de
Supported and enabled are different things so printing both.
v3: using drrs->type instead of vbt.drrs_type
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 i
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: https://gitlab.freedesktop.org/drm/in
Jani Nikula [25.08.2020 11:55]:
> On Fri, 21 Aug 2020, Pavel Machek wrote:
>> On Thu 2020-08-20 09:16:18, Linus Torvalds wrote:
>>> On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek wrote:
>>> >
>>> > Yes, it seems they make things work. (Chris asked for new patch to be
>>> > tested, so I am switchin
== Series Details ==
Series: drm/i915/fbc: Disable fbc with VT-d also with cometlake
URL : https://patchwork.freedesktop.org/series/80977/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8924_full -> Patchwork_18397_full
Summ
== Series Details ==
Series: drm/i915/fbc: Disable fbc with VT-d also with cometlake
URL : https://patchwork.freedesktop.org/series/80977/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18397
Summary
--
Hi,
On 8/25/20 12:44 PM, Patchwork wrote:
*Patch 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/80976/
*State:*failure
*Details:*
https://intel-gfx-ci.01.org/tree/drm-tip
== 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/80976/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8924 -> Patchwork_18396
===
Both VT-d and FBC enabled that caused display flicker
issue very randomly. According to sighting report,
it recommend to disable FBC to workaround this issue.
Cc: Ville Syrjälä
Cc: Rodrigo Vivi
Cc: Mika Kuoppala
Cc: Jani Nikula
Cc: William Tseng
Signed-off-by: Lee Shawn C
---
drivers/gpu/dr
== 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/80976/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ef85c003b00a 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 i
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
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
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
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
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
Hi All,
I missed on 64-bit divide caused by pwm_state.period and pwm_state.duty_cycle
being changed
to u64-s in 5.9. This new version fixes this, otherwise this is identical to v6:
Here is v6 of my patch series converting the i915 driver's code for
controlling the panel's backlight with an exter
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
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
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
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
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
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 turned off from the _PS3 method of the graphics-card dev:
Method (_PS3, 0, Serialized) // _PS3: Power State 3
{
...
PWMB = PWMC /* \_SB_.PCI
On Fri, 21 Aug 2020, Pavel Machek wrote:
> On Thu 2020-08-20 09:16:18, Linus Torvalds wrote:
>> On Thu, Aug 20, 2020 at 2:23 AM Pavel Machek wrote:
>> >
>> > Yes, it seems they make things work. (Chris asked for new patch to be
>> > tested, so I am switching to his kernel, but it survived longer
Hi Nischal,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Nischal-Varide/Critical-KclockWork-Fixes-intel_atomi-c-PossibleNull/20200819-193249
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-m021-2020
Hi Nischal,
Thank you for the patch! Perhaps something to improve:
url:
https://github.com/0day-ci/linux/commits/Nischal-Varide/Critical-KclockWork-Fixes-intel_atomi-c-PossibleNull/20200819-193249
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: i386-randconfig-m021-2020
Op 19-08-2020 om 16:08 schreef Maarten Lankhorst:
> We want to introduce backoff logic, but we need to lock the
> pool object as well for command parsing. Because of this, we
> will need backoff logic for the engine pool obj, move the batch
> validation up slightly to eb_lookup_vmas, and the actual
> -Original Message-
> From: Shankar, Uma
> Sent: 19 August 2020 13:44
> To: Laxminarayan Bharadiya, Pankaj
> ; jani.nik...@linux.intel.com;
> dan...@ffwll.ch; intel-gfx@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org; ville.syrj...@linux.intel.com;
> dani...@collabora.com; La
95 matches
Mail list logo
