Am 21.10.19 um 20:09 schrieb Navid Emamdoost:
> In the impelementation of amdgpu_fence_emit() if dma_fence_wait() fails
> and returns an errno, before returning the allocated memory for fence
> should be released.
>
> Fixes: 3d2aca8c8620 ("drm/amdgpu: fix old fence check in amdgpu_fence_emit")
> Si
Am 16.10.19 um 14:18 schrieb Christian König:
> Am 16.10.19 um 13:51 schrieb Gerd Hoffmann:
>> Factor out ttm vma setup to a new function.
>> Reduces code duplication a bit.
>>
>> v2: don't change vm_flags (moved to separate patch).
>> v4: make ttm_bo_mmap_vma_setup static.
>>
>> Signed-off-by: Ger
Am 30.09.19 um 23:26 schrieb Navid Emamdoost:
> In acp_hw_init there are some allocations that needs to be released in
> case of failure:
>
> 1- adev->acp.acp_genpd should be released if any allocation attemp for
> adev->acp.acp_cell, adev->acp.acp_res or i2s_pdata fails.
> 2- all of those allocati
Am 11.09.19 um 17:08 schrieb Thomas Hellström (VMware):
> On 9/11/19 4:06 PM, Koenig, Christian wrote:
>> Am 11.09.19 um 12:10 schrieb Thomas Hellström (VMware):
>> [SNIP]
>>>>> The problem seen in TTM is that we want to be able to change the
>>>>>
Am 17.09.19 um 11:24 schrieb Gerd Hoffmann:
> Not obvious why this is needed. According to Deniel Vetter this is most
> likely a historic artefact dating back to the days where drm drivers
> exposed hardware registers as mmap'able gem objects, to avoid dumping
> touching those registers.
Clearly
Am 10.09.19 um 21:26 schrieb Thomas Hellström (VMware):
> On 9/10/19 6:11 PM, Andy Lutomirski wrote:
>>
>>> On Sep 5, 2019, at 8:24 AM, Christoph Hellwig
>>> wrote:
>>>
On Thu, Sep 05, 2019 at 05:21:24PM +0200, Thomas Hellström (VMware)
wrote:
> On 9/5/19 4:15 PM, Dave Hansen wrote
Am 23.07.19 um 01:08 schrieb Logan Gunthorpe:
> As discussed on the list previously, in order to fully support the
> whitelist Christian added with the IOMMU, we must ensure that we
> map any buffer going through the IOMMU with an aprropriate dma_map
> call. This patchset accomplishes this by clean
Am 23.07.19 um 01:08 schrieb Logan Gunthorpe:
> pci_p2pdma_[un]map_resource() can be used to map a resource given
> it's physical address and the backing pci_dev. The functions will call
> dma_[un]map_resource() when appropriate.
>
> This is for demonstration purposes only as there are no users of
Am 23.07.19 um 01:08 schrieb Logan Gunthorpe:
> When a P2PDMA transfer is rejected due to ACS being set, we
> can also check the white list and allow the transactions.
>
> Do this by pushing the whitelist check into the
> upstream_bridge_distance() function.
>
> Signed-off-by: Logan Gunthorpe
Thi
Am 23.07.19 um 01:08 schrieb Logan Gunthorpe:
> Add constant flags to indicate two devices are not supported or whether
> the data path goes through the host bridge instead of using the negative
> values -1 and -2.
>
> This helps annotate the code better, but the main reason is so we
> can cache th
Am 04.06.19 um 13:48 schrieb Andrey Konovalov:
> On Tue, Jun 4, 2019 at 1:46 PM Koenig, Christian
> wrote:
>> Am 04.06.19 um 13:44 schrieb Andrey Konovalov:
>>> Architectures that support memory tagging have a need to perform untagging
>>> (stripping the tag) in var
Am 04.06.19 um 13:44 schrieb Andrey Konovalov:
> Architectures that support memory tagging have a need to perform untagging
> (stripping the tag) in various parts of the kernel. This patch adds an
> untagged_addr() macro, which is defined as noop for architectures that do
> not support memory taggi
Please ignore this mail,
I've fixed the double unlock and lockdep is still complaining about the
nested locking, so I'm actually facing multiple issues here.
Sorry to waste your time,
Christian.
Am 20.05.19 um 13:19 schrieb Christian König:
> Hi guys,
>
> writing the usual suspects about lockin
Hi guys,
writing the usual suspects about locking/lockdep stuff and also Daniel
in CC because he might have stumbled over this as well.
It took me a while to figuring out what the heck lockdep was complaining
about. The relevant dmesg was the following:
> [ 145.623005]
Am 18.04.19 um 10:08 schrieb Daniel Vetter:
> On Wed, Apr 17, 2019 at 09:13:22PM +0200, Christian König wrote:
>> Am 17.04.19 um 21:07 schrieb Daniel Vetter:
>>> On Tue, Apr 16, 2019 at 08:38:33PM +0200, Christian König wrote:
Each importer can now provide an invalidate_mappings callback.
Am 12.02.19 um 15:05 schrieb Colin King:
> From: Colin Ian King
>
> There are several statements that are incorrectly indented. Fix these.
>
> Signed-off-by: Colin Ian King
Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 2 +-
> drivers/gpu/drm/am
Am 30.01.19 um 09:02 schrieb Christoph Hellwig:
> On Tue, Jan 29, 2019 at 08:58:35PM +, Jason Gunthorpe wrote:
>> On Tue, Jan 29, 2019 at 01:39:49PM -0700, Logan Gunthorpe wrote:
>>
>>> implement the mapping. And I don't think we should have 'special' vma's
>>> for this (though we may need some
Am 24.01.19 um 13:06 schrieb Ard Biesheuvel:
> The DRM driver stack is designed to work with cache coherent devices
> only, but permits an optimization to be enabled in some cases, where
> for some buffers, both the CPU and the GPU use uncached mappings,
> removing the need for DMA snooping and all
Am 24.01.19 um 12:26 schrieb Ard Biesheuvel:
> On Thu, 24 Jan 2019 at 12:23, Koenig, Christian
> wrote:
>> Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
>>> [SNIP]
>>> This is *exactly* my point the whole time.
>>>
>>> The current code has
>&g
Am 24.01.19 um 10:59 schrieb Ard Biesheuvel:
> [SNIP]
> This is *exactly* my point the whole time.
>
> The current code has
>
> static inline bool drm_arch_can_wc_memory(void)
> {
> #if defined(CONFIG_PPC) && !defined(CONFIG_NOT_COHERENT_CACHE)
> return false;
>
> which means the optimization i
Am 24.01.19 um 10:28 schrieb Ard Biesheuvel:
> On Thu, 24 Jan 2019 at 10:25, Koenig, Christian
> wrote:
>> Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
>>> On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
>>>> But my concern is that it see
Am 24.01.19 um 10:13 schrieb Christoph Hellwig:
> On Wed, Jan 23, 2019 at 05:52:50PM +0100, Ard Biesheuvel wrote:
>> But my concern is that it seems likely that non-cache coherent
>> implementations are relying on this hack as well. There must be a
>> reason that this hack is only disabled for Powe
Am 21.01.19 um 11:06 schrieb Ard Biesheuvel:
> Currently, the DRM code assumes that PCI devices are always cache
> coherent for DMA, and that this can be selectively overridden for
> some buffers using non-cached mappings on the CPU side and PCIe
> NoSnoop transactions on the bus side.
>
> Whether
Am 16.01.19 um 01:33 schrieb Benjamin Herrenschmidt:
> On Tue, 2019-01-15 at 22:31 +1100, Michael Ellerman wrote:
As far as I know Power doesn't really supports un-cached memory at all,
except for a very very old and odd configuration with AGP.
>>> Hopefully Michael/Ben can elaborate here
Am 16.01.19 um 08:09 schrieb Thomas Hellstrom:
> On Tue, 2019-01-15 at 21:58 +0100, h...@lst.de wrote:
>> On Tue, Jan 15, 2019 at 07:13:11PM +0000, Koenig, Christian wrote:
>>> Thomas is correct that the interface you propose here doesn't work
>>> at
>>> a
Am 15.01.19 um 19:31 schrieb h...@lst.de:
> On Tue, Jan 15, 2019 at 06:03:39PM +, Thomas Hellstrom wrote:
>> In the graphics case, it's probably because it doesn't fit the graphics
>> use-cases:
>>
>> 1) Memory typically needs to be mappable by another device. (the "dma-
>> buf" interface)
> An
Am 14.01.19 um 20:13 schrieb Will Deacon:
> On Mon, Jan 14, 2019 at 07:07:54PM +0000, Koenig, Christian wrote:
>> Am 14.01.19 um 18:32 schrieb Ard Biesheuvel:
>> - The reason remapping the CPU side as cacheable does work
>> (which I
>> did
Am 14.01.19 um 11:53 schrieb Ard Biesheuvel:
> On Thu, 10 Jan 2019 at 10:34, Michel Dänzer wrote:
>> On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote:
>>> ARM systems do not permit the use of anything other than cached
>>> mappings for system memory, since that memory may be mapped in the
>>> linear
Hi Ard,
thanks a lot for this! At least somebody who can explain why this
doesn't work as expected.
The problem is that the hardware actually needs a few pages as uncached
in a couple of cases to work correctly. So we could still run into
issues with that solution.
For now we have blocked use
Am 21.12.18 um 19:35 schrieb Dmitry Osipenko:
> On 21.12.2018 21:27, Christian König wrote:
>> Am 19.12.18 um 18:53 schrieb Dmitry Osipenko:
>>> [SNIP]
@@ -931,9 +718,6 @@ static signed long
drm_syncobj_array_wait_timeout(struct drm_syncobj **syncobjs,
if (flags & DRM_SYNCO
Patches #1 and #3 are Reviewed-by: Christian König
Patch #2 is Acked-by: Christian König because
I can't judge if adding the counter in the thread structure is actually
a good idea.
In patch #4 I honestly don't understand at all how this stuff works, so
no-comment from my side on this.
Chr
Am 07.12.18 um 20:16 schrieb Eric Anholt:
> The entity->dependency can go away completely once we've called
> drm_sched_entity_add_dependency_cb() (if the cb is called before we
> get around to tracing). The tracepoint is more useful if we trace
> every dependency instead of just ones that get cal
Hi Stephen,
yeah, that is a known problem. I missed the change during rebase of the
revert.
Please see patch "2312f9842854 drm/v3d: fix broken build" which is
already in drm-misc-next and fixes the issue.
Christian.
Am 06.12.18 um 03:32 schrieb Stephen Rothwell:
> Hi all,
>
> After merging th
Am 06.12.18 um 17:58 schrieb Chris Wilson:
> Quoting jgli...@redhat.com (2018-12-06 15:47:04)
>> From: Jérôme Glisse
>>
>> The debugfs take reference on fence without dropping them. Also the
>> rcu section are not well balance. Fix all that ...
> Wouldn't the code be a lot simpler (and a consisten
Am 06.12.18 um 17:18 schrieb jgli...@redhat.com:
> From: Jérôme Glisse
>
> The debugfs take reference on fence without dropping them.
>
> Signed-off-by: Jérôme Glisse
> Cc: Christian König
> Cc: Daniel Vetter
> Cc: Sumit Semwal
> Cc: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedeskto
Am 06.12.18 um 16:21 schrieb Jerome Glisse:
> On Thu, Dec 06, 2018 at 08:09:28AM +0000, Koenig, Christian wrote:
>> Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
>>> From: Jérôme Glisse
>>>
>>> The debugfs take reference on fence without dropping them. A
Am 06.12.18 um 02:41 schrieb jgli...@redhat.com:
> From: Jérôme Glisse
>
> The debugfs take reference on fence without dropping them. Also the
> rcu section are not well balance. Fix all that ...
>
> Signed-off-by: Jérôme Glisse
> Cc: Christian König
> Cc: Daniel Vetter
> Cc: Sumit Semwal
> Cc
Am 03.12.18 um 21:14 schrieb Eric Anholt:
> With DEBUG_SLAB (poisoning on free) enabled, I could quickly produce
> an oops when tracing V3D.
Good catch, but the solution is a clear NAK.
drm_sched_entity_add_dependency_cb() can result in setting
entity->dependency to NULL. That in turn can lead t
Am 08.11.18 um 17:19 schrieb Eric Anholt:
> "Koenig, Christian" writes:
>
>> Am 08.11.18 um 17:04 schrieb Eric Anholt:
>>> This reverts commit 0efd2d2f68cd5dbddf4ecd974c33133257d16a8e. Fixes
>>> this failure in V3D GPU reset:
>>>
>&g
39 matches
Mail list logo
