From: Hans Verkuil
Signed-off-by: Hans Verkuil
[sa...@chromium.org:
- rebased
- removed polling-related changes
- moved the calls to drm_dp_cec_(un)set_edid() into the next patch
]
Signed-off-by: Sam McNally
---
.../display/amdgpu_dm/amdgpu_dm_mst_types.c | 2 +-
drivers/gpu/drm/drm_dp_
== Series Details ==
Series: series starting with [1/4] drm/i915/display: Ignore
IGNORE_PSR2_HW_TRACKING for platforms without sel fetch
URL : https://patchwork.freedesktop.org/series/81201/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8948 -> Patchwork_18426
===
Another step towards PSR2 selective fetch, here programming plane
selective fetch registers and MAN_TRK_CTL enabling selective fetch but
for now it is fetching the whole area of the planes.
The damaged area calculation will come as next and final step.
BSpec: 55229
Cc: Gwan-gyeong Mun
Cc: Ville S
Enabling it to check if it causes regressions in CI but the feature is
still not ready to be enabled by default.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_params.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_params.h
b/d
In case PSR2 is disabled by debugfs dc3co_enabled and
psr2_sel_fetch_enabled were still being set causing some code paths
to be executed were it should not.
We have tests for PSR1 and PSR2 so keep those features disabled when
PSR1 is active but PSR2 is supported is important.
Cc: Gwan-gyeong Mun
For platforms without selective fetch this register is reserved so
do not write 0 to it.
Cc: Gwan-gyeong Mun
Cc: Ville Syrjälä
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_psr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i
== Series Details ==
Series: drm/dp_mst: Support remote i2c writes
URL : https://patchwork.freedesktop.org/series/81191/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8946_full -> Patchwork_18424_full
Summary
---
**S
topic/nouveau-i915-dp-helpers-and-cleanup-2020-08-31-1:
UAPI Changes:
None
Cross-subsystem Changes:
* Moves a bunch of miscellaneous DP code from the i915 driver into a set
of shared DRM DP helpers
Core Changes:
* New DRM DP helpers (see above)
Driver Changes:
* Implements usage of the afo
== Series Details ==
Series: drm/i915: make object creation avoid regions layering.
URL : https://patchwork.freedesktop.org/series/81197/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/comp
From: Dave Airlie
This looked like indirect ptr for not much reason in the create
object path, I just wonder why it couldn't be simpler like this,
The tests aren't cleaned up but this was more of is this a good idea
test patch.
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 16 ---
dr
Hi Sam,
Thanks a lot for the review. I will address your comments in v7.
For those that are not addressed, please see my reply inline.
Regards,
Anitha
> -Original Message-
> From: Sam Ravnborg
> Sent: Thursday, August 20, 2020 1:10 PM
> To: Chrisanthus, Anitha
> Cc: dri-de...@lists.fre
On Thu, Aug 27, 2020 at 01:04:54PM +0800, Kai Heng Feng wrote:
> Hi Ville,
>
> > On Aug 27, 2020, at 12:24 AM, Ville Syrjälä
> > wrote:
> >
> > On Wed, Aug 26, 2020 at 01:21:15PM +0800, Kai-Heng Feng wrote:
> >> LSPCON only supports 8 bpc for RGB/YCbCr444.
> >>
> >> Set the correct bpp otherwi
On Mon, Aug 31, 2020 at 07:03:47PM +, Srivatsa, Anusha wrote:
>
>
> > -Original Message-
> > From: Ville Syrjälä
> > Sent: Monday, August 31, 2020 6:42 AM
> > To: Srivatsa, Anusha
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize P
> -Original Message-
> From: Ville Syrjälä
> Sent: Monday, August 31, 2020 6:42 AM
> To: Srivatsa, Anusha
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/pll: Centralize PLL_ENABLE register
> lookup
>
> On Fri, Aug 28, 2020 at 02:58:32PM -0700, Anusha
On Mon, 31 Aug 2020, Ville Syrjälä wrote:
> On Fri, Aug 28, 2020 at 09:19:40AM +0300, Jani Nikula wrote:
>> The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
>> used for the embedded display. Add support for using it via the EDID
>> override mechanism.
>
> Abusing the override
Hi,
On 8/31/20 3:15 PM, Thierry Reding wrote:
On Mon, Aug 31, 2020 at 01:46:28PM +0200, Hans de Goede wrote:
Hi,
On 8/31/20 1:10 PM, Thierry Reding wrote:
On Sun, Aug 30, 2020 at 02:57:42PM +0200, Hans de Goede wrote:
Before this commit a suspend + resume of the LPSS PWM controller
would res
== Series Details ==
Series: drm/dp_mst: Support remote i2c writes
URL : https://patchwork.freedesktop.org/series/81191/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8946 -> Patchwork_18424
Summary
---
**SUCCESS**
For DP MST outputs, the i2c device currently only supports transfers
that can be implemented using remote i2c reads. Such transfers must
consist of zero or more write transactions followed by one read
transaction. DDC/CI commands require standalone write transactions and
hence aren't supported.
Si
On Fri, Aug 28, 2020 at 02:58:32PM -0700, Anusha Srivatsa wrote:
> We currenty check for platform at multiple parts in the driver
> to grab the correct PLL. Let us begin to centralize it through a
> helper function.
>
> Suggested-by: Matt Roper
> Cc: Matt Roper
> Signed-off-by: Anusha Srivatsa
On Fri, Aug 28, 2020 at 09:19:40AM +0300, Jani Nikula wrote:
> The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
> used for the embedded display. Add support for using it via the EDID
> override mechanism.
Abusing the override for this feels a bit odd.
Also I have a vague reco
On Mon, Aug 31, 2020 at 01:26:46PM +0200, Hans de Goede wrote:
> Hi,
>
> On 8/31/20 1:13 PM, Thierry Reding wrote:
> > On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
> > > This commit removes a check where we would skip writing the ctrl register
> > > and then setting the update bi
On Mon, Aug 31, 2020 at 01:46:28PM +0200, Hans de Goede wrote:
> Hi,
>
> On 8/31/20 1:10 PM, Thierry Reding wrote:
> > On Sun, Aug 30, 2020 at 02:57:42PM +0200, Hans de Goede wrote:
> > > Before this commit a suspend + resume of the LPSS PWM controller
> > > would result in the controller being re
Hi,
On 8/31/20 10:56 AM, Andy Shevchenko wrote:
On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
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 w
Hi,
On 8/31/20 1:10 PM, Thierry Reding wrote:
On Sun, Aug 30, 2020 at 02:57:42PM +0200, Hans de Goede wrote:
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 cha
Hi,
On 8/31/20 1:13 PM, Thierry Reding wrote:
On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
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 wor
On Sun, Aug 30, 2020 at 02:57:48PM +0200, Hans de Goede wrote:
> 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
On Sun, Aug 30, 2020 at 02:57:49PM +0200, Hans de Goede wrote:
> 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 be
On Sun, Aug 30, 2020 at 02:57:46PM +0200, Hans de Goede wrote:
> 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
On Sun, Aug 30, 2020 at 02:57:47PM +0200, Hans de Goede wrote:
> 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 m
On Sun, Aug 30, 2020 at 02:57:45PM +0200, Hans de Goede wrote:
> 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-div
On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
> 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
On Sun, Aug 30, 2020 at 02:57:44PM +0200, Hans de Goede wrote:
> 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 du
On Sun, Aug 30, 2020 at 02:57:44PM +0200, Hans de Goede wrote:
> 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 du
On Sun, Aug 30, 2020 at 02:57:42PM +0200, Hans de Goede wrote:
> 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
On Sun, Aug 30, 2020 at 02:57:41PM +0200, Hans de Goede wrote:
> 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_p
On Sun, Aug 30, 2020 at 02:57:39PM +0200, Hans de Goede wrote:
> 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 b
On Sun, Aug 30, 2020 at 02:57:40PM +0200, Hans de Goede wrote:
> 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 clo
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/opregion: add support for
mailbox #5 EDID
URL : https://patchwork.freedesktop.org/series/81179/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8944_full -> Patchwork_18423_full
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/opregion: add support for
mailbox #5 EDID
URL : https://patchwork.freedesktop.org/series/81179/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8944 -> Patchwork_18423
==
On Sun, Aug 30, 2020 at 02:57:43PM +0200, Hans de Goede wrote:
> 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
== Series Details ==
Series: series starting with [v2,1/2] drm/i915/opregion: add support for
mailbox #5 EDID
URL : https://patchwork.freedesktop.org/series/81179/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be chec
The ACPI OpRegion Mailbox #5 ASLE extension may contain an EDID to be
used for the embedded display. Add support for using it via the EDID
override mechanism.
Note that the override EDID may be later reset or changed via debugfs,
as usual.
v2: remember to set override_edid = true.
Cc: Uma Shanka
If a panel's EDID is broken, there may be an override EDID set in the
ACPI OpRegion mailbox #5. Use it if available.
Cc: Uma Shankar
Reviewed-by: Uma Shankar
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gp
> -Original Message-
> From: Jani Nikula
> Sent: Friday, August 28, 2020 11:50 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani ; Shankar, Uma
>
> Subject: [PATCH 2/2] drm/i915/dp: use opregion mailbox #5 EDID for eDP, if
> available
>
> If a panel's EDID is broken, there m
> -Original Message-
> From: Jani Nikula
> Sent: Friday, August 28, 2020 11:58 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Shankar, Uma
> Subject: Re: [PATCH 1/2] drm/i915/opregion: add support for mailbox #5 EDID
>
> On Fri, 28 Aug 2020, Jani Nikula wrote:
> > The ACPI OpRegion M
45 matches
Mail list logo
