ike WoS games, so maybe it is the same issue :).
--
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/20140520/df30455c/attachment.html>
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/46ceb4f0/attachment.html>
cc'ing dri-devel.
> >From e314a1a1583e585d062dfc30c8aad8bf5380510b Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Mon, 19 May 2014 18:43:21 +0900
> Subject: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker
> functions.
>
> I can observe that RHEL7 environment stalls with 100%
cc'ing dri-devel.
> >From d0d57745ba23faf605b0f249b57d283fe1a8ee60 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Mon, 19 May 2014 17:59:03 +0900
> Subject: [PATCH] gpu/drm/ttm: Pass GFP flags in order to avoid deadlock.
>
> Commit 7dc19d5a "drivers: convert shrinkers to new count/scan A
Hi Linus,
just some intel fixes, I have some radeon ones but I need to get some
patches dropped from the pull req.
Dave.
The following changes since commit 14186fea0cb06bc43181ce239efe0df6f1af260a:
Merge tag 'locks-v3.15-4' of git://git.samba.org/jlayton/linux (2014-05-13
11:33:09 +0900)
On 19 May 2014 16:24, Tomasz Figa wrote:
> On 19.05.2014 09:10, Rahul Sharma wrote:
>> On 16 May 2014 20:19, Tomasz Figa wrote:
>>> On 16.05.2014 16:30, Rahul Sharma wrote:
On 16 May 2014 16:20, Tomasz Figa wrote:
> On 16.05.2014 12:35, Rahul Sharma wrote:
>> On 16 May 2014 15:12, R
t --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/53ad9955/attachment.sig>
On Mon, May 19, 2014 at 03:25:45PM -0700, Matt Roper wrote:
> On Sat, May 17, 2014 at 12:43:04AM +0200, Daniel Vetter wrote:
> > On Sat, May 17, 2014 at 12:38 AM, Matt Roper
> > wrote:
> > > + if (ret) {
> > > + if (req->flags & DRM_MODE_CURSOR_BO)
> > > +
On Mon, May 19, 2014 at 04:58:39PM -0700, Matt Roper wrote:
> If drivers support universal planes and have registered a cursor plane
> with the DRM core, we should use that universal plane support when
> handling legacy cursor ioctls. Drivers that transition to universal
> planes won't have to mai
On 20 May 2014 12:25, Stephen Rothwell wrote:
> Hi Sumit,
>
> Today's linux-next merge of the dma-buf tree got a conflict in
> drivers/gpu/drm/i915/i915_gem_dmabuf.c between commit 5cc9ed4b9a7a
> ("drm/i915: Introduce mapping of user pages into video memory (userptr)
> ioctl") from the drm-intel t
, gl_PrimitiveID is
always zero.
--
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/20140520/43bdbc10/attachment.html>
Version|unspecified |git
--
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/20140520/556cfa5f/attachment-0001.html>
Konrad,
This looks OK to me, but do you have a chance to take a look?
/Thomas
Original Message
Return-Path:
X-Original-To: thomas at shipmail.org
Delivered-To: thomas at shipmail.org
Received: from mail.shipmail.org (lin0.kontor.shipmail.org [127.0.0.1])
by mail.
On 5/19/14, Thierry Reding wrote:
> On Sun, May 18, 2014 at 01:50:36PM +0530, Ajay kumar wrote:
>> On Sun, May 18, 2014 at 2:44 AM, Thierry Reding
>> wrote:
>> > On Thu, May 15, 2014 at 05:10:16PM +0530, Ajay kumar wrote:
>> >> On Thu, May 15, 2014 at 1:43 PM, Thierry Reding
>> >> wrote:
>> > [.
From: Liviu Dudau
Currently the tda998x driver only attempts to instantiate the CEC at I2C
address 0x34, meaning that if the CEC is instead at 0x35 (for example,
due to a conflict with another device) we will not be able to use it.
Attempt to handle some such situations by trying to instantiate t
Exynos drm hdmi driver used to get dummy hdmiphy clock to
control the PMU bit for hdmiphy. This bit needs to be set
before setting any resolution to hdmi hardware. This was
handled using dummy hdmiphy clock which is removed here.
PMU is already defined as system controller for exynos
SoCs. Hdmi dr
On Mon, May 12, 2014 at 04:35:39PM +0800, Jason Wang wrote:
> Return IRQ_NONE if it was not our irq. This is necessary for the case
> when qxl is sharing irq line with a device A in a crash kernel. If qxl
> is initialized before A and A's irq was raised during this gap,
> returning IRQ_HANDLED in t
PU.
--
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/20140520/7638f530/attachment.html>
Hi Thierry, Greg,
On 05/15/2014 10:53 AM, Thierry Reding wrote:
> On Tue, May 13, 2014 at 05:32:15PM -0700, Greg Kroah-Hartman wrote:
>> On Tue, May 13, 2014 at 07:57:13PM +0200, Daniel Vetter wrote:
>>> On Tue, May 13, 2014 at 05:30:47PM +0200, Thierry Reding wrote:
From: Thierry Reding
>>
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/20140520/38abb4cd/attachment.html>
On 05/14/2014 08:26 AM, YoungJun Cho wrote:
> This configuration could be used in MIPI DSI command mode also.
>
> Signed-off-by: YoungJun Cho
> Acked-by: Inki Dae
> Acked-by: Kyungmin Park
Reviewed-by: Andrzej Hajda
> ---
> drivers/gpu/drm/exynos/exynos_drm_dsi.c |5 +++--
> 1 file chang
On 05/14/2014 08:26 AM, YoungJun Cho wrote:
> There could be the case that the page flip operation isn't finished correctly
> with some abnormal condition such as panel reset. So this patch replaces
> wait_event() with wait_event_timeout() to avoid waiting for page flip
> completion
> infinitely.
On Wed, May 14, 2014 at 2:26 PM, YoungJun Cho wrote:
>
> There could be the case that the page flip operation isn't finished correctly
> with some abnormal condition such as panel reset. So this patch replaces
> wait_event() with wait_event_timeout() to avoid waiting for page flip
> completion
>
Also adding dri-devel and linux-media. Please don't forget these lists for
the next round.
-Daniel
On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote:
> Adding Greg just as an fyi since we've chatted briefly about the avsink
> bus. Comments below.
> -Daniel
>
> On Tue, May 20, 2014 at
On 05/14/2014 08:27 AM, YoungJun Cho wrote:
> This patch adds MIPI-DSI command mode based S6E3FA0 AMOLED LCD Panel driver.
>
> Signed-off-by: YoungJun Cho
> Acked-by: Inki Dae
> Acked-by: Kyungmin Park
Few nitpicks, beside them.
Reviewed-by: Andrzej Hajda
> ---
> drivers/gpu/drm/panel/Kconf
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/eb74270a/attachment.html>
On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> Now that we unconditionally dtrt when disabling/enabling crtcs we
> don't need any hacks any longer to keep the vblank logic sane when
> all the registers go poof. So let's rip it all out.
Hmm. drm_update_vblank_count() will now see
gt; > int avsink_read_modify_display_register(struct avsink_client *client,
> > > uint32_t offset, uint32_t data, uint32_t mask);
> > >
> > > If the client is an audio client, the avsink core will find it peer
> > > display client and call its register ops;
> > > and if the client is a display client, the avsink core will just call its
> > > own register ops.
> >
> > Oh dear. Where do we need this? Imo this is really horrible, but if we
> > indeed need this then a struct device is better - we can attach mmio
> > resources to devices and let the audio side remap them as best as they see
> > fit.
Can't this just be put behind an explicit API that does what the
register writes would do? If you share an MMIO region between drivers
you always need to make sure that they don't step on each others' toes.
An explicity API can easily take care of that.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/06eb5d44/attachment.sig>
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #15 from Christian K?nig ---
(In reply to Tasev Nikola from comment #14)
> I tried different value from 128 to 90 for the ref_div_max but none work
> with my Belinea 1600x1200 screen.
Try going down to at least 32, this would match th
games, so maybe it is the same issue :).
You are probably seeing bug 66067 for trine 2.
--
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
On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrj?l? wrote:
> On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > don't need any hacks any longer to keep the vblank logic sane when
> > all the registers go poof.
On Tue, May 20, 2014 at 01:40:40AM +0100, Dave Airlie wrote:
>
> cc'ing dri-devel.
It looks pretty simple and correct . I can test it tomorrow and make sure it
works
right.
>
> > >From d0d57745ba23faf605b0f249b57d283fe1a8ee60 Mon Sep 17 00:00:00 2001
> > From: Tetsuo Handa
> > Date: Mon, 19 Ma
This series of patches add the support of DRM/KMS drivers for STMicroelectronics
chipsets stih416 and stih407.
patcheset version 3:
- Correctly split code between probe and bind funtions
- Squash some commits
- remove HQ-VDP device code to have a smaller patcheset,
Video Time Generator drivers are used to synchronize the compositor
and tvout hardware IPs by providing line count, sample count,
synchronization signals (HSYNC, VSYNC) and top and bottom fields indication.
VTG are used by pair for each data path (main or auxiliary): one for master and
one for sla
Video Trafic Advance Communication Rx and Tx drivers are designed
for inter-die communication.
Both Tx and Rx must share the same configuration to communicate
that is why vtac_mode[] is shared in sti_vtac_utils.h.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Kconfig | 6 +
Add driver for HDMI ouput
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Makefile | 5 +
drivers/gpu/drm/sti/sti_hdmi.c | 529 +
drivers/gpu/drm/sti/sti_hdmi.h | 195 +++
drivers/gpu/drm/sti/sti_hdmi_tx3g0c55ph
Add I2C client driver to retrieve EDID.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Makefile | 3 ++-
drivers/gpu/drm/sti/sti_ddc.c | 56 +++
2 files changed, 58 insertions(+), 1 deletion(-)
create mode 100644 drivers/gpu/drm/sti/sti_ddc.c
Add driver to support analog TV ouput.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Makefile | 1 +
drivers/gpu/drm/sti/sti_hda.c | 480 ++
2 files changed, 481 insertions(+)
create mode 100644 drivers/gpu/drm/sti/sti_hda.c
diff --git a/dr
STI hardware have various input sub-devices before mixing block.
Each type of sub-device have different capabilities for scaling,
filtering or accepted pixel format.
This layer interface abstract those differences and make the interaction
with compositor more simple.
Signed-off-by: Benjamin Gaigna
TVout hardware block is responsible to dispatch the data flow coming
from compositor block to any of the output (HDMI or Analog TV).
It control when output are start/stop and configure according the
require flow path.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Makefile| 3 +-
Generic Display Pipeline are one of the compositor input sub-devices.
GDP are dedicated to graphic input like RGB plans.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Makefile| 3 +-
drivers/gpu/drm/sti/sti_gdp.c | 491
drivers/gpu/drm/
VIDeo plug are one of the compositor input sub-devices.
VID are dedicated to video inputs like YUV plans.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Makefile| 1 +
drivers/gpu/drm/sti/sti_layer.h | 4 ++
drivers/gpu/drm/sti/sti_vid.c | 138
Mixer hardware IP is responsible of mixing the different inputs layers.
Z-order is managed by the mixer.
We could 2 mixers: one for main path and one for auxilary path
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Makefile| 1 +
drivers/gpu/drm/sti/sti_mixer.c | 241
Allow to get more detailed debug information on GDP
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drm_drv.h | 36 ++
drivers/gpu/drm/sti/sti_gdp.c | 235 ++
drivers/gpu/drm/sti/sti_gdp.h | 2 +
3 files changed, 273 insertions(+)
Compositor control all the input sub-devices and the mixer.
It is the main entry point for composition.
Layer interface is used to control the layer.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Kconfig | 1 +
drivers/gpu/drm/sti/Makefile | 2 +
drivers/gpu/drm/s
Make VIdeo plug more verbose on what is on going
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_vid.c | 121 ++
drivers/gpu/drm/sti/sti_vid.h | 1 +
2 files changed, 122 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_vid.c b/drivers/gp
Use debugfs to dump information about TVout
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_tvout.c | 181
1 file changed, 181 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_tvout.c b/drivers/gpu/drm/sti/sti_tvout.c
index 3e679a0..fb199c
Make mixer driver more verbose
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_mixer.c | 164
drivers/gpu/drm/sti/sti_mixer.h | 2 +
2 files changed, 166 insertions(+)
diff --git a/drivers/gpu/drm/sti/sti_mixer.c b/drivers/gpu/drm/sti/sti_
Make the link between all the hardware drivers and DRM/KMS interface.
Create the driver itself and make it register all the sub-components.
Use GEM CMA helpers for buffer allocation.
Signed-off-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/Kconfig | 8 +
drivers/gpu/drm/sti/Makefil
On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrj?l? wrote:
> > On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > > Now that we unconditionally dtrt when disabling/enabling crtcs we
> > > don't need any hacks any l
From: Ville Syrj?l?
We have a few more corner cases with the drm_vblank_on/off stuff. This
series aims to fix those.
I couldn't think of a good way to write a test case for the drm_vblank_get()
issue since it's a transient state that occurs briefly during modeset. So
I added asserts for it inste
From: Ville Syrj?l?
Make sure drm_vblank_get() never succeeds when called between
drm_vblank_off() and drm_vblank_on(). Borrow a trick from the
old drm_vblank_{pre,post}_modeset() functions and just bump
the refcount in drm_vblank_off() and drop it in drm_vblank_on().
Hopefully the use of inmode
From: Ville Syrj?l?
Signed-off-by: Ville Syrj?l?
---
drivers/gpu/drm/i915/intel_display.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index df58afc..9420f4f 100644
--- a/drivers/gpu/drm/i915/in
On Tue, May 20, 2014 at 05:03:33PM +0300, Ville Syrj?l? wrote:
> On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote:
> > On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrj?l? wrote:
> > > On Wed, May 14, 2014 at 08:51:11PM +0200, Daniel Vetter wrote:
> > > > Now that we unconditionally
From: Ville Syrj?l?
If a pipe is already active when we init/resume there might not be a
full modeset afterwards so drm_vblank_on() may not get called. In such
a case if someone is holding a vblank reference across a suspend/resume
cycle drm_vblank_get() called after resuming won't re-enable the
If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls. Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition
On 05/19/2014 03:13 PM, Maarten Lankhorst wrote:
> op 19-05-14 15:42, Thomas Hellstrom schreef:
>> Hi, Maarten!
>>
>> Some nitpicks, and that krealloc within rcu lock still worries me.
>> Otherwise looks good.
>>
>> /Thomas
>>
>>
>>
>> On 04/23/2014 12:15 PM, Maarten Lankhorst wrote:
>>> @@ -55,8 +
On Tue, May 20, 2014 at 4:20 PM, Daniel Vetter wrote:
> On Tue, May 20, 2014 at 05:03:33PM +0300, Ville Syrj?l? wrote:
>> On Tue, May 20, 2014 at 03:38:14PM +0200, Daniel Vetter wrote:
>> > On Tue, May 20, 2014 at 03:03:41PM +0300, Ville Syrj?l? wrote:
>> > > On Wed, May 14, 2014 at 08:51:11PM +02
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #16 from Tasev Nikola ---
Hi
I tried with 64, 48 and 32 for the ref_div_max .
The only one working at boot is 32 , but after the first suspend resume the
off range frequency problem appear again. I try a second suspend resume with
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #17 from Tasev Nikola ---
Created attachment 136831
--> https://bugzilla.kernel.org/attachment.cgi?id=136831&action=edit
dmesg after boot working with max divider 32
--
You are receiving this mail because:
You are watching the assi
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #18 from Tasev Nikola ---
Created attachment 136841
--> https://bugzilla.kernel.org/attachment.cgi?id=136841&action=edit
dmesg after suspend resume broken
--
You are receiving this mail because:
You are watching the assignee of the
ssignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/e98c8ef2/attachment.html>
op 20-05-14 17:13, Thomas Hellstrom schreef:
> On 05/19/2014 03:13 PM, Maarten Lankhorst wrote:
>> op 19-05-14 15:42, Thomas Hellstrom schreef:
>>> Hi, Maarten!
>>>
>>> Some nitpicks, and that krealloc within rcu lock still worries me.
>>> Otherwise looks good.
>>>
>>> /Thomas
>>>
>>>
>>>
>>> On 04
s is not really a
problem, as it comes back happily :) thank you.
--
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/201405
-
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/989fd69d/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #19 from Christian K?nig ---
>From the logs you are always getting the same set of paramaters, even when you
change the maximum used in the fix:
[drm:radeon_compute_pll_avivo] 162000 - 161990, pll dividers - fb: 1425.4 ref:
21, post 6
I think the function should stay in the header file. It's used in
performance-critical code, so we want it to be inlined.
Marek
On Fri, May 16, 2014 at 11:43 PM, Andi Kleen wrote:
> From: Andi Kleen
>
> Saves about 5k of text
>
>textdata bss dec hex filename
> 14080360
https://bugzilla.kernel.org/show_bug.cgi?id=76321
--- Comment #6 from Pali Roh?r ---
Ok, I will look at it and will try to implemenent it. So can you commit
radeon_hwmon_show_temp() part of patch?
--
You are receiving this mail because:
You are watching the assignee of the bug.
rg/archives/dri-devel/attachments/20140520/b874a571/attachment.html>
On Tue, May 20, 2014 at 05:20:05PM +0300, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrj?l?
>
> If a pipe is already active when we init/resume there might not be a
> full modeset afterwards so drm_vblank_on() may not get called. In such
> a case if someone is holding a vblank refere
Yeah, agree. That function is quite critical for command stream parsing
and patching.
Christian.
Am 20.05.2014 18:16, schrieb Marek Ol??k:
> I think the function should stay in the header file. It's used in
> performance-critical code, so we want it to be inlined.
>
> Marek
>
> On Fri, May 16, 2
https://bugzilla.kernel.org/show_bug.cgi?id=76321
--- Comment #7 from Alex Deucher ---
Yes, I already sent attachment 136431 upstream.
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=75241
--- Comment #20 from Tasev Nikola ---
You're right again.
It seems that just build the module doesn't work for me. I build a new kernel
from sources with the ref_div_max 124 and it seems to work for now.
[drm:radeon_compute_pll_avivo] 162000 - 1
is 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/20140520/1bec8f55/attachment.html>
nvilved
:).
--
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/20140520/6ce3adc4/attachment.html>
ts.freedesktop.org/archives/dri-devel/attachments/20140520/7e5f5780/attachment.html>
r the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/b9966bbd/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/8b6604e9/attachment.html>
iving 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/20140520/b57e2793/attachment.html>
ent does not work for Hawaii.
--
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/20140520/974f5bf0/attachment.html>
il because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/20baed8f/attachment.html>
si_get_backend_mask.
--
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/20140520/c4098903/attachment.html>
L:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/0c30060b/attachment-0001.html>
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/09f65a76/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140520/d4b072d2/attachment.html>
We really just want to go detect displays again and fire off a hotplug
event if things have changed, not go through full hotplug processing.
Requested-by: Daniel Vetter
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 20 +---
1 file changed, 1 insertion(+), 19
Gets the detect code (which may take awhile) out of the resume path,
speeding things up a bit.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/i915/i915_drv.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
ind
In some cases, the callers of this function may not need the return
value and delaying the uevent is ok. So add an async version of the
function for use in those cases.
Signed-off-by: Jesse Barnes
---
drivers/gpu/drm/drm_probe_helper.c | 8
include/drm/drm_crtc_helper.h | 2 ++
2
Avoids blank screens on muxed systems when runpm is active.
bug:
https://bugs.freedesktop.org/show_bug.cgi?id=75917
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/vga/vga_switcheroo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/vg
May fix display issues with non-HDMI displays.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 48 ++
1 file changed, 26 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/radeon/atombios_crtc.c
b/d
Need to adjust the pll up for deep color modes.
Additionally, the atom bpc defines were wrong in certain
cases.
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_crtc.c | 36 ++
1 file changed, 28 insertions(+), 8 deleti
From: Mario Kleiner
Program HDMI_CONTROL to send general control packets
for hdmi deep color mode signalling at every video
frame if bpc > 8.
This is only supported on evergreen / DCE-4 and later.
Signed-off-by: Mario Kleiner
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/evergreen_h
From: Mario Kleiner
DCE-4/5/6 can't support more than 12 bpc deep color over hdmi,
so clamp to 12 bpc when a hdmi deep color capable display is
connected. This even makes sense on DCE-8+, which could do up
to 16 bpc, as driving with more than 12 bpc would only waste
video bandwidth as long as we
From: Mario Kleiner
Check the HDMI cea block for deep color mode bits. If available,
assign the highest supported bpc for a hdmi display, corresponding
to the given deep color modes.
Signed-off-by: Mario Kleiner
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/drm_edid.c | 110
On Wed, May 14, 2014 at 08:49:43AM +0900, Gioh Kim wrote:
> Update some descriptions for API arguments and descriptions.
>
> Signed-off-by: Gioh Kim
I applied this to my "dma-api" branch for v3.16, thanks!
> ---
> Documentation/dma-buf-sharing.txt | 14 --
> 1 file changed, 8 ins
On Tue, May 20, 2014 at 9:43 PM, Sumit Semwal
wrote:
> Hi Bjorn,
>
> On 21 May 2014 04:50, Bjorn Helgaas wrote:
>> On Wed, May 14, 2014 at 08:49:43AM +0900, Gioh Kim wrote:
>>> Update some descriptions for API arguments and descriptions.
>>>
>>> Signed-off-by: Gioh Kim
>>
>> I applied this to m
Date 20.5.2014 14:43, Thierry Reding wrote:
> On Tue, May 20, 2014 at 12:04:38PM +0200, Daniel Vetter wrote:
>> Also adding dri-devel and linux-media. Please don't forget these lists for
>> the next round.
>> -Daniel
>>
>> On Tue, May 20, 2014 at 12:02:04PM +0200, Daniel Vetter wrote:
>>> Adding Gr
Hi Dave,
by your request I've removed Alex's I2C mutex patch from the branch. I
would like to keep the VCE patch, cause it actually fixed a serious bug
for me, but I've fixed the formal error of the missing Signed-off-by line.
Additional to that we have two new fixes from Jerome and Alex, both
The following configuration options combination:
CONFIG_DRM_EXYNOS_DP=y
CONFIG_DRM_PTN3460=m
currently leads to the following linker failure:
drivers/built-in.o: In function `exynos_drm_attach_lcd_bridge':
.../drivers/gpu/drm/exynos/exynos_dp_core.c:1004:
undefined reference to `ptn3460_init'
T
This panel is used by my tegra board and supported by the simple-panel
driver.
Signed-off-by: St?phane Marchesin
---
drivers/gpu/drm/panel/panel-simple.c | 25 +
1 file changed, 25 insertions(+)
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/p
1 - 100 of 101 matches
Mail list logo
