archives/dri-devel/attachments/20160122/05ae900e/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=108561
--- Comment #8 from Elmar Stellnberger ---
... and now the external monitor stays black all the time no matter what I do
with xrandr/nouveau while the proprietary driver does happily continue to work.
It is a shame that nobody seems to care about
oo. The other trace does a 404 now so can't check.
--
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/20160122/4a5b94b0/attachment.html>
On Friday 22 January 2016 08:01 PM, Guenter Roeck wrote:
> On Mon, Dec 21, 2015 at 06:08:44PM -0800, Eric Anholt wrote:
>> I've tested and confirmed that it doesn't actually work. We'll need
>> to sort out how to do this properly later, but for now just remove it
>> since it also caused build brea
On Fri, Jan 22, 2016 at 07:21:31PM +, Emil Velikov wrote:
> On 22 January 2016 at 18:49, Ville Syrjälä
> wrote:
> > On Fri, Jan 22, 2016 at 05:59:30PM +, Emil Velikov wrote:
>
> >> Also let's not forget about
> >>
> >> a.c:17:20: warning: ISO C forbids empty initializer braces [-Wpedant
p.org/archives/dri-devel/attachments/20160122/e6ff9ad6/attachment.html>
On Fri, Jan 22, 2016 at 05:59:30PM +, Emil Velikov wrote:
> On 22 January 2016 at 17:50, Emil Velikov wrote:
> > On 22 January 2016 at 17:47, Ville Syrjälä
> > wrote:
> >> On Fri, Jan 22, 2016 at 05:40:54PM +, Emil Velikov wrote:
> >>> On 22 January 2016 at 17:29, Ilia Mirkin wrote:
>
On Fri, Jan 22, 2016 at 05:40:54PM +, Emil Velikov wrote:
> On 22 January 2016 at 17:29, Ilia Mirkin wrote:
> > On Fri, Jan 22, 2016 at 12:18 PM, Marek Olšák wrote:
> >> On Fri, Jan 22, 2016 at 6:13 PM, Emil Velikov >> gmail.com> wrote:
> >>> On 21 January 2016 at 16:58, Marek Olšák wro
On 01/22/2016 04:18 PM, Ville Syrjälä wrote:
> On Fri, Jan 22, 2016 at 12:06:00PM +0900, Michel Dänzer wrote:
>>
>> [ Trimming KDE folks from Cc ]
>>
>> On 21.01.2016 19:09, Daniel Vetter wrote:
>>> On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote:
On 21.01.2016 16:58, Danie
On 22 January 2016 at 18:49, Ville Syrjälä
wrote:
> On Fri, Jan 22, 2016 at 05:59:30PM +, Emil Velikov wrote:
>> Also let's not forget about
>>
>> a.c:17:20: warning: ISO C forbids empty initializer braces [-Wpedantic]
>> struct foo f = {};
>> ^
>
> I long ago decid
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20160122/c5227288/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/bb521e8d/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/a5e72aeb/attachment.html>
s for the nouveau it's business as usual, no
change.
bye
--
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/20160122/152356cd/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/e0f36099/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/a324b4ce/attachment.html>
|bad resolution |bad refresh rate
--
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/20160122/42a8ff07/attachment.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/20160122/e3794721/attachment.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/20160122/b4fa35d0/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/17c6d03a/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/73ccc6e6/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/3abf74a2/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/1ca493cf/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/f239b003/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/3daef7d8/attachment.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/db673410/attachment.html>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/0c12b296/attachment-0001.html>
On Fri, Jan 22, 2016 at 6:13 PM, Emil Velikov
wrote:
> On 21 January 2016 at 16:58, Marek Olšák wrote:
>> On Thu, Jan 21, 2016 at 2:09 PM, Emil Velikov
>> wrote:
>>> On 21 January 2016 at 12:08, Marek Olšák wrote:
On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov >>> gmail.com> wrote:
>
On 01/22/2016 04:17 AM, Michel Dänzer wrote:
> On 21.01.2016 18:16, Mario Kleiner wrote:
>> On 01/21/2016 09:25 AM, Michel Dänzer wrote:
>>> On 21.01.2016 17:16, Mario Kleiner wrote:
This patch replaces calls to drm_vblank_pre/post_modeset in the
drivers dpms code with calls to drm
On 22 January 2016 at 17:50, Emil Velikov wrote:
> On 22 January 2016 at 17:47, Ville Syrjälä
> wrote:
>> On Fri, Jan 22, 2016 at 05:40:54PM +, Emil Velikov wrote:
>>> On 22 January 2016 at 17:29, Ilia Mirkin wrote:
>>> > On Fri, Jan 22, 2016 at 12:18 PM, Marek Olšák
>>> > wrote:
>>> >
On 22 January 2016 at 17:47, Ville Syrjälä
wrote:
> On Fri, Jan 22, 2016 at 05:40:54PM +, Emil Velikov wrote:
>> On 22 January 2016 at 17:29, Ilia Mirkin wrote:
>> > On Fri, Jan 22, 2016 at 12:18 PM, Marek Olšák
>> > wrote:
>> >> On Fri, Jan 22, 2016 at 6:13 PM, Emil Velikov > >> gmail.
On Fri, Jan 22, 2016 at 11:50:06AM +, Carlos Palminha wrote:
> Hi Daniel,
>
> Thanks for the tip.
> I just enabled fb.lockless_register_fb=1 and still cannot see any debug
> messages after the console_lock... :(
If this works there shouldn't be any console_lock call from
initial_config(). con
On 22 January 2016 at 17:29, Ilia Mirkin wrote:
> On Fri, Jan 22, 2016 at 12:18 PM, Marek Olšák wrote:
>> On Fri, Jan 22, 2016 at 6:13 PM, Emil Velikov
>> wrote:
>>> On 21 January 2016 at 16:58, Marek Olšák wrote:
On Thu, Jan 21, 2016 at 2:09 PM, Emil Velikov >>> gmail.com> wrote:
>>>
From: Colin Ian King
amdgpu_amdkfd_gfx_7_get_functions and amdgpu_amdkfd_gfx_8_0_get_functions
have no parameters, so use the normal void parameter convention to make
them match their prototypes in the header file
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
Signed-off-by: Colin Ian King
---
dr
On Fri, Jan 22, 2016 at 04:06:15PM +, Lionel Landwerlin wrote:
> On 22/01/16 15:04, Daniel Stone wrote:
> >Hi Lionel,
> >
> >On 21 January 2016 at 15:03, Lionel Landwerlin
> > wrote:
> >>Hi,
> >>
> >>This serie introduces pipe level color management through a set of
> >>properties
> >>attached
On Fri, Jan 22, 2016 at 12:06:00PM +0900, Michel Dänzer wrote:
>
> [ Trimming KDE folks from Cc ]
>
> On 21.01.2016 19:09, Daniel Vetter wrote:
> > On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote:
> >> On 21.01.2016 16:58, Daniel Vetter wrote:
> >>>
> >>> Can you please point me
On 21 January 2016 at 16:58, Marek Olšák wrote:
> On Thu, Jan 21, 2016 at 2:09 PM, Emil Velikov
> wrote:
>> On 21 January 2016 at 12:08, Marek Olšák wrote:
>>> On Thu, Jan 21, 2016 at 11:51 AM, Emil Velikov >> gmail.com> wrote:
On 18 January 2016 at 22:53, Marek Olšák wrote:
> T
Hi,
On 22 January 2016 at 16:21, Daniel Vetter wrote:
> On Fri, Jan 22, 2016 at 04:06:15PM +, Lionel Landwerlin wrote:
>> On 22/01/16 15:04, Daniel Stone wrote:
>> >Now with everything just using split-gamma mode, I'm much happier with
>> >how this is looking. I took a look at some other arch
From: Andrey Grodzovsky
On DELL U3014 if you clear the table before enabling MST it sometimes
hangs the receiver.
Signed-off-by: Andrey Grodzovsky
Reviewed-by: Harry Wentland
Acked-by: Alex Deucher
---
drivers/gpu/drm/drm_dp_mst_topology.c | 12 ++--
1 file changed, 6 insertions(+),
From: Hersen Wu
Previous implementation does not handle case below: boot up one MST branch
to DP connector of ASIC. After boot up, hot plug 2nd MST branch to DP output
of 1st MST, GUID is not created for 2nd MST branch. When downstream port of
2nd MST branch send upstream request, it fails becaus
From: Mykola Lysenko
1. Get edid for all connected MST displays, not only on logical ports,
in the same thread as MST topology detection is done:
There are displays that have branches inside w/o logical ports.
So in case another SST display connected downstream system can
end-up
Our PBN value overflows the 20 bits integer part of the 20.12
fixed point. We need to use 31.32 fixed point to avoid this.
This happens with display clocks larger than 293122 (at 24 bpp),
which we see with the Sharp (and similar) 4k tiled displays.
Signed-off-by: Harry Wentland
Reviewed-by: Alex
drm_fixp_from_fraction allows us to create a fixed point directly
from a fraction, rather than creating fixed point values and dividing
later. This avoids overflow of our 64 bit value for large numbers.
drm_fixp2int_ceil allows us to return the ceiling of our fixed point
value.
Signed-off-by: Har
A couple of MST fixes to bugs in the framework that we encountered when
testing with
- three-display daisy-chain configurations
- 4k tiled displays
Andrey Grodzovsky (1):
drm/dp/mst: Reverse order of MST enable and clearing VC payload table.
Harry Wentland (2):
drm: Add drm_fixp_from_fra
ay or two to be absolutely certain,
but the freeze is long overdue by now.
--
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
ea4 sp
7fa9867fe3e0 error 6 in plugin-container[557f813a5000+3d000]
--
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/20160122
On Fri, Jan 22, 2016 at 12:51:23PM +, Damien Lespiau wrote:
> We are reading at most sizeof(data) bytes, but then data may not contain
> a terminating '\0', at least in theory, so strstr() may overflow the
> stack allocated array.
>
> Make sure that data always contains at least one '\0'.
>
>
While all objects that get coredumped have an active IOVA and thus
pages already populated, etnaviv_gem_get_pages() still requires the
object lock to be held.
Signed-off-by: Lucas Stach
---
drivers/gpu/drm/etnaviv/etnaviv_dump.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/d
On 22/01/16 15:04, Daniel Stone wrote:
> Hi Lionel,
>
> On 21 January 2016 at 15:03, Lionel Landwerlin
> wrote:
>> Hi,
>>
>> This serie introduces pipe level color management through a set of properties
>> attached to the CRTC. It also provides an implementation for some Intel
>> platforms.
>>
>>
On Fri, Jan 22, 2016 at 04:48:05PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 22, 2016 at 12:51:23PM +, Damien Lespiau wrote:
> > We are reading at most sizeof(data) bytes, but then data may not contain
> > a terminating '\0', at least in theory, so strstr() may overflow the
> > stack allocate
> -Original Message-
> From: Daniel Stone [mailto:daniel at fooishbar.org]
> Sent: Friday, January 22, 2016 10:05 AM
> To: Lionel Landwerlin
> Cc: intel-gfx; Thierry Reding; Deucher, Alexander; dri-devel
> Subject: Re: [Intel-gfx] [PATCH 0/6] Pipe level color management
>
> Hi Lionel,
>
>
ent was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/92ef614e/attachment.html>
Hi Lionel,
On 21 January 2016 at 15:03, Lionel Landwerlin
wrote:
> Hi,
>
> This serie introduces pipe level color management through a set of properties
> attached to the CRTC. It also provides an implementation for some Intel
> platforms.
>
> This serie is based of a previous set of patches by S
||g/show_bug.cgi?id=93795
--
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/20160122/56c0f
Hi Dave,
A few misc radeon and amdgpu fixes for 4.5. Nothing too major.
The following changes since commit e9c5e7402dad6f4f04c2430db6f283512bcd4392:
drm/amdgpu: add missing irq.h include (2016-01-14 08:07:55 +1000)
are available in the git repository at:
git://people.freedesktop.org/~agd5
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/ba97f35f/attachment-0001.html>
and takes only 4 bytes of text.
> > > >
> > > > I like {} too and think we should encourage that. I'd rather
> > > > transition the { 0 } stuff over to {}.
> > > >
> > > So people feel against seeing/writing single extra character 0,
> > > despite that the warning has helped catch actual bug ?
> > > And now are willing to transitions 40+ cases as opposed to ~15...
> > > that
> > > feels strange to say the least.
> >
> > Does the '= { 0 }' thing even work if the first member happens to
> > be
> > something other than an integer?
>
> No. That's why I like {}. Otherwise you end up doing
> {{0}.
ISO C99
According to 6.7.8 20 all braces but the outermost ones are optional.
{}, on the other hand, is not allowed by syntax rules.
Jan
>
> Â -ilia
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jan Vesely
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/036efd7e/attachment.sig>
We are reading at most sizeof(data) bytes, but then data may not contain
a terminating '\0', at least in theory, so strstr() may overflow the
stack allocated array.
Make sure that data always contains at least one '\0'.
Signed-off-by: Damien Lespiau
---
xf86drm.c | 3 ++-
1 file changed, 2 inse
On Fri, Jan 22, 2016 at 12:47 PM, Ville Syrjälä
wrote:
> On Fri, Jan 22, 2016 at 05:40:54PM +, Emil Velikov wrote:
>> On 22 January 2016 at 17:29, Ilia Mirkin wrote:
>> > On Fri, Jan 22, 2016 at 12:18 PM, Marek Olšák
>> > wrote:
>> >> On Fri, Jan 22, 2016 at 6:13 PM, Emil Velikov > >> g
||
--
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/20160122/5dc06337/attachment.html>
ment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/c665bad7/attachment.html>
On Fri, Jan 22, 2016 at 12:18 PM, Marek Olšák wrote:
> On Fri, Jan 22, 2016 at 6:13 PM, Emil Velikov
> wrote:
>> On 21 January 2016 at 16:58, Marek Olšák wrote:
>>> On Thu, Jan 21, 2016 at 2:09 PM, Emil Velikov
>>> wrote:
On 21 January 2016 at 12:08, Marek Olšák wrote:
> On Th
On 21.01.2016 19:08, Daniel Vetter wrote:
> Equivalent change to the radeon driver.
>
> Note that with radeon this caught a bug in the dri3 DDX
> implementation, which asked for vblank interrupts when the pipe is
> off. That bug needs to be fixed before we can merge this patch (if
> amdgpu is affe
On 21.01.2016 19:08, Daniel Vetter wrote:
> These should be functionally equivalent to the older per/post modeset
> functions, except that they block out drm_vblank_get right away.
> There's only the clock adjusting code (outside of pageflips) in
> readone which uses drm_vblank_get. But that code d
On 21.01.2016 18:16, Mario Kleiner wrote:
> On 01/21/2016 09:25 AM, Michel Dänzer wrote:
>> On 21.01.2016 17:16, Mario Kleiner wrote:
>>>
>>> This patch replaces calls to drm_vblank_pre/post_modeset in the
>>> drivers dpms code with calls to drm_vblank_off/on, as recommended
>>> for drivers with h
[ Trimming KDE folks from Cc ]
On 21.01.2016 19:09, Daniel Vetter wrote:
> On Thu, Jan 21, 2016 at 05:36:46PM +0900, Michel Dänzer wrote:
>> On 21.01.2016 16:58, Daniel Vetter wrote:
>>>
>>> Can you please point me at the vblank on/off jump bug please?
>>
>> AFAIR I originally reported it in re
Hi Daniel,
Thanks for the tip.
I just enabled fb.lockless_register_fb=1 and still cannot see any debug
messages after the console_lock... :(
Regards,
C.Palminha
On 22-01-2016 07:53, Daniel Vetter wrote:
> Every new KMS driver writer seems to run into this and wonder how
> exactly drm_fb_helper_
On 22.01.2016 02:10, Alex Deucher wrote:
> On Thu, Jan 21, 2016 at 10:39 AM, Oded Gabbay
> wrote:
>> +Alex
>
> No objections from me. Care to respin with amdgpu support and signed
> off? Would probably also be nice to split the core drm change from
> the driver specific ones.
Also, it would b
On 21.01.2016 19:08, Daniel Vetter wrote:
> In
>
> commit 9cba5efab5a8145ae6c52ea273553f069c294482
> Author: Mario Kleiner
> Date: Tue Jul 29 02:36:44 2014 +0200
>
> drm/nouveau: Dis/Enable vblank irqs during suspend/resume
>
> drm_vblank_on/off calls where added around suspend/resume to
Hi Philipp,
2015-11-23 19:48 GMT+08:00 Philipp Zabel :
> Am Freitag, den 20.11.2015, 16:14 +0800 schrieb Liu Ying:
>> This patch changes the dev_info() call to dev_dbg() in ipu_plane_update()
>> to print out the information that a plane's CRTC is changed, because this
>> kind of information is onl
It may caused a dead lock if we flush the hpd work in bridge disable time.
The normal flow would like:
IN --> DRM IOCTL
1. Acquire crtc_ww_class_mutex (DRM IOCTL)
IN --> analogix_dp_bridge
2. Acquire hpd work lock (Flush hpd work)
3. HPD work already in idle, no need to
Turn off the panel power in suspend time would help to reduce
power waste.
Signed-off-by: Yakir Yang
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Changes in v5: None
Changes
Display Port monitor could support kinds of mode which indicate
in monitor edid, not just one single display resolution which
defined in panel or devivetree property display timing.
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
This change just make a little clean to make code more like
drm core expect, move hdp detect code from bridge->enable(),
and place them into connector->detect().
Note: Gustavo Padovan try to remove the controller and phy
power on function in bind time at bellow commit:
drm/exynos: do not s
Some edp screen do not have hpd signal, so we can't just return
failed when hpd plug in detect failed.
This is an hardware property, so we need add a devicetree property
"analogix,need-force-hpd" to indicate this sutiation.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Tested-by: Javier Marti
There are some IP limit on rk3288 that only support 4 physical lanes
of 2.7/1.6 Gbps/lane, so seprate them out by device_type flag.
Signed-off-by: Yakir Yang
Tested-by: Javier Martinez Canillas
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10:
- Remove the surplu
RK3288 need some special registers setting, we can separate
them out by the dev_type of plat_data.
Signed-off-by: Yakir Yang
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v10: None
Changes in v9: None
Changes in v8: None
Changes in v7: None
Changes in v6: None
Chan
Add dt binding documentation for rockchip display port PHY.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v13: None
Changes in v12: None
Changes in v11:
- Correct the title of this rockchip dp phy document(Rob)
- Add the ack from Rob Herring
Changes
Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.
Signed-off-by: Yakir Yang
Reviewed-by: Heiko Stuebner
---
Changes in v13: None
Changes in v12:
- Re-order the include headers file alphabetically in phy-rockchip-dp.c (Jingoo)
C
Rockchip DP driver is a helper driver of analogix_dp coder driver,
so most of the DT property should be descriped in analogix_dp document.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
Reviewed-by: Heiko Stuebner
---
Changes in v13: None
Changes in v12: None
Changes in v11: None
Changes in v1
Rockchip have three clocks for dp controller, we leave pclk_edp
to analogix_dp driver control, and keep the sclk_edp_24m and
sclk_edp in platform driver.
Signed-off-by: Yakir Yang
Tested-by: Heiko Stuebner
---
Changes in v13:
- Use .enable instead of preprare/commit in encoder_helper_funcs (Heik
After exynos_dp have been split the common IP code into analogix_dp driver,
the analogix_dp driver have deprecated some Samsung platform properties which
could be dynamically parsed from EDID/MODE/DPCD message, so this is an update
for Exynos DTS file for dp-controller.
Beside the backward compati
Analogix dp driver is split from exynos dp driver, so we just
make an copy of exynos_dp.txt, and then simplify exynos_dp.txt
Beside update some exynos dtsi file with the latest change
according to the devicetree binding documents.
Signed-off-by: Yakir Yang
Acked-by: Rob Herring
---
Changes in v
Both hsync/vsync polarity and interlace mode can be parsed from
drm display mode, and dynamic_range and ycbcr_coeff can be judge
by the video code.
But presumably Exynos still relies on the DT properties, so take
good use of mode_fixup() in to achieve the compatibility hacks.
Signed-off-by: Yakir
link_rate and lane_count already configured in analogix_dp_set_link_train(),
so we don't need to config those repeatly after training finished, just
remove them out.
Beside Display Port 1.2 already support 5.4Gbps link rate, the maximum sets
would change from {1.62Gbps, 2.7Gbps} to {1.62Gbps, 2.7G
Fix some obvious alignment problems, like alignment and line
over 80 characters problems, make this easy to be maintained
later.
Signed-off-by: Yakir Yang
Acked-by: Jingoo Han
Reviewed-by: Krzysztof Kozlowski
Tested-by: Javier Martinez Canillas
---
Changes in v13: None
Changes in v12:
- Add th
Split the dp core driver from exynos directory to bridge directory,
and rename the core driver to analogix_dp_*, rename the platform
code to exynos_dp.
Beside the new analogix_dp driver would export six hooks.
"analogix_dp_bind()" and "analogix_dp_unbind()"
"analogix_dp_suspned()" and "analogix_dp
Hi all,
The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
contro
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/0a43874c/attachment.html>
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20160122/455988f1/attachment.html>
Hi Heiko,
On 01/22/2016 03:11 AM, Heiko Stuebner wrote:
> Hi Yakir,
>
> Am Dienstag, 19. Januar 2016, 18:04:53 schrieb Yakir Yang:
>> Rockchip have three clocks for dp controller, we leave pclk_edp
>> to analogix_dp driver control, and keep the sclk_edp_24m and
>> sclk_edp in platform driver.
>>
>
Hi Dave
Here are some fixes for drm/rockchip, these fixes base on drm-next.
These fixes works on my popmetal(rk3288) board.
About patch: drm/atomic-helper: Export framebuffer_changed()
Daniel Vetter ack for merging it through rockchip git trees, so
framebuffer_changed() can be reused by drm/roc
Am 22.01.2016 um 06:15 schrieb Alex Deucher:
> On Thu, Jan 21, 2016 at 7:12 PM, Julian Margetson wrote:
>> On 12/28/2015 11:58 AM, Julian Margetson wrote:
>>
>> Having an isssue when adding Radeon TAHITI_vce.bin firmware to kernel.
>> When not compiled into 4.4.0rc kernels system boots but with er
On 2016å¹´01æ22æ¥ 02:19, John Keeping wrote:
> If DRM_FBDEV_EMULATION is not selected in the config then we can save a
> bit of space by not including the framebuffer code.
>
> Signed-off-by: John Keeping
> ---
> On Thu, 21 Jan 2016 17:52:51 +0100, Daniel Vetter wrote:
>
>> On Thu, Jan 21, 2016
On 01/22/2016 08:54 AM, Sudip Mukherjee wrote:
> On Friday 22 January 2016 08:01 PM, Guenter Roeck wrote:
>> On Mon, Dec 21, 2015 at 06:08:44PM -0800, Eric Anholt wrote:
>>> I've tested and confirmed that it doesn't actually work. We'll need
>>> to sort out how to do this properly later, but for n
Every new KMS driver writer seems to run into this and wonder how
exactly drm_fb_helper_initial_config can die doing nothing at all.
Set up some big warnings signs around this newbie trap to avoid future
frustration and wasting everyone's time.
Cc: Carlos Palminha
Cc: Xinliang Liu
Cc: laurent.pi
On Thu, Jan 21, 2016 at 7:09 PM, Carlos Palminha
wrote:
> i made some progress in identifying the issue...
> When my driver calls drm_fb_helper_initial_config it seems DRM blocks waiting
> for register_framebuffer to return.
> The sequence is
> drm_fb_helper_initial_config->drm_fb_helper_single_
https://bugzilla.kernel.org/show_bug.cgi?id=108221
--- Comment #14 from Fred Santos ---
(In reply to Michel Dänzer from comment #10)
> (In reply to Fred Santos from comment #9)
> > (Is there a way to 'force' the use of amdgpu?)
>
> Yes, you can force it in Section "Device" in /etc/X11/xorg.conf
Hey,
On 22 January 2016 at 07:41, Daniel Vetter wrote:
> On Thu, Jan 21, 2016 at 7:09 PM, Carlos Palminha
> wrote:
>> i made some progress in identifying the issue...
>> When my driver calls drm_fb_helper_initial_config it seems DRM blocks
>> waiting for register_framebuffer to return.
>> The s
Hi,
On 21 January 2016 at 18:30, Carlos Palminha
wrote:
> i just found that its blocking waiting for console_lock...
> @vineet, alexey: i think that console_lock is architecture dependent right?
> Do you know any issue with console_lock for ARC?
Once console_lock is acquired, you will not see a
1 - 100 of 104 matches
Mail list logo
