On Mon, 2021-05-10 at 12:26 +0200, Mauro Carvalho Chehab wrote:
> There are several UTF-8 characters at the Kernel's documentation.
>
> Several of them were due to the process of converting files from
> DocBook, LaTeX, HTML and Markdown. They were probably introduced
> by the conversion tools used
On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> This patch series is doing conversion only when using ASCII makes
> more sense than using UTF-8.
>
> See, a number of converted documents ended with weird characters
> like ZERO WIDTH NO-BREAK SPACE (U+FEFF) character. This specifi
On Tue, 2021-05-11 at 11:00 +0200, Mauro Carvalho Chehab wrote:
> Yet, this series has two positive side effects:
>
> - it helps people needing to touch the documents using non-utf8 locales[1];
> - it makes easier to grep for a text;
>
> [1] There are still some widely used distros nowadays (LT
Your title 'Use ASCII subset' is now at least a bit *closer* to
describing what the patches are actually doing, but it's still a bit
misleading because you're only doing it for *some* characters.
And the wording is still indicative of a fundamentally *misguided*
motivation for doing any of this. Y
On Wed, 2021-05-12 at 17:17 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 10:14:44 -0400
> "Theodore Ts'o" escreveu:
>
> > On Wed, May 12, 2021 at 02:50:04PM +0200, Mauro Carvalho Chehab wrote:
> > > v2:
> > > - removed EM/EN DASH conversion from this patchset;
> >
> > Are you stil
On Fri, 2021-05-14 at 10:21 +0200, Mauro Carvalho Chehab wrote:
> Em Wed, 12 May 2021 18:07:04 +0100
> David Woodhouse escreveu:
>
> > On Wed, 2021-05-12 at 14:50 +0200, Mauro Carvalho Chehab wrote:
> > > Such conversion tools - plus some text editor like LibreOffice o
On Sat, 2021-05-15 at 10:22 +0200, Mauro Carvalho Chehab wrote:
> > > Here, U is not working. No idea why. I haven't
> > > test it for *years*, as I din't see any reason why I would
> > > need to type UTF-8 characters by numbers until we started
> > > this thread.
> >
> > Pl
On Sat, 2021-05-15 at 13:23 +0200, Mauro Carvalho Chehab wrote:
> Em Sat, 15 May 2021 10:24:28 +0100
> David Woodhouse escreveu:
> > > Let's take one step back, in order to return to the intents of this
> > > UTF-8, as the discussions here are not centered into the p
On Mon, 2016-08-15 at 14:48 +0300, Mika Kuoppala wrote:
>
>
> +static void i915_svm_fault_cb(struct device *dev, int pasid, u64 addr,
> + u32 private, int rwxp, int response)
> +{
> +}
> +
> +static struct svm_dev_ops i915_svm_ops = {
> + .fault_cb = i915_svm_fa
On Mon, 2016-08-15 at 13:05 +0100, Chris Wilson wrote:
> On Mon, Aug 15, 2016 at 02:48:05PM +0300, Mika Kuoppala wrote:
> >
> > + struct task_struct *task;
>
> We don't need the task, we need the mm.
>
> Holding the task is not sufficient.
From the pure DMA point of view, you don't need the M
On Mon, 2016-08-15 at 13:23 +0100, Chris Wilson wrote:
> On Mon, Aug 15, 2016 at 01:13:25PM +0100, David Woodhouse wrote:
> > On Mon, 2016-08-15 at 13:05 +0100, Chris Wilson wrote:
> > > On Mon, Aug 15, 2016 at 02:48:05PM +0300, Mika Kuoppala wrote:
> > > >
>
On Mon, 2016-08-15 at 13:53 +0100, Chris Wilson wrote:
>
> So it is really just what happens to commands for this client when it
> dies/exits. The kneejerk reaction is to say the pages should be kept
> alive as they are now for !svm. We could be faced with a situation where
> the client copies on
On Mon, 2016-12-05 at 13:58 -0800, Kees Cook wrote:
> This blacklists the Q35 integrated graphics so IOMMU can be otherwise
> enabled. Without this, a Q35 system can only enable IOMMU when booting
> with "intel_iommu=on,igfx_off" but not "intel_iommu=on".
Hm, is this definitely the same bug? Or is
On Mon, 2016-12-05 at 14:18 -0800, Kees Cook wrote:
> Hm, I have no idea. :) What would I look for in the BIOS?
For a start, what is the actual failure mode?
> I figured since g4 was busted, surely q35 was too, since it's even
> older...
Oh no, they all have different failures. Intel never actua
i915 device side?
That way, you should hopefully get to gracefully cope with reporting
errors for a specific *context*, rather than killing the whole process.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com In
On Wed, 2015-10-07 at 09:28 -0700, Jesse Barnes wrote:
> On 10/07/2015 09:14 AM, Daniel Vetter wrote:
> > On Wed, Oct 07, 2015 at 08:16:42AM -0700, Jesse Barnes wrote:
> > > On 10/07/2015 06:00 AM, David Woodhouse wrote:
> > > > On Fri, 2015-09-04 at 0
On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
> We just need to pass in an address to execute and some flags, since we
> don't have to worry about buffer relocation or any of the other usual
> stuff. Returns a fence to be used for synchronization.
> ---
> drivers/gpu/drm/i915/i915_dma.c
On Thu, 2015-10-08 at 12:29 +0100, Tomas Elf wrote:
>
> Could someone clarify what this means from the TDR point of view,
> please? When you say "context blew up" I'm guessing that you mean that
> come context caused the fault handler to get involved somehow?
>
> Does this imply that the offend
ng intel_svm_bind_mm() will be *given* the PASID that they are to
use. In general we seem to be converging on using a single PASID space
across *all* IOMMUs in the system, and this will support that mode of
operation.
--
David WoodhouseOpen Source Technology Centre
david
with 'intel_iommu=pasid28' on the command line.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 20 ++--
include/linux/intel-iommu.h | 2 +-
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/int
Add CONFIG_INTEL_IOMMU_SVM, and allocate PASID tables on supported hardware.
Signed-off-by: David Woodhouse
---
drivers/iommu/Kconfig | 8 ++
drivers/iommu/Makefile | 1 +
drivers/iommu/intel-iommu.c | 14 ++
drivers/iommu/intel-svm.c | 65
Signed-off-by: David Woodhouse
---
drivers/iommu/dmar.c| 42 +++---
include/linux/intel-iommu.h | 10 +-
2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 8757f8d..80e3c17 100644
If the device itself reports ATS in its PCIe capabilities, but the BIOS
neglects to provide an ATSR structure to indicate that the root port can
also cope, then assume the latter is lying.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 11 ---
1 file changed, 8
is stable.
Eventually we'll also want the PASID space to be system-wide, not just
per-IOMMU. But when we have that requirement we'll also have a way to
achieve it.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 100 ++
drivers/iommu/i
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 22 +-
drivers/iommu/intel-svm.c | 71 +
include/linux/intel-iommu.h | 5
3 files changed, 97 insertions(+), 1 deletion(-)
diff --git a/drivers/iommu/intel-iommu.c b
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-svm.c | 115 +++-
include/linux/intel-iommu.h | 21
2 files changed, 134 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 1260e87
st checks
if there is *already* a mmu_notifier registered with the same
mmu_notifier_ops structure, and returns it if so.
Because of the hairy locking rules around the mmu_notifier, I've done
this differently in my own code — using idr_for_each_entry() on the IDR
I use to allocate PASIDs. That's fine while the
the page request that we know
identifies the context. So perhaps we *could* contrive to give you
precise exceptions when the hardware doesn't really do that sanely.
But I was really trying hard to avoid the necessity for that kind of
hack to work around stupid hardware :)
--
D
On Fri, 2015-10-09 at 10:47 +0200, Daniel Vetter wrote:
> On Fri, Oct 09, 2015 at 08:56:24AM +0100, David Woodhouse wrote:
> > On Fri, 2015-10-09 at 09:28 +0200, Daniel Vetter wrote:
> > >
> > > Hm if this still works the same way as on older platforms then pagefault
On Fri, 2015-09-04 at 09:59 -0700, Jesse Barnes wrote:
>
> @@ -2286,6 +2287,10 @@ struct drm_i915_gem_request {
> /** Execlists no. of times this request has been sent to the ELSP */
> int elsp_submitted;
>
> + /* core fence obj for this request, may be exported */
> +
On Fri, 2015-10-09 at 00:50 +0100, David Woodhouse wrote:
> This patch set enables PASID support for the Intel IOMMU, along with
> page request support.
>
> Like its AMD counterpart, it exposes an IOMMU-specific API. I believe
> we'll have a session at the Kernel Summit later
to device driver on fault
Fix fault response codes (swap INVALID vs. FAILURE)
Fix PASID/PRI capability handling
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIM
Signed-off-by: David Woodhouse
---
include/linux/intel-iommu.h | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 6240063..08802b9 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel
with 'intel_iommu=pasid28' on the command line.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 20 ++--
include/linux/intel-iommu.h | 2 +-
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/int
If the device itself reports ATS in its PCIe capabilities, but the BIOS
neglects to provide an ATSR structure to indicate that the root port can
also cope, then assume the latter is lying.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 11 ---
1 file changed, 8
Add CONFIG_INTEL_IOMMU_SVM, and allocate PASID tables on supported hardware.
Signed-off-by: David Woodhouse
---
drivers/iommu/Kconfig | 8 ++
drivers/iommu/Makefile | 1 +
drivers/iommu/intel-iommu.c | 14 ++
drivers/iommu/intel-svm.c | 65
The behaviour if you enable PASID support after ATS is undefined. So we
have to enable it first, even if we don't know whether we'll need it.
This is safe enough; unless we set up a context that permits it, the device
can't actually *do* anything with it.
Signed-off-by:
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 2 ++
drivers/iommu/intel-svm.c | 9 +
include/linux/dma_remapping.h | 1 +
3 files changed, 12 insertions(+)
diff --git a/drivers/iommu/intel-iommu.c b/drivers/iommu/intel-iommu.c
index 4c462ab..787cd6e 100644
--- a
This provides basic PASID support for endpoint devices, tested with a
version of the i915 driver.
Signed-off-by: David Woodhouse
---
drivers/iommu/Kconfig | 1 +
drivers/iommu/intel-iommu.c | 111
drivers/iommu/intel-svm.c | 291
Signed-off-by: David Woodhouse
---
drivers/iommu/dmar.c| 42 +++---
include/linux/intel-iommu.h | 10 +-
2 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/drivers/iommu/dmar.c b/drivers/iommu/dmar.c
index 8757f8d..80e3c17 100644
Largely based on the driver-mode implementation by Jesse Barnes.
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 22 +-
drivers/iommu/intel-svm.c | 173
include/linux/intel-iommu.h | 26 +++
3 files changed, 220
Signed-off-by: David Woodhouse
---
drivers/iommu/intel-iommu.c | 3 ++-
drivers/iommu/intel-svm.c | 26 +-
include/linux/intel-iommu.h | 3 +++
include/linux/intel-svm.h | 21 ++---
4 files changed, 48 insertions(+), 5 deletions(-)
diff --git a
On Tue, 2015-10-13 at 22:34 +0100, David Woodhouse wrote:
> If the device itself reports ATS in its PCIe capabilities, but the BIOS
> neglects to provide an ATSR structure to indicate that the root port can
> also cope, then assume the latter is lying.
Except, of course, that integrate
On Mon, 2014-03-17 at 12:21 +, Chris Wilson wrote:
> +EXPORT_SYMBOL(interval_tree_insert);
> +EXPORT_SYMBOL(interval_tree_remove);
> +EXPORT_SYMBOL(interval_tree_iter_first);
> +EXPORT_SYMBOL(interval_tree_iter_next);
I'd prefer to see EXPORT_SYMBOL_GPL for this.
--
dwmw2
smime.p7s
Descr
On Mon, 2014-03-17 at 16:17 +, David Woodhouse wrote:
>
> Can't tell though, because my machine is still dying in an endless
> stream of
> [ 199.647850] [drm:intel_set_cpu_fifo_underrun_reporting] *ERROR*
> Interrupt arrived before CRTCs were setup up
Except when
On Tue, 2014-03-18 at 14:59 +0200, Jani Nikula wrote:
> From: Chris Wilson
>
> We have reports of heavy screen corruption if we try to use the stolen
> memory reserved by the BIOS whilst the DMA-Remapper is active. This
> quirk may be only specific to a few machines or BIOSes, but first lets
> ap
On Thu, 2014-03-20 at 09:36 +0200, Jani Nikula wrote:
>
> Or an additional knob, in case it's really not working and people want
> to get other things depending on prelim hw support done.
Yeah. Perhaps the best answer is a 'disable_silicon_workarounds' option,
to disable *all* workarounds for sil
On Thu, 2014-03-20 at 10:45 +0100, Daniel Vetter wrote:
> I'd agree that this would be nice, but my maintainer time is not
> endless and when I have users screaming "regression" I do have to do
> something. And yeah with the track record set of some of the earliest
> vtd+gfx chips I'm fairly aggres
On Sun, 2013-01-20 at 23:50 +0100, Daniel Vetter wrote:
> DMAR support on g4x/gm45 integrated gpus seems to be totally busted.
> So don't bother, but instead disable it by default to allow distros to
> unconditionally enable DMAR support.
Acked-By: David Woodhouse
It *really* wi
msg33138.html
> Cc: sta...@vger.kernel.org
> Cc: David Woodhouse
> Reported-and-tested-by: Mihai Moldovan
> Signed-off-by: Daniel Vetter
> ---
> drivers/iommu/intel-iommu.c |8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/iomm
On Fri, 2011-11-11 at 14:48 +0100, Joerg Roedel wrote:
> +#define intel_iommu_gfx_mapped 1
That ought to be zero; if the IOMMU code isn't present, it's
*definitely* not mapped through the IOMMU :)
But I'm fairly sure this was already noticed and a patch is on its way
upstream already.
It's my f
On Wed, 2011-11-23 at 11:26 +0100, Daniel Vetter wrote:
> On Tue, Nov 22, 2011 at 07:31:34PM -0800, Keith Packard wrote:
> > On Tue, 22 Nov 2011 20:15:31 +, Matthew Garrett wrote:
> >
> > > So the user has to choose between 5W of power saving or having dmar? And
> > > we default to giving th
On Wed, 2011-11-23 at 15:39 +0100, Daniel Vetter wrote:
> At least for the dmar+gfx+semaphores hang I can reproduce, just disabling
> dmar with intel_iommu=igfx_off is not good enough and iirc the same holds
> for the dmar+rc6 hangs reported.
Um... let me restate that for clarity (and partly for
On Wed, 2011-11-23 at 16:31 +0100, Daniel Vetter wrote:
>
> Things I've tried that don't work around the issue:
> - Disable dmar for the igfx with intel_iommu=igfx_off
> - Apply the ilk workaround (i.e. synchronous dmar tlb flushes + gpu
> idling while flushing).
Well, the ILK workaround was only
On Wed, 2011-11-23 at 16:41 +0100, Daniel Vetter wrote:
> Hm, that comment confuses me a bit. I've always thought that igfx_off only
> instantiates a identity mapping and leaves the dmar unit on. Is that
> wrong?
It's completely off. If a DMAR unit has *only* graphics devices behind
it (as the on
On Wed, 2011-11-23 at 16:42 -0200, Eugeni Dodonov wrote:
> Those are needed by the rc6 and semaphores support in i915 driver.
>
> In i915 driver, we do not enable either rc6 or semaphores on SNB when dmar
> is enabled. So we use those variables to check the io remapping and iommu
> status.
This i
On Tue, 2011-12-20 at 08:54 -0800, Eric Anholt wrote:
> - seq_printf(m, "%p: %s%s %8zd %04x %04x %d %d%s%s%s",
> + seq_printf(m, "%p: %s%s %8zdKB %04x %04x %d %d%s%s%s",
>&obj->base,
>get_pin_flag(obj),
>get_tiling_flag(obj),
>
instead allow a device driver to call a
'iommu_release_rmrrs()' function once it's reset the hardware to *stop*
doing whatever DMA the BIOS set it up with.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
On Tue, 2014-06-17 at 09:15 +0200, Daniel Vetter wrote:
> We've always been struggling with stolen handling, and we've' always
> been struggling with vt-d stuff. Also pass-through seems to be a major
> pain (I've never tried myself). Given all that I'm voting for keeping
> the RMRR and everything e
On Tue, 2014-06-17 at 06:22 -0600, Alex Williamson wrote:
> On Tue, 2014-06-17 at 08:04 +0100, David Woodhouse wrote:
> > On Mon, 2014-06-16 at 23:35 -0600, Alex Williamson wrote:
> > >
> > > Any idea what an off-the-shelf Asus motherboard would be doing with an
s)
... so I've just stuck a sleep(5) in there to get the test to succeed.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
ling fault status reg 2
dmar: DMAR:[DMA Write] Request device [00:02.0] fault addr 88
DMAR:[fault reason 23] Unknown
fbcon: inteldrmfb (fb0) is primary device
Signed-off-by: David Woodhouse
Cc: sta...@vger.kernel.org
---
[17:01] can you pls submit this as a patch to intel-gfx?
[17:01]
62 matches
Mail list logo
