We cannot call kthread_park() from softirq context, so let's avoid it
entirely during the reset. We wanted to suspend the signaler so that it
would not mark a request as complete at the same time as we marked it as
being in error. Instead of parking the signaling, stop the engine from
advancing so
As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.
v2: And do the same for the guc.
Signed-off-by: Chris Wilson
Cc: Jeff McGee
Cc: Michał Winiarski
Revi
In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC:
Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.
v2: Restore checking of use_csb_mmio on every loop, don't forget old
vgpu.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
-
In preparation to more carefully handling incomplete preemption during
reset by execlists, we move the existing code wholesale to the backends
under a couple of new reset vfuncs.
Signed-off-by: Chris Wilson
Cc: Michał Winiarski
CC: Michel Thierry
Cc: Jeff McGee
Reviewed-by: Jeff McGee
---
dr
When setting up reset, we may need to recursively prepare an engine. In
which case we should only synchronously flush the tasklets on the outer
most call, the inner calls will then be inside an atomic section where
the tasklet will never be run (and so the sync will never complete).
Signed-off-by:
The idea was to try and let the existing tasklet run to completion
before we began the reset, but it involves a racy check against anything
else that tries to run the tasklet. Rather than acknowledge and ignore
the race, let it be and don't try and be too clever.
The tasklet will resume execution
Quoting Chris Wilson (2018-05-15 15:31:49)
> 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 ti
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 time from decimal value witho
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 without any change to vbt
structure.
== 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 Patchwork_9008
== 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 comi
== 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.
E
== 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 "drm/i915/
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 https://patchwork.freedesktop.org/patch/30/
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 DP_PSR_LINK_CRC_ERR
== 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.
E
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
> structure. Since spec does not mentio
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 mention from which VBT version th
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 fairl
>> >> 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 w
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
min/max.
Hi Michel, please elaborate what the intent
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 elaborate what the intention here is.
>>
>
> Hi Jani,
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 workarounds to prevent gpu hangs
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
> Cc: mesa-...@lists.freedesktop.org
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 device
"... 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 opportunity to improve ou
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 p
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 git://linuxtv.org/pincha
== 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 b
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 and
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 function returns
> >> a VM_FAULT valu
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. Once all instances
>> are converted
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
Thanks!
Hans
> ---
> driver
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 notifier
== 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 n
== 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 Pa
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 use-c
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 the mess. It's actual my
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 fro
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 address
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 b/drivers/mfd/cros_ec_dev.c
index
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.
Signed-off-
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 lea
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 reg
== 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 fo
== 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 Pa
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 que
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)
compiler
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
> mas
== 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: Please
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 i915
== 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 include/generated/
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 helper function which attaches co
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 redundant connector state initializat
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 HDMI connector
Documentation/
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
---
drivers/gpu/drm/i915/i915_pci.c | 1 +
1 file changed, 1 inser
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 current
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 timelines
== 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:
https://patchwork.
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 guy
== 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: kfree(NULL)
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 address
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 b/drivers/mfd/cros_ec_dev.c
index
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.
Signed-off-
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 lea
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
> -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 ;
> Sean Paul ; Gustavo Padovan
> ; Maarten Lankhorst
> ; dri-de...@lists.freedesktop.org;
> intel-gfx@lists.freedeskt
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 improve
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 Romanovsky
> ---
> d
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 image (and
currently not access
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")
> 3d8b9e258b9d ("drm/i915/gvt: let N
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 them there and allow RD
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 w
== 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 un
On 05/15/18 10:28, Neil Armstrong wrote:
> + int ret;
> +
> + cros_ec_cec = devm_kzalloc(&pdev->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 orde
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 p
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 with
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 count the number of
> > ti
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 only actually prepare on th
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 i915
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 i915
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 creat
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 ch
100 matches
Mail list logo
