Den 18.06.2019 19.23, skrev Noralf Trønnes:
>
> Den 18.06.2019 18.35, skrev Laurent Pinchart:
>> Hi Noralf,
>>
>> On Tue, Jun 18, 2019 at 03:56:19PM +0200, Noralf Trønnes wrote:
>>> Den 18.06.2019 15.13, skrev Laurent Pinchart:
The recommended way to specify GEM object functions is to provi
coccicheck reported unneeded semicolons. Remove them.
Signed-off-by: Marko Kohtala
---
drivers/video/fbdev/ssd1307fb.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/ssd1307fb.c b/drivers/video/fbdev/ssd1307fb.c
index 6c2980331ffd..9ab00e0dadc7 10
The kernel driver for ssd1307fb did not allow for all proper
initialization for a Densitron 128x36 display. The trend in the driver
has been to add devicetree properties for the controller initialization
and these patches continue on that trend.
There also were some sparse and Coccinelle errors.
On (06/19/19 01:20), Ilia Mirkin wrote:
> On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> wrote:
> >
> > On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > > dmesg
> > >
> > > nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
> > > nouveau :01:00.0: fifo: SCHED_ERROR 0
On Sat, Jun 15, 2019 at 06:59:06AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 09:44:40PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > Ralph observes that hmm_range_register() can only be called by a driver
> > while a mirror is registered. Make this clear in the
On Mon, Jun 17, 2019 at 9:36 AM Krzysztof Kozlowski wrote:
>
> On Mon, Jun 17, 2019 at 09:15:23AM -0700, Joseph Kogut wrote:
> > Hi Krzysztof,
> >
> > Thanks for the review.
> >
> > On Sun, Jun 16, 2019 at 1:59 AM Krzysztof Kozlowski wrote:
> > >
> > > On Fri, Jun 14, 2019 at 04:57:19PM -0700, Jo
sparse reported incorrect type due to different address spaces.
The screen_base is __iomem, but the memory is not from a device so we can
use screen_buffer instead and avoid some type casts.
Signed-off-by: Marko Kohtala
---
drivers/video/fbdev/ssd1307fb.c | 10 +-
1 file changed, 5 inser
On Sat, Jun 15, 2019 at 07:12:11AM -0700, Christoph Hellwig wrote:
> > + spin_lock(&mm->page_table_lock);
> > + if (mm->hmm) {
> > + if (kref_get_unless_zero(&mm->hmm->kref)) {
> > + spin_unlock(&mm->page_table_lock);
> > + return mm->hmm;
> > +
Some displays have dimensions that are not multiple of eight, for example
height of 36, but the driver divided the dimensions by 8. Defining display
to the next multiple of 8 is not good as then the display registers get
configured to dimensions that do not match. This contradicts intructions
by so
The page_offset was only applied to the end of the page range. This caused
the display updates to cause a scrolling effect on the display because the
amount of data written to the display did not match the range display
expected.
Fixes: 301bc0675b67 ("video: ssd1307fb: Make use of horizontal addre
On (06/19/19 02:07), Ilia Mirkin wrote:
> On Wed, Jun 19, 2019 at 1:48 AM Sergey Senozhatsky
> wrote:
> >
> > On (06/19/19 01:20), Ilia Mirkin wrote:
> > > On Wed, Jun 19, 2019 at 1:08 AM Sergey Senozhatsky
> > > wrote:
> > > >
> > > > On (06/14/19 11:50), Sergey Senozhatsky wrote:
> > > > > dmes
On Sat, Jun 15, 2019 at 07:14:35AM -0700, Christoph Hellwig wrote:
> > mutex_lock(&hmm->lock);
> > - list_for_each_entry(range, &hmm->ranges, list)
> > - range->valid = false;
> > - wake_up_all(&hmm->wq);
> > + /*
> > +* Since hmm_range_register() holds the mmget() lock hmm_
On Thu, Jun 13, 2019 at 10:13:54PM -0700, Kees Cook wrote:
> On Thu, Jun 13, 2019 at 04:26:32PM +0100, Catalin Marinas wrote:
> > On Thu, Jun 13, 2019 at 12:02:35PM +0100, Dave P Martin wrote:
> > > On Wed, Jun 12, 2019 at 01:43:20PM +0200, Andrey Konovalov wrote:
> > > > +static int zero;
> > > >
On Sat, Jun 15, 2019 at 07:17:26AM -0700, Christoph Hellwig wrote:
> > - /* Sanity check this really should not happen. */
> > - if (hmm == NULL || range->end <= range->start)
> > - return;
> > -
> > mutex_lock(&hmm->lock);
> > list_del_rcu(&range->list);
> > mutex_unlock(
On (06/14/19 11:50), Sergey Senozhatsky wrote:
> dmesg
>
> nouveau :01:00.0: DRM: GPU lockup - switching to software fbcon
> nouveau :01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT]
> nouveau :01:00.0: fifo: runlist 0: scheduled for recovery
> nouveau :01:00.0: fifo: channel 5: k
On Sat, Jun 15, 2019 at 07:16:12AM -0700, Christoph Hellwig wrote:
> On Thu, Jun 13, 2019 at 09:44:46PM -0300, Jason Gunthorpe wrote:
> > From: Jason Gunthorpe
> >
> > No other register/unregister kernel API attempts to provide this kind of
> > protection as it is inherently racy, so just drop it
Document new bindings for adapting ssd1307fb driver to new displays.
Signed-off-by: Marko Kohtala
---
.../devicetree/bindings/display/ssd1307fb.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/ssd1307fb.txt
b/Documentation/de
On Tue, Jun 18, 2019 at 06:27:22AM -0700, Christoph Hellwig wrote:
> On Tue, Jun 18, 2019 at 10:13:24AM -0300, Jason Gunthorpe wrote:
> > > I don't even think we even need to bother with the POISON, normal list
> > > debugging will already catch a double unregistration anyway.
> >
> > mirror->hmm
Various displays have differences that only mean initializing the display
driver IC with different fixed register values. Defining these in
devicetree offers easier way to adapt the driver to new displays than
requiring a patch to the kernel.
This adds devicetree properties needed to make the init
On (06/19/19 15:27), Sergey Senozhatsky wrote:
> [..]
>
> > If all else fails, just remove nouveau_dri.so and/or boot with
> > nouveau.noaccel=1 -- should be perfect.
>
> Can give it a try.
That has some impact on system responsiveness:
CPU% COMM
339.7 firefox
Which is sli
Dave, Daniel
- The coherent memory changes including mm changes.
- Some vmwgfx debug fixes.
- Removal of vmwgfx legacy security checks.
The following changes since commit 561564bea3248293398dc32ec36da40fb71faed0:
Merge tag 'omapdrm-5.3' of
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/l
On Wed, 19 Jun 2019, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the drm tree got a conflict in:
>
> drivers/gpu/drm/i915/Makefile.header-test
>
> between commit:
>
> e846f0dc57f4 ("kbuild: add support for ensuring headers are self-contained")
>
> from the kbuild tree and
Warnings popup when "make ARCH=i386"
In file included from include/drm/drm_mm.h:49,
from include/drm/drm_vma_manager.h:26,
from include/drm/drm_gem.h:40,
from drivers/gpu/drm/arm/display/komeda/komeda_framebuffer.c:9:
drivers/gpu/drm/arm/display/k
On Wed, Jun 19, 2019 at 9:00 AM Noralf Trønnes wrote:
>
>
>
> Den 18.06.2019 19.23, skrev Noralf Trønnes:
> >
> > Den 18.06.2019 18.35, skrev Laurent Pinchart:
> >> Hi Noralf,
> >>
> >> On Tue, Jun 18, 2019 at 03:56:19PM +0200, Noralf Trønnes wrote:
> >>> Den 18.06.2019 15.13, skrev Laurent Pincha
On Tue, Jun 18, 2019 at 11:17:34PM -0300, Rodrigo Siqueira wrote:
> On 06/07, Daniel Vetter wrote:
> > The crc core code can cope with some late crc, the race is kinda
> > unavoidable. So no need to flush pending workers, they'll complete in
> > time.
> >
> > Signed-off-by: Daniel Vetter
> > Cc:
On Tue, Jun 18, 2019 at 11:07:50PM -0300, Rodrigo Siqueira wrote:
> For historical reason, the function drm_wait_vblank_ioctl always return
> -EINVAL if something gets wrong. This scenario limits the flexibility
> for the userspace make detailed verification of the problem and take
> some action. I
On Wed, Jun 19, 2019 at 09:48:56AM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 11:07:50PM -0300, Rodrigo Siqueira wrote:
> > For historical reason, the function drm_wait_vblank_ioctl always return
> > -EINVAL if something gets wrong. This scenario limits the flexibility
> > for the usersp
Hi Laurent,
Thank you for your feedback!
> From: linux-renesas-soc-ow...@vger.kernel.org
> On Behalf Of Laurent Pinchart
> Sent: 18 June 2019 17:44
> Subject: Re: [PATCH 1/3] dt-bindings: display: renesas: Add r8a774a1 support
>
> Hi Fabrizio,
>
> Thank you for the patch.
>
> On Tue, Jun 18,
I failed to spot this while compile-testing. Oops.
Reported-by: kbuild test robot
Fixes: 9e1467002630 ("fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct
calls")
Cc: Sam Ravnborg
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Daniel Thompson
Cc: Lee Jones
Cc: Jingoo Han
Cc: Bartlomiej Zoln
On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
> Those files belong to the driver-api guide. Add them to the
> driver-api book.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/ABI/removed/sysfs-class-rfkill | 2 +-
> Documentation/ABI/stable/sysfs-class-r
On Tue, Jun 18, 2019 at 11:20 AM Daniel Vetter wrote:
>
> Yes this is a bit a big patch, but since it's essentially a complete
> rewrite of all the prime docs I didn't see how to better split it up.
>
> Changes:
> - Consistently point to drm_gem_object_funcs as the preferred hooks,
> where appli
All callers pass no_wait = false.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 5 ++---
drivers/gpu/drm/virtio/virtgpu_gem.c | 4 ++--
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 4 ++--
3 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vi
Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
This also makes the ioctl run lockless.
v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 24 ++
Add struct and helper functions to manage an array of gem objects.
See added kernel docs for details.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_array_helper.h | 15 +
drivers/gpu/drm/drm_gem_array_helper.c | 76 ++
drivers/gpu/drm/Makefile
Use gem reservation helpers and direct reservation_object_* calls
instead of ttm.
v3: Also attach the array of gem objects to the virtio command buffer,
so we can drop the object references in the completion callback. Needed
because ttm fence helpers grab a reference for us, but gem helpers
don't
virtio-gpu basically needs a sg_table for the bo, to tell the host where
the backing pages for the object are. So the gem shmem helpers are a
perfect fit. Some drm_gem_object_funcs need thin wrappers to update the
host state, but otherwise the helpers handle everything just fine.
Once the fencin
Use gem reservation helpers and direct reservation_object_* calls
instead of ttm.
v3: Due to using the gem reservation object it is initialized and ready
for use before calling ttm_bo_init, so we can also drop the tricky fence
logic which checks whenever the command is in flight still. We can
sim
No users left.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 --
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 39 --
2 files changed, 42 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
inde
No users left.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h| 1 -
drivers/gpu/drm/virtio/virtgpu_object.c | 13 -
2 files changed, 14 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/vi
Call reservation_object_* directly instead
of using ttm_bo_{reserve,unreserve}.
v3: check for EINTR too.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/vi
With this gem and ttm will use the same reservation object,
so mixing and matching ttm / gem reservation helpers should
work fine.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_object.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --
No need to do the reservation dance,
we can just wait on the fence directly.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_plane.c | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_plane
Thin wrapper around virtio_gpu_object_create(),
but calling that directly works equally well.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
drivers/gpu/drm/virtio/virtgpu_gem.c | 23 ---
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 6 +++---
ttm increasingly gets into the way while hacking on virtio-gpu memory
management. It also overkill for what virtio-gpu needs. Lets get rid
of it.
v3:
- add gem array helpers.
- rework fencing.
cheers,
Gerd
Gerd Hoffmann (12):
drm: add gem array helpers
drm/virtio: pass gem reservation
On Tue, Jun 18, 2019 at 10:55 PM Mauro Carvalho Chehab
wrote:
> diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> index fa30dfcfc3c8..b0f948d8733b 100644
> --- a/Documentation/gpu/drm-mm.rst
> +++ b/Documentation/gpu/drm-mm.rst
> @@ -320,7 +320,7 @@ struct :c:type:`struct
Hi Matthias,
On 13/6/19 21:43, Matthias Kaehlcke wrote:
> For backlight curves calculated with the CIE 1931 algorithm set
> the brightness scale type property accordingly. This makes the
> scale type available to userspace via the 'scale' sysfs attribute.
>
> Signed-off-by: Matthias Kaehlcke
Te
On 6/18/19 21:05, Krzysztof Kozlowski wrote:
> Add ID and gate for bus clock for GPU (Mali 400) on Exynos4412.
Patch applied to clk/samsung tree, thanks.
Sets color_depth according to connector->bpc.
Adds a new optional DT attribute "color-format" to represent a
preferred color formats for a specific pipeline, and the select order
is:
YCRCB420 > YCRCB422 > YCRCB444 > RGB444
The color-format can be anyone of these 4 format, one color-format n
Hi Robert,
thank you for the patch.
On Tue, 2019-06-18 at 16:50 +0100, Robert Beckett wrote:
> Notify drm core before sending pending events during crtc disable.
> This fixes the first event after disable having an old stale timestamp
> by having drm_crtc_vblank_off update the timestamp to now.
>
Hello Sean Paul,
The patch 1452c25b0e60: "drm: Add helpers to kick off self refresh
mode in drivers" from Jun 12, 2019, leads to the following static
checker warning:
drivers/gpu/drm/drm_self_refresh_helper.c:118
drm_self_refresh_helper_entry_work()
error: we previously assumed '
On Wed, Jun 19, 2019 at 12:39:37PM +0300, Dan Carpenter wrote:
> 72 int i, ret;
> 73
> 74 drm_modeset_acquire_init(&ctx, 0);
> 75
> 76 state = drm_atomic_state_alloc(dev);
> 77 if (!state) {
> 78 ret = -ENOMEM;
>
Op 19-06-2019 om 10:11 schreef Daniel Vetter:
> I failed to spot this while compile-testing. Oops.
>
> Reported-by: kbuild test robot
> Fixes: 9e1467002630 ("fbcon: replace FB_EVENT_MODE_CHANGE/_ALL with direct
> calls")
> Cc: Sam Ravnborg
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Dani
On Wed, Jun 19, 2019 at 11:04:15AM +0200, Gerd Hoffmann wrote:
> Call reservation_object_* directly instead
> of using ttm_bo_{reserve,unreserve}.
>
> v3: check for EINTR too.
>
> Signed-off-by: Gerd Hoffmann
> Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 6 +++---
Hi Krzysztof,
On 2019-06-18 21:05, Krzysztof Kozlowski wrote:
> Add vendor compatibles for specific implementation of Mali Utgard
> (Exynos3250, Exynos4-family) and Midgard (Exynos5433, Exynos7).
>
> Signed-off-by: Krzysztof Kozlowski
> ---
> Documentation/devicetree/bindings/gpu/arm,mali-midga
This test is flipped around so it either leads to a memory leak or a
NULL dereference.
Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in
drivers")
Signed-off-by: Dan Carpenter
---
I'm not totally sure what the prefered patch prefix for this code. One
thing that would help
On Wed, 19 Jun 2019 at 12:01, Marek Szyprowski wrote:
>
> Hi Krzysztof,
>
> On 2019-06-18 21:05, Krzysztof Kozlowski wrote:
> > Add vendor compatibles for specific implementation of Mali Utgard
> > (Exynos3250, Exynos4-family) and Midgard (Exynos5433, Exynos7).
> >
> > Signed-off-by: Krzysztof Koz
On Fri, Jun 14, 2019 at 10:35:23PM +0200, Daniel Vetter wrote:
> Read the docs, komeda is not an old enough driver for this :-)
>
> Signed-off-by: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
Acked-by: Liviu Dudau
I'm assuming the whole series goes through drm-misc and I don't n
On Fri, Jun 14, 2019 at 10:35:27PM +0200, Daniel Vetter wrote:
> They're the default.
>
> Aside: Would be really nice to switch the others over to
> drm_gem_object_funcs.
>
> Signed-off-by: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Brian Starkey
Acked-by: Liviu Dudau
On Tue, Jun 18, 2019 at 07:47:04PM +0200, Noralf Trønnes wrote:
> > diff --git a/Documentation/fb/modedb.rst b/Documentation/fb/modedb.rst
> > index 3c2397293977..3e8a6f79dcd7 100644
> > --- a/Documentation/fb/modedb.rst
> > +++ b/Documentation/fb/modedb.rst
> > @@ -53,6 +53,17 @@ Specifying the op
Hi Krzysztof,
On 2019-06-19 12:08, Krzysztof Kozlowski wrote:
> On Wed, 19 Jun 2019 at 12:01, Marek Szyprowski
> wrote:
>> Hi Krzysztof,
>>
>> On 2019-06-18 21:05, Krzysztof Kozlowski wrote:
>>> Add vendor compatibles for specific implementation of Mali Utgard
>>> (Exynos3250, Exynos4-family) an
On Tue, Jun 18, 2019 at 11:20:37AM +0200, Daniel Vetter wrote:
> Reorder all the functions in drm_prime.[hc] into three groups: core,
> export helpers, import helpers.
>
> Not other changes beyond moving the functions and their unchanged
> kerneldoc around in here.
>
> Cc: Sam Ravnborg
> Cc: Eri
Hi,
> - Polish for all the functions and more cross references.
That is nice, helps figurung how all this works together without wading
through the source code (or at least less of it).
For that kind of changes it is probably helpful for review to generate
the diff with more context (say --uni
On Wed, Jun 19, 2019 at 08:42:45AM +0100, james qian wang (Arm Technology
China) wrote:
> Warnings popup when "make ARCH=i386"
>
> In file included from include/drm/drm_mm.h:49,
> from include/drm/drm_vma_manager.h:26,
> from include/drm/drm_gem.h:40,
>
Hi Daniel,
Em Wed, 19 Jun 2019 11:05:57 +0200
Daniel Vetter escreveu:
> On Tue, Jun 18, 2019 at 10:55 PM Mauro Carvalho Chehab
> wrote:
> > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
> > index fa30dfcfc3c8..b0f948d8733b 100644
> > --- a/Documentation/gpu/drm-mm.rst
On Tue, Jun 18, 2019 at 10:32:08PM -0400, Brian Masney wrote:
> +++ b/include/soc/qcom/ocmem.h
> @@ -0,0 +1,62 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * The On Chip Memory (OCMEM) allocator allows various clients to allocate
> + * memory from OCMEM based on performance, latency
Hi Gerd,
On 2019/06/19, Gerd Hoffmann wrote:
> +/**
> + * drm_gem_array_from_handles -- lookup an array of gem handles.
> + *
> + * @drm_file: drm file-private structure to use for the handle look up
> + * @handles: the array of handles to lookup.
> + * @nents: the numer of handles.
> + *
> + * R
Hi Gerd,
On 2019/06/19, Gerd Hoffmann wrote:
> -static void virtio_gpu_init_ttm_placement(struct virtio_gpu_object *vgbo)
> +static const struct drm_gem_object_funcs v3d_gem_funcs = {
s/v3d/virtio/g
Doubt I'll have the time for a proper review - just this and the 1/12 nits :-\
HTH
Emil
On Wed, Jun 19, 2019 at 07:22:18AM -0300, Mauro Carvalho Chehab wrote:
> Hi Daniel,
>
> Em Wed, 19 Jun 2019 11:05:57 +0200
> Daniel Vetter escreveu:
>
> > On Tue, Jun 18, 2019 at 10:55 PM Mauro Carvalho Chehab
> > wrote:
> > > diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm
On 2019/06/18, Daniel Vetter wrote:
> Reorder all the functions in drm_prime.[hc] into three groups: core,
> export helpers, import helpers.
>
> Not other changes beyond moving the functions and their unchanged
> kerneldoc around in here.
>
> Cc: Sam Ravnborg
> Cc: Eric Anholt
> Cc: Emil Veliko
On 2019/06/18, Daniel Vetter wrote:
> Yes this is a bit a big patch, but since it's essentially a complete
> rewrite of all the prime docs I didn't see how to better split it up.
>
> Changes:
> - Consistently point to drm_gem_object_funcs as the preferred hooks,
> where applicable.
>
> - Docume
On Wed, Jun 19, 2019 at 11:04:09AM +0200, Gerd Hoffmann wrote:
> Add struct and helper functions to manage an array of gem objects.
> See added kernel docs for details.
>
> Signed-off-by: Gerd Hoffmann
Hm, feels like jumping ahead here, I think there's too much still
in-flight:
- Christian is po
On Wed, Jun 19, 2019 at 11:04:14AM +0200, Gerd Hoffmann wrote:
> All callers pass no_wait = false.
>
> Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 5 ++---
> drivers/gpu/drm/virtio/virtgpu_gem.c | 4 ++--
> drivers/gpu/drm/virtio/
On Thu, Jun 13, 2019 at 12:43:23PM -0700, Matthias Kaehlcke wrote:
> Add an entry for the stable backlight sysfs ABI to the MAINTAINERS
> file.
>
> Signed-off-by: Matthias Kaehlcke
Well spotted. Thanks!
Acked-by: Daniel Thompson
Daniel.
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insert
On Wed, Jun 19, 2019 at 11:04:16AM +0200, Gerd Hoffmann wrote:
> Use gem reservation helpers and direct reservation_object_* calls
> instead of ttm.
>
> v3: Also attach the array of gem objects to the virtio command buffer,
> so we can drop the object references in the completion callback. Needed
Hi,
> > > Second one is drm_driver->fops->mmap. That one we need to keep, but this
> > > isn't mmap on a buffer, but mmap on the entire drm_device. The one which
> > > should be replaced by drm_gem_object_funcs.vm_ops is
> > > drm_driver->gem_vm_ops.
> >
> > Hmm, seems ttm hasn't something I can
> > +struct drm_gem_object_array*
> > +drm_gem_array_from_handles(struct drm_file *drm_file, u32 *handles, u32
> > nents)
> > +{
> > + struct drm_gem_object_array *objs;
> > + u32 i;
> > +
> > + objs = drm_gem_array_alloc(nents);
> > + if (!objs)
> > + return NULL;
> > +
> > +
On Wed, Jun 19, 2019 at 1:21 PM Gerd Hoffmann wrote:
>
> Hi,
>
> > > > Second one is drm_driver->fops->mmap. That one we need to keep, but this
> > > > isn't mmap on a buffer, but mmap on the entire drm_device. The one which
> > > > should be replaced by drm_gem_object_funcs.vm_ops is
> > > > dr
Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.
This was seen while debugging weston log message:
Warning: computed repaint delay is insane: -8212 ms
On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
> .../{ => driver-api}/atomic_bitops.rst| 2 -
That's a .txt file, big fat NAK for making it an rst.
> .../{ => driver-api}/futex-requeue-pi.rst | 2 -
> .../{ => driver-api}/gcc-plugins.rst | 2 -
>
https://bugs.freedesktop.org/show_bug.cgi?id=109456
--- Comment #6 from libgra...@gmail.com ---
Updated to QEMU 4.0.0 and re-tested - same result.
Let me know if you would like anything further info.
Thanks!
--
You are receiving this mail because:
You are the assignee for the bug._
On Wed, Jun 19, 2019 at 01:43:56PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
>
> > .../{ => driver-api}/atomic_bitops.rst| 2 -
>
> That's a .txt file, big fat NAK for making it an rst.
Also, how many bloody times do I have to
On Tue, Jun 18, 2019 at 8:12 PM Daniel Vetter wrote:
>
> On Tue, Jun 18, 2019 at 07:48:06PM +0800, Cheng-yi Chiang wrote:
> > On Tue, Jun 11, 2019 at 8:35 PM Daniel Vetter wrote:
> > >
> > > On Tue, Jun 11, 2019 at 08:10:38PM +0800, Cheng-yi Chiang wrote:
> > > > On Tue, Jun 4, 2019 at 3:24 PM Da
On Wed, Jun 19, 2019 at 01:45:51PM +0200, Peter Zijlstra wrote:
> On Wed, Jun 19, 2019 at 01:43:56PM +0200, Peter Zijlstra wrote:
> > On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > .../{ => driver-api}/atomic_bitops.rst| 2 -
> >
> > That's a .txt file,
On Wed, 2019-06-19 at 12:41 +0100, Robert Beckett wrote:
> Notify drm core before sending pending events during crtc disable.
> This fixes the first event after disable having an old stale timestamp
> by having drm_crtc_vblank_off update the timestamp to now.
>
> This was seen while debugging west
Den 18.06.2019 11.20, skrev Daniel Vetter:
> Reorder all the functions in drm_prime.[hc] into three groups: core,
> export helpers, import helpers.
>
> Not other changes beyond moving the functions and their unchanged
> kerneldoc around in here.
>
> Cc: Sam Ravnborg
> Cc: Eric Anholt
> Cc: Em
On Wed, Jun 12, 2019 at 10:49:52AM +0200, Paul Cercueil wrote:
>
>
> Le mar. 11 juin 2019 à 23:55, Rob Herring a écrit :
> > On Mon, 3 Jun 2019 17:23:30 +0200, Paul Cercueil wrote:
> > > Add documentation for the devicetree bindings of the LCD controller
> > > present in
> > > the JZ47xx fami
Hi Paul.
On Mon, Jun 03, 2019 at 05:23:31PM +0200, Paul Cercueil wrote:
> Add a KMS driver for the Ingenic JZ47xx family of SoCs.
> This driver is meant to replace the aging jz4740-fb driver.
>
> This driver does not make use of the simple pipe helper, for the reason
> that it will soon be update
On Mon, Jun 03, 2019 at 05:25:54PM +0200, Paul Cercueil wrote:
> The KD035G6-54NT is a 3.5" 320x240 24-bit TFT LCD panel.
>
> Signed-off-by: Paul Cercueil
Reviewed-by: Sam Ravnborg
Rob - ping for review.
Sam
> ---
>
> Notes:
> v2: - Add an address to the panel node
> - Add
ongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-2019-06-19
for you to fetch changes up to 1ee008f240ad5401f683ec3b79a2e3b044a82a89:
drm/i915: Update DRIVER_DATE to 20190619 (2019-06-19 15:32:25 +0300)
Features:
- HDR s
Den 18.06.2019 11.20, skrev Daniel Vetter:
> Yes this is a bit a big patch, but since it's essentially a complete
> rewrite of all the prime docs I didn't see how to better split it up.
>
> Changes:
> - Consistently point to drm_gem_object_funcs as the preferred hooks,
> where applicable.
>
>
https://bugs.freedesktop.org/show_bug.cgi?id=109456
--- Comment #7 from Alex Williamson ---
Can you test this QEMU patch that's already in qemu.git for 4.1:
https://git.qemu.org/?p=qemu.git;a=commitdiff;h=3412d8ec9810b819f8b79e8e0c6b87217c876e32
Alternatively, setting the pci-hole64-size=0 can
Em Wed, 19 Jun 2019 12:42:39 +0200
Peter Zijlstra escreveu:
> On Wed, Jun 19, 2019 at 07:22:18AM -0300, Mauro Carvalho Chehab wrote:
> > Hi Daniel,
> >
> > Em Wed, 19 Jun 2019 11:05:57 +0200
> > Daniel Vetter escreveu:
> >
> > > On Tue, Jun 18, 2019 at 10:55 PM Mauro Carvalho Chehab
> > > w
https://bugs.freedesktop.org/show_bug.cgi?id=110702
--- Comment #9 from Pierre-Eric Pelloux-Prayer
---
Thanks, I could reproduce on a Raven setup using the files from comment 7 and
8.
The driver fails when trying to allocate a buffer for this video with a ENOMEM
error (the requested size is 3 G
Hi Robert.
Thanks for the contribution.
On Tue, Jun 18, 2019 at 04:30:45PM +0300, Robert Chiras wrote:
> Add dt-bindings documentation for Raydium RM67191 DSI panel.
>
> Signed-off-by: Robert Chiras
> ---
> .../bindings/display/panel/raydium,rm67191.txt | 43
> ++
> 1
https://bugs.freedesktop.org/show_bug.cgi?id=110702
--- Comment #10 from Christian König ---
(In reply to Pierre-Eric Pelloux-Prayer from comment #9)
> The driver fails when trying to allocate a buffer for this video with a
> ENOMEM error (the requested size is 3 GB).
Well that strongly sounds l
On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > -Original Message-
> > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf
> > Of
> > Ezequiel Garcia
> > Sent: Friday, June 14, 2019 9:48 PM
> > To: Shankar, Uma
> > Cc: Emil Velikov ;
> > intel-...@lists.
Hi Robert,
On Tue, Jun 18, 2019 at 10:33 AM Robert Chiras wrote:
> +Optional properties:
> +- reset-gpios: a GPIO spec for the RST_B GPIO pin
> +- pinctrl-0phandle to the pin settings for the reset pin
> +- width-mm:physical panel width [mm]
> +- height-mm:
https://bugs.freedesktop.org/show_bug.cgi?id=110949
Bug ID: 110949
Summary: Continuious warnings from agd5f 5.3-wip branch
Product: DRI
Version: XOrg git
Hardware: Other
OS: All
Status: NEW
Severity: norma
On Tue, Jun 18, 2019 at 04:30:46PM +0300, Robert Chiras wrote:
> This patch adds Raydium RM67191 TFT LCD panel driver (MIPI-DSI
> protocol).
>
> Signed-off-by: Robert Chiras
Please include in the changelog a list of what was updated - like this:
v2:
- added kconif symbol sorted (sam)
- another n
Hi Robert,
On Tue, Jun 18, 2019 at 10:31 AM Robert Chiras wrote:
> +static const struct display_timing rad_default_timing = {
> + .pixelclock = { 6600, 13200, 13200 },
> + .hactive = { 1080, 1080, 1080 },
> + .hfront_porch = { 20, 20, 20 },
> + .hsync_len = {
1 - 100 of 187 matches
Mail list logo
