On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
> Introduce a new API for modules to query if a specific type of backlight
> device has been registered. This is useful for some backlight device
> provider module(e.g. ACPI video) to know if a native control
> interface(e.g. the interface cr
On Thursday, October 10, 2013 08:54:29 AM Aaron Lu wrote:
> On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
> > On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
> >> Introduce a new API for modules to query if a specific type of backlight
> >> device has been registered. This is useful for
On Wed, Oct 02, 2013 at 01:24:25PM +0200, David Herrmann wrote:
> DRM core shares a single address_space across all inodes that belong to
> the same DRM device. This allows efficient unmapping of user-space
> mappings during buffer eviction. However, there is no easy way to get a
> shared address_s
On Fri, Oct 04, 2013 at 11:05:48AM +0900, Inki Dae wrote:
> 2013/10/4 Olof Johansson :
> > "If PD_N is LOW, then the device is in Deep power-down completely,
> > even if supply rail is ON; for the device to be able to operate, the
> > PD_N pin must be HIGH."
> I still think the pin could be repla
On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
> On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
>> Introduce a new API for modules to query if a specific type of backlight
>> device has been registered. This is useful for some backlight device
>> provider module(e.g. ACPI video) to know
On 10/10/2013 08:29 AM, Rafael J. Wysocki wrote:
> On Tuesday, October 08, 2013 02:40:00 PM Aaron Lu wrote:
>> According to Matthew Garrett, "Windows 8 leaves backlight control up
>> to individual graphics drivers rather than making ACPI calls itself.
>> There's plenty of evidence to suggest that t
On 10/10/2013 12:29 PM, Jani Nikula wrote:
> On Thu, 10 Oct 2013, Aaron Lu wrote:
>> On 10/10/2013 08:25 AM, Rafael J. Wysocki wrote:
>>> On Tuesday, October 08, 2013 02:39:58 PM Aaron Lu wrote:
+bool backlight_device_registered(enum backlight_type type)
+{
+ bool found = false;
>>
Signed-off-by: Maarten Lankhorst
Cc: # v3.7+
---
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers/gpu/drm/nouveau/nouveau_bo.c
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -1551,7 +1579,8 @@ nouveau_bo_vma_add(struct nouveau_bo *nvbo, struc
https://bugs.freedesktop.org/show_bug.cgi?id=70327
--- Comment #11 from tony.wasse...@dolphin-emu.org ---
I can confirm that the patch fixes the issue, thanks :)
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel ma
I already suspected that AMD (ATI at that time) had a very good reason
to use this E2PROM to avoid problem with classic DVI monitors (instead
of the wide spread explanation to gain world domination with it).
It's just that an option to override it would have been nice. Well, I'm
not so depth i
https://bugs.freedesktop.org/show_bug.cgi?id=69395
Mike Lothian changed:
What|Removed |Added
CC||m...@fireburn.co.uk
--- Comment #7 from M
https://bugs.freedesktop.org/show_bug.cgi?id=69395
--- Comment #8 from Mike Lothian ---
Or maybe I should ask does this big affect more than just SI?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
https://bugs.freedesktop.org/show_bug.cgi?id=68792
--- Comment #7 from Grigori Goronzy ---
(In reply to comment #6)
> (In reply to comment #5)
> > You have to enable VDPAU output as well.
>
> Sorry, but where and how?
> In VLC?
> *.conf file?
>
In preferences go to the "Video" tab and select VD
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #30 from Marek Olšák ---
Is there any performance regression? If there isn't, I'm okay with the revert.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-de
https://bugs.freedesktop.org/show_bug.cgi?id=64225
--- Comment #7 from Alexey Shvetsov ---
IT still failes with
0x7fe5003bfc10: i32 = GlobalAddress*, <4 x i32>*, <4 x i32>, <4
x i32>, <4 x i32>, <4 x i32>)* @SHA256> 0 [ORD=6879]
Stack dump:
0. Running pass 'Function Pass Manager' on module
> -Original Message-
> From: Mark Brown [mailto:broo...@kernel.org]
> Sent: Thursday, October 10, 2013 6:37 PM
> To: Inki Dae
> Cc: 'Olof Johansson'; 'Sean Paul'; devicet...@vger.kernel.org; linux-
> samsung-...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org;
To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
detection to move on to next problem.
Signed-off-by: Meelis Roos
diff --git a/drivers/gpu/drm/radeon/radeon_bios.c
b/drivers/gpu/drm/radeon/radeon_bios
On Thursday, October 10, 2013 09:02:55 AM Aaron Lu wrote:
> On 10/10/2013 08:29 AM, Rafael J. Wysocki wrote:
> > On Tuesday, October 08, 2013 02:40:00 PM Aaron Lu wrote:
> >> According to Matthew Garrett, "Windows 8 leaves backlight control up
> >> to individual graphics drivers rather than making
Parse the 3D_Structure_ALL and 3D_MASK fields of the HDMI Vendor
Specific Data Block to expose more stereo 3D modes.
Signed-off-by: Thomas Wood
---
drivers/gpu/drm/drm_edid.c | 93 ++
1 file changed, 85 insertions(+), 8 deletions(-)
diff --git a/drive
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h | 2 +-
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/imx-drm/ipu-v3/imx-ipu-v3.h
b/drivers/staging/imx-drm/ipu-v3/imx-ipu
Hi,
This series fixes DMFC allocation for small displays and pageflip events
during device close, clarifies the RGB memory formats, adds support for the
RGB565 format and KMS planes, and enables DRM PRIME using the CMA helpers.
In the next step, I would like to move the code
from drivers/staging/
The drm fourccs define formats not available as video4linux pixel formats,
such as DRM_FORMAT_BGR565, or the DRM_FORMAT_RGBX/BGRX variants.
Also, contrary to the v4l2 formats, the drm formats are well defined.
This patch also fixes the BGRA32 and RGB/RGB24 internal formats to use a
common internal
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-common.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-common.c
b/drivers/staging/imx-drm/ipu-v3/ipu-common.c
index 54466df..f90bdb4 100644
--- a/drivers/staging/imx-drm/ipu-
From: Sascha Hauer
Currently we wait for a channel until it's idle before actually
disabling it. This is not needed for all channels though, so make
waiting for idle a separate function and call it where necessary.
Signed-off-by: Sascha Hauer
Signed-off-by: Philipp Zabel
---
drivers/staging/i
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipuv3-crtc.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c
b/drivers/staging/imx-drm/ipuv3-crtc.c
index 574633b..f63931b 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipuv3-crtc.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c
b/drivers/staging/imx-drm/ipuv3-crtc.c
index f63931b..292abea 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/stagi
From: Sascha Hauer
During a device close the drm core frees all pending events in
drm_events_release(). If at that time a pageflip is pending the
interrupt handler will try to complete the now unitialized
event resulting in a NULL pointer exception. Seen on imx-drm
when userspace is killed during
Lets the IPU driver make use of the PRIME functionality introduced
by the "drm: GEM CMA: Add DRM PRIME support" patch.
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/imx-drm-core.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/imx-drm/i
Signed-off-by: Philipp Zabel
---
drivers/staging/imx-drm/ipu-v3/ipu-dc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
index 21bf1c8..1a6e06d 100644
--- a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c
+++
This patch adds support for a drm overlay plane on DI0 using the DP.
In principle, the overlay plane could also be used on DI1, but to switch
the overlay plane between display interfaces, the base planes would have
to be exchanged transparently while both display interfaces are inactive.
Signed-of
Connecting a 320x240 parallel display on i.MX6 resulted in an invalid DRDY
signal because the DC would not receive NL/EOL events on every line.
Reducing the allocated DMFC space from 4 slots (256 * 128-bit) to 2 slots
(128 * 128-bit) solved the problem.
Signed-off-by: Philipp Zabel
---
drivers/s
On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos wrote:
> To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
> from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
> detection to move on to next problem.
NACK. All this function does it attempt to read the rom fr
On Thu, Oct 10, 2013 at 1:39 AM, Rafał Miłecki wrote:
> 2013/10/10 Alex Deucher :
>> drm/radeon: use hw generated CTS/N values for audio
>
> I'd like to see such patches earlier :| I'm OK with the change for
> DCE4+ (Evergreen) (I even suggested that change myself recently), but
> I didn't h
On Thu, Oct 10, 2013 at 4:30 AM, Christian König
wrote:
> I already suspected that AMD (ATI at that time) had a very good reason to
> use this E2PROM to avoid problem with classic DVI monitors (instead of the
> wide spread explanation to gain world domination with it).
Indeed.. it may also not be
2013/10/10 Alex Deucher :
> On Thu, Oct 10, 2013 at 1:39 AM, Rafał Miłecki wrote:
>> 2013/10/10 Alex Deucher :
>>> drm/radeon: use hw generated CTS/N values for audio
>>
>> I'd like to see such patches earlier :| I'm OK with the change for
>> DCE4+ (Evergreen) (I even suggested that change m
> On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos wrote:
> > To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
> > from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
> > detection to move on to next problem.
>
> NACK. All this function does it attempt to rea
On Thu, Oct 10, 2013 at 10:50 AM, Rafał Miłecki wrote:
> 2013/10/10 Alex Deucher :
>> On Thu, Oct 10, 2013 at 1:39 AM, Rafał Miłecki wrote:
>>> 2013/10/10 Alex Deucher :
drm/radeon: use hw generated CTS/N values for audio
>>>
>>> I'd like to see such patches earlier :| I'm OK with the
2013/10/10 Alex Deucher :
> Attached. I'll send an updated pull request with the patch added.
Thanks! I promise to work on that, it just takes time to gather so old
hardware and run it (especially fglrx).
--
Rafał
___
dri-devel mailing list
dri-devel@
https://bugs.freedesktop.org/show_bug.cgi?id=66452
--- Comment #5 from Eugene Shalygin ---
Since commit 5b4e2db12d9b45e898a8eb6599d928504ffd30c3 disabled VC-1
simple/main profiles for UVD 3, maybe it might have sense to disable it for UVD
2 also? VC-1 advanced profile seems to be working fin
On Thu, Oct 10, 2013 at 11:26 AM, Meelis Roos wrote:
>> On Thu, Oct 10, 2013 at 7:51 AM, Meelis Roos wrote:
>> > To prevent hangs on non-PC machines (e.g. sparc64), probe Radeon ROM
>> > from ATI IGP only on X86. Fixes hang in this place and allows PCI radeon
>> > detection to move on to next pro
https://bugzilla.kernel.org/show_bug.cgi?id=62721
--- Comment #5 from William Shuman ---
I noticed the same behavior, but it was only reproducible for me when I was
calling wmname before launching a java application to correct some usability
issues.
Attaching dmesg output.
--
You are receiving
https://bugzilla.kernel.org/show_bug.cgi?id=62721
--- Comment #6 from William Shuman ---
Created attachment 110671
--> https://bugzilla.kernel.org/attachment.cgi?id=110671&action=edit
full dmesg output
--
You are receiving this mail because:
You are watching the assignee of the bug.
_
On Wed, Oct 9, 2013 at 6:10 PM, Alex Deucher wrote:
> Hi Dave,
>
> More radeon fixes for 3.12. Regression fixes for audio and UVD, several
> hang fixes, and some dpm fixes.
Hi Dave,
Please pull from the branch again. The only change is the addition of
the patch discussed below with Rafał.
com
https://bugs.freedesktop.org/show_bug.cgi?id=64600
--- Comment #12 from Tom Stellard ---
These patches should fix the crash on Evergreen/NI GPUs:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131007/190695.html
--
You are receiving this mail because:
You are the assignee for the
Make use of the FAULT_FLAG_ALLOW_RETRY flag to allow dropping the
mmap_sem while waiting for bo idle.
FAULT_FLAG_ALLOW_RETRY appears to be primarily designed for disk waits
but should work just as fine for GPU waits..
Signed-off-by: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo_vm.c | 62 ++
NO_EVICT bos that are not idle when all references are dropped are put on
the delayed destroy list. However, since they are not on LRU lists, they
are not available to shrinkers at that point, and buffers on the delayed
destroy list are not checked very often for idle.
So when these buffers are pu
https://bugs.freedesktop.org/show_bug.cgi?id=64600
--- Comment #13 from Tom Stellard ---
(In reply to comment #12)
> These patches should fix the crash on Evergreen/NI GPUs:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20131007/190695.
> html
These patches won't apply to llvm ma
https://bugzilla.kernel.org/show_bug.cgi?id=60791
Dragos Taranu changed:
What|Removed |Added
CC||dragos...@gmail.com
--- Comment #33 from
Hey Everyone,
I just wanted to thank once again, all the folks who were able to attend
and participate at the Android+Graphics discussion at Plumbers. For
those who could not attend, A free-link to my summary on LWN is here:
http://lwn.net/SubscriberLink/569704/a20145dcfbaf70f1/
Hopefully
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #31 from Dieter Nützel ---
Marek,
you ask about, so...
If I'm right, I see some on my poor RV730 AGP under git,
but not with Dota2 or the like 'cause I haven't such stuff.
I see it with Q3A demo (my old testing one) and mesa-demos/
o
Some rs780 asics seem to be affected as well.
See:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=91f3a6aaf280294b07c05dfe606e6c27b7ba3c72
to rs780 as well.
Fixes:
https://bugzilla.kernel.org/show_bug.cgi?id=60791
Signed-off-by: Alex Deucher
Cc: sta...@vger.kernel.org
https://bugzilla.kernel.org/show_bug.cgi?id=60639
--- Comment #13 from Alex Deucher ---
Created attachment 110691
--> https://bugzilla.kernel.org/attachment.cgi?id=110691&action=edit
possible fix
Does the attached patch help?
--
You are receiving this mail because:
You are watching the assig
The plain [EN|DIS]ABLE functions do the same thing and more
and aren't broken on some systems like [EN|DIS]ABLE_OUTPUT.
May fix:
https://bugzilla.kernel.org/show_bug.cgi?id=60639
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 8
1 file changed, 8 deletions
The plain [EN|DIS]ABLE functions do the same thing and more
and aren't broken on some systems like [EN|DIS]ABLE_OUTPUT.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/atombios_encoders.c | 7 +--
1 file changed, 1 insertion(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atom
On Thu, Oct 10, 2013 at 01:07:58PM -0700, John Stultz wrote:
> ADF:
>
> * Rob has reposted his atomic modesetting patches, which helps adress
> part of some of the issues Greg tried to resolve with ADF, although
> there still is the delta vs full update issue.
> http://www.spinics.net/lists/dr
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #32 from Alexandre Demers ---
(In reply to comment #30)
> Is there any performance regression? If there isn't, I'm okay with the
> revert.
Marek, do you have any application you propose that I could use to benchmark
it? I'll gladly g
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #33 from Alex Deucher ---
(In reply to comment #27)
> fun observation:
>
> Instead of reverting, setting this at the end of r600_cp_dma_copy_buffer()
> appears to fix it for me:
> rctx->b.flags |= R600_CONTEXT_INV_VERTEX_CACHE;
>
https://bugs.freedesktop.org/show_bug.cgi?id=63997
--- Comment #25 from Mirko ---
(In reply to comment #24)
> It was against my drm-fixes tree, but it should apply pretty easily to most
> kernels.
Unfortunately the problem seems to be the same.
Patched linux kernel 3.11.1
Xorg server 1.14
Mesa
On Sun, Oct 6, 2013 at 6:08 PM, Russell King
wrote:
> This patch adds support for the pair of LCD controllers on the Marvell
> Armada 510 SoCs. This driver supports:
> - multiple contiguous scanout buffers for video and graphics
> - shm backed cacheable buffer objects for X pixmaps for Vivante GP
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #34 from Alexandre Demers ---
(In reply to comment #33)
> (In reply to comment #27)
> > fun observation:
> >
> > Instead of reverting, setting this at the end of r600_cp_dma_copy_buffer()
> > appears to fix it for me:
> > rctx->b
On Thu, Oct 10, 2013 at 5:09 PM, Daniel Vetter wrote:
>> * Rob has reposted his atomic modesetting patches, which helps adress
>> part of some of the issues Greg tried to resolve with ADF, although
>> there still is the delta vs full update issue.
>> http://www.spinics.net/lists/dri-devel/msg4
The various create and open functions set the buffer size, but
drm_intel_bo_gem_create_from_prime() is an exception. In the 3.12 kernel
we can now use lseek on the prime fd to determine the size of the bo.
Use that and override the userprovided size. If the kernel doesn't
support this, we get an
On Thu, Oct 10, 2013 at 5:59 PM, Russell King - ARM Linux
wrote:
> On Thu, Oct 10, 2013 at 05:25:15PM -0400, Rob Clark wrote:
>> On Sun, Oct 6, 2013 at 6:08 PM, Russell King
>> wrote:
>> > + /*
>> > +* If we have an overlay plane associated with this CRTC, disable
>> > +* it
This set adds some missing devicetree nodes to the exynos5250-snow file as well
as adds a drm_bridge driver for the ptn3460 DP-LVDS chip. This chip is used in
the exynos5250-snow board.
Sean
Sean Paul (5):
ARM: dts: Add fimd display-timings for exynos5250-snow
ARM: dts: Add dp-controller node
This patch adds the internal panel timings to the exynos5250-snow board
dts file.
Signed-off-by: Sean Paul
---
v2: No difference
v3: Added status = "okay"
arch/arm/boot/dts/exynos5250-snow.dts | 18 ++
1 file changed, 18 insertions(+)
diff --git a/arch/arm/boot/dts/exynos5250-
This patch adds the dp-controller node to the exynos5250-snow board dts
file.
Signed-off-by: Sean Paul
---
v2: Added dp-controller address to node (rebased on linux-next)
v3: Added status = "okay"
arch/arm/boot/dts/exynos5250-snow.dts | 13 +
1 file changed, 13 insertions(+)
diff
This patch adds a drm_bridge driver for the PTN3460 DisplayPort to LVDS
bridge chip.
Signed-off-by: Sean Paul
---
v2:
- Changed header definition to static inline
- Changed dt node name to lvds-bridge
v3: No changes
.../devicetree/bindings/drm/bridge/ptn3460.txt | 27 ++
This patch adds code to look for the ptn3460 in the device tree file on
exynos initialization. If ptn node is found, the driver will initialize
the ptn3460 driver and skip creating a DP connector (since the bridge
driver will register its own connector).
Signed-off-by: Sean Paul
---
v2:
This patch adds a node for the ptn3460 DP-LVDS chip in the
exynos5250-snow board dts file.
Signed-off-by: Sean Paul
---
v2: Changed node name to lvds-bridge
v3: No changes
arch/arm/boot/dts/exynos5250-snow.dts | 19 +++
1 file changed, 19 insertions(+)
diff --git a/arch/arm/bo
https://bugs.freedesktop.org/show_bug.cgi?id=69395
--- Comment #9 from Alex Deucher ---
It's in my 3.13-next branch:
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.13-wip
--
You are receiving this mail because:
You are the assignee for the bug.
__
https://bugs.freedesktop.org/show_bug.cgi?id=68451
--- Comment #35 from Marek Olšák ---
Feel free to do some benchmarking if you want.
The question is why this code at the end of the function didn't set one of the
flush flags:
r600_flag_resource_cache_flush(rctx, dst);
Constants are usually re
https://bugs.freedesktop.org/show_bug.cgi?id=67107
Adam Honse changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
https://bugs.freedesktop.org/show_bug.cgi?id=67107
--- Comment #15 from Alex Deucher ---
Does this branch work any better?
http://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-next-3.13-wip
please also try cherry-picking this commit as well:
http://cgit.freedesktop.org/~agd5f/linux/commit/?h=drm-f
On Thu, Oct 10, 2013 at 03:07:01PM -0700, Kristian Høgsberg wrote:
> The various create and open functions set the buffer size, but
> drm_intel_bo_gem_create_from_prime() is an exception. In the 3.12 kernel
> we can now use lseek on the prime fd to determine the size of the bo.
> Use that and over
https://bugs.freedesktop.org/show_bug.cgi?id=67107
--- Comment #16 from Adam Honse ---
VGA switcheroo doesn't show up for me. I've been using kernels from Ubuntu's
kernel ppa (daily and -rc builds) but I'll try building my own from your tree
and see if that fixes it.
--
You are receiving this
On Thu, Oct 10, 2013 at 6:53 PM, Russell King - ARM Linux
wrote:
> On Thu, Oct 10, 2013 at 06:23:26PM -0400, Rob Clark wrote:
>> On Thu, Oct 10, 2013 at 5:59 PM, Russell King - ARM Linux
>> wrote:
>> > On Thu, Oct 10, 2013 at 05:25:15PM -0400, Rob Clark wrote:
>> >> probably this thread is applic
This patchset refactors parts of the exynos driver to move it closer to a proper
drm driver (rather than just implementing a drm layer on top of the hardware
drivers). The hope is to get to a point where the dp/hdmi drivers can implement
drm_connector/drm_encoder directly, and fimd/mixer can direct
From: Stéphane Marchesin
Signed-off-by: Stéphane Marchesin
Signed-off-by: Sean Paul
---
drivers/video/exynos/exynos_dp_core.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/video/exynos/exynos_dp_core.c
b/drivers/video/exynos/exynos_dp_core.c
index 12bbede..089ae22 100644
--- a/dr
This patch merges overlay_ops into manager_ops. In all cases,
overlay_ops is implemented in the same place as manager ops, it doesn't
serve a functional purpose, and doesn't make things more clear.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_drm_drv.h | 29 +--
drivers/gpu/dr
This patch adds an initialize function to the manager and display
operations. This allows them to keep track of drm_device in their
local context, as well as adds an initialization hook right after
the encoder is created.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_drm_drv.h |
This patch implements the initialize callback in the hdmi and mixer
manager. This allows us to get rid of drm_dev in the drm_hdmi level and
track it in the mixer and hdmi drivers. This is one of the things
holding back the complete removal of the drm_hdmi layer.
Signed-off-by: Sean Paul
---
driv
This patch implements the intitialize manager op in fimd.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/gpu/drm/exynos/exynos_drm_f
This patch changes the manager ops callbacks from accepting the subdrv
device pointer to taking a context pointer. This will allow us to move
closer to decoupling manager/display from subdrv, and subsequently
decoupling the crtc/plane from the encoder.
Signed-off-by: Sean Paul
---
drivers/gpu/dr
This patch changes the argument of the display_ops from subdrv device to
context. This will allow us to decouple manager and display from subdrv,
as well as decouple crtc from encoder.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_drm_connector.c | 8 +++
drivers/gpu/drm/exynos
This patch renames the display_op power_on to dpms to accurately reflect
what the function does.
The side-effect of this patch is that the new hdmi dpms callback is now
invoked twice in the dpms path. This is safe and will be dealt with when
the exynos_drm shim goes away.
Signed-off-by: Sean Paul
This patch removes the dpms state tracking in encoder. This
state is at best confusing and at worst incorrect since the display
drivers can turn on and off without propagating the value.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 18 --
1 file chan
Change all instances of possible_crtcs in the exynos drm driver to be
unsigned long. This matches the type used in the drm layer.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm_encoder.c | 2 +-
drivers/gpu/drm/exynos/exynos_drm
From: Daniel Kurtz
The i2c client was previously being passed into the hdmi driver via a
dedicated i2c driver, and then a global variable. This patch removes all
of that and just uses the device tree to get the i2c_client. This patch
also properly references the client so we don't lose it before
This patch changes the manual copying of mode to adjusted_mode in
mode_fixup to use drm_mode_copy instead of handling things manually.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/e
This patch removes the call from encoder dpms into connector dpms (which
will then call back into encoder dpms through the helper function). The
callback is likely to keep connector->dpms in the right state when
initiating dpms from crtc or encoder, but this isn't the right way to do
it. This patch
This patch trims exynos_drm_hdmi out of the driver. The reason it
existed in the first place was to make up for the mixture of
display/overlay/manager ops being spread across hdmi and mixer. With
that code now rationalized, mixer and hdmi map directly to
exynos_drm_crtc and exynos_drm_encoder, resp
This patch moves the code which disables unused crtc planes from the
encoder to the crtc. Since there is a 1:1 encoder/crtc mapping in
exynos, the only valid crtc change the pre-existing code could catch is
disconnecting an active crtc from the encoder. Thus it is functionally
equivalent to just di
This patch adds a mode_set callback to the manager operations which
sets the crtc's current mode to the manager driver.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 4
drivers/gpu/drm/exynos/exynos_drm_drv.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/
This patch adds a new manager callback for mode_fixup and pipes it
through exynos_drm_crtc.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_drm_crtc.c | 8 +++-
drivers/gpu/drm/exynos/exynos_drm_drv.h | 3 +++
2 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers
This patch uses the mode passed into mode_set to configure fimd instead
of directly using the panel from context. This will allow us to move
the exynos_drm_display implementation from fimd into the DP driver
where it belongs.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c
This patch removes a few fimd_context members which are either entirely
unused or unneeded.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/exynos/exynos_drm_fimd.c | 13 +
1 file changed, 1 insertion(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c
b/drivers/
This patch moves the exynos_drm_display implementation from fimd into
the dp driver. This will allow for tighter integration of the dp driver
into the exynos drm driver.
Signed-off-by: Sean Paul
---
.../devicetree/bindings/video/exynos_dp.txt| 17 +++
.../devicetree/bindings/video/samsu
This patch moves the display-timings node from fimd to dp to reflect the
device tree bindings change.
Signed-off-by: Sean Paul
---
arch/arm/boot/dts/exynos5250-arndale.dts | 7 ---
arch/arm/boot/dts/exynos5250-smdk5250.dts | 7 ---
arch/arm/boot/dts/exynos5250-snow.dts | 7 ---
From: Dave Airlie
So GNOME userspace has an issue with when it rescans for modes on hotplug
events, if the monitor has no EDID it assumes that nothing has changed on
EDID as with real hw we'd never have new modes without a new EDID, and they
kind off rely on the behaviour now, however with virtua
https://bugs.freedesktop.org/show_bug.cgi?id=68792
--- Comment #8 from Dieter Nützel ---
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
> > > You have to enable VDPAU output as well.
> >
> > Sorry, but where and how?
> > In VLC?
> > *.conf file?
> >
>
> In pref
1 - 100 of 110 matches
Mail list logo
