https://bugs.freedesktop.org/show_bug.cgi?id=107153
--- Comment #17 from Patrik Kullman ---
Created attachment 140685
--> https://bugs.freedesktop.org/attachment.cgi?id=140685&action=edit
4.18-rc5 dmesg with debug (-freesync)
Could also not build with freesync.
Mine seem to crash a lot faster
https://bugs.freedesktop.org/show_bug.cgi?id=107153
--- Comment #16 from Peter ---
Created attachment 140681
--> https://bugs.freedesktop.org/attachment.cgi?id=140681&action=edit
Dmesg with patch minus freesync
The kernel wouldn't build with that patch. It doesn't seem to recognize the
freesyn
https://bugzilla.kernel.org/show_bug.cgi?id=200531
--- Comment #1 from Alexander Mezin (mezin.alexan...@gmail.com) ---
I was wrong, it's not a regression. it's happening since the moment I upgraded
from rx 580 to vega
--
You are receiving this mail because:
You are watching the assignee of the b
https://bugzilla.kernel.org/show_bug.cgi?id=200531
Alexander Mezin (mezin.alexan...@gmail.com) changed:
What|Removed |Added
Regression|Yes |No
--
You
https://bugzilla.kernel.org/show_bug.cgi?id=200531
Alexander Mezin (mezin.alexan...@gmail.com) changed:
What|Removed |Added
Regression|No |Yes
--
You
https://bugzilla.kernel.org/show_bug.cgi?id=200531
Bug ID: 200531
Summary: amdgpu: *ERROR* REG_WAIT timeout when a display is put
to sleep
Product: Drivers
Version: 2.5
Kernel Version: 4.17.6
Hardware: x86-64
There is a member of a struct that doesn't look to be used anywhere.
(just noticed in passing).
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
On Tue, 2018-07-17 at 15:34 -0700, Dhinakaran Pandiyan wrote:
> On Tue, 2018-07-17 at 14:49 -0700, matthew.s.atw...@intel.com wrote:
> >
> > From: Matt Atwood
> >
> > According to DP spec (2.9.3.1 of DP 1.4) if
> > EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in
> > DPCD
> > 0
On Tue, Jul 17, 2018 at 03:34:35PM -0700, Dhinakaran Pandiyan wrote:
> On Tue, 2018-07-17 at 14:49 -0700, matthew.s.atw...@intel.com wrote:
> > From: Matt Atwood
> >
> > According to DP spec (2.9.3.1 of DP 1.4) if
> > EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in
> > DPCD
> >
On Tue, 2018-07-17 at 14:49 -0700, matthew.s.atw...@intel.com wrote:
> From: Matt Atwood
>
> According to DP spec (2.9.3.1 of DP 1.4) if
> EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in
> DPCD
> 02200h through 0220Fh shall contain the DPRX's true capability. These
> values wil
From: Matthias Brugger
It can happen that the clock drivers wasn't probed before the
ddp driver gets invoked. The driver used to omit a warning
that the driver failed to get the clocks. Omit this error on
the defered probe path.
Signed-off-by: Matthias Brugger
Acked-by: CK Hu
---
drivers/gpu/
Changes since v3:
- use platform device to probe clock driver
- add Acked-by CK Hu for the probe deferred patch
Changes since v2:
- fix kconfig typo (shame on me)
- delete __initconst from mm_clocks as converted to a platform driver
Changes since v1:
- add binding documentation
- ddp: use regma
From: Matthias Brugger
The mmsys memory space is shared between the drm and the
clk driver. Use regmap to access it.
Signed-off-by: Matthias Brugger
Reviewed-by: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +--
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 38 ++
From: Matthias Brugger
The MMSYS subsystem includes clocks and drm components.
This patch adds an initailization path through a platform device
for the clock part, so that both drivers get probed from the same
device tree compatible.
Signed-off-by: Matthias Brugger
---
drivers/gpu/drm/mediatek
From: Matthias Brugger
Switch probing for the MMSYS to support invocation to a
plain paltform device. The driver will be probed by the DRM subsystem.
Signed-off-by: Matthias Brugger
---
drivers/clk/mediatek/clk-mt8173.c | 51 ++-
1 file changed, 44 insertions(+), 7
From: Matthias Brugger
Switch probing for the MMSYS to support invocation to a plain
paltform device. The driver will be probed by the DRM subsystem.
Signed-off-by: Matthias Brugger
---
drivers/clk/mediatek/clk-mt2701-mm.c | 42
1 file changed, 30 insertions(+), 12
From: Matthias Brugger
It can happen that the clock drivers wasn't probed before the
ddp driver gets invoked. The driver used to omit a warning
that the driver failed to get the clocks. Omit this error on
the defered probe path.
Signed-off-by: Matthias Brugger
Acked-by: CK Hu
---
drivers/gpu/
From: Matthias Brugger
Switch probing for the MMSYS to support invocation to a plain
paltform device. The driver will be probed by the DRM subsystem.
Signed-off-by: Matthias Brugger
---
drivers/clk/mediatek/clk-mt2701-mm.c | 42
1 file changed, 30 insertions(+), 12
From: Matthias Brugger
Switch probing for the MMSYS to support invocation to a
plain paltform device. The driver will be probed by the DRM subsystem.
Signed-off-by: Matthias Brugger
---
drivers/clk/mediatek/clk-mt8173.c | 51 ++-
1 file changed, 44 insertions(+), 7
From: Matthias Brugger
The MMSYS subsystem includes clocks and drm components.
This patch adds an initailization path through a platform device
for the clock part, so that both drivers get probed from the same
device tree compatible.
Signed-off-by: Matthias Brugger
---
drivers/gpu/drm/mediatek
From: Matthias Brugger
The mmsys memory space is shared between the drm and the
clk driver. Use regmap to access it.
Signed-off-by: Matthias Brugger
Reviewed-by: Philipp Zabel
---
drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 4 +--
drivers/gpu/drm/mediatek/mtk_drm_ddp.c | 38 ++
Changes since v3:
- use platform device to probe clock driver
- add Acked-by CK Hu for the probe deferred patch
Changes since v2:
- fix kconfig typo (shame on me)
- delete __initconst from mm_clocks as converted to a platform driver
Changes since v1:
- add binding documentation
- ddp: use regma
From: Matt Atwood
According to DP spec (2.9.3.1 of DP 1.4) if
EXTENDED_RECEIVER_CAPABILITY_FIELD_PRESENT is set the addresses in DPCD
02200h through 0220Fh shall contain the DPRX's true capability. These
values will match 0h through Fh, except for DPCD_REV,
MAX_LINK_RATE, DOWN_STREAM_PORT
From: Matt Atwood
This bit was added to DP Training Aux RD interval sometime between DP
1.2 and DP 1.3. Via description of the spec this field indicates the
panels true capabilities are described in DPCD address space 02200h
through 022FFh.
Signed-off-by: Matt Atwood
---
include/drm/drm_dp_hel
https://bugs.freedesktop.org/show_bug.cgi?id=107153
Leo Li changed:
What|Removed |Added
Attachment #140677|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=107153
Leo Li changed:
What|Removed |Added
Attachment #140613|0 |1
is obsolete|
On Tue, Jul 17, 2018 at 04:43:16PM -0400, Sean Paul wrote:
> On Tue, Jul 17, 2018 at 02:52:20AM +0300, Haneen Mohammed wrote:
> > On Mon, Jul 16, 2018 at 02:22:56PM -0400, Sean Paul wrote:
> > > On Sat, Jul 14, 2018 at 03:23:32PM +0300, Haneen Mohammed wrote:
> > > > Implement the set_crc_source()
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #11 from bakarichar...@gmail.com ---
I played Vietcong but the GPU hasn't switched, is that okay? Is there any way
to monitor frequencies? However temperature seems to be OK now.
--
You are receiving this mail because:
You are watchi
https://bugs.freedesktop.org/show_bug.cgi?id=107266
--- Comment #1 from Alex Deucher ---
Please attach your full dmesg output. Are you attempting to use ROCm over the
drm-next-4.19-wip kernel?
--
You are receiving this mail because:
You are the assignee for the bug.
On Tue, Jul 17, 2018 at 02:52:20AM +0300, Haneen Mohammed wrote:
> On Mon, Jul 16, 2018 at 02:22:56PM -0400, Sean Paul wrote:
> > On Sat, Jul 14, 2018 at 03:23:32PM +0300, Haneen Mohammed wrote:
> > > Implement the set_crc_source() callback.
> > > Compute CRC using crc32 on the visible part of the
https://bugs.freedesktop.org/show_bug.cgi?id=107266
Bug ID: 107266
Summary: Radeon Pro Duo (Polaris) - ring sdma0 timeout
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Hi Laurent,
On 17/07/18 14:51, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Monday, 16 July 2018 20:20:30 EEST Kieran Bingham wrote:
>> On 24/05/18 12:50, Laurent Pinchart wrote:
>>> On Thursday, 3 May 2018 16:36:22 EEST Kieran Bingham wrote:
Use the newly exposed VSP1 interface to enable int
On Tue, Jul 17, 2018 at 12:21:03PM +0100, Jean-Philippe Brucker wrote:
> Hi Jordan,
>
> Thanks for the patches, I finally got around testing them with SMMUv3.
> It's an important feature, arguably more than SVA itself. I could pick
> this one as part of the SVA series, what do you think?
I'm good
.
>
> drm_context_t is actually just used in a few placed so the type could be
> changed but it is also exported via tools/include/uapi/drm/drm.h so
> changing the typedef of drm_context_t could break applications and thus
> this is not an option.
>
> Patch was compile test
On Tue, Jul 17, 2018 at 11:26:50AM +0200, Takashi Iwai wrote:
> For allowing other drivers to use the DRM audio component, rename the
> i915_audio_component_* with drm_audio_component_*, and split the
> generic part into drm_audio_component.h. The i915 specific stuff
> remains in struct i915_audio
Quoting Souza, Jose (2018-07-17 18:02:17)
> On Tue, 2018-07-17 at 08:28 +0100, Chris Wilson wrote:
> > Quoting José Roberto de Souza (2018-07-16 23:38:36)
> > > GPU accelerators usually don't have display block or the display
> > > driver part can be disable when building driver(for servers it save
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #10 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to Alex Deucher from comment #2)
> Duplicate of:
> https://bugs.freedesktop.org/show_bug.cgi?id=105760
This is apparently not a duplicate of that bug. Similar symptoms, but
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to bakarichard91 from comment #8)
> Hi, I've patched it and it loads perfectly without any additional
> parameters. I'm checking the temperature now.
>
> Will this ever be mer
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #8 from bakarichar...@gmail.com ---
Hi, I've patched it and it loads perfectly without any additional parameters.
I'm checking the temperature now.
Will this ever be merged to the "master"?
Thanks for the help. The support of linux i
Thomas Zimmermann writes:
> This patch unifies the naming of DRM functions for reference counting
> of struct drm_device. The resulting code is more aligned with the rest
> of the Linux kernel interfaces.
Pushed to drm-misc-next. Thanks!
signature.asc
Description: PGP signature
__
Thomas Zimmermann writes:
> This patch unifies the naming of DRM functions for reference counting
> of struct drm_device. The resulting code is more aligned with the rest
> of the Linux kernel interfaces.
>
> Signed-off-by: Thomas Zimmermann
Pushed to drm-misc-next. Thanks!
signature.asc
Des
"Gustavo A. R. Silva" writes:
> Add suffix ULL to constant 1000 in order to give the compiler complete
> information about the proper arithmetic to use.
>
> Notice that such constant is used in a context that expects an
> expression of type u64 (64 bits, unsigned) and the following
> expression i
On Tue, 2018-07-17 at 20:32 +0200, Lukas Wunner wrote:
> On Tue, Jul 17, 2018 at 02:24:31PM -0400, Lyude Paul wrote:
> > On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote:
> > > Okay, the PCI device is suspending and the nvkm_i2c_aux_acquire()
> > > wants it in resumed state, so is waiting fore
On Tue, Jul 17, 2018 at 02:24:31PM -0400, Lyude Paul wrote:
> On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote:
> > Okay, the PCI device is suspending and the nvkm_i2c_aux_acquire()
> > wants it in resumed state, so is waiting forever for the device to
> > runtime suspend in order to resume it
On Tue, 2018-07-17 at 20:20 +0200, Lukas Wunner wrote:
> On Tue, Jul 17, 2018 at 12:53:11PM -0400, Lyude Paul wrote:
> > On Tue, 2018-07-17 at 09:16 +0200, Lukas Wunner wrote:
> > > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote:
> > > > In order to fix all of the spots that need to hav
On Tue, Jul 17, 2018 at 12:53:11PM -0400, Lyude Paul wrote:
> On Tue, 2018-07-17 at 09:16 +0200, Lukas Wunner wrote:
> > On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote:
> > > In order to fix all of the spots that need to have runtime PM get/puts()
> > > added, we need to ensure that it'
Use the stronger compiler.link() test (instead of the weaker
compiler.compile()) to fix the intel atomics detection.
Fixes false positive in case of sparc compile (buildroot toolchain).
Signed-off-by: Peter Seiderer
---
meson.build | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --g
https://bugs.freedesktop.org/show_bug.cgi?id=107263
--- Comment #1 from Christian König ---
We can certainly reduce the time amdgpu needs to load, but I'm not sure that we
can get under 100ms.
See on the hardware side when switching between power states we need some delay
before the clocks/volta
Hi Kieran,
On Tuesday, 17 July 2018 19:08:44 EEST Kieran Bingham wrote:
> On 17/07/18 13:52, Laurent Pinchart wrote:
> > On Monday, 16 July 2018 21:21:00 EEST Kieran Bingham wrote:
> >> On 24/05/18 13:51, Laurent Pinchart wrote:
> >>> On Thursday, 3 May 2018 16:36:21 EEST Kieran Bingham wrote:
> >
drm_format_info table has a field 'is_yuv' to denote if the format
is yuv or not. The driver is expected to use this instead of
having a function for the same purpose.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/omapdrm/dss/dispc.c | 26 ++
1 file changed, 10 ins
drm_format_info table has a field 'is_yuv' to denote if the format
is yuv or not. The driver is expected to use this instead of
having a function for the same purpose.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/sun4i/sun4i_backend.c | 12 +++-
1 file changed, 3 insertions(+), 9
drm_format_info table has a field 'is_yuv' to denote if the format
is yuv or not. The driver is expected to use this instead of
having a function for the same purpose.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_drv.h | 2 --
drm_format_info table has a field 'is_yuv' to denote if the format
is yuv or not. The driver is expected to use this instead of
having a function for the same purpose.
Signed-off-by: Ayan Kumar halder
---
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 24 +---
1 file changed,
A lot of drivers duplicate the function to check if a format is yuv or not.
If we add a field (to denote whether the format is yuv or not) in the
drm_format_info table, all the drivers can use this field and it will
prevent duplication of similar logic.
Signed-off-by: Ayan Kumar halder
---
drive
The driver for LD9040 AMOLED LCD panel was superseded with DRM driver
panel-samsung-ld9040.c. It does not support DeviceTree and respective
possible user (Exynos4210 Universal C210) is DeviceTree-only and uses
DRM version of driver.
Suggested-by: Marek Szyprowski
Cc: Marek Szyprowski
Cc: Inki D
The driver for S6E63M0 AMOLED LCD panel is not used. It does not
support DeviceTree and respective possible users (S5Pv210 Aquila and
Goni boards) are DeviceTree-only.
Suggested-by: Marek Szyprowski
Cc: Marek Szyprowski
Cc: Inki Dae
Signed-off-by: Krzysztof Kozlowski
Acked-by: Jingoo Han
Ack
On Tue, 2018-07-17 at 08:28 +0100, Chris Wilson wrote:
> Quoting José Roberto de Souza (2018-07-16 23:38:36)
> > GPU accelerators usually don't have display block or the display
> > driver part can be disable when building driver(for servers it save
> > some resources) so it is important let usersp
On Tue, 2018-07-17 at 09:16 +0200, Lukas Wunner wrote:
> [cc += linux-pm]
>
> Hi Lyude,
>
> First of all, thanks a lot for looking into this.
>
> On Mon, Jul 16, 2018 at 07:59:25PM -0400, Lyude Paul wrote:
> > In order to fix all of the spots that need to have runtime PM get/puts()
> > added, w
https://bugs.freedesktop.org/show_bug.cgi?id=107153
--- Comment #13 from Patrik Kullman ---
Interesting, thanks Peter!
I don't quite have the same combos, booting with receiver and TV on still
crashes the driver. I'll try some with this as well.
I have now tried rc5 and bug is still present.
An
On Tue, Jul 17, 2018 at 5:29 AM, Colin King wrote:
> From: Colin Ian King
>
> Trivial fix to spelling mistake in dev_err error message.
>
> Signed-off-by: Colin Ian King
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 10 +-
> 1 file changed, 5 insertions
Hi Laurent,
On 17/07/18 13:52, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Monday, 16 July 2018 21:21:00 EEST Kieran Bingham wrote:
>> On 24/05/18 13:51, Laurent Pinchart wrote:
>>> On Thursday, 3 May 2018 16:36:21 EEST Kieran Bingham wrote:
Calculate the top and bottom fields for the interl
https://bugs.freedesktop.org/show_bug.cgi?id=107263
Alex Deucher changed:
What|Removed |Added
Severity|normal |enhancement
--
You are receiving this m
Hi Laurent,
Thanks for your review comments.
These were easier to go through than patch 8 :D
On 24/05/18 13:12, Laurent Pinchart wrote:
> Hi Kieran,
>
> Thank you for the patch.
>
> On Thursday, 3 May 2018 16:36:20 EEST Kieran Bingham wrote:
>> VSPD and VSP-DL devices can provide extended disp
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #7 from Alex Deucher (alexdeuc...@gmail.com) ---
Created attachment 277375
--> https://bugzilla.kernel.org/attachment.cgi?id=277375&action=edit
possible fix
Does this patch fix the issue?
--
You are receiving this mail because:
Yo
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #6 from bakarichar...@gmail.com ---
Created attachment 277373
--> https://bugzilla.kernel.org/attachment.cgi?id=277373&action=edit
dmesg full
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #5 from bakarichar...@gmail.com ---
Created attachment 277371
--> https://bugzilla.kernel.org/attachment.cgi?id=277371&action=edit
lspci -nn
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #4 from bakarichar...@gmail.com ---
Hi,
Sorry for the duplication. It's worth to mention that APIC problems occured too
which have been fixed using kernel parameters. (manual pci addressing)
--
You are receiving this mail because:
Y
On Tue, Jul 17, 2018 at 02:25:22PM +0200, Paul Kocialkowski wrote:
> Blending order is set based on the z position of each DRM plane. The
> blending order register is currently cleared at each atomic DRM commit,
> with the intent that each committed plane will set the appropriate
> bits (based on i
Hi Daniel,
On Mon, Jul 9, 2018 at 10:44 AM Daniel Vetter wrote:
> Avoids the inverted check compared to the open-coded version.
>
> Signed-off-by: Daniel Vetter
> Cc: Finn Thain
> Cc: linux-m...@lists.linux-m68k.org
Thanks for your patch!
> --- a/include/linux/nubus.h
> +++ b/include/linux/nu
https://bugzilla.kernel.org/show_bug.cgi?id=200517
--- Comment #3 from Alex Deucher (alexdeuc...@gmail.com) ---
Please attach your full dmesg output from boot and `lspci -nn` output.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=200517
Alex Deucher (alexdeuc...@gmail.com) changed:
What|Removed |Added
CC||alexdeuc...@gmail.c
https://bugs.freedesktop.org/show_bug.cgi?id=107262
--- Comment #3 from Paul Menzel ---
Thank you for the explanation. Could the message then please be improved to not
cause confusion?
--
You are receiving this mail because:
You are the assignee for the bug._
Hi Laurent,
On 17/07/18 11:53, Laurent Pinchart wrote:
> Hi Kieran,
>
> On Monday, 16 July 2018 20:14:55 EEST Kieran Bingham wrote:
>> On 24/05/18 12:44, Laurent Pinchart wrote:
>>> On Thursday, 3 May 2018 16:36:19 EEST Kieran Bingham wrote:
Extended display list headers allow pre and post c
https://bugs.freedesktop.org/show_bug.cgi?id=107262
Alex Deucher changed:
What|Removed |Added
Resolution|--- |NOTABUG
Status|NEW
Hi Laurent,
>>> +static void vsp1_rpf_configure_autofld(struct vsp1_rwpf *rpf,
>>> + struct vsp1_dl_ext_cmd *cmd)
>>> +{
>>> + const struct v4l2_pix_format_mplane *format = &rpf->format;
>>> + struct vsp1_extcmd_auto_fld_body *auto_fld = cmd->data;
>>> + u3
Hi Daniel,
On Fri, 2018-07-13 at 10:38 +0200, Daniel Vetter wrote:
> On Fri, Jul 13, 2018 at 10:09 AM, Lucas Stach wrote:
> > Hi Daniel,
> >
> > Am Mittwoch, den 11.07.2018, 20:07 +0200 schrieb Daniel Vetter:
> > > Hi all,
> > >
> > > I chatted a bit with Thierry about drm-panel, and state of t
On Tue, Jul 17, 2018 at 1:47 AM Linus Walleij wrote:
>
> On Tue, Jul 17, 2018 at 12:50 AM Rob Herring wrote:
> > On Mon, Jul 16, 2018 at 3:23 AM Linus Walleij
> > wrote:
>
> > > +Video Graphics Array
> >
> > VGA is more a controller interface than a panel...
>
> I don't know what else to call i
On Tue, 2018-07-17 at 14:25 +0200, Paul Kocialkowski wrote:
> Blending order is set based on the z position of each DRM plane. The
> blending order register is currently cleared at each atomic DRM commit,
> with the intent that each committed plane will set the appropriate
> bits (based on its z-po
Hi Kieran,
On Monday, 16 July 2018 20:20:30 EEST Kieran Bingham wrote:
> On 24/05/18 12:50, Laurent Pinchart wrote:
> > On Thursday, 3 May 2018 16:36:22 EEST Kieran Bingham wrote:
> >> Use the newly exposed VSP1 interface to enable interlaced frame support
> >> through the VSP1 lif pipelines.
> >
thus
this is not an option.
Patch was compile tested with: x86_64_defconfig
Patch is against 4.18-rc4 (localversion-next is next-20180717)
drivers/gpu/drm/drm_context.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_context.c b/drivers/gpu/drm/drm
On Tue, 2018-07-17 at 15:11 +0300, Leonard Crestez wrote:
> This has been unused since commit 44b460cfe554 ("drm: imx: remove struct
> imx_drm_crtc and imx_drm_crtc_helper_funcs")
>
> Signed-off-by: Leonard Crestez
Applied to imx-drm/next, thank you.
> ---
> drivers/gpu/drm/imx/imx-drm-core.c
Hi Kieran,
On Monday, 16 July 2018 21:21:00 EEST Kieran Bingham wrote:
> On 24/05/18 13:51, Laurent Pinchart wrote:
> > On Thursday, 3 May 2018 16:36:21 EEST Kieran Bingham wrote:
> >> Calculate the top and bottom fields for the interlaced frames and
> >> utilise the extended display list command
https://bugs.freedesktop.org/show_bug.cgi?id=107263
Bug ID: 107263
Summary: Decrease start-up time of amdgpu_init from 390 ms to
under 100 ms
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Hi Sébastien,
On Tue, Jul 17, 2018 at 4:23 AM, Sébastien Szymanski
wrote:
> This patch adds support for the Armadeus ST0700 Adapt. It comes with a
> Santek ST0700I5Y-RBSLW 7.0" WVGA (800x480) TFT and an adapter board so
> that it can be connected on the TFT header of Armadeus Dev boards.
>
> Sign
Blending order is set based on the z position of each DRM plane. The
blending order register is currently cleared at each atomic DRM commit,
with the intent that each committed plane will set the appropriate
bits (based on its z-pos) when enabling the plane.
However, it sometimes happens that a pa
On Tue, Jul 17, 2018 at 10:52:30AM +0200, Paul Kocialkowski wrote:
> Not all sunxi platforms with the first version of the Display Engine
> support an alpha component on the plane with the lowest z position
> (as in: lowest z-pos), that gets blended with the background color.
>
> In particular, th
On Tue, Jul 17, 2018 at 1:54 PM, Ben Skeggs wrote:
> On Tue, 17 Jul 2018 at 20:18, Karol Herbst wrote:
>>
>> mhh, we shouldn't call to Linux APIs from within of nvkm. Rather gaurd
>> the Linux glue code to the i2c stuff instead, but this is all done
>> from inside of nvkm. I think we should move
https://bugs.freedesktop.org/show_bug.cgi?id=107262
Paul Menzel changed:
What|Removed |Added
CC||pmenzel+bugs.freedesktop@mo
https://bugs.freedesktop.org/show_bug.cgi?id=107262
Bug ID: 107262
Summary: [drm] BIOS signature incorrect 0 0 with Ryzen 3 2200g
Product: DRI
Version: DRI git
Hardware: Other
OS: All
Status: NEW
Severity:
On Tue, Jul 17, 2018 at 10:48:14AM +0200, Thomas Zimmermann wrote:
> This patch unifies the naming of DRM functions for reference counting
> of struct drm_device. The resulting code is more aligned with the rest
> of the Linux kernel interfaces.
>
> Signed-off-by: Thomas Zimmermann
Applied, than
On Tue, 17 Jul 2018 at 20:18, Karol Herbst wrote:
>
> mhh, we shouldn't call to Linux APIs from within of nvkm. Rather gaurd
> the Linux glue code to the i2c stuff instead, but this is all done
> from inside of nvkm. I think we should move it out into
> drm/nouveau/nouveau_i2c.c and do the handlin
https://bugs.freedesktop.org/show_bug.cgi?id=107261
Bug ID: 107261
Summary: [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT
timeout 1us * 10 tries - optc1_lock line:628
Product: DRI
Version: DRI git
Hardware: Other
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/zte/zx_drm_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletion
This patch unifies the naming of DRM functions for reference counting
of struct drm_device. The resulting code is more aligned with the rest
of the Linux kernel interfaces.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 4 ++--
1 file changed, 2 insertions(+),
Hi Kieran,
On Monday, 16 July 2018 20:14:55 EEST Kieran Bingham wrote:
> On 24/05/18 12:44, Laurent Pinchart wrote:
> > On Thursday, 3 May 2018 16:36:19 EEST Kieran Bingham wrote:
> >> Extended display list headers allow pre and post command lists to be
> >> executed by the VSP pipeline. This prov
On Tue, Jul 17, 2018 at 09:33:52AM +0200, Lukas Wunner wrote:
> On Thu, Jul 12, 2018 at 01:02:53PM -0400, Lyude Paul wrote:
> > --- a/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c
> > @@ -1878,7 +1878,7 @@ nv50_disp_atomic_commit(struct drm_device *dev,
>
Reviewed-by: Karol Herbst
2018-07-12 19:13 GMT+02:00 Lyude Paul :
> This makes debugging with DP tracing a lot harder to interpret, so name
> each i2c based off the name of the encoder that it's for
>
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +-
> dri
isn't there like 1 space missing for each change? Or maybe my client
is messed up, but please align it with the first letter of the
parameters not the "(".
With that fixed: Reviewed-by: Karol Herbst
On Tue, Jul 17, 2018 at 2:07 AM, Lyude Paul wrote:
> Signed-off-by: Lyude Paul
> ---
> drivers
On Tue, 2018-07-17 at 10:35 +0200, Thomas Zimmermann wrote:
> This patch unifies the naming of DRM functions for reference counting
> of struct drm_device. The resulting code is more aligned with the rest
> of the Linux kernel interfaces.
>
> Signed-off-by: Thomas Zimmermann
> ---
> drivers/gpu/
mhh, we shouldn't call to Linux APIs from within of nvkm. Rather gaurd
the Linux glue code to the i2c stuff instead, but this is all done
from inside of nvkm. I think we should move it out into
drm/nouveau/nouveau_i2c.c and do the handling there.
On Tue, Jul 17, 2018 at 1:59 AM, Lyude Paul wrote:
1 - 100 of 156 matches
Mail list logo