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
neve
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 5
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)) {
+ panfrost_mmu_as_put(p
> @@ -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,
> &pfdev->jobs[j]->file_priv->mmu);
> panfrost_devfreq_recor
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 Fr
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
> Cc:
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 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 wi
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
> PANFROST_BO_
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 w
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
>> +++ b/arch/powerpc/m
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
> Signed-off-by
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 (a
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 Chri
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, Th
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, oth
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 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 chance
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 unconverted
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 to
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*() variants
https://bugs.freedesktop.org/show_bug.cgi?id=111332
Michel Dänzer changed:
What|Removed |Added
Component|DRM/AMDgpu |Drivers/Gallium/radeonsi
Pro
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
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
>
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.
> > Thi
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 in
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
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 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 int
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
>>> inst
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] [drm:evergree
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 th
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 li
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 informatio
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&D Institute Polan
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 ++
inclu
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 materi
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 files.
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/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 com
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 st
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 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 1
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 __use
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 a/drivers/gpu/drm/etnaviv/etnaviv_dump
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
--
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: Ph
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. A
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.
Sign
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 conte
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
fault
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
---
d
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
drivers/gp
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 s
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
dri-devel@lists.freedesktop
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 insertio
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 is
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 drm_syncobj_timeline
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 MM
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
>>> +++ b/inclu
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 drm_synco
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(&values[i],
> > &syncobjs[i]->binary_payload, sizeof(values[i]));
> > +
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 related
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
--- a/incl
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 t
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 materi
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 ++
include/uapi/drm/drm.
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, bu
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 bug.___
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&D Institute Poland
Samsung Electronic
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 in
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 a/Documentation/devicetre
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 ++---
drivers/gpu/drm/bridge/ad
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 par
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 impo
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
https://bugs.freedesktop.org/show_bug.cgi?id=111305
--- Comment #3 from Alex Deucher ---
(In reply to Paul Menzel from comment #2)
>
> Just to clarify, the VRAM on the external graphics device is powered off,
> correct?
Correct.
>
> Are there any tools to analyze these delays?
I guess profil
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&id=72cda9bb5e219aea0f2f62f56ae05198c59022a7
--
You are receiving this mail because:
You are the assignee for the bug.__
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
> adv7511-$(CONFIG_DRM_I2C_ADV7511
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 change
Store the timestamp of the current vblank in the new field 'time' of the
vblank trace event. If the timestamp is calculated by a driver that
supports high-precision vblank timing, set the field 'high-prec' to
'true'.
User space can now access actual hardware vblank times via the tracing
infrastruc
In the general move to have i2c_new_*_device functions which return
ERR_PTR instead of NULL, this patch converts i2c_new_secondary_device().
There are only few users, so this patch converts the I2C core and all
users in one go. The function gets renamed to i2c_new_ancillary_device()
so out-of-tree
Hi Laurent,
> > > > + if (IS_ERR(state->i2c_clients[i])) {
> > > > + err = PTR_ERR(state->i2c_clients[i]);
> > > > v4l2_err(sd, "failed to create i2c client
> > > > %u\n", i);
> > > > goto err_i2c;
>
> This will
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),
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&action=edit
tgsi version of the shader
--
You are receiving this mail because:
You are the assignee for t
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&action=edit
nir version
--
You are receiving this mail because:
You are the assignee for the bug.
This adds all the gpr registers and the define needed for selecting
the input source in the imx-nwl drm bridge.
Signed-off-by: Guido Günther
---
include/linux/mfd/syscon/imx8mq-iomuxc-gpr.h | 62
1 file changed, 62 insertions(+)
create mode 100644 include/linux/mfd/syscon/i
This adds initial support for the NWL MIPI DSI Host controller found on i.MX8
SoCs.
It adds support for the i.MX8MQ but the same IP core can also be found on e.g.
i.MX8QXP. I added the necessary hooks to support other imx8 variants but since
I only have imx8mq boards to test I omitted the platform
The Northwest Logic MIPI DSI IP core can be found in NXPs i.MX8 SoCs.
Signed-off-by: Guido Günther
---
.../bindings/display/bridge/nwl-dsi.yaml | 155 ++
1 file changed, 155 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/bridge/nwl-dsi.yaml
dif
This adds initial support for the NWL MIPI DSI Host controller found on
i.MX8 SoCs.
It adds support for the i.MX8MQ but the same IP can be found on
e.g. the i.MX8QXP.
It has been tested on the Librem 5 devkit using mxsfb.
Signed-off-by: Guido Günther
Co-developed-by: Robert Chiras
---
drivers
1 - 100 of 162 matches
Mail list logo