Hi all,
On Wed, 3 Jul 2019 01:55:08 + "Kuehling, Felix"
wrote:
>
> From: Philip Yang
>
> In order to pass mirror instead of mm to hmm_range_register, we need
> pass bo instead of ttm to amdgpu_ttm_tt_get_user_pages because mirror
> is part of amdgpu_mn structure, which is accessible from
Make it actually clear the LUT.
Reported-by: Dave Airlie
Signed-off-by: Ilia Mirkin
---
tests/util/pattern.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/util/pattern.c b/tests/util/pattern.c
index 42a0e5c7..bf1797d4 100644
--- a/tests/util/pattern.c
+++
Reviewed-by: Dave Airlie
On Wed, Jul 3, 2019 at 1:20 PM Ilia Mirkin wrote:
>
> Make it actually clear the LUT.
>
> Reported-by: Dave Airlie
> Signed-off-by: Ilia Mirkin
> ---
> tests/util/pattern.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/util/pattern.c
On Mon 01 Jul 10:39 PDT 2019, Jeffrey Hugo wrote:
> Creating the msm gem address space requires a reference to the dev where
> the iommu is located. The driver currently assumes this is the same as
> the platform device, which breaks when the iommu is outside of the
> platform device. Use the
On Fri, Jun 28, 2019 at 7:32 PM Koenig, Christian
wrote:
>
> Am 28.06.19 um 18:40 schrieb Daniel Vetter:
> > On Fri, Jun 28, 2019 at 5:21 PM Koenig, Christian
> > wrote:
> >> Am 28.06.19 um 16:38 schrieb Daniel Vetter:
> >> [SNIP]
> >>> - when you submit command buffers, you _dont_ attach
On Mon, Jul 1, 2019 at 12:07 PM Jeffrey Hugo wrote:
>
> On 7/1/2019 12:58 PM, Rob Clark wrote:
> > On Mon, Jul 1, 2019 at 11:37 AM Jeffrey Hugo wrote:
> >>
> >> On 6/30/2019 9:01 AM, Rob Clark wrote:
> >>> From: Rob Clark
> >>>
> >>> Do an extra enable/disable cycle at init, to get the clks
On 19.04.2019 10:19, Ronald Tschalär wrote:
> commit d6abe6df706c (drm/bridge: sil_sii8620: do not have a dependency
> of RC_CORE) changed the driver to select both RC_CORE and INPUT.
> However, this causes problems with other drivers, in particular an input
> driver that depends on
https://bugs.freedesktop.org/show_bug.cgi?id=109206
--- Comment #52 from Talha Khan ---
(In reply to Ondrej Lang from comment #50)
> I tested this yesterday with kernel 5.1.8 and if the file raven_dmcu.bin is
> present in the /lib/firmware/amdgpu/ folder when you are updating the kernel
> (or
Daniel,
On 02/07/2019 15:04, Daniel Thompson wrote:
On Tue, Jul 02, 2019 at 12:59:53PM +0200, Jean-Jacques Hiblot wrote:
Hi Daniel,
On 02/07/2019 11:54, Daniel Thompson wrote:
On Mon, Jul 01, 2019 at 05:14:22PM +0200, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
This patch adds a
On Tue, Jul 2, 2019 at 8:20 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Sun, Jun 30, 2019 at 08:01:43AM -0700, Rob Clark wrote:
> > From: Rob Clark
> >
> > Request the enable gpio ASIS to avoid disabling bridge during probe, if
> > already enabled. And if already
From: Rob Clark
Noticed while comparing register dump of how bootloader configures DSI
vs how kernel configures. It seems the bridge still works either way,
but fixing this clears the 'CHA_DATATYPE_ERR' error status bit.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 3
From: Rob Clark
Add a debugfs file to show status registers.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 42 +++
1 file changed, 42 insertions(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
index
From: Rob Clark
In process of debugging panel on my lenovo yoga c630, I noticed some
errors in the dsi->mode_flags, which I guess were just cargo-cult'd?
Since dumping the status regs was useful to notice this problem, I
cleaned it up and turned it into debugfs. The last patch corrects the
On Tue, Jul 02, 2019 at 12:59:53PM +0200, Jean-Jacques Hiblot wrote:
> Hi Daniel,
>
> On 02/07/2019 11:54, Daniel Thompson wrote:
> > On Mon, Jul 01, 2019 at 05:14:22PM +0200, Jean-Jacques Hiblot wrote:
> > > From: Tomi Valkeinen
> > >
> > > This patch adds a led-backlight driver (led_bl),
On Sun, Jun 30, 2019 at 01:10:28AM -0400, Kenny Ho wrote:
> On Thu, Jun 27, 2019 at 3:24 AM Daniel Vetter wrote:
> > Another question I have: What about HMM? With the device memory zone
> > the core mm will be a lot more involved in managing that, but I also
> > expect that we'll have classic
https://bugs.freedesktop.org/show_bug.cgi?id=110730
emersion changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Tue, Jul 2, 2019 at 8:59 PM Maxime Ripard wrote:
>
> On Tue, Jul 02, 2019 at 12:30:14AM +0530, Jagan Teki wrote:
> > On Tue, Jun 25, 2019 at 8:07 PM Maxime Ripard
> > wrote:
> > > > > > > > > > BSP has tcon_div and dsi_div. dsi_div is dynamic which
> > > > > > > > > > depends on
> > > > > >
On Fri, Jun 28, 2019 at 03:49:28PM -0400, Kenny Ho wrote:
> On Thu, Jun 27, 2019 at 2:11 AM Daniel Vetter wrote:
> > I feel like a better approach would by to add a cgroup for the various
> > engines on the gpu, and then also account all the sdma (or whatever the
> > name of the amd copy engines
On Sun, Jun 30, 2019 at 08:19:19AM +0200, Sam Ravnborg wrote:
> The macro DRM_VRAM_MM_FILE_OPERATIONS referencs
> functions declared in other header files.
> Include these header files so this header files
> pulls in what it references.
>
> Signed-off-by: Sam Ravnborg
> Cc: Maarten Lankhorst
>
Due to the tracking provided by the scheduler we know exactly which
submit is failing. Only dump this single submit and the required
auxiliary information. This cuts down the size of the devcoredumps
by only including relevant information.
Signed-off-by: Lucas Stach
---
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(-)
Rework fencing workflow. Stop using ttm helpers, use the
virtio_gpu_array_* helpers instead.
Due to using the gem reservation object it is initialized and ready for
use before calling ttm_bo_init. So we can simply use the standard
fencing workflow and drop the tricky logic which checks whenever
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
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
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
Rework fencing workflow, starting with virtio_gpu_execbuffer_ioctl.
Stop using ttm helpers, use the virtio_gpu_array_* helpers (which work
on the reservation objects directly) instead.
New workflow:
(1) All gem objects needed by a command are added to a
virtio_gpu_object_array.
(2) All
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
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 3 ++-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 35 +++---
drivers/gpu/drm/virtio/virtgpu_vq.c| 8 --
3 files changed, 23 insertions(+), 23
Make sure we don't leak half-initialized fences outside the driver.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_fence.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/virtio/virtgpu_fence.c
b/drivers/gpu/drm/virtio/virtgpu_fence.c
index
No users left.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index 577a8103670e..78dc5a19a358 100644
---
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
drivers/gpu/drm/virtio/virtgpu_gem.c | 24 +++-
drivers/gpu/drm/virtio/virtgpu_vq.c | 10 ++
3 files changed, 19 insertions(+), 19
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 ---
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
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
Some helper functions to manage an array of gem objects.
v6:
- add ticket to struct virtio_gpu_object_array.
- add virtio_gpu_array_{lock,unlock}_resv helpers.
- add virtio_gpu_array_add_fence helper.
v5: some small optimizations (Chia-I Wu).
v4: make them virtio-private instead of generic
Use drm_gem_reservation_object_wait() in virtio_gpu_wait_ioctl().
This also makes the ioctl run lockless.
v5: handle lookup failure.
v2: use reservation_object_test_signaled_rcu for VIRTGPU_WAIT_NOWAIT.
Signed-off-by: Gerd Hoffmann
Reviewed-by: Daniel Vetter
---
No users left.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 21 -
1 file changed, 21 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_drv.h
b/drivers/gpu/drm/virtio/virtgpu_drv.h
index d99c54abd090..23670109d167 100644
---
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.
v6:
- largely rewrite fencing logic, using the virtio_gpu_array_* helpers
- add more patches to the series.
v5:
- fence bugfixes.
- minor
Switch to the virtio_gpu_array_* helper workflow.
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/virtio/virtgpu_drv.h | 2 +-
drivers/gpu/drm/virtio/virtgpu_ioctl.c | 43 --
drivers/gpu/drm/virtio/virtgpu_vq.c| 5 ++-
3 files changed, 25 insertions(+), 25
On Fri, 28 Jun 2019 at 17:45, Daniel Vetter wrote:
>
> On Fri, Jun 28, 2019 at 06:01:14PM +0200, Andrzej Pietrasiewicz wrote:
> > It is difficult for a user to know which of the i2c adapters is for which
> > drm connector. This series addresses this problem.
> >
> > The idea is to have a symbolic
On Fri, Jun 28, 2019 at 02:43:18PM -0400, Kenny Ho wrote:
> On Thu, Jun 27, 2019 at 5:24 PM Daniel Vetter wrote:
> > On Thu, Jun 27, 2019 at 02:42:43PM -0400, Kenny Ho wrote:
> > > Um... I am going to get a bit philosophical here and suggest that the
> > > idea of sharing (especially uncontrolled
On Fri, 28 Jun 2019 12:39:05 +0200
Arnd Bergmann wrote:
> mode->name is a character array in a structure, checking it's
> address is pointless and causes a warning with some compilers:
>
> drivers/gpu/drm/drm_connector.c:144:15: error: address of array 'mode->name'
> will always evaluate to
From: Rob Clark
The bridge has pretty good docs, lets add a link to make them easier to
find.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/bridge/ti-sn65dsi86.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi86.c
b/drivers/gpu/drm/bridge/ti-sn65dsi86.c
On Tue, Jul 02, 2019 at 07:21:29AM -0400, Brian Dodge wrote:
>
> On 7/2/19 5:26 AM, Daniel Thompson wrote:
> > > [PATCH 1/2] dt-bindings: backlight: fix vendor prefix for
> > > ArcticSand arcxcnn driver bindings
> > The "v2" is normally applied to the whole patchset (if you
> > prepare the
On 07/06/2019 20:35, Andrew F. Davis wrote:
Hello all,
So I've got a new IP on our new SoC I'm looking to make use of and would
like some help figuring out what framework best matches its function. The
IP is called a "Page-based Address Translator" or PAT. A PAT instance
(there are 5 of these
On Tue, Jul 02, 2019 at 10:52:50AM -0700, Brendan Higgins wrote:
> On Wed, Jun 26, 2019 at 12:53 AM Brendan Higgins
> wrote:
> >
> > On Tue, Jun 25, 2019 at 4:22 PM Luis Chamberlain wrote:
> > >
> > > On Mon, Jun 17, 2019 at 01:26:02AM -0700, Brendan Higgins wrote:
> > > > diff --git
On Fri, Jun 28, 2019 at 12:31 PM Andrzej Pietrasiewicz
wrote:
>
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> drivers/gpu/drm/radeon/radeon_connectors.c | 82 +-
> 1 file changed, 63 insertions(+), 19 deletions(-)
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Adrian Salido (1):
libdrm: reduce number of reallocations in drmModeAtomicAddProperty
Chunming Zhou (9):
add cs chunk for syncobj timeline
add timeline wait/query ioctl v2
wrap syncobj timeline query/wait APIs for amdgpu v3
I think this could happen if KFD initialization fails for a device.
Currently we'd add the device, and then remove it again. That may leave
a gap in the proximity domains. Oak just had a fix recently to clean
that up by only adding KFD devices to the topology after successful
initialization.
From: Rob Clark
One of the challenges we need to handle to enable the aarch64 laptops
upstream is dealing with the fact that the bootloader enables the
display and takes the corresponding SMMU context-bank out of BYPASS.
Unfortunately, currently, the IOMMU framework attaches a DMA (or
From: Rob Clark
Avoid attaching any non-driver managed domain if the driver indicates
that it manages the iommu directly.
This solves a couple problems that drm/msm + arm-smmu has with the iommu
framework:
1) In some cases the bootloader takes the iommu out of bypass and
enables the
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 1 +
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c| 1 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 1 +
drivers/gpu/drm/msm/msm_drv.c | 1 +
4 files changed, 4 insertions(+)
diff --git
On Tue, Jul 2, 2019 at 1:35 PM Ard Biesheuvel wrote:
>
> On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel wrote:
> >
> > On Sun, 30 Jun 2019 at 22:36, Rob Clark wrote:
> > >
> > > From: Rob Clark
> > >
> > > On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided
> > > to
On 2019-07-01 03:29, d...@codeaurora.org wrote:
On 2019-06-26 03:10, Jeykumar Sankaran wrote:
On 2019-06-24 22:44, d...@codeaurora.org wrote:
On 2019-06-25 03:56, Jeykumar Sankaran wrote:
On 2019-06-23 23:27, Shubhashree Dhar wrote:
dpu encoder spinlock should be initialized during dpu
On 2019-07-02 11:21, Jeykumar Sankaran wrote:
On 2019-07-01 03:29, d...@codeaurora.org wrote:
On 2019-06-26 03:10, Jeykumar Sankaran wrote:
On 2019-06-24 22:44, d...@codeaurora.org wrote:
On 2019-06-25 03:56, Jeykumar Sankaran wrote:
On 2019-06-23 23:27, Shubhashree Dhar wrote:
dpu encoder
Hi,
On Tue, Jul 2, 2019 at 4:26 AM Ezequiel Garcia wrote:
>
> Hi Heiko,
>
> On Fri, 2019-06-21 at 18:13 -0300, Ezequiel Garcia wrote:
> > Let's support Gamma LUT configuration on RK3288 SoCs.
> >
> > In order to do so, this series adds a new and optional
> > address resource.
> >
> > A separate
On Fri, Jun 28, 2019 at 12:31 PM Andrzej Pietrasiewicz
wrote:
>
> Use the ddc pointer provided by the generic connector.
>
> Signed-off-by: Andrzej Pietrasiewicz
> ---
> .../gpu/drm/amd/amdgpu/amdgpu_connectors.c| 70 ++-
> 1 file changed, 51 insertions(+), 19 deletions(-)
>
On Sat, Jun 29, 2019 at 09:45:10AM -0700, Joe Perches wrote:
> On Sat, 2019-06-29 at 17:25 +0300, Alexey Dobriyan wrote:
> > On Tue, Jun 11, 2019 at 03:00:10PM -0600, Andreas Dilger wrote:
> > > On Jun 11, 2019, at 2:48 PM, Andrew Morton
> > > wrote:
> > > > On Wed, 12 Jun 2019 01:08:36 +0530
On 2019-07-01 2:20 a.m., Christoph Hellwig wrote:
> We should not have two different error codes for the same condition. In
> addition this really complicates the code due to the special handling of
> EAGAIN that drops the mmap_sem due to the FAULT_FLAG_ALLOW_RETRY logic
> in the core vm.
I
On Fri, 28 Jun 2019 12:14:44 -0700 Dan Williams
wrote:
> I believe -mm auto drops patches when they appear in the -next
> baseline. So it should "just work" to pull it into the series and send
> it along for -next inclusion.
Yup. Although it isn't very "auto" - I manually check that the patch
On Tue, Jul 2, 2019 at 11:42 AM Jason Gunthorpe wrote:
>
> On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > And I've demonstrated that I can't send patch series.. While this
> > has all the right patches, it also has the extra patches already
> > in the hmm tree, and four
Devicetree systems can set panel orientation via a panel binding, but
there's no way, as is, to propagate this setting to the connector,
where the property need to be added.
To address this, this patch sets orientation, as well as other fixed
values for the panel, in the drm_panel_attach function.
On Tue, Jul 2, 2019 at 2:30 PM Jeffrey Hugo wrote:
>
> On Sun, Jun 30, 2019 at 7:16 AM Rob Clark wrote:
> > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > @@ -1824,6 +1824,20 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
> > goto
https://bugs.freedesktop.org/show_bug.cgi?id=108318
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #10 from Timothy
On Tue, Jul 2, 2019 at 2:53 PM Ard Biesheuvel wrote:
>
> On Tue, 2 Jul 2019 at 23:02, Rob Clark wrote:
> >
> > On Tue, Jul 2, 2019 at 1:35 PM Ard Biesheuvel
> > wrote:
> > >
> > > On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel
> > > wrote:
> > > >
> > > > On Sun, 30 Jun 2019 at 22:36, Rob Clark
>
> On Mon, Jul 01, 2019 at 10:25:17AM +0200, Christoph Hellwig wrote:
> > And I've demonstrated that I can't send patch series.. While this has
> > all the right patches, it also has the extra patches already in the
> > hmm tree, and four extra patches I wanted to send once this series is
> >
On Tue, Jul 2, 2019 at 2:59 PM Leif Lindholm wrote:
>
> On Tue, Jul 02, 2019 at 02:01:49PM -0700, Rob Clark wrote:
> > > > So we are dealing with a platform that violates the UEFI spec, since
> > > > it does not bother to implement variable services at runtime (because
> > > > MS let the vendor
On Tue, Jul 2, 2019 at 7:19 AM Gerd Hoffmann wrote:
> Switch to the virtio_gpu_array_* helper workflow.
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/virtio/virtgpu_drv.h | 4 ++--
> drivers/gpu/drm/virtio/virtgpu_gem.c | 24 +++-
>
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Signed-off-by: Derek Basehore
---
On Sun, 30 Jun 2019 at 22:36, Rob Clark wrote:
>
> From: Rob Clark
>
> On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided
> to communicate some information about the display. Crutially it has the
> panel-id, so the appropriate panel driver can be selected. Read this
> out
On Sun, Jun 30, 2019 at 7:16 AM Rob Clark wrote:
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -1824,6 +1824,20 @@ int msm_dsi_host_init(struct msm_dsi *msm_dsi)
> goto fail;
> }
>
> + /*
> +* Make sure we have
From: Philip Yang
In order to pass mirror instead of mm to hmm_range_register, we need
pass bo instead of ttm to amdgpu_ttm_tt_get_user_pages because mirror
is part of amdgpu_mn structure, which is accessible from bo.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Signed-off-by: Felix
On 2019-07-02 6:59 p.m., Jason Gunthorpe wrote:
> On Wed, Jul 03, 2019 at 12:49:12AM +0200, Christoph Hellwig wrote:
>> On Tue, Jul 02, 2019 at 07:53:23PM +, Jason Gunthorpe wrote:
I'm sending this out now since we are updating many of the HMM APIs
and I think it will be useful.
>>>
https://bugs.freedesktop.org/show_bug.cgi?id=106224
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Timothy
On Tue, 2 Jul 2019 at 23:02, Rob Clark wrote:
>
> On Tue, Jul 2, 2019 at 1:35 PM Ard Biesheuvel
> wrote:
> >
> > On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel
> > wrote:
> > >
> > > On Sun, 30 Jun 2019 at 22:36, Rob Clark wrote:
> > > >
> > > > From: Rob Clark
> > > >
> > > > On snapdragon
On Tue, Jul 02, 2019 at 02:01:49PM -0700, Rob Clark wrote:
> > > So we are dealing with a platform that violates the UEFI spec, since
> > > it does not bother to implement variable services at runtime (because
> > > MS let the vendor get away with this).
> >
> > To clarify, the above remark
On Tue, 2 Jul 2019 at 22:26, Ard Biesheuvel wrote:
>
> On Sun, 30 Jun 2019 at 22:36, Rob Clark wrote:
> >
> > From: Rob Clark
> >
> > On snapdragon aarch64 laptops, a 'UEFIDisplayInfo' variable is provided
> > to communicate some information about the display. Crutially it has the
> >
This adds a helper function for reading the rotation (panel
orientation) from the device tree.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 43 +
include/drm/drm_panel.h | 7 ++
2 files changed, 50 insertions(+)
diff --git
This adds the plumbing for reading panel rotation from the devicetree
and sets up adding a panel property for the panel orientation on
Mediatek SoCs when a rotation is present.
v4 changes:
-fixed some changes made to the i915 driver
-clarified comments on of orientation helper
v3 changes:
On Tue, Jul 2, 2019 at 3:24 AM Jason Gunthorpe wrote:
>
> On Mon, Jul 01, 2019 at 09:33:04PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the hmm tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > mm/hmm.c: In function 'hmm_get_or_create':
> >
Hi Dave, Daniel,
3 fixes all cc'ed to stable. Note that dim complains about the Fixes tag
in one of the patches. The patch has:
Fixes: 921935dc6404 ("drm/amd/powerplay: enforce display related settings only
on needed")
while dim recommends:
Fixes: commit 921935dc6404 ("drm/amd/powerplay:
On Thu, Jun 27, 2019 at 9:53 AM Steven Price wrote:
>
> panfrost_ioctl_mmap_bo() contains a reimplementation of
> drm_gem_map_offset() but with a bug - it allows mapping imported
> objects (without going through the exporter). Fix this by switching to
> use the newly renamed drm_gem_map_offset()
https://bugs.freedesktop.org/show_bug.cgi?id=107907
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 2019-07-01 6:01 p.m., Timur Kristóf wrote:
> On Mon, 2019-07-01 at 16:54 +0200, Michel Dänzer wrote:
>> On 2019-06-28 2:21 p.m., Timur Kristóf wrote:
>>> I haven't found a good way to measure the maximum PCIe throughput
>>> between the CPU and GPU,
>>
>> amdgpu.benchmark=3
>>
>> on the kernel
> [PATCH 1/2] dt-bindings: backlight: fix vendor prefix for
> ArcticSand arcxcnn driver bindings
The "v2" is normally applied to the whole patchset (if you
prepare the patchset using git format-patch then you can use
the --subject-prefix argument for that).
On Sun, Jun 30, 2019 at 08:28:14PM
On Tue, Jul 02, 2019 at 07:36:53AM +0100, Lee Jones wrote:
> On Mon, 01 Jul 2019, Sekhar Nori wrote:
>
> > Hi Lee, Daniel, Jingoo,
> >
> > On 25/06/19 10:04 PM, Bartosz Golaszewski wrote:
> > > From: Bartosz Golaszewski
> > >
> > > This is another small step on the path to liberating davinci
PRIME functionality is now provided by GEM object functions. The driver
callback functions are obsolete. So this patch renames them and turns
them into static internal functions of the VRAM helper library. The
implementation of gem_prime_mmap is now unused and the patch removes it.
v3:
*
The GEM object's free function is now called through struct
drm_gem_object_funcs.free. The function struct drm_driver.gem_prime_mmap
is now required for mmap'ing GEM objects to userspace.
v2:
* set drm_driver.gem_prime_mmap to drm_gem_prime_mmap()
Signed-off-by: Thomas Zimmermann
The vbox driver uses VRAM helpers for memory management. These helpers
provide a basic implementation of PRIME functions, so the vbox driver's
empty implmentation can be removed. As a side effect of this change,
vbox can now use generic framebuffer emulation.
Signed-off-by: Thomas Zimmermann
From: Colin Ian King
There is a spelling mistake in a variable name, fix this by renaming
it to enable.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/display/dc/dce/dce_mem_input.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git
On 25/06/2019 17:34, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
There's no good reason to have the generic probing code in a separate
routine. This function is short and is inlined by the compiler anyway.
Move it into probe under the pdata-specific part.
Signed-off-by: Bartosz
On Mon, Jul 01, 2019 at 05:14:23PM +0200, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> Add DT binding for led-backlight.
I think the patchset is in the wrong order; the DT bindings
documentation should appear *before* the binding is
implemented (amoung other things this prevent
On Tue, 2 Jul 2019 at 10:20, Gerd Hoffmann wrote:
>
> Hi,
>
> > +static void drm_gem_vram_object_free(struct drm_gem_object *gem)
> > +{
> > + struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(gem);
> > +
> > + drm_gem_vram_put(gbo);
> > +}
>
> Hmm, seems git diff didn't figure it's
On Fri, Jun 28, 2019 at 11:15:10AM +0100, Linus Walleij wrote:
> On Fri, Jun 28, 2019 at 11:03 AM Bartosz Golaszewski wrote:
>
> > From: Bartosz Golaszewski
> >
> > While working on my other series related to gpio-backlight[1] I noticed
> > that we could simplify the driver if we made the only
The subject should've been "Armada updates for merge window". Sorry.
On Tue, Jul 02, 2019 at 10:13:13AM +0100, Russell King wrote:
> Hi David,
>
> The following changes since commit e93c9c99a629c61837d5a7fc2120cd2b6c70dbdd:
>
> Linux 5.1 (2019-05-05 17:42:58 -0700)
>
> are available in the
Hi Heiko,
On Fri, 2019-06-21 at 18:13 -0300, Ezequiel Garcia wrote:
> Let's support Gamma LUT configuration on RK3288 SoCs.
>
> In order to do so, this series adds a new and optional
> address resource.
>
> A separate address resource is required because on this RK3288,
> the LUT address is
On 25/06/2019 17:34, Bartosz Golaszewski wrote:
From: Bartosz Golaszewski
Instead of dereferencing pdev each time, use a helper variable for
the associated device pointer.
Signed-off-by: Bartosz Golaszewski
No objections but I think this will need to be respun against
backlight-next (or
On Mon, Jul 01, 2019 at 05:14:22PM +0200, Jean-Jacques Hiblot wrote:
> From: Tomi Valkeinen
>
> This patch adds a led-backlight driver (led_bl), which is mostly similar to
> pwm_bl except the driver uses a LED class driver to adjust the brightness
> in the HW.
>
> Signed-off-by: Tomi Valkeinen
Hi Daniel,
On 02/07/2019 11:54, Daniel Thompson wrote:
On Mon, Jul 01, 2019 at 05:14:22PM +0200, Jean-Jacques Hiblot wrote:
From: Tomi Valkeinen
This patch adds a led-backlight driver (led_bl), which is mostly similar to
pwm_bl except the driver uses a LED class driver to adjust the
VRAM PRIME helpers are now called through GEM object functions. The
driver callback functions are obsolete.
Signed-off-by: Thomas Zimmermann
Acked-by: Daniel Vetter
Reviewed-by: Emil Velikov
---
drivers/gpu/drm/bochs/bochs_drv.c | 1 -
1 file changed, 1 deletion(-)
diff --git
1 - 100 of 136 matches
Mail list logo