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
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
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
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
+++
https://bugs.freedesktop.org/show_bug.cgi?id=106224
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #1 from Timothy
https://bugs.freedesktop.org/show_bug.cgi?id=107907
Timothy Arceri changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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()
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.
>>>
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:
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 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
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 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':
> >
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
---
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:
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
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
> >
https://bugs.freedesktop.org/show_bug.cgi?id=108318
Timothy Arceri changed:
What|Removed |Added
Status|NEW |NEEDINFO
--- Comment #10 from Timothy
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
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 +++-
>
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
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 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: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 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 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 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 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 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(-)
>
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(-)
>
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
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
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
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 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
-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.
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 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 a/kunit/example-test.c b/kunit/example-test.c
> > > new file mode 100644
> > > index
On Tue, Jul 2, 2019 at 11:12 AM Rob Clark wrote:
>
> On Tue, Jul 2, 2019 at 10:09 AM Jeffrey Hugo wrote:
> >
> > On Tue, Jul 2, 2019 at 9:46 AM Rob Clark wrote:
> > >
> > > - dsi->mode_flags = MIPI_DSI_MODE_VIDEO |
> > > MIPI_DSI_MODE_VIDEO_SYNC_PULSE |
> > > -
On Fri, 14 Jun 2019 at 19:02, Koenig, Christian
wrote:
>
> Am 14.06.19 um 19:33 schrieb Emil Velikov:
> > From: Emil Velikov
> >
> > Currently the AMDGPU_CTX_PRIORITY_* defines are used in both
> > drm_amdgpu_ctx_in::priority and drm_amdgpu_sched_in::priority.
> >
> > Extend the comment to
On Tue, Jul 2, 2019 at 10:09 AM Jeffrey Hugo wrote:
>
> On Tue, Jul 2, 2019 at 9:46 AM Rob Clark wrote:
> >
> > 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
On Tue, Jul 2, 2019 at 9:46 AM Rob Clark wrote:
>
> 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.
>
>
On Tue, Jul 2, 2019 at 9:46 AM Rob Clark wrote:
>
> From: Rob Clark
>
> Add a debugfs file to show status registers.
>
> Signed-off-by: Rob Clark
Reviewed-by: Jeffrey Hugo
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
Fix audio master clock use for Silab sii902x HDMI transceiver.
Make audio master clock optional, as this clock is not mandatory.
Olivier Moysan (3):
drm/bridge: sii902x: fix missing reference to mclk clock
dt-bindings: display: sii902x: Change audio mclk binding
drm/bridge: sii902x: make
As stated in SiL9022/24 datasheet, master clock is not required for I2S.
Make mclk property optional in DT bindings.
Fixes: 3f18021f43a3 ("dt-bindings: display: sii902x: Add HDMI audio bindings")
Signed-off-by: Olivier Moysan
---
Documentation/devicetree/bindings/display/bridge/sii902x.txt | 5
The master clock on i2s bus is not mandatory,
as sii902X internal PLL can be used instead.
Make use of mclk optional.
Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
Signed-off-by: Olivier Moysan
---
drivers/gpu/drm/bridge/sii902x.c | 39
Add devm_clk_get call to retrieve reference to master clock.
Fixes: ff5781634c41 ("drm/bridge: sii902x: Implement HDMI audio support")
Signed-off-by: Olivier Moysan
---
drivers/gpu/drm/bridge/sii902x.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/bridge/sii902x.c
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
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
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
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 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 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 the comments , "we will loop GPUs that already be processed (with
lower value of proximity_domain) ", the device should already been
added into the topology_device_list. So in this case ,
kfd_topology_device_by_proximity_domain will not return a NULL pointer.
If you really get the
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
> > > > > > > > > bpp/lanes and it indeed depends on PLL computation (not
>
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 enabled, defer enabling runpm until
> attach to avoid cutting off the
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 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
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
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
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
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 ---
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
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 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
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
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(-)
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
---
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
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
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 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
Hi Oleg,
On Mon, 1 Jul 2019 at 09:00, Oleg Vasilev wrote:
>
> Currently, downstream port type is only reported in debugfs. This
> information should be considered important since it reflects the actual
> physical connector type. Some userspace (e.g. window compositors)
> may want to show this
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
>
https://bugs.freedesktop.org/show_bug.cgi?id=110730
emersion changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
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 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 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 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 1:36 PM Rob Clark wrote:
>
> From: Rob Clark
>
> Now that we can deal gracefully with bootloader (firmware) initialized
> display on aarch64 laptops[1], the next step is to deal with the fact
> that the same model of laptop can have one of multiple different panels.
>
On Mon, Jul 01, 2019 at 11:00:21AM +0300, Oleg Vasilev wrote:
> Currently, downstream port type is only reported in debugfs. This
> information should be considered important since it reflects the actual
> physical connector type. Some userspace (e.g. window compositors)
> may want to show this
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
1 - 100 of 136 matches
Mail list logo
