Good evening Daniel,
On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote:
> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM
> > core does not turn off the crtc first and neither do the drivers. With
On Wed, May 25, 2016 at 12:07 AM, Lukas Wunner wrote:
> Good evening Daniel,
>
> On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote:
>> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
>> > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM
>> > core do
Hello Andrzej,
sorry for the delay.
Andrzej Hajda wrote:
> On 05/07/2016 12:33 PM, Tobias Jakobi wrote:
>> Hello Andrzej,
>>
>> I've applied this to my 4.5.3 based tree, but I'm still seeing the page
>> fault.
>
> Thats pity, I hoped to solve two issues with one patch :)
>
>> In fact the call
https://bugzilla.kernel.org/show_bug.cgi?id=118611
--- Comment #3 from K. Paden ---
Here you are,
-Khalid
On 05/23/2016 09:35 PM, bugzilla-daemon at bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=118611
>
> --- Comment #2 from Michel Dänzer ---
> Also, please attach
https://bugzilla.kernel.org/show_bug.cgi?id=118611
--- Comment #4 from K. Paden ---
Created attachment 217341
--> https://bugzilla.kernel.org/attachment.cgi?id=217341&action=edit
DMESG.txt
--
You are receiving this mail because:
You are watching the assignee of the bug.
Return the set of supported functions to the caller. No functional
changes.
Signed-off-by: Peter Wu
---
drivers/gpu/drm/nouveau/nouveau_acpi.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_acpi.c
b/drivers/gpu/drm/nouveau/no
Since "PCI: Add runtime PM support for PCIe ports", the parent PCIe port
can be runtime-suspended which disables power resources via ACPI. This
is incompatible with DSM, resulting in a GPU device which is still in D3
and locks up the kernel on resume.
Mirror the behavior of Windows 8 and newer[1]
Hi,
Here are two patches to fix an issue reported on kernel bugzilla (infinite loop
due to unchecked function) and a more important fix to fix hanging Optimus
machines when runtime PM is enabled (with pm/pci patches).
An older (obsolete) patch for the first issue was tested by the reporter:
https
Hi David, Laurent
These removes unneeded error message from Renesas DU driver.
Current this unneeded error message makes user confuse.
Kuninori Morimoto (2):
drm: rcar-du: error message is not needed for drm_vblank_init()
drm: rcar-du: error message is not needed for EPROBE_DEFER
d
Do not unconditionally invoke function 0x1B without checking for its
availability, it leads to an infinite loop on some firmware.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=104791
Fixes: 5addcf0a5f0fad ("nouveau: add runtime PM support (v0.9)")
Signed-off-by: Peter Wu
---
drivers/gpu/
Ensure that the returned set of supported DSM functions (MUX, Optimus)
match the ACPI handle that is set in nouveau_dsm_pci_probe.
As there are no machines with a MUX function on just one PCI device and
an Optimus on another, there should not be a functional impact. This
change however makes this
Hi Laurent
> > From: Kuninori Morimoto
> >
> > EPROBE_DEFER is not error, thus, error message on kernel log on this
> > case is confusable for user. Prints it only error cases.
> >
> > Signed-off-by: Kuninori Morimoto
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_drv.c | 6 --
> > 1 file c
From: Kuninori Morimoto
The only reason drm_vblank_init() could return an error at the
moment is a kcalloc() failure.
So we can remove current error message completely.
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
- just removed error message
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 4 +---
From: Kuninori Morimoto
EPROBE_DEFER is not error, thus, error message on kernel log on this
case is confusable. Print it only error cases
Signed-off-by: Kuninori Morimoto
---
v1 -> v2
- only for rcar_du_modeset_init()
drivers/gpu/drm/rcar-du/rcar_du_drv.c | 3 ++-
1 file changed, 2 inserti
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/32549df4/attachment.html>
versions of Mesa and/or the kernel?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/76686599/attachment.html>
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/ff65298e/attachment-0001.html>
Hi Linus,
On Mon, 23 May 2016 12:10:25 -0700 Linus Torvalds wrote:
>
> Is there a patch pending for this that I'm not aware of, or is it just
> that nobody but me hates spurious warnings? Didn't this show up in
> linux-next? And if it _did_ show up in linux-next, why was the pull
> request not ta
ttachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/8b7ff323/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160525/16516fd0/attachment.html>
27;ve attached it in case you still would like to look at it.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/cf984d7a/attachment.html>
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/9c74cb5a/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/7df30d67/attachment.html>
On 05/25/2016 02:23 AM, Heiko Stuebner wrote:
> Am Dienstag, 24. Mai 2016, 11:12:20 schrieb Doug Anderson:
>> Hi,
>>
>> On Tue, May 24, 2016 at 3:17 AM, Heiko Stuebner wrote:
--- a/Documentation/devicetree/bindings/display/bridge/analogix_dp.txt
+++ b/Documentation/devicetree/bindings/d
On 05/24/2016 06:17 PM, Heiko Stuebner wrote:
> Am Dienstag, 24. Mai 2016, 14:57:23 schrieb Yakir Yang:
> []
>> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
>> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c index 29c4105..d5d4e04
>> 100644
>> --- a/drivers/gpu/drm/rockc
-devel/attachments/20160525/afbb4fa7/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=117411
no.spam.to.me at ish.de changed:
What|Removed |Added
Regression|No |Yes
Summary|[radeon]
High resoultion modes (4K/5K) are supported by encoder/crtc hardware, but
the backing hardware planes to scanout these buffers generally don't
support such large widths. Two (or more) hardware planes are used in
conjunction to scan out the entire width.
One way to support this is to virtualize the
https://bugzilla.kernel.org/show_bug.cgi?id=118911
Bug ID: 118911
Summary: [radeon][HD5650][REDWOOD] DPM stalls boot for 16
seconds
Product: Drivers
Version: 2.5
Kernel Version: at least since 3.16
Hardware: All
https://bugzilla.kernel.org/show_bug.cgi?id=118911
--- Comment #1 from no.spam.to.me at ish.de ---
Created attachment 217471
--> https://bugzilla.kernel.org/attachment.cgi?id=217471&action=edit
snipped dmesg of kernel 4.6.0 with deactivated dpm
--
You are receiving this mail because:
You are w
On Tue, May 24, 2016 at 03:15:46PM +0300, Tomi Valkeinen wrote:
> Hi,
>
> On 24/05/16 12:16, Jyri Sarha wrote:
> > Implement gamma_lut atomic crtc property, set crtc gamma size to 256
> > for all crtcs and use drm_atomic_helper_legacy_gamma_set() as
> > gamma_set func. The tv-out crtc has 1024 ele
On Wed, May 25, 2016 at 12:03:39PM +0530, Archit Taneja wrote:
> High resoultion modes (4K/5K) are supported by encoder/crtc hardware, but
> the backing hardware planes to scanout these buffers generally don't
> support such large widths. Two (or more) hardware planes are used in
> conjunction to s
https://bugzilla.kernel.org/show_bug.cgi?id=118701
--- Comment #4 from Stuart Foster ---
(In reply to Patrik Jakobsson from comment #3)
> Created attachment 217321 [details]
> Add compat ioctl
>
> Turns out we didn't have compat_ioctl hooked up. Does the patch I attached
> fix your problem?
Hi
I found that its regmap endianness issue, so I want to replace the "regmap".
Hi Stefan,
Do you have any idea about this?
Hi Mark,
Regmap endianness issue had caused some other drivers not work, like SPI etc.
Or this is fixed and I just don't know?
Thanks,
Meng
-
Hi,
On Tue, 24 May 2016 16:16:40 +0200 Philipp Zabel wrote:
> Hi Lothar,
>
> thank you for rebasing. I have applied the other two patches.
> With this one, I'd like to avoid the duplicated code. See below:
>
> Am Dienstag, den 24.05.2016, 08:31 +0200 schrieb Lothar WaÃmann:
> > Currently these
On Wed, 25 May 2016, Stephen Rothwell wrote:
> My bad. That warning turned up in linux-next last Wednesday but I
> didn't notice (I have other stuff to do and don't carefully watch all
> the builds all day - and there are quite a few warnings to filter new
> ones out out of). Maybe I need some a
On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> On 2016-05-24 19:14, Meng Yi wrote:
> > I found that its regmap endianness issue, so I want to replace the
> > "regmap".
> Hm, replace with what? Note that we need some kind of endianness
> convertion since the IP is big endian on LS1021a and l
On Tue, May 24, 2016 at 10:23 PM, Philipp Zabel
wrote:
> Am Dienstag, den 24.05.2016, 18:10 +0800 schrieb Liu Ying:
>> Wire up CRTCs', planes' and connectors' ->reset, ->duplicate and ->destroy
>> state
>> hooks to use the default implementations from the atomic helper library.
>> The helpers tr
On Tue, May 24, 2016 at 10:23 PM, Philipp Zabel
wrote:
> Am Dienstag, den 24.05.2016, 18:10 +0800 schrieb Liu Ying:
>> Use the drm_plane_helper_update/disable() and drm_helper_crtc_mode_set()
>> transistional atomic helpers. The crtc->mode_set_nofb callback is added
>> so that the primary plane
Hi Dave -
I see the main drm pull got merged, here's the first batch of fixes for
4.7 already. Fixes all around, a large portion cc: stable stuff.
BR,
Jani.
PS. I got a bit worried that Ville's "drm: Add helper for DP++ adaptors"
lacked your ack, but apparently you'd acked it on IRC [1] but i
Hi,
On 25-05-16 00:52, Peter Wu wrote:
> Hi,
>
> Here are two patches to fix an issue reported on kernel bugzilla (infinite
> loop
> due to unchecked function) and a more important fix to fix hanging Optimus
> machines when runtime PM is enabled (with pm/pci patches).
>
> An older (obsolete) patc
.
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/dc4aec8d/attachment.sig>
On Tue, May 24, 2016 at 10:20 PM, Philipp Zabel
wrote:
> Am Dienstag, den 24.05.2016, 18:10 +0800 schrieb Liu Ying:
>> The IPUv3 primary plane doesn't support partial off screen.
>> So, this patch separates plane check logics for primary plane and overlay
>> plane and adds more limitations on the
On Tue, May 24, 2016 at 10:19 PM, Philipp Zabel
wrote:
> Hi Liu,
>
> Am Dienstag, den 24.05.2016, 18:10 +0800 schrieb Liu Ying:
>> Hi,
>>
>> This patch set converts imx drm into atomic mode setting.
>> It takes 3 phases to achieve the goal as recommended.
>> This patch set may apply to Philipp Za
On Tue, May 24, 2016 at 7:11 PM, Daniel Vetter wrote:
> On Tue, May 24, 2016 at 06:10:52PM +0800, Liu Ying wrote:
>> To support generic atomic page flip, this patch customizes ->atomic_commit
>> for async commits.
>
> It's now called nonblocking instead of async. Please run s/async/nonblock/
> ove
On Tue, May 24, 2016 at 7:00 PM, Daniel Vetter wrote:
> On Tue, May 24, 2016 at 06:10:49PM +0800, Liu Ying wrote:
>> We should disable planes explicitly when suspending.
>> Especially, this is meaningful for those display controllers which
>> don't support active planes without relevant CRTCs bein
On Tue, May 24, 2016 at 6:57 PM, Daniel Vetter wrote:
> On Tue, May 24, 2016 at 06:10:44PM +0800, Liu Ying wrote:
>> Since CRTC has already been disabled in crtc_funcs->prepare(), it doesn't
>> hurt
>> to disable the primary plane in drm_helper_crtc_mode_set() before enabling it
>> in drm_helper_
Hi,
On Wednesday 25 May 2016 08:58:31, Meng Yi wrote:
> > On Tuesday 24 May 2016 23:20:02, Stefan Agner wrote:
> > > On 2016-05-24 19:14, Meng Yi wrote:
> > > > I found that its regmap endianness issue, so I want to replace the
> > > > "regmap".
> > >
> > > Hm, replace with what? Note that we nee
On Tue, May 24, 2016 at 10:23 PM, Philipp Zabel
wrote:
> Am Dienstag, den 24.05.2016, 18:10 +0800 schrieb Liu Ying:
>> For normal video modes such as 1280x720p at 60Hz and 1920x1080p at 60Hz,
>
> I'm very happy to drop all this code if possible, but the stated reason
> is not good enough. Rather
Hi Alexander,
> From: Alexander Stein [mailto:alexander.stein at systec-electronic.com]
> Sent: Wednesday, May 25, 2016 4:32 PM
> To: Stefan Agner
> Cc: Meng Yi ; dri-devel at lists.freedesktop.org; David
> Airlie
> ; airlied at redhat.com; linux-kernel at
> vger.kernel.org; Mark
> Brown
> Sub
Hi Mark,
>
> Without any description of the problem it is difficult to comment.
> There were some drivers that were abusing the API by hacking round things
> that need fixing (the main one I've seen is reporting things as big endian
> instead of native endian to cause two layers of translation t
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/c67e27cf/attachment.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/2b27b1ad/attachment.html>
Am Mittwoch, den 25.05.2016, 08:11 +0200 schrieb Lothar WaÃmann:
[...]
> > > @@ -81,10 +87,27 @@ static int imx_pd_connector_get_modes(struct
> > > drm_connector *connector)
> > >
> > > if (np) {
> > > struct drm_display_mode *mode = drm_mode_create(connector->dev);
> > > +
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/47b0c8aa/attachment.html>
On Wed, May 25, 2016 at 05:37:41PM +0800, Ying Liu wrote:
> On Tue, May 24, 2016 at 6:57 PM, Daniel Vetter wrote:
> > On Tue, May 24, 2016 at 06:10:44PM +0800, Liu Ying wrote:
> >> Since CRTC has already been disabled in crtc_funcs->prepare(), it doesn't
> >> hurt
> >> to disable the primary plan
oading..." window. See
>https://bugs.launchpad.net/ubuntu/+source/assaultcube/+bug/1581805";
>target="_blank">https://bugs.launchpad.net/ubuntu/+source/assaultcube/+bug/1581805
>
>Extreme TuxRacer and Sauerbraten have problems while changing the resolution.
>Both get REALLY sluggish then, hardware acceleration does not seem to work any
>longer. The console output starts showing "radeon 000:f0:10.0: ring 0
>stalled
>for more than msec" messages during these resolution change problems
>in
>Extreme TuxRacer.
>
>
>
>
>
> You are receiving this mail because:
>
>
> You are on the CC list for the bug.
>
>
>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/a2d9954b/attachment-0001.html>
||
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/27012414/attachment.html>
On Wed, May 25, 2016 at 05:30:05PM +0800, Ying Liu wrote:
> On Tue, May 24, 2016 at 7:00 PM, Daniel Vetter wrote:
> > On Tue, May 24, 2016 at 06:10:49PM +0800, Liu Ying wrote:
> >> We should disable planes explicitly when suspending.
> >> Especially, this is meaningful for those display controller
RL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/746bcc3b/attachment.sig>
Hi Daniel,
On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote:
> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM
> > core does not turn off the crtc first and neither do the drivers. With
> > nouve
On 05/25/2016 12:40 PM, Daniel Vetter wrote:
> On Wed, May 25, 2016 at 12:03:39PM +0530, Archit Taneja wrote:
>> High resoultion modes (4K/5K) are supported by encoder/crtc hardware, but
>> the backing hardware planes to scanout these buffers generally don't
>> support such large widths. Two (or
https://bugzilla.kernel.org/show_bug.cgi?id=88861
Wilfried Klaebe changed:
What|Removed |Added
CC||linux-kernel at lebenslange-ma
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/d359e38d/attachment.sig>
lectrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/c766743b/attachment.sig>
part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/55127a08/attachment.html>
ns.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/7695e4da/attachment.sig>
On 05/24/2016 06:05 PM, Tobias Jakobi wrote:
> Hello Krzysztof,
>
>
> Krzysztof Kozlowski wrote:
>> On 05/24/2016 03:49 PM, Tobias Jakobi wrote:
>>> Hello Krzysztof,
>>>
>>> are you sure that these are the only differences. Because AFAIK there
>>> are quite a few more:
>>> - DMA submission of com
On Wednesday 25 May 2016 10:25:29, Meng Yi wrote:
> Hi Alexander,
> Thanks for your reply.
>
> > Commit d761701c55a99598477f3cb25c03d939a7711e74 only has one child
> > commit in my repo. Both touch only i915 related things. Please do a proper
> > bisect and name the offending commit. On which comm
The current bitwise AND should result in the same assembler
but this is what the code is actually supposed to do.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_plane.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane
uot;;
> > + allwinner,function = "lcd0";
> > + allwinner,drive = ;
>
> Just a thought: would we ever need to increase the drive strength for very
> high
> resolutions?
I don't think we need to, but we can always change that late
Neither of these files issue any fbdev related calls.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos7_drm_decon.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_core.c | 1 -
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 1 -
3 files changed, 3 deletions(-)
diff --git a/drivers/gpu/d
ed Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/fd557265/attachment.sig>
available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/67730757/attachment.sig>
---
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/2d9b7f8e/attachment.sig>
//lists.freedesktop.org/archives/dri-devel/attachments/20160525/ee47c2a1/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=88861
--- Comment #12 from Lukas Wunner ---
Thanks for the report, Wilfried. Could you please create attachments with dmesg
output and Xorg output, both with and without this commit. Your kernel config
and Xorg config (if any) would also be helpful. Do
This makes the defines consistent with the rest.
Signed-off-by: Tobias Jakobi
---
drivers/gpu/drm/exynos/exynos_drm_g2d.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 01b7
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/4ba23d8c/attachment.sig>
ot available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/50918e19/attachment.sig>
Hey Krzysztof,
Krzysztof Kozlowski wrote:
> On 05/24/2016 06:05 PM, Tobias Jakobi wrote:
>> Hello Krzysztof,
>>
>>
>> Krzysztof Kozlowski wrote:
>>> On 05/24/2016 03:49 PM, Tobias Jakobi wrote:
Hello Krzysztof,
are you sure that these are the only differences. Because AFAIK there
>
On Wed, May 25, 2016 at 04:28:36PM +0530, Archit Taneja wrote:
> On 05/25/2016 12:40 PM, Daniel Vetter wrote:
> >- Is the size/width really independent of e.g. rotation/pixel format/...
> > Should it be the maximum that's possible under best circumstance (things
> > could still fail), or the mi
On Tue, May 24, 2016 at 12:12 PM, Mario Kleiner
wrote:
> When porting the hdmi deep color detection code from
> radeon-kms to amdgpu-kms apparently some kind of
> copy and paste error happened, attaching an else
> branch to the wrong if statement.
>
> The result is that hdmi deep color mode is alw
On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner wrote:
>
> On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote:
>> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
>> > When a drm_crtc structure is destroyed with drm_crtc_cleanup(), the DRM
>> > core does not turn off the crt
On Tue, May 24, 2016 at 1:47 PM, Jeff Mahoney wrote:
> The DRM_AMD_ACP option doesn't have any dependencies and selects
> MFD_CORE, which results in MFD_CORE=y. Since the code is only called
> from DRM_AMDGPU, it should depend on it. Adding the dependency results
> in MFD_CORE being selected as
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/8af5c49c/attachment.html>
---
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/76361d11/attachment.html>
On 05/24/2016 06:51 PM, Daniel Vetter wrote:
> On Tue, May 24, 2016 at 6:28 PM, Max Staudt wrote:
>> Hi Daniel,
>>
>> Thanks for the feedback! Comments below:
>>
>>
>> On 05/23/2016 03:44 PM, Daniel Vetter wrote:
>>> Do we _really_ care about fbdev mmap support so much that we want to add
>>> more
On Wed, May 25, 2016 at 1:28 AM, Jani Nikula
wrote:
>
> There may be better ones out there, but Artem's "aiaiai" has some
> helpers [1] for diffing build logs, if you want something simple to
> integrate into existing scripts.
It would be lovely to have some kind of warning detection, but quite
f
Not clearing mst manager's proposed vcpis table for
destroyed connectors when the manager is stopped
leaves it pointing to unrefernced memory,
this causes pagefault when the manager is
restarted when plugging back a branch.
Fixes: 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
lectrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160525/56a7f4a6/attachment.sig>
ktop.org/archives/dri-devel/attachments/20160525/69ca1450/attachment.html>
On Wed, May 25, 2016 at 9:12 AM, Daniel Vetter wrote:
> On Wed, May 25, 2016 at 04:28:36PM +0530, Archit Taneja wrote:
>> On 05/25/2016 12:40 PM, Daniel Vetter wrote:
>> >- Is the size/width really independent of e.g. rotation/pixel format/...
>> > Should it be the maximum that's possible under
On Fri, Oct 2, 2015 at 1:58 PM, Gerd Hoffmann wrote:
> Signed-off-by: Gerd Hoffmann
So I entirely missed this, but this isn't really how to implement
page_flip for an atomic driver. Working on some stuff and will hack up
a likely totally broken patch, but should be enough as guideline.
-Daniel
On Mon, Mar 30, 2015 at 4:49 PM, Daniel Vetter wrote:
> On Mon, Mar 30, 2015 at 02:23:47PM +0200, Gerd Hoffmann wrote:
>> > > Signed-off-by: Dave Airlie
>> > > Signed-off-by: Gerd Hoffmann
>> >
>> > Standard request from my side for new drm drivers (especially if they're
>> > this simple): Can y
On 25 May 2016 at 17:40, Daniel Vetter wrote:
> On Mon, Mar 30, 2015 at 4:49 PM, Daniel Vetter wrote:
>> On Mon, Mar 30, 2015 at 02:23:47PM +0200, Gerd Hoffmann wrote:
>>> > > Signed-off-by: Dave Airlie
>>> > > Signed-off-by: Gerd Hoffmann
>>> >
>>> > Standard request from my side for new drm d
On 25 May 2016 at 17:13, Linus Torvalds
wrote:
> On Wed, May 25, 2016 at 1:28 AM, Jani Nikula
> wrote:
>>
>> There may be better ones out there, but Artem's "aiaiai" has some
>> helpers [1] for diffing build logs, if you want something simple to
>> integrate into existing scripts.
>
> It would b
Josh,
my current git version (with gcc 5.3.1) makes objtool warn about
"duplicate frame pointer save" in drivers/gpu/drm/vmwgfx/vmwgfx_msg.c
for both vmw_send_msg() and vmw_host_get_guestinfo().
The reason is that VMW_PORT_HB_OUT() uses a magic instruction sequence
(a "rep outsb") to communicate
On Wed, May 25, 2016 at 12:36:53PM -0400, Rob Clark wrote:
> On Wed, May 25, 2016 at 9:12 AM, Daniel Vetter wrote:
> > On Wed, May 25, 2016 at 04:28:36PM +0530, Archit Taneja wrote:
> >> On 05/25/2016 12:40 PM, Daniel Vetter wrote:
> >> >- Is the size/width really independent of e.g. rotation/pixe
1 - 100 of 157 matches
Mail list logo
