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
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 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
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
---
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
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
---
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
---
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
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
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: 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
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
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
---
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
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 +
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
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
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
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
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 +
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
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
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
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 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
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
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 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
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.
> >
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
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
>
>
> 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 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)
> > > >
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,
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(-)
>
>
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 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:
> >
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
---
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 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
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
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 #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
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
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),
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
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
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
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
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
>
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=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
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
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/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
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
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
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
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
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
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
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,
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 ++
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
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
---
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
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
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
>>> +++
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 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
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
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 +--
>
1 - 100 of 166 matches
Mail list logo