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
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
== 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
== 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
== 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.
== 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
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
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
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
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
== 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.
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
>
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
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
>> >> 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
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
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
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
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
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
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
"... 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
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
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
== 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
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.
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
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
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.
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
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
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
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
== 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
== 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
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
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
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
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
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
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.
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
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
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
== 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
== 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
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
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)
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
>
== 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:
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
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
== 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
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
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
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
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
---
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:
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
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 ->
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
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
== 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:
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
== 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:
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
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
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.
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
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
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
> -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
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
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
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
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")
>
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
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
== 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
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);
>
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
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
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
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
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
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
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
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
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
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
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
== 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
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.
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
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
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
== 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
97 matches
Mail list logo