On Fri, 2019-08-09 at 14:03 +0200, Lucas Stach wrote:
> This function does only need the mmu part part of the gpu struct.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
regards
Philipp
___
dri-devel mailing list
In preparation to having a context per process, etnaviv_gem_mapping_get
should not use the current GPU context, but needs to be told which
context to use.
Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
---
drivers/gpu/drm/etnaviv/etnaviv_gem.c| 22
This reworks the MMU handling to make it possible to have multiple MMU contexts.
A context is basically one instance of GPU page tables. Currently we have one
set of page tables per GPU, which isn't all that clever, as it has the
following two consequences:
1. All GPU clients (aka processes) are
Allow the mapping code to request a specific virtual address for the gem
mapping. If the virtual address is zero we fall back to the old mode of
allocating a virtual address for the mapping.
Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
---
v2: use INSERT_LOWEST for fixed VA maode
---
With per-process address spaces in place, a rogue process submitting
bogus command streams can only hurt itself. There is no need to
validate the command stream before execution anymore.
Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
---
drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 3
Move buffer setup and starting of the FE loop in the kernel ringbuffer
into a separate function. This is a preparation to start the FE later
in the submit process.
Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 26 --
1
With softpin we allow the userspace to take control over the GPU virtual
address space. The new capability is relected by a bump of the minor DRM
version. There are a few restrictions for userspace to take into
account:
1. The kernel reserves a bit of the address space to implement zero page
If a MMU is shared between multiple GPUs, all of them need to flush their
TLBs, so a single marker that gets reset on the first flush won't do.
Replace the flush marker with a sequence number, so that it's possible to
check if the TLB is in sync with the current page table state for each GPU.
This allows to decouple the cmdbuf suballocator create and mapping
the region into the GPU address space. Allowing multiple AS to share
a single cmdbuf suballoc.
Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
Reviewed-by: Guido Günther
---
v3: moved adding mapping to MMU mmaping lsit to
There is no need for each GPU to have it's own cmdbuf suballocation
region. Only allocate a single one for the the etnaviv virtual device
and share it across all GPUs.
As the suballoc space is now potentially shared by more hardware jobs
running in parallel, double its size to 512KB to avoid
This builds on top of the MMU contexts introduced earlier. Instead of having
one context per GPU core, each GPU client receives its own context.
On MMUv1 this still means a single shared pagetable set is used by all
clients, but on MMUv2 there is now a distinct set of pagetables for each
client.
Remember if the GPU has been sucessfully initialized. Only in that case
do we need to clean up various structures in the unbind path. If the
GPU hasn't been sucessfully initialized all the cleanups should happen
in the failure paths of the init function.
Signed-off-by: Lucas Stach
Reviewed-by:
Due to the tracking provided by the scheduler we know exactly which
submit is failing. Only dump this single submit and the required
auxiliary information. This cuts down the size of the devcoredumps
by only including relevant information.
Signed-off-by: Lucas Stach
Reviewed-by: Philipp Zabel
This function does only need the mmu part part of the gpu struct.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_dump.c | 6 +++---
drivers/gpu/drm/etnaviv/etnaviv_dump.h | 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git
Quoting Lionel Landwerlin (2019-08-09 12:30:30)
> +int drm_syncobj_binary_ioctl(struct drm_device *dev, void *data,
> +struct drm_file *file_private)
> +{
> + struct drm_syncobj_binary_array *args = data;
> + struct drm_syncobj **syncobjs;
> + u32
On 08.08.2019 21:32, Laurent Pinchart wrote:
> Hello,
>
> On Tue, Jul 16, 2019 at 03:57:21PM +0200, Andrzej Hajda wrote:
>> On 16.07.2019 11:00, Daniel Vetter wrote:
>>> On Fri, Jul 12, 2019 at 11:01:38AM +0200, Andrzej Hajda wrote:
On 11.07.2019 17:50, Daniel Vetter wrote:
> On Thu, Jul
Quoting Lionel Landwerlin (2019-08-09 12:30:30)
> diff --git a/include/uapi/drm/drm.h b/include/uapi/drm/drm.h
> index 8a5b2f8f8eb9..1ce83853f997 100644
> --- a/include/uapi/drm/drm.h
> +++ b/include/uapi/drm/drm.h
> @@ -785,6 +785,22 @@ struct drm_syncobj_timeline_array {
> __u32 pad;
>
On Fri, Aug 9, 2019 at 1:32 PM Bartlomiej Zolnierkiewicz
wrote:
> On 8/8/19 11:22 PM, Arnd Bergmann wrote:
> > The omapfb driver is split into platform specific code for omap1, and
> > driver code that is also specific to omap1.
> >
> > Moving both parts into the driver directory simplifies the
On 8/7/19 3:33 AM, john.hubb...@gmail.com wrote:
> From: John Hubbard
>
> For pages that were retained via get_user_pages*(), release those pages
> via the new put_user_page*() routines, instead of via put_page() or
> release_pages().
>
> This is part a tree-wide conversion, as described in
On 8/8/19 11:22 PM, Arnd Bergmann wrote:
> All the headers we actually need are now in include/linux/soc,
> so use those versions instead and allow compile-testing on
> other architectures.
>
> Signed-off-by: Arnd Bergmann
For fbdev part:
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
On 8/8/19 11:22 PM, Arnd Bergmann wrote:
> The omapfb driver is split into platform specific code for omap1, and
> driver code that is also specific to omap1.
>
> Moving both parts into the driver directory simplifies the structure
> and avoids the dependency on certain omap machine header
Now with a single ioctl().
Cheers,
Lionel Landwerlin (1):
drm/syncobj: add sideband payload
drivers/gpu/drm/drm_internal.h | 2 ++
drivers/gpu/drm/drm_ioctl.c| 3 ++
drivers/gpu/drm/drm_syncobj.c | 55 +-
include/drm/drm_syncobj.h | 9 ++
The Vulkan timeline semaphores allow signaling to happen on the point
of the timeline without all of the its dependencies to be created.
The current 2 implementations (AMD/Intel) of the Vulkan spec on top of
the Linux kernel are using a thread to wait on the dependencies of a
given point to
On 8/8/19 11:22 PM, Arnd Bergmann wrote:
> To avoid using the mach/omap1510.h header file, pass the correct
> address as platform data.
>
> Signed-off-by: Arnd Bergmann
For fbdev part:
Acked-by: Bartlomiej Zolnierkiewicz
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
On Tue, 2019-07-02 at 16:18 +0200, Lucas Stach wrote:
> Due to the tracking provided by the scheduler we know exactly which
> submit is failing. Only dump this single submit and the required
> auxiliary information. This cuts down the size of the devcoredumps
> by only including relevant
https://bugs.freedesktop.org/show_bug.cgi?id=22
--- Comment #12 from Pierre-Eric Pelloux-Prayer
---
(In reply to Brian Schott from comment #10)
> Just rebuilt mesa, libdrm, and xf86-video-amdgpu from git this evening. The
> kernel is the gentoo patched version of 5.2.6. The problem is not
On 09/08/2019 11:07, Christoph Hellwig wrote:
> On Fri, Aug 09, 2019 at 09:40:32AM +0300, Tomi Valkeinen wrote:
>> We do call dma_set_coherent_mask() in omapdrm's probe() (in omap_drv.c),
>> but apparently that's not enough anymore. Changing that call to
>> dma_coerce_mask_and_coherent() removes
On Fri, Aug 09, 2019 at 10:54:41AM +0200, Gerd Hoffmann wrote:
> A bit later:
>
>[8.198138] radeon :00:01.0: Direct firmware load for
> radeon/PALM_pfp.bin failed with error -2
>[8.198351] r600_cp: Failed to load firmware "radeon/PALM_pfp.bin"
>[8.198512]
Hi Julien,
On 08/08/2019 16:12, Neil Armstrong wrote:
> On 25/06/2019 01:24, Kevin Hilman wrote:
>> Julien Masson writes:
>>
>>> This patch series aims to clean-up differents parts of the drm meson
>>> code source.
>>>
>>> Couple macros have been defined and used to set several registers
>>>
Hi,
On Fri, Aug 09, 2019 at 11:17:13AM +0200, Lucas Stach wrote:
> Am Donnerstag, den 08.08.2019, 12:26 +0200 schrieb Guido Günther:
> > Hi,
> > On Fri, Jul 05, 2019 at 07:17:21PM +0200, Lucas Stach wrote:
> > > This allows to decouple the cmdbuf suballocator create and mapping
> > > the region
https://bugs.freedesktop.org/show_bug.cgi?id=111248
Matt changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
Am Donnerstag, den 08.08.2019, 12:26 +0200 schrieb Guido Günther:
> Hi,
> On Fri, Jul 05, 2019 at 07:17:21PM +0200, Lucas Stach wrote:
> > This allows to decouple the cmdbuf suballocator create and mapping
> > the region into the GPU address space. Allowing multiple AS to share
> > a single cmdbuf
On Fri, Aug 09, 2019 at 09:59:56AM +0300, Tomi Valkeinen wrote:
> Hi,
>
> On 08/08/2019 15:50, Laurent Pinchart wrote:
> > Hi Greg,
> >
> > Thank you for the patch.
> >
> > On Thu, Jun 13, 2019 at 01:57:49PM +0200, Greg Kroah-Hartman wrote:
> > > When calling debugfs functions, there is no need
Am Dienstag, den 02.07.2019, 16:18 +0200 schrieb Lucas Stach:
> Due to the tracking provided by the scheduler we know exactly which
> submit is failing. Only dump this single submit and the required
> auxiliary information. This cuts down the size of the devcoredumps
> by only including relevant
On Fri, Aug 09, 2019 at 10:25:32AM +0200, Code Kipper wrote:
> On Tue, 6 Aug 2019 at 17:57, wrote:
> >
> > From: Ondrej Jirman
> >
> > Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
> > I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
> >
On Fri, Aug 09, 2019 at 09:47:00AM +0200, Borislav Petkov wrote:
> Hi,
>
> On Fri, Aug 09, 2019 at 09:21:33AM +0200, Gerd Hoffmann wrote:
> > On Thu, Aug 08, 2019 at 07:45:42PM +0200, Borislav Petkov wrote:
> > > Hi,
> > >
> > > for some unfathomable to me reason, the commit in $Subject breaks
>
https://bugs.freedesktop.org/show_bug.cgi?id=110258
--- Comment #11 from Paul Gover ---
I got in touch with the developer. He made a fix, I've tested it, so I presume
it will be included in the next kernel (for certain values of "next").
I could ask him if I could put the patch here, if people
https://bugs.freedesktop.org/show_bug.cgi?id=111332
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Gallium/radeonsi
On Thu 08-08-19 16:25:04, Weiny, Ira wrote:
> > I thought I'd caught things early enough to get away with the
> > rename and deletion of that. You could either:
> >
> > a) open code an implementation of vaddr_put_pages_dirty_lock() that
> > doesn't call any of the *put_user_pages_dirty*()
https://bugs.freedesktop.org/show_bug.cgi?id=100239
--- Comment #25 from Michel Dänzer ---
(In reply to Bruno Jacquet (Xaapyks) from comment #23)
> So I'd say the issue is still there.
Maybe you have a ~/.drirc or other drirc file which gets picked up and disables
radeonsi_zerovram? (E.g. due
On Wed 07-08-19 19:36:37, Ira Weiny wrote:
> On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
> > > So I think your debug option and my suggested renaming serve a bit
> > > different purposes (and thus both make sense). If you do the renaming, you
> > > can just grep to see
On Tue, 6 Aug 2019 at 17:57, wrote:
>
> From: Ondrej Jirman
>
> Orange Pi 3 has a DDC_CEC_EN signal connected to PH2, that enables the DDC
> I2C bus voltage shifter. Before EDID can be read, we need to pull PH2 high.
> This is realized by the ddc-en-gpios property.
Great work. Is there any
On Thu, Aug 08, 2019 at 09:44:32AM -0700, Rob Clark wrote:
> > GFP_HIGHUSER basically just means that this is an allocation that could
> > dip into highmem, in which case it would not have a kernel mapping.
> > This can happen on arm + LPAE, but not on arm64.
>
> Just a dumb question, but why is
On Thu, Aug 08, 2019 at 01:58:08PM +0200, Daniel Vetter wrote:
> > > We use shmem to get at swappable pages. We generally just assume that
> > > the gpu can get at those pages, but things fall apart in fun ways:
> > > - some setups somehow inject bounce buffers. Some drivers just give
> > > up,
Hi,
On 8/7/19 6:42 PM, Thomas Zimmermann wrote:
Hi Rong
Am 06.08.19 um 14:59 schrieb Chen, Rong A:
Hi,
On 8/5/2019 6:25 PM, Thomas Zimmermann wrote:
Hi
Am 05.08.19 um 09:28 schrieb Rong Chen:
Hi,
On 8/5/19 3:02 PM, Feng Tang wrote:
Hi Thomas,
On Sun, Aug 04, 2019 at 08:39:19PM +0200,
On Fri, Aug 09, 2019 at 09:40:32AM +0300, Tomi Valkeinen wrote:
> We do call dma_set_coherent_mask() in omapdrm's probe() (in omap_drv.c),
> but apparently that's not enough anymore. Changing that call to
> dma_coerce_mask_and_coherent() removes the WARN. I can create a patch for
> that, or
On Tue, Aug 6, 2019 at 5:59 AM Josh Poimboeuf wrote:
>
> On Mon, Aug 05, 2019 at 09:29:53PM +0200, Sedat Dilek wrote:
> > On Wed, Jul 31, 2019 at 2:25 PM Sedat Dilek wrote:
> > >
> > > On Fri, Jul 26, 2019 at 9:30 PM Chris Wilson
> > > wrote:
> > > >
> > > > Quoting Thomas Gleixner (2019-07-26
On 8/8/19 11:53 AM, Alex Deucher wrote:
On Thu, Aug 8, 2019 at 2:53 PM Guenter Roeck wrote:
On Mon, Aug 05, 2019 at 12:12:05PM +0100, Mark Brown wrote:
On Mon, Aug 05, 2019 at 02:40:32AM -0700, kernelci.org bot wrote:
Today's -next fails to build an arm allmodconfig due to:
allmodconfig
On 02/08/2019 20:51, Rob Herring wrote:
> In preparation to create partial GPU mappings of BOs on page faults,
> split out the SG list handling of panfrost_mmu_map().
>
> Cc: Tomeu Vizoso
> Cc: Boris Brezillon
> Cc: Robin Murphy
> Cc: Steven Price
> Acked-by: Alyssa Rosenzweig
>
This improves Sphinx output in two ways:
- It avoids an unmatched single-quote ('), about which Sphinx complained:
/.../Documentation/gpu/drm-internals.rst:298:
WARNING: Could not lex literal_block as "c". Highlighting skipped.
An alternative approach would be to replace "can't" with a
On 8/7/19 10:42 PM, Michael Ellerman wrote:
> Hi John,
>
> john.hubb...@gmail.com writes:
>> diff --git a/arch/powerpc/mm/book3s64/iommu_api.c
>> b/arch/powerpc/mm/book3s64/iommu_api.c
>> index b056cae3388b..e126193ba295 100644
>> --- a/arch/powerpc/mm/book3s64/iommu_api.c
>> +++
On Thu, 8 Aug 2019 13:32:06 +0800 Alex Deucher wrote:
>
> On Wed, Aug 7, 2019 at 11:49 PM Mikhail Gavrilov wrote:
> >
> > Unfortunately error "gnome-shell: page allocation failure: order:4,
> > mode:0x40cc0(GFP_KERNEL|__GFP_COMP),
> > nodemask=(null),cpuset=/,mems_allowed=0" still happens even
On 02/08/2019 20:51, Rob Herring wrote:
> The midgard/bifrost GPUs need to allocate GPU heap memory which is
> allocated on GPU page faults and not pinned in memory. The vendor driver
> calls this functionality GROW_ON_GPF.
>
> This implementation assumes that BOs allocated with the
>
On Mon, Aug 05, 2019 at 12:12:05PM +0100, Mark Brown wrote:
> On Mon, Aug 05, 2019 at 02:40:32AM -0700, kernelci.org bot wrote:
>
> Today's -next fails to build an arm allmodconfig due to:
>
> > allmodconfig (arm, gcc-8) — FAIL, 2 errors, 16 warnings, 0 section
> > mismatches
> >
> > Errors:
>
On 8/8/19 9:25 AM, Weiny, Ira wrote:
>>
>> On 8/7/19 7:36 PM, Ira Weiny wrote:
>>> On Wed, Aug 07, 2019 at 10:46:49AM +0200, Michal Hocko wrote:
On Wed 07-08-19 10:37:26, Jan Kara wrote:
> On Fri 02-08-19 12:14:09, John Hubbard wrote:
>> On 8/2/19 7:52 AM, Jan Kara wrote:
>>> On
On 02/08/2019 20:51, Rob Herring wrote:
> In preparation to handle mapping of page faults, we need the MMU handler
> to be threaded as code paths take a mutex.
>
> As the IRQ may be shared, we can't use the default handler and must
> disable the MMU interrupts locally.
>
> Cc: Tomeu Vizoso
>
> @@ -448,6 +453,7 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void
> *data)
> }
>
> if (status & JOB_INT_MASK_DONE(j)) {
> + panfrost_mmu_as_put(pfdev,
> >jobs[j]->file_priv->mmu);
>
On 8/9/19 5:01 AM, Rob Herring wrote:
On Thu, Aug 8, 2019 at 5:11 PM Alyssa Rosenzweig
wrote:
@@ -448,6 +453,7 @@ static irqreturn_t panfrost_job_irq_handler(int irq, void
*data)
}
if (status & JOB_INT_MASK_DONE(j)) {
+
On Thu, Aug 08, 2019 at 07:45:42PM +0200, Borislav Petkov wrote:
> Hi,
>
> for some unfathomable to me reason, the commit in $Subject breaks
> booting of the 32-bit partition of one of my test boxes. The box doesn't
> finish booting (normally it boots in text mode, there is no X server
> setup on
https://bugs.freedesktop.org/show_bug.cgi?id=22
--- Comment #11 from Chí-Thanh Christopher Nguyễn ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #9)
> Could you list the version number of the various component involved (kernel,
> mesa, xf86-video-amdgpu and libdrm) please?
kernel
Hi,
On 08/08/2019 15:50, Laurent Pinchart wrote:
Hi Greg,
Thank you for the patch.
On Thu, Jun 13, 2019 at 01:57:49PM +0200, Greg Kroah-Hartman wrote:
When calling debugfs functions, there is no need to ever check the
return value. The function can work or not, but the code logic should
Hi Boris,
On 08/08/2019 17:11, Boris Brezillon wrote:
> Hello,
>
> This patch series aims at adding support for runtime bus-format
> negotiation between all elements of the
> 'encoder -> bridges -> connector/display' section of the pipeline.
It was one of the big subject of the dw-hdmi support
Are you talking about the new ioctls or the existing wait?
Because we do not use the signal ioctl for binary semaphores.
On the wait side, it's used only for VkFence and we would save a 64bit
copy per fence we wait on.
I can't see that being a perf bottleneck.
On the new sideband ioctls if
Hi,
On 08/08/2019 13:10, Christoph Hellwig wrote:
The omapfb platform devices does not have a DMA mask set. The
traditional arm DMA code ignores, but the generic dma-direct/swiotlb
has stricter checks and thus fails mappings without a DMA mask.
As we use swiotlb for arm with LPAE now, omap
On Fri, Aug 02, 2019 at 08:07:52AM +, Lowry Li (Arm Technology China) wrote:
> From: "Lowry Li (Arm Technology China)"
>
> Initialize and enable output polling on Komeda.
>
> Changes since v1:
> 1. Enable the polling before registering the driver;
> 2. Disable the polling after
Hi Linus,
Usual fixes roundup, summary below in the signed tag. Nothing too
crazy or serious, one non-released ioctl is removed in the amdkfd
driver.
Dave.
drm-fixes-2019-08-09:
drm fixes for 5.3-rc4
core:
- mode parser strncpy fix
i915:
- GLK DSI escape clock setting
- HDCP memleak fix
101 - 166 of 166 matches
Mail list logo
