On Fri, 9 Aug 2019, Sedat Dilek wrote:
> On Fri, Aug 9, 2019 at 1:03 AM Nick Desaulniers
> wrote:
> >
> > On Thu, Aug 8, 2019 at 1:22 PM Thomas Gleixner wrote:
> > > > tglx just picked up 2 other patches of mine, bumping just in case he's
> > > > not picking up patches while on vacation. ;)
> >
Hi Noralf,
thank you for your comments. I've incorporated your suggestions into my draft.
On 8/7/19 1:06 AM, Noralf Trønnes wrote:
[...]
>> +static int gdepaper_probe(struct spi_device *spi)
>> +{
>> +struct device *dev = >dev;
>> +struct device_node *np = dev->of_node;
>> +const
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
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.
> >
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
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
>>>
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 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
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 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
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
https://bugs.freedesktop.org/show_bug.cgi?id=111332
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Gallium/radeonsi
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 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 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 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,
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 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
>
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:
>
> @@ -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 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 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 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*()
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
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 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 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
>
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
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
>> +++
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,
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=111248
Matt changed:
What|Removed |Added
QA Contact|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop.
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
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
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 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,
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
>
Am Freitag, den 09.08.2019, 14:04 +0200 schrieb Lucas Stach:
> 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,
We must make sure our scatterlist segments are not too big, otherwise
we might see swiotlb failures (happens with sev, also reproducable with
swiotlb=force).
Suggested-by: Laszlo Ersek
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_object.c | 10 --
1 file changed, 8
This patch-set add support for ADV7535 part in ADV7511 driver.
ADV7535 and ADV7533 are pin to pin compatible parts but ADV7535
support TMDS clock upto 148.5Mhz and resolutions up to 1080p@60Hz.
---
Changes in v2:
- rename CONFIG_DRM_I2C_ADV7533 to CONFIG_DRM_I2C_ADV753X and
update decription
On Fri, Aug 09, 2019 at 01:00:38PM +0300, Tomi Valkeinen wrote:
> Alright, thanks for the clarification!
>
> Here's my version.
Looks god to me:
Reviewed-by: Christoph Hellwig
On 8/9/19 1:43 PM, Arnd Bergmann wrote:
> 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
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
A bunch of fixes :)
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 | 58 +-
include/drm/drm_syncobj.h | 9 ++
https://bugs.freedesktop.org/show_bug.cgi?id=108718
--- Comment #2 from Pierre-Eric Pelloux-Prayer
---
Can you still reproduce this issue?
It seems to work fine here with a recent kernel + mesa configuration.
--
You are receiving this mail because:
You are the assignee for the
Hi Linus,
Please pull fbdev fix for v5.3-rc4 (fbdev patches will now go to
upstream through drm-misc tree for improved maintainership and
better integration testing so update MAINTAINERS file accordingly).
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung R Institute Poland
Samsung Electronics
Hi Laurent.
> > > +static int td043mtea1_disable(struct drm_panel *panel)
> > > +{
> > > + struct td043mtea1_device *lcd = to_td043mtea1_device(panel);
> > > +
> > > + if (!lcd->spi_suspended)
> > > + td043mtea1_power_off(lcd);
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static int
ADV7535 is a DSI to HDMI bridge chip like ADV7533 but it allows
1080p@60Hz. v1p2 is fixed to 1.8V on ADV7535 but on ADV7533 can be 1.2V
or 1.8V and is configurable in a register.
Signed-off-by: Bogdan Togorean
---
drivers/gpu/drm/bridge/adv7511/Kconfig | 8 ++---
ADV7535 is a part compatible with ADV7533 but it supports 1080p@60hz and
v1p2 supply is fixed to 1.8V
Signed-off-by: Bogdan Togorean
---
.../bindings/display/bridge/adi,adv7511.txt | 23 ++-
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git
cOn Fri, Aug 9, 2019 at 6:36 AM Steven Price wrote:
>
> On 08/08/2019 23:29, Rob Herring wrote:
> > Up until now, a single shared GPU address space was used. This is not
> > ideal as there's no protection between processes and doesn't work for
> > supporting the same GPU/CPU VA feature. Most
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,
--
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
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
Am 09.08.19 um 14:26 schrieb Lionel Landwerlin:
> On 09/08/2019 14:44, Chris Wilson wrote:
>> 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
>>> +++
Quoting Chris Wilson (2019-08-09 12:58:51)
> Quoting Lionel Landwerlin (2019-08-09 12:30:30)
> > + if (flags & I915_DRM_SYNCOBJ_BINARY_ITEM_VALUE_READ) {
> > + copy_to_user([i],
> > [i]->binary_payload, sizeof(values[i]));
> > + ret = ret
On 09/08/2019 14:58, Chris Wilson wrote:
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
Quoting Lionel Landwerlin (2019-08-09 13:38:57)
> On 09/08/2019 14:58, Chris Wilson wrote:
> > Not atomic (the u64 write should really be to avoid total corruption)
> > and nothing prevents userspace from racing. How safe is that in the
> > overall design?
>
>
> Atomic would prevent issue
https://bugs.freedesktop.org/show_bug.cgi?id=110865
--- Comment #14 from Alex Deucher ---
(In reply to Dieter Nützel from comment #13)
>
> Alex, is this the same problem?
No.
>
> GFX Clocks and Power:
> 300 MHz (MCLK)
> 300 MHz (SCLK)
Your mclk is going to a lower state when
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
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 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
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
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 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
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
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
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.
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
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
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:
Am Mittwoch, den 31.07.2019, 23:30 +0200 schrieb Christian Gmeiner:
> As seen at CodeAurora's linux-imx git repo in imx_4.19.35_1.0.0
> branch.
>
> Signed-off-by: Christian Gmeiner
Thanks, applied.
Regards,
Lucas
> ---
> drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 44 +--
>
Am Freitag, den 02.08.2019, 13:26 +0200 schrieb Christian Gmeiner:
> Changes in V2:
> - use indentation as suggested by Philipp Zabel.
>
> Signed-off-by: Christian Gmeiner
Thanks, applied.
Regards,
Lucas
> ---
> drivers/gpu/drm/etnaviv/etnaviv_perfmon.c | 4 ++--
> 1 file changed, 2
On Fri, 2019-08-09 at 14:04 +0200, Lucas Stach wrote:
> 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
On Fri, 2019-08-09 at 14:04 +0200, Lucas Stach wrote:
> 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
On 09/08/2019 14:44, Chris Wilson wrote:
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
On 09/08/2019 15:27, Koenig, Christian wrote:
Am 09.08.19 um 14:26 schrieb Lionel Landwerlin:
On 09/08/2019 14:44, Chris Wilson wrote:
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
---
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
https://bugs.freedesktop.org/show_bug.cgi?id=110258
--- Comment #12 from Alex Deucher ---
Fix is on it's way upstream:
https://cgit.freedesktop.org/drm/drm/commit/?h=drm-fixes=72cda9bb5e219aea0f2f62f56ae05198c59022a7
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111241
--- Comment #5 from Pierre-Eric Pelloux-Prayer
---
Created attachment 144994
--> https://bugs.freedesktop.org/attachment.cgi?id=144994=edit
nir version
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freedesktop.org/show_bug.cgi?id=111241
--- Comment #3 from Pierre-Eric Pelloux-Prayer
---
Here's my understanding of the issue.
This shader uses 2 passes:
- the first pass has BufferA as input and output and does:
if (first frame)
// init bufferA content
else
// do something
https://bugs.freedesktop.org/show_bug.cgi?id=111241
--- Comment #4 from Pierre-Eric Pelloux-Prayer
---
Created attachment 144993
--> https://bugs.freedesktop.org/attachment.cgi?id=144993=edit
tgsi version of the shader
--
You are receiving this mail because:
You are the assignee for the
Hi Laurent,
thanks for the review! Most of it seemed clear how to fix for the rest
i've put some questions below:
On Sat, Jul 27, 2019 at 05:47:00AM +0300, Laurent Pinchart wrote:
> Hello Guido,
>
> Thank you for the patch.
>
> On Wed, Jul 24, 2019 at 05:52:26PM +0200, Guido Günther wrote:
> >
Hi Bogdan.
This patch triggered a few general comments.
> --- a/drivers/gpu/drm/bridge/adv7511/Makefile
> +++ b/drivers/gpu/drm/bridge/adv7511/Makefile
> @@ -2,5 +2,5 @@
> adv7511-y := adv7511_drv.o
> adv7511-$(CONFIG_DRM_I2C_ADV7511_AUDIO) += adv7511_audio.o
>
The spsc_queue_peek function is accessing queue->head which belongs to
the consumer thread and shouldn't be accessed by the producer
This is fixing a rare race condition when destroying entities.
Signed-off-by: Christian König
---
drivers/gpu/drm/scheduler/sched_entity.c | 4 ++--
1 file
On Fri, Aug 9, 2019 at 6:45 AM Steven Price wrote:
>
> On 09/08/2019 04:01, Rob Herring wrote:
> [...]
> > I was worried too. It seems to be working pretty well though, but more
> > testing would be good. I don't think there are a lot of usecases that
> > use more AS than the h/w has (8 on T860),
1 - 100 of 166 matches
Mail list logo
