https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #47 from quirin.blae...@freenet.de ---
(In reply to quirin.blaeser from comment #46)
> (In reply to quirin.blaeser from comment #45)
> > (In reply to quirin.blaeser from comment #44)
> > > (In reply to Alex Deucher from comment #43)
>
On Tue, Apr 30, 2019 at 2:22 PM Kazlauskas, Nicholas
wrote:
>
> On 4/30/19 3:44 AM, Michel Dänzer wrote:
> > [CAUTION: External Email]
> >
> > On 2019-04-30 9:37 a.m., Mario Kleiner wrote:
> >> Allow to detect any connected display to be marked as
> >> VRR capable. This is useful for testing the
Hi Fabio,
On Tue, Apr 30, 2019 at 01:24:45PM -0300, Fabio Estevam wrote:
> Hi Guido,
>
> On Tue, Apr 30, 2019 at 11:40 AM Guido Günther wrote:
> >
> > This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
> > this is an IP core it will likely be found on others in the future. So
On Tue, Apr 30, 2019 at 06:10:53AM -0700, Rob Clark wrote:
> On Tue, Apr 30, 2019 at 5:42 AM Boris Brezillon
> wrote:
> >
> > +Rob, Eric, Mark and more
> >
> > Hi,
> >
> > On Fri, 5 Apr 2019 16:20:45 +0100
> > Steven Price wrote:
> >
> > > On 04/04/2019 16:20, Boris Brezillon wrote:
> > > >
On Tue, Apr 30, 2019 at 01:10:02PM +0200, Christian König wrote:
> Add a structure for the parameters of dma_buf_attach, this makes it much
> easier
> to add new parameters later on.
I don't understand this reasoning. What are the "new parameters" that
are being proposed, and why do we need to
On 2019-04-30 9:25 a.m., Andrey Konovalov wrote:
> [CAUTION: External Email]
>
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
>
On 2019-04-30 9:25 a.m., Andrey Konovalov wrote:
> [CAUTION: External Email]
>
> This patch is a part of a series that extends arm64 kernel ABI to allow to
> pass tagged user pointers (with the top byte set to something else other
> than 0x00) as syscall arguments.
>
> radeon_ttm_tt_pin_userptr()
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #16 from Christian Zigotzky ---
(In reply to Michel Dänzer from comment #15)
> This is a platform specific issue. We cannot test on this platform, so
> someone who can has to isolate the change causing the problem. I realize
> this
Hi Guido,
On Tue, Apr 30, 2019 at 11:40 AM Guido Günther wrote:
>
> This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
> this is an IP core it will likely be found on others in the future. So
> instead of adding this to the nwl host driver make it a generic PHY
> driver.
>
>
Hi "Christian,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v5.1-rc7 next-20190430]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0d
Hi Guido.
Took a look at this, but feedback is trivial as
I have no experience with PHYs so use only
the feedback you consider relevant.
Sam
> diff --git a/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> b/drivers/phy/freescale/phy-fsl-imx8-mipi-dphy.c
> new file mode 100644
> index
This is basically a resend of v8 with one minor debug printk fixed and
Rob's Reviewed-by for binding docs collteted. Thanks Rob!
This adds initial support for the Mixel IP based mipi dphy as found on i.MX8
processors. It has support for the i.MX8MQ, support for other variants can be
added - once
Add support for the MIXEL DPHY IP as found on NXP's i.MX8MQ SoCs.
Signed-off-by: Guido Günther
Reviewed-by: Sam Ravnborg
Reviewed-by: Rob Herring
---
.../bindings/phy/mixel,mipi-dsi-phy.txt | 29 +++
1 file changed, 29 insertions(+)
create mode 100644
This adds support for the Mixel DPHY as found on i.MX8 CPUs but since
this is an IP core it will likely be found on others in the future. So
instead of adding this to the nwl host driver make it a generic PHY
driver.
The driver supports the i.MX8MQ. Support for i.MX8QM and i.MX8QXP can be
added
On Mon, Apr 29, 2019 at 09:58:55PM +0200, Sam Ravnborg wrote:
> Hi Thomas.
>
> Some minor things and some bikeshedding too.
>
> One general^Wbikeshedding thing - unint32_t is used in many places.
> And then s64 in one place.
> Seems like two concepts are mixed.
> Maybe be consistent and use u32,
On Mon, Apr 29, 2019 at 04:43:37PM +0200, Thomas Zimmermann wrote:
> The mgag200 driver establishes several memory mappings for frame buffers
> and cursors. This patch converts the driver to use the equivalent
> drm_gem_vram_kmap() functions. It removes the dependencies on TTM
> and cleans up the
Am 30.04.19 um 16:34 schrieb Daniel Vetter:
> [CAUTION: External Email]
>
> On Tue, Apr 30, 2019 at 04:26:32PM +0200, Christian König wrote:
>> Am 30.04.19 um 15:59 schrieb Daniel Vetter:
>>> On Tue, Apr 30, 2019 at 03:42:22PM +0200, Christian König wrote:
Am 29.04.19 um 10:40 schrieb Daniel
On Tue, Apr 30, 2019 at 01:44:19PM +0300, Ville Syrjälä wrote:
> On Tue, Apr 30, 2019 at 11:37:46AM +0200, Linus Walleij wrote:
> > The 50 ms default timeout waiting for vblanks is too small
> > for the first vblank from the ST-Ericsson MCDE display
> > controller over DSI. Presumably this is
https://bugs.freedesktop.org/show_bug.cgi?id=110509
--- Comment #14 from james.dut...@gmail.com ---
I stop gdm and kill any remaining X processes.
When I start gdm and login, it works, and displays the desktop.
Previously, I was leaving on of the X processes running.
So, I think this
On Tue, Apr 30, 2019 at 4:41 PM Koenig, Christian
wrote:
>
> Am 30.04.19 um 16:34 schrieb Daniel Vetter:
> > [CAUTION: External Email]
> >
> > On Tue, Apr 30, 2019 at 04:26:32PM +0200, Christian König wrote:
> >> Am 30.04.19 um 15:59 schrieb Daniel Vetter:
> >>> On Tue, Apr 30, 2019 at 03:42:22PM
linux/commits/Christian-K-nig/dma-buf-add-struct-dma_buf_attach_info-v2/20190430-221017
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 8.1.0
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
https://bugs.freedesktop.org/show_bug.cgi?id=110509
--- Comment #10 from james.dut...@gmail.com ---
Created attachment 144118
--> https://bugs.freedesktop.org/attachment.cgi?id=144118=edit
dmesg with drm-next-5.2-wip
--
You are receiving this mail because:
You are the assignee for the
Am 30.04.19 um 12:51 schrieb Sahu, Satyajit:
Query the max uvd handles and used uvd handles.
NAK, please use the generic amdgpu_query_info() function for this.
Regards,
Christian.
Signed-off-by: Satyajit Sahu
---
amdgpu/amdgpu.h | 14 ++
amdgpu/amdgpu_gpu_info.c |
Am 30.04.19 um 09:01 schrieb Chunming Zhou:
heavy gpu job could occupy memory long time, which lead other user fail to get
memory.
basically pick up Christian idea:
1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO we
Am 30.04.19 um 11:23 schrieb Sam Ravnborg:
> [CAUTION: External Email]
>
> Hi Thomas.
>
+
+/**
+ * Returns the container of type drm_gem_vram_object
+ * for field bo.
+ * @bo: the VRAM buffer object
+ * Returns: The containing GEM VRAM object
+
Add a structure for the parameters of dma_buf_attach, this makes it much easier
to add new parameters later on.
v2: rebase cleanup and fix all new implementations as well
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c | 13 +++--
He unfortunately doesn't work for AMD any more.
Signed-off-by: Christian König
---
MAINTAINERS | 1 -
1 file changed, 1 deletion(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 3d199592fd2c..c52a9f5b9fe4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5369,7 +5369,6 @@ F:
On Tue, Apr 30, 2019 at 11:37:46AM +0200, Linus Walleij wrote:
> The 50 ms default timeout waiting for vblanks is too small
> for the first vblank from the ST-Ericsson MCDE display
> controller over DSI. Presumably this is because the DSI
> display is command-mode only and the state machine will
>
https://bugs.freedesktop.org/show_bug.cgi?id=110509
--- Comment #11 from james.dut...@gmail.com ---
I tried with drm-next-5.2-wip.
It does not hang any more, but I have a new error now.
It is better, in the sense that I can now reboot the system normally, and not
resort to echo b
Hi Thomas.
> >> +
> >> +/**
> >> + * Returns the container of type drm_gem_vram_object
> >> + * for field bo.
> >> + * @bo: the VRAM buffer object
> >> + * Returns: The containing GEM VRAM object
> >> + */
> >> +static inline struct drm_gem_vram_object* drm_gem_vram_of_bo(
> >> +
The 50 ms default timeout waiting for vblanks is too small
for the first vblank from the ST-Ericsson MCDE display
controller over DSI. Presumably this is because the DSI
display is command-mode only and the state machine will
take some time setting up its state for the first display
update, and we
Query the max uvd handles and used uvd handles.
Signed-off-by: Satyajit Sahu
---
amdgpu/amdgpu.h | 14 ++
amdgpu/amdgpu_gpu_info.c | 15 +++
2 files changed, 29 insertions(+)
diff --git a/amdgpu/amdgpu.h b/amdgpu/amdgpu.h
index c44a495a..407b5fae 100644
---
On 4/30/2019 4:29 PM, Christian König wrote:
> [CAUTION: External Email]
>
> Am 30.04.19 um 12:51 schrieb Sahu, Satyajit:
>> Query the max uvd handles and used uvd handles.
>
> NAK, please use the generic amdgpu_query_info() function for this.
>
> Regards,
> Christian.
Currently
Hi Dave & Daniel,
Just one fix to fix Icelake CSC programming (fixes loss of blue channel).
Best Regards, Joonas
***
drm-intel-next-fixes-2019-04-30:
- Fix to Icelake CSC losing blue channel
The following changes since commit 447811a686e8da7325516a78069ccfbd139ef1a7:
drm/i915/icl: Fix
Hi,
thanks for the feedback.
Am 29.04.19 um 21:58 schrieb Sam Ravnborg:
> Hi Thomas.
>
> Some minor things and some bikeshedding too.
>
> One general^Wbikeshedding thing - unint32_t is used in many places.
> And then s64 in one place.
> Seems like two concepts are mixed.
> Maybe be consistent
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #14 from Christian Zigotzky ---
(In reply to Michel Dänzer from comment #13)
> (In reply to Christian Zigotzky from comment #12)
> > Any news? The issue still exists with the kernel 5.1-RC7.
>
> I wouldn't expect anything to happen
https://bugs.freedesktop.org/show_bug.cgi?id=109345
--- Comment #15 from Michel Dänzer ---
This is a platform specific issue. We cannot test on this platform, so someone
who can has to isolate the change causing the problem. I realize this may suck,
but it's reality.
--
You are receiving this
These barriers only apply to the read-modify-write operations; in
particular, they do not apply to the atomic_set() primitive.
Replace the barriers with smp_mb()s.
Fixes: b1fc2839d2f92 ("drm/msm: Implement preemption for A5XX targets")
Cc: sta...@vger.kernel.org
Reported-by: "Paul E. McKenney"
Imply the i2s part of the Synopsys HDMI driver for Amlogic SoCs.
This will enable the i2s part by default when meson hdmi driver
is enable but let platforms not supported by the audio subsystem
disable it if necessary.
Signed-off-by: Jerome Brunet
---
drivers/gpu/drm/meson/Kconfig | 1 +
1 file
On Fri, Apr 26, 2019 at 4:50 PM Catalin Marinas wrote:
>
> On Mon, Apr 01, 2019 at 06:44:34PM +0200, Andrey Konovalov wrote:
> > On Fri, Mar 22, 2019 at 4:41 PM Catalin Marinas
> > wrote:
> > > On Wed, Mar 20, 2019 at 03:51:24PM +0100, Andrey Konovalov wrote:
> > > > @@ -2120,13 +2135,14 @@
Allow to detect any connected display to be marked as
VRR capable. This is useful for testing the basics of
VRR mode, e.g., scheduling and timestamping, BTR, and
transition logic, on non-VRR capable displays, e.g.,
to perform IGT test-suit kms_vrr test runs.
This fake VRR display mode is enabled
https://bugs.freedesktop.org/show_bug.cgi?id=110031
Tom Hughes changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=109303
--- Comment #5 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- ICL: igt@i915_query@query-topology-known-pci-ids - skip - Test requirement:
IS_HASWELL(devid) || IS_BROADWELL(devid) || IS_SKYLAKE(devid) || -}
https://bugs.freedesktop.org/show_bug.cgi?id=110514
--- Comment #24 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- CML: all tests - skip - Test requirement: .*(gen|intel_gen(.*)) .*, SKIP -}
{+ CML: all tests - skip - Test requirement: .*(gen|intel_gen(.*))
The Synopsys MIPI DSI IP contains a video test pattern generator which
is helpful in debugging video timing with connected displays.
Add a debugfs directory containing files which allow the VPG to be
enabled and disabled, and its orientation to be changed.
Signed-off-by: Matt Redfearn
---
Hi,
This serie aims at adding the support for SMMU on Komeda driver.
Also updates the device-tree doc about how to enable SMMU by devicetree.
This patch series depends on:
- https://patchwork.freedesktop.org/series/58710/
- https://patchwork.freedesktop.org/series/59000/
-
Adds iommu_connect and disconnect for SMMU support, and configures
TBU translation once SMMU has been attached to the display device.
Signed-off-by: Lowry Li (Arm Technology China)
---
.../gpu/drm/arm/display/komeda/d71/d71_component.c | 5 +++
drivers/gpu/drm/arm/display/komeda/d71/d71_dev.c
Updates the device-tree doc about how to enable SMMU by devicetree.
Signed-off-by: Lowry Li (Arm Technology China)
---
Documentation/devicetree/bindings/display/arm,komeda.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/arm,komeda.txt
On Mon, Apr 22, 2019 at 03:16:26AM +, Lowry Li (Arm Technology China) wrote:
> - Adds rotation property to plane.
> - Komeda display rotation support diverges from the specific formats,
> so need to check the user required rotation type with the format caps
> and reject the commit if it can
On 2019-04-30 9:37 a.m., Mario Kleiner wrote:
> Allow to detect any connected display to be marked as
> VRR capable. This is useful for testing the basics of
> VRR mode, e.g., scheduling and timestamping, BTR, and
> transition logic, on non-VRR capable displays, e.g.,
> to perform IGT test-suit
https://bugs.freedesktop.org/show_bug.cgi?id=110514
--- Comment #23 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- CML: all tests - skip - Test requirement: .* (gen|intel_gen(.*)) = .*,
SKIP -}
{+ CML: all tests - skip - Test requirement:
heavy gpu job could occupy memory long time, which lead other user fail to get
memory.
basically pick up Christian idea:
1. Reserve the BO in DC using a ww_mutex ticket (trivial).
2. If we then run into this EBUSY condition in TTM check if the BO we need
memory for (or rather the ww_mutex of
On Mon, Apr 22, 2019 at 03:16:30AM +, Lowry Li (Arm Technology China) wrote:
> Komeda series hardware doesn't support Rot90 for AFBC wide block. So
> add limitation check to reject it if such configuration has been posted.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
>
On Tue, Apr 30, 2019 at 06:19:34AM +, Lowry Li (Arm Technology China) wrote:
> Updates the device-tree doc about how to enable SMMU by devicetree.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
> Documentation/devicetree/bindings/display/arm,komeda.txt | 7 +++
> 1 file
On Tue, Apr 30, 2019 at 06:19:29AM +, Lowry Li (Arm Technology China) wrote:
> Adds iommu_connect and disconnect for SMMU support, and configures
> TBU translation once SMMU has been attached to the display device.
>
> Signed-off-by: Lowry Li (Arm Technology China)
> ---
>
On 4/30/2019 5:02 PM, Christian König wrote:
> [CAUTION: External Email]
>
> Am 30.04.19 um 13:12 schrieb Sahu, Satyajit:
>> On 4/30/2019 4:29 PM, Christian König wrote:
>>> [CAUTION: External Email]
>>>
>>> Am 30.04.19 um 12:51 schrieb Sahu, Satyajit:
Query the max uvd handles and used uvd
+Rob, Eric, Mark and more
Hi,
On Fri, 5 Apr 2019 16:20:45 +0100
Steven Price wrote:
> On 04/04/2019 16:20, Boris Brezillon wrote:
> > Hello,
> >
> > This patch adds new ioctls to expose GPU counters to userspace.
> > These will be used by the mesa driver (should be posted soon).
> >
> > A
On Tue, Apr 30, 2019 at 5:41 AM Christian König
wrote:
>
> He unfortunately doesn't work for AMD any more.
>
> Signed-off-by: Christian König
Acked-by: Alex Deucher
> ---
> MAINTAINERS | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index
Am 29.04.19 um 10:24 schrieb Daniel Vetter:
On Fri, Apr 26, 2019 at 02:36:27PM +0200, Christian König wrote:
Add a structure for the parameters of dma_buf_attach, this makes it much easier
to add new parameters later on.
Signed-off-by: Christian König
---
drivers/dma-buf/dma-buf.c
On Tue, Apr 30, 2019 at 5:42 AM Boris Brezillon
wrote:
>
> +Rob, Eric, Mark and more
>
> Hi,
>
> On Fri, 5 Apr 2019 16:20:45 +0100
> Steven Price wrote:
>
> > On 04/04/2019 16:20, Boris Brezillon wrote:
> > > Hello,
> > >
> > > This patch adds new ioctls to expose GPU counters to userspace.
> >
Am 30.04.19 um 13:12 schrieb Sahu, Satyajit:
On 4/30/2019 4:29 PM, Christian König wrote:
[CAUTION: External Email]
Am 30.04.19 um 12:51 schrieb Sahu, Satyajit:
Query the max uvd handles and used uvd handles.
NAK, please use the generic amdgpu_query_info() function for this.
Regards,
Hey Chia-I,
This looks good to me, I can't find any spinlocks being held
during that allocation.
Reviewed-by: Robert Foss
On 30.04.19 00:10, Chia-I Wu wrote:
It was changed to GFP_ATOMIC in commit ec2f0577c (add & use
virtio_gpu_queue_fenced_ctrl_buffer) because the allocation happened
with
On 4/30/19 3:44 AM, Michel Dänzer wrote:
> [CAUTION: External Email]
>
> On 2019-04-30 9:37 a.m., Mario Kleiner wrote:
>> Allow to detect any connected display to be marked as
>> VRR capable. This is useful for testing the basics of
>> VRR mode, e.g., scheduling and timestamping, BTR, and
>>
Am 30.04.19 um 14:03 schrieb Sahu, Satyajit:
> On 4/30/2019 5:02 PM, Christian König wrote:
>> [CAUTION: External Email]
>>
>> Am 30.04.19 um 13:12 schrieb Sahu, Satyajit:
>>> On 4/30/2019 4:29 PM, Christian König wrote:
[CAUTION: External Email]
Am 30.04.19 um 12:51 schrieb Sahu,
On Tue, Apr 30, 2019 at 03:42:22PM +0200, Christian König wrote:
> Am 29.04.19 um 10:40 schrieb Daniel Vetter:
> > On Fri, Apr 26, 2019 at 02:36:28PM +0200, Christian König wrote:
> > > Add optional explicit pinning callbacks instead of implicitly assume the
> > > exporter pins the buffer when a
On Fri, Apr 26, 2019 at 02:36:36PM +0200, Christian König wrote:
> The caching of SGT's is actually quite harmful and should probably removed
> altogether when all drivers are audited.
>
> Start by providing a separate DMA-buf export implementation in amdgpu. This is
> also a prerequisite of
On Fri, Apr 26, 2019 at 02:36:29PM +0200, Christian König wrote:
> To allow a smooth transition from pinning buffer objects to dynamic
> invalidation we first start to cache the sg_table for an attachment
> unless the driver has implemented the explicite pin/unpin callbacks.
>
> Signed-off-by:
On Mon, Apr 29, 2019 at 09:58:55PM +0200, Sam Ravnborg wrote:
> Hi Thomas.
>
> Some minor things and some bikeshedding too.
>
> One general^Wbikeshedding thing - unint32_t is used in many places.
> And then s64 in one place.
> Seems like two concepts are mixed.
> Maybe be consistent and use u32,
Am 30.04.19 um 15:59 schrieb Daniel Vetter:
On Tue, Apr 30, 2019 at 03:42:22PM +0200, Christian König wrote:
Am 29.04.19 um 10:40 schrieb Daniel Vetter:
On Fri, Apr 26, 2019 at 02:36:28PM +0200, Christian König wrote:
[SNIP]
+/**
+ * dma_buf_pin - Lock down the DMA-buf
+ *
+ * @dmabuf:
https://bugs.freedesktop.org/show_bug.cgi?id=110509
--- Comment #13 from Michel Dänzer ---
(In reply to James.Dutton from comment #12)
> In function: amdgpu_cs_parser_init:
> if (p->ctx->vram_lost_counter != p->job->vram_lost_counter) {
> ret = -ECANCELED;
>
On Tue, Apr 30, 2019 at 04:26:32PM +0200, Christian König wrote:
> Am 30.04.19 um 15:59 schrieb Daniel Vetter:
> > On Tue, Apr 30, 2019 at 03:42:22PM +0200, Christian König wrote:
> > > Am 29.04.19 um 10:40 schrieb Daniel Vetter:
> > > > On Fri, Apr 26, 2019 at 02:36:28PM +0200, Christian König
Am 29.04.19 um 10:40 schrieb Daniel Vetter:
On Fri, Apr 26, 2019 at 02:36:28PM +0200, Christian König wrote:
Add optional explicit pinning callbacks instead of implicitly assume the
exporter pins the buffer when a mapping is created.
v2: move in patchset and pin the dma-buf in the old mapping
https://bugs.freedesktop.org/show_bug.cgi?id=110509
--- Comment #12 from james.dut...@gmail.com ---
The error is from this bit of code in:
amdgpu_cs.c: Line about 232
In function: amdgpu_cs_parser_init:
if (p->ctx->vram_lost_counter != p->job->vram_lost_counter) {
ret =
73 matches
Mail list logo
