Hi Rob.
Thanks for starting the conversion of panel bindings to yaml.
On Wed, Jun 19, 2019 at 03:51:53PM -0600, Rob Herring wrote:
> Convert the common panel bindings to DT schema consolidating scattered
> definitions to a single schema file.
>
> The 'simple-panel' binding just a collection of p
On Thu, 20 Jun 2019 at 02:55, Qiang Yu wrote:
>
> It looks like lima_clk_init will have the same problem if devm_clk_get
> returns -EPROBE_DEFER.
Indeed, although I did not experience it but it is valid point. I'll send v2.
Best regards,
Krzysztof
___
drm_gem_object_funcs->vm_ops alone can't handle
everything mmap() needs. Add a new callback for it.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem.h | 9 +
drivers/gpu/drm/drm_gem.c | 4
2 files changed, 13 insertions(+)
diff --git a/include/drm/drm_gem.h b/include/drm/d
Add a new callback where drivers can handle mmap setup
without having to override gem_driver->fops->mmap.
Switch shmem helper over as demo.
cheers,
Gerd
Gerd Hoffmann (3):
drm: add mmap() to drm_gem_object_funcs
drm: switch shmem helper to drm_gem_object_funcs->mmap
drm: drop DEFINE_DRM_
Switch gem shmem helper from gem_driver->fops->mmap to
drm_gem_object_funcs->mmap.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_shmem_helper.h | 4 ++--
drivers/gpu/drm/drm_gem_shmem_helper.c | 18 +++---
drivers/gpu/drm/panfrost/panfrost_gem.c | 1 +
drivers/gpu/drm/
DEFINE_DRM_GEM_SHMEM_FOPS is identical to DEFINE_DRM_GEM_FOPS now,
drop it.
Signed-off-by: Gerd Hoffmann
---
include/drm/drm_gem_shmem_helper.h | 26 -
drivers/gpu/drm/cirrus/cirrus.c | 2 +-
drivers/gpu/drm/panfrost/panfrost_drv.c | 2 +-
drivers/gpu/drm/v
Thin wrapper around virtio_gpu_object_create(),
but calling that directly works equally well.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4
drivers/gpu/drm/virtio/virtgpu_gem.c | 23 ---
drivers/gpu/drm/virtio/vi
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 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 ++
Call reservation_object_* directly instead
of using ttm_bo_{reserve,unreserve}.
v4: check for EINTR only.
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
No users left.
Signed-off-by: Gerd Hoffmann
Acked-by: Daniel Vetter
---
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/
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/virtgpu_ioctl.c | 4 ++--
3 files changed, 6 insertions(+), 7 deletions(-)
dif
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 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
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 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
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.
v4:
- make gem array helpers private to virtio.
- misc minor fixes.
v3:
- add gem array helpers.
- rework fencing.
cheers,
Gerd
Gerd Hoffmann
Some helper functions to manage an array of gem objects.
v4: make them virtio-private instead of generic helpers.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 10 ++
drivers/gpu/drm/virtio/virtgpu_gem.c | 50
2 files changed, 60 insert
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
Hi,
> Also, I strongly recommend you do a very basic igt to exercise this, i.e.
> allocate some buffers, submit them in a dummby op, then close the entire
> drmfd. The old version should at least have tripped over kasan, maybe even
> oopses somewhere.
Hmm, I suspect I have to extend igt for tha
On Mon, 17 Jun 2019 at 16:56, Rob Herring wrote:
>
> On Sun, Jun 16, 2019 at 11:15 PM Tomeu Vizoso
> wrote:
> >
> > On Fri, 14 Jun 2019 at 23:22, Rob Herring wrote:
> > >
> > > On Wed, Jun 12, 2019 at 6:55 AM Tomeu Vizoso
> > > wrote:
> > > >
> > > > On Mon, 10 Jun 2019 at 19:06, Rob Herring
On Thu, 2019-06-20 at 11:14 +1000, Alastair D'Silva wrote:
> On Wed, 2019-06-19 at 17:35 -0700, Joe Perches wrote:
> > On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
> > > On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> > > > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva w
https://bugs.freedesktop.org/show_bug.cgi?id=96838
--- Comment #1 from Michael Silver ---
I can confirm this on a Dell PowerEdge 2800 running Ubuntu 18.04.
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing
Hi Brendan,
I am only responding to this because you asked me to in the v4 thread.
Thank you for evaluating my comments in the v4 thread and asking me to
comment on v5
On 6/17/19 1:25 AM, Brendan Higgins wrote:
> ## TL;DR
>
> A not so quick follow-up to Stephen's suggestions on PATCH v4. Nothin
It looks like lima_clk_init will have the same problem if devm_clk_get
returns -EPROBE_DEFER.
Regards,
Qiang
On Wed, Jun 19, 2019 at 2:55 AM Krzysztof Kozlowski wrote:
>
> There is no point to print deferred probe (and its failures to get
> resources) as an error. For example getting a regulato
Looks good for me, patch is:
Reviewed-by: Qiang Yu
I'll apply it to drm-misc-next.
Regards,
Qiang
On Wed, Jun 19, 2019 at 2:55 AM Krzysztof Kozlowski wrote:
>
> Mark long numbers with ULL to silence the Smatch warning:
>
> drivers/gpu/drm/lima/lima_device.c:314:32: warning: constant 0x1000
On Thu, 2019-06-20 at 09:15 +1000, Alastair D'Silva wrote:
> On Wed, 2019-06-19 at 09:31 -0700, Joe Perches wrote:
> > On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> > > From: Alastair D'Silva
> > >
> > > Apologies for the large CC list, it's a heads up for those
> > > responsible
>
Quoting Brendan Higgins (2019-06-17 01:25:56)
> diff --git a/kunit/test.c b/kunit/test.c
> new file mode 100644
> index 0..d05d254f1521f
> --- /dev/null
> +++ b/kunit/test.c
> @@ -0,0 +1,210 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Base unit test (KUnit) API.
> + *
> + * Co
The hardware supports either size. Also add checks to ensure that only
these two sizes may be used for supplying a LUT.
Finally, experimental evidence suggests you can't mix sizes for degamma
and gamma. Disallow this as well.
Signed-off-by: Ilia Mirkin
---
Note that all the gv100+ changes are p
Convert the common panel bindings to DT schema consolidating scattered
definitions to a single schema file.
The 'simple-panel' binding just a collection of properties and not a
complete binding itself. All of the 'simple-panel' properties are
covered by the panel-common.txt binding with the except
Convert the ampire,am-480272h3tmqw-t01h panel binding to DT schema.
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maxime Ripard
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring
---
.../panel/ampire,am-480272h3tmqw-t01h.txt | 26
.../panel/ampire,
Convert the panel-lvds binding to use DT schema. The panel-lvds schema
inherits from the panel-common.yaml schema and specific LVDS panel
bindings should inherit from this schema.
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maxime Ripard
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Sig
Convert the innolux,ee101ia-01 LVDS panel binding to DT schema.
Cc: Thierry Reding
Cc: Sam Ravnborg
Cc: Maxime Ripard
Cc: Laurent Pinchart
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Rob Herring
---
.../display/panel/innolux,ee101ia-01d.txt | 7 ---
.../display/panel/innolux,
Hi,
On Wed, Jun 12, 2019 at 1:51 AM Neil Armstrong wrote:
>
> When using an I2S source using a different clock source (usually the I2S
> audio HW uses dedicated PLLs, different from the HDMI PHY PLL), fixed
> CTS values will cause some frequent audio drop-out and glitches as
> reported on Amlogic
On Wed, Jun 19, 2019 at 10:42 PM Jason Gunthorpe wrote:
>
> On Wed, Jun 19, 2019 at 10:18:43PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 10:13 PM Jason Gunthorpe wrote:
> > > On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> > > > On Wed, Jun 19, 2019 at 6:50 PM Jason
Hi,
On Wed, Jun 19, 2019 at 8:23 AM Neil Armstrong wrote:
>
> On 18/06/2019 19:23, Jernej Škrabec wrote:
> > Hi!
> >
> > Dne torek, 18. junij 2019 ob 01:55:58 CEST je Douglas Anderson napisal(a):
> >> Let's add some better support for HDMI audio to dw_hdmi.
> >> Specifically:
> >>
> >> 1. For 44.
On some platforms using dw_hdmi it may not be possible to make an HDMI
pixel clock exactly, but it may be possible to make a rate that is
close enough to be within spec. For instance on rk3288 we can make
25,176,471 Hz instead of 25,174,825.1748... Hz (25.2 MHz / 1.001). A
future patch to the rk3
Let's add some better support for HDMI audio to dw_hdmi.
Specifically:
1. For 44.1 kHz audio the old code made the assumption that an N of
6272 was right most of the time. That wasn't true and the new table
should pick a more ideal value.
2. The new table has values from the HDMI spec for 297 MH
On Wed, Jun 19, 2019 at 10:18:43PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 10:13 PM Jason Gunthorpe wrote:
> > On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> > > On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe wrote:
> > > > On Tue, Jun 18, 2019 at 05:22:15PM +0200
On Wed, Jun 19, 2019 at 1:17 PM Rob Herring wrote:
>
> On Sun, Jun 16, 2019 at 7:29 AM Brian Masney wrote:
> >
> > Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> > must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> > optional ocmem property to the
On Wed, Jun 19, 2019 at 10:13 PM Jason Gunthorpe wrote:
> On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> > On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe wrote:
> > > On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > > > On Tue, May 21, 2019 at 11:44:11AM -0400
On Wed, 19 Jun 2019, Daniel Vetter wrote:
> - figure out what to do with the libdrm manpages. Some stuff we really
> want to also document there. But geez nroff. Maybe we need to stuff
> libdrm into the kernel, dunno.
How would people feel about converting libdrm man pages to rst, and
using rst2m
On Sun, Jun 16, 2019 at 7:29 AM Brian Masney wrote:
>
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
>
> Signed-off-by: Bri
On Wed, Jun 19, 2019 at 09:57:15PM +0200, Daniel Vetter wrote:
> On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe wrote:
> > On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > > On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > > > On Mon, May 20, 2019 at 11:39:42PM
On Wed, Jun 19, 2019 at 6:50 PM Jason Gunthorpe wrote:
> On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> > On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > > On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > > > Just a bit of paranoia, since if w
On Wed, Jun 19, 2019 at 9:36 PM Simon Ser wrote:
>
> Hi all,
>
> With Wayland compositors and DRM leases, the number of DRM userspace
> programs has increased (and will probably continue to increase).
> However it's been pretty hard to find good DRM docs for userspace.
>
> The resources currently
On Wed, Jun 19, 2019 at 12:42 PM Jason Gunthorpe wrote:
>
> On Thu, Jun 13, 2019 at 06:23:04PM -0700, John Hubbard wrote:
> > On 6/13/19 5:43 PM, Ira Weiny wrote:
> > > On Thu, Jun 13, 2019 at 07:58:29PM +, Jason Gunthorpe wrote:
> > >> On Thu, Jun 13, 2019 at 12:53:02PM -0700, Ralph Campbell
Hi all,
With Wayland compositors and DRM leases, the number of DRM userspace
programs has increased (and will probably continue to increase).
However it's been pretty hard to find good DRM docs for userspace.
The resources currently available are:
- The kernel docs, although only the high level
On Wed, Jun 19, 2019 at 12:32 PM Sean Paul wrote:
>
> On Wed, Jun 19, 2019 at 12:17:23PM -0700, Nathan Chancellor wrote:
> > Clang warns:
> >
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> > only applied to the left hand side of this bitwise operator
> > [-Wlogical-
On Wed, Jun 19, 2019 at 12:17:23PM -0700, Nathan Chancellor wrote:
> Clang warns:
>
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> only applied to the left hand side of this bitwise operator
> [-Wlogical-not-parentheses]
> if (!phy->cfg->quirks & V3_0_0_10NM_O
Hey team,
2 fixes this week, the 5.2 trickle continues.
drm-misc-fixes-2019-06-19:
panfrost- Only unmap BO's if they're mapped (Boris)
core- Handle buffer desc copy_to_user failure properly (Dan)
Cc: Boris Brezillon
Cc: Dan Carpenter
Cheers, Sean
The following changes since commit 48eaeb76
Clang warns:
drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
only applied to the left hand side of this bitwise operator
[-Wlogical-not-parentheses]
if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMINGS_QUIRK) {
^ ~
drivers/gpu/drm/msm/dsi/phy
On Wed, Jun 19, 2019 at 03:13:40PM -0400, Sean Paul wrote:
> On Wed, Jun 19, 2019 at 12:19 PM Nathan Chancellor
> wrote:
> >
> > Clang warns:
> >
> > drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> > only applied to the left hand side of this bitwise operator
> > [-Wlogi
On Wed, Jun 19, 2019 at 12:19 PM Nathan Chancellor
wrote:
>
> Clang warns:
>
> drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c:80:6: warning: logical not is
> only applied to the left hand side of this bitwise operator
> [-Wlogical-not-parentheses]
> if (!phy->cfg->quirks & V3_0_0_10NM_OLD_TIMI
On Vivante GPUs with an iommu-v1, the gpu linear window's
position must be determined at probe time, and cannot change
during the driver's lifetime.
The existing code attempts to guess a suitable window position
using the dma mask, but this does not always work [1].
According to a recent thread [
Replace the duplicated versions of the while loop with the new macro.
Signed-off-by: Andres Rodriguez
Cc: Dave Airlie
---
This patch depends on "drm/edid: parse CEA blocks embedded in DisplayID"
I didn't send them together to avoid grouping the portion that
was cc:stable and the "touch ups" in
On Wed, Jun 19, 2019 at 06:49:11PM +0100, Emil Velikov wrote:
> On Wed, 19 Jun 2019 at 17:33, Ville Syrjälä
> wrote:
> >
> > On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> > > Hi all,
> > >
> > > Recently I have been looking at i915 and its rather interesting planes.
> > >
> > > I
On Wed, Jun 19, 2019 at 12:15:26PM -0600, Jordan Crouse wrote:
> On Sun, Jun 16, 2019 at 09:29:30AM -0400, Brian Masney wrote:
> > The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
> > that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
> > and adreno_gpu_ocm
From: Sean Paul
If state allocation fails, we still try to give back the reference on
it. Also initialize ret in case the crtc is not enabled and we hit the
eject button.
Fixes: 1452c25b0e60 ("drm: Add helpers to kick off self refresh mode in
drivers")
Cc: Daniel Vetter
Cc: Jose Souza
Cc: Zai
On Sun, Jun 16, 2019 at 09:29:30AM -0400, Brian Masney wrote:
> The files a3xx_gpu.c and a4xx_gpu.c have ifdefs for the OCMEM support
> that was missing upstream. Add two new functions (adreno_gpu_ocmem_init
> and adreno_gpu_ocmem_cleanup) that removes some duplicated code. We also
> need to change
DisplayID blocks allow embedding of CEA blocks. The payloads are
identical to traditional top level CEA extension blocks, but the header
is slightly different.
This change allows the CEA parser to find a CEA block inside a DisplayID
block. Additionally, it adds support for parsing the embedded CTA
On Sun, Jun 16, 2019 at 09:29:26AM -0400, Brian Masney wrote:
> Some A3xx and A4xx Adreno GPUs do not have GMEM inside the GPU core and
> must use the On Chip MEMory (OCMEM) in order to be functional. Add the
> optional ocmem property to the Adreno Graphics Management Unit bindings.
>
> Signed-off
On Wed, 19 Jun 2019 at 17:33, Ville Syrjälä
wrote:
>
> On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> > Hi all,
> >
> > Recently I have been looking at i915 and its rather interesting planes.
> >
> > In particular newer hardware is capable of using 3 universal planes and
> > a sep
On Tue, Jun 18, 2019 at 05:22:15PM +0200, Daniel Vetter wrote:
> On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> > On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > > Just a bit of paranoia, since if we start pushing this deep into
> > > callchains it's hard to spo
On Wed, Jun 19, 2019 at 9:37 AM Jason Gunthorpe wrote:
>
> On Wed, Jun 19, 2019 at 11:40:32AM +0200, Christoph Hellwig wrote:
> > On Tue, Jun 18, 2019 at 12:47:10PM -0700, Dan Williams wrote:
> > > > Git tree:
> > > >
> > > > git://git.infradead.org/users/hch/misc.git hmm-devmem-cleanup.2
> >
On Wed, Jun 19, 2019 at 05:03:53PM +0100, Emil Velikov wrote:
> Hi all,
>
> Recently I have been looking at i915 and its rather interesting planes.
>
> In particular newer hardware is capable of using 3 universal planes and
> a separate cursor-only plane. At the same time only 1 top-most plane ca
On Mon, 2019-06-17 at 12:04 +1000, Alastair D'Silva wrote:
> From: Alastair D'Silva
>
> Apologies for the large CC list, it's a heads up for those responsible
> for subsystems where a prototype change in generic code causes a change
> in those subsystems.
>
> This series enhances hexdump.
Still
On Wed, Jun 19, 2019 at 12:33:33PM -0300, Ezequiel Garcia wrote:
> On Wed, 2019-06-19 at 18:03 +0300, Ville Syrjälä wrote:
> > On Wed, Jun 19, 2019 at 10:18:18AM -0300, Ezequiel Garcia wrote:
> > > On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > > > > -Original Message-
> > > > >
On Mon, Jun 17, 2019 at 10:33:42AM +0200, Christoph Hellwig wrote:
> > drivers/infiniband/hw/cxgb4/qp.c
> >129 static int alloc_host_sq(struct c4iw_rdev *rdev, struct t4_sq *sq)
> >130 {
> >131 sq->queue = dma_alloc_coherent(&(rdev->lldi.pdev->dev),
> > sq->memsize,
> >1
Hi Lowry,
On Mon, Jun 17, 2019 at 06:55:49AM +0100, Lowry Li (Arm Technology China) wrote:
> Adds runtime and system power management support in KMS kernel driver.
>
> Depends on:
> - https://patchwork.freedesktop.org/series/61650/
> - https://patchwork.freedesktop.org/series/60083/
>
> Signed-o
Hi all,
Recently I have been looking at i915 and its rather interesting planes.
In particular newer hardware is capable of using 3 universal planes and
a separate cursor-only plane. At the same time only 1 top-most plane can
be enabled - lets calls those plane3 or cursor.
Hence currently the har
On Wed, 2019-06-19 at 18:03 +0300, Ville Syrjälä wrote:
> On Wed, Jun 19, 2019 at 10:18:18AM -0300, Ezequiel Garcia wrote:
> > On Wed, 2019-06-19 at 06:20 +, Shankar, Uma wrote:
> > > > -Original Message-
> > > > From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On
> > >
On Wed, 19 Jun 2019, Sean Paul wrote:
> On Wed, Jun 19, 2019 at 01:01:41PM +0300, Dan Carpenter wrote:
>> 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
On 18/06/2019 19:23, Jernej Škrabec wrote:
> Hi!
>
> Dne torek, 18. junij 2019 ob 01:55:58 CEST je Douglas Anderson napisal(a):
>> Let's add some better support for HDMI audio to dw_hdmi.
>> Specifically:
>>
>> 1. For 44.1 kHz audio the old code made the assumption that an N of
>> 6272 was right m
On Wed, Jun 19, 2019 at 01:01:41PM +0300, Dan Carpenter wrote:
> 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
Thanks for the patch a
On Wed, Jun 19, 2019 at 10:18:18AM -0300, Ezequiel Garcia wrote:
> 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, 20
On Wed, Jun 19, 2019 at 01:07:05AM -0700, Christoph Hellwig wrote:
> On Wed, Jun 19, 2019 at 12:53:55AM +, Kuehling, Felix wrote:
> > This code is derived from our old MMU notifier code. Before HMM we used
> > to register a single MMU notifier per mm_struct and look up virtual
> > address ran
Reduce size of duplicated comments by switching to use SPDX identifier.
No functional change.
While here, correct MODULE_LICENSE() string to be aligned with license text.
Signed-off-by: Andy Shevchenko
---
drivers/video/backlight/pwm_bl.c | 11 +++
1 file changed, 3 insertions(+), 8 de
> rename Documentation/{ => driver-api}/atomic_bitops.rst (99%)
Same here: NAK, this document does not belong to driver-api.
I also realize that, despite previous notices, you keep touching
documentation without even CC-ing the people who care...
Andrea
___
On Wed, Jun 19, 2019 at 01:18:58AM -0700, Christoph Hellwig wrote:
> > mutex_lock(&hmm->lock);
> > - list_del(&range->list);
> > + list_del_init(&range->list);
> > mutex_unlock(&hmm->lock);
>
> I don't see the point why this is a list_del_init - that just
> reinitializeѕ range->list, b
On Wed, 19 Jun 2019 12:42:39 +0200
Peter Zijlstra wrote:
> No, the other way around, Sphinx can recognize local files and treat
> them special. That way we keep the text readable.
>
> Same with that :c:func:'foo' crap, that needs to die, and Sphinx needs
> to be taught about foo().
I did a patc
On Tue, Jun 18, 2019 at 10:31 AM Robert Chiras wrote:
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-raydium-rm67191.c
> @@ -0,0 +1,709 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * i.MX drm driver - Raydium MIPI-DSI panel driver
Please remove the "i.MX drm driver" as there is nothi
On Wed, Jun 19, 2019 at 08:08:09AM +, Fabrizio Castro wrote:
> 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 r8a7
https://bugs.freedesktop.org/show_bug.cgi?id=110949
--- Comment #2 from Mike Lothian ---
It reverts cleanly and the warnings go away once its gone
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-
https://bugs.freedesktop.org/show_bug.cgi?id=110949
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #1 from
On 6/18/19 1:46 PM, Maarten Lankhorst wrote:
> Op 18-06-2019 om 13:17 schreef Bartlomiej Zolnierkiewicz:
>> Hi,
>>
>> On 6/18/19 11:20 AM, Maarten Lankhorst wrote:
>>> Op 14-06-2019 om 11:25 schreef Maarten Lankhorst:
Hi all,
As discussed with Daniel V, I'm just doing the paperwork
https://bugs.freedesktop.org/show_bug.cgi?id=110702
--- Comment #11 from Pierre-Eric Pelloux-Prayer
---
(In reply to Christian König from comment #10)
> (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
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 = {
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
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
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:
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.
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
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 #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
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=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
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.
>
>
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
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
1 - 100 of 187 matches
Mail list logo
