Hello Thierry,
2015-11-17 13:55 GMT+01:00 Thierry Reding :
> On Mon, Nov 16, 2015 at 05:28:24PM +0100, Enric Balletbo Serra wrote:
>> Hello Thierry,
>>
>> Many thanks for your comments.
>>
>> 2015-11-16 12:50 GMT+01:00 Thierry Reding :
>> > On Sat, Nov 14, 2015 at 07:38:19PM +0100, Enric Balletbo
.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151117/4d31a75d/attachment.html>
[1.] One line summary of the problem:
1002:68a0 After suspend-resume graphics are sluggish and input lags with
displayport connected
[2.] Full description of the problem/report:
Tested with latest mainline kernel available: v4.3
Test system had Ubuntu 15.10 installed.
Booting up with displayport
On Tue, Nov 17, 2015 at 10:23 PM, David Binderman wrote:
> Hello there,
>
> [linux-4.4-rc1/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c:206]: (error)
> Array 'dsi_errors[31]' accessed at index 31, which is out of bounds.
>
> I looks to me like array dsi_errors is badly laid out:
>
> "LP
On 17 November 2015 at 20:13, Dave Airlie wrote:
>>
>> The kernel UAPI headers:
>> - Used by the kernel modules and userspace(?)
>> - Installed in /usr/include/drm
>> - Many distributions do _not_ ship them
>> - Broken for years (mostly fixed with Mikko's earlier patches)
>> - For the above
On Tue, Nov 17, 2015 at 7:18 PM, Linus Torvalds
wrote:
> On Tue, Nov 17, 2015 at 9:53 AM, Olof Johansson wrote:
>>
>> The problem as I see it is that it's unknown how many machines depends
>> on previous behavior. If it's only Pixel 2015 then I think a whitelist
>> would be just fine.
>
>
Hi Jingoo & Exynos DRM Maintainers (Inki & Andrzej & Joonyoung) & Bridge
Maintainers (Thierry?):
Ping...
The front part of this series (exynos_dp to analogix_dp) haven't received
more comments in the pasted several months. Is it difficult to carry those
patches without new changes but
Hello there,
[linux-4.4-rc1/drivers/gpu/drm/gma500/mdfld_dsi_pkg_sender.c:206]: (error)
Array 'dsi_errors[31]' accessed at index 31, which is out of bounds.
I looks to me like array dsi_errors is badly laid out:
   "LP Generic Write FIFO Full",
   "Generic Read Data Avail"
  Â
dma_addr_t may be 32 or 64 bits long on 32-bit CPUs, so we cannot
cast it to a pointer without getting a compiler warning:
drivers/gpu/drm/exynos/exynos_drm_buf.c: In function 'lowlevel_buffer_allocate':
drivers/gpu/drm/exynos/exynos_drm_buf.c:109:18: warning: cast from pointer to
integer of
On 17 November 2015 at 19:13, Gabriel Laskar wrote:
> On Tue, 17 Nov 2015 11:08:12 +
> Emil Velikov wrote:
>
>> With the above said:
>> - I was thinking about hiding the UAPI ones, although Dave suggested
>> against it.
>> - Doing s|drm/drm.h|drm.h| will break compilation:
>>+ for the
Hi John,
[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.4-rc1 next-20151117]
url:
https://github.com/0day-ci/linux/commits/John-Keeping/drm-support-hotspot-for-universal-plane-cursors/20151117-203428
base: git://people.freedesktop.org/~airlied/linux.git drm-next
Add phy driver for the Rockchip DisplayPort PHY module. This
is required to get DisplayPort working in Rockchip SoCs.
Reviewed-by: Heiko Stuebner
Signed-off-by: Yakir Yang
---
Changes in v10:
- Fix the wrong macro value of GRF_EDP_REF_CLK_SEL_INTER_HIWORD_MASK (Brian)
BIT(4) -> BIT(20)
Hi Brian,
Thank you for debugging, and fell sorry for the delay reply
On 11/06/2015 07:45 AM, Brian Norris wrote:
> Hi,
>
> A few updates:
>
> On Tue, Nov 03, 2015 at 05:13:48PM -0800, Brian Norris wrote:
>> On Wed, Nov 04, 2015 at 08:48:38AM +0800, Yakir Yang wrote:
>>> On 11/03/2015 12:38 PM,
On Tue, 17 Nov 2015 11:08:12 +
Emil Velikov wrote:
> With the above said:
> - I was thinking about hiding the UAPI ones, although Dave suggested
> against it.
> - Doing s|drm/drm.h|drm.h| will break compilation:
>+ for the kernel - as we don't add the foo/drm/ to the include directive,
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151117/a0dbc0ec/attachment.html>
On Tue, Nov 17, 2015 at 06:47:28PM +, John Keeping wrote:
> On Tue, 17 Nov 2015 19:31:32 +0100, Daniel Vetter wrote:
>
> > On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:
> > > On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter
> > > wrote:
> > > > On Tue, Nov 17, 2015 at
ves/dri-devel/attachments/20151117/56ddb9a8/attachment.html>
On Tue, Nov 17, 2015 at 04:58:06PM +, John Keeping wrote:
> On Tue, 17 Nov 2015 17:29:35 +0100, Daniel Vetter wrote:
>
> > On Tue, Nov 17, 2015 at 03:59:43PM +, John Keeping wrote:
> > > On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> > >
> > > > On Tue, Nov 17, 2015 at
On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:
> On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter wrote:
> > On Tue, Nov 17, 2015 at 03:59:43PM +, John Keeping wrote:
> >> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> >>
> >> > On Tue, Nov 17, 2015 at 03:05:34PM
Small typo:
'scalling' -> 'scaling'
With best wishes,
Tobias
Marek Szyprowski wrote:
> This patch fixes calculation of src x/y offset for negative crtc x/y
> values when scalling is enabled. This fixes possible IOMMU fault when
> scalling is enabled.
>
> Signed-off-by: Marek Szyprowski
> ---
>
Hello guys,
Daniel Stone wrote:
> Hi Marek,
>
> On 16 November 2015 at 11:35, Marek Szyprowski
> wrote:
>> On 2015-11-12 15:46, Daniel Stone wrote:
>>> On 12 November 2015 at 12:44, Tobias Jakobi
>>> wrote:
I wonder how this interacts with page flipping. If I queue a pageflip
event
Hello Marek,
Marek Szyprowski wrote:
> This patch adds common structure for keeping plane configuration and
> capabilities data. This patch is inspired by similar code developed by
> Tobias Jakobi.
>
> Signed-off-by: Marek Szyprowski
> ---
> drivers/gpu/drm/exynos/exynos5433_drm_decon.c | 18
On Tue, 17 Nov 2015 19:31:32 +0100, Daniel Vetter wrote:
> On Tue, Nov 17, 2015 at 12:07:24PM -0500, Alex Deucher wrote:
> > On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter
> > wrote:
> > > On Tue, Nov 17, 2015 at 03:59:43PM +, John Keeping wrote:
> > >> On Tue, 17 Nov 2015 17:39:32
On Tue, Nov 17, 2015 at 03:59:43PM +, John Keeping wrote:
> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
>
> > On Tue, Nov 17, 2015 at 03:05:34PM +, John Keeping wrote:
> > > The request's hot_x and hot_y are set correctly for both
> > > DRM_IOCTL_MODE_CURSOR and
art --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151117/3a9b5cd3/attachment.html>
OpenGL. I must
restart a Computer. Dmesg-log attached
--
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/20151117/e709b
On Tue, Nov 17, 2015 at 03:05:34PM +, John Keeping wrote:
> The request's hot_x and hot_y are set correctly for both
> DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to save
> the values and then apply the offset to the cursor plane when the cursor
> moves.
>
>
On 11/17/15 12:28, Daniel Vetter wrote:
> On Fri, Nov 13, 2015 at 05:53:13PM +0200, Jyri Sarha wrote:
>> Since first RFC version:
>> - Added "drm/atomic: Track drm_plane's active state"-patch
>>
>> We would need something like this to get rid off OMAPDSS somewhat
>> messy runtime_resume code. How
On Tue, Nov 17, 2015 at 03:59:43PM +, John Keeping wrote:
> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
>
> > On Tue, Nov 17, 2015 at 03:05:34PM +, John Keeping wrote:
> > > The request's hot_x and hot_y are set correctly for both
> > > DRM_IOCTL_MODE_CURSOR and
On Tue, 17 Nov 2015 13:29:49 -0200
Mauro Carvalho Chehab wrote:
> The enclosed patch should do the trick. I tested it with perl 5.10 and
> perl 5.22 it worked fine with both versions.
Indeed it seems to work - thanks! Applied to the docs tree, I'll get it
upstream before too long.
jon
On Tue, Nov 17, 2015 at 04:58:25PM +0200, Jani Nikula wrote:
> On Mon, 16 Nov 2015, Thierry Reding wrote:
> > An encoder is associated with a connector by the DRM core as a result of
> > setting up a configuration. Drivers using the atomic or legacy helpers
> > should never set up this link, even
On Tue, Nov 17, 2015 at 03:19:35PM +0100, Andrzej Hajda wrote:
> Hi Daniel,
>
> On 11/17/2015 11:06 AM, Daniel Vetter wrote:
> > On Thu, Nov 12, 2015 at 02:49:29PM +0100, Thierry Reding wrote:
> >> On Thu, Nov 12, 2015 at 11:11:20AM -0200, Gustavo Padovan wrote:
> >>> From: Gustavo Padovan
> >>>
On Mon, 16 Nov 2015, Thierry Reding wrote:
> An encoder is associated with a connector by the DRM core as a result of
> setting up a configuration. Drivers using the atomic or legacy helpers
> should never set up this link, even if it is a static one.
Not to block this patch in any way, but
On Tue, 17 Nov 2015 17:29:35 +0100, Daniel Vetter wrote:
> On Tue, Nov 17, 2015 at 03:59:43PM +, John Keeping wrote:
> > On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> >
> > > On Tue, Nov 17, 2015 at 03:05:34PM +, John Keeping wrote:
> > > > The request's hot_x and
On Tue, 17 Nov 2015, John Harrison wrote:
> This seems to have caused a warning to appear. I generally build with
> -Werror which means my build is broken :(.
>
> intel_display.c: In function 'intel_user_framebuffer_create':
> i915/intel_display.c(14593)2: warning: passing argument 2 of
>
On Tue, 17 Nov 2015, Ville Syrjälä wrote:
> On Tue, Nov 17, 2015 at 01:04:21PM +0200, Ville Syrjälä wrote:
>> On Tue, Nov 17, 2015 at 10:47:06AM +0100, Daniel Vetter wrote:
>> > On Wed, Nov 11, 2015 at 07:11:28PM +0200, ville.syrjala at linux.intel.com
>> > wrote:
>> > > From: Ville
After a recent change, two variables were left unused:
exynos/exynos5433_drm_decon.c: In function 'decon_enable':
exynos/exynos5433_drm_decon.c:381:6: warning: unused variable 'i'
[-Wunused-variable]
exynos/exynos5433_drm_decon.c:380:6: warning: unused variable 'ret'
[-Wunused-variable]
This
On Tue, 17 Nov 2015, Daniel Vetter wrote:
> On Mon, Nov 16, 2015 at 05:02:34PM +0200, ville.syrjala at linux.intel.com
> wrote:
>> From: Ville Syrjälä
>>
>> Properly double the hdisplay/vdisplay timings that we use as the primary
>> plane size with stereo doubled modes. Otherwise the modeset
On 14.11.2015 07:06, Emil Velikov wrote:
> On 13 November 2015 at 21:36, Gabriel Laskar wrote:
>>
>> There is still some issues on the headers, like the inclusion of drm.h.
>>
>> AFAIK, we should include "drm.h", in order to minimize the changes
>> between linux/libdrm when importing, as the
ll try to
test them.
--
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/20151117/7ed6074f/attachment.html>
The runtime PM operations use the suspend/resume functions
even when CONFIG_PM_SLEEP is not set, but this now fails
for the exynos DRM driver:
exynos_mixer.c:1289:61: error: 'exynos_mixer_resume' undeclared here (not in a
function)
SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume,
On 2015å¹´11æ17æ¥ 00:25, Daniel Vetter wrote:
> On Tue, Nov 10, 2015 at 05:11:57PM +0800, Mark Yao wrote:
>> >We want to display a buffer allocated by other driver, need import
>> >the buffer to gem.
> Does this work with some open-source driver/userspace or is this for the
> proprietary stack
On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
> On Tue, Nov 17, 2015 at 03:05:34PM +, John Keeping wrote:
> > The request's hot_x and hot_y are set correctly for both
> > DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to
> > save the values and then apply the
Hi Daniel,
On 11/17/2015 11:06 AM, Daniel Vetter wrote:
> On Thu, Nov 12, 2015 at 02:49:29PM +0100, Thierry Reding wrote:
>> On Thu, Nov 12, 2015 at 11:11:20AM -0200, Gustavo Padovan wrote:
>>> From: Gustavo Padovan
>>>
>>> Fixes an regression added by 3ae2436 (drm/exynos/mixer: replace
>>>
The request's hot_x and hot_y are set correctly for both
DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to save
the values and then apply the offset to the cursor plane when the cursor
moves.
Signed-off-by: John Keeping
---
v2:
- add kerneldoc for hot_x and hot_y in struct
vel/attachments/20151117/5f9e5ddd/attachment.html>
On Tue, Nov 17, 2015 at 01:04:21PM +0200, Ville Syrjälä wrote:
> On Tue, Nov 17, 2015 at 10:47:06AM +0100, Daniel Vetter wrote:
> > On Wed, Nov 11, 2015 at 07:11:28PM +0200, ville.syrjala at linux.intel.com
> > wrote:
> > > From: Ville Syrjälä
> > >
> > > We try to convert the old way of of
On Tue, Nov 17, 2015 at 1:40 PM, Daniel Vetter wrote:
> On Tue, Nov 17, 2015 at 04:58:06PM +, John Keeping wrote:
>> On Tue, 17 Nov 2015 17:29:35 +0100, Daniel Vetter wrote:
>>
>> > On Tue, Nov 17, 2015 at 03:59:43PM +, John Keeping wrote:
>> > > On Tue, 17 Nov 2015 17:39:32 +0200, Ville
ore
> canonical ?
>
>HDMI_MPEG_UNKNOWN_FRAME = 0x00,
>HDMI_MPEG_I_FRAME = 0x01,
>HDMI_MPEG_B_FRAME = 0x02,
>HDMI_MPEG_P_FRAME = 0x03,
I wasn't very clear. What I meant was the names for the constants. At
least personally I know immediately what is meant when I see "I-Frame",
"P-Frame" or "B-Frame", whereas "Bi-predictive picture" needs more
thinking.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151117/dfa13696/attachment-0001.sig>
On 17-11-2015 13:29, Mauro Carvalho Chehab wrote:
> Em Tue, 17 Nov 2015 07:44:31 -0700
> Jonathan Corbet escreveu:
>
>> On Tue, 17 Nov 2015 08:40:46 -0200
>> Mauro Carvalho Chehab wrote:
>>
>>> The above causes some versions of perl to fail, as keys expect a
>>> hash argument:
>>>
>>>
This seems to have caused a warning to appear. I generally build with
-Werror which means my build is broken :(.
intel_display.c: In function 'intel_user_framebuffer_create':
i915/intel_display.c(14593)2: warning: passing argument 2 of
'intel_framebuffer_create' discards 'const' qualifier from
Em Tue, 17 Nov 2015 07:44:31 -0700
Jonathan Corbet escreveu:
> On Tue, 17 Nov 2015 08:40:46 -0200
> Mauro Carvalho Chehab wrote:
>
> > The above causes some versions of perl to fail, as keys expect a
> > hash argument:
> >
> > Execution of .//scripts/kernel-doc aborted due to compilation
On Tue, Nov 17, 2015 at 11:15:43AM +0100, Daniel Vetter wrote:
> On Fri, Nov 13, 2015 at 01:03:48PM +0200, Ville Syrjälä wrote:
> > On Fri, Nov 13, 2015 at 12:18:24PM +0200, Jani Nikula wrote:
> > > On Thu, 12 Nov 2015, ville.syrjala at linux.intel.com wrote:
> > > > diff --git
On Tue, 17 Nov 2015, Daniel Vetter wrote:
> On Wed, Nov 11, 2015 at 11:29:11AM +0100, Maarten Lankhorst wrote:
>> From: Maarten Lankhorst
>>
>> Signed-off-by: Maarten Lankhorst
>
> Needs "Don't touch plane->old_fb/fb without having the right locks held."
> like the previous patch in the commit
On Tue, Nov 17, 2015 at 10:47:06AM +0100, Daniel Vetter wrote:
> On Wed, Nov 11, 2015 at 07:11:28PM +0200, ville.syrjala at linux.intel.com
> wrote:
> > From: Ville Syrjälä
> >
> > We try to convert the old way of of specifying fb tiling (obj->tiling)
> > into the new fb modifiers. We store
2015-09-30 23:36 GMT+09:00 Gustavo Padovan :
> Hi Andrzej,
>
> 2015-09-25 Andrzej Hajda :
>
>> samsung,exynos5-hdmi compatible was marked as deprecated in Jun 2013.
>> It was never used since then.
>>
>> Signed-off-by: Andrzej Hajda
>> ---
>>
On Tue, 17 Nov 2015, Daniel Vetter wrote:
> On Thu, Nov 12, 2015 at 06:52:20PM +0200, ville.syrjala at linux.intel.com
> wrote:
>> From: Ville Syrjälä
>>
>> I got sick and tired of staring at the line noise produced by drm.debug=0x1e,
>> so I decided to give the crtcs and planes human
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151117/1a23dacc/attachment.html>
The request's hot_x and hot_y are set correctly for both
DRM_IOCTL_MODE_CURSOR and DRM_IOCTL_MODE_CURSOR2 so we just need to save
the values and then apply the offset to the cursor plane when the cursor
moves.
Signed-off-by: John Keeping
---
drivers/gpu/drm/drm_crtc.c | 11 +++
On Tue, Nov 17, 2015 at 11:29 AM, Daniel Vetter wrote:
> On Tue, Nov 17, 2015 at 03:59:43PM +, John Keeping wrote:
>> On Tue, 17 Nov 2015 17:39:32 +0200, Ville Syrjälä wrote:
>>
>> > On Tue, Nov 17, 2015 at 03:05:34PM +, John Keeping wrote:
>> > > The request's hot_x and hot_y are set
Op 11-11-15 om 11:29 schreef Maarten Lankhorst:
> From: Maarten Lankhorst
>
> This is useful for all the boilerplate code about cleaning old_fb.
Signed-off-by: Maarten Lankhorst
On Mon, Nov 16, 2015 at 05:02:34PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Properly double the hdisplay/vdisplay timings that we use as the primary
> plane size with stereo doubled modes. Otherwise the modeset gets
> rejected on machines where the primary
2015ë
11ì 17ì¼ 01:23ì Daniel Vetter ì´(ê°) ì´ ê¸:
> On Mon, Nov 16, 2015 at 05:22:42PM +0100, Daniel Vetter wrote:
>> On Tue, Jul 28, 2015 at 05:53:23PM +0900, Joonyoung Shim wrote:
>>> Don't create a fake mmap offset in exynos_drm_gem_dumb_map_offset. If
>>> not, it will call
On Mon, Nov 16, 2015 at 06:19:53PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> An encoder is associated with a connector by the DRM core as a result of
> setting up a configuration. Drivers using the atomic or legacy helpers
> should never set up this link, even if it is a static
Typing:
# cat /sys/devices/pci:00/:00:02.0/rom
Provokes:
i915 :00:02.0: Invalid ROM contents
This is on a Dell XPS 13 9350 (Skylake). This is 4.3.0 plus some
wireless-next bits.
--Andy
--
Andy Lutomirski
AMA Capital Management, LLC
On Mon, Nov 16, 2015 at 05:46:46PM +, Russell King - ARM Linux wrote:
> On Mon, Nov 16, 2015 at 06:19:53PM +0100, Thierry Reding wrote:
> > From: Thierry Reding
> >
> > An encoder is associated with a connector by the DRM core as a result of
> > setting up a configuration. Drivers using the
On Fri, Nov 13, 2015 at 05:53:13PM +0200, Jyri Sarha wrote:
> Since first RFC version:
> - Added "drm/atomic: Track drm_plane's active state"-patch
>
> We would need something like this to get rid off OMAPDSS somewhat
> messy runtime_resume code. How does this look, could this generic
> solution
On Fri, Nov 13, 2015 at 07:38:21PM +, Alexander Goins wrote:
> Sorry; needless to say I'm not super familiar with the Intel driver.
> ilk_do_mmio_flip() uses crtc->primary->fb to fetch the gem object:
>
> struct intel_framebuffer *intel_fb =
>
On Fri, Nov 13, 2015 at 01:03:48PM +0200, Ville Syrjälä wrote:
> On Fri, Nov 13, 2015 at 12:18:24PM +0200, Jani Nikula wrote:
> > On Thu, 12 Nov 2015, ville.syrjala at linux.intel.com wrote:
> > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
> > > index 24c5434..ea00a69
On Thu, Nov 12, 2015 at 06:52:20PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> I got sick and tired of staring at the line noise produced by drm.debug=0x1e,
> so I decided to give the crtcs and planes human readable names. Each driver
> can give whatever names it
On 17 November 2015 at 07:22, Michel Dänzer wrote:
> On 14.11.2015 07:06, Emil Velikov wrote:
>> On 13 November 2015 at 21:36, Gabriel Laskar wrote:
>>>
>>> There is still some issues on the headers, like the inclusion of drm.h.
>>>
>>> AFAIK, we should include "drm.h", in order to minimize the
On Thu, Nov 12, 2015 at 02:49:29PM +0100, Thierry Reding wrote:
> On Thu, Nov 12, 2015 at 11:11:20AM -0200, Gustavo Padovan wrote:
> > From: Gustavo Padovan
> >
> > Fixes an regression added by 3ae2436 (drm/exynos/mixer: replace
> > direct cross-driver call with drm mode). The whole atomic
On Thu, Nov 12, 2015 at 04:09:56PM +0900, Alexandre Courbot wrote:
> drm_gem_object_unreference() now expects obj->dev->struct_mutex to be
> held. Use the newly-introduced drm_gem_object_unreference_unlocked()
> which handles locking for us.
This rule has been really old, I simply made the
On Wed, Nov 11, 2015 at 11:29:11AM +0100, Maarten Lankhorst wrote:
> From: Maarten Lankhorst
>
> Signed-off-by: Maarten Lankhorst
Needs "Don't touch plane->old_fb/fb without having the right locks held."
like the previous patch in the commit message. With that for patches 4&5:
Reviewed-by:
On Wed, Nov 11, 2015 at 11:29:09AM +0100, Maarten Lankhorst wrote:
> From: Maarten Lankhorst
>
> This is useful for all the boilerplate code about cleaning old_fb.
> ---
> drivers/gpu/drm/drm_atomic.c | 58
> ++--
> include/drm/drm_atomic.h | 3 +++
On Wed, Nov 11, 2015 at 11:29:08AM +0100, Maarten Lankhorst wrote:
> From: Maarten Lankhorst
>
> plane_mask should be cleared inside the retry loop,
> because it gets reset on every retry.
>
> Signed-off-by: Maarten Lankhorst
> Cc: stable at vger.kernel.org #v4.3
Nice catch, but a bit a terse
On Wed, Nov 11, 2015 at 11:29:07AM +0100, Maarten Lankhorst wrote:
> From: Maarten Lankhorst
>
> legacy_cursor_update was being set in restore_fbdev_mode_atomic which was
> probably unintended. Fix this by only setting it in the function that needs
> it.
>
> Signed-off-by: Maarten Lankhorst
On Wed, Nov 11, 2015 at 07:11:29PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> Drivers shouldn't clobber the passed in addfb ioctl parameters.
> i915 was doing just that. To prevent it from happening again,
> pass the struct around as const, starting all the way
On Wed, Nov 11, 2015 at 07:11:28PM +0200, ville.syrjala at linux.intel.com
wrote:
> From: Ville Syrjälä
>
> We try to convert the old way of of specifying fb tiling (obj->tiling)
> into the new fb modifiers. We store the result in the passed in mode_cmd
> structure. But that structure comes
On Tue, Nov 17, 2015 at 11:53:28AM +0900, Inki Dae wrote:
>
>
> 2015ë
11ì 17ì¼ 01:23ì Daniel Vetter ì´(ê°) ì´ ê¸:
> > On Mon, Nov 16, 2015 at 05:22:42PM +0100, Daniel Vetter wrote:
> >> On Tue, Jul 28, 2015 at 05:53:23PM +0900, Joonyoung Shim wrote:
> >>> Don't create a fake mmap
On Mon, Nov 16, 2015 at 06:19:53PM +0100, Thierry Reding wrote:
> From: Thierry Reding
>
> An encoder is associated with a connector by the DRM core as a result of
> setting up a configuration. Drivers using the atomic or legacy helpers
> should never set up this link, even if it is a static
On Mon, Nov 16, 2015 at 05:00:21PM +0100, Daniel Vetter wrote:
> On Wed, Nov 04, 2015 at 06:15:58PM +0800, Liu Ying wrote:
> > Since we are using ipu_plane_init() to add one primary plane for each
> > IPU CRTC, it's unnecessary to create the safe one by using the helper
> > create_primary_plane().
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151117/129180a0/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20151117/b8139a69/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151117/ddcd0ed3/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/20151117/d7096754/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/20151117/45748f24/attachment.html>
Hi Danilo,
Em Tue, 28 Jul 2015 16:45:16 -0300
Danilo Cesar Lemes de Paula escreveu:
> The "highlight" code is very sensible to the order of the hash keys,
> but the order of the keys cannot be predicted on Perl. It generates
> faulty DocBook entries like:
> - @device_for_each_child
>
>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151117/6aa47d06/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151117/ff616a31/attachment.html>
her
information, let me know.
--
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/20151117/aa29c5bf/attachment-0001.html>
On Tue, 17 Nov 2015 08:40:46 -0200
Mauro Carvalho Chehab wrote:
> The above causes some versions of perl to fail, as keys expect a
> hash argument:
>
> Execution of .//scripts/kernel-doc aborted due to compilation errors.
> Type of arg 1 to keys must be hash (not private array) at
>
nt was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151117/ee78a56a/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20151117/cf2ba41a/attachment.html>
94 matches
Mail list logo
