On Tue, Dec 18, 2018 at 8:15 AM Andrzej Hajda wrote:
>
> On 17.12.2018 15:46, Daniel Vetter wrote:
> > On Mon, Dec 17, 2018 at 10:54:48AM +0100, Andrzej Hajda wrote:
> >> Hi Daniel,
> >>
> >> Thanks for reviewing other two patches.
> >>
> >>
> >> On 14.12.2018 17:29, Daniel Vetter wrote:
> >>> On
On 12/14/18 10:35 AM, Daniel Vetter wrote:
On Fri, Dec 14, 2018 at 09:09:45AM +0200, Oleksandr Andrushchenko wrote:
On 12/13/18 5:48 PM, Daniel Vetter wrote:
On Thu, Dec 13, 2018 at 12:17:54PM +0200, Oleksandr Andrushchenko wrote:
Daniel, could you please comment?
Cross-revieweing someone els
The gem drivers use shmemfs to allocate backing storage for gem objects.
On Samsung Chromebook Plus, the drm/rockchip driver may call
rockchip_gem_get_pages -> drm_gem_get_pages -> shmem_read_mapping_page
to pin a lot of pages, breaking the page reclaim mechanism and causing
oom-killer invocation.
On Thu, Dec 13, 2018 at 11:35:33PM -0200, Helen Koike wrote:
> Hello,
>
> On 12/13/18 7:01 AM, Daniel Vetter wrote:
> > On Thu, Dec 13, 2018 at 04:43:57PM +0900, Tomasz Figa wrote:
> >> Hi Helen,
> >>
> >> On Sat, Nov 24, 2018 at 6:54 AM Helen Koike
> >> wrote:
> >>>
> >>> This flag tells core t
On Sat, Dec 15, 2018 at 09:20:38PM +, Winkler, Tomas wrote:
> >
> > On Thu, Dec 13, 2018 at 5:27 PM Winkler, Tomas
> > wrote:
> > >
> > > > On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam
> > > >
> > > > wrote:
> > > > >
> > > > > Tomas and Daniel,
> > > > >
> > > > > We got an issue here.
> >
On Mon, Dec 17, 2018 at 10:00:38AM +0300, Dan Carpenter wrote:
> The drm_mode_create_tile_group() is only called from
> drm_parse_tiled_block() and the caller expects it to return a NULL on
> error. In other words, this function should match
> drm_mode_get_tile_group().
>
> Signed-off-by: Dan Car
On Mon, Dec 17, 2018 at 10:03:44AM +0300, Dan Carpenter wrote:
> The drm_ati_pcigart_init() function was originally suppose to return one
> on success and zero on failure, but these days it returns a mix of
> zero, one and -ENOMEM on failure.
>
> This patch cleans it up and modifies the caller so
On Thu, Dec 13, 2018 at 01:55:25PM -0800, Matt Roper wrote:
> Some hardware may place additional restrictions on the gamma/degamma
> curves described by our LUT properties. E.g., that a gamma curve never
> decreases or that the red/green/blue channels of a LUT's entries must be
> equal. Let's add
On Fri, Dec 14, 2018 at 11:11:05PM +0100, Daniel Vetter wrote:
> On Fri, Dec 14, 2018 at 11:44:10AM +0100, Lucas Stach wrote:
> > Hi Dave,
> >
> > nothing major this time, mostly some cleanups that were found on the
> > way of reworking the code in preparation for new feature additions.
>
> dim:
On Sun, Dec 16, 2018 at 06:49:08PM +, emersion wrote:
> Otherwise DRM_CAP_DUMB_PREFERRED_DEPTH is zero.
>
> Signed-off-by: Simon Ser
Thanks for your patch, applied.
-Daniel
> ---
> drivers/gpu/drm/vkms/vkms_drv.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/vkm
Hi Daniel,
Thanks for reviewing other two patches.
On 14.12.2018 17:29, Daniel Vetter wrote:
> On Fri, Dec 14, 2018 at 02:38:52PM +0100, Andrzej Hajda wrote:
>> rr_cache_dir function cannot assume REPO/.git is a directory. On the other
>> side it should be backward compatible - if rr-cache direc
On Mon, Dec 17, 2018 at 10:39:07AM +0100, Daniel Vetter wrote:
> On Sat, Dec 15, 2018 at 09:20:38PM +, Winkler, Tomas wrote:
> > >
> > > On Thu, Dec 13, 2018 at 5:27 PM Winkler, Tomas
> > > wrote:
> > > >
> > > > > On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam
> > > > >
> > > > > wrote:
> >
https://bugs.freedesktop.org/show_bug.cgi?id=108992
--- Comment #12 from Michel Dänzer ---
Make sure you've tested a commit plenty before declaring it "good".
--
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel maili
Am Fr., 14. Dez. 2018 um 11:44 Uhr schrieb Lucas Stach :
>
> Hi Dave,
>
> nothing major this time, mostly some cleanups that were found on the
> way of reworking the code in preparation for new feature additions.
>
> Regards,
> Lucas
>
> The following changes since commit 6fce3a406108ee6c8a61e2a33e
Hello, Juergen, Boris!
As this DRM part of the series is the only one which needs ack/nack
(and it might take quite some time to complete) could we please
merge the patches 1 and 3 now that already have ack/r-b?
Thank you,
Oleksandr
On 12/13/18 12:16 PM, Oleksandr Andrushchenko wrote:
bump
The drm_mode_create_tile_group() is only called from
drm_parse_tiled_block() and the caller expects it to return a NULL on
error. In other words, this function should match
drm_mode_get_tile_group().
Signed-off-by: Dan Carpenter
---
I sent a version of this patch last year which updated
drm_pars
> On Sat, Dec 15, 2018 at 09:20:38PM +, Winkler, Tomas wrote:
> > >
> > > On Thu, Dec 13, 2018 at 5:27 PM Winkler, Tomas
> > >
> > > wrote:
> > > >
> > > > > On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam
> > > > >
> > > > > wrote:
> > > > > >
> > > > > > Tomas and Daniel,
> > > > > >
> > > >
>
> Header defines the interface for the I915 and MEI_HDCP drivers.
>
> Signed-off-by: Ramalingam C
> ---
> include/drm/i915_mei_hdcp_interface.h | 132
> ++
> 1 file changed, 132 insertions(+)
> create mode 100644 include/drm/i915_mei_hdcp_interface.h
>
> diff
Hi YeuHaibing,
On 17/12/2018 09:18, YueHaibing wrote:
> In case of error, the function devm_ioremap_resource() returns ERR_PTR()
> and never returns NULL. The NULL test in the return value check should
> be replaced with IS_ERR().
>
This looks correct to me.
I wonder if this failure pattern occ
https://bugs.freedesktop.org/show_bug.cgi?id=109068
Michel Dänzer changed:
What|Removed |Added
CC||harry.wentl...@amd.com,
On Sun, Dec 16, 2018 at 07:21:12AM +0300, Alexander Shiyan wrote:
> Use the SIMPLE_DEV_PM_OPS() macro to declare the driver's pm_ops.
> As a side effect, removing #ifdef CONFIG_PM_SLEEP will improve
> compilation coverage.
>
> Signed-off-by: Alexander Shiyan
> ---
> drivers/video/backlight/pwm_b
On Sun, Dec 16, 2018 at 08:02:47AM +0300, Alexander Shiyan wrote:
> This patch removes dependencies on BACKLIGHT_CLASS_DEVICE for items
> that are already placed under #ifdef BACKLIGHT_CLASS_DEVICE.
s/#ifdef/if/
Once that is fixed:
Acked-by: Daniel Thompson
>
> Signed-off-by: Alexander Shiyan
Needed as input for the dsi controller.
Signed-off-by: Heiko Stuebner
---
include/dt-bindings/clock/rk3368-cru.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dt-bindings/clock/rk3368-cru.h
b/include/dt-bindings/clock/rk3368-cru.h
index a4ed1f094da8..04fbcd92adc0 100644
--- a/incl
Add the compatible and allow the driver to also not set any crtc input
on socs that only have one vop. While that was already possible
because the driver checked against the grf-reg being 0, make that
var an int as "0x0" is a valid grf address itself. So standardize
on -1 for "no setting needed".
Add better default values for PLLs and core clocks on rk3368.
This includes all plls as well as core aclk,hclk and pclk in
both the cpu as well as peripheral domain.
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 10 ++
1 file changed, 10 insertions(+)
diff
Add the clock ids so that they can be exported from the clock driver
and referenced in the rk3368 devicetree.
Signed-off-by: Heiko Stuebner
---
include/dt-bindings/clock/rk3368-cru.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/clock/rk3368-cru.h
b/include/dt-bindin
Add the power-controller main node, the individual power domains
below it and their used quality-of-service syscons on rk3368
and hook the power-domains to their user-devicenodes.
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 177 +++
1 file cha
The rk3368 only has one vop block and thus the dw_hdmi does not need to
do the source selection.
Signed-off-by: Heiko Stuebner
---
.../display/rockchip/dw_hdmi-rockchip.txt | 1 +
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 15 +++
2 files changed, 16 insertions(+)
This ties together the last lose ends to make display support
work on rk3368 and includes some missing clock exports,
compatible values+settings for the specific encoder drivers
and quite a number of dt-changes enabling power-domains first
and then adding the display stuff.
The core rk3368 support
Export the clock using the newly added clock id.
Signed-off-by: Heiko Stuebner
---
drivers/clk/rockchip/clk-rk3368.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/rockchip/clk-rk3368.c
b/drivers/clk/rockchip/clk-rk3368.c
index 58debf7daf85..56ca10fe3e96 100644
Add the compatible and grf values and allow the driver to also
not select a specific crtc input on systems with only one vop.
Signed-off-by: Heiko Stuebner
---
.../display/rockchip/dw_mipi_dsi_rockchip.txt | 1 +
.../gpu/drm/rockchip/dw-mipi-dsi-rockchip.c | 25 +--
2 files ch
Export the clocks using the newly added clock ids.
Signed-off-by: Heiko Stuebner
---
drivers/clk/rockchip/clk-rk3368.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/rockchip/clk-rk3368.c
b/drivers/clk/rockchip/clk-rk3368.c
index 7c4d242f19c1..58debf7daf85 1
Add the core node for the Analogix displayport controller
found on rk3368 socs.
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 22 ++
1 file changed, 22 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
b/arch/arm64/boot/dts/r
The hym8563 is used on a number of Rockchip boards on 64bit as well
and maybe even more importantly is the source for 32kHz clock on those
as well, completing the clock tree of the soc. So enable it as built-in.
Signed-off-by: Heiko Stuebner
---
arch/arm64/configs/defconfig | 1 +
1 file changed
Add the display subsystem and vop and hook up the individual
encoder ports.
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 73
1 file changed, 73 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
b/arch/arm64/boot/dts/roc
Add the core node for the mipi-dsi controller found on rk3368 socs.
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
i
Add the core node for the dw-hdmi controller found on rk3368 socs.
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3368.dtsi | 14 ++
1 file changed, 14 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368.dtsi
b/arch/arm64/boot/dts/rockchip/rk3368.dtsi
i
Enable vop, hdmi and hdmi-i2c on the R88 board.
Signed-off-by: Heiko Stuebner
---
arch/arm64/boot/dts/rockchip/rk3368-r88.dts | 17 +
1 file changed, 17 insertions(+)
diff --git a/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
b/arch/arm64/boot/dts/rockchip/rk3368-r88.dts
index 74
On Mon, Dec 17, 2018 at 12:28 PM Winkler, Tomas wrote:
>
> >
> > Header defines the interface for the I915 and MEI_HDCP drivers.
> >
> > Signed-off-by: Ramalingam C
> > ---
> > include/drm/i915_mei_hdcp_interface.h | 132
> > ++
> > 1 file changed, 132 insertions(
>
> On Mon, Dec 17, 2018 at 12:28 PM Winkler, Tomas
> wrote:
> >
> > >
> > > Header defines the interface for the I915 and MEI_HDCP drivers.
> > >
> > > Signed-off-by: Ramalingam C
> > > ---
> > > include/drm/i915_mei_hdcp_interface.h | 132
> > > ++
> > > 1 file
On Mon, Dec 17, 2018 at 11:57 AM Winkler, Tomas wrote:
>
>
> > On Sat, Dec 15, 2018 at 09:20:38PM +, Winkler, Tomas wrote:
> > > >
> > > > On Thu, Dec 13, 2018 at 5:27 PM Winkler, Tomas
> > > >
> > > > wrote:
> > > > >
> > > > > > On Thu, Dec 13, 2018 at 1:36 PM C, Ramalingam
> > > > > >
> >
On Thu, Dec 13, 2018 at 01:55:25PM -0800, Matt Roper wrote:
> Some hardware may place additional restrictions on the gamma/degamma
> curves described by our LUT properties. E.g., that a gamma curve never
> decreases or that the red/green/blue channels of a LUT's entries must be
> equal. Let's add
On Mon, Dec 17, 2018 at 2:42 PM Winkler, Tomas wrote:
>
> >
> > On Mon, Dec 17, 2018 at 12:28 PM Winkler, Tomas
> > wrote:
> > >
> > > >
> > > > Header defines the interface for the I915 and MEI_HDCP drivers.
> > > >
> > > > Signed-off-by: Ramalingam C
> > > > ---
> > > > include/drm/i915_mei_h
On Fri, Dec 14, 2018 at 01:45:13PM +, Ayan Halder wrote:
> On Tue, Dec 04, 2018 at 04:50:51PM +, Liviu Dudau wrote:
>
> Hi Liviu,
>
> Please let me know if you agree with my comments. Then I will send a
> v4 patch for this.
> > On Mon, Dec 03, 2018 at 11:31:58AM +, Ayan Halder wrote:
On Fri, Dec 14, 2018 at 02:12:23PM +, Ayan Halder wrote:
> On Tue, Dec 04, 2018 at 04:57:46PM +, Liviu Dudau wrote:
>
> Hi Liviu,
> > On Mon, Dec 03, 2018 at 11:32:00AM +, Ayan Halder wrote:
> > > We have added some new formats to be supported on DP500/DP550/DP650.
> >
> > Make a bit
When the pipe_config's update_pipe flag is set we may need to update the
panel fitting settings. On GEN9+ this means we need to update the crtc's
scaler settings.
This fixes the following WARN_ON, during i915 loading on an Asrock
B150M Pro4S/D3 board with an i5-6500 CPU / graphics:
[drm:pipe_conf
Hi Johan,
Am Montag, 17. Dezember 2018, 15:00:55 CET schrieb Johan Jonker:
> Thanks Tomasz for adding all the mailing lists.
> I prefer to ask first if a qos_hdmi exists before sending it in for
> public review.
>
> All the clocks in the pmu node seem to have a "quality-of-service" (QoS)
> block.
On Fri, 14 Dec 2018 at 15:36, Ulf Hansson wrote:
>
> On Fri, 14 Dec 2018 at 15:22, Vincent Guittot
> wrote:
> >
> > With jiffies been replaced by raw ns in PM core accounting, 915 driver is
> > updated to use this new time infrastructure.
> >
> > Signed-off-by: Vincent Guittot
> > ---
> > drive
From: Maarten Lankhorst
We may not be perfect at reading out the initial mode, but when the mode
is sanitized by our first modeset we know for sure the state is compatible,
so we can compare with intel_pipe_config_compare.
Changes in v2 (Hans de Goede):
-When checking if we need to reset the mod
Hi All,
As discussed a while ago, I would like to see us enable fastboot by
default, starting with Skylake / GEN9 and newer hardware, so that we can
avoid an unnecessary modeset at boot and move to a truely flickerfree boot.
During our previous discussion about this Maarten mentioned that a first
We really want to have fastboot enabled by default to avoid an ugly
modeset during boot.
Rather then enabling it everywhere, lets start with enabling it on
Skylake and newer.
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/i915_params.c | 6 --
drivers/gpu/drm/i915/i915_params.h
On Mon, Dec 17, 2018 at 3:23 PM Hans de Goede wrote:
>
> From: Maarten Lankhorst
>
> We may not be perfect at reading out the initial mode, but when the mode
> is sanitized by our first modeset we know for sure the state is compatible,
> so we can compare with intel_pipe_config_compare.
>
> Chang
https://bugs.freedesktop.org/show_bug.cgi?id=108917
--- Comment #6 from Nicholas Kazlauskas ---
I suspect that Alex is right about this being similar to the cursor update
issue - a large volume of color management changes through the full atomic
commit codepath would likely be quite slow. The dc=
Hi,
On 17-12-18 15:29, Daniel Vetter wrote:
On Mon, Dec 17, 2018 at 3:23 PM Hans de Goede wrote:
From: Maarten Lankhorst
We may not be perfect at reading out the initial mode, but when the mode
is sanitized by our first modeset we know for sure the state is compatible,
so we can compare wit
On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote:
> Hi All,
>
> As discussed a while ago, I would like to see us enable fastboot by
> default, starting with Skylake / GEN9 and newer hardware, so that we can
> avoid an unnecessary modeset at boot and move to a truely flickerfree boot.
https://bugs.freedesktop.org/show_bug.cgi?id=109066
--- Comment #1 from Nicholas Kazlauskas ---
Do you see this occur on the amd-staging-drm-next branch from:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=amd-staging-drm-next ?
If yes, then it would also help to know more about your userspac
On Mon, Dec 17, 2018 at 10:54:48AM +0100, Andrzej Hajda wrote:
> Hi Daniel,
>
> Thanks for reviewing other two patches.
>
>
> On 14.12.2018 17:29, Daniel Vetter wrote:
> > On Fri, Dec 14, 2018 at 02:38:52PM +0100, Andrzej Hajda wrote:
> >> rr_cache_dir function cannot assume REPO/.git is a direc
https://bugzilla.kernel.org/show_bug.cgi?id=201273
--- Comment #25 from quirin.blae...@freenet.de ---
Bug is still alive. amd-staging-drm-next
75061f375e7f627acbc3aa5466bc1ee552f3f22c
plymouth low res -> clear -> crash
(4da295299bda146326b44f22d8eeaa797d6acb38 too)
--
You are receiving this mail
Hi,
On 17-12-18 15:38, Ville Syrjälä wrote:
On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote:
Hi All,
As discussed a while ago, I would like to see us enable fastboot by
default, starting with Skylake / GEN9 and newer hardware, so that we can
avoid an unnecessary modeset at boot a
On 12/17/18 4:52 PM, Boris Ostrovsky wrote:
On 12/17/18 5:19 AM, Oleksandr Andrushchenko wrote:
Hello, Juergen, Boris!
As this DRM part of the series is the only one which needs ack/nack
(and it might take quite some time to complete) could we please
merge the patches 1 and 3 now that already
https://bugs.freedesktop.org/show_bug.cgi?id=109049
Chris Wilson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
Am 10.12.18 um 22:43 schrieb Andrey Grodzovsky:
Decauple sched threads stop and start and ring mirror
list handling from the policy of what to do about the
guilty jobs.
When stoppping the sched thread and detaching sched fences
from non signaled HW fenes wait for all signaled HW fences
to complet
The only event function that is called from IRQ context is event_free,
which is already using atomic bitmap operations, so we can avoid taking
the event spinlock in this function completely. As other the other
functions still using the event spinlock are all called from normal
process context, we c
The etnaviv_gpu header only needs to know about the pointer types, so
replace by a forward declaration and only include the headers where needed.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 2 ++
drivers/gpu/drm/etnaviv/etnaviv_gpu.h | 5 ++---
2 files changed, 4 inser
It only written and we don't infer any useful information from
it anymore. Remove it.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 2 --
drivers/gpu/drm/etnaviv/etnaviv_drv.c| 8 +---
drivers/gpu/drm/etnaviv/etnaviv_gpu.c| 2 --
drivers/gpu/drm/etnaviv/et
Hi Christian,
Am Montag, den 17.12.2018, 11:09 +0100 schrieb Christian Gmeiner:
> Am Fr., 14. Dez. 2018 um 11:44 Uhr schrieb Lucas Stach tronix.de>:
> >
> > Hi Dave,
> >
> > nothing major this time, mostly some cleanups that were found on
> > the
> > way of reworking the code in preparation for
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #29 from Jerry Zuo ---
Created attachment 142834
--> https://bugs.freedesktop.org/attachment.cgi?id=142834&action=edit
parch for reg_wait timeout for dce
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #30 from Jerry Zuo ---
Please try the patch, and see if you can see reg_wait timeout
dce110_stream_encoder_dp_blank()
--
You are receiving this mail because:
You are the assignee for the bug.
Hi Sakari,
Thanks for your feedback.
On Thu, Dec 13, 2018 at 10:49:28PM +0200, sakari.ai...@iki.fi wrote:
> > + /**
> > +* @lanes:
> > +*
> > +* Number of active data lanes used for the transmissions.
>
> Could you add that these are the first "lanes" number of lanes from what
> ar
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #31 from Alex Deucher ---
(In reply to Jerry Zuo from comment #30)
> Please try the patch, and see if you can see reg_wait timeout
> dce110_stream_encoder_dp_blank()
Can you attach a non-zipped version?
--
You are receiving this m
Am Mo., 17. Dez. 2018 um 16:36 Uhr schrieb Lucas Stach :
>
> The only event function that is called from IRQ context is event_free,
> which is already using atomic bitmap operations, so we can avoid taking
> the event spinlock in this function completely. As other the other
> functions still using
Am Mo., 17. Dez. 2018 um 16:36 Uhr schrieb Lucas Stach :
>
> The etnaviv_gpu header only needs to know about the pointer types, so
> replace by a forward declaration and only include the headers where needed.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm
Am Mo., 17. Dez. 2018 um 16:36 Uhr schrieb Lucas Stach :
>
> It only written and we don't infer any useful information from
> it anymore. Remove it.
>
> Signed-off-by: Lucas Stach
Reviewed-by: Christian Gmeiner
> ---
> drivers/gpu/drm/etnaviv/etnaviv_buffer.c | 2 --
> drivers/gpu/drm/etnaviv/
https://bugs.freedesktop.org/show_bug.cgi?id=107978
--- Comment #32 from Jerry Zuo ---
Created attachment 142835
--> https://bugs.freedesktop.org/attachment.cgi?id=142835&action=edit
Patch for dp_blank timeout
--
You are receiving this mail because:
You are the assignee for the bug.__
https://bugs.freedesktop.org/show_bug.cgi?id=109066
--- Comment #2 from Benjamin Hodgetts ---
Created attachment 142836
--> https://bugs.freedesktop.org/attachment.cgi?id=142836&action=edit
Pulseaudio HDMI Sink Errors
I'll try amd-staging-drm-next but I've been getting almost non-stop errors o
On Mon, Dec 17, 2018 at 04:37:21PM +0100, Lucas Stach wrote:
> Hi Christian,
>
> Am Montag, den 17.12.2018, 11:09 +0100 schrieb Christian Gmeiner:
> > Am Fr., 14. Dez. 2018 um 11:44 Uhr schrieb Lucas Stach > tronix.de>:
> > >
> > > Hi Dave,
> > >
> > > nothing major this time, mostly some clean
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Alex Deucher changed:
What|Removed |Added
Attachment #142835|0 |1
is patch|
https://bugs.freedesktop.org/show_bug.cgi?id=107978
Alex Deucher changed:
What|Removed |Added
Attachment #142834|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=103949
--- Comment #4 from Patrik Jakobsson ---
Hi, I'm getting the same error on upstream 4.18, 4.19 and drm-fixes-4.20
whenever I hotplug a DP monitor. Can you point me to the patch that is supposed
to fix this? I took a quick look at the mailing lis
On 12/17/2018 10:27 AM, Christian König wrote:
> Am 10.12.18 um 22:43 schrieb Andrey Grodzovsky:
>> Decauple sched threads stop and start and ring mirror
>> list handling from the policy of what to do about the
>> guilty jobs.
>> When stoppping the sched thread and detaching sched fences
>> from
https://bugs.freedesktop.org/show_bug.cgi?id=109068
--- Comment #2 from Samantha McVey ---
Created attachment 142837
--> https://bugs.freedesktop.org/attachment.cgi?id=142837&action=edit
amd-staging-drm-next dmesg
--
You are receiving this mail because:
You are the assignee for the bug.__
Hi Christopher,
On Tue, 20 Nov 2018 at 03:37, Christopher James Halse Rogers
wrote:
>
> We can't use drmSetMaster to query whether or not a drm fd is master
> because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
>
Can you please mention the exact use case here? You mentioned it ove
https://bugs.freedesktop.org/show_bug.cgi?id=109068
--- Comment #3 from Samantha McVey ---
Created attachment 142838
--> https://bugs.freedesktop.org/attachment.cgi?id=142838&action=edit
4.20-rc5 dmesg
In addition, this is what happens to the levels of "brightness" and
"actual_brightness" befo
https://bugs.freedesktop.org/show_bug.cgi?id=108272
--- Comment #12 from Jan Vesely ---
Hi,
sorry for the delay. somehow I missed the notifications.
(In reply to jamespharvey20 from comment #11)
> When I originally filed this, I assumed it was 1 bug since I tried 2 things
> with OpenCL, and both
On Fri, 19 Oct 2018 at 18:20, Lucas De Marchi wrote:
>
> /_build*
> /build*
>
These two sound perfectly reasonable IMHO. They will catch vast
majority of use-cases.
With that the series is:
Acked-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-
On Wed, 24 Oct 2018 at 17:59, Eric Engestrom wrote:
>
> On Wednesday, 2018-10-24 17:53:51 +0100, Eric Engestrom wrote:
> > Fixes the tests on ARM, but more importantly this makes it much easier
> > to maintain.
>
> BTW I have a wip to replace all of those with a python script that will
> be more t
Hi Chunming Zhou,
On Fri, 2 Nov 2018 at 08:27, Chunming Zhou wrote:
>
> Signed-off-by: Chunming Zhou
> ---
> include/drm/drm.h | 38 ++
Please read through include/drm/README about how include/drm/ should be updated.
Thanks
Emil
_
On Mon, Dec 17, 2018 at 6:38 PM Emil Velikov wrote:
>
> Hi Christopher,
>
> On Tue, 20 Nov 2018 at 03:37, Christopher James Halse Rogers
> wrote:
> >
> > We can't use drmSetMaster to query whether or not a drm fd is master
> > because it requires CAP_SYS_ADMIN, even if the fd *is* a master fd.
>
On Wed, 7 Nov 2018 at 18:01, Eric Engestrom wrote:
>
> Thanks to the #error just above, any file including this header can only
> see one state for this macro: defined, with the value `1`.
> Let's just #undef it once we're done using it in here so that other
> files don't misconstrue any meaning t
On Wed, 7 Nov 2018 at 18:02, Eric Engestrom wrote:
>
> Also, move the sentence about "who would use libdrm" into its own paragraph,
> as it is something people discovering libdrm will want to know.
>
> Signed-off-by: Eric Engestrom
Reviewed-by: Emil Velikov
-Emil
__
On Wed, 7 Nov 2018 at 14:44, Eric Engestrom wrote:
>
> Reported-by: Jan Vesely
> Signed-off-by: Eric Engestrom
Reviewed-by: Emil Velikov
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/
Op 17-12-2018 om 15:19 schreef Hans de Goede:
> When the pipe_config's update_pipe flag is set we may need to update the
> panel fitting settings. On GEN9+ this means we need to update the crtc's
> scaler settings.
>
> This fixes the following WARN_ON, during i915 loading on an Asrock
> B150M Pro4S
Hi Christopher,
On Tue, 20 Nov 2018 at 04:30, Christopher James Halse Rogers
wrote:
>
> I have wanted this code in Mir, so it's plausibly useful elsewhere,
> particularly if the DRM device major number is going to become
> dynamic.
>
Can you elaborate/link to the code that uses the major/minor?
F
Sergey Suloev writes:
> Eric, Noralf,
>
> could either of you answer a question about Vc4 DRM, please ?
>
> I am trying to connect MIPI DSI display to VC4 but it isn't showing
> anything. I have noticed
> that the DSI host transfer() method vc4_dsi_host_transfer gets called
> for the commands
On Tue, 11 Dec 2018 at 22:15, François Tigeot wrote:
>
> * There is no way to check if a device name is really a drm device
> by looking it up in a virtual filesystem like on Linux
>
> * The major device number is also dynamically allocated from a pool,
> comparing it to a constant makes no se
Am 17.12.18 um 17:57 schrieb Grodzovsky, Andrey:
>
> On 12/17/2018 10:27 AM, Christian König wrote:
>> Am 10.12.18 um 22:43 schrieb Andrey Grodzovsky:
>>> Decauple sched threads stop and start and ring mirror
>>> list handling from the policy of what to do about the
>>> guilty jobs.
>>> When stoppp
On Wed, 12 Dec 2018 at 19:49, François Tigeot wrote:
>
> It is a cleaner and less fragile way to get PCI IDs than the one
> currently used by local DPorts patches.
>
Thanks for these François. Props to Ilia for pushing these.
JFYI, once DragonFly gets PCI dynamic power management, the team may
wa
On Mon, Dec 17, 2018 at 03:23:14PM +0100, Hans de Goede wrote:
> Hi All,
>
> As discussed a while ago, I would like to see us enable fastboot by
> default, starting with Skylake / GEN9 and newer hardware, so that we can
> avoid an unnecessary modeset at boot and move to a truely flickerfree boot.
On 2018-12-14 11:46, Tanmay Shah wrote:
Red and Blue colors will be interchanged on display with
current format maps for RGB565 and BGR565.
Change both format maps to display correct colors.
You can drop "DPU PATCH" prefix in the patches.
Can you also provide history on what has changed since
On 2018-12-14 07:22, Sean Paul wrote:
On Thu, Dec 13, 2018 at 10:51:03AM -0800, Jeykumar Sankaran wrote:
Bail out KMS hw init on display initialization failures with
proper error logging.
changes in v3:
- introduced in the series
Signed-off-by: Jeykumar Sankaran
---
drivers/gpu/drm/m
1 - 100 of 149 matches
Mail list logo
