Re: [Intel-gfx] [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote: > Interesting that you didn't CC any of the maintainers. Could you > do that in the future please? Please read the cover letter. The distribution list for the patchset would have been way too large to cc every maintainer (even as limited as it

Re: [Intel-gfx] [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On 18/04/17 09:50 AM, Konrad Rzeszutek Wilk wrote: > I am not sure if you know, but you can add on each patch the respective > maintainer via 'CC'. That way you can have certain maintainers CCed only > on the subsystems they cover. You put it after (or before) your SoB and > git send-email

Re: [Intel-gfx] [PATCH 05/22] drm/i915: Make use of the new sg_map helper function

On 18/04/17 12:44 AM, Daniel Vetter wrote: > On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote: >> This is a single straightforward conversion from kmap to sg_map. >> >> Signed-off-by: Logan Gunthorpe > > Acked-by: Daniel Vetter > >

Re: [Intel-gfx] [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On Tue, Apr 18, 2017 at 09:42:20AM -0600, Logan Gunthorpe wrote: > > > On 18/04/17 08:27 AM, Konrad Rzeszutek Wilk wrote: > > Interesting that you didn't CC any of the maintainers. Could you > > do that in the future please? > > Please read the cover letter. The distribution list for the

Re: [Intel-gfx] [PATCH] drm/cma-helper: Return ENOENT for "no such gem obj"

On Tue, Apr 18, 2017 at 10:40:21AM -0400, Sean Paul wrote: > On Tue, Apr 18, 2017 at 03:29:29PM +0300, Laurent Pinchart wrote: > > Hi Daniel, > > > > Thank you for the patch. > > > > On Tuesday 18 Apr 2017 14:11:20 Daniel Vetter wrote: > > > All the error codes we (ab)use are strictly not the

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

On Tue, Apr 18, 2017 at 02:10:07PM +, Lofstedt, Marta wrote: > Sorry Peter, I still see regression on the Core2 machine, with your patch. > Blergh, ok. I'll see if I can dig out an actual Core2 machine somewhere. I should have enough parts about.

Re: [Intel-gfx] [PATCH 05/22] drm/i915: Make use of the new sg_map helper function

On Thu, Apr 13, 2017 at 04:05:18PM -0600, Logan Gunthorpe wrote: > This is a single straightforward conversion from kmap to sg_map. > > Signed-off-by: Logan Gunthorpe Acked-by: Daniel Vetter Probably makes sense to merge through some other tree,

Re: [Intel-gfx] [PATCH 02/15] drm: Remove drm_modeset_(un)lock_crtc

On Fri, Apr 14, 2017 at 6:20 PM, Mike Lothian wrote: > Hi > > X no longer starts for me and I've bisected it back to this commit > > During bisect I ended up on commits where my laptop would lockup during boot The bugfix the hangs is in linux-next, but hasn't landed in

Re: [Intel-gfx] [PATCH 03/22] libiscsi: Make use of new the sg_map helper function

On 14/04/17 02:36 AM, Christoph Hellwig wrote: > On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote: >> Convert the kmap and kmap_atomic uses to the sg_map function. We now >> store the flags for the kmap instead of a boolean to indicate >> atomicitiy. We also propogate a possible

[Intel-gfx] [PATCH 11/22] RDS: Make use of the new sg_map helper function

Straightforward conversion except there's no error path, so we WARN if the sg_map fails. Signed-off-by: Logan Gunthorpe --- net/rds/ib_recv.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/net/rds/ib_recv.c b/net/rds/ib_recv.c index

Re: [Intel-gfx] [PATCH 02/22] nvmet: Make use of the new sg_map helper function

On Thu, Apr 13, 2017 at 11:06:16PM -0600, Logan Gunthorpe wrote: > Or maybe I'll just send a patch for that > separately seeing it doesn't depend on anything and is pretty simple. I > can do that next week. Yes, please just send that patch linux-nvme, we should be able to get it into 4.12.

Re: [Intel-gfx] freedesktop bug id: 100548, bisected to sched/clock commit

> -Original Message- > From: Peter Zijlstra [mailto:pet...@infradead.org] > Sent: Thursday, April 13, 2017 4:24 PM > To: Martin Peres > Cc: Lofstedt, Marta ; > pasha.tatas...@oracle.com; intel-gfx@lists.freedesktop.org; Thomas >

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915/scheduler: add gvt notification for guc

Hi Chris, Ping for your feedback on my comments. Please help to make it to move forward. :) Thanks Chuanxiao > -Original Message- > From: intel-gvt-dev [mailto:intel-gvt-dev-boun...@lists.freedesktop.org] On > Behalf Of Dong, Chuanxiao > Sent: Thursday, April 13, 2017 7:03 PM > To:

[Intel-gfx] [PATCH v6 1/3] ACPI / bus: Introduce a list of ids for "always present" devices

Several Cherry Trail devices (all of which ship with Windows 10) hide the LPSS PWM controller in ACPI, typically the _STA method looks like this: Method (_STA, 0, NotSerialized) // _STA: Status { If (OSID == One) { Return (Zero) } Return

[Intel-gfx] [RFC 1/2] drm/i915: Engine discovery uAPI

From: Tvrtko Ursulin Engine discovery uAPI allows userspace to probe for engine configuration and features without needing to maintain the internal PCI id based database. This enables removal of code duplications across userspace components. Probing is done via the

[Intel-gfx] [RFC 2/2] drm/i915: Select engines via class and instance in execbuffer2

From: Tvrtko Ursulin Building on top of the previous patch which exported the concept of engine classes and instances, we can also use this instead of the current awkward engine selection uAPI. This is primarily interesting for the VCS engine selection which is a)

[Intel-gfx] [RFC 0/2] New engine discovery and execbuffer2 engine selection uAPI

From: Tvrtko Ursulin Inspired by the recent introduction of the engine class and instance concept, and a chat with Chris Wilson about a potential unification of PCI id based device discovery across multiple userspace components, I have cooked up two patches to gather

[Intel-gfx] ✗ Fi.CI.BAT: failure for New engine discovery and execbuffer2 engine selection uAPI

== Series Details == Series: New engine discovery and execbuffer2 engine selection uAPI URL : https://patchwork.freedesktop.org/series/23189/ State : failure == Summary == Series 23189v1 New engine discovery and execbuffer2 engine selection uAPI

[Intel-gfx] [PATCH v6 2/3] ACPI / bus: Add INT0002 to list of always-present devices

The INT0002 device is necessary to clear wakeup interrupt sources on Cherry Trail devices, without it we get nobody cared IRQ msgs and some systems don't properly resume at all without it. Signed-off-by: Hans de Goede --- Changes in v6: -This is a new patch in v6 of this

[Intel-gfx] [PATCH v6 3/3] ACPI / bus: Add Bay Trail PWM controller to list of always-present devices

Just like on Cherry Trail, on some Bay Trail Windows 10 tablets we need to enable the PWM controller to get working backlight even though _STA returns 0. Add an entry for the the Bay Trail PWM controller to list of always-present devices to fix backlight control not working on some Bay Trail

Re: [Intel-gfx] [PATCH i-g-t v2] igt/gem_exec_nop/headless: Verify GT performance in headless mode

On Tue, Apr 18, 2017 at 12:41:14PM +0100, Tvrtko Ursulin wrote: > +static void headless(int fd, uint32_t handle) > +{ > + const struct intel_execution_engine *e = _execution_engines[0]; > + unsigned int nr_connected = 0; > + drmModeConnector *connector; > + drmModeRes *res; > +

[Intel-gfx] [PATCH] drm/i915/selftests: Allocate inode/file dynamically

Avoid having too large a stack by creating the fake struct inode/file on the heap instead. drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file': drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 bytes is larger than 1280 bytes

Re: [Intel-gfx] [PATCH v6 1/3] ACPI / bus: Introduce a list of ids for "always present" devices

On Tue, Apr 18, 2017 at 1:54 PM, Hans de Goede wrote: > Several Cherry Trail devices (all of which ship with Windows 10) hide the > LPSS PWM controller in ACPI, typically the _STA method looks like this: > > Method (_STA, 0, NotSerialized) // _STA: Status > { >

[Intel-gfx] [PATCH] drm/cma-helper: Return ENOENT for "no such gem obj"

All the error codes we (ab)use are strictly not the right ones (since they're all for the vfs, and the only thing we're allowed to do from an ioctl is EINVAL). But ENOENT is the common error code for failed to look up an object throughout drm, so let's use it in the cma helpers, too. Cc: Laurent

Re: [Intel-gfx] [PATCH] drm/cma-helper: Return ENOENT for "no such gem obj"

Hi Daniel, Thank you for the patch. On Tuesday 18 Apr 2017 14:11:20 Daniel Vetter wrote: > All the error codes we (ab)use are strictly not the right ones (since > they're all for the vfs, and the only thing we're allowed to do from > an ioctl is EINVAL). But ENOENT is the common error code for

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/cma-helper: Return ENOENT for "no such gem obj"

== Series Details == Series: drm/cma-helper: Return ENOENT for "no such gem obj" URL : https://patchwork.freedesktop.org/series/23172/ State : failure == Summary == Series 23172v1 drm/cma-helper: Return ENOENT for "no such gem obj"

[Intel-gfx] [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

Straightforward conversion to the new helper, except due to the lack of error path, we have to warn if unmapable memory is ever present in the sgl. Signed-off-by: Logan Gunthorpe --- drivers/block/xen-blkfront.c | 33 +++-- 1 file changed, 27

Re: [Intel-gfx] [PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function

Great, thanks! Logan On 14/04/17 10:07 AM, Kershner, David A wrote: > Can you add Acked-by for this patch? > > Acked-by: David Kershner > > Tested on s-Par and no problems. > > Thanks, > David Kershner > >> --- >> drivers/staging/unisys/visorhba/visorhba_main.c

Re: [Intel-gfx] [PATCH 03/22] libiscsi: Make use of new the sg_map helper function

On Thu, Apr 13, 2017 at 04:05:16PM -0600, Logan Gunthorpe wrote: > Convert the kmap and kmap_atomic uses to the sg_map function. We now > store the flags for the kmap instead of a boolean to indicate > atomicitiy. We also propogate a possible kmap error down and create > a new

Re: [Intel-gfx] [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

On 04/14/2017 06:03 PM, Logan Gunthorpe wrote: > > > On 14/04/17 02:39 AM, Christoph Hellwig wrote: >> On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote: >>> Very straightforward conversion to the new function in all four spots. >> >> I think the right fix here is to switch

Re: [Intel-gfx] [PATCH 01/22] scatterlist: Introduce sg_map helper functions

> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 0007b79..b95934b 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -37,6 +37,9 @@ > > #include > > +/* Prevent the highmem.h macro from aliasing ops->kunmap_atomic */ > +#undef

Re: [Intel-gfx] [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

Thanks for the information Milan. On 15/04/17 06:10 AM, Milan Broz wrote: > I think your patch is ok (if it is just plain conversion), if it is > really needed, we can switch to ahash later in follow-up patch. Sounds good to me. > p.s. > there is a lot of lists on cc, but for this patch is

[Intel-gfx] [PATCH 01/22] scatterlist: Introduce sg_map helper functions

This patch introduces functions which kmap the pages inside an sgl. Two variants are provided: one if an offset is required and one if the offset is zero. These functions replace a common pattern of kmap(sg_page(sg)) that is used in about 50 places within the kernel. The motivation for this work

[Intel-gfx] [PATCH 22/22] memstick: Make use of the new sg_map helper function

Straightforward conversion, but we have to WARN if unmappable memory finds its way into the sgl. Signed-off-by: Logan Gunthorpe --- drivers/memstick/host/jmb38x_ms.c | 23 ++- drivers/memstick/host/tifm_ms.c | 22 +- 2 files

[Intel-gfx] [PATCH 21/22] mmc: tifm_sd: Make use of the new sg_map helper function

This conversion is a bit complicated. We modiy the read_fifo, write_fifo and copy_page functions to take a scatterlist instead of a page. Thus we can use sg_map instead of kmap_atomic. There's a bit of accounting that needed to be done for the offset for this to work. (Seeing sg_map takes care of

Re: [Intel-gfx] [PATCH 04/22] target: Make use of the new sg_map function at 16 call sites (fwd)

Thanks Julia. I missed that and I'll fix it in my series. Logan On 14/04/17 09:19 AM, Julia Lawall wrote: > It looks like >cmdr_lock should be released at line 512 if it has > not been released otherwise. The lock was taken at line 438. > > julia > > -- Forwarded message -- >

Re: [Intel-gfx] [PATCH 02/22] nvmet: Make use of the new sg_map helper function

On 13/04/17 10:59 PM, Christoph Hellwig wrote: > On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote: >> This is a straight forward conversion in two places. Should kmap fail, >> the code will return an INVALD_DATA error in the completion. > > It really should be using

[Intel-gfx] [PATCH 03/22] libiscsi: Make use of new the sg_map helper function

Convert the kmap and kmap_atomic uses to the sg_map function. We now store the flags for the kmap instead of a boolean to indicate atomicitiy. We also propogate a possible kmap error down and create a new ISCSI_TCP_INTERNAL_ERR error type for this. Signed-off-by: Logan Gunthorpe

Re: [Intel-gfx] [PATCH 02/22] nvmet: Make use of the new sg_map helper function

On Thu, Apr 13, 2017 at 04:05:15PM -0600, Logan Gunthorpe wrote: > This is a straight forward conversion in two places. Should kmap fail, > the code will return an INVALD_DATA error in the completion. It really should be using nvmet_copy_from_sgl to make things safer, as we don't want to rely on

[Intel-gfx] [PATCH 12/22] scsi: ipr, pmcraid, isci: Make use of the new sg_map helper in 4 call sites

Very straightforward conversion of three scsi drivers. Signed-off-by: Logan Gunthorpe --- drivers/scsi/ipr.c | 27 ++- drivers/scsi/isci/request.c | 42 +- drivers/scsi/pmcraid.c | 19

[Intel-gfx] [PATCH 18/22] mmc: spi: Make use of the new sg_map helper function

We use the sg_map helper but it's slightly more complicated as we only check for the error when the mapping actually gets used. Such that if the mapping failed but wasn't needed then no error occurs. Signed-off-by: Logan Gunthorpe --- drivers/mmc/host/mmc_spi.c | 26

Re: [Intel-gfx] [PATCH 08/22] crypto: chcr: Make use of the new sg_map helper function

On Fri, Apr 14, 2017 at 3:35 AM, Logan Gunthorpe wrote: > The get_page in this area looks *highly* suspect due to there being no > corresponding put_page. However, I've left that as is to avoid breaking > things. chcr driver will post the request to LLD driver cxgb4 and

Re: [Intel-gfx] [PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function

> -Original Message- > From: Logan Gunthorpe [mailto:log...@deltatee.com] ... > Subject: [PATCH 10/22] staging: unisys: visorbus: Make use of the new > sg_map helper function > > Straightforward conversion to the new function. > > Signed-off-by: Logan Gunthorpe Can

[Intel-gfx] [PATCH 08/22] crypto: chcr: Make use of the new sg_map helper function

The get_page in this area looks *highly* suspect due to there being no corresponding put_page. However, I've left that as is to avoid breaking things. I've also removed the KMAP_ATOMIC_ARGS check as it appears to be dead code that dates back to when it was first committed... Signed-off-by: Logan

Re: [Intel-gfx] [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote: > Very straightforward conversion to the new function in all four spots. I think the right fix here is to switch dm-crypt to the ahash API that takes a scatterlist. ___ Intel-gfx mailing

[Intel-gfx] [PATCH 05/22] drm/i915: Make use of the new sg_map helper function

This is a single straightforward conversion from kmap to sg_map. Signed-off-by: Logan Gunthorpe --- drivers/gpu/drm/i915/i915_gem.c | 27 --- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c

[Intel-gfx] [PATCH 20/22] mmc: sdricoh_cs: Make use of the new sg_map helper function

This is a straightforward conversion to the new function. Signed-off-by: Logan Gunthorpe --- drivers/mmc/host/sdricoh_cs.c | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/drivers/mmc/host/sdricoh_cs.c b/drivers/mmc/host/sdricoh_cs.c index

[Intel-gfx] [PATCH 19/22] mmc: tmio: Make use of the new sg_map helper function

Straightforward conversion to sg_map helper. A couple paths will WARN if the memory does not end up being mappable. Signed-off-by: Logan Gunthorpe --- drivers/mmc/host/tmio_mmc.h | 12 ++-- drivers/mmc/host/tmio_mmc_dma.c | 5 +

Re: [Intel-gfx] [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

On 14/04/17 02:39 AM, Christoph Hellwig wrote: > On Thu, Apr 13, 2017 at 04:05:22PM -0600, Logan Gunthorpe wrote: >> Very straightforward conversion to the new function in all four spots. > > I think the right fix here is to switch dm-crypt to the ahash API > that takes a scatterlist. Hmm,

[Intel-gfx] [PATCH 00/22] Introduce common scatterlist map function

Hi Everyone, As part of my effort to enable P2P DMA transactions with PCI cards, we've identified the need to be able to safely put IO memory into scatterlists (and eventually other spots). This probably involves a conversion from struct page to pfn_t but that migration is a ways off and those

[Intel-gfx] [PATCH 15/22] scsi: libfc, csiostor: Change to sg_copy_buffer in two drivers

These two drivers appear to duplicate the functionality of sg_copy_buffer. So we clean them up to use the common code. This helps us remove a couple of instances that would otherwise be slightly tricky sg_map usages. Signed-off-by: Logan Gunthorpe ---

[Intel-gfx] [PATCH 07/22] crypto: shash, caam: Make use of the new sg_map helper function

Very straightforward conversion to the new function in two crypto drivers. Signed-off-by: Logan Gunthorpe --- crypto/shash.c| 9 ++--- drivers/crypto/caam/caamalg.c | 8 +++- 2 files changed, 9 insertions(+), 8 deletions(-) diff --git

[Intel-gfx] [PATCH 13/22] scsi: hisi_sas, mvsas, gdth: Make use of the new sg_map helper function

Very straightforward conversion of three scsi drivers. Signed-off-by: Logan Gunthorpe --- drivers/scsi/gdth.c| 9 +++-- drivers/scsi/hisi_sas/hisi_sas_v1_hw.c | 14 +- drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 13 +

[Intel-gfx] [PATCH 06/22] crypto: hifn_795x: Make use of the new sg_map helper function

Conversion of a couple kmap_atomic instances to the sg_map helper function. However, it looks like there was a bug in the original code: the source scatter lists offset (t->offset) was passed to ablkcipher_get which added it to the destination address. This doesn't make a lot of sense, but

[Intel-gfx] ✓ Fi.CI.BAT: success for Introduce common scatterlist map function

== Series Details == Series: Introduce common scatterlist map function URL : https://patchwork.freedesktop.org/series/23149/ State : success == Summary == Series 23149v1 Introduce common scatterlist map function https://patchwork.freedesktop.org/api/1.0/series/23149/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH] drm/doc: Interlink color manager docs better

On Thu, Apr 13, 2017 at 10:55:12AM -0700, Lionel Landwerlin wrote: > I have a tiny suggestion down there. Regardless this is : > > Reviewed-by: Lionel Landwerlin Thanks for the suggestions, polished while applying the patch. -Daniel > > On 12/04/17 08:20, Daniel

[Intel-gfx] [PATCH 04/22] target: Make use of the new sg_map function at 16 call sites

Fairly straightforward conversions in all spots. In a couple of cases any error gets propogated up should sg_map fail. In other cases a warning is issued if the kmap fails seeing there's no clear error path. This should not be an issue until someone tries to use unmappable memory in the sgl with

[Intel-gfx] [PATCH 09/22] dm-crypt: Make use of the new sg_map helper in 4 call sites

Very straightforward conversion to the new function in all four spots. Signed-off-by: Logan Gunthorpe --- drivers/md/dm-crypt.c | 38 +- 1 file changed, 25 insertions(+), 13 deletions(-) diff --git a/drivers/md/dm-crypt.c

[Intel-gfx] [PATCH 10/22] staging: unisys: visorbus: Make use of the new sg_map helper function

Straightforward conversion to the new function. Signed-off-by: Logan Gunthorpe --- drivers/staging/unisys/visorhba/visorhba_main.c | 12 +++- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/staging/unisys/visorhba/visorhba_main.c

Re: [Intel-gfx] [PATCH 01/22] scatterlist: Introduce sg_map helper functions

On 14/04/17 02:35 AM, Christoph Hellwig wrote: >> + >> static inline int is_dma_buf_file(struct file *); >> >> struct dma_buf_list { > > I think the right fix here is to rename the operation to unmap_atomic > and send out a little patch for that ASAP. Ok, I can do that next week. > I'd

[Intel-gfx] [PATCH 17/22] mmc: sdhci: Make use of the new sg_map helper function

Straightforward conversion, except due to the lack of error path we have to WARN if the memory in the SGL is not mappable. Signed-off-by: Logan Gunthorpe --- drivers/mmc/host/sdhci.c | 35 ++- 1 file changed, 30 insertions(+), 5 deletions(-)

[Intel-gfx] [PATCH 02/22] nvmet: Make use of the new sg_map helper function

This is a straight forward conversion in two places. Should kmap fail, the code will return an INVALD_DATA error in the completion. Signed-off-by: Logan Gunthorpe --- drivers/nvme/target/fabrics-cmd.c | 16 1 file changed, 12 insertions(+), 4 deletions(-)

[Intel-gfx] [PATCH 14/22] scsi: arcmsr, ips, megaraid: Make use of the new sg_map helper function

Very straightforward conversion of three scsi drivers Signed-off-by: Logan Gunthorpe --- drivers/scsi/arcmsr/arcmsr_hba.c | 16 drivers/scsi/ips.c | 8 drivers/scsi/megaraid.c | 9 +++-- 3 files changed, 23

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: uninitialized value on error path (rev3)

On Mon, 17 Apr 2017, Dan Carpenter wrote: > On Fri, Apr 14, 2017 at 08:13:43PM -, Patchwork wrote: >> == Series Details == >> >> Series: drm/i915: uninitialized value on error path (rev3) >> URL : https://patchwork.freedesktop.org/series/23038/ >> State : success

Re: [Intel-gfx] [PATCH v4] ACPI / bus: Introduce a list of ids for "always present" devices

On Mon, 2017-04-10 at 17:49 +0200, Hans de Goede wrote: > Several cherrytrail devices (all of which ship with windows 10) hide > the > lpss pwm controller in ACPI, typically the _STA method looks like > this: CherryTrail PWM LPSS > > Method (_STA, 0, NotSerialized)  // _STA: Status > {

Re: [Intel-gfx] [PATCH 16/22] xen-blkfront: Make use of the new sg_map helper function

On Tue, Apr 18, 2017 at 02:13:59PM +, David Laight wrote: > From: Logan Gunthorpe > > Sent: 13 April 2017 23:05 > > Straightforward conversion to the new helper, except due to > > the lack of error path, we have to warn if unmapable memory > > is ever present in the sgl. Interesting that you

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Fix system hang with EI UP masked on Haswell

Patchwork writes: > == Series Details == > > Series: drm/i915: Fix system hang with EI UP masked on Haswell > URL : https://patchwork.freedesktop.org/series/22991/ > State : failure > > == Summary == > > Series 22991v1 drm/i915: Fix system hang with EI UP

Re: [Intel-gfx] [PATCH] drm/i915: Fix system hang with EI UP masked on Haswell

Chris Wilson writes: > On Thu, Apr 13, 2017 at 02:15:27PM +0300, Mika Kuoppala wrote: >> Previously with commit a9c1f90c8e17 >> ("drm/i915: Don't mask EI UP interrupt on IVB|SNB") certain, >> seemingly unrelated bit (GEN6_PM_RP_UP_EI_EXPIRED) was needed >> to be

[Intel-gfx] [PATCH i-g-t v3] lib/igt_kms: Force outputs to use full range RGB

In at least SKL and GLK (possibly other devices too), using a cursor plane to scan out an fb might result in a different pipe crc than when using a regular plane at the same position with the same fb while using the CSC logic to limit the color range. The differences could be caused by the cursor

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Allocate inode/file dynamically

== Series Details == Series: drm/i915/selftests: Allocate inode/file dynamically URL : https://patchwork.freedesktop.org/series/23183/ State : success == Summary == Series 23183v1 drm/i915/selftests: Allocate inode/file dynamically

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Allocate inode/file dynamically

On Tue, Apr 18, 2017 at 3:12 PM, Chris Wilson wrote: > Avoid having too large a stack by creating the fake struct inode/file on > the heap instead. > > drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file': > drivers/gpu/drm/i915/selftests/mock_drm.c:46:1:

Re: [Intel-gfx] [PATCH] drm/cma-helper: Return ENOENT for "no such gem obj"

On Tue, Apr 18, 2017 at 03:29:29PM +0300, Laurent Pinchart wrote: > Hi Daniel, > > Thank you for the patch. > > On Tuesday 18 Apr 2017 14:11:20 Daniel Vetter wrote: > > All the error codes we (ab)use are strictly not the right ones (since > > they're all for the vfs, and the only thing we're

Re: [Intel-gfx] [RFC 1/2] drm/i915: Engine discovery uAPI

On Tue, Apr 18, 2017 at 05:56:14PM +0100, Tvrtko Ursulin wrote: > +enum drm_i915_gem_engine_class { > + DRM_I915_ENGINE_CLASS_OTHER = 0, > + DRM_I915_ENGINE_CLASS_RENDER = 1, > + DRM_I915_ENGINE_CLASS_COPY = 2, > + DRM_I915_ENGINE_CLASS_VIDEO_DECODE = 3, > +

Re: [Intel-gfx] [PATCH v6 04/20] drm/i915/tdr: Modify error handler for per engine hang recovery

On 18/04/17 14:40, Chris Wilson wrote: On Tue, Apr 18, 2017 at 01:23:19PM -0700, Michel Thierry wrote: From: Arun Siluvery This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence

[Intel-gfx] ✓ Fi.CI.BAT: success for Gen8+ engine-reset (rev2)

== Series Details == Series: Gen8+ engine-reset (rev2) URL : https://patchwork.freedesktop.org/series/21868/ State : success == Summary == Series 21868v2 Gen8+ engine-reset https://patchwork.freedesktop.org/api/1.0/series/21868/revisions/2/mbox/ Test gem_exec_suspend: Subgroup

[Intel-gfx] [PATCH v6 03/20] drm/i915: Update i915.reset to handle engine resets

From: Arun Siluvery In preparation for engine reset work update this parameter to handle more than one type of reset. Default at the moment is still full gpu reset. Cc: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH v6 02/20] drm/i915: Rename gen8_(un)request_engine_reset to gen8_reset_engine_start/cancel

As all other functions related to resetting engines are using reset_engine. v2: remove _request_ and use start/cancel instead (Chris) Cc: Chris Wilson Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/intel_uncore.c | 8 1 file

[Intel-gfx] [PATCH v6 06/20] drm/i915: Skip reset request if there is one already

From: Mika Kuoppala To perform engine reset we first disable engine to capture its state. This is done by issuing a reset request. Because we are reusing existing infrastructure, again when we actually reset an engine, reset function checks engine mask and issues

[Intel-gfx] [PATCH v6 05/20] drm/i915/tdr: Add support for per engine reset recovery

From: Arun Siluvery This change implements support for per-engine reset as an initial, less intrusive hang recovery option to be attempted before falling back to the legacy full GPU reset recovery mode if necessary. This is only supported from Gen8 onwards.

[Intel-gfx] [PATCH v6 00/20] Gen8+ engine-reset

These patches add the reset-engine feature from Gen8. This is also referred to as Timeout detection and recovery (TDR). This complements to the full gpu reset feature available in i915 but it only allows to reset a particular engine instead of all engines thus providing a light weight engine reset

[Intel-gfx] [PATCH v6 18/20] drm/i915: Watchdog timeout: DRM kernel interface to set the timeout

Final enablement patch for GPU hang detection using watchdog timeout. Using the gem_context_setparam ioctl, users can specify the desired timeout value in microseconds, and the driver will do the conversion to 'timestamps'. The recommended default watchdog threshold for video engines is 6 us,

[Intel-gfx] [PATCH v6 15/20] drm/i915: Watchdog timeout: Pass GuC shared data structure during param load

For watchdog / media reset, the firmware must know the address of the shared data page (the first page of the default context). This information should be in DWORD 9 of the GUC_CTL structure. v2: Use guc_ggtt_offset (Chris). Store the ggtt offset of the default ctx as we needed for

[Intel-gfx] [PATCH v6 16/20] drm/i915: Watchdog timeout: IRQ handler for gen8+

*** General *** Watchdog timeout (or "media engine reset") is a feature that allows userland applications to enable hang detection on individual batch buffers. The detection mechanism itself is mostly bound to the hardware and the only thing that the driver needs to do to support this form of

[Intel-gfx] [PATCH v6 09/20] drm/i915/tdr: Enable Engine reset and recovery support

From: Arun Siluvery This feature is made available only from Gen8, for previous gen devices driver uses legacy full gpu reset. Cc: Chris Wilson Cc: Mika Kuoppala Signed-off-by: Tomas Elf

[Intel-gfx] [PATCH v6 12/20] drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder

From: Daniele Ceraolo Spurio The mmio_start offset for the whitelist is the first FORCE_TO_NONPRIV register the GuC can use to restore the provided whitelist when an engine reset via GuC (which we still don't support) is triggered. We're currently adding the

[Intel-gfx] [PATCH v6 13/20] drm/i915/guc: Provide register list to be saved/restored during engine reset

From: Arun Siluvery GuC expects a list of registers from the driver which are saved/restored during engine reset. The type of value to be saved is controlled by flags. We provide a minimal set of registers that we want GuC to save and restore. This is not an issue

[Intel-gfx] [PATCH v6 11/20] drm/i915/selftests: reset engine self tests

Check that we can reset specific engines, also check the fallback to full reset if something didn't work. v2: rebase. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 147 +++ 1 file changed, 147 insertions(+)

[Intel-gfx] [PATCH v6 10/20] drm/i915: Add engine reset count in get-reset-stats ioctl

Users/tests relying on the total reset count will start seeing a smaller number since most of the hangs can be handled by engine reset. Note that if reset engine x, context a running on engine y will be unaware and unaffected. To start the discussion, include just a total engine reset count. If

[Intel-gfx] [PATCH v6 14/20] drm/i915/guc: Add support for reset engine using GuC commands

This patch adds per engine reset and recovery (TDR) support when GuC is used to submit workloads to GPU. In the case of i915 directly submission to ELSP, driver manages hang detection, recovery and resubmission. With GuC submission these tasks are shared between driver and GuC. i915 is still

[Intel-gfx] [PATCH v6 20/20] drm/i915: Watchdog timeout: Export media reset count from GuC to debugfs

From firmware v8.8, GuC provides the count of media engine resets (watchdog timeout). This information is available in the GuC shared context data struct, which resides in the first page of the default (kernel) lrc context. Since GuC handled engine resets are transparent for kernel and user,

[Intel-gfx] [PATCH v6 19/20] drm/i915: Watchdog timeout: Include threshold value in error state

Save the watchdog threshold (in us) as part of the engine state. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_gpu_error.c | 11 +++ 2 files changed, 8 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH v6 17/20] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+

Emit the required commands into the ring buffer for starting and stopping the watchdog timer before/after batch buffer start during batch buffer submission. v2: Support watchdog threshold per context engine, merge lri commands, and move watchdog commands emission to emit_bb_start. Request space

[Intel-gfx] [PATCH v6 07/20] drm/i915/tdr: Add engine reset count to error state

From: Arun Siluvery Driver maintains count of how many times a given engine is reset, useful to capture this in error state also. It gives an idea of how engine is coping up with the workloads it is executing before this error state. A follow-up patch will provide

Re: [Intel-gfx] [RFC 2/2] drm/i915: Select engines via class and instance in execbuffer2

On Tue, Apr 18, 2017 at 05:56:15PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Building on top of the previous patch which exported the concept > of engine classes and instances, we can also use this instead of > the current awkward engine selection uAPI. >

[Intel-gfx] [PATCH v6 04/20] drm/i915/tdr: Modify error handler for per engine hang recovery

From: Arun Siluvery This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function

[Intel-gfx] [PATCH v6 01/20] drm/i915: Fix stale comment about I915_RESET_IN_PROGRESS flag

It has been replaced by I915_RESET_BACKOFF / I915_RESET_HANDOFF. Signed-off-by: Michel Thierry --- drivers/gpu/drm/i915/i915_drv.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h

[Intel-gfx] [PATCH v6 08/20] drm/i915/tdr: Export per-engine reset count info to debugfs

From: Arun Siluvery A new variable is added to export the reset counts to debugfs, this includes full gpu reset and engine reset count. This is useful for tests where they are expected to trigger reset; these counts are checked before and after the test to ensure

Re: [Intel-gfx] [PATCH v6 17/20] drm/i915: Watchdog timeout: Ringbuffer command emission for gen8+

On 18/04/17 14:20, Chris Wilson wrote: On Tue, Apr 18, 2017 at 01:23:32PM -0700, Michel Thierry wrote: @@ -1329,10 +1331,29 @@ static int gen8_emit_bb_start(struct drm_i915_gem_request *req, req->ctx->ppgtt->pd_dirty_rings &= ~intel_engine_flag(req->engine); } -

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: uninitialized value on error path (rev3)

On Tue, Apr 18, 2017 at 10:58:44AM +0300, Jani Nikula wrote: > On Mon, 17 Apr 2017, Dan Carpenter wrote: > > On Fri, Apr 14, 2017 at 08:13:43PM -, Patchwork wrote: > >> == Series Details == > >> > >> Series: drm/i915: uninitialized value on error path (rev3) > >>

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: uninitialized value on error path (rev3)

On Tue, 18 Apr 2017, Dan Carpenter wrote: > On Tue, Apr 18, 2017 at 10:58:44AM +0300, Jani Nikula wrote: >> On Mon, 17 Apr 2017, Dan Carpenter wrote: >> > On Fri, Apr 14, 2017 at 08:13:43PM -, Patchwork wrote: >> >> == Series Details == >>

  1   2   >