e
> start re-using the memory for something else while it's still being
> accessed.
>
> The solution would be to wait for the EOL (End Of Line) interrupt in
> the async update path, but I'm not sure this is allowed.
For subsuming async page_flip into the async atomic
have various issues with iommu
and igfx is very long, thus far we only disabled it where there's no
workaround to stop it from hanging the box, but otherwise left it
enabled. So if we make a policy change to also disable it anywhere
where it doesn't work well (instead of no
ata,
> return -ENOMEM;
> }
>
> - entry->virtual = drm_vmalloc_dma(pages << PAGE_SHIFT);
> + entry->virtual = vmalloc_32(pages << PAGE_SHIFT);
> if (!entry->virtual) {
> kfre
On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
wrote:
>
> On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
> > On Wed, Apr 08, 2020 at 01:59:17PM +0200, Christoph Hellwig wrote:
> > > If this code was broken for non-coherent caches a crude powerpc hack
>
On Thu, Apr 9, 2020 at 4:19 PM Alex Deucher wrote:
>
> On Thu, Apr 9, 2020 at 5:41 AM Daniel Vetter wrote:
> >
> > On Thu, Apr 9, 2020 at 10:54 AM Benjamin Herrenschmidt
> > wrote:
> > >
> > > On Wed, 2020-04-08 at 14:25 +0200, Daniel Vetter wrote:
On Fri, Apr 10, 2020 at 12:57 AM Benjamin Herrenschmidt
wrote:
>
> On Thu, 2020-04-09 at 11:41 +0200, Daniel Vetter wrote:
> > Now if these boxes didn't ever have agp then I think we can get away
> > with deleting this, since we've already deleted the legacy radeon
&
oth? I.e. roll out better wrappers
first, once that's soaked through the tree, rename the last offenders.
Personally I like nr_cpu_ents and nr_dma_ents, that's about as clear as it
gets.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
__
g rework past -rc6 (small drivers tend
to be a bit later). I think simpler if we just land this in the merge
window and then smash the drm patches on top for 5.9 merge window.
Or all in in the same topic branch, but feels a bit late for that and
making sure nothing breaks.
-Daniel
>
> Best
infrastructure just not there yet or
do you plan to tightly integrate the tegra drm with the iommu (e.g. for
process space switching or similarly funky stuff)?
Yours, Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
iommu mai
On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
> * Daniel Vetter wrote:
> > On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
> > > This commit adds a very basic DRM driver for NVIDIA Tegra SoCs. It
> > > currently has rudimentary GEM suppo
On Wed, Apr 11, 2012 at 04:11:08PM +0200, Thierry Reding wrote:
> * Daniel Vetter wrote:
> > On Wed, Apr 11, 2012 at 03:23:26PM +0200, Thierry Reding wrote:
> > > * Daniel Vetter wrote:
> > > > On Wed, Apr 11, 2012 at 02:10:30PM +0200, Thierry Reding wrote:
> >
#x27;t use it to linearise pages for
> CPU view) and the 3600 is even stranger
Sorry, I really try to totally ignore everything related to gma500 ;-)
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
Mobile: +41 (0)79 365 57 48
___
iommu mailing list
On Fri, Aug 16, 2019 at 4:31 PM Corentin Labbe
wrote:
> On Wed, Aug 14, 2019 at 07:49:27PM +0200, Daniel Vetter wrote:
> > On Wed, Aug 14, 2019 at 04:50:33PM +0200, Corentin Labbe wrote:
> > > Hello
> > >
> > > Since lot of release (at least since 4.19), I hi
svm_range_dev (struct intel_svm
> > *svm, struct intel_svm_d
> > * for example, an "address" value of 0x12345f000 will
> > * flush from 0x12344 to 0x12347 (256KiB). */
> > unsigned long last = a
pointer is enough to pass an array.
Also maybe make the handle pointer
const, so it's clear that it's an input parameter.
With the bikesheds addressed:
Reviewed-by: Daniel Vetter
> +{
> + int i, ret = 0;
> + struct drm_gem_object *obj;
> +
> +
erlying
buffer size is not going to work I think.
Note: I didn't read kbase, so might be totally wrong in how GROW_ON_GPF
works.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Mon, Apr 15, 2019 at 10:30:14AM +0100, Steven Price wrote:
> On 15/04/2019 10:18, Daniel Vetter wrote:
> > On Fri, Apr 05, 2019 at 05:42:33PM +0100, Steven Price wrote:
> >> On 05/04/2019 17:16, Alyssa Rosenzweig wrote:
> >>> acronym once ever and have it as a &quo
Joonas Lahtinen
> Cc: Maarten Lankhorst
> Cc: dri-de...@lists.freedesktop.org
> Cc: David Airlie
> Cc: Jani Nikula
> Cc: Daniel Vetter
> Cc: Rodrigo Vivi
Acked-by: Daniel Vetter
for merging through whatever tree is convenient for you (or tell me I
should pick it up into drm-
ny DMA mapping and
> see:
> cat /sys/kernel/debug/dma-api/dump | cut -d' ' -f2 | sort | uniq -c
> 6 ahci
> 257 e1000e
> 6 ehci-pci
>5891 nouveau
> 24 uhci_hcd
>
> Does nouveau having this high number of DMA mapping is normal ?
Yeah se
; > returned DMA addresses directly or ignore them if it knows they're
> > overridden by its own IOMMU mapping.
>
> I'd be happy to review patches for this.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
)
> +{
> + of_node_put(data);
> +}
> +
> +static inline int compare_dev(struct device *dev, void *data)
> +{
> + return dev == data;
> +}
> +
> void component_master_del(struct device *,
> const struct component_master_ops *);
>
> diff -
7ffe3edab9b8 EFLAGS: 0246 ORIG_RAX: 0010
> RAX: ffda RBX: RCX: 7f62fcf530f9
> RDX: 2200 RSI: 40086200 RDI: 0006
> RBP: 00007f62fcf170e0 R08: R09:
> R10: 00
t I think it would've been a lot better if ARM_DMA_USE_IOMMU
> > was just enabled unconditionally if it has side-effects that platforms
> > don't opt in to but have to explicitly opt out of.
>
> Agreed on that count. Please send a patch.
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
iommu mailing list
iommu@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/iommu
On Wed, Apr 25, 2018 at 5:33 PM, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote:
>> > Coordinating the backport of a trivial helper in the arm tree is not
>> > the end of the world. Really, this cowboy attitude is a good reason
&g
On Thu, Apr 26, 2018 at 1:26 AM, Russell King - ARM Linux
wrote:
> On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote:
>> On arm that doesn't work. The iommu api seems like a good fit, except
>> the dma-api tends to get in the way a bit (drm/msm apparently has
>
On Thu, Apr 26, 2018 at 11:09 AM, Christoph Hellwig wrote:
> On Wed, Apr 25, 2018 at 11:35:13PM +0200, Daniel Vetter wrote:
>> > get_required_mask() is supposed to tell you if you are safe. However
>> > we are missing lots of implementations of it for iommus so you migh
On Thu, Apr 26, 2018 at 11:24 AM, Christoph Hellwig wrote:
> On Thu, Apr 26, 2018 at 11:20:44AM +0200, Daniel Vetter wrote:
>> The above is already what we're implementing in i915, at least
>> conceptually (it all boils down to clflush instructions because those
>>
On Thu, Apr 26, 2018 at 12:54 AM, Russell King - ARM Linux
wrote:
> On Wed, Apr 25, 2018 at 08:33:12AM -0700, Christoph Hellwig wrote:
>> On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote:
>> > - dma api hides the cache flushing requirements from us. GPUs love
p; printk_ratelimit()) {
>> + if (!(attrs & DMA_ATTR_NO_WARN) && printk_ratelimit()) {
>> dev_warn(dev,
>> "swiotlb: coherent allocation failed, size=%zu\n",
>> size);
>
>
29 matches
Mail list logo
