Add drm_panel controls to support powerup/down of the
eDP panel, if one is present at the sink side.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/exynos/Kconfig |1 +
drivers/gpu/drm/exynos/exynos_dp_core.c | 88 ---
drivers/gpu/drm/exynos/exynos_dp_co
Add commit callback for exynos_dp, and move the DP link training,
video configuration code from the hotplug handler into commit().
Signed-off-by: Sean Paul
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/exynos/exynos_dp_core.c | 24 +++-
1 file changed, 19 insertions(+), 5
Add panel_desc structure for auo_b133htn01 eDP panel.
Signed-off-by: Ajay Kumar
---
.../devicetree/bindings/panel/auo,b133htn01.txt|7 +
drivers/gpu/drm/panel/panel-simple.c | 31
2 files changed, 38 insertions(+)
create mode 100644 Documentation
For most of the panels, we need to provide delays during
various stages of panel powerup/powerdown.
So, Add a structure to hold those delay values and use them
in corresponding functions.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/panel/panel-simple.c | 30 ++
1
Move out code from enable and disable routines to prepare
and unprepare routines, so that functionality is properly
distributed across all the panel functions.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/panel/panel-simple.c | 37 +-
1 file changed, 27 inserti
Move out code from enable and disable routines to prepare
and unprepare routines, so that functionality is properly
distributed across all the panel functions.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/panel/panel-s6e8aa0.c | 22 +++---
1 file changed, 11 insertions(+), 11
Move out code from enable and disable routines to prepare
and unprepare routines, so that functionality is properly
distributed across all the panel functions.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/panel/panel-ld9040.c | 22 +++---
1 file changed, 11 insertions(+), 11 d
Modify tegra output driver to support the new panel calls:
prepare and unprepare.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/tegra/output.c |2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 446837e..0c67d7e 100644
--
Modify exynos_dsi driver to support the new panel calls:
prepare and unprepare.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/exynos/exynos_drm_dsi.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dsi.c
b/drivers/gpu/drm/exy
Modify exynos_dpi driver to support the new panel calls:
prepare and unprepare.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/exynos/exynos_drm_dpi.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dpi.c
b/drivers/gpu/drm/exynos/e
This patch adds dummy definition for prepare and unprepare
routines to simple panel driver.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/panel/panel-simple.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-s
This patch adds dummy definition for prepare and unprepare
routines to s6e8aa0 panel driver.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/panel/panel-s6e8aa0.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-s6e8aa0.c
b/drivers/gpu/drm/panel/pane
This patch adds dummy definition for prepare and unprepare
routines to ld9040 panel driver.
Signed-off-by: Ajay Kumar
---
drivers/gpu/drm/panel/panel-ld9040.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-ld9040.c
b/drivers/gpu/drm/panel/panel-l
Add a helper function drm_panel_get_modes to get modes from the panel.
Signed-off-by: Ajay Kumar
---
include/drm/drm_panel.h |8
1 file changed, 8 insertions(+)
diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
index 9addc69..efc63cc 100644
--- a/include/drm/drm_panel.
Most of the panels need an init sequence as mentioned below:
-- poweron LCD unit/LCD_EN
-- start video data
-- poweron LED unit/BACKLIGHT_EN
And, a de-init sequence as mentioned below:
-- poweroff LED unit/BACKLIGHT_EN
-- stop video data
-- poweroff L
This series is based on exynos-drm-next branch of Inki Dae's tree at:
git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git
This is originally a part of the bridge chip series:
http://www.spinics.net/lists/linux-samsung-soc/msg34826.html
But, since we can handle panel and bridge ch
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/7f921c8c/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/7297c449/attachment.html>
pretty cold - it only has 50 ?C.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/29b864a0/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/bbff7b43/attachment-0001.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/079cab32/attachment.html>
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/48195d22/attachment.html>
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/04579844/attachment.html>
h to "Uber"-Mode and see if
anything chages (does dpm still work or does the "Uber"-Mode BIOS also use a
ASIC_ProfilingInfo v3.1 table ?).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/d4f6d12e/attachment.html>
Reviewed-by: Marek Ol??k
Marek
On Thu, Jul 31, 2014 at 11:43 AM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> Signed-off-by: Michel D?nzer
> ---
> src/gallium/drivers/radeon/r600_buffer_common.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/src/g
Reviewed-by: Marek Ol??k
Marek
On Thu, Jul 31, 2014 at 11:43 AM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> Signed-off-by: Michel D?nzer
> ---
> src/gallium/drivers/radeon/r600_buffer_common.c | 12
> 1 file changed, 8 insertions(+), 4 deletions(-)
>
> diff --git a/src/galli
Strange, I've explicitly made sure that it's rebased on top of libdrm/master.
I will give it another try in a moment.
FWIW, for Intel at least a mmap/mmap64 would be needed due to the bionic
shortage of their original implementation.
As mentioned earlier, I'm seeking for a few acked/reviewed-by a
top.org/archives/dri-devel/attachments/20140731/68453eb6/attachment.html>
/archives/dri-devel/attachments/20140731/0cc5fcc5/attachment.html>
channels (no custom tweaks
to Chrome, all default).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/1dd18b9c/attachment.html>
On 31.07.2014 18:52, Christian K?nig wrote:
> Am 31.07.2014 um 11:43 schrieb Michel D?nzer:
>> From: Michel D?nzer
>>
>> Signed-off-by: Michel D?nzer
>
> At least for PIPE_USAGE_STREAM buffers that's a bad idea, cause they are
> used by VDPAU to read back to data to a CPU buffer and that's reall
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
src/gallium/drivers/radeon/r600_buffer_common.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 154c
From: Michel D?nzer
Signed-off-by: Michel D?nzer
---
src/gallium/drivers/radeon/r600_buffer_common.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/src/gallium/drivers/radeon/r600_buffer_common.c
b/src/gallium/drivers/radeon/r600_buffer_common.c
index 4e6b897.
From: Michel D?nzer
This ensures the GPU sees all previous CPU writes to VRAM, which makes it
safe:
* For userspace to stream data from CPU to GPU via VRAM instead of GTT
* For IBs to be stored in VRAM instead of GTT
* For ring buffers to be stored in VRAM instead of GTT, if the HPD flush
is p
From: Michel D?nzer
And clean up the function comment a little.
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/r600.c| 13 +--
drivers/gpu/drm/radeon/radeon.h | 9 ++--
drivers/gpu/drm/radeon/radeon_asic.c | 44 ++--
drivers/gp
On my Kaveri system, streaming data from CPU to GPU via VRAM is faster
than via GTT both with the integrated GPU and with discrete GPUs.
The following kernel patches make this safe by always flushing the HDP
cache before submitting a command stream to the GPU, and bump the radeon
DRM minor version
Some hawaii cards use a different method to fetch the
voltage info from the vbios.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=74250
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/ci_dpm.c | 13 -
1 file changed, 12 insertions(+), 1 deleti
Some hawaii boards use a different method for fetching the
voltage information from the vbios.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/radeon.h | 3 +++
drivers/gpu/drm/radeon/radeon_atombios.c | 35
2 files
The DMA API is the recommended way to map pages no matter what the
underlying bus is. Use the DMA functions for page mapping and remove
currently existing wrappers.
Signed-off-by: Alexandre Courbot
Cc: Daniel Vetter
---
Changes since v4:
- Patch against the Nouveau tree instead of the kernel
- S
On 31.07.2014 16:54, Daniel Vetter wrote:
> On Thu, Jul 31, 2014 at 3:14 AM, Michel D?nzer wrote:
>> I think it would be better to refactor drm_wait_vblank() than to
>> reinvent it.
>
> That's the ioctl implementation which spends most of its time decoding
> ioctl structures. If we take that out
op 31-07-14 17:30, Maarten Lankhorst schreef:
> This series applies on top of the driver-core-next branch of
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
>
> Before converting ttm to the new fence interface I had to fix some
> drivers to require a reservation before poking
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ttm/ttm_bo.c | 76 +++---
1 file changed, 13 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 9d36cffad3b7..d119ae4419d4 100644
--- a/drivers/gp
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index f0a689ba9685..a43930162eb6 100644
--- a
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon_gem.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index d09650c1d720..7ba883843668 100644
--- a/drivers/gpu/
With the conversion to the reservation api this should be safe.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +---
drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +---
drivers/gpu/drm/nouveau/nouveau_fence.h |2
drivers/gpu/drm/nouveau/nouveau_gem.c| 16 ++-
drivers/gpu/drm/qxl/qxl_debugfs.c|6 +
drivers/gpu/drm/qxl/qxl_drv
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |2
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c| 299 ++
drivers/gpu/drm/vmwgfx/vmwgfx_fence.h| 29 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |9 -
4 files changed, 200 inser
Only one type was ever used. This is needed to simplify the fence
support in the next commit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |5 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 -
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 ++---
drive
Final driver! \o/
This is not a proper dma_fence because the hardware may never signal
anything, so don't use dma-buf with qxl, ever.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/Makefile |2
drivers/gpu/drm/qxl/qxl_cmd.c |5 -
drivers/gpu/drm/qxl/qxl_debugfs.c |
Changes since v1:
- Kill the sw interrupt dance, add and use
radeon_irq_kms_sw_irq_get_delayed instead.
- Change custom wait function, lockdep complained about it.
Holding exclusive_lock in the wait function might cause deadlocks.
Instead do all the processing in .enable_signaling, and wait
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c | 50 -
1 file changed, 30 insertions(+), 20 deletions(-)
dif
Signed-off-by: Maarten Lankhorst
---
V1 had a nasty bug breaking gpu lockup recovery. The fix is not
allowing radeon_fence_driver_check_lockup to take exclusive_lock,
and kill it during lockup recovery instead.
---
drivers/gpu/drm/radeon/radeon.h|3 +
drivers/gpu/drm/radeon/radeon_dev
From: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/core/core/event.c |4
drivers/gpu/drm/nouveau/nouveau_bo.c |6
drivers/gpu/drm/nouveau/nouveau_display.c |4
drivers/gpu/drm/nouveau/nouveau_fence.c | 435 -
d
No users are left, kill it off! :D
Conversion to the reservation api is next on the list, after
that the functionality can be restored with rcu.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +++---
drivers/gpu/drm/nouveau/nouveau_display.c |6 --
This is the last remaining function that doesn't use the reservation
lock completely to fence off access to a buffer.
---
drivers/gpu/drm/ttm/ttm_bo.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/tt
This will ensure we always hold the required lock when calling those functions.
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
drivers/gpu/drm/nouveau/nouveau_display.c | 17 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouve
Apart from some code inside ttm itself and nouveau_bo_vma_del,
this is the only place where ttm_bo_wait is used without a reservation.
Fix this so we can remove the fence_lock later on.
After the switch to rcu the reservation lock will be
removed again.
Signed-off-by: Maarten Lankhorst
---
driv
This reorders the list to keep track of what buffers are reserved,
so previous members are always unreserved.
This gets rid of some bookkeeping that's no longer needed,
while simplifying the code some.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/qxl_release.c |1
drivers
It seems some drivers really want this as a parameter,
like vmwgfx.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/qxl_release.c|2 +-
drivers/gpu/drm/radeon/radeon_object.c |2 +-
drivers/gpu/drm/radeon/radeon_uvd.c |2 +-
drivers/gpu/drm/radeon/radeon_vm.c
fence_is_signaled callback should support being run in
atomic context, but not in irq context.
Signed-off-by: Maarten Lankhorst
---
include/linux/fence.h | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/include/linux/fence.h b/include/linux/fence.h
i
fence_is_signaled callback should support being run in
atomic context, but not in irq context.
Signed-off-by: Maarten Lankhorst
---
include/linux/fence.h | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/include/linux/fence.h b/include/linux/fence.h
i
This series applies on top of the driver-core-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
Before converting ttm to the new fence interface I had to fix some
drivers to require a reservation before poking with fence_obj.
After flipping the switch RCU becomes
lists.freedesktop.org/archives/dri-devel/attachments/20140731/a1d1784f/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/5eb27d82/attachment.html>
vel/attachments/20140731/d8dc0c18/attachment.html>
Hi,
Am 31.07.2014 16:46, schrieb Stephane Viau:
> From: Beeresh Gopal
>
> lpm-mux is programmed to enable HDMI connector
> on the docking station for S805 chipset based
> devices.
>
> Signed-off-by: Beeresh Gopal
You forgot to sign off yourself.
[...]
> diff --git a/drivers/gpu/drm/msm/hdmi/
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/a87add7e/attachment-0001.html>
- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/aa7eb1ab/attachment-0001.sig>
On Thu, Jul 31, 2014 at 9:46 AM, Maarten Lankhorst
wrote:
> All the bof_* symbols are now no longer exported.
>
> Signed-off-by: Maarten Lankhorst
Seems reasonable to me.
Reviewed-by: Alex Deucher
> ---
> radeon/Makefile.am | 1 +
> radeon/radeon_bo.c | 46 ++
All the bof_* symbols are now no longer exported.
Signed-off-by: Maarten Lankhorst
---
radeon/Makefile.am | 1 +
radeon/radeon_bo.c | 46
radeon/radeon_bo_gem.c | 24 +--
radeon/radeon_cs.c | 50 +++
No exports changed for this driver.
Signed-off-by: Maarten Lankhorst
---
intel/Makefile.am | 1 +
intel/intel_bufmgr.c | 93 ---
intel/intel_bufmgr_fake.c | 31
intel/intel_bufmgr_gem.c | 53 +++
This hides all the abi16_* functions and the nouveau_debug variable,
they should have been private to begin with.
Signed-off-by: Maarten Lankhorst
---
nouveau/Makefile.am | 1 +
nouveau/bufctx.c| 10 +-
nouveau/nouveau.c | 40
nouveau/priva
??_?M?w?~?O/q?
???1j?`#?t:?/?xgI/???w~??? ????
?r??#????1[???]???:?|???k??z?u?g|F5F ???V???w?n+?g?e???)?A|?.?~
??G?
??G????(???:a6?75?g?m?">?W?h??_}??oX?}N??(?#?5????Of??f???
l?$>?W#?L??C?6?Hj?$>X#??M |??a???3?_? |?w?O?
l?&>X ?^???E/m??!??/??}??{?+??o@XU t???8?Y??/?? ???_2\?~???_???O????'?$?5???/|? ~??_??^?K??G??
B??V???~?m?o_Co?~??_?z{?7??pO?%??=?Z???u??:??;?{_~??V??x???o
t????t?|???
o??}???~??{??}??w^??O;???k?w??9???? 3d??_??v
??ka????6?hfitu?k??]??????/??_M?w?
???E?~G??~?y??_?>??A[????}??I_??????3[3?_?7??|???/ ?y?7?ps???E?
?g?T???&p+?????i??_t?P???_tO???i
?7???O???o???/}?m??|??/_??? w?i?v???p??
????K???9n??_2p???W?|w)_??>?
d??U???/??I?K?w~???^~??O"??g??
?G??7~?z?B???~??_?iO?
7?t??0?0?N??(?G??v ???H?C?b???H?C?bG?C?bG?C?b???H?C??*?j??Q
S!T?T?v? ?0?GUL
j??QSa*T;j??Q
S??!T?T;??j?
>???*??!T?T?v? ???!T?T?v? ???!T?TF?v? ???!T?TF?v? ??!T?T? H?C??*?j??Q
S!T?T?v? U1???
?G??v? U1?Q?
?G??v? U1?Q?
?G??v? Uq???p?z? N?`???J5
???n?*??G?? ?#?K??O?S???r
>???}'9 }??v0??#cIEND?B`?
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/7d9f22e9/attachment-0001.html>
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/3fef918a/attachment.html>
On Thu, Jul 31, 2014 at 2:27 PM, Andreas F?rber wrote:
> Ajay,
>
> Am 31.07.2014 10:38, schrieb Ajay kumar:
>> On Thu, Jul 31, 2014 at 1:02 AM, Andreas F?rber wrote:
>>> Am 30.07.2014 08:21, schrieb Ajay kumar:
On Tue, Jul 29, 2014 at 4:51 PM, Andreas F?rber
wrote:
> Am 28.07.2014
Ok, I still had to manually apply some of patch 3/8 as it was corrupted
And would not apply, but after this I was able to build within one of
My android trees. I have not tested the resulting libraries yet, but the
Overall build process seems ok.
Tim
> -Original Message-
> From: Emil V
bugs for the
poor performance and crashing the GPU by running Unigine Heaven (you have to
actually reboot, otherwise the screen won't come up again, in fact the screen
is not just black, it loses its signal). And possible other issues I'm not
seeing myself or just have not noticed yet.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/665f3d9c/attachment.html>
On 05/12/14 11:04, Randy Dunlap wrote:
> On 05/12/2014 08:54 AM, Daniel Vetter wrote:
>> On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote:
>>> On 05/12/2014 01:58 AM, Daniel Vetter wrote:
On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote:
>>>
>>> If we decide to g
because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/4993cf50/attachment.html>
On 31/07/14 14:44, Maarten Lankhorst wrote:
> This hides all the abi16_* functions and the nouveau_debug variable,
> they should have been private to begin with.
>
> Signed-off-by: Maarten Lankhorst
Looks good afaict
Reviewed-by: Emil Velikov
ves/dri-devel/attachments/20140731/e348a77b/attachment-0001.html>
On Thu, Jul 31, 2014 at 5:43 AM, Michel D?nzer wrote:
> From: Michel D?nzer
>
> And clean up the function comment a little.
>
> Signed-off-by: Michel D?nzer
Applied the series to my 3.17 tree.
Alex
> ---
> drivers/gpu/drm/radeon/r600.c| 13 +--
> drivers/gpu/drm/radeon/radeon
On Thu, Jul 31, 2014 at 7:44 AM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Both on their own are complex enough.
>
> Signed-off-by: Christian K?nig
Applied to my 3.17 tree.
Alex
> ---
> drivers/gpu/drm/radeon/Makefile | 2 +-
> drivers/gpu/drm/radeon/radeon_ib.c | 319
> ++
Andreas,
On Thu, Jul 31, 2014 at 1:02 AM, Andreas F?rber wrote:
> Hi Ajay,
>
> Am 30.07.2014 08:21, schrieb Ajay kumar:
>> On Tue, Jul 29, 2014 at 4:51 PM, Andreas F?rber wrote:
>>> Am 28.07.2014 08:13, schrieb Ajay kumar:
On 7/27/14, Andreas F?rber wrote:
> Am 25.07.2014 21:22, schrie
From: Christian K?nig
Both on their own are complex enough.
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/Makefile | 2 +-
drivers/gpu/drm/radeon/radeon_ib.c | 319 +++
drivers/gpu/drm/radeon/radeon_ring.c | 287 -
ontroller needs to generate.
> >
> > Querying the panel's .get_modes() might be useful to figure out which
> > emulation mode to use in the bridge.
> But, get_modes from panel returns me only the no_of_modes but
> not the actual mode structure. How do I compare the list of supported
> emulation modes?
You could iterate over the connector's probed_modes list which should
contain all the modes that the panel reported (after .get_modes() was
called).
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/4e25edb4/attachment.sig>
This patch adds some generic functions for DCS like below
to standize on common APIs rather than per-driver
implementations.
mipi_dcs_enter_sleep_mode() / mipi_dcs_exit_sleep_mode()
- These are required to disable / enable all blocks inside
the display module.
mipi_dcs_set_display_off() / mipi_
ll other cases detection should already happen when DRM
initializes.
I see that on Tegra we call drm_helper_hpd_irq_event() in the DSI host's
->attach(), but I don't remember why that's there and I don't see why it
would be necessary either. I'll try to remove it and see if things still
work without.
> > Perhaps you can explain the exact setup where you need this (or point me
> > at the code since I can't seem to find the relevant location) so that I
> > can gain a better understanding.
>
> I can see bridge getting detected only when I set polled member of
> bridge connector to DRM_CONNECTOR_POLL_HPD, because exynos_drm
> also calls drm_helper_hpd_irq_event() to force detect all connectors at the
> end of drm_load.
That shouldn't be necessary. DRM automatically force detects all outputs
(at least if you use drm_helper_probe_single_connector_modes(), which
seems to be the case for Exynos).
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/be6cb5cc/attachment-0001.sig>
v4 of this series it was not a problem.
Thanks,
Andreas
--
SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 N?rnberg, Germany
GF: Jeff Hawn, Jennifer Guild, Felix Imend?rffer; HRB 16746 AG N?rnberg
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/1dede008/attachment-0001.sig>
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/304a7d2c/attachment.sig>
Am 31.07.2014 um 11:57 schrieb Michel D?nzer:
> On 31.07.2014 18:52, Christian K?nig wrote:
>> Am 31.07.2014 um 11:43 schrieb Michel D?nzer:
>>> From: Michel D?nzer
>>>
>>> Signed-off-by: Michel D?nzer
>> At least for PIPE_USAGE_STREAM buffers that's a bad idea, cause they are
>> used by VDPAU to
Am 31.07.2014 um 11:43 schrieb Michel D?nzer:
> From: Michel D?nzer
>
> Signed-off-by: Michel D?nzer
At least for PIPE_USAGE_STREAM buffers that's a bad idea, cause they are
used by VDPAU to read back to data to a CPU buffer and that's really
slow from VRAM.
Christian.
> ---
> src/gallium/
On Thu, Jul 31, 2014 at 10:56 AM, Michel D?nzer wrote:
> On 31.07.2014 16:54, Daniel Vetter wrote:
>> On Thu, Jul 31, 2014 at 3:14 AM, Michel D?nzer wrote:
>>> I think it would be better to refactor drm_wait_vblank() than to
>>> reinvent it.
>>
>> That's the ioctl implementation which spends most
itors).
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/f0e0cd95/attachment.html>
On Thu, Jul 31, 2014 at 10:46 AM, Stephane Viau wrote:
> From: Beeresh Gopal
>
> lpm-mux is programmed to enable HDMI connector
> on the docking station for S805 chipset based
> devices.
>
> Signed-off-by: Beeresh Gopal
other than the issues Andreas mentioned, it looks good, so with those addre
Ajay,
Am 31.07.2014 10:38, schrieb Ajay kumar:
> On Thu, Jul 31, 2014 at 1:02 AM, Andreas F?rber wrote:
>> Am 30.07.2014 08:21, schrieb Ajay kumar:
>>> On Tue, Jul 29, 2014 at 4:51 PM, Andreas F?rber wrote:
Am 28.07.2014 08:13, schrieb Ajay kumar:
> On 7/27/14, Andreas F?rber wrote:
>>
From: Beeresh Gopal
lpm-mux is programmed to enable HDMI connector
on the docking station for S805 chipset based
devices.
Signed-off-by: Beeresh Gopal
---
drivers/gpu/drm/msm/hdmi/hdmi.c | 1 +
drivers/gpu/drm/msm/hdmi/hdmi.h | 1 +
drivers/gpu/drm/msm/hdmi/hdmi_connector
rst and wait for it (taking wraparound into account obviously).
>
> Hmm... would something like this work?
>
> target = drm_vblank_count(dev, crtc) + count;
>
> ret = wait_event_timeout(...,
> drm_vblank_count(dev, crtc) == target,
>...);
>
> That should properly take into account wrap-around given that both sites
> use drm_vblank_count().
I think it would be better to refactor drm_wait_vblank() than to
reinvent it.
--
Earthling Michel D?nzer| http://www.amd.com
Libre software enthusiast |Mesa and X developer
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 234 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140731/a4eace1e/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=80331
Colin changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Thu, Jul 31, 2014 at 3:14 AM, Michel D?nzer wrote:
> I think it would be better to refactor drm_wait_vblank() than to
> reinvent it.
That's the ioctl implementation which spends most of its time decoding
ioctl structures. If we take that out then there's about half a line
which would be shared
1 - 100 of 105 matches
Mail list logo
