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 km
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 e10624a..7f8fa99 100644
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.
___
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 th
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 b/drivers/md/dm-crypt.c
index 389a363
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
b/drivers/staging/unisys/visorhba/v
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 rat
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(-)
diff --git a/drivers/
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(-)
diff --git a/drivers/n
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 insertions(+), 10 deletions(-)
di
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
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 li
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 b/drivers/gpu/drm/i915/i915_gem.c
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 5ff26ab..7eeed23 10064
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 +
drivers/mmc/host/tmio_mmc_pio.c | 24 +
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, well
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 dec
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
---
drivers/scsi/csiostor/csio_scsi.c | 54 +++-
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 a/crypto/shash.c b/crypto/shash.c
in
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 +
drivers/scsi/mvsas/mv_sas.c
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 &udev->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
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 nvmet_copy_fro
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
---
drivers/scsi
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 a
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 ---
3 files chang
> -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 you add Acked-by for
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 +++---
1
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 put_page is
implemented the
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 insertions(+), 6 deletion
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 | 12 +++-
>> 1 fil
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 ISCSI_TCP_INTERNAL_ER
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 dm-crypt
> 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 kunmap_at
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 missi
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 i
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 changed, 35 insertions(+), 10
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 t
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 t->offs
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
>
> These patchwork emails
== 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 gem
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
> {
>
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)
> >> URL : https://patchwork.fre
Hi all,
First slice of 4.13 features:
new uabi:
- extend error state dumping to include non-batch buffers requested by
userspace (Chris), so that mesa gets more useful error state dumps
- reapply the link status patch, for handlig dp link failures
(Manasi). This needs updated -modesetting to
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 ==
>> >>
>> >> Series: drm/i915: uninitialized value on er
On Thu, Apr 13, 2017 at 12:54:22PM +0300, Jari Tahvanainen wrote:
> Daniel has posted empty feat_profile.json as template to be used.
> This is my understanding about the features and what tests are covering those.
>
> Usage: piglit summary feature json-filename output-directory results-directory
On Mon, Apr 17, 2017 at 11:39:45AM +0100, Daniel Stone wrote:
> Hi Sean,
>
> On 14 April 2017 at 16:47, Sean Paul wrote:
> > On Mon, Apr 10, 2017 at 12:05:43PM -0400, Sean Paul wrote:
> >> Add a bit more colour to the -misc branch explanations, and add a merge
> >> timeline
> >> similar to the c
From: Michel Dänzer
Signed-off-by: Michel Dänzer
---
Chris / Ilia / Ben, this should be manageable for the intel/nouveau
drivers, right?
src/amdgpu_drv.h | 26 ++
src/amdgpu_kms.c | 18 +-
src/drmmode_display.c | 8 ++--
3 files changed,
From: Michel Dänzer
This allows making the master screen's pixmap_dirty_list entries
explicitly reflect that we're now tracking the root window instead of
the screen pixmap, in order to allow Present page flipping on master
outputs while there are active slave outputs.
Define HAS_DIRTYTRACKING_D
From: Tvrtko Ursulin
Verify that we reject attempts to create object larger than
INT_MAX * PAGE_SIZE since i915 currently cannot support that.
Also removed the skip on simulation since I don't know why
would that be needed here.
v2: Removed basic tag and adjusted commit msg.
Signed-off-by: Tvr
On 18/04/17 12:14, 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 ==
Series: drm/i915: uninitialized value on error path (rev3)
URL : ht
On Tue, Apr 18, 2017 at 11:29:34AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Verify that we reject attempts to create object larger than
> INT_MAX * PAGE_SIZE since i915 currently cannot support that.
>
> Also removed the skip on simulation since I don't know why
> would that be ne
From: Tvrtko Ursulin
Move the BUILD_BUG_ONs for busy-wait duration outside the
_wait_for_atomic macro as discussed on the mailing list.
v2: Simplify the macro by omitting the ret__ local. (Chris Wilson)
Signed-off-by: Tvrtko Ursulin
Suggested-by: Michal Wajdeczko
Fixes: 1d1a9774e404 ("drm/i91
On Tue, Apr 18, 2017 at 11:52:11AM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin
>
> Move the BUILD_BUG_ONs for busy-wait duration outside the
> _wait_for_atomic macro as discussed on the mailing list.
>
> v2: Simplify the macro by omitting the ret__ local. (Chris Wilson)
>
> Signed-off-b
== Series Details ==
Series: drm/i915: Fix GCC 4.4 build issue with __intel_wait_for_register_fw
(rev2)
URL : https://patchwork.freedesktop.org/series/23020/
State : failure
== Summary ==
Series 23020v2 drm/i915: Fix GCC 4.4 build issue with
__intel_wait_for_register_fw
https://patchwork.fre
Hi,
> [Zhang, Xiong Y] Thanks for your teach and propose.
> For smbios, could you teach me which type and field could be used ?
qemu adds a specific subsystem id to all virtual devices, so you can use
that to figure you are running on qemu. One good candidate to check is
the host bridge (easy
From: Tvrtko Ursulin
Check that no-op execution speed is the same in headless mode
and with the display active.
v2:
* Set graphics mode for the test to disable blanking. (Imre)
* Use igt stats framework as suggested by Chris.
Signed-off-by: Tvrtko Ursulin
Bugzilla: https://bugs.freedesktop.o
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 (0x0F)
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 devic
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 patch-set
---
drivers/ac
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 masked on Haswell
> https://patchwork.f
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 P
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 unmasked for IVB and SNB in order
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 fa
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 = &intel_execution_engines[0];
> + unsigned int nr_connected = 0;
> + drmModeConnector *connector;
> + drmModeRes *res;
>
== 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"
https://patchwork.freedesktop.org/api/1.0/series/23172/revisio
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 p
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 [-Werror=frame-larger-than=]
== 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
https://patchwork.freedesktop.org/api/1.0/series/23183/revisio
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
> {
> If (OSID == One)
>
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: error: the frame size of 132
> -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
> Gleixner
> Subject: Re: freedesktop bug id: 100548, bisect
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: Chri
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 d
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 allo
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
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
>
> Probably makes sense to merge through some oth
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 patchs
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.
__
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 rig
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 happil
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 new DRM_IOCTL_I915_GEM_ENGINE
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) currently done via disjoint set
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 some opinions on whether this
== 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
https://patchwork.freedesktop.org/api/1.0/series
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,
> + DRM_I915_ENGINE_CLAS
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 where applicable (which fails at
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
index b5c81de102e8..e06af46f5a5
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 the same.
v2: Include reset engi
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 this information in debugfs.
v
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
Signed-off-by: Arun Siluvery
Signed-off-by: Michel Thierry
---
drivers/gpu/drm/i915/i915_pa
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 changed, 4 insertions(+), 4 deletions(-)
diff --git
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 reset request again which is unne
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.
Hangchecker determines which engines a
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
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,
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
suspend/resume
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,
provi
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 a/drivers/gpu/drm/i915/i915_drv.h
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 of
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 in case of engine reset as drive
1 - 100 of 131 matches
Mail list logo
