Re: [Intel-gfx] [RFC PATCH 2/5] media: cec-notifier: Get notifier by device and connector name

Hi Neil, Thanks for this patch series! Some comments below: On 05/15/2018 12:40 AM, Neil Armstrong wrote: > In non device-tree world, we can need to get the notifier by the driver > name directly and eventually defer probe if not yet created. > > This patch adds a variant of the get function

[Intel-gfx] ✗ Fi.CI.IGT: failure for DRM helpers for Display Stream Compression PPS infoframes (rev3)

== Series Details == Series: DRM helpers for Display Stream Compression PPS infoframes (rev3) URL : https://patchwork.freedesktop.org/series/42968/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4179_full -> Patchwork_9003_full = == Summary - FAILURE == Serious unknown

Re: [Intel-gfx] [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

On 05/15/2018 12:40 AM, Neil Armstrong wrote: > This patchs adds the cec_notifier feature to the intel_hdmi part > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate > between each HDMI ports. > The changes will allow the i915 HDMI code to notify EDID and HPD changes > to

[Intel-gfx] ✗ Fi.CI.IGT: failure for Add ChromeOS EC CEC Support

== Series Details == Series: Add ChromeOS EC CEC Support URL : https://patchwork.freedesktop.org/series/43162/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4179_full -> Patchwork_9002_full = == Summary - FAILURE == Serious unknown changes coming with

Re: [Intel-gfx] [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

On 05/15/2018 12:40 AM, Neil Armstrong wrote: > This patchs adds the cec_notifier feature to the intel_hdmi part > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate > between each HDMI ports. > The changes will allow the i915 HDMI code to notify EDID and HPD changes > to

Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

On 05/15/2018 12:40 AM, Neil Armstrong wrote: > The Chrome OS Embedded Controller can expose a CEC bus, this patch add the > driver for such feature of the Embedded Controller. > > This driver is part of the cros-ec MFD and will be add as a sub-device when > the feature bit is exposed by the EC.

Re: [Intel-gfx] [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

On 15/05/2018 08:29, Hans Verkuil wrote: > On 05/15/2018 12:40 AM, Neil Armstrong wrote: >> This patchs adds the cec_notifier feature to the intel_hdmi part >> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate >> between each HDMI ports. >> The changes will allow the

Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

On 05/15/18 09:25, Neil Armstrong wrote: > Hi Hans, > > Thanks for the extensive review. > > On 15/05/2018 08:58, Hans Verkuil wrote: >> On 05/15/2018 12:40 AM, Neil Armstrong wrote: >>> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the >>> driver for such feature of the

Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

Hi Hans, Thanks for the extensive review. On 15/05/2018 08:58, Hans Verkuil wrote: > On 05/15/2018 12:40 AM, Neil Armstrong wrote: >> The Chrome OS Embedded Controller can expose a CEC bus, this patch add the >> driver for such feature of the Embedded Controller. >> >> This driver is part of the

Re: [Intel-gfx] [RFC PATCH 2/5] media: cec-notifier: Get notifier by device and connector name

On 15/05/2018 08:27, Hans Verkuil wrote: > Hi Neil, > > Thanks for this patch series! > > Some comments below: > > On 05/15/2018 12:40 AM, Neil Armstrong wrote: >> In non device-tree world, we can need to get the notifier by the driver >> name directly and eventually defer probe if not yet

Re: [Intel-gfx] [RFC PATCH 3/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

On 15/05/2018 08:34, Hans Verkuil wrote: > On 05/15/2018 12:40 AM, Neil Armstrong wrote: >> This patchs adds the cec_notifier feature to the intel_hdmi part >> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate >> between each HDMI ports. >> The changes will allow the

Re: [Intel-gfx] [PATCH] drm/i915: Allow i915_gem_reset_prepare_engine to recurse

Chris Wilson writes: > We call i915_gem_reset_prepare_engine() during reset and then upon > wedging if the reset fails. Unfortunately, kthread_park and similar do > not support being called recursively and so we must count the number of > times we prepare for reset and

Re: [Intel-gfx] [PATCH] drm/i915: Allow i915_gem_reset_prepare_engine to recurse

Quoting Mika Kuoppala (2018-05-15 09:08:45) > Chris Wilson writes: > > > We call i915_gem_reset_prepare_engine() during reset and then upon > > wedging if the reset fails. Unfortunately, kthread_park and similar do > > not support being called recursively and so we must

Re: [Intel-gfx] [PATCH v2] gpu: drm: i915: Change return type to vm_fault_t

Quoting Joonas Lahtinen (2018-05-15 14:49:17) > Quoting Souptick Joarder (2018-04-17 22:02:02) > > default: > > - WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n", > > ret); > > + WARN_ONCE(ret, "unhandled error in %s: %x\n", __func__, > > ret); > > I

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Enabling content-type setting for HDMI displays. (rev10)

== Series Details == Series: Enabling content-type setting for HDMI displays. (rev10) URL : https://patchwork.freedesktop.org/series/41876/ State : warning == Summary == $ dim checkpatch origin/drm-tip 78e458dc1b4a drm: content-type property for HDMI connector -:138: CHECK:LINE_SPACING:

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Clean up ADPA pipe select bits (rev2)

== Series Details == Series: series starting with [1/5] drm/i915: Clean up ADPA pipe select bits (rev2) URL : https://patchwork.freedesktop.org/series/43151/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4179 -> Patchwork_8997 = == Summary - SUCCESS == No regressions

[Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

The Chrome OS Embedded Controller can expose a CEC bus, this patch add the driver for such feature of the Embedded Controller. This driver is part of the cros-ec MFD and will be add as a sub-device when the feature bit is exposed by the EC. The controller will only handle a single logical

[Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device when the CEC feature bit is present. Signed-off-by: Neil Armstrong --- drivers/mfd/cros_ec_dev.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/mfd/cros_ec_dev.c

[Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

The EC can expose a CEC bus, this patch adds the CEC related definitions needed by the cros-ec-cec driver. Having a 16 byte mkbp event size makes it possible to send CEC messages from the EC to the AP directly inside the mkbp event instead of first doing a notification and then a read.

Re: [Intel-gfx] [PULL] drm-intel-next

Hi: I am truly sorry for the mess. It's actual my fault of solving a patch dependency by rebasing. Jani was trying to help me to catch the deadline, I am very appreciated for Jani's help and I am quite sorry for letting Jani experience this failure. He tried to help but I fail him. As a new

[Intel-gfx] [PATCH v11 2/2] i915: content-type property for HDMI connector

From: Stanislav Lisovskiy Added encoding of drm content_type property from drm_connector_state within AVI infoframe in order to properly handle external HDMI TV content-type setting. This requires also manipulationg ITC bit, as stated in HDMI spec. v2: * Moved

[Intel-gfx] [PATCH v11 1/2] drm: content-type property for HDMI connector

From: Stanislav Lisovskiy Added content_type property to drm_connector_state in order to properly handle external HDMI TV content-type setting. v2: * Moved helper function which attaches content type property to the drm core, as was suggested. Removed

[Intel-gfx] [PATCH v11 0/2] Enabling content-type setting for HDMI displays.

From: Stanislav Lisovskiy Added content type setting property to drm_connector(part 1) and enabled transmitting it with HDMI AVI infoframes for i915(part 2). Stanislav Lisovskiy (2): drm: content-type property for HDMI connector i915: content-type property for

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: split CNL platforms in GT1/2

== Series Details == Series: series starting with [1/2] drm/i915: split CNL platforms in GT1/2 URL : https://patchwork.freedesktop.org/series/43196/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK

Re: [Intel-gfx] [PATCH 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

Hi, On 15/05/2018 14:56, Hans Verkuil wrote: > On 05/15/18 14:46, Neil Armstrong wrote: >> This patchs adds the cec_notifier feature to the intel_hdmi part >> of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate >> between each HDMI ports. >> The changes will allow the

Re: [Intel-gfx] [PATCH rdma-next 01/21] drm/i915: Move u64-to-ptr helpers to general header

On Thu, May 03, 2018 at 04:36:55PM +0300, Leon Romanovsky wrote: > From: Leon Romanovsky > > The macro u64_to_ptr() and function ptr_to_u64() are useful enough > to be part of general header, so move them there and allow RDMA > subsystem reuse them. > > Signed-off-by: Leon

Re: [Intel-gfx] [PATCH 1/2] drm/i915: split CNL platforms in GT1/2

Quoting Lionel Landwerlin (2018-05-15 14:57:44) > We don't actually need this information in i915 but we would like to > get it in IGT and since the pciid headers are in sync.. Hmm, I don't see that we display the GT anywhere. I was thinking an immediate use-case for this information would be the

Re: [Intel-gfx] [PULL] drm-intel-next

Imo we should take this as a personal failure of anyone, things happen. Instead this is a good opportunity to improve our scripts, to make sure we catch this in the future. Cheers, Daniel On Tue, May 15, 2018 at 3:16 PM, Wang, Zhi A wrote: > Hi: > > I am truly sorry for

[Intel-gfx] [drm-tip:drm-tip 711/734] drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct rcar_du_vsp_plane_state' has no member named 'alpha'

tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip head: c03987223c762e4a61142f0a9be6027bb181cdfa commit: 9037d4b98b255979c6636045794775f5a89cc623 [711/734] Merge branch 'drm/du/next' of git://linuxtv.org/pinchartl/media into drm-next config: arm64-defconfig (attached as .config)

[Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

This patchs adds the cec_notifier feature to the intel_hdmi part of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate between each HDMI ports. The changes will allow the i915 HDMI code to notify EDID and HPD changes to an eventual CEC adapter. Signed-off-by: Neil Armstrong

[Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

In non device-tree world, we can need to get the notifier by the driver name directly and eventually defer probe if not yet created. This patch adds a variant of the get function by using the device name instead and will not create a notifier if not yet created. But the i915 driver exposes at

[Intel-gfx] [PATCH v2 0/5] Add ChromeOS EC CEC Support

Hi All, The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support through it's Embedded Controller, to enable the Linux CEC Core to communicate with it and get the CEC Physical Address from the correct HDMI Connector, the following must be added/changed: - Add the CEC sub-device

Re: [Intel-gfx] [PATCH 1/2] drm/i915: split CNL platforms in GT1/2

On 15/05/18 15:10, Chris Wilson wrote: Quoting Lionel Landwerlin (2018-05-15 14:57:44) We don't actually need this information in i915 but we would like to get it in IGT and since the pciid headers are in sync.. Hmm, I don't see that we display the GT anywhere. I was thinking an immediate

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add ChromeOS EC CEC Support (rev3)

== Series Details == Series: Add ChromeOS EC CEC Support (rev3) URL : https://patchwork.freedesktop.org/series/43162/ State : warning == Summary == $ dim checkpatch origin/drm-tip 942485c481d1 media: cec-notifier: Get notifier by device and connector name 9a7496b1dc2b drm/i915: hdmi: add CEC

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

On 05/15/2018 04:42 PM, Neil Armstrong wrote: > This patchs adds the cec_notifier feature to the intel_hdmi part > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate > between each HDMI ports. > The changes will allow the i915 HDMI code to notify EDID and HPD changes > to

[Intel-gfx] ✓ Fi.CI.BAT: success for Add ChromeOS EC CEC Support (rev2)

== Series Details == Series: Add ChromeOS EC CEC Support (rev2) URL : https://patchwork.freedesktop.org/series/43162/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4186 -> Patchwork_9004 = == Summary - SUCCESS == No regressions found. External URL:

Re: [Intel-gfx] [PATCH] drm/i915: Shrink search list for active timelines

On 13/05/2018 14:46, Chris Wilson wrote: When switching to the kernel context, we force the switch to occur after all currently active requests (so that we know the GPU won't switch immediately away and the kernel context remains current as we work). To do so we have to inspect all the

Re: [Intel-gfx] [ANNOUNCE] xorg-server 1.20.0

On Tue, 2018-05-15 at 12:51 +0200, Thomas Klausner wrote: > > Those specific fixes could probably be cherry-picked to the version > > you're trying to build, but it may be worthwhile to update to git > > master anyway. > > I'm packaging for NetBSD, and we prefer to package tarballs, not git >

[Intel-gfx] [PATCH v2] drm/i915: Shrink search list for active timelines

When switching to the kernel context, we force the switch to occur after all currently active requests (so that we know the GPU won't switch immediately away and the kernel context remains current as we work). To do so we have to inspect all the timelines and add a fence from the active work to

[Intel-gfx] ✓ Fi.CI.BAT: success for Enabling content-type setting for HDMI displays. (rev10)

== Series Details == Series: Enabling content-type setting for HDMI displays. (rev10) URL : https://patchwork.freedesktop.org/series/41876/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4186 -> Patchwork_9006 = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH v2] gpu: drm: i915: Change return type to vm_fault_t

Quoting Souptick Joarder (2018-04-17 22:02:02) > Use new return type vm_fault_t for fault handler. For > now, this is just documenting that the function returns > a VM_FAULT value rather than an errno. Once all instances > are converted, vm_fault_t will become a distinct type. > > Reference id ->

Re: [Intel-gfx] [PATCH] drm/i915: Shrink search list for active timelines

Quoting Tvrtko Ursulin (2018-05-15 14:42:02) > > On 13/05/2018 14:46, Chris Wilson wrote: > > When switching to the kernel context, we force the switch to occur after > > all currently active requests (so that we know the GPU won't switch > > immediately away and the kernel context remains

[Intel-gfx] [PATCH 2/2] drm/i915: classify all ICL as GT1

Icelake has less of an emphasis on the GT number and is more classified as trio of slices-subslices-EUs numbers. Since all the current skus have only one slice, let's classify them as GT1 for now. Signed-off-by: Lionel Landwerlin ---

[Intel-gfx] [PATCH 1/2] drm/i915: split CNL platforms in GT1/2

We don't actually need this information in i915 but we would like to get it in IGT and since the pciid headers are in sync.. Here we're splitting the CNL platforms into 2 groups : - GT1: including GT0.5/GT1 platforms (1 slice) - GT2: including GT1.5/GT2 platforms (2 slices) Signed-off-by:

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] drm/i915: Clean up ADPA pipe select bits (rev2)

On Tue, May 15, 2018 at 02:47:48AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/5] drm/i915: Clean up ADPA pipe select bits > (rev2) > URL : https://patchwork.freedesktop.org/series/43151/ > State : failure > > == Summary == > > = CI Bug Log - changes

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Shrink search list for active timelines (rev2)

== Series Details == Series: drm/i915: Shrink search list for active timelines (rev2) URL : https://patchwork.freedesktop.org/series/43102/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4186 -> Patchwork_9007 = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

On 05/15/2018 04:42 PM, Neil Armstrong wrote: > In non device-tree world, we can need to get the notifier by the driver > name directly and eventually defer probe if not yet created. > > This patch adds a variant of the get function by using the device name > instead and will not create a

[Intel-gfx] [PULL] drm-intel-next

Hi Dave - So this one contains the problematic pull from gvt. It's got both a backmerge and a rebase. I spotted the rebase, but intentionally let it slide due to the deadline closing, and then completely missed the backmerge. I don't know what I was thinking. My bad, sorry. We'll need to

Re: [Intel-gfx] linux-next: Signed-off-by missing for commits in the drm-intel tree

On Tue, 15 May 2018, Stephen Rothwell wrote: > Hi all, > > Commits > > cb8ba171ae6c ("drm/i915/gvt: let force_to_nonpriv cmd handler only valid > for LRI cmd") > 0438a1059877 ("drm/i915/gvt: do not return error on handling > force_to_nonpriv registers") >

Re: [Intel-gfx] [PATCH rdma-next 01/21] drm/i915: Move u64-to-ptr helpers to general header

On Mon, May 14, 2018 at 02:10:54PM -0600, Jason Gunthorpe wrote: > On Thu, May 03, 2018 at 04:36:55PM +0300, Leon Romanovsky wrote: > > From: Leon Romanovsky > > > > The macro u64_to_ptr() and function ptr_to_u64() are useful enough > > to be part of general header, so move

Re: [Intel-gfx] [PATCH v5 7/7] drm/i915: Expose RPCS (SSEU) configuration to userspace

On 14/05/2018 16:56, Lionel Landwerlin wrote: From: Chris Wilson We want to allow userspace to reconfigure the subslice configuration for its own use case. To do so, we expose a context parameter to allow adjustment of the RPCS register stored within the context

[Intel-gfx] [PATCH 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device when the CEC feature bit is present. Signed-off-by: Neil Armstrong --- drivers/mfd/cros_ec_dev.c | 16 1 file changed, 16 insertions(+) diff --git a/drivers/mfd/cros_ec_dev.c

[Intel-gfx] [PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

The Chrome OS Embedded Controller can expose a CEC bus, this patch add the driver for such feature of the Embedded Controller. This driver is part of the cros-ec MFD and will be add as a sub-device when the feature bit is exposed by the EC. The controller will only handle a single logical

[Intel-gfx] [PATCH 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

This patchs adds the cec_notifier feature to the intel_hdmi part of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate between each HDMI ports. The changes will allow the i915 HDMI code to notify EDID and HPD changes to an eventual CEC adapter. Signed-off-by: Neil Armstrong

[Intel-gfx] [PATCH 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

The EC can expose a CEC bus, this patch adds the CEC related definitions needed by the cros-ec-cec driver. Having a 16 byte mkbp event size makes it possible to send CEC messages from the EC to the AP directly inside the mkbp event instead of first doing a notification and then a read.

[Intel-gfx] [PATCH 1/5] media: cec-notifier: Get notifier by device and connector name

In non device-tree world, we can need to get the notifier by the driver name directly and eventually defer probe if not yet created. This patch adds a variant of the get function by using the device name instead and will not create a notifier if not yet created. But the i915 driver exposes at

[Intel-gfx] [PATCH 0/5] Add ChromeOS EC CEC Support

Hi All, The new Google "Fizz" Intel-based ChromeOS device is gaining CEC support throught it's Embedded Controller, to enable the Linux CEC Core to communicate with it and get the CEC Physical Address from the correct HDMI Connector, the following must be added/changed: - Add the CEC sub-device

Re: [Intel-gfx] [PULL] drm-intel-next

> -Original Message- > From: Nikula, Jani > Sent: Tuesday, May 15, 2018 3:26 PM > To: Dave Airlie > Cc: Daniel Vetter ; Jani Nikula > ; Joonas Lahtinen > ; Vivi, Rodrigo

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Add ChromeOS EC CEC Support (rev2)

== Series Details == Series: Add ChromeOS EC CEC Support (rev2) URL : https://patchwork.freedesktop.org/series/43162/ State : warning == Summary == $ dim checkpatch origin/drm-tip e778f6269fef media: cec-notifier: Get notifier by device and connector name -:72: WARNING:NEEDLESS_IF:

Re: [Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

On 05/15/2018 04:42 PM, Neil Armstrong wrote: > The Chrome OS Embedded Controller can expose a CEC bus, this patch add the > driver for such feature of the Embedded Controller. > > This driver is part of the cros-ec MFD and will be add as a sub-device when > the feature bit is exposed by the EC.

[Intel-gfx] ✓ Fi.CI.BAT: success for Add ChromeOS EC CEC Support (rev3)

== Series Details == Series: Add ChromeOS EC CEC Support (rev3) URL : https://patchwork.freedesktop.org/series/43162/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4186 -> Patchwork_9008 = == Summary - WARNING == Minor unknown changes coming with Patchwork_9008 need to

Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: hdmi: add CEC notifier to intel_hdmi

On Tue, May 15, 2018 at 04:42:19PM +0200, Neil Armstrong wrote: > This patchs adds the cec_notifier feature to the intel_hdmi part > of the i915 DRM driver. It uses the HDMI DRM connector name to differentiate > between each HDMI ports. > The changes will allow the i915 HDMI code to notify EDID

Re: [Intel-gfx] [PATCH v2 1/5] media: cec-notifier: Get notifier by device and connector name

On 15/05/2018 17:22, Hans Verkuil wrote: > On 05/15/2018 04:42 PM, Neil Armstrong wrote: >> In non device-tree world, we can need to get the notifier by the driver >> name directly and eventually defer probe if not yet created. >> >> This patch adds a variant of the get function by using the

Re: [Intel-gfx] [PATCH v2 3/5] mfd: cros-ec: Introduce CEC commands and events definitions.

On 05/15/2018 04:42 PM, Neil Armstrong wrote: > The EC can expose a CEC bus, this patch adds the CEC related definitions > needed by the cros-ec-cec driver. > Having a 16 byte mkbp event size makes it possible to send CEC > messages from the EC to the AP directly inside the mkbp event > instead of

Re: [Intel-gfx] [PATCH v2] gpu: drm: i915: Change return type to vm_fault_t

On Tue, May 15, 2018 at 7:19 PM, Joonas Lahtinen wrote: > Quoting Souptick Joarder (2018-04-17 22:02:02) >> Use new return type vm_fault_t for fault handler. For >> now, this is just documenting that the function returns >> a VM_FAULT value rather than an errno.

Re: [Intel-gfx] [drm-tip:drm-tip 711/734] drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct rcar_du_vsp_plane_state' has no member named 'alpha'

Hello, On Tuesday, 15 May 2018 17:24:52 EEST kbuild test robot wrote: > tree: git://anongit.freedesktop.org/drm/drm-tip drm-tip > head: c03987223c762e4a61142f0a9be6027bb181cdfa > commit: 9037d4b98b255979c6636045794775f5a89cc623 [711/734] Merge branch > 'drm/du/next' of

Re: [Intel-gfx] [PULL] drm-intel-next

Agreed. Zhi, don't worry about it. I think the main takeaways here are: 1) We need to improve the dim checks on git pulls. This is both for us pulling gvt, and now that Dave's experimenting with dim, for him pulling all the trees. 2) The GVT maintainers should consider using dim too. It would

Re: [Intel-gfx] [PATCH v2] gpu: drm: i915: Change return type to vm_fault_t

Quoting Souptick Joarder (2018-05-15 16:29:25) > On Tue, May 15, 2018 at 7:19 PM, Joonas Lahtinen > wrote: > > Quoting Souptick Joarder (2018-04-17 22:02:02) > >> Use new return type vm_fault_t for fault handler. For > >> now, this is just documenting that the

Re: [Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

Hi Neil, I suspect that this patch will conflict with some patches that will be queued for 4.18 that also introduces new devices, well, for now I don't see these merged in the Lee's tree. Based on some reviews I got when I send a patch to this file ... 2018-05-15 17:29 GMT+02:00 Hans Verkuil

Re: [Intel-gfx] [BACKPORT v4.17-rc5] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

On Mon, 14 May 2018, Michel Thierry wrote: > Factor in clear values wherever required while updating destination > min/max. Hi Michel, please elaborate what the intention here is. BR, Jani. > > References: HSDES#160184 > Signed-off-by: Michel Thierry

Re: [Intel-gfx] [BACKPORT v4.17-rc5] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

On Tue, 15 May 2018, Michel Thierry wrote: > On 5/15/2018 10:13 AM, Jani Nikula wrote: >> On Mon, 14 May 2018, Michel Thierry wrote: >>> Factor in clear values wherever required while updating destination >>> min/max. >> >> Hi Michel, please

Re: [Intel-gfx] [PULL] drm-intel-next

"... should _not_ take this as a personal failure ..." is what I meant of course. Worst possible oversight :-/ -Daniel On Tue, May 15, 2018 at 4:58 PM, Daniel Vetter wrote: > Imo we should take this as a personal failure of anyone, things > happen. Instead this is a good

Re: [Intel-gfx] [BACKPORT v4.17-rc5] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

On 5/15/2018 11:17 AM, Jani Nikula wrote: On Tue, 15 May 2018, Michel Thierry wrote: On 5/15/2018 10:13 AM, Jani Nikula wrote: On Mon, 14 May 2018, Michel Thierry wrote: Factor in clear values wherever required while updating destination

Re: [Intel-gfx] [PATCH v2] drm/i915: Wait for PSR exit before checking for vblank evasion

On Mon, May 14, 2018 at 10:16:38PM +0100, Chris Wilson wrote: > Quoting Tarun Vyas (2018-05-14 21:49:22) > > The PIPEDSL freezes on PSR entry and if PSR hasn't fully exited, then > > the pipe_update_start call schedules itself out to check back later. > > > > On ChromeOS-4.4 kernel, which is

Re: [Intel-gfx] [PATCH v2] gpu: drm: i915: Change return type to vm_fault_t

>> >> default: >> >> - WARN_ONCE(ret, "unhandled error in i915_gem_fault: %i\n", >> >> ret); >> >> + WARN_ONCE(ret, "unhandled error in %s: %x\n", __func__, >> >> ret); >> > >> > I don't see point in %x (which should be 0x%x, really), why change it? >> >> ret

Re: [Intel-gfx] [PATCH v2 4/5] mfd: cros_ec_dev: Add CEC sub-device registration

On 05/15/2018 04:42 PM, Neil Armstrong wrote: > The EC can expose a CEC bus, thus add the cros-ec-cec MFD sub-device > when the CEC feature bit is present. > > Signed-off-by: Neil Armstrong For what it is worth (not an MFD expert): Acked-by: Hans Verkuil

Re: [Intel-gfx] [BACKPORT v4.17-rc5] drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

On 5/15/2018 10:13 AM, Jani Nikula wrote: On Mon, 14 May 2018, Michel Thierry wrote: Factor in clear values wherever required while updating destination min/max. Hi Michel, please elaborate what the intention here is. Hi Jani, isn't the intention of all the

[Intel-gfx] ✓ Fi.CI.IGT: success for Enabling content-type setting for HDMI displays. (rev10)

== Series Details == Series: Enabling content-type setting for HDMI displays. (rev10) URL : https://patchwork.freedesktop.org/series/41876/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4186_full -> Patchwork_9006_full = == Summary - SUCCESS == No regressions found.

Re: [Intel-gfx] [PATCH v2 6/9] drm/i915/psr/bdw+: Enable CRC check in the static frame on the sink side

On Wed, 2018-04-18 at 15:43 -0700, José Roberto de Souza wrote: > Sink can be configured to calculate the CRC over the static frame and > compare with the CRC calculated and transmited in the VSC SDP by > source, if there is a mismatch sink will do a short pulse in HPD > and set

Re: [Intel-gfx] [PATCH v2 2/9] drm/i915/psr: Move PSR exit specific code to hardware specific function

On Wed, 2018-04-18 at 15:43 -0700, José Roberto de Souza wrote: > To proper execute PSR exit it was using 'if (HAS_DDI(dev_priv))' to > differentiate between VLV/CHV and HSW+ hardware, so here moving each > hardware handling to his own function. When 

Re: [Intel-gfx] [PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

Hi Neil, I love your patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [also build test ERROR on v4.17-rc5 next-20180515] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

[Intel-gfx] [PULL] drm-misc-next

Hi, Small fix for render nodes, changelog is slightly clobbered by moving drm-misc-next forward to drm/drm-next. :) drm-misc-next-2018-05-15: drm-misc-next for v4.18: UAPI Changes: - Fix render node number regression from control node removal. Driver Changes: - Small header fix for virgl, used

Re: [Intel-gfx] [PATCH i-g-t 3/6] igt/gem_ctx_thrash: Order writes between contexts

On 14/05/2018 16:10, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-14 11:59:09) On 14/05/2018 09:02, Chris Wilson wrote: The test wrote to the same dwords from multiple contexts, assuming that the writes would be ordered by its submission. However, as it was using multiple contexts

Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

On 15/05/2018 10:10, Hans Verkuil wrote: > On 05/15/18 09:25, Neil Armstrong wrote: >> Hi Hans, >> >> Thanks for the extensive review. >> >> On 15/05/2018 08:58, Hans Verkuil wrote: >>> On 05/15/2018 12:40 AM, Neil Armstrong wrote: The Chrome OS Embedded Controller can expose a CEC bus, this

Re: [Intel-gfx] [PATCH i-g-t 3/6] igt/gem_ctx_thrash: Order writes between contexts

Quoting Tvrtko Ursulin (2018-05-15 09:20:13) > > On 14/05/2018 16:10, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-05-14 11:59:09) > >> > >> On 14/05/2018 09:02, Chris Wilson wrote: > >>> The test wrote to the same dwords from multiple contexts, assuming that > >>> the writes would be

Re: [Intel-gfx] [RFC PATCH 5/5] media: platform: Add Chrome OS EC CEC driver

On 05/15/18 10:28, Neil Armstrong wrote: > + int ret; > + > + cros_ec_cec = devm_kzalloc(>dev, sizeof(*cros_ec_cec), > +GFP_KERNEL); > + if (!cros_ec_cec) > + return -ENOMEM; > + > + platform_set_drvdata(pdev, cros_ec_cec); >

[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/8] drm/i915: Remove tasklet flush before disable

== Series Details == Series: series starting with [1/8] drm/i915: Remove tasklet flush before disable URL : https://patchwork.freedesktop.org/series/43157/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4179_full -> Patchwork_9000_full = == Summary - FAILURE == Serious

Re: [Intel-gfx] [PATCH i-g-t 3/6] igt/gem_ctx_thrash: Order writes between contexts

On 15/05/2018 09:29, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-15 09:20:13) On 14/05/2018 16:10, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-05-14 11:59:09) On 14/05/2018 09:02, Chris Wilson wrote: The test wrote to the same dwords from multiple contexts, assuming that the

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

On Wednesday 16 May 2018 04:33 AM, Dhinakaran Pandiyan wrote: On Mon, 2018-05-14 at 09:02 +0530, vathsala nagaraju wrote: From: Vathsala Nagaraju For psr block #9, the vbt description has moved to options [0-3] for TP1,TP2,TP3 Wakeup time from decimal value

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

On Wednesday 16 May 2018 04:25 AM, Puthikorn Voravootivat wrote: On Sun, May 13, 2018 at 8:32 PM vathsala nagaraju < vathsala.nagar...@intel.com> wrote: From: Vathsala Nagaraju For psr block #9, the vbt description has moved to options [0-3] for TP1,TP2,TP3 Wakeup

[Intel-gfx] [PATCH] drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI

This patch adds the remaining register definitions and bit fields required for MG PHy DDI buffer initializations and voltage swing programming for MG PHy DDI ports. While at it this patch also fixes the naming for previously defined MG PHY registers in original commit id (c92f47b5ec977a

[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI

== Series Details == Series: drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI URL : https://patchwork.freedesktop.org/series/43227/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1c8c24d3b7fd drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI

== Series Details == Series: drm/i915/icl: Add remaining registers and bitfields for MG PHY DDI URL : https://patchwork.freedesktop.org/series/43227/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4189 -> Patchwork_9009 = == Summary - SUCCESS == No regressions found.

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Shrink search list for active timelines (rev2)

== Series Details == Series: drm/i915: Shrink search list for active timelines (rev2) URL : https://patchwork.freedesktop.org/series/43102/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4186_full -> Patchwork_9007_full = == Summary - WARNING == Minor unknown changes

[Intel-gfx] ✓ Fi.CI.IGT: success for Add ChromeOS EC CEC Support (rev3)

== Series Details == Series: Add ChromeOS EC CEC Support (rev3) URL : https://patchwork.freedesktop.org/series/43162/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4186_full -> Patchwork_9008_full = == Summary - WARNING == Minor unknown changes coming with

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

On Mon, 2018-05-14 at 09:02 +0530, vathsala nagaraju wrote: > From: Vathsala Nagaraju > > For psr block #9, the vbt description has moved to options [0-3] for > TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt > structure. Since spec does not  

Re: [Intel-gfx] [PATCH] drm/i915/psr: vbt change for psr

On Sun, May 13, 2018 at 8:32 PM vathsala nagaraju < vathsala.nagar...@intel.com> wrote: > From: Vathsala Nagaraju > For psr block #9, the vbt description has moved to options [0-3] for > TP1,TP2,TP3 Wakeup time from decimal value without any change to vbt >