Am 26.06.20 um 06:43 schrieb Sumit Semwal:
On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote:
Ignoring everything else ...
On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula wrote:
As a side note, there seem to be extra checks in place for acks when
applying non-i915 patches to drm-intel; there are
Cc Matt and Daniele
On Thu, Jun 25, 2020 at 9:38 PM Dave Airlie wrote:
>
> I can't figure this out easily so I'd thought I'd just ask, but does
> DG1 have VRAM > PCIE aperture, I'm not sure I've see any mention of
We'd need to go via lmem since there's no mappable aperture. There are
a few patch
Hi Michał,
thanks for review.
On Thu, 2020-06-25 at 21:42 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:12)
> > Verify if an additional address space associated with an open device
> > file descriptor is cleaned up correctly on device hotunplug.
> >
> > v2: rebase
Quoting Chris Wilson (2020-06-25 18:42:41)
> Quoting Christian König (2020-06-25 16:47:09)
> > Am 25.06.20 um 17:10 schrieb Chris Wilson:
> > > We have the DAG of fences, we can use that information to avoid adding
> > > an implicit coupling between execution contexts.
> >
> > No, we can't. And it
Hi Michał,
Thanks for review.
On Thu, 2020-06-25 at 21:51 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:13)
> > GEM objects belonging to user file descriptors still open on device
> > hotunplug may exhibit still more driver issues. Add a subtest that
> > implement
Hi Michał,
On Thu, 2020-06-25 at 22:02 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:15)
> > Verify if a device with a GEM batch job still running on a GPU can be
> > hot-unplugged cleanly and released, then recovered.
> >
> > v2: rebase on upstream
> >
> > Signed
Hi Daniel,
could you help my explaining to Christoph why this doesn't work?
We have exercised this multiple times in the past month and I'm really
surprised that anybody is still trying this approach.
Thanks,
Christian.
Am 26.06.20 um 10:54 schrieb Christian König:
Am 26.06.20 um 10:10 schr
On Thu, Jun 25, 2020 at 11:00:03PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The linetime watermark is a 9 bit value, which gives us
> a maximum linetime of just below 64 usec. If the linetime
> exceeds that value we currently just discard the high bits
> and program the rest into the
== Series Details ==
Series: Send a hotplug when edid changes (rev8)
URL : https://patchwork.freedesktop.org/series/62816/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8661_full -> Patchwork_18016_full
Summary
---
*
== Series Details ==
Series: mm: Skip opportunistic reclaim for dma pinned pages
URL : https://patchwork.freedesktop.org/series/78795/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
92687c80eb20 mm: Skip opportunistic reclaim for dma pinned pages
-:36: WARNING:BAD_SIGN_OFF: Dupl
Hi Michał,
Thanks for review.
On Thu, 2020-06-25 at 17:27 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:08)
> > The purpose of debug messages displayed by the test is to make
> > identification of a subtest phase that fails more easy. Since issues
> > exhibited by
Hi Michał,
On Thu, 2020-06-25 at 21:23 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:09)
> > Future subtests may want to access PCI attributes of the device after
> > driver unbind. Refactor prepare() helper.
> >
> > v2: rebase on upstream
> >
> > Signed-off-by:
== Series Details ==
Series: mm: Skip opportunistic reclaim for dma pinned pages
URL : https://patchwork.freedesktop.org/series/78795/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8665 -> Patchwork_18019
Summary
---
drm-misc-next-2020-06-26:
drm-misc-next for v5.9:
Cross-subsystem Changes:
- Improve dma-buf docs.
Core Changes:
- Add NV15, Q410, Q401 yuv formats.
- Add uncompressed AFBC modifier.
- Add DP helepr for reading Ignore MSA from DPCD.
- Add missing panel type for some panels
- Optimize drm/mm hole
Hi Michał,
On Thu, 2020-06-25 at 21:57 +0200, Michał Winiarski wrote:
> Quoting Janusz Krzysztofik (2020-06-22 18:44:14)
> > Even if all device file descriptors are closed on device hotunplug,
> > PRIME exported objects may still exists, referenced by still open
> > dma-buf file handles. Add a su
== Series Details ==
Series: drm/i915: implement Wa_14011508470;gen12
URL : https://patchwork.freedesktop.org/series/78799/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8665 -> Patchwork_18020
Summary
---
**SUCCESS*
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/dp: Helper for checking
DDI_BUF_CTL Idle status
URL : https://patchwork.freedesktop.org/series/78800/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1156c88678a4 drm/i915/dp: Helper for checking DDI_BUF_CTL Idl
Quoting Christian König (2020-06-26 09:54:19)
> Am 26.06.20 um 10:10 schrieb Chris Wilson:
> > Quoting Chris Wilson (2020-06-25 18:42:41)
> >> Quoting Christian König (2020-06-25 16:47:09)
> >>> Am 25.06.20 um 17:10 schrieb Chris Wilson:
> We have the DAG of fences, we can use that information
== Series Details ==
Series: series starting with [v3,1/2] drm/i915/dp: Helper for checking
DDI_BUF_CTL Idle status
URL : https://patchwork.freedesktop.org/series/78800/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8665 -> Patchwork_18021
Sure it is gem as usual. gem_ctx_persistance test is absolutely orthogonal to
any hotplug funcitonality.
Also it fails almost on weekly basis.
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
___
Am 26.06.20 um 13:10 schrieb Chris Wilson:
Quoting Christian König (2020-06-26 09:54:19)
[SNIP]
In other words "fence -> userspace -> page fault -> fence" or "fence ->
userspace -> system call -> fence" can easily cause the same problem and
that is not avoidable.
An example
Thread A
== Series Details ==
Series: VRR capable attach prop in i915, VRR debugfs (rev3)
URL : https://patchwork.freedesktop.org/series/78670/
State : failure
== Summary ==
Applying: drm/i915/dp: Attach and set drm connector VRR property
Applying: drm/debug: Expose connector VRR monitor range via debu
== Series Details ==
Series: display/ddi: keep register indexes in a table
URL : https://patchwork.freedesktop.org/series/78806/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
1c318e3abcdc drm/i915: move ICL port F hack to intel_bios
f1e31b8bd6eb drm/i915/display: fix comment on
== Series Details ==
Series: display/ddi: keep register indexes in a table
URL : https://patchwork.freedesktop.org/series/78806/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/i
On Thu, Jun 25, 2020 at 03:08:32PM +0200, Joerg Roedel wrote:
> From: Joerg Roedel
>
> There are no users left, all drivers have been converted to use the
> per-device private pointer offered by IOMMU core.
>
> Signed-off-by: Joerg Roedel
> ---
> arch/x86/include/asm/device.h | 3 ---
> 1 file
== Series Details ==
Series: display/ddi: keep register indexes in a table
URL : https://patchwork.freedesktop.org/series/78806/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8665 -> Patchwork_18023
Summary
---
**FAI
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/bios: Parse HOBL parameter
URL : https://patchwork.freedesktop.org/series/78807/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: series starting with [v3,1/3] drm/i915/bios: Parse HOBL parameter
URL : https://patchwork.freedesktop.org/series/78807/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_8665 -> Patchwork_18024
Summ
On Fri, Jun 26, 2020 at 9:03 AM Christian König
wrote:
>
> Am 26.06.20 um 06:43 schrieb Sumit Semwal:
> > On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote:
> >> Ignoring everything else ...
> >>
> >> On Thu, Jun 25, 2020 at 9:28 PM Jani Nikula
> >> wrote:
> >>> As a side note, there seem to be
== Series Details ==
Series: mm: Skip opportunistic reclaim for dma pinned pages
URL : https://patchwork.freedesktop.org/series/78795/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8665_full -> Patchwork_18019_full
Summary
== Series Details ==
Series: Send a hotplug when edid changes (rev8)
URL : https://patchwork.freedesktop.org/series/62816/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8661_full -> Patchwork_18016_full
Summary
---
*
Quoting Christian König (2020-06-26 12:35:30)
> Am 26.06.20 um 13:10 schrieb Chris Wilson:
> > Quoting Christian König (2020-06-26 09:54:19)
> > [SNIP]
> >> In other words "fence -> userspace -> page fault -> fence" or "fence ->
> >> userspace -> system call -> fence" can easily cause the same prob
On 6/23/20 4:28 PM, Maarten Lankhorst wrote:
Execbuffer submission will perform its own WW locking, and we
cannot rely on the implicit lock there.
This also makes it clear that the GVT code will get a lockdep splat when
multiple batchbuffer shadows need to be performed in the same instance,
fix
On Fri, Jun 26, 2020 at 12:16:06PM +0300, Lisovskiy, Stanislav wrote:
> On Thu, Jun 25, 2020 at 11:00:03PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > The linetime watermark is a 9 bit value, which gives us
> > a maximum linetime of just below 64 usec. If the linetime
> > exceeds
On 6/23/20 4:28 PM, Maarten Lankhorst wrote:
The lock here should be interruptible, so we can backoff if needed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i91
Hi,
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjälä
> Sent: perjantai 26. kesäkuuta 2020 16.47
> To: Lisovskiy, Stanislav
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
>
> On Fri, Jun 26, 2020 at 12:
On Fri, Jun 26, 2020 at 02:03:23PM +, Saarinen, Jani wrote:
> Hi,
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > Ville Syrjälä
> > Sent: perjantai 26. kesäkuuta 2020 16.47
> > To: Lisovskiy, Stanislav
> > Cc: intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gf
On Thu, 2020-06-25 at 18:01 -0700, José Roberto de Souza wrote:
> This registers will be used to implement PSR2 manual
> tracking/selective
> fetch.
>
> v2:
> - Fixed typo in _PLANE_SEL_FETCH_BASE
> - Renamed PSR2_MAN_TRK_CTL bits to better match spec names
> - Renamed _PLANE_SEL_FETCH_* to better
== Series Details ==
Series: series starting with [1/2] Revert "dma-buf: Report signaled links
inside dma-fence-chain"
URL : https://patchwork.freedesktop.org/series/78819/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8667 -> Patchwork_18025
=
Hi,
> -Original Message-
> From: Ville Syrjälä
> Sent: perjantai 26. kesäkuuta 2020 17.09
> To: Saarinen, Jani
> Cc: Lisovskiy, Stanislav ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915: Clamp linetime wm to <64usec
>
> On Fri, Jun 26, 2020 at 02:03:23
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
Use intel__read instead of I915_READ to read the
informational registers.
Extended from an original sseu-only patch by Sandeep.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata Sandeep Dhanalakota
---
== Series Details ==
Series: iommu: Remove usage of dev->archdata.iommu
URL : https://patchwork.freedesktop.org/series/78822/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ea59789bb2c8 iommu/exynos: Use dev_iommu_priv_get/set()
-:20: CHECK:COMPARISON_TO_NULL: Comparison to NULL
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
A follow up patch will move the engine mask under the gt structure,
so get ready for that.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i9
== Series Details ==
Series: iommu: Remove usage of dev->archdata.iommu
URL : https://patchwork.freedesktop.org/series/78822/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.0
Fast mode used, each commit won't be checked separately.
-
+drivers/gpu/drm/amd/
Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:07)
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index 26cae4846c82..ddefc52f6e09 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -1867,7 +1867,7 @@
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
All the info we read in intel_device_info_init_mmio are engine-related
and since we already have an engine_init_mmio function we can just
perform the operations from there.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Sh
Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:08)
> All the info we read in intel_device_info_init_mmio are engine-related
> and since we already have an engine_init_mmio function we can just
> perform the operations from there.
>
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Tvrtko Ursulin
>
== Series Details ==
Series: iommu: Remove usage of dev->archdata.iommu
URL : https://patchwork.freedesktop.org/series/78822/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8667 -> Patchwork_18026
Summary
---
**SUCCES
On 6/23/20 4:28 PM, Maarten Lankhorst wrote:
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 command
== Series Details ==
Series: drm/i915/display: Implement new combo phy initialization step (rev2)
URL : https://patchwork.freedesktop.org/series/78796/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
faec0ee3d268 drm/i915/display: Implement new combo phy initialization step
-:89:
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
Since the engines belong to the GT, move the runtime-updated list of
available engines to the intel_gt struct. The original mask has been
renamed to indicate it contains the maximum engine list that can be
found on a matching device.
In prepar
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
We already call 2 gt-related init_mmio functions in driver_mmio_probe
and a 3rd one will be added by a follow-up patch, so pre-emptively
introduce a gt_init_mmio function to group them.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
On 6/26/20 7:38 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:08)
All the info we read in intel_device_info_init_mmio are engine-related
and since we already have an engine_init_mmio function we can just
perform the operations from there.
Signed-off-by: Daniele Cer
Quoting Daniele Ceraolo Spurio (2020-06-26 15:46:53)
>
>
> On 6/26/20 7:38 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:08)
> >> All the info we read in intel_device_info_init_mmio are engine-related
> >> and since we already have an engine_init_mmio function we ca
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
Keep all the SSEU code in the relevant file. The code has also been
updated to use intel_gt instead of dev_priv.
Based on an original patch by Sandeep.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
Cc: Venkata San
== Series Details ==
Series: drm/i915/display: Implement new combo phy initialization step (rev2)
URL : https://patchwork.freedesktop.org/series/78796/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8667 -> Patchwork_18027
S
== Series Details ==
Series: drm/i915: implement Wa_14011508470;gen12
URL : https://patchwork.freedesktop.org/series/78799/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8665_full -> Patchwork_18020_full
Summary
---
On Fri, Jun 26, 2020 at 04:46:41PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 26, 2020 at 12:16:06PM +0300, Lisovskiy, Stanislav wrote:
> > On Thu, Jun 25, 2020 at 11:00:03PM +0300, Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > The linetime watermark is a 9 bit value, which gives us
>
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
From: Venkata Sandeep Dhanalakota
SSEUs are a GT capability, so track them under gt_info.
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gem/i
On Wed, 24 Jun 2020, Patchwork wrote:
> == Series Details ==
>
> Series: Send a hotplug when edid changes (rev8)
> URL : https://patchwork.freedesktop.org/series/62816/
> State : warning
>
> == Summary ==
Please at least fix the spacing issues. Please don't use spaces for
indentation.
BR,
Jani
Omg, where did those come from?..
Joshi Kunal: will you fix or should I do that?
Best Regards,
Lisovskiy Stanislav
Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
From: Jani Nikula
Sent: Friday, June 26, 2020 6:22:31 PM
T
Hi Christian,
On Fri, 26 Jun 2020, 18:10 Daniel Vetter, wrote:
> On Fri, Jun 26, 2020 at 9:03 AM Christian König
> wrote:
> >
> > Am 26.06.20 um 06:43 schrieb Sumit Semwal:
> > > On Fri, 26 Jun 2020 at 01:24, Daniel Vetter wrote:
> > >> Ignoring everything else ...
> > >>
> > >> On Thu, Jun 25
From: Stanislav Lisovskiy
From: Stanislav Lisovskiy
This series introduce to drm a way to determine if something else
except connection_status had changed during probing, which
can be used by other drivers as well. Another i915 specific part
uses this approach to determine if edid had changed w
From: Stanislav Lisovskiy
From: Stanislav Lisovskiy
Many drivers would benefit from using
drm helper to compare edid, rather
than bothering with own implementation.
v2: Added documentation for this function.
Signed-off-by: Stanislav Lisovskiy
---
drivers/gpu/drm/drm_edid.c | 33
From: Stanislav Lisovskiy
From: Stanislav Lisovskiy
This counter will be used by drm_helper_probe_detect caller to determine
if anything had changed(including edid, connection status and etc).
Hardware specific driver detect hooks are responsible for updating this
counter when some change is de
From: Stanislav Lisovskiy
Added epoch counter checking to intel_encoder_hotplug
in order to be able process all the connector changes,
besides connection status. Also now any change in connector
would result in epoch counter change, so no multiple checks
are needed.
v2: Renamed change counter to
On 2020-06-26 at 08:25:24 -0700, Lisovskiy, Stanislav wrote:
> Omg, where did those come from?..
>
> Joshi Kunal: will you fix or should I do that?
>
>
> Best Regards,
>
> Lisovskiy Stanislav
>
> Organization: Intel Finland Oy - BIC 0357606-4 - Westendinkatu 7, 02160 Espoo
>
yes stan floated
On 6/26/20 7:45 AM, Tvrtko Ursulin wrote:
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
Since the engines belong to the GT, move the runtime-updated list of
available engines to the intel_gt struct. The original mask has been
renamed to indicate it contains the maximum engine list that c
On 6/26/20 8:22 AM, Tvrtko Ursulin wrote:
On 26/06/2020 00:42, Daniele Ceraolo Spurio wrote:
From: Venkata Sandeep Dhanalakota
SSEUs are a GT capability, so track them under gt_info.
Signed-off-by: Venkata Sandeep Dhanalakota
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc
Quoting Daniele Ceraolo Spurio (2020-06-26 17:44:20)
>
>
> On 6/26/20 7:45 AM, Tvrtko Ursulin wrote:
> >
> > Only thing which looks a bit sub-optimalis the name "max_engine_mask",
> > but maybe it is just me, that max and masks do not go well together.
> > Only alternative I have for the momen
On 6/26/20 12:14 AM, Lucas De Marchi wrote:
Cc Matt and Daniele
On Thu, Jun 25, 2020 at 9:38 PM Dave Airlie wrote:
I can't figure this out easily so I'd thought I'd just ask, but does
DG1 have VRAM > PCIE aperture, I'm not sure I've see any mention of
We'd need to go via lmem since there
On 6/26/20 7:35 AM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:07)
diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
b/drivers/gpu/drm/i915/gvt/handlers.c
index 26cae4846c82..ddefc52f6e09 100644
--- a/drivers/gpu/drm/i915/gvt/handlers.c
+++ b/drivers/gpu/drm/i915/gvt
Quoting Daniele Ceraolo Spurio (2020-06-26 18:45:56)
>
>
> On 6/26/20 7:35 AM, Chris Wilson wrote:
> > Quoting Daniele Ceraolo Spurio (2020-06-26 00:42:07)
> >> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> >> b/drivers/gpu/drm/i915/gvt/handlers.c
> >> index 26cae4846c82..ddefc52f6e09 10064
Modify the helper to add a fixed delay or poll with timeout
based on platform specification to check for either Idle bit
set (DDI_BUF_CTL is idle for disable case)
v3:
* Change the timeout to 16usecs (Ville)
v2:
* Use 2 separate functions or idle and active (Ville)
Cc: Ville Syrjälä
Cc: Imre Dea
Based on the platform, Bspec expects us to wait or poll with
timeout for DDI BUF IDLE bit to be set to 0 (non idle) or get active
after enabling DDI_BUF_CTL.
v4:
* Use the timeout for GLK (Ville)
v3:
* Add a new function _active for DDI BUF CTL to be non idle (Ville)
v2:
* Based on platform, fixed
We don't need intel_dig_port and dig_port to refer to the same thing.
Prefer the latter.
v2: fix coding style
Signed-off-by: Lucas De Marchi
Reviewed-by: Matt Roper
---
drivers/gpu/drm/i915/display/intel_ddi.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/driv
We have a mix of dport, intel_dport, intel_dig_port and dig_port to
reference a intel_digital_port struct. Numbers are around
5 intel_dport
36 dport
479 intel_dig_port
352 dig_port
Since we already removed the intel_ prefix from most of our other
structs, do the same here and p
Sadly checkpatch is not working in this series and it passed even if
there was a clear alignment violation. I fixed the one reported by Ville
and reviewed the rest to check if there was others.
Lucas De Marchi (2):
drm/i915/display: remove alias to dig_port
drm/i915/display: prefer dig_port to
78 matches
Mail list logo
