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
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
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
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
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
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
---
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
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
The pull request you sent on Fri, 9 Aug 2019 16:07:35 +0200:
> https://github.com/bzolnier/linux.git tags/fbdev-v5.3-rc4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ec4c99ad7bd23dd39ffb1381136cefa4bb632e31
Thank you!
--
Deet-doot-dot, I am a bot.
Hi,
On Thu, Aug 01, 2019 at 11:18:53AM +, Ville Baillie wrote:
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 20
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 1 +
> drivers/gpu/drm/mxsfb/mxsfb_out.c | 14 +++---
> 3 files changed, 28 insertions(+), 7 deletions(-)
>
>
Hi Sam,
On Fri, Aug 09, 2019 at 03:33:08PM +0200, Sam Ravnborg wrote:
> Hi Laurent.
>
> > > > +static int td043mtea1_disable(struct drm_panel *panel)
> > > > +{
> > > > + struct td043mtea1_device *lcd = to_td043mtea1_device(panel);
> > > > +
> > > > + if (!lcd->spi_suspended)
> > > >
>
> 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
Hi Wolfram,
On Fri, Aug 09, 2019 at 05:40:47PM +0200, Wolfram Sang wrote:
> 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
>
https://bugs.freedesktop.org/show_bug.cgi?id=110457
--- Comment #10 from Eugene Bright ---
The patch is on it's way
https://bugs.freedesktop.org/show_bug.cgi?id=110258#c12
--
You are receiving this mail because:
You are the assignee for the bug.___
https://bugs.freedesktop.org/show_bug.cgi?id=110258
--- Comment #13 from Eugene Bright ---
The patch works!
I've been able to apply it to the gentoo-sources-5.2.7.
Thank you very much for reply!
--
You are receiving this mail because:
You are the assignee for the
Hi Dave, Daniel,
Same request as earlier, but with the readq/writeq stuff resolved and 5.3-rc3
backmerged. diffstat trimmed for size.
The following changes since commit 41a5a2a8531f95d18bb4efddea581ccb469e8ee5:
drm/amd/display: init res_pool dccg_ref, dchub_ref with xtalin_freq
(2019-07-18
On Wed, Aug 07, 2019 at 07:30:23PM +0200, Sam Ravnborg wrote:
> Hi Sean.
>
> On Wed, Aug 07, 2019 at 12:28:04PM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > Fixes the following warnings:
> > ../drivers/gpu/drm/drm_connector.c:989: WARNING: Unexpected indentation.
> >
On Fri, Aug 9, 2019 at 4:36 PM Bartlomiej Zolnierkiewicz
wrote:
> On 8/9/19 1:43 PM, Arnd Bergmann wrote:
> >
> > That would have been ok as well, but having the addition here was
> > intentional and seems more logical to me as this is where the headers
> > get moved around.
> I see that this is
From: Daniele Ceraolo Spurio
If the aperture is not available in HW we can't use a ggtt slot and wc
copy, so fall back to regular kmap.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Abdiel Janulgue
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 19
Intended for upstream testing so that we can still exercise the LMEM
plumbing and !HAS_MAPPABLE_APERTURE paths. Smoke tested on Skull Canyon
device. This works by allocating an intel_memory_region for a reserved
portion of system memory, which we treat like LMEM. For the LMEMBAR we
steal the
From: Abdiel Janulgue
Add a new CPU mmap implementation that allows multiple fault handlers
that depends on the object's backing pages.
Note that we multiplex mmap_gtt and mmap_offset through the same ioctl,
and use the zero extending behaviour of drm to differentiate between
them, when we
From: Abdiel Janulgue
This enables us to store extra data within vma->vm_private_data and assign
the pagefault ops for each mmap instance.
We replace the core drm_gem_mmap implementation to overcome the limitation
in having only a single offset node per gem object, allowing us to have
multiple
From: Abdiel Janulgue
Returns the available memory region areas supported by the HW.
Signed-off-by: Abdiel Janulgue
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_query.c | 57 +++
include/uapi/drm/i915_drm.h | 39 +
2 files changed,
We are going want to able to move objects between different regions
like system memory and local memory. In the future everything should
be just another region.
Signed-off-by: Matthew Auld
Signed-off-by: Abdiel Janulgue
Signed-off-by: CQ Tang
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
Convert stolen memory over to a region object. Still leaves open the
question with what to do with pre-allocated objects...
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_region.c | 2 +-
drivers/gpu/drm/i915/gem/i915_gem_stolen.c |
From: Abdiel Janulgue
LMEM can be accessed by the CPU through a BAR. The mapping itself should
be 1:1.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 16
drivers/gpu/drm/i915/gem/i915_gem_lmem.h
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/selftests/huge_pages.c | 121 +-
1 file changed, 120 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
b/drivers/gpu/drm/i915/gem/selftests/huge_pages.c
index
Add LMEM support for the CPU reloc path. When doing relocations we have
both a GPU and CPU reloc path, as well as some debugging options to force a
particular path. The GPU reloc path is preferred when the object
is not currently idle, otherwise we use the CPU reloc path. Since we
can't kmap the
From: Daniele Ceraolo Spurio
We can't fence anything without aperture.
Signed-off-by: Daniele Ceraolo Spurio
Signed-off-by: Stuart Summers
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
We need to add support for pwrite'ing an LMEM object.
Signed-off-by: Matthew Auld
Signed-off-by: Steve Hampson
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 87
1 file changed, 87 insertions(+)
diff --git
We may be missing support for the mappable aperture on some platforms.
Signed-off-by: Matthew Auld
Cc: Daniele Ceraolo Spurio
---
.../drm/i915/gem/selftests/i915_gem_coherency.c| 5 -
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 3 +++
From: Abdiel Janulgue
This call will specify which memory region an object should be placed.
Note that changing the object's backing storage should be immediately
done after an object is created or if it's not yet in use, otherwise
this will fail on a busy object.
Signed-off-by: Abdiel
From: Michal Wajdeczko
HWS placement restrictions can't just rely on HAS_LLC flag.
Signed-off-by: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
From: Abdiel Janulgue
Fault handler to handle missing pages to be filled depending on an
object's backing storage. Handle also changes needed to refault pages
depending on fault handler usage.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
---
From: Abdiel Janulgue
If there is no aperture we can't use map_gtt to map dumb buffers, so we
need a cpu-map based path to do it. We prefer map_gtt on platforms that
do have aperture.
Signed-off-by: Abdiel Janulgue
Cc: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Matthew Auld
---
Use meson library instead of shared_library to enable static build.
Signed-off-by: Peter Seiderer
---
Changes v1 -> v2:
- no changes, resend (old submission [1])
[1] https://lists.freedesktop.org/archives/dri-devel/2018-July/183886.html
---
amdgpu/meson.build| 2 +-
etnaviv/meson.build
Use the stronger compiler.link() test (instead of the weaker
compiler.compile()) to fix the intel atomics detection.
Fixes false positive in case of sparc compile (buildroot toolchain).
Signed-off-by: Peter Seiderer
---
Changes v1 -> v2:
- no changes, resend (old submission [1])
[1]
Some toolchains (e.g. br-arm-cortex-m4-full) provide empty libdl
libraries. This fools the dynamic/static detection for tests/nouveau,
so explicit check for library type instead.
Fixes:
../tests/nouveau/threaded.c:24:10: fatal error: dlfcn.h: No such file or
directory
Signed-off-by: Peter
On Fri, Aug 09, 2019 at 10:15:51PM +0200, Sam Ravnborg wrote:
> Hi Sean.
>
> > > > --- a/include/drm/drm_connector.h
> > > > +++ b/include/drm/drm_connector.h
> > > > @@ -543,8 +543,8 @@ struct drm_connector_state {
> > > > *
> > > > * This is also used in the atomic helpers to
The ARM w90x900 platform is getting removed, so this driver is obsolete.
Signed-off-by: Arnd Bergmann
---
drivers/video/fbdev/Kconfig | 14 -
drivers/video/fbdev/Makefile | 1 -
drivers/video/fbdev/nuc900fb.c | 760 ---
On Fri, Aug 9, 2019 at 10:24 AM Guido Günther wrote:
>
> 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
Hi Sean.
> > > > > --- a/include/drm/drm_connector.h
> > > > > +++ b/include/drm/drm_connector.h
> > > > > @@ -543,8 +543,8 @@ struct drm_connector_state {
> > > > >*
> > > > >* This is also used in the atomic helpers to map encoders to
> > > > > their
> > > > >* current
Volatile objects are marked as DONTNEED while pinned, therefore once
unpinned the backing store can be discarded.
Signed-off-by: Matthew Auld
Signed-off-by: CQ Tang
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 17 +++---
Simple buddy allocator. We want to allocate properly aligned
power-of-two blocks to promote usage of huge-pages for the GTT, so 64K,
2M and possibly even 1G. While we do support allocating stuff at a
specific offset, it is more intended for preallocating portions of the
address space, say for an
From: Abdiel Janulgue
Exposes available regions for the platform. Shared memory will
always be available.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
drivers/gpu/drm/i915/intel_device_info.h | 2 ++
2 files changed, 4
Support basic eviction for regions.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 7 ++
drivers/gpu/drm/i915/gem/i915_gem_region.c| 11 +++
drivers/gpu/drm/i915/gem/i915_gem_region.h| 1 +
From: Abdiel Janulgue
Signed-off-by: Abdiel Janulgue
Cc: Matthew Auld
---
drivers/gpu/drm/i915/intel_region_lmem.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_region_lmem.c
b/drivers/gpu/drm/i915/intel_region_lmem.c
In preparation for upcoming devices with device local memory, introduce the
concept of different memory regions, and a simple buddy allocator to manage
them in i915.
One of the concerns raised from v1 was around not using enough of TTM, which is
a fair criticism, so trying to get better alignment
From: Abdiel Janulgue
We can create LMEM objects, but we also need to support mapping them
into kernel space for internal use.
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Signed-off-by: Steve Hampson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/gem/i915_gem_internal.c | 4
Support memory regions, as defined by a given (start, end), and allow
creating GEM objects which are backed by said region. The immediate goal
here is to have something to represent our device memory, but later on
we also want to represent every memory domain with a region, so stolen,
shmem, and
Some objects may need to be allocated as a continuous block, thinking
ahead the various kernel io_mapping interfaces seem to expect it.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 4 +
Currently we just pass in bcs0->engine_context so it matters not, but in
the future we may want to pass in something that is not a
kernel_context, so try to be a bit more generic.
Suggested-by: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_client_blt.c | 3 ++-
We currently define LMEM, or local memory, as just another memory
region, like system memory or stolen, which we can expose to userspace
and can be mapped to the CPU via some BAR.
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/Makefile
We can already clear an object with the blt, so try to do the same to
support copying from one object backing store to another. Really this is
just object -> object, which is not that useful yet, what we really want
is two backing stores, but that will require some vma rework first,
otherwise we
Reported-by: Chris Wilson
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 31 +++-
.../gpu/drm/i915/gem/i915_gem_object_blt.c| 139 ++
.../gpu/drm/i915/gem/i915_gem_object_blt.h| 9 +-
.../i915/gem/selftests/i915_gem_client_blt.c | 16
From: CQ Tang
Signed-off-by: CQ Tang
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2aa4fbe7edc0..af63d1a0af14 100644
---
Using the gpu to write to some dword over a number of pages is rather
useful, and we already have two copies of such a thing, and we don't
want a third so move it to utils. There is probably some other stuff
also...
Signed-off-by: Matthew Auld
---
.../gpu/drm/i915/gem/selftests/huge_pages.c |
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_phys.c | 6 +-
drivers/gpu/drm/i915/gem/i915_gem_region.c| 14 +++-
drivers/gpu/drm/i915/gem/i915_gem_shmem.c | 68 ++-
drivers/gpu/drm/i915/i915_drv.c
From: Daniele Ceraolo Spurio
The following patches in the series will use it to avoid certain
operations when aperture is not available in HW.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 2 ++
1 file changed, 2 insertions(+)
diff --git
We need to add support for pread'ing an LMEM object.
Signed-off-by: Matthew Auld
Signed-off-by: Steve Hampson
Cc: Joonas Lahtinen
Cc: Abdiel Janulgue
---
drivers/gpu/drm/i915/gem/i915_gem_lmem.c | 88 +++
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +
From: Daniele Ceraolo Spurio
Skip both setup and cleanup of the aperture mapping if the HW doesn't
have an aperture bar.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 36 ++---
1 file changed, 22 insertions(+), 14
From: Abdiel Janulgue
Nothing to enumerate yet...
Signed-off-by: Abdiel Janulgue
Signed-off-by: Matthew Auld
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.h | 3 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 70 +--
Simple test writing to dwords across an object, using various engines in
a randomized order, checking that our writes land from the cpu.
Signed-off-by: Matthew Auld
---
.../drm/i915/selftests/intel_memory_region.c | 179 ++
1 file changed, 179 insertions(+)
diff --git
Hi Sean.
> > > --- a/include/drm/drm_connector.h
> > > +++ b/include/drm/drm_connector.h
> > > @@ -543,8 +543,8 @@ struct drm_connector_state {
> > >*
> > >* This is also used in the atomic helpers to map encoders to their
> > >* current and previous connectors, see
> > > - *
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. ;)
> >
> > I'm only half on vacation :)
> >
> > So I can
On Fri, Aug 9, 2019 at 3:09 PM Alyssa Rosenzweig
wrote:
>
> While newer kbase include only the numbers of errata, older kbase
> releases included one-line descriptions for each errata, which is useful
> for those working on the driver. Import these descriptions. Most are
> from kbase verbatim; a
101 - 166 of 166 matches
Mail list logo
